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

2018-02-21 Thread 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 
---
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 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

2018-02-21 Thread Andrzej Hajda 
OF graph describes MHL data lanes between MHL and respective USB
connector.

Signed-off-by: Andrzej Hajda 
---
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 5/6] extcon: add possibility to get extcon device by OF node

2018-02-21 Thread 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 
Acked-by: Chanwoo Choi 
---
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 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector

2018-02-21 Thread 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 
Reviewed-by: Rob Herring 
---
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 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

2018-02-21 Thread Andrzej Hajda 
From: Maciej Purski 

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 
Signed-off-by: Andrzej Hajda 
---
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 
---
 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->dev)->irq);
-   sii8620_hw_off(ctx);
+   if (ctx->extcon) {
+   extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL,
+

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

2018-02-21 Thread 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 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

2018-02-21 Thread Andrzej Hajda 
Since USB connector bindings are available we can describe it on TM2(e).

Signed-off-by: Andrzej Hajda 
---
 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: [PATCH 3/7] usb: dwc3: pci: Store device properties dynamically

2018-02-21 Thread Andy Shevchenko 
On Tue, Feb 20, 2018 at 11:12 PM, Thinh Nguyen
 wrote:
> On 2/17/2018 7:29 AM, Andy Shevchenko wrote:
>> On Fri, Feb 16, 2018 at 11:55 PM, Thinh Nguyen
>>  wrote:
>>> Add the ability to add device properties dynamically. Currently, device
>>> properties are added to platform device using
>>> platform_device_add_properties(). However, this function does not allow
>>> adding properties incrementally. It is useful to have this ability when
>>> the driver needs to set common device properties across different HW
>>
>> I'm not sure it's useful anyhow.
>>
>>> or
>>> if IP and FPGA validation test different configurations for different
>>> HW.
>>
>> Shouldn't be a separate stuff for FPGA exclusively?
>
> Can you clarify/expand your question?

FPGA is the one which might have different properties at run time for
the same device.
So, why do we care on driver / generic level of it?

Shouldn't be FPGA manager take care of it (via DT overlays, for example)?

>>> To address this issue, update dwc3_pci to store device properties to
>>> an array and dynamically manage them here.
>>>
>>> Introduce two new functions to do so:
>>>   * dwc3_pci_add_one_property() - this function adds one property to
>>> dwc->properties array and increase its size as needed
>>>   * dwc3_pci_add_properties() - this function takes a null terminated
>>> array of device properties and add them to dwc->properties
>>
>> So, why you can't use ACPI / DT here?
>>
>
> dwc3_pci_add_properties() is a convenient function that takes statically
> allocated array of (quirks) properties for different HW and store them
> to dwc->properties. The idea is to add more properties on top of these
> required quirks.

Yes, I understand that. What's wrong with DT? The built-in device
properties have the same nature as usual properties for DT.
Whenever driver calls device_property_read_uXX() or alike it would
check all property provides for asked one.

Other than that, quirks esp. for FPGA sounds so wrong. Why in the
first place not to make non-broken hardware?!

-- 
With Best Regards,
Andy Shevchenko
--
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: [Regression] xhci: some hard drives cannot be seen using a JMicron JMS56x enclosure

2018-02-21 Thread Mathias Nyman 

On 19.02.2018 01:38, Cyril Roelandt wrote:

Hello,

I'm inlining my answers to your questions.

On 02/15/18 17:30, Mathias Nyman wrote:

On 15.02.2018 03:05, Cyril Roelandt wrote:

Hi,

I use two hard drives in an enclosure connected to my PC using UAS. The
enclosure is a JMicron JMS56x (152d:0562); the drives are a Fujitsu MHZ2160BH
G2 (2"5, 160GB) and a Western Digital EFRX-68N32N0 (3"5, 4TB).

Using a USB2 port, I can see both drives as expected. I used to be able to use
both drives using a USB3 port (and UAS) in Linux 4.11 and 4.12, but I am
experiencing a bug starting with Linux 4.13.



Did you see the:
"usb 4-2: device firmware changed"
message with 4.12 or older kernels?


No, I cannot see this message on a 4.11 kernel.

...



could you send full logs, both dynamic debug and xhci traces to me:

echo 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control

and

echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable

both the /sys/kernel/debug/tracing/trace and dmesg


Here is the output of dmesg:



Thanks, been staring at the logs for some time now.

I can see one issue on xhci side.

endpoint 3(IN) for xhci slot 2 uses two streams.

uas driver wants to cancel two URBS on this endpoint:
  URB1 (9e50d43afa80) located in stream ring 1 at 0x1a3704130
  URB2 (9e50d43af0c0) located in stream ring 2 at 0x1a3707080

xhci stops the endpoint to cancel the URBs, this causes both streams to stop.

For URB1 we notice xHC hw was currently working on the URB we want to cancel,
i.e. stream 1 stopped at the same location as URB1 (at 0x1a3704130).
xhci driver ask hardware to move past this position, and xhci driver gives back
URB1 as "cancelled". Stream 1 continue to work after this

For the second URB we don't notice that xHC hw is working on the same URB we
want to cancel, so we bluntly write over URB2  with zeroes, and driver gives
back URB2 as "cancelled".
Stream 2 does not recover, and the URB that is queued after this on stream 2 is
never handled. Stream 2 is stuck at the position of URB2 (0x1a3707080).

As the next URB on stream 2 is never given back it blocks usb_disconnect which
is waiting for all pending urbs to be given back.

could you change one flag in the xhci driver and take the same
set of logs? It will add more details about the URB and xHC hw position check.

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index cc368ad..f1b73e6 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -772,7 +772,7 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci, 
int slot_id,
hw_deq &= ~0xf;
 
if (trb_in_td(xhci, cur_td->start_seg, cur_td->first_trb,

- cur_td->last_trb, hw_deq, false)) {
+ cur_td->last_trb, hw_deq, true)) {
xhci_find_new_dequeue_state(xhci, slot_id, ep_index,
cur_td->urb->stream_id,
cur_td, _state);


Another thing not related to xhci is that the serial number seems to be changing
for this device after reset.
First log:
[Tue Feb  6 22:17:49 2018] usb 4-2: SerialNumber: RANDOM__8A4D7F833EEF
Second log:
[Sun Feb 18 22:46:01 2018] usb 2-2: SerialNumber: RANDOM__4157B7E21ACD

This causes the "usb 4-2: device firmware changed" messages, and usb core will
try to logically disconnect the device.

Can you also plug in and out the device a few times without changing the
drives in the enclosure, and check if the serial number really is changing.

Thanks
Mathias
--
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 v3] Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export tcpci_irq. More operations can be extended in tcpci_data if needed. According to TCPCI specification, 4.4.5.2 ROLE_C

