Re: [v4,2/4] dt-binding: reset-controller: ti: add 'mediatek,infra-reset' to compatible

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Rob,

On 8/26/20 6:09 AM, Crystal Guo wrote:
> On Wed, 2020-08-26 at 03:02 +0800, Rob Herring wrote:
>> On Mon, Aug 17, 2020 at 11:03:22AM +0800, Crystal Guo wrote:
>>> The TI syscon reset controller provides a common reset management,
>>> and is suitable for MTK SoCs. Add compatible 'mediatek,infra-reset',
>>> which denotes to use ti reset-controller driver directly.
>>>
>>> Signed-off-by: Crystal Guo <crystal.guo@xxxxxxxxxxxx>
>>> ---
>>>  Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>>> index ab041032339b..5a0e9365b51b 100644
>>> --- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>>> +++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>>> @@ -25,6 +25,7 @@ Required properties:
>>>  			    "ti,k2l-pscrst"
>>>  			    "ti,k2hk-pscrst"
>>>  			    "ti,syscon-reset"
>>> +			    "mediatek,infra-reset", "ti,syscon-reset"
>>
>> You need your own binding doc. If you can use the same driver then fine, 
>> but that's a separate issue. There's also reset-simple driver if you 
>> have just array of 32-bit registers with a bit per reset.
>>
>> Don't repeat 'ti,reset-bits' either.
> 
> Do you mean I should add a Mediatek reset binding doc, although Mediatek
> reuse the TI reset controller directly?

Hmm, how do you envision not repeating the same bits in a separate binding?
Does it help if I convert this to YAML first without a ti, prefix in the file name?

The usage philosophy definitely was to use a <soc-compatible> followed by the
<generic-compatible>. This is how all of our reset nodes were added as well.

Looks like Andrew may have misinterpreted your comment [1] during the original
binding and changed "syscon-reset" to "ti,syscon-reset" in the final version [2].

regards
Suman

[1] https://lore.kernel.org/patchwork/comment/876688/
[2] https://lore.kernel.org/patchwork/patch/693172/

> 
> Best Regards
> Crystal
>>
>>>   - #reset-cells		: Should be 1. Please see the reset consumer node below
>>>  			  for usage details
>>>   - ti,reset-bits	: Contains the reset control register information
>>> -- 
>>> 2.18.0
> 




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux