From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752698AbdLEQnJ (ORCPT ); Tue, 5 Dec 2017 11:43:09 -0500 Received: from mail-co1nam03on0053.outbound.protection.outlook.com ([104.47.40.53]:61667 "EHLO NAM03-CO1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751288AbdLEQnB (ORCPT ); Tue, 5 Dec 2017 11:43:01 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=David.Daney@cavium.com; Subject: Re: [Bug fix] octeon-i2c driver updates To: "Zhang, Sean C. (NSB - CN/Hangzhou)" , Jan Glauber , "david.daney@cavium.com" Cc: "wsa@the-dreams.de" , "linux-i2c@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20171124131026.GA30811@hc> <20171201100630.GA3632@hc> From: David Daney Message-ID: <6f5215be-69c6-192d-7056-c0e6b29f3a33@caviumnetworks.com> Date: Tue, 5 Dec 2017 08:42:55 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [50.233.148.156] X-ClientProxiedBy: SN4PR0701CA0001.namprd07.prod.outlook.com (10.161.192.139) To MWHPR07MB3504.namprd07.prod.outlook.com (10.164.192.31) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f048fba3-2b45-4863-83a0-08d53bff3e8d X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286);SRVR:MWHPR07MB3504; X-Microsoft-Exchange-Diagnostics: 1;MWHPR07MB3504;3:Mid4+gqtwAHguejYwHkXB59HQBuFc+pMV5jT0IMW8M0LfZ9VTTbDel3YaQ4S5d7oJ7f5OZBtYKIt9cCz0sRAoryPqeP4oBBFKSs3QBU1ZfKZoLuXAxuIEQNKn8xUj6SOSFYp3SeSXIJ1LNQ/ImKtUH2i3y2gT49EtLmIaiK5CpfGhVQ6229p7iC1LDj+Zr+muywz3N1LRDCL7CoQpFqh0w0YzP4uT7EZ4jO6NKwpbLSRd0Ae1xsHthJnyNWVf4Ia;25:EOSAal09lLCB4RQSW0zgeO6CZXNW646TrN6V4Zem2SKz58U9HQ7G/vNEy7xqS7F3Xv2Dnbs8BbF3QMIO8T97OCCTtQVcFpy5vZ7fAlMQ2/fAHpkX3c9n1uh8k2EXgwhNWq50FmSeEgwrGMCHhHfWX4Rr+rb40sGQrywYIokqjpyk6GpOX/6UpF+5zW0xP4x/S5dkXh18aOPA777xr09ODEaeWaEaZ0ipVKuLQGLwRKjs636o582bNRJSQ3+zufele5sfOeo5aXEsnOk5Cg//tPat+ZpvV40l+pCYW6X4krbGJUzaIX+Nyv5bPkuQCZaT4W0aGQ5Vih1SOuyIHZZD5w==;31:CtmqA9LW38CQXNFibxBtbsL9Qslf1UQJeg8Q1a0kkQuX6l+PKoaj2onLGJ5ZM6UkhQxVzDTYk4cyiVYvVoLLz8wA36AkctPNN6sJg7Rtn8jCTY9UFnMgXhexfDZ6Gkm283iBAzIT7iY9INiY8Z7N8UnMQ3ewLmrHAfQ7hH15eeuxylD+WWWNYlwDLR9zb+GW0NR3hV8v8jaVjRA94kTrqCrS6Yzq8wxANtV8QxOM5PM= X-MS-TrafficTypeDiagnostic: MWHPR07MB3504: X-Microsoft-Exchange-Diagnostics: 1;MWHPR07MB3504;20:BgPa+gwVNt/33YfOmk8KZfUkxpBEEQ6HZLNEJtccnVIjikJ/1F0tlQUx5HNeHEciHm8Pso8y5WOk16o4VM0pMnQ7rljcHOZb5mDNTmmPAjSxbzRX4nKMlrvsBENR9kmo88s9eTq5H5E9ETK+OgmBgItPmWSlDg41SreeAFxAqyFZOUTIVWwxTt0hlbCJPDphU5WcuzQvmcxSGd7Fqu3fq3S+ABY6e7+BuVl0bzOhXlsjxSYSkJIqJ5zLoXlPmnMOwIJQMasCTEgN59R0XsJQt23Sw4qs33Tb2fQUqbmBX+sVQ/CJcusySGZ/s83q3AMXspxNQCRtSq8LkKrs31ZkrUmoHJTWtSlu45oiKIe0wZ+IvsS7Dv3qO7urtOGI0UXoWpcLiQ4159VH+y0zx9TSKtJDcG5tWjfK7oIrONUKHDUfmaWcff07xBwS1wOFxRmMLNl7/SlwheWy8SqsMWLyo6DtpR4aNmYGIsynUXeun69VZlxQ64twOM+Zw22NIyGMlXFZ49SgI/QbM0hAMtbvreDmJ0iac7EpI4vpXHbXvbZhnEN30dFNjVZhnUVPfMk2999b1U5nhXKILIpEv1+aoB3kql+L2nDZjdDTYPYBR7s= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(9452136761055)(82608151540597)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(10201501046)(3002001)(3231022)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011);SRVR:MWHPR07MB3504;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:MWHPR07MB3504; X-Microsoft-Exchange-Diagnostics: 1;MWHPR07MB3504;4:xUb33F+NDfKj+Fz9y5ZMMzlzF1H6AkqgPByTWtVyQYV7CtQn5vI7+pkwwVW9t5KiUCFzwCAZR225WFGMXdpgHlObsRKGsJWvEIvdV4sI5ZljXf9vWTrOhhtVKhWGtdcTa/AG7H9bDRmN+7e8ZIWsiY5srBqPGohtT7DAHoRJe49hYwHXGiI3RYxHaoXGitoYv/hxJ3+HtlGthMNTban39d+9gdf6buMtnl7Z1bxhZ6FiN3YUEJDWvt0aDlwIhbffCQH52lfc1an03xMIPvZotKGmRRVglgY/b1zMUrH1XUjxq7WCyJM9BWrhp4QvxyjcLV9y9+xkDpPsk9Tn5mOpWG41JQJuDLbIas12/5usoeYvwvzlMH0XNOPrkK7aXpb1 X-Forefront-PRVS: 0512CC5201 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(346002)(376002)(366004)(54094003)(51874003)(24454002)(13464003)(31014005)(6506006)(66066001)(50466002)(575784001)(31696002)(64126003)(106356001)(47776003)(105586002)(69596002)(33646002)(316002)(23676004)(97736004)(52146003)(65806001)(65956001)(58126008)(2501003)(110136005)(54906003)(6486002)(53546010)(6246003)(2906002)(93886005)(2486003)(2870700001)(52116002)(76176011)(16526018)(5890100001)(4326008)(7736002)(6512007)(81156014)(15650500001)(2950100002)(305945005)(6666003)(65826007)(42882006)(81166006)(8676002)(3846002)(6116002)(5660300001)(25786009)(478600001)(8936002)(67846002)(229853002)(83506002)(68736007)(72206003)(53416004)(31686004)(36756003)(101416001)(53936002);DIR:OUT;SFP:1101;SCL:1;SRVR:MWHPR07MB3504;H:ddl.caveonetworks.com;FPR:;SPF:None;PTR:InfoNoRecords;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjA3TUIzNTA0OzIzOlVKQkYwMUswMkZMSmUwc2k0L2xidmpPS1BO?= =?utf-8?B?eTVsRXZROGNiQWc4YTdPRkU1ZmNpZEhYVEc4QVhWSWZHVHhVUFYyV2JabitS?= =?utf-8?B?bXR3azB3aXhHOCtaWEV0eEFqTlRtek5wOGlXWjZKZ2NyZFdwdmlTYjdEWXJt?= =?utf-8?B?c21QQzFVUDBTOUIrQWlNUUFuazB3N05tVjNpeFpCUk5ycHNKVE5jdHNHaHgv?= =?utf-8?B?Z1hJbG9LZUFYNFd4MmZZS2gwVjNzWWdSODBSMlNocjd6Zlo3M1lRSS80S3VV?= =?utf-8?B?OVpPZ1ZqMEZOY3JuYm0yM0l5dk5UMW1SQkpOOVNrS3RzNlNybU5LZWZYMmQ0?= =?utf-8?B?WHVzcFJZMFVvVkk1ai9IVTZjelV0S0x6VlFQbmZqaDc2azBsU0VkQWtlL1hy?= =?utf-8?B?NVl3ZkdnWFp4SHVDYndnS2dycnNMblpSMExNSjhnMkNoQ3Y0WUsvRWx1V25R?= =?utf-8?B?RU1NWEhuVTVoV2xIY3JTbjcyWWdkYStlb0xFd1N1ZDkvK1hqU3pkZ0Y3dWc2?= =?utf-8?B?anAyaTRtb2x0bHhtclB6UGRTa2JxY05mbTQ1SEJ6dVI2dXYwdFh2YXhzLzR3?= =?utf-8?B?Mm1GazZtMmJqb2pSK3VhUml4SUx4bnBOZ2MrYXoxN0gwN0VJdzB0bkRzUS9l?= =?utf-8?B?MHpQWkI3ODZvb0hPWW5HZzExRkdQWVVueEUzVEUrZk8xUDExQUd2SHFuYjV4?= =?utf-8?B?c2NtTTNUdVpOTEVvMU5ESjlVSEdvL1ZVb1NwTnU3QzgzalU3RUlFdTBpQU5t?= =?utf-8?B?WXFWd1daeHZ0eUJyMURacURnM2xYVWlQdEVzaklQcFpFV0xkVFk0RVdSRzk2?= =?utf-8?B?dlpxTGpSYmxCSTM1S0lmTDZ3SENVVzRPUkFQNjMzQ1NZc3JtSmlJWG1KS1pX?= =?utf-8?B?WTRsMEZYbU15NGw5UXhFQjJvWFdiMW9CTGJmY0FJQkU1UGhMK0d4Uy9XVDNC?= =?utf-8?B?MENna0Z3Ny9rVGtqNktiL3dUYWIraVl2Wit3YnRNREl4RDIzcnFkMS9sZldY?= =?utf-8?B?WXVxV0JRNGg5T3R0bWYyVk1zeVMrL2UvVDFkb3hzME8xVFliT0hJTXJUTDlW?= =?utf-8?B?YlZvdnhkcklBZXQ5UlpCbi9FbFYrdDA2SEJvOEEwZ3JWNkxVbTlHVk02YzRH?= =?utf-8?B?bUhBd2V4VW1UZUIvTWY2bTBUVU5Qdml2R2pIMk1EakU4M2lnaGlmcEFMaEda?= =?utf-8?B?eFVqYWdNZllHSWYrckNVbEJGT3VhcFZLaVppRlUwRUhuTmFWTGlsR0JWd0V3?= =?utf-8?B?cjJiektnV3E3QWlMc0R2QWQzR2FuL2loK0trRFB4UE9mNVRyWjVVSjlqcEo5?= =?utf-8?B?RVpOU2FpbU03dFlwNkhGdHNiMndsM1MzSDFodjczeThXRmV0S3Y2Qit5cEhy?= =?utf-8?B?MThlVEJlQWY1U3kvN0ZodmtJdFREZW9kS1V1TThJSUFvUnFoSWlJZ2N6THd2?= =?utf-8?B?eHZIZ2xoclRRdjBGMVlOaHdMNW9OSmx4QjVWRk4wRE5wQ1R6c3lyRENpdHVD?= =?utf-8?B?SjNLY2JSWW45ejhpeXRxcjMwK3lFaUVYY25PU1RhdTh0Z1ZtYUgwbzlnSXNP?= =?utf-8?B?V2lieGMycWllaHc1ajFvY09QbjFDdmpBZEdVRWU5TW1lQnYzdFVKanJoN1I0?= =?utf-8?B?TGN5RHlWMEljZ2ZVVlNUQU84UUtjRFNEeGlkeVI4YVQwQ0oxcjhnS2cvNFJz?= =?utf-8?B?ZHg1STgvRlVvSFduNUs5NUFPU0JSTVJKdldjeTFDb29aY1hZckdiRlhycFFp?= =?utf-8?B?NmZlbTBVVXhKUTBjM0lwN1hFRUllZ1Q1TXFPeDhESys2Y3NlNzN2M2NXbzNE?= =?utf-8?B?QjJIMjAzVWoyeGlpNytRRGtoQmg3OUh2YS9CRFhzYkdPRVNaR25DMndXVElQ?= =?utf-8?B?RkR2MzB1dzY4Qmc1SGZrUEx2dXJkWEpQdHhweG9zNjl3dzJhN3crKzRWWEQz?= =?utf-8?B?ZVlxaklZNWgvUWoyb0pLTlhtdjF2L29mWXNlQ1Y5eEt5dCtLekdNOGh1cmxi?= =?utf-8?B?M1F1SVBNZUc4WVRyUDNLdFl6ZHlpbmsrR29BQUR2Y2hrMExZSlIrME9EOHpZ?= =?utf-8?B?L0E2eFpuUHlYeTBNRmJkOFgzeVBMcEU5SHRTWFU4WGZWaUE4TmI2TkdLK0hT?= =?utf-8?Q?oPViL/G/Lzpx7PNsJnuqiOk=3D?= X-Microsoft-Exchange-Diagnostics: 1;MWHPR07MB3504;6:vwAgDhdqmUZGwGFCeZd17sHCXXQUXJGzFK9artM00Wy4Sea+2wsurUEWFIVslJFknl13FlFMr3dv2YXN/X6cds0W/hATlTYw48X7CNa1fB9NR7oGzPL3vkxxbHm/3wKyrksvDibTc3ZavLBfx/jViOc61xWdXEEPYwaPO5XIu+45avgPQYSk6IVLvGrt8wbZNDccAVxYivGGoK2CcIrRZBNKSy/gTviN5cFpEi4lHPWHBr7YgvivzemDBrRGihySzOgs48IC60m0I9zpkbDC16C1dW6UGDIO9mz0QH8UgXW6X5vegkDtEUh+F2BiYxRjYiwUT2+Iml+Hy01l/RM5riCWw8PpuMT4PUjy1xagqh4=;5:QrgOWVNfpzRIUvREptt78apXXlC9XIxBUXE4DzV90V6GvuICw9odB2Ktn5+PduNg+G7swe4xrd2nHUnyO2DTLdiaxehG6Qk6entLt1fIZA0CvXPaPGe02nEt2jN2ogPwvzhD4MoK+Yksz+TyoIox7U0pt5xNY/xDK9sWIKyLfog=;24:/cew8FRKtiBBBHa1PLqHiJHsmJboSOM4V/6gitwFlELtiVkenAuGZ6oD8snksDwkBrxLUQTAvqFetgUAmQH91kG89hXJ/JKDl/mi0UUXxc8=;7:dlS4ne6XnvW4z35PNq2Eea5ZMhQA/Ue9fhx81WB44DMpRcHpjkGg0z4VVclwyNv1X77MlANbK0HZBN+Gdr9uDie2bmvcY/Xa6Qn9hB1y45+Uxbn2zORhs9+Da11SxFEo6ERrnUIUEGWThubQw0xWOdwoEVoMrW+z876H4XJQxSl24+9BEB1l6LSOUs2cxawS/X8PC+7IyOQVrvLy//BjDwnziegxauu3UQcXT1EYFQD1X7LGOC5MnmB2tmAm4uyf SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2017 16:42:58.7922 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f048fba3-2b45-4863-83a0-08d53bff3e8d X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR07MB3504 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/04/2017 10:44 PM, Zhang, Sean C. (NSB - CN/Hangzhou) wrote: > Hi Jan, > > Thanks for your comments, I get your point for the second point (retry of START after recovery). > > Hi David, > For the issue as the first one, would you give your further comments? Thanks in advance. > > I have an environment with CN6780 (TWSI core has property: compatible = "cavium,octeon-3860-twsi"), > And encounter below problem: > During i2c-octeon driver probing, this TWSI core original status is 0x20 (this may induced by uboot), > And octeon_i2c_init_lowlevel() function in octeon_i2c_probe() is not enough to recover the I2C bus, > If go without full recovery of octeon_i2c_recovery(), the following octeon_i2c_hlc_write(), > octeon_i2c_hlc_read(), octeon_i2c_hlc_comp_read() and octeon_i2c_hlc_comp_write() will goes error, > because these functions has no bus recovery step. > While after replace octeon_i2c_init_lowlevel() with octeon_i2c_recovery() in octeon_i2c_probe(), the > problem has gone. > > Once more, this octeon_i2c_recovery() can also recover dead lock (I2C slave device stuck low SCL) issue, > so I think use octeon_i2c_recovery() instead will be stronger. I don't want to do a bus reset unconditionally, as it is currently working well on many systems. Perhaps you could add a module parameter to enable the recovery mode on probe as an option. Would that work or be acceptable? Thanks, David Daney > > BR, > Sean Zhang > > > -----Original Message----- > From: Jan Glauber [mailto:jan.glauber@caviumnetworks.com] > Sent: Friday, December 01, 2017 6:07 PM > To: Zhang, Sean C. (NSB - CN/Hangzhou) > Cc: david.daney@cavium.com; wsa@the-dreams.de; linux-i2c@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [Bug fix] octeon-i2c driver updates > > Hi Sean, > > as you try to solve two different issues I suggest that you create one > patch per issue. > > For the second point (retry of START after recovery) I would still like > to hear Wolfram's opinion. I would assume that any i2c user should > be well aware of -EAGAIN, so I wonder if it is worth the additional > complexity of the retry logic. > > Also, the first issue changes Octeon MIPS which I'm not able to test, > so David needs to be involved here. > > thanks, > Jan > > On Thu, Nov 30, 2017 at 01:56:09AM +0000, Zhang, Sean C. (NSB - CN/Hangzhou) wrote: >> Hi Jan, >> >> Any other comments for this patch? >> >> BR, >> Sean Zhang >> >> -----Original Message----- >> From: Zhang, Sean C. (NSB - CN/Hangzhou) >> Sent: Monday, November 27, 2017 4:38 PM >> To: 'Jan Glauber' >> Cc: david.daney@cavium.com; wsa@the-dreams.de; linux-i2c@vger.kernel.org; linux-kernel@vger.kernel.org >> Subject: RE: [Bug fix] octeon-i2c driver updates >> >> Hi Jan, >> >> There are two points in this patch. >> >> Point 1. As you see, replaced octeon_i2c_init_lowlevel() by recover bus status if TWSI controller is not IDLE. >> Please take a scenario like this: when system soft reset without I2C slave reset, maybe make this I2C bus >> dead lock occurred (I2C slave device stuck low SCL) in chance. Then during system goes up and I2C slave >> device creating process, if this I2C slave device has a register with less than 8 bytes to read, but I2C bus was >> still stuck low SCL by last system reset, then the read will failed and this I2C slave device cannot be created. >> If bus recovered before the reading process, this failure can be fixed. >> >> Function flow explanation shown as below: >> >> a. System reset without I2C slave device reset >> --make SCL stuck low by I2C slave device >> ...... >> b. octeon_i2c_probe（） >> -- octeon_i2c_init_lowlevel //reset TWSI core, but SCL still stuck low by. >> ...... >> >> c. Another I2C slave device creating process >> octeon_i2c_xfer() >> -- octeon_i2c_hlc_comp_read() //failed due to SCL stuck low. >> >> If full recovery executed in octeon_i2c_probe（), above failure can be avoided. >> >> >> Point 2. octeon_i2c_recovery() is used in octeon_i2c_start() error branch, in the case of octeon_i2c_recovery() >> successful, octeon_i2c_start() will return -EAGAIN, and then octeon_i2c_xfer() return with error. I understand this like >> this: if octeon_i2c_recovery() successful, then i2c START signal can be sent again, and all following step can be continue, >> octeon_i2c_xfer() should not return error from this condition. >> >> BR, >> Sean Zhang >> >> -----Original Message----- >> From: Jan Glauber [mailto:jan.glauber@caviumnetworks.com] >> Sent: Friday, November 24, 2017 9:10 PM >> To: Zhang, Sean C. (NSB - CN/Hangzhou) >> Cc: david.daney@cavium.com; wsa@the-dreams.de; linux-i2c@vger.kernel.org; linux-kernel@vger.kernel.org >> Subject: Re: [Bug fix] octeon-i2c driver updates >> >> On Thu, Nov 23, 2017 at 11:42:36AM +0000, Zhang, Sean C. (NSB - CN/Hangzhou) wrote: >>> Dear Maintainer, >>> >>> For octeon TWSI controller, I found below two cases, maybe can be improved. >> >> Hi Sean, >> >> form the description below this looks like you're fixing a bug. Can you >> elaborate on when the I2C bus dead lock occurs. Is it always happening? >> >> What I don't like about the patch is that you're removing >> octeon_i2c_init_lowlevel() from the probe and replacing it by _always_ >> going through a full recovery. Why is this neccessary? >> >> Regards, >> Jan >> >>> >>> >From 09d9f0ce658d7f6a50d1af352dde619c29bc8bcf Mon Sep 17 00:00:00 2001 >>> From: hgt463 >>> Date: Thu, 23 Nov 2017 18:46:09 +0800 >>> Subject: [PATCH] Driver updates: >>> - In the case of I2C bus dead lock occurred during driver probing, >>> it is better try to recovery it. so added bus recovery step in >>> octeon_i2c_probe(); >>> - The purpose of function octeon_i2c_start() is to send START, so after >>> bus recovery, also need try to send START again. >>> >>> Signed-off-by: hgt463 >>> --- >>> drivers/i2c/busses/i2c-octeon-core.c | 31 ++++++++++++++++++++++++++++++- >>> drivers/i2c/busses/i2c-octeon-platdrv.c | 15 +++++++++------ >>> 2 files changed, 39 insertions(+), 7 deletions(-) >>> >>> diff --git a/drivers/i2c/busses/i2c-octeon-core.c b/drivers/i2c/busses/i2c-octeon-core.c >>> index 1d87757..3ae1e03 100644 >>> --- a/drivers/i2c/busses/i2c-octeon-core.c >>> +++ b/drivers/i2c/busses/i2c-octeon-core.c >>> @@ -255,6 +255,35 @@ static int octeon_i2c_recovery(struct octeon_i2c *i2c) >>> return ret; >>> } >>> >>> +/* >>> + * octeon_i2c_start_retry - send START to the bus after bus recovery. >>> + * @i2c: The struct octeon_i2c >>> + * >>> + * Returns 0 on success, otherwise a negative errno. >>> + */ >>> +static int octeon_i2c_start_retry(struct octeon_i2c *i2c) >>> +{ >>> + int ret; >>> + u8 stat; >>> + >>> + ret = octeon_i2c_recovery(i2c); >>> + if (ret) >>> + goto error; >>> + >>> + octeon_i2c_ctl_write(i2c, TWSI_CTL_ENAB | TWSI_CTL_STA); >>> + ret = octeon_i2c_wait(i2c); >>> + if (ret) >>> + goto error; >>> + >>> + stat = octeon_i2c_stat_read(i2c); >>> + if (stat == STAT_START || stat == STAT_REP_START) >>> + /* START successful, bail out */ >>> + return 0; >>> + >>> +error: >>> + return (ret) ? ret : -EAGAIN; >>> +} >>> + >>> /** >>> * octeon_i2c_start - send START to the bus >>> * @i2c: The struct octeon_i2c >>> @@ -280,7 +309,7 @@ static int octeon_i2c_start(struct octeon_i2c *i2c) >>> >>> error: >>> /* START failed, try to recover */ >>> - ret = octeon_i2c_recovery(i2c); >>> + ret = octeon_i2c_start_retry(i2c); >>> return (ret) ? ret : -EAGAIN; >>> } >>> >>> diff --git a/drivers/i2c/busses/i2c-octeon-platdrv.c b/drivers/i2c/busses/i2c-octeon-platdrv.c >>> index 64bda83..98063af 100644 >>> --- a/drivers/i2c/busses/i2c-octeon-platdrv.c >>> +++ b/drivers/i2c/busses/i2c-octeon-platdrv.c >>> @@ -228,12 +228,6 @@ static int octeon_i2c_probe(struct platform_device *pdev) >>> if (OCTEON_IS_MODEL(OCTEON_CN38XX)) >>> i2c->broken_irq_check = true; >>> >>> - result = octeon_i2c_init_lowlevel(i2c); >>> - if (result) { >>> - dev_err(i2c->dev, "init low level failed\n"); >>> - goto out; >>> - } >>> - >>> octeon_i2c_set_clock(i2c); >>> >>> i2c->adap = octeon_i2c_ops; >>> @@ -245,6 +239,15 @@ static int octeon_i2c_probe(struct platform_device *pdev) >>> i2c_set_adapdata(&i2c->adap, i2c); >>> platform_set_drvdata(pdev, i2c); >>> >>> + stat = octeon_i2c_stat_read(i2c); >>> + if (stat != STAT_IDLE) { >>> + result = octeon_i2c_recovery(i2c); >>> + if (result) { >>> + dev_err(i2c->dev, "octeon i2c recovery failed\n"); >>> + goto out; >>> + } >>> + } >>> + >>> result = i2c_add_adapter(&i2c->adap); >>> if (result < 0) >>> goto out; >>> >>> >>> Attached patch for you review. Thanks in advance. >>> >>> BR, >>> Sean Zhang >> >>