* Re: [PATCH v3 00/13] This series adds support for the MediaTek MT7927 (Filogic 380) combo
From: Sean Wang @ 2026-03-26 5:56 UTC (permalink / raw)
To: Javier Tia
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Ming Yen Hsieh, Deren Wu, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek, Marcin FM,
Cristian-Florin Radoi, George Salukvadze, Evgeny Kapusta,
Samu Toljamo, Ariel Rosenfeld, Chapuis Dario,
Thibaut François, 张旭涵
In-Reply-To: <20260325-mt7927-wifi-support-v2-v3-0-5ca66c97a755@jetm.me>
Hi, Javier
Sorry for the late reply. This version already looks better than v1
overall, and the patch order is cleaner. I still think a few areas
could be refined further, as this would also be a good opportunity to
refactor the code a bit so mt7927 support fits more naturally and
future chips are easier to handle as well.
On Wed, Mar 25, 2026 at 5:11 PM Javier Tia <floss@jetm.me> wrote:
>
> WiFi 7 + BT 5.4 module to the mt7925 driver. The MT7927 uses PCI ID
> 14c3:7927 (some hardware reports 14c3:6639) and shares the mt7925
> firmware interface but requires different DMA ring layout, IRQ mapping,
> chip initialization, and power management handling.
>
> Tested hardware:
> - ASUS ROG Crosshair X870E Hero (BT 0489:e13a, WiFi 14c3:6639)
> - ASUS ProArt X870E-Creator WiFi (BT 0489:e13a / 13d3:3588, WiFi 14c3:6639)
> - ASUS ROG Strix X870-I (WiFi 14c3:7927)
> - ASUS ROG Strix X870-F Gaming WiFi (BT 0489:e13a, WiFi 14c3:7927)
> - ASUS ROG Strix X870E-E (BT 13d3:3588, WiFi 14c3:7927)
> - Gigabyte X870E Aorus Master X3D (BT 0489:e10f, WiFi 14c3:7927)
> - Gigabyte Z790 AORUS MASTER X (BT 0489:e10f, WiFi 14c3:7927)
> - Gigabyte Z790 AORUS ELITE X WiFi7 (BT 0489:e10f, WiFi 14c3:7927)
> - MSI MEG X870E ACE MAX (BT 0489:e110, WiFi 14c3:7927)
> - Lenovo Legion Pro 7 16ARX9 (BT 0489:e0fa, WiFi 14c3:7927)
> - Lenovo Legion Pro 7 16AFR10H (BT 0489:e0fa, WiFi 14c3:7927)
> - TP-Link Archer TBE550E PCIe (BT 0489:e116, WiFi 14c3:7927)
> - EDUP EP-MT7927BE M.2 card (WiFi 14c3:7927)
> - Foxconn/Azurewave M.2 modules (WiFi 14c3:6639)
> - AMD RZ738 reference design (WiFi 14c3:0738)
>
> Tested on Arch Linux, CachyOS, EndeavourOS, Fedora (Bazzite), NixOS,
> openSUSE Tumbleweed, and Ubuntu across kernels 6.13-6.19.
>
> What works:
> - WiFi 7 with EHT 320MHz on 2.4/5/6 GHz bands
> - 320MHz data path verified at 841 Mbps (iperf3 -t30 -P8)
> - PCIe initialization with CBTOP remap and MT7927-specific DMA layout
> - System suspend/resume (S3)
> - DBDC (dual-band concurrent) mode
> - Explicit band_idx assignment for stable 5GHz/6GHz operation
> - ASPM and runtime PM disabled for MT7927 (see below)
>
> Known limitations (planned as follow-up series):
> - Runtime PM: disabled for MT7927 because the combo chip shares a
> CONNINFRA power domain between WiFi (PCIe) and BT (USB).
> SET_OWN/CLR_OWN transitions on the LPCTL register crash the BT
> firmware, requiring a full power cycle to recover. PM enablement
> will be addressed once safe power state transitions are determined.
> - mac_reset returns -EOPNOTSUPP (DMA recovery not yet implemented)
> - MLO (Multi-Link Operation): tested working on 5GHz+2.4GHz STR
> (776 Mbps) but requires additional patches for link lifetime
> and error handling. Sean Wang's series [1] addresses these;
> MLO support will be submitted as a follow-up on top of that.
> - TX retransmissions: elevated retry rate on all bands, firmware-side
> rate adaptation issue not addressable in the driver.
>
> [1] https://lore.kernel.org/linux-wireless/20260306232238.2039675-1-sean.wang@kernel.org/
>
> Patches 1-5 add generic 320MHz EHT support (no MT7927 references).
> Patches 6-7 introduce MT7927 chip ID helpers and firmware paths.
> Patch 8 adds per-chip IRQ map handling.
This part patch 1-8 looks good overall. My only concern was a possible
regression on mt7925, but now that the incorrect mt7925 320 MHz
support has been fixed in the version, this should be fine.
> Patch 9 introduces mt792x_dma_config struct for chip-specific DMA.
> Patch 10 combines CBTOP remap, chip init, DBDC, CNM, and mac_reset.
> Patch 11 adds mt7925_band_idx() helper for stable 5/6 GHz operation.
I am still thinking a bit more about patches 9-11. My current
preference is to introduce the generic layer first, and then migrate
the mt7925 and mt7927-specific parts on top of it.
I will handle this part on my side, since I want to carefully compare
the vendor driver with your changes first, and make sure the mt7925
side is solid before moving the mt7927-related changes forward. For
the mt7927-related work, I will make sure your contribution, as well
as the work from the other volunteers, is properly preserved when I
carry this forward.
> Patch 12 disables ASPM and runtime PM for MT7927.
> Patch 13 enables the MT7927 PCI device table entries.
>
> The WiFi firmware path and filename in linux-firmware have not been
> finalized yet. The driver currently requests mediatek/mt6639/ (the
> mobile SoC codename), but this may change based on the linux-firmware
> review.
Similar to the BT side, I would prefer to have a dedicated Linux
firmware for mt7927 WiFi. I am not sure yet whether the current
changes will work seamlessly with that, so we can revisit it later and
see what further adjustments are needed.
>
> Changes since v2 (suggested by Sean Wang):
> - Fixed is_320mhz_supported() to check for MT7927 only, not the
> entire mt7925 family. MT7925 does not support 320MHz (patch 5).
> - Dropped phy_cap_info[7] 320MHz additions (NON_OFDMA_UL_MU_MIMO
> and MU_BEAMFORMER) to keep capabilities conservative (patch 5).
> - Disabled runtime PM for MT7927 (patch 12). The combo chip shares a
> CONNINFRA power domain between WiFi and BT; SET_OWN/CLR_OWN
> transitions crash BT firmware. Discovered via user reports of BT
> lockups after enabling power_save=1 (Reported-by: Nitin Gurram).
> - Added tested hardware: MSI MEG X870E ACE MAX, Gigabyte Z790 AORUS
> ELITE X WiFi7, Lenovo Legion Pro 7 16AFR10H.
>
> Changes since v1 (suggested by Sean Wang):
> - Reorganized from 18 patches into 13 across 8 logical groups
> - Common 320MHz patches first, chip-specific changes later
> - Introduced mt792x_dma_config struct to reuse mt7925_dma_init()
> instead of duplicating as mt7927_dma_init()
> - Replaced is_mt7927() with is_320mhz_supported() in common patches
> - Added mt7925_band_idx() helper replacing scattered if/else patterns
> - Renamed MT7927-specific registers with MT7927_ prefix
> - Added PCI ID 0x0738 for AMD RZ738 hardware
> - Moved GLO_CFG_EXT1 register address into dma_config struct to
> eliminate is_mt7927() from shared mt792x_dma.c
>
> Link to v2: https://lore.kernel.org/linux-wireless/20260319-mt7927-wifi-support-v2-v2-0-d627a7fad70d@jetm.me/
> Link to v1: https://lore.kernel.org/linux-wireless/20260306-mt7927-wifi-support-v1-0-c77e7445511d@jetm.me/
>
> Assisted-by: Claude (Anthropic)
> Signed-off-by: Javier Tia <floss@jetm.me>
> ---
> Javier Tia (13):
> wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links
> wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv
> wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXS
> wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec
> wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band
> wifi: mt76: mt7925: add MT7927 chip ID helpers
> wifi: mt76: mt7925: add MT7927 firmware paths
> wifi: mt76: mt7925: use irq_map for chip-specific interrupt handling
> wifi: mt76: mt7925: add chip-specific DMA configuration
> wifi: mt76: mt7925: add MT7927 hardware initialization
> wifi: mt76: mt7925: fix band_idx for stable 5GHz/6GHz operation
> wifi: mt76: mt7925: disable ASPM and runtime PM for MT7927
> wifi: mt76: mt7925: enable MT7927 PCI device IDs
>
> drivers/net/wireless/mediatek/mt76/mt76_connac.h | 13 +-
> drivers/net/wireless/mediatek/mt76/mt7925/init.c | 19 +-
> drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 9 +
> drivers/net/wireless/mediatek/mt76/mt7925/main.c | 61 ++++-
> drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 55 +++-
> drivers/net/wireless/mediatek/mt76/mt7925/mt7925.h | 7 +
> drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 277 +++++++++++++++++++--
> .../net/wireless/mediatek/mt76/mt7925/pci_mac.c | 14 +-
> .../net/wireless/mediatek/mt76/mt7925/pci_mcu.c | 20 +-
> drivers/net/wireless/mediatek/mt76/mt792x.h | 27 ++
> drivers/net/wireless/mediatek/mt76/mt792x_dma.c | 68 ++---
> drivers/net/wireless/mediatek/mt76/mt792x_regs.h | 33 +++
> 12 files changed, 528 insertions(+), 75 deletions(-)
> ---
> base-commit: 9ac76f3d0bb2940db3a9684d596b9c8f301ef315
> change-id: 20260319-mt7927-wifi-support-v2-e89d779b28f4
>
> Best regards,
> --
> Javier Tia <floss@jetm.me>
>
>
^ permalink raw reply
* Re: [PATCH v11 0/3] of: parsing of multi #{iommu,msi}-cells in maps
From: Vijayanand Jitta @ 2026-03-26 5:53 UTC (permalink / raw)
To: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia
Cc: linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Charan Teja Kalla
In-Reply-To: <20260325-parse_iommu_cells-v11-0-1fefa5c0e82c@oss.qualcomm.com>
On 3/25/2026 4:38 PM, Vijayanand Jitta wrote:
> So far our parsing of {iommu,msi}-map properties has always blindly
> assumed that the output specifiers will always have exactly 1 cell.
> This typically does happen to be the case, but is not actually enforced
> (and the PCI msi-map binding even explicitly states support for 0 or 1
> cells) - as a result we've now ended up with dodgy DTs out in the field
> which depend on this behaviour to map a 1-cell specifier for a 2-cell
> provider, despite that being bogus per the bindings themselves.
>
> Since there is some potential use[1] in being able to map at least
> single input IDs to multi-cell output specifiers (and properly support
> 0-cell outputs as well), add support for properly parsing and using the
> target nodes' #cells values, albeit with the unfortunate complication of
> still having to work around expectations of the old behaviour too.
> -- Robin.
>
> Unlike single #{}-cell, it is complex to establish a linear relation
> between input 'id' and output specifier for multi-cell properties, thus
> it is always expected that len never going to be > 1.
>
> These changes have been tested on QEMU for the arm64 architecture.
>
> Since, this would also need update in dt-schema, raised PR[2] for the
> same.
>
> [1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/
> [2] PR for iommu-map dtschema: https://github.com/devicetree-org/dt-schema/pull/184
>
> V11:
> - Added explicit filter_np parameter to of_map_id() and of_map_msi_id()
> per Dmitry Baryshkov's review feedback, making the filter explicit
> instead of overloading arg->np as both input filter and output parameter.
> - Removed of_node_put() from inside of_map_id(), making the caller responsible
> for reference management. Updated of_msi_xlate() to properly handle reference counting.
> - Collected ACKed by tags, and fixed minor typos.
> Link to v10:
> https://lore.kernel.org/r/20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com
>
> V10:
> - Move of_map_iommu_id()/of_map_msi_id() from include/linux/of.h to
> drivers/of/base.c as out-of-line helpers per feedback from Marc Zyngier
> and Rob Herring.
> - Add kernel-doc to document both helpers for discoverability and
> usage clarity.
> - Fix of_map_msi_id() wrapper and all its callers (cdx_msi.c,
> irq-gic-its-msi-parent.c, drivers/of/irq.c) to correctly use the new
> struct of_phandle_args-based API with proper of_node_put() handling
> as per feeback from Dmitry.
> Link to v9:
> https://lore.kernel.org/r/20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com
>
> V9:
> - Updated TO/CC list based on feedback to include all relevant
> maintainers.
> - No functional changes to the patches themselves.
>
> Link to V8:
> https://lore.kernel.org/all/20260226074245.3098486-1-vijayanand.jitta@oss.qualcomm.com/
>
> V8:
> - Removed mentions of of_map_args from commit message to match code.
>
> Link to V7:
> https://lore.kernel.org/all/20260210101157.2145113-1-vijayanand.jitta@oss.qualcomm.com/
>
> V7:
> - Removed of_map_id_args structure and replaced it with
> of_phandle_args as suggested by Dmitry.
>
> Link to V6:
> https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
>
> V6:
> - Fixed build error reported by kernel test bot.
>
> Link to V5:
> https://lore.kernel.org/all/20260118181125.1436036-1-vijayanand.jitta@oss.qualcomm.com/
>
> V5:
> - Fixed Build Warnings.
> - Raised PR for iommu-map dtschema: https://github.com/devicetree-org/dt-schema/pull/184
>
> Link to V4:
> https://lore.kernel.org/all/20251231114257.2382820-1-vijayanand.jitta@oss.qualcomm.com/
>
> V4:
> - Added Reviewed-by tag.
> - Resolved warnings reported by kernel test bot, minor code
> reorganization.
>
> Link to V3:
> https://lore.kernel.org/all/20251221213602.2413124-1-vijayanand.jitta@oss.qualcomm.com/
>
> V3:
> - Added Reviewed-by tag.
> - Updated of_map_id_args struct as a wrapper to of_phandle_args and
> added comment description as suggested by Rob Herring.
>
> Link to V2:
> https://lore.kernel.org/all/20251204095530.8627-1-vijayanand.jitta@oss.qualcomm.com/
>
> V2:
> - Incorporated the patches from Robin that does the clean implementation.
> - Dropped the patches the were adding multi-map support from this series
> as suggested.
>
> V1:
> https://lore.kernel.org/all/cover.1762235099.git.charan.kalla@oss.qualcomm.com/
>
> RFC:
> https://lore.kernel.org/all/20250928171718.436440-1-charan.kalla@oss.qualcomm.com/#r
>
> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
> ---
>
> ---
> Charan Teja Kalla (1):
> of: Factor arguments passed to of_map_id() into a struct
>
> Robin Murphy (2):
> of: Add convenience wrappers for of_map_id()
> of: Respect #{iommu,msi}-cells in maps
>
> drivers/cdx/cdx_msi.c | 8 +-
> drivers/iommu/of_iommu.c | 6 +-
> drivers/irqchip/irq-gic-its-msi-parent.c | 11 +-
> drivers/of/base.c | 213 ++++++++++++++++++++++++-------
> drivers/of/irq.c | 11 +-
> drivers/pci/controller/dwc/pci-imx6.c | 18 ++-
> drivers/pci/controller/pcie-apple.c | 6 +-
> drivers/xen/grant-dma-ops.c | 5 +-
> include/linux/of.h | 30 ++++-
> 9 files changed, 237 insertions(+), 71 deletions(-)
> ---
> base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
> change-id: 20260301-parse_iommu_cells-1c33768aebba
>
> Best regards,
Hi Robin,
Could this series be pulled into an immutable branch/tag, if it doesn't
make it into the v7.1 merge window ? There are client changes dependent on it,
So it would help to get them moving forward rather than waiting another cycle.
Thanks,
Vijay
^ permalink raw reply
* Re: [PATCH v5 2/2] hwmon: emc2305: Support configurable fan PWM at shutdown
From: Guenter Roeck @ 2026-03-26 5:52 UTC (permalink / raw)
To: florin.leotescu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel
Cc: daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
In-Reply-To: <20260325160444.1736866-3-florin.leotescu@oss.nxp.com>
On 3/25/26 09:04, florin.leotescu@oss.nxp.com wrote:
> From: Florin Leotescu <florin.leotescu@nxp.com>
>
> Some systems require fans to enter in a defined safe state during system
> shutdown or reboot handoff.
>
> Add support for the optional Device Tree property "fan-shutdown-percent"
> to configure the shutdown PWM duty cycle per fan output.
>
> If the property is present for a fan channel, the driver converts the
> configured percentage value to the corresponding PWM duty cycle and
> applies it during driver shutdown.
>
> If the property is not present, the fan state remains unchanged.
>
> Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com>
Sashiko has a couple of concerns.
https://sashiko.dev/#/patchset/20260325160444.1736866-1-florin.leotescu%40oss.nxp.com
I don't know about the shutdown problem. If that is real, a lot of drivers
have the same problem. Don't bother about it right now.
However, the range check should indeed be a separate patch.
Thanks,
Guenter
> ---
> drivers/hwmon/emc2305.c | 41 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/drivers/hwmon/emc2305.c b/drivers/hwmon/emc2305.c
> index 64b213e1451e..722ec1d054f8 100644
> --- a/drivers/hwmon/emc2305.c
> +++ b/drivers/hwmon/emc2305.c
> @@ -32,6 +32,7 @@
> #define EMC2305_REG_DRIVE_PWM_OUT 0x2b
> #define EMC2305_OPEN_DRAIN 0x0
> #define EMC2305_PUSH_PULL 0x1
> +#define EMC2305_PWM_SHUTDOWN_UNSET -1
>
> #define EMC2305_PWM_DUTY2STATE(duty, max_state, pwm_max) \
> DIV_ROUND_CLOSEST((duty) * (max_state), (pwm_max))
> @@ -104,6 +105,7 @@ struct emc2305_cdev_data {
> * @pwm_output_mask: PWM output mask
> * @pwm_polarity_mask: PWM polarity mask
> * @pwm_separate: separate PWM settings for every channel
> + * @pwm_shutdown: Set shutdown PWM.
> * @pwm_min: array of minimum PWM per channel
> * @pwm_freq: array of PWM frequency per channel
> * @cdev_data: array of cooling devices data
> @@ -116,6 +118,7 @@ struct emc2305_data {
> u8 pwm_output_mask;
> u8 pwm_polarity_mask;
> bool pwm_separate;
> + s16 pwm_shutdown[EMC2305_PWM_MAX];
> u8 pwm_min[EMC2305_PWM_MAX];
> u16 pwm_freq[EMC2305_PWM_MAX];
> struct emc2305_cdev_data cdev_data[EMC2305_PWM_MAX];
> @@ -539,6 +542,7 @@ static int emc2305_of_parse_pwm_child(struct device *dev,
> struct device_node *child,
> struct emc2305_data *data)
> { u32 ch;
> + u32 pwm_shutdown_percent;
> int ret;
> struct of_phandle_args args;
>
> @@ -548,6 +552,12 @@ static int emc2305_of_parse_pwm_child(struct device *dev,
> return ret;
> }
>
> + if (ch >= EMC2305_PWM_MAX) {
> + dev_err(dev, "invalid reg %u of node %pOF (valid range 0-%u)\n", ch, child,
> + EMC2305_PWM_MAX - 1);
> + return -EINVAL;
> + }
> +
> ret = of_parse_phandle_with_args(child, "pwms", "#pwm-cells", 0, &args);
>
> if (ret)
> @@ -579,6 +589,16 @@ static int emc2305_of_parse_pwm_child(struct device *dev,
> }
>
> of_node_put(args.np);
> +
> + ret = of_property_read_u32(child, "fan-shutdown-percent",
> + &pwm_shutdown_percent);
> +
> + if (!ret) {
> + pwm_shutdown_percent = clamp(pwm_shutdown_percent, 0, 100);
> + data->pwm_shutdown[ch] =
> + DIV_ROUND_CLOSEST(pwm_shutdown_percent * EMC2305_FAN_MAX, 100);
> + }
> +
> return 0;
> }
>
> @@ -631,6 +651,9 @@ static int emc2305_probe(struct i2c_client *client)
> if (ret)
> return ret;
>
> + for (i = 0; i < EMC2305_PWM_MAX; i++)
> + data->pwm_shutdown[i] = EMC2305_PWM_SHUTDOWN_UNSET;
> +
> pwm_childs = emc2305_probe_childs_from_dt(dev);
>
> pdata = dev_get_platdata(&client->dev);
> @@ -714,6 +737,23 @@ static int emc2305_probe(struct i2c_client *client)
> return 0;
> }
>
> +static void emc2305_shutdown(struct i2c_client *client)
> +{
> + int i;
> + int ret;
> + struct emc2305_data *data = i2c_get_clientdata(client);
> +
> + for (i = 0; i < data->pwm_num; i++) {
> + if (data->pwm_shutdown[i] != EMC2305_PWM_SHUTDOWN_UNSET) {
> + ret = i2c_smbus_write_byte_data(client, EMC2305_REG_FAN_DRIVE(i),
> + data->pwm_shutdown[i]);
> + if (ret < 0)
> + dev_warn(&client->dev,
> + "Failed to set shutdown PWM for ch %d\n", i);
> + }
> + }
> +}
> +
> static const struct of_device_id of_emc2305_match_table[] = {
> { .compatible = "microchip,emc2305", },
> {},
> @@ -726,6 +766,7 @@ static struct i2c_driver emc2305_driver = {
> .of_match_table = of_emc2305_match_table,
> },
> .probe = emc2305_probe,
> + .shutdown = emc2305_shutdown,
> .id_table = emc2305_ids,
> };
>
^ permalink raw reply
* Re: [PATCH v3 9/9] arm64: dts: mt6392: add mt6392 PMIC dtsi
From: Chen-Yu Tsai @ 2026-03-26 5:43 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: wens, Luca Leonardo Scorcia, linux-mediatek, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Gary Bisson,
Julien Massot, Louis-Alexis Eyraud, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <28102417-4a2a-4e29-afbd-d0f2aa76074b@collabora.com>
On Wed, Mar 18, 2026 at 06:22:42PM +0100, AngeloGioacchino Del Regno wrote:
> Il 18/03/26 14:54, Chen-Yu Tsai ha scritto:
> > On Wed, Mar 18, 2026 at 8:39 PM AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@collabora.com> wrote:
> > >
> > > Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> > > > From: Val Packett <val@packett.cool>
> > > >
> > > > Add the dts to be included by all boards using the MT6392 PMIC.
> > > >
> > > > Signed-off-by: Val Packett <val@packett.cool>
> > > > Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> > > > ---
> > > > arch/arm64/boot/dts/mediatek/mt6392.dtsi | 141 +++++++++++++++++++++++
> > > > 1 file changed, 141 insertions(+)
> > > > create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
> > > >
> > > > diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> > > > new file mode 100644
> > > > index 000000000000..fbf6f671524c
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> > > > @@ -0,0 +1,141 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright (c) 2019 MediaTek Inc.
> > > > + * Copyright (c) 2024 Val Packett <val@packett.cool>
> > > > + */
> > > > +
> > > > +#include <dt-bindings/input/input.h>
> > > > +
> > > > +&pwrap {
> > > > + pmic: pmic {
> > > > + compatible = "mediatek,mt6392", "mediatek,mt6323";
> > > > + interrupt-controller;
> > > > + #interrupt-cells = <2>;
> > > > +
> > > > + keys {
> > > > + compatible = "mediatek,mt6392-keys";
> > > > +
> > > > + key-power {
> > > > + linux,keycodes = <KEY_POWER>;
> > > > + wakeup-source;
> > > > + };
> > > > +
> > > > + key-home {
> > > > + linux,keycodes = <KEY_HOME>;
> > > > + wakeup-source;
> > > > + };
> > > > + };
> > > > +
> > > > + pio6392: pinctrl {
> > > > + compatible = "mediatek,mt6392-pinctrl";
> > > > +
> > > > + gpio-controller;
> > > > + #gpio-cells = <2>;
> > > > + };
> > > > +
> > > > + rtc {
> > > > + compatible = "mediatek,mt6392-rtc",
> > > > + "mediatek,mt6323-rtc";
> > > > + };
> > > > +
> > > > + regulators {
> > > > + compatible = "mediatek,mt6392-regulator";
> > > > +
> > > > + mt6392_vproc_reg: buck_vproc {
> > >
> > > s/buck//g
> > >
> > > Also, no min/max voltages?!
> >
> > We really shouldn't set min/max voltages in the PMIC dtsi file.
> >
> > The min/max voltages are supposed to be the intersection of the
> > consumers acceptable operating ranges. The min/max of the regulator
> > itself is already implied by the model / compatible.
> >
>
> Your point is fair, but it's also true that some of the regulators are not
> really meant to ever output anything different than what they are supposed
> to, though, with slight variations being possible... I guess the best option
> here is to leave declaring voltages to board DTs instead, which is sensible
> in the end.
>
> Okay, agreed. Let's go with no voltages.
>
> Reminder for myself: there's a bunch of PMIC devicetrees to cleanup in here...
And to be honest, even the default names are not needed. They are again
implied by the compatible, and even the regulator's own node name.
So either we could have a whole bunch of empty regulator nodes with
labels for easy reference, or just have the upper level "regulators"
wrapper node with a "mt63??_regulators" label for board dts files
to reference and add the _used_ regulators to.
If you agree, I can do the cleanup work.
ChenYu
^ permalink raw reply
* Re: [PATCH v2 1/4] iio: adc: xilinx-xadc: Split driver into core and platform files
From: kernel test robot @ 2026-03-26 5:39 UTC (permalink / raw)
To: Sai Krishna Potthuri, Jonathan Cameron, David Lechner, Nuno Sa,
Andy Shevchenko, Michal Simek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: llvm, oe-kbuild-all, linux-iio, devicetree, linux-arm-kernel,
linux-kernel, saikrishna12468, git, Sai Krishna Potthuri
In-Reply-To: <20260323074505.3853353-2-sai.krishna.potthuri@amd.com>
Hi Sai,
kernel test robot noticed the following build errors:
[auto build test ERROR on jic23-iio/togreg]
[also build test ERROR on robh/for-next linus/master v7.0-rc5 next-20260325]
[cannot apply to xilinx-xlnx/master]
[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/Sai-Krishna-Potthuri/iio-adc-xilinx-xadc-Split-driver-into-core-and-platform-files/20260326-024045
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
patch link: https://lore.kernel.org/r/20260323074505.3853353-2-sai.krishna.potthuri%40amd.com
patch subject: [PATCH v2 1/4] iio: adc: xilinx-xadc: Split driver into core and platform files
config: i386-buildonly-randconfig-002-20260326 (https://download.01.org/0day-ci/archive/20260326/202603261323.1EonYM3W-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260326/202603261323.1EonYM3W-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/202603261323.1EonYM3W-lkp@intel.com/
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> ERROR: modpost: "xadc_handle_events" [drivers/iio/adc/xilinx-xadc-platform.ko] undefined!
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] ARM: dts: aspeed: yosemite5: Add MP5998 power monitor
From: Andrew Jeffery @ 2026-03-26 5:35 UTC (permalink / raw)
To: Daniel Hsu, robh, krzk+dt, conor+dt, joel
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Daniel Hsu
In-Reply-To: <20260305084650.24511-1-Daniel-Hsu@quantatw.com>
Hi Daniel,
On Thu, 2026-03-05 at 16:46 +0800, Daniel Hsu wrote:
> Add the MP5998 power monitor device on I2C bus with address 0x46
> for the Yosemite5 platform.
I would rather you describe the purpose of the power monitoring. Why is
this instance of an MP5998 necessary in the system design? The address
of the sensor is evident from the details in the patch and isn't
necessary to describe here.
>
> This allows the hwmon driver to probe the device and expose the
> power monitoring telemetry to userspace.
I would prefer you reword or remove this sentence. The purpose of the
devicetree is to describe the hardware. What the firmware/kernel
chooses to do with that information is a separate problem.
Andrew
>
> Signed-off-by: Daniel Hsu <Daniel-Hsu@quantatw.com>
> ---
> arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-
> yosemite5.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-
> yosemite5.dts
> index 2486981f3d6b..6287f80d70d9 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite5.dts
> @@ -422,6 +422,11 @@ power-sensor@45 {
> shunt-resistor = <1000>;
> };
>
> + power-monitor@46 {
> + compatible = "mps,mp5998";
> + reg = <0x46>;
> + };
> +
> power-monitor@47 {
> compatible = "ti,tps25990";
> reg = <0x47>;
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: David Gow @ 2026-03-26 5:34 UTC (permalink / raw)
To: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Nick Desaulniers,
Bill Wendling, Justin Stitt, Russell King, Richard Weinberger,
Anton Ivanov, Johannes Berg, aliceryhl
Cc: linux-um, llvm, linux-arm-kernel, linux-kbuild, a.hindborg,
acourbot, akpm, bjorn3_gh, boqun.feng, dakr, gary, linux-kernel,
linux-mm, lossin, mark.rutland, mmaurer, nicolas.schier, peterz,
rust-for-linux, tmgross, urezki, will
In-Reply-To: <20260322192159.88138-1-ojeda@kernel.org>
Le 23/03/2026 à 3:21 AM, Miguel Ojeda a écrit :
> On Tue, 03 Feb 2026 11:34:07 +0000 Alice Ryhl <aliceryhl@google.com> wrote:
>>
>> To get rid of these helper symbols, provide functionality to inline
>> helpers into Rust using llvm-link. This option complements full LTO, by
>> being much cheaper and avoiding incompatibility with BTF.
>
> I have been testing this. I think we can go ahead with it, with a few
> notes.
>
> I will reply to a couple other bindings in separate emails to avoid
> spamming people too much.
>
> - I will mark the Kconfig option as "(EXPERIMENTAL)", since that is
> what the commit message says and it allows us to be a bit
> conservative.
>
>
> - Clang passes `-Werror=unused-command-line-argument`, which means
> under arm (i.e. 32-bit) we get:
>
> clang: error: argument unused during compilation: '-U arm' [-Werror,-Wunused-command-line-argument]
>
> And under UML I see:
>
> clang: error: argument unused during compilation: '-I ./arch/um/include/shared' [-Werror,-Wunused-command-line-argument]
> clang: error: argument unused during compilation: '-I ./arch/x86/um/shared' [-Werror,-Wunused-command-line-argument]
> clang: error: argument unused during compilation: '-I ./arch/um/include/shared/skas' [-Werror,-Wunused-command-line-argument]
>
> So we would need e.g. `-Wno-unused-command-line-argument` there
> close to the `-Wno-override-module` one, unless Kbuild or
> ClangBuiltLinux thinks it is important to keep it for this case.
>
> On the other hand, regardless of whether we fix this (and another
> issue in a separate email found thanks to the UML build), we could
> instead add `depends on` listing explicitly the architectures where
> this is going to be actually tested. That way maintainers can decide
> whether they want to support it when they are ready. Thoughts?
>
> Cc'ing Nathan, Nicolas, Nick, Bill, Justin, David, UML, ARM.
I'm quite happy personally to just have
-Wno-unused-command-line-argument here, given that it otherwise is
working pretty well on UML and 32-bit UML.
That being said, I expect it won't get a lot of testing (regardless of
architecture) while it's hidden behind CONFIG_EXPERT.
Cheers,
-- David
^ permalink raw reply
* Re: [PATCH v11 0/9] Add support MT6316/6363/MT6373 PMICs regulators and MFD
From: Chen-Yu Tsai @ 2026-03-26 5:34 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Lee Jones, linux-mediatek, robh, krzk+dt, conor+dt, matthias.bgg,
lgirdwood, broonie, devicetree, linux-kernel, linux-arm-kernel,
kernel, igor.belwon
In-Reply-To: <701b6abc-71e8-43fc-adfd-211a62dbec64@collabora.com>
On Fri, Nov 07, 2025 at 10:01:56AM +0100, AngeloGioacchino Del Regno wrote:
> Il 06/11/25 17:11, Lee Jones ha scritto:
> > On Mon, 27 Oct 2025, AngeloGioacchino Del Regno wrote:
> >
> > > Changes in v11:
> > > - Removed unnecessary #address-cells in all mt6316 bindings
> > >
> > > Changes in v10:
> > > - Added "struct" prefix to structs kerneldoc
> > > - Renamed struct mtk_spmi_pmic_pdata to mtk_spmi_pmic_variant
> > > - Added "REG_" to MT6363/73 mfd register definitions to disambiguate
> > > - Expanded MTK_SPMI_PMIC_IRQ_GROUP macro parameter names as suggested
> > > - Some rewording of comments as suggested, addition of more comments
> > > - Refactored IRQ domain handling due to deprecation of function
> > > irq_domain_add_tree() to use the new irq_domain_create_tree()
> > > - Fixed to use generic_handle_domain_irq_safe() to avoid races
> > > - Added support for two interrupt cells in translation
> > > - Removed .irq_lock() and .irq_unlock() in favor of lockdep classes
> > > - Added support for handling PMICs without IRQ Group register for
> > > upcoming MT6685 implementation
> >
> > The MFD part looks okay.
> >
> > Let me know when you have all the Acks and the set is ready to be merged.
> >
>
>
> Lee, the regulators part was picked by Mark, so I guess you can take the MFD part
> through your tree.
>
> I'm not sure if you can also take patch [7/9] (auxadc binding), but it would be
> great if you could, because there is an auxadc example in the mfd binding that
> needs that commit in order to succeed the binding check.
Friendly ping. You might want to resend the remaining patches. Looks
like they are all ready to be merged?
ChenYu
^ permalink raw reply
* Re: [PATCH v6 1/5] mm: rmap: support batched checks of the references for large folios
From: Barry Song @ 2026-03-26 5:31 UTC (permalink / raw)
To: Baolin Wang
Cc: Lorenzo Stoakes (Oracle), David Hildenbrand (Arm), akpm,
catalin.marinas, will, lorenzo.stoakes, ryan.roberts,
Liam.Howlett, vbabka, rppt, surenb, mhocko, riel, harry.yoo,
jannh, willy, dev.jain, linux-mm, linux-arm-kernel, linux-kernel
In-Reply-To: <bfd282b1-523d-4945-97a0-ec30fe1df577@linux.alibaba.com>
On Thu, Mar 26, 2026 at 9:47 AM Baolin Wang
<baolin.wang@linux.alibaba.com> wrote:
>
>
>
> On 3/25/26 11:06 PM, Lorenzo Stoakes (Oracle) wrote:
> > On Wed, Mar 25, 2026 at 03:58:36PM +0100, David Hildenbrand (Arm) wrote:
> >> On 3/25/26 15:36, Lorenzo Stoakes (Oracle) wrote:
> >>> On Mon, Mar 16, 2026 at 03:15:18PM +0100, David Hildenbrand (Arm) wrote:
> >>>> On 3/16/26 07:25, Baolin Wang wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Sure. However, after investigating RISC‑V and x86, I found that
> >>>>> ptep_clear_flush_young() does not flush the TLB on these architectures:
> >>>>>
> >>>>> int ptep_clear_flush_young(struct vm_area_struct *vma,
> >>>>> unsigned long address, pte_t *ptep)
> >>>>> {
> >>>>> /*
> >>>>> * On x86 CPUs, clearing the accessed bit without a TLB flush
> >>>>> * doesn't cause data corruption. [ It could cause incorrect
> >>>>> * page aging and the (mistaken) reclaim of hot pages, but the
> >>>>> * chance of that should be relatively low. ]
> >>>>> *
> >>>>> * So as a performance optimization don't flush the TLB when
> >>>>> * clearing the accessed bit, it will eventually be flushed by
> >>>>> * a context switch or a VM operation anyway. [ In the rare
> >>>>> * event of it not getting flushed for a long time the delay
> >>>>> * shouldn't really matter because there's no real memory
> >>>>> * pressure for swapout to react to. ]
> >>>>> */
> >>>>> return ptep_test_and_clear_young(vma, address, ptep);
> >>>>> }
> >>>>
> >>>> You'd probably want an arch helper then, that tells you whether
> >>>> a flush_tlb_range() after ptep_test_and_clear_young() is required.
> >>>>
> >>>> Or some special flush_tlb_range() helper.
> >>>>
> >>>> I agree that it requires more work.
>
> (Sorry, David. I forgot to reply to your email because I've had a lot to
> sort out recently.)
>
> Rather than adding more arch helpers (we already have plenty for the
> young flag check), I think we should try removing the TLB flush, as I
> mentioned to Barry[1]. MGLRU reclaim already skips the TLB flush, and it
> seems to work fine. What do you think?
>
> Here are our previous attempts to remove the TLB flush:
>
> My patch: https://lkml.org/lkml/2023/10/24/533
> Barry's patch:
> https://lore.kernel.org/lkml/20220617070555.344368-1-21cnbao@gmail.com/
>
> [1]
> https://lore.kernel.org/all/6bdc4b03-9631-4717-a3fa-2785a7930aba@linux.alibaba.com/
x86: ptep_clear_flush_young does not perform any TLB
invalidation. simply, calling ptep_test_and_clear_young()
RISC-V: follows the exact same behavior as x86.
S390:
simply, calling ptep_test_and_clear_young()
powerpc:
simply, calling ptep_test_and_clear_young();
parisc:
set_pte + __flush_cache_page
but ptep_test_and_clear_young() doesn't need __flush_cache_page()
arm64:
ptep_test_and_clear_young() followed by
flush_tlb_page_nosync() can still be expensive,
based on my previous observations.
others:
ptep_test_and_clear_young + flush_tlb_page
revisiting the comment for x86:
/*
* On x86 CPUs, clearing the accessed bit without a TLB flush
* doesn't cause data corruption. [ It could cause incorrect
* page aging and the (mistaken) reclaim of hot pages, but the
* chance of that should be relatively low. ]
*
* So as a performance optimization don't flush the TLB when
* clearing the accessed bit, it will eventually be flushed by
* a context switch or a VM operation anyway. [ In the rare
* event of it not getting flushed for a long time the delay
* shouldn't really matter because there's no real memory
* pressure for swapout to react to. ]
*/
At least I feel this also applies to ARM64?
Maybe Ryan, Will, or Catalin can clarify why ARM64 requires a
nosync TLBI, whereas x86 does not?
Thanks
Barry
^ permalink raw reply
* Re: [PATCH 02/17] raid6: remove __KERNEL__ ifdefs
From: Christoph Hellwig @ 2026-03-26 5:25 UTC (permalink / raw)
To: Eric Biggers
Cc: H. Peter Anvin, Christoph Hellwig, Andrew Morton, Catalin Marinas,
Will Deacon, Ard Biesheuvel, Huacai Chen, WANG Xuerui,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Herbert Xu, Dan Williams, Chris Mason, David Sterba,
Arnd Bergmann, Song Liu, Yu Kuai, Li Nan, linux-kernel,
linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv,
linux-s390, linux-crypto, linux-btrfs, linux-arch, linux-raid
In-Reply-To: <20260325195821.GD2305@quark>
On Wed, Mar 25, 2026 at 12:58:21PM -0700, Eric Biggers wrote:
> While I do like developing code in userspace as well, I've been doing it
> less over time as the kernel's tests and benchmarks have been improved.
> Running the KUnit tests is pretty straightforward and fast.
Yes. I would have totally subscribed to hpa's position when he initially
wrote the code, but 20+ years later things look different. In fact these
days I often write code intended for userspace in the kernel first to
benefit from lockdep primarily, but also other checkers that are in theory
available in userspace but as easy to use. Now of course lockdep doesn't
really matter for the algorithms here, but the rest still stands.
I also find the point of developing new code for new platforms
interesting: in this decade we had two new platforms added: loongarch
and riscv and all other changes were to the wiring up and not the
algorithms. And of those riscv only had the compile in userspace
support added 8 month after the algorithm, so it doesn't really look
like development was aided by it. We also plan to add new optimized
code, and getting the library in shape and dropping the hard to
maintain userspace code is actually prep work for making that not
painful.
>
> The issues with providing userspace build support in the tree are that:
>
> - It has to be maintained.
> - It's fundamentally a bit of a hack that is used only by developers
> (who always have the option of doing something locally that is
> tailored to the specific function they're working on)
> - It diverts effort from the kernel's actual test and benchmark.
>
> So while the faster iteration speed that userspace development enables
> is definitely nice, I do think we should be cautious with committing to
> maintain it in the kernel tree. If it's causing problems for the
> ongoing refactoring, dropping it for now seems reasonable to me.
>
> I would suggest adding a benchmark to the KUnit test similar to the
> crypto and CRC ones, though.
The code already has a benchmark used for runtime selection, although
that could be improved on and run for bigger data sets from kunit.
^ permalink raw reply
* [PATCH v2 3/3] clk: mediatek: mt7988: use MUX_CLR_SET for gate-less muxes
From: Daniel Golle @ 2026-03-26 5:11 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Matthias Brugger,
AngeloGioacchino Del Regno, Daniel Golle,
Nícolas F. R. A. Prado, Laura Nao, Chen-Yu Tsai, Weiyi Lu,
Chun-Jie Chen, Ikjoon Jang, Sam Shih, linux-clk, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1774499536.git.daniel@makrotopia.org>
All 19 muxes in the infra_muxes[] array are pure mux selectors without
a clock gate or update register, yet they were defined using
MUX_GATE_CLR_SET_UPD with gate_shift = -1.
This macro assigns mtk_mux_gate_clr_set_upd_ops, whose
enable/disable/is_enabled callbacks perform BIT(gate_shift). Since
gate_shift is stored as u8, the -1 truncates to 255, causing a
shift-out-of-bounds at runtime:
UBSAN: shift-out-of-bounds in drivers/clk/mediatek/clk-mux.c:76:8
shift exponent 255 is too large for 64-bit type 'long unsigned int'
UBSAN: shift-out-of-bounds in drivers/clk/mediatek/clk-mux.c:102:4
shift exponent 255 is too large for 64-bit type 'long unsigned int'
UBSAN: shift-out-of-bounds in drivers/clk/mediatek/clk-mux.c:122:16
shift exponent 255 is too large for 64-bit type 'long unsigned int'
Switch these definitions to MUX_CLR_SET, which uses
mtk_mux_clr_set_upd_ops (no gate callbacks) and does not require
callers to pass sentinel values for unused update register fields.
The actual clock gating for these peripherals is handled by the
separate GATE_INFRA* definitions further down.
Fixes: 4b4719437d85f ("clk: mediatek: add drivers for MT7988 SoC")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/clk/mediatek/clk-mt7988-infracfg.c | 80 ++++++++++------------
1 file changed, 38 insertions(+), 42 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt7988-infracfg.c b/drivers/clk/mediatek/clk-mt7988-infracfg.c
index ef8267319d91b..13ffa9d88e24b 100644
--- a/drivers/clk/mediatek/clk-mt7988-infracfg.c
+++ b/drivers/clk/mediatek/clk-mt7988-infracfg.c
@@ -56,49 +56,45 @@ static const char *const infra_pcie_gfmux_tl_ck_o_p3_parents[] __initconst = {
static const struct mtk_mux infra_muxes[] = {
/* MODULE_CLK_SEL_0 */
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART0_SEL, "infra_mux_uart0_sel",
- infra_mux_uart0_parents, 0x0018, 0x0010, 0x0014, 0, 1, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART1_SEL, "infra_mux_uart1_sel",
- infra_mux_uart1_parents, 0x0018, 0x0010, 0x0014, 1, 1, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_UART2_SEL, "infra_mux_uart2_sel",
- infra_mux_uart2_parents, 0x0018, 0x0010, 0x0014, 2, 1, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI0_SEL, "infra_mux_spi0_sel", infra_mux_spi0_parents,
- 0x0018, 0x0010, 0x0014, 4, 1, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI1_SEL, "infra_mux_spi1_sel", infra_mux_spi1_parents,
- 0x0018, 0x0010, 0x0014, 5, 1, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_MUX_SPI2_SEL, "infra_mux_spi2_sel", infra_mux_spi0_parents,
- 0x0018, 0x0010, 0x0014, 6, 1, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_SEL, "infra_pwm_sel", infra_pwm_bck_parents, 0x0018,
- 0x0010, 0x0014, 14, 2, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK1_SEL, "infra_pwm_ck1_sel", infra_pwm_bck_parents,
- 0x0018, 0x0010, 0x0014, 16, 2, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK2_SEL, "infra_pwm_ck2_sel", infra_pwm_bck_parents,
- 0x0018, 0x0010, 0x0014, 18, 2, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK3_SEL, "infra_pwm_ck3_sel", infra_pwm_bck_parents,
- 0x0018, 0x0010, 0x0014, 20, 2, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK4_SEL, "infra_pwm_ck4_sel", infra_pwm_bck_parents,
- 0x0018, 0x0010, 0x0014, 22, 2, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK5_SEL, "infra_pwm_ck5_sel", infra_pwm_bck_parents,
- 0x0018, 0x0010, 0x0014, 24, 2, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK6_SEL, "infra_pwm_ck6_sel", infra_pwm_bck_parents,
- 0x0018, 0x0010, 0x0014, 26, 2, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK7_SEL, "infra_pwm_ck7_sel", infra_pwm_bck_parents,
- 0x0018, 0x0010, 0x0014, 28, 2, -1, -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PWM_CK8_SEL, "infra_pwm_ck8_sel", infra_pwm_bck_parents,
- 0x0018, 0x0010, 0x0014, 30, 2, -1, -1, -1),
+ MUX_CLR_SET(CLK_INFRA_MUX_UART0_SEL, "infra_mux_uart0_sel",
+ infra_mux_uart0_parents, 0x0018, 0x0010, 0x0014, 0, 1),
+ MUX_CLR_SET(CLK_INFRA_MUX_UART1_SEL, "infra_mux_uart1_sel",
+ infra_mux_uart1_parents, 0x0018, 0x0010, 0x0014, 1, 1),
+ MUX_CLR_SET(CLK_INFRA_MUX_UART2_SEL, "infra_mux_uart2_sel",
+ infra_mux_uart2_parents, 0x0018, 0x0010, 0x0014, 2, 1),
+ MUX_CLR_SET(CLK_INFRA_MUX_SPI0_SEL, "infra_mux_spi0_sel",
+ infra_mux_spi0_parents, 0x0018, 0x0010, 0x0014, 4, 1),
+ MUX_CLR_SET(CLK_INFRA_MUX_SPI1_SEL, "infra_mux_spi1_sel",
+ infra_mux_spi1_parents, 0x0018, 0x0010, 0x0014, 5, 1),
+ MUX_CLR_SET(CLK_INFRA_MUX_SPI2_SEL, "infra_mux_spi2_sel",
+ infra_mux_spi0_parents, 0x0018, 0x0010, 0x0014, 6, 1),
+ MUX_CLR_SET(CLK_INFRA_PWM_SEL, "infra_pwm_sel",
+ infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 14, 2),
+ MUX_CLR_SET(CLK_INFRA_PWM_CK1_SEL, "infra_pwm_ck1_sel",
+ infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 16, 2),
+ MUX_CLR_SET(CLK_INFRA_PWM_CK2_SEL, "infra_pwm_ck2_sel",
+ infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 18, 2),
+ MUX_CLR_SET(CLK_INFRA_PWM_CK3_SEL, "infra_pwm_ck3_sel",
+ infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 20, 2),
+ MUX_CLR_SET(CLK_INFRA_PWM_CK4_SEL, "infra_pwm_ck4_sel",
+ infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 22, 2),
+ MUX_CLR_SET(CLK_INFRA_PWM_CK5_SEL, "infra_pwm_ck5_sel",
+ infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 24, 2),
+ MUX_CLR_SET(CLK_INFRA_PWM_CK6_SEL, "infra_pwm_ck6_sel",
+ infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 26, 2),
+ MUX_CLR_SET(CLK_INFRA_PWM_CK7_SEL, "infra_pwm_ck7_sel",
+ infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 28, 2),
+ MUX_CLR_SET(CLK_INFRA_PWM_CK8_SEL, "infra_pwm_ck8_sel",
+ infra_pwm_bck_parents, 0x0018, 0x0010, 0x0014, 30, 2),
/* MODULE_CLK_SEL_1 */
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL, "infra_pcie_gfmux_tl_o_p0_sel",
- infra_pcie_gfmux_tl_ck_o_p0_parents, 0x0028, 0x0020, 0x0024, 0, 2, -1,
- -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL, "infra_pcie_gfmux_tl_o_p1_sel",
- infra_pcie_gfmux_tl_ck_o_p1_parents, 0x0028, 0x0020, 0x0024, 2, 2, -1,
- -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL, "infra_pcie_gfmux_tl_o_p2_sel",
- infra_pcie_gfmux_tl_ck_o_p2_parents, 0x0028, 0x0020, 0x0024, 4, 2, -1,
- -1, -1),
- MUX_GATE_CLR_SET_UPD(CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL, "infra_pcie_gfmux_tl_o_p3_sel",
- infra_pcie_gfmux_tl_ck_o_p3_parents, 0x0028, 0x0020, 0x0024, 6, 2, -1,
- -1, -1),
+ MUX_CLR_SET(CLK_INFRA_PCIE_GFMUX_TL_O_P0_SEL, "infra_pcie_gfmux_tl_o_p0_sel",
+ infra_pcie_gfmux_tl_ck_o_p0_parents, 0x0028, 0x0020, 0x0024, 0, 2),
+ MUX_CLR_SET(CLK_INFRA_PCIE_GFMUX_TL_O_P1_SEL, "infra_pcie_gfmux_tl_o_p1_sel",
+ infra_pcie_gfmux_tl_ck_o_p1_parents, 0x0028, 0x0020, 0x0024, 2, 2),
+ MUX_CLR_SET(CLK_INFRA_PCIE_GFMUX_TL_O_P2_SEL, "infra_pcie_gfmux_tl_o_p2_sel",
+ infra_pcie_gfmux_tl_ck_o_p2_parents, 0x0028, 0x0020, 0x0024, 4, 2),
+ MUX_CLR_SET(CLK_INFRA_PCIE_GFMUX_TL_O_P3_SEL, "infra_pcie_gfmux_tl_o_p3_sel",
+ infra_pcie_gfmux_tl_ck_o_p3_parents, 0x0028, 0x0020, 0x0024, 6, 2),
};
static const struct mtk_gate_regs infra0_cg_regs = {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/3] clk: mediatek: mt8192: use MUX_CLR_SET
From: Daniel Golle @ 2026-03-26 5:10 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Matthias Brugger,
AngeloGioacchino Del Regno, Daniel Golle,
Nícolas F. R. A. Prado, Laura Nao, Chen-Yu Tsai, Weiyi Lu,
Chun-Jie Chen, Ikjoon Jang, Sam Shih, linux-clk, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1774499536.git.daniel@makrotopia.org>
The mfg_pll_sel mux has neither a clock gate nor an update register,
and upd_ofs is stored as u32, so the -1 truncates to 0xFFFFFFFF.
While upd_shift being -1 (as s8) prevents the update path from
executing at runtime, the bogus upd_ofs value is still stored in the
struct.
Use MUX_CLR_SET to avoid passing sentinel values to wrongly-typed
fields.
Fixes: 710573dee31b4 ("clk: mediatek: Add MT8192 basic clocks support")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/clk/mediatek/clk-mt8192.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8192.c b/drivers/clk/mediatek/clk-mt8192.c
index 50b43807c60cf..6413619880483 100644
--- a/drivers/clk/mediatek/clk-mt8192.c
+++ b/drivers/clk/mediatek/clk-mt8192.c
@@ -579,8 +579,8 @@ static const struct mtk_mux top_mtk_muxes[] = {
dsp7_parents, 0x050, 0x054, 0x058, 0, 3, 7, 0x004, 16),
MUX_GATE_CLR_SET_UPD(CLK_TOP_MFG_REF_SEL, "mfg_ref_sel",
mfg_ref_parents, 0x050, 0x054, 0x058, 16, 2, 23, 0x004, 18),
- MUX_CLR_SET_UPD(CLK_TOP_MFG_PLL_SEL, "mfg_pll_sel",
- mfg_pll_parents, 0x050, 0x054, 0x058, 18, 1, -1, -1),
+ MUX_CLR_SET(CLK_TOP_MFG_PLL_SEL, "mfg_pll_sel", mfg_pll_parents,
+ 0x050, 0x054, 0x058, 18, 1),
MUX_GATE_CLR_SET_UPD(CLK_TOP_CAMTG_SEL, "camtg_sel",
camtg_parents, 0x050, 0x054, 0x058, 24, 3, 31, 0x004, 19),
/* CLK_CFG_5 */
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/3] clk: mediatek: add MUX_CLR_SET macro
From: Daniel Golle @ 2026-03-26 5:09 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Matthias Brugger,
AngeloGioacchino Del Regno, Daniel Golle,
Nícolas F. R. A. Prado, Laura Nao, Chen-Yu Tsai, Weiyi Lu,
Chun-Jie Chen, Ikjoon Jang, Sam Shih, linux-clk, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1774499536.git.daniel@makrotopia.org>
Some MediaTek SoCs (e.g. MT7988) define infra muxes that have neither
a clock gate nor an update register.
Add a MUX_CLR_SET convenience macro that takes only the mux register
offsets, bit shift, and width, hardcoding upd_ofs = 0 and
upd_shift = -1 so callers cannot accidentally pass bogus sentinel
values to wrongly-typed fields.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/clk/mediatek/clk-mux.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/mediatek/clk-mux.h b/drivers/clk/mediatek/clk-mux.h
index 151e56dcf8842..8a5d6aca43aa9 100644
--- a/drivers/clk/mediatek/clk-mux.h
+++ b/drivers/clk/mediatek/clk-mux.h
@@ -126,6 +126,11 @@ extern const struct clk_ops mtk_mux_gate_hwv_fenc_clr_set_upd_ops;
0, _upd_ofs, _upd, CLK_SET_RATE_PARENT, \
mtk_mux_clr_set_upd_ops)
+#define MUX_CLR_SET(_id, _name, _parents, _mux_ofs, \
+ _mux_set_ofs, _mux_clr_ofs, _shift, _width) \
+ MUX_CLR_SET_UPD(_id, _name, _parents, _mux_ofs, \
+ _mux_set_ofs, _mux_clr_ofs, _shift, _width, 0, -1)
+
#define MUX_GATE_HWV_FENC_CLR_SET_UPD_FLAGS(_id, _name, _parents, \
_mux_ofs, _mux_set_ofs, _mux_clr_ofs, \
_hwv_sta_ofs, _hwv_set_ofs, _hwv_clr_ofs, \
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/3] clk: mediatek: fix gate-less mux definitions
From: Daniel Golle @ 2026-03-26 5:09 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Matthias Brugger,
AngeloGioacchino Del Regno, Daniel Golle,
Nícolas F. R. A. Prado, Laura Nao, Chen-Yu Tsai, Weiyi Lu,
Chun-Jie Chen, Ikjoon Jang, Sam Shih, linux-clk, linux-kernel,
linux-arm-kernel, linux-mediatek
Some MediaTek clock drivers define gate-less muxes without an update
register using MUX_GATE_CLR_SET_UPD, passing -1 as a sentinel for the
absent gate and update fields. Since those fields are stored in u8 and
u32 struct members, the -1 truncates to unexpected values.
Add MUX_CLR_SET, a wrapper around MUX_CLR_SET_UPD that hardcodes the
absent fields, and convert the affected mux definitions in mt8192 and
mt7988 to use it.
Daniel Golle (3):
clk: mediatek: add MUX_CLR_SET macro
clk: mediatek: mt8192: use MUX_CLR_SET
clk: mediatek: mt7988: use MUX_CLR_SET for gate-less muxes
drivers/clk/mediatek/clk-mt7988-infracfg.c | 80 ++++++++++------------
drivers/clk/mediatek/clk-mt8192.c | 4 +-
drivers/clk/mediatek/clk-mux.h | 6 ++
3 files changed, 46 insertions(+), 44 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v2 1/8] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
From: Sean Wang @ 2026-03-26 5:05 UTC (permalink / raw)
To: Javier Tia
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno, linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek, Ryan Gilbert
In-Reply-To: <20260325-mt7927-bt-support-v2-1-b892a3252880@jetm.me>
Hi, Javier
This is already a clear improvement over the previous version, but I
think there are still a few areas that could be refined further.
On Wed, Mar 25, 2026 at 6:33 PM Javier Tia <floss@jetm.me> wrote:
>
> The MediaTek MT7927 (Filogic 380) combo WiFi 7 + BT 5.4 module uses
> hardware variant 0x6639 for its Bluetooth subsystem. Without this patch,
> the chip fails with "Unsupported hardware variant (00006639)" or hangs
> during firmware download.
>
> Three changes are needed to support MT6639:
>
> 1. CHIPID workaround: On some boards the BT USB MMIO register reads
> 0x0000 for dev_id, causing the driver to skip the 0x6639 init path.
> Force dev_id to 0x6639 when it reads zero, matching the equivalent
> WiFi-side workaround that forces chip=0x7927.
>
> 2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
> "1_1" used by MT7925 and other variants. The firmware path is
> mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin.
>
> 3. Section filtering: The MT6639 firmware binary contains 9 sections, but
> only sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related.
> Sending the remaining WiFi/other sections causes an irreversible BT
> subsystem hang requiring a full power cycle. This matches the Windows
> driver behavior observed via USB captures.
>
> Also add 0x6639 to the reset register (CONNV3) and firmware setup switch
> cases alongside the existing 0x7925 handling.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
> Link: https://github.com/openwrt/mt76/issues/927
> Reported-by: Ryan Gilbert <xelnaga@gmail.com>
> Signed-off-by: Javier Tia <floss@jetm.me>
> ---
> drivers/bluetooth/btmtk.c | 23 +++++++++++++++++++++--
> drivers/bluetooth/btmtk.h | 1 +
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
> index 2507d587f28a..13c6e45deede 100644
> --- a/drivers/bluetooth/btmtk.c
> +++ b/drivers/bluetooth/btmtk.c
> @@ -112,7 +112,11 @@ static void btmtk_coredump_notify(struct hci_dev *hdev, int state)
> void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id, u32 fw_ver,
> u32 fw_flavor)
> {
> - if (dev_id == 0x7925)
> + if (dev_id == 0x6639)
> + snprintf(buf, size,
> + "mediatek/mt%04x/BT_RAM_CODE_MT%04x_2_%x_hdr.bin",
> + dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
> + else if (dev_id == 0x7925)
> snprintf(buf, size,
> "mediatek/mt%04x/BT_RAM_CODE_MT%04x_1_%x_hdr.bin",
> dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
> @@ -130,6 +134,7 @@ EXPORT_SYMBOL_GPL(btmtk_fw_get_filename);
> int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
> wmt_cmd_sync_func_t wmt_cmd_sync)
> {
> + struct btmtk_data *data = hci_get_priv(hdev);
> struct btmtk_hci_wmt_params wmt_params;
> struct btmtk_patch_header *hdr;
> struct btmtk_global_desc *globaldesc = NULL;
> @@ -166,6 +171,14 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
> section_offset = le32_to_cpu(sectionmap->secoffset);
> dl_size = le32_to_cpu(sectionmap->bin_info_spec.dlsize);
>
> + /* MT6639: only download sections where dlmode byte0 == 0x01,
> + * matching the Windows driver behavior which skips WiFi/other
> + * sections that would cause the chip to hang.
> + */
> + if (data->dev_id == 0x6639 && dl_size > 0 &&
> + (le32_to_cpu(sectionmap->bin_info_spec.dlmodecrctype) & 0xff) != 0x01)
> + continue;
> +
> if (dl_size > 0) {
> retry = 20;
> while (retry > 0) {
> @@ -852,7 +865,7 @@ int btmtk_usb_subsys_reset(struct hci_dev *hdev, u32 dev_id)
> if (err < 0)
> return err;
> msleep(100);
> - } else if (dev_id == 0x7925) {
> + } else if (dev_id == 0x7925 || dev_id == 0x6639) {
> err = btmtk_usb_uhw_reg_read(hdev, MTK_BT_RESET_REG_CONNV3, &val);
> if (err < 0)
> return err;
> @@ -1322,6 +1335,11 @@ int btmtk_usb_setup(struct hci_dev *hdev)
> fw_flavor = (fw_flavor & 0x00000080) >> 7;
> }
>
> + if (!dev_id) {
> + bt_dev_info(hdev, "MT6639: raw CHIPID=0x0000, forcing chip=0x6639");
> + dev_id = 0x6639;
> + }
Using raw CHIPID=0x0000 to unconditionally force 0x6639 seems fragile.
If another device later hits the same missing-ID condition, it would
also be misdetected as MT6639. Normally this kind of quirk could be
carried in .driver_data, but since btusb.c is shared, I'm not sure
that is the right fit here either. This should probably be handled
through a more device-specific fallback instead of mapping all zero
CHIPID cases to 0x6639.
> +
> btmtk_data->dev_id = dev_id;
>
> err = btmtk_register_coredump(hdev, btmtk_data->drv_name, fw_version);
> @@ -1339,6 +1357,7 @@ int btmtk_usb_setup(struct hci_dev *hdev)
> case 0x7925:
> case 0x7961:
> case 0x7902:
> + case 0x6639:
> btmtk_fw_get_filename(fw_bin_name, sizeof(fw_bin_name), dev_id,
> fw_version, fw_flavor);
>
> diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
> index adaf385626ee..6645bcadb523 100644
> --- a/drivers/bluetooth/btmtk.h
> +++ b/drivers/bluetooth/btmtk.h
> @@ -8,6 +8,7 @@
> #define FIRMWARE_MT7902 "mediatek/BT_RAM_CODE_MT7902_1_1_hdr.bin"
> #define FIRMWARE_MT7961 "mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin"
> #define FIRMWARE_MT7925 "mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin"
> +#define FIRMWARE_MT7927 "mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin"
Sorry I did not respond to this earlier.
I would prefer using the mediatek/mt7927/ folder naming here. mt7927
is more widely recognized, and using it would avoid unnecessary
confusion.
>
> #define HCI_EV_WMT 0xe4
> #define HCI_WMT_MAX_EVENT_SIZE 64
>
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH 0/4] arm64: dts: renesas: Fix PHY C22 compatible strings
From: Marek Vasut @ 2026-03-26 4:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Biju Das, linux-arm-kernel@lists.infradead.org, Conor Dooley,
Geert Uytterhoeven, Krzysztof Kozlowski, Prabhakar Mahadev Lad,
magnus.damm, Rob Herring, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <CAMuHMdV_rGpnx6DzmdDgAsRJ4hXy8TP+pSnnzURjeGZfxB+5wg@mail.gmail.com>
On 3/25/26 3:32 PM, Geert Uytterhoeven wrote:
Hello Geert,
> On Mon, 16 Mar 2026 at 13:37, Marek Vasut <marek.vasut@mailbox.org> wrote:
>> On 3/16/26 10:11 AM, Biju Das wrote:
>>>> There is also Marek's older series ([1][2], as Marek doesn't do cover letters ;-).
>>
>> You seem to be commenting on a 0/4 cover letter here ...
>
> Ha, the exception to the general rule ;-)
Hehehe.
>>>> [1] "[PATCH 1/2] ARM: dts: renesas: Drop ethernet-phy-ieee802.3-c22 from PHY compatible string on all
>>>> RZ boards"
>>>> https://lore.kernel.org/20240630034649.173229-1-marex@denx.de/
>>>> [2] "[PATCH 2/2] arm64: dts: renesas: Drop ethernet-phy-ieee802.3-c22 from PHY compatible string on
>>>> all RZ boards"
>>>> https://lore.kernel.org/20240630034649.173229-2-marex@denx.de
>>>
>>> I haven't seen these patches.
>>
>> They are deprecated.
>>
>>> It does not cover all the SoCs/boards. If Marek want to take over, He can send next version
>>> covering all Renesas boards + binding change.
>> Isn't this series effectively exactly that ?
>
> I believe we still have e.g. the KSZ8041 and KSZ9031 PHY nodes to fix,
> for both RZ and R-Car boards? Some of them were covered by [1] and
> [2] above.
I hope this is now all addressed by two board fixes [3] [4] and one
larger fix [5]. But there are also other warnings on the arm32 side
which are not related to ethernet schemas.
[3]
https://lore.kernel.org/linux-arm-kernel/20260326045355.223529-1-marek.vasut+renesas@mailbox.org/
[4]
https://lore.kernel.org/linux-arm-kernel/20260326045416.223556-1-marek.vasut+renesas@mailbox.org/
[5]
https://lore.kernel.org/linux-arm-kernel/20260326045523.223620-1-marek.vasut+renesas@mailbox.org/
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v4 0/5] Add support for AAEON SRG-IMX8P MCU
From: Guenter Roeck @ 2026-03-26 4:56 UTC (permalink / raw)
To: Thomas Perrot (Schneider Electric), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Lee Jones
Cc: devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski
In-Reply-To: <20260324-dev-b4-aaeon-mcu-driver-v4-0-afb011df4794@bootlin.com>
Hi,
On 3/24/26 12:24, Thomas Perrot (Schneider Electric) wrote:
> This patch series introduces support for the AAEON SRG-IMX8P embedded
> controller (MCU). The MCU is connected via I2C and provides GPIO and
> watchdog functionality for the SRG-IMX8P board.
>
> The series includes:
> - Device tree binding for the MFD driver
> - MFD driver that serves as the core driver for the MCU
> - GPIO driver implementing the GPIO functionality
> - Watchdog driver for system monitoring
> - MAINTAINERS entry for the new drivers
>
> The drivers follow the standard Linux kernel subsystem patterns, with
> the MFD driver registering the sub-devices (GPIO and watchdog) which
> are then handled by their respective subsystem drivers.
>
> Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
Sashiko reports a number of issues with this series.
https://sashiko.dev/#/patchset/20260324-dev-b4-aaeon-mcu-driver-v4-0-afb011df4794%40bootlin.com
I can not comment on the non-watchdog concerns, even though the ones I looked at
seem to be valid. However, please address the watchdog subsystem related comments.
If functionality such as CONFIG_WATCHDOG_NOWAYOUT is explicitly not supported,
please add the rationale as comment into the driver.
Thanks,
Guenter
^ permalink raw reply
* [PATCH] clk: kirkwood: use kzalloc_flex
From: Rosen Penev @ 2026-03-26 4:55 UTC (permalink / raw)
To: linux-clk
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Michael Turquette, Stephen Boyd, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
Simplify allocation by using a flexible array member and kzalloc_flex to
combine allocations.
Add __counted_by for extra runtime analysis. Move counting variable
assignment to right after allocation as required by __counted_by.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/clk/mvebu/kirkwood.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/mvebu/kirkwood.c b/drivers/clk/mvebu/kirkwood.c
index ed061d82fb65..fc2972538008 100644
--- a/drivers/clk/mvebu/kirkwood.c
+++ b/drivers/clk/mvebu/kirkwood.c
@@ -253,8 +253,8 @@ struct clk_muxing_soc_desc {
struct clk_muxing_ctrl {
spinlock_t *lock;
- struct clk **muxes;
int num_muxes;
+ struct clk *muxes[] __counted_by(num_muxes);
};
static const char *powersave_parents[] = {
@@ -297,21 +297,18 @@ static void __init kirkwood_clk_muxing_setup(struct device_node *np,
if (WARN_ON(!base))
return;
- ctrl = kzalloc_obj(*ctrl);
- if (WARN_ON(!ctrl))
- goto ctrl_out;
-
- /* lock must already be initialized */
- ctrl->lock = &ctrl_gating_lock;
-
/* Count, allocate, and register clock muxes */
for (n = 0; desc[n].name;)
n++;
+ ctrl = kzalloc_flex(*ctrl, muxes, n);
+ if (WARN_ON(!ctrl))
+ goto ctrl_out;
+
ctrl->num_muxes = n;
- ctrl->muxes = kzalloc_objs(struct clk *, ctrl->num_muxes);
- if (WARN_ON(!ctrl->muxes))
- goto muxes_out;
+
+ /* lock must already be initialized */
+ ctrl->lock = &ctrl_gating_lock;
for (n = 0; n < ctrl->num_muxes; n++) {
ctrl->muxes[n] = clk_register_mux(NULL, desc[n].name,
--
2.53.0
^ permalink raw reply related
* [PATCH] ARM: dts: renesas: Drop KSZ8041 PHY C22 compatible string
From: Marek Vasut @ 2026-03-26 4:54 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
Microchip KSZ8041 PHY schema indicates that compatible string
"ethernet-phy-id0022.1537" must not be followed by any other
compatible string. Drop trailing "ethernet-phy-ieee802.3-c22"
to match the schema.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/renesas/r8a7743-sk-rzg1m.dts | 3 +--
arch/arm/boot/dts/renesas/r8a7745-sk-rzg1e.dts | 3 +--
arch/arm/boot/dts/renesas/r8a7790-lager.dts | 3 +--
arch/arm/boot/dts/renesas/r8a7790-stout.dts | 3 +--
arch/arm/boot/dts/renesas/r8a7791-koelsch.dts | 3 +--
arch/arm/boot/dts/renesas/r8a7791-porter.dts | 3 +--
arch/arm/boot/dts/renesas/r8a7793-gose.dts | 3 +--
arch/arm/boot/dts/renesas/r8a7794-alt.dts | 3 +--
arch/arm/boot/dts/renesas/r8a7794-silk.dts | 3 +--
9 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/renesas/r8a7743-sk-rzg1m.dts b/arch/arm/boot/dts/renesas/r8a7743-sk-rzg1m.dts
index 9b16fe7ce713c..60217797e5345 100644
--- a/arch/arm/boot/dts/renesas/r8a7743-sk-rzg1m.dts
+++ b/arch/arm/boot/dts/renesas/r8a7743-sk-rzg1m.dts
@@ -70,8 +70,7 @@ ðer {
status = "okay";
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id0022.1537",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0022.1537";
reg = <1>;
interrupts-extended = <&irqc 0 IRQ_TYPE_LEVEL_LOW>;
micrel,led-mode = <1>;
diff --git a/arch/arm/boot/dts/renesas/r8a7745-sk-rzg1e.dts b/arch/arm/boot/dts/renesas/r8a7745-sk-rzg1e.dts
index 571615a506207..42e82f0697553 100644
--- a/arch/arm/boot/dts/renesas/r8a7745-sk-rzg1e.dts
+++ b/arch/arm/boot/dts/renesas/r8a7745-sk-rzg1e.dts
@@ -65,8 +65,7 @@ ðer {
status = "okay";
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id0022.1537",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0022.1537";
reg = <1>;
interrupts-extended = <&irqc 8 IRQ_TYPE_LEVEL_LOW>;
micrel,led-mode = <1>;
diff --git a/arch/arm/boot/dts/renesas/r8a7790-lager.dts b/arch/arm/boot/dts/renesas/r8a7790-lager.dts
index 4f002aa7fbafc..8e76655016755 100644
--- a/arch/arm/boot/dts/renesas/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/renesas/r8a7790-lager.dts
@@ -685,8 +685,7 @@ ðer {
status = "okay";
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id0022.1537",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0022.1537";
reg = <1>;
interrupts-extended = <&irqc0 0 IRQ_TYPE_LEVEL_LOW>;
micrel,led-mode = <1>;
diff --git a/arch/arm/boot/dts/renesas/r8a7790-stout.dts b/arch/arm/boot/dts/renesas/r8a7790-stout.dts
index b1e20579e0710..8ba9d85f10389 100644
--- a/arch/arm/boot/dts/renesas/r8a7790-stout.dts
+++ b/arch/arm/boot/dts/renesas/r8a7790-stout.dts
@@ -208,8 +208,7 @@ ðer {
status = "okay";
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id0022.1537",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0022.1537";
reg = <1>;
interrupts-extended = <&irqc0 1 IRQ_TYPE_LEVEL_LOW>;
micrel,led-mode = <1>;
diff --git a/arch/arm/boot/dts/renesas/r8a7791-koelsch.dts b/arch/arm/boot/dts/renesas/r8a7791-koelsch.dts
index 61ea438eb6af1..48db62e0ff874 100644
--- a/arch/arm/boot/dts/renesas/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/renesas/r8a7791-koelsch.dts
@@ -676,8 +676,7 @@ ðer {
status = "okay";
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id0022.1537",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0022.1537";
reg = <1>;
interrupts-extended = <&irqc0 0 IRQ_TYPE_LEVEL_LOW>;
micrel,led-mode = <1>;
diff --git a/arch/arm/boot/dts/renesas/r8a7791-porter.dts b/arch/arm/boot/dts/renesas/r8a7791-porter.dts
index 81b3c5d74e9b3..811e263452acd 100644
--- a/arch/arm/boot/dts/renesas/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/renesas/r8a7791-porter.dts
@@ -326,8 +326,7 @@ ðer {
status = "okay";
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id0022.1537",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0022.1537";
reg = <1>;
interrupts-extended = <&irqc0 0 IRQ_TYPE_LEVEL_LOW>;
micrel,led-mode = <1>;
diff --git a/arch/arm/boot/dts/renesas/r8a7793-gose.dts b/arch/arm/boot/dts/renesas/r8a7793-gose.dts
index 5c6928c941aca..69d9c674bb032 100644
--- a/arch/arm/boot/dts/renesas/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/renesas/r8a7793-gose.dts
@@ -616,8 +616,7 @@ ðer {
status = "okay";
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id0022.1537",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0022.1537";
reg = <1>;
interrupts-extended = <&irqc0 0 IRQ_TYPE_LEVEL_LOW>;
micrel,led-mode = <1>;
diff --git a/arch/arm/boot/dts/renesas/r8a7794-alt.dts b/arch/arm/boot/dts/renesas/r8a7794-alt.dts
index 3f06a7f67d62a..5d6d0d8cc4dd8 100644
--- a/arch/arm/boot/dts/renesas/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/renesas/r8a7794-alt.dts
@@ -378,8 +378,7 @@ ðer {
status = "okay";
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id0022.1537",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0022.1537";
reg = <1>;
interrupts-extended = <&irqc0 8 IRQ_TYPE_LEVEL_LOW>;
micrel,led-mode = <1>;
diff --git a/arch/arm/boot/dts/renesas/r8a7794-silk.dts b/arch/arm/boot/dts/renesas/r8a7794-silk.dts
index 3428256057680..af474b1d9676d 100644
--- a/arch/arm/boot/dts/renesas/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/renesas/r8a7794-silk.dts
@@ -412,8 +412,7 @@ ðer {
status = "okay";
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id0022.1537",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0022.1537";
reg = <1>;
interrupts-extended = <&irqc0 8 IRQ_TYPE_LEVEL_LOW>;
micrel,led-mode = <1>;
--
2.53.0
^ permalink raw reply related
* [PATCH] ARM: dts: renesas: rza2mevb: Drop RTL8211F PHY C22 compatible string
From: Marek Vasut @ 2026-03-26 4:54 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
Realtek RTL8211F PHY schema indicates that compatible string
"ethernet-phy-id001c.c916" must not be followed by any other
compatible string. Drop trailing "ethernet-phy-ieee802.3-c22"
to match the schema.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/renesas/r7s9210-rza2mevb.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/renesas/r7s9210-rza2mevb.dts b/arch/arm/boot/dts/renesas/r7s9210-rza2mevb.dts
index f69a7fe56b6e7..55221c82ef642 100644
--- a/arch/arm/boot/dts/renesas/r7s9210-rza2mevb.dts
+++ b/arch/arm/boot/dts/renesas/r7s9210-rza2mevb.dts
@@ -94,8 +94,7 @@ ðer1 {
renesas,no-ether-link;
phy-handle = <&phy1>;
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id001c.c816",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id001c.c816";
reg = <0>;
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH] ARM: dts: renesas: r8a7742-iwg21d-q7-dbcm-ca: Drop KSZ8081 PHY C22 compatible string
From: Marek Vasut @ 2026-03-26 4:53 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
Microchip KSZ8081 PHY schema indicates that compatible string
"ethernet-phy-id0022.1560" must not be followed by any other
compatible string. Drop trailing "ethernet-phy-ieee802.3-c22"
to match the schema.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm/boot/dts/renesas/r8a7742-iwg21d-q7-dbcm-ca.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/renesas/r8a7742-iwg21d-q7-dbcm-ca.dts b/arch/arm/boot/dts/renesas/r8a7742-iwg21d-q7-dbcm-ca.dts
index 33ac4bd1e63bd..c43c08d9ff944 100644
--- a/arch/arm/boot/dts/renesas/r8a7742-iwg21d-q7-dbcm-ca.dts
+++ b/arch/arm/boot/dts/renesas/r8a7742-iwg21d-q7-dbcm-ca.dts
@@ -85,8 +85,7 @@ ðer {
status = "okay";
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id0022.1560",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0022.1560";
reg = <1>;
micrel,led-mode = <1>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH] clk: bcm: iproc-asiu: simplify allocation
From: Rosen Penev @ 2026-03-26 4:53 UTC (permalink / raw)
To: linux-clk
Cc: Michael Turquette, Stephen Boyd, Ray Jui, Scott Branden,
Broadcom internal kernel review list,
moderated list:BROADCOM IPROC ARM ARCHITECTURE, open list
Use kzalloc_flex and a flexible array member to combine allocations
While at it, take clk_data out of the struct and move it into probe.
It's not used anywhere else.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/clk/bcm/clk-iproc-asiu.c | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/clk/bcm/clk-iproc-asiu.c b/drivers/clk/bcm/clk-iproc-asiu.c
index 819ab1b55df3..56a813227981 100644
--- a/drivers/clk/bcm/clk-iproc-asiu.c
+++ b/drivers/clk/bcm/clk-iproc-asiu.c
@@ -27,8 +27,7 @@ struct iproc_asiu {
void __iomem *div_base;
void __iomem *gate_base;
- struct clk_hw_onecell_data *clk_data;
- struct iproc_asiu_clk *clks;
+ struct iproc_asiu_clk clks[];
};
#define to_asiu_clk(hw) container_of(hw, struct iproc_asiu_clk, hw)
@@ -184,22 +183,19 @@ void __init iproc_asiu_setup(struct device_node *node,
{
int i, ret;
struct iproc_asiu *asiu;
+ struct clk_hw_onecell_data *clk_data;
if (WARN_ON(!gate || !div))
return;
- asiu = kzalloc_obj(*asiu);
+ asiu = kzalloc_flex(*asiu, clks, num_clks);
if (WARN_ON(!asiu))
return;
- asiu->clk_data = kzalloc_flex(*asiu->clk_data, hws, num_clks);
- if (WARN_ON(!asiu->clk_data))
+ clk_data = kzalloc_flex(*clk_data, hws, num_clks);
+ if (WARN_ON(!clk_data))
goto err_clks;
- asiu->clk_data->num = num_clks;
-
- asiu->clks = kzalloc_objs(*asiu->clks, num_clks);
- if (WARN_ON(!asiu->clks))
- goto err_asiu_clks;
+ clk_data->num = num_clks;
asiu->div_base = of_iomap(node, 0);
if (WARN_ON(!asiu->div_base))
@@ -236,11 +232,11 @@ void __init iproc_asiu_setup(struct device_node *node,
ret = clk_hw_register(NULL, &asiu_clk->hw);
if (WARN_ON(ret))
goto err_clk_register;
- asiu->clk_data->hws[i] = &asiu_clk->hw;
+ clk_data->hws[i] = &asiu_clk->hw;
}
ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get,
- asiu->clk_data);
+ clk_data);
if (WARN_ON(ret))
goto err_clk_register;
@@ -248,17 +244,14 @@ void __init iproc_asiu_setup(struct device_node *node,
err_clk_register:
while (--i >= 0)
- clk_hw_unregister(asiu->clk_data->hws[i]);
+ clk_hw_unregister(clk_data->hws[i]);
iounmap(asiu->gate_base);
err_iomap_gate:
iounmap(asiu->div_base);
err_iomap_div:
- kfree(asiu->clks);
-
-err_asiu_clks:
- kfree(asiu->clk_data);
+ kfree(clk_data);
err_clks:
kfree(asiu);
--
2.53.0
^ permalink raw reply related
* [PATCH v3] arm64: dts: imx8mp: Add DT overlays for DH i.MX8M Plus DHCOM SoM and boards
From: Marek Vasut @ 2026-03-26 4:43 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Christoph Niedermaier, Conor Dooley, Fabio Estevam,
Frank Li, Krzysztof Kozlowski, Pengutronix Kernel Team,
Rob Herring, Sascha Hauer, devicetree, imx, kernel, linux-kernel
Add DT overlays to support DH i.MX8M Plus DHCOM SoM variants and carrier
board expansion modules. The following DT overlays are implemented:
- SoM:
- DH 660-x00 SoM with 1xRMII PHY
- DH 660-x00 SoM with 2xRMII PHY
- PDK2:
- DH 505-200 Display board in edge connector X12 via direct LVDS
- DH 531-100 SPI/I2C board in header X21
- DH 531-200 SPI/I2C board in header X22
- DH 560-200 Display board in edge connector X12
- PDK3:
- DH 505-200 Display board in edge connector X36 via direct LVDS
- DH 531-100 SPI/I2C board in header X40
- DH 531-200 SPI/I2C board in header X41
- DH 560-300 Display board in edge connector X36
- EA muRata 2AE M.2 A/E-Key card in connector X20
- NXP SPF-29853-C1 MINISASTOCSI with OV5640 sensor in connector X31
- NXP SPF-29853-C1 MINISASTOCSI with OV5640 sensor in connector X29
- PicoITX:
- DH 626-100 Display board in edge connector X2
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: devicetree@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: kernel@dh-electronics.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
V2: - Update copyright years
- Add newline between reg and port
- Place status = "okay" at the end of nodes
- Sort compatible and reg
V3: Drop the macros and use DT labels instead
---
arch/arm64/boot/dts/freescale/Makefile | 115 +++++++++++++++++-
...mx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi | 37 ++++++
.../imx8mp-dhcom-overlay-panel-clock.dtsi | 33 +++++
.../imx8mp-dhcom-overlay-panel-common.dtsi | 31 +++++
.../imx8mp-dhcom-overlay-panel-dpi.dtsi | 35 ++++++
...8mp-dhcom-overlay-panel-etm0700g0edh6.dtsi | 53 ++++++++
.../imx8mp-dhcom-overlay-panel-lvds.dtsi | 22 ++++
.../imx8mp-dhcom-pdk-overlay-eth2xfast.dtso | 10 ++
...-pdk2-overlay-505-200-x12-ch101olhlwh.dtso | 40 ++++++
...imx8mp-dhcom-pdk2-overlay-531-100-x21.dtso | 32 +++++
...imx8mp-dhcom-pdk2-overlay-531-100-x22.dtso | 32 +++++
...imx8mp-dhcom-pdk2-overlay-560-300-x12.dtso | 25 ++++
.../boot/dts/freescale/imx8mp-dhcom-pdk2.dts | 2 +-
...-pdk3-overlay-505-200-x36-ch101olhlwh.dtso | 53 ++++++++
...imx8mp-dhcom-pdk3-overlay-531-100-x40.dtso | 32 +++++
...imx8mp-dhcom-pdk3-overlay-531-100-x41.dtso | 32 +++++
...imx8mp-dhcom-pdk3-overlay-560-300-x36.dtso | 24 ++++
...imx8mp-dhcom-pdk3-overlay-732-100-x36.dtso | 36 ++++++
...-dhcom-pdk3-overlay-ea-murata-2ae-x20.dtso | 56 +++++++++
...3-overlay-nxp-spf-29853-c1-ov5640-x29.dtso | 30 +++++
...3-overlay-nxp-spf-29853-c1-ov5640-x31.dtso | 30 +++++
...-pdk3-overlay-nxp-spf-29853-c1-ov5640.dtsi | 64 ++++++++++
.../boot/dts/freescale/imx8mp-dhcom-pdk3.dts | 2 +-
...icoitx-overlay-626-100-x2-ch101olhlwh.dtso | 77 ++++++++++++
.../dts/freescale/imx8mp-dhcom-picoitx.dts | 3 +
.../imx8mp-dhcom-som-overlay-eth1xfast.dtso | 85 +++++++++++++
.../imx8mp-dhcom-som-overlay-eth2xfast.dtso | 29 +++++
.../boot/dts/freescale/imx8mp-dhcom-som.dtsi | 4 +-
28 files changed, 1017 insertions(+), 7 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-clock.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-common.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-dpi.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-etm0700g0edh6.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-lvds.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk-overlay-eth2xfast.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-531-100-x21.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-531-100-x22.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-560-300-x12.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-505-200-x36-ch101olhlwh.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-531-100-x40.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-531-100-x41.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-560-300-x36.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-732-100-x36.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-ea-murata-2ae-x20.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x29.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x31.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-picoitx-overlay-626-100-x2-ch101olhlwh.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-som-overlay-eth1xfast.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-dhcom-som-overlay-eth2xfast.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 31bc80586c682..e054fdba72d7a 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -232,9 +232,118 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-data-modul-edm-sbc.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-debix-model-a.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-debix-som-a-bmb-08.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-drc02.dtb
-dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk2.dtb
-dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk3.dtb
-dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-picoitx.dtb
+
+imx8mp-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh-dtbs := \
+ imx8mp-dhcom-pdk2.dtb \
+ imx8mp-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtbo
+
+imx8mp-dhcom-pdk2-overlay-531-100-x21-dtbs := \
+ imx8mp-dhcom-pdk2.dtb \
+ imx8mp-dhcom-pdk2-overlay-531-100-x21.dtbo
+
+imx8mp-dhcom-pdk2-overlay-531-100-x22-dtbs := \
+ imx8mp-dhcom-pdk2.dtb \
+ imx8mp-dhcom-pdk2-overlay-531-100-x22.dtbo
+
+imx8mp-dhcom-pdk2-overlay-560-300-x12-dtbs := \
+ imx8mp-dhcom-pdk2.dtb \
+ imx8mp-dhcom-pdk2-overlay-560-300-x12.dtbo
+
+imx8mp-dhcom-pdk2-overlay-eth1xfast-dtbs := \
+ imx8mp-dhcom-pdk2.dtb \
+ imx8mp-dhcom-som-overlay-eth1xfast.dtbo
+
+imx8mp-dhcom-pdk2-overlay-eth2xfast-dtbs := \
+ imx8mp-dhcom-pdk2.dtb \
+ imx8mp-dhcom-som-overlay-eth2xfast.dtbo \
+ imx8mp-dhcom-pdk-overlay-eth2xfast.dtbo
+
+imx8mp-dhcom-pdk3-overlay-505-200-x36-ch101olhlwh-dtbs := \
+ imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-pdk3-overlay-505-200-x36-ch101olhlwh.dtbo
+
+imx8mp-dhcom-pdk3-overlay-531-100-x40-dtbs := \
+ imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-pdk3-overlay-531-100-x40.dtbo
+
+imx8mp-dhcom-pdk3-overlay-531-100-x41-dtbs := \
+ imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-pdk3-overlay-531-100-x41.dtbo
+
+imx8mp-dhcom-pdk3-overlay-560-300-x36-dtbs := \
+ imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-pdk3-overlay-560-300-x36.dtbo
+
+imx8mp-dhcom-pdk3-overlay-732-100-x36-dtbs := \
+ imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-pdk3-overlay-732-100-x36.dtbo
+
+imx8mp-dhcom-pdk3-overlay-ea-murata-2ae-x20-dtbs := \
+ imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-pdk3-overlay-ea-murata-2ae-x20.dtbo
+
+imx8mp-dhcom-pdk3-overlay-eth1xfast-dtbs := \
+ imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-som-overlay-eth1xfast.dtbo
+
+imx8mp-dhcom-pdk3-overlay-eth2xfast-dtbs := \
+ imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-som-overlay-eth2xfast.dtbo \
+ imx8mp-dhcom-pdk-overlay-eth2xfast.dtbo
+
+imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x29-dtbs := \
+ imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x29.dtbo
+
+imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x31-dtbs := \
+ imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x31.dtbo
+
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-som-overlay-eth1xfast.dtbo \
+ imx8mp-dhcom-som-overlay-eth2xfast.dtbo
+
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk-overlay-eth2xfast.dtbo
+
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk2.dtb \
+ imx8mp-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtb \
+ imx8mp-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtbo \
+ imx8mp-dhcom-pdk2-overlay-531-100-x21.dtb \
+ imx8mp-dhcom-pdk2-overlay-531-100-x21.dtbo \
+ imx8mp-dhcom-pdk2-overlay-531-100-x22.dtb \
+ imx8mp-dhcom-pdk2-overlay-531-100-x22.dtbo \
+ imx8mp-dhcom-pdk2-overlay-560-300-x12.dtb \
+ imx8mp-dhcom-pdk2-overlay-560-300-x12.dtbo \
+ imx8mp-dhcom-pdk2-overlay-eth1xfast.dtb \
+ imx8mp-dhcom-pdk2-overlay-eth2xfast.dtb
+
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-pdk3.dtb \
+ imx8mp-dhcom-pdk3-overlay-505-200-x36-ch101olhlwh.dtb \
+ imx8mp-dhcom-pdk3-overlay-505-200-x36-ch101olhlwh.dtbo \
+ imx8mp-dhcom-pdk3-overlay-531-100-x40.dtb \
+ imx8mp-dhcom-pdk3-overlay-531-100-x40.dtbo \
+ imx8mp-dhcom-pdk3-overlay-531-100-x41.dtb \
+ imx8mp-dhcom-pdk3-overlay-531-100-x41.dtbo \
+ imx8mp-dhcom-pdk3-overlay-560-300-x36.dtb \
+ imx8mp-dhcom-pdk3-overlay-560-300-x36.dtbo \
+ imx8mp-dhcom-pdk3-overlay-732-100-x36.dtb \
+ imx8mp-dhcom-pdk3-overlay-732-100-x36.dtbo \
+ imx8mp-dhcom-pdk3-overlay-ea-murata-2ae-x20.dtb \
+ imx8mp-dhcom-pdk3-overlay-ea-murata-2ae-x20.dtbo \
+ imx8mp-dhcom-pdk3-overlay-eth1xfast.dtb \
+ imx8mp-dhcom-pdk3-overlay-eth2xfast.dtb \
+ imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x29.dtb \
+ imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x29.dtbo \
+ imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x31.dtb \
+ imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x31.dtbo
+
+imx8mp-dhcom-picoitx-overlay-626-100-x2-ch101olhlwh-dtbs := \
+ imx8mp-dhcom-picoitx.dtb \
+ imx8mp-dhcom-picoitx-overlay-626-100-x2-ch101olhlwh.dtbo
+
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-dhcom-picoitx.dtb \
+ imx8mp-dhcom-picoitx-overlay-626-100-x2-ch101olhlwh.dtb \
+ imx8mp-dhcom-picoitx-overlay-626-100-x2-ch101olhlwh.dtbo
+
dtb-$(CONFIG_ARCH_MXC) += imx8mp-edm-g-wb.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-frdm.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi
new file mode 100644
index 0000000000000..cabda8648e0fd
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2022-2026 Marek Vasut
+ */
+
+&display_bl {
+ pwms = <&pwm1 0 5000000 0>;
+};
+
+&i2c_dhpdk_panel {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touch_lvds: touchscreen@41 {
+ compatible = "ilitek,ili251x";
+ reg = <0x41>;
+ reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <16384>;
+ touchscreen-size-y = <9600>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c04";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
+
+&panel {
+ compatible = "chefree,ch101olhlwh-002";
+};
+
+&pwm1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-clock.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-clock.dtsi
new file mode 100644
index 0000000000000..8e702636a8021
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-clock.dtsi
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2024-2026 Marek Vasut
+ */
+
+#include <dt-bindings/clock/imx8mp-clock.h>
+
+&media_blk_ctrl {
+ /*
+ * Sys PLL3 supplies TC9595 RefClk
+ * Audio PLL2 supplies MEDIA_DISP1_PIX (DSI)
+ * Video PLL1 supplies MEDIA_DISP2_PIX (LVDS)
+ */
+ assigned-clocks = <&clk IMX8MP_CLK_MEDIA_AXI>,
+ <&clk IMX8MP_CLK_MEDIA_APB>,
+ <&clk IMX8MP_CLK_MEDIA_DISP1_PIX>,
+ <&clk IMX8MP_CLK_MEDIA_DISP2_PIX>,
+ <&clk IMX8MP_AUDIO_PLL2>,
+ <&clk IMX8MP_VIDEO_PLL1>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
+ <&clk IMX8MP_SYS_PLL1_800M>,
+ <&clk IMX8MP_AUDIO_PLL2_OUT>,
+ <&clk IMX8MP_VIDEO_PLL1_OUT>;
+ assigned-clock-rates = <500000000>, <200000000>,
+ <0>, <0>, <0>, <0>;
+};
+
+&tc_bridge {
+ assigned-clocks = <&clk IMX8MP_CLK_CLKOUT2_SEL>,
+ <&clk IMX8MP_CLK_CLKOUT2>,
+ <&clk IMX8MP_SYS_PLL3_OUT>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL3_OUT>;
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-common.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-common.dtsi
new file mode 100644
index 0000000000000..e8e4b40e20449
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-common.dtsi
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/pwm/pwm.h>
+
+#include "imx8mp-dhcom-overlay-panel-clock.dtsi"
+
+&{/} {
+ display_bl: display-bl {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 16 22 30 40 55 75 102 138 188 255>;
+ default-brightness-level = <8>;
+ enable-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* GPIO G */
+ status = "okay";
+ };
+
+ panel: panel {
+ backlight = <&display_bl>;
+ power-supply = <®_vdd_3p3v_awo>;
+
+ port {
+ panel_in: endpoint {
+ };
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-dpi.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-dpi.dtsi
new file mode 100644
index 0000000000000..9c81e9f28852c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-dpi.dtsi
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2022-2026 Marek Vasut
+ */
+
+#include "imx8mp-dhcom-overlay-panel-common.dtsi"
+
+&lcdif1 {
+ status = "okay";
+};
+
+&mipi_dsi {
+ status = "okay";
+};
+
+&panel_in {
+ remote-endpoint = <&tc_bridge_out>;
+};
+
+&tc_bridge {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ tc_bridge_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-etm0700g0edh6.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-etm0700g0edh6.dtsi
new file mode 100644
index 0000000000000..e3a521343cdfd
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-etm0700g0edh6.dtsi
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2022-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/imx8mp-clock.h>
+#include "imx8mp-dhcom-overlay-panel-dpi.dtsi"
+
+&{/} {
+ led {
+ led-0 {
+ /* LED5 GPIO conflicts with Touchscreen IRQ GPIO-E */
+ status = "disabled";
+ };
+ };
+};
+
+&i2c_dhpdk_panel {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dhcom_e>;
+ /* Touchscreen IRQ GPIO-E conflicts with LED5 GPIO */
+ interrupt-parent = <&gpio5>;
+ interrupts = <22 IRQ_TYPE_EDGE_FALLING>; /* GPIO E */
+ };
+};
+
+&display_bl {
+ pwms = <&pwm1 0 5000000 PWM_POLARITY_INVERTED>;
+};
+
+&mipi_dsi {
+ /*
+ * This is DSIM PLL frequency, DSI HS clock lane frequency
+ * is half of the "samsung,burst-clock-frequency" value.
+ */
+ samsung,burst-clock-frequency = <500000000>;
+};
+
+&panel {
+ compatible = "edt,etm0700g0edh6";
+};
+
+&pwm1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-lvds.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-lvds.dtsi
new file mode 100644
index 0000000000000..c6e60a99488a5
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-lvds.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+
+#include "imx8mp-dhcom-overlay-panel-common.dtsi"
+
+&ldb_lvds_ch0 {
+ remote-endpoint = <&panel_in>;
+};
+
+&lcdif2 {
+ status = "okay";
+};
+
+&lvds_bridge {
+ status = "okay";
+};
+
+&panel_in {
+ remote-endpoint = <&ldb_lvds_ch0>;
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk-overlay-eth2xfast.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk-overlay-eth2xfast.dtso
new file mode 100644
index 0000000000000..0da2b11720db3
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk-overlay-eth2xfast.dtso
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+ðphypdk { /* Micrel KSZ9131RNXI */
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtso
new file mode 100644
index 0000000000000..92f92e6700ed6
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-505-200-x12-ch101olhlwh.dtso
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2022-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include "imx8mp-dhcom-overlay-panel-lvds.dtsi"
+#include "imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi"
+
+&{/} {
+ gpio-keys {
+ button-1 {
+ /* BUTTON1 GPIO conflicts with Touchscreen RESET GPIO-B */
+ status = "disabled";
+ };
+ };
+
+ led {
+ led-2 {
+ /* LED7 GPIO conflicts with Touchscreen IRQ GPIO-H */
+ status = "disabled";
+ };
+ };
+};
+
+&media_blk_ctrl {
+ /*
+ * The Chefree CH101OLHLWH-002 panel requires 71.1 MHz LVDS clock.
+ * Set IMX8MP_VIDEO_PLL1 to 497.7 MHz , since 497.7 MHz / 7 = 71.1 MHz .
+ */
+ assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <0>, <497700000>;
+};
+
+&touch_lvds {
+ pinctrl-0 = <&pinctrl_dhcom_b &pinctrl_dhcom_h>;
+ pinctrl-names = "default";
+ interrupt-parent = <&gpio1>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-531-100-x21.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-531-100-x21.dtso
new file mode 100644
index 0000000000000..64c730d11e6a8
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-531-100-x21.dtso
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2022-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+&ecspi1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ eeprom@0 {
+ compatible = "microchip,25aa010a", "atmel,at25";
+ reg = <0>;
+ address-width = <8>;
+ pagesize = <16>;
+ size = <128>;
+ spi-max-frequency = <5000000>;
+ };
+};
+
+&i2c5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@56 {
+ compatible = "atmel,24c04";
+ reg = <0x56>;
+ pagesize = <16>;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-531-100-x22.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-531-100-x22.dtso
new file mode 100644
index 0000000000000..d789bf07cbb84
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-531-100-x22.dtso
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2022-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+&ecspi2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ eeprom@0 {
+ compatible = "microchip,25aa010a", "atmel,at25";
+ reg = <0>;
+ address-width = <8>;
+ pagesize = <16>;
+ size = <128>;
+ spi-max-frequency = <5000000>;
+ };
+};
+
+&i2c4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@56 {
+ compatible = "atmel,24c04";
+ reg = <0x56>;
+ pagesize = <16>;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-560-300-x12.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-560-300-x12.dtso
new file mode 100644
index 0000000000000..8ca2bd564db26
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2-overlay-560-300-x12.dtso
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2022-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include "imx8mp-dhcom-overlay-panel-etm0700g0edh6.dtsi"
+#include "imx8mp-pinfunc.h"
+
+&{/} {
+ led {
+ led-0 {
+ /* LED5 GPIO conflicts with Touchscreen IRQ GPIO-E */
+ status = "disabled";
+ };
+ };
+};
+
+&pinctrl_dhcom_e {
+ fsl,pins = <
+ /* GPIO_E */
+ MX8MP_IOMUXC_UART1_RXD__GPIO5_IO22 0x40000000
+ >;
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2.dts b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2.dts
index 3d18c964a22cd..12fcc8f59aba0 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2.dts
@@ -152,7 +152,7 @@ codec_dai: simple-audio-card,codec {
};
};
-&i2c5 {
+i2c_dhpdk_panel: &i2c5 {
sgtl5000: codec@a {
compatible = "fsl,sgtl5000";
reg = <0x0a>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-505-200-x36-ch101olhlwh.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-505-200-x36-ch101olhlwh.dtso
new file mode 100644
index 0000000000000..397fa17a9ca22
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-505-200-x36-ch101olhlwh.dtso
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2022-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include "imx8mp-dhcom-overlay-panel-lvds.dtsi"
+#include "imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi"
+#include "imx8mp-pinfunc.h"
+
+&{/} {
+ gpio-keys {
+ button-1 {
+ /* TA2 GPIO conflicts with Touchscreen RESET GPIO-B */
+ status = "disabled";
+ };
+
+ button-2 {
+ /* TA3 GPIO conflicts with Touchscreen IRQ GPIO-C */
+ status = "disabled";
+ };
+ };
+
+ led {
+ led-2 {
+ /* LED2 GPIO conflicts with BL-ON1 GPIO-G */
+ status = "disabled";
+ };
+ };
+};
+
+&media_blk_ctrl {
+ /*
+ * The Chefree CH101OLHLWH-002 panel requires 71.1 MHz LVDS clock.
+ * Set IMX8MP_VIDEO_PLL1 to 497.7 MHz , since 497.7 MHz / 7 = 71.1 MHz .
+ */
+ assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <0>, <497700000>;
+};
+
+&pinctrl_dhcom_c {
+ fsl,pins = <
+ /* GPIO_C */
+ MX8MP_IOMUXC_SAI3_MCLK__GPIO5_IO02 0x40000000
+ >;
+};
+
+&touch_lvds {
+ pinctrl-0 = <&pinctrl_dhcom_b &pinctrl_dhcom_c>;
+ pinctrl-names = "default";
+ interrupt-parent = <&gpio5>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-531-100-x40.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-531-100-x40.dtso
new file mode 100644
index 0000000000000..a319f0d881a52
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-531-100-x40.dtso
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+&ecspi1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ eeprom@0 {
+ compatible = "microchip,25aa010a", "atmel,at25";
+ reg = <0>;
+ address-width = <8>;
+ pagesize = <16>;
+ size = <128>;
+ spi-max-frequency = <5000000>;
+ };
+};
+
+&i2cmuxed0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@56 {
+ compatible = "atmel,24c04";
+ reg = <0x56>;
+ pagesize = <16>;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-531-100-x41.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-531-100-x41.dtso
new file mode 100644
index 0000000000000..aaddcc88087ae
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-531-100-x41.dtso
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+&ecspi2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ eeprom@0 {
+ compatible = "microchip,25aa010a", "atmel,at25";
+ reg = <0>;
+ address-width = <8>;
+ pagesize = <16>;
+ size = <128>;
+ spi-max-frequency = <5000000>;
+ };
+};
+
+&i2c4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@56 {
+ compatible = "atmel,24c04";
+ reg = <0x56>;
+ pagesize = <16>;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-560-300-x36.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-560-300-x36.dtso
new file mode 100644
index 0000000000000..8e9fba9297401
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-560-300-x36.dtso
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include "imx8mp-dhcom-overlay-panel-etm0700g0edh6.dtsi"
+
+&{/} {
+ gpio-keys {
+ button-3 {
+ /* TA4 GPIO conflicts with Touchscreen IRQ GPIO-E */
+ status = "disabled";
+ };
+ };
+
+ led {
+ led-2 {
+ /* LED2 GPIO conflicts with BL-ON1 GPIO-G */
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-732-100-x36.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-732-100-x36.dtso
new file mode 100644
index 0000000000000..a527b7abf9a28
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-732-100-x36.dtso
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2024-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include "imx8mp-dhcom-overlay-panel-clock.dtsi"
+
+&lcdif1 {
+ status = "okay";
+};
+
+&mipi_dsi {
+ samsung,burst-clock-frequency = <1000000000>;
+ status = "okay";
+};
+
+&tc_bridge {
+ assigned-clock-rates = <26000000>, <26000000>, <416000000>;
+ toshiba,hpd-pin = <0>;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@2 {
+ reg = <2>;
+
+ endpoint {
+ toshiba,pre-emphasis = /bits/ 8 <1 1>;
+ };
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-ea-murata-2ae-x20.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-ea-murata-2ae-x20.dtso
new file mode 100644
index 0000000000000..92ed69baea452
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-ea-murata-2ae-x20.dtso
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/imx8mp-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+
+/* This DTO requires HI00106 SoM variant. */
+
+&{/} {
+ led {
+ led-0 {
+ /* LED0 GPIO conflicts with #SDIO_RST GPIO-D */
+ status = "disabled";
+ };
+ };
+};
+
+&uart3 {
+ assigned-clocks = <&clk IMX8MP_CLK_UART3>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+ assigned-clock-rates = <80000000>;
+
+ bluetooth {
+ compatible = "cypress,cyw4373a0-bt";
+ max-speed = <4000000>;
+ };
+};
+
+/* SD slot */
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ broken-cd;
+ cap-power-off-card;
+ keep-power-in-suspend;
+ non-removable;
+ vmmc-supply = <&buck4>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wifi@1 { /* muRata 2AE */
+ compatible = "cypress,cyw4373-fmac", "brcm,bcm4329-fmac";
+ reg = <1>;
+ /*
+ * The "host-wake" interrupt output is by default not
+ * connected to the SoC, but can be connected on to
+ * SoC pin on the carrier board.
+ */
+ reset-gpios = <&gpio4 27 GPIO_ACTIVE_LOW>; /* GPIO D */
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x29.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x29.dtso
new file mode 100644
index 0000000000000..8ff313ede7c75
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x29.dtso
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include "imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640.dtsi"
+
+&mipi_csi_1 {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ mipi_csi0_ep: endpoint {
+ remote-endpoint = <&ov5640_to_mipi_csi2>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&ov5640 {
+ powerdown-gpios = <&csi2exp 1 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&csi2exp 0 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x31.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x31.dtso
new file mode 100644
index 0000000000000..52cdafa5dd2d9
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640-x31.dtso
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include "imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640.dtsi"
+
+&mipi_csi_0 {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ mipi_csi0_ep: endpoint {
+ remote-endpoint = <&ov5640_to_mipi_csi2>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&ov5640 {
+ powerdown-gpios = <&csi2exp 2 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&csi2exp 3 GPIO_ACTIVE_LOW>;
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640.dtsi
new file mode 100644
index 0000000000000..4e56547e229ee
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3-overlay-nxp-spf-29853-c1-ov5640.dtsi
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+
+#include <dt-bindings/clock/imx8mp-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+ camera0_1v5_pwr: regulator-camera0-1v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "camera0-1v5-reg";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ };
+
+ camera0_1v8_pwr: regulator-camera0-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "camera0-1v8-reg";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ camera0_2v8_pwr: regulator-camera0-2v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "camera0-2v8-reg";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ };
+};
+
+&i2cmuxed0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov5640: camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ clocks = <&clk IMX8MP_CLK_CLKOUT1>;
+ clock-names = "xclk";
+ assigned-clocks = <&clk IMX8MP_CLK_CLKOUT1_SEL>,
+ <&clk IMX8MP_CLK_CLKOUT1>;
+ assigned-clock-parents = <&clk IMX8MP_CLK_24M>;
+ assigned-clock-rates = <24000000>, <24000000>;
+ AVDD-supply = <&camera0_2v8_pwr>;
+ DOVDD-supply = <&camera0_1v8_pwr>;
+ DVDD-supply = <&camera0_1v5_pwr>;
+
+ port {
+ ov5640_to_mipi_csi2: endpoint {
+ remote-endpoint = <&mipi_csi0_ep>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&isi_0 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts
index 6ad824a7e07e0..a6a8262dc6be3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts
@@ -165,7 +165,7 @@ i2c-mux@70 {
#address-cells = <1>;
#size-cells = <0>;
- i2cmuxed0: i2c@0 {
+ i2c_dhpdk_panel: i2cmuxed0: i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-picoitx-overlay-626-100-x2-ch101olhlwh.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-picoitx-overlay-626-100-x2-ch101olhlwh.dtso
new file mode 100644
index 0000000000000..34b060cdeae1e
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-picoitx-overlay-626-100-x2-ch101olhlwh.dtso
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2024-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include "imx8mp-dhcom-overlay-panel-dpi.dtsi"
+#include "imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi"
+#include "imx8mp-pinfunc.h"
+
+&{/} {
+ lvds-encoder {
+ compatible = "onnn,fin3385", "lvds-encoder";
+ pclk-sample = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_bridge_in: endpoint {
+ remote-endpoint = <&tc_bridge_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lvds_bridge_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
+};
+
+&mipi_dsi {
+ /*
+ * This is DSIM PLL frequency, DSI HS clock lane frequency
+ * is half of the "samsung,burst-clock-frequency" value.
+ */
+ samsung,burst-clock-frequency = <900000000>;
+};
+
+&panel_in {
+ remote-endpoint = <&lvds_bridge_out>;
+};
+
+&tc_bridge_out {
+ remote-endpoint = <&lvds_bridge_in>;
+};
+
+&touch_lvds {
+ pinctrl-0 = <&pinctrl_dhcom_b &pinctrl_dhcom_h>;
+ pinctrl-names = "default";
+ interrupt-parent = <&gpio1>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+};
+
+&iomuxc {
+ /*
+ * The following DHCOM GPIOs are used on this board.
+ * Therefore, they have been removed from the list below.
+ * B: Touch controller #RESET
+ * H: Touch controller IRQ
+ * I: Yellow led
+ */
+ pinctrl-0 = <&pinctrl_dhcom_a &pinctrl_dhcom_c &pinctrl_dhcom_d
+ &pinctrl_dhcom_e &pinctrl_dhcom_f &pinctrl_dhcom_g
+ &pinctrl_dhcom_j &pinctrl_dhcom_k &pinctrl_dhcom_l
+ &pinctrl_dhcom_m &pinctrl_dhcom_n &pinctrl_dhcom_o
+ &pinctrl_dhcom_p &pinctrl_dhcom_q &pinctrl_dhcom_r
+ &pinctrl_dhcom_s &pinctrl_dhcom_int>;
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-picoitx.dts b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-picoitx.dts
index 703cf0fb3d2be..ac179765d5628 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-picoitx.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-picoitx.dts
@@ -114,6 +114,9 @@ &hdmi_tx_phy {
status = "disabled";
};
+i2c_dhpdk_panel: &i2c5 {
+};
+
&irqsteer_hdmi {
status = "disabled";
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som-overlay-eth1xfast.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som-overlay-eth1xfast.dtso
new file mode 100644
index 0000000000000..49cbf3e44601e
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som-overlay-eth1xfast.dtso
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/imx8mp-clock.h>
+
+&eqos { /* First ethernet */
+ pinctrl-0 = <&pinctrl_eqos_rmii>;
+ phy-handle = <ðphy0f>;
+ phy-mode = "rmii";
+
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_266M>,
+ <&clk IMX8MP_SYS_PLL2_100M>,
+ <&clk IMX8MP_SYS_PLL2_50M>;
+ assigned-clock-rates = <0>, <100000000>, <50000000>;
+};
+
+ðphy0g { /* Micrel KSZ9131RNXI */
+ status = "disabled";
+};
+
+ðphy0f { /* SMSC LAN8740Ai */
+ status = "okay";
+};
+
+&fec { /* Second ethernet -- HS connector not populated on 1x RMII PHY SoM */
+ status = "disabled";
+};
+
+/* No HS connector on this SoM variant, so no HDMI, PCIe and only USB HS. */
+
+&hdmi_blk_ctrl {
+ status = "disabled";
+};
+
+&hdmi_pvi {
+ status = "disabled";
+};
+
+&hdmi_tx {
+ status = "disabled";
+};
+
+&hdmi_tx_phy {
+ status = "disabled";
+};
+
+&irqsteer_hdmi {
+ status = "disabled";
+};
+
+&lcdif3 {
+ status = "disabled";
+};
+
+&pcie_phy {
+ status = "disabled";
+};
+
+&pcie {
+ status = "disabled";
+};
+
+/* No WiFi/BT chipset on this SoM variant. */
+&uart2 {
+ bluetooth {
+ status = "disabled";
+ };
+};
+
+&usb_dwc3_0 {
+ maximum-speed = "high-speed";
+};
+
+&usb_dwc3_1 {
+ maximum-speed = "high-speed";
+};
+
+/* No WiFi/BT chipset on this SoM variant. */
+&usdhc1 {
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som-overlay-eth2xfast.dtso b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som-overlay-eth2xfast.dtso
new file mode 100644
index 0000000000000..e773a754477cc
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som-overlay-eth2xfast.dtso
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2023-2026 Marek Vasut
+ */
+#include "imx8mp-dhcom-som-overlay-eth1xfast.dtso"
+
+/* Dual RMII 100/Full Fast ethernet on this SoM variant. */
+
+ðphy1f { /* SMSC LAN8740Ai */
+ status = "okay";
+};
+
+&fec { /* Second ethernet */
+ pinctrl-0 = <&pinctrl_fec_rmii>;
+ phy-handle = <ðphy1f>;
+ phy-mode = "rmii";
+ status = "okay";
+
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_266M>,
+ <&clk IMX8MP_SYS_PLL2_100M>,
+ <&clk IMX8MP_SYS_PLL2_50M>,
+ <&clk IMX8MP_SYS_PLL2_50M>;
+ assigned-clock-rates = <0>, <100000000>, <50000000>, <0>;
+};
+
+/* Resistive touch controller not populated on this one SoM variant. */
+&touch_som {
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
index f8303b7e2bd22..9d735a4a36d32 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-som.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2021-2022 Marek Vasut <marex@denx.de>
+ * Copyright (C) 2021-2026 Marek Vasut
*/
#include "imx8mp.dtsi"
@@ -398,7 +398,7 @@ channel@7 { /* Voltage over AIN3 and GND. */
};
};
- touchscreen@49 {
+ touch_som: touchscreen@49 {
compatible = "ti,tsc2004";
reg = <0x49>;
interrupts-extended = <&gpio4 0 IRQ_TYPE_EDGE_FALLING>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: imx8mp: Add DT overlays for DH i.MX8M Plus DHCOM SoM and boards
From: Marek Vasut @ 2026-03-26 4:28 UTC (permalink / raw)
To: Frank Li
Cc: linux-arm-kernel, Christoph Niedermaier, Conor Dooley,
Fabio Estevam, Krzysztof Kozlowski, Pengutronix Kernel Team,
Rob Herring, Sascha Hauer, devicetree, imx, kernel, linux-kernel
In-Reply-To: <acQqc1AuCa1Tkb-w@lizhi-Precision-Tower-5810>
On 3/25/26 7:33 PM, Frank Li wrote:
Hello Frank,
>> +#define DH_OVERLAY_PANEL_I2C_BUS i2c5
>> +#define DH_OVERLAY_PANEL_I2C_TOUCHSCREEN_PINCTRL &pinctrl_dhcom_b &pinctrl_dhcom_h
>
> This is not straight forward.
>
> you can add label like panel_i2c at dts file.
>
> panel_i2c: &i2c5 {
> }
>
> in overlay file use
>
> &panel_i2c {
> ....
> }
>
> So you use the same overlay file for difference dts. The same as others
I did that in V3, thanks.
^ permalink raw reply
* [PATCH 3/4] arm64: dts: renesas: rzg2l-smarc: Fix missing cells and reg into CSI2 subnode
From: Marek Vasut @ 2026-03-26 4:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-1-marek.vasut+renesas@mailbox.org>
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>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi b/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
index 4d2b0655859ab..3feffa4f16a9a 100644
--- a/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
+++ b/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
@@ -46,7 +46,12 @@ &csi2 {
status = "okay";
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
port@0 {
+ reg = <0>;
+
csi2_in: endpoint {
clock-lanes = <0>;
data-lanes = <1 2>;
--
2.53.0
^ permalink raw reply related
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