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
