Re: coreboot Digest, Vol 183, Issue 35

[Keith Hui]

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 
> To: Paul Menzel 
> Cc: [e-mail]
> 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  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
> > > [1] http://smbus.org/specs/smbus_cmi10.pdf

coreboot Digest, Vol 183, Issue 35

[Peter Stuge]

Keith,

Keith Hui wrote:
> 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.

Just a note that it's interesting, fun and exciting to follow your progress!

Keep up the good work. You'll get there.

//Peter