Hi Andy,
On Fri, Jan 31, 2025 at 07:18:54PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 31, 2025 at 02:01:51PM +0200, Sakari Ailus wrote:
> > The DT bindings for ov7251 specify "enable" GPIO (xshutdown in
> > documentation) but the int3472 indiscriminately provides this as a "reset"
> > GPIO to sensor drivers. Take this into account by assigning it as "enable"
> > with active high polarity for INT347E devices, i.e. ov7251. "reset" with
> > active low polarity remains the default GPIO name for other devices.
>
> ...
>
> > +static void int3472_get_func_and_polarity(struct acpi_device *adev, u8 *type,
> > + const char **func, unsigned long *gpio_flags)
> > {
> > - switch (type) {
> > + unsigned int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(int3472_gpio_map); i++) {
> > + if (*type != int3472_gpio_map[i].type_from)
> > + continue;
>
> > + if (!acpi_dev_hid_uid_match(adev, int3472_gpio_map[i].hid, NULL))
> > + continue;
>
> Hmm... But why? It's more natural to test if the device even present before
> continue to check the details of the quirk. This order looks suspicious
