[PATCH v6 1/7] dt-bindings: i2c: xiic: make clocks optional

[Abdurrahman Hussain]

> On Jan 28, 2026, at 7:43 AM, Andy Shevchenko <andriy.shevchenko at 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