From: zajec5@gmail.com (Rafał Miłecki)
To: linux-arm-kernel@lists.infradead.org
Subject: Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?
Date: Wed, 20 Apr 2011 09:29:53 +0200 [thread overview]
Message-ID: <BANLkTinMe-KedeOAiQYES-LCC2O4BoE28w@mail.gmail.com> (raw)
In-Reply-To: <op.vt76hofg3ri7v4@arend-laptop>
2011/4/20 Arend van Spriel <arend@broadcom.com>:
> On Tue, 19 Apr 2011 16:35:40 +0200, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Tuesday 19 April 2011, Arend van Spriel wrote:
>>
>>> > A new bus_type really only makes sense if you expect a lot of devices
>>> > to use this and you want to have the probing in the bus. If you only
>>> > want to have a way to enumerate devices that get created by the
>>> > parent driver, you can also use platform devices.
>>>
>>> The main assumption of the (bcm)axi driver seems to be that each core can
>>> be considered as a device. Correct me if I am wrong, but I consider a
>>> device to be an entity providing a particular system function. So an
>>> ethernet device provides ethernet connectivity function, a mixer device
>>> provides sound mixing function, and so on. The cores within a chip are
>>> not
>>> always self-contained like this. To clarify let's say a system function
>>> is
>>> realized by programming core A, core B, and finally trigger core A to set
>>> the function in motion. This implies the need of coordination between the
>>> programming steps on those cores.
>>>
>>> Is my view on what is a device wrong? Does a platform device differ in
>>> this respect from a regular device?
>>
>> 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.
>
> Hi Arnd,
>
> 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.
I do not register that exceptional devices in my code.
--
Rafa?
next prev parent reply other threads:[~2011-04-20 7:29 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
2011-04-20 7:29 ` Rafał Miłecki [this message]
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=BANLkTinMe-KedeOAiQYES-LCC2O4BoE28w@mail.gmail.com \
--to=zajec5@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).