From: Krzysztof Kozlowski <krzk@kernel.org>
To: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Cc: linux-mediatek@lists.infradead.org,
Wim Van Sebroeck <wim@linux-watchdog.org>,
Guenter Roeck <linux@roeck-us.net>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/8] dt-bindings: reset: Add mt6589 toprgu reset IDs
Date: Thu, 27 Aug 2026 11:37:51 +0200 [thread overview]
Message-ID: <409e398b-eb8f-48eb-a0d3-ed8fa811328f@kernel.org> (raw)
In-Reply-To: <20260812-smooth-artichoke-kittiwake-f6e85e@quoll>
On 12/08/2026 12:35, Krzysztof Kozlowski wrote:
> On Tue, Aug 11, 2026 at 04:20:11PM +0200, Luca Leonardo Scorcia wrote:
>>
>>> We do not take bits, but identifiers of resets.
>>
>> Currently the existing mtk_wdt.c driver does not use a reset table
>> that binds identifiers to bits for any of the existing devices. There
>> are a bunch of mediatek,mt*.h files under dt-bindings/reset [3] that
>> point directly to reset bits instead of being indexes.
>
> Many got accepted unnoticed, many times we did not care, but the point
> is still valid - pure hardware numbers do not belong to the bindings,
> because they do not bind any pieces of code. The proper binding header
> constants bind DTS with SW implementation, so two pieces of code. Not
> applicable here.
>
>> I can introduce a reset table in the driver, but it would break
>> existing devices as those bits are referred in device trees and they
>> are often non-contiguous (e.g. [4]). As before, it could be done by
>
> Then these bits stay as is in DTS but bindings header is not needed. You
> can have of course DTS header, as we did in the past multiple times for
> such hardware constants.
So I wrote above this to myself and can be ignored completely? Then why
would we not ignore your patches?
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-08-27 9:38 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-09 16:03 [PATCH v3 0/8] Properly describe mt6589 and mt8167 toprgu resets Luca Leonardo Scorcia
2026-08-09 16:03 ` [PATCH v3 1/8] dt-bindings: reset: Add mt6589 toprgu reset IDs Luca Leonardo Scorcia
2026-08-11 8:54 ` Krzysztof Kozlowski
2026-08-11 14:20 ` Luca Leonardo Scorcia
2026-08-12 10:35 ` Krzysztof Kozlowski
2026-08-27 9:37 ` Krzysztof Kozlowski [this message]
2026-08-27 11:57 ` Luca Leonardo Scorcia
2026-08-27 12:10 ` Krzysztof Kozlowski
2026-08-27 14:51 ` Luca Leonardo Scorcia
2026-08-09 16:03 ` [PATCH v3 2/8] watchdog: mediatek: Add wdt/toprgu resets for MT6589 Luca Leonardo Scorcia
2026-08-09 16:03 ` [PATCH v3 3/8] arm: dts: mediatek: mt6589: Enable toprgu reset controller Luca Leonardo Scorcia
2026-08-09 17:04 ` Akari Tsuyukusa
2026-08-09 17:08 ` Luca Leonardo Scorcia
2026-08-09 17:16 ` Akari Tsuyukusa
2026-08-09 17:49 ` Guenter Roeck
2026-08-09 18:55 ` Luca Leonardo Scorcia
2026-08-09 19:09 ` Guenter Roeck
2026-08-09 16:03 ` [PATCH v3 4/8] dt-bindings: watchdog: Add compatible for MediaTek mt8167 Luca Leonardo Scorcia
2026-08-09 16:03 ` [PATCH v3 5/8] dt-bindings: reset: Add reset controller constants for mt8167 Luca Leonardo Scorcia
2026-08-11 8:55 ` Krzysztof Kozlowski
2026-08-09 16:03 ` [PATCH v3 6/8] watchdog: mediatek: Add support for mt8167 TOPRGU/WDT Luca Leonardo Scorcia
2026-08-09 16:03 ` [PATCH v3 7/8] arm64: dts: mt8167: Properly describe the SoC watchdog Luca Leonardo Scorcia
2026-08-09 16:03 ` [PATCH v3 8/8] soc: mediatek: mtk-mmsys: Add resets for mt8167 Luca Leonardo Scorcia
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=409e398b-eb8f-48eb-a0d3-ed8fa811328f@kernel.org \
--to=krzk@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=l.scorcia@gmail.com \
--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=linux@roeck-us.net \
--cc=matthias.bgg@gmail.com \
--cc=p.zabel@pengutronix.de \
--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
all inboxes | Powered by JetHome®