On Feb 2, 2026, at 5:21 AM, Andrew Lunn [off-list ref] wrote:

On Sat, Jan 31, 2026 at 08:30:40PM -0500, Abdurrahman Hussain wrote:

quoted

On Sat Jan 31, 2026 at 10:12 AM UTC, Andy Shevchenko wrote:

quoted

On Thu, Jan 29, 2026 at 03:29:45PM -0800, Abdurrahman Hussain wrote:

quoted

quoted

On Jan 29, 2026, at 2:43 PM, Andrew Lunn [off-list ref] wrote:
On Thu, Jan 29, 2026 at 09:43:13PM +0000, Abdurrahman Hussain via B4 Relay wrote:

quoted

quoted

quoted

The xiic driver supports operation without explicit clock configuration
when clocks cannot be specified via firmware, such as on ACPI-based
systems.

Are you saying it is technically impossible to specify a clock in
ACPI?

Maybe a more accurate would be:

The xiic driver supports operation without explicit clock
configuration when the clocks are not specified via firmware, such as
when the ACPI tables are missing the description of the clocks.

Actually, ACPI (since 6.5) added a ClockInput() macro that can be added to
_CRS of a device node. The ACPI subsystem in kernel could parse these and
convert into proper clocks integrated with the CCF. But, AFAIK, this idea was
rejected in the past.

Rejected by which side? CCF?
Because specification still has that.

I think the argument was that on ACPI based systems clocks are "owned"
by AML and there could be syncronizations issuebetween AML and the OS.

See https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1712165.html

Doesn't that just mean there needs to be a call into AML to request it
take an action on a clock? Otherwise, why even have ClockInput()? This
link is to quite an old thread, 2018, where as ClockInput seems to be
pretty new.

The fact ClockInput() exists, means at some point somebody will
implement it. Once it has been implemented, somebody might need to use
it with xiic? Because it is mandatory in DT, and there is no ACPI
binding document for xiic, they could make it mandatory in ACPI as
well. And then your device breaks.

That makes sense. I might have misread the thread and came to the wrong
conclusion that converting ClockInput() into a CCF clocks was
undesirable. Thank you for clarifying. Maybe I can start looking into adding
support for this after this series is merged.

By putting in the commit message something like:

Currently Linux does not implement ACPI ClockInput to describe clock
resources, unlike DT. However the xiic driver is happy if something
magically enables the clock before the driver probes, and does not
turn it off again. The clock should always be considered optional for
ACPI.

That should act has a hint to future developers hacking on xiic not to
make it mandatory.

Yes, that is much more clear and concise! I am going to use this paragraph
verbatim in the commit message. Thanks for all the feedback, Andrew!

Best regards,
Abdurrahman