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 [off-list ref] wrote:

quoted

On Fri, Sep 19, 2025 at 7:50 AM Jassi Brar [off-list ref] wrote:

quoted

On Thu, Aug 21, 2025 at 9:12 PM Jjian Zhou [off-list ref] wrote:

.....

quoted

+#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 ?

quoted

+       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.

quoted

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.

"In this case if nobody ever reorders members you can avoid a
preprocessor macro that will get optimised away" is pointless
nitpicking. It's a strictly worse way to do the same thing.

Why bikeshed the use of container_of of all things?