Received-SPF: pass (google.com: domain of linux-kernel+bounces-130538-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Feedback-ID: i36794607:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542
Precedence: bulk
MIME-Version: 1.0
Message-Id: <3dd44bdf-7950-4822-ac7c-97fc1bdcf5d7@app.fastmail.com>
In-Reply-To: <20240403130243.41a65a767f03fd7c4d8dabf8@linux-foundation.org>
References: <20240403132547.762429-1-schnelle@linux.ibm.com>
 <20240403130243.41a65a767f03fd7c4d8dabf8@linux-foundation.org>
Date: Wed, 03 Apr 2024 22:10:48 +0200
From: "Arnd Bergmann" <arnd@kernel.org>
To: "Andrew Morton" <akpm@linux-foundation.org>,
 "Niklas Schnelle" <schnelle@linux.ibm.com>
Cc: "Heiko Carstens" <hca@linux.ibm.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/1] kgdb: Handle HAS_IOPORT dependencies
Content-Type: text/plain

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