On Tue, 2021-05-25 at 20:11 +0300, Andy Shevchenko wrote:

On Mon, May 24, 2021 at 7:30 PM Andy Shevchenko
[off-list ref] wrote:

quoted

On Mon, May 24, 2021 at 6:03 PM Sander Vanheule [off-list ref]
wrote:

quoted

On Mon, 2021-05-24 at 15:54 +0300, Andy Shevchenko wrote:

...

quoted

quoted

Sadly, I don't. Most of the info we have comes from code archives of
switch
vendors (Zyxel, Cisco etc). Boards need to be reverse engineered, and the
few
leaked datasheets that can be found on the internet aren't exactly thick
in
information.

The RTL8231 datasheet is actually quite useful, but makes no mention of
the
output value isse. Since this isn't an official resource, I don't think it
would
be appropriate to link it via a Datasheet: tag.
https://github.com/libc0607/Realtek_switch_hacking/blob/files/RTL8231_Datasheet_
1.2.pdf

Looking at the datasheet again, I came up with a... terrible hack to work
around
the output value issue.

The chip also has GPIO_INVERT registers that I hadn't used until now,
because
the logical inversion is handled in the kernel. However, these inversion
registers only apply to the output values. So, I could implement glitch-
free
output behaviour in the following way:
 * After chip reset, and before enabling the output driver (MFD
initialisation):
    - Mux all pins as GPIO
    - Change all pins to outputs,

No. no, no. This is much worse than the glitches. You never know what
the hardware is connected there and it's potential breakage (on hw
level) possible.

quoted

 so the data registers (0x1c-0x1e) become writable
    - Write value 0 to all pins
    - Change all pins to GPI to change them into high-Z
 * In the pinctrl/gpio driver:
    - Use data registers as input-only
    - Use inversion register to determine output value (can be written any
time)

The above gives glitch-free outputs, but the values that are read back
(when
configured as output), come from the data registers. They should now be
coming
from the inversion (reg_set_base) registers, but the code prefers to use
the
data registers (reg_dat_base).

Lemme read the datasheet and see if I find any clue for the hw behaviour.

Thank you for your patience!

Have you explored the possibility of using En_Sync_GPIO?

I haven't (output latching doesn't really appear to be a thing in the gpio
framework?), but I did notice that the main SoC's RTL8231 integration uses it.

Let me play around with it to see if it also latches the pin direction, or if
that's always an immediate change.


Best,
Sander