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@xxxxxxxxxxxxx> 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@xxxxxxxxxx>
>> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxxxx>
>> Signed-off-by: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
>
> 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
