int3472: GPIO type names disagree with Intel's Windows driver

int3472: GPIO type names disagree with Intel's Windows driver

[Alexander Patrakov]

Hi,

Disclosure: I used Claude Code for the table extraction, for the Windows
driver disassembly, and for drafting this email.

This is a report, not a patch. While I was getting the front camera of a
Lenovo Yoga Duet 7 13ITL6 to work, Claude Code found that Intel's Windows
control logic driver carries a table of names for the INT3472 _DSM GPIO
types. It names three types that matter for discrete-INT3472 designs, one
of which Linux already handles under a different name. I do not see a
clean way to turn that into a patch, so I would like to put the facts in
front of you and ask how you want them handled.

The table
---------

iactrllogic64.sys holds an array of 22 pointers to GPIO function names.
Index and name:

  0x00 Reset       0x08 Power1         0x10 Avdd
  0x01 Enable      0x09 Standby        0x11 Core
  0x02 Strobe      0x0a WriteProtect   0x12 Handshake
  0x03 Torch       0x0b PowerEn        0x13 HDMI_INT_IO
  0x04 Flash       0x0c Mclk           0x14 HDMIDetect
  0x05 LedRear     0x0d PrivateLED     0x15 Reserved
  0x06 LedFront    0x0e AF
  0x07 Power0      0x0f IO

Every type drivers/platform/x86/intel/int3472/discrete.c handles today
sits under a matching name at its own index: reset, strobe, power enable,
clock enable, privacy LED, handshake, hotplug detect. That is why I take
the index to be the _DSM type.

The same table is in two builds:

  DriverVer 08/23/2021,60.22000.0.11   shipped for the Yoga Duet 7 13ITL6
    sha256 28b0ce9cfabc2bd6b1cd11d3bfbffa792f0fab785dc52fcaf21b9f7e100982f8
  DriverVer 07/20/2023,63.22000.3.13186  shipped for the ThinkPad X1 Fold
    16 Gen 1, in Lenovo's camera package n3lce16w.exe
    sha256 fd1db239a9a48671f571080fb5d6c068c50f2196f807ef20cbe6fdbf12f40455

The Yoga driver came with the tablet.

The ThinkPad driver was downloaded from
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x1-fold-16-gen-1-type-21es-21et/downloads/driver-list/component?name=Camera%20and%20Card%20Reader&id=B7FF933A-6722-4635-9471-39DF68737A1D

How to reproduce
----------------

1. Lenovo's packages are Inno Setup installers that can be extracted on Linux:

     innoextract n3lce16w.exe
     # -> code$GetExtractPath$/x64/iactrllogic64.sys

2. The names are plain ASCII, stored one after another in this order.
   "AF" and "IO" are two characters long, so ask strings for short ones:

     strings -n 2 iactrllogic64.sys | grep -x -B13 -A8 PrivateLED

   (In the 2023 build "Reset" shows as "wZReset": two stray bytes sit
   directly in front of it.)

3. That the order is an index and not an accident of layout shows in the
   pointer array: 22 consecutive 64-bit pointers (image base 0x140000000)
   to those strings, at file offset 0x21060 in the 2021 build and 0x21c60
   in the 2023 build. The script at the end of this mail finds the array
   and prints it.

What this says about Linux
--------------------------

Read as rails, the three are:

  0x0f IO     digital I/O supply    (dovdd)
  0x10 Avdd   analog supply         (avdd)
  0x11 Core   digital core supply   (dvdd)

The Yoga Duet 7 has exactly these three behind its INT3472, next to a
reset and a privacy LED pin: 0x0f on pin 322, 0x10 on pin 321 and 0x11 on
pin 332. Linux handles 0x10 and warns about the other two, so the sensor
never gets all of its supplies.

Linux calls 0x10 DOVDD. That comes from commit 2a7b7652b1bb
("platform/x86: int3472: Handle GPIO type 0x10 (DOVDD)"), added for the
ThinkPad X1 Fold 16 Gen 1. Neither the commit nor its review says how the
meaning was established, and Intel's driver for that same machine has it
as Avdd. Leif, do you remember what it was based on, and which other GPIO
types that machine's INT3472 reports?

As far as I can tell the name has done no harm. Each such GPIO becomes a
regulator that supplies the sensor under the chosen name; sensor drivers
ask for all of their supplies and enable them together (ov5675 does a
regulator_bulk_enable() over avdd, dovdd and dvdd); and a supply that
nothing provides resolves to a dummy regulator on ACPI systems. So the
GPIO is switched at the same moment whichever of the three names it
carries. It would only matter to a driver that sequences its supplies or
does not ask for the name the GPIO was given.

Two more names look wrong against the table. Linux gives type 0x0b the
supply name avdd and type 0x12 the supply name dvdd. Intel calls them
PowerEn and Handshake, a general enable and a handshake signal, neither
of them tied to a rail; the names avdd and dvdd belong to 0x10 and 0x11.
I would treat those two as misnamed as well. They have worked for the
same reason as above.

Why I am not sending a patch
----------------------------

Giving 0x0f, 0x10 and 0x11 their proper names, while 0x0b and 0x12 keep
the ones they have, means two names end up on two types each:

  avdd   0x0b (PowerEn) and 0x10 (Avdd)
  dvdd   0x11 (Core) and 0x12 (Handshake)

A system whose INT3472 declares both members of a pair for one sensor
would ask for two regulators supplying the same name, and the second
regulator_register() fails with -EBUSY. No type shares a default name
with another in mainline today. I do not know whether such a system
exists; Intel's 2021 build handles Core and Handshake as separate steps,
so the firmware vocabulary at least allows it.

The ov5675 driver asks for avdd, dovdd and dvdd, and all three are
already the default names of 0x0b, 0x10 and 0x12. So I see no way to add
0x0f and 0x11 as general types without reusing a name, whatever is done
about 0x10.

For the Lenovo Yoga Duet 7 13ITL6 tablet the three GPIOs do power the
sensor with a local copy of the driver that maps 0x0f and 0x11 to the two
names 0x10 does not use, for this model only. The sensor is an OVTI5678,
the RGB-IR variant of the OV5675 that Sahan's Dell Latitude 7320
Detachable series is about:

  https://lore.kernel.org/linux-media/20260809042540.15849-1-adee.sahan@gmail.com/

