[PATCH v6 1/7] dt-bindings: i2c: xiic: make clocks optional
Andy Shevchenko
andriy.shevchenko at intel.com
Wed Jan 28 07:43:19 PST 2026
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
More information about the linux-arm-kernel
mailing list