On Wed, Jan 28, 2026 at 04:00:30PM +0100, Michal Simek wrote:

On 1/28/26 15:45, Andy Shevchenko wrote:

quoted

On Wed, Jan 28, 2026 at 03:34:02PM +0100, Andrew Lunn wrote:

quoted

On Wed, Jan 28, 2026 at 12:21:41PM +0100, Michal Simek wrote:

quoted

On 1/28/26 11:37, Krzysztof Kozlowski wrote:

quoted

On Tue, Jan 27, 2026 at 09:03:55PM +0000, Abdurrahman Hussain wrote:

quoted

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