[PATCH v9 0/8] Generic PHY Framework

[Kishon Vijay Abraham I]

Hi,

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).
> - 	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.
>
> What I seem to be missing from the PHY framework is support for event detection and generic
> read/write API which will enable the controller to talk to the PHY for the operations listed
> above and also react to events from the PHY.

IMO the event detection should be handled in the PHY driver. And I dint 
feel the need for a read/write API as phy_xxxx_ops should be doing that 
precisely.

Thanks
Kishon