linux-kernel - Re: [GIT PULL 1/2] asm-generic: rework PCI I/O space access

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a2=gm1OZtD+tN8Cn1RCuuOOCKFLyf6E2NzNYjeqNRq5bA@mail.gmail.com>
Date:   Fri, 17 Dec 2021 15:05:37 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Niklas Schnelle <schnelle@...ux.ibm.com>
Cc:     John Garry <john.garry@...wei.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL 1/2] asm-generic: rework PCI I/O space access

On Fri, Dec 17, 2021 at 2:52 PM Niklas Schnelle <schnelle@...ux.ibm.com> wrote:
> > The CONFIG_LEGACY_PCI should take care of a lot of it, and I
> > think that can be a single patch. I'd expand the Kconfig description
> > to explain that this also covers PCIe devices that use the legacy
> > I/O space even if they do not have a PCIe-to-PCI bridge in them.
> >
> > The introduction of CONFIG_HAS_IOPORT, plus selecting it from
> > the respective architectures makes sense as another patch, but
> > I would make that separate from the #ifdef and 'depends on'
> > changes to individual subsystems or drivers, as they are
> > better reviewed separately.
>
> Sounds like a plan. How should I mark authorship in the split up
> patches. I definitely still see you as the main author to all of this
> but of course I'll have to do quite a bit of editing and you shouldn't
> get blamed for any mistakes I make. So not sure how to handle Sign-off-
> bys and git's author property.

I don't care much either way. The two options are:

a) leave me as patch author, with my Signed-off-by, and list
    in the changelog what you have changed that wasn't in
    my version

b) list me as 'Co-developed-by' and have yourself as the patch
    author.

        Arnd