[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABqG17h0+HWSCF0PRVBaj37WYYsz17+n1MD1Uiuscqy_dvU41g@mail.gmail.com>
Date: Tue, 24 Sep 2024 20:14:06 +0530
From: Naresh Solanki <naresh.solanki@...ements.com>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Jean Delvare <jdelvare@...e.com>, linux-kernel@...r.kernel.org,
linux-hwmon@...r.kernel.org
Subject: Re: [PATCH] hwmon: (max6639) : Add DT support
Hi Guenter,
On Tue, 24 Sept 2024 at 19:42, Guenter Roeck <linux@...ck-us.net> wrote:
>
> On 9/24/24 02:29, Naresh Solanki wrote:
> > Hi Guenter,
> >
> > Sorry for the late reply,
> >
> > On Fri, 28 Jun 2024 at 20:30, Guenter Roeck <linux@...ck-us.net> wrote:
> >>
> >> On 6/28/24 04:54, Naresh Solanki wrote:
> >>> Remove platform data & add devicetree support.
> >>>
> >>
> >> Unless I am missing something, this doesn't just add devicetree support,
> >> it actually _mandates_ devicetree support. There are no defaults.
> >> That is not acceptable.
> > I agree with you. It is best to have some defaults & then overwrite
> > based on DT properties.
> > But in that case we would have to assume that all fans are enabled
> > irrespective of their hardware connections in the schematics(example
> > fan_enable).
> >
> > I'm not sure if that is fine. But if you feel that is alright then
> > I'll rewrite the driver to assume
> > everything is enabled with default values.
>
> That would still be a functional change, or am I missing something ?
> It would overwrite any configuration written by a BIOS/ROMMON.
With that, driver would take the current chip configuration as default &
just configure specific config specified in DT(if any) & continue with
initialization?
This can keep into account the Chip defaults, BIOS written configuration
& even DT.
Is this what you mean ?
If yes then I'll align the driver accordingly.
Please let me know if I understood your intent correctly & any other
thoughts on this.
Regards,
Naresh
>
> Guenter
>
Powered by blists - more mailing lists