From: Thierry Reding <thierry.reding@gmail.com>
To: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: jonathanh@nvidia.com, mperttunen@nvidia.com,
sudeep.holla@arm.com, talho@nvidia.com, robh@kernel.org,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
stefank@nvidia.com, krzysztof.kozlowski@linaro.org
Subject: Re: [PATCH v4 6/6] firmware: tegra: bpmp: Add support for DRAM MRQ GSCs
Date: Thu, 8 Jun 2023 18:12:46 +0200 [thread overview]
Message-ID: <ZIH9_hFsWz2kKQJy@orome> (raw)
In-Reply-To: <ZIG571modfPCnl2p@44189d9-lcedt>
[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]
On Thu, Jun 08, 2023 at 02:22:23PM +0300, Peter De Schrijver wrote:
> On Wed, Jun 07, 2023 at 05:57:39PM +0200, Thierry Reding wrote:
> > > No, on the contrary, now it's clear you can either have void __iomem *
> > > and struct gen_pool * or void *virt but not both.
> >
> > No, it's not clear. You can have one part of your driver write the
> > sram.virt field and another read dram.virt and they'll end up pointing
> > at the same memory location but with different meaning. That's why you
> > need to introduce the enumeration in order to specify which one of the
> > two you want to pick.
> >
> > And that's exactly where you start introducing the potential for
> > inconsistency: now you need to be extra careful that the enumeration and
> > the unions are set correctly. You effectively have two sources of truth
> > and they don't necessarily match. You can also end up (at least
> > theoretically) with the invalid value, so you need an extra check for
> > that too.
> >
> > You can avoid all of those inconsistencies if you reduce this to one
> > source of truth, namely the pointers that you're going to use.
> >
>
> There are 4 possible states for these pointers:
> both NULL
> both non-NULL
> sram pointer NULL, dram pointer non-NULL
> dram pointer NULL, sram pointer non-NULL
>
> So how is this one source of truth?
If you add a tristate enum you turn this into 6 possible states, how is
that any better?
My point is that the pointer contents are enough to determine which mode
we use. In either case we have to make sure that the state is consistent
so we can't end up with both non-NULL. The difference is that without
the enum we only have to make sure that the pointers are correct. With
the additional enum we also need to make sure that that value is
consistent with the values that we store in the pointers.
Anyway, time is running out, so I'll just apply the series and "fix"
this up myself.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2023-06-08 16:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 13:20 [PATCH v4 0/6] firmware: tegra: Add MRQ support for Tegra264 Peter De Schrijver
2023-05-11 13:20 ` [PATCH v4 1/6] dt-bindings: mailbox: tegra: Document Tegra264 HSP Peter De Schrijver
2023-05-11 13:20 ` [PATCH v4 2/6] mailbox: tegra: add support for Tegra264 Peter De Schrijver
2023-05-11 13:20 ` [PATCH v4 3/6] soc/tegra: fuse: Add " Peter De Schrijver
2023-05-16 9:08 ` Thierry Reding
2023-05-11 13:20 ` [PATCH v4 4/6] dt-bindings: Add support for DRAM MRQ GSCs Peter De Schrijver
2023-05-11 19:21 ` Conor Dooley
2023-05-12 6:39 ` Krzysztof Kozlowski
2023-05-16 9:12 ` Thierry Reding
2023-05-16 11:53 ` Conor Dooley
2023-05-12 6:42 ` Krzysztof Kozlowski
2023-05-11 13:20 ` [PATCH v4 5/6] dt-bindings: Add support for tegra186-bpmp " Peter De Schrijver
2023-05-11 19:25 ` Conor Dooley
2023-05-12 6:45 ` Krzysztof Kozlowski
2023-05-16 9:14 ` Thierry Reding
2023-05-11 13:20 ` [PATCH v4 6/6] firmware: tegra: bpmp: Add support for " Peter De Schrijver
2023-05-16 9:35 ` Thierry Reding
2023-05-16 9:55 ` Peter De Schrijver
2023-06-07 15:57 ` Thierry Reding
2023-06-08 9:06 ` Peter De Schrijver
2023-06-08 16:05 ` Thierry Reding
2023-06-08 11:22 ` Peter De Schrijver
2023-06-08 16:12 ` Thierry Reding [this message]
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=ZIH9_hFsWz2kKQJy@orome \
--to=thierry.reding@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mperttunen@nvidia.com \
--cc=pdeschrijver@nvidia.com \
--cc=robh@kernel.org \
--cc=stefank@nvidia.com \
--cc=sudeep.holla@arm.com \
--cc=talho@nvidia.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