From: Boris Brezillon <boris.brezillon@bootlin.com>
To: vitor <vitor.soares@synopsys.com>
Cc: Wolfram Sang <wsa@the-dreams.de>, <linux-i2c@vger.kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>, <linux-doc@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Przemyslaw Sroka <psroka@cadence.com>,
Arkadiusz Golec <agolec@cadence.com>,
Alan Douglas <adouglas@cadence.com>,
Bartosz Folta <bfolta@cadence.com>, Damian Kos <dkos@cadence.com>,
Alicja Jurasik-Urbaniak <alicja@cadence.com>,
"Cyprian Wronka" <cwronka@cadence.com>,
Suresh Punnoose <sureshp@cadence.com>,
"Rafal Ciepiela" <rafalc@cadence.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Nishanth Menon <nm@ti.com>, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
"Kumar Gala" <galak@codeaurora.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Linus Walleij <linus.walleij@linaro.org>,
Xiang Lin <Xiang.Lin@synaptics.com>, <linux-gpio@vger.kernel.org>,
Sekhar Nori <nsekhar@ti.com>, Przemyslaw Gaj <pgaj@cadence.com>,
Peter Rosin <peda@axentia.se>,
Mike Shettel <mshettel@codeaurora.org>,
Stephen Boyd <swboyd@chromium.org>,
Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v10 0/9] Add the I3C subsystem
Date: Mon, 19 Nov 2018 13:43:51 +0100 [thread overview]
Message-ID: <20181119134351.7f2edcc8@bbrezillon> (raw)
In-Reply-To: <ffcc3c3d-0bfd-23e2-5fbb-00cfbcd6b7af@synopsys.com>
On Mon, 19 Nov 2018 12:35:42 +0000
vitor <vitor.soares@synopsys.com> wrote:
> Hi Boris,
>
> On 16/11/18 13:16, Boris Brezillon wrote:
> > On Fri, 16 Nov 2018 12:31:42 +0000
> > vitor <vitor.soares@synopsys.com> wrote:
> >
> >> Hi Boris,
> >>
> >>
> >> On 15/11/18 19:00, Boris Brezillon wrote:
> >>> On Thu, 15 Nov 2018 18:03:47 +0000
> >>> vitor <vitor.soares@synopsys.com> wrote:
> >>>
> >>>> Hi Boris,
> >>>>
> >>>>
> >>>> On 15/11/18 15:28, Boris Brezillon wrote:
> >>>>> On Thu, 15 Nov 2018 16:01:37 +0100
> >>>>> Wolfram Sang <wsa@the-dreams.de> wrote:
> >>>>>
> >>>>>> Hi Boris,
> >>>>>>
> >>>>>>> What we could do though, is expose I3C devices that do not have a
> >>>>>>> driver in kernel space, like spidev does.
> >>>>>> ...
> >>>>>>
> >>>>>>> Mark, Wolfram, Arnd, Greg, any opinion?
> >>>>>> Is there a benefit for having drivers in userspace? My gut feeling is to
> >>>>>> encourage people to write kernel drivers. If this is, for some reason,
> >>>>>> not possible for some driver, then we have a use case at hand to test
> >>>>>> the then-to-be-developed userspace interface against. Until then, I
> >>>>>> personally wouldn't waste effort on designing it without a user in
> >>>>>> sight.
> >>>>> I kind of agree with that. Vitor, do you have a use case in mind for
> >>>>> such userspace drivers? I don't think it's worth designing an API for
> >>>>> something we don't need (yet).
> >>>> My use case is a tool for tests, lets say like the i2c tools.
> >>> What would you like to test exactly?
> >>>
> >>>> There is
> >>>> other subsystems, some of them mentioned on this thread, that have and
> >>>> ioctl system call or other method to change parameters or send data.
> >>> I don't think they added the /dev interface before having a real use
> >>> case for it.
> >>>
> >>>> I rise this topic because I really think it worth to define now how this
> >>>> should be design (and for me how to do the things right) to avoid future
> >>>> issues.
> >>> Actually it should be done the other way around: you should have a real
> >>> need and the /dev interface should be designed to fulfill this need.
> >>> Based on this real use case we can discuss other potential usage that
> >>> might appear in the future and try to design something more
> >>> future-proof, but clearly, this userspace interface should be driven by
> >>> a real/well-defined use case.
> >>>
> >>> Also, exposing things to userspace is way more risky than adding a new
> >>> in-kernel subsystem/framework, because it then becomes part of the
> >>> stable ABI.
> >>>
> >>> To make things clearer, I'm not against the idea of exposing I3C
> >>> devices (or I3C buses) to userspace, but I'd like to understand what you
> >>> plan to do with that. If this is about testing, what kind of tests
> >>> you'd like to run. If this is about developing drivers in userspace,
> >>> why can't these be done in kernel space (license issues?), and what
> >>> would those drivers be allowed to do?
> >>
> >> Basically I need a tool that help me during the development and to avoid
> >> me to write a dummy driver for each device that I test.
> > But we want I3C device drivers to be upstreamed, so why not developing a
> > real driver everytime you test a new device and submitting it upstream?
>
>
> Usually the devices that I test aren't the final product so it isn't
> easy to do the upstream.
>
> But when possible I plan to do that.
>
>
> >
> >> For instances do some read/write,
> > Doing SDR/DDR transfers is probably acceptable, but I still think we
> > should push hard to have kernel drivers when that's possible.
> >
> >> get/set ccc commands,
> > Exposing CCC commands is definitely not a good idea, since they're not
> > even exposed to kernel drivers.
> >
> >> if something
> >> goes wrong during the bus initialization have a to debug etc...
> > Can't we add such a debug infrastructure in the kernel. Maybe we can
> > expose debugfs files too if that helps, though if those debugfs files
> > are actually used by userspace libs/tools, it's not any better than
> > ioctls or sysfs files, since they will anyway become a stable ABI.
> >
> >>
> >> For me this is a valid use case and I imagine when people start to
> >> develop in i3c this interface will help everyone.
> > How about you propose an i3cdev driver that allow users to do SDR
> > transfers throuh an ioctl?
>
> I think that was for v6 I started to something to expose the bus like in
> i2c-dev, but I liked the idea of expose only the device doesn't have a
> driver. Do you know if there is already something in the kernel doing
> the same?
I know [1], but there might be other subsystems doing the same thing.
[1]https://elixir.bootlin.com/linux/v4.20-rc3/source/drivers/spi/spidev.c
next prev parent reply other threads:[~2018-11-19 12:43 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-26 14:43 [PATCH v10 0/9] Add the I3C subsystem Boris Brezillon
2018-10-26 14:43 ` [PATCH v10 1/9] i3c: Add core I3C infrastructure Boris Brezillon
2018-10-26 14:43 ` [PATCH v10 2/9] docs: driver-api: Add I3C documentation Boris Brezillon
2018-10-26 14:43 ` [PATCH v10 3/9] i3c: Add sysfs ABI spec Boris Brezillon
2018-10-26 14:43 ` [PATCH v10 4/9] dt-bindings: i3c: Document core bindings Boris Brezillon
2018-10-26 14:43 ` [PATCH v10 5/9] MAINTAINERS: Add myself as the I3C subsystem maintainer Boris Brezillon
2018-10-26 14:43 ` [PATCH v10 6/9] i3c: master: Add driver for Cadence IP Boris Brezillon
2018-10-26 14:43 ` [PATCH v10 7/9] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
2018-10-26 14:43 ` [PATCH v10 8/9] gpio: Add a driver for Cadence I3C GPIO expander Boris Brezillon
2018-10-26 14:43 ` [PATCH v10 9/9] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander Boris Brezillon
2018-10-26 15:22 ` [PATCH v10 0/9] Add the I3C subsystem vitor
2018-10-26 16:15 ` Boris Brezillon
2018-10-26 16:20 ` vitor
2018-10-26 16:30 ` Boris Brezillon
2018-10-26 16:18 ` Boris Brezillon
2018-11-11 17:39 ` Greg Kroah-Hartman
2018-11-11 18:10 ` Boris Brezillon
2018-11-11 19:10 ` Greg Kroah-Hartman
2018-11-11 20:08 ` Boris Brezillon
2018-11-11 20:57 ` Greg Kroah-Hartman
2018-11-11 20:59 ` Greg Kroah-Hartman
2018-11-15 12:14 ` vitor
2018-11-15 12:57 ` Boris Brezillon
2018-11-15 14:25 ` Arnd Bergmann
2018-11-15 15:25 ` vitor
2018-11-15 19:07 ` Boris Brezillon
2018-11-15 15:01 ` Wolfram Sang
2018-11-15 15:11 ` Arnd Bergmann
2018-11-15 15:28 ` Boris Brezillon
2018-11-15 18:03 ` vitor
2018-11-15 19:00 ` Boris Brezillon
2018-11-16 12:31 ` vitor
2018-11-16 12:50 ` Przemyslaw Gaj
2018-11-16 13:16 ` Boris Brezillon
2018-11-19 12:35 ` vitor
2018-11-19 12:43 ` Boris Brezillon [this message]
2018-11-19 12:46 ` vitor
2018-11-15 15:18 ` vitor
2018-11-15 19:08 ` Mark Brown
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=20181119134351.7f2edcc8@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=Xiang.Lin@synaptics.com \
--cc=adouglas@cadence.com \
--cc=agolec@cadence.com \
--cc=alicja@cadence.com \
--cc=arnd@arndb.de \
--cc=bfolta@cadence.com \
--cc=broonie@kernel.org \
--cc=corbet@lwn.net \
--cc=cwronka@cadence.com \
--cc=devicetree@vger.kernel.org \
--cc=dkos@cadence.com \
--cc=galak@codeaurora.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linus.walleij@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mshettel@codeaurora.org \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=pawel.moll@arm.com \
--cc=peda@axentia.se \
--cc=pgaj@cadence.com \
--cc=psroka@cadence.com \
--cc=rafalc@cadence.com \
--cc=robh+dt@kernel.org \
--cc=sureshp@cadence.com \
--cc=swboyd@chromium.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=vitor.soares@synopsys.com \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).