Linux-Watchdog Archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno 
	<angelogioacchino.delregno@collabora.com>,
	linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v3 2/2] watchdog: mediatek: mt7988: add wdt support
Date: Mon, 20 Nov 2023 10:06:03 -0800	[thread overview]
Message-ID: <3a9d2d26-87c5-47b2-b03d-81b398a54abf@roeck-us.net> (raw)
In-Reply-To: <ZVuYdZQbwj4tAfER@makrotopia.org>

On 11/20/23 09:33, Daniel Golle wrote:
> On Mon, Nov 20, 2023 at 09:19:46AM -0800, Guenter Roeck wrote:
>> On 11/14/23 09:04, Daniel Golle wrote:
>>> [...]
>>> @@ -89,6 +93,11 @@ static const struct mtk_wdt_data mt7986_data = {
>>>    	.toprgu_sw_rst_num = MT7986_TOPRGU_SW_RST_NUM,
>>>    };
>>> +static const struct mtk_wdt_data mt7988_data = {
>>> +	.toprgu_sw_rst_num = 24,
>>
>> Kind of odd to have this defined locally, while the others are in include files,
>> but not worth arguing about.
> 
>>From I have just learned from Krzysztof Kozlowski those headers shouldn't
> even exist in first place, as the listed IDs are not actually referenced
> anywhere in the driver, hence they aren't actually bindings [1].
> 
> Quote from that thread:
> | >>> Where is the driver change using these IDs?
> | >> It isn't needed as the driver doesn't list the IDs. [...]
> | > Then it is not a binding.
> ---
> 
> Now that they do exist it's too late to change that for everything
> already existing, I suppose. However, it also doesn't seem like adding
> such a header for MT7988 as well is going to be acknowledged, hence we
> will have to live with the inconsistency in the driver in which older
> SoCs will obtain the number of resets from a macro in their respective
> dt-bindings header while newer SoCs won't have such header and hence
> it will have to be defined in the driver itself (as that's also the
> only place where that number is being used).
> 

As I said, not worth arguing about. However, it seems to me that "too late
to change that for everything" isn't really correct. If MTxxxx_TOPRGU_RST_NUM
isn't supposed to be in devicetree include files, all those defines could be
removed from the from there and be added to the watchdog driver. I don't know
about the other defines in include/dt-bindings/reset/mediatek,mtXXXX-resets.h -
many of those _are_ used in dtsi files, but many others are not.

In summary, while I don't really know/understand what is supposed to be defined
in include/dt-bindings/, whatever is known to _not_ to be there (such as the
total number of reset pins on a SoC) could be moved into the driver(s) using it.

Of course, it might well be that there is a rule saying that anything in
include/dt-bindings/ must not be removed from it even if it is not supposed
to be there. In that case, my apologies for the noise.

Thanks,
Guenter


      reply	other threads:[~2023-11-20 18:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-14 17:04 [PATCH v3 1/2] dt-bindings: watchdog: mediatek,mtk-wdt: add MT7988 watchdog and toprgu Daniel Golle
2023-11-14 17:04 ` [PATCH v3 2/2] watchdog: mediatek: mt7988: add wdt support Daniel Golle
2023-11-20 17:19   ` Guenter Roeck
2023-11-20 17:33     ` Daniel Golle
2023-11-20 18:06       ` Guenter Roeck [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=3a9d2d26-87c5-47b2-b03d-81b398a54abf@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@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 read-only IMAP folder(s) and NNTP newsgroup(s).