* Re: [PATCH v9 5/9] drm/imx: Add support for i.MX94 DCIF
From: Frank Li @ 2026-06-15 14:58 UTC (permalink / raw)
To: Laurentiu Palcu
Cc: Ying Liu, Luca Ceresoli, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, linux-clk,
imx, devicetree, linux-arm-kernel, linux-kernel, dri-devel
In-Reply-To: <20260612-dcif-upstreaming-v9-5-8d0ff89aa3c5@oss.nxp.com>
On Fri, Jun 12, 2026 at 02:58:36PM +0300, Laurentiu Palcu wrote:
> The i.MX94 Display Control Interface features:
> * Up to maximum 3 layers of alpha blending:
> - 1 background layer(Layer 0);
> - 1 foreground layer(Layer 1);
> - A programmable constant color behind the background layer;
> * Each layer supports:
> - programmable plane size;
> - programmable background color;
> - embedded alpha and global alpha;
> * Data output with CRC checksum for 4 programmable regions;
>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # bridge refcounting
> Signed-off-by: Sandor Yu <sandor.yu@nxp.com>
> Co-developed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH V12 7/9] iio: imu: inv_icm42607: Add Accelerometer for icm42607
From: Chris Morgan @ 2026-06-15 14:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner, jic23,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh
In-Reply-To: <ai_gIR2d9fzHLZ-G@ashevche-desk.local>
On Mon, Jun 15, 2026 at 02:21:05PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 11, 2026 at 03:26:04PM -0500, Chris Morgan wrote:
>
> > Add icm42607 accelerometer sensor for icm42607.
>
> ...
>
> > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
>
> Please, please, use IWYU! So many headers are missing...
> (Same comment to all files in this series.)
>
> + array_size.h
> + bits.h // BIT()
> + cleanup.h // guard()()
> + device/devres.h // devm_kasprintf()
> + err.h // -EINVAL, IS_ERR()
>
> > +#include <linux/iio/iio.h>
> > +#include <linux/mutex.h>
> > +#include <linux/pm_runtime.h>
> > +#include <linux/regmap.h>
>
> + types.h // s16, __be16
>
> Also you need to have
>
> asm/byteorder.h // be16_to_cpup()
How are you running IWYU against the builds? So far I've tried but I
can't seem to get it to run properly.
>
> ...
>
> > +static int inv_icm42607_accel_read_odr(struct inv_icm42607_state *st,
> > + int *val, int *val2)
> > +{
> > + unsigned int odr;
> > + unsigned int i;
> > +
> > + guard(mutex)(&st->lock);
> > +
> > + odr = st->conf.accel.odr;
> > +
> > + for (i = 5; i < ARRAY_SIZE(inv_icm42607_accel_odr); ++i) {
>
> Why pre-increment? Same for all other cases.
The register starts at 5 and all values below 5 are invalid. Starting
this increment at 5 ensures we don't expose invalid values to
userspace.
>
> > + if (i == odr)
> > + break;
> > + }
> > + if (i >= ARRAY_SIZE(inv_icm42607_accel_odr))
> > + return -EINVAL;
> > +
> > + *val = inv_icm42607_accel_odr[i][0];
> > + *val2 = inv_icm42607_accel_odr[i][1];
> > +
> > + return IIO_VAL_INT_PLUS_MICRO;
> > +}
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Thank you,
Chris
^ permalink raw reply
* Re: [PATCH V12 5/9] iio: imu: inv_icm42607: Add PM support for icm42607
From: Chris Morgan @ 2026-06-15 14:49 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner, jic23,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh
In-Reply-To: <ai_Tzbl3sZlyrh2M@ashevche-desk.local>
On Mon, Jun 15, 2026 at 01:28:29PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 11, 2026 at 03:26:02PM -0500, Chris Morgan wrote:
>
> > Add power management support for the ICM42607 device driver.
>
> ...
>
> > +static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
> > + enum inv_icm42607_sensor_mode gyro,
> > + enum inv_icm42607_sensor_mode accel,
> > + bool temp, unsigned int *sleep_ms)
> > +{
> > + enum inv_icm42607_sensor_mode oldaccel = st->conf.accel.mode;
> > + enum inv_icm42607_sensor_mode oldgyro = st->conf.gyro.mode;
> > + bool oldtemp = st->conf.temp_en;
> > + unsigned int sleepval_ms;
> > + unsigned int val;
> > + int ret;
> > +
> > + if (gyro == oldgyro && accel == oldaccel && temp == oldtemp)
> > + return 0;
>
> This validation seems weak, see below why.
>
> > + val = FIELD_PREP(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, gyro);
> > + val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, accel);
> > + /*
> > + * Note that temp being enabled here doesn't affect PM since
> > + * per 10.25 of the datasheet the clock will be off by default
> > + * if both the gyro and accel modes are off.
> > + */
> > + if (!temp)
> > + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
> > + ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
> > + if (ret)
> > + return ret;
> > +
> > + st->conf.gyro.mode = gyro;
> > + st->conf.accel.mode = accel;
> > + st->conf.temp_en = temp;
>
> > + sleepval_ms = 0;
> > + if (temp && !oldtemp)
> > + sleepval_ms = max(sleepval_ms, INV_ICM42607_TEMP_STARTUP_TIME_MS);
> > +
> > + if (accel != oldaccel)
> > + sleepval_ms = max(sleepval_ms, INV_ICM42607_ACCEL_STARTUP_TIME_MS);
> > +
> > + if (gyro != oldgyro)
> > + sleepval_ms = max(sleepval_ms, INV_ICM42607_GYRO_STARTUP_TIME_MS);
>
> Does it mean that it might be more than a single conditional to become true?
> If so, the last code wins, which is most likely buggy approach. Can you put
> a comment, and possible convert this to if-else-if, to clarify what's going
> on here?
I've changed this logic in the next version, but basically what needs
to be done is ensure if any sensor changes from off to on we wait the
startup delay amount of time for that sensor. If more than one sensor
changes from off to on, we wait the maximum of the two sensors delay.
I'm going to change this instead to just (sensor && !oldsensor) for
each of the three. Note that I also have to insert a shutdown delay
for the gyro to ensure if the state goes from on to off the sensor is
on a minimum of 45ms per the datasheet.
So I do expect it to be possible for more than one condition to be true
here, and when it is I want to select the maximum value for the sleep.
If the sleep_ms is specified however, we will use that value.
>
> > + if (sleep_ms)
> > + *sleep_ms = sleepval_ms;
> > + else if (sleepval_ms)
> > + fsleep(sleepval_ms * USEC_PER_MSEC);
> > +
> > + return 0;
> > +}
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Thank you,
Chris
^ permalink raw reply
* Re: [PATCH 07/12] clk: qcom: gcc-mdm9607: Drop incorrect apss_tcu_clk_src
From: Konrad Dybcio @ 2026-06-15 14:44 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Georgi Djakov,
Shawn Guo, Bryan O'Donoghue, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, linux-arm-msm,
linux-clk, linux-kernel, devicetree
In-Reply-To: <ailwFPgY13_7dZ-C@linaro.org>
On 6/10/26 4:09 PM, Stephan Gerhold wrote:
> On Wed, Jun 10, 2026 at 03:50:11PM +0200, Konrad Dybcio wrote:
>> On 6/9/26 4:14 PM, Stephan Gerhold wrote:
>>> From: Stephan Gerhold <stephan@gerhold.net>
>>>
>>> This clock does not seem to exist on MDM9607. Reading/writing the registers
>>> always results in 0 or crashes. The math in the frequency table is also
>>> broken. GPLL2 on MDM9607 runs at 480 MHz, so:
>>>
>>> - F(155000000, P_GPLL2, 6, 0, 0), // 480 MHz/6 = 80 MHz, not 155 MHz
>>> - F(310000000, P_GPLL2, 3, 0, 0), // 480 MHz/3 = 160 MHz, not 310 MHz
>>>
>>> Presumably, this definition was mistakenly copied as-is from gcc-msm8916
>>> (which uses 930 MHz for GPLL2). There are no branch consumers of this root
>>> clock inside gcc-mdm9607 (notably, gcc_apss_tcu_clk has bimc_ddr_clk_src as
>>> parent instead of this clock), so we can just drop it.
>>>
>>> Cc: stable@vger.kernel.org
>>> Fixes: 48b7253264ea ("clk: qcom: Add MDM9607 GCC driver")
>>> Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
>>> ---
>>
>> It does, CMD_RCGR @ 0x37000
>>
>> Interestingly, there's also an SMMU instance.. although downstream doesn't
>> seem bothered with it
>>
>
> Thanks for checking, but that still doesn't give us enough to work with
> it. In particular:
>
> - What are the frequency tables? Which parents exist with which IDs?
> - What is the hid_width?
> - Where do we hook it up to some children?
>
> The way it is right now it's definitely wrong. I don't think we'll need
> it so removing it like this patch is probably the easiest thing to do...
>
> Thanks,
> Stephan
>
> PS: This platform has the weird TZ-managed SMMU (like MSM8916), so there
> isn't much you can do with it from Linux. Unless you are running TF-A,
> then you can describe it as "arm,mmu-500" and use it for everything
> pretty much exactly like you would normally expect. But you still don't
> need to do anything with this clock.
Alright then, let's just get rid of it
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Maxime Chevallier @ 2026-06-15 14:44 UTC (permalink / raw)
To: Christian Marangi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <6a300da0.d5af3cef.1ca29d.19c4@mx.google.com>
On 6/15/26 16:35, Christian Marangi wrote:
> On Mon, Jun 15, 2026 at 04:29:04PM +0200, Maxime Chevallier wrote:
>>
>>
>> On 6/15/26 16:10, Christian Marangi wrote:
>>> On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
>>>> Hi Christian,
>>>>
>>>> On 6/15/26 14:29, Christian Marangi wrote:
>>>>> Add support for late PCS provider attachment to a phylink instance.
>>>>> This works by creating a global notifier for the PCS provider and
>>>>> making each phylink instance that makes use of fwnode subscribe to
>>>>> this notifier.
>>>>>
>>>>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
>>>>> a new PCS provider is added.
>>>>>
>>>>> phylink will then react to this event and will call the new function
>>>>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
>>>>> provided by the event is present in the pcs-handle property of the
>>>>> phylink instance.
>>>>>
>>>>> If a related PCS is found, then such PCS is added to the phylink
>>>>> instance PCS list.
>>>>>
>>>>> Then we link the PCS to the phylink instance and we refresh the supported
>>>>> interfaces of the phylink instance.
>>>>>
>>>>> Finally we check if we are in a major_config_failed scenario and trigger
>>>>> an interface reconfiguration in the next phylink resolve.
>>>>>
>>>>> In the example scenario where the link was previously torn down due to
>>>>> removal of PCS, the link will be established again as the PCS came back
>>>>> and is now available to phylink.
>>>>>
>>>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
>>>>> if (pl->link_gpio)
>>>>> gpiod_put(pl->link_gpio);
>>>>>
>>>>> + /* Unregister notifier for late PCS attach */
>>>>> + if (pl->fwnode_pcs_nb.notifier_call)
>>>>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>>>
>>>> I wanted to try this out, but I get :
>>>>
>>>> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
>>>> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> | register_fwnode_pcs_notifier
>>>>
>>>> I guess you either need to stub this, or there's a missing Kconfig
>>>> dependency somewhere
>>>>
>>>
>>> Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
>>> the static declaration for unregister_fwnode_pcs_notifier.
>>
>> I'll give it a go with this yeah, I have a few devices here I'd like to
>> try this on.
>>
>> Can you CC me for the next rounds ?
>>
>
> Sure, if you can would be good to check also the other commit if everything
> is logically correct.
Absolutely, I'm planning on doing this :) This is quite the series though,
I'll try to give it some deeper look in the upcoming days, I expect net-next
to close soon anyways, so that's as good as it gets for reviewing this :)
Also, it's probably a good idea to have Sean in CC as well, I know a few people
interested in the Xilinx PCS his series brought, hopefully he can follow-up on
this series with the other new PCS drivers.
>
> BTW by checking test from patchwork I can see also another fix is needed if
> you want to test this revision.
>
> phylink_create()
>
> -if (config->num_possible_pcs && pl->mac_ops->mac_select_pcs) {
> +if (config->num_possible_pcs && mac_ops->mac_select_pcs) {
Ack, I'll test it with this change, thanks :)
Maxime
>
> Aside from these change I expect the current legacy code to be not
> affected by these change.
I'll probably have things to say about this "legacy" naming :)
Thanks for driving this work forwards anyway, that's
>
^ permalink raw reply
* Re: [PATCH v7 4/5] iio: adc: versal-sysmon: add threshold event support
From: Andy Shevchenko @ 2026-06-15 14:43 UTC (permalink / raw)
To: Salih Erim
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260614233722.2603459-5-salih.erim@amd.com>
On Mon, Jun 15, 2026 at 12:37:21AM +0100, Salih Erim wrote:
> Add threshold event support for temperature and supply voltage
> channels.
>
> Temperature events:
> - Rising threshold with configurable value on the device
> temperature channel (current max across all satellites)
> - Per-channel hysteresis as a millicelsius value
> - Event direction is IIO_EV_DIR_RISING (hysteresis mode)
>
> Supply voltage events:
> - Rising/falling threshold per supply channel
> - Per-channel alarm enable via alarm configuration registers
>
> The hardware supports both window and hysteresis alarm modes for
> temperature. This driver uses hysteresis mode, where the upper
> threshold triggers the alarm and the lower threshold clears it
> (re-arm point). The hardware has a single ISR bit per temperature
> channel with no indication of which threshold was crossed, so
> hysteresis mode is the natural fit. The lower threshold register
> is computed internally as (upper - hysteresis).
>
> Hysteresis is stored in the driver as a millicelsius value,
> initialized from the hardware registers at probe. Writing the
> rising threshold or hysteresis recomputes the lower register.
> ALARM_CONFIG is hard-coded to hysteresis mode during init.
>
> The hardware also provides a separate over-temperature (OT)
> threshold, but it is not exposed through IIO as it serves as a
> hardware safety mechanism for platform shutdown. OT will be
> exposed through the thermal framework in a follow-up series.
>
> The interrupt handler masks active threshold interrupts (which are
> level-sensitive) and schedules a delayed worker to poll for condition
> clear before unmasking. When no hardware IRQ is available, event
> specs are not attached and interrupt init is skipped, since the
> I2C regmap backend cannot be called from atomic context.
>
> When disabling a supply channel alarm, the group interrupt remains
> active if any other channel in the same alarm group still has an
> alarm enabled.
>
> A devm cleanup action masks all interrupts on driver unbind to
> prevent unhandled interrupt storms after the IRQ handler is freed.
...
> +static void sysmon_q8p7_to_millicelsius(s16 raw_data, int *val)
> +{
> + *val = (raw_data * (int)MILLI) >> SYSMON_FRACTIONAL_SHIFT;
MILLIDEGREE_PER_DEGREE is defined as int.
> +}
> +
> +static void sysmon_millicelsius_to_q8p7(u32 *raw_data, int val)
> +{
> + *raw_data = (val << SYSMON_FRACTIONAL_SHIFT) / (int)MILLI;
Ditto.
> +}
...
> +static void sysmon_supply_processedtoraw(int val, u32 reg_val, u32 *raw_data)
> +{
> + int exponent = FIELD_GET(SYSMON_MODE_MASK, reg_val);
> + int format = FIELD_GET(SYSMON_FMT_MASK, reg_val);
> + int scale, tmp;
> +
> + scale = BIT(SYSMON_SUPPLY_MANTISSA_BITS - exponent);
> + tmp = (val * scale) / (int)MILLI;
Due to agnosticism of this function, I dunno if the above can be applied here.
> + if (format)
> + tmp = clamp(tmp, S16_MIN, S16_MAX);
> + else
> + tmp = clamp(tmp, 0, U16_MAX);
> +
> + *raw_data = (u16)tmp;
> +}
...
> +static int sysmon_read_alarm_config(struct sysmon *sysmon,
> + unsigned long address)
> +{
> + u32 shift = address % SYSMON_ALARM_BITS_PER_REG;
> + u32 offset = SYSMON_ALARM_OFFSET(address);
> + unsigned int reg_val;
> + int ret;
> +
> + ret = regmap_read(sysmon->regmap, offset, ®_val);
> + if (ret)
> + return ret;
> +
> + return !!(reg_val & BIT(shift));
regmap_test_bits()?
> +}
...
> -static int sysmon_parse_fw(struct iio_dev *indio_dev, struct device *dev)
> +static int sysmon_parse_fw(struct iio_dev *indio_dev, struct device *dev,
> + int irq)
I would leave one line (82 characters IIANM).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 2/2] clk: renesas: r9a09g077: Add RTC clocks
From: Prabhakar @ 2026-06-15 14:39 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Magnus Damm
Cc: linux-kernel, linux-renesas-soc, linux-clk, devicetree, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615143943.1610095-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add the core and module clock definitions for the Real-Time Clock (RTC)
peripheral on the Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/clk/renesas/r9a09g077-cpg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/renesas/r9a09g077-cpg.c b/drivers/clk/renesas/r9a09g077-cpg.c
index 873c41ae5606..5640c2035e5a 100644
--- a/drivers/clk/renesas/r9a09g077-cpg.c
+++ b/drivers/clk/renesas/r9a09g077-cpg.c
@@ -149,7 +149,7 @@ static const struct rzv2h_pll_limits r9a09g077_cpg_pll3_limits = {
enum clk_ids {
/* Core Clock Outputs exported to DT */
- LAST_DT_CORE_CLK = R9A09G077_LCDC_CLKD,
+ LAST_DT_CORE_CLK = R9A09G077_PCLKRTC,
/* External Input Clocks */
CLK_EXTAL,
@@ -337,6 +337,7 @@ static const struct cpg_core_clk r9a09g077_core_clks[] __initconst = {
sel_clk_pll4d3_div10_div20, ARRAY_SIZE(sel_clk_pll4d3_div10_div20), 0),
DEF_DIV_LCDC("LCDC_CLKD", R9A09G077_LCDC_CLKD, CLK_SEL_CLK_PLL3, LCDCDIVSEL,
dtable_2_32),
+ DEF_FIXED("PCLKRTC", R9A09G077_PCLKRTC, CLK_EXTAL, 128, 1),
};
static const struct mssr_mod_clk r9a09g077_mod_clks[] __initconst = {
@@ -367,6 +368,7 @@ static const struct mssr_mod_clk r9a09g077_mod_clks[] __initconst = {
DEF_MOD("sci5fck", 600, CLK_SCI5ASYNC),
DEF_MOD("iic2", 601, R9A09G077_CLK_PCLKL),
DEF_MOD("spi3", 602, CLK_SPI3ASYNC),
+ DEF_MOD("rtc", 605, R9A09G077_CLK_PCLKL),
DEF_MOD("lcdc", 1204, R9A09G077_CLK_PCLKAL),
DEF_MOD("sdhi0", 1212, R9A09G077_CLK_PCLKAM),
DEF_MOD("sdhi1", 1213, R9A09G077_CLK_PCLKAM),
--
2.54.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: clock: renesas,r9a09g077/87: Add PCLKRTC clock ID
From: Prabhakar @ 2026-06-15 14:39 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Magnus Damm
Cc: linux-kernel, linux-renesas-soc, linux-clk, devicetree, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615143943.1610095-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add the peripheral clock ID definition for the Real-Time Clock (PCLKRTC)
on the Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs.
Note that the LCDC_CLKD clock is utilized as the operating clock source
for the RTC IP.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
include/dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h | 1 +
include/dt-bindings/clock/renesas,r9a09g087-cpg-mssr.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h b/include/dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h
index f6cb8d649a46..aa47685f329a 100644
--- a/include/dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h
+++ b/include/dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h
@@ -35,5 +35,6 @@
#define R9A09G077_XSPI_CLK1 23
#define R9A09G077_PCLKCAN 24
#define R9A09G077_LCDC_CLKD 25
+#define R9A09G077_PCLKRTC 26
#endif /* __DT_BINDINGS_CLOCK_RENESAS_R9A09G077_CPG_H__ */
diff --git a/include/dt-bindings/clock/renesas,r9a09g087-cpg-mssr.h b/include/dt-bindings/clock/renesas,r9a09g087-cpg-mssr.h
index 312e563b322e..1c73d0dcef18 100644
--- a/include/dt-bindings/clock/renesas,r9a09g087-cpg-mssr.h
+++ b/include/dt-bindings/clock/renesas,r9a09g087-cpg-mssr.h
@@ -35,5 +35,6 @@
#define R9A09G087_XSPI_CLK1 23
#define R9A09G087_PCLKCAN 24
#define R9A09G087_LCDC_CLKD 25
+#define R9A09G087_PCLKRTC 26
#endif /* __DT_BINDINGS_CLOCK_RENESAS_R9A09G087_CPG_H__ */
--
2.54.0
^ permalink raw reply related
* [PATCH 0/2] Add RTC clocks for R9A09G077/87
From: Prabhakar @ 2026-06-15 14:39 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Magnus Damm
Cc: linux-kernel, linux-renesas-soc, linux-clk, devicetree, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi all,
This patch series adds RTC clocks for R9A09G077/87 SoCs. The first patch
adds the PCLKRTC clock ID to the device tree bindings, and the second
patch adds the RTC clocks to the Renesas R9A09G077 clock driver.
Note this patch series applies on top of the patch series "Add PLL3 and
LCDC_CLKD support for RZ/T2H and RZ/N2H" [0].
[0] https://lore.kernel.org/all/20260615104845.4122868-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
Cheers,
Prabhakar
Lad Prabhakar (2):
dt-bindings: clock: renesas,r9a09g077/87: Add PCLKRTC clock ID
clk: renesas: r9a09g077: Add RTC clocks
drivers/clk/renesas/r9a09g077-cpg.c | 4 +++-
include/dt-bindings/clock/renesas,r9a09g077-cpg-mssr.h | 1 +
include/dt-bindings/clock/renesas,r9a09g087-cpg-mssr.h | 1 +
3 files changed, 5 insertions(+), 1 deletion(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v5 4/4] arm64: dts: nuvoton: npcm845-evb: Add peripheral nodes
From: sashiko-bot @ 2026-06-15 14:38 UTC (permalink / raw)
To: Tomer Maimon; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260615142548.1373799-5-tmaimon77@gmail.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] The reserved memory region 'tip_reserved' for the TIP firmware lacks the 'no-map' property, which will cause memory corruption or speculative access crashes.
- [High] The `cooling-levels` property in the `&pwm_fan` sub-nodes is configured as a standard 32-bit integer array (`<127 255>`) instead of an 8-bit integer array (`/bits/ 8 <127 255>`).
- [Medium] Aliases 'fiu1' and 'fiu3' are cross-assigned to '&fiu3' and '&fiu1', contradicting their fixed-partition labels.
- [Low] The property 'snps,eee-force-disable' is undocumented and is not parsed by any kernel driver.
- [Low] Duplicate unit-address in `fiu0` flash partitions.
--
commit 157ec4fb1bc26d1a937aeb0fed0b00add10a7c95
Author: Tomer Maimon <tmaimon77@gmail.com>
arm64: dts: nuvoton: npcm845-evb: Add peripheral nodes
Enable peripheral support for the NPCM845 evaluation board by wiring up
the SoC controller nodes to the board design. Add board aliases, GPIO-backed
MDIO buses, reserved memory, flash partitions, and various controllers.
> diff --git a/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts b/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
> index 5edf5d13342da..28dbb865d739d 100644
> --- a/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
> +++ b/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
> @@ -10,6 +10,42 @@ / {
>
> aliases {
> serial0 = &serial0;
> + ethernet1 = &gmac1;
[ ... ]
> + mdio-gpio1 = &mdio1;
> + fiu0 = &fiu0;
> + fiu1 = &fiu3;
> + fiu2 = &fiux;
> + fiu3 = &fiu1;
[Severity: Medium]
Does this alias mapping intentionally cross-assign fiu1 to &fiu3 and fiu3 to
&fiu1?
Looking further down in the patch, the partition under &fiu1 is explicitly
labeled spi1-system1, and the partition under &fiu3 is labeled spi3-system1.
This swap could cause user-space confusion by mapping /dev/mtd1 to a partition
labeled spi3-system1 and /dev/mtd3 to a partition labeled spi1-system1.
[ ... ]
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + tip_reserved: tip@0 {
> + reg = <0x0 0x0 0x0 0x6200000>;
> + };
> + };
[Severity: High]
Without the no-map property, will the kernel map this 98MB reserved memory
region into the standard linear mapping with cacheable attributes?
Since this memory belongs to the TIP coprocessor, the ARM64 CPU might
aggressively perform speculative instruction prefetches and data loads here.
Could this lead to corrupted non-coherent working state via cache line
evictions, or trigger fatal asynchronous SErrors and synchronous external
aborts if the memory is hardware-protected by TrustZone?
[ ... ]
> +&gmac1 {
> + phy-mode = "rgmii-id";
> + snps,eee-force-disable;
> + status = "okay";
> +};
[Severity: Low]
Is the snps,eee-force-disable property supported? It does not appear in the
snps,dwmac DT binding schema and seems to be ignored by the stmmac driver.
This appears to be a dead configuration that triggers a dt-schema violation.
[ ... ]
> +&fiu0 {
> + status = "okay";
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + spi-rx-bus-width = <1>;
> + reg = <0>;
> + spi-max-frequency = <5000000>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + bmc@0 {
> + label = "bmc";
> + reg = <0x00000000 0x04000000>;
> + };
> + u-boot@0 {
> + label = "u-boot";
> + reg = <0x00000000 0x007C0000>;
> + };
[Severity: Low]
Both the bmc and u-boot partitions are using the @0 unit-address. Does this
result in a duplicate unit-address warning from the devicetree compiler?
[ ... ]
> +&pwm_fan {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm0_pins &pwm1_pins
[ ... ]
> + #address-cells = <1>;
> + #size-cells = <0>;
> + fan@0 {
> + reg = <0x00>;
> + fan-tach-ch = /bits/ 8 <0x0 0x1>;
> + cooling-levels = <127 255>;
> + };
[Severity: High]
Should the cooling-levels property be configured as an 8-bit array, matching
the fan-tach-ch format, such as /bits/ 8 <127 255>?
The Nuvoton PWM fan driver parses this property using
of_property_read_u8_array() and of_property_count_u8_elems().
Since the DT property is authored as two 32-bit big-endian integers, it
consumes 8 bytes total. The driver might incorrectly count 8 elements and
parse them as an array of [0, 0, 0, 127, 0, 0, 0, 255].
Could this corrupt the thermal control map and shut the fans off completely
at intermediate or critical temperatures?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615142548.1373799-1-tmaimon77@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v2 4/5] arm64: dts: exynos: add initial support for Samsung Exynos8855 smdk
From: Peter Griffin @ 2026-06-15 14:37 UTC (permalink / raw)
To: Alim Akhtar
Cc: krzk, robh, conor+dt, linusw, linux-samsung-soc, linux-kernel,
devicetree, linux-gpio, hajun.sung
In-Reply-To: <20260615085252.1964423-5-alim.akhtar@samsung.com>
Hi Alim,
On Mon, 15 Jun 2026 at 09:34, Alim Akhtar <alim.akhtar@samsung.com> wrote:
>
> Add initial devicetree support for Samsung smdk board using
> Exynos8855 SoC.
I think it would be worthwhile adding a more verbose description of
the Exynos8855 SoC in the commit message e.g. a brief list of the
major IPs on the SoC.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
[..]
> diff --git a/arch/arm64/boot/dts/exynos/exynos8855-smdk.dts b/arch/arm64/boot/dts/exynos/exynos8855-smdk.dts
> new file mode 100644
> index 000000000000..f5132bcaa47c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos8855-smdk.dts
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Samsung Exynos8855 SMDK board device tree source
> + *
> + * Copyright (C) 2026 Samsung Electronics Co., Ltd.
> + *
> + * Device tree source file for WinLink's E850-96 board which is based on
> + * Samsung Exynos8855 SoC.
E850-96 isn't based on the Exynos8855 SoC. I guess it's leftover from
a copy/paste.
regards,
Peter
> + */
> +
> +/dts-v1/;
> +
> +#include "exynos8855.dtsi"
> +
> +/ {
> + model = "Samsung Exynos8855 SMDK board";
> + compatible = "samsung,exynos8855-smdk","samsung,exynos8855";
> +
> + chosen {
> + };
> +
> + memory@80000000 {
> + device_type = "memory";
> + reg = <0x0 0x80000000 0x80000000>;
> + };
> +
> +};
> +
> +&oscclk {
> + clock-frequency = <76800000>;
> +};
> +
> diff --git a/arch/arm64/boot/dts/exynos/exynos8855.dtsi b/arch/arm64/boot/dts/exynos/exynos8855.dtsi
> new file mode 100644
> index 000000000000..d403f41bbecb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos8855.dtsi
> @@ -0,0 +1,199 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Samsung Exynos8855 SoC device tree source
> + *
> + * Copyright (C) 2023 Samsung Electronics Co., Ltd.
> + *
> + * Samsung Exynos8855 SoC device nodes are listed in this file.
> + * Exynos8855 based board files can include this file and provide
> + * values for board specific bindings.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + compatible = "samsung,exynos8855";
> + #address-cells = <2>;
> + #size-cells = <1>;
> +
> + interrupt-parent = <&gic>;
> +
> + aliases {
> + pinctrl0 = &pinctrl_alive;
> + pinctrl1 = &pinctrl_cmgp;
> + pinctrl2 = &pinctrl_hsi_ufs;
> + pinctrl3 = &pinctrl_peric;
> + pinctrl4 = &pinctrl_pericmmc;
> + pinctrl5 = &pinctrl_usi;
> + };
> +
> + oscclk: clock-oscclk {
> + compatible = "fixed-clock";
> + clock-output-names = "oscclk";
> + #clock-cells = <0>;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> + core1 {
> + cpu = <&cpu1>;
> + };
> + core2 {
> + cpu = <&cpu2>;
> + };
> + core3 {
> + cpu = <&cpu3>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <&cpu4>;
> + };
> + core1 {
> + cpu = <&cpu5>;
> + };
> + core2 {
> + cpu = <&cpu6>;
> + };
> + };
> +
> + cluster2 {
> + core0 {
> + cpu = <&cpu7>;
> + };
> + };
> + };
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a520";
> + reg = <0x0>;
> + enable-method = "psci";
> + };
> +
> + cpu1: cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a520";
> + reg = <0x100>;
> + enable-method = "psci";
> + };
> +
> + cpu2: cpu@200 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a520";
> + reg = <0x200>;
> + enable-method = "psci";
> + };
> +
> + cpu3: cpu@300 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a520";
> + reg = <0x300>;
> + enable-method = "psci";
> + };
> +
> + cpu4: cpu@400 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a720";
> + reg = <0x400>;
> + enable-method = "psci";
> + };
> +
> + cpu5: cpu@500 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a720";
> + reg = <0x500>;
> + enable-method = "psci";
> + };
> +
> + cpu6: cpu@600 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a720";
> + reg = <0x600>;
> + enable-method = "psci";
> + };
> +
> + cpu7: cpu@700 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a720";
> + reg = <0x700>;
> + enable-method = "psci";
> + };
> + };
> +
> + psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> +
> + soc: soc@0 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x20000000>;
> +
> + gic: interrupt-controller@10200000 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x10200000 0x10000>,
> + <0x10240000 0x140000>;
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + pinctrl_alive: pinctrl@11850000 {
> + compatible = "samsung,exynos8855-pinctrl";
> + reg = <0x11850000 0x1000>;
> +
> + wakeup-interrupt-controller {
> + compatible = "samsung,exynos850-wakeup-eint",
> + "samsung,exynos7-wakeup-eint";
> + };
> + };
> +
> + pinctrl_cmgp: pinctrl@12030000 {
> + compatible = "samsung,exynos8855-pinctrl";
> + reg = <0x12030000 0x1000>;
> + };
> +
> + pinctrl_usi: pinctrl@15030000 {
> + compatible = "samsung,exynos8855-pinctrl";
> + reg = <0x15030000 0x1000>;
> + };
> +
> + pinctrl_peric: pinctrl@15440000 {
> + compatible = "samsung,exynos8855-pinctrl";
> + reg = <0x15440000 0x1000>;
> + };
> +
> + pinctrl_pericmmc: pinctrl@154f0000 {
> + compatible = "samsung,exynos8855-pinctrl";
> + reg = <0x154f0000 0x1000>;
> + };
> +
> + pinctrl_hsi_ufs: pinctrl@17040000 {
> + compatible = "samsung,exynos8855-pinctrl";
> + reg = <0x17040000 0x1000>;
> + };
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + /* Hypervisor Virtual Timer interrupt is not wired to GIC */
> + interrupts =
> + <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
> + };
> +};
> +
> +#include "exynos8855-pinctrl.dtsi"
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Christian Marangi @ 2026-06-15 14:35 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <7702ac09-75fd-49de-8ad2-fceaa122b627@bootlin.com>
On Mon, Jun 15, 2026 at 04:29:04PM +0200, Maxime Chevallier wrote:
>
>
> On 6/15/26 16:10, Christian Marangi wrote:
> > On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
> >> Hi Christian,
> >>
> >> On 6/15/26 14:29, Christian Marangi wrote:
> >>> Add support for late PCS provider attachment to a phylink instance.
> >>> This works by creating a global notifier for the PCS provider and
> >>> making each phylink instance that makes use of fwnode subscribe to
> >>> this notifier.
> >>>
> >>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
> >>> a new PCS provider is added.
> >>>
> >>> phylink will then react to this event and will call the new function
> >>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
> >>> provided by the event is present in the pcs-handle property of the
> >>> phylink instance.
> >>>
> >>> If a related PCS is found, then such PCS is added to the phylink
> >>> instance PCS list.
> >>>
> >>> Then we link the PCS to the phylink instance and we refresh the supported
> >>> interfaces of the phylink instance.
> >>>
> >>> Finally we check if we are in a major_config_failed scenario and trigger
> >>> an interface reconfiguration in the next phylink resolve.
> >>>
> >>> In the example scenario where the link was previously torn down due to
> >>> removal of PCS, the link will be established again as the PCS came back
> >>> and is now available to phylink.
> >>>
> >>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> >>> ---
> >>
> >> [...]
> >>
> >>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
> >>> if (pl->link_gpio)
> >>> gpiod_put(pl->link_gpio);
> >>>
> >>> + /* Unregister notifier for late PCS attach */
> >>> + if (pl->fwnode_pcs_nb.notifier_call)
> >>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> >>
> >> I wanted to try this out, but I get :
> >>
> >> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
> >> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> | register_fwnode_pcs_notifier
> >>
> >> I guess you either need to stub this, or there's a missing Kconfig
> >> dependency somewhere
> >>
> >
> > Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
> > the static declaration for unregister_fwnode_pcs_notifier.
>
> I'll give it a go with this yeah, I have a few devices here I'd like to
> try this on.
>
> Can you CC me for the next rounds ?
>
Sure, if you can would be good to check also the other commit if everything
is logically correct.
BTW by checking test from patchwork I can see also another fix is needed if
you want to test this revision.
phylink_create()
-if (config->num_possible_pcs && pl->mac_ops->mac_select_pcs) {
+if (config->num_possible_pcs && mac_ops->mac_select_pcs) {
Aside from these change I expect the current legacy code to be not
affected by these change.
--
Ansuel
^ permalink raw reply
* Re: [PATCH v3 02/10] Input: cap11xx - remove unused register macros
From: sashiko-bot @ 2026-06-15 14:34 UTC (permalink / raw)
To: Jun Yan; +Cc: conor+dt, dmitry.torokhov, robh, devicetree, linux-input
In-Reply-To: <20260615142103.352163-3-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] Removing sensor delta registers from the volatile register list causes regmap to incorrectly cache their values, breaking debugfs observability.
Pre-existing issues:
- [High] The driver requests its IRQ after registering the input device, creating a race condition where an unhandled interrupt can permanently disable the device.
--
commit 72bbdd7bb3155f054afabfd004f5e097d568001b
Author: Jun Yan <jerrysteve1101@gmail.com>
Input: cap11xx - remove unused register macros
Remove unused register address macros and unused definitions in
the cap11xx_reg_defaults array and cap11xx_volatile_reg. This cleanup
reduces code clutter and makes the driver easier to maintain.
> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index 485d8ba977235..686174722204c 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
[ ... ]
> @@ -149,12 +97,6 @@ static bool cap11xx_volatile_reg(struct device *dev, unsigned int reg)
> switch (reg) {
> case CAP11XX_REG_MAIN_CONTROL:
> case CAP11XX_REG_SENSOR_INPUT:
> - case CAP11XX_REG_SENOR_DELTA(0):
> - case CAP11XX_REG_SENOR_DELTA(1):
> - case CAP11XX_REG_SENOR_DELTA(2):
> - case CAP11XX_REG_SENOR_DELTA(3):
> - case CAP11XX_REG_SENOR_DELTA(4):
> - case CAP11XX_REG_SENOR_DELTA(5):
[Severity: Medium]
Does removing the sensor delta registers from the volatile list cause a
regression for observability via the regmap debugfs interface?
These registers contain real-time capacitance delta hardware values that are
continuously updated by the device. Treating them as non-volatile causes
regmap to cache them on the first read, resulting in stale values for any
subsequent reads by tuning tools or developers.
> return true;
> }
>
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a pre-existing probe
ordering flaw in cap11xx_i2c_probe():
error = input_register_device(priv->idev);
if (error)
return error;
error = devm_request_threaded_irq(dev, i2c_client->irq,
NULL, cap11xx_thread_func,
IRQF_ONESHOT, dev_name(dev), priv);
Could this sequence lead to the interrupt being permanently disabled?
Since input_register_device() exposes the device to userspace, a daemon
can immediately open the device, waking the sensor from deep sleep.
If the sensor generates a hardware interrupt before
devm_request_threaded_irq() completes, the generic IRQ core will receive an
interrupt with no registered handler.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615142103.352163-1-jerrysteve1101@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Daniel Lezcano @ 2026-06-15 14:33 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Gaurav Kohli, Krzysztof Kozlowski, Bjorn Andersson,
Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Amit Kucheria, Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <hebyboondtxyyetwuwggoiysurz335xzn7asf6yit3qrexap3x@kngk2m5xum3x>
Le 15/06/2026 à 16:11, Dmitry Baryshkov a écrit :
> On Mon, Jun 15, 2026 at 02:30:49PM +0200, Daniel Lezcano wrote:
>> Hi Gaurav,
>>
>> Le 15/06/2026 à 14:12, Gaurav Kohli a écrit :
>>>
>>>
>>> On 6/15/2026 4:04 PM, Daniel Lezcano wrote:
>>>> On 6/13/26 13:05, Gaurav Kohli wrote:
>>>>>
>>>>>
>>>>> On 6/13/2026 1:11 PM, Krzysztof Kozlowski wrote:
>>>>>> On 12/06/2026 15:52, Gaurav Kohli wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 6/11/2026 5:53 PM, Krzysztof Kozlowski wrote:
>>>>>>>> On 11/06/2026 13:12, Gaurav Kohli wrote:
>>>>>>>>>> Why? And where is this generic property defined? You cannot just
>>>>>>>>>> sprinkle generic properties in random bindings.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ack, will add why part.
>>>>>>>>> These names are matched with the thermal
>>>>>>>>> mitigation device identifiers
>>>>>>>>> populated by remote firmware over QMI and define
>>>>>>>>> mitigation devices are
>>>>>>>>> exposed as cooling devices.
>>>>>>>>
>>>>>>>> No, -names correspond to values passed via DT, not
>>>>>>>> some remote firmware.
>>>>>>>> The remote firmware should give you interface which
>>>>>>>> is explicit and does
>>>>>>>> not need such properties.
>>>>>>>
>>>>>>> thanks Krzysztof for review, We need tmd-names because
>>>>>>> of following reasons:
>>>>>>>
>>>>>>> Following Daniel's series [1], the thermal framework supports
>>>>>>> mapping multiple cooling devices per remoteproc/device via indexed
>>>>>>> cooling-cells.
>>>>>>>
>>>>>>> 1) The thermal framework's cooling-maps reference
>>>>>>> cooling devices by index (for #cooling-cells = <3>).
>>>>>>> Without tmd- names,
>>>>>>> there's no way to know which index corresponds to which
>>>>>>> TMD, as firmware
>>>>>>> may return tmd-names in any order.
>>>>>>>
>>>>>>> below are the changes post new thermal mapping changes:
>>>>>>> DT: tmd-names = "cdsp_sw", "xyz";
>>>>>>> Firmware: ["cdsp_sw", "xyz1", "xyz2",]
>>>>>>> Driver registers: Only "cdsp_sw" (index 0) and "xyz" (index 1)
>>>>>>
>>>>>> names property are not to instruct drivers to register or not to
>>>>>> register something.
>>>>>>
>>>>>> I don't understand the problem and explanation in the binding is
>>>>>> basically non-existing.
>>>>>>
>>>>>> Remember that all lists and indices ARE FIXED, so driver knows exactly
>>>>>> which index means what.
>>>>>>
>>>>>
>>>>> thanks for review, shall i use driver data, which is basically
>>>>> pas data structure like below:
>>>>>
>>>>> static const struct qcom_pas_data {
>>>>> .crash_reason_smem = 601,
>>>>> .firmware_name = "cdsp.mdt",
>>>>> .tmd_names = (const char *[]){"xyz", NULL},
>>>>> .num_tmds = 1,
>>>>>
>>>>> Is something like above acceptable? and this will also help to
>>>>> filter tmd names as well?
>>>>
>>>>
>>>> How the thermal framework will bind the thermal zone with the TMD ?
>>>> (node pointer, id) ?
>>>>
>>>
>>> Hi Daniel,
>>>
>>> thanks for review.
>>>
>>> With id only, in this case instead of taking tmd names from device tree,
>>> qmi_tmd will take tmd name from pas_data(driver) and register with the
>>> cooling framework with id only. Please let us know if this looks fine.
>> May be I'm missing something but:
>>
>> - The QMI TMD returns a list of names, not ids
>> - The QMI TMD may return the list in different order than assumed
>> - The cooling map index points to the name of the TMD in the DT
>> - This name is used to match the name in the aformentionned list
>> - The index in the list and the id in the DT can differ
>
> Would it be better if we define standard indices for the standard names?
> This way we decouple the actual firmware strings from the DT.
I don't think so, it seems to me too fragile and prone to error.
It is a remote proc, an external subsystem. The contract between the
client and the server is the protocol. The protocol specifies the
identifier as named strings, the TMD names, not numerical identifiers.
When asking for the list of TMDs, we get a list of strings. But as it is
an external subsystems, may be tomorrow someone decide to send list
ordered alphabetically, or per number of states, or whatever.
With hardcoded id the QMI TMD clients break
>> Krzysztof , I don't get why having the TMD names as properties is wrong,
>> they describes the existing TMDs on the system and the cooling maps index
>> points to the one to be connected with thermal zone.
>
^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: qcom: sc8180x-primus: Describe the display power net
From: sashiko-bot @ 2026-06-15 14:31 UTC (permalink / raw)
To: Konrad Dybcio; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260615-topic-8180_disp_power-v1-2-18d36b548c48@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Typo in pinctrl node name: 'blw-pwr-en-state' instead of 'bl-pwr-en-state'.
--
commit 811dfdf2795d7b72d8bd9ca1c392faa696962302
Author: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
arm64: dts: qcom: sc8180x-primus: Describe the display power net
This commit describes and wires up the power supplies for the eDP panel and
its backlight. Previously, this was only working because of settings
inherited from the bootloader.
> diff --git a/arch/arm64/boot/dts/qcom/sc8180x-primus.dts b/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
> index ffe7c45366ed4..ed4f7f10e3768 100644
> --- a/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8180x-primus.dts
[ ... ]
> @@ -769,6 +803,12 @@ &wifi {
> };
>
> /* PINCTRL */
> +&pmc8180_2_gpios {
> + bl_pwr_en: blw-pwr-en-state {
[Severity: Low]
This isn't a bug, but there appears to be a typo in the pinctrl node name.
Should "blw-pwr-en-state" be "bl-pwr-en-state" to match the typical naming
conventions for backlight pin states?
> + pins = "gpio1";
> + function = "normal";
> + };
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-8180_disp_power-v1-0-18d36b548c48@oss.qualcomm.com?part=2
^ permalink raw reply
* Re: [PATCH v7 3/5] iio: adc: versal-sysmon: add I2C driver
From: Andy Shevchenko @ 2026-06-15 14:30 UTC (permalink / raw)
To: Salih Erim
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260614233722.2603459-4-salih.erim@amd.com>
On Mon, Jun 15, 2026 at 12:37:20AM +0100, Salih Erim wrote:
> Add an I2C transport driver for the Versal SysMon block. The SysMon
> provides an I2C slave interface that allows an external master to
> read voltage and temperature measurements through the same register
> map used by the MMIO path.
>
> The I2C command frame is an 8-byte structure containing a 4-byte data
> payload, a 2-byte register offset, and a 1-byte instruction field.
> Read operations send the frame with a read instruction, then receive
> a 4-byte response containing the register value.
>
> Events are not supported on the I2C path because there is no
> interrupt line and the I2C regmap backend cannot be called from
> atomic context.
...
> +static const struct regmap_config sysmon_i2c_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = SYSMON_REG_STRIDE,
> + .max_register = SYSMON_MAX_REG,
> + .reg_read = sysmon_i2c_reg_read,
> + .reg_write = sysmon_i2c_reg_write,
> +};
No cache?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Maxime Chevallier @ 2026-06-15 14:29 UTC (permalink / raw)
To: Christian Marangi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <6a3007ce.73de60af.3a056d.d903@mx.google.com>
On 6/15/26 16:10, Christian Marangi wrote:
> On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
>> Hi Christian,
>>
>> On 6/15/26 14:29, Christian Marangi wrote:
>>> Add support for late PCS provider attachment to a phylink instance.
>>> This works by creating a global notifier for the PCS provider and
>>> making each phylink instance that makes use of fwnode subscribe to
>>> this notifier.
>>>
>>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
>>> a new PCS provider is added.
>>>
>>> phylink will then react to this event and will call the new function
>>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
>>> provided by the event is present in the pcs-handle property of the
>>> phylink instance.
>>>
>>> If a related PCS is found, then such PCS is added to the phylink
>>> instance PCS list.
>>>
>>> Then we link the PCS to the phylink instance and we refresh the supported
>>> interfaces of the phylink instance.
>>>
>>> Finally we check if we are in a major_config_failed scenario and trigger
>>> an interface reconfiguration in the next phylink resolve.
>>>
>>> In the example scenario where the link was previously torn down due to
>>> removal of PCS, the link will be established again as the PCS came back
>>> and is now available to phylink.
>>>
>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>> ---
>>
>> [...]
>>
>>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
>>> if (pl->link_gpio)
>>> gpiod_put(pl->link_gpio);
>>>
>>> + /* Unregister notifier for late PCS attach */
>>> + if (pl->fwnode_pcs_nb.notifier_call)
>>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>
>> I wanted to try this out, but I get :
>>
>> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
>> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> | register_fwnode_pcs_notifier
>>
>> I guess you either need to stub this, or there's a missing Kconfig
>> dependency somewhere
>>
>
> Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
> the static declaration for unregister_fwnode_pcs_notifier.
I'll give it a go with this yeah, I have a few devices here I'd like to
try this on.
Can you CC me for the next rounds ?
Maxime
>
^ permalink raw reply
* Re: [PATCH v3 06/10] Input: cap11xx - add reset gpio support
From: sashiko-bot @ 2026-06-15 14:29 UTC (permalink / raw)
To: Jun Yan; +Cc: linux-input, robh, dmitry.torokhov, conor+dt, devicetree
In-Reply-To: <20260615142103.352163-7-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Coding style violations: redundant 'else' after 'return' and inconsistent brace usage.
--
commit 2a7317102372f10d4bd76864cfeaec2d7955c415
Author: Jun Yan <jerrysteve1101@gmail.com>
Input: cap11xx - add reset gpio support
This commit adds support for an optional hardware reset pin on CAP11xx
devices to improve reliability and ensure proper initialization during probe.
> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
[ ... ]
> @@ -452,6 +457,16 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
> if (IS_ERR(priv->regmap))
> return PTR_ERR(priv->regmap);
>
> + priv->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->reset_gpio))
> + return dev_err_probe(dev, PTR_ERR(priv->reset_gpio),
> + "Failed to get 'reset' GPIO\n");
> + else if (priv->reset_gpio) {
[Severity: Low]
This isn't a bug, but does this follow the standard kernel coding style?
Since the preceding if statement ends with a return, the else keyword here
is redundant. Additionally, kernel style guidelines generally prefer that if
one branch of a conditional requires braces, all branches should use them.
Could this be simplified by dropping the else and just using a separate if
statement for checking priv->reset_gpio?
> + usleep_range(CAP11XX_T_RST_FILT_MIN_US, CAP11XX_T_RST_FILT_MIN_US * 2);
> + gpiod_set_value_cansleep(priv->reset_gpio, 0);
> + msleep(CAP11XX_T_RST_ON_MIN_MS);
> + }
> +
> error = regmap_read(priv->regmap, CAP11XX_REG_PRODUCT_ID, &val);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615142103.352163-1-jerrysteve1101@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v7 5/5] iio: adc: versal-sysmon: add oversampling support
From: Andy Shevchenko @ 2026-06-15 14:28 UTC (permalink / raw)
To: Salih Erim
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260614233722.2603459-6-salih.erim@amd.com>
On Mon, Jun 15, 2026 at 12:37:22AM +0100, Salih Erim wrote:
> Add support for reading and writing the oversampling ratio through
> the IIO oversampling_ratio attribute. The hardware supports averaging
> 2, 4, 8, or 16 samples, plus a ratio of 1 (no averaging).
>
> Temperature and supply channels share oversampling configuration at
> the type level (all temperature channels share one ratio, all supply
> channels share another), exposed through info_mask_shared_by_type.
>
> The hardware encoding uses sample_count / 2 in a 4-bit field within
> the CONFIG register. Per-channel averaging enable registers must also
> be updated to activate or deactivate averaging.
...
> +static int sysmon_osr_write_temp(struct sysmon *sysmon, int val)
> +{
> + /*
> + * HW register encoding is sample_count / 2:
> + * 0=none, 1=2x, 2=4x, 4=8x, 8=16x (not log2-based).
> + */
> + int hw_val = val >> 1;
If, for some reason, val happens to be a small negative number, here might be
a surprising behaviour.
> + unsigned int readback;
> + int ret;
> +
> + ret = regmap_update_bits(sysmon->regmap, SYSMON_CONFIG,
> + SYSMON_CONFIG_TEMP_SAT_OSR,
> + FIELD_PREP(SYSMON_CONFIG_TEMP_SAT_OSR, hw_val));
> + if (ret)
> + return ret;
> +
> + /*
> + * Readback fence: the SysMon CONFIG register resides in the
> + * PMC domain behind the NoC. A posted write may not reach the
> + * hardware before the next MMIO access. Reading the register
> + * back forces the interconnect to complete the write, preventing
> + * a bus hang on the subsequent access.
> + */
> + regmap_read(sysmon->regmap, SYSMON_CONFIG, &readback);
> +
> + return sysmon_set_avg_enable(sysmon, SYSMON_TEMP_EN_AVG_BASE,
> + SYSMON_TEMP_EN_AVG_COUNT,
> + hw_val ? ~0U : 0);
Is the last parameter > 32-bit? If not, drop 'U' as it might have a nice
side-effect in case this become actually > 32-bit. Same for other cases.
In other words, using ~0U should be quite cautious.
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net-next v5 12/15] onsemi: s2500: Add driver support for TS2500 MAC-PHY
From: Julian Braha @ 2026-06-15 14:27 UTC (permalink / raw)
To: Selvamani.Rajagopal, Andrew Lunn, Piergiorgio Beruto,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Andrew Lunn, Parthiban Veerasooran,
Richard Cochran, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan
Cc: netdev, linux-kernel, devicetree, linux-doc, Jerry Ray
In-Reply-To: <20260614-s2500-mac-phy-support-v5-12-89874b72f725@onsemi.com>
Hi Selvamani,
On 6/14/26 18:00, Selvamani Rajagopal via B4 Relay wrote:
> diff --git a/drivers/net/ethernet/onsemi/Kconfig b/drivers/net/ethernet/onsemi/Kconfig
> new file mode 100644
> index 000000000000..8d72194151ea
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/Kconfig
> @@ -0,0 +1,21 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# onsemi network device configuration
> +#
> +
> +config NET_VENDOR_ONSEMI
> + bool "onsemi network devices"
> + help
> + If you have a network card belonging to this class, say Y.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about onsemi ethernet devices. If you say Y, you
> + will be asked for your specific card in the following questions.
> +
> +if NET_VENDOR_ONSEMI
> +
> +source "drivers/net/ethernet/onsemi/s2500/Kconfig"
> +
> +endif # NET_VENDOR_ONSEMI
When you put the 'if NET_VENDOR_ONSEMI' around the 'source', you're
making it a dependency on every config option in that sourced Kconfig.
> diff --git a/drivers/net/ethernet/onsemi/s2500/Kconfig b/drivers/net/ethernet/onsemi/s2500/Kconfig
> new file mode 100644
> index 000000000000..f2e8d5d1429d
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/Kconfig
> @@ -0,0 +1,21 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# onsemi S2500 Driver Support
> +#
> +
> +if NET_VENDOR_ONSEMI
> +
> +config S2500_MACPHY
> + tristate "S2500 support"
> + depends on SPI
> + select NCN26000_PHY
> + select OA_TC6
> + help
> + Support for the onsemi TS2500 MACPHY Ethernet chip.
> + It works under the framework that conform to OPEN Alliance
> + 10BASE-T1x Serial Interface specification.
> +
> + To compile this driver as a module, choose M here. The module will be
> + called s2500.
> +
> +endif # NET_VENDOR_ONSEMI
Which means that when you add 'if NET_VENDOR_ONSEMI' again inside the
sourced Kconfig, it's a duplicate dependency.
I think putting the if-endif in either place is fine, but it's redundant
to do it twice. You could maybe consider using a comment for the second
instance instead.
- Julian Braha
^ permalink raw reply
* [PATCH v5 4/4] arm64: dts: nuvoton: npcm845-evb: Add peripheral nodes
From: Tomer Maimon @ 2026-06-15 14:25 UTC (permalink / raw)
To: andrew, robh, krzk+dt, conor+dt
Cc: openbmc, devicetree, linux-kernel, avifishman70, tmaimon77,
tali.perry1, venture, yuenn, benjaminfair
In-Reply-To: <20260615142548.1373799-1-tmaimon77@gmail.com>
Enable peripheral support for the NPCM845 evaluation board by wiring up
the SoC controller nodes to the board design. Add board aliases,
GPIO-backed MDIO buses for the external PHYs, a reserved-memory region
for TIP firmware, and flash partitions for the FIU boot flash. Enable
the Ethernet MACs, MMC controller, FIU controllers, USB device
controllers, ADC, RNG, PWM/FAN controller, I2C buses, and PECI
interface with the board-specific pinctrl and PHY connections they
require.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
---
.../boot/dts/nuvoton/nuvoton-npcm845-evb.dts | 413 ++++++++++++++++++
1 file changed, 413 insertions(+)
diff --git a/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts b/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
index 5edf5d13342d..28dbb865d739 100644
--- a/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
+++ b/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
@@ -10,6 +10,42 @@ / {
aliases {
serial0 = &serial0;
+ ethernet1 = &gmac1;
+ ethernet2 = &gmac2;
+ ethernet3 = &gmac3;
+ mdio-gpio0 = &mdio0;
+ mdio-gpio1 = &mdio1;
+ fiu0 = &fiu0;
+ fiu1 = &fiu3;
+ fiu2 = &fiux;
+ fiu3 = &fiu1;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ i2c6 = &i2c6;
+ i2c7 = &i2c7;
+ i2c8 = &i2c8;
+ i2c9 = &i2c9;
+ i2c10 = &i2c10;
+ i2c11 = &i2c11;
+ i2c12 = &i2c12;
+ i2c13 = &i2c13;
+ i2c14 = &i2c14;
+ i2c15 = &i2c15;
+ i2c16 = &i2c16;
+ i2c17 = &i2c17;
+ i2c18 = &i2c18;
+ i2c19 = &i2c19;
+ i2c20 = &i2c20;
+ i2c21 = &i2c21;
+ i2c22 = &i2c22;
+ i2c23 = &i2c23;
+ i2c24 = &i2c24;
+ i2c25 = &i2c25;
+ i2c26 = &i2c26;
};
chosen {
@@ -26,12 +62,389 @@ refclk: refclk-25mhz {
clock-frequency = <25000000>;
#clock-cells = <0>;
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ tip_reserved: tip@0 {
+ reg = <0x0 0x0 0x0 0x6200000>;
+ };
+ };
+
+ mdio0: mdio-0 {
+ compatible = "virtual,mdio-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpios = <&gpio1 25 GPIO_ACTIVE_HIGH>,
+ <&gpio1 26 GPIO_ACTIVE_HIGH>;
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+
+ mdio1: mdio-1 {
+ compatible = "virtual,mdio-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>,
+ <&gpio2 28 GPIO_ACTIVE_HIGH>;
+
+ phy1: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+};
+
+&gmac1 {
+ phy-mode = "rgmii-id";
+ snps,eee-force-disable;
+ status = "okay";
+};
+
+&gmac2 {
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&r1_pins
+ &r1oen_pins>;
+ phy-handle = <&phy0>;
+ status = "okay";
+};
+
+&gmac3 {
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&r2_pins
+ &r2oen_pins>;
+ phy-handle = <&phy1>;
+ status = "okay";
};
&serial0 {
status = "okay";
};
+&fiu0 {
+ status = "okay";
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <1>;
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bmc@0 {
+ label = "bmc";
+ reg = <0x00000000 0x04000000>;
+ };
+ u-boot@0 {
+ label = "u-boot";
+ reg = <0x00000000 0x007C0000>;
+ };
+ u-boot-env@7c0000 {
+ label = "u-boot-env";
+ reg = <0x007C0000 0x00040000>;
+ };
+ kernel@800000 {
+ label = "kernel";
+ reg = <0x00800000 0x00800000>;
+ };
+ rofs@1000000 {
+ label = "rofs";
+ reg = <0x01000000 0x02C00000>;
+ };
+ rwfs@3c00000 {
+ label = "rwfs";
+ reg = <0x03C00000 0x00400000>;
+ };
+ };
+ };
+};
+
+&fiu1 {
+ status = "okay";
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <2>;
+ spi-tx-bus-width = <2>;
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "spi1-system1";
+ reg = <0x0 0x0>;
+ };
+ };
+ };
+};
+
+&fiu3 {
+ pinctrl-0 = <&spi3_pins>, <&spi3quad_pins>;
+ status = "okay";
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <1>;
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "spi3-system1";
+ reg = <0x0 0x0>;
+ };
+ };
+ };
+};
+
+&fiux {
+ nuvoton,spix-mode;
+};
+
+&sdhci {
+ status = "okay";
+};
+
+&udc0 {
+ status = "okay";
+};
+
+&udc1 {
+ status = "okay";
+};
+
+&udc2 {
+ status = "okay";
+};
+
+&udc3 {
+ status = "okay";
+};
+
+&udc4 {
+ status = "okay";
+};
+
+&udc5 {
+ status = "okay";
+};
+
+&udc6 {
+ status = "okay";
+};
+
+&udc7 {
+ status = "okay";
+};
+
+&mc {
+ status = "okay";
+};
+
+&peci {
+ status = "okay";
+};
+
+&rng {
+ status = "okay";
+};
+
+&adc {
+ #io-channel-cells = <1>;
+ status = "okay";
+};
+
&watchdog1 {
status = "okay";
};
+
+&pwm_fan {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pins &pwm1_pins
+ &pwm2_pins &pwm3_pins
+ &pwm4_pins &pwm5_pins
+ &pwm6_pins &pwm7_pins
+ &fanin0_pins &fanin1_pins
+ &fanin2_pins &fanin3_pins
+ &fanin4_pins &fanin5_pins
+ &fanin6_pins &fanin7_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ fan@0 {
+ reg = <0x00>;
+ fan-tach-ch = /bits/ 8 <0x0 0x1>;
+ cooling-levels = <127 255>;
+ };
+ fan@1 {
+ reg = <0x01>;
+ fan-tach-ch = /bits/ 8 <0x2 0x3>;
+ cooling-levels = <127 255>;
+ };
+ fan@2 {
+ reg = <0x02>;
+ fan-tach-ch = /bits/ 8 <0x4 0x5>;
+ cooling-levels = <127 255>;
+ };
+ fan@3 {
+ reg = <0x03>;
+ fan-tach-ch = /bits/ 8 <0x6 0x7>;
+ cooling-levels = <127 255>;
+ };
+ fan@4 {
+ reg = <0x04>;
+ fan-tach-ch = /bits/ 8 <0x8 0x9>;
+ cooling-levels = <127 255>;
+ };
+ fan@5 {
+ reg = <0x05>;
+ fan-tach-ch = /bits/ 8 <0xa 0xb>;
+ cooling-levels = <127 255>;
+ };
+ fan@6 {
+ reg = <0x06>;
+ fan-tach-ch = /bits/ 8 <0xc 0xd>;
+ cooling-levels = <127 255>;
+ };
+ fan@7 {
+ reg = <0x07>;
+ fan-tach-ch = /bits/ 8 <0xe 0xf>;
+ cooling-levels = <127 255>;
+ };
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ eeprom@50 {
+ compatible = "atmel,24c256";
+ reg = <0x50>;
+ };
+};
+
+&i2c2 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ipmb@10 {
+ compatible = "ipmb-dev";
+ reg = <0x10>;
+ i2c-protocol;
+ };
+};
+
+&i2c3 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ipmb@11 {
+ compatible = "ipmb-dev";
+ reg = <0x11>;
+ i2c-protocol;
+ };
+};
+
+&i2c4 {
+ status = "okay";
+};
+
+&i2c5 {
+ status = "okay";
+};
+
+&i2c6 {
+ status = "okay";
+};
+
+&i2c7 {
+ status = "okay";
+};
+
+&i2c8 {
+ status = "okay";
+};
+
+&i2c9 {
+ status = "okay";
+};
+
+&i2c10 {
+ status = "okay";
+};
+
+&i2c11 {
+ status = "okay";
+};
+
+&i2c12 {
+ status = "okay";
+};
+
+&i2c13 {
+ status = "okay";
+};
+
+&i2c14 {
+ status = "okay";
+};
+
+&i2c15 {
+ status = "okay";
+};
+
+&i2c16 {
+ status = "okay";
+};
+
+&i2c17 {
+ status = "okay";
+};
+
+&i2c18 {
+ status = "okay";
+};
+
+&i2c19 {
+ status = "okay";
+};
+
+&i2c20 {
+ status = "okay";
+};
+
+&i2c21 {
+ status = "okay";
+};
+
+&i2c22 {
+ status = "okay";
+};
+
+&i2c23 {
+ status = "okay";
+};
+
+&i2c24 {
+ status = "okay";
+};
+
+&i2c25 {
+ status = "okay";
+};
+
+&i2c26 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v5 3/4] arm64: dts: nuvoton: npcm845: Add peripheral nodes
From: Tomer Maimon @ 2026-06-15 14:25 UTC (permalink / raw)
To: andrew, robh, krzk+dt, conor+dt
Cc: openbmc, devicetree, linux-kernel, avifishman70, tmaimon77,
tali.perry1, venture, yuenn, benjaminfair
In-Reply-To: <20260615142548.1373799-1-tmaimon77@gmail.com>
Extend the NPCM845 SoC DTSI with the peripheral controller nodes needed
by the evaluation board and downstream platforms. Add the Ethernet MACs,
USB device controllers and PHY, MMC controller, FIU controllers, memory
controller, RNG, ADC, PWM/FAN controller, and I2C buses. Also add the
OP-TEE firmware node needed to describe these blocks.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
---
.../dts/nuvoton/nuvoton-common-npcm8xx.dtsi | 695 +++++++++++++++++-
.../boot/dts/nuvoton/nuvoton-npcm845.dtsi | 11 +-
2 files changed, 697 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
index 0e5feabf2d71..7608dcf5489c 100644
--- a/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
+++ b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
@@ -4,6 +4,7 @@
#include <dt-bindings/clock/nuvoton,npcm845-clk.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
/ {
#address-cells = <2>;
@@ -35,6 +36,11 @@ gic: interrupt-controller@dfff9000 {
};
};
+ udc0_phy: usb-phy {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
ahb {
#address-cells = <2>;
#size-cells = <2>;
@@ -51,6 +57,252 @@ clk: rstc: reset-controller@f0801000 {
#clock-cells = <1>;
};
+ gmac1: ethernet@f0804000 {
+ device_type = "network";
+ compatible = "snps,dwmac-3.72a", "snps,dwmac";
+ reg = <0x0 0xf0804000 0x0 0x2000>;
+ interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ clocks = <&clk NPCM8XX_CLK_AHB>;
+ clock-names = "stmmaceth";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rg2_pins
+ &rg2mdio_pins>;
+ status = "disabled";
+ };
+
+ gmac2: ethernet@f0806000 {
+ device_type = "network";
+ compatible = "snps,dwmac-3.72a", "snps,dwmac";
+ reg = <0x0 0xf0806000 0x0 0x2000>;
+ interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ clocks = <&clk NPCM8XX_CLK_AHB>;
+ clock-names = "stmmaceth";
+ pinctrl-names = "default";
+ pinctrl-0 = <&r1_pins
+ &r1err_pins
+ &r1md_pins>;
+ status = "disabled";
+ };
+
+ gmac3: ethernet@f0808000 {
+ device_type = "network";
+ compatible = "snps,dwmac-3.72a", "snps,dwmac";
+ reg = <0x0 0xf0808000 0x0 0x2000>;
+ interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ clocks = <&clk NPCM8XX_CLK_AHB>;
+ clock-names = "stmmaceth";
+ pinctrl-names = "default";
+ pinctrl-0 = <&r2_pins
+ &r2err_pins
+ &r2md_pins>;
+ status = "disabled";
+ };
+
+ mc: memory-controller@f0824000 {
+ compatible = "nuvoton,npcm845-memory-controller";
+ reg = <0x0 0xf0824000 0x0 0x1000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ udc0: usb@f0830000 {
+ compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
+ reg = <0x0 0xf0830000 0x0 0x1000
+ 0x0 0xfffeb000 0x0 0x800>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_SU>;
+ clock-names = "clk_usb_bridge";
+
+ phys = <&udc0_phy>;
+ phy_type = "utmi_wide";
+ dr_mode = "peripheral";
+ status = "disabled";
+ };
+
+ udc1: usb@f0831000 {
+ compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
+ reg = <0x0 0xf0831000 0x0 0x1000
+ 0x0 0xfffeb800 0x0 0x800>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_SU>;
+ clock-names = "clk_usb_bridge";
+
+ phys = <&udc0_phy>;
+ phy_type = "utmi_wide";
+ dr_mode = "peripheral";
+ status = "disabled";
+ };
+
+ udc2: usb@f0832000 {
+ compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
+ reg = <0x0 0xf0832000 0x0 0x1000
+ 0x0 0xfffec000 0x0 0x800>;
+ interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_SU>;
+ clock-names = "clk_usb_bridge";
+
+ phys = <&udc0_phy>;
+ phy_type = "utmi_wide";
+ dr_mode = "peripheral";
+ status = "disabled";
+ };
+
+ udc3: usb@f0833000 {
+ compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
+ reg = <0x0 0xf0833000 0x0 0x1000
+ 0x0 0xfffec800 0x0 0x800>;
+ interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_SU>;
+ clock-names = "clk_usb_bridge";
+
+ phys = <&udc0_phy>;
+ phy_type = "utmi_wide";
+ dr_mode = "peripheral";
+ status = "disabled";
+ };
+
+ udc4: usb@f0834000 {
+ compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
+ reg = <0x0 0xf0834000 0x0 0x1000
+ 0x0 0xfffed000 0x0 0x800>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_SU>;
+ clock-names = "clk_usb_bridge";
+
+ phys = <&udc0_phy>;
+ phy_type = "utmi_wide";
+ dr_mode = "peripheral";
+ status = "disabled";
+ };
+
+ udc5: usb@f0835000 {
+ compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
+ reg = <0x0 0xf0835000 0x0 0x1000
+ 0x0 0xfffed800 0x0 0x800>;
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_SU>;
+ clock-names = "clk_usb_bridge";
+
+ phys = <&udc0_phy>;
+ phy_type = "utmi_wide";
+ dr_mode = "peripheral";
+ status = "disabled";
+ };
+
+ udc6: usb@f0836000 {
+ compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
+ reg = <0x0 0xf0836000 0x0 0x1000
+ 0x0 0xfffee000 0x0 0x800>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_SU>;
+ clock-names = "clk_usb_bridge";
+
+ phys = <&udc0_phy>;
+ phy_type = "utmi_wide";
+ dr_mode = "peripheral";
+ status = "disabled";
+ };
+
+ udc7: usb@f0837000 {
+ compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
+ reg = <0x0 0xf0837000 0x0 0x1000
+ 0x0 0xfffee800 0x0 0x800>;
+ interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_SU>;
+ clock-names = "clk_usb_bridge";
+
+ phys = <&udc0_phy>;
+ phy_type = "utmi_wide";
+ dr_mode = "peripheral";
+ status = "disabled";
+ };
+
+ udc8: usb@f0838000 {
+ compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
+ reg = <0x0 0xf0838000 0x0 0x1000
+ 0x0 0xfffef000 0x0 0x800>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_SU>;
+ clock-names = "clk_usb_bridge";
+
+ phys = <&udc0_phy>;
+ phy_type = "utmi_wide";
+ dr_mode = "peripheral";
+ status = "disabled";
+ };
+
+ udc9: usb@f0839000 {
+ compatible = "nuvoton,npcm845-udc", "nuvoton,npcm750-udc";
+ reg = <0x0 0xf0839000 0x0 0x1000
+ 0x0 0xfffef800 0x0 0x800>;
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_SU>;
+ clock-names = "clk_usb_bridge";
+
+ phys = <&udc0_phy>;
+ phy_type = "utmi_wide";
+ dr_mode = "peripheral";
+ status = "disabled";
+ };
+
+ sdhci: mmc@f0842000 {
+ compatible = "nuvoton,npcm845-sdhci";
+ reg = <0x0 0xf0842000 0x0 0x100>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_AHB>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc8_pins
+ &mmc_pins>;
+ status = "disabled";
+ };
+
+ fiu0: spi@fb000000 {
+ compatible = "nuvoton,npcm845-fiu";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0xfb000000 0x0 0x1000>;
+ reg-names = "control";
+ clocks = <&clk NPCM8XX_CLK_SPI0>;
+ status = "disabled";
+ };
+
+ fiu1: spi@fb002000 {
+ compatible = "nuvoton,npcm845-fiu";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0xfb002000 0x0 0x1000>;
+ reg-names = "control";
+ clocks = <&clk NPCM8XX_CLK_SPI1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>;
+ status = "disabled";
+ };
+
+ fiu3: spi@c0000000 {
+ compatible = "nuvoton,npcm845-fiu";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0xc0000000 0x0 0x1000>;
+ reg-names = "control";
+ clocks = <&clk NPCM8XX_CLK_SPI3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi3_pins>;
+ status = "disabled";
+ };
+
+ fiux: spi@fb001000 {
+ compatible = "nuvoton,npcm845-fiu";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0xfb001000 0x0 0x1000>,
+ <0x0 0xf8000000 0x0 0x2000000>;
+ reg-names = "control", "memory";
+ clocks = <&clk NPCM8XX_CLK_SPIX>;
+ status = "disabled";
+ };
+
apb {
#address-cells = <1>;
#size-cells = <1>;
@@ -59,13 +311,6 @@ apb {
ranges = <0x0 0x0 0xf0000000 0x00300000>,
<0xfff00000 0x0 0xfff00000 0x00016000>;
- timer0: timer@8000 {
- compatible = "nuvoton,npcm845-timer";
- interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x8000 0x1C>;
- clocks = <&refclk>;
- };
-
serial0: serial@0 {
compatible = "nuvoton,npcm845-uart", "nuvoton,npcm750-uart";
reg = <0x0 0x1000>;
@@ -168,6 +413,442 @@ peci: peci-controller@100000 {
cmd-timeout-ms = <1000>;
status = "disabled";
};
+
+ rng: rng@b000 {
+ compatible = "nuvoton,npcm845-rng";
+ reg = <0xb000 0x8>;
+ status = "disabled";
+ };
+
+ adc: adc@c000 {
+ compatible = "nuvoton,npcm845-adc";
+ reg = <0xC000 0x8>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_ADC>;
+ resets = <&rstc 0x20 27>;
+ status = "disabled";
+ };
+
+ i2c0: i2c@80000 {
+ reg = <0x80000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb0_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@81000 {
+ reg = <0x81000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb1_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@82000 {
+ reg = <0x82000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb2_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c3: i2c@83000 {
+ reg = <0x83000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb3_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c4: i2c@84000 {
+ reg = <0x84000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb4_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c5: i2c@85000 {
+ reg = <0x85000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb5_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c6: i2c@86000 {
+ reg = <0x86000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb6_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c7: i2c@87000 {
+ reg = <0x87000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb7_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c8: i2c@88000 {
+ reg = <0x88000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb8_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c9: i2c@89000 {
+ reg = <0x89000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb9_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c10: i2c@8a000 {
+ reg = <0x8a000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb10_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c11: i2c@8b000 {
+ reg = <0x8b000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb11_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c12: i2c@8c000 {
+ reg = <0x8c000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb12_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c13: i2c@8d000 {
+ reg = <0x8d000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb13_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c14: i2c@8e000 {
+ reg = <0x8e000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb14_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c15: i2c@8f000 {
+ reg = <0x8f000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb15_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c16: i2c@fff00000 {
+ reg = <0xfff00000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb16_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c17: i2c@fff01000 {
+ reg = <0xfff01000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb17_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c18: i2c@fff02000 {
+ reg = <0xfff02000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb18_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c19: i2c@fff03000 {
+ reg = <0xfff03000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb19_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c20: i2c@fff04000 {
+ reg = <0xfff04000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb20_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c21: i2c@fff05000 {
+ reg = <0xfff05000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb21_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c22: i2c@fff06000 {
+ reg = <0xfff06000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb22_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c23: i2c@fff07000 {
+ reg = <0xfff07000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb23_pins>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c24: i2c@fff08000 {
+ reg = <0xfff08000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c25: i2c@fff09000 {
+ reg = <0xfff09000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ i2c26: i2c@fff0a000 {
+ reg = <0xfff0a000 0x1000>;
+ compatible = "nuvoton,npcm845-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk NPCM8XX_CLK_APB2>;
+ clock-frequency = <100000>;
+ interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+ nuvoton,sys-mgr = <&gcr>;
+ status = "disabled";
+ };
+
+ pwm_fan:pwm-fan-controller@103000 {
+ compatible = "nuvoton,npcm845-pwm-fan";
+ reg = <0x103000 0x3000>,
+ <0x180000 0x8000>;
+ reg-names = "pwm", "fan";
+ clocks = <&clk NPCM8XX_CLK_APB3>,
+ <&clk NPCM8XX_CLK_APB4>;
+ clock-names = "pwm","fan";
+ interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pins &pwm1_pins
+ &pwm2_pins &pwm3_pins
+ &pwm4_pins &pwm5_pins
+ &pwm6_pins &pwm7_pins
+ &pwm8_pins &pwm9_pins
+ &pwm10_pins &pwm11_pins
+ &fanin0_pins &fanin1_pins
+ &fanin2_pins &fanin3_pins
+ &fanin4_pins &fanin5_pins
+ &fanin6_pins &fanin7_pins
+ &fanin8_pins &fanin9_pins
+ &fanin10_pins &fanin11_pins
+ &fanin12_pins &fanin13_pins
+ &fanin14_pins &fanin15_pins>;
+ status = "disabled";
+ };
+
+ pspi: spi@201000 {
+ compatible = "nuvoton,npcm845-pspi";
+ reg = <0x201000 0x1000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pspi_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_APB5>;
+ clock-names = "clk_apb5";
+ resets = <&rstc 0x24 23>;
+ status = "disabled";
+ };
+
};
};
diff --git a/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845.dtsi b/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845.dtsi
index 8239d9a9f0d2..21dea323612d 100644
--- a/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845.dtsi
+++ b/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845.dtsi
@@ -64,8 +64,8 @@ arm-pmu {
};
psci {
- compatible = "arm,psci-1.0";
- method = "smc";
+ compatible = "arm,psci-1.0";
+ method = "smc";
};
timer {
@@ -75,4 +75,11 @@ timer {
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
};
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
};
--
2.34.1
^ permalink raw reply related
* [PATCH v5 2/4] arm64: dts: nuvoton: npcm845: Reorder timer0 and PECI nodes
From: Tomer Maimon @ 2026-06-15 14:25 UTC (permalink / raw)
To: andrew, robh, krzk+dt, conor+dt
Cc: openbmc, devicetree, linux-kernel, avifishman70, tmaimon77,
tali.perry1, venture, yuenn, benjaminfair
In-Reply-To: <20260615142548.1373799-1-tmaimon77@gmail.com>
Move the timer0 and PECI nodes so the APB children are ordered by
ascending unit address.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
---
.../dts/nuvoton/nuvoton-common-npcm8xx.dtsi | 25 ++++++++++++-------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
index 9e4fa2669f4d..0e5feabf2d71 100644
--- a/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
+++ b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
@@ -59,15 +59,6 @@ apb {
ranges = <0x0 0x0 0xf0000000 0x00300000>,
<0xfff00000 0x0 0xfff00000 0x00016000>;
- peci: peci-controller@100000 {
- compatible = "nuvoton,npcm845-peci";
- reg = <0x100000 0x1000>;
- interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clk NPCM8XX_CLK_APB3>;
- cmd-timeout-ms = <1000>;
- status = "disabled";
- };
-
timer0: timer@8000 {
compatible = "nuvoton,npcm845-timer";
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
@@ -138,6 +129,13 @@ serial6: serial@6000 {
status = "disabled";
};
+ timer0: timer@8000 {
+ compatible = "nuvoton,npcm845-timer";
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x8000 0x1C>;
+ clocks = <&refclk>;
+ };
+
watchdog0: watchdog@801c {
compatible = "nuvoton,npcm845-wdt", "nuvoton,npcm750-wdt";
interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
@@ -161,6 +159,15 @@ watchdog2: watchdog@a01c {
status = "disabled";
clocks = <&refclk>;
};
+
+ peci: peci-controller@100000 {
+ compatible = "nuvoton,npcm845-peci";
+ reg = <0x100000 0x1000>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk NPCM8XX_CLK_APB3>;
+ cmd-timeout-ms = <1000>;
+ status = "disabled";
+ };
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v5 1/4] arm64: dts: nuvoton: npcm845: Drop redundant timer clock-names
From: Tomer Maimon @ 2026-06-15 14:25 UTC (permalink / raw)
To: andrew, robh, krzk+dt, conor+dt
Cc: openbmc, devicetree, linux-kernel, avifishman70, tmaimon77,
tali.perry1, venture, yuenn, benjaminfair
In-Reply-To: <20260615142548.1373799-1-tmaimon77@gmail.com>
The NPCM845 timer0 node references a single clock, but its
clock-names property is not described by the timer binding. Drop the
undocumented name so the DTS matches the binding.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
---
arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
index c781190b42c5..9e4fa2669f4d 100644
--- a/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
+++ b/arch/arm64/boot/dts/nuvoton/nuvoton-common-npcm8xx.dtsi
@@ -73,7 +73,6 @@ timer0: timer@8000 {
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
reg = <0x8000 0x1C>;
clocks = <&refclk>;
- clock-names = "refclk";
};
serial0: serial@0 {
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/4] arm64: dts: nuvoton: add NPCM845 SoC and EVB support
From: Tomer Maimon @ 2026-06-15 14:25 UTC (permalink / raw)
To: andrew, robh, krzk+dt, conor+dt
Cc: openbmc, devicetree, linux-kernel, avifishman70, tmaimon77,
tali.perry1, venture, yuenn, benjaminfair
This series fixes the remaining timer binding issue and adds device tree
support for peripherals on the Nuvoton NPCM845 SoC and its Evaluation
Board (EVB).
The first patch drops the undocumented timer0 clock-names property.
The second patch reorders timer0 and PECI so the APB child nodes stay in
ascending unit-address order.
The third patch introduces peripheral nodes for Ethernet, MMC, SPI, USB,
RNG, ADC, PWM-FAN, I2C, and OP-TEE firmware in the NPCM845 SoC device
tree.
The fourth patch enables these peripherals for the NPCM845-EVB, adding
MDIO nodes, reserved memory, aliases, and board-specific configurations
such as PHY modes and SPI flash partitions.
The NPCM8XX device tree was tested on NPCM845 evaluation board.
This series depends on:
https://lore.kernel.org/all/20260610121822.2524634-2-tmaimon77@gmail.com/
https://lore.kernel.org/all/20260610121822.2524634-3-tmaimon77@gmail.com/
https://lore.kernel.org/all/20260610121822.2524634-4-tmaimon77@gmail.com/
Addressed comments from:
- Rob Herring
Changes since version 4:
- Split the timer0 clock-names cleanup into a separate first patch.
- Remove nuvoton,sysgcr from udc8 and udc9.
- Rename apb: bus@f0000000 back to apb.
- Add no-map to tip_reserved.
- Rename spix-mode to nuvoton,spix-mode.
- Keep cooling-levels as 32-bit cells while encoding fan-tach-ch
as /bits/ 8.
Tomer Maimon (4):
arm64: dts: nuvoton: npcm845: Drop redundant timer clock-names
arm64: dts: nuvoton: npcm845: Reorder timer0 and PECI nodes
arm64: dts: nuvoton: npcm845: Add peripheral nodes
arm64: dts: nuvoton: npcm845-evb: Add peripheral nodes
.../dts/nuvoton/nuvoton-common-npcm8xx.dtsi | 721 +++++++++++++++++-
.../boot/dts/nuvoton/nuvoton-npcm845-evb.dts | 413 ++++++++++
.../boot/dts/nuvoton/nuvoton-npcm845.dtsi | 11 +-
3 files changed, 1126 insertions(+), 19 deletions(-)
--
2.34.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox