On Sat, Jul 02, 2016 at 12:01:14PM +0300, Mika Westerberg wrote: > There are these boards for Makers and IoT stuff which basically have pin > header where you can connect different low speed peripherals, like > sensors and so on. The main point is that you don't always know > beforehand what devices will be connected to the board. Now, it seems Sure, that's where most of this crap comes from. > that IoT/Maker folks solved this in userspace so that they are not using > existing drivers provided by Linux kernel but instead they are using raw > access to buses like I2C and SPI, and provide their own "drivers" for > those peripherals. ...which is of course a terrible solution which results in a huge amount of wheel reinvention and effort duplication. The best practice here is to use overlays, there's people doing active work on standardizing connectors for DT at the minute which will help a lot there but engagement from the maker community in general seems depressingly poor even though some of this stuff ends up getting productized. Unfortunately you're going to have to redo all the overlay work for ACPI to use it on x86. What would be really nice would be if the schematic capture tools were able to output DT overlays automatically, that'd make it really simple to design an add on board/circuit and get the software support up with no bother. > Now, since spidev is just Linux software abstraction for raw access to > the SPI bus I don't think it is good idea to allocate special ACPI ID > just for that - it does not describe hardware. So instead I'm thinking > we could re-use those Windows ACPI IDs in the driver. Yes, exactly - spidev should never appear directly in ACPI or DT since our ideas about the best way to control the hardware may change. > With this we can either stick these devices with the boot firmware > shipping with boards or alternatively provide overlays which can be > loaded to the existing firmware as needed. Users of these boards can > then take mainline Linux and use whatever existing IoT userspace > components. It really needs to be overlays, not everyone using these boards is doing the roll your own driver stuff - they also get used by people developing more substantial add on modules for example, or people prototyping more real systems who want normal software support. > I'm going to prepare a new patch adding these ACPI IDs to the spidev > early next week. Please also ensure that we complain loudly when we use them like we do for spidev. We shouldn't be encouraging people to develop software like this.
Attachment:
signature.asc
Description: PGP signature