Its sensor-side patches are on hold over the ability to describe the 4x4
RGB-IR sensor pattern, so there is no in-tree user for these types yet
either.

Windows driver logic
--------------------

Claude Code says the following about what the Windows driver does with
these types, and I have not verified it. It comes from reading a
disassembly (objdump -d -M intel iactrllogic64.sys) of the power-on
routine, which can be found through its trace string,
"discrete::DiscreteControl::SensorOn".

  2023 build (X1 Fold): switches Enable, Power0, Power1, PowerEn and
  Avdd (0x10) in that order, then handles the handshake, Reset and Mclk,
  with waits of 2 to 5 ms between steps. It does not touch 0x0e, 0x0f or
  0x11 anywhere.

  2021 build (Yoga Duet 7): switches Mclk and Reset, then Avdd (0x10),
  Core (0x11), IO (0x0f) and AF (0x0e) back to back, waits 2 ms, then
  Reset again and Handshake. The power-off routine switches the same
  four off together.

If that is right, both builds treat 0x10 as a supply and the older one
treats 0x0f and 0x11 the same way.

Question
--------

How should this proceed, given the misnamed GPIO types in Linux and the
name conflicts that would follow from attempts to fix them?

Thanks,
Alexander Patrakov

---- int3472-gpio-names.py ----
#!/usr/bin/env python3
"""Print the GPIO function name table of Intel's iactrllogic64.sys.

    int3472-gpio-names.py iactrllogic64.sys

The driver has an array of pointers to short names ("Reset", "Enable", ...).
This finds the array by looking for a pointer to "Reset" followed by a pointer
to "Enable", and prints every name with its index.
"""
import struct, sys

d = open(sys.argv[1], 'rb').read()
pe = struct.unpack_from('<I', d, 0x3c)[0]
nsec, optsize = struct.unpack_from('<H', d, pe + 6)[0],
struct.unpack_from('<H', d, pe + 20)[0]
base = struct.unpack_from('<Q', d, pe + 24 + 24)[0]            #
ImageBase of a PE32+ file
secs = [struct.unpack_from('<IIII', d, pe + 24 + optsize + 40 * i + 8)
for i in range(nsec)]

def name_at(va):
    """The string a virtual address points to, if it is a short
printable one."""
    for vsize, rva, rawsize, raw in secs:
        if base + rva <= va < base + rva + max(vsize, rawsize):
            off = raw + va - base - rva
            end = d.find(b'\0', off)
            s = d[off:end]
            return s.decode() if 1 < len(s) < 24 and all(32 <= c < 127
for c in s) else None

for off in range(0, len(d) - 16, 8):
    if name_at(struct.unpack_from('<Q', d, off)[0]) == 'Reset' and \
       name_at(struct.unpack_from('<Q', d, off + 8)[0]) == 'Enable':
        print('pointer table at file offset 0x%x' % off)
        i = 0
        while (n := name_at(struct.unpack_from('<Q', d, off + 8 *
i)[0])) is not None:
            print('  0x%02x  %s' % (i, n))
            i += 1
        break
else:
    print('no table found')

Re: int3472: GPIO type names disagree with Intel's Windows driver

[Dan Scally]

Good morning Alexander

On 09/10/2026 04:06, Alexander Patrakov wrote:
> Hi,
> 
> Disclosure: I used Claude Code for the table extraction, for the Windows
> driver disassembly, and for drafting this email.
> 
> This is a report, not a patch. While I was getting the front camera of a
> Lenovo Yoga Duet 7 13ITL6 to work, Claude Code found that Intel's Windows
> control logic driver carries a table of names for the INT3472 _DSM GPIO
> types. It names three types that matter for discrete-INT3472 designs, one
> of which Linux already handles under a different name. I do not see a
> clean way to turn that into a patch, so I would like to put the facts in
> front of you and ask how you want them handled.
> 
> The table
> ---------
> 
> iactrllogic64.sys holds an array of 22 pointers to GPIO function names.
> Index and name:
> 
>    0x00 Reset       0x08 Power1         0x10 Avdd
>    0x01 Enable      0x09 Standby        0x11 Core
>    0x02 Strobe      0x0a WriteProtect   0x12 Handshake
>    0x03 Torch       0x0b PowerEn        0x13 HDMI_INT_IO
>    0x04 Flash       0x0c Mclk           0x14 HDMIDetect
>    0x05 LedRear     0x0d PrivateLED     0x15 Reserved
>    0x06 LedFront    0x0e AF
>    0x07 Power0      0x0f IO
> 
> Every type drivers/platform/x86/intel/int3472/discrete.c handles today
> sits under a matching name at its own index: reset, strobe, power enable,
> clock enable, privacy LED, handshake, hotplug detect. That is why I take
> the index to be the _DSM type.
> 
> The same table is in two builds:
> 
>    DriverVer 08/23/2021,60.22000.0.11   shipped for the Yoga Duet 7 13ITL6
>      sha256 28b0ce9cfabc2bd6b1cd11d3bfbffa792f0fab785dc52fcaf21b9f7e100982f8
>    DriverVer 07/20/2023,63.22000.3.13186  shipped for the ThinkPad X1 Fold
>      16 Gen 1, in Lenovo's camera package n3lce16w.exe
>      sha256 fd1db239a9a48671f571080fb5d6c068c50f2196f807ef20cbe6fdbf12f40455
> 
> The Yoga driver came with the tablet.
> 
> The ThinkPad driver was downloaded from
> https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x1-fold-16-gen-1-type-21es-21et/downloads/driver-list/component?name=Camera%20and%20Card%20Reader&id=B7FF933A-6722-4635-9471-39DF68737A1D
> 
> How to reproduce
> ----------------
> 
> 1. Lenovo's packages are Inno Setup installers that can be extracted on Linux:
> 
>       innoextract n3lce16w.exe
>       # -> code$GetExtractPath$/x64/iactrllogic64.sys
> 
> 2. The names are plain ASCII, stored one after another in this order.
>     "AF" and "IO" are two characters long, so ask strings for short ones:
> 
>       strings -n 2 iactrllogic64.sys | grep -x -B13 -A8 PrivateLED
> 
>     (In the 2023 build "Reset" shows as "wZReset": two stray bytes sit
>     directly in front of it.)
> 
> 3. That the order is an index and not an accident of layout shows in the
>     pointer array: 22 consecutive 64-bit pointers (image base 0x140000000)
>     to those strings, at file offset 0x21060 in the 2021 build and 0x21c60
>     in the 2023 build. The script at the end of this mail finds the array
>     and prints it.
> 
> What this says about Linux
> --------------------------
> 
> Read as rails, the three are:
> 
>    0x0f IO     digital I/O supply    (dovdd)
>    0x10 Avdd   analog supply         (avdd)
>    0x11 Core   digital core supply   (dvdd)
> 
> The Yoga Duet 7 has exactly these three behind its INT3472, next to a
> reset and a privacy LED pin: 0x0f on pin 322, 0x10 on pin 321 and 0x11 on
> pin 332. Linux handles 0x10 and warns about the other two, so the sensor
> never gets all of its supplies.
> 
> Linux calls 0x10 DOVDD. That comes from commit 2a7b7652b1bb
> ("platform/x86: int3472: Handle GPIO type 0x10 (DOVDD)"), added for the
> ThinkPad X1 Fold 16 Gen 1. Neither the commit nor its review says how the
> meaning was established, and Intel's driver for that same machine has it
> as Avdd. Leif, do you remember what it was based on, and which other GPIO
> types that machine's INT3472 reports?
> 
> As far as I can tell the name has done no harm. Each such GPIO becomes a
> regulator that supplies the sensor under the chosen name; sensor drivers
> ask for all of their supplies and enable them together (ov5675 does a
> regulator_bulk_enable() over avdd, dovdd and dvdd); and a supply that
> nothing provides resolves to a dummy regulator on ACPI systems. So the
> GPIO is switched at the same moment whichever of the three names it
> carries. It would only matter to a driver that sequences its supplies or
> does not ask for the name the GPIO was given.
> 
> Two more names look wrong against the table. Linux gives type 0x0b the
> supply name avdd and type 0x12 the supply name dvdd. Intel calls them
> PowerEn and Handshake, a general enable and a handshake signal, neither
> of them tied to a rail; the names avdd and dvdd belong to 0x10 and 0x11.
> I would treat those two as misnamed as well. They have worked for the
> same reason as above.

