2011/3/18 George Kashperko <george@xxxxxxxxxxx>: >> I don't see the point where my patch is in conflict with your idea. > Not your patch, just scan_read32, scan_switchcore, ssb_iounmap, > ssb_ioremap. So far ssb_core_name is fine. > Yet again, ssb code model is core-sentric which is not actually true > from the hardware pint of view. With few workarounds it works fine for > sb. For axi we will have more of these. > > scan_read32, scan_switchcore, ssb_iounmap, ssb_ioremap are all > host-driven services. In ssb model host is operating cores and therefore > requires all that switch, scan_read, map, unmap etc. While with model > where host is providing not core but backplane access the only routine > among those above you need is scan_read32 and nothing more (actually you > don't need it too as host ops with read(8|16|32) are completely > sufficient for scanning). The purpose of scan_read32 for ssb model is > that ssb_bus_ops are operating cores which you don't have at the moment > when scanning. With host ops designed as u32 (*read32)(struct host > *host, phys_addr_t addr) host will do what it supposed to - manage its > means of backplane physical access and will have absolutely no need to > break into understanding what the core/sprom/otp/etc. is. That's what I wanted to hear from the beginning, thanks! :) The reason I implemented scan_switchcore is early stage, when I prepare bus for reading EROM: erombase = ai_scan_read32(bus, 0, SSB_CHIPCO_EROM); pci_write_config_dword(bus->host_pci, PCI_BAR0_WIN, erombase); In above you can see my hack which works for PCI host only. This hack I wanted to replace with scan_switchcore and that functions seems to perform exactly this operation. AFAIU we need to adjust PCI_BAR0_WIN and PCI_BAR0_WIN2 later, when we already have info about core from EROM. In early stage we can not use that. Anyway with what you said now, I'll re-read your mails again, to fully understand your POV. -- 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