Re: [GIT PULL] pin control bulk changes for v3.13

[Vineet Gupta <Vineet.Gupta1@synopsys.com>]

On 11/11/2013 03:53 PM, Linus Walleij wrote:
> On Mon, Nov 11, 2013 at 11:00 AM, Vineet Gupta
> <Vineet.Gupta1@synopsys.com> wrote:
>> On 11/11/2013 03:03 PM, Linus Walleij wrote:
>>> Actually I think device tree changes - if you mean changes to this platform's
>>> DTS/DTSI files, should go through the ARC arch tree.
>> But current workflow is prone to broken bisectability - arch maintainers need to
>> make sure that the core/driver changes hit mainline before the actual dts/dtsi
>> files in arch/*
> No. This is *not* a bisectability problem, as it has been established
> that device trees and kernel code shall *not* be built and deployed
> together.

Well that is a fine design *goal*. But in reality (at least his patch) is making a
driver change and then enabling arch via DT to access it. I can't fathom what is
the issue with having both the changes routed via the same tree - other than
possible merge hassles - which can can PITA for arches such as ARM. So you can say
that as a general *practice* subsys guys don't prefer what I'm asking for and I'm
OK if you reason it that way. But saying that it is not a bisectability problem
and is design goal etc is bogus IMO.

> Consider:
>
> - Just subsystem changes are merged: OK you can still take your
>   DTS from somewhere and boot this kernel with it.
>
> - Just the arch/*/*.dts[i] changes are merged: OK these new DT
>   nodes remain unused, presumably the system survives anyway?
>
> It only becomes a problem if you also start to apply patches deleting
> functionality that has been moved over to the device tree in the same
> merge window - don't do that. Take a sweep with the broomstick
> next time instead.

Ya Ya I see, but the patch under consideration don't fall in either of those
buckets. We have 1 change in each of arch and subsys.

-Vineet