Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752576AbdHAVrx convert rfc822-to-8bit (ORCPT ); Tue, 1 Aug 2017 17:47:53 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:53579 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752012AbdHAVrv (ORCPT ); Tue, 1 Aug 2017 17:47:51 -0400 Date: Tue, 1 Aug 2017 23:47:38 +0200 From: Boris Brezillon To: Wolfram Sang Cc: "Andrew F. Davis" , Arnd Bergmann , linux-i2c@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Greg Kroah-Hartman , Przemyslaw Sroka , Arkadiusz Golec , Alan Douglas , Bartosz Folta , Damian Kos , Alicja Jurasik-Urbaniak , Jan Kotas , Cyprian Wronka , Alexandre Belloni , Thomas Petazzoni , Nishanth Menon , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org, Linux Kernel Mailing List Subject: Re: [RFC 2/5] i3c: Add core I3C infrastructure Message-ID: <20170801234738.148a874c@bbrezillon> In-Reply-To: <20170801172703.GA2737@katana> References: <1501518290-5723-1-git-send-email-boris.brezillon@free-electrons.com> <1501518290-5723-3-git-send-email-boris.brezillon@free-electrons.com> <20170731231509.77d1fba4@bbrezillon> <20170731214211.GA11776@tetsubishi> <1538596b-80ed-7800-db97-70e73b90b9e2@ti.com> <20170801172703.GA2737@katana> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 841 Lines: 24 Le Tue, 1 Aug 2017 19:27:03 +0200, Wolfram Sang a écrit : > > I'm surprised they didn't allow for slave clock stretching when > > communicating with a legacy i2c device, it will prohibit use of a rather > > large class of devices. :( > > Yes, but I3C is push/pull IIRC. It is. > > > As for interrupts you are always free to wire up an out-of-band > > interrupt like before. :) > > Yes, my wording was a bit too strong. It is possible, sure. Yet, I > understood that one of the features of I3C is to have in-band interrupt > support. We will see if the demand for backward compatibility or "saving > pins" is higher. > Indeed, you can use in-band interrupts if your device is able to generate them, but that doesn't prevent I3C device designers from using an external pin to signal interrupts if they prefer.