[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <28a513fd-1e7c-4772-a3c1-f312938459ed@app.fastmail.com>
Date: Tue, 04 Jul 2023 13:25:22 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Geert Uytterhoeven" <geert@...ux-m68k.org>,
"Niklas Schnelle" <schnelle@...ux.ibm.com>
Cc: "Alessandro Zummo" <a.zummo@...ertech.it>,
"Alexandre Belloni" <alexandre.belloni@...tlin.com>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"Bjorn Helgaas" <bhelgaas@...gle.com>,
Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
"Mauro Carvalho Chehab" <mchehab@...nel.org>,
"Alan Stern" <stern@...land.harvard.edu>,
"Rafael J . Wysocki" <rafael@...nel.org>,
"Paul Walmsley" <paul.walmsley@...ive.com>,
"Palmer Dabbelt" <palmer@...belt.com>,
"Albert Ou" <aou@...s.berkeley.edu>, linux-kernel@...r.kernel.org,
Linux-Arch <linux-arch@...r.kernel.org>,
linux-pci@...r.kernel.org, "Arnd Bergmann" <arnd@...nel.org>,
linux-rtc@...r.kernel.org, "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v5 30/44] rtc: add HAS_IOPORT dependencies
On Tue, Jul 4, 2023, at 10:06, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Mon, May 22, 2023 at 12:51 PM Niklas Schnelle <schnelle@...ux.ibm.com> wrote:
>> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
>> not being declared. We thus need to add HAS_IOPORT as dependency for
>> those drivers using them.
>>
>> Co-developed-by: Arnd Bergmann <arnd@...nel.org>
>> Signed-off-by: Arnd Bergmann <arnd@...nel.org>
>> Signed-off-by: Niklas Schnelle <schnelle@...ux.ibm.com>
>
> Thanks for your patch, which is now commit 8bb12adb214b2d7c ("rtc:
> add HAS_IOPORT dependencies") upstream.
>
>> --- a/drivers/rtc/Kconfig
>> +++ b/drivers/rtc/Kconfig
>> @@ -1193,7 +1195,7 @@ config RTC_DRV_MSM6242
>>
>> config RTC_DRV_BQ4802
>> tristate "TI BQ4802"
>> - depends on HAS_IOMEM
>> + depends on HAS_IOMEM && HAS_IOPORT
>> help
>> If you say Y here you will get support for the TI
>> BQ4802 RTC chip.
>
> This driver can use either iomem or ioport.
> By adding a dependency on HAS_IOPORT, it can no longer be used
> on platforms that provide HAS_IOMEM only.
You are correct, we could allow building this driver even
without IOPORT and make it use ioport_map() or an #ifdef.
> Probably the driver should be refactored to make it use only
> the accessors that are available.
Since the driver itself has no DT support, it looks like the
only way it can be used is from the sparc64/ultra45 wrapper,
but that architecture always provides CONFIG_IOPORT, so I
don't think it makes any difference in the end. We can change
this again if another user comes up.
It might be good to know whether the machine uses a memory or
I/O resource in its device tree.
Arnd
Powered by blists - more mailing lists