aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-08-05can: kvaser_usb: leaf: Assign correct timestamp_freq for ↵Jimmy Assarsson1-3/+3
kvaser_usb_leaf_imx_dev_cfg_{16,24,32}mhz Assign correct timestamp_freq to kvaser_usb_leaf_imx_dev_cfg_{16,24,32}mhz. Since the driver didn't utilize the value, this didn't cause any problems. Signed-off-by: Jimmy Assarsson <[email protected]> Reviewed-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05can: kvaser_usb: leaf: Add struct for Tx ACK commandsJimmy Assarsson1-1/+9
Add, struct leaf_cmd_tx_acknowledge, for Tx ACK commands received from leaf devices (M32C and leafimx28). Signed-off-by: Jimmy Assarsson <[email protected]> Reviewed-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05can: kvaser_usb: hydra: Set hardware timestamp on transmitted packetsJimmy Assarsson1-1/+4
Set hardware timestamp on transmitted packets. Signed-off-by: Jimmy Assarsson <[email protected]> Reviewed-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05can: kvaser_usb: hydra: Add struct for Tx ACK commandsJimmy Assarsson1-2/+17
Add, struct kvaser_cmd_tx_ack, for standard Tx ACK commands. Expand kvaser_usb_hydra_ktime_from_cmd() to extract timestamps from both standard and extended Tx ACK commands. Unsupported commands are silently ignored, and 0 is returned. Signed-off-by: Jimmy Assarsson <[email protected]> Reviewed-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05can: kvaser_usb: hydra: kvaser_usb_hydra_ktime_from_rx_cmd: Drop {rx_} in ↵Jimmy Assarsson1-5/+4
function name Rename function, since this function will be used for more than just the rx commands. Signed-off-by: Jimmy Assarsson <[email protected]> Reviewed-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05can: kvaser_usb: Add helper functions to convert device timestamp into ktimeJimmy Assarsson2-6/+28
Add helper function kvaser_usb_ticks_to_ktime() that converts from device ticks to ktime. And kvaser_usb_timestamp{48,64}_to_ktime() that converts from device 48-bit or 64-bit timestamp, to ktime. Signed-off-by: Jimmy Assarsson <[email protected]> Reviewed-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05Merge patch series "can: esd_402_pci: Do cleanup; Add one-shot mode"Marc Kleine-Budde3-45/+53
Stefan Mätje <[email protected]> says: The goal of this patch series is to do some cleanup and also add the support for the one-shot mode before the next patch introduces CAN-FD support for this driver. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05can: esd_402_pci: Add support for one-shot modeStefan Mätje3-4/+11
This patch adds support for one-shot mode. In this mode there happens no automatic retransmission in the case of an arbitration lost error or on any bus error. Signed-off-by: Stefan Mätje <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05can: esd_402_pci: Rename esdACC CTRL register macrosStefan Mätje2-41/+42
Rename macros to use for esdACC CTRL register access to match the internal documentation and to make the macro prefix consistent. - ACC_CORE_OF_CTRL_MODE -> ACC_CORE_OF_CTRL Makes the name match the documentation. - ACC_REG_CONTROL_MASK_MODE_ -> ACC_REG_CTRL_MASK_ ACC_REG_CONTROL_MASK_ -> ACC_REG_CTRL_MASK_ Makes the prefix consistent for macros describing masks in the same register (CTRL). Signed-off-by: Stefan Mätje <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05tools build: Correct bpf fixdep dependenciesBrian Norris3-4/+22
The dependencies in tools/lib/bpf/Makefile are incorrect. Before we recurse to build $(BPF_IN_STATIC), we need to build its 'fixdep' executable. I can't use the usual shortcut from Makefile.include: <target>: <sources> fixdep because its 'fixdep' target relies on $(OUTPUT), and $(OUTPUT) differs in the parent 'make' versus the child 'make' -- so I imitate it via open-coding. I tweak a few $(MAKE) invocations while I'm at it, because 1. I'm adding a new recursive make; and 2. these recursive 'make's print spurious lines about files that are "up to date" (which isn't normally a feature in Kbuild subtargets) or "jobserver not available" (see [1]) I also need to tweak the assignment of the OUTPUT variable, so that relative path builds work. For example, for 'make tools/lib/bpf', OUTPUT is unset, and is usually treated as "cwd" -- but recursive make will change cwd and so OUTPUT has a new meaning. For consistency, I ensure OUTPUT is always an absolute path. And $(Q) gets a backup definition in tools/build/Makefile.include, because Makefile.include is sometimes included without tools/build/Makefile, so the "quiet command" stuff doesn't actually work consistently without it. After this change, top-level builds result in an empty grep result from: $ grep 'cannot find fixdep' $(find tools/ -name '*.cmd') [1] https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html If we're not using $(MAKE) directly, then we need to use more '+'. Signed-off-by: Brian Norris <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Acked-by: Jiri Olsa <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Richter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-08-05tools build: Avoid circular .fixdep-in.o.cmd issuesBrian Norris2-12/+2
The 'fixdep' tool is used to post-process dependency files for various reasons, and it runs after every object file generation command. This even includes 'fixdep' itself. In Kbuild, this isn't actually a problem, because it uses a single command to generate fixdep (a compile-and-link command on fixdep.c), and afterward runs the fixdep command on the accompanying .fixdep.cmd file. In tools/ builds (which notably is maintained separately from Kbuild), fixdep is generated in several phases: 1. fixdep.c -> fixdep-in.o 2. fixdep-in.o -> fixdep Thus, fixdep is not available in the post-processing for step 1, and instead, we generate .cmd files that look like: ## from tools/objtool/libsubcmd/.fixdep.o.cmd # cannot find fixdep (/path/to/linux/tools/objtool/libsubcmd//fixdep) [...] These invalid .cmd files are benign in some respects, but cause problems in others (such as the linked reports). Because the tools/ build system is rather complicated in its own right (and pointedly different than Kbuild), I choose to simply open-code the rule for building fixdep, and avoid the recursive-make indirection that produces the problem in the first place. Signed-off-by: Brian Norris <[email protected]> Acked-by: Jiri Olsa <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Richter <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-08-05tools build: Correct libsubcmd fixdep dependenciesBrian Norris1-1/+1
All built targets need fixdep to be built first, before handling object dependencies [1]. We're missing one such dependency before the libsubcmd target. This resolves .cmd file generation issues such that the following sequence produces many fewer results: $ git clean -xfd tools/ $ make tools/objtool $ grep "cannot find fixdep" $(find tools/objtool -name '*.cmd') In particular, only a buggy tools/objtool/libsubcmd/.fixdep.o.cmd remains, due to circular dependencies of fixdep on itself. Such incomplete .cmd files don't usually cause a direct problem, since they're designed to fail "open", but they can cause some subtle problems that would otherwise be handled by proper fixdep'd dependency files. [2] [1] This problem is better described in commit abb26210a395 ("perf tools: Force fixdep compilation at the start of the build"). I don't apply its solution here, because additional recursive make can be a bit of overkill. [2] Example failure case: cp -arl linux-src linux-src2 cd linux-src2 make O=/path/to/out cd ../linux-src rm -rf ../linux-src2 make O=/path/to/out Previously, we'd see errors like: make[6]: *** No rule to make target '/path/to/linux-src2/tools/include/linux/compiler.h', needed by '/path/to/out/tools/bpf/resolve_btfids/libsubcmd/exec-cmd.o'. Stop. Now, the properly-fixdep'd .cmd files will ignore a missing /path/to/linux-src2/... Signed-off-by: Brian Norris <[email protected]> Acked-by: Jiri Olsa <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Richter <[email protected]> Link: https://lore.kernel.org/all/ZGVi9HbI43R5trN8@bhelgaas/ Link: https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-08-05platform/x86: int3472: make common part a separate moduleArnd Bergmann2-3/+13
Linking an object file into multiple modules is not supported and causes a W=1 warning: scripts/Makefile.build:236: drivers/platform/x86/intel/int3472/Makefile: common.o is added to multiple modules: intel_skl_int3472_discrete intel_skl_int3472_tps68470 Split out the common part here into a separate module to make it more reliable. Fixes: a2f9fbc247ee ("platform/x86: int3472: Split into 2 drivers") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-08-05hid-asus: use hid for brightness control on keyboardLuke D. Jones3-1/+45
On almost all ASUS ROG series laptops the MCU used for the USB keyboard also has a HID packet used for setting the brightness. This is usually the same as the WMI method. But in some laptops the WMI method either is missing or doesn't work, so we should default to the HID control. Signed-off-by: Luke D. Jones <[email protected]> Acked-by: Benjamin Tissoires <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-08-05perf/x86/intel/bts: Fix comment about default perf_event_paranoid settingJames Clark1-3/+0
The default paranoid setting was updated in commit 0161028b7c8a ("perf/core: Change the default paranoia level to 2") so this comment is no longer true. Signed-off-by: James Clark <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2024-08-05perf/x86/intel/uncore: Use D0:F0 as a default deviceZhenyu Wang1-0/+4
Some uncore PMON registers are located in the MMIO space of the Host Bridge and DRAM Controller device, which is located at D0:F0 for Tiger Lake and later client generation. Use D0:F0 as a default device. So it doesn't need to keep adding the complete Device ID list for each generation anymore. Signed-off-by: Zhenyu Wang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Kan Liang <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05perf/x86/intel/uncore: Add LNL uncore iMC freerunning supportZhenyu Wang1-0/+1
LNL uncore imc freerunning counters keep same as previous HW. Signed-off-by: Zhenyu Wang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Kan Liang <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05perf/x86/intel/uncore: Add Lunar Lake supportKan Liang3-0/+141
The uncore subsystem for Lunar Lake is similar to the previous Meteor Lake. The uncore PerfMon registers are located at both MSR and MMIO space. The ARB and iMC are kept. There is no difference from the Meteor Lake. Move the global control initialization to the first box of the CBOX. The sNCU is moved to the MMIO space. The HBO is newly added and only be accessed from the MMIO space. Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05perf/x86/intel/uncore: Factor out common MMIO init and ops functionsKan Liang1-17/+30
Some uncore PMON registers are located in the MMIO space. For the client machine, the MMIO space is usually located at D0:F0 but in a different BAR. For example, some uncore PMON registers are located in the SAF BAR, not the MCHBAR in the Lunar Lake. The current __uncore_imc_init_box() hard code the BAR information. Factor out the uncore_get_box_mmio_addr() which uses the BAR information as a parameter. The only change is the error output message. The hardcode name 'MCHBAR' is replaced by the offset of a BAR. Add a new macro, MMIO_UNCORE_COMMON_OPS(), since the MMIO ops functions are usually the same among different generations. Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05perf/x86/intel/uncore: Add Arrow Lake supportKan Liang1-0/+3
>From the perspective of the uncore PMU, the Arrow Lake is the same as the previous Meteor Lake. The only difference is the event list, which will be supported in the perf tool later. Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05cleanup: Add usage and style documentationDan Williams3-0/+145
When proposing that PCI grow some new cleanup helpers for pci_dev_put() and pci_dev_{lock,unlock} [1], Bjorn had some fundamental questions about expectations and best practices. Upon reviewing an updated changelog with those details he recommended adding them to documentation in the header file itself. Add that documentation and link it into the rendering for Documentation/core-api/. Signed-off-by: Dan Williams <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/171175585714.2192972.12661675876300167762.stgit@dwillia2-xfh.jf.intel.com
2024-08-05lockdep: suggest the fix for "lockdep bfs error:-1" on print_bfs_bugLuis Claudio R. Goncalves1-0/+3
When lockdep fails while performing the Breadth-first-search operation due to lack of memory, hint that increasing the value of the config switch LOCKDEP_CIRCULAR_QUEUE_BITS should fix the warning. Preface the scary backtrace with the suggestion: [ 163.849242] Increase LOCKDEP_CIRCULAR_QUEUE_BITS to avoid this warning: [ 163.849248] ------------[ cut here ]------------ [ 163.849250] lockdep bfs error:-1 [ 163.849263] WARNING: CPU: 24 PID: 2454 at kernel/locking/lockdep.c:2091 print_bfs_bug+0x27/0x40 ... Signed-off-by: Luis Claudio R. Goncalves <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Boqun Feng <[email protected]> Reviewed-by: Waiman Long <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2024-08-05Merge patch series "can: fsl,flexcan: add imx95 wakeup"Marc Kleine-Budde3-10/+46
The flexcan in iMX95 is not compatible with imx93 because wakeup method is difference. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05can: flexcan: add wakeup support for imx95Haibo Chen2-7/+45
iMX95 defines a bit in GPR that sets/unsets the IPG_STOP signal to the FlexCAN module, controlling its entry into STOP mode. Wakeup should work even if FlexCAN is in STOP mode. Due to iMX95 architecture design, the A-Core cannot access GPR; only the system manager (SM) can configure GPR. To support the wakeup feature, follow these steps: - For suspend: 1) During Linux suspend, when CAN suspends, do nothing for GPR and keep CAN-related clocks on. 2) In ATF, check whether CAN needs to support wakeup; if yes, send a request to SM through the SCMI protocol. 3) In SM, configure the GPR and unset IPG_STOP. 4) A-Core suspends. - For wakeup and resume: 1) A-Core wakeup event arrives. 2) In SM, deassert IPG_STOP. 3) Linux resumes. Add a new fsl_imx95_devtype_data and FLEXCAN_QUIRK_SETUP_STOP_MODE_SCMI to reflect this. Reviewed-by: Han Xu <[email protected]> Signed-off-by: Haibo Chen <[email protected]> Reviewed-by: Vincent Mailhol <[email protected]> Signed-off-by: Frank Li <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05dt-bindings: can: fsl,flexcan: move fsl,imx95-flexcan standaloneHaibo Chen1-3/+1
The flexcan in iMX95 is not compatible with imx93 because wakeup method is difference. Make fsl,imx95-flexcan not fallback to fsl,imx93-flexcan. Reviewed-by: Han Xu <[email protected]> Signed-off-by: Haibo Chen <[email protected]> Reviewed-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Frank Li <[email protected]> Acked-by: Rob Herring (Arm) <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-08-05perf mem: Update documentation for new optionsNamhyung Kim1-31/+63
Add a common options section and move some items to the section. Also add description of new options to report options. Suggested-by: Ian Rogers <[email protected]> Reviewed-by: Ian Rogers <[email protected]> Signed-off-by: Namhyung Kim <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2024-08-05media: siano: Simplify smscore_load_firmware_from_fileRicardo Ribalda2-14/+5
The function is never called with a loadfirmware_handler, so we can remove some dead code. We can also use this as a excuse to remove some unused type definitions. This fixes the following smatch warning: drivers/media/common/siano/smscoreapi.c:1172 smscore_load_firmware_from_file() error: we previously assumed 'loadfirmware_handler' could be null (see line 1150) Signed-off-by: Ricardo Ribalda <[email protected]> Reported-by: Hans Verkuil <[email protected]> Closes: https://lore.kernel.org/linux-media/[email protected]/T/#t Signed-off-by: Hans Verkuil <[email protected]>
2024-08-05leds: lm3601x: Reset LED controller during probeJack Chen1-0/+4
LED controller should be reset during initialization to avoid abnormal behaviors. For example, when power to SoC is recycled but power to LED controller is not, LED controller should not presume to be in original state. Signed-off-by: Jack Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]>
2024-08-05timekeeping: Fix bogus clock_was_set() invocation in do_adjtimex()Thomas Gleixner1-1/+1
The addition of the bases argument to clock_was_set() fixed up all call sites correctly except for do_adjtimex(). This uses CLOCK_REALTIME instead of CLOCK_SET_WALL as argument. CLOCK_REALTIME is 0. As a result the effect of that clock_was_set() notification is incomplete and might result in timers expiring late because the hrtimer code does not re-evaluate the affected clock bases. Use CLOCK_SET_WALL instead of CLOCK_REALTIME to tell the hrtimers code which clock bases need to be re-evaluated. Fixes: 17a1b8826b45 ("hrtimer: Add bases argument to clock_was_set()") Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/all/877ccx7igo.ffs@tglx
2024-08-05ntp: Safeguard against time_constant overflowJustin Stitt1-3/+2
Using syzkaller with the recently reintroduced signed integer overflow sanitizer produces this UBSAN report: UBSAN: signed-integer-overflow in ../kernel/time/ntp.c:738:18 9223372036854775806 + 4 cannot be represented in type 'long' Call Trace: handle_overflow+0x171/0x1b0 __do_adjtimex+0x1236/0x1440 do_adjtimex+0x2be/0x740 The user supplied time_constant value is incremented by four and then clamped to the operating range. Before commit eea83d896e31 ("ntp: NTP4 user space bits update") the user supplied value was sanity checked to be in the operating range. That change removed the sanity check and relied on clamping after incrementing which does not work correctly when the user supplied value is in the overflow zone of the '+ 4' operation. The operation requires CAP_SYS_TIME and the side effect of the overflow is NTP getting out of sync. Similar to the fixups for time_maxerror and time_esterror, clamp the user space supplied value to the operating range. [ tglx: Switch to clamping ] Fixes: eea83d896e31 ("ntp: NTP4 user space bits update") Signed-off-by: Justin Stitt <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Miroslav Lichvar <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/all/[email protected] Closes: https://github.com/KSPP/linux/issues/352
2024-08-05ntp: Clamp maxerror and esterror to operating rangeJustin Stitt1-2/+2
Using syzkaller alongside the newly reintroduced signed integer overflow sanitizer spits out this report: UBSAN: signed-integer-overflow in ../kernel/time/ntp.c:461:16 9223372036854775807 + 500 cannot be represented in type 'long' Call Trace: handle_overflow+0x171/0x1b0 second_overflow+0x2d6/0x500 accumulate_nsecs_to_secs+0x60/0x160 timekeeping_advance+0x1fe/0x890 update_wall_time+0x10/0x30 time_maxerror is unconditionally incremented and the result is checked against NTP_PHASE_LIMIT, but the increment itself can overflow, resulting in wrap-around to negative space. Before commit eea83d896e31 ("ntp: NTP4 user space bits update") the user supplied value was sanity checked to be in the operating range. That change removed the sanity check and relied on clamping in handle_overflow() which does not work correctly when the user supplied value is in the overflow zone of the '+ 500' operation. The operation requires CAP_SYS_TIME and the side effect of the overflow is NTP getting out of sync. Miroslav confirmed that the input value should be clamped to the operating range and the same applies to time_esterror. The latter is not used by the kernel, but the value still should be in the operating range as it was before the sanity check got removed. Clamp them to the operating range. [ tglx: Changed it to clamping and included time_esterror ] Fixes: eea83d896e31 ("ntp: NTP4 user space bits update") Signed-off-by: Justin Stitt <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Miroslav Lichvar <[email protected]> Link: https://lore.kernel.org/all/[email protected] Closes: https://github.com/KSPP/linux/issues/354
2024-08-05x86/mm/ident_map: Use gbpages only where full GB page should be mapped.Steve Wahl1-5/+18
When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. Signed-off-by: Steve Wahl <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Pavin Joseph <[email protected]> Tested-by: Sarah Brofeldt <[email protected]> Tested-by: Eric Hagberg <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-05x86/kexec: Add EFI config table identity mapping for kexec kernelTao Liu1-0/+27
A kexec kernel boot failure is sometimes observed on AMD CPUs due to an unmapped EFI config table array. This can be seen when "nogbpages" is on the kernel command line, and has been observed as a full BIOS reboot rather than a successful kexec. This was also the cause of reported regressions attributed to Commit 7143c5f4cf20 ("x86/mm/ident_map: Use gbpages only where full GB page should be mapped.") which was subsequently reverted. To avoid this page fault, explicitly include the EFI config table array in the kexec identity map. Further explanation: The following 2 commits caused the EFI config table array to be accessed when enabling sev at kernel startup. commit ec1c66af3a30 ("x86/compressed/64: Detect/setup SEV/SME features earlier during boot") commit c01fce9cef84 ("x86/compressed: Add SEV-SNP feature detection/setup") This is in the code that examines whether SEV should be enabled or not, so it can even affect systems that are not SEV capable. This may result in a page fault if the EFI config table array's address is unmapped. Since the page fault occurs before the new kernel establishes its own identity map and page fault routines, it is unrecoverable and kexec fails. Most often, this problem is not seen because the EFI config table array gets included in the map by the luck of being placed at a memory address close enough to other memory areas that *are* included in the map created by kexec. Both the "nogbpages" command line option and the "use gpbages only where full GB page should be mapped" change greatly reduce the chance of being included in the map by luck, which is why the problem appears. Signed-off-by: Tao Liu <[email protected]> Signed-off-by: Steve Wahl <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Pavin Joseph <[email protected]> Tested-by: Sarah Brofeldt <[email protected]> Tested-by: Eric Hagberg <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/all/[email protected]
2024-08-05arm64: dts: ti: k3-am62-verdin-dahlia: Keep CTRL_SLEEP_MOCI# regulator onFrancesco Dolcini2-28/+0
This reverts commit 3935fbc87ddebea5439f3ab6a78b1e83e976bf88. CTRL_SLEEP_MOCI# is a signal that is defined for all the SoM implementing the Verdin family specification, this signal is supposed to control the power enable in the carrier board when the system is in deep sleep mode. However this is not possible with Texas Instruments AM62 SoC, IOs output buffer is disabled in deep sleep and IOs are in tri-state mode. Given that we cannot properly control this pin, force it to be always high to minimize potential issues. Fixes: 3935fbc87dde ("arm64: dts: ti: k3-am62-verdin-dahlia: support sleep-moci") Cc: <[email protected]> Link: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1361669/am625-gpio-output-state-in-deep-sleep/5244802 Signed-off-by: Francesco Dolcini <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]>
2024-08-05drm/mediatek: Set sensible cursor width/height values to fix crashAngeloGioacchino Del Regno1-2/+2
Hardware-speaking, there is no feature-reduced cursor specific plane, so this driver reserves the last all Overlay plane as a Cursor plane, but sets the maximum cursor width/height to the maximum value that the full overlay plane can use. While this could be ok, it raises issues with common userspace using libdrm (especially Mutter, but other compositors too) which will crash upon performing allocations and/or using said cursor plane. Reduce the maximum width/height for the cursor to 512x512 pixels, value taken from IGT's maximum cursor size test, which succeeds. Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Fei Shao <[email protected]> Tested-by: Fei Shao <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2024-08-05ALSA: line6: Fix racy access to midibufTakashi Iwai1-0/+5
There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here). This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races. Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2024-08-05drm/omap: add CONFIG_MMU dependencyArnd Bergmann1-0/+1
Compile-testing with CONFIG_MMU disabled causes a link error in omapdrm: arm-linux-gnueabi-ld: drivers/gpu/drm/omapdrm/omap_gem.o: in function `omap_gem_fault_2d': omap_gem.c:(.text+0x36e): undefined reference to `vmf_insert_mixed' arm-linux-gnueabi-ld: drivers/gpu/drm/omapdrm/omap_gem.o: in function `omap_gem_fault': omap_gem.c:(.text+0x74a): undefined reference to `vmf_insert_mixed' Avoid this by adding a Kconfig dependency. Fixes: dc6fcaaba5a5 ("drm/omap: Allow build with COMPILE_TEST=y") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-08-05ASoC: cs-amp-lib: Fix NULL pointer crash if efi.get_variable is NULLRichard Fitzgerald1-1/+1
Call efi_rt_services_supported() to check that efi.get_variable exists before calling it. Signed-off-by: Richard Fitzgerald <[email protected]> Fixes: 1cad8725f2b9 ("ASoC: cs-amp-lib: Add helpers for factory calibration data") Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-05ASoC: cs35l56: Stop creating ALSA controls for firmware coefficientsSimon Trimmer1-0/+11
A number of laptops have gone to market with old firmware versions that export controls that have since been hidden, but we can't just install a newer firmware because the firmware for each product is customized and qualified by the OEM. The issue is that alsactl save and restore has no idea what controls are good to persist which can lead to misconfiguration. There is no reason that the UCM or user should need to interact with any of the ALSA controls for the firmware coefficients so they can be removed entirely. Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Signed-off-by: Simon Trimmer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-05ASoC: wm_adsp: Add control_add callback and export wm_adsp_control_add()Simon Trimmer2-3/+17
The callback allows codec drivers to affect how firmware coefficients are added as controls. For example a codec driver may selectively add controls by choosing to call wm_adsp_control_add() based on some filter logic. Signed-off-by: Simon Trimmer <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-08-05net: netconsole: Fix MODULE_AUTHOR formatBreno Leitao1-1/+1
Update the MODULE_AUTHOR for netconsole, according to the format, as stated in module.h: use "Name <email>" or just "Name" Suggested-by: Stephen Hemminger <[email protected]> Signed-off-by: Breno Leitao <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-05net: phy: vitesse: implement downshift in vsc73xx physPawel Dembicki1-0/+90
This commit implements downshift feature in vsc73xx family phys. By default downshift was enabled with maximum tries. Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: Pawel Dembicki <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-05net: skbuff: sprinkle more __GFP_NOWARN on ingress allocsJakub Kicinski1-6/+9
build_skb() and frag allocations done with GFP_ATOMIC will fail in real life, when system is under memory pressure, and there's nothing we can do about that. So no point printing warnings. Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-08-05pmdomain: Merge branch fixes into nextUlf Hansson1-5/+0
Merge the pmdomain fixes for v6.11-rc[n] into the next branch, to allow them to get tested together with the new changes that are targeted for v6.12. Signed-off-by: Ulf Hansson <[email protected]>
2024-08-05cpuidle: psci: Enable the hierarchical topology for s2idle on PREEMPT_RTUlf Hansson1-7/+6
To enable the domain-idle-states to be used during s2idle on a PREEMPT_RT based configuration, let's allow the re-assignment of the ->enter_s2idle() callback to psci_enter_s2idle_domain_idle_state(). Similar to s2ram, let's leave the support for CPU hotplug outside PREEMPT_RT, as it's depending on using runtime PM. For s2idle, this means that an offline CPU's PM domain will remain powered-on. In practise this may lead to that a shallower idle-state than necessary gets selected, which shouldn't be an issue (besides wasting power). Signed-off-by: Ulf Hansson <[email protected]> Tested-by: Raghavendra Kakarla <[email protected]> # qcm6490 with PREEMPT_RT set Acked-by: Sebastian Andrzej Siewior <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05cpuidle: psci: Enable the hierarchical topology for s2ram on PREEMPT_RTUlf Hansson1-5/+15
The hierarchical PM domain topology are currently disabled on a PREEMPT_RT based configuration. As a first step to enable it to be used, let's try to attach the CPU devices to their PM domains on PREEMPT_RT. In this way the syscore ops becomes available, allowing the PM domain topology to be managed during s2ram. For the moment let's leave the support for CPU hotplug outside PREEMPT_RT, as it's depending on using runtime PM. For s2ram, this isn't a problem as all CPUs are managed via the syscore ops. Signed-off-by: Ulf Hansson <[email protected]> Tested-by: Raghavendra Kakarla <[email protected]> # qcm6490 with PREEMPT_RT set Acked-by: Sebastian Andrzej Siewior <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05cpuidle: psci: Drop redundant assignment of CPUIDLE_FLAG_RCU_IDLEUlf Hansson1-1/+0
When using the hierarchical topology and PSCI OSI-mode we may end up overriding the deepest idle-state's ->enter|enter_s2idle() callbacks, but there is no point to also re-assign the CPUIDLE_FLAG_RCU_IDLE for the idle-state in question, as that has already been set when parsing the states from DT. See init_state_node(). Signed-off-by: Ulf Hansson <[email protected]> Tested-by: Raghavendra Kakarla <[email protected]> # qcm6490 with PREEMPT_RT set Acked-by: Sebastian Andrzej Siewior <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05cpuidle: psci-domain: Enable system-wide suspend on PREEMPT_RTUlf Hansson1-3/+7
The domain-idle-states are currently disabled on a PREEMPT_RT based configuration for the cpuidle-psci-domain. To enable them to be used for system-wide suspend and in particular during s2idle, let's set the GENPD_FLAG_RPM_ALWAYS_ON instead of GENPD_FLAG_ALWAYS_ON for the corresponding genpd provider. In this way, the runtime PM path remains disabled in genpd for its attached devices, while powering-on/off the PM domain during system-wide suspend becomes allowed. Signed-off-by: Ulf Hansson <[email protected]> Tested-by: Raghavendra Kakarla <[email protected]> # qcm6490 with PREEMPT_RT set Acked-by: Sebastian Andrzej Siewior <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05pmdomain: core: Use dev_name() instead of kobject_get_path() in debugfsUlf Hansson1-20/+3
Using kobject_get_path() means a dynamic memory allocation gets done, which doesn't work on a PREEMPT_RT based configuration while holding genpd's raw spinlock. To fix the problem, let's convert into using the simpler dev_name(). This means the information about the path doesn't get presented in debugfs, but hopefully this shouldn't be an issue. Signed-off-by: Ulf Hansson <[email protected]> Tested-by: Raghavendra Kakarla <[email protected]> # qcm6490 with PREEMPT_RT set Acked-by: Sebastian Andrzej Siewior <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-08-05pmdomain: core: Don't hold the genpd-lock when calling dev_pm_domain_set()Ulf Hansson1-2/+3
There is no need to hold the genpd-lock, while assigning the dev->pm_domain. In fact, it becomes a problem on a PREEMPT_RT based configuration as the genpd-lock may be a raw spinlock, while the lock acquired through the call to dev_pm_domain_set() is a regular spinlock. To fix the problem, let's simply move the calls to dev_pm_domain_set() outside the genpd-lock. Signed-off-by: Ulf Hansson <[email protected]> Tested-by: Raghavendra Kakarla <[email protected]> # qcm6490 with PREEMPT_RT set Acked-by: Sebastian Andrzej Siewior <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.