Re: int3472: the vendor GPIO type table, and four values that differ

[Sergey Lebedev <lsa.uz@pm.me>]

Hans, thank you - your two anchors let me find the bug, and it was mine.

You wrote that 0x12 = HANDSHAKE came from Intel directly, and pointed at
dmanresa's independent mapping of 0x10 to AVDD. Neither fits the table I
sent, so I went back to the binary. The table I posted is short by two
entries.

My first pass ran strings(1) with a minimum length of three, which
silently dropped every name shorter than that. Two were dropped, both
sitting between PrivateLED and Avdd:

  0001f370: 4544 0000 4146 0000 494f 0000 4176 6464   ED..AF..IO..Avdd
                      ^^^^        ^^^^
                      0x0e AF     0x0f IO

Everything above 0x0d was therefore reported two slots low. Corrected,
the table runs 0x00..0x15:

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

Every disagreement I reported disappears:

  value   int3472.h        vendor, corrected
  0x01    POWERDOWN        Enable          - same pin, as you explained
  0x10    DOVDD            Avdd
  0x12    HANDSHAKE        Handshake       - agrees
  0x13    HOTPLUG_DETECT   HDMI_INT_IO     - agrees, same function

So the answer to the question I asked is that the kernel was right at
every disputed value and my table was wrong. Sorry for the noise.

One thing survives, and it is the reason I am writing rather than just
withdrawing. You said the 0x10 dovdd mapping was a guess - that you knew
it controlled a regulator, did not know which, and picked dovdd because
avdd was already taken by 0x0b. Intel's own table calls 0x10 Avdd. That
is a second, independent vote for dmanresa's reading, arrived at from a
different artifact.

It does not settle what 0x0b should be called. If 0x10 is avdd, then
0x0b - which the vendor calls PowerEn, and which the kernel calls
POWER_ENABLE, not a rail name at all - may never have needed a rail
name. Your point that drivers bulk-enable everything still decides
whether any of this is worth changing.

The indexing is still positional inference: nothing in the binary takes
the address of these strings, so I am reading an array of logging text
and assuming its order is the enum's order. What makes me believe it now
is that three values established independently of this binary - Intel's
0x12, dmanresa's 0x10, and the kernel's 0x13 - all land at once under a
single two-slot correction. That is a much better argument than the one
I made the first time.

Sergey Lebedev