Being able to print these is useful when debugging the sequencer.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260217-nova-misc-v3-5-b4e2d45eafbc@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
The `GspSeqCmdRunner` trait is never used as we never call the `run`
methods from generic code. Remove it.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260217-nova-misc-v3-4-b4e2d45eafbc@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
The opcodes are already the right type in the C union, so we can use
them directly instead of converting them to a byte stream and back again
using `FromBytes`.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260217-nova-misc-v3-3-b4e2d45eafbc@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
We only ever display these in debug context, for which the automatically
derived `Debug` impls work just fine - so use them and remove these
boilerplate-looking implementations.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alistair Popple <apopple@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260217-nova-misc-v3-2-b4e2d45eafbc@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Not processing the whole data from a received message is a strong
indicator of a bug - emit a warning when such cases are detected.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260217-nova-misc-v3-1-b4e2d45eafbc@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
The current code indexes into `after_rx` using `tx` which is an index
for the whole buffer, not the split buffer `after_rx`.
Also add more rigorous no-panic proofs.
Fixes: 75f6b1de81 ("gpu: nova-core: gsp: Add GSP command queue bindings and handling")
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260129-nova-core-cmdq1-v3-5-2ede85493a27@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
The current code hands out buffers that go all the way up to and
including `rx - 1`, but we need to maintain an empty slot to prevent the
ring buffer from wrapping around into having 'tx == rx', which means
empty.
Also add more rigorous no-panic proofs.
Fixes: 75f6b1de81 ("gpu: nova-core: gsp: Add GSP command queue bindings and handling")
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260129-nova-core-cmdq1-v3-4-2ede85493a27@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
The current code unnecessarily uses, for example, &before_rx[0..0] to
return an empty slice. Instead, just use an empty slice.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260129-nova-core-cmdq1-v3-3-2ede85493a27@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
We should modulo not bitwise-and here. The current code could, for
example, set wptr to MSGQ_NUM_PAGES which is not valid.
Fixes: 75f6b1de81 ("gpu: nova-core: gsp: Add GSP command queue bindings and handling")
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260129-nova-core-cmdq1-v3-1-2ede85493a27@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Use checked_add() when computing offsets from firmware-provided values
in the RISC-V firmware parsing code. These values come from the BinHdr
structure parsed from the firmware file header.
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260126202305.2526618-6-joelagnelf@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Use checked_add() when computing the firmware data end offset in the
BinFirmware::data() method. The data_offset and data_size fields come
from the BinHdr structure parsed from the firmware file header.
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260126202305.2526618-5-joelagnelf@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Use checked_add() when computing the end offset in the frombytes_at()
helper function. This function is called with firmware-provided offsets.
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260126202305.2526618-4-joelagnelf@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Use checked_add() when computing signature offsets from firmware-
provided values in signatures_iter().
Without checked arithmetic, overflow could wrap to a small plausible
offset that points to entirely wrong data.
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260126202305.2526618-3-joelagnelf@nvidia.com
[acourbot@nvidia.com: remove obvious computation comments.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Use checked_add() and checked_mul() when computing offsets from
firmware-provided values in new_fwsec().
Without checked arithmetic, corrupt firmware could cause integer
overflow. The danger is not just wrapping to a huge value, but
potentially wrapping to a small plausible offset that passes validation
yet accesses entirely wrong data, causing silent corruption or security
issues.
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260126202305.2526618-2-joelagnelf@nvidia.com
[acourbot@nvidia.com: rewrap commit message to make checkpatch happy.]
[acourbot@nvidia.com: add missing empty lines after new code blocks.]
[acourbot@nvidia.com: move SAFETY comments to the unsafe statement they
describe.]
[acourbot@nvidia.com: remove obvious computation comments and use
`CALC:` for the remaining ones.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
During system resume, the following errors occurred:
[ 430.638625] mmc1: error -84 writing Cache Enable bit
[ 430.643618] mmc1: error -84 doing runtime resume
For eMMC and SD, there are two tuning pass windows and the gap between
those two windows may only have one cell. If tuning step > 1, the gap may
just be skipped and host assumes those two windows as a continuous
windows. This will cause a wrong delay cell near the gap to be selected.
Set the tuning step to 1 to avoid selecting the wrong delay cell.
For SDIO, the gap is sufficiently large, so the default tuning step does
not cause this issue.
Fixes: e37907bd82 ("arm64: dts: freescale: add i.MX93 11x11 EVK basic support")
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
During system resume, the following errors occurred:
[ 430.638625] mmc1: error -84 writing Cache Enable bit
[ 430.643618] mmc1: error -84 doing runtime resume
For eMMC and SD, there are two tuning pass windows and the gap between
those two windows may only have one cell. If tuning step > 1, the gap may
just be skipped and host assumes those two windows as a continuous
windows. This will cause a wrong delay cell near the gap to be selected.
Set the tuning step to 1 to avoid selecting the wrong delay cell.
For SDIO, the gap is sufficiently large, so the default tuning step does
not cause this issue.
Fixes: 6772c4cffd ("arm64: dts: freescale: add i.MX91 11x11 EVK basic support")
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
The test_sys_enter_exit test was setting target_pid before attaching
the BPF programs, which causes syscalls made during the attach phase
to be counted. This is flaky because, apparently, there is no
guarantee that both on_enter and on_exit will trigger during the
attachment.
Move the target_pid assignment to after task_local_storage__attach()
so that only explicit sys_gettid() calls are counted.
Reported-by: BPF CI Bot (Claude Opus 4.6) <bot+bpf-ci@kernel.org>
Closes: https://github.com/kernel-patches/vmtest/issues/448
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/r/20260224211202.214325-1-ihor.solodrai@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Fix a bug where kunit_run_irq_test() could hang if the system is too
slow. This was noticed with the crypto library tests in certain VMs.
Specifically, if kunit_irq_test_timer_func() and the associated hrtimer
code took over 5us to run, then the CPU would spend all its time
executing that code in hardirq context. As a result, the task executing
kunit_run_irq_test() never had a chance to run, exit the loop, and
cancel the timer.
To fix it, make kunit_irq_test_timer_func() increase the timer interval
when the other contexts aren't having a chance to run.
Fixes: 950a81224e ("lib/crypto: tests: Add hash-test-template.h and gen-hash-testvecs.py")
Cc: stable@vger.kernel.org
Reviewed-by: David Gow <david@davidgow.net>
Link: https://lore.kernel.org/r/20260224033751.97615-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Wa_15010599737 was a workaround originally proposed (and ultimately
rejected) for DG2-G10. There's no record of it ever being relevant or
even considered for any other platforms.
The specific bit this workaround was setting is documented as "This bit
should be set to 1 for the DX9 API and 0 for all other APIs" which means
that it should almost always be left at the default value of 0 on Linux.
The register itself is directly accessible from userspace, so in the
special cases where it might be relevant (e.g., Wine/Proton running
Windows DX9 apps), the userspace drivers already have the ability to
change the setting without involvement of the kernel.
Fixes: 7f3ee7d880 ("drm/xe/xe2hpg: Add initial GT workarounds")
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260223-forupstream-wa_cleanup-v3-2-7f201eb2f172@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_18041344222 applies to all graphics versions from 20.01 through 30.00
(inclusive). Consolidate the RTP entries into a single range-based
entry.
v2:
- Drop the FUNC(xe_rtp_match_not_sriov_vf) to align with commit
a800b95c24 ("drm/xe/xe2hpg: Remove SRIOV VF check for
Wa_18041344222") and commit 0ffe9dcf26 ("drm/xe/xe3: Remove SRIOV
VF check for Wa_18041344222") which just landed. (Shuicheng)
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260223-forupstream-wa_cleanup-v3-1-7f201eb2f172@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Zloop uses a command option parser for all control commands,
but most options are only valid for adding a new device. Check
for incorrectly specified options in the remove handler.
Fixes: eb0570c7df ("block: new zoned loop block device driver")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Zloop is file system backed and thus needs to sync the underlying file
system to persist data. Set BLK_FEAT_WRITE_CACHE so that the block
layer actually send flush commands, and fix the flush implementation
as sync_filesystem requires s_umount to be held and the code currently
misses that.
Fixes: eb0570c7df ("block: new zoned loop block device driver")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
There have been several renamings and modified Make rules since
introduction of this unittest document.
The file list in the Chinese translation had been extended.
For a change to drivers/of/unittest-data/tests-*.dtsi surrounding
translation has to be updated.
Signed-off-by: Markus Heidelberg <m.heidelberg@cab.de>
Link: https://patch.msgid.link/20260223111207.54640-1-m.heidelberg@cab.de
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Move compatibles for Qualcomm Kryo and Oryon custom CPU cores out of the
enum into separate one with deprecated: true annotation, because these
are too generic names.
These are names of the families and there are significant differences
within individual processors, e.g. Kryo6xx can based on architectures
from Cortex-X2, A710, A510 to A78 and probably more.
Just like other vendor processors are differentiated, also Qualcomm CPUs
should come with specific compatibles.
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Konrad Dybcio <konradybcio@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://patch.msgid.link/20260223074422.18468-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Add DT compatible string for NXP i.MX93 Wireless EVK board.
i.MX93 Wireless SiP is created by integrating i.MX93 and IW610 WLCSP
(Wi-Fi + BLE + 802.15.4). And i.MX93 Wireless EVK board with the i.MX93
Wireless SiP basically reuse the i.MX93 11x11 EVK board, with some minor
functional and pin connection differences.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
The sdma script app_2_mcu needs the permission to access the peripheral
devices:
1) SDMA2 transactions are set to user-mode in this particular case.
2) This type of script doesn't use the peripheral interface (connected
directly to SPBA), but it uses the peripheral DMA interface, then the
SDMA2-issued transactions are subjected to AIPSTZ5's security-related
checks.
So need to clear the Supervisor Protect bit of SPBA2, otherwise the sdma
script can't work. As the imx-aipstz is a common driver for all aips bus,
so set default value (zero) for all opacr registers.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
i.MX93 SoC mediamix blk-ctrl contains one DISPLAY_MUX register which
configures parallel display format by using the "PARALLEL_DISP_FORMAT"
field. Document the Parallel Display Format Configuration(PDFC) subnode
and add the subnode to example.
[m.felsch@pengutronix.de: add bus-width]
Signed-off-by: Liu Ying <victor.liu@nxp.com>
[m.felsch@pengutronix.de: port to v6.18-rc1]
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the
DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which
reinitializes the waitqueue list head to empty.
Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the
same DVR device share it), this orphans any existing waitqueue entries
from io_uring poll or epoll, leaving them with stale prev/next pointers
while the list head is reset to {self, self}.
The waitqueue and spinlock in dvr_buffer are already properly
initialized once in dvb_dmxdev_init(). The open path only needs to
reset the buffer data pointer, size, and read/write positions.
Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct
assignment of data/size and a call to dvb_ringbuffer_reset(), which
properly resets pread, pwrite, and error with correct memory ordering
without touching the waitqueue or spinlock.
Cc: stable@vger.kernel.org
Fixes: 34731df288 ("V4L/DVB (3501): Dmxdev: use dvb_ringbuffer")
Reported-by: syzbot+ab12f0c08dd7ab8d057c@syzkaller.appspotmail.com
Tested-by: syzbot+ab12f0c08dd7ab8d057c@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/698a26d3.050a0220.3b3015.007d.GAE@google.com/
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Have reserved eDMA2 channels 0 and 1 for V2X fast hash in imx95.dtsi.
So update the dma-channel-mask from 0xc0000000 to 0xc0000003 to mark
channels 0, 1, 30, and 31 as reserved.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reserve eDMA channels 0 and 1 on the AXI eDMA controller for exclusive
use by V2X (Vehicle-to-Everything) fast hash operations.
Reviewed-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Tested-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
i.MX93 Wireless SiP is created by integrating i.MX93 and IW610 WLCSP
(Wi-Fi + BLE + 802.15.4). And i.MX93 Wireless EVK board with the i.MX93
Wireless SiP basically reuse the i.MX93 11x11 EVK board, with some minor
functional and pin connection differences. Reuse the new
imx93-11x11-evk-common.dtsi and add the board-specific changes here.
Here are the detailed differences between i.MX93 Wireless EVK and i.MX93
11x11 EVK board.
Function differences:
Function i.MX93W EVK i.MX93 EVK
WIFI/BT IW610 in i.MX93W IW612 M.2 module
MQS N Y
PDM MIC N Y
M.2 N Y
RPi 40-pin HDR Limited support(pin conflict) Y
Pin connection differences:
Function Signal name i.MX93W EVK i.MX93 EVK
WIFI/BT SPI_FRM SAI1_TXFS (spi1.PCS0) GPIO_IO08 (spi3.PCS0)
SPI_TXD SAI1_TXC (spi1.SIN) GPIO_IO09 (spi3.SIN)
SPI_RXD SAI1_RXD0 (spi1.SOUT) GPIO_IO10 (spi3.SOUT)
SPI_CLK SAI1_TXD0 (spi1.SCK) GPIO_IO11 (spi3.SCK)
SPI_INT CCM_CLKO1 on-board IO expander
NB_WAKE_IN PDM_CLK on-module IO expander
WL_WAKE_IN PDM_BIT_STREAM0 on-module IO expander
IND_RST_WL PDM_BIT_STREAM1 on-module IO expander
IND_RST_NB GPIO_IO28 on-module IO expander
PDn GPIO_IO29 on-module IO expander
NB_WAKE_OUT GPIO_IO14 on-board IO expander
WL_WAKE_OUT GPIO_IO15 CCM_CLKO1
I2C3 I2C3_SDA GPIO_IO00 GPIO_IO28
I2C3_SCL GPIO_IO01 GPIO_IO29
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Introduce imx93w.dtsi to describe the new NXP i.MX93 Wireless SiP, which
integrates the i.MX93 application processor with the NXP IW610 WLCSP
(Wi-Fi + Bluetooth LE + 802.15.4) connectivity device.
The new imx93w.dtsi is based on imx93.dtsi and adds the pieces required
for the internal connection between i.MX93 and IW610 inside the SiP.
This includes USDHC3 which is used as the host interface to the IW610
and the required GPIO settings(e.g. WL_RST, WL_REG_ON, etc.).
These nodes reflect internal SiP wiring and are not board specific, so
they are placed in a dedicated imx93w.dtsi file that can be reused by
multiple boards adopting the i.MX93 Wireless SiP.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
The previous patch renamed imx93-11x11-evk.dts to
imx93-11x11-evk-common.dtsi to prepare for adding the i.MX93 Wireless
EVK, which shares most of its design with the 11x11 EVK.
Move the board specific differences out of imx93-11x11-evk-common.dtsi
and back into imx93-11x11-evk.dts, ensuring that the common dtsi only
contains the truly shared parts between the two EVK boards.
No functional changes intended.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
The i.MX93 Wireless EVK reuses most of the 11x11 EVK design. To avoid
duplication and DTS-to-DTS includes, extract the common parts into a new
imx93-11x11-evk-common.dtsi shared by both boards.
Rename imx93-11x11-evk.dts to imx93-11x11-evk-common.dtsi and include it
from imx93-11x11-evk.dts.
Only structural changes are introduced, with no intended functional
impact.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
During system resume, the following errors occurred:
[ 430.638625] mmc1: error -84 writing Cache Enable bit
[ 430.643618] mmc1: error -84 doing runtime resume
For eMMC and SD, there are two tuning pass windows and the gap between
those two windows may only have one cell. If tuning step > 1, the gap may
just be skipped and host assumes those two windows as a continuous
windows. This will cause a wrong delay cell near the gap to be selected.
Set the tuning step to 1 to avoid selecting the wrong delay cell.
For SDIO, the gap is sufficiently large, so the default tuning step does
not cause this issue.
Fixes: 0565d20cd8 ("arm64: dts: freescale: Support i.MX93 9x9 Quick Start Board")
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Add support for AONMIX MQS (i.e. MQS1).
Reviewed-by: Chancel Liu <chancel.liu@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Add DT node for AONMIX MQS (i.e. MQS1).
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Fix the PMIC_SD2_VSEL gpio-line-name position. It should be on line 19
of gpio3, not line 20.
Fixes: 90bbe88e0e ("arm64: dts: freescale: add Toradex SMARC iMX95")
Cc: stable@vger.kernel.org
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Rename at45db321d@1 to flash@1 to fix below CHECK_DTBS warnings:
at45db321d@1 (atmel,at45db321d): $nodename:0: 'at45db321d@1' does not match '^(flash|.*sram|nand)(@.*)?$'
from schema $id: http://devicetree.org/schemas/mtd/atmel,dataflash.yaml
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Change node name fpga@0 to fpga@0,0 to fix below CHECK_DTBS warnings:
memory-controller@83fda000 (fsl,imx51-weim): 'fpga@0' does not match any of the regexes: '^.*@[0-7],[0-9a-f]+$', '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/memory-controllers/fsl/fsl,imx-weim.yam
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Remove simple bus 'usbphy' and move chip nodes to up layers to fix below
CHECK_DTBS warnings.
arch/arm/boot/dts/nxp/imx/imx35-pdk.dtb: usbphy (simple-bus): usb-phy@1:reg:0: [1] is too short
from schema $id: http://devicetree.org/schemas/simple-bus.yaml
Remove property 'reg' because it is never used at driver.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Rename the i2c clock-names from "ipg_per" to "ipg" to match the binding
documentation.
Fix the following CHECK_DTBS warning:
i2c@43f80000 (fsl,imx35-i2c): clock-names:0: 'ipg' was expected
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Rename emi to emi-bus to fix below CHECK_DTBS warning:
arch/arm/boot/dts/nxp/imx/imx31-bug.dtb: emi@b8000000 (simple-bus): $nodename:0: 'emi@b8000000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|localbus|soc|axi|ahb|apb)(@.+)?$'
from schema $id: http://devicetree.org/schemas/simple-bus.yaml
Signed-off-by: Frank Li <Frank.Li@nxp.com>
According to i.MX 8M Quad Reference Manual, GPU_AHB_CLK_ROOT's maximum
frequency is 400MHz.
Fixes: 45d2c84eb3 ("arm64: dts: imx8mq: add GPU node")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
According to JESD223F, the maximum number of queues (MAXQ) is 32. When MCQ
is enabled and ESI is disabled, nr_hw_queues=32 causes a shift overflow
problem.
Fix this by using 64-bit intermediate values to handle the nr_hw_queues=32
case safely.
Signed-off-by: wangshuaiwei <wangshuaiwei1@xiaomi.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20260224063228.50112-1-wangshuaiwei1@xiaomi.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Use my kernel.org email address.
Link: https://lkml.kernel.org/r/20260223160027.122307-1-yosry@kernel.org
Signed-off-by: Yosry Ahmed <yosry@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Nhat Pham <nphamcs@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
My Intel email is going to bounce soon. Map it to my personal Gmail
address.
Link: https://lkml.kernel.org/r/20260223170905.278956-1-daniele.alessandrelli@intel.com
Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
Cc: Daniele Alessandrelli <daniele.alessandrelli@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Commit d49004c5f0 ("arch, mm: consolidate initialization of nodes, zones
and memory map") moved free_area_init() from setup_arch() to
mm_core_init_early(), which runs after setup_arch() returns.
This changed the ordering relative to init_cpu_to_node() on x86. Before
the commit, free_area_init() ran during paging_init() (called from
setup_arch()) *before* init_cpu_to_node(). After the commit, it runs
*after* init_cpu_to_node().
On machines with memoryless NUMA nodes (e.g., node 0 has CPUs but no
memory), this causes a NULL pointer dereference:
1. numa_register_nodes() skips memoryless nodes: no alloc_node_data()
and no node_set_online() for them.
2. init_cpu_to_node() sets memoryless nodes online (they have CPUs)
but does not allocate NODE_DATA.
3. free_area_init() checks "if (!node_online(nid))" to decide whether
to call alloc_offline_node_data(). Since the memoryless node is now
online, the allocation is skipped, leaving NODE_DATA(nid) == NULL.
4. The immediate "pgdat = NODE_DATA(nid)" dereferences NULL.
The crash happens before console_init(), so no output is visible without
earlyprintk. With earlyprintk enabled, the following panic is observed:
BUG: unable to handle page fault for address: 000000000002a1e0
Oops: Oops: 0000 [#1] SMP NOPTI
RIP: 0010:free_area_init_node+0x3a/0x540
Call Trace:
<TASK>
free_area_init+0x331/0x4e0
start_kernel+0x69/0x4a0
x86_64_start_reservations+0x24/0x30
x86_64_start_kernel+0x125/0x130
common_startup_64+0x13e/0x148
</TASK>
Kernel panic - not syncing: Attempted to kill the idle task!
Fix this by checking "if (!NODE_DATA(nid))" instead of "if
(!node_online(nid))". This directly tests whether the per-node data
structure needs to be allocated, regardless of the node's online status.
This change is also safe for non-x86 architectures as they all allocate
NODE_DATA for every node including memoryless ones, so the check simply
evaluates to false with no change in behavior.
Link: https://lkml.kernel.org/r/20260222115702.3659-1-ming.lei@redhat.com
Fixes: d49004c5f0 ("arch, mm: consolidate initialization of nodes, zones and memory map")
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
