linux-kernel - Re: [PATCH 0/3] net: ethernet: atheros: atlx: Use PCI generic definitions instead of private duplicates

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAErSpo6iRVWU-yL5CRF_GEY7CWg5iV=Jw0BrdNV4h3Jvh5AuAw@mail.gmail.com>
Date:   Fri, 21 Jun 2019 13:12:58 -0500
From:   Bjorn Helgaas <bhelgaas@...gle.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Puranjay Mohan <puranjay12@...il.com>,
        Jay Cliburn <jcliburn@...il.com>,
        Chris Snook <chris.snook@...il.com>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Bjorn Helgaas <bjorn@...gaas.com>,
        netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        Linux PCI <linux-pci@...r.kernel.org>
Subject: Re: [PATCH 0/3] net: ethernet: atheros: atlx: Use PCI generic
 definitions instead of private duplicates

On Fri, Jun 21, 2019 at 12:27 PM Joe Perches <joe@...ches.com> wrote:
>
> (adding the atlx maintainers to cc)
>
> On Fri, 2019-06-21 at 12:11 -0500, Bjorn Helgaas wrote:
> > On Fri, Jun 21, 2019 at 11:39 AM Puranjay Mohan <puranjay12@...il.com> wrote:
> > > This patch series removes the private duplicates of PCI definitions in
> > > favour of generic definitions defined in pci_regs.h.
> > >
> > > Puranjay Mohan (3):
> > >   net: ethernet: atheros: atlx: Rename local PCI defines to generic
> > >     names
> > >   net: ethernet: atheros: atlx: Include generic PCI definitions
> > >   net: ethernet: atheros: atlx: Remove unused and private PCI
> > >     definitions
> > >
> > >  drivers/net/ethernet/atheros/atlx/atl2.c | 5 +++--
> > >  drivers/net/ethernet/atheros/atlx/atl2.h | 2 --
> > >  drivers/net/ethernet/atheros/atlx/atlx.h | 1 -
> > >  3 files changed, 3 insertions(+), 5 deletions(-)
> >
> > Let's slow this down a little bit; I'm afraid we're going to overwhelm folks.
>
> I generally disagree.
>
> Consolidation of these sorts of changes are generally
> better done treewide all at once, posted as a series to
> a list and maintainers allowing time (weeks to months)
> for the specific maintainers to accept them and then
> whatever remainder exists reposted and possibly applied
> by an overall maintainer (e.g.: Dave M)
>
> > Before posting more to LKML/netdev, how about we first complete a
> > sweep of all the drivers to see what we're getting into.  It could be
> > that this will end up being more churn than it's worth.
>
> Also doubtful.
>
> Subsystem specific local PCI #defines without generic
> naming is poor style and makes treewide grep and
> refactoring much more difficult.

Don't worry, we have the same objectives.  I totally agree that local
#defines are a bad thing, which is why I proposed this project in the
first place.

I'm just saying that this is a "first-patch" sort of learning project
and I think it'll avoid some list spamming and discouragement if we
can figure out the scope and shake out some of the teething problems
ahead of time.  I don't want to end up with multiple versions of
dozens of little 2-3 patch series posted every week or two.  I'd
rather be able to deal with a whole block of them at one time.

> The atlx maintainers should definitely have been cc'd
> on these patches.
>
> Jay Cliburn <jcliburn@...il.com> (maintainer:ATLX ETHERNET DRIVERS)
> Chris Snook <chris.snook@...il.com> (maintainer:ATLX ETHERNET DRIVERS)
>
> Puranjay, can you please do a few things more here:
>
> 1: Make sure you use scripts/get_maintainer.pl to cc the
>    appropriate people.
>
> 2: Show that you compiled the object files and verified
>    where possible that there are no object file changes.

Do you have any pointers for the best way to do this?  Is it as simple
as comparing output of "objdump -d"?

> 3: State that there are no object changes in the proposed
>    commit log.

Thanks for the additional tips.

Bjorn