Hi Paul,
Thanks for filing the bug for me.
Yes, I found out how. It is reflected in my WIP patch now.
Hi Tim,
iasl is even stricter with EISAID - it exactly requires the format SMB0001, so doing what you said still throws an error.
I had to upgrade the kernel from 4.4.14 to 5.4.42 for the i2c-scmi driver to catch on. Then I was getting a shitload of invalid parameter errors which eventually boils down to _SBW being expected to return a package of one integer, instead of just an integer. Oops. I fixed that, but somehow it's still not showing my devices. Gotta try harder.
Thanks Keith
---------- Forwarded message ---------- From: Tim Wawrzynczak twawrzynczak@google.com To: Paul Menzel pmenzel@molgen.mpg.de Cc: coreboot@coreboot.org Bcc: Date: Tue, 26 May 2020 16:59:31 -0600 Subject: [coreboot] Re: Please solve this ACPI dilemma Hi Keith,
Many ACPI devices use an EISAID for their _HID, and I believe that Linux's ACPICPA converts an EISAID to a string for _HID matching. You could try something like this instead (you can see in the Linux sources there are 3 ACPI _HID matches, and this is one of them). `Name(_HID, EISAID("SMBUS01")) `.
Cheers, -Tim
On Mon, May 25, 2020 at 5:39 AM Paul Menzel pmenzel@molgen.mpg.de wrote:
Dear Keith,
Am 25.05.20 um 02:05 schrieb Keith Hui:
I am attempting to build SCMI [1] support for the DSDT for asus/p3b-f to get around a PCI<->ACPI resource conflict that renders the whole SMBus and the hardware monitor inoperative. The board has ACPI AML hooks that run before and after suspend and resume, so my plan is to have Linux access the SMBus exclusively through ACPI, using the driver i2c-scmi.
The spec calls for methods _SBI, _SBR, _SBW, _SBT, _SBA. I don't need the last two for my purpose so I'll skip them. During build iasl warns that they are unrecognized reserved methods and **our build process treats all warning as errors** so my build broke.
I created a bug report for iasl [1].
What is the error number? Please look into `IGNORED_IASL_WARNINGS` in `Makefile.inc` how certain iasl warnings can be ignored.
The driver knows that some IBM bioses implementing the methods without the leading underscores, but it only expects this on devices with an _HID of "SMBUSIBM". If I use this _HID, iasl errors out: "_HID suffix must be all hex digits (SIBM)", so I have to use SMB0001, for which i2c-scmi would only look for the _SB? methods, that from what I can see is the correct way. So either my build breaks, or I can expect a build that is not going to work.
Please contact the Linux maintainers.
I cannot proceed unless I hack the build process (I send in a patch to Makefile.inc to make an exception for p3b-f) to disregard iasl warnings.
Ah, looks like you found my suggestion already.
And if I resolve the conflict by removing all ASL code for SMBus access, I would have no working suspend, even S1.
What am I supposed to do?
Kind regards,
Paul