On Thu, 2011-02-10 at 19:40 +0200, George Kashperko wrote:
> Under "plain SSB" I mean SSB AI/SB bus interconnected with
A plain SSB bus is a plain SSB bus. Not AI, not PCI-SSB. It's plain SSB.
And that's exactly the kind of horrible confusion I am trying
to avoid. It would be completely avoided if SSB and AI bus
implementations were separated. You could _still_ implement a thin
abstraction layer on top of that to avoid if(ssb) ... else ...
code in drivers. Let's call it "hndbackplane" or something like that.
void hndbackplane_device_enable(struct dev)
{
if (device_is_ssb)
ssb_device_enable()
else
ai_device_enable()
}
And I want to say it once again: The code you added does only work
on embedded. If PCI support is to be added, the PCI-host code will
have to be changed, too. (Currently it will crash with NULL pointer
derefs on the ops)
You're actually abusing the ops structure. The ops structure is meant
to abstract the SSB backplane from its host bus. It is _not_ meant
to abstract the SSB backplane itself. Your patches mix that up. It's
an abstraction layer violation, which my proposal avoids completely.
In case I didn't say it clear enough in the past: Having SSB and AI
being separate busses does _not_ mean that they cannot share some
code. So the duplication of code is not an issue.
> system without intermediate PCI/SDIO/PCMCIA/etc bus - therefore no core
> switching required and whole mmio addrspace for all the cores can be
> accessed simultaneously. At least it looks as such for me from GPL'ed
> sourcecodes from Broadcom. Unfortunately have no other better source of
> knowledge of how is it working rather than these sources
It's pretty well understood how it works. Just read the documentation.
That is the PDF I provided and the b43 documentation wiki.
--
Greetings Michael.
--
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
