On Thu, 2024-04-04 at 13:17 +0200, Arnd Bergmann wrote:
> On Thu, Apr 4, 2024, at 12:58, Niklas Schnelle wrote:
> > diff --git a/drivers/char/tpm/tpm_infineon.c b/drivers/char/tpm/tpm_infineon.c
> > index 9c924a1440a9..99c6e565ec8d 100644
> > --- a/drivers/char/tpm/tpm_infineon.c
> > +++ b/drivers/char/tpm/tpm_infineon.c
> > @@ -26,7 +26,9 @@
> > #define TPM_MAX_TRIES 5000
> > #define TPM_INFINEON_DEV_VEN_VALUE 0x15D1
> >
> > +#ifdef CONFIG_HAS_IOPORT
> > #define TPM_INF_IO_PORT 0x0
> > +#endif
> > #define TPM_INF_IO_MEM 0x1
>
> I think hiding this definition in this version of a patch
> results in a build failure because of the assignment that
> you are not stubbing out:
>
> /* read IO-ports through PnP */
> if (pnp_port_valid(dev, 0) && pnp_port_valid(dev, 1) &&
> !(pnp_port_flags(dev, 0) & IORESOURCE_DISABLED)) {
> tpm_dev.iotype = TPM_INF_IO_PORT;
>
> I don't know what changed since the earlier versions I tested,
> or if I just missed it, but I think you either have to remove
> the #ifdef above or add another one in tpm_inf_pnp_probe().
>
> Arnd
Good find! I do see the same #ifdef in v5 but maybe something else
changed. I think this was also hidden during both my local test builds
and kernel test robot because of the PNP -> ACPI || ISA dependency
which I think implies HAS_IOPORT. So unless I'm missing something we
can't currently get here with HAS_IOPORT=n. Maybe that changed?
I'm now thinking maybe keeping TPM_INF_IO_PORT is the cleaner choice.
It saves us 4 lines of #ifdeffery at the cost of one sometimes "unused"
define.
Thanks,
Niklas
