linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Rafał Miłecki" <zajec5@gmail.com>
To: Rob Herring <robh@kernel.org>
Cc: "Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Justin Chen" <justinpopo6@gmail.com>,
	linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	bcm-kernel-feedback-list@broadcom.com,
	"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V2] dt-bindings: watchdog: brcm,bcm7038: add more compatible strings
Date: Wed, 9 Feb 2022 21:05:49 +0100	[thread overview]
Message-ID: <b29cd450-3753-2971-86ba-2f1e719b151f@gmail.com> (raw)
In-Reply-To: <YgQd25G0UROyTMA9@robh.at.kernel.org>

On 9.02.2022 21:02, Rob Herring wrote:
> On Wed, Feb 09, 2022 at 08:26:00PM +0100, Rafał Miłecki wrote:
>> On 9.02.2022 20:09, Rob Herring wrote:
>>> On Wed, Jan 26, 2022 at 11:20:34PM +0100, Rafał Miłecki wrote:
>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>
>>>> This hardware block is used on almost all BCM63xx family chipsets and
>>>> BCM4908 which reuses a lot of BCM63xx parts. Add relevant compatible
>>>> strings and also include a generic one.
>>>>
>>>> The only SoC with a different block I found is BCM6838 (thus not included
>>>> in this change).
>>>>
>>>> It may be worth noting that BCM6338, BCM6345, BCM6348 and BCM63268 don't
>>>> include "SoftRst" register but that can be handled by drivers based on
>>>> precise compatible string.
>>>>
>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>> ---
>>>> V2: Sort enum entries & update brcm,twd.yaml
>>>> ---
>>>>    .../devicetree/bindings/mfd/brcm,twd.yaml     |  2 +-
>>>>    .../bindings/watchdog/brcm,bcm7038-wdt.yaml   | 21 +++++++++++++++----
>>>>    2 files changed, 18 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/brcm,twd.yaml b/Documentation/devicetree/bindings/mfd/brcm,twd.yaml
>>>> index 634526f790b8..3f5db1990aba 100644
>>>> --- a/Documentation/devicetree/bindings/mfd/brcm,twd.yaml
>>>> +++ b/Documentation/devicetree/bindings/mfd/brcm,twd.yaml
>>>> @@ -55,7 +55,7 @@ examples:
>>>>            #size-cells = <1>;
>>>>            watchdog@28 {
>>>> -            compatible = "brcm,bcm7038-wdt";
>>>> +            compatible = "brcm,bcm4908-wdt", "brcm,bcm63xx-wdt";
>>>>                reg = <0x28 0x8>;
>>>>            };
>>>>        };
>>>> diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml
>>>> index a926809352b8..4d848442913c 100644
>>>> --- a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml
>>>> +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml
>>>> @@ -16,9 +16,22 @@ maintainers:
>>>>    properties:
>>>>      compatible:
>>>> -    enum:
>>>> -      - brcm,bcm6345-wdt
>>>> -      - brcm,bcm7038-wdt
>>>> +    items:
>>>> +      - enum:
>>>> +          - brcm,bcm4908-wdt
>>>> +          - brcm,bcm6338-wdt
>>>> +          - brcm,bcm6345-wdt
>>>> +          - brcm,bcm6348-wdt
>>>> +          - brcm,bcm6848-wdt
>>>> +          - brcm,bcm6858-wdt
>>>> +          - brcm,bcm7038-wdt
>>>> +          - brcm,bcm60333-wdt
>>>> +          - brcm,bcm63138-wdt
>>>> +          - brcm,bcm63148-wdt
>>>> +          - brcm,bcm63268-wdt
>>>> +          - brcm,bcm63381-wdt
>>>> +          - brcm,bcm68360-wdt
>>>> +      - const: brcm,bcm63xx-wdt
>>>
>>> Is it really worthwhile to update all these DTs?:
>>>
>>> arch/mips/boot/dts/brcm/bcm63268.dtsi:                  compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm6328.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm6358.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm6362.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm6368.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm7125.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm7346.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm7358.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm7360.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm7362.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm7420.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm7425.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>> arch/mips/boot/dts/brcm/bcm7435.dtsi:                   compatible = "brcm,bcm7038-wdt";
>>
>> I don't have problem handling that.
> 
> Even if the dts files above are updated, the driver still has to support
> the above case.
> 
> It's pointless to change this. We've already got 1000s of warnings to
> fix and 2000 bindings still to convert if you need something to do.
> 
>>> I don't think so.
>> So what's the policy for such bindings then? How to select SoCs that
>> should have their own bindings? How can I tell which should /borrow/ a
>> binding instead?
> 
> The way it is supposed to work is the first implementation gets
> 'soc1-block'. When the 2nd implementation comes about, it gets
> 'soc2-block'. If soc2 implementation is 'the same' or a superset, then
> it should have a fallback to 'soc1-block'. Another way to test that is,
> "I want my existing s/w to work as-is with this new h/w". The process
> repeats on the next SoC, but you could be backwards compatible with
> soc1, soc2, both or none. Is that what you are asking?
> 
> If you are doing all this after the fact at once, then it can be a
> bit different in how you do compatibles.
> 
> In this case, I would make "brcm,bcm7038-wdt" the fallback to the rest
> (granted, I know nothing about these chips or the relationship between
> them), but you have to keep supporting "brcm,bcm7038-wdt". 6345 is up
> to you I guess as there aren't any upstream dts files using it. Florian
> might care.

I think I got it now, thanks for explaining!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      reply	other threads:[~2022-02-09 20:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-26 13:21 [PATCH] dt-bindings: watchdog: brcm, bcm7038: add more compatible strings Rafał Miłecki
2022-01-26 22:10 ` Rob Herring
2022-01-26 22:20 ` [PATCH V2] " Rafał Miłecki
2022-02-09 19:09   ` [PATCH V2] dt-bindings: watchdog: brcm,bcm7038: " Rob Herring
2022-02-09 19:26     ` Rafał Miłecki
2022-02-09 20:02       ` Rob Herring
2022-02-09 20:05         ` Rafał Miłecki [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b29cd450-3753-2971-86ba-2f1e719b151f@gmail.com \
    --to=zajec5@gmail.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=justinpopo6@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=rafal@milecki.pl \
    --cc=robh@kernel.org \
    --cc=wim@linux-watchdog.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).