linux-kernel - Re: [PATCH v2 00/11] mscc: ocelot: add support for SerDes muxing configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 5 Sep 2018 11:07:50 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Paul Burton <paul.burton@...s.com>
Cc:     Quentin Schulz <quentin.schulz@...tlin.com>,
        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

On 04/09/2018 16:03:51-0700, Paul Burton wrote:
> Well, it sounded like David is OK with this all going through the MIPS
> tree, though we'd need an ack for the PHY parts.
> 
> Alternatively I'd be happy for the DT changes to go through the net-next
> tree, which may make more sense given that the .dts changes are pretty
> trivial in comparison with the driver changes. If David wants to do that
> then for patches 1 & 8:
> 
>     Acked-by: Paul Burton <paul.burton@...s.com>
> 
> Either way there may be conflicts for ocelot.dtsi when it comes to
> merging to master, but they should be simple to resolve. It seems
> Wolfram already took your DT changes for I2C so there's probably going
> to be multiple trees updating that file this cycle already anyway.
> 

Actually, I think Wolfram meant that he took the bindings so you can
take the DT patches for i2c.

> Ideally I'd say "don't break bisection" but that's sort of a separate
> issue here since even if you restructure your series to do that it would
> still need to go through one tree. For example you could adjust
> mscc_ocelot_probe() to handle either the reg property or the syscon,
> then adjust the DT to use the syscon, then remove the code dealing with
> the reg property, and I'd consider that a good idea anyway but it would
> still probably all need to go through one tree to make sure things get
> merged in the right order & avoid breaking bisection.
> 

I don't really think bisection is important at this stage but if you
don't want to break it, then I guess it makes more sense to have the
whole series through net.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com