* [PATCH v2 1/2] dt-bindings: trivial: Add q50sn12072 and q54sn120a1 support
From: Brian Chiang @ 2026-03-26 13:48 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Guenter Roeck
Cc: devicetree, linux-kernel, linux-hwmon, Jack Cheng, Brian Chiang,
Jack Cheng
In-Reply-To: <20260326-add-support-for-q50sn12072-and-q54sn120a1-v2-0-77bc77eedc76@inventec.com>
From: Jack Cheng <cheng.jackhy@inventec.com>
Add support for the Delta Electronics q50sn12072 and q54sn120a1
1/4 Brick DC/DC Regulated Power Modules.
Signed-off-by: Jack Cheng <cheng.jackhy@inventec.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
Documentation/devicetree/bindings/trivial-devices.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index a482aeadcd44..d4b78154df82 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -96,7 +96,11 @@ properties:
# Delta Electronics DPS920AB 920W 54V Power Supply
- delta,dps920ab
# 1/4 Brick DC/DC Regulated Power Module
+ - delta,q50sn12072
+ # 1/4 Brick DC/DC Regulated Power Module
- delta,q54sj108a2
+ # 1/4 Brick DC/DC Regulated Power Module
+ - delta,q54sn120a1
# Devantech SRF02 ultrasonic ranger in I2C mode
- devantech,srf02
# Devantech SRF08 ultrasonic ranger
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] Add support for q50sn12072 and q54sn120a1
From: Brian Chiang @ 2026-03-26 13:48 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Guenter Roeck
Cc: devicetree, linux-kernel, linux-hwmon, Jack Cheng, Brian Chiang,
Jack Cheng
The Q54SN12072 and Q54SN120A1 are high-efficiency, high-density DC-DC power
module from Delta Power Modules.
The Q54SN12072, quarter brick, single output 12V. This product provides up
to 1200 watts of output power at 38~60V. The Q54SN12072 offers peak
efficiency up to 98.3%@54Vin.
The Q54SN120A1, quarter brick, single output 12V. This product provides up
to 1300 watts of output power at 40~60V. The Q54SN120A1 offers peak
efficiency up to 98.1%@54Vin.
Add support for them to q54sj108a2 driver.
Signed-off-by: Jack Cheng <Cheng.JackHY@inventec.com>
Co-developed-by: Brian Chiang <chiang.brian@inventec.com>
Signed-off-by: Brian Chiang <chiang.brian@inventec.com>
Changes in v2:
- Drop Q50SN12072_DEBUGFS_VOUT_COMMAND debugfs entry
- Add .format[PSC_VOLTAGE_OUT] = linear explicitly to all three chip
entries for consistency
- Replace hardcoded MFR_MODEL check (ret != 14 || strncmp("Q54SJ108A2"))
with a loop over q54sj108a2_id[] using strncasecmp to support all
three chip variants dynamically
- Remove of_device_get_match_data()/i2c_match_id() early chip_id path;
derive chip_id exclusively from MFR_MODEL hardware read
- Remove unused .data fields from of_device_id entries
- Guard store_default, blackbox_erase, blackbox_set_offset, blackbox_read,
and flash_key debugfs entries under psu->chip == q54sj108a2 check
- Add dev_notice() when configured device name differs from detected model
- Update MODULE_DESCRIPTION to "PMBus driver for Delta Q54SJ108A2 and
compatibles"
- Fix commit message typo: "Q54SN12072" -> "Q50SN12072"
- Link to v1: https://lore.kernel.org/r/20250701-add-support-for-q50sn12072-and-q54sn120a1-v1-0-c387baf928cb@inventec.com
---
Jack Cheng (2):
dt-bindings: trivial: Add q50sn12072 and q54sn120a1 support
hwmon: (pmbus/q54sj108a2) Add support for q50sn12072 and q54sn120a1
.../devicetree/bindings/trivial-devices.yaml | 4 +
drivers/hwmon/pmbus/q54sj108a2.c | 97 +++++++++++++++-------
2 files changed, 72 insertions(+), 29 deletions(-)
---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20250701-add-support-for-q50sn12072-and-q54sn120a1-a9c299e6d81d
Best regards,
--
Brian Chiang <chiang.brian@inventec.com>
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Add clock guard DT description
From: Vyacheslav Yurkov @ 2026-03-26 13:39 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley
Cc: Rob Herring, Vyacheslav Yurkov, Michael Turquette, Stephen Boyd,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-clk,
devicetree
In-Reply-To: <8e7d0c53-aa23-4514-81a5-335a76bb0c45@kernel.org>
On 26.03.2026 11:08, Krzysztof Kozlowski wrote:
>>
>> DTS example:
>> clock_guard: clock_controller_guard {
>> compatible = "clock-controller-guard";
>> #clock-cells = <1>;
>> clocks = <&h2f_clk 0>, <&clk_fgpa_rx 0>, <clk_fpga_tx 0>;
>> clock-names = "h2f_clk0", "clk_fpga_rx", "clk_fpga_tx";
>> gpios = <&fpga_ip 0 GPIO_ACTIVE_HIGH>, <&fpga_ip 1 GPIO_ACTIVE_HIGH>;
>> gpio-names = "gpio-input0", "gpio-input1";
>> clock-output-names = "clkctrl-guard";
>> };
>>
>> custom_device {
>> compatible = "...";
>> ...
>> #clock-cells = <1>;
>> clocks = <&clock_guard 0>;
>> clock-names = "clock-guard";
>> };
>
> So a pure SW construct? Device has specific clock inputs but you do not
> model them and instead replace with one fake-guard-input.
>
> I don't see how this represents the hardware at all.
>
> Maybe some diagrams would help, assuming we still talk about hardware.
>
> Best regards,
> Krzysztof
Techincally that's correct, it's a software construct. If this is not a
right place to submit such a helper driver, I'd appreciate a hint what
subsystem is the right one.
I was not sure how to provide a diagram in the mailing list, so I posted
in on Github https://github.com/OSS-Keepers/clock-controller-guard/issues/1
It is a driver which models dependencies for other drivers. These are
soft or "indirect" dependencies, because we cannot access the FPGA
unless the FPGA_PLL_locked, and GPIO is telling us we are good to go.
Conor, I think this should answer your question as well.
Thanks,
Slava
^ permalink raw reply
* Re: (subset) [PATCH 1/2] dt-bindings: connector: add pd-disable dependency
From: Frank Li @ 2026-03-26 13:36 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, amitsd,
gregkh, kyletso, Xu Yang
Cc: devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260312071609.388047-1-xu.yang_2@nxp.com>
On Thu, 12 Mar 2026 15:16:08 +0800, Xu Yang wrote:
> When Power Delivery is not supported, the source is unable to obtain the
> current capability from the Source PDO. As a result, typec-power-opmode
> needs to be added to advertise such capability.
>
>
Applied, thanks!
[2/2] arm64: dts: freescale: imx8mp-moduline-display-106: add typec-power-opmode property
commit: 057756df6770c033eb8ebbc9b0066f6602e99b08
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v3 8/9] media: i2c: ov08d10: add support for reset and power management
From: Sakari Ailus @ 2026-03-26 13:26 UTC (permalink / raw)
To: Matthias Fend
Cc: Jimmy Su, Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, linux-media, linux-kernel,
devicetree, bsp-development.geo
In-Reply-To: <20260324-ov08d10-v3-8-1e44069cf91e@emfend.at>
Hi Matthias,
A few more minor comments.
On Tue, Mar 24, 2026 at 11:41:42AM +0100, Matthias Fend wrote:
> Add support for the required power supplies as well as the control of an
> optional sensor reset.
>
> Signed-off-by: Matthias Fend <matthias.fend@emfend.at>
> ---
> drivers/media/i2c/ov08d10.c | 93 ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 92 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/ov08d10.c b/drivers/media/i2c/ov08d10.c
> index ce0fa30a86129302b5dda0b8796e44054fd77c88..19035991e8bb164d4fca5d87ee4551191974e8bb 100644
> --- a/drivers/media/i2c/ov08d10.c
> +++ b/drivers/media/i2c/ov08d10.c
> @@ -8,6 +8,7 @@
> #include <linux/module.h>
> #include <linux/pm_runtime.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
> #include <media/v4l2-ctrls.h>
> #include <media/v4l2-device.h>
> #include <media/v4l2-fwnode.h>
> @@ -513,9 +514,17 @@ static const char * const ov08d10_test_pattern_menu[] = {
> "Standard Color Bar",
> };
>
> +static const char *const ov08d10_supply_names[] = {
> + "dovdd", /* Digital I/O power */
> + "avdd", /* Analog power */
> + "dvdd", /* Digital core power */
> +};
> +
> struct ov08d10 {
> struct device *dev;
> struct clk *clk;
> + struct reset_control *reset;
> + struct regulator_bulk_data supplies[ARRAY_SIZE(ov08d10_supply_names)];
>
> struct v4l2_subdev sd;
> struct media_pad pad;
> @@ -1265,6 +1274,56 @@ static const struct v4l2_subdev_internal_ops ov08d10_internal_ops = {
> .open = ov08d10_open,
> };
>
> +static int ov08d10_power_off(struct device *dev)
> +{
> + struct v4l2_subdev *sd = dev_get_drvdata(dev);
> + struct ov08d10 *ov08d10 = to_ov08d10(sd);
> +
> + reset_control_assert(ov08d10->reset);
> +
> + regulator_bulk_disable(ARRAY_SIZE(ov08d10->supplies),
> + ov08d10->supplies);
> +
> + clk_disable_unprepare(ov08d10->clk);
> +
> + return 0;
> +}
> +
> +static int ov08d10_power_on(struct device *dev)
> +{
> + struct v4l2_subdev *sd = dev_get_drvdata(dev);
> + struct ov08d10 *ov08d10 = to_ov08d10(sd);
> + int ret;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(ov08d10->supplies),
> + ov08d10->supplies);
> + if (ret < 0) {
> + dev_err(dev, "failed to enable regulators: %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(ov08d10->clk);
> + if (ret < 0) {
> + regulator_bulk_disable(ARRAY_SIZE(ov08d10->supplies),
> + ov08d10->supplies);
> +
> + dev_err(dev, "failed to enable imaging clock: %d\n", ret);
> + return ret;
> + }
> +
> + if (ov08d10->reset) {
> + /* Delay from DVDD stable to sensor XSHUTDN pull up: 5ms */
> + fsleep(5 * USEC_PER_MSEC);
> +
> + reset_control_deassert(ov08d10->reset);
> +
> + /* Delay from XSHUTDN pull up to SCCB start: 8ms */
> + fsleep(8 * USEC_PER_MSEC);
Don't you need the fsleep()'s (or at least the latter one) even if you have
no reset GPIO?
> + }
> +
> + return 0;
> +}
> +
> static int ov08d10_identify_module(struct ov08d10 *ov08d10)
> {
> struct i2c_client *client = v4l2_get_subdevdata(&ov08d10->sd);
> @@ -1371,6 +1430,10 @@ static void ov08d10_remove(struct i2c_client *client)
> media_entity_cleanup(&sd->entity);
> v4l2_ctrl_handler_free(sd->ctrl_handler);
> pm_runtime_disable(ov08d10->dev);
> + if (!pm_runtime_status_suspended(ov08d10->dev)) {
> + ov08d10_power_off(ov08d10->dev);
> + pm_runtime_set_suspended(ov08d10->dev);
> + }
> mutex_destroy(&ov08d10->mutex);
> }
>
> @@ -1378,6 +1441,7 @@ static int ov08d10_probe(struct i2c_client *client)
> {
> struct ov08d10 *ov08d10;
> unsigned long freq;
> + unsigned int i;
> int ret;
>
> ov08d10 = devm_kzalloc(&client->dev, sizeof(*ov08d10), GFP_KERNEL);
> @@ -1403,12 +1467,32 @@ static int ov08d10_probe(struct i2c_client *client)
> return ret;
> }
>
> + ov08d10->reset = devm_reset_control_get_optional_exclusive(ov08d10->dev, NULL);
This is a bit long.
I'll take the set now but please post a fix on top.
> + if (IS_ERR(ov08d10->reset))
> + return dev_err_probe(ov08d10->dev, PTR_ERR(ov08d10->reset),
> + "failed to get reset\n");
> + reset_control_assert(ov08d10->reset);
> +
> + for (i = 0; i < ARRAY_SIZE(ov08d10_supply_names); i++)
> + ov08d10->supplies[i].supply = ov08d10_supply_names[i];
> +
> + ret = devm_regulator_bulk_get(ov08d10->dev,
> + ARRAY_SIZE(ov08d10->supplies),
> + ov08d10->supplies);
> + if (ret)
> + return dev_err_probe(ov08d10->dev, ret,
> + "failed to get regulators\n");
> +
> v4l2_i2c_subdev_init(&ov08d10->sd, client, &ov08d10_subdev_ops);
>
> + ret = ov08d10_power_on(ov08d10->dev);
> + if (ret)
> + return dev_err_probe(ov08d10->dev, ret, "failed to power on\n");
> +
> ret = ov08d10_identify_module(ov08d10);
> if (ret) {
> dev_err(ov08d10->dev, "failed to find sensor: %d\n", ret);
> - return ret;
> + goto probe_error_power_off;
> }
>
> mutex_init(&ov08d10->mutex);
> @@ -1452,9 +1536,15 @@ static int ov08d10_probe(struct i2c_client *client)
> v4l2_ctrl_handler_free(ov08d10->sd.ctrl_handler);
> mutex_destroy(&ov08d10->mutex);
>
> +probe_error_power_off:
> + ov08d10_power_off(ov08d10->dev);
> +
> return ret;
> }
>
> +static DEFINE_RUNTIME_DEV_PM_OPS(ov08d10_pm_ops,
> + ov08d10_power_off, ov08d10_power_on, NULL);
> +
> #ifdef CONFIG_ACPI
> static const struct acpi_device_id ov08d10_acpi_ids[] = {
> { "OVTI08D1" },
> @@ -1473,6 +1563,7 @@ MODULE_DEVICE_TABLE(of, ov08d10_of_match);
> static struct i2c_driver ov08d10_i2c_driver = {
> .driver = {
> .name = "ov08d10",
> + .pm = pm_ptr(&ov08d10_pm_ops),
> .acpi_match_table = ACPI_PTR(ov08d10_acpi_ids),
> .of_match_table = ov08d10_of_match,
> },
>
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH] arm64: dts: monaco: extend fastrpc compute cb
From: Bjorn Andersson @ 2026-03-26 13:24 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: konradybcio, robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260326125834.2758331-1-srinivas.kandagatla@oss.qualcomm.com>
On Thu, Mar 26, 2026 at 12:58:34PM +0000, Srinivas Kandagatla wrote:
> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
[..]
> +
> + compute-cb@b {
That doesn't match the patternProperties "(compute-)?cb@[0-9]*$".
Is the reg an index, or an "address"? Should we use base 10, or should
we fix the yaml?
Regards,
Bjorn
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <0xb>;
> + iommus = <&apps_smmu 0x19cb 0x0400>;
> + dma-coherent;
> + };
> +
> + compute-cb@c {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <0xc>;
> + iommus = <&apps_smmu 0x19cc 0x000>;
> + dma-coherent;
> + };
> };
> };
> };
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH V2 4/5] dt-bindings: dma: xlnx,axi-dma: Add "xlnx,include-stscntrl-strm" property
From: Rob Herring (Arm) @ 2026-03-26 13:22 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Radhey Shyam Pandey, Michal Simek, Frank Li, devicetree, git,
Conor Dooley, Vinod Koul, Tomi Valkeinen, Suraj Gupta,
Abin Joseph, Thomas Gessler, Folker Schwesinger, linux-kernel,
Krzysztof Kozlowski, linux-arm-kernel, dmaengine, Kees Cook
In-Reply-To: <20260313062533.421249-5-srinivas.neeli@amd.com>
On Fri, 13 Mar 2026 11:55:32 +0530, Srinivas Neeli wrote:
> Add an optional boolean DT property "xlnx,include-stscntrl-strm" to
> indicate that the AXI DMA IP is configured with the AXI4-Stream status
> and control interface. This enables the use of APP fields in DMA
> descriptors for metadata reporting.
>
> This property is distinct from "xlnx,axistream-connected" and serves a
> different purpose:
>
> - "xlnx,include-stscntrl-strm": Indicates whether APP fields are present
> in DMA descriptors. When enabled, the driver can access status/control
> metadata through these descriptor fields.
>
> - "xlnx,axistream-connected": Indicates whether a streaming IP (client)
> is connected to the DMA IP.
>
> These two configurations are independent of each other. For example, in
> TSN (Time-Sensitive Networking) designs, a streaming client may be
> connected to the DMA IP, but the status/control stream interface is not
> enabled. In such cases, "xlnx,axistream-connected" would be present while
> "xlnx,include-stscntrl-strm" would be absent.
>
> Adding this property allows the driver to correctly determine descriptor
> layout and access APP fields only when the hardware supports them.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
> .../devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v5 0/9] arm64: dts: amlogic: Add MMC/SD/SDIO support for Khadas VIM4 (Amlogic T7)
From: Neil Armstrong @ 2026-03-26 13:10 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley, Xianwei Zhao, Nick Xie
In-Reply-To: <177453048347.439230.1647215482099213609.b4-ty@linaro.org>
On 3/26/26 14:08, Neil Armstrong wrote:
> Hi,
>
> On Thu, 26 Mar 2026 10:59:11 +0100, Ronald Claveau wrote:
>> This patch series depends on Jian's SCMI clock patches yet to merge
>> https://lore.kernel.org/all/20260313070022.700437-1-jian.hu@amlogic.com/
>>
>> This series adds device tree support for the MMC, SD card and SDIO
>> interfaces on the Amlogic T7 SoC and the Khadas VIM4 board.
>>
>> The first patches add the necessary building blocks in the T7 SoC
>> DTSI: pinctrl nodes for pin muxing, PWM controller nodes, and MMC
>> controller nodes. The amlogic,t7-mmc and amlogic,t7-pwm compatible
>> strings are introduced with fallbacks to existing drivers, avoiding
>> the need for new driver code.
>>
>> [...]
>
> Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
>
> [1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
> https://git.kernel.org/amlogic/c/fb69fa2cabc68da247bcc0bc99a14dc857b16842
> [4/9] arm64: dts: amlogic: t7: Add PWM pinctrl nodes
> https://git.kernel.org/amlogic/c/b1e49f6c1ac15b2c947bdb1d22a82b823de22d27
> [6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
> https://git.kernel.org/amlogic/c/60eff75ac67bbf5445bdbd2842b0109ac591441c
I'll pick patch 3,5,7 & 9 once patches 1 & 2 from [1] are merged.
[1] https://lore.kernel.org/all/20260326092645.1053261-1-jian.hu@amlogic.com/
Thanks,
Neil
>
> These changes has been applied on the intermediate git tree [1].
>
> The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
> for inclusion in their intermediate git branches in order to be sent to Linus during
> the next merge window, or sooner if it's a set of fixes.
>
> In the cases of fixes, those will be merged in the current release candidate
> kernel and as soon they appear on the Linux master branch they will be
> backported to the previous Stable and Long-Stable kernels [2].
>
> The intermediate git branches are merged daily in the linux-next tree [3],
> people are encouraged testing these pre-release kernels and report issues on the
> relevant mailing-lists.
>
> If problems are discovered on those changes, please submit a signed-off-by revert
> patch followed by a corrective changeset.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>
^ permalink raw reply
* Re: [PATCH v10 0/8] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-03-26 13:09 UTC (permalink / raw)
To: Andrew Morton
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, bhe, vgoyal, dyoung, rdunlap,
peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees, elver,
paulmck, lirongqing, rppt, ardb, leitao, osandov, cfsworks,
tangyouling, sourabhjain, ritesh.list, eajames, songshuaishuai,
kevin.brodsky, samuel.holland, vishal.moola, junhui.liu, coxu,
liaoyuanhong, jbohac, fuqiang.wang, guoren, chenjiahao16,
hbathini, james.morse, takahiro.akashi, lizhengyu3, x86,
linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260325210049.28cca592a001e745954b3241@linux-foundation.org>
On 2026/3/26 12:00, Andrew Morton wrote:
> On Wed, 25 Mar 2026 10:58:56 +0800 Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
>> The crash memory allocation, and the exclude of crashk_res, crashk_low_res
>> and crashk_cma memory are almost identical across different architectures,
>> This patch set handle them in crash core in a general way, which eliminate
>> a lot of duplication code.
>>
>> And add support for crashkernel CMA reservation for arm64 and riscv.
>
> So who is patchmonkey for this.
>
>> .../admin-guide/kernel-parameters.txt | 16 +--
>> arch/arm64/kernel/machine_kexec_file.c | 39 ++-----
>> arch/arm64/mm/init.c | 5 +-
>> arch/loongarch/kernel/machine_kexec_file.c | 39 ++-----
>> arch/powerpc/include/asm/kexec_ranges.h | 1 -
>> arch/powerpc/kexec/crash.c | 7 +-
>> arch/powerpc/kexec/ranges.c | 101 +----------------
>> arch/riscv/kernel/machine_kexec_file.c | 38 ++-----
>> arch/riscv/mm/init.c | 5 +-
>> arch/x86/kernel/crash.c | 89 ++-------------
>> drivers/of/fdt.c | 9 +-
>> drivers/of/kexec.c | 9 ++
>> include/linux/crash_core.h | 9 ++
>> kernel/crash_core.c | 105 +++++++++++++++++-
>
> Me, I guess, with as many arch acks as I can gather, please.
>
> I'm seriously trying to slow things down now, but I guess I can make an
> exception for non-MM material.
>
> AI review asks a few questions:
> https://sashiko.dev/#/patchset/20260325025904.2811960-1-ruanjinjie@huawei.com
>
> Can you please check these? And I'm interested in learning how many of
> these are valid. Thanks.
Thanks for the feedback. At the very least, the issue highlighted below
remains valid and needs to be addressed, which can be fixed with below
fixed number usable ranges.
+#define MAX_USABLE_RANGES (6)
"
> */
> -#define MAX_USABLE_RANGES 2
> +#define MAX_USABLE_RANGES (2 + CRASHKERNEL_CMA_RANGES_MAX)
Could this silently drop crash memory if the crash kernel is built without
CONFIG_CMA?
If the main kernel is compiled with CONFIG_CMA, it might append up to 6
regions to the linux,usable-memory-range property (2 standard + 4 CMA).
If the crash kernel is compiled without CONFIG_CMA,
CRASHKERNEL_CMA_RANGES_MAX
evaluates to 0. During boot, the crash kernel's FDT parsing logic limits the
ranges to MAX_USABLE_RANGES (which would be 2). This truncates the ranges
and drops all the CMA-backed crash memory.
Since the crash kernel only registers these regions as normal RAM, it
doesn't
require CONFIG_CMA to use them. Should MAX_USABLE_RANGES unconditionally
accommodate the maximum possible ranges any sender might provide?"
Regarding the concurrency issue mentioned below, as noted in my v9
response, could we confirm if this is indeed a bug? If so, I believe
each affected architecture might need a separate fix, as this issue
already exists in the current code and likely requires a more
comprehensive solution. Does anyone have thoughts on whether this is a
valid concern or suggestions on how to address it?
Link:
https://lore.kernel.org/all/4cfde40c-673a-12b0-dfc5-703d582d6ea9@huawei.com/
"
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -326,15 +326,25 @@ int crash_prepare_headers(int need_kernel_map,
void **addr, unsigned long *sz,
> struct crash_mem *cmem;
> int ret;
>
> + if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
> + lock_device_hotplug();
Can this cause a self-deadlock during memory hotplug?
When memory is onlined or offlined via sysfs (for example, in state_store()
calling lock_device_hotplug_sysfs()), the device_hotplug_lock is already
acquired before initiating the hotplug sequence.
Since crash_prepare_headers() can be invoked by the crash_memhp_notifier
during these memory hotplug operations, acquiring device_hotplug_lock again
here would cause a recursive mutex acquisition.
> +
> max_nr_ranges = arch_get_system_nr_ranges();
> - if (!max_nr_ranges)
> - return -ENOMEM;
> + if (!max_nr_ranges) {
> + ret = -ENOMEM;
> + goto unlock;
> + }
>
> cmem = alloc_cmem(max_nr_ranges);
> - if (!cmem)
> - return -ENOMEM;
> + if (!cmem) {
> + ret = -ENOMEM;
> + goto unlock;
> + }
>
> ret = arch_crash_populate_cmem(cmem);
While the locking attempts to address the race, is it possible that the
architecture specific population callbacks could still write out of bounds?
The callbacks appear to unconditionally write to
cmem->ranges[cmem->nr_ranges]
without verifying if cmem->nr_ranges >= cmem->max_nr_ranges.
Would it be safer to also add explicit bounds checking inside the populate
callbacks to return an error like -ENOMEM when the array capacity is
exceeded?"
>
^ permalink raw reply
* Re: (subset) [PATCH v5 0/9] arm64: dts: amlogic: Add MMC/SD/SDIO support for Khadas VIM4 (Amlogic T7)
From: Neil Armstrong @ 2026-03-26 13:08 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ulf Hansson, Johannes Berg,
van Spriel, Ronald Claveau
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley, Xianwei Zhao, Nick Xie
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-0-d3f182b48e9d@aliel.fr>
Hi,
On Thu, 26 Mar 2026 10:59:11 +0100, Ronald Claveau wrote:
> This patch series depends on Jian's SCMI clock patches yet to merge
> https://lore.kernel.org/all/20260313070022.700437-1-jian.hu@amlogic.com/
>
> This series adds device tree support for the MMC, SD card and SDIO
> interfaces on the Amlogic T7 SoC and the Khadas VIM4 board.
>
> The first patches add the necessary building blocks in the T7 SoC
> DTSI: pinctrl nodes for pin muxing, PWM controller nodes, and MMC
> controller nodes. The amlogic,t7-mmc and amlogic,t7-pwm compatible
> strings are introduced with fallbacks to existing drivers, avoiding
> the need for new driver code.
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
https://git.kernel.org/amlogic/c/fb69fa2cabc68da247bcc0bc99a14dc857b16842
[4/9] arm64: dts: amlogic: t7: Add PWM pinctrl nodes
https://git.kernel.org/amlogic/c/b1e49f6c1ac15b2c947bdb1d22a82b823de22d27
[6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
https://git.kernel.org/amlogic/c/60eff75ac67bbf5445bdbd2842b0109ac591441c
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* [PATCH v4 2/2] arm64: dts: imx8qm-tqma8qm-mba8x: Disable Cortex-A72 cluster
From: Alexander Stein @ 2026-03-26 13:02 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Alexander Stein, imx, linux-arm-kernel, devicetree, linux-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260326130225.1406806-1-alexander.stein@ew.tq-group.com>
Due to missing workaround for "ERR050104: Arm/A53: Cache coherency issue"
disable the whole Cortex-A72 cluster.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v4:
* None
.../dts/freescale/imx8qm-tqma8qm-mba8x.dts | 39 -------------------
.../boot/dts/freescale/imx8qm-tqma8qm.dtsi | 13 +++++--
2 files changed, 10 insertions(+), 42 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
index bf972010a88e7..ab3b244b684fd 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
@@ -298,45 +298,6 @@ map3 {
};
};
};
-
- cpu1-thermal {
- trips {
- soc_active1_0: trip-active0 {
- temperature = <40000>;
- hysteresis = <5000>;
- type = "active";
- };
-
- soc_active1_1: trip-active1 {
- temperature = <48000>;
- hysteresis = <3000>;
- type = "active";
- };
-
- soc_active1_2: trip-active2 {
- temperature = <60000>;
- hysteresis = <10000>;
- type = "active";
- };
- };
-
- cooling-maps {
- map1 {
- trip = <&soc_active1_0>;
- cooling-device = <&fan0 1 1>;
- };
-
- map2 {
- trip = <&soc_active1_1>;
- cooling-device = <&fan0 2 2>;
- };
-
- map3 {
- trip = <&soc_active1_2>;
- cooling-device = <&fan0 3 3>;
- };
- };
- };
};
};
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
index d94605c999915..f0e398eb2aad7 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
@@ -15,6 +15,13 @@ / {
model = "TQ-Systems i.MX8QM TQMa8QM";
compatible = "tq,imx8qm-tqma8qm", "fsl,imx8qm";
+ /* Due to missing workaround for ERR050104 */
+ cpus {
+ /delete-node/ cpu-map;
+ /delete-node/ cpu@100;
+ /delete-node/ cpu@101;
+ };
+
memory@80000000 {
device_type = "memory";
/*
@@ -174,6 +181,8 @@ &mu2_m0 {
};
&thermal_zones {
+ /delete-node/ cpu1-thermal;
+
pmic0-thermal {
polling-delay-passive = <250>;
polling-delay = <2000>;
@@ -199,9 +208,7 @@ map0 {
<&A53_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
<&A53_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
<&A53_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
- <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
- <&A72_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
- <&A72_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
};
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/2] arm64: dts: freescale: add initial device tree for TQMa8x
From: Alexander Stein @ 2026-03-26 13:02 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Alexander Stein, imx, linux-arm-kernel, devicetree, linux-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260326130225.1406806-1-alexander.stein@ew.tq-group.com>
This adds support for TQMa8QM module on MBa8x board, based on i.MX8 SoC.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v4:
* Sorted nodes by node name, not by phandle
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8qm-tqma8qm-mba8x.dts | 910 ++++++++++++++++++
.../boot/dts/freescale/imx8qm-tqma8qm.dtsi | 318 ++++++
3 files changed, 1229 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 04cf176fc1d81..c58b97522e7f0 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -404,6 +404,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8qm-apalis-v1.1-eval-v1.2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qm-apalis-v1.1-ixora-v1.1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qm-apalis-v1.1-ixora-v1.2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qm-mek.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8qm-tqma8qm-mba8x.dtb
imx8qm-mek-ov5640-csi0-dtbs := imx8qm-mek.dtb imx8qm-mek-ov5640-csi0.dtbo
dtb-${CONFIG_ARCH_MXC} += imx8qm-mek-ov5640-csi0.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
new file mode 100644
index 0000000000000..bf972010a88e7
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
@@ -0,0 +1,910 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2019-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/net/ti-dp83867.h>
+#include <dt-bindings/pwm/pwm.h>
+
+#include "imx8qm-tqma8qm.dtsi"
+
+/ {
+ model = "TQ-Systems i.MX8QM TQMa8QM on MBa8x";
+ compatible = "tq,imx8qm-tqma8qm-mba8x", "tq,imx8qm-tqma8qm", "fsl,imx8qm";
+
+ adc {
+ compatible = "iio-hwmon";
+ io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>;
+ };
+
+ aliases {
+ rtc0 = &pcf85063;
+ rtc1 = &rtc;
+ };
+
+ chosen {
+ stdout-path = &lpuart0;
+ };
+
+
+ clk_xtal25: clk-xtal25 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpiokeys>;
+ autorepeat;
+
+ switch-1 {
+ label = "SWITCH_A";
+ linux,code = <BTN_0>;
+ gpios = <&lsio_gpio2 11 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ switch-2 {
+ label = "SWITCH_B";
+ linux,code = <BTN_1>;
+ gpios = <&lsio_gpio1 0 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpioled>;
+
+ user-led0 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_HEARTBEAT;
+ gpios = <&lsio_gpio5 20 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ user-led1 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&lsio_gpio5 19 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ fan0: pwm-fan {
+ compatible = "pwm-fan";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwmfan>;
+ fan-supply = <®_pwm_fan>;
+ #cooling-cells = <2>;
+ /* typical 25 kHz -> 40.000 nsec */
+ pwms = <&lsio_pwm3 0 40000 PWM_POLARITY_INVERTED>;
+ cooling-levels = <0 32 64 128 196 240>;
+ pulses-per-revolution = <2>;
+ interrupt-parent = <&lsio_gpio2>;
+ interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
+ status = "disabled";
+ };
+
+ reg_mba8x_12v: regulator-mba8x-12v {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_mba8x_12v>;
+ regulator-name = "MBa8x-V12";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ enable-active-high;
+ gpio = <&lsio_gpio1 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_mba8x_v3v3: regulator-mba8x-v3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "V_3V3_MB";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_pwm_fan: regulator-pwm-fan {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_regpwmfan>;
+ regulator-name = "FAN_PWR";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ gpio = <&lsio_gpio2 12 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <®_mba8x_12v>;
+ };
+
+ reg_usb_phy: regulator-usb-phy {
+ compatible = "regulator-fixed";
+ regulator-max-microvolt = <3000000>;
+ regulator-min-microvolt = <3000000>;
+ regulator-name = "usb-phy-dummy";
+ };
+
+ reg_v1v5_pcie: regulator-v1v5-pcie {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_pcie_v1v5>;
+ regulator-name = "V_1V5_MPCIE";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ vin-supply = <®_mba8x_v3v3>;
+ enable-active-high;
+ gpio = <&lsio_gpio0 31 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ };
+
+ reg_v1v8: regulator-v1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "MBa8x-V1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_v3v3_pcie: regulator-v3v3-pcie {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_pcie_v3v3>;
+ regulator-name = "V_3V3_MPCIE";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <®_mba8x_v3v3>;
+ enable-active-high;
+ gpio = <&lsio_gpio1 1 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ };
+
+ reg_v3v3_sd: regulator-v3v3-sd {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_v3v3_sd>;
+ regulator-name = "V3V3_SD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <®_mba8x_v3v3>;
+ gpio = <&lsio_gpio4 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-boot-on;
+ off-on-delay-us = <200000>;
+ };
+
+ reg_vref_v1v8: regulator-vref-v1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VREF_V1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /*
+ * global autoconfigured region for contiguous allocations
+ * must not exceed memory size and region
+ */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0 0x3c000000>;
+ alloc-ranges = <0 0x96000000 0 0x3c000000>;
+ linux,cma-default;
+ };
+
+ decoder_boot: decoder-boot@84000000 {
+ reg = <0 0x84000000 0 0x2000000>;
+ no-map;
+ };
+
+ encoder1_boot: encoder1-boot@86000000 {
+ reg = <0 0x86000000 0 0x200000>;
+ no-map;
+ };
+
+ encoder2_boot: encoder2-boot@86200000 {
+ reg = <0 0x86200000 0 0x200000>;
+ no-map;
+ };
+
+ decoder_rpc: decoder-rpc@92000000 {
+ reg = <0 0x92000000 0 0x100000>;
+ no-map;
+ };
+
+ encoder1_rpc: encoder1-rpc@92100000 {
+ reg = <0 0x92100000 0 0x700000>;
+ no-map;
+ };
+
+ encoder2_rpc: encoder1-rpc@92800000 {
+ reg = <0 0x92800000 0 0x700000>;
+ no-map;
+ };
+ };
+
+ sound {
+ compatible = "fsl,imx-audio-tlv320aic32x4";
+ model = "tqm-tlv320aic32";
+ ssi-controller = <&sai1>;
+ audio-codec = <&tlv320aic3x04>;
+ audio-routing =
+ "IN3_L", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "IN1_L", "Line In Jack",
+ "IN1_R", "Line In Jack",
+ "Line Out Jack", "LOL",
+ "Line Out Jack", "LOR";
+ };
+
+ sound-hdmi {
+ compatible = "fsl,imx-audio-hdmi";
+ model = "imx-audio-dp";
+ audio-cpu = <&sai5>;
+ hdmi-out;
+ };
+
+ thermal-zones {
+ cpu0-thermal {
+ trips {
+ soc_active0_0: trip-active0 {
+ temperature = <40000>;
+ hysteresis = <5000>;
+ type = "active";
+ };
+
+ soc_active0_1: trip-active1 {
+ temperature = <48000>;
+ hysteresis = <3000>;
+ type = "active";
+ };
+
+ soc_active0_2: trip-active2 {
+ temperature = <60000>;
+ hysteresis = <10000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map1 {
+ trip = <&soc_active0_0>;
+ cooling-device = <&fan0 1 1>;
+ };
+
+ map2 {
+ trip = <&soc_active0_1>;
+ cooling-device = <&fan0 2 2>;
+ };
+
+ map3 {
+ trip = <&soc_active0_2>;
+ cooling-device = <&fan0 3 3>;
+ };
+ };
+ };
+
+ cpu1-thermal {
+ trips {
+ soc_active1_0: trip-active0 {
+ temperature = <40000>;
+ hysteresis = <5000>;
+ type = "active";
+ };
+
+ soc_active1_1: trip-active1 {
+ temperature = <48000>;
+ hysteresis = <3000>;
+ type = "active";
+ };
+
+ soc_active1_2: trip-active2 {
+ temperature = <60000>;
+ hysteresis = <10000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map1 {
+ trip = <&soc_active1_0>;
+ cooling-device = <&fan0 1 1>;
+ };
+
+ map2 {
+ trip = <&soc_active1_1>;
+ cooling-device = <&fan0 2 2>;
+ };
+
+ map3 {
+ trip = <&soc_active1_2>;
+ cooling-device = <&fan0 3 3>;
+ };
+ };
+ };
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ nvmem-cells = <&fec_mac0>;
+ nvmem-cell-names = "mac-address";
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ethphy0>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ reset-gpios = <&lsio_gpio2 6 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ enet-phy-lane-no-swap;
+ interrupt-parent = <&lsio_gpio2>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+};
+
+&fec2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec2>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy3>;
+ nvmem-cells = <&fec_mac1>;
+ nvmem-cell-names = "mac-address";
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy3: ethernet-phy@3 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ethphy3>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ reset-gpios = <&lsio_gpio2 4 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ enet-phy-lane-no-swap;
+ };
+ };
+};
+
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ status = "okay";
+};
+
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ status = "okay";
+};
+
+&hsio_phy {
+ fsl,hsio-cfg = "pciea-pcieb-sata";
+ fsl,refclk-pad-mode = "input";
+ status = "okay";
+};
+
+/* no refclock gating */
+&hsio_refa_clk {
+ compatible = "fixed-factor-clock";
+ clocks = <&pcieclk 0>;
+ clock-div = <1>;
+ clock-mult = <1>;
+ /delete-property/ enable-gpios;
+};
+
+&hsio_refb_clk {
+ compatible = "fixed-factor-clock";
+ clocks = <&pcieclk 0>;
+ clock-div = <1>;
+ clock-mult = <1>;
+ /delete-property/ enable-gpios;
+};
+
+&i2c1 {
+ tlv320aic3x04: audio-codec@18 {
+ compatible = "ti,tlv320aic32x4";
+ reg = <0x18>;
+ clocks = <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ clock-names = "mclk";
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>, <49152000>, <12288000>, <12288000>;
+ ldoin-supply = <®_mba8x_v3v3>;
+ iov-supply = <®_v1v8>;
+ };
+
+ sensor1: temperature-sensor@1c {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x1c>;
+ };
+
+ eeprom2: eeprom@54 {
+ compatible = "nxp,se97b", "atmel,24c02";
+ reg = <0x54>;
+ pagesize = <16>;
+ vcc-supply = <®_mba8x_v3v3>;
+ };
+
+ pcieclk: clock-generator@68 {
+ compatible = "renesas,9fgv0441";
+ reg = <0x68>;
+ clocks = <&clk_xtal25>;
+ #clock-cells = <1>;
+ };
+};
+
+&lpspi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi0 &pinctrl_lpspi0_cs>;
+ cs-gpios = <&lsio_gpio3 5 GPIO_ACTIVE_LOW>, <&lsio_gpio3 6 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&lpspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi1 &pinctrl_lpspi1_cs>;
+ cs-gpios = <&lsio_gpio3 24 GPIO_ACTIVE_LOW>, <&lsio_gpio3 25 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&lpspi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi2 &pinctrl_lpspi2_cs>;
+ cs-gpios = <&lsio_gpio3 10 GPIO_ACTIVE_LOW>, <&lsio_gpio3 11 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&lpuart0 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart0>;
+ status = "okay";
+};
+
+&lpuart1 {
+ /* X62 pin header */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart1>;
+ status = "okay";
+};
+
+&lpuart2 {
+ /* mikroBUS */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart2>;
+ status = "okay";
+};
+
+&lsio_gpio2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio2>;
+ gpio-line-names = "", "", "", "",
+ "", "PCIE0_DISABLE#", "", "";
+
+ pcie0-wdisable1-hog {
+ gpio-hog;
+ gpios = <5 0>;
+ output-high;
+ line-name = "PCIE0_DISABLE#";
+ };
+
+ pcie-clk-pd-hog {
+ gpio-hog;
+ gpios = <10 0>;
+ output-high;
+ line-name = "PCIE_CLK_PD#";
+ };
+};
+
+&lsio_pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lsio_pwm3>;
+ status = "okay";
+};
+
+&pciea {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pciea>;
+ phys = <&hsio_phy 0 PHY_TYPE_PCIE 0>;
+ phy-names = "pcie-phy";
+ reset-gpio = <&lsio_gpio4 29 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&pcieb {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcieb>;
+ phys = <&hsio_phy 1 PHY_TYPE_PCIE 1>;
+ phy-names = "pcie-phy";
+ reset-gpio = <&lsio_gpio5 0 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&sai1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai1>;
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&sai1_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>, <49152000>, <12288000>, <49152000>;
+ status = "okay";
+};
+
+&sai5 {
+ status = "okay";
+};
+
+&sai5_lpcg {
+ status = "okay";
+};
+
+&sata {
+ status = "okay";
+};
+
+&usbphy1 {
+ phy-3p0-supply = <®_usb_phy>;
+ status = "okay";
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg1>;
+ srp-disable;
+ hnp-disable;
+ adp-disable;
+ power-active-high;
+ over-current-active-low;
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usb3_phy {
+ status = "okay";
+};
+
+&usbotg3 {
+ /* over-current disabled by default */
+ status = "okay";
+};
+
+&usbotg3_cdns3 {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbhub>;
+ status = "okay";
+
+ hub_2_0: hub@1 {
+ compatible = "usb451,8142";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&lsio_gpio2 7 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_mba8x_v3v3>;
+ };
+
+ hub_3_0: hub@2 {
+ compatible = "usb451,8140";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&lsio_gpio2 7 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_mba8x_v3v3>;
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ bus-width = <4>;
+ cd-gpios = <&lsio_gpio5 22 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&lsio_gpio5 21 GPIO_ACTIVE_HIGH>;
+ vmmc-supply = <®_v3v3_sd>;
+ no-mmc;
+ no-sdio;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio>;
+
+ pinctrl_adc0: adc0grp {
+ fsl,pins = <IMX8QM_ADC_IN1_DMA_ADC0_IN1 0x02000060>,
+ <IMX8QM_ADC_IN2_DMA_ADC0_IN2 0x02000060>;
+ };
+
+ pinctrl_ethphy0: ethphy0grp {
+ fsl,pins = <IMX8QM_ESAI1_SCKR_LSIO_GPIO2_IO06 0x00000041>,
+ <IMX8QM_ESAI1_TX0_LSIO_GPIO2_IO08 0x00000021>;
+ };
+
+ pinctrl_ethphy3: ethphy3grp {
+ fsl,pins = <IMX8QM_ESAI1_FSR_LSIO_GPIO2_IO04 0x00000041>;
+ };
+
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <IMX8QM_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB_PAD 0x000014a0>,
+ <IMX8QM_ENET0_MDC_CONN_ENET0_MDC 0x06000041>,
+ <IMX8QM_ENET0_MDIO_CONN_ENET0_MDIO 0x06000041>,
+ <IMX8QM_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL 0x00000041>,
+ <IMX8QM_ENET0_RGMII_TXC_CONN_ENET0_RGMII_TXC 0x00000041>,
+ <IMX8QM_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0 0x00000041>,
+ <IMX8QM_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1 0x00000041>,
+ <IMX8QM_ENET0_RGMII_TXD2_CONN_ENET0_RGMII_TXD2 0x00000041>,
+ <IMX8QM_ENET0_RGMII_TXD3_CONN_ENET0_RGMII_TXD3 0x00000041>,
+ <IMX8QM_ENET0_RGMII_RXC_CONN_ENET0_RGMII_RXC 0x00000040>,
+ <IMX8QM_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL 0x00000040>,
+ <IMX8QM_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0 0x00000040>,
+ <IMX8QM_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1 0x00000040>,
+ <IMX8QM_ENET0_RGMII_RXD2_CONN_ENET0_RGMII_RXD2 0x00000040>,
+ <IMX8QM_ENET0_RGMII_RXD3_CONN_ENET0_RGMII_RXD3 0x00000040>;
+ };
+
+ pinctrl_fec2: fec2grp {
+ fsl,pins = <IMX8QM_COMP_CTL_GPIO_1V8_3V3_ENET_ENETA_PAD 0x000014a0>,
+ <IMX8QM_ENET1_MDC_CONN_ENET1_MDC 0x06000041>,
+ <IMX8QM_ENET1_MDIO_CONN_ENET1_MDIO 0x06000041>,
+ <IMX8QM_ENET1_RGMII_TX_CTL_CONN_ENET1_RGMII_TX_CTL 0x00000041>,
+ <IMX8QM_ENET1_RGMII_TXC_CONN_ENET1_RGMII_TXC 0x00000041>,
+ <IMX8QM_ENET1_RGMII_TXD0_CONN_ENET1_RGMII_TXD0 0x00000041>,
+ <IMX8QM_ENET1_RGMII_TXD1_CONN_ENET1_RGMII_TXD1 0x00000041>,
+ <IMX8QM_ENET1_RGMII_TXD2_CONN_ENET1_RGMII_TXD2 0x00000041>,
+ <IMX8QM_ENET1_RGMII_TXD3_CONN_ENET1_RGMII_TXD3 0x00000041>,
+ <IMX8QM_ENET1_RGMII_RXC_CONN_ENET1_RGMII_RXC 0x00000040>,
+ <IMX8QM_ENET1_RGMII_RX_CTL_CONN_ENET1_RGMII_RX_CTL 0x00000040>,
+ <IMX8QM_ENET1_RGMII_RXD0_CONN_ENET1_RGMII_RXD0 0x00000040>,
+ <IMX8QM_ENET1_RGMII_RXD1_CONN_ENET1_RGMII_RXD1 0x00000040>,
+ <IMX8QM_ENET1_RGMII_RXD2_CONN_ENET1_RGMII_RXD2 0x00000040>,
+ <IMX8QM_ENET1_RGMII_RXD3_CONN_ENET1_RGMII_RXD3 0x00000040>;
+ };
+
+ pinctrl_flexcan1: flexcan0grp {
+ fsl,pins = <IMX8QM_FLEXCAN0_TX_DMA_FLEXCAN0_TX 0x00000021>,
+ <IMX8QM_FLEXCAN0_RX_DMA_FLEXCAN0_RX 0x00000021>;
+ };
+
+ pinctrl_flexcan2: flexcan1grp {
+ fsl,pins = <IMX8QM_FLEXCAN1_TX_DMA_FLEXCAN1_TX 0x00000021>,
+ <IMX8QM_FLEXCAN1_RX_DMA_FLEXCAN1_RX 0x00000021>;
+ };
+
+ pinctrl_gpio2: gpio2grp {
+ fsl,pins = <IMX8QM_ESAI1_FST_LSIO_GPIO2_IO05 0x00000021>,
+ <IMX8QM_ESAI1_TX2_RX3_LSIO_GPIO2_IO10 0x00000021>;
+ };
+
+ pinctrl_gpio: gpiogrp {
+ fsl,pins = /* GPIO0_05 on X62:26 */
+ <IMX8QM_SIM0_GPIO0_00_LSIO_GPIO0_IO05 0x00000021>,
+ /* GPIO1_14 on X64:21 */
+ <IMX8QM_LVDS1_I2C1_SCL_LSIO_GPIO1_IO14 0x00000021>,
+ /* GPIO1_15 on X64:23 */
+ <IMX8QM_LVDS1_I2C1_SDA_LSIO_GPIO1_IO15 0x00000021>,
+ /* GPIO2_17 on X63:37 */
+ <IMX8QM_SPI3_SCK_LSIO_GPIO2_IO17 0x00000021>,
+ /* GPIO2_21 on X63:39 */
+ <IMX8QM_SPI3_CS1_LSIO_GPIO2_IO21 0x00000021>,
+ /* GPIO4_12 on X61:24 */
+ <IMX8QM_USDHC2_CD_B_LSIO_GPIO4_IO12 0x00000021>,
+ /* GPIO4_11 on X61:26 */
+ <IMX8QM_USDHC2_WP_LSIO_GPIO4_IO11 0x00000021>,
+ /* GPIO4_10 on X61:28 */
+ <IMX8QM_USDHC2_VSELECT_LSIO_GPIO4_IO10 0x00000021>,
+ /* GPIO4_09 on X61:30 */
+ <IMX8QM_USDHC2_RESET_B_LSIO_GPIO4_IO09 0x00000021>,
+ /* GPIO5_23 on X62:24 */
+ <IMX8QM_USDHC1_STROBE_LSIO_GPIO5_IO23 0x00000021>,
+ /* GPIO5_24 on X61:15 */
+ <IMX8QM_USDHC2_CLK_LSIO_GPIO5_IO24 0x00000021>,
+ /* GPIO5_25 on X61:17 */
+ <IMX8QM_USDHC2_CMD_LSIO_GPIO5_IO25 0x00000021>,
+ /* GPIO5_26 on X61:19 */
+ <IMX8QM_USDHC2_DATA0_LSIO_GPIO5_IO26 0x00000021>,
+ /* GPIO5_27 on X61:21 */
+ <IMX8QM_USDHC2_DATA1_LSIO_GPIO5_IO27 0x00000021>,
+ /* GPIO5_28 on X61:23 */
+ <IMX8QM_USDHC2_DATA2_LSIO_GPIO5_IO28 0x00000021>,
+ /* GPIO5_29 on X61:25 */
+ <IMX8QM_USDHC2_DATA3_LSIO_GPIO5_IO29 0x00000021>;
+ };
+
+ pinctrl_gpiokeys: gpiokeysgrp {
+ fsl,pins = <IMX8QM_ESAI1_TX3_RX2_LSIO_GPIO2_IO11 0x00000021>,
+ <IMX8QM_SCU_GPIO0_04_LSIO_GPIO1_IO00 0x00000021>;
+ };
+
+ pinctrl_gpioled: gpioledgrp {
+ fsl,pins = <IMX8QM_USDHC1_DATA4_LSIO_GPIO5_IO19 0x00000021>,
+ <IMX8QM_USDHC1_DATA5_LSIO_GPIO5_IO20 0x00000021>;
+ };
+
+ pinctrl_lpspi0_cs: lpspi0csgrp {
+ fsl,pins = <IMX8QM_SPI0_CS0_LSIO_GPIO3_IO05 0x00000021>,
+ <IMX8QM_SPI0_CS1_LSIO_GPIO3_IO06 0x00000021>;
+ };
+
+ pinctrl_lpspi0: lpspi0grp {
+ fsl,pins = <IMX8QM_SPI0_SCK_DMA_SPI0_SCK 0x0600004d>,
+ <IMX8QM_SPI0_SDO_DMA_SPI0_SDO 0x0600004d>,
+ <IMX8QM_SPI0_SDI_DMA_SPI0_SDI 0x0600004d>;
+ };
+
+ pinctrl_lpspi1_cs: lpspi1csgrp {
+ fsl,pins = <IMX8QM_ADC_IN6_LSIO_GPIO3_IO24 0x00000021>,
+ <IMX8QM_ADC_IN7_LSIO_GPIO3_IO25 0x00000021>;
+ };
+
+ pinctrl_lpspi1: lpspi1grp {
+ fsl,pins = <IMX8QM_ADC_IN3_DMA_SPI1_SCK 0x0600004d>,
+ <IMX8QM_ADC_IN4_DMA_SPI1_SDO 0x0600004d>,
+ <IMX8QM_ADC_IN5_DMA_SPI1_SDI 0x0600004d>;
+ };
+
+ pinctrl_lpspi2: lpspi2grp {
+ fsl,pins = <IMX8QM_SPI2_SCK_DMA_SPI2_SCK 0x0600004d>,
+ <IMX8QM_SPI2_SDO_DMA_SPI2_SDO 0x0600004d>,
+ <IMX8QM_SPI2_SDI_DMA_SPI2_SDI 0x0600004d>;
+ };
+
+ pinctrl_lpspi2_cs: lpspi2sgrp {
+ fsl,pins = <IMX8QM_SPI2_CS0_LSIO_GPIO3_IO10 0x00000021>,
+ <IMX8QM_SPI2_CS1_LSIO_GPIO3_IO11 0x00000021>;
+ };
+
+ pinctrl_lpuart0: lpuart0grp {
+ fsl,pins = <IMX8QM_UART0_RX_DMA_UART0_RX 0x06000021>,
+ <IMX8QM_UART0_TX_DMA_UART0_TX 0x06000021>,
+ <IMX8QM_UART0_CTS_B_DMA_UART0_CTS_B 0x00000021>,
+ <IMX8QM_UART0_RTS_B_DMA_UART0_RTS_B 0x00000021>;
+ };
+
+ pinctrl_lpuart1: lpuart1grp {
+ fsl,pins = <IMX8QM_UART1_RX_DMA_UART1_RX 0x06000021>,
+ <IMX8QM_UART1_TX_DMA_UART1_TX 0x06000021>,
+ <IMX8QM_UART1_CTS_B_DMA_UART1_CTS_B 0x00000021>,
+ <IMX8QM_UART1_RTS_B_DMA_UART1_RTS_B 0x00000021>;
+ };
+
+ pinctrl_lpuart2: lpuart2grp {
+ fsl,pins = <IMX8QM_LVDS0_I2C1_SDA_DMA_UART2_RX 0x06000021>,
+ <IMX8QM_LVDS0_I2C1_SCL_DMA_UART2_TX 0x06000021>;
+ };
+
+ pinctrl_lsio_pwm3: lsiopwm3grp {
+ fsl,pins = <IMX8QM_GPT0_COMPARE_LSIO_PWM3_OUT 0x00000021>;
+ };
+
+ pinctrl_pciea: pcieagrp {
+ fsl,pins = <IMX8QM_PCIE_CTRL0_PERST_B_LSIO_GPIO4_IO29 0x06000021>,
+ <IMX8QM_PCIE_CTRL0_CLKREQ_B_HSIO_PCIE0_CLKREQ_B 0x06000021>,
+ <IMX8QM_PCIE_CTRL0_WAKE_B_LSIO_GPIO4_IO28 0x04000021>;
+ };
+
+ pinctrl_pcieb: pciebgrp {
+ fsl,pins = <IMX8QM_PCIE_CTRL1_PERST_B_LSIO_GPIO5_IO00 0x06000021>,
+ <IMX8QM_PCIE_CTRL1_CLKREQ_B_HSIO_PCIE1_CLKREQ_B 0x06000021>,
+ <IMX8QM_PCIE_CTRL1_WAKE_B_LSIO_GPIO4_IO31 0x04000021>;
+ };
+
+ pinctrl_pwmfan: pwmfangrp {
+ fsl,pins = <IMX8QM_SPI3_CS0_LSIO_GPIO2_IO20 0x30>;
+ };
+
+ pinctrl_reg_mba8x_12v: regmba12vgrp {
+ fsl,pins = <IMX8QM_SCU_GPIO0_06_LSIO_GPIO1_IO02 0x00000021>;
+ };
+
+ pinctrl_reg_pcie_v1v5: regpcie1v5grp {
+ fsl,pins = <IMX8QM_SCU_GPIO0_03_LSIO_GPIO0_IO31 0x00000021>;
+ };
+
+ pinctrl_reg_pcie_v3v3: regpcie3v3grp {
+ fsl,pins = <IMX8QM_SCU_GPIO0_05_LSIO_GPIO1_IO01 0x00000021>;
+ };
+
+ pinctrl_regpwmfan: regpwmfangrp {
+ fsl,pins = <IMX8QM_ESAI1_TX4_RX1_LSIO_GPIO2_IO12 0x00000021>;
+ };
+
+ pinctrl_reg_v3v3_sd: regv3v3sdgrp {
+ fsl,pins = <IMX8QM_USDHC1_RESET_B_LSIO_GPIO4_IO07 0x00000021>;
+ };
+
+ pinctrl_sai1: sai1grp {
+ fsl,pins = <IMX8QM_SAI1_RXD_AUD_SAI1_RXD 0x06000041>,
+ <IMX8QM_SAI1_RXC_AUD_SAI1_RXC 0x06000041>,
+ <IMX8QM_SAI1_RXFS_AUD_SAI1_RXFS 0x06000041>,
+ <IMX8QM_SAI1_TXD_AUD_SAI1_TXD 0x06000061>,
+ <IMX8QM_SAI1_TXC_AUD_SAI1_TXC 0x06000041>,
+ <IMX8QM_MCLK_OUT0_AUD_ACM_MCLK_OUT0 0x0600004d>;
+ };
+
+ pinctrl_usbhub: usbhubgrp {
+ fsl,pins = <IMX8QM_ESAI1_SCKT_LSIO_GPIO2_IO07 0x00000021>;
+ };
+
+ pinctrl_usbotg1: usbotg1grp {
+ fsl,pins = <IMX8QM_USB_SS3_TC2_CONN_USB_OTG1_OC 0x00000021>,
+ <IMX8QM_USB_SS3_TC0_CONN_USB_OTG1_PWR 0x00000021>;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <IMX8QM_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041>,
+ <IMX8QM_USDHC1_CMD_CONN_USDHC1_CMD 0x00000021>,
+ <IMX8QM_USDHC1_DATA0_CONN_USDHC1_DATA0 0x00000021>,
+ <IMX8QM_USDHC1_DATA1_CONN_USDHC1_DATA1 0x00000021>,
+ <IMX8QM_USDHC1_DATA2_CONN_USDHC1_DATA2 0x00000021>,
+ <IMX8QM_USDHC1_DATA3_CONN_USDHC1_DATA3 0x00000021>,
+ <IMX8QM_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x00000021>;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <IMX8QM_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041>,
+ <IMX8QM_USDHC1_CMD_CONN_USDHC1_CMD 0x00000021>,
+ <IMX8QM_USDHC1_DATA0_CONN_USDHC1_DATA0 0x00000021>,
+ <IMX8QM_USDHC1_DATA1_CONN_USDHC1_DATA1 0x00000021>,
+ <IMX8QM_USDHC1_DATA2_CONN_USDHC1_DATA2 0x00000021>,
+ <IMX8QM_USDHC1_DATA3_CONN_USDHC1_DATA3 0x00000021>,
+ <IMX8QM_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x00000021>;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <IMX8QM_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041>,
+ <IMX8QM_USDHC1_CMD_CONN_USDHC1_CMD 0x00000021>,
+ <IMX8QM_USDHC1_DATA0_CONN_USDHC1_DATA0 0x00000021>,
+ <IMX8QM_USDHC1_DATA1_CONN_USDHC1_DATA1 0x00000021>,
+ <IMX8QM_USDHC1_DATA2_CONN_USDHC1_DATA2 0x00000021>,
+ <IMX8QM_USDHC1_DATA3_CONN_USDHC1_DATA3 0x00000021>,
+ <IMX8QM_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x00000021>;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
+ fsl,pins = <IMX8QM_USDHC1_DATA6_LSIO_GPIO5_IO21 0x00000021>,
+ <IMX8QM_USDHC1_DATA7_LSIO_GPIO5_IO22 0x00000021>;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
new file mode 100644
index 0000000000000..d94605c999915
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
@@ -0,0 +1,318 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2019-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ */
+
+#include <dt-bindings/firmware/imx/rsrc.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/thermal/thermal.h>
+
+#include "imx8qm.dtsi"
+
+/ {
+ model = "TQ-Systems i.MX8QM TQMa8QM";
+ compatible = "tq,imx8qm-tqma8qm", "fsl,imx8qm";
+
+ memory@80000000 {
+ device_type = "memory";
+ /*
+ * DRAM base addr, size : 1024 MiB DRAM
+ * should be corrected by bootloader
+ */
+ reg = <0x00000000 0x80000000 0 0x40000000>;
+ };
+
+ reg_tqma8x_v3v3: regulator-tqma8x-v3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "V_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ /* SW7 controlled by SCU */
+ reg_1v8_io1: regulator-v1v8-io1 {
+ compatible = "regulator-fixed";
+ regulator-name = "V_1V8_IO1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ /* LDO4 controlled by SCU */
+ reg_3v3_emmc: regulator-v3v3-emmc {
+ compatible = "regulator-fixed";
+ regulator-name = "V_3V3_EMMC";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+};
+
+&acm {
+ status = "okay";
+};
+
+&adc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc0>;
+ vref-supply = <®_vref_v1v8>;
+ status = "okay";
+};
+
+/* TQMa8QM only uses industrial grade, reduce trip points accordingly */
+&cpu_alert0 {
+ temperature = <95000>;
+};
+
+&cpu_crit0 {
+ temperature = <100000>;
+};
+
+&cpu_alert1 {
+ temperature = <95000>;
+};
+
+&cpu_crit1 {
+ temperature = <100000>;
+};
+
+&gpu_alert0 {
+ temperature = <95000>;
+};
+
+&gpu_crit0 {
+ temperature = <100000>;
+};
+
+&gpu_alert1 {
+ temperature = <95000>;
+};
+
+&gpu_crit1 {
+ temperature = <100000>;
+};
+
+&drc_alert0 {
+ temperature = <95000>;
+};
+
+&drc_crit0 {
+ temperature = <100000>;
+};
+/* end of temperature grade adjustments */
+
+&flexspi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexspi0>;
+ status = "okay";
+
+ flash0: flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <66000000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ vcc-supply = <®_1v8_io1>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c1>;
+ pinctrl-1 = <&pinctrl_lpi2c1gpio>;
+ scl-gpios = <&lsio_gpio0 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&lsio_gpio0 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ se97: temperature-sensor@1b {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x1b>;
+ };
+
+ pcf85063: rtc@51 {
+ compatible = "nxp,pcf85063a";
+ reg = <0x51>;
+ quartz-load-femtofarads = <7000>;
+ };
+
+ at24c02: eeprom@53 {
+ compatible = "nxp,se97b", "atmel,24c02";
+ reg = <0x53>;
+ pagesize = <16>;
+ read-only;
+ vcc-supply = <®_tqma8x_v3v3>;
+ };
+
+ m24c64: eeprom@57 {
+ compatible = "atmel,24c64";
+ reg = <0x57>;
+ pagesize = <32>;
+ vcc-supply = <®_tqma8x_v3v3>;
+ };
+};
+
+&mu_m0 {
+ status = "okay";
+};
+
+&mu1_m0 {
+ status = "okay";
+};
+
+&mu2_m0 {
+ status = "okay";
+};
+
+&thermal_zones {
+ pmic0-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = <&tsens IMX_SC_R_PMIC_0>;
+
+ trips {
+ pmic_alert0: trip0 {
+ temperature = <110000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ pmic_crit0: trip1 {
+ temperature = <125000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&pmic_alert0>;
+ cooling-device =
+ <&A53_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A53_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A53_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A72_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A72_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+};
+
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ vmmc-supply = <®_3v3_emmc>;
+ vqmmc-supply = <®_1v8_io1>;
+ no-sd;
+ no-sdio;
+ non-removable;
+ status = "okay";
+};
+
+&vpu {
+ compatible = "nxp,imx8qm-vpu";
+ status = "okay";
+};
+
+&vpu_core0 {
+ memory-region = <&decoder_boot>, <&decoder_rpc>;
+ status = "okay";
+};
+
+&vpu_core1 {
+ memory-region = <&encoder1_boot>, <&encoder1_rpc>;
+ status = "okay";
+};
+
+&vpu_core2 {
+ memory-region = <&encoder2_boot>, <&encoder2_rpc>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_lpi2c1: lpi2c1grp {
+ fsl,pins = <IMX8QM_GPT0_CAPTURE_DMA_I2C1_SDA 0x0600004d>,
+ <IMX8QM_GPT0_CLK_DMA_I2C1_SCL 0x0600004d>;
+ };
+
+ pinctrl_lpi2c1gpio: lpi2c1gpiogrp {
+ fsl,pins = <IMX8QM_GPT0_CAPTURE_LSIO_GPIO0_IO15 0x0600004d>,
+ <IMX8QM_GPT0_CLK_LSIO_GPIO0_IO14 0x0600004d>;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041>,
+ <IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021>,
+ <IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021>,
+ <IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021>,
+ <IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021>,
+ <IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021>,
+ <IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021>,
+ <IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021>,
+ <IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021>,
+ <IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021>,
+ <IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041>,
+ <IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x00000021>;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK 0x06000040>,
+ <IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021>,
+ <IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021>,
+ <IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021>,
+ <IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021>,
+ <IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021>,
+ <IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021>,
+ <IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021>,
+ <IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021>,
+ <IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021>,
+ <IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041>,
+ <IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x00000021>;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <IMX8QM_EMMC0_CLK_CONN_EMMC0_CLK 0x06000040>,
+ <IMX8QM_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021>,
+ <IMX8QM_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021>,
+ <IMX8QM_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021>,
+ <IMX8QM_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021>,
+ <IMX8QM_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021>,
+ <IMX8QM_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021>,
+ <IMX8QM_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021>,
+ <IMX8QM_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021>,
+ <IMX8QM_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021>,
+ <IMX8QM_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041>,
+ <IMX8QM_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x00000021>;
+ };
+
+ pinctrl_flexspi0: flexspi0grp {
+ fsl,pins = <IMX8QM_QSPI0A_DATA0_LSIO_QSPI0A_DATA0 0x0000004d>,
+ <IMX8QM_QSPI0A_DATA1_LSIO_QSPI0A_DATA1 0x0000004d>,
+ <IMX8QM_QSPI0A_DATA2_LSIO_QSPI0A_DATA2 0x0000004d>,
+ <IMX8QM_QSPI0A_DATA3_LSIO_QSPI0A_DATA3 0x0000004d>,
+ <IMX8QM_QSPI0A_DQS_LSIO_QSPI0A_DQS 0x0000004d>,
+ <IMX8QM_QSPI0A_SS0_B_LSIO_QSPI0A_SS0_B 0x0000004d>,
+ <IMX8QM_QSPI0A_SS1_B_LSIO_QSPI0A_SS1_B 0x0000004d>,
+ <IMX8QM_QSPI0A_SCLK_LSIO_QSPI0A_SCLK 0x0000004d>,
+ <IMX8QM_QSPI0B_SCLK_LSIO_QSPI0B_SCLK 0x0000004d>,
+ <IMX8QM_QSPI0B_DATA0_LSIO_QSPI0B_DATA0 0x0000004d>,
+ <IMX8QM_QSPI0B_DATA1_LSIO_QSPI0B_DATA1 0x0000004d>,
+ <IMX8QM_QSPI0B_DATA2_LSIO_QSPI0B_DATA2 0x0000004d>,
+ <IMX8QM_QSPI0B_DATA3_LSIO_QSPI0B_DATA3 0x0000004d>,
+ <IMX8QM_QSPI0B_DQS_LSIO_QSPI0B_DQS 0x0000004d>,
+ <IMX8QM_QSPI0B_SS0_B_LSIO_QSPI0B_SS0_B 0x0000004d>,
+ <IMX8QM_QSPI0B_SS1_B_LSIO_QSPI0B_SS1_B 0x0000004d>;
+ };
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/2] Support TQMa8QM
From: Alexander Stein @ 2026-03-26 13:02 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Alexander Stein, imx, linux-arm-kernel, devicetree, linux-kernel,
linux, linux-renesas-soc
Hi,
this series adds support for TQ's TQMa8QM. In v4 several prepatory have been
merged already. So this series include only the two missing patches:
1. platform DT
2. Workaround for missing "ERR050104: Arm/A53: Cache coherency issue"
workaround. See [1] for details. Split into separate commit for easy revert
once an errata workaround has been integrated.
Changes in v4:
* Reduced recipient audience due to reduced patches
* Sorted nodes by name (not by phandle)
Changes in v3:
* Small cleanups in patch 1 & 4
Changes in v2:
The need for clock-output-names properties for renesas,9fgv0441 has
been removed by reworkging the PCIe clocking
Best regards,
Alexander
[1] https://lore.kernel.org/all/20230420112952.28340-1-iivanov@suse.de/
Alexander Stein (2):
arm64: dts: freescale: add initial device tree for TQMa8x
arm64: dts: imx8qm-tqma8qm-mba8x: Disable Cortex-A72 cluster
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8qm-tqma8qm-mba8x.dts | 871 ++++++++++++++++++
.../boot/dts/freescale/imx8qm-tqma8qm.dtsi | 325 +++++++
3 files changed, 1197 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-tqma8qm-mba8x.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-tqma8qm.dtsi
--
2.43.0
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: embedded-controller: Add synology,microp device
From: Markus Probst @ 2026-03-26 13:02 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Krzysztof Kozlowski, Conor Dooley,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Greg Kroah-Hartman, devicetree, linux-kernel,
rust-for-linux
In-Reply-To: <20260325220749.GA17597-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2845 bytes --]
On Wed, 2026-03-25 at 17:07 -0500, Rob Herring wrote:
> On Sat, Mar 21, 2026 at 01:02:22PM +0000, Markus Probst wrote:
> > On Sat, 2026-03-21 at 13:32 +0100, Krzysztof Kozlowski wrote:
> > > On 21/03/2026 13:17, Markus Probst wrote:
> > > > On Sat, 2026-03-21 at 11:21 +0100, Krzysztof Kozlowski wrote:
> > > > > On Fri, Mar 20, 2026 at 11:09:53PM +0100, Markus Probst wrote:
> > > > > > +
> > > > > > +examples:
> > > > > > + - |
> > > > > > + #include <dt-bindings/leds/common.h>
> > > > > > +
> > > > > > + embedded-controller {
> > > > > > + compatible = "synology,microp";
> > > > > > +
> > > > > > + power-led {
> > > > > > + color = <LED_COLOR_ID_BLUE>;
> > > > > > + function = LED_FUNCTION_POWER;
> > > > > > + };
> > > > > > +
> > > > > > + status-led {
> > > > > > + color = <LED_COLOR_ID_MULTI>;
> > > > > > + function = LED_FUNCTION_STATUS;
> > > > > > + };
> > > > >
> > > > > Where are other leds? Binding mentions 4.
> > > > >
> > > > Status and Power leds exist on every Synology NAS model I am aware of.
> > > > But there are models which have additionally a usb or alert led. The
> > > > device nodes for those leds should only be present, if they exist
> > > > physically on the device.
> > >
> > > Then help me to understand - are these different models?
> > Yes, even with different CPU architectures.
> > How much the "microp" device differs is not clear, but the
> > communication protocol is the same.
> > >
> > > EC is not a generic purpose component and is tightly coupled with the
> > > actual board it is being present on. Unless exactly same board is used
> > > in different models (unlikely) then the compatible defines the LEDs and
> > > they are not needed in DT.
> > So for instance "synology,ds923p-microp", "synology,ds723p-microp" etc.
> > ?
> >
> > I can do that, but that would be many.
>
> How many is many?
Estimated 300.
As a side note: I only have 1 model I can test the driver with.
>
> > Having it generic seems more flexible.
>
> Is there firmware for these ECs? If so is it the same or different
> firmware for each device? If the former or the functionality is really
> trivial, then I'd be more comfortable with 1 or a few compatibles.
The firmware is not public and the exact differences between them isn't
documented. The communication protocol is the same though.
>
> Generic means you'll need to add quirk properties when there is some
> difference the OS needs to handle which we'll reject. So stuck with one
> compatible and no way to distinguish different ECs is anything but
> flexible.
Describing the physical leds that are present on the NAS device are not
quirk properties, at least in my definition.
Thanks
- Markus Probst
>
> Rob
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: monaco: extend fastrpc compute cb
From: Srinivas Kandagatla @ 2026-03-26 12:58 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel, Srinivas Kandagatla
For some reason we ended up adding only 4 out of 11 compute cb's for
CDSP, add the missing compute cb. This will also improve the end
user-experience by enabling running multiple AI usecases in parallel.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 49 ++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 10e799dd4a78..884a49c0b019 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -7739,6 +7739,55 @@ compute-cb@4 {
<&apps_smmu 0x1964 0x0400>;
dma-coherent;
};
+
+ compute-cb@5 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <5>;
+ iommus = <&apps_smmu 0x19c5 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@6 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <6>;
+ iommus = <&apps_smmu 0x19c6 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@7 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <7>;
+ iommus = <&apps_smmu 0x19c7 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@8 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <8>;
+ iommus = <&apps_smmu 0x19c8 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@9 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <9>;
+ iommus = <&apps_smmu 0x19c9 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@b {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <0xb>;
+ iommus = <&apps_smmu 0x19cb 0x0400>;
+ dma-coherent;
+ };
+
+ compute-cb@c {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <0xc>;
+ iommus = <&apps_smmu 0x19cc 0x000>;
+ dma-coherent;
+ };
};
};
};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 5/5] PCI: rzg3s-host: Add support for RZ/V2H(P) SoC
From: Claudiu Beznea @ 2026-03-26 12:56 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: Claudiu Beznea, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, John Madieu,
linux-pci, linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CA+V-a8s_Kv5WwocsKy_qBEtZ=0gzN-YbAz3pYjubf_qZVLhBew@mail.gmail.com>
Hi, Prabhakar,
On 3/25/26 13:53, Lad, Prabhakar wrote:
>> from [1]:
>> "For example, if rzg3s_pcie_resets_prepare_and_get() returns -EPROBE_DEFER,
>> the static variable is never decremented. On subsequent probe retries,
>> the variable will be artificially inflated, eventually causing the bounds
>> check to fail and returning a permanent -EINVAL. This would also prevent
>> driver unbind and rebind from working correctly."
>>
> The other alternative would be the below, where we wouldn't need to
> use the num-lanes property but would need a comparison with the DT
> compatible,
Or move rzv2h_num_total_lanes outside of rzv2h_pcie_setup_lanes() and reset it
on failure path.
>
> + for_each_compatible_node(np, NULL, "renesas,r9a09g057-pcie") {
If it's possible I would avoid spreading compatibles though the file but instead
use driver data where possible.
Thank you,
Claudiu
> + if (of_device_is_available(np))
> + count++;
> + }
> + if (!count)
> + return 0;
> +
> + /* If both PCIe channels are enabled configure the LINK_MASTER
> in x2 lane mode.
> + * If only one channel is enabled check the port index and if
> port1 is enabled
> + * configure the LINK_MASTER in x2 lane mode, otherwise keep
> it in x4 lane mode.
> + */
> + if (count == RZV2H_MAX_PCIE_PORTS ||
> + (count == 1 && host->channel == 1))
> + host->link_mode = RZV2H_PCIE_MODE_DUAL_X2;
> + else
> + host->link_mode = RZV2H_PCIE_MODE_SINGLE_X4;
^ permalink raw reply
* Re: [PATCH v5 3/9] arm64: dts: amlogic: t7: Add MMC controller nodes
From: Neil Armstrong @ 2026-03-26 12:56 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-3-d3f182b48e9d@aliel.fr>
On 3/26/26 10:59, Ronald Claveau wrote:
> Add device tree nodes for the three MMC controllers available
> on the Amlogic T7 SoC, using amlogic,meson-axg-mmc as fallback compatible.
> All nodes are disabled by default and should be
> enabled in the board-specific DTS file.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 39 +++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 36d13371f56ba..fe1ced0a58967 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -374,6 +374,45 @@ sec_ao: ao-secure@10220 {
> reg = <0x0 0x10220 0x0 0x140>;
> amlogic,has-chip-id;
> };
> +
> + sd_emmc_a: mmc@88000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x88000 0x0 0x800>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_A>,
> + <&clkc_periphs CLKID_SD_EMMC_A>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_A_SEL>;
> + assigned-clock-parents = <&xtal>;
> + status = "disabled";
> + };
> +
> + sd_emmc_b: mmc@8a000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x8a000 0x0 0x800>;
> + interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_B>,
> + <&clkc_periphs CLKID_SD_EMMC_B>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_B_SEL>;
> + assigned-clock-parents = <&xtal>;
> + status = "disabled";
> + };
> +
> + sd_emmc_c: mmc@8c000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x8c000 0x0 0x800>;
> + interrupts = <GIC_SPI 178 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_C>,
> + <&clkc_periphs CLKID_SD_EMMC_C>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_C_SEL>;
> + assigned-clock-parents = <&xtal>;
> + status = "disabled";
> + };
> };
>
> };
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v5 8/9] dt-bindings: net: wireless: brcm: Add compatible for bcm43752
From: Neil Armstrong @ 2026-03-26 12:55 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Conor Dooley
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-8-d3f182b48e9d@aliel.fr>
On 3/26/26 10:59, Ronald Claveau wrote:
> Add bcm43752 compatible with its bcm4329 compatible fallback.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> index 3be7576787644..81fd3e37452a6 100644
> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml
> @@ -42,6 +42,7 @@ properties:
> - brcm,bcm4356-fmac
> - brcm,bcm4359-fmac
> - brcm,bcm4366-fmac
> + - brcm,bcm43752-fmac
> - cypress,cyw4373-fmac
> - cypress,cyw43012-fmac
> - infineon,cyw43439-fmac
>
I'll apply all the other DT patches, please send this one alone with the [PATCH net-next] prefix so it gets picked by the wireless/net people.
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v5 1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
From: Neil Armstrong @ 2026-03-26 12:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260326-add-emmc-t7-vim4-v5-1-d3f182b48e9d@aliel.fr>
On 3/26/26 10:59, Ronald Claveau wrote:
> These pinctrl nodes are required by the eMMC, SD card and SDIO drivers
> to configure pin muxing at runtime.
>
> - eMMC: control, 4-bit/8-bit data, data strobe and clock gate pins
> - SD card: data, clock, command and clock gate pins
> - SDIO: data, clock, command and clock gate pins
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 98 +++++++++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 6510068bcff92..36d13371f56ba 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -250,6 +250,104 @@ gpio: bank@4000 {
> #gpio-cells = <2>;
> gpio-ranges = <&periphs_pinctrl 0 0 157>;
> };
> +
> + emmc_ctrl_pins: emmc-ctrl {
> + mux-0 {
> + groups = "emmc_cmd";
> + function = "emmc";
> + bias-pull-up;
> + };
> +
> + mux-1 {
> + groups = "emmc_clk";
> + function = "emmc";
> + bias-disable;
> + };
> + };
> +
> + emmc_data_4b_pins: emmc-data-4b {
> + mux {
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_data_8b_pins: emmc-data-8b {
> + mux {
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3",
> + "emmc_nand_d4",
> + "emmc_nand_d5",
> + "emmc_nand_d6",
> + "emmc_nand_d7";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_ds_pins: emmc-ds {
> + mux {
> + groups = "emmc_nand_ds";
> + function = "emmc";
> + bias-pull-down;
> + };
> + };
> +
> + emmc_clk_gate_pins: emmc-clk-gate {
> + mux {
> + groups = "GPIOB_8";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdcard_pins: sdcard {
> + mux {
> + groups = "sdcard_d0",
> + "sdcard_d1",
> + "sdcard_d2",
> + "sdcard_d3",
> + "sdcard_clk",
> + "sdcard_cmd";
> + function = "sdcard";
> + bias-pull-up;
> + };
> + };
> +
> + sdcard_clk_gate_pins: sdcard-clk-gate {
> + mux {
> + groups = "GPIOC_4";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdio_pins: sdio {
> + mux {
> + groups = "sdio_d0",
> + "sdio_d1",
> + "sdio_d2",
> + "sdio_d3",
> + "sdio_clk",
> + "sdio_cmd";
> + function = "sdio";
> + bias-pull-up;
> + };
> + };
> +
> + sdio_clk_gate_pins: sdio-clk-gate {
> + mux {
> + groups = "GPIOX_4";
> + function = "gpio_periphs";
> + bias-pull-up;
> + };
> + };
> };
>
> gpio_intc: interrupt-controller@4080 {
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v2 0/2] mmc: hisilicon: Convert dw-mshc bindings and fix dtbs
From: Wei Xu @ 2026-03-26 12:53 UTC (permalink / raw)
To: Ulf Hansson
Cc: Bhargav Joshi, devicetree, linux-arm-kernel, robh, krzk+dt,
conor+dt, zhangfei.gao, linux-mmc, daniel.baluta, simona.toaca,
d-gole, m-chawdhry, linux-kernel
In-Reply-To: <CAPDyKFq6F3PZgqTtHXZPQPPBvdPhsQPtUVHiZV6X-QXvS42+CA@mail.gmail.com>
Hi Uffe,
On 2026/3/26 20:39, Ulf Hansson wrote:
> On Thu, 26 Mar 2026 at 12:19, Wei Xu <xuwei5@hisilicon.com> wrote:
>>
>> Hi Bhargav,
>>
>> On 2026/3/26 6:54, Bhargav Joshi wrote:
>>> This series converts the Hisilicon dw-mshc text bindings to DT schema
>>> format and cleans up legacy node names in Hisilicon board files.
>>>
>>> While testing the new YAML schema, dtbs_check flagged the hi3660,
>>> hi3670, and hi6220 SoC files for using the non-standard 'dwmmc' node
>>> name prefix. resulting in warnings.
>>>
>>> Patch 1 Convert to DT schema
>>> Patch 2 updates the Hisilicon dtsi files to use standard 'mmc'
>>> node name.
>>>
>>> Changes in v2:
>>> - Patch 1:
>>> - Grouped compatible strings into an enum.
>>> - Replaced raw numbers with proper flags.
>>> - Fixed property order and removed invalid hex values.
>>> - Added explanation for clock order change in commit message.
>>> - Collected Acked-by tag.
>>> - Patch 2:
>>> - No code changes.
>>> - Collected Acked-by and Reviewed-by tags.
>>>
>>> Signed-off-by: Bhargav Joshi <rougueprince47@gmail.com>
>>> ---
>>> Note: this patch is part of the process for applying to GSoC device
>>> tree bindings conversion project #
>>> https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
>>>
>>> - The file is enabled by arm64 defconfig (CONFIG_MMC_DW_K3=y)
>>> - It is used in following
>>> /arch/arm64/boot/dts/hisilicon/hi3660.dtsi
>>> -included by /arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
>>> /arch/arm64/boot/dts/hisilicon/hi3670.dtsi
>>> -included by /arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts
>>>
>>> Bhargav Joshi (2):
>>> dt-bindings: mmc: hisilicon,hi3660-dw-mshc: Convert to DT schema
>>> arm64: dts: hisilicon: Rename dwmmc nodes to mmc
>>>
>>> .../mmc/hisilicon,hi3660-dw-mshc.yaml | 117 ++++++++++++++++++
>>> .../devicetree/bindings/mmc/k3-dw-mshc.txt | 73 -----------
>>> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 +-
>>> arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 4 +-
>>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 6 +-
>>> 5 files changed, 124 insertions(+), 80 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml
>>> delete mode 100644 Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
>>>
>>
>> Series applied to the HiSilicon arm64 dt tree.
>> Thanks!
>>
>> Best Regards,
>> Wei
>
> Usually I pick DT bindings (patch1/2) for mmc via my mmc tree and I
> also just did. Would it be possible for you to drop patch1/2 from your
> tree?
So I will drop them.
Thanks!
Best Regards,
Wei
>
> Kind regards
> Uffe
>
> .
>
^ permalink raw reply
* Re: [PATCH] ARM: dts: renesas: rza2mevb: Drop RTL8211F PHY C22 compatible string
From: Marek Vasut @ 2026-03-26 12:52 UTC (permalink / raw)
To: Geert Uytterhoeven, Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdVwa47N2VsvH8pBkAD215dr3M-qkA0SXed0vhLS2-aoKA@mail.gmail.com>
On 3/26/26 10:45 AM, Geert Uytterhoeven wrote:
Hello Geert,
> On Thu, 26 Mar 2026 at 05:54, Marek Vasut
> <marek.vasut+renesas@mailbox.org> wrote:
>> Realtek RTL8211F PHY schema indicates that compatible string
>> "ethernet-phy-id001c.c916" must not be followed by any other
>
> This is actually RTL8201F / c816; I will fix this while applying.
Ouf ... thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Andrew Lunn @ 2026-03-26 12:47 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
AngeloGioacchino Del Regno, Heiner Kallweit, Russell King,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20260326-add-airoha-an8801-support-v2-4-1a42d6b6050f@collabora.com>
> +static int an8801r_led_blink_set(struct phy_device *phydev, u8 index,
> + unsigned long *delay_on,
> + unsigned long *delay_off)
> +{
...
> + ret = phy_modify_mmd(phydev, MDIO_MMD_VEND2, LED_ON_CTRL(index),
> + LED_ON_EN, blink ? LED_ON_EN : 0);
> + if (ret)
> + return ret;
> +
> + return 0;
Just
return phy_modify_mmd(phydev, MDIO_MMD_VEND2, LED_ON_CTRL(index),
LED_ON_EN, blink ? LED_ON_EN : 0);
> + if (!led_trigger)
> + continue;
> +
> + ret = an8801r_led_hw_control_set(phydev, led_id, led_trigger);
> + if (ret)
> + return ret;
> + }
> + return 0;
> +}
Please take a look at all your functions. Can the last error check be
removed and just use return ret, etc.
> +static int an8801r_of_init_leds(struct phy_device *phydev, u8 *led_cfg)
> +{
> + struct device *dev = &phydev->mdio.dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *leds;
> + u32 function_enum_idx;
> + int ret;
> +
> + if (!np)
> + return 0;
> +
> + /* If devicetree is present, leds configuration is required */
> + leds = of_get_child_by_name(np, "leds");
> + if (!leds)
> + return 0;
> +
> + for_each_available_child_of_node_scoped(leds, led) {
> + u32 led_idx;
> +
> + ret = of_property_read_u32(led, "reg", &led_idx);
> + if (ret)
> + goto out;
> +
> + if (led_idx >= AN8801R_NUM_LEDS) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + ret = of_property_read_u32(led, "function-enumerator",
> + &function_enum_idx);
> + if (ret)
> + function_enum_idx = AN8801R_LED_FN_NONE;
> +
What is this doing? Is this documented in the binding?
> + if (function_enum_idx >= AN8801R_LED_FN_MAX) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + led_cfg[led_idx] = function_enum_idx;
> + }
> +out:
> + of_node_put(leds);
> + return ret;
> +}
> +static int an8801r_read_status(struct phy_device *phydev)
> +{
> + int prev_speed, ret;
> + u32 val;
> +
> + prev_speed = phydev->speed;
> +
> + ret = genphy_read_status(phydev);
> + if (ret)
> + return ret;
> +
> + if (phydev->link && prev_speed != phydev->speed) {
> + val = phydev->speed == SPEED_1000 ?
> + AN8801_BPBUS_LINK_MODE_1000 : 0;
> +
> + return an8801_buckpbus_reg_rmw(phydev,
> + AN8801_BPBUS_REG_LINK_MODE,
> + AN8801_BPBUS_LINK_MODE_1000,
> + val);
> + };
This is unusual. What is it doing? Please add a comment.
Andrew
^ permalink raw reply
* Re: [PATCH v2 0/2] mmc: hisilicon: Convert dw-mshc bindings and fix dtbs
From: Ulf Hansson @ 2026-03-26 12:39 UTC (permalink / raw)
To: Wei Xu
Cc: Bhargav Joshi, devicetree, linux-arm-kernel, robh, krzk+dt,
conor+dt, zhangfei.gao, linux-mmc, daniel.baluta, simona.toaca,
d-gole, m-chawdhry, linux-kernel
In-Reply-To: <69C51640.8070408@hisilicon.com>
On Thu, 26 Mar 2026 at 12:19, Wei Xu <xuwei5@hisilicon.com> wrote:
>
> Hi Bhargav,
>
> On 2026/3/26 6:54, Bhargav Joshi wrote:
> > This series converts the Hisilicon dw-mshc text bindings to DT schema
> > format and cleans up legacy node names in Hisilicon board files.
> >
> > While testing the new YAML schema, dtbs_check flagged the hi3660,
> > hi3670, and hi6220 SoC files for using the non-standard 'dwmmc' node
> > name prefix. resulting in warnings.
> >
> > Patch 1 Convert to DT schema
> > Patch 2 updates the Hisilicon dtsi files to use standard 'mmc'
> > node name.
> >
> > Changes in v2:
> > - Patch 1:
> > - Grouped compatible strings into an enum.
> > - Replaced raw numbers with proper flags.
> > - Fixed property order and removed invalid hex values.
> > - Added explanation for clock order change in commit message.
> > - Collected Acked-by tag.
> > - Patch 2:
> > - No code changes.
> > - Collected Acked-by and Reviewed-by tags.
> >
> > Signed-off-by: Bhargav Joshi <rougueprince47@gmail.com>
> > ---
> > Note: this patch is part of the process for applying to GSoC device
> > tree bindings conversion project #
> > https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
> >
> > - The file is enabled by arm64 defconfig (CONFIG_MMC_DW_K3=y)
> > - It is used in following
> > /arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> > -included by /arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> > /arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> > -included by /arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts
> >
> > Bhargav Joshi (2):
> > dt-bindings: mmc: hisilicon,hi3660-dw-mshc: Convert to DT schema
> > arm64: dts: hisilicon: Rename dwmmc nodes to mmc
> >
> > .../mmc/hisilicon,hi3660-dw-mshc.yaml | 117 ++++++++++++++++++
> > .../devicetree/bindings/mmc/k3-dw-mshc.txt | 73 -----------
> > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 +-
> > arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 4 +-
> > arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 6 +-
> > 5 files changed, 124 insertions(+), 80 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml
> > delete mode 100644 Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
> >
>
> Series applied to the HiSilicon arm64 dt tree.
> Thanks!
>
> Best Regards,
> Wei
Usually I pick DT bindings (patch1/2) for mmc via my mmc tree and I
also just did. Would it be possible for you to drop patch1/2 from your
tree?
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Marek Vasut @ 2026-03-26 12:38 UTC (permalink / raw)
To: Fidelio Lawson, Woojung Huh, UNGLinuxDriver, Andrew Lunn,
Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Chevallier
Cc: netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <20260326-ksz87xx_errata_low_loss_connections-v1-3-79a698f43626@exotec.com>
[-- Attachment #1: Type: text/plain, Size: 5627 bytes --]
On 3/26/26 10:10 AM, Fidelio Lawson wrote:
> +static int ksz8_handle_module3_errata(struct ksz_device *dev)
> +{
> + int ret = 0;
> + const u16 *regs = dev->info->regs;
> + u16 indir_reg = 0x0000;
> + u8 indir_val = 0x00;
> +
> + switch (dev->low_loss_wa_mode) {
> + case KSZ_LOW_LOSS_WA_1:
> + indir_reg = 0x3C;
> + indir_val = 0x15;
> + break;
> + case KSZ_LOW_LOSS_WA_2:
> + indir_reg = 0x4C;
> + indir_val = 0x40;
> + break;
> + default:
> + break;
> + }
> +
> + mutex_lock(&dev->alu_mutex);
> +
> + ret = ksz_write8(dev, regs[REG_IND_CTRL_0], 0xA0);
> +
> + if (!ret)
> + ret = ksz_write8(dev, 0x6F, indir_reg);
> +
> + if (!ret)
> + ret = ksz_write8(dev, regs[REG_IND_BYTE], indir_val);
> +
> + mutex_unlock(&dev->alu_mutex);
> +
> + return ret;
> +}
Since this is configurable from DT, please adjust the bindings and make
the low pass filter bandwidth actually configurable according to the
values supported by the hardware, see this article:
https://microchip.my.site.com/s/article/Solution-for-Using-CAT-5E-or-CAT-6-Short-Cable-with-a-Link-Issue-for-the-KSZ8795-Family
The indirect register (0x4C) is an 8-bit register. The bits [7:6] are
described in the table below.
Low pass filter bandwidth
00 = 90MHz
01 = 62MHz
10 = 55MHz
11 = 44MHz
...
I had this attached patch in my tree for a while, I just never got
around to finishing it, because even with this in place, there was some
packet loss with short cables at low temperatures. Maybe it can help:
From 937278ee6dc0aa46797cc4b2d53078f95b6557a9 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex@nabladev.com>
Date: Mon, 2 Jun 2025 01:42:17 +0200
Subject: [PATCH] net: dsa: microchip: Fix KSZ87xx high quality cable errata
module 3
KSZ87xx may fail to establish link, or may take long time to
establish link, when using high quality > CAT-5 ethernet cables.
This is described in KSZ87xx Errata DS80000687C Module 3:
Module 3: Establishing a link through low loss connections.
The receiver of the embedded PHYs is tuned by default to
support long cable length applications. This was developed
using low quality, high loss cables. Because of this, the
equalizer in the PHY may amplify high amplitude receiver
signals to the point that the signal is distorted internally,
preventing a link from being established.
More detailed description and a more advanced fix is described in
"
Solution for Using CAT-5E or CAT-6 Short Cable with a Link Issue
for the KSZ8795 Family
"
https://microchip.my.site.com/s/article/Solution-for-Using-CAT-5E-or-CAT-6-Short-Cable-with-a-Link-Issue-for-the-KSZ8795-Family
The fix reduces low pass filter bandwidth from 90 MHz to 62 MHz
to block higher frequency components which make it through the
higher quality cables and saturate the receiver amplifier. In
case of even shorter cables, the link equalizer function has to
start from position 0 instead of the default position 0xf to
cater for those cables, configure the equalizer position as well.
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
drivers/net/dsa/microchip/ksz8.c | 33 ++++++++++++++++++++++++++--
drivers/net/dsa/microchip/ksz8_reg.h | 2 +-
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz8.c
b/drivers/net/dsa/microchip/ksz8.c
index 3309c2c172f02..f8716c8d0d375 100644
--- a/drivers/net/dsa/microchip/ksz8.c
+++ b/drivers/net/dsa/microchip/ksz8.c
@@ -1891,10 +1891,39 @@ static int ksz8_handle_global_errata(struct
dsa_switch *ds)
* KSZ879x/KSZ877x/KSZ876x and some EEE link partners may result in
* the link dropping.
*/
- if (dev->info->ksz87xx_eee_link_erratum)
+ if (dev->info->ksz87xx_eee_link_erratum) {
ret = ksz8_ind_write8(dev, TABLE_EEE, REG_IND_EEE_GLOB2_HI, 0);
+ if (ret)
+ return ret;
+ }
- return ret;
+ /*
+ * Module 3: Establishing a link through low loss connections.
+ * The receiver of the embedded PHYs is tuned by default to
+ * support long cable length applications. This was developed
+ * using low quality, high loss cables. Because of this, the
+ * equalizer in the PHY may amplify high amplitude receiver
+ * signals to the point that the signal is distorted internally,
+ * preventing a link from being established.
+ *
+ * More detailed description and a more advanced fix is described in
+ * "
+ * Solution for Using CAT-5E or CAT-6 Short Cable with a Link Issue
+ * for the KSZ8795 Family
+ * "
+ *
https://microchip.my.site.com/s/article/Solution-for-Using-CAT-5E-or-CAT-6-Short-Cable-with-a-Link-Issue-for-the-KSZ8795-Family
+ *
+ * The following two magic writes are the implementation of the
+ * aforementioned workaround.
+ */
+
+ /* Force low pass filter bandwidth from 90 MHz to 62 MHz */
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, 0x4c, 0x40);
+ if (ret)
+ return ret;
+
+ /* Force DSP EQ initial value to 0 */
+ return ksz8_ind_write8(dev, TABLE_LINK_MD, 0x08, 0);
}
int ksz8_enable_stp_addr(struct ksz_device *dev)
diff --git a/drivers/net/dsa/microchip/ksz8_reg.h
b/drivers/net/dsa/microchip/ksz8_reg.h
index 329688603a582..c4897f27c6d1c 100644
--- a/drivers/net/dsa/microchip/ksz8_reg.h
+++ b/drivers/net/dsa/microchip/ksz8_reg.h
@@ -342,7 +342,7 @@
#define TABLE_EEE (TABLE_EEE_V << TABLE_EXT_SELECT_S)
#define TABLE_ACL (TABLE_ACL_V << TABLE_EXT_SELECT_S)
#define TABLE_PME (TABLE_PME_V << TABLE_EXT_SELECT_S)
-#define TABLE_LINK_MD (TABLE_LINK_MD << TABLE_EXT_SELECT_S)
+#define TABLE_LINK_MD (TABLE_LINK_MD_V << TABLE_EXT_SELECT_S)
#define TABLE_READ BIT(4)
#define TABLE_SELECT_S 2
#define TABLE_STATIC_MAC_V 0
--
2.53.0
[-- Attachment #2: 0001-net-dsa-microchip-Fix-KSZ87xx-high-quality-cable-err.patch --]
[-- Type: text/x-patch, Size: 4121 bytes --]
From 937278ee6dc0aa46797cc4b2d53078f95b6557a9 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex@nabladev.com>
Date: Mon, 2 Jun 2025 01:42:17 +0200
Subject: [PATCH] net: dsa: microchip: Fix KSZ87xx high quality cable errata
module 3
KSZ87xx may fail to establish link, or may take long time to
establish link, when using high quality > CAT-5 ethernet cables.
This is described in KSZ87xx Errata DS80000687C Module 3:
Module 3: Establishing a link through low loss connections.
The receiver of the embedded PHYs is tuned by default to
support long cable length applications. This was developed
using low quality, high loss cables. Because of this, the
equalizer in the PHY may amplify high amplitude receiver
signals to the point that the signal is distorted internally,
preventing a link from being established.
More detailed description and a more advanced fix is described in
"
Solution for Using CAT-5E or CAT-6 Short Cable with a Link Issue
for the KSZ8795 Family
"
https://microchip.my.site.com/s/article/Solution-for-Using-CAT-5E-or-CAT-6-Short-Cable-with-a-Link-Issue-for-the-KSZ8795-Family
The fix reduces low pass filter bandwidth from 90 MHz to 62 MHz
to block higher frequency components which make it through the
higher quality cables and saturate the receiver amplifier. In
case of even shorter cables, the link equalizer function has to
start from position 0 instead of the default position 0xf to
cater for those cables, configure the equalizer position as well.
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
drivers/net/dsa/microchip/ksz8.c | 33 ++++++++++++++++++++++++++--
drivers/net/dsa/microchip/ksz8_reg.h | 2 +-
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c
index 3309c2c172f02..f8716c8d0d375 100644
--- a/drivers/net/dsa/microchip/ksz8.c
+++ b/drivers/net/dsa/microchip/ksz8.c
@@ -1891,10 +1891,39 @@ static int ksz8_handle_global_errata(struct dsa_switch *ds)
* KSZ879x/KSZ877x/KSZ876x and some EEE link partners may result in
* the link dropping.
*/
- if (dev->info->ksz87xx_eee_link_erratum)
+ if (dev->info->ksz87xx_eee_link_erratum) {
ret = ksz8_ind_write8(dev, TABLE_EEE, REG_IND_EEE_GLOB2_HI, 0);
+ if (ret)
+ return ret;
+ }
- return ret;
+ /*
+ * Module 3: Establishing a link through low loss connections.
+ * The receiver of the embedded PHYs is tuned by default to
+ * support long cable length applications. This was developed
+ * using low quality, high loss cables. Because of this, the
+ * equalizer in the PHY may amplify high amplitude receiver
+ * signals to the point that the signal is distorted internally,
+ * preventing a link from being established.
+ *
+ * More detailed description and a more advanced fix is described in
+ * "
+ * Solution for Using CAT-5E or CAT-6 Short Cable with a Link Issue
+ * for the KSZ8795 Family
+ * "
+ * https://microchip.my.site.com/s/article/Solution-for-Using-CAT-5E-or-CAT-6-Short-Cable-with-a-Link-Issue-for-the-KSZ8795-Family
+ *
+ * The following two magic writes are the implementation of the
+ * aforementioned workaround.
+ */
+
+ /* Force low pass filter bandwidth from 90 MHz to 62 MHz */
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, 0x4c, 0x40);
+ if (ret)
+ return ret;
+
+ /* Force DSP EQ initial value to 0 */
+ return ksz8_ind_write8(dev, TABLE_LINK_MD, 0x08, 0);
}
int ksz8_enable_stp_addr(struct ksz_device *dev)
diff --git a/drivers/net/dsa/microchip/ksz8_reg.h b/drivers/net/dsa/microchip/ksz8_reg.h
index 329688603a582..c4897f27c6d1c 100644
--- a/drivers/net/dsa/microchip/ksz8_reg.h
+++ b/drivers/net/dsa/microchip/ksz8_reg.h
@@ -342,7 +342,7 @@
#define TABLE_EEE (TABLE_EEE_V << TABLE_EXT_SELECT_S)
#define TABLE_ACL (TABLE_ACL_V << TABLE_EXT_SELECT_S)
#define TABLE_PME (TABLE_PME_V << TABLE_EXT_SELECT_S)
-#define TABLE_LINK_MD (TABLE_LINK_MD << TABLE_EXT_SELECT_S)
+#define TABLE_LINK_MD (TABLE_LINK_MD_V << TABLE_EXT_SELECT_S)
#define TABLE_READ BIT(4)
#define TABLE_SELECT_S 2
#define TABLE_STATIC_MAC_V 0
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: mmc: hisilicon,hi3660-dw-mshc: Convert to DT schema
From: Ulf Hansson @ 2026-03-26 12:34 UTC (permalink / raw)
To: Bhargav Joshi
Cc: devicetree, linux-arm-kernel, xuwei5, robh, krzk+dt, conor+dt,
zhangfei.gao, linux-mmc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry, linux-kernel
In-Reply-To: <20260325225439.68161-2-rougueprince47@gmail.com>
On Wed, 25 Mar 2026 at 23:55, Bhargav Joshi <rougueprince47@gmail.com> wrote:
>
> Convert the Hisilicon DesignWare Mobile Storage Host Controller
> (dw-mshc) bindings from text format to DT schema.
>
> As part of this conversion, the binding file is renamed from
> k3-dw-mshc.txt to hisilicon,hi3660-dw-mshc.yaml to align with compatible
> string naming conventions. Examples have been updated to pass schema
> validation.
>
> Note: synopsys-dw-mshc binding specifies clock names as "biu" followed
> by "ciu". However, this Hisilicon binding reverses the order to 'ciu'
> then 'biu' to match both the legacy text binding and in-kernel Hisilicon
> DTS board files.
>
> Signed-off-by: Bhargav Joshi <rougueprince47@gmail.com>
> Acked-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Applied for next, thanks!
Kind regards
Uffe
> ---
> Changes in v2:
> - Grouped compatible strings into an enum.
> - Replaced raw numbers with proper flags.
> - Fixed property order and removed invalid hex values.
> - Added explanation for clock order change in commit message.
> - Collected Acked-by tag.
>
> .../mmc/hisilicon,hi3660-dw-mshc.yaml | 117 ++++++++++++++++++
> .../devicetree/bindings/mmc/k3-dw-mshc.txt | 73 -----------
> 2 files changed, 117 insertions(+), 73 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml
> delete mode 100644 Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml
> new file mode 100644
> index 000000000000..296bd776488e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml
> @@ -0,0 +1,117 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mmc/hisilicon,hi3660-dw-mshc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Hisilicon specific extensions to the Synopsys Designware Mobile Storage Host Controller
> +
> +maintainers:
> + - Zhangfei Gao <zhangfei.gao@linaro.org>
> +
> +description:
> + The Synopsys designware mobile storage host controller is used to interface
> + a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
> + differences between the core Synopsys dw mshc controller properties described
> + by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific
> + extensions to the Synopsys Designware Mobile Storage Host Controller.
> +
> +allOf:
> + - $ref: /schemas/mmc/synopsys-dw-mshc-common.yaml#
> +
> +properties:
> + compatible:
> + oneOf:
> + - enum:
> + - hisilicon,hi3660-dw-mshc
> + - hisilicon,hi4511-dw-mshc
> + - hisilicon,hi6220-dw-mshc
> + - items:
> + - const: hisilicon,hi3670-dw-mshc
> + - const: hisilicon,hi3660-dw-mshc
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: card interface unit clock
> + - description: bus interface unit clock
> +
> + clock-names:
> + items:
> + - const: ciu
> + - const: biu
> +
> + hisilicon,peripheral-syscon:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: phandle of syscon used to control peripheral.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/hi3620-clock.h>
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + mmc@fcd03000 {
> + compatible = "hisilicon,hi4511-dw-mshc";
> + reg = <0xfcd03000 0x1000>;
> + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&mmc_clock HI3620_SD_CIUCLK>, <&clock HI3620_DDRC_PER_CLK>;
> + clock-names = "ciu", "biu";
> + vmmc-supply = <&ldo12>;
> + fifo-depth = <0x100>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sd_pmx_pins &sd_cfg_func1 &sd_cfg_func2>;
> + bus-width = <4>;
> + disable-wp;
> + cd-gpios = <&gpio10 3 GPIO_ACTIVE_HIGH>;
> + cap-mmc-highspeed;
> + cap-sd-highspeed;
> + };
> +
> + - |
> + #include <dt-bindings/clock/hi6220-clock.h>
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + mmc@f723e000 {
> + compatible = "hisilicon,hi6220-dw-mshc";
> + reg = <0x0 0xf723e000 0x0 0x1000>;
> + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clock_sys HI6220_MMC1_CIUCLK>,
> + <&clock_sys HI6220_MMC1_CLK>;
> + clock-names = "ciu", "biu";
> + bus-width = <4>;
> + disable-wp;
> + cap-sd-highspeed;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + card-detect-delay = <200>;
> + hisilicon,peripheral-syscon = <&ao_ctrl>;
> + cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default", "idle";
> + pinctrl-0 = <&sd_pmx_func &sd_clk_cfg_func &sd_cfg_func>;
> + pinctrl-1 = <&sd_pmx_idle &sd_clk_cfg_idle &sd_cfg_idle>;
> + vqmmc-supply = <&ldo7>;
> + vmmc-supply = <&ldo10>;
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
> deleted file mode 100644
> index 36c4bea675d5..000000000000
> --- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
> +++ /dev/null
> @@ -1,73 +0,0 @@
> -* Hisilicon specific extensions to the Synopsys Designware Mobile
> - Storage Host Controller
> -
> -Read synopsys-dw-mshc.txt for more details
> -
> -The Synopsys designware mobile storage host controller is used to interface
> -a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
> -differences between the core Synopsys dw mshc controller properties described
> -by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific
> -extensions to the Synopsys Designware Mobile Storage Host Controller.
> -
> -Required Properties:
> -
> -* compatible: should be one of the following.
> - - "hisilicon,hi3660-dw-mshc": for controllers with hi3660 specific extensions.
> - - "hisilicon,hi3670-dw-mshc", "hisilicon,hi3660-dw-mshc": for controllers
> - with hi3670 specific extensions.
> - - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions.
> - - "hisilicon,hi6220-dw-mshc": for controllers with hi6220 specific extensions.
> -
> -Optional Properties:
> -- hisilicon,peripheral-syscon: phandle of syscon used to control peripheral.
> -
> -Example:
> -
> - /* for Hi3620 */
> -
> - /* SoC portion */
> - dwmmc_0: dwmmc0@fcd03000 {
> - compatible = "hisilicon,hi4511-dw-mshc";
> - reg = <0xfcd03000 0x1000>;
> - interrupts = <0 16 4>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> - clocks = <&mmc_clock HI3620_SD_CIUCLK>, <&clock HI3620_DDRC_PER_CLK>;
> - clock-names = "ciu", "biu";
> - };
> -
> - /* Board portion */
> - dwmmc0@fcd03000 {
> - vmmc-supply = <&ldo12>;
> - fifo-depth = <0x100>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&sd_pmx_pins &sd_cfg_func1 &sd_cfg_func2>;
> - bus-width = <4>;
> - disable-wp;
> - cd-gpios = <&gpio10 3 0>;
> - cap-mmc-highspeed;
> - cap-sd-highspeed;
> - };
> -
> - /* for Hi6220 */
> -
> - dwmmc_1: dwmmc1@f723e000 {
> - compatible = "hisilicon,hi6220-dw-mshc";
> - bus-width = <0x4>;
> - disable-wp;
> - cap-sd-highspeed;
> - sd-uhs-sdr12;
> - sd-uhs-sdr25;
> - card-detect-delay = <200>;
> - hisilicon,peripheral-syscon = <&ao_ctrl>;
> - reg = <0x0 0xf723e000 0x0 0x1000>;
> - interrupts = <0x0 0x49 0x4>;
> - clocks = <&clock_sys HI6220_MMC1_CIUCLK>, <&clock_sys HI6220_MMC1_CLK>;
> - clock-names = "ciu", "biu";
> - cd-gpios = <&gpio1 0 1>;
> - pinctrl-names = "default", "idle";
> - pinctrl-0 = <&sd_pmx_func &sd_clk_cfg_func &sd_cfg_func>;
> - pinctrl-1 = <&sd_pmx_idle &sd_clk_cfg_idle &sd_cfg_idle>;
> - vqmmc-supply = <&ldo7>;
> - vmmc-supply = <&ldo10>;
> - };
> --
> 2.53.0
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox