From: Sudeep Holla <sudeep.holla@arm.com>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: Rob Herring <robh@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
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: Wed, 25 Jan 2023 14:11:13 +0000 [thread overview]
Message-ID: <20230125141113.kkbowopusikuogx6@bogus> (raw)
In-Reply-To: <Y9EyB+OO7MyGy20w@e120937-lin>
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.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-01-25 14:12 UTC|newest]
Thread overview: 13+ 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-25 12:42 ` Sudeep Holla
2023-01-25 13:43 ` Cristian Marussi
2023-01-25 14:11 ` Sudeep Holla [this message]
2023-01-25 15:40 ` Cristian Marussi
2023-01-25 17:30 ` Rob Herring
2023-01-26 9:43 ` Cristian Marussi
2023-01-26 14:46 ` Sudeep Holla
2023-01-26 15:25 ` Rob Herring
2023-01-26 17:04 ` Sudeep Holla
2023-01-27 18:52 ` Rob Herring
2023-02-06 10:47 ` Sudeep Holla
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=20230125141113.kkbowopusikuogx6@bogus \
--to=sudeep.holla@arm.com \
--cc=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 \
/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