linux-kernel - Re: [PATCH 1/4] dt-bindings: remoteproc: fsl,imx-rproc: add new compatible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241024164851.GA572386-robh@kernel.org>
Date: Thu, 24 Oct 2024 11:48:51 -0500
From: Rob Herring <robh@...nel.org>
To: Laurentiu Mihalcea <laurentiumihalcea111@...il.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Shawn Guo <shawnguo@...nel.org>,
	Daniel Baluta <daniel.baluta@....com>, Peng Fan <peng.fan@....com>,
	Mark Brown <broonie@...nel.org>, Takashi Iwai <tiwai@...e.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
	Bard Liao <yung-chuan.liao@...ux.intel.com>,
	Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
	Jaroslav Kysela <perex@...ex.cz>,
	Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>,
	Conor Dooley <conor+dt@...nel.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Iuliana Prodan <iuliana.prodan@....com>,
	linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org,
	imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	linux-sound@...r.kernel.org, sound-open-firmware@...a-project.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] dt-bindings: remoteproc: fsl,imx-rproc: add new
 compatible

On Thu, Oct 24, 2024 at 01:47:53PM +0300, Laurentiu Mihalcea wrote:
> 
> 
> On 10/24/2024 10:45 AM, Krzysztof Kozlowski wrote:
> > On Wed, Oct 23, 2024 at 12:21:11PM -0400, Laurentiu Mihalcea wrote:
> >> From: Laurentiu Mihalcea <laurentiu.mihalcea@....com>
> >>
> >> Add new compatible for imx95's CM7 with SOF.
> >>
> >> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@....com>
> >> ---
> >>  .../bindings/remoteproc/fsl,imx-rproc.yaml    | 58 +++++++++++++++++--
> >>  1 file changed, 53 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> >> index 57d75acb0b5e..ab0d8e017965 100644
> >> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> >> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> >> @@ -28,6 +28,15 @@ properties:
> >>        - fsl,imx8qxp-cm4
> >>        - fsl,imx8ulp-cm33
> >>        - fsl,imx93-cm33
> >> +      - fsl,imx95-cm7-sof
> >> +
> >> +  reg:
> >> +    maxItems: 2
> >> +
> >> +  reg-names:
> >> +    items:
> >> +      - const: dram
> >> +      - const: mailbox
> > That's quite different programming model. Are you sure these are devices
> > from similar class/type?
> Yep, these are all Cortex-M cores. It's just that their usage differs quite a lot.
> >
> > Your big if:then: block suggests this could be separate binding.
> Ideally I would have wanted to place the compatible inside dsp/fsl,dsp.yaml as the
> programming model would have been more similar.
> 
> Unfortunately, these are different physical devices (HiFi DSP core vs CM core) even
> though they're all used for DSP purposes so I'm not sure this is entirely appropriate.

That doesn't matter too much. trivial-devices.yaml is a bunch of 
completely unrelated devices which happen to have the same binding. We 
could probably take that farther with things like trivial clock 
providers for example. 

Having 'reg' vs not is pretty clearly something that should be different 
binding.

> 
> Alternatively, if you think grouping these devices (i.e: those represented by the -dsp compatibles
> from fsl,dsp and the one represented by the compatible introduced here) under the same binding
> is alright we can just branch off from fsl,dsp and fsl,imx-rproc and create a new binding for
> these devices. I'm expecting this to be relatively clean as they have the same programming
> model.

If it's just add a compatible and nothing else somewhere, I'd do that. 
If it's more than that, then I'd make a new binding doc.

Rob