From: Abdurrahman Hussain <abdurrahman@nexthop.ai>

The xiic driver is designed to operate without explicit clock configuration
when clocks are not specified in the firmware.

Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
---
 Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml b/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
index 658ae92fa86d..cc500130f41f 100644
--- a/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
+++ b/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
@@ -43,7 +43,6 @@ required:
   - compatible
   - reg
   - interrupts
-  - clocks
 
 unevaluatedProperties: false
 

-- 
2.52.0

On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:
> The xiic driver is designed to operate without explicit clock configuration

And if you change this in the driver, then you change bindings?

You miss here explanation based on hardware - how does the hardware work
if nothing ticks it clocks?

Best regards,
Krzysztof

On 1/28/26 11:37, Krzysztof Kozlowski wrote:
> On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:
>> The xiic driver is designed to operate without explicit clock configuration
> 
> And if you change this in the driver, then you change bindings?
> 
> You miss here explanation based on hardware - how does the hardware work
> if nothing ticks it clocks?

Hardware obviously have clock input which needs to be connected. Without it it 
won't work.
And there are designs like Microblaze one where clock is shared with cpu itself 
and there is no way to adjust it. It is just working.

Then we have configurations where clock is coming from clock generator which 
needs to be enabled. That's case for SOCs with ARM cpus or with clock generators.

This series targets case around PCIe EP. Clock is likely derived from PCIe 
itself and there is no way how to change it, adjust it. It is just running on 
fixed value.

In DT this is design/described via fixed-clock but I expect this concept is not 
used on systems with ACPI.

Thanks,
Michal

On Wed, Jan 28, 2026 at 12:21:41PM +0100, Michal Simek wrote:
> 
> 
> On 1/28/26 11:37, Krzysztof Kozlowski wrote:
> > On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:
> > > The xiic driver is designed to operate without explicit clock configuration
> > 
> > And if you change this in the driver, then you change bindings?
> > 
> > You miss here explanation based on hardware - how does the hardware work
> > if nothing ticks it clocks?
> 
> Hardware obviously have clock input which needs to be connected. Without it
> it won't work.

Should ACPI potential limitations be making the DT description less
accurate?

Would it not be better that the driver has an DT binding and an ACPI
binding? Where there are common properties, common functions can be
used to retrieve them. However, if ACPI lacks usable clocks, use the
of_ method to get the clock from DT, and skip it for ACPI.

    Andrew

On Wed, Jan 28, 2026 at 03:34:02PM +0100, Andrew Lunn wrote:
> On Wed, Jan 28, 2026 at 12:21:41PM +0100, Michal Simek wrote:
> > On 1/28/26 11:37, Krzysztof Kozlowski wrote:
> > > On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:
> > > > The xiic driver is designed to operate without explicit clock configuration
> > > 
> > > And if you change this in the driver, then you change bindings?
> > > 
> > > You miss here explanation based on hardware - how does the hardware work
> > > if nothing ticks it clocks?
> > 
> > Hardware obviously have clock input which needs to be connected. Without it
> > it won't work.
> 
> Should ACPI potential limitations be making the DT description less
> accurate?
> 
> Would it not be better that the driver has an DT binding and an ACPI
> binding? Where there are common properties, common functions can be
> used to retrieve them. However, if ACPI lacks usable clocks, use the
> of_ method to get the clock from DT, and skip it for ACPI.

Why should we use of_ methods? If this is required we can check the type of
fwnode and act accordingly, but I think this should go deeper into some
treewide available helpers, because now some drivers repeat the mantra.

But how do the driver get the clock frequency (if needed for some register
settings and/or calculations)? DT seems to have well established property
'clock-frequency' for that. Can we consider it as "ACPI binding" as well?

-- 
With Best Regards,
Andy Shevchenko

On Wed, Jan 28, 2026 at 04:45:12PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 28, 2026 at 03:34:02PM +0100, Andrew Lunn wrote:
> > On Wed, Jan 28, 2026 at 12:21:41PM +0100, Michal Simek wrote:
> > > On 1/28/26 11:37, Krzysztof Kozlowski wrote:
> > > > On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:
> > > > > The xiic driver is designed to operate without explicit clock configuration
> > > > 
> > > > And if you change this in the driver, then you change bindings?
> > > > 
> > > > You miss here explanation based on hardware - how does the hardware work
> > > > if nothing ticks it clocks?
> > > 
> > > Hardware obviously have clock input which needs to be connected. Without it
> > > it won't work.
> > 
> > Should ACPI potential limitations be making the DT description less
> > accurate?
> > 
> > Would it not be better that the driver has an DT binding and an ACPI
> > binding? Where there are common properties, common functions can be
> > used to retrieve them. However, if ACPI lacks usable clocks, use the
> > of_ method to get the clock from DT, and skip it for ACPI.
> 
> Why should we use of_ methods? If this is required we can check the type of
> fwnode and act accordingly, but I think this should go deeper into some
> treewide available helpers, because now some drivers repeat the mantra.
> 
> But how do the driver get the clock frequency (if needed for some register
> settings and/or calculations)? DT seems to have well established property
> 'clock-frequency' for that. Can we consider it as "ACPI binding" as well?

Well established and somewhat deprecated. Generally, 'clocks' should be 
used instead. There are some exceptions like I2C buses here to set the 
bus frequency (or max freq). We probably should have used 
'bus-frequency' in this case, but that predates me.

ACPI can use whatever the ACPI binding maintainers want. If you know who 
they are, please let me know. :)

Rob

On Thu, Jan 29, 2026 at 10:14:04AM -0600, Rob Herring wrote:
> On Wed, Jan 28, 2026 at 04:45:12PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 28, 2026 at 03:34:02PM +0100, Andrew Lunn wrote:
> > > On Wed, Jan 28, 2026 at 12:21:41PM +0100, Michal Simek wrote:
> > > > On 1/28/26 11:37, Krzysztof Kozlowski wrote:
> > > > > On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:
> > > > > > The xiic driver is designed to operate without explicit clock configuration
> > > > > 
> > > > > And if you change this in the driver, then you change bindings?
> > > > > 
> > > > > You miss here explanation based on hardware - how does the hardware work
> > > > > if nothing ticks it clocks?
> > > > 
> > > > Hardware obviously have clock input which needs to be connected. Without it
> > > > it won't work.
> > > 
> > > Should ACPI potential limitations be making the DT description less
> > > accurate?
> > > 
> > > Would it not be better that the driver has an DT binding and an ACPI
> > > binding? Where there are common properties, common functions can be
> > > used to retrieve them. However, if ACPI lacks usable clocks, use the
> > > of_ method to get the clock from DT, and skip it for ACPI.
> > 
> > Why should we use of_ methods? If this is required we can check the type of
> > fwnode and act accordingly, but I think this should go deeper into some
> > treewide available helpers, because now some drivers repeat the mantra.
> > 
> > But how do the driver get the clock frequency (if needed for some register
> > settings and/or calculations)? DT seems to have well established property
> > 'clock-frequency' for that. Can we consider it as "ACPI binding" as well?
> 
> Well established and somewhat deprecated. Generally, 'clocks' should be 
> used instead. There are some exceptions like I2C buses here to set the 
> bus frequency (or max freq). We probably should have used 
> 'bus-frequency' in this case, but that predates me.
> 
> ACPI can use whatever the ACPI binding maintainers want. If you know who 
> they are, please let me know. :)

