[PATCH 1/2] dt-bindings: mailbox: add support for referencing controllers solely by node
Conor Dooley
conor at kernel.org
Fri Dec 20 11:41:57 PST 2024
On Fri, Dec 20, 2024 at 07:51:32AM +0000, Tudor Ambarus wrote:
>
>
> On 12/19/24 6:58 PM, Conor Dooley wrote:
> > On Thu, Dec 19, 2024 at 03:42:11PM +0000, Tudor Ambarus wrote:
> >> Hi, Conor,
> >>
> >> On 12/19/24 2:11 PM, Conor Dooley wrote:
> >>>> There are mailbox clients that can discover the mailbox channel ID at
> >>>> run-time. For such cases passing the channel identifier via DT is
> >>>> redundant. Add support for referencing controllers solely by node.
> >>> I don't really get your implementation, why not just allow #mbox-cells = 0?
> >>> That's what's done for things like fixed frequency clocks that only have
> >>> a single output.
> >>
> >> Ah, indeed!
> >>
> >> instead of:
> >> of_parse_phandle(dev->of_node, "mbox", 0);
> >> I can do a:
> >> of_parse_phandle_with_args(dev->of_node, "mboxes",
> >> "#mbox-cells", 0, &of_args)
> >> where #mbox-cells = 0;
> >>
> >> Or ... can I pass NULL for cells_name and make the #mbox-cells property
> >> optional and still keeping its requirement of being at least 1?
> >
> > I think the mbox-cells = 0 approach is preferred, that property is what
> > marks it as a mailbox controller after all. Perhaps Rob or Krzysztof can
> > comment?
>
> I think using mbox-cells = 0 is better indeed. In my proposal I
> considered the list to always have a single phandle, thus a reference to
> a single mailbox controller, whereas it may be possible that clients to
> reference multiple mailbox controllers. If so, #mbox-cells needs to be
> defined in all the controllers, for consistency reasons, similar to what
> happens with fixed clocks, as you already mentioned.
Oh right, I had totally forgotten about that, that's a solid argument
for the mbox-cells = 0 approach for sure.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20241220/ab3799f7/attachment.sig>
More information about the linux-arm-kernel
mailing list