linux-kernel - Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses

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]

Date:	Sat, 7 Aug 2010 00:35:21 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Greg KH <gregkh@...e.de>
Cc:	Patrick Pannuto <ppannuto@...cinc.com>,
	Patrick Pannuto <ppannuto@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"damm@...nsource.se" <damm@...nsource.se>,
	"lethal@...ux-sh.org" <lethal@...ux-sh.org>,
	"rjw@...k.pl" <rjw@...k.pl>, "dtor@...l.ru" <dtor@...l.ru>,
	"eric.y.miao@...il.com" <eric.y.miao@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Kevin Hilman <khilman@...prootsystems.com>
Subject: Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform 
	busses

On Fri, Aug 6, 2010 at 5:46 PM, Greg KH <gregkh@...e.de> wrote:
> On Fri, Aug 06, 2010 at 09:12:27AM -0600, Grant Likely wrote:
>> On Fri, Aug 6, 2010 at 8:27 AM, Greg KH <gregkh@...e.de> wrote:
>> > On Thu, Aug 05, 2010 at 04:59:35PM -0600, Grant Likely wrote:
>> >> (On that point Greg, what is the reason for even having the
>> >> /sys/devices/platform/ parent?  Why not just let the platform devices
>> >> sit at the root of the device tree?  In the OF case (granted, I'm
>> >> biased) all of the platform_device registrations reflect the actual
>> >> device hierarchy expressed in the device tree data.)
>> >
>> > If we sat them at the "root", there would be a bunch of them there.  I
>> > don't know, we could drop the parent, I guess whoever created the
>> > platform device oh so long ago, decided that it would look nicer to be
>> > in this type of structure.
>>
>> Personally I'd rather see a meaningful structure used here.  Maybe
>> having them all in the root will encourage people to find realistic
>> parents for their platform devices.  :-)
>
> That would be nice, but take your "standard" PC today:
>        > ls /sys/devices/platform/
>        Fixed MDIO bus.0  i8042  pcspkr  power  serial8250  uevent vesafb.0
>
> There are tty devices below the serial port, which is nice to see, but
> the others?  I don't know what type of bus they would be on, do you?

Does it matter?  On my PC I count 7 devices.  On my servers, I see the
same.  I don't personally don't see any disadvantage to having them at
the root.

However, looking at them:

"Fixed MDIO bus" is actually a complete hack that I'm going to try and
get rid of.
i8042 is keyboard/mouse that probably lives on the southbridge.  I
imagine hanging off the PCI bus in the ISA IO range.
ditto pcspkr
ditto serial8250
ditto vesafb

I wouldn't have any problem modifying those specific drivers to
register under something like /sys/devices/legacy, but I don't really
think it is in any way necessary.

I suppose one *could* try to figure out the actual PCI topology that
leads to these devices, but that gets into trying to guess what the
BIOS set up to decide where to register those things.  Probably a lot
of error-prone work for absolutely no benefit.  :-)

However, on the embedded side I'm seeing a lot of devices show up
under /sys/devices/platform.  Embedded is generally different.  We
*know* what the bus topology is.  However, it seems to me that many
developers are under the mistaken assumption that platform devices
must live in /sys/devices/platform, so they don't bother reflecting
the topology in the device model and it seems to be affecting how
embedded PM is being approached (my opinion).  Removing the "struct
device platform_bus" may reduce the confusion.

>> Why don't I float a patch to remove this and see if anybody freaks
>> out.  Should I wrap it with a CONFIG_ so that it can be configurable
>> for a release or to, or just make it unconditional?
>
> If you can figure out a structure for the desktop/server machines, sure,
> I say just always enable it :)

I've got a patch in my tree now.  I'll play with it a bit before
posting it for RFC.

g.
--
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/