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

[Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx>]

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