linux-kernel - Re: [PATCH v6 2/2] dt-bindings: mfd: mediatek: mt6397: Convert to DT schema format

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202409201337500284902d@mail.local>
Date: Fri, 20 Sep 2024 15:37:50 +0200
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Cc: Macpaul Lin <macpaul.lin@...iatek.com>, Andrew Lunn <andrew@...n.ch>,
	Florian Fainelli <f.fainelli@...il.com>,
	Vladimir Oltean <olteanv@...il.com>,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, Sean Wang <sean.wang@...iatek.com>,
	Sen Chu <sen.chu@...iatek.com>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>,
	Sebastian Reichel <sre@...nel.org>,
	Chen Zhong <chen.zhong@...iatek.com>, linux-input@...r.kernel.org,
	linux-leds@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-rtc@...r.kernel.org, linux-sound@...r.kernel.org,
	Alexandre Mergnat <amergnat@...libre.com>,
	Bear Wang <bear.wang@...iatek.com>,
	Pablo Sun <pablo.sun@...iatek.com>, Macpaul Lin <macpaul@...il.com>,
	Chris-qj chen <chris-qj.chen@...iatek.com>,
	MediaTek Chromebook Upstream <Project_Global_Chrome_Upstream_Group@...iatek.com>,
	Chen-Yu Tsai <wenst@...omium.org>
Subject: Re: [PATCH v6 2/2] dt-bindings: mfd: mediatek: mt6397: Convert to DT
 schema format

On 20/09/2024 09:31:24+0200, AngeloGioacchino Del Regno wrote:
> Il 18/09/24 16:18, Macpaul Lin ha scritto:
> > 
> > On 9/18/24 19:56, Alexandre Belloni wrote:
> > > 
> > > On 18/09/2024 13:51:51+0200, Alexandre Belloni wrote:
> > > > > Changes for v4:
> > > > >  - Remove "mediatek,mt6357" from PMIC's compatible string since there is a
> > > > >    seperated DT schema for PMIC mt6357.
> > > > > > Changes for v5:
> > > > >  - Rebase to next-20240913 (linux-next/master).
> > > > >  - Fix the "title" (device type) of mfd/mediatek,mt6397.yaml to "PMIC".
> > > > >  - RTC:
> > > > >   - Drop "start-year"
> > > > 
> > > > Maybe, instead of dropping the property, you should add support in the
> > > > driver by setting range_min and range_max.
> > > 
> > > Looking at this even more, the driver can probably be simplified by
> > > setting start_year in probe and dropping RTC_MIN_YEAR_OFFSET.
> > 
> > Thank you for pointing out where and how the driver should be changed.
> > However, I'm wondering if this should be a fix with a separated
> > patchset (bindings and the driver)? The board or SoC's device trees
> > should be reviewed as well. I'll need to get someone's help (permission)
> > inside MediaTek to check those dts and construct the patch for RTC
> > driver.
> > That will take sometime.
> > 
> 
> Alexandre, I definitely agree with you on the fact that the MTK PMIC RTC driver
> can (and needs to) be improved, and that it can make use of some nice cleanup...
> 
> ... but!
> 
> This series performs a conversion to schema, and the previous txt file didn't
> say anything about the start-year property - which was not mandatory to support
> at that time (nor now, afaik?), so adding support for that is out of scope for
> this series.

It is mandatory now. I agree this can be done in a subsequent series.

> 
> Eventually, that can come as a series on top, adding support for that in the
> binding (and, of course, in the driver).
> 
> I should be able to tackle that... most probably next week - but still, the
> improvements would come as a series on top of this one.
> 
> Cheers,
> Angelo

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com