From: balbi@ti•com (Felipe Balbi)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v9 0/8] Generic PHY Framework
Date: Thu, 4 Jul 2013 13:12:16 +0300 [thread overview]
Message-ID: <20130704101216.GD4830@arwen.pp.htv.fi> (raw)
In-Reply-To: <51D54694.20203@ti.com>
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: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130704/5ba55a88/attachment-0001.sig>
next prev parent reply other threads:[~2013-07-04 10:12 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-26 11:47 [PATCH v9 0/8] Generic PHY Framework Kishon Vijay Abraham I
2013-06-26 11:47 ` [PATCH v9 1/8] drivers: phy: add generic PHY framework Kishon Vijay Abraham I
2013-06-26 12:10 ` Felipe Balbi
2013-07-17 6:29 ` Greg KH
2013-07-17 9:32 ` Kishon Vijay Abraham I
2013-07-17 17:25 ` Greg KH
2013-07-18 6:03 ` Kishon Vijay Abraham I
2013-07-18 6:24 ` Greg KH
2013-07-18 6:27 ` Kishon Vijay Abraham I
2013-06-26 11:47 ` [PATCH v9 2/8] usb: phy: omap-usb2: use the new " Kishon Vijay Abraham I
2013-06-26 11:47 ` [PATCH v9 3/8] usb: phy: twl4030: " Kishon Vijay Abraham I
2013-06-26 11:47 ` [PATCH v9 4/8] ARM: OMAP: USB: Add phy binding information Kishon Vijay Abraham I
2013-06-26 11:47 ` [PATCH v9 5/8] ARM: dts: omap: update usb_otg_hs data Kishon Vijay Abraham I
2013-06-26 11:47 ` [PATCH v9 6/8] usb: musb: omap2430: use the new generic PHY framework Kishon Vijay Abraham I
2013-06-26 11:47 ` [PATCH v9 7/8] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2 Kishon Vijay Abraham I
2013-06-26 11:47 ` [PATCH v9 8/8] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops Kishon Vijay Abraham I
2013-07-03 9:32 ` [PATCH v9 0/8] Generic PHY Framework Patel, Satish
2013-07-03 10:05 ` Kishon Vijay Abraham I
2013-07-03 13:20 ` Felipe Balbi
2013-07-04 5:17 ` Kishon Vijay Abraham I
2013-07-04 9:21 ` Patel, Satish
2013-07-04 9:55 ` Kishon Vijay Abraham I
2013-07-04 9:58 ` Patel, Satish
2013-07-04 10:12 ` Felipe Balbi [this message]
2013-07-04 10:45 ` Patel, Satish
2013-07-08 11:24 ` Patel, Satish
2013-07-08 12:17 ` Kishon Vijay Abraham I
2013-07-09 2:23 ` Patel, Satish
2013-07-09 11:44 ` Felipe Balbi
2013-07-09 12:33 ` Patel, Satish
2013-07-09 17:34 ` Felipe Balbi
2013-07-30 6:25 ` Rahul Sharma
2013-07-08 13:26 ` Felipe Balbi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130704101216.GD4830@arwen.pp.htv.fi \
--to=balbi@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox