linux-kernel - Re: [PATCH v2 09/12] dt-bindings: memory-controllers: Convert fsl,elbc to YAML

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Z7uzLeXiXIdVYNM5@buserror.net>
Date: Sun, 23 Feb 2025 17:45:49 -0600
From: Crystal Wood <oss@...error.net>
To: Rob Herring <robh@...nel.org>
Cc: j.ne@...teo.net, devicetree@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org,
	Michael Ellerman <mpe@...erman.id.au>,
	Nicholas Piggin <npiggin@...il.com>,
	Christophe Leroy <christophe.leroy@...roup.eu>,
	Naveen N Rao <naveen@...nel.org>, linux-kernel@...r.kernel.org,
	linux-mtd@...ts.infradead.org
Subject: Re: [PATCH v2 09/12] dt-bindings: memory-controllers: Convert
 fsl,elbc to YAML

On Mon, Feb 10, 2025 at 03:53:24PM -0600, Rob Herring wrote:
> Generally, if a bus has control registers or resources like clocks, then 
> we tend not to call them 'simple-bus'. And '"specific-bus", 
> "simple-bus"' gives some problems around what driver if any do you 
> bind to. 

Isn't the general idea that you bind to the first one in the list that
you have a driver for, since it goes from most to least specific?

> If you have chip selects, then you have config registers for those. 
> Not really "simple" if you ask me. That being said, you could keep 
> 'simple-bus' here. I would tend to err on making the schema match the 
> actual .dts rather than updating the .dts files on older platforms like 
> these.

By that definition I wonder how much truly qualifies.  Even with
IMMR/CCSR, firmware needs to at least set the base register (which is
itself inside CCSR, so there's no way to avoid relying on knowledge of
what the firmware did, except on 8xx).  Though I acknowledge that eLBC is
a stretch, with FCM and UPM being exceptions.  FCM didn't exist in the
original LBC, and UPM was... kind of considered a fringe use case
until someone hooked NAND up to it.  :-P

The point back then wasn't that such registers don't exist, but that the
OS can use the devices without having to care.  But of course, there's
subjectivity there about what the OS might care about (e.g. UPM).

FWIW, on these chips (especially the later ones) there were all sorts of
things (in general, not specifically LBC-related) that firmware had to
set up to present a coherent system to the OS.  Not all the choices made
there were great, but if we tried to describe all the gory details from
the start I'm sure we would have made an even bigger mess of it.

> > For non-NAND devices this bus generally meets the definition of "an
> > internal I/O bus that cannot be probed for devices" where "devices on the
> > bus can be accessed directly without additional configuration
> > required".  NAND flash is an exception, but those devices have
> > compatibles that are specific to the bus controller.
> 
> NAND bindings have evolved quite a bit if you haven't been paying 
> attention.

I haven't, as I acknowledged... but I was describing how eLBC does it,
and just meant that we're not binding to drivers that don't know about
the bus in that case.  The NAND control registers are part of eLBC/IFC,
not a separate block (the reg in the NAND node itself is just the SRAM
used as a buffer).  I'm not sure what that would be expected to look like
these days.

-Crystal