summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* extcon: Use dev_of_node(dev) instead of dev->of_nodeAndy Shevchenko2023-05-291-8/+4
| | | | | | | | | The dev_of_node function should be preferred. In the result we may drop unneeded NULL check of the pointer to the device object. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: Use device_match_of_node() helperAndy Shevchenko2023-05-291-1/+1
| | | | | | | Instead of open coding, use device_match_of_node() helper. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: Amend kernel documentation of struct extcon_devAndy Shevchenko2023-05-291-3/+3
| | | | | | | | | First of all, the @lock description is missing. Add it. Second, correct the terminator value for the mutual exclusive cabling. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: Use sysfs_emit() to instead of sprintf()Andy Shevchenko2023-05-291-9/+9
| | | | | | | | | Follow the advice of the Documentation/filesystems/sysfs.rst that show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: Use DECLARE_BITMAP() to declare bit arraysAndy Shevchenko2023-05-291-4/+4
| | | | | | | | Bit arrays has a specific type helper for the declaration. Use it instead of homegronw equivalent. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: Fix kernel doc of property capability fields to avoid warningsAndy Shevchenko2023-05-291-0/+4
| | | | | | | | | | | | | | | | Kernel documentation has to be synchronized with a code, otherwise the validator is not happy: Function parameter or member 'usb_bits' not described in 'extcon_cable' Function parameter or member 'chg_bits' not described in 'extcon_cable' Function parameter or member 'jack_bits' not described in 'extcon_cable' Function parameter or member 'disp_bits' not described in 'extcon_cable' Describe the fields added in the past. Fixes: ceaa98f442cf ("extcon: Add the support for the capability of each property") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: Fix kernel doc of property fields to avoid warningsAndy Shevchenko2023-05-291-0/+4
| | | | | | | | | | | | | | | | Kernel documentation has to be synchronized with a code, otherwise the validator is not happy: Function parameter or member 'usb_propval' not described in 'extcon_cable' Function parameter or member 'chg_propval' not described in 'extcon_cable' Function parameter or member 'jack_propval' not described in 'extcon_cable' Function parameter or member 'disp_propval' not described in 'extcon_cable' Describe the fields added in the past. Fixes: 067c1652e7a7 ("extcon: Add the support for extcon property according to extcon type") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: usbc-tusb320: add USB_ROLE_SWITCH dependencyArnd Bergmann2023-05-291-0/+1
| | | | | | | | | | | | | | | | | | | | When CONFIG_USB_ROLE_SWITCH=m, tusb320 cannot be built-in: ld.lld: error: undefined symbol: fwnode_usb_role_switch_get >>> referenced by extcon-usbc-tusb320.c >>> drivers/extcon/extcon-usbc-tusb320.o:(tusb320_probe) in archive vmlinux.a ld.lld: error: undefined symbol: usb_role_switch_set_role >>> referenced by extcon-usbc-tusb320.c >>> drivers/extcon/extcon-usbc-tusb320.o:(tusb320_state_update_handler) in archive vmlinux.a Add the appropriate Kconfig dependency to prevent this configuration but still allow the driver to be built-in when USB_ROLE_SWITCH is disabled. Fixes: df101446a402 ("extcon: usbc-tusb320: add usb_role_switch support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: usbc-tusb320: add usb_role_switch supportAlvin Šipraga2023-05-291-0/+21
| | | | | | | | | | | | The connector child node of the TUSB320 device might be linked with a dual-role capable USB controller. Add driver support for detecting a usb_role_switch and setting its state in the typec interrupt handler. This follows similar practice in other drivers in the typec subsystem, which this extcon driver can opt-in to. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: usbc-tusb320: add accessory detection supportAlvin Šipraga2023-05-291-22/+68
| | | | | | | | | | | | | | | | | | | | | The TUSB320 can detect the following types of accessory: - Audio Accessory - Audio Accessory with charge-thru - Debug Accessory (DFP) - Debug Accessory (UFP) Moreover, the typec subsystem can be informed of this through the typec_set_mode() function. The information will be propagated to any linked typec muxes. Add the necessary support to the driver. Note that for the Debug Accessory modes, an educated guess was made that for the USB data role, DFP implies HOST and UFP implies DEVICE. But this might want to be made configurable at a later date. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: Add extcon_alloc_groups to simplify extcon register functionBumwoo Lee2023-05-291-22/+39
| | | | | | | | The alloc groups is functionalized from extcon_dev_register. Signed-off-by: Bumwoo Lee <bw365.lee@samsung.com> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: Add extcon_alloc_muex to simplify extcon register functionBumwoo Lee2023-05-291-48/+61
| | | | | | | | The mutual exclusive part is functionalized from extcon_dev_register. Signed-off-by: Bumwoo Lee <bw365.lee@samsung.com> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: Add extcon_alloc_cables to simplify extcon register functionBumwoo Lee2023-05-291-46/+65
| | | | | | | | The cable allocation part is functionalized from extcon_dev_register. Signed-off-by: Bumwoo Lee <bw365.lee@samsung.com> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: Remove redundant null checking for classBumwoo Lee2023-05-291-11/+10
| | | | | | | | create_extcon_class() is already Null checking. Signed-off-by: Bumwoo Lee <bw365.lee@samsung.com> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: palmas: Remove unused of_gpio.hAndy Shevchenko2023-05-291-1/+0
| | | | | | | | of_gpio.h provides a single function, which is not used in this driver. Remove unused header. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: qcom-spmi: Switch to platform_get_irq_byname_optionalBryan O'Donoghue2023-05-291-2/+2
| | | | | | | | | | | | | | | | | | | | Valid configurations for the extcon interrupt declarations are - usb_id - usb_vbus - (usb_id | usb_vbus) In the case of a standalone usb_id or usb_vbus failure to find one of the interrupts shouldn't generate a warning message. A warning is already in place if both IRQs are missing. Switch to using platform_get_irq_byname_optional() in order to facilitate this behaviour. Suggested-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* dt-bindings: pm8941-misc: Fix usb_id and usb_vbus definitionsBryan O'Donoghue2023-05-291-4/+8
| | | | | | | | | | | | | | | | | | | dts validation is throwing an error for me on 8916 and 8939 with extcon@1300. In that case we have usb_vbus but not usb_id. It wasn't immediately obvious if there was a valid use-case for the existing code for usb_id in isolation, however discussing further, we concluded that usb_id, usb_vbus or (usb_id | usb_vbus) are valid combinations as an external IC may be responsible for usb_id or usb_vbus. Expand the definition with anyOf to capture the three different valid modes. Fixes: 4fcdd677c4ea ("bindings: pm8941-misc: Add support for VBUS detection") Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* dt-bindings: pm8941-misc: rename misc node nameLuca Weiss2023-05-291-1/+1
| | | | | | | | | | The spmi-pmic bindings is now using usb-detect@ for this node, so adjust the example to match. Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: axp288: Replace open coded acpi_dev_put()Andy Shevchenko2023-05-291-1/+1
| | | | | | | | Instead of calling put_device(&adev->dev) where adev is a pointer to an ACPI device, use specific call, i.e. acpi_dev_put(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* extcon: usbc-tusb320: Unregister typec port on driver removalAlvin Šipraga2023-05-291-8/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | The driver can register a typec port if suitable firmware properties are present. But if the driver is removed through sysfs unbind, rmmod or similar, then it does not clean up after itself and the typec port device remains registered. This can be seen in sysfs, where stale typec ports get left over in /sys/class/typec. In order to fix this we have to add an i2c_driver remove function and call typec_unregister_port(), which is a no-op in the case where no typec port is created and the pointer remains NULL. In the process we should also put the fwnode_handle when the typec port isn't registered anymore, including if an error occurs during probe. The typec subsystem does not increase or decrease the reference counter for us, so we track it in the driver's private data. Note that the conditional check on TYPEC_PWR_MODE_PD was removed in the probe path because a call to tusb320_set_adv_pwr_mode() will perform an even more robust validation immediately after, hence there is no functional change here. Fixes: bf7571c00dca ("extcon: usbc-tusb320: Add USB TYPE-C support") Cc: stable@vger.kernel.org Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
* Linux 6.4-rc4v6.4-rc4Linus Torvalds2023-05-281-1/+1
|
* Merge tag 'x86-urgent-2023-05-28' of ↵Linus Torvalds2023-05-281-2/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 cpu fix from Thomas Gleixner: "A single fix for x86: - Prevent a bogus setting for the number of HT siblings, which is caused by the CPUID evaluation trainwreck of X86. That recomputes the value for each CPU, so the last CPU "wins". That can cause completely bogus sibling values" * tag 'x86-urgent-2023-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/topology: Fix erroneous smp_num_siblings on Intel Hybrid platforms
| * x86/topology: Fix erroneous smp_num_siblings on Intel Hybrid platformsZhang Rui2023-05-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Traditionally, all CPUs in a system have identical numbers of SMT siblings. That changes with hybrid processors where some logical CPUs have a sibling and others have none. Today, the CPU boot code sets the global variable smp_num_siblings when every CPU thread is brought up. The last thread to boot will overwrite it with the number of siblings of *that* thread. That last thread to boot will "win". If the thread is a Pcore, smp_num_siblings == 2. If it is an Ecore, smp_num_siblings == 1. smp_num_siblings describes if the *system* supports SMT. It should specify the maximum number of SMT threads among all cores. Ensure that smp_num_siblings represents the system-wide maximum number of siblings by always increasing its value. Never allow it to decrease. On MeteorLake-P platform, this fixes a problem that the Ecore CPUs are not updated in any cpu sibling map because the system is treated as an UP system when probing Ecore CPUs. Below shows part of the CPU topology information before and after the fix, for both Pcore and Ecore CPU (cpu0 is Pcore, cpu 12 is Ecore). ... -/sys/devices/system/cpu/cpu0/topology/package_cpus:000fff -/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-11 +/sys/devices/system/cpu/cpu0/topology/package_cpus:3fffff +/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-21 ... -/sys/devices/system/cpu/cpu12/topology/package_cpus:001000 -/sys/devices/system/cpu/cpu12/topology/package_cpus_list:12 +/sys/devices/system/cpu/cpu12/topology/package_cpus:3fffff +/sys/devices/system/cpu/cpu12/topology/package_cpus_list:0-21 Notice that the "before" 'package_cpus_list' has only one CPU. This means that userspace tools like lscpu will see a little laptop like an 11-socket system: -Core(s) per socket: 1 -Socket(s): 11 +Core(s) per socket: 16 +Socket(s): 1 This is also expected to make the scheduler do rather wonky things too. [ dhansen: remove CPUID detail from changelog, add end user effects ] CC: stable@kernel.org Fixes: bbb65d2d365e ("x86: use cpuid vector 0xb when available for detecting cpu topology") Fixes: 95f3d39ccf7a ("x86/cpu/topology: Provide detect_extended_topology_early()") Suggested-by: Len Brown <len.brown@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/all/20230323015640.27906-1-rui.zhang%40intel.com
* | Merge tag 'perf-urgent-2023-05-28' of ↵Linus Torvalds2023-05-282-1/+12
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Thomas Gleixner: "A small set of perf fixes: - Make the MSR-readout based CHA discovery work around broken discovery tables in some SPR firmwares. - Prevent saving PEBS configuration which has software bits set that cause a crash when restored into the relevant MSR" * tag 'perf-urgent-2023-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/uncore: Correct the number of CHAs on SPR perf/x86/intel: Save/restore cpuc->active_pebs_data_cfg when using guest PEBS
| * | perf/x86/uncore: Correct the number of CHAs on SPRKan Liang2023-05-241-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The number of CHAs from the discovery table on some SPR variants is incorrect, because of a firmware issue. An accurate number can be read from the MSR UNC_CBO_CONFIG. Fixes: 949b11381f81 ("perf/x86/intel/uncore: Add Sapphire Rapids server CHA support") Reported-by: Stephane Eranian <eranian@google.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Stephane Eranian <eranian@google.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230508140206.283708-1-kan.liang@linux.intel.com
| * | perf/x86/intel: Save/restore cpuc->active_pebs_data_cfg when using guest PEBSLike Xu2023-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After commit b752ea0c28e3 ("perf/x86/intel/ds: Flush PEBS DS when changing PEBS_DATA_CFG"), the cpuc->pebs_data_cfg may save some bits that are not supported by real hardware, such as PEBS_UPDATE_DS_SW. This would cause the VMX hardware MSR switching mechanism to save/restore invalid values for PEBS_DATA_CFG MSR, thus crashing the host when PEBS is used for guest. Fix it by using the active host value from cpuc->active_pebs_data_cfg. Fixes: b752ea0c28e3 ("perf/x86/intel/ds: Flush PEBS DS when changing PEBS_DATA_CFG") Signed-off-by: Like Xu <likexu@tencent.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Link: https://lore.kernel.org/r/20230517133808.67885-1-likexu@tencent.com
* | | Merge tag 'objtool-urgent-2023-05-28' of ↵Linus Torvalds2023-05-282-3/+13
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull unwinder fixes from Thomas Gleixner: "A set of unwinder and tooling fixes: - Ensure that the stack pointer on x86 is aligned again so that the unwinder does not read past the end of the stack - Discard .note.gnu.property section which has a pointlessly different alignment than the other note sections. That confuses tooling of all sorts including readelf, libbpf and pahole" * tag 'objtool-urgent-2023-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/show_trace_log_lvl: Ensure stack pointer is aligned, again vmlinux.lds.h: Discard .note.gnu.property section
| * | | x86/show_trace_log_lvl: Ensure stack pointer is aligned, againVernon Lovejoy2023-05-161-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned") tried to align the stack pointer in show_trace_log_lvl(), otherwise the "stack < stack_info.end" check can't guarantee that the last read does not go past the end of the stack. However, we have the same problem with the initial value of the stack pointer, it can also be unaligned. So without this patch this trivial kernel module #include <linux/module.h> static int init(void) { asm volatile("sub $0x4,%rsp"); dump_stack(); asm volatile("add $0x4,%rsp"); return -EAGAIN; } module_init(init); MODULE_LICENSE("GPL"); crashes the kernel. Fixes: e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned") Signed-off-by: Vernon Lovejoy <vlovejoy@redhat.com> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/r/20230512104232.GA10227@redhat.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
| * | | vmlinux.lds.h: Discard .note.gnu.property sectionJosh Poimboeuf2023-05-161-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When tooling reads ELF notes, it assumes each note entry is aligned to the value listed in the .note section header's sh_addralign field. The kernel-created ELF notes in the .note.Linux and .note.Xen sections are aligned to 4 bytes. This causes the toolchain to set those sections' sh_addralign values to 4. On the other hand, the GCC-created .note.gnu.property section has an sh_addralign value of 8 for some reason, despite being based on struct Elf32_Nhdr which only needs 4-byte alignment. When the mismatched input sections get linked together into the vmlinux .notes output section, the higher alignment "wins", resulting in an sh_addralign of 8, which confuses tooling. For example: $ readelf -n .tmp_vmlinux.btf ... readelf: .tmp_vmlinux.btf: Warning: note with invalid namesz and/or descsz found at offset 0x170 readelf: .tmp_vmlinux.btf: Warning: type: 0x4, namesize: 0x006e6558, descsize: 0x00008801, alignment: 8 In this case readelf thinks there's alignment padding where there is none, so it starts reading an ELF note in the middle. With newer toolchains (e.g., latest Fedora Rawhide), a similar mismatch triggers a build failure when combined with CONFIG_X86_KERNEL_IBT: btf_encoder__encode: btf__dedup failed! Failed to encode BTF libbpf: failed to find '.BTF' ELF section in vmlinux FAILED: load BTF from vmlinux: No data available make[1]: *** [scripts/Makefile.vmlinux:35: vmlinux] Error 255 This latter error was caused by pahole crashing when it encountered the corrupt .notes section. This crash has been fixed in dwarves version 1.25. As Tianyi Liu describes: "Pahole reads .notes to look for LINUX_ELFNOTE_BUILD_LTO. When LTO is enabled, pahole needs to call cus__merge_and_process_cu to merge compile units, at which point there should only be one unspecified type (used to represent some compilation information) in the global context. However, when the kernel is compiled without LTO, if pahole calls cus__merge_and_process_cu due to alignment issues with notes, multiple unspecified types may appear after merging the cus, and older versions of pahole only support up to one. This is why pahole 1.24 crashes, while newer versions support multiple. However, the latest version of pahole still does not solve the problem of incorrect LTO recognition, so compiling the kernel may be slower than normal." Even with the newer pahole, the note section misaligment issue still exists and pahole is misinterpreting the LTO note. Fix it by discarding the .note.gnu.property section. While GNU properties are important for user space (and VDSO), they don't seem to have any use for vmlinux. (In fact, they're already getting (inadvertently) stripped from vmlinux when CONFIG_DEBUG_INFO_BTF is enabled. The BTF data is extracted from vmlinux.o with "objcopy --only-section=.BTF" into .btf.vmlinux.bin.o. That file doesn't have .note.gnu.property, so when it gets modified and linked back into the main object, the linker automatically strips it (see "How GNU properties are merged" in the ld man page).) Reported-by: Daniel Xu <dxu@dxuuu.xyz> Link: https://lkml.kernel.org/bpf/57830c30-cd77-40cf-9cd1-3bb608aa602e@app.fastmail.com Debugged-by: Tianyi Liu <i.pear@outlook.com> Suggested-by: Joan Bruguera Micó <joanbrugueram@gmail.com> Link: https://lore.kernel.org/r/20230418214925.ay3jpf2zhw75kgmd@treble Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
* | | | Merge tag 'core-debugobjects-2023-05-28' of ↵Linus Torvalds2023-05-284-10/+50
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull debugobjects fixes from Thomas Gleixner: "Two fixes for debugobjects: - Prevent the allocation path from waking up kswapd. That's a long standing issue due to the GFP_ATOMIC allocation flag. As debug objects can be invoked from pretty much any context waking kswapd can end up in arbitrary lock chains versus the waitqueue lock - Correct the explicit lockdep wait-type violation in debug_object_fill_pool()" * tag 'core-debugobjects-2023-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: debugobjects: Don't wake up kswapd from fill_pool() debugobjects,locking: Annotate debug_object_fill_pool() wait type violation
| * | | | debugobjects: Don't wake up kswapd from fill_pool()Tetsuo Handa2023-05-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | syzbot is reporting a lockdep warning in fill_pool() because the allocation from debugobjects is using GFP_ATOMIC, which is (__GFP_HIGH | __GFP_KSWAPD_RECLAIM) and therefore tries to wake up kswapd, which acquires kswapd_wait::lock. Since fill_pool() might be called with arbitrary locks held, fill_pool() should not assume that acquiring kswapd_wait::lock is safe. Use __GFP_HIGH instead and remove __GFP_NORETRY as it is pointless for !__GFP_DIRECT_RECLAIM allocation. Fixes: 3ac7fe5a4aab ("infrastructure to debug (dynamic) objects") Reported-by: syzbot <syzbot+fe0c72f0ccbb93786380@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/6577e1fa-b6ee-f2be-2414-a2b51b1c5e30@I-love.SAKURA.ne.jp Closes: https://syzkaller.appspot.com/bug?extid=fe0c72f0ccbb93786380
| * | | | debugobjects,locking: Annotate debug_object_fill_pool() wait type violationPeter Zijlstra2023-05-024-9/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is an explicit wait-type violation in debug_object_fill_pool() for PREEMPT_RT=n kernels which allows them to more easily fill the object pool and reduce the chance of allocation failures. Lockdep's wait-type checks are designed to check the PREEMPT_RT locking rules even for PREEMPT_RT=n kernels and object to this, so create a lockdep annotation to allow this to stand. Specifically, create a 'lock' type that overrides the inner wait-type while it is held -- allowing one to temporarily raise it, such that the violation is hidden. Reported-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: Qi Zheng <zhengqi.arch@bytedance.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Qi Zheng <zhengqi.arch@bytedance.com> Link: https://lkml.kernel.org/r/20230429100614.GA1489784@hirez.programming.kicks-ass.net
* | | | | Merge tag 'irq-urgent-2023-05-28' of ↵Linus Torvalds2023-05-287-31/+69
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Thomas Gleixner: "A set of fixes for interrupt chip drivers: - Prevent loss of state in the MIPS GIC interrupt controller - Disable pseudo NMIs on Mediatek based Chromebooks as they have firmware issues which cause instantenous chrashes and freezes wen pseudo NMIs are used - Fix the error handling path in the MBIGEN driver and a defined but not used warning in the meson-gpio interrupt chip driver" * tag 'irq-urgent-2023-05-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/mbigen: Unify the error handling in mbigen_of_create_domain() irqchip/meson-gpio: Mark OF related data as maybe unused irqchip/mips-gic: Use raw spinlock for gic_lock irqchip/mips-gic: Don't touch vl_map if a local interrupt is not routable irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues dt-bindings: interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs w/ broken FW
| * \ \ \ \ Merge tag 'irqchip-fixes-6.4-1' of ↵Thomas Gleixner2023-05-227-31/+69
| |\ \ \ \ \ | | |_|_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip fixes from Marc Zyngier: - MIPS GIC fixes for issues that could result in either loss of state in the interrupt controller, or a deadlock - Workaround for Mediatek Chromebooks that only save/restore partial state when turning the GIC redistributors off, resulting if fireworks if Linux uses interrupt priorities for pseudo-NMIs - Fix the MBIGEN error handling on init - Mark meson-gpio OF data structures as __maybe_unused, avoiding compilation warnings on non-OF setups Link: https://lore.kernel.org/lkml/20230521101812.2520740-1-maz@kernel.org
| | * | | | irqchip/mbigen: Unify the error handling in mbigen_of_create_domain()Kefeng Wang2023-05-161-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dan Carpenter reported that commit fea087fc291b "irqchip/mbigen: move to use bus_get_dev_root()" leads to the following Smatch static checker warning: drivers/irqchip/irq-mbigen.c:258 mbigen_of_create_domain() error: potentially dereferencing uninitialized 'child'. It should not cause a problem on real hardware, but better to fix the warning, let's move the bus_get_dev_root() out of the loop, and unify the error handling to silence it. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230505090654.12793-1-wangkefeng.wang@huawei.com
| | * | | | irqchip/meson-gpio: Mark OF related data as maybe unusedKrzysztof Kozlowski2023-05-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/irqchip/irq-meson-gpio.c:153:34: error: ‘meson_irq_gpio_matches’ defined but not used [-Werror=unused-const-variable=] Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230512164506.212267-1-krzysztof.kozlowski@linaro.org
| | * | | | irqchip/mips-gic: Use raw spinlock for gic_lockJiaxun Yang2023-05-161-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we may hold gic_lock in hardirq context, use raw spinlock makes more sense given that it is for low-level interrupt handling routine and the critical section is small. Fixes BUG: [ 0.426106] ============================= [ 0.426257] [ BUG: Invalid wait context ] [ 0.426422] 6.3.0-rc7-next-20230421-dirty #54 Not tainted [ 0.426638] ----------------------------- [ 0.426766] swapper/0/1 is trying to lock: [ 0.426954] ffffffff8104e7b8 (gic_lock){....}-{3:3}, at: gic_set_type+0x30/08 Fixes: 95150ae8b330 ("irqchip: mips-gic: Implement irq_set_type callback") Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230424103156.66753-3-jiaxun.yang@flygoat.com
| | * | | | irqchip/mips-gic: Don't touch vl_map if a local interrupt is not routableJiaxun Yang2023-05-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a GIC local interrupt is not routable, it's vl_map will be used to control some internal states for core (providing IPTI, IPPCI, IPFDC input signal for core). Overriding it will interfere core's intetrupt controller. Do not touch vl_map if a local interrupt is not routable, we are not going to remap it. Before dd098a0e0319 (" irqchip/mips-gic: Get rid of the reliance on irq_cpu_online()"), if a local interrupt is not routable, then it won't be requested from GIC Local domain, and thus gic_all_vpes_irq_cpu_online won't be called for that particular interrupt. Fixes: dd098a0e0319 (" irqchip/mips-gic: Get rid of the reliance on irq_cpu_online()") Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230424103156.66753-2-jiaxun.yang@flygoat.com
| | * | | | irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issuesDouglas Anderson2023-05-163-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some Chromebooks with Mediatek SoCs have a problem where the firmware doesn't properly save/restore certain GICR registers. Newer Chromebooks should fix this issue and we may be able to do firmware updates for old Chromebooks. At the moment, the only known issue with these Chromebooks is that we can't enable "pseudo NMIs" since the priority register can be lost. Enabling "pseudo NMIs" on Chromebooks with the problematic firmware causes crashes and freezes. Let's detect devices with this problem and then disable "pseudo NMIs" on them. We'll detect the problem by looking for the presence of the "mediatek,broken-save-restore-fw" property in the GIC device tree node. Any devices with fixed firmware will not have this property. Our detection plan works because we never bake a Chromebook's device tree into firmware. Instead, device trees are always bundled with the kernel. We'll update the device trees of all affected Chromebooks and then we'll never enable "pseudo NMI" on a kernel that is bundled with old device trees. When a firmware update is shipped that fixes this issue it will know to patch the device tree to remove the property. In order to make this work, the quick detection mechanism of the GICv3 code is extended to be able to look for properties in addition to looking at "compatible". Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230515131353.v2.2.I88dc0a0eb1d9d537de61604cd8994ecc55c0cac1@changeid
| | * | | | dt-bindings: interrupt-controller: arm,gic-v3: Add quirk for Mediatek SoCs ↵Douglas Anderson2023-05-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | w/ broken FW When trying to turn on the "pseudo NMI" kernel feature in Linux, it was discovered that all Mediatek-based Chromebooks that ever shipped (at least ones with GICv3) had a firmware bug where they wouldn't save certain GIC "GICR" registers properly. If a processor ever entered a suspend/idle mode where the GICR registers lost state then they'd be reset to their default state. As a result of the bug, if you try to enable "pseudo NMIs" on the affected devices then certain interrupts will unexpectedly get promoted to be "pseudo NMIs" and cause crashes / freezes / general mayhem. ChromeOS is looking to start turning on "pseudo NMIs" in production to make crash reports more actionable. To do so, we will release firmware updates for at least some of the affected Mediatek Chromebooks. However, even when we update the firmware of a Chromebook it's always possible that a user will end up booting with old firmware. We need to be able to detect when we're running with firmware that will crash and burn if pseudo NMIs are enabled. The current plan is: * Update the device trees of all affected Chromebooks to include the 'mediatek,broken-save-restore-fw' property. The kernel can use this to know not to enable certain features like "pseudo NMI". NOTE: device trees for Chromebooks are never baked into the firmware but are bundled with the kernel. A kernel will never be configured to use "pseudo NMIs" and be bundled with an old device tree. * When we get a fixed firmware for one of these Chromebooks, it will patch the device tree to remove this property. For some details, you can also see the public bug <https://issuetracker.google.com/281831288> Reviewed-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230515131353.v2.1.Iabe67a827e206496efec6beb5616d5a3b99c1e65@changeid
* | | | | | Merge tag 'mips-fixes_6.4_1' of ↵Linus Torvalds2023-05-284-16/+26
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux Pull MIPS fixes from Thomas Bogendoerfer: - fixes to get alchemy platform back in shape - fix for initrd detection * tag 'mips-fixes_6.4_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: mips: Move initrd_start check after initrd address sanitisation. MIPS: Alchemy: fix dbdma2 MIPS: Restore Au1300 support MIPS: unhide PATA_PLATFORM
| * | | | | | mips: Move initrd_start check after initrd address sanitisation.Liviu Dudau2023-05-231-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PAGE_OFFSET is technically a virtual address so when checking the value of initrd_start against it we should make sure that it has been sanitised from the values passed by the bootloader. Without this change, even with a bootloader that passes correct addresses for an initrd, we are failing to load it on MT7621 boards, for example. Signed-off-by: Liviu Dudau <liviu@dudau.co.uk> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
| * | | | | | MIPS: Alchemy: fix dbdma2Manuel Lauss2023-05-231-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Various fixes for the Au1200/Au1550/Au1300 DBDMA2 code: - skip cache invalidation if chip has working coherency circuitry. - invalidate KSEG0-portion of the (physical) data address. - force the dma channel doorbell write out to bus immediately with a sync. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
| * | | | | | MIPS: Restore Au1300 supportManuel Lauss2023-05-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Au1300, at least the one I have to test, uses the NetLogic vendor ID, but commit 95b8a5e0111a ("MIPS: Remove NETLOGIC support") also dropped Au1300 detection. Restore Au1300 detection. Tested on DB1300 with Au1380 chip. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
| * | | | | | MIPS: unhide PATA_PLATFORMManuel Lauss2023-05-231-0/+1
| |/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Alchemy DB1200/DB1300 boards can use the pata_platform driver. Unhide the config entry in all of MIPS. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
* | | | | | Merge tag 'powerpc-6.4-3' of ↵Linus Torvalds2023-05-281-0/+6
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fix from Michael Ellerman: - Reinstate ARCH_FORCE_MAX_ORDER ranges to fix various breakage * tag 'powerpc-6.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/mm: Reinstate ARCH_FORCE_MAX_ORDER ranges
| * | | | | | powerpc/mm: Reinstate ARCH_FORCE_MAX_ORDER rangesMichael Ellerman2023-05-211-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 1e8fed873e74 ("powerpc: drop ranges for definition of ARCH_FORCE_MAX_ORDER") removed the limits on the possible values for ARCH_FORCE_MAX_ORDER. However removing the ranges entirely causes some common work flows to break. For example building a defconfig (which uses 64K pages), changing the page size to 4K, and rebuilding used to work, because ARCH_FORCE_MAX_ORDER would be clamped to 12 by the ranges. With the ranges removed it creates a kernel that builds but crashes at boot: kernel BUG at mm/huge_memory.c:470! Oops: Exception in kernel mode, sig: 5 [#1] ... NIP hugepage_init+0x9c/0x278 LR do_one_initcall+0x80/0x320 Call Trace: do_one_initcall+0x80/0x320 kernel_init_freeable+0x304/0x3ac kernel_init+0x30/0x1a0 ret_from_kernel_user_thread+0x14/0x1c The reasoning for removing the ranges was that some of the values were too large. So take that into account and limit the maximums to 10 which is the default max, except for the 4K case which uses 12. Fixes: 1e8fed873e74 ("powerpc: drop ranges for definition of ARCH_FORCE_MAX_ORDER") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230519113806.370635-1-mpe@ellerman.id.au
* | | | | | | Merge tag 'for-linus-6.4-rc4-tag' of ↵Linus Torvalds2023-05-275-12/+21
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fixes from Juergen Gross: - a double free fix in the Xen pvcalls backend driver - a fix for a regression causing the MSI related sysfs entries to not being created in Xen PV guests - a fix in the Xen blkfront driver for handling insane input data better * tag 'for-linus-6.4-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: x86/pci/xen: populate MSI sysfs entries xen/pvcalls-back: fix double frees with pvcalls_new_active_socket() xen/blkfront: Only check REQ_FUA for writes
| * | | | | | | x86/pci/xen: populate MSI sysfs entriesMaximilian Heyne2023-05-243-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit bf5e758f02fc ("genirq/msi: Simplify sysfs handling") reworked the creation of sysfs entries for MSI IRQs. The creation used to be in msi_domain_alloc_irqs_descs_locked after calling ops->domain_alloc_irqs. Then it moved into __msi_domain_alloc_irqs which is an implementation of domain_alloc_irqs. However, Xen comes with the only other implementation of domain_alloc_irqs and hence doesn't run the sysfs population code anymore. Commit 6c796996ee70 ("x86/pci/xen: Fixup fallout from the PCI/MSI overhaul") set the flag MSI_FLAG_DEV_SYSFS for the xen msi_domain_info but that doesn't actually have an effect because Xen uses it's own domain_alloc_irqs implementation. Fix this by making use of the fallback functions for sysfs population. Fixes: bf5e758f02fc ("genirq/msi: Simplify sysfs handling") Signed-off-by: Maximilian Heyne <mheyne@amazon.de> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20230503131656.15928-1-mheyne@amazon.de Signed-off-by: Juergen Gross <jgross@suse.com>
| * | | | | | | xen/pvcalls-back: fix double frees with pvcalls_new_active_socket()Dan Carpenter2023-05-241-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the pvcalls_new_active_socket() function, most error paths call pvcalls_back_release_active(fedata->dev, fedata, map) which calls sock_release() on "sock". The bug is that the caller also frees sock. Fix this by making every error path in pvcalls_new_active_socket() release the sock, and don't free it in the caller. Fixes: 5db4d286a8ef ("xen/pvcalls: implement connect command") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/e5f98dc2-0305-491f-a860-71bbd1398a2f@kili.mountain Signed-off-by: Juergen Gross <jgross@suse.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 11:22:39 +0100