Hi,

On Fri, Jan 20, 2017 at 02:36:12AM +0100, msuchanek wrote:
> On 2017-01-16 23:54, Rob Herring wrote:
> > Here's a new version of the serdev bus support with all the review
> > feedback so far incorporated. I've left it named serdev for now pending
> > any further votes one way or the other, but I did rename the sysfs
> > visible
> > portions to "serial".
> > 
> > There's still some discussion about what to do with devices that pass
> > thru
> > data to userspace unmodified like GPS and could still use tty device for
> > the data path. IMO, we should treat this as a separate problem following
> > this series. Drivers we want to convert to serdev and already in the
> > kernel don't need this functionality.
> 
> The whole point of the serial bus is to simplify and clean up support for
> serial devices.
> If tty users cannot use the kernel support for automagic kill
> switches/resets/whatever with kernel GPIO or whatever framework and must
> continue supporting userspace GPIO and hacks for writing IO space from
> userland for their devices there is just no point.

> I mean it's fine to add support for your single pet device but if you are
> to support non-trivial number of devices they don't get all perfect kernel
> driver overnight. And if you need userspace GPIO for half of your devices
> you can just continue using it for all to *simplify* your userspace code.

This is definitely not about a single pet device. It helps for most
of the serial attached bluetooth chips. For example my work on the
Nokia N-series bluetooth driver is waiting for this series and
supporting the nokia bluetooth chips with userspace GPIOs is more
or less impossible with the data being handled in the kernel, since
GPIOs have to be toggled based on that data.

Also there is the kurobox, which uses a serial attached board reset
controller. It may not need extra GPIOs/regulators/whatever, but it
must have a full-in-kernel driver, so that 'reboot' works as expected ;)

> It has already happened for SPI devices and the implementation of the
> userspace access to SPI is dragging for years.

Talking about dragging for years: This series has been initially
discussed in 2014. Implementing this step-by-step looks sensible
to me.

-- Sebastian