netdev - Re: Merging SSB and HND/AI support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTims0DPfG+u9qynuuj_-0WjUr1nAGLuFz3k706T-@mail.gmail.com>
Date:	Mon, 17 Jan 2011 14:43:08 +0100
From:	Jonas Gorski <jonas.gorski@...il.com>
To:	Michael Büsch <mb@...sch.de>
Cc:	linux-mips@...ux-mips.org, linux-wireless@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: Merging SSB and HND/AI support

On 17 January 2011 12:57, Michael Büsch <mb@...sch.de> 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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html