From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Boris Brezillon <boris.brezillon@collabora.com>,
Steven Price <steven.price@arm.com>,
Liviu Dudau <liviu.dudau@arm.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Chanwoo Choi <cw00.choi@samsung.com>, Kees Cook <kees@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
Chia-I Wu <olvaffe@gmail.com>, Chen-Yu Tsai <wenst@chromium.org>,
kernel@collabora.com, dri-devel@lists.freedesktop.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-pm@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3 05/10] mailbox: add MediaTek GPUEB IPI mailbox
Date: Mon, 22 Sep 2025 14:59:43 +0200 [thread overview]
Message-ID: <1933660.tdWV9SEqCh@workhorse> (raw)
In-Reply-To: <CABb+yY0_TZC0Dd3Rue=6Am4=Urs8hdkaa6RE=42t58SYUsLV0w@mail.gmail.com>
On Sunday, 21 September 2025 07:00:59 Central European Summer Time Jassi Brar wrote:
> On Wed, Sep 17, 2025 at 7:23 AM Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com> wrote:
> ....
>
> > +#define MBOX_CTL_TX_STS 0x0000
> > +#define MBOX_CTL_IRQ_SET 0x0004
> > +#define MBOX_CTL_IRQ_CLR 0x0074
> > +#define MBOX_CTL_RX_STS 0x0078
> > +
> 1) Please don't pollute the global namespace. Make these something
> like MBOX_MTK_GPUEB_xxx. Here and elsewhere.
I tend to disagree. These don't pollute the global namespace, they're
defined as part of the file, so only pollute its local scope. I'm not
going to make 25 character long symbols just to work around an issue
that doesn't exist, but may exist in the unlikely future where
mailbox.h gets its own symbol named precisely the same way but
whoever adds it doesn't try to compile test every single mailbox
driver to make sure they didn't break anything.
> 2) You don't write short values, so maybe just 0x04, 0x04 0x74 and 0x78.
>
>
> > +#define MBOX_FULL BIT(0) /* i.e. we've received data */
> > +#define MBOX_CLOGGED BIT(1) /* i.e. the channel is shutdown */
> > +
> This is confusing. CLOGGED usually means malfunction, but it seems you
> want to call it STOPPED or UNINIT?
I don't agree that "CLOGGED usually means malfunction". To clog something
is to impede its flow, which in this case is the correct terminology to
refer to what's happened to the channel. "UNINIT" is wrong, it's initialised
properly. "STOPPED" is also wrong, it's not stopped, it still sends, it just
won't pass it on through.
>
>
> > +#define MBOX_MAX_RX_SIZE 32 /* in bytes */
> > +
> > +struct mtk_gpueb_mbox {
> > + struct device *dev;
> > + struct clk *clk;
> > + void __iomem *mbox_mmio;
> > + void __iomem *mbox_ctl;
> > + struct mbox_controller mbox;
> > + struct mtk_gpueb_mbox_chan *ch;
> > + int irq;
> > + const struct mtk_gpueb_mbox_variant *v;
> > +};
> Other structures have kernel-doc, so why not here too?
> ...
>
Because fully documenting all internal structures is not required
for acceptance and writing redundant explanations for members that
can be understood from name and context is redundant.
> > +
> > +static int mtk_gpueb_mbox_send_data(struct mbox_chan *chan, void *data)
> > +{
> > + struct mtk_gpueb_mbox_chan *ch = chan->con_priv;
> > + int i;
> > + u32 *values = data;
> > +
> maybe order in decreasing lengths ?
>
>
> > +
> > + /*
> > + * We don't want any fancy nonsense, just write the 32-bit values in
> > + * order. memcpy_toio/__iowrite32_copy don't work here, because fancy.
> > + */
> >
> Please make the comment technical. Currently it just expresses your
> distaste for fancy :)
>
Then I will have to make an assertive statement about memory semantics
of those two calls and how they differ from writel, which I don't want
to do, because it would likely be inaccurate or not the full picture
as those two calls can do a variety of things depending on the platform.
Saying that I want 32-bit writes in order is much simpler than explaining
how the two mentioned calls some well-meaning future developer may wish
to replace this with don't do that.
> > + for (i = 0; i < ch->c->tx_len; i += 4)
> > + writel(values[i / 4], ch->ebm->mbox_mmio + ch->c->tx_offset + i);
> > +
>
> ...
> > +
> > +static struct mbox_chan *
> > +mtk_gpueb_mbox_of_xlate(struct mbox_controller *mbox,
> > + const struct of_phandle_args *sp)
> > +{
> > + struct mtk_gpueb_mbox *ebm = dev_get_drvdata(mbox->dev);
> > +
> > + if (!sp->args_count)
> > + return ERR_PTR(-EINVAL);
> > +
> > + if (sp->args[0] >= ebm->v->num_channels)
> > + return ERR_PTR(-ECHRNG);
> > +
> > + return &mbox->chans[sp->args[0]];
> > +}
> >
> Just use the default of_mbox_index_xlate()
>
> ....
> > +
> > + for (i = 0; i < ebm->v->num_channels; i++) {
>
> You make this block a bit cleaner by using a temporary variable
> echan = &ebm->ch[i];
> and using echan instead of ebm->ch[i] a dozen times below.
>
> > + ebm->ch[i].c = &ebm->v->channels[i];
> > + if (ebm->ch[i].c->rx_len > MBOX_MAX_RX_SIZE) {
> > + dev_err(ebm->dev, "Channel %s RX size (%d) too large\n",
> > + ebm->ch[i].c->name, ebm->ch[i].c->rx_len);
> > + return -EINVAL;
> > + }
> > + ebm->ch[i].full_name = devm_kasprintf(ebm->dev, GFP_KERNEL, "%s:%s",
> > + dev_name(ebm->dev), ebm->ch[i].c->name);
> > + if (!ebm->ch[i].full_name)
> > + return -ENOMEM;
> > +
> > + ebm->ch[i].ebm = ebm;
> > + ebm->ch[i].num = i;
> > + spin_lock_init(&ebm->mbox.chans[i].lock);
> > + ebm->mbox.chans[i].con_priv = &ebm->ch[i];
> > + atomic_set(&ebm->ch[i].rx_status, MBOX_CLOGGED);
> > + }
> > +
>
>
> -j
>
next prev parent reply other threads:[~2025-09-22 13:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-17 12:22 [PATCH v3 00/10] MT8196 GPU Frequency/Power Control Support Nicolas Frattaroli
2025-09-17 12:22 ` [PATCH v3 01/10] dt-bindings: gpu: mali-valhall-csf: add mediatek,mt8196-mali variant Nicolas Frattaroli
2025-09-17 15:02 ` Rob Herring (Arm)
2025-09-18 0:30 ` Krzysztof Kozlowski
2025-09-18 14:01 ` Nicolas Frattaroli
2025-09-19 4:28 ` Krzysztof Kozlowski
2025-09-19 10:08 ` Nicolas Frattaroli
2025-09-17 12:22 ` [PATCH v3 02/10] dt-bindings: devfreq: add mt8196-gpufreq binding Nicolas Frattaroli
2025-09-18 0:31 ` Krzysztof Kozlowski
2025-09-17 12:22 ` [PATCH v3 03/10] dt-bindings: sram: Add compatible for mediatek,mt8196-gpufreq-sram Nicolas Frattaroli
2025-09-17 12:44 ` AngeloGioacchino Del Regno
2025-09-17 12:22 ` [PATCH v3 04/10] dt-bindings: mailbox: Add MT8196 GPUEB Mailbox Nicolas Frattaroli
2025-09-17 12:46 ` AngeloGioacchino Del Regno
2025-09-17 12:22 ` [PATCH v3 05/10] mailbox: add MediaTek GPUEB IPI mailbox Nicolas Frattaroli
2025-09-17 12:50 ` AngeloGioacchino Del Regno
2025-09-21 5:00 ` Jassi Brar
2025-09-22 12:59 ` Nicolas Frattaroli [this message]
2025-09-22 13:19 ` Mark Brown
2025-09-17 12:22 ` [PATCH v3 06/10] drm/panthor: call into devfreq for current frequency Nicolas Frattaroli
2025-09-17 12:22 ` [PATCH v3 07/10] drm/panthor: devfreq: make get_dev_status use get_cur_freq Nicolas Frattaroli
2025-09-17 12:22 ` [PATCH v3 08/10] drm/panthor: devfreq: add pluggable devfreq providers Nicolas Frattaroli
2025-09-17 12:22 ` [PATCH v3 09/10] drm/panthor: add no_clocks soc_data member for MT8196 Nicolas Frattaroli
2025-09-17 12:43 ` AngeloGioacchino Del Regno
2025-09-17 12:22 ` [PATCH v3 10/10] drm/panthor: add support for MediaTek MFlexGraphics Nicolas Frattaroli
2025-09-17 13:28 ` [PATCH v3 00/10] MT8196 GPU Frequency/Power Control Support Ulf Hansson
2025-09-17 15:44 ` Nicolas Frattaroli
2025-09-18 15:26 ` Ulf Hansson
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=1933660.tdWV9SEqCh@workhorse \
--to=nicolas.frattaroli@collabora.com \
--cc=airlied@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=boris.brezillon@collabora.com \
--cc=conor+dt@kernel.org \
--cc=cw00.choi@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavoars@kernel.org \
--cc=jassisinghbrar@gmail.com \
--cc=kees@kernel.org \
--cc=kernel@collabora.com \
--cc=krzk+dt@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthias.bgg@gmail.com \
--cc=mripard@kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=olvaffe@gmail.com \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tzimmermann@suse.de \
--cc=wenst@chromium.org \
/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;
as well as URLs for NNTP newsgroup(s).