Return-path: Received: from mail-qw0-f46.google.com ([209.85.216.46]:49659 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752924Ab1DTH3y convert rfc822-to-8bit (ORCPT ); Wed, 20 Apr 2011 03:29:54 -0400 MIME-Version: 1.0 In-Reply-To: References: <201104171938.12834.arnd@arndb.de> <201104191635.40351.arnd@arndb.de> Date: Wed, 20 Apr 2011 09:29:53 +0200 Message-ID: Subject: Re: Could I (ab)use bus (struct bus_type) for virtual Broadcom bus? From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= To: Arend van Spriel Cc: Arnd Bergmann , George Kashperko , Hauke Mehrtens , Russell King , "linux-kernel@vger.kernel.org" , "linux-wireless@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Jonas Gorski , "b43-dev@lists.infradead.org" , Greg KH , Andy Botting , Larry Finger Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: 2011/4/20 Arend van Spriel : > On Tue, 19 Apr 2011 16:35:40 +0200, Arnd Bergmann 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ł