Indeed, much of the reverse-engineering here was a bit of best-effort. We were fairly sure those 
GPIO lines represented power and their drivers were looking for supplies with particular names, so 
those were the names we used without necessarily understanding which was which.
> 
> Why I am not sending a patch
> ----------------------------
> 
> Giving 0x0f, 0x10 and 0x11 their proper names, while 0x0b and 0x12 keep
> the ones they have, means two names end up on two types each:
> 
>    avdd   0x0b (PowerEn) and 0x10 (Avdd)
>    dvdd   0x11 (Core) and 0x12 (Handshake)
> 
> A system whose INT3472 declares both members of a pair for one sensor
> would ask for two regulators supplying the same name, and the second
> regulator_register() fails with -EBUSY. No type shares a default name
> with another in mainline today. I do not know whether such a system
> exists; Intel's 2021 build handles Core and Handshake as separate steps,
> so the firmware vocabulary at least allows it.
> 
> The ov5675 driver asks for avdd, dovdd and dvdd, and all three are
> already the default names of 0x0b, 0x10 and 0x12. So I see no way to add
> 0x0f and 0x11 as general types without reusing a name, whatever is done
> about 0x10.

Does the situation need amending? The handshake pin being modelled as a regulator named dvdd is a 
deliberate situation; see Hans' commit message in c5d0393272048 ("platform/x86: int3472: Add 
handshake pin support") for the explanation. I would think the same applies for PowerEnable (though 
I suppose it could also be legitimately modeled as a GPIO, but sensor driver handling of those is 
less consistent).

Is there some sensor case you're aware of that's not working because of this problem?

Thanks
Dan

> 
> For the Lenovo Yoga Duet 7 13ITL6 tablet the three GPIOs do power the
> sensor with a local copy of the driver that maps 0x0f and 0x11 to the two
> names 0x10 does not use, for this model only. The sensor is an OVTI5678,
> the RGB-IR variant of the OV5675 that Sahan's Dell Latitude 7320
> Detachable series is about:
> 
>    https://lore.kernel.org/linux-media/20260809042540.15849-1-adee.sahan@gmail.com/
> 
> Its sensor-side patches are on hold over the ability to describe the 4x4
> RGB-IR sensor pattern, so there is no in-tree user for these types yet
> either.
> 
> Windows driver logic
> --------------------
> 
> Claude Code says the following about what the Windows driver does with
> these types, and I have not verified it. It comes from reading a
> disassembly (objdump -d -M intel iactrllogic64.sys) of the power-on
> routine, which can be found through its trace string,
> "discrete::DiscreteControl::SensorOn".
> 
>    2023 build (X1 Fold): switches Enable, Power0, Power1, PowerEn and
>    Avdd (0x10) in that order, then handles the handshake, Reset and Mclk,
>    with waits of 2 to 5 ms between steps. It does not touch 0x0e, 0x0f or
>    0x11 anywhere.
> 
>    2021 build (Yoga Duet 7): switches Mclk and Reset, then Avdd (0x10),
>    Core (0x11), IO (0x0f) and AF (0x0e) back to back, waits 2 ms, then
>    Reset again and Handshake. The power-off routine switches the same
>    four off together.
> 
> If that is right, both builds treat 0x10 as a supply and the older one
> treats 0x0f and 0x11 the same way.
> 
> Question
> --------
> 
> How should this proceed, given the misnamed GPIO types in Linux and the
> name conflicts that would follow from attempts to fix them?
> 
> Thanks,
> Alexander Patrakov
> 
> ---- int3472-gpio-names.py ----
> #!/usr/bin/env python3
> """Print the GPIO function name table of Intel's iactrllogic64.sys.
> 
>      int3472-gpio-names.py iactrllogic64.sys
> 
> The driver has an array of pointers to short names ("Reset", "Enable", ...).
> This finds the array by looking for a pointer to "Reset" followed by a pointer
> to "Enable", and prints every name with its index.
> """
> import struct, sys
> 
> d = open(sys.argv[1], 'rb').read()
> pe = struct.unpack_from('<I', d, 0x3c)[0]
> nsec, optsize = struct.unpack_from('<H', d, pe + 6)[0],
> struct.unpack_from('<H', d, pe + 20)[0]
> base = struct.unpack_from('<Q', d, pe + 24 + 24)[0]            #
> ImageBase of a PE32+ file
> secs = [struct.unpack_from('<IIII', d, pe + 24 + optsize + 40 * i + 8)
> for i in range(nsec)]
> 
> def name_at(va):
>      """The string a virtual address points to, if it is a short
> printable one."""
>      for vsize, rva, rawsize, raw in secs:
>          if base + rva <= va < base + rva + max(vsize, rawsize):
>              off = raw + va - base - rva
>              end = d.find(b'\0', off)
>              s = d[off:end]
>              return s.decode() if 1 < len(s) < 24 and all(32 <= c < 127
> for c in s) else None
> 
> for off in range(0, len(d) - 16, 8):
>      if name_at(struct.unpack_from('<Q', d, off)[0]) == 'Reset' and \
>         name_at(struct.unpack_from('<Q', d, off + 8)[0]) == 'Enable':
>          print('pointer table at file offset 0x%x' % off)
>          i = 0
>          while (n := name_at(struct.unpack_from('<Q', d, off + 8 *
> i)[0])) is not None:
>              print('  0x%02x  %s' % (i, n))
>              i += 1
>          break
> else:
>      print('no table found')

