Re: [RFC][PATCH] ssb: separate common scanning functions

[George Kashperko <george@znau.edu.ua>]

В Птн, 18/03/2011 в 23:42 +0100, Rafał Miłecki пишет:
> 2011/3/18 George Kashperko <george@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?
> 
These are already done by host-device driver in its _probe.
After you done with that you alloc your host-specific bcmb_pci_host
struct and call something like bcmb_add_bus(host, &my_host_ops);

Have nice day,
George