* [PATCH v1 2/2] ASoC: qcom: sc8280xp: add Shikra EVK machine variants
From: Ajay Kumar Nandam @ 2026-06-11 11:29 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel, ajay.nandam,
Mohammad Rafi Shaik
In-Reply-To: <20260611112946.954172-1-ajay.nandam@oss.qualcomm.com>
Add machine-driver support for Qualcomm Shikra EVK variants by matching
dedicated compatible strings and applying board-specific audio behavior.
Shikra platforms are available as CQM, CQS, and IQS variants with
different audio components and processing architectures:
- CQM/CQS use an I2S-based path with WSA885x amplifiers and
PM4125 + Rouleur codec components.
- CQM runs in DSP-bypass mode, where the complete audio pipeline runs
on CPU only and no DSP is involved.
- CQS uses modem-DSP based audio processing.
- IQS uses a third-party MAX98091 codec with modem-DSP support.
Introduce variant-specific handling so codec controls, DAPM widgets, and
clock programming match the board design and avoid invalid clock setup on
variants where it is not applicable.
Co-developed-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Signed-off-by: Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com>
---
sound/soc/qcom/common.c | 2 ++
sound/soc/qcom/sc8280xp.c | 58 +++++++++++++++++++++++++++++++++++++--
sound/soc/qcom/sdw.c | 3 ++
3 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/sound/soc/qcom/common.c b/sound/soc/qcom/common.c
index f42c98ded..32d6c09b2 100644
--- a/sound/soc/qcom/common.c
+++ b/sound/soc/qcom/common.c
@@ -3,6 +3,7 @@
// Copyright (c) 2018, The Linux Foundation. All rights reserved.
#include <dt-bindings/sound/qcom,q6afe.h>
+#include <dt-bindings/sound/qcom,qaif.h>
#include <linux/module.h>
#include <sound/jack.h>
#include <linux/input-event-codes.h>
@@ -430,6 +431,7 @@ int qcom_snd_wcd_jack_setup(struct snd_soc_pcm_runtime *rtd,
}
switch (cpu_dai->id) {
+ case QAIF_CDC_DMA_RX0:
case TX_CODEC_DMA_TX_0:
case TX_CODEC_DMA_TX_1:
case TX_CODEC_DMA_TX_2:
diff --git a/sound/soc/qcom/sc8280xp.c b/sound/soc/qcom/sc8280xp.c
index e5d23e244..4c985f81c 100644
--- a/sound/soc/qcom/sc8280xp.c
+++ b/sound/soc/qcom/sc8280xp.c
@@ -37,6 +37,25 @@ static struct snd_soc_dapm_widget sc8280xp_dapm_widgets[] = {
SND_SOC_DAPM_SPK("DP7 Jack", NULL),
};
+static struct snd_soc_dapm_widget shikra_cqm_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Headphone Jack", NULL),
+ SND_SOC_DAPM_MIC("Mic Jack", NULL),
+};
+
+static const struct snd_soc_dapm_widget shikra_iqs_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Headphone", NULL),
+ SND_SOC_DAPM_MIC("Headset Mic", NULL),
+ SND_SOC_DAPM_MIC("Int Mic", NULL),
+ SND_SOC_DAPM_SPK("Speaker", NULL),
+};
+
+static const struct snd_kcontrol_new shikra_iqs_controls[] = {
+ SOC_DAPM_PIN_SWITCH("Headset Mic"),
+ SOC_DAPM_PIN_SWITCH("Headphone"),
+ SOC_DAPM_PIN_SWITCH("Int Mic"),
+ SOC_DAPM_PIN_SWITCH("Speaker"),
+};
+
struct snd_soc_common {
const char *driver_name;
const struct snd_soc_dapm_widget *dapm_widgets;
@@ -49,6 +68,7 @@ struct snd_soc_common {
bool codec_sysclk_set;
bool mi2s_mclk_enable;
bool mi2s_bclk_enable;
+ bool dsp_bypass;
};
struct sc8280xp_snd_data {
@@ -219,6 +239,10 @@ static int sc8280xp_snd_hw_params(struct snd_pcm_substream *substream,
int mclk_freq = sc8280xp_get_mclk_freq(params);
int bclk_freq = sc8280xp_get_bclk_freq(params);
+ /* Skip DSP configuration when operating in CPU-only (bypass) mode */
+ if (data->snd_soc_common_priv->dsp_bypass)
+ return 0;
+
switch (cpu_dai->id) {
case PRIMARY_MI2S_RX ... QUATERNARY_MI2S_TX:
case QUINARY_MI2S_RX ... QUINARY_MI2S_TX:
@@ -239,7 +263,7 @@ static int sc8280xp_snd_hw_params(struct snd_pcm_substream *substream,
SND_SOC_CLOCK_IN);
if (data->snd_soc_common_priv->codec_sysclk_set)
- snd_soc_dai_set_sysclk(cpu_dai,
+ snd_soc_dai_set_sysclk(codec_dai,
0, mclk_freq,
SND_SOC_CLOCK_IN);
break;
@@ -284,7 +308,7 @@ static void sc8280xp_add_be_ops(struct snd_soc_card *card)
int i;
for_each_card_prelinks(card, i, link) {
- if (link->no_pcm == 1) {
+ if (link->no_pcm == 1 || link->num_codecs > 0) {
link->init = sc8280xp_snd_init;
link->be_hw_params_fixup = sc8280xp_be_hw_params_fixup;
link->ops = &sc8280xp_be_ops;
@@ -375,6 +399,33 @@ static struct snd_soc_common sc8280xp_priv_data = {
.num_dapm_widgets = ARRAY_SIZE(sc8280xp_dapm_widgets),
};
+static const struct snd_soc_common shikra_cqm_priv_data = {
+ .driver_name = "shikra",
+ .dapm_widgets = shikra_cqm_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(shikra_cqm_dapm_widgets),
+ .dsp_bypass = true,
+};
+
+static const struct snd_soc_common shikra_cqs_priv_data = {
+ .driver_name = "shikra",
+ .dapm_widgets = shikra_cqm_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(shikra_cqm_dapm_widgets),
+ .mi2s_bclk_enable = true,
+ .codec_sysclk_set = true,
+};
+
+static const struct snd_soc_common shikra_iqs_priv_data = {
+ .driver_name = "shikra",
+ .dapm_widgets = shikra_iqs_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(shikra_iqs_dapm_widgets),
+ .controls = shikra_iqs_controls,
+ .num_controls = ARRAY_SIZE(shikra_iqs_controls),
+ .codec_dai_fmt = SND_SOC_DAIFMT_CBP_CFP |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_I2S,
+ .codec_sysclk_set = true,
+ .mi2s_bclk_enable = true,
+};
+
static struct snd_soc_common sm8450_priv_data = {
.driver_name = "sm8450",
.dapm_widgets = sc8280xp_dapm_widgets,
@@ -408,6 +459,9 @@ static const struct of_device_id snd_sc8280xp_dt_match[] = {
{.compatible = "qcom,qcs9075-sndcard", .data = &qcs9100_priv_data},
{.compatible = "qcom,qcs9100-sndcard", .data = &qcs9100_priv_data},
{.compatible = "qcom,sc8280xp-sndcard", .data = &sc8280xp_priv_data},
+ {.compatible = "qcom,shikra-cqm-sndcard", .data = &shikra_cqm_priv_data},
+ {.compatible = "qcom,shikra-cqs-sndcard", .data = &shikra_cqs_priv_data},
+ {.compatible = "qcom,shikra-iqs-sndcard", .data = &shikra_iqs_priv_data},
{.compatible = "qcom,sm8450-sndcard", .data = &sm8450_priv_data},
{.compatible = "qcom,sm8550-sndcard", .data = &sm8550_priv_data},
{.compatible = "qcom,sm8650-sndcard", .data = &sm8650_priv_data},
diff --git a/sound/soc/qcom/sdw.c b/sound/soc/qcom/sdw.c
index 6576b47a4..0be743cec 100644
--- a/sound/soc/qcom/sdw.c
+++ b/sound/soc/qcom/sdw.c
@@ -4,6 +4,7 @@
#include <dt-bindings/sound/qcom,lpass.h>
#include <dt-bindings/sound/qcom,q6afe.h>
+#include <dt-bindings/sound/qcom,qaif.h>
#include <linux/module.h>
#include <sound/soc.h>
#include "sdw.h"
@@ -41,6 +42,8 @@ static bool qcom_snd_is_sdw_dai(int id)
switch (id) {
case LPASS_CDC_DMA_TX3:
case LPASS_CDC_DMA_RX0:
+ case QAIF_CDC_DMA_VA_TX0:
+ case QAIF_CDC_DMA_RX0:
return true;
default:
break;
--
2.34.1
^ permalink raw reply related
* [PATCH v1 1/2] ASoC: dt-bindings: qcom,sm8250: add Shikra sound card compatibles
From: Ajay Kumar Nandam @ 2026-06-11 11:29 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel, ajay.nandam,
Mohammad Rafi Shaik
In-Reply-To: <20260611112946.954172-1-ajay.nandam@oss.qualcomm.com>
Add Shikra sound-card compatible strings to the Qualcomm sound card
binding so DT can describe board-specific audio topologies:
- qcom,shikra-cqm-sndcard
- qcom,shikra-cqs-sndcard
- qcom,shikra-iqs-sndcard
Shikra EVK variants use different codec/interface combinations and DSP
processing paths. Describing these variants explicitly in DT allows the
machine driver to select the correct DAPM routes, controls, and clocking
behavior for each board.
Co-developed-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Signed-off-by: Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com>
---
Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
index 15f38622b..c5c7284bf 100644
--- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
@@ -45,6 +45,9 @@ properties:
- qcom,sc7180-qdsp6-sndcard
- qcom,sc8280xp-sndcard
- qcom,sdm845-sndcard
+ - qcom,shikra-cqm-sndcard
+ - qcom,shikra-cqs-sndcard
+ - qcom,shikra-iqs-sndcard
- qcom,sm8250-sndcard
- qcom,sm8450-sndcard
- qcom,x1e80100-sndcard
--
2.34.1
^ permalink raw reply related
* [PATCH v1 0/2] ASoC: qcom: Shikra machine driver and DT binding support
From: Ajay Kumar Nandam @ 2026-06-11 11:29 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel, ajay.nandam
This series adds Qualcomm Shikra sound-card variant support in DT
bindings and in the sc8280xp machine driver.
Shikra EVK variants use different audio components and processing
architectures:
- CQM/CQS use an I2S-based path with WSA885x amplifiers and
PM4125 + Rouleur codec components.
- CQM runs in DSP-bypass mode (CPU-only audio pipeline).
- CQS uses modem-DSP based audio processing.
- IQS uses a third-party MAX98091 codec with modem-DSP support.
The DT binding patch adds explicit Shikra compatibles, and the machine
patch wires variant-specific DAPM/controls and clock behavior so each
board is configured correctly.
Dependencies:
- lore.kernel.org/all/20260605103739.3557573-1-harendra.gautam@oss.qualcomm.com/
- lore.kernel.org/all/20260608023011.942228-1-mohammad.rafi.shaik@oss.qualcomm.com/
- lore.kernel.org/linux-arm-msm/20260610154517.134570-1-prasad.kumpatla@oss.qualcomm.com/
Ajay Kumar Nandam (2):
ASoC: dt-bindings: qcom,sm8250: add Shikra sound card compatibles
ASoC: qcom: sc8280xp: add Shikra EVK machine variants
.../bindings/sound/qcom,sm8250.yaml | 3 +
sound/soc/qcom/common.c | 2 +
sound/soc/qcom/sc8280xp.c | 58 ++++++++++++++++++-
sound/soc/qcom/sdw.c | 3 +
4 files changed, 64 insertions(+), 2 deletions(-)
base-commit: abe651837cb394f76d738a7a747322fca3bf17ba
prerequisite-patch-id: 430488f50f36039338965ab1fc28d83f02dbc9fd
prerequisite-patch-id: 359ddad8a3fb36f171c96da5ce5ffacd7dd63e8f
prerequisite-patch-id: a98885b9d0e0655bb3161dc2c31fd92a844a5e4e
prerequisite-patch-id: 63e6b911ad6700c1039802235c0a6d5870957f8c
prerequisite-patch-id: 6d481dd14afe58a17230318f418ec3fe0d327faf
prerequisite-patch-id: 7675b5ea6f01d7dadb8df43c8532daa4167fc92f
prerequisite-patch-id: 3fcc510f8f38ce63b24f02d48257ce8d7079b61e
prerequisite-patch-id: 037f677639a12a986e024f9a66df2def301925d4
prerequisite-patch-id: 888f7d13f882fdd0a01bc3fcbe008e9e56394bd3
prerequisite-patch-id: 7db9bb6a1d3de3667a0880f8a75c24ce62e52ecd
prerequisite-patch-id: b898d117a21bddc176ae19937b03e733df72f821
prerequisite-patch-id: 3ca81fae4cb388c4970e908fb63cc99bc1cdd008
prerequisite-patch-id: 80aead6484e36f52cb6cc7fd7d9e0326d8296860
prerequisite-patch-id: 2f1bd3efac328030dd8efe28fb95f84603868043
prerequisite-patch-id: 047b4fb1894b92109aa7afcebd7d5c7988ec5379
prerequisite-patch-id: 222630a15afc952683d954a3c66617a223546de0
prerequisite-patch-id: 3c55edb41f1e25920a350ce1c6f31fde67fee45a
prerequisite-patch-id: 0de75678d071f174c865afa2915be4df1aef8c8d
prerequisite-patch-id: 14840d7e2441e2110c1e147941744be637c9595f
prerequisite-patch-id: a7706e25f5951ec41e6b662c1704df8d20662d77
prerequisite-patch-id: 1e1be31d7ddc47eec9193164defa3e5c473b6ef1
prerequisite-patch-id: d13035abab3ff342753f5bf87b53bbf06a02c6a1
prerequisite-patch-id: 79fcbe1428667a6e0059cea9cbfd62d38d114930
--
2.34.1
^ permalink raw reply
* Re: [PATCH 3/4] clk: qcom: Add Audio Core clock controller support on Qualcomm Shikra SoC
From: Konrad Dybcio @ 2026-06-11 11:27 UTC (permalink / raw)
To: Imran Shaik, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Philipp Zabel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260605-shikra-audiocorecc-v1-3-7ee6b5f2d928@oss.qualcomm.com>
On 6/5/26 1:26 PM, Imran Shaik wrote:
> Add support for Audio Core Clock Controller (AUDIOCORECC) on Qualcomm
> Shikra SoC. The AUDIOCORECC clocks and resets support differs based on
> Audio subsystem enablement. In the CQM variant, both clocks and resets
> are required as Audio is on APPS, while in the CQS variant only reset
> control is required since Audio is handled on Modem. Handle these
> requirements using variant specific compatibles.
>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> ---
[...]
> +static const struct qcom_reset_map audio_core_cc_shikra_resets[] = {
> + [AUDIO_CORE_CSR_RX_SWR_CGCR] = { 0x1c },
> + [AUDIO_CORE_CSR_TX_SWR_CGCR] = { 0x30 },
So these are not "real resets", but for the sake of existing art, we
can keep pretending they are
bit 1 is HW_CTL (1->hw controlled) and bit 0 is taken into account only
if 1 is cleared
existing drivers toggle the HW_CTRL bit (meaning it's an
maybe-on/surely-on switch rather than off/on).. do we need to rectify
that somehow?
Konrad
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: shikra: Add support for AudioCoreCC node
From: Konrad Dybcio @ 2026-06-11 11:25 UTC (permalink / raw)
To: Imran Shaik, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Philipp Zabel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260605-shikra-audiocorecc-v1-4-7ee6b5f2d928@oss.qualcomm.com>
On 6/5/26 1:26 PM, Imran Shaik wrote:
> Add support for Audio Core Clock Controller (AudioCoreCC) node on Qualcomm
> Shikra SoC. The CQM variant requires both clock and reset support, while
> the CQS variant requires only reset support. Update the respective device
> tree variants to enable and override the node as per variant requirements.
>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 4 ++++
> arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 5 +++++
> arch/arm64/boot/dts/qcom/shikra.dtsi | 13 +++++++++++++
> 3 files changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> index 0a52ab9b7a4c34d371f5ac23efe59d1c9d2723f4..0883c480bfbc80d7bead966b9ba932dee8a77bbf 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> @@ -23,6 +23,10 @@ chosen {
> };
> };
>
> +&audiocorecc {
> + status = "okay";
> +};
> +
> &sdhc_1 {
> vmmc-supply = <&pm4125_l20>;
> vqmmc-supply = <&pm4125_l14>;
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> index b3f19a64d7aed3121ef092df684b19a4de39b497..b5e3d573868a836ad5e5e8eb3024cb5fb71dbb4e 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> @@ -23,6 +23,11 @@ chosen {
> };
> };
>
> +&audiocorecc {
> + compatible = "qcom,shikra-cqs-audiocorecc";
> + status = "okay";
> +};
> +
> &sdhc_1 {
> vmmc-supply = <&pm4125_l20>;
> vqmmc-supply = <&pm4125_l14>;
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..f15757d52af04d8cb5540354a239127cb0d174a3 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -4,6 +4,7 @@
> */
>
> #include <dt-bindings/clock/qcom,rpmcc.h>
> +#include <dt-bindings/clock/qcom,shikra-audiocorecc.h>
> #include <dt-bindings/clock/qcom,shikra-gcc.h>
> #include <dt-bindings/interconnect/qcom,icc.h>
> #include <dt-bindings/interconnect/qcom,rpm-icc.h>
> @@ -640,6 +641,18 @@ &clk_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
> };
> };
>
> + audiocorecc: clock-controller@a0a0000 {
> + compatible = "qcom,shikra-cqm-audiocorecc";
> + reg = <0x0 0x0a0a0000 0x0 0x10000>,
This is called AUDIO_CORE_CC where seemingly all the clocks live
> + <0x0 0x0a0b4000 0x0 0x1000>;
and this is called AUDIO_CORE_CSR where seemingly all the resets live
so it would make sense to split them
Konrad
^ permalink raw reply
* Re: [PATCH 3/4] clk: qcom: Add Audio Core clock controller support on Qualcomm Shikra SoC
From: Konrad Dybcio @ 2026-06-11 11:22 UTC (permalink / raw)
To: Imran Shaik, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Philipp Zabel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260605-shikra-audiocorecc-v1-3-7ee6b5f2d928@oss.qualcomm.com>
On 6/5/26 1:26 PM, Imran Shaik wrote:
> Add support for Audio Core Clock Controller (AUDIOCORECC) on Qualcomm
> Shikra SoC. The AUDIOCORECC clocks and resets support differs based on
> Audio subsystem enablement. In the CQM variant, both clocks and resets
> are required as Audio is on APPS, while in the CQS variant only reset
> control is required since Audio is handled on Modem. Handle these
> requirements using variant specific compatibles.
>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> ---
[...]
> +static int audio_core_cc_shikra_probe(struct platform_device *pdev)
> +{
> + int ret;
> +
> + ret = qcom_cc_probe_by_index(pdev, 1, &audio_core_cc_shikra_reset_desc);
> + if (ret)
> + return ret;
> +
> + if (device_is_compatible(&pdev->dev, "qcom,shikra-cqs-audiocorecc"))
> + return 0;
> +
> + return qcom_cc_probe(pdev, &audio_core_cc_shikra_desc);
> +}
If the clock list is complete and you pinky-promise to never extend it,
we can simply go with a single compatible and use protected-clocks in DT
to avoid accessing any of these registers (sorta like kodiak GCC), removing
the complexity
Konrad
^ permalink raw reply
* Re: [PATCH V11 6/9] iio: imu: inv_icm42607: Add Temp Support in icm42607
From: Jonathan Cameron @ 2026-06-11 11:22 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260610175455.19006-7-macroalpha82@gmail.com>
On Wed, 10 Jun 2026 12:54:50 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add functions for reading temperature sensor data.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Hi Chris,
A few consistency things around the channel definitions and some
left over stuff I think from you ripping out the interrupt / buffered support.
Thanks,
Jonathan
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> new file mode 100644
> index 000000000000..55260082a19e
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> @@ -0,0 +1,82 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/iio/iio.h>
> +#include <linux/mutex.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +
> +#include "inv_icm42607.h"
> +#include "inv_icm42607_temp.h"
> +int inv_icm42607_temp_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + s16 temp;
> + int ret;
> +
> + if (chan->type != IIO_TEMP)
> + return -EINVAL;
This feels little over defensive given the function name. Any bug
that called it anyway would be pretty bad!
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
The lack of having the shared_by_all stuff in here makes things
a little fragile (once you've added them to the bitmap below) as
which chan->type we get depends on channel registration ordering.
So avoid this being called for those mask elements. I'll reply
to next patch to call that out in a few mins.
> + if (!iio_device_claim_direct(indio_dev))
> + return -EBUSY;
A driver that isn't yet doing buffered support should not be
claiming modes (as it's always in direct mode). If this is
serializing for some reason other than avoiding mode transitions,
it should be using the local lock. Seems it is doing that
anyway so just drop this layer of protection.
> + ret = inv_icm42607_temp_read(st, &temp);
> + iio_device_release_direct(indio_dev);
> + if (ret)
> + return ret;
> + *val = temp;
> + return IIO_VAL_INT;
> + /*
> + * T°C = (temp / 128) + 25
> + * Tm°C = 1000 * ((temp * 100 / 12800) + 25)
> + * scale: 100000 / 12800 ~= 7.8125
> + * offset: 3200
> + */
> + case IIO_CHAN_INFO_SCALE:
> + *val = 7;
> + *val2 = 812500000;
> + return IIO_VAL_INT_PLUS_NANO;
> + case IIO_CHAN_INFO_OFFSET:
> + *val = 3200;
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
> new file mode 100644
> index 000000000000..e03924e30866
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
> @@ -0,0 +1,33 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#ifndef INV_ICM42607_TEMP_H_
> +#define INV_ICM42607_TEMP_H_
> +
> +#include <linux/bitops.h>
> +
> +struct iio_dev;
> +struct iio_chan_spec;
> +
> +#define INV_ICM42607_TEMP_CHAN(_index) \
> +{ \
> + .type = IIO_TEMP, \
> + .info_mask_separate = \
> + BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_OFFSET) | \
> + BIT(IIO_CHAN_INFO_SCALE), \
Whilst it makes no difference to exposure of sysfs attributes, this
should include the shared_by_all stuff form the other channels.
That is supposed to be in every channel so that we can easily see
what affects each channel.
> + .scan_index = _index, \
> + .scan_type = { \
> + .sign = 's', \
> + .realbits = 16, \
> + .storagebits = 16, \
> + }, \
> +}
> +
> +int inv_icm42607_temp_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask);
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v3 3/4] arm64: qcom: ipq5018: Add GEPHY RX and TX clocks
From: Konrad Dybcio @ 2026-06-11 11:17 UTC (permalink / raw)
To: Paolo Abeni, george.moussalem, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Bjorn Andersson, Konrad Dybcio
Cc: netdev, devicetree, linux-kernel, linux-arm-msm, Dmitry Baryshkov
In-Reply-To: <3d0f0b12-9bec-42b2-b8e8-264c6da0fbae@oss.qualcomm.com>
On 6/11/26 1:17 PM, Konrad Dybcio wrote:
> On 6/11/26 11:28 AM, Paolo Abeni wrote:
>> On 6/5/26 2:41 PM, George Moussalem via B4 Relay wrote:
>>> From: George Moussalem <george.moussalem@outlook.com>
>>>
>>> Add RX and TX clocks for the IPQ5018 GEPHY to enable the datapath.
>>>
>>> Fixes: f5f2b835e316 ("arm64: dts: qcom: ipq5018: Add GE PHY to internal mdio bus")
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>>
>> I think here we need an explicit ack from arm people to take this patch
>> (and the whole series).
>
> This one should go through the qcom tree
this one = this single dts patch
Konrad
^ permalink raw reply
* Re: [PATCH v8 2/7] mfd: Add driver for ASUS Transformer embedded controller
From: Lee Jones @ 2026-06-11 11:17 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <20260528053203.9339-3-clamor95@gmail.com>
On Thu, 28 May 2026, Svyatoslav Ryhel wrote:
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Support Nuvoton NPCE795-based ECs as used in Asus Transformer TF201,
> TF300T, TF300TG, TF300TL and TF700T pad and dock, as well as TF101 dock
> and TF600T, P1801-T and TF701T pad. This is a glue driver handling
> detection and common operations for EC's functions.
>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
> drivers/mfd/Kconfig | 16 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/asus-transformer-ec.c | 542 ++++++++++++++++++++++++
> include/linux/mfd/asus-transformer-ec.h | 92 ++++
> 4 files changed, 651 insertions(+)
> create mode 100644 drivers/mfd/asus-transformer-ec.c
> create mode 100644 include/linux/mfd/asus-transformer-ec.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 7192c9d1d268..e1c32505b97a 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -137,6 +137,22 @@ config MFD_AAT2870_CORE
> additional drivers must be enabled in order to use the
> functionality of the device.
>
> +config MFD_ASUS_TRANSFORMER_EC
> + tristate "ASUS Transformer's embedded controller"
> + select MFD_CORE
> + depends on I2C && OF
> + help
> + Select this to enable support for the Embedded Controller (EC)
> + found in Tegra based ASUS Transformer series tablets and mobile
> + docks.
> +
> + This driver handles the core I2C communication with the EC and
> + provides support for its sub-devices, including battery management,
> + charger detection, LEDs and keyboard dock functions support.
> +
> + This driver can also be built as a module. If so, the module
> + will be called asus-transformer-ec.
> +
> config MFD_AT91_USART
> tristate "AT91 USART Driver"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index e75e8045c28a..fd80088d8a9a 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
> obj-$(CONFIG_MFD_88PM886_PMIC) += 88pm886.o
> obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
> obj-$(CONFIG_MFD_SM501) += sm501.o
> +obj-$(CONFIG_MFD_ASUS_TRANSFORMER_EC) += asus-transformer-ec.o
> obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o
> obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
> obj-$(CONFIG_MFD_BD9571MWV) += bd9571mwv.o
> diff --git a/drivers/mfd/asus-transformer-ec.c b/drivers/mfd/asus-transformer-ec.c
> new file mode 100644
> index 000000000000..1f5900d0fdc9
> --- /dev/null
> +++ b/drivers/mfd/asus-transformer-ec.c
> @@ -0,0 +1,542 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include <linux/array_size.h>
> +#include <linux/debugfs.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/mfd/asus-transformer-ec.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/property.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +#include <linux/unaligned.h>
> +
> +#define ASUSEC_RSP_BUFFER_SIZE (ASUSEC_ENTRIES / ASUSEC_ENTRY_SIZE)
> +
> +#define ASUSEC_RESET 0
> +#define ASUSEC_RETRY_MAX 3
> +#define ASUSEC_ACCESS_TIMEOUT 300
> +
> +enum asusec_variant {
> + ASUSEC_SL101_DOCK = 1,
> + ASUSEC_TF101_DOCK,
> + ASUSEC_TF201_PAD,
> + ASUSEC_TF600T_PAD,
> + ASUSEC_MAX
> +};
> +
> +enum asusec_mode {
> + ASUSEC_MODE_NONE,
> + ASUSEC_MODE_NORMAL,
> + ASUSEC_MODE_FACTORY,
> + ASUSEC_MODE_MAX
> +};
> +
> +/**
> + * struct asus_ec_chip_info
> + *
> + * @name: prefix associated with the EC
> + * @variant: id of programming model of EC
> + * @mode: state of Factory Mode bit in EC control register
> + */
> +struct asus_ec_chip_info {
> + const char *name;
> + enum asusec_variant variant;
> + enum asusec_mode fmode;
> +};
> +
> +/**
> + * struct asus_ec_data
> + *
> + * @ec: public part shared with all cells (must be first)
> + * @ecreq_lock: prevents simultaneous access to EC
> + * @ecreq_gpio: EC request GPIO
> + * @client: pointer to EC's i2c_client
> + * @info: pointer to EC's version description
> + * @ec_buf: buffer for EC read
> + * @logging_disabled: flag disabling logging on reset events
> + */
> +struct asus_ec_data {
> + struct asusec_core ec;
> + struct mutex ecreq_lock;
> + struct gpio_desc *ecreq_gpio;
> + struct i2c_client *client;
> + const struct asus_ec_chip_info *info;
> + u8 ec_buf[ASUSEC_ENTRY_BUFSIZE];
> + bool logging_disabled;
> +};
> +
> +/**
> + * struct dockram_ec_data
> + *
> + * @ctl_lock: prevent simultaneous access to Dockram
> + * @ctl_buf: buffer for Dockram read
> + */
> +struct dockram_ec_data {
> + struct mutex ctl_lock;
> + u8 ctl_buf[ASUSEC_ENTRY_BUFSIZE];
> +};
> +
> +/**
> + * asus_dockram_access_ctl - Read from or write to the DockRAM control register.
> + * @client: Handle to the DockRAM device.
> + * @out: Pointer to a variable where the register value will be stored.
> + * @mask: Bitmask of bits to be cleared.
> + * @xor: Bitmask of bits to be set (via XOR).
> + *
> + * This performs a control register read if @out is provided and both @mask
> + * and @xor are zero. Otherwise, it performs a control register update if
> + * @mask and @xor are provided.
> + *
> + * Returns a negative errno code else zero on success.
> + */
> +int asus_dockram_access_ctl(struct i2c_client *client, u64 *out, u64 mask,
> + u64 xor)
> +{
> + struct dockram_ec_data *ddata = i2c_get_clientdata(client);
> + u8 *buf = ddata->ctl_buf;
> + u64 val;
> + int ret = 0;
> +
> + guard(mutex)(&ddata->ctl_lock);
> +
> + memset(buf, 0, ASUSEC_ENTRY_BUFSIZE);
> + ret = i2c_smbus_read_i2c_block_data(client, ASUSEC_DOCKRAM_CONTROL,
> + ASUSEC_ENTRY_SIZE, buf);
> + if (ret < ASUSEC_ENTRY_SIZE) {
> + dev_err(&client->dev, "failed to access control buffer: %d\n",
> + ret);
> + return ret;
Should we return a negative error code here if the read is shorter than
expected, rather than propagating the positive byte count?
> + }
> +
> + if (buf[0] != ASUSEC_CTL_SIZE) {
> + dev_err(&client->dev, "buffer size exceeds %d: %d\n",
> + ASUSEC_CTL_SIZE, buf[0]);
> + return -EPROTO;
> + }
> +
> + val = get_unaligned_le64(buf + 1);
> +
> + if (out)
> + *out = val;
> +
> + if (mask || xor) {
> + put_unaligned_le64((val & ~mask) ^ xor, buf + 1);
> + ret = i2c_smbus_write_i2c_block_data(client,
> + ASUSEC_DOCKRAM_CONTROL,
> + ASUSEC_ENTRY_SIZE, buf);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(asus_dockram_access_ctl);
> +
> +static int asus_ec_signal_request(struct asus_ec_data *ddata)
> +{
> + guard(mutex)(&ddata->ecreq_lock);
> +
> + gpiod_set_value_cansleep(ddata->ecreq_gpio, 1);
> + msleep(50);
> +
> + gpiod_set_value_cansleep(ddata->ecreq_gpio, 0);
> + msleep(200);
Do these numbers come from the datasheet or were they arbitrarily chosen?
> +
> + return 0;
> +}
> +
> +static void asus_ec_clear_buffer(struct asus_ec_data *ddata)
> +{
> + int ret, retry = ASUSEC_RSP_BUFFER_SIZE;
> +
> + /*
> + * Read the buffer till we get valid data by checking ASUSEC_OBF_MASK
> + * of the status byte or till we reach end of the 256 byte buffer.
> + */
> + while (retry--) {
> + ret = i2c_smbus_read_i2c_block_data(ddata->client, ASUSEC_READ_BUF,
> + ASUSEC_ENTRY_SIZE,
> + ddata->ec_buf);
> + if (ret < ASUSEC_ENTRY_SIZE)
> + continue;
> +
> + if (ddata->ec_buf[ASUSEC_IRQ_STATUS] & ASUSEC_OBF_MASK)
> + continue;
> +
> + break;
> + }
> +}
> +
> +static int asus_ec_log_info(struct asus_ec_data *ddata, unsigned int reg,
> + const char *name, const char **out)
> +{
> + struct device *dev = &ddata->client->dev;
> + u8 buf[ASUSEC_ENTRY_BUFSIZE];
> + int ret;
> +
> + memset(buf, 0, ASUSEC_ENTRY_BUFSIZE);
> + ret = i2c_smbus_read_i2c_block_data(ddata->ec.dockram, reg,
> + ASUSEC_ENTRY_SIZE, buf);
> + if (ret < ASUSEC_ENTRY_SIZE)
> + return ret;
Same here. These should be negative.
> +
> + if (buf[0] > ASUSEC_ENTRY_SIZE) {
> + dev_err(dev, "bad data len; buffer: %*ph; ret: %d\n",
> + ASUSEC_ENTRY_BUFSIZE, buf, ret);
> + return -EPROTO;
> + }
> +
> + if (!ddata->logging_disabled) {
> + dev_info(dev, "%-14s: %.*s\n", name, buf[0], buf + 1);
> +
> + if (out) {
> + *out = devm_kasprintf(dev, GFP_KERNEL, "%.*s",
> + buf[0], buf + 1);
> + if (!*out)
> + return -ENOMEM;
> + }
> + }
FWIW, I hate this! What does it give you now that development is done?
> + return 0;
> +}
> +
> +static int asus_ec_reset(struct asus_ec_data *ddata)
> +{
> + int retry, ret;
> +
> + guard(mutex)(&ddata->ecreq_lock);
> +
> + for (retry = 0; retry < ASUSEC_RETRY_MAX; retry++) {
for (int return = ... is generally preferred for throwaway variables.
> + ret = i2c_smbus_write_word_data(ddata->client, ASUSEC_WRITE_BUF,
> + ASUSEC_RESET);
> + if (!ret)
> + return 0;
> +
> + msleep(ASUSEC_ACCESS_TIMEOUT);
I like that this is defined, can we do that with the others please?
> + }
> +
> + return ret;
> +}
> +
> +static int asus_ec_susb_on_status(struct asus_ec_data *ddata)
> +{
> + u64 flag;
> + int ret;
> +
> + ret = asus_dockram_access_ctl(ddata->ec.dockram, &flag, 0, 0);
> + if (ret)
> + return ret;
> +
> + flag &= ASUSEC_CTL_SUSB_MODE;
> + dev_info(&ddata->client->dev, "EC FW behaviour: %s\n",
> + flag ? "susb on when receive ec_req" :
> + "susb on when system wakeup");
> +
> + return 0;
> +}
> +
> +static int asus_ec_set_factory_mode(struct asus_ec_data *ddata,
> + enum asusec_mode fmode)
> +{
> + dev_info(&ddata->client->dev, "Entering %s mode.\n",
> + fmode == ASUSEC_MODE_FACTORY ? "factory" : "normal");
> +
> + return asus_dockram_access_ctl(ddata->ec.dockram, NULL,
> + ASUSEC_CTL_FACTORY_MODE,
> + fmode == ASUSEC_MODE_FACTORY ?
> + ASUSEC_CTL_FACTORY_MODE : 0);
Why not create make:
ASUSEC_MODE_FACTORY == ASUSEC_CTL_FACTORY_MODE
What happens to NORMAL?
> +}
> +
> +static int asus_ec_detect(struct asus_ec_data *ddata)
> +{
> + int ret;
> +
> + ret = asus_ec_reset(ddata);
> + if (ret)
> + goto err_exit;
> +
> + asus_ec_clear_buffer(ddata);
> +
> + ret = asus_ec_log_info(ddata, ASUSEC_DOCKRAM_INFO_MODEL, "Model",
> + &ddata->ec.model);
You can use 100-chars and make the code look beautiful! :)
> + if (ret)
> + goto err_exit;
> +
> + ret = asus_ec_log_info(ddata, ASUSEC_DOCKRAM_INFO_FW, "FW version",
> + NULL);
> + if (ret)
> + goto err_exit;
> +
> + ret = asus_ec_log_info(ddata, ASUSEC_DOCKRAM_INFO_CFGFMT, "Config format",
> + NULL);
> + if (ret)
> + goto err_exit;
> +
> + ret = asus_ec_log_info(ddata, ASUSEC_DOCKRAM_INFO_HW, "HW version",
> + NULL);
> + if (ret)
> + goto err_exit;
> +
> + /* Disable logging on next EC request */
Why, but why?
> + ddata->logging_disabled = true;
> +
> + /* Check and inform about EC firmware behavior */
> + ret = asus_ec_susb_on_status(ddata);
> + if (ret)
> + goto err_exit;
> +
> + ddata->ec.name = ddata->info->name;
> +
> + /* Some EC require factory mode to be set normal on each request */
> + if (ddata->info->fmode)
> + ret = asus_ec_set_factory_mode(ddata, ddata->info->fmode);
> +
> +err_exit:
> + if (ret)
> + dev_err(&ddata->client->dev, "failed to access EC: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static void asus_ec_handle_smi(struct asus_ec_data *ddata, unsigned int code)
> +{
> + switch (code) {
> + case ASUSEC_SMI_HANDSHAKE:
> + case ASUSEC_SMI_RESET:
> + asus_ec_detect(ddata);
> + break;
> + }
> +}
> +
> +static irqreturn_t asus_ec_interrupt(int irq, void *dev_id)
> +{
> + struct asus_ec_data *ddata = dev_id;
> + unsigned long notify_action;
> + int ret;
> +
> + ret = i2c_smbus_read_i2c_block_data(ddata->client, ASUSEC_READ_BUF,
> + ASUSEC_ENTRY_SIZE, ddata->ec_buf);
> + if (ret < ASUSEC_ENTRY_SIZE ||
> + !(ddata->ec_buf[ASUSEC_IRQ_STATUS] & ASUSEC_OBF_MASK))
Unwrap for readability.
Also, I think a comment would be helpful.
> + return IRQ_NONE;
> +
> + notify_action = ddata->ec_buf[ASUSEC_IRQ_STATUS];
> + if (notify_action & ASUSEC_SMI_MASK) {
> + unsigned int code = ddata->ec_buf[ASUSEC_SMI_CODE];
> +
> + asus_ec_handle_smi(ddata, code);
> +
> + notify_action |= code << 8;
> + }
> +
> + blocking_notifier_call_chain(&ddata->ec.notify_list,
> + notify_action, ddata->ec_buf);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void asus_ec_release_dockram_dev(void *client)
> +{
> + i2c_unregister_device(client);
> +}
> +
> +static struct i2c_client *devm_asus_dockram_get(struct device *dev)
> +{
> + struct i2c_client *parent = to_i2c_client(dev);
> + struct i2c_client *dockram;
> + struct dockram_ec_data *ddata;
> + int ret;
> +
> + dockram = i2c_new_ancillary_device(parent, "dockram",
> + parent->addr + 2);
Could we define a macro for the address offset '2' here to avoid using a magic
number?
> + if (IS_ERR(dockram))
> + return dockram;
> +
> + ret = devm_add_action_or_reset(dev, asus_ec_release_dockram_dev,
> + dockram);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + ddata = devm_kzalloc(&dockram->dev, sizeof(*ddata), GFP_KERNEL);
> + if (!ddata)
> + return ERR_PTR(-ENOMEM);
> +
> + i2c_set_clientdata(dockram, ddata);
> + mutex_init(&ddata->ctl_lock);
> +
> + return dockram;
> +}
> +
> +static const struct mfd_cell asus_ec_sl101_dock_mfd_devices[] = {
> + MFD_CELL_NAME("asus-transformer-ec-kbc"),
> +};
> +
> +static const struct mfd_cell asus_ec_tf101_dock_mfd_devices[] = {
> + MFD_CELL_BASIC("asus-transformer-ec-battery", NULL, NULL, 0, 1),
> + MFD_CELL_BASIC("asus-transformer-ec-charger", NULL, NULL, 0, 1),
> + MFD_CELL_BASIC("asus-transformer-ec-led", NULL, NULL, 0, 1),
> + MFD_CELL_NAME("asus-transformer-ec-keys"),
> + MFD_CELL_NAME("asus-transformer-ec-kbc"),
> +};
> +
> +static const struct mfd_cell asus_ec_tf201_pad_mfd_devices[] = {
> + MFD_CELL_NAME("asus-transformer-ec-battery"),
> + MFD_CELL_NAME("asus-transformer-ec-led"),
> +};
> +
> +static const struct mfd_cell asus_ec_tf600t_pad_mfd_devices[] = {
> + MFD_CELL_NAME("asus-transformer-ec-battery"),
> + MFD_CELL_NAME("asus-transformer-ec-charger"),
> + MFD_CELL_NAME("asus-transformer-ec-led"),
> +};
> +
> +static int asus_ec_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct asus_ec_data *ddata;
> + const struct mfd_cell *cells;
> + unsigned int num_cells;
> + unsigned long irqflags;
> + int ret;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_I2C_BLOCK))
> + return dev_err_probe(dev, -ENXIO,
> + "I2C bus is missing required SMBus block mode support\n");
> +
> + ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> + if (!ddata)
> + return -ENOMEM;
> +
> + ddata->info = device_get_match_data(dev);
> + if (!ddata->info)
> + return -ENODEV;
> +
> + switch (ddata->info->variant) {
> + case ASUSEC_SL101_DOCK:
> + cells = asus_ec_sl101_dock_mfd_devices;
> + num_cells = ARRAY_SIZE(asus_ec_sl101_dock_mfd_devices);
> + break;
> + case ASUSEC_TF101_DOCK:
> + cells = asus_ec_tf101_dock_mfd_devices;
> + num_cells = ARRAY_SIZE(asus_ec_tf101_dock_mfd_devices);
> + break;
> + case ASUSEC_TF201_PAD:
> + cells = asus_ec_tf201_pad_mfd_devices;
> + num_cells = ARRAY_SIZE(asus_ec_tf201_pad_mfd_devices);
> + break;
> + case ASUSEC_TF600T_PAD:
> + cells = asus_ec_tf600t_pad_mfd_devices;
> + num_cells = ARRAY_SIZE(asus_ec_tf600t_pad_mfd_devices);
> + break;
> + default:
> + return dev_err_probe(dev, -EINVAL,
> + "unknown device variant %d\n",
> + ddata->info->variant);
> + }
> +
> + i2c_set_clientdata(client, ddata);
> + ddata->client = client;
> +
> + ddata->ec.dockram = devm_asus_dockram_get(dev);
> + if (IS_ERR(ddata->ec.dockram))
> + return dev_err_probe(dev, PTR_ERR(ddata->ec.dockram),
> + "failed to get dockram\n");
> +
> + ddata->ecreq_gpio = devm_gpiod_get(dev, "request", GPIOD_OUT_LOW);
> + if (IS_ERR(ddata->ecreq_gpio))
> + return dev_err_probe(dev, PTR_ERR(ddata->ecreq_gpio),
> + "failed to get EC request GPIO\n");
> +
> + BLOCKING_INIT_NOTIFIER_HEAD(&ddata->ec.notify_list);
> + mutex_init(&ddata->ecreq_lock);
> +
> + asus_ec_signal_request(ddata);
> +
> + ret = asus_ec_detect(ddata);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to detect EC version\n");
> +
> + /*
> + * Systems using device tree should set up interrupt via DTS,
> + * the rest will use the default low interrupt.
> + */
> + irqflags = dev->of_node ? 0 : IRQF_TRIGGER_LOW;
> +
> + ret = devm_request_threaded_irq(dev, client->irq, NULL,
> + &asus_ec_interrupt,
> + IRQF_ONESHOT | irqflags,
> + client->name, ddata);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register IRQ\n");
> +
> + /* Parent I2C controller uses DMA, ASUS EC and child devices do not */
> + client->dev.coherent_dma_mask = 0;
> + client->dev.dma_mask = &client->dev.coherent_dma_mask;
> +
> + return devm_mfd_add_devices(dev, 0, cells, num_cells, NULL, 0, NULL);
> +}
> +
> +static const struct asus_ec_chip_info asus_ec_sl101_dock_data = {
> + .name = "dock",
> + .variant = ASUSEC_SL101_DOCK,
> + .fmode = ASUSEC_MODE_NONE,
> +};
> +
> +static const struct asus_ec_chip_info asus_ec_tf101_dock_data = {
> + .name = "dock",
> + .variant = ASUSEC_TF101_DOCK,
> + .fmode = ASUSEC_MODE_NONE,
> +};
> +
> +static const struct asus_ec_chip_info asus_ec_tf201_pad_data = {
> + .name = "pad",
> + .variant = ASUSEC_TF201_PAD,
> + .fmode = ASUSEC_MODE_NORMAL,
> +};
> +
> +static const struct asus_ec_chip_info asus_ec_tf600t_pad_data = {
> + .name = "pad",
> + .variant = ASUSEC_TF600T_PAD,
> + .fmode = ASUSEC_MODE_NORMAL,
> +};
Any reason not to just pass the identifier (variant) and add the name
and fmode attribues to the switch() above?
> +
> +static const struct of_device_id asus_ec_match[] = {
> + {
> + .compatible = "asus,sl101-ec-dock",
> + .data = &asus_ec_sl101_dock_data
> + }, {
> + .compatible = "asus,tf101-ec-dock",
> + .data = &asus_ec_tf101_dock_data
> + }, {
> + .compatible = "asus,tf201-ec-pad",
> + .data = &asus_ec_tf201_pad_data
> + }, {
> + .compatible = "asus,tf600t-ec-pad",
> + .data = &asus_ec_tf600t_pad_data
> + },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, asus_ec_match);
> +
> +static struct i2c_driver asus_ec_driver = {
> + .driver = {
> + .name = "asus-transformer-ec",
> + .of_match_table = asus_ec_match,
> + },
> + .probe = asus_ec_probe,
> +};
> +module_i2c_driver(asus_ec_driver);
> +
> +MODULE_AUTHOR("Michał Mirosław <mirq-linux@rere.qmqm.pl>");
> +MODULE_AUTHOR("Svyatoslav Ryhel <clamor95@gmail.com>");
> +MODULE_DESCRIPTION("ASUS Transformer's EC driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/asus-transformer-ec.h b/include/linux/mfd/asus-transformer-ec.h
> new file mode 100644
> index 000000000000..f085eea2193e
> --- /dev/null
> +++ b/include/linux/mfd/asus-transformer-ec.h
> @@ -0,0 +1,92 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __MFD_ASUS_TRANSFORMER_EC_H
> +#define __MFD_ASUS_TRANSFORMER_EC_H
> +
> +#include <linux/notifier.h>
> +#include <linux/platform_device.h>
> +
> +struct i2c_client;
> +
> +/**
> + * struct asusec_core - public part shared with all cells
> + *
> + * @model: firmware version running on the EC
> + * @name: prefix associated with the EC
> + * @dockram: pointer to Dockram's i2c_client
> + * @notify_list: notify list used by cells
> + */
> +struct asusec_core {
> + const char *model;
> + const char *name;
> + struct i2c_client *dockram;
> + struct blocking_notifier_head notify_list;
> +};
> +
> +#define ASUSEC_ENTRIES 0x100
> +#define ASUSEC_ENTRY_SIZE 32
> +#define ASUSEC_ENTRY_BUFSIZE (ASUSEC_ENTRY_SIZE + 1)
> +
> +/* interrupt sources */
> +#define ASUSEC_IRQ_STATUS 1
> +#define ASUSEC_OBF_MASK BIT(0)
> +#define ASUSEC_KEY_MASK BIT(2)
> +#define ASUSEC_KBC_MASK BIT(3)
> +#define ASUSEC_AUX_MASK BIT(5)
> +#define ASUSEC_SCI_MASK BIT(6)
> +#define ASUSEC_SMI_MASK BIT(7)
> +
> +/* SMI notification codes */
> +#define ASUSEC_SMI_CODE 2
> +#define ASUSEC_SMI_POWER_NOTIFY 0x31 /* USB cable plug event */
> +#define ASUSEC_SMI_HANDSHAKE 0x50 /* response to ec_req edge */
> +#define ASUSEC_SMI_WAKE 0x53
> +#define ASUSEC_SMI_RESET 0x5f
> +#define ASUSEC_SMI_ADAPTER_EVENT 0x60 /* charger to dock plug event */
> +#define ASUSEC_SMI_BACKLIGHT_ON 0x63
> +#define ASUSEC_SMI_AUDIO_DOCK_IN 0x70
> +
> +#define ASUSEC_SMI_ACTION(code) (ASUSEC_SMI_MASK | ASUSEC_OBF_MASK | \
> + (ASUSEC_SMI_##code << 8))
> +
> +/* control register [0x0a] layout */
> +#define ASUSEC_CTL_SIZE 8
> +
> +/*
> + * EC reports power from 40-pin connector in the LSB of the control
> + * register. The following values have been observed (xor 0x02):
> + *
> + * PAD-ec no-plug 0x40 / PAD-ec DOCK 0x20 / DOCK-ec no-plug 0x40
> + * PAD-ec AC 0x25 / PAD-ec DOCK+AC 0x24 / DOCK-ec AC 0x25
> + * PAD-ec USB 0x45 / PAD-ec DOCK+USB 0x24 / DOCK-ec USB 0x41
> + */
> +
> +#define ASUSEC_CTL_DIRECT_POWER_SOURCE BIT_ULL(0)
> +#define ASUSEC_STAT_CHARGING BIT_ULL(2)
> +#define ASUSEC_CTL_FULL_POWER_SOURCE BIT_ULL(5)
> +#define ASUSEC_CTL_SUSB_MODE BIT_ULL(9)
> +#define ASUSEC_CMD_SUSPEND_S3 BIT_ULL(33)
> +#define ASUSEC_CTL_TEST_DISCHARGE BIT_ULL(35)
> +#define ASUSEC_CMD_SUSPEND_INHIBIT BIT_ULL(37)
> +#define ASUSEC_CTL_FACTORY_MODE BIT_ULL(38)
> +#define ASUSEC_CTL_KEEP_AWAKE BIT_ULL(39)
> +#define ASUSEC_CTL_USB_CHARGE BIT_ULL(40)
> +#define ASUSEC_CTL_LED_BLINK BIT_ULL(40)
> +#define ASUSEC_CTL_LED_AMBER BIT_ULL(41)
> +#define ASUSEC_CTL_LED_GREEN BIT_ULL(42)
> +#define ASUSEC_CMD_SWITCH_HDMI BIT_ULL(56)
> +#define ASUSEC_CMD_WIN_SHUTDOWN BIT_ULL(62)
> +
> +#define ASUSEC_DOCKRAM_INFO_MODEL 0x01
> +#define ASUSEC_DOCKRAM_INFO_FW 0x02
> +#define ASUSEC_DOCKRAM_INFO_CFGFMT 0x03
> +#define ASUSEC_DOCKRAM_INFO_HW 0x04
> +#define ASUSEC_DOCKRAM_CONTROL 0x0a
> +#define ASUSEC_DOCKRAM_BATT_CTL 0x14
> +
> +#define ASUSEC_WRITE_BUF 0x64
> +#define ASUSEC_READ_BUF 0x6a
> +
> +int asus_dockram_access_ctl(struct i2c_client *client,
> + u64 *out, u64 mask, u64 xor);
> +
> +#endif /* __MFD_ASUS_TRANSFORMER_EC_H */
> --
> 2.51.0
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v3 3/4] arm64: qcom: ipq5018: Add GEPHY RX and TX clocks
From: Konrad Dybcio @ 2026-06-11 11:17 UTC (permalink / raw)
To: Paolo Abeni, george.moussalem, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Bjorn Andersson, Konrad Dybcio
Cc: netdev, devicetree, linux-kernel, linux-arm-msm, Dmitry Baryshkov
In-Reply-To: <850ba1ab-78fd-45b3-9411-97d50bb02ed9@redhat.com>
On 6/11/26 11:28 AM, Paolo Abeni wrote:
> On 6/5/26 2:41 PM, George Moussalem via B4 Relay wrote:
>> From: George Moussalem <george.moussalem@outlook.com>
>>
>> Add RX and TX clocks for the IPQ5018 GEPHY to enable the datapath.
>>
>> Fixes: f5f2b835e316 ("arm64: dts: qcom: ipq5018: Add GE PHY to internal mdio bus")
>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>
> I think here we need an explicit ack from arm people to take this patch
> (and the whole series).
This one should go through the qcom tree
Ordering shouldn't matter much, given the context suggests the
PHY either never worked or worked by luck
Konrad
^ permalink raw reply
* RE: [PATCH v1 1/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: Zhang Yi @ 2026-06-11 11:16 UTC (permalink / raw)
To: krzk
Cc: broonie, conor+dt, devicetree, krzk+dt, linux-sound, robh, tiwai,
zhangyi
In-Reply-To: <c6d33f8d-fcd3-4b23-81d0-6583d943b9d9@kernel.org>
> This was v1:
> https://lore.kernel.org/all/20260608083540.12581-1-zhangyi@everest-semi.com/
>
> Then you send v2 calling it v1:
> https://lore.kernel.org/all/20260609025605.16945-1-zhangyi@everest-semi.com/
>
> Then you sent it again:
> https://lore.kernel.org/all/20260609030623.17404-1-zhangyi@everest-semi.com/
>
> And now you send v4 (??!?) calling it v1:
> https://lore.kernel.org/all/20260611031824.4628-1-zhangyi@everest-semi.com/
>
> All within three days. And in the same time you never responded to
> actual feedback.
>
> This is not acceptable. Please stop spamming the list with the same
> version and respond to the feedback. I expect addressing EVERY email you
> received with reviews.
First of all, I apologize for sending several identical patches.
Actually, I haven't ignored your feedback;
I've responded to all the feedback you've provided so far, but I haven't received any further comments.
As for the several patches with identical content,
this is because the AI responded to the patches from the previous versions,
and my email indicated that my patches had been bounced. So I assumed you hadn't received them.
Also, I haven't heard back from you since I replied to your feedback, so I'm not sure if you saw my reply.
So I submitted another version of the patch and included an explanation in the comments addressing the feedback you provided earlier.
If there's any other feedback I may have overlooked, please let me know. Thank you.
By the way, if you can see this email, please reply so I can confirm that you can view what I sent.
^ permalink raw reply
* Re: [PATCH v5 4/4] clk: qcom: Add Global clock controller support on Qualcomm Shikra SoC
From: Konrad Dybcio @ 2026-06-11 11:15 UTC (permalink / raw)
To: Imran Shaik, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Richard Cochran,
Brian Masney
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, Krzysztof Kozlowski,
linux-arm-msm, linux-clk, devicetree, linux-kernel, netdev,
Dmitry Baryshkov
In-Reply-To: <20260608-shikra-gcc-rpmcc-clks-v5-4-94cefe092ee3@oss.qualcomm.com>
On 6/8/26 2:21 PM, Imran Shaik wrote:
> Add support for Global clock controller (GCC) on Qualcomm Shikra SoC.
>
> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 0/2] Add support for the QMP PCIe PHYs in Qualcomm IPQ9650
From: Vinod Koul @ 2026-06-11 11:15 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260602-ipq9650_pcie_phy-v1-0-d8c32a36dbd9@oss.qualcomm.com>
On 02-06-26, 14:40, Kathiravan Thirumoorthy wrote:
> Qualcomm's IPQ9650 SoC has 3 Gen3 dual lane and 2 Gen3 single lane
> controllers with the QMP PHYs. Unlike the PHYs in the other IPQ SoC,
> refgen supply is needed to bringup the PHYs. Both single and dual lane
> shares the same HW init sequence. So reuse the tables.
>
> Document the compatible along with refgen supply and add the phy driver
> support for it.
Please rebase this on phy-next tomorrow. It does not apply for me due to
changes applied ealier today
--
~Vinod
^ permalink raw reply
* Re: [PATCH V11 4/9] iio: imu: inv_icm42607: Add I2C and SPI For icm42607
From: Jonathan Cameron @ 2026-06-11 11:12 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260610175455.19006-5-macroalpha82@gmail.com>
On Wed, 10 Jun 2026 12:54:48 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add I2C and SPI driver support for InvenSense ICM-42607 devices.
> Add necessary Kconfig and Makefile to allow building of (incomplete)
> driver.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Some similar missing FIELD_PREP() comments. Not a bug, but
a readability issue that is easy to resolve.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 334264120b42..26dc09bbeaed 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
>
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
> new file mode 100644
> index 000000000000..2946d5465853
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +
> +#include "inv_icm42607.h"
> +
> +static int inv_icm42607_i2c_bus_setup(struct inv_icm42607_state *st)
> +{
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_clear_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
> + INV_ICM42607_INTF_CONFIG1_I3C_DDR_EN |
> + INV_ICM42607_INTF_CONFIG1_I3C_SDR_EN);
> + if (ret)
> + return ret;
> +
> + val = FIELD_PREP(INV_ICM42607_DRIVE_CONFIG2_I2C_MASK,
> + INV_ICM42607_SLEW_RATE_12_36NS);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_DRIVE_CONFIG2,
> + INV_ICM42607_DRIVE_CONFIG2_I2C_MASK, val);
> + if (ret)
> + return ret;
> +
> + return regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> + INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK,
> + INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_SPI_DIS);
FIELD_PREP() (see below)
> +}
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
> new file mode 100644
> index 000000000000..3485777ac5b6
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
> @@ -0,0 +1,104 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/spi/spi.h>
> +
> +#include "inv_icm42607.h"
> +
> +static int inv_icm42607_spi_bus_setup(struct inv_icm42607_state *st)
> +{
> + unsigned int val;
> + int ret;
> +
> + /* Only support 4-wire mode for now. */
> + ret = regmap_set_bits(st->map, INV_ICM42607_REG_DEVICE_CONFIG,
> + INV_ICM42607_DEVICE_CONFIG_SPI_AP_4WIRE);
> + if (ret)
> + return ret;
> +
> + ret = regmap_clear_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
> + INV_ICM42607_INTF_CONFIG1_I3C_DDR_EN |
> + INV_ICM42607_INTF_CONFIG1_I3C_SDR_EN);
> + if (ret)
> + return ret;
> +
> + val = FIELD_PREP(INV_ICM42607_DRIVE_CONFIG3_SPI_MASK,
> + INV_ICM42607_SLEW_RATE_2NS);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_DRIVE_CONFIG3,
> + INV_ICM42607_DRIVE_CONFIG3_SPI_MASK, val);
> + if (ret)
> + return ret;
> +
> + return regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> + INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK,
> + INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_I2C_DIS);
Should be a FIELD_PREP() for readability (so reviewer doesn't need to check
this field includes bit 0)
> +}
>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: pinctrl: qcom,pmic-gpio: Add Qualcomm PMK7750
From: sashiko-bot @ 2026-06-11 11:12 UTC (permalink / raw)
To: Krzysztof Kozlowski; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260611110708.69234-2-krzysztof.kozlowski@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Adding `qcom,pmk7750-gpio` to the standalone enum list without updating the corresponding `allOf` conditional blocks causes a schema validation hole. When used standalone, the compatible string bypasses generation-specific constraints (such as `gpio-line-names` and `gpio-reserved-ranges`) that apply to the PMK8550 generation it claims to be compatible with.
--
commit c696fcf54d49ee1cd5093d304f55dcf2aa2358e3
Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
dt-bindings: pinctrl: qcom,pmic-gpio: Add Qualcomm PMK7750
Document Qualcomm PMK7750 GPIO used with Eliza SoC. PMIC is almost the
same as PMK8550, thus compatible with it.
> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> index 386c31e9c52b8..f656c836896f5 100644
> --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> @@ -15,79 +15,85 @@ description:
>
> properties:
> compatible:
> - items:
> - - enum:
[ ... ]
> + oneOf:
> + - items:
> + - enum:
[ ... ]
> + - qcom,pmiv0104-gpio
> + - qcom,pmk8350-gpio
> + - qcom,pmk7750-gpio
[Severity: Medium]
Since qcom,pmk7750-gpio is added here to the standalone enum list, won't
standalone usage bypass the generation-specific constraints (such as the
gpio-line-names limit) defined in the allOf conditional block for the
PMK8550 generation?
Should qcom,pmk7750-gpio also be added to the allOf conditional block
containing qcom,pmk8550-gpio, or should it be removed from this standalone
enum list if the fallback is always expected?
> + - qcom,pmk8550-gpio
> + - qcom,pmk8850-gpio
[ ... ]
> + - items:
> + - enum:
> + - qcom,pmk7750-gpio
> + - const: qcom,pmk8550-gpio
> + - const: qcom,spmi-gpio
>
> reg:
> maxItems: 1
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611110708.69234-2-krzysztof.kozlowski@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Gaurav Kohli @ 2026-06-11 11:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano, Amit Kucheria,
Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <20260610-ocelot-of-stimulating-excellence-bcb0fe@quoll>
On 6/10/2026 1:01 PM, Krzysztof Kozlowski wrote:
> On Tue, Jun 09, 2026 at 03:52:56PM +0530, Gaurav Kohli wrote:
>> Document Qualcomm PAS remoteproc thermal mitigation properties used for
>> QMI-based throttling.
>>
>> Add:
>> - #cooling-cells (2 or 3)
>
> Why 2 or 3?
>
thanks Krzysztof for review, will use cooling-cells 3 only as it is
backword compatible and will add why part.
>> - tmd-names (thermal mitigation device names)
>
> Why? And where is this generic property defined? You cannot just
> sprinkle generic properties in random bindings.
>
Ack, will add why part.
These names are matched with the thermal mitigation device identifiers
populated by remote firmware over QMI and define mitigation devices are
exposed as cooling devices.
Without tmd-names in DT, it is unclear which index corresponds to which
binding. With #cooling-cells, tmd-names in DT provides an explicit
name-to-index mapping. Please suggest.
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH V11 3/9] iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
From: Jonathan Cameron @ 2026-06-11 11:09 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260610175455.19006-4-macroalpha82@gmail.com>
On Wed, 10 Jun 2026 12:54:47 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add the core component of a new inv_icm42607 driver. This includes
> a few setup functions and the full register definition in the
> header file.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Hi Chris,
A couple more minor things from a fresh read.
Thanks
Jonathan
> ---
> drivers/iio/imu/inv_icm42607/inv_icm42607.h | 334 ++++++++++++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_core.c | 197 +++++++++++
> 2 files changed, 531 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
>
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> new file mode 100644
> index 000000000000..716fc0f1c3fd
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> new file mode 100644
> index 000000000000..334264120b42
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +
> +static int inv_icm42607_setup(struct inv_icm42607_state *st,
> + inv_icm42607_bus_setup inv_icm42607_bus_setup)
> +{
> + const struct device *dev = regmap_get_device(st->map);
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(st->map, INV_ICM42607_REG_WHOAMI, &val);
> + if (ret)
> + return ret;
> +
> + /* Warn, but don't fail. */
> + if (val != st->hw->whoami)
> + dev_warn(dev, "Unknown whoami %#02x expected %#02x (%s)\n",
> + val, st->hw->whoami, st->hw->name);
> +
> + ret = regmap_write(st->map, INV_ICM42607_REG_SIGNAL_PATH_RESET,
> + INV_ICM42607_SIGNAL_PATH_RESET_SOFT_RESET);
> + if (ret)
> + return ret;
> +
> + fsleep(INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC);
> +
> + /*
> + * No polling interval specified in datasheet, so use reset time as
> + * polling interval and 10x reset time as timeout period.
> + */
> + ret = regmap_read_poll_timeout(st->map, INV_ICM42607_REG_INT_STATUS,
> + val, val & INV_ICM42607_INT_STATUS_RESET_DONE,
> + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC),
> + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC * 10));
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "reset error, reset done bit not set\n");
> +
> + /* Sync the regcache again after a reset. */
> + regcache_mark_dirty(st->map);
> + ret = regcache_sync(st->map);
Sashiko raised the point that you don't have a writeable register list for the regmap
and so potentially we at very least write a bunch of stuff that isn't needed.
I doubt it's actually a problem or you would have seen it, but nice little optimization
to reduce what is written.
> + if (ret)
> + return ret;
> +
> + ret = inv_icm42607_bus_setup(st);
> + if (ret)
> + return ret;
> +
> + ret = regmap_set_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> + INV_ICM42607_INTF_CONFIG0_SENSOR_DATA_ENDIAN);
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
> + INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK,
> + INV_ICM42607_INTF_CONFIG1_CLKSEL_PLL);
That should have a FIELD_PREP() to save us having to got check that
the MASK includes the LSB.
> + if (ret)
> + return ret;
> +
> + return inv_icm42607_set_conf(st, st->hw->conf);
> +}
> +
> +MODULE_AUTHOR("InvenSense, Inc.");
> +MODULE_DESCRIPTION("InvenSense ICM-42607x device driver");
Why does it have a trailing x? Whilst a wild card is less harmful
here than in many places I'd still drop it.
> +MODULE_LICENSE("GPL");
> +MODULE_IMPORT_NS("IIO_INV_SENSORS_TIMESTAMP");
Do we need this yet? I think it only gets used later, in which case
move it to the first patch that needs this.
^ permalink raw reply
* Re: [PATCH v5 3/4] clk: qcom: smd-rpm: Add missing RF_CLK1/RF_CLK2 clocks support on Agatti
From: Konrad Dybcio @ 2026-06-11 11:09 UTC (permalink / raw)
To: Imran Shaik, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Richard Cochran,
Brian Masney
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, Krzysztof Kozlowski,
linux-arm-msm, linux-clk, devicetree, linux-kernel, netdev
In-Reply-To: <31525025-333e-4845-9dfa-df68a3df3752@oss.qualcomm.com>
On 6/11/26 12:52 PM, Imran Shaik wrote:
>
>
> On 11-06-2026 03:10 pm, Konrad Dybcio wrote:
>> On 6/8/26 2:21 PM, Imran Shaik wrote:
>>> Add support for missing RF_CLK1/RF_CLK2 clocks on Qualcomm Agatti (QCM2290)
>>> SoC.
>>>
>>> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
>>> ---
>>> drivers/clk/qcom/clk-smd-rpm.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
>>> index 103db984a40b950bd33fba668a292be46af6326e..0b624ed4715c75042b92ec49c073b281533cace4 100644
>>> --- a/drivers/clk/qcom/clk-smd-rpm.c
>>> +++ b/drivers/clk/qcom/clk-smd-rpm.c
>>> @@ -495,6 +495,7 @@ DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(rf_clk2, 5, 19200000);
>>> DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(rf_clk3, 6, 19200000);
>>> DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(ln_bb_clk, 8, 19200000);
>>> +DEFINE_CLK_SMD_RPM_XO_BUFFER_PREFIX(38m4_, rf_clk2, 5, 38400000);
>>> DEFINE_CLK_SMD_RPM_XO_BUFFER_PREFIX(38m4_, rf_clk3, 6, 38400000);
>>> DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(cxo_d0, 1, 19200000);
>>> @@ -1262,6 +1263,10 @@ static struct clk_smd_rpm *qcm2290_clks[] = {
>>> [RPM_SMD_QDSS_A_CLK] = &clk_smd_rpm_branch_qdss_a_clk,
>>> [RPM_SMD_LN_BB_CLK2] = &clk_smd_rpm_ln_bb_clk2,
>>> [RPM_SMD_LN_BB_CLK2_A] = &clk_smd_rpm_ln_bb_clk2_a,
>>> + [RPM_SMD_RF_CLK1] = &clk_smd_rpm_rf_clk1,
>>> + [RPM_SMD_RF_CLK1_A] = &clk_smd_rpm_rf_clk1_a,
>>
>> Is RF_CLK1 19.2 MHz (with the other RFCLKs being 38.4) on purpose?
>>
>
> Yes Konrad, as per the hardware connectivity, RF_CLK1 runs at 19.2 MHz, while the other RF clocks operate at 38.4 MHz.
OK thanks
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v5 phy-next 16/16] MAINTAINERS: expand Lynx 28G entry to cover Lynx 10G SerDes
From: Ioana Ciornei @ 2026-06-11 11:07 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, Tanjeff Moos, linux-kernel,
devicetree, Conor Dooley, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260610151952.2141019-17-vladimir.oltean@nxp.com>
On Wed, Jun 10, 2026 at 06:19:52PM +0300, Vladimir Oltean wrote:
> The lynx-28g and lynx-10g drivers share code and hardware architecture,
> so let them be covered by a single MAINTAINERS entry.
>
> Add myself as a second maintainer alongside Ioana Ciornei.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
^ permalink raw reply
* [PATCH v2] dt-bindings: pinctrl: qcom,pmic-gpio: Add Qualcomm PMK7750
From: Krzysztof Kozlowski @ 2026-06-11 11:07 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-gpio, devicetree, linux-kernel
Cc: Krzysztof Kozlowski, Abel Vesa
Document Qualcomm PMK7750 GPIO used with Eliza SoC. PMIC is almost the
same as PMK8550, thus compatible with it.
Cc: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
1. Add fallback compatible.
---
.../bindings/pinctrl/qcom,pmic-gpio.yaml | 152 +++++++++---------
1 file changed, 79 insertions(+), 73 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
index 386c31e9c52b..f656c836896f 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
@@ -15,79 +15,85 @@ description:
properties:
compatible:
- items:
- - enum:
- - qcom,pm2250-gpio
- - qcom,pm660-gpio
- - qcom,pm660l-gpio
- - qcom,pm6125-gpio
- - qcom,pm6150-gpio
- - qcom,pm6150l-gpio
- - qcom,pm6350-gpio
- - qcom,pm6450-gpio
- - qcom,pm7250b-gpio
- - qcom,pm7325-gpio
- - qcom,pm7550-gpio
- - qcom,pm7550ba-gpio
- - qcom,pm8005-gpio
- - qcom,pm8018-gpio
- - qcom,pm8019-gpio
- - qcom,pm8038-gpio
- - qcom,pm8058-gpio
- - qcom,pm8150-gpio
- - qcom,pm8150b-gpio
- - qcom,pm8150l-gpio
- - qcom,pm8226-gpio
- - qcom,pm8350-gpio
- - qcom,pm8350b-gpio
- - qcom,pm8350c-gpio
- - qcom,pm8450-gpio
- - qcom,pm8550-gpio
- - qcom,pm8550b-gpio
- - qcom,pm8550ve-gpio
- - qcom,pm8550vs-gpio
- - qcom,pm8916-gpio
- - qcom,pm8917-gpio
- - qcom,pm8921-gpio
- - qcom,pm8937-gpio
- - qcom,pm8941-gpio
- - qcom,pm8950-gpio
- - qcom,pm8953-gpio
- - qcom,pm8994-gpio
- - qcom,pm8998-gpio
- - qcom,pma8084-gpio
- - qcom,pmc8180-gpio
- - qcom,pmc8180c-gpio
- - qcom,pmc8380-gpio
- - qcom,pmcx0102-gpio
- - qcom,pmd8028-gpio
- - qcom,pmh0101-gpio
- - qcom,pmh0104-gpio
- - qcom,pmh0110-gpio
- - qcom,pmi632-gpio
- - qcom,pmi8950-gpio
- - qcom,pmi8994-gpio
- - qcom,pmi8998-gpio
- - qcom,pmih0108-gpio
- - qcom,pmiv0104-gpio
- - qcom,pmk8350-gpio
- - qcom,pmk8550-gpio
- - qcom,pmk8850-gpio
- - qcom,pmm8155au-gpio
- - qcom,pmm8654au-gpio
- - qcom,pmp8074-gpio
- - qcom,pmr735a-gpio
- - qcom,pmr735b-gpio
- - qcom,pmr735d-gpio
- - qcom,pms405-gpio
- - qcom,pmx55-gpio
- - qcom,pmx65-gpio
- - qcom,pmx75-gpio
- - qcom,pmxr2230-gpio
-
- - enum:
- - qcom,spmi-gpio
- - qcom,ssbi-gpio
+ oneOf:
+ - items:
+ - enum:
+ - qcom,pm2250-gpio
+ - qcom,pm660-gpio
+ - qcom,pm660l-gpio
+ - qcom,pm6125-gpio
+ - qcom,pm6150-gpio
+ - qcom,pm6150l-gpio
+ - qcom,pm6350-gpio
+ - qcom,pm6450-gpio
+ - qcom,pm7250b-gpio
+ - qcom,pm7325-gpio
+ - qcom,pm7550-gpio
+ - qcom,pm7550ba-gpio
+ - qcom,pm8005-gpio
+ - qcom,pm8018-gpio
+ - qcom,pm8019-gpio
+ - qcom,pm8038-gpio
+ - qcom,pm8058-gpio
+ - qcom,pm8150-gpio
+ - qcom,pm8150b-gpio
+ - qcom,pm8150l-gpio
+ - qcom,pm8226-gpio
+ - qcom,pm8350-gpio
+ - qcom,pm8350b-gpio
+ - qcom,pm8350c-gpio
+ - qcom,pm8450-gpio
+ - qcom,pm8550-gpio
+ - qcom,pm8550b-gpio
+ - qcom,pm8550ve-gpio
+ - qcom,pm8550vs-gpio
+ - qcom,pm8916-gpio
+ - qcom,pm8917-gpio
+ - qcom,pm8921-gpio
+ - qcom,pm8937-gpio
+ - qcom,pm8941-gpio
+ - qcom,pm8950-gpio
+ - qcom,pm8953-gpio
+ - qcom,pm8994-gpio
+ - qcom,pm8998-gpio
+ - qcom,pma8084-gpio
+ - qcom,pmc8180-gpio
+ - qcom,pmc8180c-gpio
+ - qcom,pmc8380-gpio
+ - qcom,pmcx0102-gpio
+ - qcom,pmd8028-gpio
+ - qcom,pmh0101-gpio
+ - qcom,pmh0104-gpio
+ - qcom,pmh0110-gpio
+ - qcom,pmi632-gpio
+ - qcom,pmi8950-gpio
+ - qcom,pmi8994-gpio
+ - qcom,pmi8998-gpio
+ - qcom,pmih0108-gpio
+ - qcom,pmiv0104-gpio
+ - qcom,pmk8350-gpio
+ - qcom,pmk7750-gpio
+ - qcom,pmk8550-gpio
+ - qcom,pmk8850-gpio
+ - qcom,pmm8155au-gpio
+ - qcom,pmm8654au-gpio
+ - qcom,pmp8074-gpio
+ - qcom,pmr735a-gpio
+ - qcom,pmr735b-gpio
+ - qcom,pmr735d-gpio
+ - qcom,pms405-gpio
+ - qcom,pmx55-gpio
+ - qcom,pmx65-gpio
+ - qcom,pmx75-gpio
+ - qcom,pmxr2230-gpio
+ - enum:
+ - qcom,spmi-gpio
+ - qcom,ssbi-gpio
+ - items:
+ - enum:
+ - qcom,pmk7750-gpio
+ - const: qcom,pmk8550-gpio
+ - const: qcom,spmi-gpio
reg:
maxItems: 1
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 5/8] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Konrad Dybcio @ 2026-06-11 11:05 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: <20260526-hamoa_pdc-v2-5-f6857af1ce91@oss.qualcomm.com>
On 5/26/26 12:54 PM, Maulik Shah wrote:
> All PDC irqchip supports pass through mode in which both Direct SPIs and
> GPIO IRQs (as SPIs) are sent to GIC without latching at PDC.
>
> Newer PDCs (v3.0 onwards) also support additional secondary controller mode
> where PDC latches GPIO IRQs and sends to GIC as level type IRQ. Direct SPIs
> still works same as pass through mode without latching at PDC even in
> secondary controller mode.
>
> All the SoCs so far default uses pass through mode with the exception of
> x1e. x1e PDC may be set to secondary controller mode for builds on CRD
> boards whereas it may be set to pass through mode for IoT-EVK boards.
> The mode configuration is done in firmware and initially shipped windows
> firmware did not have SCM interface to read or modify the PDC mode.
> Later only write access is opened up for non secure world.
>
> Using the write access available add changes to modify the PDC mode to
> pass through mode via SCM write. When the write fails (on older firmware)
> assume to work in secondary mode.
>
> Co-developed-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
[...]
> +static inline bool pdc_pin_uses_seconary_mode(int pin_out)
Please add a comment somewhere near here, repeating what you said in
the previous commit message (about the SPIs being mapped first, followed
by GPIO-as-SPIs)
Konrad
^ permalink raw reply
* Re: [PATCH 2/2] phy: nuvoton: Add MA35D1 USB2 OTG PHY driver
From: Vinod Koul @ 2026-06-11 11:04 UTC (permalink / raw)
To: Joey Lu
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jacky Huang, Shan-Chun Hung, linux-phy, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260604101220.1092822-3-a0987203069@gmail.com>
On 04-06-26, 18:12, Joey Lu wrote:
> Add a PHY driver for the USB 2.0 PHYs in the Nuvoton MA35D1 SoC,
> intended for use with the EHCI and OHCI host controllers.
>
> The MA35D1 SoC has two USB ports:
>
> - USB0: an OTG port shared between a DWC2 gadget controller and
> EHCI0/OHCI0 host controllers. A hardware mux automatically routes
> the physical USB0 signals to the appropriate controller based on the
> USB ID pin state. The DWC2 IP is device-only in hardware,
> so host-mode operation on USB0 is handled entirely by EHCI0/OHCI0.
>
> - USB1: a dedicated host-only port served by EHCI1/OHCI1.
>
> The driver implements:
> - Power-On Reset sequence with a guard that skips re-initialization if
> the PHY is already operational. This protects PHY0 when the DWC2
> gadget driver has already run its own init before EHCI0 probes.
> - Optional resistor calibration trim via nuvoton,rcalcode.
> - Optional over-current detect polarity via nuvoton,oc-active-high.
> - For PHY0 only: a USB role switch that exposes the hardware ID pin
> state (PWRONOTP[16]).
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/phy/nuvoton/Kconfig | 15 ++
> drivers/phy/nuvoton/Makefile | 1 +
> drivers/phy/nuvoton/phy-ma35d1-otg.c | 264 +++++++++++++++++++++++++++
> 3 files changed, 280 insertions(+)
> create mode 100644 drivers/phy/nuvoton/phy-ma35d1-otg.c
>
> diff --git a/drivers/phy/nuvoton/Kconfig b/drivers/phy/nuvoton/Kconfig
> index d02cae2db315..5fdd13f841e7 100644
> --- a/drivers/phy/nuvoton/Kconfig
> +++ b/drivers/phy/nuvoton/Kconfig
> @@ -10,3 +10,18 @@ config PHY_MA35_USB
> help
> Enable this to support the USB2.0 PHY on the Nuvoton MA35
> series SoCs.
> +
> +config PHY_MA35_USB_OTG
> + tristate "Nuvoton MA35 USB2.0 OTG PHY driver"
> + depends on ARCH_MA35 || COMPILE_TEST
> + depends on OF
> + select GENERIC_PHY
> + select MFD_SYSCON
> + select USB_ROLE_SWITCH
> + help
> + Enable this to support the USB2.0 OTG PHY on the Nuvoton MA35
> + series SoCs. This driver handles PHY initialization for the
> + EHCI/OHCI host controllers, including per-PHY power-on reset,
> + resistor calibration trim, and over-current polarity
> + configuration. For the OTG port (PHY0), it also monitors the
> + USB ID pin and registers a USB role switch.
> diff --git a/drivers/phy/nuvoton/Makefile b/drivers/phy/nuvoton/Makefile
> index 2937e3921898..3ecd76f35d7c 100644
> --- a/drivers/phy/nuvoton/Makefile
> +++ b/drivers/phy/nuvoton/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
>
> obj-$(CONFIG_PHY_MA35_USB) += phy-ma35d1-usb2.o
> +obj-$(CONFIG_PHY_MA35_USB_OTG) += phy-ma35d1-otg.o
Have you considered reusing usb2 driver with a different power_on
function? Or handle the differences internally in the driver. There are
few similarities in two and some things are different
--
~Vinod
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: pse-pd: add Realtek/Broadcom PSE MCU support
From: Oleksij Rempel @ 2026-06-11 11:03 UTC (permalink / raw)
To: Jonas Jelonek
Cc: Kory Maincent, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, devicetree, linux-kernel, Daniel Golle,
Bjørn Mork
In-Reply-To: <20260608205758.1830521-1-jelonek.jonas@gmail.com>
Hi Jonas,
On Mon, Jun 08, 2026 at 08:57:55PM +0000, Jonas Jelonek wrote:
> This series adds a PSE-PD driver for the microcontroller (MCU) that fronts
> the PSE silicon on a range of managed switches, together with its DT
> binding.
>
> Hardware model
> ==============
>
> These boards do not expose the PSE chips to the host directly. A small
> microcontroller sits on an I2C/SMBus or UART bus and manages one or more PSE
> chips behind it; the host CPU only ever talks to that MCU, using a fixed
> 12-byte request/response protocol with a trailing checksum. The PSE silicon
> never appears on the bus.
>
> The same protocol family is used by MCUs fronting Realtek PSE chips
> (RTL8238B, RTL8239, RTL8239C) and Broadcom PSE chips (BCM59111, BCM59121),
> diverging in opcode numbering and a few response layouts. The driver
> abstracts that behind a per-dialect opcode table and parser hooks, selected
> by the compatible. The specific PSE chip behind the MCU is detected at
> runtime and only influences per-chip constants (power scaling and the
> per-port cap).
>
> Why the compatible names the protocol, not the chip
> ===================================================
>
> The compatibles are "realtek,pse-mcu-rtk" and "realtek,pse-mcu-bcm". This is
> a deliberate choice and the part most likely to raise questions, so the
> reasoning up front.
>
> The node names the protocol dialect, not a part:
>
> - The DT node describes the MCU, not a PSE chip: the PSE chips are behind
> the MCU and never appear on the bus, so naming the node after one (e.g.
> "realtek,rtl8239") would describe hardware that isn't at that address.
>
> - The PSE chips are, in principle, usable without this MCU (host-driven
> directly) - different hardware with a different programming model that
> would warrant its own binding. Claiming the PSE-chip compatibles here
> would collide with that.
>
> - Naming the MCU silicon is equally wrong: these are ordinary
> general-purpose microcontrollers (GigaDevice, Nuvoton, ...) that vary
> across boards and are not dedicated to this application.
>
> - What is fixed, and all the driver needs at DT-parse time, is the
> protocol dialect, so the compatible encodes exactly that. The two
> dialects share one protocol family and one binding, kept in a single
> "realtek" vendor namespace because this MCU front-end is found almost
> exclusively on Realtek-based switches; a "-rtk"/"-bcm" suffix selects
> the dialect. This follows the "google,cros-ec-*" pattern: a compatible
> for a firmware/protocol interface implemented by varying
> microcontrollers.
>
> One compatible per dialect spans both transports:
>
> - The 12-byte wire protocol is identical over I2C/SMBus and UART; only the
> plumbing differs (SMBus vs native framing on I2C, baud rate on UART),
> and the transport is already expressed structurally by the node's parent
> bus (i2c@... vs serial@...). A "-i2c"/"-uart" suffix would only
> duplicate that, for a protocol that does not change across transports.
>
> - This is the multi-transport model used by e.g. "bosch,bmi160" (one
> compatible, separate i2c and spi drivers binding it), rather than the
> cros-ec model of per-transport compatibles - cros-ec splits because its
> on-wire framing genuinely differs per bus, which is not the case here.
>
> The binding documents both points as well.
>
> Testing
> =======
>
> - Linksys LGS328MPCv2 (RTL8238B, I2C)
> - Zyxel GS1900-10HP A1 (BCM59121, UART)
> - Zyxel GS1900-10HP B1 (RTL8238B, UART)
> - Zyxel XMG1915-10EP (RTL8239C, UART)
> - Zyxel XS1930-12HP (RTL8239, SMBus)
>
Thank you for your work!
Overall, LGTM. Can you please take a look at this report:
https://sashiko.dev/#/patchset/20260608205758.1830521-1-jelonek.jonas%40gmail.com
kzalloc_obj - seems to be a false positive. Some other have good points.
Best Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH V11 0/9] Add Invensense ICM42607
From: Jonathan Cameron @ 2026-06-11 10:59 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260610175455.19006-1-macroalpha82@gmail.com>
On Wed, 10 Jun 2026 12:54:44 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add support for the ICM42607 IMU. This sensor shares the same
> functionality but a different register layout with the existing
> ICM42600.
>
> This driver should work with the ICM42607 and ICM42607P over both I2C
> and SPI, however only the ICM42607P over I2C could be tested.
Hi Chris,
Just a quick reminder to check if there is useful feedback at:
https://sashiko.dev/#/patchset/20260610175455.19006-1-macroalpha82%40gmail.com
I didn't look into most of the but the last one about no avail mask bits
being set for gyro channels was easy to verify as correct and suggests
a testing gap.
Jonathan
^ permalink raw reply
* Re: [PATCH 0/9] media/arm64: HM1092 IR camera and ASUS Zenbook A14 (X1P42100) camera support
From: Ramshouriesh R @ 2026-06-11 10:55 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab, Bryan O'Donoghue,
Loic Poulain, Bryan O'Donoghue, Vinod Koul, Neil Armstrong,
Aleksandrs Vinarskis, linux-arm-msm, devicetree, linux-kernel,
linux-media, linux-phy
In-Reply-To: <8be0a964-e2fc-4c0a-a5ca-0e9e42b3d747@linaro.org>
On Thu, 11 Jun 2026 at 15:31, Vladimir Zapolskiy
<vladimir.zapolskiy@linaro.org> wrote:
> This patch should be removed from consideration, since it is not based on
> the upstream codebase.
>
> I'd suggest you to upstream the sensor driver only through linux-media, which
> is patches 2/9 and 3/8, all other changes should go only after it.
Will do, thanks. This is my first submission, so I hadn't realised the
sensor driver should go on its own. For v2, I'll send the HM1092 binding
and driver as a standalone linux-media series, and then I'll post the
A14 DTS and
PHY enablement separately once the driver and its prerequisites have landed
--
^ 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