Re: int3472: GPIO type names disagree with Intel's Windows driver

[Alexander Patrakov]

On Fri, Oct 9, 2026 at 6:03 PM Dan Scally <dan.scally@ideasonboard.com> wrote:
> On 09/10/2026 04:06, Alexander Patrakov wrote:
> > Hi,
> > Why I am not sending a patch
> > ----------------------------
> >
> > Giving 0x0f, 0x10 and 0x11 their proper names, while 0x0b and 0x12 keep
> > the ones they have, means two names end up on two types each:
> >
> >    avdd   0x0b (PowerEn) and 0x10 (Avdd)
> >    dvdd   0x11 (Core) and 0x12 (Handshake)
> >
> > A system whose INT3472 declares both members of a pair for one sensor
> > would ask for two regulators supplying the same name, and the second
> > regulator_register() fails with -EBUSY. No type shares a default name
> > with another in mainline today. I do not know whether such a system
> > exists; Intel's 2021 build handles Core and Handshake as separate steps,
> > so the firmware vocabulary at least allows it.
> >
> > The ov5675 driver asks for avdd, dovdd and dvdd, and all three are
> > already the default names of 0x0b, 0x10 and 0x12. So I see no way to add
> > 0x0f and 0x11 as general types without reusing a name, whatever is done
> > about 0x10.
>
> Does the situation need amending? The handshake pin being modelled as a regulator named dvdd is a
> deliberate situation; see Hans' commit message in c5d0393272048 ("platform/x86: int3472: Add
> handshake pin support") for the explanation. I would think the same applies for PowerEnable (though
> I suppose it could also be legitimately modeled as a GPIO, but sensor driver handling of those is
> less consistent).
>
> Is there some sensor case you're aware of that's not working because of this problem?


My sensor does not work without a patch that maps 0x0f and 0x11 to
something that the ov5675 driver tries to enable. The INT3472 of the
Lenovo Yoga Duet 7 13ITL6 declares types 0x0f, 0x10 and 0x11, plus a
reset and a privacy LED, and neither 0x0b nor 0x12. But I am reluctant to
send a patch that knowingly gives a GPIO type the wrong supply name, thus
spreading the mistake.

I have read c5d0393272048, and I accept that "dvdd" for the handshake pin
is a deliberate abstraction and not a claim about the pin. Type 0x10 is a
different case: its commit says the pin controls the DOVDD rail, the
constant is named INT3472_GPIO_TYPE_DOVDD, and Intel's table calls that
type Avdd. That one is a statement of fact, and it looks wrong.

Here is the whole story: Claude, initially, found that the driver
complains about the two unmapped GPIOs, matched that to the three
regulator supplies that the ov5675 driver requests (avdd, dovdd, dvdd),
and _arbitrarily_ assigned the two supply names that were still free to
the two complained-about types ("GPIO type 0x%02x unknown; the sensor may
not work\n"). At least it told me about the guess:

+ * There is no 0x0b (avdd) and no 0x12 (dvdd), and the sensor needs three
+ * rails, so 0x0f and 0x11 are taken to be the remaining two. Which of them
+ * is avdd and which dvdd is a guess; ov5675.c enables all three together,
+ * so the labels do not change behaviour.

Then I asked Claude to try harder to figure out which is which, and at
that point it found the table in the Windows driver. It then created a
patch with the mapping that follows the table, but added a DMI lookup to
int3472_get_con_id_and_polarity() that matches the tablet, so that it
could override the conflicting generic mapping of 0x10. I started
questioning everything, and finally got this:

---
Your clone is at v7.3-rc6. The commit is 2a7b7652b1bb, "platform/x86:
int3472: Handle GPIO type 0x10 (DOVDD)", by Leif Skunberg, February 2026.

The commit message asserts the meaning and gives no basis for it. It says
the Fold's _DSM returns type 0x10 for a pin "which controls the DOVDD
(digital I/O power) regulator enable", and nothing about how that was
determined. It does not list the machine's other pins.

Version 1 was a quirk for that one machine. It added an entry to the
per-device GPIO map. Hans de Goede asked for it to be handled as a new
generic type instead, and for the name "dovdd". So the generalisation to
every machine came from review, based on a single device.
---
...which links to
https://lkml.iu.edu/hypermail/linux/kernel/2602.1/02605.html

So, I tried to investigate the same Fold that served as the basis for the
initial "dovdd" type assignment to 0x10, and Claude found that the Fold's
own Windows driver package contradicts this assignment: its table names
type 0x10 "Avdd", the same as the table in the driver for my tablet.

I asked Claude to fix int3472 so that I can submit a patch without adding
further wrong statements about avdd/dvdd/dovdd, and it flagged the risk:

---
Renaming 0x10 to "avdd" breaks any machine whose firmware declares both
type 0x0b and type 0x10 for the same sensor. The driver already names
0x0b "avdd", and registering two regulators for one supply name fails,
taking the whole INT3472 probe with it.
---

That comes from reading the code; nobody has tested it on hardware. I am
not aware of any such machine, but that's only because I am not aware of
anything other than my Yoga tablet and the Fold.

Thanks,
Alexander Patrakov

Re: int3472: GPIO type names disagree with Intel's Windows driver

[Dan Scally]

Hi Alexander

On 09/10/2026 12:25, Alexander Patrakov wrote:
> On Fri, Oct 9, 2026 at 6:03 PM Dan Scally <dan.scally@ideasonboard.com> wrote:
>> On 09/10/2026 04:06, Alexander Patrakov wrote:
>>> Hi,
>>> Why I am not sending a patch
>>> ----------------------------
>>>
>>> Giving 0x0f, 0x10 and 0x11 their proper names, while 0x0b and 0x12 keep
>>> the ones they have, means two names end up on two types each:
>>>
>>>     avdd   0x0b (PowerEn) and 0x10 (Avdd)
>>>     dvdd   0x11 (Core) and 0x12 (Handshake)
>>>
>>> A system whose INT3472 declares both members of a pair for one sensor
>>> would ask for two regulators supplying the same name, and the second
>>> regulator_register() fails with -EBUSY. No type shares a default name
>>> with another in mainline today. I do not know whether such a system
>>> exists; Intel's 2021 build handles Core and Handshake as separate steps,
>>> so the firmware vocabulary at least allows it.
>>>
>>> The ov5675 driver asks for avdd, dovdd and dvdd, and all three are
>>> already the default names of 0x0b, 0x10 and 0x12. So I see no way to add
>>> 0x0f and 0x11 as general types without reusing a name, whatever is done
>>> about 0x10.
>>
>> Does the situation need amending? The handshake pin being modelled as a regulator named dvdd is a
>> deliberate situation; see Hans' commit message in c5d0393272048 ("platform/x86: int3472: Add
>> handshake pin support") for the explanation. I would think the same applies for PowerEnable (though
>> I suppose it could also be legitimately modeled as a GPIO, but sensor driver handling of those is
>> less consistent).
>>
>> Is there some sensor case you're aware of that's not working because of this problem?
> 
> 
> My sensor does not work without a patch that maps 0x0f and 0x11 to
> something that the ov5675 driver tries to enable.

