[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fc00f8cf-b566-4694-82fe-76010d2f7c78@lunn.ch>
Date: Wed, 28 Jan 2026 15:34:02 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Michal Simek <michal.simek@....com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
Abdurrahman Hussain <abdurrahman@...thop.ai>,
Andi Shyti <andi.shyti@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, info@...ean-labs.com,
Andy Shevchenko <andriy.shevchenko@...el.com>,
linux-arm-kernel@...ts.infradead.org, linux-i2c@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v6 1/7] dt-bindings: i2c: xiic: make clocks optional
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
Powered by blists - more mailing lists