Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Greg KH]

On Tue, Apr 19, 2011 at 03:58:32PM +0200, Arend van Spriel wrote:
> On Sun, 17 Apr 2011 19:38:12 +0200, Arnd Bergmann <arnd at arndb.de> wrote:
> 
> Hi Rafał,
> 
> As you probably expected I tried to integrate and use your bcmai/bcmaxi/?
> driver with our brcm80211 driver (making progress). In the mean time
> I tried to follow the discussions going on, but I am still catching
> up.
> 
> >Compare this to the PCI bus type, which essentially deals with devices
> >that have a PCI configuration space that contains generic (irq, memory,
> >vendor/device ID, ...) registers along with device specific registers.
> 
> How much alike is the (BCM)AXI bus type? My assumption was that each
> registered PCI device is handled by a single driver module. In the
> current(?) bcmai implementation each device driver is called with the
> appropriate device structure reference, but it will also have the bus
> structure reference and through that can also access other cores on the
> (bcm)axi bus. This seems to me a potential issue when there are no
> synchronization mechanisms in place (whether in a SoC configuration or
> PCI-hosted). Does the PCI bus type allow driver for device A access
> device B?
> 
> >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?

Please don't use a platform device, unless there is no other way for
your device to work.  For this device, you are connected to the PCI bus,
so a platform device does not make sense at all.

thanks,

greg k-h