Right, ok. This has always been done a little unsatisfactorily in retrospect. On a devicetree system 
the regulators would be declared against the sensor's node with names that the driver was known to 
expect, here we're fixing names (by passing REGULATOR_SUPPLY() entries in the regulator's init_data) 
in what is effectively the regulator's driver and hoping that they match up to the sensor driver's 
expectations.

I think that what probably needs to happen, really, is for skl_int3472_register_regulator() to look 
up its array of consumer_supplies (which maps sensor device name to regulator name) based on DMI 
matching just as int3472_tps68470_get_board_data() does for the TPS68470 IC version of the INT3472, 
and we can drop this idea of getting the con_id in int3472_get_con_id_and_polarity() entirely. 
Perhaps we could provide a fall-back to the current names in the event of no DMI matching...but 
really the goal ought to be to register the regulator with an array of consumer_supplies that mimic 
what the devicetree bindings declare as the supply names for the sensor. You could then add 0x0f and 
0x11 as new GPIO types that register a regulator without worrying about duplicated names.

Thanks
Dan

The INT3472 of the
> Lenovo Yoga Duet 7 13ITL6 declares types 0x0f, 0x10 and 0x11, plus a
> reset and a privacy LED, and neither 0x0b nor 0x12. But I am reluctant to
> send a patch that knowingly gives a GPIO type the wrong supply name, thus
> spreading the mistake.
> 
> I have read c5d0393272048, and I accept that "dvdd" for the handshake pin
> is a deliberate abstraction and not a claim about the pin. Type 0x10 is a
> different case: its commit says the pin controls the DOVDD rail, the
> constant is named INT3472_GPIO_TYPE_DOVDD, and Intel's table calls that
> type Avdd. That one is a statement of fact, and it looks wrong.
> 
> Here is the whole story: Claude, initially, found that the driver
> complains about the two unmapped GPIOs, matched that to the three
> regulator supplies that the ov5675 driver requests (avdd, dovdd, dvdd),
> and _arbitrarily_ assigned the two supply names that were still free to
> the two complained-about types ("GPIO type 0x%02x unknown; the sensor may
> not work\n"). At least it told me about the guess:
> 
> + * There is no 0x0b (avdd) and no 0x12 (dvdd), and the sensor needs three
> + * rails, so 0x0f and 0x11 are taken to be the remaining two. Which of them
> + * is avdd and which dvdd is a guess; ov5675.c enables all three together,
> + * so the labels do not change behaviour.
> 
> Then I asked Claude to try harder to figure out which is which, and at
> that point it found the table in the Windows driver. It then created a
> patch with the mapping that follows the table, but added a DMI lookup to
> int3472_get_con_id_and_polarity() that matches the tablet, so that it
> could override the conflicting generic mapping of 0x10. I started
> questioning everything, and finally got this:
> 
> ---
> Your clone is at v7.3-rc6. The commit is 2a7b7652b1bb, "platform/x86:
> int3472: Handle GPIO type 0x10 (DOVDD)", by Leif Skunberg, February 2026.
> 
> The commit message asserts the meaning and gives no basis for it. It says
> the Fold's _DSM returns type 0x10 for a pin "which controls the DOVDD
> (digital I/O power) regulator enable", and nothing about how that was
> determined. It does not list the machine's other pins.
> 
> Version 1 was a quirk for that one machine. It added an entry to the
> per-device GPIO map. Hans de Goede asked for it to be handled as a new
> generic type instead, and for the name "dovdd". So the generalisation to
> every machine came from review, based on a single device.
> ---
> ...which links to
> https://lkml.iu.edu/hypermail/linux/kernel/2602.1/02605.html
> 
> So, I tried to investigate the same Fold that served as the basis for the
> initial "dovdd" type assignment to 0x10, and Claude found that the Fold's
> own Windows driver package contradicts this assignment: its table names
> type 0x10 "Avdd", the same as the table in the driver for my tablet.
> 
> I asked Claude to fix int3472 so that I can submit a patch without adding
> further wrong statements about avdd/dvdd/dovdd, and it flagged the risk:
> 
> ---
> Renaming 0x10 to "avdd" breaks any machine whose firmware declares both
> type 0x0b and type 0x10 for the same sensor. The driver already names
> 0x0b "avdd", and registering two regulators for one supply name fails,
> taking the whole INT3472 probe with it.
> ---
> 
> That comes from reading the code; nobody has tested it on hardware. I am
> not aware of any such machine, but that's only because I am not aware of
> anything other than my Yoga tablet and the Fold.
> 
> Thanks,
> Alexander Patrakov

Re: int3472: GPIO type names disagree with Intel's Windows driver

[Sakari Ailus]

Hi Alexander, Dan,

On Fri, Oct 09, 2026 at 07:25:07PM +0800, Alexander Patrakov wrote:
> On Fri, Oct 9, 2026 at 6:03 PM Dan Scally <dan.scally@ideasonboard.com> wrote:
> > On 09/10/2026 04:06, Alexander Patrakov wrote:
> > > Hi,
> > > Why I am not sending a patch
> > > ----------------------------
> > >
> > > Giving 0x0f, 0x10 and 0x11 their proper names, while 0x0b and 0x12 keep
> > > the ones they have, means two names end up on two types each:
> > >
> > >    avdd   0x0b (PowerEn) and 0x10 (Avdd)
> > >    dvdd   0x11 (Core) and 0x12 (Handshake)
> > >
> > > A system whose INT3472 declares both members of a pair for one sensor
> > > would ask for two regulators supplying the same name, and the second
> > > regulator_register() fails with -EBUSY. No type shares a default name
> > > with another in mainline today. I do not know whether such a system
> > > exists; Intel's 2021 build handles Core and Handshake as separate steps,
> > > so the firmware vocabulary at least allows it.
> > >
> > > The ov5675 driver asks for avdd, dovdd and dvdd, and all three are
> > > already the default names of 0x0b, 0x10 and 0x12. So I see no way to add
> > > 0x0f and 0x11 as general types without reusing a name, whatever is done
> > > about 0x10.
> >
> > Does the situation need amending? The handshake pin being modelled as a regulator named dvdd is a
> > deliberate situation; see Hans' commit message in c5d0393272048 ("platform/x86: int3472: Add
> > handshake pin support") for the explanation. I would think the same applies for PowerEnable (though
> > I suppose it could also be legitimately modeled as a GPIO, but sensor driver handling of those is
> > less consistent).
> >
> > Is there some sensor case you're aware of that's not working because of this problem?
> 
> 
> My sensor does not work without a patch that maps 0x0f and 0x11 to
> something that the ov5675 driver tries to enable. The INT3472 of the
> Lenovo Yoga Duet 7 13ITL6 declares types 0x0f, 0x10 and 0x11, plus a
> reset and a privacy LED, and neither 0x0b nor 0x12. But I am reluctant to
> send a patch that knowingly gives a GPIO type the wrong supply name, thus
> spreading the mistake.

