[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a9dd348fd7df95ebd5ad9cc58d57b588a18ccc9d.camel@mediatek.com>
Date: Mon, 22 Sep 2025 07:17:27 +0000
From: Jjian Zhou (周建) <Jjian.Zhou@...iatek.com>
To: "jassisinghbrar@...il.com" <jassisinghbrar@...il.com>,
"nicolas.frattaroli@...labora.com" <nicolas.frattaroli@...labora.com>
CC: "linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"wenst@...omium.org" <wenst@...omium.org>, "devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@...iatek.com>, "robh@...nel.org"
<robh@...nel.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "matthias.bgg@...il.com"
<matthias.bgg@...il.com>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH v5 2/2] mailbox: mediatek: Add mtk-vcp-mailbox driver
On Sat, 2025-09-20 at 23:02 -0500, Jassi Brar wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> On Fri, Sep 19, 2025 at 2:02 PM Nicolas Frattaroli
> <nicolas.frattaroli@...labora.com> wrote:
> >
> > On Friday, 19 September 2025 18:32:12 Central European Summer Time
> > Jassi Brar wrote:
> > > On Fri, Sep 19, 2025 at 3:31 AM Chen-Yu Tsai <wenst@...omium.org>
> > > wrote:
> > > >
> > > > On Fri, Sep 19, 2025 at 7:50 AM Jassi Brar <
> > > > jassisinghbrar@...il.com> wrote:
> > > > >
> > > > > On Thu, Aug 21, 2025 at 9:12 PM Jjian Zhou <
> > > > > jjian.zhou@...iatek.com> wrote:
> > > > >
> > > > > .....
> > > > >
> > > > > > +#include <linux/module.h>
> > > > > > +#include <linux/of.h>
> > > > > > +#include <linux/platform_device.h>
> > > > > > +#include <linux/slab.h>
> > > > > > +
> > > > > > +struct mtk_vcp_mbox_priv {
> > > > >
> > > > > Maybe 'mtk_vcp_mbox' is a more appropriate name ?
> > > > >
> > > > > > + void __iomem *base;
> > > > > > + struct device *dev;
> > > > > > + struct mbox_controller mbox;
> > > > > > + const struct mtk_vcp_mbox_cfg *cfg;
> > > > > > + struct mtk_ipi_info ipi_recv;
> > > > >
> > > > > Maybe also have "struct mbox_chan chan[1]; " so that you
> > > > > don't have to
> > > > > allocate one during the probe.
> > > > > Also if you have "struct mbox_controller mbox;" as the first
> > > > > member,
> > > > > you could simply typecast that to get this structure.
> > > > > Something like "struct mpfs_mbox" in mailbox-mpfs.c
> > > >
> > > > I read somewhere that this way of subclassing is not
> > > > recommended.
> > > > Instead the base class should explicitly not be the first
> > > > member.
> > > > And then container_of() should be used.
> > > >
> > > > I don't remember where I read this though. But I think the
> > > > explicit
> > > > container_of() is easier for understanding the intent.
> > > >
> > >
> > > And how does container_of() work ? :)
> > > typcasting the first member to its parent is the simplest form of
> > > container_of.
> > >
> > > -j
> > >
> > >
> >
> > Which is why it's completely equivalent and since code is supposed
> > to communicate meaning to humans, container_of should be used.
> >
>
> Nobody is suggesting typecasting cfg, dev or anything else.
> Typecasting between mailbox controllers is fine and arguably easier
> on
> the eyes than using a container_of.
>
> -j
OK. How about:
struct mtk_vcp_mbox *priv = (struct mtk_vcp_mbox *)chan-
>con_priv;
Thanks.
Powered by blists - more mailing lists