[PATCH] i2c: designware: don't infer timings described by ACPI from clock rate

Ard Biesheuvel ard.biesheuvel at linaro.org
Fri May 19 03:48:07 PDT 2017


On 19 May 2017 at 11:37, Jarkko Nikula <jarkko.nikula at linux.intel.com> wrote:
> On 05/19/2017 01:06 PM, Ard Biesheuvel wrote:
>>
>> On 19 May 2017 at 11:01, Jarkko Nikula <jarkko.nikula at linux.intel.com>
>> wrote:
>>>
>>> On 05/19/2017 11:56 AM, Ard Biesheuvel wrote:
>>>>
>>>>
>>>> Commit bd698d24b1b57 ("i2c: designware: Get selected speed mode
>>>> sda-hold-time via ACPI") updated the logic that reads the timing
>>>> parameters for various I2C bus rates from the DSDT, to only read
>>>> the timing parameters for the currently selected mode.
>>>>
>>>> This causes a WARN_ON() splat on platforms that legally omit the clock
>>>> frequency from the ACPI description, because in the new situation, the
>>>> core I2C designware driver still accesses the fields in the driver
>>>> struct that we no longer populate, and proceeds to calculate them from
>>>> the clock frequency. Since the clock frequency is unspecified, the
>>>> driver complains loudly using a WARN_ON().
>>>>
>>>> So revert back to the old situation, where the struct fields for all
>>>> timings are populated, but retain the new logic which chooses the SDA
>>>> hold time from the timing mode that is currently in use.
>>>>
>>>> Fixes: bd698d24b1b57 ("i2c: designware: Get selected speed mode ...")
>>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>>> ---
>>>>  drivers/i2c/busses/i2c-designware-platdrv.c | 18 ++++++++++--------
>>>>  1 file changed, 10 insertions(+), 8 deletions(-)
>>>>
>>> Thanks, this is ok to me. Let's add also kudos to Lorenzo:
>>>
>>> Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>>> Acked-by: Jarkko Nikula <jarkko.nikula at linux.intel.com>
>>
>>
>> Thanks. I suppose this is going in as a fix? If not, please cc to -stable
>>
> That's not needed as the bd698d24b1b57 came during pre 4.12-rc1 cycle. But
> good to get this into 4.12 due probable regression in high-speed transfers
> and to get rid of log spamming.
>

Agreed. Thanks.



More information about the linux-arm-kernel mailing list