Re: [GIT PULL] pin control bulk changes for v3.13
On 11/11/2013 03:53 PM, Linus Walleij wrote: > On Mon, Nov 11, 2013 at 11:00 AM, Vineet Gupta > 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 -- 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/
Re: [GIT PULL] pin control bulk changes for v3.13
On Mon, Nov 11, 2013 at 11:00 AM, Vineet Gupta 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. 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. >> As the idea is to eventually move the DTS stuff out of the kernel we should >> not try to couple these into the subsystem trees. > > IMHO putting the 2 parts in a patch series and routing via the same subsys > tree > will not really couple them. I fail to see how u would use the commits in > driver/* > (or not use the commits in arch/*) to do the proposed seperation of future. I don't understand this. First you say it is prone to broken bisectability, then you say it is not coupled? Isn't this the same thing? Yours, Linus Walleij -- 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/
Re: [GIT PULL] pin control bulk changes for v3.13
On 11/11/2013 03:03 PM, Linus Walleij wrote: > On Mon, Nov 11, 2013 at 8:54 AM, Vineet Gupta > wrote: >> On 11/11/2013 12:14 PM, Linus Walleij wrote: >>> - Add the Abilis TB10x pin control driver used on the ARC >>> architecture. Also the corresponding GPIO driver is merged >>> through this tree, so the ARC has full support for pins >>> and GPIOs after this. >> Only the actual DT changes in arch/arc/plat-tb10x are missing which will >> require a >> 2nd pull request for ARC for rc1 which could have been avoided had I bitched >> about >> it earlier. > 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/* > As the idea is to eventually move the DTS stuff out of the kernel we should > not try to couple these into the subsystem trees. IMHO putting the 2 parts in a patch series and routing via the same subsys tree will not really couple them. I fail to see how u would use the commits in driver/* (or not use the commits in arch/*) to do the proposed seperation of future. > Bindings Documentation/devicetree/bindings/* should go through the > subsystem trees though. Agreed ! -Vineet -- 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/
Re: [GIT PULL] pin control bulk changes for v3.13
On Mon, Nov 11, 2013 at 8:54 AM, Vineet Gupta wrote: > On 11/11/2013 12:14 PM, Linus Walleij wrote: >> - Add the Abilis TB10x pin control driver used on the ARC >> architecture. Also the corresponding GPIO driver is merged >> through this tree, so the ARC has full support for pins >> and GPIOs after this. > > Only the actual DT changes in arch/arc/plat-tb10x are missing which will > require a > 2nd pull request for ARC for rc1 which could have been avoided had I bitched > about > it earlier. Actually I think device tree changes - if you mean changes to this platform's DTS/DTSI files, should go through the ARC arch tree. As the idea is to eventually move the DTS stuff out of the kernel we should not try to couple these into the subsystem trees. Bindings Documentation/devicetree/bindings/* should go through the subsystem trees though. Yours, Linus Walleij -- 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/
Re: [GIT PULL] pin control bulk changes for v3.13
On Mon, Nov 11, 2013 at 8:54 AM, Vineet Gupta vineet.gup...@synopsys.com wrote: On 11/11/2013 12:14 PM, Linus Walleij wrote: - Add the Abilis TB10x pin control driver used on the ARC architecture. Also the corresponding GPIO driver is merged through this tree, so the ARC has full support for pins and GPIOs after this. Only the actual DT changes in arch/arc/plat-tb10x are missing which will require a 2nd pull request for ARC for rc1 which could have been avoided had I bitched about it earlier. Actually I think device tree changes - if you mean changes to this platform's DTS/DTSI files, should go through the ARC arch tree. As the idea is to eventually move the DTS stuff out of the kernel we should not try to couple these into the subsystem trees. Bindings Documentation/devicetree/bindings/* should go through the subsystem trees though. Yours, Linus Walleij -- 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/
Re: [GIT PULL] pin control bulk changes for v3.13
On 11/11/2013 03:03 PM, Linus Walleij wrote: On Mon, Nov 11, 2013 at 8:54 AM, Vineet Gupta vineet.gup...@synopsys.com wrote: On 11/11/2013 12:14 PM, Linus Walleij wrote: - Add the Abilis TB10x pin control driver used on the ARC architecture. Also the corresponding GPIO driver is merged through this tree, so the ARC has full support for pins and GPIOs after this. Only the actual DT changes in arch/arc/plat-tb10x are missing which will require a 2nd pull request for ARC for rc1 which could have been avoided had I bitched about it earlier. 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/* As the idea is to eventually move the DTS stuff out of the kernel we should not try to couple these into the subsystem trees. IMHO putting the 2 parts in a patch series and routing via the same subsys tree will not really couple them. I fail to see how u would use the commits in driver/* (or not use the commits in arch/*) to do the proposed seperation of future. Bindings Documentation/devicetree/bindings/* should go through the subsystem trees though. Agreed ! -Vineet -- 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/
Re: [GIT PULL] pin control bulk changes for v3.13
On Mon, Nov 11, 2013 at 11:00 AM, Vineet Gupta vineet.gup...@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. 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. As the idea is to eventually move the DTS stuff out of the kernel we should not try to couple these into the subsystem trees. IMHO putting the 2 parts in a patch series and routing via the same subsys tree will not really couple them. I fail to see how u would use the commits in driver/* (or not use the commits in arch/*) to do the proposed seperation of future. I don't understand this. First you say it is prone to broken bisectability, then you say it is not coupled? Isn't this the same thing? Yours, Linus Walleij -- 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/
Re: [GIT PULL] pin control bulk changes for v3.13
On 11/11/2013 03:53 PM, Linus Walleij wrote: On Mon, Nov 11, 2013 at 11:00 AM, Vineet Gupta vineet.gup...@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 -- 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/
Re: [GIT PULL] pin control bulk changes for v3.13
On 11/11/2013 12:14 PM, Linus Walleij wrote: > - Add the Abilis TB10x pin control driver used on the ARC > architecture. Also the corresponding GPIO driver is merged > through this tree, so the ARC has full support for pins > and GPIOs after this. Only the actual DT changes in arch/arc/plat-tb10x are missing which will require a 2nd pull request for ARC for rc1 which could have been avoided had I bitched about it earlier. -Vineet -- 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/
Re: [GIT PULL] pin control bulk changes for v3.13
On 11/11/2013 12:14 PM, Linus Walleij wrote: - Add the Abilis TB10x pin control driver used on the ARC architecture. Also the corresponding GPIO driver is merged through this tree, so the ARC has full support for pins and GPIOs after this. Only the actual DT changes in arch/arc/plat-tb10x are missing which will require a 2nd pull request for ARC for rc1 which could have been avoided had I bitched about it earlier. -Vineet -- 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/
