From: Guenter Roeck <linux@roeck-us.net>
To: Sergio Paracuellos <sergio.paracuellos@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: "Arınç ÜNAL" <arinc.unal@arinc9.com>,
linux-watchdog@vger.kernel.org, wim@linux-watchdog.org,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, tsbogend@alpha.franken.de,
p.zabel@pengutronix.de, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-mips@vger.kernel.org
Subject: Re: [PATCH v4 1/5] dt-bindings: watchdog: mt7621-wdt: add phandle to access system controller registers
Date: Sun, 12 Feb 2023 07:27:28 -0800 [thread overview]
Message-ID: <afe68663-8ade-ae5a-00a1-083b2f263cb0@roeck-us.net> (raw)
In-Reply-To: <CAMhs-H-JGZMR6mB=USywAh4aRS9ZFOVebwLv8=N2f3uvWpcXDA@mail.gmail.com>
On 2/12/23 00:13, Sergio Paracuellos wrote:
> On Sat, Feb 11, 2023 at 12:42 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 11/02/2023 12:01, Sergio Paracuellos wrote:
>>> On Sat, Feb 11, 2023 at 11:47 AM Arınç ÜNAL <arinc.unal@arinc9.com> wrote:
>>>>
>>>> On 11.02.2023 13:41, Sergio Paracuellos wrote:
>>>>> On Sat, Feb 11, 2023 at 10:10 AM Arınç ÜNAL <arinc.unal@arinc9.com> wrote:
>>>>>>
>>>>>> Is this mediatek,sysctl property required after your changes on the
>>>>>> watchdog code?
>>>>>
>>>>> I don't really understand the question :-) Yes, it is. Since we have
>>>>> introduced a new phandle in the watchdog node to be able to access the
>>>>> reset status register through the 'sysc' syscon node.
>>>>> We need the bindings to be aligned with the mt7621.dtsi file and we
>>>>> are getting the syscon regmap handler via
>>>>> 'syscon_regmap_lookup_by_phandle()'. See PATCH 5 of the series, Arınç.
>>>>
>>>> I believe you need to put mediatek,sysctl under "required:".
>>>
>>> Ah, I understood your question now :-). You meant 'required' property.
>>> I need more coffee, I guess :-). I am not sure if you can add
>>> properties as required after bindings are already mainlined for
>>> compatibility issues. The problem with this SoC is that drivers become
>>> mainlined before the device tree was so if things are properly fixed
>>> now this kind of issues appear. Let's see Krzysztof and Rob comments
>>> for this.
>>
>> If your driver fails to probe without mediatek,sysctl, you already made
>> it required (thus broke the ABI) regardless what dt-binding is saying.
>> In such case you should update dt-binding to reflect reality.
>>
>> Now ABI break is different case. Usually you should not break it without
>> valid reasons (e.g. it was never working before). Your commit msg
>> suggests that you only improve the code, thus ABI break is not really
>> justified. In such case - binding is correct, driver should be reworked
>> to accept DTS without the new property.
>
> Thanks for clarification, Krzysztof. Ok, so if this is the case I need
> to add this property required (as Arinc was properly pointing out in
> previous mail) since without it the driver is going to fail on probe
> (PATCH 5 of the series). I understand the "it was never working
> before" argument reason for ABI breaks. What happens if the old driver
> code was not ideal and totally dependent on architecture specific
> operations when this could be totally avoided and properly make arch
> independent agnostic drivers? This driver was added in 2016 [0]. There
> was not a device tree file in the kernel for this SoC mainlined until
> 2022 [1]. I also personally migrated this watchdog binding in 2022
> from text to YAML and maintained it without changes [2]. When this was
> mainlined not all drivers were properly reviewed and the current code
> was just maintained as it is. Most users of this SoC are in the
> openWRT community where the dtsi of the mainline is not used yet and
> they maintain their own mt7621.dtsi files. Also, when a new version of
> the openWRT selected kernel is added they also modify and align with
> its mt7621.dtsi file without maintaining previous dtb's. If "make the
> driver arch independent to be able to be compile tested" and this kind
> of arguments are not valid at all I need to know because I have
> started to review driver code for this SoC and other drivers also have
> the same arch dependency that ideally should be avoided in the same
> way. This at the end means to break the ABI again in the future for
> those drivers / bindings. So I can just let them be as it is and not
> provide any change at all and continue without being compile tested
> and other beneficial features to detect future driver breakage.
>
Problem is that there are (presumably) shipped systems out there with
the old devicetree file. The watchdog driver would no longer instantiate
on those systems.
Guenter
next prev parent reply other threads:[~2023-02-12 15:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-11 7:33 [PATCH v4 0/5] watchdog: mt7621-wdt: avoid globals and arch dependencies Sergio Paracuellos
2023-02-11 7:33 ` [PATCH v4 1/5] dt-bindings: watchdog: mt7621-wdt: add phandle to access system controller registers Sergio Paracuellos
2023-02-11 9:10 ` Arınç ÜNAL
2023-02-11 10:41 ` Sergio Paracuellos
2023-02-11 10:46 ` Arınç ÜNAL
2023-02-11 11:01 ` Sergio Paracuellos
2023-02-11 11:42 ` Krzysztof Kozlowski
2023-02-12 8:13 ` Sergio Paracuellos
2023-02-12 15:27 ` Guenter Roeck [this message]
2023-02-13 8:59 ` Sergio Paracuellos
2023-02-13 19:36 ` Guenter Roeck
2023-02-13 19:57 ` Sergio Paracuellos
2023-02-13 20:09 ` Guenter Roeck
2023-02-13 8:38 ` Krzysztof Kozlowski
2023-02-13 8:58 ` Sergio Paracuellos
2023-02-11 11:42 ` Krzysztof Kozlowski
2023-02-11 7:33 ` [PATCH v4 2/5] mips: dts: ralink: mt7621: add phandle to system controller node for watchdog Sergio Paracuellos
2023-02-11 9:11 ` Arınç ÜNAL
2023-02-11 7:33 ` [PATCH v4 3/5] mips: dts: ralink: mt7621: rename watchdog node from 'wdt' into 'watchdog' Sergio Paracuellos
2023-02-11 9:12 ` Arınç ÜNAL
2023-02-11 7:33 ` [PATCH v4 4/5] watchdog: mt7621-wdt: avoid static global declarations Sergio Paracuellos
2023-02-11 7:33 ` [PATCH v4 5/5] watchdog: mt7621-wdt: avoid ralink architecture dependent code Sergio Paracuellos
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=afe68663-8ade-ae5a-00a1-083b2f263cb0@roeck-us.net \
--to=linux@roeck-us.net \
--cc=arinc.unal@arinc9.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=sergio.paracuellos@gmail.com \
--cc=tsbogend@alpha.franken.de \
--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