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  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]
Date:   Fri, 3 Nov 2017 03:11:03 -0700
From:   Guenter Roeck <>
To:     Joel Stanley <>
Cc:     Rob Herring <>,
        Philipp Zabel <>,
        Mykola Kostenok <>,
        Jaghathiswari Rankappagounder Natarajan <>,
        Patrick Venture <>,
        Andrew Jeffery <>,
        devicetree <>,,
        Linux Kernel Mailing List <>,
        Benjamin Herrenschmidt <>,
        Jeremy Kerr <>
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 <> 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.


Powered by blists - more mailing lists