There is no such "entity" AFAIK, as on ACPI side we try pushing vendors to make
their efforts to bring a standard. Nevertheless, we have players, like MSFT, who
make decisions on their own (hence we have tons of "extensions" to the ACPI and
other specifications. Speaking of the standard, we have UEFI, MIPI and problably
others that have their own properties (but standard) and they usually use dedicated
prefixes (uefi-*, mipi-*). Also we have custom vendor specific ones, for example,
Intel in some cases (legit I suppose, as it's about Intel's IP) provides intc-*
properties. In many cases, though we have utilisation of the DT properties and
vendors more or less follow that. (Disclaimer: I described how I see it's done,
and not how I think it has to be done)

-- 
With Best Regards,
Andy Shevchenko

On 1/28/26 15:45, Andy Shevchenko wrote:
> On Wed, Jan 28, 2026 at 03:34:02PM +0100, Andrew Lunn wrote:
>> On Wed, Jan 28, 2026 at 12:21:41PM +0100, Michal Simek wrote:
>>> On 1/28/26 11:37, Krzysztof Kozlowski wrote:
>>>> On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:
>>>>> The xiic driver is designed to operate without explicit clock configuration
>>>>
>>>> And if you change this in the driver, then you change bindings?
>>>>
>>>> You miss here explanation based on hardware - how does the hardware work
>>>> if nothing ticks it clocks?
>>>
>>> Hardware obviously have clock input which needs to be connected. Without it
>>> it won't work.
>>
>> Should ACPI potential limitations be making the DT description less
>> accurate?
>>
>> Would it not be better that the driver has an DT binding and an ACPI
>> binding? Where there are common properties, common functions can be
>> used to retrieve them. However, if ACPI lacks usable clocks, use the
>> of_ method to get the clock from DT, and skip it for ACPI.
> 
> Why should we use of_ methods? If this is required we can check the type of
> fwnode and act accordingly, but I think this should go deeper into some
> treewide available helpers, because now some drivers repeat the mantra.
> 
> But how do the driver get the clock frequency (if needed for some register
> settings and/or calculations)? DT seems to have well established property
> 'clock-frequency' for that. Can we consider it as "ACPI binding" as well?

"clock-frequency" property in i2c is used for selecting i2c speed 100/400kHz.

Clock frequency in this driver is about describing clock coming to IP itself.
Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml

Thanks,
Michal

On Wed, Jan 28, 2026 at 04:00:30PM +0100, Michal Simek wrote:
> On 1/28/26 15:45, Andy Shevchenko wrote:
> > On Wed, Jan 28, 2026 at 03:34:02PM +0100, Andrew Lunn wrote:
> > > On Wed, Jan 28, 2026 at 12:21:41PM +0100, Michal Simek wrote:
> > > > On 1/28/26 11:37, Krzysztof Kozlowski wrote:
> > > > > On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:
> > > > > > The xiic driver is designed to operate without explicit clock configuration
> > > > > 
> > > > > And if you change this in the driver, then you change bindings?
> > > > > 
> > > > > You miss here explanation based on hardware - how does the hardware work
> > > > > if nothing ticks it clocks?
> > > > 
> > > > Hardware obviously have clock input which needs to be connected. Without it
> > > > it won't work.
> > > 
> > > Should ACPI potential limitations be making the DT description less
> > > accurate?
> > > 
> > > Would it not be better that the driver has an DT binding and an ACPI
> > > binding? Where there are common properties, common functions can be
> > > used to retrieve them. However, if ACPI lacks usable clocks, use the
> > > of_ method to get the clock from DT, and skip it for ACPI.
> > 
> > Why should we use of_ methods? If this is required we can check the type of
> > fwnode and act accordingly, but I think this should go deeper into some
> > treewide available helpers, because now some drivers repeat the mantra.
> > 
> > But how do the driver get the clock frequency (if needed for some register
> > settings and/or calculations)? DT seems to have well established property
> > 'clock-frequency' for that. Can we consider it as "ACPI binding" as well?
> 
> "clock-frequency" property in i2c is used for selecting i2c speed 100/400kHz.
> 
> Clock frequency in this driver is about describing clock coming to IP itself.
> Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml

Ah, I see, then is_of_node() probably is the compromise how to deal with
this setup.

-- 
With Best Regards,
Andy Shevchenko

> On Jan 28, 2026, at 7:43 AM, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> 
> On Wed, Jan 28, 2026 at 04:00:30PM +0100, Michal Simek wrote:
>> On 1/28/26 15:45, Andy Shevchenko wrote:
>>> On Wed, Jan 28, 2026 at 03:34:02PM +0100, Andrew Lunn wrote:
>>>> On Wed, Jan 28, 2026 at 12:21:41PM +0100, Michal Simek wrote:
>>>>> On 1/28/26 11:37, Krzysztof Kozlowski wrote:
>>>>>> On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:
>>>>>>> The xiic driver is designed to operate without explicit clock configuration
>>>>>> 
>>>>>> And if you change this in the driver, then you change bindings?
>>>>>> 
>>>>>> You miss here explanation based on hardware - how does the hardware work
>>>>>> if nothing ticks it clocks?
>>>>> 
>>>>> Hardware obviously have clock input which needs to be connected. Without it
>>>>> it won't work.
>>>> 
>>>> Should ACPI potential limitations be making the DT description less
>>>> accurate?
>>>> 
>>>> Would it not be better that the driver has an DT binding and an ACPI
>>>> binding? Where there are common properties, common functions can be
>>>> used to retrieve them. However, if ACPI lacks usable clocks, use the
>>>> of_ method to get the clock from DT, and skip it for ACPI.
>>> 
>>> Why should we use of_ methods? If this is required we can check the type of
>>> fwnode and act accordingly, but I think this should go deeper into some
>>> treewide available helpers, because now some drivers repeat the mantra.
>>> 
>>> But how do the driver get the clock frequency (if needed for some register
>>> settings and/or calculations)? DT seems to have well established property
>>> 'clock-frequency' for that. Can we consider it as "ACPI binding" as well?
>> 
>> "clock-frequency" property in i2c is used for selecting i2c speed 100/400kHz.
>> 
>> Clock frequency in this driver is about describing clock coming to IP itself.
>> Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
> 
> Ah, I see, then is_of_node() probably is the compromise how to deal with
> this setup.
> 

Thanks for all the feedback!

So, if everyone agrees, I can make the changes to:

- Remove the DT bindings change.
- Make the driver fetch the clock only on OF by checking is_of_node().

Does this sound acceptable?

Best regards,
Abdurrahman

On 1/28/26 15:34, Andrew Lunn wrote:
> On Wed, Jan 28, 2026 at 12:21:41PM +0100, Michal Simek wrote:
>>
>>
>> On 1/28/26 11:37, Krzysztof Kozlowski wrote:
>>> On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:
>>>> The xiic driver is designed to operate without explicit clock configuration
>>>
>>> And if you change this in the driver, then you change bindings?
>>>
>>> You miss here explanation based on hardware - how does the hardware work
>>> if nothing ticks it clocks?
>>
>> Hardware obviously have clock input which needs to be connected. Without it
>> it won't work.
> 
> Should ACPI potential limitations be making the DT description less
> accurate?
> 
> Would it not be better that the driver has an DT binding and an ACPI
> binding? Where there are common properties, common functions can be
> used to retrieve them. However, if ACPI lacks usable clocks, use the
> of_ method to get the clock from DT, and skip it for ACPI.

I found is_of_node()/is_acpi_node() to detect if this driver is probed on 
OF/ACPI system. If this is the right way to go then clocks can stay required on 
DT system and not required on ACPI.

Thanks,
Michal

On Wed, Jan 28, 2026 at 03:34:02PM +0100, Andrew Lunn wrote:
> On Wed, Jan 28, 2026 at 12:21:41PM +0100, Michal Simek wrote:
> > 
> > 
> > On 1/28/26 11:37, Krzysztof Kozlowski wrote:
> > > On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:
> > > > The xiic driver is designed to operate without explicit clock configuration
> > > 
> > > And if you change this in the driver, then you change bindings?
> > > 
> > > You miss here explanation based on hardware - how does the hardware work
> > > if nothing ticks it clocks?
> > 
> > Hardware obviously have clock input which needs to be connected. Without it
> > it won't work.
> 
> Should ACPI potential limitations be making the DT description less
> accurate?

We absolutely should not be cocking up bindings because ACPI requires
less complete descriptions.

> Would it not be better that the driver has an DT binding and an ACPI
> binding? Where there are common properties, common functions can be
> used to retrieve them. However, if ACPI lacks usable clocks, use the
> of_ method to get the clock from DT, and skip it for ACPI.
> 
>     Andrew
> 
>