On Tuesday 26 August 2014 18:42:51 Rafał Miłecki wrote: > > We're working on another Broadcom platform, SoC with an ARM CPU, > platform called bcm53xx. It shares many things with the older (MIPS > based) bcm47xx, so we need to figure out how to modify some of the > drivers. > > Hauke recently proposed sharing code for NVRAM support as a separated > driver. In his RFC patch it was added as a new platform driver. I > liked this idea (I'd simply prefer to modify existing code instead of > duplicating it), so I played with it a bit today. > > My plan was to modify bcm47xx code to make nvram.c a separated driver > and update bcm47xx/bcma to use it. Well, it didn't work out. The > problem is that we need access to the NVRAM pretty early. Please take > a look at my description of bcm47xx booting process (it's simply a > summary of start_kernel and bcm47xx code): > > 1) prom_init / plat_mem_setup > These two functions are called in pretty much the same phase from the > setup_arch (arch/mips/kernel/setup.c). > Task: detect & register memory > Requires: CPU type, maybe Broadcom chip ID (highmem support) > Available: CPU type > Not available: kmalloc, device_add (kobject) > > 2) arch_init_irq > Called from the arch specific init_IRQ (arch/mips/kernel/irq.c) > Task: setup bcma's MIPS core > Requires: bcma bus MIPS core > Available: kmalloc > Not available: device_add (kobject) > > 3) plat_time_init > Called from the arch specific time_init (arch/mips/kernel/time.c) > Task: set frequency > Requires: bcma bus ChipCommon core, nvram > Available: kmalloc > Not available: device_add (kobject) My impression is that all the information that you need in these early three steps is stuff that is already meant to be part of DT. This isn't surprising, because the bcm47xx serves a similar purpose to DT, it's just more specialized. This duplication is a bit unfortunate, but it seems that just using the respective information from DT would be easier here. Is any of the information you need early dynamic? It sounds that for a given SoC, it should never change and can just be statically encoded in DT. > 4) At some point we need to register bcma devices, device_initcall can > be used for that > > As you can see, we need access to the NVRAM quite early (step 3, > plat_time_init, or even earlier), but device_add (platform > devices/drivers) is not available then yet. So I'm afraid we won't be > able to use this common way to write NVRAM driver. > > > So there I want to present my plan for the NVRAM improvements. If you > don't agree with any part of it, or you can see any better solution, > please speak up! > > 1) I won't make nvram.c a platform driver. Instead I would like to > make it less bcm47xx specific. I don't want to touch bcm47xx_bus in > this file. Instead I want to add a generic function that will accept > address and size of memory where NVRAM should be found. Then I'd like > to move this file out of "mips" arch (drivers/misc/? > drivers/bcma/nvram/?) and allow using it for bcm53xx. In general, I'd try to avoid adding any platform specific code on ARM when it needs to run as something other than a device driver. Moving the code out of arch/mips and making it more generic definitely sounds good to me, but I'd prefer to have an actual platform_driver for it. > 2) I was also thinking about cleaning bcm47xx init. Right now we do a > lot of hacks in plat_mem_setup & bcma to register the bus and scan its > cores. It's so early (before mm_init) that we can't alloc memory! > Doing all this stuff slightly later (e.g. arch_init_irq) would allow > us to simply use "kmalloc" and drop all current hacks in bcma. This sounds good > 3) Above change (point 2) would require some small change in bcma. We > would need 2-stages init: detecting (with kmalloc!) bus cores, > registering cores. This is required, because we can't register cores > too early, device_add (and the underlying kobject) would oops/WARN in > kobject_get. Right. Could you do the bcma scan much later, at the time when device_add works as well? Traditionally PCI has been a problem since it had to be enabled really early, but that restriction should be gone now, and we can actually probe it from a loadable module. A common exception is the console driver, and we have a number of other cases where we do a minimal bus scan just to find the serial console at very early boot, but then probe all other devices from a regular initcall. On a global level, there is another choice, which is to do something similar to the 'pxa-impedence-matcher' and the 'sunxi-babelfish': These are two projects that implement a last-stage boot loader that runs before the kernel and translates a platform-specific boot format into standard DTB format. We could do the same for bcm53xx and translate any nvram strings we know about into properties of device nodes we already have, and copy all remaining strings into a properties of the /chosen node. That way, we don't even need any nvram driver for ARM, except a trivial one that provides raw write access to user space for updating it. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
