* Re: [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Florijan Plohl @ 2026-04-03 8:29 UTC (permalink / raw)
To: Frank Li
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel, upstream
In-Reply-To: <ac50OHuEApM3tRHq@lizhi-Precision-Tower-5810>
Hello,
On 4/2/26 15:50, Frank Li wrote:
> On Thu, Apr 02, 2026 at 09:08:26AM +0200, Florijan Plohl wrote:
>> Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
> what's means PEB-AV-18? Is it random board name?
The PEB-AV-18 is PHYTEC designation for Audio/Video adapter modules that can
be used to connect displays on their boards.
I will improve commit message to add more such information in v2.
>
>
>> The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
>>
>> Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
>> ---
>> arch/arm64/boot/dts/freescale/Makefile | 4 +
>> .../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
>> .../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> Any difference between 91 and 93, can use one overlay file?
>
> Frank
Can you suggest how to do so?
There are imx93-pinfunc.h and imx91-pinfunc.h which are not unified
between imx91 and imx93.
So we can only create common dtsi like so:
imx91-93-phyboard-segin-peb-av-18.dtsi
and still use separate dtsos:
imx91-phyboard-segin-peb-av-18.dtso
imx93-phyboard-segin-peb-av-18.dtso
Is that your idea?
BR,
Florijan Plohl
>> --
>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH v11 0/4] crypto: spacc - Add SPAcc Crypto Driver
From: Tony He @ 2026-04-03 8:35 UTC (permalink / raw)
To: Ruud Derwig
Cc: Pavitrakumar Managutte, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
herbert@gondor.apana.org.au, robh@kernel.org, conor+dt@kernel.org,
manjunath.hadli@vayavyalabs.com, adityak@vayavyalabs.com,
navami.telsang@vayavyalabs.com, bhoomikak@vayavyalabs.com
In-Reply-To: <SA3PR12MB7997CAA00BEFD7402AC63DD7CF5EA@SA3PR12MB7997.namprd12.prod.outlook.com>
Hi Ruud,
Thanks for your quick reply.
I would like to confirm my understanding regarding the use of
SPAcc as a pure crypto engine in IPsec scenarios.
My concern is that the main bottleneck may not be the crypto
throughput itself, but the per-packet overhead, such as
descriptor setup, submission, and DMA cost. Since IPsec traffic
typically operates at MTU-sized packets (~1500 bytes), this
per-packet cost may significantly reduce the overall benefit of
offloading.
In other words, for MTU-sized traffic, the performance gain from
a pure crypto engine might be limited, or in some cases even
offset by the overhead of per-packet scheduling and DMA.
Could you please confirm whether this understanding is correct?
Also, do you happen to have any performance data for network
workloads (e.g., IPsec throughput), comparing:
1)with SPAcc enabled
2)without SPAcc (software crypto)
It would be very helpful to understand the actual benefit in
real-world scenarios.
Thanks.
Tony
On Fri, Apr 3, 2026 at 3:59 PM Ruud Derwig <Ruud.Derwig@synopsys.com> wrote:
>
> Hi Tony,
>
> > Is SPAcc capable of handling full ESP packet processing (i.e.,
> > beyond basic encryption/decryption and authentication)?
>
> No, SPAcc only implements the crypto algorithms.
> (The name/documentation only shows that it was designed to
> support the crypto algorithms of various communication protocols.)
>
> Regards,
>
> Ruud.
>
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: codecs: Add TAS675x quad-channel audio amplifier driver
From: kernel test robot @ 2026-04-03 8:39 UTC (permalink / raw)
To: Sen Wang, linux-sound
Cc: oe-kbuild-all, broonie, lgirdwood, robh, krzk+dt, conor+dt,
devicetree, perex, tiwai, shenghao-ding, kevin-lu, baojun.xu,
niranjan.hy, l-badrinarayanan, devarsht, v-singh1, linux-kernel,
Sen Wang
In-Reply-To: <20260401024210.28542-3-sen@ti.com>
Hi Sen,
kernel test robot noticed the following build warnings:
[auto build test WARNING on broonie-sound/for-next]
[also build test WARNING on tiwai-sound/for-next tiwai-sound/for-linus robh/for-next linus/master v7.0-rc6 next-20260401]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Sen-Wang/dt-bindings-sound-Add-ti-tas675x/20260401-114532
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
patch link: https://lore.kernel.org/r/20260401024210.28542-3-sen%40ti.com
patch subject: [PATCH 2/4] ASoC: codecs: Add TAS675x quad-channel audio amplifier driver
config: arc-randconfig-001-20260402 (https://download.01.org/0day-ci/archive/20260402/202604021838.DCOggoRo-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 13.4.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260402/202604021838.DCOggoRo-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604021838.DCOggoRo-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: sound/soc/codecs/tas675x.c:1473 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst
* Hardware power sequencing
Warning: sound/soc/codecs/tas675x.c:1551 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst
* Device start-up defaults
Warning: sound/soc/codecs/tas675x.c:1790 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst
* Read and log all latched fault registers
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v1 5/5] riscv: dts: starfive: jhb100: Add JHB100 base DT
From: Conor Dooley @ 2026-04-03 8:49 UTC (permalink / raw)
To: Changhuang Liang
Cc: Emil Renner Berthing, Joel Stanley, Drew Fustini,
Darshan Prajapati, linux-riscv@lists.infradead.org, Rob Herring,
Alexandre Ghiti, Anup Patel, Hal Feng, Guodong Xu, Yixun Lan,
Heinrich Schuchardt, devicetree@vger.kernel.org, Conor Dooley,
Albert Ou, E Shattow, Leyfoon Tan, Junhui Liu, Daniel Lezcano,
Michal Simek, Paul Walmsley, linux-kernel@vger.kernel.org,
Samuel Holland, Michael Zhu, Palmer Dabbelt, Thomas Gleixner,
JiSheng Teoh, Krzysztof Kozlowski
In-Reply-To: <ZQ4PR01MB1202CB8B853CA7E03531914BF25E2@ZQ4PR01MB1202.CHNPR01.prod.partner.outlook.cn>
[-- Attachment #1: Type: text/plain, Size: 4826 bytes --]
On Fri, Apr 03, 2026 at 03:06:23AM +0000, Changhuang Liang wrote:
> Hi, Conor
>
> > On Thu, Apr 02, 2026 at 01:40:19AM -0700, Changhuang Liang wrote:
> > > From: Ley Foon Tan <leyfoon.tan@starfivetech.com>
> > >
> > > Add JHB100 base dtsi and dts. Consist of 4 Dubhe-70 cores, CLINT,
> > > PLIC, PMU, UART and 1GB DDR.
> > >
> > > Signed-off-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
> > > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > > ---
> > > MAINTAINERS | 6 +
> > > arch/riscv/boot/dts/starfive/Makefile | 2 +
> > > .../boot/dts/starfive/jhb100-evb1-eth.dts | 6 +
> > > arch/riscv/boot/dts/starfive/jhb100-evb1.dtsi | 32 ++
> > > arch/riscv/boot/dts/starfive/jhb100.dtsi | 326
> > ++++++++++++++++++
> > > 5 files changed, 372 insertions(+)
> > > create mode 100644 arch/riscv/boot/dts/starfive/jhb100-evb1-eth.dts
> > > create mode 100644 arch/riscv/boot/dts/starfive/jhb100-evb1.dtsi
> > > create mode 100644 arch/riscv/boot/dts/starfive/jhb100.dtsi
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS index
> > > 7d10988cbc62..b1892a480c31 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -25306,6 +25306,12 @@ S: Supported
> > > F:
> > Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100
> > -intc.yaml
> > > F: drivers/irqchip/irq-starfive-jh8100-intc.c
> > >
> > > +STARFIVE JHB100 DEVICETREES
> > > +M: Changhuang Liang <changhuang.liang@starfivetech.com>
> > > +L: linux-riscv@lists.infradead.org
> > > +S: Maintained
> >
> > Supported, no?
> >
> > > +F: arch/riscv/boot/dts/starfive/jhb100*
> > > +
> > > STATIC BRANCH/CALL
> > > M: Peter Zijlstra <peterz@infradead.org>
> > > M: Josh Poimboeuf <jpoimboe@kernel.org>
> > > diff --git a/arch/riscv/boot/dts/starfive/Makefile
> > > b/arch/riscv/boot/dts/starfive/Makefile
> > > index 3dd1f05283f7..7cdb75788053 100644
> > > --- a/arch/riscv/boot/dts/starfive/Makefile
> > > +++ b/arch/riscv/boot/dts/starfive/Makefile
> > > @@ -18,3 +18,5 @@ dtb-$(CONFIG_ARCH_STARFIVE) +=
> > > jh7110-starfive-visionfive-2-lite.dtb
> > > dtb-$(CONFIG_ARCH_STARFIVE) +=
> > > jh7110-starfive-visionfive-2-lite-emmc.dtb
> > > dtb-$(CONFIG_ARCH_STARFIVE) += jh7110-starfive-visionfive-2-v1.2a.dtb
> > > dtb-$(CONFIG_ARCH_STARFIVE) += jh7110-starfive-visionfive-2-v1.3b.dtb
> > > +
> > > +dtb-$(CONFIG_ARCH_STARFIVE) += jhb100-evb1-eth.dtb
> > > diff --git a/arch/riscv/boot/dts/starfive/jhb100-evb1-eth.dts
> > > b/arch/riscv/boot/dts/starfive/jhb100-evb1-eth.dts
> > > new file mode 100644
> > > index 000000000000..62cd046e1224
> > > --- /dev/null
> > > +++ b/arch/riscv/boot/dts/starfive/jhb100-evb1-eth.dts
> > > @@ -0,0 +1,6 @@
> > > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > > +/*
> > > + * Copyright (c) 2024-2026 StarFive Technology Co., Ltd.
> > > + */
> > > +
> > > +#include "jhb100-evb1.dtsi"
> >
> > What is the point of this file? Is this the base-board?
> > Shouldn't it have a specific compatible?
> >
> > Can the SoM be used without a base board? I've got no info about this board
> > appearing on google, do you even have pictures of it or any documentation?
> > I see this
> > https://www.starfivetech.com/en/index.php?s=hardware&c=show&id=22
> > and
> > https://www.starfivetech.com/en/index.php?s=hardware&c=show&id=23
> > but the former doesn't look like it needs a base-board and the latter is called
> > "evb3", so is not what's here?
>
> The former is the base board of the EVB1. Currently, we are only carrying out
> upstream work based on the EVB1. The EVB1 base board has reserved slots
Except when I look at the first link, the picture doesn't show something
that is a SoM + base-board, it's just a regular board. If that's the
case, the breakdown of files doesn't make sense, with jhb100-evb1.dtsi
sounding like it should be a dts. Usually we talk about base-boards in
relation to a SoM, like what the mars-cm needs to function.
> that can accommodate expansion boards to verify more advanced features.
> At present, the jhb100-evb1.dtsi file corresponds to the configuration of the
> EVB1 base board. In the future, we will add dtsi files for the expansion boards.
> The jhb100-evb1-eth.dts file will then be used to combine these dtsi files to
> generate the final version of the device tree source.
Sounds like here the evb1 is a complete board and jhb100-evb1-eth.dts
represents some kind of expansion card added to that board?
I think this not correct, since the base-board needs to be usable in
isolation. Take a look at what rockchip do for rk3588-rock-5b-pcie-ep
in arch/arm64/boot/dts/rockchip/Makefile/, where these expansion type
things are dealt with using overlays.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 23/27] clk: mediatek: Add MT8196 disp-ao clock support
From: Jason-JH Lin (林睿祥) @ 2026-04-03 8:54 UTC (permalink / raw)
To: Laura Nao
Cc: Guangjie Song (宋光杰), robh@kernel.org,
kernel@collabora.com, Sirius Wang (王皓昱),
Nancy Lin (林欣螢), AngeloGioacchino Del Regno,
linux-mediatek@lists.infradead.org, conor+dt@kernel.org,
Paul-pl Chen (陳柏霖),
linux-kernel@vger.kernel.org,
Project_Global_Chrome_Upstream_Group, devicetree@vger.kernel.org,
richardcochran@gmail.com, krzk+dt@kernel.org,
mturquette@baylibre.com, Nicolas Prado, p.zabel@pengutronix.de,
Singo Chang (張興國), wenst@chromium.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-clk@vger.kernel.org, matthias.bgg@gmail.com,
sboyd@kernel.org
In-Reply-To: <20260402100538.27291-1-laura.nao@collabora.com>
[snip]
> > > +static const struct of_device_id of_match_clk_mt8196_vdisp_ao[]
> > > = {
> > > + { .compatible = "mediatek,mt8196-vdisp-ao", .data =
> > > &mm_v_mcd },
> >
> > Hi Laura,
> >
> > We are going to send mtk-mmsys driver for MT8196 recently, but we
> > found
> > the compatible name is used here.
> >
> > As your commit message, vdisp-ao is integrated with the mtk-mmsys
> > driver, which registers the vdisp-ao clock driver via
> > platform_device_register_data().
> >
> > Shouldn't this compatible name belong to mmsys driver for MT8196?
> >
>
> That's right, my fault for missing that! Thanks for the heads up.
>
> I'm aware Angelo is currently restructuring mediatek-drm (including
> mmsys and mutex), and that might affect the way vdisp-ao is loaded
> too.
> So I'm not sure whether it makes sense to send a patch to fix this
> right away.
OK, we'll try to contact Angelo from other places.
Thanks for your confirmation!
Regards,
Jason-JH.Lin
>
> Best,
>
> Laura
>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: qcom,rpmhpd: Add RPMh power domain for Hawi SoC
From: Krzysztof Kozlowski @ 2026-04-03 8:58 UTC (permalink / raw)
To: Fenglin Wu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel
In-Reply-To: <20260402-haw-rpmhpd-v2-1-2bce0767f2ca@oss.qualcomm.com>
On 03/04/2026 02:35, Fenglin Wu wrote:
> Document the RPMh power domain for Hawi SoC, and add definitions for
> the new power domains which present in Hawi SoC:
> - RPMHPD_DCX (Display Core X): supplies VDD_DISP for the display
> subsystem
> - RPMHPD_GBX (Graphics Box): supplies VDD_GFX_BX for the GPU/graphics
> subsystem
>
> Also, add constants for new power domain levels that supported in Hawi
> SoC, including: LOW_SVS_D3_0, LOW_SVS_D1_0, LOW_SVS_D0_0, SVS_L2_0,
> TURBO_L1_0/1/2, TURBO_L1_0/1/2.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
> include/dt-bindings/power/qcom,rpmhpd.h | 12 ++++++++++++
> 2 files changed, 13 insertions(+)
>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH ath-next v4 2/6] wifi: ath12k: Add ath12k_hw_params for IPQ5424
From: Baochen Qiang @ 2026-04-03 9:01 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Saravanakumar Duraisamy
In-Reply-To: <20260402-ath12k-ipq5424-v4-2-cd1e0f0a6c88@oss.qualcomm.com>
On 4/2/2026 11:54 AM, Raj Kumar Bhagat wrote:
> From: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
>
> Add ath12k_hw_params for the ath12k AHB-based WiFi 7 device IPQ5424.
> The WiFi device IPQ5424 is similar to IPQ5332. Most of the hardware
> parameters like hw_ops, wmi_init, ring_mask, etc., are the same between
> IPQ5424 and IPQ5332, hence use these same parameters for IPQ5424.
> Some parameters are specific to IPQ5424; initially set these to
> 0 or NULL, and populate them in subsequent patches.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
> Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/core.h | 1 +
> drivers/net/wireless/ath/ath12k/wifi7/hw.c | 75 ++++++++++++++++++++++++++++++
> 2 files changed, 76 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
> index 59c193b24764..68453594eba8 100644
> --- a/drivers/net/wireless/ath/ath12k/core.h
> +++ b/drivers/net/wireless/ath/ath12k/core.h
> @@ -157,6 +157,7 @@ enum ath12k_hw_rev {
> ATH12K_HW_WCN7850_HW20,
> ATH12K_HW_IPQ5332_HW10,
> ATH12K_HW_QCC2072_HW10,
> + ATH12K_HW_IPQ5424_HW10,
> };
>
> enum ath12k_firmware_mode {
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> index ec6dba96640b..9b9ca06a9f45 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
> @@ -753,6 +753,81 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
>
> .dp_primary_link_only = false,
> },
> + {
> + .name = "ipq5424 hw1.0",
> + .hw_rev = ATH12K_HW_IPQ5424_HW10,
> + .fw = {
> + .dir = "IPQ5424/hw1.0",
> + .board_size = 256 * 1024,
> + .cal_offset = 128 * 1024,
> + .m3_loader = ath12k_m3_fw_loader_remoteproc,
> + .download_aux_ucode = false,
> + },
> + .max_radios = 1,
> + .single_pdev_only = false,
> + .qmi_service_ins_id = ATH12K_QMI_WLFW_SERVICE_INS_ID_V01_IPQ5332,
> + .internal_sleep_clock = false,
> +
> + .hw_ops = &qcn9274_ops,
> + .ring_mask = &ath12k_wifi7_hw_ring_mask_ipq5332,
> +
> + .host_ce_config = ath12k_wifi7_host_ce_config_ipq5332,
> + .ce_count = 12,
> + .target_ce_config = ath12k_wifi7_target_ce_config_wlan_ipq5332,
> + .target_ce_count = 12,
> + .svc_to_ce_map =
> + ath12k_wifi7_target_service_to_ce_map_wlan_ipq5332,
> + .svc_to_ce_map_len = 18,
> +
> + .rxdma1_enable = true,
> + .num_rxdma_per_pdev = 1,
> + .num_rxdma_dst_ring = 0,
> + .rx_mac_buf_ring = false,
> + .vdev_start_delay = false,
> +
> + .interface_modes = BIT(NL80211_IFTYPE_STATION) |
> + BIT(NL80211_IFTYPE_AP) |
> + BIT(NL80211_IFTYPE_MESH_POINT),
> + .supports_monitor = true,
> +
> + .idle_ps = false,
> + .download_calib = true,
> + .supports_suspend = false,
> + .tcl_ring_retry = true,
> + .reoq_lut_support = false,
> + .supports_shadow_regs = false,
> +
> + .num_tcl_banks = 48,
> + .max_tx_ring = 4,
> +
> + .wmi_init = &ath12k_wifi7_wmi_init_qcn9274,
> +
> + .qmi_cnss_feature_bitmap = BIT(CNSS_QDSS_CFG_MISS_V01),
> +
> + .rfkill_pin = 0,
> + .rfkill_cfg = 0,
> + .rfkill_on_level = 0,
> +
> + .rddm_size = 0,
> +
> + .def_num_link = 0,
> + .max_mlo_peer = 256,
> +
> + .otp_board_id_register = 0,
> +
> + .supports_sta_ps = false,
> +
> + .acpi_guid = NULL,
> + .supports_dynamic_smps_6ghz = false,
> + .iova_mask = 0,
> + .supports_aspm = false,
> +
> + .ce_ie_addr = NULL,
> + .ce_remap = NULL,
> + .bdf_addr_offset = 0x940000,
> +
> + .dp_primary_link_only = true,
> + },
> };
mhi_config and current_cc_support are missing, please explicitly set them.
>
> /* Note: called under rcu_read_lock() */
>
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: renesas: Fix missing cells and reg in Draak/Ebisu panel DTO
From: Geert Uytterhoeven @ 2026-04-03 9:01 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-2-marek.vasut+renesas@mailbox.org>
On Thu, 26 Mar 2026 at 05:24, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add missing cells and reg DT property into Draak/Ebisu panel DTO to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso:30.10-34.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@1: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: renesas: Fix missing cells and reg in Salvator-X panel DTO
From: Geert Uytterhoeven @ 2026-04-03 9:02 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-3-marek.vasut+renesas@mailbox.org>
On Thu, 26 Mar 2026 at 05:24, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add missing cells and reg DT property into Salvator-X panel DTO to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso:30.10-34.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@1: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: renesas: rzg2l-smarc: Fix missing cells and reg into CSI2 subnode
From: Geert Uytterhoeven @ 2026-04-03 9:03 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-4-marek.vasut+renesas@mailbox.org>
On Thu, 26 Mar 2026 at 05:24, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add missing cells and reg DT property into CSI2 subnode to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi:49.10-55.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: renesas: rzg2l-smarc: Fix missing cells and reg into DU subnode
From: Geert Uytterhoeven @ 2026-04-03 9:03 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-5-marek.vasut+renesas@mailbox.org>
On Thu, 26 Mar 2026 at 05:24, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add missing cells and reg DT property into DU subnode to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi:29.10-33.5: Warning (unit_address_vs_reg): /fragment@1/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH ath-next v4 0/6] wifi: ath12k: Enable IPQ5424 AHB WiFi device
From: Baochen Qiang @ 2026-04-03 9:13 UTC (permalink / raw)
To: Raj Kumar Bhagat, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Saravanakumar Duraisamy, Sowmiya Sree Elavalagan,
Krzysztof Kozlowski
In-Reply-To: <20260402-ath12k-ipq5424-v4-0-cd1e0f0a6c88@oss.qualcomm.com>
On 4/2/2026 11:53 AM, Raj Kumar Bhagat wrote:
> Add support for the new ath12k AHB device IPQ5424, as currently, Ath12k
> AHB only supports IPQ5332 WiFi devices.
>
> The IPQ5424 is an IEEE 802.11be 2 GHz WiFi device, supporting 4x4
> configurations. To enable the IPQ5424 device:
> - Add the necessary hardware parameters for IPQ5424.
> - Modify the boot-up sequence for ath12k AHB to accommodate the
> requirements of the IPQ5424 device.
>
> ---
> Changes in v4:
> - DT binding: dropped copyright update as per discussion in v3.
> - DT binding: Used DT binding from v2 and retained Acked-by tag.
> - Link to v3: https://patch.msgid.link/20260331-ath12k-ipq5424-v3-0-1455b9cae29c@oss.qualcomm.com
>
> Changes in v3:
> - DT binding: updated copyright.
> - DT binding: Dropped Acked-by tag as copyright is updated.
> - Rebased on latest ToT.
> - Dropped ath12k_ahb_ops because qcom_mdt_load() and
> qcom_mdt_load_no_init() now have different number of arguments.
> - Link to v2: https://lore.kernel.org/all/20250518-ath12k-ipq5424-v2-0-ef81b833dc97@quicinc.com/
>
> Changes in v2:
> - DT binding: Removed the redundant example for IPQ5424, as it is similar
> to IPQ5332.
> - Added driver probe data structure to eliminate the redundant switch-case
> logic in the ath12k_ahb_probe() function.
> - Validation completed, hence changed from RFC to PATCH.
> - Link to v1: https://lore.kernel.org/all/20250130051838.1924079-1-quic_rajkbhag@quicinc.com/
>
> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
>
> ---
> Raj Kumar Bhagat (2):
> dt-bindings: net: wireless: add ath12k wifi device IPQ5424
> wifi: ath12k: add ath12k_hw_version_map entry for IPQ5424
>
> Saravanakumar Duraisamy (3):
> wifi: ath12k: Add ath12k_hw_params for IPQ5424
> wifi: ath12k: add ath12k_hw_regs for IPQ5424
> wifi: ath12k: Add CE remap hardware parameters for IPQ5424
>
> Sowmiya Sree Elavalagan (1):
> wifi: ath12k: Enable IPQ5424 WiFi device support
>
> .../bindings/net/wireless/qcom,ipq5332-wifi.yaml | 1 +
> drivers/net/wireless/ath/ath12k/ahb.c | 36 +++++----
> drivers/net/wireless/ath/ath12k/ahb.h | 1 +
> drivers/net/wireless/ath/ath12k/ce.h | 13 ++-
> drivers/net/wireless/ath/ath12k/core.h | 1 +
> drivers/net/wireless/ath/ath12k/wifi7/ahb.c | 8 ++
> drivers/net/wireless/ath/ath12k/wifi7/hal.c | 7 ++
> drivers/net/wireless/ath/ath12k/wifi7/hal.h | 3 +
> .../net/wireless/ath/ath12k/wifi7/hal_qcn9274.c | 88 ++++++++++++++++++++
> .../net/wireless/ath/ath12k/wifi7/hal_qcn9274.h | 1 +
> drivers/net/wireless/ath/ath12k/wifi7/hw.c | 93 +++++++++++++++++++++-
> 11 files changed, 231 insertions(+), 21 deletions(-)
> ---
> base-commit: 15551ababf6d4e857f2101366a0c3eaa86dd822c
> change-id: 20260331-ath12k-ipq5424-cddb63a46a97
>
only nit in patch 2/6, so for patches 2-6/6:
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
>
^ permalink raw reply
* Re: [PATCH v12 00/15] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-04-03 9:14 UTC (permalink / raw)
To: Borislav Petkov
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260402133644.GBac5w7OYl9MwvVxY_@fat_crate.local>
On 2026/4/2 21:36, Borislav Petkov wrote:
> On Thu, Apr 02, 2026 at 07:47:53PM +0800, Jinjie Ruan wrote:
>> Thank you for the reminder and for your patience. I apologize for the
>> frequent updates; I am becoming more familiar with the community's
>> workflow.
>
> Yap, and you can use that time while waiting to learn about it:
Thanks for the pointer! I'm using the wait time to dive into the process
docs. Definitely a lot to learn about the workflow, but I'm getting there.
>
> Documentation/process/
>
^ permalink raw reply
* Re: [PATCH 1/6] ARM: dts: renesas: r8a7778: Add missing unit to bus node
From: Geert Uytterhoeven @ 2026-04-03 9:21 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260327234244.91707-2-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Sat, 28 Mar 2026 at 00:42, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add missing unit to bus node to fix the following DTC warning:
> "
> arch/arm/boot/dts/renesas/r8a7778.dtsi:43.12-48.4: Warning (unit_address_vs_reg): /bus: node has a reg or ranges property, but no unit name
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
> --- a/arch/arm/boot/dts/renesas/r8a7778.dtsi
> +++ b/arch/arm/boot/dts/renesas/r8a7778.dtsi
> @@ -40,7 +40,7 @@ aliases {
> spi2 = &hspi2;
> };
>
> - lbsc: bus {
> + lbsc: bus@0 {
Note for the future: if we ever add proper LBSC support (including its
own compatible value and reg property), this should be changed to the
address in the reg property. This applies to the first four patches.
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/6] ARM: dts: renesas: r8a7779: Add missing unit to bus node
From: Geert Uytterhoeven @ 2026-04-03 9:22 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260327234244.91707-3-marek.vasut+renesas@mailbox.org>
On Sat, 28 Mar 2026 at 00:43, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add missing unit to bus node to fix the following DTC warning:
> "
> arch/arm/boot/dts/renesas/r8a7779.dtsi:707.12-712.4: Warning (unit_address_vs_reg): /bus: node has a reg or ranges property, but no unit name
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/6] ARM: dts: renesas: r8a7792: Add missing unit to bus node
From: Geert Uytterhoeven @ 2026-04-03 9:22 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260327234244.91707-4-marek.vasut+renesas@mailbox.org>
On Sat, 28 Mar 2026 at 00:43, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add missing unit to bus node to fix the following DTC warning:
> "
> arch/arm/boot/dts/renesas/r8a7792.dtsi:89.12-94.4: Warning (unit_address_vs_reg): /bus: node has a reg or ranges property, but no unit name
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 4/6] ARM: dts: renesas: r7s72100: Add missing unit to bus node
From: Geert Uytterhoeven @ 2026-04-03 9:22 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260327234244.91707-5-marek.vasut+renesas@mailbox.org>
On Sat, 28 Mar 2026 at 00:43, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add missing unit to bus node to fix the following DTC warning:
> "
> arch/arm/boot/dts/renesas/r7s72100.dtsi:40.11-46.4: Warning (unit_address_vs_reg): /bus: node has a reg or ranges property, but no unit name
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 5/6] ARM: dts: renesas: genmai: Drop superfluous cells
From: Geert Uytterhoeven @ 2026-04-03 9:23 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260327234244.91707-6-marek.vasut+renesas@mailbox.org>
On Sat, 28 Mar 2026 at 00:43, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Drop superfluous address-cells and size-cells to fix DTC warning:
> "
> arch/arm/boot/dts/renesas/r7s72100-genmai.dts:28.17-55.4: Warning (avoid_unnecessary_addr_size): /flash@18000000: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" or "ranges" property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
My bad...
Fixes: 30e0a8cf886cb459 ("ARM: dts: renesas: genmai: Add FLASH nodes")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 6/6] ARM: dts: renesas: rskrza1: Drop superfluous cells
From: Geert Uytterhoeven @ 2026-04-03 9:24 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260327234244.91707-7-marek.vasut+renesas@mailbox.org>
On Sat, 28 Mar 2026 at 00:43, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Drop superfluous address-cells and size-cells to fix DTC warning:
> "
> arch/arm/boot/dts/renesas/r7s72100-rskrza1.dts:32.17-72.4: Warning (avoid_unnecessary_addr_size): /flash@18000000: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" or "ranges" property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
My bad...
Fixes: 98537eb77d3ef185 ("ARM: dts: renesas: rskrza1: Add FLASH nodes")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 08/11] drm/bridge: imx8mp-hdmi-tx-connector-fixup: add an hdmi-connector when missing using a DT overlay at boot time
From: Liu Ying @ 2026-04-03 9:28 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares
In-Reply-To: <20260402-drm-lcdif-dbanc-v3-8-27cd247a0847@bootlin.com>
Hi Luca,
On Thu, Apr 02, 2026 at 11:26:03AM +0200, Luca Ceresoli wrote:
> The imx8mp-hdmi-tx is one of many drivers based on dw-hdmi. dw-hdmi in turn
> can operate in two different modes, depending on the platform data as set
> by the driver:
>
> A. hdmi->plat_data->output_port = 0:
> the HDMI output (port@1) in device tree is not used [0]
>
> B. hdmi->plat_data->output_port = 1:
> the HDMI output (port@1) is parsed to find the next bridge
>
> The imx8mp-hdmi-tx driver falls in case A. This implies next_bridge will
> always be NULL, and so dw_hdmi_bridge_attach() [1] will always fail if
> called with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
>
> In fact case A assumes that DRM_BRIDGE_ATTACH_NO_CONNECTOR is not set and
> in that case it adds an HDMI Type A connector programmatically at bridge
> attach time.
>
> Support for DRM_BRIDGE_ATTACH_NO_CONNECTOR is implemented by dw-hdmi.c in
> case B. However switching to base B requires that port@1 is connected to a
> "next bridge" DT node, typically the HDMI connector, because dw-hdmi won't
> add the connector when using DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> Many dts files for imx8mp-based boards in the kernel have such a connector
> described and linked to port@1, so the pipeline will be fully attached up
> to a display-connector and a drm_connector added by the
> bridge-connector. Sadly some of those dts files don't have the connector
> described. Adding it would solve the problem easily, but this would break
> existing devices which do not update the dtb when upgrading to a newer
> kernel.
>
> In preparation for switching to case B while preserving backward
> compatibility for such devices, introduce a module adding the
> hdmi-connector node to the live device tree at init time. This will allow
> the dw-hdmi code to find the next bridge (the one wrapping the
> hdmi-connector) and let the pipeline work as before.
>
> The module is inserted only if there is no endpoint in port@1. So boards
> whose device tree describe the connector will not have the device tre
> modified, and will start isntantiating the correct HDMI connector type as
> described in the device tree.
>
> For boards lacking a connector description in DT the overlay will be added,
> abd the HDMI connector will be Type A, which is a reasonable fallback and
> is what the driver is currently doing.
>
> [0] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L3310
> [1] https://elixir.bootlin.com/linux/v7.0-rc1/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2907
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> Changes in v3:
> - removed unused variable
> - simplified overlay using full path to port@1
> - handle of_overlay_fdt_apply() errors
> - use of_graph_get_endpoint_by_regs() for more robust endpoint lookup
> - improve subject line
>
> Changes in v2:
> - don't apply the overlay if the SoC is not i.MX8MP
> - build unconditionally, but depend on DRM_IMX_LCDIF
> - remove useless error check
> - add missing cleanup.h and init.h includes, remove unneeded includes
> - avoid dtc warnings on overlay
> - fix typo in Kconfig help text
> - not added the Tested-bys because the code has changed
> - split the 'plat_data->output_port = 1' line to a separate patch
> - improve commit message
>
> This patch is inspired by commit 0ff223d99147 ("drm/tilcdc: Convert legacy
> panel binding via DT overlay at boot time")
> ---
> drivers/gpu/drm/bridge/imx/Kconfig | 18 +++++++
> drivers/gpu/drm/bridge/imx/Makefile | 2 +
> .../bridge/imx/imx8mp-hdmi-tx-connector-fixup.c | 58 ++++++++++++++++++++++
> .../bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso | 33 ++++++++++++
> 4 files changed, 111 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig b/drivers/gpu/drm/bridge/imx/Kconfig
> index b9028a5e5a06..49f074559b00 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -18,6 +18,8 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
> depends on OF
> depends on COMMON_CLK
> select DRM_DW_HDMI
> + select OF_OVERLAY
> + select DRM_DISPLAY_CONNECTOR
> imply DRM_IMX8MP_HDMI_PAI
> imply DRM_IMX8MP_HDMI_PVI
> imply PHY_FSL_SAMSUNG_HDMI_PHY
> @@ -25,6 +27,22 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
> Choose this to enable support for the internal HDMI encoder found
> on the i.MX8MP SoC.
>
> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
> + bool
> + default y
> + depends on DRM_IMX_LCDIF
> + depends on DRM_IMX8MP_DW_HDMI_BRIDGE
> + depends on OF
> + help
> + Modifies at early boot the live device tree of boards using the
> + i.MX8MP fsl,imx8mp-hdmi-tx adding a hdmi-connector node linked to
> + the hdmi-tx. This is needed to support bridge-connector usage in
> + the i.MX8MP LCDIF driver.
> +
> + You need this if you use the i.MX8MP HDMI output and your board
> + device tree file does not have an hdmi-connector node connected
> + to it.
> +
> config DRM_IMX8MP_HDMI_PAI
> tristate "Freescale i.MX8MP HDMI PAI bridge support"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile b/drivers/gpu/drm/bridge/imx/Makefile
> index 8d01fda25451..84499fe2e444 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,6 +1,8 @@
> obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
> obj-$(CONFIG_DRM_IMX_LEGACY_BRIDGE) += imx-legacy-bridge.o
> obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE) += imx8mp-hdmi-tx.o
> +obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP) += imx8mp-hdmi-tx-connector-fixup.o \
> + imx8mp-hdmi-tx-connector-fixup.dtbo.o
> obj-$(CONFIG_DRM_IMX8MP_HDMI_PAI) += imx8mp-hdmi-pai.o
> obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
> obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
> new file mode 100644
> index 000000000000..dc1736bfc3ac
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
> @@ -0,0 +1,58 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Add an hdmi-connector node to boards using the imx8mp hdmi_tx which
> + * don't have one. This is needed for the i.MX LCDIF to work with
> + * DRM_BRIDGE_ATTACH_NO_CONNECTOR.
> + *
> + * Copyright (C) 2026 GE HealthCare
> + * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
> + */
> +
> +#include <linux/cleanup.h>
> +#include <linux/init.h>
> +#include <linux/of.h>
> +#include <linux/of_graph.h>
> +
> +/* Embedded dtbo symbols created by cmd_wrap_S_dtb in scripts/Makefile.dtbs */
> +extern char __dtbo_imx8mp_hdmi_tx_connector_fixup_begin[];
> +extern char __dtbo_imx8mp_hdmi_tx_connector_fixup_end[];
> +
> +static int __init imx8mp_hdmi_tx_connector_fixup_init(void)
> +{
> + struct device_node *soc __free(device_node) = NULL;
> + struct device_node *hdmi_tx __free(device_node) = NULL;
> + struct device_node *endpoint __free(device_node) = NULL;
> + void *dtbo_start;
> + u32 dtbo_size;
> + int ovcs_id;
> + int err;
> +
> + soc = of_find_node_by_path("/soc@0");
> + if (!soc)
> + return 0;
> +
> + /* This applies to i.MX8MP only, do nothing on other systems */
> + if (!of_device_is_compatible(soc, "fsl,imx8mp-soc"))
> + return 0;
> +
> + hdmi_tx = of_find_node_by_path("/soc@0/bus@32c00000/hdmi@32fd8000");
> + if (!of_device_is_available(hdmi_tx))
> + return 0;
> +
> + /* If endpoint exists, assume an hdmi-connector exists already */
> + endpoint = of_graph_get_endpoint_by_regs(hdmi_tx, 1, -1);
> + if (endpoint)
> + return 0;
> +
> + dtbo_start = __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
> + dtbo_size = __dtbo_imx8mp_hdmi_tx_connector_fixup_end -
> + __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
> +
> + err = of_overlay_fdt_apply(dtbo_start, dtbo_size, &ovcs_id, NULL);
> + if (err)
> + err = of_overlay_remove(&ovcs_id);
> +
> + return err;
> +}
> +
> +subsys_initcall(imx8mp_hdmi_tx_connector_fixup_init);
> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> new file mode 100644
> index 000000000000..070be24fed3e
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * DTS overlay adding an hdmi-connector node to boards using the imx8mp hdmi_tx
> + *
> + * Copyright (C) 2026 GE HealthCare
> + * Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&{/} {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + fixup-hdmi-connector {
> + compatible = "hdmi-connector";
> + label = "HDMI";
> + type = "a";
> +
> + port {
> + fixup_hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_tx_out>;
> + };
> + };
> + };
> +};
> +
> +&{/soc@0/bus@32c00000/hdmi@32fd8000/ports/port@1} {
> + hdmi_tx_out: endpoint {
> + remote-endpoint = <&fixup_hdmi_connector_in>;
> + };
> +};
>
There is a build warning(W=1):
DTC drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtbo
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.dtso:12.6-27.3: Warning (avoid_unnecessary_addr_size): /fragment@0/__overlay__: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" or "ranges" property
--
Regards,
Liu Ying
^ permalink raw reply
* [PATCH v2 2/3] iio: adc: qcom-pm8xxx-xoadc: remove redundant error logging in pm8xxx_read_raw
From: Antony Kurniawan Soemardi @ 2026-04-03 9:23 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko
Cc: linux-arm-msm, devicetree, linux-kernel, linux-iio, phone-devel,
Antony Kurniawan Soemardi
In-Reply-To: <20260403-pm8xxx-xoadc-label-v2-0-29b50bf821e6@smankusors.com>
Remove dev_err() for missing channels and rely on -EINVAL to report
failures, reducing unnecessary log noise.
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
drivers/iio/adc/qcom-pm8xxx-xoadc.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/iio/adc/qcom-pm8xxx-xoadc.c b/drivers/iio/adc/qcom-pm8xxx-xoadc.c
index 31f88cf7f7f18297132d152648b312c0fb60608e..d63af84bf44776c9c7106a43473b1678496247cb 100644
--- a/drivers/iio/adc/qcom-pm8xxx-xoadc.c
+++ b/drivers/iio/adc/qcom-pm8xxx-xoadc.c
@@ -657,11 +657,8 @@ static int pm8xxx_read_raw(struct iio_dev *indio_dev,
switch (mask) {
case IIO_CHAN_INFO_PROCESSED:
ch = pm8xxx_get_channel(adc, chan->address);
- if (!ch) {
- dev_err(adc->dev, "no such channel %lu\n",
- chan->address);
+ if (!ch)
return -EINVAL;
- }
ret = pm8xxx_read_channel(adc, ch, &adc_code);
if (ret)
return ret;
@@ -677,11 +674,8 @@ static int pm8xxx_read_raw(struct iio_dev *indio_dev,
return IIO_VAL_INT;
case IIO_CHAN_INFO_RAW:
ch = pm8xxx_get_channel(adc, chan->address);
- if (!ch) {
- dev_err(adc->dev, "no such channel %lu\n",
- chan->address);
+ if (!ch)
return -EINVAL;
- }
ret = pm8xxx_read_channel(adc, ch, &adc_code);
if (ret)
return ret;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] ARM: dts: qcom: pm8921: add labels for ADC channels
From: Antony Kurniawan Soemardi @ 2026-04-03 9:23 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko
Cc: linux-arm-msm, devicetree, linux-kernel, linux-iio, phone-devel,
Antony Kurniawan Soemardi, Konrad Dybcio
In-Reply-To: <20260403-pm8xxx-xoadc-label-v2-0-29b50bf821e6@smankusors.com>
Add label properties to all XOADC ADC channel nodes in the PM8921 PMIC
device tree. This allows userspace and drivers to identify channels by
name rather than relying on datasheet name.
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
arch/arm/boot/dts/qcom/pm8921.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/pm8921.dtsi b/arch/arm/boot/dts/qcom/pm8921.dtsi
index 535cb6a2543f69bc30abc89bff4e14a19147ce38..15246f4bd2672ccd4fc3359b66541d53d4da88b4 100644
--- a/arch/arm/boot/dts/qcom/pm8921.dtsi
+++ b/arch/arm/boot/dts/qcom/pm8921.dtsi
@@ -75,50 +75,62 @@ pm8921_xoadc: xoadc@197 {
vcoin: adc-channel@0 {
reg = <0x00 0x00>;
+ label = "vcoin";
};
vbat: adc-channel@1 {
reg = <0x00 0x01>;
+ label = "vbat";
};
dcin: adc-channel@2 {
reg = <0x00 0x02>;
+ label = "dcin";
};
vph_pwr: adc-channel@4 {
reg = <0x00 0x04>;
+ label = "vph_pwr";
};
batt_therm: adc-channel@8 {
reg = <0x00 0x08>;
+ label = "batt_therm";
};
batt_id: adc-channel@9 {
reg = <0x00 0x09>;
+ label = "batt_id";
};
usb_vbus: adc-channel@a {
reg = <0x00 0x0a>;
+ label = "usb_vbus";
};
die_temp: adc-channel@b {
reg = <0x00 0x0b>;
+ label = "die_temp";
};
ref_625mv: adc-channel@c {
reg = <0x00 0x0c>;
+ label = "ref_625mv";
};
ref_1250mv: adc-channel@d {
reg = <0x00 0x0d>;
+ label = "ref_1250mv";
};
chg_temp: adc-channel@e {
reg = <0x00 0x0e>;
+ label = "chg_temp";
};
ref_muxoff: adc-channel@f {
reg = <0x00 0x0f>;
+ label = "ref_muxoff";
};
};
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 09/11] drm/bridge: imx8mp-hdmi-tx-connector-fixup: show a warning when adding the overlay
From: Liu Ying @ 2026-04-03 9:35 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares
In-Reply-To: <20260402-drm-lcdif-dbanc-v3-9-27cd247a0847@bootlin.com>
On Thu, Apr 02, 2026 at 11:26:04AM +0200, Luca Ceresoli wrote:
> Describing the HDMI connector in device tree is recommended. While the
> overlay insertion is a workaround to avoid breaking existing devices, every
> dts should be improved by adding a connector description.
>
> Add a warning to make users aware as far as possible.
>
> As a warning line cannot hold all the relevant info, add a detailed comment
> in the code so it easy to find when the warning is seen.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> Patch added in v3. Kept as a separate comment w.r.t. the patch adding the
> overlay to let it be added in a later moment in case we want to convert
> existing dts files before adding the warning.
> ---
> .../gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
> index dc1736bfc3ac..f6190d86abd0 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx-connector-fixup.c
> @@ -44,6 +44,23 @@ static int __init imx8mp_hdmi_tx_connector_fixup_init(void)
> if (endpoint)
> return 0;
>
> + /*
> + * Boards with an HDMI connector should describe it in a device
> + * tree node with compatible = "hdmi-connector".
> + *
> + * If you see this warning, it means such a node was not found and
> + * a fallback one is added using a device tree overlay. Please add
> + * one in your device tree, also describing the exact connector
> + * type (the added overlay assumes Type A as a fallback, but it
> + * might be wrong).
> + *
> + * This node is necessary for modern DRM, where bridge drivers do
> + * not create a connector (see the DRM_BRIDGE_ATTACH_NO_CONNECTOR
> + * flag). See https://docs.kernel.org/gpu/drm-kms-helpers.html for
> + * more info.
> + */
> + pr_warn("Please add a hdmi-connector DT node for imx8mp-hdmi-tx.");
Missing '\n' in warning message. With it added:
Reviewed-by: Liu Ying <victor.liu@nxp.com>
> +
> dtbo_start = __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
> dtbo_size = __dtbo_imx8mp_hdmi_tx_connector_fixup_end -
> __dtbo_imx8mp_hdmi_tx_connector_fixup_begin;
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio LAWSON @ 2026-04-03 9:35 UTC (permalink / raw)
To: Vladimir Oltean, Bastien Curutchet
Cc: Woojung Huh, UNGLinuxDriver, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <20260326094211.hdaf4tz7lbjyjznn@skbuf>
On 3/26/26 10:42, Vladimir Oltean wrote:
> On Thu, Mar 26, 2026 at 10:10:23AM +0100, Fidelio Lawson wrote:
>> Implement the "Module 3: Equalizer fix for short cables" erratum from
>> Microchip document DS80000687C for KSZ87xx switches.
>>
>> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
>> where the PHY receiver equalizer may amplify high-amplitude signals
>> excessively, resulting in internal distortion and link establishment
>> failures.
>>
>> Depending on the selected workaround (1 or 2), the driver writes a
>> specific value to the indirect PHY register
>> using the 6E/6F/A0 indirect access mechanism.
>>
>> The errata fix is applied during global switch initialization when
>> enabled via device tree.
>>
>> Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
>> ---
>> drivers/net/dsa/microchip/ksz8.c | 46 ++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>>
>> diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c
>> index 78b42cf50ce2..b6f3a1ce85fc 100644
>> --- a/drivers/net/dsa/microchip/ksz8.c
>> +++ b/drivers/net/dsa/microchip/ksz8.c
>> @@ -1901,6 +1901,41 @@ void ksz8_phylink_mac_link_up(struct phylink_config *config,
>> ksz8_phy_port_link_up(dev, port, duplex, tx_pause, rx_pause);
>> }
>>
>> +static int ksz8_handle_module3_errata(struct ksz_device *dev)
>> +{
>> + int ret = 0;
>
> "ret" does not need to be zero-initialized. It is unconditionally
> overwritten by ksz_write8().
>
> And please sort lines with variable declarations in decreasing line
> length order. Netdev calls this "reverse Christmas tree" ordering and is
> the preferred coding style.
>
>> + const u16 *regs = dev->info->regs;
>> + u16 indir_reg = 0x0000;
>> + u8 indir_val = 0x00;
>> +
>> + switch (dev->low_loss_wa_mode) {
>> + case KSZ_LOW_LOSS_WA_1:
>> + indir_reg = 0x3C;
>> + indir_val = 0x15;
>> + break;
>> + case KSZ_LOW_LOSS_WA_2:
>> + indir_reg = 0x4C;
>> + indir_val = 0x40;
>
> Do the 3c and 4c registers have any associated documentation? Do we know
> what they are or what they do? We should have some macros for them,
> instead of magic numbers.
>
>> + break;
>> + default:
>> + break;
>
> Is it expected that in the default case (no workaround), the code flow
> writes indir_val = 0x00 to indir_reg = 0x0000? Or would it be better to
> just exit early without making any change?
>
>> + }
>> +
>> + mutex_lock(&dev->alu_mutex);
>> +
>> + ret = ksz_write8(dev, regs[REG_IND_CTRL_0], 0xA0);
>> +
>> + if (!ret)
>> + ret = ksz_write8(dev, 0x6F, indir_reg);
>> +
>> + if (!ret)
>> + ret = ksz_write8(dev, regs[REG_IND_BYTE], indir_val);
>
> Is this sequence better suited for ksz8_ind_write8()? Perhaps wrapped in
> another layer similar to ksz8_pme_write8(), once we know what the magic
> numbers represent in terms of indirect table?
>
>> +
>> + mutex_unlock(&dev->alu_mutex);
>> +
>> + return ret;
>> +}
>> +
>> static int ksz8_handle_global_errata(struct dsa_switch *ds)
>> {
>> struct ksz_device *dev = ds->priv;
>> @@ -1915,6 +1950,17 @@ static int ksz8_handle_global_errata(struct dsa_switch *ds)
>> if (dev->info->ksz87xx_eee_link_erratum)
>> ret = ksz8_ind_write8(dev, TABLE_EEE, REG_IND_EEE_GLOB2_HI, 0);
>>
>> + /* KSZ87xx Errata DS80000687C.
>> + * Module 3: Equalizer fix for short cables
>> + * The receiver of the embedded PHYs is tuned by default
>> + * to support long cable length applications.
>> + * Because of this, the equalizer in the PHY may amplify
>> + * high amplitude receiver signals to the point that
>> + * the signal is distorted internally
>> + */
>> + if (!ret && dev->low_loss_wa_enable && ksz_is_ksz87xx(dev))
>> + ret = ksz8_handle_module3_errata(dev);
>> +
>> return ret;
>> }
>>
>>
>> --
>> 2.53.0
>>
>
> FYI, the driver is in a restructuring process. The ksz88xx_switch_ops
> will be split out of the common ksz_switch_ops. This will conflict with
> your series, so you should rebase on top of that much larger set.
> You can coordinate with Bastien Curutchet to see what is the status:
> https://lore.kernel.org/netdev/20260313153849.qkfzv5c2u6fepjku@skbuf
Hi Vladimir,
Thanks for the review and for the detailed feedback!
I’ll apply your suggestions in the next version of the patch.
Thanks again for the guidance.
Best regards,
Fidelio
^ permalink raw reply
* [PATCH 0/3] Add driver support for ESWIN EIC7700 HSP clock and reset generator
From: dongxuyang @ 2026-04-03 9:34 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, linux-clk, devicetree,
linux-kernel, p.zabel, huangyifeng, dongxuyang
Cc: ningyu, linmin, pinkesh.vaghela
From: Xuyang Dong <dongxuyang@eswincomputing.com>
Add support for the ESWIN EIC7700 HSP (high-speed peripherals). The drivers
provide basic functionality to manage and control the clock and reset
signals for EIC7700 HSP, including mmc, USB, ethernet, SATA and DMAC.
The clock and reset registers are mapped to overlapping I/O address ranges.
This causes a resource conflict when two drivers attempt to request the
same region. Use the auxiliary device framework: the main driver
allocates the shared register region and passes it to auxiliary
devices, avoiding resource contention and duplicate remapping.
Features:
Implements support for the ESWIN EIC7700 HSP clock and reset controller.
Provide API to manage clock and reset signals for the EIC7700 HSP.
Supported chips:
ESWIN EIC7700 series SoC.
Test:
Test this patch on the Sifive HiFive Premier P550 (which used the EIC7700
SoC), include USB and other peripherals. All the drivers of these modules
use the clock module and reset module.
This patch depends on ESWIN EIC7700 clock controller patch [1], [2] and [3].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20260331&id=8add6d87dc69c0620c7e60bdc6be6b3b0092d9fa
[2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20260331&id=cd44f127c1d42833a32ba0a0965255ee6184f8c1
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20260331&id=858f6273cf003e97c817903a07d8001b483fe40b
Xuyang Dong (3):
dt-bindings: clock: Add ESWIN eic7700 HSP clock and reset generator
clk: eswin: Add eic7700 HSP clock driver
reset: eswin: Add eic7700 HSP reset driver
.../bindings/clock/eswin,eic7700-hspcrg.yaml | 63 ++++
MAINTAINERS | 3 +
drivers/clk/eswin/Kconfig | 12 +
drivers/clk/eswin/Makefile | 1 +
drivers/clk/eswin/clk-eic7700-hsp.c | 339 ++++++++++++++++++
drivers/reset/Kconfig | 13 +
drivers/reset/Makefile | 1 +
drivers/reset/reset-eic7700-hsp.c | 151 ++++++++
.../dt-bindings/clock/eswin,eic7700-hspcrg.h | 33 ++
.../dt-bindings/reset/eswin,eic7700-hspcrg.h | 21 ++
10 files changed, 637 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/eswin,eic7700-hspcrg.yaml
create mode 100644 drivers/clk/eswin/clk-eic7700-hsp.c
create mode 100644 drivers/reset/reset-eic7700-hsp.c
create mode 100644 include/dt-bindings/clock/eswin,eic7700-hspcrg.h
create mode 100644 include/dt-bindings/reset/eswin,eic7700-hspcrg.h
--
2.34.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox