This patch adds support for the new udc-core reset notifier to the
net2272 driver.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
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>
This patch adds support for the new udc-core reset notifier to the
net2280 driver.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
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: Alan Stern <stern@rowland.harvard.edu>
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>
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>
Some mass storage devices return a bogus value in response to a Get Max LUN
request. The Iomega Jaz USB Adapter responds with 0x10, hence my recent
patch to use the US_FL_SINGLE_LUN quirk for it.
The USB MSC Bulk Only Transport document says "The device shall return one
byte of data that contains the maximum LUN supported by the device."
Since the LUN field in the command block wrapper is only 4 bits wide, it
might be helpful to report too-large LUN values in the kernel log, and
assume max LUN is actually 0. That could get some devices which currently
need the US_FL_SINGLE_LUN quirk to work.
Signed-off-by: Mark Knibbs <markk@clara.co.uk>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
as it turns out, at least AM437x silicon (non-FPGA)
needs to enable PHY suspend quirk. So let's allow
for PHY suspend quirk to be used with non-FPGA
builds too.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Make the hid function available for gadgets composed with configfs.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
