summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-04-29wifi: rtw89: coex: Add Wi-Fi null data status version 7Ching-Te Ku
The mechanism will use Wi-Fi null packet to stop the packets from access point to avoid the interference to Bluetooth when switch to Bluetooth slot. The report can check whether the null packet is working as expected or not. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240423130502.32682-2-pkshih@realtek.com
2024-04-29wifi: rtw89: 8852b: update hardware parameters for RFE type 5Ping-Ke Shih
RFE type 5 of 8852B is a type of hardware module, which can use different external components, so update register settings accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240423121247.24714-2-pkshih@realtek.com
2024-04-29wifi: rtw89: fix CTS transmission issue with center frequency deviationKuan-Chung Chen
The CTS cannot be received by the peer due to center frequency deviation. This issue can be solved by correct settings to transmit proper CTS. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240423121247.24714-1-pkshih@realtek.com
2024-04-28ksmbd: fix uninitialized symbol 'share' in smb2_tree_connect()Namjae Jeon
Fix uninitialized symbol 'share' in smb2_tree_connect(). Fixes: e9d8c2f95ab8 ("ksmbd: add continuous availability share parameter") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2024-04-28Linux 6.9-rc6v6.9-rc6Linus Torvalds
2024-04-28Merge tag 'sched-urgent-2024-04-28' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar: - Fix EEVDF corner cases - Fix two nohz_full= related bugs that can cause boot crashes and warnings * tag 'sched-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/isolation: Fix boot crash when maxcpus < first housekeeping CPU sched/isolation: Prevent boot crash when the boot CPU is nohz_full sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf() sched/eevdf: Fix miscalculation in reweight_entity() when se is not curr sched/eevdf: Always update V if se->on_rq when reweighting
2024-04-28Merge tag 'x86-urgent-2024-04-28' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: - Make the CPU_MITIGATIONS=n interaction with conflicting mitigation-enabling boot parameters a bit saner. - Re-enable CPU mitigations by default on non-x86 - Fix TDX shared bit propagation on mprotect() - Fix potential show_regs() system hang when PKE initialization is not fully finished yet. - Add the 0x10-0x1f model IDs to the Zen5 range - Harden #VC instruction emulation some more * tag 'x86-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n cpu: Re-enable CPU mitigations by default for !X86 architectures x86/tdx: Preserve shared bit on mprotect() x86/cpu: Fix check for RDPKRU in __show_regs() x86/CPU/AMD: Add models 0x10-0x1f to the Zen5 range x86/sev: Check for MWAITX and MONITORX opcodes in the #VC handler
2024-04-28Merge tag 'irq-urgent-2024-04-28' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fix from Ingo Molnar: "Fix a double free bug in the init error path of the GICv3 irqchip driver" * tag 'irq-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/gic-v3-its: Prevent double free on error
2024-04-28hwmon: (pmbus/adm1275) add adm1281 supportJose Ramon San Buenaventura
Add support for adm1281 which is similar to adm1275 and other chips of the series. Signed-off-by: Jose Ramon San Buenaventura <jose.sanbuenaventura@analog.com> Link: https://lore.kernel.org/r/20240425070948.25788-3-jose.sanbuenaventura@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28dt-bindings: hwmon: adm1275: add adm1281Jose Ramon San Buenaventura
Add support for the adm1281 Hot-Swap Controller and Digital Power and Energy Monitor Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Jose Ramon San Buenaventura <jose.sanbuenaventura@analog.com> Link: https://lore.kernel.org/r/20240425070948.25788-2-jose.sanbuenaventura@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (coretemp) Extend the bitmask to read temperature to 0xffRicardo Neri
The Intel Software Development manual defines the temperature digital readout as the bits [22:16] of the IA32_[PACKAGE]_THERM_STATUS registers. Bit 23 is specified as reserved. In recent processors, however, the temperature digital readout uses bits [23:16]. In those processors, using the bitmask 0x7f would lead to incorrect readings if the temperature deviates from TjMax by more than 127 degrees Celsius. Although not guaranteed, bit 23 is likely to be 0 in processors from a few generations ago. The temperature reading would still be correct in those processors when using a 0xff bitmask. Model-specific provisions can be made for older processors in which bit 23 is not 0 should the need arise. Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Link: https://lore.kernel.org/r/20240425171311.19519-4-ricardo.neri-calderon@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (jc42) Remove I2C_CLASS_SPD supportHeiner Kallweit
Last host driver supporting I2C_CLASS_SPD was i801. Now that I2C_CLASS_SPD support has been removed there, we can remove it here too. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/3c4a1715-bfbb-4ae2-b35f-2f20f95e4932@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (aspeed-g6-pwm-tach) Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Link: https://lore.kernel.org/r/20240409085552.19868-2-u.kleine-koenig@pengutronix.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28MAINTAINERS: repair file entry in ADP1050 HARDWARE MONITOR DRIVERLukas Bulwahn
Commit 4e1008d8aae5 ("dt-bindings: hwmon: pmbus: adp1050: add bindings") adds the ADP1050 HARDWARE MONITOR DRIVER section, but slips in a typo in its file entry. Fortunately, ./scripts/get_maintainer.pl --self-test=patterns complains about this broken reference. Fix the typo in ADP1050 HARDWARE MONITOR DRIVER maintainer entry. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20240402134203.8297-1-lukas.bulwahn@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (pwm-fan) Make use of device propertiesAndy Shevchenko
Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. Add mod_devicetable.h include. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240404191323.3547465-3-andriy.shevchenko@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (pwm-fan) Convert to use of_property_read_u32_array()Andy Shevchenko
This is a preparatory change to fulfill further conversion the driver to be OF-independent. The independent code has no analogue API that can read the value by index in the device property array. Suggested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240404191323.3547465-2-andriy.shevchenko@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: add HAS_IOPORT dependenciesNiklas Schnelle
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at compile time. We thus need to add HAS_IOPORT as dependency for those drivers using them. Acked-by: Guenter Roeck <linux@roeck-us.net> Co-developed-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Link: https://lore.kernel.org/r/20240404124700.3807842-2-schnelle@linux.ibm.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (pmbus/mp2975) Use i2c_get_match_data()Andy Shevchenko
Use preferred i2c_get_match_data() instead of of_device_get_match_data() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240325120952.3019767-4-andriy.shevchenko@linux.intel.com [groeck: Dropped __maybe_unused from mp2975_of_match] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (pmbus/mp2975) Constify local pointers to pmbus_driver_infoAndy Shevchenko
Constify the local variables pointing to "struct pmbus_driver_info" and other encoding params to annotate the function is not modifying pointed data. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240325120952.3019767-3-andriy.shevchenko@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (pmbus/mp2975) Replace home made version of __assign_bit()Andy Shevchenko
The newly introduced SWAP() macro is quite generic by naming, but moreover it's a repetition of the existing __assign_bit(). With this applied, add a missing bits.h (via now required bitops.h). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240325120952.3019767-2-andriy.shevchenko@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (pmbus/adp1050) Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240325124156.3036266-1-andriy.shevchenko@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (dell-smm) Add Dell Precision 7540 to fan control whitelistSeiji Nishikawa
Add Precision 7540 to the fan control whitelist, in addition to 7510. Signed-off-by: Seiji Nishikawa <snishika@redhat.com> Link: https://lore.kernel.org/r/20240325045913.385853-2-snishika@redhat.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (pmbus) Add driver for ADP1050Radu Sabau
Add support for ADP1050 Digital Controller for Isolated Power Supplies with PMBus interface Voltage, Current and Temperature Monitor. The ADP1050 implements several features to enable a robust system of parallel and redundant operation for customers who require high availability. The device can measure voltage, current and temperature that can be used in different techniques to identify and safely shut down an erroneous power supply in parallel operation mode. Signed-off-by: Radu Sabau <radu.sabau@analog.com> Link: https://lore.kernel.org/r/20240321142201.10330-2-radu.sabau@analog.com [groeck: Fixed corrupted link in documentation] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28dt-bindings: hwmon: pmbus: adp1050: add bindingsRadu Sabau
Add dt-bindings for adp1050 digital controller for isolated power supply with pmbus interface voltage, current and temperature monitor. Signed-off-by: Radu Sabau <radu.sabau@analog.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240321142201.10330-1-radu.sabau@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28dt-bindings: hwmon: ibm,p8-occ-hwmon: move to trivial devicesJavier Carrasco
This binding meets the requirements to be converted to dtschema via trivial-devices.yaml. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20240322-hwmon_dtschema-v3-5-6697de2a8228@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28dt-bindings: hwmon: stts751: convert to dtschemaJavier Carrasco
Convert existing binding to support validation. This is a straightforward conversion with no new properties. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20240322-hwmon_dtschema-v3-4-6697de2a8228@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28dt-bindings: hwmon: pwm-fan: drop text fileJavier Carrasco
This binding was converted to dtschema a year ago. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20240322-hwmon_dtschema-v3-3-6697de2a8228@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28dt-bindings: hwmon: ibmpowernv: convert to dtschemaJavier Carrasco
Convert existing binding to support validation. The binding has been renamed to match its compatible strings, with no further additions. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20240322-hwmon_dtschema-v3-2-6697de2a8228@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28dt-bindings: hwmon: as370: convert to dtschemaJavier Carrasco
Convert existing binding to support validation. This is a straightforward conversion with now new properties. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20240322-hwmon_dtschema-v3-1-6697de2a8228@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28dt-bindings: hwmon: max6650: convert to dtschemaJavier Carrasco
Convert existing bindings to dtschema to support validation. This is a straightforward conversion with no new properties. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240321-hwmon_yaml-v2-2-74fa8eb60ec9@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28dt-bindings: hwmon: lm87: convert to dtschemaJavier Carrasco
Convert existing bindings to dtschema to support validation. This is a straightforward conversion with no new properties. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240320-hwmon_yaml-v1-1-a349ca21ccab@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (acpi_power_meter) Ensure IPMI space handler is ready on Dell systemsKai-Heng Feng
The following error can be observed at boot: [ 3.717920] ACPI Error: No handler for Region [SYSI] (00000000ab9e62c5) [IPMI] (20230628/evregion-130) [ 3.717928] ACPI Error: Region IPMI (ID=7) has no handler (20230628/exfldio-261) [ 3.717936] No Local Variables are initialized for Method [_GHL] [ 3.717938] No Arguments are initialized for method [_GHL] [ 3.717940] ACPI Error: Aborting method \_SB.PMI0._GHL due to previous error (AE_NOT_EXIST) (20230628/psparse-529) [ 3.717949] ACPI Error: Aborting method \_SB.PMI0._PMC due to previous error (AE_NOT_EXIST) (20230628/psparse-529) [ 3.717957] ACPI: \_SB_.PMI0: _PMC evaluation failed: AE_NOT_EXIST On Dell systems several methods of acpi_power_meter access variables in IPMI region [0], so wait until IPMI space handler is installed by acpi_ipmi and also wait until SMI is selected to make the space handler fully functional. Since the dependency is inside BIOS's ASL code and it's not discoverable, so use this fixup is a hack to workaround BIOS issue. [0] https://www.dell.com/support/manuals/en-us/redhat-enterprise-linux-v8.0/rhel8_rn_pub/advanced-configuration-and-power-interface-acpi-error-messages-displayed-in-dmesg?guid=guid-0d5ae482-1977-42cf-b417-3ed5c3f5ee62 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20240320084317.366853-2-kai.heng.feng@canonical.com [groeck: Simplified added code] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28ACPI: IPMI: Add helper to wait for when SMI is selectedKai-Heng Feng
On Dell servers, many APCI methods of acpi_power_meter module evaluate variables inside IPMI region, so the region handler needs to be installed. In addition to that, the handler needs to be fully functional, and that depends on SMI being selected. So add a helper to let acpi_power_meter know when the handler is installed and ready to be used. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20240320084317.366853-1-kai.heng.feng@canonical.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (lm70) fix links in doc and commentsKousik Sanagavarapu
Update links in the documentation and in-code comments which point to the datasheet. The current links don't work because National Semiconductor (which is the original manufacturer of this chip) has been a part of Texas Instruments since 2011 and http://www.national.com/ doesn't work anymore. Fixes: e1a8e913f97e ("[PATCH] lm70: New hardware monitoring driver") Signed-off-by: Kousik Sanagavarapu <five231003@gmail.com> Link: https://lore.kernel.org/r/20240318154540.90613-3-five231003@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28dt-bindings: hwmon: adc128d818: convert to dtschemaJavier Carrasco
Convert adc128d818 bindings to dtschema to support validation. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20240319-adc128d818_dtschema-v2-1-0824a6d69493@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (pmbus/mp2975) Fix IRQ maskingPatrick Rudolph
The MP2971/MP2973 use a custom 16bit register format for SMBALERT_MASK which doesn't follow the PMBUS specification. Map the PMBUS defined bits used by the common code onto the custom format used by MPS and since the SMBALERT_MASK is currently never read by common code only implement the mapping for write transactions. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> Link: https://lore.kernel.org/r/20240318174406.3782306-1-naresh.solanki@9elements.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28hwmon: (dell-smm) Add Dell G5 5505 to DMI tableTobias Jakobi
Enables reading the speed of the CPU and GPU fan on the G5. Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240310220710.896230-1-tjakobi@math.uni-bielefeld.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2024-04-28erofs: reliably distinguish block based and fscache modeChristian Brauner
When erofs_kill_sb() is called in block dev based mode, s_bdev may not have been initialised yet, and if CONFIG_EROFS_FS_ONDEMAND is enabled, it will be mistaken for fscache mode, and then attempt to free an anon_dev that has never been allocated, triggering the following warning: ============================================ ida_free called for id=0 which is not allocated. WARNING: CPU: 14 PID: 926 at lib/idr.c:525 ida_free+0x134/0x140 Modules linked in: CPU: 14 PID: 926 Comm: mount Not tainted 6.9.0-rc3-dirty #630 RIP: 0010:ida_free+0x134/0x140 Call Trace: <TASK> erofs_kill_sb+0x81/0x90 deactivate_locked_super+0x35/0x80 get_tree_bdev+0x136/0x1e0 vfs_get_tree+0x2c/0xf0 do_new_mount+0x190/0x2f0 [...] ============================================ Now when erofs_kill_sb() is called, erofs_sb_info must have been initialised, so use sbi->fsid to distinguish between the two modes. Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com> Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Reviewed-by: Chao Yu <chao@kernel.org> Link: https://lore.kernel.org/r/20240419123611.947084-3-libaokun1@huawei.com Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2024-04-28erofs: get rid of erofs_fs_contextBaokun Li
Instead of allocating the erofs_sb_info in fill_super() allocate it during erofs_init_fs_context() and ensure that erofs can always have the info available during erofs_kill_sb(). After this erofs_fs_context is no longer needed, replace ctx with sbi, no functional changes. Suggested-by: Jingbo Xu <jefflexu@linux.alibaba.com> Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com> Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Reviewed-by: Chao Yu <chao@kernel.org> Link: https://lore.kernel.org/r/20240419123611.947084-2-libaokun1@huawei.com Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2024-04-28erofs: modify the error message when prepare_ondemand_read failedHongbo Li
When prepare_ondemand_read failed, wrong error message is printed. The prepare_read is also implemented in cachefiles, so we amend it. Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com> Reviewed-by: Chao Yu <chao@kernel.org> Link: https://lore.kernel.org/r/20240424084247.759432-1-lihongbo22@huawei.com Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2024-04-28ALSA: emu10k1: make E-MU FPGA writes potentially more reliableOswald Buddenhagen
We did not delay after the second strobe signal, so another immediately following access could potentially corrupt the written value. This is a purely speculative fix with no supporting evidence, but after taking out the spinlocks around the writes, it seems plausible that a modern processor could be actually too fast. Also, it's just cleaner to be consistent. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-7-oswald.buddenhagen@gmx.de>
2024-04-28ALSA: emu10k1: fix E-MU dock initializationOswald Buddenhagen
A side effect of making the dock monitoring interrupt-driven was that we'd be very quick to program a freshly connected dock. However, for unclear reasons, the dock does not work when we do that - despite the FPGA netlist upload going just fine. We work around this by adding a delay before programming the dock; for safety, the value is several times as much as was determined empirically. Note that a badly timed dock hot-plug would have triggered the problem even before the referenced commit - but now it would happen 100% instead of about 3% of the time, thus making it impossible to work around by re-plugging. Fixes: fbb64eedf5a3 ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584 Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-6-oswald.buddenhagen@gmx.de>
2024-04-28ALSA: emu10k1: use mutex for E-MU FPGA access lockingOswald Buddenhagen
The FPGA access through the GPIO port does not interfere with other sound processor register access, so there is no need to subject it to emu_lock. And after moving all FPGA access out of the interrupt handler, it does not need to be IRQ-safe, either. What's more, attaching the dock causes a firmware upload, which takes several seconds. We really don't want to disable IRQs for this long, and even less also have someone else spin with IRQs disabled waiting for us. Therefore, use a mutex for FPGA access locking. This makes the code somewhat more noisy, as we need to wrap bigger sections into the mutex, as it needs to enclose the spinlocks. The latter has the "side effect" of fixing dock FPGA programming in a corner case: a really badly timed mixer access right between entering FPGA programming mode and uploading the netlist would mess up the protocol. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-5-oswald.buddenhagen@gmx.de>
2024-04-28ALSA: emu10k1: move the whole GPIO event handling to the workqueueOswald Buddenhagen
The actual event processing was already done by workqueue items. We can move the event dispatching there as well, rather than doing it already in the interrupt handler callback. This change has a rather profound "side effect" on the reliability of the FPGA programming: once we enter programming mode, we must not issue any snd_emu1010_fpga_{read,write}() calls until we're done, as these would badly mess up the programming protocol. But exactly that would happen when trying to program the dock, as that triggers GPIO interrupts as a side effect. This is mitigated by deferring the actual interrupt handling, as workqueue items are not re-entrant. To avoid scheduling the dispatcher on non-events, we now explicitly ignore GPIO IRQs triggered by "uninteresting" pins, which happens a lot as a side effect of calling snd_emu1010_fpga_{read,write}(). Fixes: fbb64eedf5a3 ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584 Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-4-oswald.buddenhagen@gmx.de>
2024-04-28ALSA: emu10k1: factor out snd_emu1010_load_dock_firmware()Oswald Buddenhagen
Pulled out of the next patch to improve its legibility. As the function is now available, call it directly from snd_emu10k1_emu1010_init(), thus making the MicroDock firmware loading synchronous - there isn't really a reason not to. Note that this does not affect the AudioDocks of rev1 cards, as these have no independent power supplies, and thus come up only a while after the main card is initialized. As a drive-by, adjust the priorities of two messages to better reflect their impact. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-3-oswald.buddenhagen@gmx.de>
2024-04-28ALSA: emu10k1: fix E-MU card dock presence monitoringOswald Buddenhagen
While there are two separate IRQ status bits for dock attach and detach, the hardware appears to mix them up more or less randomly, making them useless for tracking what actually happened. It is much safer to check the dock status separately and proceed based on that, as the old polling code did. Note that the code assumes that only the dock can be hot-plugged - if other option card bits changed, the logic would break. Fixes: fbb64eedf5a3 ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584 Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-2-oswald.buddenhagen@gmx.de>
2024-04-28sched/isolation: Fix boot crash when maxcpus < first housekeeping CPUOleg Nesterov
housekeeping_setup() checks cpumask_intersects(present, online) to ensure that the kernel will have at least one housekeeping CPU after smp_init(), but this doesn't work if the maxcpus= kernel parameter limits the number of processors available after bootup. For example, a kernel with "maxcpus=2 nohz_full=0-2" parameters crashes at boot time on a virtual machine with 4 CPUs. Change housekeeping_setup() to use cpumask_first_and() and check that the returned CPU number is valid and less than setup_max_cpus. Another corner case is "nohz_full=0" on a machine with a single CPU or with the maxcpus=1 kernel argument. In this case non_housekeeping_mask is empty and tick_nohz_full_setup() makes no sense. And indeed, the kernel hits the WARN_ON(tick_nohz_full_running) in tick_sched_do_timer(). And how should the kernel interpret the "nohz_full=" parameter? It should be silently ignored, but currently cpulist_parse() happily returns the empty cpumask and this leads to the same problem. Change housekeeping_setup() to check cpumask_empty(non_housekeeping_mask) and do nothing in this case. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Phil Auld <pauld@redhat.com> Acked-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20240413141746.GA10008@redhat.com
2024-04-28sched/isolation: Prevent boot crash when the boot CPU is nohz_fullOleg Nesterov
Documentation/timers/no_hz.rst states that the "nohz_full=" mask must not include the boot CPU, which is no longer true after: 08ae95f4fd3b ("nohz_full: Allow the boot CPU to be nohz_full"). However after: aae17ebb53cd ("workqueue: Avoid using isolated cpus' timers on queue_delayed_work") the kernel will crash at boot time in this case; housekeeping_any_cpu() returns an invalid CPU number until smp_init() brings the first housekeeping CPU up. Change housekeeping_any_cpu() to check the result of cpumask_any_and() and return smp_processor_id() in this case. This is just the simple and backportable workaround which fixes the symptom, but smp_processor_id() at boot time should be safe at least for type == HK_TYPE_TIMER, this more or less matches the tick_do_timer_boot_cpu logic. There is no worry about cpu_down(); tick_nohz_cpu_down() will not allow to offline tick_do_timer_cpu (the 1st online housekeeping CPU). Fixes: aae17ebb53cd ("workqueue: Avoid using isolated cpus' timers on queue_delayed_work") Reported-by: Chris von Recklinghausen <crecklin@redhat.com> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Phil Auld <pauld@redhat.com> Acked-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20240411143905.GA19288@redhat.com Closes: https://lore.kernel.org/all/20240402105847.GA24832@redhat.com/
2024-04-28ARM: dts: imx6ul-pico: Use #pwm-cells = <3> for imx27-pwm deviceUwe Kleine-König
The binding dictates using 3 pwm-cells. Adhere to that. This fixes the following dtbs_check warnings: arch/arm/boot/dts/nxp/imx/imx6ul-pico-dwarf.dtb: pwm@2088000: #pwm-cells:0:0: 3 was expected from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml# arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dtb: pwm@2088000: #pwm-cells:0:0: 3 was expected from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml# arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dtb: pwm@2088000: #pwm-cells:0:0: 3 was expected from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml# Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-04-28ARM: dts: imx6ul-kontron-bl-common: Use #pwm-cells = <3> for imx27-pwm deviceUwe Kleine-König
The binding dictates using 3 pwm-cells. Adhere to that. This fixes the following dtbs_check warnings: arch/arm/boot/dts/nxp/imx/imx6ul-kontron-bl.dtb: pwm@20fc000: #pwm-cells:0:0: 3 was expected from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml# arch/arm/boot/dts/nxp/imx/imx6ul-kontron-bl-43.dtb: pwm@20fc000: #pwm-cells:0:0: 3 was expected from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml# arch/arm/boot/dts/nxp/imx/imx6ull-kontron-bl.dtb: pwm@20fc000: #pwm-cells:0:0: 3 was expected from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml# Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>