Hi Andreas,
On Fri, Nov 15, 2019 at 1:01 PM Andreas Färber <afaerber@xxxxxxx> wrote:
> Am 15.11.19 um 09:58 schrieb Geert Uytterhoeven:
> > On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@xxxxxxxxxxxx> 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
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
