Re: [PATCH 4.19 16/50] gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist

[Hans de Goede]

Hi,

On 9/19/19 9:46 AM, Pavel Machek wrote:
> On Wed 2019-09-18 08:18:59, Greg Kroah-Hartman wrote:
> > From: Hans de Goede <hdegoede@xxxxxxxxxx>
> >
> > commit 61f7f7c8f978b1c0d80e43c83b7d110ca0496eb4 upstream.
> >
> > Another day; another DSDT bug we need to workaround...
> >
> > Since commit ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events
> > at least once on boot") we call _AEI edge handlers at boot.
> >
> > In some rare cases this causes problems. One example of this is the Minix
> > Neo Z83-4 mini PC, this device has a clear DSDT bug where it has some copy
> > and pasted code for dealing with Micro USB-B connector host/device role
> > switching, while the mini PC does not even have a micro-USB connector.
> > This code, which should not be there, messes with the DDC data pin from
> > the HDMI connector (switching it to GPIO mode) breaking HDMI support.
> >
> > To avoid problems like this, this commit adds a new
> > gpiolib_acpi.run_edge_events_on_boot kernel commandline option, which
> > allows disabling the running of _AEI edge event handlers at boot.
>
> So... apparently Windows does _not_ run _AEI edge event handlers at
> boot, otherwise Minix would realize that fault.

Right, also came the conclusion that Windows likely does not run
_AEI edge event handlers at boot.

> Would it make sense not to do it by default, either?

Well as the commit-msg for the commit which originally added this
explains, there are at least 2 reasons to run them at boot:

1) This is necessary on at least some ms surface devices to get
the initial LID state correct, otherwise the LID will be report
being closed until the first time it is actually closed +
opened again. Now this case we can probably quirk ourselves
out of in some way.

2) The other case is Cherry Trail based tablets. The hw on these
can typically do both USB device and host mode on the tablets
micro-b or type-c connector. This involves a mux which switches
the data lines between the host and device controllers inside the
Cherry Trail SoC. This mux is controlled by an edge-triggered ACPI
eventhandler connected to the ID pin of the micro-b connector.

OOTB Windows only supports host mode, I guess there might be some
way to get device mode to work under Windows but tablet manufacturers
do not seem to care about this.

By default many UEFI firmwares put the mux in host mode during boot,
independent of the actual ID pin value since they only care about host
mode and want to support e.g. booting from USB or an external kbd.

By default the ID pin on the micro-b connector is high (pulled up)
an actual micro-b to host(A-female) cable pulls the ID-pin to gnd,
a USB-A to micro-B cable such as used to connect the tablet to a PC
leaves the ID pin floating (pulled high).

So without a host adapter inserted, we boot with the mux in host
mode, and the ID pin high. Now if the user connects the tablet to
a PC (or it was connected at boot) the ID pin does not change,
the mux is not change and device mode does not work since the
mux is set wrong. The only way to fix this is to force the ID
pin to change, so that would mean inserting a host-adapter, removing
it again and then connecting the tablet to a PC.

Running the _AEI handler at boot correctly puts the mux in
device position fixing this. Almost all Cherry Trall devices
suffer from this, makig it impossible to quirk our way out of this.

Now arguably we could limit the running of _AEI handlers at boot
to Cherry Trail, I would not object to that, but the
Minix Neo Z83-4 mini PC is a Cherry Trail device itself, as
mentioned in the commit msg, the  troublesome _AEI handler on this
device is the same ID pin handler which we want to run boot on all
Cherry Trail tablets. In this mini-pc case it is wrong though since
the mini-pc does not even have a micro-b connector.

I hope this explains.

Regards,

Hans