From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752286AbcDZGnB (ORCPT ); Tue, 26 Apr 2016 02:43:01 -0400 Received: from mail-bn1on0059.outbound.protection.outlook.com ([157.56.110.59]:8547 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751221AbcDZGm7 (ORCPT ); Tue, 26 Apr 2016 02:42:59 -0400 Authentication-Results: the-dreams.de; dkim=none (message not signed) header.d=none;the-dreams.de; dmarc=none action=none header.from=caviumnetworks.com; Date: Tue, 26 Apr 2016 08:42:42 +0200 From: Jan Glauber To: Wolfram Sang CC: , , David Daney Subject: Re: [PATCH v7 03/15] i2c: octeon: Remove I2C_FUNC_SMBUS_QUICK support Message-ID: <20160426064242.GC5758@hardcore> References: <1461594824-7215-1-git-send-email-jglauber@cavium.com> <1461594824-7215-4-git-send-email-jglauber@cavium.com> <20160425221621.GI1550@katana> <20160426055845.GB5758@hardcore> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160426055845.GB5758@hardcore> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [46.223.168.231] X-ClientProxiedBy: VI1PR06CA0062.eurprd06.prod.outlook.com (10.163.160.30) To CY1PR07MB2587.namprd07.prod.outlook.com (10.167.16.137) X-MS-Office365-Filtering-Correlation-Id: 719d4478-e203-467f-7f95-08d36d9e004e X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2587;2:XpcP14ZnpO5BiKrl7XdrN5V2r+NXZ7YTerTsOqYO0wVfAnBvW0OFf5t/kJzsF7ikB8ty4swuZnshMkwXpmfg3NBFZx2/BetBW9eUSoWEwbBtontfv45AFIPZbCdt+QsBYIjAyKPYDnF116MDErW4DX4ZllIAtHO479byHZsu2DkQOMGE+J2IWsyryuKqmgMW;3:5r7V2t1PTqVWrwYzDRZ2vP0RvqcEjZSJt3TMCkE4GvWoBty+o4NltzFJNgkJ+PjONytj5haZh5dMVsEyHpHCMp/IILX1gnwTnvtlCbKRO8BNEzQbyhZa/8rX1LxIpDBe;25:7wd9cir/rqFtulbtykD8JBDvrdK8LuX2IlK8sQuOE5TAPHEGRRabEM51ehZyIs5Umw3bbWtE5yYZ0JeNdPdJ+8b3Muik6N6pbF+/qk650tfmbb3XwUzVsSU9M2n11IX7GQVt90WfQmhFIIba0xxAejKltmBSkC09kvMwwbtdqDbmPT9F9L8XSZDslZ1dzYOfI80RnnFZh+Hd/Mm8Gl441OGiuq4k5YEFVJmb0kHPsvPHXPX9jvNstJ7QWfAAiHg87V42VLUVfqPW8x074yItTO08eLl9pAJVOPD7MU5xl5n+oBvvC3FUWtLJIEgJrQZ/cGjPp+L9VLajym5SLPE/Ig== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2587; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2587;20:CLU/K2TuBm7g90lV4S0L2xMD4rXQ6Yy2hmam5q4oXho9lPebWNNgrrOU5NwP2GGcLiuThtO05IxrAEB7yeI2biCGSj6IGWJBXrcnWPI6KUFAJR8CZFnpZDfQBLds3P8hcf3xIHOUG4GWNmdgsUkG6/zCbnMAFl+VZvNQi0lSkQdSegVBzCzCofC0YwyS7LgapFx+B7Lp95Vhg1vRd2DObYBx3Yp6k0Khb/aAMY2X1wcGf1gfBWATghoVuQhAcGqrLlYLPmjuwv5ztDH5tzTMtYM1SATEX+msrxaOO3MMEz8QQWsXZ4BcLwNDPJiWa+YHobo+o0+fRlpPgSwka8BbphasLAdn6oc99hDfLveJyre4V2EmsxUo/Lo/wM/eaKgn5yT/9fv/ROibQe0rzp8NBqRED8/B7niq0JWys4QUOwU//XEsiFhdkeKfHhEgbMQfRp5gvUaflohsQSzsraLPitbQu1ciEGI7qHFxvRMcR8WzG2MCQTvFk/dfVWKhRxEsg1kYjN7TgTiqtOFggiJ6ka7tr9QWKwqo1kLnua9ABlwfsL3l+oHjrONzHLEq83qzRDscLxWkSLPXqB3oP6Cv66Un5RMyeiCQQzmLGIwBCss= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(9101521072)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046);SRVR:CY1PR07MB2587;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2587; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2587;4:ArlBydI64/WWenJVR9c+MVnPwskSdG0zvXzzKmMHCYYZMkrBS70APpNbwO3Lalrw6efCnAK0GiJsOrc1p/DjCqFh73SlIQKpVuZndt1ZhZ7xkoCdRD8PgvyM86PaQYS7W1iCiECj0wY1HiRhS5xxi2tC0eyjkljuPUNSvEoeomhpsMolTh14tu+wIqkRlzVh0MhcLrXzMYfJPEBEFvzmFqMQ4VxXxBt47PmJF3p9GZ+qT3rZieqv274oHg6mBJjFz4QYvHJ3UzQAjmEYtmLiGXGFuknE9pt3uNxa8AN/Ipm3jM/1uYMOFwFfEzaYNKMj1X2GmpCbwfXms6K4IUkwN3f6dBY73k1KevWfYkw5czBNe4LsxqvhYEFvJrvCRhKouV+vR0P695KgpuYIb9uuuA== X-Forefront-PRVS: 0924C6A0D5 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(24454002)(81166005)(76176999)(50986999)(54356999)(33656002)(97756001)(1096002)(42186005)(86362001)(110136002)(4001350100001)(189998001)(77096005)(1076002)(107886002)(9686002)(2950100001)(92566002)(46406003)(33716001)(83506001)(50466002)(19580405001)(19580395003)(47776003)(23726003)(2906002)(3846002)(586003)(6116002)(5008740100001)(66066001)(4326007)(93886004)(5004730100002)(15760500001);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR07MB2587;H:hardcore;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY1PR07MB2587;23:67+1Jd/zI7H4IdRx7ozFplz9DONCRk35g7tuTwQSa?= =?us-ascii?Q?l38Xhnr2zb5xzUVC4o83c1sJxAb8/3iKTxbgMoruyfiKNQ0gBwGYDQ35zX+x?= =?us-ascii?Q?eH5rYii8v9twV7RyNUfiCTcRGlG6hq/r9LH5D5aATZoNhbHNoZ8tlY9bfUR6?= =?us-ascii?Q?TgLiXMPbixZTAHzFmM27iBYbKB7CHYzs9cXqX52I+NftNRkGKRhs1KO4KjgX?= =?us-ascii?Q?xgtqr/1vPs9KledlhICR7IMd2cgLRSJeTLKozqUaB0z2U7UYgQrfnmKhTKO3?= =?us-ascii?Q?a4XiM2quQE6LBa+eNuXvIZmrDXjpGoMHeJsJh4rQ3FifDkZg4NNwlgMzGhiH?= =?us-ascii?Q?8P2vsDHVbgecIdhSKDEKpzhlhrJP6z2tS6EthnNLKaOjAVv3C7kNgE6NPn4+?= =?us-ascii?Q?VgVmc4Lzw1ei++H3S8b6y68prmVAawgZt4OVb03lCazUNnLoQ8poV22odJW3?= =?us-ascii?Q?5hFzAWUrLVZ/6ldMwC6r4Z9dCbL6ltfSdZwV7Pd9ZBRm9VLtF9JJu8iKiUqH?= =?us-ascii?Q?eh1a62G/ljYgBWXky6vfjAFi0TaBWZq5uAfzDrJU8tV3frtL8AkbpnkEl9jM?= =?us-ascii?Q?7rOBjKq8bM/vtd4FqCjkw2UR7CveXIM7DlVFI0UVDrtGkiSDCjlp6Fq0Y3OP?= =?us-ascii?Q?y67NCFNIQaeMJ5STfxi7QHA8lnP1bqjwrshpNsCpeAZzAWeWgHZ+kNVXhUtX?= =?us-ascii?Q?Ol17sPkCLUqH0FCmPG6pgaZWGjmbmK86EHp5/1/piwJR8kqOtyUCwntl0ewg?= =?us-ascii?Q?hUbUIFTwHIj0B38C975bb5rtw+wD2DexwECEGc5xOj9ojA31O5bLLawxIoUl?= =?us-ascii?Q?8PUphDMEluqbtHyrBFZUXx7sh2sq8D9KgyaeNO+e7pRAzWA6qatqqtHSvrYl?= =?us-ascii?Q?FGb56JV8OlwSrybtz9MJWsOeWsnY6yE0ZTYmIwJn633OlwQ7R82bmsJZDdFT?= =?us-ascii?Q?7+qXPfL7kotwcGqsGB4uVjkXFory9pxlGvLjO358l26GZ6iTQNKhU3qvm/Yu?= =?us-ascii?Q?hdH1AFPBCl8rzSiOcvlwmje/hMqTiUuIb2u4ZNP/X7q0g=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2587;5:LdJQuYceuRud8yI/PZgjhPsmljMaeTjkBlOotTcNsovDZSwR7zEvHjz4i61LS638VDEx7WwhdQmoUaRpRjBYIgjmhsfDH0D1XlXEBMOwVt5LdUWn6TDCjpjhtlUBPQoJYY/MYzimu2aBXKyQ9J2/LAAU11QnmVwQk7QRu8f4F1bZ4anvxzLZMQNCjvsDwkHZ;24:HFryP6wGEm0bOysqojv6eQ54n4CgaCg8qoPDPw//nirwxh2X3l79mq8pRYple+r31AX0t3jIfPFbU+K6PrPrmnWTv8bu5jneFo3gOuKU1pk=;7:RdaX4DSLYLe6JP0lQzgzvw82DhGnFneTQL1dGn2pHDvQnBVkzlSKi73PsF5sQ+jmTmrtfadhri72WbZNMtIh6c87OC+4t96clOo7YZkt9FpafBACj8JWoKI0Qy1qaQMXkKN7SSLoSrgk6682TCQMRcr0Or3HLzDkLldniXHE2XCfk+E1eSS5o4TkpMno8pbqYm3h+csQdfAbOs0u8tGy8/2Ngcr3Xg2kx6zR1KPoagc= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2016 06:42:55.6464 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2587 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 26, 2016 at 07:58:45AM +0200, Jan Glauber wrote: > On Tue, Apr 26, 2016 at 12:16:22AM +0200, Wolfram Sang wrote: > > On Mon, Apr 25, 2016 at 04:33:32PM +0200, Jan Glauber wrote: > > > SMBUS QUICK never worked for the read case, because EINVAL was returned > > > for a zero length message. The hardware does not support SMBUS QUICK > > > messages so disable the support and remove the zero length check. > > > > > > Signed-off-by: Jan Glauber > > > > I see better now and I think we need to drop this patch. It looks like > > the driver supports only SMBUS_QUICK_WRITE which can be used for > > scanning devices. The driver probably works with 'i2cdetect -q'. This > > will regress if I apply the patch. > > > > It seems it can't do SMBUS_QUICK_READ thus the extra check in the code. > > > > I2C_FUNC_SMBUS_QUICK should have been split up in READ and WRITE to > > support this scenario. > > > > Are my assumptions correct? > > Yes, I thought briefly about splitting SMBUS_QUICK into read-write > variants too. To me the question is if this feature is still used on modern > devices or if this is more a relict of the past. I don't know enough > about SMBUS to answer that. > > Also, the ThunderX documentation does not mention that it is supported. > The read case would be forbidden by the documentation (that was probably > the reason for adding the read EINVAL). The write case is kind of a grey > area, it might or might not work. > > I'll see what i2cdetect does. Checking on ThunderX: [root@localhost linux-aarch64]# i2cdetect -q 0 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0 using quick write commands. I will probe address range 0x03-0x77. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: 60 61 62 63 64 65 66 67 UU 69 6a 6b 6c 6d 6e 6f 70: 70 71 72 73 74 75 76 77 Address 68 is the only device (rtc clock, module loaded). Do all these other numbers make sense (although there are no devices)? --Jan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Glauber Subject: Re: [PATCH v7 03/15] i2c: octeon: Remove I2C_FUNC_SMBUS_QUICK support Date: Tue, 26 Apr 2016 08:42:42 +0200 Message-ID: <20160426064242.GC5758@hardcore> References: <1461594824-7215-1-git-send-email-jglauber@cavium.com> <1461594824-7215-4-git-send-email-jglauber@cavium.com> <20160425221621.GI1550@katana> <20160426055845.GB5758@hardcore> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: Received: from mail-bn1on0059.outbound.protection.outlook.com ([157.56.110.59]:8547 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751221AbcDZGm7 (ORCPT ); Tue, 26 Apr 2016 02:42:59 -0400 Content-Disposition: inline In-Reply-To: <20160426055845.GB5758@hardcore> Sender: linux-i2c-owner@vger.kernel.org List-Id: linux-i2c@vger.kernel.org To: Wolfram Sang Cc: linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, David Daney On Tue, Apr 26, 2016 at 07:58:45AM +0200, Jan Glauber wrote: > On Tue, Apr 26, 2016 at 12:16:22AM +0200, Wolfram Sang wrote: > > On Mon, Apr 25, 2016 at 04:33:32PM +0200, Jan Glauber wrote: > > > SMBUS QUICK never worked for the read case, because EINVAL was returned > > > for a zero length message. The hardware does not support SMBUS QUICK > > > messages so disable the support and remove the zero length check. > > > > > > Signed-off-by: Jan Glauber > > > > I see better now and I think we need to drop this patch. It looks like > > the driver supports only SMBUS_QUICK_WRITE which can be used for > > scanning devices. The driver probably works with 'i2cdetect -q'. This > > will regress if I apply the patch. > > > > It seems it can't do SMBUS_QUICK_READ thus the extra check in the code. > > > > I2C_FUNC_SMBUS_QUICK should have been split up in READ and WRITE to > > support this scenario. > > > > Are my assumptions correct? > > Yes, I thought briefly about splitting SMBUS_QUICK into read-write > variants too. To me the question is if this feature is still used on modern > devices or if this is more a relict of the past. I don't know enough > about SMBUS to answer that. > > Also, the ThunderX documentation does not mention that it is supported. > The read case would be forbidden by the documentation (that was probably > the reason for adding the read EINVAL). The write case is kind of a grey > area, it might or might not work. > > I'll see what i2cdetect does. Checking on ThunderX: [root@localhost linux-aarch64]# i2cdetect -q 0 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0 using quick write commands. I will probe address range 0x03-0x77. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60: 60 61 62 63 64 65 66 67 UU 69 6a 6b 6c 6d 6e 6f 70: 70 71 72 73 74 75 76 77 Address 68 is the only device (rtc clock, module loaded). Do all these other numbers make sense (although there are no devices)? --Jan