On Sun, Feb 09, 2025 at 02:31:34PM -0600, Crystal Wood wrote:
> On Fri, Feb 07, 2025 at 10:30:26PM +0100, J. Neuschäfer via B4 Relay wrote:
> > From: "J. Neuschäfer" <j.ne@xxxxxxxxxx>
> >
> > Convert the Freescale localbus controller bindings from text form to
> > YAML. The updated list of compatible strings reflects current usage
> > in arch/powerpc/boot/dts/, except that many existing device trees
> > erroneously specify "simple-bus" in addition to fsl,*elbc.
> >
> > Changes compared to the txt version:
> > - removed the board-control (fsl,mpc8272ads-bcsr) node because it only
> > appears in this example and nowhere else
> > - added a new example with NAND flash
> > - updated list of compatible strings
> >
> > Signed-off-by: J. Neuschäfer <j.ne@xxxxxxxxxx>
> > ---
> >
> > V2:
> > - fix order of properties in examples, according to dts coding style
> > - move to Documentation/devicetree/bindings/memory-controllers
> > - clarify the commit message a tiny bit
> > - remove unnecessary multiline markers (|)
> > - define address format in patternProperties
> > - trim subject line (remove "binding")
> > - remove use of "simple-bus", because it's technically incorrect
>
> While I admit I haven't been following recent developments in this area,
> as someone who was involved when "simple-bus" was created (and was on the
> ePAPR committee that standardized it) I'm surprised to hear simple-bus
> being called "erroneous" or "technically incorrect" here.
Erroneous because the binding did not say "simple-bus" was used. Not
uncommon with the old .txt bindings.
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.
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.
> 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.
> The fact that the address encoding is non-linear is irrelevant; the
> addresses can still be translated using the standard "ranges" mechanism.
> This seems to be a disconnect between the schema verification and the way
> the compatible has previously been defined and used.
>
> And as a practical matter, unless I'm missing something (which I might be
> since I haven't been in devicetree-land for nearly a decade), Linux is
> relying on simple-bus to probe these devices. There is a driver that
> binds to the bus itself but that is just for error interrupts and NAND.
>
> You'd probably need something like commit 3e25f800afb82bd9e5f8 ("memory:
> fsl_ifc: populate child devices without relying on simple-bus") and the
> subsequent fix in dd8adc713b1656 ("memory: fsl_ifc: populate child
> nodes of buses and mfd devices")...
>
> I'm curious what the reasoning was for removing simple-bus from IFC. It
> seems that the schema verification also played a role in that:
> https://www.spinics.net/lists/devicetree/msg220418.html
If a kernel change is needed to support changed .dts files, then we
shouldn't be doing that here (being mature platforms). That would mean
new DTB will not work with existing kernels.
>
> ...but there's also the comment in 985ede63a045eabf3f9d ("dt-bindings:
> memory: fsl: convert ifc binding to yaml schema") that "this will help to
> enforce the correct probe order between parent device and child devices",
> but was that really not already guaranteed by the parent/child
> relationship (and again, it should only really matter for NAND except for
> the possibility of missing error reports during early boot)?
>
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - fsl,mpc8313-elbc
> > + - fsl,mpc8315-elbc
> > + - fsl,mpc8377-elbc
> > + - fsl,mpc8378-elbc
> > + - fsl,mpc8379-elbc
> > + - fsl,mpc8536-elbc
> > + - fsl,mpc8569-elbc
> > + - fsl,mpc8572-elbc
> > + - fsl,p1020-elbc
> > + - fsl,p1021-elbc
> > + - fsl,p1023-elbc
> > + - fsl,p2020-elbc
> > + - fsl,p2041-elbc
> > + - fsl,p3041-elbc
> > + - fsl,p4080-elbc
> > + - fsl,p5020-elbc
> > + - fsl,p5040-elbc
> > + - const: fsl,elbc
>
> Is it really necessary to list every single chip?
Yes. If they exist, they have to be documented.
>
> And then it would need to be updated when new ones came out? I know this
> particular line of chips is not going to see any new members at this
> point, but as far as the general approach goes...
>
> Does the schema validation complain if it sees an extra compatible it
> doesn't recognize? If so that's obnoxious.
Yes.
More annoying is having to boot and debug typos:
compatible = "foo,bar", "simplebus";
Rob
