On Fri, 18 Jan 2013 11:05:14 +0200, Pantelis Antoniou <pa...@antoniou-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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
