[PATCH 0/1] kgdb: Handle HAS_IOPORT dependencies

Niklas Schnelle posted 1 patch 1 year, 10 months ago
lib/Kconfig.kgdb | 1 +
1 file changed, 1 insertion(+)
[PATCH 0/1] kgdb: Handle HAS_IOPORT dependencies
Posted by Niklas Schnelle 1 year, 10 months ago
Hi Andrew,

This is a follow up in my ongoing effort of making inb()/outb() and
similar I/O port accessors compile-time optional. Previously I sent this
as a treewide series titled "treewide: Remove I/O port accessors for
HAS_IOPORT=n" with the latest being its 5th version[0]. With a significant
subset of patches merged I've changed over to per-subsystem series. These
series are stand alone and should be merged via the relevant tree such
that with all subsystems complete we can follow this up with the final
patch that will make the I/O port accessors compile-time optional.

The current state of the full series with changes to the remaining
subsystems and the aforementioned final patch can be found for your
convenience on my git.kernel.org tree in the has_ioport_v6 branch[1] with
signed tags. As for compile-time vs runtime see Linus' reply to my first
attempt[2].

Thanks,
Niklas

[0] https://lore.kernel.org/all/20230522105049.1467313-1-schnelle@linux.ibm.com/
[1] https://git.kernel.org/pub/scm/linux/kernel/git/niks/linux.git/log/?h=has_ioport_v6
[2] https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/

Niklas Schnelle (1):
  kgdb: add HAS_IOPORT dependency

 lib/Kconfig.kgdb | 1 +
 1 file changed, 1 insertion(+)

-- 
2.40.1
Re: [PATCH 0/1] kgdb: Handle HAS_IOPORT dependencies
Posted by Andrew Morton 1 year, 10 months ago
On Wed,  3 Apr 2024 15:25:46 +0200 Niklas Schnelle <schnelle@linux.ibm.com> wrote:

> Hi Andrew,
> 
> This is a follow up in my ongoing effort of making inb()/outb() and
> similar I/O port accessors compile-time optional. Previously I sent this
> as a treewide series titled "treewide: Remove I/O port accessors for
> HAS_IOPORT=n" with the latest being its 5th version[0]. With a significant
> subset of patches merged I've changed over to per-subsystem series. These
> series are stand alone and should be merged via the relevant tree such
> that with all subsystems complete we can follow this up with the final
> patch that will make the I/O port accessors compile-time optional.
> 
> The current state of the full series with changes to the remaining
> subsystems and the aforementioned final patch can be found for your
> convenience on my git.kernel.org tree in the has_ioport_v6 branch[1] with
> signed tags. As for compile-time vs runtime see Linus' reply to my first
> attempt[2].

Thanks.

I'm not fully understanding the timing.  Am I correct in believing that the 44
other patches are not dependent upon this one?  And that this patch is not
dependent upon those 44?
Re: [PATCH 0/1] kgdb: Handle HAS_IOPORT dependencies
Posted by Arnd Bergmann 1 year, 10 months ago
On Wed, Apr 3, 2024, at 22:02, Andrew Morton wrote:
> On Wed,  3 Apr 2024 15:25:46 +0200 Niklas Schnelle  <schnelle@linux.ibm.com> wrote:
>> 
>> This is a follow up in my ongoing effort of making inb()/outb() and
>> similar I/O port accessors compile-time optional. Previously I sent this
>> as a treewide series titled "treewide: Remove I/O port accessors for
>> HAS_IOPORT=n" with the latest being its 5th version[0]. With a significant
>> subset of patches merged I've changed over to per-subsystem series. These
>> series are stand alone and should be merged via the relevant tree such
>> that with all subsystems complete we can follow this up with the final
>> patch that will make the I/O port accessors compile-time optional.
>> 
>> The current state of the full series with changes to the remaining
>> subsystems and the aforementioned final patch can be found for your
>> convenience on my git.kernel.org tree in the has_ioport_v6 branch[1] with
>> signed tags. As for compile-time vs runtime see Linus' reply to my first
>> attempt[2].
>
> I'm not fully understanding the timing.  Am I correct in believing that the 44
> other patches are not dependent upon this one?  And that this patch is not
> dependent upon those 44?

Correct, there is just one last patch that depends on everything
else going in first.

      Arnd