All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: firmware: arm,scmi: Restrict protocol child node properties
Date: Thu, 26 Jan 2023 09:43:44 +0000	[thread overview]
Message-ID: <Y9JLUIioxFPn4BS0@e120937-lin> (raw)
In-Reply-To: <20230125141113.kkbowopusikuogx6@bogus>

On Wed, Jan 25, 2023 at 02:11:13PM +0000, Sudeep Holla wrote:
> On Wed, Jan 25, 2023 at 01:43:48PM +0000, Cristian Marussi wrote:
> > so now that the catch-all protocol@ patternProperty is gone in favour
> > of the 'protocol-node' definition and $refs, does that mean that any
> > current and future SCMI officially published protocol <N> has to be
> > added to the above explicit protocol list, even though it does not
> > have any special additional required property beside reg ?
> > (like protocol@18 above...)
> >
> 
> If there are no consumers, should we just not add and deal with it
> entirely within the kernel. I know we rely today on presence of node
> before we initialise, but hey we have exception for system power protocol
> for other reasons, why not add this one too.
> 
> In short we shouldn't have to add a node if there are no consumers. It
> was one of the topic of discussion initially when SCMI binding was added
> and they exist only for the consumers otherwise we don't need it as
> everything is discoverable from the interface.

It is fine for me the no-consumers/no-node argument (which anyway would
require a few changes in the core init logic anyway to work this way...),
BUT is it not that ANY protocol (even future-ones) does have, potentially,
consumers indeed, since each protocol-node can potentially have a dedicated
channel and related DT channel-descriptor ? (when multiple channels are
allowed by the transport)

I mean, as an example, you dont strictly need protos 0x18/0x12 nodes for
anything (if we patch the core init as said) UNLESS you want to dedicate
a channel to those protocols; so I'm just checking here if these kind of
scenarios will still be allowed with this binding change, or if I am
missing something.

Thanks,
Cristian


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: firmware: arm,scmi: Restrict protocol child node properties
Date: Thu, 26 Jan 2023 09:43:44 +0000	[thread overview]
Message-ID: <Y9JLUIioxFPn4BS0@e120937-lin> (raw)
In-Reply-To: <20230125141113.kkbowopusikuogx6@bogus>

On Wed, Jan 25, 2023 at 02:11:13PM +0000, Sudeep Holla wrote:
> On Wed, Jan 25, 2023 at 01:43:48PM +0000, Cristian Marussi wrote:
> > so now that the catch-all protocol@ patternProperty is gone in favour
> > of the 'protocol-node' definition and $refs, does that mean that any
> > current and future SCMI officially published protocol <N> has to be
> > added to the above explicit protocol list, even though it does not
> > have any special additional required property beside reg ?
> > (like protocol@18 above...)
> >
> 
> If there are no consumers, should we just not add and deal with it
> entirely within the kernel. I know we rely today on presence of node
> before we initialise, but hey we have exception for system power protocol
> for other reasons, why not add this one too.
> 
> In short we shouldn't have to add a node if there are no consumers. It
> was one of the topic of discussion initially when SCMI binding was added
> and they exist only for the consumers otherwise we don't need it as
> everything is discoverable from the interface.

It is fine for me the no-consumers/no-node argument (which anyway would
require a few changes in the core init logic anyway to work this way...),
BUT is it not that ANY protocol (even future-ones) does have, potentially,
consumers indeed, since each protocol-node can potentially have a dedicated
channel and related DT channel-descriptor ? (when multiple channels are
allowed by the transport)

I mean, as an example, you dont strictly need protos 0x18/0x12 nodes for
anything (if we patch the core init as said) UNLESS you want to dedicate
a channel to those protocols; so I'm just checking here if these kind of
scenarios will still be allowed with this binding change, or if I am
missing something.

Thanks,
Cristian


  parent reply	other threads:[~2023-01-26  9:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-24 22:20 [PATCH] dt-bindings: firmware: arm,scmi: Restrict protocol child node properties Rob Herring
2023-01-24 22:20 ` Rob Herring
2023-01-25 12:42 ` Sudeep Holla
2023-01-25 12:42   ` Sudeep Holla
2023-01-25 13:43 ` Cristian Marussi
2023-01-25 13:43   ` Cristian Marussi
2023-01-25 14:11   ` Sudeep Holla
2023-01-25 14:11     ` Sudeep Holla
2023-01-25 15:40     ` Cristian Marussi
2023-01-25 15:40       ` Cristian Marussi
2023-01-25 17:30     ` Rob Herring
2023-01-25 17:30       ` Rob Herring
2023-01-26  9:43     ` Cristian Marussi [this message]
2023-01-26  9:43       ` Cristian Marussi
2023-01-26 14:46       ` Sudeep Holla
2023-01-26 14:46         ` Sudeep Holla
2023-01-26 15:25         ` Rob Herring
2023-01-26 15:25           ` Rob Herring
2023-01-26 17:04           ` Sudeep Holla
2023-01-26 17:04             ` Sudeep Holla
2023-01-27 18:52             ` Rob Herring
2023-01-27 18:52               ` Rob Herring
2023-02-06 10:47               ` Sudeep Holla
2023-02-06 10:47                 ` Sudeep Holla
2023-02-06 17:22                 ` Rob Herring
2023-02-06 17:22                   ` Rob Herring

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=Y9JLUIioxFPn4BS0@e120937-lin \
    --to=cristian.marussi@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sudeep.holla@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.