[PATCH v3] arm64: dts: exynos: add OF graph between USB-PHY and MUIC

[Andrzej Hajda]

OF graph describes USB data lanes between USB-PHY and respective MUIC.
Since graph is present and DWC driver can use it to get extcon, obsolete
extcon property can be removed.

Signed-off-by: Andrzej Hajda 
---
v3:
 - removed #address-cells/#size-cells from ports node.

Hi Krzysztof,

This is next version of the patch I forgot. I have addressed your comments,
I hope correctly :)

Regards
Andrzej
---
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi| 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index a1e3194b7483..95cbf5f0921d 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -868,6 +868,14 @@
};
};
};
+
+   ports {
+   port {
+   muic_to_usb: endpoint {
+   remote-endpoint = 
<_to_muic>;
+   };
+   };
+   };
};
 
regulators {
@@ -1283,12 +1291,17 @@
 
 _dwc3 {
dr_mode = "otg";
-   extcon = <>;
 };
 
 _phy {
vbus-supply = <_reg>;
status = "okay";
+
+   port {
+   usb_to_muic: endpoint {
+   remote-endpoint = <_to_usb>;
+   };
+   };
 };
 
  {
-- 
2.18.0

Re: USB role switches, usb-connector, typec and device trees

[Andrzej Hajda]

On 12.06.2018 19:33, Mats Karrman wrote:
> Hi Andrzej,
>
> On 2018-06-07 13:40, Andrzej Hajda wrote:
>
>> On 06.06.2018 23:36, Mats Karrman wrote:
>>> Hello Gentlemen,
>>>
>>> I'm trying to get my head around USB role switches in connection with 
>>> Type-C ports
>>> and device-trees. So far I have not found much documentation, e.g. there 
>>> are no
>>> device-tree bindings documented and really no good examples in existing 
>>> device
>>> trees, although there has been some attempts, e.g. [1] and [2]. Anyway, so 
>>> I send
>>> you a couple of questions instead:
>>>
>>> 1) tcpm uses the port device struct to find a single usb_role_switch but 
>>> there is
>>> room for three USB busses in the Type-C connector; one high speed and two 
>>> (?) super-
>>> speed. These would not all come from the same controller (there might even 
>>> be
>>> separate controllers for host and device mode for each bus).
>>> The case I am working on now only have a single USB2 otg controller so it 
>>> should
>>> be possible to make that driver register a role switch but for other cases?
>>> I imagine it would be possible to create a composite driver as a proxy for 
>>> all role
>>> switches but that would probably be different for every platform/product - 
>>> not
>>> very elegant. Could the role switch infrastructure be extended to handle 
>>> arbitrary
>>> sets of coordinated switches?
>>>
>>> 2) How should the connection between the Type-C port and the switches best 
>>> be
>>> expressed in a device tree? Using graph I presume, but should it be mixed 
>>> into the
>>> existing "usb-connector" or should this be a separate block?
>>> I think it is unfortunate that the graph use numeric addresses that need to 
>>> be
>>> fixed by documentation
>> I also do not like port numbers, I even have argued for using names
>> during multiple discussions, but the discussion ended as is :(
>>
>>> and already I see problems with the current assignment
>>> (0=HS, 1=SS, 2=SBU), e.g. if the host and device mode are handled by 
>>> different
>>> controllers. Graph do support multiple endpoints for one port but then we 
>>> have
>>> another level of magic numbers which does not exactly make things easier
>>> (e.g. 0=dual or host controller, 1=device controller, 2=mode switch).
>> Where do you want to use these magic numbers? To describe endpoints? I
> For some hypothetic worst case scenario where a switch needs to handle
> different USB controllers for port host and device mode. However I think
> Heikki and Hans are correct in saying we should wait to worry about that
> until we have an actual use-case.
>
>> guess there should be controllable mux/switch behind the port, it could
>> be standalone, or a part of bigger IP.
>> Anyway it should be described by device node, probably parent of USB-C
> child?
>
>> device-node, in such case only links from USB connector going to
>> different IPs should be described using OF graphs.
>> And in such case drivers of these devices should
>> ask/determine/change/communicate their role using in-kernel frameworks
>> (for example extcon).
>>
>> There are many different configurations of USB-C ports
>> InterfaceControllers, Muxes/Switches, USB related devices, Alternate
>> Mode devices, PMICs, USB-PDs, 
>> Could you describe particular one you have problem with, to make the
>> discussion more specific.
> My use-case now is simple. I have a typec port that I need to connect to
> a dual-role USB controller, probably extended with a usb-role-switch
> device and I want to express that connection in the device-tree. I was looking
> for a documented description or example of how to do this but I realize that
> that is not yet available.

USB connector bindings [1] are not enough? Did you look at the example?
I do not know what is exactly your usb-role-switch. Can you provide some
schematics? Or describe which physical lines of USB-C connector are
connected to which chips (including muxes/switches).
Two rules of thumb, I think quite simple:
1. Do you have USB interface controller? Ie chip which is connected to
CC lines of USB-C and performs cable detection, maybe PD negotiations,
etc. This device should be the parent of USB connector node.
2. Connections between connector and other chips should be described
using OF graph.

[1]:
https://www.kernel.org/doc/Documentation/devicetree/bindings/connector/usb-connector.txt

Regards
Andrzej

>
> // Mats
>
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB role switches, usb-connector, typec and device trees

[Andrzej Hajda]

On 06.06.2018 23:36, Mats Karrman wrote:
> Hello Gentlemen,
>
> I'm trying to get my head around USB role switches in connection with Type-C 
> ports
> and device-trees. So far I have not found much documentation, e.g. there are 
> no
> device-tree bindings documented and really no good examples in existing device
> trees, although there has been some attempts, e.g. [1] and [2]. Anyway, so I 
> send
> you a couple of questions instead:
>
> 1) tcpm uses the port device struct to find a single usb_role_switch but 
> there is
> room for three USB busses in the Type-C connector; one high speed and two (?) 
> super-
> speed. These would not all come from the same controller (there might even be
> separate controllers for host and device mode for each bus).
> The case I am working on now only have a single USB2 otg controller so it 
> should
> be possible to make that driver register a role switch but for other cases?
> I imagine it would be possible to create a composite driver as a proxy for 
> all role
> switches but that would probably be different for every platform/product - not
> very elegant. Could the role switch infrastructure be extended to handle 
> arbitrary
> sets of coordinated switches?
>
> 2) How should the connection between the Type-C port and the switches best be
> expressed in a device tree? Using graph I presume, but should it be mixed 
> into the
> existing "usb-connector" or should this be a separate block?
> I think it is unfortunate that the graph use numeric addresses that need to be
> fixed by documentation 

I also do not like port numbers, I even have argued for using names
during multiple discussions, but the discussion ended as is :(

> and already I see problems with the current assignment
> (0=HS, 1=SS, 2=SBU), e.g. if the host and device mode are handled by different
> controllers. Graph do support multiple endpoints for one port but then we have
> another level of magic numbers which does not exactly make things easier
> (e.g. 0=dual or host controller, 1=device controller, 2=mode switch).

Where do you want to use these magic numbers? To describe endpoints? I
guess there should be controllable mux/switch behind the port, it could
be standalone, or a part of bigger IP.
Anyway it should be described by device node, probably parent of USB-C
device-node, in such case only links from USB connector going to
different IPs should be described using OF graphs.
And in such case drivers of these devices should
ask/determine/change/communicate their role using in-kernel frameworks
(for example extcon).

There are many different configurations of USB-C ports
InterfaceControllers, Muxes/Switches, USB related devices, Alternate
Mode devices, PMICs, USB-PDs, 
Could you describe particular one you have problem with, to make the
discussion more specific.

Regards
Andrzej

>
> What are your thoughts on this? Please tell me I missed something and that 
> there is
> a simple solution :-)






>
> BR // Mats
>
> [1] https://www.spinics.net/lists/linux-usb/msg168071.html
> [2] https://www.spinics.net/lists/linux-usb/msg168072.html
>
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH linux-next] USB: dwc3: dwc3_get_extcon() can be static

[Andrzej Hajda]

On 18.05.2018 09:38, Roger Quadros wrote:
> On 18/05/18 08:39, Andrzej Hajda wrote:
>> On 17.05.2018 18:06, kbuild test robot wrote:
>>> Fixes: 5f0b74e54890 ("USB: dwc3: get extcon device by OF graph bindings")
>>> Signed-off-by: kbuild test robot <fengguang...@intel.com>
>> It should be static of course, my bad.
>>
>> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
> I don't think we accept patches from robots, yet :)

What do you mean by 'we'? In case of whole kernel it is not true:

$ git log --author='kbuild test robot <fengguang...@intel.com>'
--oneline | wc -l
183

Regards
Andrzej

>
>>  --
>> Regards
>> Andrzej
>>
>>> ---
>>>  drd.c |2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
>>> index 2706824..218371f 100644
>>> --- a/drivers/usb/dwc3/drd.c
>>> +++ b/drivers/usb/dwc3/drd.c
>>> @@ -440,7 +440,7 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
>>> return NOTIFY_DONE;
>>>  }
>>>  
>>> -struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
>>> +static struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
>>>  {
>>> struct device *dev = dwc->dev;
>>> struct device_node *np_phy, *np_conn;
>>>
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH linux-next] USB: dwc3: dwc3_get_extcon() can be static

[Andrzej Hajda]

On 17.05.2018 18:06, kbuild test robot wrote:
> Fixes: 5f0b74e54890 ("USB: dwc3: get extcon device by OF graph bindings")
> Signed-off-by: kbuild test robot <fengguang...@intel.com>

It should be static of course, my bad.

Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>

 --
Regards
Andrzej

> ---
>  drd.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
> index 2706824..218371f 100644
> --- a/drivers/usb/dwc3/drd.c
> +++ b/drivers/usb/dwc3/drd.c
> @@ -440,7 +440,7 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
>   return NOTIFY_DONE;
>  }
>  
> -struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
> +static struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
>  {
>   struct device *dev = dwc->dev;
>   struct device_node *np_phy, *np_conn;
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] USB: dwc3: get extcon device by OF graph bindings

[Andrzej Hajda]

Hi,

This small patchset tries to address issue with broken DT extcon property
in case of USB controller - DWC3. It exposes similar problem as in proposed
USB connector bindings[1] - extcon device is required by devices not always
connected directly to extcon device. Here we have:
DWC3 -> USB-PHY -> MUIC -> USB-connector
   ^
MHL-bridge-^

More details and proposition of generic solution in first patch 

v2:
- rebased on latest linux-next,
- since recently dwc3 fallbacks to ID detection using internal OTG block if
  extcon property is not present, added code allowing to fallback to OTG
  block also in case of graph is not present

[1]: https://marc.info/?i=20180131134435.12216-1-a.hajda%40samsung.com

Regards
Andrzej


Andrzej Hajda (2):
  USB: dwc3: get extcon device by OF graph bindings
  arm64: dts: exynos: add OF graph between USB-PHY and MUIC

 .../dts/exynos/exynos5433-tm2-common.dtsi | 19 ++-
 drivers/usb/dwc3/drd.c| 34 +++
 2 files changed, 46 insertions(+), 7 deletions(-)

-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] USB: dwc3: get extcon device by OF graph bindings

[Andrzej Hajda]

extcon device is used to detect host/device connection. Since extcon
OF property is deprecated, alternative method should be added.
This method uses OF graph bindings to locate extcon.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/usb/dwc3/drd.c | 34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index 1d8c557e97e0..270682486f82 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #include "debug.h"
@@ -439,17 +440,38 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
return NOTIFY_DONE;
 }
 
+struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
+{
+   struct device *dev = dwc->dev;
+   struct device_node *np_phy, *np_conn;
+   struct extcon_dev *edev;
+
+   if (of_property_read_bool(dev->of_node, "extcon"))
+   return extcon_get_edev_by_phandle(dwc->dev, 0);
+
+   np_phy = of_parse_phandle(dev->of_node, "phys", 0);
+   np_conn = of_graph_get_remote_node(np_phy, -1, -1);
+
+   if (np_conn)
+   edev = extcon_find_edev_by_node(np_conn);
+   else
+   edev = NULL;
+
+   of_node_put(np_conn);
+   of_node_put(np_phy);
+
+   return edev;
+}
+
 int dwc3_drd_init(struct dwc3 *dwc)
 {
int ret, irq;
 
-   if (dwc->dev->of_node &&
-   of_property_read_bool(dwc->dev->of_node, "extcon")) {
-   dwc->edev = extcon_get_edev_by_phandle(dwc->dev, 0);
-
-   if (IS_ERR(dwc->edev))
-   return PTR_ERR(dwc->edev);
+   dwc->edev = dwc3_get_extcon(dwc);
+   if (IS_ERR(dwc->edev))
+   return PTR_ERR(dwc->edev);
 
+   if (dwc->edev) {
dwc->edev_nb.notifier_call = dwc3_drd_notifier;
ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
   >edev_nb);
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC

[Andrzej Hajda]

OF graph describes USB data lanes between USB-PHY and respective MUIC.
Since graph is present and DWC driver can use it to get extcon, obsolete
extcon property can be removed.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 .../dts/exynos/exynos5433-tm2-common.dtsi | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 03453b822093..042e5894a138 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -868,6 +868,18 @@
};
};
};
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   muic_to_usb: endpoint {
+   remote-endpoint = 
<_to_muic>;
+   };
+   };
+   };
};
 
regulators {
@@ -1287,12 +1299,17 @@
 
 _dwc3 {
dr_mode = "otg";
-   extcon = <>;
 };
 
 _phy {
vbus-supply = <_reg>;
status = "okay";
+
+   port {
+   usb_to_muic: endpoint {
+   remote-endpoint = <_to_usb>;
+   };
+   };
 };
 
  {
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] USB: dwc3: get extcon device by OF graph bindings

[Andrzej Hajda]

On 31.01.2018 16:57, Andrzej Hajda wrote:
> extcon device is used to detect host/device connection. Since extcon
> OF property is deprecated, alternative method should be added.
> This method uses OF graph bindings to locate extcon.
>
> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>

Ping, 3.5 months passed.

Regards
Andrzej

> ---
> Hi all,
>
> This patch implements alternative method to get extcon from DWC3.
> The code works but is hacky, as DWC3 must traverse different DT nodes
> to get extcon, in case of TM2 it is USB-PHY and MUIC, but other
> platforms can have different paths.
> I would be glad if it can be merged as is for now, but additional work
> must be done to make it generic.
> I guess on DT binding side it is OK. So the problem should be addressed
> in the code.
> My rough idea is to implement kind of extcon aliases/forwarder mechanism,
> ie. USB-PHY will expect on its output remote port extcon, and it should 
> register
> extcon-forwarder pointing to this extcon. This way DWC3 can look for the 
> extcon
> on its PHY phandle, and it will receive via forwarding mechanism extcon
> exposed by MUIC.
> As I said this is rough idea for discussion, other propositions are welcome.
>
> Regards
> Andrzej
> ---
>  drivers/usb/dwc3/drd.c | 41 -
>  1 file changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
> index cc8ab9a8e9d2..eee2eca3d513 100644
> --- a/drivers/usb/dwc3/drd.c
> +++ b/drivers/usb/dwc3/drd.c
> @@ -8,6 +8,7 @@
>   */
>  
>  #include 
> +#include 
>  
>  #include "debug.h"
>  #include "core.h"
> @@ -38,24 +39,38 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
>   return NOTIFY_DONE;
>  }
>  
> +struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
> +{
> + struct device *dev = dwc->dev;
> + struct device_node *np_phy, *np_conn;
> + struct extcon_dev *edev;
> +
> + if (of_property_read_bool(dev->of_node, "extcon"))
> + return extcon_get_edev_by_phandle(dwc->dev, 0);
> +
> + np_phy = of_parse_phandle(dev->of_node, "phys", 0);
> + np_conn = of_graph_get_remote_node(np_phy, -1, -1);
> + edev = extcon_get_edev_by_of_node(np_conn);
> + of_node_put(np_conn);
> + of_node_put(np_phy);
> +
> + return edev;
> +}
> +
>  int dwc3_drd_init(struct dwc3 *dwc)
>  {
>   int ret;
>  
> - if (dwc->dev->of_node) {
> - if (of_property_read_bool(dwc->dev->of_node, "extcon"))
> - dwc->edev = extcon_get_edev_by_phandle(dwc->dev, 0);
> -
> - if (IS_ERR(dwc->edev))
> - return PTR_ERR(dwc->edev);
> + dwc->edev = dwc3_get_extcon(dwc);
> + if (IS_ERR(dwc->edev))
> + return PTR_ERR(dwc->edev);
>  
> - dwc->edev_nb.notifier_call = dwc3_drd_notifier;
> - ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
> ->edev_nb);
> - if (ret < 0) {
> - dev_err(dwc->dev, "couldn't register cable notifier\n");
> - return ret;
> - }
> + dwc->edev_nb.notifier_call = dwc3_drd_notifier;
> + ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
> +>edev_nb);
> + if (ret < 0) {
> + dev_err(dwc->dev, "couldn't register cable notifier\n");
> + return ret;
>   }
>  
>   dwc3_drd_update(dwc);


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 01/13] dt-bindings: connector: add properties for typec

[Andrzej Hajda]

On 28.03.2018 18:06, Li Jun wrote:
> Add bingdings supported by current typec driver, so user can pass
> all those properties via dt.
>
> Signed-off-by: Li Jun 
> ---
>  .../bindings/connector/usb-connector.txt   | 39 
> ++
>  1 file changed, 39 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> index e1463f1..922f22b 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -15,6 +15,29 @@ Optional properties:
>  - type: size of the connector, should be specified in case of USB-A, USB-B
>non-fullsize connectors: "mini", "micro".
>  
> +Optional properties for usb-c-connector:
> +- power-type: should be one of "source", "sink" or "dual"(DRP) if typec
> +  connector has power support.
> +- try-power-role: preferred power role if "dual"(DRP) can support Try.SNK
> +  or Try.SRC, should be "sink" for Try.SNK or "source" for Try.SRC.
> +- data-type: should be one of "host", "device", "dual"(DRD) if typec
> +  connector supports USB data.
> +
> +Required properties for usb-c-connector with power delivery support:
> +- source-pdos: An array of u32 with each entry providing supported power
> +  source data object(PDO), the detailed bit definitions of PDO can be found
> +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> +  Source_Capabilities Message, the order of each entry(PDO) should follow
> +  the PD spec chapter 6.4.1. Required for power source and power dual role.
> +- sink-pdos: An array of u32 with each entry providing supported power
> +  sink data object(PDO), the detailed bit definitions of PDO can be found
> +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
> +  Sink Capabilities Message, the order of each entry(PDO) should follow
> +  the PD spec chapter 6.4.1. Required for power sink and power dual role.
> +- op-sink-microwatt-hours: Sink required operating power in micro
> +  watt-hours, if source offered power is less then it, Capability Mismatch
> +  is set, required for power sink and power dual role.

I have lurked into specs and I am not sure what is the relation of this
field with PD protocol, there is Minimum Operating Power, Maximum
Operating Power and Operating Power present in different RDOs, there are
also similar fields in sink PDOs.
I guess it can be one of them, which one? why other ones are not
provided? What if this or any other property can be calculated only in
runtime?
I am not sure if any of them should be marked "required".

> +
>  Required nodes:
>  - any data bus to the connector should be modeled using the OF graph bindings
>specified in bindings/graph.txt, unless the bus is between parent node and
> @@ -73,3 +96,19 @@ ccic: s2mm005@33 {
>   };
>   };
>  };
> +
> +3. USB-C connector attached to a typec port controller(ptn5110), which has
> +power delivery support and enables drp.
> +
> +typec: ptn5110@50 {
> + ...
> + usb_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";
> + power-type = "dual";
> + try-power-role = "sink";
> + source-pdos = <0x380190c8>;

I understand from DT specification point of view cryptic numbers are OK,
but for sake of readability I strongly suggest use/define macros similar
to the ones present already in kernel:
    source-pdos = < PDO_FIXED(5000, 400, PDO_FIXED_FLAGS) >;

It much less error prone, and makes review process much more easier.

Regards
Andrzej

> + sink-pdos = <0x380190c8 0x3802d0c8>;
> + op-sink-microwatt-hours = <900>;
> + };
> +};


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 12.03.2018 11:41, Roger Quadros wrote:
> Andrezej,
>
> Why don't you have any of the USB maintainers in to/cc?
>
> Greg Kroah-Hartman <gre...@linuxfoundation.org> (supporter:USB SUBSYSTEM)
> Felipe Balbi <ba...@kernel.org> (maintainer:USB GADGET/PERIPHERAL SUBSYSTEM)

Serious omission, sorry for that.

>
> On 12/03/18 09:02, Andrzej Hajda wrote:
>> On 09.03.2018 11:24, Roger Quadros wrote:
>>> Hi,
>>>
>>> On 27/02/18 09:11, Andrzej Hajda wrote:
>>>> These bindings allow to describe most known standard USB connectors
>>>> and it should be possible to extend it if necessary.
>>>> USB connectors, beside USB can be used to route other protocols,
>>>> for example UART, Audio, MHL. In such case every device passing data
>>>> through the connector should have appropriate graph bindings.
>>>>
>>>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>>>> ---
>>>> v4:
>>>> - improved 'type' description (Rob),
>>>> - improved description of 2nd example (Rob).
>>>> v3:
>>>> - removed MHL port (samsung connector will have separate bindings),
>>>> - added 2nd example for USB-C,
>>>> - improved formatting.
>>>> v2:
>>>> - moved connector type(A,B,C) to compatible string (Rob),
>>>> - renamed size property to type (Rob),
>>>> - changed type description to be less confusing (Laurent),
>>>> - removed vendor specific compatibles (implied by graph port number),
>>>> - added requirement of connector being a child of IC (Rob),
>>>> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>>>>   by USB Controller in runtime, downside is that device is not able to
>>>>   report its real capabilities, maybe better would be to make it 
>>>> optional(?)),
>>>> - assigned port numbers to data buses (Rob).
>>>>
>>>> Regards
>>>> Andrzej
>>>> ---
>>>>  .../bindings/connector/usb-connector.txt   | 75 
>>>> ++
>>>>  1 file changed, 75 insertions(+)
>>>>  create mode 100644 
>>>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>>>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>> new file mode 100644
>>>> index ..e1463f14af38
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> Should this lie in  bindings/usb/connector?


I guess this is question for DT people. For me both locations are OK.

>
>>>> @@ -0,0 +1,75 @@
>>>> +USB Connector
>>>> +=
>>>> +
>>>> +USB connector node represents physical USB connector. It should be
>>>> +a child of USB interface controller.
>>>> +
>>>> +Required properties:
>>>> +- compatible: describes type of the connector, must be one of:
>>>> +"usb-a-connector",
>>>> +"usb-b-connector",
>>>> +"usb-c-connector".
>>> compatible should be just "usb-connector"
>>>
>>> Type should be a property
>>>
>>> type: type of usb connector "A", "B", "AB", "C"
>>> AB is for dual-role connectors.
>> I have proposed such property (and size also) in my first RFC [1]. Rod
>> did not like it :)
>>
>> [1]: https://marc.info/?l=devicetree=150660411515233=2
>>
> This is what Rob says here https://patchwork.kernel.org/patch/9976043/
> "We did "type" for hdmi-connector, but I think I'd really prefer 
> compatible be used to distinguish as least where it may matter to s/w. 
> In the HDMI case, they all are pretty much the same, just different 
> physical size."
>
> So the question is. Does it matter to this particular software implementation
> if it is type A,B,C connector?
> If yes, how?

IMHO both approaches can work from S/W POV. As I understood it moving
usb type to compatible was rather matter of devicetree guidelines I am
not aware of. Again question to Rob.

>
> Type A will never have any alternate function. It is always dedicated to USB.
>
> Also does the size "full", "micro", "mini" matter to software?
>
>>> micro super-speed and high-speed connectors are different. How do you 
>>> differentiate tha

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 12.03.2018 08:02, Andrzej Hajda wrote:
> On 09.03.2018 11:24, Roger Quadros wrote:
>> Hi,
>>
>> On 27/02/18 09:11, Andrzej Hajda wrote:
>>> These bindings allow to describe most known standard USB connectors
>>> and it should be possible to extend it if necessary.
>>> USB connectors, beside USB can be used to route other protocols,
>>> for example UART, Audio, MHL. In such case every device passing data
>>> through the connector should have appropriate graph bindings.
>>>
>>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>>> ---
>>> v4:
>>> - improved 'type' description (Rob),
>>> - improved description of 2nd example (Rob).
>>> v3:
>>> - removed MHL port (samsung connector will have separate bindings),
>>> - added 2nd example for USB-C,
>>> - improved formatting.
>>> v2:
>>> - moved connector type(A,B,C) to compatible string (Rob),
>>> - renamed size property to type (Rob),
>>> - changed type description to be less confusing (Laurent),
>>> - removed vendor specific compatibles (implied by graph port number),
>>> - added requirement of connector being a child of IC (Rob),
>>> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>>>   by USB Controller in runtime, downside is that device is not able to
>>>   report its real capabilities, maybe better would be to make it 
>>> optional(?)),
>>> - assigned port numbers to data buses (Rob).
>>>
>>> Regards
>>> Andrzej
>>> ---
>>>  .../bindings/connector/usb-connector.txt   | 75 
>>> ++
>>>  1 file changed, 75 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> new file mode 100644
>>> index ..e1463f14af38
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> @@ -0,0 +1,75 @@
>>> +USB Connector
>>> +=
>>> +
>>> +USB connector node represents physical USB connector. It should be
>>> +a child of USB interface controller.
>>> +
>>> +Required properties:
>>> +- compatible: describes type of the connector, must be one of:
>>> +"usb-a-connector",
>>> +"usb-b-connector",
>>> +"usb-c-connector".
>> compatible should be just "usb-connector"
>>
>> Type should be a property
>>
>> type: type of usb connector "A", "B", "AB", "C"
>> AB is for dual-role connectors.
> I have proposed such property (and size also) in my first RFC [1]. Rod
> did not like it :)

Ups, ugly typo, I meant Rob, of course.

Regards
Andrzej

>
> [1]: https://marc.info/?l=devicetree=150660411515233=2
>
>
>> micro super-speed and high-speed connectors are different. How do you 
>> differentiate that?
> I am aware of it, and property differentiating it was also in my earlier
> iterations.
> If there will be need to differentiate such connectors, adding property
> max-speed or max-mode would do the thing.
>
>>> +
>>> +Optional properties:
>>> +- label: symbolic name for the connector,
>> Why do you need label? We can't maintain consistency as people will put 
>> creative names there.
>> Device/bus driver could generate a valid label.
> It follows convention for other connectors: HDMI, DVI, 
>
>>> +- type: size of the connector, should be specified in case of USB-A, USB-B
>>> +  non-fullsize connectors: "mini", "micro".
>> type is misleading. Type is usually A/B/C. It should be size here instead.
> As you can see in discussion for previous iterations it follows
> convention already established for other connectors.
>
>> size: size of the connector if not standard size. "mini", "micro"
>>
>> If not specified it is treated as standard sized connector.
>> e.g. for Type-C there is no mini/micro. so size doesn't have to be specificed
> Few lines above it is described: should be specified in case of USB-A,
> USB-B non-fullsize connectors.
>
>> What about Type-C connector?
>>> +
>>> +Required nodes:
>>> +- any data bus to the connector should be modeled using the OF graph 
>>> bindings
>> s/modeled/modelle

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 09.03.2018 11:24, Roger Quadros wrote:
> Hi,
>
> On 27/02/18 09:11, Andrzej Hajda wrote:
>> These bindings allow to describe most known standard USB connectors
>> and it should be possible to extend it if necessary.
>> USB connectors, beside USB can be used to route other protocols,
>> for example UART, Audio, MHL. In such case every device passing data
>> through the connector should have appropriate graph bindings.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>> v4:
>> - improved 'type' description (Rob),
>> - improved description of 2nd example (Rob).
>> v3:
>> - removed MHL port (samsung connector will have separate bindings),
>> - added 2nd example for USB-C,
>> - improved formatting.
>> v2:
>> - moved connector type(A,B,C) to compatible string (Rob),
>> - renamed size property to type (Rob),
>> - changed type description to be less confusing (Laurent),
>> - removed vendor specific compatibles (implied by graph port number),
>> - added requirement of connector being a child of IC (Rob),
>> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>>   by USB Controller in runtime, downside is that device is not able to
>>   report its real capabilities, maybe better would be to make it 
>> optional(?)),
>> - assigned port numbers to data buses (Rob).
>>
>> Regards
>> Andrzej
>> ---
>>  .../bindings/connector/usb-connector.txt   | 75 
>> ++
>>  1 file changed, 75 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>
>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> new file mode 100644
>> index ..e1463f14af38
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> @@ -0,0 +1,75 @@
>> +USB Connector
>> +=
>> +
>> +USB connector node represents physical USB connector. It should be
>> +a child of USB interface controller.
>> +
>> +Required properties:
>> +- compatible: describes type of the connector, must be one of:
>> +"usb-a-connector",
>> +"usb-b-connector",
>> +"usb-c-connector".
> compatible should be just "usb-connector"
>
> Type should be a property
>
> type: type of usb connector "A", "B", "AB", "C"
> AB is for dual-role connectors.

I have proposed such property (and size also) in my first RFC [1]. Rod
did not like it :)

[1]: https://marc.info/?l=devicetree=150660411515233=2


>
> micro super-speed and high-speed connectors are different. How do you 
> differentiate that?

I am aware of it, and property differentiating it was also in my earlier
iterations.
If there will be need to differentiate such connectors, adding property
max-speed or max-mode would do the thing.

>
>> +
>> +Optional properties:
>> +- label: symbolic name for the connector,
> Why do you need label? We can't maintain consistency as people will put 
> creative names there.
> Device/bus driver could generate a valid label.

It follows convention for other connectors: HDMI, DVI, 

>
>> +- type: size of the connector, should be specified in case of USB-A, USB-B
>> +  non-fullsize connectors: "mini", "micro".
> type is misleading. Type is usually A/B/C. It should be size here instead.

As you can see in discussion for previous iterations it follows
convention already established for other connectors.

>
> size: size of the connector if not standard size. "mini", "micro"
>
> If not specified it is treated as standard sized connector.
> e.g. for Type-C there is no mini/micro. so size doesn't have to be specificed
Few lines above it is described: should be specified in case of USB-A,
USB-B non-fullsize connectors.

>
> What about Type-C connector?
>> +
>> +Required nodes:
>> +- any data bus to the connector should be modeled using the OF graph 
>> bindings
> s/modeled/modelled

>> +  specified in bindings/graph.txt, unless the bus is between parent node and
>> +  the connector. Since single connector can have multpile data buses every 
>> bus
> s/multpile/multiple

OK, I will fix both typos.

>
>> +  has assigned OF graph port number as follows:
>> +0: High Speed (HS), present in all connectors,
>> +1: Super Speed (SS), present in SS capable connectors,
>> +2: Sideband use (SBU), present in USB-C.
>> +
>&

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi Chanwoo,

On 08.03.2018 02:52, Chanwoo Choi wrote:
> Hi Andrzej, Archit,
>
> On 2018년 03월 07일 20:13, Andrzej Hajda wrote:
>> Hi Chanwoo, Archit,
>>
>> On 07.03.2018 05:48, Chanwoo Choi wrote:
>>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
>>>> Hi Rob and Andrzej,
>>>>
>>>> On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
>>>>> Hi Rob, Chanwoo, Krzysztof,
>>>>>
>>>>>
>>>>> On 27.02.2018 08:11, Andrzej Hajda wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Thanks for reviews of previous iterations.
>>>>>>
>>>>>> This patchset introduces USB physical connector bindings, together with
>>>>>> working example.
>>>>>> I have removed RFC prefix - the patchset seems to be heading
>>>>>> to a happy end :)
>>>>>>
>>>>>> v5: fixed extra parenthesis in dts, renamed extcon function.
>>>>>> v4: improved binding descriptions, added missing reg in dts.
>>>>>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
>>>>>> example.
>>>>>> v2: I have addressed comments by Rob and Laurent, thanks 
>>>>>>
>>>>>> Changes in datail are described in the patches.
>>>>>>
>>>>>> Regards
>>>>>> Andrzej
>>>>>>
>>>>>>
>>>>>> Andrzej Hajda (5):
>>>>>>   dt-bindings: add bindings for USB physical connector
>>>>>>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>>>>>>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>>>>>>   arm64: dts: exynos: add OF graph between MHL and USB connector
>>>>>>   extcon: add possibility to get extcon device by OF node
>>>>>>
>>>>>> Maciej Purski (1):
>>>>>>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
>>>>> It looks like all patches received R-B or acks (I forgot add Krzysztof's
>>>>> acks for dts part).
>>>>> Now I have a question how to merge them.
>>>>> The only functional dependency is between bridge and extcon, and from
>>>>> the formal PoV bindings should be merged 1st.
>>>>> I can merge it:
>>>>> 1. All patches via drm-misc tree.
>>>>> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
>>>>> samsung-soc tree.
>>>>>
>>>>> Is it OK, for all? Better ideas?
>>>> Krzysztof picked the dts patches. I'll make the immutable branch based on 
>>>> v4.16-rc1
>>>> and apply them except for dts patchs. And I'll send the immutable branch 
>>>> to Rob and Andrzej.
>>>>
>>>>
>>> I made the immutable branch[1] as following: If you agree, I'll send pull 
>>> request.
>>> [1] 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17
>>>
>>> Or you can make the immutable branch and send pull request to Rob and me.
>>>
>> It seems you took v5 instead of v6 version of extcon patch.
> My mistake. I picked v6 and made the new immutable branch.
> After Archit confirm it, I'll send pull request.
>


Lets just queue all patches (except dts) via extcon branch (thanks
Daniel for advice), without making immutable branch.
It seems to be a simplest acceptable approach.

You can add my ack to sii8620 bridge patch (as bridge maintainer), to
fulfill process requirements.

Regards
Andrzej

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 07.03.2018 12:22, Krzysztof Kozlowski wrote:
> On Wed, Mar 7, 2018 at 12:13 PM, Andrzej Hajda <a.ha...@samsung.com> wrote:
>> Hi Chanwoo, Archit,
>>
>> On 07.03.2018 05:48, Chanwoo Choi wrote:
>>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
>>>> Hi Rob and Andrzej,
>>>>
>>>> On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
>>>>> Hi Rob, Chanwoo, Krzysztof,
>>>>>
>>>>>
>>>>> On 27.02.2018 08:11, Andrzej Hajda wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Thanks for reviews of previous iterations.
>>>>>>
>>>>>> This patchset introduces USB physical connector bindings, together with
>>>>>> working example.
>>>>>> I have removed RFC prefix - the patchset seems to be heading
>>>>>> to a happy end :)
>>>>>>
>>>>>> v5: fixed extra parenthesis in dts, renamed extcon function.
>>>>>> v4: improved binding descriptions, added missing reg in dts.
>>>>>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
>>>>>> example.
>>>>>> v2: I have addressed comments by Rob and Laurent, thanks
>>>>>>
>>>>>> Changes in datail are described in the patches.
>>>>>>
>>>>>> Regards
>>>>>> Andrzej
>>>>>>
>>>>>>
>>>>>> Andrzej Hajda (5):
>>>>>>   dt-bindings: add bindings for USB physical connector
>>>>>>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>>>>>>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>>>>>>   arm64: dts: exynos: add OF graph between MHL and USB connector
>>>>>>   extcon: add possibility to get extcon device by OF node
>>>>>>
>>>>>> Maciej Purski (1):
>>>>>>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
>>>>> It looks like all patches received R-B or acks (I forgot add Krzysztof's
>>>>> acks for dts part).
>>>>> Now I have a question how to merge them.
>>>>> The only functional dependency is between bridge and extcon, and from
>>>>> the formal PoV bindings should be merged 1st.
>>>>> I can merge it:
>>>>> 1. All patches via drm-misc tree.
>>>>> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
>>>>> samsung-soc tree.
>>>>>
>>>>> Is it OK, for all? Better ideas?
>>>> Krzysztof picked the dts patches. I'll make the immutable branch based on 
>>>> v4.16-rc1
>>>> and apply them except for dts patchs. And I'll send the immutable branch 
>>>> to Rob and Andrzej.
>>>>
>>>>
>>> I made the immutable branch[1] as following: If you agree, I'll send pull 
>>> request.
>>> [1] 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17
>>>
>>> Or you can make the immutable branch and send pull request to Rob and me.
>>>
>> It seems you took v5 instead of v6 version of extcon patch.
> I also took v5:
> https://patchwork.kernel.org/patch/10244407/
> https://patchwork.kernel.org/patch/10244431/
>
> There was no v6 in samsung-soc patchwork. Is it a problem for DTS?

No, v6 was only typo fix in comment, and only extcon patch has v6.

Regards
Andrzej

>
> BR,
> Krzysztof
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi Chanwoo, Archit,

On 07.03.2018 05:48, Chanwoo Choi wrote:
> On 2018년 03월 07일 11:12, Chanwoo Choi wrote:
>> Hi Rob and Andrzej,
>>
>> On 2018년 03월 06일 21:53, Andrzej Hajda wrote:
>>> Hi Rob, Chanwoo, Krzysztof,
>>>
>>>
>>> On 27.02.2018 08:11, Andrzej Hajda wrote:
>>>> Hi,
>>>>
>>>> Thanks for reviews of previous iterations.
>>>>
>>>> This patchset introduces USB physical connector bindings, together with
>>>> working example.
>>>> I have removed RFC prefix - the patchset seems to be heading
>>>> to a happy end :)
>>>>
>>>> v5: fixed extra parenthesis in dts, renamed extcon function.
>>>> v4: improved binding descriptions, added missing reg in dts.
>>>> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
>>>> example.
>>>> v2: I have addressed comments by Rob and Laurent, thanks 
>>>>
>>>> Changes in datail are described in the patches.
>>>>
>>>> Regards
>>>> Andrzej
>>>>
>>>>
>>>> Andrzej Hajda (5):
>>>>   dt-bindings: add bindings for USB physical connector
>>>>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>>>>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>>>>   arm64: dts: exynos: add OF graph between MHL and USB connector
>>>>   extcon: add possibility to get extcon device by OF node
>>>>
>>>> Maciej Purski (1):
>>>>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
>>> It looks like all patches received R-B or acks (I forgot add Krzysztof's
>>> acks for dts part).
>>> Now I have a question how to merge them.
>>> The only functional dependency is between bridge and extcon, and from
>>> the formal PoV bindings should be merged 1st.
>>> I can merge it:
>>> 1. All patches via drm-misc tree.
>>> 2. All patches except dts via drm-misc, and Krzysztof will merge dts via
>>> samsung-soc tree.
>>>
>>> Is it OK, for all? Better ideas?
>> Krzysztof picked the dts patches. I'll make the immutable branch based on 
>> v4.16-rc1
>> and apply them except for dts patchs. And I'll send the immutable branch to 
>> Rob and Andrzej.
>>
>>
> I made the immutable branch[1] as following: If you agree, I'll send pull 
> request.
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git/log/?h=ib-extcon-drm-dt-v4.17
>
> Or you can make the immutable branch and send pull request to Rob and me.
>

It seems you took v5 instead of v6 version of extcon patch.

Beside it I am OK with your immutable branch, Archit is it OK to do it
this way in drm-misc?


Regards

Andrzej



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi Rob, Chanwoo, Krzysztof,


On 27.02.2018 08:11, Andrzej Hajda wrote:
> Hi,
>
> Thanks for reviews of previous iterations.
>
> This patchset introduces USB physical connector bindings, together with
> working example.
> I have removed RFC prefix - the patchset seems to be heading
> to a happy end :)
>
> v5: fixed extra parenthesis in dts, renamed extcon function.
> v4: improved binding descriptions, added missing reg in dts.
> v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
> example.
> v2: I have addressed comments by Rob and Laurent, thanks 
>
> Changes in datail are described in the patches.
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (5):
>   dt-bindings: add bindings for USB physical connector
>   dt-bindings: add bindings for Samsung micro-USB 11-pin connector
>   arm64: dts: exynos: add micro-USB connector node to TM2 platforms
>   arm64: dts: exynos: add OF graph between MHL and USB connector
>   extcon: add possibility to get extcon device by OF node
>
> Maciej Purski (1):
>   drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

It looks like all patches received R-B or acks (I forgot add Krzysztof's
acks for dts part).
Now I have a question how to merge them.
The only functional dependency is between bridge and extcon, and from
the formal PoV bindings should be merged 1st.
I can merge it:
1. All patches via drm-misc tree.
2. All patches except dts via drm-misc, and Krzysztof will merge dts via
samsung-soc tree.

Is it OK, for all? Better ideas?

Regards
Andrzej


>
>  .../connector/samsung,usb-connector-11pin.txt  | 49 +++
>  .../bindings/connector/usb-connector.txt   | 75 +
>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 38 -
>  drivers/extcon/extcon.c| 44 +++---
>  drivers/gpu/drm/bridge/sil-sii8620.c   | 97 
> +-
>  include/linux/extcon.h |  6 ++
>  6 files changed, 293 insertions(+), 16 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
>  create mode 100644 
> Documentation/devicetree/bindings/connector/usb-connector.txt
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Andrzej Hajda]

On 06.03.2018 10:38, Jun Li wrote:
> Hi
>> -Original Message-
>> From: Andrzej Hajda [mailto:a.ha...@samsung.com]
>> Sent: 2018年3月5日 17:59
>> To: Jun Li <jun...@nxp.com>; gre...@linuxfoundation.org;
>> robh...@kernel.org; heikki.kroge...@linux.intel.com; li...@roeck-us.net
>> Cc: mark.rutl...@arm.com; yue...@google.com; Peter Chen
>> <peter.c...@nxp.com>; garsi...@embeddedor.com; o_leve...@orange.fr;
>> shufan_...@richtek.com; linux-usb@vger.kernel.org;
>> devicet...@vger.kernel.org; dl-linux-imx <linux-...@nxp.com>
>> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
>> typec power delivery
>>
>> On 05.03.2018 08:00, Jun Li wrote:
>>>> -Original Message-
>>>> From: Andrzej Hajda [mailto:a.ha...@samsung.com]
>>>> Sent: 2018年2月27日 16:41
>>>> To: Jun Li <jun...@nxp.com>; gre...@linuxfoundation.org;
>>>> robh...@kernel.org; heikki.kroge...@linux.intel.com;
>>>> robh+li...@roeck-us.net
>>>> Cc: mark.rutl...@arm.com; yue...@google.com; Peter Chen
>>>> <peter.c...@nxp.com>; garsi...@embeddedor.com;
>> o_leve...@orange.fr;
>>>> shufan_...@richtek.com; linux-usb@vger.kernel.org;
>>>> devicet...@vger.kernel.org; dl-linux-imx <linux-...@nxp.com>
>>>> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties
>>>> for typec power delivery
>>>>
>>>> On 26.02.2018 12:49, Li Jun wrote:
>>>>> In case of usb-c-connector with power delivery support, add
>>>>> bingdings supported by current typec driver, so user can pass all
>>>>> those properties via dt.
>>>>>
>>>>> Signed-off-by: Li Jun <jun...@nxp.com>
>>>>> ---
>>>>> Changes for v2:
>>>>> - Added typec properties are based on general usb connector bindings[1]
>>>>>   proposed by Andrzej Hajda.
>>>>> - Use the standard unit suffixes as defined in property-units.txt.
>>>>>
>>>>> [1]
>>>>>
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
>>>> t
>>>>
>> chwork.kernel.org%2Fpatch%2F10231447%2F=02%7C01%7Cjun.li%40
>>>> nxp.co
>>>>
>> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
>>>> c5c30163
>>>>
>> 5%7C0%7C0%7C636553176880292197=2Pi0AtiwAqHQE3rGl%2Bo49K
>>>> 7yZZcp%2B
>>>>> 5bvJAknRBMGTrk%3D=0
>>>>>
>>>>>  .../bindings/connector/usb-connector.txt   | 43
>>>> ++
>>>>>  1 file changed, 43 insertions(+)
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> index e1463f1..242f6df 100644
>>>>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> +++
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> @@ -15,6 +15,30 @@ Optional properties:
>>>>>  - type: size of the connector, should be specified in case of USB-A,
>> USB-B
>>>>>non-fullsize connectors: "mini", "micro".
>>>>>
>>>>> +Required properties for usb-c-connector with power delivery support:
>>>>> +- port-type: should be one of "source", "sink" or "dual".
>>>>> +- default-role: preferred power role if port-type is "dual"(drp),
>>>>> +should be
>>>>> +  "sink" or "source".
>>>> Since port carries data and power, it would be better to explicitly
>>>> mention it in names of properties which can be ambiguous.
>>>> Maybe instead of 'port-type' you can use 'power-role', for example.
>>> Port-type is align with the name of typec coding and ABI, 'power-role'
>>> is more like for the current role rather than the port's ability.
>> I am not sure what are you exactly mean by "coding and ABI", but I guess it 
>> is
>> just about Power-Delivery part of USB-C. And if you want to put this property
>> into USB node without mark it is related to PD part of USB connector, you
>> risk confusion with possible USB data related properties.
> Understood your concern, I am following typec naming conventions,
> for typec, port-type property has the same meaning as
> /sys/class/typec

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Andrzej Hajda]

On 05.03.2018 08:00, Jun Li wrote:
>
>> -Original Message-
>> From: Andrzej Hajda [mailto:a.ha...@samsung.com]
>> Sent: 2018年2月27日 16:41
>> To: Jun Li <jun...@nxp.com>; gre...@linuxfoundation.org;
>> robh...@kernel.org; heikki.kroge...@linux.intel.com; li...@roeck-us.net
>> Cc: mark.rutl...@arm.com; yue...@google.com; Peter Chen
>> <peter.c...@nxp.com>; garsi...@embeddedor.com; o_leve...@orange.fr;
>> shufan_...@richtek.com; linux-usb@vger.kernel.org;
>> devicet...@vger.kernel.org; dl-linux-imx <linux-...@nxp.com>
>> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
>> typec power delivery
>>
>> On 26.02.2018 12:49, Li Jun wrote:
>>> In case of usb-c-connector with power delivery support, add bingdings
>>> supported by current typec driver, so user can pass all those
>>> properties via dt.
>>>
>>> Signed-off-by: Li Jun <jun...@nxp.com>
>>> ---
>>> Changes for v2:
>>> - Added typec properties are based on general usb connector bindings[1]
>>>   proposed by Andrzej Hajda.
>>> - Use the standard unit suffixes as defined in property-units.txt.
>>>
>>> [1]
>>>
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
>> chwork.kernel.org%2Fpatch%2F10231447%2F=02%7C01%7Cjun.li%40
>> nxp.co
>> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
>> c5c30163
>> 5%7C0%7C0%7C636553176880292197=2Pi0AtiwAqHQE3rGl%2Bo49K
>> 7yZZcp%2B
>>> 5bvJAknRBMGTrk%3D=0
>>>
>>>  .../bindings/connector/usb-connector.txt   | 43
>> ++
>>>  1 file changed, 43 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> index e1463f1..242f6df 100644
>>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> @@ -15,6 +15,30 @@ Optional properties:
>>>  - type: size of the connector, should be specified in case of USB-A, USB-B
>>>non-fullsize connectors: "mini", "micro".
>>>
>>> +Required properties for usb-c-connector with power delivery support:
>>> +- port-type: should be one of "source", "sink" or "dual".
>>> +- default-role: preferred power role if port-type is "dual"(drp),
>>> +should be
>>> +  "sink" or "source".
>> Since port carries data and power, it would be better to explicitly mention 
>> it
>> in names of properties which can be ambiguous.
>> Maybe instead of 'port-type' you can use 'power-role', for example.
> Port-type is align with the name of typec coding and ABI, 'power-role'
> is more like for the current role rather than the port's ability.

I am not sure what are you exactly mean by "coding and ABI", but I guess
it is just about Power-Delivery part of USB-C. And if you want to put
this property into USB node without mark it is related to PD part of USB
connector, you risk confusion with possible USB data related properties.
Simple question, what if somebody wants to add property describing USB
data capabilities (DFP, UFP, DRD), how should it be named?

>
>> Other thing is that default-role is required only in case of DRP, so maybe
>> better would be to squash it in power-role, for example:
>>     power-role: should be on of "source", "sink", "dual-source", "dual-sink",
>> in case of dual roles suffix determines preferred role.
> I don't know how much this squash can benefit, "dual-source/sink" is not
> directly showing its meaning by name.

Some benefit is simpler binding, no conditionally-required property.

Another question is that USB TypeC specification describes 7 different
"behavioral models" [1]:
- Source-only
- Source (Default) – strong preference toward being a Source but
subsequently
capable of becoming a Sink using USB PD swap mechanisms.
- Sink-only
- Sink (Default) – strong preference toward being a Sink but
subsequently capable of
becoming a Source using USB PD swap mechanisms.
- DRP: Toggling (Source/Sink)
- DRP: Sourcing Device
- DRP: Sinking Host

How it maps to your proposed props?

[1]: USB Type-C specification release 1.3, chapter 4.5.1.4.

Regards
Andrzej

>
>>
>>> +- src-pdos: An array of u32 with each entry providing supported power
>>> +  source data object(PDO), the detailed bit definitions of PDO can be
>>> +found
&g

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 02.03.2018 14:13, Heikki Krogerus wrote:
> Hi,
>
> On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote:
>> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
>> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
>> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
>> +
>> +ccic: s2mm005@33 {
>> +...
>> +usb_con: connector {
>> +compatible = "usb-c-connector";
>> +label = "USB-C";
> Is this child node really necessary? There will never be more then
> one connector per CC line.

But there can be more connectors/cc-lines per IC, for example EZ-PD CCG5[1].

[1]:
http://www.cypress.com/products/ez-pd-ccg5-two-port-usb-type-c-and-power-delivery

>
> We should prefer device_graph* functions over of_graph* and
I guess you mean fwnode_graph* functions.
> acpi_graph* functions in the drivers so we don't have to handle the
> same thing multiple times with separate APIs. Is it still possible if
> there is that connector child node?

Bindings proposed here are OF bindings, I suppose the most important is
to follow OF specification and guidelines and these bindings tries to
follow it.
It looks like it should not be a problem for fwnode framework to handle
such bindings, but it is just my guess. I have not seen any fwnode*
specification I am not sure what is the real purpose of this framework,
but it seems to be just in-kernel abstraction for different firmware
standards (OF, ACPI), so even if it lacks at the moment some
functionality it should not be a barrier for OF bindings.

Regards
Andrzej

>
>> +ports {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +port@0 {
>> +reg = <0>;
>> +usb_con_hs: endpoint {
>> +remote-endpoint = <_usbc_hs>;
>> +};
>> +};
>> +port@1 {
>> +reg = <1>;
>> +usb_con_ss: endpoint {
>> +remote-endpoint = <_phy_ss>;
>> +};
>> +};
>> +port@2 {
>> +reg = <2>;
>> +usb_con_sbu: endpoint {
>> +remote-endpoint = <_aux>;
>> +};
>> +};
>> +};
>> +};
>> +};
>
> Thanks,
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