2018-02-21 Thread ShuFanLee 
From: ShuFanLee 

Signed-off-by: ShuFanLee 
---
 drivers/staging/typec/tcpci.c | 128 +-
 drivers/staging/typec/tcpci.h |  13 +
 2 files changed, 115 insertions(+), 26 deletions(-)

 patch changelogs between v1 & v2
 - Remove unnecessary i2c_client in the structure of tcpci
 - Rename structure of tcpci_vendor_data to tcpci_data
 - Not exporting tcpci read/write wrappers but register i2c regmap in glue 
driver
 - Add set_vconn ops in tcpci_data
   (It is necessary for RT1711H to enable/disable idle mode before 
disabling/enabling vconn)
 - Export tcpci_irq so that vendor can call it in their own IRQ handler

 patch changelogs between v2 & v3
 - Change the return type of tcpci_irq from int to irqreturn_t
 - Disable IRQs and request threaded IRQ before registering tcpci port

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 9bd4412..4959c69 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -21,7 +21,6 @@
 
 struct tcpci {
struct device *dev;
-   struct i2c_client *client;
 
struct tcpm_port *port;
 
@@ -30,6 +29,12 @@ struct tcpci {
bool controls_vbus;
 
struct tcpc_dev tcpc;
+   struct tcpci_data *data;
+};
+
+struct tcpci_chip {
+   struct tcpci *tcpci;
+   struct tcpci_data data;
 };
 
 static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc)
@@ -37,8 +42,7 @@ static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev 
*tcpc)
return container_of(tcpc, struct tcpci, tcpc);
 }
 
-static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,
-   u16 *val)
+static int tcpci_read16(struct tcpci *tcpci, unsigned int reg, u16 *val)
 {
return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16));
 }
@@ -98,8 +102,10 @@ static int tcpci_set_cc(struct tcpc_dev *tcpc, enum 
typec_cc_status cc)
 static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
enum typec_cc_status cc)
 {
+   int ret;
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
-   unsigned int reg = TCPC_ROLE_CTRL_DRP;
+   unsigned int reg = (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
+  (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
 
switch (cc) {
default:
@@ -117,7 +123,19 @@ static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
break;
}
 
-   return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+   ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+   if (ret < 0)
+   return ret;
+   usleep_range(500, 1000);
+   reg |= TCPC_ROLE_CTRL_DRP;
+   ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+   if (ret < 0)
+   return ret;
+   ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
+  TCPC_CMD_LOOK4CONNECTION);
+   if (ret < 0)
+   return ret;
+   return 0;
 }
 
 static enum typec_cc_status tcpci_to_typec_cc(unsigned int cc, bool sink)
@@ -178,6 +196,16 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool 
enable)
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
int ret;
 
+   /* Handle vendor set vconn */
+   if (tcpci->data) {
+   if (tcpci->data->set_vconn) {
+   ret = tcpci->data->set_vconn(tcpci, tcpci->data,
+enable);
+   if (ret < 0)
+   return ret;
+   }
+   }
+
ret = regmap_write(tcpci->regmap, TCPC_POWER_CTRL,
   enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
if (ret < 0)
@@ -323,6 +351,15 @@ static int tcpci_init(struct tcpc_dev *tcpc)
if (time_after(jiffies, timeout))
return -ETIMEDOUT;
 
+   /* Handle vendor init */
+   if (tcpci->data) {
+   if (tcpci->data->init) {
+   ret = tcpci->data->init(tcpci, tcpci->data);
+   if (ret < 0)
+   return ret;
+   }
+   }
+
/* Clear all events */
ret = tcpci_write16(tcpci, TCPC_ALERT, 0x);
if (ret < 0)
@@ -344,9 +381,15 @@ static int tcpci_init(struct tcpc_dev *tcpc)
return tcpci_write16(tcpci, TCPC_ALERT_MASK, reg);
 }
 
