[{"id":1759279,"web_url":"http://patchwork.ozlabs.org/comment/1759279/","msgid":"<1504009379.25945.142.camel@linux.intel.com>","list_archive_url":null,"date":"2017-08-29T12:22:59","subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to\n\tnearest supported clk","submitter":{"id":8583,"url":"http://patchwork.ozlabs.org/api/people/8583/","name":"Andy Shevchenko","email":"andriy.shevchenko@linux.intel.com"},"content":"On Tue, 2017-08-29 at 14:08 +0200, Hans de Goede wrote:\n> The Lenovo Miix2 8 DSDT contains an i2c clk / bus speed of 1700000 Hz\n> for one if its devices, which is not supported.\n> \n> This is the second DSDT to show up with an unsupported clk in a short\n> time, remove the hardcoded fix for DSDTs with a 1 MiHz clock and\n> simply\n> always round down the clk to the nearest supported value.\n> \n> Reported-by: russianneuromancer@ya.ru\n> Fixes: 682c6c2188 (\"i2c: designware: Some broken DSTDs use 1MiHz ...\")\n> Signed-off-by: Hans de Goede <hdegoede@redhat.com>\n> ---\n>  drivers/i2c/busses/i2c-designware-platdrv.c | 16 ++++++++++++----\n>  1 file changed, 12 insertions(+), 4 deletions(-)\n> \n> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c\n> b/drivers/i2c/busses/i2c-designware-platdrv.c\n> index 57248bccadbc..2b98a173136f 100644\n> --- a/drivers/i2c/busses/i2c-designware-platdrv.c\n> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c\n> @@ -256,7 +256,8 @@ static int dw_i2c_plat_probe(struct\n> platform_device *pdev)\n>  \tstruct dw_i2c_dev *dev;\n>  \tu32 acpi_speed, ht = 0;\n>  \tstruct resource *mem;\n> -\tint irq, ret;\n> +\tint i, irq, ret;\n> +\tconst int supported_speeds[] = { 0, 100000, 400000, 1000000,\n> 3400000 };\n>  \n>  \tirq = platform_get_irq(pdev, 0);\n>  \tif (irq < 0)\n> @@ -297,9 +298,16 @@ static int dw_i2c_plat_probe(struct\n> platform_device *pdev)\n>  \t}\n>  \n>  \tacpi_speed = i2c_acpi_find_bus_speed(&pdev->dev);\n> -\t/* Some broken DSTDs use 1MiHz instead of 1MHz */\n> -\tif (acpi_speed == 1048576)\n> -\t\tacpi_speed = 1000000;\n> +\t/*\n> +\t * Some DSTDs use a non standard speed, round down to the\n> lowest\n> +\t * standard speed.\n> +\t */\n> +\tfor (i = 1; i < ARRAY_SIZE(supported_speeds); i++) {\n> +\t\tif (acpi_speed < supported_speeds[i])\n> +\t\t\tbreak;\n> +\t}\n> +\tacpi_speed = supported_speeds[i - 1];\n\nI dunno what standard says if we may or may not use 100 kHz as a last\nresort even for speeds defined less than 100 kHz.","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhSTM5wjhz9sNc\n\tfor <incoming@patchwork.ozlabs.org>;\n\tTue, 29 Aug 2017 22:23:03 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751446AbdH2MXC (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 08:23:02 -0400","from mga02.intel.com ([134.134.136.20]:27983 \"EHLO mga02.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751390AbdH2MXC (ORCPT <rfc822;linux-i2c@vger.kernel.org>);\n\tTue, 29 Aug 2017 08:23:02 -0400","from orsmga003.jf.intel.com ([10.7.209.27])\n\tby orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t29 Aug 2017 05:23:01 -0700","from smile.fi.intel.com (HELO smile) ([10.237.72.86])\n\tby orsmga003.jf.intel.com with ESMTP; 29 Aug 2017 05:23:00 -0700"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.41,444,1498546800\"; d=\"scan'208\";a=\"1008818439\"","Message-ID":"<1504009379.25945.142.camel@linux.intel.com>","Subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to\n\tnearest supported clk","From":"Andy Shevchenko <andriy.shevchenko@linux.intel.com>","To":"Hans de Goede <hdegoede@redhat.com>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>,\n\tWolfram Sang <wsa@the-dreams.de>","Cc":"linux-i2c@vger.kernel.org","Date":"Tue, 29 Aug 2017 15:22:59 +0300","In-Reply-To":"<20170829120835.17276-1-hdegoede@redhat.com>","References":"<20170829120835.17276-1-hdegoede@redhat.com>","Organization":"Intel Finland Oy","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.22.6-1 ","Mime-Version":"1.0","Content-Transfer-Encoding":"8bit","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759303,"web_url":"http://patchwork.ozlabs.org/comment/1759303/","msgid":"<078c7214-230e-2a68-734b-2a01003ee378@redhat.com>","list_archive_url":null,"date":"2017-08-29T12:52:33","subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","submitter":{"id":1893,"url":"http://patchwork.ozlabs.org/api/people/1893/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi,\n\nOn 29-08-17 14:22, Andy Shevchenko wrote:\n> On Tue, 2017-08-29 at 14:08 +0200, Hans de Goede wrote:\n>> The Lenovo Miix2 8 DSDT contains an i2c clk / bus speed of 1700000 Hz\n>> for one if its devices, which is not supported.\n>>\n>> This is the second DSDT to show up with an unsupported clk in a short\n>> time, remove the hardcoded fix for DSDTs with a 1 MiHz clock and\n>> simply\n>> always round down the clk to the nearest supported value.\n>>\n>> Reported-by: russianneuromancer@ya.ru\n>> Fixes: 682c6c2188 (\"i2c: designware: Some broken DSTDs use 1MiHz ...\")\n>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>\n>> ---\n>>   drivers/i2c/busses/i2c-designware-platdrv.c | 16 ++++++++++++----\n>>   1 file changed, 12 insertions(+), 4 deletions(-)\n>>\n>> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c\n>> b/drivers/i2c/busses/i2c-designware-platdrv.c\n>> index 57248bccadbc..2b98a173136f 100644\n>> --- a/drivers/i2c/busses/i2c-designware-platdrv.c\n>> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c\n>> @@ -256,7 +256,8 @@ static int dw_i2c_plat_probe(struct\n>> platform_device *pdev)\n>>   \tstruct dw_i2c_dev *dev;\n>>   \tu32 acpi_speed, ht = 0;\n>>   \tstruct resource *mem;\n>> -\tint irq, ret;\n>> +\tint i, irq, ret;\n>> +\tconst int supported_speeds[] = { 0, 100000, 400000, 1000000,\n>> 3400000 };\n>>   \n>>   \tirq = platform_get_irq(pdev, 0);\n>>   \tif (irq < 0)\n>> @@ -297,9 +298,16 @@ static int dw_i2c_plat_probe(struct\n>> platform_device *pdev)\n>>   \t}\n>>   \n>>   \tacpi_speed = i2c_acpi_find_bus_speed(&pdev->dev);\n>> -\t/* Some broken DSTDs use 1MiHz instead of 1MHz */\n>> -\tif (acpi_speed == 1048576)\n>> -\t\tacpi_speed = 1000000;\n>> +\t/*\n>> +\t * Some DSTDs use a non standard speed, round down to the\n>> lowest\n>> +\t * standard speed.\n>> +\t */\n>> +\tfor (i = 1; i < ARRAY_SIZE(supported_speeds); i++) {\n>> +\t\tif (acpi_speed < supported_speeds[i])\n>> +\t\t\tbreak;\n>> +\t}\n>> +\tacpi_speed = supported_speeds[i - 1];\n> \n> I dunno what standard says if we may or may not use 100 kHz as a last\n> resort even for speeds defined less than 100 kHz.\n\nThe < 100000 case is for when i2c_acpi_find_bus_speed() returns 0, so\nthat we then keep it 0, in which case the code a bit lower will pick\na default. Since speeds < 100000 are clearly not valid treating them\nas ACPI not providing any bus-speed info seems sensible to me.\n\nRegards,\n\nHans","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx02.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=hdegoede@redhat.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhT9x27ZDz9t42\n\tfor <incoming@patchwork.ozlabs.org>;\n\tTue, 29 Aug 2017 22:52:38 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751358AbdH2Mwg (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 08:52:36 -0400","from mx1.redhat.com ([209.132.183.28]:39966 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751286AbdH2Mwf (ORCPT <rfc822;linux-i2c@vger.kernel.org>);\n\tTue, 29 Aug 2017 08:52:35 -0400","from smtp.corp.redhat.com\n\t(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 9396A806A6;\n\tTue, 29 Aug 2017 12:52:35 +0000 (UTC)","from shalem.localdomain (ovpn-117-162.ams2.redhat.com\n\t[10.36.117.162])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id C2D976FEFE;\n\tTue, 29 Aug 2017 12:52:34 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 9396A806A6","Subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","To":"Andy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>,\n\tWolfram Sang <wsa@the-dreams.de>","Cc":"linux-i2c@vger.kernel.org","References":"<20170829120835.17276-1-hdegoede@redhat.com>\n\t<1504009379.25945.142.camel@linux.intel.com>","From":"Hans de Goede <hdegoede@redhat.com>","Message-ID":"<078c7214-230e-2a68-734b-2a01003ee378@redhat.com>","Date":"Tue, 29 Aug 2017 14:52:33 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<1504009379.25945.142.camel@linux.intel.com>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.13","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.26]);\n\tTue, 29 Aug 2017 12:52:35 +0000 (UTC)","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759378,"web_url":"http://patchwork.ozlabs.org/comment/1759378/","msgid":"<afe402a1-4476-edc0-8158-a6d26975fb05@linux.intel.com>","list_archive_url":null,"date":"2017-08-29T14:12:59","subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","submitter":{"id":43309,"url":"http://patchwork.ozlabs.org/api/people/43309/","name":"Jarkko Nikula","email":"jarkko.nikula@linux.intel.com"},"content":"On 08/29/2017 03:52 PM, Hans de Goede wrote:\n> Hi,\n> \n> On 29-08-17 14:22, Andy Shevchenko wrote:\n>> On Tue, 2017-08-29 at 14:08 +0200, Hans de Goede wrote:\n>>> The Lenovo Miix2 8 DSDT contains an i2c clk / bus speed of 1700000 Hz\n>>> for one if its devices, which is not supported.\n>>>\n>>> This is the second DSDT to show up with an unsupported clk in a short\n>>> time, remove the hardcoded fix for DSDTs with a 1 MiHz clock and\n>>> simply\n>>> always round down the clk to the nearest supported value.\n>>>\n>>> Reported-by: russianneuromancer@ya.ru\n>>> Fixes: 682c6c2188 (\"i2c: designware: Some broken DSTDs use 1MiHz ...\")\n>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>\n>>> ---\n>>>   drivers/i2c/busses/i2c-designware-platdrv.c | 16 ++++++++++++----\n>>>   1 file changed, 12 insertions(+), 4 deletions(-)\n>>>\n>>> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c\n>>> b/drivers/i2c/busses/i2c-designware-platdrv.c\n>>> index 57248bccadbc..2b98a173136f 100644\n>>> --- a/drivers/i2c/busses/i2c-designware-platdrv.c\n>>> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c\n>>> @@ -256,7 +256,8 @@ static int dw_i2c_plat_probe(struct\n>>> platform_device *pdev)\n>>>       struct dw_i2c_dev *dev;\n>>>       u32 acpi_speed, ht = 0;\n>>>       struct resource *mem;\n>>> -    int irq, ret;\n>>> +    int i, irq, ret;\n>>> +    const int supported_speeds[] = { 0, 100000, 400000, 1000000,\n>>> 3400000 };\n>>>       irq = platform_get_irq(pdev, 0);\n>>>       if (irq < 0)\n>>> @@ -297,9 +298,16 @@ static int dw_i2c_plat_probe(struct\n>>> platform_device *pdev)\n>>>       }\n>>>       acpi_speed = i2c_acpi_find_bus_speed(&pdev->dev);\n>>> -    /* Some broken DSTDs use 1MiHz instead of 1MHz */\n>>> -    if (acpi_speed == 1048576)\n>>> -        acpi_speed = 1000000;\n>>> +    /*\n>>> +     * Some DSTDs use a non standard speed, round down to the\n>>> lowest\n>>> +     * standard speed.\n>>> +     */\n>>> +    for (i = 1; i < ARRAY_SIZE(supported_speeds); i++) {\n>>> +        if (acpi_speed < supported_speeds[i])\n>>> +            break;\n>>> +    }\n>>> +    acpi_speed = supported_speeds[i - 1];\n>>\n>> I dunno what standard says if we may or may not use 100 kHz as a last\n>> resort even for speeds defined less than 100 kHz.\n> \n> The < 100000 case is for when i2c_acpi_find_bus_speed() returns 0, so\n> that we then keep it 0, in which case the code a bit lower will pick\n> a default. Since speeds < 100000 are clearly not valid treating them\n> as ACPI not providing any bus-speed info seems sensible to me.\n> \nI don't know how sensible values timing parameter calculation routines \nwould produce for \"bogus\" < 100 kHz ACPI speeds so picking the default \n400 kHz sounds more sensible to me as well as it used to be the default \nspeed earlier.\n\nAcked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhVyn2Dzyz9t38\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 30 Aug 2017 00:15:13 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752843AbdH2OPM (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 10:15:12 -0400","from mga04.intel.com ([192.55.52.120]:58343 \"EHLO mga04.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752428AbdH2OPL (ORCPT <rfc822;linux-i2c@vger.kernel.org>);\n\tTue, 29 Aug 2017 10:15:11 -0400","from fmsmga003.fm.intel.com ([10.253.24.29])\n\tby fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t29 Aug 2017 07:15:11 -0700","from mylly.fi.intel.com (HELO [10.237.72.56]) ([10.237.72.56])\n\tby FMSMGA003.fm.intel.com with ESMTP; 29 Aug 2017 07:15:09 -0700"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.41,445,1498546800\"; d=\"scan'208\";a=\"895182183\"","Subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","To":"Hans de Goede <hdegoede@redhat.com>,\n\tAndy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tWolfram Sang <wsa@the-dreams.de>","Cc":"linux-i2c@vger.kernel.org","References":"<20170829120835.17276-1-hdegoede@redhat.com>\n\t<1504009379.25945.142.camel@linux.intel.com>\n\t<078c7214-230e-2a68-734b-2a01003ee378@redhat.com>","From":"Jarkko Nikula <jarkko.nikula@linux.intel.com>","Message-ID":"<afe402a1-4476-edc0-8158-a6d26975fb05@linux.intel.com>","Date":"Tue, 29 Aug 2017 17:12:59 +0300","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<078c7214-230e-2a68-734b-2a01003ee378@redhat.com>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759645,"web_url":"http://patchwork.ozlabs.org/comment/1759645/","msgid":"<20170829201826.htdia6olxs3j5k66@ninjato>","list_archive_url":null,"date":"2017-08-29T20:18:26","subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","submitter":{"id":22495,"url":"http://patchwork.ozlabs.org/api/people/22495/","name":"Wolfram Sang","email":"wsa@the-dreams.de"},"content":"Hi,\n\n> > I dunno what standard says if we may or may not use 100 kHz as a last\n> > resort even for speeds defined less than 100 kHz.\n> \n> The < 100000 case is for when i2c_acpi_find_bus_speed() returns 0, so\n> that we then keep it 0, in which case the code a bit lower will pick\n> a default.\n\nThis is fine by me.\n\n> Since speeds < 100000 are clearly not valid treating them\n\nHere I wonder: Not valid because of ACPI specs? Because I2C specs surely\nallow speeds < 100kHz.\n\n> as ACPI not providing any bus-speed info seems sensible to me.\n\nRegards,\n\n   Wolfram","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhg1z0t60z9sR9\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 30 Aug 2017 06:18:31 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751280AbdH2US3 (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 16:18:29 -0400","from sauhun.de ([88.99.104.3]:46201 \"EHLO pokefinder.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750909AbdH2US3 (ORCPT <rfc822;linux-i2c@vger.kernel.org>);\n\tTue, 29 Aug 2017 16:18:29 -0400","from localhost (p54B33289.dip0.t-ipconnect.de [84.179.50.137])\n\tby pokefinder.org (Postfix) with ESMTPSA id 100A22C33B2;\n\tTue, 29 Aug 2017 22:18:28 +0200 (CEST)"],"Date":"Tue, 29 Aug 2017 22:18:26 +0200","From":"Wolfram Sang <wsa@the-dreams.de>","To":"Hans de Goede <hdegoede@redhat.com>","Cc":"Andy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>, linux-i2c@vger.kernel.org","Subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","Message-ID":"<20170829201826.htdia6olxs3j5k66@ninjato>","References":"<20170829120835.17276-1-hdegoede@redhat.com>\n\t<1504009379.25945.142.camel@linux.intel.com>\n\t<078c7214-230e-2a68-734b-2a01003ee378@redhat.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"7t4jmlr4yb56t7mi\"","Content-Disposition":"inline","In-Reply-To":"<078c7214-230e-2a68-734b-2a01003ee378@redhat.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759649,"web_url":"http://patchwork.ozlabs.org/comment/1759649/","msgid":"<3cc3df29-b2b5-4a2a-fce4-a9d2302fee54@redhat.com>","list_archive_url":null,"date":"2017-08-29T20:27:14","subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","submitter":{"id":1893,"url":"http://patchwork.ozlabs.org/api/people/1893/","name":"Hans de Goede","email":"hdegoede@redhat.com"},"content":"Hi,\n\nOn 08/29/2017 10:18 PM, Wolfram Sang wrote:\n> Hi,\n> \n>>> I dunno what standard says if we may or may not use 100 kHz as a last\n>>> resort even for speeds defined less than 100 kHz.\n>>\n>> The < 100000 case is for when i2c_acpi_find_bus_speed() returns 0, so\n>> that we then keep it 0, in which case the code a bit lower will pick\n>> a default.\n> \n> This is fine by me.\n> \n>> Since speeds < 100000 are clearly not valid treating them\n> \n> Here I wonder: Not valid because of ACPI specs? Because I2C specs surely\n> allow speeds < 100kHz.\n\nThe speed comes from an ACPI entry describing an i2c client,\nany compliant i2c client must at least support 100KHz, right ?\n\nAlternatively I could wrap the entire round-down for loop in\nan if (acpi_speed) {} block.\n\nRegards,\n\nHans","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","ext-mx05.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx05.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=hdegoede@redhat.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhgD92bdfz9sR9\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 30 Aug 2017 06:27:21 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751514AbdH2U1S (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 16:27:18 -0400","from mx1.redhat.com ([209.132.183.28]:34412 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751249AbdH2U1R (ORCPT <rfc822;linux-i2c@vger.kernel.org>);\n\tTue, 29 Aug 2017 16:27:17 -0400","from smtp.corp.redhat.com\n\t(int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 4D6962D5A13;\n\tTue, 29 Aug 2017 20:27:17 +0000 (UTC)","from dhcp-45-79.space.revspace.nl (ovpn-112-19.ams2.redhat.com\n\t[10.36.112.19])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 3AF89692B4;\n\tTue, 29 Aug 2017 20:27:16 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 4D6962D5A13","Subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","To":"Wolfram Sang <wsa@the-dreams.de>","Cc":"Andy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>, linux-i2c@vger.kernel.org","References":"<20170829120835.17276-1-hdegoede@redhat.com>\n\t<1504009379.25945.142.camel@linux.intel.com>\n\t<078c7214-230e-2a68-734b-2a01003ee378@redhat.com>\n\t<20170829201826.htdia6olxs3j5k66@ninjato>","From":"Hans de Goede <hdegoede@redhat.com>","Message-ID":"<3cc3df29-b2b5-4a2a-fce4-a9d2302fee54@redhat.com>","Date":"Tue, 29 Aug 2017 22:27:14 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170829201826.htdia6olxs3j5k66@ninjato>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.16","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.29]);\n\tTue, 29 Aug 2017 20:27:17 +0000 (UTC)","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759683,"web_url":"http://patchwork.ozlabs.org/comment/1759683/","msgid":"<20170829210048.mqcyep22tqn7t65l@ninjato>","list_archive_url":null,"date":"2017-08-29T21:00:48","subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","submitter":{"id":22495,"url":"http://patchwork.ozlabs.org/api/people/22495/","name":"Wolfram Sang","email":"wsa@the-dreams.de"},"content":"> The speed comes from an ACPI entry describing an i2c client,\n> any compliant i2c client must at least support 100KHz, right ?\n\nWell, due to flaky board design, you may not be able to utilize the max\nspeed because of interferences etc even if the devices would support it.\nSuch knowledge of flaky boards could be encoded in the ACPI tables, or?\nBut probably not in the client device, hmmm...\n\n> Alternatively I could wrap the entire round-down for loop in\n> an if (acpi_speed) {} block.\n\nI don't know enough about real-world ACPI tables to suggest a best\npractice here. I just wanted to add that busses < 100 kHz are legal from\nhow I read the specs.\n\nOh well, Jarkko liked the patch, so let's all sleep over this patch and\nif nothing else comes up, I'll apply it tomorrow or so...","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhgyq42rNz9sN7\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 30 Aug 2017 07:00:51 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751275AbdH2VAu (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 17:00:50 -0400","from sauhun.de ([88.99.104.3]:46441 \"EHLO pokefinder.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751270AbdH2VAt (ORCPT <rfc822;linux-i2c@vger.kernel.org>);\n\tTue, 29 Aug 2017 17:00:49 -0400","from localhost (p54B33289.dip0.t-ipconnect.de [84.179.50.137])\n\tby pokefinder.org (Postfix) with ESMTPSA id 939542C31F4;\n\tTue, 29 Aug 2017 23:00:48 +0200 (CEST)"],"Date":"Tue, 29 Aug 2017 23:00:48 +0200","From":"Wolfram Sang <wsa@the-dreams.de>","To":"Hans de Goede <hdegoede@redhat.com>","Cc":"Andy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>, linux-i2c@vger.kernel.org","Subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","Message-ID":"<20170829210048.mqcyep22tqn7t65l@ninjato>","References":"<20170829120835.17276-1-hdegoede@redhat.com>\n\t<1504009379.25945.142.camel@linux.intel.com>\n\t<078c7214-230e-2a68-734b-2a01003ee378@redhat.com>\n\t<20170829201826.htdia6olxs3j5k66@ninjato>\n\t<3cc3df29-b2b5-4a2a-fce4-a9d2302fee54@redhat.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"7xxyyjbdsudeshzx\"","Content-Disposition":"inline","In-Reply-To":"<3cc3df29-b2b5-4a2a-fce4-a9d2302fee54@redhat.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759804,"web_url":"http://patchwork.ozlabs.org/comment/1759804/","msgid":"<f05a083c-c8d1-352f-d084-1ccf5e37e14c@electromag.com.au>","list_archive_url":null,"date":"2017-08-30T01:23:07","subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","submitter":{"id":66145,"url":"http://patchwork.ozlabs.org/api/people/66145/","name":"Phil Reid","email":"preid@electromag.com.au"},"content":"On 30/08/2017 05:00, Wolfram Sang wrote:\n> \n>> The speed comes from an ACPI entry describing an i2c client,\n>> any compliant i2c client must at least support 100KHz, right ?\n> \n> Well, due to flaky board design, you may not be able to utilize the max\n> speed because of interferences etc even if the devices would support it.\n> Such knowledge of flaky boards could be encoded in the ACPI tables, or?\n> But probably not in the client device, hmmm...\n> \n>> Alternatively I could wrap the entire round-down for loop in\n>> an if (acpi_speed) {} block.\n> \n> I don't know enough about real-world ACPI tables to suggest a best\n> practice here. I just wanted to add that busses < 100 kHz are legal from\n> how I read the specs.\n> \n> Oh well, Jarkko liked the patch, so let's all sleep over this patch and\n> if nothing else comes up, I'll apply it tomorrow or so...\n> \n\nMy understanding is 100k is what the client must support.\nBut sometimes buses need to be run slower.\nParticularly when using range extenders.\n\neg: I have an i2c bus running over a 10m cable that needs to run at about 40k\nto be reliable.","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhnnb4NXRz9sNc\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 30 Aug 2017 11:23:15 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751290AbdH3BXO (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 29 Aug 2017 21:23:14 -0400","from anchovy2.45ru.net.au ([203.30.46.146]:37293 \"EHLO\n\tanchovy.45ru.net.au\" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org\n\twith ESMTP id S1751240AbdH3BXN (ORCPT\n\t<rfc822; linux-i2c@vger.kernel.org>); Tue, 29 Aug 2017 21:23:13 -0400","(qmail 18720 invoked by uid 5089); 30 Aug 2017 01:23:11 -0000","by simscan 1.2.0 ppid: 18639, pid: 18640, t: 0.0378s\n\tscanners: regex: 1.2.0 attach: 1.2.0 clamav: 0.88.3/m:40/d:1950","from unknown (HELO ?192.168.0.122?)\n\t(preid@electromag.com.au@203.59.230.133)\n\tby anchovy3.45ru.net.au with ESMTPA; 30 Aug 2017 01:23:10 -0000"],"Subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","To":"Wolfram Sang <wsa@the-dreams.de>, Hans de Goede <hdegoede@redhat.com>","Cc":"Andy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tJarkko Nikula <jarkko.nikula@linux.intel.com>, linux-i2c@vger.kernel.org","References":"<20170829120835.17276-1-hdegoede@redhat.com>\n\t<1504009379.25945.142.camel@linux.intel.com>\n\t<078c7214-230e-2a68-734b-2a01003ee378@redhat.com>\n\t<20170829201826.htdia6olxs3j5k66@ninjato>\n\t<3cc3df29-b2b5-4a2a-fce4-a9d2302fee54@redhat.com>\n\t<20170829210048.mqcyep22tqn7t65l@ninjato>","From":"Phil Reid <preid@electromag.com.au>","Message-ID":"<f05a083c-c8d1-352f-d084-1ccf5e37e14c@electromag.com.au>","Date":"Wed, 30 Aug 2017 09:23:07 +0800","User-Agent":"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170829210048.mqcyep22tqn7t65l@ninjato>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Language":"en-AU","Content-Transfer-Encoding":"7bit","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1759937,"web_url":"http://patchwork.ozlabs.org/comment/1759937/","msgid":"<6757ad09-e78d-8d36-3ae7-e2377971a0d4@linux.intel.com>","list_archive_url":null,"date":"2017-08-30T07:37:33","subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","submitter":{"id":43309,"url":"http://patchwork.ozlabs.org/api/people/43309/","name":"Jarkko Nikula","email":"jarkko.nikula@linux.intel.com"},"content":"On 08/30/2017 04:23 AM, Phil Reid wrote:\n> On 30/08/2017 05:00, Wolfram Sang wrote:\n>> I don't know enough about real-world ACPI tables to suggest a best\n>> practice here. I just wanted to add that busses < 100 kHz are legal from\n>> how I read the specs.\n>>\n>> Oh well, Jarkko liked the patch, so let's all sleep over this patch and\n>> if nothing else comes up, I'll apply it tomorrow or so...\n>>\n> \n> My understanding is 100k is what the client must support.\n> But sometimes buses need to be run slower.\n> Particularly when using range extenders.\n> \n> eg: I have an i2c bus running over a 10m cable that needs to run at \n> about 40k\n> to be reliable.\n> \nI acked the patch because I see it as a possibility for a regression if \nwe blindly accept slower than 100 kHz speed from ACPI without validating \ndoes that result working setup and timing parameters.\n\nIt is better to have an another patch explicitly adding support for\n< 100 kHz speeds when needed.","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xhyHw3ZxGz9s7F\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed, 30 Aug 2017 17:46:36 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751039AbdH3Hqf (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tWed, 30 Aug 2017 03:46:35 -0400","from mga14.intel.com ([192.55.52.115]:32282 \"EHLO mga14.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750839AbdH3Hqe (ORCPT <rfc822;linux-i2c@vger.kernel.org>);\n\tWed, 30 Aug 2017 03:46:34 -0400","from fmsmga003.fm.intel.com ([10.253.24.29])\n\tby fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t30 Aug 2017 00:46:34 -0700","from mylly.fi.intel.com (HELO [10.237.72.56]) ([10.237.72.56])\n\tby FMSMGA003.fm.intel.com with ESMTP; 30 Aug 2017 00:46:18 -0700"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.41,448,1498546800\"; d=\"scan'208\";a=\"895444995\"","Subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","To":"Phil Reid <preid@electromag.com.au>, Wolfram Sang <wsa@the-dreams.de>,\n\tHans de Goede <hdegoede@redhat.com>","Cc":"Andy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tlinux-i2c@vger.kernel.org","References":"<20170829120835.17276-1-hdegoede@redhat.com>\n\t<1504009379.25945.142.camel@linux.intel.com>\n\t<078c7214-230e-2a68-734b-2a01003ee378@redhat.com>\n\t<20170829201826.htdia6olxs3j5k66@ninjato>\n\t<3cc3df29-b2b5-4a2a-fce4-a9d2302fee54@redhat.com>\n\t<20170829210048.mqcyep22tqn7t65l@ninjato>\n\t<f05a083c-c8d1-352f-d084-1ccf5e37e14c@electromag.com.au>","From":"Jarkko Nikula <jarkko.nikula@linux.intel.com>","Message-ID":"<6757ad09-e78d-8d36-3ae7-e2377971a0d4@linux.intel.com>","Date":"Wed, 30 Aug 2017 10:37:33 +0300","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<f05a083c-c8d1-352f-d084-1ccf5e37e14c@electromag.com.au>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}},{"id":1761250,"web_url":"http://patchwork.ozlabs.org/comment/1761250/","msgid":"<20170831182945.ttdwpjjar6rcmlfd@ninjato>","list_archive_url":null,"date":"2017-08-31T18:29:45","subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","submitter":{"id":22495,"url":"http://patchwork.ozlabs.org/api/people/22495/","name":"Wolfram Sang","email":"wsa@the-dreams.de"},"content":"On Tue, Aug 29, 2017 at 02:08:35PM +0200, Hans de Goede wrote:\n> The Lenovo Miix2 8 DSDT contains an i2c clk / bus speed of 1700000 Hz\n> for one if its devices, which is not supported.\n> \n> This is the second DSDT to show up with an unsupported clk in a short\n> time, remove the hardcoded fix for DSDTs with a 1 MiHz clock and simply\n> always round down the clk to the nearest supported value.\n> \n> Reported-by: russianneuromancer@ya.ru\n> Fixes: 682c6c2188 (\"i2c: designware: Some broken DSTDs use 1MiHz ...\")\n> Signed-off-by: Hans de Goede <hdegoede@redhat.com>\n\nApplied to for-current, thanks!","headers":{"Return-Path":"<linux-i2c-owner@vger.kernel.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-i2c-owner@vger.kernel.org;\n\treceiver=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xjrWd66Dtz9sMN\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri,  1 Sep 2017 04:29:49 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751309AbdHaS3s (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tThu, 31 Aug 2017 14:29:48 -0400","from sauhun.de ([88.99.104.3]:54002 \"EHLO pokefinder.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750996AbdHaS3s (ORCPT <rfc822;linux-i2c@vger.kernel.org>);\n\tThu, 31 Aug 2017 14:29:48 -0400","from localhost (p54B33F3D.dip0.t-ipconnect.de [84.179.63.61])\n\tby pokefinder.org (Postfix) with ESMTPSA id 0B03C2C3619;\n\tThu, 31 Aug 2017 20:29:46 +0200 (CEST)"],"Date":"Thu, 31 Aug 2017 20:29:45 +0200","From":"Wolfram Sang <wsa@the-dreams.de>","To":"Hans de Goede <hdegoede@redhat.com>","Cc":"Jarkko Nikula <jarkko.nikula@linux.intel.com>,\n\tAndy Shevchenko <andriy.shevchenko@linux.intel.com>,\n\tlinux-i2c@vger.kernel.org","Subject":"Re: [PATCH] i2c: designware: Round down ACPI provided clk to nearest\n\tsupported clk","Message-ID":"<20170831182945.ttdwpjjar6rcmlfd@ninjato>","References":"<20170829120835.17276-1-hdegoede@redhat.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\"; boundary=\"mhzxb6tdsodjxl3r\"","Content-Disposition":"inline","In-Reply-To":"<20170829120835.17276-1-hdegoede@redhat.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"linux-i2c-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-i2c.vger.kernel.org>","X-Mailing-List":"linux-i2c@vger.kernel.org"}}]