Created attachment 255329 [details] DMESG SoC: Intel Atom x5-Z8300 ================ BUG: (Not a regression) === [ 20.403162] ACPI Error: No handler for Region [XOPR] (ffff8eefb5cde318) [GenericSerialBus] (20160930/evregion-166) [ 20.403330] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20160930/exfldio-299) [ 20.403453] ACPI Error: Method parse/execution failed [\_SB.STR0._TMP] (Node ffff8eefb5d1f668), AE_NOT_EXIST (20160930/psparse-543) [ 20.403626] thermal thermal_zone1: failed to read out thermal zone (-5) OCCURANCE: Sporadic. (Doesn't occur on few boots) ========
Created attachment 255331 [details] DSDT
Created attachment 255333 [details] SSDT
please attach the full acpidump output
Created attachment 255357 [details] DSDT+SSDT[1-7] DSDT, SSDT1 - SSDT7
Created attachment 255359 [details] acpidump(ASCII HEX, not decompiled) If needed, Non-decompiled ACPIDUMP in ASCII HEX format
Created attachment 255361 [details] DMESG(without bug) This is the DMESG output from the instance without this bug. The difference seems to be that I2C7 bus which is managed by PUNIT is initialized before Intel thermal driver. Since thermal driver is itself reliant on I2C7 bus, this could be the case of improper module-loading order.
OK, I see. It seems in ACPI address space handler, we should be able to probe another driver. Let me think about it how this can work. Thanks for the report.
(In reply to Lv Zheng from comment #7) > OK, I see. > It seems in ACPI address space handler, we should be able to probe another > driver. > > Let me think about it how this can work. > Thanks for the report. XOPR is handled exclusively by IEC7 bus. I2C7 bus is controlled through cherrytrail PUNIT semaphore. Also INT3403, a DPTF thermal device is located on I2C7 bus. At the moment, 'int3403_thermal' module is loading ahead of 'intel-designware-platform' module causing the issue. I've altered the module load order and everything went smoothly. Thanks, Tagore
> At the moment, 'int3403_thermal' module is loading ahead of > 'intel-designware-platform' module causing the issue. I've altered the module > load order and everything went smoothly. This is a kind of way to fix it. Do we need to, for example, return -EPROBE_DEFER or invoke request_module() in case "No handler for Region" exception is caught by the Linux kernel via ACPICA exception handler.
I think so. This is the way GPIO space operation region does today.
We can not handle this problem as the way of GPIO. For the GPIO case, driver gets EPROBE_DEFER when requesting GPIO resource. But in this case, driver is evaluating an ACPI control method. the root cause of the problem is that _DEP is missing for STR0, as we can see _DEP for STR1 and STR2. Closed as this problem is caused by buggy firmware.
However, there are several workarounds for this problem 1. build ACPI battery driver as module and build in I2C driver. or 2. manually add _DEP for STR0 in ACPI table, and rebuilt the kernel with customized DSDT.
Let me re-open it. Possibly we can just return some significant error number for handler missing. When such a specific error gets seen by the caller, the caller can return EPROBE_DEFER (if it's really in the .probe call).
First of all, I'd say this is a FIRMWARE Bug, because everything will work well if _DEP is added for STR0, in ACPI table. Second, for the solution described in comment #13, technically, yes, but practically, probably no. We need to kick off the discussion to see if this is the right way to go. However, for this particular bug, I'd say it should be closed because of buggy firmware. If needed, I can attach a customized DSDT file for the bug reporter to workaround the problem.
By defining a bug as a firmware bug, we should validate if Windows is also misbehaving to such firmware.