-static irqreturn_t tcpci_irq(int irq, void *dev_id)
+static irqreturn_t _tcpci_irq(int irq, void *dev_id)
 {
struct tcpci *tcpci = dev_id;
+
+   return tcpci_irq(tcpci);
+}
+
+irqreturn_t tcpci_irq(struct tcpci *tcpci)
+{
u16 status;
 
tcpci_read16(tcpci, TCPC_ALERT, );
@@ -412,6 +455,7 @@ static irqreturn_t tcpci_irq(int irq, void *dev_id)
 
return IRQ_HANDLED;
 }
+EXPORT_SYMBOL_GPL(tcpci_irq);
 
 static const struct regmap_config tcpci_regmap_config = {
.reg_bits = 8,
@@ -435,22 +479,18 @@

[PATCH 4.14 151/167] usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT

2018-02-21 Thread Greg Kroah-Hartman 
4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit ec897569ad7dbc6d595873a487c3fac23f463f76 upstream.

Move the Kconfig symbols USB_UHCI_BIG_ENDIAN_MMIO and
USB_UHCI_BIG_ENDIAN_DESC out of drivers/usb/host/Kconfig, which is
conditional upon USB && USB_SUPPORT, so that it can be freely selected
by platform Kconfig symbols in architecture code.

For example once the MIPS_GENERIC platform selects are fixed in commit
2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN"), the MIPS
32r6_defconfig warns like so:

warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct 
dependencies (USB_SUPPORT && USB)
warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct 
dependencies (USB_SUPPORT && USB)

Fixes: 2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN")
Signed-off-by: James Hogan 
Cc: Corentin Labbe 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: linux-usb@vger.kernel.org
Cc: linux-m...@linux-mips.org
Acked-by: Greg Kroah-Hartman 
Patchwork: https://patchwork.linux-mips.org/patch/18559/
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/Kconfig  |8 
 drivers/usb/host/Kconfig |8 
 2 files changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -19,6 +19,14 @@ config USB_EHCI_BIG_ENDIAN_MMIO
 config USB_EHCI_BIG_ENDIAN_DESC
bool
 
+config USB_UHCI_BIG_ENDIAN_MMIO
+   bool
+   default y if SPARC_LEON
+
+config USB_UHCI_BIG_ENDIAN_DESC
+   bool
+   default y if SPARC_LEON
+
 menuconfig USB_SUPPORT
bool "USB support"
depends on HAS_IOMEM
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -637,14 +637,6 @@ config USB_UHCI_ASPEED
bool
default y if ARCH_ASPEED
 
-config USB_UHCI_BIG_ENDIAN_MMIO
-   bool
-   default y if SPARC_LEON
-
-config USB_UHCI_BIG_ENDIAN_DESC
-   bool
-   default y if SPARC_LEON
-
 config USB_FHCI_HCD
tristate "Freescale QE USB Host Controller support"
depends on OF_GPIO && QE_GPIO && QUICC_ENGINE


--
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 4.9 32/77] usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT

2018-02-21 Thread Greg Kroah-Hartman 
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit ec897569ad7dbc6d595873a487c3fac23f463f76 upstream.

Move the Kconfig symbols USB_UHCI_BIG_ENDIAN_MMIO and
USB_UHCI_BIG_ENDIAN_DESC out of drivers/usb/host/Kconfig, which is
conditional upon USB && USB_SUPPORT, so that it can be freely selected
by platform Kconfig symbols in architecture code.

For example once the MIPS_GENERIC platform selects are fixed in commit
2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN"), the MIPS
32r6_defconfig warns like so:

warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct 
dependencies (USB_SUPPORT && USB)
warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct 
dependencies (USB_SUPPORT && USB)

Fixes: 2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN")
Signed-off-by: James Hogan 
Cc: Corentin Labbe 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: linux-usb@vger.kernel.org
Cc: linux-m...@linux-mips.org
Acked-by: Greg Kroah-Hartman 
Patchwork: https://patchwork.linux-mips.org/patch/18559/
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/Kconfig  |8 
 drivers/usb/host/Kconfig |8 
 2 files changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -19,6 +19,14 @@ config USB_EHCI_BIG_ENDIAN_MMIO
 config USB_EHCI_BIG_ENDIAN_DESC
bool
 
+config USB_UHCI_BIG_ENDIAN_MMIO
+   bool
+   default y if SPARC_LEON
+
+config USB_UHCI_BIG_ENDIAN_DESC
+   bool
+   default y if SPARC_LEON
+
 menuconfig USB_SUPPORT
bool "USB support"
depends on HAS_IOMEM
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -628,14 +628,6 @@ config USB_UHCI_PLATFORM
bool
default y if ARCH_VT8500
 
-config USB_UHCI_BIG_ENDIAN_MMIO
-   bool
-   default y if SPARC_LEON
-
-config USB_UHCI_BIG_ENDIAN_DESC
-   bool
-   default y if SPARC_LEON
-
 config USB_FHCI_HCD
tristate "Freescale QE USB Host Controller support"
depends on OF_GPIO && QE_GPIO && QUICC_ENGINE


--
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 v3] Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export tcpci_irq. More operations can be extended in tcpci_data if needed. According to TCPCI specification, 4.4.5.2 RO

2018-02-21 Thread Greg KH 
On Wed, Feb 21, 2018 at 10:30:34PM +0800, ShuFanLee wrote:
> From: ShuFanLee 
> 
> Signed-off-by: ShuFanLee 

Something went really wrong with your subject line :(

Please fix and try again.

thanks,

greg k-h
--
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] usb: phy-generic: Use gpiod_set_value_cansleep

2018-02-21 Thread Mike Looijmans 
The nop_reset and shutdown methods are called in a context that can sleep,
so use gpiod_set_value_cansleep instead of gpiod_set_value.

If you've connected the reset line to a GPIO expander, you'd get a kernel
"slowpath" warning with gpiod_set_value.

Signed-off-by: Mike Looijmans 
---
 drivers/usb/phy/phy-generic.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 74ba882..a53b89b 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -63,9 +63,9 @@ static void nop_reset(struct usb_phy_generic *nop)
if (!nop->gpiod_reset)
return;
 
-   gpiod_set_value(nop->gpiod_reset, 1);
+   gpiod_set_value_cansleep(nop->gpiod_reset, 1);
usleep_range(1, 2);
-   gpiod_set_value(nop->gpiod_reset, 0);
+   gpiod_set_value_cansleep(nop->gpiod_reset, 0);
 }
 
 /* interface to regulator framework */
@@ -159,7 +159,7 @@ void usb_gen_phy_shutdown(struct usb_phy *phy)
 {
struct usb_phy_generic *nop = dev_get_drvdata(phy->dev);
 
-   gpiod_set_value(nop->gpiod_reset, 1);
+   gpiod_set_value_cansleep(nop->gpiod_reset, 1);
 
if (!IS_ERR(nop->clk))
clk_disable_unprepare(nop->clk);
-- 
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 v4 5/6] extcon: add possibility to get extcon device by OF node

2018-02-21 Thread Andy Shevchenko 
On Wed, Feb 21, 2018 at 10:55 AM, Andrzej Hajda  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.
Second, it's not _get_, it's _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()?

> +}

See good example in i2c-core-of.c

of_find_i2c_adapter_by_node()
of_get_i2c_adapter_by_node()

-- 
With Best Regards,
Andy Shevchenko
--
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] staging: typec: handle vendor defined part and modify drp toggling flow

2018-02-21 Thread ShuFanLee 
From: ShuFanLee 

Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export 
tcpci_irq.
More operations can be extended in tcpci_data if needed.
According to TCPCI specification, 4.4.5.2 ROLE_CONTROL,
TCPC shall not start DRP toggling until subsequently the TCPM
writes to the COMMAND register to start DRP toggling.
DRP toggling flow is chagned as following:
  - Write DRP = 0 & Rd/Rd
  - Write DRP = 1
  - Set LOOK4CONNECTION command

Signed-off-by: ShuFanLee 
---
 drivers/staging/typec/tcpci.c | 128 +-
 drivers/staging/typec/tcpci.h |  13 +
 2 files changed, 115 insertions(+), 26 deletions(-)

 patch changelogs between v1 & v2
 - Remove unnecessary i2c_client in the structure of tcpci
 - Rename structure of tcpci_vendor_data to tcpci_data
 - Not exporting tcpci read/write wrappers but register i2c regmap in glue 
driver
 - Add set_vconn ops in tcpci_data
   (It is necessary for RT1711H to enable/disable idle mode before 
disabling/enabling vconn)
 - Export tcpci_irq so that vendor can call it in their own IRQ handler

 patch changelogs between v2 & v3
 - Change the return type of tcpci_irq from int to irqreturn_t

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 9bd4412..4959c69 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -21,7 +21,6 @@
 
 struct tcpci {
struct device *dev;
-   struct i2c_client *client;
 
struct tcpm_port *port;
 
@@ -30,6 +29,12 @@ struct tcpci {
bool controls_vbus;
 
struct tcpc_dev tcpc;
+   struct tcpci_data *data;
+};
+
+struct tcpci_chip {
+   struct tcpci *tcpci;
+   struct tcpci_data data;
 };
 
 static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc)
@@ -37,8 +42,7 @@ static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev 
*tcpc)
return container_of(tcpc, struct tcpci, tcpc);
 }
 
-static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,
-   u16 *val)
+static int tcpci_read16(struct tcpci *tcpci, unsigned int reg, u16 *val)
 {
return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16));
 }
@@ -98,8 +102,10 @@ static int tcpci_set_cc(struct tcpc_dev *tcpc, enum 
typec_cc_status cc)
 static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
enum typec_cc_status cc)
 {
+   int ret;
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
-   unsigned int reg = TCPC_ROLE_CTRL_DRP;
+   unsigned int reg = (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
+  (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
 
switch (cc) {
default:
@@ -117,7 +123,19 @@ static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
break;
}
 
-   return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+   ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+   if (ret < 0)
+   return ret;
+   usleep_range(500, 1000);
+   reg |= TCPC_ROLE_CTRL_DRP;
+   ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+   if (ret < 0)
+   return ret;
+   ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
+  TCPC_CMD_LOOK4CONNECTION);
+   if (ret < 0)
+   return ret;
+   return 0;
 }
 
 static enum typec_cc_status tcpci_to_typec_cc(unsigned int cc, bool sink)
@@ -178,6 +196,16 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool 
enable)
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
int ret;
 
