Commit graph

1,309,163 commits

Author SHA1 Message Date
Bitterblue Smith
faa2e484b3 wifi: rtw88: Fix USB/SDIO devices not transmitting beacons
All USB devices supported by rtw88 have the same problem: they don't
transmit beacons in AP mode. (Some?) SDIO devices are also affected.
The cause appears to be clearing BIT_EN_BCNQ_DL of REG_FWHW_TXQ_CTRL
before uploading the beacon reserved page, so don't clear the bit for
USB and SDIO devices.

Tested with RTL8811CU and RTL8723DU.

Cc: <stable@vger.kernel.org> # 6.6.x
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/49de73b5-698f-4865-ab63-100e28dfc4a1@gmail.com
2024-09-02 08:36:01 +08:00
Inochi Amaoto
585dcb21cc riscv: dts: sophgo: Add mcu device for Milk-V Pioneer
Add mcu device and thermal zones node for Milk-V Pioneer.

Tested-by: Chen Wang <unicorn_wang@outlook.com>
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
Link: https://lore.kernel.org/r/IA1PR20MB4953C675C28B35723E87A36BBB822@IA1PR20MB4953.namprd20.prod.outlook.com
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
2024-09-02 08:35:13 +08:00
Chen Wang
a508d794f8 riscv: sophgo: dts: add gpio controllers for SG2042 SoC
Add support for the GPIO controller of Sophgo SG2042.

SG2042 uses IP from Synopsys DesignWare APB GPIO and has
three GPIO controllers.

Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
Link: https://lore.kernel.org/r/20240819080851.1954691-1-unicornxw@gmail.com
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
2024-09-02 08:35:13 +08:00
Chen Wang
014b839f79 riscv: sophgo: dts: add mmc controllers for SG2042 SoC
SG2042 has two MMC controller, one for emmc, another for sd-card.

Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
Link: https://lore.kernel.org/r/03ac9ec9c23bbe4c3b30271e76537bdbe5638665.1722847198.git.unicorn_wang@outlook.com
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
2024-09-02 08:35:12 +08:00
Inochi Amaoto
c8eb04aecd riscv: dts: sophgo: Add i2c device support for sg2042
The i2c ip of sg2042 is a standard Synopsys i2c ip, which is already
supported by the mainline kernel.

Add i2c device node for sg2042.

Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
Tested-by: Chen Wang <unicorn_wang@outlook.com>
Link: https://lore.kernel.org/r/IA1PR20MB49530E59974AF0FCA4FAB6DBBBB72@IA1PR20MB4953.namprd20.prod.outlook.com
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
2024-09-02 08:35:12 +08:00
Inochi Amaoto
5d9e6bc82b riscv: dts: sophgo: Use common "interrupt-parent" for all peripherals for sg2042
As all peripherals of sg2042 share the same "interrupt-parent",
there is no need to use peripherals specific "interrupt-parent".
Define "interrupt-parent" in the SoC level.

Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
Tested-by: Chen Wang <unicorn_wang@outlook.com>
Link: https://lore.kernel.org/r/IA1PR20MB49531F6DFD2F116207C1397DBBB72@IA1PR20MB4953.namprd20.prod.outlook.com
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
2024-09-02 08:35:12 +08:00
Inochi Amaoto
63c33528b7 riscv: dts: sophgo: Add sdhci0 configuration for Huashan Pi
Add configuration for sdhci0 for Huashan Pi to support sd card.

Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
Link: https://lore.kernel.org/r/IA1PR20MB49538AC83C5DB314D10F7186BBA92@IA1PR20MB4953.namprd20.prod.outlook.com
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
2024-09-02 08:32:11 +08:00
Inochi Amaoto
514951a81a riscv: dts: sophgo: cv18xx: add DMA controller
Add DMA controller dt node for CV18XX/SG200x.

Link: https://lore.kernel.org/r/IA1PR20MB4953BD73E12B8A1CDBD9E1A3BB042@IA1PR20MB4953.namprd20.prod.outlook.com
Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
2024-09-02 08:32:11 +08:00
Tim Harvey
e09e0a7ae3 dt-bindings: arm: fsl: rename gw7905 to gw75xx
The GW7905 was renamed to GW7500 before production release.

While we typically do not change compatibles, the GW7905 was never
released before its product name was changed to a GW7500.

The use the the 'xx' wildcard is to denote the fact that this
device-tree can support range of board models from GW7500 to GW7599 as
has been done historically with the Gateworks baseboards to support
various build customizatoins based on the same PCB.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-09-02 08:19:11 +08:00
Markus Niebel
968a549cca ARM: dts: imx6qdl-mba6b: remove doubled entry for I2C1 pinmux
Since the muxing is described already in imx6qdl-tqma6 can be reused
by this variant. No functional change.

Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-09-02 08:17:55 +08:00
Markus Niebel
0bfef93bd6 ARM: dts: imx6qdl-mba6: improve compatible for LM75 temp sensor
Use national,lm75a to specify exact variant used. This should cause
no functional changes.

Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-09-02 08:17:54 +08:00
Markus Niebel
5d0813c2f7 ARM: dts: imx6qdl-tqma6: improve compatible for LM75 temp sensor
Use national,lm75a to specify exact variant used. This should cause
no functional changes.

