[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