+   /* Handle vendor set vconn */
+   if (tcpci->data) {
+   if (tcpci->data->set_vconn) {
+   ret = tcpci->data->set_vconn(tcpci, tcpci->data,
+enable);
+   if (ret < 0)
+   return ret;
+   }
+   }
+
ret = regmap_write(tcpci->regmap, TCPC_POWER_CTRL,
   enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
if (ret < 0)
@@ -323,6 +351,15 @@ static int tcpci_init(struct tcpc_dev *tcpc)
if (time_after(jiffies, timeout))
return -ETIMEDOUT;
 
+   /* Handle vendor init */
+   if (tcpci->data) {
+   if (tcpci->data->init) {
+   ret = tcpci->data->init(tcpci, tcpci->data);
+   if (ret < 0)
+   return ret;
+   }
+   }
+
/* Clear all events */
ret = tcpci_write16(tcpci, TCPC_ALERT, 0x);
if (ret < 0)
@@ -344,9 +381,15 @@ static int tcpci_init(struct tcpc_dev *tcpc)
return tcpci_write16(tcpci, TCPC_ALERT_MASK, reg);
 }
 
-static irqreturn_t tcpci_irq(int irq, void *dev_id)
+static irqreturn_t _tcpci_irq(int irq, void *dev_id)
 {
struct tcpci *tcpci = dev_id;
+
+   return

Re: [PATCH v5 00/17] Support for Qualcomm QUSBv2 and QMPv3 USB PHYs

2018-02-21 Thread Doug Anderson 
Manu,

On Mon, Feb 19, 2018 at 9:21 PM, Manu Gautam  wrote:
> Hi Kishon,
>
>
> On 2/16/2018 5:19 PM, Kishon Vijay Abraham I wrote:
>>
>> On Thursday 01 February 2018 06:08 PM, Kishon Vijay Abraham I wrote:
>>>
>>> The series looks good. I'll start merging once -rc1 is tagged.
>> merged, thanks!
>>
>> -Kishon
>
> Following git isn't updated with these:
> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
>
> Should I be looking at somewhere else?
> I have some follow-up PHY patches to send, hence wanted to make sure they
> apply cleanly in your tree.

Sometimes you've got to give maintainers a day or three before patches
actually show up on git.kernel.org.  ...but I happened to notice that
they all appear to be there now so you should be all set to post your
followup patches.  :)

-Doug
--
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] staging: typec: handle vendor defined part and modify drp toggling flow

2018-02-21 Thread Guenter Roeck 
On Wed, Feb 21, 2018 at 11:02:23PM +0800, ShuFanLee wrote:
> From: ShuFanLee 
> 
> Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export 
> tcpci_irq.
> More operations can be extended in tcpci_data if needed.
> According to TCPCI specification, 4.4.5.2 ROLE_CONTROL,
> TCPC shall not start DRP toggling until subsequently the TCPM
> writes to the COMMAND register to start DRP toggling.
> DRP toggling flow is chagned as following:
>   - Write DRP = 0 & Rd/Rd
>   - Write DRP = 1
>   - Set LOOK4CONNECTION command
> 
> Signed-off-by: ShuFanLee 

Mostly loooks good to me. Couple of nitpicks below.

Guenter

> ---
>  drivers/staging/typec/tcpci.c | 128 
> +-
>  drivers/staging/typec/tcpci.h |  13 +
>  2 files changed, 115 insertions(+), 26 deletions(-)
> 
>  patch changelogs between v1 & v2
>  - Remove unnecessary i2c_client in the structure of tcpci
>  - Rename structure of tcpci_vendor_data to tcpci_data
>  - Not exporting tcpci read/write wrappers but register i2c regmap in glue 
> driver
>  - Add set_vconn ops in tcpci_data
>(It is necessary for RT1711H to enable/disable idle mode before 
> disabling/enabling vconn)
>  - Export tcpci_irq so that vendor can call it in their own IRQ handler
> 
>  patch changelogs between v2 & v3
>  - Change the return type of tcpci_irq from int to irqreturn_t
> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 9bd4412..4959c69 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -21,7 +21,6 @@
>  
>  struct tcpci {
>   struct device *dev;
> - struct i2c_client *client;
>  
>   struct tcpm_port *port;
>  
> @@ -30,6 +29,12 @@ struct tcpci {
>   bool controls_vbus;
>  
>   struct tcpc_dev tcpc;
> + struct tcpci_data *data;
> +};
> +
> +struct tcpci_chip {
> + struct tcpci *tcpci;
> + struct tcpci_data data;
>  };
>  
>  static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc)
> @@ -37,8 +42,7 @@ static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev 
> *tcpc)
>   return container_of(tcpc, struct tcpci, tcpc);
>  }
>  
> -static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,
> - u16 *val)
> +static int tcpci_read16(struct tcpci *tcpci, unsigned int reg, u16 *val)
>  {
>   return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16));
>  }
> @@ -98,8 +102,10 @@ static int tcpci_set_cc(struct tcpc_dev *tcpc, enum 
> typec_cc_status cc)
>  static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
>   enum typec_cc_status cc)
>  {
> + int ret;
>   struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
> - unsigned int reg = TCPC_ROLE_CTRL_DRP;
> + unsigned int reg = (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
> +(TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
>  
>   switch (cc) {
>   default:
> @@ -117,7 +123,19 @@ static int tcpci_start_drp_toggling(struct tcpc_dev 
> *tcpc,
>   break;
>   }
>  
> - return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> + ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> + if (ret < 0)
> + return ret;
> + usleep_range(500, 1000);
> + reg |= TCPC_ROLE_CTRL_DRP;
> + ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> + if (ret < 0)
> + return ret;
> + ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
> +TCPC_CMD_LOOK4CONNECTION);
> + if (ret < 0)
> + return ret;
> + return 0;

regmap_write returns a negative return code or 0, thus this can be
simplified to
return regmap_write(...);

>  }
>  
>  static enum typec_cc_status tcpci_to_typec_cc(unsigned int cc, bool sink)
> @@ -178,6 +196,16 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool 
> enable)
>   struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
>   int ret;
>  
> + /* Handle vendor set vconn */
> + if (tcpci->data) {
> + if (tcpci->data->set_vconn) {
> + ret = tcpci->data->set_vconn(tcpci, tcpci->data,
> +  enable);
> + if (ret < 0)
> + return ret;
> + }
> + }
> +
>   ret = regmap_write(tcpci->regmap, TCPC_POWER_CTRL,
>  enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
>   if (ret < 0)
> @@ -323,6 +351,15 @@ static int tcpci_init(struct tcpc_dev *tcpc)
>   if (time_after(jiffies, timeout))
>   return -ETIMEDOUT;
>  
> + /* Handle vendor init */
> + if (tcpci->data) {
> + if (tcpci->data->init) {
> + ret = tcpci->data->init(tcpci, tcpci->data);
> + if (ret < 0)
> + return ret;
> + }
> + }
> +
>   /* Clear all

information required

2018-02-21 Thread info 
Thanks for your last email response to me.
The information required should include the following-:
Your full names
Your address
Telephone number
Your private email
Occupation
Age
This is to enable my further discussion with you in confidence.
Best regards and wishes to you.
Mohammad Amir Khadov

NB: Please reply to:

uk...@postaxte.com


uk...@postaxte.com
--
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 3/7] usb: dwc3: pci: Store device properties dynamically

2018-02-21 Thread Thinh Nguyen 
Hi Andy,

On 2/21/2018 6:46 AM, Andy Shevchenko wrote:
> On Tue, Feb 20, 2018 at 11:12 PM, Thinh Nguyen
>  wrote:
>> On 2/17/2018 7:29 AM, Andy Shevchenko wrote:
>>> On Fri, Feb 16, 2018 at 11:55 PM, Thinh Nguyen
>>>  wrote:
 Add the ability to add device properties dynamically. Currently, device
 properties are added to platform device using
 platform_device_add_properties(). However, this function does not allow
 adding properties incrementally. It is useful to have this ability when
 the driver needs to set common device properties across different HW
>>>
>>> I'm not sure it's useful anyhow.
>>>
 or
 if IP and FPGA validation test different configurations for different
 HW.
>>>
>>> Shouldn't be a separate stuff for FPGA exclusively?
>>
>> Can you clarify/expand your question?
> 
> FPGA is the one which might have different properties at run time for
> the same device.
> So, why do we care on driver / generic level of it?
> 
> Shouldn't be FPGA manager take care of it (via DT overlays, for example)?

Normally it is handled using DT overlays. But for using FPGA as PCI 
device, I'm not aware of a better solution.

> 
 To address this issue, update dwc3_pci to store device properties to
 an array and dynamically manage them here.

 Introduce two new functions to do so:
* dwc3_pci_add_one_property() - this function adds one property to
  dwc->properties array and increase its size as needed
* dwc3_pci_add_properties() - this function takes a null terminated
  array of device properties and add them to dwc->properties
>>>
>>> So, why you can't use ACPI / DT here?
>>>
>>
>> dwc3_pci_add_properties() is a convenient function that takes statically
>> allocated array of (quirks) properties for different HW and store them
>> to dwc->properties. The idea is to add more properties on top of these
>> required quirks.
> 
> Yes, I understand that. What's wrong with DT? The built-in device
> properties have the same nature as usual properties for DT.
> Whenever driver calls device_property_read_uXX() or alike it would
> check all property provides for asked one.

I may not have explained fully in my commit message the purpose of this 
change. That's why I think I misinterpreted your previous question.

With this new debugging feature, we want to delay adding device 
properties until the user initiates it. Because the driver cannot use 
platform_device_add_properties() to incrementally add properties to 
platform device, we need a way to store properties so they can be added 
in later time. That's why I added these 2 new functions.

> Other than that, quirks esp. for FPGA sounds so wrong. Why in the
> first place not to make non-broken hardware?!

I may have used the term 'quirk' incorrectly since they were placed in 
dwc3_pci_quirk(). There's no quirk for FPGA, but there are some initial 
setup properties for FPGA. To be specific, these properties:
 PROPERTY_ENTRY_BOOL("snps,usb3_lpm_capable"),
 PROPERTY_ENTRY_BOOL("snps,has-lpm-erratum"),
 PROPERTY_ENTRY_BOOL("snps,dis_enblslpm_quirk"),
 PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),

BR,
Thinh
--
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] usb: quirks: add control message delay for 1b1c:1b20

2018-02-21 Thread Danilo Krummrich 
Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.

Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.

Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):

[   29.103520] usb 1-8: string descriptor 0 read error: -110
[   34.363097] usb 1-8: can't set config #1, error -110

Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:

[   35.400533] usbhid 1-8:1.0: can't add hid device: -110
[   35.401014] usbhid: probe of 1-8:1.0 failed with error -110

The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.

Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().

The overall boot time seems not to be influenced by these additional
delays, even on fast machines.

Signed-off-by: Danilo Krummrich 
---
v2: remove empty line in usb_get_descriptor() added by accident
---
 drivers/usb/core/message.c | 4 
 drivers/usb/core/quirks.c  | 3 ++-
 include/linux/usb/quirks.h | 3 +++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 77001bcfc504..a4025760dd84 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -150,6 +150,10 @@ int usb_control_msg(struct usb_device *dev, unsigned int 
pipe, __u8 request,
 
ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout);
 
+   /* Linger a bit, prior to the next control message. */
+   if (dev->quirks & USB_QUIRK_DELAY_CTRL_MSG)
+   msleep(200);
+
kfree(dr);
 
return ret;
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 4024926c1d68..4450bec7f3af 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -227,7 +227,8 @@ static const struct usb_device_id usb_quirk_list[] = {
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
 
/* Corsair Strafe RGB */
-   { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+   { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT |
+ USB_QUIRK_DELAY_CTRL_MSG },
 
/* Corsair K70 LUX */
{ USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT },
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index f1fcec2fd5f8..b7a99ce56bc9 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -63,4 +63,7 @@
  */
 #define USB_QUIRK_DISCONNECT_SUSPEND   BIT(12)
 
+/* Device needs a pause after every control message. */
+#define USB_QUIRK_DELAY_CTRL_MSG   BIT(13)
+
 #endif /* __LINUX_USB_QUIRKS_H */
-- 
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

Re: Host & gadget transparent driver

2018-02-21 Thread Greg KH 
On Wed, Feb 21, 2018 at 11:23:26PM +0200, Ran Shalit wrote:
> Hello,
> 
> I am facing the following challenge:
> 
> We have a camera device, and a ready drivers in the following configuration:
> 
> (1) host <--> camera
> 
> The drivers for host is a binary, i.e. source code is probably not
> available, and also the protocol datasheet is probably not available.

Really?  A USB host driver that is not released under the GPL?  That's
really difficult to imagine, but you are on your own here as that's an
obvious license violation.  Please go talk to your lawyers about this
problem, or you will have bigger problems if you try to rely on this.

best of luck, you are on your own here, sorry.

greg k-h
--
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] usb: quirks: add control message delay for 1b1c:1b20

2018-02-21 Thread Danilo Krummrich 
Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.

Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.

Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):

[   29.103520] usb 1-8: string descriptor 0 read error: -110
[   34.363097] usb 1-8: can't set config #1, error -110

Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:

[   35.400533] usbhid 1-8:1.0: can't add hid device: -110
[   35.401014] usbhid: probe of 1-8:1.0 failed with error -110

The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.

Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().

The overall boot time seems not to be influenced by these additional
delays, even on fast machines.

Signed-off-by: Danilo Krummrich 
---
 drivers/usb/core/message.c | 5 +
 drivers/usb/core/quirks.c  | 3 ++-
 include/linux/usb/quirks.h | 3 +++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 77001bcfc504..cbab2a99ce16 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -150,6 +150,10 @@ int usb_control_msg(struct usb_device *dev, unsigned int 
pipe, __u8 request,
 
ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout);
 
+   /* Linger a bit, prior to the next control message. */
+   if (dev->quirks & USB_QUIRK_DELAY_CTRL_MSG)
+   msleep(200);
+
kfree(dr);
 
return ret;
@@ -642,6 +646,7 @@ int usb_get_descriptor(struct usb_device *dev, unsigned 
char type,
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type << 8) + index, 0, buf, size,
USB_CTRL_GET_TIMEOUT);
+
if (result <= 0 && result != -ETIMEDOUT)
continue;
if (result > 1 && ((u8 *)buf)[1] != type) {
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 4024926c1d68..4450bec7f3af 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -227,7 +227,8 @@ static const struct usb_device_id usb_quirk_list[] = {
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
 
/* Corsair Strafe RGB */
-   { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+   { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT |
+ USB_QUIRK_DELAY_CTRL_MSG },
 
/* Corsair K70 LUX */
{ USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT },
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index f1fcec2fd5f8..b7a99ce56bc9 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -63,4 +63,7 @@
  */
 #define USB_QUIRK_DISCONNECT_SUSPEND   BIT(12)
 
+/* Device needs a pause after every control message. */
+#define USB_QUIRK_DELAY_CTRL_MSG   BIT(13)
+
 #endif /* __LINUX_USB_QUIRKS_H */
-- 
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

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

2018-02-21 Thread kbuild test robot 
Hi Andrzej,

I love your patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.16-rc2 next-20180221]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrzej-Hajda/dt-bindings-add-bindings-for-USB-physical-connector/20180221-185759
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

>> Error: arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi:864.1-2 syntax 
>> error
   FATAL ERROR: Unable to parse input tree

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

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

2018-02-21 Thread Andrzej Hajda 
On 21.02.2018 15:27, Andy Shevchenko wrote:
> On Wed, Feb 21, 2018 at 10:55 AM, Andrzej Hajda  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 v3] Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export tcpci_irq. More operations can be extended in tcpci_data if needed. According to TCPCI specification, 4.4.5.2 RO

2018-02-21 Thread 李書帆 
Hi Gerg,

  Thank you!

  I've fixed it and sent another email.

Best Regards,
*
Shu-Fan Lee
Richtek Technology Corporation
TEL: +886-3-5526789 #2359
FAX: +886-3-5526612
*


寄件者: Greg KH 
寄件日期: 2018年2月21日 下午 10:39
收件者: ShuFanLee
副本: heikki.kroge...@linux.intel.com; li...@roeck-us.net; shufan_lee(李書帆); 
cy_huang(黃啟原); linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org
主旨: Re: [PATCH v3] Handle vendor defined behavior in tcpci_init, 
tcpci_set_vconn and export tcpci_irq. More operations can be extended in 
tcpci_data if needed. According to TCPCI specification, 4.4.5.2 ROLE_CONTROL, 
TCPC shall not start DRP toggling until ...

On Wed, Feb 21, 2018 at 10:30:34PM +0800, ShuFanLee wrote:
> From: ShuFanLee 
>
> Signed-off-by: ShuFanLee 

Something went really wrong with your subject line :(

Please fix and try again.

thanks,

greg k-h
* Email Confidentiality Notice 

The information contained in this e-mail message (including any attachments) 
may be confidential, proprietary, privileged, or otherwise exempt from 
disclosure under applicable laws. It is intended to be conveyed only to the 
designated recipient(s). Any use, dissemination, distribution, printing, 
retaining or copying of this e-mail (including its attachments) by unintended 
recipient(s) is strictly prohibited and may be unlawful. If you are not an 
intended recipient of this e-mail, or believe that you have received this 
e-mail in error, please notify the sender immediately (by replying to this 
e-mail), delete any and all copies of this e-mail (including any attachments) 
from your system, and do not disclose the content of this e-mail to any other 
person. Thank you!

[PATCH 4.15 152/163] usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT

2018-02-21 Thread Greg Kroah-Hartman 
4.15-stable review patch.  If anyone has any objections, please let me know.

--

From: James Hogan 

commit ec897569ad7dbc6d595873a487c3fac23f463f76 upstream.

Move the Kconfig symbols USB_UHCI_BIG_ENDIAN_MMIO and
USB_UHCI_BIG_ENDIAN_DESC out of drivers/usb/host/Kconfig, which is
conditional upon USB && USB_SUPPORT, so that it can be freely selected
by platform Kconfig symbols in architecture code.

For example once the MIPS_GENERIC platform selects are fixed in commit
2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN"), the MIPS
32r6_defconfig warns like so:

warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct 
dependencies (USB_SUPPORT && USB)
warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct 
dependencies (USB_SUPPORT && USB)

Fixes: 2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN")
Signed-off-by: James Hogan 
Cc: Corentin Labbe 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: linux-usb@vger.kernel.org
Cc: linux-m...@linux-mips.org
Acked-by: Greg Kroah-Hartman 
Patchwork: https://patchwork.linux-mips.org/patch/18559/
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/Kconfig  |8 
 drivers/usb/host/Kconfig |8 
 2 files changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -19,6 +19,14 @@ config USB_EHCI_BIG_ENDIAN_MMIO
 config USB_EHCI_BIG_ENDIAN_DESC
bool
 
+config USB_UHCI_BIG_ENDIAN_MMIO
+   bool
+   default y if SPARC_LEON
+
+config USB_UHCI_BIG_ENDIAN_DESC
+   bool
+   default y if SPARC_LEON
+
 menuconfig USB_SUPPORT
bool "USB support"
depends on HAS_IOMEM
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -625,14 +625,6 @@ config USB_UHCI_ASPEED
bool
default y if ARCH_ASPEED
 
-config USB_UHCI_BIG_ENDIAN_MMIO
-   bool
-   default y if SPARC_LEON
-
-config USB_UHCI_BIG_ENDIAN_DESC
-   bool
-   default y if SPARC_LEON
-
 config USB_FHCI_HCD
tristate "Freescale QE USB Host Controller support"
depends on OF_GPIO && QE_GPIO && QUICC_ENGINE


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

Host & gadget transparent driver

2018-02-21 Thread Ran Shalit 
Hello,

I am facing the following challenge:

We have a camera device, and a ready drivers in the following configuration:

(1) host <--> camera

The drivers for host is a binary, i.e. source code is probably not
available, and also the protocol datasheet is probably not available.

But we need to use the camera in the following configuration:

(2) host <---> embedded board  <--> camera

In other words, there is a transparent medium in between the host and device.

I would like to ask what is the general concept for implementing the
drivers in the embedded board ?

Does these task requires reverse engineering ?

Is there any known example or driver which does something similar ?

Thanks a lot,
ranran
--
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