Hi Grant, On Feb 9, 2013, at 12:02 AM, Grant Likely wrote:
> 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 > I'm fine with this, as long as nothing breaks. I'll wait until it lands in mainline to test it. >> 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. > Fire bad. Got it. > g. What about the other (more substantial) patches that are in limbo? Any word on them? Regards -- Pantelis -- 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/
