* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Neil Armstrong @ 2026-03-30 7:49 UTC (permalink / raw)
To: Bryan O'Donoghue, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <c5278028-dfe9-4d09-970a-a25977967bdd@linaro.org>
On 3/27/26 18:42, Bryan O'Donoghue wrote:
> On 27/03/2026 15:28, Neil Armstrong wrote:
>>> To be frankly honest you can make an argument for it either way. However my honestly held position is analysing other upstream implementations connecting to the PHY means we can't make the PHY device a drivers/phy device - it would have to be a V4L2 device and then for me the question is why is that even required ?
>>
>> This is plain wrong, DT definition is different from software implementation, you can do whatever you want if you describe HW accurately.
>
> I'm not sure what point it is you are trying to make here. Are you trying to say drivers/phy is OK with you but you want an endpoint ? If so, please just say so.
I'm against using the "phys = <>" property in the CAMSS to reference the PHYs, a "PHY" in the classic terminology is tied to a single consumer, and if it can be shared to multiple consumer you must model a mux or whatever in the middle.
The PHY API as an internal software implementation is probably fine, even if it makes implementation of split mode much much harder and doesn't really solve anything, you can just call init()/poweron()/poweroff()/exit() directly from the CSIPHY media callbacks.
>
> I can see an argument for that hence my response to Konrad, I just don't see why its a Qualcomm specific argument and of course understood stuff bubbles up in review, we have a public debate and come to a consensus - that's a good thing.
>
> However, I'd want wider buy-in and understanding that endpoints in the PHYs is a more accurate description of the data-flow.
It is, and it was designed for that, and extensively used in the media DT representation, so I wonder here you would not use it...
In an ideal world, you would add nodes for each CAMSS hw elements and adds port/endpoints links between all nodes to describe the data graph, this would be used to construct the media controller graph, and make it much easier supporting new hardware.
>
> We've been applying DT bindings aplenty without that so far. So we would establish new CSI2 PHY bindings should represent the sensor endpoints.
We've been using a dummy representation of CAMM in a single node with only endpoints connecting to the sensors and hiding all the hardware layout in code, it doesn't scale and makes supporting new HW hard.
I mean this is common sense, why would we continue to stick to the current CAMSS bindings ???
>
> Is that what you want ?
>
>> The CSIPHYs are not tied to a single "consumer" block, they can be connected to different consumers at runtime, which is not something classic PHY devices are designed for. So they are de facto a media element in the dynamic camera pipeline.
>
> The existing CAMSS binding and media graph are not changed by this series.
This is not my point, I don't care about the software implementation at all, I care about accurate hardware representation. Using the "phys = <>" property does not describe hardware accurately.
In other words: The CSIPHY are not connected to CAMSS. This is _not_ true, tying the CSIPHYs to the CAMSS block hides the real data muxing in software.
Please remind DT is used by multiple operating systems, and properly describing hardware in DT will help have good software support over all OSes, not just Linux.
>
>> And actually Rob Herring asked use to define the complete data flow, it was a strong requirement. I don't see why we wouldn't here.
>
> I'm implementing feedback from Rob.
>
> https://lore.kernel.org/linux-media/20250710230846.GA44483-robh@kernel.org/
Where did he ask using the PHY DT bindings ? Is he aware those CSIPHYs are muxed to multiple consumers which are burried in the CAMSS code ?
>
> To me, here is where we stand:
>
> - Individual nodes - we all agree that
> - As sub-nodes - I think the majority agrees this Krzsztof, Dmitry
> I'm fine with it too.
> - drivers/phy - I think we are accepting this is also fine ?
Like I said this adds a supplementary API layer for no reason and will make life harder, but I don't care personally.
> - endpoints should flow into the PHY and then back to the controller
>
> I get that argument. In fact I _like_ that argument at least I like my conception of that argument.
>
> I'll stipulate to that argument meaning then that, new CSI2 PHYs shall include endpoints for this purpose globally.
>
> As I've said before, there's nothing Qualcomm specific about this discussion, really.
There is, because the current Qualcomm CAMSS bindings are insufficient and should be entirely redesigned from the ground up to properly describe the HW.
Neil
>
> ---
> bod
^ permalink raw reply
* [PATCH v5 2/3] pwm: add Andes PWM driver support
From: Ben Zong-You Xie via B4 Relay @ 2026-03-30 7:45 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
In-Reply-To: <20260330-andes-pwm-v5-0-01c59a659d2c@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
Add a driver for the PWM controller found in Andes AE350 platforms and
QiLai SoCs.
The Andes PWM controller features:
- 4 independent channels.
- Dual clock source support (APB clock and external clock) to provide
a flexible range of frequencies.
- Support for normal and inversed polarity.
The driver implements the .apply() and .get_state() callbacks. Since the
clock source of each channel can be selected by programming the
register, clock selection logic is implemented to prioritize the
external clock to maximize the supported period range, falling back to
the APB clock for higher frequency requirements.
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-andes.c | 306 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 317 insertions(+)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 6f3147518376..b82f2c857ada 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -73,6 +73,16 @@ config PWM_AIROHA
To compile this driver as a module, choose M here: the module
will be called pwm-airoha.
+config PWM_ANDES
+ tristate "Andes PWM support"
+ depends on ARCH_ANDES || COMPILE_TEST
+ help
+ Generic PWM framework driver for Andes platform, such as QiLai SoC
+ and AE350 platform.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-andes.
+
config PWM_APPLE
tristate "Apple SoC PWM support"
depends on ARCH_APPLE || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 0dc0d2b69025..858f225289cc 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PWM) += core.o
obj-$(CONFIG_PWM_AB8500) += pwm-ab8500.o
obj-$(CONFIG_PWM_ADP5585) += pwm-adp5585.o
obj-$(CONFIG_PWM_AIROHA) += pwm-airoha.o
+obj-$(CONFIG_PWM_ANDES) += pwm-andes.o
obj-$(CONFIG_PWM_APPLE) += pwm-apple.o
obj-$(CONFIG_PWM_ARGON_FAN_HAT) += pwm-argon-fan-hat.o
obj-$(CONFIG_PWM_ATMEL) += pwm-atmel.o
diff --git a/drivers/pwm/pwm-andes.c b/drivers/pwm/pwm-andes.c
new file mode 100644
index 000000000000..835c8db55987
--- /dev/null
+++ b/drivers/pwm/pwm-andes.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Andes PWM, used in Andes AE350 platform and QiLai SoC
+ *
+ * Copyright (C) 2026 Andes Technology Corporation.
+ *
+ * Limitations:
+ * - When disabling a channel, the current period will not be completed, and the
+ * output will be constant zero.
+ * - The current period will be completed first if reconfiguring.
+ * - Further, if the reconfiguration changes the clock source, the output will
+ * not be the old one nor the new one. And the output will be the new one
+ * until writing to the reload register.
+ * - The hardware can neither do a 0% nor a 100% relative duty cycle.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/math64.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/regmap.h>
+#include <linux/time.h>
+#include <linux/types.h>
+
+#define ANDES_PWM_CH_ENABLE 0x1C
+#define ANDES_PWM_CH_ENABLE_PWM(ch) BIT(3 + (4 * (ch)))
+
+#define ANDES_PWM_CH_CTRL(ch) (0x20 + (0x10 * (ch)))
+#define ANDES_PWM_CH_CTRL_MODE_PWM BIT(2)
+#define ANDES_PWM_CH_CTRL_CLK BIT(3)
+#define ANDES_PWM_CH_CTRL_PARK BIT(4)
+#define ANDES_PWM_CH_CTRL_MASK GENMASK(4, 0)
+
+#define ANDES_PWM_CH_RELOAD(ch) (0x24 + (0x10 * (ch)))
+#define ANDES_PWM_CH_RELOAD_HIGH GENMASK(31, 16)
+#define ANDES_PWM_CH_RELOAD_LOW GENMASK(15, 0)
+
+#define ANDES_PWM_CH_COUNTER(ch) (0x28 + (0x10 * (ch)))
+
+#define ANDES_PWM_CH_MAX 4
+#define ANDES_PWM_CYCLE_MIN 1
+#define ANDES_PWM_CYCLE_MAX 0x10000
+
+struct andes_pwm {
+ struct regmap *regmap;
+ struct clk *pclk;
+ struct clk *extclk;
+ unsigned int pclk_rate;
+ unsigned int extclk_rate;
+};
+
+static const struct regmap_config andes_pwm_regmap_config = {
+ .name = "andes_pwm",
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .pad_bits = 0,
+ .max_register = ANDES_PWM_CH_COUNTER(ANDES_PWM_CH_MAX - 1),
+ .cache_type = REGCACHE_NONE,
+};
+
+static inline struct andes_pwm *to_andes_pwm(struct pwm_chip *chip)
+{
+ return pwmchip_get_drvdata(chip);
+}
+
+static int andes_pwm_enable(struct pwm_chip *chip, unsigned int channel,
+ bool enable)
+{
+ struct andes_pwm *ap = to_andes_pwm(chip);
+
+ return regmap_assign_bits(ap->regmap, ANDES_PWM_CH_ENABLE,
+ ANDES_PWM_CH_ENABLE_PWM(channel), enable);
+}
+
+static int andes_pwm_config(struct pwm_chip *chip, unsigned int channel,
+ const struct pwm_state *state)
+{
+ struct andes_pwm *ap = to_andes_pwm(chip);
+ unsigned int clk_rate = ap->extclk_rate;
+ unsigned int try = 2;
+ u64 high_ns = state->duty_cycle;
+ u64 low_ns = state->period - high_ns;
+ unsigned int ctrl = ANDES_PWM_CH_CTRL_MODE_PWM;
+ u64 high_cycles;
+ u64 low_cycles;
+ u32 reload;
+
+ /*
+ * Reload register for PWM mode:
+ *
+ * 31 : 16 15 : 0
+ * PWM16_Hi | PWM16_Lo
+ *
+ * The high duration is (PWM16_Hi + 1) cycles and the low duration is
+ * (PWM16_Lo + 1) cycles. For a duty cycle of 10 cycles and a total
+ * period of 30 cycles in normal polarity, PWM16_Hi is set to
+ * 9 (10 - 1) and PWM16_Lo to 19 (30 - 10 - 1). Also, PWM16_Hi is set to
+ * 19 and PWM16_Lo is set to 9 in inversed polarity.
+ *
+ * Because the register stores "cycles - 1", the valid range for
+ * each phase is 1 to 65536 (0x10000) cycles. This implies the hardware
+ * cannot achieve a true 0% or 100% duty cycle.
+ *
+ * The controller supports two clock sources: the APB clock and an
+ * external clock. The driver first attempts to use the external clock
+ * to widest possible range of supported periods. If the requests
+ * exceeds the valid range of the register, it falls back to the APB
+ * clock. The request is rejected if the timing cannot be met by either
+ * source.
+ */
+ if (state->polarity == PWM_POLARITY_INVERSED)
+ swap(high_ns, low_ns);
+
+ while (try) {
+ high_cycles = mul_u64_u64_div_u64(clk_rate, high_ns,
+ NSEC_PER_SEC);
+ low_cycles = mul_u64_u64_div_u64(clk_rate, low_ns,
+ NSEC_PER_SEC);
+ if (high_cycles > ANDES_PWM_CYCLE_MAX)
+ high_cycles = ANDES_PWM_CYCLE_MAX;
+
+ if (low_cycles > ANDES_PWM_CYCLE_MAX)
+ low_cycles = ANDES_PWM_CYCLE_MAX;
+
+ if (high_cycles >= ANDES_PWM_CYCLE_MIN &&
+ low_cycles >= ANDES_PWM_CYCLE_MIN)
+ break;
+
+ try--;
+ clk_rate = ap->pclk_rate;
+ }
+
+ /*
+ * try == 0 : no clock is valid
+ * try == 1 : use APB clock
+ * try == 2 : use external clock
+ */
+ if (!try)
+ return -EINVAL;
+
+ /*
+ * If changing the clock source here, the output will not be the old one
+ * nor the new one. And the output will be the new one until writing to
+ * the reload register.
+ */
+ ctrl |= (try == 1) ? ANDES_PWM_CH_CTRL_CLK : 0;
+ ctrl |= (state->polarity == PWM_POLARITY_INVERSED) ?
+ ANDES_PWM_CH_CTRL_PARK : 0;
+ regmap_update_bits(ap->regmap, ANDES_PWM_CH_CTRL(channel),
+ ANDES_PWM_CH_CTRL_MASK, ctrl);
+ reload = FIELD_PREP(ANDES_PWM_CH_RELOAD_HIGH, high_cycles - 1) |
+ FIELD_PREP(ANDES_PWM_CH_RELOAD_LOW, low_cycles - 1);
+
+ return regmap_write(ap->regmap, ANDES_PWM_CH_RELOAD(channel), reload);
+}
+
+static int andes_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ unsigned int channel = pwm->hwpwm;
+ int ret;
+
+ if (!state->enabled) {
+ if (pwm->state.enabled)
+ andes_pwm_enable(chip, channel, false);
+
+ return 0;
+ }
+
+ ret = andes_pwm_config(chip, channel, state);
+ if (ret)
+ return ret;
+
+ return andes_pwm_enable(chip, channel, true);
+}
+
+static int andes_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct andes_pwm *ap = to_andes_pwm(chip);
+ unsigned int channel = pwm->hwpwm;
+ unsigned int ctrl;
+ unsigned int clk_rate;
+ unsigned int reload;
+ u64 high_cycles;
+ u64 low_cycles;
+
+ regmap_read(ap->regmap, ANDES_PWM_CH_CTRL(channel), &ctrl);
+ clk_rate = FIELD_GET(ANDES_PWM_CH_CTRL_CLK, ctrl) ? ap->pclk_rate
+ : ap->extclk_rate;
+ state->enabled = regmap_test_bits(ap->regmap, ANDES_PWM_CH_ENABLE,
+ ANDES_PWM_CH_ENABLE_PWM(channel));
+ state->polarity = regmap_test_bits(ap->regmap,
+ ANDES_PWM_CH_CTRL(channel),
+ ANDES_PWM_CH_CTRL_PARK);
+ regmap_read(ap->regmap, ANDES_PWM_CH_RELOAD(channel), &reload);
+ high_cycles = FIELD_GET(ANDES_PWM_CH_RELOAD_HIGH, reload) + 1;
+ low_cycles = FIELD_GET(ANDES_PWM_CH_RELOAD_LOW, reload) + 1;
+
+ /*
+ * high_cycles and low_cycles are both 16 bits, and NSEC_PER_SEC is 30
+ * bits. Thus, the multiplication is safe from overflow
+ */
+ if (state->polarity == PWM_POLARITY_NORMAL) {
+ state->duty_cycle = DIV_ROUND_UP_ULL(high_cycles * NSEC_PER_SEC,
+ clk_rate);
+ state->period = state->duty_cycle +
+ DIV_ROUND_UP_ULL(low_cycles * NSEC_PER_SEC,
+ clk_rate);
+ } else {
+ state->duty_cycle = DIV_ROUND_UP_ULL(low_cycles * NSEC_PER_SEC,
+ clk_rate);
+ state->period = state->duty_cycle +
+ DIV_ROUND_UP_ULL(high_cycles * NSEC_PER_SEC,
+ clk_rate);
+ }
+
+ return 0;
+}
+
+static const struct pwm_ops andes_pwm_ops = {
+ .apply = andes_pwm_apply,
+ .get_state = andes_pwm_get_state,
+};
+
+static int andes_pwm_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct pwm_chip *chip;
+ struct andes_pwm *ap;
+ void __iomem *reg_base;
+ int ret;
+
+ chip = devm_pwmchip_alloc(dev, ANDES_PWM_CH_MAX, sizeof(*ap));
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
+
+ ap = to_andes_pwm(chip);
+ reg_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(reg_base))
+ return dev_err_probe(dev, PTR_ERR(reg_base),
+ "failed to map I/O space\n");
+
+ ap->pclk = devm_clk_get_enabled(dev, "pclk");
+ if (IS_ERR(ap->pclk))
+ return dev_err_probe(dev, PTR_ERR(ap->pclk),
+ "failed to get APB clock\n");
+
+ ap->extclk = devm_clk_get_optional_enabled(dev, "extclk");
+ if (IS_ERR(ap->extclk))
+ return dev_err_probe(dev, PTR_ERR(ap->extclk),
+ "failed to get external clock\n");
+
+ /*
+ * If the clock rate is greater than 10^9, there may be an overflow when
+ * calculating the cycles in andes_pwm_config()
+ */
+ ap->pclk_rate = clk_get_rate(ap->pclk);
+ if (ap->pclk_rate > NSEC_PER_SEC)
+ ap->pclk = NULL;
+
+ ap->extclk_rate = ap->extclk ? clk_get_rate(ap->extclk) : 0;
+ if (ap->extclk_rate > NSEC_PER_SEC)
+ ap->extclk = NULL;
+
+ if (!ap->pclk && !ap->extclk)
+ return dev_err_probe(dev, -EINVAL, "clocks are out of range\n");
+
+ ap->regmap = devm_regmap_init_mmio(dev, reg_base,
+ &andes_pwm_regmap_config);
+ if (IS_ERR(ap->regmap)) {
+ return dev_err_probe(dev, PTR_ERR(ap->regmap),
+ "failed to initialize regmap\n");
+ }
+
+ chip->ops = &andes_pwm_ops;
+ ret = devm_pwmchip_add(dev, chip);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to add pwm chip\n");
+
+ return 0;
+}
+
+static const struct of_device_id andes_pwm_of_match[] = {
+ { .compatible = "andestech,ae350-pwm" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, andes_pwm_of_match);
+
+static struct platform_driver andes_pwm_driver = {
+ .driver = {
+ .name = "andes_pwm",
+ .of_match_table = andes_pwm_of_match,
+ },
+ .probe = andes_pwm_probe,
+};
+module_platform_driver(andes_pwm_driver);
+
+MODULE_AUTHOR("Ben Zong-You Xie <ben717@andestech.com>");
+MODULE_DESCRIPTION("Andes PWM driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v5 3/3] MAINTAINERS: add an entry for Andes PWM driver
From: Ben Zong-You Xie via B4 Relay @ 2026-03-30 7:45 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
In-Reply-To: <20260330-andes-pwm-v5-0-01c59a659d2c@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
Add an entry for the Andes PWM driver to the MAINTAINERS file.
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 708c050ac397..72eedd1a3428 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1866,6 +1866,12 @@ S: Supported
F: Documentation/devicetree/bindings/spi/andestech,ae350-spi.yaml
F: drivers/spi/spi-atcspi200.c
+ANDES PWM DRIVER
+M: Ben Zong-You Xie <ben717@andestech.com>
+S: Supported
+F: Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
+F: drivers/pwm/pwm-andes.c
+
ANDROID DRIVERS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Arve Hjønnevåg <arve@android.com>
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/3] pwm: add support for Andes platform
From: Ben Zong-You Xie via B4 Relay @ 2026-03-30 7:45 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
The ATCPIT100 is a set of compact multi-function timers, which can be
a simple timer or PWM, or a combination of the timer and the PWM. This
IP block is a core component of the Andes AE350 platform, which serves
as a reference architecture for SoC designs. The QiLai SoC also
integrates this controller.
This device driver was previously part of the Linux Kernel, and the
compatible was its IP name "andestech,atcpit100". However, the driver
and its binding were removed due to the deprecation of the NDS32
architecture [1]. Although Andes now dedicates our effort on RISC-V,
ATCPIT100 is still one of our peripheral IPs, and that's why we are
re-introducing it now. Since only using the IP block name as the
compatible is forbidden now, change the compatible to
"andestech,ae350-pwm" and "andestech,qilai-pwm".
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aec499c75cf8e0b599be4d559e6922b613085f8f
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
Changes in v5:
- Rebased on ukleinek/pwm/for-next
- (1/4)
- Added Rob's reviewed-by tag.
- Link to v4: https://patch.msgid.link/20260204-andes-pwm-v4-0-67016bb13555@andestech.com
Changes in v4:
- Updated cover letter title and its commit message.
- (1/3)
- Updated the compatibles and the binding file name.
- Added the description to the binding.
- Corrected device register size.
- Dropped the changes to the MAINTAINERS file.
- (2/3)
- Updated the driver name.
- Made the driver support inversed polarity.
- Changed the clock selection algorithm.
- Made the configuration depend on ARCH_ANDES, instead of RISCV. (Krzysztof)
- Dropped the changes to the MAINTAINERS file.
- (3/3) (new)
- Collected all changes to the MAINTAINERS file into a single patch.
- Link to v3: https://patch.msgid.link/20250123193534.874256-1-ben717@andestech.com
Changes in v3:
- (1/2):
- modified the compatible string. (Krzysztof)
- (2/2):
- added a check for the clock rate to prevent the overflow warning.
(kernel test robot)
- removed the unnecessary check in .apply(). (kernel test robot)
- Link to v2: https://patch.msgid.link/20241202060147.1271264-1-ben717@andestech.com
Changes in v2:
- (1/2):
- changed "title" in the yaml file.
- removed vendor-specific property, and added clocks property.
- (2/2):
- added a description for hardware limitations. (Uwe)
- switched the clock parent depending on the requested setting
instead of statically configuring the clock source in DT. (Uwe)
- Link to v1: https://patch.msgid.link/20241028102721.1961289-1-ben717@andestech.com
---
Ben Zong-You Xie (3):
dt-bindings: pwm: add support for AE350 PWM controller
pwm: add Andes PWM driver support
MAINTAINERS: add an entry for Andes PWM driver
.../bindings/pwm/andestech,ae350-pwm.yaml | 61 ++++
MAINTAINERS | 6 +
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-andes.c | 306 +++++++++++++++++++++
5 files changed, 384 insertions(+)
---
base-commit: aa8f35172ab66c57d4355a8c4e28d05b44c938e3
change-id: 20260204-andes-pwm-10ea6611c3cf
Best regards,
--
Ben Zong-You Xie <ben717@andestech.com>
^ permalink raw reply
* [PATCH v5 1/3] dt-bindings: pwm: add support for AE350 PWM controller
From: Ben Zong-You Xie via B4 Relay @ 2026-03-30 7:45 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
In-Reply-To: <20260330-andes-pwm-v5-0-01c59a659d2c@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
The ATCPIT100 is a set of compact multi-function timers, which can be
used as pulse width modulators (PWM) as well as simple timers.
ATCPIT100 supports up to 4 PIT channels, and each PIT channel may be
configured as a simple timer or PWM, or a combination of the timer and
the PWM. This IP block is a core component of the Andes AE350 platform,
which serves as a reference architecture for SoC designs. The QiLai SoC
also integrates this controller.
The binding introduces the following compatible strings:
- "andestech,qilai-pwm": For the implementation integrated into the
Andes QiLai SoC.
- "andestech,ae350-pwm": As a fallback compatible string representing
the base IP design used across the AE350 platform architecture.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
.../bindings/pwm/andestech,ae350-pwm.yaml | 61 ++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml b/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
new file mode 100644
index 000000000000..287f3c62965f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/andestech,ae350-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Andes PWM controller on AE350 platform
+
+description:
+ This controller has 4 channels and two clock sources. Each channel can
+ switch the clock source by programming the corresponding register.
+
+maintainers:
+ - Ben Zong-You Xie <ben717@andestech.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - andestech,qilai-pwm
+ - const: andestech,ae350-pwm
+ - const: andestech,ae350-pwm
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+ clocks:
+ items:
+ - description: APB bus clock
+ - description: External clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: extclk
+
+required:
+ - compatible
+ - reg
+ - "#pwm-cells"
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm@f0400000 {
+ compatible = "andestech,ae350-pwm";
+ reg = <0xf0400000 0x100000>;
+ #pwm-cells = <3>;
+ clocks = <&pclk>, <&extclk>;
+ clock-names = "pclk", "extclk";
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 7/9] regulator: mt6392: Add support for MT6392 regulator
From: Luca Leonardo Scorcia @ 2026-03-30 7:39 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Gary Bisson, Louis-Alexis Eyraud, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <CAGXv+5GmDtrtFHJXs+fDyF+dZ5YW-TSEqXnPs2xCH8cu-Xcn9w@mail.gmail.com>
Il giorno gio 19 mar 2026 alle ore 06:04 Chen-Yu Tsai
<wenst@chromium.org> ha scritto:
> If this PMIC is anything like the MT6358, then it has 0.01V fine
> tuning for most if not all the LDOs. It is sometimes needed as
> a rail may have a 0.04V boost that would otherwise be invisible
> to the system. And then if you have something like 3.04V set in
> the DT constraints, you end up with something the regulator driver
> doesn't support, but the hardware does.
>
> Please see how it's done in the MT6358 driver. I spent a lot of
> time on that driver to make it actually support the full range
> of voltages, and describing the supplies.
>
I had a good look at the datasheet (MT6392 PMIC Datasheet v1.0 08 Dec.
2016) and unfortunately I did not see any fine tuning option in there.
I'm sure this data sheet is not perfect as it's missing some regulator
registers that are clearly used in the Android sources, but there's no
mention of fine tuning in that code either. I guess it does not have
that capability.
I will shortly submit v4 that hopefully addresses the rest of the comments.
Thanks for your help!
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
^ permalink raw reply
* Re: [PATCH] dt-bindings: rtc: moxa,moxart-rtc: convert to json-schema
From: Krzysztof Kozlowski @ 2026-03-30 7:34 UTC (permalink / raw)
To: Serban-Pascu Robert
Cc: alexandre.belloni, robh, krzk+dt, conor+dt, devicetree, linux-rtc,
linux-kernel, daniel.baluta
In-Reply-To: <20260329184615.454887-1-robyserbanpascu06@gmail.com>
On Sun, Mar 29, 2026 at 09:46:15PM +0300, Serban-Pascu Robert wrote:
> Convert the MOXA ART real-time clock text binding to DT schema.
>
> Signed-off-by: Serban-Pascu Robert <robyserbanpascu06@gmail.com>
> ---
> .../bindings/rtc/moxa,moxart-rtc.txt | 17 --------
> .../bindings/rtc/moxa,moxart-rtc.yaml | 43 +++++++++++++++++++
Is this another part of GSoC or independent try to hop-on the same bus?
I am asking because in both cases I expect you to follow GSoC
guidelines.
And this was not tested - you have clear warnings in dtbs for deprecated
properties.
This is not a trivial binding and you were supposed to do a detailed
check in git history and in all existing sources.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 4/4] riscv: dts: andes: qilai: add I2C controller
From: Ben Zong-You Xie via B4 Relay @ 2026-03-30 7:30 UTC (permalink / raw)
To: Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-i2c, devicetree, linux-kernel, linux-riscv,
Ben Zong-You Xie
In-Reply-To: <20260330-atciic100-v4-0-d40822f63e4e@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
Add the I2C node to QiLai DTS.
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
arch/riscv/boot/dts/andes/qilai.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/riscv/boot/dts/andes/qilai.dtsi b/arch/riscv/boot/dts/andes/qilai.dtsi
index de3de32f8c39..8b40f4d7f8d5 100644
--- a/arch/riscv/boot/dts/andes/qilai.dtsi
+++ b/arch/riscv/boot/dts/andes/qilai.dtsi
@@ -182,5 +182,12 @@ uart0: serial@30300000 {
reg-io-width = <4>;
no-loopback-test;
};
+
+ i2c: i2c@30800000 {
+ compatible = "andestech,qilai-i2c",
+ "andestech,ae350-i2c";
+ reg = <0x0 0x30800000 0x0 0x100000>;
+ interrupts = <6 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/4] MAINTAINERS: add an entry for Andes I2C driver
From: Ben Zong-You Xie via B4 Relay @ 2026-03-30 7:30 UTC (permalink / raw)
To: Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-i2c, devicetree, linux-kernel, linux-riscv,
Ben Zong-You Xie
In-Reply-To: <20260330-atciic100-v4-0-d40822f63e4e@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
Add an entry for the Andes I2C driver to the MAINTAINERS file.
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7d10988cbc62..7272ebe7a22b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1863,6 +1863,12 @@ S: Supported
F: Documentation/devicetree/bindings/spi/andestech,ae350-spi.yaml
F: drivers/spi/spi-atcspi200.c
+ANDES I2C DRIVER
+M: Ben Zong-You Xie <ben717@andestech.com>
+S: Supported
+F: Documentation/devicetree/bindings/i2c/andestech,ae350-i2c.yaml
+F: drivers/i2c/busses/i2c-andes.c
+
ANDROID DRIVERS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Arve Hjønnevåg <arve@android.com>
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/4] dt-bindings: i2c: add support for AE350 I2C controller
From: Ben Zong-You Xie via B4 Relay @ 2026-03-30 7:30 UTC (permalink / raw)
To: Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-i2c, devicetree, linux-kernel, linux-riscv,
Ben Zong-You Xie, Conor Dooley
In-Reply-To: <20260330-atciic100-v4-0-d40822f63e4e@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
Document device tree bindings for the I2C controller on Andes AE350
platform.
The ATCIIC100 is a dedicated I2C controller IP developed by
Andes Technology. This IP block is a core component of the Andes
AE350 platform, which serves as a reference architecture for SoC
designs. The QiLai SoC also integrates this I2C controller.
The binding introduces the following compatible strings:
- "andestech,qilai-i2c": For the implementation integrated into the
Andes QiLai SoC.
- "andestech,ae350-i2c": As a fallback compatible string representing
the base IP design used across the AE350 platform architecture.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
.../bindings/i2c/andestech,ae350-i2c.yaml | 45 ++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/andestech,ae350-i2c.yaml b/Documentation/devicetree/bindings/i2c/andestech,ae350-i2c.yaml
new file mode 100644
index 000000000000..59a521fb249b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/andestech,ae350-i2c.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/andestech,ae350-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Andes I2C controller on AE350 platform
+
+maintainers:
+ - Ben Zong-You Xie <ben717@andestech.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - andestech,qilai-i2c
+ - const: andestech,ae350-i2c
+ - const: andestech,ae350-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c@f0a00000 {
+ compatible = "andestech,ae350-i2c";
+ reg = <0xf0a00000 0x100000>;
+ interrupts = <6 IRQ_TYPE_LEVEL_HIGH>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/4] i2c: add Andes I2C driver support
From: Ben Zong-You Xie via B4 Relay @ 2026-03-30 7:30 UTC (permalink / raw)
To: Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-i2c, devicetree, linux-kernel, linux-riscv,
Ben Zong-You Xie
In-Reply-To: <20260330-atciic100-v4-0-d40822f63e4e@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
Add support for Andes I2C driver. Andes I2C can act as either a
controller or a target, depending on the control register settings. Now,
we only support controller mode.
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
drivers/i2c/busses/Kconfig | 10 ++
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-andes.c | 341 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 352 insertions(+)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 7cb6b9b864a7..6aaa5a1223c2 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -446,6 +446,16 @@ config I2C_AT91_SLAVE_EXPERIMENTAL
- There are some mismatches with a SAMA5D4 as slave and a SAMA5D2 as
master.
+config I2C_ANDES
+ tristate "Andes I2C Controller"
+ depends on ARCH_ANDES || COMPILE_TEST
+ help
+ If you say yes to this option, support will be included for the
+ Andes I2C controller.
+
+ This support is also available as a module. If so, the module
+ will be called i2c-andes.
+
config I2C_AU1550
tristate "Au1550/Au1200/Au1300 SMBus interface"
depends on MIPS_ALCHEMY
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 547123ab351f..89d85d10f8d2 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_I2C_ASPEED) += i2c-aspeed.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
i2c-at91-y := i2c-at91-core.o i2c-at91-master.o
i2c-at91-$(CONFIG_I2C_AT91_SLAVE_EXPERIMENTAL) += i2c-at91-slave.o
+obj-$(CONFIG_I2C_ANDES) += i2c-andes.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_AXXIA) += i2c-axxia.o
obj-$(CONFIG_I2C_BCM2835) += i2c-bcm2835.o
diff --git a/drivers/i2c/busses/i2c-andes.c b/drivers/i2c/busses/i2c-andes.c
new file mode 100644
index 000000000000..5f135d8c9b13
--- /dev/null
+++ b/drivers/i2c/busses/i2c-andes.c
@@ -0,0 +1,341 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for Andes I2C controller, used in Andes AE350 platform and QiLai SoC
+ *
+ * Copyright (C) 2026 Andes Technology Corporation.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/completion.h>
+#include <linux/iopoll.h>
+#include <linux/i2c.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/spinlock.h>
+
+#define ANDES_I2C_ID_REG 0x0
+#define ANDES_I2C_ID_MASK GENMASK(31, 8)
+#define ANDES_I2C_ID 0x020210
+
+#define ANDES_I2C_CFG_REG 0x10
+#define ANDES_I2C_CFG_FIFOSIZE GENMASK(1, 0)
+
+#define ANDES_I2C_INTEN_REG 0x14
+#define ANDES_I2C_INTEN_FIFO_EMPTY BIT(0)
+#define ANDES_I2C_INTEN_FIFO_FULL BIT(1)
+#define ANDES_I2C_INTEN_CMPL BIT(9)
+
+#define ANDES_I2C_STATUS_REG 0x18
+#define ANDES_I2C_STATUS_FIFO_EMPTY BIT(0)
+#define ANDES_I2C_STATUS_FIFO_FULL BIT(1)
+#define ANDES_I2C_STATUS_ADDR_HIT BIT(3)
+#define ANDES_I2C_STATUS_CMPL BIT(9)
+#define ANDES_I2C_STATUS_W1C GENMASK(9, 3)
+
+#define ANDES_I2C_ADDR_REG 0x1C
+
+#define ANDES_I2C_DATA_REG 0x20
+
+#define ANDES_I2C_CTRL_REG 0x24
+#define ANDES_I2C_CTRL_DATA_CNT GENMASK(7, 0)
+#define ANDES_I2C_CTRL_DIR BIT(8)
+#define ANDES_I2C_CTRL_PHASE GENMASK(12, 9)
+
+#define ANDES_I2C_CMD_REG 0x28
+#define ANDES_I2C_CMD_ACTION GENMASK(2, 0)
+#define ANDES_I2C_CMD_TRANS BIT(0)
+
+#define ANDES_I2C_SETUP_REG 0x2C
+#define ANDES_I2C_SETUP_IICEN BIT(0)
+#define ANDES_I2C_SETUP_REQ BIT(2)
+
+#define ANDES_I2C_TPM_REG 0x30
+
+#define ANDES_I2C_TIMEOUT_US 400000
+#define ANDES_I2C_TIMEOUT usecs_to_jiffies(ANDES_I2C_TIMEOUT_US)
+
+#define ANDES_I2C_MAX_DATA_LEN 256
+
+struct andes_i2c {
+ struct i2c_adapter adap;
+ struct completion completion;
+ spinlock_t lock;
+ struct regmap *map;
+ u8 *buf;
+ unsigned int fifo_size;
+ int irq;
+ u16 buf_len;
+ bool addr_hit;
+ bool xfer_done;
+};
+
+static const struct regmap_config andes_i2c_regmap_config = {
+ .name = "andes_i2c",
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .pad_bits = 0,
+ .max_register = ANDES_I2C_TPM_REG,
+ .cache_type = REGCACHE_NONE,
+};
+
+static void andes_i2c_xfer_common(struct andes_i2c *i2c, u32 status)
+{
+ unsigned long flags;
+ unsigned int fsize = i2c->fifo_size;
+ unsigned int val;
+
+ spin_lock_irqsave(&i2c->lock, flags);
+ if (status & ANDES_I2C_STATUS_FIFO_EMPTY) {
+ /* Disable the FIFO empty interrupt for the last write */
+ if (i2c->buf_len <= fsize) {
+ fsize = i2c->buf_len;
+ regmap_clear_bits(i2c->map, ANDES_I2C_INTEN_REG,
+ ANDES_I2C_INTEN_FIFO_EMPTY);
+ }
+
+ while (fsize--) {
+ val = *i2c->buf++;
+ regmap_write(i2c->map, ANDES_I2C_DATA_REG, val);
+ i2c->buf_len--;
+ }
+ } else if (status & ANDES_I2C_STATUS_FIFO_FULL) {
+ while (fsize--) {
+ regmap_read(i2c->map, ANDES_I2C_DATA_REG, &val);
+ *i2c->buf++ = (u8)val;
+ i2c->buf_len--;
+ }
+ }
+
+ if (status & ANDES_I2C_STATUS_CMPL) {
+ i2c->xfer_done = true;
+ if (status & ANDES_I2C_STATUS_ADDR_HIT)
+ i2c->addr_hit = true;
+
+ /* Write 1 to clear the status */
+ regmap_set_bits(i2c->map, ANDES_I2C_STATUS_REG,
+ ANDES_I2C_STATUS_W1C);
+
+ /* For the last read, retrieve all remaining data in FIFO. */
+ while (i2c->buf_len > 0) {
+ regmap_read(i2c->map, ANDES_I2C_DATA_REG, &val);
+ *i2c->buf++ = (u8)val;
+ i2c->buf_len--;
+ }
+ }
+
+ spin_unlock_irqrestore(&i2c->lock, flags);
+}
+
+static irqreturn_t andes_i2c_irq_handler(int irq, void *data)
+{
+ struct andes_i2c *i2c = data;
+ u32 i2c_status;
+
+ regmap_read(i2c->map, ANDES_I2C_STATUS_REG, &i2c_status);
+ andes_i2c_xfer_common(i2c, i2c_status);
+ if (i2c->xfer_done)
+ complete(&i2c->completion);
+
+ return IRQ_HANDLED;
+}
+
+static int andes_i2c_xfer_wait(struct andes_i2c *i2c, struct i2c_msg *msg)
+{
+ unsigned int mask;
+ unsigned int i2c_ctrl;
+
+ /*
+ * Set the data count. If there are 256 bytes to be transmitted, write
+ * zero to the data count field.
+ */
+ regmap_update_bits(i2c->map, ANDES_I2C_CTRL_REG,
+ ANDES_I2C_CTRL_DATA_CNT,
+ FIELD_PREP(ANDES_I2C_CTRL_DATA_CNT, i2c->buf_len));
+
+ regmap_set_bits(i2c->map, ANDES_I2C_CTRL_REG, ANDES_I2C_CTRL_PHASE);
+ if (msg->flags & I2C_M_RD)
+ regmap_set_bits(i2c->map, ANDES_I2C_CTRL_REG,
+ ANDES_I2C_CTRL_DIR);
+ else
+ regmap_clear_bits(i2c->map, ANDES_I2C_CTRL_REG,
+ ANDES_I2C_CTRL_DIR);
+
+ regmap_write(i2c->map, ANDES_I2C_ADDR_REG, msg->addr);
+
+ if (i2c->irq >= 0) {
+ mask = ANDES_I2C_INTEN_CMPL;
+ mask |= (msg->flags & I2C_M_RD) ? ANDES_I2C_INTEN_FIFO_FULL
+ : ANDES_I2C_INTEN_FIFO_EMPTY;
+ regmap_set_bits(i2c->map, ANDES_I2C_INTEN_REG, mask);
+ }
+
+ regmap_set_bits(i2c->map, ANDES_I2C_CMD_REG, ANDES_I2C_CMD_TRANS);
+ if (i2c->irq >= 0) {
+ unsigned long time_left;
+
+ time_left = wait_for_completion_timeout(&i2c->completion,
+ ANDES_I2C_TIMEOUT);
+ if (!time_left)
+ return -ETIMEDOUT;
+
+ if (!i2c->addr_hit)
+ return -ENXIO;
+
+ regmap_write(i2c->map, ANDES_I2C_INTEN_REG, 0);
+ reinit_completion(&i2c->completion);
+ } else {
+ unsigned int val;
+ int ret;
+
+ mask = ANDES_I2C_STATUS_CMPL;
+ mask |= (msg->flags & I2C_M_RD) ? ANDES_I2C_STATUS_FIFO_FULL
+ : ANDES_I2C_STATUS_FIFO_EMPTY;
+ while (!i2c->xfer_done) {
+ ret = regmap_read_poll_timeout(i2c->map,
+ ANDES_I2C_STATUS_REG,
+ val, val & mask, 2000,
+ ANDES_I2C_TIMEOUT_US);
+ if (ret)
+ return ret;
+
+ andes_i2c_xfer_common(i2c, val);
+ }
+
+ if (!i2c->addr_hit)
+ return -ENXIO;
+ }
+
+ /* Check if all data is successfully transmitted */
+ regmap_read(i2c->map, ANDES_I2C_CTRL_REG, &i2c_ctrl);
+ if (FIELD_GET(ANDES_I2C_CTRL_DATA_CNT, i2c_ctrl))
+ return -EIO;
+
+ return 0;
+}
+
+static int andes_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msg,
+ int num)
+{
+ int i;
+ struct i2c_msg *m;
+ struct andes_i2c *i2c = i2c_get_adapdata(adap);
+ int ret;
+
+ for (i = 0; i < num; i++) {
+ m = &msg[i];
+ i2c->addr_hit = false;
+ i2c->buf = m->buf;
+ i2c->buf_len = m->len;
+ i2c->xfer_done = false;
+ ret = andes_i2c_xfer_wait(i2c, m);
+ if (ret < 0)
+ return ret;
+ }
+
+ return num;
+}
+
+static u32 andes_i2c_func(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+}
+
+static struct i2c_algorithm andes_i2c_algo = {
+ .xfer = andes_i2c_xfer,
+ .functionality = andes_i2c_func,
+};
+
+static const struct i2c_adapter_quirks andes_i2c_quirks = {
+ .flags = I2C_AQ_NO_ZERO_LEN,
+ .max_write_len = ANDES_I2C_MAX_DATA_LEN,
+ .max_read_len = ANDES_I2C_MAX_DATA_LEN,
+};
+
+static int andes_i2c_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct andes_i2c *i2c;
+ void __iomem *reg_base;
+ u32 i2c_id;
+ int ret;
+ struct i2c_adapter *adap;
+
+ i2c = devm_kzalloc(dev, sizeof(*i2c), GFP_KERNEL);
+ if (!i2c)
+ return -ENOMEM;
+
+ reg_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(reg_base))
+ return dev_err_probe(dev, PTR_ERR(reg_base),
+ "failed to map I/O space\n");
+
+ i2c->map = devm_regmap_init_mmio(dev, reg_base,
+ &andes_i2c_regmap_config);
+ if (IS_ERR(i2c->map))
+ return dev_err_probe(dev, PTR_ERR(i2c->map),
+ "failed to initialize regmap\n");
+
+ regmap_read(i2c->map, ANDES_I2C_ID_REG, &i2c_id);
+ if (FIELD_GET(ANDES_I2C_ID_MASK, i2c_id) != ANDES_I2C_ID)
+ return dev_err_probe(dev, -ENODEV, "unmatched hardware ID 0x%x\n",
+ i2c_id);
+
+ i2c->irq = platform_get_irq(pdev, 0);
+ if (i2c->irq >= 0) {
+ ret = devm_request_irq(dev, i2c->irq, andes_i2c_irq_handler, 0,
+ dev_name(dev), i2c);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "unable to request IRQ %d\n",
+ i2c->irq);
+ } else {
+ dev_warn(dev, "no IRQ resource, falling back to poll mode\n");
+ }
+
+ spin_lock_init(&i2c->lock);
+ init_completion(&i2c->completion);
+ adap = &i2c->adap;
+ strscpy(adap->name, pdev->name, sizeof(adap->name));
+ adap->algo = &andes_i2c_algo;
+ adap->class = I2C_CLASS_HWMON;
+ adap->dev.parent = dev;
+ adap->dev.of_node = dev->of_node;
+ adap->owner = THIS_MODULE;
+ adap->quirks = &andes_i2c_quirks;
+ adap->retries = 1;
+ adap->timeout = ANDES_I2C_TIMEOUT;
+ i2c_set_adapdata(adap, i2c);
+ platform_set_drvdata(pdev, i2c);
+ ret = devm_i2c_add_adapter(dev, adap);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to add adapter\n");
+
+ regmap_read(i2c->map, ANDES_I2C_CFG_REG, &i2c->fifo_size);
+ i2c->fifo_size = 2 << FIELD_GET(ANDES_I2C_CFG_FIFOSIZE, i2c->fifo_size);
+
+ regmap_set_bits(i2c->map, ANDES_I2C_SETUP_REG,
+ ANDES_I2C_SETUP_IICEN | ANDES_I2C_SETUP_REQ);
+ return 0;
+}
+
+static const struct of_device_id andes_i2c_of_match[] = {
+ { .compatible = "andestech,ae350-i2c" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, andes_i2c_of_match);
+
+static struct platform_driver andes_i2c_platform_driver = {
+ .driver = {
+ .name = "andes_i2c",
+ .of_match_table = andes_i2c_of_match,
+ },
+ .probe = andes_i2c_probe,
+};
+
+module_platform_driver(andes_i2c_platform_driver);
+
+MODULE_AUTHOR("Ben Zong-You Xie <ben717@andestech.com>");
+MODULE_DESCRIPTION("Andes I2C controller driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/4] i2c: add support for Andes platform
From: Ben Zong-You Xie via B4 Relay @ 2026-03-30 7:30 UTC (permalink / raw)
To: Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: linux-i2c, devicetree, linux-kernel, linux-riscv,
Ben Zong-You Xie, Conor Dooley
This patch series adds I2C support to Andes platform, such as AE350 and
QiLai SoC.
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
Changes in v4:
- Rebased on andi.shyti/i2c/i2c-host-next.
- (1/4)
- Added Conor's acked by tag.
- Link to v3: https://patch.msgid.link/20260128-atciic100-v3-0-8c002fcc2bb4@andestech.com
Changes in v3:
- (1/4)
- Rewrote the commit message to provide a detailed hardware
description and explain the relationship between the ATCIIC100 IP,
the AE350 platform, and the QiLai SoC. (Krzysztof)
- Link to v2: https://patch.msgid.link/20260122-atciic100-v2-0-7559136d07cf@andestech.com
Changes in v2:
- ATCIIC100 is the hardware name for the Andes I2C controller and was used
throughout v1. However, since Device Tree bindings should reflect the hardware
identity and driver/config naming typically follows the i2c-<soc/platform>
convention, this version replaces occurrences of "atciic100" with more
appropriate names, such as "i2c-andes" or "andes_i2c," to align with upstream
standards.
- Updated cover letter title and the description.
- Rebased on andi.shyti/i2c/i2c-host-next.
- (1/4)
- Updated the title and the description of the patch.
- Specified what the hardware is, and modify the title and compatibles. (Krzysztof)
- Corrected device register size.
- (2/4)
- Updated the title and the description of the patch.
- Replaced the readl/writel operations with regmap APIs.
- Replaced all occurrences of atciic100 with proper names.
- Used module_platform_driver() to initialize. (Andi)
- Moved CONFIG_I2C_ANDES (CONFIG_I2C_ATCIIC100 in v1) to the
"Embedded system I2C/SMBus host controller drivers" section.
- Made CONFIG_I2C_ANDES depend on ARCH_ANDES
- (3/4) (new)
- Added an entry to the MAINTAINERS file.
- (4/4) (new)
- Added the I2C node to QiLai DTS.
- Link to v1: https://patch.msgid.link/20250207021923.2912373-1-ben717@andestech.com
---
Ben Zong-You Xie (4):
dt-bindings: i2c: add support for AE350 I2C controller
i2c: add Andes I2C driver support
MAINTAINERS: add an entry for Andes I2C driver
riscv: dts: andes: qilai: add I2C controller
.../bindings/i2c/andestech,ae350-i2c.yaml | 45 +++
MAINTAINERS | 6 +
arch/riscv/boot/dts/andes/qilai.dtsi | 7 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-andes.c | 341 +++++++++++++++++++++
6 files changed, 410 insertions(+)
---
base-commit: 46ec065d8610c5e8d11a8b205a6b7bd3c40d46b8
change-id: 20260120-atciic100-da3ec68f7bb4
Best regards,
--
Ben Zong-You Xie <ben717@andestech.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add SM7325 Motorola edge 30 (dubai)
From: Krzysztof Kozlowski @ 2026-03-30 7:25 UTC (permalink / raw)
To: Val Packett
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260329103055.96649-1-val@packett.cool>
On Sun, Mar 29, 2026 at 07:16:39AM -0300, Val Packett wrote:
> Motorola edge 30 (motorola,dubai) is a smartphone based on the
> SM7325 SoC.
>
> Signed-off-by: Val Packett <val@packett.cool>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Krzysztof Kozlowski @ 2026-03-30 7:23 UTC (permalink / raw)
To: Hongliang Wang
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <ac62e280-1099-c0bc-f322-ba8b65307053@loongson.cn>
On 30/03/2026 09:18, Hongliang Wang wrote:
>
> On 2026/3/27 下午2:39, Krzysztof Kozlowski wrote:
>> On 27/03/2026 04:09, Hongliang Wang wrote:
>>> The initial idea was that this patch could be used for both ACPI and DTS.
>>>>>> The i2c-ls2x driver is compatible with both Loongson 2K and 3A+7A
>>>>>> platform, parse
>>>>>> the same parameters regardless of dts or acpi parameter passing, So
>>>>>> clock-input
>>>>>> and clock-div attributes are defined to describe input clock of i2c
>>>>>> controller and
>>>>>> divisor of input clock. It can be used on both 2K and 3A+7A platform.
>>>>> And you cannot use them in DTS.
>>> OK
>>>> I need to keep guessing what you want to achieve, because neither your
>>>> message nor commit text was explicit
>>> What I want to achieve is to describe the input clock and divisor of I2C
>>> controller
>> Input clocks are defined as clock inputs obviously in DT, not as
>> integers. Bindings need to describe the hardware, so start with that.
> I can describe the hardware in loongson,ls2x-i2c.yaml, and I would like to
> confirm with you what final implementation plan you agree to? clock
> framework
> or custom clock-input an clock-div attributes? if clock framework, how
> can it
> also be used for ACPI?
And you ask DT maintainer for that? It's not relevant. You sent DT
bindings patch, so this patch must be correct and we discuss this patch
here.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: dts: gemini: Rename power controller node to gemini-poweroff
From: Krzysztof Kozlowski @ 2026-03-30 7:22 UTC (permalink / raw)
To: Khushal Chitturi
Cc: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw, daniel.baluta,
simona.toaca, d-gole, m-chawdhry, linux-pm, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260329205151.15161-3-khushalchitturi@gmail.com>
On Mon, Mar 30, 2026 at 02:21:51AM +0530, Khushal Chitturi wrote:
> Update the node name for the Cortina Gemini power controller from
> power-controller to gemini-poweroff since node "power controller" is
> reserved for power domain controller.
>
> Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
> ---
> arch/arm/boot/dts/gemini/gemini.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/gemini/gemini.dtsi b/arch/arm/boot/dts/gemini/gemini.dtsi
> index befe322bd7de..c524adadcf81 100644
> --- a/arch/arm/boot/dts/gemini/gemini.dtsi
> +++ b/arch/arm/boot/dts/gemini/gemini.dtsi
> @@ -228,7 +228,7 @@ intcon: interrupt-controller@48000000 {
> #interrupt-cells = <2>;
> };
>
> - power-controller@4b000000 {
> + gemini-poweroff@4b000000 {
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
If you cannot find a name matching your device, please check in kernel
sources for similar cases or you can grow the spec (via pull request to
DT spec repo).
Why gemini is added here? It's not generic.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-30 7:21 UTC (permalink / raw)
To: Khushal Chitturi
Cc: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw, daniel.baluta,
simona.toaca, d-gole, m-chawdhry, linux-pm, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260329205151.15161-2-khushalchitturi@gmail.com>
On Mon, Mar 30, 2026 at 02:21:50AM +0530, Khushal Chitturi wrote:
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + gemini-poweroff@4b000000 {
I gave a list of possible names, yet you chosen different one. No, it
does not work like that.
Please read the feedback and choose one of the names mentioned there.
And next time please read DT maintainer review feedback more carefully.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-03-30 7:18 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <ca984be0-e7a6-4897-bf9f-db9465942c6e@kernel.org>
On 2026/3/27 下午2:39, Krzysztof Kozlowski wrote:
> On 27/03/2026 04:09, Hongliang Wang wrote:
>> The initial idea was that this patch could be used for both ACPI and DTS.
>>>>> The i2c-ls2x driver is compatible with both Loongson 2K and 3A+7A
>>>>> platform, parse
>>>>> the same parameters regardless of dts or acpi parameter passing, So
>>>>> clock-input
>>>>> and clock-div attributes are defined to describe input clock of i2c
>>>>> controller and
>>>>> divisor of input clock. It can be used on both 2K and 3A+7A platform.
>>>> And you cannot use them in DTS.
>> OK
>>> I need to keep guessing what you want to achieve, because neither your
>>> message nor commit text was explicit
>> What I want to achieve is to describe the input clock and divisor of I2C
>> controller
> Input clocks are defined as clock inputs obviously in DT, not as
> integers. Bindings need to describe the hardware, so start with that.
I can describe the hardware in loongson,ls2x-i2c.yaml, and I would like to
confirm with you what final implementation plan you agree to? clock
framework
or custom clock-input an clock-div attributes? if clock framework, how
can it
also be used for ACPI?
>
> Best regards,
> Krzysztof
Best regards,
Hongliang Wang
^ permalink raw reply
* Re: [PATCH v3 0/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Viresh Kumar @ 2026-03-30 7:18 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260329123449.309814-1-krishnagopi487@gmail.com>
On 29-03-26, 18:04, Gopi Krishna Menon wrote:
> This patch series converts SPEAr Thermal Sensor bindings to DT schema
> and removes the thermal_flags property from spear13xx.dtsi.
>
> Changes since v2:
> - Reword the commit message and subject to correct explanation in patch 2
> - No changes in patch 1
> Changes since v1:
> - Changed unevaluatedProperties to additionalProperties in the binding
> - Reword the commit message and subject in the second patch
>
> Note:
> * This patch is part of the GSoC2026 application process for device tree bindings conversions
> * https://github.com/LinuxFoundationGSoC/ProjectIdeas/wiki/GSoC-2026-Device-Tree-Bindings
>
> Gopi Krishna Menon (2):
> dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
> ARM: dts: st: spear: remove undocumented thermal_flags property
>
> .../bindings/thermal/spear-thermal.txt | 14 --------
> .../thermal/st,thermal-spear1340.yaml | 36 +++++++++++++++++++
> arch/arm/boot/dts/st/spear13xx.dtsi | 1 -
> 3 files changed, 36 insertions(+), 15 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/thermal/spear-thermal.txt
> create mode 100644 Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH 2/2 v2] devicetree: spi: add spi-mosi-idle-low property support
From: Krzysztof Kozlowski @ 2026-03-30 7:16 UTC (permalink / raw)
To: charles-antoine.couret
Cc: broonie, robh, krzk+dt, conor+dt, linux-spi, devicetree,
linux-kernel
In-Reply-To: <20260329125832.2985115-1-charles-antoine.couret@mind.be>
On Sun, Mar 29, 2026 at 02:58:32PM +0200, charles-antoine.couret@mind.be wrote:
> From: Charles-Antoine Couret <charles-antoine.couret@mind.be>
>
> This flag means that device requires the MOSI line to be low
> when it's in idle state.
>
> Signed-off-by: Charles-Antoine Couret <charles-antoine.couret@mind.be>
> ---
> Documentation/devicetree/bindings/spi/spi-controller.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
There is no patch 1/2 here, even on mailing lists, so probably this has
messed threading.
Please use subject prefixes matching the subsystem. You can get them for
example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 06/24] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
From: Krzysztof Kozlowski @ 2026-03-30 7:15 UTC (permalink / raw)
To: Cristian Marussi, Rob Herring (Arm)
Cc: etienne.carriere, Krzysztof Kozlowski, d-gole, linux-fsdevel,
Conor Dooley, linux-doc, f.fainelli, vincent.guittot,
philip.radford, souvik.chakravarty, peng.fan, dan.carpenter,
lukasz.luba, arm-scmi, sudeep.holla, michal.simek, linux-kernel,
jonathan.cameron, elif.topuz, linux-arm-kernel, james.quinlan,
devicetree, brauner
In-Reply-To: <aclo1laTrsQFSan6@pluto>
On 29/03/2026 20:00, Cristian Marussi wrote:
>>
>> My bot found errors running 'make dt_binding_check' on your patch:
>>
>> yamllint warnings/errors:
>>
>> dtschema/dtc warnings/errors:
>> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/firmware/arm,scmi.example.dtb: scmi (arm,scmi): protocol@19: Unevaluated properties are not allowed ('i2c2-pins', 'keys-pins', 'mdio-pins' were unexpected)
>> from schema $id: http://devicetree.org/schemas/firmware/arm,scmi.yaml
>>
>> doc reference errors (make refcheckdocs):
>>
>> See https://patchwork.kernel.org/project/devicetree/patch/20260329163337.637393-7-cristian.marussi@arm.com
>>
>> The base for the series is generally the latest rc1. A different dependency
>> should be noted in *this* patch.
>>
>> If you already ran 'make dt_binding_check' and didn't see the above
>> error(s), then make sure 'yamllint' is installed and dt-schema is up to
>> date:
>>
>> pip3 install dtschema --upgrade
>>
>
> Yes...the new protocol block definition ended up intermixed with the
> previous protocol block...totally wrong.
This is not a problem. Problem was that you did not test it and sent
completely untested code to mailing list.
Add "RFC" prefix you subjects so we know that we can ignore the patchset
in the future.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH net-next v5 00/14] macb usrio/tsu patches
From: Jiawen Wu @ 2026-03-30 7:12 UTC (permalink / raw)
To: patchwork-bot+netdevbpf, 'Conor Dooley',
'Conor Dooley'
Cc: netdev, conor.dooley, Valentina.FernandezAlanis, andrew+netdev,
davem, edumazet, kuba, pabeni, robh, krzk+dt, conor+dt,
daire.mcnamara, pjw, palmer, aou, alex, nicolas.ferre,
claudiu.beznea, richardcochran, samuel.holland, devicetree,
linux-kernel, linux-riscv, dave.stevenson, sean.anderson,
vineeth.karumanchi, abin.joseph, theo.lebrun, Ryan.Wanner,
haokexin, netdev, conor.dooley, Valentina.FernandezAlanis,
andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, daire.mcnamara, pjw, palmer, aou, alex, nicolas.ferre,
claudiu.beznea, richardcochran, samuel.holland, devicetree,
linux-kernel, linux-riscv, dave.stevenson, sean.anderson,
vineeth.karumanchi, abin.joseph, theo.lebrun, Ryan.Wanner,
haokexin
In-Reply-To: <177482042554.472023.12757157452690281696.git-patchwork-notify@kernel.org>
> Hello:
>
> This series was applied to netdev/net-next.git (main)
> by Jakub Kicinski <kuba@kernel.org>:
>
> On Wed, 25 Mar 2026 16:28:04 +0000 you wrote:
> > From: Conor Dooley <conor.dooley@microchip.com>
> >
> > Hey folks,
> >
> > At the very least, it'd be good of the soc vendor folks could check
> > their platforms and see if their usrio stuff actually lines up with what
> > the driver currently calls "macb_default_usrio". Ours didn't and it was
> > a nasty surprise.
> >
> > [...]
>
> Here is the summary with links:
> - [net-next,v5,01/14] Revert "net: macb: Clean up the .usrio settings in macb_config instances"
> https://git.kernel.org/netdev/net-next/c/8ccf062c6770
> - [net-next,v5,02/14] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in
> usrio
> https://git.kernel.org/netdev/net-next/c/a17871778ee2
> - [net-next,v5,03/14] net: macb: split USRIO_HAS_CLKEN capability in two
> https://git.kernel.org/netdev/net-next/c/039f185a0060
> - [net-next,v5,04/14] dt-bindings: net: cdns,macb: replace cdns,refclk-ext with cdns,refclk-source
> https://git.kernel.org/netdev/net-next/c/dfa36d7e860c
> - [net-next,v5,05/14] net: macb: rework usrio refclk selection code
> https://git.kernel.org/netdev/net-next/c/6c5b565d7d41
> - [net-next,v5,06/14] net: macb: np4 doesn't need a usrio pointer
> https://git.kernel.org/netdev/net-next/c/826cbe636e10
> - [net-next,v5,07/14] net: macb: add mpfs specific usrio configuration
> https://git.kernel.org/netdev/net-next/c/c711311d6ba3
> - [net-next,v5,08/14] net: macb: warn on pclk use as a tsu_clk fallback
> https://git.kernel.org/netdev/net-next/c/3fe13d858f83
> - [net-next,v5,09/14] net: macb: clean up tsu clk rate acquisition
> https://git.kernel.org/netdev/net-next/c/b698a1e397ab
> - [net-next,v5,10/14] dt-bindings: net: macb: add property indicating timer adjust mode
> https://git.kernel.org/netdev/net-next/c/09a6164a4f1d
> - [net-next,v5,11/14] net: macb: timer adjust mode is not supported
> https://git.kernel.org/netdev/net-next/c/41adda8764fd
> - [net-next,v5,12/14] net: macb: runtime detect MACB_CAPS_USRIO_DISABLED
> https://git.kernel.org/netdev/net-next/c/47c86c463612
> - [net-next,v5,13/14] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided
> https://git.kernel.org/netdev/net-next/c/32fc6a9f6e75
> - [net-next,v5,14/14] net: macb: drop usrio pointer on EyeQ5 config
> https://git.kernel.org/netdev/net-next/c/cd1082a96f9a
>
> You are awesome, thank you!
> --
> Deet-doot-dot, I am a bot.
> https://korg.docs.kernel.org/patchwork/pwbot.html
Hi,
There are compilation errors after merging this patch set.
I believe the error occurred where the CONFIG_OF is not set.
root@w-MS-7E16:~/net-next# make C=1 W=1
CALL scripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
CC [M] drivers/net/ethernet/cadence/macb_main.o
drivers/net/ethernet/cadence/macb_main.c:5755:19: error: ‘at91_default_usrio’ undeclared here (not in a function)
5755 | .usrio = &at91_default_usrio,
| ^~~~~~~~~~~~~~~~~~
make[6]: *** [scripts/Makefile.build:289: drivers/net/ethernet/cadence/macb_main.o] Error 1
make[5]: *** [scripts/Makefile.build:548: drivers/net/ethernet/cadence] Error 2
make[4]: *** [scripts/Makefile.build:548: drivers/net/ethernet] Error 2
make[3]: *** [scripts/Makefile.build:548: drivers/net] Error 2
make[2]: *** [scripts/Makefile.build:548: drivers] Error 2
make[1]: *** [/root/net-next/Makefile:2105: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
^ permalink raw reply
* Re: [PATCH v3 06/24] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
From: Krzysztof Kozlowski @ 2026-03-30 7:11 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, arm-scmi, linux-fsdevel,
linux-doc, sudeep.holla, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
dan.carpenter, d-gole, jonathan.cameron, elif.topuz, lukasz.luba,
philip.radford, brauner, souvik.chakravarty, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260329163337.637393-7-cristian.marussi@arm.com>
On Sun, Mar 29, 2026 at 05:33:17PM +0100, Cristian Marussi wrote:
> Add new SCMI v4.0 Telemetry protocol bindings definitions.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> Cc: Rob Herring <robh@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> ---
> Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index be817fd9cc34..e936ae7c0fb9 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -298,6 +298,14 @@ properties:
> reg:
> const: 0x19
>
> + protocol@1B:
It's always lowercase hex in DTS.
> + $ref: '#/$defs/protocol-node'
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + const: 0x1B
Here as well.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v11 01/11] riscv: kexec_file: Fix crashk_low_res not exclude bug
From: Jinjie Ruan @ 2026-03-30 7:11 UTC (permalink / raw)
To: Guo Ren
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, feng.tang, pawan.kumar.gupta, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, cfsworks, osandov,
jbohac, tangyouling, sourabhjain, ritesh.list, eajames,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, chenjiahao16, hbathini,
takahiro.akashi, james.morse, lizhengyu3, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <CAJF2gTRN=RpgzQsQ7QDbwjDmyQZP9anQZ+CaK2r-Mrz9dQbohQ@mail.gmail.com>
On 2026/3/30 11:49, Guo Ren wrote:
> On Sat, Mar 28, 2026 at 3:41 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>>
>> As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X")
>> and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for
>> crashkres_low.") for arm64, while implementing crashkernel=X,[high,low],
>> riscv should have excluded the "crashk_low_res" reserved ranges from
>> the crash kernel memory to prevent them from being exported through
>> /proc/vmcore, and the exclusion would need an extra crash_mem range.
>>
>> Cc: Guo Ren <guoren@kernel.org>
>> Cc: Baoquan He <bhe@redhat.com>
>> Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]")
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> arch/riscv/kernel/machine_kexec_file.c | 14 +++++++++++---
>> 1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
>> index 54e2d9552e93..3f7766057cac 100644
>> --- a/arch/riscv/kernel/machine_kexec_file.c
>> +++ b/arch/riscv/kernel/machine_kexec_file.c
>> @@ -61,7 +61,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>> unsigned int nr_ranges;
>> int ret;
>>
>> - nr_ranges = 1; /* For exclusion of crashkernel region */
>> + nr_ranges = 2; /* For exclusion of crashkernel region */
>> walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
>>
>> cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
>> @@ -76,8 +76,16 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>>
>> /* Exclude crashkernel region */
>> ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
>> - if (!ret)
>> - ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>> + if (ret)
>> + goto out;
>> +
>> + if (crashk_low_res.end) {
>> + ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
> Exclude crashk_low_res is reasonable, but have you tested this?
Just simply tested on qemu with crashkernel=4G with following kexec
mentioned in
https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/.
And the second kernel can be started normally.
https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
# dmesg | grep crash
[ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000
(128 MB)
[ 0.000000] crashkernel reserved: 0x000000017fe00000 -
0x000000027fe00000 (4096 MB)
>
>> + if (ret)
>> + goto out;
>> + }
>> +
>> + ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>>
>> out:
>> kfree(cmem);
>> --
>> 2.34.1
>>
>
>
^ permalink raw reply
* Re: [PATCH net-next v3 1/3] dt-bindings: net: pse-pd: add poll-interval-ms property
From: Krzysztof Kozlowski @ 2026-03-30 7:10 UTC (permalink / raw)
To: Carlo Szelinsky
Cc: Oleksij Rempel, Kory Maincent, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-leds
In-Reply-To: <20260329153124.2823980-2-github@szelinsky.de>
On Sun, Mar 29, 2026 at 05:31:22PM +0200, Carlo Szelinsky wrote:
> Add the optional poll-interval-ms property for PSE controllers that
> use poll-based event detection instead of interrupts. Defaults to
> 500ms if not specified.
Why?
>
> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
> Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
> ---
> .../devicetree/bindings/net/pse-pd/pse-controller.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
> index cd09560e0aea..329d020f054c 100644
> --- a/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
> +++ b/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
> @@ -27,6 +27,14 @@ properties:
> subnode. This property is deprecated, please use pse-pis instead.
> enum: [0, 1]
>
> + poll-interval-ms:
We allow poll interval for input devices, because how sensitive buttons
are or what capacitor is there charging/discharging is really a
hardware property of the board.
Why that would be true for PSE controller? Controller is specific, so
any internal aspects of polling are already implied by compatible.
You have entire commit msg to explain WHY you are doing this, not
explain WHAT you did. We see what you did in the diff.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 02/15] firmware: qcom: Add a generic PAS service
From: Sumit Garg @ 2026-03-30 7:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Konrad Dybcio, linux-arm-msm, devicetree, dri-devel, freedreno,
linux-media, netdev, linux-wireless, ath12k, linux-remoteproc,
andersson, konradybcio, robh, krzk+dt, conor+dt, robin.clark,
sean, akhilpo, lumag, abhinav.kumar, jesszhan0024, marijn.suijten,
airlied, simona, vikash.garodia, dikshita.agarwal, bod, mchehab,
elder, andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
linux-kernel, Sumit Garg
In-Reply-To: <a0a7269d-7a09-4a78-a4b0-b39b67bc253b@kernel.org>
On Fri, Mar 27, 2026 at 02:56:40PM +0100, Krzysztof Kozlowski wrote:
> On 23/03/2026 15:26, Konrad Dybcio wrote:
> >>>
> >>> This pattern has been carried from the PAS API contract among kernel
> >>> clients and the SCM PAS service earlier. The clients don't hold a
> >>> reference to the PAS data like underlying platform or TEE device etc.
> >>> Hence the need to have a global data pointer to hold reference to the
> >>> ops data structure registered by drivers having different lifetime of
> >>> devices. Also, the PAS APIs can be called from very different client
> >>> driver contexts.
> >>>
> >>> Surely, avoiding global data is always better given a better alternative
> >>> is there. Do you have any better alternative proposal here?
> >>
> >> Why it cannot be part of the context?
> >>
> >> Look at your API, e.g.:
> >> qcom_pas_init_image(). It takes struct qcom_pas_context which should
> >> contain the ops.
Have a look at all other PAS client APIs, the context isn't something
that each client takes a reference and pass it on for every PAS
invocation. And changing the PAS API contract for kernel clients is out
of scope of this patch-set.
> >
> > This would make the client have to select the ops. The whole point is to
> > avoid that, since the client has no clue (and is supposed not to have any).
>
> Yeah, I see. The problem is that this patchset just keeps growing the
> singletons so except existing 'struct qcom_scm *__scm' in qcom_scm.c,
> this one brings at least three new: 'ops_ptr', 'qcom_pas_ops_scm' and
> 'qcom_pas_ops_tee'.
Not sure how you equate ops structure __pointer__ to the ops structure
itself. Can you enlighten me how in the rest of the kernel ops data
structures are shared among independent modules registering on different
bus types?
>
> I don't think you need all four in total, but only one which will hold
> whatever pointers are necessary.
Your arguments seems to be in favour of the existing monolithic SCM
driver design but you need to understand that's not how underlying TZ
services are implemented. The PAS service in TZ has nothing to do with
the ICE service for inline crypto as an example.
Please go through the motivation of this patch-set and the corresponding
OP-TEE implementation as TZ which is all open source.
-Sumit
^ 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