On 27.02.2018 23:26, Chanwoo Choi wrote:
> Hi,
>
> On 2018년 02월 27일 21:05, Andrzej Hajda wrote:
>> On 27.02.2018 12:08, Chanwoo Choi wrote:
>>> Hi,
>>>
>>> On 2018년 02월 27일 16:11, Andrzej Hajda wrote:
>>>> From: Maciej Purski <m.pur...@samsung.com>
>>>>
>>>> Currently MHL chip must be turned on permanently to detect MHL cable. It
>>>> duplicates micro-USB controller's (MUIC) functionality and consumes
>>>> unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
>>>> only if it detects MHL cable.
>>>>
>>>> Signed-off-by: Maciej Purski <m.pur...@samsung.com>
>>>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>>>> ---
>>>> v5: updated extcon API
>>>>
>>>> This is rework of the patch by Maciej with following changes:
>>>> - use micro-USB port bindings to get extcon, instead of extcon property,
>>>> - fixed remove sequence,
>>>> - fixed extcon get state logic.
>>>>
>>>> Code finding extcon node is hacky IMO, I guess ultimately it should be done
>>>> via some framework (maybe even extcon), or at least via helper, I hope it
>>>> can stay as is until the proper solution will be merged.
>>>>
>>>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>>>> ---
>>>>  drivers/gpu/drm/bridge/sil-sii8620.c | 97 
>>>> ++--
>>>>  1 file changed, 94 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
>>>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>>>> index 9e785b8e0ea2..62b0adabcac2 100644
>>>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>>>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>>>> @@ -17,6 +17,7 @@
>>>>  
>>>>  #include 
>>>>  #include 
>>>> +#include 
>>>>  #include 
>>>>  #include 
>>>>  #include 
>>>> @@ -25,6 +26,7 @@
>>>>  #include 
>>>>  #include 
>>>>  #include 
>>>> +#include 
>>>>  #include 
>>>>  #include 
>>>>  
>>>> @@ -81,6 +83,10 @@ struct sii8620 {
>>>>struct edid *edid;
>>>>unsigned int gen2_write_burst:1;
>>>>enum sii8620_mt_state mt_state;
>>>> +  struct extcon_dev *extcon;
>>>> +  struct notifier_block extcon_nb;
>>>> +  struct work_struct extcon_wq;
>>>> +  int cable_state;
>>>>struct list_head mt_queue;
>>>>struct {
>>>>int r_size;
>>>> @@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct 
>>>> sii8620 *ctx)
>>>>ctx->rc_dev = rc_dev;
>>>>  }
>>>>  
>>>> +static void sii8620_cable_out(struct sii8620 *ctx)
>>>> +{
>>>> +  disable_irq(to_i2c_client(ctx->dev)->irq);
>>>> +  sii8620_hw_off(ctx);
>>>> +}
>>>> +
>>>> +static void sii8620_extcon_work(struct work_struct *work)
>>>> +{
>>>> +  struct sii8620 *ctx =
>>>> +  container_of(work, struct sii8620, extcon_wq);
>>>> +  int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
>>>> +
>>>> +  if (state == ctx->cable_state)
>>>> +  return;
>>>> +
>>>> +  ctx->cable_state = state;
>>>> +
>>>> +  if (state > 0)
>>>> +  sii8620_cable_in(ctx);
>>>> +  else
>>>> +  sii8620_cable_out(ctx);
>>>> +}
>>>> +
>>>> +static int sii8620_extcon_notifier(struct notifier_block *self,
>>>> +  unsigned long event, void *ptr)
>>>> +{
>>>> +  struct sii8620 *ctx =
>>>> +  container_of(self, struct sii8620, extcon_nb);
>>>> +
>>>> +  schedule_work(>extcon_wq);
>>>> +
>>>> +  return NOTIFY_DONE;
>>>> +}
>>>> +
>>>> +static int sii8620_extcon_init(struct sii8620 *ctx)
>>>> +{
>>>> +  struct extcon_dev *edev;
>>>> +  struct device_node *musb, *muic;
>>>> +  int ret;
>>>> +
>>>> +  /* get micro-USB connector node */
>>>> +  musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
>>>> +  /* next get micro-USB Interface Contro

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

On 27.02.2018 22:24, Rob Herring wrote:
> On Wed, Feb 21, 2018 at 2:55 AM, Andrzej Hajda <a.ha...@samsung.com> wrote:
>> OF graph describes MHL data lanes between MHL and respective USB
>> connector.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>> v4:
>> - added missing reg property in connector's port node (Krzysztof)
>> ---
>>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 32 
>> --
>>  1 file changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> index f604f6b1a9c2..2ed506df94d0 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> @@ -817,9 +817,22 @@
>> clocks = <_system_controller 0>;
>> clock-names = "xtal";
>>
>> -   port {
>> -   mhl_to_hdmi: endpoint {
>> -   remote-endpoint = <_to_mhl>;
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   port@0 {
>> +   reg = <0>;
>> +   mhl_to_hdmi: endpoint {
>> +   remote-endpoint = <_to_mhl>;
>> +   };
>> +   };
>> +
>> +   port@1 {
>> +   reg = <1>;
>> +   mhl_to_musb_con: endpoint {
>> +   remote-endpoint = <_con_to_mhl>;
>> +   };
> These ports are mutually exclusive, right? If so, it should be 1 port
> with 2 endpoints. Ports should represent independent data flows.
> Something muxed or replicated (1 to many connection) should be be
> endpoints.

No, this is HDMI -> MHL bridge, so port 0 is HDMI input, and port 1 is
MHL output.

Regards
Andrzej

>
> Rob
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 5/6] extcon: add possibility to get extcon device by OF node

[Andrzej Hajda]

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
Acked-by: Chanwoo Choi <cw00.c...@samsung.com>
---
v5: function renamed to extcon_find_edev_by_node (Andy)
v2: changed label to follow local convention (Chanwoo)
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..8bff5fd18185 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_find_edev_by_node - Find the extcon device from devicetree.
+ * @node   : OF node identifying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(_dev_list_lock);
+   list_for_each_entry(edev, _dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto out;
+   edev = ERR_PTR(-EPROBE_DEFER);
+out:
+   mutex_unlock(_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(_dev_list_lock);
-   list_for_each_entry(edev, _dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(_dev_list_lock);
+   edev = extcon_find_edev_by_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_find_edev_by_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 6d94e82c8ad9..7f033b1ea568 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_find_edev_by_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -283,6 +284,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_find_edev_by_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
2.16.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

On 27.02.2018 12:08, Chanwoo Choi wrote:
> Hi,
>
> On 2018년 02월 27일 16:11, Andrzej Hajda wrote:
>> From: Maciej Purski <m.pur...@samsung.com>
>>
>> Currently MHL chip must be turned on permanently to detect MHL cable. It
>> duplicates micro-USB controller's (MUIC) functionality and consumes
>> unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
>> only if it detects MHL cable.
>>
>> Signed-off-by: Maciej Purski <m.pur...@samsung.com>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>> v5: updated extcon API
>>
>> This is rework of the patch by Maciej with following changes:
>> - use micro-USB port bindings to get extcon, instead of extcon property,
>> - fixed remove sequence,
>> - fixed extcon get state logic.
>>
>> Code finding extcon node is hacky IMO, I guess ultimately it should be done
>> via some framework (maybe even extcon), or at least via helper, I hope it
>> can stay as is until the proper solution will be merged.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>>  drivers/gpu/drm/bridge/sil-sii8620.c | 97 
>> ++--
>>  1 file changed, 94 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>> index 9e785b8e0ea2..62b0adabcac2 100644
>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>> @@ -17,6 +17,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -25,6 +26,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -81,6 +83,10 @@ struct sii8620 {
>>  struct edid *edid;
>>  unsigned int gen2_write_burst:1;
>>  enum sii8620_mt_state mt_state;
>> +struct extcon_dev *extcon;
>> +struct notifier_block extcon_nb;
>> +struct work_struct extcon_wq;
>> +int cable_state;
>>  struct list_head mt_queue;
>>  struct {
>>  int r_size;
>> @@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620 
>> *ctx)
>>  ctx->rc_dev = rc_dev;
>>  }
>>  
>> +static void sii8620_cable_out(struct sii8620 *ctx)
>> +{
>> +disable_irq(to_i2c_client(ctx->dev)->irq);
>> +sii8620_hw_off(ctx);
>> +}
>> +
>> +static void sii8620_extcon_work(struct work_struct *work)
>> +{
>> +struct sii8620 *ctx =
>> +container_of(work, struct sii8620, extcon_wq);
>> +int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
>> +
>> +if (state == ctx->cable_state)
>> +return;
>> +
>> +ctx->cable_state = state;
>> +
>> +if (state > 0)
>> +sii8620_cable_in(ctx);
>> +else
>> +sii8620_cable_out(ctx);
>> +}
>> +
>> +static int sii8620_extcon_notifier(struct notifier_block *self,
>> +unsigned long event, void *ptr)
>> +{
>> +struct sii8620 *ctx =
>> +container_of(self, struct sii8620, extcon_nb);
>> +
>> +schedule_work(>extcon_wq);
>> +
>> +return NOTIFY_DONE;
>> +}
>> +
>> +static int sii8620_extcon_init(struct sii8620 *ctx)
>> +{
>> +struct extcon_dev *edev;
>> +struct device_node *musb, *muic;
>> +int ret;
>> +
>> +/* get micro-USB connector node */
>> +musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
>> +/* next get micro-USB Interface Controller node */
>> +muic = of_get_next_parent(musb);
>> +
>> +if (!muic) {
>> +dev_info(ctx->dev, "no extcon found, switching to 'always on' 
>> mode\n");
>> +return 0;
>> +}
>> +
>> +edev = extcon_find_edev_by_node(muic);
>> +of_node_put(muic);
>> +if (IS_ERR(edev)) {
>> +if (PTR_ERR(edev) == -EPROBE_DEFER)
>> +return -EPROBE_DEFER;
>> +dev_err(ctx->dev, "Invalid or missing extcon\n");
>> +return PTR_ERR(edev);
>> +}
>> +
>> +ctx->extcon = edev;
>> +ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
>> +INIT_WORK(>extcon_wq, sii8620_extcon_work);
>> +ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
> You bett

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Andrzej Hajda]

On 26.02.2018 12:49, Li Jun wrote:
> In case of usb-c-connector with power delivery support, add bingdings
> supported by current typec driver, so user can pass all those properties
> via dt.
>
> Signed-off-by: Li Jun <jun...@nxp.com>
> ---
> Changes for v2:
> - Added typec properties are based on general usb connector bindings[1]
>   proposed by Andrzej Hajda.
> - Use the standard unit suffixes as defined in property-units.txt.
>
> [1] https://patchwork.kernel.org/patch/10231447/
>
>  .../bindings/connector/usb-connector.txt   | 43 
> ++
>  1 file changed, 43 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> index e1463f1..242f6df 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -15,6 +15,30 @@ Optional properties:
>  - type: size of the connector, should be specified in case of USB-A, USB-B
>non-fullsize connectors: "mini", "micro".
>  
> +Required properties for usb-c-connector with power delivery support:
> +- port-type: should be one of "source", "sink" or "dual".
> +- default-role: preferred power role if port-type is "dual"(drp), should be
> +  "sink" or "source".

Since port carries data and power, it would be better to explicitly
mention it in names of properties which can be ambiguous.
Maybe instead of 'port-type' you can use 'power-role', for example.
Other thing is that default-role is required only in case of DRP, so
maybe better would be to squash it in power-role, for example:
    power-role: should be on of "source", "sink", "dual-source",
"dual-sink", in case of dual roles suffix determines preferred role.


> +- src-pdos: An array of u32 with each entry providing supported power
> +  source data object(PDO), the detailed bit definitions of PDO can be found
> +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> +  Source_Capabilities Message, the order of each entry(PDO) should follow
> +  the PD spec chapter 6.4.1. Required for power source and power dual role.
> +- snk-pdos: An array of u32 with each entry providing supported power
> +  sink data object(PDO), the detailed bit definitions of PDO can be found in
> +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink
> +  Capabilities Message, the order of each entry(PDO) should follow the PD
> +  spec chapter 6.4.1. Required for power sink and power dual role.

We should avoid magic numbers, magic numbers are bad :)
If we really need to use PDOs here, I think we can re-use PDO_* macros
[1] - DTC should be able to parse it, maybe some lifting will be necessary.

[1]:
https://elixir.bootlin.com/linux/v4.16-rc3/source/include/linux/usb/pd.h#L161
> +- max-snk-microvolt: The max voltage the sink can support in micro volts,
> +  required for power sink and power dual role.
> +- max-snk-microamp: The max current the sink can support in micro amps,
> +  required for power sink and power dual role.
> +- max-snk-microwatt-hours: The max power the sink can support in micro
> +  Watt-hours, required for power sink and power dual role.
> +- op-snk-microwatt-hours: Sink required operating power in micro Watt-hours,
> +  if source offered power is less then it, Capability Mismatch is set,
> +  required for power sink and power dual role.

What is the relation between above properties and PDOs specified earlier?
Are you sure all these props are required?

And general remark regarding all above properties. For me, most of them
are specific not to the port but to devices responsible for power
management: chargers, pmics,
In many cases these properties are redundant with devices capabilities.
On the other side I guess in many cases it may be convenient to put them
here, so I am not sure what is better :)

Regards
Andrzej

> +
>  Required nodes:
>  - any data bus to the connector should be modeled using the OF graph bindings
>specified in bindings/graph.txt, unless the bus is between parent node and
> @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
>   };
>   };
>  };
> +
> +3. USB-C connector attached to a typec port controller(ptn5110), which has
> +power delivery support and enables drp.
> +
> +typec: ptn5110@50 {
> + ...
> + usb_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";
> + port-type = "dual";
> + default-role = "sink";
> + src-pdos = <0x380190c8>;
> +   

[PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

These bindings allow to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriate graph bindings.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
v4:
- improved 'type' description (Rob),
- improved description of 2nd example (Rob).
v3:
- removed MHL port (samsung connector will have separate bindings),
- added 2nd example for USB-C,
- improved formatting.
v2:
- moved connector type(A,B,C) to compatible string (Rob),
- renamed size property to type (Rob),
- changed type description to be less confusing (Laurent),
- removed vendor specific compatibles (implied by graph port number),
- added requirement of connector being a child of IC (Rob),
- removed max-mode (subtly suggested by Rob, it should be detected anyway
  by USB Controller in runtime, downside is that device is not able to
  report its real capabilities, maybe better would be to make it optional(?)),
- assigned port numbers to data buses (Rob).

Regards
Andrzej
---
 .../bindings/connector/usb-connector.txt   | 75 ++
 1 file changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..e1463f14af38
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,75 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"usb-a-connector",
+"usb-b-connector",
+"usb-c-connector".
+
+Optional properties:
+- label: symbolic name for the connector,
+- type: size of the connector, should be specified in case of USB-A, USB-B
+  non-fullsize connectors: "mini", "micro".
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS), present in all connectors,
+1: Super Speed (SS), present in SS capable connectors,
+2: Sideband use (SBU), present in USB-C.
+
+Examples
+
+
+1. Micro-USB connector with HS lines routed via controller (MUIC):
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
+};
+
+2. USB-C connector attached to CC controller (s2mm005), HS lines routed
+to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
+DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
+
+ccic: s2mm005@33 {
+   ...
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   usb_con_hs: endpoint {
+   remote-endpoint = <_usbc_hs>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   usb_con_ss: endpoint {
+   remote-endpoint = <_phy_ss>;
+   };
+   };
+   port@2 {
+   reg = <2>;
+   usb_con_sbu: endpoint {
+   remote-endpoint = <_aux>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

OF graph describes MHL data lanes between MHL and respective USB
connector.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
v5: removed extra parenthesis (kbuild test robot)
v4: added missing reg property in connector's port node (Krzysztof)
---
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 +++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index f604f6b1a9c2..03453b822093 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -817,9 +817,22 @@
clocks = <_system_controller 0>;
clock-names = "xtal";
 
-   port {
-   mhl_to_hdmi: endpoint {
-   remote-endpoint = <_to_mhl>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   mhl_to_musb_con: endpoint {
+   remote-endpoint = <_con_to_mhl>;
+   };
};
};
};
@@ -842,6 +855,18 @@
 "usb-b-connector";
label = "micro-USB";
type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   musb_con_to_mhl: endpoint {
+   remote-endpoint = 
<_to_musb_con>;
+   };
+   };
+   };
};
};
 
-- 
2.16.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 5/6] extcon: add possibility to get extcon device by OF node

[Andrzej Hajda]

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
Acked-by: Chanwoo Choi <cw00.c...@samsung.com>
---
v5: function renamed to extcon_find_edev_by_node (Andy)
v2: changed label to follow local convention (Chanwoo)
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..47a5ca9eb86d 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_find_edev_by_node - Find the extcon device from devicetree.
+ * @node   : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(_dev_list_lock);
+   list_for_each_entry(edev, _dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto out;
+   edev = ERR_PTR(-EPROBE_DEFER);
+out:
+   mutex_unlock(_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(_dev_list_lock);
-   list_for_each_entry(edev, _dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(_dev_list_lock);
+   edev = extcon_find_edev_by_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_find_edev_by_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_find_edev_by_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 6d94e82c8ad9..7f033b1ea568 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_find_edev_by_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -283,6 +284,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_find_edev_by_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
2.16.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

From: Maciej Purski <m.pur...@samsung.com>

Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.

Signed-off-by: Maciej Purski <m.pur...@samsung.com>
Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
v5: updated extcon API

This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.

Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 97 ++--
 1 file changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9e785b8e0ea2..62b0adabcac2 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -81,6 +83,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620 
*ctx)
ctx->rc_dev = rc_dev;
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+   if (state == ctx->cable_state)
+   return;
+
+   ctx->cable_state = state;
+
+   if (state > 0)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   schedule_work(>extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   struct device_node *musb, *muic;
+   int ret;
+
+   /* get micro-USB connector node */
+   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+   /* next get micro-USB Interface Controller node */
+   muic = of_get_next_parent(musb);
+
+   if (!muic) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   return 0;
+   }
+
+   edev = extcon_find_edev_by_node(muic);
+   of_node_put(muic);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   INIT_WORK(>extcon_wq, sii8620_extcon_work);
+   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
 
-   sii8620_cable_in(ctx);
+   if (!ctx->extcon)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client)
 {
struct sii8620 *ctx = i2c_get_clientdata(client);
 
-   disable_irq(to_i2c_client(ctx->

[PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi,

Thanks for reviews of previous iterations.

This patchset introduces USB physical connector bindings, together with
working example.
I have removed RFC prefix - the patchset seems to be heading
to a happy end :)

v5: fixed extra parenthesis in dts, renamed extcon function.
v4: improved binding descriptions, added missing reg in dts.
v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
example.
v2: I have addressed comments by Rob and Laurent, thanks 

Changes in datail are described in the patches.

Regards
Andrzej


Andrzej Hajda (5):
  dt-bindings: add bindings for USB physical connector
  dt-bindings: add bindings for Samsung micro-USB 11-pin connector
  arm64: dts: exynos: add micro-USB connector node to TM2 platforms
  arm64: dts: exynos: add OF graph between MHL and USB connector
  extcon: add possibility to get extcon device by OF node

Maciej Purski (1):
  drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

 .../connector/samsung,usb-connector-11pin.txt  | 49 +++
 .../bindings/connector/usb-connector.txt   | 75 +
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 38 -
 drivers/extcon/extcon.c| 44 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c   | 97 +-
 include/linux/extcon.h |  6 ++
 6 files changed, 293 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

-- 
2.16.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector

[Andrzej Hajda]

Samsung micro-USB 11-pin connector beside standard micro-USB pins,
has pins dedicated to route MHL traffic.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
Reviewed-by: Rob Herring <r...@kernel.org>
---
v4:
- removed description of property inherited from usb-connector (Rob),
- fixed example description.
---
 .../connector/samsung,usb-connector-11pin.txt  | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt

diff --git 
a/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
new file mode 100644
index ..22256e295a7a
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
@@ -0,0 +1,49 @@
+Samsung micro-USB 11-pin connector
+==
+
+Samsung micro-USB 11-pin connector is an extension of micro-USB connector.
+It is present in multiple Samsung mobile devices.
+It has additional pins to route MHL traffic simultanously with USB.
+
+The bindings are superset of usb-connector bindings for micro-USB connector[1].
+
+Required properties:
+- compatible: must be: "samsung,usb-connector-11pin", "usb-b-connector",
+- type: must be "micro".
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS),
+3: Mobile High-Definition Link (MHL), specific to 11-pin Samsung micro-USB.
+
+[1]: bindings/connector/usb-connector.txt
+
+Example
+---
+
+Micro-USB connector with HS lines routed via controller (MUIC) and MHL lines
+connected to HDMI-MHL bridge (sii8620):
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "samsung,usb-connector-11pin", "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   usb_con_mhl: endpoint {
+   remote-endpoint = <_mhl>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

[Andrzej Hajda]

Since USB connector bindings are available we can describe it on TM2(e).

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 0b61dda99569..f604f6b1a9c2 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -836,6 +836,13 @@
 
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+   musb_con: musb_connector {
+   compatible = "samsung,usb-connector-11pin",
+"usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
};
 
regulators {
-- 
2.16.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

On 26.02.2018 16:21, Krzysztof Kozlowski wrote:
> On Wed, Feb 21, 2018 at 9:55 AM, Andrzej Hajda <a.ha...@samsung.com> wrote:
>> OF graph describes MHL data lanes between MHL and respective USB
>> connector.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>> v4:
>> - added missing reg property in connector's port node (Krzysztof)
>> ---
>>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 32 
>> --
>>  1 file changed, 29 insertions(+), 3 deletions(-)
> You have a duplicated '};' so kbuild complains so I assume there will
> be next iteration of this. Beside that I am okay with both, so I will
> take next version when your bindings and driver changes get
> acked/accepted.

Yes, test robot already reported it, thanks for looking at it.
I have postponed next iteration in case anything new is spotted, but
since it is calm I will send it in few minutes.

Regards
Andrzej

>
> Best Regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 5/6] extcon: add possibility to get extcon device by OF node

[Andrzej Hajda]

On 21.02.2018 15:27, Andy Shevchenko wrote:
> On Wed, Feb 21, 2018 at 10:55 AM, Andrzej Hajda <a.ha...@samsung.com> wrote:
>> Since extcon property is not allowed in DT, extcon subsystem requires
>> another way to get extcon device. Lets try the simplest approach - get
>> edev by of_node.
>> +/*
>> + * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
>> + * @node   : OF node identyfying edev
>> + *
>> + * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
>> + */
>> +struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
> First of all, the all other similar cases use "_by_node" in the name.

OK, looks better.

> Second, it's not _get_, it's _find_.

The patch splits exisiting extcon_get_edev_by_phandle function into two
functions, nothing more.
Thus it followed naming convention present in extcon framework. I can
switch it of course to _find_.

>
>> +{
>> +   struct extcon_dev *edev;
>> +
>> +   mutex_lock(_dev_list_lock);
>> +   list_for_each_entry(edev, _dev_list, entry)
>> +   if (edev->dev.parent && edev->dev.parent->of_node == node)
>> +   goto out;
>> +   edev = ERR_PTR(-EPROBE_DEFER);
>> +out:
>> +   mutex_unlock(_dev_list_lock);
>> +
>> +   return edev;
> Can't it be done using bus_find_device()?

There is no special extcon bus, so I am not sure. Anyway if it can, it
should be done probably in another patch.

Regards
Andrzej

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

OF graph describes MHL data lanes between MHL and respective USB
connector.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
v4:
- added missing reg property in connector's port node (Krzysztof)
---
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 32 --
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index f604f6b1a9c2..2ed506df94d0 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -817,9 +817,22 @@
clocks = <_system_controller 0>;
clock-names = "xtal";
 
-   port {
-   mhl_to_hdmi: endpoint {
-   remote-endpoint = <_to_mhl>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   mhl_to_musb_con: endpoint {
+   remote-endpoint = <_con_to_mhl>;
+   };
};
};
};
@@ -842,6 +855,19 @@
 "usb-b-connector";
label = "micro-USB";
type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   musb_con_to_mhl: endpoint {
+   remote-endpoint = 
<_to_musb_con>;
+   };
+   };
+   };
+   };
};
};
 
-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

These bindings allow to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriate graph bindings.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
v4:
- improved 'type' description (Rob),
- improved description of 2nd example (Rob).
v3:
- removed MHL port (samsung connector will have separate bindings),
- added 2nd example for USB-C,
- improved formatting.
v2:
- moved connector type(A,B,C) to compatible string (Rob),
- renamed size property to type (Rob),
- changed type description to be less confusing (Laurent),
- removed vendor specific compatibles (implied by graph port number),
- added requirement of connector being a child of IC (Rob),
- removed max-mode (subtly suggested by Rob, it should be detected anyway
  by USB Controller in runtime, downside is that device is not able to
  report its real capabilities, maybe better would be to make it optional(?)),
- assigned port numbers to data buses (Rob).

Regards
Andrzej
---
 .../bindings/connector/usb-connector.txt   | 75 ++
 1 file changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..e1463f14af38
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,75 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"usb-a-connector",
+"usb-b-connector",
+"usb-c-connector".
+
+Optional properties:
+- label: symbolic name for the connector,
+- type: size of the connector, should be specified in case of USB-A, USB-B
+  non-fullsize connectors: "mini", "micro".
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS), present in all connectors,
+1: Super Speed (SS), present in SS capable connectors,
+2: Sideband use (SBU), present in USB-C.
+
+Examples
+
+
+1. Micro-USB connector with HS lines routed via controller (MUIC):
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
+};
+
+2. USB-C connector attached to CC controller (s2mm005), HS lines routed
+to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
+DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
+
+ccic: s2mm005@33 {
+   ...
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   usb_con_hs: endpoint {
+   remote-endpoint = <_usbc_hs>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   usb_con_ss: endpoint {
+   remote-endpoint = <_phy_ss>;
+   };
+   };
+   port@2 {
+   reg = <2>;
+   usb_con_sbu: endpoint {
+   remote-endpoint = <_aux>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 5/6] extcon: add possibility to get extcon device by OF node

[Andrzej Hajda]

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
Acked-by: Chanwoo Choi <cw00.c...@samsung.com>
---
v2: changed label to follow local convention (Chanwoo)
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..c4972c4cb3bd 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
+ * @node   : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(_dev_list_lock);
+   list_for_each_entry(edev, _dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto out;
+   edev = ERR_PTR(-EPROBE_DEFER);
+out:
+   mutex_unlock(_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(_dev_list_lock);
-   list_for_each_entry(edev, _dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(_dev_list_lock);
+   edev = extcon_get_edev_by_of_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_get_edev_by_of_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 6d94e82c8ad9..b47e0c7f01fe 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -283,6 +284,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_get_edev_by_of_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

From: Maciej Purski <m.pur...@samsung.com>

Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.

Signed-off-by: Maciej Purski <m.pur...@samsung.com>
Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.

Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 97 ++--
 1 file changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9e785b8e0ea2..565cc352ca81 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -81,6 +83,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620 
*ctx)
ctx->rc_dev = rc_dev;
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+   if (state == ctx->cable_state)
+   return;
+
+   ctx->cable_state = state;
+
+   if (state > 0)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   schedule_work(>extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   struct device_node *musb, *muic;
+   int ret;
+
+   /* get micro-USB connector node */
+   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+   /* next get micro-USB Interface Controller node */
+   muic = of_get_next_parent(musb);
+
+   if (!muic) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   return 0;
+   }
+
+   edev = extcon_get_edev_by_of_node(muic);
+   of_node_put(muic);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   INIT_WORK(>extcon_wq, sii8620_extcon_work);
+   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
 
-   sii8620_cable_in(ctx);
+   if (!ctx->extcon)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client)
 {
struct sii8620 *ctx = i2c_get_clientdata(client);
 
-   disable_irq(to_i2c_client(ctx->

[PATCH v4 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi,

Thanks for reviews of previous iterations.

This patchset introduces USB physical connector bindings, together with
working example.
I have removed RFC prefix - the patchset seems to be heading
to a happy end :)

v4: improved binding descriptions, added missing reg in dts.
v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C
example.
v2: I have addressed comments by Rob and Laurent, thanks 

Changes in datail are described in the patches.

Regards
Andrzej


Andrzej Hajda (5):
  dt-bindings: add bindings for USB physical connector
  dt-bindings: add bindings for Samsung micro-USB 11-pin connector
  arm64: dts: exynos: add micro-USB connector node to TM2 platforms
  arm64: dts: exynos: add OF graph between MHL and USB connector
  extcon: add possibility to get extcon device by OF node

Maciej Purski (1):
  drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

 .../connector/samsung,usb-connector-11pin.txt  | 49 +++
 .../bindings/connector/usb-connector.txt   | 75 +
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 39 -
 drivers/extcon/extcon.c| 44 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c   | 97 +-
 include/linux/extcon.h |  6 ++
 6 files changed, 294 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector

[Andrzej Hajda]

Samsung micro-USB 11-pin connector beside standard micro-USB pins,
has pins dedicated to route MHL traffic.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
Reviewed-by: Rob Herring <r...@kernel.org>
---
v4:
- removed description of property inherited from usb-connector (Rob),
- fixed example description.
---
 .../connector/samsung,usb-connector-11pin.txt  | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt

diff --git 
a/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
new file mode 100644
index ..22256e295a7a
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
@@ -0,0 +1,49 @@
+Samsung micro-USB 11-pin connector
+==
+
+Samsung micro-USB 11-pin connector is an extension of micro-USB connector.
+It is present in multiple Samsung mobile devices.
+It has additional pins to route MHL traffic simultanously with USB.
+
+The bindings are superset of usb-connector bindings for micro-USB connector[1].
+
+Required properties:
+- compatible: must be: "samsung,usb-connector-11pin", "usb-b-connector",
+- type: must be "micro".
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS),
+3: Mobile High-Definition Link (MHL), specific to 11-pin Samsung micro-USB.
+
+[1]: bindings/connector/usb-connector.txt
+
+Example
+---
+
+Micro-USB connector with HS lines routed via controller (MUIC) and MHL lines
+connected to HDMI-MHL bridge (sii8620):
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "samsung,usb-connector-11pin", "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   usb_con_mhl: endpoint {
+   remote-endpoint = <_mhl>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

[Andrzej Hajda]

Since USB connector bindings are available we can describe it on TM2(e).

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 0b61dda99569..f604f6b1a9c2 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -836,6 +836,13 @@
 
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+   musb_con: musb_connector {
+   compatible = "samsung,usb-connector-11pin",
+"usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
};
 
regulators {
-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 19.02.2018 15:28, Rob Herring wrote:
> On Thu, Feb 15, 2018 at 11:39:15AM +0100, Andrzej Hajda wrote:
>> These bindings allow to describe most known standard USB connectors
>> and it should be possible to extend it if necessary.
>> USB connectors, beside USB can be used to route other protocols,
>> for example UART, Audio, MHL. In such case every device passing data
>> through the connector should have appropriate graph bindings.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>> v3:
>> - removed MHL port (samsung connector will have separate bindings),
>> - added 2nd example for USB-C,
>> - improved formatting
>> v2:
>> - moved connector type(A,B,C) to compatible string (Rob),
>> - renamed size property to type (Rob),
>> - changed type description to be less confusing (Laurent),
>> - removed vendor specific compatibles (implied by graph port number),
>> - added requirement of connector being a child of IC (Rob),
>> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>>   by USB Controller in runtime, downside is that device is not able to
>>   report its real capabilities, maybe better would be to make it 
>> optional(?)),
>> - assigned port numbers to data buses (Rob).
>>
>> Regards
>> Andrzej
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>>
>> dt-bindings: add bindings for USB physical connector v3
>> ---
>>  .../bindings/connector/usb-connector.txt   | 74 
>> ++
>>  1 file changed, 74 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>
>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> new file mode 100644
>> index ..1efda92639da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> @@ -0,0 +1,74 @@
>> +USB Connector
>> +=
>> +
>> +USB connector node represents physical USB connector. It should be
>> +a child of USB interface controller.
>> +
>> +Required properties:
>> +- compatible: describes type of the connector, must be one of:
>> +"usb-a-connector",
>> +"usb-b-connector",
>> +"usb-c-connector".
>> +
>> +Optional properties:
>> +- label: symbolic name for the connector,
>> +- type: size of the connector, should be specified in case of USB-A, USB-B
>> +  non-standard (large) connector sizes: "mini", "micro".
> The smaller connectors are standard too. Perhaps "non-fullsize connector 
> sizes".

The word "standard" is used in specs, but your description looks better,
maybe even shorter version would work: "non-fullsize connectors:".

>
> We're missing a micro-AB connector, but I think those are actually 
> pretty rare. Most phones are micro-B connectors, but do both host and 
> device.
>
>> +
>> +Required nodes:
>> +- any data bus to the connector should be modeled using the OF graph 
>> bindings
>> +  specified in bindings/graph.txt, unless the bus is between parent node and
>> +  the connector. Since single connector can have multpile data buses every 
>> bus
>> +  has assigned OF graph port number as follows:
>> +0: High Speed (HS), present in all connectors,
>> +1: Super Speed (SS), present in SS capable connectors,
> This should also say endpoint 0 is USB-SS, endpoint 1 (and higher?) is 
> Alternate Mode. And show in the example.

What if there is SS mux before, which muxes USB-SS and DP lines. In my
case the mux is located in USB-PHY (it is 2nd example below).
In such case there is only one graph connection to SS port and this
connection will handle both USB-SS and AltMode traffic.
Anyway from USB-C connector's point of view, there is no distinction
which lines are USB-SS, which are AltMode. In fact platform decides in
real time about muxing of SS and AltMode signals, as it depends on
cable/plug orientations. Maybe instead of mapping endpoint numbers to
SS/AltMode, we should map them to SS1/SS2 lines if necessary(???).

To be sure of your intentions. Do you want to model simple SS muxes as a
part of USB-C connector?

>> +2: Sideband use (SBU), present in USB-C.
>> +
>> +Examples
>> +
>> +
>> +1. Micro-USB connector with HS lines routed via controller (MUIC):
>> +
>> +muic-max77843@66 {
>> +...
>> +usb_con: connector {
>> +compatible = "usb-b-c

Re: [RFC PATCH v2 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

On 15.02.2018 13:14, Krzysztof Kozlowski wrote:
> On Thu, Feb 15, 2018 at 11:39 AM, Andrzej Hajda <a.ha...@samsung.com> wrote:
>> OF graph describes MHL data lanes between MHL and respective USB
>> connector.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>>  .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 
>> +++---
>>  1 file changed, 28 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> index 7e49fadee412..ef758f7337e9 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> @@ -779,9 +779,22 @@
>> clocks = <_system_controller 0>;
>> clock-names = "xtal";
>>
>> -   port {
>> -   mhl_to_hdmi: endpoint {
>> -   remote-endpoint = <_to_mhl>;
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   port@0 {
>> +   reg = <0>;
>> +   mhl_to_hdmi: endpoint {
>> +   remote-endpoint = <_to_mhl>;
>> +   };
>> +   };
>> +
>> +   port@1 {
>> +   reg = <1>;
>> +   mhl_to_musb_con: endpoint {
>> +   remote-endpoint = <_con_to_mhl>;
>> +   };
>> };
>> };
>> };
>> @@ -804,6 +817,18 @@
>>  "usb-b-connector";
>> label = "micro-USB";
>> type = "micro";
>> +
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   port@3 {
> I think you might need here "reg = <3>". Doesn't it produce a warning now?

You are right, I will fix it. Warning is produced only if compiled with W=1.

Regards
Andrzej

>
> BR,
> Krzysztof
>
>> +   musb_con_to_mhl: endpoint {
>> +   remote-endpoint = 
>> <_to_musb_con>;
>> +   };
>> +   };
>> +   };
>> +   };
>> };
>> };
>>
>> --
>> 2.16.1
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 5/6] extcon: add possibility to get extcon device by OF node

[Andrzej Hajda]

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
Acked-by: Chanwoo Choi <cw00.c...@samsung.com>
---
v2: changed label to follow local convention (Chanwoo)
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..c4972c4cb3bd 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
+ * @node   : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(_dev_list_lock);
+   list_for_each_entry(edev, _dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto out;
+   edev = ERR_PTR(-EPROBE_DEFER);
+out:
+   mutex_unlock(_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(_dev_list_lock);
-   list_for_each_entry(edev, _dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(_dev_list_lock);
+   edev = extcon_get_edev_by_of_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_get_edev_by_of_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 6d94e82c8ad9..b47e0c7f01fe 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -283,6 +284,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_get_edev_by_of_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

OF graph describes MHL data lanes between MHL and respective USB
connector.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 +++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 7e49fadee412..ef758f7337e9 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -779,9 +779,22 @@
clocks = <_system_controller 0>;
clock-names = "xtal";
 
-   port {
-   mhl_to_hdmi: endpoint {
-   remote-endpoint = <_to_mhl>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   mhl_to_musb_con: endpoint {
+   remote-endpoint = <_con_to_mhl>;
+   };
};
};
};
@@ -804,6 +817,18 @@
 "usb-b-connector";
label = "micro-USB";
type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   musb_con_to_mhl: endpoint {
+   remote-endpoint = 
<_to_musb_con>;
+   };
+   };
+   };
+   };
};
};
 
-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

These bindings allow to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriate graph bindings.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
v3:
- removed MHL port (samsung connector will have separate bindings),
- added 2nd example for USB-C,
- improved formatting
v2:
- moved connector type(A,B,C) to compatible string (Rob),
- renamed size property to type (Rob),
- changed type description to be less confusing (Laurent),
- removed vendor specific compatibles (implied by graph port number),
- added requirement of connector being a child of IC (Rob),
- removed max-mode (subtly suggested by Rob, it should be detected anyway
  by USB Controller in runtime, downside is that device is not able to
  report its real capabilities, maybe better would be to make it optional(?)),
- assigned port numbers to data buses (Rob).

Regards
Andrzej

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>

dt-bindings: add bindings for USB physical connector v3
---
 .../bindings/connector/usb-connector.txt   | 74 ++
 1 file changed, 74 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..1efda92639da
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,74 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"usb-a-connector",
+"usb-b-connector",
+"usb-c-connector".
+
+Optional properties:
+- label: symbolic name for the connector,
+- type: size of the connector, should be specified in case of USB-A, USB-B
+  non-standard (large) connector sizes: "mini", "micro".
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS), present in all connectors,
+1: Super Speed (SS), present in SS capable connectors,
+2: Sideband use (SBU), present in USB-C.
+
+Examples
+
+
+1. Micro-USB connector with HS lines routed via controller (MUIC):
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
+};
+
+2. USB-C connector attached to CC controller (s2mm005), HS lines routed
+to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort:
+
+ccic: s2mm005@33 {
+   ...
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   usb_con_hs: endpoint {
+   remote-endpoint = <_usbc_hs>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   usb_con_ss: endpoint {
+   remote-endpoint = <_phy_ss>;
+   };
+   };
+   port@2 {
+   reg = <2>;
+   usb_con_sbu: endpoint {
+   remote-endpoint = <_aux>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

[Andrzej Hajda]

Since USB connector bindings are available we can describe it on TM2(e).

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index a1e93d91a3ed..7e49fadee412 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -798,6 +798,13 @@
 
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+   musb_con: musb_connector {
+   compatible = "samsung,usb-connector-11pin",
+"usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
};
 
regulators {
-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

From: Maciej Purski <m.pur...@samsung.com>

Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.

Signed-off-by: Maciej Purski <m.pur...@samsung.com>
Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.

Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 97 ++--
 1 file changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9e785b8e0ea2..565cc352ca81 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -81,6 +83,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620 
*ctx)
ctx->rc_dev = rc_dev;
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+   if (state == ctx->cable_state)
+   return;
+
+   ctx->cable_state = state;
+
+   if (state > 0)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   schedule_work(>extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   struct device_node *musb, *muic;
+   int ret;
+
+   /* get micro-USB connector node */
+   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+   /* next get micro-USB Interface Controller node */
+   muic = of_get_next_parent(musb);
+
+   if (!muic) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   return 0;
+   }
+
+   edev = extcon_get_edev_by_of_node(muic);
+   of_node_put(muic);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   INIT_WORK(>extcon_wq, sii8620_extcon_work);
+   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
 
-   sii8620_cable_in(ctx);
+   if (!ctx->extcon)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client)
 {
struct sii8620 *ctx = i2c_get_clientdata(client);
 
-   disable_irq(to_i2c_client(ctx->

[RFC PATCH v2 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector

[Andrzej Hajda]

Samsung micro-USB 11-pin connector beside standard micro-USB pins,
has pins dedicated to route MHL traffic.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 .../connector/samsung,usb-connector-11pin.txt  | 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt

diff --git 
a/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
new file mode 100644
index ..c8ef1ad6732f
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
@@ -0,0 +1,51 @@
+Samsung micro-USB 11-pin connector
+==
+
+Samsung micro-USB 11-pin connector is an extension of micro-USB connector.
+It is present in multiple Samsung mobile devices.
+It has additional pins to route MHL traffic simultanously with USB.
+
+The bindings are superset of usb-connector bindings for micro-USB connector[1].
+
+Required properties:
+- compatible: must be: "samsung,usb-connector-11pin", "usb-b-connector",
+- type: must be "micro".
+
+Optional properties:
+- label: symbolic name for the connector.
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS),
+3: Mobile High-Definition Link (MHL), specific to 11-pin Samsung micro-USB.
+
+[1]: bindings/connector/usb-connector.txt
+
+Example
+---
+
+Micro-USB connector with HS lines routed via controller (MUIC) and :
+
+muic-max77843@66 {
+   ...
+   usb_con: connector {
+   compatible = "samsung,usb-connector-11pin", "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   usb_con_mhl: endpoint {
+   remote-endpoint = <_mhl>;
+   };
+   };
+   };
+   };
+};
-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 0/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi,

Thanks for reviews of previous iterations.

This patchset introduces USB physical connector bindings, together with working 
example.

v2: I have addressed comments by Rob and Laurent, thanks 
v3: Separate binding for Samsung 11-pin connector, added full-blown USB-C 
example.

Changes are also described in patches.

Regards
Andrzej


Andrzej Hajda (5):
  dt-bindings: add bindings for USB physical connector
  dt-bindings: add bindings for Samsung micro-USB 11-pin connector
  arm64: dts: exynos: add micro-USB connector node to TM2 platforms
  arm64: dts: exynos: add OF graph between MHL and USB connector
  extcon: add possibility to get extcon device by OF node

Maciej Purski (1):
  drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

 .../connector/samsung,usb-connector-11pin.txt  | 51 
 .../bindings/connector/usb-connector.txt   | 74 +
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 38 -
 drivers/extcon/extcon.c| 44 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c   | 97 +-
 include/linux/extcon.h |  6 ++
 6 files changed, 294 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/connector/samsung,usb-connector-11pin.txt
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

-- 
2.16.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 07.02.2018 22:43, Rob Herring wrote:
> On Mon, Feb 05, 2018 at 10:06:35AM +0100, Andrzej Hajda wrote:
>> On 05.02.2018 07:08, Rob Herring wrote:
>>> On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
>>>> These bindings allow to describe most known standard USB connectors
>>>> and it should be possible to extend it if necessary.
>>>> USB connectors, beside USB can be used to route other protocols,
>>>> for example UART, Audio, MHL. In such case every device passing data
>>>> through the connector should have appropriate graph bindings.
>>>>
>>>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>>>> ---
>>>> v2:
>>>> - moved connector type(A,B,C) to compatible string (Rob),
>>>> - renamed size property to type (Rob),
>>>> - changed type description to be less confusing (Laurent),
>>>> - removed vendor specific compatibles (implied by graph port number),
>>> How so? More below...
>>>
>>>> - added requirement of connector being a child of IC (Rob),
>>>> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>>>>   by USB Controller in runtime, downside is that device is not able to
>>>>   report its real capabilities, maybe better would be to make it 
>>>> optional(?)),
>>>> - assigned port numbers to data buses (Rob).
>>>>
>>>> Regards
>>>> Andrzej
>>>>
>>>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>>>> ---
>>>>  .../bindings/connector/usb-connector.txt   | 48 
>>>> ++
>>>>  1 file changed, 48 insertions(+)
>>>>  create mode 100644 
>>>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>>>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>> new file mode 100644
>>>> index ..02020f5d760a
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>> @@ -0,0 +1,48 @@
>>>> +USB Connector
>>>> +=
>>>> +
>>>> +USB connector node represents physical USB connector. It should be
>>>> +a child of USB interface controller.
>>>> +
>>>> +Required properties:
>>>> +- compatible: describes type of the connector, must be one of:
>>>> +"usb-a-connector", "usb-b-connector", "usb-c-connector",
>>> Nit: one per line.
>>>
>>>> +
>>>> +Optional properties:
>>>> +- label: symbolic name for the connector
>>>> +- type: size of the connector, should be specified in case of USB-A, USB-B
>>>> +  non-standard (large) connector sizes: "mini", "micro"
>>>> +
>>>> +Required nodes:
>>>> +- any data bus to the connector should be modeled using the OF graph 
>>>> bindings
>>>> +  specified in bindings/graph.txt, unless the bus is between parent node 
>>>> and
>>>> +  the connector. Since single connector can have multpile data buses 
>>>> every bus
>>>> +  has assigned OF graph port number as follows:
>>>> +0: High Speed (HS), present in all connectors,
>>>> +1: Super Speed (SS), present in SS capable connectors,
>>>> +2: Sideband use (SBU), present in USB-C,
>>>> +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung 
>>>> micro-USB
>>> This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
>>> That makes me think the Samsung connector should have its own compatible 
>>> string.
>> Do you mean, sth like:
>>     connector {
>>             compatible = "samsung,usb-connector-11pin";
>>             label = "micro-USB";
>>             ports {
>>                     #address-cells = <1>;
>>                     #size-cells = <0>;
>>
>>                     port@3 {
>>                             reg = <3>;
>>                             musb_con_mhl_in: endpoint {
>>                                     remote-endpoint = <_out>;
>>                             };
>>                     };
>>     };
> Yes, basically.
>
>> Or should I add "usb-b-connector" extra compatible and "t

Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 05.02.2018 07:08, Rob Herring wrote:
> On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
>> These bindings allow to describe most known standard USB connectors
>> and it should be possible to extend it if necessary.
>> USB connectors, beside USB can be used to route other protocols,
>> for example UART, Audio, MHL. In such case every device passing data
>> through the connector should have appropriate graph bindings.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>> v2:
>> - moved connector type(A,B,C) to compatible string (Rob),
>> - renamed size property to type (Rob),
>> - changed type description to be less confusing (Laurent),
>> - removed vendor specific compatibles (implied by graph port number),
> How so? More below...
>
>> - added requirement of connector being a child of IC (Rob),
>> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>>   by USB Controller in runtime, downside is that device is not able to
>>   report its real capabilities, maybe better would be to make it 
>> optional(?)),
>> - assigned port numbers to data buses (Rob).
>>
>> Regards
>> Andrzej
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>>  .../bindings/connector/usb-connector.txt   | 48 
>> ++
>>  1 file changed, 48 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>
>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> new file mode 100644
>> index ..02020f5d760a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> @@ -0,0 +1,48 @@
>> +USB Connector
>> +=
>> +
>> +USB connector node represents physical USB connector. It should be
>> +a child of USB interface controller.
>> +
>> +Required properties:
>> +- compatible: describes type of the connector, must be one of:
>> +"usb-a-connector", "usb-b-connector", "usb-c-connector",
> Nit: one per line.
>
>> +
>> +Optional properties:
>> +- label: symbolic name for the connector
>> +- type: size of the connector, should be specified in case of USB-A, USB-B
>> +  non-standard (large) connector sizes: "mini", "micro"
>> +
>> +Required nodes:
>> +- any data bus to the connector should be modeled using the OF graph 
>> bindings
>> +  specified in bindings/graph.txt, unless the bus is between parent node and
>> +  the connector. Since single connector can have multpile data buses every 
>> bus
>> +  has assigned OF graph port number as follows:
>> +0: High Speed (HS), present in all connectors,
>> +1: Super Speed (SS), present in SS capable connectors,
>> +2: Sideband use (SBU), present in USB-C,
>> +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung 
>> micro-USB
> This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
> That makes me think the Samsung connector should have its own compatible 
> string.

Do you mean, sth like:
    connector {
            compatible = "samsung,usb-connector-11pin";
            label = "micro-USB";
            ports {
                    #address-cells = <1>;
                    #size-cells = <0>;

                    port@3 {
                            reg = <3>;
                            musb_con_mhl_in: endpoint {
                                    remote-endpoint = <_out>;
                            };
                    };
    };

Or should I add "usb-b-connector" extra compatible and "type" property?
I slightly prefer my approach(less different bindings), but I am also OK
with the above.

>
> Can we go ahead and define the video modes of Type-C? Normally, if 2 
> data streams are mutually exclusive, then they are a single port with 2 
> endpoints. So we'd either have 2 endpoints on port 1 or we stick with 
> port 3 is always video. We can still know what is mutually exclusive 
> based on the compatible. 

I am sorry, I do not understand what you mean. Port 3 is present only in
11-pin Samsung micro-USB, USB Type-C has only ports 0, 1, 2.
Here is list of possible ports depending on connector type:
- USB 2.0: HS
- 11-pin Samsung micro-USB: HS,MHL
- USB 3.x type A,B: HS,SS
- USB-C: HS,SS,SBU

All ports have separate lines, so they can work simultaneously.

And regarding MHL on standard micro-USB connector. MHL and MUIC will
share HS port, 

Re: [PATCH 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC

[Andrzej Hajda]

On 01.02.2018 08:50, Krzysztof Kozlowski wrote:
> On Wed, Jan 31, 2018 at 4:57 PM, Andrzej Hajda <a.ha...@samsung.com> wrote:
>> OF graph describes USB data lanes between USB-PHY and respective MUIC.
>> Since graph is present and DWC driver can use it to get extcon, obsolete
>> extcon property can be removed.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>>  arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 18 
>> +-
>>  1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> index 427ff861b441..b20b42659206 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> @@ -828,6 +828,17 @@
>> };
>> };
>> };
>> +
>> +   ports {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   port@0 {
>> +   reg = <0>;
>> +   muic_to_usb: endpoint {
>> +   remote-endpoint = 
>> <_to_muic>;
>> +   };
>> +   };
>> };
>> };
>>
>> @@ -1242,12 +1253,17 @@
>>
>>  _dwc3 {
>> dr_mode = "otg";
>> -   extcon = <>;
> Look ok for me.
>
> Does this depend on #1 patch for DWC?

Yes, it depends. #1 adds code to find extcon using graph, without it
dwc3 won't be able to work in dual-role mode.
Alternatively, I could split this patch into two parts:
2a. adding graph bindings.
2b. removing extcon property.
In such case only 2b depends on #1.

Regards
Andrzej

>
> Best regards,
> Krzysztof
>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] USB: dwc3: get extcon device by OF graph bindings

[Andrzej Hajda]

Hi,

This small patchset tries to address issue with broken DT extcon property
in case of USB controller - DWC3. It exposes similar problem as in proposed
USB connector bindings[1] - extcon device is required by devices not always
connected directly to extcon device. Here we have:
DWC3 -> USB-PHY -> MUIC -> USB-connector
   ^
MHL-bridge-^

More details and proposition of generic solution in first patch 

[1]: https://marc.info/?i=20180131134435.12216-1-a.hajda%40samsung.com

Regards
Andrzej


Andrzej Hajda (2):
  USB: dwc3: get extcon device by OF graph bindings
  arm64: dts: exynos: add OF graph between USB-PHY and MUIC

 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 18 +-
 drivers/usb/dwc3/drd.c | 41 +++---
 2 files changed, 45 insertions(+), 14 deletions(-)

-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] USB: dwc3: get extcon device by OF graph bindings

[Andrzej Hajda]

extcon device is used to detect host/device connection. Since extcon
OF property is deprecated, alternative method should be added.
This method uses OF graph bindings to locate extcon.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
Hi all,

This patch implements alternative method to get extcon from DWC3.
The code works but is hacky, as DWC3 must traverse different DT nodes
to get extcon, in case of TM2 it is USB-PHY and MUIC, but other
platforms can have different paths.
I would be glad if it can be merged as is for now, but additional work
must be done to make it generic.
I guess on DT binding side it is OK. So the problem should be addressed
in the code.
My rough idea is to implement kind of extcon aliases/forwarder mechanism,
ie. USB-PHY will expect on its output remote port extcon, and it should register
extcon-forwarder pointing to this extcon. This way DWC3 can look for the extcon
on its PHY phandle, and it will receive via forwarding mechanism extcon
exposed by MUIC.
As I said this is rough idea for discussion, other propositions are welcome.

Regards
Andrzej
---
 drivers/usb/dwc3/drd.c | 41 -
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index cc8ab9a8e9d2..eee2eca3d513 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 
 #include "debug.h"
 #include "core.h"
@@ -38,24 +39,38 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
return NOTIFY_DONE;
 }
 
+struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
+{
+   struct device *dev = dwc->dev;
+   struct device_node *np_phy, *np_conn;
+   struct extcon_dev *edev;
+
+   if (of_property_read_bool(dev->of_node, "extcon"))
+   return extcon_get_edev_by_phandle(dwc->dev, 0);
+
+   np_phy = of_parse_phandle(dev->of_node, "phys", 0);
+   np_conn = of_graph_get_remote_node(np_phy, -1, -1);
+   edev = extcon_get_edev_by_of_node(np_conn);
+   of_node_put(np_conn);
+   of_node_put(np_phy);
+
+   return edev;
+}
+
 int dwc3_drd_init(struct dwc3 *dwc)
 {
int ret;
 
-   if (dwc->dev->of_node) {
-   if (of_property_read_bool(dwc->dev->of_node, "extcon"))
-   dwc->edev = extcon_get_edev_by_phandle(dwc->dev, 0);
-
-   if (IS_ERR(dwc->edev))
-   return PTR_ERR(dwc->edev);
+   dwc->edev = dwc3_get_extcon(dwc);
+   if (IS_ERR(dwc->edev))
+   return PTR_ERR(dwc->edev);
 
-   dwc->edev_nb.notifier_call = dwc3_drd_notifier;
-   ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
-  >edev_nb);
-   if (ret < 0) {
-   dev_err(dwc->dev, "couldn't register cable notifier\n");
-   return ret;
-   }
+   dwc->edev_nb.notifier_call = dwc3_drd_notifier;
+   ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
+  >edev_nb);
+   if (ret < 0) {
+   dev_err(dwc->dev, "couldn't register cable notifier\n");
+   return ret;
}
 
dwc3_drd_update(dwc);
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC

[Andrzej Hajda]

OF graph describes USB data lanes between USB-PHY and respective MUIC.
Since graph is present and DWC driver can use it to get extcon, obsolete
extcon property can be removed.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 427ff861b441..b20b42659206 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -828,6 +828,17 @@
};
};
};
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   muic_to_usb: endpoint {
+   remote-endpoint = 
<_to_muic>;
+   };
+   };
};
};
 
@@ -1242,12 +1253,17 @@
 
 _dwc3 {
dr_mode = "otg";
-   extcon = <>;
 };
 
 _phy {
vbus-supply = <_reg>;
status = "okay";
+
+   port {
+   usb_to_muic: endpoint {
+   remote-endpoint = <_to_usb>;
+   };
+   };
 };
 
  {
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 0/5] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi,

This patchset introduces USB physical connector bindings, together with working 
example.
I have added comments in relevant patches to describe possible issues.
In v2 I have addressed comments by Rob and Laurent, thanks 
Changes are described in patches.

Regards
Andrzej


Andrzej Hajda (4):
  dt-bindings: add bindings for USB physical connector
  arm64: dts: exynos: add micro-USB connector node to TM2 platforms
  arm64: dts: exynos: add OF graph between MHL and USB connector
  extcon: add possibility to get extcon device by OF node

Maciej Purski (1):
  drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

 .../bindings/connector/usb-connector.txt   | 48 +++
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 37 -
 drivers/extcon/extcon.c| 44 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c   | 97 +-
 include/linux/extcon.h |  6 ++
 5 files changed, 216 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 3/5] arm64: dts: exynos: add OF graph between MHL and USB connector

[Andrzej Hajda]

OF graph describes MHL data lanes between MHL and respective USB
connector.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 +++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index e5a6a2303060..427ff861b441 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -779,9 +779,22 @@
clocks = <_system_controller 0>;
clock-names = "xtal";
 
-   port {
-   mhl_to_hdmi: endpoint {
-   remote-endpoint = <_to_mhl>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   mhl_to_musb_con: endpoint {
+   remote-endpoint = <_con_to_mhl>;
+   };
};
};
};
@@ -803,6 +816,18 @@
compatible = "usb-b-connector";
label = "micro-USB";
type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   musb_con_to_mhl: endpoint {
+   remote-endpoint = 
<_to_musb_con>;
+   };
+   };
+   };
+   };
};
};
 
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 5/5] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

From: Maciej Purski <m.pur...@samsung.com>

Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.

Signed-off-by: Maciej Purski <m.pur...@samsung.com>
Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.

Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 97 ++--
 1 file changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9e785b8e0ea2..565cc352ca81 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -81,6 +83,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620 
*ctx)
ctx->rc_dev = rc_dev;
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+   if (state == ctx->cable_state)
+   return;
+
+   ctx->cable_state = state;
+
+   if (state > 0)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   schedule_work(>extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   struct device_node *musb, *muic;
+   int ret;
+
+   /* get micro-USB connector node */
+   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+   /* next get micro-USB Interface Controller node */
+   muic = of_get_next_parent(musb);
+
+   if (!muic) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   return 0;
+   }
+
+   edev = extcon_get_edev_by_of_node(muic);
+   of_node_put(muic);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   INIT_WORK(>extcon_wq, sii8620_extcon_work);
+   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
 
-   sii8620_cable_in(ctx);
+   if (!ctx->extcon)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client)
 {
struct sii8620 *ctx = i2c_get_clientdata(client);
 
-   disable_irq(to_i2c_client(ctx->

[RFC PATCH v2 4/5] extcon: add possibility to get extcon device by OF node

[Andrzej Hajda]

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
Acked-by: Chanwoo Choi <cw00.c...@samsung.com>
---
v2: changed label to follow local convention (Chanwoo)
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..c4972c4cb3bd 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
+ * @node   : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(_dev_list_lock);
+   list_for_each_entry(edev, _dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto out;
+   edev = ERR_PTR(-EPROBE_DEFER);
+out:
+   mutex_unlock(_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(_dev_list_lock);
-   list_for_each_entry(edev, _dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(_dev_list_lock);
+   edev = extcon_get_edev_by_of_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_get_edev_by_of_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 6d94e82c8ad9..b47e0c7f01fe 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -283,6 +284,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_get_edev_by_of_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

These bindings allow to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriate graph bindings.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
v2:
- moved connector type(A,B,C) to compatible string (Rob),
- renamed size property to type (Rob),
- changed type description to be less confusing (Laurent),
- removed vendor specific compatibles (implied by graph port number),
- added requirement of connector being a child of IC (Rob),
- removed max-mode (subtly suggested by Rob, it should be detected anyway
  by USB Controller in runtime, downside is that device is not able to
  report its real capabilities, maybe better would be to make it optional(?)),
- assigned port numbers to data buses (Rob).

Regards
Andrzej

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 .../bindings/connector/usb-connector.txt   | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..02020f5d760a
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,48 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"usb-a-connector", "usb-b-connector", "usb-c-connector",
+
+Optional properties:
+- label: symbolic name for the connector
+- type: size of the connector, should be specified in case of USB-A, USB-B
+  non-standard (large) connector sizes: "mini", "micro"
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+  specified in bindings/graph.txt, unless the bus is between parent node and
+  the connector. Since single connector can have multpile data buses every bus
+  has assigned OF graph port number as follows:
+0: High Speed (HS), present in all connectors,
+1: Super Speed (SS), present in SS capable connectors,
+2: Sideband use (SBU), present in USB-C,
+3: Mobile High-Definition Link (MHL), present in 11-pin Samsung micro-USB
+
+Example
+---
+
+muic_max77843@66 {
+   ...
+   musb_con: connector {
+   compatible = "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@3 {
+   reg = <3>;
+   musb_con_mhl_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+};
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH v2 2/5] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

[Andrzej Hajda]

Since USB connector bindings are available we can describe it on TM2(e).

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index a1e93d91a3ed..e5a6a2303060 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -798,6 +798,12 @@
 
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+   musb_con: musb_connector {
+   compatible = "usb-b-connector";
+   label = "micro-USB";
+   type = "micro";
+   };
};
 
regulators {
-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi Laurent,

Thank you for the review.

On 18.10.2017 17:11, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch.
>
> On Thursday, 28 September 2017 16:07:27 EEST Andrzej Hajda wrote:
>> These bindings allows to describe most known standard USB connectors
>> and it should be possible to extend it if necessary.
>> USB connectors, beside USB can be used to route other protocols,
>> for example UART, Audio, MHL. In such case every device passing data
>> through the connector should have appropriate graph bindings.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>> There are few things for discussion (IMO):
>> 1. vendor specific connectors, I have added them here, but maybe better is
>>to place them in separate files.
> It's useful to have one vendor-specific compatible string to be used in the 
> example. We could split vendor-specific connectors to separate files later if 
> needed, but for now I'm fine keeping them here.
>
>> 2. physical connector description - I have split it to three properties:
>>type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
>>This tripled is able to describe all USB-standard connectors, but there
>>are also impossible combinations, for example(c, *, micro). Maybe better
>>would be to just enumerate all possible connectors in include file.
> I don't have a strong opinion on this. The three properties are nicely 
> descriptive. You might want to list the valid combinations in the bindings 
> though.

According to Rob's suggestion in next iteration I will encode USB port
type into compatible ie:
- usb-a-connector,
- usb-b-connector,
- usb-c-connector.

Rob suggested also to encode there speed as well, but I am afraid it
will inflate number of compatibles:
(3 types: a, b, c) x (3 speed modes: hs, ss, ssplus) = 9 combinations

>> 3. Numbering of port/remote nodes, currently only 0 is assigned for
>> Interface Controller. Maybe other functions should be also assigned:
>>HS, SS, CC, SBU, ... whatever. Maybe functions should be described
>>as an additional property of remote node?
> Given that one of the main reasons this binding is needed is to describe MHL 
> connection to a USB connector, I think we'll need to define additional 
> functions, yes. I'm not sure yet how that should look like though.

Current idea is to encode it in port number.

>
>> ---
>>  .../bindings/connector/usb-connector.txt   | 49 +++
>>  1 file changed, 49 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>
>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt new file
>> mode 100644
>> index ..f3a4e85122d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> @@ -0,0 +1,49 @@
>> +USB Connector
>> +=
>> +
>> +Required properties:
>> +- compatible: "usb-connector"
>> +  connectors with vendor specific extensions can add one of additional
>> +  compatibles:
>> +"samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
>> +- type: the USB connector type: "a", "b", "ab", "c"
>> +- max-mode: max USB speed mode supported by the connector:
>> +  "ls", "fs", "hs", "ss", "ss+"
>> +
>> +Optional properties:
>> +- label: a symbolic name for the connector
>> +- size: size of the connector, should be specified in case of
>> +  non-standard USB connectors: "mini", "micro", "powered"
> "non-standard" sounds like "vendor-specific", while I assume you're talking 
> about the size. The USB specification uses the term "standard" for this 
> purpose, so it's hard to use another one that would convey the right meaning 
> precisely. Maybe "non-standard ('large') USB connector sizes" ?

OK.

And answer for your question from other e-mail:
> One more comment, do I assume correctly that the Samsung 11-pin connector 
> carries USB and MHL on different pins ?

Yes, there are three additional pins: MHL_DP, MHL_DN and MHL_ID [1].

[1]:
https://ae01.alicdn.com/kf/HTB1nn.6KVaNXFXXq6xXFXXXc/221542210/HTB1nn.6KVaNXFXXq6xXFXXXc.jpg?size=69211=700=700=dcababf11610a489d451d7cb0b8ab60e

Thanks
Andrzej

>
>> +Required nodes:
>> +- any data bus to the connector should be modeled using the
>> +  OF graph bindings specified in bindings/graph.txt.
>>

Re: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 06.10.2017 19:23, Rob Herring wrote:
> On Fri, Oct 6, 2017 at 6:10 AM, Andrzej Hajda <a.ha...@samsung.com> wrote:
>> Hi Rob,
>>
>> Thanks for review.
>>
>> On 06.10.2017 01:12, Rob Herring wrote:
>>> On Thu, Sep 28, 2017 at 03:07:27PM +0200, Andrzej Hajda wrote:
>>>> These bindings allows to describe most known standard USB connectors
>>>> and it should be possible to extend it if necessary.
>>>> USB connectors, beside USB can be used to route other protocols,
>>>> for example UART, Audio, MHL. In such case every device passing data
>>>> through the connector should have appropriate graph bindings.
>>> Yay!
>>>
>>>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>>>> ---
>>>> There are few things for discussion (IMO):
>>>> 1. vendor specific connectors, I have added them here, but maybe better is
>>>>to place them in separate files.
>>> I'd worry about the standard connectors first, but probably good to have
>>> an idea of how vendor connectors need to be extended.
>>>
>>>> 2. physical connector description - I have split it to three properties:
>>>>type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
>>>>This tripled is able to describe all USB-standard connectors, but there
>>>>are also impossible combinations, for example(c, *, micro). Maybe better
>>>>would be to just enumerate all possible connectors in include file.
>>> We did "type" for hdmi-connector, but I think I'd really prefer
>>> compatible be used to distinguish as least where it may matter to s/w.
>>> In the HDMI case, they all are pretty much the same, just different
>>> physical size.
>> I guess that from S/W point of view only matters:
>> - which IP is connected to which part of the connector, and this can be
>> handled by port node(s),
>> - Type: A, B, C
>> - probably maximal supported speed of the connector - for example SS+
>> connectors have the same wires but different electrical characteristics
>> than SS as I understand,
>>
>> With this in mind maybe we can drop 'type' and introduce following
>> compatibles:
>> - usb-a-connector,
>> - usb-b-connector,
>> - usb-c-connector.
>> Encoding other properties in compatible would explode their number, so I
>> would prefer to avoid it.
>> I would leave other props:
>> max-speed: hs, ss, ss+,
>> (optional)size: micro, mini
>>
>> I would drop also unpopular/obsolete variants: type-ab, powered, they
>> can be added later if necessary.
>>
>> Just for reference, list of connectors defined by USB (>= 2) specifications:
>> 1. USB 2.0 (with later amendments):
>> - Standard-A plug and receptacle
>> - Standard-B plug and receptacle
>> - Mini-B plug and receptacle
>> - Micro-B plug and receptacle
>> - Micro-AB receptacle
>> - Micro-A plug
>> 2. USB 3.0:
>> - USB 3.0 Standard-A plug and receptacle
>> - USB 3.0 Standard-B plug and receptacle
>> - USB 3.0 Powered-B plug and receptacle
>> - USB 3.0 Micro-B plug and receptacle
>> - USB 3.0 Micro-A plug
>> - USB 3.0 Micro-AB receptacle
>> 3. USB 3.1:
>> - Enhanced SuperSpeed Standard-A plug and receptacle
>> - Enhanced SuperSpeed Standard-B plug and receptacle
>> - Enhanced SuperSpeed Micro-B plug and receptacle
>> - Enhanced SuperSpeed Micro-A plug
>> - Enhanced SuperSpeed Micro-AB receptacle
>> 4. USB-C (release 1.3):
>> - USB Full-Featured Type-C receptacle
>> - USB 2.0 Type-C receptacle
>> - USB Full-Featured Type-C plug
>> - USB 2.0 Type-C plug
>> - USB Type-C Power-Only plug
>>
>>>> 3. Numbering of port/remote nodes, currently only 0 is assigned for 
>>>> Interface
>>>>Controller. Maybe other functions should be also assigned:
>>>>HS, SS, CC, SBU, ... whatever. Maybe functions should be described
>>>>as an additional property of remote node?
>>> child of the controller is also an option. There's already prec
>> Shall we support both solutions or just make one mandatory?
> Oops, I was just going to say for display, there's already precedent
> that ports are used. So that means at least SS should just be
> described with ports. Then HS probably should be a port too just to be
> symmetrical.
>
> The connector being a child of the USB-PD (or other controller chip)
> is probably the only thing that makes sense. I guess the question is
> whether there are cases where that doesn't m

Re: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi Rob,

Thanks for review.

On 06.10.2017 01:12, Rob Herring wrote:
> On Thu, Sep 28, 2017 at 03:07:27PM +0200, Andrzej Hajda wrote:
>> These bindings allows to describe most known standard USB connectors
>> and it should be possible to extend it if necessary.
>> USB connectors, beside USB can be used to route other protocols,
>> for example UART, Audio, MHL. In such case every device passing data
>> through the connector should have appropriate graph bindings.
> Yay!
>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>> There are few things for discussion (IMO):
>> 1. vendor specific connectors, I have added them here, but maybe better is
>>to place them in separate files.
> I'd worry about the standard connectors first, but probably good to have 
> an idea of how vendor connectors need to be extended.
>
>> 2. physical connector description - I have split it to three properties:
>>type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
>>This tripled is able to describe all USB-standard connectors, but there
>>are also impossible combinations, for example(c, *, micro). Maybe better
>>would be to just enumerate all possible connectors in include file.
> We did "type" for hdmi-connector, but I think I'd really prefer 
> compatible be used to distinguish as least where it may matter to s/w. 
> In the HDMI case, they all are pretty much the same, just different 
> physical size.

I guess that from S/W point of view only matters:
- which IP is connected to which part of the connector, and this can be
handled by port node(s),
- Type: A, B, C
- probably maximal supported speed of the connector - for example SS+
connectors have the same wires but different electrical characteristics
than SS as I understand,

With this in mind maybe we can drop 'type' and introduce following
compatibles:
- usb-a-connector,
- usb-b-connector,
- usb-c-connector.
Encoding other properties in compatible would explode their number, so I
would prefer to avoid it.
I would leave other props:
max-speed: hs, ss, ss+,
(optional)size: micro, mini

I would drop also unpopular/obsolete variants: type-ab, powered, they
can be added later if necessary.

Just for reference, list of connectors defined by USB (>= 2) specifications:
1. USB 2.0 (with later amendments):
- Standard-A plug and receptacle
- Standard-B plug and receptacle
- Mini-B plug and receptacle
- Micro-B plug and receptacle
- Micro-AB receptacle
- Micro-A plug
2. USB 3.0:
- USB 3.0 Standard-A plug and receptacle
- USB 3.0 Standard-B plug and receptacle
- USB 3.0 Powered-B plug and receptacle
- USB 3.0 Micro-B plug and receptacle
- USB 3.0 Micro-A plug
- USB 3.0 Micro-AB receptacle
3. USB 3.1:
- Enhanced SuperSpeed Standard-A plug and receptacle
- Enhanced SuperSpeed Standard-B plug and receptacle
- Enhanced SuperSpeed Micro-B plug and receptacle
- Enhanced SuperSpeed Micro-A plug
- Enhanced SuperSpeed Micro-AB receptacle
4. USB-C (release 1.3):
- USB Full-Featured Type-C receptacle
- USB 2.0 Type-C receptacle
- USB Full-Featured Type-C plug
- USB 2.0 Type-C plug
- USB Type-C Power-Only plug

>> 3. Numbering of port/remote nodes, currently only 0 is assigned for Interface
>>Controller. Maybe other functions should be also assigned:
>>HS, SS, CC, SBU, ... whatever. Maybe functions should be described
>>as an additional property of remote node?
> child of the controller is also an option. There's already prec

Shall we support both solutions or just make one mandatory?

>
>> ...
>>
>> Regards
>> Andrzej
>> ---
>>  .../bindings/connector/usb-connector.txt   | 49 
>> ++
>>  1 file changed, 49 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>
>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> new file mode 100644
>> index ..f3a4e85122d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> @@ -0,0 +1,49 @@
>> +USB Connector
>> +=
>> +
>> +Required properties:
>> +- compatible: "usb-connector"
>> +  connectors with vendor specific extensions can add one of additional
>> +  compatibles:
>> +"samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
>> +- type: the USB connector type: "a", "b", "ab", "c"
>> +- max-mode: max USB speed mode supported by the connector:
>> +  "ls", "fs", "hs", "ss", "ss+"
> Do we really see cases where

[RFC PATCH 4/4] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

[Andrzej Hajda]

From: Maciej Purski <m.pur...@samsung.com>

Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.

Signed-off-by: Maciej Purski <m.pur...@samsung.com>
Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.

Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 98 ++--
 1 file changed, 95 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 5131bfb94f06..6f40cbc2445e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -78,6 +80,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2102,6 +2108,78 @@ static void sii8620_cable_in(struct sii8620 *ctx)
enable_irq(to_i2c_client(ctx->dev)->irq);
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+   if (state == ctx->cable_state)
+   return;
+
+   ctx->cable_state = state;
+
+   if (state > 0)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   schedule_work(>extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   struct device_node *musb, *muic;
+   int ret;
+
+   /* get micro-USB connector node */
+   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+   /* next get micro-USB Interface Controller node */
+   muic = of_graph_get_remote_node(musb, -1, 0);
+   of_node_put(musb);
+
+   if (!muic) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   return 0;
+   }
+
+   edev = extcon_get_edev_by_of_node(muic);
+   of_node_put(muic);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   INIT_WORK(>extcon_wq, sii8620_extcon_work);
+   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2201,13 +2279,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
 
-   sii8620_cable_in(ctx);
+   if (!ctx->extcon)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2216,9 +2301,16 @@ static int sii8620_remove(struct i2c_client *client)
 {
struct sii8620 *ctx = i2c_get_clientdata(client);
 
-   di

[RFC PATCH 3/4] extcon: add possibility to get extcon device by of node

[Andrzej Hajda]

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..fdb8c1d767c1 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
+ * @node   : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(_dev_list_lock);
+   list_for_each_entry(edev, _dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto end;
+   edev = ERR_PTR(-EPROBE_DEFER);
+end:
+   mutex_unlock(_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(_dev_list_lock);
-   list_for_each_entry(edev, _dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(_dev_list_lock);
+   edev = extcon_get_edev_by_of_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_get_edev_by_of_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 744d60ca80c3..2f88e7491672 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -261,6 +261,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -382,6 +383,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_get_edev_by_of_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 0/4] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

Hi,

This patchset introduces USB connector bindings, together with working example.
I have added comments in relevant patches to describe possible issues.

Regards
Andrzej


Andrzej Hajda (3):
  dt-bindings: add bindings for USB physical connector
  arm64: dts: exynos: add micro-USB connector node to TM2 platforms
  extcon: add possibility to get extcon device by of node

Maciej Purski (1):
  drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

 .../bindings/connector/usb-connector.txt   | 49 +++
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 47 ++-
 drivers/extcon/extcon.c| 44 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c   | 98 +-
 include/linux/extcon.h |  6 ++
 5 files changed, 228 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 2/4] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

[Andrzej Hajda]

Since USB connector bindings are available we can describe it on TM2(e).

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 47 --
 1 file changed, 44 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index e30bae4cf878..39b1ca0ef4cd 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -135,6 +135,28 @@
"RCV", "HPOUT3R";
status = "okay";
};
+
+   musb_con: musb_connector {
+   compatible = "samsung,usb-connector-11pin", "usb-connector";
+   label = "micro-usb";
+   type = "b";
+   size = "micro";
+   max-mode = "hs";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   musb_con_to_muic: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_to_musb_con>;
+   };
+   musb_con_to_mhl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_to_musb_con>;
+   };
+   };
+   };
 };
 
  {
@@ -768,9 +790,22 @@
clocks = <_system_controller 0>;
clock-names = "xtal";
 
-   port {
-   mhl_to_hdmi: endpoint {
-   remote-endpoint = <_to_mhl>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   mhl_to_musb_con: endpoint {
+   remote-endpoint = <_con_to_mhl>;
+   };
};
};
};
@@ -787,6 +822,12 @@
 
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+   port {
+   muic_to_musb_con: endpoint@0 {
+   remote-endpoint = <_con_to_muic>;
+   };
+   };
};
 
regulators {
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

These bindings allows to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriate graph bindings.

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
There are few things for discussion (IMO):
1. vendor specific connectors, I have added them here, but maybe better is
   to place them in separate files.
2. physical connector description - I have split it to three properties:
   type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
   This tripled is able to describe all USB-standard connectors, but there
   are also impossible combinations, for example(c, *, micro). Maybe better
   would be to just enumerate all possible connectors in include file.
3. Numbering of port/remote nodes, currently only 0 is assigned for Interface
   Controller. Maybe other functions should be also assigned:
   HS, SS, CC, SBU, ... whatever. Maybe functions should be described
   as an additional property of remote node?
...

Regards
Andrzej
---
 .../bindings/connector/usb-connector.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..f3a4e85122d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,49 @@
+USB Connector
+=
+
+Required properties:
+- compatible: "usb-connector"
+  connectors with vendor specific extensions can add one of additional
+  compatibles:
+"samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
+- type: the USB connector type: "a", "b", "ab", "c"
+- max-mode: max USB speed mode supported by the connector:
+  "ls", "fs", "hs", "ss", "ss+"
+
+Optional properties:
+- label: a symbolic name for the connector
+- size: size of the connector, should be specified in case of
+  non-standard USB connectors: "mini", "micro", "powered"
+
+Required nodes:
+- any data bus to the connector should be modeled using the
+  OF graph bindings specified in bindings/graph.txt.
+  There should be exactly one port with at least one endpoint to
+  different device nodes. The first endpoint (reg = <0>) should
+  point to USB Interface Controller.
+
+Example
+---
+
+musb_con: connector {
+   compatible = "samsung,usb-connector-11pin", "usb-connector";
+   label = "usb";
+   type = "b";
+   size = "micro";
+   max-mode = "hs";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   musb_con_usb_in: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_usb_out>;
+   };
+
+   musb_con_mhl_in: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out>;
+   };
+   };
+};
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/7] usb: gadget: fsl_qe_udc: fix IS_ERR_VALUE usage

[Andrzej Hajda]

IS_ERR_VALUE macro should be used only with unsigned long type.
Otherwise it can work incorrectly.

The patch follows conclusion from discussion on LKML [1][2].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2120927
[2]: http://permalink.gmane.org/gmane.linux.kernel/2150581

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/usb/gadget/udc/fsl_qe_udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c 
b/drivers/usb/gadget/udc/fsl_qe_udc.c
index 53c0692..93d28cb 100644
--- a/drivers/usb/gadget/udc/fsl_qe_udc.c
+++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
@@ -2340,7 +2340,7 @@ static struct qe_udc *qe_udc_config(struct 
platform_device *ofdev)
 {
struct qe_udc *udc;
struct device_node *np = ofdev->dev.of_node;
-   unsigned int tmp_addr = 0;
+   unsigned long tmp_addr = 0;
struct usb_device_para __iomem *usbpram;
unsigned int i;
u64 size;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/7] fix IS_ERR_VALUE usage

[Andrzej Hajda]

Hi,

This small set of independent patches tries to fix incorrect
IS_ERR_VALUE macro usage. It fixes most usages leading to errors
as described in [1]. It also follows conclusion from the discussion
[1][2] - IS_ERR_VALUE should be used only with unsigned long type,
signed types should use comparison 'ret < 0'.

The patchset does not fix errors present in net/ethernet/freescale
and soc/fsq/qe drivers - these drivers mixes different types:
dma_addr_t, u32, unsigned long, fixing it properly seems to me more
challenging, maybe maintainers or brave volunteers can look it.

The list of missing fixes:
drivers/net/ethernet/freescale/fs_enet/mac-scc.c:149:36-37: WARNING: incorrect 
argument type in IS_ERR_VALUE(fep -> ring_mem_addr)
drivers/net/ethernet/freescale/ucc_geth.c:2237:48-49: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> tx_bd_ring_offset [ j ])
drivers/net/ethernet/freescale/ucc_geth.c:2314:48-49: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> rx_bd_ring_offset [ j ])
drivers/net/ethernet/freescale/ucc_geth.c:2524:44-45: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> tx_glbl_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2544:45-46: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> thread_dat_tx_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2571:46-47: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> send_q_mem_reg_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2612:42-43: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> scheduler_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2659:54-55: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> tx_fw_statistics_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2696:44-45: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> rx_glbl_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2715:45-46: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> thread_dat_rx_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2736:54-55: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> rx_fw_statistics_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2756:53-54: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> rx_irq_coalescing_tbl_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2822:44-45: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> rx_bd_qs_tbl_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2908:47-48: WARNING: incorrect 
argument type in IS_ERR_VALUE(ugeth -> exf_glbl_param_offset)
drivers/net/ethernet/freescale/ucc_geth.c:292:36-37: WARNING: incorrect 
argument type in IS_ERR_VALUE(init_enet_offset)
drivers/net/ethernet/freescale/ucc_geth.c:3042:39-40: WARNING: incorrect 
argument type in IS_ERR_VALUE(init_enet_pram_offset)
drivers/soc/fsl/qe/ucc_fast.c:271:60-61: WARNING: incorrect argument type in 
IS_ERR_VALUE(uccf -> ucc_fast_tx_virtual_fifo_base_offset)
drivers/soc/fsl/qe/ucc_fast.c:284:60-61: WARNING: incorrect argument type in 
IS_ERR_VALUE(uccf -> ucc_fast_rx_virtual_fifo_base_offset)
drivers/soc/fsl/qe/ucc_slow.c:186:38-39: WARNING: incorrect argument type in 
IS_ERR_VALUE(uccs -> us_pram_offset)
drivers/soc/fsl/qe/ucc_slow.c:213:38-39: WARNING: incorrect argument type in 
IS_ERR_VALUE(uccs -> rx_base_offset)
drivers/soc/fsl/qe/ucc_slow.c:224:38-39: WARNING: incorrect argument type in 
IS_ERR_VALUE(uccs -> tx_base_offset)
drivers/net/ethernet/freescale/fs_enet/mac-fcc.c:110:35-36: WARNING: unknown 
argument type in IS_ERR_VALUE(fpi -> dpram_offset)

[1]: http://permalink.gmane.org/gmane.linux.kernel/2120927
[2]: http://permalink.gmane.org/gmane.linux.kernel/2150581

Regards
Andrzej


Andrzej Hajda (7):
  netfilter: fix IS_ERR_VALUE usage
  MIPS: module: fix incorrect IS_ERR_VALUE macro usages
  drivers: char: mem: fix IS_ERROR_VALUE usage
  atmel-isi: fix IS_ERR_VALUE usage
  serial: clps711x: fix IS_ERR_VALUE usage
  fbdev: exynos: fix IS_ERR_VALUE usage
  usb: gadget: fsl_qe_udc: fix IS_ERR_VALUE usage

 arch/mips/kernel/module-rela.c|  2 +-
 arch/mips/kernel/module.c |  2 +-
 drivers/char/mem.c|  2 +-
 drivers/media/platform/soc_camera/atmel-isi.c |  4 ++--
 drivers/tty/serial/clps711x.c | 14 --
 drivers/usb/gadget/udc/fsl_qe_udc.c   |  2 +-
 drivers/video/fbdev/exynos/exynos_mipi_dsi.c  |  6 +++---
 include/linux/netfilter/x_tables.h|  6 +++---
 net/ipv4/netfilter/arp_tables.c   | 11 +++
 net/ipv4/netfilter/ip_tables.c| 12 
 net/ipv6/netfilter/ip6_tables.c   | 13 +
 11 files changed, 44 insertions(+), 30 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/38] Fixes related to incorrect usage of unsigned types

[Andrzej Hajda]

On 09/21/2015 03:42 PM, David Howells wrote:
> Andrzej Hajda <a.hajda-sze3o3uu22jbdgjk7y7...@public.gmane.org> wrote:
> 
>> Semantic patch finds comparisons of types:
>> unsigned < 0
>> unsigned >= 0
>> The former is always false, the latter is always true.
>> Such comparisons are useless, so theoretically they could be
>> safely removed, but their presence quite often indicates bugs.
> 
> Or someone has left them in because they don't matter and there's the
> possibility that the type being tested might be or become signed under some
> circumstances.  If the comparison is useless, I'd expect the compiler to just
> discard it - for such cases your patch is pointless.
> 
> If I have, for example:
> 
>   unsigned x;
> 
>   if (x == 0 || x > 27)
>   give_a_range_error();
> 
> I will write this as:
> 
>   unsigned x;
> 
>   if (x <= 0 || x > 27)
>   give_a_range_error();
> 
> because it that gives a way to handle x being changed to signed at some point
> in the future for no cost.  In which case, your changing the <= to an ==
> "because the < part of the case is useless" is arguably wrong.

This is why I have not checked for such cases - I have skipped checks of type
unsigned <= 0
exactly for the reasons above.

However I have left two other checks as they seems to me more suspicious - they
are always true or false. But as Dmitry and Andrew pointed out Linus have quite
strong opinion against removing range checks in such cases as he finds it
clearer. I think it applies to patches 29-36. I am not sure about patches 
26-28,37.

Regards
Andrzej

> 
> David
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo-u79uwxl29ty76z2rm5m...@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 27/38] usbnet: remove invalid check

[Andrzej Hajda]

skb->len is always non-negative.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/net/usb/lan78xx.c  | 5 -
 drivers/net/usb/smsc75xx.c | 5 -
 drivers/net/usb/smsc95xx.c | 5 -
 3 files changed, 15 deletions(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index a39518f..e0556dc 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2522,11 +2522,6 @@ static int lan78xx_rx(struct lan78xx_net *dev, struct 
sk_buff *skb)
skb_pull(skb, align_count);
}
 
-   if (unlikely(skb->len < 0)) {
-   netdev_warn(dev->net, "invalid rx length<0 %d", skb->len);
-   return 0;
-   }
-
return 1;
 }
 
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index d9e7892..30033db 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -2185,11 +2185,6 @@ static int smsc75xx_rx_fixup(struct usbnet *dev, struct 
sk_buff *skb)
skb_pull(skb, align_count);
}
 
-   if (unlikely(skb->len < 0)) {
-   netdev_warn(dev->net, "invalid rx length<0 %d\n", skb->len);
-   return 0;
-   }
-
return 1;
 }
 
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 26423ad..66b3ab9 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1815,11 +1815,6 @@ static int smsc95xx_rx_fixup(struct usbnet *dev, struct 
sk_buff *skb)
skb_pull(skb, align_count);
}
 
-   if (unlikely(skb->len < 0)) {
-   netdev_warn(dev->net, "invalid rx length<0 %d\n", skb->len);
-   return 0;
-   }
-
return 1;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/38] usb: host: ehci-msm: fix handling platform_get_irq result

[Andrzej Hajda]

The function can return negative values.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
---
 drivers/usb/host/ehci-msm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 275c92e..c4f84c8 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -80,12 +80,12 @@ static int ehci_msm_probe(struct platform_device *pdev)
return  -ENOMEM;
}
 
-   hcd->irq = platform_get_irq(pdev, 0);
-   if (hcd->irq < 0) {
+   ret = platform_get_irq(pdev, 0);
+   if (ret < 0) {
dev_err(>dev, "Unable to get IRQ resource\n");
-   ret = hcd->irq;
goto put_hcd;
}
+   hcd->irq = ret;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/21] On-demand device registration

[Andrzej Hajda]

On 06/10/2015 12:19 PM, Tomeu Vizoso wrote:
 On 10 June 2015 at 09:30, Linus Walleij linus.wall...@linaro.org wrote:
 On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:
 On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote:

 This is what systemd is doing in userspace for starting services:
 ask for your dependencies and wait for them if they are not
 there. So drivers ask for resources and wait for them. It also
 needs to be abstract, so for example we need to be able to
 hang on regulator_get() until the driver is up and providing that
 regulator, and as long as everything is in slowpath it should
 be OK. (And vice versa mutatis mutandis for clk, gpio, pin
 control, interrupts (!) and DMA channels for example.)

 I understood above that you propose probing devices in order, but now
 you mention that resource getters would block until the dependency is
 fulfilled which confuses me because if we are probing in order then
 all dependencies would be fulfilled before the device in question gets
 probed.

 Sorry, the problem space is a bit convoluted so the answers
 get a bit convoluted. Maybe I'm thinking aloud and altering the course
 of my thoughts as I type...

 I guess there can be explicit dependencies for resources like this
 patch does, but another way would be for all resource fetch functions
 to be instrumented, so that you do not block until you try to take
 a resource that is not yet there, e.g.:

 regulator_get(...) - not available, so:
 - identify target regulator provider - this will need instrumentation
 - probe it

 It then turns out the regulator driver is on the i2c bus, so we
 need to probe the i2c driver:
 - identify target i2c host for the regulator driver - this will need
   instrumentation
 - probe the i2c host driver

 i2c host comes out, probes the regulator driver, regulator driver
 probes and then the regulator_get() call returns.
 
 Hmm, if I understand correctly what you say, this is exactly what this
 particular series does:
 
 regulator_get - of_platform_device_ensure - probe() on the platform
 device that encloses the requested device node (i2c host) - i2c slave
 gets probed and the regulator registered - regulator_get returns the
 requested resource

The downside of this solution is that it will not work without device
tree or even without device dependencies not explicitly specified in
device tree.

 
 The downside I'm currently looking at is that an explicit dependency
 graph would be useful to have for other purposes. For example to print
 a neat warning when a dependency cannot be fulfilled. Or to refuse to
 unbind a device which other devices depend on,

As I understand Greg you cannot prevent unbinding by design, see [1].

[1]: http://thread.gmane.org/gmane.linux.kernel/1154308/focus=1154648

 or to automatically
 unbind the devices that depend on it,

What about devices that have weak dependency? They should not be unbound
but they should be somehow noticed about unbinding.

In general many kernel frameworks are broken in handling hot-unbinding
of drivers, consumers are not noticed about unbinding of their resource
providers and usually they stay with broken handles or handles to dummy
resources.

I suspect the only proper solution for handling resources that can
dynamically appear/disappear is to provide notification to their
consumers about appearance change of the resource.

I have proposed some times ago solution for above problems based on the
statement above, cover letter explains it in more detail [2].
In short it solves following issues:
- consumer receives resource as soon as it becomes available,
- consumer is notified just before resource removal,
- it can properly handle provider unbind/re-bind,
- it avoids late init due to deferred probing,
- it allows to track optional resources.

[2]: http://thread.gmane.org/gmane.linux.kernel.gpio/5201

Regards
Andrzej

 or to print a warning if a
 device is hotplugged off and other devices depend on it.
 
 This requires instrumentation on anything providing a resource
 to another driver like those I mentioned and a lot of overhead
 infrastructure, but I think it's the right approach. However I don't
 know if I would ever be able to pull that off myself, I know talk
 is cheap and I should show the code instead.
 
 Yeah, if you can give it a second look and say if it matches what you
 wrote above, it would be very much appreciated.
 
 Deepest respect for your efforts!
 
 Thanks!
 
 Tomeu
 
 Yours,
 Linus Walleij
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
 --
 To unsubscribe from this list: send the line unsubscribe linux-gpio in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to