Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
SET_FEATURE request with DEBUG_MODE only worked the first time after module
initialisation. Per the USB 2.0 debug device specification, said request
is to be treated as if it were a SET_CONFIGURATION request, i.e. endpoint
must be re-configured.
As configure_endpoints() may now get called multiple times, move it outside
__init and move serial_alloc_tty() call into __init.
Code has assumption that endpoint mapping remains unchanged with consecutive
calls of configure_endpoints().
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The recent change bringing device-tree support triggers a warning in a
non device-tree build :
drivers/usb/gadget/udc/pxa27x_udc.c:2405:28: warning: 'udc_pxa_dt_ids'
defined but not used [-Wunused-variable]
Fix the warning with a preprocessor condition.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 6856d30 (usb: dwc3: ep0: return early
on NULL requests) tried to fix a minor corner
case where we could dereference a NULL pointer
but it also ended up introducing some dead code.
Unfortunately, that dead code, if reached, could
end up starving the endpoint request list because
a request would never be given back when it should.
Fix this by moving the check for empty request list
before its first use.
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The FUSBH200 debug port has a EHCI-compatible register layout so there
is no need to define a custom struct.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that ehci-dbgp has its own header, use it rather than duplicating
the declarations, etc.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The fotg210_dbg_port struct is a copy of the ehci_dbg_port definition
in the <linux/usb/ehci_def.h> header. Embedded in this definition are
a number of macros which came along for the ride. These macros are not
used in the fotg210 driver and will conflict those in the new
<linux/usb/ehci-dbgp.h> header.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If CONFIG_XEN_DOM0 is enabled, the ehci-dbgp driver notifies Xen of
controller reset events via xen_dbgp_reset_prep() and
xen_dbgp_external_startup() (via calls to xen_dbgp_op().) Otherwise
<linux/usb/ehci_def.h> defines them as no-ops to disable this logic.
The fotg210 driver copies much of the dbgp code from ehci_def.h, but it
unconditionally defines the Xen hooks as no-ops, effectively disabling
these notifications when CONFIG_EARLY_PRINTK_DBGP is disabled. When
enabled, though, notifying Xen is dependent on CONFIG_XEN_DOM0 due to
fotg210 leveraging the ehci-dbgp driver.
The following table compares the implementations of xen_dbgp_reset_prep()
and xen_dbgp_external_startup() in the ehci-dbgp and fotg210 drivers
under the relevant configurations:
EARLY_PRINTK_DBGP? XEN_DOM0? ehci-dbgp fotg210
------------------ --------- ------------- -------------
n n no-op no-op
n y xen_dbgp_op() no-op
y n no-op no-op
y y xen_dbgp_op() xen_dbgp_op()
This suggests that fotg210 is, at best, indifferent to whether Xen is
notified of these events. Make fotg210 consistent with ehci-dbgp as a
step towards consolidating this code duplication.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The FUSBH200 debug port has a EHCI-compatible register layout so there
is no need to define a custom struct.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that ehci-dbgp has its own header, use it rather than duplicating
the declarations, etc.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The fusbh200_dbg_port struct is a copy of the ehci_dbg_port definition
in the <linux/usb/ehci_def.h> header. Embedded in this definition are
a number of macros which came along for the ride. These macros are not
used in the fusbh200 driver and will conflict those in the new
<linux/usb/ehci-dbgp.h> header.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If CONFIG_XEN_DOM0 is enabled, the ehci-dbgp driver notifies Xen of
controller reset events via xen_dbgp_reset_prep() and
xen_dbgp_external_startup() (via calls to xen_dbgp_op().) Otherwise
<linux/usb/ehci_def.h> defines them as no-ops to disable this logic.
The fusbh200 driver copies much of the dbgp code from ehci_def.h, but it
unconditionally defines the Xen hooks as no-ops, effectively disabling
these notifications when CONFIG_EARLY_PRINTK_DBGP is disabled. When
enabled, though, notifying Xen is dependent on CONFIG_XEN_DOM0 due to
fusbh200 leveraging the ehci-dbgp driver.
The following table compares the implementations of xen_dbgp_reset_prep()
and xen_dbgp_external_startup() in the ehci-dbgp and fusbh200 drivers
under the relevant configurations:
EARLY_PRINTK_DBGP? XEN_DOM0? ehci-dbgp fusbh200
------------------ --------- ------------- -------------
n n no-op no-op
n y xen_dbgp_op() no-op
y n no-op no-op
y y xen_dbgp_op() xen_dbgp_op()
This suggests that fusbh200 is, at best, indifferent to whether Xen is
notified of these events. Make fusbh200 consistent with ehci-dbgp as a
step towards consolidating this code duplication.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