The GPIO naming in Windows drivers is also an abstraction while Linux
drivers typically use datasheet names of regulators, which are sensor
specific. The handshake GPIO shouldn't exist with the regulators so it
should be possible to map the rest independently of that. Changing the
default mapping would also be possible, in principle, but that'd still
require ensuring all sensor drivers still get the required regulators. I'm
not sure it's worth it.

-- 
Regards,

Sakari Ailus

Re: int3472: GPIO type names disagree with Intel's Windows driver

[diamondback]

On Saturday, October 10th, 2026 at 12:36 AM, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
 
> The GPIO naming in Windows drivers is also an abstraction while Linux
> drivers typically use datasheet names of regulators, which are sensor
> specific. The handshake GPIO shouldn't exist with the regulators so it
> should be possible to map the rest independently of that. Changing the
> default mapping would also be possible, in principle, but that'd still
> require ensuring all sensor drivers still get the required regulators. I'm
> not sure it's worth it.

Answering Alexander's question to me from the first mail:

On 09/10/2026 04:06, Alexander Patrakov wrote:
> Leif, do you remember what it was based on, and which other GPIO
> types that machine's INT3472 reports?

It was based on inference. My notes from February only say "likely
DOVDD": the ov5675 driver asks for avdd, dovdd and dvdd, 0x0b and 0x12
already had avdd and dvdd, so 0x10 got the remaining name. v1 already
called it DOVDD; Hans only asked me to drop the OVTI5675 quirk entry and
spell the con_id "dovdd" instead of "vio". In hindsight, my commit
message should not have stated it so concretely.

What the Fold declares (from _DSM and the BIOS pin fields):

  INT3472:00 (\_SB.PC00.DSC0), all sensor-on value 1:
    0x00  reset    pin 335
    0x0b  PowerEn  pin 140
    0x10  Avdd     pin 164
  INT3472:01 (\_SB.PC00.DSC1): no _CRS, zero pins.

No 0x0f, 0x11 or 0x12. And a correction: that INT3472 is not the
OV5675's. The OV5675's _DEP names only the IVSC device, it uses dummy
regulators for all three supplies, and the supply map shows both
regulators going to the IR sensor:

  INT3472:00-avdd -> i2c-SMO55F0:00.avdd
  INT3472:00-dovdd -> i2c-SMO55F0:00.dovdd

So 0x10 on the Fold is a VD55G0 pin, not an OV5675 one.

I can confirm the table from the same package (iactrllogic64.sys,
same sha256, 22 entries at 0x21c60, 0x10 = Avdd). The same names were
also posted on this list in September, so this is the third sighting.

Dan's suggestion makes sense to me, the Fold is a good test unit: it
declares 0x0b and 0x10 for the same sensor, so renaming 0x10 to avdd
across the board would make INT3472:00 fail to probe here (-EBUSY).
Happy to test whatever you send.

Leif

Re: int3472: GPIO type names disagree with Intel's Windows driver

[Hans de Goede]

Hi,

