* Re: [PATCH v1 3/3] ASoC: qcom: qdsp6: generalize GPR service domain
From: Srinivas Kandagatla @ 2026-06-18 21:45 UTC (permalink / raw)
To: Ajay Kumar Nandam, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel,
mohammad.rafi.shaik, Pratyush Meduri
In-Reply-To: <20260609064038.492641-4-ajay.nandam@oss.qualcomm.com>
On 6/9/26 7:40 AM, Ajay Kumar Nandam wrote:
> Use each GPR domain advertised by the qcom APR/GPR layer when building
> APM/PRM packets and add explicit dest_domain parameters to all AudioReach
> alloc helpers.
> Legacy helpers fall back to ADSP while graphs, media-format, and
> shared-memory packets reuse gdev->domain_id for modem targets.
Why?
>
I dont understand what are you trying to do, commit log itself is not
clear and does explain the problem that you are solving or what exactly
> Co-developed-by: Pratyush Meduri <mpratyus@qti.qualcomm.com>
> Signed-off-by: Pratyush Meduri <mpratyus@qti.qualcomm.com>
> Signed-off-by: Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com>
> ---
> sound/soc/qcom/qdsp6/audioreach.c | 112 +++++++++++++++++++++---------
> sound/soc/qcom/qdsp6/audioreach.h | 23 +++---
> sound/soc/qcom/qdsp6/q6apm.c | 48 +++++++++----
> sound/soc/qcom/qdsp6/q6prm.c | 19 ++---
> 4 files changed, 138 insertions(+), 64 deletions(-)
>
^ permalink raw reply
* Re: [PATCH RFC] dt-bindings: sound: Convert cirrus,cs35l36 to DT schema
From: Rhodes, David @ 2026-06-18 21:38 UTC (permalink / raw)
To: david, David Rhodes, Richard Fitzgerald, Liam Girdwood,
Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
patches, Bjorn Helgaas
Cc: linux-sound, devicetree, linux-kernel, phone-devel
In-Reply-To: <20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz>
On 6/18/26 9:33 AM, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> Convert CS35L36 Speaker Amplifier.
>
> Changes:
> - maintainers email to the generic Cirrus email
> - Both the codec and downstream worked just fine without
> VP-supply provided. Align with datasheet for similar models.
> - add dai-common.yaml to cover for '#sound-dai-cells',
> 'sound-name-prefix'
>
> Co-developed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
Reviewed-by: David Rhodes <David.Rhodes@cirrus.com>
Thanks,
David
^ permalink raw reply
* Re: [PATCH v1 2/2] ASoC: qcom: sc8280xp: add Shikra EVK machine variants
From: Srinivas Kandagatla @ 2026-06-18 21:34 UTC (permalink / raw)
To: Ajay Kumar Nandam, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel,
Mohammad Rafi Shaik
In-Reply-To: <20260611112946.954172-3-ajay.nandam@oss.qualcomm.com>
On 6/11/26 12:29 PM, Ajay Kumar Nandam wrote:
> 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.
This patch is doing too many things you need to seperate them in to
seperate patches.
> - 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;
How is this related to this patch?
> };
>
> 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;
> +
This has nothing to do with what this patch is doing.
> 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,
this is not related to shikra support
> 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) {
Looks like you are mixing multiple changes in single patch, please
seperate them.
> 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;
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: magnetometer: add support for Melexis MLX90393
From: Nikhil Gautam @ 2026-06-18 21:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-iio, jic23, dlechner, nuno.sa, andy, robh, krzk+dt,
conor+dt, devicetree, linux-kernel
In-Reply-To: <ajRGf0YT-fCZA1ih@ashevche-desk.local>
On 19-06-2026 12:56 am, Andy Shevchenko wrote:
> On Thu, Jun 18, 2026 at 09:31:41PM +0530, Nikhil Gautam wrote:
Hi Andy,
Thank you very much for taking the time to do such a thorough review of
this patch series.
Your detailed comments and suggestions are very helpful.
I'll address the issues you've pointed out, update the cover letter to
better explain the design decisions,
and incorporate the requested coding style and API changes in the next
revision.
I appreciate your review and feedback.
>> +config MLX90393
>> + tristate "MELEXIS MLX90393 3-axis magnetometer sensor"
>> + depends on I2C
> Why not a regmap?
The MLX90393 uses both register-based and command-based transactions.
Since regmap does not naturally model the command-based interface,
using it would require workarounds such as virtual registers or bypass
paths.
A custom transport abstraction is therefore simpler and better suited
for this device.
I already discussed this on thread, Link :
https://lore.kernel.org/linux-iio/20260423121834.4244-1-nikhilgtr@gmail.com/
>> +#ifndef MLX90393_H
>> +#define MLX90393_H
>>
>> +#include <linux/bitops.h>
>> +#include <linux/bits.h>
> Not required, it's covered by bitops.h.
Noted. Thanks
>> +#include <linux/types.h>
> ...
>
>> +#define MLX90393_MEASURE_ALL \
>> + (MLX90393_MEASURE_TEMP | MLX90393_MEASURE_X | \
>> + MLX90393_MEASURE_Y | MLX90393_MEASURE_Z)
> Split logically.
>
> #define MLX90393_MEASURE_ALL \
> (MLX90393_MEASURE_TEMP | \
> MLX90393_MEASURE_X | MLX90393_MEASURE_Y | MLX90393_MEASURE_Z)
>
> Or just a (long) single line.
Agreed. Thanks
>> + int (*xfer)(void *context, const u8 *tx, int tx_len,
>> + u8 *rx, int rx_len);
> One line, it's only 81 characters.
Agreed Thanks
>> +};
>> +
>> +int mlx90393_core_probe(struct device *dev,
> You want forward declaration for struct device.
Agreed, Thanks
> + array_size.h
> + bitfield.h // FIELD_GET()
>
>> +#include <linux/delay.h>
> + errno.h // -Exxx
>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
> + types.h // uXX
>
>> +#include <linux/unaligned.h>
>> +#include <linux/units.h>
> IWYU, please (just pointed out a few missing above, there are more).
Sure, will do it.
>> +/* Datasheet: Table no.17 */
>> +static const int mlx90393_scale_table[MLX90393_AXIS_MAX]
>> + [MLX90393_GAIN_MAX]
>> + [MLX90393_RES_MAX] = {
> This is broken indentation.
Noted, Thanks
>> +/*
>> + * Calculate total conversion time in microseconds.
>> + *
>> + * Formula derived from datasheet timing equations.
> Which formula? Where is datasheet? What if I have no access to it?
> Always repeat the important details in the comment in the code.
Got it, will add all details from datasheet
>> + */
>> +
> Unneeded blank line.
Noted, Thanks
>> +static int mlx90393_get_tconv_us(struct mlx90393_data *data)
>> +{
>> + const int osr = data->osr;
>> + const int osr2 = data->osr2;
>> + const int df = data->dig_filt;
>> +
>> + int tconvm;
>> + int tconvt;
>> +
>> + int m = 3; /* X,Y,Z */
>> +
>> + /*
>> + * Datasheet:
> What chapter/section/table name? Page number?
Sure will add.
>> + * TCONVM = 67 + 64 * 2^OSR * (2 + 2^DIG_FILT)
> What does this cryptic message mean? Please, accompany this with more English
> plain text.
Agreed, Thanks
>> +static int mlx90393_xfer(struct mlx90393_data *data,
>> + const u8 *tx, int tx_len,
>> + u8 *rx, int rx_len)
>> +{
>> + return data->ops->xfer(data->bus_context,
>> + tx, tx_len,
>> + rx, rx_len);
> It's perfectly one line.
>
> Also you might want to have
>
> if (!...->xfer)
> return -E...;
>
>> +}
Noted, Thanks
>> +static int mlx90393_check_status(u8 cmd, u8 status)
>> +{
>> + /* Always validate error bit */
>> + if (status & MLX90393_STATUS_ERROR)
>> + return -EIO;
>> +
>> + switch (cmd & MLX90393_CMD_MASK) {
>> + case MLX90393_CMD_RM:
>> + /*
>> + * D1:D0 indicates response availability
>> + * 00 means invalid/no measurement
>> + */
>> + if ((status & MLX90393_STATUS_RESP) == 0)
>> + return -EIO;
>> + return 0;
>> + case MLX90393_CMD_RT:
>> + /* Reset acknowledge */
>> + if (!(status & MLX90393_STATUS_RT))
> For sake of consistency you might want to also compare to 0 here.
Thanks, I'll make that change.
>> +static int mlx90393_write_reg(struct mlx90393_data *data, u8 reg, u16 val)
> Here the variable is named 'reg' there is 'reg_addr'. As I can see the code is
> full of inconsistencies (like 2+ people with different style guidelines wrote
> it). Please. take your time and check the code and make it consistent.
Got it, will make it consistent across whole file.
>> +{
>> + u8 tx[4];
>> + u8 status;
>> + int ret;
>> +
>> + tx[0] = MLX90393_CMD_WR;
>> + put_unaligned_be16(val, &tx[1]);
>> + /* Register address is encoded in bits [7:2] */
>> + tx[3] = reg << 2;
>> +
>> + ret = mlx90393_xfer(data, tx, sizeof(tx), &status, 1);
>> + if (ret)
>> + return ret;
>> +
>> + return mlx90393_check_status(tx[0], status);
>> +}
>> +
>> +static int mlx90393_update_bits(struct mlx90393_data *data, u8 reg_addr,
>> + u16 mask, u16 val)
>> +{
>> + u16 reg;
>> + int ret;
>> +
>> + ret = mlx90393_read_reg(data, reg_addr, ®);
>> + if (ret)
>> + return ret;
>>
>> + reg &= ~mask;
>> + reg |= (val << __ffs(mask)) & mask;
> bitfield.h has macros for this.
Noted, Thanks
>> +static int mlx90393_find_osr(int val, int *osr)
>> +{
>> + for (unsigned int i = 0; i < MLX90393_OSR_MAX; i++)
>> + if (mlx90393_osr_avail[i] == val) {
>> + *osr = i;
>> + return 0;
>> + }
> Missing {}.
Agreed, removed intentionally as single statement, will add as per
guidelines all the places
where needed
>> +static int mlx90393_get_temp_osr2(struct mlx90393_data *data, int *val)
>> +{
>> + *val = mlx90393_osr2_avail[data->osr2];
> Missing blank line.
Noted, Thanks
>> int mlx90393_write_raw(struct iio_dev *indio_dev,
>> + const struct iio_chan_spec *chan,
>> + int val, int val2,
>> + long mask)
>> +{
>> + struct mlx90393_data *data = iio_priv(indio_dev);
>> + int ret;
> Not needed, return directly.
Agreed.
>> + /* Datasheet: 22124 millidegC/LSB */
>> + /* Datasheet: temperature offset */
> Again, at least put a page, better to have Section/Table/et cetera title.
Sure, will do it
> + *vals = mlx90393_osr_avail;
> + *type = IIO_VAL_INT;
> + *length = MLX90393_OSR_MAX;
> + }
> + return IIO_AVAIL_LIST;
> +
> + default:
> + return -EINVAL;
> + }
>> + return -EINVAL;
> Besides missing blank line, this is actually a dead code.
Correct, this will never be called. will fix
>> +static int mlx90393_init(struct mlx90393_data *data)
>> +{
>> + int ret;
>> + u16 reg;
>> +
>> + /* Exit mode */
>> + ret = mlx90393_write_cmd(data, MLX90393_CMD_EX);
>> + if (ret)
>> + return ret;
>> +
>> + /* Wait for device comes out of reset */
> Datasheet? Empirical?
Agreed, Thanks
>> + fsleep(1000);
> 1 * USEC_PER_MSEC
> (will require time.h to be included).
Noted, Thanks
>> + /* Reset device */
>> + ret = mlx90393_write_cmd(data, MLX90393_CMD_RT);
>> + if (ret)
>> + return ret;
>> +
>> + /* Wait for device to reset */
>> + fsleep(6000);
> As per above.
This delay is not 6000ms it is 1500ms as per datasheet, forgot to update
in code
Thanks for pointing out, will update all places delay requirement with
datasheet reference.
>> +int mlx90393_core_probe(struct device *dev,
>> + const struct mlx90393_transfer_ops *ops,
>> + void *context)
>> +{
>> + struct iio_dev *indio_dev;
>> + struct mlx90393_data *data;
>> + int ret;
>> +
>> + indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
>> + if (!indio_dev)
>> + return -ENOMEM;
>> +
>> + data = iio_priv(indio_dev);
>> + devm_mutex_init(dev, &data->lock);
> Nonsense. If we don't check the return code of devm_*(), there is a little
> reason to use it in the first place. But then one should not use devm further.
> Easy fix: check for returned errors.
Agreed, I'll fix this in the next revision.
>> + data->dev = dev;
>> + data->ops = ops;
>> + data->bus_context = context;
>> +
>> + indio_dev->name = "mlx90393";
>> + indio_dev->info = &mlx90393_info;
>> + indio_dev->modes = INDIO_DIRECT_MODE;
>> + indio_dev->channels = mlx90393_channels;
>> + indio_dev->num_channels = ARRAY_SIZE(mlx90393_channels);
>> +
>> + ret = mlx90393_init(data);
>> + if (ret)
>> + return dev_err_probe(dev, ret, "failed to initialize device\n");
>> +
>> + return devm_iio_device_register(dev, indio_dev);
>> +}
>> +EXPORT_SYMBOL_GPL(mlx90393_core_probe);
> Make it namespaces.
Okay, will do it
> + array_size.h
> + errno.h
>
>> +#include <linux/module.h>
>> +#include <linux/i2c.h>
>> +#include <linux/mod_devicetable.h>
> ...and so on.
>
> Same, follow the IWYU principle.
Got it, will take care
>> +/*
>> + * MLX90393 commands use repeated-start transfers where
>> + * every command is followed by a status/data response.
>> + */
>> +static int mlx90393_i2c_xfer(void *context,
>> + const u8 *tx, int tx_len,
>> + u8 *rx, int rx_len)
>> +{
>> + struct i2c_client *client = context;
>> + int ret;
>> + struct i2c_msg msgs[2] = {
>> + [0] = {
>> + .addr = client->addr,
>> + .len = tx_len,
>> + .buf = (u8 *)tx,
>> + },
>> + [1] = {
>> + .addr = client->addr,
>> + .flags = I2C_M_RD,
>> + .len = rx_len,
>> + .buf = rx,
>> + },
>> + };
>> +
>> + ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
>> + if (ret != ARRAY_SIZE(msgs))
>> + return ret < 0 ? ret : -EIO;
> Please, make this to be the regular pattern
>
> if (ret < 0)
> return ret;
> if (ret != ARRAY_SIZE(msgs))
> return -EIO;
>
>> + return 0;
>> +}
Thanks, I'll make that change.
>> +static struct i2c_driver mlx90393_i2c_driver = {
>> + .driver = {
>> + .name = "mlx90393",
>> + .of_match_table = mlx90393_of_match,
>> + },
>> + .probe = mlx90393_i2c_probe,
>> +};
> Remove this blank line.
Noted
>> +module_i2c_driver(mlx90393_i2c_driver);
>>
Thanks & Regards,
Nikhil
^ permalink raw reply
* Re: [PATCH v2 0/2] iio: magnetometer: add support for Melexis MLX90393
From: Nikhil Gautam @ 2026-06-18 20:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-iio, jic23, dlechner, nuno.sa, andy, robh, krzk+dt,
conor+dt, devicetree, linux-kernel
In-Reply-To: <ajQ_9uHMcTY2Hnmx@ashevche-desk.local>
On 19-06-2026 12:29 am, Andy Shevchenko wrote:
> On Thu, Jun 18, 2026 at 09:31:39PM +0530, Nikhil Gautam wrote:
>> Hi,
>>
>> This series adds initial Industrial I/O subsystem support for the
>> Melexis MLX90393 3-axis magnetometer and temperature sensor.
>>
>> The MLX90393 supports both I2C and SPI interfaces. This series
>> implements support for the I2C interface while keeping the driver
>> structure transport-independent to simplify future SPI support.
>>
>> Currently supported features:
>>
>> * Raw magnetic field measurements for X/Y/Z axes
>> * Raw temperature measurements
>> * Configurable gain/scale selection
>> * Configurable oversampling ratio
>> * Direct mode operation through the IIO subsystem
>> * I2C interface support
>>
>> The driver has been tested on Raspberry Pi 5 hardware using an
>> MLX90393 sensor connected over I2C. Magnetic field and temperature
>> measurements were verified through the IIO sysfs interface.
> This doesn't answer to two important questions:
> - why do we need a brand new driver?
> Can't one of the existing be updated to cover this HW?
>
> - where to find the datasheet? Any Links or other means to get it?
Hi Andy,
I looked at the existing magnetometer drivers in the IIO subsystem,
but none support the MLX90393 or a sufficiently similar register map and
command protocol.
The MLX90393 uses its own command-based interface and device-specific
configuration and conversion logic,
so extending an existing driver would require substantial changes with
little code reuse.
Therefore, I chose to implement it as a separate driver.
The datasheet is publicly available from Melexis:
Link:
https://media.melexis.com/-/media/files/documents/datasheets/mlx90393-datasheet-melexis.pdf
I'll include the datasheet link and clarify the rationale for introducing
a new driver in the cover letter of the next revision.
Thanks,
Nikhil
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: magnetometer: add support for Melexis MLX90393
From: Nikhil Gautam @ 2026-06-18 20:22 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-iio, jic23, dlechner, nuno.sa, andy, robh, krzk+dt,
conor+dt, devicetree, linux-kernel
In-Reply-To: <ajQpq1yzA-ig2c7s@monoceros>
On 18-06-2026 10:55 pm, Uwe Kleine-König wrote:
> Hello,
>
> On Thu, Jun 18, 2026 at 09:31:41PM +0530, Nikhil Gautam wrote:
> Please make that:
>
> { .name = "mlx90393" },
Thanks for pointing this out. I'll update it in v3.
> I guess you want
>
> .id_table = mlx90393_id,
Yes, that's correct. I'll add the missing .id_table entry in the next
version.
Thanks for the review!
Best regards,
Nikhil
^ permalink raw reply
* Re: [PATCH] dt-bindings: spi: st,stm32-qspi: Add power-domains property
From: Mark Brown @ 2026-06-18 20:05 UTC (permalink / raw)
To: Patrice Chotard
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Christophe Kerello, linux-spi, devicetree,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260618-add_power_domain_for_qpsi-v1-1-4d7e57bcfb9a@foss.st.com>
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]
On Thu, Jun 18, 2026 at 08:46:35AM +0200, Patrice Chotard wrote:
> STM32 QSPI may be in a power domain. Allow a single 'power-domains'
> entry for STM32 QSPI.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 04/12] i3c: master: Add support for devices using SETAASA
From: Frank Li @ 2026-06-18 20:00 UTC (permalink / raw)
To: sashiko-reviews
Cc: Akhil R, robh, Frank.Li, linux-i3c, devicetree, linux-hwmon,
conor+dt
In-Reply-To: <20260616101919.299491F000E9@smtp.kernel.org>
On Tue, Jun 16, 2026 at 10:19:18AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
>
> New issues:
> - [High] Missing CCC command whitelisting in I3C master drivers causes entire bus initialization to fail.
> - [High] Premature SETAASA broadcast preempts and breaks SETDASA initialization.
> - [High] Missing physical device address reset (RSTDAA) on SETAASA attach failure allows address collisions.
>
> Pre-existing issues:
> - [High] Bypassing PID validation allows duplicate PIDs, triggering a pre-existing Use-After-Free during teardown.
> --
>
> commit ef82dd52670ca8654bff7067823722f8e77933d1
> Author: Akhil R <akhilrajeev@nvidia.com>
>
> i3c: master: Add support for devices using SETAASA
>
> Add support for devices using SETAASA, such as SPD5118 and SPD5108
> attached to DDR5 memory modules that do not support ENTDAA. Follow the
> guidelines proposed by the MIPI Discovery and Configuration
> Specification [1] for discovering such devices.
>
> SETAASA (Set All Addresses to Static Address) differs from standard I3C
> address assignment that uses ENTDAA or SETDASA to assign dynamic
> addresses. Devices using SETAASA assign their pre-defined static addresses
> as their dynamic addresses during DAA, and it is not mandatory for these
> devices to implement standard CCC commands like GETPID, GETDCR, or GETBCR.
> For such devices, it is generally recommended to issue SETHID (specified
> by JEDEC JESD300) as a prerequisite for SETAASA to stop HID bit flipping.
>
> Link: https://www.mipi.org/mipi-disco-for-i3c-download
>
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > index f0e05bcac26da..557332d932576 100644
> > --- a/drivers/i3c/master.c
> > +++ b/drivers/i3c/master.c
>
> [ ... ]
>
> > @@ -1852,6 +1898,22 @@ static int i3c_master_early_i3c_dev_add(struct i3c_master_controller *master,
> > if (ret)
> > goto err_free_dev;
> >
> > + /*
> > + * For devices using SETAASA instead of ENTDAA, the address is statically
> > + * assigned. Update the dynamic address to the provided static address.
> > + * Reattach the I3C device after updating the dynamic address with the same
> > + * static address. It is not mandatory for such devices to implement CCC
> > + * commands like GETPID, GETDCR etc. Hence, we can return after reattaching.
> > + */
> > + if (i3cdev->boardinfo->static_addr_method & I3C_ADDR_METHOD_SETAASA) {
> > + i3cdev->info.dyn_addr = i3cdev->boardinfo->static_addr;
> > + ret = i3c_master_reattach_i3c_dev(i3cdev, 0);
> > + if (ret)
> > + goto err_detach_dev;
> ^^^^^^^^
>
> [Severity: High]
> Does skipping the physical device address reset (RSTDAA) here allow address
> collisions?
>
> If i3c_master_reattach_i3c_dev() fails for a SETAASA device, the code jumps to
> err_detach_dev. Unlike the SETDASA error path which jumps to err_rstdaa to
> issue a directed RSTDAA command and clear the dynamic address, this path
> leaves the physical device active at that address.
>
> Meanwhile, i3c_master_detach_i3c_dev() frees the address slot in the master's
> software state. During subsequent Dynamic Address Assignment (DAA), the master
> may assign this supposedly "free" address to another device, resulting in two
> physical devices responding to the same dynamic address.
Look AI correct, please check it.
Frank
>
> [ ... ]
>
> > @@ -2206,6 +2268,12 @@ static int i3c_master_bus_init(struct i3c_master_controller *master)
> > if (ret)
> > goto err_bus_cleanup;
> >
> > + if (master->addr_method & I3C_ADDR_METHOD_SETAASA) {
> > + ret = i3c_master_setaasa_locked(master);
> > + if (ret)
> > + goto err_bus_cleanup;
> > + }
> > +
>
> [Severity: High]
> Will this unconditional broadcast of SETAASA cause the entire bus initialization
> to fail on certain controllers?
>
> Several I3C master drivers (e.g., Cadence, SVC, Renesas) implement a strict
> whitelist via the supports_ccc_cmd callback. Because these whitelists were
> not updated to allow I3C_CCC_SETAASA (0x29) and I3C_CCC_VENDOR(0, true)
> (SETHID), the master driver returns -EOPNOTSUPP. This error propagates up
> through i3c_master_setaasa_locked(), causing i3c_master_bus_init() to
> immediately abort.
>
> [Severity: High]
> Does this premature SETAASA broadcast break SETDASA initialization?
>
> By broadcasting SETAASA before processing devices that require SETDASA:
>
> list_for_each_entry(i3cboardinfo, &master->boardinfo.i3c, node) {
> ...
> if (i3cboardinfo->static_addr)
> i3c_master_early_i3c_dev_add(master, i3cboardinfo);
> }
>
> any device with a static address will accept the broadcast and adopt its
> static address as its dynamic address. If a device was configured to use
> SETDASA, it will erroneously accept the SETAASA broadcast.
>
> When i3c_master_early_i3c_dev_add() subsequently attempts to issue the
> directed SETDASA command, the device already has an assigned dynamic address
> and will ignore the command. This causes the software state to desynchronize
> from the physical device state. The MIPI I3C spec explicitly mandates that
> SETDASA commands must be sent prior to the SETAASA command.
>
> > /*
> > * Reserve init_dyn_addr first, and then try to pre-assign dynamic
>
> [ ... ]
>
> > @@ -2724,6 +2799,9 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
> > return -EINVAL;
> > }
> >
> > + /* Update the address methods required for device discovery */
> > + master->addr_method |= boardinfo->static_addr_method;
> > +
> > boardinfo->pid = ((u64)reg[1] << 32) | reg[2];
> >
> > if ((boardinfo->pid & GENMASK_ULL(63, 48)) ||
> ^^^^^^^^
>
> [Severity: High]
> This isn't a bug introduced by this patch, but does allowing duplicate PIDs
> (such as PID=0 for SETAASA devices) trigger a pre-existing Use-After-Free during
> teardown?
>
> Since SETAASA devices don't require standard CCC commands like GETPID,
> configuring multiple SETAASA devices with an identical dummy PID (like PID=0)
> passes the validation here.
>
> When i3c_master_register_new_i3c_devs() is called, dev_set_name() assigns
> identical sysfs names to these duplicate devices. device_register() then fails
> with -EEXIST. In the error path, put_device() is called, freeing desc->dev,
> but desc->dev is not set to NULL.
>
> During bus teardown in i3c_master_unregister_i3c_devs(), the core iterates
> over all devices, sees the non-NULL dangling pointer, and calls
> device_is_registered(&desc->dev->dev), leading to a Use-After-Free.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=4
^ permalink raw reply
* Re: [PATCH v2 03/10] tests: asm: Introduce treehdr_vers macro
From: Herve Codina @ 2026-06-18 19:55 UTC (permalink / raw)
To: David Gibson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <ajPFLjQ96nmsPLp2@zatzit>
Hi David,
On Thu, 18 Jun 2026 20:15:10 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Apr 09, 2026 at 01:54:19PM +0200, Herve Codina wrote:
> > tree.S is used to generate custom dtbs. It uses the treehdr macro to
> > build the header part.
> >
> > The current definition of this macro doesn't allow to set custom
> > settings related to version fields.
> >
> > In order to easily generate some dtb with custom version values without
> > duplicating the full header computation, introduce the treehdr_vers
> > macro.
> >
> > The modification doesn't introduce any functional changes.
> >
> > Signed-off-by: Herve Codina <herve.codina@bootlin.com>
>
> I just killed the not-very-portable trees.S in the main git tree, so
> this will need reworking for the new treegen.c system.
Killing trees.S has been a good idea.
Even if it implies more work on my side, I can only agree with this
decision.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: Conor Dooley @ 2026-06-18 19:54 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <BXIzXc2sQ5SGynZ1chd-pw@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2850 bytes --]
On Thu, Jun 18, 2026 at 09:59:00PM +0300, Stefan Dösinger wrote:
> Am Donnerstag, 18. Juni 2026, 00:23:56 Ostafrikanische Zeit schrieben Sie:
>
> > Do you actually need an aux bus here though? Since you have to add
> > simple-mfd for your the syscon-reboot and simple-mfd is a real bus, can you
> > set the reset controller up with an mfd_cell + devm_mfd_add_devices()
> > instead?
>
> I'll have to read up on devm_mfd_add_devices; The aux bus was the suggestion
> of Philipp Zabel. At first sight it sounds to me like they do fairly similar
> things. I don't see any precedence for [devm_]mfd_add_devices in drivers/clk/.
I think you don't see it because the driver calling mfd_add_devices()
probably isn't in drivers/clk and probably also uses an mfd_cell for the
clock.
There's some in drivers/soc and some in drivers/mfd (I'll be honest and
admit to not knowing what actually drives the placement of the mfd
driver).
I think aux bus makes perfect sense when you have a clock/reset
controller, but once you start expanding past that and you have reboot
or hwmon or hwspinlock then mfd starts to make sense.
>
> Whatever way I go I'd like to use the same for all 3 clock/reset controllers.
> So far I only made topclk a simple-mfd. I recently stumbled upon spinlock
> registers in matrixclk, so I guess I can justify a simple-mfd there too. For
Just to note, simple-mfd is used when you have child nodes. You don't
need simple-mfd if a device fills multiple roles but doesn't have
children.
Your hwspinlock may not require a child node at all, you can just put
#hwlock-cells into the main node and use mfd_add_devices().
You'd then have topclock that is a syscon + simple-mfd, matrixclk that is
a syscon and lsp that's using the aux bus. The topclock and matrixclock
would have dedicated and trivial drivers somewhere that have the mfd_cells
and call mfd_add_devices(). The fact that topclock would be a simple-mfd
has basically no impact - I think the difference is that topclock will
call of_platform_populate() where matrixclk will not.
Probably the compatibles you've chosen start to make less sense at this
point though, but probably "topclk" and "matrixclk" are not what the
documentation for this device calls these register regions?
> lspclk all I can see is clocks and resets and I ran out of unknown registers
> in there.
I think the priority is having something that reflects the hardware
accurately, I wouldn't compromise on that just to have the same design
for all three drivers.
I guess the problem you have is that the reset driver is shared? You can
always have more than one way to probe a driver. Because I messed up
stuff in the past, reset-mpfs.c has both aux bus and mfd probing in it,
which could serve as an example for how to have both in one file.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 03/12] i3c: master: Support ACPI enumeration of child devices
From: Frank Li @ 2026-06-18 19:53 UTC (permalink / raw)
To: sashiko-reviews
Cc: Akhil R, linux-hwmon, conor+dt, linux-i3c, Frank.Li, devicetree,
robh
In-Reply-To: <20260616101515.34CA61F000E9@smtp.kernel.org>
On Tue, Jun 16, 2026 at 10:15:14AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] devm_kzalloc allocated 'boardinfo' is leaked for every ACPI child node that is ignored because it lacks I2C/I3C resources.
> --
>
> commit 9a388c2056a553d628ce4b8b623a812d4aa08951
> Author: Akhil R <akhilrajeev@nvidia.com>
>
> i3c: master: Support ACPI enumeration of child devices
>
> This commit adds support for describing I3C and I2C devices via ACPI tables,
> rather than relying solely on the device tree reg property. It implements
> reading _ADR and LVR properties from ACPI resources to retrieve the static
> address and other device properties.
>
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > index 3b19a5e8f46d0..f0e05bcac26da 100644
> > --- a/drivers/i3c/master.c
> > +++ b/drivers/i3c/master.c
>
> [ ... ]
>
> > @@ -2708,6 +2762,74 @@ static int i3c_master_add_dev(struct i3c_master_controller *master,
> > return ret;
> > }
> >
> > +#ifdef CONFIG_ACPI
> > +static int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
> > + struct fwnode_handle *fwnode)
> > +{
> > + struct acpi_device *adev = to_acpi_device_node(fwnode);
> > + acpi_bus_address adr;
> > + u32 reg[3] = { 0 };
> > + int ret;
> > +
> > + /*
> > + * If the ACPI table entry has _ADR method, it's an I3C device.
> > + * Otherwise it may be an I2C device described by an I2cSerialBus
> > + * resource. If no I2cSerialBus resource is found, ignore the entry.
> > + */
> > + if (!acpi_has_method(adev->handle, "_ADR")) {
> > + ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
> > + if (ret == -ENODEV)
> > + return 0;
>
> [Severity: Medium]
> Does this leak the boardinfo allocated in i3c_master_add_i2c_boardinfo()?
>
> If an ACPI child lacks an _ADR method, i3c_master_add_i2c_boardinfo()
> unconditionally allocates boardinfo using devm_kzalloc().
>
> If the node also lacks an I2cSerialBus resource, i3c_acpi_add_i2c_boardinfo()
> returns -ENODEV. This causes i3c_master_add_i2c_boardinfo() to return -ENODEV
> without freeing the allocated boardinfo.
>
> Because we catch -ENODEV here and return 0, the overall bus probe continues
> and ultimately succeeds. This means the devres-allocated memory stays tied
> to the master device, leaking sizeof(struct i2c_dev_boardinfo) for every
> ignored ACPI child node.
Is it true?
Frank
>
> > +
> > + return ret;
> > + }
> > +
> > + adr = acpi_device_adr(adev);
>
> [ ... ]
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=3
^ permalink raw reply
* Re: [PATCH v4 07/12] i3c: dw-i3c-master: Add SETAASA as supported CCC
From: Frank Li @ 2026-06-18 19:43 UTC (permalink / raw)
To: Akhil R
Cc: Alexandre Belloni, Frank Li, Miquel Raynal, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Guenter Roeck, Philipp Zabel,
Jon Hunter, Thierry Reding, linux-i3c, devicetree, linux-hwmon,
linux-tegra, linux-kernel
In-Reply-To: <20260616095429.3947205-8-akhilrajeev@nvidia.com>
On Tue, Jun 16, 2026 at 09:54:21AM +0000, Akhil R wrote:
> Add SETAASA and SETHID to the supported list of CCC commands for
> DesignWare I3C host controller.
>
> SETAASA is a broadcast command that assigns predefined static addresses
> to all I3C devices on the bus.
>
> SETHID is to stop HID bit flipping by the SPD Hub to which the SPD devices
> are connected. It is a prerequisite command to be sent before SETAASA as
> recommended by JESD300-5 and JESD403 sideband bus specifications.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/i3c/master/dw-i3c-master.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index 971b429b76bc..3e510fddf06c 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
> @@ -309,6 +309,8 @@ static bool dw_i3c_master_supports_ccc_cmd(struct i3c_master_controller *m,
> case I3C_CCC_GETSTATUS:
> case I3C_CCC_GETMXDS:
> case I3C_CCC_GETHDRCAP:
> + case I3C_CCC_SETAASA:
> + case I3C_CCC_VENDOR(0, true): /* SETHID */
> return true;
> default:
> return false;
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v4 03/12] i3c: master: Support ACPI enumeration of child devices
From: Frank Li @ 2026-06-18 19:41 UTC (permalink / raw)
To: Akhil R
Cc: Alexandre Belloni, Frank Li, Miquel Raynal, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Guenter Roeck, Philipp Zabel,
Jon Hunter, Thierry Reding, linux-i3c, devicetree, linux-hwmon,
linux-tegra, linux-kernel
In-Reply-To: <20260616095429.3947205-4-akhilrajeev@nvidia.com>
On Tue, Jun 16, 2026 at 09:54:17AM +0000, Akhil R wrote:
> Although the existing subsystem allows host controllers to register
> through the ACPI table, it was not possible to describe I3C or I2C
> devices when using ACPI. This is because the driver relied on the reg
> property to retrieve the PID, static address, etc., whereas ACPI uses
> _ADR or serial resources to describe such devices.
>
> Read _ADR and LVR from ACPI resources and extract the data as per the
> ACPI specification for an I3C bus. Also read mipi-i3c-static-address as
> per the MIPI DISCO specifications [1] to get the static address to be
> used.
>
> Enable describing I3C or I2C devices in the ACPI table. This is required
> if the device uses a static address or if it needs device-specific
> properties.
>
> [1] https://www.mipi.org/mipi-disco-for-i3c-download
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/i3c/master.c | 149 ++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 141 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index 3b19a5e8f46d..f0e05bcac26d 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
> @@ -5,6 +5,7 @@
> * Author: Boris Brezillon <boris.brezillon@bootlin.com>
> */
>
> +#include <linux/acpi.h>
> #include <linux/atomic.h>
> #include <linux/bitmap.h>
> #include <linux/bug.h>
> @@ -2596,6 +2597,55 @@ EXPORT_SYMBOL_GPL(i3c_master_do_daa);
>
> #define OF_I3C_REG1_IS_I2C_DEV BIT(31)
>
> +#ifdef CONFIG_ACPI
> +static int i3c_acpi_get_i2c_resource(struct acpi_resource *ares, void *data)
> +{
> + struct i2c_dev_boardinfo *boardinfo = data;
> + struct acpi_resource_i2c_serialbus *sb;
> +
> + if (boardinfo->base.addr || !i2c_acpi_get_i2c_resource(ares, &sb))
> + return 1;
> +
> + boardinfo->base.addr = sb->slave_address;
> + if (sb->access_mode == ACPI_I2C_10BIT_MODE)
> + boardinfo->base.flags |= I2C_CLIENT_TEN;
> +
> + boardinfo->lvr = sb->lvr;
> +
> + return 1;
> +}
> +
> +static int i3c_acpi_add_i2c_boardinfo(struct i2c_dev_boardinfo *boardinfo,
> + struct fwnode_handle *fwnode)
> +{
> + struct acpi_device *adev = to_acpi_device_node(fwnode);
> + LIST_HEAD(resources);
> + int ret;
> +
> + boardinfo->base.fwnode = acpi_fwnode_handle(adev);
> + acpi_set_modalias(adev, dev_name(&adev->dev), boardinfo->base.type,
> + sizeof(boardinfo->base.type));
> +
> + ret = acpi_dev_get_resources(adev, &resources,
> + i3c_acpi_get_i2c_resource, boardinfo);
> + if (ret < 0)
> + return ret;
> +
> + acpi_dev_free_resource_list(&resources);
> +
> + if (!boardinfo->base.addr)
> + return -ENODEV;
> +
> + return 0;
> +}
> +#else
> +static inline int i3c_acpi_add_i2c_boardinfo(struct i2c_dev_boardinfo *boardinfo,
> + struct fwnode_handle *fwnode)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
> static int
> i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
> struct fwnode_handle *fwnode, u32 *reg)
> @@ -2612,6 +2662,13 @@ i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
> ret = of_i2c_get_board_info(dev, to_of_node(fwnode), &boardinfo->base);
> if (ret)
> return ret;
> +
> + /* LVR is encoded in reg[2] for Device Tree. */
> + boardinfo->lvr = reg[2];
> + } else if (is_acpi_device_node(fwnode)) {
> + ret = i3c_acpi_add_i2c_boardinfo(boardinfo, fwnode);
> + if (ret)
> + return ret;
> } else {
> return -EINVAL;
> }
> @@ -2626,9 +2683,6 @@ i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
> return -EOPNOTSUPP;
> }
>
> - /* LVR is encoded in reg[2]. */
> - boardinfo->lvr = reg[2];
> -
> list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
> fwnode_handle_get(fwnode);
>
> @@ -2683,8 +2737,8 @@ i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
> return 0;
> }
>
> -static int i3c_master_add_dev(struct i3c_master_controller *master,
> - struct fwnode_handle *fwnode)
> +static int i3c_master_add_of_dev(struct i3c_master_controller *master,
> + struct fwnode_handle *fwnode)
> {
> u32 reg[3];
> int ret;
> @@ -2708,6 +2762,74 @@ static int i3c_master_add_dev(struct i3c_master_controller *master,
> return ret;
> }
>
> +#ifdef CONFIG_ACPI
> +static int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
> + struct fwnode_handle *fwnode)
> +{
> + struct acpi_device *adev = to_acpi_device_node(fwnode);
> + acpi_bus_address adr;
> + u32 reg[3] = { 0 };
> + int ret;
> +
> + /*
> + * If the ACPI table entry has _ADR method, it's an I3C device.
> + * Otherwise it may be an I2C device described by an I2cSerialBus
> + * resource. If no I2cSerialBus resource is found, ignore the entry.
> + */
> + if (!acpi_has_method(adev->handle, "_ADR")) {
> + ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
> + if (ret == -ENODEV)
> + return 0;
> +
> + return ret;
> + }
> +
> + adr = acpi_device_adr(adev);
> +
> + /* For I3C devices, _ADR will have the 48 bit PID of the device */
> + reg[1] = upper_32_bits(adr);
> + reg[2] = lower_32_bits(adr);
> +
> + fwnode_property_read_u32(fwnode, "mipi-i3c-static-address", ®[0]);
> +
> + return i3c_master_add_i3c_boardinfo(master, fwnode, reg);
> +}
> +
> +static u8 i3c_acpi_i2c_get_lvr(struct i2c_client *client)
> +{
> + struct acpi_device *adev = to_acpi_device_node(client->dev.fwnode);
> + struct i2c_dev_boardinfo boardinfo = {};
> + LIST_HEAD(resources);
> + int ret;
> + u8 lvr;
> +
> + lvr = I3C_LVR_I2C_INDEX(2) | I3C_LVR_I2C_FM_MODE;
> +
> + ret = acpi_dev_get_resources(adev, &resources,
> + i3c_acpi_get_i2c_resource, &boardinfo);
> + if (ret < 0)
> + return lvr;
> +
> + if (boardinfo.base.addr)
> + lvr = boardinfo.lvr;
> +
> + acpi_dev_free_resource_list(&resources);
> +
> + return lvr;
> +}
> +#else
> +static inline int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
> + struct fwnode_handle *fwnode)
> +{
> + return -ENODEV;
> +}
> +
> +static inline u8 i3c_acpi_i2c_get_lvr(struct i2c_client *client)
> +{
> + return I3C_LVR_I2C_INDEX(2) | I3C_LVR_I2C_FM_MODE;
> +}
> +#endif
> +
> static int fwnode_populate_i3c_bus(struct i3c_master_controller *master)
> {
> struct device *dev = &master->dev;
> @@ -2719,7 +2841,13 @@ static int fwnode_populate_i3c_bus(struct i3c_master_controller *master)
> return 0;
>
> fwnode_for_each_available_child_node_scoped(fwnode, child) {
> - ret = i3c_master_add_dev(master, child);
> + if (is_of_node(child))
> + ret = i3c_master_add_of_dev(master, child);
> + else if (is_acpi_device_node(child))
> + ret = i3c_master_add_acpi_dev(master, child);
> + else
> + continue;
> +
> if (ret)
> return ret;
> }
> @@ -2787,8 +2915,13 @@ static u8 i3c_master_i2c_get_lvr(struct i2c_client *client)
> u8 lvr = I3C_LVR_I2C_INDEX(2) | I3C_LVR_I2C_FM_MODE;
> u32 reg[3];
>
> - if (!fwnode_property_read_u32_array(client->dev.fwnode, "reg", reg, ARRAY_SIZE(reg)))
> - lvr = reg[2];
> + if (is_of_node(client->dev.fwnode)) {
> + if (!fwnode_property_read_u32_array(client->dev.fwnode, "reg",
> + reg, ARRAY_SIZE(reg)))
> + lvr = reg[2];
> + } else if (is_acpi_device_node(client->dev.fwnode)) {
> + lvr = i3c_acpi_i2c_get_lvr(client);
> + }
>
> return lvr;
> }
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v4 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Frank Li @ 2026-06-18 19:35 UTC (permalink / raw)
To: Akhil R
Cc: Alexandre Belloni, Frank Li, Miquel Raynal, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Guenter Roeck, Philipp Zabel,
Jon Hunter, Thierry Reding, linux-i3c, devicetree, linux-hwmon,
linux-tegra, linux-kernel
In-Reply-To: <20260616095429.3947205-2-akhilrajeev@nvidia.com>
On Tue, Jun 16, 2026 at 09:54:15AM +0000, Akhil R wrote:
> Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> Discovery and Configuration Specification [1] to specify which discovery
> method an I3C device supports during bus initialization. The property is
> a bitmap, where a bit value of 1 indicates support for that method, and 0
> indicates lack of support.
>
> Bit 0: SETDASA CCC (Direct)
> Bit 1: SETAASA CCC (Broadcast)
> Bit 2: Other CCC (vendor / standards extension)
> All other bits are reserved.
>
> It is specifically needed when an I3C device requires SETAASA for the
> address assignment. SETDASA will be supported by default if this property
> is absent, which means for now the property just serves as a flag to
> enable SETAASA, but keep the property as a bitmap to align with the
> specifications.
>
> [1] https://www.mipi.org/mipi-disco-for-i3c-download
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> .../devicetree/bindings/i3c/i3c.yaml | 36 ++++++++++++++++---
> include/dt-bindings/i3c/i3c.h | 4 +++
> 2 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> index e25fa72fd785..5603f2e7807d 100644
> --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> @@ -31,10 +31,12 @@ properties:
> described in the device tree, which in turn means we have to describe
> I3C devices.
>
> - Another use case for describing an I3C device in the device tree is when
> - this I3C device has a static I2C address and we want to assign it a
> - specific I3C dynamic address before the DAA takes place (so that other
> - devices on the bus can't take this dynamic address).
> + Other use-cases for describing an I3C device in the device tree are:
> + - When the I3C device has a static I2C address and we want to assign
> + it a specific I3C dynamic address before the DAA takes place (so
> + that other devices on the bus can't take this dynamic address).
> + - When the I3C device requires SETAASA for its discovery and uses a
> + pre-defined static address.
>
> "#size-cells":
> const: 0
> @@ -145,7 +147,31 @@ patternProperties:
> Dynamic address to be assigned to this device. In case static address is
> present (first cell of the reg property != 0), this address is assigned
> through SETDASA. If static address is not present, this address is assigned
> - through SETNEWDA after assigning a temporary address via ENTDAA.
> + through SETNEWDA after assigning a temporary address via ENTDAA. If
> + SETAASA is used, this property is not used, and the static address itself
> + becomes the dynamic address.
> +
> + mipi-i3c-static-method:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0x1
> + maximum: 0x7
> + default: 1
> + description: |
> + Bitmap describing which methods of Dynamic Address Assignment from a
> + static address are supported by this I3C Target. For each defined bit
> + position, a set bit indicates support for that method and a cleared
> + bit indicates lack of support.
> +
> + Bit 0: SETDASA CCC (Direct)
> + Bit 1: SETAASA CCC (Broadcast)
> + Bit 2: Other CCC (vendor / standards extension)
> + All other bits are reserved.
> +
> + This property follows the MIPI I3C specification. The primary use
> + of this property is to indicate support for SETAASA, i.e Bit 1, but
> + will allow other values mentioned in the specification so that it
> + mirrors the specification. SETDASA will remain as the default method
> + even if this property is not present.
>
> required:
> - reg
> diff --git a/include/dt-bindings/i3c/i3c.h b/include/dt-bindings/i3c/i3c.h
> index 373439218bba..78b8c634aad8 100644
> --- a/include/dt-bindings/i3c/i3c.h
> +++ b/include/dt-bindings/i3c/i3c.h
> @@ -13,4 +13,8 @@
> #define I2C_NO_FILTER_HIGH_FREQUENCY (1 << 5)
> #define I2C_NO_FILTER_LOW_FREQUENCY (2 << 5)
>
> +#define I3C_ADDR_METHOD_SETDASA (1 << 0)
> +#define I3C_ADDR_METHOD_SETAASA (1 << 1)
> +#define I3C_ADDR_METHOD_VENDOR (1 << 2)
> +
> #endif
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH RFC v4 10/12] reset: zte: Add a zx297520v3 reset driver
From: Stefan Dösinger @ 2026-06-18 19:28 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Brian Masney, Philipp Zabel
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <90c4f50eb23dec06497d46f9c0f522a6b90a918b.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 3121 bytes --]
Am Donnerstag, 18. Juni 2026, 12:24:26 Ostafrikanische Zeit schrieb Philipp
Zabel:
> On Di, 2026-06-16 at 23:26 +0300, Stefan Dösinger wrote:
> > This drives the auxiliary devices created by the clock driver.
>
> Which auxiliary devices? Which clock driver?
The ones from patches 7-10. But I guess you're telling me to spell this out
for readers who see my patch in the kernel commit log rather than the
submission series.
> > + [ZX297520V3_UART0_RESET] = { .reg = 0x78, .mask = BIT(6) |
BIT(7)
> > },
> Is this a single reset line controlled by two bits (do you know what
> they are)? Or might these actually be two different reset controls that
> are just always set together?
Most devices on this SoC have two reset lines. In most cases asserting one is
enough to reset the device, and consequently both need to be deasserted to
bring the device out of reset. In some cases both need to be asserted to reset
the device and it keeps operating fine with only one asserted. I believe I
documented some of that in comments, but maybe I forgot to move it from the
clock part of the driver.
Exceptions apply - some devices have only one reset bit and for some I haven't
found any. USB as you noticed has 3.
I don't really know the difference between the two lines. I don't have a
datasheet and ZTE's downstream kernel only operates on the USB resets. The old
upstream zx2967xx code had no reset driver at all. So I found the resets by
setting the registers and then single bits to 0 and seeing what disappears
from mmio space. Everything on this board except USB comes with resets
deasserted on boot.
I'm pretty sure that what I identified as resets are actually resets and not
extra clocks because previous device configuration gets lost after asserting a
reset, whereas it is retained when disabling pclk.
I absolutely expect to run into surprises and epiphanies in the future and
problems on as of yet untested types of zx297520v3 devices.
> > + [ZX297520V3_USB_RESET] = { .reg = 0x80, .mask = BIT(3) |
BIT(4)
> > | BIT(5), + .wait_mask = BIT(1)},
>
> Same as above, are these actually three separate reset lines?
It is likely a combination of the same 2 indistinguishable lines (4, 5) and a
separate USB PHY line (3) - this is what ZTE's code suggests, but it is a mess
of #ifdefs and redirection, so I don't know if I isolated the correct
codepath. (No, a kernel built from that ugly code doesn't boot, so I can't add
printks).
The PHY reset line does not do anything observable on my device if I recall
correctly. It might be nonexistent, it might be a leftover from older
revisions or some devices might have different PHYs, similarly to how Ethernet
PHYs differ.
I'll double check those USB resets before I resend. It's been months since I
looked at this particular part of the board, and maybe I missed something. On
the booted ZTE kernel and in the bootloader, when booted via USB, all 3 are
deasserted. When booted via the NAND boot chain they are asserted when the
kernel takes over.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: magnetometer: add support for Melexis MLX90393
From: Andy Shevchenko @ 2026-06-18 19:26 UTC (permalink / raw)
To: Nikhil Gautam
Cc: linux-iio, jic23, dlechner, nuno.sa, andy, robh, krzk+dt,
conor+dt, devicetree, linux-kernel
In-Reply-To: <20260618160141.11409-3-nikhilgtr@gmail.com>
On Thu, Jun 18, 2026 at 09:31:41PM +0530, Nikhil Gautam wrote:
> Add Industrial I/O subsystem support for the Melexis
> MLX90393 3-axis magnetometer and temperature sensor.
>
> The driver currently supports:
>
> raw magnetic field measurements
> raw temperature measurements
> configurable gain/scale selection
> configurable oversampling ratio
> direct mode operation
>
> The MLX90393 supports both I2C and SPI interfaces. This
> initial implementation adds support for the I2C interface.
>
> The driver is structured around a shared sensor core with
> a small transport abstraction layer to simplify future SPI
> support without duplicating sensor logic.
...
> +config MLX90393
> + tristate "MELEXIS MLX90393 3-axis magnetometer sensor"
> + depends on I2C
Why not a regmap?
> + help
> + Say yes here to build support for the MELEXIS MLX90393 3-axis
> + magnetometer.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called mlx90393.
> +
> config MMC35240
> tristate "MEMSIC MMC35240 3-axis magnetic sensor"
> select REGMAP_I2C
> diff --git a/drivers/iio/magnetometer/Makefile b/drivers/iio/magnetometer/Makefile
> index 9297723a97d8..542c89d38a59 100644
> --- a/drivers/iio/magnetometer/Makefile
> +++ b/drivers/iio/magnetometer/Makefile
> @@ -14,6 +14,8 @@ obj-$(CONFIG_BMC150_MAGN_SPI) += bmc150_magn_spi.o
>
> obj-$(CONFIG_MAG3110) += mag3110.o
> obj-$(CONFIG_HID_SENSOR_MAGNETOMETER_3D) += hid-sensor-magn-3d.o
> +obj-$(CONFIG_MLX90393) += mlx90393_core.o
> +obj-$(CONFIG_MLX90393) += mlx90393_i2c.o
> obj-$(CONFIG_MMC35240) += mmc35240.o
...
> +#ifndef MLX90393_H
> +#define MLX90393_H
> +#include <linux/bitops.h>
> +#include <linux/bits.h>
Not required, it's covered by bitops.h.
> +#include <linux/types.h>
...
> +#define MLX90393_MEASURE_ALL \
> + (MLX90393_MEASURE_TEMP | MLX90393_MEASURE_X | \
> + MLX90393_MEASURE_Y | MLX90393_MEASURE_Z)
Split logically.
#define MLX90393_MEASURE_ALL \
(MLX90393_MEASURE_TEMP | \
MLX90393_MEASURE_X | MLX90393_MEASURE_Y | MLX90393_MEASURE_Z)
Or just a (long) single line.
...
> + int (*xfer)(void *context, const u8 *tx, int tx_len,
> + u8 *rx, int rx_len);
One line, it's only 81 characters.
> +};
> +
> +int mlx90393_core_probe(struct device *dev,
You want forward declaration for struct device.
> + const struct mlx90393_transfer_ops *ops,
> + void *context);
> +
...
+ array_size.h
+ bitfield.h // FIELD_GET()
> +#include <linux/delay.h>
+ errno.h // -Exxx
> +#include <linux/module.h>
> +#include <linux/mutex.h>
+ types.h // uXX
> +#include <linux/unaligned.h>
> +#include <linux/units.h>
IWYU, please (just pointed out a few missing above, there are more).
...
> +/* Datasheet: Table no.17 */
> +static const int mlx90393_scale_table[MLX90393_AXIS_MAX]
> + [MLX90393_GAIN_MAX]
> + [MLX90393_RES_MAX] = {
This is broken indentation.
> + /* XY axis */
> + {
> + { 751, 1502, 3004, 6009},
> + { 601, 1202, 2403, 4840},
> + { 451, 901, 1803, 3605},
> + { 376, 751, 1502, 3004},
> + { 300, 601, 1202, 2403},
> + { 250, 501, 1001, 2003},
> + { 200, 401, 801, 1602},
> + { 150, 300, 601, 1202},
> + },
> + /* Z axis */
> + {
> + { 1210, 2420, 4840, 9680},
> + { 968, 1936, 3872, 7744},
> + { 726, 1452, 2904, 5808},
> + { 605, 1210, 2420, 4840},
> + { 484, 968, 1936, 3872},
> + { 403, 807, 1613, 3227},
> + { 323, 645, 1291, 2581},
> + { 242, 484, 968, 1936},
> + }
> +};
...
> +/*
> + * Calculate total conversion time in microseconds.
> + *
> + * Formula derived from datasheet timing equations.
Which formula? Where is datasheet? What if I have no access to it?
Always repeat the important details in the comment in the code.
> + */
> +
Unneeded blank line.
> +static int mlx90393_get_tconv_us(struct mlx90393_data *data)
> +{
> + const int osr = data->osr;
> + const int osr2 = data->osr2;
> + const int df = data->dig_filt;
> +
> + int tconvm;
> + int tconvt;
> +
> + int m = 3; /* X,Y,Z */
> +
> + /*
> + * Datasheet:
What chapter/section/table name? Page number?
> + * TCONVM = 67 + 64 * 2^OSR * (2 + 2^DIG_FILT)
What does this cryptic message mean? Please, accompany this with more English
plain text.
> + */
> + tconvm = 67 + (64 * BIT(osr) * (2 + BIT(df)));
> +
> + /*
> + * Datasheet:
> + * TCONVT = 67 + 192 * 2^OSR2
> + */
> + tconvt = 67 + (192 * BIT(osr2));
> + /*
> + * Total conversion time:
> + * TSTBY + TACTIVE + m * TCONVM + TCONVT + TCONV_END
> + */
> + return 220 + 360 + (m * tconvm) + tconvt + 1100;
> +}
...
> +static int mlx90393_xfer(struct mlx90393_data *data,
> + const u8 *tx, int tx_len,
> + u8 *rx, int rx_len)
> +{
> + return data->ops->xfer(data->bus_context,
> + tx, tx_len,
> + rx, rx_len);
It's perfectly one line.
Also you might want to have
if (!...->xfer)
return -E...;
> +}
...
> +static int mlx90393_check_status(u8 cmd, u8 status)
> +{
> + /* Always validate error bit */
> + if (status & MLX90393_STATUS_ERROR)
> + return -EIO;
> +
> + switch (cmd & MLX90393_CMD_MASK) {
> + case MLX90393_CMD_RM:
> + /*
> + * D1:D0 indicates response availability
> + * 00 means invalid/no measurement
> + */
> + if ((status & MLX90393_STATUS_RESP) == 0)
> + return -EIO;
> + return 0;
> + case MLX90393_CMD_RT:
> + /* Reset acknowledge */
> + if (!(status & MLX90393_STATUS_RT))
For sake of consistency you might want to also compare to 0 here.
> + return -EIO;
> + return 0;
> + default:
> + return 0;
> + }
> +}
...
> +static int mlx90393_write_reg(struct mlx90393_data *data, u8 reg, u16 val)
Here the variable is named 'reg' there is 'reg_addr'. As I can see the code is
full of inconsistencies (like 2+ people with different style guidelines wrote
it). Please. take your time and check the code and make it consistent.
> +{
> + u8 tx[4];
> + u8 status;
> + int ret;
> +
> + tx[0] = MLX90393_CMD_WR;
> + put_unaligned_be16(val, &tx[1]);
> + /* Register address is encoded in bits [7:2] */
> + tx[3] = reg << 2;
> +
> + ret = mlx90393_xfer(data, tx, sizeof(tx), &status, 1);
> + if (ret)
> + return ret;
> +
> + return mlx90393_check_status(tx[0], status);
> +}
> +
> +static int mlx90393_update_bits(struct mlx90393_data *data, u8 reg_addr,
> + u16 mask, u16 val)
> +{
> + u16 reg;
> + int ret;
> +
> + ret = mlx90393_read_reg(data, reg_addr, ®);
> + if (ret)
> + return ret;
> + reg &= ~mask;
> + reg |= (val << __ffs(mask)) & mask;
bitfield.h has macros for this.
> + return mlx90393_write_reg(data, reg_addr, reg);
> +}
...
> +static int mlx90393_find_osr(int val, int *osr)
> +{
> + for (unsigned int i = 0; i < MLX90393_OSR_MAX; i++)
> + if (mlx90393_osr_avail[i] == val) {
> + *osr = i;
> + return 0;
> + }
Missing {}.
> + return -EINVAL;
> +}
...
> +static int mlx90393_get_temp_osr2(struct mlx90393_data *data, int *val)
> +{
> + *val = mlx90393_osr2_avail[data->osr2];
Missing blank line.
> + return IIO_VAL_INT;
> +}
...
> +static int mlx90393_write_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int val, int val2,
> + long mask)
> +{
> + struct mlx90393_data *data = iio_priv(indio_dev);
> + int ret;
Not needed, return directly.
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE: {
> + guard(mutex)(&data->lock);
> + ret = mlx90393_set_scale(data, chan, val, val2);
> + return ret;
> + }
> + case IIO_CHAN_INFO_OVERSAMPLING_RATIO: {
> + guard(mutex)(&data->lock);
> + switch (chan->type) {
> + case IIO_TEMP:
> + return mlx90393_set_temp_osr2(data, val);
> +
> + case IIO_MAGN:
> + return mlx90393_set_osr(data, val);
> +
> + default:
> + return -EINVAL;
> + }
> + }
> + default:
> + return -EINVAL;
> + }
> +}
...
> + /* Datasheet: 22124 millidegC/LSB */
> + /* Datasheet: temperature offset */
Again, at least put a page, better to have Section/Table/et cetera title.
...
> +static int mlx90393_read_avail(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + const int **vals,
> + int *type,
> + int *length,
> + long mask)
> +{
> + struct mlx90393_data *data = iio_priv(indio_dev);
> + static int scale_avail[MLX90393_GAIN_MAX][MLX90393_AXIS_MAX];
> + enum mlx90393_axis_type axis;
> + u8 res;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE: {
> + guard(mutex)(&data->lock);
> + axis = chan->channel2 == IIO_MOD_Z;
> + res = axis ? data->res_z : data->res_xy;
> +
> + for (unsigned int i = 0; i < MLX90393_GAIN_MAX; i++) {
> + scale_avail[i][0] = 0;
> + scale_avail[i][1] = mlx90393_scale_table[axis][i][res];
> + }
> +
> + *vals = &scale_avail[0][0];
> + *type = IIO_VAL_INT_PLUS_NANO;
> + *length = MLX90393_GAIN_MAX * MLX90393_AXIS_MAX;
> + return IIO_AVAIL_LIST;
> + }
> + case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
> + if (chan->type == IIO_TEMP) {
> + *vals = mlx90393_osr2_avail;
> + *type = IIO_VAL_INT;
> + *length = MLX90393_OSR2_MAX;
> + } else {
> + *vals = mlx90393_osr_avail;
> + *type = IIO_VAL_INT;
> + *length = MLX90393_OSR_MAX;
> + }
> + return IIO_AVAIL_LIST;
> +
> + default:
> + return -EINVAL;
> + }
> + return -EINVAL;
Besides missing blank line, this is actually a dead code.
> +}
...
> +static int mlx90393_init(struct mlx90393_data *data)
> +{
> + int ret;
> + u16 reg;
> +
> + /* Exit mode */
> + ret = mlx90393_write_cmd(data, MLX90393_CMD_EX);
> + if (ret)
> + return ret;
> +
> + /* Wait for device comes out of reset */
Datasheet? Empirical?
> + fsleep(1000);
1 * USEC_PER_MSEC
(will require time.h to be included).
> + /* Reset device */
> + ret = mlx90393_write_cmd(data, MLX90393_CMD_RT);
> + if (ret)
> + return ret;
> +
> + /* Wait for device to reset */
> + fsleep(6000);
As per above.
> + ret = mlx90393_read_reg(data, MLX90393_REG_CONF1, ®);
> + if (ret)
> + return ret;
> +
> + data->gain_sel = FIELD_GET(MLX90393_CONF1_GAIN_SEL, reg);
> + data->hallconf = FIELD_GET(MLX90393_CONF1_HALLCONF, reg);
> +
> + ret = mlx90393_read_reg(data, MLX90393_REG_CONF3, ®);
> + if (ret)
> + return ret;
> +
> + data->res_xy = FIELD_GET(MLX90393_CONF3_RES_X, reg);
> + data->res_z = FIELD_GET(MLX90393_CONF3_RES_Z, reg);
> + data->dig_filt = FIELD_GET(MLX90393_CONF3_DIG_FILT, reg);
> + data->osr = FIELD_GET(MLX90393_CONF3_OSR, reg);
> + data->osr2 = FIELD_GET(MLX90393_CONF3_OSR2, reg);
> +
> + return 0;
> +}
...
> +int mlx90393_core_probe(struct device *dev,
> + const struct mlx90393_transfer_ops *ops,
> + void *context)
> +{
> + struct iio_dev *indio_dev;
> + struct mlx90393_data *data;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + data = iio_priv(indio_dev);
> + devm_mutex_init(dev, &data->lock);
Nonsense. If we don't check the return code of devm_*(), there is a little
reason to use it in the first place. But then one should not use devm further.
Easy fix: check for returned errors.
> + data->dev = dev;
> + data->ops = ops;
> + data->bus_context = context;
> +
> + indio_dev->name = "mlx90393";
> + indio_dev->info = &mlx90393_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = mlx90393_channels;
> + indio_dev->num_channels = ARRAY_SIZE(mlx90393_channels);
> +
> + ret = mlx90393_init(data);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to initialize device\n");
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
> +EXPORT_SYMBOL_GPL(mlx90393_core_probe);
Make it namespaces.
...
+ array_size.h
+ errno.h
> +#include <linux/module.h>
> +#include <linux/i2c.h>
> +#include <linux/mod_devicetable.h>
...and so on.
Same, follow the IWYU principle.
...
> +/*
> + * MLX90393 commands use repeated-start transfers where
> + * every command is followed by a status/data response.
> + */
> +static int mlx90393_i2c_xfer(void *context,
> + const u8 *tx, int tx_len,
> + u8 *rx, int rx_len)
> +{
> + struct i2c_client *client = context;
> + int ret;
> + struct i2c_msg msgs[2] = {
> + [0] = {
> + .addr = client->addr,
> + .len = tx_len,
> + .buf = (u8 *)tx,
> + },
> + [1] = {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .len = rx_len,
> + .buf = rx,
> + },
> + };
> +
> + ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
> + if (ret != ARRAY_SIZE(msgs))
> + return ret < 0 ? ret : -EIO;
Please, make this to be the regular pattern
if (ret < 0)
return ret;
if (ret != ARRAY_SIZE(msgs))
return -EIO;
> + return 0;
> +}
...
> +static struct i2c_driver mlx90393_i2c_driver = {
> + .driver = {
> + .name = "mlx90393",
> + .of_match_table = mlx90393_of_match,
> + },
> + .probe = mlx90393_i2c_probe,
> +};
> +
Remove this blank line.
> +module_i2c_driver(mlx90393_i2c_driver);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 02/10] libfdt: Don't assume that a FDT_BEGIN_NODE tag is available at offset 0
From: Herve Codina @ 2026-06-18 19:17 UTC (permalink / raw)
To: David Gibson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <ajPE5eGcOwWMAeiN@zatzit>
Hi David,
On Thu, 18 Jun 2026 20:13:57 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Apr 09, 2026 at 01:54:18PM +0200, Herve Codina wrote:
> > In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present
> > at the offset 0 of the structure block.
> >
> > This assumption is not correct. Indeed, a FDT_NOP can be present at the
> > offset 0 and this is a legit case.
> >
> > fdt_first_node() has been introduced recently to get the offset of the
> > first node (first FDT_BEGIN_NODE) in a fdt blob.
> >
> > Use this function to get the first node offset instead of looking for
> > this node at offset 0.
> >
> > Signed-off-by: Herve Codina <herve.codina@bootlin.com>
>
> The problem is real, of course. But this approach to solving it with
> a special case just for the root node is really ugly.
>
> Granted, it's a problem of my own making - I chose not to create an
> fdt_root_offset() function in the first place, instead making it part
> of the API that offset 0 means the root node. Nonetheless, here we
> are and the question is whether we can do better.
>
> # Straightforward things first
>
> - This patch should be folded with 1/10, they're both harder to
> understand without the context of the other.
Ok, I will squash, no problem.
>
> - If it must exist, the function should be fdt_root_offset(), not
> fdt_first_node(), for at least three reasons:
> * "first" in what sense?
> * "first" amongst what set of nodes?
> * We have a strong convention to always explicitly say "offset",
> not just referring to offset values as "node" or "property".
> This is deliberate: it's an attempt to discourage the otherwise
> likely misunderstanding that a function getting a "node" gives
> you some sort of persistent handle. "offset" makes it clearer
> that the value will no longer be valid after a modification to
> the tree.
Make sense. I will rename to fdt_root_offset()
>
> - The situation described is subtle enough that this *really* needs a
> testcase. It shouldn't be that hard: change the existing
> 'nopulate' test tool to add an FDT_NOP before the first tag, not
> just after
Yes, will add a test.
>
> # Is FDT_NOP before the root node actually legitimate?
>
> Arguably the simplest solution here would be to explicitly ban this.
> Yes, it would be a slightly odd restriction in the spec. However,
> avoiding the mess in the library might be worth it. Note that this
> situation can never arise from fdt_nop_node(), unless you apply it to
> the root node, in which case there's no tree left.
We tried to have something robust for future addition (structured tags).
Maybe a future tag will be nopified by some future tools before being
processed by libfdt.
IMHO, we should have support for FDT_NOP before the root node.
>
> # Less special casery
>
> Even if we accept the need for FDT_NOP before the root node, I think
> we can do better. The below implements this as a special case, just
> for offset 0. Instead, we could allow all node operations on a
> FDT_NOP offset, automatically advancing to the next FDT_BEGIN_NODE
> tag. We may be able to do that in check_node_offset_() minimising
> code duplication.
>
IHMO, check_node_offset_() should only check that the given offset is a
node and not trying to find the next node available after possible FDT_NOP.
Got the feeling that having this kind of search in check_node_offset_() is
error prone.
I am not sure that a lot of code duplication will be present. On some entry
points, we have this kind of code:
--- 8< ---
if (offset == 0) {
offset = fdt_root_offset(fdt);
if (offset < 0)
return offset;
}
--- 8< ---
It has the benefit to keep things clear and is needed only on some entry
points (API function). Internal function should receive an offset pointing
to a node. For those internal function check_node_offset_() should not
automatically skip FDT_NOP tags but should really return an error if such a
tag is encountered.
For offsets other than offset 0, FDT_NOP is handled without any extra cost in
current code implementation.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH V2 3/3] dmaengine: zynqmp_dma: Guard IRQ handler against spurious interrupts
From: Frank Li @ 2026-06-18 19:15 UTC (permalink / raw)
To: Golla Nagendra
Cc: vkoul, Frank.Li, michal.simek, robh, krzk+dt, conor+dt,
jay.buddhabhatti, harini.katakam, m.tretter, radhey.shyam.pandey,
abin.joseph, kees, sakari.ailus, git, dmaengine, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260618071056.2024286-4-nagendra.golla@amd.com>
On Thu, Jun 18, 2026 at 12:40:56PM +0530, Golla Nagendra wrote:
> [You don't often get email from nagendra.golla@amd.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Add pm_runtime_get_if_active() check in zynqmp_dma_irq_handler() to
> safely handle spurious interrupts that may arrive while the device is
> runtime-suspended. Without this guard, a spurious interrupt could cause
> the handler to access hardware registers (ISR, IMR) with clocks gated,
> potentially leading to a synchronous external abort and kernel crash.
>
> When the device is not runtime-active, pm_runtime_get_if_active()
> returns false without incrementing the usage counter, and the handler
> returns IRQ_NONE immediately. When the device is active, it increments
> the usage counter to prevent a concurrent runtime suspend during
> register access, and pm_runtime_put() releases the reference afterward.
>
> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
> ---
> drivers/dma/xilinx/zynqmp_dma.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index a9dfec3c0ca3..ce9163138be7 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c
> @@ -730,6 +730,9 @@ static irqreturn_t zynqmp_dma_irq_handler(int irq, void *data)
> u32 isr, imr, status;
> irqreturn_t ret = IRQ_NONE;
>
> + if (pm_runtime_get_if_active(chan->dev) <= 0)
> + return IRQ_NONE;
> +
Can you add AQUIRE macro in include/linux/pm_runtime.h
so here can use PM_RUNTIME_ACQUIRE_IF_ACITVE
Other person can get benefit for auto clean up especially if there are some
difference return path.
Frank
> isr = readl(chan->regs + ZYNQMP_DMA_ISR);
> imr = readl(chan->regs + ZYNQMP_DMA_IMR);
> status = isr & ~imr;
> @@ -756,6 +759,8 @@ static irqreturn_t zynqmp_dma_irq_handler(int irq, void *data)
> ret = IRQ_HANDLED;
> }
>
> + pm_runtime_put(chan->dev);
> +
> return ret;
> }
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 0/2] iio: magnetometer: add support for Melexis MLX90393
From: Andy Shevchenko @ 2026-06-18 18:59 UTC (permalink / raw)
To: Nikhil Gautam
Cc: linux-iio, jic23, dlechner, nuno.sa, andy, robh, krzk+dt,
conor+dt, devicetree, linux-kernel
In-Reply-To: <20260618160141.11409-1-nikhilgtr@gmail.com>
On Thu, Jun 18, 2026 at 09:31:39PM +0530, Nikhil Gautam wrote:
> Hi,
>
> This series adds initial Industrial I/O subsystem support for the
> Melexis MLX90393 3-axis magnetometer and temperature sensor.
>
> The MLX90393 supports both I2C and SPI interfaces. This series
> implements support for the I2C interface while keeping the driver
> structure transport-independent to simplify future SPI support.
>
> Currently supported features:
>
> * Raw magnetic field measurements for X/Y/Z axes
> * Raw temperature measurements
> * Configurable gain/scale selection
> * Configurable oversampling ratio
> * Direct mode operation through the IIO subsystem
> * I2C interface support
>
> The driver has been tested on Raspberry Pi 5 hardware using an
> MLX90393 sensor connected over I2C. Magnetic field and temperature
> measurements were verified through the IIO sysfs interface.
This doesn't answer to two important questions:
- why do we need a brand new driver?
Can't one of the existing be updated to cover this HW?
- where to find the datasheet? Any Links or other means to get it?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: Stefan Dösinger @ 2026-06-18 18:59 UTC (permalink / raw)
To: Conor Dooley
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260617-deed-snap-4649ffae0e27@spud>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
Am Donnerstag, 18. Juni 2026, 00:23:56 Ostafrikanische Zeit schrieben Sie:
> Do you actually need an aux bus here though? Since you have to add
> simple-mfd for your the syscon-reboot and simple-mfd is a real bus, can you
> set the reset controller up with an mfd_cell + devm_mfd_add_devices()
> instead?
I'll have to read up on devm_mfd_add_devices; The aux bus was the suggestion
of Philipp Zabel. At first sight it sounds to me like they do fairly similar
things. I don't see any precedence for [devm_]mfd_add_devices in drivers/clk/.
Whatever way I go I'd like to use the same for all 3 clock/reset controllers.
So far I only made topclk a simple-mfd. I recently stumbled upon spinlock
registers in matrixclk, so I guess I can justify a simple-mfd there too. For
lspclk all I can see is clocks and resets and I ran out of unknown registers
in there.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/2] clk: amlogic: Add A9 AO clock controller driver
From: Julian Braha @ 2026-06-18 18:56 UTC (permalink / raw)
To: jian.hu, Neil Armstrong, Jerome Brunet, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Xianwei Zhao, Kevin Hilman, Martin Blumenstingl
Cc: linux-amlogic, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260618-a9_aoclk-v4-2-569d0425e50c@amlogic.com>
Hi Jian,
On 6/18/26 10:49, Jian Hu via B4 Relay wrote:
> +config COMMON_CLK_A9_AO
> + tristate "Amlogic A9 SoC AO clock controller support"
> + depends on ARM64 || COMPILE_TEST
> + default ARCH_MESON
> + select COMMON_CLK_MESON_REGMAP
> + select COMMON_CLK_MESON_CLKC_UTILS
> + select COMMON_CLK_MESON_DUALDIV
Selecting COMMON_CLK_MESON_REGMAP is unnecessary since you're already
selecting COMMON_CLK_MESON_DUALDIV here.
- Julian Braha
^ permalink raw reply
* Re: [PATCH V2 2/3] dmaengine: zynqmp_dma: Add per-channel reset support
From: Frank Li @ 2026-06-18 18:52 UTC (permalink / raw)
To: Golla Nagendra
Cc: vkoul, Frank.Li, michal.simek, robh, krzk+dt, conor+dt,
jay.buddhabhatti, harini.katakam, m.tretter, radhey.shyam.pandey,
abin.joseph, kees, sakari.ailus, git, dmaengine, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260618071056.2024286-3-nagendra.golla@amd.com>
On Thu, Jun 18, 2026 at 12:40:55PM +0530, Golla Nagendra wrote:
> [You don't often get email from nagendra.golla@amd.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Versal Gen 2 and Versal Net SoCs expose a dedicated reset line per
> ZDMA channel, replacing the earlier approach where a single reset
> was shared across all channels. Add reset handling in the channel
> probe path using device_reset_optional() to trigger a reset pulse
> on the channel during initialization.
>
> Platforms without per-channel reset continue to work unaffected
> since device_reset_optional() returns 0 when no reset is specified.
>
> add pm_runtime_put_noidle() in the probe error path before
> pm_runtime_disable() to balance the usage counter incremented by
> pm_runtime_resume_and_get(). This is particularly important since
> device_reset_optional() can return -EPROBE_DEFER, causing the
> kernel to retry probe() and leak one PM usage count per retry
> without the put.
Use sperate patch to fix this problem
Frank
>
> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
> ---
> drivers/dma/xilinx/zynqmp_dma.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
> index f6a812e49ddc..a9dfec3c0ca3 100644
> --- a/drivers/dma/xilinx/zynqmp_dma.c
> +++ b/drivers/dma/xilinx/zynqmp_dma.c
> @@ -18,6 +18,7 @@
> #include <linux/clk.h>
> #include <linux/io-64-nonatomic-lo-hi.h>
> #include <linux/pm_runtime.h>
> +#include <linux/reset.h>
>
> #include "../dmaengine.h"
>
> @@ -916,6 +917,11 @@ static int zynqmp_dma_chan_probe(struct zynqmp_dma_device *zdev,
> if (IS_ERR(chan->regs))
> return PTR_ERR(chan->regs);
>
> + err = device_reset_optional(&pdev->dev);
> + if (err)
> + return dev_err_probe(&pdev->dev, err,
> + "failed to reset channel\n");
> +
> chan->bus_width = ZYNQMP_DMA_BUS_WIDTH_64;
> chan->dst_burst_len = ZYNQMP_DMA_MAX_DST_BURST_LEN;
> chan->src_burst_len = ZYNQMP_DMA_MAX_SRC_BURST_LEN;
> @@ -1152,6 +1158,7 @@ static int zynqmp_dma_probe(struct platform_device *pdev)
> err_disable_pm:
> if (!pm_runtime_enabled(zdev->dev))
> zynqmp_dma_runtime_suspend(zdev->dev);
> + pm_runtime_put_noidle(zdev->dev);
> pm_runtime_disable(zdev->dev);
> return ret;
> }
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v10 3/4] dt-bindings: clock: imx95-blk-ctl: Define formatter child node schema
From: Frank Li @ 2026-06-18 18:45 UTC (permalink / raw)
To: guoniu.zhou
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Laurent Pinchart, Frank Li, Abel Vesa, Peng Fan,
Michael Turquette, Stephen Boyd, imx, linux-media, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, Guoniu Zhou
In-Reply-To: <20260618-csi_formatter-v10-3-f23830312ba5@oss.nxp.com>
On Thu, Jun 18, 2026 at 05:41:37PM +0800, guoniu.zhou@oss.nxp.com wrote:
> From: Guoniu Zhou <guoniu.zhou@nxp.com>
>
> The Camera CSR contains control registers for multiple CSI formatter IPs
> at different register offsets. Each formatter is an independent hardware
> block with its own clock input and media pipeline connection.
>
> Define schema to allow formatter child nodes under nxp,imx95-camera-csr,
> with 'reg' property specifying the formatter's register offset within the
> CSR address space.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> ---
> Changes in v10:
> - Use single quotes for regex pattern to be consistent (Krzysztof Kozlowski)
> - Add formatter subnode binding and camera-csr syscon example
> - Update commit title and message
>
> Changes in v9:
> - New patch to address the issue of formatter acting as a child node of syscon
> ---
> .../bindings/clock/nxp,imx95-blk-ctl.yaml | 64 +++++++++++++++++++++-
> 1 file changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> index 534fa219d9f9..b4d0a7670fac 100644
> --- a/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> @@ -46,7 +46,27 @@ required:
> - power-domains
> - clocks
>
> -additionalProperties: false
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nxp,imx95-camera-csr
> + then:
> + properties:
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 1
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + patternProperties:
> + '^formatter@[0-9a-f]+$':
> + type: object
> + $ref: /schemas/media/fsl,imx95-csi-formatter.yaml#
suppose "unevaluatedProperties:" false should under '^formatter@[0-9a-f]+$':
> +
> +unevaluatedProperties: false
here should keep original additionalProperties: false
Frank
>
> examples:
> - |
> @@ -57,4 +77,46 @@ examples:
> clocks = <&scmi_clk 114>;
> power-domains = <&scmi_devpd 21>;
> };
> +
> + - |
> + #include <dt-bindings/clock/nxp,imx95-clock.h>
> +
> + syscon@4ac10000 {
> + compatible = "nxp,imx95-camera-csr", "syscon";
> + reg = <0x4ac10000 0x10000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #clock-cells = <1>;
> + clocks = <&scmi_clk 62>;
> + power-domains = <&scmi_devpd 3>;
> +
> + formatter@20 {
> + compatible = "fsl,imx95-csi-formatter";
> + reg = <0x20 0x100>;
> + clocks = <&cameramix_csr IMX95_CLK_CAMBLK_CSI2_FOR0>;
> + power-domains = <&scmi_devpd 3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + endpoint {
> + remote-endpoint = <&mipi_csi_0_out>;
> + };
> +
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + endpoint {
> + remote-endpoint = <&isi_in_2>;
> + };
> + };
> + };
> + };
> + };
> ...
>
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v10 2/4] media: dt-bindings: Add CSI Pixel Formatter DT bindings
From: Frank Li @ 2026-06-18 18:41 UTC (permalink / raw)
To: guoniu.zhou
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Laurent Pinchart, Frank Li, Abel Vesa, Peng Fan,
Michael Turquette, Stephen Boyd, imx, linux-media, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, Guoniu Zhou
In-Reply-To: <20260618-csi_formatter-v10-2-f23830312ba5@oss.nxp.com>
On Thu, Jun 18, 2026 at 05:41:36PM +0800, guoniu.zhou@oss.nxp.com wrote:
> From: Guoniu Zhou <guoniu.zhou@nxp.com>
>
> The i.MX95 CSI pixel formatting module uses packet info, pixel and
> non-pixel data from the CSI-2 host controller and reformat them to
> match Pixel Link(PL) definition.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> Changes in v10:
> - Drop syscon parent node from example
> - Drop Reviewed-by tags from Frank and Krzysztof due to binding changes
> - Add description for reg property
> - Add space after formatter@20 before opening brace in example
> - Enhance the port description with more detailed information
> - Delete the blank line immediately following the endpoint in example
>
> Changes in v9:
> - Use direct node instead of syscon wrapper in example
>
> Changes in v8:
> - Use standard port reference instead of video-interfaces.yaml
> - Add parent syscon node in example to show device integration
> - Add required constraints for port@0 and port@1 in ports node
>
> Changes in v7:
> - Change compatible to imx95-csi-formatter as IP is i.MX95 specific per Marco's suggestion
> Link: https://lore.kernel.org/linux-media/20260511-csi_formatter-v6-0-01028e312e2b@oss.nxp.com/T/#mcd135b3de179b3cb69daa1fd6e0e8e27c85b3332
> ---
> .../bindings/media/fsl,imx95-csi-formatter.yaml | 88 ++++++++++++++++++++++
> 1 file changed, 88 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml b/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml
> new file mode 100644
> index 000000000000..58c4e1cc056b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml
> @@ -0,0 +1,88 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/fsl,imx95-csi-formatter.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: i.MX95 CSI Pixel Formatter
> +
> +maintainers:
> + - Guoniu Zhou <guoniu.zhou@nxp.com>
> +
> +description:
> + The CSI pixel formatting module found on i.MX95 uses packet info, pixel
> + and non-pixel data from the CSI-2 host controller and reformat them to
> + match Pixel Link(PL) definition.
> +
> +properties:
> + compatible:
> + const: fsl,imx95-csi-formatter
> +
> + reg:
> + maxItems: 1
> + description: Register offset and size within the parent syscon
> +
> + clocks:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + Input port, connects to MIPI CSI-2 receiver output (IDI interface)
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + Output port, connects to ISI input via Pixel Link (PL)
> +
> + required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - power-domains
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/nxp,imx95-clock.h>
> +
> + formatter@20 {
> + compatible = "fsl,imx95-csi-formatter";
> + reg = <0x20 0x100>;
> + clocks = <&cameramix_csr IMX95_CLK_CAMBLK_CSI2_FOR0>;
> + power-domains = <&scmi_devpd 3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + endpoint {
> + remote-endpoint = <&mipi_csi_0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + endpoint {
> + remote-endpoint = <&isi_in_2>;
> + };
> + };
> + };
> + };
>
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v10 1/4] dt-bindings: clock: imx95-blk-ctl: Use single quotes consistently
From: Frank Li @ 2026-06-18 18:40 UTC (permalink / raw)
To: guoniu.zhou
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Laurent Pinchart, Frank Li, Abel Vesa, Peng Fan,
Michael Turquette, Stephen Boyd, imx, linux-media, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, Guoniu Zhou
In-Reply-To: <20260618-csi_formatter-v10-1-f23830312ba5@oss.nxp.com>
On Thu, Jun 18, 2026 at 05:41:35PM +0800, guoniu.zhou@oss.nxp.com wrote:
> From: Guoniu Zhou <guoniu.zhou@nxp.com>
>
> Change "clocks" to 'clocks' in the description to match the quote style
> used for property names like '#clock-cells' throughout the file.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Changes in v10:
> - New patch to fix inconsistent quote usage (Krzysztof Kozlowski)
> ---
> Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> index 27403b4c52d6..534fa219d9f9 100644
> --- a/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> @@ -36,7 +36,7 @@ properties:
> const: 1
> description:
> The clock consumer should specify the desired clock by having the clock
> - ID in its "clocks" phandle cell. See
> + ID in its 'clocks' phandle cell. See
> include/dt-bindings/clock/nxp,imx95-clock.h
>
> required:
>
> --
> 2.34.1
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox