2011/3/18 George Kashperko <george@xxxxxxxxxxx>:
> 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Å
--
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
