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

[Tarang Raval]

Hi Sakari, Kate.

> On Mon, Jul 06, 2026 at 09:05:08PM +0800, Kate Hsuan wrote:
> > 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 [] = {
>
> I'd call this "power_enable_hids_vana" as other bindings than Sony are also
> using vana regulator, e.g. ST and Toshiba.
>
> > "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.
>
> Feel free to write a patch. Looks like this series is fine for merging so
> I'll pick it later today.

Okay, I'll send a separate follow-up patch.

Best Regards,
Tarang