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

[Sakari Ailus <sakari.ailus@linux.intel.com>]

Hi 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@siliconsignals.io> 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.

> 
> Thank you :)

Thank you for the series!

-- 
Kind regards,

Sakari Ailus