Ard Biesheuvel [Mon, 14 Sep 2020 08:24:37 +0000 (11:24 +0300)]
ARM: module: add support for place relative relocations
commit
22f2d23098f7d34fc5142531cffb241d14611684 upstream.
When using the new adr_l/ldr_l/str_l macros to refer to external symbols
from modules, the linker may emit place relative ELF relocations that
need to be fixed up by the module loader. So add support for these.
Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Phil Elwell [Thu, 28 Oct 2021 11:16:00 +0000 (12:16 +0100)]
Revert "ARM: proc-v7: Retry uncached stmia if necessary"
This reverts commit
3e1698ed5013c1054e3dbf8a9fcd3a8549a95ece.
Phil Elwell [Thu, 9 Sep 2021 09:37:15 +0000 (10:37 +0100)]
ARM: dts: Add Pi Zero 2 support
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Maxime Ripard [Mon, 14 Jun 2021 13:28:30 +0000 (15:28 +0200)]
drm/vc4: hvs: Force modeset on gamma lut change
The HVS Gamma block can only be updated when idle, so we need to disable
the HVS channel when the gamma property is set in an atomic commit.
Since the pixelvalve cannot have its assigned channel halted without
stalling unless it's disabled as well, in our case that means forcing a
full disable / enable cycle on the pipeline.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Wed, 28 Apr 2021 10:32:10 +0000 (12:32 +0200)]
drm/vc4: Add debugfs node that dumps the vc5 gamma PWL entries
This helps with debugging the conversion from a 256 point gamma LUT to
16 point PWL entries as used by the BCM2711.
Co-developed-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dave Stevenson [Tue, 27 Apr 2021 12:24:21 +0000 (14:24 +0200)]
drm/vc4: Add support for gamma on BCM2711
BCM2711 changes from a 256 entry lookup table to a 16 point
piecewise linear function as the pipeline bitdepth has increased
to make a LUT unwieldy.
Implement a simple conversion from a 256 entry LUT that userspace
is likely to expect to 16 evenly spread points in the PWL. This
could be improved with curve fitting at a later date.
Co-developed-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Dom Cobley [Tue, 19 Oct 2021 13:14:55 +0000 (14:14 +0100)]
clk-bcm2835: Remove VEC clock support
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Dom Cobley [Tue, 19 Oct 2021 13:15:45 +0000 (14:15 +0100)]
dt: Move VEC clock to clk-raspberrypi
clk-2835 is deprecated and gets an innacurate clock for VEC (107MHz).
Switch to clk-raspberrypi which uses the right PLL to get an accurate 108MHz.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Dom Cobley [Tue, 19 Oct 2021 13:13:53 +0000 (14:13 +0100)]
clk-raspberrypi: Support VEC clock
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Gergo Koteles [Sun, 24 Oct 2021 21:18:09 +0000 (23:18 +0200)]
staging/bcm2835-camera: Add support for MPEG_VIDEO_FORCE_KEY_FRAME
Signed-off-by: Gergo Koteles <soyer@irl.hu>
soyer [Sat, 23 Oct 2021 10:23:50 +0000 (12:23 +0200)]
staging/bcm2835-camera: Add support for H264_MIN_QP, H264_MAX_QP
Signed-off-by: Gergo Koteles <soyer@irl.hu>
Dom Cobley [Mon, 25 Oct 2021 13:46:53 +0000 (14:46 +0100)]
Merge remote-tracking branch 'stable/linux-5.10.y' into rpi-5.10.y
Phil Elwell [Mon, 25 Oct 2021 10:48:18 +0000 (11:48 +0100)]
ARM: dts: vc4-kms-v3d: Always disable firmware HDMI
Both the firmware audio driver and the vc4-kms-v3d driver are capable
of providing HDMI audio, but only one should be active at any time.
The vc4-kms-v3d overlays disable the firmware audio driver, but they
also have a noaudio parameter that as well as disabling the ARM-side
HDMI audio also re-enables the firmware HDMI audio. This is not
guaranteed to work and has been seen to break the display completely.
Modify the noaudio parameters so that the firmware HDMI audio support
remains disabled.
See: https://github.com/raspberrypi/linux/issues/4651
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
John Cox [Fri, 22 Oct 2021 12:11:38 +0000 (13:11 +0100)]
media: bcm2835-codec: Limit video callbacks
Limit the number of allowed video callbacks. This helps with limiting
the size of the coded input FIFO which in turn helps to control latency.
Choose -5 as the magic number as it translates to DPB+5 buffers which
has been proven to be a good number in the past.
Ideally coded buffers would not be returned to the user until they
had been decoded into the DPB or been discarded as bad, but that grade
of control is unavailable to us.
Signed-off-by: John Cox <jc@kynesim.co.uk>
Sakari Ailus [Tue, 5 Jul 2016 09:41:15 +0000 (11:41 +0200)]
media: v4l: subdev: Improve link format validation debug messages
Commit
db8e94e7cf27d8bc101ef5b8ee5c1af77cd5b1c9 upstream
The existing link format validation failure debug message in media-entity.c
helped to pinpoint the point of failure but provided no additional
information what's wrong. Tell the user exactly why the validation failed.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Dave Stevenson [Fri, 15 Oct 2021 16:57:27 +0000 (17:57 +0100)]
media/bcm2835-unicam: Add support for configuration via MC API
Adds Media Controller API support for more complex pipelines.
libcamera is about to switch to using this mechanism for configuring
sensors.
This can be enabled by either a module parameter, or device tree.
Various functions have been moved to group video-centric and
mc-centric functions together.
Based on a similar conversion done to ti-vpe.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Dave Stevenson [Wed, 23 Sep 2020 14:16:18 +0000 (15:16 +0100)]
media/bcm2835-unicam: Parse pad numbers correctly
The driver was making big assumptions about the source device
using pad 0 and 1, which doesn't follow for more complex
devices where Unicam's source device may be a sink device for
something else.
Read the pad numbers through media controller, and reference
them appropriately.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
David Plowman [Thu, 21 Oct 2021 13:49:15 +0000 (14:49 +0100)]
vc04_services: isp: Report input node as wanting full range RAW color space
RAW color spaces are more usually reported as having full range
quantization.
Tested using libcamera.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
David Plowman [Thu, 21 Oct 2021 13:47:20 +0000 (14:47 +0100)]
media: i2c: ov9281: Sensor should report RAW color space
Tested on Raspberry Pi running libcamera.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
David Plowman [Thu, 21 Oct 2021 13:47:00 +0000 (14:47 +0100)]
media: i2c: ov5647: Sensor should report RAW color space
Tested on Raspberry Pi running libcamera.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
David Plowman [Thu, 21 Oct 2021 13:45:07 +0000 (14:45 +0100)]
media: i2c: imx519: Sensor should report RAW color space
Tested on Raspberry Pi running libcamera.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
David Plowman [Thu, 21 Oct 2021 13:44:43 +0000 (14:44 +0100)]
media: i2c: imx477: Sensor should report RAW color space
Tested on Raspberry Pi running libcamera.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
David Plowman [Thu, 21 Oct 2021 13:44:01 +0000 (14:44 +0100)]
media: i2c: imx290: Sensor should report RAW color space
Tested on Raspberry Pi running libcamera.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
David Plowman [Thu, 21 Oct 2021 13:41:55 +0000 (14:41 +0100)]
media: i2c: imx219: Sensor should report RAW color space
Tested on Raspberry Pi running libcamera.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Greg Kroah-Hartman [Wed, 20 Oct 2021 09:45:06 +0000 (11:45 +0200)]
Linux 5.10.75
Link: https://lore.kernel.org/r/20211018132334.702559133@linuxfoundation.org
Tested-by: Fox Chen <foxhlchen@gmail.com>
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Tested-by: Salvatore Bonaccorso <carnil@debian.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Hulk Robot <hulkrobot@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maarten Zanders [Mon, 11 Oct 2021 14:27:20 +0000 (16:27 +0200)]
net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's
commit
4a3e0aeddf091f00974b02627c157843ce382a24 upstream.
mv88e6xxx_port_ppu_updates() interpretes data in the PORT_STS
register incorrectly for internal ports (ie no PPU). In these
cases, the PHY_DETECT bit indicates link status. This results
in forcing the MAC state whenever the PHY link goes down which
is not intended. As a side effect, LED's configured to show
link status stay lit even though the physical link is down.
Add a check in mac_link_down and mac_link_up to see if it
concerns an external port and only then, look at PPU status.
Fixes:
5d5b231da7ac (net: dsa: mv88e6xxx: use PHY_DETECT in mac_link_up/mac_link_down)
Reported-by: Maarten Zanders <m.zanders@televic.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Maarten Zanders <maarten.zanders@mind.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shannon Nelson [Fri, 8 Oct 2021 19:38:01 +0000 (12:38 -0700)]
ionic: don't remove netdev->dev_addr when syncing uc list
commit
5c976a56570f29aaf4a2f9a1bf99789c252183c9 upstream.
Bridging, and possibly other upper stack gizmos, adds the
lower device's netdev->dev_addr to its own uc list, and
then requests it be deleted when the upper bridge device is
removed. This delete request also happens with the bridging
vlan_filtering is enabled and then disabled.
Bonding has a similar behavior with the uc list, but since it
also uses set_mac to manage netdev->dev_addr, it doesn't have
the same the failure case.
Because we store our netdev->dev_addr in our uc list, we need
to ignore the delete request from dev_uc_sync so as to not
lose the address and all hope of communicating. Note that
ndo_set_mac_address is expressly changing netdev->dev_addr,
so no limitation is set there.
Fixes:
2a654540be10 ("ionic: Add Rx filter and rx_mode ndo support")
Signed-off-by: Shannon Nelson <snelson@pensando.io>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vladimir Oltean [Tue, 12 Oct 2021 11:40:37 +0000 (14:40 +0300)]
net: mscc: ocelot: warn when a PTP IRQ is raised for an unknown skb
commit
9fde506e0c53b8309f69b18b4b8144c544b4b3b1 upstream.
When skb_match is NULL, it means we received a PTP IRQ for a timestamp
ID that the kernel has no idea about, since there is no skb in the
timestamping queue with that timestamp ID.
This is a grave error and not something to just "continue" over.
So print a big warning in case this happens.
Also, move the check above ocelot_get_hwtimestamp(), there is no point
in reading the full 64-bit current PTP time if we're not going to do
anything with it anyway for this skb.
Fixes:
4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Baowen Zheng [Tue, 12 Oct 2021 12:48:50 +0000 (14:48 +0200)]
nfp: flow_offload: move flow_indr_dev_register from app init to app start
commit
60d950f443a52d950126ad664fbd4a1eb8353dc9 upstream.
In commit
74fc4f828769 ("net: Fix offloading indirect devices dependency
on qdisc order creation"), it adds a process to trigger the callback to
setup the bo callback when the driver regists a callback.
In our current implement, we are not ready to run the callback when nfp
call the function flow_indr_dev_register, then there will be error
message as:
kernel: Oops: 0000 [#1] SMP PTI
kernel: CPU: 0 PID: 14119 Comm: kworker/0:0 Tainted: G
kernel: Workqueue: events work_for_cpu_fn
kernel: RIP: 0010:nfp_flower_indr_setup_tc_cb+0x258/0x410
kernel: RSP: 0018:
ffffbc1e02c57bf8 EFLAGS:
00010286
kernel: RAX:
0000000000000000 RBX:
ffff9c761fabc000 RCX:
0000000000000001
kernel: RDX:
0000000000000001 RSI:
fffffffffffffff0 RDI:
ffffffffc0be9ef1
kernel: RBP:
ffffbc1e02c57c58 R08:
ffffffffc08f33aa R09:
ffff9c6db7478800
kernel: R10:
0000009c003f6e00 R11:
ffffbc1e02800000 R12:
ffffbc1e000d9000
kernel: R13:
ffffbc1e000db428 R14:
ffff9c6db7478800 R15:
ffff9c761e884e80
kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
kernel: CR2:
fffffffffffffff0 CR3:
00000009e260a004 CR4:
00000000007706f0
kernel: DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
kernel: DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
kernel: PKRU:
55555554
kernel: Call Trace:
kernel: ? flow_indr_dev_register+0xab/0x210
kernel: ? __cond_resched+0x15/0x30
kernel: ? kmem_cache_alloc_trace+0x44/0x4b0
kernel: ? nfp_flower_setup_tc+0x1d0/0x1d0 [nfp]
kernel: flow_indr_dev_register+0x158/0x210
kernel: ? tcf_block_unbind+0xe0/0xe0
kernel: nfp_flower_init+0x40b/0x650 [nfp]
kernel: nfp_net_pci_probe+0x25f/0x960 [nfp]
kernel: ? nfp_rtsym_read_le+0x76/0x130 [nfp]
kernel: nfp_pci_probe+0x6a9/0x820 [nfp]
kernel: local_pci_probe+0x45/0x80
So we need to call flow_indr_dev_register in app start process instead of
init stage.
Fixes:
74fc4f828769 ("net: Fix offloading indirect devices dependency on qdisc order creation")
Signed-off-by: Baowen Zheng <baowen.zheng@corigine.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Louis Peens <louis.peens@corigine.com>
Link: https://lore.kernel.org/r/20211012124850.13025-1-louis.peens@corigine.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vegard Nossum [Mon, 11 Oct 2021 15:22:49 +0000 (17:22 +0200)]
r8152: select CRC32 and CRYPTO/CRYPTO_HASH/CRYPTO_SHA256
commit
9973a43012b6ad1720dbc4d5faf5302c28635b8c upstream.
Fix the following build/link errors by adding a dependency on
CRYPTO, CRYPTO_HASH, CRYPTO_SHA256 and CRC32:
ld: drivers/net/usb/r8152.o: in function `rtl8152_fw_verify_checksum':
r8152.c:(.text+0x2b2a): undefined reference to `crypto_alloc_shash'
ld: r8152.c:(.text+0x2bed): undefined reference to `crypto_shash_digest'
ld: r8152.c:(.text+0x2c50): undefined reference to `crypto_destroy_tfm'
ld: drivers/net/usb/r8152.o: in function `_rtl8152_set_rx_mode':
r8152.c:(.text+0xdcb0): undefined reference to `crc32_le'
Fixes:
9370f2d05a2a1 ("r8152: support request_firmware for RTL8153")
Fixes:
ac718b69301c7 ("net/usb: new driver for RTL8152")
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
chongjiapeng [Sat, 9 Oct 2021 08:09:26 +0000 (16:09 +0800)]
qed: Fix missing error code in qed_slowpath_start()
commit
a5a14ea7b4e55604acb0dc9d88fdb4cb6945bc77 upstream.
The error code is missing in this code scenario, add the error code
'-EINVAL' to the return value 'rc'.
Eliminate the follow smatch warning:
drivers/net/ethernet/qlogic/qed/qed_main.c:1298 qed_slowpath_start()
warn: missing error code 'rc'.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Fixes:
d51e4af5c209 ("qed: aRFS infrastructure support")
Signed-off-by: chongjiapeng <jiapeng.chong@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Thu, 7 Oct 2021 17:49:57 +0000 (19:49 +0200)]
mqprio: Correct stats in mqprio_dump_class_stats().
commit
14132690860e4d06aa3e1c4d7d8e9866ba7756dd upstream.
Introduction of lockless subqueues broke the class statistics.
Before the change stats were accumulated in `bstats' and `qstats'
on the stack which was then copied to struct gnet_dump.
After the change the `bstats' and `qstats' are initialized to 0
and never updated, yet still fed to gnet_dump. The code updates
the global qdisc->cpu_bstats and qdisc->cpu_qstats instead,
clobbering them. Most likely a copy-paste error from the code in
mqprio_dump().
__gnet_stats_copy_basic() and __gnet_stats_copy_queue() accumulate
the values for per-CPU case but for global stats they overwrite
the value, so only stats from the last loop iteration / tc end up
in sch->[bq]stats.
Use the on-stack [bq]stats variables again and add the stats manually
in the global case.
Fixes:
ce679e8df7ed2 ("net: sched: add support for TCQ_F_NOLOCK subqueues to sch_mqprio")
Cc: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
https://lore.kernel.org/all/
20211007175000.2334713-2-bigeasy@linutronix.de/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prashant Malani [Tue, 28 Sep 2021 10:19:30 +0000 (03:19 -0700)]
platform/x86: intel_scu_ipc: Fix busy loop expiry time
commit
41512e4dc0b84525495e784295092592adb87f1b upstream.
The macro IPC_TIMEOUT is already in jiffies (it is also used like that
elsewhere in the file when calling wait_for_completion_timeout()). Don’t
convert it using helper functions for the purposes of calculating the
busy loop expiry time.
Fixes:
e7b7ab3847c9 (“platform/x86: intel_scu_ipc: Sleeping is fine when polling”)
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20210928101932.2543937-2-pmalani@chromium.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jackie Liu [Mon, 23 Aug 2021 09:25:26 +0000 (17:25 +0800)]
acpi/arm64: fix next_platform_timer() section mismatch error
commit
596143e3aec35c93508d6b7a05ddc999ee209b61 upstream.
Fix modpost Section mismatch error in next_platform_timer().
[...]
WARNING: modpost: vmlinux.o(.text.unlikely+0x26e60): Section mismatch in reference from the function next_platform_timer() to the variable .init.data:acpi_gtdt_desc
The function next_platform_timer() references
the variable __initdata acpi_gtdt_desc.
This is often because next_platform_timer lacks a __initdata
annotation or the annotation of acpi_gtdt_desc is wrong.
WARNING: modpost: vmlinux.o(.text.unlikely+0x26e64): Section mismatch in reference from the function next_platform_timer() to the variable .init.data:acpi_gtdt_desc
The function next_platform_timer() references
the variable __initdata acpi_gtdt_desc.
This is often because next_platform_timer lacks a __initdata
annotation or the annotation of acpi_gtdt_desc is wrong.
ERROR: modpost: Section mismatches detected.
Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.
make[1]: *** [scripts/Makefile.modpost:59: vmlinux.symvers] Error 1
make[1]: *** Deleting file 'vmlinux.symvers'
make: *** [Makefile:1176: vmlinux] Error 2
[...]
Fixes:
a712c3ed9b8a ("acpi/arm64: Add memory-mapped timer support in GTDT driver")
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Acked-by: Hanjun Guo <guohanjun@huawei.com>
Link: https://lore.kernel.org/r/20210823092526.2407526-1-liu.yun@linux.dev
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 1 Oct 2021 12:34:09 +0000 (15:34 +0300)]
drm/msm/dsi: fix off by one in dsi_bus_clk_enable error handling
commit
c8f01ffc83923a91e8087aaa077de13354a7aa59 upstream.
This disables a lock which wasn't enabled and it does not disable
the first lock in the array.
Fixes:
6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211001123409.GG2283@kili
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 1 Oct 2021 12:33:08 +0000 (15:33 +0300)]
drm/msm/dsi: Fix an error code in msm_dsi_modeset_init()
commit
739b4e7756d3301dd673ca517afca46a5f635562 upstream.
Return an error code if msm_dsi_manager_validate_current_config().
Don't return success.
Fixes:
8b03ad30e314 ("drm/msm/dsi: Use one connector for dual DSI mode")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211001123308.GF2283@kili
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rob Clark [Thu, 30 Sep 2021 17:43:20 +0000 (10:43 -0700)]
drm/msm/a6xx: Track current ctx by seqno
commit
14eb0cb4e9a7323c8735cf6c681ed8423ce6ae06 upstream.
In theory a context can be destroyed and a new one allocated at the same
address, making the pointer comparision to detect when we don't need to
update the current pagetables invalid. Instead assign a sequence number
to each context on creation, and use this for the check.
Fixes:
84c31ee16f90 ("drm/msm/a6xx: Add support for per-instance pagetables")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Baryshkov [Sat, 25 Sep 2021 19:28:24 +0000 (22:28 +0300)]
drm/msm/mdp5: fix cursor-related warnings
commit
c491a0c7bbf3a64732cb8414021429d15ec08eec upstream.
Since
f35a2a99100f ("drm/encoder: make encoder control functions
optional") drm_mode_config_validate would print warnings if both cursor
plane and cursor functions are provided. Restore separate set of
drm_crtc_funcs to be used if separate cursor plane is provided.
[ 6.556046] ------------[ cut here ]------------
[ 6.556071] [CRTC:93:crtc-0] must not have both a cursor plane and a cursor_set func
[ 6.556091] WARNING: CPU: 1 PID: 76 at drivers/gpu/drm/drm_mode_config.c:648 drm_mode_config_validate+0x238/0x4d0
[ 6.567453] Modules linked in:
[ 6.577604] CPU: 1 PID: 76 Comm: kworker/u8:2 Not tainted 5.15.0-rc1-dirty #43
[ 6.580557] Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
[ 6.587763] Workqueue: events_unbound deferred_probe_work_func
[ 6.593926] pstate:
60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 6.599740] pc : drm_mode_config_validate+0x238/0x4d0
[ 6.606596] lr : drm_mode_config_validate+0x238/0x4d0
[ 6.611804] sp :
ffff8000121b3980
[ 6.616838] x29:
ffff8000121b3990 x28:
0000000000000000 x27:
0000000000000001
[ 6.620140] x26:
ffff8000114cde50 x25:
ffff8000114cdd40 x24:
ffff0000987282d8
[ 6.627258] x23:
0000000000000000 x22:
0000000000000000 x21:
0000000000000001
[ 6.634376] x20:
ffff000098728000 x19:
ffff000080a39000 x18:
ffffffffffffffff
[ 6.641494] x17:
3136564e3631564e x16:
0000000000000324 x15:
ffff800011c78709
[ 6.648613] x14:
0000000000000000 x13:
ffff800011a22850 x12:
00000000000009ab
[ 6.655730] x11:
0000000000000339 x10:
ffff800011a22850 x9 :
ffff800011a22850
[ 6.662848] x8 :
00000000ffffefff x7 :
ffff800011a7a850 x6 :
ffff800011a7a850
[ 6.669966] x5 :
000000000000bff4 x4 :
40000000fffff339 x3 :
0000000000000000
[ 6.677084] x2 :
0000000000000000 x1 :
0000000000000000 x0 :
ffff00008093b800
[ 6.684205] Call trace:
[ 6.691319] drm_mode_config_validate+0x238/0x4d0
[ 6.693577] drm_dev_register+0x17c/0x210
[ 6.698435] msm_drm_bind+0x4b4/0x694
[ 6.702429] try_to_bring_up_master+0x164/0x1d0
[ 6.706075] __component_add+0xa0/0x170
[ 6.710415] component_add+0x14/0x20
[ 6.714234] msm_hdmi_dev_probe+0x1c/0x2c
[ 6.718053] platform_probe+0x68/0xe0
[ 6.721959] really_probe.part.0+0x9c/0x30c
[ 6.725606] __driver_probe_device+0x98/0x144
[ 6.729600] driver_probe_device+0xc8/0x15c
[ 6.734114] __device_attach_driver+0xb4/0x120
[ 6.738106] bus_for_each_drv+0x78/0xd0
[ 6.742619] __device_attach+0xdc/0x184
[ 6.746351] device_initial_probe+0x14/0x20
[ 6.750172] bus_probe_device+0x9c/0xa4
[ 6.754337] deferred_probe_work_func+0x88/0xc0
[ 6.758158] process_one_work+0x1d0/0x370
[ 6.762671] worker_thread+0x2c8/0x470
[ 6.766839] kthread+0x15c/0x170
[ 6.770483] ret_from_fork+0x10/0x20
[ 6.773870] ---[ end trace
5884eb76cd26d274 ]---
[ 6.777500] ------------[ cut here ]------------
[ 6.782043] [CRTC:93:crtc-0] must not have both a cursor plane and a cursor_move func
[ 6.782063] WARNING: CPU: 1 PID: 76 at drivers/gpu/drm/drm_mode_config.c:654 drm_mode_config_validate+0x290/0x4d0
[ 6.794362] Modules linked in:
[ 6.804600] CPU: 1 PID: 76 Comm: kworker/u8:2 Tainted: G W 5.15.0-rc1-dirty #43
[ 6.807555] Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
[ 6.816148] Workqueue: events_unbound deferred_probe_work_func
[ 6.822311] pstate:
60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 6.828126] pc : drm_mode_config_validate+0x290/0x4d0
[ 6.834981] lr : drm_mode_config_validate+0x290/0x4d0
[ 6.840189] sp :
ffff8000121b3980
[ 6.845223] x29:
ffff8000121b3990 x28:
0000000000000000 x27:
0000000000000001
[ 6.848525] x26:
ffff8000114cde50 x25:
ffff8000114cdd40 x24:
ffff0000987282d8
[ 6.855643] x23:
0000000000000000 x22:
0000000000000000 x21:
0000000000000001
[ 6.862763] x20:
ffff000098728000 x19:
ffff000080a39000 x18:
ffffffffffffffff
[ 6.869879] x17:
3136564e3631564e x16:
0000000000000324 x15:
ffff800011c790c2
[ 6.876998] x14:
0000000000000000 x13:
ffff800011a22850 x12:
0000000000000a2f
[ 6.884116] x11:
0000000000000365 x10:
ffff800011a22850 x9 :
ffff800011a22850
[ 6.891234] x8 :
00000000ffffefff x7 :
ffff800011a7a850 x6 :
ffff800011a7a850
[ 6.898351] x5 :
000000000000bff4 x4 :
40000000fffff365 x3 :
0000000000000000
[ 6.905470] x2 :
0000000000000000 x1 :
0000000000000000 x0 :
ffff00008093b800
[ 6.912590] Call trace:
[ 6.919702] drm_mode_config_validate+0x290/0x4d0
[ 6.921960] drm_dev_register+0x17c/0x210
[ 6.926821] msm_drm_bind+0x4b4/0x694
[ 6.930813] try_to_bring_up_master+0x164/0x1d0
[ 6.934459] __component_add+0xa0/0x170
[ 6.938799] component_add+0x14/0x20
[ 6.942619] msm_hdmi_dev_probe+0x1c/0x2c
[ 6.946438] platform_probe+0x68/0xe0
[ 6.950345] really_probe.part.0+0x9c/0x30c
[ 6.953991] __driver_probe_device+0x98/0x144
[ 6.957984] driver_probe_device+0xc8/0x15c
[ 6.962498] __device_attach_driver+0xb4/0x120
[ 6.966492] bus_for_each_drv+0x78/0xd0
[ 6.971004] __device_attach+0xdc/0x184
[ 6.974737] device_initial_probe+0x14/0x20
[ 6.978556] bus_probe_device+0x9c/0xa4
[ 6.982722] deferred_probe_work_func+0x88/0xc0
[ 6.986543] process_one_work+0x1d0/0x370
[ 6.991057] worker_thread+0x2c8/0x470
[ 6.995223] kthread+0x15c/0x170
[ 6.998869] ret_from_fork+0x10/0x20
[ 7.002255] ---[ end trace
5884eb76cd26d275 ]---
Fixes:
aa649e875daf ("drm/msm/mdp5: mdp5_crtc: Restore cursor state only if LM cursors are enabled")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210925192824.3416259-1-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Wed, 29 Sep 2021 12:18:57 +0000 (13:18 +0100)]
drm/msm: Fix null pointer dereference on pointer edp
commit
2133c4fc8e1348dcb752f267a143fe2254613b34 upstream.
The initialization of pointer dev dereferences pointer edp before
edp is null checked, so there is a potential null pointer deference
issue. Fix this by only dereferencing edp after edp has been null
checked.
Addresses-Coverity: ("Dereference before null check")
Fixes:
ab5b0107ccf3 ("drm/msm: Initial add eDP support in msm drm driver (v5)")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210929121857.213922-1-colin.king@canonical.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Douglas Anderson [Wed, 6 Oct 2021 02:29:08 +0000 (19:29 -0700)]
drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
commit
97794170b696856483f74b47bfb6049780d2d3a0 upstream.
In commit
e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid
corruption test") the function connector_bad_edid() started assuming
that the memory for the EDID passed to it was big enough to hold
`edid[0x7e] + 1` blocks of data (1 extra for the base block). It
completely ignored the fact that the function was passed `num_blocks`
which indicated how much memory had been allocated for the EDID.
Let's fix this by adding a bounds check.
This is important for handling the case where there's an error in the
first block of the EDID. In that case we will call
connector_bad_edid() without having re-allocated memory based on
`edid[0x7e]`.
Fixes:
e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005192905.v2.1.Ib059f9c23c2611cb5a9d760e7d0a700c1295928d@changeid
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vegard Nossum [Tue, 12 Oct 2021 11:52:42 +0000 (13:52 +0200)]
drm/panel: olimex-lcd-olinuxino: select CRC32
commit
a14bc107edd0c108bda2245e50daa22f91c95d20 upstream.
Fix the following build/link error by adding a dependency on the CRC32
routines:
ld: drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.o: in function `lcd_olinuxino_probe':
panel-olimex-lcd-olinuxino.c:(.text+0x303): undefined reference to `crc32_le'
Fixes:
17fd7a9d324fd ("drm/panel: Add support for Olimex LCD-OLinuXino panel")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211012115242.10325-1-vegard.nossum@oracle.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kamal Dasu [Fri, 8 Oct 2021 20:36:02 +0000 (16:36 -0400)]
spi: bcm-qspi: clear MSPI spifie interrupt during probe
commit
75b3cb97eb1f05042745c0655a7145b0262d4c5c upstream.
Intermittent Kernel crash has been observed on probe in
bcm_qspi_mspi_l2_isr() handler when the MSPI spifie interrupt bit
has not been cleared before registering for interrupts.
Fix the driver to move SoC specific custom interrupt handling code
before we register IRQ in probe. Also clear MSPI interrupt status
resgiter prior to registering IRQ handlers.
Fixes:
cc20a38612db ("spi: iproc-qspi: Add Broadcom iProc SoCs support")
Signed-off-by: Kamal Dasu <kdasu@broadcom.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20211008203603.40915-3-kdasu.kdev@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vadim Pasternak [Mon, 27 Sep 2021 14:22:14 +0000 (17:22 +0300)]
platform/mellanox: mlxreg-io: Fix read access of n-bytes size attributes
commit
db9cc7d6f95e7d89b0ce57e785cfd9d67a7505d8 upstream.
Fix shift argument for function rol32(). It should be provided in bits,
while was provided in bytes.
Fixes:
86148190a7db ("platform/mellanox: mlxreg-io: Add support for complex attributes")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20210927142214.2613929-3-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vadim Pasternak [Mon, 27 Sep 2021 14:22:13 +0000 (17:22 +0300)]
platform/mellanox: mlxreg-io: Fix argument base in kstrtou32() call
commit
9b024201693e397441668cca0d2df7055fe572eb upstream.
Change kstrtou32() argument 'base' to be zero instead of 'len'.
It works by chance for setting one bit value, but it is not supposed to
work in case value passed to mlxreg_io_attr_store() is greater than 1.
It works for example, for:
echo 1 > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable
But it will fail for:
echo n > /sys/devices/platform/mlxplat/mlxreg-io/hwmon/.../jtag_enable,
where n > 1.
The flow for input buffer conversion is as below:
_kstrtoull(const char *s, unsigned int base, unsigned long long *res)
calls:
rv = _parse_integer(s, base, &_res);
For the second case, where n > 1:
- _parse_integer() converts 's' to 'val'.
For n=2, 'len' is set to 2 (string buffer is 0x32 0x0a), for n=3
'len' is set to 3 (string buffer 0x33 0x0a), etcetera.
- 'base' is equal or greater then '2' (length of input buffer).
As a result, _parse_integer() exits with result zero (rv):
rv = 0;
while (1) {
...
if (val >= base)-> (2 >= 2)
break;
...
rv++;
...
}
And _kstrtoull() in their turn will fail:
if (rv == 0)
return -EINVAL;
Fixes:
5ec4a8ace06c ("platform/mellanox: Introduce support for Mellanox register access driver")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20210927142214.2613929-2-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ido Schimmel [Tue, 12 Oct 2021 17:49:55 +0000 (20:49 +0300)]
mlxsw: thermal: Fix out-of-bounds memory accesses
commit
332fdf951df8b870e3da86b122ae304e2aabe88c upstream.
Currently, mlxsw allows cooling states to be set above the maximum
cooling state supported by the driver:
# cat /sys/class/thermal/thermal_zone2/cdev0/type
mlxsw_fan
# cat /sys/class/thermal/thermal_zone2/cdev0/max_state
10
# echo 18 > /sys/class/thermal/thermal_zone2/cdev0/cur_state
# echo $?
0
This results in out-of-bounds memory accesses when thermal state
transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the
transition table is accessed with a too large index (state) [1].
According to the thermal maintainer, it is the responsibility of the
driver to reject such operations [2].
Therefore, return an error when the state to be set exceeds the maximum
cooling state supported by the driver.
To avoid dead code, as suggested by the thermal maintainer [3],
partially revert commit
a421ce088ac8 ("mlxsw: core: Extend cooling
device with cooling levels") that tried to interpret these invalid
cooling states (above the maximum) in a special way. The cooling levels
array is not removed in order to prevent the fans going below 20% PWM,
which would cause them to get stuck at 0% PWM.
[1]
BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290
Read of size 4 at addr
ffff8881052f7bf8 by task kworker/0:0/5
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122
Hardware name: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 03/08/2016
Workqueue: events_freezable_power_ thermal_zone_device_check
Call Trace:
dump_stack_lvl+0x8b/0xb3
print_address_description.constprop.0+0x1f/0x140
kasan_report.cold+0x7f/0x11b
thermal_cooling_device_stats_update+0x271/0x290
__thermal_cdev_update+0x15e/0x4e0
thermal_cdev_update+0x9f/0xe0
step_wise_throttle+0x770/0xee0
thermal_zone_device_update+0x3f6/0xdf0
process_one_work+0xa42/0x1770
worker_thread+0x62f/0x13e0
kthread+0x3ee/0x4e0
ret_from_fork+0x1f/0x30
Allocated by task 1:
kasan_save_stack+0x1b/0x40
__kasan_kmalloc+0x7c/0x90
thermal_cooling_device_setup_sysfs+0x153/0x2c0
__thermal_cooling_device_register.part.0+0x25b/0x9c0
thermal_cooling_device_register+0xb3/0x100
mlxsw_thermal_init+0x5c5/0x7e0
__mlxsw_core_bus_device_register+0xcb3/0x19c0
mlxsw_core_bus_device_register+0x56/0xb0
mlxsw_pci_probe+0x54f/0x710
local_pci_probe+0xc6/0x170
pci_device_probe+0x2b2/0x4d0
really_probe+0x293/0xd10
__driver_probe_device+0x2af/0x440
driver_probe_device+0x51/0x1e0
__driver_attach+0x21b/0x530
bus_for_each_dev+0x14c/0x1d0
bus_add_driver+0x3ac/0x650
driver_register+0x241/0x3d0
mlxsw_sp_module_init+0xa2/0x174
do_one_initcall+0xee/0x5f0
kernel_init_freeable+0x45a/0x4de
kernel_init+0x1f/0x210
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at
ffff8881052f7800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 1016 bytes inside of
1024-byte region [
ffff8881052f7800,
ffff8881052f7c00)
The buggy address belongs to the page:
page:
0000000052355272 refcount:1 mapcount:0 mapping:
0000000000000000 index:0x0 pfn:0x1052f0
head:
0000000052355272 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x200000000010200(slab|head|node=0|zone=2)
raw:
0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0
raw:
0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[2] https://lore.kernel.org/linux-pm/
9aca37cb-1629-5c67-1895-
1fdc45c0244e@linaro.org/
[3] https://lore.kernel.org/linux-pm/
af9857f2-578e-de3a-e62b-
6baff7e69fd4@linaro.org/
CC: Daniel Lezcano <daniel.lezcano@linaro.org>
Fixes:
a50c1e35650b ("mlxsw: core: Implement thermal zone")
Fixes:
a421ce088ac8 ("mlxsw: core: Extend cooling device with cooling levels")
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20211012174955.472928-1-idosch@idosch.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wang Hai [Wed, 13 Oct 2021 06:16:31 +0000 (14:16 +0800)]
ata: ahci_platform: fix null-ptr-deref in ahci_platform_enable_regulators()
commit
776c75010803849c1cc4f11031a2b3960ab05202 upstream.
I got a null-ptr-deref report:
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
...
RIP: 0010:regulator_enable+0x84/0x260
...
Call Trace:
ahci_platform_enable_regulators+0xae/0x320
ahci_platform_enable_resources+0x1a/0x120
ahci_probe+0x4f/0x1b9
platform_probe+0x10b/0x280
...
entry_SYSCALL_64_after_hwframe+0x44/0xae
If devm_regulator_get() in ahci_platform_get_resources() fails,
hpriv->phy_regulator will point to NULL, when enabling or disabling it,
null-ptr-deref will occur.
ahci_probe()
ahci_platform_get_resources()
devm_regulator_get(, "phy") // failed, let phy_regulator = NULL
ahci_platform_enable_resources()
ahci_platform_enable_regulators()
regulator_enable(hpriv->phy_regulator) // null-ptr-deref
commit
962399bb7fbf ("ata: libahci_platform: Fix regulator_get_optional()
misuse") replaces devm_regulator_get_optional() with devm_regulator_get(),
but PHY regulator omits to delete "hpriv->phy_regulator = NULL;" like AHCI.
Delete it like AHCI regulator to fix this bug.
Fixes: commit
962399bb7fbf ("ata: libahci_platform: Fix regulator_get_optional() misuse")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Wed, 6 Oct 2021 07:34:19 +0000 (10:34 +0300)]
pata_legacy: fix a couple uninitialized variable bugs
commit
013923477cb311293df9079332cf8b806ed0e6f2 upstream.
The last byte of "pad" is used without being initialized.
Fixes:
55dba3120fbc ("libata: update ->data_xfer hook for ATAPI")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ziyang Xuan [Wed, 13 Oct 2021 07:50:32 +0000 (15:50 +0800)]
NFC: digital: fix possible memory leak in digital_in_send_sdd_req()
commit
291c932fc3692e4d211a445ba8aa35663831bac7 upstream.
'skb' is allocated in digital_in_send_sdd_req(), but not free when
digital_in_send_cmd() failed, which will cause memory leak. Fix it
by freeing 'skb' if digital_in_send_cmd() return failed.
Fixes:
2c66daecc409 ("NFC Digital: Add NFC-A technology support")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ziyang Xuan [Wed, 13 Oct 2021 07:50:12 +0000 (15:50 +0800)]
NFC: digital: fix possible memory leak in digital_tg_listen_mdaa()
commit
58e7dcc9ca29c14e44267a4d0ea61e3229124907 upstream.
'params' is allocated in digital_tg_listen_mdaa(), but not free when
digital_send_cmd() failed, which will cause memory leak. Fix it by
freeing 'params' if digital_send_cmd() return failed.
Fixes:
1c7a4c24fbfd ("NFC Digital: Add target NFC-DEP support")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ziyang Xuan [Wed, 13 Oct 2021 03:49:32 +0000 (11:49 +0800)]
nfc: fix error handling of nfc_proto_register()
commit
0911ab31896f0e908540746414a77dd63912748d upstream.
When nfc proto id is using, nfc_proto_register() return -EBUSY error
code, but forgot to unregister proto. Fix it by adding proto_unregister()
in the error handling case.
Fixes:
c7fe3b52c128 ("NFC: add NFC socket family")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211013034932.2833737-1-william.xuanziyang@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cindy Lu [Wed, 29 Sep 2021 09:09:33 +0000 (17:09 +0800)]
vhost-vdpa: Fix the wrong input in config_cb
commit
bcef9356fc2e1302daf373c83c826aa27954d128 upstream.
Fix the wrong input in for config_cb. In function vhost_vdpa_config_cb,
the input cb.private was used as struct vhost_vdpa, so the input was
wrong here, fix this issue
Fixes:
776f395004d8 ("vhost_vdpa: Support config interrupt in vdpa")
Signed-off-by: Cindy Lu <lulu@redhat.com>
Link: https://lore.kernel.org/r/20210929090933.20465-1-lulu@redhat.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Wed, 13 Oct 2021 14:35:49 +0000 (16:35 +0200)]
ethernet: s2io: fix setting mac address during resume
commit
40507e7aada8422c38aafa0c8a1a09e4623c712a upstream.
After recent cleanups, gcc started warning about a suspicious
memcpy() call during the s2io_io_resume() function:
In function '__dev_addr_set',
inlined from 'eth_hw_addr_set' at include/linux/etherdevice.h:318:2,
inlined from 's2io_set_mac_addr' at drivers/net/ethernet/neterion/s2io.c:5205:2,
inlined from 's2io_io_resume' at drivers/net/ethernet/neterion/s2io.c:8569:7:
arch/x86/include/asm/string_32.h:182:25: error: '__builtin_memcpy' accessing 6 bytes at offsets 0 and 2 overlaps 4 bytes at offset 2 [-Werror=restrict]
182 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/netdevice.h:4648:9: note: in expansion of macro 'memcpy'
4648 | memcpy(dev->dev_addr, addr, len);
| ^~~~~~
What apparently happened is that an old cleanup changed the calling
conventions for s2io_set_mac_addr() from taking an ethernet address
as a character array to taking a struct sockaddr, but one of the
callers was not changed at the same time.
Change it to instead call the low-level do_s2io_prog_unicast() function
that still takes the old argument type.
Fixes:
2fd376884558 ("S2io: Added support set_mac_address driver entry point")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211013143613.2049096-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nanyong Sun [Tue, 12 Oct 2021 12:59:01 +0000 (20:59 +0800)]
net: encx24j600: check error in devm_regmap_init_encx24j600
commit
f03dca0c9e2297c84a018e306f8a9cd534ee4287 upstream.
devm_regmap_init may return error which caused by like out of memory,
this will results in null pointer dereference later when reading
or writing register:
general protection fault in encx24j600_spi_probe
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11
9c53a778c1306b1b02359f3c2bbedc0222cba652
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540
Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00
RSP: 0018:
ffffc900010476b8 EFLAGS:
00010207
RAX:
dffffc0000000000 RBX:
fffffffffffffff4 RCX:
0000000000000000
RDX:
0000000000000012 RSI:
ffff888002de0000 RDI:
0000000000000094
RBP:
ffff888013c9a000 R08:
0000000000000000 R09:
fffffbfff3f9cc6a
R10:
ffffc900010476e8 R11:
fffffbfff3f9cc69 R12:
0000000000000001
R13:
000000000000000a R14:
ffff888013c9af54 R15:
ffff888013c9ad08
FS:
00007ffa984ab580(0000) GS:
ffff88801fe00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
000055a6384136c8 CR3:
000000003bbe6003 CR4:
0000000000770ef0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
PKRU:
55555554
Call Trace:
encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459
spi_probe drivers/spi/spi.c:397
really_probe drivers/base/dd.c:517
__driver_probe_device drivers/base/dd.c:751
driver_probe_device drivers/base/dd.c:782
__device_attach_driver drivers/base/dd.c:899
bus_for_each_drv drivers/base/bus.c:427
__device_attach drivers/base/dd.c:971
bus_probe_device drivers/base/bus.c:487
device_add drivers/base/core.c:3364
__spi_add_device drivers/spi/spi.c:599
spi_add_device drivers/spi/spi.c:641
spi_new_device drivers/spi/spi.c:717
new_device_store+0x18c/0x1f1 [spi_stub
4e02719357f1ff33f5a43d00630982840568e85e]
dev_attr_store drivers/base/core.c:2074
sysfs_kf_write fs/sysfs/file.c:139
kernfs_fop_write_iter fs/kernfs/file.c:300
new_sync_write fs/read_write.c:508 (discriminator 4)
vfs_write fs/read_write.c:594
ksys_write fs/read_write.c:648
do_syscall_64 arch/x86/entry/common.c:50
entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113
Add error check in devm_regmap_init_encx24j600 to avoid this situation.
Fixes:
04fbfce7a222 ("net: Microchip encx24j600 driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Nanyong Sun <sunnanyong@huawei.com>
Link: https://lore.kernel.org/r/20211012125901.3623144-1-sunnanyong@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arun Ramadoss [Mon, 11 Oct 2021 15:48:08 +0000 (21:18 +0530)]
net: dsa: microchip: Added the condition for scheduling ksz_mib_read_work
commit
ef1100ef20f29aec4e62abeccdb5bdbebba1e378 upstream.
When the ksz module is installed and removed using rmmod, kernel crashes
with null pointer dereferrence error. During rmmod, ksz_switch_remove
function tries to cancel the mib_read_workqueue using
cancel_delayed_work_sync routine and unregister switch from dsa.
During dsa_unregister_switch it calls ksz_mac_link_down, which in turn
reschedules the workqueue since mib_interval is non-zero.
Due to which queue executed after mib_interval and it tries to access
dp->slave. But the slave is unregistered in the ksz_switch_remove
function. Hence kernel crashes.
To avoid this crash, before canceling the workqueue, resetted the
mib_interval to 0.
v1 -> v2:
-Removed the if condition in ksz_mib_read_work
Fixes:
469b390e1ba3 ("net: dsa: microchip: use delayed_work instead of timer + work")
Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Herve Codina [Fri, 8 Oct 2021 10:34:37 +0000 (12:34 +0200)]
net: stmmac: fix get_hw_feature() on old hardware
commit
075da584bae2da6a37428d59a477b6bdad430ac3 upstream.
Some old IPs do not provide the hardware feature register.
On these IPs, this register is read 0x00000000.
In old driver version, this feature was handled but a regression came
with the commit
f10a6a3541b4 ("stmmac: rework get_hw_feature function").
Indeed, this commit removes the return value in dma->get_hw_feature().
This return value was used to indicate the validity of retrieved
information and used later on in stmmac_hw_init() to override
priv->plat data if this hardware feature were valid.
This patch restores the return code in ->get_hw_feature() in order
to indicate the hardware feature validity and override priv->plat
data only if this hardware feature is valid.
Fixes:
f10a6a3541b4 ("stmmac: rework get_hw_feature function")
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aya Levin [Sun, 26 Sep 2021 14:55:41 +0000 (17:55 +0300)]
net/mlx5e: Mutually exclude RX-FCS and RX-port-timestamp
commit
0bc73ad46a76ed6ece4dcacb28858e7b38561e1c upstream.
Due to current HW arch limitations, RX-FCS (scattering FCS frame field
to software) and RX-port-timestamp (improved timestamp accuracy on the
receive side) can't work together.
RX-port-timestamp is not controlled by the user and it is enabled by
default when supported by the HW/FW.
This patch sets RX-port-timestamp opposite to RX-FCS configuration.
Fixes:
102722fc6832 ("net/mlx5e: Add support for RXFCS feature flag")
Signed-off-by: Aya Levin <ayal@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Valentine Fatiev [Sun, 15 Aug 2021 14:43:19 +0000 (17:43 +0300)]
net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path
commit
94b960b9deffc02fc0747afc01f72cc62ab099e3 upstream.
Prior to this patch in case mlx5_core_destroy_cq() failed it returns
without completing all destroy operations and that leads to memory leak.
Instead, complete the destroy flow before return error.
Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq()
to be symmetrical with mlx5_core_create_cq().
kmemleak complains on:
unreferenced object 0xc000000038625100 (size 64):
comm "ethtool", pid 28301, jiffies
4298062946 (age 785.380s)
hex dump (first 32 bytes):
60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4.....
02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}.....
backtrace:
[<
000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core]
[<
00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core]
[<
000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core]
[<
00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core]
[<
000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core]
[<
0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core]
[<
0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core]
[<
0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230
[mlx5_core]
[<
0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300
[mlx5_core]
[<
0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core]
[<
00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core]
[<
00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0
[<
00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0
[<
00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0
[<
00000000646c5c2c>] genl_rcv_msg+0x78/0x120
[<
00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0
Fixes:
e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Valentine Fatiev <valentinef@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vegard Nossum [Tue, 12 Oct 2021 15:25:09 +0000 (17:25 +0200)]
net: korina: select CRC32
commit
427f974d9727ca681085ddcd0530c97ab5811ae0 upstream.
Fix the following build/link error by adding a dependency on the CRC32
routines:
ld: drivers/net/ethernet/korina.o: in function `korina_multicast_list':
korina.c:(.text+0x1af): undefined reference to `crc32_le'
Fixes:
ef11291bcd5f9 ("Add support the Korina (IDT RC32434) Ethernet MAC")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Acked-by: Florian fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20211012152509.21771-1-vegard.nossum@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vegard Nossum [Tue, 12 Oct 2021 09:34:46 +0000 (11:34 +0200)]
net: arc: select CRC32
commit
e599ee234ad4fdfe241d937bbabd96e0d8f9d868 upstream.
Fix the following build/link error by adding a dependency on the CRC32
routines:
ld: drivers/net/ethernet/arc/emac_main.o: in function `arc_emac_set_rx_mode':
emac_main.c:(.text+0xb11): undefined reference to `crc32_le'
The crc32_le() call comes through the ether_crc_le() call in
arc_emac_set_rx_mode().
[v2: moved the select to ARC_EMAC_CORE; the Makefile is a bit confusing,
but the error comes from emac_main.o, which is part of the arc_emac module,
which in turn is enabled by CONFIG_ARC_EMAC_CORE. Note that arc_emac is
different from emac_arc...]
Fixes:
775dd682e2b0ec ("arc_emac: implement promiscuous mode and multicast filtering")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Link: https://lore.kernel.org/r/20211012093446.1575-1-vegard.nossum@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Shevchenko [Thu, 23 Sep 2021 22:46:40 +0000 (01:46 +0300)]
gpio: pca953x: Improve bias setting
commit
55a9968c7e139209a9e93d4ca4321731bea5fc95 upstream.
The commit
15add06841a3 ("gpio: pca953x: add ->set_config implementation")
introduced support for bias setting. However this, due to being half-baked,
brought potential issues:
- the turning bias via disabling makes the pin floating for a while;
- once enabled, bias can't be disabled.
Fix all these by adding support for bias disabling and move the disabling
part under the corresponding conditional.
While at it, add support for default setting, since it's cheap to add.
Fixes:
15add06841a3 ("gpio: pca953x: add ->set_config implementation")
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eiichi Tsukata [Wed, 13 Oct 2021 20:27:29 +0000 (17:27 -0300)]
sctp: account stream padding length for reconf chunk
commit
a2d859e3fc97e79d907761550dbc03ff1b36479c upstream.
sctp_make_strreset_req() makes repeated calls to sctp_addto_chunk()
which will automatically account for padding on each call. inreq and
outreq are already 4 bytes aligned, but the payload is not and doing
SCTP_PAD4(a + b) (which _sctp_make_chunk() did implicitly here) is
different from SCTP_PAD4(a) + SCTP_PAD4(b) and not enough. It led to
possible attempt to use more buffer than it was allocated and triggered
a BUG_ON.
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Fixes:
cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk")
Reported-by: Eiichi Tsukata <eiichi.tsukata@nutanix.com>
Signed-off-by: Eiichi Tsukata <eiichi.tsukata@nutanix.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
Link: https://lore.kernel.org/r/b97c1f8b0c7ff79ac4ed206fc2c49d3612e0850c.1634156849.git.mleitner@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Keith Busch [Thu, 7 Oct 2021 06:50:31 +0000 (23:50 -0700)]
nvme-pci: Fix abort command id
commit
85f74acf097a63a07f5a7c215db6883e5c35e3ff upstream.
The request tag is no longer the only component of the command id.
Fixes:
e7006de6c2380 ("nvme: code command_id with a genctr for use-after-free validation")
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Saenz Julienne [Tue, 31 Aug 2021 12:58:42 +0000 (14:58 +0200)]
ARM: dts: bcm2711-rpi-4-b: Fix pcie0's unit address formatting
commit
13dbc954b3c9a9de0ad5b7279e8d3b708d31068b upstream.
dtbs_check currently complains that:
arch/arm/boot/dts/bcm2711-rpi-4-b.dts:220.10-231.4: Warning
(pci_device_reg): /scb/pcie@
7d500000/pci@1,0: PCI unit address format
error, expected "0,0"
Unsurprisingly pci@0,0 is the right address, as illustrated by its reg
property:
&pcie0 {
pci@0,0 {
/*
* As defined in the IEEE Std 1275-1994 document,
* reg is a five-cell address encoded as (phys.hi
* phys.mid phys.lo size.hi size.lo). phys.hi
* should contain the device's BDF as
0b00000000
*
bbbbbbbb dddddfff 00000000. The other cells
* should be zero.
*/
reg = <0 0 0 0 0>;
};
};
The device is clearly 0. So fix it.
Also add a missing 'device_type = "pci"'.
Fixes:
258f92d2f840 ("ARM: dts: bcm2711: Add reset controller to xHCI node")
Suggested-by: Rob Herring <robh@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210831125843.1233488-1-nsaenzju@redhat.com
Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Wahren [Sat, 7 Aug 2021 11:06:33 +0000 (13:06 +0200)]
ARM: dts: bcm2711-rpi-4-b: fix sd_io_1v8_reg regulator states
commit
b55ec7528879a822a4d350248daa04bbb27f25fd upstream.
DT schema check complains at sd_io_1v8_reg about the following:
[1800000, 1, 3300000, 0] is too long
Additional items are not allowed (3300000, 0 were unexpected)
So fix the states definition.
Fixes:
7dbe8c62ceeb ("ARM: dts: Add minimal Raspberry Pi 4 support")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/1628334401-6577-3-git-send-email-stefan.wahren@i2se.com
Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Wahren [Sat, 7 Aug 2021 11:06:32 +0000 (13:06 +0200)]
ARM: dts: bcm2711: fix MDIO #address- and #size-cells
commit
2faff6737a8a684b077264f0aed131526c99eec4 upstream.
The values of #address-cells and #size-cells are swapped. Fix this
and avoid the following DT schema warnings for mdio@e14:
#address-cells:0:0: 1 was expected
#size-cells:0:0: 0 was expected
Fixes:
be8af7a9e3cc ("ARM: dts: bcm2711-rpi-4: Enable GENET support")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Link: https://lore.kernel.org/r/1628334401-6577-2-git-send-email-stefan.wahren@i2se.com
Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Saenz Julienne [Tue, 31 Aug 2021 12:58:43 +0000 (14:58 +0200)]
ARM: dts: bcm2711-rpi-4-b: Fix usb's unit address
commit
3f32472854614d6f53b09b4812372dba9fc5c7de upstream.
The unit address is supposed to represent '<device>,<function>'. Which
are both 0 for RPi4b's XHCI controller. On top of that although
OpenFirmware states bus number goes in the high part of the last reg
parameter, FDT doesn't seem to care for it[1], so remove it.
[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/
20210830103909.323356-1-nsaenzju@redhat.com/#
24414633
Fixes:
258f92d2f840 ("ARM: dts: bcm2711: Add reset controller to xHCI node")
Suggested-by: Rob Herring <robh@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210831125843.1233488-2-nsaenzju@redhat.com
Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sumit Garg [Tue, 12 Oct 2021 07:31:16 +0000 (13:01 +0530)]
tee: optee: Fix missing devices unregister during optee_remove
commit
7f565d0ead264329749c0da488de9c8dfa2f18ce upstream.
When OP-TEE driver is built as a module, OP-TEE client devices
registered on TEE bus during probe should be unregistered during
optee_remove. So implement optee_unregister_devices() accordingly.
Fixes:
c3fa24af9244 ("tee: optee: add TEE bus device enumeration support")
Reported-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Mon, 16 Aug 2021 18:39:54 +0000 (21:39 +0300)]
iio: dac: ti-dac5571: fix an error code in probe()
commit
f7a28df7db84eb3410e9eca37832efa5aed93338 upstream.
If we have an unexpected number of channels then return -EINVAL instead
of returning success.
Fixes:
df38a4a72a3b ("iio: dac: add TI DAC5571 family support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20210816183954.GB2068@kili
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Tue, 14 Sep 2021 10:53:33 +0000 (13:53 +0300)]
iio: ssp_sensors: fix error code in ssp_print_mcu_debug()
commit
4170d3dd1467e9d78cb9af374b19357dc324b328 upstream.
The ssp_print_mcu_debug() function should return negative error codes on
error. Returning "length" is meaningless. This change does not affect
runtime because the callers only care about zero/non-zero.
Reported-by: Jonathan Cameron <jic23@kernel.org>
Fixes:
50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20210914105333.GA11657@kili
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 9 Sep 2021 09:13:36 +0000 (12:13 +0300)]
iio: ssp_sensors: add more range checking in ssp_parse_dataframe()
commit
8167c9a375ccceed19048ad9d68cb2d02ed276e0 upstream.
The "idx" is validated at the start of the loop but it gets incremented
during the iteration so it needs to be checked again.
Fixes:
50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20210909091336.GA26312@kili
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miquel Raynal [Wed, 18 Aug 2021 11:11:25 +0000 (13:11 +0200)]
iio: adc: max1027: Fix the number of max1X31 channels
commit
f0cb5fed37ab37f6a6c5463c5fd39b58a45670c8 upstream.
The macro MAX1X29_CHANNELS() already calls MAX1X27_CHANNELS().
Calling MAX1X27_CHANNELS() before MAX1X29_CHANNELS() in the definition
of MAX1X31_CHANNELS() declares the first 8 channels twice. So drop this
extra call from the MAX1X31 channels list definition.
Fixes:
7af5257d8427 ("iio: adc: max1027: Prepare the introduction of different resolutions")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210818111139.330636-3-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Valek - 2N [Mon, 20 Sep 2021 12:53:48 +0000 (14:53 +0200)]
iio: light: opt3001: Fixed timeout error when 0 lux
commit
26d90b5590579def54382a2fc34cfbe8518a9851 upstream.
Reading from sensor returned timeout error under
zero light conditions.
Signed-off-by: Jiri Valek - 2N <valek@2n.cz>
Fixes:
ac663db3678a ("iio: light: opt3001: enable operation w/o IRQ")
Link: https://lore.kernel.org/r/20210920125351.6569-1-valek@2n.cz
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hui Liu [Sun, 26 Sep 2021 07:30:28 +0000 (15:30 +0800)]
iio: mtk-auxadc: fix case IIO_CHAN_INFO_PROCESSED
commit
c2980c64c7fd4585d684574c92d1624d44961edd upstream.
The previous driver does't apply the necessary scaling to take the
voltage range into account.
We change readback value from raw data to input voltage to fix case
IIO_CHAN_INFO_PROCESSED.
Fixes:
ace4cdfe67be ("iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.")
Signed-off-by: Hui Liu <hui.liu@mediatek.com>
Link: https://lore.kernel.org/r/20210926073028.11045-2-hui.liu@mediatek.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miquel Raynal [Wed, 18 Aug 2021 11:11:24 +0000 (13:11 +0200)]
iio: adc: max1027: Fix wrong shift with 12-bit devices
commit
732ae19ee8f58ecaf30cbc1bbbda5cbee6a45043 upstream.
10-bit devices must shift the value twice.
This is not needed anymore on 12-bit devices.
Fixes:
ae47d009b508 ("iio: adc: max1027: Introduce 12-bit devices support")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210818111139.330636-2-miquel.raynal@bootlin.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Sat, 21 Aug 2021 10:37:24 +0000 (12:37 +0200)]
iio: adc128s052: Fix the error handling path of 'adc128_probe()'
commit
bbcf40816b547b3c37af49168950491d20d81ce1 upstream.
A successful 'regulator_enable()' call should be balanced by a
corresponding 'regulator_disable()' call in the error handling path of the
probe, as already done in the remove function.
Update the error handling path accordingly.
Fixes:
913b86468674 ("iio: adc: Add TI ADC128S052")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/85189f1cfcf6f5f7b42d8730966f2a074b07b5f5.1629542160.git.christophe.jaillet@wanadoo.fr
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandru Tachici [Mon, 6 Sep 2021 06:56:30 +0000 (09:56 +0300)]
iio: adc: ad7793: Fix IRQ flag
commit
1a913270e57a8e7f1e3789802f1f64e6d0654626 upstream.
In Sigma-Delta devices the SDO line is also used as an interrupt.
Leaving IRQ on level instead of falling might trigger a sample read
when the IRQ is enabled, as the SDO line is already low. Not sure
if SDO line will always immediately go high in ad_sd_buffer_postenable
before the IRQ is enabled.
Also the datasheet seem to explicitly say the falling edge of the SDO
should be used as an interrupt:
>From the AD7793 datasheet: " The DOUT/RDY falling edge can be
used as an interrupt to a processor"
Fixes:
da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags")
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210906065630.16325-4-alexandru.tachici@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandru Tachici [Mon, 6 Sep 2021 06:56:29 +0000 (09:56 +0300)]
iio: adc: ad7780: Fix IRQ flag
commit
e081102f3077aa716974ccebec97003c890d5641 upstream.
Correct IRQ flag here is falling.
In Sigma-Delta devices the SDO line is also used as an interrupt.
Leaving IRQ on level instead of falling might trigger a sample read
when the IRQ is enabled, as the SDO line is already low. Not sure
if SDO line will always immediately go high in ad_sd_buffer_postenable
before the IRQ is enabled.
Also the datasheet seem to explicitly say the falling edge of the SDO
should be used as an interrupt:
>From the AD7780 datasheet: " The DOUT/Figure 22 RDY falling edge
can be used as an interrupt to a processor"
Fixes:
da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags")
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210906065630.16325-3-alexandru.tachici@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandru Tachici [Mon, 6 Sep 2021 06:56:28 +0000 (09:56 +0300)]
iio: adc: ad7192: Add IRQ flag
commit
89a86da5cb8e0ee153111fb68a719d31582c206b upstream.
IRQ type in ad_sigma_delta_info struct was missing.
In Sigma-Delta devices the SDO line is also used as an interrupt.
Leaving IRQ on level instead of falling might trigger a sample read
when the IRQ is enabled, as the SDO line is already low. Not sure
if SDO line will always immediately go high in ad_sd_buffer_postenable
before the IRQ is enabled.
Also the datasheet seem to explicitly say the falling edge of the SDO
should be used as an interrupt:
>From the AD7192 datasheet: "The DOUT/RDY falling edge can be used
as an interrupt to a processor,"
Fixes:
da4d3d6bb9f6 ("iio: adc: ad-sigma-delta: Allow custom IRQ flags")
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210906065630.16325-2-alexandru.tachici@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Saravana Kannan [Wed, 29 Sep 2021 19:05:49 +0000 (12:05 -0700)]
driver core: Reject pointless SYNC_STATE_ONLY device links
commit
f729a592adb6760013c3e48622a5bf256b992452 upstream.
SYNC_STATE_ONLY device links intentionally allow cycles because cyclic
sync_state() dependencies are valid and necessary.
However a SYNC_STATE_ONLY device link where the consumer and the supplier
are the same device is pointless because the device link would be deleted
as soon as the device probes (because it's also the consumer) and won't
affect when the sync_state() callback is called. It's a waste of CPU cycles
and memory to create this device link. So reject any attempts to create
such a device link.
Fixes:
05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY flag")
Cc: stable <stable@vger.kernel.org>
Reported-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210929190549.860541-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Saravana Kannan [Wed, 29 Sep 2021 00:07:33 +0000 (17:07 -0700)]
drivers: bus: simple-pm-bus: Add support for probing simple bus only devices
commit
98e96cf80045a383fcc47c58dd4e87b3ae587b3e upstream.
fw_devlink could end up creating device links for bus only devices.
However, bus only devices don't get probed and can block probe() or
sync_state() [1] call backs of other devices. To avoid this, probe these
devices using the simple-pm-bus driver.
However, there are instances of devices that are not simple buses (they get
probed by their specific drivers) that also list the "simple-bus" (or other
bus only compatible strings) in their compatible property to automatically
populate their child devices. We still want these devices to get probed by
their specific drivers. So, we make sure this driver only probes devices
that are only buses.
[1] - https://lore.kernel.org/lkml/CAPDyKFo9Bxremkb1dDrr4OcXSpE0keVze94Cm=zrkOVxHHxBmQ@mail.gmail.com/
Fixes:
c442a0d18744 ("driver core: Set fw_devlink to "permissive" behavior by default")
Cc: stable <stable@vger.kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Tested-by: Saravana Kannan <saravanak@google.com>
Tested-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210929000735.585237-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Billy Tsai [Tue, 31 Aug 2021 07:14:44 +0000 (15:14 +0800)]
iio: adc: aspeed: set driver data when adc probe.
commit
eb795cd97365a3d3d9da3926d234a7bc32a3bb15 upstream.
Fix the issue when adc remove will get the null driver data.
Fixed: commit
573803234e72 ("iio: Aspeed ADC")
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Link: https://lore.kernel.org/r/20210831071458.2334-2-billy_tsai@aspeedtech.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cédric Le Goater [Mon, 11 Oct 2021 07:02:03 +0000 (09:02 +0200)]
powerpc/xive: Discard disabled interrupts in get_irqchip_state()
commit
6f779e1d359b8d5801f677c1d49dcfa10bf95674 upstream.
When an interrupt is passed through, the KVM XIVE device calls the
set_vcpu_affinity() handler which raises the P bit to mask the
interrupt and to catch any in-flight interrupts while routing the
interrupt to the guest.
On the guest side, drivers (like some Intels) can request at probe
time some MSIs and call synchronize_irq() to check that there are no
in flight interrupts. This will call the XIVE get_irqchip_state()
handler which will always return true as the interrupt P bit has been
set on the host side and lock the CPU in an infinite loop.
Fix that by discarding disabled interrupts in get_irqchip_state().
Fixes:
da15c03b047d ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race")
Cc: stable@vger.kernel.org #v5.4+
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Tested-by: seeteena <s1seetee@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211011070203.99726-1-clg@kaod.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Wed, 6 Oct 2021 17:34:55 +0000 (19:34 +0200)]
x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT automatically
commit
711885906b5c2df90746a51f4cd674f1ab9fbb1d upstream.
This Kconfig option was added initially so that memory encryption is
enabled by default on machines which support it.
However, devices which have DMA masks that are less than the bit
position of the encryption bit, aka C-bit, require the use of an IOMMU
or the use of SWIOTLB.
If the IOMMU is disabled or in passthrough mode, the kernel would switch
to SWIOTLB bounce-buffering for those transfers.
In order to avoid that,
2cc13bb4f59f ("iommu: Disable passthrough mode when SME is active")
disables the default IOMMU passthrough mode so that devices for which the
default 256K DMA is insufficient, can use the IOMMU instead.
However 2, there are cases where the IOMMU is disabled in the BIOS, etc.
(think the usual hardware folk "oops, I dropped the ball there" cases) or a
driver doesn't properly use the DMA APIs or a device has a firmware or
hardware bug, e.g.:
ea68573d408f ("drm/amdgpu: Fail to load on RAVEN if SME is active")
However 3, in the above GPU use case, there are APIs like Vulkan and
some OpenGL/OpenCL extensions which are under the assumption that
user-allocated memory can be passed in to the kernel driver and both the
GPU and CPU can do coherent and concurrent access to the same memory.
That cannot work with SWIOTLB bounce buffers, of course.
So, in order for those devices to function, drop the "default y" for the
SME by default active option so that users who want to have SME enabled,
will need to either enable it in their config or use "mem_encrypt=on" on
the kernel command line.
[ tlendacky: Generalize commit message. ]
Fixes:
7744ccdbc16f ("x86/mm: Add Secure Memory Encryption (SME) support")
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/8bbacd0e-4580-3194-19d2-a0ecad7df09c@molgen.mpg.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Boyd [Wed, 13 Oct 2021 12:45:11 +0000 (13:45 +0100)]
nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
commit
5d388fa01fa6eb310ac023a363a6cb216d9d8fe9 upstream.
If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic
*p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we
subtract one from that making a large number that is then shifted more than the
number of bits that fit into an unsigned long.
UBSAN reports this problem:
UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8
shift exponent 64 is too large for 64-bit type 'unsigned long'
CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
Workqueue: events_unbound deferred_probe_work_func
Call trace:
dump_backtrace+0x0/0x170
show_stack+0x24/0x30
dump_stack_lvl+0x64/0x7c
dump_stack+0x18/0x38
ubsan_epilogue+0x10/0x54
__ubsan_handle_shift_out_of_bounds+0x180/0x194
__nvmem_cell_read+0x1ec/0x21c
nvmem_cell_read+0x58/0x94
nvmem_cell_read_variable_common+0x4c/0xb0
nvmem_cell_read_variable_le_u32+0x40/0x100
a6xx_gpu_init+0x170/0x2f4
adreno_bind+0x174/0x284
component_bind_all+0xf0/0x264
msm_drm_bind+0x1d8/0x7a0
try_to_bring_up_master+0x164/0x1ac
__component_add+0xbc/0x13c
component_add+0x20/0x2c
dp_display_probe+0x340/0x384
platform_probe+0xc0/0x100
really_probe+0x110/0x304
__driver_probe_device+0xb8/0x120
driver_probe_device+0x4c/0xfc
__device_attach_driver+0xb0/0x128
bus_for_each_drv+0x90/0xdc
__device_attach+0xc8/0x174
device_initial_probe+0x20/0x2c
bus_probe_device+0x40/0xa4
deferred_probe_work_func+0x7c/0xb8
process_one_work+0x128/0x21c
process_scheduled_works+0x40/0x54
worker_thread+0x1ec/0x2a8
kthread+0x138/0x158
ret_from_fork+0x10/0x20
Fix it by making sure there are any bits to mask out.
Fixes:
69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers")
Cc: Douglas Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20211013124511.18726-1-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans Potsch [Wed, 6 Oct 2021 12:13:32 +0000 (14:13 +0200)]
EDAC/armada-xp: Fix output of uncorrectable error counter
commit
d9b7748ffc45250b4d7bcf22404383229bc495f5 upstream.
The number of correctable errors is displayed as uncorrectable
errors because the "SBE" error count is passed to both calls of
edac_mc_handle_error().
Pass the correct uncorrectable error count to the second
edac_mc_handle_error() call when logging uncorrectable errors.
[ bp: Massage commit message. ]
Fixes:
7f6998a41257 ("ARM: 8888/1: EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC")
Signed-off-by: Hans Potsch <hans.potsch@nokia.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20211006121332.58788-1-hans.potsch@nokia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Halil Pasic [Mon, 11 Oct 2021 05:39:21 +0000 (07:39 +0200)]
virtio: write back F_VERSION_1 before validate
commit
2f9a174f918e29608564c7a4e8329893ab604fb4 upstream.
The virtio specification virtio-v1.1-cs01 states: "Transitional devices
MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not
been acknowledged by the driver." This is exactly what QEMU as of 6.1
has done relying solely on VIRTIO_F_VERSION_1 for detecting that.
However, the specification also says: "... the driver MAY read (but MUST
NOT write) the device-specific configuration fields to check that it can
support the device ..." before setting FEATURES_OK.
In that case, any transitional device relying solely on
VIRTIO_F_VERSION_1 for detecting legacy drivers will return data in
legacy format. In particular, this implies that it is in big endian
format for big endian guests. This naturally confuses the driver which
expects little endian in the modern mode.
It is probably a good idea to amend the spec to clarify that
VIRTIO_F_VERSION_1 can only be relied on after the feature negotiation
is complete. Before validate callback existed, config space was only
read after FEATURES_OK. However, we already have two regressions, so
let's address this here as well.
The regressions affect the VIRTIO_NET_F_MTU feature of virtio-net and
the VIRTIO_BLK_F_BLK_SIZE feature of virtio-blk for BE guests when
virtio 1.0 is used on both sides. The latter renders virtio-blk unusable
with DASD backing, because things simply don't work with the default.
See Fixes tags for relevant commits.
For QEMU, we can work around the issue by writing out the feature bits
with VIRTIO_F_VERSION_1 bit set. We (ab)use the finalize_features
config op for this. This isn't enough to address all vhost devices since
these do not get the features until FEATURES_OK, however it looks like
the affected devices actually never handled the endianness for legacy
mode correctly, so at least that's not a regression.
No devices except virtio net and virtio blk seem to be affected.
Long term the right thing to do is to fix the hypervisors.
Cc: <stable@vger.kernel.org> #v4.11
Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Fixes:
82e89ea077b9 ("virtio-blk: Add validation for block size in config space")
Fixes:
fe36cbe0671e ("virtio_net: clear MTU when out of range")
Reported-by: markver@us.ibm.com
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Link: https://lore.kernel.org/r/20211011053921.1198936-1-pasic@linux.ibm.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Srinivas Kandagatla [Wed, 22 Sep 2021 15:43:26 +0000 (16:43 +0100)]
misc: fastrpc: Add missing lock before accessing find_vma()
commit
f9a470db2736b01538ad193c316eb3f26be37d58 upstream.
fastrpc driver is using find_vma() without any protection, as a
result we see below warning due to recent patch
5b78ed24e8ec
("mm/pagemap: add mmap_assert_locked() annotations to find_vma*()")
which added mmap_assert_locked() in find_vma() function.
This bug went un-noticed in previous versions. Fix this issue by adding
required protection while calling find_vma().
CPU: 0 PID: 209746 Comm: benchmark_model Not tainted 5.15.0-rc2-00445-ge14fe2bf817a-dirty #969
Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
pstate:
60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : find_vma+0x64/0xd0
lr : find_vma+0x60/0xd0
sp :
ffff8000158ebc40
...
Call trace:
find_vma+0x64/0xd0
fastrpc_internal_invoke+0x570/0xda8
fastrpc_device_ioctl+0x3e0/0x928
__arm64_sys_ioctl+0xac/0xf0
invoke_syscall+0x44/0x100
el0_svc_common.constprop.3+0x70/0xf8
do_el0_svc+0x24/0x88
el0_svc+0x3c/0x138
el0t_64_sync_handler+0x90/0xb8
el0t_64_sync+0x180/0x184
Fixes:
80f3afd72bd4 ("misc: fastrpc: consider address offset before sending to DSP")
Cc: stable@vger.kernel.org
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20210922154326.8927-1-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomaz Solc [Wed, 6 Oct 2021 12:57:50 +0000 (14:57 +0200)]
USB: serial: option: add prod. id for Quectel EG91
commit
c184accc4a42c7872dc8e8d0fc97a740dc61fe24 upstream.
Adding support for Quectel EG91 LTE module.
The interface layout is same as for EG95.
usb-devices output:
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2c7c ProdID=0191 Rev=03.18
S: Manufacturer=Android
S: Product=Android
C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
Interfaces:
0: Diag
1: GNSS
2: AT-command interface/modem
3: Modem
4: QMI
Signed-off-by: Tomaz Solc <tomaz.solc@tablix.org>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniele Palmas [Mon, 4 Oct 2021 10:56:55 +0000 (12:56 +0200)]
USB: serial: option: add Telit LE910Cx composition 0x1204
commit
f5a8a07edafed8bede17a95ef8940fe3a57a77d5 upstream.
Add the following Telit LE910Cx composition:
0x1204: tty, adb, mbim, tty, tty, tty, tty
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Link: https://lore.kernel.org/r/20211004105655.8515-1-dnlplm@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yu-Tung Chang [Thu, 30 Sep 2021 02:11:12 +0000 (10:11 +0800)]
USB: serial: option: add Quectel EC200S-CN module support
commit
2263eb7370060bdb0013bc14e1a7c9bf33617a55 upstream.
Add usb product id of the Quectel EC200S-CN module.
usb-devices output for 0x6002:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2c7c ProdID=6002 Rev=03.18
S: Manufacturer=Android
S: Product=Android
S: SerialNumber=0000
C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
Signed-off-by: Yu-Tung Chang <mtwget@gmail.com>
Link: https://lore.kernel.org/r/20210930021112.330396-1-mtwget@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aleksander Morgado [Thu, 7 Oct 2021 12:25:01 +0000 (14:25 +0200)]
USB: serial: qcserial: add EM9191 QDL support
commit
11c52d250b34a0862edc29db03fbec23b30db6da upstream.
When the module boots into QDL download mode it exposes the 1199:90d2
ids, which can be mapped to the qcserial driver, and used to run
firmware upgrades (e.g. with the qmi-firmware-update program).
T: Bus=01 Lev=03 Prnt=08 Port=03 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1199 ProdID=90d2 Rev=00.00
S: Manufacturer=Sierra Wireless, Incorporated
S: Product=Sierra Wireless EM9191
S: SerialNumber=8W0382004102A109
C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=2mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=qcserial
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Cullen [Fri, 15 Oct 2021 20:17:50 +0000 (13:17 -0700)]
Input: xpad - add support for another USB ID of Nacon GC-100
commit
3378a07daa6cdd11e042797454c706d1c69f9ca6 upstream.
The Nacon GX100XF is already mapped, but it seems there is a Nacon
GC-100 (identified as NC5136Wht PCGC-100WHITE though I believe other
colours exist) with a different USB ID when in XInput mode.
Signed-off-by: Michael Cullen <michael@michaelcullen.name>
Link: https://lore.kernel.org/r/20211015192051.5196-1-michael@michaelcullen.name
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miquel Raynal [Tue, 5 Oct 2021 22:16:31 +0000 (00:16 +0200)]
usb: musb: dsps: Fix the probe error path
commit
c2115b2b16421d93d4993f3fe4c520e91d6fe801 upstream.
Commit
7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after
initializing musb") has inverted the calls to
dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without
updating correctly the error path. dsps_create_musb_pdev() allocates and
registers a new platform device which must be unregistered and freed
with platform_device_unregister(), and this is missing upon
dsps_setup_optional_vbus_irq() error.
While on the master branch it seems not to trigger any issue, I observed
a kernel crash because of a NULL pointer dereference with a v5.10.70
stable kernel where the patch mentioned above was backported. With this
kernel version, -EPROBE_DEFER is returned the first time
dsps_setup_optional_vbus_irq() is called which triggers the probe to
error out without unregistering the platform device. Unfortunately, on
the Beagle Bone Black Wireless, the platform device still living in the
system is being used by the USB Ethernet gadget driver, which during the
boot phase triggers the crash.
My limited knowledge of the musb world prevents me to revert this commit
which was sent to silence a robot warning which, as far as I understand,
does not make sense. The goal of this patch was to prevent an IRQ to
fire before the platform device being registered. I think this cannot
ever happen due to the fact that enabling the interrupts is done by the
->enable() callback of the platform musb device, and this platform
device must be already registered in order for the core or any other
user to use this callback.
Hence, I decided to fix the error path, which might prevent future
errors on mainline kernels while also fixing older ones.
Fixes:
7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20211005221631.1529448-1-miquel.raynal@bootlin.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhang Jianhua [Thu, 23 Sep 2021 02:53:40 +0000 (10:53 +0800)]
efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock()
commit
38fa3206bf441911258e5001ac8b6738693f8d82 upstream.
While reboot the system by sysrq, the following bug will be occur.
BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:90
in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 10052, name: rc.shutdown
CPU: 3 PID: 10052 Comm: rc.shutdown Tainted: G W O 5.10.0 #1
Call trace:
dump_backtrace+0x0/0x1c8
show_stack+0x18/0x28
dump_stack+0xd0/0x110
___might_sleep+0x14c/0x160
__might_sleep+0x74/0x88
down_interruptible+0x40/0x118
virt_efi_reset_system+0x3c/0xd0
efi_reboot+0xd4/0x11c
machine_restart+0x60/0x9c
emergency_restart+0x1c/0x2c
sysrq_handle_reboot+0x1c/0x2c
__handle_sysrq+0xd0/0x194
write_sysrq_trigger+0xbc/0xe4
proc_reg_write+0xd4/0xf0
vfs_write+0xa8/0x148
ksys_write+0x6c/0xd8
__arm64_sys_write+0x18/0x28
el0_svc_common.constprop.3+0xe4/0x16c
do_el0_svc+0x1c/0x2c
el0_svc+0x20/0x30
el0_sync_handler+0x80/0x17c
el0_sync+0x158/0x180
The reason for this problem is that irq has been disabled in
machine_restart() and then it calls down_interruptible() in
virt_efi_reset_system(), which would occur sleep in irq context,
it is dangerous! Commit
99409b935c9a("locking/semaphore: Add
might_sleep() to down_*() family") add might_sleep() in
down_interruptible(), so the bug info is here. down_trylock()
can solve this problem, cause there is no might_sleep.
--------
Cc: <stable@vger.kernel.org>
Signed-off-by: Zhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ard Biesheuvel [Wed, 1 Sep 2021 06:33:19 +0000 (08:33 +0200)]
efi/cper: use stack buffer for error record decoding
commit
b3a72ca80351917cc23f9e24c35f3c3979d3c121 upstream.
Joe reports that using a statically allocated buffer for converting CPER
error records into human readable text is probably a bad idea. Even
though we are not aware of any actual issues, a stack buffer is clearly
a better choice here anyway, so let's move the buffer into the stack
frames of the two functions that refer to it.
Cc: <stable@vger.kernel.org>
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Mon, 27 Sep 2021 12:13:57 +0000 (14:13 +0200)]
cb710: avoid NULL pointer subtraction
commit
42641042c10c757fe10cc09088cf3f436cec5007 upstream.
clang-14 complains about an unusual way of converting a pointer to
an integer:
drivers/misc/cb710/sgbuf2.c:50:15: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction]
return ((ptr - NULL) & 3) != 0;
Replace this with a normal cast to uintptr_t.
Fixes:
5f5bac8272be ("mmc: Driver for CB710/720 memory card reader (MMC part)")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210927121408.939246-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nikolay Martynov [Fri, 8 Oct 2021 09:25:47 +0000 (12:25 +0300)]
xhci: Enable trust tx length quirk for Fresco FL11 USB controller
commit
ea0f69d8211963c4b2cc1998b86779a500adb502 upstream.
Tested on SD5200T TB3 dock which has Fresco Logic FL1100 USB 3.0 Host
Controller.
Before this patch streaming video from USB cam made mouse and keyboard
connected to the same USB bus unusable. Also video was jerky.
With this patch streaming video doesn't have any effect on other
periferals and video is smooth.
Cc: stable@vger.kernel.org
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211008092547.3996295-6-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pavankumar Kondeti [Fri, 8 Oct 2021 09:25:46 +0000 (12:25 +0300)]
xhci: Fix command ring pointer corruption while aborting a command
commit
ff0e50d3564f33b7f4b35cadeabd951d66cfc570 upstream.
The command ring pointer is located at [6:63] bits of the command
ring control register (CRCR). All the control bits like command stop,
abort are located at [0:3] bits. While aborting a command, we read the
CRCR and set the abort bit and write to the CRCR. The read will always
give command ring pointer as all zeros. So we essentially write only
the control bits. Since we split the 64 bit write into two 32 bit writes,
there is a possibility of xHC command ring stopped before the upper
dword (all zeros) is written. If that happens, xHC updates the upper
dword of its internal command ring pointer with all zeros. Next time,
when the command ring is restarted, we see xHC memory access failures.
Fix this issue by only writing to the lower dword of CRCR where all
control bits are located.
Cc: stable@vger.kernel.org
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211008092547.3996295-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Bell [Fri, 8 Oct 2021 09:25:43 +0000 (12:25 +0300)]
xhci: guard accesses to ep_state in xhci_endpoint_reset()
commit
a01ba2a3378be85538e0183ae5367c1bc1d5aaf3 upstream.
See https://github.com/raspberrypi/linux/issues/3981
Two read-modify-write cycles on ep->ep_state are not guarded by
xhci->lock. Fix these.
Fixes:
f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset")
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211008092547.3996295-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 8 Oct 2021 09:25:45 +0000 (12:25 +0300)]
USB: xhci: dbc: fix tty registration race
commit
880de403777376e50bdf60def359fa50a722006f upstream.
Make sure to allocate resources before registering the tty device to
avoid having a racing open() and write() fail to enable rx or
dereference a NULL pointer when accessing the uninitialised fifo.
Fixes:
dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
Cc: stable@vger.kernel.org # 4.16
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211008092547.3996295-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>