This patch removes unnecessary blank lines in prism2fw.c file to
comply with the standard kernel coding style.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fix open parenthesis alignment matching in prism2fw.c file
to comply with the standard kernel coding style.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch removes unnecessary blank line in p80211wep.c file to
comply with the standard kernel coding style.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Comparison to NULL could be written in preferred form.
Change it to comply with the standard kernel coding style.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fix open parenthesis alignment in p80211req.c file to
comply with the standard kernel coding style.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fix open parenthesis alignment in hfa384x_usb.c file to
comply with the standard kernel coding style.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch avoids using BUG_ON() from driver,
and return from hfa384x_usbin_callback with WARN_ON()
if skb was NULL or data in skb is different from expected one.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch removes unnecessary parentheses in different statements of
hfa384x_usb.c file in order to to comply with the standard kernel
coding style.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fix the following checkpatch script warning:
WARNING: Possible unnecessary 'out of memory' message.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fix the following checkpatch.pl script warning:
WARNING: line over 80 characters
It also add spaces between or operators inside the macro to
comply with the standard kernel coding style.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The TIOCMIWAIT implementation would return -EINVAL if any of the three
supported signals were included in the mask.
Instead of returning an error in case TIOCM_CTS is included, simply
drop the mask check completely, which is in accordance with how other
drivers implement this ioctl.
Fixes: 5a6a62bdb9 ("cdc-acm: add TIOCMIWAIT")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't pass a size larger than iov_len to kernel_sendmsg().
Otherwise it will cause a NULL pointer deref when kernel_sendmsg()
returns with rv < size.
DRBD as external module has been around in the kernel 2.4 days already.
We used to be compatible to 2.4 and very early 2.6 kernels,
we used to use
rv = sock_sendmsg(sock, &msg, iov.iov_len);
then later changed to
rv = kernel_sendmsg(sock, &msg, &iov, 1, size);
when we should have used
rv = kernel_sendmsg(sock, &msg, &iov, 1, iov.iov_len);
tcp_sendmsg() used to totally ignore the size parameter.
57be5bd ip: convert tcp_sendmsg() to iov_iter primitives
changes that, and exposes our long standing error.
Even with this error exposed, to trigger the bug, we would need to have
an environment (config or otherwise) causing us to not use sendpage()
for larger transfers, a failing connection, and have it fail "just at the
right time". Apparently that was unlikely enough for most, so this went
unnoticed for years.
Still, it is known to trigger at least some of these,
and suspected for the others:
[0] http://lists.linbit.com/pipermail/drbd-user/2016-July/023112.html
[1] http://lists.linbit.com/pipermail/drbd-dev/2016-March/003362.html
[2] https://forums.grsecurity.net/viewtopic.php?f=3&t=4546
[3] https://ubuntuforums.org/showthread.php?t=2336150
[4] http://e2.howsolveproblem.com/i/1175162/
This should go into 4.9,
and into all stable branches since and including v4.0,
which is the first to contain the exposing change.
It is correct for all stable branches older than that as well
(which contain the DRBD driver; which is 2.6.33 and up).
It requires a small "conflict" resolution for v4.4 and earlier, with v4.5
we dropped the comment block immediately preceding the kernel_sendmsg().
Fixes: b411b3637f ("The DRBD driver")
Cc: <stable@vger.kernel.org> # 2.6.33.x-
Cc: viro@zeniv.linux.org.uk
Cc: christoph.lechleitner@iteg.at
Cc: wolfgang.glas@iteg.at
Reported-by: Christoph Lechleitner <christoph.lechleitner@iteg.at>
Tested-by: Christoph Lechleitner <christoph.lechleitner@iteg.at>
Signed-off-by: Richard Weinberger <richard@nod.at>
[changed oneliner to be "obvious" without context; more verbose message]
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
We have a couple of drivers, acpi_apd.c and acpi_lpss.c,
that need to pass extra build-in properties to the devices
they create. Previously the drivers added those properties
to the struct device which is member of the struct
acpi_device, but that does not work. Those properties need
to be assigned to the struct device of the platform device
instead in order for them to become available to the
drivers.
To fix this, this patch changes acpi_create_platform_device
function to take struct property_entry pointer as parameter.
Fixes: 20a875e2e8 (serial: 8250_dw: Add quirk for APM X-Gene SoC)
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Tested-by: Yazen Ghannam <yazen.ghannam@amd.com>
Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
3 more amdgpu fixes.
* 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux:
drm/amd/powerplay: return false instead of -EINVAL
drm/amdgpu/powerplay/smu7: fix unintialized data usage
drm/amdgpu: fix crash in acp_hw_fini
i915 fixes, include Sandybridge rendering regression fix.
* tag 'drm-intel-fixes-2016-11-09' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Limit Valleyview and earlier to only using mappable scanout
drm/i915: Round tile chunks up for constructing partial VMAs
drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms
drm/i915/dp: BDW cdclk fix for DP audio
drm/i915/vlv: Prevent enabling hpd polling in late suspend
drm/i915: Respect alternate_ddc_pin for all DDI ports
this became a largish pull-request, as we've got a bunch of pending
ASoC fixes at this time. One noticeable change is the removal of
error directive in uapi/sound/asoc.h. We found that the API has
been already used on Chromebooks, so we need to support it even now.
A slight big LOC is found in Qualcomm lpass driver, but the rest are
all small and easy fixes for ASoC drivers (sti, sun4i, Realtek codecs,
Intel, tas571x, etc) in addition to the patches to harden the ALSA
core proc file accesses.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJYI3I4AAoJEGwxgFQ9KSmkgEMP/iGW/7T2AqD39pKtmfXH60gt
hU9ccBt+gSrKqyMZHjrqp69o2//9JSsx6ezJXAWm5OeDwPJCxwSBIy2fGzxBZDwW
0nhYbeoZFQbQucCTDLRO33n0xe7YIMtjp9H55PBBoaWKDdDoRiOdsKIRSFWToV2Q
IOPY3pvYUP8RzYA2GC9Ud5xDb0U/J3je7PGhwM880sBlOxykTJJwrq95tG8EGIF8
CAj/B/IJw0SuA79RDjBSziT9xAfHjiky4wYTw7HcjgBStLv3R2txM3775Cvhsnwr
ISdXmh2ImibCh5ADIivXoNTkptq0mTurWi/6W1fENqZVxaAh7/MsWjlVKfAmgUKT
kTRgLJLZIQ/P0ejKnbRI2+K4z0iLcF4w4GURi3iwEOKuvX1jDN/F9pte/ZCB3BIw
IKxRZ2ClWAdlpPt/reNNH3fKICguLlktoZWUkZm1rVZ2ACieQVMmodYjIMP0egXr
EHus0Pp+B9U3prvncGKSIG9+/8XFBdYh++811cVkT78W2nBmy9VjvbA2iBTo1Yzj
mWzpU/Zp+wC44TyMHP+AtZj+XsAM0l0gQRMUKoMe1RTdOmBleGsiGaN/V9kTuX0S
bHbPV1CKnfw/4mQDc9BGuVC6xz/kS3xgqqUscdIf0flN7/kYJbzOJlz2fM/svP7z
w0yH9d7pvEGKJTqLlyOm
=jmAA
-----END PGP SIGNATURE-----
Merge tag 'sound-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"This became a largish pull-request, as we've got a bunch of pending
ASoC fixes at this time. One noticeable change is the removal of error
directive in uapi/sound/asoc.h. We found that the API has been already
used on Chromebooks, so we need to support it even now.
A slight big LOC is found in Qualcomm lpass driver, but the rest are
all small and easy fixes for ASoC drivers (sti, sun4i, Realtek codecs,
Intel, tas571x, etc) in addition to the patches to harden the ALSA
core proc file accesses"
* tag 'sound-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (26 commits)
ALSA: info: Return error for invalid read/write
ALSA: info: Limit the proc text input size
ASoC: samsung: spdif: Fix DMA filter initialization
ASoC: sun4i-codec: Enable bus clock after getting GPIO
ASoC: lpass-cpu: add module licence and description
ASoC: lpass-platform: Fix broken pcm data usage
ASoC: sun4i-codec: return error code instead of NULL when create_card fails
ASoC: hdmi-codec: Fix hdmi_of_xlate_dai_name when #sound-dai-cells = <0>
ASoC: samsung: get access to DMA engine early to defer probe properly
ASoC: da7219: Connect output enable register to DAIOUT
ASoC: Intel: Skylake: Fix to turn off hdmi power on probe failure
ASoC: sti-sas: enable fast io for regmap
ASoC: sti: fix channel status update after playback start
ASoC: PXA: Brownstone needs I2C
ASoC: Intel: Skylake: Always acquire runtime pm ref on unload
ASoC: Intel: Atom: add terminate entry for dmi_system_id tables
ASoC: rt298: fix jack type detect error
ASoC: rt5663: fix a debug statement
ASoC: cs4270: fix DAPM stream name mismatch
ASoC: Intel: haswell depends on sst-firmware
...
The refactor seemed to trigger dan.carpenter@oracle.com's
static tester to find a possible double-free in the code.
While designing the fix we saw a condition under which the
buffer being freed could also be overflowed.
We also realized how to rebuild the related debugfs file's
"contents" (a string) without deleting and re-creating the file.
This fix should eliminate the possible double-free, the
potential overflow and improve code readability.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJYI04nAAoJEM9EDqnrzg2+rT4P/1sN1ZUDwKgyJ3Qk3n5AAvlR
PtbqeRhzUD7QdTR5yb/k/37rqYB7BBB5xd5VDlYKuD8luppjoAS2J4SRkngPFQiV
NZMP1Sq5nWeEyeG8it+MzH364zBUGK+D94VqlhUDLHKa27WMWTB2vrcLq/DI06np
35r4dWnV3+2+lgg0zvJGP7QoQLlPByB5q7pwTA9TBaPnDHVh/Myq4jS70wfEYDqY
NMxkq02vQHS7a2mysZbrE2fXC2OBRTCGP+9lsdvJx9XfYQkIHfe4qMAxu0XlqDSM
6POHEr5cPizENGSp7myV9G97FuF0UHZXnLEKe04DLbuGao2omMiNHvrnS/zPgKRQ
zpCMsf4FVChjCipQzne1eLQbQskWVDy58ziURzefO+bV8aFe61KBOvAiNEZ+7i21
CeEBeU2A5brd1y6ELcFCf2SDjmyd/ScyYqwIIrsY0eK1D3GveeHX1tkMGH8y7hWD
CoY/cKUSHwZ6ZwFpzeCs96wzZ19o7BLKogyIyYQWc1s09uijIHInxkRxUqtfVErj
2SpOXOqLkpjpU0Kga8beU6OtXLRv/ob518RPTPF5NAzjl08xn20pZckKL092uhVj
k/VlJUE72Om2XJmBbta2Sz7iN8QfujJO0Ql/Nl51lX++pVbQIjFDaRhIYt6Yb0af
y1XRJXqDJ3sh9J/od3fN
=ELyS
-----END PGP SIGNATURE-----
Merge tag 'for-linus-4.9-rc4-ofs-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux
Pull orangefs fix from Mike Marshall:
"We recently refactored the Orangefs debugfs code. The refactor seemed
to trigger dan.carpenter@oracle.com's static tester to find a possible
double-free in the code.
While designing the fix we saw a condition under which the buffer
being freed could also be overflowed.
We also realized how to rebuild the related debugfs file's "contents"
(a string) without deleting and re-creating the file.
This fix should eliminate the possible double-free, the potential
overflow and improve code readability"
* tag 'for-linus-4.9-rc4-ofs-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux:
orangefs: clean up debugfs
Pull s390 fixes from Martin Schwidefsky:
"Two bug fixes
- a memory alignment fix in the s390 only hypfs code
- a fix for the generic percpu code that caused ftrace to break on
s390. This is not relevant for x86 but for all architectures that
use the generic percpu code"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
percpu: use notrace variant of preempt_disable/preempt_enable
s390/hypfs: Use get_free_page() instead of kmalloc to ensure page alignment
This patch will fix regression caused by commit 1e793f6fc0 ("scsi:
megaraid_sas: Fix data integrity failure for JBOD (passthrough)
devices").
The problem was that the MEGASAS_IS_LOGICAL macro did not have braces
and as a result the driver ended up exposing a lot of non-existing SCSI
devices (all SCSI commands to channels 1,2,3 were returned as
SUCCESS-DID_OK by driver).
[mkp: clarified patch description]
Fixes: 1e793f6fc0
Reported-by: Jens Axboe <axboe@kernel.dk>
CC: stable@vger.kernel.org
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Tested-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Tested-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If the DC clock is disabled before the attached IDMACs are properly
stopped the IDMACs may hang the IPU or even the whole system.
Make sure the IDMACs are in safe state by disabling the planes before
removal of the DC clock.
Also set the atomic parameter to false to stop calling the atomic_begin
hook, which does nothing useful as we immediately afterwards turn off
vblank interrupts and possibly send the pending vblank event.
Fixes: 33f1423530 (drm/imx: atomic phase 1: Use transitional atomic
CRTC and plane helpers)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
If a command is aborted in the kernel but not in the adapter, it might be
considered complete and its DMA memory released, but it is still alive in
the adapter, which will trigger an invalid DMA access upon its completion
(in the DMA operations to deliver the command response to the driver).
On powerpc platforms with IOMMU/EEH capabilities, the problem is observed
during PCI device removal with ongoing IO requests -- which might trigger
an EEH event very often, pointing to a 'TCE Request Page Access Error'.
In that path, which is qla2x00_remove_one(), the commands are aborted in
qla2x00_abort_all_cmds(), which does not perform an abort in the adapter
as is done in qla2xxx_eh_abort() for example.
So, this patch changes qla2x00_abort_all_cmds() to abort commands in the
adapter too, with a call to qla2xxx_eh_abort(), which already implements
all the logic to submit abort requests and handle responses.
Reported-by: Naresh Bannoth <nbannoth@in.ibm.com>
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Acked-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When the driver is unloading, in qla2x00_remove_one(), there is a single
call/point in time to abort ongoing commands, qla2x00_abort_all_cmds(),
which is still several steps away from the call to scsi_remove_host().
If more commands continue to arrive and be processed during that
interval, when the driver is tearing down and releasing its structures,
it might potentially hit an oops due to invalid memory access:
Unable to handle kernel paging request for data at address 0x00000138
<...>
NIP [d000000004700a40] qla2xxx_queuecommand+0x80/0x3f0 [qla2xxx]
LR [d000000004700a10] qla2xxx_queuecommand+0x50/0x3f0 [qla2xxx]
So, fail commands in qla2xxx_queuecommand() if the UNLOADING bit is set.
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Acked-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Before calling task_release_itt() task data is memset to zero because of
which DDP context information is lost resulting in incorrect DDP
resource cleanup, to fix this call task_release_itt() before memset.
Signed-off-by: Varun Prakash <varun@chelsio.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The new mpu3050 driver fails to build if I2C is disabled:
drivers/iio/built-in.o: In function `mpu3050_i2c_driver_exit':
mpu3050-i2c.c:(.exit.text+0x17f): undefined reference to `i2c_del_driver'
drivers/iio/built-in.o: In function `mpu3050_i2c_driver_init':
mpu3050-i2c.c:(.init.text+0x215): undefined reference to `i2c_register_driver'
This adds a Kconfig dependency to ensure we only build it when I2C
is available.
Fixes: 3904b28efb ("iio: gyro: Add driver for the MPU-3050 gyroscope")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The newly added mpu3050 driver has two initializations for the
module owner, which causes a warning for 'make W=1':
include/linux/export.h:37:21: error: initialized field overwritten [-Werror=override-init]
drivers/iio/gyro/mpu3050-core.c:749:19: note: in expansion of macro 'THIS_MODULE'
This removes one of the two.
Fixes: 3904b28efb ("iio: gyro: Add driver for the MPU-3050 gyroscope")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Removing a call to the taos_chip_off() makes it unused when CONFIG_PM
is disabled:
drivers/staging/iio/light/tsl2583.c:438:12: error: ‘taos_chip_off’ defined but not used [-Werror=unused-function]
This removes all the #ifdef in this file, and marks the PM functions as
__maybe_unused instead, which is more reliable and gives us better
compile time coverage.
Fixes: 0561155f6f ("staging: iio: tsl2583: don't shutdown chip when updating the lux table")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
If we're using a shadow copy of a PCI device ROM, the shadow copy is in RAM
and the device never sees accesses to it and doesn't respond to it. We
don't have to route the shadow range to the PCI device, and the device
doesn't have to claim the range.
Previously we treated the shadow copy as though it were the ROM BAR, and we
failed to claim it because the region wasn't routed to the device:
pci 0000:01:00.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
pci_bus 0000:01: Allocating resources
pci 0000:01:00.0: can't claim BAR 6 [mem 0x000c0000-0x000dffff]: no compatible bridge window
The failure path of pcibios_allocate_dev_rom_resource() cleared out the
resource start address, which also caused the following ioremap() warning:
WARNING: CPU: 0 PID: 116 at /build/linux-akdJXO/linux-4.8.0/arch/x86/mm/ioremap.c:121 __ioremap_caller+0x1ec/0x370
ioremap on RAM at 0x0000000000000000 - 0x000000000001ffff
Handle an option ROM shadow copy as RAM, without trying to insert it into
the iomem resource tree.
This fixes a regression caused by 0c0e0736ac ("PCI: Set ROM shadow
location in arch code, not in PCI core"), which appeared in v4.6. The
regression causes video device initialization to fail. This was reported
on AMD Turks, but it likely affects others as well.
Fixes: 0c0e0736ac ("PCI: Set ROM shadow location in arch code, not in PCI core")
Reported-and-tested-by: Vecu Bosseur <vecu.bosseur@gmail.com>
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1627496
Link: https://bugzilla.kernel.org/show_bug.cgi?id=175391
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1352272
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v4.6+
ARC linux uses 2 distribution modes for common interrupts: round robin
mode (IDU_M_DISTRI_RR) and a simple destination mode (IDU_M_DISTRI_DEST).
The first one is used when more than 1 cores may handle a common interrupt
and the second one is used when only 1 core may handle a common interrupt.
However idu_irq_set_affinity() always sets IDU_M_DISTRI_RR for all affinity
values. But there is no sense in setting of such mode if only 1 core must
handle a common interrupt.
Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The regulator changes assigned data to an uninitialized pointer:
drivers/staging/iio/frequency/ad9832.c: In function 'ad9832_probe':
drivers/staging/iio/frequency/ad9832.c:214:11: error: 'st' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This moves the allocation of the 'st' structure before its first
use, as it should have been.
Fixes: 43a07e48af ("staging: iio: ad9832: clean-up regulator 'reg'")
Fixes: a98461d79b ("staging: iio: ad9832: add DVDD regulator")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This came up when reviewing code to address missing IRQ affinity
setting in AXS103 platform and/or implementing hierarchical IRQ domains
- smp_ipi_irq_setup() callers pass hwirq but in turn calls
request_percpu_irq() which expects a linux virq. So invoke
irq_find_mapping() to do the conversion
(also explicitify this in code by renaming the args appropriately)
- idu_of_init()/idu_cascade_isr() were similarly using linux virq where
hwirq is expected, so do the conversion using irqd_to_hwirq() helper
Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
[vgupta: made changelog a bit concise a bit]
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Two places need fixing:
* Four patches from Robin Murphy fix several issues with the
recently merged generic DT-bindings support for arm-smmu
drivers
* A fix for a dead-lock issue in the VT-d driver, which shows up
on iommu hotplug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJYIe6KAAoJECvwRC2XARrjJtgP/0O2b5JBuMGPBdCcFdClGji4
ozxDwfOMUohRfo6p33V7G+bQiNmF5NUhqWPuEXQ64BejFe3GY2+jWS5C0bj2w+Cm
5u8C5K6WJ93q2Bdg8BLhe17H00kjM+vFucMZBvcZlDWZlrDzbSR1tVG84zhlAUR+
ewuBzf8qEAAK1xLuVU6ywLBHK6L/tX4mACgvwktQR8qRrz5bGGIecH9ZAHCzYODb
6PJ3/hchn1e0Ckntg1i+Ggx6A9+aof+U+t0iJeFBN1HpAuN+FhaGNmf8b7v7AQAn
0el/ByVfp51kzGo1/mi/bW1odgNMSqhOn+oA2Na2fHrn9A0/2c8LtYmsGmRacNqi
HPLm0iKAZUb7HAKlSJnm4eVjQsFxAcIXe+rEE3RgxJbbKpWPVy2zaEXw6c++ALhi
R2xI1L9cLXhV/bOfba05uuSTp604yAFcli4tbo81AziZZ+hpXCPTAYrjtw11LbiC
JaFBPksctESm2bOSDXkbSgwIQN+jRnMH7xR/t9L2vCIt0m3IGCFqz5ia4rcmCq1+
quRp6GCd9G2oW8DemI9bggYCZeGzbWbOAQCQfKoRGl50WJ279vUpVhpUUo8OBcPg
xE+GqGNAEcWchNDODH5nVrfuCK3TV0NWW+N3tOh0IC2QT85JMa+9nc287vq4ZwqQ
bhionSy/gs2ht9NPa9XO
=N8iu
-----END PGP SIGNATURE-----
Merge tag 'iommu-fixes-v4.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull IOMMU fixes from Joerg Roedel:
- Four patches from Robin Murphy fix several issues with the recently
merged generic DT-bindings support for arm-smmu drivers
- A fix for a dead-lock issue in the VT-d driver, which shows up on
iommu hotplug
* tag 'iommu-fixes-v4.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/vt-d: Fix dead-locks in disable_dmar_iommu() path
iommu/arm-smmu: Fix out-of-bounds dereference
iommu/arm-smmu: Check that iommu_fwspecs are ours
iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
iommu/arm-smmu: Work around ARM DMA configuration
For CONFIG_SERIAL_EARLYCON we need 800MHz for NPS SoC
The early console driver uses BASE_BAUD and not using dtb.
The default of 50MHz is NOT good for NPS SoC.
Signed-off-by: Noam Camus <noamca@mellanox.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Today we register to plat_smp_ops.clear() method which actually
is acking the IPI.
However this is already taking care by our irqchip driver specifically
by the irq_chip.irq_eoi() method.
This is perfect timing where it should be done and no special handling
is needed at plat_smp_ops.clear().
Signed-off-by: Noam Camus <noamca@mellanox.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
This has caused a bunch of build failures at a few sites, with GNU
2015.12 and older as the assembler seems to need -mlock to be able to
grok llock/scond instructions for ARC700 builds.
different places since the
older tools still seem to release
of tools which most people are using seem to trip with the -mlock flag
not being passed.
This reverts commit c300547588.
Returning -EINVAL from a bool-returning function
phm_check_smc_update_required_for_display_configuration has an unexpected
effect of returning true, which is probably not what was intended.
Replace -EINVAL by false.
The only place this function is called from is
psm_adjust_power_state_dynamic in
drivers/gpu/drm/amd/powerplay/eventmgr/psm.c:106:
if (!equal || phm_check_smc_update_required_for_display_configuration(hwmgr)) {
phm_apply_state_adjust_rules(hwmgr, requested, pcurrent);
phm_set_power_state(hwmgr, &pcurrent->hardware, &requested->hardware);
hwmgr->current_ps = requested;
}
It seems to expect a boolean value here.
This issue has been found using the following Coccinelle semantic patch
written by Peter Senna Tschudin:
<smpl>
@@
identifier f;
constant C;
typedef bool;
@@
bool f (...){
<+...
* return -C;
...+>
}
</smpl>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Andrew Shadura <andrew.shadura@collabora.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
A recent bugfix replaced an out-of-bounds access with direct
use of unintialized data:
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c: In function 'smu7_patch_limits_vddc':
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2033:6: error: 'vddc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2146:11: note: 'vddc' was declared here
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2033:6: error: 'vddci' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2146:17: note: 'vddci' was declared here
uint32_t vddc, vddci;
This initializes the data as before using the correct type.
Fixes: 77f7f71f5b ("drm/amdgpu/powerplay/smu7: fix static checker warning")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It turns out that the disable_dmar_iommu() code-path tried
to get the device_domain_lock recursivly, which will
dead-lock when this code runs on dmar removal. Fix both
code-paths that could lead to the dead-lock.
Fixes: 55d940430a ('iommu/vt-d: Get rid of domain->iommu_lock')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
When we iterate a master's config entries, what we generally care
about is the entry's stream map index, rather than the entry index
itself, so it's nice to have the iterator automatically assign the
former from the latter. Unfortunately, booting with KASAN reveals
the oversight that using a simple comma operator results in the
entry index being dereferenced before being checked for validity,
so we always access one element past the end of the fwspec array.
Flip things around so that the check always happens before the index
may be dereferenced.
Fixes: adfec2e709 ("iommu/arm-smmu: Convert to iommu_fwspec")
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
We seem to have forgotten to check that iommu_fwspecs actually belong to
us before we go ahead and dereference their private data. Oops.
Fixes: 021bb8420d ("iommu/arm-smmu: Wire up generic configuration support")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
We now delay installing our per-bus iommu_ops until we know an SMMU has
successfully probed, as they don't serve much purpose beforehand, and
doing so also avoids fights between multiple IOMMU drivers in a single
kernel. However, the upshot of passing the return value of bus_set_iommu()
back from our probe function is that if there happens to be more than
one SMMUv3 device in a system, the second and subsequent probes will
wind up returning -EBUSY to the driver core and getting torn down again.
Avoid re-setting ops if ours are already installed, so that any genuine
failures stand out.
Fixes: 08d4ca2a67 ("iommu/arm-smmu: Support non-PCI devices with SMMUv3")
CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
CC: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The 32-bit ARM DMA configuration code predates the IOMMU core's default
domain functionality, and instead relies on allocating its own domains
and attaching any devices using the generic IOMMU binding to them.
Unfortunately, it does this relatively early on in the creation of the
device, before we've seen our add_device callback, which leads us to
attempt to operate on a half-configured master.
To avoid a crash, check for this situation on attach, but refuse to
play, as there's nothing we can do. This at least allows VFIO to keep
working for people who update their 32-bit DTs to the generic binding,
albeit with a few (innocuous) warnings from the DMA layer on boot.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Currently the ALSA proc handler allows read or write even if the proc
file were write-only or read-only. It's mostly harmless, does thing
but allocating memory and ignores the input/output. But it doesn't
tell user about the invalid use, and it's confusing and inconsistent
in comparison with other proc files.
This patch adds some sanity checks and let the proc handler returning
an -EIO error when the invalid read/write is performed.
Cc: <stable@vger.kernel.org> # v4.2+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ALSA proc handler allows currently the write in the unlimited size
until kmalloc() fails. But basically the write is supposed to be only
for small inputs, mostly for one line inputs, and we don't have to
handle too large sizes at all. Since the kmalloc error results in the
kernel warning, it's better to limit the size beforehand.
This patch adds the limit of 16kB, which must be large enough for the
currently existing code.
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit 345ddcc882 ("ftrace: Have set_ftrace_pid use the bitmap like
events do") added a couple of this_cpu_read calls to the ftrace code.
On x86 this is not a problem, since it has single instructions to read
percpu data. Other architectures which use the generic variant now
have additional preempt_disable and preempt_enable calls in the core
ftrace code. This may lead to recursive calls and in result to a dead
machine, e.g. if preemption and debugging options are enabled.
To fix this use the notrace variant of preempt_disable and
preempt_enable within the generic percpu code.
Reported-and-bisected-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Tested-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Fixes: 345ddcc882 ("ftrace: Have set_ftrace_pid use the bitmap like events do")
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Fix the following warn:
fs/nfs/nfs4session.c: In function ‘nfs4_slot_seqid_in_use’:
fs/nfs/nfs4session.c:203:54: warning: ‘cur_seq’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (nfs4_slot_get_seqid(tbl, slotid, &cur_seq) == 0 &&
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
cur_seq == seq_nr && test_bit(slotid, tbl->used_slots))
~~~~~~~~~~~~~~~~~
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
We used to check for a valid layout type id before verifying pNFS flags
as an indicator for if we are using pNFS. This changed in 3132e49ece
with the introduction of multiple layout types, since now we are passing
an array of ids instead of just one. Since then, users have been seeing
a KERN_ERR printk show up whenever mounting NFS v4 without pNFS. This
patch restores the original behavior of exiting set_pnfs_layoutdriver()
early if we aren't using pNFS.
Fixes 3132e49ece ("pnfs: track multiple layout types in fsinfo
structure")
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
cl_rpcclient starts as ERR_PTR(-EINVAL), and connections like that
are floating freely through the system. Most places check whether
pointer is valid before dereferencing it, but newly added code
in nfs_match_client does not.
Which causes crashes when more than one NFS mount point is present.
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
We need to hold the rcu_read_lock() when calling rcu_dereference(),
otherwise we can't guarantee that the object being dereferenced still
exists.
Fixes: 39e5d2df ("SUNRPC search xprt switch for sockaddr")
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
The current code doesn't even compile as somehow the inline assembly
can't see the register names defined as ARC_RTC_*
I'm pretty sure It worked when I first got it merged, but the tools were
definitely different then.
So better to write this in "C" anyways.
CC: stable@vger.kernel.org #4.2+
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The original syscall only used to return errno to indicate if cmpxchg
succeeded. It was not returning the "previous" value which typical cmpxchg
callers are interested in to build their slowpaths or retry loops.
Given user preemption in syscall return path etc, it is not wise to
check this in userspace afterwards, but should be what kernel actually
observed in the syscall.
So change the syscall interface to always return the previous value and
additionally set Z flag to indicate whether operation succeeded or not
(just like ARM implementation when they used to have this syscall)
The flag approach avoids having to put_user errno which is nice given
the use case for this syscall cares mostly about the "previous" value.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
