Report max_msg_sz for mana_ib, which is 16MB.
Fixes: 4bda1d5332 ("RDMA/mana_ib: Implement port parameters")
Signed-off-by: Shiraz Saleem <shirazsaleem@microsoft.com>
Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com>
Link: https://patch.msgid.link/20260512094209.264955-1-kotaranov@linux.microsoft.com
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Sashiko points out the legacy write path in ib_uverbs_write() does
allocate a struct uverbs_attr_bundle, but it doesn't wrap it in a
bundle_priv so downcasting here isn't safe.
Instead lift the method_elm out of the bundle_priv and use it for the
debug function. The legacy write path will leave it set as NULL since the
write method_elm uses a different type.
Cc: stable@vger.kernel.org
Fixes: 1de9287ece ("RDMA: Add ib_copy_validate_udata_in()")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
It was incorrect to place them in uverbs_ioctl because that makes every
driver depends on ib_uverbs.ko, which is undesired. ib_core_uverbs.c is
for functions used by alot of drivers that are linked into ib_core
instead.
Fixes: 1de9287ece ("RDMA: Add ib_copy_validate_udata_in()")
Link: https://patch.msgid.link/r/1-v1-045258567bd6+9fe-ib_uverbs_support_ko_jgg@nvidia.com
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
The xfstests' test-case generic/003 fails with errors:
sudo ./check generic/003
FSTYP -- hfs
PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #18 SMP PREEMPT_DYNAMIC Fri Mar 13 17:54:19 PDT 2026
MKFS_OPTIONS -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
output mismatch
QA output created by 003
ERROR: access time has changed for file1 after remount
ERROR: access time has changed after modifying file1
ERROR: change time has not been updated after changing file1
ERROR: access time has changed for file in read-only filesystem
Silence is golden
This patch fixes the issue with change time by
adding inode_set_ctime_current() and mark_inode_dirty()
in hfs_rename(). Also, it reworks hfs_inode_setattr() by
changing simple_inode_init_ts() on inode_set_mtime_to_ts()
and inode_set_ctime_current() calls.
HFS hasn't any field in on-disk layout that can keep
the file/folder access times (atime). It was added
setting of SB_NOATIME in SB_NOATIME.
Finally, we have only atime related errors in
generic/003 output:
sudo ./check generic/003
FSTYP -- hfs
PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.1.0-rc1+ #52 SMP PREEMPT_DYNAMIC Wed May 13 15:04:37 PDT 2026
MKFS_OPTIONS -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
QA output created by 003
ERROR: access time has not been updated after accessing file1 first time
ERROR: access time has not been updated after accessing file2
ERROR: access time has not been updated after accessing file3 second time
ERROR: access time has not been updated after accessing file3 third time
Silence is golden
The generic/003 test-case needs to be disabled for HFS case
because it cannot support the file/folder access times (atime).
Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/3
cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
cc: Yangtao Li <frank.li@vivo.com>
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
Link: https://lore.kernel.org/r/20260514195630.354206-2-slava@dubeyko.com
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
Older steppings of the Loongson-3C6000 series incorrectly report the
supported link speeds on their PCIe bridges (device IDs 0x3c19, 0x3c29)
as only 2.5 GT/s, despite the upstream bus supporting speeds from
2.5 GT/s up to 16 GT/s.
As a result, since commit 774c71c52a ("PCI/bwctrl: Enable only if more
than one speed is supported"), bwctrl will be disabled if there's only
one 2.5 GT/s value in vector 'supported_speeds'.
Manually override the 'supported_speeds' field for affected PCIe bridges
with those found on the upstream bus to correctly reflect the supported
link speeds. Updating the speeds to reflect what the hardware actually
supports avoids quirks in drivers consuming the speed information.
This commit was originally found from AOSC OS[1].
Fixes: cd89edda40 ("PCI: loongson: Add ACPI init support")
Signed-off-by: Ayden Meng <aydenmeng@yeah.net>
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
[Ziyao Li: move from drivers/pci/quirks.c to drivers/pci/controller/pci-loongson.c]
Signed-off-by: Ziyao Li <liziyao@uniontech.com>
[Xi Ruoyao: Fixed falling through logic, added debug log, Fixes tag and rebased to 7.0-rc7]
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
[bhelgaas: commit log, https://lore.kernel.org/all/9d815df3b33a63223112b97440c01247935363c1.camel@xry111.site]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Lain Fearyncess Yang <fsf@live.com>
Tested-by: Ayden Meng <aydenmeng@yeah.net>
Tested-by: Mingcong Bai <jeffbai@aosc.io>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Cc: stable@vger.kernel.org
Link: 4392f44136
Link: https://github.com/AOSC-Tracking/linux/pull/2#1
Link: https://patch.msgid.link/20260412101731.107059-1-xry111@xry111.site
The vpcie-supply property should reference the regulator that controls
the actual M.2 power supply, not the W_DISABLE1# signal.
On imx95-19x19-evk:
- reg_pcie0 controls M.2 W_DISABLE1# signal
- reg_m2_pwr controls the actual M.2 power supply
Fix the vpcie-supply to use reg_m2_pwr for proper power control in
PCIe endpoint mode.
Fixes: 58bea81052 ("arm64: dts: imx95: add pcie1 ep overlay file and create pcie-ep dtb files")
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
For PCIe endpoint mode, only M.2 power supply needs to be ensured.
On imx8qxp-mek, the M.2 power is always on and cannot be controlled,
while reg_pcieb only controls the M.2 W_DISABLE1# signal. Remove the
unnecessary vpcie-supply property from pcie0_ep node.
Fixes: 1c9b0c6044 ("arm64: dts: imx8: use common imx-pcie0-ep.dtso to enable PCI ep function")
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
For PCIe endpoint mode, only M.2 power supply needs to be ensured.
On imx8dxl-evk, the M.2 power is always on and cannot be controlled,
while reg_pcieb only controls the M.2 W_DISABLE1# signal. Remove the
unnecessary vpcie-supply property from pcie0_ep node.
Also remove reset-gpio as PCIe endpoint mode doesn't require reset
control.
Fixes: c1c4820b60 ("arm64: dts: imx8dxl-evk: Add pcie0-ep node and use unified pcie0 label")
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Replace deprecated "gpio" property with "gpios" in
regulator-vmmc-usdhc2 fixed regulator node.
Signed-off-by: Antoine Gouby <antoine.gouby@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Commit 0a869409a9 ("ACPI: battery: Convert the driver to a platform
one") changed the parent of the battery wakeup source to the platform
device used for driver binding, but it forgot to update the
acpi_pm_wakeup_event() call in acpi_battery_update() accordingly.
Do it now to unbreak waking up the system on critical battery status
during suspend-to-idle and during transitions to ACPI S3/S4.
Fixes: 0a869409a9 ("ACPI: battery: Convert the driver to a platform one")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 7.0+ <stable@vger.kernel.org> # 7.0+
Link: https://patch.msgid.link/12898712.O9o76ZdvQC@rafael.j.wysocki
-----BEGIN PGP SIGNATURE-----
iQJIBAABCgAyFiEES0KozwfymdVUl37v6iDy2pc3iXMFAmoMpZAUHHBhdWxAcGF1
bC1tb29yZS5jb20ACgkQ6iDy2pc3iXNJ2xAAk2PLXepc0tY306zUsgSF92V58tTs
eI+TBppUC6cSISo63ym40Nv+fQTB9HyEVX5GXxOqjIxh9terD1UEWWUV4Idfi85t
UP00AklRB6xrAA7rmPy/u7QYNPM8HRecFB+7jLsV19FRujKGLJCHfZjj/CmLQZaN
KBHakQl4qD6eng1bST9S1WbUe3pr2YwujlBizE5+gHWdtx5+ElVoTWGlYNnAsfNh
PZzl0PPAPCEcfUljl2gVpW6zgxqVvsB/HI63DU/bE7XYQ8T+pzw52ghffIIbQits
1t5BGPfdgt1vXGk73QTl69Pk4wc3niaH/gM/80pfzEevHVEu9dcn6hu6yULlGkjz
P3d/AacCjc4e1O2Jt3QoYBNfmkv5ceIEByKiX2SScNE8bHYI16jkmWj+MR0NA9PC
9CxL+AhWzx8R1nGEUl+zNnzyVZPpFqJb5B8dZ+xxPHwPZev6pGjpKH00ZqLLzV2n
PQce1Y8jzIGVSCQpJJvrnYiNg4quEKQ3wCI6hnPNxPgBN4U6dGRQ0fU1K/coG2o2
1YXwIktKJRNR0cB8rEqXMnoGxR9q0JsDanpMB9tH3XKCU4kpfTkp40lpvtF2z2SB
K9zSVvd3otQmbiKwD+rDoIoZJc97ZhYDADAKsixNh/Mnn1eTQF8L8FxBEcmIvrCX
ZnS/KWRrxoAqYnc=
=yDvf
-----END PGP SIGNATURE-----
Merge tag 'lsm-pr-20260519' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm
Pull lsm fix from Paul Moore:
"A single LSM patch to add a missing credential mutex lock to the
lsm_set_self_attr(2) syscall so it behaves similar to the associated
procfs API and avoids issues with ptrace"
* tag 'lsm-pr-20260519' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm:
lsm: hold cred_guard_mutex for lsm_set_self_attr()
After
3645eb7e39 ("x86/fred: Fix early boot failures on SEV-ES/SNP guests"),
__sev_{get,put}_ghcb() handle the early-boot GHCB fallback internally, making
the ghcbs_initialized guards in __set_pages_state() and
svsm_perform_call_protocol() redundant.
Remove them.
Also initialize state->ghcb to NULL in the early-boot path of
__sev_get_ghcb() so that the ghcb_state is well-defined for all callers,
even though __sev_put_ghcb() currently returns early before reading it.
No functional change intended.
Suggested-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://patch.msgid.link/20260518102230.3394603-1-nikunj@amd.com
- Make sure that the issuing of a deferred non-NCQ command via
workqueue feature is only used when mixing NCQ and non-NCQ commands
to the same link (i.e. return value ATA_DEFER_LINK), and nothing
else. This way we will not incorrectly try to use the feature for
e.g. PATA drivers.
- The deferred non-NCQ command was stored in a per-port struct.
When using Port Multipliers with FIS-Based Switching, we would thus
needlessly defer commands to all other links. Store the deferred QC
in a per-link struct, such that Port Multipliers with FBS will get
the same performance as before.
- The issuing of a deferred non-NCQ command via workqueue feature
broke support for Port Multipliers using Command-Based Switching.
The issuing of a deferred non-NCQ command via workqueue feature is
not compatible with the use of ap->excl_link, which PMPs with CBS
use for fairness (using implicit round robin).
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRN+ES/c4tHlMch3DzJZDGjmcZNcgUCagyJuQAKCRDJZDGjmcZN
clYrAP9WGyaktaHe8MVLFAOIvtj58qAyDGH5U9gqA/lc8MfFDQEAvC81OBtXkpP6
WaZGuAw6eqja1KlSg6mzmfOLvVIHLwk=
=MbtN
-----END PGP SIGNATURE-----
Merge tag 'ata-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux
Pull ata fixes from Niklas Cassel:
- Make sure that the issuing of a deferred non-NCQ command via
workqueue feature is only used when mixing NCQ and non-NCQ commands
to the same link (i.e. return value ATA_DEFER_LINK), and nothing
else. This way we will not incorrectly try to use the feature for
e.g. PATA drivers
- The deferred non-NCQ command was stored in a per-port struct. When
using Port Multipliers with FIS-Based Switching, we would thus
needlessly defer commands to all other links. Store the deferred QC
in a per-link struct, such that Port Multipliers with FBS will get
the same performance as before
- The issuing of a deferred non-NCQ command via workqueue feature broke
support for Port Multipliers using Command-Based Switching. The
issuing of a deferred non-NCQ command via workqueue feature is not
compatible with the use of ap->excl_link, which PMPs with CBS use for
fairness (using implicit round robin)
* tag 'ata-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
ata: libata-scsi: do not needlessly defer commands when using PMP with FBS
ata: libata-scsi: do not use the deferred QC feature on PMPs with CBS
ata: libata-scsi: do not use the deferred QC feature for ATA_DEFER_PORT
ata: libata-scsi: improve readability of ata_scsi_qc_issue()
Apply improved drive-strength values and pull-up/down configurations as
devised from hardware measurements to improve signal quality on PHYTEC
phyCORE-i.MX 91/93 SoM based boards. Also improve eMMC HS400 mode by
setting property "fsl,strobe-dll-delay-target" which shifts the strobe
DLL sampling window to the optimal position.
Signed-off-by: Christoph Stoidner <c.stoidner@phytec.de>
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
According to measurements, the PHY reset signal shows an overshoot on
the rising edge that exceeds the specified limits (max 2.1V) when using
X4 strength on ENET2_RXC. Reduce drive-strength to X1 to decrease the
overshoot and bring signal within specification limits.
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Set PMIC BUCK5 mode to forced PWM (Pulse Width Modulation) mode instead
of the default automatic PFM and PWM transition mode. FPWM mode produces
less ripple on the output voltage rail under light load conditions. And
since BUCK5 supplies SoC internal ADC reference voltage we need to keep
voltage ripple to a minimum. This solves issues with the occasional ADC
calibration procedure failures on phyCORE-i.MX91/93 SoM based boards.
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Vishal reported that KVM unit test 'x2apic' started failing after commit
0e98eb1481 ("entry: Prepare for deferred hrtimer rearming").
The reason is that KVM/VMX is injecting interrupts while it has interrupts
disabled, for a context that will enable interrupts, this means that
regs->flags.X86_EFLAGS_IF == 0 and irqentry_exit() will not do the right
thing.
Notably, irqentry_exit() must not call hrtimer_rearm_deferred() when the return
context does not have IF set, because this will cause problems vs NMIs.
Therefore, fix up the state after the injection.
Fixes: 0e98eb1481 ("entry: Prepare for deferred hrtimer rearming")
Reported-by: "Verma, Vishal L" <vishal.l.verma@intel.com>
Suggested-by: Thomas Gleixner <tglx@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: "Verma, Vishal L" <vishal.l.verma@intel.com>
Tested-by: David Woodhouse <dwmw@amazon.co.uk>
Tested-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Link: https://patch.msgid.link/20260423155936.957351833@infradead.org
Closes: https://lore.kernel.org/r/70cd3e97fbb796e2eb2ff8cd4b7614ada05a5f24.camel%40intel.com
Move the VMX interrupt dispatch magic into the x86 core code. This
isolates KVM from the FRED/IDT decisions and reduces the amount of
EXPORT_SYMBOL_FOR_KVM().
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: "Verma, Vishal L" <vishal.l.verma@intel.com>
Tested-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Zhao Liu <zhao1.liu@intel.com>
Tested-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Binbin Wu <binbin.wu@linxu.intel.com>
Acked-by: Sean Christopherson <seanjc@google.com>
Link: https://patch.msgid.link/20260508091829.GO3126523@noisy.programming.kicks-ass.net
The macro HAS_DMC_WAKELOCK() is currently only used inside
intel_dmc_wl.c and doesn't need to be exposed to the rest of the driver.
Furthermore, there is a distinction between the display IP having
support for the feature and the driver actually using it, so using
HAS_DMC_WAKELOCK() outside of intel_dmc_wl.c would potentially be wrong
anyway.
Let's drop that macro. If other part of the driver needs to check if
the driver is using the DMC wakelock feature, we would need actually to
expose the function __intel_dmc_wl_supported().
Since HAS_DMC_WAKELOCK() was kind of self-documenting in the sense that
it tells us what display IPs have support for the feature and we are now
dropping it, let's also take this opportunity to add a documentation
note on the subject.
Reviewed-by: Daniel Charles <daniel.charles@intel.com>
Link: https://patch.msgid.link/20260429-drop-has_dmc_wakelock-v1-1-62cb6fab1da0@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Support tianma,tm050rdh03 DPI panel on i.MX93 9x9 QSB.
Move the common parts from imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtso into
imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtsi for reuse by the tm050rdh03
overlay file.
The panel connects with the QSB board through an adapter board[1]
designed by NXP.
Link: https://www.nxp.com/design/design-center/development-boards-and-designs/parallel-lcd-display:TM050RDH03-41 [1]
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Some i.MX boards (i.MX8MP EVK and i.MX95-15x15 EVK) have M.2 connectors
that are physically wired to both USDHC and PCIe controllers. The
default device tree enables USDHC for SDIO WiFi modules and disables
PCIe to avoid regulator conflicts.
Add a common imx-m2-pcie.dtso that can be applied to enable PCIe and
disable USDHC when a PCIe module is installed in the M.2 connector.
This creates the following DTB files:
- imx8mp-evk-pcie.dtb: i.MX8MP EVK with PCIe enabled
- imx95-15x15-evk-pcie.dtb: i.MX95-15x15 EVK with PCIe enabled
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Disable the PCIe bus in the default device tree to avoid shared
regulator conflicts between SDIO and PCIe buses. The non-deterministic
probe order between these two buses can break the PCIe initialization
sequence, causing PCIe devices to fail detection intermittently.
On i.MX95-15x15 EVK board, the M.2 connector is physically wired to both
USDHC3 and PCIe0, however the out-of-box module is SDIO IW612 WiFi, so
enable SDIO WiFi in the default imx95-15x15-evk.dts.
Add 'm2_usdhc' label to USDHC3 to support device tree overlay for PCIe
modules. Users who need PCIe can use imx95-15x15-evk-pcie.dtb (added in
a follow-up patch) which applies an overlay to enable PCIe and disable
USDHC3.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Disable the PCIe bus in the default device tree to avoid shared
regulator conflicts between SDIO and PCIe buses. The non-deterministic
probe order between these two buses can break the PCIe initialization
sequence, causing PCIe devices to fail detection intermittently.
On i.MX8MP EVK board, the M.2 connector is physically wired to both
USDHC1 and PCIe0, however the out-of-box module is SDIO IW612 WiFi, so
enable the SDIO WiFi in the default imx8mp-evk.dts.
Add 'm2_usdhc' label to USDHC1 to support device tree overlay for PCIe
modules. Users who need PCIe can use imx8mp-evk-pcie.dtb (added in a
follow-up patch) which applies an overlay to enable PCIe and disable
USDHC1.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Sort the Makefile entries alphabetically. No functional change.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Fix the RS485 functionality, the RS485 RTS signal is active high on Ivy.
Fixes: f33a1f9a94 ("arm64: dts: freescale: imx95-verdin: Add Ivy carrier board")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Add Zinnia Carrier Board mated with Verdin iMX95.
It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O,
2 x GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector
for a modem, USB and SD card interfaces.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Some carrier board reuse the UART_2 control signals as GPIO, split
the pinctrl RTS/CTS in separated nodes to maximize flexibility.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Add Zinnia Carrier Board mated with Verdin iMX8M Plus.
It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O,
2 x GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector
for a modem, USB and SD card interfaces.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Some carrier board reuse the UART_2 control signals as GPIO, split
the pinctrl RTS/CTS in separated nodes to maximize flexibility.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Add Zinnia Carrier Board mated with Verdin iMX8M Mini.
It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O,
1 x GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector
for a modem, USB and SD card interfaces.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Some carrier board reuse the UART_2 control signals as GPIO, split
the pinctrl RTS/CTS in separated nodes to maximize flexibility.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Add Toradex Verdin Zinnia carrier board mated with Verdin
iMX8M Plus, Verdin iMX8M Mini and Verdin iMX95.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
IRQ_TYPE_xxx flags are not correct in the context of GPIO flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning: IRQ_TYPE_EDGE_FALLING = 2 = GPIO_SINGLE_ENDED.
Correct the Type-C int-gpios to use proper flags, assuming the author of
the code wanted similar logical behavior:
IRQ_TYPE_EDGE_FALLING => GPIO_ACTIVE_LOW
Fixes: c4b4593ecb ("arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
FFA_PARTITION_INFO_GET_REGS reports the size of each partition
information descriptor in x2[63:48]. However, __ffa_partition_info_get_regs()
walks the returned register payload with a hardcoded 24-byte stride
(regs += 3), even though the size is already read into buf_sz.
That works for the FF-A v1.1/v1.2 24-byte descriptor layout, where each
descriptor consumes three registers. Newer FF-A revisions can extend the
descriptor while keeping the existing fields at the front. For example, a
48-byte descriptor consumes six registers, so advancing by only three
registers desynchronises the parser and can make it read subsequent entries
from the middle of a descriptor.
Use the advertised descriptor size to derive the register stride. Validate
that the size is register-aligned, large enough for the fields parsed by the
driver, and that the requested number of descriptors fits in the returned
x3..x17 register window. The driver still copies only the fields it
understands, but now skips over any trailing descriptor fields correctly.
Fixes: ba85c644ac ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS")
Suggested-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Jamie Nguyen <jamien@nvidia.com>
Link: https://patch.msgid.link/20260518203116.42624-1-jamien@nvidia.com
(sudeep.holla: Minor rewordng of the commit message and subject)
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
bio_integrity_verify() expects the passed struct bvec_iter to be an
iterator over bio data, not integrity. So construct a separate data
bvec_iter without the bio_integrity_bytes() conversion and pass it to
bio_integrity_verify() instead of bip_iter.
Fixes: 0bde8a12b5 ("block: add fs_bio_integrity helpers")
Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260513182924.1753582-1-csander@purestorage.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
While touching these arrays, unify usage of whitespace in the list
terminator.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Message-ID: <20260519150156.1590826-2-u.kleine-koenig@baylibre.com>
Signed-off-by: Corey Minyard <corey@minyard.net>
Just like it is done for the platform-specific bandwidth parameters, use
a separate function named get_display_bw_params() to return the display
IP-specific parameters. This simplifies intel_bw_init_hw() by having
just one call for each of the *_get_bw_info() functions.
v2:
- Prefer to call get_display_bw_params() only once in
intel_bw_init_hw() instead of having multiple calls in each of the
affected *_get_bw_info() functions. (Jani)
v3:
- Call get_display_bw_params() only after the check on
HAS_DISPLAY(display). (Jani)
- Return &gen11_bw_params only if display version is 11. (Matt)
v4:
- Like done with get_soc_bw_params(), drop drm_WARN() when no display
IP is matched.
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-5-918528006549@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
To align with struct intel_platform_bw_params, rename struct
intel_sa_info to intel_display_bw_params. Also add comments to contrast
their purposes.
v2:
- Use gen11 and gen12 as prefixes for ICL's and TGL's display-specific
parameters variables. (Matt)
- Prefer to use "display" instead of "disp" in variable names. (Jani)
- Drop the redundant "disp" from the variable names.
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-4-918528006549@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Now that intel_sa_info contains bandwidth parameters specific to the
display IP, we can drop many duplicates and reuse from previous
releases.
Let's do that and also simplify intel_bw_init_hw() while at it.
v2:
- Drop rkl_sa_info and reuse icl_sa_info. (Matt)
- Add comment explaining RKL's display's peculiarity on using ICL's
parameters. (Matt)
- Don't rename xelpdp_sa_info to mtl_sa_info. Renaming of instances
to use IP names will be done in upcoming changes.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-3-918528006549@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
We got confirmation from the hardware team that the bandwidth parameters
deprogbwlimit and derating are platform-specific and not tied to the
display IP. As such, let's make sure that we use platform checks for
those.
The rest of the members of struct intel_sa_info are tied to the display
IP and we will deal with them as a follow-up.
v2:
- Use good old if-ladder instead of weird-looking pattern "assign ret,
check platform, then return ret". (Jani, Matt)
- Have a single call site for get_platform_bw_params() and pass the
result as parameter to the *_get_bw_info() functions. (Jani)
- Avoid using "plat" as abbreviation for "platform". (Jani)
- s/_plat_bw_params/_bw_params/, since all of the instances are
prefixed with platform names. (Jani)
- s/struct intel_platform_bw_params/struct intel_soc_bw_params/.
(Matt)
- Do not return a default value; prefer to return NULL and
intentionally cause a NULL pointer dereference if a platform is
missing. (Gustavo)
v3:
- Call get_soc_bw_params() only after the check on
HAS_DISPLAY(display). (Jani)
- Combine if-ladder branches for adl_s_bw_params into a single one.
(Matt)
- Flatten if-ladder by checking for WCL before PTL (as opposed to
checking for WCL inside the brace for PTL). (Matt)
- Bail out of intel_bw_init_hw() if display version is below 11.
(Gustavo)
v4:
- Drop drm_WARN() when no platform was matched to avoid
special-casing DG2 and any other platform that doesn't use
SoC-specific parameters. (Jani)
- Pass dram_info to get_soc_bw_params() to keep a single call to
intel_dram_info(). (Jani)
- Don't use 2 separate if-ladders (one for client and another for
discrete platforms) and keep a single one for simplicity. (Gustavo)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260518-separate-platform-from-diplay-ip-specific-bw-params-v4-2-918528006549@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
By convention MODULE_DEVICE_TABLE() immediately follows the ID table it
exports, because this is easier to read and verify. It also makes more
sense since #ifdef for ACPI or OF could hide both of them.
Most of the drivers already have this correctly placed, so adjust
the missing ones. No functional impact.
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260514060525.9253-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Document the GPI DMA engine found on the Eliza SoC.
It is fully compatible with the GPI DMA engine found on SM6350,
thus using qcom,sm6350-gpi-dma as fallback compatible.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
Link: https://patch.msgid.link/20260515-eliza-gpi-dma-v2-1-1255b43d5ca9@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
SpacemiT K3 reuses most of the PDMA IP design found on K1, with one
difference being the extended DRCMR base address. Add "spacemit,k3-pdma"
compatible string and define a new mmp_pdma_ops for K3 PDMA.
Signed-off-by: Guodong Xu <guodong@riscstar.com>
Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Link: https://patch.msgid.link/20260518-k3-pdma-v6-3-67fdf319a8f8@linux.spacemit.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
