Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210128170331.4f2ac87b@canb.auug.org.au> <CAMuHMdWAOXpJGTRM7O7ix4uG-hpH-kDiueN51oA0YEZ0vJdZfw@mail.gmail.com>
In-Reply-To: <CAMuHMdWAOXpJGTRM7O7ix4uG-hpH-kDiueN51oA0YEZ0vJdZfw@mail.gmail.com>
From:   Arnd Bergmann <arnd@kernel.org>
Date:   Tue, 9 Feb 2021 12:35:30 +0100
Message-ID: <CAK8P3a1Fv=Bei+Zkq43yn_dek=RB96_yXrtJ-ZA5K4nf06joOw@mail.gmail.com>
Subject: Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree
To:     Geert Uytterhoeven <geert@linux-m68k.org>
Cc:     Stephen Rothwell <sfr@canb.auug.org.au>,
        Bartosz Golaszewski <brgl@bgdev.pl>,
        Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
        ARM <linux-arm-kernel@lists.infradead.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>,
        Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Feb 9, 2021 at 11:01 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Jan 28, 2021 at 7:05 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > diff --cc arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > index 37da418393e0,950010a290f0..000000000000
> > --- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > +++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > @@@ -42,7 -42,6 +42,11 @@@
> >         clock-names = "apb_pclk";
> >   };
> >
> >  +&wdt {
> >  +      status = "okay";
> >  +      clocks = <&wdt_clk>;
> >  +};
> > ++
> > + &gpio {
> > +       status = "okay";
> > + };
>
> Probably some sort order should be taken into account (gpio before uart0),
> also avoidng the conflict?
>

We normally do this by asking everyone to send the dts changes for
inclusion through the soc tree rather than the subsystem that contains
the driver. Why is this one in the gpio-brgl tree?

       Arnd