| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Current usbhsx_for_each_xxx macro will read out-of-array's
memory after last loop operation.
It was not good C language operation, and the binary which was
compiled by (at least) gcc 4.8.1 is broken
This patch tidyup these issues
Reported-by: Yusuke Goda <[email protected]>
Reviewed-by: Takashi Yoshii <[email protected]>
Signed-off-by: Kuninori Morimoto <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Use a mapping table (dpll_map) to match the possible system clock rates
to the appropriate DPLL parameters.
Introduce a function "omap_usb3_get_dpll_params()" that will
return the matching DPLL parameters for the given clock rate.
Also, bail out on phy init if DPLL locking fails.
Signed-off-by: Roger Quadros <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
ehci-omap needs NOP_USB_XCEIV PHY driver to function
properly, so select it. As the USB PHY drivers no longer
depend on USB_PHY, it is safe to select the PHY drivers.
Signed-off-by: Roger Quadros <[email protected]>
Tested-by: Adrien Vergé <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Convert PHY Drivers from menuconfig to menu so that the PHY drivers
can be explicitely selected by the controller drivers.
USB_PHY is no longer a user visible option. It is upto to the PHY
drivers to select it if needed. This patch does so for the existing
PHY drivers that use the USB_PHY library.
Doing so moves the USB_PHY and PHY driver selection problem from the
end user to the PHY and controller driver developer.
e.g.
Earlier, a controller driver (e.g. EHCI_OMAP) that needs to select
a PHY driver (e.g. NOP_PHY) couldn't do so because the PHY driver
depended on USB_PHY. Making the controller driver depend on USB_PHY
has a negative effect i.e. it becomes invisible to the user till
USB_PHY is enabled. Most end users will not familiar with this.
With this patch, the end user just needs to select the controller driver
needed for his/her platform without worrying about which PHY driver to
select.
Also update USB_EHCI_MSM, USB_LPC32XX and USB_OMAP to not depend
on USB_PHY any more. They can safely select the necessary PHY drivers.
[ [email protected] : refreshed on top of my next branch. Changed bool
followed by default n into def_bool n ]
CC: Pavankumar Kondeti <[email protected]>
Acked-by: Roland Stigge <[email protected]>
Signed-off-by: Roger Quadros <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
before changing to configured state, we need
to wait until gadget driver has had a chance
to process the request.
In case of USB_GADGET_DELAYED_STATUS, that means
we need to defer usb_gadget_set_state() until
the upcoming usb_ep_queue().
Reported-by: Alan Stern <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
In case we're switching back to USB_STATE_ADDRESS
from USB_STATE_CONFIGURED (if host sends
a set configuration command for configuration
zero), we should only switch if the request
is successfully processed by the gadget driver.
Reported-by: Alan Stern <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
usb_gadget_set_state() will call sysfs_notify()
which might sleep. Some users might want to call
usb_gadget_set_state() from the very IRQ handler
which actually changes the gadget state.
Instead of having every UDC driver add their own
workqueue for such a simple notification, we're
adding it generically to our struct usb_gadget,
so the details are hidden from all UDC drivers.
Acked-by: Alan Stern <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Change intervall into interval.
Signed-off-by: Huang Rui <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
in order to make our IRQ handler thread easier
to read, we re-factor the inner loop to a separate
function.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
that function isn't really processing any event
buffer, rather just checking whether it contains
events to be processed.
Due to that reason, we're reaning it to dwc3_check_event_buf()
instead.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
We can make use of bit 31 of the GEVNTSIZ(n)
registers to mask/unmask interrupts from that
particular interrupter.
With that feature, we can easily drop IRQF_ONESHOT
from our driver which makes it possible to
properly change IRQ priorities when using RT
patchset *and* it allows us to make use of the
scheduler to choose the proper time to handle
this IRQ thread.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
That register has more than just the event buffer
size; we can also mask and unmask that particular
interrupter on bit 31 of that register.
In this patch we introduce the necessary macros
and make sure to use the new macros while also
making sure we mask interrupts during driver
removal.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
LPM is enabled in Connection Done interrupt,
there's no need to enable it early.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
the macro DWC3_DCFG_LPM_CAP was defined twice.
This patch just removes one of the definitions,
no functional changes.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
that way we get debugging information when
enabling verbose debug of the driver.
It will be no-op otherwise.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
no functional changes, just grouping dep
initialization.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
by moving that dev_vdbg() to the internal
__dwc3_gadget_ep_enable() we get the print
even when enable ep0, which calls the internal
function directly.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
use the new devm_ioremap_resource() on core.c
Signed-off-by: Felipe Balbi <[email protected]>
|
|
use the new devm_ioremap_resource on dwc3-omap.c
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Recent versions of the core, can suspend and resume
the PHYs automatically, so we don't need to fiddle
with dwc3's Global PHY registers at all.
On versions prior to 1.94a this patch will mean
that we will never ask dwc3 to suspend the PHY.
This is an acceptable behavior or such old versions
of the core, specially considering that the only
chip known to have a version prior to 1.94a was
OMAP5 ES1.0 and that's not supported in mainline
kernel, because it was just a test spin of OMAP5.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
This patch adapts the dwc3 to use the device tree helper
"of_usb_get_dr_mode" for the mode of operation of the dwc3 instance
being probed.
[ [email protected] : make of_usb_get_dr_mode() conditional on
dev->of_node and let pdata pass dr_mode too ]
Reviewed-by: Roger Quadros <[email protected]>
Signed-off-by: Ruchika Kharwar <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
stmp_reset_block() may fail, so let's check its return value and propagate it
in the case of error.
Acked-by: Shawn Guo <[email protected]>
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
The musb driver no longer uses procfs, so get rid of the proc_dir_entry
variable in struct musb.
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
This patch adds OF match table to the driver to allow instantiating it
using device tree.
Signed-off-by: Tomasz Figa <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
all other drivers using Synopsys IPs with DT
have a compatible of snps,$driver, in order
to add consistency, we are switching over to
snps,dwc3 but keeping synopsys,dwc3 in the core
driver to maintain backwards compatibility.
New DTS bindings should NOT use synopsys,dwc3.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
in order to allow different instances of the
core work in different maximum speeds, we will
move the maximum_speed module_parameter to
both DeviceTree (making use the new maximum-speed
DT property) and platform_data.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
in case we're not in a DT boot, we should
still be able to tell the driver how to behave.
In order to be able to pass flags to the driver,
we introduce platform_data structure which the
core driver should use.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
this helper will be used for controllers which
want to work at a lower speed even though they
support higher USB transfer rates.
One such case is Texas Instruments' AM437x
SoC where it uses a USB3 controller without
a USB3 PHY, rendering the controller USB2-only.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
This is a Linux-only driver which makes use
of GPL-only symbols. It makes no sense to
maintain Dual BSD/GPL licensing for this driver.
Considering that the amount of work to use this
driver in any different operating system would likely
be as large as developing the driver from scratch and
considering that we depend on GPL-only symbols, we
will switch over to a GPL v2-only license.
Cc: Anton Tikhomirov <[email protected]>
Acked-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
@list is not as a parameter of dwc3_event_buffer, so remove it in
comments.
Signed-off-by: Huang Rui <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
We cannot request an IRQ with spinlocks held
as that would trigger a sleeping inside
spinlock warning.
Cc: <[email protected]> # v3.10
Reported-by: Stephen Boyd <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
That driver hasn't been really maintained for
a long time. It doesn't compile in any way, it
includes non-existent headers, has no users,
and is just plain broken.
The person who used to work with that driver
has publicly stated that he has no plans to
touch that driver again and is ok with removal[1].
Due to these factors, imx_udc is now removed from
the tree, if someone really believe it needs to
be kept, please fix the bugs in that driver.
[1] http://marc.info/?l=linux-usb&m=136197620417636&w=2
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Glue layers are starting to have separate
requirements. For example, OMAP's glue layer
is starting to use extcon framework which
no one else needs.
In order to make it clear the proper dependencies,
we are now allowing glue layers to be selectable
so that each glue layer can list their own dependencies
without messing with the core IP driver.
Signed-off-by: Felipe Balbi <[email protected]>
|
|
If the descriptor is missing the reqeust is never unmapped. This patch
changes this and renames the cleanup label to unlock since there is no
cleanup done. The cleanup would revert the allocation of ressource (i.e.
this dma mapping) but it does not, it simply unlocks and returns.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
The cleanup in the error is missing the dma controller. The structure is
allocated at runtime and ux500 allocates even a little more than just
this struct. So cleanup!
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
This patch removes is_dma_capable() and an ifdef in the init/exit path
around init/de-init of the dma_controller. Since we have the empty stubs
in the PIO code we can call it without gcc trouble. Earlier we had an
ifdef and the is_dma_capable() macro where gcc ignored the if (0) path
even that the function was not around :)
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Add a dma_controller_create() returning NULL so a few ifdefs can
dropped.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
The core code creates a controller and immediately after that it calls
the ->start() callback. This one might drop an error but nobody cares.
The same thing happens in the destroy corner: First ->stop() called
followed by destroy callback. So why not merge those two into the same
function since there is no difference.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
This check is hardly required and alas is wrong. 'c' might be NULL but
the chances are low that 'controller' after the container_of() becomes
NULL.
Since no other DMA implementation is doing that and musb-core does not
call it with a NULL pointer it can dropped.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
The ifdef reads somehow better than an ifndef
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Silence compiler warnings on 64-bit systems introduced by commit
05cf0dec ("USB: mos7840: fix race in led handling") which uses the
usb-serial data pointer to temporarily store the device type during
probe but failed to add the required casts.
[gregkh - change uintptr_t to unsigned long]
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Fix race in LED handling introduced by commit 0eafe4de ("USB: serial:
mos7840: add support for MCS7810 devices") which reused the port control
urb for manipulating the LED without making sure that the urb is not
already in use. This could lead to the control urb being manipulated
while in flight.
Fix by adding a dedicated LED urb and ctrlrequest along with a LED-busy
flag to handle concurrency.
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Fix race in device-type detection introduced by commit 0eafe4de ("USB:
serial: mos7840: add support for MCS7810 devices") which used a static
variable to hold the device type.
Move type detection to probe and use serial data to store the device
type.
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Fix race in mos7840_get_reg which unconditionally manipulated the
control urb (which may already be in use) by adding a control-urb busy
flag.
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
This adds a driver for the Suunto ANT+ USB device, exposing it as a usb
serial device. This lets the userspace "gant" program to talk to the
device to communicate over the ANT+ protocol to any devices it finds.
Reported-by: Steinar Gunderson <[email protected]>
Tested-by: Steinar Gunderson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
When ohci-hcd is shutting down, call ohci_usb_reset reset ohci-hcd, the
root hub generate an interrupt, but ohci->rh_state is OHCI_RH_HALTED,
and ohci_irq ignore the interrupt, the kernel trigger warning "irq
nobody cared". ehci-hcd is first disable interrupts, then reset ehci.
This patch disable ohci interrupt before reset ohci.
The patch is tested at the arm cortex-a9 demo board.
Signed-off-by: caizhiyong <[email protected]>
Reviewed-by: Alan Stern <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
commit 57f6ce072e35770a63be0c5d5e82f90d8da7d665 ("usb: phy:
add a new driver for usb3 phy") added the new Kconfig option
OMAP_USB3, but it had no dependencies whatsoever, and hence
became available across all arch/platforms.
Which presumably caused this to show up in x86 randconfig:
warning: (USB_MUSB_HDRC && OMAP_USB3) selects \
OMAP_CONTROL_USB which has unmet direct \
dependencies (USB_SUPPORT && ARCH_OMAP2PLUS)
Then commit 6992819feb39cb9adac72170555d957d07f869f2 ("usb: phy:
fix Kconfig warning") was added. However, this just deleted the
ARCH_OMAP2PLUS dependency from OMAP_CONTROL_USB, further
compounding the problem by opening up OMAP_CONTROL_USB to
all arch/platforms as well.
Earlier it was suggested[1] that we revert the change of 6992819feb
to restore the dependency, and add a same ARCH_OMAP2PLUS dependency
to the new OMAP_USB3 entry. However that was discouraged on the
grounds of people wanting the extra sanity compile testing on x86,
even though the driver could probably never be used there.
Now we have CONFIG_COMPILE_TEST, so developers who value the ability
to compile drivers on an architecture that it never can be used for
can have that, and people who want dependencies to shield them from
seeing options that aren't relevant to their platform get what they
want too.
Here we restore the dependency but couple it with COMPILE_TEST, in
order to achieve both of the above goals.
[1] https://patchwork.kernel.org/patch/2194511/
Acked-by: Felipe Balbi <[email protected]>
Cc: Kishon Vijay Abraham I <[email protected]>
Cc: Moiz Sonasath <[email protected]>
Cc: Jiri Slaby <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Merge the usb_hcd_ep93xx_probe() into ohci_hcd_ep93xx_drv_probe() and
the usb_hcd_ep93xx_remove() into ohci_hcd_ep93xx_drv_remove(). As Alan
Stern pointed out, there is no reason for them to be separate.
Also, as Alan Stern suggested, eliminate the ep93xx_start_hc() and
ep93xx_stop_hc() routines and simply call clk_enable() and clk_disable()
directly. The extra level of redirection does not add any clarity.
Signed-off-by: H Hartley Sweeten <[email protected]>
Acked-by: Alan Stern <[email protected]>
Cc: Lennert Buytenhek <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Use devm_clk_get() to make the code a bit cleaner and simpler.
This also fixes a bug where a clk_put() is not done if usb_add_hcd()
fails.
Signed-off-by: H Hartley Sweeten <[email protected]>
Acked-by: Alan Stern <[email protected]>
Cc: Lennert Buytenhek <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Use platform_get_irq() instead of accessing the platform_device
resources directly.
Signed-off-by: H Hartley Sweeten <[email protected]>
Acked-by: Alan Stern <[email protected]>
Cc: Lennert Buytenhek <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|