On Sun, 3 May 2020 19:25:20 +0300 Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > On Sun, May 3, 2020 at 2:22 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > On Tue, 28 Apr 2020 19:29:22 +0200 > > Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > ... > > > > This was tested on the following models: Acer Switch 10 SW5-012 (CM32181) > > > Asus T100TA (CM3218), Asus T100CHI (CM3218) and HP X2 10-n000nd (CM32181). > > > > I assume it's far too much to hope this CPM0 / CPM1 stuff is actually defined > > in a spec anywhere? > > > > There are standard way of adding vendor specific data blobs to ACPI and this > > isn't one of them (unless I'm missing something). People need to beat > > up vendors earlier about this stuff. > > > > Grumble over... > > > > Code looks fine to me, but I'd like an ACPI review ideally. > > ACPI didn't cover embedded world and has the following issues > a) where it should be strict (like how many I2CSerialBus() resources > can be given and for what type of devices, etc), it doesn't > b) they need to provides better validation tools, but they didn't > c) it's still windows oriented :-( > > Above is custom extension on how to add device properties (and note, > we have now _DSD() and still we have some M$ way of thinking how to > use them). > > Since the above approach is in the wild, I'm afraid we have not many > possibilities here (each of them with own problems): > 1/ shout at vendors to use ACPI properly and simple don't by broken > hardware (rather firmware) > 2/ try to support custom changes (may lead to several approaches for > the same thing) > 3/ create a lot of board files (something in between 1/ and 2/) > > As a result: > 1/ is obviously a best one, but I think it's an utopia. Let's keep the "shout" bit where possible :) Makes us feel better anyway. > 2/ in practice we don't have many deviations (luckily OEMs are quite > lazy to modify reference BIOSes and often reuse existing approaches) > 3/ may not work, because on cheap laptops the means of distinguishing > them (like DMI strings) may also been broken. > The UEFI forum are finally making steps in the right direction on how they develop their specs (sort of) so I guess interested companies should rock up and see if they can get some of this stuff fixed. (those that can attend meetings anyway - but that's a different issue). Spec meetings are fun and everyone loves the EDK2 source code :) J
