mbox series

[0/3] Add mediatek,gce-events definition to mediatek,gce-mailbox bindings

Message ID 20231218083604.7327-1-jason-jh.lin@mediatek.com
Headers show
Series Add mediatek,gce-events definition to mediatek,gce-mailbox bindings | expand

Message

Jason-JH Lin (林睿祥) Dec. 18, 2023, 8:36 a.m. UTC
From: Jason-jh Lin <jason-jh.lin@mediatek.corp-partner.google.com>

Since mediatek,gce-events property is a HW event signal from GCE,
it should be defined in mediatek,gce-mailbox.yaml.

Change the description of mediatek,gce-events property existed in
other bindings to reference mediatek,gce-mailbox.yaml.

Jason-JH.Lin (3):
  dt-bindings: mailbox: mediatek,gce-mailbox: Add mediatek,gce-events
    definition
  dt-bindings: media: mediatek-mdp: Change the description of gce-events
  dt-bindings: soc: mediatek: Change the description of gce-events

 .../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml  | 7 +++++++
 .../devicetree/bindings/media/mediatek,mdp3-rdma.yaml      | 5 +----
 .../devicetree/bindings/media/mediatek,mdp3-rsz.yaml       | 5 +----
 .../devicetree/bindings/media/mediatek,mdp3-wrot.yaml      | 5 +----
 .../devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml   | 5 +----
 .../devicetree/bindings/soc/mediatek/mediatek,mutex.yaml   | 5 +----
 .../devicetree/bindings/soc/mediatek/mediatek,wdma.yaml    | 5 +----
 7 files changed, 13 insertions(+), 24 deletions(-)

Comments

Conor Dooley Dec. 19, 2023, 4:54 p.m. UTC | #1
On Mon, Dec 18, 2023 at 04:36:01PM +0800, Jason-JH.Lin wrote:
> From: Jason-jh Lin <jason-jh.lin@mediatek.corp-partner.google.com>
> 
> Since mediatek,gce-events property is a HW event signal from GCE,
> it should be defined in mediatek,gce-mailbox.yaml.
> 
> Change the description of mediatek,gce-events property existed in
> other bindings to reference mediatek,gce-mailbox.yaml.

I don't understand this series. I would understand it if the property
should be related to the mailbox provider and it is moved there from the
mailbox consumer, but this series does not do that. Instead the series
now documents this property for both consumers and providers.

Secondly it removes the typedef from the consumers, which makes no sense
if this is a valid property there.

Is your intention to document a property that should be common across
all consumers in a single place? If that is your goal, then something
like spi-peripheral-props.yaml is what you need here.

Confused,
Conor.