[cross-list: linux-mips@ and linux-wireless@] 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) 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. 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. 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. -- Rafał