On 10-Oct-26 10:01, diamondback wrote:
> On Saturday, October 10th, 2026 at 12:36 AM, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
>  
>> The GPIO naming in Windows drivers is also an abstraction while Linux
>> drivers typically use datasheet names of regulators, which are sensor
>> specific. The handshake GPIO shouldn't exist with the regulators so it
>> should be possible to map the rest independently of that. Changing the
>> default mapping would also be possible, in principle, but that'd still
>> require ensuring all sensor drivers still get the required regulators. I'm
>> not sure it's worth it.
> 
> Answering Alexander's question to me from the first mail:
> 
> On 09/10/2026 04:06, Alexander Patrakov wrote:
>> Leif, do you remember what it was based on, and which other GPIO
>> types that machine's INT3472 reports?
> 
> It was based on inference. My notes from February only say "likely
> DOVDD": the ov5675 driver asks for avdd, dovdd and dvdd, 0x0b and 0x12
> already had avdd and dvdd, so 0x10 got the remaining name. v1 already
> called it DOVDD; Hans only asked me to drop the OVTI5675 quirk entry and
> spell the con_id "dovdd" instead of "vio". In hindsight, my commit
> message should not have stated it so concretely.
> 
> What the Fold declares (from _DSM and the BIOS pin fields):
> 
>   INT3472:00 (\_SB.PC00.DSC0), all sensor-on value 1:
>     0x00  reset    pin 335
>     0x0b  PowerEn  pin 140
>     0x10  Avdd     pin 164
>   INT3472:01 (\_SB.PC00.DSC1): no _CRS, zero pins.
> 
> No 0x0f, 0x11 or 0x12. And a correction: that INT3472 is not the
> OV5675's. The OV5675's _DEP names only the IVSC device, it uses dummy
> regulators for all three supplies, and the supply map shows both
> regulators going to the IR sensor:
> 
>   INT3472:00-avdd -> i2c-SMO55F0:00.avdd
>   INT3472:00-dovdd -> i2c-SMO55F0:00.dovdd
> 
> So 0x10 on the Fold is a VD55G0 pin, not an OV5675 one.

Thank you for providing this information.

> Dan's suggestion makes sense to me
I'm afraid that Dan's suggestion to:

"I think that what probably needs to happen, really, is for
skl_int3472_register_regulator() to look up its array of consumer_supplies (which
maps sensor device name to regulator name) based on DMI matching just as
int3472_tps68470_get_board_data() does for the TPS68470 IC version of the INT3472"

Is not going to scale we are seeing many many different laptop models using
the discrete INT3472 devices, so we really need a generic solution here and
so far the current code has been scaling reasonable well.

The fact that currently we have a conflict between 0x0b poweren -> avdd
and 0x10 Avdd -> dovdd is unfortunate. I would like to see 0x10 register
the avdd regulator as per the Windows table, but that might cause
breakage on some laptop models.

For now the only laptop + sensor which we've seen use 0xf and 0x11 (+ 0x10)
_DSM type GPIOs is Alexander's Lenovo Yoga Duet 7 13ITL6 with the OVTI5675
sensor. The other laptop, diamond back's ThinkPad X1 Fold 16 Gen 1, which
we know to use an OVTI5675 is behind a ivsc and does not claim any GPIOs at
all.

So for now I think it what should happen is:


1. An int3472 driver patch renaming INT3472_GPIO_TYPE_DOVDD to
INT3472_GPIO_TYPE_AVDD, while keeping this mapped to dovdd with a remark
that this is mapped to dovdd for historical reasons and cannot be easily
changed because this might break support for some laptops

+ 2 new defines for DOVDD / DVDD, resulting in (combined)

#define INT3472_GPIO_TYPE_DOVDD                                 0x0f
#define INT3472_GPIO_TYPE_AVDD					0x10
#define INT3472_GPIO_TYPE_DVDD					0x11

So this basically syncs our defines with what we've learned from
the Windows drivers, without changing any functionality.
   

2. A patch to add mappings for the new INT3472_GPIO_TYPE_DOVDD(0x0f) and
INT3472_GPIO_TYPE_DVDD(0x11) values to dovdd resp dvdd regulators.

This one just adds new mappings so should be safe to.


3. A patch adding an entry for the OVTI5675 to int3472_gpio_map[] to
actually map the new INT3472_GPIO_TYPE_AVDD (0x10) the avdd (on the
OVTI5675 only)

This might cause breakage if there is a laptop not on our radar
with a OVTI5675 sensor using 0x0b (power-enable) + 0x10 (avdd) gpio
types at the same time. But there is only one way to find that out
really.


4. A patch to change the mapping of the new INT3472_GPIO_TYPE_AVDD (0x10)
to actually be mapped to avdd and mapping INT3472_GPIO_TYPE_POWER_ENABLE
to dvdd instead of avdd + dropping the int3472_gpio_map[] added in
the 3th patch.

Yes this undoes patch 3, the idea being that we can easily revert patch 4
if necessary.

Note patch 4 can cause 2 types of problems:

1. A name-conflict in the registered regulators. This would be a real
problem and a reason to go with a revert.

2. Some sensor drivers for sensors using INT3472_GPIO_TYPE_POWER_ENABLE
GPIOs may only check for avdd and not dvdd (*), in that case we could
extend the regulator handling in the sensor driver instead of reverting
patch 4.

I hope any problems with patch 4 will be of the second category so
that we can keep it around and have straight forward mappings between
the defines and the regulator names.

Regards,

Hans



*) I'm pretty sure we likely have a few of those, bonus points for
checking all sensor drivers for sensors listed in
drivers/media/pci/intel/ipu-bridge.c and pro-actively adding "dvdd"
support if they only support "avdd" atm

Re: int3472: GPIO type names disagree with Intel's Windows driver

[Hans de Goede]

Hi,

