Re:The Heart of RISC-V Development Is Unmatched
by AnthonyMouse on Friday October 30, 2020 @09:31PM
(#24948391)
> There’s no way or even motivation to describe those board specific miscellanies in such way that Linux Kernel drivers can dynamically consume and adapt to, or decide how to behave.
It doesn't seem like an intractable problem to standardize and document this sort of thing. Once you know that pin 45 is connected to a model ABC123 backlight controller, you know to communicate with it on pin 45 using the ABC123 backlight controller driver. If the same pin is used for multiple outputs, no problem, standardize the method for switching between outputs and describe which pins are switched to which devices using which control pins in a machine-readable table.
Apparently they haven't done this, so how do we get them to start?
On many non-PC platforms, you’re given a thousand “pins” to which you’re free to connect whatever circuit that you conceived for your product, be it green and red buttons, or backlight control circuits, or temperature sensing inputs, or SATA controllers, or 4 bit 74 series counter repurposed to switch pin 567 between SATA controller configuration interface output and battery temperature gauge input and laser ranging sensor power modulation output and self destruction device detonation cord output.
There’s no way or even motivation to describe those board specific miscellanies in such way that Linux Kernel drivers can dynamically consume and adapt to, or decide how to behave.
This is not an issue for x86 PC platform, because every x86/x64 PC is either a 100% clone of IBM 5170 “PC/AT” to run IBM DOS 5.0 or Microsoft MS-DOS 5.0 binary without ever catching fire, or a Microsoft Windows Logo Program certified product that boots into Windows of the same era from binary installer disc/USB key.