> I mean that all OF devices have fully resolved MMIO resources. So > very early serial devices that sit in I/O space on sparc64 end > up being OF device drivers. See for example, drivers/net/sunsu.c > which is simply a 8250 chip that sits behind Sun's I/O space bus > that sits on PCI and provides things normally found via ISA on > x86 machines. Another example is drivers/serial/sunsab.c
Right. On Cell, we use the "normal" 8250 driver, via of_serial which basically initializes it from the of device and associated resources. It gets a bit messy because we -also- create a platform driver that can be matched by 8250, in fact, we have a bit of generic powerpc code that does that early at boot, initializes our low level very early udbg thingy with it and creates the platform devices. And then the serial port can -also- be detected by 8250_pci.c when it's on a PCI based UART :-) Now, generally thinks work fine even if you use all 3 drivers because they have the same resources and 8250 has some smarts to figure that out and not re-create ports. It somewhat fails in the case where we end up with IO looking like MMIO on one side and looking like PCI IO on another tho. We -could- try to standardize on a single of those 3 methods of course. The of_serial one has some appeal but I quite like the platform driver approach at this stage because we have code to handle all sort of weirdo special cases in there (more or less insane device-tree's, weird SoC's, etc...) and still pump out something 8250_platform can grok, and that code can run -very- early and provide a udbg backend for early debug and xmon usage. > I would make these device drivers OF device drivers. > > Another option is to make use of the "address" property if present. > You can bypass all of the hassle of figuring out what the 'reg' > property resolves to by using that and if the device is the > console it is pretty reliable to expect OF to provide that "address" > property. > > Of course this doesn't work well for non-console devices. Also we have various broken firmwares with non usable "address" properties to deal with. Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev