- 13 Oct, 2023 2 commits
-
-
Robert Hancock authored
The driver was previously using offset and scale values for the temperature sensor readings which were only valid for 7-series devices. Add per-device-type values for offset and scale and set them appropriately for each device type. Note that the values used for the UltraScale family are for UltraScale+ (i.e. the SYSMONE4 primitive) using the internal reference, as that seems to be the most common configuration and the device tree values Xilinx's device tree generator produces don't seem to give us anything to tell us which configuration is used. However, the differences within the UltraScale family seem fairly minor and it's closer than using the 7-series values instead in any case. Fixes: c2b7720a ("iio: xilinx-xadc: Add basic support for Ultrascale System Monitor") Signed-off-by:
Robert Hancock <robert.hancock@calian.com> Acked-by:
O'Griofa, Conall <conall.ogriofa@amd.com> Tested-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Robert Hancock authored
In the probe function, the driver was reading out the thresholds already set in the core, which can be configured by the user in the Vivado tools when the FPGA image is built. However, it later clobbered those values with zero or maximum values. In particular, the overtemperature shutdown threshold register was overwritten with the max value, which effectively prevents the FPGA from shutting down when the desired threshold was eached, potentially risking hardware damage in that case. Remove this code to leave the preconfigured default threshold values intact. The code was also disabling all alarms regardless of what enable state they were left in by the FPGA image, including the overtemperature shutdown feature. Leave these bits in their original state so they are not unconditionally disabled. Fixes: bdc8cda1 ("iio:adc: Add Xilinx XADC driver") Signed-off-by:
-
- 10 Oct, 2023 1 commit
-
-
Krzysztof Kozlowski authored
The Documentation/devicetree/bindings/gpio/gpio-consumer-common.yaml schema does not enforce number of reset GPIOs, thus each device binding must do it. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231005083650.92222-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
- 06 Oct, 2023 1 commit
-
-
Greg Kroah-Hartman authored
Merge tag 'iio-fixes-for-6.6a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-linus Jonathan writes: 1st set of IIO fixes for 6.6 Note last minute rebase to fix up a stale Fixes tag. All patches have been in Linux-next for some time. adi,ad3552r - Fix swapped device IDs for the two parts that are supported. adi,ad7192 - Use the right reference voltage source. adi,ad7292 - Fix additionalProperties to be false, not true. adi,ad74413 - Add missing Kconfig depends on IIO_BUFFER and IIO_TRIGGERED_BUFFER adi,admv1013 - Fix up some corner cases for the mixer vgate register value. bosch,bmp280 - Fix a null pointer dereference caused by a wrong boolean operator. bosch,bno055 - Add missing Kconfig depends on IIO_BUFFER and IIO_TRIGGERED_BUFFER freescale,imx8eqxp - Fix some wrong register addresses. google,cros_ec - Fix a use after free if very badly timed buffer disable occurs by holding the device in buffered mode. infineon,dps310 - Expand a timeout so we don't hit it on working parts. meas,m5611 - Allow for a ROM CRC of 0 as it is a valid value and there are devices out there where it happens. murata,irsd200 - Make sure the buffer used to build up the scan is large enough to take the timestamp. rohm,bu27010 binding - Add a missing required vdd-supply vishay,vcnl4000 - Don't power down chip in wrong place. * tag 'iio-fixes-for-6.6a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio: pressure: ms5611: ms5611_prom_is_valid false negative bug dt-bindings: iio: adc: adi,ad7292: Fix additionalProperties on channel nodes iio: adc: ad7192: Correct reference voltage iio: light: vcnl4000: Don't power on/off chip in config iio: addac: Kconfig: update ad74413r selections iio: pressure: dps310: Adjust Timeout Settings iio: imu: bno055: Fix missing Kconfig dependencies iio: adc: imx8qxp: Fix address for command buffer registers iio: cros_ec: fix an use-after-free in cros_ec_sensors_push_data() iio: irsd200: fix -Warray-bounds bug in irsd200_trigger_handler dt-bindings: iio: rohm,bu27010: add missing vdd-supply to example iio: admv1013: add mixer_vgate corner cases iio: pressure: bmp280: Fix NULL pointer exception iio: dac: ad3552r: Correct device IDs
-
- 05 Oct, 2023 15 commits
-
-
Alexander Zangerl authored
The ms5611 driver falsely rejects lots of MS5607-02BA03-50 chips with "PROM integrity check failed" because it doesn't accept a prom crc value of zero as legitimate. According to the datasheet for this chip (and the manufacturer's application note about the PROM CRC), none of the possible values for the CRC are excluded - but the current code in ms5611_prom_is_valid() ends with return crc_orig != 0x0000 && crc == crc_orig Discussed with the driver author (Tomasz Duszynski) and he indicated that at that time (2015) he was dealing with some faulty chip samples which returned blank data under some circumstances and/or followed example code which indicated CRC zero being bad. As far as I can tell this exception should not be applied anymore; We've got a few hundred custom boards here with this chip where large numbers of the prom have a legitimate CRC value 0, and do work fine, but which the current driver code wrongly rejects. Signed-off-by:
Alexander Zangerl <az@breathe-safe.com> Fixes: c0644160 ("iio: pressure: add support for MS5611 pressure and temperature sensor") Link: https://lore.kernel.org/r/2535-1695168070.831792@Ze3y.dhYT.s3fx Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Rob Herring authored
"additionalProperties: true" is only for incomplete schemas such as bus child nodes in a bus's schema. That doesn't apply to the "channel" nodes in the adi,ad7292 binding, so fix additionalProperties to be false. Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
Marcelo Schmitt <marcelo.schmitt1@gmail.com> Link: https://lore.kernel.org/r/20230926164357.100325-1-robh@kernel.orgSigned-off-by:
-
Alisa-Dariana Roman authored
The avdd and the reference voltage are two different sources but the reference voltage was assigned according to the avdd supply. Add vref regulator structure and set the reference voltage according to the vref supply from the devicetree. In case vref supply is missing, reference voltage is set according to the avdd supply for compatibility with old devicetrees. Fixes: b581f748 ("staging: iio: adc: ad7192: move out of staging") Signed-off-by:
Alisa-Dariana Roman <alisa.roman@analog.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230924152149.41884-1-alisadariana@gmail.comSigned-off-by:
-
Mårten Lindahl authored
After enabling/disabling interrupts on the vcnl4040 chip the als and/or ps sensor is powered on or off depending on the interrupt enable bits. This is made as a last step in write_event_config. But there is no reason to do this as the runtime PM handles the power state of the sensors. Interfering with this may impact sensor readings. Consider the following: 1. Userspace makes sensor data reading which triggers RPM resume (sensor powered on) and a RPM suspend timeout. The timeout is 2000ms before RPM suspend powers the sensor off if no new reading is made within the timeout period. 2. Userspace disables interrupts => powers sensor off 3. Userspace reads sensor data = 0 because sensor is off and the suspend timeout has not passed. For each new reading made within the timeout period the timeout is renewed with 2000ms and RPM will not make a new resume (device was not suspended). So the sensor will not be powered on. 4. No further userspace reading for 2000ms ends RPM suspend timeout and triggers suspend (powers off already powered off sensor). Powering sensor off in (2) makes all consecutive readings made within 2000ms to the previous reading (3) return invalid data. Skip setting power state when writing new event config. Fixes: 54667612 ("iio: light: vcnl4000: Add interrupt support for vcnl4040") Fixes: bc292aaf ("iio: light: vcnl4000: add illuminance irq vcnl4040/4200") Signed-off-by:Mårten Lindahl <marten.lindahl@axis.com> Link: https://lore.kernel.org/r/20230907-vcnl4000-pm-fix-v2-1-298e01f54db4@axis.com Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Antoniu Miclaus authored
Building ad74413r without selecting IIO_BUFFER and IIO_TRIGGERED_BUFFER generates error with respect to the iio trigger functions that are used within the driver. Update the Kconfig accordingly. Fixes: fea251b6 ("iio: addac: add AD74413R driver") Signed-off-by:
Antoniu Miclaus <antoniu.miclaus@analog.com> Link: https://lore.kernel.org/r/20230912085421.51102-1-antoniu.miclaus@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Lakshmi Yadlapati authored
The DPS310 sensor chip has been encountering intermittent errors while reading the sensor device across various system designs. This issue causes the chip to become "stuck," preventing the indication of "ready" status for pressure and temperature measurements in the MEAS_CFG register. To address this issue, this commit fixes the timeout settings to improve sensor stability: - After sending a reset command to the chip, the timeout has been extended from 2.5 ms to 15 ms, aligning with the DPS310 specification. - The read timeout value of the MEAS_CFG register has been adjusted from 20ms to 30ms to match the specification. Signed-off-by:
Lakshmi Yadlapati <lakshmiy@us.ibm.com> Fixes: 7b4ab4ab ("iio: pressure: dps310: Reset chip after timeout") Link: https://lore.kernel.org/r/20230829180222.3431926-2-lakshmiy@us.ibm.com Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Jonathan Cameron authored
This driver uses IIO triggered buffers so it needs to select them in Kconfig. on riscv-32bit: /opt/crosstool/gcc-13.2.0-nolibc/riscv32-linux/bin/riscv32-linux-ld: drivers/iio/imu/bno055/bno055.o: in function `.L367': bno055.c:(.text+0x2c96): undefined reference to `devm_iio_triggered_buffer_setup_ext' Reported-by:
Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/linux-next/40566b4b-3950-81fe-ff14-871d8c447627@infradead.org/ Fixes: 4aefe1c2 ("iio: imu: add Bosch Sensortec BNO055 core driver") Cc: Andrea Merello <andrea.merello@iit.it> Acked-by:
-
Philipp Rossak authored
The ADC Command Buffer Register high and low are currently pointing to the wrong address and makes it impossible to perform correct ADC measurements over all channels. According to the datasheet of the imx8qxp the ADC_CMDL register starts at address 0x100 and the ADC_CMDH register starts at address 0x104. This bug seems to be in the kernel since the introduction of this driver. This can be observed by checking all raw voltages of the adc and they are all nearly identical: cat /sys/bus/iio/devices/iio\:device0/in_voltage*_raw 3498 3494 3491 3491 3489 3490 3490 3490 Fixes: 1e23dcaa ("iio: imx8qxp-adc: Add driver support for NXP IMX8QXP ADC") Signed-off-by:
Philipp Rossak <embed3d@gmail.com> Acked-by:
Haibo Chen <haibo.chen@nxp.com> Link: https://lore.kernel.org/r/20230904220204.23841-1-embed3d@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Tzung-Bi Shih authored
cros_ec_sensors_push_data() reads `indio_dev->active_scan_mask` and calls iio_push_to_buffers_with_timestamp() without making sure the `indio_dev` stays in buffer mode. There is a race if `indio_dev` exits buffer mode right before cros_ec_sensors_push_data() accesses them. An use-after-free on `indio_dev->active_scan_mask` was observed. The call trace: [...] _find_next_bit cros_ec_sensors_push_data cros_ec_sensorhub_event blocking_notifier_call_chain cros_ec_irq_thread It was caused by a race condition: one thread just freed `active_scan_mask` at [1]; while another thread tried to access the memory at [2]. Fix it by calling iio_device_claim_buffer_mode() to ensure the `indio_dev` can't exit buffer mode during cros_ec_sensors_push_data(). [1]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/industrialio-buffer.c#L1189 [2]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c#L198 Cc: stable@vger.kernel.org Fixes: aa984f1b ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO") Signed-off-by:
Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230829030622.1571852-1-tzungbi@kernel.orgSigned-off-by:
-
GONG, Ruiqi authored
When compiling with gcc 13 with -Warray-bounds enabled: In file included from drivers/iio/proximity/irsd200.c:15: In function ‘iio_push_to_buffers_with_timestamp’, inlined from ‘irsd200_trigger_handler’ at drivers/iio/proximity/irsd200.c:770:2: ./include/linux/iio/buffer.h:42:46: error: array subscript ‘int64_t {aka long long int}[0]’ is partly outside array bounds of ‘s16[1]’ {aka ‘short int[1]’} [-Werror=array-bounds=] 42 | ((int64_t *)data)[ts_offset] = timestamp; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~ drivers/iio/proximity/irsd200.c: In function ‘irsd200_trigger_handler’: drivers/iio/proximity/irsd200.c:763:13: note: object ‘buf’ of size 2 763 | s16 buf = 0; | ^~~ The problem seems to be that irsd200_trigger_handler() is taking a s16 variable as an int64_t buffer. As Jonathan suggested [1], fix it by extending the buffer to a two-element array of s64. Link: https://github.com/KSPP/linux/issues/331 Link: https://lore.kernel.org/lkml/20230809181329.46c00a5d@jic23-huawei/ [1] Fixes: 3db3562b ("iio: Add driver for Murata IRS-D200") Signed-off-by:GONG, Ruiqi <gongruiqi1@huawei.com> Acked-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Waqar Hameed <waqar.hameed@axis.com> Tested-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230810035910.1334706-1-gongruiqi@huaweicloud.comSigned-off-by:
-
Krzysztof Kozlowski authored
Bindings require vdd-supply but the example DTS was missing one. This fixes dt_binding_check error: Documentation/devicetree/bindings/iio/light/rohm,bu27010.example.dtb: light-sensor@38: 'vdd-supply' is a required property Fixes: ce2a8c16 ("dt-bindings: iio: ROHM BU27010 RGBC + flickering sensor") Signed-off-by:
Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/20230808063223.80431-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Carlos Llamas authored
A transaction complete work is allocated and queued for each transaction. Under certain conditions the work->type might be marked as BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT to notify userspace about potential spamming threads or as BINDER_WORK_TRANSACTION_PENDING when the target is currently frozen. However, these work types are not being handled in binder_release_work() so they will leak during a cleanup. This was reported by syzkaller with the following kmemleak dump: BUG: memory leak unreferenced object 0xffff88810e2d6de0 (size 32): comm "syz-executor338", pid 5046, jiffies 4294968230 (age 13.590s) hex dump (first 32 bytes): e0 6d 2d 0e 81 88 ff ff e0 6d 2d 0e 81 88 ff ff .m-......m-..... 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81573b75>] kmalloc_trace+0x25/0x90 mm/slab_common.c:1114 [<ffffffff83d41873>] kmalloc include/linux/slab.h:599 [inline] [<ffffffff83d41873>] kzalloc include/linux/slab.h:720 [inline] [<ffffffff83d41873>] binder_transaction+0x573/0x4050 drivers/android/binder.c:3152 [<ffffffff83d45a05>] binder_thread_write+0x6b5/0x1860 drivers/android/binder.c:4010 [<ffffffff83d486dc>] binder_ioctl_write_read drivers/android/binder.c:5066 [inline] [<ffffffff83d486dc>] binder_ioctl+0x1b2c/0x3cf0 drivers/android/binder.c:5352 [<ffffffff816b25f2>] vfs_ioctl fs/ioctl.c:51 [inline] [<ffffffff816b25f2>] __do_sys_ioctl fs/ioctl.c:871 [inline] [<ffffffff816b25f2>] __se_sys_ioctl fs/ioctl.c:857 [inline] [<ffffffff816b25f2>] __x64_sys_ioctl+0xf2/0x140 fs/ioctl.c:857 [<ffffffff84b30008>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84b30008>] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [<ffffffff84c0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fix the leaks by kfreeing these work types in binder_release_work() and handle them as a BINDER_WORK_TRANSACTION_COMPLETE cleanup. Cc: stable@vger.kernel.org Fixes: 0567461a ("binder: return pending info for frozen async txns") Fixes: a7dc1e6f ("binder: tell userspace to dump current backtrace when detected oneway spamming") Reported-by: syzbot+7f10c1653e35933c0f1e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7f10c1653e35933c0f1eSuggested-by:Alice Ryhl <aliceryhl@google.com> Signed-off-by:
Carlos Llamas <cmllamas@google.com> Reviewed-by:
Todd Kjos <tkjos@google.com> Link: https://lore.kernel.org/r/20230922175138.230331-1-cmllamas@google.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Russ Weight authored
Update the firmware_loader documentation and corresponding section in the MAINTAINERs file with a new email address. Signed-off-by:
Russ Weight <russell.h.weight@intel.com> Link: https://lore.kernel.org/r/20230929151326.311959-1-russell.h.weight@intel.comSigned-off-by:
-
Kees Cook authored
There has been a repeated misunderstanding about what the hardware embargo list is for. Clarify the language in the process so that it is clear that only fixes are coordinated. There is explicitly no prenotification process. The list members are also expected to keep total radio silence during embargoes. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: workflows@vger.kernel.org Cc: linux-doc@vger.kernel.org Signed-off-by:
-
Jorge Sanjuan Garcia authored
When calling mcb_bus_add_devices(), both mcb devices and the mcb bus will attempt to attach a device to a driver because they share the same bus_type. This causes an issue when trying to cast the container of the device to mcb_device struct using to_mcb_device(), leading to a wrong cast when the mcb_bus is added. A crash occurs when freing the ida resources as the bus numbering of mcb_bus gets confused with the is_added flag on the mcb_device struct. The only reason for this cast was to keep an is_added flag on the mcb_device struct that does not seem necessary. The function device_attach() handles already bound devices and the mcb subsystem does nothing special with this is_added flag so remove it completely. Fixes: 18d28819 ("mcb: Correctly initialize the bus's device") Cc: stable <stable@kernel.org> Signed-off-by:
Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com> Co-developed-by:
Jose Javier Rodriguez Barbarin <JoseJavier.Rodriguez@duagon.com> Signed-off-by:
-
- 02 Oct, 2023 2 commits
-
-
Greg Kroah-Hartman authored
Merge tag 'coresight-fixes-v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux into char-misc-linus Suzuki writes: coresight: Fixes for v6.6 Couple of fixes for the CoreSight self-hosted tracing targeting v6.6. Includes : - Fix runtime warnings while reusing the TMC-ETR buffer - Fix (disable) warning when a large buffer is allocated in the flat mode. * tag 'coresight-fixes-v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux: coresight: tmc-etr: Disable warnings for allocation failures coresight: Fix run time warnings while reusing ETR buffer
-
Greg Kroah-Hartman authored
Merge tag 'counter-fixes-for-6.6a' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter into char-misc-linus William writes: First set of Counter fixes for 6.6 The counter_get_ext() function would incorrectly refer to the first element of the extensions array to handle component array extensions when they are located at a different index; a fix is provided to index to the correct element in the array for this case. A fix for the microchip-tcb-capture is provided as well to correct an inverted internal GCLK logic for clock selection. * tag 'counter-fixes-for-6.6a' of git://git.kernel.org/pub/scm/linux/kernel/git/wbg/counter: counter: microchip-tcb-capture: Fix the use of internal GCLK logic counter: chrdev: fix getting array extensions
-
- 01 Oct, 2023 15 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Merge tag 'kbuild-fixes-v6.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Fix the module compression with xz so the in-kernel decompressor works - Document a kconfig idiom to express an optional dependency between modules - Make modpost, when W=1 is given, detect broken drivers that reference .exit.* sections - Remove unused code * tag 'kbuild-fixes-v6.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: remove stale code for 'source' symlink in packaging scripts modpost: Don't let "driver"s reference .exit.* vmlinux.lds.h: remove unused CPU_KEEP and CPU_DISCARD macros modpost: add missing else to the "of" check Documentation: kbuild: explain handling optional dependencies kbuild: Use CRC32 and a 1MiB dictionary for XZ compressed modules
-
Linus Torvalds authored
Merge tag 'mm-hotfixes-stable-2023-10-01-08-34' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "Fourteen hotfixes, eleven of which are cc:stable. The remainder pertain to issues which were introduced after 6.5" * tag 'mm-hotfixes-stable-2023-10-01-08-34' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: Crash: add lock to serialize crash hotplug handling selftests/mm: fix awk usage in charge_reserved_hugetlb.sh and hugetlb_reparenting_test.sh that may cause error mm: mempolicy: keep VMA walk if both MPOL_MF_STRICT and MPOL_MF_MOVE are specified mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions() mm, memcg: reconsider kmem.limit_in_bytes deprecation mm: zswap: fix potential memory corruption on duplicate store arm64: hugetlb: fix set_huge_pte_at() to work with all swap entries mm: hugetlb: add huge page size param to set_huge_pte_at() maple_tree: add MAS_UNDERFLOW and MAS_OVERFLOW states maple_tree: add mas_is_active() to detect in-tree walks nilfs2: fix potential use after free in nilfs_gccache_submit_read_data() mm: abstract moving to the next PFN mm: report success more often from filemap_map_folio_range() fs: binfmt_elf_efpic: fix personality for ELF-FDPIC
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-miscLinus Torvalds authored
Pull misc driver fix from Greg KH: "Here is a single, much requested, fix for a set of misc drivers to resolve a much reported regression in the -rc series that has also propagated back to the stable releases. Sorry for the delay, lots of conference travel for a few weeks put me very far behind in patch wrangling. It has been reported by many to resolve the reported problem, and has been in linux-next with no reported issues" * tag 'char-misc-6.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: misc: rtsx: Fix some platforms can not boot and move the l1ss judgment to probe
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
Pull tty / serial driver fixes from Greg KH: "Here are two tty/serial driver fixes for 6.6-rc4 that resolve some reported regressions: - revert a n_gsm change that ended up causing problems - 8250_port fix for irq data both have been in linux-next for over a week with no reported problems" * tag 'tty-6.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux" serial: 8250_port: Check IRQ data before use
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Ingo Molnar: "Misc fixes: a kerneldoc build warning fix, add SRSO mitigation for AMD-derived Hygon processors, and fix a SGX kernel crash in the page fault handler that can trigger when ksgxd races to reclaim the SECS special page, by making the SECS page unswappable" * tag 'x86-urgent-2023-10-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race x86/srso: Add SRSO mitigation for Hygon processors x86/kgdb: Fix a kerneldoc warning when build with W=1
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fix from Ingo Molnar: "Fix a spurious kernel warning during CPU hotplug events that may trigger when timer/hrtimer softirqs are pending, which are otherwise hotplug-safe and don't merit a warning" * tag 'timers-urgent-2023-10-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: timers: Tag (hr)timer softirq as hotplug safe
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull scheduler fix from Ingo Molnar: "Fix a RT tasks related lockup/live-lock during CPU offlining" * tag 'sched-urgent-2023-10-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/rt: Fix live lock between select_fallback_rq() and RT push
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf event fixes from Ingo Molnar: "Misc fixes: work around an AMD microcode bug on certain models, and fix kexec kernel PMI handlers on AMD systems that get loaded on older kernels that have an unexpected register state" * tag 'perf-urgent-2023-10-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/amd: Do not WARN() on every IRQ perf/x86/amd/core: Fix overflow reset on hotplug
-
Masahiro Yamada authored
Since commit d8131c29 ("kbuild: remove $(MODLIB)/source symlink"), modules_install does not create the 'source' symlink. Remove the stale code from builddeb and kernel.spec. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Uwe Kleine-König authored
Drivers must not reference functions marked with __exit as these likely are not available when the code is built-in. There are few creative offenders uncovered for example in ARCH=amd64 allmodconfig builds. So only trigger the section mismatch warning for W=1 builds. The dual rule that drivers must not reference .init.* is implemented since commit 0db25245 ("modpost: don't allow *driver to reference .init.*") which however missed that .exit.* should be handled in the same way. Thanks to Masahiro Yamada and Arnd Bergmann who gave valuable hints to find this improvement. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Masahiro Yamada authored
Remove the left-over of commit e24f6628 ("modpost: remove all traces of cpuinit/cpuexit sections"). Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Mauricio Faria de Oliveira authored
Without this 'else' statement, an "usb" name goes into two handlers: the first/previous 'if' statement _AND_ the for-loop over 'devtable', but the latter is useless as it has no 'usb' device_id entry anyway. Tested with allmodconfig before/after patch; no changes to *.mod.c: git checkout v6.6-rc3 make -j$(nproc) allmodconfig make -j$(nproc) olddefconfig make -j$(nproc) find . -name '*.mod.c' | cpio -pd /tmp/before # apply patch make -j$(nproc) find . -name '*.mod.c' | cpio -pd /tmp/after diff -r /tmp/before/ /tmp/after/ # no difference Fixes: acbef7b7 ("modpost: fix module autoloading for OF devices with generic compatible property") Signed-off-by:Mauricio Faria de Oliveira <mfo@canonical.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds authored
Pull ARM SoC fixes from Arnd Bergmann: "These are the latest bug fixes that have come up in the soc tree. Most of these are fairly minor. Most notably, the majority of changes this time are not for dts files as usual. - Updates to the addresses of the broadcom and aspeed entries in the MAINTAINERS file. - Defconfig updates to address a regression on samsung and a build warning from an unknown Kconfig symbol - Build fixes for the StrongARM and Uniphier platforms - Code fixes for SCMI and FF-A firmware drivers, both of which had a simple bug that resulted in invalid data, and a lesser fix for the optee firmware driver - Multiple fixes for the recently added loongson/loongarch "guts" soc driver - Devicetree fixes for RISC-V on the startfive platform, addressing issues with NOR flash, usb and uart. - Multiple fixes for NXP i.MX8/i.MX9 dts files, fixing problems with clock, gpio, hdmi settings and the Makefile - Bug fixes for i.MX firmware code and the OCOTP soc driver - Multiple fixes for the TI sysc bus driver - Minor dts updates for TI omap dts files, to address boot time warnings and errors" * tag 'soc-fixes-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (35 commits) MAINTAINERS: Fix Florian Fainelli's email address arm64: defconfig: enable syscon-poweroff driver ARM: locomo: fix locomolcd_power declaration soc: loongson: loongson2_guts: Remove unneeded semicolon soc: loongson: loongson2_guts: Convert to devm_platform_ioremap_resource() soc: loongson: loongson_pm2: Populate children syscon nodes dt-bindings: soc: loongson,ls2k-pmc: Allow syscon-reboot/syscon-poweroff as child soc: loongson: loongson_pm2: Drop useless of_device_id compatible dt-bindings: soc: loongson,ls2k-pmc: Use fallbacks for ls2k-pmc compatible soc: loongson: loongson_pm2: Add dependency for INPUT arm64: defconfig: remove CONFIG_COMMON_CLK_NPCM8XX=y ARM: uniphier: fix cache kernel-doc warnings MAINTAINERS: aspeed: Update Andrew's email address MAINTAINERS: aspeed: Update git tree URL firmware: arm_ffa: Don't set the memory region attributes for MEM_LEND arm64: dts: imx: Add imx8mm-prt8mm.dtb to build arm64: dts: imx8mm-evk: Fix hdmi@3d node soc: imx8m: Enable OCOTP clock for imx8mm before reading registers arm64: dts: imx8mp-beacon-kit: Fix audio_pll2 clock arm64: dts: imx8mp: Fix SDMA2/3 clocks ... -
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-traceLinus Torvalds authored
Pull tracing fixes from Steven Rostedt: - Make sure 32-bit applications using user events have aligned access when running on a 64-bit kernel. - Add cond_resched in the loop that handles converting enums in print_fmt string is trace events. - Fix premature wake ups of polling processes in the tracing ring buffer. When a task polls waiting for a percentage of the ring buffer to be filled, the writer still will wake it up at every event. Add the polling's percentage to the "shortest_full" list to tell the writer when to wake it up. - For eventfs dir lookups on dynamic events, an event system's only event could be removed, leaving its dentry with no children. This is totally legitimate. But in eventfs_release() it must not access the children array, as it is only allocated when the dentry has children. * tag 'trace-v6.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: eventfs: Test for dentries array allocated in eventfs_release() tracing/user_events: Align set_bit() address for all archs tracing: relax trace_event_eval_update() execution with cond_resched() ring-buffer: Update "shortest_full" in polling
-
- 30 Sep, 2023 4 commits
-
-
Steven Rostedt (Google) authored
The dcache_dir_open_wrapper() could be called when a dynamic event is being deleted leaving a dentry with no children. In this case the dlist->dentries array will never be allocated. This needs to be checked for in eventfs_release(), otherwise it will trigger a NULL pointer dereference. Link: https://lore.kernel.org/linux-trace-kernel/20230930090106.1c3164e9@rorschach.local.home Cc: Mark Rutland <mark.rutland@arm.com> Acked-by:
Masami Hiramatsu (Google) <mhiramat@kernel.org> Fixes: ef36b4f9 ("eventfs: Remember what dentries were created on dir open") Signed-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org>
-
Beau Belgrave authored
All architectures should use a long aligned address passed to set_bit(). User processes can pass either a 32-bit or 64-bit sized value to be updated when tracing is enabled when on a 64-bit kernel. Both cases are ensured to be naturally aligned, however, that is not enough. The address must be long aligned without affecting checks on the value within the user process which require different adjustments for the bit for little and big endian CPUs. Add a compat flag to user_event_enabler that indicates when a 32-bit value is being used on a 64-bit kernel. Long align addresses and correct the bit to be used by set_bit() to account for this alignment. Ensure compat flags are copied during forks and used during deletion clears. Link: https://lore.kernel.org/linux-trace-kernel/20230925230829.341-2-beaub@linux.microsoft.com Link: https://lore.kernel.org/linux-trace-kernel/20230914131102.179100-1-cleger@rivosinc.com/ Cc: stable@vger.kernel.org Fixes: 72357590 ("tracing/user_events: Use remote writes for event enablement") Reported-by:
Clément Léger <cleger@rivosinc.com> Suggested-by:
Beau Belgrave <beaub@linux.microsoft.com> Signed-off-by:
-
Clément Léger authored
When kernel is compiled without preemption, the eval_map_work_func() (which calls trace_event_eval_update()) will not be preempted up to its complete execution. This can actually cause a problem since if another CPU call stop_machine(), the call will have to wait for the eval_map_work_func() function to finish executing in the workqueue before being able to be scheduled. This problem was observe on a SMP system at boot time, when the CPU calling the initcalls executed clocksource_done_booting() which in the end calls stop_machine(). We observed a 1 second delay because one CPU was executing eval_map_work_func() and was not preempted by the stop_machine() task. Adding a call to cond_resched() in trace_event_eval_update() allows other tasks to be executed and thus continue working asynchronously like before without blocking any pending task at boot time. Link: https://lore.kernel.org/linux-trace-kernel/20230929191637.416931-1-cleger@rivosinc.com Cc: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Atish Patra <atishp@rivosinc.com> Reviewed-by:
-
Steven Rostedt (Google) authored
It was discovered that the ring buffer polling was incorrectly stating that read would not block, but that's because polling did not take into account that reads will block if the "buffer-percent" was set. Instead, the ring buffer polling would say reads would not block if there was any data in the ring buffer. This was incorrect behavior from a user space point of view. This was fixed by commit 42fb0a1e by having the polling code check if the ring buffer had more data than what the user specified "buffer percent" had. The problem now is that the polling code did not register itself to the writer that it wanted to wait for a specific "full" value of the ring buffer. The result was that the writer would wake the polling waiter whenever there was a new event. The polling waiter would then wake up, see that there's not enough data in the ring buffer to notify user space and then go back to sleep. The next event would wake it up again. Before the polling fix was added, the code would wake up around 100 times for a hackbench 30 benchmark. After the "fix", due to the constant waking of the writer, it would wake up over 11,0000 times! It would never leave the kernel, so the user space behavior was still "correct", but this definitely is not the desired effect. To fix this, have the polling code add what it's waiting for to the "shortest_full" variable, to tell the writer not to wake it up if the buffer is not as full as it expects to be. Note, after this fix, it appears that the waiter is now woken up around 2x the times it was before (~200). This is a tremendous improvement from the 11,000 times, but I will need to spend some time to see why polling is more aggressive in its wakeups than the read blocking code. Link: https://lore.kernel.org/linux-trace-kernel/20230929180113.01c2cae3@rorschach.local.home Cc: stable@vger.kernel.org Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Fixes: 42fb0a1e ("tracing/ring-buffer: Have polling block on watermark") Reported-by:
Julia Lawall <julia.lawall@inria.fr> Tested-by:
-
