On Wed, Sep 9, 2020 at 9:10 AM Suman Anna [off-list ref] wrote:

On 9/8/20 1:49 PM, Rob Herring wrote:

quoted

On Wed, Sep 2, 2020 at 5:26 PM Suman Anna [off-list ref] wrote:

quoted

Hi Rob,

On 8/26/20 6:09 AM, Crystal Guo wrote:

quoted

On Wed, 2020-08-26 at 03:02 +0800, Rob Herring wrote:

quoted

On Mon, Aug 17, 2020 at 11:03:22AM +0800, Crystal Guo wrote:

quoted

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 <redacted>
---
 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?

I mean 'ti,reset-bits' isn't really something that should have been in
DT in the first place, but rather implied by the compatible string.

Ok, should I be deprecating this and move this data to driver then?

No, I'm just asking to not have new users.

I am assuming that is how you are envisioning the new Mediatek binding to be
atleast.

Right.

Rob