Fengguang Wu run into a kernel ops after he complied dummy_hcd and g_cdc
into the kernel. The problem was that u_serial was used by g_cdc before
u_serial was initialized. In the module case eveything is initialized in
the correct order but if we compile it into the kernel we rely on
Makefile order which I did wrong and now I correct this.
Cc: Fengguang Wu <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
---
I kinda assumed that this was already fixed (i.e. a patch like this was sent)
but it seems not to be that case.
drivers/usb/gadget/Makefile | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 97a13c3..1ded3d4 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -35,6 +35,12 @@ mv_udc-y := mv_udc_core.o
obj-$(CONFIG_USB_FUSB300) += fusb300_udc.o
obj-$(CONFIG_USB_MV_U3D) += mv_u3d_core.o
+# USB Functions
+obj-$(CONFIG_USB_U_SERIAL) += u_serial.o
+obj-$(CONFIG_USB_F_ACM) += f_acm.o
+f_ss_lb-y := f_loopback.o f_sourcesink.o
+obj-$(CONFIG_USB_F_SS_LB) += f_ss_lb.o
+
#
# USB gadget drivers
#
@@ -74,9 +80,3 @@ obj-$(CONFIG_USB_G_WEBCAM) += g_webcam.o
obj-$(CONFIG_USB_G_NCM) += g_ncm.o
obj-$(CONFIG_USB_G_ACM_MS) += g_acm_ms.o
obj-$(CONFIG_USB_GADGET_TARGET) += tcm_usb_gadget.o
-
-# USB Functions
-obj-$(CONFIG_USB_F_ACM) += f_acm.o
-f_ss_lb-y := f_loopback.o f_sourcesink.o
-obj-$(CONFIG_USB_F_SS_LB) += f_ss_lb.o
-obj-$(CONFIG_USB_U_SERIAL) += u_serial.o
--
1.7.10.4
On Mon, Mar 04, 2013 at 10:28:09PM +0100, Sebastian Andrzej Siewior wrote:
> Fengguang Wu run into a kernel ops after he complied dummy_hcd and g_cdc
> into the kernel. The problem was that u_serial was used by g_cdc before
> u_serial was initialized. In the module case eveything is initialized in
> the correct order but if we compile it into the kernel we rely on
> Makefile order which I did wrong and now I correct this.
>
> Cc: Fengguang Wu <[email protected]>
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Tested-by: Fengguang Wu <[email protected]>
Thanks!
On Tue, Mar 05, 2013 at 05:57:34PM +0800, Fengguang Wu wrote:
> On Mon, Mar 04, 2013 at 10:28:09PM +0100, Sebastian Andrzej Siewior wrote:
> > Fengguang Wu run into a kernel ops after he complied dummy_hcd and g_cdc
> > into the kernel. The problem was that u_serial was used by g_cdc before
> > u_serial was initialized. In the module case eveything is initialized in
> > the correct order but if we compile it into the kernel we rely on
> > Makefile order which I did wrong and now I correct this.
> >
> > Cc: Fengguang Wu <[email protected]>
> > Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
>
> Tested-by: Fengguang Wu <[email protected]>
Note that I still get this warning, however looks like an unrelated
issue:
[ 602.536679] [ INFO: possible circular locking dependency detected ]
[ 602.536672]
[ 602.536679] ======================================================
[ 602.536679] [ INFO: possible circular locking dependency detected ]
[ 602.536693] 3.8.0-bisect-next-20130301-dirty #212 Not tainted
[ 602.536694] -------------------------------------------------------
[ 602.536698] kworker/0:1/27 is trying to acquire lock:
[ 602.536750] (&fb_info->lock){+.+.+.}, at: [<ffffffff814c0176>] lock_fb_info+0x26/0x60
[ 602.536751]
[ 602.536751] but task is already holding lock:
[ 602.536773] (console_lock){+.+.+.}, at: [<ffffffff815a6a13>] console_callback+0x13/0x150
[ 602.536774]
[ 602.536774] which lock already depends on the new lock.
Thanks,
Fengguang
On Mon, Mar 04, 2013 at 10:28:09PM +0100, Sebastian Andrzej Siewior wrote:
> Fengguang Wu run into a kernel ops after he complied dummy_hcd and g_cdc
> into the kernel. The problem was that u_serial was used by g_cdc before
> u_serial was initialized. In the module case eveything is initialized in
> the correct order but if we compile it into the kernel we rely on
> Makefile order which I did wrong and now I correct this.
>
> Cc: Fengguang Wu <[email protected]>
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
> ---
> I kinda assumed that this was already fixed (i.e. a patch like this was sent)
> but it seems not to be that case.
already in Greg's queue, cheers
--
balbi
* Felipe Balbi | 2013-03-05 12:49:44 [+0200]:
>> I kinda assumed that this was already fixed (i.e. a patch like this was sent)
>> but it seems not to be that case.
>
>already in Greg's queue, cheers
great…
Sebastian
* Fengguang Wu | 2013-03-05 18:35:13 [+0800]:
>Note that I still get this warning, however looks like an unrelated
>issue:
>
>[ 602.536679] [ INFO: possible circular locking dependency detected ]
>[ 602.536672]
>[ 602.536679] ======================================================
>[ 602.536679] [ INFO: possible circular locking dependency detected ]
>[ 602.536693] 3.8.0-bisect-next-20130301-dirty #212 Not tainted
>[ 602.536694] -------------------------------------------------------
>[ 602.536698] kworker/0:1/27 is trying to acquire lock:
>[ 602.536750] (&fb_info->lock){+.+.+.}, at: [<ffffffff814c0176>] lock_fb_info+0x26/0x60
>[ 602.536751]
>[ 602.536751] but task is already holding lock:
>[ 602.536773] (console_lock){+.+.+.}, at: [<ffffffff815a6a13>] console_callback+0x13/0x150
>[ 602.536774]
>[ 602.536774] which lock already depends on the new lock.
This does not look good but it does not like USB. It looks more like the
tty/fb area.
>Thanks,
>Fengguang
Sebastian