On 13.02.23 14:06, Hans de Goede wrote:
ACPI can sometimes be unreliable, but that is just down to it being badly implemented by
board vendors.
The problem is: it's hard to find any vendor who does it really right.
And frankly, it's horribly complicated to implement, compared w/ DT.
Actually I wonder why that has been invented in the first place - back
then DT was already field-proven, and already technically superior.
I only know one thing that DT doesn't have (and I'm very thankful for
that): imperative bytecode. This weird idea probably comes from the
ancient realmode/DOS times where BIOS vendors had the funny idea that
the BIOS should be some universal driver blob. This already failed under
DOS (applications brought their own drivers for good reaons) and became
worse w/ protected mode. And w/ EFI a whole new level of weirdness.
Even on coreboot we have to deal with horrible fw blobs.
Maybe our (IT industry) worst mistake was ever allowing silicon or board
vendors to put their hands on software and not publishing full specs.
If used correctly it is no more or less reliable as any other code, so its reliability is not
really a good argument not to use it unless the ACPI code on PCEngines devices is known to
be unreliable ?
It's actually known to be unreliable. And very incomplete.
See my other mails.
Oh, one thing I still forgot to mention: if I read the code correctly,
the abused AMD0030 device causes the whole FCH register space (at least
the part that *may* contain gpios) as GPIO lines and making them
accessible from userspace. We already *know* that some of them aren't
gpios, but due to lack of specs (blame to AMD), we have no idea what
they actually, depending on individual SoC models (or even between
production charges). This is really irresponsible - that could possibly
lead to hardware damage.
If people wanted to use ACPI instead of the APU driver, why not just build their kernels without the APU driver linked in?
Most people do no want to / don't have the skills to build their own kernel, so they are
going to be relying on a distro (including openwrt as a sort of distro) provided kernel.
Distros usually ship them as modules. Blacklisting isn't so hard to
understand. Note that these boards aren't made for the average John Doe.
PC-engines used to advice their users to do much more complicated and
actually dangerous things like writing raw HW registers from userland.
For the upstream / mainline kernel we have a very clear defined policy of
never breaking userspace (APIs). Even though these are designed for embedded
usage, some people might be running normal distro-s on these.
People are actually running normal Distros on these. The driver was
originally written for industrial devices running Debian.
Yes a boolean module parameter with the default value of the boolean
configurable through Kconfig, so that e.g. openwrt can just pick
default values matching what it wants and won't need to specify
anything on the kernel commandline.
Since Openwrt keeps its own patch queues for dozens of packages anyways,
I wonder why that's an issue at all. And I still wonder why anybody
prefers an new, inconsistent, model specific naming scheme over a
existing consistent one.
Note this is not just about the mapping though. From what I understand
about this, using the pcengines-apu driver conflicts with the ACPI way
of accessing the LEDs and gpios.
Yes, it's better to blacklist the pinctrl-amd driver (which was made for
very different devices) on APU boards. Or even better complain
@pcengines, when they ship devices with broken new firmware.
So for the new APU models, there should be a module-option to decide
whether for probe() to continue at all on those models or whether
it should just return -ENODEV (so the driver won't bind), leaving
things just as they were before this changes. The purpose of this
is to keep the ACPI way of accessing the LEDs, ..., working.
Why should be keep their *new*, *incompatible*, *incomplete* ACPI stuff
working at all ? Who will actually benefit from that ?
Actually, since thats much newer than the already mainlined, field
proven traditional way and doesn't add any new functionality (in fact
castrates functionality), the more appropriate description is "make it
working" and "disable/break existing functionality".
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287
