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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7482716.OJg3IkqZRp@wuerfel>
Date:   Mon, 17 Oct 2016 13:34:54 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Lubomir Rintel <lkundrak@...sk>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        Dominik Brodowski <linux@...inikbrodowski.net>
Subject: Re: [PATCH] char/pcmcia: add scr24x_cs chip card interface driver

On Monday, October 17, 2016 1:22:01 PM CEST Lubomir Rintel wrote:
> > > > And why do you need a char device for this type of
> > > > hardware?  Isn't there already an existing interface for this device
> > > > class?
> > > 
> > > (Arnd answered this better than I would do in his response to this
> > > message).
> > 
> > Yeah, that makes sense.  A bit messy though.
> 
> I guess that makes sense; the chip card readers tend to be rather
> complex and the API (IFD Handler API) user space typically uses is
> rather generic -- it would require quite some logic to interface with a
> particular hardware.
> 
> Moreover, most of the present-day smart card readers are standard CCID
> class USB devices, with the CCID to IFD done in userspace. There's some
> serial readers too, attached via UARTs too that use the tty ioctls to
> detect the card presence and set the baud rate, etc.
> 
> The rest (PCMCIA) seem to emulate either of the two. It still makes
> sense to implement the IFD in userspace and I guess there's not too
> much common ground for a device class here.

Well, you could in theory implement this as a tty driver
and be compatible with the serial port devices, see
drivers/tty/goldfish.c for an example driver.

Not sure if that actually improves things for you or not,
but the advantage is that there is an existing kernel
subsystem for it.

	Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