On Fri, Aug 14, 2015 at 9:46 AM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > On Fri, Aug 14, 2015 at 2:30 AM, Simon Horman <horms@xxxxxxxxxxxx> wrote: >> On Thu, Aug 13, 2015 at 02:45:55PM +0200, Geert Uytterhoeven wrote: >>> On Thu, Aug 13, 2015 at 2:29 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >>> > On Wed, Aug 5, 2015 at 2:55 AM, Simon Horman <horms@xxxxxxxxxxxx> wrote: >>> >> Where possible I prefer not to apply non-DTS/DTSI patches on top of >>> >> DTS/DTSI patches, I believe this is in keeping with how the ARM SoC >>> >> maintainers like things handled. With this in mind I have done the following: >>> >> >>> >> 1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch. >>> >> I intend for this to turn up in next soon. >>> >> 2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch. >>> >> I intend for these to be present in the renesas devel branch but >>> >> not in next until after the release of v4.3-rc1. I would also be >>> >> happy to drop them and let Linus Walleij take these patches for v4.4, >>> >> assuming patches 1 - 3 are accepted for v4.3. >>> > >>> > OK. >>> > >>> > Will the world explode if I try to queue the pinctrl patches 4-6 in my >>> > tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge >>> > it in parallel? >>> >>> There won't be a mapping between gpio and pins in any branch having the >>> pinctrl changes but not the dtsi changes. >> >> It sounds to me that Linus should take his option 2; defer to v4.4. >> In which case I should drop the changes from my tree (they are not in next >> anyway). Please let me know if thats the way we will move this forwards. > > Sounds fine to me. > > And in the unlikely event we discover regressions in v4.3-rc1 due to having > the dtsi changes without the pinctrl changes, we can still fast-track them > into v4.3-rc2. Sounds like a plan. Hit me on the head about this once v4.3-rc1 is out! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html