Hi Andreas,
On Fri, Nov 15, 2019 at 1:01 PM Andreas Färber afaerber@suse.de wrote:
Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven:
On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong narmstrong@baylibre.com wrote:
On 12/11/2019 11:47, Andreas Färber wrote:
For example, RTD1295 will support LSADC only from revision B00 on (and it's not the first time I'm seeing such things in the industry). So if a user complains, it will be helpful to see that information.
Referencing your Amlogic review, with all due respect for its authors, the common framework here just lets that information evaporate into the deeps of sysfs.
Hopefully we never had the case where needed to use the soc info in drivers, but now we have one and having such infrastructure already in-place will help.
Renesas platforms makes a extensive usage of the soc info infrastructure to figure out plenty of HW parameters at runtime and lower their DT changes.
We do our best to use it solely for detecting quirks in early SoC revisions.
Got a pointer? I fail to immediately understand how sysfs would help drivers (as opposed to userspace) detect quirks: Parsing strings back doesn't sound efficient, and I don't see you exporting any custom APIs in drivers/soc/renesas/renesas-soc.c?
We use soc_device_match(), inside kernel drivers. Exposure through sysfs is a side-effect of using soc_device_register(), and welcomed, as it allows the user to find out quickly which SoC and revision is being used.
FTR, lshw (Ubuntu 18.04 has v2.18, which does seem to be the latest upstream version) does not parse /sys/devices/soc0/.
Gr{oetje,eeting}s,
Geert