On 12-Oct-26 18:10, Hans de Goede wrote:
> Hi,
> 
> On 10-Oct-26 10:01, diamondback wrote:
>> On Saturday, October 10th, 2026 at 12:36 AM, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
>>  
>>> The GPIO naming in Windows drivers is also an abstraction while Linux
>>> drivers typically use datasheet names of regulators, which are sensor
>>> specific. The handshake GPIO shouldn't exist with the regulators so it
>>> should be possible to map the rest independently of that. Changing the
>>> default mapping would also be possible, in principle, but that'd still
>>> require ensuring all sensor drivers still get the required regulators. I'm
>>> not sure it's worth it.
>>
>> Answering Alexander's question to me from the first mail:
>>
>> On 09/10/2026 04:06, Alexander Patrakov wrote:
>>> Leif, do you remember what it was based on, and which other GPIO
>>> types that machine's INT3472 reports?
>>
>> It was based on inference. My notes from February only say "likely
>> DOVDD": the ov5675 driver asks for avdd, dovdd and dvdd, 0x0b and 0x12
>> already had avdd and dvdd, so 0x10 got the remaining name. v1 already
>> called it DOVDD; Hans only asked me to drop the OVTI5675 quirk entry and
>> spell the con_id "dovdd" instead of "vio". In hindsight, my commit
>> message should not have stated it so concretely.
>>
>> What the Fold declares (from _DSM and the BIOS pin fields):
>>
>>   INT3472:00 (\_SB.PC00.DSC0), all sensor-on value 1:
>>     0x00  reset    pin 335
>>     0x0b  PowerEn  pin 140
>>     0x10  Avdd     pin 164
>>   INT3472:01 (\_SB.PC00.DSC1): no _CRS, zero pins.
>>
>> No 0x0f, 0x11 or 0x12. And a correction: that INT3472 is not the
>> OV5675's. The OV5675's _DEP names only the IVSC device, it uses dummy
>> regulators for all three supplies, and the supply map shows both
>> regulators going to the IR sensor:
>>
>>   INT3472:00-avdd -> i2c-SMO55F0:00.avdd
>>   INT3472:00-dovdd -> i2c-SMO55F0:00.dovdd
>>
>> So 0x10 on the Fold is a VD55G0 pin, not an OV5675 one.
> 
> Thank you for providing this information.
> 
>> Dan's suggestion makes sense to me
> I'm afraid that Dan's suggestion to:
> 
> "I think that what probably needs to happen, really, is for
> skl_int3472_register_regulator() to look up its array of consumer_supplies (which
> maps sensor device name to regulator name) based on DMI matching just as
> int3472_tps68470_get_board_data() does for the TPS68470 IC version of the INT3472"
> 
> Is not going to scale we are seeing many many different laptop models using
> the discrete INT3472 devices, so we really need a generic solution here and
> so far the current code has been scaling reasonable well.
> 
> The fact that currently we have a conflict between 0x0b poweren -> avdd
> and 0x10 Avdd -> dovdd is unfortunate. I would like to see 0x10 register
> the avdd regulator as per the Windows table, but that might cause
> breakage on some laptop models.
> 
> For now the only laptop + sensor which we've seen use 0xf and 0x11 (+ 0x10)
> _DSM type GPIOs is Alexander's Lenovo Yoga Duet 7 13ITL6 with the OVTI5675
> sensor. The other laptop, diamond back's ThinkPad X1 Fold 16 Gen 1, which
> we know to use an OVTI5675 is behind a ivsc and does not claim any GPIOs at
> all.
> 
> So for now I think it what should happen is:
> 
> 
> 1. An int3472 driver patch renaming INT3472_GPIO_TYPE_DOVDD to
> INT3472_GPIO_TYPE_AVDD, while keeping this mapped to dovdd with a remark
> that this is mapped to dovdd for historical reasons and cannot be easily
> changed because this might break support for some laptops
> 
> + 2 new defines for DOVDD / DVDD, resulting in (combined)
> 
> #define INT3472_GPIO_TYPE_DOVDD                                 0x0f
> #define INT3472_GPIO_TYPE_AVDD					0x10
> #define INT3472_GPIO_TYPE_DVDD					0x11
> 
> So this basically syncs our defines with what we've learned from
> the Windows drivers, without changing any functionality.
>    
> 
> 2. A patch to add mappings for the new INT3472_GPIO_TYPE_DOVDD(0x0f) and
> INT3472_GPIO_TYPE_DVDD(0x11) values to dovdd resp dvdd regulators.
> 
> This one just adds new mappings so should be safe to.
> 
> 
> 3. A patch adding an entry for the OVTI5675 to int3472_gpio_map[] to
> actually map the new INT3472_GPIO_TYPE_AVDD (0x10) the avdd (on the
> OVTI5675 only)
> 
> This might cause breakage if there is a laptop not on our radar
> with a OVTI5675 sensor using 0x0b (power-enable) + 0x10 (avdd) gpio
> types at the same time. But there is only one way to find that out
> really.
> 
> 
> 4. A patch to change the mapping of the new INT3472_GPIO_TYPE_AVDD (0x10)
> to actually be mapped to avdd and mapping INT3472_GPIO_TYPE_POWER_ENABLE
> to dvdd instead of avdd + dropping the int3472_gpio_map[] added in
> the 3th patch.
> > Yes this undoes patch 3, the idea being that we can easily revert patch 4
> if necessary.
> 
> Note patch 4 can cause 2 types of problems:
> 
> 1. A name-conflict in the registered regulators. This would be a real
> problem and a reason to go with a revert.

Thinking more about this I remembered that some HP laptops use
both power-enable + handshake, see e.g.:

https://bugzilla-attachments.redhat.com/attachment.cgi?id=2111237

Where 'INT3472:01' registers both an avdd + dvdd with the old code,
so mapping INT3472_GPIO_TYPE_POWER_ENABLE to dvdd is going to cause
a conflict here.

ATM we have (note new fixed INT3472_GPIO_TYPE_AVDD define):

0x0b INT3472_GPIO_TYPE_POWER_ENABLE -> avdd
0x10 INT3472_GPIO_TYPE_AVDD         -> dovdd
0x12 INT3472_GPIO_TYPE_HANDSHAKE    -> dvdd

So new proposal for patch 4, swap the 0x0b and 0x10 mappings
resulting in:

0x0b INT3472_GPIO_TYPE_POWER_ENABLE -> dovdd
0x10 INT3472_GPIO_TYPE_AVDD         -> avdd
0x12 INT3472_GPIO_TYPE_HANDSHAKE    -> dvdd

Note please also rename avdd_second_sensor to power_enable_second_sensor.

This avoids any regulator name conflicts for all the supported
existing combos, leaving only "2." below as potential problem
with the suggested patch 4:

> 2. Some sensor drivers for sensors using INT3472_GPIO_TYPE_POWER_ENABLE
> GPIOs may only check for avdd and not dvdd (*), in that case we could
> extend the regulator handling in the sensor driver instead of reverting
> patch 4.

And as mentioned we can fix those by extending the supply handling in
the sensor driver.

Ok, so I decided to really do my homework and just checked all
sensor drivers listed in ipu-bridge.c and present in 7.3 (some
or only available out of tree so far) and all of them either do
not support any of avdd, dvdd + dovdd, or they support all of them.

So I think that just swapping avdd and dovdd in the current setup
so as to correctly map 0x10 -> INT3472_GPIO_TYPE_AVDD -> "avdd"
is the right thing to do and that also means we can just squash
patches 3 and 4.

Since I think I've this all figured out now, let me just turn this into
a patch-set.

I'll Cc everyone on this email-thread on the patch-set.

Regards,

Hans