About zero-length packet design for EHCI
Hi Alan, When reading the code (at qh_urb_transaction) about zero-length packet for EHCI, would you please help me on below questions: - I have not found the zero-length qtd prepared for control read (eg, the transfer size is multiple of wMaxPacketSize), Am I missing something? - Why the IN transfer doesn't need to prepare zero-length qtd? In the 2.0 spec, it does not say it is only for OUT. Ch 5.7.3 Ch 5.8.3 A bulk (interrupt) transfer is complete when the endpoint does one of the following: - Has transferred exactly the amount of data expected - Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet Ch 5.6.4 An isochronous IN endpoint must return a zero-length packet whenever data is requested at a faster interval than the specified interval and data is not available. Thanks. -- Best Regards, Peter Chen -- 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 RFC] 2/2 huawei_cdc_ncm: introduce new TX ncm stack
Ok, for now I should let go of this - might be it was a little bit too much for the time constaints I am having. But thank you for your effort Oliver. Anyway, trying to write this new TX engine helped me in understand better things and conceive the patch I sent you affecting cdc_ncm.c, which triggers some OOPSes but not in a qemu vm, so I can't read them actually. Any hint on my code is always apreciated, regardless. Enrico -- 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: Errata for Freescale root-hub TT?
Le Mon, 29 Jun 2015 16:40:52 +0800, Peter Chen peter.c...@freescale.com a écrit : I am not sure if you have noticed the patch[1], it is the solution for this issue, in the RTL, the default reserved time for one packet is 1023 bytes for siTD, so after 4 * 64 packets has transfered, the reserved time is not enough for 1023 bytes packet. This issue should exist at all ARC/Chipidea cores. In that case can't we enable the patch for all cores instead of using platform data flags ? Hi Matthieu This bit may also affects QH, we only make sure Freescale's part QH design does not be affected by this tt ctrl bits, but doesn't know other vender's. Peter
Re: Errata for Freescale root-hub TT?
Hi Peter, Le Mon, 29 Jun 2015 16:40:52 +0800, Peter Chen peter.c...@freescale.com a écrit : I am not sure if you have noticed the patch[1], it is the solution for this issue, in the RTL, the default reserved time for one packet is 1023 bytes for siTD, so after 4 * 64 packets has transfered, the reserved time is not enough for 1023 bytes packet. This issue should exist at all ARC/Chipidea cores. In that case can't we enable the patch for all cores instead of using platform data flags ? Matthieu -- 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: About zero-length packet design for EHCI
On Tue, Jun 30, 2015 at 12:03:34PM -0400, Alan Stern wrote: On Tue, 30 Jun 2015, Peter Chen wrote: Hi Alan, When reading the code (at qh_urb_transaction) about zero-length packet for EHCI, would you please help me on below questions: - I have not found the zero-length qtd prepared for control read (eg, the transfer size is multiple of wMaxPacketSize), Am I missing something? The status stage transaction for a control-IN transfer has length 0, but I guess that's not what you mean. Control-IN transfers don't have a zero-length QTD in the data stage because IN transfers _never_ have a zero-length QTD. Then, how to cover the ch 8.5.3.2 Variable-length Data Stage: If the data structure is an exact multiple of wMaxPacketSize for the pipe, the function will return a zero-length packet to indicate the end of the Data stage. By reading your answers below, does it mean neither host nor device need to prepare qtd and dtd for reading zero-length packet, the hardware can handle it, and knows the data stage is over? - Why the IN transfer doesn't need to prepare zero-length qtd? In the 2.0 spec, it does not say it is only for OUT. Ch 5.7.3 Ch 5.8.3 A bulk (interrupt) transfer is complete when the endpoint does one of the following: - Has transferred exactly the amount of data expected - Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet Right. The host doesn't know beforehand how much data the device will send during an IN transfer. It only knows how much data to expect -- the device might send less than that amount. Therefore the host must prepare QTDs for all the data it expects. Suppose the host expects the device will send 525 bytes. Then it prepares a 525-byte QTD. If the device sends a 512-byte packet followed by a 13-byte packet, all is well. But what if the device wants to send only 512 bytes? Then it sends a 512-byte packet followed by a 0-byte packet. When the host controller sees the 0-byte packet, it knows the transfer is over -- but we still had to prepare a full 525-byte QTD, because we didn't know beforehand that the device would send only 512 bytes. To put it another way, the sender indicates that he will send less data than expected by sending a short packet. If the amount of data he wants to send is _not_ a multiple of the maxpacket size, then nothing special needs to happen. The last packet will automatically be shorter than the maxpacket size. But if the amount of data he wants to send _is_ a multiple of the maxpacket size, then after sending all the data he still needs to send a short packet. Since there is no more data left to send, he is forced to send a zero-length packet. Thus, when the host is the sender (i.e., for an OUT transfer), the host has to send a zero-length packet if the amount of data is shorter than the device expects and is a multiple of the maxpacket size. When the host is the receiver (i.e., for an IN transfer), the _device_ is responsible for sending a zero-length packet -- not the host. Ch 5.6.4 An isochronous IN endpoint must return a zero-length packet whenever data is requested at a faster interval than the specified interval and data is not available. That's right, but you don't see it in ehci-hcd because for isochronous transfers, the packet lengths are always specified by the class driver in the urb_iso_packet_descriptor structures. Get it, thanks. -- Best Regards, Peter Chen -- 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
答复: about [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan
Hi，bjorn, Thanks for your kindly reply and providing so much info about linux wwan components! We'll make a deep research on linux wwan architecture, maybe we can support it in the newly developing products. About what you saying about submit the patch formally, what steps should I do? Is there any documents about it? Best Regards！ Jakio.chen 华为技术有限公司 Huawei Technologies Co., Ltd. Phone: 18909297056 Email: cqi.c...@huawei.com 地址：西安市锦业一路软件大厦G座 邮编：71 -邮件原件- 发件人: Bjørn Mork [mailto:bj...@mork.no] 发送时间: 2015年6月26日 17:21 收件人: Chenqi (jakio) 抄送: torva...@linux-foundation.org; aleksan...@aleksander.es; d...@redhat.com; oli...@neukum.org; ben.hutchi...@codethink.co.uk; linux-usb@vger.kernel.org; net...@vger.kernel.org; mar...@holtmann.org; xiaomao0...@hotmail.com; Zhangyuhan 主题: Re: about [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan Chenqi (jakio) cqi.c...@huawei.com writes: Hi, All, I'm from Huawei Technologies Co., Ltd, working in mobile broadband devices department. Huawei's broadband card don't support wwan in linux OS, there are several historical reasons: 1. Huawei produced dozens of broadband card types in past years, and our customers/users integrate our products in many different OS versions, We need give customer/user a continuous method to let them use convenience. 2. Wwan connection need application support, while we didn't test them for compatibility. Meanwhile, we have provided serial port to let other existing applications dial-up the connection I understand that you guys have some confusion why the Huawei broadband cards support wwan in windows OS but not in linux OS with the same device ID. Since wwan standard is used firstly in windows OS, when we pronounced to support this feature, wwan is not enabled in linux. So we keep the card's behavior in linux same as before. The Linux kernel/drivers/userspace always will attempt to use hardware in the same way Windows use it, or at least as close as we are able to get. The reason is simple: A billion (or whatever) Windows users is the best test lab you can get. You may not agree with this strategy, but as a hardware vendor you have to expect it to happen. The community will continue to develop support based on that assumption, even if you try to accommodate Linux by adding addiotional Linux specific features or modes. This wwan patch has great influence on our broadband cards, we have tested many our broadband cards with this kernel version, and this compatible issue is common. So please approve our modification for this problem. If noone else has any comments or objections here, then I am certainly not going to object to the proposed patch. Please go ahead and submit the patch formally. I am going to keep my big mouth shut :) I think the root cause of this issue is this kernel version trait the NCM as wwan devtype, maybe we can add a flag in usb descriptor in future to indicate whether the device support wwan or not, then Huawei can support wwan feature later for the newest product without introducing compatible issues. BTW: if we want to join the usb-ethernet kernel evolution in linux, which forum or organization should we join in? We can participate in it to avoid similar problems. USB networking drivers are discussed, along with other network drivers, on the net...@vger.kernel.org mailing list. Preferable with a copy to the linux-usb@vger.kernel.org mailing list for USB expert review. But as you point out above: wwan connections need application support. Userspace projects like ModemManager, oFono, libmbim, libqmi, umbim, uqmi and probably more, each have their own development forums/mailing lists. This is where the most important part of the wwan developemt takes place. Huawei have already made important contributions to the development of both Linux wwan drivers and userspace applications. I am sure all those projects will appreciate any further help Huawei are able to offer. Thanks a lot for your detailed introduction and explanation. Bjørn
答复: 答复: about [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan
Hi， Greg，
Got it！
Thanks
Jakio.chen
-邮件原件-
发件人: Greg KH [mailto:gre...@linuxfoundation.org]
发送时间: 2015年7月1日 9:05
收件人: Chenqi (jakio)
抄送: Bjørn Mork; torva...@linux-foundation.org; aleksan...@aleksander.es;
d...@redhat.com; oli...@neukum.org; ben.hutchi...@codethink.co.uk;
linux-usb@vger.kernel.org; net...@vger.kernel.org; mar...@holtmann.org;
xiaomao0...@hotmail.com; Zhangyuhan; Maqianni
主题: Re: 答复: about [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan
On Wed, Jul 01, 2015 at 12:49:01AM +, Chenqi (jakio) wrote:
Hi，bjorn,
Thanks for your kindly reply and providing so much info about linux wwan
components!
We'll make a deep research on linux wwan architecture, maybe we can support
it in the newly developing products.
About what you saying about submit the patch formally, what steps should I
do? Is there any documents about it?
The kernel source file, Documentation/SubmittingPatches describes the steps and
details everything you need to know about how to properly submit a kernel patch.
thanks,
greg k-h
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: [PATCH 5/7] usb: dwc3: qcom: switch dev_dbg() to dev_info()
On Tue, Jun 30, 2015 at 06:15:29PM -0500, Andy Gross wrote: On Tue, Jun 30, 2015 at 12:56:48PM -0500, Felipe Balbi wrote: those two messages are informing that the clock doesn't exist; that, however, is a valid situation and driver continues just fine by ignoring the error. Reviewed-by: Andy Gross agr...@codeaurora.org thanks, added this to testing/next -- balbi signature.asc Description: Digital signature
Re: 答复: about [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan
On Wed, Jul 01, 2015 at 12:49:01AM +, Chenqi (jakio) wrote: Hi，bjorn, Thanks for your kindly reply and providing so much info about linux wwan components! We'll make a deep research on linux wwan architecture, maybe we can support it in the newly developing products. About what you saying about submit the patch formally, what steps should I do? Is there any documents about it? The kernel source file, Documentation/SubmittingPatches describes the steps and details everything you need to know about how to properly submit a kernel patch. 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: [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.
It's pointless to post a patch that you know has problems with it (i.e. it's not even in proper kernel coding style), as it will never be reviewed or even looked at. Thanks for the reply, and I'm sorry for the clumsy ask. I would still appreciate feedback on two points: 1. Is the basic premise reasonable? Is Hans correct in asserting that an alternate USB over IP module will be considered? 2. Do I correctly understand that there are no circumstances where copied code can be left unmodified? Even in the case where the copied code is working, production code, and the changes would be just for style? Please do the most basic of polite things and fix this up before posting things. It is often difficult for a newcomer to know what the polite thing is, even after studying FAQs and documentation. I appreciate your patience (and clue bats) as I try to learn. And really, all in one patch? That too is pretty hard to review... Yeah. I see the point of pain. I did not see a solution as I formed the patch, but I'll try harder before resending. Cheers, Jeremy -- 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 5/5] usb: phy: msm-usb: Replace deprecated API of extcon
This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).
Alter deprecated API as following:
- extcon_register_interest() - extcon_register_notifier()
- extcon_get_cable_state(*edev, char *) - extcon_get_cable_state_(*edev, id)
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/usb/phy/phy-msm-usb.c | 20 ++--
include/linux/usb/msm_hsusb.h | 2 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 00c49bb1bd29..61d86d8bf5b7 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1561,15 +1561,16 @@ static int msm_otg_read_dt(struct platform_device
*pdev, struct msm_otg *motg)
}
if (!IS_ERR(ext_vbus)) {
+ motg-vbus.extcon = ext_vbus;
motg-vbus.nb.notifier_call = msm_otg_vbus_notifier;
- ret = extcon_register_interest(motg-vbus.conn, ext_vbus-name,
- USB, motg-vbus.nb);
+ ret = extcon_register_notifier(ext_vbus, EXTCON_USB,
+ motg-vbus.nb);
if (ret 0) {
dev_err(pdev-dev, register VBUS notifier failed\n);
return ret;
}
- ret = extcon_get_cable_state(ext_vbus, USB);
+ ret = extcon_get_cable_state_(ext_vbus, EXTCON_USB);
if (ret)
set_bit(B_SESS_VLD, motg-inputs);
else
@@ -1577,15 +1578,16 @@ static int msm_otg_read_dt(struct platform_device
*pdev, struct msm_otg *motg)
}
if (!IS_ERR(ext_id)) {
+ motg-id.extcon = ext_id;
motg-id.nb.notifier_call = msm_otg_id_notifier;
- ret = extcon_register_interest(motg-id.conn, ext_id-name,
- USB-HOST, motg-id.nb);
+ ret = extcon_register_notifier(ext_id, EXTCON_USB_HOST,
+ motg-id.nb);
if (ret 0) {
dev_err(pdev-dev, register ID notifier failed\n);
return ret;
}
- ret = extcon_get_cable_state(ext_id, USB-HOST);
+ ret = extcon_get_cable_state_(ext_id, EXTCON_USB_HOST);
if (ret)
clear_bit(ID, motg-inputs);
else
@@ -1805,10 +1807,8 @@ static int msm_otg_remove(struct platform_device *pdev)
if (phy-otg-host || phy-otg-gadget)
return -EBUSY;
- if (motg-id.conn.edev)
- extcon_unregister_interest(motg-id.conn);
- if (motg-vbus.conn.edev)
- extcon_unregister_interest(motg-vbus.conn);
+ extcon_unregister_notifier(motg-id.extcon, EXTCON_USB_HOST,
motg-id.nb);
+ extcon_unregister_notifier(motg-vbus.extcon, EXTCON_USB,
motg-vbus.nb);
msm_otg_debugfs_cleanup();
cancel_delayed_work_sync(motg-chg_work);
diff --git a/include/linux/usb/msm_hsusb.h b/include/linux/usb/msm_hsusb.h
index e55a1504266e..5df2c8f59aa0 100644
--- a/include/linux/usb/msm_hsusb.h
+++ b/include/linux/usb/msm_hsusb.h
@@ -128,7 +128,7 @@ struct msm_otg_platform_data {
*/
struct msm_usb_cable {
struct notifier_block nb;
- struct extcon_specific_cable_nb conn;
+ struct extcon_dev *extcon;
};
/**
--
1.8.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] usb: renesas_usbhs: Replace deprecated API of extcon
This patch removes the deprecated API of extcon and then use the new extcon API
with the unique id to indicate the each external connector (USB-HOST).
- extcon_get_cable_state(*edev, char *) - extcon_get_cable_state_(*edev, id)
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Felipe Balbi ba...@ti.com
Cc: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Cc: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Cc: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Cc: Peter Chen peter.c...@freescale.com
Cc: Varka Bhadram var...@cdac.in
Cc: Takeshi Kihara takeshi.kihara...@renesas.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/usb/renesas_usbhs/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index e8bf40808b39..7b98e1d9194c 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -388,7 +388,7 @@ static void usbhsc_hotplug(struct usbhs_priv *priv)
if (enable !mod) {
if (priv-edev) {
- cable = extcon_get_cable_state(priv-edev, USB-HOST);
+ cable = extcon_get_cable_state_(priv-edev,
EXTCON_USB_HOST);
if ((cable 0 id != USBHS_HOST) ||
(!cable id != USBHS_GADGET)) {
dev_info(pdev-dev,
--
1.8.5.5
--
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 3/5] usb: phy: tahvo: Use devm_extcon_dev_[allocate|register]() and replace deprecated API
This patch uses the devm_extcon_dev_[allocate|register]() to manage the
resource automatically and replace deprecated API as following:
- extcon_[set|get]_cable_state(*edev, char *) -
extcon_[set|get]_cable_state_(*edev, id)
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/usb/phy/phy-tahvo.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
index b40d6a87d694..ab5d364f6e8c 100644
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -57,7 +57,7 @@ struct tahvo_usb {
struct clk *ick;
int irq;
int tahvo_mode;
- struct extcon_dev extcon;
+ struct extcon_dev *extcon;
};
static const unsigned int tahvo_cable[] = {
@@ -121,7 +121,7 @@ static void check_vbus_state(struct tahvo_usb *tu)
prev_state = tu-vbus_state;
tu-vbus_state = reg TAHVO_STAT_VBUS;
if (prev_state != tu-vbus_state) {
- extcon_set_cable_state(tu-extcon, USB, tu-vbus_state);
+ extcon_set_cable_state_(tu-extcon, EXTCON_USB, tu-vbus_state);
sysfs_notify(tu-pt_dev-dev.kobj, NULL, vbus_state);
}
}
@@ -130,7 +130,7 @@ static void tahvo_usb_become_host(struct tahvo_usb *tu)
{
struct retu_dev *rdev = dev_get_drvdata(tu-pt_dev-dev.parent);
- extcon_set_cable_state(tu-extcon, USB-HOST, true);
+ extcon_set_cable_state_(tu-extcon, EXTCON_USB_HOST, true);
/* Power up the transceiver in USB host mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_REGOUT | USBR_NSUSPEND |
@@ -149,7 +149,7 @@ static void tahvo_usb_become_peripheral(struct tahvo_usb
*tu)
{
struct retu_dev *rdev = dev_get_drvdata(tu-pt_dev-dev.parent);
- extcon_set_cable_state(tu-extcon, USB-HOST, false);
+ extcon_set_cable_state_(tu-extcon, EXTCON_USB_HOST, false);
/* Power up transceiver and set it in USB peripheral mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_SLAVE_CONTROL | USBR_REGOUT |
@@ -365,11 +365,13 @@ static int tahvo_usb_probe(struct platform_device *pdev)
*/
tu-vbus_state = retu_read(rdev, TAHVO_REG_IDSR) TAHVO_STAT_VBUS;
- tu-extcon.name = DRIVER_NAME;
- tu-extcon.supported_cable = tahvo_cable;
- tu-extcon.dev.parent = pdev-dev;
+ tu-extcon = devm_extcon_dev_allocate(pdev-dev, tahvo_cable);
+ if (IS_ERR(tu-extcon)) {
+ dev_err(pdev-dev, failed to allocate memory for extcon\n);
+ return -ENOMEM;
+ }
- ret = extcon_dev_register(tu-extcon);
+ ret = devm_extcon_dev_register(pdev-dev, tu-extcon);
if (ret) {
dev_err(pdev-dev, could not register extcon device: %d\n,
ret);
@@ -377,9 +379,9 @@ static int tahvo_usb_probe(struct platform_device *pdev)
}
/* Set the initial cable state. */
- extcon_set_cable_state(tu-extcon, USB-HOST,
+ extcon_set_cable_state_(tu-extcon, EXTCON_USB_HOST,
tu-tahvo_mode == TAHVO_MODE_HOST);
- extcon_set_cable_state(tu-extcon, USB, tu-vbus_state);
+ extcon_set_cable_state_(tu-extcon, EXTCON_USB, tu-vbus_state);
/* Create OTG interface */
tahvo_usb_power_off(tu);
@@ -396,7 +398,7 @@ static int tahvo_usb_probe(struct platform_device *pdev)
if (ret 0) {
dev_err(pdev-dev, cannot register USB transceiver: %d\n,
ret);
- goto err_extcon_unreg;
+ goto err_disable_clk;
}
dev_set_drvdata(pdev-dev, tu);
@@ -424,8 +426,6 @@ err_free_irq:
free_irq(tu-irq, tu);
err_remove_phy:
usb_remove_phy(tu-phy);
-err_extcon_unreg:
- extcon_dev_unregister(tu-extcon);
err_disable_clk:
if (!IS_ERR(tu-ick))
clk_disable(tu-ick);
@@ -440,7 +440,6 @@ static int tahvo_usb_remove(struct platform_device *pdev)
sysfs_remove_group(pdev-dev.kobj, tahvo_attr_group);
free_irq(tu-irq, tu);
usb_remove_phy(tu-phy);
- extcon_dev_unregister(tu-extcon);
if (!IS_ERR(tu-ick))
clk_disable(tu-ick);
--
1.8.5.5
--
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/5] usb: dwc3: omap: Replace deprecated API of extcon
This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).
Alter deprecated API as following:
- extcon_register_interest() - extcon_register_notifier()
- extcon_get_cable_state(*edev, char *) - extcon_get_cable_state_(*edev, id)
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/usb/dwc3/dwc3-omap.c | 32 +---
1 file changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 6b486a36863c..651a0e803882 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -128,8 +128,7 @@ struct dwc3_omap {
u32 dma_status:1;
- struct extcon_specific_cable_nb extcon_vbus_dev;
- struct extcon_specific_cable_nb extcon_id_dev;
+ struct extcon_dev *edev;
struct notifier_block vbus_nb;
struct notifier_block id_nb;
@@ -454,23 +453,23 @@ static int dwc3_omap_extcon_register(struct dwc3_omap
*omap)
}
omap-vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
- ret = extcon_register_interest(omap-extcon_vbus_dev,
- edev-name, USB,
- omap-vbus_nb);
+ ret = extcon_register_notifier(edev, EXTCON_USB,
+ omap-vbus_nb);
if (ret 0)
dev_vdbg(omap-dev, failed to register notifier for
USB\n);
omap-id_nb.notifier_call = dwc3_omap_id_notifier;
- ret = extcon_register_interest(omap-extcon_id_dev,
- edev-name, USB-HOST,
- omap-id_nb);
+ ret = extcon_register_notifier(edev, EXTCON_USB_HOST,
+ omap-id_nb);
if (ret 0)
dev_vdbg(omap-dev, failed to register notifier for
USB-HOST\n);
- if (extcon_get_cable_state(edev, USB) == true)
+ if (extcon_get_cable_state_(edev, EXTCON_USB) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
- if (extcon_get_cable_state(edev, USB-HOST) == true)
+ if (extcon_get_cable_state_(edev, EXTCON_USB_HOST) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
+
+ omap-edev = edev;
}
return 0;
@@ -565,11 +564,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
return 0;
err3:
- if (omap-extcon_vbus_dev.edev)
- extcon_unregister_interest(omap-extcon_vbus_dev);
- if (omap-extcon_id_dev.edev)
- extcon_unregister_interest(omap-extcon_id_dev);
-
+ extcon_unregister_notifier(omap-edev, EXTCON_USB, omap-vbus_nb);
+ extcon_unregister_notifier(omap-edev, EXTCON_USB_HOST, omap-id_nb);
err2:
dwc3_omap_disable_irqs(omap);
@@ -586,10 +582,8 @@ static int dwc3_omap_remove(struct platform_device *pdev)
{
struct dwc3_omap*omap = platform_get_drvdata(pdev);
- if (omap-extcon_vbus_dev.edev)
- extcon_unregister_interest(omap-extcon_vbus_dev);
- if (omap-extcon_id_dev.edev)
- extcon_unregister_interest(omap-extcon_id_dev);
+ extcon_unregister_notifier(omap-edev, EXTCON_USB, omap-vbus_nb);
+ extcon_unregister_notifier(omap-edev, EXTCON_USB_HOST, omap-id_nb);
dwc3_omap_disable_irqs(omap);
of_platform_depopulate(omap-dev);
pm_runtime_put_sync(pdev-dev);
--
1.8.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.
On Tue, Jun 30, 2015 at 10:34:25PM -0500, Jeremy White wrote: It's pointless to post a patch that you know has problems with it (i.e. it's not even in proper kernel coding style), as it will never be reviewed or even looked at. Thanks for the reply, and I'm sorry for the clumsy ask. I would still appreciate feedback on two points: 1. Is the basic premise reasonable? Is Hans correct in asserting that an alternate USB over IP module will be considered? I have no idea, if it fully replaces the usbip functionality, I don't see why that would be rejected. But why can't you just fix up usbip for the issues you find lacking? 2. Do I correctly understand that there are no circumstances where copied code can be left unmodified? Even in the case where the copied code is working, production code, and the changes would be just for style? I doubt the changes would just be for style if you are craming it into the kernel tree, as it's a totally different environment from any other place this code might have been running in before. Please do the most basic of polite things and fix this up before posting things. It is often difficult for a newcomer to know what the polite thing is, even after studying FAQs and documentation. Did you read Documentation/SubmittingPatches? I appreciate your patience (and clue bats) as I try to learn. And really, all in one patch? That too is pretty hard to review... Yeah. I see the point of pain. I did not see a solution as I formed the patch, but I'll try harder before resending. Remember you need to make this trivial to review in order to get it accepted. You have to do extra work because of this because our limited resource is reviewers and maintainers, not developers. 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
[EDT][PATCH] USB XHCI: Bugfix for NULL pointer deference in xhci_endpoint_init() function
EP-D52BC23FD00D4E2BBEED88BA6AF8C4AC virt_dev-num_cached_rings counts on freed ring and is not updated correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring is added into cache and then num_rings_cache is incremented as below: virt_dev-ring_cache[rings_cached] = virt_dev-eps[ep_index].ring; virt_dev-num_rings_cached++; here, free ring pointer is added to a current index and then index is incremented. So current index always points to empty location in the ring cache. For getting available free ring, current index should be decremented first and then corresponding ring buffer value should be taken from ring cache. But In function xhci_endpoint_init(), the num_rings_cached index is accessed before decrement. virt_dev-eps[ep_index].new_ring = virt_dev-ring_cache[virt_dev-num_rings_cached]; virt_dev-ring_cache[virt_dev-num_rings_cached] = NULL; virt_dev-num_rings_cached--; This is bug in manipulating the index of ring cache. And it should be as below: virt_dev-num_rings_cached--; virt_dev-eps[ep_index].new_ring = virt_dev-ring_cache[virt_dev-num_rings_cached]; virt_dev-ring_cache[virt_dev-num_rings_cached] = NULL; Signed-off-by: Aman Deep aman.d...@samsung.com --- drivers/usb/host/xhci-mem.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index f833640..3e442f7 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1427,10 +1427,10 @@ int xhci_endpoint_init(struct xhci_hcd *xhci, /* Attempt to use the ring cache */ if (virt_dev-num_rings_cached == 0) return -ENOMEM; + virt_dev-num_rings_cached--; virt_dev-eps[ep_index].new_ring = virt_dev-ring_cache[virt_dev-num_rings_cached]; virt_dev-ring_cache[virt_dev-num_rings_cached] = NULL; - virt_dev-num_rings_cached--; xhci_reinit_cached_ring(xhci, virt_dev-eps[ep_index].new_ring, 1, type); } -- 1.7.9.5
Re: Official bugreport 4.1 kernel (audio gadget and ChipIdea)
On Tuesday, June 30, 2015 at 04:23:01 AM, Peter Chen wrote: On Fri, Jun 26, 2015 at 07:15:18PM +0200, Sébastien Pruvost wrote: Hello, I'm sending this mail to report a bug concerning the latest kernel 4.1. Here is the problem (and the test I've done): I have firstly used the 3.10.53 kernel for my two sabrelites in order to use the audio gadget driver with the Dual Role ChipIdea Controller (in order to switch roles between my two IMX6 sabreLite). After loading g_audio in my two sabreLite and plugging the cable (microA – microB), there is an error “ci_hdrc.0 request length too big for isochronous snd_uac2.0 1116 Error”. And even after running aplay command, I still got this error and there is no sound getting out of the jack port. I've switched roles between the two boards by following this: https:// www.kernel.org/doc/Documentation/usb/chipidea.txt. This works fine with the serial driver, I can see a new serial interface (host side) and after switching role a new serial interfaces at device side. Same thing for ethernet gadget: this works fine too. But not with the audio gadget. In fact, there is a new audio interface at host side but I can not interact with it (even alsamixer doesn’t see any controls on this new sound card). I’ve tested that audio gadget works fine if I don’t use ChipIdea HighSpeed Dual Role Controller. Secondly I have tested this audio gadget with the latest Kernel 4.1 for my two IMX6 sabrelites (imx_v6_v7_defconfig). Now these previous errors are gone but there are still no sound getting out of the jack port (even if there are a new sound card in host side) It is may not a role switch problem, please check if the g_audio can work well with an ubuntu PC (make sure your codec works well). ci_hdrc.0 request length too big for isochronous Doesn't this just mean it cannot transfer such a long buffer via ISO pipe ? I guess the UAC should send smaller buffers to work with the CI HDRC? Best regards, Marek Vasut -- 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: move assignment out of if condition
Fix four occurrences of the checkpatch.pl error:
ERROR: do not use assignment in if condition
Signed-off-by: Kris Borer kbo...@gmail.com
---
drivers/usb/core/hcd.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index be5b207..e268c45 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2683,12 +2683,13 @@ int usb_add_hcd(struct usb_hcd *hcd,
* bottom up so that hcds can customize the root hubs before hub_wq
* starts talking to them. (Note, bus id is assigned early too.)
*/
- if ((retval = hcd_buffer_create(hcd)) != 0) {
+ retval = hcd_buffer_create(hcd);
+ if (retval != 0) {
dev_dbg(hcd-self.controller, pool alloc failed\n);
goto err_create_buf;
}
-
- if ((retval = usb_register_bus(hcd-self)) 0)
+ retval = usb_register_bus(hcd-self);
+ if (retval 0)
goto err_register_bus;
rhdev = usb_alloc_dev(NULL, hcd-self, 0);
@@ -2734,7 +2735,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
/* reset is misnamed; its role is now one-time init. the controller
* should already have been reset (and boot firmware kicked off etc).
*/
- if (hcd-driver-reset (retval = hcd-driver-reset(hcd)) 0) {
+ retval = hcd-driver-reset(hcd);
+ if (hcd-driver-reset retval 0) {
dev_err(hcd-self.controller, can't setup: %d\n, retval);
goto err_hcd_driver_setup;
}
@@ -2766,7 +2768,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
/* starting here, usbcore will pay attention to this root hub */
- if ((retval = register_root_hub(hcd)) != 0)
+ retval = register_root_hub(hcd);
+ if (retval != 0)
goto err_register_root_hub;
retval = sysfs_create_group(rhdev-dev.kobj, usb_bus_attr_group);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: move assignment out of if condition
Hello.
On 6/30/2015 4:02 PM, Kris Borer wrote:
Fix four occurrences of the checkpatch.pl error:
ERROR: do not use assignment in if condition
Signed-off-by: Kris Borer kbo...@gmail.com
---
drivers/usb/core/hcd.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index be5b207..e268c45 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
[...]
@@ -2734,7 +2735,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
/* reset is misnamed; its role is now one-time init. the controller
* should already have been reset (and boot firmware kicked off etc).
*/
- if (hcd-driver-reset (retval = hcd-driver-reset(hcd)) 0) {
+ retval = hcd-driver-reset(hcd);
+ if (hcd-driver-reset retval 0) {
If hcd-driver-reset() is NULL, this change warrants a kernel oops.
[...]
WBR, Sergei
--
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: move assignment out of if condition
On Tue, 2015-06-30 at 09:02 -0400, Kris Borer wrote:
Fix four occurrences of the checkpatch.pl error:
ERROR: do not use assignment in if condition
Signed-off-by: Kris Borer kbo...@gmail.com
Sorry, but NACK!
Those patches are totally broken.
---
drivers/usb/core/hcd.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index be5b207..e268c45 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2683,12 +2683,13 @@ int usb_add_hcd(struct usb_hcd *hcd,
* bottom up so that hcds can customize the root hubs before hub_wq
* starts talking to them. (Note, bus id is assigned early too.)
*/
- if ((retval = hcd_buffer_create(hcd)) != 0) {
+ retval = hcd_buffer_create(hcd);
+ if (retval != 0) {
dev_dbg(hcd-self.controller, pool alloc failed\n);
goto err_create_buf;
}
-
- if ((retval = usb_register_bus(hcd-self)) 0)
+ retval = usb_register_bus(hcd-self);
+ if (retval 0)
goto err_register_bus;
rhdev = usb_alloc_dev(NULL, hcd-self, 0);
@@ -2734,7 +2735,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
/* reset is misnamed; its role is now one-time init. the controller
* should already have been reset (and boot firmware kicked off etc).
*/
- if (hcd-driver-reset (retval = hcd-driver-reset(hcd)) 0) {
+ retval = hcd-driver-reset(hcd);
You happily follow the NULL pointer.
Regards
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
[PATCH] USB XHCI: Bugfix for NULL pointer deference in xhci_endpoint_init() function
virt_dev-num_cached_rings counts on freed ring and is not updated correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring is added into cache and then num_rings_cache is incremented as below: virt_dev-ring_cache[rings_cached] = virt_dev-eps[ep_index].ring; virt_dev-num_rings_cached++; here, free ring pointer is added to a current index and then index is incremented. So current index always points to empty location in the ring cache. For getting available free ring, current index should be decremented first and then corresponding ring buffer value should be taken from ring cache. But In function xhci_endpoint_init(), the num_rings_cached index is accessed before decrement. virt_dev-eps[ep_index].new_ring = virt_dev-ring_cache[virt_dev-num_rings_cached]; virt_dev-ring_cache[virt_dev-num_rings_cached] = NULL; virt_dev-num_rings_cached--; This is bug in manipulating the index of ring cache. And it should be as below: virt_dev-num_rings_cached--; virt_dev-eps[ep_index].new_ring = virt_dev-ring_cache[virt_dev-num_rings_cached]; virt_dev-ring_cache[virt_dev-num_rings_cached] = NULL; Signed-off-by: Aman Deep aman.d...@samsung.com --- drivers/usb/host/xhci-mem.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index f833640..3e442f7 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1427,10 +1427,10 @@ int xhci_endpoint_init(struct xhci_hcd *xhci, /* Attempt to use the ring cache */ if (virt_dev-num_rings_cached == 0) return -ENOMEM; + virt_dev-num_rings_cached--; virt_dev-eps[ep_index].new_ring = virt_dev-ring_cache[virt_dev-num_rings_cached]; virt_dev-ring_cache[virt_dev-num_rings_cached] = NULL; - virt_dev-num_rings_cached--; xhci_reinit_cached_ring(xhci, virt_dev-eps[ep_index].new_ring, 1, type); } -- 1.7.9.5
[PATCH 0/5] usb: Replace deprecated API of extcon
This patch removes the deprecated API of extcon framwork and then use the new extcon API with the unique id to indicate the each external connector. Th deprecated API with cable name as following: - int extcon_register_interest(struct extcon_specific_cable_nb *obj, const char *extcon_name, const char *cable_name, struct notifier_block *nb); - int extcon_unregister_interest(struct extcon_specific_cable_nb *nb); - int extcon_get_cable_state(struct extcon_dev *edev, const char *cable_name); - int extcon_set_cable_state(struct extcon_dev *edev, const char *cable_name, bool cable_state); The recommeded API with unique id of each external connector as following: - int extcon_register_notifier(struct extcon_dev *edev, unsigned int id, struct notifier_block *nb); - int extcon_unregister_notifier(struct extcon_dev *edev, unsigned int id, struct notifier_block *nb); - int extcon_get_cable_state_(struct extcon_dev *edev, unsigned int id); - int extcon_set_cable_state_(struct extcon_dev *edev, unsigned int id, bool cable_state); Depends on: This patch-set is based on latest linux.git[1] because this patch-set have the dependency of extcon patches for Linux v4.2. [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ Chanwoo Choi (5): usb: dwc3: omap: Replace deprecated API of extcon usb: phy: omap-otg: Replace deprecated API of extcon usb: phy: tahvo: Use devm_extcon_dev_[allocate|register]() and replace deprecated API usb: renesas_usbhs: Replace deprecated API of extcon usb: phy: msm-usb: Replace deprecated API of extcon drivers/usb/dwc3/dwc3-omap.c | 32 +--- drivers/usb/phy/phy-msm-usb.c | 20 ++-- drivers/usb/phy/phy-omap-otg.c | 22 +++--- drivers/usb/phy/phy-tahvo.c| 27 +-- drivers/usb/renesas_usbhs/common.c | 2 +- include/linux/usb/msm_hsusb.h | 2 +- 6 files changed, 49 insertions(+), 56 deletions(-) -- 1.8.5.5 -- 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/5] usb: phy: omap-otg: Replace deprecated API of extcon
This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).
Alter deprecated API as following:
- extcon_register_interest() - extcon_register_notifier()
- extcon_get_cable_state(*edev, char *) - extcon_get_cable_state_(*edev, id)
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/usb/phy/phy-omap-otg.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
index 56ee7603034b..12af8b1595ee 100644
--- a/drivers/usb/phy/phy-omap-otg.c
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -30,8 +30,7 @@ struct otg_device {
void __iomem*base;
boolid;
boolvbus;
- struct extcon_specific_cable_nb vbus_dev;
- struct extcon_specific_cable_nb id_dev;
+ struct extcon_dev *extcon;
struct notifier_block vbus_nb;
struct notifier_block id_nb;
};
@@ -106,6 +105,7 @@ static int omap_otg_probe(struct platform_device *pdev)
extcon = extcon_get_extcon_dev(config-extcon);
if (!extcon)
return -EPROBE_DEFER;
+ otd_dev-extcon = extcon;
otg_dev = devm_kzalloc(pdev-dev, sizeof(*otg_dev), GFP_KERNEL);
if (!otg_dev)
@@ -118,20 +118,19 @@ static int omap_otg_probe(struct platform_device *pdev)
otg_dev-id_nb.notifier_call = omap_otg_id_notifier;
otg_dev-vbus_nb.notifier_call = omap_otg_vbus_notifier;
- ret = extcon_register_interest(otg_dev-id_dev, config-extcon,
- USB-HOST, otg_dev-id_nb);
+ ret = extcon_register_notifier(extcon, EXTCON_USB_HOST,
otg_dev-id_nb);
if (ret)
return ret;
- ret = extcon_register_interest(otg_dev-vbus_dev, config-extcon,
- USB, otg_dev-vbus_nb);
+ ret = extcon_register_notifier(extcon, EXTCON_USB, otg_dev-vbus_nb);
if (ret) {
- extcon_unregister_interest(otg_dev-id_dev);
+ extcon_unregister_notifier(extcon, EXTCON_USB_HOST,
+ otg_dev-id_nb);
return ret;
}
- otg_dev-id = extcon_get_cable_state(extcon, USB-HOST);
- otg_dev-vbus = extcon_get_cable_state(extcon, USB);
+ otg_dev-id = extcon_get_cable_state_(extcon, EXTCON_USB_HOST);
+ otg_dev-vbus = extcon_get_cable_state_(extcon, EXTCON_USB);
omap_otg_set_mode(otg_dev);
rev = readl(otg_dev-base);
@@ -147,9 +146,10 @@ static int omap_otg_probe(struct platform_device *pdev)
static int omap_otg_remove(struct platform_device *pdev)
{
struct otg_device *otg_dev = platform_get_drvdata(pdev);
+ struct extcon_dev *edev = otg_dev-extcon;
- extcon_unregister_interest(otg_dev-id_dev);
- extcon_unregister_interest(otg_dev-vbus_dev);
+ extcon_unregister_notifier(edev, EXTCON_USB_HOST,otg_dev-id_nb);
+ extcon_unregister_notifier(edev, EXTCON_USB, otg_dev-vbus_nb);
return 0;
}
--
1.8.5.5
--
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: self-modeswitching device
On Tue, 30 Jun 2015, Oliver Neukum wrote: Hi, I am looking at a device that spontaneously switches its mode. I guess that you need to actively do something that some Windows versions do to keep the device in its initial mode. When does the spontaneous mode switch occur? The device contains an SD card reader. That leaves me in a predicament. The medium if it is mounted before the device switches will be dirty. Normally we say that unmounting before you switch is a responsibility of user space. But this device switches by itself. In that particular case I would go as far as make the storage driver refuse the storage interface of the initial mode. What do you think? I agree. If a storage device is going to disconnect itself at random times, we shouldn't try to access it. Users can override this behavior with usb-storage's i quirk flag if they need to. Alan Stern -- 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] usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers
Hi On 30.06.2015 04:54, Reyad Attiyat wrote: Hey Mathias, The intention is to send an extra endpoint packet of length zero as my wireless card needs this to function properly. I have skimmed through the xhci spec and assumed that each td would generate a packet. That is why I do not chain the last trb or add a interrupt flag, since I don't want to call the urb completion function called twice or called with the incorrect td or length. I just found in xhci 1.0 spec section 4.9.1 that To generate a zero-length USB transaction software shall explicitly define a TD with a single transfer TRB, and its TRB transfer length field shall equal 0 So with this in mind your approach was correct, we shouldn't chain the last data containing TRB with the zero TRB. This way xhci treats it as a separate TD. Xhci controller thinks we have two TDs, while the driver only sees one TD. This TD will interrupt in the middle, and has transferred all data before its last TRB. I suspect that this may cause some issues, especially if we stop at the zero trb and the driver has already returned the URB before the last TRB is handled. If we continue with this option we need to make sure handle_tx_events(), process_bulk_intr_td() and finish_td() work with with a SUCCESS bulk transfer event in the middle of a TD. and that an transfer event for the zero transfer received after URB is already returned doesn't mess anything up. As the xhci specs in 4.9.1 requires us to define a TD with a single TRB for the zero-packet, I think it would be better to add an additional TD to the bulk URB. Then we should check if we need a zero transfer already in xchi_urb_enqueue(), and make sure it allocates one more TD (doing size++ should be enough), and make sure xhci_queue_bulk_tx() can handle bulk URBs with two TDs. I have since tried a patch that just chains the trbs together, with the zero-length trb, and this still creates a zero-length packet. I was thinking I could remove the use of the last_trb variable I was using and simply chain all the trbs together and place the interupt flag on the zero-length trb if it exsits. Also I noticed that the other host controller drivers (ehci and ohci) check to ensure that the endpoint is sending data out and that the urb length is greater than zero. I will add these checks as well to keep in line with the their implementation. Adding the direction out check would be good. Do you think this is the best method for creating a zero-length packet, will every trb convert into at least one endpoint packet? I think adding a new TD for the zero length transfer would be the best option. This way we follow the specs. I started looking at zero-packet bulk issue only after your first patch, so there might be many things I haven't taken into consideration yet. -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: OHCI: Fix race between ED unlink and URB submission
This patch fixes a bug introduced by commit 977dcfdc6031 (USB: OHCI:
don't lose track of EDs when a controller dies). The commit changed
ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
been called. The user-visible consequence is that the driver
occasionally crashes or locks up when an URB is submitted while
another URB for the same endpoint is being unlinked.
This patch moves the ED state change later, to the right place. The
drawback is that now we may unnecessarily execute some instructions
multiple times when a controller dies. Since controllers dying is an
exceptional occurrence, a little wasted time won't matter.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Reported-by: Heiko Przybyl lil_...@web.de
Tested-by: Heiko Przybyl lil_...@web.de
Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e
CC: sta...@vger.kernel.org
---
[as1780]
drivers/usb/host/ohci-q.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
Index: usb-4.0/drivers/usb/host/ohci-q.c
===
--- usb-4.0.orig/drivers/usb/host/ohci-q.c
+++ usb-4.0/drivers/usb/host/ohci-q.c
@@ -980,10 +980,6 @@ rescan_all:
int completed, modified;
__hc32 *prev;
- /* Is this ED already invisible to the hardware? */
- if (ed-state == ED_IDLE)
- goto ed_idle;
-
/* only take off EDs that the HC isn't using, accounting for
* frame counter wraps and EDs with partially retired TDs
*/
@@ -1011,12 +1007,10 @@ skip_ed:
}
/* ED's now officially unlinked, hc doesn't see */
- ed-state = ED_IDLE;
ed-hwHeadP = ~cpu_to_hc32(ohci, ED_H);
ed-hwNextED = 0;
wmb();
ed-hwINFO = ~cpu_to_hc32(ohci, ED_SKIP | ED_DEQUEUE);
-ed_idle:
/* reentrancy: if we drop the schedule lock, someone might
* have modified this list. normally it's just prepending
@@ -1087,6 +1081,7 @@ rescan_this:
if (list_empty(ed-td_list)) {
*last = ed-ed_next;
ed-ed_next = NULL;
+ ed-state = ED_IDLE;
list_del(ed-in_use_list);
} else if (ohci-rh_state == OHCI_RH_RUNNING) {
*last = ed-ed_next;
--
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: host: xhci: remove typo in function documentation
Fix though to through in documentation of xhci_alloc_streams(). Signed-off-by: Luis de Bethencourt l...@debethencourt.com --- drivers/usb/host/xhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 7da0d60..e66857f 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -3117,7 +3117,7 @@ static u32 xhci_calculate_no_streams_bitmask(struct xhci_hcd *xhci, } /* - * The USB device drivers use this function (though the HCD interface in USB + * The USB device drivers use this function (through the HCD interface in USB * core) to prepare a set of bulk endpoints to use streams. Streams are used to * coordinate mass storage command queueing across multiple endpoints (basically * a stream ID == a task ID). -- 2.1.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][RFC] usbhid: enable autosuspend for internal devices
On Sat, 27 Jun 2015, Greg Kroah-Hartman wrote: On Fri, Jun 26, 2015 at 09:20:19PM -0400, Alan Stern wrote: My Apple keyboard isn't here at the moment, and I don't remember exactly what its hub descriptor contains. In theory, it _should_ mark the permanently attached port as non-removable. I can test it next week, if you would like to see the actual values. That would be great. Here we go: # lsusb -v -s 3:4 Bus 003 Device 004: ID 05ac:1002 Apple, Inc. Extended Keyboard Hub [Mitsumi] Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 8 idVendor 0x05ac Apple, Inc. idProduct 0x1002 Extended Keyboard Hub [Mitsumi] bcdDevice1.22 iManufacturer 1 Mitsumi Electric iProduct2 Hub in Apple Extended USB Keyboard iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 50mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 3 wHubCharacteristic 0x0004 Ganged power switching Compound device Ganged overcurrent protection bPwrOn2PwrGood 22 * 2 milli seconds bHubContrCurrent 50 milli Ampere DeviceRemovable0x02 PortPwrCtrlMask0xff Hub Port Status: Port 1: .0103 power enable connect Port 2: .0100 power Port 3: .0100 power Device Status: 0x (Bus Powered) As you can see, the hub descriptor says that the hub is part of a compound device. Port 1 is attached to the internal keyboard controller, so it is connected and enabled, whereas the other two ports don't have anything plugged in right now. Most importantly, the DeviceRemovable bitmask is set to 0x02. Since bit 0 is reserved, the bit that is set corresponds to port 1. It is set to indicate that the port is non-removable (i.e., the meaning is the opposite of what the name suggests). And sure enough: $ cat /sys/bus/usb/devices/3-1.4.1/removable fixed (The internal hub is 3-1.4, and the keyboard controller is therefore 3-1.4.1.) I don't have any computers with a device permanently attached to an xHCI root-hub port. If someone else does, maybe they can check what happens when these two lines: if (!(wHubCharacteristics HUB_CHAR_COMPOUND)) return; are deleted from drivers/usb/core/hub.c:set_usb_port_removable(). Deleting those lines may cause the device to show up as fixed rather than removable. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB disks not recognized during boot
On Mon, 29 Jun 2015, Raphael Hertzog wrote: [ Please keep me in CC as I'm not subscribed ] Hello, I'm the happy owner of a Intel NUC D54250WYKH (updated it to latest Intel firmware) which has an XHCI host controller. It's connected over USB 3 to a JBOD-configured disk enclosure (ICYBOX IB-RD3640SU3E2) which uses a JMicron USB to ATA bridge. I have attached the output of lspci -v, lsusb -v, lshw to describe the hardware in more details. When I boot the computer, the disk enclosure is not detected/recognized (even though it's correctly powered up). I have to power cycle the disk enclosure while the NUC is running so that it gets properly detected (see dmesg-powercycle). The kernel messages do not show any obvious error during boot (see attached file dmesg-boot) I have this problem with the stock 4.1 kernel as well as all Debian kernels (3.16.x in Jessie, 4.0.x in Stretch). While googling for possible solutions to force a new detection of the hardware, I found the explanation of how to unbind/rebind the xhci_hcd module: echo -n :00:14.0 /sys/bus/pci/drivers/xhci_hcd/unbind echo -n :00:14.0 /sys/bus/pci/drivers/xhci_hcd/bind (with :00:14.0 the PCI identifier of the xHCI root hub) This does not work for me. The undetected disk enclosure stays unnoticed... only the hardware power cycle works. I also tried to tweak the usbcore options (disabling autosuspend, old_scheme_first=Y, increasing initial_descriptor_timeout to 15000) but none of this did help. Do you have any suggestion of what could be wrong in my setup ? I'm happy to try patches and/or do further tests. Offhand, it sounds like something is wrong with the enclosure. It's possible that the BIOS does something strange to it, which prevents it from working until the power is cycled. Have you checked for BIOS updates? Here's another thing you can do: Try capturing a usbmon trace while doing the unbind/bind test. Since a controller's usbmon trace file doesn't exist until after it is bound, you will have to run your trace on the /sys/kernel/debug/usb/usbmon/0u file, which will capture information on _all_ USB buses -- so try to minimize other USB activity while running the test. Alan Stern -- 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
self-modeswitching device
Hi, I am looking at a device that spontaneously switches its mode. I guess that you need to actively do something that some Windows versions do to keep the device in its initial mode. The device contains an SD card reader. That leaves me in a predicament. The medium if it is mounted before the device switches will be dirty. Normally we say that unmounting before you switch is a responsibility of user space. But this device switches by itself. In that particular case I would go as far as make the storage driver refuse the storage interface of the initial mode. What do you think? Regards 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: About zero-length packet design for EHCI
On Tue, 30 Jun 2015, Peter Chen wrote: Hi Alan, When reading the code (at qh_urb_transaction) about zero-length packet for EHCI, would you please help me on below questions: - I have not found the zero-length qtd prepared for control read (eg, the transfer size is multiple of wMaxPacketSize), Am I missing something? The status stage transaction for a control-IN transfer has length 0, but I guess that's not what you mean. Control-IN transfers don't have a zero-length QTD in the data stage because IN transfers _never_ have a zero-length QTD. - Why the IN transfer doesn't need to prepare zero-length qtd? In the 2.0 spec, it does not say it is only for OUT. Ch 5.7.3 Ch 5.8.3 A bulk (interrupt) transfer is complete when the endpoint does one of the following: - Has transferred exactly the amount of data expected - Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet Right. The host doesn't know beforehand how much data the device will send during an IN transfer. It only knows how much data to expect -- the device might send less than that amount. Therefore the host must prepare QTDs for all the data it expects. Suppose the host expects the device will send 525 bytes. Then it prepares a 525-byte QTD. If the device sends a 512-byte packet followed by a 13-byte packet, all is well. But what if the device wants to send only 512 bytes? Then it sends a 512-byte packet followed by a 0-byte packet. When the host controller sees the 0-byte packet, it knows the transfer is over -- but we still had to prepare a full 525-byte QTD, because we didn't know beforehand that the device would send only 512 bytes. To put it another way, the sender indicates that he will send less data than expected by sending a short packet. If the amount of data he wants to send is _not_ a multiple of the maxpacket size, then nothing special needs to happen. The last packet will automatically be shorter than the maxpacket size. But if the amount of data he wants to send _is_ a multiple of the maxpacket size, then after sending all the data he still needs to send a short packet. Since there is no more data left to send, he is forced to send a zero-length packet. Thus, when the host is the sender (i.e., for an OUT transfer), the host has to send a zero-length packet if the amount of data is shorter than the device expects and is a multiple of the maxpacket size. When the host is the receiver (i.e., for an IN transfer), the _device_ is responsible for sending a zero-length packet -- not the host. Ch 5.6.4 An isochronous IN endpoint must return a zero-length packet whenever data is requested at a faster interval than the specified interval and data is not available. That's right, but you don't see it in ehci-hcd because for isochronous transfers, the packet lengths are always specified by the class driver in the urb_iso_packet_descriptor structures. Alan Stern -- 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: move assignment out of if condition
On Tue, Jun 30, 2015 at 09:02:22AM -0400, Kris Borer wrote: Fix four occurrences of the checkpatch.pl error: ERROR: do not use assignment in if condition If you are going to do stuff like this, use Coccinelle so you are sure you don't break the code. Also always test your changes, if possible. 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: [Bug 100631] Usb device not functioning in initramfs luks disk unlock
On Tue, Jun 30, 2015 at 08:53:14AM +0200, Glasswall Information Point wrote: Op 29-06-15 om 19:01 schreef bugzilla-dae...@bugzilla.kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=100631 --- Comment #1 from Greg Kroah-Hartman g...@kroah.com --- On Mon, Jun 29, 2015 at 09:53:04AM +, bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=100631 Bug ID: 100631 Summary: Usb device not functioning in initramfs luks disk unlock Please send to the linux-usb@vger.kernel.org mailing list. Sending a random link isn't ok, please include the information here as well. 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: self-modeswitching device
On Tue, 2015-06-30 at 11:34 -0400, Alan Stern wrote: On Tue, 30 Jun 2015, Oliver Neukum wrote: Hi, I am looking at a device that spontaneously switches its mode. I guess that you need to actively do something that some Windows versions do to keep the device in its initial mode. When does the spontaneous mode switch occur? 6 seconds after device discovery. In that particular case I would go as far as make the storage driver refuse the storage interface of the initial mode. What do you think? I agree. If a storage device is going to disconnect itself at random times, we shouldn't try to access it. Users can override this behavior with usb-storage's i quirk flag if they need to. Good. Regards 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 7/7] usb: dwc3: drop CONFIG_USB_DWC3_DEBUG
On Tue, Jun 30, 2015 at 12:56:50PM -0500, Felipe Balbi wrote: now that we have no users of dev_dbg() in dwc3, we can't safely remove CONFIG_USB_DWC3_DEBUG. If dev_dbg() is ever strictly necessary - and I don't see why it would, considering we want to rely on tracepoints for debug - we will depend on DYNAMIC_PRINTK to enable such messages. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/dwc3/Kconfig | 9 - drivers/usb/dwc3/Makefile | 2 -- 2 files changed, 11 deletions(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index dede32e809b6..cdd3eae604af 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -103,12 +103,3 @@ config USB_DWC3_QCOM help Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside, say 'Y' or 'M' if you have one such device. - -comment Debugging features - -config USB_DWC3_DEBUG - bool Enable Debugging Messages - help - Say Y here to enable debugging messages on DWC3 Driver. - -endif argh, of course I sent the wrong version :-) Here's the correct one 8-- From 775881f78c796a8988943ad3c487de38a18bd94f Mon Sep 17 00:00:00 2001 From: Felipe Balbi ba...@ti.com Date: Tue, 30 Jun 2015 12:51:49 -0500 Subject: [PATCH v2 7/7] usb: dwc3: drop CONFIG_USB_DWC3_DEBUG now that we have no users of dev_dbg() in dwc3, we can't safely remove CONFIG_USB_DWC3_DEBUG. If dev_dbg() is ever strictly necessary - and I don't see why it would, considering we want to rely on tracepoints for debug - we will depend on DYNAMIC_PRINTK to enable such messages. Signed-off-by: Felipe Balbi ba...@ti.com --- changes since v1 - fix erroneous removal of endif drivers/usb/dwc3/Kconfig | 7 --- drivers/usb/dwc3/Makefile | 2 -- 2 files changed, 9 deletions(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index dede32e809b6..5a42c4590402 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -104,11 +104,4 @@ config USB_DWC3_QCOM Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside, say 'Y' or 'M' if you have one such device. -comment Debugging features - -config USB_DWC3_DEBUG - bool Enable Debugging Messages - help - Say Y here to enable debugging messages on DWC3 Driver. - endif diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile index c7076e37c4ed..acc951d46c27 100644 --- a/drivers/usb/dwc3/Makefile +++ b/drivers/usb/dwc3/Makefile @@ -1,8 +1,6 @@ # define_trace.h needs to know how to find our header CFLAGS_trace.o := -I$(src) -ccflags-$(CONFIG_USB_DWC3_DEBUG) := -DDEBUG - obj-$(CONFIG_USB_DWC3) += dwc3.o dwc3-y := core.o debug.o trace.o -- 2.4.4 -- balbi signature.asc Description: Digital signature
Re: [EDT][PATCH] USB XHCI: Bugfix for NULL pointer deference in xhci_endpoint_init() function
On Tue, Jun 30, 2015 at 12:10:40PM +, AMAN DEEP wrote: EP-D52BC23FD00D4E2BBEED88BA6AF8C4AC What does this mean? And what does [EDT] in your subject mean? Please fix up and resend properly. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] usb: dwc3: omap: drop dev_dbg() usage
Some of the messages were plain unnecessary
and some were actually errors. Fix it all
up.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 43 ---
1 file changed, 4 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 6b486a36863c..e8a09a88eddd 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -225,12 +225,10 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
switch (status) {
case OMAP_DWC3_ID_GROUND:
- dev_dbg(omap-dev, ID GND\n);
-
if (omap-vbus_reg) {
ret = regulator_enable(omap-vbus_reg);
if (ret) {
- dev_dbg(omap-dev, regulator enable failed\n);
+ dev_err(omap-dev, regulator enable failed\n);
return;
}
}
@@ -245,8 +243,6 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
break;
case OMAP_DWC3_VBUS_VALID:
- dev_dbg(omap-dev, VBUS Connect\n);
-
val = dwc3_omap_read_utmi_ctrl(omap);
val = ~USBOTGSS_UTMI_OTG_CTRL_SESSEND;
val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG
@@ -261,8 +257,6 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
regulator_disable(omap-vbus_reg);
case OMAP_DWC3_VBUS_OFF:
- dev_dbg(omap-dev, VBUS Disconnect\n);
-
val = dwc3_omap_read_utmi_ctrl(omap);
val = ~(USBOTGSS_UTMI_OTG_CTRL_SESSVALID
| USBOTGSS_UTMI_OTG_CTRL_VBUSVALID
@@ -273,7 +267,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
break;
default:
- dev_dbg(omap-dev, invalid state\n);
+ dev_WARN(omap-dev, invalid state\n);
}
}
@@ -284,37 +278,8 @@ static irqreturn_t dwc3_omap_interrupt(int irq, void
*_omap)
reg = dwc3_omap_read_irqmisc_status(omap);
- if (reg USBOTGSS_IRQMISC_DMADISABLECLR) {
- dev_dbg(omap-dev, DMA Disable was Cleared\n);
+ if (reg USBOTGSS_IRQMISC_DMADISABLECLR)
omap-dma_status = false;
- }
-
- if (reg USBOTGSS_IRQMISC_OEVT)
- dev_dbg(omap-dev, OTG Event\n);
-
- if (reg USBOTGSS_IRQMISC_DRVVBUS_RISE)
- dev_dbg(omap-dev, DRVVBUS Rise\n);
-
- if (reg USBOTGSS_IRQMISC_CHRGVBUS_RISE)
- dev_dbg(omap-dev, CHRGVBUS Rise\n);
-
- if (reg USBOTGSS_IRQMISC_DISCHRGVBUS_RISE)
- dev_dbg(omap-dev, DISCHRGVBUS Rise\n);
-
- if (reg USBOTGSS_IRQMISC_IDPULLUP_RISE)
- dev_dbg(omap-dev, IDPULLUP Rise\n);
-
- if (reg USBOTGSS_IRQMISC_DRVVBUS_FALL)
- dev_dbg(omap-dev, DRVVBUS Fall\n);
-
- if (reg USBOTGSS_IRQMISC_CHRGVBUS_FALL)
- dev_dbg(omap-dev, CHRGVBUS Fall\n);
-
- if (reg USBOTGSS_IRQMISC_DISCHRGVBUS_FALL)
- dev_dbg(omap-dev, DISCHRGVBUS Fall\n);
-
- if (reg USBOTGSS_IRQMISC_IDPULLUP_FALL)
- dev_dbg(omap-dev, IDPULLUP Fall\n);
dwc3_omap_write_irqmisc_status(omap, reg);
@@ -434,7 +399,7 @@ static void dwc3_omap_set_utmi_mode(struct dwc3_omap *omap)
reg = ~USBOTGSS_UTMI_OTG_CTRL_SW_MODE;
break;
default:
- dev_dbg(omap-dev, UNKNOWN utmi mode %d\n, utmi_mode);
+ dev_WARN(omap-dev, UNKNOWN utmi mode %d\n, utmi_mode);
}
dwc3_omap_write_utmi_ctrl(omap, reg);
--
2.4.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 4/7] usb: dwc3: exynos: switch dev_dbg() to dev_info()
that message is informing that the clock is missing.
However, that's a valid condition for some setups; driver
even ignores the error and continues just fine.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-exynos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 7bd0a95b2815..dd5cb5577dca 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -145,7 +145,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
exynos-susp_clk = devm_clk_get(dev, usbdrd30_susp_clk);
if (IS_ERR(exynos-susp_clk)) {
- dev_dbg(dev, no suspend clk specified\n);
+ dev_info(dev, no suspend clk specified\n);
exynos-susp_clk = NULL;
}
clk_prepare_enable(exynos-susp_clk);
--
2.4.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 6/7] usb: dwc3: st: remove two unnecessary messages
the mode of operation is exposed through debugfs at all times. Because of that, we're removing the unnecessary messages. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/dwc3/dwc3-st.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c index 4a1a543deeda..de4d52f62517 100644 --- a/drivers/usb/dwc3/dwc3-st.c +++ b/drivers/usb/dwc3/dwc3-st.c @@ -135,8 +135,6 @@ static int st_dwc3_drd_init(struct st_dwc3 *dwc3_data) | USB3_SEL_FORCE_DMPULLDOWN2 | USB3_FORCE_DMPULLDOWN2); val |= USB3_DEVICE_NOT_HOST; - - dev_dbg(dwc3_data-dev, Configuring as Device\n); break; case USB_DR_MODE_HOST: @@ -154,8 +152,6 @@ static int st_dwc3_drd_init(struct st_dwc3 *dwc3_data) */ val |= USB3_DELAY_VBUSVALID; - - dev_dbg(dwc3_data-dev, Configuring as Host\n); break; default: -- 2.4.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 5/7] usb: dwc3: qcom: switch dev_dbg() to dev_info()
those two messages are informing that the clock
doesn't exist; that, however, is a valid situation
and driver continues just fine by ignoring the error.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-qcom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 8c2e8eec80c2..088026048f49 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -48,13 +48,13 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
qdwc-iface_clk = devm_clk_get(qdwc-dev, iface);
if (IS_ERR(qdwc-iface_clk)) {
- dev_dbg(qdwc-dev, failed to get optional iface clock\n);
+ dev_info(qdwc-dev, failed to get optional iface clock\n);
qdwc-iface_clk = NULL;
}
qdwc-sleep_clk = devm_clk_get(qdwc-dev, sleep);
if (IS_ERR(qdwc-sleep_clk)) {
- dev_dbg(qdwc-dev, failed to get optional sleep clock\n);
+ dev_info(qdwc-dev, failed to get optional sleep clock\n);
qdwc-sleep_clk = NULL;
}
--
2.4.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 3/7] usb: dwc3: keystone: convert dev_dbg() to dev_err()
that's an error condition, not a debugging message.
Let's promote it appropriately.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-keystone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c
index fe3b9335a74e..c1ca2a0a56ef 100644
--- a/drivers/usb/dwc3/dwc3-keystone.c
+++ b/drivers/usb/dwc3/dwc3-keystone.c
@@ -115,7 +115,7 @@ static int kdwc3_probe(struct platform_device *pdev)
error = clk_prepare_enable(kdwc-clk);
if (error 0) {
- dev_dbg(kdwc-dev, unable to enable usb clock, err %d\n,
+ dev_err(kdwc-dev, unable to enable usb clock, err %d\n,
error);
return error;
}
--
2.4.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/7] usb: dwc3: remove CONFIG_USB_DWC3_DEBUG
Hi, I plan to get these patches merged for v4.3 merge window. Let me know if you have any real objections. Keep in mind that I like dev_dbg() or I'm used to dev_dbg() are not valid objections. cheers Felipe Balbi (7): usb: dwc3: drop dev_dbg() from dwc3 usb: dwc3: omap: drop dev_dbg() usage usb: dwc3: keystone: convert dev_dbg() to dev_err() usb: dwc3: exynos: switch dev_dbg() to dev_info() usb: dwc3: qcom: switch dev_dbg() to dev_info() usb: dwc3: st: remove two unnecessary messages usb: dwc3: drop CONFIG_USB_DWC3_DEBUG drivers/usb/dwc3/Kconfig | 9 - drivers/usb/dwc3/Makefile| 2 -- drivers/usb/dwc3/core.c | 8 +--- drivers/usb/dwc3/dwc3-exynos.c | 2 +- drivers/usb/dwc3/dwc3-keystone.c | 2 +- drivers/usb/dwc3/dwc3-omap.c | 43 drivers/usb/dwc3/dwc3-qcom.c | 4 ++-- drivers/usb/dwc3/dwc3-st.c | 4 drivers/usb/dwc3/ep0.c | 4 ++-- drivers/usb/dwc3/gadget.c| 41 +- 10 files changed, 42 insertions(+), 77 deletions(-) -- 2.4.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 7/7] usb: dwc3: drop CONFIG_USB_DWC3_DEBUG
now that we have no users of dev_dbg() in dwc3, we can't safely remove CONFIG_USB_DWC3_DEBUG. If dev_dbg() is ever strictly necessary - and I don't see why it would, considering we want to rely on tracepoints for debug - we will depend on DYNAMIC_PRINTK to enable such messages. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/usb/dwc3/Kconfig | 9 - drivers/usb/dwc3/Makefile | 2 -- 2 files changed, 11 deletions(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index dede32e809b6..cdd3eae604af 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -103,12 +103,3 @@ config USB_DWC3_QCOM help Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside, say 'Y' or 'M' if you have one such device. - -comment Debugging features - -config USB_DWC3_DEBUG - bool Enable Debugging Messages - help - Say Y here to enable debugging messages on DWC3 Driver. - -endif diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile index c7076e37c4ed..acc951d46c27 100644 --- a/drivers/usb/dwc3/Makefile +++ b/drivers/usb/dwc3/Makefile @@ -1,8 +1,6 @@ # define_trace.h needs to know how to find our header CFLAGS_trace.o := -I$(src) -ccflags-$(CONFIG_USB_DWC3_DEBUG) := -DDEBUG - obj-$(CONFIG_USB_DWC3) += dwc3.o dwc3-y := core.o debug.o trace.o -- 2.4.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/7] usb: dwc3: drop dev_dbg() from dwc3
After this patch, the actual dwc3 driver
doesn't need dev_dbg(). After a couple more
patches on glue layers, we will be able to
remove CONFIG_DWC3_DEBUG and rely solely
on tracepoints for our debugging.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/core.c | 8 +---
drivers/usb/dwc3/ep0.c| 4 ++--
drivers/usb/dwc3/gadget.c | 41 +++--
3 files changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 5c110d8e293b..80dff84c224a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -245,7 +245,8 @@ static int dwc3_event_buffers_setup(struct dwc3 *dwc)
for (n = 0; n dwc-num_event_buffers; n++) {
evt = dwc-ev_buffs[n];
- dev_dbg(dwc-dev, Event buf %p dma %08llx length %d\n,
+ dwc3_trace(trace_dwc3_core,
+ Event buf %p dma %08llx length %d,
evt-buf, (unsigned long long) evt-dma,
evt-length);
@@ -572,12 +573,13 @@ static int dwc3_core_init(struct dwc3 *dwc)
reg |= DWC3_GCTL_GBLHIBERNATIONEN;
break;
default:
- dev_dbg(dwc-dev, No power optimization available\n);
+ dwc3_trace(trace_dwc3_core,
+ No power optimization available);
}
/* check if current dwc3 is on simulation board */
if (dwc-hwparams.hwparams6 DWC3_GHWPARAMS6_EN_FPGA) {
- dev_dbg(dwc-dev, it is on FPGA board\n);
+ dwc3_trace(trace_dwc3_core, it is on FPGA board);
dwc-is_fpga = true;
}
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 2ef3c8d6a9db..b8bf71634118 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -933,7 +933,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
ret = usb_gadget_map_request(dwc-gadget, req-request,
dep-number);
if (ret) {
- dev_dbg(dwc-dev, failed to map request\n);
+ dwc3_trace(trace_dwc3_ep0, failed to map request);
return;
}
@@ -956,7 +956,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
ret = usb_gadget_map_request(dwc-gadget, req-request,
dep-number);
if (ret) {
- dev_dbg(dwc-dev, failed to map request\n);
+ dwc3_trace(trace_dwc3_ep0, failed to map request);
return;
}
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 333a7c0078fc..c4915a095240 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -265,7 +265,8 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct
dwc3_request *req,
usb_gadget_unmap_request(dwc-gadget, req-request,
req-direction);
- dev_dbg(dwc-dev, request %p from %s completed %d/%d === %d\n,
+ dwc3_trace(trace_dwc3_gadget,
+ request %p from %s completed %d/%d === %d,
req, dep-name, req-request.actual,
req-request.length, status);
trace_dwc3_gadget_giveback(req);
@@ -984,7 +985,8 @@ static int __dwc3_gadget_kick_transfer(struct dwc3_ep *dep,
u16 cmd_param,
cmd |= DWC3_DEPCMD_PARAM(cmd_param);
ret = dwc3_send_gadget_ep_cmd(dwc, dep-number, cmd, params);
if (ret 0) {
- dev_dbg(dwc-dev, failed to send STARTTRANSFER command\n);
+ dwc3_trace(trace_dwc3_gadget,
+ failed to send STARTTRANSFER command);
/*
* FIXME we need to iterate over the list of requests
@@ -1095,7 +1097,8 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
ret = __dwc3_gadget_kick_transfer(dep, 0, true);
if (ret ret != -EBUSY)
- dev_dbg(dwc-dev, %s: failed to kick transfers\n,
+ dwc3_trace(trace_dwc3_gadget,
+ %s: failed to kick transfers,
dep-name);
return ret;
}
@@ -1112,7 +1115,8 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
ret = __dwc3_gadget_kick_transfer(dep, dep-resource_index,
false);
if (ret ret != -EBUSY)
- dev_dbg(dwc-dev, %s: failed to kick transfers\n,
+ dwc3_trace(trace_dwc3_gadget,
+ %s: failed to kick transfers,
dep-name);
return ret;
}
@@ -1125,7 +1129,8 @@
Re: [PATCH 3/7] usb: dwc3: keystone: convert dev_dbg() to dev_err()
Hello.
On 06/30/2015 08:56 PM, Felipe Balbi wrote:
that's an error condition, not a debugging message.
Let's promote it appropriately.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-keystone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c
index fe3b9335a74e..c1ca2a0a56ef 100644
--- a/drivers/usb/dwc3/dwc3-keystone.c
+++ b/drivers/usb/dwc3/dwc3-keystone.c
@@ -115,7 +115,7 @@ static int kdwc3_probe(struct platform_device *pdev)
error = clk_prepare_enable(kdwc-clk);
if (error 0) {
- dev_dbg(kdwc-dev, unable to enable usb clock, err %d\n,
+ dev_err(kdwc-dev, unable to enable usb clock, err %d\n,
Perhaps time to s/err/error/?
[...]
WBR, Sergei
--
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: OHCI: Fix race between ED unlink and URB submission
Hello. On 06/30/2015 06:25 PM, Alan Stern wrote: This patch fixes a bug introduced by commit 977dcfdc6031 (USB: OHCI: don't lose track of EDs when a controller dies). The commit changed ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had been called. The user-visible consequence is that the driver occasionally crashes or locks up when an URB is submitted while another URB for the same endpoint is being unlinked. This patch moves the ED state change later, to the right place. The drawback is that now we may unnecessarily execute some instructions multiple times when a controller dies. Since controllers dying is an exceptional occurrence, a little wasted time won't matter. Signed-off-by: Alan Stern st...@rowland.harvard.edu Reported-by: Heiko Przybyl lil_...@web.de Tested-by: Heiko Przybyl lil_...@web.de Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e Documentation/SubmittingPatches says to use 12-digit SHA1 and the summary after it enclosed in (). CC: sta...@vger.kernel.org WBR, Sergei -- 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: OHCI: Fix race between ED unlink and URB submission
On Tue, 30 Jun 2015, Sergei Shtylyov wrote: Hello. On 06/30/2015 06:25 PM, Alan Stern wrote: This patch fixes a bug introduced by commit 977dcfdc6031 (USB: OHCI: don't lose track of EDs when a controller dies). The commit changed ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had been called. The user-visible consequence is that the driver occasionally crashes or locks up when an URB is submitted while another URB for the same endpoint is being unlinked. This patch moves the ED state change later, to the right place. The drawback is that now we may unnecessarily execute some instructions multiple times when a controller dies. Since controllers dying is an exceptional occurrence, a little wasted time won't matter. Signed-off-by: Alan Stern st...@rowland.harvard.edu Reported-by: Heiko Przybyl lil_...@web.de Tested-by: Heiko Przybyl lil_...@web.de Fixes: 977dcfdc60311e7aa571cabf6f39c36dde13339e Documentation/SubmittingPatches says to use 12-digit SHA1 and the summary after it enclosed in (). Yes, you're right. I did it that way in the first two lines of the body of the patch description but not in the Fixes: tag. Greg can alter the text of the tag (by copying the reference in the body) if he wants. Alan Stern -- 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 7/7] usb: dwc3: drop CONFIG_USB_DWC3_DEBUG
Hello. On 06/30/2015 08:56 PM, Felipe Balbi wrote: now that we have no users of dev_dbg() in dwc3, we can't safely remove CONFIG_USB_DWC3_DEBUG. s/can't/can/. If dev_dbg() is ever strictly necessary - and I don't see why it would, considering we want to rely on tracepoints for debug - we will depend on DYNAMIC_PRINTK to enable such messages. Signed-off-by: Felipe Balbi ba...@ti.com [...] WBR, Sergei -- 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 v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
On Tue, 26 May 2015 16:18:54 +0100
, Lee Jones lee.jo...@linaro.org
wrote:
On Thu, 21 May 2015, Thierry Reding wrote:
On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
On Wed, 20 May 2015, Thierry Reding wrote:
On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
On Tue, 19 May 2015, Andrew Bresticker wrote:
On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
abres...@chromium.org wrote:
On Thu, May 14, 2015 at 12:40 AM, Lee Jones
lee.jo...@linaro.org wrote:
On Thu, 14 May 2015, Jon Hunter wrote:
On 13/05/15 15:39, Lee Jones wrote:
On Mon, 04 May 2015, Andrew Bresticker wrote:
Add a binding document for the XUSB host complex on NVIDIA
Tegra124
and later SoCs. The XUSB host complex includes a mailbox for
communication with the XUSB micro-controller and an xHCI
host-controller.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
---
Changes from v7:
- Move non-shared resources into child nodes.
New for v7.
---
.../bindings/mfd/nvidia,tegra124-xusb.txt | 37
++
1 file changed, 37 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
diff --git
a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
new file mode 100644
index 000..bc50110
--- /dev/null
+++
b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
@@ -0,0 +1,37 @@
+NVIDIA Tegra XUSB host copmlex
+==
+
+The XUSB host complex on Tegra124 and later SoCs contains
an xHCI host
+controller and a mailbox for communication with the XUSB
micro-controller.
+
+Required properties:
+
+ - compatible: For Tegra124, must contain
nvidia,tegra124-xusb.
+ Otherwise, must contain 'nvidia,chip-xusb,
nvidia,tegra124-xusb'
+ where chip is tegra132.
+ - reg: Must contain the base and length of the XUSB FPCI
registers.
+ - ranges: Bus address mapping for the XUSB block. Can be
empty since the
+ mapping is 1:1.
+ - #address-cells: Must be 2.
+ - #size-cells: Must be 2.
+
+Example:
+
+ usb@0,70098000 {
+ compatible = nvidia,tegra124-xusb;
+ reg = 0x0 0x70098000 0x0 0x1000;
+ ranges;
+
+ #address-cells = 2;
+ #size-cells = 2;
+
+ usb-host@0,7009 {
+ compatible = nvidia,tegra124-xhci;
+ ...
+ };
+
+ mailbox {
+ compatible = nvidia,tegra124-xusb-mbox;
+ ...
+ };
This doesn't appear to be a proper MFD. I would have the USB
and
Mailbox devices probe seperately and use a phandle to point
the USB
device to its Mailbox.
usb@xyz {
mboxes = xusb-mailbox, [chan];
};
I am assuming that Andrew had laid it out like this to reflect
the hw
structure. The mailbox and xhci controller are part of the xusb
sub-system and hence appear as child nodes. My understanding is
that for
device-tree we want the device-tree structure to reflect the
actual hw.
Is this not the case?
Yes, the DT files should reflect h/w. I have requested to see
what
the memory map looks like, so I might provide a more appropriate
solution to accepting a pretty pointless MFD.
FWIW, the address map for XUSB looks like this:
XUSB_HOST: 0x7009 - 0x7009a000
xHCI registers: 0x7009 - 0x70098000
FPCI configuration registers: 0x70098000 - 0x70099000
IPFS configuration registers: 0x70099000 - 0x7009a000
Two solutions spring to mind. You can either call
of_platform_populate() from the USB driver, as some already do:
drivers/usb/dwc3/dwc3-exynos.c:
ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-keystone.c:
error =
Re: [PATCH] phy: phy-mxs-usb: suspend to RAM causes NULL pointer dereference
Am 30.06.2015 um 08:10 schrieb Felipe Balbi: On Tue, Jun 30, 2015 at 07:30:35AM +0200, Stefan Wahren wrote: Am 15.06.2015 um 06:37 schrieb Stefan Wahren: Triggering suspend to RAM via sysfs on a i.MX28 causes a NULL pointer dereference. This patch avoids the oops in mxs_phy_get_vbus_status() by aborting since there is no syscon available. Signed-off-by: Stefan Wahren stefan.wah...@i2se.com Fixes: efdbd3a5d6e (usb: phy: mxs: do not set PWD.RXPWD1PT1 for low speed connection) CC: sta...@vger.kernel.org # 4.0 Acked-by: Peter Chen peter.c...@freescale.com Just a gentle ping it's in my queue, but -rc1 wasn't tagged yet, was it ? In a hurry for some reason ? Everything is fine. Sorry for the noise. Stefan -- 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: ftdi_sio: add CBUS mode for FT232R devices
On Sun, Jun 21, 2015 at 12:12 AM, Stefan Agner ste...@agner.ch wrote: Add interface to allow CBUS access. The functions set_bitmode and read_pins use control transfers only hence should not interfere with the serial operation mode. Signed-off-by: Stefan Agner ste...@agner.ch Interesting. Waiting for Johan's review on both patches. Need his or Greg's ACK on patch 1 if I should merge through the GPIO tree. Yours, Linus Walleij -- 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: ftdi_sio: add CBUS mode for FT232R devices
On Tue, Jun 30, 2015 at 08:46:51AM +0200, Linus Walleij wrote: On Sun, Jun 21, 2015 at 12:12 AM, Stefan Agner ste...@agner.ch wrote: Add interface to allow CBUS access. The functions set_bitmode and read_pins use control transfers only hence should not interfere with the serial operation mode. Signed-off-by: Stefan Agner ste...@agner.ch Interesting. Waiting for Johan's review on both patches. See the discussion in the cover letter thread. https://lkml.org/lkml/2015/6/20/205 Johan -- 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] phy: phy-mxs-usb: suspend to RAM causes NULL pointer dereference
On Tue, Jun 30, 2015 at 07:30:35AM +0200, Stefan Wahren wrote: Am 15.06.2015 um 06:37 schrieb Stefan Wahren: Triggering suspend to RAM via sysfs on a i.MX28 causes a NULL pointer dereference. This patch avoids the oops in mxs_phy_get_vbus_status() by aborting since there is no syscon available. Signed-off-by: Stefan Wahren stefan.wah...@i2se.com Fixes: efdbd3a5d6e (usb: phy: mxs: do not set PWD.RXPWD1PT1 for low speed connection) CC: sta...@vger.kernel.org # 4.0 Acked-by: Peter Chen peter.c...@freescale.com Just a gentle ping it's in my queue, but -rc1 wasn't tagged yet, was it ? In a hurry for some reason ? -- balbi signature.asc Description: Digital signature
Re: [Bug 100631] Usb device not functioning in initramfs luks disk unlock
Op 29-06-15 om 19:01 schreef bugzilla-dae...@bugzilla.kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=100631 --- Comment #1 from Greg Kroah-Hartman g...@kroah.com --- On Mon, Jun 29, 2015 at 09:53:04AM +, bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=100631 Bug ID: 100631 Summary: Usb device not functioning in initramfs luks disk unlock Please send to the linux-usb@vger.kernel.org mailing list. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] usb: dwc3: keystone: convert dev_dbg() to dev_err()
On Wed, Jul 01, 2015 at 12:12:05AM +0300, Sergei Shtylyov wrote:
On 07/01/2015 12:10 AM, Felipe Balbi wrote:
that's an error condition, not a debugging message.
Let's promote it appropriately.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-keystone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-keystone.c
b/drivers/usb/dwc3/dwc3-keystone.c
index fe3b9335a74e..c1ca2a0a56ef 100644
--- a/drivers/usb/dwc3/dwc3-keystone.c
+++ b/drivers/usb/dwc3/dwc3-keystone.c
@@ -115,7 +115,7 @@ static int kdwc3_probe(struct platform_device *pdev)
error = clk_prepare_enable(kdwc-clk);
if (error 0) {
- dev_dbg(kdwc-dev, unable to enable usb clock, err %d\n,
+ dev_err(kdwc-dev, unable to enable usb clock, err %d\n,
Perhaps time to s/err/error/?
what do you mean ? There's a dev_error now ? Can't seem to find it with
grep.
I meant err in the message. :-)
oh, haha, I was completely blind to that. I'll fix it in my branch
(testing/next) Thanks.
--
balbi
signature.asc
Description: Digital signature
[RFC PATCH 0/1] RFC - Implement a usbredir kernel module
The following patch proposes a new kernel module to provide an alternate protocol for transporting USB devices over a TCP/IP connection. This flows from a few conversations on the Spice devel mailing list.[1][2] I am relying heavily on the opinion of Hans de Goede, who believes that the usbredir protocol is superior to that used by the existing usbip kernel module[3]. The basic approach in this module is the same as usbip (virtual hcd driver) but it attempts to support a configurable number of devices and hubs, rather than just one hub and the limit of 8 devices. This version of the code should be sufficient to review my general approach, but it is known to be incomplete. I have successfully mounted and operated a thumb drive across the interface. Hopefully it is enough to warrant advice and comments; feedback is greatly appreciated. Anyone wishing to test this will also need a related set of usbredir patches, recently sent to the spice-devel mailing list.[4] Roughly half of the code (all of the code that fails checkpatch grin) was copied, essentially unchanged, from the usbredir project. I felt that diffability was more important than checkpatch; I stand ready to be corrected. After review, I plan to build a fairly extensive set of unit tests (see the new usbredirtestserver in [3]), and would hope to submit a complete module later in the summer. Cheers, Jeremy [1] http://lists.freedesktop.org/archives/spice-devel/2014-August/017145.html [2] http://lists.freedesktop.org/archives/spice-devel/2015-April/019451.html [3] http://lists.freedesktop.org/archives/spice-devel/2014-August/017174.html [4] http://lists.freedesktop.org/archives/spice-devel/2015-June/020595.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] Add a usbredir kernel module to remotely connect USB devices over IP.
On Tue, Jun 30, 2015 at 04:44:10PM -0500, Jeremy White wrote: This module uses the usbredir protocol and user space tools, which are used by the SPICE project. Signed-off-by: Jeremy White jwh...@codeweavers.com --- MAINTAINERS |6 + drivers/usb/Kconfig |2 + drivers/usb/Makefile|1 + drivers/usb/usbredir/Kconfig| 25 + drivers/usb/usbredir/Makefile |4 + drivers/usb/usbredir/README | 20 + drivers/usb/usbredir/TODO | 12 + drivers/usb/usbredir/device.c | 327 + drivers/usb/usbredir/hub.c | 489 drivers/usb/usbredir/main.c | 100 ++ drivers/usb/usbredir/redir.c| 535 drivers/usb/usbredir/rx.c | 40 + drivers/usb/usbredir/strtok_r.c | 69 + drivers/usb/usbredir/strtok_r.h | 26 + drivers/usb/usbredir/sysfs.c| 145 +++ drivers/usb/usbredir/tx.c | 151 +++ drivers/usb/usbredir/urb.c | 266 drivers/usb/usbredir/usbredir.h | 225 drivers/usb/usbredir/usbredirfilter.c | 294 + drivers/usb/usbredir/usbredirfilter.h | 144 +++ drivers/usb/usbredir/usbredirparser.c | 1795 +++ drivers/usb/usbredir/usbredirparser.h | 386 ++ drivers/usb/usbredir/usbredirproto-compat.h | 88 ++ drivers/usb/usbredir/usbredirproto.h| 309 + 24 files changed, 5459 insertions(+) create mode 100644 drivers/usb/usbredir/Kconfig create mode 100644 drivers/usb/usbredir/Makefile create mode 100644 drivers/usb/usbredir/README create mode 100644 drivers/usb/usbredir/TODO create mode 100644 drivers/usb/usbredir/device.c create mode 100644 drivers/usb/usbredir/hub.c create mode 100644 drivers/usb/usbredir/main.c create mode 100644 drivers/usb/usbredir/redir.c create mode 100644 drivers/usb/usbredir/rx.c create mode 100644 drivers/usb/usbredir/strtok_r.c create mode 100644 drivers/usb/usbredir/strtok_r.h create mode 100644 drivers/usb/usbredir/sysfs.c create mode 100644 drivers/usb/usbredir/tx.c create mode 100644 drivers/usb/usbredir/urb.c create mode 100644 drivers/usb/usbredir/usbredir.h create mode 100644 drivers/usb/usbredir/usbredirfilter.c create mode 100644 drivers/usb/usbredir/usbredirfilter.h create mode 100644 drivers/usb/usbredir/usbredirparser.c create mode 100644 drivers/usb/usbredir/usbredirparser.h create mode 100644 drivers/usb/usbredir/usbredirproto-compat.h create mode 100644 drivers/usb/usbredir/usbredirproto.h It's pointless to post a patch that you know has problems with it (i.e. it's not even in proper kernel coding style), as it will never be reviewed or even looked at. Please do the most basic of polite things and fix this up before posting things. And really, all in one patch? That too is pretty hard to review... 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 3/7] usb: dwc3: keystone: convert dev_dbg() to dev_err()
On 07/01/2015 12:10 AM, Felipe Balbi wrote:
that's an error condition, not a debugging message.
Let's promote it appropriately.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-keystone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-keystone.c b/drivers/usb/dwc3/dwc3-keystone.c
index fe3b9335a74e..c1ca2a0a56ef 100644
--- a/drivers/usb/dwc3/dwc3-keystone.c
+++ b/drivers/usb/dwc3/dwc3-keystone.c
@@ -115,7 +115,7 @@ static int kdwc3_probe(struct platform_device *pdev)
error = clk_prepare_enable(kdwc-clk);
if (error 0) {
- dev_dbg(kdwc-dev, unable to enable usb clock, err %d\n,
+ dev_err(kdwc-dev, unable to enable usb clock, err %d\n,
Perhaps time to s/err/error/?
what do you mean ? There's a dev_error now ? Can't seem to find it with
grep.
I meant err in the message. :-)
WBR, Sergei
--
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 7/7] usb: dwc3: drop CONFIG_USB_DWC3_DEBUG
On Tue, Jun 30, 2015 at 10:23:16PM +0300, Sergei Shtylyov wrote: Hello. On 06/30/2015 08:56 PM, Felipe Balbi wrote: now that we have no users of dev_dbg() in dwc3, we can't safely remove CONFIG_USB_DWC3_DEBUG. s/can't/can/. heh, thanks :-) I'll fix in branch only. -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/7] usb: dwc3: keystone: convert dev_dbg() to dev_err()
On Tue, Jun 30, 2015 at 10:21:40PM +0300, Sergei Shtylyov wrote:
Hello.
On 06/30/2015 08:56 PM, Felipe Balbi wrote:
that's an error condition, not a debugging message.
Let's promote it appropriately.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-keystone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-keystone.c
b/drivers/usb/dwc3/dwc3-keystone.c
index fe3b9335a74e..c1ca2a0a56ef 100644
--- a/drivers/usb/dwc3/dwc3-keystone.c
+++ b/drivers/usb/dwc3/dwc3-keystone.c
@@ -115,7 +115,7 @@ static int kdwc3_probe(struct platform_device *pdev)
error = clk_prepare_enable(kdwc-clk);
if (error 0) {
-dev_dbg(kdwc-dev, unable to enable usb clock, err %d\n,
+dev_err(kdwc-dev, unable to enable usb clock, err %d\n,
Perhaps time to s/err/error/?
what do you mean ? There's a dev_error now ? Can't seem to find it with
grep.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 5/7] usb: dwc3: qcom: switch dev_dbg() to dev_info()
On Tue, Jun 30, 2015 at 12:56:48PM -0500, Felipe Balbi wrote: those two messages are informing that the clock doesn't exist; that, however, is a valid situation and driver continues just fine by ignoring the error. Reviewed-by: Andy Gross agr...@codeaurora.org -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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
