From: Niklas Schnelle <firstname.lastname@example.org>
To: Arnd Bergmann <email@example.com>
Cc: John Garry <firstname.lastname@example.org>,
Linus Torvalds <email@example.com>,
Linux Kernel Mailing List <firstname.lastname@example.org>
Subject: Re: [GIT PULL 1/2] asm-generic: rework PCI I/O space access
Date: Fri, 17 Dec 2021 14:52:05 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On Fri, 2021-12-17 at 14:32 +0100, Arnd Bergmann wrote:
> On Fri, Dec 17, 2021 at 2:19 PM Niklas Schnelle <firstname.lastname@example.org> wrote:
> > I've had some time to look into this a bit. As a refreshed starting
> > point I have rebased Arnd's patch to v5.16-rc5. Since I'm not sure how
> > to handle authorship and it's very early I haven't sent it as RFC but
> > it's available as a patch from my GitHub here:
> > https://gist.github.com/niklas88/a08fe76bdf9f5798500fccea6583e275
> > I have incorporated the following findings from this thread already:
> > - Added HAS_IOPORT to arch Kconfigs
> > - Added "config LEGACY_PCI" to drivers/pci/Kconfig
> > - Fixed CONFIG_HAS_IOPORT typo in asm-generic/io.h
> > - Removed LEGACY_PCI dependency of i2c-i801.
> > Which is also used in current gen Intel platforms
> > and depends on x86 anyway.
> > I have tested this on s390 with HAS_IOPORT=n and allyesconfig as well
> > as running it with defconfig. I've also been using it on my Ryzen 3990X
> > workstation with LEGACY_PCI=n for a few days. I do get about 60 MiB
> > fewer modules compared with a similar config of v5.15.8. Hard to say
> > which other systems might miss things of course.
> > I have not yet worked on the discussed IOPORT_NATIVE flag. Mostly I'm
> > wondering two things. For one it feels like that could be a separate
> > change on top since HAS_IOPORT + LEGACY_PCI is already quite big.
> > Secondly I'm wondering about good ways of identifying such drivers and
> > how much this overlaps with the ISA config flag.
> > I'd of course appreciate feedback. If you agree this is still
> > worthwhile to persue I'd think the next step would be trying to
> > refactor this into more manageable patches.
> Thanks a lot for restarting this work! I think this all looks reasonable
> (a lot was my original patch anyway, so of course I think that ;)), but
> it would be good to split it up into multiple patches.
> 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.
next prev parent reply other threads:[~2021-12-17 13:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 13:47 [GIT PULL 1/2] asm-generic: rework PCI I/O space access Arnd Bergmann
2021-07-02 13:49 ` [GIT PULL 2/2] asm-generic: Unify asm/unaligned.h around struct helper Arnd Bergmann
2021-07-02 20:13 ` pr-tracker-bot
2021-07-02 19:42 ` [GIT PULL 1/2] asm-generic: rework PCI I/O space access Linus Torvalds
2021-07-03 12:12 ` Arnd Bergmann
2021-07-05 10:06 ` Arnd Bergmann
2021-08-03 9:46 ` John Garry
2021-08-03 10:06 ` Arnd Bergmann
2021-08-03 11:23 ` John Garry
2021-08-03 12:15 ` Arnd Bergmann
2021-08-04 7:55 ` John Garry
2021-08-04 8:52 ` Arnd Bergmann
2021-08-10 9:19 ` John Garry
2021-08-10 11:33 ` Arnd Bergmann
2021-09-03 8:31 ` Niklas Schnelle
2021-12-17 13:19 ` Niklas Schnelle
2021-12-17 13:32 ` Arnd Bergmann
2021-12-17 13:52 ` Niklas Schnelle [this message]
2021-12-17 14:05 ` Arnd Bergmann
2021-12-17 14:27 ` John Garry
2021-12-17 14:32 ` Arnd Bergmann
2021-12-17 15:27 ` John Garry
2021-12-17 15:55 ` Arnd Bergmann
2021-12-17 16:30 ` John Garry
2021-12-20 9:27 ` Niklas Schnelle
2021-12-21 16:48 ` John Garry
2021-12-21 16:57 ` Niklas Schnelle
2021-12-19 14:23 ` David Laight
2021-12-21 16:21 ` John Garry
2021-07-05 12:40 ` Niklas Schnelle
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.