Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751747AbdGaUQs (ORCPT ); Mon, 31 Jul 2017 16:16:48 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:33166 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751701AbdGaUQo (ORCPT ); Mon, 31 Jul 2017 16:16:44 -0400 MIME-Version: 1.0 In-Reply-To: <1501518290-5723-3-git-send-email-boris.brezillon@free-electrons.com> References: <1501518290-5723-1-git-send-email-boris.brezillon@free-electrons.com> <1501518290-5723-3-git-send-email-boris.brezillon@free-electrons.com> From: Arnd Bergmann Date: Mon, 31 Jul 2017 22:16:42 +0200 X-Google-Sender-Auth: b5aFZFP6nfQK94giNyWGH_Ul3kM Message-ID: Subject: Re: [RFC 2/5] i3c: Add core I3C infrastructure To: Boris Brezillon Cc: Wolfram Sang , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 929 Lines: 19 On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon wrote: > Add core infrastructure to support I3C in Linux and document it. > - I2C backward compatibility has been designed to be transparent to I2C > drivers and the I2C subsystem. The I3C master just registers an I2C > adapter which creates a new I2C bus. I'd say that, from a > representation PoV it's not ideal because what should appear as a > single I3C bus exposing I3C and I2C devices here appears as 2 > different busses connected to each other through the parenting (the > I3C master is the parent of the I2C and I3C busses). > On the other hand, I don't see a better solution if we want something > that is not invasive. Can you describe the reasons for making i3c a separate subsystem then, rather than extending the i2c subsystem to handle both i2c devices as before and also i3c devices and hosts? Arnd