linux-kernel - Re: [PATCH v4] i2c: aspeed: 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: <CACPK8Xf0pr6tw=7RDpcVCL0-sKAP=N25ntU-5a=t0G0mqNkoPA@mail.gmail.com>
Date:   Mon, 6 Nov 2017 12:40:21 +1100
From:   Joel Stanley <joel@....id.au>
To:     Wolfram Sang <wsa@...-dreams.de>, Rob Herring <robh+dt@...nel.org>
Cc:     Brendan Higgins <brendanhiggins@...gle.com>,
        Philipp Zabel <philipp.zabel@...il.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Andrew Jeffery <andrew@...id.au>, linux-i2c@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] i2c: aspeed: Deassert reset in probe

On Sun, Nov 5, 2017 at 11:49 PM, Wolfram Sang <wsa@...-dreams.de> wrote:
> On Wed, Nov 01, 2017 at 10:53:30AM +1030, Joel Stanley wrote:
>> In order to use i2c from a cold boot, the i2c peripheral must be taken
>> out of reset. We request a shared reset controller each time a bus
>> driver is loaded, as the reset is shared between the 14 i2c buses.
>>
>> On remove the reset is asserted, which only touches the hardware once
>> the last i2c bus is removed.
>>
>> The reset is required as the I2C buses will not work without releasing
>> the reset. Previously the driver only worked with out of tree hacks
>> that released this reset before the driver was loaded. Update the
>> device tree bindings to reflect this.
>>
>> Signed-off-by: Joel Stanley <joel@....id.au>
>> ---
>> v4:
>>   - Make reset required and update device tree bindings
>
> For that change, I'd like to have an ack from Rob first. Won't that
> cause problems when you update only the kernel and keep the "old"
> devicetree?

In theory, yes.

In practice, the consumers of the Aspeed port are using a downstream
fork that I maintain as part of the OpenBMC project:

  https://github.com/openbmc/linux/

None of the machines that use this kernel take a copy of the dtb and
place it in flash, for example.

My goal is to make the upstream port fully functional so we don't need
the downstream any more.

Cheers,

Joel