-----Original Message-----
From: Balbi, Felipe
Sent: Wednesday, July 03, 2013 6:51 PM
To: ABRAHAM, KISHON VIJAY
Cc: Patel, Satish; grant.lik...@linaro.org; t...@atomide.com; Balbi,
Felipe; a...@arndb.de; swar...@nvidia.com;
sylvester.nawro...@gmail.com; linux-ker...@vger.kernel.org; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
u...@vger.kernel.org; gre...@linuxfoundation.org; akpm@linux-
foundation.org; rob.herr...@calxeda.com; r...@landley.net;
li...@arm.linux.org.uk; benoit.cous...@linaro.org; mche...@redhat.com;
ces...@cesarb.net; da...@davemloft.net; Nayak, Rajendra;
shawn....@linaro.org; Shilimkar, Santosh; devicetree-
disc...@lists.ozlabs.org; linux-...@vger.kernel.org; Nori, Sekhar;
Krishnamoorthy, Balaji T; Cherian, George
Subject: Re: [PATCH v9 0/8] Generic PHY Framework
Hi,
On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I
wrote:
On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote:
Hi Kishon,
-----Original Message-----
From: ABRAHAM, KISHON VIJAY
Sent: Wednesday, June 26, 2013 5:17 PM
To: grant.lik...@linaro.org; t...@atomide.com; Balbi, Felipe;
ABRAHAM,
KISHON VIJAY; a...@arndb.de; swar...@nvidia.com;
sylvester.nawro...@gmail.com; linux-ker...@vger.kernel.org; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
u...@vger.kernel.org; gre...@linuxfoundation.org; akpm@linux-
foundation.org
Cc: rob.herr...@calxeda.com; r...@landley.net;
li...@arm.linux.org.uk;
benoit.cous...@linaro.org; mche...@redhat.com; ces...@cesarb.net;
da...@davemloft.net; Nayak, Rajendra; shawn....@linaro.org;
Shilimkar,
Santosh; devicetree-discuss@lists.ozlabs.org; linux-
d...@vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T;
Cherian,
George
Subject: [PATCH v9 0/8] Generic PHY Framework
Added a generic PHY framework that provides a set of APIs for the
PHY
drivers
to create/destroy a PHY and APIs for the PHY users to obtain a
reference to
the PHY with or without using phandle.
This framework will be of use only to devices that uses external
PHY
(PHY
functionality is not embedded within the controller).
The intention of creating this framework is to bring the phy
drivers
spread
all over the Linux kernel to drivers/phy to increase code re-use
and
to
increase code maintainability.
I would like to use this framework for a smart-card controller
connected to a
smart-card phy. I have some questions and would like to get
feedback on the same.
glad to know that :-)
I am using “TDA8026" Smartcard PHY from NXP. Here is the link for
datasheet
and app note for the same. The smart card controller is inside the
TI SoC
I am working with.
Datasheet :
www.nxp.com/documents/data_sheet/TDA8026.pdf?
Appnote :
http://www.nxp.com/documents/application_note/AN10724.pdf
The TI SoC details are not public (yet). I can provide details to
you offline.
Brief about operation:
- The controller can work with and without a PHY
- When not using PHY, it is limited to talking to a single
smart card. There is also a need to put external de-activation
logic
on card removal for this case.
- With a PHY you can use more than one smart card.
- Phy has 5 slots : 1 for smart card (credit/debit/other card
with chip)
and others for SAM – SIM like modules
- Once the PHY is initialized, there are some operations that the
controller
can request of the PHY like:
- Card configurations - set voltage
- Activation of card
- ATR – Answer to reset
- Warm reset
- ADPU exchange
- Deactivation ( Normal/Emergency)
hmm.. We should think about extending the phy_ops to include these
operations (something like phy_smart_card_ops so that other
smart_card PHYs will also be able to use it).
let's try to avoid use-case specific additions. set_voltage sounds
like
a regulator thing, but the regulator is controlled through the PHY. I
guess it makes sense to have a generic phy_set_voltage() call since
even
USB can make use of that.
For card activation, it sounds like phy_init()/phy_shutdown() would
cover it.
For warm reset perhaps a phy_reset() callback ? Although that could,
easily, get abused.
For deactivation, that's phy_shutdown().
ATR and ADPU needs more thought, I guess.
- In the mode when smartcard controller talks directly to the
card without the need
for a PHY, all the above operations will be carried out by the
controller itself
My current thought process is to make the controller driver provide
the user interface
and talk to the PHY using the generic PHY framework you proposed.
In the case where there
is no PHY, my idea is to create a "dummy" PHY which uses the
controller functionality itself.
right. And in the case where you actually have a PHY, create a PHY
driver and implement the phy_smart_card_ops and register with the
PHY
framework.
I would try to avoid that. Otherwise we will have phy_usb_ops,
phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would
easily
blow up.
