From: Arnd Bergmann <firstname.lastname@example.org> To: Boris Brezillon <email@example.com> Cc: Wolfram Sang <firstname.lastname@example.org>, Linux I2C <email@example.com>, Jonathan Corbet <firstname.lastname@example.org>, "open list:DOCUMENTATION" <email@example.com>, gregkh <firstname.lastname@example.org>, Przemyslaw Sroka <email@example.com>, Arkadiusz Golec <firstname.lastname@example.org>, Alan Douglas <email@example.com>, Bartosz Folta <firstname.lastname@example.org>, Damian Kos <email@example.com>, Alicja Jurasik-Urbaniak <firstname.lastname@example.org>, Cyprian Wronka <email@example.com>, Suresh Punnoose <firstname.lastname@example.org>, Rafal Ciepiela <email@example.com>, Thomas Petazzoni <firstname.lastname@example.org>, Nishanth Menon <email@example.com>, Rob Herring <firstname.lastname@example.org>, Pawel Moll <email@example.com>, Mark Rutland <firstname.lastname@example.org>, Ian Campbell <email@example.com>, Kumar Gala <firstname.lastname@example.org>, DTML <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org>, Vitor Soares <Vitor.Soares@synopsys.com>, Geert Uytterhoeven <email@example.com>, Linus Walleij <firstname.lastname@example.org>, Xiang Lin <Xiang.Lin@synaptics.com>, "open list:GPIO SUBSYSTEM" <email@example.com>, Sekhar Nori <firstname.lastname@example.org>, Przemyslaw Gaj <email@example.com>, Peter Rosin <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH v8 00/10] Add the I3C subsystem Date: Mon, 8 Oct 2018 12:47:21 +0200 [thread overview] Message-ID: <CAK8P3a2C+FHiPnHKEAanhD=RpqDG1VywTEGhpdBvvKQ8zmwdUA@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Wed, Oct 3, 2018 at 3:22 PM Boris Brezillon <firstname.lastname@example.org> wrote: > > Sorry for the huge delay between v7 and v8 despite the small amount of > things I was asked to fix/rework. > > This patch series is adding a new subsystem to support I3C devices. > > This is just adding support for basic features. Extra features will > be added afterwards. > > There are a few design choices that are worth mentioning because they > impact the way I3C device drivers can interact with their devices: > > - all functions used to send I3C/I2C frames must be called in > non-atomic context. Mainly done this way to ease implementation, but > this is still open to discussion. Please let me know if you think it's > worth considering an asynchronous model here > - the I3C bus and I3C master controller are now tightly coupled even > though they're still allocated separately. There's now a 1:1 > relationship between these objects, and the I3C master is no longer > represented under the I3C bus object. > Arnd, let me know if you had something different in mind, and I'll > rework the implementation accordingly. I looked at the entire series again and I'm rather happy with how it turned out. I've commented on a tiny issue about the readsl() that should be easy to resolve one way or another, with that you can add my Reviewed-by: Arnd Bergmann <email@example.com> There is one additional issue that we've talked about previously and that I'd like to hear about from GregKH or maybe other subsystem maintainers: In the current version, you have a single 'bus_type' object, and this is used to represent both a 'host' and a 'device'. I think we concluded that this is done in other subsystems as well, and that this is fitting here because a host (master device) can hand over being a master to another device (slave), which then becomes the host and sees this one as a slave. Also a lot of the sysfs attributes are the same because of this relationship. It also means that you get a mix of things in sysfs: /sys/devices/i3c/<bus> /sys/devices/i3c/<device> /sys/devices/i3c/<bus>/<device> which is a bit like what we have on USB where we can have hub devices that are again parents of other USB devices, but I don't think we can have i3c hubs or multiplexers in the same way, so it's only a single level. I'm ok with this model after our previous discussion and couldn't come up with a better one. If anyone else still sees it as problematic and has a better idea, please let us know now. Arnd
next prev parent reply other threads:[~2018-10-08 10:47 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-03 13:22 Boris Brezillon 2018-10-03 13:22 ` [PATCH v8 01/10] i3c: Add core I3C infrastructure Boris Brezillon 2018-10-03 13:22 ` [PATCH v8 02/10] docs: driver-api: Add I3C documentation Boris Brezillon 2018-10-03 13:22 ` [PATCH v8 03/10] i3c: Add sysfs ABI spec Boris Brezillon 2018-10-03 13:22 ` [PATCH v8 04/10] dt-bindings: i3c: Document core bindings Boris Brezillon 2018-10-03 13:22 ` [PATCH v8 05/10] dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg property Boris Brezillon 2018-10-03 18:37 ` Joe Perches 2018-10-03 18:45 ` Geert Uytterhoeven 2018-10-03 19:02 ` Joe Perches 2018-10-03 18:59 ` Boris Brezillon 2018-10-03 19:06 ` Boris Brezillon 2018-10-03 13:22 ` [PATCH v8 06/10] MAINTAINERS: Add myself as the I3C subsystem maintainer Boris Brezillon 2018-10-03 13:22 ` [PATCH v8 07/10] i3c: master: Add driver for Cadence IP Boris Brezillon 2018-10-08 10:06 ` Arnd Bergmann 2018-10-08 10:21 ` Boris Brezillon 2018-10-08 10:36 ` Arnd Bergmann 2018-10-08 12:05 ` Boris Brezillon 2018-10-03 13:22 ` [PATCH v8 08/10] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon 2018-10-03 13:22 ` [PATCH v8 09/10] gpio: Add a driver for Cadence I3C GPIO expander Boris Brezillon 2018-10-03 13:22 ` [PATCH v8 10/10] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander Boris Brezillon 2018-10-04 8:35 ` Linus Walleij 2018-10-08 10:47 ` Arnd Bergmann [this message] 2018-10-17 13:18 ` [PATCH v8 00/10] Add the I3C subsystem Boris Brezillon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAK8P3a2C+FHiPnHKEAanhD=RpqDG1VywTEGhpdBvvKQ8zmwdUA@mail.gmail.com' \ --firstname.lastname@example.org \ --cc=Vitor.Soares@synopsys.com \ --cc=Xiang.Lin@synaptics.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v8 00/10] Add the I3C subsystem' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).