* Re: [PATCH v1 2/7] ASoC: codecs: ES8389: Modify volatile_register
From: sashiko-bot @ 2026-06-11 3:31 UTC (permalink / raw)
To: Zhang Yi; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260611031824.4628-3-zhangyi@everest-semi.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Incomplete volatile register whitelist causes state loss on suspend/resume.
- [High] Ignored `regmap_read()` return values lead to the use of uninitialized stack variables.
- [High] Unbalanced clock prepare/enable and disable/unprepare calls due to manual bias level manipulation.
--
commit 13fa26be72cc2a7540f3f86a2ef766aae985561e
Author: Zhang Yi <zhangyi@everest-semi.com>
ASoC: codecs: ES8389: Modify volatile_register
Mark some registers that are not volatile as false
And modified the logic for cache_bypass during 8389_resume.
> diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
> index 449d9574b03a8..be7a36f17083f 100644
> --- a/sound/soc/codecs/es8389.c
> +++ b/sound/soc/codecs/es8389.c
> @@ -50,10 +50,29 @@ static const char * const es8389_core_supplies[] = {
> static bool es8389_volatile_register(struct device *dev,
> unsigned int reg)
> {
> - if ((reg <= 0xff))
> - return true;
> - else
> + switch (reg) {
> + case ES8389_ADCL_VOL:
> + case ES8389_ADCR_VOL:
> + case ES8389_MIC1_GAIN:
> + case ES8389_MIC2_GAIN:
> + case ES8389_DACL_VOL:
> + case ES8389_DACR_VOL:
> + case ES8389_ALC_ON:
> + case ES8389_ALC_CTL:
> + case ES8389_ALC_TARGET:
> + case ES8389_ALC_GAIN:
> + case ES8389_ADC_MUTE:
> + case ES8389_OSR_VOL:
> + case ES8389_DAC_INV:
> + case ES8389_MIX_VOL:
> + case ES8389_DAC_MIX:
> + case ES8389_ADC_RESET:
> + case ES8389_ADC_MODE:
> + case ES8389_DMIC_EN:
> return false;
> + default:
> + return true;
> + }
> }
[Severity: High]
This isn't a bug introduced by this patch, but will this incomplete whitelist
cause state loss across suspend/resume cycles?
Because the default case marks all unlisted registers as volatile, critical
configuration registers like ES8389_ADC_HPF2, ES8389_MASTER_MODE, and
ES8389_CLK_DIV1 are omitted from the cache.
Since regcache_sync() skips volatile registers, won't es8389_init() just
overwrite these with default values during resume, discarding any active
user configurations?
[ ... ]
> @@ -861,13 +880,13 @@ static int es8389_resume(struct snd_soc_component *component)
> regcache_cache_only(es8389->regmap, false);
> regcache_cache_bypass(es8389->regmap, true);
> regmap_read(es8389->regmap, ES8389_RESET, ®v);
[Severity: High]
This is a pre-existing issue, but does this code risk branching on an
uninitialized variable?
If regmap_read() fails during early resume, regv will contain uninitialized
stack memory. The subsequent check against 0xff will yield unpredictable
results, potentially skipping the required initialization.
The same issue appears to exist in es8389_init() when reading
ES8389_MAX_REGISTER into the local variable reg before assigning it to
es8389->version. Could we check the return values of these reads?
> - regcache_cache_bypass(es8389->regmap, false);
>
> if (regv == 0xff)
> es8389_init(component);
> else
> es8389_set_bias_level(component, SND_SOC_BIAS_ON);
[Severity: High]
This is a pre-existing issue, but does calling es8389_set_bias_level()
directly from the resume and suspend handlers conflict with the ASoC DAPM
framework?
Since DAPM independently transitions bias levels and triggers the
registered set_bias_level callback, it seems this direct call would cause
clk_prepare_enable() to run multiple times on resume, leaking the clock
reference count.
Similarly, during suspend, wouldn't redundant calls to
clk_disable_unprepare() cause a clock underflow warning?
>
> + regcache_cache_bypass(es8389->regmap, false);
> regcache_sync(es8389->regmap);
>
> return 0;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611031824.4628-1-zhangyi@everest-semi.com?part=2
^ permalink raw reply
* Re: [PATCH v1 1/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: sashiko-bot @ 2026-06-11 3:28 UTC (permalink / raw)
To: Zhang Yi; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260611031824.4628-2-zhangyi@everest-semi.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Adding Devicetree properties ('everest,hpfl', 'everest,hpfr') that represent raw register values instead of physical hardware descriptions, and statically configuring audio processing features that should be ALSA kcontrols.
- [Medium] Custom clock routing property 'everest,mclk-from-sclk' bypasses standard ASoC clock configuration APIs.
--
commit f53482d6ef6f3f66c8185a876c24dae03171cfd8
Author: Zhang Yi <zhangyi@everest-semi.com>
ASoC: dt-bindings: ES8389: Add members about HPF and clock
Add members related to HPF and mclk_source. The value of HPF is not dB, it
is just the value of registers. And add HPF settings to the example.
> diff --git a/Documentation/devicetree/bindings/sound/everest,es8389.yaml b/Documentation/devicetree/bindings/sound/everest,es8389.yaml
> index 75ce0bc489045..be92014c0c597 100644
> --- a/Documentation/devicetree/bindings/sound/everest,es8389.yaml
> +++ b/Documentation/devicetree/bindings/sound/everest,es8389.yaml
> @@ -38,6 +38,27 @@ properties:
> description:
> Interface power supply.
>
> + everest,mclk-from-sclk:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + Indicates that SCLK is used as the internal clock.
[Severity: Medium]
Does this custom boolean flag bypass standard ASoC clock configuration APIs?
Statically configuring the codec to use SCLK as the internal clock via
devicetree limits machine driver flexibility. ASoC clock routing decisions
are normally handled dynamically by the machine driver using standard APIs
like snd_soc_dai_set_sysclk() and the standard devicetree clocks property.
A later commit in the series (ASoC: codecs: ES8389: Fix the issue about
mclk_src) addresses a type mismatch where the driver initially expected a u8
instead of a boolean, but the architectural bypass issue remains.
> +
> + everest,hpfl:
> + $ref: /schemas/types.yaml#/definitions/uint8
> + description:
> + the HPF value of ADCL.
> + minimum: 0x00
> + maximum: 0x0f
> + default: 0x0a
> +
> + everest,hpfr:
> + $ref: /schemas/types.yaml#/definitions/uint8
> + description:
> + the HPF value of ADCR.
> + minimum: 0x00
> + maximum: 0x0f
> + default: 0x0a
[Severity: Medium]
Should these properties be represented as ALSA kcontrols instead?
Devicetree is designed to describe hardware topology and physical
characteristics, not to pass raw register configurations. Audio processing
parameters like a High-Pass Filter (HPF) should be exposed to userspace as
ALSA kcontrols so they can be dynamically adjusted or bypassed.
In sound/soc/codecs/es8389.c:es8389_probe(), the driver reads these custom
raw register properties directly. Can we expose these as kcontrols instead?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611031824.4628-1-zhangyi@everest-semi.com?part=1
^ permalink raw reply
* Re: [PATCH v1 4/7] ASoC: codecs: ES8389: Modify the clock table
From: sashiko-bot @ 2026-06-11 3:27 UTC (permalink / raw)
To: Zhang Yi; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260611031824.4628-5-zhangyi@everest-semi.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Flawed clock coefficient matching logic makes `dmic_sel = 0` and `dvdd_vol = 0` act as wildcards, leading to incorrect hardware configuration and dead code.
- [High] Unchecked `regmap_read()` return value leads to the use of uninitialized stack memory for hardware configuration.
--
commit b24373f65176191e8456a8034960817f67429760
Author: Zhang Yi <zhangyi@everest-semi.com>
ASoC: codecs: ES8389: Modify the clock table
Updated the configuration for certain frequencies
If get_coeff does not find a value that matches the condition, return -EINVAL
> diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
> index 886069be1535f..647d9d62820e6 100644
> --- a/sound/soc/codecs/es8389.c
> +++ b/sound/soc/codecs/es8389.c
[ ... ]
> @@ -434,52 +434,54 @@ static const struct _coeff_div coeff_div[] = {
[ ... ]
> {256, 24576000, 96000, 0x00, 0x40, 0x00, 0xC0, 0x10, 0xC1, 0x80, 0xC0, 0x00, 0x9F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x80, 0x12, 0xC0, 0x35, 0x91, 0x28, 2, 2},
> {128, 24576000, 192000, 0x00, 0x50, 0x00, 0xC0, 0x18, 0xC1, 0x81, 0xC0, 0x00, 0x8F, 0x7F, 0xBF, 0xC0, 0x3F, 0x7F, 0x80, 0x12, 0xC0, 0x3F, 0xF9, 0x3F, 2, 2},
> + {64, 12288000, 192000, 0x00, 0x41, 0x00, 0xC0, 0x18, 0xC1, 0x80, 0x00, 0x00, 0x8F, 0x7F, 0xEF, 0xC0, 0x7F, 0x7F, 0x80, 0x12, 0xC0, 0x3F, 0xF9, 0x3F, 1, 0},
[Severity: High]
This is a pre-existing issue, but will the wildcard matching logic in
get_coeff() cause this new entry to match incorrectly?
In get_coeff(), the wildcard logic uses modulo 2:
dmic_det |= ~(coeff_div[i].dmic_sel % 2) & 0x01;
For dmic_sel = 0, 0 % 2 == 0, which forces dmic_det to 1 regardless of the
requested dmic state. This makes 0 behave exactly like the 2 wildcard. As a
result, entries intending to strictly match dmic = 0 (such as this newly
added entry) will incorrectly match any DMIC state.
Could this also cause existing entries like `{... 2, 0}` to mask subsequent
`{... 2, 1}` entries, resulting in unreachable dead code and incorrect
hardware coefficients being applied?
> };
>
> static inline int get_coeff(u8 vddd, u8 dmic, int mclk, int rate)
[ ... ]
> @@ -657,7 +659,8 @@ static int es8389_pcm_hw_params(struct snd_pcm_substream *substream,
> regmap_write(es8389->regmap, ES8389_SYSTEM18, coeff_div[coeff].Reg0x18);
> regmap_write(es8389->regmap, ES8389_SYSTEM19, coeff_div[coeff].Reg0x19);
> } else {
> - dev_warn(component->dev, "Clock coefficients do not match");
> + dev_err(component->dev, "Clock coefficients do not match");
> + return -EINVAL;
[Severity: High]
This is a pre-existing issue, but could the lack of error checking on
regmap_read() lead to the use of uninitialized stack memory for hardware
configuration?
Earlier in es8389_pcm_hw_params(), the driver calls regmap_read() without
validating its return value:
regmap_read(es8389->regmap, ES8389_DMIC_EN, ®v);
dmic_enable = regv >> 7 & 0x01;
If the underlying communication fails, the local variable regv remains
uninitialized. This stack memory is then immediately evaluated when selecting
coefficients. Could this cause the driver to select and apply random,
non-deterministic clock coefficients to the hardware?
> }
>
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611031824.4628-1-zhangyi@everest-semi.com?part=4
^ permalink raw reply
* Re: [PATCH v1 5/7] ASoC: codecs: ES8389: Modify the initial configuration
From: sashiko-bot @ 2026-06-11 3:26 UTC (permalink / raw)
To: Zhang Yi; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260611031824.4628-6-zhangyi@everest-semi.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The return values of multiple `regmap_read()` calls are ignored, leading to the use of uninitialized stack variables.
--
commit eeca5823fe9bef5ffe179596ec0a3aab2d9ba07a
Author: Zhang Yi <zhangyi@everest-semi.com>
ASoC: codecs: ES8389: Modify the initial configuration
Modify the initial configuration.
> diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
> index 647d9d62820e6..284eb707f9f7f 100644
> --- a/sound/soc/codecs/es8389.c
> +++ b/sound/soc/codecs/es8389.c
> @@ -793,7 +793,7 @@ static void es8389_init(struct snd_soc_component *component)
>
> regmap_read(es8389->regmap, ES8389_MAX_REGISTER, ®);
> es8389->version = reg;
[Severity: High]
This isn't a bug introduced by this patch, but I noticed the return value of
regmap_read() is ignored here. If the read fails, 'reg' will remain
uninitialized, and es8389->version will be corrupted with stack garbage.
Could this also cause unpredictable behavior in other parts of the driver?
Similar unchecked regmap_read() calls seem to exist in:
- es8389_pcm_hw_params() (corrupting dmic_enable)
- es8389_mute() (triggering spurious state changes)
- es8389_resume() (potentially triggering es8389_init() erroneously)
> - regmap_write(es8389->regmap, ES8389_ISO_CTL, 0x00);
> + regmap_write(es8389->regmap, ES8389_ISO_CTL, 0x56);
> regmap_write(es8389->regmap, ES8389_RESET, 0x7E);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611031824.4628-1-zhangyi@everest-semi.com?part=5
^ permalink raw reply
* [PATCH v1 7/7] ASoC: codecs: ES8389: Add INPUTL MUX and INPUTR MUX
From: Zhang Yi @ 2026-06-11 3:18 UTC (permalink / raw)
To: linux-sound, broonie, devicetree; +Cc: tiwai, robh, krzk+dt, conor+dt, Zhang Yi
In-Reply-To: <20260611031824.4628-1-zhangyi@everest-semi.com>
Add INPUTL MUX and INPUTR MUX in route
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
---
sound/soc/codecs/es8389.c | 35 +++++++++++++++++++++++++++++++++--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
index 2460cf977..23e85ddfe 100644
--- a/sound/soc/codecs/es8389.c
+++ b/sound/soc/codecs/es8389.c
@@ -164,6 +164,16 @@ static const struct soc_enum alc_ramprate =
static const struct soc_enum alc_winsize =
SOC_ENUM_SINGLE(ES8389_ALC_CTL, 0, 16, winsize);
+static const char *const es8389_adcl_mux_txt[] = {
+ "Normal",
+ "ADC2 channel to ADC1 channel",
+};
+
+static const char *const es8389_adcr_mux_txt[] = {
+ "Normal",
+ "ADC1 channel to ADC2 channel",
+};
+
static const char *const es8389_outl_mux_txt[] = {
"Normal",
"DAC2 channel to DAC1 channel",
@@ -191,6 +201,20 @@ static const unsigned int es8389_pga_values[] = {
1, 5, 6
};
+static const struct soc_enum es8389_adcl_mux_enum =
+ SOC_ENUM_SINGLE(ES8389_ADC_MODE, 5,
+ ARRAY_SIZE(es8389_adcl_mux_txt), es8389_adcl_mux_txt);
+
+static const struct snd_kcontrol_new es8389_adcl_mux_controls =
+ SOC_DAPM_ENUM("INPUTL MUX", es8389_adcl_mux_enum);
+
+static const struct soc_enum es8389_adcr_mux_enum =
+ SOC_ENUM_SINGLE(ES8389_ADC_MODE, 4,
+ ARRAY_SIZE(es8389_adcr_mux_txt), es8389_adcr_mux_txt);
+
+static const struct snd_kcontrol_new es8389_adcr_mux_controls =
+ SOC_DAPM_ENUM("INPUTR MUX", es8389_adcr_mux_enum);
+
static const struct soc_enum es8389_outl_mux_enum =
SOC_ENUM_SINGLE(ES8389_DAC_MIX, 5,
ARRAY_SIZE(es8389_outl_mux_txt), es8389_outl_mux_txt);
@@ -319,6 +343,8 @@ static const struct snd_soc_dapm_widget es8389_dapm_widgets[] = {
&es8389_adc_mixer_controls[0],
ARRAY_SIZE(es8389_adc_mixer_controls)),
SND_SOC_DAPM_MUX("ADC MUX", SND_SOC_NOPM, 0, 0, &es8389_dmic_mux_controls),
+ SND_SOC_DAPM_MUX("INPUTL MUX", SND_SOC_NOPM, 0, 0, &es8389_adcl_mux_controls),
+ SND_SOC_DAPM_MUX("INPUTR MUX", SND_SOC_NOPM, 0, 0, &es8389_adcr_mux_controls),
SND_SOC_DAPM_MUX("OUTL MUX", SND_SOC_NOPM, 0, 0, &es8389_outl_mux_controls),
SND_SOC_DAPM_MUX("OUTR MUX", SND_SOC_NOPM, 0, 0, &es8389_outr_mux_controls),
@@ -332,10 +358,15 @@ static const struct snd_soc_dapm_route es8389_dapm_routes[] = {
{"ADCL", NULL, "PGAL"},
{"ADCR", NULL, "PGAR"},
+ {"INPUTL MUX", "Normal", "ADCL"},
+ {"INPUTL MUX", "ADC2 channel to ADC1 channel", "ADCR"},
+ {"INPUTR MUX", "Normal", "ADCR"},
+ {"INPUTR MUX", "ADC1 channel to ADC2 channel", "ADCL"},
+
{"ADC Mixer", "DACL ADCL Mixer", "DACL"},
{"ADC Mixer", "DACR ADCR Mixer", "DACR"},
- {"ADC Mixer", NULL, "ADCL"},
- {"ADC Mixer", NULL, "ADCR"},
+ {"ADC Mixer", NULL, "INPUTL MUX"},
+ {"ADC Mixer", NULL, "INPUTR MUX"},
{"ADC MUX", "AMIC", "ADC Mixer"},
{"ADC MUX", "DMIC", "DMIC"},
--
2.17.1
^ permalink raw reply related
* [PATCH v1 6/7] ASoC: codecs: ES8389: Add private members related to HPF
From: Zhang Yi @ 2026-06-11 3:18 UTC (permalink / raw)
To: linux-sound, broonie, devicetree; +Cc: tiwai, robh, krzk+dt, conor+dt, Zhang Yi
In-Reply-To: <20260611031824.4628-1-zhangyi@everest-semi.com>
Add private members related to HPF.
And defines ES8389_HPF_DEFAULT
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
---
sound/soc/codecs/es8389.c | 18 ++++++++++++++++--
sound/soc/codecs/es8389.h | 1 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
index 284eb707f..2460cf977 100644
--- a/sound/soc/codecs/es8389.c
+++ b/sound/soc/codecs/es8389.c
@@ -36,6 +36,8 @@ struct es8389_private {
unsigned int sysclk;
int mastermode;
+ u8 hpfl;
+ u8 hpfr;
u8 vddd;
bool mclk_src;
int version;
@@ -743,8 +745,8 @@ static int es8389_mute(struct snd_soc_dai *dai, int mute, int direction)
regmap_update_bits(es8389->regmap, ES8389_DAC_FORMAT_MUTE,
0x03, 0x00);
} else {
- regmap_update_bits(es8389->regmap, ES8389_ADC_HPF1, 0x0f, 0x0a);
- regmap_update_bits(es8389->regmap, ES8389_ADC_HPF2, 0x0f, 0x0a);
+ regmap_update_bits(es8389->regmap, ES8389_ADC_HPF1, 0x0f, es8389->hpfl);
+ regmap_update_bits(es8389->regmap, ES8389_ADC_HPF2, 0x0f, es8389->hpfr);
regmap_update_bits(es8389->regmap, ES8389_ADC_FORMAT_MUTE,
0x03, 0x00);
}
@@ -902,6 +904,18 @@ static int es8389_probe(struct snd_soc_component *component)
es8389->mclk_src = device_property_read_bool(component->dev, "everest,mclk-from-sclk");
+ ret = device_property_read_u8(component->dev, "everest,hpfl", &es8389->hpfl);
+ if (ret != 0) {
+ dev_dbg(component->dev, "hpfl return %d\n", ret);
+ es8389->hpfl = ES8389_HPF_DEFAULT;
+ }
+
+ ret = device_property_read_u8(component->dev, "everest,hpfr", &es8389->hpfr);
+ if (ret != 0) {
+ dev_dbg(component->dev, "hpfr return %d\n", ret);
+ es8389->hpfr = ES8389_HPF_DEFAULT;
+ }
+
for (i = 0; i < ARRAY_SIZE(es8389_core_supplies); i++)
es8389->core_supply[i].supply = es8389_core_supplies[i];
ret = devm_regulator_bulk_get(component->dev, ARRAY_SIZE(es8389_core_supplies), es8389->core_supply);
diff --git a/sound/soc/codecs/es8389.h b/sound/soc/codecs/es8389.h
index 7f1212219..81353dcec 100644
--- a/sound/soc/codecs/es8389.h
+++ b/sound/soc/codecs/es8389.h
@@ -105,6 +105,7 @@
#define ES8389_MIC_SEL_MASK (7 << 4)
#define ES8389_MIC_DEFAULT (1 << 4)
+#define ES8389_HPF_DEFAULT (0x0A << 0)
#define ES8389_MASTER_MODE_EN (1 << 0)
--
2.17.1
^ permalink raw reply related
* [PATCH v1 4/7] ASoC: codecs: ES8389: Modify the clock table
From: Zhang Yi @ 2026-06-11 3:18 UTC (permalink / raw)
To: linux-sound, broonie, devicetree; +Cc: tiwai, robh, krzk+dt, conor+dt, Zhang Yi
In-Reply-To: <20260611031824.4628-1-zhangyi@everest-semi.com>
Updated the configuration for certain frequencies
If get_coeff does not find a value that matches the condition, return -EINVAL
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
---
sound/soc/codecs/es8389.c | 49 +++++++++++++++++++++------------------
1 file changed, 26 insertions(+), 23 deletions(-)
diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
index 886069be1..647d9d628 100644
--- a/sound/soc/codecs/es8389.c
+++ b/sound/soc/codecs/es8389.c
@@ -434,52 +434,54 @@ static const struct _coeff_div coeff_div[] = {
{36, 576000, 16000, 0x00, 0x55, 0x84, 0xD0, 0x01, 0xC1, 0x90, 0x00, 0x00, 0x23, 0x8F, 0xBF, 0xC0, 0x1F, 0x8F, 0x01, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{48, 768000, 16000, 0x02, 0x57, 0x04, 0xC0, 0x01, 0xC1, 0x90, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{50, 800000, 16000, 0x00, 0x7E, 0x01, 0xD9, 0x00, 0xC2, 0x80, 0x00, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0xC7, 0x95, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
- {64, 1024000, 16000, 0x00, 0x45, 0x24, 0xC0, 0x01, 0xD1, 0x90, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
- {72, 1152000, 16000, 0x00, 0x45, 0x24, 0xC0, 0x01, 0xD1, 0x90, 0x00, 0x00, 0x23, 0x8F, 0xBF, 0xC0, 0x1F, 0x8F, 0x01, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
+ {64, 1024000, 16000, 0x00, 0x45, 0x24, 0xC0, 0x01, 0xC1, 0x90, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
+ {72, 1152000, 16000, 0x00, 0x45, 0x24, 0xC0, 0x01, 0xC1, 0x90, 0x00, 0x00, 0x23, 0x8F, 0xBF, 0xC0, 0x1F, 0x8F, 0x01, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{96, 1536000, 16000, 0x02, 0x55, 0x84, 0xD0, 0x01, 0xC1, 0x90, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{128, 2048000, 16000, 0x00, 0x51, 0x04, 0xD0, 0x01, 0xC1, 0x90, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{144, 2304000, 16000, 0x00, 0x51, 0x00, 0xC0, 0x01, 0xC1, 0x90, 0x00, 0x00, 0x23, 0x8F, 0xBF, 0xC0, 0x1F, 0x8F, 0x01, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
+ {150, 2400000, 16000, 0x02, 0x7E, 0x01, 0xC9, 0x00, 0xC2, 0x80, 0x40, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0xC7, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
{192, 3072000, 16000, 0x02, 0x65, 0x25, 0xE0, 0x00, 0xE1, 0x90, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
- {256, 4096000, 16000, 0x00, 0x41, 0x04, 0xC0, 0x01, 0xD1, 0x90, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
+ {256, 4096000, 16000, 0x00, 0x41, 0x04, 0xC0, 0x01, 0xC1, 0x90, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{300, 4800000, 16000, 0x02, 0x66, 0x01, 0xD9, 0x00, 0xC2, 0x80, 0x00, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0xC7, 0x95, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{384, 6144000, 16000, 0x02, 0x51, 0x04, 0xD0, 0x01, 0xC1, 0x90, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
- {512, 8192000, 16000, 0x01, 0x41, 0x04, 0xC0, 0x01, 0xD1, 0x90, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
+ {512, 8192000, 16000, 0x01, 0x41, 0x04, 0xC0, 0x01, 0xC1, 0x90, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{750, 12000000, 16000, 0x0E, 0x7E, 0x01, 0xC9, 0x00, 0xC2, 0x80, 0x40, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0xC7, 0x95, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
- {768, 12288000, 16000, 0x02, 0x41, 0x04, 0xC0, 0x01, 0xD1, 0x90, 0x40, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
- {1024, 16384000, 16000, 0x03, 0x41, 0x04, 0xC0, 0x01, 0xD1, 0x90, 0x40, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
+ {768, 12288000, 16000, 0x02, 0x41, 0x04, 0xC0, 0x01, 0xC1, 0x90, 0x40, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
+ {1024, 16384000, 16000, 0x03, 0x41, 0x04, 0xC0, 0x01, 0xC1, 0x90, 0x40, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{1152, 18432000, 16000, 0x08, 0x51, 0x04, 0xD0, 0x01, 0xC1, 0x90, 0x40, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{1200, 19200000, 16000, 0x0B, 0x66, 0x01, 0xD9, 0x00, 0xC2, 0x80, 0x40, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0xC7, 0x95, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{1500, 24000000, 16000, 0x0E, 0x26, 0x01, 0xD9, 0x00, 0xC2, 0x80, 0xC0, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0xC7, 0x95, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
- {1536, 24576000, 16000, 0x05, 0x41, 0x04, 0xC0, 0x01, 0xD1, 0x90, 0xC0, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
+ {1536, 24576000, 16000, 0x05, 0x41, 0x04, 0xC0, 0x01, 0xC1, 0x90, 0xC0, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0xFF, 0x7F, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{1625, 26000000, 16000, 0x40, 0x6E, 0x05, 0xC8, 0x01, 0xC2, 0x90, 0xC0, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x12, 0x31, 0x0E, 2, 2},
{800, 19200000, 24000, 0x07, 0x66, 0x01, 0xD9, 0x00, 0xC2, 0x80, 0x40, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0xC7, 0x95, 0x00, 0x12, 0x00, 0x1A, 0x49, 0x14, 2, 2},
{375, 12000000, 32000, 0x0E, 0x2E, 0x05, 0xC8, 0x00, 0xC2, 0x80, 0x40, 0x01, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x23, 0x61, 0x1B, 2, 0},
- {600, 19200000, 32000, 0x05, 0x46, 0x01, 0xD8, 0x10, 0xD2, 0x80, 0x40, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x23, 0x61, 0x1B, 2, 2},
- {32, 1411200, 44100, 0x00, 0x45, 0xA4, 0xD0, 0x10, 0xD1, 0x80, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {600, 19200000, 32000, 0x05, 0x46, 0x01, 0xD8, 0x10, 0xC2, 0x80, 0x40, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x23, 0x61, 0x1B, 2, 2},
+ {32, 1411200, 44100, 0x00, 0x45, 0xA4, 0xD0, 0x10, 0xC1, 0x80, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
{64, 2822400, 44100, 0x00, 0x51, 0x00, 0xC0, 0x10, 0xC1, 0x80, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {128, 5644800, 44100, 0x00, 0x41, 0x04, 0xD0, 0x10, 0xD1, 0x80, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {256, 11289600, 44100, 0x01, 0x41, 0x04, 0xD0, 0x10, 0xD1, 0x80, 0x40, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {512, 22579200, 44100, 0x03, 0x41, 0x04, 0xD0, 0x10, 0xD1, 0x80, 0xC0, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {32, 1536000, 48000, 0x00, 0x45, 0xA4, 0xD0, 0x10, 0xD1, 0x80, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {128, 5644800, 44100, 0x00, 0x41, 0x04, 0xD0, 0x10, 0xC1, 0x80, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {256, 11289600, 44100, 0x01, 0x41, 0x04, 0xD0, 0x10, 0xC1, 0x80, 0x40, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {512, 22579200, 44100, 0x03, 0x41, 0x04, 0xD0, 0x10, 0xC1, 0x80, 0xC0, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {32, 1536000, 48000, 0x00, 0x45, 0xA4, 0xD0, 0x10, 0xC1, 0x80, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
{48, 2304000, 48000, 0x02, 0x55, 0x04, 0xC0, 0x10, 0xC1, 0x80, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
{50, 2400000, 48000, 0x00, 0x76, 0x01, 0xC8, 0x10, 0xC2, 0x80, 0x00, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
{64, 3072000, 48000, 0x00, 0x51, 0x04, 0xC0, 0x10, 0xC1, 0x80, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {100, 4800000, 48000, 0x00, 0x46, 0x01, 0xD8, 0x10, 0xD2, 0x80, 0x00, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {100, 4800000, 48000, 0x00, 0x46, 0x01, 0xD8, 0x10, 0xC2, 0x80, 0x00, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
{125, 6000000, 48000, 0x04, 0x6E, 0x05, 0xC8, 0x10, 0xC2, 0x80, 0x00, 0x01, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {128, 6144000, 48000, 0x00, 0x41, 0x04, 0xD0, 0x10, 0xD1, 0x80, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {200, 9600000, 48000, 0x01, 0x46, 0x01, 0xD8, 0x10, 0xD2, 0x80, 0x00, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {128, 6144000, 48000, 0x00, 0x41, 0x04, 0xD0, 0x10, 0xC1, 0x80, 0x00, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {200, 9600000, 48000, 0x01, 0x46, 0x01, 0xD8, 0x10, 0xC2, 0x80, 0x00, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
{250, 12000000, 48000, 0x04, 0x76, 0x01, 0xC8, 0x10, 0xC2, 0x80, 0x40, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {256, 12288000, 48000, 0x01, 0x41, 0x04, 0xD0, 0x10, 0xD1, 0x80, 0x40, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {384, 18432000, 48000, 0x02, 0x41, 0x04, 0xD0, 0x10, 0xD1, 0x80, 0x40, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {400, 19200000, 48000, 0x03, 0x46, 0x01, 0xD8, 0x10, 0xD2, 0x80, 0x40, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {500, 24000000, 48000, 0x04, 0x46, 0x01, 0xD8, 0x10, 0xD2, 0x80, 0xC0, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
- {512, 24576000, 48000, 0x03, 0x41, 0x04, 0xD0, 0x10, 0xD1, 0x80, 0xC0, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {256, 12288000, 48000, 0x01, 0x41, 0x04, 0xD0, 0x10, 0xC1, 0x80, 0x40, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {384, 18432000, 48000, 0x02, 0x41, 0x04, 0xD0, 0x10, 0xC1, 0x80, 0x40, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {400, 19200000, 48000, 0x03, 0x46, 0x01, 0xD8, 0x10, 0xC2, 0x80, 0x40, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {500, 24000000, 48000, 0x04, 0x46, 0x01, 0xD8, 0x10, 0xC2, 0x80, 0xC0, 0x00, 0x18, 0x95, 0xD0, 0xC0, 0x63, 0x95, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
+ {512, 24576000, 48000, 0x03, 0x41, 0x04, 0xD0, 0x10, 0xC1, 0x80, 0xC0, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
{800, 38400000, 48000, 0x18, 0x45, 0x04, 0xC0, 0x10, 0xC1, 0x80, 0xC0, 0x00, 0x1F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x00, 0x12, 0x00, 0x35, 0x91, 0x28, 2, 2},
{128, 11289600, 88200, 0x00, 0x50, 0x00, 0xC0, 0x10, 0xC1, 0x80, 0x40, 0x00, 0x9F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x80, 0x12, 0xC0, 0x32, 0x89, 0x25, 2, 2},
- {64, 6144000, 96000, 0x00, 0x41, 0x00, 0xD0, 0x10, 0xD1, 0x80, 0x00, 0x00, 0x9F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x80, 0x12, 0xC0, 0x35, 0x91, 0x28, 2, 2},
+ {64, 6144000, 96000, 0x00, 0x41, 0x00, 0xD0, 0x10, 0xC1, 0x80, 0x00, 0x00, 0x9F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x80, 0x12, 0xC0, 0x35, 0x91, 0x28, 2, 2},
{96, 9216000, 96000, 0x02, 0x43, 0x00, 0xC0, 0x10, 0xC0, 0x80, 0x00, 0x00, 0x9F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x80, 0x12, 0xC0, 0x35, 0x91, 0x28, 2, 2},
{256, 24576000, 96000, 0x00, 0x40, 0x00, 0xC0, 0x10, 0xC1, 0x80, 0xC0, 0x00, 0x9F, 0x7F, 0xBF, 0xC0, 0x7F, 0x7F, 0x80, 0x12, 0xC0, 0x35, 0x91, 0x28, 2, 2},
{128, 24576000, 192000, 0x00, 0x50, 0x00, 0xC0, 0x18, 0xC1, 0x81, 0xC0, 0x00, 0x8F, 0x7F, 0xBF, 0xC0, 0x3F, 0x7F, 0x80, 0x12, 0xC0, 0x3F, 0xF9, 0x3F, 2, 2},
+ {64, 12288000, 192000, 0x00, 0x41, 0x00, 0xC0, 0x18, 0xC1, 0x80, 0x00, 0x00, 0x8F, 0x7F, 0xEF, 0xC0, 0x7F, 0x7F, 0x80, 0x12, 0xC0, 0x3F, 0xF9, 0x3F, 1, 0},
};
static inline int get_coeff(u8 vddd, u8 dmic, int mclk, int rate)
@@ -657,7 +659,8 @@ static int es8389_pcm_hw_params(struct snd_pcm_substream *substream,
regmap_write(es8389->regmap, ES8389_SYSTEM18, coeff_div[coeff].Reg0x18);
regmap_write(es8389->regmap, ES8389_SYSTEM19, coeff_div[coeff].Reg0x19);
} else {
- dev_warn(component->dev, "Clock coefficients do not match");
+ dev_err(component->dev, "Clock coefficients do not match");
+ return -EINVAL;
}
return 0;
--
2.17.1
^ permalink raw reply related
* [PATCH v1 2/7] ASoC: codecs: ES8389: Modify volatile_register
From: Zhang Yi @ 2026-06-11 3:18 UTC (permalink / raw)
To: linux-sound, broonie, devicetree; +Cc: tiwai, robh, krzk+dt, conor+dt, Zhang Yi
In-Reply-To: <20260611031824.4628-1-zhangyi@everest-semi.com>
Mark some registers that are not volatile as false
And modified the logic for `cache_bypass` during `8389_resume`.
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
---
sound/soc/codecs/es8389.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
index 449d9574b..be7a36f17 100644
--- a/sound/soc/codecs/es8389.c
+++ b/sound/soc/codecs/es8389.c
@@ -50,10 +50,29 @@ static const char * const es8389_core_supplies[] = {
static bool es8389_volatile_register(struct device *dev,
unsigned int reg)
{
- if ((reg <= 0xff))
- return true;
- else
+ switch (reg) {
+ case ES8389_ADCL_VOL:
+ case ES8389_ADCR_VOL:
+ case ES8389_MIC1_GAIN:
+ case ES8389_MIC2_GAIN:
+ case ES8389_DACL_VOL:
+ case ES8389_DACR_VOL:
+ case ES8389_ALC_ON:
+ case ES8389_ALC_CTL:
+ case ES8389_ALC_TARGET:
+ case ES8389_ALC_GAIN:
+ case ES8389_ADC_MUTE:
+ case ES8389_OSR_VOL:
+ case ES8389_DAC_INV:
+ case ES8389_MIX_VOL:
+ case ES8389_DAC_MIX:
+ case ES8389_ADC_RESET:
+ case ES8389_ADC_MODE:
+ case ES8389_DMIC_EN:
return false;
+ default:
+ return true;
+ }
}
static const DECLARE_TLV_DB_SCALE(dac_vol_tlv, -9550, 50, 0);
@@ -861,13 +880,13 @@ static int es8389_resume(struct snd_soc_component *component)
regcache_cache_only(es8389->regmap, false);
regcache_cache_bypass(es8389->regmap, true);
regmap_read(es8389->regmap, ES8389_RESET, ®v);
- regcache_cache_bypass(es8389->regmap, false);
if (regv == 0xff)
es8389_init(component);
else
es8389_set_bias_level(component, SND_SOC_BIAS_ON);
+ regcache_cache_bypass(es8389->regmap, false);
regcache_sync(es8389->regmap);
return 0;
--
2.17.1
^ permalink raw reply related
* [PATCH v1 3/7] ASoC: codecs: ES8389: Fix the issue about mclk_src
From: Zhang Yi @ 2026-06-11 3:18 UTC (permalink / raw)
To: linux-sound, broonie, devicetree; +Cc: tiwai, robh, krzk+dt, conor+dt, Zhang Yi
In-Reply-To: <20260611031824.4628-1-zhangyi@everest-semi.com>
Fix the issue with incorrect modifications to mclk_src
When the system needs to be configured to use the MCLK from the SCLK pin,
the code still sets the relevant registers to use the MCLK from the MCLK pin
And setting `mclk_src` to `u8` is inappropriate,
because the purpose of `mclk_src` is to determine whether to use SCLK as MCLK.
Therefore, we will change the `mclk_src` member from `u8` to `bool`.
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
---
sound/soc/codecs/es8389.c | 12 ++++--------
sound/soc/codecs/es8389.h | 5 ++---
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
index be7a36f17..886069be1 100644
--- a/sound/soc/codecs/es8389.c
+++ b/sound/soc/codecs/es8389.c
@@ -36,8 +36,8 @@ struct es8389_private {
unsigned int sysclk;
int mastermode;
- u8 mclk_src;
u8 vddd;
+ bool mclk_src;
int version;
enum snd_soc_bias_level bias_level;
};
@@ -607,9 +607,9 @@ static int es8389_pcm_hw_params(struct snd_pcm_substream *substream,
regmap_update_bits(es8389->regmap, ES8389_ADC_FORMAT_MUTE, ES8389_DATA_LEN_MASK, state);
regmap_update_bits(es8389->regmap, ES8389_DAC_FORMAT_MUTE, ES8389_DATA_LEN_MASK, state);
- if (es8389->mclk_src == ES8389_SCLK_PIN) {
+ if (es8389->mclk_src) {
regmap_update_bits(es8389->regmap, ES8389_MASTER_CLK,
- ES8389_MCLK_SOURCE, es8389->mclk_src);
+ ES8389_MCLK_MASK, ES8389_MCLK_FROM_SCLK);
es8389->sysclk = params_channels(params) * params_width(params) * params_rate(params);
}
@@ -897,11 +897,7 @@ static int es8389_probe(struct snd_soc_component *component)
int ret, i;
struct es8389_private *es8389 = snd_soc_component_get_drvdata(component);
- ret = device_property_read_u8(component->dev, "everest,mclk-src", &es8389->mclk_src);
- if (ret != 0) {
- dev_dbg(component->dev, "mclk-src return %d", ret);
- es8389->mclk_src = ES8389_MCLK_SOURCE;
- }
+ es8389->mclk_src = device_property_read_bool(component->dev, "everest,mclk-from-sclk");
for (i = 0; i < ARRAY_SIZE(es8389_core_supplies); i++)
es8389->core_supply[i].supply = es8389_core_supplies[i];
diff --git a/sound/soc/codecs/es8389.h b/sound/soc/codecs/es8389.h
index d21e72f87..7f1212219 100644
--- a/sound/soc/codecs/es8389.h
+++ b/sound/soc/codecs/es8389.h
@@ -116,9 +116,8 @@
#define ES8389_TDM_SLOT (0x70 << 0)
#define ES8389_TDM_SHIFT 4
-#define ES8389_MCLK_SOURCE (1 << 6)
-#define ES8389_MCLK_PIN (1 << 6)
-#define ES8389_SCLK_PIN (0 << 6)
+#define ES8389_MCLK_MASK (3 << 6)
+#define ES8389_MCLK_FROM_SCLK (1 << 6)
/* ES8389_FMT */
#define ES8389_S24_LE (0 << 5)
--
2.17.1
^ permalink raw reply related
* [PATCH v1 5/7] ASoC: codecs: ES8389: Modify the initial configuration
From: Zhang Yi @ 2026-06-11 3:18 UTC (permalink / raw)
To: linux-sound, broonie, devicetree; +Cc: tiwai, robh, krzk+dt, conor+dt, Zhang Yi
In-Reply-To: <20260611031824.4628-1-zhangyi@everest-semi.com>
Modify the initial configuration
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
---
sound/soc/codecs/es8389.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
index 647d9d628..284eb707f 100644
--- a/sound/soc/codecs/es8389.c
+++ b/sound/soc/codecs/es8389.c
@@ -793,7 +793,7 @@ static void es8389_init(struct snd_soc_component *component)
regmap_read(es8389->regmap, ES8389_MAX_REGISTER, ®);
es8389->version = reg;
- regmap_write(es8389->regmap, ES8389_ISO_CTL, 0x00);
+ regmap_write(es8389->regmap, ES8389_ISO_CTL, 0x56);
regmap_write(es8389->regmap, ES8389_RESET, 0x7E);
regmap_write(es8389->regmap, ES8389_ISO_CTL, 0x38);
regmap_write(es8389->regmap, ES8389_ADC_HPF1, 0x64);
@@ -845,7 +845,7 @@ static void es8389_init(struct snd_soc_component *component)
regmap_write(es8389->regmap, ES8389_SCLK_DIV, 0x04);
regmap_write(es8389->regmap, ES8389_LRCK_DIV1, 0x01);
regmap_write(es8389->regmap, ES8389_LRCK_DIV2, 0x00);
- regmap_write(es8389->regmap, ES8389_OSC_CLK, 0x00);
+ regmap_write(es8389->regmap, ES8389_OSC_CLK, 0x10);
regmap_write(es8389->regmap, ES8389_ADC_OSR, 0x1F);
regmap_write(es8389->regmap, ES8389_ADC_DSP, 0x7F);
regmap_write(es8389->regmap, ES8389_ADC_MUTE, 0xC0);
--
2.17.1
^ permalink raw reply related
* [PATCH v1 0/7] ASoC: codecs: ES8389: Modify the ES8389 driver
From: Zhang Yi @ 2026-06-11 3:18 UTC (permalink / raw)
To: linux-sound, broonie, devicetree; +Cc: tiwai, robh, krzk+dt, conor+dt, Zhang Yi
Modify the initialization configuration and routes for ES8389,
and add private members.
Describe the added private members in `devicetree/bindings`
v1 -> v0:
-The binding patch has been placed before the corresponding code patch
-Provide a more detailed description of the binding patch
-Provide a more detailed description of the patch about HPF
Zhang Yi (7):
ASoC: dt-bindings: ES8389: Add members about HPF and clock
ASoC: codecs: ES8389: Modify volatile_register
ASoC: codecs: ES8389: Fix the issue about mclk_src
ASoC: codecs: ES8389: Modify the clock table
ASoC: codecs: ES8389: Modify the initial configuration
ASoC: codecs: ES8389: Add private members related to HPF
ASoC: codecs: ES8389: Add INPUTL MUX and INPUTR MUX
.../bindings/sound/everest,es8389.yaml | 23 +++
sound/soc/codecs/es8389.c | 141 +++++++++++++-----
sound/soc/codecs/es8389.h | 6 +-
3 files changed, 128 insertions(+), 42 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH v1 1/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: Zhang Yi @ 2026-06-11 3:18 UTC (permalink / raw)
To: linux-sound, broonie, devicetree; +Cc: tiwai, robh, krzk+dt, conor+dt, Zhang Yi
In-Reply-To: <20260611031824.4628-1-zhangyi@everest-semi.com>
Add members related to HPF and mclk_source
The value of HPF is not dB, it is just the value of registers
And add HPF settings to the example
Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
---
.../bindings/sound/everest,es8389.yaml | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/everest,es8389.yaml b/Documentation/devicetree/bindings/sound/everest,es8389.yaml
index 75ce0bc48..be92014c0 100644
--- a/Documentation/devicetree/bindings/sound/everest,es8389.yaml
+++ b/Documentation/devicetree/bindings/sound/everest,es8389.yaml
@@ -38,6 +38,27 @@ properties:
description:
Interface power supply.
+ everest,mclk-from-sclk:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Indicates that SCLK is used as the internal clock.
+
+ everest,hpfl:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description:
+ the HPF value of ADCL.
+ minimum: 0x00
+ maximum: 0x0f
+ default: 0x0a
+
+ everest,hpfr:
+ $ref: /schemas/types.yaml#/definitions/uint8
+ description:
+ the HPF value of ADCR.
+ minimum: 0x00
+ maximum: 0x0f
+ default: 0x0a
+
required:
- compatible
- reg
@@ -58,5 +79,7 @@ examples:
#sound-dai-cells = <0>;
vddd-supply = <&vdd3v3>;
vdda-supply = <&vdd3v3>;
+ everest,hpfl = [0a];
+ everest,hpfr = [0a];
};
};
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v6 5/6] remoteproc: qcom: pas: Add late attach support for subsystems
From: Aiqun(Maria) Yu @ 2026-06-11 3:10 UTC (permalink / raw)
To: Stephan Gerhold, Jingyi Wang
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Luca Weiss, Bartosz Golaszewski, Konrad Dybcio, shengchao.guo,
tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel,
Gokul Krishna Krishnakumar
In-Reply-To: <ahBG6jKYdSAboWjs@linaro.org>
On 5/22/2026 8:07 PM, Stephan Gerhold wrote:
> On Tue, May 19, 2026 at 12:24:23AM -0700, Jingyi Wang wrote:
>> Subsystems can be brought out of reset by entities such as bootloaders.
>> As the irq enablement could be later than subsystem bring up, the state
>> of subsystem should be checked by reading SMP2P bits.
>>
>> A new qcom_pas_attach() function is introduced. if a crash state is
>> detected for the subsystem, rproc_report_crash() is called. If the ready
>> state is detected, it will be marked as "attached", otherwise it could
>> be the early boot feature is not supported by other entities. In this
>> case, the state will be marked as RPROC_OFFLINE so that the PAS driver
>> can load the firmware and start the remoteproc.
>>
>> Co-developed-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
>> Signed-off-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>
> Unfortunately, removing the ping-pong functionality that was present in
> previous patch versions makes the whole mechanism a lot more fragile.
> I'm not entirely sure if this has changed in SMP2P v2 or more recent
> firmware versions, but in my experience the SMP2P "ready" bit does not
> tell you if the remoteproc is actually running. The problem is that the
> "ready" bit is asserted by the remoteproc when the firmware is ready,
> but it is not cleared when you shutdown or forcibly stop the remoteproc.
>
> If this is still the case, you can easily reproduce that with the
> following test:
>
> 1. Start the system as usual and let it attach the remoteproc
> 2. Manually stop the remoteproc in sysfs (echo stop > state)
> 3. modprobe -r qcom_q6v5_pas
> 4. modprobe qcom_q6v5_pas
> 5. If the "ready" bit is still set, the driver will try attaching the
> remoteproc, but it's actually not running. No recovery will happen.
>
> In this situation, it is very difficult to detect the correct remoteproc
> state without relying on an additional query mechanism like the
> ping-pong feature.
This a valid use case and concern. We had a discussion with Bjorn, and
want to take this scenario into consideration of the separate robustness
improvement series[1].
Stephan could you agree to have the basic function in this series can be
go in firstly.
[1]
https://lore.kernel.org/all/20260519-rproc-attach-issue-v2-0-caa1eaf75081@oss.qualcomm.com/
>
> You can make it a bit more reliable if you also check the status of the
> "stop-ack" bit. This would tell you if the remoteproc was cleanly
> stopped with the SMP2P "stop" mechanism. However, that will typically
> still not fix the case above since nowadays remoteprocs are typically
> stopped via the QMI qcom_sysmon and the "stop-ack" is not set in that
> case. I believe this might set the separate "shutdown-ack" bit though
> that is described for some SoCs, I never finished testing that.
>
> And even if you check both "stop-ack" and "shutdown-ack", that doesn't
> tell you if the remoteproc was forcibly killed using
> qcom_scm_pas_shutdown() without gracefully stopping it first. The ideal
> solution would be querying the PAS API to tell us if the remoteproc is
> actively running, but the last time I checked I was unfortunately not
> able to find a documented call that would tell us that.
It is a state currently kernel don't know whether the remoteproc is
offline or crashed when ready==1 && error==0 && ping-pong==0 scenario.
If it is re-modprob, the software don't have any data and only the
firmware can tell us whether if it is active or not per my understanding.
Maybe let's have this scenario and solution discussion in the other
series I mentioned before.
>
> Thanks,
> Stephan
--
Thx and BRs,
Aiqun(Maria) Yu
^ permalink raw reply
* Re: [PATCH v3 00/11] kdump: reduce vmcore size and capture time
From: Wandun @ 2026-06-11 3:09 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, Rob Herring, saravanak,
bhe, rppt, pjw, palmer, aou, chenhuacai, kernel
Cc: catalin.marinas, will, alex, akpm, pasha.tatashin, pratyush,
ruirui.yang, m.szyprowski, robin.murphy
In-Reply-To: <7ed207fa-4c86-426a-8570-495902ce04c3@gmail.com>
On 6/11/26 10:09, Wandun wrote:
>
>
> On 5/27/26 11:29, Wandun Chen wrote:
>> From: Wandun Chen <chenwandun@lixiang.com>
>>
>> On SoCs that carve out large firmware-owned reserved memory (GPU
>> firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps
>> those carveouts as part of system RAM even though their contents are
>> firmware state that is not useful for kernel crash analysis.
>>
>> This series introduces an opt-in 'dumpable' flag [1] on struct
>> reserved_mem and uses it to filter the elfcorehdr PT_LOAD ranges on
>> DT-based architectures (arm64, riscv, loongarch). By default reserved
>> regions are treated as non-dumpable; CMA regions are explicitly opted
>> in because their pages are returned to the buddy allocator and may
>> carry key crash-analysis data.
>>
>> The series is organized as follows:
>> Patches 1-3: Pre-existing fixes and a small prep change.
>> Patches 4-5: Restructure to allow appending /memreserve/ entries.
>> Patches 6-7: Add a dumpable flag and append /memreserve/ entries.
>> Patch 8: Add generic kdump helpers.
>> Patches 9-11: Wire the helpers into arm64, riscv and loongarch kdump
>> elfcorehdr preparation.
> Hi,
>
> Gentle ping on this series.
>
> Status summary:
> -patch 03: respun separately per Rob's suggestion, picked up for 7.2
> -patch 06: Acked-by: Marek Szyprowski -patch 09: Acked-by: Will Deacon
> The remaining patches (01, 02, 04, 05, 07, 08, 10, 11) are still
> awaiting review. your feedback would be greately appreciated. I know we
> are at the end of 7.1 -rc cycle, I don't want to rush this series, just
> collecting more feedback, and will send next version based on 7.2-rc1.
> If spliting the series into smaller logical group would make review
> easier, please let me know. Best regards, Wandun
Apologies for the formatting issue in my previous email.
Here is the properly formatted version.
Gentle ping on this series.
Status summary:
- patch 03: respun separately per Rob's suggestion, picked up for 7.2
- patch 06: Acked-by: Marek Szyprowski
- patch 09: Acked-by: Will Deacon
The remaining patches (01, 02, 04, 05, 07, 08, 10, 11) are still
awaiting review. Your feedback would be greatly appreciated.
I know we are at the end of 7.1-rc cycle, I don't want to rush this
series, just collecting more feedback, and will send next version based
on 7.2-rc1.
If splitting the series into smaller logical groups would make review
easier, please let me know.
Best regards,
Wandun
>>
>> v2 --> v3:
>> 1. Fix out-of-bounds issue if device tree lacks /reserved-memory node.[2]
>> 2. Fix UAF issue when alloc_reserved_mem_array() fails.
>> 3. Add some prepare patches.
>>
>> v1 --> v2:
>> 1. v1 added an opt-out DT property ('linux,no-dump'). Per Rob's
>> feedback [1], v2 drop that property and exclude reserve memory
>> by default.
>> 2. Split some prepared patches from the original patches.
>> 3. Address coding-style comments on patch 5 from Rob.
>>
>> [1] https://lore.kernel.org/lkml/20260506144542.GA2072596-
>> robh@kernel.org/
>> [2] https://sashiko.dev/#/patchset/20260520091844.592753-1-
>> chenwandun%40lixiang.com?part=4
>>
>> Wandun Chen (11):
>> of: reserved_mem: handle NULL name in of_reserved_mem_lookup()
>> kexec/crash: provide crash_exclude_mem_range() stub when
>> CONFIG_CRASH_DUMP=n
>> of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()
>> fails
>> of: reserved_mem: zero total_reserved_mem_cnt if no valid
>> /reserved-memory entry
>> of: reserved_mem: split alloc_reserved_mem_array() from
>> fdt_scan_reserved_mem_late()
>> of: reserved_mem: add dumpable flag to opt-in vmcore
>> of: reserved_mem: save /memreserve/ entries into the reserved_mem
>> array
>> of: reserved_mem: add kdump helpers to exclude non-dumpable regions
>> arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
>> riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
>> loongarch: kdump: exclude non-dumpable reserved memory regions from
>> vmcore
>>
>> arch/arm64/kernel/machine_kexec_file.c | 6 ++
>> arch/loongarch/kernel/machine_kexec_file.c | 6 ++
>> arch/riscv/kernel/machine_kexec_file.c | 4 +
>> drivers/of/fdt.c | 11 +-
>> drivers/of/of_private.h | 3 +
>> drivers/of/of_reserved_mem.c | 117 +++++++++++++++++++--
>> include/linux/crash_core.h | 6 ++
>> include/linux/of_reserved_mem.h | 15 +++
>> kernel/dma/contiguous.c | 1 +
>> 9 files changed, 157 insertions(+), 12 deletions(-)
>>
>
^ permalink raw reply
* Re: [PATCH v3 00/11] kdump: reduce vmcore size and capture time
From: Wandun @ 2026-06-11 2:09 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, Rob Herring, saravanak,
bhe, rppt, pjw, palmer, aou, chenhuacai, kernel
Cc: catalin.marinas, will, alex, akpm, pasha.tatashin, pratyush,
ruirui.yang, m.szyprowski, robin.murphy
In-Reply-To: <20260527032917.3385849-1-chenwandun1@gmail.com>
On 5/27/26 11:29, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> On SoCs that carve out large firmware-owned reserved memory (GPU
> firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps
> those carveouts as part of system RAM even though their contents are
> firmware state that is not useful for kernel crash analysis.
>
> This series introduces an opt-in 'dumpable' flag [1] on struct
> reserved_mem and uses it to filter the elfcorehdr PT_LOAD ranges on
> DT-based architectures (arm64, riscv, loongarch). By default reserved
> regions are treated as non-dumpable; CMA regions are explicitly opted
> in because their pages are returned to the buddy allocator and may
> carry key crash-analysis data.
>
> The series is organized as follows:
> Patches 1-3: Pre-existing fixes and a small prep change.
> Patches 4-5: Restructure to allow appending /memreserve/ entries.
> Patches 6-7: Add a dumpable flag and append /memreserve/ entries.
> Patch 8: Add generic kdump helpers.
> Patches 9-11: Wire the helpers into arm64, riscv and loongarch kdump
> elfcorehdr preparation.
Hi,
Gentle ping on this series.
Status summary:
-patch 03: respun separately per Rob's suggestion, picked up for 7.2
-patch 06: Acked-by: Marek Szyprowski -patch 09: Acked-by: Will Deacon
The remaining patches (01, 02, 04, 05, 07, 08, 10, 11) are still
awaiting review. your feedback would be greately appreciated. I know we
are at the end of 7.1 -rc cycle, I don't want to rush this series, just
collecting more feedback, and will send next version based on 7.2-rc1.
If spliting the series into smaller logical group would make review
easier, please let me know. Best regards, Wandun
>
> v2 --> v3:
> 1. Fix out-of-bounds issue if device tree lacks /reserved-memory node.[2]
> 2. Fix UAF issue when alloc_reserved_mem_array() fails.
> 3. Add some prepare patches.
>
> v1 --> v2:
> 1. v1 added an opt-out DT property ('linux,no-dump'). Per Rob's
> feedback [1], v2 drop that property and exclude reserve memory
> by default.
> 2. Split some prepared patches from the original patches.
> 3. Address coding-style comments on patch 5 from Rob.
>
> [1] https://lore.kernel.org/lkml/20260506144542.GA2072596-robh@kernel.org/
> [2] https://sashiko.dev/#/patchset/20260520091844.592753-1-chenwandun%40lixiang.com?part=4
>
> Wandun Chen (11):
> of: reserved_mem: handle NULL name in of_reserved_mem_lookup()
> kexec/crash: provide crash_exclude_mem_range() stub when
> CONFIG_CRASH_DUMP=n
> of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()
> fails
> of: reserved_mem: zero total_reserved_mem_cnt if no valid
> /reserved-memory entry
> of: reserved_mem: split alloc_reserved_mem_array() from
> fdt_scan_reserved_mem_late()
> of: reserved_mem: add dumpable flag to opt-in vmcore
> of: reserved_mem: save /memreserve/ entries into the reserved_mem
> array
> of: reserved_mem: add kdump helpers to exclude non-dumpable regions
> arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
> riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
> loongarch: kdump: exclude non-dumpable reserved memory regions from
> vmcore
>
> arch/arm64/kernel/machine_kexec_file.c | 6 ++
> arch/loongarch/kernel/machine_kexec_file.c | 6 ++
> arch/riscv/kernel/machine_kexec_file.c | 4 +
> drivers/of/fdt.c | 11 +-
> drivers/of/of_private.h | 3 +
> drivers/of/of_reserved_mem.c | 117 +++++++++++++++++++--
> include/linux/crash_core.h | 6 ++
> include/linux/of_reserved_mem.h | 15 +++
> kernel/dma/contiguous.c | 1 +
> 9 files changed, 157 insertions(+), 12 deletions(-)
>
^ permalink raw reply
* RE: [PATCH v9 3/4] arm64: dts: aspeed: Add initial AST27xx SoC device tree
From: Ryan Chen @ 2026-06-11 1:48 UTC (permalink / raw)
To: Andrew Jeffery, sashiko-reviews@lists.linux.dev
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
In-Reply-To: <45e1df1ad72eb982ddb13500b9224bf54b6f3fa2.camel@codeconstruct.com.au>
> Subject: Re: [PATCH v9 3/4] arm64: dts: aspeed: Add initial AST27xx SoC device
> tree
>
> Hi Ryan,
>
> On Tue, 2026-06-09 at 05:36 +0000, Ryan Chen wrote:
> > > Subject: Re: [PATCH v9 3/4] arm64: dts: aspeed: Add initial AST27xx
> > > SoC device tree
> > >
> > > Thank you for your contribution! Sashiko AI review found 3 potential
> > > issue(s) to
> > > consider:
> > > - [High] INTC1 maps its summary interrupts to INTC0's TSP routing
> > > range, preventing SOC1 interrupts from reaching the Cortex-A35 GIC.
> > > - [Low] The device tree defines ad-hoc top-level nodes ('secondary',
> > > 'tertiary',
> > > 'bootmcu') that violate standard naming schemas, and embeds direct
> > > Linux kernel source URLs to justify '#size-cells' behavior.
> > > - [Low] Duplicate label definitions in the pinctrl device tree
> > > include for multiple pinctrl groups in SOC1 will cause a hard DTC build
> failure.
> > > --
> > >
> > > commit 92031db9a3c255cefbfcc33df4ca0cb9780dd226
> > > Author: Ryan Chen <ryan_chen@aspeedtech.com>
> > >
> > > arm64: dts: aspeed: Add initial AST27xx SoC device tree
> > >
> > > Add initial device tree support for the ASPEED AST27xx family, the
> > > 8th-generation Baseboard Management Controller (BMC) SoCs.
> > >
> > > > diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> > > > b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> > > > new file mode 100644
> > > > index 0000000000000..ef283d95649a3
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> > > [ ... ]
> > > > @@ -82,10 +82,10 @@ l2: l2-cache0 {
> > > > };
> > > >
> > > > secondary {
> > > > #address-cells = <2>;
> > > > /*
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t
> > > ree/drivers/
> > > of/address.c?h=v6.16#n491 */
> > > > #size-cells = <0>;
> > > > /*
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > > > /tre
> > > > e/drivers/of/address.c?h=v6.16#n430 */
> > > >
> > >
> > > [Severity: Low]
> > > Are these OS-specific comments and ad-hoc root nodes ('secondary',
> > > 'tertiary',
> > > 'bootmcu') appropriate here?
> > >
> > > Device trees typically provide an OS-agnostic hardware description
> > > using generic nodes (like 'bus', 'soc', or 'remoteproc'). Embedding
> > > Linux kernel source URLs suggests the hardware is being modeled
> > > around a specific Linux parser implementation rather than providing
> > > an independent hardware description.
> >
> > The concern is valid and acknowledged. The sub-processor interrupt
> > controllers (ssp_nvic for SSP/Cortex-M4, tsp_nvic for TSP/Cortex-M4,
> > bootmcu_hlic for BootMCU/RISC-V) cannot be placed under the soc1 bus
> > because their registers reside in each sub-processor's private address
> > space and are not accessible from the Cortex-A35 cores.
> >
> > The 2-cell address scheme (#address-cells = <2>, #size-cells = <0>)
> > encodes a <cpu-index reg-base> tuple as suggested by Matt Johnston [1].
>
> That was me, not Matt.
>
> Further, that two cell scheme was part of a tentative sketch for discussion from
> quite some time ago and wasn't intended to be copy/pasted without further
> thought. We should remove the index now.
I will replace by following
secondary {
#address-cells = <1>;
#size-cells = <0>;
ssp_nvic: interrupt-controller@e000e100 {
compatible = "arm,v7m-nvic";
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-controller;
reg = <0xe000e100>;
arm,num-irq-priority-bits = <3>;
status = "disabled";
};
};
tertiary {
#address-cells = <1>;
#size-cells = <0>;
tsp_nvic: interrupt-controller@e000e100 {
compatible = "arm,v7m-nvic";
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-controller;
reg = <0xe000e100>;
arm,num-irq-priority-bits = <3>;
status = "disabled";
};
};
>
> > The Linux kernel source URLs in the comments are admittedly
> > Linux-specific and will be removed in v11; the cover letter explains
> > the rationale instead.
> >
> > All sub-processor nodes carry status = "disabled". They are present
> > solely to provide phandle references for the aspeed,interrupt-ranges
> > properties in intc0 and intc1, which the interrupt controller drivers
> > use to build the interrupt domain hierarchy at boot time.
> >
> > [1]
> > https://lore.kernel.org/all/1a2ca78746e00c2ec4bfc2953a897c48376ed36f.c
> > amel@codeconstruct.com.au/
> >
> > >
> > > > ssp_nvic: interrupt-controller@1,e000e100 {
> > > [ ... ]
> > > > diff --git
> > > > a/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
> > > > b/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
> > > > new file mode 100644
> > > > index 0000000000000..72d93323593d5
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
> > > [ ... ]
> > > > @@ -475,10 +475,10 @@ pinctrl_hvi3c15_default: hvi3c15-default-state
> {
> > > > function = "I3C15";
> > > > groups = "HVI3C15";
> > > > };
> > > >
> > > > pinctrl_tach0_default: tach0-default-state {
> > > > function = "TACH0";
> > > > groups = "TACH0";
> > > > };
> > > >
> > >
> > > [Severity: Low]
> > > Is this label duplicated? There is another pinctrl_tach0_default
> > > definition earlier in this file.
> > >
> > > Defining the same pinctrl label multiple times (such as
> > > pinctrl_tach0_default through pinctrl_tach15_default, and
> > > pinctrl_ncts5_default) in the same device tree will cause a fatal syntax
> error in the Device Tree Compiler.
> >
> > Will fixed in v11. The labels pinctrl_tach0_default through
> > pinctrl_tach15_default were duplicated in aspeed-g7-soc1-pinctrl.dtsi
> > due to a copy-paste error. The second block has been removed.
>
> Please send me fixes for these, and avoid sending patches under review to
> soc@ in the future:
Yes. I follow.
Thanks the instruction.
>
> > Note that the soc@kernel.org is usually not the place to discuss the
> > patches, thus work sent to this address should be already considered
> > as acceptable by the community.
>
> https://docs.kernel.org/process/maintainer-soc.html#submitting-patches-to-th
> e-main-soc-maintainers
>
> Andrew
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] Add compatible strings for RPM and mailbox devices for Shikra
From: Bjorn Andersson @ 2026-06-11 1:47 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Gross, Mathieu Poirier, Stephan Gerhold, Jassi Brar,
Sneh Mankad
Cc: linux-arm-msm, devicetree, linux-kernel, linux-remoteproc,
Komal Bajaj
In-Reply-To: <20260508-shikra_mailbox_and_rpm_changes-v3-0-698f8e5fb339@oss.qualcomm.com>
On Fri, 08 May 2026 16:10:45 +0530, Sneh Mankad wrote:
> Add support for RPM processor, rpm-smd device and APCS IPC device
> for Shikra by adding appropriate compatibles.
>
>
Applied, thanks!
[2/3] dt-bindings: remoteproc: Add Shikra RPM processor compatible
commit: 181836fb3aa6715e3dcd899c9283daa9dfbb91a0
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH 1/2] dt-bindings: remoteproc: qcom,sm8550-pas: Add Hawi ADSP compatible
From: Bjorn Andersson @ 2026-06-11 1:47 UTC (permalink / raw)
To: Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Manivannan Sadhasivam, Mukesh Ojha
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20260427190614.3679937-1-mukesh.ojha@oss.qualcomm.com>
On Tue, 28 Apr 2026 00:36:13 +0530, Mukesh Ojha wrote:
> Document compatible string for the ADSP Peripheral Authentication
> Service on the Hawi SoC, which is compatible with the Qualcomm SM8550
> ADSP PAS and can fallback to SM8550 except for the one additional
> interrupt ("shutdown-ack").
>
>
Applied, thanks!
[2/2] dt-bindings: remoteproc: qcom,sm8550-pas: Add Hawi CDSP compatible
commit: a9697e35887e7e3dc1135dd97efd39d46d910e73
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 0/2] remoteproc: qcom: Add Shikra remoteproc support
From: Bjorn Andersson @ 2026-06-11 1:47 UTC (permalink / raw)
To: Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Komal Bajaj
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Bibek Kumar Patro, Dmitry Baryshkov
In-Reply-To: <20260521-shikra-rproc-v3-0-2fca0bbe1ad7@oss.qualcomm.com>
On Thu, 21 May 2026 18:51:36 +0530, Komal Bajaj wrote:
> Add Peripheral Authentication Service (PAS) support for the Qualcomm
> Shikra SoC. This series introduces the device tree bindings and the
> driver resource configurations for the three remoteproc cores present
> on Shikra: CDSP, LPAICP and MPSS.
>
>
Applied, thanks!
[1/2] dt-bindings: remoteproc: qcom,shikra-pas: Document Shikra PAS remoteprocs
commit: 39176cdac9c7206ad4e70f22f134a6984a89be8b
[2/2] remoteproc: qcom: pas: Add Shikra remoteproc support
commit: 23dd0092bc150b55a62347ed4814c14fda7a32c2
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next v8 6/6] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
From: sashiko-bot @ 2026-06-11 1:32 UTC (permalink / raw)
To: lizhi2; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260610013223.972-1-lizhi2@eswincomputing.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Device Tree compiler warning: unit address without `reg` property.
- [Low] Device Tree schema validation warnings: non-standard node names.
--
commit 61fe87b2af33a89c6531d0d7ec8f49899a52057e
Author: Zhi Li <lizhi2@eswincomputing.com>
riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
Enable the on-board Gigabit Ethernet controller on the
HiFive Premier P550 development board.
> diff --git a/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts b/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> index 131ed1fc6b2ed..edd91b04e2515 100644
> --- a/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> +++ b/arch/riscv/boot/dts/eswin/eic7700-hifive-premier-p550.dts
> @@ -13,11 +13,251 @@ / {
[ ... ]
> chosen {
> stdout-path = "serial0:115200n8";
> };
> +
> + vcc_1v8: vcc1v8 {
^^^^^^
[Severity: Low]
Should this node be named using the generic regulator-* pattern, such as
regulator-1v8? The current name might trigger dtbs_check validation warnings
for the fixed-regulator schema.
> + compatible = "regulator-fixed";
> + regulator-name = "vcc1v8";
> + regulator-always-on;
[ ... ]
> diff --git a/arch/riscv/boot/dts/eswin/eic7700.dtsi b/arch/riscv/boot/dts/eswin/eic7700.dtsi
> index c3ed93008bca1..c77bc8b1b7bc0 100644
> --- a/arch/riscv/boot/dts/eswin/eic7700.dtsi
> +++ b/arch/riscv/boot/dts/eswin/eic7700.dtsi
[ ... ]
> @@ -202,6 +205,11 @@ pmu {
> <0x00000000 0x0000000f 0xfffffffc 0x000000ff 0x00000078>;
> };
>
> + xtal24m: oscillator {
^^^^^^^^^^
[Severity: Low]
Would it be better to use the generic clock-* pattern for this node name,
such as clock-24m? Using oscillator might trigger dtbs_check warnings
against the fixed-clock binding schema.
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + };
> +
> soc {
> compatible = "simple-bus";
> ranges;
> @@ -245,6 +253,85 @@ plic: interrupt-controller@c000000 {
> #interrupt-cells = <1>;
> };
>
> + hsp_power_domain: bus@50400000 {
^^^^^^^^^^^^
[Severity: Low]
Does this node need a reg property? It has a unit address (@50400000), which
usually requires a matching reg property. Without it, the devicetree compiler
might generate a unit_address_vs_reg warning.
> + compatible = "simple-pm-bus";
> + ranges;
> + clocks = <&clk 171>;
> + #address-cells = <2>;
> + #size-cells = <2>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610012727.848-1-lizhi2@eswincomputing.com?part=6
^ permalink raw reply
* Re: [PATCH net-next v8 2/6] dt-bindings: ethernet: eswin: add EIC7700 eth1 RX clock inversion variant
From: sashiko-bot @ 2026-06-11 1:32 UTC (permalink / raw)
To: lizhi2; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260610012907.894-1-lizhi2@eswincomputing.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Using a top-level `oneOf` partition for `compatible`-based constraints breaks schema extensibility and violates dt-schema conditional patterns.
--
commit c1875936c193e91a73baa1d661559e819f16e710
Author: Zhi Li <lizhi2@eswincomputing.com>
dt-bindings: ethernet: eswin: add EIC7700 eth1 RX clock inversion variant
This commit adds a new compatible string for the EIC7700 eth1 MAC variant
to handle RX clock inversion requirements. It introduces specific
tx-internal-delay-ps constraints for each variant using a oneOf block.
> diff --git a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
> index 4e02fedae5c67..8cb7545c56e87 100644
> --- a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
> +++ b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
[ ... ]
> allOf:
> - $ref: snps,dwmac.yaml#
>
> +oneOf:
> + - properties:
> + compatible:
> + contains:
> + const: eswin,eic7700-qos-eth
> + tx-internal-delay-ps:
> + minimum: 0
> + maximum: 2540
> + multipleOf: 20
> +
> + - properties:
> + compatible:
> + contains:
> + const: eswin,eic7700-qos-eth-clk-inversion
> + tx-internal-delay-ps:
> + minimum: 2000
> + maximum: 4540
> + multipleOf: 20
[Severity: Medium]
According to the device tree bindings subsystem guidelines, YAML binding
schemas typically use allOf with if-then blocks to apply different
constraints based on the compatible string.
Does placing a oneOf block at the root level create a mutually-exclusive
validation partition that will break schema extensibility?
If a new compatible string is added to the enum in the future, it looks
like it might fail the entire oneOf block by not matching either arm,
causing the whole document to fail validation.
Could this be rewritten using allOf and if-then conditionals?
[ ... ]
> @@ -67,11 +89,6 @@ properties:
> maximum: 2540
> multipleOf: 20
>
> - tx-internal-delay-ps:
> - minimum: 0
> - maximum: 2540
> - multipleOf: 20
> -
> eswin,hsp-sp-csr:
> description:
> HSP CSR is to control and get status of different high-speed peripherals
[Severity: Medium]
Is it intended to remove tx-internal-delay-ps entirely from the main
properties block?
Removing the property from the root properties block is usually considered
a schema anti-pattern. Should the base property definition remain here,
with only the range constraints being overridden in the conditional blocks
above?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610012727.848-1-lizhi2@eswincomputing.com?part=2
^ permalink raw reply
* Re: [PATCH v16 00/10] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-06-11 1:30 UTC (permalink / raw)
To: Andrew Morton
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, bhe, rppt, pasha.tatashin,
pratyush, ruirui.yang, rdunlap, peterz, feng.tang, dapeng1.mi,
kees, elver, kuba, lirongqing, ebiggers, paulmck, leitao, coxu,
Liam.Howlett, ryan.roberts, osandov, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, adityag, liaoyuanhong,
seanjc, fuqiang.wang, ardb, chenjiahao16, guoren, x86, linux-doc,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, devicetree, kexec
In-Reply-To: <20260608091000.d88d7f5cc1bc4fa17f5774fe@linux-foundation.org>
On 6/9/2026 12:10 AM, Andrew Morton wrote:
> On Mon, 8 Jun 2026 15:34:49 +0800 Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
>> The crash memory allocation, and the exclude of crashk_res, crashk_low_res
>> and crashk_cma memory are almost identical across different architectures,
>> This patch set handle them in crash core in a general way, which eliminate
>> a lot of duplication code.
>>
>> And add support for crashkernel CMA reservation for arm64 and riscv.
>
> fyi, AI review might have found a bunch of issues in arch-specific
> code, all of them pre-existing.
Hi, Andrew，
As Mike conveyed, Baoquan proposed splitting out the unrelated bug fixes
into a separate patch set, in order to keep v16 from growing excessively.
Link: https://lore.kernel.org/all/ah2Lx7KHI60tzd0v@MiWiFi-R3L-srv/
Best Regards,
Jinjie
>
> https://sashiko.dev/#/patchset/20260608073459.3119290-1-ruanjinjie@huawei.com
>
^ permalink raw reply
* [PATCH 2/3] arm64: dts: renesas: r8a77965-salvator-xs: Enable GPU support
From: Marek Vasut @ 2026-06-11 0:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Frank Binns,
Geert Uytterhoeven, Krzysztof Kozlowski, Maarten Lankhorst,
Magnus Damm, Matt Coster, Maxime Ripard, Niklas Söderlund,
Rob Herring, Simona Vetter, Thomas Zimmermann, devicetree,
dri-devel, linux-renesas-soc
In-Reply-To: <20260611005952.146825-1-marek.vasut+renesas@mailbox.org>
Enable GPU on Salvator-X 2nd version with R-Car M3-N.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Frank Binns <frank.binns@imgtec.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Matt Coster <matt.coster@imgtec.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
index a1d3c8d531cfe..f0d9c0124f69c 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
@@ -30,3 +30,7 @@ &du {
clock-names = "du.0", "du.1", "du.3",
"dclkin.0", "dclkin.1", "dclkin.3";
};
+
+&gpu {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: renesas: r8a77965-ulcb: Enable GPU support
From: Marek Vasut @ 2026-06-11 0:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Frank Binns,
Geert Uytterhoeven, Krzysztof Kozlowski, Maarten Lankhorst,
Magnus Damm, Matt Coster, Maxime Ripard, Niklas Söderlund,
Rob Herring, Simona Vetter, Thomas Zimmermann, devicetree,
dri-devel, linux-renesas-soc
In-Reply-To: <20260611005952.146825-1-marek.vasut+renesas@mailbox.org>
Enable GPU on M3NULCB with R-Car M3-N.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Frank Binns <frank.binns@imgtec.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Matt Coster <matt.coster@imgtec.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts b/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts
index 71704b67a20e1..127eb2ea3c920 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts
@@ -31,3 +31,7 @@ &du {
clock-names = "du.0", "du.1", "du.3",
"dclkin.0", "dclkin.1", "dclkin.3";
};
+
+&gpu {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: renesas: r8a77965-salvator-x: Enable GPU support
From: Marek Vasut @ 2026-06-11 0:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Frank Binns,
Geert Uytterhoeven, Krzysztof Kozlowski, Maarten Lankhorst,
Magnus Damm, Matt Coster, Maxime Ripard, Niklas Söderlund,
Rob Herring, Simona Vetter, Thomas Zimmermann, devicetree,
dri-devel, linux-renesas-soc
Enable GPU on Salvator-X with R-Car M3-N.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Frank Binns <frank.binns@imgtec.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Matt Coster <matt.coster@imgtec.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
index f84c64ed4df7b..af8cfdccd2103 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
@@ -30,3 +30,7 @@ &du {
clock-names = "du.0", "du.1", "du.3",
"dclkin.0", "dclkin.1", "dclkin.3";
};
+
+&gpu {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
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