* printk cleanups in memblock and numa_memblks
* update kernel-doc for MEMBLOCK_RSRV_NOINIT to be more accurate and
detailed
-----BEGIN PGP SIGNATURE-----
iQFEBAABCgAuFiEEeOVYVaWZL5900a/pOQOGJssO/ZEFAmiv6AwQHHJwcHRAa2Vy
bmVsLm9yZwAKCRA5A4Ymyw79kR4SB/4u5L2tlpZaM2PzMqHVrdXDWNs7ntmRr97e
BA0fsIoSVtcqAEUkXiG+2x9cBuzJuiGOkSKOu28u7567zQji8rX3IAHaR1Uw1K+0
2mmzC3QxMjM6g7g310uA+agMAQlZne6ppiCEqyNnng3Uda8zZudL8NojOjtr3rJi
+ebiy5/2KR9DDV+758ZCQ4MmBGqnS5YLXu+xXbmnsPw7AqujSADskvrTLugii5qp
khQwTEX9foUR9kwAsrHPmqW560m2oWNf4eh3uxWtVxuCtbAnqC6uxVnaORW7UKaB
gLcOCinvBE6Le4sggJQvr6NpAJ1HcrXzA61CfBV9UUXNXb9obxDO
=xp5F
-----END PGP SIGNATURE-----
Merge tag 'fixes-2025-08-28' of git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock
Pull memblock fixes from Mike Rapoport:
- printk cleanups in memblock and numa_memblks
- update kernel-doc for MEMBLOCK_RSRV_NOINIT to be more accurate and
detailed
* tag 'fixes-2025-08-28' of git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock:
memblock: fix kernel-doc for MEMBLOCK_RSRV_NOINIT
mm: numa,memblock: Use SZ_1M macro to denote bytes to MB conversion
mm/numa_memblks: Use pr_debug instead of printk(KERN_DEBUG)
less restrictive with the formats it accepts. A fix for amdgpu to pin
vmapped dma-buf, and a revert for tegra for a regression in the dma-buf
/ GEM code.
-----BEGIN PGP SIGNATURE-----
iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCaK/35wAKCRAnX84Zoj2+
duAqAX9IIovrilRa/6169LIVEFbI3NfhWJorjDp5GB6jEilKxu6LBWFNYmyiLLwI
0+c4WiEBfAk/jHkpO4fdtAbIczic5d1WdSlO3VipH6w8WMDca1A3DcDM4BXO2x5Z
74f5CctKSA==
=PWA/
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2025-08-28' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
Several nouveau fixes to remove unused code, fix an error path and be
less restrictive with the formats it accepts. A fix for amdgpu to pin
vmapped dma-buf, and a revert for tegra for a regression in the dma-buf
/ GEM code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@redhat.com>
Link: https://lore.kernel.org/r/20250828-hypersonic-colorful-squirrel-64f04b@houat
- Merge two CONFIG_POWERPC64_CPU entries in Kconfig.cputype
- Replace extra-y to always-y in Makefile
- Cleanup to use dev_fwnode helper
- Fix misleading comment in kvmppc_prepare_to_enter()
- misc cleanup and fixes
Thanks to: Amit Machhiwal, Andrew Donnellan, Christophe Leroy, Gautam Menghani,
Jiri Slaby (SUSE), Masahiro Yamada, Shrikanth Hegde, Stephen Rothwell, Venkat
Rao Bagalkote, Xichao Zhao
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEqX2DNAOgU8sBX3pRpnEsdPSHZJQFAmiv5qEACgkQpnEsdPSH
ZJQeEA/+NahRLWuQM/dikXUo/Nje0/VSuQn4t/Yw8SUpqteBmGw84r8VZkxY0yu4
9Mmvi/7flStL59Nede94dEO7TJvOhcn7OD2X0gQpQl5ZaHD3z8oGmEnZ023tUin1
kzuEtsRTepU2ELEpqJCGzGNxV+Sxv+pqP7Okg65/u9HCUaq/1e89J5Km4rw4svx4
LLcs+FUAobbI7LV6SeKr877Ujp0dsLkSwvC/g4aqgszm4HbJi8WiD8QfTJYmzi6L
f4VzCzl+ox1ml+IpQKbQfjbAiB4MCIHc1mMCuK+A4VFmqGnlqk4/oeUmrNanRwSR
tDpeTka0HGO6dOIuf/G/Bc9bf23+dvKrH6NDpz4rI2mP88akedVMpLV9SmQXLZWy
UEnLCf4Ic3DeVGvlwlXd6C+0wAqjqu3ud9I640mlJhGAdPJ+NR0XHDFKP3hgxh7o
H8BQLBqm2CRDYOGFf8veY1u7EBsCTC0pjsvNrZa/IFzjOmZQJXwA4hG5sKkau3YG
yOMzylhjpSPOPl85jaKS5XrIzXLYhFgZ13jqf3NNx6Ydmrg89tR+3RGvqG+H0pi2
s/WQ+84Rw9hqzT7qOAQhUS1H7YHUOreeRrLZUVBl2SNXEh7Vw8ew1GkQJE7yMgsC
8gfrnnomxaMtg0GnxdQEm7pb0rmBujWCc1QBA6pZdgDhE+M8U0Y=
=+F44
-----END PGP SIGNATURE-----
Merge tag 'powerpc-6.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Madhavan Srinivasan:
- Merge two CONFIG_POWERPC64_CPU entries in Kconfig.cputype
- Replace extra-y to always-y in Makefile
- Cleanup to use dev_fwnode helper
- Fix misleading comment in kvmppc_prepare_to_enter()
- misc cleanup and fixes
Thanks to Amit Machhiwal, Andrew Donnellan, Christophe Leroy, Gautam
Menghani, Jiri Slaby (SUSE), Masahiro Yamada, Shrikanth Hegde, Stephen
Rothwell, Venkat Rao Bagalkote, and Xichao Zhao
* tag 'powerpc-6.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/boot/install.sh: Fix shellcheck warnings
powerpc/prom_init: Fix shellcheck warnings
powerpc/kvm: Fix ifdef to remove build warning
powerpc: unify two CONFIG_POWERPC64_CPU entries in the same choice block
powerpc: use always-y instead of extra-y in Makefiles
powerpc/64: Drop unnecessary 'rc' variable
powerpc: Use dev_fwnode()
KVM: PPC: Fix misleading interrupts comment in kvmppc_prepare_to_enter()
Amlogic GXL has 4 I2C attached to gpio-periphs. I2C_D is on GPIOX_10/11.
Add the relevant func 3 pinmux per the datasheet for S805X/S905X/S905D.
Fixes: 0f15f500ff ("pinctrl: meson: Add GXL pinctrl definitions")
Signed-off-by: Da Xue <da@libre.computer>
Link: https://lore.kernel.org/20250821233335.1707559-1-da@libre.computer
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When using MMIO with regmap, fast_io is implied. No need to set it
again.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20250813161517.4746-12-wsa+renesas@sang-engineering.com
Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Merge series from Cezary Rojewski <cezary.rojewski@intel.com>:
Set of patches all connected to the machine-board registration process
and the board_selection.c file. Apart from LOC reduction, allows for
multiple cards of the same 'type' e.g.: avs_rt5640, to be present
simultanetously without any workarounds or tricks. The last patch
improves debugability - helps us (the devs) deal with basic I2S-boards
issues out there without forcing the user to constantly switch between
debug-friendly and non-debug options.
--
Initially I wanted to have the first two patches (new implementation and
the follow up cleanup) to be just one patch. However, the git diff, even
with --patience does not look good, at least in my opinion. Decided to
split the changes into two separate patches to make it easy to review
and comment.
As the first two patches carry heaviest load, the summary:
- provide a unified avs_register_board() wrapper for
platform_device_register_data(PLATFORM_DEVID_AUTO). The _AUTO is what
makes every device name unique and prevents any naming conflicts to
occur when matching components <-> cards in runtime
- provide avs_register_board_pdata(), a wrapper one-level above
avs_register_board() that takes all custom parameters in its argument
list so that the initialization of 'struct avs_mach_pdata' does not
need to be repeated in every function like its done today
- make use of the two above to write simpler registration functions:
1. init any interface-type-specific values e.g.: SSP port for I2S
board
2. call avs_register_board_pdata()
3. register the ASoC component with avs_register_xxx_component()
In regard to the last three patches - two are simplifications, no
functional changes just LOC reduction and readability.
The last one is to improve debug-ability, especially when working in the
open field - often we, the devs, find it useful when debugging
production systems to run i2s_test (the debug board) without impacting
the 'real' board e.g.: avs_rt5640. By default i2s_test is empty so a
typical user and their scenarios are not impacted.
Merge series from Qianfeng Rong <rongqianfeng@vivo.com>:
The 'ret' variable usually is used to store returns from some functions,
which return either zero on success or negative error codes on failure.
Storing the negative error codes in unsigned type, doesn't cause an issue
at runtime but it's ugly as pants. Additionally, assigning negative error
codes to unsigned type may trigger a GCC warning when the -Wsign-conversion
flag is enabled.
Change "ret" from u32/unsigned int to int type. No effect on runtime.
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
Current Renesas MSIOF get unknown error when first used.
This patch-set will fixup this issue.
Volodymyr reports that using a Xen DomU as a nested guest (where
HCR_EL2.E2H == 0), ATS12 results in a translation that stops at
the L2's S1, which isn't something you'd normally expects.
Comparing the code against the spec proves to be illuminating,
and suggests that the author of such code must have been tired,
cross-eyed, drunk, or maybe all of the above.
The gist of it is that, apart from HCR_EL2.VM or HCR_EL2.DC being
0, only the use of the EL2&0 translation regime limits the walk
to S1 only, and that we must finish the S2 walk in any other case.
Which solves the above issue, as E2H==0 indicates that ATS12 walks
the EL1&0 translation regime.
Explicitly checking for EL2&0 fixes this.
Reported-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Suggested-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Fixes: be04cebf3e ("KVM: arm64: nv: Add emulation of AT S12E{0,1}{R,W}")
Link: https://lore.kernel.org/r/20250806141707.3479194-2-volodymyr_babchuk@epam.com
Link: https://lore.kernel.org/r/20250809144811.2314038-2-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Fix the rules in tools/testing/selftests/vfio/.gitignore to not ignore
some already tracked files (.gitignore, Makefile, lib/libvfio.mk).
This change should be a no-op, since these files are already tracked by git
and thus git will not ignore updates to them even though they match the
ignore rules in the VFIO selftests .gitignore file.
However, they do generate warnings with W=1, as reported by the kernel test
robot.
$ KBUILD_EXTRA_WARN=1 scripts/misc-check
tools/testing/selftests/vfio/.gitignore: warning: ignored by one of the .gitignore files
tools/testing/selftests/vfio/Makefile: warning: ignored by one of the .gitignore files
tools/testing/selftests/vfio/lib/libvfio.mk: warning: ignored by one of the .gitignore files
Fix this by explicitly un-ignoring the tracked files.
Fixes: 292e9ee22b ("selftests: Create tools/testing/selftests/vfio")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202508280918.rFRyiLEU-lkp@intel.com/
Signed-off-by: David Matlack <dmatlack@google.com>
Link: https://lore.kernel.org/r/20250828185815.382215-1-dmatlack@google.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Add the missing op in the device description to avoid issues with jack
detection.
Fixes: 6b04629ae9 ("ASoC: SOF: Intel: add initial support for WCL")
Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Ajye Huang <ajye_huang@compal.corp-partner.google.com>
Message-ID: <20250826154040.2723998-1-ajye_huang@compal.corp-partner.google.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no point having __vcpu_{read,write}_sys_reg_{from,to}_cpu()
exposed to the rest of the kernel, as the only callers are in
sys_regs.c.
Move them where they below, which is another opportunity to
simplify things a bit.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20250817121926.217900-5-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Volodymyr reports (again!) that under some circumstances (E2H==0,
walking S1 PTs), PAR_EL1 doesn't report the value of the latest
walk in the CPU register, but that instead the value is written to
the backing store.
Further investigation indicates that the root cause of this is
that a group of registers (PAR_EL1, TPIDR*_EL{0,1}, the *32_EL2 dregs)
should always be considered as "on CPU", as they are not remapped
between EL1 and EL2.
We fail to treat them accordingly, and end-up considering that
the register (PAR_EL1 in this example) should be written to memory
instead of in the register.
While it would be possible to quickly work around it, it is obvious
that the way we track these things at the moment is pretty horrible,
and could do with some improvement.
Revamp the whole thing by:
- defining a location for a register (memory, cpu), potentially
depending on the state of the vcpu
- define a transformation for this register (mapped register, potential
translation, special register needing some particular attention)
- convey this information in a structure that can be easily passed
around
As a result, the accessors themselves become much simpler, as the
state is explicit instead of being driven by hard-to-understand
conventions.
We get rid of the "pure EL2 register" notion, which wasn't very
useful, and add sanitisation of the values by applying the RESx
masks as required, something that was missing so far.
And of course, we add the missing registers to the list, with the
indication that they are always loaded.
Reported-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Fixes: fedc612314 ("KVM: arm64: nv: Handle virtual EL2 registers in vcpu_read/write_sys_reg()")
Link: https://lore.kernel.org/r/20250806141707.3479194-3-volodymyr_babchuk@epam.com
Link: https://lore.kernel.org/r/20250817121926.217900-4-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Distinguishing between NV and VHE is slightly pointless, and only
serves as an extra complication, or a way to introduce bugs, such
as the way SPSR_EL1 gets written without checking for the state
being resident.
Get rid if this silly distinction, and fix the bug in one go.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20250817121926.217900-3-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Just like c6e35dff58 ("KVM: arm64: Check for SYSREGS_ON_CPU before
accessing the CPU state") fixed the 64bit state access, add a check
for the 32bit state actually being on the CPU before writing it.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20250817121926.217900-2-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Bindings expect GPIO hog names to end with 'hog' suffix, so correct it
to fix dtbs_check warning:
ste-nomadik-s8815.dtb: mmcsd-gpio: $nodename:0: 'mmcsd-gpio' does not match '^.+-hog(-[0-9]+)?$'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250115211627.193961-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit e9fc3ce99b ("libbpf: Streamline error reporting for high-level
APIs") redefined the way that bpf_prog_detach2() returns. Therefore, adapt
the usage in test_lirc_mode2_user.c.
Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20250828-selftests-bpf-v1-1-c7811cd8b98c@suse.com
The QiLai implementation of this cache controller uses a cache-sets of
2048, and mandates it in an if/else block - but the definition of the
property only permits 1024. Add 2048 as an option, and deny its use
outside of the QiLai.
Fixes: 51b081cdb9 ("dt-bindings: cache: add QiLai compatible to ax45mp")
Reviewed-by: Ben Zong-You Xie <ben717@andestech.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
For Intel SKL and KBL platforms, it may be bound with one of three
HD-audio drivers (AVS, SOF and legacy). AVS is the preferred one when
DMIC is detected, and that's how it's defined in the snd-intel-dspcfg
config table.
But, when AVS driver is disabled (CONFIG_SND_SOC_INTEL_AVS=n), the
device may be bound freely with either SOF or legacy driver.
Before 6.17, the legacy driver took it primarily, but on 6.17, likely
due to the recent code shuffling, SOF driver seems taking it at first,
and fails to probe. For avoiding the regression, we should enforce to
bind those with the legacy HD-audio drvier when AVS is disabled.
This patch adds the extra two entries in intel-dspcfg table that are
applied only when CONFIG_SND_SOC_INTEL_AVS=n, for binding with the
legacy driver.
Note that there are entries for APL in that config table block, but
APL may be supported by SOF for certain setups, so the choice can't be
exclusive. Hence this patch includes only SKL and KBL.
Link: https://bugzilla.suse.com/show_bug.cgi?id=1248121
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20250828141101.16294-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Secure AVIC feature provides SEV-SNP guests hardware acceleration for
performance sensitive APIC accesses while securely managing the guest-owned
APIC state through the use of a private APIC backing page.
This helps prevent the hypervisor from generating unexpected interrupts for
a vCPU or otherwise violate architectural assumptions around the APIC
behavior.
Add a new x2APIC driver that will serve as the base of the Secure AVIC
support. It is initially the same as the x2APIC physical driver (without IPI
callbacks), but will be modified as features are implemented.
As the new driver does not implement Secure AVIC features yet, if the
hypervisor sets the Secure AVIC bit in SEV_STATUS, maintain the existing
behavior to enforce the guest termination.
[ bp: Massage commit message. ]
Co-developed-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com>
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/20250828070334.208401-2-Neeraj.Upadhyay@amd.com
The Peripheral Virtualization Unit (PVU) on the AM65 SoC is capable of
restricting DMA from PCIe devices to specific regions of host memory.
Add the optional property "memory-regions" to point to such regions of
memory when PVU is used.
Since the PVU deals with system physical addresses, utilizing the PVU
with PCIe devices also requires setting up the VMAP registers to map the
Requester ID of the PCIe device to the CBA Virtual ID, which in turn is
mapped to the system physical address. Hence, describe the VMAP
registers which are optional unless the PVU shall be used for PCIe.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
[mani: Expanded PVU in description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250728023701.116963-3-huaqian.li@siemens.com
It turns out that the platform firmware on some models does not return
valid data when reading the bitmap of supported platform profiles.
This prevents the driver from loading on said models, even when the
platform profile interface itself works.
Fix this by stop using said bitmap until we have figured out how
the OEM software itself detects available platform profiles.
Tested-by: Lynne Megido <lynne@bune.city>
Reported-by: Lynne Megido <lynne@bune.city>
Closes: https://lore.kernel.org/platform-driver-x86/3f56e68f-85df-4c0a-982c-43f9d635be38@bune.city/
Fixes: 191e21f1a4 ("platform/x86: acer-wmi: use an ACPI bitmap to set the platform profile choices")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20250826204007.5088-1-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add support for the Fn+P hotkey found on newer HP Victus (and probably
newer Omen) laptops. This hotkey is intended for use with Omen Gaming Hub
to change the performance profile (see [1]).
Pressing Fn+P under linux produced the following warning in dmesg:
> hp_wmi: Unknown event_id - 27 - 0x7
Implemented a handling for this event so that the hotkey cycles between the
platform profiles when triggered.
Tested on Victus 16-s1011nt (9Z791EA, MB 8C9C).
Changes in v2:
- Make the key just switches between platform profiles instead of
assigning a key event code.
- v1: https://lore.kernel.org/all/20250802213541.18791-2-edip@medip.dev/
[1]: https://jpcdn.it/img/adadf6c927ffeb75afd8038f95db400a.png
Signed-off-by: Edip Hazuri <edip@medip.dev>
Link: https://lore.kernel.org/r/20250814204529.18467-4-edip@medip.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add Bartlett Lake P-core only product support to intel_pmc_core
driver. Bartlett Lake hybrid product reuses Raptor Lake model name
so it is already enabled.
Acked-by: Xi Pardee <xi.pardee@linux.intel.com>
Signed-off-by: Li Yifan <yifan2.li@intel.com>
Link: https://lore.kernel.org/r/20250826034550.2284738-1-yifan2.li@intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
asus_wmi_register_driver() may be called from multiple drivers
concurrently, which can lead to the racy list operations, eventually
corrupting the memory and hitting Oops on some ASUS machines.
Also, the error handling is missing, and it forgot to unregister ACPI
lps0 dev ops in the error case.
This patch covers those issues by introducing a simple mutex at
acpi_wmi_register_driver() & *_unregister_driver, and adding the
proper call of asus_s2idle_check_unregister() in the error path.
Fixes: feea7bd6b0 ("platform/x86: asus-wmi: Refactor Ally suspend/resume")
Link: https://bugzilla.suse.com/show_bug.cgi?id=1246924
Link: https://lore.kernel.org/07815053-0e31-4e8e-8049-b652c929323b@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20250827052441.23382-1-tiwai@suse.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Handle LVDS pixel clock.
The LTDC operates with multiple clock domains for register access,
requiring all clocks to be provided during read/write operations. This
imposes a dependency between the LVDS and LTDC to access correctly all
LTDC registers. And because both IPs' pixel rates must be synchronized,
the LTDC has to handle the LVDS clock.
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-8-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
STM32MP25 SoC features a new version of the LTDC IP. Add its compatible
to the list of device to probe and implement its quirks.
This hardware supports a pad frequency of 150MHz and a peripheral bus
clock.
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-7-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
On STM32MP25 SoC, the syscfg peripheral provides a clock to the display
subsystem through a multiplexer. Since it only provides a single clock,
the cell value is 0.
Doing so allows the clock consumers to reach the peripheral and gate the
clock accordingly.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Christophe Roullier <christophe.roullier@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-6-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
STM32 LVDS peripheral may be in a power domain. Allow an optional
single 'power-domains' entry for STM32 LVDS devices.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-5-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
access-controllers is an optional property that allows a peripheral to
refer to one or more domain access controller(s).
This property is added when the peripheral is under the STM32 firewall
controller. It allows an accurate representation of the hardware, where
the peripheral is connected to a firewall bus. The firewall can then
check the peripheral accesses before allowing its device to probe.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-4-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Update the compatible to accept both "st,stm32mp255-lvds" and
st,stm32mp25-lvds" respectively. Default will fall back to
"st,stm32mp25-lvds".
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-3-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
access-controllers is an optional property that allows a peripheral to
refer to one or more domain access controller(s).
This property is added when the peripheral is under the STM32 firewall
controller. It allows an accurate representation of the hardware, where
the peripheral is connected to a firewall bus. The firewall can then check
the peripheral accesses before allowing its device to probe.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-2-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
The new STMicroelectronics SoC features a display controller similar to
the one used in previous SoCs. Because there is additional registers,
and different mandatory clocks it is incompatible with existing IPs. On
STM32MP251, the device only needs two clocks while on STM32MP255 it
needs four.
Add the new names to the list of compatible string and handle each
quirks accordingly.
Acked-by: Philippe Cornu <philippe.cornu@foss.st.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250822-drm-misc-next-v5-1-9c825e28f733@foss.st.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Prevents instant wakeup ~1s after suspend.
It seems to be kernel/system dependent if the IRQ actually manages to wake
the system every time or if it gets ignored (and everything works as
expected).
Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250827131424.16436-1-wse@tuxedocomputers.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
* there is a dedicated "noise cancel" key in top row, between mic mute
and PrintScreen; it sends 0xCA when pressed by itself (mapped to F13),
0xCB with Fn (mapped to F14)
* Fn+f sends 0x9D; it is not documented in the manual, but some web
search results mention "asus intelligent performance"; mapped to FN_F
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Link: https://lore.kernel.org/r/20250827152954.4844-1-anton@khirnov.net
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
It'd be great if it can get the correct debug information using DSO
build-Id not just the path name. Instead of adding new callsites of
debuginfo__new(), let's add dso__debuginfo() which can hide the access
using the pathname and help the future conversion.
Suggested-by: Ian Rogers <irogers@google.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250816031635.25318-12-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When user requests data-type annotation but no DWARF info is available,
show a warning message about it.
Warning:
DWARF debuginfo not found.
Data-type in this DSO will not be displayed.
Please make sure to have debug information.
Press any key...
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250816031635.25318-10-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Support data type display with a key press so that users can toggle the
output dynamically on TUI. Also display "[Type]" in the title line if
it's enabled.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250816031635.25318-9-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Until now, the --code-with-type option is available only on stdio.
But it was an artifical limitation because of an implemention issue.
Implement the same logic in annotation_line__write() for stdio2/TUI
and remove the limitation and update the man page.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250816031635.25318-8-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
