On Mon, Apr 8, 2024, at 10:50, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Fri, Apr 5, 2024 at 12:10 PM Niklas Schnelle <schnelle@xxxxxxxxxxxxx> wrote:
>> In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
>> compile time. 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>
>> ---
>> Note: This patch does not depend any not-yet-mainline HAS_IOPORT changes
>> and may be merged via subsystem specific trees at your earliest
>> convenience.
>>
>> v1 - v2:
>> - Removed HAS_IOPORT dependency for I2C_PARPORT
>
> Thanks for your patch, which is now commit 53f44c1005ba6421 ("i2c: add
> HAS_IOPORT dependencies") in i2c-host/i2c/i2c-host (next-20240408).
>
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -885,6 +885,7 @@ config I2C_NPCM
>>
>> config I2C_OCORES
>> tristate "OpenCores I2C Controller"
>> + depends on HAS_IOPORT
>
> This restricts the driver to platforms that select HAS_IOPORT, while
> the driver supports both MMIO and IOPORT.
>
> At least for
> arch/xtensa/configs/audio_kc705_defconfig:CONFIG_I2C_OCORES=y
> the HAS_IOPORT dependency does not seem to be met.
>
> I think the IOPORT part in i2c-ocores.c should be protected by
> "#ifdef HAS_IOPORT" first, so the driver can still be built on platforms
> that do not support IOPORT.
Good catch! I sent a fixup for this driver now.
Arnd
