From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754134AbdF0Xr7 (ORCPT <rfc822;w@1wt.eu>);
        Tue, 27 Jun 2017 19:47:59 -0400
Received: from mail-qk0-f170.google.com ([209.85.220.170]:34814 "EHLO
        mail-qk0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754117AbdF0Xrs (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 27 Jun 2017 19:47:48 -0400
MIME-Version: 1.0
In-Reply-To: <20170627090042.GA2408@katana>
References: <20170620211516.13095-1-brendanhiggins@google.com>
 <20170620211516.13095-4-brendanhiggins@google.com> <20170623184305.xqqhjgrbdmgk6lsr@ninjato>
 <CAFd5g45=O2_MgfZEkmbY-=ZZY+izxeWSuhZT+B2e08P=O+WEog@mail.gmail.com> <20170627090042.GA2408@katana>
From: Brendan Higgins <brendanhiggins@google.com>
Date: Tue, 27 Jun 2017 16:47:45 -0700
Message-ID: <CAFd5g449iu6DGvMuP8-n8C6GBbr62G6_ZYS6Lh9038EB0XO9YA@mail.gmail.com>
Subject: Re: [PATCH v11 3/4] i2c: aspeed: added driver for Aspeed I2C
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        "David S . Miller" <davem@davemloft.net>, mchehab@kernel.org,
        Joel Stanley <joel@jms.id.au>, martin.petersen@oracle.com,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        linux-i2c@vger.kernel.org, devicetree <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        OpenBMC Maillist <openbmc@lists.ozlabs.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jun 27, 2017 at 2:00 AM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> > If SCL is stuck low, how do you want to send a STOP?
>> >
>>
>> Fair point. I should probably drop that in the future and just do a
>> reset, and even then, doing a
>> reset is probably just wishful thinking. If a slave is holding down
>> SCL, we are pretty screwed.
>
> Yes, you'd need to reset the client device. And that has to be done in
> the client driver. I wonder if i2c_transfer and friends should return a
> specific error value in that case... need to think about it.
>

Well, a good first step would be to make my recovery code conform to
the struct i2c_bus_recovery_info. Is i2c_generic_scl_recovery supposed
to be part of the user interface, or is it just intended to help put the
main recovery function together?