Hi Kishon, > -----Original Message----- > From: ABRAHAM, KISHON VIJAY > Sent: Wednesday, June 26, 2013 5:17 PM > To: grant.likely@xxxxxxxxxx; tony@xxxxxxxxxxx; Balbi, Felipe; ABRAHAM, > KISHON VIJAY; arnd@xxxxxxxx; swarren@xxxxxxxxxx; > sylvester.nawrocki@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux- > omap@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux- > usb@xxxxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; akpm@linux- > foundation.org > Cc: rob.herring@xxxxxxxxxxx; rob@xxxxxxxxxxx; linux@xxxxxxxxxxxxxxxx; > benoit.cousson@xxxxxxxxxx; mchehab@xxxxxxxxxx; cesarb@xxxxxxxxxx; > davem@xxxxxxxxxxxxx; Nayak, Rajendra; shawn.guo@xxxxxxxxxx; Shilimkar, > Santosh; devicetree-discuss@xxxxxxxxxxxxxxxx; linux- > doc@xxxxxxxxxxxxxxx; 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. 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) - 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. 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. Is there a reason why such functionality has not been included. If it was only a case of lack of use case, then do you think it will be useful to extend the framework to add such functionality? I can help with the development. Thanks, Satish -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
