linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Arend van Spriel" <arend@broadcom.com>
To: "Arnd Bergmann" <arnd@arndb.de>
Cc: "Rafał Miłecki" <zajec5@gmail.com>,
	"George Kashperko" <george@znau.edu.ua>,
	"Hauke Mehrtens" <hauke@hauke-m.de>,
	"Russell King" <rmk@arm.linux.org.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Jonas Gorski" <jonas.gorski@gmail.com>,
	"b43-dev@lists.infradead.org" <b43-dev@lists.infradead.org>,
	"Greg KH" <greg@kroah.com>, "Andy Botting" <andy@andybotting.com>,
	"Larry Finger" <Larry.Finger@lwfinger.net>
Subject: Re: Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?
Date: Wed, 20 Apr 2011 09:57:40 +0200	[thread overview]
Message-ID: <op.vt7787f43ri7v4@arend-laptop> (raw)
In-Reply-To: <201104200926.09110.arnd@arndb.de>

On Wed, 20 Apr 2011 09:26:08 +0200, Arnd Bergmann <arnd@arndb.de> wrote:

> On Wednesday 20 April 2011 09:16:26 Arend van Spriel wrote:
>> >
>> > A platform device means something that cannot be probed, in every  
>> other
>> > respect it is the same as other devices. From your explanation above,
>> > it seems that you don't actually need to represent the cores on your
>> > particular chips as struct device in Linux at all.
>> >
>> > If you wanted to use platform_device, the right way would probably
>> > be an MFD device that creates multiple child devices (which end
>> > up as platform_device, though you don't need to worry about that)
>> > from the PCI driver. Then you could use the child devices completely
>> > independent from one another.
>> >
>> > Since you say that the cores in this case are tightly coupled and
>> > don't provide independent functionality to the system, there is
>> > no need to represent them as devices.
>>
>> The case is a hypothetical one, but I consider it a likely one. The axi
>> bus driver currently registers each detected core as a device in the  
>> linux
>> device tree. My statement is that this implies loose or no coupling
>> between those cores, which is not true. One (or two) exceptions have
>> already been identified. I would expect your last line to read: ...to  
>> the
>> system, those cores should not be represented as devices.
>
> The important question is what is most practical here. If most of the
> cores of this type are standalone devices, it's probably best to  
> represent
> all of them as separate devices, and find ways to deal with the few  
> logical
> devices that are spread across multiple cores.
> It it's the exception and you typically have a significant number of IP
> blocks that need to be combined to make a single logical device, I would
> recommend not representing each of them as a struct device.
>
> We really need to figure out first what the requirements are given the
> hardware you want to support with this.

Very true. I have forwarded this email conversation to a colleague of mine  
to see whether my hypothesis is likely or rarely true at least for  
Broadcom chipsets. As we concluded that Broadcom seems to be the only one  
currently using this bus that input may be sufficient to determine the  
requirements.

Gr. AvS
-- 
"The world is indeed comic, but the joke is on mankind." — H.P. Lovecraft


  reply	other threads:[~2011-04-20  7:58 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-14 11:28 Could I (ab)use bus (struct bus_type) for virtual Broadcom bus? Rafał Miłecki
2011-04-14 11:43 ` George Kashperko
2011-04-14 12:04   ` Rafał Miłecki
2011-04-14 12:34     ` Hauke Mehrtens
2011-04-14 13:07       ` Rafał Miłecki
2011-04-14 13:15         ` George Kashperko
2011-04-14 13:45           ` Rafał Miłecki
2011-04-15 18:36             ` George Kashperko
2011-04-15 19:21               ` Rafał Miłecki
2011-04-15 19:42                 ` George Kashperko
2011-04-15 19:52                   ` Rafał Miłecki
2011-04-15 19:56                     ` Peter Stuge
2011-04-16 14:00                       ` Rafał Miłecki
2011-04-16 14:13                         ` Jonas Gorski
2011-04-15 19:50                 ` George Kashperko
2011-04-17 17:38                 ` Arnd Bergmann
2011-04-18 12:19                   ` Rafał Miłecki
2011-04-18 14:19                     ` Arnd Bergmann
2011-04-18 14:31                       ` Rafał Miłecki
2011-04-18 15:35                         ` George Kashperko
2011-04-18 15:53                           ` Rafał Miłecki
2011-04-18 16:48                             ` George Kashperko
2011-04-19 13:46                         ` Arnd Bergmann
2011-04-19 13:58                   ` Arend van Spriel
2011-04-19 14:02                     ` Greg KH
2011-04-20  6:39                       ` Arend van Spriel
2011-04-20  6:44                         ` Arnd Bergmann
2011-04-19 14:20                     ` Rafał Miłecki
2011-04-19 14:35                     ` Arnd Bergmann
2011-04-20  7:16                       ` Arend van Spriel
2011-04-20  7:26                         ` Arnd Bergmann
2011-04-20  7:57                           ` Arend van Spriel [this message]
2011-04-20  7:29                         ` Rafał Miłecki
2011-05-05 12:33                           ` AXI driver status => previously: " Arend van Spriel
2011-05-05 12:48                             ` Rafał Miłecki
2011-05-05 12:54                               ` Arend van Spriel
2011-04-14 13:03     ` George Kashperko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.vt7787f43ri7v4@arend-laptop \
    --to=arend@broadcom.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=andy@andybotting.com \
    --cc=arnd@arndb.de \
    --cc=b43-dev@lists.infradead.org \
    --cc=george@znau.edu.ua \
    --cc=greg@kroah.com \
    --cc=hauke@hauke-m.de \
    --cc=jonas.gorski@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).