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]

Date:	Fri, 08 Feb 2013 22:02:13 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>,
	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

On Fri, 18 Jan 2013 11:05:14 +0200, Pantelis Antoniou <panto@...oniou-consulting.com> wrote:
> 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.

It's actually the other way around. The DT code path used to be a
completely separate of_platform_bus_type that didn't share any code with
platform_bus_type. So in fact, the code patches have converged instead
of diverged.

When I merged the paths there were some breakages that prevented me from
using platform_device_add() directly. Most of those are now gone and

I've got a patch in my tree which makes the OF code use
platform_device_add(). That makes this patch series unnecessary. The
patch is currently in linux-next. Assuming I don't run into any major
problems it will be merged in v3.9

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

Pitchforks? pish. It's the torches that are dangerous.

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/