linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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?

  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).