Please do not top post in the open source mailing lists. On Mon, Sep 24, 2018 at 5:50 PM Banik, Subrata <subrata.banik@xxxxxxxxx> wrote: > You are right that this ASL code is not same with Intel reference BIOS code because BIOS sources are different between what you are looking vs what Chrome OS is using. In Coreboot BIOS, we are more relying on EDS spec and as COM 3 is dedicated for CPU GPIO hence we are mapping, 0/1/2/4/5 (whatever present in EDS vol 1.1) But how would it possible to make interoperability work if there are *different* firmwares for the *same* ACPI HID? ACPI table is a part of protocol by which firmware sends data to the software. If one breaks this protocol they must use another ACPI HID for that kind of device. > We have ensured that PCR ID and offsets are correct in ASL code for respective community, I don't think anything else really matter from BIOS unless you tell me, that you are having any required that your drive code will only probe for 4 COMM for LP and 5 for ICL-H? See above. So, I do not see any bug in the driver, but in firmware. In this case FW may not use INT3455 HID. This is my understanding, if you would like more details, ask BIOS and ACPI teams. > First of all, this is pre-production chip, so, I don't think there is a bug in the driver (yet) discovered. > > Looking to the above ASL code I may conclude that is definitely is *not* from our reference BIOS. > I have checked two versions of it and found that in both we have the following mapping: > for LP variant: there are only 4 communities are exported for H variant: there are only 5 communities are exported > > So, I guess the problem is in ASL code you provided. It simple should not export that community at all. > > In case you need to do so, there are ways: > - contact Intel and ask for a change in reference BIOS > - acquire another ACPI ID for the case, or, perhaps use special constants like > _HRV for that purpose (also need to contact Intel while doing that) -- With Best Regards, Andy Shevchenko