* Re: [PATCH 2/4] phy: qcom-qusb2: Fix SM6115 init sequence
From: Konrad Dybcio @ 2026-06-17 13:03 UTC (permalink / raw)
To: Iskren Chernev, Konrad Dybcio, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Wesley Cheng,
Greg Kroah-Hartman, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <6fb6f805-aea1-47e7-bb7c-bc5ecb2201ae@iskren.info>
On 6/17/26 2:48 PM, Iskren Chernev wrote:
>
>
> On 6/15/26 1:44 PM, Konrad Dybcio wrote:
>> On 6/14/26 2:29 PM, Iskren Chernev wrote:
>>>
>>>
>>> On 6/10/26 3:04 PM, Konrad Dybcio wrote:
>>>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>
>>>> I don't know where the existing one came from, but it's apparently
>>>> wrong, according to both docs and a downstream DT [1]. Fix it up.
>>>
>>> They came from DTB extracted from a running billie2 (OnePlus Nord N100):
>>> [1] https://mainlining.dev/wp-content/uploads/2021/02/03_dtbdump_Qualcomm_Technologies_Inc._Bengal_SoC.dts
>>>
>>> The phone was bough early after launch, so it could have been wrong/updated later.
>>
>> Good to see you're still around!
>>
>> Looks like vendor tuning. I see that even the initial commit for
>> 6115 had the init sequence I posted. And the OnePlus sources have
>> what seems like a project-specific local copy of the DTSI:
>>
>> https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/qcom/bengal-usb.dtsi#L145
>> https://github.com/OnePlusOSS/android_kernel_oneplus_sm4250/blob/oneplus/SM4250_Q_10.0/arch/arm64/boot/dts/vendor/20882/bengal-usb.dtsi#L148
>>
>> To support that, we should add a new property to override the TUNEx
>> registers - like e.g. qcom,hstx-trim-value that's already consumed
>
> My 2 cents - I never understood why init sequences are taboo in mainline
> and widely used in downstream. I guess if it doesn't change (but across
> what and who decides) it should be in code, but if it's "tuning"
> - whatever that means, possibly depends on other components around, it
> should be "configurable" via DT.
The PHY has some electrical characteristics of its own, and then atop
that are the characteristics of what's on the other end of it. Making
all parameters configurable (i.e. raw init sequence) leads to duplication
and pure blob seqeuences, whereas making everything constant leads to
polluting the driver (if every device-specific seq was to be in C files)
I think the current model of "override as necessary" is OK, especially
since we can use the upstream leverage to require describing what the
altered parameters actually change
>> Would you like to look into that, or should I take this?
>
> You can take it, the other option is to mark a TODO, and if somebody
> feels strongly about the binary value in a usb tune register s/he can
> take up the task.
Seems like OnePlus does.. actually, a number of vendors do. Sony
does/used to do some tuning there too.
> I just wanted to point out that the number didn't come from a random
> number generator (or AI).
I'm sorry if my language was too harsh. You used the best sources
you had and had no reason to believe they were not the expected values.
Konrad
^ permalink raw reply
* Re: [PATCH v4 4/5] arm64: dts: qcom: sm8650-qrd: add SPMI ADC channels and thermal nodes
From: sashiko-bot @ 2026-06-17 13:11 UTC (permalink / raw)
To: Neil Armstrong; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260617-topic-sm8x50-adc5-gen3-v4-4-4af9251731f1@linaro.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The patch relies on undefined parameterized macros (e.g., `ADC5_GEN3_DIE_TEMP(1)`), which will completely break device tree compilation.
- [Low] The unit-address of the PM8550VE thermal channel node (`channel@503`) does not match its evaluated `reg` property (`0x803`), causing a DTC unit_address_vs_reg warning.
--
commit 3ff480d3d3bffdbe30ed6468b6ac6d09de994eeb
Author: Neil Armstrong <neil.armstrong@linaro.org>
arm64: dts: qcom: sm8650-qrd: add SPMI ADC channels and thermal nodes
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system. The thermal nodes are sorted by the
sensor channel to be coherent with the system thermal nodes ordering.
> diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
> index a3982ae229290..d4a0627ebbf6e 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
> @@ -158,6 +158,92 @@ platform {
> };
> };
>
> + thermal-zones {
> + skin-thermal {
> + thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
[Severity: Low]
Will this cause a device tree compilation failure?
It appears this patch uses parameterized macros like
ADC5_GEN3_AMUX1_THM_100K_PU(1) and ADC5_GEN3_DIE_TEMP(1), but the required
header defining them (qcom-adc5-gen3.h) isn't present in the tree.
The existing qcom-adc5-gen3-common.h defines these macros without arguments
(e.g., ADC5_GEN3_DIE_TEMP is 0x03), so using them with parameters will
evaluate to a syntax error like 0x03(1).
[ ... ]
> + /* PM8550VE Channel nodes */
> + channel@503 {
> + reg = <ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
[Severity: Low]
Does this unit-address match the evaluated reg property?
PMK8550VE_SID evaluates to 8 in sm8650-qrd.dts. Assuming the macro calculates
the address using the SID, the reg property will logically evaluate to 0x803.
The hardcoded channel@503 unit-address would then mismatch the 0x803 reg
property, which will trigger a DTC unit_address_vs_reg warning once the build
failure is resolved. Should this node be named channel@803?
> + label = "pm8550ve_die_temp";
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + /* PM8550VS_G Channel nodes */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-topic-sm8x50-adc5-gen3-v4-0-4af9251731f1@linaro.org?part=4
^ permalink raw reply
* Re: [PATCH v3 1/8] irqchip/qcom-pdc: restructure version support
From: Konrad Dybcio @ 2026-06-17 13:12 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <20260616-hamoa_pdc_v3-v3-1-4d8e1504ea75@oss.qualcomm.com>
On 6/16/26 11:25 AM, Maulik Shah wrote:
> PDC irqchip updates IRQ_ENABLE and IRQ_CFG and for three different
> versions v2.7, v3.0 and v3.2. These registers are organized in H/W
> as below on various SoCs.
[...]
> - ret = pdc_setup_pin_mapping(node);
> + ret = pdc_setup_pin_mapping(dev, node);
dev is enough, we can get the np in that function from dev->of_node
otherwise:
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 2/5] arm64: dts: qcom: sm8550-qrd: add SPMI ADC channels and thermal nodes
From: sashiko-bot @ 2026-06-17 13:12 UTC (permalink / raw)
To: Neil Armstrong; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260617-topic-sm8x50-adc5-gen3-v4-2-4af9251731f1@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch references missing function-like macros (e.g., `ADC5_GEN3_AMUX1_THM_100K_PU(1)`) and depends on a non-existent header `qcom-adc5-gen3.h`, leading to a dtc syntax error.
--
commit ffba2e8b8d47299d82f0442684ecd38fc3ef60a5
Author: Neil Armstrong <neil.armstrong@linaro.org>
arm64: dts: qcom: sm8550-qrd: add SPMI ADC channels and thermal nodes
This commit adds the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICs on the system. It also adds thermal nodes sorted by the
sensor channel to maintain coherency.
> diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
> index 2fb2e0be5e4c6..9356b40a18507 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
> @@ -205,6 +205,92 @@ platform {
> };
> };
>
> + thermal-zones {
> + skin-thermal {
> + thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
[Severity: Low]
Will this compile correctly?
It appears that ADC5_GEN3_AMUX1_THM_100K_PU and similar macros are being
invoked as function-like macros taking an argument. If the intended header
is missing, the preprocessor might fall back to definitions that do not take
arguments, expanding this to invalid syntax like 0x44(1) and causing a dtc
syntax error.
[ ... ]
> +&pmk8550_vadc {
> + /* PM8550 Channel nodes */
> + channel@100 {
> + reg = <ADC5_GEN3_REF_GND(1)>;
> + label = "pm8550_offset_ref";
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@101 {
> + reg = <ADC5_GEN3_1P25VREF(1)>;
> + label = "pm8550_vref_1p25";
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + channel@103 {
> + reg = <ADC5_GEN3_DIE_TEMP(1)>;
[Severity: Low]
Are we certain this macro expansion is valid?
Similar to the thermal-sensors property above, using ADC5_GEN3_DIE_TEMP(1)
as a parameterized macro could lead to a syntax error if the available
definitions do not accept arguments.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-topic-sm8x50-adc5-gen3-v4-0-4af9251731f1@linaro.org?part=2
^ permalink raw reply
* Re: [PATCH v7 0/6] Enable I2C on SA8255p Qualcomm platforms
From: Mattijs Korpershoek @ 2026-06-17 13:15 UTC (permalink / raw)
To: Praveen Talari, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Bjorn Andersson,
Mukesh Kumar Savaliya, Viken Dadhaniya
Cc: Mattijs Korpershoek, Praveen Talari, linux-arm-msm, linux-i2c,
devicetree, linux-kernel, bjorn.andersson, konrad.dybcio,
aniket.randive, chandana.chiluveru, prasad.sodagudi,
Krzysztof Kozlowski, Nikunj Kela
In-Reply-To: <20260617-enable-i2c-on-sa8255p-v7-0-ad736dbeab57@oss.qualcomm.com>
On Wed, Jun 17, 2026 at 10:20, Praveen Talari <praveen.talari@oss.qualcomm.com> wrote:
> The Qualcomm automotive SA8255p SoC relies on firmware to configure
> platform resources, including clocks, interconnects and TLMM.
> The driver requests resources operations over SCMI using power
> and performance protocols.
>
> The SCMI power protocol enables or disables resources like clocks,
> interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
> such as resume/suspend, to control power states(on/off).
>
> The SCMI performance protocol manages I2C frequency, with each
> frequency rate represented by a performance level. The driver uses
> geni_se_set_perf_opp() API to request the desired frequency rate..
>
> As part of geni_se_set_perf_opp(), the OPP for the requested frequency
> is obtained using dev_pm_opp_find_freq_floor() and the performance
> level is set using dev_pm_opp_set_opp().
>
> Tested-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
I've retested this on top of linux-next-20260616 and it still works fine
for me on the Ride SX (SA8775P) board:
/ # uname -a
Linux (none) 7.1.0-next-20260616+ #2 SMP PREEMPT_RT Wed Jun 17 14:58:42 CEST 2026 aarch64 aarch64 aarch64 GNU/Linux
/ # i2cdetect -l
i2c-11 i2c Geni-I2C I2C adapter
i2c-18 i2c Geni-I2C I2C adapter
/ # i2cdetect -F 11
Functionalities implemented by bus #11
I2C yes
SMBus quick command no
SMBus send byte yes
SMBus receive byte yes
SMBus write byte yes
SMBus read byte yes
SMBus write word yes
SMBus read word yes
SMBus process call yes
SMBus block write yes
SMBus block read no
SMBus block process call no
SMBus PEC yes
I2C block write yes
I2C block read yes
/ # i2cdetect -F 18
Functionalities implemented by bus #18
I2C yes
SMBus quick command no
SMBus send byte yes
SMBus receive byte yes
SMBus write byte yes
SMBus read byte yes
SMBus write word yes
SMBus read word yes
SMBus process call yes
SMBus block write yes
SMBus block read no
SMBus block process call no
SMBus PEC yes
I2C block write yes
I2C block read yes
Regards,
Mattijs
^ permalink raw reply
* Re: [PATCH v1 1/6] ASoC: qcom: qdsp6: add topology-driven Audio IF support
From: Prasad Kumpatla @ 2026-06-17 13:24 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, linux-sound, devicetree, linux-kernel
In-Reply-To: <90202cfd-19ad-4ae9-9f0d-cde014d8a663@kernel.org>
On 6/15/2026 2:58 PM, Srinivas Kandagatla wrote:
>
> On 6/10/26 4:45 PM, Prasad Kumpatla wrote:
>> Add topology parsing and media-format programming for Audio IF
>> source and sink modules.
>>
>> Add the Audio IF module IDs, the required topology tokens, and a
>> dedicated topology loader that stores the parsed interface
>> configuration in the AudioReach module state. Also add the Audio IF
>> media-format path that sends the interface configuration, hardware
>> endpoint media format, and frame-duration parameters for Audio IF
>> modules.
>>
>> This keeps the serial-interface configuration topology-driven while
>> still allowing the machine driver to provide runtime slot and media
>> format settings. The same Audio IF path can then be reused for TDM,
>> PCM, and I2S style backends.
>>
>> The new UAPI tokens (AR_TKN_U32_MODULE_SYNC_SRC=262 through
>> AR_TKN_U32_MODULE_INV_EXT_BIT_CLK=276) are added.
>>
>> MODULE_ID_AUDIO_IF_SINK (0x0700117C) and MODULE_ID_AUDIO_IF_SOURCE
>> (0x0700117D) are introduced in this patch.
>>
> Which platform is this tested on, also please send a PR to
> github.com/linux-msm/audioreach-topology to add thse new tokens.
Hi Srini,
Thanks for reviewing and comments.
this module is validated on Hawi and Shikra. Sure will raise the PR with
these tokens usage.
>
>> Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
>> ---
>> include/uapi/sound/snd_ar_tokens.h | 58 ++++++++++++++++
>> sound/soc/qcom/qdsp6/audioreach.c | 97 ++++++++++++++++++++++++++
>> sound/soc/qcom/qdsp6/audioreach.h | 62 +++++++++++++++++
>> sound/soc/qcom/qdsp6/topology.c | 108 +++++++++++++++++++++++++++++
>> 4 files changed, 325 insertions(+)
>>
>> diff --git a/include/uapi/sound/snd_ar_tokens.h b/include/uapi/sound/snd_ar_tokens.h
>> index 6b8102eaa..355a1e629 100644
>> --- a/include/uapi/sound/snd_ar_tokens.h
>> +++ b/include/uapi/sound/snd_ar_tokens.h
>> @@ -168,6 +168,48 @@ enum ar_event_types {
>> * LOG_WAIT = 0,
>> * LOG_IMMEDIATELY = 1
>> *
>> + * %AR_TKN_U32_MODULE_SYNC_SRC: Frame sync source
>> + * 0 = external, 1 = internal
>> + *
>> + * %AR_TKN_U32_MODULE_CTRL_DATA_OUT_ENABLE: Enable data-out tri-state control
>> + * 0 = disable, 1 = enable
>> + *
>> + * %AR_TKN_U32_MODULE_SLOT_MASK: Active TDM slot bitmask
>> + *
>> + * %AR_TKN_U32_MODULE_NSLOTS_PER_FRAME: Number of slots per TDM frame
>> + *
>> + * %AR_TKN_U32_MODULE_SLOT_WIDTH: Slot width in bits (16 or 32)
>> + *
>> + * %AR_TKN_U32_MODULE_SYNC_MODE: Frame sync mode
>> + * 0 = short pulse, 1 = long pulse
> We have 3 possible values, please correct this, also you could add
> defines for these values.
Ack, will update
>> + *
>> + * %AR_TKN_U32_MODULE_CTRL_INVERT_SYNC_PULSE: Invert frame sync pulse polarity
>> + * 0 = normal, 1 = inverted
>> + *
>> + * %AR_TKN_U32_MODULE_CTRL_SYNC_DATA_DELAY: Data delay relative to frame sync
>> + * 0 = no delay, 1 = one cycle delay
> Exactly same here, we have 2 cyle delay too.
Ack, will update
>> + *
>> + * %AR_TKN_U32_MODULE_INTF_MODE: Audio IF interface mode
>> + * AUDIO_IF_INTF_MODE_TDM = 0,
>> + * AUDIO_IF_INTF_MODE_PCM = 1,
>> + * AUDIO_IF_INTF_MODE_I2S = 2
> Same here, defines for these.
Ack, will update
>
>> + *
>> + * %AR_TKN_U32_MODULE_QAIF_TYPE: QAIF hardware port type index
>> + *
>> + * %AR_TKN_U32_MODULE_ACTIVE_LANE_MASK: Active lane bitmask for multi-lane
>> + *
>> + * %AR_TKN_U32_MODULE_FRAME_SYNC_RATE: Frame sync rate in Hz
>> + *
>> + * %AR_TKN_U32_MODULE_BIT_CLK_TYPE: Bit clock type
>> + * 0 = internal, 1 = external,
>> + * 2 = skip (bypass bit clock enable)
>> + *
>> + * %AR_TKN_U32_MODULE_INV_INT_BIT_CLK: Invert internal bit clock
>> + * 0 = normal, 1 = inverted
>> + *
>> + * %AR_TKN_U32_MODULE_INV_EXT_BIT_CLK: Invert external bit clock
>> + * 0 = normal, 1 = inverted
>> + *
>> * %AR_TKN_DAI_INDEX: dai index
>> *
>> */
>> @@ -240,6 +282,22 @@ enum ar_event_types {
>> #define AR_TKN_U32_MODULE_LOG_TAP_POINT_ID 260
>> #define AR_TKN_U32_MODULE_LOG_MODE 261
>>
>> +#define AR_TKN_U32_MODULE_SYNC_SRC 262
>> +#define AR_TKN_U32_MODULE_CTRL_DATA_OUT_ENABLE 263
>> +#define AR_TKN_U32_MODULE_SLOT_MASK 264
>> +#define AR_TKN_U32_MODULE_NSLOTS_PER_FRAME 265
>> +#define AR_TKN_U32_MODULE_SLOT_WIDTH 266
>> +#define AR_TKN_U32_MODULE_SYNC_MODE 267
>> +#define AR_TKN_U32_MODULE_CTRL_INVERT_SYNC_PULSE 268
>> +#define AR_TKN_U32_MODULE_CTRL_SYNC_DATA_DELAY 269
>> +#define AR_TKN_U32_MODULE_INTF_MODE 270
>> +#define AR_TKN_U32_MODULE_QAIF_TYPE 271
>> +#define AR_TKN_U32_MODULE_ACTIVE_LANE_MASK 272
>> +#define AR_TKN_U32_MODULE_FRAME_SYNC_RATE 273
>> +#define AR_TKN_U32_MODULE_BIT_CLK_TYPE 274
>> +#define AR_TKN_U32_MODULE_INV_INT_BIT_CLK 275
>> +#define AR_TKN_U32_MODULE_INV_EXT_BIT_CLK 276
>> +
> Here you prefix the tokens with U32, however in dirver this values are
> validated against U8 and U16, So please fix the prefixes to reflect the
> range.
>
>
> ...
Yes that's correct, will update them properly.
>
>>
>> default:
>> rc = 0;
>> diff --git a/sound/soc/qcom/qdsp6/audioreach.h b/sound/soc/qcom/qdsp6/audioreach.h
>> index 62a2fd79b..1dc29ddfd 100644
>> --- a/sound/soc/qcom/qdsp6/audioreach.h
>> +++ b/sound/soc/qcom/qdsp6/audioreach.h
>> @@ -22,6 +22,8 @@ struct q6apm_graph;
>> #define MODULE_ID_PLACEHOLDER_DECODER 0x07001009
>> #define MODULE_ID_I2S_SINK 0x0700100A
>> #define MODULE_ID_I2S_SOURCE 0x0700100B
>> +#define MODULE_ID_AUDIO_IF_SINK 0x0700117C
>> +#define MODULE_ID_AUDIO_IF_SOURCE 0x0700117D
> Please place it in the assending order.
Ack, will update.
>
>> #define MODULE_ID_SAL 0x07001010
>> #define MODULE_ID_MFC 0x07001015
>> #define MODULE_ID_DATA_LOGGING 0x0700101A
>> @@ -544,6 +546,41 @@ struct param_id_i2s_intf_cfg {
>> #define PORT_ID_I2S_OUPUT 1
>> #define I2S_STACK_SIZE 2048
>>
>> +#define PARAM_ID_AUDIO_IF_INTF_CFG 0x08001B11
>> +
>> +#define AUDIO_IF_INTF_MODE_TDM 0x0
>> +#define AUDIO_IF_INTF_MODE_PCM 0x1
>> +#define AUDIO_IF_INTF_MODE_I2S 0x2
>> +
>> +struct param_id_audio_if_intf_cfg {
> I know that we have not added documentation for all the structures, but
> Am in process of adding them. Can you add kernel doc to these structs.
Ack, will update
>> + uint16_t qaif_type;
>> + uint16_t intf_idx;
>> + uint16_t intf_mode;
>> + uint16_t ctrl_data_out_enable;
>> + uint32_t active_slot_mask;
>> + uint16_t nslots_per_frame;
>> + uint16_t slot_width;
>> + uint32_t active_lane_mask;
>> + uint32_t frame_sync_rate;
>> + uint16_t frame_sync_src;
>> + uint16_t frame_sync_mode;
>> + uint16_t invert_frame_sync_pulse;
>> + uint16_t frame_sync_data_delay;
>> + uint16_t bit_clk_type;
>> + uint8_t inv_int_bit_clk;
>> + uint8_t inv_ext_bit_clk;
>> +} __packed;
>> +
>> +#define PARAM_ID_HW_EP_FRAME_DURATION 0x08001B2F
>> +#define AUDIO_IF_FRAME_DURATION_US 1000
> Why is this hardcoded?
As this module End point operate with a 1 ms processing interval.
>> +
>> +struct param_id_hw_ep_frame_duration {
>> + uint32_t frame_duration_in_us;
>> + uint32_t allow_frame_duration_normalization;
>> + uint32_t min_normalized_frame_dur_us;
>> + uint32_t max_normalized_frame_dur_us;
>> +} __packed;
>> +
>> #define PARAM_ID_DISPLAY_PORT_INTF_CFG 0x08001154
>>
>> struct param_id_display_port_intf_cfg {
>> @@ -877,6 +914,28 @@ struct audioreach_module {
>> uint32_t data_format;
>> uint32_t hw_interface_type;
>>
>> + /* Audio IF module (TDM/PCM/I2S) */
>> + /*
>> + * uint32_t fields first to minimise intra-block padding;
> Why do we need this comments does not add a real value here?
No much, will remove them.
>> + * 2 bytes of trailing padding remain after inv_ext_bit_clk
>> + * before the next uint32_t field (interleave_type).
>> + */
>> + uint32_t slot_mask;
>> + uint32_t active_lane_mask;
>> + uint32_t frame_sync_rate;
>> + uint16_t qaif_type;
>> + uint16_t sync_src;
>> + uint16_t ctrl_data_out_enable;
>> + uint16_t nslots_per_frame;
>> + uint16_t slot_width;
>> + uint16_t intf_mode;
>> + uint16_t sync_mode;
>> + uint16_t ctrl_invert_sync_pulse;
>> + uint16_t ctrl_sync_data_delay;
>> + uint16_t bit_clk_type;
>> + uint8_t inv_int_bit_clk;
>> + uint8_t inv_ext_bit_clk;
>> +
>> /* PCM module specific */
>> uint32_t interleave_type;
>>
>> @@ -907,6 +966,9 @@ struct audioreach_module_config {
>> u32 channel_allocation;
>> u32 sd_line_mask;
>> int fmt;
>> + u32 slot_mask;
>> + u16 nslots_per_frame;
>> + u16 slot_width;
>> struct snd_codec codec;
>> u8 channel_map[AR_PCM_MAX_NUM_CHANNEL];
>> };
>> diff --git a/sound/soc/qcom/qdsp6/topology.c b/sound/soc/qcom/qdsp6/topology.c
>> index 1f69fba6d..2ae7ac3d2 100644
>> --- a/sound/soc/qcom/qdsp6/topology.c
>> +++ b/sound/soc/qcom/qdsp6/topology.c
>> @@ -753,6 +753,108 @@ static int audioreach_widget_i2s_module_load(struct audioreach_module *mod,
>> return 0;
>> }
>>
>> +static int audioreach_widget_audio_if_module_load(struct audioreach_module *mod,
>> + const struct snd_soc_tplg_vendor_array *mod_array)
>> +{
>> + const struct snd_soc_tplg_vendor_value_elem *mod_elem;
>> + int tkn_count = 0;
>> + u32 val;
>> +
>> + mod_elem = mod_array->value;
>> +
>> + while (tkn_count < le32_to_cpu(mod_array->num_elems)) {
>> + val = le32_to_cpu(mod_elem->value);
>> + switch (le32_to_cpu(mod_elem->token)) {
>> + case AR_TKN_U32_MODULE_HW_IF_IDX:
>> + if (val > U16_MAX)
>> + return -EINVAL;
> Plese fix such instances as suggested at the top.
Ack, will update
>
>> + mod->hw_interface_idx = val;
>> + break;
>> + case AR_TKN_U32_MODULE_FMT_DATA:
>> + mod->data_format = val;
>> + break;
>> + case AR_TKN_U32_MODULE_HW_IF_TYPE:
>> + mod->hw_interface_type = val;
> where are we using this?
Its not being used any where, i will remove this.
Thanks,
Prasad
>
>> + break;
>> + case AR_TKN_U32_MODULE_SYNC_SRC:
>> + if (val > U16_MAX)
>> + return -EINVAL;
>> + mod->sync_src = (u16)val;
>> + break;
>> + case AR_TKN_U32_MODULE_CTRL_DATA_OUT_ENABLE:
>> + if (val > U16_MAX)
>> + return -EINVAL;
>> + mod->ctrl_data_out_enable = (u16)val;
>> + break;
>> + case AR_TKN_U32_MODULE_SLOT_MASK:
>> + mod->slot_mask = val;
>> + break;
>> + case AR_TKN_U32_MODULE_NSLOTS_PER_FRAME:
>> + if (val > U16_MAX)
>> + return -EINVAL;
>> + mod->nslots_per_frame = (u16)val;
>> + break;
>> + case AR_TKN_U32_MODULE_SLOT_WIDTH:
>> + if (val > U16_MAX)
>> + return -EINVAL;
>> + mod->slot_width = (u16)val;
>> + break;
>> + case AR_TKN_U32_MODULE_INTF_MODE:
>> + if (val > U16_MAX)
>> + return -EINVAL;
>> + mod->intf_mode = (u16)val;
>> + break;
>> + case AR_TKN_U32_MODULE_SYNC_MODE:
>> + if (val > U16_MAX)
>> + return -EINVAL;
>> + mod->sync_mode = (u16)val;
>> + break;
>> + case AR_TKN_U32_MODULE_CTRL_INVERT_SYNC_PULSE:
>> + if (val > U16_MAX)
>> + return -EINVAL;
>> + mod->ctrl_invert_sync_pulse = (u16)val;
>> + break;
>> + case AR_TKN_U32_MODULE_CTRL_SYNC_DATA_DELAY:
>> + if (val > U16_MAX)
>> + return -EINVAL;
>> + mod->ctrl_sync_data_delay = (u16)val;
>> + break;
>> + case AR_TKN_U32_MODULE_QAIF_TYPE:
>> + if (val > U16_MAX)
>> + return -EINVAL;
>> + mod->qaif_type = (u16)val;
>> + break;
>> + case AR_TKN_U32_MODULE_ACTIVE_LANE_MASK:
>> + mod->active_lane_mask = val;
>> + break;
>> + case AR_TKN_U32_MODULE_FRAME_SYNC_RATE:
>> + mod->frame_sync_rate = val;
>> + break;
>> + case AR_TKN_U32_MODULE_BIT_CLK_TYPE:
>> + if (val > U16_MAX)
>> + return -EINVAL;
>> + mod->bit_clk_type = (u16)val;
>> + break;
>> + case AR_TKN_U32_MODULE_INV_INT_BIT_CLK:
>> + if (val > U8_MAX)
>> + return -EINVAL;
>> + mod->inv_int_bit_clk = (u8)val;
>> + break;
>> + case AR_TKN_U32_MODULE_INV_EXT_BIT_CLK:
>> + if (val > U8_MAX)
>> + return -EINVAL;
>> + mod->inv_ext_bit_clk = (u8)val;
>> + break;
>> + default:
>> + break;
>> + }
>> + tkn_count++;
>> + mod_elem++;
>> + }
>> +
>> + return 0;
>> +}
^ permalink raw reply
* Re: [PATCH v3 2/8] irqchip/qcom-pdc: Move all statics to struct pdc_desc
From: Konrad Dybcio @ 2026-06-17 13:26 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <20260616-hamoa_pdc_v3-v3-2-4d8e1504ea75@oss.qualcomm.com>
On 6/16/26 11:25 AM, Maulik Shah wrote:
> There are multiple statics used. Move all to struct pdc_desc to better
> align with versioning support. Document them.
>
> No functional impact.
>
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
[...]
> static void pdc_enable_intr(struct irq_data *d, bool on)
> {
> - unsigned long flags;
> + guard(raw_spinlock)(&pdc->lock);
tglx suggested to use guard(irq) around "the other callsite"..
which I'm not sure where it'd be - maybe around __pdc_enable_intr()
in pdc_setup_pin_mapping()?
Otherwise this patch looks good to me
Konrad
^ permalink raw reply
* Re: [PATCH v1 3/6] dt-bindings: sound: qcom,q6dsp-lpass-ports: add Audio IF clocks
From: Prasad Kumpatla @ 2026-06-17 13:27 UTC (permalink / raw)
To: Krzysztof Kozlowski, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Srinivas Kandagatla
Cc: linux-arm-msm, linux-sound, devicetree, linux-kernel
In-Reply-To: <6238983c-6b10-4639-b6ed-d1d25b00e748@kernel.org>
On 6/11/2026 2:29 PM, Krzysztof Kozlowski wrote:
> On 10/06/2026 17:45, Prasad Kumpatla wrote:
>> Add the LPASS Audio IF clock IDs used by newer backend interfaces.
>>
>> Platforms using Audio IF module backends request the interface bit
>> clocks through q6prm. Add the Audio IF IBIT and EBIT IDs to the binding
>> header so these clocks can be referenced from device trees.
>>
>> Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
>> ---
>> .../sound/qcom,q6dsp-lpass-ports.h | 57 +++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>>
>> diff --git a/include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h b/include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h
>> index 45850f2d4..bc860fcbf 100644
>> --- a/include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h
>> +++ b/include/dt-bindings/sound/qcom,q6dsp-lpass-ports.h
>> @@ -233,6 +233,63 @@
>> /* Clock ID for RX CORE MCLK2 2X MCLK */
>> #define LPASS_CLK_ID_RX_CORE_MCLK2_2X_MCLK 70
>>
>> +/** Clock ID of the Audio Intf 0 internal bit clock (IBIT). */
>> +#define LPASS_CLK_ID_AUD_INTF0_IBIT 71
> Missing indent
Hi Krzysztof,
Thanks for reviewing and comments.
Ack, will update
>
>> +/** Clock ID of the Audio Intf 0 external bit clock (EBIT). */
> This is not kerneldoc. Please do not introduce your own style.
Sure will remove and add proper comments if required.
>
>> +#define LPASS_CLK_ID_AUD_INTF0_EBIT 72
> Why everything has "AUD" middle prefix? What is Audio IF and how does it
> differ from Audio on this device? IOW, Why Audio has to be specified? Is
> there non-Audio block?
Agree, As this is already audio, it may not required to use again AUD in
the macro to represent. Will update.
>
>> +/** Clock ID of the Audio Intf 1 internal bit clock (IBIT). */
> All these comments are pointless - you repeat the define name. Explain
> once what is ibit, ebit etc, not every time.
Sure, we add comments if required.
Thanks,
Prasad
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v4 5/5] arm64: dts: qcom: sm8650-hdk: add SPMI ADC channels and thermal nodes
From: sashiko-bot @ 2026-06-17 13:30 UTC (permalink / raw)
To: Neil Armstrong; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260617-topic-sm8x50-adc5-gen3-v4-5-4af9251731f1@linaro.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Dangerously high and ineffective passive trip points for skin and ambient thermal zones.
- [Low] Use of undefined macro ADC5_GEN3_DIE_TEMP(x) causes a DTC syntax error.
- [Low] The unit-address of the pm8550ve_die_temp ADC channel node does not match its reg property.
--
commit f0b9d1fd765aad624439c8e56ebe37c1e26e52c9
Author: Neil Armstrong <neil.armstrong@linaro.org>
arm64: dts: qcom: sm8650-hdk: add SPMI ADC channels and thermal nodes
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
> diff --git a/arch/arm64/boot/dts/qcom/sm8650-hdk.dts b/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
> index eabc828c05b4c..05af2913055ed 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
> @@ -220,6 +220,92 @@ platform {
> };
> };
>
> + thermal-zones {
> + skin-thermal {
> + thermal-sensors = <&pmk8550_vadc ADC5_GEN3_AMUX1_THM_100K_PU(1)>;
[Severity: Low]
Is the header defining parameterized macros like ADC5_GEN3_AMUX1_THM_100K_PU(x)
missing? Without it, the C preprocessor leaves the macro unexpanded, or expands
the parameterless constant in include/linux/iio/adc/qcom-adc5-gen3-common.h to
0x03(1), which causes a DTC syntax error and breaks the build.
> +
> + trips {
> + active-config0 {
> + temperature = <125000>;
> + hysteresis = <1000>;
> + type = "passive";
> + };
[Severity: High]
Is it intentional to set the passive trip point for the skin-thermal zone to
125°C? While 125°C is a typical critical threshold for internal silicon dies,
it is physically impossible for skin or external surface temperatures without
causing severe burns or melting the device. Does this functionally disable
skin thermal mitigation?
[ ... ]
> @@ -1041,27 +1127,218 @@ led@3 {
> };
> };
[ ... ]
> + /* PM8550VE Channel nodes */
> + channel@503 {
> + reg = <ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
> + label = "pm8550ve_die_temp";
[Severity: Low]
Does the unit-address channel@503 match the evaluated reg property here?
Assuming PMK8550VE_SID is 8, the standard SPMI ADC encoding (sid << 8 | offset)
would evaluate to 0x803, making the unit-address channel@503 mismatched.
Should this be updated to channel@803 to avoid dtc validation warnings?
> + qcom,pre-scaling = <1 1>;
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-topic-sm8x50-adc5-gen3-v4-0-4af9251731f1@linaro.org?part=5
^ permalink raw reply
* [PATCH v6 0/4] arm64: dts: nuvoton: add NPCM845 SoC and EVB support
From: Tomer Maimon @ 2026-06-17 13:32 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:
- sashiko-bot
Changes since version 5:
- Add no-map to the tip_reserved firmware memory region.
- Drop the unsupported snps,eee-force-disable property from gmac1.
- Rework the FIU0 boot flash layout into nested fixed-partitions
under the bmc container.
- Keep patches 1-3 unchanged.
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.
- Rename spix-mode to nuvoton,spix-mode.
- Keep cooling-levels as 32-bit cells while encoding fan-tach-ch
as /bits/ 8.
Changes since version 3:
- reomve tmp100.
Changes since version 2:
- Fix dts warning
- Arrange node order by ascending unit address.
Changes since version 1:
- Fix commit message
- Fix dtbs_check warnings.
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 | 417 ++++++++++
.../boot/dts/nuvoton/nuvoton-npcm845.dtsi | 11 +-
3 files changed, 1130 insertions(+), 19 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v6 1/4] arm64: dts: nuvoton: npcm845: Drop redundant timer clock-names
From: Tomer Maimon @ 2026-06-17 13:32 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: <20260617133212.287768-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 v6 2/4] arm64: dts: nuvoton: npcm845: Reorder timer0 and PECI nodes
From: Tomer Maimon @ 2026-06-17 13:32 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: <20260617133212.287768-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 v6 3/4] arm64: dts: nuvoton: npcm845: Add peripheral nodes
From: Tomer Maimon @ 2026-06-17 13:32 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: <20260617133212.287768-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 v6 4/4] arm64: dts: nuvoton: npcm845-evb: Add peripheral nodes
From: Tomer Maimon @ 2026-06-17 13:32 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: <20260617133212.287768-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 | 417 ++++++++++++++++++
1 file changed, 417 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..1092dc5bb7ab 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,393 @@ 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>;
+ no-map;
+ };
+ };
+
+ 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";
+ 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 {
+ compatible = "fixed-partitions";
+ label = "bmc";
+ reg = <0x00000000 0x04000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ 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 v2 1/5] dt-bindings: watchdog: mediatek: Add MT8127
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:36 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami, Krzysztof Kozlowski
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-0-6859e29e72a8@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add entry for MT8127 SoC's watchdog which is compatible with MT6589's
one.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
index 953629cb9558..e6e4546da0aa 100644
--- a/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml
@@ -40,6 +40,7 @@ properties:
- mediatek,mt7622-wdt
- mediatek,mt7623-wdt
- mediatek,mt7629-wdt
+ - mediatek,mt8127-wdt
- mediatek,mt8173-wdt
- mediatek,mt8188-wdt
- mediatek,mt8189-wdt
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/5] ARM: Basic support for Amazon ford tablet (MT8127)
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:36 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami, Krzysztof Kozlowski
This series of patches adds basic support for MT8127 SoC based Amazon ford
tablet and fixes a small indentation error in the dtsi file.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Changes in v2:
- Move amazon ford compatible string to existing enum.
- Fix watchdog node not sorted in unit address ascending order (sashiko report).
- Move bindings documentation patches before patches implementing the bindings.
- Link to v1: https://lore.kernel.org/r/20260617-mt8127-amazon-ford-basic-v1-0-d02ad15ac359@proton.me
---
Zakariya Hadrami (5):
dt-bindings: watchdog: mediatek: Add MT8127
dt-bindings: arm: mediatek: Add MT8127 Amazon ford
ARM: dts: mediatek: mt8127: Fix indentation error
ARM: dts: mediatek: mt8127: Add watchdog support
ARM: dts: mediatek: Add basic support for Amazon ford board
.../devicetree/bindings/arm/mediatek.yaml | 1 +
.../bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
arch/arm/boot/dts/mediatek/Makefile | 1 +
arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts | 46 ++++++++++++++++++++++
arch/arm/boot/dts/mediatek/mt8127.dtsi | 9 ++++-
5 files changed, 57 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260616-mt8127-amazon-ford-basic-1509d7052f7e
Best regards,
--
Zakariya Hadrami <zkh1@proton.me>
^ permalink raw reply
* [PATCH v2 2/5] dt-bindings: arm: mediatek: Add MT8127 Amazon ford
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-0-6859e29e72a8@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add entry for the MT8127 based Amazon ford tablet.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
Documentation/devicetree/bindings/arm/mediatek.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 382d0eb4d0af..853f5e8cd158 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -122,6 +122,7 @@ properties:
- const: mediatek,mt7988a
- items:
- enum:
+ - amazon,ford
- mediatek,mt8127-moose
- const: mediatek,mt8127
- items:
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/5] ARM: dts: mediatek: mt8127: Fix indentation error
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-0-6859e29e72a8@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Fix an indentation error caused by a space at the start of a line.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
arch/arm/boot/dts/mediatek/mt8127.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mediatek/mt8127.dtsi b/arch/arm/boot/dts/mediatek/mt8127.dtsi
index aced173c2a52..bd61ec7e70c0 100644
--- a/arch/arm/boot/dts/mediatek/mt8127.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt8127.dtsi
@@ -75,7 +75,7 @@ uart_clk: dummy26m {
compatible = "fixed-clock";
clock-frequency = <26000000>;
#clock-cells = <0>;
- };
+ };
};
timer {
--
2.54.0
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: mediatek: mt8127: Add watchdog support
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-0-6859e29e72a8@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
Add watchdog node and disable it by default as it was not present
initially.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
arch/arm/boot/dts/mediatek/mt8127.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt8127.dtsi b/arch/arm/boot/dts/mediatek/mt8127.dtsi
index bd61ec7e70c0..3e23673e7a9e 100644
--- a/arch/arm/boot/dts/mediatek/mt8127.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt8127.dtsi
@@ -99,6 +99,13 @@ soc {
compatible = "simple-bus";
ranges;
+ watchdog: watchdog@10007000 {
+ compatible = "mediatek,mt8127-wdt","mediatek,mt6589-wdt";
+ reg = <0 0x10007000 0 0x100>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_LOW>;
+ status = "disabled";
+ };
+
timer: timer@10008000 {
compatible = "mediatek,mt8127-timer",
"mediatek,mt6577-timer";
--
2.54.0
^ permalink raw reply related
* [PATCH v2 5/5] ARM: dts: mediatek: Add basic support for Amazon ford board
From: Zakariya Hadrami via B4 Relay @ 2026-06-17 13:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
linux-watchdog, Zakariya Hadrami
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-0-6859e29e72a8@proton.me>
From: Zakariya Hadrami <zkh1@proton.me>
This tablet uses a MediaTek MT8127 system-on-chip with 1GB of RAM.
It can currently boot into initramfs with a working UART and
Simple Framebuffer using already initialized panel by the bootloader.
Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
---
arch/arm/boot/dts/mediatek/Makefile | 1 +
arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts | 46 +++++++++++++++++++++++
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/Makefile b/arch/arm/boot/dts/mediatek/Makefile
index 37c4cded0eae..a610bc75c7d9 100644
--- a/arch/arm/boot/dts/mediatek/Makefile
+++ b/arch/arm/boot/dts/mediatek/Makefile
@@ -14,5 +14,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7623n-rfb-emmc.dtb \
mt7623n-bananapi-bpi-r2.dtb \
mt7629-rfb.dtb \
+ mt8127-amazon-ford.dtb \
mt8127-moose.dtb \
mt8135-evbp1.dtb
diff --git a/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
new file mode 100644
index 000000000000..21bdab0e43f8
--- /dev/null
+++ b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+#include "mt8127.dtsi"
+
+/ {
+ model = "MediaTek MT8127 Amazon Ford";
+ compatible = "amazon,ford", "mediatek,mt8127";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+
+ framebuffer0: framebuffer@b7a00000 {
+ compatible = "simple-framebuffer";
+ memory-region = <&framebuffer_reserved>;
+ width = <1024>;
+ height = <600>;
+ stride = <(1024 * 2)>;
+ format = "r5g6b5";
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0 0x80000000 0 0x40000000>;
+ };
+
+ reserved-memory {
+ framebuffer_reserved: framebuffer@b7a00000 {
+ reg = <0 0xb7a00000 0 0x1000000>;
+ no-map;
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&watchdog {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v5 09/10] dt-bindings: firmware: add arm,ras-cper
From: Ahmed Tiba @ 2026-06-17 13:41 UTC (permalink / raw)
To: Rob Herring
Cc: Jonathan Cameron, will, xueshuai, saket.dumbre, mchehab, dave,
djbw, bp, tony.luck, guohanjun, lenb, skhan, vishal.l.verma,
rafael, corbet, ira.weiny, dave.jiang, krzk+dt, catalin.marinas,
alison.schofield, conor+dt, linux-arm-kernel, Michael.Zhao2,
linux-doc, linux-kernel, linux-cxl, Dmitry.Lamerov, devicetree,
linux-acpi, linux-edac, acpica-devel
In-Reply-To: <20260612144910.GA989816-robh@kernel.org>
On 12/06/2026 15:49, Rob Herring wrote:
> On Thu, Jun 11, 2026 at 03:22:21PM +0100, Ahmed Tiba wrote:
>> On 29/05/2026 17:44, Jonathan Cameron wrote:
>>> On Fri, 29 May 2026 10:50:49 +0100
>>> Ahmed Tiba<ahmed.tiba@arm.com> wrote:
>>>> .../devicetree/bindings/firmware/arm,ras-cper.yaml | 54 ++++++++++++++++++++++
>>>> MAINTAINERS | 5 ++
>>>> 2 files changed, 59 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
>>>> new file mode 100644
>>>> index 000000000000..3d4de096093f
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
>>>> @@ -0,0 +1,54 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id:http://devicetree.org/schemas/firmware/arm,ras-cper.yaml#
>>>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Arm RAS CPER provider
>>>> +
>>>> +maintainers:
>>>> + - Ahmed Tiba<ahmed.tiba@arm.com>
>>>> +
>>>> +description:
>>>> + Arm Reliability, Availability and Serviceability (RAS) firmware can expose
>>>> + a firmware-first CPER error source directly via DeviceTree. Firmware
>>>> + provides the CPER Generic Error Status block and notifies the OS through
>>>> + an interrupt.
>>> I'd like some spec references in here if possible.
>> I can add a reference to the UEFI CPER specification for the Generic
>> Error Status record format.
>>
>> For the firmware-first DT description itself I do not have a more specific
>> public reference to cite.
>
> Is there a platform actually using this with DT (FVP doesn't really
> count)?
>
> Rob
Yes. The initial intended user is the upstream zena-css platform,
with validation so far on FVP.
I will note that in the next revision commit message and cover letter.
Best regards,
Ahmed
^ permalink raw reply
* Re: [PATCH 3/7] hwmon: adm1275: Support ROHM BD12780
From: Guenter Roeck @ 2026-06-17 13:50 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen, Matti Vaittinen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Wensheng Wang, Ashish Yadav, Kim Seer Paller,
Cedric Encarnacion, Chris Packham, Yuxi Wang, Charles Hsu,
ChiShih Tsai, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <46b3f680-91a9-4a2a-a197-8f0ca5e38b90@gmail.com>
On 6/16/26 22:48, Matti Vaittinen wrote:
> Thanks for taking the time to review this! Feedback is appreciated :)
>
> On 16/06/2026 17:13, Guenter Roeck wrote:
>> On 6/15/26 23:36, Matti Vaittinen wrote:
>>> From: Matti Vaittinen <mazziesaccount@gmail.com>
>>>
>>> ROHM BD12780 and BD12780A are hot-swap controllers. They are largely
>>> similar to Analog Devices ADM1278. Besides the ID registers and some
>>> added functionality, the BD12780 and BD12780A mark PMON_CONFIG bits
>>> [15:14] as reserved. Hence TSFILT setting must be omitted on these ICs.
>>>
>>> The BD12780 has 3 pins usable for configuring the I2C address. The
>>> BD12780A lists the ADDR3-pin as "not connect".
>>>
>>> Support ROHM BD12780 and BD12780A controllers.
>>>
>>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>> ---
>>> drivers/hwmon/pmbus/Kconfig | 2 +-
>>> drivers/hwmon/pmbus/adm1275.c | 46 +++++++++++++++++++++++++++++------
>>> 2 files changed, 39 insertions(+), 9 deletions(-)
>>>
>
> // snip
>
>>> @@ -487,6 +489,21 @@ static const struct i2c_device_id adm1275_id[] = {
>>> { "adm1281", adm1281 },
>>> { "adm1293", adm1293 },
>>> { "adm1294", adm1294 },
>>> + /*
>>> + * The BD12780a is functionally identical to BD12780(*). Even the pmbus ID
>>> + * register contents are same. When instantiated from the DT, it is required
>>> + * to have the bd12780 as a fall-back. We still need the bd12780a ID here,
>>> + * because the i2c_device_id is created from the first compatible, not from
>>> + * the fall-back entry.
>>> + * (*)Until proven to differ. I prefer having own compatible for these
>>> + * variants for that day. Please note that even though the probe is called
>>> + * based on the 'bd12780a' -entry, the ID is picked at probe based on the
>>> + * pmbus register contents and not by DT entry. Thus, if the bd12780 and
>>> + * bd12780a are found to require different handling, then this needs to be
>>> + * changed, or bd12780a is handled as bd12780.
>>> + */
>>> + { "bd12780", bd12780 },
>>> + { "bd12780a", /* driver data unused, see --^ */ },
>>
>> We don't usually do that. There are various A/B/C variants for many chips,
>> and we just use the base name unless a difference is warranted. Either this
>> is needed, and driver data is needed as well, or it isn't. If it is not needed,
>> it should be dropped.
>
> At the moment the only difference I know is reduced amount of I2C slave addresses. This shouldn't be visible to this driver.
>
> My problem is that I don't know for sure if we later notice something that requires differentiating. Thus I would like to have different DT compatibles (or other source of I2C IDs if those are used to instantiate the driver). If we don't do this, then we have problems if we later find out that these ICs require different handling as users because we can't differentiate these ICs if they are described with same compatible/I2C ID.
>
> The "fun" thing is that both variants have exactly same MFR_MODEL and MFR_REVISION register contents. Thus, these ICs can't be differentiated by reading PMBus registers.
>
> This is also why the driver data entry gets unused. The existing probe mechanism in this driver, scans the names in this ID list and compares it to the PMBus MFR_MODEL, and then picks-up the driver data to use. Now because BD12780 and BD12780A both have same MFR_MODEL, the scan in probe will always pick the same driver data entry, no matter what ID was matched by bus code. That's why I added the comment here.
>
> If I drop the { "bd12780a", /* driver data unused, see --^ */ } -entry from the ID list and add the of_device_ids, then I think this problem is solved for the DT-platforms. As far as I understand, this would still cause any non DT platform to describe both variants as "bd12780", making it impossible to later differentiate ICs in the driver, right? I can do this, but for me it feels a bit like asking for problems...
>
> My thinking was to have different IDs for these variants so hardware description could have different IDs for different ICs. Then, if we later need to differentiate these ICs, we still have an option to change the probe to trust the i2c_get_match_data() when PMBus indicates the bd12780.
>
> This however is some extra complexity, and I would like to add it to the probe only if it really is required.
>
> But yeah, having an ID entry in the list and driver data not used even when the matching IC is found, is unusual and would have caught me off guard. Hence I added the (long) comment.
>
It is unusual and unnecessary. If for whatever reason it turns out to be necessary
later to have a separate ID, add it then. Again, there are lots of chips with A/B/C
variants. We only add separate entries for them if/when needed just for "in case".
>>
>>> { "mc09c", sq24905c },
>>> { }
>>> };
>
> // snip
>
>>> @@ -712,7 +732,16 @@ static int adm1275_probe(struct i2c_client *client)
>>> break;
>>> case adm1278:
>>> case adm1281:
>>> + case bd12780:
>>> case sq24905c:
>>> + {
>>> + u16 defconfig;
>>> +
>>> + if (data->id == bd12780)
>>> + defconfig = BD12780_PMON_DEFCONFIG;
>>> + else
>>> + defconfig = ADM1278_PMON_DEFCONFIG;
>>> +
>>
>> Please add a separate case statement for the new chip
>> and do not overload existing chip data.
>
> I originally did just that. I, however, was not happy with this as it resulted quite long own case this IC, which is almost identical to this other (adm1278, adm1281, sq24905c) case. I wanted the code to shout that the DB12780 is indeed (almost) identical to the adm1278. But yeah, I agree, having "if (foo)" in "switch (foo)" case can get confusing.
>
Better that than embedded if statements. At some point it would
probably make sense to rework the driver to use per-chip configuration
data, similar to other drivers such as lm90. But that would be a separate
effort. Until then, please keep per-chip configuration in separate case
statements.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v6 4/4] arm64: dts: nuvoton: npcm845-evb: Add peripheral nodes
From: sashiko-bot @ 2026-06-17 13:53 UTC (permalink / raw)
To: Tomer Maimon; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260617133212.287768-5-tmaimon77@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Incorrect type for PWM fan cooling-levels property causes intermediate cooling states to turn fans off.
- [Medium] The `&fiux` node is missing the `status = "okay";` property, so the controller will remain disabled.
- [Medium] The FIU aliases intentionally violate device tree bindings to work around a hardcoded driver array, improperly swapping physical mappings.
- [Medium] The `ipmb@10` and `ipmb@11` nodes lack the `I2C_OWN_SLAVE_ADDRESS` bitmask in their `reg` property.
--
commit cf191e9e7fae85040690a2905adeff456af8e03b
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, and flash partitions. Enable various peripheral
controllers and interfaces with board-specific pinctrl and phy connections.
> diff --git a/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts b/arch/arm64/boot/dts/nuvoton/nuvoton-npcm845-evb.dts
> index 5edf5d13342da..1092dc5bb7aba 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;
[Severity: Medium]
Do these aliases intentionally violate the device tree bindings for the soc?
The device tree bindings explicitly map the fiu1 node to the fiu1 hardware,
fiu2 to fiu3, and fiu3 to fiux.
Mapping fiu1 to &fiu3, fiu2 to &fiux, and fiu3 to &fiu1 appears to swap
the physical mappings to match the hardcoded npxm8xx_fiu_info array in
spi-npcm-fiu.c.
Should the driver be fixed instead of working around it by conflicting with
the physical hardware intent here?
[ ... ]
> +&fiux {
> + nuvoton,spix-mode;
> +};
[Severity: Medium]
Will the fiux controller remain disabled without setting its status?
The commit message mentions enabling the controllers, but the base soc
dtsi file defaults the fiux node to status = "disabled".
Is a status = "okay" property needed here to ensure the kernel actually
probes it?
[ ... ]
> +&pwm_fan {
> + status = "okay";
> + pinctrl-names = "default";
[ ... ]
> + fan@0 {
> + reg = <0x00>;
> + fan-tach-ch = /bits/ 8 <0x0 0x1>;
> + cooling-levels = <127 255>;
> + };
[Severity: High]
Does this cooling-levels definition cause intermediate thermal states to
turn the fans completely off?
The npcm750-pwm-fan.c driver parses cooling-levels strictly as an array of
8-bit unsigned integers via of_property_read_u8_array(). Because the
/bits/ 8 directive is missing, the device tree compiler generates two
32-bit big-endian integers (00 00 00 7f 00 00 00 ff).
When the driver counts the elements using of_property_count_u8_elems(), it
will find 8 states instead of 2. The parsed levels become:
[0, 0, 0, 127, 0, 0, 0, 255]
Could this result in a 0% duty cycle when requesting intermediate states
like state 0, 1, or 2, risking hardware overheating? Should this be written
as cooling-levels = /bits/ 8 <127 255>; instead?
[ ... ]
> +&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;
> + };
> +};
[Severity: Medium]
Are the I2C_OWN_SLAVE_ADDRESS bitmasks missing from these reg properties?
According to the ipmb-dev device tree bindings, ipmb devices must operate
as i2c slaves. Passing a raw address like reg = <0x10> tells the i2c core
to treat it as a master-side client target.
This can trigger a warning in i2c_slave_register() and might cause address
collisions or break reception. Should this be defined as
reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>; to instruct the underlying
controller to listen in slave mode?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617133212.287768-1-tmaimon77@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH 6/7] hwmon: adm1275: Support ROHM BD12790
From: Guenter Roeck @ 2026-06-17 13:54 UTC (permalink / raw)
To: Matti Vaittinen, Matti Vaittinen, Matti Vaittinen
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Wensheng Wang, Ashish Yadav, Kim Seer Paller,
Cedric Encarnacion, Chris Packham, Yuxi Wang, Charles Hsu,
ChiShih Tsai, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <7e430392-1b27-4c3d-bfc7-1311b9838156@gmail.com>
On 6/16/26 22:56, Matti Vaittinen wrote:
> On 16/06/2026 17:08, Guenter Roeck wrote:
>> On 6/15/26 23:44, Matti Vaittinen wrote:
>>> From: Matti Vaittinen <mazziesaccount@gmail.com>
>>>
>>> Add support for ROHM BD12790 hot-swap controller which is largely
>>> similar to Analog Devices adm1272.
>>>
>>> The BD12790 uses the same selectable 60V/100V voltage ranges and
>>> 15mV/30mV current-sense ranges as the ADM1272, and the same VRANGE
>>> (bit 5) and IRANGE (bit 0) layout in PMON_CONFIG. It therefore uses
>>> a dedicated coefficient table that mirrors adm1272_coefficients, with
>>> the following differences derived from BD12790 datasheet Table 1 (p.18):
>>> - power 60V/30mV: m=17560 (vs. 17561)
>>> - power 100V/30mV: m=10536 (vs. 10535)
>>> - temperature: b=31880 (vs. 31871, reflecting T[11:0] = 4.2*T + 3188)
>>>
>>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>> Assisted-by: GitHub Copilot:claude-sonnet-4.6
>>>
>>> ---
>>> Originally this patch was AI-generated. I did pretty much re-write the
>>> probe changes by hand, and also fixed some of the coefficient math
>>> afterwards :/ But yeah, this one was AI "assisted". :)
>>>
>>> drivers/hwmon/pmbus/Kconfig | 4 +--
>>> drivers/hwmon/pmbus/adm1275.c | 53 +++++++++++++++++++++++++++++------
>>> 2 files changed, 47 insertions(+), 10 deletions(-)
>
> // snip
>
>>> @@ -655,12 +681,23 @@ static int adm1275_probe(struct i2c_client *client)
>>> break;
>>> case adm1272:
>>> case adm1273:
>>> + case bd12790:
>>
>> Please don't overload the existing case statements.
>> Just add separate case statements for the new chips.
>>
>
> Hmm. Ok, although, here, same as with the BD12780, I would like the code to clearly show that the BD12790 is very very similar to another IC (adm1272). When we have own case for it, this information gets kind of lost as these cases are a tad too long to easily spot the differences. If there are any ideas how to ease spotting this while having own cases - I am keen to hear.
>
You could add a comment into the case statement.
Guenter
^ permalink raw reply
* [PATCH v6 00/10] ACPI: APEI: share GHES CPER helpers and add DT FFH provider
From: Ahmed Tiba @ 2026-06-17 13:54 UTC (permalink / raw)
To: Rafael J. Wysocki, Tony Luck, Borislav Petkov, Hanjun Guo,
Mauro Carvalho Chehab, Shuai Xue, Len Brown, Saket Dumbre,
Davidlohr Bueso, Jonathan Cameron, Dave Jiang, Alison Schofield,
Vishal Verma, Ira Weiny, Dan Williams, Ahmed Tiba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: linux-kernel, linux-acpi, acpica-devel, linux-cxl, devicetree,
linux-edac, linux-doc, Dmitry.Lamerov
This is v6 of the GHES refactor series. Compared to v5, it addresses
the latest review comments and tightens the DT CPER provider and
related helper wiring.
The DT firmware-first CPER provider is intended for the upstream
zena-css platform. Validation so far has been on FVP.
Changes in v6:
- Keep cper_estatus_len() out of the final DT provider patch by restoring it
to the APEI internal header and keeping the DT-side length helper local.
- Remove the include guard dance around apei-internal.h in ghes_cper.c.
- Drop stray vendor notifier declarations from ghes_cper.h.
- Rework the DT CPER provider to:
- validate block_status and CPER lengths before parsing
- remove the unsupported synchronous/SEA path
- embed struct acpi_hest_generic in the driver state
- remove the unnecessary copy helper
- avoid caching DT-provider estatus records
- reject undersized status buffers
- bound source_id to u16 and document why 0 is left unused
- consume the status and ack buffers from the binding-defined
memory-region entries
- treat those regions as shared memory rather than MMIO
- clear block_status after consuming a record before raising the ack bit
- Rewrite and rewrap the admin-guide text to describe the DT firmware-first
CPER model directly.
Link to v5: https://lore.kernel.org/r/20260529-topics-ahmtib01-ras_ffh_arm_internal_review-v5-0-2e0500d42642@arm.com
ACPI: APEI: share GHES CPER helpers and add DT FFH provider
This is v5 of the GHES refactor series. Compared to v4, it only updates
the DT binding to address the latest review comments.
Changes in v5:
- Dropped the `oneOf` from `memory-region` and described it as a plain
list with `minItems: 1`.
- Simplified the DT example to keep only the `arm,ras-cper` device node.
- Link to v4: https://lore.kernel.org/r/20260518-topics-ahmtib01-ras_ffh_arm_internal_review-v4-0-42698675ba61@arm.com
ACPI: APEI: share GHES CPER helpers and add DT FFH provider
This is v4 of the GHES refactor series. Compared to v3, it mainly
updates the shared header comment and the DT binding/description
for the firmware-owned CPER buffer.
Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
Changes in v4:
- Reworded the ghes_cper.h header comment and kept the original copyrights.
- Fixed the ghes_cper.h W=1 warnings by limiting the ACPI
fixmap-based declarations to the ACPI build path.
- Updated the DT binding to describe the CPER buffer
as firmware-owned shared memory.
- Described the optional ack area as a second memory-region entry.
- Updated the DT example accordingly.
- Link to v3: https://lore.kernel.org/r/20260318-topics-ahmtib01-ras_ffh_arm_internal_review-v3-0-48e6a1c249ef@arm.com
Changes in v3:
- Fixed the new ghes_cper.h header comment and kept the original
copyrights.
- Added <linux/bitfield.h> to fix the kernel test robot build failure.
- Renamed the binding/compatible and DT-side naming to ras-cper.
- Switched the DT provider to generic firmware property accessors.
- Replaced atomic source IDs with IDA.
- Updated IRQ/error/resource handling as suggested in review
(platform_get_irq(), dev_err_probe(), devm platform ioremap
helpers).
- Removed the ARM64 dependency and fixed Kconfig/build coverage.
- Clarified comments and kept the early move patches mechanical.
- Link to v2: https://lore.kernel.org/r/20260220-topics-ahmtib01-ras_ffh_arm_internal_review-v2-0-347fa2d7351b@arm.com
Changes in v2:
- Dropped the proposed "estatus core" and kept GHES naming/flow intact
(per Borislav Petkov).
- Re-sliced the series into smaller mechanical steps (per Mauro Carvalho Chehab).
- Minor DT binding fixes based on Krzysztof Kozlowski's feedback.
- Removed fixmap slot usage from the DT FFH driver (per Will Deacon).
Series structure:
- Patches 1-8 are mechanical moves only and do not change behavior.
- Patch 9 wires the shared helpers back into GHES.
- The DT firmware-first CPER buffer provider is added in the final patches.
- "ACPI: APEI: introduce GHES helper" is internal build glue only
and does not introduce a new user-visible configuration option.
- Link to v1: https://lore.kernel.org/r/20251217112845.1814119-1-ahmed.tiba@arm.com
---
Ahmed Tiba (10):
ACPI: APEI: GHES: share macros via a private header
ACPI: APEI: GHES: move CPER read helpers
ACPI: APEI: GHES: move GHESv2 ack and alloc helpers
ACPI: APEI: GHES: move estatus cache helpers
ACPI: APEI: GHES: move vendor record helpers
ACPI: APEI: GHES: move CXL CPER helpers
ACPI: APEI: introduce GHES helper
ACPI: APEI: share GHES CPER helpers
dt-bindings: firmware: add arm,ras-cper
RAS: add firmware-first CPER provider
Documentation/admin-guide/RAS/main.rst | 15 +
.../devicetree/bindings/firmware/arm,ras-cper.yaml | 52 +
MAINTAINERS | 6 +
drivers/Makefile | 1 +
drivers/acpi/Kconfig | 4 +
drivers/acpi/apei/Kconfig | 1 +
drivers/acpi/apei/apei-internal.h | 3 +-
drivers/acpi/apei/ghes.c | 1043 +------------------
drivers/acpi/apei/ghes_cper.c | 1056 ++++++++++++++++++++
drivers/ras/Kconfig | 11 +
drivers/ras/Makefile | 1 +
drivers/ras/cper-esource.c | 322 ++++++
include/acpi/ghes.h | 10 +-
include/acpi/ghes_cper.h | 141 +++
include/cxl/event.h | 2 +-
15 files changed, 1621 insertions(+), 1047 deletions(-)
---
base-commit: b1cbabe84ca1381a004fb91ee1791a1a53bce44e
change-id: 20260220-topics-ahmtib01-ras_ffh_arm_internal_review-bfddc7fc7cab
Best regards,
--
Ahmed Tiba <ahmed.tiba@arm.com>
^ 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