| Message ID | 20230705213010.390849-16-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | media: ipu-bridge: Shared with atomisp, rework VCM instantiation | expand |
On Wed, Jul 05, 2023 at 11:30:07PM +0200, Hans de Goede wrote: > Some ACPI glue code (1) may want to do an acpi_device_id match while > it only has a struct acpi_device available because the first physical > node may not have been instantiated yet. > > Add a new acpi_match_acpi_device() helper for this, which takes > a "struct acpi_device *" as argument rather then the "struct device *" > which acpi_match_device() takes. > > 1) E.g. code which parses ACPI tables to transforms them > into more standard kernel data structures like fwnodes Looks like it's v1 of my original patch, anyway this is now in Linux Next as 2b5ae9604949 ("ACPI: bus: Introduce acpi_match_acpi_device() helper").
Hi, On 7/6/23 11:19, Andy Shevchenko wrote: > On Wed, Jul 05, 2023 at 11:30:07PM +0200, Hans de Goede wrote: >> Some ACPI glue code (1) may want to do an acpi_device_id match while >> it only has a struct acpi_device available because the first physical >> node may not have been instantiated yet. >> >> Add a new acpi_match_acpi_device() helper for this, which takes >> a "struct acpi_device *" as argument rather then the "struct device *" >> which acpi_match_device() takes. >> >> 1) E.g. code which parses ACPI tables to transforms them >> into more standard kernel data structures like fwnodes > > Looks like it's v1 of my original patch, anyway this is now in Linux Next as > 2b5ae9604949 ("ACPI: bus: Introduce acpi_match_acpi_device() helper"). Ah interesting, it does indeed look a lot like your version. but it was developed independently. Unfortunately it seems that this is headed for 6.6-rc1 and the atomisp changes in this series which rely on this are intended for 6.6-rc1 too. So we still need to figure out how to merge this. Regards, Hans
On Thu, Jul 06, 2023 at 02:29:35PM +0200, Hans de Goede wrote: > On 7/6/23 11:19, Andy Shevchenko wrote: > > On Wed, Jul 05, 2023 at 11:30:07PM +0200, Hans de Goede wrote: ... > > Looks like it's v1 of my original patch, anyway this is now in Linux Next as > > 2b5ae9604949 ("ACPI: bus: Introduce acpi_match_acpi_device() helper"). > > Ah interesting, it does indeed look a lot like your version. > but it was developed independently. Very interesting! It's a second patch of me that collides with someone's else work. > Unfortunately it seems that this is headed for 6.6-rc1 and the atomisp > changes in this series which rely on this are intended for 6.6-rc1 too. > > So we still need to figure out how to merge this. Standard way? I.e. ask Rafael for immutable tag/branch?
On Thu, Jul 6, 2023 at 2:29 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 7/6/23 11:19, Andy Shevchenko wrote: > > On Wed, Jul 05, 2023 at 11:30:07PM +0200, Hans de Goede wrote: > >> Some ACPI glue code (1) may want to do an acpi_device_id match while > >> it only has a struct acpi_device available because the first physical > >> node may not have been instantiated yet. > >> > >> Add a new acpi_match_acpi_device() helper for this, which takes > >> a "struct acpi_device *" as argument rather then the "struct device *" > >> which acpi_match_device() takes. > >> > >> 1) E.g. code which parses ACPI tables to transforms them > >> into more standard kernel data structures like fwnodes > > > > Looks like it's v1 of my original patch, anyway this is now in Linux Next as > > 2b5ae9604949 ("ACPI: bus: Introduce acpi_match_acpi_device() helper"). > > Ah interesting, it does indeed look a lot like your version. > but it was developed independently. > > Unfortunately it seems that this is headed for 6.6-rc1 and the atomisp > changes in this series which rely on this are intended for 6.6-rc1 too. No, the material Andy is talking about will be pushed for 6.5-rc1 (probably even today), because it is part of a fix for systems that are broken in the field. > So we still need to figure out how to merge this. This shouldn't be a problem.
Hi, On 7/6/23 15:26, Rafael J. Wysocki wrote: > On Thu, Jul 6, 2023 at 2:29 PM Hans de Goede <hdegoede@redhat.com> wrote: >> >> Hi, >> >> On 7/6/23 11:19, Andy Shevchenko wrote: >>> On Wed, Jul 05, 2023 at 11:30:07PM +0200, Hans de Goede wrote: >>>> Some ACPI glue code (1) may want to do an acpi_device_id match while >>>> it only has a struct acpi_device available because the first physical >>>> node may not have been instantiated yet. >>>> >>>> Add a new acpi_match_acpi_device() helper for this, which takes >>>> a "struct acpi_device *" as argument rather then the "struct device *" >>>> which acpi_match_device() takes. >>>> >>>> 1) E.g. code which parses ACPI tables to transforms them >>>> into more standard kernel data structures like fwnodes >>> >>> Looks like it's v1 of my original patch, anyway this is now in Linux Next as >>> 2b5ae9604949 ("ACPI: bus: Introduce acpi_match_acpi_device() helper"). >> >> Ah interesting, it does indeed look a lot like your version. >> but it was developed independently. >> >> Unfortunately it seems that this is headed for 6.6-rc1 and the atomisp >> changes in this series which rely on this are intended for 6.6-rc1 too. > > No, the material Andy is talking about will be pushed for 6.5-rc1 > (probably even today), because it is part of a fix for systems that > are broken in the field. > >> So we still need to figure out how to merge this. > > This shouldn't be a problem. Great, thank you. Regards, Hans
On Thu, Jul 06, 2023 at 03:26:20PM +0200, Rafael J. Wysocki wrote: > On Thu, Jul 6, 2023 at 2:29 PM Hans de Goede <hdegoede@redhat.com> wrote: > > On 7/6/23 11:19, Andy Shevchenko wrote: > > > On Wed, Jul 05, 2023 at 11:30:07PM +0200, Hans de Goede wrote: ... > > > Looks like it's v1 of my original patch, anyway this is now in Linux Next as > > > 2b5ae9604949 ("ACPI: bus: Introduce acpi_match_acpi_device() helper"). > > > > Ah interesting, it does indeed look a lot like your version. > > but it was developed independently. > > > > Unfortunately it seems that this is headed for 6.6-rc1 and the atomisp > > changes in this series which rely on this are intended for 6.6-rc1 too. > > No, the material Andy is talking about will be pushed for 6.5-rc1 > (probably even today), because it is part of a fix for systems that > are broken in the field. Oh, totally forgot about that. > > So we still need to figure out how to merge this. > > This shouldn't be a problem. True, and thank you!
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index d161ff707de4..de75ad675f92 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -888,6 +888,23 @@ static bool __acpi_match_device(struct acpi_device *device, return true; } +/** + * acpi_match_acpi_device - Match a struct acpi_device against a given list of ACPI IDs + * @ids: Array of struct acpi_device_id object to match against. + * @adev: The acpi_device structure to match. + * + * Return a pointer to the first matching ID on success or %NULL on failure. + */ +const struct acpi_device_id *acpi_match_acpi_device(const struct acpi_device_id *ids, + struct acpi_device *adev) +{ + const struct acpi_device_id *id = NULL; + + __acpi_match_device(adev, ids, NULL, &id, NULL); + return id; +} +EXPORT_SYMBOL_GPL(acpi_match_acpi_device); + /** * acpi_match_device - Match a struct device against a given list of ACPI IDs * @ids: Array of struct acpi_device_id object to match against. @@ -902,10 +919,7 @@ static bool __acpi_match_device(struct acpi_device *device, const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids, const struct device *dev) { - const struct acpi_device_id *id = NULL; - - __acpi_match_device(acpi_companion_match(dev), ids, NULL, &id, NULL); - return id; + return acpi_match_acpi_device(ids, acpi_companion_match(dev)); } EXPORT_SYMBOL_GPL(acpi_match_device); diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h index c941d99162c0..db854e78b2f8 100644 --- a/include/acpi/acpi_bus.h +++ b/include/acpi/acpi_bus.h @@ -561,6 +561,8 @@ void acpi_bus_trim(struct acpi_device *start); acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle * ejd); int acpi_match_device_ids(struct acpi_device *device, const struct acpi_device_id *ids); +const struct acpi_device_id *acpi_match_acpi_device(const struct acpi_device_id *ids, + struct acpi_device *adev); void acpi_set_modalias(struct acpi_device *adev, const char *default_id, char *modalias, size_t len); int acpi_create_dir(struct acpi_device *);
Some ACPI glue code (1) may want to do an acpi_device_id match while it only has a struct acpi_device available because the first physical node may not have been instantiated yet. Add a new acpi_match_acpi_device() helper for this, which takes a "struct acpi_device *" as argument rather then the "struct device *" which acpi_match_device() takes. 1) E.g. code which parses ACPI tables to transforms them into more standard kernel data structures like fwnodes Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/acpi/bus.c | 22 ++++++++++++++++++---- include/acpi/acpi_bus.h | 2 ++ 2 files changed, 20 insertions(+), 4 deletions(-)