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] [day] [month] [year] [list]
Date: Mon, 6 May 2024 06:49:34 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Naresh Solanki <naresh.solanki@...ements.com>
Cc: Rob Herring <robh@...nel.org>, krzysztof.kozlowski+dt@...aro.org,
	u.kleine-koenig@...gutronix.de, Jean Delvare <jdelvare@...e.com>,
	linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pwm@...r.kernel.org
Subject: Re: [PATCH 2/4] hwmon: (max6639) : Utilise pwm subsystem

On Mon, May 06, 2024 at 03:35:40PM +0530, Naresh Solanki wrote:
> +Rob Herring
> 
> Hi Guenter,
> 
> 
> On Mon, 22 Apr 2024 at 18:07, Guenter Roeck <linux@...ck-us.net> wrote:
> >
> > On 4/22/24 03:39, Naresh Solanki wrote:
> > > Hi Guenter,
> > >
> > > On Wed, 17 Apr 2024 at 02:52, Guenter Roeck <linux@...ck-us.net> wrote:
> > >>
> > >> On Tue, Apr 16, 2024 at 10:47:15PM +0530, Naresh Solanki wrote:
> > >>> Utilise pwm subsystem for fan pwm handling
> > >>>
> > >>> Signed-off-by: Naresh Solanki <naresh.solanki@...ements.com>
> > >>
> > >> That adds a lot of complexity to the driver. I am missing the benefits.
> > >> You are supposed to explain why you are making changes, not just that
> > >> you are making them.
> > >>
> > >> Why are you making those changes ?
> > > Sure.
> > > This is to align with fan-common.yml wherein chip pwm is exposed.
> > > I'll update commit message
> > >
> >
> > Adding lots of complexity to a driver just to have it match a yaml file ?
> > I'll want to see a use case. Explain why you need the pwm exposed.
> > "because the yaml file demands it" is not a use case.
> The idea behind this was that this approach provides flexibility with
> hardware routing i.e., PWM0 might be connected to Fan1 & vise
> versa instead of assuming 1:1 mapping.
> 

The chip does not support such a configuration. Any hardware implementing
this would make automatic fan control using the chip's capabilities
impossible. Also, userspace fan control does not rely on the pwm subsystem.

This would make sense if someone was to use the chip as generic pwm
controller, which would be very unlikely. A "might be" is not sufficient
to warrant such an invasive and (in terms of code size) expensive change.

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