On 19 May 2017 at 11:37, Jarkko Nikula <jarkko.nikula@xxxxxxxxxxxxxxx> wrote:
> On 05/19/2017 01:06 PM, Ard Biesheuvel wrote:
>>
>> On 19 May 2017 at 11:01, Jarkko Nikula <jarkko.nikula@xxxxxxxxxxxxxxx>
>> 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@xxxxxxxxxx>
>>>> ---
>>>> 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@xxxxxxx>
>>> Acked-by: Jarkko Nikula <jarkko.nikula@xxxxxxxxxxxxxxx>
>>
>>
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
