Re: Q: Does mass storage gadget use DMA ?
On Mon, Feb 12, 2018 at 2:39 PM, Oliver Neukum wrote: > Am Sonntag, den 11.02.2018, 22:17 +0200 schrieb Ran Shalit: >> On Tue, Feb 6, 2018 at 8:55 AM, Felipe Balbi >> wrote: >> > >> > >> > Hi, >> > >> > Ran Shalit writes: >> > > >> > > Hello, >> > > >> > > I check code in: >> > > https://elixir.free-electrons.com/linux/v3.3/source/drivers/usb/gadget/f_mass_storage.c >> > > but I see no API usage of DMA, yet it is being mentioned as if it is >> > > used. >> > >> > but it is used. It's just managed by the UDC driver (dwc3, musb, >> > chipidea, Renesas, etc) >> > >> Just to be sure, >> can I assume that other usb gadget drivers are using DMA (including >> gadgetfs for userspace driver) ? >> And it is also correct for host drivers (such as camera device ) ? > > None of these drivers are for hardware. They implement a protocol. > On the host as well as on the gadget side there are driver for the > actual host controllers (EHCI, XHCI, ...) as well as their gadget > equivalents. > > Any of these drivers may or may not use DMA. Neither the assumption > that they use DMA or the assumption that they do not use DMA > is valid. In fact they may mix it. I asked about DMA > Your code must be ready to cope with either usage. > > HTH > Oliver > -- 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: Q: Does mass storage gadget use DMA ?
On Thu, Feb 15, 2018 at 10:56 AM, Ran Shalit wrote: > On Mon, Feb 12, 2018 at 2:39 PM, Oliver Neukum wrote: >> Am Sonntag, den 11.02.2018, 22:17 +0200 schrieb Ran Shalit: >>> On Tue, Feb 6, 2018 at 8:55 AM, Felipe Balbi >>> wrote: >>> > >>> > >>> > Hi, >>> > >>> > Ran Shalit writes: >>> > > >>> > > Hello, >>> > > >>> > > I check code in: >>> > > https://elixir.free-electrons.com/linux/v3.3/source/drivers/usb/gadget/f_mass_storage.c >>> > > but I see no API usage of DMA, yet it is being mentioned as if it is >>> > > used. >>> > >>> > but it is used. It's just managed by the UDC driver (dwc3, musb, >>> > chipidea, Renesas, etc) >>> > >>> Just to be sure, >>> can I assume that other usb gadget drivers are using DMA (including >>> gadgetfs for userspace driver) ? >>> And it is also correct for host drivers (such as camera device ) ? >> >> None of these drivers are for hardware. They implement a protocol. >> On the host as well as on the gadget side there are driver for the >> actual host controllers (EHCI, XHCI, ...) as well as their gadget >> equivalents. >> >> Any of these drivers may or may not use DMA. Neither the assumption >> that they use DMA or the assumption that they do not use DMA >> is valid. In fact they may mix it. > Hi, I actually asked about DMA, because I see that it is possible to send urb using DMA allocated buffers or not (coherent and non-coherent) usb_buffer_alloc(). So, How can we actually know if I should use this API with a device or not ? I mean, is it always possible to use the coherent buffer with the device ? Sorry for the previous disrupted email, it was sent by mistake. Thanks a lot, Ran that there is API for dma > >> Your code must be ready to cope with either usage. >> >> HTH >> Oliver >> -- 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 v1 13/14] USB: typec: Re-use DEFINE_SHOW_ATTRIBUTE() macro
On Wed, Feb 14, 2018 at 06:08:29PM +0200, Andy Shevchenko wrote:
> ...instead of open coding file operations followed by custom ->open()
> callbacks per each attribute.
>
> Cc: Heikki Krogerus
> Cc: Guenter Roeck
> Signed-off-by: Andy Shevchenko
Reviewed-by: Heikki Krogerus
> ---
> drivers/usb/typec/fusb302/fusb302.c | 17 +++--
> drivers/usb/typec/tcpm.c| 17 +++--
> 2 files changed, 6 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/usb/typec/fusb302/fusb302.c
> b/drivers/usb/typec/fusb302/fusb302.c
> index 9ce4756adad6..da179aaf789e 100644
> --- a/drivers/usb/typec/fusb302/fusb302.c
> +++ b/drivers/usb/typec/fusb302/fusb302.c
> @@ -199,7 +199,7 @@ static void fusb302_log(struct fusb302_chip *chip, const
> char *fmt, ...)
> va_end(args);
> }
>
> -static int fusb302_seq_show(struct seq_file *s, void *v)
> +static int fusb302_debug_show(struct seq_file *s, void *v)
> {
> struct fusb302_chip *chip = (struct fusb302_chip *)s->private;
> int tail;
> @@ -216,18 +216,7 @@ static int fusb302_seq_show(struct seq_file *s, void *v)
>
> return 0;
> }
> -
> -static int fusb302_debug_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, fusb302_seq_show, inode->i_private);
> -}
> -
> -static const struct file_operations fusb302_debug_operations = {
> - .open = fusb302_debug_open,
> - .llseek = seq_lseek,
> - .read = seq_read,
> - .release= single_release,
> -};
> +DEFINE_SHOW_ATTRIBUTE(fusb302_debug);
>
> static struct dentry *rootdir;
>
> @@ -242,7 +231,7 @@ static int fusb302_debugfs_init(struct fusb302_chip *chip)
>
> chip->dentry = debugfs_create_file(dev_name(chip->dev),
> S_IFREG | 0444, rootdir,
> -chip, &fusb302_debug_operations);
> +chip, &fusb302_debug_fops);
>
> return 0;
> }
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index f4d563ee7690..a163ba55b061 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -506,7 +506,7 @@ static void tcpm_log_source_caps(struct tcpm_port *port)
> }
> }
>
> -static int tcpm_seq_show(struct seq_file *s, void *v)
> +static int tcpm_debug_show(struct seq_file *s, void *v)
> {
> struct tcpm_port *port = (struct tcpm_port *)s->private;
> int tail;
> @@ -523,18 +523,7 @@ static int tcpm_seq_show(struct seq_file *s, void *v)
>
> return 0;
> }
> -
> -static int tcpm_debug_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, tcpm_seq_show, inode->i_private);
> -}
> -
> -static const struct file_operations tcpm_debug_operations = {
> - .open = tcpm_debug_open,
> - .llseek = seq_lseek,
> - .read = seq_read,
> - .release= single_release,
> -};
> +DEFINE_SHOW_ATTRIBUTE(tcpm_debug);
>
> static struct dentry *rootdir;
>
> @@ -550,7 +539,7 @@ static int tcpm_debugfs_init(struct tcpm_port *port)
>
> port->dentry = debugfs_create_file(dev_name(port->dev),
> S_IFREG | 0444, rootdir,
> -port, &tcpm_debug_operations);
> +port, &tcpm_debug_fops);
>
> return 0;
> }
> --
> 2.15.1
--
heikki
--
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
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
[RFC PATCH v2 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector
Samsung micro-USB 11-pin connector beside standard micro-USB pins,
has pins dedicated to route MHL traffic.
Signed-off-by: Andrzej Hajda
---
.../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 = <&sii8620_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 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
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(&ctx->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(&ctx->extcon_wq, sii8620_extcon_work);
+ ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->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 = &sii8620_bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(&ctx->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,
+ &ctx->extcon_nb);
+ flush_work(&c
[RFC PATCH v2 1/6] dt-bindings: add bindings for USB physical connector
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
---
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
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 = <&max77865_usbc_hs>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ usb_con_ss: endpoint {
+ remote-endpoint = <&usbdrd_phy_ss>;
+ };
+ };
+ port@2 {
+ reg = <2>;
+ usb_con_sbu: endpoint {
+ remote-endpoint = <&dp_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
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 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 5/6] extcon: add possibility to get extcon device by OF node
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(&extcon_dev_list_lock);
+ list_for_each_entry(edev, &extcon_dev_list, entry)
+ if (edev->dev.parent && edev->dev.parent->of_node == node)
+ goto out;
+ edev = ERR_PTR(-EPROBE_DEFER);
+out:
+ mutex_unlock(&extcon_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(&extcon_dev_list_lock);
- list_for_each_entry(edev, &extcon_dev_list, entry) {
- if (edev->dev.parent && edev->dev.parent->of_node == node) {
- mutex_unlock(&extcon_dev_list_lock);
- of_node_put(node);
- return edev;
- }
- }
- mutex_unlock(&extcon_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
OF graph describes MHL data lanes between MHL and respective USB
connector.
Signed-off-by: Andrzej Hajda
---
.../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 = <&pmu_system_controller 0>;
clock-names = "xtal";
- port {
- mhl_to_hdmi: endpoint {
- remote-endpoint = <&hdmi_to_mhl>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mhl_to_hdmi: endpoint {
+ remote-endpoint = <&hdmi_to_mhl>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mhl_to_musb_con: endpoint {
+ remote-endpoint = <&musb_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 =
<&mhl_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] usb: dwc3: debugfs: Re-use DEFINE_SHOW_ATTRIBUTE() macro
...instead of open coding file operations followed by custom ->open()
callbacks per each attribute.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/debugfs.c | 79 --
1 file changed, 34 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 00e65530c81e..160dc90a4a41 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -487,8 +487,8 @@ static const struct file_operations dwc3_link_state_fops = {
};
struct dwc3_ep_file_map {
- char name[25];
- int (*show)(struct seq_file *s, void *unused);
+ const char name[25];
+ const struct file_operations *const fops;
};
static int dwc3_tx_fifo_queue_show(struct seq_file *s, void *unused)
@@ -596,7 +596,7 @@ static int dwc3_event_queue_show(struct seq_file *s, void
*unused)
return 0;
}
-static int dwc3_ep_transfer_type_show(struct seq_file *s, void *unused)
+static int dwc3_transfer_type_show(struct seq_file *s, void *unused)
{
struct dwc3_ep *dep = s->private;
struct dwc3 *dwc = dep->dwc;
@@ -632,7 +632,7 @@ static int dwc3_ep_transfer_type_show(struct seq_file *s,
void *unused)
return 0;
}
-static int dwc3_ep_trb_ring_show(struct seq_file *s, void *unused)
+static int dwc3_trb_ring_show(struct seq_file *s, void *unused)
{
struct dwc3_ep *dep = s->private;
struct dwc3 *dwc = dep->dwc;
@@ -670,49 +670,33 @@ static int dwc3_ep_trb_ring_show(struct seq_file *s, void
*unused)
return 0;
}
-static struct dwc3_ep_file_map map[] = {
- { "tx_fifo_queue", dwc3_tx_fifo_queue_show, },
- { "rx_fifo_queue", dwc3_rx_fifo_queue_show, },
- { "tx_request_queue", dwc3_tx_request_queue_show, },
- { "rx_request_queue", dwc3_rx_request_queue_show, },
- { "rx_info_queue", dwc3_rx_info_queue_show, },
- { "descriptor_fetch_queue", dwc3_descriptor_fetch_queue_show, },
- { "event_queue", dwc3_event_queue_show, },
- { "transfer_type", dwc3_ep_transfer_type_show, },
- { "trb_ring", dwc3_ep_trb_ring_show, },
-};
-
-static int dwc3_endpoint_open(struct inode *inode, struct file *file)
-{
- const char *file_name = file_dentry(file)->d_iname;
- struct dwc3_ep_file_map *f_map;
- int i;
-
- for (i = 0; i < ARRAY_SIZE(map); i++) {
- f_map = &map[i];
-
- if (strcmp(f_map->name, file_name) == 0)
- break;
- }
-
- return single_open(file, f_map->show, inode->i_private);
-}
-
-static const struct file_operations dwc3_endpoint_fops = {
- .open = dwc3_endpoint_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
+DEFINE_SHOW_ATTRIBUTE(dwc3_tx_fifo_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_rx_fifo_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_tx_request_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_rx_request_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_rx_info_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_descriptor_fetch_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_event_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_transfer_type);
+DEFINE_SHOW_ATTRIBUTE(dwc3_trb_ring);
+
+static const struct dwc3_ep_file_map dwc3_ep_file_map[] = {
+ { "tx_fifo_queue", &dwc3_tx_fifo_queue_fops, },
+ { "rx_fifo_queue", &dwc3_rx_fifo_queue_fops, },
+ { "tx_request_queue", &dwc3_tx_request_queue_fops, },
+ { "rx_request_queue", &dwc3_rx_request_queue_fops, },
+ { "rx_info_queue", &dwc3_rx_info_queue_fops, },
+ { "descriptor_fetch_queue", &dwc3_descriptor_fetch_queue_fops, },
+ { "event_queue", &dwc3_event_queue_fops, },
+ { "transfer_type", &dwc3_transfer_type_fops, },
+ { "trb_ring", &dwc3_trb_ring_fops, },
};
static void dwc3_debugfs_create_endpoint_file(struct dwc3_ep *dep,
- struct dentry *parent, int type)
+ struct dentry *parent, const char *const name,
+ const struct file_operations *const fops)
{
- struct dentry *file;
- struct dwc3_ep_file_map *ep_file = &map[type];
-
- file = debugfs_create_file(ep_file->name, S_IRUGO, parent, dep,
- &dwc3_endpoint_fops);
+ (void) debugfs_create_file(name, S_IRUGO, parent, dep, fops);
}
static void dwc3_debugfs_create_endpoint_files(struct dwc3_ep *dep,
@@ -720,8 +704,13 @@ static void dwc3_debugfs_create_endpoint_files(struct
dwc3_ep *dep,
{
int i;
- for (i = 0; i < ARRAY_SIZE(map); i++)
- dwc3_debugfs_create_endpoint_file(dep, parent, i);
+ for (i = 0; i < ARRAY_SIZE(dwc3_ep_file_map); i++) {
+ const struct file_operations *fops = dwc3_ep_file_map[i].fops;
+ const char *name = dwc3_ep_file_map[i].name;
+
+ dwc3_debugfs_create_endpoint_file(dep, p
Re: USB gadget : generic functionfs function has no os_desc while rndis function has, why?
On 02/11/2018 08:52 AM, Jun Sun wrote: Thanks for your reply, Krzysztof. I now understand all the fields. However, I just realize I can't really extend your example to cover my need, because your example uses RNDIS where kernel already support OS descriptor. In my case I'm preparing my own functionfs-based gadget. I suppose somewhere inside my functionfs daemon, I should add OS descriptor support. Is that understanding right? If so, is there any example? I searched around internet and can't seem to find a single example where functionfs-based USB gadget supports OS descriptor. In fact, it is not even clear to me what kernel interfaces are used for conveying OS descriptor for functionfs-based function. Thanks again. Really appreciate your help. I don't have any good example for that but this should be simple. It's only adding an additional flag to you descriptors (FFS_HAS_OS_DESC or sth similar, check ffs header for this) and then adding your os_desc to your descriptors. Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- 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 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector
On Thu, Feb 15, 2018 at 11:39 AM, Andrzej Hajda wrote:
> OF graph describes MHL data lanes between MHL and respective USB
> connector.
>
> Signed-off-by: Andrzej Hajda
> ---
> .../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 = <&pmu_system_controller 0>;
> clock-names = "xtal";
>
> - port {
> - mhl_to_hdmi: endpoint {
> - remote-endpoint = <&hdmi_to_mhl>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + mhl_to_hdmi: endpoint {
> + remote-endpoint = <&hdmi_to_mhl>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + mhl_to_musb_con: endpoint {
> + remote-endpoint = <&musb_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?
BR,
Krzysztof
> + musb_con_to_mhl: endpoint {
> + remote-endpoint =
> <&mhl_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
Re: [PATCH] usb: dwc3: debugfs: Re-use DEFINE_SHOW_ATTRIBUTE() macro
On Thu, 2018-02-15 at 13:16 +0200, Felipe Balbi wrote:
> ...instead of open coding file operations followed by custom ->open()
> callbacks per each attribute.
>
Reviewed-by: Andy Shevchenko
Though one comment below.
> Signed-off-by: Felipe Balbi
> static void dwc3_debugfs_create_endpoint_file(struct dwc3_ep *dep,
> + struct dentry *parent, const char *const name,
> + const struct file_operations *const fops)
> {
> + (void) debugfs_create_file(name, S_IRUGO, parent, dep, fops);
> }
At this point why do you need one line function anymore?
> + dwc3_debugfs_create_endpoint_file(dep, parent,
> + name, fops);
--
Andy Shevchenko
Intel Finland Oy
--
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 02/49] usb: dwc2: Force mode optimizations
Grigor Tovmasyan writes: > From: Vardan Mikayelyan > > If the dr_mode is USB_DR_MODE_OTG, forcing the mode is needed during > driver probe to get the host and device specific HW parameters. Then we > clear the force mode bits so that the core operates in OTG mode. > > The force mode bits should not be touched at any other time during the > driver lifetime and they should be preserved whenever the GUSBCFG > register is written to. The force mode bit values will persist across > soft resets of the core. > > If the dr_mode is either USB_DR_MODE_HOST or USB_DR_MODE_PERIPHERAL, the > force mode is set just once at probe to configure the core as either a > host or peripheral. > > Given the above, we no longer need any other reset delays, force delays, > or any forced modes anywhere else in the driver. So replace all calls to > dwc2_core_reset_and_force_dr_mode() with dwc2_core_reset() and remove > all other unnecessary delays. > > Also remove the dwc2_force_mode_if_needed() function since the "if > needed" part is already taken care of by the polling in > dwc2_force_mode(). > > Finally, remove all other calls to dwc2_clear_force_mode(). > > Tested-by: Stefan Wahren > Signed-off-by: John Youn > Signed-off-by: Vardan Mikayelyan > Signed-off-by: Grigor Tovmasyan Only patch #1 applied to testing/next. checking file drivers/usb/dwc2/core.c checking file drivers/usb/dwc2/core.h Hunk #1 succeeded at 1106 (offset 6 lines). checking file drivers/usb/dwc2/hcd.c Hunk #3 succeeded at 2261 (offset 5 lines). checking file drivers/usb/dwc2/params.c Hunk #1 succeeded at 579 (offset -1 lines). Hunk #2 FAILED at 603. 1 out of 2 hunks FAILED checking file drivers/usb/dwc2/platform.c Hunk #1 succeeded at 425 (offset 10 lines). please rebase -- balbi signature.asc Description: PGP signature
Re: [PATCH 0/6] usb: dwc2: minor fixes
Hi, Grigor Tovmasyan writes: > This series contains patches which are already have been sent in > "usb: dwc2: fixes, enhancements and new features" series. > > That patch series was too large, and based on community feedbacks decided to > split that series into small pieces. This is a first one. > > In this series we included only minor fixes for dwc2 driver. > > All patches were tested on HAPS-DX7 platform. > > > Changes after first submission: > > usb: dwc2: Add safety check in setting of descriptor chain pointer > > Updated description of patch. odd, I don't have 1/6 in my inbox. Care to resend it? -- balbi signature.asc Description: PGP signature
Re: [PATCH 5/6] usb: dwc2: eliminate irq parameter from dwc2_gadget_init
Grigor Tovmasyan writes: > From: Vardan Mikayelyan > > The irq is available in hsotg already, so there's no need to pass it as > separate function parameter. > > Signed-off-by: Vardan Mikayelyan > Signed-off-by: Grigor Tovmasyan doesn't apply. 1-4 are applied. Please rebase on testing/next -- balbi signature.asc Description: PGP signature
Re: [PATCH 0/6] usb: dwc2: minor fixes
Felipe Balbi writes: > Hi, > > Grigor Tovmasyan writes: >> This series contains patches which are already have been sent in >> "usb: dwc2: fixes, enhancements and new features" series. >> >> That patch series was too large, and based on community feedbacks decided to >> split that series into small pieces. This is a first one. >> >> In this series we included only minor fixes for dwc2 driver. >> >> All patches were tested on HAPS-DX7 platform. >> >> >> Changes after first submission: >> >> usb: dwc2: Add safety check in setting of descriptor chain pointer >> >> Updated description of patch. > > odd, I don't have 1/6 in my inbox. Care to resend it? nevermind, it just wasn't in the same thread (go figure) -- balbi signature.asc Description: PGP signature
Re: [PATCH] usb: dwc3: debugfs: Re-use DEFINE_SHOW_ATTRIBUTE() macro
Andy Shevchenko writes:
> On Thu, 2018-02-15 at 13:16 +0200, Felipe Balbi wrote:
>> ...instead of open coding file operations followed by custom ->open()
>> callbacks per each attribute.
>>
>
> Reviewed-by: Andy Shevchenko
>
> Though one comment below.
>
>> Signed-off-by: Felipe Balbi
>
>> static void dwc3_debugfs_create_endpoint_file(struct dwc3_ep *dep,
>> +struct dentry *parent, const char *const name,
>> +const struct file_operations *const fops)
>> {
>> +(void) debugfs_create_file(name, S_IRUGO, parent, dep, fops);
>> }
>
> At this point why do you need one line function anymore?
fair enough, here you go:
8<--
From 32ea5fda7654e7c081fff161544da73d53bf8fac Mon Sep 17 00:00:00 2001
From: Felipe Balbi
Date: Thu, 15 Feb 2018 13:03:38 +0200
Subject: [PATCH] usb: dwc3: debugfs: Re-use DEFINE_SHOW_ATTRIBUTE() macro
...instead of open coding file operations followed by custom ->open()
callbacks per each attribute.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/debugfs.c | 79 ++
1 file changed, 30 insertions(+), 49 deletions(-)
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 00e65530c81e..c4c0dcb3f589 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -487,8 +487,8 @@ static const struct file_operations dwc3_link_state_fops = {
};
struct dwc3_ep_file_map {
- char name[25];
- int (*show)(struct seq_file *s, void *unused);
+ const char name[25];
+ const struct file_operations *const fops;
};
static int dwc3_tx_fifo_queue_show(struct seq_file *s, void *unused)
@@ -596,7 +596,7 @@ static int dwc3_event_queue_show(struct seq_file *s, void
*unused)
return 0;
}
-static int dwc3_ep_transfer_type_show(struct seq_file *s, void *unused)
+static int dwc3_transfer_type_show(struct seq_file *s, void *unused)
{
struct dwc3_ep *dep = s->private;
struct dwc3 *dwc = dep->dwc;
@@ -632,7 +632,7 @@ static int dwc3_ep_transfer_type_show(struct seq_file *s,
void *unused)
return 0;
}
-static int dwc3_ep_trb_ring_show(struct seq_file *s, void *unused)
+static int dwc3_trb_ring_show(struct seq_file *s, void *unused)
{
struct dwc3_ep *dep = s->private;
struct dwc3 *dwc = dep->dwc;
@@ -670,58 +670,39 @@ static int dwc3_ep_trb_ring_show(struct seq_file *s, void
*unused)
return 0;
}
-static struct dwc3_ep_file_map map[] = {
- { "tx_fifo_queue", dwc3_tx_fifo_queue_show, },
- { "rx_fifo_queue", dwc3_rx_fifo_queue_show, },
- { "tx_request_queue", dwc3_tx_request_queue_show, },
- { "rx_request_queue", dwc3_rx_request_queue_show, },
- { "rx_info_queue", dwc3_rx_info_queue_show, },
- { "descriptor_fetch_queue", dwc3_descriptor_fetch_queue_show, },
- { "event_queue", dwc3_event_queue_show, },
- { "transfer_type", dwc3_ep_transfer_type_show, },
- { "trb_ring", dwc3_ep_trb_ring_show, },
+DEFINE_SHOW_ATTRIBUTE(dwc3_tx_fifo_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_rx_fifo_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_tx_request_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_rx_request_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_rx_info_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_descriptor_fetch_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_event_queue);
+DEFINE_SHOW_ATTRIBUTE(dwc3_transfer_type);
+DEFINE_SHOW_ATTRIBUTE(dwc3_trb_ring);
+
+static const struct dwc3_ep_file_map dwc3_ep_file_map[] = {
+ { "tx_fifo_queue", &dwc3_tx_fifo_queue_fops, },
+ { "rx_fifo_queue", &dwc3_rx_fifo_queue_fops, },
+ { "tx_request_queue", &dwc3_tx_request_queue_fops, },
+ { "rx_request_queue", &dwc3_rx_request_queue_fops, },
+ { "rx_info_queue", &dwc3_rx_info_queue_fops, },
+ { "descriptor_fetch_queue", &dwc3_descriptor_fetch_queue_fops, },
+ { "event_queue", &dwc3_event_queue_fops, },
+ { "transfer_type", &dwc3_transfer_type_fops, },
+ { "trb_ring", &dwc3_trb_ring_fops, },
};
-static int dwc3_endpoint_open(struct inode *inode, struct file *file)
-{
- const char *file_name = file_dentry(file)->d_iname;
- struct dwc3_ep_file_map *f_map;
- int i;
-
- for (i = 0; i < ARRAY_SIZE(map); i++) {
- f_map = &map[i];
-
- if (strcmp(f_map->name, file_name) == 0)
- break;
- }
-
- return single_open(file, f_map->show, inode->i_private);
-}
-
-static const struct file_operations dwc3_endpoint_fops = {
- .open = dwc3_endpoint_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
-
-static void dwc3_debugfs_create_endpoint_file(struct dwc3_ep *dep,
- struct dentry *parent, int type)
-{
- struct dentry *file;
-
Re: [PATCH] usb: dwc2: Fix kernel doc's warnings.
Hi, Grigor Tovmasyan writes: > Added descriptions for all not described parameters. > > Signed-off-by: Grigor Tovmasyan Fails to apply: checking file drivers/usb/dwc2/core.c Hunk #2 succeeded at 390 with fuzz 2 (offset -11 lines). Hunk #3 succeeded at 439 with fuzz 2 (offset -11 lines). checking file drivers/usb/dwc2/core.h Hunk #4 FAILED at 531. Hunk #5 succeeded at 613 (offset 4 lines). Hunk #6 succeeded at 648 (offset 4 lines). Hunk #7 succeeded at 671 (offset 4 lines). Hunk #8 succeeded at 772 (offset 4 lines). Hunk #9 succeeded at 781 (offset 4 lines). Hunk #10 succeeded at 802 (offset 4 lines). Hunk #11 succeeded at 868 (offset 4 lines). Hunk #12 succeeded at 892 (offset 4 lines). Hunk #13 succeeded at 904 (offset 4 lines). 1 out of 13 hunks FAILED checking file drivers/usb/dwc2/debug.h checking file drivers/usb/dwc2/debugfs.c checking file drivers/usb/dwc2/gadget.c Hunk #4 FAILED at 205. Hunk #5 succeeded at 205 (offset -36 lines). Hunk #6 succeeded at 230 (offset -38 lines). Hunk #7 succeeded at 332 (offset -37 lines). Hunk #8 succeeded at 2443 (offset -35 lines). Hunk #9 succeeded at 2741 (offset -52 lines). Hunk #10 succeeded at 3200 (offset -48 lines). Hunk #11 succeeded at 4280 (offset -38 lines). Hunk #12 succeeded at 4426 (offset -38 lines). Hunk #13 succeeded at 4500 (offset -38 lines). Hunk #14 succeeded at 4556 (offset -38 lines). Hunk #15 succeeded at 4608 (offset -38 lines). Hunk #16 succeeded at 4701 (offset -38 lines). 1 out of 16 hunks FAILED checking file drivers/usb/dwc2/hcd.c Hunk #1 succeeded at 572 (offset -12 lines). Hunk #2 succeeded at 4046 (offset -53 lines). checking file drivers/usb/dwc2/hcd.h Hunk #5 FAILED at 313. Hunk #6 succeeded at 399 (offset 8 lines). 1 out of 6 hunks FAILED checking file drivers/usb/dwc2/hcd_ddma.c checking file drivers/usb/dwc2/hcd_intr.c Hunk #1 succeeded at 478 (offset 6 lines). Hunk #2 succeeded at 572 (offset 6 lines). checking file drivers/usb/dwc2/hcd_queue.c Hunk #1 succeeded at 679 (offset 3 lines). Hunk #2 succeeded at 1277 (offset 3 lines). Hunk #3 succeeded at 1632 (offset 53 lines). checking file drivers/usb/dwc2/params.c Hunk #3 succeeded at 640 (offset 16 lines). checking file drivers/usb/dwc2/pci.c -- balbi signature.asc Description: PGP signature
Re: [PATCH/RFC 3/6] usb: gadget: Add NO_DMA dummies for DMA mapping API
Hi,
Geert Uytterhoeven writes:
> Add dummies for usb_gadget_{,un}map_request{,_by_dev}(), to allow
> compile-testing if NO_DMA=y.
>
> This prevents the following from showing up later:
>
> ERROR: "usb_gadget_unmap_request_by_dev"
> [drivers/usb/renesas_usbhs/renesas_usbhs.ko] undefined!
> ERROR: "usb_gadget_map_request_by_dev"
> [drivers/usb/renesas_usbhs/renesas_usbhs.ko] undefined!
> ERROR: "usb_gadget_map_request" [drivers/usb/mtu3/mtu3.ko] undefined!
> ERROR: "usb_gadget_unmap_request" [drivers/usb/mtu3/mtu3.ko] undefined!
> ERROR: "usb_gadget_map_request" [drivers/usb/gadget/udc/renesas_usb3.ko]
> undefined!
> ERROR: "usb_gadget_unmap_request"
> [drivers/usb/gadget/udc/renesas_usb3.ko] undefined!
>
> Signed-off-by: Geert Uytterhoeven
Should I take this or is it going with the rest of the series? If you
wanna take it through Trivial or something like that:
Acked-by: Felipe Balbi
--
balbi
signature.asc
Description: PGP signature
Re: High CPU load produced by USB (DW2)
On 14 February 2018 at 13:07, Minas Harutyunyan wrote: > On 2/14/2018 12:57 PM, Mirza Krak wrote: >> On 8 February 2018 at 14:53, Minas Harutyunyan >> wrote: < snip > > > I reviewed your interrupt count log again. About 140,000 interrupts in 2 > seconds, obviously it's not SOF only interrupts. More probably, its NAK > respond interrupts to SSPLIT/CSPLIT transactions. For this case I can > recommend you to apply patch from Douglas Anderson: "[PATCH v2] usb: > dwc2: host: Don't retry NAKed transactions right away" which already > merged to 4.16-rc1. > > In your setups you see different behavior on different HUBs. Your HUBs > have different "TT think time": 8 and 32. In USB2.0 spec "TT think time" > described as follow "TT requires at most 8/32 FS bit times of inter > transaction gap on a full-/low-speed downstream bus". So, your "worst" > HUB with "TT think time"=8 sending more frequently SSPLIT/CSPLIT > transactions which replied by NAK. As result you see about 4 time more > interrupts comparing to "good" HUB. Could you please check interrupts > count for "good" HUB and check "4 time" hypothesis. Did some further testing. The "good" HUB is actually as bad as the "bad" HUB, and it was my setup that caused the different behavior. Did not use the same devices etc. Once I made sure that the configuration and setup was the same on both board I could see that the behaved similarly. And that is the following interrupt load: - BT USB (FS) = ~80k interrupts / second - Keyboard (FS) = ~80k interrupts / second - WiFI USB (HS) = ~8k interrupts / second After applying the suggested patch [1], it is steady around 8k interrupts / second no matter what device I connect (HS/FS, HUB/NO-HUB). Which is acceptable and usable. Should this patch be a candidate for stable? Because in the current state, this combination DWC2 + HS HUB + FS device, is not "usable". [1]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/dwc2?h=v4.16-rc1&id=38d2b5fb75c15923fb89c32134516a623515bce4 -- Med Vänliga Hälsningar / Best Regards Mirza Krak -- 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 01/14] usb: dwc2: Rename hibernation to partial_power_down
Grigor Tovmasyan writes: > From: Vardan Mikayelyan > > No-op change, only rename. > > This code was misnamed originally. It was only responsible for partial > power down and not for hibernation. > > Rename core_params->hibernation to core_params->power_down, > dwc2_set_param_hibernation() to dwc2_set_param_power_down(). > > Signed-off-by: Vardan Mikayelyan > Signed-off-by: John Youn > Signed-off-by: Grigor Tovmasyan Fails to apply, please rebase: checking file drivers/usb/dwc2/core.c Hunk #1 succeeded at 126 (offset -2 lines). Hunk #2 succeeded at 180 (offset -2 lines). Hunk #3 succeeded at 218 (offset -2 lines). checking file drivers/usb/dwc2/core.h Hunk #2 FAILED at 498. Hunk #3 FAILED at 1110. 2 out of 3 hunks FAILED checking file drivers/usb/dwc2/core_intr.c Hunk #2 succeeded at 361 (offset -56 lines). Hunk #3 succeeded at 441 (offset -56 lines). checking file drivers/usb/dwc2/debugfs.c Hunk #1 FAILED at 754. 1 out of 1 hunk FAILED checking file drivers/usb/dwc2/gadget.c Hunk #1 succeeded at 3523 (offset -42 lines). Hunk #2 succeeded at 4368 (offset -44 lines). checking file drivers/usb/dwc2/hcd.c Hunk #1 succeeded at 3389 (offset -3 lines). Hunk #2 succeeded at 3424 (offset -3 lines). Hunk #3 succeeded at 4356 (offset -3 lines). Hunk #4 succeeded at 4370 (offset -3 lines). Hunk #5 succeeded at 4386 (offset -3 lines). Hunk #6 succeeded at 4411 (offset -3 lines). Hunk #7 succeeded at 4433 (offset -3 lines). checking file drivers/usb/dwc2/params.c Hunk #1 FAILED at 278. 1 out of 1 hunk FAILED -- balbi signature.asc Description: PGP signature
Re: [PATCH/RFC 6/6] Treewide: Remove depends on HAS_DMA in case of platform dependency
Geert Uytterhoeven writes: > Remove dependencies on HAS_DMA where a Kconfig symbol depends on another > symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". > In most cases this other symbol is an architecture or platform specific > symbol, or PCI. > > Generic symbols and drivers without platform dependencies keep their > dependencies on HAS_DMA, to prevent compiling subsystems or drivers that > cannot work anyway. > > This simplifies the dependencies, and allows to improve compile-testing. > > Notes: > - FSL_FMAN keeps its dependency on HAS_DMA, as it calls set_dma_ops(), > which does not exist if HAS_DMA=n (Do we need a dummy? The use of > set_dma_ops() in this driver is questionable), > - SND_SOC_LPASS_IPQ806X and SND_SOC_LPASS_PLATFORM loose their > dependency on HAS_DMA, as they are selected from > SND_SOC_APQ8016_SBC. > > Signed-off-by: Geert Uytterhoeven for drivers/usb/gadget/: Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature
[balbi-usb:testing/next 45/57] drivers/usb/dwc2/core.c:438:13: error: static declaration of 'dwc2_clear_force_mode' follows non-static declaration
tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
testing/next
head: 65223a0ed97c8c4b18c4899653745058f87d67e3
commit: 4caf1fe8fb537388810a4c8fecfa5324b26f80ea [45/57] usb: dwc2: Make
dwc2_force_mode() static
config: i386-randconfig-x072-201806 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 4caf1fe8fb537388810a4c8fecfa5324b26f80ea
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> drivers/usb/dwc2/core.c:438:13: error: static declaration of
>> 'dwc2_clear_force_mode' follows non-static declaration
static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
^
In file included from drivers/usb/dwc2/core.c:57:0:
drivers/usb/dwc2/core.h:1101:6: note: previous declaration of
'dwc2_clear_force_mode' was here
void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg);
^
vim +/dwc2_clear_force_mode +438 drivers/usb/dwc2/core.c
428
429 /**
430 * dwc2_clear_force_mode() - Clears the force mode bits.
431 *
432 * After clearing the bits, wait up to 100 ms to account for any
433 * potential IDDIG filter delay. We can't know if we expect this delay
434 * or not because the value of the connector ID status is affected by
435 * the force mode. We only need to call this once during probe if
436 * dr_mode == OTG.
437 */
> 438 static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
439 {
440 u32 gusbcfg;
441
442 gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
443 gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
444 gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
445 dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
446
447 if (dwc2_iddig_filter_enabled(hsotg))
448 msleep(100);
449 }
450
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [balbi-usb:testing/next 45/57] drivers/usb/dwc2/core.c:438:13: error: static declaration of 'dwc2_clear_force_mode' follows non-static declaration
Hi, kbuild test robot writes: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > testing/next > head: 65223a0ed97c8c4b18c4899653745058f87d67e3 > commit: 4caf1fe8fb537388810a4c8fecfa5324b26f80ea [45/57] usb: dwc2: Make > dwc2_force_mode() static > config: i386-randconfig-x072-201806 (attached as .config) > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 > reproduce: > git checkout 4caf1fe8fb537388810a4c8fecfa5324b26f80ea > # save the attached .config to linux build tree > make ARCH=i386 > > All errors (new ones prefixed by >>): > >>> drivers/usb/dwc2/core.c:438:13: error: static declaration of >>> 'dwc2_clear_force_mode' follows non-static declaration > static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg) > ^ >In file included from drivers/usb/dwc2/core.c:57:0: >drivers/usb/dwc2/core.h:1101:6: note: previous declaration of > 'dwc2_clear_force_mode' was here > void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg); > ^ > > vim +/dwc2_clear_force_mode +438 drivers/usb/dwc2/core.c > >428 >429/** >430 * dwc2_clear_force_mode() - Clears the force mode bits. >431 * >432 * After clearing the bits, wait up to 100 ms to account for any >433 * potential IDDIG filter delay. We can't know if we expect > this delay >434 * or not because the value of the connector ID status is > affected by >435 * the force mode. We only need to call this once during probe > if >436 * dr_mode == OTG. >437 */ > > 438static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg) patch dropped. -- balbi signature.asc Description: PGP signature
Re: [balbi-usb:testing/next 45/57] drivers/usb/dwc2/core.c:438:13: error: static declaration of 'dwc2_clear_force_mode' follows non-static declaration
Hi Balbi
On 2/15/2018 17:34, Felipe Balbi wrote:
>
> Hi,
>
> kbuild test robot writes:
>> tree:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_balbi_usb.git&d=DwIFAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=K1ULVL1slpLXpMJJlAXSOxws4tRq0IkTBqxDkyW2hUQ&m=2Hq2CZMELUidsi9x-Kqf4yuAh4IoxCX3Th1gZtmyZmc&s=Kw25jbj17VVP-cEEsCvpsfmS6NIuM8JAI8vfOtC2Nt4&e=
>> testing/next
>> head: 65223a0ed97c8c4b18c4899653745058f87d67e3
>> commit: 4caf1fe8fb537388810a4c8fecfa5324b26f80ea [45/57] usb: dwc2: Make
>> dwc2_force_mode() static
>> config: i386-randconfig-x072-201806 (attached as .config)
>> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
>> reproduce:
>> git checkout 4caf1fe8fb537388810a4c8fecfa5324b26f80ea
>> # save the attached .config to linux build tree
>> make ARCH=i386
>>
>> All errors (new ones prefixed by >>):
>>
drivers/usb/dwc2/core.c:438:13: error: static declaration of
'dwc2_clear_force_mode' follows non-static declaration
>> static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
>> ^
>> In file included from drivers/usb/dwc2/core.c:57:0:
>> drivers/usb/dwc2/core.h:1101:6: note: previous declaration of
>> 'dwc2_clear_force_mode' was here
>> void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg);
>> ^
>>
>> vim +/dwc2_clear_force_mode +438 drivers/usb/dwc2/core.c
>>
>> 428
>> 429 /**
>> 430 * dwc2_clear_force_mode() - Clears the force mode bits.
>> 431 *
>> 432 * After clearing the bits, wait up to 100 ms to account for any
>> 433 * potential IDDIG filter delay. We can't know if we expect
>> this delay
>> 434 * or not because the value of the connector ID status is
>> affected by
>> 435 * the force mode. We only need to call this once during probe
>> if
>> 436 * dr_mode == OTG.
>> 437 */
>> > 438 static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
>
> patch dropped.
>
This patch have a dependency from "[PATCH 6/6] usb: dwc2: Force mode"
("[PATCH 0/6] usb: dwc2: minor fixes" patches) which I missed.
I will rebase
[PATCH 5/6] usb: dwc2: eliminate irq parameter from dwc2_gadget_init
[PATCH 6/6] usb: dwc2: Force mode
Please apply this patch after applying that two patches.
Thanks, Grigor.
--
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 01/14] usb: dwc2: Rename hibernation to partial_power_down
Hi Balbi On 2/15/2018 17:23, Felipe Balbi wrote: > Grigor Tovmasyan writes: > >> From: Vardan Mikayelyan >> >> No-op change, only rename. >> >> This code was misnamed originally. It was only responsible for partial >> power down and not for hibernation. >> >> Rename core_params->hibernation to core_params->power_down, >> dwc2_set_param_hibernation() to dwc2_set_param_power_down(). >> >> Signed-off-by: Vardan Mikayelyan >> Signed-off-by: John Youn >> Signed-off-by: Grigor Tovmasyan > > Fails to apply, please rebase: > > checking file drivers/usb/dwc2/core.c > Hunk #1 succeeded at 126 (offset -2 lines). > Hunk #2 succeeded at 180 (offset -2 lines). > Hunk #3 succeeded at 218 (offset -2 lines). > checking file drivers/usb/dwc2/core.h > Hunk #2 FAILED at 498. > Hunk #3 FAILED at 1110. > 2 out of 3 hunks FAILED > checking file drivers/usb/dwc2/core_intr.c > Hunk #2 succeeded at 361 (offset -56 lines). > Hunk #3 succeeded at 441 (offset -56 lines). > checking file drivers/usb/dwc2/debugfs.c > Hunk #1 FAILED at 754. > 1 out of 1 hunk FAILED > checking file drivers/usb/dwc2/gadget.c > Hunk #1 succeeded at 3523 (offset -42 lines). > Hunk #2 succeeded at 4368 (offset -44 lines). > checking file drivers/usb/dwc2/hcd.c > Hunk #1 succeeded at 3389 (offset -3 lines). > Hunk #2 succeeded at 3424 (offset -3 lines). > Hunk #3 succeeded at 4356 (offset -3 lines). > Hunk #4 succeeded at 4370 (offset -3 lines). > Hunk #5 succeeded at 4386 (offset -3 lines). > Hunk #6 succeeded at 4411 (offset -3 lines). > Hunk #7 succeeded at 4433 (offset -3 lines). > checking file drivers/usb/dwc2/params.c > Hunk #1 FAILED at 278. > 1 out of 1 hunk FAILED > I will rebase this patch series also. Thanks, Grigor. -- 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 v1 03/14] USB: musb: Re-use DEFINE_SHOW_ATTRIBUTE() macro
On Wed, Feb 14, 2018 at 06:08:19PM +0200, Andy Shevchenko wrote: > ...instead of open coding file operations followed by custom ->open() > callbacks per each attribute. > > Cc: Bin Liu > Signed-off-by: Andy Shevchenko Acked-by: Bin Liu Regards, -Bin. -- 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 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector
On 15.02.2018 13:14, Krzysztof Kozlowski wrote:
> On Thu, Feb 15, 2018 at 11:39 AM, Andrzej Hajda wrote:
>> OF graph describes MHL data lanes between MHL and respective USB
>> connector.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> .../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 = <&pmu_system_controller 0>;
>> clock-names = "xtal";
>>
>> - port {
>> - mhl_to_hdmi: endpoint {
>> - remote-endpoint = <&hdmi_to_mhl>;
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + mhl_to_hdmi: endpoint {
>> + remote-endpoint = <&hdmi_to_mhl>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + mhl_to_musb_con: endpoint {
>> + remote-endpoint = <&musb_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 =
>> <&mhl_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
RE: [[INTERNAL] PATCH 0/2] Fix STM32F7 DWC2 OTG HS binding
Forget this one! Sorry for the inconvenience. > -Original Message- > From: Amelie DELAUNAY > Sent: jeudi 15 février 2018 16:47 > To: John Youn ; Felipe Balbi ; > Greg Kroah-Hartman ; Rob Herring > ; Mark Rutland > Cc: linux-usb@vger.kernel.org; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; Amelie DELAUNAY > Subject: [[INTERNAL] PATCH 0/2] Fix STM32F7 DWC2 OTG HS binding > > This patchset fixes STM32F7 DWC2 OTG HS binding. It actually re-applies the > v2 former patches adding STM32F7 DWC2 OTG HS support. > > Amelie Delaunay (2): > dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding > usb: dwc2: fix STM32F7 USB OTG HS compatible > > Documentation/devicetree/bindings/usb/dwc2.txt | 2 +- > drivers/usb/dwc2/params.c | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) > > -- > 2.7.4 -- 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] usb: dwc2: fix STM32F7 USB OTG HS compatible
This patch fixes compatible for STM32F7 USB OTG HS and consistently rename
dw2_set_params function.
The v2 former patch [1] had been acked by Paul Young, but v1 was merged.
[1] https://patchwork.kernel.org/patch/9925573/
Fixes: d8fae8b93682 ("usb: dwc2: add support for STM32F7xx USB OTG HS")
Signed-off-by: Amelie Delaunay
---
drivers/usb/dwc2/params.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 03fd20f..c4a4749 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -137,7 +137,7 @@ static void dwc2_set_stm32f4x9_fsotg_params(struct
dwc2_hsotg *hsotg)
p->activate_stm_fs_transceiver = true;
}
-static void dwc2_set_stm32f7xx_hsotg_params(struct dwc2_hsotg *hsotg)
+static void dwc2_set_stm32f7_hsotg_params(struct dwc2_hsotg *hsotg)
{
struct dwc2_core_params *p = &hsotg->params;
@@ -164,8 +164,8 @@ const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "st,stm32f4x9-fsotg",
.data = dwc2_set_stm32f4x9_fsotg_params },
{ .compatible = "st,stm32f4x9-hsotg" },
- { .compatible = "st,stm32f7xx-hsotg",
- .data = dwc2_set_stm32f7xx_hsotg_params },
+ { .compatible = "st,stm32f7-hsotg",
+ .data = dwc2_set_stm32f7_hsotg_params },
{},
};
MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
--
2.7.4
--
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] dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding
This patch fixes binding documentation for DWC2 controller in HS mode
found on STMicroelectronics STM32F7 SoC.
The v2 former patch [1] had been acked by Rob Herring, but v1 was merged.
[1] https://patchwork.kernel.org/patch/9925575/
Fixes: 000777dadc7e ("dt-bindings: usb: Document the STM32F7xx DWC2 ...")
Signed-off-by: Amelie Delaunay
---
Documentation/devicetree/bindings/usb/dwc2.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt
b/Documentation/devicetree/bindings/usb/dwc2.txt
index e64d903..46da5f1 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -19,7 +19,7 @@ Required properties:
configured in FS mode;
- "st,stm32f4x9-hsotg": The DWC2 USB HS controller instance in STM32F4x9 SoCs
configured in HS mode;
- - "st,stm32f7xx-hsotg": The DWC2 USB HS controller instance in STM32F7xx SoCs
+ - "st,stm32f7-hsotg": The DWC2 USB HS controller instance in STM32F7 SoCs
configured in HS mode;
- reg : Should contain 1 register range (address and length)
- interrupts : Should contain 1 interrupt
--
2.7.4
--
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] Fix STM32F7 DWC2 OTG HS binding
This patchset fixes STM32F7 DWC2 OTG HS binding. It actually re-applies the v2 former patches adding STM32F7 DWC2 OTG HS support. Amelie Delaunay (2): dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding usb: dwc2: fix STM32F7 USB OTG HS compatible Documentation/devicetree/bindings/usb/dwc2.txt | 2 +- drivers/usb/dwc2/params.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) -- 2.7.4 -- 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
[[INTERNAL] PATCH 0/2] Fix STM32F7 DWC2 OTG HS binding
This patchset fixes STM32F7 DWC2 OTG HS binding. It actually re-applies the v2 former patches adding STM32F7 DWC2 OTG HS support. Amelie Delaunay (2): dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding usb: dwc2: fix STM32F7 USB OTG HS compatible Documentation/devicetree/bindings/usb/dwc2.txt | 2 +- drivers/usb/dwc2/params.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) -- 2.7.4 -- 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 6/6] usb: dwc2: Force mode optimizations
Hi Balbi,
I rebased this commit to your testing/next (see below).
Please skip 05/06 patch in this series, it was already applied via
"[PATCH v2 00/49] usb: dwc2: fixes, enhancements and new features "
patch series.
Please ignore "[PATCH v2 00/49] usb: dwc2: fixes, enhancements and new
features " patch series.
Please apply this rebased patch.
Also, please, reapply "[PATCH 09/17] usb: dwc2: Make dwc2_force_mode()
static" which was dropped because of having dependancy from this pacth.
Thanks a lot.
On 1/16/2018 16:05, Grigor Tovmasyan wrote:
> From: Vardan Mikayelyan
>
> If the dr_mode is USB_DR_MODE_OTG, forcing the mode is needed during
> driver probe to get the host and device specific HW parameters. Then we
> clear the force mode bits so that the core operates in OTG mode.
>
> The force mode bits should not be touched at any other time during the
> driver lifetime and they should be preserved whenever the GUSBCFG
> register is written to. The force mode bit values will persist across
> soft resets of the core.
>
> If the dr_mode is either USB_DR_MODE_HOST or USB_DR_MODE_PERIPHERAL, the
> force mode is set just once at probe to configure the core as either a
> host or peripheral.
>
> Given the above, we no longer need any other reset delays, force delays,
> or any forced modes anywhere else in the driver. So replace all calls to
> dwc2_core_reset_and_force_dr_mode() with dwc2_core_reset() and remove
> all other unnecessary delays.
>
> Also remove the dwc2_force_mode_if_needed() function since the "if
> needed" part is already taken care of by the polling in
> dwc2_force_mode().
>
> Finally, remove all other calls to dwc2_clear_force_mode().
>
> Tested-by: Stefan Wahren
> Signed-off-by: John Youn
> Signed-off-by: Vardan Mikayelyan
> Signed-off-by: Grigor Tovmasyan
> ---
> drivers/usb/dwc2/core.c | 61
> +++--
> drivers/usb/dwc2/core.h | 4 +--
> drivers/usb/dwc2/hcd.c | 6 ++---
> drivers/usb/dwc2/params.c | 12 ++---
> drivers/usb/dwc2/platform.c | 9 ++-
> 5 files changed, 28 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 82a7d98c3436..dbca3b8890da 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -376,14 +376,14 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool
> skip_wait)
> return 0;
> }
>
> -/*
> - * Force the mode of the controller.
> +/**
> + * dwc2_force_mode() - Force the mode of the controller.
>*
>* Forcing the mode is needed for two cases:
>*
>* 1) If the dr_mode is set to either HOST or PERIPHERAL we force the
>* controller to stay in a particular mode regardless of ID pin
> - * changes. We do this usually after a core reset.
> + * changes. We do this once during probe.
>*
>* 2) During probe we want to read reset values of the hw
>* configuration registers that are only available in either host or
> @@ -400,7 +400,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool
> skip_wait)
>* the filter is configured and enabled. We poll the current mode of
>* the controller to account for this delay.
>*/
> -static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
> +void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
> {
> u32 gusbcfg;
> u32 set;
> @@ -412,17 +412,17 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg,
> bool host)
>* Force mode has no effect if the hardware is not OTG.
>*/
> if (!dwc2_hw_is_otg(hsotg))
> - return false;
> + return;
>
> /*
>* If dr_mode is either peripheral or host only, there is no
>* need to ever force the mode to the opposite mode.
>*/
> if (WARN_ON(host && hsotg->dr_mode == USB_DR_MODE_PERIPHERAL))
> - return false;
> + return;
>
> if (WARN_ON(!host && hsotg->dr_mode == USB_DR_MODE_HOST))
> - return false;
> + return;
>
> gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
>
> @@ -434,7 +434,7 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg,
> bool host)
> dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
>
> dwc2_wait_for_mode(hsotg, host);
> - return true;
> + return;
> }
>
> /**
> @@ -450,6 +450,11 @@ void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
> {
> u32 gusbcfg;
>
> + if (!dwc2_hw_is_otg(hsotg))
> + return;
> +
> + dev_dbg(hsotg->dev, "Clearing force mode bits\n");
> +
> gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
> gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
> gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
> @@ -464,16 +469,13 @@ void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
>*/
> void dwc2_force_dr_mode(struct dwc2_hsotg *hsotg)
> {
> - bool ret;
> -
> switch (hsotg->dr_mode) {
> case USB_DR_MODE_HOST:
> - ret = dwc2_force_mode(h
Wakeup from USB on i.MX6S
Hello everyone, I am working on an i.MX6S (Solo, not SoloLite or SoloX) attached to a module attached to a carrier board. It's running Yocto 2.2.3. I am trying to wake it up from one of the available standby states (freeze/mem/standby) by plugging in an USB Device. I have already studied several sources including - https://www.spinics.net/lists/linux-usb/msg135943.html (Wakeup from USB on mx6 in this mailing list) and - https://community.nxp.com/thread/446856#comments (i.MX6SX - Wake up from Stop mode with USB at NXP). All of the describe to pipe "enabled" into the correct wakeup-file corresponding to the correct device and piping "mem" (or freeze/standby) into the file "/sys/power/state". The system goes into standby wthout problems and can be woken up by its wake-button, which is enabled by default as "/sys/devices/soc0/gpio-keys/power/wakeup". After enabling "/sys/devices/soc0/soc/200.aips-bus/200.spba-bus/202.serial/tty/ttymxc0/power/wakeup", I was also able to wake it up by sending any serial input. But I didn't manage so far to wake it up by plugging in an USB-Stick or an USB-Keyboard or pressing a key on that keyboard when it's already plugged in (which creates a new device with wakeup capability, I did also enable). Most sources describe enabling the wakeup capability of several usb-devices to make it work - so I simply enabled all of them by "for i in $(find /sys/devices/soc0/ -name wakeup);do echo enabled > $i;done" which enables the following devices: "find /sys/devices/soc0/ -name wakeup /sys/devices/soc0/gpio-keys/power/wakeup /sys/devices/soc0/soc/1ffc000.pcie/pci:00/:00:00.0/power/wakeup /sys/devices/soc0/soc/200.aips-bus/20c9000.usbphy/power/wakeup /sys/devices/soc0/soc/200.aips-bus/200.spba-bus/202.serial/tty/ttymxc0/power/wakeup /sys/devices/soc0/soc/200.aips-bus/20ca000.usbphy/power/wakeup /sys/devices/soc0/soc/210.aips-bus/21f4000.serial/tty/ttymxc4/power/wakeup /sys/devices/soc0/soc/210.aips-bus/21ec000.serial/tty/ttymxc2/power/wakeup /sys/devices/soc0/soc/210.aips-bus/21e8000.serial/tty/ttymxc1/power/wakeup /sys/devices/soc0/soc/210.aips-bus/21f.serial/tty/ttymxc3/power/wakeup /sys/devices/soc0/soc/210.aips-bus/2184200.usb/power/wakeup /sys/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/power/wakeup /sys/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/power/wakeup /sys/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/power/wakeup /sys/devices/soc0/soc/210.aips-bus/2184000.usb/power/wakeup /sys/devices/soc0/soc/210.aips-bus/2184000.usb/ci_hdrc.0/power/wakeup" (the first one was already enabled, of course). After doing so, The system didn't wake up from standby or freeze, but woke up immediately from "mem" state. (The LEDs just flickered, no "Suspended for *.* seconds" message was given. The time given in "PM: noirq resume of devices complete after *.* msecs" was significantly shorter (266 vs 10 msecs).) I found that this immediate wakeup is caused by "/sys/devices/soc0/soc/210.aips-bus/2184200.usb/power/wakeup" - disabling it stopped the board from immediately waking up from mem state. This immediate-wakeup-device also wakes the system when nothing is plugged in. A reply by Peter Chen (https://www.spinics.net/lists/linux-usb/msg135994.html) to the mailing list thread I've referenced above also tells me, that enabling the wakeup capability of a device should stop it from powering down when entering any standby state (it needs to be powered to wake the system). I am not totally sure, but I think my USB Ports are still being powered down on entering standby, even after enabling their wakeup. I think so because the LED of my USB Stick and the NumLock LED of my Keyboard turn off in freeze/mem/standby, but I haven't measured the voltage of the ports yet. Do you have any idea how I can make the Wakeup_On_USB_Device_Plug_In work? And do you have any idea what are my mistakes or the problems with the system? The most references I can find about usb wakeup problems are related to the mx6sx (SoloX) or mx6sl (SoloLite) cpu. Best regards and thanks in advance, Ralf -- 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 5/6] usb: dwc2: eliminate irq parameter from dwc2_gadget_init
On 2/15/2018 17:08, Felipe Balbi wrote: > Grigor Tovmasyan writes: > >> From: Vardan Mikayelyan >> >> The irq is available in hsotg already, so there's no need to pass it as >> separate function parameter. >> >> Signed-off-by: Vardan Mikayelyan >> Signed-off-by: Grigor Tovmasyan > > doesn't apply. 1-4 are applied. Please rebase on testing/next > Seems like this patch was already merged with your testing/text. -- 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: [BUG] SD card reader disappears after suspend
On 14.02.2018 15:06, Samuel Sadok wrote: Thanks for the patches. However no luck yet, the usb device still doesn't reinitialize. Logs: https://gist.github.com/90ccb390c5777b9e2d5dc595f44d50da Can I somehow check if it is at all possible to bring back this particular device after hub power loss? For instance would you expect reloading all USB modules to bring back the device? I tried that and it didn't help: I'm starting to run out if ideas, maybe powering port off and on again in the logical disconnect could be worth a shot, or maybe trying to disable->re-enable port a bit earlier, before the disconnect -Mathias #!/bin/bash echo "Unload modules..." echo 1 > /sys/bus/pci/devices/\:00\:14.0/remove rmmod xhci_pci rmmod xhci_hcd rmmod usbhid rmmod bcm5974 rmmod btusb rmmod uas rmmod usb_storage rmmod usbcore rmmod usb_common echo "wait" sleep 2 echo "Reload modules..." modprobe usb_common modprobe usbcore modprobe usb_storage modprobe uas modprobe btusb modprobe bcm5974 modprobe usbhid modprobe xhci_hcd modprobe xhci_pci echo 1 > /sys/bus/pci/rescan 2018-02-13 17:07 GMT+01:00 Mathias Nyman : On 12.02.2018 16:03, Mathias Nyman wrote: On 10.02.2018 02:01, Samuel Sadok wrote: Thanks Mathias for looking into this. 2018-02-06 18:32 GMT+01:00 Mathias Nyman : Does reverting 37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices help? Unfortunately not, the card reader is still missing after resume. Here's the dmesg and usbmon (as previously, doing one suspend-resume cycle): https://gist.github.com/anonymous/5aea8eddf97e1b964bffd75ed88793fd For this log I also increased the usbmon buffer size as suggested by Alan (to about 2MB). This (seemingly) resolved the issue with the log gaps. Ok, one reason reverting didn't help is that it we still don't really disable and re-enable: [ 100.771564] usb usb2-port4: logical disconnect ... [ 100.771586] usb usb2-port4: Not disabling port; link state is RxDetect The reset resume of device "usb 2-4" (the device in question) happens around [100.77]. In the usbmon log there is no activity at that exact time, only ~50ms before and after. Can we infer from this that the issue is independent from the actual device and must stem from some faulty state in the kernel or USB controller? Btw I also added/modified some debug lines for my own understanding, those are tagged with "[CUSTOM LOG]". * check that root cause for failing USB3 device reset after resume is not that several xhci slots are in Default state at the same time. xHC can't handle this. In normal device enumeration usb core has a mutex protecting it, not sure it works here, maybe usb core and xhci are out of sync after xHC reset? I find this line in particular interesting: [ 100.771536] xhci_hcd :00:14.0: [CUSTOM LOG] xHCI xhci_urb_enqueue called with unaddressed device, slot_id = 1 This comes from xhci_check_args(). Since udev->slot_id == 1 is non-zero this implies that xhci->devs[udev->slot_id] must be NULL for this particular device (usb 2-4), which I guess is not good. So to me this does indeed look like the usb core and xhci are out of sync. However I'm not familiar with the code (for instance what is slot_id is for, who uses it, should it always be 0 on resume?) but based on the log and what you wrote I guess this sounds like a good point: xhci uses slot_id to identify different usb devices connected to it. xHC hw gives each enabled attached usb device a slot_id. When usb core asks xhci host to do something to a device xhci driver knows which device based on udev->slot_id when xhci controller is reset, all xhci slots are disabled and freed, but usb core still has udev->slot_id pointers set. In normal resume case the xHC controller is not reset, but if something goes wrong, or power is cut from xHC during suspend then we recover by resetting xHC at resume. I'll try to write some quick testpatches that: - removes LPM and LTM disabling from usb_reset_and_verify_device - zeroes udev->slot_id when slot is disabled and freed in xhci - forces a disable/enable port after port reset failed a few times. A series for testing can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git port-disable-test https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=port-disable-test Based on 4.15 Can you try it out? -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 -- 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: [PATCH v3] Add delay-init quirk for Corsair K70 RGB keyboards
On Sun, Feb 04, 2018 at 04:50:58PM +, JackStocker wrote: > Following on from this patch: https://lkml.org/lkml/2017/11/3/516, > Corsair K70 RGB keyboards also require the DELAY_INIT quirk to > start correctly at boot. > > Device ids found here: > usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13 > usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 3-3: Product: Corsair K70 RGB Gaming Keyboard > > Signed-off-by: JackStocker I need a "real" name here please. 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
Re: [PATCH v1 1/1] usb: cdc_acm: prevent race at write to acm while system resumes
On Mon, Feb 12, 2018 at 12:15:03PM -0800, sathyanarayan.kuppusw...@linux.intel.com wrote: > From: Dominik Bozek > > ACM driver may accept data to transmit while system is not fully > resumed. In this case ACM driver buffers data and prepare URBs > on usb anchor list. > There is a little chance that two tasks put a char and initiate > acm_tty_flush_chars(). In such a case, driver will put one URB > twice on usb anchor list. > This patch also reset length of data before resue of a buffer. > This not only prevent sending rubbish, but also lower risc of race. > > Without this patch we hit following kernel panic in one of our > stabilty/stress tests. > > [ 46.884442] *list_add double add*: new=9b2ab7289330, > prev=9b2ab7289330, next=9b2ab81e28e0. > [ 46.884476] Modules linked in: hci_uart btbcm bluetooth rfkill_gpio > igb_avb(O) cfg80211 snd_soc_sst_bxt_tdf8532 snd_soc_skl snd_soc_skl_ipc > snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_sst_acpi snd_soc_sst_match > snd_hda_ext_core snd_hda_core trusty_timer trusty_wall trusty_log > trusty_virtio trusty_ipc trusty_mem trusty_irq trusty virtio_ring virtio > intel_ipu4_mmu_bxtB0 lib2600_mod_bxtB0 intel_ipu4_isys_mod_bxtB0 > lib2600psys_mod_bxtB0 intel_ipu4_psys_mod_bxtB0 intel_ipu4_mod_bxtB0 > intel_ipu4_wrapper_bxtB0 intel_ipu4_acpi videobuf2_dma_contig as3638 dw9714 > lm3643 crlmodule smiapp smiapp_pll > [ 46.884480] CPU: 1 PID: 33 Comm: kworker/u8:1 Tainted: G U W O > 4.9.56-quilt-2e5dc0ac-g618ed69ced6e-dirty #4 > [ 46.884489] Workqueue: events_unbound flush_to_ldisc > [ 46.884494] b98ac012bb08 ad3e82e5 b98ac012bb58 > > [ 46.884497] b98ac012bb48 ad0a23d1 0024ad6374dd > 9b2ab7289330 > [ 46.884500] 9b2ab81e28e0 9b2ab7289330 0002 > > [ 46.884501] Call Trace: > [ 46.884507] [] dump_stack+0x67/0x92 > [ 46.884511] [] __warn+0xd1/0xf0 > [ 46.884513] [] warn_slowpath_fmt+0x5f/0x80 > [ 46.884516] [] __list_add+0xb3/0xc0 > [ 46.884521] [] *usb_anchor_urb*+0x4c/0xa0 > [ 46.884524] [] *acm_tty_flush_chars*+0x8f/0xb0 > [ 46.884527] [] *acm_tty_put_char*+0x41/0x100 > [ 46.884530] [] tty_put_char+0x24/0x40 > [ 46.884533] [] do_output_char+0xa5/0x200 > [ 46.884535] [] __process_echoes+0x148/0x290 > [ 46.884538] [] n_tty_receive_buf_common+0x57c/0xb00 > [ 46.884541] [] n_tty_receive_buf2+0x14/0x20 > [ 46.884543] [] tty_ldisc_receive_buf+0x22/0x50 > [ 46.884545] [] flush_to_ldisc+0xc5/0xe0 > [ 46.884549] [] process_one_work+0x148/0x440 > [ 46.884551] [] worker_thread+0x69/0x4a0 > [ 46.884554] [] ? max_active_store+0x80/0x80 > [ 46.884556] [] kthread+0x110/0x130 > [ 46.884559] [] ? kthread_park+0x60/0x60 > [ 46.884563] [] ret_from_fork+0x27/0x40 > [ 46.884566] ---[ end trace 3bd599058b8a9eb3 ]--- > > Signed-off-by: Sathyanarayanan Kuppuswamy > Why hasn't the author of this patch signed off on it? 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
Re: [PATCH 1/2] usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT
On Wed, Jan 31, 2018 at 10:24:45PM +, James Hogan wrote: > 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 the > patch "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) > > Signed-off-by: James Hogan > Cc: Greg Kroah-Hartman > Cc: Corentin Labbe > Cc: linux-usb@vger.kernel.org Acked-by: Greg Kroah-Hartman -- 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
[BUG] musb: broken isochronous transfer at TI AM335x platform
Hi all,
Almost two years ago I faced an issue related to PWC-driven V4L2
webcam attached to BeagleBone Black SBC. [1][2] The issue still
persists in 4.16-rc1. However, some research has been carried out
since then. I would like to summarize my findings below. I also would
like to receive feedback since the issue appears not to have one
single source and probably may affect setups other than mine.
Initial issue signs were the following. When Philips SPC 900 webcam
(handled by pwc kernel module) is attached to BeagleBone Black SBC
(equipped with TI AM335x Cortex-A8 CPU and Inventra MUSB Dual-Role USB
controller), no frames can be received from the camera. In other
words, the major functional purpose of the camera was broken. From
user-space point of view,
ioctl(fd, VIDIOC_DQBUF, &buf)
indefinitely waits for a frame, yet all other functionalities (i.e.
setting formats) works as usual. This happens always when "ondemand"
cpufreq policy is set and from time to time when "performance" is
used. This also happens disregarding whether DMA USB is used.
Other instances of the camera (same model) have been tested and found
to have same behavior. Then, I've found that the reason for such
behavior is that pwc module never feeds V4L2 subsystem with frames
from the module side, because frame completion criteria never
satisfied in pwc_isoc_handler(). PWC considers the "shorter" or empty
incoming USB ISO packet as end-of-frame sign. Usually, every URB has
10 packets and every packet consists of 956 payload data bytes in case
of PWC. Also, when end-of-frame is received the accumulated amount of
bytes must be equal to expected (known from frame format, i.e width *
height * pixel-depth). It appeared that it was never the case, empty
USB packet was always received in advance to expected frame end and
then every frame was discarded.
I've also bisected the following. The USB ISO transfer works well since commit
2035772010db ("usb: musb: musb_host: Enable HCD_BH flag to handle
urb return in bottom half")
and stops working after commit
f551e1352983 ("Revert "usb: musb: musb_host: Enable HCD_BH flag to
handle urb return in bottom half"")
To reliably connect these two facts, I had to assembly OpenVizsla
hardware USB monitor (sniffer). [3] Using this tool the following MUSB
Host + PWC webcam behavior patterns were found [4]:
[] 7.219456 d= 0.000997 [181.0 + 3.667] [ 3] IN : 4.5
[T ] 7.219459 d= 0.03 [181.0 + 7.083] [800] DATA0: 53 da ...
[] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5
[T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0: 13 36 ...
[] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
[] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00
[] 7.223456 d= 0.000997 [185.0 + 3.667] [ 3] IN : 4.5
[] 7.223459 d= 0.03 [185.0 + 7.000] [ 3] DATA0: 00 00
Please note, that the time moment "7.221456" has missed IN request
packet which must be sent out every 1ms in this low-speed USB case.
Then, all incoming packets became empty ones. Such moments coincide
with frame discarding in pwc driver.
Even though IN sending is usually handled by USB host hardware, it is
not fully true for MUSB. Every IN is triggered by musb kernel driver
(see MUSB_RXCSR_H_REQPKT usage in musb_host_packet_rx() and
musb_ep_program()) since auto IN is not used. Rather complicated logic
is incorporated to decide whether IN packet has to be sent. First,
musb_host_packet_rx() handles IN sending when current URB is not
completed (i.e. current URB has another packet which has to be
received next). Second, musb_advance_schedule() (via musb_start_urb())
handles the case when current URB is completed but there is another
URB pending. It seems that there is a hardware logic to fire IN packet
in a way to have exactly 1ms between two consequent INs. So,
MUSB_RXCSR_H_REQPKT is considered as IN requesting flag.
Both functions are triggered by musb_host_rx() interrupt handler. And
there are a lot of other important things between interrupt triggering
and next IN requesting. It appears that sometimes it takes 0.4-0.5 ms
between the interrupt and MUSB_RXCSR_H_REQPKT writing. This delays
also lead to missed IN (It is actually sent, but at (last)+2ms time
instead of (last)+1ms) and confusing the peripheral as shown above.
This is a case of URB-completion branch.
The most time-consuming part is urb->giveback() calling.
Unfortunately, it is performed synchronously before requesting IN.
This explains why commit
2035772010db ("usb: musb: musb_host: Enable HCD_BH flag to handle
urb return in bottom half")
masks the issue. Moving (postponing) urb->giveback() call out of
interrupt context eliminated extra delays between IN requesting.
(Un)fortunately, this commit was reverted and the issue returned back.
I proposed a patch to swap time-consuming urb->giveback() and
MUSB_RXCSR_H_REQPKT writing but th
Re: [PATCH v3] Add delay-init quirk for Corsair K70 RGB keyboards
On 15/02/18 17:35, Greg Kroah-Hartman wrote: On Sun, Feb 04, 2018 at 04:50:58PM +, JackStocker wrote: Following on from this patch: https://lkml.org/lkml/2017/11/3/516, Corsair K70 RGB keyboards also require the DELAY_INIT quirk to start correctly at boot. Device ids found here: usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13 usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-3: Product: Corsair K70 RGB Gaming Keyboard Signed-off-by: JackStocker I need a "real" name here please. thanks, greg k-h As in 'Jack Stocker' is that correct? Cheers, Jack -- 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] Add delay-init quirk for Corsair K70 RGB keyboards
On Thu, Feb 15, 2018 at 05:59:34PM +, Jack wrote: > On 15/02/18 17:35, Greg Kroah-Hartman wrote: > > On Sun, Feb 04, 2018 at 04:50:58PM +, JackStocker wrote: > > > Following on from this patch: https://lkml.org/lkml/2017/11/3/516, > > > Corsair K70 RGB keyboards also require the DELAY_INIT quirk to > > > start correctly at boot. > > > > > > Device ids found here: > > > usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13 > > > usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > > > usb 3-3: Product: Corsair K70 RGB Gaming Keyboard > > > > > > Signed-off-by: JackStocker > > I need a "real" name here please. > > > > thanks, > > > > greg k-h > As in 'Jack Stocker' is that correct? If that is how you sign legal documents, yes :) 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
Re: [Regression] xhci: some hard drives cannot be seen using a JMicron JMS56x enclosure
Hi Adding Oliver 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? When I plug the USB cable, I can see the following output in dmesg: [Tue Feb 6 22:17:49 2018] usb 4-2: new SuperSpeed USB device number 10 using xhci_hcd [Tue Feb 6 22:17:49 2018] usb 4-2: New USB device found, idVendor=152d, idProduct=0562 [Tue Feb 6 22:17:49 2018] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=5 [Tue Feb 6 22:17:49 2018] usb 4-2: Product: JMS56x Series [Tue Feb 6 22:17:49 2018] usb 4-2: Manufacturer: JMicron [Tue Feb 6 22:17:49 2018] usb 4-2: SerialNumber: RANDOM__8A4D7F833EEF [Tue Feb 6 22:17:49 2018] scsi host6: uas [Tue Feb 6 22:17:50 2018] scsi 6:0:0:0: Direct-Access FUJITSU MHZ2160BH G2 0104 PQ: 0 ANSI: 6 [Tue Feb 6 22:17:50 2018] scsi 6:0:0:1: Direct-Access WDC WD40 EFRX-68N32N0 0104 PQ: 0 ANSI: 6 [Tue Feb 6 22:17:50 2018] sd 6:0:0:0: Attached scsi generic sg2 type 0 [Tue Feb 6 22:17:50 2018] sd 6:0:0:1: Attached scsi generic sg3 type 0 [Tue Feb 6 22:17:57 2018] sd 6:0:0:0: [sdb] 312581808 512-byte logical blocks: (160 GB/149 GiB) [Tue Feb 6 22:17:57 2018] sd 6:0:0:1: [sdc] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB) [Tue Feb 6 22:17:57 2018] sd 6:0:0:0: [sdb] Write Protect is off [Tue Feb 6 22:17:57 2018] sd 6:0:0:0: [sdb] Mode Sense: 67 00 10 08 [Tue Feb 6 22:17:57 2018] sd 6:0:0:1: [sdc] Write Protect is off [Tue Feb 6 22:17:57 2018] sd 6:0:0:1: [sdc] Mode Sense: 67 00 10 08 [Tue Feb 6 22:17:57 2018] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA [Tue Feb 6 22:17:57 2018] sd 6:0:0:1: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA [Tue Feb 6 22:17:57 2018] sdb: sdb1 [Tue Feb 6 22:17:57 2018] sd 6:0:0:0: [sdb] Attached SCSI disk [Tue Feb 6 22:18:27 2018] sd 6:0:0:1: tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: IN [Tue Feb 6 22:18:27 2018] sd 6:0:0:1: tag#1 CDB: Inquiry 12 01 00 00 40 00 [Tue Feb 6 22:18:27 2018] scsi host6: uas_eh_device_reset_handler start [Tue Feb 6 22:18:28 2018] usb 4-2: reset SuperSpeed USB device number 10 using xhci_hcd [Tue Feb 6 22:18:28 2018] usb 4-2: device firmware changed [Tue Feb 6 22:18:28 2018] scsi host6: uas_post_reset: alloc streams error -19 after reset [Tue Feb 6 22:18:28 2018] usb 4-2: USB disconnect, device number 10 [Tue Feb 6 22:20:29 2018] iwlwifi :03:00.0: Radio type=0x0-0x3-0x1 [Tue Feb 6 22:20:29 2018] iwlwifi :03:00.0: Radio type=0x0-0x3-0x1 [Tue Feb 6 22:20:29 2018] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [Tue Feb 6 22:20:30 2018] INFO: task kworker/0:3:191 blocked for more than 120 seconds. [Tue Feb 6 22:20:30 2018] Not tainted 4.14.0-3-amd64 #1 Debian 4.14.13-1 [Tue Feb 6 22:20:30 2018] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [Tue Feb 6 22:20:30 2018] kworker/0:3 D0 191 2 0x8000 [Tue Feb 6 22:20:30 2018] Workqueue: usb_hub_wq hub_event [usbcore] [Tue Feb 6 22:20:30 2018] Call Trace: [Tue Feb 6 22:20:30 2018] ? __schedule+0x28e/0x880 [Tue Feb 6 22:20:30 2018] schedule+0x28/0x80 [Tue Feb 6 22:20:30 2018] schedule_preempt_disabled+0xa/0x10 [Tue Feb 6 22:20:30 2018] __mutex_lock.isra.1+0x1a0/0x4e0 [Tue Feb 6 22:20:30 2018] ? _dev_info+0x64/0x80 [Tue Feb 6 22:20:30 2018] ? usb_disconnect+0x57/0x260 [usbcore] Maybe something is keeping the usb device lock, that would block hub work from finishing usb_disconnect() when waiting for usb_lock_device(udev) [Tue Feb 6 22:20:30 2018] usb_disconnect+0x57/0x260 [usbcore] [Tue Feb 6 22:20:30 2018] hub_event+0x52b/0x15d0 [usbcore] [Tue Feb 6 22:20:30 2018] process_one_work+0x185/0x380 [Tue Feb 6 22:20:30 2018] worker_thread+0x2e/0x390 [Tue Feb 6 22:20:30 2018] ? process_one_work+0x380/0x380 [Tue Feb 6 22:20:30 2018] kthread+0x118/0x130 [Tue Feb 6 22:20:30 2018] ? kthread_create_on_node+0x70/0x70 [Tue Feb 6 22:20:30 2018] ret_from_fork+0x1f/0x30 [Tue Feb 6 22:20:30 2018] INFO: task scsi_eh_6:9856 blocked for more than 120 seconds. [Tue Feb 6 22:20:30 2018] Not tainted 4.14.0-3-amd64 #1 Debian 4.14.13-1 [Tue Feb 6 22:20:30 2018] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [Tue Feb 6 22:20:30 2018] scsi_eh_6 D0 9856 2 0x8000 [Tue Feb 6 22:20:30 2018] Call Trace: [Tue Feb 6 22:20:30 2018] ? __schedule+0x28e/0x880 [Tue Feb 6 22:20:30 2018] schedule+0x28/0x80 [Tue Feb 6 22:20:30 2018] async_synchronize_cookie
[PATCH v4] Add delay-init quirk for Corsair K70 RGB keyboards
Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.
Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
Signed-off-by: Jack Stocker
---
Changes in v4:
- Corrected 'real' name.
Changes in v3:
- Added correct v1 commit message.
Changes in v2:
- Moved K70 entry above Strafe to preserve ascending order.
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index a6aaf2f..0405d68 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -218,6 +218,9 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x1a0a, 0x0200), .driver_info =
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+ /* Corsair K70 RGB */
+ { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
--
2.7.4
--
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 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality
[+ Ard, who helped me chasing the initial issue] On 15/02/18 06:43, Bockholdt Arne wrote: > Hi all, > > on our Intel Atom C2578 server with a SuperMicro A1SAi board and a > Renesas uPD720201 USB 3.0 host controller the controller has stopped > working since kernel 4.13.x. Before that kernel the dmesg messages from > XHCI were: > > dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: xHCI Host Controller > dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: new USB bus registered, > assigned bus number 2 > dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: hcc params 0x014051cf > hci version 0x100 quirks 0x0010 > dmesg-4.12.1-serverv4.log:usb usb2: Manufacturer: Linux 4.12.1-serverv4 > xhci-hcd > dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: xHCI Host Controller > dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: new USB bus registered, > assigned bus number 3 > dmesg-4.12.1-serverv4.log:usb usb3: Manufacturer: Linux 4.12.1-serverv4 > xhci-hcd > > After that the message look like that: > > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: Resetting > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: Refused to change power > state, currently in D3 > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: xHCI Host Controller > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: new USB bus registered, > assigned bus number 2 > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: Host halt failed, -19 > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: can't setup: -19 > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: USB bus 2 deregistered > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: init :03:00.0 fail, -19 > > I've tested it with 4.15.3 too, it's still the same. I've narrowed it > down to the following patch: > > commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 > Author: Marc Zyngier mailto:marc.zyng...@arm.com>> > Date: Tue Aug 1 20:11:08 2017 -0500 > > xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue > > Reverting the patch on top of 4.15.3 restores the USB3 functionality on > our server. Please let me know if there is anything I can do to fix the > problem. Thank you. Hi Arne, This looks pretty bad. I suspect that once reset, the firmware is lost. I'll try to write a patch dumping some information about it. Ard: Do you know if the Cello board has a SPI flash connected to the Renesas chip, from which it would load the firmware? Another possibility is that power management kicks in, and that the endpoint is stuck there. Could also be firmware related, but not only. I'd welcome any idea on the subject, as I cannot reproduce this issue on the HW I have. It we cannot work out what exactly is causing this, we may have to default to not resetting the part and rely on a command-line option to do it... I can't say I'm a fan. Thanks, M. -- Jazz is not dead. It just smells funny... -- 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 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality
On 15 February 2018 at 19:29, Marc Zyngier wrote: > [+ Ard, who helped me chasing the initial issue] > > On 15/02/18 06:43, Bockholdt Arne wrote: >> Hi all, >> >> on our Intel Atom C2578 server with a SuperMicro A1SAi board and a >> Renesas uPD720201 USB 3.0 host controller the controller has stopped >> working since kernel 4.13.x. Before that kernel the dmesg messages from >> XHCI were: >> >> dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: xHCI Host Controller >> dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: new USB bus registered, >> assigned bus number 2 >> dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: hcc params 0x014051cf >> hci version 0x100 quirks 0x0010 >> dmesg-4.12.1-serverv4.log:usb usb2: Manufacturer: Linux 4.12.1-serverv4 >> xhci-hcd >> dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: xHCI Host Controller >> dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: new USB bus registered, >> assigned bus number 3 >> dmesg-4.12.1-serverv4.log:usb usb3: Manufacturer: Linux 4.12.1-serverv4 >> xhci-hcd >> >> After that the message look like that: >> >> dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: Resetting >> dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: Refused to change power >> state, currently in D3 >> dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: xHCI Host Controller >> dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: new USB bus registered, >> assigned bus number 2 >> dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: Host halt failed, -19 >> dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: can't setup: -19 >> dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: USB bus 2 deregistered >> dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: init :03:00.0 fail, -19 >> >> I've tested it with 4.15.3 too, it's still the same. I've narrowed it >> down to the following patch: >> >> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 >> Author: Marc Zyngier mailto:marc.zyng...@arm.com>> >> Date: Tue Aug 1 20:11:08 2017 -0500 >> >> xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue >> >> Reverting the patch on top of 4.15.3 restores the USB3 functionality on >> our server. Please let me know if there is anything I can do to fix the >> problem. Thank you. > Hi Arne, > > This looks pretty bad. I suspect that once reset, the firmware is lost. > I'll try to write a patch dumping some information about it. > > Ard: Do you know if the Cello board has a SPI flash connected to the > Renesas chip, from which it would load the firmware? > No. The system firmware includes a firmware image for the Renesas, and uploads it via the PCIe config space before attaching the ordinary xhci pci driver. https://lists.01.org/pipermail/edk2-devel/2017-April/010013.html This is actually rather annoying, because we cannot distribute the firmware image itself, so rebuilding the firmware from source involves finding your own copy. > Another possibility is that power management kicks in, and that the > endpoint is stuck there. Could also be firmware related, but not only. > I'd welcome any idea on the subject, as I cannot reproduce this issue on > the HW I have. > > It we cannot work out what exactly is causing this, we may have to > default to not resetting the part and rely on a command-line option to > do it... I can't say I'm a fan. > Given that the Cello implementation does not have non-volatile storage either, and the fact that the firmware upload occurs only once, my suspicion is that something else is going on here. -- 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: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT
On Thu, Feb 15, 2018 at 06:42:03PM +0100, Greg Kroah-Hartman wrote: > On Wed, Jan 31, 2018 at 10:24:45PM +, James Hogan wrote: > > 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 the > > patch "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) > > > > Signed-off-by: James Hogan > > Cc: Greg Kroah-Hartman > > Cc: Corentin Labbe > > Cc: linux-usb@vger.kernel.org > > Acked-by: Greg Kroah-Hartman Thanks, I'll apply this as a MIPS fix for 4.16. Okay to leave patch 2 for you to deal with Greg since it doesn't really directly affect MIPS nor is it important for 4.16? Cheers James signature.asc Description: Digital signature
Re: [PATCH 1/2] usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT
On Thu, Feb 15, 2018 at 09:38:48PM +, James Hogan wrote: > On Thu, Feb 15, 2018 at 06:42:03PM +0100, Greg Kroah-Hartman wrote: > > On Wed, Jan 31, 2018 at 10:24:45PM +, James Hogan wrote: > > > 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 the > > > patch "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) > > > > > > Signed-off-by: James Hogan > > > Cc: Greg Kroah-Hartman > > > Cc: Corentin Labbe > > > Cc: linux-usb@vger.kernel.org > > > > Acked-by: Greg Kroah-Hartman > > Thanks, I'll apply this as a MIPS fix for 4.16. > > Okay to leave patch 2 for you to deal with Greg since it doesn't really > directly affect MIPS nor is it important for 4.16? Just take both of them and be done with it :) 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
Re: [PATCH 1/2] usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT
On Thu, Feb 15, 2018 at 10:41:42PM +0100, Greg Kroah-Hartman wrote: > On Thu, Feb 15, 2018 at 09:38:48PM +, James Hogan wrote: > > On Thu, Feb 15, 2018 at 06:42:03PM +0100, Greg Kroah-Hartman wrote: > > > On Wed, Jan 31, 2018 at 10:24:45PM +, James Hogan wrote: > > > > 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 the > > > > patch "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) > > > > > > > > Signed-off-by: James Hogan > > > > Cc: Greg Kroah-Hartman > > > > Cc: Corentin Labbe > > > > Cc: linux-usb@vger.kernel.org > > > > > > Acked-by: Greg Kroah-Hartman > > > > Thanks, I'll apply this as a MIPS fix for 4.16. > > > > Okay to leave patch 2 for you to deal with Greg since it doesn't really > > directly affect MIPS nor is it important for 4.16? > > Just take both of them and be done with it :) Okay, Thanks James signature.asc Description: Digital signature
Q: usb_control_msg() parameters
Hello, I am trying to understand article on reverse engineering usb driver, published in http://www.linuxjournal.com/node/7353/print (2004) I have difficulties understanding the input to the function usb_control_msg() especially the 0x12, 0xc8 numbers. I could not find them in the article, then tried even in the delcom datasheet, but did not find it there too. These numbers refer to __u8 request, __u8 requesttype , value, and index, but I could not understand how they are figured it out in the article. usb_control_msg(led->udev, usb_sndctrlpipe(led->udev, 0), 0x12, <<--- ? 0xc8, <<-- ? (0x02 * 0x100) + 0x0a, <-- ? (0x00 * 0x100) + color, <-- ? buffer, 8, 2 * HZ); Thanks for any comment, Ran -- 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 v1 1/1] usb: cdc_acm: prevent race at write to acm while system resumes
Hi Greg, On 02/15/2018 09:37 AM, Greg KH wrote: Why hasn't the author of this patch signed off on it? This patch has been initially submitted with Gerrit-ID and some custom tags. During the scrubbing process of this unrelated details, I think the automated script accidentally deleted the signed-off tag. Let me confirm it with author and get back to you. Mostly I will submit a v2 with proper sign-off info. -- Sathyanarayanan Kuppuswamy Linux kernel developer -- 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/1] usb: cdc_acm: prevent race at write to acm while system resumes
From: Dominik Bozek
ACM driver may accept data to transmit while system is not fully
resumed. In this case ACM driver buffers data and prepare URBs
on usb anchor list.
There is a little chance that two tasks put a char and initiate
acm_tty_flush_chars(). In such a case, driver will put one URB
twice on usb anchor list.
This patch also reset length of data before resue of a buffer.
This not only prevent sending rubbish, but also lower risc of race.
Without this patch we hit following kernel panic in one of our
stabilty/stress tests.
[ 46.884442] *list_add double add*: new=9b2ab7289330,
prev=9b2ab7289330, next=9b2ab81e28e0.
[ 46.884476] Modules linked in: hci_uart btbcm bluetooth rfkill_gpio
igb_avb(O) cfg80211 snd_soc_sst_bxt_tdf8532 snd_soc_skl snd_soc_skl_ipc
snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_sst_acpi snd_soc_sst_match
snd_hda_ext_core snd_hda_core trusty_timer trusty_wall trusty_log trusty_virtio
trusty_ipc trusty_mem trusty_irq trusty virtio_ring virtio intel_ipu4_mmu_bxtB0
lib2600_mod_bxtB0 intel_ipu4_isys_mod_bxtB0 lib2600psys_mod_bxtB0
intel_ipu4_psys_mod_bxtB0 intel_ipu4_mod_bxtB0 intel_ipu4_wrapper_bxtB0
intel_ipu4_acpi videobuf2_dma_contig as3638 dw9714 lm3643 crlmodule smiapp
smiapp_pll
[ 46.884480] CPU: 1 PID: 33 Comm: kworker/u8:1 Tainted: G U W O
4.9.56-quilt-2e5dc0ac-g618ed69ced6e-dirty #4
[ 46.884489] Workqueue: events_unbound flush_to_ldisc
[ 46.884494] b98ac012bb08 ad3e82e5 b98ac012bb58
[ 46.884497] b98ac012bb48 ad0a23d1 0024ad6374dd
9b2ab7289330
[ 46.884500] 9b2ab81e28e0 9b2ab7289330 0002
[ 46.884501] Call Trace:
[ 46.884507] [] dump_stack+0x67/0x92
[ 46.884511] [] __warn+0xd1/0xf0
[ 46.884513] [] warn_slowpath_fmt+0x5f/0x80
[ 46.884516] [] __list_add+0xb3/0xc0
[ 46.884521] [] *usb_anchor_urb*+0x4c/0xa0
[ 46.884524] [] *acm_tty_flush_chars*+0x8f/0xb0
[ 46.884527] [] *acm_tty_put_char*+0x41/0x100
[ 46.884530] [] tty_put_char+0x24/0x40
[ 46.884533] [] do_output_char+0xa5/0x200
[ 46.884535] [] __process_echoes+0x148/0x290
[ 46.884538] [] n_tty_receive_buf_common+0x57c/0xb00
[ 46.884541] [] n_tty_receive_buf2+0x14/0x20
[ 46.884543] [] tty_ldisc_receive_buf+0x22/0x50
[ 46.884545] [] flush_to_ldisc+0xc5/0xe0
[ 46.884549] [] process_one_work+0x148/0x440
[ 46.884551] [] worker_thread+0x69/0x4a0
[ 46.884554] [] ? max_active_store+0x80/0x80
[ 46.884556] [] kthread+0x110/0x130
[ 46.884559] [] ? kthread_park+0x60/0x60
[ 46.884563] [] ret_from_fork+0x27/0x40
[ 46.884566] ---[ end trace 3bd599058b8a9eb3 ]---
Signed-off-by: Dominik Bozek
Signed-off-by: Kuppuswamy Sathyanarayanan
Acked-by: Oliver Neukum
---
drivers/usb/class/cdc-acm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 06b3b54..7b366a6 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -174,6 +174,7 @@ static int acm_wb_alloc(struct acm *acm)
wb = &acm->wb[wbn];
if (!wb->use) {
wb->use = 1;
+ wb->len = 0;
return wbn;
}
wbn = (wbn + 1) % ACM_NW;
@@ -805,16 +806,18 @@ static int acm_tty_write(struct tty_struct *tty,
static void acm_tty_flush_chars(struct tty_struct *tty)
{
struct acm *acm = tty->driver_data;
- struct acm_wb *cur = acm->putbuffer;
+ struct acm_wb *cur;
int err;
unsigned long flags;
+ spin_lock_irqsave(&acm->write_lock, flags);
+
+ cur = acm->putbuffer;
if (!cur) /* nothing to do */
- return;
+ goto out;
acm->putbuffer = NULL;
err = usb_autopm_get_interface_async(acm->control);
- spin_lock_irqsave(&acm->write_lock, flags);
if (err < 0) {
cur->use = 0;
acm->putbuffer = cur;
--
2.7.4
--
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: High CPU load produced by USB (DW2)
On 2/15/2018 5:20 PM, Mirza Krak wrote: > On 14 February 2018 at 13:07, Minas Harutyunyan > wrote: >> On 2/14/2018 12:57 PM, Mirza Krak wrote: >>> On 8 February 2018 at 14:53, Minas Harutyunyan >>> wrote: > > < snip > > >> >> I reviewed your interrupt count log again. About 140,000 interrupts in 2 >> seconds, obviously it's not SOF only interrupts. More probably, its NAK >> respond interrupts to SSPLIT/CSPLIT transactions. For this case I can >> recommend you to apply patch from Douglas Anderson: "[PATCH v2] usb: >> dwc2: host: Don't retry NAKed transactions right away" which already >> merged to 4.16-rc1. >> >> In your setups you see different behavior on different HUBs. Your HUBs >> have different "TT think time": 8 and 32. In USB2.0 spec "TT think time" >> described as follow "TT requires at most 8/32 FS bit times of inter >> transaction gap on a full-/low-speed downstream bus". So, your "worst" >> HUB with "TT think time"=8 sending more frequently SSPLIT/CSPLIT >> transactions which replied by NAK. As result you see about 4 time more >> interrupts comparing to "good" HUB. Could you please check interrupts >> count for "good" HUB and check "4 time" hypothesis. > > Did some further testing. The "good" HUB is actually as bad as the > "bad" HUB, and it was my setup that caused the different behavior. Did > not use the same devices etc. > > Once I made sure that the configuration and setup was the same on both > board I could see that the behaved similarly. And that is the > following interrupt load: > > - BT USB (FS) = ~80k interrupts / second > - Keyboard (FS) = ~80k interrupts / second > - WiFI USB (HS) = ~8k interrupts / second > > After applying the suggested patch [1], it is steady around 8k > interrupts / second no matter what device I connect (HS/FS, > HUB/NO-HUB). Which is acceptable and usable. Great! > > Should this patch be a candidate for stable? Because in the current > state, this combination DWC2 + HS HUB + FS device, is not "usable". > Ask the author of patch or dwc2 maintainer. Thanks, Minas > [1]. > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_commit_drivers_usb_dwc2-3Fh-3Dv4.16-2Drc1-26id-3D38d2b5fb75c15923fb89c32134516a623515bce4&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI&m=5Np0whDSSNNvE3TAVBpFa0JUmvQbS3qWdpC0PQssosY&s=CYTOKYUsKlYbJKodeDN_ZybQpBL0ULIyf2Y_MeZgV30&e= > -- 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: Q: usb_control_msg() parameters
On Fri, Feb 16, 2018 at 01:00:06AM +0200, Ran Shalit wrote: > Hello, > > I am trying to understand article on reverse engineering usb driver, > published in > http://www.linuxjournal.com/node/7353/print (2004) That article was written a _long_ time ago :( > I have difficulties understanding the input to the function usb_control_msg() > especially the 0x12, 0xc8 numbers. > I could not find them in the article, then tried even in the delcom > datasheet, but did not find it there too. > These numbers refer to __u8 request, __u8 requesttype , value, and > index, but I could not understand how they are figured it out in the > article. > > usb_control_msg(led->udev, > usb_sndctrlpipe(led->udev, 0), > 0x12, <<--- ? > 0xc8, <<-- ? > (0x02 * 0x100) + 0x0a, <-- ? > (0x00 * 0x100) + color, <-- ? > buffer, > 8, > 2 * HZ); I thought I got them from the data sheet for the device, but that was over a decade ago, so I really don't remember, 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
Re: Q: usb_control_msg() parameters
On Fri, Feb 16, 2018 at 8:54 AM, Greg KH wrote: > On Fri, Feb 16, 2018 at 01:00:06AM +0200, Ran Shalit wrote: >> Hello, >> >> I am trying to understand article on reverse engineering usb driver, >> published in >> http://www.linuxjournal.com/node/7353/print (2004) > > That article was written a _long_ time ago :( > >> I have difficulties understanding the input to the function usb_control_msg() >> especially the 0x12, 0xc8 numbers. >> I could not find them in the article, then tried even in the delcom >> datasheet, but did not find it there too. >> These numbers refer to __u8 request, __u8 requesttype , value, and >> index, but I could not understand how they are figured it out in the >> article. >> >> usb_control_msg(led->udev, >> usb_sndctrlpipe(led->udev, 0), >> 0x12, <<--- ? >> 0xc8, <<-- ? >> (0x02 * 0x100) + 0x0a, <-- ? >> (0x00 * 0x100) + color, <-- ? >> buffer, >> 8, >> 2 * HZ); > > I thought I got them from the data sheet for the device, but that was > over a decade ago, so I really don't remember, sorry. > My question can be more of a general question. I am trying to understand how I should set these arguments (in general) with another device for example. I did not find any complete example/documentation which gives more details as to how to set these arguments: request - USB message request value requesttype - USB message request type value value - USB message value index - USB message index value Thanks for the comments, Ran > 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
Re: [PATCH 6/6] usb: dwc2: Force mode optimizations
Hi, Grigor Tovmasyan writes: > Hi Balbi, > > I rebased this commit to your testing/next (see below). Are you sure you did? checking file drivers/usb/dwc2/core.c Hunk #1 FAILED at 367. Hunk #2 FAILED at 391. Hunk #3 FAILED at 403. Hunk #4 FAILED at 425. Hunk #5 FAILED at 441. Hunk #6 FAILED at 455. Hunk #7 succeeded at 481 with fuzz 2. Hunk #8 FAILED at 718. 7 out of 8 hunks FAILED checking file drivers/usb/dwc2/core.h Hunk #1 FAILED at 1116. 1 out of 1 hunk FAILED checking file drivers/usb/dwc2/hcd.c Hunk #1 FAILED at 141. Hunk #2 FAILED at 239. Hunk #3 FAILED at 2270. 3 out of 3 hunks FAILED checking file drivers/usb/dwc2/params.c Hunk #1 FAILED at 593. Hunk #2 FAILED at 620. Hunk #3 FAILED at 639. 3 out of 3 hunks FAILED checking file drivers/usb/dwc2/platform.c Hunk #1 FAILED at 427. 1 out of 1 hunk FAILED And this is after fixing your malformed patch with mangled lines. Please rebase again and use git send-email. For reference, My testing/next is @ 08900d3304bb787164e79a8942112208917d1ddd -- balbi signature.asc Description: PGP signature
Re: [PATCH] usb: musb: fix enumeration after resume
On Wed, 7 Feb 2018 14:37:00 -0600 Bin Liu wrote: > On Tue, Feb 06, 2018 at 08:00:24PM +0100, Andreas Kemnade wrote: > > Hi, > > > > On Tue, 6 Feb 2018 12:46:05 -0600 > > Bin Liu wrote: > > > > > Hi, > > > > > > On Sat, Jan 27, 2018 at 09:34:03AM +0100, Andreas Kemnade wrote: > > > > On dm3730 there are enumeration problems after resume. > > > > Investigation led to the cause that the MUSB_POWER_SOFTCONN > > > > bit is not set. If it was set before suspend (because it > > > > was enabled via musb_pullup()), it is set in > > > > musb_restore_context() so the pullup is enabled. But then > > > > musb_start() is called which overwrites MUSB_POWER and > > > > therefore disables MUSB_POWER_SOFTCONN, so no pullup is > > > > enabled and the device is not enumerated. > > > > > > Do you see the issue with the v4.15? > > > > > Yes. Tested without other patches. > > It was also there in earlier kernels but I had not had motivation enough > > to debug. > > Applied to my tree. Thanks. > > > So maybe it deserves a CC: Stable > > I would prefer it is first tested on each stable tree. > Tested with 4.16-rc1 with and without that patch The problem still exists and can be fixed by that patch. Regards, Andreas pgpLQssM4piPD.pgp Description: OpenPGP digital signature
Re: Q: usb_control_msg() parameters
On Fri, Feb 16, 2018 at 09:02:11AM +0200, Ran Shalit wrote: > On Fri, Feb 16, 2018 at 8:54 AM, Greg KH wrote: > > On Fri, Feb 16, 2018 at 01:00:06AM +0200, Ran Shalit wrote: > >> Hello, > >> > >> I am trying to understand article on reverse engineering usb driver, > >> published in > >> http://www.linuxjournal.com/node/7353/print (2004) > > > > That article was written a _long_ time ago :( > > > >> I have difficulties understanding the input to the function > >> usb_control_msg() > >> especially the 0x12, 0xc8 numbers. > >> I could not find them in the article, then tried even in the delcom > >> datasheet, but did not find it there too. > >> These numbers refer to __u8 request, __u8 requesttype , value, and > >> index, but I could not understand how they are figured it out in the > >> article. > >> > >> usb_control_msg(led->udev, > >> usb_sndctrlpipe(led->udev, 0), > >> 0x12, <<--- ? > >> 0xc8, <<-- ? > >> (0x02 * 0x100) + 0x0a, <-- ? > >> (0x00 * 0x100) + color, <-- ? > >> buffer, > >> 8, > >> 2 * HZ); > > > > I thought I got them from the data sheet for the device, but that was > > over a decade ago, so I really don't remember, sorry. > > > > My question can be more of a general question. > I am trying to understand how I should set these arguments (in > general) with another device for example. > I did not find any complete example/documentation which gives more > details as to how to set these arguments: > > request - USB message request value > requesttype - USB message request type value These either come from the USB spec itself, or from the device spec if it is a vendor-specific device. > value - USB message value > index - USB message index value And these come from the device specification. One such example of all of this would be the usb test and measurement driver. Look at the spec for that, it defines lots of control messages and the specific values for what they need to be. Same will be true of your specific device as well. Now if you don't have the spec for your device, well, that's a different story, and you somehow have to reverse engineer it, or find it out some other way. Hope this helps, 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
