* 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
* Re: [PATCH v3 2/8] soc: qcom: Add support for QMI TMD cooling devices
From: Gaurav Kohli @ 2026-06-11 10:53 UTC (permalink / raw)
To: Dmitry Baryshkov
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, Casey Connolly
In-Reply-To: <pyt62qpa75nzdatp5xl7vcqrdzmrzsf5ethw6wq62bzg6b7qtv@ts2v53im4bos>
On 6/9/2026 5:00 PM, Dmitry Baryshkov wrote:
> On Tue, Jun 09, 2026 at 03:52:57PM +0530, Gaurav Kohli wrote:
>> From: Casey Connolly <casey.connolly@linaro.org>
>>
>> Add a Qualcomm QMI Thermal Mitigation Device (TMD) to support thermal
>> cooling devices backed by remote subsystems.
>>
>> On several Qualcomm platforms, remote processors (for example modem and
>> CDSP) expose thermal mitigation controls through the TMD QMI service.
>> Client drivers need a way to discover that service, map DT thermal
>> mitigation endpoints to cooling devices, and forward cooling state
>> updates to the remote subsystem.
>>
>> Co-developed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
>
> Wrong SoB chain.
>
Thanks for review, Ack.
>> ---
>> MAINTAINERS | 6 +
>> drivers/soc/qcom/Kconfig | 10 +
>> drivers/soc/qcom/Makefile | 1 +
>> drivers/soc/qcom/qmi_tmd.c | 604 +++++++++++++++++++++++++++++++++++++++
>> include/linux/soc/qcom/qmi.h | 1 +
>> include/linux/soc/qcom/qmi_tmd.h | 23 ++
>> 6 files changed, 645 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 57656ec0e9d5..3d60702a655a 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -22286,6 +22286,12 @@ F: Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
>> F: Documentation/networking/device_drivers/ethernet/qualcomm/ppe/ppe.rst
>> F: drivers/net/ethernet/qualcomm/ppe/
>>
>> +QUALCOMM QMI (REMOTEPROC THERMAL MITIGATION) TMD
>> +M: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>> +L: linux-arm-msm@vger.kernel.org
>> +L: linux-pm@vger.kernel.org
>> +F: drivers/soc/qcom/qmi_tmd.c
>> +
>> QUALCOMM QSEECOM DRIVER
>> M: Maximilian Luz <luzmaximilian@gmail.com>
>> L: linux-arm-msm@vger.kernel.org
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 2caadbbcf830..a292ce57fd4a 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -128,6 +128,16 @@ config QCOM_QMI_HELPERS
>> tristate
>> depends on NET
>>
>> +config QCOM_QMI_TMD
>> + bool "Qualcomm QMI TMD library" if COMPILE_TEST
>> + depends on ARCH_QCOM
>> + select QCOM_QMI_HELPERS
>> + help
>> + This enables the QMI-based Thermal Mitigation Device (TMD) library
>> + for Qualcomm remote subsystems. The library manages TMD messaging and
>> + handles QMI communication with remote processors (modem, CDSP) to
>> + exchange mitigation state and apply thermal mitigation requests.
>> +
>> config QCOM_RAMP_CTRL
>> tristate "Qualcomm Ramp Controller driver"
>> depends on ARCH_QCOM || COMPILE_TEST
>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>> index b7f1d2a57367..4544e61c74e7 100644
>> --- a/drivers/soc/qcom/Makefile
>> +++ b/drivers/soc/qcom/Makefile
>> @@ -14,6 +14,7 @@ obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink.o
>> obj-$(CONFIG_QCOM_PMIC_GLINK) += pmic_glink_altmode.o
>> obj-$(CONFIG_QCOM_PMIC_PDCHARGER_ULOG) += pmic_pdcharger_ulog.o
>> CFLAGS_pmic_pdcharger_ulog.o := -I$(src)
>> +obj-$(CONFIG_QCOM_QMI_TMD) += qmi_tmd.o
>> obj-$(CONFIG_QCOM_QMI_HELPERS) += qmi_helpers.o
>> qmi_helpers-y += qmi_encdec.o qmi_interface.o
>> obj-$(CONFIG_QCOM_RAMP_CTRL) += ramp_controller.o
>> diff --git a/drivers/soc/qcom/qmi_tmd.c b/drivers/soc/qcom/qmi_tmd.c
>> new file mode 100644
>> index 000000000000..9d88ae48c864
>> --- /dev/null
>> +++ b/drivers/soc/qcom/qmi_tmd.c
>> @@ -0,0 +1,604 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2025, Linaro Limited
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + *
>> + * QMI Thermal Mitigation Device (TMD) library.
>> + * This library provides cooling device support for remote subsystems
>> + * (modem and CDSP) running the TMD service via QMI.
>
> Why are you limiting it to these DSPs only? I quickly checked, my X13s
> (sc8280xp) also has one on the ADSP.
>
Adsp is low power dsp, not prone to thermal issues and no TMD service is
up and running. So we are defining for Cdsp and Modem only.
>> + */
>> +#include <linux/cleanup.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/module.h>
>> +#include <linux/net.h>
>> +#include <linux/of.h>
>> +#include <linux/slab.h>
>> +#include <linux/soc/qcom/qmi.h>
>> +#include <linux/soc/qcom/qmi_tmd.h>
>> +#include <linux/thermal.h>
>> +
>> +#define QMI_TMD_INSTANCE_MODEM 0x0
>> +#define QMI_TMD_INSTANCE_CDSP 0x43
>> +#define QMI_TMD_INSTANCE_CDSP1 0x44
>
> Other instances? Are those numbers fixed?
>
> Should we pass the instance ID from the PAS driver instead?
>
thanks for this suggestion, will move instance id part to pas driver.
>> +
>> +#define QMI_TMD_SERVICE_VERS_V01 0x01
>> +
>> +#define QMI_TMD_SET_LEVEL_REQ 0x0021
>> +#define QMI_TMD_GET_DEV_LIST_REQ 0x0020
>> +
>> +#define QMI_TMD_DEV_ID_LEN_MAX 32
>> +#define QMI_TMD_DEV_LIST_MAX 32
>> +#define QMI_TMD_RESP_TIMEOUT msecs_to_jiffies(100)
>> +#define TMD_GET_LEVEL_REQ_MAX_LEN 36
>> +#define TMD_SET_LEVEL_REQ_MAX_LEN 40
>> +
>> +#define TMD_GET_DEV_LIST_REQ_MAX_LEN 0
>> +#define TMD_GET_DEV_LIST_RESP_MAX_LEN 1099
>> +
>> +struct tmd_dev_id {
>> + char mitigation_dev_id[QMI_TMD_DEV_ID_LEN_MAX + 1];
>> +};
>> +
>> +static const struct qmi_elem_info tmd_dev_id_ei[] = {
>> + {
>> + .data_type = QMI_STRING,
>> + .elem_len = QMI_TMD_DEV_ID_LEN_MAX + 1,
>> + .elem_size = sizeof(char),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0,
>> + .offset = offsetof(struct tmd_dev_id,
>> + mitigation_dev_id),
>> + },
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +struct tmd_dev_list {
>> + struct tmd_dev_id mitigation_dev_id;
>> + u8 max_mitigation_level;
>> +};
>> +
>> +static const struct qmi_elem_info tmd_dev_list_ei[] = {
>> + {
>> + .data_type = QMI_STRUCT,
>> + .elem_len = 1,
>> + .elem_size = sizeof(struct tmd_dev_id),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0,
>> + .offset = offsetof(struct tmd_dev_list,
>> + mitigation_dev_id),
>> + .ei_array = tmd_dev_id_ei,
>> + },
>> + {
>> + .data_type = QMI_UNSIGNED_1_BYTE,
>> + .elem_len = 1,
>> + .elem_size = sizeof(uint8_t),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0,
>> + .offset = offsetof(struct tmd_dev_list,
>> + max_mitigation_level),
>> + },
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +struct tmd_get_dev_list_req {
>> + char placeholder;
>> +};
>> +
>> +static const struct qmi_elem_info tmd_get_dev_list_req_ei[] = {
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +struct tmd_get_dev_list_resp {
>> + struct qmi_response_type_v01 resp;
>> + u8 mitigation_device_list_valid;
>> + u32 mitigation_device_list_len;
>> + struct tmd_dev_list
>> + mitigation_device_list[QMI_TMD_DEV_LIST_MAX];
>> +};
>> +
>> +static const struct qmi_elem_info tmd_get_dev_list_resp_ei[] = {
>> + {
>> + .data_type = QMI_STRUCT,
>> + .elem_len = 1,
>> + .elem_size = sizeof(struct qmi_response_type_v01),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x02,
>> + .offset = offsetof(struct tmd_get_dev_list_resp,
>> + resp),
>> + .ei_array = qmi_response_type_v01_ei,
>> + },
>> + {
>> + .data_type = QMI_OPT_FLAG,
>> + .elem_len = 1,
>> + .elem_size = sizeof(uint8_t),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x10,
>> + .offset = offsetof(struct tmd_get_dev_list_resp,
>> + mitigation_device_list_valid),
>> + },
>> + {
>> + .data_type = QMI_DATA_LEN,
>> + .elem_len = 1,
>> + .elem_size = sizeof(uint8_t),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x10,
>> + .offset = offsetof(struct tmd_get_dev_list_resp,
>> + mitigation_device_list_len),
>> + },
>> + {
>> + .data_type = QMI_STRUCT,
>> + .elem_len = QMI_TMD_DEV_LIST_MAX,
>> + .elem_size = sizeof(struct tmd_dev_list),
>> + .array_type = VAR_LEN_ARRAY,
>> + .tlv_type = 0x10,
>> + .offset = offsetof(struct tmd_get_dev_list_resp,
>> + mitigation_device_list),
>> + .ei_array = tmd_dev_list_ei,
>> + },
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +struct tmd_set_level_req {
>> + struct tmd_dev_id mitigation_dev_id;
>> + u8 mitigation_level;
>> +};
>> +
>> +static const struct qmi_elem_info tmd_set_level_req_ei[] = {
>> + {
>> + .data_type = QMI_STRUCT,
>> + .elem_len = 1,
>> + .elem_size = sizeof(struct tmd_dev_id),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x01,
>> + .offset = offsetof(struct tmd_set_level_req,
>> + mitigation_dev_id),
>> + .ei_array = tmd_dev_id_ei,
>> + },
>> + {
>> + .data_type = QMI_UNSIGNED_1_BYTE,
>> + .elem_len = 1,
>> + .elem_size = sizeof(uint8_t),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x02,
>> + .offset = offsetof(struct tmd_set_level_req,
>> + mitigation_level),
>> + },
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +struct tmd_set_level_resp {
>> + struct qmi_response_type_v01 resp;
>> +};
>> +
>> +static const struct qmi_elem_info tmd_set_level_resp_ei[] = {
>> + {
>> + .data_type = QMI_STRUCT,
>> + .elem_len = 1,
>> + .elem_size = sizeof(struct qmi_response_type_v01),
>> + .array_type = NO_ARRAY,
>> + .tlv_type = 0x02,
>> + .offset = offsetof(struct tmd_set_level_resp, resp),
>> + .ei_array = qmi_response_type_v01_ei,
>> + },
>> + {
>> + .data_type = QMI_EOTI,
>> + .array_type = NO_ARRAY,
>> + .tlv_type = QMI_COMMON_TLV_TYPE,
>> + },
>> +};
>> +
>> +/**
>> + * struct qmi_tmd - A TMD cooling device
>> + * @name: The name of this tmd shared by the remote subsystem
>> + * @cdev: Thermal cooling device handle
>> + * @cur_state: The current mitigation state
>> + * @max_state: The maximum state
>> + * @qmi_tmd_cli: Parent QMI TMD client
>> + */
>> +struct qmi_tmd {
>> + const char *name;
>> + struct thermal_cooling_device *cdev;
>> + unsigned int cur_state;
>> + unsigned int max_state;
>> + struct qmi_tmd_client *qmi_tmd_cli;
>> +};
>> +
>> +/**
>> + * struct qmi_tmd_client - QMI TMD client state
>> + * @dev: Device associated with this instance
>> + * @handle: QMI connection handle
>> + * @mutex: Lock to synchronise QMI communication
>
> What is it protecting?
>
Ack, will add more comment for this.
This is to serialize all TMD client qmi request/response sequences such
as qmi_txn_init, qmi_send_request during Dsp subsystem restart.
>> + * @connection_active: Whether or not we're connected to the QMI TMD service
>> + * @svc_arrive_work: Work item for initialising when the TMD service starts
>> + * @num_tmds: Number of tmds described in the device tree
>> + * @tmds: An array of tmd structures
>> + */
>> +struct qmi_tmd_client {
>> + struct device *dev;
>> + struct qmi_handle handle;
>> + /* protects QMI transactions and connection_active */
>> + struct mutex mutex;
>> + bool connection_active;
>> + struct work_struct svc_arrive_work;
>> + int num_tmds;
>> + struct qmi_tmd tmds[] __counted_by(num_tmds);
>> +};
>> +
>> +/* Notify the remote subsystem of the requested cooling state */
>> +static int qmi_tmd_send_state_request(struct qmi_tmd *tmd, int state)
>> +{
>> + struct tmd_set_level_resp resp = { 0 };
>> + struct tmd_set_level_req req = { 0 };
>> + struct qmi_tmd_client *qmi_tmd_cli = tmd->qmi_tmd_cli;
>> + struct qmi_txn txn;
>> + int ret = 0;
>> +
>> + guard(mutex)(&qmi_tmd_cli->mutex);
>> +
>> + if (!qmi_tmd_cli->connection_active)
>> + return 0;
>> +
>> + strscpy(req.mitigation_dev_id.mitigation_dev_id, tmd->name,
>> + QMI_TMD_DEV_ID_LEN_MAX + 1);
>> + req.mitigation_level = state;
>> +
>> + ret = qmi_txn_init(&qmi_tmd_cli->handle, &txn,
>> + tmd_set_level_resp_ei, &resp);
>> + if (ret < 0) {
>> + dev_err(qmi_tmd_cli->dev, "qmi set state %d txn init failed for %s ret %d\n",
>> + state, tmd->name, ret);
>> + return ret;
>> + }
>> +
>> + ret = qmi_send_request(&qmi_tmd_cli->handle, NULL, &txn,
>> + QMI_TMD_SET_LEVEL_REQ,
>> + TMD_SET_LEVEL_REQ_MAX_LEN,
>> + tmd_set_level_req_ei, &req);
>> + if (ret < 0) {
>> + dev_err(qmi_tmd_cli->dev, "qmi set state %d txn send failed for %s ret %d\n",
>> + state, tmd->name, ret);
>> + qmi_txn_cancel(&txn);
>> + return ret;
>> + }
>> +
>> + ret = qmi_txn_wait(&txn, QMI_TMD_RESP_TIMEOUT);
>> + if (ret < 0) {
>> + dev_err(qmi_tmd_cli->dev, "qmi set state %d txn wait failed for %s ret %d\n",
>> + state, tmd->name, ret);
>> + return ret;
>> + }
>> +
>> + if (resp.resp.result != QMI_RESULT_SUCCESS_V01) {
>> + dev_err(qmi_tmd_cli->dev,
>> + "qmi set state %d failed for %s result %#x error %#x\n",
>> + state, tmd->name,
>> + resp.resp.result, resp.resp.error);
>> + return -EREMOTEIO;
>> + }
>> +
>> + dev_dbg(qmi_tmd_cli->dev, "Requested state %d/%d for %s\n", state,
>> + tmd->max_state, tmd->name);
>> +
>> + return 0;
>> +}
>> +
>> +static int qmi_tmd_get_max_state(struct thermal_cooling_device *cdev,
>> + unsigned long *state)
>> +{
>> + struct qmi_tmd *tmd = cdev->devdata;
>> +
>> + *state = tmd->max_state;
>> +
>> + return 0;
>> +}
>> +
>> +static int qmi_tmd_get_cur_state(struct thermal_cooling_device *cdev,
>> + unsigned long *state)
>> +{
>> + struct qmi_tmd *tmd = cdev->devdata;
>> +
>> + *state = tmd->cur_state;
>
> Mutex protection?
>
This callback only reads the cached local state and does not perform any
QMI transaction, that's why not using lock here.
>> +
>> + return 0;
>> +}
>> +
>> +static int qmi_tmd_set_cur_state(struct thermal_cooling_device *cdev,
>> + unsigned long state)
>> +{
>> + struct qmi_tmd *tmd = cdev->devdata;
>> + int ret;
>> +
>> + if (state > tmd->max_state)
>> + return -EINVAL;
>> +
>> + if (tmd->cur_state == state)
>> + return 0;
>
> Hmm, again, mutex protection for the cur_state? Or is it provided by the
> thermal core?
>
Yes, it is already protected by cdev->lock.
>> +
>> + ret = qmi_tmd_send_state_request(tmd, state);
>> + if (!ret)
>> + tmd->cur_state = state;
>> +
>> + return ret;
>> +}
>> +
>> +static const struct thermal_cooling_device_ops qmi_tmd_cooling_ops = {
>> + .get_max_state = qmi_tmd_get_max_state,
>> + .get_cur_state = qmi_tmd_get_cur_state,
>> + .set_cur_state = qmi_tmd_set_cur_state,
>> +};
>> +
>> +static int qmi_tmd_register(struct qmi_tmd_client *qmi_tmd_cli,
>> + const char *label, u8 max_state)
>> +{
>> + struct device *dev = qmi_tmd_cli->dev;
>> + struct qmi_tmd *tmd;
>> + int index;
>> +
>> + for (index = 0; index < qmi_tmd_cli->num_tmds; index++) {
>> + tmd = &qmi_tmd_cli->tmds[index];
>> +
>> + if (!strncasecmp(tmd->name, label,
>> + QMI_TMD_DEV_ID_LEN_MAX + 1))
>> + goto found;
>> + }
>> +
>> + dev_dbg(qmi_tmd_cli->dev,
>> + "TMD '%s' available in firmware but not specified in DT\n",
>> + label);
>
> If we can read them from the firmware, why do you need to specify them
> in DT?
>
We need DT, because cooling-device binding is index-based as per new
thermal framework changes:
https://lore.kernel.org/all/20260526140802.1059293-12-daniel.lezcano@oss.qualcomm.com/
And also the firmware list is name-based and ordering is not consistent
across platforms/firmware. DT provides the explicit set and order of
TMDs that thermal framework should bind. Firmware may also expose
additional/virtual TMD's that are not used for binding with thermal zone.
>> + return 0;
>> +
>> +found:
>> + tmd->max_state = max_state;
>> +
>> + /*
>> + * If the cooling device already exists then the QMI service went away and
>> + * came back. So just make sure the current cooling device state is
>> + * reflected on the remote side and then return.
>> + */
>> + if (tmd->cdev)
>> + return qmi_tmd_send_state_request(tmd, tmd->cur_state);
>> +
>> + tmd->cdev = thermal_of_cooling_device_register(dev->of_node, index,
>> + label, tmd, &qmi_tmd_cooling_ops);
>> + if (IS_ERR(tmd->cdev))
>> + return PTR_ERR(tmd->cdev);
>> +
>> + return 0;
>> +}
>> +
>> +static void qmi_tmd_unregister(struct qmi_tmd_client *qmi_tmd_cli)
>> +{
>> + struct qmi_tmd *tmd;
>> + int index;
>> +
>> + for (index = 0; index < qmi_tmd_cli->num_tmds; index++) {
>> + tmd = &qmi_tmd_cli->tmds[index];
>> +
>> + if (!tmd->cdev)
>> + continue;
>> +
>> + thermal_cooling_device_unregister(tmd->cdev);
>> + tmd->cdev = NULL;
>> + }
>> +}
>> +
>> +static void qmi_tmd_svc_arrive(struct work_struct *work)
>> +{
>> + struct qmi_tmd_client *qmi_tmd_cli =
>> + container_of(work, struct qmi_tmd_client, svc_arrive_work);
>> +
>> + struct tmd_get_dev_list_req req = { 0 };
>> + struct tmd_get_dev_list_resp *resp __free(kfree) = NULL;
>> + int ret, i;
>> + struct qmi_txn txn;
>> +
>> + resp = kzalloc_obj(*resp, GFP_KERNEL);
>> + if (!resp) {
>> + ret = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + scoped_guard(mutex, &qmi_tmd_cli->mutex) {
>> + ret = qmi_txn_init(&qmi_tmd_cli->handle, &txn,
>> + tmd_get_dev_list_resp_ei, resp);
>> + if (ret < 0)
>> + goto out;
>> +
>> + ret = qmi_send_request(&qmi_tmd_cli->handle, NULL, &txn,
>> + QMI_TMD_GET_DEV_LIST_REQ,
>> + TMD_GET_DEV_LIST_REQ_MAX_LEN,
>> + tmd_get_dev_list_req_ei, &req);
>> + if (ret < 0) {
>> + qmi_txn_cancel(&txn);
>> + goto out;
>> + }
>> +
>> + ret = qmi_txn_wait(&txn, QMI_TMD_RESP_TIMEOUT);
>> + if (ret < 0)
>> + goto out;
>> +
>> + if (resp->resp.result != QMI_RESULT_SUCCESS_V01) {
>> + ret = -EPROTO;
>> + goto out;
>> + }
>> +
>> + qmi_tmd_cli->connection_active = true;
>> + }
>> +
>> + for (i = 0; i < resp->mitigation_device_list_len; i++) {
>> + struct tmd_dev_list *device =
>> + &resp->mitigation_device_list[i];
>> +
>> + ret = qmi_tmd_register(qmi_tmd_cli,
>> + device->mitigation_dev_id.mitigation_dev_id,
>> + device->max_mitigation_level);
>> + if (ret)
>> + break;
>> + }
>> +
>> +out:
>> + if (ret)
>> + dev_err(qmi_tmd_cli->dev, "Failed to initialize TMD service: %d\n", ret);
>> +}
>> +
>> +static void qmi_tmd_del_server(struct qmi_handle *qmi, struct qmi_service *service)
>> +{
>> + struct qmi_tmd_client *qmi_tmd_cli =
>> + container_of(qmi, struct qmi_tmd_client, handle);
>> +
>> + kernel_sock_shutdown(qmi->sock, SHUT_RDWR);
>
> So, connection is protected by the mutex, but socket shutdown isn't.
> Why?
>
Ack.
>> +
>> + scoped_guard(mutex, &qmi_tmd_cli->mutex)
>> + qmi_tmd_cli->connection_active = false;
>> +}
>> +
>> +static int qmi_tmd_new_server(struct qmi_handle *qmi, struct qmi_service *service)
>> +{
>> + struct sockaddr_qrtr sq = { AF_QIPCRTR, service->node, service->port };
>> + struct qmi_tmd_client *qmi_tmd_cli;
>> + int ret;
>> +
>> + qmi_tmd_cli = container_of(qmi, struct qmi_tmd_client, handle);
>> +
>> + scoped_guard(mutex, &qmi_tmd_cli->mutex) {
>> + ret = kernel_connect(qmi->sock, (struct sockaddr_unsized *)&sq,
>> + sizeof(sq), 0);
>> + }
>> +
>> + if (ret < 0) {
>> + dev_err(qmi_tmd_cli->dev, "QMI connect failed for node %u port %u: %d\n",
>> + service->node, service->port, ret);
>> + return ret;
>> + }
>> +
>> + queue_work(system_highpri_wq, &qmi_tmd_cli->svc_arrive_work);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct qmi_ops qmi_tmd_ops = {
>> + .new_server = qmi_tmd_new_server,
>> + .del_server = qmi_tmd_del_server,
>> +};
>> +
>> +static int qmi_tmd_get_instance_id(const char *remoteproc_name)
>> +{
>> + if (!strcmp(remoteproc_name, "modem"))
>> + return QMI_TMD_INSTANCE_MODEM;
>> +
>> + if (!strcmp(remoteproc_name, "cdsp"))
>> + return QMI_TMD_INSTANCE_CDSP;
>> +
>> + if (!strcmp(remoteproc_name, "cdsp1"))
>> + return QMI_TMD_INSTANCE_CDSP1;
>> +
>> + return -ENODEV;
>
> Okay, this definitely should be coming from the PAS driver, being a part
> of the platform data.
>
thanks for this suggestion, let me check with this approach and make
changes.
>> +}
>> +
>> +/**
>> + * qmi_tmd_init() - Initialize QMI TMD instance
>> + * @dev: Device pointer
>> + * @remoteproc_name: Remoteproc name (for example modem, cdsp)
>> + * @tmd_names: Array of TMD names
>> + * @num_tmds: Number of TMD names
>> + *
>> + * Return: Pointer to qmi_tmd_client on success, ERR_PTR on failure
>> + */
>> +struct qmi_tmd_client *qmi_tmd_init(struct device *dev,
>> + const char *remoteproc_name,
>> + const char * const *tmd_names,
>> + int num_tmds)
>> +{
>> + struct qmi_tmd_client *qmi_tmd_cli;
>> + int ret, i, instance_id;
>> +
>> + if (!dev || !remoteproc_name || !tmd_names || num_tmds <= 0)
>> + return ERR_PTR(-EINVAL);
>> +
>> + instance_id = qmi_tmd_get_instance_id(remoteproc_name);
>> + if (instance_id < 0) {
>> + dev_err(dev, "Unsupported remoteproc name '%s' for TMD lookup\n",
>> + remoteproc_name);
>> + return ERR_PTR(instance_id);
>> + }
>> +
>> + qmi_tmd_cli = devm_kzalloc(dev, struct_size(qmi_tmd_cli, tmds, num_tmds), GFP_KERNEL);
>> + if (!qmi_tmd_cli)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + qmi_tmd_cli->dev = dev;
>> + qmi_tmd_cli->num_tmds = num_tmds;
>> + mutex_init(&qmi_tmd_cli->mutex);
>> + INIT_WORK(&qmi_tmd_cli->svc_arrive_work, qmi_tmd_svc_arrive);
>> +
>> + /* Initialize TMD structures */
>
> Is it a useful comment?
>
>> + for (i = 0; i < num_tmds; i++) {
>> + qmi_tmd_cli->tmds[i].name = tmd_names[i];
>> + qmi_tmd_cli->tmds[i].qmi_tmd_cli = qmi_tmd_cli;
>> + }
>> +
>> + ret = qmi_handle_init(&qmi_tmd_cli->handle,
>> + TMD_GET_DEV_LIST_RESP_MAX_LEN,
>> + &qmi_tmd_ops, NULL);
>> + if (ret < 0) {
>> + dev_err(dev, "QMI handle init failed: %d\n", ret);
>> + return ERR_PTR(ret);
>> + }
>> +
>> + ret = qmi_add_lookup(&qmi_tmd_cli->handle, QMI_SERVICE_ID_TMD,
>> + QMI_TMD_SERVICE_VERS_V01, instance_id);
>> + if (ret < 0) {
>> + dev_err(dev, "QMI add lookup failed: %d\n", ret);
>> + goto err_release_handle;
>> + }
>> +
>> + return qmi_tmd_cli;
>> +
>> +err_release_handle:
>> + qmi_handle_release(&qmi_tmd_cli->handle);
>> +
>> + return ERR_PTR(ret);
>> +}
>> +EXPORT_SYMBOL_GPL(qmi_tmd_init);
>> +
>> +/**
>> + * qmi_tmd_exit() - Deinitialize QMI TMD instance
>> + * @qmi_tmd_cli: QMI TMD client to deinitialize
>> + */
>> +void qmi_tmd_exit(struct qmi_tmd_client *qmi_tmd_cli)
>> +{
>> + if (!qmi_tmd_cli)
>> + return;
>> +
>> + cancel_work_sync(&qmi_tmd_cli->svc_arrive_work);
>> + qmi_handle_release(&qmi_tmd_cli->handle);
>> + qmi_tmd_unregister(qmi_tmd_cli);
>> +
>> + scoped_guard(mutex, &qmi_tmd_cli->mutex)
>> + qmi_tmd_cli->connection_active = false;
>> +}
>> +EXPORT_SYMBOL_GPL(qmi_tmd_exit);
>
^ permalink raw reply
* Re: [PATCH v5 3/4] clk: qcom: smd-rpm: Add missing RF_CLK1/RF_CLK2 clocks support on Agatti
From: Imran Shaik @ 2026-06-11 10:52 UTC (permalink / raw)
To: Konrad Dybcio, 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: <b86e9f5f-a7ec-489e-829e-6e07c62841a3@oss.qualcomm.com>
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.
Thanks,
Imran
^ permalink raw reply
* Re: [PATCH V11 4/9] iio: imu: inv_icm42607: Add I2C and SPI For icm42607
From: Jonathan Cameron @ 2026-06-11 10:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, Chris Morgan
In-Reply-To: <aipolU1W3QNXdd5b@ashevche-desk.local>
On Thu, 11 Jun 2026 10:49:41 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Wed, Jun 10, 2026 at 12:54:48PM -0500, Chris Morgan wrote:
>
> > Add I2C and SPI driver support for InvenSense ICM-42607 devices.
> > Add necessary Kconfig and Makefile to allow building of (incomplete)
> > driver.
>
> ...
>
> > drivers/iio/imu/Kconfig | 1 +
> > drivers/iio/imu/Makefile | 1 +
> > drivers/iio/imu/inv_icm42607/Kconfig | 30 +++++
> > drivers/iio/imu/inv_icm42607/Makefile | 10 ++
>
> These should be part of the previous patch.
>
> ...
>
> > +config INV_ICM42607
> > + tristate
>
> To make it compilable w.o. SPI/I2C make this as
>
> tristate "Inven... Core driver" if COMPILE_TEST
Hi Andy,
Is it worth it? I'm not convinced - we will get pretty
good build coverage with a dependence on either SPI or I2C.
Plus as someone who always builds with COMPILE_TEST this
seems overly noisy to me.
Jonathan
^ permalink raw reply
* Re: [PATCH v1 1/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: Krzysztof Kozlowski @ 2026-06-11 10:51 UTC (permalink / raw)
To: Zhang Yi; +Cc: linux-sound, broonie, devicetree, tiwai, robh, krzk+dt, conor+dt
In-Reply-To: <20260611-mamba-of-legendary-anger-af76a9@quoll>
On 11/06/2026 12:45, Krzysztof Kozlowski wrote:
> On Thu, Jun 11, 2026 at 11:18:18AM +0800, Zhang Yi wrote:
>> Add members related to HPF and mclk_source
>> The value of HPF is not dB, it is just the value of registers
>> And add HPF settings to the example
>>
>> Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
>> ---
>> .../bindings/sound/everest,es8389.yaml | 23 +++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>
> So this is like third time you send the same.
>
> You never responded to feedback, I don't see improvements and you keep
> sending the same v1.
>
> Version your patches correctly - read help of git format-patch or just
> use b4.
>
> NAK again because you just ignore us.
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.
Best regards,
Krzysztof
^ 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