On Fri, 2021-12-17 at 14:32 +0100, Arnd Bergmann wrote: > On Fri, Dec 17, 2021 at 2:19 PM Niklas Schnelle <schnelle@xxxxxxxxxxxxx> 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. Yes definitely. > > 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. > > Arnd 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.
