linux-kernel - [RFC] Does PHY UTMI data width belong to DWC2 or PHY binding?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Oct 2013 10:12:21 -0400
From:	Matt Porter <matt.porter@...aro.org>
To:	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dia.com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Felipe Balbi <balbi@...com>,
	Kishon Vijay Abraham I <kishon@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Paul Zimmerman <paulz@...opsys.com>,
	Devicetree List <devicetree@...r.kernel.org>,
	Linux USB List <linux-usb@...r.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [RFC] Does PHY UTMI data width belong to DWC2 or PHY binding?

This is a summary of an unresolved issue resulting from this thread:
http://www.spinics.net/lists/arm-kernel/msg277700.html

The BCM281xx family of SoCs contain an OTG subsystem consisting of a
DWC2 HSOTG controller and an internal UTMI PHY. This is appears as
follows (monospace font requirement ahead):

+----------------+              +-----------------+
|                |              |                 |
|                |       8      |                 |
|      DWC2      |<------/----->|     BCM Kona    |
|                |     UTMI     |     UTMI PHY    |
|                |              |                 |
+----------------+              +-----------------+

The internal UTMI phy is connected via an 8-bit data path. There is
no way to autodetect whether the data path is 8-bit or 16-bit. As such,
it was determined that a DT property is necessary to reflect this.

In the original patch submitted this property was offered as an
additional optional dwc2 property:

--- a/Documentation/devicetree/bindings/staging/dwc2.txt
+++ b/Documentation/devicetree/bindings/staging/dwc2.txt
@@ -6,10 +6,14 @@ Required properties:
 - reg : Should contain 1 register range (address and length)
 - interrupts : Should contain 1 interrupt

+Optional properties:
+- snps,phy-utmi-width: Must contain the UTMI data width (either 8 or 16)
+
 Example:

         usb@...c0000 {
                 compatible = "ralink,rt3050-usb, snps,dwc2";
                 reg = <0x101c0000 40000>;
                 interrupts = <18>;
+		snps,phy-utmi-width = <8>;
         };

The open question is whether this required hardware property belongs to
the DWC2 controller or the PHY itself.

If the UTMI data path width is considered to be a property of the PHY
then this will impact both the generic PHY framework and the PHY device
node (producer) binding. The binding would need to be extended to carry
the data path width property. In addition, the generic PHY framework
would need to allow for this information to be gathered in some manner
for use by the controller driver (PHY consumer). In the case of DWC2,
the driver needs to know whether to program the phy interface for 8 or
16 bit UTMI communication.

Thanks,
Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/