| To: | Jonas Gorski <jonas.gorski@gmail.com> |
|---|---|
| Subject: | Re: Merging SSB and HND/AI support |
| From: | Geert Uytterhoeven <geert@linux-m68k.org> |
| Date: | Mon, 17 Jan 2011 14:54:24 +0100 |
| Cc: | Michael Büsch <mb@bu3sch.de>, linux-mips@linux-mips.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org |
| Dkim-signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lUcBKaoVOnQqedyjNMI7R+WIjjYfW3QC4LdIO0BmbIY=; b=lENoMGI7gFNifFBbruqLORBBkKROc9uGj1RcjqeeuSy0Gf9JXd880OXt46oHBzRNk5 L5tx6WoSm7LggwBKPuQRxuehaJgFKR01dy0QtxqNldjF+1fg06umcKt91N7yRJBj39mv A57WqxQevxVSClHpesM4O0IXuDy8LWqWPPW80= |
| Domainkey-signature: | a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=utBKNppHDcFmyRDPkMQIZo0MO7LVW7B3QYWLaS0KrGqeRQtlJvG34t03zOpfUFBNbe P0kvGrflfCu3OMzdMesqLDRK0nCZgxmHdbAOQcZdSc4OJw2R6jN6CSngIcoxv3BU3N6H 9XdUPNcrl6VpmnfTrcDuJjcseyjxWpqMWw/p0= |
| In-reply-to: | <AANLkTims0DPfG+u9qynuuj_-0WjUr1nAGLuFz3k706T-@mail.gmail.com> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <AANLkTi=GDcy50zsC6=Dgv1-Ty3cYK2qpx9o=q3JdXuCh@mail.gmail.com> <1295261783.24530.3.camel@maggie> <AANLkTikJcug7LUTgX_YDD4Z8ZBrdkAdLq8_Epa6TkA5f@mail.gmail.com> <1295265468.24530.23.camel@maggie> <AANLkTims0DPfG+u9qynuuj_-0WjUr1nAGLuFz3k706T-@mail.gmail.com> |
| Sender: | linux-mips-bounce@linux-mips.org |
On Mon, Jan 17, 2011 at 14:43, Jonas Gorski <jonas.gorski@gmail.com> wrote:
> On 17 January 2011 12:57, Michael Büsch <mb@bu3sch.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.
> P.S: Any suggestions for the name? Would be "ai" okay? Technically
> it's "AMBA Interconnect", but "amba" is already taken.
If it's AMBA, can it be integrated with the existing code in drivers/amba/?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] sched: provide scheduler_ipi() callback in response to smp_send_reschedule(), Chris Metcalf |
|---|---|
| Next by Date: | Re: [PATCH] sched: provide scheduler_ipi() callback in response to smp_send_reschedule(), Jesper Nilsson |
| Previous by Thread: | Re: Merging SSB and HND/AI support, Jonas Gorski |
| Next by Thread: | Re: Merging SSB and HND/AI support, Jonas Gorski |
| Indexes: | [Date] [Thread] [Top] [All Lists] |