diff mbox series

[07/13] drivers: Add generic match helper by ACPI_COMPANION device

Message ID 1559747630-28065-8-git-send-email-suzuki.poulose@arm.com (mailing list archive)
State New, archived
Headers show
Series None | expand

Commit Message

Suzuki K Poulose June 5, 2019, 3:13 p.m. UTC
Add a generic helper to match a device by the acpi device.

Cc: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Cc: Mark Brown <broonie@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
 drivers/base/core.c    | 6 ++++++
 include/linux/device.h | 1 +
 2 files changed, 7 insertions(+)

Comments

Rafael J. Wysocki June 6, 2019, 9:17 a.m. UTC | #1
On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
> Add a generic helper to match a device by the acpi device.

"by its ACPI companion device object", please.

Also, it would be good to combine this patch with the patch(es) that
cause device_match_acpi_dev() to be actually used.

Helpers without any users are arguably not useful.

>
> Cc: Len Brown <lenb@kernel.org>
> Cc: linux-acpi@vger.kernel.org
> Cc: linux-spi@vger.kernel.org
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>  drivers/base/core.c    | 6 ++++++
>  include/linux/device.h | 1 +
>  2 files changed, 7 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index b827ca1..597095b 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -3346,3 +3346,9 @@ int device_match_devt(struct device *dev, const void *pdevt)
>         return dev->devt == *(dev_t *)pdevt;
>  }
>  EXPORT_SYMBOL_GPL(device_match_devt);
> +
> +int device_match_acpi_dev(struct device *dev, const void *adev)
> +{
> +       return ACPI_COMPANION(dev) == adev;
> +}
> +EXPORT_SYMBOL(device_match_acpi_dev);
> diff --git a/include/linux/device.h b/include/linux/device.h
> index f315692..a03b50d 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -166,6 +166,7 @@ void subsys_dev_iter_exit(struct subsys_dev_iter *iter);
>  int device_match_of_node(struct device *dev, const void *np);
>  int device_match_fwnode(struct device *dev, const void *fwnode);
>  int device_match_devt(struct device *dev, const void *pdevt);
> +int device_match_acpi_dev(struct device *dev, const void *adev);
>
>  int bus_for_each_dev(struct bus_type *bus, struct device *start, void *data,
>                      int (*fn)(struct device *dev, void *data));
> --
> 2.7.4
>
Suzuki K Poulose June 6, 2019, 9:28 a.m. UTC | #2
On 06/06/2019 10:17, Rafael J. Wysocki wrote:
> On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>
>> Add a generic helper to match a device by the acpi device.
> 
> "by its ACPI companion device object", please.

Sure.

> 
> Also, it would be good to combine this patch with the patch(es) that
> cause device_match_acpi_dev() to be actually used.
> 
> Helpers without any users are arguably not useful.

Sure, the helpers will be part of the part2 of the whole series,
which will actually have the individual subsystems consuming the
new helpers. For your reference, it is available here :

http://linux-arm.org/git?p=linux-skp.git;a=shortlog;h=refs/heads/driver-cleanup/v2

e.g: 
http://linux-arm.org/git?p=linux-skp.git;a=commit;h=59534e843e2f214f1f29659993f6e423bef16b28

I could simply pull those patches into this part, if you prefer that.
However, that would be true for the other patches in the part2.
I am open to suggestions, on how to split the series.

Cheers
Suzuki
Rafael J. Wysocki June 6, 2019, 9:57 a.m. UTC | #3
On Thu, Jun 6, 2019 at 11:28 AM Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
>
>
> On 06/06/2019 10:17, Rafael J. Wysocki wrote:
> > On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> >>
> >> Add a generic helper to match a device by the acpi device.
> >
> > "by its ACPI companion device object", please.
>
> Sure.
>
> >
> > Also, it would be good to combine this patch with the patch(es) that
> > cause device_match_acpi_dev() to be actually used.
> >
> > Helpers without any users are arguably not useful.
>
> Sure, the helpers will be part of the part2 of the whole series,
> which will actually have the individual subsystems consuming the
> new helpers. For your reference, it is available here :
>
> http://linux-arm.org/git?p=linux-skp.git;a=shortlog;h=refs/heads/driver-cleanup/v2
>
> e.g:
> http://linux-arm.org/git?p=linux-skp.git;a=commit;h=59534e843e2f214f1f29659993f6e423bef16b28
>
> I could simply pull those patches into this part, if you prefer that.

Not really.

I'd rather do it the other way around: push the introduction of the
helpers to part 2.

> However, that would be true for the other patches in the part2.
> I am open to suggestions, on how to split the series.

You can introduce each helper along with its users in one patch.

This way the total number of patches will be reduced and they will be
easier to review IMO.
Suzuki K Poulose June 12, 2019, 9:43 a.m. UTC | #4
Hi Rafael,

