On 17 January 2011 12:57, Michael BÃsch <mb@xxxxxxxxx> wrote: > Well... I don't really like the idea of running one driver and > subsystem implementation on completely distinct types of silicon. > We will end up with the same mess that broadcom ended up with in > their "SB" code (broadcom's SSB backplane implementation). > For example, in their code the driver calls pci_enable_device() and > related PCI functions, even if there is no PCI device at all. The calls > are magically re-routed to the actual SB backplane. > You'd have to do the same mess with SSB. Calling ssb_device_enable() > will mean "enable the SSB device", if the backplane is SSB, and will > mean "enable the HND/AI" device, if the backplane is HND/AI. It didn't strike me as that bad, but I also didn't look at any PCI code. > So I'm still in favor of doing a separate HND/AI bus implementation, > even if > that means duplicating a few lines of code. Well, it means at least duplicating most of the chipcommon driver and the mips core driver. But if you are fine with that, I see no problem with having a separate driver for the AI bus. > SSB doesn't search for SSB busses in the system, because there's no > way to do so. The architecture (or the PCI/PCMCIA/SDIO device) registers > the bus, > if it detected an SSB device. So for the embedded case, it's hardcoded > in the arch code. For the PCI case it simply depends on the PCI IDs. > I don't see a problem here. Your arch code will already have to know > what machine it is running on. So it will have to decide whether to > register a SSB or HND/AI bus. Okay. This is mostly for the embedded case, where it is possible to create a single kernel that boots on both. The "detection" could also be done through the cpu type (74k => register AI bus, else SSB bus) instead of the chipid register of the common core. >> Also I don't know >> if it is a good idea to let arch-specific code depend on code in >> staging. > > Sure. The code needs to be cleaned up and moved to the mainline kernel > _anyway_. You don't get around this. Yes, you are right. So I guess the proposed course of action would be: 1. Make the HND/AI-Bus code from brcm80211 its own independent driver, 2. Re-add the non-wifi related code (chipcommon, mips, etc), 3. Clean up the code until it meets Linux' code style/quality, 4. Move it out of staging, and finally 5. Add the required arch specific code to bcm47xx for the newer SoCs. Jonas P.S: Any suggestions for the name? Would be "ai" okay? Technically it's "AMBA Interconnect", but "amba" is already taken. -- 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
