[RESEND PATCH v2 0/2] iio: frequency: adf4377: add clock provider support

[RESEND PATCH v2 0/2] iio: frequency: adf4377: add clock provider support

[Antoniu Miclaus]

This series adds clock provider functionality to the ADF4377 frequency
synthesizer driver to address user requests for controlling output
frequencies from userspace.

While implemented as an IIO driver, the ADF4377 is commonly used as a
clock source. This patch series enables it to function as either:
- A traditional IIO device (when #clock-cells is not specified)
- A clock provider (when #clock-cells is present in device tree)

The implementation provides standard clock framework integration with
rate control, enable/disable support, and maintains backward
compatibility with existing IIO configurations.

Antoniu Miclaus (2):
  dt-bindings: iio: frequency: adf4377: add clk provider
  iio: frequency: adf4377: add clk provider support

 .../bindings/iio/frequency/adi,adf4377.yaml   |   8 ++
 drivers/iio/frequency/adf4377.c               | 119 +++++++++++++++++-
 2 files changed, 125 insertions(+), 2 deletions(-)

-- 
2.43.0

[RESEND PATCH v2 1/2] dt-bindings: iio: frequency: adf4377: add clk provider

[Antoniu Miclaus]

Add support for clock provider.

Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
changes in v2:
 - fix commit title
 - drop _clk suffix for clock names
 - drop additional example and update the existing one
 .../devicetree/bindings/iio/frequency/adi,adf4377.yaml    | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml
index 5f950ee9aec7..be69b9c68e74 100644
--- a/Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,adf4377.yaml
@@ -40,6 +40,12 @@ properties:
     items:
       - const: ref_in
 
+  '#clock-cells':
+    const: 0
+
+  clock-output-names:
+    maxItems: 1
+
   chip-enable-gpios:
     description:
       GPIO that controls the Chip Enable Pin.
@@ -97,6 +103,8 @@ examples:
             spi-max-frequency = <10000000>;
             clocks = <&adf4377_ref_in>;
             clock-names = "ref_in";
+            #clock-cells = <0>;
+            clock-output-names = "adf4377";
         };
     };
 ...
-- 
2.43.0

[RESEND PATCH v2 2/2] iio: frequency: adf4377: add clk provider support

[Antoniu Miclaus]

Add clk provider feature for the adf4377.

Even though the driver was sent as an IIO driver in most cases the
device is actually seen as a clock provider.

This patch aims to cover actual usecases requested by users in order to
completely control the output frequencies from userspace.

Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
Changes in v2:
- Replace deprecated .is_enabled clock operation with .is_prepared
- Use modern devm_clk_hw_register() instead of devm_clk_register()
- Switch to clk_parent_data with fw_name instead of parent_names array
- Use devm_of_clk_add_hw_provider() with of_clk_hw_simple_get for modern DT integration
- Fix indentation alignment in adf4377_clk_recalc_rate function parameter
- Remove manual clock provider cleanup by using devm_* variants
 drivers/iio/frequency/adf4377.c | 119 +++++++++++++++++++++++++++++++-
 1 file changed, 117 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/frequency/adf4377.c b/drivers/iio/frequency/adf4377.c
index 08833b7035e4..045747351ed7 100644
--- a/drivers/iio/frequency/adf4377.c
+++ b/drivers/iio/frequency/adf4377.c
@@ -8,6 +8,7 @@
 #include <linux/bitfield.h>
 #include <linux/bits.h>
 #include <linux/clk.h>
+#include <linux/clk-provider.h>
 #include <linux/clkdev.h>
 #include <linux/delay.h>
 #include <linux/device.h>
@@ -435,9 +436,14 @@ struct adf4377_state {
 	struct gpio_desc	*gpio_ce;
 	struct gpio_desc	*gpio_enclk1;
 	struct gpio_desc	*gpio_enclk2;
+	struct clk		*clk;
+	struct clk		*clkout;
+	struct clk_hw		hw;
 	u8			buf[2] __aligned(IIO_DMA_MINALIGN);
 };
 