While at it change node name to 'temperature-sensor@48' to
describe the function of the IC.

Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-09-02 08:17:54 +08:00
Markus Niebel
135be5386d ARM: dts: imx6qdl-tqma6: move i2c3 pinmux to imx6qdl-tqma6b
Move the pinmux entries to the variant where they are actual
used. No functional changes.

Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-09-02 08:17:54 +08:00
Dmitry Baryshkov
1530257937 drm/msm/dpu: enable writeback on SM6350
Enable WB2 hardware block, enabling writeback support on this platform.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Luca Weiss <luca.weiss@fairphone.com>
Patchwork: https://patchwork.freedesktop.org/patch/570194/
Link: https://lore.kernel.org/r/20231203003203.1293087-5-dmitry.baryshkov@linaro.org
2024-09-02 02:53:44 +03:00
Dmitry Baryshkov
ab2b03d73a drm/msm/dpu: enable writeback on SM6125
Enable WB2 hardware block, enabling writeback support on this platform.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/570193/
Link: https://lore.kernel.org/r/20231203003203.1293087-4-dmitry.baryshkov@linaro.org
2024-09-02 02:53:44 +03:00
Dmitry Baryshkov
1f5bcc4316 drm/msm/dpu: enable writeback on SC8108X
Enable WB2 hardware block, enabling writeback support on this platform.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/570196/
Link: https://lore.kernel.org/r/20231203003203.1293087-3-dmitry.baryshkov@linaro.org
2024-09-02 02:53:44 +03:00
Dmitry Baryshkov
47cebb740a drm/msm/dpu: enable writeback on SM8150
Enable WB2 hardware block, enabling writeback support on this platform.

Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/570192/
Link: https://lore.kernel.org/r/20231203003203.1293087-2-dmitry.baryshkov@linaro.org
[DB: picked up WB_SDM845_MASK from sdm845 patch]
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-09-02 02:53:44 +03:00
Sherry Yang
25b8507515 drm/msm: fix %s null argument error
The following build error was triggered because of NULL string argument:

BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c: In function 'mdp5_smp_dump':
BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:352:51: error: '%s' directive argument is null [-Werror=format-overflow=]
BUILDSTDERR:   352 |                         drm_printf(p, "%s:%d\t%d\t%s\n",
BUILDSTDERR:       |                                                   ^~
BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:352:51: error: '%s' directive argument is null [-Werror=format-overflow=]

This happens from the commit a61ddb4393 ("drm: enable (most) W=1
warnings by default across the subsystem"). Using "(null)" instead
to fix it.

Fixes: bc5289eed4 ("drm/msm/mdp5: add debugfs to show smp block status")
Signed-off-by: Sherry Yang <sherry.yang@oracle.com>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/611071/
Link: https://lore.kernel.org/r/20240827165337.1075904-1-sherry.yang@oracle.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-09-02 02:53:44 +03:00
Dmitry Baryshkov
1328cb7c34 drm/msm/dsi: correct programming sequence for SM8350 / SM8450
According to the display-drivers, 5nm DSI PLL (v4.2, v4.3) have
different boundaries for pll_clock_inverters programming. Follow the
vendor code and use correct values.

Fixes: 2f9ae4e395 ("drm/msm/dsi: add support for DSI-PHY on SM8350 and SM8450")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/606947/
Link: https://lore.kernel.org/r/20240804-sm8350-fixes-v1-3-1149dd8399fe@linaro.org
2024-09-02 02:53:44 +03:00
Abhinav Kumar
c7c4122026 drm/msm/dp: enable widebus on all relevant chipsets
Hardware document indicates that widebus is recommended on DP on all
MDSS chipsets starting version 5.x.x and above.

Follow the guideline and mark widebus support on all relevant
chipsets for DP.

Fixes: 766f705204 ("drm/msm/dp: Remove now unused connector_type from desc")
Fixes: 1b2d98bdd7 ("drm/msm/dp: Add DisplayPort controller for SM8650")
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes: 757a2f36ab ("drm/msm/dp: enable widebus feature for display port")
Fixes: 1b2d98bdd7 ("drm/msm/dp: Add DisplayPort controller for SM8650")
Patchwork: https://patchwork.freedesktop.org/patch/606556/
Link: https://lore.kernel.org/r/20240730195012.2595980-1-quic_abhinavk@quicinc.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-09-02 02:53:44 +03:00
Arnaud Vrac
caedbf17c4 drm/msm: add msm8998 hdmi phy/pll support
Add support for the HDMI PHY as present on the Qualcomm MSM8998 SoC.
This code is mostly copy & paste of the vendor code from msm-4.4
kernel.lnx.4.4.r38-rel.

Signed-off-by: Arnaud Vrac <avrac@freebox.fr>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr>
Patchwork: https://patchwork.freedesktop.org/patch/605631/
Link: https://lore.kernel.org/r/20240724-hdmi-tx-v7-4-e44a20553464@freebox.fr
[DB: replaced division with do_div64 to fix build issues on ARM32]
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-09-02 02:53:44 +03:00
Marc Gonzalez
a61eb17f40 drm/msm/hdmi: add "qcom,hdmi-tx-8998" compatible
Current driver already supports the msm8998 HDMI TX.
We just need to add the compatible string.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr>
Patchwork: https://patchwork.freedesktop.org/patch/605632/
Link: https://lore.kernel.org/r/20240724-hdmi-tx-v7-3-e44a20553464@freebox.fr
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-09-02 02:53:44 +03:00
Marc Gonzalez
656810411b dt-bindings: display/msm: hdmi: add qcom,hdmi-tx-8998
HDMI TX block embedded in the APQ8098.

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr>
Patchwork: https://patchwork.freedesktop.org/patch/605638/
Link: https://lore.kernel.org/r/20240724-hdmi-tx-v7-2-e44a20553464@freebox.fr
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-09-02 02:53:44 +03:00
Marc Gonzalez
8886def25e dt-bindings: phy: add qcom,hdmi-phy-8998
HDMI PHY block embedded in the APQ8098.

Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr>
Patchwork: https://patchwork.freedesktop.org/patch/605634/
Link: https://lore.kernel.org/r/20240724-hdmi-tx-v7-1-e44a20553464@freebox.fr
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-09-02 02:53:44 +03:00
Dmitry Baryshkov
be3415c620 drm/msm/dpu: Configure DP INTF/PHY selector
Some platforms provides a mechanism for configuring the mapping between
(one or two) DisplayPort intfs and their PHYs.

In particular SC8180X requires this to be configured, since on this
platform there are fewer controllers than PHYs.

The change implements the logic for optionally configuring which PHY
each of the DP INTFs should be connected to and marks the SC8180X DPU to
program 2 entries.

For now the request is simply to program the mapping 1:1, any support
for alternative mappings is left until the use case arrise.

Note that e.g. msm-4.14 unconditionally maps INTF 0 to PHY 0 on all
platforms, so perhaps this is needed in order to get DisplayPort working
on some other platforms as well.

Co-developed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/600895/
Link: https://lore.kernel.org/r/20240625-dp-phy-sel-v3-1-c77c7066c454@linaro.org
2024-09-02 02:53:31 +03:00
Liao Chen
0f3e1eaaf7 ata: sata_gemini: Enable module autoloading
Add MODULE_DEVICE_TABLE(), so modules can be properly autoloaded based
on the alias from of_device_id table.

Signed-off-by: Liao Chen <liaochen4@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2024-09-02 08:06:23 +09:00
Liao Chen
619c98622b ata: pata_ixp4xx: Enable module autoloading
Add MODULE_DEVICE_TABLE(), so modules can be properly autoloaded based
on the alias from of_device_id table.

Signed-off-by: Liao Chen <liaochen4@huawei.com>
Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2024-09-02 08:06:04 +09:00
Liao Chen
4b4e1a961f ata: pata_ftide010: Enable module autoloading
Add MODULE_DEVICE_TABLE(), so modules can be properly autoloaded based
on the alias from of_device_id table.

Signed-off-by: Liao Chen <liaochen4@huawei.com>
Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2024-09-02 08:05:36 +09:00
Linus Torvalds
c9f016e72b A set of X86 fixes:
- x2apic_disable() clears x2apic_state and x2apic_mode unconditionally,
     even when the state is X2APIC_ON_LOCKED, which prevents the kernel to
     disable it thereby creating inconsistent state.
 
     Reorder the logic so it actually works correctly
 
   - The XSTATE logic for handling LBR is incorrect as it assumes that
     XSAVES supports LBR when the CPU supports LBR. In fact both conditions
     need to be true. Otherwise the enablement of LBR in the IA32_XSS MSR
     fails and subsequently the machine crashes on the next XRSTORS
     operation because IA32_XSS is not initialized.
 
     Cache the XSTATE support bit during init and make the related functions
     use this cached information and the LBR CPU feature bit to cure this.
 
   - Cure a long standing bug in KASLR
 
     KASLR uses the full address space between PAGE_OFFSET and vaddr_end to
     randomize the starting points of the direct map, vmalloc and vmemmap
     regions.  It thereby limits the size of the direct map by using the
     installed memory size plus an extra configurable margin for hot-plug
     memory.  This limitation is done to gain more randomization space
     because otherwise only the holes between the direct map, vmalloc,
     vmemmap and vaddr_end would be usable for randomizing.
 
     The limited direct map size is not exposed to the rest of the kernel, so
     the memory hot-plug and resource management related code paths still
     operate under the assumption that the available address space can be
     determined with MAX_PHYSMEM_BITS.
 
     request_free_mem_region() allocates from (1 << MAX_PHYSMEM_BITS) - 1
     downwards.  That means the first allocation happens past the end of the
     direct map and if unlucky this address is in the vmalloc space, which
     causes high_memory to become greater than VMALLOC_START and consequently
     causes iounmap() to fail for valid ioremap addresses.
 
     Cure this by exposing the end of the direct map via PHYSMEM_END and use
     that for the memory hot-plug and resource management related places
     instead of relying on MAX_PHYSMEM_BITS. In the KASLR case PHYSMEM_END
     maps to a variable which is initialized by the KASLR initialization and
     otherwise it is based on MAX_PHYSMEM_BITS as before.
 
   - Prevent a data leak in mmio_read(). The TDVMCALL exposes the value of
     an initialized variabled on the stack to the VMM. The variable is only
     required as output value, so it does not have to exposed to the VMM in
     the first place.
 
   - Prevent an array overrun in the resource control code on systems with
     Sub-NUMA Clustering enabled because the code failed to adjust the index
     by the number of SNC nodes per L3 cache.
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmbUUu0THHRnbHhAbGlu
 dXRyb25peC5kZQAKCRCmGPVMDXSYodFsEADFgxq2wjnH+VpuaIhLiQIfUa7iVeUl
 bwHAakZRMJ+Cb8BsvaRCMdAWWF+cRdLabAHuh7MRJFFzzdwrVTswnxT9baUBBjEe
 Kd3ZeQOS4AvWxpJNQEDg9r7tYtavmml9ix+Jh0OF+YmXLIweQk5RhDN+ncha07cJ
 0DuPt4ngI24iyAyUX+7gZsRZiwoOm0HqImaRiisaspTbGpNwnrwFQCEioCdwnAv0
 H5S7WTAlsZURCINLBNT+fV5oPjk2E3Ckj/CCJGoG1LYedGUD/44M1Hj0Xsqm4pHF
 Zd0+CuFyYpGqkAuBY6moWOheYP8V2U+yhf9Rtvh8/+h3qxZ/yon5i0ycO/2wMjiF
 0NBomMeKh4PNyefYq8lHWK3kcXphrXH3yv09wVBDdLMXDy98beuS5NScGgza8148
 /nqq0l1uLUyM9TkWg9H+4wW73EzQW1DYIliDU3tC98u+E77kQbyCx+2f0WI2k+ar
 3wy7nYzyEJXl38NUTB+La4xXbhsELcaYQ/Q6scIsWAL+6+KlRb3FNBn+HT+KmOmF
 y702km/28C0uxrLk2OQCjX/zXQtXe2/4aoUzGqFf9atsifa0IBrc8YBzdIDB49Jt
 zz/MOAZTcz4jfyD3sRfYuG2QhBbdTz3f/kd3OryquitdAGozpoeztMIGs1PU2Y6s
 zInlLtUwaosadg==
 =T4i1
 -----END PGP SIGNATURE-----

Merge tag 'x86-urgent-2024-09-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull x86 fixes from Thomas Gleixner:

 - x2apic_disable() clears x2apic_state and x2apic_mode unconditionally,
   even when the state is X2APIC_ON_LOCKED, which prevents the kernel to
   disable it thereby creating inconsistent state.

   Reorder the logic so it actually works correctly

 - The XSTATE logic for handling LBR is incorrect as it assumes that
   XSAVES supports LBR when the CPU supports LBR. In fact both
   conditions need to be true. Otherwise the enablement of LBR in the
   IA32_XSS MSR fails and subsequently the machine crashes on the next
   XRSTORS operation because IA32_XSS is not initialized.

   Cache the XSTATE support bit during init and make the related
   functions use this cached information and the LBR CPU feature bit to
   cure this.

 - Cure a long standing bug in KASLR

   KASLR uses the full address space between PAGE_OFFSET and vaddr_end
   to randomize the starting points of the direct map, vmalloc and
   vmemmap regions. It thereby limits the size of the direct map by
   using the installed memory size plus an extra configurable margin for
   hot-plug memory. This limitation is done to gain more randomization
   space because otherwise only the holes between the direct map,
   vmalloc, vmemmap and vaddr_end would be usable for randomizing.

   The limited direct map size is not exposed to the rest of the kernel,
   so the memory hot-plug and resource management related code paths
   still operate under the assumption that the available address space
   can be determined with MAX_PHYSMEM_BITS.

   request_free_mem_region() allocates from (1 << MAX_PHYSMEM_BITS) - 1
   downwards. That means the first allocation happens past the end of
   the direct map and if unlucky this address is in the vmalloc space,
   which causes high_memory to become greater than VMALLOC_START and
   consequently causes iounmap() to fail for valid ioremap addresses.

   Cure this by exposing the end of the direct map via PHYSMEM_END and
   use that for the memory hot-plug and resource management related
   places instead of relying on MAX_PHYSMEM_BITS. In the KASLR case
   PHYSMEM_END maps to a variable which is initialized by the KASLR
   initialization and otherwise it is based on MAX_PHYSMEM_BITS as
   before.

 - Prevent a data leak in mmio_read(). The TDVMCALL exposes the value of
   an initialized variabled on the stack to the VMM. The variable is
   only required as output value, so it does not have to exposed to the
   VMM in the first place.

 - Prevent an array overrun in the resource control code on systems with
   Sub-NUMA Clustering enabled because the code failed to adjust the
   index by the number of SNC nodes per L3 cache.

* tag 'x86-urgent-2024-09-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/resctrl: Fix arch_mbm_* array overrun on SNC
  x86/tdx: Fix data leak in mmio_read()
  x86/kaslr: Expose and use the end of the physical memory address space
  x86/fpu: Avoid writing LBR bit to IA32_XSS unless supported
  x86/apic: Make x2apic_disable() work correctly
2024-09-01 14:43:08 -07:00
Linus Torvalds
3df9427f35 A single fix for x86 performance monitoring:
Haswell PMUs suffer from several errata and require to limit the minimal
   period for counter events, otherwise they suffer from endless loops in
   the PMU interrupt.
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmbUUYwTHHRnbHhAbGlu
 dXRyb25peC5kZQAKCRCmGPVMDXSYoR4TEACtbidjmHaiVf+ZnYAhiknXlukEZTm4
 4VbUTke0N4A7nqZ/uOkzYOJHvu5ZTptIShJooZ+1Dzyt1Le8x35MB5XNxbpR77eR
 dugyPaFgwNOPrIHJBUOYrfKlckcKWdziKUWEKhfXBp0Us4DXxz4kdjK8ib+G+kFq
 1Gre8F4hw00i5enj1756Aq3eE8pQh+ATk39cGMZ5WtmSVDyG5bRQdxTQYtf6EUGa
 fOTfXy+20RU9qgKPwr7klmAseZZ+oAydK/IYofWmJAYWmDY0PSh0XL2d7hLPA9+k
 UdzdOZJymu8XE3esjy58igxUHyDO2E/X1RCUlqPbQJrGnLgg1uGg1ZuDia84UohO
 s1XyG7DOKjD/t1Rkz86DH+Vu8cmfMsmVeHmQXqaWScYB+X58sCoy3gQ4s776xYFo
 Cqay21FyHDueCaH2BUQ50gRpBe2BkpVichMtHpE/+EmftR0H62V/1AZ4UqWSD8Fk
 KTGb2YAaO4vBUJWijX+c2Dx+9zADeegtliF9kk+vz8PotHlLQto/ioajgyvAj/sn
 XHWmlAZlciUxKAZjX4MVLNQ6Y+twq7OccpKOagKCcDWDtolp1i3RfZv9OzsT5/oY
 s70q/KqNBwEAuYUP7DfE8i4fbDQTGEJfAroHeTBTVFsf2X+TEGHy/jjgxk0nm9wg
 BhNYXL3klDtWWA==
 =kGa7
 -----END PGP SIGNATURE-----

Merge tag 'perf-urgent-2024-09-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull perf fix from Thomas Gleixner:
 "A single fix for x86 performance monitoring.

  Haswell PMUs suffer from several errata and require a limit the
  minimal period for counter events, otherwise they suffer from endless
  loops in the PMU interrupt"

* tag 'perf-urgent-2024-09-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86/intel: Limit the period on Haswell
2024-09-01 14:33:31 -07:00
Linus Torvalds
51859c5aa6 A single fix for rt_mutex:
The deadlock detection code drops into an infinite scheduling loop while
   still holding rt_mutex::wait_lock, which rightfully triggers a
   'scheduling in atomic' warning. Unlock it before that.
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmbLKh0THHRnbHhAbGlu
 dXRyb25peC5kZQAKCRCmGPVMDXSYoSh0D/sHm7YsexyVAXRxtm1vCJ1rE+ditn/K
 X60QuH8EyLa2abUY9xKKKaM3YuE+4juN1dyej6uBcET8n9olqGQn0pyxukTDy3Hq
 Khy7OIAzYfGd7J0kJXA6DHMWAi16e4GduMcDYCw0BwYCQG4D1Ybe/lfsm0mgdcd/
 aLFSD8/+oAK7bIWy9VE4wXUPT51v7iFnwajvcKsOL1c3u2StF6A0zCLbjkU5Di20
 6Ko4f+B8dh3Bh9yIP/uiwHQHdVUjXp5Y9pVuFLemC8BqGVrwMi71jEEFYQva+evU
 UTQ8VCbhxIAcz6pqWYA3P5WeqFIQLAXq5UNJLK+63qm/Wf4eoaXNhK+Nr2fCigYu
 R6T+H5nx2WATATXfPORgfHYgHWwyWaj6nUPK0kaJYUTHFK5Nlg/ir5siqE/Gz9qq
 ldajnvKpheeuu6rsrdHdJrdI84XVOmjeAJ+5A8i7VMv2jEE50txlxXKt5jeVt2yE
 xm2+NABT4Dlycf/56e6OYZUEADQfX1YlvFGBQe1UYpcmOC1nTKaWWeQ1xlA3ZR92
 plUgXLtRSKaZ3vEFQ3L+/1w0Af3P3/mapb+IgTxW/FEt8WAw6UuwBS9gMZDOhTI+
 GZF0EFj8tUmTNDcWkNAu3m3y5Qmp3iVFYBbYXmyJdKVRJbaMu/uq51JnOOIxmaLf
 L6KovDUg8eF3bQ==
 =B3iX
 -----END PGP SIGNATURE-----

Merge tag 'locking-urgent-2024-08-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull locking fix from Thomas Gleixner:
 "A single fix for rt_mutex.

  The deadlock detection code drops into an infinite scheduling loop
  while still holding rt_mutex::wait_lock, which rightfully triggers a
  'scheduling in atomic' warning.

  Unlock it before that"

* tag 'locking-urgent-2024-08-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  rtmutex: Drop rt_mutex::wait_lock before scheduling
2024-09-01 14:26:33 -07:00
Linus Torvalds
9a754292e8 A set of fixes for interrupt chip drivers:
- Unbreak the PLIC driver for Allwinner D1 systems
 
     The recent conversion of the PLIC driver to a platform driver broke
     Allwinnder D1 systems due to the deferred probing of platform drivers.
 
     Due to that the only timer available on D1 systems cannot get an
     interrupt, which causes the system to hang at boot. Other RISCV
     platforms are not affected because they provide the architected SBI
     timer which uses the built in core interrupt controller.
 
     Cure this by probing PLIC early on D1 systems
 
   - Cure a regression in ARM/GIC-V3 on 32-bit ARM systems caused by the
     recent addition of a initialization function, which accesses system
     registers before they are enabled. On 64-bit ARM they are enabled
     prior to that by sheer luck.
 
     Ensure they are enabled.
 
   - Cure a use before check problem in the MSI library. The existing NULL
     pointer check is too late.
 
   - Cure a lock order inversion in the ARM/GIC-V4 driver
 
   - Fix a IS_ERR() vs. NULL pointer check issue in the RISCV APLIC driver
 
   - Plug a reference count leak in the ARM/GIC-V2 driver
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmbLKWcTHHRnbHhAbGlu
 dXRyb25peC5kZQAKCRCmGPVMDXSYoXhjD/4jfhR7ZLnpPpG1uGNJYYblYIg7NHPO
 5ZTHVYYDQ1SfiVBsPR8C95hgLeENbvonslUu5+uQEAq1m4rlpnYezeg4lOKeB5GX
 dx53VVWhoaAMDjTmBwYZwWPfAtWpNGHJIBAf7sLOJGOOnhkin1UqA/mvtOB6W7o0
 vVm64GlHtVNU/TlGbt/u6swgfzYLI9vsoQfJBhR+s9ymWF/NzZf/jSqUTbpoTKy3
 AuXCgTqqJoBFpVYyLJg/PVQyPXMfV32OpVkgeRtsubylT1fjvNY1sFSWVQqHtA5K
 GAjQv0CK5HwGvMtGF0ONZHw0i5ErUASyTuP68r6YFFZX+ki7hnZjVqU1zVlZ5eH0
 lkai6Md2iqePqzhFEl0QeXlo+QFFWTlM6uVOQprMzQuAidgiS0kMkT/YQLrB2jcj
 M8romsyoDPd4rlyqbQohaZzYbhx10qsYNQhMm/2XNK7x0eGSpr5NCaluqIWn+EsD
 e9dDYjS8Rg8lDo89cOoqLRbEJtBeILO/uBqjqFLs2espoHAp5P2IncA/QHj3xU+F
 JadGo7jRtOiw+KfJVc45O+wb/YcWR3QcCWlxgbIVzUer2iUq81CbxhX/P3pAktlQ
 sacMZtbS9iSQVuEGrblrOlTYVUAJd0olKi8HH7QDKERAxpywG/GNrMhlhsHsSFiu
 PJWX2ZtZILsknQ==
 =L+kH
 -----END PGP SIGNATURE-----

Merge tag 'irq-urgent-2024-08-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull irq fixes from Thomas Gleixner:
 "A set of fixes for interrupt chip drivers:

   - Unbreak the PLIC driver for Allwinner D1 systems

     The recent conversion of the PLIC driver to a platform driver broke
     Allwinnder D1 systems due to the deferred probing of platform
     drivers.

     Due to that the only timer available on D1 systems cannot get an
     interrupt, which causes the system to hang at boot. Other RISCV
     platforms are not affected because they provide the architected SBI
     timer which uses the built in core interrupt controller.

     Cure this by probing PLIC early on D1 systems

   - Cure a regression in ARM/GIC-V3 on 32-bit ARM systems caused by the
     recent addition of a initialization function, which accesses system
     registers before they are enabled. On 64-bit ARM they are enabled
     prior to that by sheer luck.

     Ensure they are enabled.

   - Cure a use before check problem in the MSI library. The existing
     NULL pointer check is too late.

   - Cure a lock order inversion in the ARM/GIC-V4 driver

   - Fix a IS_ERR() vs. NULL pointer check issue in the RISCV APLIC
     driver

   - Plug a reference count leak in the ARM/GIC-V2 driver"

* tag 'irq-urgent-2024-08-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip/irq-msi-lib: Check for NULL ops in msi_lib_irq_domain_select()
  irqchip/gic-v3: Init SRE before poking sysregs
  irqchip/gic-v2m: Fix refcount leak in gicv2m_of_init()
  irqchip/riscv-aplic: Fix an IS_ERR() vs NULL bug in probe()
  irqchip/gic-v4: Fix ordering between vmapp and vpe locks
  irqchip/sifive-plic: Probe plic driver early for Allwinner D1 platform
2024-09-01 14:19:00 -07:00
Apurva Nandan
5b035d14a5 arm64: dts: ti: k3-j722s-evm: Enable Inter-Processor Communication
The K3 J722S-EVM platform is based on the J722S SoC which has one
single-core Arm Cortex-R5F processor in each of the WAKEUP, MCU and MAIN
voltage domain, and two C71x DSP subsystems in MAIN voltage domain.

The Inter-Processor communication between the A53 cores and these R5F
and DSP remote cores is achieved through shared memory and Mailboxes.
Thus, add the memory carveouts and enable the mailbox clusters required
for communication.

Also, The remoteproc firmware like of R5F and DSPs in the MAIN voltage
domain use timers. Therefore, change the status of the timer nodes to
"reserved" to avoid any clash during booting of remotecores. Usage is
described as below:

	+===================+=============+
	|  Remoteproc Node  | Timer Node  |
	+===================+=============+
	| main_r5fss0_core0 | main_timer0 |
	+-------------------+-------------+
	| c7x_0             | main_timer1 |
	+-------------------+-------------+
	| c7x_1             | main_timer2 |
	+-------------------+-------------+

Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20240830161742.925145-3-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 16:07:42 -05:00
Apurva Nandan
05b1653c4f arm64: dts: ti: k3-j722s-main: Add R5F and C7x remote processor nodes
The K3 J722S SoCs have one single-core Arm Cortex-R5F processor in each
of the WAKEUP, MCU and MAIN voltage domain, and two C71x DSP subsystems
in MAIN voltage domain. Add the DT nodes to support Inter-Processor
Communication.

Signed-off-by: Apurva Nandan <a-nandan@ti.com>
[ refactoring changes to k3-j722s-main.dtsi ]
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240830161742.925145-2-b-padhi@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 16:07:32 -05:00
Prasanth Babu Mantena
ce9d793b2b arm64: dts: ti: k3-am68-sk-som: Update Partition info for OSPI Flash
Commit 73f1f26e2e ("arm64: dts: ti: k3-am68-sk-som: Add support
for OSPI flash") introduced the flash node with discontinuous
partitions. Updating the partition offset to be continuous from
the previous partition to maintain linearity.

Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
Link: https://lore.kernel.org/r/20240828060830.555733-1-p-mantena@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 16:06:30 -05:00
Kent Overstreet
7f12a963b6 bcachefs: fix rebalance accounting
Fixes: 49aa783039 ("bcachefs: Fix rebalance_work accounting")
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2024-09-01 15:54:40 -04:00
Wolfram Sang
64dce81f8c ipmi: docs: don't advertise deprecated sysfs entries
"i2c-adapter" class entries are deprecated since 2009. Switch to the
proper location.

Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
Closes: https://lore.kernel.org/r/80c4a898-5867-4162-ac85-bdf7c7c68746@gmail.com
Fixes: 259307074b ("ipmi: Add SMBus interface driver (SSIF)")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Message-Id: <20240901090211.3797-2-wsa+renesas@sang-engineering.com>
Signed-off-by: Corey Minyard <corey@minyard.net>
2024-09-01 14:35:35 -05:00
Robert Nelson
c5e615963b arm64: dts: ti: Add k3-am67a-beagley-ai
BeagleBoard.org BeagleY-AI is an easy to use, affordable open source
hardware single board computer based on the Texas Instruments AM67A,
which features a quad-core 64-bit Arm CPU subsystem, 2 general-purpose
digital-signal-processors (DSP) and matrix-multiply-accelerators (MMA),
GPU, vision and deep learning accelerators, and multiple Arm Cortex-R5
cores for low-power, low-latency GPIO control.

https://beagley-ai.org/
https://openbeagle.org/beagley-ai/beagley-ai

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Jared McArthur <j-mcarthur@ti.com>
Link: https://lore.kernel.org/r/20240829213929.48540-2-robertcnelson@gmail.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 14:02:20 -05:00
Robert Nelson
b8c773f556 dt-bindings: arm: ti: Add BeagleY-AI
This board is based on ti,j722s family using the am67a variation.

https://beagley-ai.org/
https://openbeagle.org/beagley-ai/beagley-ai

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
Reviewed-by: Jared McArthur <j-mcarthur@ti.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240829213929.48540-1-robertcnelson@gmail.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 14:02:20 -05:00
Diogo Ivo
f3be0032e1 arm64: dts: ti: iot2050: Declare Ethernet PHY leds
Each Ethernet PHY on IOT2050 platforms drives 3 LEDs whose triggers
can be configured to signal link properties such as connection status
or speed.

Declare the LEDs, exposing their trigger controls to userspace.

Signed-off-by: Diogo Ivo <diogo.ivo@siemens.com>
Link: https://lore.kernel.org/r/20240829-ivo-iot2050_leds-v1-1-792a512b2178@siemens.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 14:02:20 -05:00
Judith Mendez
50f368a0c1 arm64: dts: ti: k3-am65: Add ESM nodes
Add Error Signaling Module (ESM) instances in MCU and MAIN domains,
set ESM interrupt sources for rti as per TRM [0] 9.4 Interrupt
Sources.

There are no ESM0_ESM_INT* events routed to MCU ESM, so it is not
possible to reset the CPU using watchdog and ESM0 configuration.
However add ESM instances for device completion.

Add comments to describe what interrupt sources are routed to ESM
modules.

[0] http://www.ti.com/lit/pdf/spruid7

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20240815204833.452132-7-jm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 14:02:20 -05:00
Judith Mendez
633bcfa502 arm64: dts: ti: k3-am64: Add more ESM interrupt sources
Add ESM interrupt sources for rti as per TRM [0] in 9.4 Interrupt
Sources.

[0] https://www.ti.com/lit/pdf/spruim2

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20240815204833.452132-6-jm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 14:02:20 -05:00
Judith Mendez
54ed32742a arm64: dts: ti: k3-am62a: Add ESM nodes
Add Error Signaling Module (ESM) instances in MCU and MAIN domains,
set ESM interrupt sources for rti as per TRM [0] 10.4 Interrupt
Sources.

Add comments to describe what interrupt sources are routed to ESM
modules.

[0] https://www.ti.com/lit/pdf/spruj16

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20240815204833.452132-2-jm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 14:02:20 -05:00
Judith Mendez
cc3a295ebb arm64: dts: ti: k3-am62: Add comments to ESM nodes
Add comments to describe what interrupt sources are routed to ESM
modules.

There is no functional change.

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20240815204833.452132-5-jm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 14:02:20 -05:00
Judith Mendez
c94da2159d arm64: dts: ti: k3-am62p: Fix ESM interrupt sources
Fix interrupt sources for rti routed to the ESM0 as per [0], in 10.4
Interrupt Sources

Add comments to describe what interrupt sources are routed to ESM
modules.

[0] https://www.ti.com/lit/pdf/spruj83

Fixes: b5080c7c1f ("arm64: dts: ti: k3-am62p: Add nodes for more IPs")
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20240815204833.452132-3-jm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 14:02:18 -05:00
Santhosh Kumar K
d4847546b6 arm64: dts: ti: k3-am62p: Remove 'reserved' status for ESM
Remove 'reserved' status for MCU ESM node. Watchdog reset is
propagated through ESM0 to MCU ESM to reset the CPU, so enable MCU ESM
to reset the CPU with watchdog timeout.

Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20240815204833.452132-4-jm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 14:01:39 -05:00
Nishanth Menon
5c19aeb8ae arm64: dts: ti: k3-j721s2-evm-gesi-exp-board: Rename gpio-hog node name
Fix the gpio hog node name to p15-hog to match up with gpio-hog
convention. This fixes dtbs_check warning:
p15: $nodename:0: 'p15' does not match '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$'

Acked-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://lore.kernel.org/r/20240830102822.3970269-1-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 13:39:29 -05:00
Nishanth Menon
47ca0776e3 arm64: dts: ti: k3-am642-evm-nand: Rename pinctrl node and gpio-hog names
Rename the pin mux and gpio-hog node names to match up with binding
rules. This fixes dtbs_check warnings:
'gpmc0-pins-default' does not match any of the regexes: '-pins(-[0-9]+)?$|-pin$', 'pinctrl-[0-9]+'
'gpio0-36' does not match '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$'

While at it, change the phandle name to be consistent with the pinctrl
naming.

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20240830113137.3986091-1-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 13:39:00 -05:00
MD Danish Anwar
2bea7920da arm64: dts: ti: k3-am654-idk: Fix dtbs_check warning in ICSSG dmas
ICSSG doesn't use mgmnt rsp dmas. But these are added in the dmas for
icssg1-eth and icssg0-eth node.

These mgmnt rsp dmas result in below dtbs_check warnings.

/workdir/arch/arm64/boot/dts/ti/k3-am654-idk.dtb: icssg1-eth: dmas: [[39, 49664], [39, 49665], [39, 49666], [39, 49667], [39, 49668], [39, 49669], [39, 49670], [39, 49671], [39, 16896], [39, 16897], [39, 16898], [39, 16899]] is too long
	from schema $id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml#
/workdir/arch/arm64/boot/dts/ti/k3-am654-idk.dtb: icssg0-eth: dmas: [[39, 49408], [39, 49409], [39, 49410], [39, 49411], [39, 49412], [39, 49413], [39, 49414], [39, 49415], [39, 16640], [39, 16641], [39, 16642], [39, 16643]] is too long
	from schema $id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml#

Fix these warnings by removing mgmnt rsp dmas from icssg1-eth and
icssg0-eth nodes.

Fixes: a4d5bc3214 ("arm64: dts: ti: k3-am654-idk: Add ICSSG Ethernet ports")
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240830111000.232028-1-danishanwar@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 13:38:30 -05:00
Andrew Davis
6c67a0f164 arm64: dts: ti: k3-j784s4: Include entire FSS region in ranges
Add FSS regions at 0x50000000, 0x400000000, and 0x600000000. Although
not used currently by the Linux FSS driver, these regions belong to
the FSS and should be included in the ranges mapping.

While here, a couple of these numbers had missing zeros which was
hidden by odd alignments, fix both these issues.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Santhosh Kumar K <s-k6@ti.com>
Link: https://lore.kernel.org/r/20240828172956.26630-5-afd@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
2024-09-01 13:37:52 -05:00