Small pull request this time containing only 3 patches.
One patch is fixing at91 resource retrieval, one fixes a
conditional in the generic OTG FSM and another fixes a
state transition also on our generic OTG FSM.
Signed-of-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTYS5/AAoJEIaOsuA1yqREe18P/2eVLHvG7f6zNV1F1bYlvYqB
smdL3u43G0DfQ1t0K3FY27c/r1T7/IwVg6pXN/cKtpV7cnYX6SoC4rM9Dl8L9A/w
goGVMCG61P1qEOF1yNn1szTHe8eO8YH9xmhIZbRnCA3h39epruMnYZk7mg++sVun
WTDmDPfsIfSHKoGhkFXIJhAXGfq/Ni9BAgYWfWmjNgXN4JE2lmhTgP5OAnJRq4rJ
C8kTyt4PSm8zJxggpoC8en1unE45DLBxXjNc71hYwXUq9xWx/MH9L4lHJ2qitPMp
wVrj65bXwrPMv59+c3FwYHiT9IGKXT//+Se/BkT68KRH64kb/XG6lapSD799Lw2t
f405eqjzGjpotvf/UFtWbgnQHar6dI1mBfLgboXxZlVnMVkPXqy++XKHfvMGNnRY
VRUCKz/2i7iZl5bcgRd8nI6C65rIcpCdcVW23nzABVBI/9MEh53FhrWVcui16O/X
sD0pxZmQF9+Wv9OS7Z4fxDuwObcWdMlLHvCTlgKC/bAJ5jSTis6Grw0TFyYsrkAO
TlJq6gK+vcRo38mZsQQf4ovHMvgZJmDjqFpAhEj03GRNio1adgMa6TOD4qs+ll6T
IsEVUZBn9Q1m4lSSSdadLBEhsK7Gc/dDu2uQ/WMwT7WB0A4H7lsmK6XQ3QHVsaTR
ADt2zXWCRx9j37ewIIi1
=AEqv
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v3.15-rc4
Small pull request this time containing only 3 patches.
One patch is fixing at91 resource retrieval, one fixes a
conditional in the generic OTG FSM and another fixes a
state transition also on our generic OTG FSM.
Signed-of-by: Felipe Balbi <balbi@ti.com>
Commit 2ee57d5873 ("dm cache: add passthrough mode") inadvertently
removed the deferred set reference that was taken in cache_map()'s
writethrough mode support. Restore taking this reference.
This issue was found with code inspection.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
Cc: stable@vger.kernel.org # 3.13+
- Signedness bug in the TB10x
- GPIO inversion fix for the AS3722
- Clear pending pin interrups enabled in the bootloader in the
pinctrl-single driver
- Minor pin definition fixes for the PFC/Renesas driver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTYTNSAAoJEEEQszewGV1zQCMQAJiLlixT5DlBl1vjOueao7tt
05JJi0NtBCMWMoJAOvk9RdEKBgFuMN4uv7oac3o10UnB3j6/7R1AjNjw2qZWPISV
FoJJOCOiVd9GmLNXyFX8VKiuU1udszqS78OUxAsuRd18xO7qKPPjAR9Oxyok4LBm
rBYTXMi52u+/uOrZ3TutqaS0HmoUnb3S0D2o2U59hInZcYDJcD5MogeHZbiy7L13
fyOo9m1UopeLF0DhzvgcQUjF+ZzPfXYbkowGDkNIZ0jruo2/oQvSBZ7g2F1qrEIx
4+Vn0n0ODotsqB7OT2IueuP+1eJaY1uvUAGQWxagoARiWndGfgX9dyRbNL4LevZT
64d+5ggRRgbXLikYtn1XqE2wu3f76kJlbmTMjEOD4iGfyHl9eG2sIDBfxaaMTzfU
zLrkFwL70HuBzkL/KaBbFnXmlpcbAhcQ5XGQH0hXn01vn19K2UVFNtZpKosByKji
urL7h7Gmi/uWNw6wIC4MC58zZrFImCUKWnoabX9L8p7OYiEcdDTcCl0rZLr7AbXS
qTiTb9+/92yNLZI4kxYtuTZBF48CbfNV8ZkTrxSm0lckUDVOw7JidTEVVLtNJbT5
cK8tfXOvm5WEyL0QA6RhA++Cn8jCJe/rv/q1w/YYaCwDakVHu2Ur6bH8dBcCamIv
yryVMnUMHYxHD9IauZa/
=uhce
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v3.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Here is a small set of pin control fixes for the v3.15 series. All
are individual driver fixes and quite self-contained. One of them
tagged for stable.
- Signedness bug in the TB10x
- GPIO inversion fix for the AS3722
- Clear pending pin interrups enabled in the bootloader in the
pinctrl-single driver
- Minor pin definition fixes for the PFC/Renesas driver"
* tag 'pinctrl-v3.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
sh-pfc: r8a7791: Fix definition of MOD_SEL3
sh-pfc: r8a7790: Fix definition of IPSR5
pinctrl: single: Clear pin interrupts enabled by bootloader
pinctrl: as3722: fix handling of GPIO invert bit
pinctrl/TB10x: Fix signedness bug
This reverts commit 9fb6c9c73b.
Tjmax on some Intel CPUs is below 85 degrees C. One known example is
L5630 with Tjmax of 71 degrees C. There are other Xeon processors with
Tjmax of 70 or 80 degrees C. Also, the Intel IA32 System Programming
document states that the temperature target is in bits 23:16 of MSR 0x1a2
(MSR_TEMPERATURE_TARGET), which is 8 bits, not 7.
So even if turbostat uses similar checks to validate Tjmax, there is no
evidence that the checks are actually required. On the contrary, the
checks are known to cause problems and therefore need to be removed.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75071.
Fixes: 9fb6c9c hwmon: (coretemp) Refine TjMax detection
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
According commit d640113fe (ACPI: processor: fix acpi_get_cpuid for UP
processor), BIOS may not provide _MAT or MADT tables and acpi_get_apicid()
always returns -1. For these cases, original code will pass apic_id with
vaule of -1 to acpi_map_cpuid() and it will check the acpi_id. If acpi_id
is equal to zero, ignores apic_id and return zero for CPU0.
Commit b981513 (ACPI / scan: bail out early if failed to parse APIC
ID for CPU) changed the behavior. Return ENODEV when find apic_id is
less than zero after calling acpi_get_apicid(). This causes acpi-cpufreq
driver fails to be loaded on some machines. This patch is to fix it.
Fixes: b981513f80 (ACPI / scan: bail out early if failed to parse APIC ID for CPU)
References: https://bugzilla.kernel.org/show_bug.cgi?id=73781
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Reported-and-tested-by: KATO Hiroshi <katoh@mikage.ne.jp>
Reported-and-tested-by: Stuart Foster <smf.linux@ntlworld.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ad2s1200 - Fix some missing parenthesis in a for statement that could have
led to an error being missed when getting gpios.
* Fix a null derefference issue in the mpu6050 when platform data is not
provided (or is provided via the device tree for example).
* exynos_adc bug on remove due to child devices having been added to the
parent of the IIO device rather than the IIO device itself. This caused an
issue with the IIO device removing itself in it's remove function.
* Make all ADC drivers buildable as modules to avoid dependency issues if
the IIO core is itself built as a module. The exynos adc bug became
apparently whilst this fix was being tested.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTW8mSAAoJEFSFNJnE9BaI9jsP/AlX5/G8f5jynM1C0WNQ3WaA
EigVPSWbZgIUaPoMCULNTFoKCB/o76ecR83t+q8+b/2i/wyTdvI+5nmDhR5kH/mN
m5nRHjYT3mv2u8WnXQgoY7LtcaGDPFEG8TgykXCq4e6OeEa5rpCjeDcVWe6ogT2i
jtrgOLvbW+y99GY8nGng5B3vqPyQoQQxiZBVvHstRlSFJbyRD2PaCsoWlu5ap1c1
xbuVf2T48rfTskqZK8gzlGeXszZsrGeU4UZBCBMxIfG3Q5KtOtMj1FgfNBr/Dwgp
AgYwY7x5V7CV3pucMBB7ZES8NPjXh3POQhrx9ZWWHZzMAMDjlbTDjUQFSZHiT1MO
tfh9B3aGNxpWJ/wv23wPlyFSQ8/ffTWA6v8VlxkItrwJa5123FdDPRsHvn4cTAJe
LHNeERlRYJbOZd+iPyojObwpU7le4f/yk2heb45TlRmb5vAuJd7VWDXkjO3XRZJB
ya1gYUEbC+XF8gnFSrEOLI7RTYUcBIB216PPODP3jh4Ui32lfDgGvqr2QSy5XMZF
JK8SChrVw/OhC8th+/qOKGmSnjxfVx1IndpzdnrCD5c6B3YeFKkk7dzwBLIMXubW
MOcVguVOZawgtodff48uoCQ9EJlvVpSWf6ps/oWdYDIp0zur50lFokixIggUYQc0
WYiQk6D+Lovmb9x9BYms
=qTIz
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-3.15b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
Second set of fixes for IIO in the 3.15 cycle.
* ad2s1200 - Fix some missing parenthesis in a for statement that could have
led to an error being missed when getting gpios.
* Fix a null derefference issue in the mpu6050 when platform data is not
provided (or is provided via the device tree for example).
* exynos_adc bug on remove due to child devices having been added to the
parent of the IIO device rather than the IIO device itself. This caused an
issue with the IIO device removing itself in it's remove function.
* Make all ADC drivers buildable as modules to avoid dependency issues if
the IIO core is itself built as a module. The exynos adc bug became
apparently whilst this fix was being tested.
The ACPI PNP subsystem returns errors from pnpacpi_set_resources()
and pnpacpi_disable_resources() if the _SRS or _DIS methods are not
present, respectively, but it should not do that, because those
methods are optional. For this reason, modify pnpacpi_set_resources()
and pnpacpi_disable_resources(), respectively, to ignore missing _SRS
or _DIS.
This problem has been uncovered by commit 202317a573 (ACPI / scan:
Add acpi_device objects for all device nodes in the namespace) and
manifested itself by causing serial port suspend to fail on some
systems.
Fixes: 202317a573 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
References: https://bugzilla.kernel.org/show_bug.cgi?id=74371
Reported-by: wxg4net <wxg4net@gmail.com>
Reported-and-tested-by: <nonproffessional@gmail.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Do checksum offload only if the client of the driver wants checksum to be
offloaded.
In V1 version of this patch, I addressed comments from
Stephen Hemminger <stephen@networkplumber.org> and
Eric Dumazet <eric.dumazet@gmail.com>.
In this version of the patch I have addressed comments from
David Miller.
This patch fixes a bug that is exposed in gateway scenarios.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For phy devices that don't issue interrupts upon link
state changes, phylib polls the link state resulting in
repeated calls to adjust_link(), even if the link state
didn't change. As a result, some mac registers are
repeatedly read and written with the same values, which
is not ok.
To fix this, adjust_link() has been refactored to check
first whether the link state has changed and to take action
only if needed, updating mac registers and local state
variables. The 'new_state' local flag, set if one of the
link params changed (link, speed or duplex), has been
rendered useless and removed by this refactoring.
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit 12a2856b60.
The commit above doesn't appear to be necessary any more as the
checksums appear to be correctly computed/validated.
Additionally the above commit breaks kvm configurations where
one VM is using a device that support checksum offload (virtio) and
the other VM does not.
In this case, packets leaving virtio device will have CHECKSUM_PARTIAL
set. The packets is forwarded to a macvtap that has offload features
turned off. Since we use CHECKSUM_UNNECESSARY, the host does does not
update the checksum and thus a bad checksum is passed up to
the guest.
CC: Daniel Lezcano <daniel.lezcano@free.fr>
CC: Patrick McHardy <kaber@trash.net>
CC: Andrian Nord <nightnord@gmail.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
CC: Michael S. Tsirkin <mst@redhat.com>
CC: Jason Wang <jasowang@redhat.com>
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The following is a problematic configuration:
VM1: virtio-net device connected to macvtap0@eth0
VM2: e1000 device connect to macvtap1@eth0
The problem is is that virtio-net supports checksum offloading
and thus sends the packets to the host with CHECKSUM_PARTIAL set.
On the other hand, e1000 does not support any acceleration.
For small TCP packets (and this includes the 3-way handshake),
e1000 ends up receiving packets that only have a partial checksum
set. This causes TCP to fail checksum validation and to drop
packets. As a result tcp connections can not be established.
Commit 3e4f8b7873
macvtap: Perform GSO on forwarding path.
fixes this issue for large packets wthat will end up undergoing GSO.
This commit adds a check for the non-GSO case and attempts to
compute the checksum for partially checksummed packets in the
non-GSO case.
CC: Daniel Lezcano <daniel.lezcano@free.fr>
CC: Patrick McHardy <kaber@trash.net>
CC: Andrian Nord <nightnord@gmail.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
CC: Michael S. Tsirkin <mst@redhat.com>
CC: Jason Wang <jasowang@redhat.com>
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds set_rx_int_on_com function for interrupt when
dma is completed.
Signed-off-by: Byungho An <bh74.an@samsung.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds rxqueue enable function according to number of rxqueue
and adds rxqueue disable function for removing.
Signed-off-by: Byungho An <bh74.an@samsung.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch moves sw reset to probe function because
sw reset is needed early stage before open function.
Signed-off-by: Byungho An <bh74.an@samsung.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add handling for " 8 GT/s" in print_port_info().
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes the following sparse warnings:
drivers/net/ethernet/altera/altera_msgdma.c:23:5: warning: symbol 'msgdma_initialize' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:28:6: warning: symbol 'msgdma_uninitialize' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:32:6: warning: symbol 'msgdma_reset' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:77:6: warning: symbol 'msgdma_disable_rxirq' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:83:6: warning: symbol 'msgdma_enable_rxirq' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:89:6: warning: symbol 'msgdma_disable_txirq' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:95:6: warning: symbol 'msgdma_enable_txirq' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:101:6: warning: symbol 'msgdma_clear_rxirq' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:107:6: warning: symbol 'msgdma_clear_txirq' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:114:5: warning: symbol 'msgdma_tx_buffer' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:129:5: warning: symbol 'msgdma_tx_completions' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:154:5: warning: symbol 'msgdma_add_rx_desc' was not declared. Should it be static?
drivers/net/ethernet/altera/altera_msgdma.c:181:5: warning: symbol 'msgdma_rx_status' was not declared. Should it be static?
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Vince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
sgdma_descrip is a function name as well as the name of a struct. In
sgdma_initialize(), we should initialize the descriptor length field
with the actual length of a descriptor not with the size of the
function. In order to prevent such things from happening in the future,
rename the function to sgdma_setup_descrip().
Found by sparse which yields the following warning:
drivers/net/ethernet/altera/altera_sgdma.c:74:30: warning: expression using sizeof on a function
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
When using dt resources retrieval (interrupts and reg properties) there is
no predefined order for these resources in the platform dev resource
table. Also don't expect the number of resource to be always 2.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> # 3.4
Signed-off-by: Felipe Balbi <balbi@ti.com>
Fixes: a53268be0c ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
Cc: stable@vger.kernel.org
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Beginning with kernel 3.13, this driver fails on some systems. The problem
was bisected to:
Commit 1bf4bbb402
Author: Felix Fietkau <nbd@openwrt.org>
Title: mac80211: send control port protocol frames to the VO queue
There is noting wrong with the above commit. The regression occurs because
V0 queue on RTL8192SE cards uses priority 6, not the usual 7. The fix is to
modify the rtl8192se routine that sets the correct transmit queue.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=74541
Reported-by: Alex Miller <almiller_1@yahoo.co.uk>
Tested-by: Alex Miller <almiller_1@yahoo.co.uk>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [3.13+]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are some corner cases where the driver could get stuck with a full
tid queue that is paused, leading to a software tx queue hang.
Since the tx queueing rework, pausing per-tid queues on aggregation
session setup is no longer necessary. The driver will assign sequence
numbers to buffered frames when a new session is established, in order
to get the correct starting sequence number.
mac80211 prevents new frames from entering the queue during setup.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the amount of noise fluctuates strongly, low immunity settings
can sometimes disrupt signal detection on AR913x chips. When that
happens, no OFDM/CCK errors are reported anymore, and ANI tunes the
radio to the lowest immunity settings.
Usually rx/tx fails as well in that case.
To fix this, keep noise immunity settings at or above ANI default level,
which will keep radio parameters at or above INI values.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Pull drm fixes from Dave Airlie:
"Smattering of fixes, i915, exynos, tegra, msm, vmwgfx.
A bit of framebuffer reference counting fallout fixes, i915 GM45
regression fix, DVI regression fix, vmware info leak between processes
fix"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/exynos: use %pad for dma_addr_t
drm/exynos: dsi: use IS_ERR() to check devm_ioremap_resource() results
MAINTAINERS: update maintainer entry for Exynos DP driver
drm/exynos: balance framebuffer refcount
drm/i915: Move all ring resets before setting the HWS page
drm/i915: Don't WARN nor handle unexpected hpd interrupts on gmch platforms
drm/msm/mdp4: cure for the cursor blues (v2)
drm/msm: default to XR24 rather than AR24
drm/msm: fix memory leak
drm/tegra: restrict plane loops to legacy planes
drm/i915: Allow full PPGTT with param override
drm/i915: Discard BIOS framebuffers too small to accommodate chosen mode
drm/vmwgfx: Make sure user-space can't DMA across buffer object boundaries v2
drm/i915: get power domain in case the BIOS enabled eDP VDD
drm/i915: Don't check gmch state on inherited configs
drm/i915: Allow user modes to exceed DVI 165MHz limit
Use %pad for dma_addr_t, because a dma_addr_t type can vary
based on build options. So, it prevents possible build warnings
in printks.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
devm_ioremap_resource() returns an error pointer, not NULL. Thus,
the result should be checked with IS_ERR().
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
exynos_drm_crtc_mode_set assigns primary framebuffer to plane without
taking reference. Then during framebuffer removal it is dereferenced twice,
causing oops. The patch fixes it.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
single security fix, cc'd stable.
* 'vmwgfx-fixes-3.15' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Make sure user-space can't DMA across buffer object boundaries v2
Fix the compile error:
drivers/pnp/quirks.c:393:2: error: implicit declaration of function 'pcibios_bus_to_resource'
that occurs when building with CONFIG_PCI unset. The quirk is only
relevent to Intel devices, so we could use "#if defined(CONFIG_X86) &&
defined(CONFIG_PCI)" instead, but testing CONFIG_X86 is not strictly
necessary.
Fixes: cb171f7abb (PNP: Work around BIOS defects in Intel MCH area reporting)
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Address a regression caused by commit ad332c8a45:
(ACPI / EC: Clear stale EC events on Samsung systems)
After the earlier patch, there was found to be a race condition on some
earlier Samsung systems (N150/N210/N220). The function acpi_ec_clear was
sometimes discarding a new EC event before its GPE was triggered by the
system. In the case of these systems, this meant that the "lid open"
event was not registered on resume if that was the cause of the wake,
leading to problems when attempting to close the lid to suspend again.
After testing on a number of Samsung systems, both those affected by the
previous EC bug and those affected by the race condition, it seemed that
the best course of action was to process rather than discard the events.
On Samsung systems which accumulate stale EC events, there does not seem
to be any adverse side-effects of running the associated _Q methods.
This patch adds an argument to the static function acpi_ec_sync_query so
that it may be used within the acpi_ec_clear loop in place of
acpi_ec_query_unlocked which was used previously.
With thanks to Stefan Biereigel for reporting the issue, and for all the
people who helped test the new patch on affected systems.
Fixes: ad332c8a45 (ACPI / EC: Clear stale EC events on Samsung systems)
References: https://lkml.kernel.org/r/532FE3B2.9060808@biereigel-wb.de
References: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173
Reported-by: Stefan Biereigel <stefan@biereigel.de>
Signed-off-by: Kieran Clancy <clancy.kieran@gmail.com>
Tested-by: Stefan Biereigel <stefan@biereigel.de>
Tested-by: Dennis Jansen <dennis.jansen@web.de>
Tested-by: Nicolas Porcel <nicolasporcel06@gmail.com>
Tested-by: Maurizio D'Addona <mauritiusdadd@gmail.com>
Tested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com>
Tested-by: Giannis Koutsou <giannis.koutsou@gmail.com>
Tested-by: Kieran Clancy <clancy.kieran@gmail.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
clockevent fixes for 3.15 from Daniel Lezcano:
* Lorenzo Pieralizi fixed an issue with the arch_arm_timer where the
C3STOP flag for all the arch can cause some trouble by setting the
flag only if the power domain is not always on
* Alexander Shiyan fixed a compilation by changing the init function
to the right prototype
Use INIT_WORK_ONSTACK to silence "ODEBUG: object is on stack, but not
annotated".
Reported-by: Zdeněk Kabeláč <zkabelac@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <ejt@redhat.com>
When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules loaded but some driver still stuck in the deferred list
and there is a need for external event to kick the deferred queue to probe
these drivers.
The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
audio support built as modules and using nfsroot for root filesystem.
The following log fragment shows such sequence when all audio modules
were loaded but the sound card is not present since the machine driver has
failed to probe due to missing dependency during it's probe.
The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
machine driver:
...
[ 12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
[ 12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
[ 12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
[ 12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
[ 12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
[ 12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
[ 12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
[ 13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
[ 13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
[ 13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
[ 13.346755] davinci_mcasp_driver_init: LEAVE
[ 13.377446] platform sound.3: Driver davinci_evm requests probe deferral
[ 13.592527] platform sound.3: really_probe: probe_count = 0
In the log the machine driver enters it's probe at 12.719969 (this point it
has been removed from the deferred lists). McASP driver already executing
it's probing (since 12.615118).
The machine driver tries to construct the sound card (12.950839) but did
not found one of the components so it fails. After this McASP driver
registers all the ASoC components (the machine driver still in it's probe
function after it failed to construct the card) and the deferred work is
prepared at 13.099026 (note that this time the machine driver is not in the
lists so it is not going to be handled when the work is executing).
Lastly the machine driver exit from it's probe and the core places it to
the deferred list but there will be no other driver going to load and the
deferred queue is not going to be kicked again - till we have external event
like connecting USB stick, etc.
The proposed solution is to try the deferred queue once more when the last
driver is asking for deferring and we had drivers loaded while this last
driver was probing.
This way we can avoid drivers stuck in the deferred queue.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Stable <stable@vger.kernel.org> # v3.4+
CC drivers/clocksource/zevio-timer.o
drivers/clocksource/zevio-timer.c:215:1: warning: comparison of distinct pointer types lacks a cast [enabled by default]
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
ARM arch timers are tightly coupled with the CPU logic and lose context
on platform implementing HW power management when cores are powered
down at run-time. Marking the arch timers as C3STOP regardless of power
management capabilities causes issues on platforms with no power management,
since in that case the arch timers cannot possibly enter states where the
timer loses context at runtime and therefore can always be used as a high
resolution clockevent device.
In order to fix the C3STOP issue in a way compliant with how real HW
works, this patch adds a boolean property to the arch timer bindings
to define if the arch timer is managed by an always-on power domain.
This power domain is present on all ARM platforms to date, and manages
HW that must not be turned off, whatever the state of other HW
components (eg power controller). On platforms with no power management
capabilities, it is the only power domain present, which encompasses
and manages power supply for all HW components in the system.
If the timer is powered by the always-on power domain, the always-on
property must be present in the bindings which means that the timer cannot
be shutdown at runtime, so it is not a C3STOP clockevent device.
If the timer binding does not contain the always-on property, the timer is
assumed to be power-gateable, hence it must be defined as a C3STOP
clockevent device.
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Magnus Damm <damm@opensource.se>
Cc: Marc Carino <marc.ceeeee@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
The whole db drop avoidance stuff is for T4 only. So we cannot allow
that to be enabled for T5 devices.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
This is required to work around a T5 HW issue.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
In cases where the cm calls c4iw_modify_rc_qp() with the endpoint
mutex held, they must be called with internal == 1. rx_data() and
process_mpa_reply() are not doing this. This causes a deadlock
because c4iw_modify_rc_qp() might call c4iw_ep_disconnect() in some
!internal cases, and c4iw_ep_disconnect() acquires the endpoint mutex.
The design was intended to only do the disconnect for !internal calls.
Change rx_data(), FPDU_MODE case, to call c4iw_modify_rc_qp() with
internal == 1, and then disconnect only after releasing the mutex.
Change process_mpa_reply() to call c4iw_modify_rc_qp(TERMINATE) with
internal == 1 and set a new attr flag telling it to send a TERMINATE
message. Previously this was implied by !internal.
Change process_mpa_reply() to return whether the caller should
disconnect after releasing the endpoint mutex. Now rx_data() will do
the disconnect in the cases where process_mpa_reply() wants to
disconnect after the TERMINATE is sent.
Change c4iw_modify_rc_qp() RTS->TERM to only disconnect if !internal,
and to send a TERMINATE message if attrs->send_term is 1.
Change abort_connection() to not aquire the ep mutex for setting the
state, and make all calls to abort_connection() do so with the mutex
held.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
During frequency transitions, the cpufreq core takes the responsibility of
invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
for those cpufreq drivers that define the ->target_index callback but don't
set the ASYNC_NOTIFICATION flag.
The powernow-k7 cpufreq driver falls under this category, but this driver was
invoking the _begin() and _end() APIs itself around frequency transitions,
which led to double invocation of the _begin() API. The _begin API makes
contending callers wait until the previous invocation is complete. Hence,
the powernow-k7 driver ended up waiting on itself, leading to system hangs
during boot.
Fix this by removing the calls to the _begin() and _end() APIs from the
powernow-k7 driver, since they rightly belong to the cpufreq core.
Fixes: 12478cf0c5 (cpufreq: Make sure frequency transitions are serialized)
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
During frequency transitions, the cpufreq core takes the responsibility of
invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
for those cpufreq drivers that define the ->target_index callback but don't
set the ASYNC_NOTIFICATION flag.
The powernow-k6 cpufreq driver falls under this category, but this driver was
invoking the _begin() and _end() APIs itself around frequency transitions,
which led to double invocation of the _begin() API. The _begin API makes
contending callers wait until the previous invocation is complete. Hence,
the powernow-k6 driver ended up waiting on itself, leading to system hangs
during boot.
Fix this by removing the calls to the _begin() and _end() APIs from the
powernow-k6 driver, since they rightly belong to the cpufreq core.
(Note that during ->exit(), the powernow-k6 driver sets the frequency
without any help from the cpufreq core. So add explicit calls to the
_begin() and _end() APIs around that frequency transition alone, to take
care of that special case. Also, add a missing 'break' statement there.)
Fixes: 12478cf0c5 (cpufreq: Make sure frequency transitions are serialized)
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The value of 'max_multiplier' is meant to be used for comparison with
clock_ratio[index].driver_data, not the index itself! Fix the code in
powernow_k6_cpu_exit() that has this bug.
Also, while at it, make the for-loop condition look for CPUFREQ_TABLE_END,
instead of hard-coding the loop count to 8.
Reported-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
During frequency transitions, the cpufreq core takes the responsibility of
invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
for those cpufreq drivers that define the ->target_index callback but don't
set the ASYNC_NOTIFICATION flag.
The longhaul cpufreq driver falls under this category, but this driver was
invoking the _begin() and _end() APIs itself around frequency transitions,
which led to double invocation of the _begin() API. The _begin API makes
contending callers wait until the previous invocation is complete. Hence,
the longhaul driver ended up waiting on itself, leading to system hangs
during boot.
Fix this by removing the calls to the _begin() and _end() APIs from the
longhaul driver, since they rightly belong to the cpufreq core.
(Note that during module_exit(), the longhaul driver sets the frequency
without any help from the cpufreq core. So add explicit calls to the
_begin() and _end() APIs around that frequency transition alone, to take
care of that special case.)
Fixes: 12478cf0c5 (cpufreq: Make sure frequency transitions are serialized)
Reported-and-tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This branch contains a pair of important bug fixes for the DT code:
- Fix some incorrect binding property names before they enter common usage
- Fix bug where some platform devices will be unable to get their
interrupt number when they depend on an interrupt controller that is
not available at device creation time. This is a problem causing
mainline to fail on a number of ARM platforms.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTXr8WAAoJEMWQL496c2LNhzgP/RhhIS9ySzJkdPEMksnBaQbN
JKG+wBwlzvtJSPw2xX5EpWweOd1PDqHxLjjWu7q5WIrQQyOGRAELkYg1H+5ksFo1
obCAFOjTC7VXPGc+BX0dLN6Eq4UHP8k3Ui8zlMSZQNt+gBvYo1gX2ulR8sQgS8rF
xw+8iNDA2GIFusQbci35yOAhp6yo/ble3KIeR5dFKeMpiVSh9rqdLS+H9HgnG5Sw
G2LUrAeRY2yQbow3c1001HiKrJieZZSTCq8oiZDgJZY5+Qk8zamyj2xxgMoJUA8Q
2Kcb3379vNvDgjYX61NiwyrhIbJEiao8IXq6WMDNbmH3+FUwogrnh/A/g5POtX0N
JV5tGkc/2lfm5oBCFSzcw661XjLysPsm3nPLhnxRL/dlBVkl0IZzTVYPTqUtoKlK
NfwKFUDgg+QVmhFQT0BDCyOGAcRsz4rNEPPB6M12OmEKgxGpetfUaFdBcJqSNaxf
Ac6AAZCXrkLlRNOVhK333ILPxv1JRC++JAeRKNwHr9e6j2aJjUgilSuzpHJ5Lkyo
sj6kp+n1n+giYlgc9GjM7b33tm8XEd4rbcgwCWwaypEsl4FIwPs9xMys7md8SOCE
AAnVPVUvLGC9O2GhldeQlOgtGWzILW3zJXb2mrMIIGyLBGBx1qr3VJIZpxoddTc0
UtIJn0X37mKY/R4/hWs4
=B2JT
-----END PGP SIGNATURE-----
Merge tag 'dt-for-linus' of git://git.secretlab.ca/git/linux
Pull devicetree bug fixes from Grant Likely:
"These are some important bug fixes that need to get into v3.15.
This branch contains a pair of important bug fixes for the DT code:
- Fix some incorrect binding property names before they enter common
usage
- Fix bug where some platform devices will be unable to get their
interrupt number when they depend on an interrupt controller that
is not available at device creation time. This is a problem
causing mainline to fail on a number of ARM platforms"
* tag 'dt-for-linus' of git://git.secretlab.ca/git/linux:
of/irq: do irq resolution in platform_get_irq
of: selftest: add deferred probe interrupt test
dt: Fix binding typos in clock-names and interrupt-names
We are allocating the size of a pointer and not the size of the data.
This will lead to memory corruption.
There isn't actually a "cb_device" struct, btw. The code is only able
to compile because GCC knows that all pointers are the same size.
Fixes: 96ca848ef7 ('DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Sricharan R <r.sricharan@ti.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Link: http://lkml.kernel.org/r/20140403072134.GA14286@mwanda
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The set_irq_affinity() function has two issues:
1) It has no protection against selecting an offline cpu from the
given mask.
2) It pointlessly restricts the affinity masks to have a single cpu
set. This collides with the irq migration code of arm.
irq affinity is set to core 3
core 3 goes offline
migration code sets mask to cpu_online_mask and calls the
irq_set_affinity() callback of the irq_chip which fails due to bit
0,1,2 set.
So instead of doing silly for_each_cpu() loops just pick any bit of
the mask which intersects with the online mask.
Get rid of fiddling with the default_irq_affinity as well.
[ Gregory: Fixed the access to the routing register ]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>
Link: http://lkml.kernel.org/r/20140304203101.088889302@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Fix format string mismatch in bonding_show_min_links().
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On suspend, _scsih_suspend calls mpt2sas_base_free_resources, which
in turn calls pci_disable_device if the device is enabled prior to
suspending. However, _scsih_suspend also calls pci_disable_device
itself.
Thus, in the event that the device is enabled prior to suspending,
pci_disable_device will be called twice. This patch removes the
duplicate call to pci_disable_device in _scsi_suspend as it is both
unnecessary and results in a kernel oops.
Signed-off-by: Tyler Stachecki <tstache1@binghamton.edu>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
With commit cc9fa74e2a ("slip/slcan: added locking in wakeup function") a
formerly missing locking was added to slip.c and slcan.c by Andre Naujoks.
Alexander Stein contributed the fix 367525c8c2 ("can: slcan: Fix spinlock
variant") as the kernel lock debugging advised to use spin_lock_bh() instead
of just using spin_lock().
This fix has to be applied to the same code section in slip.c for the same
reason too.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Dan writes:
"The Dell drivers use the same configuration for PIDs:
81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card
81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card
81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card
81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card
81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card
These devices are all clearly Sierra devices, but are also definitely
Gobi-based. The A8 might be the MC7700/7710 and A9 is likely a MC7750.
>From DellGobi5kSetup.exe from the Dell drivers:
usbif0: serial/firmware loader?
usbif2: nmea
usbif3: modem/ppp
usbif8: net/QMI"
Reported-by: AceLan Kao <acelan.kao@canonical.com>
Reported-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
A number of older CMOTech modems are based on Qualcomm
chips and exporting a QMI/wwan function.
Reported-by: Lars Melin <larsm17@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
This adds ability for the arc_emac to really handle its supplying clock.
To get the needed clock-frequency either a real clock or the previous
clock-frequency property must be provided.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Max Schwarz <max.schwarz@online.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
The probe function at the moment only frees the netdev but does not disconnect
the phy or removes the mdio bus it registered.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
A single fix for some framebuffer reference counting fallout caused by
the primary plane helpers introduced in 3.15-rc1.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTWQzGAAoJEN0jrNd/PrOhrkAP/2BQvFszaEeMlI1sb18DK9pm
tu3BNf+gB/ZvsMVok79KdeDHi73v5acwqDapDmCcHKS1JRpqbKMgzWDrXYg39WWi
0i+nyWt43ajXqO3/PvrDiqDRTwb4Ee/GdQMVVti6+VcSYlKSMqrcCsL2SStfiUIU
z6tL0WpEF5oKRHwfSKjFP3CRkSiElLbjKDk5Z/b1noZoahjdFrc54fWpK71+Tf5C
HZ7vsWJxgqip0CRtRqYer8auLSdHN7LhNBRVCGWbgSNHMuKp07U/9qktmBFgLtkO
gOGu6W7wLR8sgCmNpDv6ht5pvu3cGWKRCDTSmbF79CTCdc/Wb2rMs/JSeq4CJPcP
wZ+TwnUwNp+Qv2McTONp6wCZ/qpBBcZgymOVCt9bossKs03DMT4H7C5ypri8QrQM
40V8KEmYpiAcO5JN0oXUd4Q2n6NniZwCP4xt/U4cUXTjCqMAnLBozCji8ApDLegX
wmSz2+G0NGAcnJEK482PE+lxavOaWPyRg1y777VCfOSstqiSaukmrg4/xxrMdp+a
fDSZWLdVPqZUaUr5qWPl0Szbihw3brmMSCzubrP5dOtw8MUUHXIRGbBE5w2PH8tD
do4yvxPPO9W0iH6PW+rN4Z4ll+SS0EQwsohBPA0/Z2CAC+CrMAseBb/71/syocqA
JIY2cogdFI0Ynzp6t4xn
=uM53
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-3.15-rc3' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Fixes for v3.15-rc3
A single fix for some framebuffer reference counting fallout caused by
the primary plane helpers introduced in 3.15-rc1.
* tag 'drm/tegra/for-3.15-rc3' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: restrict plane loops to legacy planes
Fixes for msm for 3.15.. a memory leak fix for devices using vram
carveout instead of iommu. Plus I think finally managed to sort out /
workaround some cursor vs underflow issues. And small fbcon tweak
needed to avoid extra full-modesets at boot.
* 'msm-fixes-3.15-rc3' of git://people.freedesktop.org/~robclark/linux:
drm/msm/mdp4: cure for the cursor blues (v2)
drm/msm: default to XR24 rather than AR24
drm/msm: fix memory leak
Fix regression with DVI and fix warns, and GM45 boot regression.
* tag 'drm-intel-fixes-2014-04-25' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Move all ring resets before setting the HWS page
drm/i915: Don't WARN nor handle unexpected hpd interrupts on gmch platforms
drm/i915: Allow full PPGTT with param override
drm/i915: Discard BIOS framebuffers too small to accommodate chosen mode
drm/i915: get power domain in case the BIOS enabled eDP VDD
drm/i915: Don't check gmch state on inherited configs
drm/i915: Allow user modes to exceed DVI 165MHz limit
Pull irq fixes from Thomas Gleixner:
"A slighlty large fix for a subtle issue in the CPU hotplug code of
certain ARM SoCs, where the not yet online cpu needs to setup the cpu
local timer and needs to set the interrupt affinity to itself.
Setting interrupt affinity to a not online cpu is prohibited and
therefor the timer interrupt ends up on the wrong cpu, which leads to
nasty complications.
The SoC folks tried to hack around that in the SoC code in some more
than nasty ways. The proper solution is to have a way to enforce the
affinity setting to a not online cpu. The core patch to the genirq
code provides that facility and the follow up patches make use of it
in the GIC interrupt controller and the exynos timer driver.
The change to the core code has no implications to existing users,
except for the rename of the locked function and therefor the
necessary fixup in mips/cavium. Aside of that, no runtime impact is
possible, as none of the existing interrupt chips implements anything
which depends on the force argument of the irq_set_affinity()
callback"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
clocksource: Exynos_mct: Register clock event after request_irq()
clocksource: Exynos_mct: Use irq_force_affinity() in cpu bringup
irqchip: Gic: Support forced affinity setting
genirq: Allow forcing cpu affinity of interrupts
Here are a few tty/serial fixes for 3.15-rc3 that resolve a number of
reported issues in the 8250 and samsung serial drivers, as well as a
character loss fix for the tty core that was caused by the lock removal
patches a release ago.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlNcUDMACgkQMUfUDdst+ylZvgCgjeJTIxh+7Lpo/yqbFRZz05dc
KZ4AoLBTof/1fV2UMczNm61vrp0+wvyi
=FnZz
-----END PGP SIGNATURE-----
Merge tag 'tty-3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are a few tty/serial fixes for 3.15-rc3 that resolve a number of
reported issues in the 8250 and samsung serial drivers, as well as a
character loss fix for the tty core that was caused by the lock
removal patches a release ago"
* tag 'tty-3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
serial_core: fix uart PORT_UNKNOWN handling
serial: samsung: Change barrier() to cpu_relax() in console output
serial: samsung: don't check config for every character
serial: samsung: Use the passed in "port", fixing kgdb w/ no console
serial: 8250: Fix thread unsafe __dma_tx_complete function
8250_core: Fix unwanted TX chars write
tty: Fix race condition between __tty_buffer_request_room and flush_to_ldisc
Here are some small staging and IIO driver fixes for 3.15-rc3.
Nothing major at all, just some assorted issues that people have reported.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlNcTrIACgkQMUfUDdst+ymTPACfQTyAgaXWKIOEAk2Ur8YeSqhr
NxYAn0T1tgCRuNNtj6/TnGN8RxzaMqtZ
=9ZEj
-----END PGP SIGNATURE-----
Merge tag 'staging-3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging / IIO driver fixes from Greg KH:
"Here are some small staging and IIO driver fixes for 3.15-rc3.
Nothing major at all, just some assorted issues that people have
reported"
* tag 'staging-3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: comedi: usbdux: bug fix for accessing 'ao_chanlist' in private data
iio: adc: mxs-lradc: fix warning when buidling on avr32
iio: cm36651: Fix i2c client leak and possible NULL pointer dereference
iio: querying buffer scan_mask should return 0/1
staging:iio:ad2s1200 fix a missing break
iio: adc: at91_adc: correct default shtim value
ARM: at91: at91sam9260: change at91_adc name
ARM: at91: at91sam9g45: change at91_adc name
iio: cm32181: Fix read integration time function
iio: adc: at91_adc: Repair broken platform_data support
Here are a number of USB fixes for 3.15-rc3. The majority are gadget
fixes, as we didn't get any of those in for 3.15-rc2. The others are
all over the place, and there's a number of new device id addtions as
well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlNcUKIACgkQMUfUDdst+ynSsQCeKmkO1od6fPs5uHPSEwns+pqB
+B4Anip6dHYATN5GCv+p3JWLZkQgT9lD
=s4E0
-----END PGP SIGNATURE-----
Merge tag 'usb-3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are a number of USB fixes for 3.15-rc3. The majority are gadget
fixes, as we didn't get any of those in for 3.15-rc2. The others are
all over the place, and there's a number of new device id addtions as
well."
* tag 'usb-3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (35 commits)
usb: option: add and update a number of CMOTech devices
usb: option: add Alcatel L800MA
usb: option: add Olivetti Olicard 500
usb: qcserial: add Sierra Wireless MC7305/MC7355
usb: qcserial: add Sierra Wireless MC73xx
usb: qcserial: add Sierra Wireless EM7355
USB: io_ti: fix firmware download on big-endian machines
usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM
xhci: extend quirk for Renesas cards
xhci: Switch Intel Lynx Point ports to EHCI on shutdown.
usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
phy: core: make NULL a valid phy reference if !CONFIG_GENERIC_PHY
phy: fix kernel oops in phy_lookup()
phy: restore OMAP_CONTROL_PHY dependencies
phy: exynos: fix building as a module
USB: serial: fix sysfs-attribute removal deadlock
usb: wusbcore: fix panic in wusbhc_chid_set
usb: wusbcore: convert nested lock to use spin_lock instead of spin_lock_irq
uwb: don't call spin_unlock_irq in a USB completion handler
usb: chipidea: coordinate usb phy initialization for different phy type
...
- Fix for broken ACPI notifications on some systems caused by
a recent ACPI hotplug commit that blocked the propagation of
unknown type notifications to device drivers inadvertently.
- intel_idle fix to make the IvyTown C-states handling (added
recently) work as intended which now is broken due to missing
braces. From Christoph Jaeger.
- ACPICA fix to make it allocate buffers of the right sizes for
the Generic Serial Bus operation region access. From Lv Zheng.
- PM core fix unblocking cpuidle before entering the "freeze"
sleep state which causes that state to be able to actually save
more energy than runtime idle.
- Configuration and build fixes for the highbank and powernv
cpufreq drivers from Kefeng Wang and Srivatsa S Bhat.
- Coccinelle warning fix related to error pointers for the
unicore32 cpufreq driver from Duan Jiong.
- Integer overflow fix for the ppc-corenet cpufreq driver from
Geert Uytterhoeven.
- Workaround for BIOSes that don't report the entire Intel MCH
area in their ACPI tables from Bjorn Helgaas.
- ACPI tools Makefile fix and cleanup from Thomas Renninger.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJTWvQ7AAoJEILEb/54YlRxpf4P/R0yuUNC02E5zRD4VZdZ1fD7
H/7xJ9XDDcZiqe8sEAr8DiatoHsuQGfB5Vs+Vv/RGzGN7xz+wQ7V73niBGjHWekI
kl7DFcnM7aF4zy+hNQUKJiB0O19D+ttH3Jfow5Vpd4rQj7qIjp9s3okQn5HArrKS
KsoU4g+Mvt3VP3egeXGBmR4WqHYpEK8AIkV8d8XnOP7eTP4Q/Ed2aSFGsuwVhlft
63iBgB7yac+OSnTNTedsi5xxh+Bx/W6Q2SPSn0g2MVtzQICEMgGB6l+ftJZLBoI/
YRD6CkcYyOAllNjy6EGNg5UfwtbSh4qlfQ+dQkrpKZCgjVBfgeheiwrjrt/20/4l
QsEMVDhdoIBZEfJyT0o6LkRA7EHH+gykAhxJ35ocVgJxMbDzcJG2/aHnEs+zJIxc
TKWidhQYqangqfPZeLN3fGCJ8959ohBUWFNUO+JZDGKpguBFjC4GrC1bDuR5tF78
z5hm1QHGeJGrPZMg1qrAcRR2WMJv2tc/SBBeoNFzMy7Hi27bKJxPIktbUYWWD8NB
jP93jRbg2eGnGJucidlZ1Xx31GWY7wzU4kMQ6jPEKhbn5lRSITvqrYPgEPeSaSyr
xCUPGi+TrV18AD/OwSF+DJnIfgroKDETCtgBLponMr29Pa8bgTHu9HOe7/BbGf46
EbRPpwx8p6eaob2c7n5F
=yMFR
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
"These include a fix for a recent ACPI regression related to device
notifications, intel_idle fix related to IvyTown support, fix for a
buffer size issue in ACPICA, PM core fix related to the "freeze" sleep
state, four fixes for various types of breakage in cpufreq drivers, a
PNP workaround for a wrong memory region size in ACPI tables, and a
fix and cleanup for the ACPI tools Makefile.
Specifics:
- Fix for broken ACPI notifications on some systems caused by a
recent ACPI hotplug commit that blocked the propagation of unknown
type notifications to device drivers inadvertently.
- intel_idle fix to make the IvyTown C-states handling (added
recently) work as intended which now is broken due to missing
braces. From Christoph Jaeger.
- ACPICA fix to make it allocate buffers of the right sizes for the
Generic Serial Bus operation region access. From Lv Zheng.
- PM core fix unblocking cpuidle before entering the "freeze" sleep
state which causes that state to be able to actually save more
energy than runtime idle.
- Configuration and build fixes for the highbank and powernv cpufreq
drivers from Kefeng Wang and Srivatsa S Bhat.
- Coccinelle warning fix related to error pointers for the unicore32
cpufreq driver from Duan Jiong.
- Integer overflow fix for the ppc-corenet cpufreq driver from Geert
Uytterhoeven.
- Workaround for BIOSes that don't report the entire Intel MCH area
in their ACPI tables from Bjorn Helgaas.
- ACPI tools Makefile fix and cleanup from Thomas Renninger"
* tag 'pm+acpi-3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / notify: Do not block unknown type notifications in root handler
PNP: Work around BIOS defects in Intel MCH area reporting
cpufreq: highbank: fix ARM_HIGHBANK_CPUFREQ dependency warning
cpufreq: ppc: Fix integer overflow in expression
cpufreq, powernv: Fix build failure on UP
cpufreq: unicore32: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO
PM / suspend: Make cpuidle work in the "freeze" state
intel_idle: fix IVT idle state table setting
ACPICA: Fix buffer allocation issue for generic_serial_bus region accesses.
tools/power/acpi: Minor bugfixes
This patch fixes the PTP Tx timestamp interrupt handler. The original
code misinterpreted the interrupt handler design. We were clearing the
ena_mask bit for the Timesync interrupts. This is done to indicate that
the interrupt will be handled in a scheduled work item (instead of
immediately) and that work item is responsible for re-enabling the
interrupts. However, the Tx timestamp was being handled immediately and
nothing was ever re-enabling it. This resulted in a single interrupt
working for the life of the driver.
This patch fixes the issue by instead clearing the bit from icr0 which
is used to indicate that the interrupt was immediately handled and can
be re-enabled right away. This patch also clears up a related issue due
to writing the PRTTSYN_STAT_0 register, which was unintentionally
clearing the cause bits for Timesync interrupts.
Change-ID: I057bd70d53c302f60fab78246989cbdfa469d83b
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Anjali Singhai Jain <anjali.singhai@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlNZf5EACgkQjTAFq1RaXHPFhACghgdQaxG++36VEhtToY+H8o2x
3UUAniZ+DbwtSapriPekjVKRC7VuQFsD
=N5FA
-----END PGP SIGNATURE-----
Merge tag 'linux-can-fixes-for-3.15-20140424' of git://gitorious.org/linux-can/linux-can
Marc Kleine-Budde says:
====================
this is a pull request for net/master, for the v3.15 release cycle, consisting
of 26 patches.
Thomas Gleixner contributes 21 patches for the c_can driver, which address
several shortcomings in the driver like hardware initialisation, concurrency,
message ordering and poor performance. Two patches Oliver Hartkopp, one adds a
missing lock to the sja1000_isa driver, the other one fixes the return value in
the generic bit time configuration function. And finally a patch by Alexander
Stein, that fixes the slcan driver to use the correct spinlock variant.
To make it 26 patches, Wolfgang Grandegger patch for the c_can_pci
driver, which enables the bus master only for MSI and a patch by
Wolfram Sang, which converts the 'instance' in the c_can driver to the
proper type.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch changes the name used by Ethtool to something more
conventional in preparation for TSE Ethtool register dump
support to be added in the near future.
Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch addresses a fault in the error recovery path of the probe
routine where the netdev structure was not being unregistered properly
leading to a panic only when the phy probe failed.
Abbreviated panic stack seen is as follows:
(free_netdev+0xXX) from (altera_tse_probe+0xXX)
(altera_tse_probe+0xXX) from (platform_drv_probe+0xXX)
(platform_drv_probe+0xXX) from (driver_probe_device+0xXX)
(driver_probe_device+0xXX) from (__driver_attach+0xXX)
(__driver_attach+0xXX) from (bus_for_each_dev+0xXX)
(bus_for_each_dev+0xXX) from (driver_attach+0xXX)
(driver_attach+0xXX) from (bus_add_driver+0xXX)
(bus_add_driver+0xXX) from (driver_register+0xXX)
(driver_register+0xXX) from (__platform_driver_register+0xXX)
(__platform_driver_register+0xXX) from (altera_tse_driver_init+0xXX)
(altera_tse_driver_init+0xXX) from (do_one_initcall+0xXX)
(do_one_initcall+0xXX) from (kernel_init_freeable+0xXX)
(kernel_init_freeable+0xXX) from (kernel_init+0xXX)
(kernel_init+0xXX) from (ret_from_fork+0xXX)
Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch initializes the pause quanta set for transmitted pause frames
to the IEEE specified default of 0xffff.
Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch works around a recently discovered unaligned receive dma problem
with the Altera SGMDA. The Altera SGDMA component cannot be configured to
DMA data to unaligned addresses for receive packet operations from the
Triple Speed Ethernet component because of a potential data transfer
corruption that can occur. This patch addresses this issue by
utilizing the shift 16 bits feature of the Altera Triple Speed Ethernet
component and modifying the receive buffer physical addresses accordingly
such that the target receive DMA address is always aligned on a 32-bit
boundary.
Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
Tested-by: Matthew Gerlach <mgerlach@altera.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Starting with commit 2dc33bbc "bnx2x: Remove the sriov VFOP mechanism",
the bnx2x started enforcing vlan credits for all vlan configurations.
This exposed 2 issues:
- Vlan credits are not returned once a VF is removed; this causes a leak
of credits, and eventually will lead to VFs with no vlan credits.
- A vlan credit must be set aside for the Hypervisor to use, and should
not be visible to the VF.
Although linux VFs at the moment do not support vlan configuration [from the
VF side] which causes them to be resilient to this sort of issue, Windows VF
over linux hypervisors might fail to load as the vlan credits become depleted.
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When removing a VF interface, the driver fails to release that VF's mailbox
and bulletin board allocated memory.
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The whole IIO subsystem can be built as modules. If you make it a
module then stuff marked as "Y" in the adc directory simply won't be
linked in properly.
The two configs that were wrong were EXYNOS_ADC and LP8788_ADC. I
know for a fact that EXYNOS_ADC will work as a module. I assume
LP8788_ADC will also be fine.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Using pdev->dev with device_for_each_child() would iterate over all
of the children of the platform device and delete them.
Thus, causing crashes during module unload.
We should be using the indio_dev->dev structure for
registering/unregistering child nodes.
Reported-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Naveen Krishna Ch <ch.naveen@samsung.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The driver segfaults when the kernel boots with device tree as the
platform data is then not present and the pointer is deferenced without
checking it is not null. This patch introduces such a check avoiding the
crash.
Signed-off-by: Atilla Filiz <atilla.filiz@essensium.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Stable@vger.kernel.org
* pnp:
PNP: Work around BIOS defects in Intel MCH area reporting
* acpi-hotplug:
ACPI / notify: Do not block unknown type notifications in root handler
This is a set of seven fixes, three (hpsa) and free'd command references
correcting bugs in the last round of updates and the remaining four correcting
problems within the SCSI error handler that was causing a deadlock within USB.
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJTWnfJAAoJEDeqqVYsXL0MO/UH/RWKALNIMzMg8yUSlozPFXFj
xgPgbp/DJdYq952wrAF0D+ewoukdXJS3QbF594aBb73iWUzEKFz8Z1naVrcV0+/9
ob1Uo56yb4PP9Qd7vtx7g3RK2o5Oz7NXICuH/zhEzhiVle/U5b1M1IZ9XnqK1bFD
gnplHz7UoKZskQKTSo6wxfAWJBD7V/JDpA6E2YbTtw1c0W4c1kgiSN2hOFjjiQEl
E3/JJzLr3BqSKoh5+5LPclXIYsXy3DT4L9b2nedEDIAN0yGx1HMeQKR26ZobeCx6
w5IkgQaRZJgoJgX7PyRtgdMh4TYZ4vKXFZ3jWqtQG7kCdWD2jwl9Dyruhj1vE8Q=
=izXj
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"This is a set of seven fixes, three (hpsa) and free'd command
references correcting bugs in the last round of updates and the
remaining four correcting problems within the SCSI error handler that
was causing a deadlock within USB"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
[SCSI] More USB deadlock fixes
[SCSI] Fix USB deadlock caused by SCSI error handling
[SCSI] Fix command result state propagation
[SCSI] Fix spurious request sense in error handling
[SCSI] don't reference freed command in scsi_prep_return
[SCSI] don't reference freed command in scsi_init_sgtable
[SCSI] hpsa: fix NULL dereference in hpsa_put_ctlr_into_performant_mode()
Since we didn't get around to collect fixes in time for -rc2 over
the easter vacation, this one is unfortunately a bit larger than
we'd like for an -rc3 merge. A large set of the changes is in the
device tree sources, so I'm splitting out the description between
code changes and DT changes. Aside from omap and versatile express,
the actual code bugs are sporadic and trivial. Here is an overview:
imx:
- fix video clock settings
- fix one clock refcounting bug
omap:
- update defconfig for renamed USB PHY driver
- fix error handling in gpmc
- fix N900 video initialization regression
- fix reression in hwmod code from missing braces
- fix am43xx and omap3 clocks
- remove bogus write to voltage control register
pxa:
- fix build regression from 3.13 header cleanup
rockchip:
- fix a misleading printk string
shmobile:
- fix incorrect sound setting on multiple machines
spear:
- remove incorrect __init section annotation
tegra:
- remove a stale Kconfig entry
u300:
- update defconfig
ux500:
- enable common wireless and sensor drivers in defconfig
- more defconfig updates
vexpress:
- fix voltage calculation for opp
- fix reboot hang and warning
- fix out-of-bounds array access
- improve error handling in clock driver
overall:
- always select CLKSRC_OF in multiplatform builds
And these are the devicetree related changes:
imx:
- add missing #clock-cell properties
- fix pinctrl setting in imx6sl-evk
- fix video endpoint on imx53
- remove obsolete lvds-channel nodes (multiple patches)
- add missing second stmpe node
- fix usb host mode on dmo-edmqmx6 (multiple patches)
- fix gic node #address-cells to match usage
- add missing legacy IRQ map for PCIe
- fix microsom pincontrol setting for rgmii
- fix fatal typo in touchscreen DT usage for mx5
- list all RAM present on m53evk and mx53qsb
omap:
- fix bug in DT handling of gpmc external bus
- add DT for older revision of beagleboard
- fix regression after DT node name fixes
- remove obsolete properties for gpmc
- fix pinmux comment to match DT it refers to
- fix newly added dra7xx clock node data
- add missing clock for USB PHY
mvebu:
- add missing clock for mdio node
- fix nonstandard vendor prefixes on i2c nodes
rockchip:
- fix pin control setting for uart
shmobile:
- fix typo in DT data for pin control (multiple patches)
- fix gic node #address-cells to match usage
tegra:
- fix clock and uart DT representation to match hardware
zynq:
- add DT nodes for newly added driver
- add DT properties required for cpufreq-ondemand
overall:
- restore alphabetic order in Makefile
- grammar fixes in bindings
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAU1pK92CrR//JCVInAQLerA/9GwLHJIBU6osKnZtIWDYPhYj81uRxgF5Q
qtaUdsSoDQmIiW8tzJL0VUBJQfSpPtf4hsIPh5dMKclalx+0kca3zpPepo58rvEP
zG39OIK/fBsmD/eVkz0y3lG5BUu9/1gkpnM8jSEmkDWqcNX8wQoOeHSrWXWzEk1G
2eZlXsYr9OVuIGRx14wnINvPuD2Z75zEXA7KDbDuYqauQvVojj5wH6s8R7Ujy7e1
+NGCThkLJUF2wid+6QmVk9D6tQXyVxmf+cr080n58LmOmoVnoFkCjs5gaUUIP8Zb
nM97PQly0s1JIRn+9jF7+U0KNyp9eec7Ogc00tpvvBmQI2kVfHfSRROLq+tDGu1t
nEEy52X/QVgWWY+1qUl+gqIWWmMTpniDF1pd/5jP3jKXUc/sM7OfLGQaTP4O7sR6
5MlfvqvSO/EaMeWEvX4e8+Z+2dY1qFZUYk7VtamqmOegzkcDjAiJ3aQNozuqq9JH
TTHbA2Em9VGC1LlAMAg7h46rM//npCeJ0Q5yjuFk093UBEbAF4HWO2PFNrdohKzC
Yz/R+vkvGeQ98K/4jj4UIyjcB4PUX+DRrozC10i2XCQh+UIYdgC4dFQz1nH/4iQS
CrdSRmDvpZDjSFV5m4+QVkaEsTJnXX6vV62VBVRcSLkqyfPABWj1y9c2L3K8kfBJ
6nbficflFqE=
=PPo/
-----END PGP SIGNATURE-----
Merge tag 'fixes-3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Arnd Bergmann:
"Since we didn't get around to collect fixes in time for -rc2 over the
easter vacation, this one is unfortunately a bit larger than we'd like
for an -rc3 merge.
A large set of the changes is in the device tree sources, so I'm
splitting out the description between code changes and DT changes.
Aside from omap and versatile express, the actual code bugs are and
trivial. Here is an overview:
imx:
- fix video clock settings
- fix one clock refcounting bug
omap:
- update defconfig for renamed USB PHY driver
- fix error handling in gpmc
- fix N900 video initialization regression
- fix reression in hwmod code from missing braces
- fix am43xx and omap3 clocks
- remove bogus write to voltage control register
pxa:
- fix build regression from 3.13 header cleanup
rockchip:
- fix a misleading printk string
shmobile:
- fix incorrect sound setting on multiple machines
spear:
- remove incorrect __init section annotation
tegra:
- remove a stale Kconfig entry
u300:
- update defconfig
ux500:
- enable common wireless and sensor drivers in defconfig
- more defconfig updates
vexpress:
- fix voltage calculation for opp
- fix reboot hang and warning
- fix out-of-bounds array access
- improve error handling in clock driver
overall:
- always select CLKSRC_OF in multiplatform builds
And these are the devicetree related changes:
imx:
- add missing #clock-cell properties
- fix pinctrl setting in imx6sl-evk
- fix video endpoint on imx53
- remove obsolete lvds-channel nodes (multiple patches)
- add missing second stmpe node
- fix usb host mode on dmo-edmqmx6 (multiple patches)
- fix gic node #address-cells to match usage
- add missing legacy IRQ map for PCIe
- fix microsom pincontrol setting for rgmii
- fix fatal typo in touchscreen DT usage for mx5
- list all RAM present on m53evk and mx53qsb
omap:
- fix bug in DT handling of gpmc external bus
- add DT for older revision of beagleboard
- fix regression after DT node name fixes
- remove obsolete properties for gpmc
- fix pinmux comment to match DT it refers to
- fix newly added dra7xx clock node data
- add missing clock for USB PHY
mvebu:
- add missing clock for mdio node
- fix nonstandard vendor prefixes on i2c nodes
rockchip:
- fix pin control setting for uart
shmobile:
- fix typo in DT data for pin control (multiple patches)
- fix gic node #address-cells to match usage
tegra:
- fix clock and uart DT representation to match hardware
zynq:
- add DT nodes for newly added driver
- add DT properties required for cpufreq-ondemand
overall:
- restore alphabetic order in Makefile
- grammar fixes in bindings"
* tag 'fixes-3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (66 commits)
ARM: vexpress/TC2: Convert OPP voltage to uV before storing
power/reset: vexpress: Fix restart/power off operation
dt: tegra: remove non-existent clock IDs
clk: tegra: remove non-existent clocks
ARM: tegra: remove UART5/UARTE from tegra124.dtsi
ARM: tegra: remove TEGRA_EMC_SCALING_ENABLE
ARM: Tidy up DTB Makefile entries
ARM: fix missing CLKSRC_OF on multi-platform
ARM: spear: add __init to spear_clocksource_init()
ARM: pxa: hx4700.h: include "irqs.h" for PXA_NR_BUILTIN_GPIO
arm/mach-vexpress: array accessed out of bounds
clk: vexpress: NULL dereference on error path
ARM: OMAP2+: Fix GPMC remap for devices using an offset
ARM: zynq: dt: Add I2C nodes to Zynq device tree
ARM: zynq: DT: Add 'clock-latency' property
ARM: OMAP2+: Fix oops for GPMC free
ARM: dts: Add support for the BeagleBoard xM A/B
ARM: dts: Grammar /that will/it will/
ARM: dts: Grammar /is uses/ is used/
ARM: OMAP2+: Fix config name for USB3 PHY
...
A number of older CMOTech modems are based on Qualcomm
chips. The blacklisted interfaces are QMI/wwan.
Reported-by: Lars Melin <larsm17@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
During firmware download the device expects memory addresses in
big-endian byte order. As the wIndex parameter which hold the address is
sent in little-endian byte order regardless of host byte order, we need
to use swab16 rather than cpu_to_be16.
Also make sure to handle the struct ti_i2c_desc size parameter which is
returned in little-endian byte order.
Reported-by: Ludovic Drolez <ldrolez@debian.org>
Tested-by: Ludovic Drolez <ldrolez@debian.org>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]
Instead of creating nested #ifdefs, this patch fixes it by defining the
xHCI PCI stubs as inline.
This warning has been in since 3.2 kernel and was
caused by commit 421aa841a1
"usb/xhci: hide MSI code behind PCI bars", but wasn't noticed
until 3.13 when a configuration with these options was tried
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Cc: stable@vger.kernel.org # 3.2
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.
The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.
This patch should be backported to stable kernels as old as 3.12,
that contain the commit 638298dc66
"xhci: Fix spurious wakeups after S5 on Haswell"
Signed-off-by: Denis Turischev <denis@compulab.co.il>
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a previous Set TR Dequeue Pointer command has set the
pointer to the final Link TRB of a segment, and then another URB gets
enqueued and cancelled again before it can be completed. Further
investigation showed that the xHC had returned the Link TRB in the TRB
Pointer field of the Transfer Event (CC == Stopped -- Length Invalid),
but when xhci_find_new_dequeue_state() later accesses the Endpoint
Context's TR Dequeue Pointer field it is set to the first TRB of the
next segment.
The driver expects those two values to be the same in this situation,
and uses the cycle state of the latter together with the address of the
former. This should be fine according to the XHCI specification, since
the endpoint ring should be stopped when returning the Transfer Event
and thus should not advance over the Link TRB before it gets restarted.
However, real-world XHCI implementations apparently don't really care
that much about these details, so the driver should follow a more
defensive approach to try to work around HC spec violations.
This patch removes the stopped_trb variable that had been used to store
the TRB Pointer from the last Transfer Event of a stopped TRB. Instead,
xhci_find_new_dequeue_state() now relies only on the Endpoint Context,
requiring a small amount of additional processing to find the virtual
address corresponding to the TR Dequeue Pointer. Some other parts of the
function were slightly rearranged to better fit into this model.
This patch should be backported to kernels as old as 2.6.31 that contain
the commit ae63674714 "USB: xhci: URB
cancellation support."
Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In commit a51435a313
Author: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Date: Wed Mar 12 16:39:40 2014 +0530
drm/i915: disable rings before HW status page setup
we reordered stopping the rings to do so before we set the HWS register.
However, there is an extra workaround for g45 to reset the rings twice,
and for consistency we should apply that workaround before setting the
HWS to be sure that the rings are truly stopped.
Reference: http://lkml.kernel.org/r/20140423202248.GA3621@amd.pavel.ucw.cz
Tested-by: Pavel Machek <pavel@ucw.cz>
Cc: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The status bits are unconditionally set, the control bits only enable
the actual interrupt generation. Which means if we get some random
other interrupts we'll bogusly complain about them.
So restrict the WARN to platforms with a sane hotplug interrupt
handling scheme. And even more important also don't attempt to process
the hpd bit since we've detected a storm already. Instead just clear
the bit silently.
This WARN has been introduced in
commit b8f102e8bf
Author: Egbert Eich <eich@suse.de>
Date: Fri Jul 26 14:14:24 2013 +0200
drm/i915: Add messages useful for HPD storm detection debugging (v2)
before that we silently handled the hpd event and so partially
defeated the storm detection.
v2: Pimp commit message (Jani)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Egbert Eich <eich@suse.de>
Cc: bitlord <bitlord0xff@gmail.com>
Reported-by: bitlord <bitlord0xff@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The hw cursor is relatively adept at triggering underflows, which
manifest as a "blue flash" (since blue is configured as the underflow
color). Juggle a few things around to tighten up the timing for setting
cursor registers in DONE irq.
And most importantly, don't ever disable the hw cursor. Instead flip it
to a blank/empty cursor. This seems far more reliable, as even simply
clearing the cursor-enable bit (with no other updates in previous/
following frames) can in some cases cause underflow.
v1: original
v2: add missing locking spotted by Micah
Cc: Micah Richert <richert@braincorporation.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since X11 is going to create an XR24 fb, if the pixel formats do not
match then crtc helpers will think it is a full modeset even if mode is
the same, which prevents smooth/flickerless handover from fbcon/plymouth
to X11.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This reverts commit d2bee8fb6e.
Enabling autosuspend for Intel Bluetooth devices has been shown to not
work reliable. It does work for some people with certain combinations
of USB host controllers, but for others it puts the device to sleep and
it will not wake up for any event.
These events can be important ones like HCI Inquiry Complete or HCI
Connection Request. The events will arrive as soon as you poke the
device with a new command, but that is not something we can do in
these cases.
Initially there were patches to the xHCI USB controller that fixed
this for some people, but not for all. This could be well a problem
somewhere in the USB subsystem or in the USB host controllers or
just plain a hardware issue somewhere. At this moment we just do
not know and the only safe action is to revert this patch.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Tedd Ho-Jeong An <tedd.an@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
brcmfmac has been broken on my cubietruck with a BCM43362:
brcmfmac: brcmf_chip_recognition: found AXI chip: BCM43362, rev=1
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
since commit 5303626103: "brcmfmac: update core reset and disable routines".
The problem is that since this commit brcmf_chip_ai_resetcore no longer sets
BCMA_IOCTL itself before bringing the core out of reset, instead relying on
brcmf_chip_ai_coredisable to do so. But brcmf_chip_ai_coredisable is a nop
of the chip is already in reset. This patch modifies brcmf_chip_ai_coredisable
to always set BCMA_IOCTL even if the core is already in reset.
This fixes brcmfmac hanging in firmware loading on my board.
Cc: stable@vger.kernel.org # v3.14
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit "ath9k: move sc_flags to ath_common" moved setting
ATH_OP_INVALID flag below ieee80211_register_hw. This is causing
the flag never being cleared randomly as the drv_start is called
prior to setting flag. Fix this by setting the flag prior to
register_hw.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While porting a RS485 driver from 2.6.29 to 3.14, i noticed that the serial tty
driver could break it by using uart ports that it does not own :
1. uart_change_pm ist called during uart_open and calls the uart pm function
without checking for PORT_UNKNOWN.
The fix is to move uart_change_pm from uart_open to uart_port_startup.
2. The return code from the uart request_port call in uart_set_info is not
handled properly, leading to the situation that the serial driver also
thinks it owns the uart ports.
This can triggered by doing following actions :
setserial /dev/ttyS0 uart none # release the uart ports
modprobe lirc-serial # or any other device that uses the uart
setserial /dev/ttyS0 uart 16550 # gives no error and the uart tty driver
# can use the ports as well
Signed-off-by: Thomas Pfaff <tpfaff@pcs.com>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The two functions to write out to the console (one used in normal
console mode and one in polling console mode) were slightly different.
One used a barrier() in its loop and the other a cpu_relax(). The
barrier() really doesn't do anything since we're using rd_regl() to
read the port anyway. Switch it to cpu_relax() to make things
consistent.
No known bugs / issues are fixed by this change--it just makes things
more consistent.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The s3c24xx_serial_console_putchar() is _only_ ever used by
s3c24xx_serial_console_write() and is called in a loop (indirectly
through uart_console_write()). There's no reason to call
s3c24xx_port_configured() for every iteration through the loop. Move
it outside the loop.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The two functions in the samsung serial driver used for writing
characters out to the port were inconsistent about whether they used
the passed in "port" or the global "cons_uart". There was no reason
to use the global and the use of the global in
s3c24xx_serial_put_poll_char() caused a crash in the case where you
used the serial port for kgdboc but not for console.
Fix it so we used the passed in variable.
Note that this doesn't fix all problems with the samsung serial
driver. Specifically:
* s3c24xx_serial_console_putchar() is still 99% identical to
s3c24xx_serial_put_poll_char() (the function signature is different,
but that's about it). A future patch will make them slightly less
identical and judging by other serial drivers we may need yet more
differences eventually.
* The samsung serial driver still doesn't allow you to have more than
one console port since it still uses the global cons_uart in
s3c24xx_serial_console_write().
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
__dma_tx_complete is not protected against concurrent
call of serial8250_tx_dma. it can lead to circular tail
index corruption or parallel call of serial_tx_dma on the
same data portion.
This patch fixes this issue by holding the port lock.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On transmit-hold-register empty, serial8250_tx_chars
should be called only if we don't use DMA.
DMA has its own tx cycle.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The race was introduced while development of linux-3.11 by
e8437d7ecb and
e9975fdec0.
Originally it was found and reproduced on linux-3.12.15 and
linux-3.12.15-rt25, by sending 500 byte blocks with 115kbaud to the
target uart in a loop with 100 milliseconds delay.
In short:
1. The consumer flush_to_ldisc is on to remove the head tty_buffer.
2. The producer adds a number of bytes, so that a new tty_buffer must
be allocated and added by __tty_buffer_request_room.
3. The consumer removes the head tty_buffer element, without handling
newly committed data.
Detailed example:
* Initial buffer:
* Head, Tail -> 0: used=250; commit=250; read=240; next=NULL
* Consumer: ''flush_to_ldisc''
* consumed 10 Byte
* buffer:
* Head, Tail -> 0: used=250; commit=250; read=250; next=NULL
{{{
count = head->commit - head->read; // count = 0
if (!count) { // enter
// INTERRUPTED BY PRODUCER ->
if (head->next == NULL)
break;
buf->head = head->next;
tty_buffer_free(port, head);
continue;
}
}}}
* Producer: tty_insert_flip_... 10 bytes + tty_flip_buffer_push
* buffer:
* Head, Tail -> 0: used=250; commit=250; read=250; next=NULL
* added 6 bytes: head-element filled to maximum.
* buffer:
* Head, Tail -> 0: used=256; commit=250; read=250; next=NULL
* added 4 bytes: __tty_buffer_request_room is called
* buffer:
* Head -> 0: used=256; commit=256; read=250; next=1
* Tail -> 1: used=4; commit=0; read=250 next=NULL
* push (tty_flip_buffer_push)
* buffer:
* Head -> 0: used=256; commit=256; read=250; next=1
* Tail -> 1: used=4; commit=4; read=250 next=NULL
* Consumer
{{{
count = head->commit - head->read;
if (!count) {
// INTERRUPTED BY PRODUCER <-
if (head->next == NULL) // -> no break
break;
buf->head = head->next;
tty_buffer_free(port, head);
// ERROR: tty_buffer head freed -> 6 bytes lost
continue;
}
}}}
This patch reintroduces a spin_lock to protect this case. Perhaps later
a lock-less solution could be found.
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@gmx.at>
Cc: stable <stable@vger.kernel.org> # 3.11
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This series contains straight-forward fixes for different
Versatile Express infrastructure drivers:
- NULL pointer dereference on the error path in the clk driver
- out of boundary array access in the dcscb driver
- broken restart/power off implementation
- mis-interpreted voltage unit in the spc driver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQEcBAABAgAGBQJTWTroAAoJEL9jRaJfXa5PHMkIAJB2S6zuqIxn7qRsfeD5YauR
nz7AHjDaakoVy6YTaMdHQI+dXSK6BPUNvMbrKzW3WWbT4ktJ/r3k/OeeBv/2T93L
8KW1Bbif7kPfdfITwCCWDs5waTDVXSBC6AGGoXomzQIt4MqghhzoLRc6uvhnuYAL
R7ZJsTWRa+47LVOJsghVffMyNlwCMj//prW7PBY6RIZXhpcbI+FGYv5Rm1XRITWn
uL2cSulBmWeqMVCR/gFx8/K5TqZ90q835dD1Ggh+BeB1Vaifu9/cI3D8w0hl/xy9
nRneKdTaTEpKjgwI3up4vMFbLbMI7brdMphZ9ZeGgK+YuWXFDbKvvdwjvDJ4Tx0=
=BS4Q
-----END PGP SIGNATURE-----
Merge tag 'vexpress/fixes-for-3.15' of git://git.linaro.org/people/pawel.moll/linux into fixes
ARM Versatile Express fixes for 3.15
This series contains straight-forward fixes for different
Versatile Express infrastructure drivers:
- NULL pointer dereference on the error path in the clk driver
- out of boundary array access in the dcscb driver
- broken restart/power off implementation
- mis-interpreted voltage unit in the spc driver
* tag 'vexpress/fixes-for-3.15' of git://git.linaro.org/people/pawel.moll/linux:
ARM: vexpress/TC2: Convert OPP voltage to uV before storing
power/reset: vexpress: Fix restart/power off operation
arm/mach-vexpress: array accessed out of bounds
clk: vexpress: NULL dereference on error path
Includes an update to 3.15-rc2
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:
irq: no irq domain found for /ocp/pinmux@48002030 !
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)
This is because we're wrongly trying to populate resources that are not
yet available. It's perfectly valid to create irqchips dynamically, so
let's fix up the issue by resolving the interrupt resources when
platform_get_irq is called.
And then we also need to accept the fact that some irqdomains do not
exist that early on, and only get initialized later on. So we can
make the current WARN_ON into just into a pr_debug().
We still attempt to populate irq resources when we create the devices.
This allows current drivers which don't use platform_get_irq to continue
to function. Once all drivers are fixed, this code can be removed.
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Grant Likely <grant.likely@linaro.org>
slc_xmit is called within softirq context and locks sl->lock, but
slcan_write_wakeup is not softirq context, so we need to use
spin_[un]lock_bh!
Detected using kernel lock debugging mechanism.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
When trying to set a data bitrate on non CAN FD devices the 'ip' tool
answers with:
RTNETLINK answers: Unknown error 524
Rename '-ENOTSUPP' to '-EOPNOTSUPP' so that 'ip' answers correctly:
RTNETLINK answers: Operation not supported
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
When accessing the SJA1000 controller registers in the indirect access mode,
writing the register number and reading/writing the data has to be an atomic
attempt.
As the sja1000_isa driver is an old style driver with a fixed number of
instances the locking variable depends on the same index like all the other
configuration elements given on the module command line.
As a positive side effect dev->dev_id is populated by the instance index,
which was missing in 3e66d0138c ("can: populate netdev::dev_id for udev
discrimination").
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Coverity complains that c_can_pci_probe() calls pci_enable_msi() without
checking the result:
CID 712278 (#1 of 1): Unchecked return value (CHECKED_RETURN) 3. check_return:
Calling pci_enable_msi_block without checking return value (as is done
elsewhere 88 out of 105 times).
88 pci_enable_msi(pdev);
This is CID 712278.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Reported-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Commit 6439fbce10 (can: c_can: fix error checking of priv->instance in
probe()) found the warning but applied a suboptimal solution. Since, both
pdev->id and of_alias_get_id() return integers, it makes sense to convert the
variable to an integer and avoid the cast.
Signed-off-by: Wolfram Sang <wsa@sang-engineering.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
It's suffcient to kill the TXIE bit in the message control register
even if the documentation of C and D CAN says that it's not allowed to
do that while MSGVAL is set. Reality tells a different story and this
change gives us another 2% of CPU back for not waiting on I/O.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Mark suggested to use one IF for the softirq and the other for the
xmit function to avoid the xmit lock.
That requires to write the frame into the interface first, then handle
the echo skb and store the dlc before committing the TX request to the
message ram.
We use an atomic to handle the active buffers instead of reading the
MSGVAL register as thats way faster especially on PCH/x86.
Suggested-by: Mark <mark5@del-llc.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Instead of obfuscating the code by artificial 16 bit splits use the
proper 32 bit assignments and split the result when writing to the
interface.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Remove the MASK from the TX transfer side.
Make the code readable and get rid of the annoying IFX_WRITE_XXX_16BIT
macros which are just obfuscating the code.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Sigh!
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Alexander reported that the new optimized handling of the RX fifo
causes random packet loss on Intel PCH C_CAN hardware.
After a few fruitless debugging sessions I got hold of a PCH (eg20t)
afflicted system. That machine does not have the CAN interface wired
up, but it was possible to reproduce the issue with the HW loopback
mode.
As Alexander observed correctly, clearing the NewDat flag along with
reading out the message buffer causes that issue on C_CAN, while D_CAN
handles that correctly.
Instead of restoring the original message buffer handling horror the
following workaround solves the issue:
transfer buffer to IF without clearing the NewDat
handle the message
clear NewDat bit
That's similar to the original code but conditional for C_CAN.
I really wonder why all user manuals (C_CAN, Intel PCH and some more)
recommend to clear the NewDat bit right away. The knows it all Oracle
operated by Gurgle does not unearth any useful information either. I
simply cannot believe that we are the first to uncover that HW issue.
Reported-and-tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The RX buffer split causes packet loss in the hardware:
What happens is:
RX Packet 1 --> message buffer 1 (newdat bit is not cleared)
RX Packet 2 --> message buffer 2 (newdat bit is not cleared)
RX Packet 3 --> message buffer 3 (newdat bit is not cleared)
RX Packet 4 --> message buffer 4 (newdat bit is not cleared)
RX Packet 5 --> message buffer 5 (newdat bit is not cleared)
RX Packet 6 --> message buffer 6 (newdat bit is not cleared)
RX Packet 7 --> message buffer 7 (newdat bit is not cleared)
RX Packet 8 --> message buffer 8 (newdat bit is not cleared)
Clear newdat bit in message buffer 1
Clear newdat bit in message buffer 2
Clear newdat bit in message buffer 3
Clear newdat bit in message buffer 4
Clear newdat bit in message buffer 5
Clear newdat bit in message buffer 6
Clear newdat bit in message buffer 7
Clear newdat bit in message buffer 8
Now if during that clearing of newdat bits, a new message comes in,
the HW gets confused and drops it.
It does not matter how many of them you clear. I put a delay between
clear of buffer 1 and buffer 2 which was long enough that the message
should have been queued either in buffer 1 or buffer 9. But it did not
show up anywhere. The next message ended up in buffer 1. So the
hardware lost a packet of course without telling it via one of the
error handlers.
That does not happen on all clear newdat bit events. I see one of 10k
packets dropped in the scenario which allows us to reproduce. But the
trace looks always the same.
Not splitting the RX Buffer avoids the packet loss but can cause
reordering. It's hard to trigger, but it CAN happen.
With that mode we use the HW as it was probably designed for. We read
from the buffer 1 upwards and clear the buffer as we get the
message. That's how all microcontrollers use it. So I assume that the
way we handle the buffers was never really tested. According to the
public documentation it should just work :)
Let the user decide which evil is the lesser one.
[ Oliver Hartkopp: Provided a sane config option and help text and
made me switch to favour potential and unlikely reordering over
packet loss ]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The driver handles pointlessly TWO interrupts per packet. The reason
is that it enables the status interrupt which fires for each rx and tx
packet and it enables the per message object interrupts as well.
The status interrupt merily acks or in case of D_CAN ignores the TX/RX
state and then the message object interrupt fires.
The message objects interrupts are only useful if all message objects
have hardware filters activated.
But we don't have that and its not simple to implement in that driver
without rewriting it completely.
So we can ditch the message object interrupts and handle the RX/TX
right away from the status interrupt. Instead of TWO we handle ONE.
Note: We must keep the TXIE/RXIE bits in the message buffers because
the status interrupt alone is not reliable enough in corner cases.
If we ever have the need for HW filtering, then this code needs a
complete overhaul and we can think about it then. For now we prefer a
lower interrupt load.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
On D_CAN the RXOK, TXOK and LEC bits are cleared/set on read of the
status register. No need to update them.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Instead of writing to the message object we can simply clear the
NewDat bit with the get method.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
If the allocation of the error skb fails, we still want to see the
error statistics.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Reading the LEC type with
return (mode & ENABLED) && (status & LEC_MASK);
is not guaranteed to return (status & LEC_MASK) if the enabled bit in
mode is set. It's guaranteed to return 0 or !=0.
Remove the inline function and call unconditionally into the
berr_handling code and return early when the reporting is disabled.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
If the allocation of an error skb fails, the state change handling
returns w/o doing any work. That leaves the interface in a wreckaged
state as the internal status is wrong.
Split the interface handling and the skb handling.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
There is no guarantee that the skb is in the same state after calling
net_receive_skb(). It might be freed or reused. Not really harmful as
its a read access, except you turn on the proper debugging options
which catch a use after free.
The whole can subsystem is full of this. Copy and paste ....
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The state change handler is called with device interrupts disabled
already. So no point in disabling them again when we enter bus off
state.
But what's worse is that we reenable the interrupts at the end of NAPI
poll unconditionally. So c_can_start() which is called from the
restart timer can trigger interrupts which confuse the hell out of the
half reinitialized driver/hw.
Remove the pointless device interrupt disable in the BUS_OFF handler
and prevent reenabling the device interrupts at the end of the poll
routine when the current state is BUS_OFF.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
c_can_start() enables interrupts way too early. The first enabling
happens when setting the control mode in c_can_chip_config() and then
again at the end of the function.
But that happens before napi_enable() and that means that an interrupt
which comes in will disable interrupts again and call napi_schedule,
which ignores the request and the later napi_enable() is not making
thinks work either. So the interface is up with all device interrupts
disabled.
Move the device interrupt after napi_enable() and add it to the other
callsites of c_can_start() in c_can_set_mode() and c_can_power_up()
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
All type checks in c_can.c are != BOSCH_D_CAN so nobody noticed so far
that the pci code does not update the type information.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The kernel oopses in phy_lookup() due to 'phy->init_data' being NULL if we
register PHYs from a device tree probing driver and then call phy_get() on a
device that has no representation in the device tree (e.g. a PCI device).
Checking the pointer before dereferening it and skipping an interation if
it's NULL prevents this kernel oops.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When OMAP_CONTROL_USB was renamed to OMAP_CONTROL_PHY (commit
14da699b), its dependencies were lost in the process. Nothing in the
commit message indicates that this removal was intentional, so I think
it was by accident and the dependencies should be restored.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Roger Quadros <rogerq@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The top-level phy-samsung-usb2 driver may be configured as a
loadable module, which currently causes link errors because
of the dependency on the exynos{5250,4x12,4210}_usb2_phy_config
symbol. Solving this could be achieved by exporting these
symbols, but as the SoC-specific parts of the driver are not
currently built as modules, it seems better to just link
everything into one module and avoid the need for the export.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix driver new_id sysfs-attribute removal deadlock by making sure to
not hold any locks that the attribute operations grab when removing the
attribute.
Specifically, usb_serial_deregister holds the table mutex when
deregistering the driver, which includes removing the new_id attribute.
This can lead to a deadlock as writing to new_id increments the
attribute's active count before trying to grab the same mutex in
usb_serial_probe.
The deadlock can easily be triggered by inserting a sleep in
usb_serial_deregister and writing the id of an unbound device to new_id
during module unload.
As the table mutex (in this case) is used to prevent subdriver unload
during probe, it should be sufficient to only hold the lock while
manipulating the usb-serial driver list during deregister. A racing
probe will then either fail to find a matching subdriver or fail to get
the corresponding module reference.
Since v3.15-rc1 this also triggers the following lockdep warning:
======================================================
[ INFO: possible circular locking dependency detected ]
3.15.0-rc2 #123 Tainted: G W
-------------------------------------------------------
modprobe/190 is trying to acquire lock:
(s_active#4){++++.+}, at: [<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94
but task is already holding lock:
(table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (table_lock){+.+.+.}:
[<c0075f84>] __lock_acquire+0x1694/0x1ce4
[<c0076de8>] lock_acquire+0xb4/0x154
[<c03af3cc>] _raw_spin_lock+0x4c/0x5c
[<c02bbc24>] usb_store_new_id+0x14c/0x1ac
[<bf007eb4>] new_id_store+0x68/0x70 [usbserial]
[<c025f568>] drv_attr_store+0x30/0x3c
[<c01690e0>] sysfs_kf_write+0x5c/0x60
[<c01682c0>] kernfs_fop_write+0xd4/0x194
[<c010881c>] vfs_write+0xbc/0x198
[<c0108e4c>] SyS_write+0x4c/0xa0
[<c000f880>] ret_fast_syscall+0x0/0x48
-> #0 (s_active#4){++++.+}:
[<c03a7a28>] print_circular_bug+0x68/0x2f8
[<c0076218>] __lock_acquire+0x1928/0x1ce4
[<c0076de8>] lock_acquire+0xb4/0x154
[<c0166b70>] __kernfs_remove+0x254/0x310
[<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94
[<c0169fb8>] remove_files.isra.1+0x48/0x84
[<c016a2fc>] sysfs_remove_group+0x58/0xac
[<c016a414>] sysfs_remove_groups+0x34/0x44
[<c02623b8>] driver_remove_groups+0x1c/0x20
[<c0260e9c>] bus_remove_driver+0x3c/0xe4
[<c026235c>] driver_unregister+0x38/0x58
[<bf007fb4>] usb_serial_bus_deregister+0x84/0x88 [usbserial]
[<bf004db4>] usb_serial_deregister+0x6c/0x78 [usbserial]
[<bf005330>] usb_serial_deregister_drivers+0x2c/0x4c [usbserial]
[<bf016618>] usb_serial_module_exit+0x14/0x1c [sierra]
[<c009d6cc>] SyS_delete_module+0x184/0x210
[<c000f880>] ret_fast_syscall+0x0/0x48
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(table_lock);
lock(s_active#4);
lock(table_lock);
lock(s_active#4);
*** DEADLOCK ***
1 lock held by modprobe/190:
#0: (table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]
stack backtrace:
CPU: 0 PID: 190 Comm: modprobe Tainted: G W 3.15.0-rc2 #123
[<c0015e10>] (unwind_backtrace) from [<c0013728>] (show_stack+0x20/0x24)
[<c0013728>] (show_stack) from [<c03a9a54>] (dump_stack+0x24/0x28)
[<c03a9a54>] (dump_stack) from [<c03a7cac>] (print_circular_bug+0x2ec/0x2f8)
[<c03a7cac>] (print_circular_bug) from [<c0076218>] (__lock_acquire+0x1928/0x1ce4)
[<c0076218>] (__lock_acquire) from [<c0076de8>] (lock_acquire+0xb4/0x154)
[<c0076de8>] (lock_acquire) from [<c0166b70>] (__kernfs_remove+0x254/0x310)
[<c0166b70>] (__kernfs_remove) from [<c0167aa0>] (kernfs_remove_by_name_ns+0x4c/0x94)
[<c0167aa0>] (kernfs_remove_by_name_ns) from [<c0169fb8>] (remove_files.isra.1+0x48/0x84)
[<c0169fb8>] (remove_files.isra.1) from [<c016a2fc>] (sysfs_remove_group+0x58/0xac)
[<c016a2fc>] (sysfs_remove_group) from [<c016a414>] (sysfs_remove_groups+0x34/0x44)
[<c016a414>] (sysfs_remove_groups) from [<c02623b8>] (driver_remove_groups+0x1c/0x20)
[<c02623b8>] (driver_remove_groups) from [<c0260e9c>] (bus_remove_driver+0x3c/0xe4)
[<c0260e9c>] (bus_remove_driver) from [<c026235c>] (driver_unregister+0x38/0x58)
[<c026235c>] (driver_unregister) from [<bf007fb4>] (usb_serial_bus_deregister+0x84/0x88 [usbserial])
[<bf007fb4>] (usb_serial_bus_deregister [usbserial]) from [<bf004db4>] (usb_serial_deregister+0x6c/0x78 [usbserial])
[<bf004db4>] (usb_serial_deregister [usbserial]) from [<bf005330>] (usb_serial_deregister_drivers+0x2c/0x4c [usbserial])
[<bf005330>] (usb_serial_deregister_drivers [usbserial]) from [<bf016618>] (usb_serial_module_exit+0x14/0x1c [sierra])
[<bf016618>] (usb_serial_module_exit [sierra]) from [<c009d6cc>] (SyS_delete_module+0x184/0x210)
[<c009d6cc>] (SyS_delete_module) from [<c000f880>] (ret_fast_syscall+0x0/0x48)
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If no valid CHID value has previously been set on an HWA, writing a
value of all zeros will cause a kernel panic in uwb_radio_stop because
wusbhc->uwb_rc has not been set. This patch skips the call to
uwb_radio_stop if wusbhc->uwb_rc has not been initialized.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nesting a spin_lock_irq/unlock_irq inside a lock that has already
disabled interrupts will enable interrupts before we are ready when
spin_unlock_irq is called. This patch converts the inner lock to use
spin_lock and spin_unlock instead.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
