On Thu, May 18, 2023 at 7:57 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > On 5/18/23 18:36, Andy Shevchenko wrote: > > On Thu, May 18, 2023 at 6:32 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: ... > >> + * Note this code uses the same DSM GUID as the INT3472 discrete.c code > >> + * and there is some overlap, but there are enough differences that it is > >> + * difficult to share the code. > > > > Can you add the name of the variable in that file, so likely the > > source code indexing tool might add a link? > > You mean change the comment something like this: > > * Note this code uses the same DSM GUID as the int3472_gpio_guid in > * the INT3472 discrete.c code and there is some overlap, but there are > * enough differences that it is difficult to share the code. > > I guess, where int3472_gpio_guid comes from: > > drivers/platform/x86/intel/int3472/discrete.c: > > static const guid_t int3472_gpio_guid = > GUID_INIT(0x79234640, 0x9e10, 0x4fea, > 0xa5, 0xc1, 0xb5, 0xaa, 0x8b, 0x19, 0x75, 0x6f); > > > ? Yes! ... > >> + devm_acpi_dev_add_driver_gpios(dev, data.map->mapping); > > > > Won't we print a warning here as well in case of error? > > The only way this can fail is with -ENOMEM (we already know dev > has an ACPI companion) and generally speaking the rule is to > not log errors for ENOMEM since when we hit that the kernel > already complains loudly before returning from the alloc call. But this is based on the information about internal implementation of the above mentioned API. Strictly speaking it might return, in the future, another error code as well. -- With Best Regards, Andy Shevchenko
