linux-kernel - Re: [PATCH] char/pcmcia: add scr24x

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Oct 2016 21:24:10 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Lubomir Rintel <lkundrak@...sk>, 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 10, 2016 7:33:45 PM CEST Greg Kroah-Hartman wrote:
> > +
> > +#define SCR24X_DEVS 8
> > +static DECLARE_BITMAP(scr24x_minors, SCR24X_DEVS);
> > +
> > +static struct class *scr24x_class;
> > +dev_t scr24x_devt;
> 
> global variable?  And why do you need a char device for this type of
> hardware?  Isn't there already an existing interface for this device
> class?

It looks like this is modeled after the other two chip card drivers
in drivers/char/pcmcia/, which are also char devices. Looking at
https://pcsclite.alioth.debian.org/ccid.html, it seems that other
drivers for this protocol are typically in user space when they are
for USB devices, so apparently no existing subsystem abstraction
in the kernel.

This reminds me that there is just one other driver in drivers/char/pcmcia
(synclink_cs), and that should be moved to drivers/tty/ with the other
synclink variants. If we do this, we could rename drivers/char/pcmcia
to something that implies "smartcard".

	Arnd