From: Vitor Soares <Vitor.Soares@synopsys.com> To: Boris Brezillon <boris.brezillon@collabora.com> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>, Jose Abreu <Jose.Abreu@synopsys.com>, Joao Pinto <Joao.Pinto@synopsys.com>, "arnd@arndb.de" <arnd@arndb.de>, "wsa@the-dreams.de" <wsa@the-dreams.de>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "bbrezillon@kernel.org" <bbrezillon@kernel.org>, "broonie@kernel.org" <broonie@kernel.org> Subject: RE: [RFC v2 0/4] Introduce i3c device userspace interface Date: Mon, 17 Feb 2020 15:32:55 +0000 [thread overview] Message-ID: <CH2PR12MB4216459E37F9AB1AAF0B2EFDAE160@CH2PR12MB4216.namprd12.prod.outlook.com> (raw) In-Reply-To: <20200217155141.08e87b3f@collabora.com> Hi Boris, From: Boris Brezillon <boris.brezillon@collabora.com> Date: Mon, Feb 17, 2020 at 14:51:41 > Hello Vitor, > > Sorry for taking so long to reply, and thanks for working on that topic. > > On Wed, 29 Jan 2020 13:17:31 +0100 > Vitor Soares <Vitor.Soares@synopsys.com> wrote: > > > For today there is no way to use i3c devices from user space and > > the introduction of such API will help developers during the i3c device > > or i3c host controllers development. > > > > The i3cdev module is highly based on i2c-dev and yet I tried to address > > the concerns raised in [1]. > > > > NOTES: > > - The i3cdev dynamically request an unused major number. > > > > - The i3c devices are dynamically exposed/removed from dev/ folder based > > on if they have a device driver bound to it. > > May I ask why you need to automatically bind devices to the i3cdev > driver when they don't have a driver matching the device id > loaded/compiled-in? If we get the i3c subsystem to generate proper > uevents we should be able to load the i3cdev module and bind the device > to this driver using a udev rule. My idea was to expose every device to user-space by default so we can test them without a driver (more or less the i2c use case) but as we agreed during the i3c subsystem only expose devices that doesn't have device driver. I considered to have a uevent but to expose the devices by default it would required something generic, what I didn't figure out and tend to follow the i2c-dev module. With this current approach even if a device has a driver we can unbind it through the Sysfs and have access from user space which I found useful for debug. > > Regards, > > Boris
WARNING: multiple messages have this Message-ID (diff)
From: Vitor Soares <Vitor.Soares@synopsys.com> To: Boris Brezillon <boris.brezillon@collabora.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com>, Joao Pinto <Joao.Pinto@synopsys.com>, "arnd@arndb.de" <arnd@arndb.de>, "wsa@the-dreams.de" <wsa@the-dreams.de>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "bbrezillon@kernel.org" <bbrezillon@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "broonie@kernel.org" <broonie@kernel.org>, "linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org> Subject: RE: [RFC v2 0/4] Introduce i3c device userspace interface Date: Mon, 17 Feb 2020 15:32:55 +0000 [thread overview] Message-ID: <CH2PR12MB4216459E37F9AB1AAF0B2EFDAE160@CH2PR12MB4216.namprd12.prod.outlook.com> (raw) In-Reply-To: <20200217155141.08e87b3f@collabora.com> Hi Boris, From: Boris Brezillon <boris.brezillon@collabora.com> Date: Mon, Feb 17, 2020 at 14:51:41 > Hello Vitor, > > Sorry for taking so long to reply, and thanks for working on that topic. > > On Wed, 29 Jan 2020 13:17:31 +0100 > Vitor Soares <Vitor.Soares@synopsys.com> wrote: > > > For today there is no way to use i3c devices from user space and > > the introduction of such API will help developers during the i3c device > > or i3c host controllers development. > > > > The i3cdev module is highly based on i2c-dev and yet I tried to address > > the concerns raised in [1]. > > > > NOTES: > > - The i3cdev dynamically request an unused major number. > > > > - The i3c devices are dynamically exposed/removed from dev/ folder based > > on if they have a device driver bound to it. > > May I ask why you need to automatically bind devices to the i3cdev > driver when they don't have a driver matching the device id > loaded/compiled-in? If we get the i3c subsystem to generate proper > uevents we should be able to load the i3cdev module and bind the device > to this driver using a udev rule. My idea was to expose every device to user-space by default so we can test them without a driver (more or less the i2c use case) but as we agreed during the i3c subsystem only expose devices that doesn't have device driver. I considered to have a uevent but to expose the devices by default it would required something generic, what I didn't figure out and tend to follow the i2c-dev module. With this current approach even if a device has a driver we can unbind it through the Sysfs and have access from user space which I found useful for debug. > > Regards, > > Boris _______________________________________________ linux-i3c mailing list linux-i3c@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2020-02-17 15:33 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-29 12:17 [RFC v2 0/4] Introduce i3c device userspace interface Vitor Soares 2020-01-29 12:17 ` Vitor Soares 2020-01-29 12:17 ` [RFC v2 1/4] i3c: master: export i3c_masterdev_type Vitor Soares 2020-01-29 12:17 ` Vitor Soares 2020-02-17 14:56 ` Boris Brezillon 2020-02-17 14:56 ` Boris Brezillon 2020-02-17 14:59 ` Boris Brezillon 2020-02-17 14:59 ` Boris Brezillon 2020-01-29 12:17 ` [RFC v2 2/4] i3c: master: export i3c_bus_type symbol Vitor Soares 2020-01-29 12:17 ` Vitor Soares 2020-01-29 12:17 ` [RFC v2 3/4] i3c: master: add i3c_for_each_dev helper Vitor Soares 2020-01-29 12:17 ` Vitor Soares 2020-01-29 12:17 ` [RFC v2 4/4] i3c: add i3cdev module to expose i3c dev in /dev Vitor Soares 2020-01-29 12:17 ` Vitor Soares 2020-01-29 14:30 ` Arnd Bergmann 2020-01-29 14:30 ` Arnd Bergmann 2020-01-29 17:00 ` Vitor Soares 2020-01-29 17:00 ` Vitor Soares 2020-01-29 19:39 ` Arnd Bergmann 2020-01-29 19:39 ` Arnd Bergmann 2020-02-04 13:19 ` Vitor Soares 2020-02-04 13:19 ` Vitor Soares 2020-02-17 15:26 ` Boris Brezillon 2020-02-17 15:26 ` Boris Brezillon 2020-02-17 14:51 ` [RFC v2 0/4] Introduce i3c device userspace interface Boris Brezillon 2020-02-17 14:51 ` Boris Brezillon 2020-02-17 15:06 ` Arnd Bergmann 2020-02-17 15:06 ` Arnd Bergmann 2020-02-17 15:36 ` Boris Brezillon 2020-02-17 15:36 ` Boris Brezillon 2020-02-17 15:55 ` Vitor Soares 2020-02-17 15:55 ` Vitor Soares 2020-02-17 16:03 ` gregkh 2020-02-17 16:03 ` gregkh 2020-02-17 16:12 ` Vitor Soares 2020-02-17 16:12 ` Vitor Soares 2020-02-17 16:23 ` Boris Brezillon 2020-02-17 16:23 ` Boris Brezillon 2020-02-17 16:31 ` Arnd Bergmann 2020-02-17 16:31 ` Arnd Bergmann 2020-02-17 17:06 ` Boris Brezillon 2020-02-17 17:06 ` Boris Brezillon 2020-02-17 16:19 ` Arnd Bergmann 2020-02-17 16:19 ` Arnd Bergmann 2020-02-17 16:34 ` Boris Brezillon 2020-02-17 16:34 ` Boris Brezillon 2020-02-17 15:32 ` Vitor Soares [this message] 2020-02-17 15:32 ` Vitor Soares 2020-02-17 15:52 ` Boris Brezillon 2020-02-17 15:52 ` Boris Brezillon 2020-02-17 17:37 ` Boris Brezillon 2020-02-17 17:37 ` 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=CH2PR12MB4216459E37F9AB1AAF0B2EFDAE160@CH2PR12MB4216.namprd12.prod.outlook.com \ --to=vitor.soares@synopsys.com \ --cc=Joao.Pinto@synopsys.com \ --cc=Jose.Abreu@synopsys.com \ --cc=arnd@arndb.de \ --cc=bbrezillon@kernel.org \ --cc=boris.brezillon@collabora.com \ --cc=broonie@kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=linux-i3c@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=wsa@the-dreams.de \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.