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
