IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
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>
Richard Gong is no longer at Intel, so update the MAINTAINER's entry for
the Stratix10 firmware drivers.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This contains quite a few device-specific fixes for usual HD- and
USB-audio in addition to a couple of ALSA core fixes (a UAF fix in
sequencer and a fix for a misplaced PCM 32bit compat ioctl).
Nothing really stands out.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmFoIj8OHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9IrBAAvYoJvsUsZUwUSw0istIVaNiVBE4u91IBsNe/
W3WHVYAO4rLgZFfnasZ0kaPQ/BEwNhuk/vrJueZJuKU/kF8nCrYNX+nr8SB902Ws
xdoZhROtIIh9B8NO0D6yeYlIByJ1dldlqn/4+ujzPnY7ISWGbJ2KIcusnSsCte+e
2qMhT2paxjuSUFPZiPbXDGKPYcWYwn0lf7XjLe5lVlTAmHW2wX2PDs0wppkIXcXZ
C9Tkbz4SfCWh+HKrAd1AbYpP+OAF/9EetXGdBFDaZHex/AxNNi02588Fc84/Ofno
XxlO5/Z9O5VYVflsEGnF6B18D+Xsj94TC5h598OVDPgi5z2UgpQZusWTLGBfn4O4
LUbM+NYbLeaWLAwKi6wdAWq1b4eKx5m9Uxysb40bumR38rfauCTedolB+8OpsaRs
/kRjZmthgNXWDfjgAT6bPubwzpRdqscxA/SfY8lCObXVqgSdrmeFPCCqXYekKx4L
Xazx0tyMxbpIAoSo+rWzErLntpQ4Rijtq4t3mLcfl1U7m3tkq/D2zBHrrxENJSuC
TMko6F3maUSkGcGv+MMA2YO+J8juVEZ/vQFVT4C6PbOt1UnlpDQ8BHDxor+bVRpf
txK0o+5WOkPySRik1IkLRhScF0QIYbZnrdG/zSbSkcsDmxNbt3F1Jb5EGLheBpA4
yvzncTk=
=sxyi
-----END PGP SIGNATURE-----
Merge tag 'sound-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"This contains quite a few device-specific fixes for usual HD- and
USB-audio in addition to a couple of ALSA core fixes (a UAF fix in
sequencer and a fix for a misplaced PCM 32bit compat ioctl).
Nothing really stands out"
* tag 'sound-5.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: usb-audio: Add quirk for VF0770
ALSA: hda: avoid write to STATESTS if controller is in reset
ALSA: hda/realtek: Fix the mic type detection issue for ASUS G551JW
ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctl
ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2
ALSA: hda: intel: Allow repeatedly probing on codec configuration errors
ALSA: hda/realtek: Add quirk for TongFang PHxTxX1
ALSA: hda/realtek - ALC236 headset MIC recording issue
ALSA: usb-audio: Enable rate validation for Scarlett devices
ALSA: hda/realtek: Add quirk for Clevo X170KM-G
ALSA: hda/realtek: Complete partial device name to avoid ambiguity
ALSA: hda - Enable headphone mic on Dell Latitude laptops with ALC3254
ALSA: seq: Fix a potential UAF by wrong private_free call order
ALSA: hda/realtek: Enable 4-speaker output for Dell Precision 5560 laptop
ALSA: usb-audio: Fix a missing error check in scarlett gen2 mixer
io_mutex is taken by spi_setup() and spi-mux's .setup() callback calls
spi_setup() which results in a nested lock of io_mutex.
add_lock is taken by spi_add_device(). The device_add() call in there
can result in calling spi-mux's .probe() callback which registers its
own spi controller which in turn results in spi_add_device() being
called again.
To fix this initialize the controller's locks already in
spi_alloc_controller() to give spi_mux_probe() a chance to set the
lockdep subclass.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211013133710.2679703-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently we have a global spi_add_lock which we take when adding new
devices so that we can check that we're not trying to reuse a chip
select that's already controlled. This means that if the SPI device is
itself a SPI controller and triggers the instantiation of further SPI
devices we trigger a deadlock as we try to register and instantiate
those devices while in the process of doing so for the parent controller
and hence already holding the global spi_add_lock. Since we only care
about concurrency within a single SPI bus move the lock to be per
controller, avoiding the deadlock.
This can be easily triggered in the case of spi-mux.
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
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
Decrease reference count of chardevice during char device deletion in
order to fix a memory leak. Add a release callabck for the device
associated chardev and move ida_simple_remove into the release function.
Fixes: 2637baed7801 ("nvme: introduce generic per-namespace chardev")
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Suggested-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Adam Manzanares <a.manzanares@samsung.com>
Reviewed-by: Javier González <javier@javigon.com>
Tested-by: Yi Zhang <yi.zhang@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
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>
'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>
'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>
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>
The removal of eprobes was broken and missed in testing. Add various ways
to remove eprobes that are considered acceptable to the testing process to
catch when/if they break again.
Link: https://lkml.kernel.org/r/20211013205533.836644549@goodmis.org
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
When an event probe is to be removed via the API that created it via the
dynamic events, an -ENOENT error is returned.
This is because the removal of the event probe does not expect to see the
event system and name that the event probe is attached to, even though
that's part of the API to create it. As the removal of probes is to use
the same API as they are created.
In fact, the removal is not consistent with the kprobes and uprobes
removal. Fix that by allowing various ways to remove the eprobe.
The eprobe is created with:
e:[GROUP/]NAME SYSTEM/EVENT [OPTIONS]
Have it get removed by echoing in the following into dynamic_events:
# Remove all eprobes with NAME
echo '-:NAME' >> dynamic_events
# Remove a specific eprobe
echo '-:GROUP/NAME' >> dynamic_events
echo '-:GROUP/NAME SYSTEM/EVENT' >> dynamic_events
echo '-:NAME SYSTEM/EVENT' >> dynamic_events
echo '-:GROUP/NAME SYSTEM/EVENT OPTIONS' >> dynamic_events
echo '-:NAME SYSTEM/EVENT OPTIONS' >> dynamic_events
Link: https://lkml.kernel.org/r/20211012081925.0e19cc4f@gandalf.local.home
Link: https://lkml.kernel.org/r/20211013205533.630722129@goodmis.org
Suggested-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Fixes: 7491e2c442781 ("tracing: Add a probe that attaches to trace events")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
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>
My previous bugfix ended up making things worse for the QCOM IOMMU
driver when it forgot to add the Kconfig symbol that is getting used to
control the compilation of the SMMU implementation specific code
for Qualcomm.
Fixes: 424953cf3c66 ("qcom_scm: hide Kconfig symbol")
Reported-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reported-by: John Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/lkml/20211010023350.978638-1-dmitry.baryshkov@linaro.org/
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Unregisters OP-TEE client devices (UUIDs of some known Trusted
Applications) from the TEE bus when the OP-TEE driver is unloaded.
-----BEGIN PGP SIGNATURE-----
iQJOBAABCgA4FiEEFV+gSSXZJY9ZyuB5LinzTIcAHJcFAmFmzW4aHGplbnMud2lr
bGFuZGVyQGxpbmFyby5vcmcACgkQLinzTIcAHJcyrQ//Utl1/sIMNrGT2wk2fU5A
aN7vrWzUBv+VH5zZ1yTqNGEvuu/IJJ+9+wAz6DNVB/vaDCak/VX9toNJX+SwsanN
2qqrAeQPDnHJEaFBul/ogz2RN9pU66NwIeYVdYmkyE0rBtIjgbDOG7f2uPEpKVVj
dTfX69QFohsD/Amnz6G4+vr8olEtrhDcODgcq2FnXhGiTl1PVY397k+MpNzUopvO
0+hWOzPGs14Y0axornZcT/Y2mYp7fGMna+KtLauBHft44xDNp5Qgd5jOZjFfpUxh
wJXaBsYti1OgYdS8gPvpC20bpC22iqYd3R+WapRvT5PxEsx2GLaWtoG+gBGJ4SDd
T2EOf/XHcHsaY/iYqG2ICwbAjDLgvGgoqXa4A6jIzR6z3/WFtrjCN1M0W3TXQSXC
6IIYpsYaVKFMK4wcmhNTXylltegOtnCMfvMkI8kXj27PVkKgQypk/DrAHO5qP/fZ
UbOWFFq8fziWHO+K6txTqMRO7DyuJlleRDYiZ3Y6ED+M8eQ4Ejl2i9KqboV+ljKC
/lHOmbPEB0EGzWxDvPT+XZu+19/NFPmj6ILdNbsEMNUxtYKZj6HU0s8wEOx0M/yw
5rZY4D2g40QKEl6QzI9s2SN623+Mhl5tgi0qcMOo7QHLrJatXpgptPgTtwgV1VAZ
numJsMBTCEfDxhNiyLuTm2s=
=WXLA
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmFnMLYACgkQmmx57+YA
GNkKLg/9H3iRbiksUw9WyAMJz8C+rNcB8ftucWPwFIx3zBKumc4t7iLKbUUQHyzF
1fvXUKO/PxfzdJ50uwFHHz2SxZwAKQQU0IhwchPM1e5ubFWZvYC9ycvzWV8orUG4
c1w4FlP8jXrzTx5cNvpr2E3GMhTjjIgmbMXEww7bNH3HeQ7xN4q8o7olYRRsYHpM
DJZWAFb1XDxWwlftVglFUDyWrJlLxa1S2OQWVR8KLY37Ff1L5vyEFiXnjDuwIzeG
AuJGl9RlxW3UT6vTkhb0g9hpqKPtn0xc85Dd4hrg52OSvIzpuN99mG2f3AqPzgbi
T5EtM0tQ7E7F8UdPqtVP6ib9nNAutBgadje34vHLurOZ9Td1FllInFUTioyyPsop
B/sAAfpQRt84R/NEms3sm6sHK2vsf8RY1FwwmNRncrkxZmHV/Glt6bAXxs3Z1Wsx
vlXOYIAqF4sTU4wQCSJe6dsiqn1Bhgl/uUYurwufPf6dcI646+pGlBlMxTTYEmNq
Hbzcvd/QaBkRiHD2sguctXotSPpAGUX/zEua7koOl5kMQEX+VRQdGqJMhgW5N/P1
xMVeKDPvbiKUK41YFeO4y1fEaSGON/JSvZRmr4zRCFwFH1RIobH/z3zo90VS9z5y
CPg12UIqdDf5Vy/Z8qW1AoovJIGF71lRVr4wCESGNwoQzXPtzLI=
=HZ3a
-----END PGP SIGNATURE-----
Merge tag 'optee-fix2-for-v5.15' of git://git.linaro.org/people/jens.wiklander/linux-tee into arm/fixes
Fix missing devices unregister during optee_remove
Unregisters OP-TEE client devices (UUIDs of some known Trusted
Applications) from the TEE bus when the OP-TEE driver is unloaded.
* tag 'optee-fix2-for-v5.15' of git://git.linaro.org/people/jens.wiklander/linux-tee:
tee: optee: Fix missing devices unregister during optee_remove
Link: https://lore.kernel.org/r/20211013122854.GA1542549@jade
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
5.15, please pull the following:
- Stefan fixes the VEC (video encoder) bus address for 2711, fixes the
MDIO bus controller #address-cells/#size-cells inversion and the SDIO
regulator voltage ranges
- Nicolas fixes DTC warnings for the PCIe host bridge and its child
USB device
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmFmAAgACgkQh9CWnEQH
BwR2FhAAr4S1yCqKUrTXV0yM1M2teZgtNZE/19fWkeKd++9o/RrG+dYdoos/wPTm
M45jrsQt5spt20Qw1UBet+cROL1DfG34eoCX5jC7HzdN5YEZ0HYV8tgWDI0woVQo
5jfD5ELbxLeQvAHXGluPYZpT//DKP67JS66HmNO4E3NEEB1JJXBw3nyCn+JQlRa/
MUBJGkfuu5cYJkgRQLCtfXM/rY7SrbHWvrPGTDrEPzKtlKNvNna5126qgEYBqckg
chicQR/CXi7c3tN+qBKFyMQGK2sdkAeOROnpHMXehevp+SVRnuk1IKemGAZF3EFb
C0fTM/rS8AgzjQpAgmhQkuBRjCNcnvJOKWOQTgete8JaBwqhfPzBq2ZJJW1eFKFp
A9vtynHPrOWDn507lrTS7MV9lgr6K99OG76uiS9gMArJ+jgFm4XUP9kT36o+hpPx
3/YUr1rXWx8V9oT4pjVHYTiNICmlnpwZCldkP6sMpo2UWIUS1amKK70ly4wBTn5A
hTuvkmM09V5aQomZK8yZljaLedaGfek4k5Lxw6wkPwM+NblYr4puACcGKgnPwUIw
iFU9v10NfSMHPJgEWMHZvFOGCN+GM+DI0gZA9VyOslmOuNdj/+A9jmkjJZ8YcBw5
bdqo1glj/BZI7+kE17FAMz+mBZpzsDFVHLHiD8bOteVh3/tzsHA=
=EOTX
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmFnLAsACgkQmmx57+YA
GNnnPw/9GC0xjSAGyNShAg7t68zibHmth0sfeih96WjzrDAIYgrBm0RBgcV2bn83
+I4jgpSpVIMHs1hSFMYIpm1UP65XQrS5kdKrWHt4NgnMTmYJByv8Ydthh0fTZenW
/zFe6aQqBLNOpfYPcFHeS090WuUkteniAU8Ba7DbdZVldRsgGZMTpCpQApkwQ/0c
YY+TY1j6kTW+JCTx/Z1CkTVcjNgEtKc7zTfpk9XbmU5FQkixL0Ife4580JV5PJvW
u7QraAeZW96stGKWOEb5UK+nKjUQyc79fBj5uo9B4A2CmEhc+Ur90GQ1BTepVgPB
mvfj97Ipuz57h5/fVTrnUJjfNcpy0aFbxzVny29LB0ZKk3UHtnH1ps4o5fGVVW41
zZuu9BVAKiFNi99Foqv+UzLAUP5u4yrq/53X0qeJQeu+5j+R9WAQNkWTrOvzu72t
x1xBBqXKHAvFIp+/4oPNyLNcUHJx8jjOJawOsX7h2vkoA3A1b2wPMA0WuuCJSArg
jKhu7Eo8tAbDuszyIpB/hNm7OLQuJPTZN/YR5JCFzu5LVYFiRe8XW33+Ct/Y792Y
PifWxhpzUlGTdJE+xCDgjT9M96UaGHbXrd6j2FIImAj+JP/PW9x9v+mb0DCk/QCI
b6nDzRfpNb5J3zTyTsWTrl5FY7JVEVHeWF1YhmImnUXeiVt3tqM=
=SPDH
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-5.15/devicetree' of https://github.com/Broadcom/stblinux into arm/fixes
This pull request contains Broadcom ARM-based SoCs Device Tree fixes for
5.15, please pull the following:
- Stefan fixes the VEC (video encoder) bus address for 2711, fixes the
MDIO bus controller #address-cells/#size-cells inversion and the SDIO
regulator voltage ranges
- Nicolas fixes DTC warnings for the PCIe host bridge and its child
USB device
* tag 'arm-soc/for-5.15/devicetree' of https://github.com/Broadcom/stblinux:
ARM: dts: bcm2711-rpi-4-b: Fix usb's unit address
ARM: dts: bcm2711-rpi-4-b: Fix pcie0's unit address formatting
ARM: dts: bcm2711-rpi-4-b: fix sd_io_1v8_reg regulator states
ARM: dts: bcm2711: fix MDIO #address- and #size-cells
ARM: dts: bcm283x: Fix VEC address for BCM2711
Link: https://lore.kernel.org/r/20211012213841.1872021-1-f.fainelli@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It looks that the offset 0x7d060 is a copy & paste from above
hlos1_vote_turing_mmu_tbu1_gdsc. Correct it to 0x7d07c as per
downstream kernel.
Fixes: cbe63bfdc54f ("clk: qcom: Add Global Clock controller (GCC) driver for SM6115")
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Link: https://lore.kernel.org/r/20210919022308.24046-1-shawn.guo@linaro.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
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>
Replace camel case function parameter name byRate (hungarian notation)
with snake case equivalent, in card.c
Signed-off-by: Tommaso Merciai <tomm.merciai@gmail.com>
Link: https://lore.kernel.org/r/20211007161535.7563-1-tomm.merciai@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
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>
Fix a VDUSE documentation build warning:
Documentation/userspace-api/vduse.rst:21: WARNING: Title underline too short.
Fixes: 7bc7f61897b6 ("Documentation: Add documentation for VDUSE")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Xie Yongji <xieyongji@bytedance.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Link: https://lore.kernel.org/r/20211006202904.30241-1-rdunlap@infradead.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Xie Yongji <xieyongji@bytedance.com>
Acked-by: Jason Wang <jasowang@redhat.com>
It turns out that access to config space before completing the feature
negotiation is broken for big endian guests at least with QEMU hosts up
to 6.1 inclusive. This affects any device that accesses config space in
the validate callback: at the moment that is virtio-net with
VIRTIO_NET_F_MTU but since 82e89ea077b9 ("virtio-blk: Add validation for
block size in config space") that also started affecting virtio-blk with
VIRTIO_BLK_F_BLK_SIZE. Further, unlike VIRTIO_NET_F_MTU which is off by
default on QEMU, VIRTIO_BLK_F_BLK_SIZE is on by default, which resulted
in lots of people not being able to boot VMs on BE.
The spec is very clear that what we are doing is legal so QEMU needs to
be fixed, but given it's been broken for so many years and no one
noticed, we need to give QEMU a bit more time before applying this.
Further, this patch is incomplete (does not check blk size is a power
of two) and it duplicates the logic from nbd.
Revert for now, and we'll reapply a cleaner logic in the next release.
Cc: stable@vger.kernel.org
Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config space")
Cc: Xie Yongji <xieyongji@bytedance.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Currently we unset vq irq after freeing irq and that will result in
error messages:
pi_update_irte: failed to update PI IRTE
irq bypass consumer (token 000000005a07a12b) unregistration fails: -22
This patch solves this.
Signed-off-by: Wu Zongyong <wuzongyong@linux.alibaba.com>
Link: https://lore.kernel.org/r/02637d38dcf4e4b836c5b3a65055fe92bf812b3b.1631687872.git.wuzongyong@linux.alibaba.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
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>
fbtft_remove_common() is only called with a non-NULL fb_info. (All
callers are in remove callbacks and the matching probe callbacks set
driver data accordingly.) So fbtft_remove_common() always returns zero.
Make it return void instead which makes it easier to see in the callers
that there is no error to handle.
Also the return value of platform and spi remove callbacks is ignored
anyway and not freeing resources in .remove() is a bad idea.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20211012153945.2651412-20-u.kleine-koenig@pengutronix.de
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use zeroing allocator rather than allocator followed by memset with 0.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20211012024624.GA1062447@embeddedor
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As format check raised by scripts/checkpatch.pl, comment in the rtw_ap.c
looks misspelled by accident. Help fix it.
The original error is as below shows:
CHECK: 'followign' may be misspelled - perhaps 'following'?
+Set to 0 (HT pure) under the followign conditions
Signed-off-by: Siou-Jhih, Guo <hallblazzar@gmail.com>
Link: https://lore.kernel.org/r/20211011214803.GA239300@hallblazzar-Precision-5510
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 723de0f9171e ("staging: most: remove device from interface
structure") moved registration of driver-provided struct device to
the most subsystem. This updated dim2 driver as well.
However, struct device passed to register_device() becomes refcounted,
and must not be explicitly deallocated, but must provide release method
instead. Which is incompatible with managing it via devres.
This patch makes the device structure allocated without devres, adds
device release method, and moves device destruction there.
Fixes: 723de0f9171e ("staging: most: remove device from interface structure")
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Link: https://lore.kernel.org/r/20211005143448.8660-2-nikita.yoush@cogentembedded.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 723de0f9171e ("staging: most: remove device from interface
structure") moved registration of driver-provided struct device to
the most subsystem.
Dim2 used to register the same struct device to provide a custom device
attribute. This causes double-registration of the same struct device.
Fix that by moving the custom attribute to driver's dev_groups.
This moves attribute to the platform_device object, which is a better
location for platform-specific attributes anyway.
Fixes: 723de0f9171e ("staging: most: remove device from interface structure")
Acked-by: Christian Gromm <christian.gromm@microchip.com>
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Link: https://lore.kernel.org/r/20211011061117.21435-1-nikita.yoush@cogentembedded.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the SupportPlatform entry of struct odm_dm_struct and any code
that depends on SupportPlatform != ODM_CE.
Merge functions in places where there was a "top-level function" that
would select a "sub-function" based on SupportPlatform.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20211011201159.10252-9-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
odm BoardType is never set, so it's always 0 (ODM_BOARD_NORMAL).
Remove dead code and the BoardType itself.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20211011201159.10252-8-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SupportICType in struct odm_dm_struct is always ODM_RTL8188E. Remove the
component and code that is executed only for other types.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20211011201159.10252-6-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that we don't call dm_CheckStatistics any more, we don't need
fw_cur_in_ps and fw_ps_awake.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20211011201159.10252-3-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ext lna info is never set. Remove it and fix up the one place
where it's read.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Link: https://lore.kernel.org/r/20211010175204.24029-11-martin@kaiser.cx
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
