From: Stefano Garzarella <sgarzare@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
Cc: linux-integrity@vger.kernel.org, Peter Huewe <peterhuewe@gmx.de>,
Jason Gunthorpe <jgg@ziepe.ca>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Stuart Yoder <stuart.yoder@arm.com>,
Chu Guangqing <chuguangqing@inspur.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tpm_crb: Remove dead code from crb_map_res()
Date: Wed, 2 Sep 2026 10:54:32 +0200 [thread overview]
Message-ID: <apfg2kg2jkmooZoq@sgarzare-redhat> (raw)
In-Reply-To: <apcDfzVRBtwghIuN@kernel.org>
On Tue, Sep 01, 2026 at 07:55:27PM +0300, Jarkko Sakkinen wrote:
>On Tue, Sep 01, 2026 at 06:06:40PM +0200, Stefano Garzarella wrote:
>> On Tue, Sep 01, 2026 at 05:29:46PM +0300, Jarkko Sakkinen wrote:
>> > In all the pre-existing call sites both @iomem and @iobase_ptr are
>> > either NULL or non-NULL.
>>
>> I don't know this code, but I'm a bit worried about iobase_ptr and
>> *iobase_ptr. IIUC it is true that iobase_ptr and iores are either NULL or
>> non-NULL, but here we are removing the case where *iobase_ptr is NULL.
>>
>> Now looking at crb_map_io(), IIUC iobase_array is initialized with NULL
>> pointers and the code we are removing was the only one initializing those
>> pointers IIUC, or am I missing something?
>
>crb_map_io() sets both to non-NULL value, or leaves both as NULL.
>
>crb_map_pluton() explicitly calls both explicitly with NULL.
>
>If anything else will arrive too crb_map_res, that'd be unexpected
>input, which without this patch will go unnoticed and will lead to
>undefined behavior.
This is clear, and it's what is done in the first hunk, what is not
clear to me is why removing the second hunk.
>
>Not sure what is the argument here really.
Sorry, I should have commented in the diff:
>diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
>index ceb4100ba400..e7a61f36c58b 100644
>--- a/drivers/char/tpm/tpm_crb.c
>+++ b/drivers/char/tpm/tpm_crb.c
>@@ -570,15 +570,12 @@ static void __iomem *crb_map_res(struct device *dev, struct resource *iores,
> if (start != new_res.start)
> return IOMEM_ERR_PTR(-EINVAL);
>
>+ if ((iores == NULL) != (iobase_ptr == NULL))
>+ return IOMEM_ERR_PTR(-EINVAL);
>+
This makes sense to me.
> if (!iores)
> return devm_ioremap_resource(dev, &new_res);
>
>- if (!*iobase_ptr) {
>- *iobase_ptr = devm_ioremap_resource(dev, iores);
>- if (IS_ERR(*iobase_ptr))
>- return *iobase_ptr;
>- }
>-
This is unclear to me, here we are checking if the value stored in
iobase_ptr is NULL (so something different from the check we are adding
above, but appropriate because it only makes sense when both are
non-NULL). If the value stored in the pointer is NULL we are setting it.
Looking at the code, I can't see any other point where that values
(iobase_array[]) are initialized, but again, I don't know this code, so
I may missing something.
Stefano
> return *iobase_ptr + (new_res.start - iores->start);
> }
next prev parent reply other threads:[~2026-09-02 8:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 14:29 Jarkko Sakkinen
2026-09-01 16:06 ` Stefano Garzarella
2026-09-01 16:55 ` Jarkko Sakkinen
2026-09-02 8:54 ` Stefano Garzarella [this message]
2026-09-09 16:01 ` Jarkko Sakkinen
2026-09-23 23:57 ` 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=apfg2kg2jkmooZoq@sgarzare-redhat \
--to=sgarzare@redhat.com \
--cc=chuguangqing@inspur.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterhuewe@gmx.de \
--cc=rafael.j.wysocki@intel.com \
--cc=stuart.yoder@arm.com \
/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®