Re: [PATCH v9 0/8] Generic PHY Framework

[Kishon Vijay Abraham I <kishon@ti.com>]

On Thursday 04 July 2013 02:51 PM, Patel, Satish wrote:
> Hi,
>
>> -----Original Message-----
>> From: Balbi, Felipe
>> Sent: Wednesday, July 03, 2013 6:51 PM
>> To: ABRAHAM, KISHON VIJAY
>> Cc: Patel, Satish; grant.likely@linaro.org; tony@atomide.com; Balbi,
>> Felipe; arnd@arndb.de; swarren@nvidia.com;
>> sylvester.nawrocki@gmail.com; linux-kernel@vger.kernel.org; linux-
>> omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> usb@vger.kernel.org; gregkh@linuxfoundation.org; akpm@linux-
>> foundation.org; rob.herring@calxeda.com; rob@landley.net;
>> linux@arm.linux.org.uk; benoit.cousson@linaro.org; mchehab@redhat.com;
>> cesarb@cesarb.net; davem@davemloft.net; Nayak, Rajendra;
>> shawn.guo@linaro.org; Shilimkar, Santosh; devicetree-
>> discuss@lists.ozlabs.org; linux-doc@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.likely@linaro.org; tony@atomide.com; Balbi, Felipe;
>> ABRAHAM,
>>>>> KISHON VIJAY; arnd@arndb.de; swarren@nvidia.com;
>>>>> sylvester.nawrocki@gmail.com; linux-kernel@vger.kernel.org; linux-
>>>>> omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>>>>> usb@vger.kernel.org; gregkh@linuxfoundation.org; akpm@linux-
>>>>> foundation.org
>>>>> Cc: rob.herring@calxeda.com; rob@landley.net;
>> linux@arm.linux.org.uk;
>>>>> benoit.cousson@linaro.org; mchehab@redhat.com; cesarb@cesarb.net;
>>>>> davem@davemloft.net; Nayak, Rajendra; shawn.guo@linaro.org;
>> Shilimkar,
>>>>> Santosh; devicetree-discuss@lists.ozlabs.org; linux-
>>>>> doc@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.
>>
>
> - I do agree with you. Creating Phy specific ops will blow up whole
>    concept of generic phy f/w.
> - Can we have interface like phy_setconfig - with parameter like
>    phy_setconfig(int param, void *value)
> 	- Here param can be enum of available config parameters for
> 	  specific phy.
> Phy can perform different operation/set internal state based on
> param selection and value passed by.
> 	
> e.x in case of smartcard
> 	enum set_config {
> 		SET_VOLATAGE,
> 		SET_ACTIVATE,
> 		SET_WARMRESET,
> 		SET_ATR,
> 		SET_DEACTIVE,
> 		....
> 	};

hmm.. this looks similar to ioctl and can be abused easily IMO :s

-Kishon

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel