[PATCH v7 1/6] i2c: xiic: skip input clock setup on non-OF systems

[Abdurrahman Hussain]

> On Feb 2, 2026, at 5:21 AM, Andrew Lunn <andrew at lunn.ch> wrote:
> 
> On Sat, Jan 31, 2026 at 08:30:40PM -0500, Abdurrahman Hussain wrote:
>> On Sat Jan 31, 2026 at 10:12 AM UTC, Andy Shevchenko wrote:
>>> On Thu, Jan 29, 2026 at 03:29:45PM -0800, Abdurrahman Hussain wrote:
>>>>> On Jan 29, 2026, at 2:43 PM, Andrew Lunn <andrew at lunn.ch> wrote:
>>>>> On Thu, Jan 29, 2026 at 09:43:13PM +0000, Abdurrahman Hussain via B4 Relay wrote:
>>> 
>>>>>> 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