I was seeing cases where I was losing interrupts when inserting and
removing SD cards. Sometimes the card would get "stuck" in the
inserted state.
I believe that the problem was related to the code to handle the case
where we needed both rising and falling edges. This code would
disable the interrupt as the polarity was switched. If an interrupt
came at the wrong time it could be lost.
We'll match what the gpio-dwapb.c driver does upstream and change the
interrupt polarity without disabling things.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Host controllers lacking the required internal vmmc regulator may still
follow the spec with regard to the LSB of SDHCI_POWER_CONTROL. Set the
SDHCI_POWER_ON bit when vmmc is enabled to encourage the controller to
to drive CMD, DAT, SDCLK.
This fixes a regression observed on some Qualcomm and Nvidia boards
caused by 5222161 mmc: sdhci: Improve external VDD regulator support.
Fixes: 52221610dd (mmc: sdhci: Improve external VDD regulator support)
Signed-off-by: Tim Kryger <tim.kryger@gmail.com>
Tested-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When setting base_reachable_time or base_reachable_time_ms on a
specific interface through sysctl or netlink, the reachable_time
value is not updated.
This means that neighbour entries will continue to be updated using the
old value until it is recomputed in neigh_period_work (which
recomputes the value every 300*HZ).
On systems with HZ equal to 1000 for instance, it means 5mins before
the change is effective.
This patch changes this behavior by recomputing reachable_time after
each set on base_reachable_time or base_reachable_time_ms.
The new value will become effective the next time the neighbour's timer
is triggered.
Changes are made in two places: the netlink code for set and the sysctl
handling code. For sysctl, I use a proc_handler. The ipv6 network
code does provide its own handler but it already refreshes
reachable_time correctly so it's not an issue.
Any other user of neighbour which provide its own handlers must
refresh reachable_time.
Signed-off-by: Jean-Francois Remy <jeff@melix.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
On i.MX28, the MDIO bus is shared between the two FEC instances.
The driver makes sure that the second FEC uses the MDIO bus of the
first FEC. This is done conditionally if FEC_QUIRK_ENET_MAC is set.
However, in newer designs, such as Vybrid or i.MX6SX, each FEC MAC
has its own MDIO bus. Simply removing the quirk FEC_QUIRK_ENET_MAC
is not an option since other logic, triggered by this quirk, is
still needed.
Furthermore, there are board designs which use the same MDIO bus
for both PHY's even though the second bus would be available on the
SoC side. Such layout are popular since it saves pins on SoC side.
Due to the above quirk, those boards currently do work fine. The
boards in the mainline tree with such a layout are:
- Freescale Vybrid Tower with TWR-SER2 (vf610-twr.dts)
- Freescale i.MX6 SoloX SDB Board (imx6sx-sdb.dts)
This patch adds a new quirk FEC_QUIRK_SINGLE_MDIO for i.MX28, which
makes sure that the MDIO bus of the first FEC is used in any case.
However, the boards above do have a SoC with a MDIO bus for each FEC
instance. But the PHY's are not connected in a 1:1 configuration. A
proper device tree description is needed to allow the driver to
figure out where to find its PHY. This patch fixes that shortcoming
by adding a MDIO bus child node to the first FEC instance, along
with the two PHY's on that bus, and making use of the phy-handle
property to add a reference to the PHY's.
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull LED fix from Bryan Wu.
* 'leds-fixes-for-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
leds: netxbig: fix oops at probe time
it was agreement that WRITE_ONCE(x, val) is better than ASSIGN_ONCE(val, x)
Lets change that for 3.19 as 3.19 has no user yet, but the first users
will hit linux-next soon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iQIcBAABAgAGBQJUtXl3AAoJEBF7vIC1phx8QLsQAIthwLT9FC94YWYrKYkC1CT3
CY8gvjVXIki+CVs/a1qdcvuKXj4qLHBDO2ignhPvbqesmHyqIa010gsIT7sm6/d4
GyDY5AIzoeBFW8jYwVZGr+OMxjgZCTTopqB/vO//CI4aVHB2pE9Jw4cNA6Rl8uWo
SRXJXBWIw6nKElpTvqjV2PQXiOFqssfW5asjedzHfwpeJucjk3q59K54/RG19EUs
uqFVoElQMMiJ8QPlb91gYWH4AAdoc/G+YQkxlwt95638U6TKX/5FHc02glvgMNtI
EYt4/Aavn/NQLGUMeDF2IxptUCbr4F7GcSkYgYFeaYWPssgOAkMdtxyDT9SwwEt5
Oyq27CJ9TGPzdjRACteR+NUm6I5wOsy/mLX54BoumUGrApYtZzIvJDDEmIuWDzl8
OdrSR1+D9oi31gcL4qMJEIAe4s+ALJ/witFcdAoEXPugZsV4mkjBB7sEew1qrha9
WovyVsqlTnKtpNaoqPWH6jdBdsW49YsEVLVxsS5BT+48ZAYQEDXcAHJ1t65mQfsk
0c9hIwiOgt5Y1nNe0CMaQ6zLpzBRhf+wUAsg/fDZgB/P0O+Yg9XnGlNqL6WPV9xP
HK3PVgabzYcAr+ahEwvN3Ng5SE1FJ5xUv6kXhnVVjkOrfCMbgrckNHHVr4mvzK0n
E4VlqRGrSzfSqE7RuS2s
=GROK
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux
Pull WRITE_ONCE argument order change from Christian Borntraeger:
"As discussed on LKML[1] it was agreed that WRITE_ONCE(x, val) is
better than ASSIGN_ONCE(val, x)
Lets change that for 3.19 as 3.19 has no user yet, but the first users
will hit linux-next soon"
[1] http://marc.info/?l=linux-kernel&m=142081181707596
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux:
kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)
In netfront the Rx and Tx path are independent and use different
locks. The Tx lock is held with hard irqs disabled, but Rx lock is
held with only BH disabled. Since both sides use the same stats lock,
a deadlock may occur.
[ INFO: possible irq lock inversion dependency detected ]
3.16.2 #16 Not tainted
---------------------------------------------------------
swapper/0/0 just changed the state of lock:
(&(&queue->tx_lock)->rlock){-.....}, at: [<c03adec8>]
xennet_tx_interrupt+0x14/0x34
but this lock took another, HARDIRQ-unsafe lock in the past:
(&stat->syncp.seq#2){+.-...}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&stat->syncp.seq#2);
local_irq_disable();
lock(&(&queue->tx_lock)->rlock);
lock(&stat->syncp.seq#2);
<Interrupt>
lock(&(&queue->tx_lock)->rlock);
Using separate locks for the Rx and Tx stats fixes this deadlock.
Reported-by: Dmitry Piotrovsky <piotrovskydmitry@gmail.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since ALE table is a common resource for both the interfaces in Dual EMAC
mode and while bringing up the second interface in cpsw_ndo_set_rx_mode()
all the multicast entries added by the first interface is flushed out and
only second interface multicast addresses are added. Fixing this by
flushing multicast addresses based on dual EMAC port vlans which will not
affect the other emac port multicast addresses.
Fixes: d9ba8f9 (driver: net: ethernet: cpsw: dual emac interface implementation)
Cc: <stable@vger.kernel.org> # v3.9+
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes a NULL pointer dereference on led_dat->mode_val. Due to
this bug, a kernel oops can be observed at probe time on the LaCie 2Big
and 5Big v2 boards:
Unable to handle kernel NULL pointer dereference at virtual address 00000008
[...]
[<c03f244c>] (netxbig_led_probe) from [<c02c8c6c>] (platform_drv_probe+0x4c/0x9c)
[<c02c8c6c>] (platform_drv_probe) from [<c02c72d0>] (driver_probe_device+0x98/0x25c)
[<c02c72d0>] (driver_probe_device) from [<c02c7520>] (__driver_attach+0x8c/0x90)
[<c02c7520>] (__driver_attach) from [<c02c5c24>] (bus_for_each_dev+0x68/0x94)
[<c02c5c24>] (bus_for_each_dev) from [<c02c6408>] (bus_add_driver+0x124/0x1dc)
[<c02c6408>] (bus_add_driver) from [<c02c7ac0>] (driver_register+0x78/0xf8)
[<c02c7ac0>] (driver_register) from [<c000888c>] (do_one_initcall+0x80/0x1cc)
[<c000888c>] (do_one_initcall) from [<c0733618>] (kernel_init_freeable+0xe4/0x1b4)
[<c0733618>] (kernel_init_freeable) from [<c058db9c>] (kernel_init+0xc/0xec)
[<c058db9c>] (kernel_init) from [<c0009850>] (ret_from_fork+0x14/0x24)
[...]
This bug was introduced by commit 588a6a9928
("leds: netxbig: fix attribute-creation race").
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: <stable@vger.kernel.org> # 3.17+
Acked-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
In commit 5ad24def21 ("cxgb4vf: Fix ethtool get_settings for VF driver")
mdio_addr of port_info structure was used unininitialzed. Fixing it.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Until the driver is corrected to stop using mach/at91isam9_smc.h, it won't
compile in a ARCH_MULTIPLATFORM configuration.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The QEMU open source machine emulator and virtualizer presents firmware
and operating systems running in virtual machines ("guests") with purely
virtual hardware (ie. hardware that has never existed in physical form).
Since QEMU exposes some of these devices in a DTB, it makes sense to
define "qemu" and "virtio" as vendor prefixes.
The qemu definition is from [1], revision 4451 (22:24, 25 November 2014).
The virtio definition is composed from [2] and [3].
[1] http://wiki.qemu.org/Main_Page
[2] http://docs.oasis-open.org/virtio/virtio/v1.0/csprd01/virtio-v1.0-csprd01.html
[3] http://en.wikipedia.org/wiki/OASIS_%28organization%29
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Peter Maydell suggested that we describe new devices / DTB nodes in the
kernel Documentation tree that we expose to arm "virt" guests in QEMU.
Although the kernel is not required to access the fw_cfg interface,
"Documentation/devicetree/bindings/arm" is probably the best central spot
to keep the fw_cfg description in.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Just fix a minor typo about the example path.
Signed-off-by: Kaixu Xia <xiakaixu@huawei.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Rob Herring <robh@kernel.org>
fix the dev_dbg to display the offset which is the calculated
dma_pfn_offset value and set later in the code.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Current vendor-prefixes.txt already has "ak" prefix for Asahi Kasei Corp
by ae8c4209af2c(of: Add vendor prefix for Asahi Kasei Corp.)
It went through the appropriate review process. But, almost all
Asahi Kasei chip drivers are using "asahi-kasei" prefix today.
(arch/arm/boot/dts/tegra20-seaboard.dts only is using "ak,ak8975",
but there are instances of "asahi-kasei,ak8975" in other dts files.
And drivers/iio/magnetometer/ak8975.c doesn't support "ak,ak8975" prefix)
So, we made a mistake there.
In addition, checkpatch.pl reports WARNING if it is using "asahi-kasei"
prerfix in DT file.
(DT compatible string vendor "asahi-kasei" appears un-documented)
Marking it deprecated and warning with checkpatch is certainly
preferable. So, this patch replace "ak" to "asahi-kasei" in
vendor-prefixes.txt. (and fixup tegra20-seaboard)
OTOH, Asahi Kasei is usually referred to as "AKM", but this patch
doesn't care about it. Because no DT is using that today.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Per Grant, secretlab.ca is defunct and he has moved his tree to
kernel.org so update the DT website and git tree. devicetree.org needs
work, but is better than "Internal Server Error" that secretlab.ca
returns.
Cc: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
The regex matching on of_get_property and of_match_table cause Grant and
me to be copied on loads of drivers as well as be listed as maintainers
of those drivers. I believe the intent here was to check for documenting
of properties, but that has proven horribly ineffective. checkpatch now
at least partially covers this checking compatible strings. So remove
these regex's to reduce the firehose somewhat.
Cc: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Feedback has shown that WRITE_ONCE(x, val) is easier to use than
ASSIGN_ONCE(val,x).
There are no in-tree users yet, so lets change it for 3.19.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Davidlohr Bueso <dave@stgolabs.net>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
This update contains 3 patches to fix one compile error,
and two run-time bugs. One of them fixes infinite loop
on ARM.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUtVidAAoJEAsCRMQNDUMcUiAP/inLnr7pl9TX3bOWBE7NAb34
Xf70i9wozKC0ZQmfkfIMKwB4iJmapu4u73U0PvdEx+EULRLj2v/DvzAJDbTjczRo
/XtHJfq+fdewjQjn2z4Z+kMj9QblA79wgmBps/YgV+6y+pAoiluGyNPFv3t3CszF
IkJfPNkKUXr8g2y4/2/rP8nl6XQnmEdm4cN3vWLDTQFBd38+zeGvWnAej2I5XWOn
0wa1DeDWhzRsEFIsW970xOD6DPw9KyN9N5IOPxRP7OzNRxMysbS7xrksclyCHmQu
qmsSMscuLXrwmZvai2JHppEkxcnQQGb0gh/I/SICniF4S36nZzsW1GTqiDBLwS1i
S8iadd4kS3hu8KLXHO5SH5Jtq7sQdxol1mLLrkkXSccoFWR64wFuia0ifcQxUh4j
8bibMBDf/auO2K5b4b+kqK9wwflxZRpO3HKslrBmy3DKEXfu2jJ6KiofnFYgcjhx
1uKfwqDz4MU1o6qgw4IMBMW8GfSAai8tQ1B3IJ0aAQpS5ZLlaG6bYCwqu+eo8Wba
/3SW48EUwlxVHH09nax0TVzmtPZaWheTO8cpRG+Oeg0Nn6pO0PyX2531qApYp/JR
sUk6OoCUz50yhqMtNozmcK1S6w5kDaVySkrr/Wc6p5HcMhav4OWWWTJ5Hze5kypp
XnAd9OyI/AzJKZq51i6a
=nVlg
-----END PGP SIGNATURE-----
Merge tag 'linux-kselftest-3.19-rc-5' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
Pull kselftest fixes from Shuah Khan:
"This update contains three patches to fix one compile error, and two
run-time bugs. One of them fixes infinite loop on ARM"
* tag 'linux-kselftest-3.19-rc-5' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
selftests/vm: fix link error for transhuge-stress test
tools: testing: selftests: mq_perf_tests: Fix infinite loop on ARM
selftests/exec: allow shell return code of 126
- Several critical linear p2m fixes that prevented some hosts from
booting.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAABAgAGBQJUtQHNAAoJEFxbo/MsZsTR/qgH/iiW4k2T8dBGZ7TPyzt88iyT
4caWjuujp2OUaRqhBQdY7z05uai6XxgJLwDyqiO+qHaRUj+ZWCrjh/ZFPU1+09hK
GdwPMWU7xMRs/7F2ANO03jJ/ktvsYXtazcVrV89Q3t+ZZJIQ/THovDkaoa+dF2lh
W8d5H7N2UNCJLe9w2fm5iOq4SKoTsJOq6pVQ6gUBqJcgkSDWavd6bowXnTlcepZN
tNaSMZsOt4CAvYQIa0nKPJo6Q4QN3buRQMWEOAOmGVT/RkVi68wirwk59uNzcS7E
HjhqxFjhXYamNTuwHYZlchBrZutdbymSlucVucb1wAoxRAX+Wd1jk5EPl6zLv4w=
=kFSE
-----END PGP SIGNATURE-----
Merge tag 'stable/for-linus-3.19-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen bug fixes from David Vrabel:
"Several critical linear p2m fixes that prevented some hosts from
booting"
* tag 'stable/for-linus-3.19-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
x86/xen: properly retrieve NMI reason
xen: check for zero sized area when invalidating memory
xen: use correct type for physical addresses
xen: correct race in alloc_p2m_pmd()
xen: correct error for building p2m list on 32 bits
x86/xen: avoid freeing static 'name' when kasprintf() fails
x86/xen: add extra memory for remapped frames during setup
x86/xen: don't count how many PFNs are identity mapped
x86/xen: Free bootmem in free_p2m_page() during early boot
x86/xen: Remove unnecessary BUG_ON(preemptible()) in xen_setup_timer()
Corrected the comment describing the ndo operations to
reflect the actual prototype for couple of operations
Signed-off-by: B Viswanath <marichika4@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The "smemc" clock is removed on BG2Q SoCs. In fact, bit19 of clkenable
register is for nfc. Current code use bit19 for non-exist "smemc"
incorrectly, this prevents eMMC from working due to the sdhci's
"core" clk is still gated.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Cc: stable@vger.kernel.org # 3.16+
Signed-off-by: Michael Turquette <mturquette@linaro.org>
All slow clk users are not properly claiming it (get + prepare + enable)
before using it.
If all users properly claiming this clock release it, the clock is
disabled, but faulty users still depends on it, and the system hangs.
This fix prevents the slow clock from being disabled, and should solve the
hanging issue, but offending drivers should be patched to properly claim
this clock.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Bo Shen <voice.shen@atmel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Pull thermal management fixes from Zhang Rui:
"Specifics:
- Fix a problem that Intel SoC DTS thermal driver does not work when
CONFIG_THERMAL_INT340X is not set.
- Fix a NULL pointer dereference when processor_thermal_device driver
is loaded on a platform without ACPI support"
* 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
int340x_thermal/processor_thermal_device: return failure when
ACPI/int340x_thermal: enumerate INT3401 for Intel SoC DTS thermal driver
ACPI/int340x_thermal: enumerate INT340X devices even if they're not in _ART/_TRT
In case of PCI driver we will get a warning:
dw_dmac_pci 0000:00:18.0: Unbalanced pm_runtime_enable!
dw_dmac_pci 0000:00:18.0: DesignWare DMA Controller, 8 channels
This happens due to pm_runtime_enable() call from the driver when PM runtime is
enabled by core.
This patch moves that call to the platform driver where it might make sense.
Fixes: bb32baf76e (dmaengine: dw: enable runtime PM)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
This patch removes a duplicate AHCI-mode SATA Device ID for the Intel Sunrise Point PCH.
Signed-off-by: James Ralston <james.d.ralston@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The driver was recently adapted to a core API change, but the
change was incomplete, missing out the suspend helper and
leaving an extraneous local variable around:
usb/phy/phy-mv-usb.c: In function 'mv_otg_update_state':
usb/phy/phy-mv-usb.c:341:18: warning: unused variable 'phy' [-Wunused-variable]
usb/phy/phy-mv-usb.c: In function 'mv_otg_suspend':
usb/phy/phy-mv-usb.c:861:16: error: 'struct usb_phy' has no member named 'state'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: e47d92545c ("usb: move the OTG state from the USB PHY to the OTG structure")
Signed-off-by: Felipe Balbi <balbi@ti.com>
Sparse emits a bunch of warnings in mips-cm.h due to casting away of
__iomem by the addr_gcr_*() functions:
arch/mips/include/asm/mips-cm.h:134:1: warning: cast removes address space of expression
And subsequent passing of the return values to __raw_readl() and
__raw_writel() in the read_gcr_*() and write_gcr_*() functions:
arch/mips/include/asm/mips-cm.h:134:1: warning: incorrect type in argument 2 (different address spaces)
arch/mips/include/asm/mips-cm.h:134:1: expected void volatile [noderef] <asn:2>*mem
arch/mips/include/asm/mips-cm.h:134:1: got unsigned int [usertype] *
arch/mips/include/asm/mips-cm.h:134:1: warning: incorrect type in argument 1 (different address spaces)
arch/mips/include/asm/mips-cm.h:134:1: expected void const volatile [noderef] <asn:2>*mem
arch/mips/include/asm/mips-cm.h:134:1: got unsigned int [usertype] *
Fix by adding __iomem to the addr_gcr_*() return type and cast.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8874/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
[...]
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
arch/mips/Kconfig:2681:error: recursive dependency detected!
arch/mips/Kconfig:2681: symbol MIPS32_N32 depends on MIPS32_COMPAT
arch/mips/Kconfig:2658: symbol MIPS32_COMPAT is selected by MIPS32_N32
Introduced by d74473bdf7a4c1ef7ae2b75f585fe5649ac2dcea (MIPS: Compat: Fix
build error if CONFIG_MIPS32_COMPAT but no compat ABI.)
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
In that case nor __NR_seccomp_*_32 symbols will be defined in
<asm/unistd.h> so the attempt to use it in kernel.seccomp.c will fail
with:
kernel/seccomp.c:565:2: error: '__NR_seccomp_read_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:24: error: '__NR_seccomp_write_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:47: error: '__NR_seccomp_exit_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:69: error: '__NR_seccomp_sigreturn_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
Solved by changing the compat ABIs in kconfig to select MIPS32_COMPAT
directly. This also means the user no longer has to select MIPS32_COMPAT
before being able to see the ABI options.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fixes sparse warnings:
arch/mips/jz4740/irq.c:63:6: warning: symbol 'jz4740_irq_suspend' was not declared. Should it be static?
arch/mips/jz4740/irq.c:69:6: warning: symbol 'jz4740_irq_resume' was not declared. Should it be static?
Also, I've seen some elusive build errors on my automated build test
where JZ4740_IRQ_BASE and NR_IRQS are missing, but I can't reproduce
them manually for some reason. Anyway, mach-jz4740/irq.h should help us
avoid relying on some implicit include.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8724/
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
In particular the use of the antiquated PIX PATA drivers was a nuiscance
since most userland has switched to the new /dev/sda drivers as well as
the lack of EXT4.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commit 4227a2d4ef (MIPS: Support for hybrid
FPRs) changes the kernel to execute read_c0_config5() even on processors
that don't have a Config5 register. According to the arch spec the
behaviour of trying to read or write this register is UNDEFINED where this
register doesn't exist, that is merely looking at this register is
already cruel because that might kill a kitten.
In case of Qemu older than v2.2 Qemu has elected to implement this
UNDEFINED behaviour by taking a RI exception - which then fries the
kernel:
[...]
Freeing YAMON memory: 956k freed
Freeing unused kernel memory: 240K (80674000 - 806b0000)
Reserved instruction in kernel code[#1]:
CPU: 0 PID: 1 Comm: init Not tainted 3.18.0-rc6-00058-g4227a2d #26
task: 86047588 ti: 86048000 task.ti: 86048000
$ 0 : 00000000 77a638cc 00000000 00000000
[...]
For qemu v2.2.0 commit f31b035a9f10dc9b57f01c426110af845d453ce2
(target-mips: correctly handle access to unimplemented CP0 register)
changed the behaviour to returning zero on read and ignoring writes
which more matches how typical hardware implementations actually behave.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
static code analysis from cppcheck reports:
[drivers/video/fbdev/broadsheetfb.c:673]:
(error) Memory leak: sector_buffer
sector_buffer is not being kfree'd on each call to
broadsheet_spiflash_rewrite_sector(), so free it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
commit 0efaa7e82f
locks: generic_delete_lease doesn't need a file_lock at all
moves the call to fl->fl_lmops->lm_change() to a place in the
code where fl might be a non-lease lock.
When that happens, fl_lmops is NULL and an Oops ensures.
So add an extra test to restore correct functioning.
Reported-by: Linda Walsh <suse@tlinx.org>
Link: https://bugzilla.suse.com/show_bug.cgi?id=912569
Cc: stable@vger.kernel.org (v3.18)
Fixes: 0efaa7e82f
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jeff Layton <jlayton@primarydata.com>
Commit 5d26a105b5 ("crypto: prefix module autoloading with "crypto-"")
changed the automatic module loading when requesting crypto algorithms
to prefix all module requests with "crypto-". This requires all crypto
modules to have a crypto specific module alias even if their file name
would otherwise match the requested crypto algorithm.
Even though commit 5d26a105b5 added those aliases for a vast amount of
modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
annotations to those files to make them get loaded automatically, again.
This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
with kernels v3.18 and below.
Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
won't work for crypto modules any more.
Fixes: 5d26a105b5 ("crypto: prefix module autoloading with "crypto-"")
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
of_platform_device_create is only defined when CONFIG_OF_ADDRESS is set,
which is normally always the case when CONFIG_OF is defined, except on Sparc,
so explicitly check for CONFIG_OF_ADDRESS rather then for CONFIG_OF.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Using the native code here can't work properly, as the hypervisor would
normally have cleared the two reason bits by the time Dom0 gets to see
the NMI (if passed to it at all). There's a shared info field for this,
and there's an existing hook to use - just fit the two together. This
is particularly relevant so that NMIs intended to be handled by APEI /
GHES actually make it to the respective handler.
Note that the hook can (and should) be used irrespective of whether
being in Dom0, as accessing port 0x61 in a DomU would be even worse,
while the shared info field would just hold zero all the time. Note
further that hardware NMI handling for PVH doesn't currently work
anyway due to missing code in the hypervisor (but it is expected to
work the native rather than the PV way).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
BAR tx cmd tid was set to non qos (8). This is wrong as BAR
should be sent with the tid of the BA session.
This led to a corruption in the firmware. The visible
effect of this from the driver side is the BA notification
that comes back after the BAR. It was botched and led to the
WARNING below.
------------[ cut here ]------------
WARNING: CPU: 2 PID: 17707 at /home/tester/workspace_hostap/iwlwifi/drivers/net/wireless/iwlwifi/mvm/tx.c:976 iwl_mvm_rx_ba_notif+0x4ba/0x4d0 [iwlmvm]()
Q 4500, tid 8, flow 65535
Modules linked in: iwlmvm(O) mac80211(O) iwlwifi(O) cfg80211(O) compat(O) netconsole configfs ctr ccm arc4 autofs4 microcode bnep rfcomm snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel joydev snd_hda_codec uvcvideo videobuf2_core snd_hwdep videodev snd_pcm videobuf2_vmalloc videobuf2_memops i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device drm_kms_helper dell_wmi dell_laptop drm btusb bluetooth snd psmouse i2c_algo_bit sparse_keymap wmi soundcore 6lowpan_iphc dcdbas serio_raw video lpc_ich ppdev mac_hid parport_pc nfsd nfs_acl auth_rpcgss nfs fscache binfmt_misc lockd sunrpc lp parport msdos sdhci_pci sdhci mmc_core ahci libahci e1000e ptp pps_core [last unloaded: compat]
CPU: 2 PID: 17707 Comm: irq/46-iwlwifi Tainted: G W O 3.14.17-patched #4
Hardware name: Dell Inc. Latitude E6430/0CPWYR, BIOS A09 12/13/2012
00000000 00000000 ebd49d6c c1616221 f985dbdc ebd49d9c c1044e44 f9861df4
ebd49dc8 0000452b f985dbdc 000003d0 f98395da f98395da ebd49f10 eaf3d8a4
0000ffff ebd49db4 c1044f03 00000009 ebd49dac f9861df4 ebd49dc8 ebd49e64
Call Trace:
[<c1616221>] dump_stack+0x41/0x52
[<c1044e44>] warn_slowpath_common+0x84/0xa0
[<f98395da>] ? iwl_mvm_rx_ba_notif+0x4ba/0x4d0 [iwlmvm]
[<f98395da>] ? iwl_mvm_rx_ba_notif+0x4ba/0x4d0 [iwlmvm]
[<c1044f03>] warn_slowpath_fmt+0x33/0x40
[<f98395da>] iwl_mvm_rx_ba_notif+0x4ba/0x4d0 [iwlmvm]
[<c10e3952>] ? ring_buffer_unlock_commit+0xa2/0xd0
[<c10e9767>] ? trace_buffer_unlock_commit+0x37/0x50
[<f98568a3>] ? iwl_tm_mvm_send_rx+0x53/0x90 [iwlmvm]
[<f98327a8>] iwl_mvm_rx_dispatch+0x108/0x130 [iwlmvm]
[<f9eac7e7>] iwl_pcie_irq_handler+0xf17/0x15b0 [iwlwifi]
[<c10994c1>] irq_thread_fn+0x21/0x50
[<c109926c>] irq_thread+0xec/0x110
[<c10994a0>] ? irq_thread_dtor+0xb0/0xb0
[<c10993f0>] ? irq_finalize_oneshot.part.34+0xc0/0xc0
[<c1099180>] ? wake_threads_waitq+0x40/0x40
[<c1062fdb>] kthread+0x9b/0xb0
[<c1627137>] ret_from_kernel_thread+0x1b/0x28
[<c1062f40>] ? flush_kthread_worker+0x90/0x90
---[ end trace 5e0f67374816db17 ]---
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
If the asssocated access point is strong byBBVGACurrent will be adjusted
accordingly.
Users will nolonger see distant access points without taking down interface.
When changing channel reset byBBVGACurrent back to pDevice->abyBBVGA[0] for
max sensitivity.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move PSTxDesc->m_td1TD1 to inside spin locks.
if m_td1TD1.byTCR has TCR_EDP and TCR_STP are set, the interrupt handler will
try and complete the buffer before it is completed. Usually on the tail
of a burst of tx packets.
This results in a partially completed packet being transmitted or worse
sitll dead lock when skb is freed by the interrupt handler.
Set head_td->m_td1TD1.byTCR to 0 in first lock of vnt_tx_packet to stop
interrupt handler completing the buffer. Move Set TSR1 & ReqCount in
s_cbFillTxBufHead to the second lock.
cbReqCount is carried to the second lock in pTDInfo->dwReqCount without
the padding removed.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
