linux-kernel - Re: [RFC] driver-core: Remove dummy 'platform

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] [day] [month] [year] [list]

Message-ID: <CACxGe6vA2+BwJkA_N0m=c9GcdRUQotdjjDg=Vh10EJOcNxpPTQ@mail.gmail.com>
Date:	Wed, 23 Apr 2014 15:49:17 +0100
From:	Grant Likely <grant.likely@...aro.org>
To:	Rob Herring <robherring2@...il.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kay Sievers <kay.sievers@...y.org>
Subject: Re: [RFC] driver-core: Remove dummy 'platform_bus'

On Wed, Apr 23, 2014 at 3:16 PM, Rob Herring <robherring2@...il.com> wrote:
> On Wed, Apr 23, 2014 at 9:05 AM, Grant Likely <grant.likely@...aro.org> wrote:
>> On Mon, 21 Apr 2014 16:05:29 -0500, Rob Herring <robherring2@...il.com> wrote:
>>> On Wed, Nov 21, 2012 at 8:44 AM, Grant Likely <grant.likely@...retlab.ca> wrote:
>>> > The "platform_bus" (note: not platform_bus_type) only exists as an empty
>>> > directory to put platform devices into. However, it really doesn't make
>>> > sense to segregate all the platform devices into a sub directory when
>>> > typically they are memory mapped devices that doen't go through any
>>> > particular bus. Particularly on embedded type platforms the platform_bus
>>> > directory doesn't add anything.
>>> >
>>> > However, this will probably just end up breaking some userspace that
>>> > depends on the /sys/devices/platform/ path to be present (no matter how
>>> > much we protest that userspace must not depend on paths in sysfs). So
>>> > while I'm seriously proposing this change, it may just be unacceptable
>>> > ABI breakage
>>>
>>> An old thread, but was there ever a conclusion to this? We now have a
>>> mixture of using platform_bus as the parent or not on various ARM
>>> platforms.
>>
>> We kind of concluded in the opposite direction. Instead of removing the
>> /sys/device/platform directory, the drivers/of code should be changed to
>> use it.
>>
>> The following patch is sufficient to have the same effect. It doesn't
>> unify the OF and non-OF paths of platform device addition, but it gets
>> them closer. I've been nervous about applying it because I'm concerned
>> about userspace breakage, but maybe it just needs to be merged and we
>> can quirk out systems that break.
>
> Given that we've changed practically all device names in converting to
> DT and I haven't heard of any complaints, we may be okay.
>
> We also have some platforms (imx6 for example) setting the parent to
> an soc device. I still need to understand why the soc device needs to
> be the parent, but it is pointless platform variation in my book. It
> would also change the paths when someone has the whim to add an soc
> device.

Yes, that is just dumb and should be discouraged.

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/