Arrgh.... Tired to hell but can't sleep... So im back ! ;) > On Thu, 2011-02-10 at 20:24 +0200, George Kashperko wrote: > > > code in drivers. Let's call it "hndbackplane" or something like that. > > hndbackplane... nevah!!1 :p Since some time I started hating hnd abbreviation dunno why. > > Well, it's just a name I made up right now. > It obviously is not a good one. ;) > It was just my way to explain the idea of a thin layer between > SSB (or AI) and drivers. That thin layer can be a mostly-inline function > layer with if()..else or a function table layer. Yes, I got your idea. But to be honest the more I think about actual implementation the more I beleive mine initial proposal is less intrusive one but might need to be redesigned slightly to avoid confusion with original SSB and guarantee proper support with hosted AI later on. Anyway as I've already said I'm going to take a break for few days to plan things with separate bus driver. Its not like I gave up and will start on bus code right away. Just want to see the whole picture. As soon as I finish with my paintings and if only I see at least 1ne more advantage for separate bus driver rather than ssb+ai driver I will start with this way ofcourse. But yet again not like im scared of amount of if/else stuff this will introduce (most of it could be hidden with proper inliners anyway). Just looks like AI bus driver is either to replicate the whole ssb_bus struct layout or whole ssb-based code subset with device drivers as well will be flooded with those if/else or inline ssb_gimme_bus(). Replicating (or including in first place) the whole ssb_bus makes me think AI is much more SSB than just AI, while all those if/else even inlined look for me less desirable and clean than ssb_core_(ctl|state)_flags. Wrapping required ssb codebase with some bcmai_zzz() will require ssb_bus struct replication yet again. There might be some other way I dont see atm, hopefully I will after get some rest. > > Any chance someone can share alike .pdf for AI socs ? > > I think that's pretty much the only one available. > Broadcom doesn't really distribute docs on HND, but only code. Maybe some kind Broadcom guy could comment on this ? -.- Might not, but I was to try anyway. > > Also would be much > > appreciated if you could help me with finding out non-embedded bcm > > ai-based hw part-numbers. > > I have no idea. You could probably look at brcm80211 for starters? > Already done with that, unfortunately PCI_VENDOR_ID_BROADCOM with dev_ids 0x4357/0x4353/0x4727 gives me no clue if they are SB or AI based. Must back again dig deep into bcm80211 but I'm already tired to hell with all those sih, sii and osh stuff :/ Have nice day, George -- 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
