[RFC][PATCH] ssb: separate common scanning functions
Rafał Miłecki
zajec5 at gmail.com
Fri Mar 18 18:42:20 EDT 2011
2011/3/18 George Kashperko <george at znau.edu.ua>:
> Well, I see this as following. In generic host life time there are
> several states. These states are following:
> 1. Host just started up, underlying backplane is powered up, we issued
> backplane detect/scan. At this point at least some minimal windowed
> access is up (if such required), not yet cores/devices are known.
> 2. Backplane got identified, scanned, individual cores/devices
> recognised, buscommon and buscore are registered with kernel to get them
> matched with drivers, and then probed and set up.
> 3. Buscommon and buscore are driven, host can finish with host specific
> workarounds, both buscommon and buscore can get their _init entry points
> called, we can setup host device irq routine, finally we can expose the
> rest cores/devices to kernel.
>
> With that in mind here is my general host ops design pseudo code:
> struct host_ops {
> /* Init call we should get once both buscommon and buscore drivers are bound (state #3) */
> int (*init)(struct bcmb_bus *bus);
>
> /* Regular backplane access ops */
> u8 (*read(8|16|32))(struct bcmb_bus *bus, bcmb_addr_t addr);
> void (*write(8|16|32))(struct bcmb_bus *bus, bcmb_addr_t addr, u(8|16|32) val);
>
> /* For some theoretically hard-to-set-up before scan hosts we could keep scan_read32 */
> u32 scan_read32(struct bcmb_bus *bus, bcmb_addr_t addr);
> };
I don't think it makes much sense. If init is going to be called in
state #3, what about some pre-init? set_master, request_region, xtal,
iomap?
--
Rafał
More information about the b43-dev
mailing list