+#define to_adf4377_state(h)	container_of(h, struct adf4377_state, hw)
+
 static const char * const adf4377_muxout_modes[] = {
 	[ADF4377_MUXOUT_HIGH_Z] = "high_z",
 	[ADF4377_MUXOUT_LKDET] = "lock_detect",
@@ -929,6 +935,108 @@ static int adf4377_freq_change(struct notifier_block *nb, unsigned long action,
 	return NOTIFY_OK;
 }
 
+static unsigned long adf4377_clk_recalc_rate(struct clk_hw *hw,
+					     unsigned long parent_rate)
+{
+	struct adf4377_state *st = to_adf4377_state(hw);
+	u64 freq;
+	int ret;
+
+	ret = adf4377_get_freq(st, &freq);
+	if (ret)
+		return 0;
+
+	return freq;
+}
+
+static int adf4377_clk_set_rate(struct clk_hw *hw,
+				unsigned long rate,
+				unsigned long parent_rate)
+{
+	struct adf4377_state *st = to_adf4377_state(hw);
+
+	return adf4377_set_freq(st, rate);
+}
+
+static int adf4377_clk_prepare(struct clk_hw *hw)
+{
+	struct adf4377_state *st = to_adf4377_state(hw);
+
+	return regmap_update_bits(st->regmap, 0x1a, ADF4377_001A_PD_CLKOUT1_MSK |
+				  ADF4377_001A_PD_CLKOUT2_MSK,
+				  FIELD_PREP(ADF4377_001A_PD_CLKOUT1_MSK, 0) |
+				  FIELD_PREP(ADF4377_001A_PD_CLKOUT2_MSK, 0));
+}
+
+static void adf4377_clk_unprepare(struct clk_hw *hw)
+{
+	struct adf4377_state *st = to_adf4377_state(hw);
+
+	regmap_update_bits(st->regmap, 0x1a, ADF4377_001A_PD_CLKOUT1_MSK |
+			   ADF4377_001A_PD_CLKOUT2_MSK,
+			   FIELD_PREP(ADF4377_001A_PD_CLKOUT1_MSK, 1) |
+			   FIELD_PREP(ADF4377_001A_PD_CLKOUT2_MSK, 1));
+}
+
+static int adf4377_clk_is_prepared(struct clk_hw *hw)
+{
+	struct adf4377_state *st = to_adf4377_state(hw);
+	unsigned int readval;
+	int ret;
+
+	ret = regmap_read(st->regmap, 0x1a, &readval);
+	if (ret)
+		return ret;
+
+	return !(readval & (ADF4377_001A_PD_CLKOUT1_MSK | ADF4377_001A_PD_CLKOUT2_MSK));
+}
+
+static const struct clk_ops adf4377_clk_ops = {
+	.recalc_rate = adf4377_clk_recalc_rate,
+	.set_rate = adf4377_clk_set_rate,
+	.prepare = adf4377_clk_prepare,
+	.unprepare = adf4377_clk_unprepare,
+	.is_prepared = adf4377_clk_is_prepared,
+};
+
+static int adf4377_clk_register(struct adf4377_state *st)
+{
+	struct spi_device *spi = st->spi;
+	struct clk_init_data init;
+	struct clk_parent_data parent_data;
+	int ret;
+
+	if (!device_property_present(&spi->dev, "#clock-cells"))
+		return 0;
+
+	if (device_property_read_string(&spi->dev, "clock-output-names", &init.name)) {
+		init.name = devm_kasprintf(&spi->dev, GFP_KERNEL, "%s-clk",
+					   fwnode_get_name(dev_fwnode(&spi->dev)));
+		if (!init.name)
+			return -ENOMEM;
+	}
+
+	parent_data.fw_name = "ref_in";
+
+	init.ops = &adf4377_clk_ops;
+	init.parent_data = &parent_data;
+	init.num_parents = 1;
+	init.flags = CLK_SET_RATE_PARENT;
+
+	st->hw.init = &init;
+	ret = devm_clk_hw_register(&spi->dev, &st->hw);
+	if (ret)
+		return ret;
+
+	ret = devm_of_clk_add_hw_provider(&spi->dev, of_clk_hw_simple_get, &st->hw);
+	if (ret)
+		return ret;
+
+	st->clkout = st->hw.clk;
+
+	return 0;
+}
+
 static const struct adf4377_chip_info adf4377_chip_info = {
 	.name = "adf4377",
 	.has_gpio_enclk2 = true,
@@ -958,8 +1066,6 @@ static int adf4377_probe(struct spi_device *spi)
 
 	indio_dev->info = &adf4377_info;
 	indio_dev->name = "adf4377";
-	indio_dev->channels = adf4377_channels;
-	indio_dev->num_channels = ARRAY_SIZE(adf4377_channels);
 
 	st->regmap = regmap;
 	st->spi = spi;
@@ -979,6 +1085,15 @@ static int adf4377_probe(struct spi_device *spi)
 	if (ret)
 		return ret;
 
+	ret = adf4377_clk_register(st);
+	if (ret)
+		return ret;
+
+	if (!st->clkout) {
+		indio_dev->channels = adf4377_channels;
+		indio_dev->num_channels = ARRAY_SIZE(adf4377_channels);
+	}
+
 	return devm_iio_device_register(&spi->dev, indio_dev);
 }
 
-- 
2.43.0

Re: [RESEND PATCH v2 0/2] iio: frequency: adf4377: add clock provider support

[David Lechner]

On 11/21/25 3:59 AM, Antoniu Miclaus wrote:
> This series adds clock provider functionality to the ADF4377 frequency
> synthesizer driver to address user requests for controlling output
> frequencies from userspace.
> 
> While implemented as an IIO driver, the ADF4377 is commonly used as a
> clock source. This patch series enables it to function as either:
> - A traditional IIO device (when #clock-cells is not specified)
> - A clock provider (when #clock-cells is present in device tree)
> 
> The implementation provides standard clock framework integration with
> rate control, enable/disable support, and maintains backward
> compatibility with existing IIO configurations.
> 
> Antoniu Miclaus (2):
>   dt-bindings: iio: frequency: adf4377: add clk provider
>   iio: frequency: adf4377: add clk provider support
> 
>  .../bindings/iio/frequency/adi,adf4377.yaml   |   8 ++
>  drivers/iio/frequency/adf4377.c               | 119 +++++++++++++++++-
>  2 files changed, 125 insertions(+), 2 deletions(-)
> 

When doing a RESEND, please add a note that says why.

Also, you still didn't include the clock mailing list or maintainers,
so I don't expect this to progress since the last time.

Re: [RESEND PATCH v2 0/2] iio: frequency: adf4377: add clock provider support

[Miclaus, Antoniu]

>On 11/21/25 3:59 AM, Antoniu Miclaus wrote:
>> This series adds clock provider functionality to the ADF4377 frequency
>> synthesizer driver to address user requests for controlling output
>> frequencies from userspace.
>> 
>> While implemented as an IIO driver, the ADF4377 is commonly used as a
>> clock source. This patch series enables it to function as either:
>> - A traditional IIO device (when #clock-cells is not specified)
>> - A clock provider (when #clock-cells is present in device tree)
>> 
>> The implementation provides standard clock framework integration with
>> rate control, enable/disable support, and maintains backward
>> compatibility with existing IIO configurations.
>> 
>> Antoniu Miclaus (2):
>>   dt-bindings: iio: frequency: adf4377: add clk provider
>>   iio: frequency: adf4377: add clk provider support
>> 
>>  .../bindings/iio/frequency/adi,adf4377.yaml   |   8 ++
>>  drivers/iio/frequency/adf4377.c               | 119 +++++++++++++++++-
>>  2 files changed, 125 insertions(+), 2 deletions(-)
>> 
>
>When doing a RESEND, please add a note that says why.
>
>Also, you still didn't include the clock mailing list or maintainers,
>so I don't expect this to progress since the last time.

I forgot to mention in the resend patch, but i missed some of the changes 
when i sent the first v2 series.
Should i send a v3 with the mentions + clock mailing list?
Or do another RESEND PATCH for v2?

Re: [RESEND PATCH v2 0/2] iio: frequency: adf4377: add clock provider support

[David Lechner]

On 11/24/25 6:09 AM, Miclaus, Antoniu wrote:
>> On 11/21/25 3:59 AM, Antoniu Miclaus wrote:
>>> This series adds clock provider functionality to the ADF4377 frequency
>>> synthesizer driver to address user requests for controlling output
>>> frequencies from userspace.
>>>
>>> While implemented as an IIO driver, the ADF4377 is commonly used as a
>>> clock source. This patch series enables it to function as either:
>>> - A traditional IIO device (when #clock-cells is not specified)
>>> - A clock provider (when #clock-cells is present in device tree)
>>>
>>> The implementation provides standard clock framework integration with
>>> rate control, enable/disable support, and maintains backward
>>> compatibility with existing IIO configurations.
>>>
>>> Antoniu Miclaus (2):
>>>    dt-bindings: iio: frequency: adf4377: add clk provider
>>>    iio: frequency: adf4377: add clk provider support
>>>
>>>   .../bindings/iio/frequency/adi,adf4377.yaml   |   8 ++
>>>   drivers/iio/frequency/adf4377.c               | 119 +++++++++++++++++-
>>>   2 files changed, 125 insertions(+), 2 deletions(-)
>>>
>>
>> When doing a RESEND, please add a note that says why.
>>
>> Also, you still didn't include the clock mailing list or maintainers,
>> so I don't expect this to progress since the last time.
> 
> I forgot to mention in the resend patch, but i missed some of the changes 
> when i sent the first v2 series.
> Should i send a v3 with the mentions + clock mailing list?

Doing a v3 with a proper changelog compared to the original v2
+ cc the clock list/maintainers seems like the best way to me.

> Or do another RESEND PATCH for v2?
> 

No, I think that would confuse things even more.