* Re: [PATCH 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-10 10:47 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov
In-Reply-To: <adjQl37-6a--_y3Y@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]
Hello Andrea,
On Fri, Apr 10, 2026 at 12:27:35PM +0200, Andrea della Porta wrote:
> On 08:27 Fri 10 Apr , Uwe Kleine-König wrote:
> > On Thu, Apr 09, 2026 at 06:16:41PM +0200, Andrea della Porta wrote:
> > > On 23:45 Sun 05 Apr , Uwe Kleine-König wrote:
> > > > On Fri, Apr 03, 2026 at 04:31:55PM +0200, Andrea della Porta wrote:
> > > > > +static void rp1_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> > > > > +{
> > > > > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > > > > + u32 value;
> > > > > +
> > > > > + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > > > + value &= ~PWM_MODE_MASK;
> > > > > + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > > > +
> > > > > + rp1_pwm_apply_config(chip, pwm);
> > > >
> > > > What is the purpose of this call?
> > >
> > > To update the configuration on the next PWM strobe in order to avoid
> > > glitches. I'll add a short comment in the code.
> >
> > .pwm_free() should not touch the hardware configuration. Changing the
> > pinmuxing (which I guess is the purpose of clearing PWM_MODE_MASK) is
> > somewhat a grey area. If that saves energy, that's okish. Otherwise
> > not interfering with the operation of the PWM (e.g. to keep a display on
> > during kexec or so) is preferred.
>
> Sorry I should've been more clear on this. The pinmux/conf is not changed
> at all by this mask, only the PWM output mode is. The controller can output
> several type of waveforms and clearing PWM_MODE_MASK is just setting the
> controller to output a 0, which is the reset default i.e. the same value
> as just before exporting the channel.
> I guess this is the expected behaviour in case of a fan, it should stop
> spinning in case you unexport the pwm channel, but I see it could be
> different with displays.
> Honestly I don't have a strong opinion about that, please just let me
> know if I should drop that pwm_free entirely.
Yes, in this case drop the function completely. It's the responsibility
of the consumer to stop the PWM before releasing it.
> > > > > +static int rp1_pwm_resume(struct device *dev)
> > > > > +{
> > > > > + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> > > > > +
> > > > > + return clk_prepare_enable(rp1->clk);
> > > >
> > > > Hmm, if this fails and then the driver is unbound, the clk operations
> > > > are not balanced.
> > >
> > > I'll add some flags to check if the clock is really enabled or not.
> >
> > To be honest, I guess that is a problem of several drivers, not only in
> > drivers/pwm. If this complicates the driver, I guess addressing this
> > isn't very critical.
>
> I'll come up with something, we can always drop this check if deemed
> too 'noisy'.
Great, thanks
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 00/12] net: airoha: Support multiple net_devices connected to the same GDM port
From: Lorenzo Bianconi @ 2026-04-10 10:39 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260409195645.16c68979@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
On Apr 09, Jakub Kicinski wrote:
> On Mon, 06 Apr 2026 12:34:05 +0200 Lorenzo Bianconi wrote:
> > EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> > Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> > manages the traffic in a TDM manner. As a result multiple net_devices can
> > connect to the same GDM{3,4} port and there is a theoretical "1:n"
> > relation between GDM ports and net_devices.
>
> Still waiting for the device tree review. I'm going to blindly send out
> the Sashiko review, please comment if any of it makes sense?
ack, I will do.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v1 3/5] irqchip: starfive: Use devm_ interfaces to simplify resource release
From: Changhuang Liang @ 2026-04-10 9:01 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
In-Reply-To: <20260410090106.622781-1-changhuang.liang@starfivetech.com>
Use devm_ interfaces to simplify resource release. Make clock and reset
get optional as they are not used on the JHB100 SoC. Replace pr_ logging
with dev_* logging.
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
---
drivers/irqchip/irq-starfive-jhb100-intc.c | 44 ++++++++--------------
1 file changed, 15 insertions(+), 29 deletions(-)
diff --git a/drivers/irqchip/irq-starfive-jhb100-intc.c b/drivers/irqchip/irq-starfive-jhb100-intc.c
index 2c9cdad7f377..312a4634870a 100644
--- a/drivers/irqchip/irq-starfive-jhb100-intc.c
+++ b/drivers/irqchip/irq-starfive-jhb100-intc.c
@@ -7,16 +7,14 @@
* Author: Changhuang Liang <changhuang.liang@starfivetech.com>
*/
-#define pr_fmt(fmt) "irq-starfive-jhb100: " fmt
-
#include <linux/bitops.h>
#include <linux/clk.h>
#include <linux/irq.h>
#include <linux/irqchip.h>
#include <linux/irqchip/chained_irq.h>
#include <linux/irqdomain.h>
-#include <linux/of_address.h>
#include <linux/of_irq.h>
+#include <linux/platform_device.h>
#include <linux/reset.h>
#include <linux/spinlock.h>
@@ -127,48 +125,44 @@ static int starfive_intc_probe(struct platform_device *pdev, struct device_node
if (!irqc)
return -ENOMEM;
- irqc->base = of_iomap(intc, 0);
+ irqc->base = devm_platform_ioremap_resource(pdev, 0);
if (!irqc->base) {
- pr_err("Unable to map registers\n");
+ dev_err(&pdev->dev, "unable to map registers\n");
ret = -ENXIO;
goto err_free;
}
- rst = of_reset_control_get_exclusive(intc, NULL);
+ rst = devm_reset_control_get_optional(&pdev->dev, NULL);
if (IS_ERR(rst)) {
- pr_err("Unable to get reset control %pe\n", rst);
+ dev_err(&pdev->dev, "Unable to get reset control %pe\n", rst);
ret = PTR_ERR(rst);
- goto err_unmap;
+ goto err_free;
}
- clk = of_clk_get(intc, 0);
+ clk = devm_clk_get_optional_enabled(&pdev->dev, NULL);
if (IS_ERR(clk)) {
- pr_err("Unable to get clock %pe\n", clk);
+ dev_err(&pdev->dev, "Unable to get and enable clock %pe\n", clk);
ret = PTR_ERR(clk);
- goto err_reset_put;
+ goto err_free;
}
ret = reset_control_deassert(rst);
if (ret)
- goto err_clk_put;
-
- ret = clk_prepare_enable(clk);
- if (ret)
- goto err_reset_assert;
+ goto err_free;
raw_spin_lock_init(&irqc->lock);
irqc->domain = irq_domain_create_linear(of_fwnode_handle(intc), STARFIVE_INTC_SRC_IRQ_NUM,
&starfive_intc_domain_ops, irqc);
if (!irqc->domain) {
- pr_err("Unable to create IRQ domain\n");
+ dev_err(&pdev->dev, "Unable to create IRQ domain\n");
ret = -EINVAL;
- goto err_clk_disable;
+ goto err_reset_assert;
}
parent_irq = of_irq_get(intc, 0);
if (parent_irq < 0) {
- pr_err("Failed to get main IRQ: %d\n", parent_irq);
+ dev_err(&pdev->dev, "Failed to get main IRQ: %d\n", parent_irq);
ret = parent_irq;
goto err_remove_domain;
}
@@ -176,23 +170,15 @@ static int starfive_intc_probe(struct platform_device *pdev, struct device_node
irq_set_chained_handler_and_data(parent_irq, starfive_intc_irq_handler,
irqc);
- pr_info("Interrupt controller register, nr_irqs %d\n",
- STARFIVE_INTC_SRC_IRQ_NUM);
+ dev_info(&pdev->dev, "Interrupt controller register, nr_irqs %d\n",
+ STARFIVE_INTC_SRC_IRQ_NUM);
return 0;
err_remove_domain:
irq_domain_remove(irqc->domain);
-err_clk_disable:
- clk_disable_unprepare(clk);
err_reset_assert:
reset_control_assert(rst);
-err_clk_put:
- clk_put(clk);
-err_reset_put:
- reset_control_put(rst);
-err_unmap:
- iounmap(irqc->base);
err_free:
kfree(irqc);
return ret;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v3 10/12] net: airoha: Do not stop GDM port if it is shared
From: Lorenzo Bianconi @ 2026-04-10 10:35 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree, Xuegang Lu
In-Reply-To: <20260410025726.1810041-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4665 bytes --]
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> net: airoha: Do not stop GDM port if it is shared
>
> Theoretically, in the current codebase, two independent net_devices can
> be connected to the same GDM port so we need to check the GDM port is not
> used by any other running net_device before setting the forward
> configuration to FE_PSE_PORT_DROP.
>
> Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > index fd27ba13029bd..5b0cd37b155e4 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
>
> [ ... ]
>
> > @@ -1688,18 +1693,18 @@ static int airoha_dev_stop(struct net_device *netdev)
> > struct airoha_gdm_dev *dev = netdev_priv(netdev);
> > struct airoha_gdm_port *port = dev->port;
> > struct airoha_qdma *qdma = dev->qdma;
> > - int i, err;
> > + int i;
> >
> > netif_tx_disable(netdev);
> > - err = airoha_set_vip_for_gdm_port(dev, false);
> > - if (err)
> > - return err;
> > -
> > for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
> > netdev_tx_reset_subqueue(netdev, i);
> >
> > - airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> > - FE_PSE_PORT_DROP);
> > + if (atomic_dec_and_test(&port->users)) {
> > + airoha_set_vip_for_gdm_port(dev, false);
> > + airoha_set_gdm_port_fwd_cfg(qdma->eth,
> > + REG_GDM_FWD_CFG(port->id),
> > + FE_PSE_PORT_DROP);
> > + }
> >
> > if (atomic_dec_and_test(&qdma->users)) {
> > airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> > GLOBAL_CFG_TX_DMA_EN_MASK |
> > GLOBAL_CFG_RX_DMA_EN_MASK);
> >
> > for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++) {
> > if (!qdma->q_tx[i].ndesc)
> > continue;
> >
> > airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
> > }
> > }
>
> This problem wasn't introduced by this patch, but does the QDMA teardown
> path have a DMA corruption vulnerability here?
>
> When GLOBAL_CFG_TX_DMA_EN_MASK is cleared, it fails to poll
> GLOBAL_CFG_TX_DMA_BUSY_MASK, proceeding to unmap memory while the hardware
> DMA engine may still be processing in-flight descriptors.
>
> Furthermore, airoha_qdma_cleanup_tx_queue() unmaps the DMA addresses and
> frees the SKBs, but it does not appear to clear the physical hardware
> descriptors or reset the hardware ring pointers (REG_TX_CPU_IDX /
> REG_TX_DMA_IDX).
>
> When the device is later reopened in airoha_dev_open(),
> GLOBAL_CFG_TX_DMA_EN_MASK is set again without re-initializing the rings.
> Will the hardware DMA engine resume fetching from its previous index,
> processing stale descriptors whose backing memory was already unmapped
> and freed?
ack, I will work on it with a dedicated patch.
>
> [ ... ]
>
> > @@ -1851,10 +1856,22 @@ static void airoha_dev_get_stats64(struct net_device *netdev,
> > static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
> > {
> > struct airoha_gdm_dev *dev = netdev_priv(netdev);
> > + u32 cur_len, len = ETH_HLEN + mtu + ETH_FCS_LEN;
> > struct airoha_gdm_port *port = dev->port;
> > - u32 len = ETH_HLEN + mtu + ETH_FCS_LEN;
> > struct airoha_eth *eth = dev->eth;
> >
> > + cur_len = FIELD_GET(GDM_LONG_LEN_MASK,
> > + airoha_fe_rr(eth, REG_GDM_LEN_CFG(port->id)));
> > + if (len < cur_len) {
> > + u8 port_refcnt = atomic_read(&port->users);
> > +
> > + /* We can decrease the device MTU just if the GDM port is
> > + * not shared or if the other device is not running.
> > + */
> > + if (port_refcnt > 1 || (port_refcnt && !netif_running(netdev)))
> > + return -EBUSY;
> > + }
> > +
>
> Does this MTU decrease validation create a state trap on shared ports?
>
> If both eth0 and eth1 (sharing a port) are up, and a user increases eth0 MTU
> to 9000, the hardware MTU updates to 9000. If the user then tries to lower
> eth0 MTU back to 1500, len < cur_len evaluates to true. Because eth1 is also
> up (port_refcnt > 1), this returns -EBUSY.
>
> This would prevent either interface from decreasing its MTU without fully
> bringing down the sibling interface.
>
> Should the software netdev->mtu be decoupled from the hardware validation,
> allowing valid MTU changes in software while dynamically programming the
> hardware MTU to the maximum of all currently up interfaces on the shared
> port?
It seems more correct to me avoid receiving in the stack packet bigger than the
configured 'SW MTU".
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v1 5/5] irqchip: starfive: Implement irq_set_type and irq_ack hooks
From: Changhuang Liang @ 2026-04-10 9:01 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
In-Reply-To: <20260410090106.622781-1-changhuang.liang@starfivetech.com>
Add irq_set_type hook to support configuring interrupt trigger types
(level high/low, edge rising/falling) for the JHB100 interrupt controller.
Also add irq_ack hook as required by handle_edge_irq.
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
---
drivers/irqchip/irq-starfive-jhb100-intc.c | 72 ++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/drivers/irqchip/irq-starfive-jhb100-intc.c b/drivers/irqchip/irq-starfive-jhb100-intc.c
index d5ecbb603a58..d34f960b0770 100644
--- a/drivers/irqchip/irq-starfive-jhb100-intc.c
+++ b/drivers/irqchip/irq-starfive-jhb100-intc.c
@@ -9,6 +9,7 @@
#include <linux/bitops.h>
#include <linux/clk.h>
+#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/irqchip.h>
#include <linux/irqchip/chained_irq.h>
@@ -18,12 +19,20 @@
#include <linux/reset.h>
#include <linux/spinlock.h>
+#define STARFIVE_INTC_SRC_TYPE(n) (0x04 + ((n) * 0x20))
#define STARFIVE_INTC_SRC_CLEAR(n) (0x10 + ((n) * 0x20))
#define STARFIVE_INTC_SRC_MASK(n) (0x14 + ((n) * 0x20))
#define STARFIVE_INTC_SRC_INT(n) (0x1c + ((n) * 0x20))
+#define STARFIVE_INTC_TRIGGER_MASK 0x3
+#define STARFIVE_INTC_TRIGGER_HIGH 0
+#define STARFIVE_INTC_TRIGGER_LOW 1
+#define STARFIVE_INTC_TRIGGER_POSEDGE 2
+#define STARFIVE_INTC_TRIGGER_NEGEDGE 3
+
#define STARFIVE_INTC_NUM 2
#define STARFIVE_INTC_SRC_IRQ_NUM 32
+#define STARFIVE_INTC_TYPE_NUM 16
struct starfive_irq_chip {
void __iomem *base;
@@ -31,6 +40,17 @@ struct starfive_irq_chip {
raw_spinlock_t lock;
};
+static void starfive_intc_mod(struct starfive_irq_chip *irqc, u32 reg,
+ u32 mask, u32 data)
+{
+ u32 value;
+
+ value = ioread32(irqc->base + reg) & ~mask;
+ data &= mask;
+ data |= value;
+ iowrite32(data, irqc->base + reg);
+}
+
static void starfive_intc_bit_set(struct starfive_irq_chip *irqc,
u32 reg, u32 bit_mask)
{
@@ -77,10 +97,62 @@ static void starfive_intc_mask(struct irq_data *d)
raw_spin_unlock(&irqc->lock);
}
+static void starfive_intc_ack(struct irq_data *d)
+{
+ /* for handle_edge_irq, nothing to do */
+}
+
+static int starfive_intc_set_type(struct irq_data *d, unsigned int type)
+{
+ struct starfive_irq_chip *irqc = irq_data_get_irq_chip_data(d);
+ u32 i, bitpos, ty_pos, ty_shift, tmp;
+
+ i = d->hwirq / STARFIVE_INTC_SRC_IRQ_NUM;
+ bitpos = d->hwirq % STARFIVE_INTC_SRC_IRQ_NUM;
+ ty_pos = bitpos / STARFIVE_INTC_TYPE_NUM;
+ ty_shift = (bitpos % STARFIVE_INTC_TYPE_NUM) * 2;
+
+ switch (type) {
+ case IRQF_TRIGGER_LOW:
+ tmp = STARFIVE_INTC_TRIGGER_LOW << ty_shift;
+ irq_set_handler_locked(d, handle_level_irq);
+ break;
+ case IRQF_TRIGGER_HIGH:
+ tmp = STARFIVE_INTC_TRIGGER_HIGH << ty_shift;
+ irq_set_handler_locked(d, handle_level_irq);
+ break;
+ case IRQF_TRIGGER_FALLING:
+ tmp = STARFIVE_INTC_TRIGGER_NEGEDGE << ty_shift;
+ irq_set_handler_locked(d, handle_edge_irq);
+ break;
+ case IRQF_TRIGGER_RISING:
+ tmp = STARFIVE_INTC_TRIGGER_POSEDGE << ty_shift;
+ irq_set_handler_locked(d, handle_edge_irq);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ raw_spin_lock(&irqc->lock);
+
+ starfive_intc_mod(irqc, STARFIVE_INTC_SRC_TYPE(i) + 4 * ty_pos,
+ STARFIVE_INTC_TRIGGER_MASK << ty_shift, tmp);
+
+ /* Once the type is updated, clear interrupt can help to reset the type value */
+ starfive_intc_bit_set(irqc, STARFIVE_INTC_SRC_CLEAR(i), BIT(bitpos));
+ starfive_intc_bit_clear(irqc, STARFIVE_INTC_SRC_CLEAR(i), BIT(bitpos));
+
+ raw_spin_unlock(&irqc->lock);
+
+ return 0;
+}
+
static struct irq_chip intc_dev = {
.name = "StarFive JHB100 INTC",
.irq_unmask = starfive_intc_unmask,
.irq_mask = starfive_intc_mask,
+ .irq_ack = starfive_intc_ack,
+ .irq_set_type = starfive_intc_set_type,
};
static int starfive_intc_map(struct irq_domain *d, unsigned int irq,
--
2.25.1
^ permalink raw reply related
* [PATCH v1 4/5] irqchip: starfive: Increase the interrupt source number up to 64
From: Changhuang Liang @ 2026-04-10 9:01 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
In-Reply-To: <20260410090106.622781-1-changhuang.liang@starfivetech.com>
From: Mason Huo <mason.huo@starfivetech.com>
StarFive JHB100 SoC interrupt controller actually supports 64 interrupt
sources, the original code only supported up to 32. now it is extended
to 64.
Signed-off-by: Mason Huo <mason.huo@starfivetech.com>
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
---
drivers/irqchip/irq-starfive-jhb100-intc.c | 43 ++++++++++++++--------
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git a/drivers/irqchip/irq-starfive-jhb100-intc.c b/drivers/irqchip/irq-starfive-jhb100-intc.c
index 312a4634870a..d5ecbb603a58 100644
--- a/drivers/irqchip/irq-starfive-jhb100-intc.c
+++ b/drivers/irqchip/irq-starfive-jhb100-intc.c
@@ -18,10 +18,11 @@
#include <linux/reset.h>
#include <linux/spinlock.h>
-#define STARFIVE_INTC_SRC0_CLEAR 0x10
-#define STARFIVE_INTC_SRC0_MASK 0x14
-#define STARFIVE_INTC_SRC0_INT 0x1c
+#define STARFIVE_INTC_SRC_CLEAR(n) (0x10 + ((n) * 0x20))
+#define STARFIVE_INTC_SRC_MASK(n) (0x14 + ((n) * 0x20))
+#define STARFIVE_INTC_SRC_INT(n) (0x1c + ((n) * 0x20))
+#define STARFIVE_INTC_NUM 2
#define STARFIVE_INTC_SRC_IRQ_NUM 32
struct starfive_irq_chip {
@@ -53,18 +54,26 @@ static void starfive_intc_bit_clear(struct starfive_irq_chip *irqc,
static void starfive_intc_unmask(struct irq_data *d)
{
struct starfive_irq_chip *irqc = irq_data_get_irq_chip_data(d);
+ int i, bitpos;
+
+ i = d->hwirq / STARFIVE_INTC_SRC_IRQ_NUM;
+ bitpos = d->hwirq % STARFIVE_INTC_SRC_IRQ_NUM;
raw_spin_lock(&irqc->lock);
- starfive_intc_bit_clear(irqc, STARFIVE_INTC_SRC0_MASK, BIT(d->hwirq));
+ starfive_intc_bit_clear(irqc, STARFIVE_INTC_SRC_MASK(i), BIT(bitpos));
raw_spin_unlock(&irqc->lock);
}
static void starfive_intc_mask(struct irq_data *d)
{
struct starfive_irq_chip *irqc = irq_data_get_irq_chip_data(d);
+ int i, bitpos;
+
+ i = d->hwirq / STARFIVE_INTC_SRC_IRQ_NUM;
+ bitpos = d->hwirq % STARFIVE_INTC_SRC_IRQ_NUM;
raw_spin_lock(&irqc->lock);
- starfive_intc_bit_set(irqc, STARFIVE_INTC_SRC0_MASK, BIT(d->hwirq));
+ starfive_intc_bit_set(irqc, STARFIVE_INTC_SRC_MASK(i), BIT(bitpos));
raw_spin_unlock(&irqc->lock);
}
@@ -93,20 +102,23 @@ static void starfive_intc_irq_handler(struct irq_desc *desc)
struct starfive_irq_chip *irqc = irq_data_get_irq_handler_data(&desc->irq_data);
struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned long value;
- int hwirq;
+ int hwirq, i;
chained_irq_enter(chip, desc);
- value = ioread32(irqc->base + STARFIVE_INTC_SRC0_INT);
- while (value) {
- hwirq = ffs(value) - 1;
+ for (i = 0; i < STARFIVE_INTC_NUM; i++) {
+ value = ioread32(irqc->base + STARFIVE_INTC_SRC_INT(i));
+ while (value) {
+ hwirq = ffs(value) - 1;
- generic_handle_domain_irq(irqc->domain, hwirq);
+ generic_handle_domain_irq(irqc->domain,
+ hwirq + i * STARFIVE_INTC_SRC_IRQ_NUM);
- starfive_intc_bit_set(irqc, STARFIVE_INTC_SRC0_CLEAR, BIT(hwirq));
- starfive_intc_bit_clear(irqc, STARFIVE_INTC_SRC0_CLEAR, BIT(hwirq));
+ starfive_intc_bit_set(irqc, STARFIVE_INTC_SRC_CLEAR(i), BIT(hwirq));
+ starfive_intc_bit_clear(irqc, STARFIVE_INTC_SRC_CLEAR(i), BIT(hwirq));
- __clear_bit(hwirq, &value);
+ __clear_bit(hwirq, &value);
+ }
}
chained_irq_exit(chip, desc);
@@ -152,7 +164,8 @@ static int starfive_intc_probe(struct platform_device *pdev, struct device_node
raw_spin_lock_init(&irqc->lock);
- irqc->domain = irq_domain_create_linear(of_fwnode_handle(intc), STARFIVE_INTC_SRC_IRQ_NUM,
+ irqc->domain = irq_domain_create_linear(of_fwnode_handle(intc),
+ STARFIVE_INTC_SRC_IRQ_NUM * STARFIVE_INTC_NUM,
&starfive_intc_domain_ops, irqc);
if (!irqc->domain) {
dev_err(&pdev->dev, "Unable to create IRQ domain\n");
@@ -171,7 +184,7 @@ static int starfive_intc_probe(struct platform_device *pdev, struct device_node
irqc);
dev_info(&pdev->dev, "Interrupt controller register, nr_irqs %d\n",
- STARFIVE_INTC_SRC_IRQ_NUM);
+ STARFIVE_INTC_SRC_IRQ_NUM * STARFIVE_INTC_NUM);
return 0;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Mark Brown @ 2026-04-10 10:28 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Liam Girdwood, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <20260410100330.1fc4b97b@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]
On Fri, Apr 10, 2026 at 10:03:30AM +0200, Herve Codina wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > > > I didn't want to set a particular limit related to the number of GPIOs
> > > > used for thje gain value. Of course 2^32 is obviously a lot.
> > > > What do you think about 16 for maxItems?
> > > What is the most you are aware of? Take that and double it.
> > > Seems to me 256 levels would be way more than a human ear could distinguish.
> > There's plenty of gain controls with way more than 256 bits of
> > resolution, though I'm not aware of any that are configured via GPIO.
> > The step size and absolute values you want can vary dramatically
> > depending on application, possibly in the same system (eg, a DAC that
> > can be connected to both headphones or speakers) so you often end up
> > making practical adjustments in a small subset of the available range
> > but that subset can vary a lot for the same part.
> Mark, do you think that max 16 GPIOs could be an acceptable limit?
> IMHO, this value is large enough to be used as the limit.
That does seem larger than any real system would ever need.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: Mark Brown @ 2026-04-10 10:25 UTC (permalink / raw)
To: Karthik S
Cc: Srinivas Kandagatla, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
linux-sound, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <8d97669b-7bde-4a21-8131-0907554f534e@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 954 bytes --]
On Fri, Apr 10, 2026 at 11:10:22AM +0530, Karthik S wrote:
> Hi @Mark ,
Please don't add random characters to my name.
Please don't top post, reply in line with needed context. This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.
> On the indus mezz skew, The codec rails are distributed through fixed Vdd
> (3.3V supply). These rails are Board‑controlled , not switched by the codec
> and not power‑cycled dynamically. There is no per‑codec enable/disable
> control exposed to software.The codec is wired to rails that are always
> powered when the board is powered. Hence this justifies it being handled as
> a board dt property.
This is a compltely normal situation for regulators, probably true for
the majority of current systems with regulators in use. Why would this
board be different?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-04-10 10:27 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov
In-Reply-To: <adiW1tBC8Imd14LD@monoceros>
Hi Uwe,
On 08:27 Fri 10 Apr , Uwe Kleine-König wrote:
> Hello Andrea,
>
> On Thu, Apr 09, 2026 at 06:16:41PM +0200, Andrea della Porta wrote:
> > On 23:45 Sun 05 Apr , Uwe Kleine-König wrote:
> > > On Fri, Apr 03, 2026 at 04:31:55PM +0200, Andrea della Porta wrote:
> > > > +static void rp1_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> > > > +{
> > > > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > > > + u32 value;
> > > > +
> > > > + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > > + value &= ~PWM_MODE_MASK;
> > > > + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > > +
> > > > + rp1_pwm_apply_config(chip, pwm);
> > >
> > > What is the purpose of this call?
> >
> > To update the configuration on the next PWM strobe in order to avoid
> > glitches. I'll add a short comment in the code.
>
> .pwm_free() should not touch the hardware configuration. Changing the
> pinmuxing (which I guess is the purpose of clearing PWM_MODE_MASK) is
> somewhat a grey area. If that saves energy, that's okish. Otherwise
> not interfering with the operation of the PWM (e.g. to keep a display on
> during kexec or so) is preferred.
Sorry I should've been more clear on this. The pinmux/conf is not changed
at all by this mask, only the PWM output mode is. The controller can output
several type of waveforms and clearing PWM_MODE_MASK is just setting the
controller to output a 0, which is the reset default i.e. the same value
as just before exporting the channel.
I guess this is the expected behaviour in case of a fan, it should stop
spinning in case you unexport the pwm channel, but I see it could be
different with displays.
Honestly I don't have a strong opinion about that, please just let me
know if I should drop that pwm_free entirely.
>
> > > > +static int rp1_pwm_resume(struct device *dev)
> > > > +{
> > > > + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> > > > +
> > > > + return clk_prepare_enable(rp1->clk);
> > >
> > > Hmm, if this fails and then the driver is unbound, the clk operations
> > > are not balanced.
> >
> > I'll add some flags to check if the clock is really enabled or not.
>
> To be honest, I guess that is a problem of several drivers, not only in
> drivers/pwm. If this complicates the driver, I guess addressing this
> isn't very critical.
I'll come up with something, we can always drop this check if deemed
too 'noisy'.
Many thanks,
Andrea
>
> Best regards
> Uwe
^ permalink raw reply
* Re: [PATCH net-next v3 09/12] net: airoha: Support multiple net_devices for a single FE GDM port
From: Lorenzo Bianconi @ 2026-04-10 10:19 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree
In-Reply-To: <20260410025724.1810007-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 8640 bytes --]
On Apr 09, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> net: airoha: Support multiple net_devices for a single FE GDM port
>
> This commit introduces support for mapping multiple net_device interfaces
> to a single Frame Engine (FE) GDM port via an external hardware arbiter.
> It updates the rx/tx paths, port allocation, and registration logic to
> handle the new net_device array.
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> [ ... ]
> > @@ -615,9 +617,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> > u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
> > struct page *page = virt_to_head_page(e->buf);
> > u32 desc_ctrl = le32_to_cpu(desc->ctrl);
> > - struct airoha_gdm_port *port;
> > - struct net_device *netdev;
> > - int data_len, len, p;
> > + struct airoha_gdm_dev *dev;
> > + int data_len, len;
> >
> > if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
> > break;
>
> While looking at this code, I noticed an issue that predates this patch.
> Can the lack of a memory barrier after checking the descriptor ownership bit
> cause stale reads?
>
> The driver checks QDMA_DESC_DONE_MASK to verify that the hardware has finished
> writing the descriptor. However, it reads desc->msg1 before this check and
> without a dma_rmb():
>
> u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
> struct page *page = virt_to_head_page(e->buf);
> u32 desc_ctrl = le32_to_cpu(desc->ctrl);
>
> if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
> break;
>
> Since weakly ordered architectures can reorder memory reads, could the CPU
> prefetch msg1 before the DMA engine writes the new descriptor values, leading
> to routing the packet to the wrong gdm_dev?
This issue has been already fixed with the following commit:
commit 4ae0604a0673e11e2075b178387151fcad5111b5
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date: Tue Apr 7 08:48:04 2026 +0200
net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process()
Add missing dma_rmb() in airoha_qdma_rx_process routine to make sure the
DMA read operations are completed when the NIC reports the processing on
the current descriptor is done. Moreover, add missing READ_ONCE() in
airoha_qdma_rx_process() for DMA descriptor control fields in order to
avoid any compiler reordering.
>
> [ ... ]
> > @@ -1764,9 +1765,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
> > airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
> > airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
> >
> > - /* XXX: handle XSI_USB_PORT and XSI_PCE1_PORT */
> > - nbq = port->id == AIROHA_GDM3_IDX && airoha_is_7581(eth) ? 4 : 0;
> > - src_port = eth->soc->ops.get_src_port_id(port, nbq);
> > + src_port = eth->soc->ops.get_src_port_id(port, dev->nbq);
> > if (src_port < 0)
> > return src_port;
>
> Can configuring the loopback for one device break connectivity for other
> devices sharing the same port?
>
> When multiple net_devices (like PCIE0 and PCIE1 on GDM3) open and call
> airoha_set_gdm2_loopback(), they modify global hardware registers such as
> REG_FE_WAN_PORT.
>
> Since WAN0_MASK is unconditionally updated to track the current device's
> src_port:
>
> airoha_fe_rmw(eth, REG_FE_WAN_PORT,
> WAN1_EN_MASK | WAN1_MASK | WAN0_MASK,
> FIELD_PREP(WAN0_MASK, src_port));
>
> won't the last configured device clobber the hardware state for the others?
This issue is fixed with the following patch in the series:
commit 008995bd8f39c5fdf37a933fa3c962e7ef52e8c6
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date: Fri Apr 3 12:07:27 2026 +0200
net: airoha: Introduce WAN device flag
Introduce WAN flag to specify if a given device is used to transmit/receive
WAN or LAN traffic. Current codebase supports specifying LAN/WAN device
configuration in ndo_init() callback during device bootstrap.
Please note it is possible to specify multiple LAN devices but just a
single WAN one.
>
> [ ... ]
> > @@ -1987,7 +1986,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> > }
> >
> > fport = airoha_get_fe_port(dev);
> > - msg1 = FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> > + msg1 = FIELD_PREP(QDMA_ETH_TXMSG_NBOQ_MASK, dev->nbq) |
> > + FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> > FIELD_PREP(QDMA_ETH_TXMSG_METER_MASK, 0x7f);
> >
> > q = &qdma->q_tx[qid];
>
> Does sharing the hardware QDMA TX queues among multiple net_device instances
> introduce a permanent transmit stall?
>
> In airoha_dev_xmit(), if a shared hardware queue is full, the driver stops the
> netdev_queue of the specific netdev making the call:
>
> if (q->queued + nr_frags >= q->ndesc) {
> /* not enough space in the queue */
> netif_tx_stop_queue(txq);
> spin_unlock_bh(&q->lock);
> return NETDEV_TX_BUSY;
> }
>
> However, the TX completion handler (airoha_tx_irq_process()) only wakes the
> queue of the netdev attached to the completed packet. If an interface's TX
> queue is stopped but it has no pending packets in the hardware queue (because
> another interface filled it), will it ever get woken up?
This issue is orthogonal to this series and it will be fixed with a dedicated
patch.
>
> [ ... ]
> > @@ -2955,11 +2958,25 @@ static int airoha_alloc_gdm_device(struct airoha_eth *eth,
> > netdev->dev_addr);
> > }
> >
> > + /* Allowed nbq for EN7581 on GDM3 port are 4 and 5 for PCIE0
> > + * and PCIE1 respectively.
> > + */
> > + index = nbq;
> > + if (index && airoha_is_7581(eth) && port->id == AIROHA_GDM3_IDX)
> > + index -= 4;
> > +
> > + if (index >= ARRAY_SIZE(port->devs) || port->devs[index]) {
> > + dev_err(eth->dev, "invalid nbq id: %d\n", nbq);
> > + return -EINVAL;
> > + }
> > +
> > + netdev->dev.of_node = of_node_get(np);
> > dev = netdev_priv(netdev);
>
> Does this code leak the of_node reference?
>
> The node reference is explicitly incremented via of_node_get(np). The networking
> core does not automatically drop explicit of_node references on free_netdev().
> Without a matching of_node_put() in the error paths or the driver's teardown
> function (airoha_remove()), will this reference permanently leak when the device
> is destroyed?
ack, I will fix it in v4.
>
> [ ... ]
> > @@ -3003,7 +3021,43 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
> > if (err)
> > return err;
> >
> > - return airoha_alloc_gdm_device(eth, port, np);
> > + for_each_child_of_node(np, node) {
> > + /* Multiple external serdes connected to the FE GDM port via an
> > + * external arbiter.
> > + */
> > + const __be32 *nbq_ptr;
> > + int nbq;
> > +
> > + if (!of_device_is_compatible(node, "airoha,eth-port"))
> > + continue;
> > +
> > + d++;
> > + if (!of_device_is_available(node))
> > + continue;
> > +
> > + nbq_ptr = of_get_property(node, "reg", NULL);
> > + if (!nbq_ptr) {
> > + dev_err(eth->dev, "missing nbq id\n");
> > + of_node_put(node);
> > + return -EINVAL;
> > + }
> > +
> > + /* Verify the provided nbq parameter is valid */
> > + nbq = be32_to_cpup(nbq_ptr);
> > + err = eth->soc->ops.get_src_port_id(port, nbq);
> > + if (err < 0) {
> > + of_node_put(node);
> > + return err;
> > + }
> > +
> > + err = airoha_alloc_gdm_device(eth, port, nbq, node);
> > + if (err) {
> > + of_node_put(node);
> > + return err;
> > + }
> > + }
> > +
> > + return !d ? airoha_alloc_gdm_device(eth, port, 0, np) : 0;
> > }
>
> Does passing 0 for nbq in the fallback path break older device trees on the
> EN7581 SoC?
>
> Later, when the interface is brought up, airoha_set_gdm2_loopback() calls
> airoha_en7581_get_src_port_id(), which returns -EINVAL for GDM3 if nbq is
> not 4 or 5:
>
> switch (port->id) {
> case AIROHA_GDM3_IDX:
> /* 7581 SoC supports PCIe serdes on GDM3 port */
> if (nbq == 4)
> return HSGMII_LAN_7581_PCIE0_SRCPORT;
> if (nbq == 5)
> return HSGMII_LAN_7581_PCIE1_SRCPORT;
> break;
>
> If nbq is hardcoded to 0 for legacy DTs, won't this cause interface
> initialization to fail unconditionally for GDM3?
ack, I will fix it in v4.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 1/4] dt-bindings: soc: amlogic: clk-measure: Add A1 and T7 compatible
From: Jian Hu @ 2026-04-10 10:03 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Martin Blumenstingl, robh+dt, Rob Herring, Krzysztof Kozlowski
Cc: Jian Hu, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260410100329.3167482-1-jian.hu@amlogic.com>
Add the Amlogic A1 and T7 compatible for the clk-measurer IP.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
.../bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
index 39d4637c2d08..b1200e6940ac 100644
--- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
+++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
@@ -24,6 +24,8 @@ properties:
- amlogic,meson-sm1-clk-measure
- amlogic,c3-clk-measure
- amlogic,s4-clk-measure
+ - amlogic,a1-clk-measure
+ - amlogic,t7-clk-measure
reg:
maxItems: 1
--
2.47.1
^ permalink raw reply related
* [PATCH 0/4] soc: amlogic: clk-measure: add A1 and T7 support
From: Jian Hu @ 2026-04-10 10:03 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Martin Blumenstingl, robh+dt, Rob Herring, Krzysztof Kozlowski
Cc: Jian Hu, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
This series adds Amlogic clock measurement support for A1 and T7 SoCs,
including binding updates, driver additions, and device tree enablement.
Jian Hu (4):
dt-bindings: soc: amlogic: clk-measure: Add A1 and T7 compatible
soc: amlogic: clk-measure: Add A1 and T7 support
arm64: dts: meson: a1: Add clk measure support
arm64: dts: amlogic: t7: Add clk measure support
.../amlogic/amlogic,meson-gx-clk-measure.yaml | 2 +
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 5 +
drivers/soc/amlogic/meson-clk-measure.c | 272 ++++++++++++++++++
4 files changed, 284 insertions(+)
--
2.47.1
^ permalink raw reply
* Re: [PATCH 3/6] pinctrl: tegra: Add Tegra238 pinmux driver
From: Krzysztof Kozlowski @ 2026-04-10 10:05 UTC (permalink / raw)
To: pshete, linux-gpio, devicetree, linux-tegra, linux-kernel, arnd,
bjorn.andersson, conor+dt, dmitry.baryshkov, ebiggers, geert,
jonathanh, krzk+dt, kuninori.morimoto.gx, linusw, luca.weiss,
michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp, sven,
thierry.reding, webgeek1234
In-Reply-To: <20260409131340.168556-4-pshete@nvidia.com>
On 09/04/2026 15:13, pshete@nvidia.com wrote:
> From: Prathamesh Shete <pshete@nvidia.com>
>
> This change adds support for the two pin controllers
Please do not use "This commit/patch/change", but imperative mood. See
longer explanation here:
https://elixir.bootlin.com/linux/v6.16/source/Documentation/process/submitting-patches.rst#L94
> (MAIN and AON) found on Tegra238.
>
> Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
> ---
> drivers/pinctrl/tegra/Kconfig | 9 +
> drivers/pinctrl/tegra/Makefile | 1 +
> drivers/pinctrl/tegra/pinctrl-tegra238.c | 2056 ++++++++++++++++++++++
> 3 files changed, 2066 insertions(+)
> create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra238.c
>
> diff --git a/drivers/pinctrl/tegra/Kconfig b/drivers/pinctrl/tegra/Kconfig
> index 660d101ea367..ccb8c337b4ee 100644
> --- a/drivers/pinctrl/tegra/Kconfig
> +++ b/drivers/pinctrl/tegra/Kconfig
> @@ -36,6 +36,15 @@ config PINCTRL_TEGRA234
> bool
> select PINCTRL_TEGRA
>
> +config PINCTRL_TEGRA238
> + tristate "NVIDIA Tegra238 pinctrl driver"
> + select PINCTRL_TEGRA
> + help
> + Say Y or M here to enable support for the pinctrl driver for
> + NVIDIA Tegra238 SoC. This driver controls the pin multiplexing
> + and configuration for the MAIN and AON pin controllers found
> + on Tegra238.
All other Tegra drivers are non-selectable, so you are introducing
completely different style. This needs explanation WHY in the commit msg.
Also, since you are changing things around, then I suggest to finally
enable proper COMPILE_TEST for all tegra pinctrl. Unless I mistaken,
it's impossible to compile test currently anything from Tegra pinctrl...
Actually let me take a look, maybe I will do it for several platforms.
...
> +static struct platform_driver tegra238_pinctrl_driver = {
> + .driver = {
> + .name = "tegra238-pinctrl",
> + .of_match_table = tegra238_pinctrl_of_match,
> + },
> + .probe = tegra238_pinctrl_probe,
> +};
> +
> +static int __init tegra238_pinctrl_init(void)
> +{
> + return platform_driver_register(&tegra238_pinctrl_driver);
> +}
> +module_init(tegra238_pinctrl_init);
> +
> +static void __exit tegra238_pinctrl_exit(void)
> +{
> + platform_driver_unregister(&tegra238_pinctrl_driver);
> +}
> +module_exit(tegra238_pinctrl_exit);
Why this cannot be module_platform_driver()?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 4/4] arm64: dts: amlogic: t7: Add clk measure support
From: Jian Hu @ 2026-04-10 10:03 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Martin Blumenstingl, robh+dt, Rob Herring, Krzysztof Kozlowski
Cc: Jian Hu, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260410100329.3167482-1-jian.hu@amlogic.com>
Add the clock measure device to the T7 SoC family.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7fe72c94ed62..cec2ea74850d 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -701,6 +701,11 @@ pwm_ao_cd: pwm@60000 {
status = "disabled";
};
+ clock-measurer@48000 {
+ compatible = "amlogic,t7-clk-measure";
+ reg = <0x0 0x48000 0x0 0x1c>;
+ };
+
sd_emmc_a: mmc@88000 {
compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
reg = <0x0 0x88000 0x0 0x800>;
--
2.47.1
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: meson: a1: Add clk measure support
From: Jian Hu @ 2026-04-10 10:03 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Martin Blumenstingl, robh+dt, Rob Herring, Krzysztof Kozlowski
Cc: Jian Hu, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260410100329.3167482-1-jian.hu@amlogic.com>
Add the clock measure device to the A1 SoC family.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
index 348411411f3d..6f6a6145cba1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -576,6 +576,11 @@ saradc: adc@2c00 {
status = "disabled";
};
+ clock-measurer@3400 {
+ compatible = "amlogic,a1-clk-measure";
+ reg = <0x0 0x3400 0x0 0x1c>;
+ };
+
i2c1: i2c@5c00 {
compatible = "amlogic,meson-axg-i2c";
status = "disabled";
--
2.47.1
^ permalink raw reply related
* [PATCH 2/4] soc: amlogic: clk-measure: Add A1 and T7 support
From: Jian Hu @ 2026-04-10 10:03 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Martin Blumenstingl, robh+dt, Rob Herring, Krzysztof Kozlowski
Cc: Jian Hu, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260410100329.3167482-1-jian.hu@amlogic.com>
Add support for the A1 and T7 SoC family in amlogic clk measure.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
drivers/soc/amlogic/meson-clk-measure.c | 272 ++++++++++++++++++++++++
1 file changed, 272 insertions(+)
diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
index d862e30a244e..083524671b76 100644
--- a/drivers/soc/amlogic/meson-clk-measure.c
+++ b/drivers/soc/amlogic/meson-clk-measure.c
@@ -787,6 +787,258 @@ static const struct meson_msr_id clk_msr_s4[] = {
};
+static struct meson_msr_id clk_msr_a1[] = {
+ CLK_MSR_ID(0, "tdmout_b_sclk"),
+ CLK_MSR_ID(1, "tdmout_a_sclk"),
+ CLK_MSR_ID(2, "tdmin_lb_sclk"),
+ CLK_MSR_ID(3, "tdmin_b_sclk"),
+ CLK_MSR_ID(4, "tdmin_a_sclk"),
+ CLK_MSR_ID(5, "vad"),
+ CLK_MSR_ID(6, "resamplea"),
+ CLK_MSR_ID(7, "pdm_sysclk"),
+ CLK_MSR_ID(8, "pdm_dclk"),
+ CLK_MSR_ID(9, "locker_out"),
+ CLK_MSR_ID(10, "locker_in"),
+ CLK_MSR_ID(11, "spdifin"),
+ CLK_MSR_ID(12, "tdmin_vad"),
+ CLK_MSR_ID(13, "au_adc"),
+ CLK_MSR_ID(14, "au_dac"),
+ CLK_MSR_ID(16, "spicc_a"),
+ CLK_MSR_ID(17, "spifc"),
+ CLK_MSR_ID(18, "sd_emmc_a"),
+ CLK_MSR_ID(19, "dmcx4"),
+ CLK_MSR_ID(20, "dmc"),
+ CLK_MSR_ID(21, "psram"),
+ CLK_MSR_ID(22, "cecb"),
+ CLK_MSR_ID(23, "ceca"),
+ CLK_MSR_ID(24, "ts"),
+ CLK_MSR_ID(25, "pwm_f"),
+ CLK_MSR_ID(26, "pwm_e"),
+ CLK_MSR_ID(27, "pwm_d"),
+ CLK_MSR_ID(28, "pwm_c"),
+ CLK_MSR_ID(29, "pwm_b"),
+ CLK_MSR_ID(30, "pwm_a"),
+ CLK_MSR_ID(31, "saradc"),
+ CLK_MSR_ID(32, "usb_bus"),
+ CLK_MSR_ID(33, "dsp_b"),
+ CLK_MSR_ID(34, "dsp_a"),
+ CLK_MSR_ID(35, "axi"),
+ CLK_MSR_ID(36, "sys"),
+ CLK_MSR_ID(40, "rng_ring_osc0"),
+ CLK_MSR_ID(41, "rng_ring_osc1"),
+ CLK_MSR_ID(42, "rng_ring_osc2"),
+ CLK_MSR_ID(43, "rng_ring_osc3"),
+ CLK_MSR_ID(44, "dds_out"),
+ CLK_MSR_ID(45, "cpu_clk_div16"),
+ CLK_MSR_ID(46, "gpio_msr"),
+ CLK_MSR_ID(50, "osc_ring_cpu0"),
+ CLK_MSR_ID(51, "osc_ring_cpu1"),
+ CLK_MSR_ID(54, "osc_ring_top0"),
+ CLK_MSR_ID(55, "osc_ring_top1"),
+ CLK_MSR_ID(56, "osc_ring_ddr"),
+ CLK_MSR_ID(57, "osc_ring_dmc"),
+ CLK_MSR_ID(58, "osc_ring_dspa"),
+ CLK_MSR_ID(59, "osc_ring_dspb"),
+ CLK_MSR_ID(60, "osc_ring_rama"),
+ CLK_MSR_ID(61, "osc_ring_ramb"),
+};
+
+static struct meson_msr_id clk_msr_t7[] = {
+ CLK_MSR_ID(0, "sys"),
+ CLK_MSR_ID(1, "axi"),
+ CLK_MSR_ID(2, "rtc"),
+ CLK_MSR_ID(3, "dspa"),
+ CLK_MSR_ID(4, "dspb"),
+ CLK_MSR_ID(5, "mali"),
+ CLK_MSR_ID(6, "sys_cpu_clk_div16"),
+ CLK_MSR_ID(7, "ceca"),
+ CLK_MSR_ID(8, "cecb"),
+ CLK_MSR_ID(10, "fclk_div5"),
+ CLK_MSR_ID(11, "mpll0"),
+ CLK_MSR_ID(12, "mpll1"),
+ CLK_MSR_ID(13, "mpll2"),
+ CLK_MSR_ID(14, "mpll3"),
+ CLK_MSR_ID(15, "mpll_50m"),
+ CLK_MSR_ID(16, "pcie_inp"),
+ CLK_MSR_ID(17, "pcie_inn"),
+ CLK_MSR_ID(18, "mpll_test_out"),
+ CLK_MSR_ID(19, "hifi_pll"),
+ CLK_MSR_ID(20, "gp0_pll"),
+ CLK_MSR_ID(21, "gp1_pll"),
+ CLK_MSR_ID(22, "eth_mppll_50m"),
+ CLK_MSR_ID(23, "sys_pll_div16"),
+ CLK_MSR_ID(24, "ddr_dpll_pt"),
+ CLK_MSR_ID(25, "earcrx_pll"),
+ CLK_MSR_ID(26, "paie1_clk_inp"),
+ CLK_MSR_ID(27, "paie1_clk_inn"),
+ CLK_MSR_ID(28, "amlgdc"),
+ CLK_MSR_ID(29, "gdc"),
+ CLK_MSR_ID(30, "mod_eth_phy_ref"),
+ CLK_MSR_ID(31, "mod_eth_tx"),
+ CLK_MSR_ID(32, "eth_clk125Mhz"),
+ CLK_MSR_ID(33, "eth_clk_rmii"),
+ CLK_MSR_ID(34, "co_clkin_to_mac"),
+ CLK_MSR_ID(35, "mod_eth_rx_clk_rmii"),
+ CLK_MSR_ID(36, "co_rx"),
+ CLK_MSR_ID(37, "co_tx"),
+ CLK_MSR_ID(38, "eth_phy_rxclk"),
+ CLK_MSR_ID(39, "eth_phy_plltxclk"),
+ CLK_MSR_ID(40, "ephy_test"),
+ CLK_MSR_ID(41, "dsi_b_meas"),
+ CLK_MSR_ID(42, "hdmirx_apl"),
+ CLK_MSR_ID(43, "hdmirx_tmds"),
+ CLK_MSR_ID(44, "hdmirx_cable"),
+ CLK_MSR_ID(45, "hdmirx_apll_clk_audio"),
+ CLK_MSR_ID(46, "hdmirx_5m"),
+ CLK_MSR_ID(47, "hdmirx_2m"),
+ CLK_MSR_ID(48, "hdmirx_cfg"),
+ CLK_MSR_ID(49, "hdmirx_hdcp2x_eclk"),
+ CLK_MSR_ID(50, "vid_pll0_div"),
+ CLK_MSR_ID(51, "hdmi_vid_pll"),
+ CLK_MSR_ID(54, "vdac_clk"),
+ CLK_MSR_ID(55, "vpu_clk_buf"),
+ CLK_MSR_ID(56, "mod_tcon_clko"),
+ CLK_MSR_ID(57, "lcd_an_clk_ph2"),
+ CLK_MSR_ID(58, "lcd_an_clk_ph3"),
+ CLK_MSR_ID(59, "hdmi_tx_pixel"),
+ CLK_MSR_ID(60, "vdin_meas"),
+ CLK_MSR_ID(61, "vpu_clk"),
+ CLK_MSR_ID(62, "vpu_clkb"),
+ CLK_MSR_ID(63, "vpu_clkb_tmp"),
+ CLK_MSR_ID(64, "vpu_clkc"),
+ CLK_MSR_ID(65, "vid_lock"),
+ CLK_MSR_ID(66, "vapbclk"),
+ CLK_MSR_ID(67, "ge2d"),
+ CLK_MSR_ID(68, "aud_pll"),
+ CLK_MSR_ID(69, "aud_sck"),
+ CLK_MSR_ID(70, "dsi_a_meas"),
+ CLK_MSR_ID(72, "mipi_csi_phy"),
+ CLK_MSR_ID(73, "mipi_isp"),
+ CLK_MSR_ID(76, "hdmitx_tmds"),
+ CLK_MSR_ID(77, "hdmitx_sys"),
+ CLK_MSR_ID(78, "hdmitx_fe"),
+ CLK_MSR_ID(80, "hdmitx_prif"),
+ CLK_MSR_ID(81, "hdmitx_200m"),
+ CLK_MSR_ID(82, "hdmitx_aud"),
+ CLK_MSR_ID(83, "hdmitx_pnx"),
+ CLK_MSR_ID(84, "spicc5"),
+ CLK_MSR_ID(85, "spicc4"),
+ CLK_MSR_ID(86, "spicc3"),
+ CLK_MSR_ID(87, "spicc2"),
+ CLK_MSR_ID(93, "vdec"),
+ CLK_MSR_ID(94, "wave521_aclk"),
+ CLK_MSR_ID(95, "wave521_cclk"),
+ CLK_MSR_ID(96, "wave521_bclk"),
+ CLK_MSR_ID(97, "hcodec"),
+ CLK_MSR_ID(98, "hevcb"),
+ CLK_MSR_ID(99, "hevcf"),
+ CLK_MSR_ID(100, "hdmi_aud_pll"),
+ CLK_MSR_ID(101, "hdmi_acr_ref"),
+ CLK_MSR_ID(102, "hdmi_meter"),
+ CLK_MSR_ID(103, "hdmi_vid"),
+ CLK_MSR_ID(104, "hdmi_aud"),
+ CLK_MSR_ID(105, "hdmi_dsd"),
+ CLK_MSR_ID(108, "dsi1_phy"),
+ CLK_MSR_ID(109, "dsi0_phy"),
+ CLK_MSR_ID(110, "smartcard"),
+ CLK_MSR_ID(111, "sar_adc"),
+ CLK_MSR_ID(113, "sd_emmc_c"),
+ CLK_MSR_ID(114, "sd_emmc_b"),
+ CLK_MSR_ID(115, "sd_emmc_a"),
+ CLK_MSR_ID(116, "gpio_msr"),
+ CLK_MSR_ID(117, "spicc1"),
+ CLK_MSR_ID(118, "spicc0"),
+ CLK_MSR_ID(119, "anakin"),
+ CLK_MSR_ID(121, "ts_clk(temp sensor)"),
+ CLK_MSR_ID(122, "ts_a73"),
+ CLK_MSR_ID(123, "ts_a53"),
+ CLK_MSR_ID(124, "ts_nna"),
+ CLK_MSR_ID(130, "audio_vad"),
+ CLK_MSR_ID(131, "acodec_dac_clk_x128"),
+ CLK_MSR_ID(132, "audio_locker_in"),
+ CLK_MSR_ID(133, "audio_locker_out"),
+ CLK_MSR_ID(134, "audio_tdmout_c_sclk"),
+ CLK_MSR_ID(135, "audio_tdmout_b_sclk"),
+ CLK_MSR_ID(136, "audio_tdmout_a_sclk"),
+ CLK_MSR_ID(137, "audio_tdmin_lb_sclk"),
+ CLK_MSR_ID(138, "audio_tdmin_c_sclk"),
+ CLK_MSR_ID(139, "audio_tdmin_b_sclk"),
+ CLK_MSR_ID(140, "audio_tdmin_a_sclk"),
+ CLK_MSR_ID(141, "audio_resamplea"),
+ CLK_MSR_ID(142, "audio_pdm_sysclk"),
+ CLK_MSR_ID(143, "audio_spdifoutb_mst"),
+ CLK_MSR_ID(144, "audio_spdifout_mst"),
+ CLK_MSR_ID(145, "audio_spdifin_mst"),
+ CLK_MSR_ID(146, "audio_pdm_dclk"),
+ CLK_MSR_ID(147, "audio_resampleb"),
+ CLK_MSR_ID(148, "earcrx_pll_dmac"),
+ CLK_MSR_ID(156, "pwm_ao_h"),
+ CLK_MSR_ID(157, "pwm_ao_g"),
+ CLK_MSR_ID(158, "pwm_ao_f"),
+ CLK_MSR_ID(159, "pwm_ao_e"),
+ CLK_MSR_ID(160, "pwm_ao_d"),
+ CLK_MSR_ID(161, "pwm_ao_c"),
+ CLK_MSR_ID(162, "pwm_ao_b"),
+ CLK_MSR_ID(163, "pwm_ao_a"),
+ CLK_MSR_ID(164, "pwm_f"),
+ CLK_MSR_ID(165, "pwm_e"),
+ CLK_MSR_ID(166, "pwm_d"),
+ CLK_MSR_ID(167, "pwm_c"),
+ CLK_MSR_ID(168, "pwm_b"),
+ CLK_MSR_ID(169, "pwm_a"),
+ CLK_MSR_ID(170, "aclkm"),
+ CLK_MSR_ID(171, "mclk_pll"),
+ CLK_MSR_ID(172, "a73_sys_pll_div16"),
+ CLK_MSR_ID(173, "a73_cpu_clk_div16"),
+ CLK_MSR_ID(176, "rng_ring_0"),
+ CLK_MSR_ID(177, "rng_ring_1"),
+ CLK_MSR_ID(178, "rng_ring_2"),
+ CLK_MSR_ID(179, "rng_ring_3"),
+ CLK_MSR_ID(180, "am_ring_out0"),
+ CLK_MSR_ID(181, "am_ring_out1"),
+ CLK_MSR_ID(182, "am_ring_out2"),
+ CLK_MSR_ID(183, "am_ring_out3"),
+ CLK_MSR_ID(184, "am_ring_out4"),
+ CLK_MSR_ID(185, "am_ring_out5"),
+ CLK_MSR_ID(186, "am_ring_out6"),
+ CLK_MSR_ID(187, "am_ring_out7"),
+ CLK_MSR_ID(188, "am_ring_out8"),
+ CLK_MSR_ID(189, "am_ring_out9"),
+ CLK_MSR_ID(190, "am_ring_out10"),
+ CLK_MSR_ID(191, "am_ring_out11"),
+ CLK_MSR_ID(192, "am_ring_out12"),
+ CLK_MSR_ID(193, "am_ring_out13"),
+ CLK_MSR_ID(194, "am_ring_out14"),
+ CLK_MSR_ID(195, "am_ring_out15"),
+ CLK_MSR_ID(196, "am_ring_out16"),
+ CLK_MSR_ID(197, "am_ring_out17"),
+ CLK_MSR_ID(198, "am_ring_out18"),
+ CLK_MSR_ID(199, "am_ring_out19"),
+ CLK_MSR_ID(200, "mipi_csi_phy0"),
+ CLK_MSR_ID(201, "mipi_csi_phy1"),
+ CLK_MSR_ID(202, "mipi_csi_phy2"),
+ CLK_MSR_ID(203, "mipi_csi_phy3"),
+ CLK_MSR_ID(204, "vid_pll1_div"),
+ CLK_MSR_ID(205, "vid_pll2_div"),
+ CLK_MSR_ID(206, "am_ring_out20"),
+ CLK_MSR_ID(207, "am_ring_out21"),
+ CLK_MSR_ID(208, "am_ring_out22"),
+ CLK_MSR_ID(209, "am_ring_out23"),
+ CLK_MSR_ID(210, "am_ring_out24"),
+ CLK_MSR_ID(211, "am_ring_out25"),
+ CLK_MSR_ID(212, "am_ring_out26"),
+ CLK_MSR_ID(213, "am_ring_out27"),
+ CLK_MSR_ID(214, "am_ring_out28"),
+ CLK_MSR_ID(215, "am_ring_out29"),
+ CLK_MSR_ID(216, "am_ring_out30"),
+ CLK_MSR_ID(217, "am_ring_out31"),
+ CLK_MSR_ID(218, "am_ring_out32"),
+ CLK_MSR_ID(219, "enc0_if"),
+ CLK_MSR_ID(220, "enc2"),
+ CLK_MSR_ID(221, "enc1"),
+ CLK_MSR_ID(222, "enc0")
+};
+
static int meson_measure_id(struct meson_msr_id *clk_msr_id,
unsigned int duration)
{
@@ -1026,6 +1278,18 @@ static const struct meson_msr_data clk_msr_s4_data = {
.reg = &msr_reg_offset_v2,
};
+static const struct meson_msr_data clk_msr_a1_data = {
+ .msr_table = (void *)clk_msr_a1,
+ .msr_count = ARRAY_SIZE(clk_msr_a1),
+ .reg = &msr_reg_offset_v2,
+};
+
+static const struct meson_msr_data clk_msr_t7_data = {
+ .msr_table = (void *)clk_msr_t7,
+ .msr_count = ARRAY_SIZE(clk_msr_t7),
+ .reg = &msr_reg_offset_v2,
+};
+
static const struct of_device_id meson_msr_match_table[] = {
{
.compatible = "amlogic,meson-gx-clk-measure",
@@ -1059,6 +1323,14 @@ static const struct of_device_id meson_msr_match_table[] = {
.compatible = "amlogic,s4-clk-measure",
.data = &clk_msr_s4_data,
},
+ {
+ .compatible = "amlogic,a1-clk-measure",
+ .data = &clk_msr_a1_data,
+ },
+ {
+ .compatible = "amlogic,t7-clk-measure",
+ .data = &clk_msr_t7_data,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, meson_msr_match_table);
--
2.47.1
^ permalink raw reply related
* [PATCH v3 2/2] riscv: dts: spacemit: enable USB3 on OrangePi R2S
From: Chukun Pan @ 2026-04-10 10:00 UTC (permalink / raw)
To: Yixun Lan
Cc: Rob Herring, Paul Walmsley, Alexandre Ghiti, Albert Ou,
Palmer Dabbelt, Conor Dooley, Krzysztof Kozlowski, linux-riscv,
linux-kernel, devicetree, spacemit, Chukun Pan
In-Reply-To: <20260410100010.1197804-1-amadeus@jmu.edu.cn>
Enable the DWC3 USB3.0 controller and its associated PHY on the
OrangePi R2S. The USB regulator provides VBUS for USB2 and USB3
ports, but the USB2 ports are handled by a separate controller.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
.../boot/dts/spacemit/k1-orangepi-r2s.dts | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
index 409a6db269ae..bc68721e6263 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
@@ -40,6 +40,20 @@ vcc4v0: regulator-vcc4v0 {
regulator-max-microvolt = <4000000>;
vin-supply = <&vcc_5v0>;
};
+
+ vcc5v0_usb: regulator-vcc5v0-usb {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio K1_GPIO(126) GPIO_ACTIVE_HIGH>;
+ regulator-name = "vcc5v0_usb";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_5v0>;
+ };
+};
+
+&combo_phy {
+ status = "okay";
};
&emmc {
@@ -109,3 +123,13 @@ &uart0 {
pinctrl-0 = <&uart0_2_cfg>;
status = "okay";
};
+
+&usbphy2 {
+ status = "okay";
+};
+
+&usb_dwc3 {
+ dr_mode = "host";
+ vbus-supply = <&vcc5v0_usb>;
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/2] riscv: dts: spacemit: add fixed regulators for OrangePi R2S
From: Chukun Pan @ 2026-04-10 10:00 UTC (permalink / raw)
To: Yixun Lan
Cc: Rob Herring, Paul Walmsley, Alexandre Ghiti, Albert Ou,
Palmer Dabbelt, Conor Dooley, Krzysztof Kozlowski, linux-riscv,
linux-kernel, devicetree, spacemit, Chukun Pan
In-Reply-To: <20260410100010.1197804-1-amadeus@jmu.edu.cn>
Define the power input and the 4V power as fixed regulator supplies.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
.../boot/dts/spacemit/k1-orangepi-r2s.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
index de75f6aac740..409a6db269ae 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
@@ -21,6 +21,25 @@ aliases {
chosen {
stdout-path = "serial0";
};
+
+ vcc_5v0: regulator-vcc-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_5v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vcc4v0: regulator-vcc4v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc4v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <4000000>;
+ regulator-max-microvolt = <4000000>;
+ vin-supply = <&vcc_5v0>;
+ };
};
&emmc {
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/3] riscv: dts: spacemit: enable USB3 on OrangePi
From: Chukun Pan @ 2026-04-10 10:00 UTC (permalink / raw)
To: Yixun Lan
Cc: Rob Herring, Paul Walmsley, Alexandre Ghiti, Albert Ou,
Palmer Dabbelt, Conor Dooley, Krzysztof Kozlowski, linux-riscv,
linux-kernel, devicetree, spacemit, Chukun Pan
Changes in v3:
- Drop OrangePi RV2 part to avoid conflicts
- Link to v2: https://lore.kernel.org/lkml/20260402100007.110201-1-amadeus@jmu.edu.cn/
Changes in v2:
- Drop common board dtsi and PCIe regulator
- Enable USB3 on OrangePi R2S and RV2 boards
- Link to v1: https://lore.kernel.org/lkml/20260116100001.208334-2-amadeus@jmu.edu.cn/
The schematic of OrangePi RV2 is available at:
https://drive.google.com/drive/folders/1pcI_U0C3VJKTCg8A1zj08CwNbohnONSR
Chukun Pan (2):
riscv: dts: spacemit: add fixed regulators for OrangePi R2S
riscv: dts: spacemit: enable USB3 on OrangePi R2S
.../boot/dts/spacemit/k1-orangepi-r2s.dts | 43 +++++++++++++++++++
1 file changed, 43 insertions(+)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Krzysztof Kozlowski @ 2026-04-10 9:57 UTC (permalink / raw)
To: Akhil R
Cc: Frank.Li, acpica-devel, alexandre.belloni, conor+dt, devicetree,
ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon, linux-i3c,
linux-kernel, linux, miquel.raynal, p.zabel, rafael, robh,
sakari.ailus, wsa+renesas
In-Reply-To: <20260410083710.54993-1-akhilrajeev@nvidia.com>
On 10/04/2026 10:37, Akhil R wrote:
> On Fri, 10 Apr 2026 09:18:48 +0200, Krzysztof Kozlowski wrote:
>> On 10/04/2026 08:57, Guenter Roeck wrote:
>>> On 4/9/26 23:39, Krzysztof Kozlowski wrote:
>>>> On 09/04/2026 12:57, Akhil R wrote:
>>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>>> SPD5118 hwmon sensor as modules to the defconfig and therefore
>>>>> enable the support for SPD5118 sensor on SOCAMM found in NVIDIA
>>>>> Vera platforms.
>>>>
>>>> git grep for "Vera" gave me zero results. Are you sure this is an
>>>> upstream platform? Please point the DTS using this.
>>>>
>>>
>>> I think this is an ACPI based system, or at least that is what Google search
>>> tells me.
>>
>> Thanks. Following Google Vera is either a "CPU" or entire architecture
>> (at least that's how they call it), so it does not have SPD5118 sensor.
>
> SOCAMM is a Memory Module. SPD5118, as it's Kconfig mentions, is a sensor
> found within such memory modules. I didn't quite get why would you state
> that the SOCAMM present in Vera architecture (or CPU) does not have
> SPD5118 in it.
I said that CPU or entire architecture does not have it.
Commit is pretty vague in helping me to figure out the things I asked
for in last email.
>
> Pasting the below from the Vera Rubin product page [1] -
> "NVIDIA Vera CPUs add enhanced serviceability with small-outline
> compression-attached memory modules (SOCAMM) LPDDR5X and in-system tests
> for the CPU cores."
>
> [1]: https://www.nvidia.com/en-us/data-center/technologies/rubin/
So this is for Vera Rubin? For what is this exactly?
>
>>
>>
>> "Nvidia vera socamm" gives me something about "rubin". It's not me who
>> should be guessing all this.
>>
>> "nvidia vera socamm SPD5118" gives me even less, so justification is flaky.
>>
>> To remind, this commit msg should convince why generic kernel for
>> developers affecting all possible platforms - not end users, because
>> they always use distro kernels - should enable these configs. And it
>> should bring me clear rule what I can or cannot remove from defconfig,
>> if in 2 years I come and start pruning it from symbols.
>
> I found little details on what we should be adding in the defconfig. It
Then maybe we should not be adding it to defconfig?
We usually do not make changes which we do not know why we are making
them. IOW, every commit must be useful for the community and this is
achieved by either explicit or implicit answer why doing this.
And I gave in the past clear guidelines - this is config for the
upstream kernel developers to use the upstream hardware and/or for
distros to understand what is needed to support that upstream hardware
(although last part in theory, because many distros do variantion of
allmodconfig, so they don't really care about our defconfig).
> would help if you could share some guidance. Do you mean to say that the
> defconfig should include only the configs which are necessary in
> development platforms and not in end-products?
No, the type of product does not matter because upstream supports every
type of product. Upstream does not say "oh, you run end-product, so we
don't care about you". But defconfig is not used by endusers and has
zero meaning to them.
It seems to missed or ignored one more reason I wrote:
>> And it
>> should bring me clear rule what I can or cannot remove from defconfig,
>> if in 2 years I come and start pruning it from symbols.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 3/5] irqchip: starfive: Use devm_ interfaces to simplify resource release
From: Changhuang Liang @ 2026-04-10 9:53 UTC (permalink / raw)
To: Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thomas Gleixner
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-riscv@lists.infradead.org, Leyfoon Tan
In-Reply-To: <631d4d65fdbda29cfbc0b96987b5f56fcd5116ea.camel@pengutronix.de>
Hi, Philipp,
Thanks for the review.
> On Fr, 2026-04-10 at 02:01 -0700, Changhuang Liang wrote:
> > Use devm_ interfaces to simplify resource release. Make clock and
> > reset get optional as they are not used on the JHB100 SoC. Replace pr_
> > logging with dev_* logging.
> >
> > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > ---
> > drivers/irqchip/irq-starfive-jhb100-intc.c | 44
> > ++++++++--------------
> > 1 file changed, 15 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-starfive-jhb100-intc.c
> > b/drivers/irqchip/irq-starfive-jhb100-intc.c
> > index 2c9cdad7f377..312a4634870a 100644
> > --- a/drivers/irqchip/irq-starfive-jhb100-intc.c
> > +++ b/drivers/irqchip/irq-starfive-jhb100-intc.c
> [...]
> > @@ -127,48 +125,44 @@ static int starfive_intc_probe(struct
> platform_device *pdev, struct device_node
> > if (!irqc)
> > return -ENOMEM;
> >
> > - irqc->base = of_iomap(intc, 0);
> > + irqc->base = devm_platform_ioremap_resource(pdev, 0);
> > if (!irqc->base) {
> > - pr_err("Unable to map registers\n");
> > + dev_err(&pdev->dev, "unable to map registers\n");
> > ret = -ENXIO;
> > goto err_free;
> > }
> >
> > - rst = of_reset_control_get_exclusive(intc, NULL);
> > + rst = devm_reset_control_get_optional(&pdev->dev, NULL);
>
> Please use devm_reset_control_get_optional_exclusive() directly.
Thank you for the reminder. I found that I can use devm_reset_control_get_optional_exclusive_deasserted
to simplify the code in next version.
> > if (IS_ERR(rst)) {
> > - pr_err("Unable to get reset control %pe\n", rst);
> > + dev_err(&pdev->dev, "Unable to get reset control %pe\n", rst);
>
> Consider using dev_err_probe() to stop printing -EPROBE_DEFER.
>
Best Regards,
Changhunag
^ permalink raw reply
* Re: [PATCH 7/7] clk: sunxi-ng: Add Allwinner A733 RTC CCU support
From: Junhui Liu @ 2026-04-10 9:49 UTC (permalink / raw)
To: wens, Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Jernej Skrabec, Samuel Holland,
Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, linux-clk, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-rtc, devicetree, André Przywara
In-Reply-To: <CAGb2v64euL+QNXiJdTn0JygYLXg0WoguPSprKT4sKGZGVZbwug@mail.gmail.com>
On Sat Mar 28, 2026 at 10:41 PM CST, Chen-Yu Tsai wrote:
> On Wed, Jan 21, 2026 at 7:04 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
>>
>> Add support for the internal CCU found in the RTC module of the Allwinner
>> A733 SoC. While the basic 16MHz (IOSC) and 32kHz logic remains compatible
>> with older SoCs like the sun6i, the A733 introduces several new features.
>>
>> The A733 RTC CCU supports choosing one of three external crystal
>> frequencies: 19.2MHz, 24MHz, and 26MHz. It features hardware detection
>> logic to automatically identify the frequency used on the board and
>> exports this DCXO signal as the "hosc" clock.
>>
>> Furthermore, the driver implements logic to derive a 32kHz reference
>> from the HOSC. This is achieved through a muxed clock path using fixed
>> pre-dividers to normalize the different crystal frequencies to ~32kHz.
>
> Have you tested whether the actually normalizes the frequency, i.e.
> selects a different divider based on the DCXO frequency? Otherwise
> we're just lying about the frequency.
I only have A733 boards with 26MHz crystals, so I couldn't test all
crystal configurations. However, I exported the "hosc_32k" clock
(referred to as dcxo24M_div32k_clk in the vendor driver) to a physical
pin via the fanout path and measured it with the oscilloscope.
Observations:
- Normal conditions: The frequency remains stable within the 32.744 kHz
to 32.791 kHz range.
- Forced condition: I grounded the R24 resistor on radxa A7A board to
trick the SoC into detecting a 24MHz crystal while the actual input
remained 26MHz. In this case, the frequency became unstable but still
stayed around the 32.2 kHz to 33.3 kHz range.
Based on these results, it appears the hardware does attempt to
normalize the frequency towards 32.768 kHz via some internal logic.
>
>> This path reuses the same hardware mux registers as the HOSC clock.
>>
>> Additionally, this CCU provides several gate clocks for specific
>> peripherals, including SerDes, HDMI, and UFS. The driver is implemented
>> as an auxiliary driver to be bound to the sun6i-rtc driver.
>>
>> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
>> ---
>> drivers/clk/sunxi-ng/Kconfig | 5 +
>> drivers/clk/sunxi-ng/Makefile | 2 +
>> drivers/clk/sunxi-ng/ccu-sun60i-a733-rtc.c | 204 +++++++++++++++++++++++++++++
>> drivers/clk/sunxi-ng/ccu-sun60i-a733-rtc.h | 18 +++
>> drivers/clk/sunxi-ng/ccu_rtc.h | 7 +
>> 5 files changed, 236 insertions(+)
>>
[...]
>> +
>> +static const struct clk_parent_data hosc_parents[] = {
>> + { .fw_name = "osc24M" },
>> + { .fw_name = "osc19M" },
>> + { .fw_name = "osc26M" },
>> + { .fw_name = "osc24M" },
>> +};
>
> As mentioned in my reply to the binding, this is wrong. There is only
> one input.
>
> The most you can do is check the rate of the parent clock against the
> detected one, and _scream_ that the DT is wrong. And maybe override
> the reported frequency.
I will add a warning message if the frequency detected by the driver
does not match the one in the DT.
>
> If you want to do the latter, you could add a new fixed rate gated
> clock type to our library. You would fill in the rate before the
> clocks get registered. I probably wouldn't go that far. We want people
> to have correct hardware descriptions.
>
> Funnily enough Allwinner's BSP actually implements a fixed rate gate
> for the next 24M-to-32k divider clock.
Yes, I noticed that as well. I agree, and I will model this path as a
simple fixed-rate clock (32768Hz) in v2.
>
>> +
>> +struct ccu_mux hosc_clk = {
>> + .enable = DCXO_CTRL_DCXO_EN,
>> + .mux = _SUNXI_CCU_MUX(14, 2),
>> + .common = {
>> + .reg = DCXO_CTRL_REG,
>> + .hw.init = CLK_HW_INIT_PARENTS_DATA("hosc",
>> + hosc_parents,
>> + &ccu_mux_ro_ops,
>> + 0),
>> + },
>> +};
>
> So this is wrong.
>
>> +
>> +static const struct ccu_mux_fixed_prediv hosc_32k_predivs[] = {
>> + { .index = 0, .div = 732 },
>
> Why is it 732 instead of 750?
As mentioned above, the target frequency is 32.768kHz rather than
32.0kHz. However, since I will drop this prediv array and use a
fixed-rate clock instead, I think this will no longer be an issue.
--
Best regards,
Junhui Liu
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: qcom: x1e80100-microsoft-romulus: add PM8010 camera regulators
From: Konrad Dybcio @ 2026-04-10 9:49 UTC (permalink / raw)
To: Oliver White, andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: bod, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260409201717.108169-2-oliverjwhite07@gmail.com>
On 4/9/26 10:17 PM, Oliver White wrote:
> Add the PM8010 regulator outputs used by the front-facing OV02C10
> camera module on Microsoft Romulus.
>
> These rails provide the supplies referenced by the camera enablement patch.
>
> Signed-off-by: Oliver White <oliverjwhite07@gmail.com>
> ---
FWIW the regulator config is a little different, at least on my device
that reports (in device manager -> cameras -> details -> hardware IDs
or similar) to have
MSHW0470 FRONT_RGB (OV02...)
MSHW0472 FRONT_IR (ID SMO55F0, it's likely a STMicro VD55G0)
All voltages are flat, no ranges
LDO1 (RGB) 1.2 V
LDO2 (IR) 1.2 V
LDO3 (RGB) 1.8 V
LDO4 (IR) 1.8 V
LDO5 (RGB) 2.8 V
LDO6 (IR) 1.8 V
LDO7 remains unused, and would be only used with an IR sensor that's
MSHW0492 or MSHW0562
Konrad
^ permalink raw reply
* RE: [PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Yu-Chun Lin [林祐君] @ 2026-04-10 9:39 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰], linusw@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
afaerber@suse.com, TY_Chang[張子逸]
In-Reply-To: <CAMRc=MfUh_OuxS4SC6QzSOg_PMNc9i9crGYgBASrbVUgHDHSCw@mail.gmail.com>
Hi Bart,
> On Wed, 8 Apr 2026 04:52:42 +0200, Yu-Chun Lin <eleanor.lin@realtek.com>
> said:
> > From: Tzuyi Chang <tychang@realtek.com>
> >
> > Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
> >
> > Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
> > which manages pins via shared bank registers, the RTD1625 introduces a
> > per-pin register architecture. Each GPIO line now has its own
> > dedicated 32-bit control register to manage configuration
> > independently, including direction, output value, input value,
> > interrupt enable, and debounce. Therefore, this distinct hardware
> > design requires a separate driver.
> >
> > Reviewed-by: Linus Walleij <linusw@kernel.org>
> > Signed-off-by: Tzuyi Chang <tychang@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v2:
> > - Remove "default y".
> > - Add base_offset member to struct rtd1625_gpio_info to handle merged
> regions.
> > ---
> > drivers/gpio/Kconfig | 11 +
> > drivers/gpio/Makefile | 1 +
> > drivers/gpio/gpio-rtd1625.c | 584
> > ++++++++++++++++++++++++++++++++++++
> > 3 files changed, 596 insertions(+)
> > create mode 100644 drivers/gpio/gpio-rtd1625.c
> >
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index
> > 5ee11a889867..281549ad72ac 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -638,6 +638,17 @@ config GPIO_RTD
> > Say yes here to support GPIO functionality and GPIO interrupt on
> > Realtek DHC SoCs.
> >
> > +config GPIO_RTD1625
> > + tristate "Realtek DHC RTD1625 GPIO support"
> > + depends on ARCH_REALTEK || COMPILE_TEST
> > + select GPIOLIB_IRQCHIP
> > + help
> > + This option enables support for the GPIO controller on Realtek
> > + DHC (Digital Home Center) RTD1625 SoC.
> > +
> > + Say yes here to support both basic GPIO line functionality
> > + and GPIO interrupt handling capabilities for this platform.
> > +
> > config GPIO_SAMA5D2_PIOBU
> > tristate "SAMA5D2 PIOBU GPIO support"
> > depends on MFD_SYSCON
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index
> > c05f7d795c43..c95ba218d53a 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -159,6 +159,7 @@ obj-$(CONFIG_GPIO_REALTEK_OTTO)
> += gpio-realtek-otto.o
> > obj-$(CONFIG_GPIO_REG) += gpio-reg.o
> > obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
> > obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
> > +obj-$(CONFIG_GPIO_RTD1625) += gpio-rtd1625.o
> > obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
> > obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
> > obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
> > diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
> > new file mode 100644 index 000000000000..bcc1bbb115fa
> > --- /dev/null
> > +++ b/drivers/gpio/gpio-rtd1625.c
> > @@ -0,0 +1,584 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Realtek DHC RTD1625 gpio driver
> > + *
> > + * Copyright (c) 2023 Realtek Semiconductor Corp.
>
> No modifications since 2023?
>
Will include 2026.
> > + */
> > +
> > +#include <linux/bitfield.h>
> > +#include <linux/bitops.h>
> > +#include <linux/gpio/driver.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irqchip.h>
> > +#include <linux/irqchip/chained_irq.h> #include <linux/irqdomain.h>
> > +#include <linux/module.h> #include <linux/platform_device.h> #include
> > +<linux/property.h> #include <linux/spinlock.h> #include
> > +<linux/types.h>
> > +
> > +#define RTD1625_GPIO_DIR BIT(0)
> > +#define RTD1625_GPIO_OUT BIT(2)
> > +#define RTD1625_GPIO_IN BIT(4)
> > +#define RTD1625_GPIO_EDGE_INT_DP BIT(6) #define
> > +RTD1625_GPIO_EDGE_INT_EN BIT(8) #define
> RTD1625_GPIO_LEVEL_INT_EN
> > +BIT(16) #define RTD1625_GPIO_LEVEL_INT_DP BIT(18) #define
> > +RTD1625_GPIO_DEBOUNCE GENMASK(30, 28) #define
> > +RTD1625_GPIO_DEBOUNCE_WREN BIT(31)
> > +
> > +#define RTD1625_GPIO_WREN(x) ((x) << 1)
> > +
> > +/* Write-enable masks for all GPIO configs and reserved hardware bits
> > +*/ #define RTD1625_ISO_GPIO_WREN_ALL 0x8000aa8a #define
> > +RTD1625_ISOM_GPIO_WREN_ALL 0x800aaa8a
> > +
> > +#define RTD1625_GPIO_DEBOUNCE_1US 0
> > +#define RTD1625_GPIO_DEBOUNCE_10US 1
> > +#define RTD1625_GPIO_DEBOUNCE_100US 2 #define
> > +RTD1625_GPIO_DEBOUNCE_1MS 3 #define
> RTD1625_GPIO_DEBOUNCE_10MS 4
> > +#define RTD1625_GPIO_DEBOUNCE_20MS 5 #define
> > +RTD1625_GPIO_DEBOUNCE_30MS 6 #define
> RTD1625_GPIO_DEBOUNCE_50MS 7
> > +
> > +#define GPIO_CONTROL(gpio) ((gpio) * 4)
> > +
> > +/**
> > + * struct rtd1625_gpio_info - Specific GPIO register information
> > + * @num_gpios: The number of GPIOs
> > + * @irq_type_support: Supported IRQ types
> > + * @gpa_offset: Offset for GPIO assert interrupt status registers
> > + * @gpda_offset: Offset for GPIO deassert interrupt status registers
> > + * @level_offset: Offset of level interrupt status register
> > + * @write_en_all: Write-enable mask for all configurable bits */
> > +struct rtd1625_gpio_info {
> > + unsigned int num_gpios;
> > + unsigned int irq_type_support;
> > + unsigned int base_offset;
> > + unsigned int gpa_offset;
> > + unsigned int gpda_offset;
> > + unsigned int level_offset;
> > + unsigned int write_en_all;
> > +};
>
> Please remove the tabs in the above struct.
>
Ack.
> > +
> > +struct rtd1625_gpio {
> > + struct gpio_chip gpio_chip;
> > + const struct rtd1625_gpio_info *info;
> > + void __iomem *base;
> > + void __iomem *irq_base;
> > + unsigned int irqs[3];
> > + raw_spinlock_t lock;
> > + unsigned int *save_regs;
> > +};
>
> I'd also personally remove these tabs here but won't die on that hill.
>
Ack.
> > +
> > +static unsigned int rtd1625_gpio_gpa_offset(struct rtd1625_gpio
> > +*data, unsigned int offset) {
> > + return data->info->gpa_offset + ((offset / 32) * 4); }
> > +
> > +static unsigned int rtd1625_gpio_gpda_offset(struct rtd1625_gpio
> > +*data, unsigned int offset) {
> > + return data->info->gpda_offset + ((offset / 32) * 4); }
> > +
> > +static unsigned int rtd1625_gpio_level_offset(struct rtd1625_gpio
> > +*data, unsigned int offset) {
> > + return data->info->level_offset + ((offset / 32) * 4); }
>
> Looking at these, I'm under the impression that this driver could quite easily be
> converted to using gpio-mmio or even gpio-regmap with an MMIO regmap,
> have you looked into it by any chance?
>
> Bart
We did look into gpio-mmio and gpio-regmap, but they are not quite suitable for
our platform due to the specific hardware design:
1. Per-GPIO Dedicated Registers: Unlike typical GPIO controllers that pack 32 pins
into a single 32-bit register (1 bit per pin), our hardware uses a dedicated 32-bit
register for each individual GPIO. This single register controls the
input/output state, direction, and interrupt trigger type for that specific pin.
2. Write-Enable (WREN) Mask Mechanism: Our hardware requires a specific Write-Enable
mask to be written simultaneously when updating the register values.
3. Hardware Debounce: We also need to support hardware debounce settings per pin,
which requires custom configuration via set_config mapped to these specific per-pin
registers.
Because of these hardware constraints, manually implementing the gpio_chip callbacks
seems to be the most straightforward
Best Regards,
Yu-Chun
^ permalink raw reply
* [PATCH v1 0/5] Add interrupt controller for JHB100 SoC
From: Changhuang Liang @ 2026-04-10 9:01 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner,
Philipp Zabel
Cc: linux-kernel, devicetree, linux-riscv, Ley Foon Tan,
Changhuang Liang
This patchset adds external interrupt controller driver for the StarFive
JHB100 SoC. It supports up to 64 interrupt sources, and both level and
edge trigger types.
Changhuang Liang (4):
dt-bindings: interrupt-controller: Convert the word "jh8100" to
"jhb100"
irqchip: starfive: Convert the word "jh8100" to "jhb100"
irqchip: starfive: Use devm_ interfaces to simplify resource release
irqchip: starfive: Implement irq_set_type and irq_ack hooks
Mason Huo (1):
irqchip: starfive: Increase the interrupt source number up to 64
...00-intc.yaml => starfive,jhb100-intc.yaml} | 12 +-
MAINTAINERS | 6 +-
drivers/irqchip/Kconfig | 6 +-
drivers/irqchip/Makefile | 2 +-
drivers/irqchip/irq-starfive-jh8100-intc.c | 207 -------------
drivers/irqchip/irq-starfive-jhb100-intc.c | 278 ++++++++++++++++++
6 files changed, 289 insertions(+), 222 deletions(-)
rename Documentation/devicetree/bindings/interrupt-controller/{starfive,jh8100-intc.yaml => starfive,jhb100-intc.yaml} (81%)
delete mode 100644 drivers/irqchip/irq-starfive-jh8100-intc.c
create mode 100644 drivers/irqchip/irq-starfive-jhb100-intc.c
--
2.25.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox