[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180904161028.nh5ejrtj22r5az5e@pburton-laptop>
Date: Tue, 4 Sep 2018 09:10:28 -0700
From: Paul Burton <paul.burton@...s.com>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>,
quentin.schulz@...tlin.com
Cc: David Miller <davem@...emloft.net>, andrew@...n.ch,
ralf@...ux-mips.org, jhogan@...nel.org, robh+dt@...nel.org,
mark.rutland@....com, kishon@...com, f.fainelli@...il.com,
allan.nielsen@...rochip.com, linux-mips@...ux-mips.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, thomas.petazzoni@...tlin.com
Subject: Re: [PATCH v2 00/11] mscc: ocelot: add support for SerDes muxing
configuration
Hi Alexandre, Quentin, all,
On Tue, Sep 04, 2018 at 05:16:53PM +0200, Alexandre Belloni wrote:
> On 03/09/2018 22:09:10-0700, David Miller wrote:
> > From: Alexandre Belloni <alexandre.belloni@...tlin.com>
> > Date: Mon, 3 Sep 2018 15:45:22 +0200
> >
> > > On 03/09/2018 15:34:15+0200, Andrew Lunn wrote:
> > >> > I suggest patches 1 and 8 go through MIPS tree, 2 to 5 and 11 go through
> > >> > net while the others (6, 7, 9 and 10) go through the generic PHY subsystem.
> > >>
> > >> Hi Quentin
> > >>
> > >> Are you expecting merge conflicts? If not, it might be simpler to gets
> > >> ACKs from each maintainer, and then merge it though one tree.
> > >
> > > There are some other DT changes for this cycle so those should probably
> > > go through MIPS.
> >
> > No objection for this going through the MIPS tree, and from me:
> >
> > Acked-by: David S. Miller <davem@...emloft.net>
>
> What I meant was that 1/11 and 8/11 should go through MIPS because of
> the potential conflicts. The other patches can go through net-next as
> that will make more sense. Maybe Quentin can split the series in two,
> one for MIPS and one for net if that makes it easier for you to apply.
I'd be happy to take the .dts changes through the MIPS tree, though
looking at them won't patch 1 break bisection?
Since you remove the hsio reg entry it looks to me like
mscc_ocelot_probe() will fail with -EINVAL (which comes from
devm_ioremap_resource() with res=NULL) until patch 3.
I'd feel more comfortable merging this piecemeal if it doesn't result in
us breaking bisection for however long it takes for both the trees
involved to be merged.
Thanks,
Paul
Powered by blists - more mailing lists