[PATCH v9 0/8] Generic PHY Framework

[Felipe Balbi]

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.likely at linaro.org; tony at atomide.com; Balbi, Felipe; ABRAHAM,
> >>KISHON VIJAY; arnd at arndb.de; swarren at nvidia.com;
> >>sylvester.nawrocki at gmail.com; linux-kernel at vger.kernel.org; linux-
> >>omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> >>usb at vger.kernel.org; gregkh at linuxfoundation.org; akpm at linux-
> >>foundation.org
> >>Cc: rob.herring at calxeda.com; rob at landley.net; linux at arm.linux.org.uk;
> >>benoit.cousson at linaro.org; mchehab at redhat.com; cesarb at cesarb.net;
> >>davem at davemloft.net; Nayak, Rajendra; shawn.guo at linaro.org; Shilimkar,
> >>Santosh; devicetree-discuss at lists.ozlabs.org; linux-
> >>doc at 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.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130703/9388d732/attachment.sig>