[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACPK8Xc1d89MXBjSJw7Jz0oqkCcoxKbymaVDmJq-kHFK6qG0Sw@mail.gmail.com>
Date: Wed, 1 Nov 2017 10:15:32 +1030
From: Joel Stanley <joel@....id.au>
To: Philipp Zabel <philipp.zabel@...il.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
Rick Altherr <raltherr@...gle.com>,
Rob Herring <robh+dt@...nel.org>,
Hartmut Knaack <knaack.h@....de>,
Lars-Peter Clausen <lars@...afoo.de>,
Peter Meerwald-Stadler <pmeerw@...erw.net>,
linux-iio@...r.kernel.org, devicetree <devicetree@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe
On Tue, Oct 31, 2017 at 10:28 PM, Philipp Zabel <philipp.zabel@...il.com> wrote:
> On Tue, Oct 31, 2017 at 3:12 AM, Joel Stanley <joel@....id.au> wrote:
>> The ASPEED SoC must deassert a reset in order to use the ADC peripheral.
>>
>> The device tree bindings are updated to document the resets phandle, and
>> the example is updated to match what is expected for both the reset and
>> clock phandle. Note that the bindings should have always had the reset
>> controller, as the hardware is unusable without it.
>>
>> Signed-off-by: Joel Stanley <joel@....id.au>
>
> It is unfortunate that this has to break DT (theoretical) backwards
> compatibility, but given that the old bindings never worked,
> this is better than to pretend a required reset is optional.
>
> Reviewed-by: Philipp Zabel <philipp.zabel@...il.com>
Thanks. I agree that it's unfortunate; this has been my first time
working on an ARM SoC and there were few things we could have done
better in hindsight.
I've got similar patches for the ASPEED hwmon pwm/tach driver, and the
i2c driver that I'll send out now.
Thanks for the review.
Cheers,
Joel
Powered by blists - more mailing lists