linux-kernel - Re: [PATCH v2 2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe

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: <900c6a0b-b7e3-a317-76fd-7694e971944f@roeck-us.net>
Date:   Fri, 3 Nov 2017 03:11:03 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Joel Stanley <joel@....id.au>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Philipp Zabel <philipp.zabel@...il.com>,
        Mykola Kostenok <c_mykolak@...lanox.com>,
        Jaghathiswari Rankappagounder Natarajan <jaghu@...gle.com>,
        Patrick Venture <venture@...gle.com>,
        Andrew Jeffery <andrew@...id.au>,
        devicetree <devicetree@...r.kernel.org>,
        linux-hwmon@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Jeremy Kerr <jk@...abs.org>
Subject: Re: [PATCH v2 2/3] hwmon: (aspeed-pwm-tacho) Deassert reset in probe

On 11/02/2017 07:32 PM, Joel Stanley wrote:
> On Fri, Nov 3, 2017 at 1:54 AM, Guenter Roeck <linux@...ck-us.net> wrote:
>> On Thu, Nov 02, 2017 at 02:53:48PM +1100, Joel Stanley wrote:
>>> The ASPEED SoC must deassert a reset in order to use the PWM/tach
>>> peripheral.
>>>
>> Again, you claim that the current driver would not work at all, which
>> is simply not correct. It doesn't work if the chip wasn't taken out
>> of reset by other means. This doesn't take into account situations and
>> hardware where the chip is taken out of reset automatically at boot, h
>> or by the ROM monitor/BIOS. It assumes that the reset pin can _always_
>> be controlled by software.
> 
> The reset is internal to the SoC. There is no pin to speak of, just a
> wire inside the SoC, so it can always be controlled by software.
> 
> There's SoC does not release any resets automatically; the default
> value on boot is for the reset to be asserted and this is not
> configurable.
> 
>> Similar, it forces the chip into reset when the driver is removed,
>> which is even worse. Unload the driver, and no more fan control ?
>> Really ? Then why is there an autonomous chip for fan control
>> to start with ? This is questionable even if the reset pin is
>> optional.
> 
> Similarly, the PWM/Tach unit is inside the SoC; it's not an external device.
> 
> It would be strange to remove the driver and expect the system to keep
> operating normally.
> 
>> You'll have to make reset handling optional for me to accept it.
>> I am quite sure that I said that before.
> 
> Please reconsider in light of the details above. It does not make any
> sense to build a system without this reset.
> 

So you are saying that this driver never worked ? Hard to believe.
I'll need input from other users.

Guenter