The Tegra30 I2S driver was writing the AHUB interface parameters to the
playback path register rather than the capture path register. This
caused the capture parameters not to be configured at all, so if
capturing using non-HW-default parameters (e.g. 16-bit stereo rather
than 8-bit mono) the audio would be corrupted.
With this fixed, audio capture from an analog microphone works correctly
on the Cardhu board.
Cc: [email protected]
Signed-off-by: Stephen Warren <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
commit 56b765b79 ("htb: improved accuracy at high rates")
broke the "linklayer atm" handling.
tc class add ... htb rate X ceil Y linklayer atm
The linklayer setting is implemented by modifying the rate table
which is send to the kernel. No direct parameter were
transferred to the kernel indicating the linklayer setting.
The commit 56b765b79 ("htb: improved accuracy at high rates")
removed the use of the rate table system.
To keep compatible with older iproute2 utils, this patch detects
the linklayer by parsing the rate table. It also supports future
versions of iproute2 to send this linklayer parameter to the
kernel directly. This is done by using the __reserved field in
struct tc_ratespec, to convey the choosen linklayer option, but
only using the lower 4 bits of this field.
Linklayer detection is limited to speeds below 100Mbit/s, because
at high rates the rtab is gets too inaccurate, so bad that
several fields contain the same values, this resembling the ATM
detect. Fields even start to contain "0" time to send, e.g. at
1000Mbit/s sending a 96 bytes packet cost "0", thus the rtab have
been more broken than we first realized.
Signed-off-by: Jesper Dangaard Brouer <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Jesse Gross says:
====================
Three bug fixes that are fairly small either way but resolve obviously
incorrect code. For net/3.11.
====================
Signed-off-by: David S. Miller <[email protected]>
Drivers supporting NAPI should use a NAPI-specific function for receiving
packets. Hence netif_rx is changed to netif_receive_skb.
Furthermore netif_napi_del should be used in the probe and remove function
to clean up the NAPI resource information.
Thanks to Francois Romieu, David Shwatrz and Rami Rosen for their help on
this patch.
Signed-off-by: Julia Lawall <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
It is possible for some versions of firmware to advertise capabilities that driver
is not ready to handle. This may lead to controller stall. Since the driver is
interested only in subset of flags, clearing the rest.
Signed-off-by: Sarveshwar Bandi <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
It doesn't make sense to output a tunnel packet using the same
parameters that it was received with since that will generally
just result in the packet going back to us. As a result, userspace
assumes that the tunnel key is cleared when transitioning through
the switch. In the majority of cases this doesn't matter since a
packet is either going to a tunnel port (in which the key is
overwritten with new values) or to a non-tunnel port (in which
case the key is ignored). However, it's theoreticaly possible that
userspace could rely on the documented behavior, so this corrects
it.
Signed-off-by: Jesse Gross <[email protected]>
Flex array is used to allocate hash buckets which is type struct
hlist_head, but we use `struct hlist_head *` to calculate
array size. Since hlist_head is of size pointer it works fine.
Following patch use correct type.
Signed-off-by: Pravin B Shelar <[email protected]>
Signed-off-by: Jesse Gross <[email protected]>
git silently included an extra hunk in vport_cmd_set() during
automatic merging. This code is unreachable so it does not actually
introduce a problem but it is clearly incorrect.
Signed-off-by: Jesse Gross <[email protected]>
Make sure the USB control request is allocated separately from
containing structure to prevent potential memory corruption on
non-cache-coherent systems.
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Make sure port DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Make sure to fail properly if the device is not accepted during attach
in order to avoid null-pointer derefs (of missing interface private
data) at disconnect or release.
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The parallel-port code of the drivers used a stack allocated
control-request buffer for asynchronous (and possibly deferred) control
requests. This not only violates the no-DMA-from-stack requirement but
could also lead to corrupt control requests being submitted.
Cc: [email protected]
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The chipidea i.MX driver is split into two drivers. The ci_hdrc_imx driver
handles the chipidea cores and the usbmisc_imx driver handles the noncore
registers common to all chipidea cores (but SoC specific). Current flow is:
- usbmisc sets an ops pointer in the ci_hdrc_imx driver during probe
- ci_hdrc_imx checks if the pointer is valid during probe, if yes calls
the functions in the ops pointer.
- usbmisc_imx calls back into the ci_hdrc_imx driver to get additional
data
This is overly complicated and has problems if the drivers are compiled
as modules. In this case the usbmisc_imx driver can be unloaded even if
the ci_hdrc_imx driver still needs usbmisc functionality.
This patch changes this by letting the ci_hdrc_imx driver calling functions
from the usbmisc_imx driver. This way the symbol resolving during module
load makes sure the ci_hdrc_imx driver depends on the usbmisc_imx driver.
Also instead of letting the usbmisc_imx driver call back into the ci_hdrc_imx
driver, pass the needed data in the first place.
Signed-off-by: Sascha Hauer <[email protected]>
Acked-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
For chipidea, the IP must know vbus before the controller
begins to run. So the .pullup should only be called when
the vbus is there.
Tested-by: Marek Vasut <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Currently, the controller only runs when the ci->vbus_active is true.
So the flag CI_HDRC_PULLUP_ON_VBUS is useless no longer.
If the user doesn't have otgsc, he/she needs to change ci_handle_vbus_change
to update ci->vbus_active.
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
CI_HDRC_REGS_SHARED stands for the controller registers is shared
with other USB drivers, if all USB drivers are at chipidea/, it doesn't
needed to be set.
CI_HDRC_PULLUP_ON_VBUS stands for pullup dp when the vbus is on. This
flag doesn't need to be set if the vbus is always on for gadget
since dp has always pulled up after the gadget has initialized.
So, the current code seems to misuse this two flags.
- When the gadget initializes, the controller doesn't need to run if
it depends on vbus (CI_HDRC_PULLUP_ON_VBUS), it does not relate to
shared register.
- When the gadget starts (load one gadget module), the controller
can run if vbus is on (CI_HDRC_PULLUP_ON_VBUS), it also does not
relate to shared register.
Tested-by: Marek Vasut <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
When the gadget role starts, we need to make sure the vbus is lower
than OTGSC_BSV, or there will be an vbus interrupt since we use
B_SESSION_VALID as vbus interrupt to indicate connect and disconnect.
When the host role starts, it may not be useful to wait vbus to lower
than OTGSC_BSV, but it can indicate some hardware problems like the
vbus is still higher than OTGSC_BSV after we disconnect to host some
time later (5000 milliseconds currently), which is obvious not correct.
Tested-by: Marek Vasut <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
We add vbus interrupt handler at ci_otg_work, it uses OTGSC_BSV(at otgsc)
to know it is connect or disconnet event.
Meanwhile, we introduce two flags id_event and b_sess_valid_event to
indicate it is an id interrupt or a vbus interrupt.
Tested-by: Marek Vasut <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
During the initialization, it needs to disable all interrupts
enable bit as well as clear all interrupts status bits to avoid
exceptional interrupt.
Tested-by: Marek Vasut <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Since we need otgsc to know vbus's status at some chipidea
controllers even it is peripheral-only mode. Besides, some
SoCs (eg, AR9331 SoC) don't have otgsc register even
the DCCPARAMS_DC and DCCPARAMS_HC are both 1 at CAP_DCCPARAMS.
We inroduce flag CI_HDRC_DUAL_ROLE_NOT_OTG to indicate if the
controller is dual role, but not supports OTG. If this flag is
not set, we follow the rule that if DCCPARAMS_DC and DCCPARAMS_HC
are both 1 at CAP_DCCPARAMS, then this controller is otg capable.
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
- The role's init will be called at probe procedure.
- The role's destroy will be called at fail patch
at probe and driver's removal.
- The role's start/stop will be called when specific
role has started.
Tested-by: Marek Vasut <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
This file is mainly used to access otgsc currently, it may
add otg related things in the future.
Tested-by: Marek Vasut <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
It is useless at below cases:
- If we implement both usb host and device at chipidea driver.
- If we don't need phy->otg.
Tested-by: Marek Vasut <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
For boards which have board level vbus control (eg, through gpio), we
need to vbus operation according to below rules:
- For host, we need open vbus before start hcd, and close it
after remove hcd.
- For otg, the vbus needs to be on/off when usb role switches.
When the host roles begins, it opens vbus; when the host role
finishes, it closes vbus.
We put vbus operation to host as host is the only vbus user,
When we are at host mode, the vbus is on, when we are not at
host mode, vbus should be off.
Tested-by: Marek Vasut <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The vbus regulator is a common element for USB vbus operation,
So, move it from glue layer to core.
Tested-by: Marek Vasut <[email protected]>
Signed-off-by: Michael Grzeschik <[email protected]>
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
After the rename to ci_hdrc we ended up with two MODULE_ALIAS entries, so
remove the old one.
Signed-off-by: Fabio Estevam <[email protected]>
Reviewed-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Commit 40dcd0e ("usb: chipidea: add PTW, PTS and STS handling") introduced
the following code to the ci_hdrc_probe() function:
+ if (!dev->of_node && dev->parent)
+ dev->of_node = dev->parent->of_node;
This inadvertently associates the ci_hdrc device with the ci_hdrc_imx
driver (which created the ci_hdrc device in the first place).
This results in ci_hdrc_imx_probe() being run for the ci_hdrc device
if ci_hdrc_probe() fails for some reason.
ci_hdrc_imx_probe() will happily create a new ci_hdrc platform_device
whose probing will likewise fail and trigger a new invocation of
ci_hdrc_imx_probe() ... ad nauseam.
Signed-off-by: Lothar Waßmann <[email protected]>
Reviewed-and-tested-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
If a role fails to start, propagate the error code up the call stack
from probe.
Signed-off-by: Lothar Waßmann <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
This prevents the USB PHY refcount to be decremented below zero upon
unloading the ci-hdrc-imx module.
Signed-off-by: Lothar Waßmann <[email protected]>
Acked-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
This patch provides a cleaner solution to the problem described in
commit 20a677fd ("usb: chipidea: improve kconfig").
The goal to be achieved is to force USB_CHIPIDEA=m if either
USB_EHCI_HCD=m or USB_GADGET=m.
If both are 'y' USB_CHIPIDEA may be selected to be 'm' or 'y'.
The old patch had the drawback, that USB_CHIPIDEA could be chosen as
'y' though USB_EHCI_HCD or USB_GADGET (or both) were 'm' leading to a
situation where USB_CHIPIDEA_HOST or USB_CHIPIDEA_UDC vanished from
the config options producing a compilable but dysfunctional driver.
Signed-off-by: Lothar Waßmann <[email protected]>
Reviewed-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Remove an unused macro leftover from the old initialization code.
Signed-off-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Currently hw_phymode_configure() is located inside hw_device_reset(), which is
only called by chipidea udc driver.
When operating in host mode, we also need to call hw_phymode_configure() in
order to properly configure the PHY mode, so move this function into probe.
After this change, USB Host1 port on mx53qsb board is functional.
Signed-off-by: Fabio Estevam <[email protected]>
Tested-by: Arnaud Patard <[email protected]>
Reviewed-by: Peter Chen <[email protected]>
Signed-off-by: Alexander Shishkin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
if pdata is a NULL pointer we could cause a
kernel oops when probing the driver. Make sure
to cope with systems which won't pass pdata
to the driver.
Tested-by: Paul Zimmerman <[email protected]>
Reported-by: Paul Zimmerman <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
rh_call_control() contains a buffer, tbuf, which it uses to hold
USB descriptors. These discriptors are eventually copied into the
transfer_buffer in the URB. The buffer in the URB is dynamically
defined and is always large enough to hold the amount of data it
requests.
tbuf is currently statically allocated on the stack with a size
of 15 bytes, regardless of the size specified in the URB.
This patch dynamically allocates tbuf, and ensures that tbuf is
at least as big as the buffer in the URB.
If an hcd attempts to write a descriptor containing more than
15 bytes ( such as the Standard BOS Descriptor for hubs, defined
in the USB3.0 Spec, section 10.13.1 ) the write would overflow
the buffer and corrupt the stack. This patch addresses this
behavior.
Acked-by: Alan Stern <[email protected]>
Signed-off-by: Sean O. Stalley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 9841f37a1c ("usb: ehci: Add support for SINGLE_STEP_SET_FEATURE
test of EHSET") added additional code to the EHCI hub driver but it is
anticipated to only have a limited audience (e.g. embedded silicon
vendors and integrators). Avoid subjecting all EHCI (and in the future
maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally
compiling the EHSET-specific additions with a new Kconfig option,
CONFIG_USB_HCD_TEST_MODE.
Signed-off-by: Jack Pham <[email protected]>
Acked-by: Alan Stern <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The driver currently knows about 3 different PL2303 chip types:
The two legacy chip types type_0 and type_1 (PL2303H ?) and the HX
type.
The device distinction is currently completely based on the examination
of the USB descriptors.
During the last years, Prolific has introduced further PL2303 chips,
such as the HXD (HX rev. D), TA (which replaced the X/HX chips), SA,
RA, EA and TB variants.
Unfortunately, all these new chips are currently detected as HX chips,
because they are all using the same bMaxPacketSize0 = 0x40 value in the
USB device descriptor.
At this point it is not clear if these chips are really working with
the driver, there are just some positive indicators (like device
manufacturers claiming Linux support for these devices or commit
8d48fdf689 "correctly handle baudrates above 115200" which should only
be necessary for newer devices, ...)
For a complete support of all devices, we need to distinguish between
them, because they differ in several functional aspects, such as the
maximum supported baud rate (HXD, TB, EA: 12Mbps, HX, TA: 6Mbps,
RA: 1Mbps, SA: 115.2kbps), handshaking line support, RS422/485 and
GPIO ports support (currently not supported by the driver).
And there might be further differences that we don't know yet.
This patch improves the chip type detection by evaluating the bcdDevice
value of the device descriptor. The values are taken from the
datasheets and are safe to use because manufacturers can't change them:
3.00: X/HX, TA
4.00: HXD, EA, RA, SA
5.00: TB
The rest of the device descriptors is completely identical, so no
further distinction is possible this way.
Anyway, Prolifics "checkChipVersion.exe"-tool is definitely able to
distinguish for example between the X/HX and the TA chips, so there
must be a possibility to improve the distinction further...
Signed-off-by: Frank Schäfer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The chip type distinction is getting more and more relevant and
complicating, so always print the chip type.
Printing a name string is also much better than just printing an
internal index number.
Signed-off-by: Frank Schäfer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
There is no need for two else-if constructs for the type_1 chip
detection in pl2303_startup(), so merge them.
Signed-off-by: Frank Schäfer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Merge a bunch of fixes from Andrew Morton.
* emailed patches from Andrew Morton <[email protected]>:
fs/proc/task_mmu.c: fix buffer overflow in add_page_map()
arch: *: Kconfig: add "kernel/Kconfig.freezer" to "arch/*/Kconfig"
ocfs2: fix null pointer dereference in ocfs2_dir_foreach_blk_id()
x86 get_unmapped_area(): use proper mmap base for bottom-up direction
ocfs2: fix NULL pointer dereference in ocfs2_duplicate_clusters_by_page
ocfs2: Revert 40bd62e to avoid regression in extended allocation
drivers/rtc/rtc-stmp3xxx.c: provide timeout for potentially endless loop polling a HW bit
hugetlb: fix lockdep splat caused by pmd sharing
aoe: adjust ref of head for compound page tails
microblaze: fix clone syscall
mm: save soft-dirty bits on file pages
mm: save soft-dirty bits on swapped pages
memcg: don't initialize kmem-cache destroying work for root caches
Explicitly truncate the second operand of do_div() to 32 bits to guard
against bogus code calling it with a 64-bit divisor.
[Thorsten]
After upgrading from 3.2 to 3.10, mounting a btrfs volume fails with:
btrfs: setting nodatacow, compression disabled
btrfs: enabling auto recovery
btrfs: disk space caching is enabled
*** ZERO DIVIDE *** FORMAT=2
Current process id is 722
BAD KERNEL TRAP: 00000000
Modules linked in: evdev mac_hid ext4 crc16 jbd2 mbcache btrfs xor lzo_compress zlib_deflate raid6_pq crc32c libcrc32c
PC: [<319535b2>] __btrfs_map_block+0x11c/0x119a [btrfs]
SR: 2000 SP: 30c1fab4 a2: 30f0faf0
d0: 00000000 d1: 00001000 d2: 00000000 d3: 00000000
d4: 00010000 d5: 00000000 a0: 3085c72c a1: 3085c72c
Process mount (pid: 722, task=30f0faf0)
Frame format=2 instr addr=319535ae
Stack from 30c1faec:
00000000 00000020 00000000 00001000 00000000 01401000 30253928 300ffc00
00a843ac 3026f640 00000000 00010000 0009e250 00d106c0 00011220 00000000
00001000 301c6830 0009e32a 000000ff 00000009 3085c72c 00000000 00000000
30c1fd14 00000000 00000020 00000000 30c1fd14 0009e26c 00000020 00000003
00000000 0009dd8a 300b0b6c 30253928 00a843ac 00001000 00000000 00000000
0000a008 3194e76a 30253928 00a843ac 00001000 00000000 00000000 00000002
Call Trace: [<00001000>] kernel_pg_dir+0x0/0x1000
[...]
Code: 222e ff74 2a2e ff5c 2c2e ff60 4c45 1402 <2d40> ff64 2d41 ff68 2205 4c2e 1800 ff68 4c04 0800 2041 d1c0 2206 4c2e 1400 ff68
[Geert]
As diagnosed by Andreas, fs/btrfs/volumes.c:__btrfs_map_block()
calls
do_div(stripe_nr, stripe_len);
with stripe_len u64, while do_div() assumes the divisor is a 32-bit number.
Due to the lack of truncation in the m68k-specific implementation of
do_div(), the division is performed using the upper 32-bit word of
stripe_len, which is zero.
This was introduced by commit 53b381b3ab
("Btrfs: RAID5 and RAID6"), which changed the divisor from
map->stripe_len (struct map_lookup.stripe_len is int) to a 64-bit temporary.
Reported-by: Thorsten Glaser <[email protected]>
Signed-off-by: Andreas Schwab <[email protected]>
Tested-by: Thorsten Glaser <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Cc: [email protected]
As pointed out by Andreas Schwab, pointers passed to ARAnyM NatFeat calls
should be physical addresses, not virtual addresses.
Fortunately on Atari, physical and virtual kernel addresses are the same,
as long as normal kernel memory is concerned, so this usually worked fine
without conversion.
But for modules, pointers to literal strings are located in vmalloc()ed
memory. Depending on the version of ARAnyM, this causes the nf_get_id()
call to just fail, or worse, crash ARAnyM itself with e.g.
Gotcha! Illegal memory access. Atari PC = $968c
This is a big issue for distro kernels, who want to have all drivers as
loadable modules in an initrd.
Add a wrapper for nf_get_id() that copies the literal to the stack to
work around this issue.
Reported-by: Thorsten Glaser <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Cc: [email protected]
