linux-kernel - Re: [PATCH] platform: Fix platform device resource linking

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: <82FE4A4D-DCA8-4C2C-97E7-6B73D424DCF5@antoniou-consulting.com>
Date:	Fri, 18 Jan 2013 11:05:14 +0200
From:	Pantelis Antoniou <panto@...oniou-consulting.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, Matt Porter <mporter@...com>,
	Russ Dill <Russ.Dill@...com>,
	Koen Kooi <koen@...inion.thruhere.net>
Subject: Re: [PATCH] platform: Fix platform device resource linking

Hi Greg,

On Jan 18, 2013, at 5:00 AM, Greg Kroah-Hartman wrote:

> On Thu, Jan 17, 2013 at 07:27:21PM +0200, Pantelis Antoniou wrote:
>>>> In a nutshell, we have to exercise the platform device subsystem, in ways
>>>> that never happened before, so all sorts of weird bugs that no-one has seen
>>>> before.
>>> 
>>> Why do you have to do this?  What are you doing that is so different
>>> from everyone else?  What drivers are you using that trigger this type
>>> of thing?
>>> 
>> 
>> This is all part of a larger patchset; I guess you weren't directly CCed.
>> The name of the patchset is 'Introducing Device Tree Overlays' and is a
>> method of changing the live device tree and have the changes reflected to
>> the kernel's state.
> 
> Ok, no wonder I was confused :)
> 
> How about cc:ing me on the next round of these patches, all of the,
> which will give me the proper background as to what is going on?
> 

Will do. I'm still waiting for some feedback from the DT maintainers, but
I will make sure that you will be CCed on the next revision.

You can of course take a look at it and comment on the current version too. 

>>>> In that case, the code path for creating platform devices from DT is
>>>> not the same as the one that is used when creating platform device from
>>>> a board file.
>>> 
>>> Why not?
>>> 
>> 
>> Because while DT creates platform devices, it doesn't use the platform device
>> methods to do so, rather than builds the platform device itself. This is 
>> something that was overlooked.
> 
> Can't this be fixed?  What does the platform device core need to do to
> resolve this?
> 

Hmm, due to historical reasons the two ways of creating platform devices
have diverged. The core of the issue is that while OF creates platform devices
it does so in it's own way.

Take a look at of_device_add()/platform_device_add(), 
of_device_register()/platform_device_register() for example.

It is pretty obvious some bits in platform_device_* are more recent and are missing
in of_device_*.

It might make sense for the of_device_* functions that are duplicating 
platform_device_* functions to be removed, and their functionality to 
be subsumed by platform_device_*, possibly by calling some helper functions
in drivers/of/ when of_node is not NULL. The of_device_* functions can be 
replaced by a direct call to platform_device_* via a define (until all of
the callers get converted).

The problem with doing anything like this would be that a whole bunch of
devices/arches depend on DT, and if anything breaks there will be a lot of
angry people with pitchforks after the culprit.

So without the full force of a core maintainer behind such a move, people
are reluctant to do so.   

> thanks,
> 
> greg k-h

Regards

-- Pantelis

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