From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Balbi Subject: Re: [PATCH v9 0/8] Generic PHY Framework Date: Thu, 4 Jul 2013 13:12:16 +0300 Message-ID: <20130704101216.GD4830@arwen.pp.htv.fi> References: <1372247257-30186-1-git-send-email-kishon@ti.com> <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com> <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi> <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com> <51D54694.20203@ti.com> Reply-To: balbi-l0cyMroinI0@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0033406102592651998==" Return-path: In-Reply-To: <51D54694.20203-l0cyMroinI0@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Kishon Vijay Abraham I Cc: "mchehab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "Patel, Satish" , "Nori, Sekhar" , "Mankad, Maulik Ojas" , "swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org" , "grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , "cesarb-PWySMVKUnqmsTnJN9+BGXg@public.gmane.org" , "Cherian, George" , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" , "rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org" , "linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org" , "sylvester.nawrocki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" , "linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "Krishnamoorthy, Balaji T" , "gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org" li List-Id: linux-omap@vger.kernel.org --===============0033406102592651998== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DrWhICOqskFTAXiy" Content-Disposition: inline --DrWhICOqskFTAXiy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 04, 2013 at 03:25:32PM +0530, Kishon Vijay Abraham I wrote: > 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org; Balbi, > >>Felipe; arnd-r2nGTMty4D4@public.gmane.org; swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org; > >>sylvester.nawrocki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux- > >>omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux- > >>usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org; akpm@linux- > >>foundation.org; rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org; rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org; > >>linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org; benoit.cousson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; mchehab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; > >>cesarb-PWySMVKUnqmsTnJN9+BGXg@public.gmane.org; davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org; Nayak, Rajendra; > >>shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Shilimkar, Santosh; devicetree- > >>discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org; Balbi, Felipe; > >>ABRAHAM, > >>>>>KISHON VIJAY; arnd-r2nGTMty4D4@public.gmane.org; swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org; > >>>>>sylvester.nawrocki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux- > >>>>>omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux- > >>>>>usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org; akpm@linux- > >>>>>foundation.org > >>>>>Cc: rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org; rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org; > >>linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org; > >>>>>benoit.cousson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; mchehab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; cesarb-PWySMVKUnqmsTnJN9+BGXg@public.gmane.org; > >>>>>davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org; Nayak, Rajendra; shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; > >>Shilimkar, > >>>>>Santosh; devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; linux- > >>>>>doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 =E2=80=9CTDA8026" 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 =E2=80=93 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 =E2=80=93 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. > >=09 > >e.x in case of smartcard > > enum set_config { > > SET_VOLATAGE, > > SET_ACTIVATE, > > SET_WARMRESET, > > SET_ATR, > > SET_DEACTIVE, > > .... > > }; >=20 > hmm.. this looks similar to ioctl and can be abused easily IMO :s +1 What we need is to come up with generic ways to model those, if we need set voltage, then add a phy_set_voltage() kinda thing, perhaps add capability flags to enable/disable support fort those (just like mmc does). But adding something which can handle "anything" like phy_set_config(), it's the same as adding use-case specific ops. --=20 balbi --DrWhICOqskFTAXiy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJR1UqAAAoJEIaOsuA1yqREhAkP/Rd4xec0TWkbSZsV6qhxZAaZ Y6oPI+mTdrCUPYWM6itlSpFV/FndNy0KM+lEQyPCDEdgRObar5NYBJ2moKKtzyEB LwzdyYTYK2hZXZyQ2s2YLFKA19hjs7biABzAW2Xd/rEhn0+x+fhJQvuoGCGFLRQn vKPZlNsaBR+zAzzZKAVqntvmFxcIPLkgfRpSNYHNoAITRO40wUVeIf+8wfqXQG5q 4d0Ft7L1FBWRJjXdfyaJrvlhym2uu+fmspnpWPdFITfJ2AYxP5yac/pZe+RWSlg+ SLReGDPi6pXxDg1kGNBW4B/37yIUmUOjp43VysX5onl9t8GthgjsGWxOLiJDswwh L6KnknTd4Lb8bBFMeTlO56R7xTIrqys9sk6WsfGGxtIVklCqG2UOLHx8NdA4CvUK eXUoSq8IDG8l5ycG54Y07TKvL4xH9WmGKMtVRiNMzKpPF0ayfmk0uGYTruTwHzYa pvQu6taDM+j784Odr7lX24vVrWcOL9shmU09MHYfpeL4bVCFm4uM70TydGnb4DRS mUFt6A3JFNF09S5Rv8ROjkXOqgJ0knplWuGDyQSHman2EXwzgvXxaut88vd3Htnm +hK2k9Mh9OOGAJhE7v0gdxvZ31tL4QdqPvv2/9zMxtuPysqDCUsPMf3hQPcHqUyG 1Wxtl9E13UejWAjs5Ax5 =QJRa -----END PGP SIGNATURE----- --DrWhICOqskFTAXiy-- --===============0033406102592651998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org https://lists.ozlabs.org/listinfo/devicetree-discuss --===============0033406102592651998==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@ti.com (Felipe Balbi) Date: Thu, 4 Jul 2013 13:12:16 +0300 Subject: [PATCH v9 0/8] Generic PHY Framework In-Reply-To: <51D54694.20203@ti.com> References: <1372247257-30186-1-git-send-email-kishon@ti.com> <780E789C2E067A4BB8F69D0BB9EC4F253E975B5E@DBDE04.ent.ti.com> <51D3F773.9000209@ti.com> <20130703132038.GI15056@arwen.pp.htv.fi> <780E789C2E067A4BB8F69D0BB9EC4F253E975D6E@DBDE04.ent.ti.com> <51D54694.20203@ti.com> Message-ID: <20130704101216.GD4830@arwen.pp.htv.fi> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Jul 04, 2013 at 03:25:32PM +0530, Kishon Vijay Abraham I wrote: > 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 at linaro.org; tony at atomide.com; Balbi, > >>Felipe; 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; 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: 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 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. > >> > > > >- 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 +1 What we need is to come up with generic ways to model those, if we need set voltage, then add a phy_set_voltage() kinda thing, perhaps add capability flags to enable/disable support fort those (just like mmc does). But adding something which can handle "anything" like phy_set_config(), it's the same as adding use-case specific ops. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: