[PATCH v9 0/8] Generic PHY Framework

[PATCH v9 0/8] Generic PHY Framework

[Kishon Vijay Abraham I]

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.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

If the PHY driver has to send notification on connect/disconnect, the PHY
driver should make use of the extcon framework. Using this susbsystem 
to use extcon framwork will have to be analysed.

Making omap-usb2 and twl4030 to use this framework is provided as a sample.

This patch series is developed on linux mainline tree.

This framework is already being used by display PHYs
http://www.spinics.net/lists/arm-kernel/msg251666.html

These patches are hosted in git://gitorious.org/linuxphy/linuxphy.git testing

Changes from v8:
* Added phy_set_drvdata and phy_get_drvdata in phy.h.
* Changed phy_create API not to take void *priv. private data should now be set
using phy_set_drvdata now.

Changes from v7:
* Fixed Documentation
* Added to_phy, of_phy_provider_register and devm_of_phy_provider_register
* modified runtime_pm usage in phy_init, phy_exit, phy_power_on and
phy_power_off. Now phy_power_on will enable the clocks and phy_power_off will
disable the clocks.
* pm_runtime_no_callbacks() is added so that pm_runtime_get_sync doesn't fail
* modified other patches to adhere to the changes in the PHY framework
* removed usb: phy: twl4030: twl4030 shouldn't be subsys_initcall as it will
be merged separately.
* reference counting has been added to protect phy ops when the PHY is shared
by multiple consumers.

Changes from v6
* corrected few typos in Documentation
* Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when
  PHY Subsystem is kept as module and the dependent modules are built-in)
* Added if pm_runtime_enabled check before runtime pm calls.

Changes from v5:
* removed the new sysfs entries as it dint have any new information other than
  what is already there in /sys/devices/...
* removed a bunch of APIs added to get the PHY and now only phy_get and
  devm_phy_get are used.
* Added new APIs to register/unregister the PHY provider. This is needed for
  dt boot case.
* Enabled pm runtime and incorporated the comments given by Alan Stern in a
  different patch series by Gautam.
* Removed the *phy_bind* API. Now the phy binding information should be passed
  using the platform data to the controller devices.
* Fixed a few typos.

Changes from v4:
* removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy providers*
  should use their custom implementation of of_xlate or use of_phy_xlate to get
  *phy instance* from *phy providers*.
* Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
* changed phy_core from having subsys_initcall to module_init.
* other minor fixes.

Changes from v3:
* Changed the return value of PHY APIs to ENOSYS
* Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting
  PHYs if the same IP implements multiple PHYs.
* modified phy_bind API so that the binding information can now be _updated_.
  In effect of this removed the binding information added in board files and
  added only in usb-musb.c. If a particular board uses a different phy binding,
  it can update it in board file after usb_musb_init().
* Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding
  information.

Changes from v2:
* removed phy_descriptor structure completely so changed the APIs which were
  taking phy_descriptor as parameters
* Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used
  by PHY user drivers which has *phy* and *phy-names* binding in the dt data
* Fixed a few typos
* Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and
  class_dev_iter_exit for traversing through the phy list. (Note we still need
  phy_bind list and phy_bind_mutex).
* Changed the sysfs entry name from *bind* to *phy_bind*.

Changes from v1:
* Added Documentation for the PHY framework
* Added few more APIs mostly w.r.t devres
* Modified omap-usb2 and twl4030 to make use of the new framework

Did USB enumeration testing in panda and beagle.

Kishon Vijay Abraham I (8):
  drivers: phy: add generic PHY framework
  usb: phy: omap-usb2: use the new generic PHY framework
  usb: phy: twl4030: use the new generic PHY framework
  ARM: OMAP: USB: Add phy binding information
  ARM: dts: omap: update usb_otg_hs data
  usb: musb: omap2430: use the new generic PHY framework
  usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
  usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

 .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 +
 Documentation/phy.txt                              |  129 +++++
 MAINTAINERS                                        |    7 +
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 +
 arch/arm/boot/dts/omap3-evm.dts                    |    2 +
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 +
 arch/arm/boot/dts/omap4.dtsi                       |    3 +
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 arch/arm/mach-omap2/usb-musb.c                     |    6 +-
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   13 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  544 ++++++++++++++++++++
 drivers/usb/musb/Kconfig                           |    1 +
 drivers/usb/musb/musb_core.c                       |    1 +
 drivers/usb/musb/musb_core.h                       |    3 +
 drivers/usb/musb/omap2430.c                        |   26 +-
 drivers/usb/phy/Kconfig                            |    1 +
 drivers/usb/phy/phy-omap-usb2.c                    |   60 ++-
 drivers/usb/phy/phy-twl4030-usb.c                  |   63 ++-
 include/linux/phy/phy.h                            |  344 +++++++++++++
 include/linux/usb/musb.h                           |    3 +
 25 files changed, 1243 insertions(+), 54 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

-- 
1.7.10.4

[PATCH v9 0/8] Generic PHY Framework

[Kishon Vijay Abraham I]

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.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

If the PHY driver has to send notification on connect/disconnect, the PHY
driver should make use of the extcon framework. Using this susbsystem 
to use extcon framwork will have to be analysed.

Making omap-usb2 and twl4030 to use this framework is provided as a sample.

This patch series is developed on linux mainline tree.

This framework is already being used by display PHYs
http://www.spinics.net/lists/arm-kernel/msg251666.html

These patches are hosted in git://gitorious.org/linuxphy/linuxphy.git testing

Changes from v8:
* Added phy_set_drvdata and phy_get_drvdata in phy.h.
* Changed phy_create API not to take void *priv. private data should now be set
using phy_set_drvdata now.

Changes from v7:
* Fixed Documentation
* Added to_phy, of_phy_provider_register and devm_of_phy_provider_register
* modified runtime_pm usage in phy_init, phy_exit, phy_power_on and
phy_power_off. Now phy_power_on will enable the clocks and phy_power_off will
disable the clocks.
* pm_runtime_no_callbacks() is added so that pm_runtime_get_sync doesn't fail
* modified other patches to adhere to the changes in the PHY framework
* removed usb: phy: twl4030: twl4030 shouldn't be subsys_initcall as it will
be merged separately.
* reference counting has been added to protect phy ops when the PHY is shared
by multiple consumers.

Changes from v6
* corrected few typos in Documentation
* Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when
  PHY Subsystem is kept as module and the dependent modules are built-in)
* Added if pm_runtime_enabled check before runtime pm calls.

Changes from v5:
* removed the new sysfs entries as it dint have any new information other than
  what is already there in /sys/devices/...
* removed a bunch of APIs added to get the PHY and now only phy_get and
  devm_phy_get are used.
* Added new APIs to register/unregister the PHY provider. This is needed for
  dt boot case.
* Enabled pm runtime and incorporated the comments given by Alan Stern in a
  different patch series by Gautam.
* Removed the *phy_bind* API. Now the phy binding information should be passed
  using the platform data to the controller devices.
* Fixed a few typos.

Changes from v4:
* removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy providers*
  should use their custom implementation of of_xlate or use of_phy_xlate to get
  *phy instance* from *phy providers*.
* Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
* changed phy_core from having subsys_initcall to module_init.
* other minor fixes.

Changes from v3:
* Changed the return value of PHY APIs to ENOSYS
* Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting
  PHYs if the same IP implements multiple PHYs.
* modified phy_bind API so that the binding information can now be _updated_.
  In effect of this removed the binding information added in board files and
  added only in usb-musb.c. If a particular board uses a different phy binding,
  it can update it in board file after usb_musb_init().
* Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding
  information.

Changes from v2:
* removed phy_descriptor structure completely so changed the APIs which were
  taking phy_descriptor as parameters
* Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used
  by PHY user drivers which has *phy* and *phy-names* binding in the dt data
* Fixed a few typos
* Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and
  class_dev_iter_exit for traversing through the phy list. (Note we still need
  phy_bind list and phy_bind_mutex).
* Changed the sysfs entry name from *bind* to *phy_bind*.

Changes from v1:
* Added Documentation for the PHY framework
* Added few more APIs mostly w.r.t devres
* Modified omap-usb2 and twl4030 to make use of the new framework

Did USB enumeration testing in panda and beagle.

Kishon Vijay Abraham I (8):
  drivers: phy: add generic PHY framework
  usb: phy: omap-usb2: use the new generic PHY framework
  usb: phy: twl4030: use the new generic PHY framework
  ARM: OMAP: USB: Add phy binding information
  ARM: dts: omap: update usb_otg_hs data
  usb: musb: omap2430: use the new generic PHY framework
  usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
  usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

 .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 +
 Documentation/phy.txt                              |  129 +++++
 MAINTAINERS                                        |    7 +
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 +
 arch/arm/boot/dts/omap3-evm.dts                    |    2 +
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 +
 arch/arm/boot/dts/omap4.dtsi                       |    3 +
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 arch/arm/mach-omap2/usb-musb.c                     |    6 +-
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   13 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  544 ++++++++++++++++++++
 drivers/usb/musb/Kconfig                           |    1 +
 drivers/usb/musb/musb_core.c                       |    1 +
 drivers/usb/musb/musb_core.h                       |    3 +
 drivers/usb/musb/omap2430.c                        |   26 +-
 drivers/usb/phy/Kconfig                            |    1 +
 drivers/usb/phy/phy-omap-usb2.c                    |   60 ++-
 drivers/usb/phy/phy-twl4030-usb.c                  |   63 ++-
 include/linux/phy/phy.h                            |  344 +++++++++++++
 include/linux/usb/musb.h                           |    3 +
 25 files changed, 1243 insertions(+), 54 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

-- 
1.7.10.4

[PATCH v9 0/8] Generic PHY Framework

[Kishon Vijay Abraham I]

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.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

If the PHY driver has to send notification on connect/disconnect, the PHY
driver should make use of the extcon framework. Using this susbsystem 
to use extcon framwork will have to be analysed.

Making omap-usb2 and twl4030 to use this framework is provided as a sample.

This patch series is developed on linux mainline tree.

This framework is already being used by display PHYs
http://www.spinics.net/lists/arm-kernel/msg251666.html

These patches are hosted in git://gitorious.org/linuxphy/linuxphy.git testing

Changes from v8:
* Added phy_set_drvdata and phy_get_drvdata in phy.h.
* Changed phy_create API not to take void *priv. private data should now be set
using phy_set_drvdata now.

Changes from v7:
* Fixed Documentation
* Added to_phy, of_phy_provider_register and devm_of_phy_provider_register
* modified runtime_pm usage in phy_init, phy_exit, phy_power_on and
phy_power_off. Now phy_power_on will enable the clocks and phy_power_off will
disable the clocks.
* pm_runtime_no_callbacks() is added so that pm_runtime_get_sync doesn't fail
* modified other patches to adhere to the changes in the PHY framework
* removed usb: phy: twl4030: twl4030 shouldn't be subsys_initcall as it will
be merged separately.
* reference counting has been added to protect phy ops when the PHY is shared
by multiple consumers.

Changes from v6
* corrected few typos in Documentation
* Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when
  PHY Subsystem is kept as module and the dependent modules are built-in)
* Added if pm_runtime_enabled check before runtime pm calls.

Changes from v5:
* removed the new sysfs entries as it dint have any new information other than
  what is already there in /sys/devices/...
* removed a bunch of APIs added to get the PHY and now only phy_get and
  devm_phy_get are used.
* Added new APIs to register/unregister the PHY provider. This is needed for
  dt boot case.
* Enabled pm runtime and incorporated the comments given by Alan Stern in a
  different patch series by Gautam.
* Removed the *phy_bind* API. Now the phy binding information should be passed
  using the platform data to the controller devices.
* Fixed a few typos.

Changes from v4:
* removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy providers*
  should use their custom implementation of of_xlate or use of_phy_xlate to get
  *phy instance* from *phy providers*.
* Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
* changed phy_core from having subsys_initcall to module_init.
* other minor fixes.

Changes from v3:
* Changed the return value of PHY APIs to ENOSYS
* Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting
  PHYs if the same IP implements multiple PHYs.
* modified phy_bind API so that the binding information can now be _updated_.
  In effect of this removed the binding information added in board files and
  added only in usb-musb.c. If a particular board uses a different phy binding,
  it can update it in board file after usb_musb_init().
* Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding
  information.

Changes from v2:
* removed phy_descriptor structure completely so changed the APIs which were
  taking phy_descriptor as parameters
* Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used
  by PHY user drivers which has *phy* and *phy-names* binding in the dt data
* Fixed a few typos
* Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and
  class_dev_iter_exit for traversing through the phy list. (Note we still need
  phy_bind list and phy_bind_mutex).
* Changed the sysfs entry name from *bind* to *phy_bind*.

Changes from v1:
* Added Documentation for the PHY framework
* Added few more APIs mostly w.r.t devres
* Modified omap-usb2 and twl4030 to make use of the new framework

Did USB enumeration testing in panda and beagle.

Kishon Vijay Abraham I (8):
  drivers: phy: add generic PHY framework
  usb: phy: omap-usb2: use the new generic PHY framework
  usb: phy: twl4030: use the new generic PHY framework
  ARM: OMAP: USB: Add phy binding information
  ARM: dts: omap: update usb_otg_hs data
  usb: musb: omap2430: use the new generic PHY framework
  usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
  usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

 .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 +
 Documentation/phy.txt                              |  129 +++++
 MAINTAINERS                                        |    7 +
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 +
 arch/arm/boot/dts/omap3-evm.dts                    |    2 +
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 +
 arch/arm/boot/dts/omap4.dtsi                       |    3 +
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 arch/arm/mach-omap2/usb-musb.c                     |    6 +-
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   13 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  544 ++++++++++++++++++++
 drivers/usb/musb/Kconfig                           |    1 +
 drivers/usb/musb/musb_core.c                       |    1 +
 drivers/usb/musb/musb_core.h                       |    3 +
 drivers/usb/musb/omap2430.c                        |   26 +-
 drivers/usb/phy/Kconfig                            |    1 +
 drivers/usb/phy/phy-omap-usb2.c                    |   60 ++-
 drivers/usb/phy/phy-twl4030-usb.c                  |   63 ++-
 include/linux/phy/phy.h                            |  344 +++++++++++++
 include/linux/usb/musb.h                           |    3 +
 25 files changed, 1243 insertions(+), 54 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

-- 
1.7.10.4

[PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

The PHY framework 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. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.

PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
 Documentation/phy.txt                              |  129 +++++
 MAINTAINERS                                        |    7 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   13 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  544 ++++++++++++++++++++
 include/linux/phy/phy.h                            |  344 +++++++++++++
 9 files changed, 1112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 0000000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===============
+
+Required Properties:
+#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
+		cells is defined by the binding for the phy node. The PHY
+		provider can use the values in cells to find the appropriate
+		PHY.
+
+For example:
+
+phys: phy {
+    compatible = "xxx";
+    reg = <...>;
+    .
+    .
+    #phy-cells = <1>;
+    .
+    .
+};
+
+That node describes an IP block (PHY provider) that implements 2 different PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should be
+given while trying to get a reference to it.
+
+PHY user node
+=============
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+	    *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&usb2_phy>, <&usb3_phy>;
+    phy-names = "usb2phy", "usb3phy";
+    .
+    .
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&phys 1>;
+    phy-names = "usbphy";
+    .
+    .
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+"1" to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 0000000..05f8fda
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,129 @@
+			    PHY SUBSYSTEM
+		  Kishon Vijay Abraham I <kishon@ti.com>
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+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 for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the PHY, the framework provides its own implementation of of_xlate in
+of_phy_simple_xlate. If the PHY provider implements multiple instances, it
+should provide its own implementation of of_xlate. of_xlate is used only for
+dt boot case.
+
+struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+
+__of_phy_provider_register and __devm_of_phy_provider_register can be used to
+register the phy_provider and it takes device, owner and of_xlate as
+arguments. For the dt boot case, all PHY providers should use one of the above
+2 APIs to register the PHY provider.
+
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+void of_phy_provider_unregister(struct phy_provider *phy_provider);
+
+devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
+unregister the PHY.
+
+3. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provides 2 APIs to create the PHY.
+
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+	const char *label);
+extern struct phy *devm_phy_create(struct device *dev, u8 id,
+        const struct phy_ops *ops, const char *label);
+
+The PHY drivers can use one of the above 2 APIs to create the PHY by passing
+the device pointer, id, phy ops, label and a driver data.
+phy_ops is a set of function pointers for performing PHY operations such as
+init, exit, power_on and power_off. *label* is mandatory for non-dt boot case
+and it should be unique as well.
+
+Inorder to dereference the private data (in phy_ops), the phy provider driver
+can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
+phy_ops to get back the private data.
+
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a reference to
+it. This framework provides the following APIs to get a reference to the PHY.
+
+struct phy *phy_get(struct device *dev, const char *string);
+struct phy *devm_phy_get(struct device *dev, const char *string);
+
+phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot,
+the string arguments should contain the phy name as given in the dt data and
+in the case of non-dt boot, it should contain the label of the PHY.
+The only difference between the two APIs is that devm_phy_get associates the
+device with the PHY using devres on successful PHY get. On driver detach,
+release function is invoked on the the devres data and devres data is freed.
+
+5. Releasing a reference to the PHY
+
+When the controller no longer needs the PHY, it has to release the reference
+to the PHY it has obtained using the APIs mentioned in the above section. The
+PHY framework provides 2 APIs to release a reference to the PHY.
+
+void phy_put(struct phy *phy);
+void devm_phy_put(struct device *dev, struct phy *phy);
+
+Both these APIs are used to release a reference to the PHY and devm_phy_put
+destroys the devres associated with this PHY.
+
+6. Destroying the PHY
+
+When the driver that created the PHY is unloaded, it should destroy the PHY it
+created using one of the following 2 APIs.
+
+void phy_destroy(struct phy *phy);
+void devm_phy_destroy(struct device *dev, struct phy *phy);
+
+Both these APIs destroy the PHY and devm_phy_destroy destroys the devres
+associated with this PHY.
+
+7. PM Runtime
+
+This subsystem is pm runtime enabled. So while creating the PHY,
+pm_runtime_enable of the phy device created by this subsystem is called and
+while destroying the PHY, pm_runtime_disable is called. Note that the phy
+device created by this subsystem will be a child of the device that calls
+phy_create (PHY provider device).
+
+So pm_runtime_get_sync of the phy_device created by this subsystem will invoke
+pm_runtime_get_sync of PHY provider device because of parent-child relationship.
+It should also be noted that phy_power_on and phy_power_off performs
+phy_pm_runtime_get_sync and phy_pm_runtime_put respectively.
+There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync,
+phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
+phy_pm_runtime_forbid for performing PM operations.
+
+8. DeviceTree Binding
+
+The documentation for PHY dt binding can be found @
+Documentation/devicetree/bindings/phy/phy-bindings.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 0c9dc71..c234461 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3536,6 +3536,13 @@ S:	Maintained
 F:	include/asm-generic
 F:	include/uapi/asm-generic
 
+GENERIC PHY FRAMEWORK
+M:	Kishon Vijay Abraham I <kishon@ti.com>
+L:	linux-kernel@vger.kernel.org
+S:	Supported
+F:	drivers/phy/
+F:	include/linux/phy/
+
 GENERIC UIO DRIVER FOR PCI DEVICES
 M:	"Michael S. Tsirkin" <mst@redhat.com>
 L:	kvm@vger.kernel.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 9953a42..2943fb6 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -166,4 +166,6 @@ source "drivers/ipack/Kconfig"
 
 source "drivers/reset/Kconfig"
 
+source "drivers/phy/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 130abc1..46c99a1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -8,6 +8,8 @@
 obj-y				+= irqchip/
 obj-y				+= bus/
 
+obj-$(CONFIG_GENERIC_PHY)	+= phy/
+
 # GPIO must come after pinctrl as gpios may need to mux pins etc
 obj-y				+= pinctrl/
 obj-y				+= gpio/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 0000000..5f85909
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,13 @@
+#
+# PHY
+#
+
+menuconfig GENERIC_PHY
+	tristate "PHY Subsystem"
+	help
+	  Generic PHY support.
+
+	  This framework is designed to provide a generic interface for PHY
+	  devices present in the kernel. This layer will have the generic
+	  API by which phy drivers can create PHY using the phy framework and
+	  phy users can obtain reference to the PHY.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 0000000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 0000000..6c75dc3
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,544 @@
+/*
+ * phy-core.c  --  Generic Phy framework.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I <kishon@ti.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/pm_runtime.h>
+
+static struct class *phy_class;
+static DEFINE_MUTEX(phy_provider_mutex);
+static LIST_HEAD(phy_provider_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_put(phy);
+}
+
+static void devm_phy_provider_release(struct device *dev, void *res)
+{
+	struct phy_provider *phy_provider = *(struct phy_provider **)res;
+
+	of_phy_provider_unregister(phy_provider);
+}
+
+static void devm_phy_consume(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_destroy(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+	return res == match_data;
+}
+
+static struct phy *phy_lookup(const char *phy_name)
+{
+	struct phy *phy;
+	struct device *dev;
+	struct class_dev_iter iter;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		if (strcmp(phy->label, phy_name))
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+
+static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
+{
+	struct phy_provider *phy_provider;
+
+	list_for_each_entry(phy_provider, &phy_provider_list, list) {
+		if (phy_provider->dev->of_node == node)
+			return phy_provider;
+	}
+
+	return ERR_PTR(-EPROBE_DEFER);
+}
+
+/**
+ * of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. This function uses of_xlate call back function provided
+ * while registering the phy_provider to find the phy instance.
+ */
+static struct phy *of_phy_get(struct device *dev, int index)
+{
+	int ret;
+	struct phy_provider *phy_provider;
+	struct phy *phy = NULL;
+	struct of_phandle_args args;
+
+	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
+		index, &args);
+	if (ret) {
+		dev_dbg(dev, "failed to get phy in %s node\n",
+			dev->of_node->full_name);
+		return ERR_PTR(-ENODEV);
+	}
+
+	mutex_lock(&phy_provider_mutex);
+	phy_provider = of_phy_provider_lookup(args.np);
+	if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
+		phy = ERR_PTR(-EPROBE_DEFER);
+		goto err0;
+	}
+
+	phy = phy_provider->of_xlate(phy_provider->dev, &args);
+	module_put(phy_provider->owner);
+
+err0:
+	mutex_unlock(&phy_provider_mutex);
+	of_node_put(args.np);
+
+	return phy;
+}
+
+/**
+ * phy_put() - release the PHY
+ * @phy: the phy returned by phy_get()
+ *
+ * Releases a refcount the caller received from phy_get().
+ */
+void phy_put(struct phy *phy)
+{
+	if (IS_ERR(phy))
+		return;
+
+	module_put(phy->ops->owner);
+	put_device(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_put);
+
+/**
+ * devm_phy_put() - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * of_phy_simple_xlate() - returns the phy instance from phy provider
+ * @dev: the PHY provider device
+ * @args: of_phandle_args (not used here)
+ *
+ * Intended to be used by phy provider for the common case where #phy-cells is
+ * 0. For other cases where #phy-cells is greater than '0', the phy provider
+ * should provide a custom of_xlate function that reads the *args* and returns
+ * the appropriate phy.
+ */
+struct phy *of_phy_simple_xlate(struct device *dev, struct of_phandle_args
+	*args)
+{
+	struct phy *phy;
+	struct class_dev_iter iter;
+	struct device_node *node = dev->of_node;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		if (node != phy->dev.of_node)
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
+
+/**
+ * phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling phy_put() to release that count.
+ */
+struct phy *phy_get(struct device *dev, const char *string)
+{
+	int index = 0;
+	struct phy *phy = NULL;
+
+	if (string == NULL) {
+		dev_WARN(dev, "missing string\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (dev->of_node) {
+		index = of_property_match_string(dev->of_node, "phy-names",
+			string);
+		phy = of_phy_get(dev, index);
+		if (IS_ERR(phy)) {
+			dev_WARN(dev, "unable to find phy\n");
+			return phy;
+		}
+	} else {
+		phy = phy_lookup(string);
+		if (IS_ERR(phy)) {
+			dev_WARN(dev, "unable to find phy\n");
+			return phy;
+		}
+	}
+
+	if (!try_module_get(phy->ops->owner))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	get_device(&phy->dev);
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(phy_get);
+
+/**
+ * devm_phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_get(dev, string);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+	const char *label)
+{
+	int ret;
+	struct phy *phy;
+
+	if (!dev) {
+		dev_WARN(dev, "no device provided for PHY\n");
+		ret = -EINVAL;
+		goto err0;
+	}
+
+	phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+	if (!phy) {
+		ret = -ENOMEM;
+		goto err0;
+	}
+
+	device_initialize(&phy->dev);
+	mutex_init(&phy->mutex);
+
+	phy->dev.class = phy_class;
+	phy->dev.parent = dev;
+	phy->dev.of_node = dev->of_node;
+	phy->id = id;
+	phy->ops = ops;
+	phy->label = kstrdup(label, GFP_KERNEL);
+
+	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
+	if (ret)
+		goto err1;
+
+	ret = device_add(&phy->dev);
+	if (ret)
+		goto err1;
+
+	if (pm_runtime_enabled(dev)) {
+		pm_runtime_enable(&phy->dev);
+		pm_runtime_no_callbacks(&phy->dev);
+	}
+
+	return phy;
+
+err1:
+	put_device(&phy->dev);
+	kfree(phy->label);
+	kfree(phy);
+
+err0:
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+
+/**
+ * devm_phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ *
+ * Creates a new PHY device adding it to the PHY class.
+ * While at that, it also associates the device with the phy using devres.
+ * On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_consume, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_create(dev, id, ops, label);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_create);
+
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+	pm_runtime_disable(&phy->dev);
+	device_unregister(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_destroy);
+
+/**
+ * devm_phy_destroy() - destroy the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_destroy
+ * to destroy the phy.
+ */
+void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_consume, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_destroy);
+
+/**
+ * __of_phy_provider_register() - create/register phy provider with the framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider.
+ */
+struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider *phy_provider;
+
+	phy_provider = kzalloc(sizeof(*phy_provider), GFP_KERNEL);
+	if (!phy_provider)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider->dev = dev;
+	phy_provider->owner = owner;
+	phy_provider->of_xlate = of_xlate;
+
+	mutex_lock(&phy_provider_mutex);
+	list_add_tail(&phy_provider->list, &phy_provider_list);
+	mutex_unlock(&phy_provider_mutex);
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__of_phy_provider_register);
+
+/**
+ * __devm_of_phy_provider_register() - create/register phy provider with the
+ * framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider. While at that, it also associates the device with the
+ * phy provider using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ */
+struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider **ptr, *phy_provider;
+
+	ptr = devres_alloc(devm_phy_provider_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider = __of_phy_provider_register(dev, owner, of_xlate);
+	if (!IS_ERR(phy_provider)) {
+		*ptr = phy_provider;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__devm_of_phy_provider_register);
+
+/**
+ * of_phy_provider_unregister() - unregister phy provider from the framework
+ * @phy_provider: phy provider returned by of_phy_provider_register()
+ *
+ * Removes the phy_provider created using of_phy_provider_register().
+ */
+void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+	if (IS_ERR(phy_provider))
+		return;
+
+	mutex_lock(&phy_provider_mutex);
+	list_del(&phy_provider->list);
+	kfree(phy_provider);
+	mutex_unlock(&phy_provider_mutex);
+}
+EXPORT_SYMBOL_GPL(of_phy_provider_unregister);
+
+/**
+ * devm_of_phy_provider_unregister() - remove phy provider from the framework
+ * @dev: struct device of the phy provider
+ *
+ * destroys the devres associated with this phy provider and invokes
+ * of_phy_provider_unregister to unregister the phy provider.
+ */
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider) {
+	int r;
+
+	r = devres_destroy(dev, devm_phy_provider_release, devm_phy_match,
+		phy_provider);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY provider device resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_provider_unregister);
+
+/**
+ * phy_release() - release the phy
+ * @dev: the dev member within phy
+ *
+ * When the last reference to the device is removed, it is called
+ * from the embedded kobject as release method.
+ */
+static void phy_release(struct device *dev)
+{
+	struct phy *phy;
+
+	phy = to_phy(dev);
+	dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
+	kfree(phy->label);
+	kfree(phy);
+}
+
+static int __init phy_core_init(void)
+{
+	phy_class = class_create(THIS_MODULE, "phy");
+	if (IS_ERR(phy_class)) {
+		pr_err("failed to create phy class --> %ld\n",
+			PTR_ERR(phy_class));
+		return PTR_ERR(phy_class);
+	}
+
+	phy_class->dev_release = phy_release;
+
+	return 0;
+}
+module_init(phy_core_init);
+
+static void __exit phy_core_exit(void)
+{
+	class_destroy(phy_class);
+}
+module_exit(phy_core_exit);
+
+MODULE_DESCRIPTION("Generic PHY Framework");
+MODULE_AUTHOR("Kishon Vijay Abraham I <kishon@ti.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 0000000..ae09503
--- /dev/null
+++ b/include/linux/phy/phy.h
@@ -0,0 +1,344 @@
+/*
+ * phy.h -- generic phy header file
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I <kishon@ti.com>
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __DRIVERS_PHY_H
+#define __DRIVERS_PHY_H
+
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/device.h>
+#include <linux/pm_runtime.h>
+
+struct phy;
+
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @power_on: powering on the phy
+ * @power_off: powering off the phy
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+	int	(*init)(struct phy *phy);
+	int	(*exit)(struct phy *phy);
+	int	(*power_on)(struct phy *phy);
+	int	(*power_off)(struct phy *phy);
+	struct module *owner;
+};
+
+/**
+ * struct phy - represents the phy device
+ * @dev: phy device
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ * @mutex: mutex to protect phy_ops
+ * @init_count: used to protect when the PHY is used by multiple consumers
+ * @power_count: used to protect when the PHY is used by multiple consumers
+ */
+struct phy {
+	struct device		dev;
+	int			id;
+	const struct phy_ops	*ops;
+	const char		*label;
+	struct mutex		mutex;
+	int			init_count;
+	int			power_count;
+};
+
+/**
+ * struct phy_provider - represents the phy provider
+ * @dev: phy provider device
+ * @owner: the module owner having of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy pointer
+ * @list: to maintain a linked list of PHY providers
+ */
+struct phy_provider {
+	struct device		*dev;
+	struct module		*owner;
+	struct list_head	list;
+	struct phy * (*of_xlate)(struct device *dev,
+		struct of_phandle_args *args);
+};
+
+#define	to_phy(dev)	(container_of((dev), struct phy, dev))
+
+#define	of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+#define	devm_of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+static inline void phy_set_drvdata(struct phy *phy, void *data)
+{
+	dev_set_drvdata(&phy->dev, data);
+}
+
+static inline void *phy_get_drvdata(struct phy *phy)
+{
+	return dev_get_drvdata(&phy->dev);
+}
+
+#if IS_ENABLED(CONFIG_GENERIC_PHY)
+extern struct phy *phy_get(struct device *dev, const char *string);
+extern struct phy *devm_phy_get(struct device *dev, const char *string);
+extern void phy_put(struct phy *phy);
+extern void devm_phy_put(struct device *dev, struct phy *phy);
+extern struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args);
+extern struct phy *phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label);
+extern struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label);
+extern void phy_destroy(struct phy *phy);
+extern void devm_phy_destroy(struct device *dev, struct phy *phy);
+extern struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern void of_phy_provider_unregister(struct phy_provider *phy_provider);
+extern void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+#else
+static inline struct phy *phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_put(struct phy *phy)
+{
+}
+
+static inline void devm_phy_put(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_destroy(struct phy *phy)
+{
+}
+
+static inline void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy_provider *__of_phy_provider_register(
+	struct device *dev, struct module *owner, struct phy * (*of_xlate)(
+	struct device *dev, struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy_provider *__devm_of_phy_provider_register(struct device
+	*dev, struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+}
+
+static inline void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider)
+{
+}
+#endif
+
+static inline int phy_pm_runtime_get(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get(&phy->dev);
+}
+
+static inline int phy_pm_runtime_get_sync(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get_sync(&phy->dev);
+}
+
+static inline int phy_pm_runtime_put(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put(&phy->dev);
+}
+
+static inline int phy_pm_runtime_put_sync(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put_sync(&phy->dev);
+}
+
+static inline void phy_pm_runtime_allow(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_allow(&phy->dev);
+}
+
+static inline void phy_pm_runtime_forbid(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_forbid(&phy->dev);
+}
+
+static inline int phy_init(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->init_count++ == 0 && phy->ops->init) {
+		ret = phy->ops->init(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy init failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->init_count == 0 && phy->ops->exit) {
+		ret = phy->ops->exit(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy exit failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+
+static inline int phy_power_on(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->power_count++ == 0 && phy->ops->power_on) {
+		ret = phy->ops->power_on(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweron failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+
+	return ret;
+}
+
+static inline int phy_power_off(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->power_count == 0 && phy->ops->power_off) {
+		ret =  phy->ops->power_off(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweroff failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+
+	return ret;
+}
+
+#endif /* __DRIVERS_PHY_H */
-- 
1.7.10.4

[PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

The PHY framework 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. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.

PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Tested-by: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
 .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
 Documentation/phy.txt                              |  129 +++++
 MAINTAINERS                                        |    7 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   13 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  544 ++++++++++++++++++++
 include/linux/phy/phy.h                            |  344 +++++++++++++
 9 files changed, 1112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 0000000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===============
+
+Required Properties:
+#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
+		cells is defined by the binding for the phy node. The PHY
+		provider can use the values in cells to find the appropriate
+		PHY.
+
+For example:
+
+phys: phy {
+    compatible = "xxx";
+    reg = <...>;
+    .
+    .
+    #phy-cells = <1>;
+    .
+    .
+};
+
+That node describes an IP block (PHY provider) that implements 2 different PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should be
+given while trying to get a reference to it.
+
+PHY user node
+=============
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+	    *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&usb2_phy>, <&usb3_phy>;
+    phy-names = "usb2phy", "usb3phy";
+    .
+    .
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&phys 1>;
+    phy-names = "usbphy";
+    .
+    .
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+"1" to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 0000000..05f8fda
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,129 @@
+			    PHY SUBSYSTEM
+		  Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+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 for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the PHY, the framework provides its own implementation of of_xlate in
+of_phy_simple_xlate. If the PHY provider implements multiple instances, it
+should provide its own implementation of of_xlate. of_xlate is used only for
+dt boot case.
+
+struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+
+__of_phy_provider_register and __devm_of_phy_provider_register can be used to
+register the phy_provider and it takes device, owner and of_xlate as
+arguments. For the dt boot case, all PHY providers should use one of the above
+2 APIs to register the PHY provider.
+
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+void of_phy_provider_unregister(struct phy_provider *phy_provider);
+
+devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
+unregister the PHY.
+
+3. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provides 2 APIs to create the PHY.
+
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+	const char *label);
+extern struct phy *devm_phy_create(struct device *dev, u8 id,
+        const struct phy_ops *ops, const char *label);
+
+The PHY drivers can use one of the above 2 APIs to create the PHY by passing
+the device pointer, id, phy ops, label and a driver data.
+phy_ops is a set of function pointers for performing PHY operations such as
+init, exit, power_on and power_off. *label* is mandatory for non-dt boot case
+and it should be unique as well.
+
+Inorder to dereference the private data (in phy_ops), the phy provider driver
+can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
+phy_ops to get back the private data.
+
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a reference to
+it. This framework provides the following APIs to get a reference to the PHY.
+
+struct phy *phy_get(struct device *dev, const char *string);
+struct phy *devm_phy_get(struct device *dev, const char *string);
+
+phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot,
+the string arguments should contain the phy name as given in the dt data and
+in the case of non-dt boot, it should contain the label of the PHY.
+The only difference between the two APIs is that devm_phy_get associates the
+device with the PHY using devres on successful PHY get. On driver detach,
+release function is invoked on the the devres data and devres data is freed.
+
+5. Releasing a reference to the PHY
+
+When the controller no longer needs the PHY, it has to release the reference
+to the PHY it has obtained using the APIs mentioned in the above section. The
+PHY framework provides 2 APIs to release a reference to the PHY.
+
+void phy_put(struct phy *phy);
+void devm_phy_put(struct device *dev, struct phy *phy);
+
+Both these APIs are used to release a reference to the PHY and devm_phy_put
+destroys the devres associated with this PHY.
+
+6. Destroying the PHY
+
+When the driver that created the PHY is unloaded, it should destroy the PHY it
+created using one of the following 2 APIs.
+
+void phy_destroy(struct phy *phy);
+void devm_phy_destroy(struct device *dev, struct phy *phy);
+
+Both these APIs destroy the PHY and devm_phy_destroy destroys the devres
+associated with this PHY.
+
+7. PM Runtime
+
+This subsystem is pm runtime enabled. So while creating the PHY,
+pm_runtime_enable of the phy device created by this subsystem is called and
+while destroying the PHY, pm_runtime_disable is called. Note that the phy
+device created by this subsystem will be a child of the device that calls
+phy_create (PHY provider device).
+
+So pm_runtime_get_sync of the phy_device created by this subsystem will invoke
+pm_runtime_get_sync of PHY provider device because of parent-child relationship.
+It should also be noted that phy_power_on and phy_power_off performs
+phy_pm_runtime_get_sync and phy_pm_runtime_put respectively.
+There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync,
+phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
+phy_pm_runtime_forbid for performing PM operations.
+
+8. DeviceTree Binding
+
+The documentation for PHY dt binding can be found @
+Documentation/devicetree/bindings/phy/phy-bindings.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 0c9dc71..c234461 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3536,6 +3536,13 @@ S:	Maintained
 F:	include/asm-generic
 F:	include/uapi/asm-generic
 
+GENERIC PHY FRAMEWORK
+M:	Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
+L:	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+S:	Supported
+F:	drivers/phy/
+F:	include/linux/phy/
+
 GENERIC UIO DRIVER FOR PCI DEVICES
 M:	"Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
 L:	kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 9953a42..2943fb6 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -166,4 +166,6 @@ source "drivers/ipack/Kconfig"
 
 source "drivers/reset/Kconfig"
 
+source "drivers/phy/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 130abc1..46c99a1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -8,6 +8,8 @@
 obj-y				+= irqchip/
 obj-y				+= bus/
 
+obj-$(CONFIG_GENERIC_PHY)	+= phy/
+
 # GPIO must come after pinctrl as gpios may need to mux pins etc
 obj-y				+= pinctrl/
 obj-y				+= gpio/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 0000000..5f85909
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,13 @@
+#
+# PHY
+#
+
+menuconfig GENERIC_PHY
+	tristate "PHY Subsystem"
+	help
+	  Generic PHY support.
+
+	  This framework is designed to provide a generic interface for PHY
+	  devices present in the kernel. This layer will have the generic
+	  API by which phy drivers can create PHY using the phy framework and
+	  phy users can obtain reference to the PHY.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 0000000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 0000000..6c75dc3
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,544 @@
+/*
+ * phy-core.c  --  Generic Phy framework.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/pm_runtime.h>
+
+static struct class *phy_class;
+static DEFINE_MUTEX(phy_provider_mutex);
+static LIST_HEAD(phy_provider_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_put(phy);
+}
+
+static void devm_phy_provider_release(struct device *dev, void *res)
+{
+	struct phy_provider *phy_provider = *(struct phy_provider **)res;
+
+	of_phy_provider_unregister(phy_provider);
+}
+
+static void devm_phy_consume(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_destroy(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+	return res == match_data;
+}
+
+static struct phy *phy_lookup(const char *phy_name)
+{
+	struct phy *phy;
+	struct device *dev;
+	struct class_dev_iter iter;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		if (strcmp(phy->label, phy_name))
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+
+static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
+{
+	struct phy_provider *phy_provider;
+
+	list_for_each_entry(phy_provider, &phy_provider_list, list) {
+		if (phy_provider->dev->of_node == node)
+			return phy_provider;
+	}
+
+	return ERR_PTR(-EPROBE_DEFER);
+}
+
+/**
+ * of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. This function uses of_xlate call back function provided
+ * while registering the phy_provider to find the phy instance.
+ */
+static struct phy *of_phy_get(struct device *dev, int index)
+{
+	int ret;
+	struct phy_provider *phy_provider;
+	struct phy *phy = NULL;
+	struct of_phandle_args args;
+
+	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
+		index, &args);
+	if (ret) {
+		dev_dbg(dev, "failed to get phy in %s node\n",
+			dev->of_node->full_name);
+		return ERR_PTR(-ENODEV);
+	}
+
+	mutex_lock(&phy_provider_mutex);
+	phy_provider = of_phy_provider_lookup(args.np);
+	if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
+		phy = ERR_PTR(-EPROBE_DEFER);
+		goto err0;
+	}
+
+	phy = phy_provider->of_xlate(phy_provider->dev, &args);
+	module_put(phy_provider->owner);
+
+err0:
+	mutex_unlock(&phy_provider_mutex);
+	of_node_put(args.np);
+
+	return phy;
+}
+
+/**
+ * phy_put() - release the PHY
+ * @phy: the phy returned by phy_get()
+ *
+ * Releases a refcount the caller received from phy_get().
+ */
+void phy_put(struct phy *phy)
+{
+	if (IS_ERR(phy))
+		return;
+
+	module_put(phy->ops->owner);
+	put_device(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_put);
+
+/**
+ * devm_phy_put() - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * of_phy_simple_xlate() - returns the phy instance from phy provider
+ * @dev: the PHY provider device
+ * @args: of_phandle_args (not used here)
+ *
+ * Intended to be used by phy provider for the common case where #phy-cells is
+ * 0. For other cases where #phy-cells is greater than '0', the phy provider
+ * should provide a custom of_xlate function that reads the *args* and returns
+ * the appropriate phy.
+ */
+struct phy *of_phy_simple_xlate(struct device *dev, struct of_phandle_args
+	*args)
+{
+	struct phy *phy;
+	struct class_dev_iter iter;
+	struct device_node *node = dev->of_node;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		if (node != phy->dev.of_node)
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
+
+/**
+ * phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling phy_put() to release that count.
+ */
+struct phy *phy_get(struct device *dev, const char *string)
+{
+	int index = 0;
+	struct phy *phy = NULL;
+
+	if (string == NULL) {
+		dev_WARN(dev, "missing string\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (dev->of_node) {
+		index = of_property_match_string(dev->of_node, "phy-names",
+			string);
+		phy = of_phy_get(dev, index);
+		if (IS_ERR(phy)) {
+			dev_WARN(dev, "unable to find phy\n");
+			return phy;
+		}
+	} else {
+		phy = phy_lookup(string);
+		if (IS_ERR(phy)) {
+			dev_WARN(dev, "unable to find phy\n");
+			return phy;
+		}
+	}
+
+	if (!try_module_get(phy->ops->owner))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	get_device(&phy->dev);
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(phy_get);
+
+/**
+ * devm_phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_get(dev, string);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+	const char *label)
+{
+	int ret;
+	struct phy *phy;
+
+	if (!dev) {
+		dev_WARN(dev, "no device provided for PHY\n");
+		ret = -EINVAL;
+		goto err0;
+	}
+
+	phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+	if (!phy) {
+		ret = -ENOMEM;
+		goto err0;
+	}
+
+	device_initialize(&phy->dev);
+	mutex_init(&phy->mutex);
+
+	phy->dev.class = phy_class;
+	phy->dev.parent = dev;
+	phy->dev.of_node = dev->of_node;
+	phy->id = id;
+	phy->ops = ops;
+	phy->label = kstrdup(label, GFP_KERNEL);
+
+	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
+	if (ret)
+		goto err1;
+
+	ret = device_add(&phy->dev);
+	if (ret)
+		goto err1;
+
+	if (pm_runtime_enabled(dev)) {
+		pm_runtime_enable(&phy->dev);
+		pm_runtime_no_callbacks(&phy->dev);
+	}
+
+	return phy;
+
+err1:
+	put_device(&phy->dev);
+	kfree(phy->label);
+	kfree(phy);
+
+err0:
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+
+/**
+ * devm_phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ *
+ * Creates a new PHY device adding it to the PHY class.
+ * While at that, it also associates the device with the phy using devres.
+ * On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_consume, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_create(dev, id, ops, label);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_create);
+
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+	pm_runtime_disable(&phy->dev);
+	device_unregister(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_destroy);
+
+/**
+ * devm_phy_destroy() - destroy the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_destroy
+ * to destroy the phy.
+ */
+void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_consume, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_destroy);
+
+/**
+ * __of_phy_provider_register() - create/register phy provider with the framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider.
+ */
+struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider *phy_provider;
+
+	phy_provider = kzalloc(sizeof(*phy_provider), GFP_KERNEL);
+	if (!phy_provider)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider->dev = dev;
+	phy_provider->owner = owner;
+	phy_provider->of_xlate = of_xlate;
+
+	mutex_lock(&phy_provider_mutex);
+	list_add_tail(&phy_provider->list, &phy_provider_list);
+	mutex_unlock(&phy_provider_mutex);
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__of_phy_provider_register);
+
+/**
+ * __devm_of_phy_provider_register() - create/register phy provider with the
+ * framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider. While at that, it also associates the device with the
+ * phy provider using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ */
+struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider **ptr, *phy_provider;
+
+	ptr = devres_alloc(devm_phy_provider_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider = __of_phy_provider_register(dev, owner, of_xlate);
+	if (!IS_ERR(phy_provider)) {
+		*ptr = phy_provider;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__devm_of_phy_provider_register);
+
+/**
+ * of_phy_provider_unregister() - unregister phy provider from the framework
+ * @phy_provider: phy provider returned by of_phy_provider_register()
+ *
+ * Removes the phy_provider created using of_phy_provider_register().
+ */
+void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+	if (IS_ERR(phy_provider))
+		return;
+
+	mutex_lock(&phy_provider_mutex);
+	list_del(&phy_provider->list);
+	kfree(phy_provider);
+	mutex_unlock(&phy_provider_mutex);
+}
+EXPORT_SYMBOL_GPL(of_phy_provider_unregister);
+
+/**
+ * devm_of_phy_provider_unregister() - remove phy provider from the framework
+ * @dev: struct device of the phy provider
+ *
+ * destroys the devres associated with this phy provider and invokes
+ * of_phy_provider_unregister to unregister the phy provider.
+ */
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider) {
+	int r;
+
+	r = devres_destroy(dev, devm_phy_provider_release, devm_phy_match,
+		phy_provider);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY provider device resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_provider_unregister);
+
+/**
+ * phy_release() - release the phy
+ * @dev: the dev member within phy
+ *
+ * When the last reference to the device is removed, it is called
+ * from the embedded kobject as release method.
+ */
+static void phy_release(struct device *dev)
+{
+	struct phy *phy;
+
+	phy = to_phy(dev);
+	dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
+	kfree(phy->label);
+	kfree(phy);
+}
+
+static int __init phy_core_init(void)
+{
+	phy_class = class_create(THIS_MODULE, "phy");
+	if (IS_ERR(phy_class)) {
+		pr_err("failed to create phy class --> %ld\n",
+			PTR_ERR(phy_class));
+		return PTR_ERR(phy_class);
+	}
+
+	phy_class->dev_release = phy_release;
+
+	return 0;
+}
+module_init(phy_core_init);
+
+static void __exit phy_core_exit(void)
+{
+	class_destroy(phy_class);
+}
+module_exit(phy_core_exit);
+
+MODULE_DESCRIPTION("Generic PHY Framework");
+MODULE_AUTHOR("Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 0000000..ae09503
--- /dev/null
+++ b/include/linux/phy/phy.h
@@ -0,0 +1,344 @@
+/*
+ * phy.h -- generic phy header file
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __DRIVERS_PHY_H
+#define __DRIVERS_PHY_H
+
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/device.h>
+#include <linux/pm_runtime.h>
+
+struct phy;
+
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @power_on: powering on the phy
+ * @power_off: powering off the phy
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+	int	(*init)(struct phy *phy);
+	int	(*exit)(struct phy *phy);
+	int	(*power_on)(struct phy *phy);
+	int	(*power_off)(struct phy *phy);
+	struct module *owner;
+};
+
+/**
+ * struct phy - represents the phy device
+ * @dev: phy device
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ * @mutex: mutex to protect phy_ops
+ * @init_count: used to protect when the PHY is used by multiple consumers
+ * @power_count: used to protect when the PHY is used by multiple consumers
+ */
+struct phy {
+	struct device		dev;
+	int			id;
+	const struct phy_ops	*ops;
+	const char		*label;
+	struct mutex		mutex;
+	int			init_count;
+	int			power_count;
+};
+
+/**
+ * struct phy_provider - represents the phy provider
+ * @dev: phy provider device
+ * @owner: the module owner having of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy pointer
+ * @list: to maintain a linked list of PHY providers
+ */
+struct phy_provider {
+	struct device		*dev;
+	struct module		*owner;
+	struct list_head	list;
+	struct phy * (*of_xlate)(struct device *dev,
+		struct of_phandle_args *args);
+};
+
+#define	to_phy(dev)	(container_of((dev), struct phy, dev))
+
+#define	of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+#define	devm_of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+static inline void phy_set_drvdata(struct phy *phy, void *data)
+{
+	dev_set_drvdata(&phy->dev, data);
+}
+
+static inline void *phy_get_drvdata(struct phy *phy)
+{
+	return dev_get_drvdata(&phy->dev);
+}
+
+#if IS_ENABLED(CONFIG_GENERIC_PHY)
+extern struct phy *phy_get(struct device *dev, const char *string);
+extern struct phy *devm_phy_get(struct device *dev, const char *string);
+extern void phy_put(struct phy *phy);
+extern void devm_phy_put(struct device *dev, struct phy *phy);
+extern struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args);
+extern struct phy *phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label);
+extern struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label);
+extern void phy_destroy(struct phy *phy);
+extern void devm_phy_destroy(struct device *dev, struct phy *phy);
+extern struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern void of_phy_provider_unregister(struct phy_provider *phy_provider);
+extern void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+#else
+static inline struct phy *phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_put(struct phy *phy)
+{
+}
+
+static inline void devm_phy_put(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_destroy(struct phy *phy)
+{
+}
+
+static inline void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy_provider *__of_phy_provider_register(
+	struct device *dev, struct module *owner, struct phy * (*of_xlate)(
+	struct device *dev, struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy_provider *__devm_of_phy_provider_register(struct device
+	*dev, struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+}
+
+static inline void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider)
+{
+}
+#endif
+
+static inline int phy_pm_runtime_get(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get(&phy->dev);
+}
+
+static inline int phy_pm_runtime_get_sync(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get_sync(&phy->dev);
+}
+
+static inline int phy_pm_runtime_put(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put(&phy->dev);
+}
+
+static inline int phy_pm_runtime_put_sync(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put_sync(&phy->dev);
+}
+
+static inline void phy_pm_runtime_allow(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_allow(&phy->dev);
+}
+
+static inline void phy_pm_runtime_forbid(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_forbid(&phy->dev);
+}
+
+static inline int phy_init(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->init_count++ == 0 && phy->ops->init) {
+		ret = phy->ops->init(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy init failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->init_count == 0 && phy->ops->exit) {
+		ret = phy->ops->exit(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy exit failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+
+static inline int phy_power_on(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->power_count++ == 0 && phy->ops->power_on) {
+		ret = phy->ops->power_on(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweron failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+
+	return ret;
+}
+
+static inline int phy_power_off(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->power_count == 0 && phy->ops->power_off) {
+		ret =  phy->ops->power_off(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweroff failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+
+	return ret;
+}
+
+#endif /* __DRIVERS_PHY_H */
-- 
1.7.10.4

[PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

The PHY framework 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. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.

PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
 Documentation/phy.txt                              |  129 +++++
 MAINTAINERS                                        |    7 +
 drivers/Kconfig                                    |    2 +
 drivers/Makefile                                   |    2 +
 drivers/phy/Kconfig                                |   13 +
 drivers/phy/Makefile                               |    5 +
 drivers/phy/phy-core.c                             |  544 ++++++++++++++++++++
 include/linux/phy/phy.h                            |  344 +++++++++++++
 9 files changed, 1112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 0000000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===============
+
+Required Properties:
+#phy-cells:	Number of cells in a PHY specifier;  The meaning of all those
+		cells is defined by the binding for the phy node. The PHY
+		provider can use the values in cells to find the appropriate
+		PHY.
+
+For example:
+
+phys: phy {
+    compatible = "xxx";
+    reg = <...>;
+    .
+    .
+    #phy-cells = <1>;
+    .
+    .
+};
+
+That node describes an IP block (PHY provider) that implements 2 different PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should be
+given while trying to get a reference to it.
+
+PHY user node
+=============
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+	    *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&usb2_phy>, <&usb3_phy>;
+    phy-names = "usb2phy", "usb3phy";
+    .
+    .
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss at xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&phys 1>;
+    phy-names = "usbphy";
+    .
+    .
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+"1" to differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 0000000..05f8fda
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,129 @@
+			    PHY SUBSYSTEM
+		  Kishon Vijay Abraham I <kishon@ti.com>
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+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 for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the PHY, the framework provides its own implementation of of_xlate in
+of_phy_simple_xlate. If the PHY provider implements multiple instances, it
+should provide its own implementation of of_xlate. of_xlate is used only for
+dt boot case.
+
+struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+
+__of_phy_provider_register and __devm_of_phy_provider_register can be used to
+register the phy_provider and it takes device, owner and of_xlate as
+arguments. For the dt boot case, all PHY providers should use one of the above
+2 APIs to register the PHY provider.
+
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+void of_phy_provider_unregister(struct phy_provider *phy_provider);
+
+devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
+unregister the PHY.
+
+3. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provides 2 APIs to create the PHY.
+
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+	const char *label);
+extern struct phy *devm_phy_create(struct device *dev, u8 id,
+        const struct phy_ops *ops, const char *label);
+
+The PHY drivers can use one of the above 2 APIs to create the PHY by passing
+the device pointer, id, phy ops, label and a driver data.
+phy_ops is a set of function pointers for performing PHY operations such as
+init, exit, power_on and power_off. *label* is mandatory for non-dt boot case
+and it should be unique as well.
+
+Inorder to dereference the private data (in phy_ops), the phy provider driver
+can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
+phy_ops to get back the private data.
+
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a reference to
+it. This framework provides the following APIs to get a reference to the PHY.
+
+struct phy *phy_get(struct device *dev, const char *string);
+struct phy *devm_phy_get(struct device *dev, const char *string);
+
+phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot,
+the string arguments should contain the phy name as given in the dt data and
+in the case of non-dt boot, it should contain the label of the PHY.
+The only difference between the two APIs is that devm_phy_get associates the
+device with the PHY using devres on successful PHY get. On driver detach,
+release function is invoked on the the devres data and devres data is freed.
+
+5. Releasing a reference to the PHY
+
+When the controller no longer needs the PHY, it has to release the reference
+to the PHY it has obtained using the APIs mentioned in the above section. The
+PHY framework provides 2 APIs to release a reference to the PHY.
+
+void phy_put(struct phy *phy);
+void devm_phy_put(struct device *dev, struct phy *phy);
+
+Both these APIs are used to release a reference to the PHY and devm_phy_put
+destroys the devres associated with this PHY.
+
+6. Destroying the PHY
+
+When the driver that created the PHY is unloaded, it should destroy the PHY it
+created using one of the following 2 APIs.
+
+void phy_destroy(struct phy *phy);
+void devm_phy_destroy(struct device *dev, struct phy *phy);
+
+Both these APIs destroy the PHY and devm_phy_destroy destroys the devres
+associated with this PHY.
+
+7. PM Runtime
+
+This subsystem is pm runtime enabled. So while creating the PHY,
+pm_runtime_enable of the phy device created by this subsystem is called and
+while destroying the PHY, pm_runtime_disable is called. Note that the phy
+device created by this subsystem will be a child of the device that calls
+phy_create (PHY provider device).
+
+So pm_runtime_get_sync of the phy_device created by this subsystem will invoke
+pm_runtime_get_sync of PHY provider device because of parent-child relationship.
+It should also be noted that phy_power_on and phy_power_off performs
+phy_pm_runtime_get_sync and phy_pm_runtime_put respectively.
+There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync,
+phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
+phy_pm_runtime_forbid for performing PM operations.
+
+8. DeviceTree Binding
+
+The documentation for PHY dt binding can be found @
+Documentation/devicetree/bindings/phy/phy-bindings.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 0c9dc71..c234461 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3536,6 +3536,13 @@ S:	Maintained
 F:	include/asm-generic
 F:	include/uapi/asm-generic
 
+GENERIC PHY FRAMEWORK
+M:	Kishon Vijay Abraham I <kishon@ti.com>
+L:	linux-kernel at vger.kernel.org
+S:	Supported
+F:	drivers/phy/
+F:	include/linux/phy/
+
 GENERIC UIO DRIVER FOR PCI DEVICES
 M:	"Michael S. Tsirkin" <mst@redhat.com>
 L:	kvm at vger.kernel.org
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 9953a42..2943fb6 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -166,4 +166,6 @@ source "drivers/ipack/Kconfig"
 
 source "drivers/reset/Kconfig"
 
+source "drivers/phy/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 130abc1..46c99a1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -8,6 +8,8 @@
 obj-y				+= irqchip/
 obj-y				+= bus/
 
+obj-$(CONFIG_GENERIC_PHY)	+= phy/
+
 # GPIO must come after pinctrl as gpios may need to mux pins etc
 obj-y				+= pinctrl/
 obj-y				+= gpio/
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
new file mode 100644
index 0000000..5f85909
--- /dev/null
+++ b/drivers/phy/Kconfig
@@ -0,0 +1,13 @@
+#
+# PHY
+#
+
+menuconfig GENERIC_PHY
+	tristate "PHY Subsystem"
+	help
+	  Generic PHY support.
+
+	  This framework is designed to provide a generic interface for PHY
+	  devices present in the kernel. This layer will have the generic
+	  API by which phy drivers can create PHY using the phy framework and
+	  phy users can obtain reference to the PHY.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
new file mode 100644
index 0000000..9e9560f
--- /dev/null
+++ b/drivers/phy/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_GENERIC_PHY)	+= phy-core.o
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 0000000..6c75dc3
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,544 @@
+/*
+ * phy-core.c  --  Generic Phy framework.
+ *
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * Author: Kishon Vijay Abraham I <kishon@ti.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/export.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/pm_runtime.h>
+
+static struct class *phy_class;
+static DEFINE_MUTEX(phy_provider_mutex);
+static LIST_HEAD(phy_provider_list);
+
+static void devm_phy_release(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_put(phy);
+}
+
+static void devm_phy_provider_release(struct device *dev, void *res)
+{
+	struct phy_provider *phy_provider = *(struct phy_provider **)res;
+
+	of_phy_provider_unregister(phy_provider);
+}
+
+static void devm_phy_consume(struct device *dev, void *res)
+{
+	struct phy *phy = *(struct phy **)res;
+
+	phy_destroy(phy);
+}
+
+static int devm_phy_match(struct device *dev, void *res, void *match_data)
+{
+	return res == match_data;
+}
+
+static struct phy *phy_lookup(const char *phy_name)
+{
+	struct phy *phy;
+	struct device *dev;
+	struct class_dev_iter iter;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		if (strcmp(phy->label, phy_name))
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+
+static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
+{
+	struct phy_provider *phy_provider;
+
+	list_for_each_entry(phy_provider, &phy_provider_list, list) {
+		if (phy_provider->dev->of_node == node)
+			return phy_provider;
+	}
+
+	return ERR_PTR(-EPROBE_DEFER);
+}
+
+/**
+ * of_phy_get() - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @index: the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. This function uses of_xlate call back function provided
+ * while registering the phy_provider to find the phy instance.
+ */
+static struct phy *of_phy_get(struct device *dev, int index)
+{
+	int ret;
+	struct phy_provider *phy_provider;
+	struct phy *phy = NULL;
+	struct of_phandle_args args;
+
+	ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
+		index, &args);
+	if (ret) {
+		dev_dbg(dev, "failed to get phy in %s node\n",
+			dev->of_node->full_name);
+		return ERR_PTR(-ENODEV);
+	}
+
+	mutex_lock(&phy_provider_mutex);
+	phy_provider = of_phy_provider_lookup(args.np);
+	if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
+		phy = ERR_PTR(-EPROBE_DEFER);
+		goto err0;
+	}
+
+	phy = phy_provider->of_xlate(phy_provider->dev, &args);
+	module_put(phy_provider->owner);
+
+err0:
+	mutex_unlock(&phy_provider_mutex);
+	of_node_put(args.np);
+
+	return phy;
+}
+
+/**
+ * phy_put() - release the PHY
+ * @phy: the phy returned by phy_get()
+ *
+ * Releases a refcount the caller received from phy_get().
+ */
+void phy_put(struct phy *phy)
+{
+	if (IS_ERR(phy))
+		return;
+
+	module_put(phy->ops->owner);
+	put_device(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_put);
+
+/**
+ * devm_phy_put() - release the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_put
+ * to release the phy.
+ */
+void devm_phy_put(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_release, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_put);
+
+/**
+ * of_phy_simple_xlate() - returns the phy instance from phy provider
+ * @dev: the PHY provider device
+ * @args: of_phandle_args (not used here)
+ *
+ * Intended to be used by phy provider for the common case where #phy-cells is
+ * 0. For other cases where #phy-cells is greater than '0', the phy provider
+ * should provide a custom of_xlate function that reads the *args* and returns
+ * the appropriate phy.
+ */
+struct phy *of_phy_simple_xlate(struct device *dev, struct of_phandle_args
+	*args)
+{
+	struct phy *phy;
+	struct class_dev_iter iter;
+	struct device_node *node = dev->of_node;
+
+	class_dev_iter_init(&iter, phy_class, NULL, NULL);
+	while ((dev = class_dev_iter_next(&iter))) {
+		phy = to_phy(dev);
+		if (node != phy->dev.of_node)
+			continue;
+
+		class_dev_iter_exit(&iter);
+		return phy;
+	}
+
+	class_dev_iter_exit(&iter);
+	return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
+
+/**
+ * phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling phy_put() to release that count.
+ */
+struct phy *phy_get(struct device *dev, const char *string)
+{
+	int index = 0;
+	struct phy *phy = NULL;
+
+	if (string == NULL) {
+		dev_WARN(dev, "missing string\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (dev->of_node) {
+		index = of_property_match_string(dev->of_node, "phy-names",
+			string);
+		phy = of_phy_get(dev, index);
+		if (IS_ERR(phy)) {
+			dev_WARN(dev, "unable to find phy\n");
+			return phy;
+		}
+	} else {
+		phy = phy_lookup(string);
+		if (IS_ERR(phy)) {
+			dev_WARN(dev, "unable to find phy\n");
+			return phy;
+		}
+	}
+
+	if (!try_module_get(phy->ops->owner))
+		return ERR_PTR(-EPROBE_DEFER);
+
+	get_device(&phy->dev);
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(phy_get);
+
+/**
+ * devm_phy_get() - lookup and obtain a reference to a phy.
+ * @dev: device that requests this phy
+ * @string: the phy name as given in the dt data or phy device name
+ * for non-dt case
+ *
+ * Gets the phy using phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_get(dev, string);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_get);
+
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops,
+	const char *label)
+{
+	int ret;
+	struct phy *phy;
+
+	if (!dev) {
+		dev_WARN(dev, "no device provided for PHY\n");
+		ret = -EINVAL;
+		goto err0;
+	}
+
+	phy = kzalloc(sizeof(*phy), GFP_KERNEL);
+	if (!phy) {
+		ret = -ENOMEM;
+		goto err0;
+	}
+
+	device_initialize(&phy->dev);
+	mutex_init(&phy->mutex);
+
+	phy->dev.class = phy_class;
+	phy->dev.parent = dev;
+	phy->dev.of_node = dev->of_node;
+	phy->id = id;
+	phy->ops = ops;
+	phy->label = kstrdup(label, GFP_KERNEL);
+
+	ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
+	if (ret)
+		goto err1;
+
+	ret = device_add(&phy->dev);
+	if (ret)
+		goto err1;
+
+	if (pm_runtime_enabled(dev)) {
+		pm_runtime_enable(&phy->dev);
+		pm_runtime_no_callbacks(&phy->dev);
+	}
+
+	return phy;
+
+err1:
+	put_device(&phy->dev);
+	kfree(phy->label);
+	kfree(phy);
+
+err0:
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(phy_create);
+
+/**
+ * devm_phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ *
+ * Creates a new PHY device adding it to the PHY class.
+ * While at that, it also associates the device with the phy using devres.
+ * On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	struct phy **ptr, *phy;
+
+	ptr = devres_alloc(devm_phy_consume, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy = phy_create(dev, id, ops, label);
+	if (!IS_ERR(phy)) {
+		*ptr = phy;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy;
+}
+EXPORT_SYMBOL_GPL(devm_phy_create);
+
+/**
+ * phy_destroy() - destroy the phy
+ * @phy: the phy to be destroyed
+ *
+ * Called to destroy the phy.
+ */
+void phy_destroy(struct phy *phy)
+{
+	pm_runtime_disable(&phy->dev);
+	device_unregister(&phy->dev);
+}
+EXPORT_SYMBOL_GPL(phy_destroy);
+
+/**
+ * devm_phy_destroy() - destroy the PHY
+ * @dev: device that wants to release this phy
+ * @phy: the phy returned by devm_phy_get()
+ *
+ * destroys the devres associated with this phy and invokes phy_destroy
+ * to destroy the phy.
+ */
+void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+	int r;
+
+	r = devres_destroy(dev, devm_phy_consume, devm_phy_match, phy);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_phy_destroy);
+
+/**
+ * __of_phy_provider_register() - create/register phy provider with the framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider.
+ */
+struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider *phy_provider;
+
+	phy_provider = kzalloc(sizeof(*phy_provider), GFP_KERNEL);
+	if (!phy_provider)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider->dev = dev;
+	phy_provider->owner = owner;
+	phy_provider->of_xlate = of_xlate;
+
+	mutex_lock(&phy_provider_mutex);
+	list_add_tail(&phy_provider->list, &phy_provider_list);
+	mutex_unlock(&phy_provider_mutex);
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__of_phy_provider_register);
+
+/**
+ * __devm_of_phy_provider_register() - create/register phy provider with the
+ * framework
+ * @dev: struct device of the phy provider
+ * @owner: the module owner containing of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy provider
+ *
+ * Creates struct phy_provider from dev and of_xlate function pointer.
+ * This is used in the case of dt boot for finding the phy instance from
+ * phy provider. While at that, it also associates the device with the
+ * phy provider using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ */
+struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	struct phy_provider **ptr, *phy_provider;
+
+	ptr = devres_alloc(devm_phy_provider_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	phy_provider = __of_phy_provider_register(dev, owner, of_xlate);
+	if (!IS_ERR(phy_provider)) {
+		*ptr = phy_provider;
+		devres_add(dev, ptr);
+	} else {
+		devres_free(ptr);
+	}
+
+	return phy_provider;
+}
+EXPORT_SYMBOL_GPL(__devm_of_phy_provider_register);
+
+/**
+ * of_phy_provider_unregister() - unregister phy provider from the framework
+ * @phy_provider: phy provider returned by of_phy_provider_register()
+ *
+ * Removes the phy_provider created using of_phy_provider_register().
+ */
+void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+	if (IS_ERR(phy_provider))
+		return;
+
+	mutex_lock(&phy_provider_mutex);
+	list_del(&phy_provider->list);
+	kfree(phy_provider);
+	mutex_unlock(&phy_provider_mutex);
+}
+EXPORT_SYMBOL_GPL(of_phy_provider_unregister);
+
+/**
+ * devm_of_phy_provider_unregister() - remove phy provider from the framework
+ * @dev: struct device of the phy provider
+ *
+ * destroys the devres associated with this phy provider and invokes
+ * of_phy_provider_unregister to unregister the phy provider.
+ */
+void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider) {
+	int r;
+
+	r = devres_destroy(dev, devm_phy_provider_release, devm_phy_match,
+		phy_provider);
+	dev_WARN_ONCE(dev, r, "couldn't find PHY provider device resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_provider_unregister);
+
+/**
+ * phy_release() - release the phy
+ * @dev: the dev member within phy
+ *
+ * When the last reference to the device is removed, it is called
+ * from the embedded kobject as release method.
+ */
+static void phy_release(struct device *dev)
+{
+	struct phy *phy;
+
+	phy = to_phy(dev);
+	dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
+	kfree(phy->label);
+	kfree(phy);
+}
+
+static int __init phy_core_init(void)
+{
+	phy_class = class_create(THIS_MODULE, "phy");
+	if (IS_ERR(phy_class)) {
+		pr_err("failed to create phy class --> %ld\n",
+			PTR_ERR(phy_class));
+		return PTR_ERR(phy_class);
+	}
+
+	phy_class->dev_release = phy_release;
+
+	return 0;
+}
+module_init(phy_core_init);
+
+static void __exit phy_core_exit(void)
+{
+	class_destroy(phy_class);
+}
+module_exit(phy_core_exit);
+
+MODULE_DESCRIPTION("Generic PHY Framework");
+MODULE_AUTHOR("Kishon Vijay Abraham I <kishon@ti.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 0000000..ae09503
--- /dev/null
+++ b/include/linux/phy/phy.h
@@ -0,0 +1,344 @@
+/*
+ * phy.h -- generic phy header file
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I <kishon@ti.com>
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __DRIVERS_PHY_H
+#define __DRIVERS_PHY_H
+
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/device.h>
+#include <linux/pm_runtime.h>
+
+struct phy;
+
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @power_on: powering on the phy
+ * @power_off: powering off the phy
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+	int	(*init)(struct phy *phy);
+	int	(*exit)(struct phy *phy);
+	int	(*power_on)(struct phy *phy);
+	int	(*power_off)(struct phy *phy);
+	struct module *owner;
+};
+
+/**
+ * struct phy - represents the phy device
+ * @dev: phy device
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+ * @label: label given to the phy
+ * @mutex: mutex to protect phy_ops
+ * @init_count: used to protect when the PHY is used by multiple consumers
+ * @power_count: used to protect when the PHY is used by multiple consumers
+ */
+struct phy {
+	struct device		dev;
+	int			id;
+	const struct phy_ops	*ops;
+	const char		*label;
+	struct mutex		mutex;
+	int			init_count;
+	int			power_count;
+};
+
+/**
+ * struct phy_provider - represents the phy provider
+ * @dev: phy provider device
+ * @owner: the module owner having of_xlate
+ * @of_xlate: function pointer to obtain phy instance from phy pointer
+ * @list: to maintain a linked list of PHY providers
+ */
+struct phy_provider {
+	struct device		*dev;
+	struct module		*owner;
+	struct list_head	list;
+	struct phy * (*of_xlate)(struct device *dev,
+		struct of_phandle_args *args);
+};
+
+#define	to_phy(dev)	(container_of((dev), struct phy, dev))
+
+#define	of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+#define	devm_of_phy_provider_register(dev, xlate)	\
+	__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+static inline void phy_set_drvdata(struct phy *phy, void *data)
+{
+	dev_set_drvdata(&phy->dev, data);
+}
+
+static inline void *phy_get_drvdata(struct phy *phy)
+{
+	return dev_get_drvdata(&phy->dev);
+}
+
+#if IS_ENABLED(CONFIG_GENERIC_PHY)
+extern struct phy *phy_get(struct device *dev, const char *string);
+extern struct phy *devm_phy_get(struct device *dev, const char *string);
+extern void phy_put(struct phy *phy);
+extern void devm_phy_put(struct device *dev, struct phy *phy);
+extern struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args);
+extern struct phy *phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label);
+extern struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label);
+extern void phy_destroy(struct phy *phy);
+extern void devm_phy_destroy(struct device *dev, struct phy *phy);
+extern struct phy_provider *__of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern struct phy_provider *__devm_of_phy_provider_register(struct device *dev,
+	struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args));
+extern void of_phy_provider_unregister(struct phy_provider *phy_provider);
+extern void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider);
+#else
+static inline struct phy *phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_get(struct device *dev, const char *string)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_put(struct phy *phy)
+{
+}
+
+static inline void devm_phy_put(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy *of_phy_simple_xlate(struct device *dev,
+	struct of_phandle_args *args)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy *devm_phy_create(struct device *dev, u8 id,
+	const struct phy_ops *ops, const char *label)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void phy_destroy(struct phy *phy)
+{
+}
+
+static inline void devm_phy_destroy(struct device *dev, struct phy *phy)
+{
+}
+
+static inline struct phy_provider *__of_phy_provider_register(
+	struct device *dev, struct module *owner, struct phy * (*of_xlate)(
+	struct device *dev, struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct phy_provider *__devm_of_phy_provider_register(struct device
+	*dev, struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+	struct of_phandle_args *args))
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline void of_phy_provider_unregister(struct phy_provider *phy_provider)
+{
+}
+
+static inline void devm_of_phy_provider_unregister(struct device *dev,
+	struct phy_provider *phy_provider)
+{
+}
+#endif
+
+static inline int phy_pm_runtime_get(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get(&phy->dev);
+}
+
+static inline int phy_pm_runtime_get_sync(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_get_sync(&phy->dev);
+}
+
+static inline int phy_pm_runtime_put(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put(&phy->dev);
+}
+
+static inline int phy_pm_runtime_put_sync(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return -EINVAL;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return -ENOTSUPP;
+
+	return pm_runtime_put_sync(&phy->dev);
+}
+
+static inline void phy_pm_runtime_allow(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_allow(&phy->dev);
+}
+
+static inline void phy_pm_runtime_forbid(struct phy *phy)
+{
+	if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
+		return;
+
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
+	pm_runtime_forbid(&phy->dev);
+}
+
+static inline int phy_init(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->init_count++ == 0 && phy->ops->init) {
+		ret = phy->ops->init(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy init failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+	int ret;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->init_count == 0 && phy->ops->exit) {
+		ret = phy->ops->exit(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy exit failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+	return ret;
+}
+
+static inline int phy_power_on(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+
+	mutex_lock(&phy->mutex);
+	if (phy->power_count++ == 0 && phy->ops->power_on) {
+		ret = phy->ops->power_on(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweron failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+
+	return ret;
+}
+
+static inline int phy_power_off(struct phy *phy)
+{
+	int ret = -ENOTSUPP;
+
+	mutex_lock(&phy->mutex);
+	if (--phy->power_count == 0 && phy->ops->power_off) {
+		ret =  phy->ops->power_off(phy);
+		if (ret < 0) {
+			dev_err(&phy->dev, "phy poweroff failed --> %d\n", ret);
+			goto out;
+		}
+	}
+
+out:
+	mutex_unlock(&phy->mutex);
+	phy_pm_runtime_put(phy);
+
+	return ret;
+}
+
+#endif /* __DRIVERS_PHY_H */
-- 
1.7.10.4

[PATCH v9 2/8] usb: phy: omap-usb2: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/phy/Kconfig         |    1 +
 drivers/usb/phy/phy-omap-usb2.c |   45 +++++++++++++++++++++++++++++++++++----
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 7ef3eb8..5caeafd 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -69,6 +69,7 @@ config OMAP_CONTROL_USB
 config OMAP_USB2
 	tristate "OMAP USB2 PHY Driver"
 	depends on ARCH_OMAP2PLUS
+	depends on GENERIC_PHY
 	select OMAP_CONTROL_USB
 	help
 	  Enable this to support the transceiver that is part of SOC. This
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 844ab68..751b30f 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/delay.h>
 #include <linux/usb/omap_control_usb.h>
+#include <linux/phy/phy.h>
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
 	return 0;
 }
 
+static int omap_usb_power_off(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 0);
+
+	return 0;
+}
+
+static int omap_usb_power_on(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 1);
+
+	return 0;
+}
+
+static struct phy_ops ops = {
+	.power_on	= omap_usb_power_on,
+	.power_off	= omap_usb_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
 	struct omap_usb			*phy;
+	struct phy			*generic_phy;
 	struct usb_otg			*otg;
+	struct phy_provider		*phy_provider;
 
 	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
 	if (!phy) {
@@ -144,6 +171,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
+	phy_provider = devm_of_phy_provider_register(phy->dev,
+			of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
 	phy->control_dev = omap_get_control_dev();
 	if (IS_ERR(phy->control_dev)) {
 		dev_dbg(&pdev->dev, "Failed to get control device\n");
@@ -159,6 +191,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	otg->start_srp		= omap_usb_start_srp;
 	otg->phy		= &phy->phy;
 
+	platform_set_drvdata(pdev, phy);
+	pm_runtime_enable(phy->dev);
+
+	generic_phy = devm_phy_create(phy->dev, 0, &ops, "omap-usb2");
+	if (IS_ERR(generic_phy))
+		return PTR_ERR(generic_phy);
+
+	phy_set_drvdata(generic_phy, phy);
+
 	phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
 	if (IS_ERR(phy->wkupclk)) {
 		dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n");
@@ -174,10 +215,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	usb_add_phy_dev(&phy->phy);
 
-	platform_set_drvdata(pdev, phy);
-
-	pm_runtime_enable(phy->dev);
-
 	return 0;
 }
 
-- 
1.7.10.4

[PATCH v9 2/8] usb: phy: omap-usb2: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/phy/Kconfig         |    1 +
 drivers/usb/phy/phy-omap-usb2.c |   45 +++++++++++++++++++++++++++++++++++----
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 7ef3eb8..5caeafd 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -69,6 +69,7 @@ config OMAP_CONTROL_USB
 config OMAP_USB2
 	tristate "OMAP USB2 PHY Driver"
 	depends on ARCH_OMAP2PLUS
+	depends on GENERIC_PHY
 	select OMAP_CONTROL_USB
 	help
 	  Enable this to support the transceiver that is part of SOC. This
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 844ab68..751b30f 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/delay.h>
 #include <linux/usb/omap_control_usb.h>
+#include <linux/phy/phy.h>
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
 	return 0;
 }
 
+static int omap_usb_power_off(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 0);
+
+	return 0;
+}
+
+static int omap_usb_power_on(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 1);
+
+	return 0;
+}
+
+static struct phy_ops ops = {
+	.power_on	= omap_usb_power_on,
+	.power_off	= omap_usb_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
 	struct omap_usb			*phy;
+	struct phy			*generic_phy;
 	struct usb_otg			*otg;
+	struct phy_provider		*phy_provider;
 
 	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
 	if (!phy) {
@@ -144,6 +171,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
+	phy_provider = devm_of_phy_provider_register(phy->dev,
+			of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
 	phy->control_dev = omap_get_control_dev();
 	if (IS_ERR(phy->control_dev)) {
 		dev_dbg(&pdev->dev, "Failed to get control device\n");
@@ -159,6 +191,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	otg->start_srp		= omap_usb_start_srp;
 	otg->phy		= &phy->phy;
 
+	platform_set_drvdata(pdev, phy);
+	pm_runtime_enable(phy->dev);
+
+	generic_phy = devm_phy_create(phy->dev, 0, &ops, "omap-usb2");
+	if (IS_ERR(generic_phy))
+		return PTR_ERR(generic_phy);
+
+	phy_set_drvdata(generic_phy, phy);
+
 	phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
 	if (IS_ERR(phy->wkupclk)) {
 		dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n");
@@ -174,10 +215,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	usb_add_phy_dev(&phy->phy);
 
-	platform_set_drvdata(pdev, phy);
-
-	pm_runtime_enable(phy->dev);
-
 	return 0;
 }
 
-- 
1.7.10.4

[PATCH v9 2/8] usb: phy: omap-usb2: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/phy/Kconfig         |    1 +
 drivers/usb/phy/phy-omap-usb2.c |   45 +++++++++++++++++++++++++++++++++++----
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 7ef3eb8..5caeafd 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -69,6 +69,7 @@ config OMAP_CONTROL_USB
 config OMAP_USB2
 	tristate "OMAP USB2 PHY Driver"
 	depends on ARCH_OMAP2PLUS
+	depends on GENERIC_PHY
 	select OMAP_CONTROL_USB
 	help
 	  Enable this to support the transceiver that is part of SOC. This
diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 844ab68..751b30f 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -28,6 +28,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/delay.h>
 #include <linux/usb/omap_control_usb.h>
+#include <linux/phy/phy.h>
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,10 +120,36 @@ static int omap_usb2_suspend(struct usb_phy *x, int suspend)
 	return 0;
 }
 
+static int omap_usb_power_off(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 0);
+
+	return 0;
+}
+
+static int omap_usb_power_on(struct phy *x)
+{
+	struct omap_usb *phy = phy_get_drvdata(x);
+
+	omap_control_usb_phy_power(phy->control_dev, 1);
+
+	return 0;
+}
+
+static struct phy_ops ops = {
+	.power_on	= omap_usb_power_on,
+	.power_off	= omap_usb_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
 	struct omap_usb			*phy;
+	struct phy			*generic_phy;
 	struct usb_otg			*otg;
+	struct phy_provider		*phy_provider;
 
 	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
 	if (!phy) {
@@ -144,6 +171,11 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
+	phy_provider = devm_of_phy_provider_register(phy->dev,
+			of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
 	phy->control_dev = omap_get_control_dev();
 	if (IS_ERR(phy->control_dev)) {
 		dev_dbg(&pdev->dev, "Failed to get control device\n");
@@ -159,6 +191,15 @@ static int omap_usb2_probe(struct platform_device *pdev)
 	otg->start_srp		= omap_usb_start_srp;
 	otg->phy		= &phy->phy;
 
+	platform_set_drvdata(pdev, phy);
+	pm_runtime_enable(phy->dev);
+
+	generic_phy = devm_phy_create(phy->dev, 0, &ops, "omap-usb2");
+	if (IS_ERR(generic_phy))
+		return PTR_ERR(generic_phy);
+
+	phy_set_drvdata(generic_phy, phy);
+
 	phy->wkupclk = devm_clk_get(phy->dev, "usb_phy_cm_clk32k");
 	if (IS_ERR(phy->wkupclk)) {
 		dev_err(&pdev->dev, "unable to get usb_phy_cm_clk32k\n");
@@ -174,10 +215,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	usb_add_phy_dev(&phy->phy);
 
-	platform_set_drvdata(pdev, phy);
-
-	pm_runtime_enable(phy->dev);
-
 	return 0;
 }
 
-- 
1.7.10.4

[PATCH v9 3/8] usb: phy: twl4030: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed.

However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 drivers/usb/phy/phy-twl4030-usb.c |   50 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8fbe2d9..437ba30 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -33,6 +33,7 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 #include <linux/usb/otg.h>
+#include <linux/phy/phy.h>
 #include <linux/usb/musb-omap.h>
 #include <linux/usb/ulpi.h>
 #include <linux/i2c/twl.h>
@@ -431,6 +432,14 @@ static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
 	dev_dbg(twl->dev, "%s\n", __func__);
 }
 
+static int twl4030_phy_power_off(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_suspend(twl, 0);
+	return 0;
+}
+
 static void __twl4030_phy_resume(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
@@ -459,6 +468,14 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 	}
 }
 
+static int twl4030_phy_power_on(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_resume(twl);
+	return 0;
+}
+
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 {
 	/* Enable writing to power configuration registers */
@@ -602,13 +619,22 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 	status = twl4030_usb_linkstat(twl);
 	twl->linkstat = status;
 
-	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
+	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
+		twl4030_phy_resume(twl);
+	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
+static int twl4030_phy_init(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	return twl4030_usb_phy_init(&twl->phy);
+}
+
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
 {
 	struct twl4030_usb *twl = phy_to_twl(x);
@@ -646,13 +672,22 @@ static int twl4030_set_host(struct usb_otg *otg, struct usb_bus *host)
 	return 0;
 }
 
+static const struct phy_ops ops = {
+	.init		= twl4030_phy_init,
+	.power_on	= twl4030_phy_power_on,
+	.power_off	= twl4030_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
 	struct twl4030_usb_data *pdata = pdev->dev.platform_data;
 	struct twl4030_usb	*twl;
+	struct phy		*phy;
 	int			status, err;
 	struct usb_otg		*otg;
 	struct device_node	*np = pdev->dev.of_node;
+	struct phy_provider	*phy_provider;
 
 	twl = devm_kzalloc(&pdev->dev, sizeof *twl, GFP_KERNEL);
 	if (!twl)
@@ -689,6 +724,19 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	otg->set_host		= twl4030_set_host;
 	otg->set_peripheral	= twl4030_set_peripheral;
 
+	phy_provider = devm_of_phy_provider_register(twl->dev,
+		of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(twl->dev, 0, &ops, "twl4030");
+	if (IS_ERR(phy)) {
+		dev_dbg(&pdev->dev, "Failed to create PHY\n");
+		return PTR_ERR(phy);
+	}
+
+	phy_set_drvdata(phy, twl);
+
 	/* init spinlock for workqueue */
 	spin_lock_init(&twl->lock);
 
-- 
1.7.10.4

[PATCH v9 3/8] usb: phy: twl4030: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed.

However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 drivers/usb/phy/phy-twl4030-usb.c |   50 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8fbe2d9..437ba30 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -33,6 +33,7 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 #include <linux/usb/otg.h>
+#include <linux/phy/phy.h>
 #include <linux/usb/musb-omap.h>
 #include <linux/usb/ulpi.h>
 #include <linux/i2c/twl.h>
@@ -431,6 +432,14 @@ static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
 	dev_dbg(twl->dev, "%s\n", __func__);
 }
 
+static int twl4030_phy_power_off(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_suspend(twl, 0);
+	return 0;
+}
+
 static void __twl4030_phy_resume(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
@@ -459,6 +468,14 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 	}
 }
 
+static int twl4030_phy_power_on(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_resume(twl);
+	return 0;
+}
+
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 {
 	/* Enable writing to power configuration registers */
@@ -602,13 +619,22 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 	status = twl4030_usb_linkstat(twl);
 	twl->linkstat = status;
 
-	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
+	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
+		twl4030_phy_resume(twl);
+	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
+static int twl4030_phy_init(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	return twl4030_usb_phy_init(&twl->phy);
+}
+
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
 {
 	struct twl4030_usb *twl = phy_to_twl(x);
@@ -646,13 +672,22 @@ static int twl4030_set_host(struct usb_otg *otg, struct usb_bus *host)
 	return 0;
 }
 
+static const struct phy_ops ops = {
+	.init		= twl4030_phy_init,
+	.power_on	= twl4030_phy_power_on,
+	.power_off	= twl4030_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
 	struct twl4030_usb_data *pdata = pdev->dev.platform_data;
 	struct twl4030_usb	*twl;
+	struct phy		*phy;
 	int			status, err;
 	struct usb_otg		*otg;
 	struct device_node	*np = pdev->dev.of_node;
+	struct phy_provider	*phy_provider;
 
 	twl = devm_kzalloc(&pdev->dev, sizeof *twl, GFP_KERNEL);
 	if (!twl)
@@ -689,6 +724,19 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	otg->set_host		= twl4030_set_host;
 	otg->set_peripheral	= twl4030_set_peripheral;
 
+	phy_provider = devm_of_phy_provider_register(twl->dev,
+		of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(twl->dev, 0, &ops, "twl4030");
+	if (IS_ERR(phy)) {
+		dev_dbg(&pdev->dev, "Failed to create PHY\n");
+		return PTR_ERR(phy);
+	}
+
+	phy_set_drvdata(phy, twl);
+
 	/* init spinlock for workqueue */
 	spin_lock_init(&twl->lock);
 
-- 
1.7.10.4

[PATCH v9 3/8] usb: phy: twl4030: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed.

However using the old usb phy library cannot be completely removed
because otg is intertwined with phy and moving to the new
framework completely will break otg. Once we have a separate otg state machine,
we can get rid of the usb phy library.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 drivers/usb/phy/phy-twl4030-usb.c |   50 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8fbe2d9..437ba30 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -33,6 +33,7 @@
 #include <linux/io.h>
 #include <linux/delay.h>
 #include <linux/usb/otg.h>
+#include <linux/phy/phy.h>
 #include <linux/usb/musb-omap.h>
 #include <linux/usb/ulpi.h>
 #include <linux/i2c/twl.h>
@@ -431,6 +432,14 @@ static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
 	dev_dbg(twl->dev, "%s\n", __func__);
 }
 
+static int twl4030_phy_power_off(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_suspend(twl, 0);
+	return 0;
+}
+
 static void __twl4030_phy_resume(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
@@ -459,6 +468,14 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 	}
 }
 
+static int twl4030_phy_power_on(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	twl4030_phy_resume(twl);
+	return 0;
+}
+
 static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 {
 	/* Enable writing to power configuration registers */
@@ -602,13 +619,22 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 	status = twl4030_usb_linkstat(twl);
 	twl->linkstat = status;
 
-	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID)
+	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
+		twl4030_phy_resume(twl);
+	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
+static int twl4030_phy_init(struct phy *phy)
+{
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
+	return twl4030_usb_phy_init(&twl->phy);
+}
+
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
 {
 	struct twl4030_usb *twl = phy_to_twl(x);
@@ -646,13 +672,22 @@ static int twl4030_set_host(struct usb_otg *otg, struct usb_bus *host)
 	return 0;
 }
 
+static const struct phy_ops ops = {
+	.init		= twl4030_phy_init,
+	.power_on	= twl4030_phy_power_on,
+	.power_off	= twl4030_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
 	struct twl4030_usb_data *pdata = pdev->dev.platform_data;
 	struct twl4030_usb	*twl;
+	struct phy		*phy;
 	int			status, err;
 	struct usb_otg		*otg;
 	struct device_node	*np = pdev->dev.of_node;
+	struct phy_provider	*phy_provider;
 
 	twl = devm_kzalloc(&pdev->dev, sizeof *twl, GFP_KERNEL);
 	if (!twl)
@@ -689,6 +724,19 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	otg->set_host		= twl4030_set_host;
 	otg->set_peripheral	= twl4030_set_peripheral;
 
+	phy_provider = devm_of_phy_provider_register(twl->dev,
+		of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		return PTR_ERR(phy_provider);
+
+	phy = devm_phy_create(twl->dev, 0, &ops, "twl4030");
+	if (IS_ERR(phy)) {
+		dev_dbg(&pdev->dev, "Failed to create PHY\n");
+		return PTR_ERR(phy);
+	}
+
+	phy_set_drvdata(phy, twl);
+
 	/* init spinlock for workqueue */
 	spin_lock_init(&twl->lock);
 
-- 
1.7.10.4

[PATCH v9 4/8] ARM: OMAP: USB: Add phy binding information

[Kishon Vijay Abraham I]

In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/usb-musb.c |    6 +++++-
 include/linux/usb/musb.h       |    3 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..284ba51 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
 	musb_plat.mode = board_data->mode;
 	musb_plat.extvbus = board_data->extvbus;
 
-	if (cpu_is_omap44xx())
+	if (cpu_is_omap44xx()) {
 		musb_plat.has_mailbox = true;
+		musb_plat.phy_label = "omap-usb2";
+	} else if (cpu_is_omap34xx()) {
+		musb_plat.phy_label = "twl4030";
+	}
 
 	if (soc_is_am35xx()) {
 		oh_name = "am35x_otg_hs";
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..596f8c8 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
 	/* for clk_get() */
 	const char	*clock;
 
+	/* phy label */
+	const char	*phy_label;
+
 	/* (HOST or OTG) switch VBUS on/off */
 	int		(*set_vbus)(struct device *dev, int is_on);
 
-- 
1.7.10.4

[PATCH v9 4/8] ARM: OMAP: USB: Add phy binding information

[Kishon Vijay Abraham I]

In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/usb-musb.c |    6 +++++-
 include/linux/usb/musb.h       |    3 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..284ba51 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
 	musb_plat.mode = board_data->mode;
 	musb_plat.extvbus = board_data->extvbus;
 
-	if (cpu_is_omap44xx())
+	if (cpu_is_omap44xx()) {
 		musb_plat.has_mailbox = true;
+		musb_plat.phy_label = "omap-usb2";
+	} else if (cpu_is_omap34xx()) {
+		musb_plat.phy_label = "twl4030";
+	}
 
 	if (soc_is_am35xx()) {
 		oh_name = "am35x_otg_hs";
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..596f8c8 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
 	/* for clk_get() */
 	const char	*clock;
 
+	/* phy label */
+	const char	*phy_label;
+
 	/* (HOST or OTG) switch VBUS on/off */
 	int		(*set_vbus)(struct device *dev, int is_on);
 
-- 
1.7.10.4

[PATCH v9 4/8] ARM: OMAP: USB: Add phy binding information

[Kishon Vijay Abraham I]

In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/usb-musb.c |    6 +++++-
 include/linux/usb/musb.h       |    3 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..284ba51 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
 	musb_plat.mode = board_data->mode;
 	musb_plat.extvbus = board_data->extvbus;
 
-	if (cpu_is_omap44xx())
+	if (cpu_is_omap44xx()) {
 		musb_plat.has_mailbox = true;
+		musb_plat.phy_label = "omap-usb2";
+	} else if (cpu_is_omap34xx()) {
+		musb_plat.phy_label = "twl4030";
+	}
 
 	if (soc_is_am35xx()) {
 		oh_name = "am35x_otg_hs";
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..596f8c8 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@ struct musb_hdrc_platform_data {
 	/* for clk_get() */
 	const char	*clock;
 
+	/* phy label */
+	const char	*phy_label;
+
 	/* (HOST or OTG) switch VBUS on/off */
 	int		(*set_vbus)(struct device *dev, int is_on);
 
-- 
1.7.10.4

[PATCH v9 5/8] ARM: dts: omap: update usb_otg_hs data

[Kishon Vijay Abraham I]

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +++++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 ++++++
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 ++
 arch/arm/boot/dts/omap3-evm.dts                    |    2 ++
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 ++
 arch/arm/boot/dts/omap4.dtsi                       |    3 +++
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 7 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f3..c0871a7 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be "50". This signifies the controller can supply upto
    100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
 	num-eps = <16>;
 	ram-bits = <12>;
 	ctrl-module = <&omap_control_usb>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
 	compatible = "ti,omap-usb2";
 	reg = <0x4a0ad080 0x58>;
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the registers
    filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy@4a084400 {
 	      <0x4a084c00 0x40>;
 	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3046d1f..023596e 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -123,6 +123,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 96d1c20..f2b8314 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -69,6 +69,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index a626c50..b65916e 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -74,6 +74,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..dae620b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -517,6 +517,7 @@
 				compatible = "ti,omap-usb2";
 				reg = <0x4a0ad080 0x58>;
 				ctrl-module = <&omap_control_usb>;
+				#phy-cells = <0>;
 			};
 		};
 
@@ -655,6 +656,8 @@
 			interrupt-names = "mc", "dma";
 			ti,hwmods = "usb_otg_hs";
 			usb-phy = <&usb2_phy>;
+			phys = <&usb2_phy>;
+			phy-names = "usb2-phy";
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..ce4cd6f 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -80,6 +80,7 @@
 		usb1v8-supply = <&vusb1v8>;
 		usb3v1-supply = <&vusb3v1>;
 		usb_mode = <1>;
+		#phy-cells = <0>;
 	};
 
 	twl_pwm: pwm {
-- 
1.7.10.4

[PATCH v9 5/8] ARM: dts: omap: update usb_otg_hs data

[Kishon Vijay Abraham I]

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +++++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 ++++++
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 ++
 arch/arm/boot/dts/omap3-evm.dts                    |    2 ++
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 ++
 arch/arm/boot/dts/omap4.dtsi                       |    3 +++
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 7 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f3..c0871a7 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be "50". This signifies the controller can supply upto
    100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
 	num-eps = <16>;
 	ram-bits = <12>;
 	ctrl-module = <&omap_control_usb>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
 	compatible = "ti,omap-usb2";
 	reg = <0x4a0ad080 0x58>;
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the registers
    filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy@4a084400 {
 	      <0x4a084c00 0x40>;
 	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3046d1f..023596e 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -123,6 +123,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 96d1c20..f2b8314 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -69,6 +69,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index a626c50..b65916e 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -74,6 +74,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..dae620b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -517,6 +517,7 @@
 				compatible = "ti,omap-usb2";
 				reg = <0x4a0ad080 0x58>;
 				ctrl-module = <&omap_control_usb>;
+				#phy-cells = <0>;
 			};
 		};
 
@@ -655,6 +656,8 @@
 			interrupt-names = "mc", "dma";
 			ti,hwmods = "usb_otg_hs";
 			usb-phy = <&usb2_phy>;
+			phys = <&usb2_phy>;
+			phy-names = "usb2-phy";
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..ce4cd6f 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -80,6 +80,7 @@
 		usb1v8-supply = <&vusb1v8>;
 		usb3v1-supply = <&vusb3v1>;
 		usb_mode = <1>;
+		#phy-cells = <0>;
 	};
 
 	twl_pwm: pwm {
-- 
1.7.10.4

[PATCH v9 5/8] ARM: dts: omap: update usb_otg_hs data

[Kishon Vijay Abraham I]

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +++++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 ++++++
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 ++
 arch/arm/boot/dts/omap3-evm.dts                    |    2 ++
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 ++
 arch/arm/boot/dts/omap4.dtsi                       |    3 +++
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 7 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f3..c0871a7 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be "50". This signifies the controller can supply upto
    100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs at 4a0ab000 {
 	num-eps = <16>;
 	ram-bits = <12>;
 	ctrl-module = <&omap_control_usb>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy at 4a0ad080 {
 	compatible = "ti,omap-usb2";
 	reg = <0x4a0ad080 0x58>;
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the registers
    filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy at 4a084400 {
 	      <0x4a084c00 0x40>;
 	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3046d1f..023596e 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -123,6 +123,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 96d1c20..f2b8314 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -69,6 +69,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index a626c50..b65916e 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -74,6 +74,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..dae620b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -517,6 +517,7 @@
 				compatible = "ti,omap-usb2";
 				reg = <0x4a0ad080 0x58>;
 				ctrl-module = <&omap_control_usb>;
+				#phy-cells = <0>;
 			};
 		};
 
@@ -655,6 +656,8 @@
 			interrupt-names = "mc", "dma";
 			ti,hwmods = "usb_otg_hs";
 			usb-phy = <&usb2_phy>;
+			phys = <&usb2_phy>;
+			phy-names = "usb2-phy";
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..ce4cd6f 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -80,6 +80,7 @@
 		usb1v8-supply = <&vusb1v8>;
 		usb3v1-supply = <&vusb3v1>;
 		usb_mode = <1>;
+		#phy-cells = <0>;
 	};
 
 	twl_pwm: pwm {
-- 
1.7.10.4

[PATCH v9 6/8] usb: musb: omap2430: use the new generic PHY framework

[Kishon Vijay Abraham I]

Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/musb/Kconfig     |    1 +
 drivers/usb/musb/musb_core.c |    1 +
 drivers/usb/musb/musb_core.h |    3 +++
 drivers/usb/musb/omap2430.c  |   26 ++++++++++++++++++++------
 4 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 06f8d29..6ef595a 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -47,6 +47,7 @@ config USB_MUSB_TUSB6010
 config USB_MUSB_OMAP2PLUS
 	tristate "OMAP2430 and onwards"
 	depends on ARCH_OMAP2PLUS
+	depends on GENERIC_PHY
 
 config USB_MUSB_AM35X
 	tristate "AM35x"
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 37a261a..f732bcc 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1864,6 +1864,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 	musb->board_set_power = plat->set_power;
 	musb->min_power = plat->min_power;
 	musb->ops = plat->platform_ops;
+	musb->phy_label = plat->phy_label;
 
 	/* The musb_platform_init() call:
 	 *   - adjusts musb->mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..498ae21 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include <linux/usb.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/musb.h>
+#include <linux/phy/phy.h>
 
 struct musb;
 struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
 	u16			int_tx;
 
 	struct usb_phy		*xceiv;
+	struct phy		*phy;
 
 	int nIrq;
 	unsigned		irq_wake:1;
@@ -434,6 +436,7 @@ struct musb {
 	unsigned                double_buffer_not_ok:1;
 
 	struct musb_hdrc_config	*config;
+	const char		*phy_label;
 
 #ifdef MUSB_CONFIG_PROC_FS
 	struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 628b93f..12b94da 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,11 +348,21 @@ static int omap2430_musb_init(struct musb *musb)
 	 * up through ULPI.  TWL4030-family PMICs include one,
 	 * which needs a driver, drivers aren't always needed.
 	 */
-	if (dev->parent->of_node)
+	if (dev->parent->of_node) {
+		musb->phy = devm_phy_get(dev->parent, "usb2-phy");
+
+		/* We can't totally remove musb->xceiv as of now because
+		 * musb core uses xceiv.state and xceiv.otg. Once we have
+		 * a separate state machine to handle otg, these can be moved
+		 * out of xceiv and then we can start using the generic PHY
+		 * framework
+		 */
 		musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
 		    "usb-phy", 0);
-	else
+	} else {
 		musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+		musb->phy = devm_phy_get(dev, musb->phy_label);
+	}
 
 	if (IS_ERR(musb->xceiv)) {
 		status = PTR_ERR(musb->xceiv);
@@ -364,6 +374,10 @@ static int omap2430_musb_init(struct musb *musb)
 		return -EPROBE_DEFER;
 	}
 
+	if (IS_ERR(musb->phy)) {
+		pr_err("HS USB OTG: no PHY configured\n");
+		return PTR_ERR(musb->phy);
+	}
 	musb->isr = omap2430_musb_interrupt;
 
 	status = pm_runtime_get_sync(dev);
@@ -397,7 +411,7 @@ static int omap2430_musb_init(struct musb *musb)
 	if (glue->status != OMAP_MUSB_UNKNOWN)
 		omap_musb_set_mailbox(glue);
 
-	usb_phy_init(musb->xceiv);
+	phy_init(musb->phy);
 
 	pm_runtime_put_noidle(musb->controller);
 	return 0;
@@ -460,6 +474,7 @@ static int omap2430_musb_exit(struct musb *musb)
 	del_timer_sync(&musb_idle_timer);
 
 	omap2430_low_level_exit(musb);
+	phy_exit(musb->phy);
 
 	return 0;
 }
@@ -619,7 +634,7 @@ static int omap2430_runtime_suspend(struct device *dev)
 				OTG_INTERFSEL);
 
 		omap2430_low_level_exit(musb);
-		usb_phy_set_suspend(musb->xceiv, 1);
+		phy_power_off(musb->phy);
 	}
 
 	return 0;
@@ -634,8 +649,7 @@ static int omap2430_runtime_resume(struct device *dev)
 		omap2430_low_level_init(musb);
 		musb_writel(musb->mregs, OTG_INTERFSEL,
 				musb->context.otg_interfsel);
-
-		usb_phy_set_suspend(musb->xceiv, 0);
+		phy_power_on(musb->phy);
 	}
 
 	return 0;
-- 
1.7.10.4

[PATCH v9 6/8] usb: musb: omap2430: use the new generic PHY framework

[Kishon Vijay Abraham I]

Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/musb/Kconfig     |    1 +
 drivers/usb/musb/musb_core.c |    1 +
 drivers/usb/musb/musb_core.h |    3 +++
 drivers/usb/musb/omap2430.c  |   26 ++++++++++++++++++++------
 4 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 06f8d29..6ef595a 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -47,6 +47,7 @@ config USB_MUSB_TUSB6010
 config USB_MUSB_OMAP2PLUS
 	tristate "OMAP2430 and onwards"
 	depends on ARCH_OMAP2PLUS
+	depends on GENERIC_PHY
 
 config USB_MUSB_AM35X
 	tristate "AM35x"
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 37a261a..f732bcc 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1864,6 +1864,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 	musb->board_set_power = plat->set_power;
 	musb->min_power = plat->min_power;
 	musb->ops = plat->platform_ops;
+	musb->phy_label = plat->phy_label;
 
 	/* The musb_platform_init() call:
 	 *   - adjusts musb->mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..498ae21 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include <linux/usb.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/musb.h>
+#include <linux/phy/phy.h>
 
 struct musb;
 struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
 	u16			int_tx;
 
 	struct usb_phy		*xceiv;
+	struct phy		*phy;
 
 	int nIrq;
 	unsigned		irq_wake:1;
@@ -434,6 +436,7 @@ struct musb {
 	unsigned                double_buffer_not_ok:1;
 
 	struct musb_hdrc_config	*config;
+	const char		*phy_label;
 
 #ifdef MUSB_CONFIG_PROC_FS
 	struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 628b93f..12b94da 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,11 +348,21 @@ static int omap2430_musb_init(struct musb *musb)
 	 * up through ULPI.  TWL4030-family PMICs include one,
 	 * which needs a driver, drivers aren't always needed.
 	 */
-	if (dev->parent->of_node)
+	if (dev->parent->of_node) {
+		musb->phy = devm_phy_get(dev->parent, "usb2-phy");
+
+		/* We can't totally remove musb->xceiv as of now because
+		 * musb core uses xceiv.state and xceiv.otg. Once we have
+		 * a separate state machine to handle otg, these can be moved
+		 * out of xceiv and then we can start using the generic PHY
+		 * framework
+		 */
 		musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
 		    "usb-phy", 0);
-	else
+	} else {
 		musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+		musb->phy = devm_phy_get(dev, musb->phy_label);
+	}
 
 	if (IS_ERR(musb->xceiv)) {
 		status = PTR_ERR(musb->xceiv);
@@ -364,6 +374,10 @@ static int omap2430_musb_init(struct musb *musb)
 		return -EPROBE_DEFER;
 	}
 
+	if (IS_ERR(musb->phy)) {
+		pr_err("HS USB OTG: no PHY configured\n");
+		return PTR_ERR(musb->phy);
+	}
 	musb->isr = omap2430_musb_interrupt;
 
 	status = pm_runtime_get_sync(dev);
@@ -397,7 +411,7 @@ static int omap2430_musb_init(struct musb *musb)
 	if (glue->status != OMAP_MUSB_UNKNOWN)
 		omap_musb_set_mailbox(glue);
 
-	usb_phy_init(musb->xceiv);
+	phy_init(musb->phy);
 
 	pm_runtime_put_noidle(musb->controller);
 	return 0;
@@ -460,6 +474,7 @@ static int omap2430_musb_exit(struct musb *musb)
 	del_timer_sync(&musb_idle_timer);
 
 	omap2430_low_level_exit(musb);
+	phy_exit(musb->phy);
 
 	return 0;
 }
@@ -619,7 +634,7 @@ static int omap2430_runtime_suspend(struct device *dev)
 				OTG_INTERFSEL);
 
 		omap2430_low_level_exit(musb);
-		usb_phy_set_suspend(musb->xceiv, 1);
+		phy_power_off(musb->phy);
 	}
 
 	return 0;
@@ -634,8 +649,7 @@ static int omap2430_runtime_resume(struct device *dev)
 		omap2430_low_level_init(musb);
 		musb_writel(musb->mregs, OTG_INTERFSEL,
 				musb->context.otg_interfsel);
-
-		usb_phy_set_suspend(musb->xceiv, 0);
+		phy_power_on(musb->phy);
 	}
 
 	return 0;
-- 
1.7.10.4

[PATCH v9 6/8] usb: musb: omap2430: use the new generic PHY framework

[Kishon Vijay Abraham I]

Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/musb/Kconfig     |    1 +
 drivers/usb/musb/musb_core.c |    1 +
 drivers/usb/musb/musb_core.h |    3 +++
 drivers/usb/musb/omap2430.c  |   26 ++++++++++++++++++++------
 4 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 06f8d29..6ef595a 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -47,6 +47,7 @@ config USB_MUSB_TUSB6010
 config USB_MUSB_OMAP2PLUS
 	tristate "OMAP2430 and onwards"
 	depends on ARCH_OMAP2PLUS
+	depends on GENERIC_PHY
 
 config USB_MUSB_AM35X
 	tristate "AM35x"
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 37a261a..f732bcc 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1864,6 +1864,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 	musb->board_set_power = plat->set_power;
 	musb->min_power = plat->min_power;
 	musb->ops = plat->platform_ops;
+	musb->phy_label = plat->phy_label;
 
 	/* The musb_platform_init() call:
 	 *   - adjusts musb->mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..498ae21 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include <linux/usb.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/musb.h>
+#include <linux/phy/phy.h>
 
 struct musb;
 struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
 	u16			int_tx;
 
 	struct usb_phy		*xceiv;
+	struct phy		*phy;
 
 	int nIrq;
 	unsigned		irq_wake:1;
@@ -434,6 +436,7 @@ struct musb {
 	unsigned                double_buffer_not_ok:1;
 
 	struct musb_hdrc_config	*config;
+	const char		*phy_label;
 
 #ifdef MUSB_CONFIG_PROC_FS
 	struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 628b93f..12b94da 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,11 +348,21 @@ static int omap2430_musb_init(struct musb *musb)
 	 * up through ULPI.  TWL4030-family PMICs include one,
 	 * which needs a driver, drivers aren't always needed.
 	 */
-	if (dev->parent->of_node)
+	if (dev->parent->of_node) {
+		musb->phy = devm_phy_get(dev->parent, "usb2-phy");
+
+		/* We can't totally remove musb->xceiv as of now because
+		 * musb core uses xceiv.state and xceiv.otg. Once we have
+		 * a separate state machine to handle otg, these can be moved
+		 * out of xceiv and then we can start using the generic PHY
+		 * framework
+		 */
 		musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
 		    "usb-phy", 0);
-	else
+	} else {
 		musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+		musb->phy = devm_phy_get(dev, musb->phy_label);
+	}
 
 	if (IS_ERR(musb->xceiv)) {
 		status = PTR_ERR(musb->xceiv);
@@ -364,6 +374,10 @@ static int omap2430_musb_init(struct musb *musb)
 		return -EPROBE_DEFER;
 	}
 
+	if (IS_ERR(musb->phy)) {
+		pr_err("HS USB OTG: no PHY configured\n");
+		return PTR_ERR(musb->phy);
+	}
 	musb->isr = omap2430_musb_interrupt;
 
 	status = pm_runtime_get_sync(dev);
@@ -397,7 +411,7 @@ static int omap2430_musb_init(struct musb *musb)
 	if (glue->status != OMAP_MUSB_UNKNOWN)
 		omap_musb_set_mailbox(glue);
 
-	usb_phy_init(musb->xceiv);
+	phy_init(musb->phy);
 
 	pm_runtime_put_noidle(musb->controller);
 	return 0;
@@ -460,6 +474,7 @@ static int omap2430_musb_exit(struct musb *musb)
 	del_timer_sync(&musb_idle_timer);
 
 	omap2430_low_level_exit(musb);
+	phy_exit(musb->phy);
 
 	return 0;
 }
@@ -619,7 +634,7 @@ static int omap2430_runtime_suspend(struct device *dev)
 				OTG_INTERFSEL);
 
 		omap2430_low_level_exit(musb);
-		usb_phy_set_suspend(musb->xceiv, 1);
+		phy_power_off(musb->phy);
 	}
 
 	return 0;
@@ -634,8 +649,7 @@ static int omap2430_runtime_resume(struct device *dev)
 		omap2430_low_level_init(musb);
 		musb_writel(musb->mregs, OTG_INTERFSEL,
 				musb->context.otg_interfsel);
-
-		usb_phy_set_suspend(musb->xceiv, 0);
+		phy_power_on(musb->phy);
 	}
 
 	return 0;
-- 
1.7.10.4

[PATCH v9 7/8] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2

[Kishon Vijay Abraham I]

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 drivers/usb/phy/phy-omap-usb2.c |   25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 751b30f..3f2b125 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
 	return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-	u32 ret;
-	struct omap_usb *phy = phy_to_omapusb(x);
-
-	if (suspend && !phy->is_suspended) {
-		omap_control_usb_phy_power(phy->control_dev, 0);
-		pm_runtime_put_sync(phy->dev);
-		phy->is_suspended = 1;
-	} else if (!suspend && phy->is_suspended) {
-		ret = pm_runtime_get_sync(phy->dev);
-		if (ret < 0) {
-			dev_err(phy->dev, "get_sync failed with err %d\n",
-									ret);
-			return ret;
-		}
-		omap_control_usb_phy_power(phy->control_dev, 1);
-		phy->is_suspended = 0;
-	}
-
-	return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
 	struct omap_usb *phy = phy_get_drvdata(x);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	phy->phy.dev		= phy->dev;
 	phy->phy.label		= "omap-usb2";
-	phy->phy.set_suspend	= omap_usb2_suspend;
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
@@ -182,7 +158,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	phy->is_suspended	= 1;
 	omap_control_usb_phy_power(phy->control_dev, 0);
 
 	otg->set_host		= omap_usb_set_host;
-- 
1.7.10.4

[PATCH v9 7/8] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2

[Kishon Vijay Abraham I]

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 drivers/usb/phy/phy-omap-usb2.c |   25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 751b30f..3f2b125 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
 	return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-	u32 ret;
-	struct omap_usb *phy = phy_to_omapusb(x);
-
-	if (suspend && !phy->is_suspended) {
-		omap_control_usb_phy_power(phy->control_dev, 0);
-		pm_runtime_put_sync(phy->dev);
-		phy->is_suspended = 1;
-	} else if (!suspend && phy->is_suspended) {
-		ret = pm_runtime_get_sync(phy->dev);
-		if (ret < 0) {
-			dev_err(phy->dev, "get_sync failed with err %d\n",
-									ret);
-			return ret;
-		}
-		omap_control_usb_phy_power(phy->control_dev, 1);
-		phy->is_suspended = 0;
-	}
-
-	return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
 	struct omap_usb *phy = phy_get_drvdata(x);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	phy->phy.dev		= phy->dev;
 	phy->phy.label		= "omap-usb2";
-	phy->phy.set_suspend	= omap_usb2_suspend;
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
@@ -182,7 +158,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	phy->is_suspended	= 1;
 	omap_control_usb_phy_power(phy->control_dev, 0);
 
 	otg->set_host		= omap_usb_set_host;
-- 
1.7.10.4

[PATCH v9 7/8] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2

[Kishon Vijay Abraham I]

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 drivers/usb/phy/phy-omap-usb2.c |   25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/drivers/usb/phy/phy-omap-usb2.c b/drivers/usb/phy/phy-omap-usb2.c
index 751b30f..3f2b125 100644
--- a/drivers/usb/phy/phy-omap-usb2.c
+++ b/drivers/usb/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
 	return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-	u32 ret;
-	struct omap_usb *phy = phy_to_omapusb(x);
-
-	if (suspend && !phy->is_suspended) {
-		omap_control_usb_phy_power(phy->control_dev, 0);
-		pm_runtime_put_sync(phy->dev);
-		phy->is_suspended = 1;
-	} else if (!suspend && phy->is_suspended) {
-		ret = pm_runtime_get_sync(phy->dev);
-		if (ret < 0) {
-			dev_err(phy->dev, "get_sync failed with err %d\n",
-									ret);
-			return ret;
-		}
-		omap_control_usb_phy_power(phy->control_dev, 1);
-		phy->is_suspended = 0;
-	}
-
-	return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
 	struct omap_usb *phy = phy_get_drvdata(x);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	phy->phy.dev		= phy->dev;
 	phy->phy.label		= "omap-usb2";
-	phy->phy.set_suspend	= omap_usb2_suspend;
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
@@ -182,7 +158,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	phy->is_suspended	= 1;
 	omap_control_usb_phy_power(phy->control_dev, 0);
 
 	otg->set_host		= omap_usb_set_host;
-- 
1.7.10.4

[PATCH v9 8/8] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

[Kishon Vijay Abraham I]

Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 drivers/usb/phy/phy-twl4030-usb.c |   57 +++++++++----------------------------
 1 file changed, 13 insertions(+), 44 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 437ba30..2148e2b 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int on)
 	}
 }
 
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (twl->asleep)
-		return;
+		return 0;
 
 	twl4030_phy_power(twl, 0);
 	twl->asleep = 1;
 	dev_dbg(twl->dev, "%s\n", __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_suspend(twl, 0);
 	return 0;
 }
 
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
 	twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
 		twl4030_i2c_access(twl, 0);
 }
 
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (!twl->asleep)
-		return;
-	__twl4030_phy_resume(twl);
+		return 0;
+	__twl4030_phy_power_on(twl);
 	twl->asleep = 0;
 	dev_dbg(twl->dev, "%s\n", __func__);
 
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 		cancel_delayed_work(&twl->id_workaround_work);
 		schedule_delayed_work(&twl->id_workaround_work, HZ);
 	}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_resume(twl);
 	return 0;
 }
 
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct *work)
 	}
 }
 
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
 {
-	struct twl4030_usb *twl = phy_to_twl(phy);
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
 	enum omap_musb_vbus_id_status status;
 
 	/*
@@ -621,32 +611,13 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 
 	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
-		twl4030_phy_resume(twl);
+		twl4030_phy_power_on(phy);
 	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
-static int twl4030_phy_init(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	return twl4030_usb_phy_init(&twl->phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
-	struct twl4030_usb *twl = phy_to_twl(x);
-
-	if (suspend)
-		twl4030_phy_suspend(twl, 1);
-	else
-		twl4030_phy_resume(twl);
-
-	return 0;
-}
-
 static int twl4030_set_peripheral(struct usb_otg *otg,
 					struct usb_gadget *gadget)
 {
@@ -717,8 +688,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	twl->phy.label		= "twl4030";
 	twl->phy.otg		= otg;
 	twl->phy.type		= USB_PHY_TYPE_USB2;
-	twl->phy.set_suspend	= twl4030_set_suspend;
-	twl->phy.init		= twl4030_usb_phy_init;
 
 	otg->phy		= &twl->phy;
 	otg->set_host		= twl4030_set_host;
-- 
1.7.10.4

[PATCH v9 8/8] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

[Kishon Vijay Abraham I]

Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 drivers/usb/phy/phy-twl4030-usb.c |   57 +++++++++----------------------------
 1 file changed, 13 insertions(+), 44 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 437ba30..2148e2b 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int on)
 	}
 }
 
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (twl->asleep)
-		return;
+		return 0;
 
 	twl4030_phy_power(twl, 0);
 	twl->asleep = 1;
 	dev_dbg(twl->dev, "%s\n", __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_suspend(twl, 0);
 	return 0;
 }
 
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
 	twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
 		twl4030_i2c_access(twl, 0);
 }
 
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (!twl->asleep)
-		return;
-	__twl4030_phy_resume(twl);
+		return 0;
+	__twl4030_phy_power_on(twl);
 	twl->asleep = 0;
 	dev_dbg(twl->dev, "%s\n", __func__);
 
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 		cancel_delayed_work(&twl->id_workaround_work);
 		schedule_delayed_work(&twl->id_workaround_work, HZ);
 	}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_resume(twl);
 	return 0;
 }
 
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct *work)
 	}
 }
 
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
 {
-	struct twl4030_usb *twl = phy_to_twl(phy);
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
 	enum omap_musb_vbus_id_status status;
 
 	/*
@@ -621,32 +611,13 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 
 	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
-		twl4030_phy_resume(twl);
+		twl4030_phy_power_on(phy);
 	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
-static int twl4030_phy_init(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	return twl4030_usb_phy_init(&twl->phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
-	struct twl4030_usb *twl = phy_to_twl(x);
-
-	if (suspend)
-		twl4030_phy_suspend(twl, 1);
-	else
-		twl4030_phy_resume(twl);
-
-	return 0;
-}
-
 static int twl4030_set_peripheral(struct usb_otg *otg,
 					struct usb_gadget *gadget)
 {
@@ -717,8 +688,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	twl->phy.label		= "twl4030";
 	twl->phy.otg		= otg;
 	twl->phy.type		= USB_PHY_TYPE_USB2;
-	twl->phy.set_suspend	= twl4030_set_suspend;
-	twl->phy.init		= twl4030_usb_phy_init;
 
 	otg->phy		= &twl->phy;
 	otg->set_host		= twl4030_set_host;
-- 
1.7.10.4

[PATCH v9 8/8] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops

[Kishon Vijay Abraham I]

Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 drivers/usb/phy/phy-twl4030-usb.c |   57 +++++++++----------------------------
 1 file changed, 13 insertions(+), 44 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 437ba30..2148e2b 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int on)
 	}
 }
 
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (twl->asleep)
-		return;
+		return 0;
 
 	twl4030_phy_power(twl, 0);
 	twl->asleep = 1;
 	dev_dbg(twl->dev, "%s\n", __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_suspend(twl, 0);
 	return 0;
 }
 
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
 	twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
 		twl4030_i2c_access(twl, 0);
 }
 
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (!twl->asleep)
-		return;
-	__twl4030_phy_resume(twl);
+		return 0;
+	__twl4030_phy_power_on(twl);
 	twl->asleep = 0;
 	dev_dbg(twl->dev, "%s\n", __func__);
 
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 		cancel_delayed_work(&twl->id_workaround_work);
 		schedule_delayed_work(&twl->id_workaround_work, HZ);
 	}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_resume(twl);
 	return 0;
 }
 
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct *work)
 	}
 }
 
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
 {
-	struct twl4030_usb *twl = phy_to_twl(phy);
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
 	enum omap_musb_vbus_id_status status;
 
 	/*
@@ -621,32 +611,13 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 
 	if (status == OMAP_MUSB_ID_GROUND || status == OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
-		twl4030_phy_resume(twl);
+		twl4030_phy_power_on(phy);
 	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
-static int twl4030_phy_init(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	return twl4030_usb_phy_init(&twl->phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
-	struct twl4030_usb *twl = phy_to_twl(x);
-
-	if (suspend)
-		twl4030_phy_suspend(twl, 1);
-	else
-		twl4030_phy_resume(twl);
-
-	return 0;
-}
-
 static int twl4030_set_peripheral(struct usb_otg *otg,
 					struct usb_gadget *gadget)
 {
@@ -717,8 +688,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	twl->phy.label		= "twl4030";
 	twl->phy.otg		= otg;
 	twl->phy.type		= USB_PHY_TYPE_USB2;
-	twl->phy.set_suspend	= twl4030_set_suspend;
-	twl->phy.init		= twl4030_usb_phy_init;
 
 	otg->phy		= &twl->phy;
 	otg->set_host		= twl4030_set_host;
-- 
1.7.10.4

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
> The PHY framework 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. For dt-boot, the PHY drivers should
> also register *PHY provider* with the framework.
> 
> PHY drivers should create the PHY by passing id and ops like init, exit,
> power_on and power_off. This framework is also pm runtime enabled.
> 
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for dt binding can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

looks great to my eyes

Acked-by: Felipe Balbi <balbi@ti.com>

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
> The PHY framework 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. For dt-boot, the PHY drivers should
> also register *PHY provider* with the framework.
> 
> PHY drivers should create the PHY by passing id and ops like init, exit,
> power_on and power_off. This framework is also pm runtime enabled.
> 
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for dt binding can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

looks great to my eyes

Acked-by: Felipe Balbi <balbi@ti.com>

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH v9 1/8] drivers: phy: add generic PHY framework

[Felipe Balbi]

On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
> The PHY framework 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. For dt-boot, the PHY drivers should
> also register *PHY provider* with the framework.
> 
> PHY drivers should create the PHY by passing id and ops like init, exit,
> power_on and power_off. This framework is also pm runtime enabled.
> 
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for dt binding can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

looks great to my eyes

Acked-by: Felipe Balbi <balbi@ti.com>

-- 
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/20130626/47aed22b/attachment.sig>

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

[Patel, Satish]

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.

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

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

[Patel, Satish]

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.

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

[PATCH v9 0/8] Generic PHY Framework

[Patel, Satish]

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.

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

Re: [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-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 “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

[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

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

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 5019 bytes --]

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 “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.

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v9 0/8] Generic PHY Framework

[Felipe Balbi]

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.

-- 
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/20130703/9388d732/attachment.sig>

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

[Kishon Vijay Abraham I]

Hi,

On Wednesday 03 July 2013 06:50 PM, Felipe Balbi wrote:
> 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.

true. But it's certainly going to be difficult to map certain function
specific ops to the generic ops (just like ATR and ADPU in smart card
case or set pixel for hdmi).

Thanks
Kishon
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v9 0/8] Generic PHY Framework

[Kishon Vijay Abraham I]

Hi,

On Wednesday 03 July 2013 06:50 PM, Felipe Balbi wrote:
> 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.

true. But it's certainly going to be difficult to map certain function
specific ops to the generic ops (just like ATR and ADPU in smart card
case or set pixel for hdmi).

Thanks
Kishon

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

[Patel, Satish]

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,
		....
	};

- Also, can have similar interface phy_getconfig to know current phy state.



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

[PATCH v9 0/8] Generic PHY Framework

[Patel, Satish]

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,
		....
	};

- Also, can have similar interface phy_getconfig to know current phy state.



> --
> balbi

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

[Kishon Vijay Abraham I]

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

[PATCH v9 0/8] Generic PHY Framework

[Kishon Vijay Abraham I]

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

-Kishon

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

[Patel, Satish]

Hi,

> -----Original Message-----
> From: ABRAHAM, KISHON VIJAY
> Sent: Thursday, July 04, 2013 3:26 PM
> To: Patel, Satish
> Cc: Balbi, Felipe; grant.likely@linaro.org; tony@atomide.com;
> 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; Mankad, Maulik Ojas
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> 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
> 
what are your inputs to adapt multiple phys into generic phy f/w ?

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

[PATCH v9 0/8] Generic PHY Framework

[Patel, Satish]

Hi,

> -----Original Message-----
> From: ABRAHAM, KISHON VIJAY
> Sent: Thursday, July 04, 2013 3:26 PM
> To: Patel, Satish
> Cc: Balbi, Felipe; grant.likely at linaro.org; tony at atomide.com;
> 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; Mankad, Maulik Ojas
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> 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
> 
what are your inputs to adapt multiple phys into generic phy f/w ?

> -Kishon

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

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 8098 bytes --]

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 “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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v9 0/8] Generic PHY Framework

[Felipe Balbi]

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>

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

[Patel, Satish]

Hi,

> -----Original Message-----
> From: Balbi, Felipe
> Sent: Thursday, July 04, 2013 3:42 PM
> To: ABRAHAM, KISHON VIJAY
> Cc: Patel, Satish; Balbi, Felipe; grant.likely@linaro.org;
> tony@atomide.com; 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; Mankad, Maulik Ojas
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> 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@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
> 
> +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).
> 

This will required study of capabilities of available phys.
Only point of consideration is  - list should not gets exhausted to cover all 
phy capabilities

> But adding something which can handle "anything" like
> phy_set_config(),
> it's the same as adding use-case specific ops.
> 
> --
> balbi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 0/8] Generic PHY Framework

[Patel, Satish]

Hi,

> -----Original Message-----
> From: Balbi, Felipe
> Sent: Thursday, July 04, 2013 3:42 PM
> To: ABRAHAM, KISHON VIJAY
> Cc: Patel, Satish; Balbi, Felipe; grant.likely at linaro.org;
> tony at atomide.com; 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; Mankad, Maulik Ojas
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> 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).
> 

This will required study of capabilities of available phys.
Only point of consideration is  - list should not gets exhausted to cover all 
phy capabilities

> But adding something which can handle "anything" like
> phy_set_config(),
> it's the same as adding use-case specific ops.
> 
> --
> balbi

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

[Patel, Satish]

Hi,


> -----Original Message-----
> From: Balbi, Felipe
> Sent: Thursday, July 04, 2013 3:42 PM
> To: ABRAHAM, KISHON VIJAY
> Cc: Patel, Satish; Balbi, Felipe; grant.likely@linaro.org;
> tony@atomide.com; 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; Mankad, Maulik Ojas
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> 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@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
> 
> +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.
> 

We have two options over here

Option 1: 

Defining generic api to which can be mapped over multiple phys
For smartcard case, I have can thought of following mapping with new 
generic apis as suggested.

Smartcard_poweron -> power_on
Smartcard_powerdown -> power_off
Smartcard_set_voltage -> phy_set_voltage
Smartcard_activate_card -> phy_activate_slot
Smartcard_deactivate_card -> phy_deactivate_slot
Smartcard_set_c4/c8/rst/io -> phy_set_pin
Smartcard_warm_reset -> phy_warmreset
Smartcard_set_clkdiv -> phy_set_clock
Smartcard_get_clkdiv -> phy_get_clock
Smartcard_set_atr_mute_timeout -> ??
Smartcard_set_atr_early_timeout -> ??	
Smartcard_get_isr_status -> phy_get_status
Smartcard_get_version -> phy_get_version


- Pros:
	- smartcard phy can make use of generic phy f/w
- cons:
	- does not confirm whether above APIs will capable of including requirements
	  of other available phys
	- list might gets extended for other phys like ethernet, sensor phy etc.
	- any change in single api needs to validated for all existing phy which has
	  bind to generic f/w 
	
Option 2:
We can have set/get config or generic ops kind of implementation

- pros:
	- all phy can be pluged-in to this f/w. The word "generic phy" will be justified
	- no cost of maintaining or defining apis for unknown phy capabilities at present

- cons:
	- factor of getting abused by community.

My recommendation is to see the problem as generic logical level rather than thinking what 
already exits and what cannot be repeated - because interface looks like user space or kernel
space communication.

Where we should make our call ??

-
satish

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

[PATCH v9 0/8] Generic PHY Framework

[Patel, Satish]

Hi,


> -----Original Message-----
> From: Balbi, Felipe
> Sent: Thursday, July 04, 2013 3:42 PM
> To: ABRAHAM, KISHON VIJAY
> Cc: Patel, Satish; Balbi, Felipe; grant.likely at linaro.org;
> tony at atomide.com; 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; Mankad, Maulik Ojas
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> 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.
> 

We have two options over here

Option 1: 

Defining generic api to which can be mapped over multiple phys
For smartcard case, I have can thought of following mapping with new 
generic apis as suggested.

Smartcard_poweron -> power_on
Smartcard_powerdown -> power_off
Smartcard_set_voltage -> phy_set_voltage
Smartcard_activate_card -> phy_activate_slot
Smartcard_deactivate_card -> phy_deactivate_slot
Smartcard_set_c4/c8/rst/io -> phy_set_pin
Smartcard_warm_reset -> phy_warmreset
Smartcard_set_clkdiv -> phy_set_clock
Smartcard_get_clkdiv -> phy_get_clock
Smartcard_set_atr_mute_timeout -> ??
Smartcard_set_atr_early_timeout -> ??	
Smartcard_get_isr_status -> phy_get_status
Smartcard_get_version -> phy_get_version


- Pros:
	- smartcard phy can make use of generic phy f/w
- cons:
	- does not confirm whether above APIs will capable of including requirements
	  of other available phys
	- list might gets extended for other phys like ethernet, sensor phy etc.
	- any change in single api needs to validated for all existing phy which has
	  bind to generic f/w 
	
Option 2:
We can have set/get config or generic ops kind of implementation

- pros:
	- all phy can be pluged-in to this f/w. The word "generic phy" will be justified
	- no cost of maintaining or defining apis for unknown phy capabilities at present

- cons:
	- factor of getting abused by community.

My recommendation is to see the problem as generic logical level rather than thinking what 
already exits and what cannot be repeated - because interface looks like user space or kernel
space communication.

Where we should make our call ??

-
satish

> --
> balbi

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

[Kishon Vijay Abraham I]

Hi,

On Monday 08 July 2013 04:54 PM, Patel, Satish wrote:
> Hi,
>
>
>> -----Original Message-----
>> From: Balbi, Felipe
>> Sent: Thursday, July 04, 2013 3:42 PM
>> To: ABRAHAM, KISHON VIJAY
>> Cc: Patel, Satish; Balbi, Felipe; grant.likely@linaro.org;
>> tony@atomide.com; 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; Mankad, Maulik Ojas
>> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
>>
>> 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@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
>>
>> +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.
>>
>
> We have two options over here
>
> Option 1:
>
> Defining generic api to which can be mapped over multiple phys
> For smartcard case, I have can thought of following mapping with new
> generic apis as suggested.
>
> Smartcard_poweron -> power_on
> Smartcard_powerdown -> power_off
> Smartcard_set_voltage -> phy_set_voltage
> Smartcard_activate_card -> phy_activate_slot
> Smartcard_deactivate_card -> phy_deactivate_slot

how is activate/deactivate different from poweron/poweroff in this
use case?
> Smartcard_set_c4/c8/rst/io -> phy_set_pin

Whats should be exactly done here? Looks to me like it should be
part of init. Does these pin settings need to be changed dynamically?
> Smartcard_warm_reset -> phy_warmreset

Again looks to me like it should be part of init.
> Smartcard_set_clkdiv -> phy_set_clock
> Smartcard_get_clkdiv -> phy_get_clock

Why would the smartcard give clock to the PHY? Shouldn't the driver
of the PHY driver be doing that by itself?

> Smartcard_set_atr_mute_timeout -> ??
> Smartcard_set_atr_early_timeout -> ??	
> Smartcard_get_isr_status -> phy_get_status

Why? Is it like the detection of an external event? Then the PHY
driver should use *extcon* for event detection and passing.

> Smartcard_get_version -> phy_get_version

Again why? Why would the smartcard need the version of the PHY?

Thanks
Kishon
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v9 0/8] Generic PHY Framework

[Kishon Vijay Abraham I]

Hi,

On Monday 08 July 2013 04:54 PM, Patel, Satish wrote:
> Hi,
>
>
>> -----Original Message-----
>> From: Balbi, Felipe
>> Sent: Thursday, July 04, 2013 3:42 PM
>> To: ABRAHAM, KISHON VIJAY
>> Cc: Patel, Satish; Balbi, Felipe; grant.likely at linaro.org;
>> tony at atomide.com; 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; Mankad, Maulik Ojas
>> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
>>
>> 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.
>>
>
> We have two options over here
>
> Option 1:
>
> Defining generic api to which can be mapped over multiple phys
> For smartcard case, I have can thought of following mapping with new
> generic apis as suggested.
>
> Smartcard_poweron -> power_on
> Smartcard_powerdown -> power_off
> Smartcard_set_voltage -> phy_set_voltage
> Smartcard_activate_card -> phy_activate_slot
> Smartcard_deactivate_card -> phy_deactivate_slot

how is activate/deactivate different from poweron/poweroff in this
use case?
> Smartcard_set_c4/c8/rst/io -> phy_set_pin

Whats should be exactly done here? Looks to me like it should be
part of init. Does these pin settings need to be changed dynamically?
> Smartcard_warm_reset -> phy_warmreset

Again looks to me like it should be part of init.
> Smartcard_set_clkdiv -> phy_set_clock
> Smartcard_get_clkdiv -> phy_get_clock

Why would the smartcard give clock to the PHY? Shouldn't the driver
of the PHY driver be doing that by itself?

> Smartcard_set_atr_mute_timeout -> ??
> Smartcard_set_atr_early_timeout -> ??	
> Smartcard_get_isr_status -> phy_get_status

Why? Is it like the detection of an external event? Then the PHY
driver should use *extcon* for event detection and passing.

> Smartcard_get_version -> phy_get_version

Again why? Why would the smartcard need the version of the PHY?

Thanks
Kishon

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

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 1465 bytes --]

Hi,

On Mon, Jul 08, 2013 at 01:24:49PM +0200, Patel, Satish wrote:

[ big snip ]

> We have two options over here
> 
> Option 1: 
> 
> Defining generic api to which can be mapped over multiple phys
> For smartcard case, I have can thought of following mapping with new 
> generic apis as suggested.
> 
> Smartcard_poweron -> power_on
> Smartcard_powerdown -> power_off
> Smartcard_set_voltage -> phy_set_voltage

these three are generic enough

> Smartcard_activate_card -> phy_activate_slot
> Smartcard_deactivate_card -> phy_deactivate_slot

this looks unnecessary, why can't you always activate the card when you
phy_poweron ?

> Smartcard_set_c4/c8/rst/io -> phy_set_pin

why do you want to control each pin separately ? looks like something we
don't want to allow, in order to prevent users fiddling with the HW
directly.

> Smartcard_warm_reset -> phy_warmreset

phy_reset()

> Smartcard_set_clkdiv -> phy_set_clock
> Smartcard_get_clkdiv -> phy_get_clock

why do you need to control the clock like that ? That should be
something in the clock framework and, hey, it already exists:

clk_set_rate()
clk_get_rate()

> Smartcard_set_atr_mute_timeout -> ??
> Smartcard_set_atr_early_timeout -> ??	
> Smartcard_get_isr_status -> phy_get_status
> Smartcard_get_version -> phy_get_version

these look unnecessary. Why does any other entity need to know about the
PHY version and Interrupt status ?

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v9 0/8] Generic PHY Framework

[Felipe Balbi]

Hi,

On Mon, Jul 08, 2013 at 01:24:49PM +0200, Patel, Satish wrote:

[ big snip ]

> We have two options over here
> 
> Option 1: 
> 
> Defining generic api to which can be mapped over multiple phys
> For smartcard case, I have can thought of following mapping with new 
> generic apis as suggested.
> 
> Smartcard_poweron -> power_on
> Smartcard_powerdown -> power_off
> Smartcard_set_voltage -> phy_set_voltage

these three are generic enough

> Smartcard_activate_card -> phy_activate_slot
> Smartcard_deactivate_card -> phy_deactivate_slot

this looks unnecessary, why can't you always activate the card when you
phy_poweron ?

> Smartcard_set_c4/c8/rst/io -> phy_set_pin

why do you want to control each pin separately ? looks like something we
don't want to allow, in order to prevent users fiddling with the HW
directly.

> Smartcard_warm_reset -> phy_warmreset

phy_reset()

> Smartcard_set_clkdiv -> phy_set_clock
> Smartcard_get_clkdiv -> phy_get_clock

why do you need to control the clock like that ? That should be
something in the clock framework and, hey, it already exists:

clk_set_rate()
clk_get_rate()

> Smartcard_set_atr_mute_timeout -> ??
> Smartcard_set_atr_early_timeout -> ??	
> Smartcard_get_isr_status -> phy_get_status
> Smartcard_get_version -> phy_get_version

these look unnecessary. Why does any other entity need to know about the
PHY version and Interrupt status ?

-- 
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/20130708/f80e2ded/attachment.sig>

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

[Patel, Satish]

Hi,

> -----Original Message-----
> From: ABRAHAM, KISHON VIJAY
> Sent: Monday, July 08, 2013 5:47 PM
> To: Patel, Satish
> Cc: Balbi, Felipe; grant.likely@linaro.org; tony@atomide.com;
> 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; Mankad, Maulik Ojas; Srinivasan, Nageswari; Sundareson,
> Prabindh
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> Hi,
> 
> On Monday 08 July 2013 04:54 PM, Patel, Satish wrote:
> > Hi,
> >
> >
> >> -----Original Message-----
> >> From: Balbi, Felipe
> >> Sent: Thursday, July 04, 2013 3:42 PM
> >> To: ABRAHAM, KISHON VIJAY
> >> Cc: Patel, Satish; Balbi, Felipe; grant.likely@linaro.org;
> >> tony@atomide.com; 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; Mankad, Maulik Ojas
> >> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> >>
> >> 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@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
> >>
> >> +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.
> >>
> >
> > We have two options over here
> >
> > Option 1:
> >
> > Defining generic api to which can be mapped over multiple phys
> > For smartcard case, I have can thought of following mapping with new
> > generic apis as suggested.
> >
> > Smartcard_poweron -> power_on
> > Smartcard_powerdown -> power_off
> > Smartcard_set_voltage -> phy_set_voltage
> > Smartcard_activate_card -> phy_activate_slot
> > Smartcard_deactivate_card -> phy_deactivate_slot
> 
> how is activate/deactivate different from poweron/poweroff in this
> use case?

power on/off normal power sequence. While activate/de-activate will be 
called during card transaction.

Brief on how it works:
- when system start, execute power on for phy
- smartcard controller and phy is connected through i2c, clock lines and 
i/o lines
- clock will be supplied by controller to phy to get data sync on i/o lines

Operation:
 
Once the card gets inserted into the slot, user application can initiate
activate sequence anytime, it is not mandatory that activation has to be called
Immediately. It all depends whether other connections ( network, printer) are proper.
User application can do some checks and then dynamically activate the card

There are 2 sequence of activation - normal activation and warm reset. If first
fails then warm reset should be executed, if card does not response to both then
deactivation will be carried out

- For activation there are some timing parameters ( called ATR - Answer to reset timings)
Has to be set to the phy

- on activation card will respond with some initial characters (ATR), which will be verified
by application, in case of error user application will de-activate the card not the phy module

- After activation, use application initiate normal tx/rx

- Once tx/rx is done, it will initiate deactivation of card not the phy module.


> > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> 
> Whats should be exactly done here? Looks to me like it should be
> part of init. Does these pin settings need to be changed dynamically?

These are all phy pins which will be physically come in contact with smart card 
When inserted. In case of synchronous card, these pins will be toggled manually
by s/w bit bang algorithm


> > Smartcard_warm_reset -> phy_warmreset
>
Explained above.
 
> Again looks to me like it should be part of init.
> > Smartcard_set_clkdiv -> phy_set_clock
> > Smartcard_get_clkdiv -> phy_get_clock
> 
> Why would the smartcard give clock to the PHY? Shouldn't the driver
> of the PHY driver be doing that by itself?
> 
Source of clock to the  phy is from smart card controller

> > Smartcard_set_atr_mute_timeout -> ??
> > Smartcard_set_atr_early_timeout -> ??
> > Smartcard_get_isr_status -> phy_get_status
> 

ATR timeout parameter has to be configured for activation. This will
differ for various smart card segments.

> Why? Is it like the detection of an external event? Then the PHY
> driver should use *extcon* for event detection and passing.
>

Smartcard controller need a way to ready isr status ( like card presence,
Card inserted in to which slot, removed from which slot ) to maintain its
Internal state machine.
 
> > Smartcard_get_version -> phy_get_version
> 
> Again why? Why would the smartcard need the version of the PHY?
> 

Can be omitted. This is for the test suite reference.
> Thanks
> Kishon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 0/8] Generic PHY Framework

[Patel, Satish]

Hi,

> -----Original Message-----
> From: ABRAHAM, KISHON VIJAY
> Sent: Monday, July 08, 2013 5:47 PM
> To: Patel, Satish
> Cc: Balbi, Felipe; grant.likely at linaro.org; tony at atomide.com;
> 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; Mankad, Maulik Ojas; Srinivasan, Nageswari; Sundareson,
> Prabindh
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> Hi,
> 
> On Monday 08 July 2013 04:54 PM, Patel, Satish wrote:
> > Hi,
> >
> >
> >> -----Original Message-----
> >> From: Balbi, Felipe
> >> Sent: Thursday, July 04, 2013 3:42 PM
> >> To: ABRAHAM, KISHON VIJAY
> >> Cc: Patel, Satish; Balbi, Felipe; grant.likely at linaro.org;
> >> tony at atomide.com; 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; Mankad, Maulik Ojas
> >> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> >>
> >> 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.
> >>
> >
> > We have two options over here
> >
> > Option 1:
> >
> > Defining generic api to which can be mapped over multiple phys
> > For smartcard case, I have can thought of following mapping with new
> > generic apis as suggested.
> >
> > Smartcard_poweron -> power_on
> > Smartcard_powerdown -> power_off
> > Smartcard_set_voltage -> phy_set_voltage
> > Smartcard_activate_card -> phy_activate_slot
> > Smartcard_deactivate_card -> phy_deactivate_slot
> 
> how is activate/deactivate different from poweron/poweroff in this
> use case?

power on/off normal power sequence. While activate/de-activate will be 
called during card transaction.

Brief on how it works:
- when system start, execute power on for phy
- smartcard controller and phy is connected through i2c, clock lines and 
i/o lines
- clock will be supplied by controller to phy to get data sync on i/o lines

Operation:
 
Once the card gets inserted into the slot, user application can initiate
activate sequence anytime, it is not mandatory that activation has to be called
Immediately. It all depends whether other connections ( network, printer) are proper.
User application can do some checks and then dynamically activate the card

There are 2 sequence of activation - normal activation and warm reset. If first
fails then warm reset should be executed, if card does not response to both then
deactivation will be carried out

- For activation there are some timing parameters ( called ATR - Answer to reset timings)
Has to be set to the phy

- on activation card will respond with some initial characters (ATR), which will be verified
by application, in case of error user application will de-activate the card not the phy module

- After activation, use application initiate normal tx/rx

- Once tx/rx is done, it will initiate deactivation of card not the phy module.


> > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> 
> Whats should be exactly done here? Looks to me like it should be
> part of init. Does these pin settings need to be changed dynamically?

These are all phy pins which will be physically come in contact with smart card 
When inserted. In case of synchronous card, these pins will be toggled manually
by s/w bit bang algorithm


> > Smartcard_warm_reset -> phy_warmreset
>
Explained above.
 
> Again looks to me like it should be part of init.
> > Smartcard_set_clkdiv -> phy_set_clock
> > Smartcard_get_clkdiv -> phy_get_clock
> 
> Why would the smartcard give clock to the PHY? Shouldn't the driver
> of the PHY driver be doing that by itself?
> 
Source of clock to the  phy is from smart card controller

> > Smartcard_set_atr_mute_timeout -> ??
> > Smartcard_set_atr_early_timeout -> ??
> > Smartcard_get_isr_status -> phy_get_status
> 

ATR timeout parameter has to be configured for activation. This will
differ for various smart card segments.

> Why? Is it like the detection of an external event? Then the PHY
> driver should use *extcon* for event detection and passing.
>

Smartcard controller need a way to ready isr status ( like card presence,
Card inserted in to which slot, removed from which slot ) to maintain its
Internal state machine.
 
> > Smartcard_get_version -> phy_get_version
> 
> Again why? Why would the smartcard need the version of the PHY?
> 

Can be omitted. This is for the test suite reference.
> Thanks
> Kishon

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

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 3992 bytes --]

Hi,

On Tue, Jul 09, 2013 at 04:23:29AM +0200, Patel, Satish wrote:
> > > We have two options over here
> > >
> > > Option 1:
> > >
> > > Defining generic api to which can be mapped over multiple phys
> > > For smartcard case, I have can thought of following mapping with new
> > > generic apis as suggested.
> > >
> > > Smartcard_poweron -> power_on
> > > Smartcard_powerdown -> power_off
> > > Smartcard_set_voltage -> phy_set_voltage
> > > Smartcard_activate_card -> phy_activate_slot
> > > Smartcard_deactivate_card -> phy_deactivate_slot
> > 
> > how is activate/deactivate different from poweron/poweroff in this
> > use case?
> 
> power on/off normal power sequence. While activate/de-activate will be 
> called during card transaction.

why can't you implement activate/deactivate with suspend/resume ?

> Brief on how it works:
> - when system start, execute power on for phy
> - smartcard controller and phy is connected through i2c, clock lines and 
> i/o lines
> - clock will be supplied by controller to phy to get data sync on i/o lines

fair enough.

> Operation:
>
> Once the card gets inserted into the slot, user application can
> initiate activate sequence anytime, it is not mandatory that
> activation has to be called Immediately. It all depends whether other
> connections ( network, printer) are proper.  User application can do
> some checks and then dynamically activate the card

The card or the phy ? Who actually activates ? Is the activation
handling part of the PHY or part of the smartcard controller ?

> There are 2 sequence of activation - normal activation and warm reset.
> If first fails then warm reset should be executed, if card does not
> response to both then deactivation will be carried out

ret = phy_resume(phy);
if (ret == -EINVAL) { /* perhaps there's a better error code */
	ret = phy_reset(phy);
	if (ret)
		phy_suspend(phy);
}

????

> - For activation there are some timing parameters ( called ATR -
> Answer to reset timings) Has to be set to the phy

does that change in runtime or is it something which is set during probe
and never touched again ?

> - on activation card will respond with some initial characters (ATR),
> which will be verified by application, in case of error user
> application will de-activate the card not the phy module
> 
> - After activation, use application initiate normal tx/rx
> 
> - Once tx/rx is done, it will initiate deactivation of card not the
> phy module.

then that has nothing to do with the PHY framework, right ?

> > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > 
> > Whats should be exactly done here? Looks to me like it should be
> > part of init. Does these pin settings need to be changed dynamically?
> 
> These are all phy pins which will be physically come in contact with
> smart card When inserted. In case of synchronous card, these pins will
> be toggled manually by s/w bit bang algorithm

is that a requirement or just something that everybody does ?

In any case, you can hide that under some gpio calls, or something
similar.

> > Why? Is it like the detection of an external event? Then the PHY
> > driver should use *extcon* for event detection and passing.
> >
> 
> Smartcard controller need a way to ready isr status ( like card presence,
> Card inserted in to which slot, removed from which slot ) to maintain its
> Internal state machine.

register an interrupt handler with devm_request_threaded_irq(), what's
the problem ?

> > > Smartcard_get_version -> phy_get_version
> > 
> > Again why? Why would the smartcard need the version of the PHY?
> > 
> 
> Can be omitted. This is for the test suite reference.

if it's for testsuite, it sounds like something that should be done
through userland and, as such, should be implemented by a set of debugfs
files which expose the necessary information. That has nothing to do
with the PHY framework.

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

[PATCH v9 0/8] Generic PHY Framework

[Felipe Balbi]

Hi,

On Tue, Jul 09, 2013 at 04:23:29AM +0200, Patel, Satish wrote:
> > > We have two options over here
> > >
> > > Option 1:
> > >
> > > Defining generic api to which can be mapped over multiple phys
> > > For smartcard case, I have can thought of following mapping with new
> > > generic apis as suggested.
> > >
> > > Smartcard_poweron -> power_on
> > > Smartcard_powerdown -> power_off
> > > Smartcard_set_voltage -> phy_set_voltage
> > > Smartcard_activate_card -> phy_activate_slot
> > > Smartcard_deactivate_card -> phy_deactivate_slot
> > 
> > how is activate/deactivate different from poweron/poweroff in this
> > use case?
> 
> power on/off normal power sequence. While activate/de-activate will be 
> called during card transaction.

why can't you implement activate/deactivate with suspend/resume ?

> Brief on how it works:
> - when system start, execute power on for phy
> - smartcard controller and phy is connected through i2c, clock lines and 
> i/o lines
> - clock will be supplied by controller to phy to get data sync on i/o lines

fair enough.

> Operation:
>
> Once the card gets inserted into the slot, user application can
> initiate activate sequence anytime, it is not mandatory that
> activation has to be called Immediately. It all depends whether other
> connections ( network, printer) are proper.  User application can do
> some checks and then dynamically activate the card

The card or the phy ? Who actually activates ? Is the activation
handling part of the PHY or part of the smartcard controller ?

> There are 2 sequence of activation - normal activation and warm reset.
> If first fails then warm reset should be executed, if card does not
> response to both then deactivation will be carried out

ret = phy_resume(phy);
if (ret == -EINVAL) { /* perhaps there's a better error code */
	ret = phy_reset(phy);
	if (ret)
		phy_suspend(phy);
}

????

> - For activation there are some timing parameters ( called ATR -
> Answer to reset timings) Has to be set to the phy

does that change in runtime or is it something which is set during probe
and never touched again ?

> - on activation card will respond with some initial characters (ATR),
> which will be verified by application, in case of error user
> application will de-activate the card not the phy module
> 
> - After activation, use application initiate normal tx/rx
> 
> - Once tx/rx is done, it will initiate deactivation of card not the
> phy module.

then that has nothing to do with the PHY framework, right ?

> > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > 
> > Whats should be exactly done here? Looks to me like it should be
> > part of init. Does these pin settings need to be changed dynamically?
> 
> These are all phy pins which will be physically come in contact with
> smart card When inserted. In case of synchronous card, these pins will
> be toggled manually by s/w bit bang algorithm

is that a requirement or just something that everybody does ?

In any case, you can hide that under some gpio calls, or something
similar.

> > Why? Is it like the detection of an external event? Then the PHY
> > driver should use *extcon* for event detection and passing.
> >
> 
> Smartcard controller need a way to ready isr status ( like card presence,
> Card inserted in to which slot, removed from which slot ) to maintain its
> Internal state machine.

register an interrupt handler with devm_request_threaded_irq(), what's
the problem ?

> > > Smartcard_get_version -> phy_get_version
> > 
> > Again why? Why would the smartcard need the version of the PHY?
> > 
> 
> Can be omitted. This is for the test suite reference.

if it's for testsuite, it sounds like something that should be done
through userland and, as such, should be implemented by a set of debugfs
files which expose the necessary information. That has nothing to do
with the PHY framework.

-- 
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/20130709/b8472db6/attachment-0001.sig>

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

[Patel, Satish]

Hi,

> -----Original Message-----
> From: Balbi, Felipe
> Sent: Tuesday, July 09, 2013 5:14 PM
> To: Patel, Satish
> Cc: ABRAHAM, KISHON VIJAY; Balbi, Felipe; grant.likely@linaro.org;
> tony@atomide.com; 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; Mankad, Maulik Ojas;
> Srinivasan, Nageswari; Sundareson, Prabindh
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> Hi,
> 
> On Tue, Jul 09, 2013 at 04:23:29AM +0200, Patel, Satish wrote:
> > > > We have two options over here
> > > >
> > > > Option 1:
> > > >
> > > > Defining generic api to which can be mapped over multiple phys
> > > > For smartcard case, I have can thought of following mapping with
> new
> > > > generic apis as suggested.
> > > >
> > > > Smartcard_poweron -> power_on
> > > > Smartcard_powerdown -> power_off
> > > > Smartcard_set_voltage -> phy_set_voltage
> > > > Smartcard_activate_card -> phy_activate_slot
> > > > Smartcard_deactivate_card -> phy_deactivate_slot
> > >
> > > how is activate/deactivate different from poweron/poweroff in this
> > > use case?
> >
> > power on/off normal power sequence. While activate/de-activate will
> be
> > called during card transaction.
> 
> why can't you implement activate/deactivate with suspend/resume ?
> 
> > Brief on how it works:
> > - when system start, execute power on for phy
> > - smartcard controller and phy is connected through i2c, clock lines
> and
> > i/o lines
> > - clock will be supplied by controller to phy to get data sync on
> i/o lines
> 
> fair enough.
> 
> > Operation:
> >
> > Once the card gets inserted into the slot, user application can
> > initiate activate sequence anytime, it is not mandatory that
> > activation has to be called Immediately. It all depends whether
> other
> > connections ( network, printer) are proper.  User application can do
> > some checks and then dynamically activate the card
> 
> The card or the phy ? Who actually activates ? Is the activation
> handling part of the PHY or part of the smartcard controller ?
> 

It’s a activation of smart card which is inserted into the phy slot. 
Smart card activation will by done phy but initiated by user application
Handling of activation should be done at both the side - controller as well
As phy. Phy will raise certain signals and check timeout while activation
, while controller will store data coming from smart card to FIFO. Its
Controller which will give command to phy to initiate activation sequence when it
is ready. 

Which means, both controller and phy has role to play while activation.
Also it is applicable while deactivation.


> > There are 2 sequence of activation - normal activation and warm
> reset.
> > If first fails then warm reset should be executed, if card does not
> > response to both then deactivation will be carried out
> 
> ret = phy_resume(phy);
> if (ret == -EINVAL) { /* perhaps there's a better error code */
> 	ret = phy_reset(phy);
> 	if (ret)
> 		phy_suspend(phy);
> }
>

Its not like this. There are the cases, when during normal activation card respond
With some characters, but they might not be valid or error prone - This check will be 
done by user application as only application knows how to decode characters as per protocol.

It there is any error in characters/timeout paratmeters, user application will ask to initiate
Warm reset.
 
> ????
> 
> > - For activation there are some timing parameters ( called ATR -
> > Answer to reset timings) Has to be set to the phy
> 
> does that change in runtime or is it something which is set during
> probe
> and never touched again ?
> 
> > - on activation card will respond with some initial characters
> (ATR),
> > which will be verified by application, in case of error user
> > application will de-activate the card not the phy module
> >
> > - After activation, use application initiate normal tx/rx
> >
> > - Once tx/rx is done, it will initiate deactivation of card not the
> > phy module.
> 
> then that has nothing to do with the PHY framework, right ?

But all such sequence will be initiated by PHY by raising certain signals
and only controller can give the push when to start.
> 
> > > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > >
> > > Whats should be exactly done here? Looks to me like it should be
> > > part of init. Does these pin settings need to be changed
> dynamically?
> >
> > These are all phy pins which will be physically come in contact with
> > smart card When inserted. In case of synchronous card, these pins
> will
> > be toggled manually by s/w bit bang algorithm
> 
> is that a requirement or just something that everybody does ?
>

Its requirement for synchronous card. At present there is no open driver
Which does this thing.
 
> In any case, you can hide that under some gpio calls, or something
> similar.

Can't be done using GPIO as pin can be toggled only which i2c read/write
to the phy.
> 
> > > Why? Is it like the detection of an external event? Then the PHY
> > > driver should use *extcon* for event detection and passing.
> > >
> >
> > Smartcard controller need a way to ready isr status ( like card
> presence,
> > Card inserted in to which slot, removed from which slot ) to
> maintain its
> > Internal state machine.
> 
> register an interrupt handler with devm_request_threaded_irq(), what's
> the problem ?
> 
> > > > Smartcard_get_version -> phy_get_version
> > >
> > > Again why? Why would the smartcard need the version of the PHY?
> > >
> >
> > Can be omitted. This is for the test suite reference.
> 
> if it's for testsuite, it sounds like something that should be done
> through userland and, as such, should be implemented by a set of
> debugfs
> files which expose the necessary information. That has nothing to do
> with the PHY framework.
> 
Agree.. can be omitted.


I am ok to give internal webex presentation (TI team) to brief 
on phy and smart card controller interface.


> --
> balbi

[PATCH v9 0/8] Generic PHY Framework

[Patel, Satish]

Hi,

> -----Original Message-----
> From: Balbi, Felipe
> Sent: Tuesday, July 09, 2013 5:14 PM
> To: Patel, Satish
> Cc: ABRAHAM, KISHON VIJAY; Balbi, Felipe; grant.likely at linaro.org;
> tony at atomide.com; 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; Mankad, Maulik Ojas;
> Srinivasan, Nageswari; Sundareson, Prabindh
> Subject: Re: [PATCH v9 0/8] Generic PHY Framework
> 
> Hi,
> 
> On Tue, Jul 09, 2013 at 04:23:29AM +0200, Patel, Satish wrote:
> > > > We have two options over here
> > > >
> > > > Option 1:
> > > >
> > > > Defining generic api to which can be mapped over multiple phys
> > > > For smartcard case, I have can thought of following mapping with
> new
> > > > generic apis as suggested.
> > > >
> > > > Smartcard_poweron -> power_on
> > > > Smartcard_powerdown -> power_off
> > > > Smartcard_set_voltage -> phy_set_voltage
> > > > Smartcard_activate_card -> phy_activate_slot
> > > > Smartcard_deactivate_card -> phy_deactivate_slot
> > >
> > > how is activate/deactivate different from poweron/poweroff in this
> > > use case?
> >
> > power on/off normal power sequence. While activate/de-activate will
> be
> > called during card transaction.
> 
> why can't you implement activate/deactivate with suspend/resume ?
> 
> > Brief on how it works:
> > - when system start, execute power on for phy
> > - smartcard controller and phy is connected through i2c, clock lines
> and
> > i/o lines
> > - clock will be supplied by controller to phy to get data sync on
> i/o lines
> 
> fair enough.
> 
> > Operation:
> >
> > Once the card gets inserted into the slot, user application can
> > initiate activate sequence anytime, it is not mandatory that
> > activation has to be called Immediately. It all depends whether
> other
> > connections ( network, printer) are proper.  User application can do
> > some checks and then dynamically activate the card
> 
> The card or the phy ? Who actually activates ? Is the activation
> handling part of the PHY or part of the smartcard controller ?
> 

It?s a activation of smart card which is inserted into the phy slot. 
Smart card activation will by done phy but initiated by user application
Handling of activation should be done at both the side - controller as well
As phy. Phy will raise certain signals and check timeout while activation
, while controller will store data coming from smart card to FIFO. Its
Controller which will give command to phy to initiate activation sequence when it
is ready. 

Which means, both controller and phy has role to play while activation.
Also it is applicable while deactivation.


> > There are 2 sequence of activation - normal activation and warm
> reset.
> > If first fails then warm reset should be executed, if card does not
> > response to both then deactivation will be carried out
> 
> ret = phy_resume(phy);
> if (ret == -EINVAL) { /* perhaps there's a better error code */
> 	ret = phy_reset(phy);
> 	if (ret)
> 		phy_suspend(phy);
> }
>

Its not like this. There are the cases, when during normal activation card respond
With some characters, but they might not be valid or error prone - This check will be 
done by user application as only application knows how to decode characters as per protocol.

It there is any error in characters/timeout paratmeters, user application will ask to initiate
Warm reset.
 
> ????
> 
> > - For activation there are some timing parameters ( called ATR -
> > Answer to reset timings) Has to be set to the phy
> 
> does that change in runtime or is it something which is set during
> probe
> and never touched again ?
> 
> > - on activation card will respond with some initial characters
> (ATR),
> > which will be verified by application, in case of error user
> > application will de-activate the card not the phy module
> >
> > - After activation, use application initiate normal tx/rx
> >
> > - Once tx/rx is done, it will initiate deactivation of card not the
> > phy module.
> 
> then that has nothing to do with the PHY framework, right ?

But all such sequence will be initiated by PHY by raising certain signals
and only controller can give the push when to start.
> 
> > > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > >
> > > Whats should be exactly done here? Looks to me like it should be
> > > part of init. Does these pin settings need to be changed
> dynamically?
> >
> > These are all phy pins which will be physically come in contact with
> > smart card When inserted. In case of synchronous card, these pins
> will
> > be toggled manually by s/w bit bang algorithm
> 
> is that a requirement or just something that everybody does ?
>

Its requirement for synchronous card. At present there is no open driver
Which does this thing.
 
> In any case, you can hide that under some gpio calls, or something
> similar.

Can't be done using GPIO as pin can be toggled only which i2c read/write
to the phy.
> 
> > > Why? Is it like the detection of an external event? Then the PHY
> > > driver should use *extcon* for event detection and passing.
> > >
> >
> > Smartcard controller need a way to ready isr status ( like card
> presence,
> > Card inserted in to which slot, removed from which slot ) to
> maintain its
> > Internal state machine.
> 
> register an interrupt handler with devm_request_threaded_irq(), what's
> the problem ?
> 
> > > > Smartcard_get_version -> phy_get_version
> > >
> > > Again why? Why would the smartcard need the version of the PHY?
> > >
> >
> > Can be omitted. This is for the test suite reference.
> 
> if it's for testsuite, it sounds like something that should be done
> through userland and, as such, should be implemented by a set of
> debugfs
> files which expose the necessary information. That has nothing to do
> with the PHY framework.
> 
Agree.. can be omitted.


I am ok to give internal webex presentation (TI team) to brief 
on phy and smart card controller interface.


> --
> balbi

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

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 6547 bytes --]

Hi,

On Tue, Jul 09, 2013 at 02:33:58PM +0200, Patel, Satish wrote:
> > > Operation:
> > >
> > > Once the card gets inserted into the slot, user application can
> > > initiate activate sequence anytime, it is not mandatory that
> > > activation has to be called Immediately. It all depends whether
> > other
> > > connections ( network, printer) are proper.  User application can do
> > > some checks and then dynamically activate the card
> > 
> > The card or the phy ? Who actually activates ? Is the activation
> > handling part of the PHY or part of the smartcard controller ?
> > 
> 
> It’s a activation of smart card which is inserted into the phy slot. 
> Smart card activation will by done phy but initiated by user application
> Handling of activation should be done at both the side - controller as well
> As phy. Phy will raise certain signals and check timeout while activation
> , while controller will store data coming from smart card to FIFO. Its
> Controller which will give command to phy to initiate activation sequence when it
> is ready. 
> 
> Which means, both controller and phy has role to play while activation.
> Also it is applicable while deactivation.

right, so when the smartcard device is opened, you want to powerup the
PHY, powerup the smartcard controller and get things going, which means
that all your activation logic can, and should, be hidden by
phy_power_on() and phy_power_off()

Perhaps you also want to delay phy_init() and phy_shutdown() to that
very time, which would mean that we wouldn't even need
phy_power_{on,off}() calls whatsoever.

> > > There are 2 sequence of activation - normal activation and warm
> > reset.
> > > If first fails then warm reset should be executed, if card does not
> > > response to both then deactivation will be carried out
> > 
> > ret = phy_resume(phy);
> > if (ret == -EINVAL) { /* perhaps there's a better error code */
> > 	ret = phy_reset(phy);
> > 	if (ret)
> > 		phy_suspend(phy);
> > }
> >
> 
> Its not like this. There are the cases, when during normal activation
> card respond With some characters, but they might not be valid or
> error prone - This check will be done by user application as only
> application knows how to decode characters as per protocol.

sure, and if the characters are invalid, the application needs to tell
the kernel, perhaps it would be enough to send and IOCTL or, even
easier, close the device and reopen it.

> It there is any error in characters/timeout paratmeters, user
> application will ask to initiate Warm reset.

and for that we can use an IOCTL which is implemented by smart card
layer. I mean, I'm assuming the smartcard would be seen as a char dev by
userland so it would be something like this:

ret = read(fd, buf, SIZE);
if (ret < 0)
	boom();

ret = process_buffer(buf, ret);
if (ret == -EINVAL) { /* we have received invalid characters */
	ret = ioctl(fd, IOCTL_SMARTCARD_WARM_RESET);
	if (ret < 0)
		handle_error();
}

in kernel space we would have an ioctl handler like so:

static int smart_card_ioctl(struct file *fd, unsigned code, usigned long v)
{
	struct smart_card *sc = fd->private_data;
	unsigned long flags;
	int ret;

	spin_lock_irqsave(&sc->lock, flags);
	switch (v)
	case SMART_CARD_WARM_RESET:
		ret = phy_shutdown(sc->phy);
		if (ret < 0)
			boom();

		ret = smart_card_reset(sc);
		if (ret < 0)
			boom();

		ret = phy_init(sc->phy);
		if (ret < 0)
			boom();
		break;
	[ ... ]
	}

	spin_unlock_irqrestore(&sc->lock, flags);

	return ret;
}

see, we don't need to add a bunch of stuff in the PHY framework, because
you shouldn't expose the PHY directly to userland. You *must* have an
abstraction to userland with an in-kernel usage of the PHY layer.

> > > - on activation card will respond with some initial characters
> > (ATR),
> > > which will be verified by application, in case of error user
> > > application will de-activate the card not the phy module
> > >
> > > - After activation, use application initiate normal tx/rx
> > >
> > > - Once tx/rx is done, it will initiate deactivation of card not the
> > > phy module.
> > 
> > then that has nothing to do with the PHY framework, right ?
> 
> But all such sequence will be initiated by PHY by raising certain
> signals and only controller can give the push when to start.

sure, that's fair. But you don't need to expose every single detail of
the PHY. You need to use abstractions to make accesses to the PHY easy
to maintain. See the example above.

> > > > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > > >
> > > > Whats should be exactly done here? Looks to me like it should be
> > > > part of init. Does these pin settings need to be changed
> > dynamically?
> > >
> > > These are all phy pins which will be physically come in contact with
> > > smart card When inserted. In case of synchronous card, these pins
> > will
> > > be toggled manually by s/w bit bang algorithm
> > 
> > is that a requirement or just something that everybody does ?
> >
> 
> Its requirement for synchronous card. At present there is no open driver
> Which does this thing.

alright, so you need to tell the PHY in which mode it should work and
the PHY driver needs to be smart enough to choose proper callbacks
depending on the mode.

> > In any case, you can hide that under some gpio calls, or something
> > similar.
> 
> Can't be done using GPIO as pin can be toggled only which i2c read/write
> to the phy.

so ? look at the numerous I2C GPIO expanders we have in the kernel ;-)

> > > > > Smartcard_get_version -> phy_get_version
> > > >
> > > > Again why? Why would the smartcard need the version of the PHY?
> > > >
> > >
> > > Can be omitted. This is for the test suite reference.
> > 
> > if it's for testsuite, it sounds like something that should be done
> > through userland and, as such, should be implemented by a set of
> > debugfs
> > files which expose the necessary information. That has nothing to do
> > with the PHY framework.
> > 
> Agree.. can be omitted.
> 
> 
> I am ok to give internal webex presentation (TI team) to brief 
> on phy and smart card controller interface.

let's try to cut down on internal agreements and let the community help
defining a proper way to handle the PHY :-)

Still, if you want to point me and Kishon (privately) to some internal
documentation, we can certainly read through it :-)

cheers

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

[PATCH v9 0/8] Generic PHY Framework

[Felipe Balbi]

Hi,

On Tue, Jul 09, 2013 at 02:33:58PM +0200, Patel, Satish wrote:
> > > Operation:
> > >
> > > Once the card gets inserted into the slot, user application can
> > > initiate activate sequence anytime, it is not mandatory that
> > > activation has to be called Immediately. It all depends whether
> > other
> > > connections ( network, printer) are proper.  User application can do
> > > some checks and then dynamically activate the card
> > 
> > The card or the phy ? Who actually activates ? Is the activation
> > handling part of the PHY or part of the smartcard controller ?
> > 
> 
> It?s a activation of smart card which is inserted into the phy slot. 
> Smart card activation will by done phy but initiated by user application
> Handling of activation should be done at both the side - controller as well
> As phy. Phy will raise certain signals and check timeout while activation
> , while controller will store data coming from smart card to FIFO. Its
> Controller which will give command to phy to initiate activation sequence when it
> is ready. 
> 
> Which means, both controller and phy has role to play while activation.
> Also it is applicable while deactivation.

right, so when the smartcard device is opened, you want to powerup the
PHY, powerup the smartcard controller and get things going, which means
that all your activation logic can, and should, be hidden by
phy_power_on() and phy_power_off()

Perhaps you also want to delay phy_init() and phy_shutdown() to that
very time, which would mean that we wouldn't even need
phy_power_{on,off}() calls whatsoever.

> > > There are 2 sequence of activation - normal activation and warm
> > reset.
> > > If first fails then warm reset should be executed, if card does not
> > > response to both then deactivation will be carried out
> > 
> > ret = phy_resume(phy);
> > if (ret == -EINVAL) { /* perhaps there's a better error code */
> > 	ret = phy_reset(phy);
> > 	if (ret)
> > 		phy_suspend(phy);
> > }
> >
> 
> Its not like this. There are the cases, when during normal activation
> card respond With some characters, but they might not be valid or
> error prone - This check will be done by user application as only
> application knows how to decode characters as per protocol.

sure, and if the characters are invalid, the application needs to tell
the kernel, perhaps it would be enough to send and IOCTL or, even
easier, close the device and reopen it.

> It there is any error in characters/timeout paratmeters, user
> application will ask to initiate Warm reset.

and for that we can use an IOCTL which is implemented by smart card
layer. I mean, I'm assuming the smartcard would be seen as a char dev by
userland so it would be something like this:

ret = read(fd, buf, SIZE);
if (ret < 0)
	boom();

ret = process_buffer(buf, ret);
if (ret == -EINVAL) { /* we have received invalid characters */
	ret = ioctl(fd, IOCTL_SMARTCARD_WARM_RESET);
	if (ret < 0)
		handle_error();
}

in kernel space we would have an ioctl handler like so:

static int smart_card_ioctl(struct file *fd, unsigned code, usigned long v)
{
	struct smart_card *sc = fd->private_data;
	unsigned long flags;
	int ret;

	spin_lock_irqsave(&sc->lock, flags);
	switch (v)
	case SMART_CARD_WARM_RESET:
		ret = phy_shutdown(sc->phy);
		if (ret < 0)
			boom();

		ret = smart_card_reset(sc);
		if (ret < 0)
			boom();

		ret = phy_init(sc->phy);
		if (ret < 0)
			boom();
		break;
	[ ... ]
	}

	spin_unlock_irqrestore(&sc->lock, flags);

	return ret;
}

see, we don't need to add a bunch of stuff in the PHY framework, because
you shouldn't expose the PHY directly to userland. You *must* have an
abstraction to userland with an in-kernel usage of the PHY layer.

> > > - on activation card will respond with some initial characters
> > (ATR),
> > > which will be verified by application, in case of error user
> > > application will de-activate the card not the phy module
> > >
> > > - After activation, use application initiate normal tx/rx
> > >
> > > - Once tx/rx is done, it will initiate deactivation of card not the
> > > phy module.
> > 
> > then that has nothing to do with the PHY framework, right ?
> 
> But all such sequence will be initiated by PHY by raising certain
> signals and only controller can give the push when to start.

sure, that's fair. But you don't need to expose every single detail of
the PHY. You need to use abstractions to make accesses to the PHY easy
to maintain. See the example above.

> > > > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > > >
> > > > Whats should be exactly done here? Looks to me like it should be
> > > > part of init. Does these pin settings need to be changed
> > dynamically?
> > >
> > > These are all phy pins which will be physically come in contact with
> > > smart card When inserted. In case of synchronous card, these pins
> > will
> > > be toggled manually by s/w bit bang algorithm
> > 
> > is that a requirement or just something that everybody does ?
> >
> 
> Its requirement for synchronous card. At present there is no open driver
> Which does this thing.

alright, so you need to tell the PHY in which mode it should work and
the PHY driver needs to be smart enough to choose proper callbacks
depending on the mode.

> > In any case, you can hide that under some gpio calls, or something
> > similar.
> 
> Can't be done using GPIO as pin can be toggled only which i2c read/write
> to the phy.

so ? look at the numerous I2C GPIO expanders we have in the kernel ;-)

> > > > > Smartcard_get_version -> phy_get_version
> > > >
> > > > Again why? Why would the smartcard need the version of the PHY?
> > > >
> > >
> > > Can be omitted. This is for the test suite reference.
> > 
> > if it's for testsuite, it sounds like something that should be done
> > through userland and, as such, should be implemented by a set of
> > debugfs
> > files which expose the necessary information. That has nothing to do
> > with the PHY framework.
> > 
> Agree.. can be omitted.
> 
> 
> I am ok to give internal webex presentation (TI team) to brief 
> on phy and smart card controller interface.

let's try to cut down on internal agreements and let the community help
defining a proper way to handle the PHY :-)

Still, if you want to point me and Kishon (privately) to some internal
documentation, we can certainly read through it :-)

cheers

-- 
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/20130709/9c264c9a/attachment.sig>

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Greg KH]

On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
> +menuconfig GENERIC_PHY
> +	tristate "PHY Subsystem"
> +	help
> +	  Generic PHY support.
> +
> +	  This framework is designed to provide a generic interface for PHY
> +	  devices present in the kernel. This layer will have the generic
> +	  API by which phy drivers can create PHY using the phy framework and
> +	  phy users can obtain reference to the PHY.

Shouldn't this be something that other drivers select?  How will anyone
know if they need this or not?

> --- /dev/null
> +++ b/drivers/phy/phy-core.c
> @@ -0,0 +1,544 @@
> +/*
> + * phy-core.c  --  Generic Phy framework.
> + *
> + * Copyright (C) 2013 Texas Instruments
> + *
> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.

You really mean "any later version" (I have to ask)?

> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.

Are these two paragraphs needed?  This isn't a "program", and they got a
copy of the GPL already with the kernel.

> +static struct class *phy_class;

Why do you need a class?

When modifying/adding new sysfs stuff, you need a Documentation/ABI/
entry as well.

thanks,

greg k-h

[PATCH v9 1/8] drivers: phy: add generic PHY framework

[Greg KH]

On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
> +menuconfig GENERIC_PHY
> +	tristate "PHY Subsystem"
> +	help
> +	  Generic PHY support.
> +
> +	  This framework is designed to provide a generic interface for PHY
> +	  devices present in the kernel. This layer will have the generic
> +	  API by which phy drivers can create PHY using the phy framework and
> +	  phy users can obtain reference to the PHY.

Shouldn't this be something that other drivers select?  How will anyone
know if they need this or not?

> --- /dev/null
> +++ b/drivers/phy/phy-core.c
> @@ -0,0 +1,544 @@
> +/*
> + * phy-core.c  --  Generic Phy framework.
> + *
> + * Copyright (C) 2013 Texas Instruments
> + *
> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.

You really mean "any later version" (I have to ask)?

> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.

Are these two paragraphs needed?  This isn't a "program", and they got a
copy of the GPL already with the kernel.

> +static struct class *phy_class;

Why do you need a class?

When modifying/adding new sysfs stuff, you need a Documentation/ABI/
entry as well.

thanks,

greg k-h

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

Hi,

On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
> On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
>> +menuconfig GENERIC_PHY
>> +	tristate "PHY Subsystem"
>> +	help
>> +	  Generic PHY support.
>> +
>> +	  This framework is designed to provide a generic interface for PHY
>> +	  devices present in the kernel. This layer will have the generic
>> +	  API by which phy drivers can create PHY using the phy framework and
>> +	  phy users can obtain reference to the PHY.
> 
> Shouldn't this be something that other drivers select?  How will anyone
> know if they need this or not?

All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those
PHY drivers can be selected like in [1].
The PHY consumer driver should ideally use *depends on* in their Kconfig.

[1] ->
http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> 
>> --- /dev/null
>> +++ b/drivers/phy/phy-core.c
>> @@ -0,0 +1,544 @@
>> +/*
>> + * phy-core.c  --  Generic Phy framework.
>> + *
>> + * Copyright (C) 2013 Texas Instruments
>> + *
>> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
>> + *
>> + * This program is free software; you can redistribute  it and/or modify it
>> + * under  the terms of  the GNU General  Public License as published by the
>> + * Free Software Foundation;  either version 2 of the  License, or (at your
>> + * option) any later version.
> 
> You really mean "any later version" (I have to ask)?

That was copied from somewhere :-s
> 
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> 
> Are these two paragraphs needed?  This isn't a "program", and they got a
> copy of the GPL already with the kernel.

hmm.. I can remove that.
> 
>> +static struct class *phy_class;
> 
> Why do you need a class?

Wanted to group all the PHY drivers to be used by different subsystems
(SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
initial version [3] on using a bus_type instead of class but then it was
decided to go with class itself.

[3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
> 
> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
> entry as well.

I'm not actually adding any new sysfs entry other than what a *class_create*
must have created. Do I need to add one for that?

Thanks
Kishon

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

Hi,

On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
> On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
>> +menuconfig GENERIC_PHY
>> +	tristate "PHY Subsystem"
>> +	help
>> +	  Generic PHY support.
>> +
>> +	  This framework is designed to provide a generic interface for PHY
>> +	  devices present in the kernel. This layer will have the generic
>> +	  API by which phy drivers can create PHY using the phy framework and
>> +	  phy users can obtain reference to the PHY.
> 
> Shouldn't this be something that other drivers select?  How will anyone
> know if they need this or not?

All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those
PHY drivers can be selected like in [1].
The PHY consumer driver should ideally use *depends on* in their Kconfig.

[1] ->
http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> 
>> --- /dev/null
>> +++ b/drivers/phy/phy-core.c
>> @@ -0,0 +1,544 @@
>> +/*
>> + * phy-core.c  --  Generic Phy framework.
>> + *
>> + * Copyright (C) 2013 Texas Instruments
>> + *
>> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
>> + *
>> + * This program is free software; you can redistribute  it and/or modify it
>> + * under  the terms of  the GNU General  Public License as published by the
>> + * Free Software Foundation;  either version 2 of the  License, or (at your
>> + * option) any later version.
> 
> You really mean "any later version" (I have to ask)?

That was copied from somewhere :-s
> 
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> 
> Are these two paragraphs needed?  This isn't a "program", and they got a
> copy of the GPL already with the kernel.

hmm.. I can remove that.
> 
>> +static struct class *phy_class;
> 
> Why do you need a class?

Wanted to group all the PHY drivers to be used by different subsystems
(SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
initial version [3] on using a bus_type instead of class but then it was
decided to go with class itself.

[3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
> 
> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
> entry as well.

I'm not actually adding any new sysfs entry other than what a *class_create*
must have created. Do I need to add one for that?

Thanks
Kishon

[PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

Hi,

On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
> On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
>> +menuconfig GENERIC_PHY
>> +	tristate "PHY Subsystem"
>> +	help
>> +	  Generic PHY support.
>> +
>> +	  This framework is designed to provide a generic interface for PHY
>> +	  devices present in the kernel. This layer will have the generic
>> +	  API by which phy drivers can create PHY using the phy framework and
>> +	  phy users can obtain reference to the PHY.
> 
> Shouldn't this be something that other drivers select?  How will anyone
> know if they need this or not?

All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those
PHY drivers can be selected like in [1].
The PHY consumer driver should ideally use *depends on* in their Kconfig.

[1] ->
http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> 
>> --- /dev/null
>> +++ b/drivers/phy/phy-core.c
>> @@ -0,0 +1,544 @@
>> +/*
>> + * phy-core.c  --  Generic Phy framework.
>> + *
>> + * Copyright (C) 2013 Texas Instruments
>> + *
>> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
>> + *
>> + * This program is free software; you can redistribute  it and/or modify it
>> + * under  the terms of  the GNU General  Public License as published by the
>> + * Free Software Foundation;  either version 2 of the  License, or (at your
>> + * option) any later version.
> 
> You really mean "any later version" (I have to ask)?

That was copied from somewhere :-s
> 
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> 
> Are these two paragraphs needed?  This isn't a "program", and they got a
> copy of the GPL already with the kernel.

hmm.. I can remove that.
> 
>> +static struct class *phy_class;
> 
> Why do you need a class?

Wanted to group all the PHY drivers to be used by different subsystems
(SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
initial version [3] on using a bus_type instead of class but then it was
decided to go with class itself.

[3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
> 
> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
> entry as well.

I'm not actually adding any new sysfs entry other than what a *class_create*
must have created. Do I need to add one for that?

Thanks
Kishon

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Greg KH]

On Wed, Jul 17, 2013 at 03:02:59PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
> > On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
> >> +menuconfig GENERIC_PHY
> >> +	tristate "PHY Subsystem"
> >> +	help
> >> +	  Generic PHY support.
> >> +
> >> +	  This framework is designed to provide a generic interface for PHY
> >> +	  devices present in the kernel. This layer will have the generic
> >> +	  API by which phy drivers can create PHY using the phy framework and
> >> +	  phy users can obtain reference to the PHY.
> > 
> > Shouldn't this be something that other drivers select?  How will anyone
> > know if they need this or not?
> 
> All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those
> PHY drivers can be selected like in [1].
> The PHY consumer driver should ideally use *depends on* in their Kconfig.
> 
> [1] ->
> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html

No, switch it around the other way.  How would I even _know_ that I need
to enable the generic PHY subsystem in the first place?  How can I
determine that I need this for my hardware?  You need to give hints to
someone who doesn't even know what a PHY is, otherwise they will always
disable it and move on.

> >> --- /dev/null
> >> +++ b/drivers/phy/phy-core.c
> >> @@ -0,0 +1,544 @@
> >> +/*
> >> + * phy-core.c  --  Generic Phy framework.
> >> + *
> >> + * Copyright (C) 2013 Texas Instruments
> >> + *
> >> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
> >> + *
> >> + * This program is free software; you can redistribute  it and/or modify it
> >> + * under  the terms of  the GNU General  Public License as published by the
> >> + * Free Software Foundation;  either version 2 of the  License, or (at your
> >> + * option) any later version.
> > 
> > You really mean "any later version" (I have to ask)?
> 
> That was copied from somewhere :-s

So, is that what you really mean to have for this code?

> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> > 
> > Are these two paragraphs needed?  This isn't a "program", and they got a
> > copy of the GPL already with the kernel.
> 
> hmm.. I can remove that.
> > 
> >> +static struct class *phy_class;
> > 
> > Why do you need a class?
> 
> Wanted to group all the PHY drivers to be used by different subsystems
> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
> initial version [3] on using a bus_type instead of class but then it was
> decided to go with class itself.
> 
> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html

Ok, but what does the class usage get you?

> > When modifying/adding new sysfs stuff, you need a Documentation/ABI/
> > entry as well.
> 
> I'm not actually adding any new sysfs entry other than what a *class_create*
> must have created. Do I need to add one for that?

If you are not creating anything in sysfs at all, why use the driver
model?  (hint, I think you need to do something here to justify it...)

thanks,

greg k-h

[PATCH v9 1/8] drivers: phy: add generic PHY framework

[Greg KH]

On Wed, Jul 17, 2013 at 03:02:59PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
> > On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
> >> +menuconfig GENERIC_PHY
> >> +	tristate "PHY Subsystem"
> >> +	help
> >> +	  Generic PHY support.
> >> +
> >> +	  This framework is designed to provide a generic interface for PHY
> >> +	  devices present in the kernel. This layer will have the generic
> >> +	  API by which phy drivers can create PHY using the phy framework and
> >> +	  phy users can obtain reference to the PHY.
> > 
> > Shouldn't this be something that other drivers select?  How will anyone
> > know if they need this or not?
> 
> All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those
> PHY drivers can be selected like in [1].
> The PHY consumer driver should ideally use *depends on* in their Kconfig.
> 
> [1] ->
> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html

No, switch it around the other way.  How would I even _know_ that I need
to enable the generic PHY subsystem in the first place?  How can I
determine that I need this for my hardware?  You need to give hints to
someone who doesn't even know what a PHY is, otherwise they will always
disable it and move on.

> >> --- /dev/null
> >> +++ b/drivers/phy/phy-core.c
> >> @@ -0,0 +1,544 @@
> >> +/*
> >> + * phy-core.c  --  Generic Phy framework.
> >> + *
> >> + * Copyright (C) 2013 Texas Instruments
> >> + *
> >> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
> >> + *
> >> + * This program is free software; you can redistribute  it and/or modify it
> >> + * under  the terms of  the GNU General  Public License as published by the
> >> + * Free Software Foundation;  either version 2 of the  License, or (at your
> >> + * option) any later version.
> > 
> > You really mean "any later version" (I have to ask)?
> 
> That was copied from somewhere :-s

So, is that what you really mean to have for this code?

> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> > 
> > Are these two paragraphs needed?  This isn't a "program", and they got a
> > copy of the GPL already with the kernel.
> 
> hmm.. I can remove that.
> > 
> >> +static struct class *phy_class;
> > 
> > Why do you need a class?
> 
> Wanted to group all the PHY drivers to be used by different subsystems
> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
> initial version [3] on using a bus_type instead of class but then it was
> decided to go with class itself.
> 
> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html

Ok, but what does the class usage get you?

> > When modifying/adding new sysfs stuff, you need a Documentation/ABI/
> > entry as well.
> 
> I'm not actually adding any new sysfs entry other than what a *class_create*
> must have created. Do I need to add one for that?

If you are not creating anything in sysfs at all, why use the driver
model?  (hint, I think you need to do something here to justify it...)

thanks,

greg k-h

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

Hi,

On Wednesday 17 July 2013 10:55 PM, Greg KH wrote:
> On Wed, Jul 17, 2013 at 03:02:59PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
>>> On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
>>>> +menuconfig GENERIC_PHY
>>>> +	tristate "PHY Subsystem"
>>>> +	help
>>>> +	  Generic PHY support.
>>>> +
>>>> +	  This framework is designed to provide a generic interface for PHY
>>>> +	  devices present in the kernel. This layer will have the generic
>>>> +	  API by which phy drivers can create PHY using the phy framework and
>>>> +	  phy users can obtain reference to the PHY.
>>>
>>> Shouldn't this be something that other drivers select?  How will anyone
>>> know if they need this or not?
>>
>> All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those
>> PHY drivers can be selected like in [1].
>> The PHY consumer driver should ideally use *depends on* in their Kconfig.
>>
>> [1] ->
>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> 
> No, switch it around the other way.  How would I even _know_ that I need
> to enable the generic PHY subsystem in the first place?  How can I
> determine that I need this for my hardware?  You need to give hints to
> someone who doesn't even know what a PHY is, otherwise they will always
> disable it and move on.
> 
>>>> --- /dev/null
>>>> +++ b/drivers/phy/phy-core.c
>>>> @@ -0,0 +1,544 @@
>>>> +/*
>>>> + * phy-core.c  --  Generic Phy framework.
>>>> + *
>>>> + * Copyright (C) 2013 Texas Instruments
>>>> + *
>>>> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
>>>> + *
>>>> + * This program is free software; you can redistribute  it and/or modify it
>>>> + * under  the terms of  the GNU General  Public License as published by the
>>>> + * Free Software Foundation;  either version 2 of the  License, or (at your
>>>> + * option) any later version.
>>>
>>> You really mean "any later version" (I have to ask)?
>>
>> That was copied from somewhere :-s
> 
> So, is that what you really mean to have for this code?

indeed.
> 
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>
>>> Are these two paragraphs needed?  This isn't a "program", and they got a
>>> copy of the GPL already with the kernel.
>>
>> hmm.. I can remove that.
>>>
>>>> +static struct class *phy_class;
>>>
>>> Why do you need a class?
>>
>> Wanted to group all the PHY drivers to be used by different subsystems
>> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
>> initial version [3] on using a bus_type instead of class but then it was
>> decided to go with class itself.
>>
>> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
> 
> Ok, but what does the class usage get you?

hmm.. actually I use class only to iterate through the list of devices in *phy*
class which could very well be implemented using list. Just that I wont have a
/sys/class/phy/ entry to find the list of phys added in the system. I dont
think I want to add any other stuff to expose to the user space at this point
of time.
> 
>>> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
>>> entry as well.
>>
>> I'm not actually adding any new sysfs entry other than what a *class_create*
>> must have created. Do I need to add one for that?
> 
> If you are not creating anything in sysfs at all, why use the driver
> model?  (hint, I think you need to do something here to justify it...)

Well.. it helps me to use pm_runtime to enable clocks utilizing the
parent-child relationship.

Thanks
Kishon

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

Hi,

On Wednesday 17 July 2013 10:55 PM, Greg KH wrote:
> On Wed, Jul 17, 2013 at 03:02:59PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
>>> On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
>>>> +menuconfig GENERIC_PHY
>>>> +	tristate "PHY Subsystem"
>>>> +	help
>>>> +	  Generic PHY support.
>>>> +
>>>> +	  This framework is designed to provide a generic interface for PHY
>>>> +	  devices present in the kernel. This layer will have the generic
>>>> +	  API by which phy drivers can create PHY using the phy framework and
>>>> +	  phy users can obtain reference to the PHY.
>>>
>>> Shouldn't this be something that other drivers select?  How will anyone
>>> know if they need this or not?
>>
>> All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those
>> PHY drivers can be selected like in [1].
>> The PHY consumer driver should ideally use *depends on* in their Kconfig.
>>
>> [1] ->
>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> 
> No, switch it around the other way.  How would I even _know_ that I need
> to enable the generic PHY subsystem in the first place?  How can I
> determine that I need this for my hardware?  You need to give hints to
> someone who doesn't even know what a PHY is, otherwise they will always
> disable it and move on.
> 
>>>> --- /dev/null
>>>> +++ b/drivers/phy/phy-core.c
>>>> @@ -0,0 +1,544 @@
>>>> +/*
>>>> + * phy-core.c  --  Generic Phy framework.
>>>> + *
>>>> + * Copyright (C) 2013 Texas Instruments
>>>> + *
>>>> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
>>>> + *
>>>> + * This program is free software; you can redistribute  it and/or modify it
>>>> + * under  the terms of  the GNU General  Public License as published by the
>>>> + * Free Software Foundation;  either version 2 of the  License, or (at your
>>>> + * option) any later version.
>>>
>>> You really mean "any later version" (I have to ask)?
>>
>> That was copied from somewhere :-s
> 
> So, is that what you really mean to have for this code?

indeed.
> 
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>
>>> Are these two paragraphs needed?  This isn't a "program", and they got a
>>> copy of the GPL already with the kernel.
>>
>> hmm.. I can remove that.
>>>
>>>> +static struct class *phy_class;
>>>
>>> Why do you need a class?
>>
>> Wanted to group all the PHY drivers to be used by different subsystems
>> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
>> initial version [3] on using a bus_type instead of class but then it was
>> decided to go with class itself.
>>
>> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
> 
> Ok, but what does the class usage get you?

hmm.. actually I use class only to iterate through the list of devices in *phy*
class which could very well be implemented using list. Just that I wont have a
/sys/class/phy/ entry to find the list of phys added in the system. I dont
think I want to add any other stuff to expose to the user space at this point
of time.
> 
>>> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
>>> entry as well.
>>
>> I'm not actually adding any new sysfs entry other than what a *class_create*
>> must have created. Do I need to add one for that?
> 
> If you are not creating anything in sysfs at all, why use the driver
> model?  (hint, I think you need to do something here to justify it...)

Well.. it helps me to use pm_runtime to enable clocks utilizing the
parent-child relationship.

Thanks
Kishon

[PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

Hi,

On Wednesday 17 July 2013 10:55 PM, Greg KH wrote:
> On Wed, Jul 17, 2013 at 03:02:59PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
>>> On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
>>>> +menuconfig GENERIC_PHY
>>>> +	tristate "PHY Subsystem"
>>>> +	help
>>>> +	  Generic PHY support.
>>>> +
>>>> +	  This framework is designed to provide a generic interface for PHY
>>>> +	  devices present in the kernel. This layer will have the generic
>>>> +	  API by which phy drivers can create PHY using the phy framework and
>>>> +	  phy users can obtain reference to the PHY.
>>>
>>> Shouldn't this be something that other drivers select?  How will anyone
>>> know if they need this or not?
>>
>> All the PHY drivers should go here. So only if *GENERIC_PHY* is enabled those
>> PHY drivers can be selected like in [1].
>> The PHY consumer driver should ideally use *depends on* in their Kconfig.
>>
>> [1] ->
>> http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html
> 
> No, switch it around the other way.  How would I even _know_ that I need
> to enable the generic PHY subsystem in the first place?  How can I
> determine that I need this for my hardware?  You need to give hints to
> someone who doesn't even know what a PHY is, otherwise they will always
> disable it and move on.
> 
>>>> --- /dev/null
>>>> +++ b/drivers/phy/phy-core.c
>>>> @@ -0,0 +1,544 @@
>>>> +/*
>>>> + * phy-core.c  --  Generic Phy framework.
>>>> + *
>>>> + * Copyright (C) 2013 Texas Instruments
>>>> + *
>>>> + * Author: Kishon Vijay Abraham I <kishon@ti.com>
>>>> + *
>>>> + * This program is free software; you can redistribute  it and/or modify it
>>>> + * under  the terms of  the GNU General  Public License as published by the
>>>> + * Free Software Foundation;  either version 2 of the  License, or (at your
>>>> + * option) any later version.
>>>
>>> You really mean "any later version" (I have to ask)?
>>
>> That was copied from somewhere :-s
> 
> So, is that what you really mean to have for this code?

indeed.
> 
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>
>>> Are these two paragraphs needed?  This isn't a "program", and they got a
>>> copy of the GPL already with the kernel.
>>
>> hmm.. I can remove that.
>>>
>>>> +static struct class *phy_class;
>>>
>>> Why do you need a class?
>>
>> Wanted to group all the PHY drivers to be used by different subsystems
>> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
>> initial version [3] on using a bus_type instead of class but then it was
>> decided to go with class itself.
>>
>> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
> 
> Ok, but what does the class usage get you?

hmm.. actually I use class only to iterate through the list of devices in *phy*
class which could very well be implemented using list. Just that I wont have a
/sys/class/phy/ entry to find the list of phys added in the system. I dont
think I want to add any other stuff to expose to the user space at this point
of time.
> 
>>> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
>>> entry as well.
>>
>> I'm not actually adding any new sysfs entry other than what a *class_create*
>> must have created. Do I need to add one for that?
> 
> If you are not creating anything in sysfs at all, why use the driver
> model?  (hint, I think you need to do something here to justify it...)

Well.. it helps me to use pm_runtime to enable clocks utilizing the
parent-child relationship.

Thanks
Kishon

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Greg KH]

On Thu, Jul 18, 2013 at 11:33:17AM +0530, Kishon Vijay Abraham I wrote:
> >> Wanted to group all the PHY drivers to be used by different subsystems
> >> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
> >> initial version [3] on using a bus_type instead of class but then it was
> >> decided to go with class itself.
> >>
> >> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
> > 
> > Ok, but what does the class usage get you?
> 
> hmm.. actually I use class only to iterate through the list of devices in *phy*
> class which could very well be implemented using list. Just that I wont have a
> /sys/class/phy/ entry to find the list of phys added in the system. I dont
> think I want to add any other stuff to expose to the user space at this point
> of time.
> > 
> >>> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
> >>> entry as well.
> >>
> >> I'm not actually adding any new sysfs entry other than what a *class_create*
> >> must have created. Do I need to add one for that?
> > 
> > If you are not creating anything in sysfs at all, why use the driver
> > model?  (hint, I think you need to do something here to justify it...)
> 
> Well.. it helps me to use pm_runtime to enable clocks utilizing the
> parent-child relationship.

Ok, that's a good reason for this, nevermind then.  Care to send the
latest patches you have in emails so I can review them?

thanks,

greg k-h

[PATCH v9 1/8] drivers: phy: add generic PHY framework

[Greg KH]

On Thu, Jul 18, 2013 at 11:33:17AM +0530, Kishon Vijay Abraham I wrote:
> >> Wanted to group all the PHY drivers to be used by different subsystems
> >> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
> >> initial version [3] on using a bus_type instead of class but then it was
> >> decided to go with class itself.
> >>
> >> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
> > 
> > Ok, but what does the class usage get you?
> 
> hmm.. actually I use class only to iterate through the list of devices in *phy*
> class which could very well be implemented using list. Just that I wont have a
> /sys/class/phy/ entry to find the list of phys added in the system. I dont
> think I want to add any other stuff to expose to the user space at this point
> of time.
> > 
> >>> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
> >>> entry as well.
> >>
> >> I'm not actually adding any new sysfs entry other than what a *class_create*
> >> must have created. Do I need to add one for that?
> > 
> > If you are not creating anything in sysfs at all, why use the driver
> > model?  (hint, I think you need to do something here to justify it...)
> 
> Well.. it helps me to use pm_runtime to enable clocks utilizing the
> parent-child relationship.

Ok, that's a good reason for this, nevermind then.  Care to send the
latest patches you have in emails so I can review them?

thanks,

greg k-h

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

On Thursday 18 July 2013 11:54 AM, Greg KH wrote:
> On Thu, Jul 18, 2013 at 11:33:17AM +0530, Kishon Vijay Abraham I wrote:
>>>> Wanted to group all the PHY drivers to be used by different subsystems
>>>> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
>>>> initial version [3] on using a bus_type instead of class but then it was
>>>> decided to go with class itself.
>>>>
>>>> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
>>>
>>> Ok, but what does the class usage get you?
>>
>> hmm.. actually I use class only to iterate through the list of devices in *phy*
>> class which could very well be implemented using list. Just that I wont have a
>> /sys/class/phy/ entry to find the list of phys added in the system. I dont
>> think I want to add any other stuff to expose to the user space at this point
>> of time.
>>>
>>>>> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
>>>>> entry as well.
>>>>
>>>> I'm not actually adding any new sysfs entry other than what a *class_create*
>>>> must have created. Do I need to add one for that?
>>>
>>> If you are not creating anything in sysfs at all, why use the driver
>>> model?  (hint, I think you need to do something here to justify it...)
>>
>> Well.. it helps me to use pm_runtime to enable clocks utilizing the
>> parent-child relationship.
> 
> Ok, that's a good reason for this, nevermind then.  Care to send the
> latest patches you have in emails so I can review them?

Sure.

Thanks
Kishon

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

On Thursday 18 July 2013 11:54 AM, Greg KH wrote:
> On Thu, Jul 18, 2013 at 11:33:17AM +0530, Kishon Vijay Abraham I wrote:
>>>> Wanted to group all the PHY drivers to be used by different subsystems
>>>> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
>>>> initial version [3] on using a bus_type instead of class but then it was
>>>> decided to go with class itself.
>>>>
>>>> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
>>>
>>> Ok, but what does the class usage get you?
>>
>> hmm.. actually I use class only to iterate through the list of devices in *phy*
>> class which could very well be implemented using list. Just that I wont have a
>> /sys/class/phy/ entry to find the list of phys added in the system. I dont
>> think I want to add any other stuff to expose to the user space at this point
>> of time.
>>>
>>>>> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
>>>>> entry as well.
>>>>
>>>> I'm not actually adding any new sysfs entry other than what a *class_create*
>>>> must have created. Do I need to add one for that?
>>>
>>> If you are not creating anything in sysfs at all, why use the driver
>>> model?  (hint, I think you need to do something here to justify it...)
>>
>> Well.. it helps me to use pm_runtime to enable clocks utilizing the
>> parent-child relationship.
> 
> Ok, that's a good reason for this, nevermind then.  Care to send the
> latest patches you have in emails so I can review them?

Sure.

Thanks
Kishon

[PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

On Thursday 18 July 2013 11:54 AM, Greg KH wrote:
> On Thu, Jul 18, 2013 at 11:33:17AM +0530, Kishon Vijay Abraham I wrote:
>>>> Wanted to group all the PHY drivers to be used by different subsystems
>>>> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments in my
>>>> initial version [3] on using a bus_type instead of class but then it was
>>>> decided to go with class itself.
>>>>
>>>> [3] -> http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01389.html
>>>
>>> Ok, but what does the class usage get you?
>>
>> hmm.. actually I use class only to iterate through the list of devices in *phy*
>> class which could very well be implemented using list. Just that I wont have a
>> /sys/class/phy/ entry to find the list of phys added in the system. I dont
>> think I want to add any other stuff to expose to the user space at this point
>> of time.
>>>
>>>>> When modifying/adding new sysfs stuff, you need a Documentation/ABI/
>>>>> entry as well.
>>>>
>>>> I'm not actually adding any new sysfs entry other than what a *class_create*
>>>> must have created. Do I need to add one for that?
>>>
>>> If you are not creating anything in sysfs at all, why use the driver
>>> model?  (hint, I think you need to do something here to justify it...)
>>
>> Well.. it helps me to use pm_runtime to enable clocks utilizing the
>> parent-child relationship.
> 
> Ok, that's a good reason for this, nevermind then.  Care to send the
> latest patches you have in emails so I can review them?

Sure.

Thanks
Kishon

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

[Rahul Sharma]

Hi Balbi, Kishon,

I have similar requirements for exynos hdmi phy. hdmi driver (controller)
need to set the operating clock to hdmi phy which depends on the pixel
clock.

Phy has an internal pll to be configured as per changing resolution. It can
be done by writing into phy registers. CCF callbacks (set/get_rate) can
not be used unless I register phy as a clock controller. But that way
hdmi driver loses finer power control for the phy. Phy should be ON, only
when hdmi hotplugged.

Callback: set_phy_operating_freq in phy framework, seems generic and
addressing similar requirements for other phys. What you say on this?

regards,
Rahul Sharma.

On Tue, Jul 9, 2013 at 11:04 PM, Felipe Balbi <balbi@ti.com> wrote:
>
> Hi,
>
> On Tue, Jul 09, 2013 at 02:33:58PM +0200, Patel, Satish wrote:
> > > > Operation:
> > > >
> > > > Once the card gets inserted into the slot, user application can
> > > > initiate activate sequence anytime, it is not mandatory that
> > > > activation has to be called Immediately. It all depends whether
> > > other
> > > > connections ( network, printer) are proper.  User application can do
> > > > some checks and then dynamically activate the card
> > >
> > > The card or the phy ? Who actually activates ? Is the activation
> > > handling part of the PHY or part of the smartcard controller ?
> > >
> >
> > It’s a activation of smart card which is inserted into the phy slot.
> > Smart card activation will by done phy but initiated by user application
> > Handling of activation should be done at both the side - controller as well
> > As phy. Phy will raise certain signals and check timeout while activation
> > , while controller will store data coming from smart card to FIFO. Its
> > Controller which will give command to phy to initiate activation sequence when it
> > is ready.
> >
> > Which means, both controller and phy has role to play while activation.
> > Also it is applicable while deactivation.
>
> right, so when the smartcard device is opened, you want to powerup the
> PHY, powerup the smartcard controller and get things going, which means
> that all your activation logic can, and should, be hidden by
> phy_power_on() and phy_power_off()
>
> Perhaps you also want to delay phy_init() and phy_shutdown() to that
> very time, which would mean that we wouldn't even need
> phy_power_{on,off}() calls whatsoever.
>
> > > > There are 2 sequence of activation - normal activation and warm
> > > reset.
> > > > If first fails then warm reset should be executed, if card does not
> > > > response to both then deactivation will be carried out
> > >
> > > ret = phy_resume(phy);
> > > if (ret == -EINVAL) { /* perhaps there's a better error code */
> > >     ret = phy_reset(phy);
> > >     if (ret)
> > >             phy_suspend(phy);
> > > }
> > >
> >
> > Its not like this. There are the cases, when during normal activation
> > card respond With some characters, but they might not be valid or
> > error prone - This check will be done by user application as only
> > application knows how to decode characters as per protocol.
>
> sure, and if the characters are invalid, the application needs to tell
> the kernel, perhaps it would be enough to send and IOCTL or, even
> easier, close the device and reopen it.
>
> > It there is any error in characters/timeout paratmeters, user
> > application will ask to initiate Warm reset.
>
> and for that we can use an IOCTL which is implemented by smart card
> layer. I mean, I'm assuming the smartcard would be seen as a char dev by
> userland so it would be something like this:
>
> ret = read(fd, buf, SIZE);
> if (ret < 0)
>         boom();
>
> ret = process_buffer(buf, ret);
> if (ret == -EINVAL) { /* we have received invalid characters */
>         ret = ioctl(fd, IOCTL_SMARTCARD_WARM_RESET);
>         if (ret < 0)
>                 handle_error();
> }
>
> in kernel space we would have an ioctl handler like so:
>
> static int smart_card_ioctl(struct file *fd, unsigned code, usigned long v)
> {
>         struct smart_card *sc = fd->private_data;
>         unsigned long flags;
>         int ret;
>
>         spin_lock_irqsave(&sc->lock, flags);
>         switch (v)
>         case SMART_CARD_WARM_RESET:
>                 ret = phy_shutdown(sc->phy);
>                 if (ret < 0)
>                         boom();
>
>                 ret = smart_card_reset(sc);
>                 if (ret < 0)
>                         boom();
>
>                 ret = phy_init(sc->phy);
>                 if (ret < 0)
>                         boom();
>                 break;
>         [ ... ]
>         }
>
>         spin_unlock_irqrestore(&sc->lock, flags);
>
>         return ret;
> }
>
> see, we don't need to add a bunch of stuff in the PHY framework, because
> you shouldn't expose the PHY directly to userland. You *must* have an
> abstraction to userland with an in-kernel usage of the PHY layer.
>
> > > > - on activation card will respond with some initial characters
> > > (ATR),
> > > > which will be verified by application, in case of error user
> > > > application will de-activate the card not the phy module
> > > >
> > > > - After activation, use application initiate normal tx/rx
> > > >
> > > > - Once tx/rx is done, it will initiate deactivation of card not the
> > > > phy module.
> > >
> > > then that has nothing to do with the PHY framework, right ?
> >
> > But all such sequence will be initiated by PHY by raising certain
> > signals and only controller can give the push when to start.
>
> sure, that's fair. But you don't need to expose every single detail of
> the PHY. You need to use abstractions to make accesses to the PHY easy
> to maintain. See the example above.
>
> > > > > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > > > >
> > > > > Whats should be exactly done here? Looks to me like it should be
> > > > > part of init. Does these pin settings need to be changed
> > > dynamically?
> > > >
> > > > These are all phy pins which will be physically come in contact with
> > > > smart card When inserted. In case of synchronous card, these pins
> > > will
> > > > be toggled manually by s/w bit bang algorithm
> > >
> > > is that a requirement or just something that everybody does ?
> > >
> >
> > Its requirement for synchronous card. At present there is no open driver
> > Which does this thing.
>
> alright, so you need to tell the PHY in which mode it should work and
> the PHY driver needs to be smart enough to choose proper callbacks
> depending on the mode.
>
> > > In any case, you can hide that under some gpio calls, or something
> > > similar.
> >
> > Can't be done using GPIO as pin can be toggled only which i2c read/write
> > to the phy.
>
> so ? look at the numerous I2C GPIO expanders we have in the kernel ;-)
>
> > > > > > Smartcard_get_version -> phy_get_version
> > > > >
> > > > > Again why? Why would the smartcard need the version of the PHY?
> > > > >
> > > >
> > > > Can be omitted. This is for the test suite reference.
> > >
> > > if it's for testsuite, it sounds like something that should be done
> > > through userland and, as such, should be implemented by a set of
> > > debugfs
> > > files which expose the necessary information. That has nothing to do
> > > with the PHY framework.
> > >
> > Agree.. can be omitted.
> >
> >
> > I am ok to give internal webex presentation (TI team) to brief
> > on phy and smart card controller interface.
>
> let's try to cut down on internal agreements and let the community help
> defining a proper way to handle the PHY :-)
>
> Still, if you want to point me and Kishon (privately) to some internal
> documentation, we can certainly read through it :-)
>
> cheers
>
> --
> balbi
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[PATCH v9 0/8] Generic PHY Framework

