RE: [PATCH v5 0/3] usb: udc: Unify dp control
On Thu, Jan 29, 2015 at 12:27:23PM +0800, Peter Chen wrote: Hi Felipe, Hi Felipe, I see you tree is closed, but below three patches are not in your tree, will you queue them now or at next rc? I have some other patches based on them, so I would like to know your ideas, thanks. It's up to Felipe again, but I'd say include the patches that you wrote on top of these in the same patchset, because adding an api without users makes it more difficult to validate wrt its intended use cases and it also makes potential bugs that are introduced in the api patches sit quietly in the tree until you add users, at which point it's probable that these apis will need fixing anyway. Ok, it seems most of you agree these two APIs, I will create two patch sets, one for vbus, and another for function driver to deactivations count, I will add use cases for both of patch sets. Peter -- 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: intensive IO on usb-storage device causing system lock
Hello to everybody reading this list, Hello alan. First of all - thank you for your help, attention and time in helping me troubleshoot this problem. I am 99% certain the device generating the problem is Bus 001 Device 010: ID 1e68:0022 TrekStor GmbH Co. KG I don't think the problem is on the hardware behaviour. I am recompiling the kernel now with some more debugging hints - sorry I didn't do this before. To trigger the problem it takes LOTS of IO, so I will be back in some days unfortunately. Thank you for the usbmon hint - I think I'll try this if we can't understand what's happening from the tracing data. I say this because I think that usbmon will generate LOT of data - literally GB of it, and itwould become problematic to handle / share it the right way. thank you very much again, 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: [PATCH v5 3/3] usb: udc: add usb_udc_activation_handler
On Tue, Feb 03, 2015 at 12:04:08PM +0200, Alexander Shishkin wrote:
Peter Chen peter.c...@freescale.com writes:
Currently, connect gadget is unconditional after binding,
but some function drivers may want to connect gadget on the fly.
With this API, the function driver can disconnect gadget during
the initialization, and connect gadget when it wants.
During this API, the deactivation count will be update, and it
will try to connect or disconnect gadget. It can be used to
enable functions for gadget when necessary.
Signed-off-by: Peter Chen peter.c...@freescale.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/gadget/udc/udc-core.c | 35 ++-
include/linux/usb/gadget.h| 5 +
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 9396a86..a757334 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -37,6 +37,7 @@
* @list - for use by the udc class driver
* @vbus - for udcs who care about vbus status, this value is real vbus
status;
* for udcs who do not care about vbus status, this value is always true
+ * @deactivations - the deactivation count to connect or disconnect gadget
*
* This represents the internal data structure which is used by the
UDC-class
* to hold information about udc driver and gadget together.
@@ -47,6 +48,7 @@ struct usb_udc {
struct device dev;
struct list_headlist;
boolvbus;
+ int deactivations;
};
static struct class *udc_class;
@@ -168,13 +170,44 @@ EXPORT_SYMBOL_GPL(usb_gadget_set_state);
static void usb_udc_connect_control(struct usb_udc *udc)
{
- if (udc-vbus)
+ if (udc-vbus !udc-deactivations)
usb_gadget_connect(udc-gadget);
else
usb_gadget_disconnect(udc-gadget);
}
/**
+ * usb_udc_activation_handler - updates udc's deactivation count and
+ * try to connect or disconnect
+ *
+ * @gadget: The gadget which the function is at
+ * @active: the function needs to be active or not
+ *
+ * The composite core or function driver calls it when it
+ * wants to activate or deactivate function.
+ */
+void usb_udc_activation_handler(struct usb_gadget *gadget, bool active)
+{
+ struct usb_udc *udc = usb_gadget_find_udc(gadget);
+
if (!udc)
return;
can make this function slightly easier on the eyes.
Will change
+ mutex_lock(udc_lock);
+ if (udc) {
+ if (active) {
+ if (udc-deactivations == 0) {
+ WARN_ON(1);
+ return;
This returns with the udc_lock locked.
oops, will change
Also, you probably want WARN_ON_ONCE() like so:
if (WARN_ON_ONCE(udc-deactivations)) ...
Will change
Also, I don't think you want udc_lock here at all, it looks like its (at
least intended) use is to serialize accesses to udc_list. You could use
an atomic if you want to protect against concurrent (de-)activations,
but then you would still need to synchronize
usb_gadget_connect()/usb_gadget_disconnect() that result from these
activations. I assume that normally these will serialize on gadget
driver's spinlock in pullup(), so it should be all right.
I would like udc-core can make sure deactivations count change
and usb_gadget_connect/usb_gadget_disconnect calling be serial.
--
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
[PATCH 1/2] usb: chipidea: add a flag for turn on vbus early for host
From: Li Jun b47...@freescale.com
Some usb PHYs need power supply from vbus to make it work, eg mxs-phy, if
there is no vbus, USB PHY will not in correct state when the controller starts
to work, for host, this requires vbus should be turned on before setting port
power(PP) of ehci, to work with this kind of USB PHY design, this patch adds
a flag CI_HDRC_TURN_VBUS_EARLY_ON, can be checked by host driver to turn on
vbus while start host.
Signed-off-by: Li Jun jun...@freescale.com
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/ci_hdrc_imx.c | 12
include/linux/usb/chipidea.h | 1 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index f7f9fd4..389f0e0 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -32,19 +32,23 @@ static const struct ci_hdrc_imx_platform_flag
imx27_usb_data = {
};
static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
- .flags = CI_HDRC_IMX28_WRITE_FIX,
+ .flags = CI_HDRC_IMX28_WRITE_FIX |
+ CI_HDRC_TURN_VBUS_EARLY_ON,
};
static const struct ci_hdrc_imx_platform_flag imx6q_usb_data = {
- .flags = CI_HDRC_SUPPORTS_RUNTIME_PM,
+ .flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
+ CI_HDRC_TURN_VBUS_EARLY_ON,
};
static const struct ci_hdrc_imx_platform_flag imx6sl_usb_data = {
- .flags = CI_HDRC_SUPPORTS_RUNTIME_PM,
+ .flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
+ CI_HDRC_TURN_VBUS_EARLY_ON,
};
static const struct ci_hdrc_imx_platform_flag imx6sx_usb_data = {
- .flags = CI_HDRC_SUPPORTS_RUNTIME_PM,
+ .flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
+ CI_HDRC_TURN_VBUS_EARLY_ON,
};
static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 39ba00f..ab94f78 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -28,6 +28,7 @@ struct ci_hdrc_platform_data {
#define CI_HDRC_DUAL_ROLE_NOT_OTG BIT(4)
#define CI_HDRC_IMX28_WRITE_FIXBIT(5)
#define CI_HDRC_FORCE_FULLSPEEDBIT(6)
+#define CI_HDRC_TURN_VBUS_EARLY_ON BIT(7)
enum usb_dr_modedr_mode;
#define CI_HDRC_CONTROLLER_RESET_EVENT 0
#define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: chipidea: host: turn on vbus before add hcd if early vbus on is required
From: Li Jun b47...@freescale.com
If CI_HDRC_TURN_VBUS_EARLY_ON is set, turn on vbus before adding hcd, so it
will not set reg_vbus of ehci_ci_priv, then vbus will not be handled by ehci
core.
Signed-off-by: Li Jun jun...@freescale.com
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/host.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index feb9f07..21fe1a3 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -44,11 +44,10 @@ static int ehci_ci_portpower(struct usb_hcd *hcd, int
portnum, bool enable)
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
struct ehci_ci_priv *priv = (struct ehci_ci_priv *)ehci-priv;
struct device *dev = hcd-self.controller;
- struct ci_hdrc *ci = dev_get_drvdata(dev);
int ret = 0;
int port = HCS_N_PORTS(ehci-hcs_params);
- if (priv-reg_vbus !ci_otg_is_fsm_mode(ci)) {
+ if (priv-reg_vbus) {
if (port 1) {
dev_warn(dev,
Not support multi-port regulator control\n);
@@ -114,12 +113,23 @@ static int host_start(struct ci_hdrc *ci)
priv = (struct ehci_ci_priv *)ehci-priv;
priv-reg_vbus = NULL;
- if (ci-platdata-reg_vbus)
- priv-reg_vbus = ci-platdata-reg_vbus;
+ if (ci-platdata-reg_vbus !ci_otg_is_fsm_mode(ci)) {
+ if (ci-platdata-flags CI_HDRC_TURN_VBUS_EARLY_ON) {
+ ret = regulator_enable(ci-platdata-reg_vbus);
+ if (ret) {
+ dev_err(ci-dev,
+ Failed to enable vbus regulator, ret=%d\n,
+ ret);
+ goto put_hcd;
+ }
+ } else {
+ priv-reg_vbus = ci-platdata-reg_vbus;
+ }
+ }
ret = usb_add_hcd(hcd, 0, 0);
if (ret) {
- goto put_hcd;
+ goto disable_reg;
} else {
struct usb_otg *otg = ci-otg;
@@ -139,6 +149,10 @@ static int host_start(struct ci_hdrc *ci)
return ret;
+disable_reg:
+ if (ci-platdata-reg_vbus !ci_otg_is_fsm_mode(ci)
+ (ci-platdata-flags CI_HDRC_TURN_VBUS_EARLY_ON))
+ regulator_disable(ci-platdata-reg_vbus);
put_hcd:
usb_put_hcd(hcd);
@@ -152,6 +166,9 @@ static void host_stop(struct ci_hdrc *ci)
if (hcd) {
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
+ if (ci-platdata-reg_vbus !ci_otg_is_fsm_mode(ci)
+ (ci-platdata-flags CI_HDRC_TURN_VBUS_EARLY_ON))
+ regulator_disable(ci-platdata-reg_vbus);
}
}
--
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: net2280 driver and gadgetfs?
On Tue, 3 Feb 2015, Mario Schuknecht wrote:
I used gadgetfs with PLX3380 controler. I had the problem that was
reported here:
http://thread.gmane.org/gmane.linux.usb.general/116872/focus=117488
Perphaps this is also your problem. The commit that caused the error
is probably this:
commit 7f7f25e82d54870df24d415a7007fbd327da027b
Author: Al Viro v...@zeniv.linux.org.uk
Date: Tue Feb 11 17:49:24 2014 -0500
replace checking for -read/-aio_read presence with check in -f_mode
Since we are about to introduce new methods (read_iter/write_iter), the
tests in a bunch of places would have to grow inconveniently. Check
once (at open() time) and store results in -f_mode as FMODE_CAN_READ
and FMODE_CAN_WRITE resp. It might end up being a temporary measure -
once everything switches from -aio_{read,write} to -{read,write}_iter
it might make sense to return to open-coded checks. We'll see...
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
If a driver register a read function, it is remembered in a flag in
the open function.
--- a/fs/open.c
+++ b/fs/open.c
@@ -725,6 +725,10 @@ static int do_dentry_open(struct file *f,
}
if ((f-f_mode (FMODE_READ | FMODE_WRITE)) == FMODE_READ)
i_readcount_inc(inode);
+ if ((f-f_mode FMODE_READ) likely(f-f_op-read ||
f-f_op-aio_read))
+ f-f_mode |= FMODE_CAN_READ;
+ if ((f-f_mode FMODE_WRITE) likely(f-f_op-write ||
f-f_op-aio_write))
+ f-f_mode |= FMODE_CAN_WRITE;
And if the file is read this flag is checked.
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -396,7 +396,7 @@ ssize_t vfs_read(struct file *file, char __user
*buf, size_t count, loff_t *pos)
if (!(file-f_mode FMODE_READ))
return -EBADF;
- if (!file-f_op-read !file-f_op-aio_read)
+ if (!(file-f_mode FMODE_CAN_READ))
I have fixed the problem for myself. Setting FMODE_CAN_READ flag after
change of file-pointer.
diff --git a/drivers/usb/gadget/legacy/inode.c
b/drivers/usb/gadget/legacy/inode.c
index e96077b..1b56bee 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -857,6 +857,7 @@ ep_config (struct file *fd, const char __user
*buf, size_t len, loff_t *ptr)
}
if (value == 0) {
fd-f_op = ep_io_operations;
+ fd-f_mode |= FMODE_CAN_READ;
value = length;
}
gone:
@@ -1926,6 +1927,7 @@ dev_config (struct file *fd, const char __user
*buf, size_t len, loff_t *ptr)
* kick in after the ep0 descriptor is closed.
*/
fd-f_op = ep0_io_operations;
+ fd-f_mode |= FMODE_CAN_READ;
value = len;
}
return value;
--
It seems that there is no maintainer for the gadgetfs. It is located
under the folder legacy.
Therefore I use the functionfs now, which has a similar functionality.
I hope I could help you.
Mario
You should submit a patch with your changes so that they will be
available to everybody.
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 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls
On Tuesday 03 February 2015 00:15:19 Felipe Balbi wrote: f_phonet's -set_alt() method will call usb_ep_disable() potentially on an endpoint which is already disabled. That's something the gadget/function driver must guarantee that it's always balanced. In order to balance the calls, just make sure the endpoint was enabled before by means of checking the validity of driver_data. Reported-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com --- Your patches cause that kernel does not print any error message to n900 screen anymore and reboot device in 10 seconds. I did not loaded any external modules. In qemu I see this crash in early boot: [0.500549] Unable to handle kernel NULL pointer dereference at virtual address [0.501068] pgd = c0004000 [0.501281] [] *pgd= [0.501800] Internal error: Oops: 8005 [#1] PREEMPT ARM [0.502197] Modules linked in: [0.502593] CPU: 0 PID: 1 Comm: swapper Not tainted 3.19.0-rc5+ #300 [0.502990] Hardware name: Nokia RX-51 board [0.503295] task: cf8a8000 ti: cf8ac000 task.ti: cf8ac000 [0.503692] PC is at 0x0 [0.503906] LR is at omap2430_runtime_resume+0x30/0x68 [0.504333] pc : []lr : [c02c910c]psr: a113 [0.504333] sp : cf8adda0 ip : 0001 fp : c0059824 [0.505004] r10: cf8adde8 r9 : cf9b5884 r8 : cf9b58cc [0.505340] r7 : 0004 r6 : cf93ee10 r5 : c068944c r4 : cf83a010 [0.505767] r3 : r2 : r1 : 0414 r0 : fa0ab000 [0.506195] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [0.506683] Control: 10c53c7d Table: 80004059 DAC: 0015 [0.507049] Process swapper (pid: 1, stack limit = 0xcf8ac238) [0.507476] Stack: (0xcf8adda0 to 0xcf8ae000) [0.507812] dda0: c02c90dc c0021ff4 cf9b5810 c0267de4 c0269680 cf9b5810 [0.508331] ddc0: c0269740 cf9b5810 cf9b5810 c026ac44 c0428350 cfa29410 [0.508819] dde0: cfb36800 c0428350 cfa29410 cfa2a540 6113 cfa2a500 cfa29410 [0.509307] de00: c063e9f8 006c c05fe9f4 c05bc6d4 c026b114 cfa2c100 cfa29410 [0.509826] de20: cfa2a500 c026b174 cf83a010 c02c1698 cfa29410 006c fa0ab000 ffed [0.510314] de40: cfa29410 c063e9f8 c063e9f8 c060af98 c05fe9f4 c05bc6d4 c0263d78 [0.510833] de60: cfa29410 c02624ec cfa29410 c063e9f8 c063e9f8 [0.511322] de80: c0262718 cfa29410 cfa29444 c0262790 c063e9f8 cf8adea8 [0.511810] dea0: c0262730 c0261070 cf88cb8c cfa2c230 c063e9f8 c063e9f8 cfb27a80 c0638848 [0.512298] dec0: c0261e20 c04281ec c04281ed c063e9f8 cfb3b200 [0.512786] dee0: c060af98 c02630c8 c0263cd8 c05e390c cfb3b200 c0008798 c05bc6d4 c004aa44 [0.513336] df00: c058c09c cfcb6e13 c0546eb9 a113 c058c09c 0006 0065 [0.513854] df20: 0006 c004aae8 0065 0006 0006 c05bc6d4 cfcb6e03 cfcb6e12 [0.514373] df40: 0006 c05f1fb8 0006 c05f1fbc c05f1f9c c064d2c0 0065 [0.514862] df60: c05fe9f4 c05bccfc 0006 0006 c05bc6d4 c0626858 c05fe5c0 c05fe5c0 [0.515350] df80: c05bcd94 cf8ac000 [0.515869] dfa0: c03e1094 c03e109c c000dc78 [0.516387] dfc0: [0.516906] dfe0: 0013 [0.517791] [c02c910c] (omap2430_runtime_resume) from [c0267de4] (pm_generic_runtime_resume+0x2c/0x40) [0.518432] [c0267de4] (pm_generic_runtime_resume) from [c0269680] (__rpm_callback+0x8c/0xdc) [0.518981] [c0269680] (__rpm_callback) from [c0269740] (rpm_callback+0x70/0x88) [0.519470] [c0269740] (rpm_callback) from [c026ac44] (rpm_resume+0x514/0x704) [0.519927] [c026ac44] (rpm_resume) from [c026b114] (__pm_runtime_resume+0x4c/0x90) [0.520446] [c026b114] (__pm_runtime_resume) from [c026b174] (pm_runtime_irq_safe+0x1c/0x74) [0.520996] [c026b174] (pm_runtime_irq_safe) from [c02c1698] (musb_init_controller+0x50/0x60c) [0.521545] [c02c1698] (musb_init_controller) from [c0263d78] (platform_drv_probe+0x48/0x90) [0.522094] [c0263d78] (platform_drv_probe) from [c02624ec] (really_probe+0xac/0x1e0) [0.522583] [c02624ec] (really_probe) from [c0262718] (driver_probe_device+0x30/0x48) [0.523101] [c0262718] (driver_probe_device) from [c0262790] (__driver_attach+0x60/0x84) [0.523590] [c0262790] (__driver_attach) from [c0261070] (bus_for_each_dev+0x50/0x84) [0.524078] [c0261070] (bus_for_each_dev) from [c0261e20] (bus_add_driver+0xac/0x1bc) [0.524566] [c0261e20] (bus_add_driver) from [c02630c8] (driver_register+0x9c/0xe0) [0.525054] [c02630c8] (driver_register) from [c0008798] (do_one_initcall+0x100/0x1b0) [
RE: [PATCH v1] ehci-pci: disable for Intel MID platforms
On Tue, 3 Feb 2015, Peter Chen wrote: How i386 platform chooses which driver is suitable for device? The ehci_pci_init may overwrite what ci_hdrc_host_init does if it runs later? There's nothing special about the i386 platform. _All_ platforms that support PCI use the same matching code to select drivers. (This is true for other buses too, not just for PCI. For example, all platforms use the same matching code for the USB bus.) The device core iterates through all the drivers that are registered on the PCI bus. When it finds a driver that matches the device ID, it calls the driver's probe routine. If the probe routine returns 0 then the core stops iterating; otherwise it keeps iterating through the list of drivers. So in this case it's more or less random. Whichever driver gets registered on the PCI bus first is the one that will be probed first. But with Andy's patch, the ehci-pci driver won't interfere with the ci_hdrc_host driver, even if ehci-pci gets probed first. In fact, ehci_pci_init() will never be called, because ehci_pci_probe() will return - ENODEV immediately. It is module_init(ehci_pci_init) in ehci-pci.c, so ehci_pci_init will always be called. Oops, yes, you're right. I was thinking of ehci_pci_setup, sorry. ehci_pci_init will indeed get called. But it won't overwrite anything in ci_hdrc_host_init. The only thing it touches is its own private ehci_pci_hc_driver structure. 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_V4 1/3] dt: usb: jz4740: Add DT binding document for OHCI
On 02/03/2015 11:53 AM, Zubair Lutfullah Kakakhel wrote: On 03/02/15 10:32, Lars-Peter Clausen wrote: On 02/03/2015 11:17 AM, Zubair Lutfullah Kakakhel wrote: [...] V4 Changes Removed clock binding because of pending work in clock tree. Will add binding later. Rather than introduce a bad binding now and change later. But this patch is introducing a bad binding. The part needs the clock to work. The binding you are specifying right now says that it works fine without any clocks. Facing a chicken and egg problem with these patches here.. When the new clock driver gets in we can add the correct clock binding and replace devm_clk_get(pdev-dev, uhc); with devm_clk_get(pdev-dev, NULL); Specifying the current binding got NAKed by Arnd who mentioned that clock names shouldn't be needed as required properties. And even if needed, then it shouldn't be uhc and more close to what other ohci drivers have. It's not a chicken and egg problem. The order is very clear, first convert the clock driver to the CCF, then update the driver to pass NULL instead of uhc, then add the devicetree bindings. - Lars -- 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: Kernel Ooops upon USB disconnect of a Western Digital My Passport 1TB drive
On Mon, Feb 2, 2015 at 7:27 PM, Alan Stern st...@rowland.harvard.edu wrote:
Had you made any changes to the runtime suspend settings?
blk_post_runtime_resume wouldn't be called unless the drive had gone
into runtime suspend. And even then, it's not likely to be called
after you unplug the USB cable.
Alan Stern
I have enabled SCSI ATA Bus power management with this udev rule:
ACTION==add, SUBSYSTEM==scsi_host, KERNEL==host*,
ATTR{link_power_management_policy}=min_power
( And generally almost all of actions herein:
https://wiki.archlinux.org/index.php/Power_saving#Laptop_Mode )
Here's another with dynamic debugging on (and some of the stack trace):
[ 1565.610481] usb usb2: usb wakeup-resume
[ 1565.613019] usb usb2: usb auto-resume
[ 1565.615599] hub 2-0:1.0: hub_resume
[ 1565.617876] usb usb2-port1: status 0507 change
[ 1565.620125] hub 2-0:1.0: state 7 ports 3 chg evt
[ 1565.623471] hub 2-0:1.0: state 7 ports 3 chg evt
[ 1565.650219] hub 2-0:1.0: state 7 ports 3 chg evt 0002
[ 1565.663520] usb 2-1: usb wakeup-resume
[ 1565.665518] usb 2-1: finish resume
[ 1565.667684] hub 2-1:1.0: hub_resume
[ 1565.669812] usb 2-1-port2: status 0101 change 0001
[ 1565.773645] usb usb2-port1: resume, status 0
[ 1565.776031] hub 2-1:1.0: state 7 ports 8 chg 0004 evt
[ 1565.778664] usb 2-1-port2: status 0101, change , 12 Mb/s
[ 1565.847291] usb 2-1.2: new high-speed USB device number 3 using ehci-pci
[ 1565.860480] usb 2-1-port2: not reset yet, waiting 10ms
[ 1565.945202] usb 2-1.2: default language 0x0409
[ 1565.947882] usb 2-1.2: udev 3, busnum 2, minor = 130
[ 1565.950384] usb 2-1.2: usb_probe_device
[ 1565.952704] usb 2-1.2: configuration #1 chosen from 1 choice
[ 1565.955145] usb 2-1.2: adding 2-1.2:1.0 (config #1, interface 0)
[ 1565.957630] hub 2-1:1.0: state 7 ports 8 chg evt 0004
[ 1566.005124] usb-storage 2-1.2:1.0: usb_probe_interface
[ 1566.006655] usb-storage 2-1.2:1.0: usb_probe_interface - got id
[ 1566.008169] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[ 1566.010155] scsi host6: usb-storage 2-1.2:1.0
[ 1566.012149] usbcore: registered new interface driver usb-storage
[ 1566.016061] usbcore: registered new interface driver uas
[ 1567.015852] scsi 6:0:0:0: Direct-Access WD My Passport
0748 1016 PQ: 0 ANSI: 6
[ 1567.018966] scsi 6:0:0:1: Enclosure WD SES Device
1016 PQ: 0 ANSI: 6
[ 1567.027072] scsi 6:0:0:1: scsi_runtime_idle
[ 1567.029695] sd 6:0:0:0: [sdb] Spinning up disk...
[ 1567.032764] scsi 6:0:0:1: scsi_runtime_suspend
[ 1568.031907] .ready
[ 1569.060225] sd 6:0:0:0: [sdb] 1953458176 512-byte logical blocks:
(1.00 TB/931 GiB)
[ 1569.063857] sd 6:0:0:0: [sdb] Write Protect is off
[ 1569.065613] ses 6:0:0:1: Attached Enclosure device
[ 1569.068492] sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
[ 1569.071598] sd 6:0:0:0: [sdb] No Caching mode page found
[ 1569.073628] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 1569.087891] sdb: sdb1
[ 1569.093382] sd 6:0:0:0: [sdb] Attached SCSI disk
[ 1615.830142] hub 2-1:1.0: state 7 ports 8 chg evt 0004
[ 1615.833066] usb 2-1-port2: status 0100, change 0001, 12 Mb/s
[ 1615.835764] usb 2-1.2: USB disconnect, device number 3
[ 1615.838471] usb 2-1.2: unregistering device
[ 1615.841199] usb 2-1.2: unregistering interface 2-1.2:1.0
[ 1615.844996] scsi target6:0:0: scsi_runtime_idle
[ 1615.848746] scsi target6:0:0: scsi_runtime_suspend
[ 1615.868925] scsi target6:0:0: scsi_runtime_resume
[ 1615.870975] ses 6:0:0:1: scsi_runtime_resume
[ 1615.872913] BUG: unable to handle kernel NULL pointer dereference
at 01a0
[ 1615.874896] IP: [812850d5] blk_post_runtime_resume+0x65/0x80
[ 1615.876843] PGD 0
[ 1615.878765] Oops: 0002 [#1] PREEMPT SMP
[ 1615.880734] Modules linked in: ses enclosure uas usb_storage
netconsole joydev mousedev snd_hda_codec_hdmi snd_hda_codec_conexant
snd_hda_codec_generic coretemp intel_rapl x86_pkg_temp_thermal
intel_powerclamp kvm_intel kvm arc4 crct10dif_pclmul iwldvm
crc32_pclmul iTCO_wdt iTCO_vendor_support crc32c_intel mac80211
ghash_clmulni_intel ip6t_REJECT nf_reject_ipv6 aesni_intel xt_hl
aes_x86_64 lrw gf128mul ip6t_rt psmouse iwlwifi glue_helper
ablk_helper cryptd i2c_i801 serio_raw cfg80211 nf_conntrack_ipv6
nf_defrag_ipv6 snd_hda_intel wmi thinkpad_acpi nvram thermal rfkill
ipt_REJECT nf_reject_ipv4 hwmon tpm_tis ac tpm battery
snd_hda_controller snd_hda_codec snd_hwdep evdev snd_pcm mac_hid
xt_limit e1000e snd_timer xt_tcpudp mei_me snd mei ptp soundcore
shpchp pps_core lpc_ich processor xt_addrtype nf_conntrack_ipv4
nf_defrag_ipv4 xt_conntrack at ffd8
[ 1616.064883] IP: [81091500] kthread_data+0x10/0x20
[ 1616.068189] PGD 1814067 PUD 1816067 PMD 0
[ 1616.071462] Oops: [#2] PREEMPT SMP
[ 1616.074719] Modules linked in: ses enclosure uas usb_storage
netconsole joydev mousedev snd_hda_codec_hdmi snd_hda_codec_conexant
snd_hda_codec_generic coretemp intel_rapl x86_pkg_temp_thermal
intel_powerclamp
Re: [PATCH 2/2] usb: musb: try a race-free wakeup
On 02/02/2015 11:44 PM, Bin Liu wrote: Sebastian, Hi Bin, I think I found the cause. Plugging a device behind a hub, this is related to runtime PM, so the finish_resume_work() should also be added in musb_runtime_resume(), also musb_host_resume_root_hub() should not be moved as did in your patch, this call is used to trigger the bus resume. A patch will be coming soon - tomorrow. Thank you. Regards, -Bin. Sebastian -- 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 RESEND] usb: dwc2: Fix a bug in reading the endpoint directions from reg.
Hi Roshan,
-Original Message-
From: Roshan Pius [mailto:rp...@chromium.org]
Sent: Monday, February 2, 2015 11:56 PM
To: linux-usb@vger.kernel.org
Cc: benc...@chromium.org; Kaukab, Yousaf; Roshan Pius
Subject: [PATCH RESEND] usb: dwc2: Fix a bug in reading the endpoint
directions from reg.
According to the DWC2 datasheet, the HWCFG1 register stores the configured
endpoint directions for endpoints 0-15 in bit positions 0-31.
==
Endpoint Direction (EpDir)
This 32-bit field uses two bits per endpoint to determine the endpoint
direction.
Endpoint
Bits [31:30]: Endpoint 15 direction
Bits [29:28]: Endpoint 14 direction
Bits [3:2]: Endpoint 1 direction
Bits[1:0]: Endpoint 0 direction (always BIDIR) ==
The DWC2 driver is currently interpreting the contents of the register as
directions for endpoints 1-15 which leads to an error in determining the
configured endpoint directions in the core because the first 2 bits determine
the direction of endpoint 0 and not 1.
This is based on testing/next branch in Felipe's git.
Signed-off-by: Roshan Pius rp...@chromium.org
---
drivers/usb/dwc2/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index
50ae096..706165c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3167,7 +3167,7 @@ static int s3c_hsotg_hw_cfg(struct dwc2_hsotg
*hsotg)
hsotg-eps_out[0] = hsotg-eps_in[0];
cfg = readl(hsotg-regs + GHWCFG1);
- for (i = 1; i hsotg-num_of_eps; i++, cfg = 2) {
+ for (i = 1, cfg = 2; i hsotg-num_of_eps; i++, cfg = 2) {
Nice catch! I wouldn't have found it on my hardware as GHWCFG1 is always 0.
ep_type = cfg 3;
/* Direction in or both */
if (!(ep_type 2)) {
--
2.2.0.rc0.207.ga3a616c
BR,
Yousaf
--
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 8/8] phy: add driver for TI TUSB1210 ULPI PHY
Hi David, Felipe, why would you have dwc3 mess around with the PHY's gpios ? Doesn't look very good. ..but unfortunately we can't use the bus without it :(. We depend on being able to read the vendor and product id's in the bus driver. Doesn't the ugly platform device case look less ugly than this? The platform device would in any case need to be created only for this case. We can't any more just create the phy device unconditionally for every PCI platform like it was created before, as it's clear now the PHY device can be be created from other sources. It was a risk always. But the big problem is that since the PHY on your board is ULPI PHY, it will make it really difficult to add the ULPI bus support. And like I said in my previous mail, we would really need it for the boards that expect the PHY driver to provide functions like charger detection. We don't need it only for BYT based boards. So on top of the above, since the GPIO resources are given to dwc3, I actually think that my hack is better then the platform device. So what do you guys think we should do? I can't figure out how would we make the platform device work with ulpi bus. If we think about handling this in ulpi bus driver by setting setting the gpios before attempting to access the phy, which I'm not completely against, we have couple of problems. Firstly, the gpio resources are given to the dwc3 in this case, while normally they will be given to separate device object for the phy. Secondly, these gpios were not labeled in DSDT, but apparently requesting the gpios with index will be deprecated and not acceptable any more. With the remaining platforms that have not labeled the gpios we have to bind the gpios to labels separately in the drivers. With ACPI platforms the labels are introduced in struct acpi_gpio_mapping which needs to be registered with acpi_dev_add_driver_gpios(). Check net/rfkill/rfkill-gpio.c as an example how to use it. I think those points would make this too platform specific case to be handled in the ulpi bus driver. Suggestions? I still think the correct thing to do is to handle this in the quirk in dwc3-pci.c. Cheers, -- heikki -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Ooops upon USB disconnect of a Western Digital My Passport 1TB drive
On Tue, 3 Feb 2015, Athlion wrote:
On Mon, Feb 2, 2015 at 7:27 PM, Alan Stern st...@rowland.harvard.edu wrote:
Had you made any changes to the runtime suspend settings?
blk_post_runtime_resume wouldn't be called unless the drive had gone
into runtime suspend. And even then, it's not likely to be called
after you unplug the USB cable.
Alan Stern
I have enabled SCSI ATA Bus power management with this udev rule:
ACTION==add, SUBSYSTEM==scsi_host, KERNEL==host*,
ATTR{link_power_management_policy}=min_power
That won't have any effect on SCSI over USB, as far as I know.
( And generally almost all of actions herein:
https://wiki.archlinux.org/index.php/Power_saving#Laptop_Mode )
Here's another with dynamic debugging on (and some of the stack trace):
[ 1565.610481] usb usb2: usb wakeup-resume
[ 1565.613019] usb usb2: usb auto-resume
[ 1565.615599] hub 2-0:1.0: hub_resume
[ 1565.617876] usb usb2-port1: status 0507 change
[ 1565.620125] hub 2-0:1.0: state 7 ports 3 chg evt
[ 1565.623471] hub 2-0:1.0: state 7 ports 3 chg evt
[ 1565.650219] hub 2-0:1.0: state 7 ports 3 chg evt 0002
[ 1565.663520] usb 2-1: usb wakeup-resume
[ 1565.665518] usb 2-1: finish resume
[ 1565.667684] hub 2-1:1.0: hub_resume
[ 1565.669812] usb 2-1-port2: status 0101 change 0001
[ 1565.773645] usb usb2-port1: resume, status 0
[ 1565.776031] hub 2-1:1.0: state 7 ports 8 chg 0004 evt
[ 1565.778664] usb 2-1-port2: status 0101, change , 12 Mb/s
[ 1565.847291] usb 2-1.2: new high-speed USB device number 3 using ehci-pci
[ 1565.860480] usb 2-1-port2: not reset yet, waiting 10ms
[ 1565.945202] usb 2-1.2: default language 0x0409
[ 1565.947882] usb 2-1.2: udev 3, busnum 2, minor = 130
[ 1565.950384] usb 2-1.2: usb_probe_device
[ 1565.952704] usb 2-1.2: configuration #1 chosen from 1 choice
[ 1565.955145] usb 2-1.2: adding 2-1.2:1.0 (config #1, interface 0)
[ 1565.957630] hub 2-1:1.0: state 7 ports 8 chg evt 0004
[ 1566.005124] usb-storage 2-1.2:1.0: usb_probe_interface
[ 1566.006655] usb-storage 2-1.2:1.0: usb_probe_interface - got id
[ 1566.008169] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[ 1566.010155] scsi host6: usb-storage 2-1.2:1.0
[ 1566.012149] usbcore: registered new interface driver usb-storage
[ 1566.016061] usbcore: registered new interface driver uas
[ 1567.015852] scsi 6:0:0:0: Direct-Access WD My Passport
0748 1016 PQ: 0 ANSI: 6
[ 1567.018966] scsi 6:0:0:1: Enclosure WD SES Device
1016 PQ: 0 ANSI: 6
Your device contains two Logical Units. One of them is the My Passport
disk drive, and the other is the SES Device enclosure.
[ 1567.027072] scsi 6:0:0:1: scsi_runtime_idle
[ 1567.029695] sd 6:0:0:0: [sdb] Spinning up disk...
[ 1567.032764] scsi 6:0:0:1: scsi_runtime_suspend
[ 1568.031907] .ready
[ 1569.060225] sd 6:0:0:0: [sdb] 1953458176 512-byte logical blocks:
(1.00 TB/931 GiB)
[ 1569.063857] sd 6:0:0:0: [sdb] Write Protect is off
[ 1569.065613] ses 6:0:0:1: Attached Enclosure device
[ 1569.068492] sd 6:0:0:0: [sdb] Mode Sense: 47 00 10 08
[ 1569.071598] sd 6:0:0:0: [sdb] No Caching mode page found
[ 1569.073628] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 1569.087891] sdb: sdb1
[ 1569.093382] sd 6:0:0:0: [sdb] Attached SCSI disk
[ 1615.830142] hub 2-1:1.0: state 7 ports 8 chg evt 0004
[ 1615.833066] usb 2-1-port2: status 0100, change 0001, 12 Mb/s
[ 1615.835764] usb 2-1.2: USB disconnect, device number 3
[ 1615.838471] usb 2-1.2: unregistering device
[ 1615.841199] usb 2-1.2: unregistering interface 2-1.2:1.0
[ 1615.844996] scsi target6:0:0: scsi_runtime_idle
[ 1615.848746] scsi target6:0:0: scsi_runtime_suspend
[ 1615.868925] scsi target6:0:0: scsi_runtime_resume
[ 1615.870975] ses 6:0:0:1: scsi_runtime_resume
[ 1615.872913] BUG: unable to handle kernel NULL pointer dereference
at 01a0
[ 1615.874896] IP: [812850d5] blk_post_runtime_resume+0x65/0x80
[ 1615.876843] PGD 0
[ 1615.878765] Oops: 0002 [#1] PREEMPT SMP
[ 1615.880734] Modules linked in: ses enclosure uas usb_storage
netconsole joydev mousedev snd_hda_codec_hdmi snd_hda_codec_conexant
snd_hda_codec_generic coretemp intel_rapl x86_pkg_temp_thermal
intel_powerclamp kvm_intel kvm arc4 crct10dif_pclmul iwldvm
crc32_pclmul iTCO_wdt iTCO_vendor_support crc32c_intel mac80211
ghash_clmulni_intel ip6t_REJECT nf_reject_ipv6 aesni_intel xt_hl
aes_x86_64 lrw gf128mul ip6t_rt psmouse iwlwifi glue_helper
ablk_helper cryptd i2c_i801 serio_raw cfg80211 nf_conntrack_ipv6
nf_defrag_ipv6 snd_hda_intel wmi thinkpad_acpi nvram thermal rfkill
ipt_REJECT nf_reject_ipv4 hwmon tpm_tis ac tpm battery
snd_hda_controller snd_hda_codec snd_hwdep evdev snd_pcm mac_hid
xt_limit e1000e snd_timer xt_tcpudp mei_me snd mei ptp soundcore
shpchp pps_core lpc_ich processor xt_addrtype nf_conntrack_ipv4
nf_defrag_ipv4 xt_conntrack at ffd8
[ 1616.064883] IP: [81091500]
[PATCH v4] ehci-pci: disable for Intel MID platforms (update)
This is a follow up to the previously submitted commit cefa9a31a5f0 (ehci-pci:
disable for Intel MID platforms).
It includes the following changes:
- table and function are renamed to reflect this is not only about ChipIdea
- ChipIdea PCI driver (ci_hdrc_pci.c) gets the comment about the table in
ehci-pci.c
- MIPS IDs removed from the list since it was discovered and tested on Intel
MID platforms
Reviewed-by: Alexander Shishkin alexander.shish...@linux.intel.com
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/usb/chipidea/ci_hdrc_pci.c | 3 +++
drivers/usb/host/ehci-pci.c| 16 ++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_pci.c
b/drivers/usb/chipidea/ci_hdrc_pci.c
index 241ae34..4df6694 100644
--- a/drivers/usb/chipidea/ci_hdrc_pci.c
+++ b/drivers/usb/chipidea/ci_hdrc_pci.c
@@ -111,6 +111,9 @@ static void ci_hdrc_pci_remove(struct pci_dev *pdev)
* PCI device structure
*
* Check pci.h for details
+ *
+ * Note: ehci-pci driver may try to probe the device first. You have to add an
+ * ID to the bypass_pci_id_table in ehci-pci driver to prevent this.
*/
static const struct pci_device_id ci_hdrc_pci_id_table[] = {
{
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 9652021..2a5d2fd 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -42,18 +42,22 @@ static inline bool is_intel_quark_x1000(struct pci_dev
*pdev)
pdev-device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
}
-static const struct pci_device_id ci_hdrc_pci_id_table[] = {
- { PCI_DEVICE(0x153F, 0x1004), },
- { PCI_DEVICE(0x153F, 0x1006), },
+/*
+ * This is the list of PCI IDs for the devices that have EHCI USB class and
+ * specific drivers for that. One of the example is a ChipIdea device installed
+ * on some Intel MID platforms.
+ */
+static const struct pci_device_id bypass_pci_id_table[] = {
+ /* ChipIdea on Intel MID platform */
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006), },
{}
};
-static inline bool is_ci_hdrc_pci(struct pci_dev *pdev)
+static inline bool is_bypassed_id(struct pci_dev *pdev)
{
- return !!pci_match_id(ci_hdrc_pci_id_table, pdev);
+ return !!pci_match_id(bypass_pci_id_table, pdev);
}
/*
@@ -368,7 +372,7 @@ static const struct ehci_driver_overrides pci_overrides
__initconst = {
static int ehci_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
- if (is_ci_hdrc_pci(pdev))
+ if (is_bypassed_id(pdev))
return -ENODEV;
return usb_hcd_pci_probe(pdev, 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 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls
On Tuesday 03 February 2015 16:43:45 Felipe Balbi wrote: Hi, On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 00:15:19 Felipe Balbi wrote: f_phonet's -set_alt() method will call usb_ep_disable() potentially on an endpoint which is already disabled. That's something the gadget/function driver must guarantee that it's always balanced. In order to balance the calls, just make sure the endpoint was enabled before by means of checking the validity of driver_data. Reported-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com --- Your patches cause that kernel does not print any error message to n900 screen anymore and reboot device in 10 seconds. I did not loaded any external modules. In qemu I see this crash in early boot: alright, so n900's working fine. I'll wait until you debug qemu a little more, thank you NO! It does not working, see . It break n900 totally! -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls
Hi, On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 00:15:19 Felipe Balbi wrote: f_phonet's -set_alt() method will call usb_ep_disable() potentially on an endpoint which is already disabled. That's something the gadget/function driver must guarantee that it's always balanced. In order to balance the calls, just make sure the endpoint was enabled before by means of checking the validity of driver_data. Reported-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com --- Your patches cause that kernel does not print any error message to n900 screen anymore and reboot device in 10 seconds. I did not loaded any external modules. In qemu I see this crash in early boot: alright, so n900's working fine. I'll wait until you debug qemu a little more, thank you -- balbi signature.asc Description: Digital signature
[PATCH] usb: musb: fix device hotplug behind hub
The commit 889ad3b usb: musb: try a race-free wakeup breaks device
hotplug enumeraitonn when the device is connected behind a hub while usb
autosuspend is enabled.
Adding finish_resume_work into runtime resume callback fixes the issue.
Also resume root hub is required to resume the bus from runtime suspend,
so move musb_host_resume_root_hub() back to its original location, where
handles RESUME interrupt.
Signed-off-by: Bin Liu b-...@ti.com
---
drivers/usb/musb/musb_core.c| 7 +++
drivers/usb/musb/musb_virthub.c | 1 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 5e0f284..85f7257 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -483,6 +483,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
musb-xceiv-state = OTG_STATE_A_HOST;
musb-is_active = 1;
+ musb_host_resume_root_hub(musb);
break;
case OTG_STATE_B_WAIT_ACON:
musb-xceiv-state = OTG_STATE_B_PERIPHERAL;
@@ -2362,6 +2363,12 @@ static int musb_runtime_resume(struct device *dev)
musb_restore_context(musb);
first = 0;
+ if (musb-need_finish_resume) {
+ musb-need_finish_resume = 0;
+ schedule_delayed_work(musb-finish_resume_work,
+ msecs_to_jiffies(20));
+ }
+
return 0;
}
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 66d2996..e2d2d8c 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -72,7 +72,6 @@ void musb_host_finish_resume(struct work_struct *work)
musb-xceiv-state = OTG_STATE_A_HOST;
spin_unlock_irqrestore(musb-lock, flags);
- musb_host_resume_root_hub(musb);
}
void musb_port_suspend(struct musb *musb, bool do_suspend)
--
1.8.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_V4 1/3] dt: usb: jz4740: Add DT binding document for OHCI
Hello.
On 2/3/2015 1:17 PM, Zubair Lutfullah Kakakhel wrote:
From: Paul Burton paul.bur...@imgtec.com
Add the binding documentation for the JZ4740 OHCI controller.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
Signed-off-by: Zubair Lutfullah Kakakhel zubair.kakak...@imgtec.com
[...]
diff --git a/Documentation/devicetree/bindings/usb/ingenic,jz4740-ohci.txt
b/Documentation/devicetree/bindings/usb/ingenic,jz4740-ohci.txt
new file mode 100644
index 000..29c1934
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ingenic,jz4740-ohci.txt
@@ -0,0 +1,21 @@
+Ingenic JZ4740 SoC OHCI controller binding
+
+The Ingenic JZ4740 SoC includes an OHCI compliant USB host controller
+interface for use with USB 1.1 devices.
+
+Required properties:
+ - compatible: Should be ingenic,jz4740-ohci
+ - reg: Should contain the address size of the OHCI controller registers.
+ - interrupts: Should specify the interrupt line number
+
+Example for jz4740:
+
+/ {
+ ohci: jz4780-ohci@0x134a {
The name should be usb@134a, according to the ePAPR standard.
[...]
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: intensive IO on usb-storage device causing system lock
On Tue, 3 Feb 2015, Enrico Mioso wrote: Hi guys. I finally was able to obtain some informations about what was going on - infos I retained useful. I am re-sending these, since it seems my previous message didn't get to the list - but might be I am wrong and didn't find it. This time I posted all the traces to a pstebin, so that it's easier to read the message and might be there are less problems with it in general. 1 - First trace: there where no problems http://cxg.de/_298ad9.htm 2 - Trace immediately before the crash http://cxg.de/_c43356.htm Without CONFIG_FRAME_POINTER, the stack traces are not very helpful. 3 - lspci: http://cxg.de/_4f202a.htm 4 - lsusb: http://cxg.de/_223f6c.htm Any help / hint would be very apreciated. You have two USB mass storage devices. Do you know which one is connected to the problem? You can try using usbmon to see what's going on at the USB level. See Documentation/usb/usbmon.txt for instructions. 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
OOPS: musb_am335x: __device_attach
Hi, I am facing the following issue, when running 3.19-rc6 on my beaglebone black: [9.638571] Unable to handle kernel paging request at virtual address 69646b89 [9.646309] pgd = db6dc000 [9.649168] [69646b89] *pgd= [9.652929] Internal error: Oops: 5 [#1] SMP ARM [9.657769] Modules linked in: musb_am335x(+) [9.662351] CPU: 0 PID: 220 Comm: systemd-udevd Not tainted 3.19.0-rc6-3.ga7bdd86-default #1 [9.671196] Hardware name: Generic AM33XX (Flattened Device Tree) [9.677583] task: db6af300 ti: db6d8000 task.ti: db6d8000 [9.683257] PC is at __device_attach+0x18/0x4c [9.687918] LR is at bus_for_each_drv+0x60/0x94 [9.692668] pc : [c07a68e0]lr : [c07a4920]psr: 60010013 [9.692668] sp : db6d9c70 ip : c0ed5708 fp : [9.704704] r10: r9 : r8 : c112b96c [9.710180] r7 : db183410 r6 : c07a68c8 r5 : db608a10 r4 : c0ed5708 [9.717023] r3 : 69646b6d r2 : 0da0 r1 : db608a10 r0 : c0ed5708 [9.723867] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [9.731347] Control: 10c5387d Table: 9b6dc019 DAC: 0015 [9.737371] Process systemd-udevd (pid: 220, stack limit = 0xdb6d8248) [9.744213] Stack: (0xdb6d9c70 to 0xdb6da000) [9.748781] 9c60: c07a68c8 db608a10 c07a4920 [9.757358] 9c80: db08bd70 db49b238 db608a10 db608a44 c1011b68 c07a64ac db608a18 db608a10 [9.765934] 9ca0: c1011b68 c07a599c db608a18 db608a10 c07a3a60 [9.774511] 9cc0: 60010013 dfa46780 db608a00 db608a10 dfa467cc [9.783088] 9ce0: db183410 c08b75dc dfa46780 0001 c08b7718 [9.791665] 9d00: 8000 db764640 c04f4c98 db03bdc0 22f3 db184088 c07a8560 [9.800241] 9d20: c11155d0 c0400180 db578088 dfa46780 dfa46574 db183410 [9.808819] 9d40: 0001 bf000278 c08b7b6c 0001 db57ef88 c0d2ab48 db183410 [9.817395] 9d60: db183400 bf000234 bf000234 0003 bf30 bf00 db183410 [9.825972] 9d80: fdfb c07a8578 c07a852c db183410 c112b990 c105bde0 c07a6670 [9.834549] 9da0: c07a8740 db183410 bf000234 db183410 bf000234 db183444 bf002000 [9.843125] 9dc0: c07a69a8 bf000234 c07a6914 c07a4870 db08bd5c db1734b4 [9.851703] 9de0: bf000234 db727a00 c1011b68 c07a5c78 bf000208 c04f5980 bf000234 bf000234 [9.860281] 9e00: c0f49a20 db330b80 db6d9e90 c07a7174 c0f49a20 c0f49a20 c0209c34 [9.868857] 9e20: dfe35b78 c0cd2e64 db194c80 dfe35b78 0008 dfa59000 [9.877434] 9e40: db6d9f18 c034ac1c 0007 dfe35b78 c848 c0379774 c02e0458 [9.886010] 9e60: 0002 db330b00 e083b000 bf000284 bf000284 db330b00 db6d9f54 db6d9e90 [9.894587] 9e80: db6d9f18 bf000278 c02e0494 8000 7fff c02dd32c db57d340 [9.903164] 9ea0: db57d340 e083b000 c0f455a4 bf000278 c1055360 0035 [9.911741] 9ec0: db6d9ee4 b6f50bac db6d9f5c db6d9f88 28ae 0002 81a4 [9.920317] 9ee0: 0001 [9.928894] 9f00: [9.937469] 9f20: 0007 b6f50bac 017b c021a848 db6d8000 1000 [9.946046] 9f40: 00d12058 c02e0a44 0002 db6d9f5c e083b000 13d8 e083be00 [9.954622] 9f60: e083b72f e083bba8 040c 04fc 001b [9.963200] 9f80: 001c 0014 0011 000d 00044640 [9.971776] 9fa0: c021a680 00044640 0007 b6f50bac [9.980352] 9fc0: 00044640 017b 0002 00d12058 [9.988929] 9fe0: bec55da8 bec55d98 b6f47114 b6e713b0 60010010 0007 975b1a3e 975b2a3e [9.997521] [c07a68e0] (__device_attach) from [c07a4920] (bus_for_each_drv+0x60/0x94) [ 10.006102] [c07a4920] (bus_for_each_drv) from [c07a64ac] (device_attach+0x7c/0x90) [ 10.014498] [c07a64ac] (device_attach) from [c07a599c] (bus_probe_device+0x8c/0xb0) [ 10.022895] [c07a599c] (bus_probe_device) from [c07a3a60] (device_add+0x3ac/0x568) [ 10.031209] [c07a3a60] (device_add) from [c08b75dc] (of_platform_device_create_pdata+0x7c/0xb0) [ 10.040702] [c08b75dc] (of_platform_device_create_pdata) from [c08b7718] (of_platform_bus_create+0xf4/0x3bc) [ 10.051377] [c08b7718] (of_platform_bus_create) from [c08b7b6c] (of_platform_populate+0x64/0xb4) [ 10.060965] [c08b7b6c] (of_platform_populate) from [bf30] (am335x_child_probe+0x30/0x4c [musb_am335x]) [ 10.071466] [bf30] (am335x_child_probe [musb_am335x]) from [c07a8578] (platform_drv_probe+0x4c/0xac) [ 10.081777] [c07a8578] (platform_drv_probe) from [c07a6670] (driver_probe_device+0x154/0x3ac) [ 10.091084]
Re: [PATCH RESEND] usb: dwc2: Fix a bug in reading the endpoint directions from reg.
On 02/02/2015 02:55 PM, Roshan Pius wrote:
According to the DWC2 datasheet, the HWCFG1 register stores
the configured endpoint directions for endpoints 0-15 in bit positions
0-31.
==
Endpoint Direction (EpDir)
This 32-bit field uses two bits per endpoint to determine the endpoint
direction.
Endpoint
Bits [31:30]: Endpoint 15 direction
Bits [29:28]: Endpoint 14 direction
Bits [3:2]: Endpoint 1 direction
Bits[1:0]: Endpoint 0 direction (always BIDIR)
==
The DWC2 driver is currently interpreting the contents of the register
as directions for endpoints 1-15 which leads to an error in determining
the configured endpoint directions in the core because the first 2 bits
determine the direction of endpoint 0 and not 1.
This is based on testing/next branch in Felipe's git.
Signed-off-by: Roshan Pius rp...@chromium.org
---
drivers/usb/dwc2/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 50ae096..706165c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3167,7 +3167,7 @@ static int s3c_hsotg_hw_cfg(struct dwc2_hsotg *hsotg)
hsotg-eps_out[0] = hsotg-eps_in[0];
cfg = readl(hsotg-regs + GHWCFG1);
- for (i = 1; i hsotg-num_of_eps; i++, cfg = 2) {
+ for (i = 1, cfg = 2; i hsotg-num_of_eps; i++, cfg = 2) {
ep_type = cfg 3;
/* Direction in or both */
if (!(ep_type 2)) {
Good catch on this.
Acked-by: John Youn johny...@synopsys.com
Hi Felipe,
Any chance you'll accept this into your 3.20 queue?
It affects any DWC2 core instance that has unidirectional endpoints defined.
Regards,
John
--
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/3] usb: gadget: function: phonet: balance usb_ep_disable calls
On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 16:43:45 Felipe Balbi wrote: Hi, On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 00:15:19 Felipe Balbi wrote: f_phonet's -set_alt() method will call usb_ep_disable() potentially on an endpoint which is already disabled. That's something the gadget/function driver must guarantee that it's always balanced. In order to balance the calls, just make sure the endpoint was enabled before by means of checking the validity of driver_data. Reported-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com --- Your patches cause that kernel does not print any error message to n900 screen anymore and reboot device in 10 seconds. I did not loaded any external modules. In qemu I see this crash in early boot: alright, so n900's working fine. I'll wait until you debug qemu a little more, thank you NO! It does not working, see . It break n900 totally! settle down a bit more. I don't have the HW you have and things are working fine on boards I _do_ have, there's not much more I can do to help without you doing your homework. Debug a bit more and bring more information as to what's going on, until then you're on your own. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls
On Tuesday 03 February 2015 20:51:34 Felipe Balbi wrote: On Tue, Feb 03, 2015 at 01:35:25PM -0600, Felipe Balbi wrote: On Tue, Feb 03, 2015 at 08:27:52PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote: On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 16:43:45 Felipe Balbi wrote: Hi, On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 00:15:19 Felipe Balbi wrote: f_phonet's -set_alt() method will call usb_ep_disable() potentially on an endpoint which is already disabled. That's something the gadget/function driver must guarantee that it's always balanced. In order to balance the calls, just make sure the endpoint was enabled before by means of checking the validity of driver_data. Reported-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com --- Your patches cause that kernel does not print any error message to n900 screen anymore and reboot device in 10 seconds. I did not loaded any external modules. In qemu I see this crash in early boot: alright, so n900's working fine. I'll wait until you debug qemu a little more, thank you NO! It does not working, see . It break n900 totally! settle down a bit more. I don't have the HW you have and things are working fine on boards I _do_ have, there's not much more I can do to help without you doing your homework. Debug a bit more and bring more information as to what's going on, until then you're on your own. And what more do you need? It crash on my n900 and also in qemu. I sent you kernel crash dump from qemu which introduced *your* patches. Before applying your patches there was no crash in early boot stage. In current state I review all 3 patches as: Rejected-by: Pali Rohár pali.ro...@gmail.com [It breaks booting Nokia N900 device] next step, figure why it's broken. Working just fine here on AM335x which has the same musb IP. in any case, .config will help. # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.19.0-rc5 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_ARM_DMA_USE_IOMMU=y CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8 CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_FHANDLE is not set CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_HANDLE_DOMAIN_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_PREEMPT_RCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_BOOST is not set # CONFIG_RCU_NOCB_CPU is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_CGROUPS=y #
Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls
On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote: On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 16:43:45 Felipe Balbi wrote: Hi, On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 00:15:19 Felipe Balbi wrote: f_phonet's -set_alt() method will call usb_ep_disable() potentially on an endpoint which is already disabled. That's something the gadget/function driver must guarantee that it's always balanced. In order to balance the calls, just make sure the endpoint was enabled before by means of checking the validity of driver_data. Reported-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com --- Your patches cause that kernel does not print any error message to n900 screen anymore and reboot device in 10 seconds. I did not loaded any external modules. In qemu I see this crash in early boot: alright, so n900's working fine. I'll wait until you debug qemu a little more, thank you NO! It does not working, see . It break n900 totally! settle down a bit more. I don't have the HW you have and things are working fine on boards I _do_ have, there's not much more I can do to help without you doing your homework. Debug a bit more and bring more information as to what's going on, until then you're on your own. And what more do you need? It crash on my n900 and also in qemu. I sent you kernel crash dump from qemu which introduced *your* patches. Before applying your patches there was no crash in early boot stage. In current state I review all 3 patches as: Rejected-by: Pali Rohár pali.ro...@gmail.com [It breaks booting Nokia N900 device] -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls
On Tue, Feb 03, 2015 at 01:35:25PM -0600, Felipe Balbi wrote: On Tue, Feb 03, 2015 at 08:27:52PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote: On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 16:43:45 Felipe Balbi wrote: Hi, On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 00:15:19 Felipe Balbi wrote: f_phonet's -set_alt() method will call usb_ep_disable() potentially on an endpoint which is already disabled. That's something the gadget/function driver must guarantee that it's always balanced. In order to balance the calls, just make sure the endpoint was enabled before by means of checking the validity of driver_data. Reported-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com --- Your patches cause that kernel does not print any error message to n900 screen anymore and reboot device in 10 seconds. I did not loaded any external modules. In qemu I see this crash in early boot: alright, so n900's working fine. I'll wait until you debug qemu a little more, thank you NO! It does not working, see . It break n900 totally! settle down a bit more. I don't have the HW you have and things are working fine on boards I _do_ have, there's not much more I can do to help without you doing your homework. Debug a bit more and bring more information as to what's going on, until then you're on your own. And what more do you need? It crash on my n900 and also in qemu. I sent you kernel crash dump from qemu which introduced *your* patches. Before applying your patches there was no crash in early boot stage. In current state I review all 3 patches as: Rejected-by: Pali Rohár pali.ro...@gmail.com [It breaks booting Nokia N900 device] next step, figure why it's broken. Working just fine here on AM335x which has the same musb IP. in any case, .config will help. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls
Hi, On Tue, Feb 03, 2015 at 08:57:11PM +0100, Pali Rohár wrote: f_phonet's -set_alt() method will call usb_ep_disable() potentially on an endpoint which is already disabled. That's something the gadget/function driver must guarantee that it's always balanced. In order to balance the calls, just make sure the endpoint was enabled before by means of checking the validity of driver_data. Reported-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com --- Your patches cause that kernel does not print any error message to n900 screen anymore and reboot device in 10 seconds. I did not loaded any external modules. In qemu I see this crash in early boot: alright, so n900's working fine. I'll wait until you debug qemu a little more, thank you NO! It does not working, see . It break n900 totally! settle down a bit more. I don't have the HW you have and things are working fine on boards I _do_ have, there's not much more I can do to help without you doing your homework. Debug a bit more and bring more information as to what's going on, until then you're on your own. And what more do you need? It crash on my n900 and also in qemu. I sent you kernel crash dump from qemu which introduced *your* patches. Before applying your patches there was no crash in early boot stage. In current state I review all 3 patches as: Rejected-by: Pali Rohár pali.ro...@gmail.com [It breaks booting Nokia N900 device] next step, figure why it's broken. Working just fine here on AM335x which has the same musb IP. Why is broken? That is easy. You send 3 patches which broke it. as I said, working just fine here: http://hastebin.com/zolunekepo -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls
On Tue, Feb 03, 2015 at 08:27:52PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote: On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 16:43:45 Felipe Balbi wrote: Hi, On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 00:15:19 Felipe Balbi wrote: f_phonet's -set_alt() method will call usb_ep_disable() potentially on an endpoint which is already disabled. That's something the gadget/function driver must guarantee that it's always balanced. In order to balance the calls, just make sure the endpoint was enabled before by means of checking the validity of driver_data. Reported-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com --- Your patches cause that kernel does not print any error message to n900 screen anymore and reboot device in 10 seconds. I did not loaded any external modules. In qemu I see this crash in early boot: alright, so n900's working fine. I'll wait until you debug qemu a little more, thank you NO! It does not working, see . It break n900 totally! settle down a bit more. I don't have the HW you have and things are working fine on boards I _do_ have, there's not much more I can do to help without you doing your homework. Debug a bit more and bring more information as to what's going on, until then you're on your own. And what more do you need? It crash on my n900 and also in qemu. I sent you kernel crash dump from qemu which introduced *your* patches. Before applying your patches there was no crash in early boot stage. In current state I review all 3 patches as: Rejected-by: Pali Rohár pali.ro...@gmail.com [It breaks booting Nokia N900 device] next step, figure why it's broken. Working just fine here on AM335x which has the same musb IP. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls
On Tuesday 03 February 2015 20:35:25 Felipe Balbi wrote: On Tue, Feb 03, 2015 at 08:27:52PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 20:18:59 Felipe Balbi wrote: On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 16:43:45 Felipe Balbi wrote: Hi, On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali Rohár wrote: On Tuesday 03 February 2015 00:15:19 Felipe Balbi wrote: f_phonet's -set_alt() method will call usb_ep_disable() potentially on an endpoint which is already disabled. That's something the gadget/function driver must guarantee that it's always balanced. In order to balance the calls, just make sure the endpoint was enabled before by means of checking the validity of driver_data. Reported-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Felipe Balbi ba...@ti.com --- Your patches cause that kernel does not print any error message to n900 screen anymore and reboot device in 10 seconds. I did not loaded any external modules. In qemu I see this crash in early boot: alright, so n900's working fine. I'll wait until you debug qemu a little more, thank you NO! It does not working, see . It break n900 totally! settle down a bit more. I don't have the HW you have and things are working fine on boards I _do_ have, there's not much more I can do to help without you doing your homework. Debug a bit more and bring more information as to what's going on, until then you're on your own. And what more do you need? It crash on my n900 and also in qemu. I sent you kernel crash dump from qemu which introduced *your* patches. Before applying your patches there was no crash in early boot stage. In current state I review all 3 patches as: Rejected-by: Pali Rohár pali.ro...@gmail.com [It breaks booting Nokia N900 device] next step, figure why it's broken. Working just fine here on AM335x which has the same musb IP. Why is broken? That is easy. You send 3 patches which broke it. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v4] ehci-pci: disable for Intel MID platforms (update)
On Tue, Feb 03, 2015 at 11:15:34PM +0300, Sergei Shtylyov wrote:
Hello.
On 02/03/2015 07:08 PM, Andy Shevchenko wrote:
This is a follow up to the previously submitted commit cefa9a31a5f0
(ehci-pci:
disable for Intel MID platforms).
It includes the following changes:
- table and function are renamed to reflect this is not only about ChipIdea
- ChipIdea PCI driver (ci_hdrc_pci.c) gets the comment about the table in
ehci-pci.c
- MIPS IDs removed from the list since it was discovered and tested on Intel
MID platforms
Reviewed-by: Alexander Shishkin alexander.shish...@linux.intel.com
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
[...]
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 9652021..2a5d2fd 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -42,18 +42,22 @@ static inline bool is_intel_quark_x1000(struct pci_dev
*pdev)
pdev-device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
}
-static const struct pci_device_id ci_hdrc_pci_id_table[] = {
-{ PCI_DEVICE(0x153F, 0x1004), },
-{ PCI_DEVICE(0x153F, 0x1006), },
+/*
+ * This is the list of PCI IDs for the devices that have EHCI USB class and
+ * specific drivers for that. One of the example is a ChipIdea device
installed
+ * on some Intel MID platforms.
+ */
+static const struct pci_device_id bypass_pci_id_table[] = {
+/* ChipIdea on Intel MID platform */
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006), },
I'd suggest using PCI_VDEVICE() here instead.
Not a big deal.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: phy: phy-generic: No need to call gpiod_direction_output() twice
From: Fabio Estevam fabio.este...@freescale.com
Commit 9eb0797722895f4309b4 (usb: phy: generic: fix the gpios to be optional)
calls gpiod_direction_output() in the probe function, so there is no need to
call it again, as we can simply call gpiod_set_value() directly.
Also, in usb_gen_phy_shutdown() we can simply put the GPIO directly in its
active level state and this allows us to simplify the nop_reset function to
treat only the reset case.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Simplify nop_reset() function
drivers/usb/phy/phy-generic.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 70be50b..58c887e 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -62,14 +62,14 @@ static int nop_set_suspend(struct usb_phy *x, int suspend)
return 0;
}
-static void nop_reset_set(struct usb_phy_generic *nop, int asserted)
+static void nop_reset(struct usb_phy_generic *nop)
{
if (!nop-gpiod_reset)
return;
- gpiod_direction_output(nop-gpiod_reset, !asserted);
+ gpiod_set_value(nop-gpiod_reset, 1);
usleep_range(1, 2);
- gpiod_set_value(nop-gpiod_reset, asserted);
+ gpiod_set_value(nop-gpiod_reset, 0);
}
/* interface to regulator framework */
@@ -151,8 +151,7 @@ int usb_gen_phy_init(struct usb_phy *phy)
if (!IS_ERR(nop-clk))
clk_prepare_enable(nop-clk);
- /* De-assert RESET */
- nop_reset_set(nop, 0);
+ nop_reset(nop);
return 0;
}
@@ -162,8 +161,8 @@ void usb_gen_phy_shutdown(struct usb_phy *phy)
{
struct usb_phy_generic *nop = dev_get_drvdata(phy-dev);
- /* Assert RESET */
- nop_reset_set(nop, 1);
+ if (nop-gpiod_reset)
+ gpiod_set_value(nop-gpiod_reset, 1);
if (!IS_ERR(nop-clk))
clk_disable_unprepare(nop-clk);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: phy-generic: No need to call gpiod_direction_output() twice
Hi Felipe, On Sun, Feb 1, 2015 at 3:37 PM, Felipe Balbi ba...@ti.com wrote: I like this, very much. Two comments though. We requested the gpio with _optional(), and NULL is a valid gpio_desc, this if (nop-gpiod_reset) is unnecessary. And also, since we don't have anymore the assert But if the reset-gpios property is not present in the dts, then nop-gpiod_reset is NULL, and it is better not to call 'gpiod_direction_output(nop-gpiod_reset, 1)' in this case, right? argument, we should rename nop_reset_set() to nop_reset. Agreed, will change it in v2. Regards, Fabio Estevam -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] ehci-pci: disable for Intel MID platforms (update)
Hello.
On 02/03/2015 07:08 PM, Andy Shevchenko wrote:
This is a follow up to the previously submitted commit cefa9a31a5f0 (ehci-pci:
disable for Intel MID platforms).
It includes the following changes:
- table and function are renamed to reflect this is not only about ChipIdea
- ChipIdea PCI driver (ci_hdrc_pci.c) gets the comment about the table in
ehci-pci.c
- MIPS IDs removed from the list since it was discovered and tested on Intel
MID platforms
Reviewed-by: Alexander Shishkin alexander.shish...@linux.intel.com
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
[...]
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 9652021..2a5d2fd 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -42,18 +42,22 @@ static inline bool is_intel_quark_x1000(struct pci_dev
*pdev)
pdev-device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
}
-static const struct pci_device_id ci_hdrc_pci_id_table[] = {
- { PCI_DEVICE(0x153F, 0x1004), },
- { PCI_DEVICE(0x153F, 0x1006), },
+/*
+ * This is the list of PCI IDs for the devices that have EHCI USB class and
+ * specific drivers for that. One of the example is a ChipIdea device installed
+ * on some Intel MID platforms.
+ */
+static const struct pci_device_id bypass_pci_id_table[] = {
+ /* ChipIdea on Intel MID platform */
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006), },
I'd suggest using PCI_VDEVICE() here instead.
[...]
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: phy: phy-generic: No need to call gpiod_direction_output() twice
On Tue, Feb 03, 2015 at 06:21:24PM -0200, Fabio Estevam wrote:
Hi Felipe,
On Sun, Feb 1, 2015 at 3:37 PM, Felipe Balbi ba...@ti.com wrote:
I like this, very much. Two comments though. We requested the gpio with
_optional(), and NULL is a valid gpio_desc, this if (nop-gpiod_reset)
is unnecessary. And also, since we don't have anymore the assert
But if the reset-gpios property is not present in the dts, then
nop-gpiod_reset is NULL, and it is better not to call
'gpiod_direction_output(nop-gpiod_reset, 1)' in this case, right?
it doesn't make a difference though, right ?
gpiod_direction_output(NULL, 1) won't do anything.
/me goes look at code
Man this is messed up. If you follow gpiod_get_optional, you'll end up
at gpiod_get_index_optional() which I quote below:
1989 struct gpio_desc *__must_check __gpiod_get_index_optional(struct device
*dev,
1990 const char *con_id,
1991 unsigned int index,
1992 enum gpiod_flags
flags)
1993 {
1994 struct gpio_desc *desc;
1995
1996 desc = gpiod_get_index(dev, con_id, index, flags);
1997 if (IS_ERR(desc)) {
1998 if (PTR_ERR(desc) == -ENOENT)
1999 return NULL;
2000 }
2001
2002 return desc;
2003 }
2004 EXPORT_SYMBOL_GPL(__gpiod_get_index_optional);
So, if the error code is -ENOENT it returns NULL, that tells me NULL is
a valid gpio descriptor. If you follow gpiod_direction_output() however,
what you get is:
1072 int gpiod_direction_output(struct gpio_desc *desc, int value)
1073 {
1074 if (!desc || !desc-chip) {
1075 pr_warn(%s: invalid GPIO\n, __func__);
1076 return -EINVAL;
1077 }
1078 if (test_bit(FLAG_ACTIVE_LOW, desc-flags))
1079 value = !value;
1080 return _gpiod_direction_output_raw(desc, value);
1081 }
1082 EXPORT_SYMBOL_GPL(gpiod_direction_output);
That pr_warn() tells me NULL is *not* a valid gpio descriptor. Linus, is
that just something that was missed until now ?
argument, we should rename nop_reset_set() to nop_reset.
Agreed, will change it in v2.
Thanks
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH_V4 1/3] dt: usb: jz4740: Add DT binding document for OHCI
On 03/02/15 10:32, Lars-Peter Clausen wrote:
On 02/03/2015 11:17 AM, Zubair Lutfullah Kakakhel wrote:
[...]
V4 Changes
Removed clock binding because of pending work in clock tree. Will add
binding later. Rather than introduce a bad binding now and change later.
But this patch is introducing a bad binding. The part needs the clock to
work. The binding you are specifying right now says that it works fine
without any clocks.
Facing a chicken and egg problem with these patches here..
When the new clock driver gets in we can add the correct clock binding and
replace
devm_clk_get(pdev-dev, uhc); with devm_clk_get(pdev-dev, NULL);
Specifying the current binding got NAKed by Arnd who mentioned that clock names
shouldn't be needed as required properties.
And even if needed, then it shouldn't be uhc and more close to what other
ohci drivers have.
Hence rather than bad binding now, we'll add a binding later..
[...]
+Example for jz4740:
+
+/ {
+ohci: jz4780-ohci@0x134a {
s/jz4780/jz4740
Thanks
ZubairLK
+compatible = ingenic,jz4740-ohci;
+reg = 0x134a 0x1;
+
+interrupts = 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_V4 1/3] dt: usb: jz4740: Add DT binding document for OHCI
From: Paul Burton paul.bur...@imgtec.com
Add the binding documentation for the JZ4740 OHCI controller.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
Signed-off-by: Zubair Lutfullah Kakakhel zubair.kakak...@imgtec.com
---
The jz4740 is platform only at the moment.
But DT support is being added
See http://patchwork.linux-mips.org/bundle/paulburton/ci20-v3.20/
V4 Changes
Removed clock binding because of pending work in clock tree. Will add
binding later. Rather than introduce a bad binding now and change later.
V3 Changes: named binding jz4740 instead of confusing it with jz47xx.
The driver name is jz4740. And will not be renamed
V2 Changes: Removed interrupt parent binding as that can be inherited.
Forgot a binding for clock-names
---
.../devicetree/bindings/usb/ingenic,jz4740-ohci.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644
Documentation/devicetree/bindings/usb/ingenic,jz4740-ohci.txt
diff --git a/Documentation/devicetree/bindings/usb/ingenic,jz4740-ohci.txt
b/Documentation/devicetree/bindings/usb/ingenic,jz4740-ohci.txt
new file mode 100644
index 000..29c1934
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ingenic,jz4740-ohci.txt
@@ -0,0 +1,21 @@
+Ingenic JZ4740 SoC OHCI controller binding
+
+The Ingenic JZ4740 SoC includes an OHCI compliant USB host controller
+interface for use with USB 1.1 devices.
+
+Required properties:
+ - compatible: Should be ingenic,jz4740-ohci
+ - reg: Should contain the address size of the OHCI controller registers.
+ - interrupts: Should specify the interrupt line number
+
+Example for jz4740:
+
+/ {
+ ohci: jz4780-ohci@0x134a {
+ compatible = ingenic,jz4740-ohci;
+ reg = 0x134a 0x1;
+
+ interrupts = 5;
+ };
+};
+
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH_V4 0/3] usb: ohci: jz4740: Add DT support and a fix
Hi, Here are a few simple patches for the jz4740. First adds a simple DT binding. Seconds adds DT support. Third is a minor fix in clock enabling. Patches are based on 3.19-rc7. Quite disjoint and stay within jz4740 so should apply easily on other trees. If you would like to have them rebased to a different tree, please tell. Thank-you V4 changes Removed clk bindings. They can be added later when the work on jz4740 clks is done. Rather than add bindings now and change later. V3 changes DT corrections. Added ACKS for 2 and 3. V2 changes Removed an interrupt parent binding. Forgot a binding Unprepared clock when disabling ZubairLK Paul Burton (3): dt: usb: jz4740: Add DT binding document for OHCI usb: ohci: jz4740: add DT support usb: ohci: jz4740: prepare the clock before enabling it .../devicetree/bindings/usb/ingenic,jz4740-ohci.txt | 21 + drivers/usb/host/ohci-jz4740.c | 15 --- 2 files changed, 33 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/ingenic,jz4740-ohci.txt -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH_V4 2/3] usb: ohci: jz4740: add DT support
From: Paul Burton paul.bur...@imgtec.com
This is a simple matter of providing a match table, the probe code needs
no modification.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
Signed-off-by: Zubair Lutfullah Kakakhel zubair.kakak...@imgtec.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ohci-jz4740.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/host/ohci-jz4740.c b/drivers/usb/host/ohci-jz4740.c
index 8ddd8f5..bb69733 100644
--- a/drivers/usb/host/ohci-jz4740.c
+++ b/drivers/usb/host/ohci-jz4740.c
@@ -234,11 +234,20 @@ static int jz4740_ohci_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static struct of_device_id jz4740_ohci_of_match[] = {
+ { .compatible = ingenic,jz4740-ohci, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, jz4740_ohci_of_match);
+#endif
+
static struct platform_driver ohci_hcd_jz4740_driver = {
.probe = jz4740_ohci_probe,
.remove = jz4740_ohci_remove,
.driver = {
.name = jz4740-ohci,
+ .of_match_table = of_match_ptr(jz4740_ohci_of_match),
.owner = THIS_MODULE,
},
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH_V4 3/3] usb: ohci: jz4740: prepare the clock before enabling it
From: Paul Burton paul.bur...@imgtec.com The clock must have been prepared before enabling it. Signed-off-by: Paul Burton paul.bur...@imgtec.com Signed-off-by: Zubair Lutfullah Kakakhel zubair.kakak...@imgtec.com Acked-by: Alan Stern st...@rowland.harvard.edu -- V2 changes. Add disable_unprepare as well --- drivers/usb/host/ohci-jz4740.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/ohci-jz4740.c b/drivers/usb/host/ohci-jz4740.c index bb69733..129f6b9 100644 --- a/drivers/usb/host/ohci-jz4740.c +++ b/drivers/usb/host/ohci-jz4740.c @@ -189,7 +189,7 @@ static int jz4740_ohci_probe(struct platform_device *pdev) clk_set_rate(jz4740_ohci-clk, 4800); - clk_enable(jz4740_ohci-clk); + clk_prepare_enable(jz4740_ohci-clk); if (jz4740_ohci-vbus) ohci_jz4740_set_vbus_power(jz4740_ohci, true); @@ -209,7 +209,7 @@ static int jz4740_ohci_probe(struct platform_device *pdev) err_disable: if (jz4740_ohci-vbus) regulator_disable(jz4740_ohci-vbus); - clk_disable(jz4740_ohci-clk); + clk_disable_unprepare(jz4740_ohci-clk); err_free: usb_put_hcd(hcd); @@ -227,7 +227,7 @@ static int jz4740_ohci_remove(struct platform_device *pdev) if (jz4740_ohci-vbus) regulator_disable(jz4740_ohci-vbus); - clk_disable(jz4740_ohci-clk); + clk_disable_unprepare(jz4740_ohci-clk); usb_put_hcd(hcd); -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH_V4 1/3] dt: usb: jz4740: Add DT binding document for OHCI
On 02/03/2015 11:17 AM, Zubair Lutfullah Kakakhel wrote:
[...]
V4 Changes
Removed clock binding because of pending work in clock tree. Will add
binding later. Rather than introduce a bad binding now and change later.
But this patch is introducing a bad binding. The part needs the clock to
work. The binding you are specifying right now says that it works fine
without any clocks.
[...]
+Example for jz4740:
+
+/ {
+ ohci: jz4780-ohci@0x134a {
s/jz4780/jz4740
+ compatible = ingenic,jz4740-ohci;
+ reg = 0x134a 0x1;
+
+ interrupts = 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: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out
On 17.01.2015 09:56, poma wrote: On 17.01.2015 00:57, sean darcy wrote: On 01/16/2015 07:09 AM, poma wrote: On 16.01.2015 10:37, Hayes Wang wrote: poma [mailto:pomidorabelis...@gmail.com] Sent: Friday, January 16, 2015 4:25 PM [...] This looks like a USB problem. Is there a way to get usb (or NetworkManager) to reinitialize the driver when this happens? I would ask these people for advice, therefore. Our hw engineers need to analyse the behavior of the device. However, I don't think you have such instrument to provide the required information. If we don't know the reason, we couldn't give you the proper solution. Besides, your solution would work if and only if reloading the driver is helpful. The issue have to debug from the hardware, and I have no idea about what the software could do before analysing the hw. Maybe you could try the following driver first to check if it is useful. http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2PNid=13PFid=56Level=5Conn=4DownTypeID=3GetDown=false Best Regards, Hayes Thanks for your response, Mr. Hayes. Mr. Sean, please download and check if timeout is still present with built RTL8153 module from REALTEK site, as Mr. Hayes proposed. http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2PNid=13PFid=56Level=5Conn=4DownTypeID=3GetDown=false#2 r8152.53-2.03.0.tar.bz2 Procedure - should be equal for both, Fedora 21 20: $ uname -r 3.17.8-300.fc21.x86_64 $ su -c 'yum install kernel-devel' $ tar xf r8152.53-2.03.0.tar.bz2 $ cd r8152-2.03.0/ $ make $ su # cp 50-usb-realtek-net.rules /etc/udev/rules.d/ # udevadm trigger --action=add # modprobe -rv r8152 # cp r8152.ko /lib/modules/$(uname -r)/updates/ # depmod # modprobe -v r8152 poma OK. Did all that. Now to see if I get the same problem over the next couple of weeks. I'd never heard about the updates subfolder in modules. Very slick. But when I update the kernel, I get to do this again correct? How will I $ cd r8152-2.03.0/ $ make clean $ make $ su # cp r8152.ko /lib/modules/$(uname -r)/updates/ # depmod # modprobe -v r8152 is part of the procedure necessary for a new i.e. an upgraded kernel. know that this module has been incorporated in the running kernel. modinfo doesn't give any version info. $ modinfo r8152 -n will show the module considered for loading. BTW, I'm not sure what modprobe --dump-modversions is supposed to do, but it doesn't: #modprobe --dump-modversions r8152 modprobe: FATAL: Module r8152 not found. # modprobe --dump-modversions r8152.ko modprobe: FATAL: Module r8152.ko not found. #lsmod | grep 8152 r8152 49646 0 --dump-modversions will probably show the same error for any module. Thanks for all your help. sean YW Mr. Sean, is your problem with r8152 resolved, are kernel: r8152 2-2:1.0 internal: Tx timeout still present? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] usb: udc: add usb_udc_activation_handler
Peter Chen peter.c...@freescale.com writes:
Currently, connect gadget is unconditional after binding,
but some function drivers may want to connect gadget on the fly.
With this API, the function driver can disconnect gadget during
the initialization, and connect gadget when it wants.
During this API, the deactivation count will be update, and it
will try to connect or disconnect gadget. It can be used to
enable functions for gadget when necessary.
Signed-off-by: Peter Chen peter.c...@freescale.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/gadget/udc/udc-core.c | 35 ++-
include/linux/usb/gadget.h| 5 +
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 9396a86..a757334 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -37,6 +37,7 @@
* @list - for use by the udc class driver
* @vbus - for udcs who care about vbus status, this value is real vbus
status;
* for udcs who do not care about vbus status, this value is always true
+ * @deactivations - the deactivation count to connect or disconnect gadget
*
* This represents the internal data structure which is used by the UDC-class
* to hold information about udc driver and gadget together.
@@ -47,6 +48,7 @@ struct usb_udc {
struct device dev;
struct list_headlist;
boolvbus;
+ int deactivations;
};
static struct class *udc_class;
@@ -168,13 +170,44 @@ EXPORT_SYMBOL_GPL(usb_gadget_set_state);
static void usb_udc_connect_control(struct usb_udc *udc)
{
- if (udc-vbus)
+ if (udc-vbus !udc-deactivations)
usb_gadget_connect(udc-gadget);
else
usb_gadget_disconnect(udc-gadget);
}
/**
+ * usb_udc_activation_handler - updates udc's deactivation count and
+ * try to connect or disconnect
+ *
+ * @gadget: The gadget which the function is at
+ * @active: the function needs to be active or not
+ *
+ * The composite core or function driver calls it when it
+ * wants to activate or deactivate function.
+ */
+void usb_udc_activation_handler(struct usb_gadget *gadget, bool active)
+{
+ struct usb_udc *udc = usb_gadget_find_udc(gadget);
+
if (!udc)
return;
can make this function slightly easier on the eyes.
+ mutex_lock(udc_lock);
+ if (udc) {
+ if (active) {
+ if (udc-deactivations == 0) {
+ WARN_ON(1);
+ return;
This returns with the udc_lock locked.
Also, you probably want WARN_ON_ONCE() like so:
if (WARN_ON_ONCE(udc-deactivations)) ...
Also, I don't think you want udc_lock here at all, it looks like its (at
least intended) use is to serialize accesses to udc_list. You could use
an atomic if you want to protect against concurrent (de-)activations,
but then you would still need to synchronize
usb_gadget_connect()/usb_gadget_disconnect() that result from these
activations. I assume that normally these will serialize on gadget
driver's spinlock in pullup(), so it should be all right.
Regards,
--
Alex
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] usb: udc: Unify dp control
Peter Chen peter.c...@freescale.com writes: On Thu, Jan 29, 2015 at 12:27:23PM +0800, Peter Chen wrote: Hi Felipe, Hi Felipe, I see you tree is closed, but below three patches are not in your tree, will you queue them now or at next rc? I have some other patches based on them, so I would like to know your ideas, thanks. It's up to Felipe again, but I'd say include the patches that you wrote on top of these in the same patchset, because adding an api without users makes it more difficult to validate wrt its intended use cases and it also makes potential bugs that are introduced in the api patches sit quietly in the tree until you add users, at which point it's probable that these apis will need fixing anyway. Regards, -- Alex -- 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: phy: phy-generic: No need to call gpiod_direction_output() twice
On Tue, Feb 3, 2015 at 6:52 PM, Felipe Balbi ba...@ti.com wrote:
it doesn't make a difference though, right ?
gpiod_direction_output(NULL, 1) won't do anything.
Yes, I will send a v3 without the NULL check.
gpiod_set_value returns immediately if desc is NULL:
void gpiod_set_value(struct gpio_desc *desc, int value)
{
if (!desc)
return;
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] usb: phy: phy-generic: No need to call gpiod_direction_output() twice
From: Fabio Estevam fabio.este...@freescale.com
Commit 9eb0797722895f4309b4 (usb: phy: generic: fix the gpios to be optional)
calls gpiod_direction_output() in the probe function, so there is no need to
call it again, as we can simply call gpiod_set_value() directly.
Also, in usb_gen_phy_shutdown() we can simply put the GPIO directly in its
active level state and this allows us to simplify the nop_reset function to
treat only the reset case.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v2:
- No need to do a NULL check prior to gpiod_set_value()
drivers/usb/phy/phy-generic.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 70be50b..deee68e 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -62,14 +62,14 @@ static int nop_set_suspend(struct usb_phy *x, int suspend)
return 0;
}
-static void nop_reset_set(struct usb_phy_generic *nop, int asserted)
+static void nop_reset(struct usb_phy_generic *nop)
{
if (!nop-gpiod_reset)
return;
- gpiod_direction_output(nop-gpiod_reset, !asserted);
+ gpiod_set_value(nop-gpiod_reset, 1);
usleep_range(1, 2);
- gpiod_set_value(nop-gpiod_reset, asserted);
+ gpiod_set_value(nop-gpiod_reset, 0);
}
/* interface to regulator framework */
@@ -151,8 +151,7 @@ int usb_gen_phy_init(struct usb_phy *phy)
if (!IS_ERR(nop-clk))
clk_prepare_enable(nop-clk);
- /* De-assert RESET */
- nop_reset_set(nop, 0);
+ nop_reset(nop);
return 0;
}
@@ -162,8 +161,7 @@ void usb_gen_phy_shutdown(struct usb_phy *phy)
{
struct usb_phy_generic *nop = dev_get_drvdata(phy-dev);
- /* Assert RESET */
- nop_reset_set(nop, 1);
+ gpiod_set_value(nop-gpiod_reset, 1);
if (!IS_ERR(nop-clk))
clk_disable_unprepare(nop-clk);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] ehci-pci: disable for Intel MID platforms (update)
On Tue, Feb 03, 2015 at 06:08:39PM +0200, Andy Shevchenko wrote:
This is a follow up to the previously submitted commit cefa9a31a5f0 (ehci-pci:
disable for Intel MID platforms).
It includes the following changes:
- table and function are renamed to reflect this is not only about ChipIdea
- ChipIdea PCI driver (ci_hdrc_pci.c) gets the comment about the table in
ehci-pci.c
- MIPS IDs removed from the list since it was discovered and tested on Intel
MID platforms
Reviewed-by: Alexander Shishkin alexander.shish...@linux.intel.com
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/usb/chipidea/ci_hdrc_pci.c | 3 +++
drivers/usb/host/ehci-pci.c| 16 ++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_pci.c
b/drivers/usb/chipidea/ci_hdrc_pci.c
index 241ae34..4df6694 100644
--- a/drivers/usb/chipidea/ci_hdrc_pci.c
+++ b/drivers/usb/chipidea/ci_hdrc_pci.c
@@ -111,6 +111,9 @@ static void ci_hdrc_pci_remove(struct pci_dev *pdev)
* PCI device structure
*
* Check pci.h for details
+ *
+ * Note: ehci-pci driver may try to probe the device first. You have to add
an
+ * ID to the bypass_pci_id_table in ehci-pci driver to prevent this.
*/
This one is the same with your v3.
static const struct pci_device_id ci_hdrc_pci_id_table[] = {
{
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 9652021..2a5d2fd 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -42,18 +42,22 @@ static inline bool is_intel_quark_x1000(struct pci_dev
*pdev)
pdev-device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
}
-static const struct pci_device_id ci_hdrc_pci_id_table[] = {
- { PCI_DEVICE(0x153F, 0x1004), },
- { PCI_DEVICE(0x153F, 0x1006), },
+/*
+ * This is the list of PCI IDs for the devices that have EHCI USB class and
+ * specific drivers for that. One of the example is a ChipIdea device
installed
+ * on some Intel MID platforms.
+ */
+static const struct pci_device_id bypass_pci_id_table[] = {
+ /* ChipIdea on Intel MID platform */
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006), },
{}
};
-static inline bool is_ci_hdrc_pci(struct pci_dev *pdev)
+static inline bool is_bypassed_id(struct pci_dev *pdev)
{
- return !!pci_match_id(ci_hdrc_pci_id_table, pdev);
+ return !!pci_match_id(bypass_pci_id_table, pdev);
}
/*
@@ -368,7 +372,7 @@ static const struct ehci_driver_overrides pci_overrides
__initconst = {
static int ehci_pci_probe(struct pci_dev *pdev, const struct pci_device_id
*id)
{
- if (is_ci_hdrc_pci(pdev))
+ if (is_bypassed_id(pdev))
return -ENODEV;
return usb_hcd_pci_probe(pdev, id);
}
--
I have no idea for this change.
If Greg has still not queued your pci patch, you can squash all your
versions for pci and chipidea to one patch set, in this set, one patch
for pci, and another for chipidea.
--
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
