linux-kernel - Smartcard/SIM card subsystem, LDO regulator and signal modelling

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-next>] [day] [month] [year] [list]

Message-ID: <BANLkTikAzjmVoNK20RHRkhHkn3YgSra6dA@mail.gmail.com>
Date:	Wed, 18 May 2011 12:36:17 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	linux-kernel@...r.kernel.org
Cc:	Bibek BASU <bibek.basu@...ricsson.com>,
	Sascha Hauer <kernel@...gutronix.de>,
	Catalin Marinas <catalin.marinas@....com>,
	Juergen Beisert <jbe@...gutronix.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Smartcard/SIM card subsystem, LDO regulator and signal modelling

Hi folks,

I have this special regulator in the AB5500 which we will attempt to
submit for mainline inclusion soon:

It's basically an LDO for powering a SIM card (which in turn is basically
a smartcard), but apart from plain regulation also expose some other
electrical properties of the interface to software:

- Select pull-up resistance on some I/O lines
- Select weak pull-down on some data lines
- Select load capacitance limits on the data lines
- Select whether to run in low impedance or transmission gate mode

I think these will be mostly similar so what other SIM card controllers
will need to have. All the stuff needs to have userspace interfaces
since the stuff is usually controlled on behalf of another CPU
running the modem (and also performing the actual traffic on
the SIM data lines).

My first naïve idea was that this could be some plain regulator,
then add a few sysfs files for the custom stuff and have these
in the regulator driver.

However now I think we might even need to create a misc device
or a new drivers/smartcard/* subsystem, just that it will include
spawning a regulator for the LDO part. If drivers/smartcard/*
was created we'd easily fold into that, but since we're not
needing the generics of actually talking to the card we end
up in a strange place where we'd go implementing a
framework that we don't use and cannot test :-/

Maybe we should indeed create drivers/smartcard/*
and only add a tentative API for power & regulator
such as <linux/smartcard/power.h> or so?

Any thoughts on this, have you seen this before etc?

Also CC:ing some people with SoC systems that include a
SIM/smartcard reader ... RealView and Freescale comes to
mind.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/