lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <op.vt76hofg3ri7v4@arend-laptop>
Date:	Wed, 20 Apr 2011 09:16:26 +0200
From:	"Arend van Spriel" <arend@...adcom.com>
To:	"Arnd Bergmann" <arnd@...db.de>
cc:	Rafał Miłecki <zajec5@...il.com>,
	"George Kashperko" <george@...u.edu.ua>,
	"Hauke Mehrtens" <hauke@...ke-m.de>,
	"Russell King" <rmk@....linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"Jonas Gorski" <jonas.gorski@...il.com>,
	"b43-dev@...ts.infradead.org" <b43-dev@...ts.infradead.org>,
	"Greg KH" <greg@...ah.com>, "Andy Botting" <andy@...ybotting.com>,
	"Larry Finger" <Larry.Finger@...inger.net>
Subject: Re: Could I (ab)use bus (struct bus_type) for virtual Broadcom
 bus?

On Tue, 19 Apr 2011 16:35:40 +0200, Arnd Bergmann <arnd@...db.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.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