On 06/06/2019 10:57, Rafael J. Wysocki wrote:
> On Thu, Jun 6, 2019 at 11:28 AM Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>
>>
>>
>> On 06/06/2019 10:17, Rafael J. Wysocki wrote:
>>> On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>>>
>>>> Add a generic helper to match a device by the acpi device.
>>>
>>> "by its ACPI companion device object", please.
>>
>> Sure.
>>
>>>
>>> Also, it would be good to combine this patch with the patch(es) that
>>> cause device_match_acpi_dev() to be actually used.
>>>
>>> Helpers without any users are arguably not useful.
>>
>> Sure, the helpers will be part of the part2 of the whole series,
>> which will actually have the individual subsystems consuming the
>> new helpers. For your reference, it is available here :
>>
>> http://linux-arm.org/git?p=linux-skp.git;a=shortlog;h=refs/heads/driver-cleanup/v2
>>
>> e.g:
>> http://linux-arm.org/git?p=linux-skp.git;a=commit;h=59534e843e2f214f1f29659993f6e423bef16b28
>>
>> I could simply pull those patches into this part, if you prefer that.
> 
> Not really.
> 
> I'd rather do it the other way around: push the introduction of the
> helpers to part 2.

Sure, I will do that.

> 
>> However, that would be true for the other patches in the part2.
>> I am open to suggestions, on how to split the series.
> 
> You can introduce each helper along with its users in one patch.
> 
> This way the total number of patches will be reduced and they will be
> easier to review IMO.
> 

Wouldn't it make the merging complicated ? I am still not clear how we plan
to merge the part 2 ?

Cheers
Suzuki
Rafael J. Wysocki June 12, 2019, 10:07 p.m. UTC | #5
On Wednesday, June 12, 2019 11:43:38 AM CEST Suzuki K Poulose wrote:
> Hi Rafael,
> 
> On 06/06/2019 10:57, Rafael J. Wysocki wrote:
> > On Thu, Jun 6, 2019 at 11:28 AM Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> >>
> >>
> >>
> >> On 06/06/2019 10:17, Rafael J. Wysocki wrote:
> >>> On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> >>>>
> >>>> Add a generic helper to match a device by the acpi device.
> >>>
> >>> "by its ACPI companion device object", please.
> >>
> >> Sure.
> >>
> >>>
> >>> Also, it would be good to combine this patch with the patch(es) that
> >>> cause device_match_acpi_dev() to be actually used.
> >>>
> >>> Helpers without any users are arguably not useful.
> >>
> >> Sure, the helpers will be part of the part2 of the whole series,
> >> which will actually have the individual subsystems consuming the
> >> new helpers. For your reference, it is available here :
> >>
> >> http://linux-arm.org/git?p=linux-skp.git;a=shortlog;h=refs/heads/driver-cleanup/v2
> >>
> >> e.g:
> >> http://linux-arm.org/git?p=linux-skp.git;a=commit;h=59534e843e2f214f1f29659993f6e423bef16b28
> >>
> >> I could simply pull those patches into this part, if you prefer that.
> > 
> > Not really.
> > 
> > I'd rather do it the other way around: push the introduction of the
> > helpers to part 2.
> 
> Sure, I will do that.
> 
> > 
> >> However, that would be true for the other patches in the part2.
> >> I am open to suggestions, on how to split the series.
> > 
> > You can introduce each helper along with its users in one patch.
> > 
> > This way the total number of patches will be reduced and they will be
> > easier to review IMO.
> > 
> 
> Wouldn't it make the merging complicated ? I am still not clear how we plan
> to merge the part 2 ?

I wouldn't worry about it that much.  Without review, you have nothing to merge anyway.

Technically, every patch with a new helper and its users can go in via the Greg's tree
as long as it has been ACKed by the maintainers of the code touched by it.
diff mbox series

Patch

diff --git a/drivers/base/core.c b/drivers/base/core.c
index b827ca1..597095b 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3346,3 +3346,9 @@  int device_match_devt(struct device *dev, const void *pdevt)
 	return dev->devt == *(dev_t *)pdevt;
 }
 EXPORT_SYMBOL_GPL(device_match_devt);
+
+int device_match_acpi_dev(struct device *dev, const void *adev)
+{
+	return ACPI_COMPANION(dev) == adev;
+}
+EXPORT_SYMBOL(device_match_acpi_dev);
diff --git a/include/linux/device.h b/include/linux/device.h
index f315692..a03b50d 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -166,6 +166,7 @@  void subsys_dev_iter_exit(struct subsys_dev_iter *iter);
 int device_match_of_node(struct device *dev, const void *np);
 int device_match_fwnode(struct device *dev, const void *fwnode);
 int device_match_devt(struct device *dev, const void *pdevt);
+int device_match_acpi_dev(struct device *dev, const void *adev);
 
 int bus_for_each_dev(struct bus_type *bus, struct device *start, void *data,
 		     int (*fn)(struct device *dev, void *data));