[PATCH v2 1/2] dt-bindings: remoteproc: Support multiple reserved memory regions

Shun-Yi Wang (王順億) Shun-Yi.Wang at mediatek.com
Wed Jul 31 06:41:10 PDT 2024


Hi Krzysztof,

Thanks for the reviews.

On Wed, 2024-07-31 at 14:40 +0200, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 31/07/2024 14:17, Shun-yi Wang wrote:
> > From: "shun-yi.wang" <shun-yi.wang at mediatek.com>
> > 
> > Remove the maximum number of 1 for memory regions.
> 
> Why?
> 

For future applications, MTK SCP will reserve multiple regions for
specific hardware use.

> > Instead, add some descriptions to ensure the integrity
> > of the documentation.
> 
> What? How is this related?
> 

My original thinking was to keep the memory-region option.
But currently, there is no maximum value limitation, so I
add some description. Should I just drop the description directly?

Best regards,
Shun-yi

> > 
> > Signed-off-by: shun-yi.wang <shun-yi.wang at mediatek.com>
> > ---
> >  Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 8
> ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git
> a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > index d05d1563ec19..3362c8ffdccc 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> > @@ -55,7 +55,9 @@ properties:
> >        initializing SCP.
> >  
> >    memory-region:
> > -    maxItems: 1
> 
> No, no, no. Bindings must be specific/constrainted.
> 
> > +    description:
> > +      List of phandles to the reserved memory nodes used by
> > +      remoteproc devices.
> 
> No, drop, it's entirely redundant and pointless. You did not add any
> new
> information. This is always a list, always phandles and always
> reserved
> memory regions. So what does it bring?
> 
> Please do not upstream random junk from your downstream kernel. :(
> 
> Best regards,
> Krzysztof
> 


More information about the linux-arm-kernel mailing list