netdev - Re: [PATCH 0/8] net: mvpp2: add TX interrupts support

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]

Message-ID: <20170728170320.4e4bd683@windsurf.lan>
Date:   Fri, 28 Jul 2017 17:03:20 +0200
From:   Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, linux@....linux.org.uk,
        antoine.tenart@...e-electrons.com,
        miquel.raynal@...e-electrons.com,
        linux-arm-kernel@...ts.infradead.org, jason@...edaemon.net,
        andrew@...n.ch, sebastian.hesselbarth@...il.com,
        gregory.clement@...e-electrons.com, nadavh@...vell.com,
        hannah@...vell.com, yehuday@...vell.com, stefanc@...vell.com,
        mw@...ihalf.com
Subject: Re: [PATCH 0/8] net: mvpp2: add TX interrupts support

Hello,

On Wed, 26 Jul 2017 13:35:33 -0700 (PDT), David Miller wrote:

> >  - This series depends on the previous series sent by Antoine Ténart
> >    "net: mvpp2: MAC/GoP configuration and optional PHYs". Functionally
> >    speaking there is no real dependency, but we touch in a few areas
> >    the same piece of code, so I based my patch series on top of
> >    Antoine's.
> > 
> >  - Please do not apply the last patch of this series "arm64: dts:
> >    marvell: add TX interrupts for PPv2.2", it will be taken by the ARM
> >    mvebu maintainers.  
> 
> Please don't do things this way.
> 
> Patiently wait for Antione's series to make it into my tree, then
> submit your's.

I'll resubmit when Antoine's series is merged. The idea of submitting
my patches was to allow others to review/test them, not necessarily to
have them merged right away. Perhaps I should have marked them RFC to
make it clear that I don't expect you to merge them right away.

> Also, if we're continually going to elide the DTS file patches, just

It's the dutty of the sub-architecture maintainers to merge the DTS
changes. Merging them through your tree doesn't work really well, as
the changes might very likely conflict with other DTS changes merged by
the sub-architecture maintainer.

But it makes sense to have such DTS changes in the same patch series,
since they are really related. It's very common to have patch series
that contain patches that will be merged by different maintainers.

> don't bother adding them to the series.  That way you don't have to
> give me special instructions, and I don't have the possibility of
> making a mistake and applying it accidently.

... but OK, I won't resend them, so you don't get potentially confused
by such patches.

Thanks!

Thomas Petazzoni
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com