Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-431-g1d6a3ebb56-fm-20230511.001-g1d6a3ebb
Mime-Version: 1.0
Message-Id: <440855f4-897c-4597-bbe6-7c5f295f616a@app.fastmail.com>
In-Reply-To: <2c03973e-0635-4dbb-a1df-bfda8cbee161@rowland.harvard.edu>
References: <20230516110038.2413224-1-schnelle@linux.ibm.com>
 <20230516110038.2413224-36-schnelle@linux.ibm.com>
 <2023051643-overtime-unbridle-7cdd@gregkh>
 <2c03973e-0635-4dbb-a1df-bfda8cbee161@rowland.harvard.edu>
Date:   Wed, 17 May 2023 14:17:58 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Alan Stern" <stern@rowland.harvard.edu>,
        "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc:     "Niklas Schnelle" <schnelle@linux.ibm.com>,
        "Bjorn Helgaas" <bhelgaas@google.com>,
        =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>,
        "Mauro Carvalho Chehab" <mchehab@kernel.org>,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        "Geert Uytterhoeven" <geert@linux-m68k.org>,
        "Paul Walmsley" <paul.walmsley@sifive.com>,
        "Palmer Dabbelt" <palmer@dabbelt.com>,
        "Albert Ou" <aou@eecs.berkeley.edu>, linux-kernel@vger.kernel.org,
        Linux-Arch <linux-arch@vger.kernel.org>,
        linux-pci@vger.kernel.org, "Arnd Bergmann" <arnd@kernel.org>,
        linux-usb@vger.kernel.org
Subject: Re: [PATCH v4 35/41] usb: uhci: handle HAS_IOPORT dependencies
Content-Type: text/plain
Precedence: bulk

On Tue, May 16, 2023, at 22:17, Alan Stern wrote:
> On Tue, May 16, 2023 at 06:29:56PM +0200, Greg Kroah-Hartman wrote:
>> On Tue, May 16, 2023 at 01:00:31PM +0200, Niklas Schnelle wrote:
>
>> I'm confused now.
>> 
>> So if CONFIG_HAS_IOPORT is enabled, wonderful, all is good.
>> 
>> But if it isn't, then these are just no-ops that do nothing?  So then
>> the driver will fail to work?  Why have these stubs at all?
>> 
>> Why not just not build the driver at all if this option is not enabled?
>
> I should add something to my previous email.  This particular section of 
> code is protected by:
>
> #ifndef CONFIG_USB_UHCI_SUPPORT_NON_PCI_HC
> /* Support PCI only */
>
> So it gets used only in cases where the driver supports just a PCI bus 
> -- no other sorts of non-PCI on-chip devices.  But the preceding patch 
> in this series changes the Kconfig file to say:
>
>  config USB_UHCI_HCD
> 	tristate "UHCI HCD (most Intel and VIA) support"
> 	depends on (USB_PCI && HAS_IOPORT) || USB_UHCI_SUPPORT_NON_PCI_HC
>
> As a result, when the configuration includes support only for PCI 
> controllers the driver won't get built unless HAS_IOPORT is set.  Thus 
> the no-op case (in this part of the code) can't arise.

Indeed, that makes sense.

> Which is a long-winded way of saying that you're right; the UHCI_IN() 
> and UHCI_OUT() wrappers aren't needed in this part of the driver.  I 
> guess Niklas put them in either for consistency with the rest of the 
> code or because it didn't occur to him that they could be omitted.  (And 
> I didn't spot it either.)

It's probably less confusing to leave out the PCI-only part of
the patch then and only modify the generic portion.

      Arnd