lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 20 Jan 2017 02:36:12 +0100 From: msuchanek <msuchanek@...e.de> To: Rob Herring <robh@...nel.org> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Marcel Holtmann <marcel@...tmann.org>, Jiri Slaby <jslaby@...e.com>, Sebastian Reichel <sre@...nel.org>, Arnd Bergmann <arnd@...db.de>, "Dr . H . Nikolaus Schaller" <hns@...delico.com>, Peter Hurley <peter@...leysoftware.com>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Alan Cox <gnomes@...rguk.ukuu.org.uk>, Loic Poulain <loic.poulain@...el.com>, Pavel Machek <pavel@....cz>, NeilBrown <neil@...wn.name>, Linus Walleij <linus.walleij@...aro.org>, linux-bluetooth@...r.kernel.org, linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org, linux-serial-owner@...r.kernel.org Subject: Re: [PATCH v2 0/9] Serial slave device bus 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. It has already happened for SPI devices and the implementation of the userspace access to SPI is dragging for years. Thanks Michal
Powered by blists - more mailing lists