linux-kernel - Re: hwmon: (adt7475) Add support for inverting pwm output

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]

Message-ID: <52e26a67-9131-2dc0-40cb-db5c07370027@alliedtelesis.co.nz>
Date:   Tue, 18 Apr 2023 21:20:02 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Mariusz Białończyk <manio@...boo.net>
CC:     "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: hwmon: (adt7475) Add support for inverting pwm output


On 19/04/23 08:41, Chris Packham wrote:
> Hi Marius,
>
> +cc linux-hwmon, lkml
>
> On 18/04/23 23:06, Mariusz Białończyk wrote:
>> Hi Chris,
>> I discovered by accident that my dmesg is telling me:
>> [Mon Apr 17 19:08:59 2023] adt7475 19-002e: Error configuring pwm 
>> polarity
>> [Mon Apr 17 19:08:59 2023] adt7475 19-002e: ADT7473 device, revision 1
>>
>> motherboard:
>> DMI: System manufacturer System Product Name/M4A785TD-V EVO, BIOS 
>> 2105    07/23/2010
>>
>> Is this something i need to be afraid, or it's nothing serious?
>
> It's probably harmless, unless your board is intentionally setting the 
> pwm-active-state (which I suspect it won't be as your BIOS is probably 
> taking care of that if required). I suspect it's more a case of the 
> code not handling the absence of a device tree which the check for 
> -EINVAL was supposed to deal with. There's an outside chance that 
> there is a problem on the I2C bus but that would require your platform 
> to be actively using the pwm polarity feature via a device tree 
> (unlikely outside of embedded devices).
>
> I think it'd still be a good idea to squash the errant warning so 
> genuine errors are caught. I'll see if I can provoke the issue on 
> devices I have access to. Are you in a position to try a patch if I 
> come up with one?
Ah I think I see the problem. On platforms without device tree support 
the of_property_read_*() functions return -ENOSYS so I need to deal with 
that error code as well as -EINVAL.