[Rahul Sharma]

Hi Balbi, Kishon,

I have similar requirements for exynos hdmi phy. hdmi driver (controller)
need to set the operating clock to hdmi phy which depends on the pixel
clock.

Phy has an internal pll to be configured as per changing resolution. It can
be done by writing into phy registers. CCF callbacks (set/get_rate) can
not be used unless I register phy as a clock controller. But that way
hdmi driver loses finer power control for the phy. Phy should be ON, only
when hdmi hotplugged.

Callback: set_phy_operating_freq in phy framework, seems generic and
addressing similar requirements for other phys. What you say on this?

regards,
Rahul Sharma.

On Tue, Jul 9, 2013 at 11:04 PM, Felipe Balbi <balbi@ti.com> wrote:
>
> Hi,
>
> On Tue, Jul 09, 2013 at 02:33:58PM +0200, Patel, Satish wrote:
> > > > Operation:
> > > >
> > > > Once the card gets inserted into the slot, user application can
> > > > initiate activate sequence anytime, it is not mandatory that
> > > > activation has to be called Immediately. It all depends whether
> > > other
> > > > connections ( network, printer) are proper.  User application can do
> > > > some checks and then dynamically activate the card
> > >
> > > The card or the phy ? Who actually activates ? Is the activation
> > > handling part of the PHY or part of the smartcard controller ?
> > >
> >
> > It?s a activation of smart card which is inserted into the phy slot.
> > Smart card activation will by done phy but initiated by user application
> > Handling of activation should be done at both the side - controller as well
> > As phy. Phy will raise certain signals and check timeout while activation
> > , while controller will store data coming from smart card to FIFO. Its
> > Controller which will give command to phy to initiate activation sequence when it
> > is ready.
> >
> > Which means, both controller and phy has role to play while activation.
> > Also it is applicable while deactivation.
>
> right, so when the smartcard device is opened, you want to powerup the
> PHY, powerup the smartcard controller and get things going, which means
> that all your activation logic can, and should, be hidden by
> phy_power_on() and phy_power_off()
>
> Perhaps you also want to delay phy_init() and phy_shutdown() to that
> very time, which would mean that we wouldn't even need
> phy_power_{on,off}() calls whatsoever.
>
> > > > There are 2 sequence of activation - normal activation and warm
> > > reset.
> > > > If first fails then warm reset should be executed, if card does not
> > > > response to both then deactivation will be carried out
> > >
> > > ret = phy_resume(phy);
> > > if (ret == -EINVAL) { /* perhaps there's a better error code */
> > >     ret = phy_reset(phy);
> > >     if (ret)
> > >             phy_suspend(phy);
> > > }
> > >
> >
> > Its not like this. There are the cases, when during normal activation
> > card respond With some characters, but they might not be valid or
> > error prone - This check will be done by user application as only
> > application knows how to decode characters as per protocol.
>
> sure, and if the characters are invalid, the application needs to tell
> the kernel, perhaps it would be enough to send and IOCTL or, even
> easier, close the device and reopen it.
>
> > It there is any error in characters/timeout paratmeters, user
> > application will ask to initiate Warm reset.
>
> and for that we can use an IOCTL which is implemented by smart card
> layer. I mean, I'm assuming the smartcard would be seen as a char dev by
> userland so it would be something like this:
>
> ret = read(fd, buf, SIZE);
> if (ret < 0)
>         boom();
>
> ret = process_buffer(buf, ret);
> if (ret == -EINVAL) { /* we have received invalid characters */
>         ret = ioctl(fd, IOCTL_SMARTCARD_WARM_RESET);
>         if (ret < 0)
>                 handle_error();
> }
>
> in kernel space we would have an ioctl handler like so:
>
> static int smart_card_ioctl(struct file *fd, unsigned code, usigned long v)
> {
>         struct smart_card *sc = fd->private_data;
>         unsigned long flags;
>         int ret;
>
>         spin_lock_irqsave(&sc->lock, flags);
>         switch (v)
>         case SMART_CARD_WARM_RESET:
>                 ret = phy_shutdown(sc->phy);
>                 if (ret < 0)
>                         boom();
>
>                 ret = smart_card_reset(sc);
>                 if (ret < 0)
>                         boom();
>
>                 ret = phy_init(sc->phy);
>                 if (ret < 0)
>                         boom();
>                 break;
>         [ ... ]
>         }
>
>         spin_unlock_irqrestore(&sc->lock, flags);
>
>         return ret;
> }
>
> see, we don't need to add a bunch of stuff in the PHY framework, because
> you shouldn't expose the PHY directly to userland. You *must* have an
> abstraction to userland with an in-kernel usage of the PHY layer.
>
> > > > - on activation card will respond with some initial characters
> > > (ATR),
> > > > which will be verified by application, in case of error user
> > > > application will de-activate the card not the phy module
> > > >
> > > > - After activation, use application initiate normal tx/rx
> > > >
> > > > - Once tx/rx is done, it will initiate deactivation of card not the
> > > > phy module.
> > >
> > > then that has nothing to do with the PHY framework, right ?
> >
> > But all such sequence will be initiated by PHY by raising certain
> > signals and only controller can give the push when to start.
>
> sure, that's fair. But you don't need to expose every single detail of
> the PHY. You need to use abstractions to make accesses to the PHY easy
> to maintain. See the example above.
>
> > > > > > Smartcard_set_c4/c8/rst/io -> phy_set_pin
> > > > >
> > > > > Whats should be exactly done here? Looks to me like it should be
> > > > > part of init. Does these pin settings need to be changed
> > > dynamically?
> > > >
> > > > These are all phy pins which will be physically come in contact with
> > > > smart card When inserted. In case of synchronous card, these pins
> > > will
> > > > be toggled manually by s/w bit bang algorithm
> > >
> > > is that a requirement or just something that everybody does ?
> > >
> >
> > Its requirement for synchronous card. At present there is no open driver
> > Which does this thing.
>
> alright, so you need to tell the PHY in which mode it should work and
> the PHY driver needs to be smart enough to choose proper callbacks
> depending on the mode.
>
> > > In any case, you can hide that under some gpio calls, or something
> > > similar.
> >
> > Can't be done using GPIO as pin can be toggled only which i2c read/write
> > to the phy.
>
> so ? look at the numerous I2C GPIO expanders we have in the kernel ;-)
>
> > > > > > Smartcard_get_version -> phy_get_version
> > > > >
> > > > > Again why? Why would the smartcard need the version of the PHY?
> > > > >
> > > >
> > > > Can be omitted. This is for the test suite reference.
> > >
> > > if it's for testsuite, it sounds like something that should be done
> > > through userland and, as such, should be implemented by a set of
> > > debugfs
> > > files which expose the necessary information. That has nothing to do
> > > with the PHY framework.
> > >
> > Agree.. can be omitted.
> >
> >
> > I am ok to give internal webex presentation (TI team) to brief
> > on phy and smart card controller interface.
>
> let's try to cut down on internal agreements and let the community help
> defining a proper way to handle the PHY :-)
>
> Still, if you want to point me and Kishon (privately) to some internal
> documentation, we can certainly read through it :-)
>
> cheers
>
> --
> balbi
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

On Friday 28 June 2013 08:57 AM, Jingoo Han wrote:
> On Wed, 26 Jun 2013 17:17:29 +0530, Kishon Vijay Abraham Iwrote:
>> The PHY framework 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. For dt-boot, the PHY drivers should
>> also register *PHY provider* with the framework.
>>
>> PHY drivers should create the PHY by passing id and ops like init, exit,
>> power_on and power_off. This framework is also pm runtime enabled.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for dt binding can be found at
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
> Tested-by: Jingoo Han <jg1.han@samsung.com>
>
> It looks great to me!
>
> I tested this General PHY framework with Exynos5250 eDP.
> It works properly.

Thanks for testing this :-)

> I will share the patch 'Generic PHY driver for the Exynos SoC DP PHY', soon.
> Thanks.

Cool.

Thanks
Kishon

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

On Friday 28 June 2013 08:57 AM, Jingoo Han wrote:
> On Wed, 26 Jun 2013 17:17:29 +0530, Kishon Vijay Abraham Iwrote:
>> The PHY framework 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. For dt-boot, the PHY drivers should
>> also register *PHY provider* with the framework.
>>
>> PHY drivers should create the PHY by passing id and ops like init, exit,
>> power_on and power_off. This framework is also pm runtime enabled.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for dt binding can be found at
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
> Tested-by: Jingoo Han <jg1.han@samsung.com>
>
> It looks great to me!
>
> I tested this General PHY framework with Exynos5250 eDP.
> It works properly.

Thanks for testing this :-)

> I will share the patch 'Generic PHY driver for the Exynos SoC DP PHY', soon.
> Thanks.

Cool.

Thanks
Kishon

[PATCH v9 1/8] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

On Friday 28 June 2013 08:57 AM, Jingoo Han wrote:
> On Wed, 26 Jun 2013 17:17:29 +0530, Kishon Vijay Abraham Iwrote:
>> The PHY framework 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. For dt-boot, the PHY drivers should
>> also register *PHY provider* with the framework.
>>
>> PHY drivers should create the PHY by passing id and ops like init, exit,
>> power_on and power_off. This framework is also pm runtime enabled.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for dt binding can be found at
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
> Tested-by: Jingoo Han <jg1.han@samsung.com>
>
> It looks great to me!
>
> I tested this General PHY framework with Exynos5250 eDP.
> It works properly.

Thanks for testing this :-)

> I will share the patch 'Generic PHY driver for the Exynos SoC DP PHY', soon.
> Thanks.

Cool.

Thanks
Kishon

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Jingoo Han]

On Wed, 26 Jun 2013 17:17:29 +0530, Kishon Vijay Abraham Iwrote:
> The PHY framework 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. For dt-boot, the PHY drivers should
> also register *PHY provider* with the framework.
>
> PHY drivers should create the PHY by passing id and ops like init, exit,
> power_on and power_off. This framework is also pm runtime enabled.
>
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for dt binding can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

Tested-by: Jingoo Han <jg1.han@samsung.com>

It looks great to me!

I tested this General PHY framework with Exynos5250 eDP.
It works properly.
I will share the patch 'Generic PHY driver for the Exynos SoC DP PHY', soon.
Thanks.

Best regards,
Jingoo Han

> ---
>  .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
>  Documentation/phy.txt                              |  129 +++++
>  MAINTAINERS                                        |    7 +
>  drivers/Kconfig                                    |    2 +
>  drivers/Makefile                                   |    2 +
>  drivers/phy/Kconfig                                |   13 +
>  drivers/phy/Makefile                               |    5 +
>  drivers/phy/phy-core.c                             |  544 ++++++++++++++++++++
>  include/linux/phy/phy.h                            |  344 +++++++++++++
>  9 files changed, 1112 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
>  create mode 100644 Documentation/phy.txt
>  create mode 100644 drivers/phy/Kconfig
>  create mode 100644 drivers/phy/Makefile
>  create mode 100644 drivers/phy/phy-core.c
>  create mode 100644 include/linux/phy/phy.h

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Jingoo Han]

On Wed, 26 Jun 2013 17:17:29 +0530, Kishon Vijay Abraham Iwrote:
> The PHY framework 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. For dt-boot, the PHY drivers should
> also register *PHY provider* with the framework.
>
> PHY drivers should create the PHY by passing id and ops like init, exit,
> power_on and power_off. This framework is also pm runtime enabled.
>
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for dt binding can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

Tested-by: Jingoo Han <jg1.han@samsung.com>

It looks great to me!

I tested this General PHY framework with Exynos5250 eDP.
It works properly.
I will share the patch 'Generic PHY driver for the Exynos SoC DP PHY', soon.
Thanks.

Best regards,
Jingoo Han

> ---
>  .../devicetree/bindings/phy/phy-bindings.txt       |   66 +++
>  Documentation/phy.txt                              |  129 +++++
>  MAINTAINERS                                        |    7 +
>  drivers/Kconfig                                    |    2 +
>  drivers/Makefile                                   |    2 +
>  drivers/phy/Kconfig                                |   13 +
>  drivers/phy/Makefile                               |    5 +
>  drivers/phy/phy-core.c                             |  544 ++++++++++++++++++++
>  include/linux/phy/phy.h                            |  344 +++++++++++++
>  9 files changed, 1112 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
>  create mode 100644 Documentation/phy.txt
>  create mode 100644 drivers/phy/Kconfig
>  create mode 100644 drivers/phy/Makefile
>  create mode 100644 drivers/phy/phy-core.c
>  create mode 100644 include/linux/phy/phy.h