From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Arnd Bergmann <arnd@kernel.org>, Peter Huewe <peterhuewe@gmx.de>,
Jarkko Sakkinen <jarkko@kernel.org>
Cc: linux-integrity@vger.kernel.org,
Heiko Carstens <hca@linux.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] char: tpm: handle HAS_IOPORT dependencies
Date: Thu, 04 Apr 2024 17:41:45 +0200 [thread overview]
Message-ID: <4cdb6399d803d37a883d1a2fbe119c0a14610106.camel@linux.ibm.com> (raw)
In-Reply-To: <95a63afe-ccd7-4551-86af-00b7fb0d8ff9@app.fastmail.com>
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
next prev parent reply other threads:[~2024-04-04 15:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 10:58 [PATCH 0/1] char: tpm: Handle " Niklas Schnelle
2024-04-04 10:58 ` [PATCH 1/1] char: tpm: handle " Niklas Schnelle
2024-04-04 11:17 ` Arnd Bergmann
2024-04-04 15:22 ` Jarkko Sakkinen
2024-04-04 15:41 ` Niklas Schnelle [this message]
2024-04-04 15:56 ` Arnd Bergmann
2024-04-05 9:23 ` Niklas Schnelle
2024-04-05 21:02 ` Arnd Bergmann
2024-04-04 15:19 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4cdb6399d803d37a883d1a2fbe119c0a14610106.camel@linux.ibm.com \
--to=schnelle@linux.ibm.com \
--cc=arnd@kernel.org \
--cc=hca@linux.ibm.com \
--cc=jarkko@kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterhuewe@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®