Re: [PATCH v6 3/4] platform: int3472: discrete: con_id vana for Sony IMX471 as power enable

[Kate Hsuan]

Hi Hans, Sakari and Tarang,

Thank you for your comments.

On Mon, Jul 6, 2026 at 3:16 PM Tarang Raval
<tarang.raval@xxxxxxxxxxxxxxxxx> wrote:
>
> Hi Sakari,
>
> > On Thu, Jul 02, 2026 at 08:05:25PM +0200, Hans de Goede wrote:
> > > > I went through the INT3472 driver and would like to propose a generic
> > > > approach that satisfies both sides without per-HID quirks or sensor driver
> > > > changes.
> > > >
> > > > The problem is:
> > > >  - INT3472 standardizes on "avdd" internally
> > > >  - Sony IMX sensor drivers use "vana" per datasheet, and all existing
> > > >    Sony DT bindings (imx219, imx290, imx415) already use vana-supply
> > > >  - Changing imx471 to "avdd" now will create inconsistency with those
> > > >    bindings, or require a rename later
> > >
> > > Ack, as mentioned in my reply to Sakari from 1 minute ago I'm ok
> > > with sticking with vana for the imx* case,
> >
> > At least some Sony sensors use "INT" PnP vendor prefix and so telling them
> > apart from the rest doesn't work at least this way. There could also be
> > other prefixes as well, they're not all "SONY". Right now there is one with
> > INT prefix and three with SONY prefix.
> >
> > If we start having lots of devices with the same quirk, we could also
> > introduce a pointer to an array of IDs to avoid repeating the same quirk
> > over and over.
> >
> > Kate's patch adds two quirks so this could be already considered (and only
> > one of these IDs is using SONY prefix).

The idea may look like

const char *sony_hids [] = {
"SONY471A",
"TBE20A0,
NULL
};

 { /* imx471 expects "vana" as con_id for power enable */
     .hid = sony_hids,   <--- A ponter to sony_hids
     .type_from = INT3472_GPIO_TYPE_POWER_ENABLE,
     .type_to = INT3472_GPIO_TYPE_POWER_ENABLE,
     .con_id = "vana",
     .enable_time_us = GPIO_REGULATOR_ENABLE_TIME,
 },

and
and the following functions need to be changed.
Do I understand it correctly?

Sakari, do you want to implement this approach or could Tarang and I do that?

>
> The HID prefix is not actually a concern for the alias idea, because the
> alias table triggers on supply_name not on HID. Since INT3472 always
> assigns "avdd" to any POWER_ENABLE GPIO regardless of HID prefix, the
> alias would work the same for SONY471A, TBE20A0 or any future INTXXXXX
> prefix.
>
> However there is a different problem with the alias idea: it would register
> both avdd and vana for every sensor that has a POWER_ENABLE GPIO, not just
> Sony IMX sensors. So I agree this is not a good approach.
>
> The NULL-terminated HID array is the correct approach, the mapping is
> explicit and only applied to hid we explicitly list.
>
> I can send a patch implementing this on top of Kate's patch.
Sounds good.
If Sakari agree with that, I can include your patch in my series.

Thank you :)
>
> Best Regards,
> Tarang
>


-- 
BR,
Kate