Pull MIPS fixes from Ralf Baechle:
- MIPS didn't define the new ioremap_uc. Defined it as an alias for
ioremap_uncached.
- Replace workaround for MIPS16 build issue with a correct one.
* git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: Define ioremap_uc
MIPS: UAPI: Ignore __arch_swab{16,32,64} when using MIPS16
Revert "MIPS: UAPI: Fix unrecognized opcode WSBH/DSBH/DSHD when using MIPS16."
Pull swiotlb fixlet from Konrad Rzeszutek Wilk:
"Enable the SWIOTLB under 32-bit PAE kernels.
Nowadays most distros enable this due to CONFIG_HYPERVISOR|XEN=y which
select SWIOTLB. But for those that are not interested in
virtualization and wanting to use 32-bit PAE kernels and wanting to
have working DMA operations - this configures it for them"
* 'stable/for-linus-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb:
swiotlb: Enable it under x86 PAE
Leandro Awa writes:
"After switching to version 4.1.6, our parallelized and distributed
workflows now fail consistently with errors of the form:
T34: ./regex.c:39:22: error: config.h: No such file or directory
From our 'git bisect' testing, the following commit appears to be the
possible cause of the behavior we've been seeing: commit 766c4cbfacd8"
Al Viro says:
"What happens is that 766c4cbfac got the things subtly wrong.
We used to treat d_is_negative() after lookup_fast() as "fall with
ENOENT". That was wrong - checking ->d_flags outside of ->d_seq
protection is unreliable and failing with hard error on what should've
fallen back to non-RCU pathname resolution is a bug.
Unfortunately, we'd pulled the test too far up and ran afoul of
another kind of staleness. The dentry might have been absolutely
stable from the RCU point of view (and we might be on UP, etc), but
stale from the remote fs point of view. If ->d_revalidate() returns
"it's actually stale", dentry gets thrown away and the original code
wouldn't even have looked at its ->d_flags.
What we need is to check ->d_flags where 766c4cbfac does (prior to
->d_seq validation) but only use the result in cases where we do not
discard this dentry outright"
Reported-by: Leandro Awa <lawa@nvidia.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=104911
Fixes: 766c4cbfac ("namei: d_is_negative() should be checked...")
Tested-by: Leandro Awa <lawa@nvidia.com>
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
- Two fixes for cpufreq regressions, an acpi-cpufreq driver one
introduced during the 4.2 cycle when we started to preserve
cpufreq directories for offline CPUs and a general one
introduced recently (Srinivas Pandruvada).
- Two devfreq fixes, one for a double kfree() in an error code
path and one for a confusing sysfs-related failure (Geliang Tang,
Tobias Jakobi).
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJWGEL/AAoJEILEb/54YlRxnqsP/i9hnNDDhm1L+WW6YfB++BmY
LRhYSIKY73Q7ILXyk06tZLaOu5C1hohMNWfJKHJBROaMtSCgT1xE3OYD14a7QVQW
fWVejjOnOmxZOkgC/t7x6ZQBHSd/j8L+EFQkwWhU5Q7H7ezj4e7pf4pPZRvEz2rI
aJEipY7AYKGKB+q3RlkXsFZiMA59z1rebbZA+aOsIytZwtUhNL0XeTXuT+G3VQ0Z
YP65JZjXYvyl+JxkUhEGqcYK5VO2TBTrRuBqb9lUGo8IruKhIsEjnq9tsLtF69SX
HBJ1AS5dAxZOcRXHbea/8+nB4e1kPwKespqgCc8w4ggSz51uV+YI7lwiD5Py7dWc
3uZTpUv1fqiy0HM1br/IKus2KyZMglHx6k5MbtMrt/Xi1MFuG3b4sNcZs/tY6jXN
Jl3X+a0ne3zY2+XDQgwYEnqNnTUQyVDRSkbE8sG57Bs3T2EcXiaI2HF+9XuYnDLg
zC8T/VO9L122yGBnAakP5rtFapNB3AdHjJ0OTezTpOiAgekLkNX5/Yp+wI4ZJrog
jSDBeNDNsO717kttTD0hzUmcrLYCoLtn/oRnGEUxheT4QEUz+De8h9ycFaJOMaRp
sGs1y/Hv//4aj7XMSz3xmyhJ0GMsBmcmc5I/DIYpvHnHPvTHWU/+inTG/PhE3dKj
euPLl6ofOaoEjy0W+Jgg
=oLdU
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI fixes from Rafael Wysocki:
"These are four fixes for bugs in the devfreq and cpufreq subsystems,
including two regression fixes (one for a recent regression and one
for a problem introduced in 4.2).
Specifics:
- Two fixes for cpufreq regressions, an acpi-cpufreq driver one
introduced during the 4.2 cycle when we started to preserve cpufreq
directories for offline CPUs and a general one introduced recently
(Srinivas Pandruvada).
- Two devfreq fixes, one for a double kfree() in an error code path
and one for a confusing sysfs-related failure (Geliang Tang, Tobias
Jakobi)"
* tag 'pm+acpi-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: prevent lockup on reading scaling_available_frequencies
cpufreq: acpi_cpufreq: prevent crash on reading freqdomain_cpus
PM / devfreq: fix double kfree
PM / devfreq: Fix governor_store()
Pull strscpy powerpc fix from Chris Metcalf.
Fix powerpc big-endian build.
* 'strscpy' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
arch/powerpc: provide zero_bytemask() for big-endian
We see various small fixes, but nothing looks too scary, all are
small gentle bug fixes:
- Most of changes are for ASoC codecs: Realtek, SGTL5000, TAS2552,
TLV320, WM8962
- A couple of dwc and imx-ssi fixes
- Usual oneliner HD-audio quirks
- An old emux synth code fix
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJWF3nMAAoJEGwxgFQ9KSmklqgP/A9ShFKf/m/Swwtvzhn01GP7
jBY5n4xvH7e9ThYmRpDQJ5XJX8TuKjWnyxeo/c1Ym3U8a8hgiEgJPp+eo98iEQ2s
thK9Ie9p/AlEsThdvnPxHPSZoM5grx90fpG/m4CYlZJGfBcUYOSC9hnZnxKjdu7f
mHto/T7Xj7um0rZLp0tqvp6vVktvefhMbRNC/LhCZhGbB5OFpNMwSbD3benGKIcj
YIJiazEtfzTmqX4R5wNICX8mhEVQkBGTINKPIMTt5sMMClUuzAUNaGvZSXHSPlbB
AkqHsT2GMagNv9uyz7dT2xTURHNrU3k3QBlPAE3Bufu1JEBHf4qYfwPvY3XM2+Jx
79estFRhb+WpExLSkQsuycsSbLmRhTKstSwGF3u2Bg047BpF4tV0UwNizFO3cUU+
sz18IfqxmWlbJCB6JdRFRzSD12mSaKPmrtcLHjQt3kvS8nD1qWLlBCy4lgx8oRPW
tz0gEEp16gbVBhZQt9WsrL8Jbs995dJoR14t1Xjk81jK01kR01szfdCWR6mT9HH5
lzuzpCnW4mVrDec+Eyh7P1P/BOGlWHievv1McV4vYfql+E+WB2KxBRrd7cqLaIen
CRCm6knMmk/6lf8LaVVA5c4N/RkP3UmfMgMOBQgU038vqGVwSDzogvG/H21zMc4W
HBfw9/7EVVTzM0YsFLsI
=gld/
-----END PGP SIGNATURE-----
Merge tag 'sound-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"We see various small fixes, but nothing looks too scary, all are small
gentle bug fixes:
- Most of changes are for ASoC codecs: Realtek, SGTL5000, TAS2552,
TLV320, WM8962
- A couple of dwc and imx-ssi fixes
- Usual oneliner HD-audio quirks
- An old emux synth code fix"
* tag 'sound-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
MAINTAINERS: Remove wm97xx entry
ASoC: tas2552: fix dBscale-min declaration
ALSA: synth: Fix conflicting OSS device registration on AWE32
ALSA: hda - Disable power_save_node for IDT 92HD73xx chips
ALSA: hda - Apply SPDIF pin ctl to MacBookPro 12,1
ALSA: hda: Add dock support for ThinkPad T550
ASoC: dwc: fix dma stop transferring issue
ASoC: dwc: correct irq clear method
ASoC: tlv320aic3x: Prevent writing reserved registers on tlv320aic3104 CODECs
ASoC: rt5645: Correct the naming and setting of ADC Boost Volume Control
ASoC: sgtl5000: fix wrong register MIC_BIAS_VOLTAGE setup on probe
ASoC: wm8962: balance pm_runtime_enable
ASoC: imx-ssi: Fix DAI hardware signal inversions
ASoC: sgtl5000: fix error message output for MicBias voltage
ASoC: db1200: Fix DAI link format for db1300 and db1550
- DM core AB-BA deadlock fix in the device destruction path (vs device
creation's DM table swap).
- DM raid fix to properly round up the region_size to the next
power-of-2.
- DM cache fix for a NULL pointer seen while switching from the
"cleaner" cache policy.
2 fixes for regressions introduced during the 4.3 merge:
- request-based DM error propagation regressed due to incorrect
changes introduced when adding the bi_error field to bio.
- DM snapshot fix to only support snapshots that overflow if the client
(e.g. lvm2) is prepared to deal with the associated snapshot status
interface change.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWGC/jAAoJEMUj8QotnQNaTgYIAJz1AG5IcHz8D3zi8+MBWXFL
WAYrXfXSxexsymVKFsqi6z9fYiW5fRZ41/+Kl8/dYnhBIS8uUzWlad2qw/JFg+zC
l/EzdHWjakzuGm9/quK2h/CBC/3pmRH9UeKgzOPODOpAzkJfrKoO4/J7JPIi3JyP
esE/2F2TBwERL4oC74UB7/nuM/xckS/DRjbd3B82/IsfM5n+MARvuSSrqWcPEu8h
Hh5k42KyA+Tq7uElLnXF8phFOCJCn9IyI+QLdxj33PfDxwrtXMvV6Sxw7FS8b7oF
/gw3Dod4sEv+EJZ1A+O9mxGBk3ajCpMvUYbcY6owIHyB1mKWiSKyvyBPyIY6RiQ=
=2z9t
-----END PGP SIGNATURE-----
Merge tag 'dm-4.3-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull dm fixes from Mike Snitzer:
"Three stable fixes:
- DM core AB-BA deadlock fix in the device destruction path (vs
device creation's DM table swap).
- DM raid fix to properly round up the region_size to the next
power-of-2.
- DM cache fix for a NULL pointer seen while switching from the
"cleaner" cache policy.
Two fixes for regressions introduced during the 4.3 merge:
- request-based DM error propagation regressed due to incorrect
changes introduced when adding the bi_error field to bio.
- DM snapshot fix to only support snapshots that overflow if the
client (e.g. lvm2) is prepared to deal with the associated
snapshot status interface change"
* tag 'dm-4.3-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm snapshot: add new persistent store option to support overflow
dm cache: fix NULL pointer when switching from cleaner policy
dm: fix request-based dm error reporting
dm raid: fix round up of default region size
dm: fix AB-BA deadlock in __dm_destroy()
Pull btrfs fixes from Chris Mason:
"These are small and assorted. Neil's is the oldest, I dropped the
ball thinking he was going to send it in"
* 'for-linus-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
Btrfs: support NFSv2 export
Btrfs: open_ctree: Fix possible memory leak
Btrfs: fix deadlock when finalizing block group creation
Btrfs: update fix for read corruption of compressed and shared extents
Btrfs: send, fix corner case for reference overwrite detection
The fixes for this week include one small patch that was years in the
making and that finally fixes using all eight CPUs on exynos542x.
The rest are lots of minor changes for sunxi, imx, exynos and shmobile
* fixing the minimum voltage for Allwinner A20
* thermal boot issue on SMDK5250.
* invalid clock used for FIMD IOMMU.
* audio on Renesas r8a7790/r8a7791
* invalid clock used for FIMD IOMMU
* LEDs on exynos5422-odroidxu3-common
* usb pin control for imx-rex
* imx53: fix PMIC interrupt level
* a Makefile typo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUAVhbS1GCrR//JCVInAQLwiQ/+LeAAqODQKpLI9BhKSSa1YiPgs8zr/O+q
6SpyNf969j2d67hhDbBNIrcNw7bdYElogq+2emrPnsJ/o/GX18VFs+41s+zb2P1r
dxmH9LA7wrUg05nc/TgyYXJZQa+JIZBymYJ6Kc9cdbkhmRZazAcV6POT4ZG5qfER
QDwPGwBn/wXLMZ0yJnocUVexTn+GUdy0b7XRg141PYtYHg+mA0EEPHqul1IyB/rV
W5u9HoA86mWLH+8CEzl7RTCXEPga/+ScxqimDFMW7Ok6F+CkPnD7u5z92p8dU38T
J0Dc/xSA9w+8Y4AQuN1qM7g5W/qNszozaBusshIMF+UK5dDEEwWpdpvRr4mLpqLS
hohu7zUel3V5n846Rwkr181Hh9yn5V7MiJ0vjj5gYmYeteLs5Gar94I/vnd9BMrD
7lJo0aTMcoQNIvf2i1SEfyhQW/YOdWiU452sxtzNFe/wJ/6hdQxx/qgBMA1Dxm7/
s1+bQ3ndBa5qiiTcVg5XBAGnxe5Eo7lqHStDyJ6hy3v8nt5ew1iPbBt8XEwHonDC
8whzRKQMI70hz5nQoMLjEwiGhT3yFQu2IyrFD2yPldq2i4VC2iZybWianKa5BXlu
16Easzhk05uZu340+tqCxxGwTaVSjNcJ+HRHRvW4cw6sReCeUPOtlnzlOGRufZpO
pi2gCB3aTnY=
=IsHY
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Arnd Bergmann:
"The fixes for this week include one small patch that was years in the
making and that finally fixes using all eight CPUs on exynos542x.
The rest are lots of minor changes for sunxi, imx, exynos and shmobile
- fixing the minimum voltage for Allwinner A20
- thermal boot issue on SMDK5250.
- invalid clock used for FIMD IOMMU.
- audio on Renesas r8a7790/r8a7791
- invalid clock used for FIMD IOMMU
- LEDs on exynos5422-odroidxu3-common
- usb pin control for imx-rex
- imx53: fix PMIC interrupt level
- a Makefile typo"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: dts: Fix wrong clock binding for sysmmu_fimd1_1 on exynos5420
ARM: dts: Fix bootup thermal issue on smdk5250
ARM: shmobile: r8a7791 dtsi: Add CPG/MSTP Clock Domain for sound
ARM: shmobile: r8a7790 dtsi: Add CPG/MSTP Clock Domain for sound
arm-cci500: Don't enable PMU driver by default
ARM: dts: fix usb pin control for imx-rex dts
ARM: imx53: qsrb: fix PMIC interrupt level
ARM: imx53: include IRQ dt-bindings header
ARM: dts: add suspend opp to exynos4412
ARM: dts: Fix LEDs on exynos5422-odroidxu3
ARM: EXYNOS: reset Little cores when cpu is up
ARM: dts: Fix Makefile target for sun4i-a10-itead-iteaduino-plus
ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to meet SoC specifications
Commit 76c44f6d80 introduced the possibly for "Overflow" to be reported
by the snapshot device's status. Older userspace (e.g. lvm2) does not
handle the "Overflow" status response.
Fix this incompatibility by requiring newer userspace code, that can
cope with "Overflow", request the persistent store with overflow support
by using "PO" (Persistent with Overflow) for the snapshot store type.
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Fixes: 76c44f6d80 ("dm snapshot: don't invalidate on-disk image on snapshot write overflow")
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Recent Linux clients have started to send GETLAYOUT requests with
minlength less than blocksize.
Servers aren't really allowed to impose this kind of restriction on
layouts; see RFC 5661 section 18.43.3 for details.
This has been observed to cause indefinite hangs on fsx runs on some
clients.
Cc: stable@vger.kernel.org
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
When a device group is detached from its domain, the iommu
core code calls into the iommu driver to detach each device
individually.
Before this functionality went into the iommu core code, it
was implemented in the drivers, also in the AMD IOMMU
driver as the device alias handling code.
This code is still present, as there might be aliases that
don't exist as real PCI devices (and are therefore invisible
to the iommu core code).
Unfortunatly it might happen now, that a device is unbound
multiple times from its domain, first by the alias handling
code and then by the iommu core code (or vice verca).
This ends up in the do_detach function which dereferences
the dev_data->domain pointer. When the device is already
detached, this pointer is NULL and we get a kernel oops.
Removing the alias code completly is not an option, as that
would also remove the code which handles invisible aliases.
The code could be simplified, but this is too big of a
change outside the merge window.
For now, just check the dev_data->domain pointer in
do_detach and bail out if it is NULL.
Reported-by: Andreas Hartmann <andihartmann@freenet.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
AMD IOMMU driver makes use of IOMMU PCI devices, so prevent binding other
PCI drivers to IOMMU PCI devices.
This fixes a bug reported by Boris that system suspend/resume gets broken
on AMD platforms. For more information, please refer to:
https://lkml.org/lkml/2015/9/26/89
Fixes: 991de2e590 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()")
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
As we're about to remove the of_node field from the irqdomain
structure, introduce an accessor for it. Subsequent patches
will take care of the actual repainting.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Link: http://lkml.kernel.org/r/1444402211-1141-1-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
A recent cleanup removed the 'irq' parameter from many functions, but
left the documentation for this in place for at least one function.
This removes it.
Fixes: bd0b9ac405 ("genirq: Remove irq argument from irq flow handlers")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: kbuild-all@01.org
Cc: Austin Schuh <austin@peloton-tech.com>
Cc: Santosh Shilimkar <ssantosh@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/5400000.cD19rmgWjV@wuerfel
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
A cleanup of the omap gpio driver introduced a use of the
handle_bad_irq() function in a device driver that can be
a loadable module.
This broke the ARM allmodconfig build:
ERROR: "handle_bad_irq" [drivers/gpio/gpio-omap.ko] undefined!
This patch exports the handle_bad_irq symbol in order to
allow the use in modules.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Santosh Shilimkar <ssantosh@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Austin Schuh <austin@peloton-tech.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/5847725.4IBopItaOr@wuerfel
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Or Gerlitz says:
====================
Mellanox driver update to 4.3-rc4
Small set of fixes for net, which includes Carol's patches, a fix
from Achiad to have the right behaviour for mlx5 Eth devices w.r.t
VLANs in promiscuous mode, a good-bye patch from Ido who left Mellanox
and the 1st patch from Jiri to our NIC drivers (I love one-liners)...
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove Ido Shamay as co-maintainer for the mlx4 Ethernet driver,
as he no longer works for Mellanox.
Signed-off-by: Ido Shamay <idos@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the device was set to promiscuous mode, we didn't disable
VLAN filtering, which is wrong behaviour, fix that.
Now when the device is set to promiscuous mode RX packets
sent over any VLAN (or no VLAN tag at all) will be accepted.
Signed-off-by: Achiad Shochat <achiad@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We used the wrong register name for querying the PVLC register
Fixes: a124d13ef5 ('net/mlx5_core: Add more query port helpers')
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Test interrupts fails if not all completion vectors called
request_irq. This case happens if only mlx4_en is loaded and
we have more completion vectors than rx rings.
Fixes: c66fa19c40 ('net/mlx4: Add EQ pool')
Signed-off-by: Carol L Soto <clsoto@linux.vnet.ibm.com>
Acked-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The cleaner policy doesn't make use of the per cache block hint space in
the metadata (unlike the other policies). When switching from the
cleaner policy to mq or smq a NULL pointer crash (in dm_tm_new_block)
was observed. The crash was caused by bugs in dm-cache-metadata.c
when trying to skip creation of the hint btree.
The minimal fix is to change hint size for the cleaner policy to 4 bytes
(only hint size supported).
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
With atomic drivers we need to make sure that (at least in general)
property reads hold the right locks. But the legacy dpms property is
special and can be read locklessly. Since userspace loves to just
randomly look at that all the time (like with "status") do that.
To make it clear that we play tricks use the READ_ONCE compiler
barrier (and also for paranoia).
Note that there's not really anything bad going on since even with the
new atomic paths we eventually end up not chasing any pointers (and
hence possibly freed memory and other fun stuff). The locking WARNING
has been added in
commit 88a48e297b
Author: Rob Clark <robdclark@gmail.com>
Date: Thu Dec 18 16:01:50 2014 -0500
drm: add atomic properties
but since drivers are converting not everyone will have seen this from
the start.
Jens reported this and submitted a patch to just grab the
mode_config.connection_mutex, but we can do a bit better.
v2: Remove unused variables I failed to git add for real.
Reference: http://mid.gmane.org/20150928194822.GA3930@kernel.dk
Reported-by: Jens Axboe <axboe@fb.com>
Tested-by: Jens Axboe <axboe@fb.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radeon and amdgpu fixes for 4.3. Highlights:
- Move pm sysfs setup later in the driver init process to avoid
problems with laptop scripts attempting to change pm settings
before the driver has finished setting up the pm hardware.
- Fix console restore if a drm app (e.g. X) is forcibly killed
- Flag iceland support as experimental for now
- Misc bug fixes
* 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: fix memory leak in amdgpu_vm_update_page_directory
drm/amdgpu: fix 32-bit compiler warning
drm/amdgpu: flag iceland as experimental
drm/amdgpu: check before checking pci bridge registers
drm/amdgpu: fix num_crtc on CZ
drm/amdgpu: restore the fbdev mode in lastclose
drm/radeon: restore the fbdev mode in lastclose
drm/radeon: add quirk for ASUS R7 370
drm/amdgpu: add pm sysfs files late
drm/radeon: add pm sysfs files late
The commit 55ce74d4bf (md/raid1: ensure
device failure recorded before write request returns) is causing crash in
the LVM2 testsuite test shell/lvchange-raid.sh. For me the crash is 100%
reproducible.
The reason for the crash is that the newly added code in raid1d moves the
list from conf->bio_end_io_list to tmp, then tests if tmp is non-empty and
then incorrectly pops the bio from conf->bio_end_io_list (which is empty
because the list was alrady moved).
Raid-10 has a similar bug.
Kernel Fault: Code=15 regs=000000006ccb8640 (Addr=0000000100000000)
CPU: 3 PID: 1930 Comm: mdX_raid1 Not tainted 4.2.0-rc5-bisect+ #35
task: 000000006cc1f258 ti: 000000006ccb8000 task.ti: 000000006ccb8000
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00001000000001001111111000001111 Not tainted
r00-03 000000ff0804fe0f 000000001059d000 000000001059f818 000000007f16be38
r04-07 000000001059d000 000000007f16be08 0000000000200200 0000000000000001
r08-11 000000006ccb8260 000000007b7934d0 0000000000000001 0000000000000000
r12-15 000000004056f320 0000000000000000 0000000000013dd0 0000000000000000
r16-19 00000000f0d00ae0 0000000000000000 0000000000000000 0000000000000001
r20-23 000000000800000f 0000000042200390 0000000000000000 0000000000000000
r24-27 0000000000000001 000000000800000f 000000007f16be08 000000001059d000
r28-31 0000000100000000 000000006ccb8560 000000006ccb8640 0000000000000000
sr00-03 0000000000249800 0000000000000000 0000000000000000 0000000000249800
sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
IASQ: 0000000000000000 0000000000000000 IAOQ: 000000001059f61c 000000001059f620
IIR: 0f8010c6 ISR: 0000000000000000 IOR: 0000000100000000
CPU: 3 CR30: 000000006ccb8000 CR31: 0000000000000000
ORIG_R28: 000000001059d000
IAOQ[0]: call_bio_endio+0x34/0x1a8 [raid1]
IAOQ[1]: call_bio_endio+0x38/0x1a8 [raid1]
RP(r2): raid_end_bio_io+0x88/0x168 [raid1]
Backtrace:
[<000000001059f818>] raid_end_bio_io+0x88/0x168 [raid1]
[<00000000105a4f64>] raid1d+0x144/0x1640 [raid1]
[<000000004017fd5c>] kthread+0x144/0x160
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Fixes: 55ce74d4bf ("md/raid1: ensure device failure recorded before write request returns.")
Fixes: 95af587e95 ("md/raid10: ensure device failure recorded before write request returns.")
Signed-off-by: NeilBrown <neilb@suse.com>
All unrecovered machine check errors on PowerNV should cause an
immediate panic. There are 2 reasons that this is the right policy:
it's not safe to continue, and we're already trying to reboot.
Firstly, if we go through the recovery process and do not successfully
recover, we can't be sure about the state of the machine, and it is
not safe to recover and proceed.
Linux knows about the following sources of Machine Check Errors:
- Uncorrectable Errors (UE)
- Effective - Real Address Translation (ERAT)
- Segment Lookaside Buffer (SLB)
- Translation Lookaside Buffer (TLB)
- Unknown/Unrecognised
In the SLB, TLB and ERAT cases, we can further categorise these as
parity errors, multihit errors or unknown/unrecognised.
We can handle SLB errors by flushing and reloading the SLB. We can
handle TLB and ERAT multihit errors by flushing the TLB. (It appears
we may not handle TLB and ERAT parity errors: I will investigate
further and send a followup patch if appropriate.)
This leaves us with uncorrectable errors. Uncorrectable errors are
usually the result of ECC memory detecting an error that it cannot
correct, but they also crop up in the context of PCI cards failing
during DMA writes, and during CAPI error events.
There are several types of UE, and there are 3 places a UE can occur:
Skiboot, the kernel, and userspace. For Skiboot errors, we have the
facility to make some recoverable. For userspace, we can simply kill
(SIGBUS) the affected process. We have no meaningful way to deal with
UEs in kernel space or in unrecoverable sections of Skiboot.
Currently, these unrecovered UEs fall through to
machine_check_expection() in traps.c, which calls die(), which OOPSes
and sends SIGBUS to the process. This sometimes allows us to stumble
onwards. For example we've seen UEs kill the kernel eehd and
khugepaged. However, the process killed could have held a lock, or it
could have been a more important process, etc: we can no longer make
any assertions about the state of the machine. Similarly if we see a
UE in skiboot (and again we've seen this happen), we're not in a
position where we can make any assertions about the state of the
machine.
Likewise, for unknown or unrecognised errors, we're not able to say
anything about the state of the machine.
Therefore, if we have an unrecovered MCE, the most appropriate thing
to do is to panic.
The second reason is that since e784b6499d ("powerpc/powernv: Invoke
opal_cec_reboot2() on unrecoverable machine check errors."), we
attempt a special OPAL reboot on an unhandled MCE. This is so the
hardware can record error data for later debugging.
The comments in that commit assert that we are heading down the panic
path anyway. At the moment this is not always true. With UEs in kernel
space, for instance, they are marked as recoverable by the hardware,
so if the attempt to reboot failed (e.g. old Skiboot), we wouldn't
panic() but would simply die() and OOPS. It doesn't make sense to be
staggering on if we've just tried to reboot: we should panic().
Explicitly panic() on unrecovered MCEs on PowerNV.
Update the comments appropriately.
This fixes some hangs following EEH events on cxlflash setups.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reviewed-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
native_hpte_clear() is called in real mode from two places:
- Early in boot during htab initialisation if firmware assisted dump is
active.
- Late in the kexec path.
In both contexts there is no need to disable interrupts are they are
already disabled. Furthermore, locking around the tlbie() is only required
for pre POWER5 hardware.
On POWER5 or newer hardware concurrent tlbie()s work as expected and on pre
POWER5 hardware concurrent tlbie()s could result in deadlock. This code
would only be executed at crashdump time, during which all bets are off,
concurrent tlbie()s are unlikely and taking locks is unsafe therefore the
best course of action is to simply do nothing. Concurrent tlbie()s are not
possible in the first case as secondary CPUs have not come up yet.
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
When scaling_available_frequencies is read on an offlined cpu, then
either lockup or junk values are displayed. This is caused by
freed freq_table, which policy is using.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The Atmel sdhci device needs the
SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RST quirk. Without it, the
internal clock could never stabilised when changing the sd clock
frequency.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The Atmel sdhci device needs a new quirk. sdhci_set_clock set the Clock
Control Register to 0 before computing the new value and writing it.
It disables the internal clock which causes a reset mecanism. If we
write the new value before this reset mecanism is done, it will prevent
the stabilisation of the internal clock, so a delay is needed. This
delay is about 2-3 cycles of the base clock. To be safe, a 1 ms delay is
used.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In case of armada_38x_quirks error, all clocks should be cleaned-up, same
as after mv_conf_mbus_windows failure.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Cc: <stable@vger.kernel.org> # v4.2
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
According to 'FE-2946959' erratum the clock inversion option is
needed to support slow frequencies when the card input hold time
requirement is high. This setting is not required for high speed
MMC and might cause timing violation.
Signed-off-by: Nadav Haklai <nadavh@marvell.com>
Cc: <stable@vger.kernel.org> # v4.2
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
shci-pxav3 driver is enabling by default the
SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN quirk. However this quirk is not
required for Armada 38x and leads to wrong clock setting in the divider.
Signed-off-by: Nadav Haklai <nadavh@marvell.com>
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Cc: <stable@vger.kernel.org> # v4.2
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
For some reason, only the little-endian flavor of
powerpc provided the zero_bytemask() implementation.
Reported-by: Michal Sojka <sojkam1@fel.cvut.cz>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
We need to explicitly check the AVX and AES CPU features, as we can't
infer them from the related XSAVE feature flags. For example, the
Core i3 2310M passes the XSAVE feature test but does not implement
AES-NI.
Reported-and-tested-by: Stéphane Glondu <glondu@debian.org>
References: https://bugs.debian.org/800934
Fixes: ce4f5f9b65 ("x86/fpu, crypto x86/camellia_aesni_avx: Simplify...")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: stable <stable@vger.kernel.org> # 4.2
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Some of the crypto algorithms write to the initialization vector,
but no space has been allocated for it. This clobbers adjacent memory.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
If we get MAX_MSIX interrupts would like to have each receive ring
with his own msix interrupt line. Do not need the shared_ports
variable at mlx4_enable_msix
Fixes: 9293267a3e ('net/mlx4_core: Capping number of requested MSIXs to MAX_MSIX')
Signed-off-by: Carol L Soto <clsoto@linux.vnet.ibm.com>
Acked-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
"Y" was the right answer for MDIO_OCTEON when this option was only
available on CAVIUM_OCTEON_SOC. But now that the option is visible on
all (64-bit) systems, this piece of advice no longer makes sense. This
helper module is selected automatically by drivers which need it
anyway.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes: a6d6786452 ("net: mdio-octeon: Modify driver to work on both ThunderX and Octeon")
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Sunil Goutham <sgoutham@cavium.com>
Cc: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
Cc: David Daney <david.daney@cavium.com>
Cc: David S. Miller <davem@davemloft.net>
Acked-by: David Daney <david.daney@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The recently added mlxsw driver produces warnings in ARM
allmodconfig:
drivers/net/ethernet/mellanox/mlxsw/pci.c: In function 'mlxsw_pci_cmd_exec':
drivers/net/ethernet/mellanox/mlxsw/pci.c:1585:59: warning: right shift count >= width of type [-Wshift-count-overflow]
linux/byteorder/big_endian.h:38:51: note: in definition of macro '__cpu_to_be32'
drivers/net/ethernet/mellanox/mlxsw/pci.c:76:2: note: in expansion of macro 'iowrite32be'
This uses upper_32_bits() to extract the bits while avoiding that warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Fixes: eda6500a98 "mlxsw: Add PCI bus implementation"
Signed-off-by: David S. Miller <davem@davemloft.net>
Similar to commit c29390c6df ("xps: must clear sender_cpu before forwarding")
the skb->sender_cpu needs to be cleared before xmit.
Fixes: 3896d655f4 ("bpf: introduce bpf_clone_redirect() helper")
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Similar to commit c29390c6df ("xps: must clear sender_cpu before forwarding")
the skb->sender_cpu needs to be cleared when moving from Rx
Tx, otherwise kernel could crash.
Fixes: 2bd82484bb ("xps: fix xps for stacked devices")
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make unix_sk() just like inet[6]_sk() by constify'ing the sock
parameter.
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Starting with commit 7d607f9170 ("mmc: host: omap_hsmmc: use
devm_regulator_get_optional() for vmmc") MMC on omap3 stopped working
for legacy booting.
This is because legacy booting sets up some of the resource in the
platform init code, and for optional regulators always seem to
return -EPROBE_DEFER for the legacy booting.
Let's fix the issue by checking for device tree based booting for
now. Then when omap3 boots in device tree only mode, this patch
can be just reverted.
Fixes: 7d607f9170 ("mmc: host: omap_hsmmc: use
devm_regulator_get_optional() for vmmc")
Cc: Felipe Balbi <balbi@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This reverts commit c55d7a0553.
Without reverting this commit we get "unbalanced disables for pbias_mmc_omap4"
errors on omap4430. It seems that 4430 and 4460 behave in a different way for
the PBIAS regulator registers and until that has been debugged further we
cannot rely on the regulator status registers in hardare on 4430.
Fixes: 7d607f9170 ("mmc: host: omap_hsmmc: use
devm_regulator_get_optional() for vmmc")
Cc: Felipe Balbi <balbi@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
