linux-kernel - Re: [PATCH v5 0/3] Enable ACPI-defined peripherals on i2c-piix4 SMBus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9019cce9-837f-97fc-0f3b-7503b8fc3717@metux.net>
Date:   Mon, 19 Aug 2019 20:30:30 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     acooks@...ionali.st, Jean Delvare <jdelvare@...e.de>,
        Linux I2C <linux-i2c@...r.kernel.org>
Cc:     Wolfram Sang <wsa@...-dreams.de>, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org, platypus-sw@...ngear.com,
        "Tobin C . Harding" <me@...in.cc>,
        Guenter Roeck <linux@...ck-us.net>,
        Will Wagner <willw@...allon.com>
Subject: Re: [PATCH v5 0/3] Enable ACPI-defined peripherals on i2c-piix4 SMBus

On 11.08.19 04:52, Andrew Cooks wrote:

Hi,

> My initial work is based on a board that is similar to the APU2, but has additional peripherals connected to the smbus, including a NCT7491 thermal monitor/fan controller and PCA6524 GPIO controller. These are simply peripherals on a board variant, not 'platform' devices, so I didn't want to follow the platform driver approach that the APU2 GPIO driver uses.

Why are they not platform devices ?

IMHO, a platform device is something not on a bus that can do the
probing/enumeration (like eg. pci or usb does).

Can these devices be probed directly by the bus they're connected to,
or do you have a different definition of the term "platform device" ?

:O

> SMBus (and I2C) peripherals can generally not be enumerated without some firmware support. It is possible to probe for specific devices on the bus (eg sensors-detect) but in general it is not feasible to let every supported device driver probe the bus for its device. ACPI and Devicetree provides the kernel with metadata for the device: type, address, calibrated set points for temperature, etc.

Yes, I know. My question was whether these particular devices - if
they're in the SoC itself - do need some extra support in BIOS
(acpi entries, etc), that's not already in aegesa. Or in other words:
do I need to patch my BIOS ?

I was assuming these devices are in the SoC itself - correct me if
I'm wrong.

> Since the peripherals are not standard platform devices, they are not described by the ACPI tables provided by Coreboot or AMD, but it's not too difficult to create supplementary device description tables (ACPI) for non-standard devices. These can be added to coreboot, supplied to qemu as additional firmware files (see -acpitable arg), or built into the kernel (see https://www.kernel.org/doc/Documentation/acpi/ssdt-overlays.txt)

Oh, I didn't know about SSDT overlays yet. That's interesting.

Is it also possible to describe things like leds-gpio or gpio-keyboard ?
Could be a nice idea to trim down my apu2 driver to not much more than
a piece of configuration (just like we'd do on a DT-based system)

> ACPI may be an ugly abomination, but it's what we're stuck with on x86 and it can only improve when more people get their hands on it.

hmm, I'm planning to introduce DT to x86 (also patch up apu'2 coreboot
do deliver a DT to the kernel) ... but just lacking time to get my hands
dirty on this topic.

> You might find it helpful to look at the coreboot source for the APU2 (src/mainboard/pcengines/apu2/gpio_ftns.h)

In which version ?

--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287