From: Andrew Lunn <andrew@lunn.ch>
To: Abdurrahman Hussain <abdurrahman@nexthop.ai>
Cc: Andy Shevchenko <andriy.shevchenko@intel.com>,
Michal Simek <michal.simek@amd.com>,
Andi Shyti <andi.shyti@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v7 1/6] i2c: xiic: skip input clock setup on non-OF systems
Date: Mon, 2 Feb 2026 14:21:50 +0100 [thread overview]
Message-ID: <8be34da2-bf0e-47a0-bf91-3329ed0ec8ab@lunn.ch> (raw)
In-Reply-To: <CAGYn4vxRbPVFvzm1b_mk2KvnRcJSO0Ewmx1tCTEALaZAu+ZQJQ@mail.gmail.com>
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@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.
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.
Andrew
next prev parent reply other threads:[~2026-02-02 13:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-29 21:43 [PATCH v7 0/6] i2c: xiic: use generic device property accessors Abdurrahman Hussain via B4 Relay
2026-01-29 21:43 ` [PATCH v7 1/6] i2c: xiic: skip input clock setup on non-OF systems Abdurrahman Hussain via B4 Relay
2026-01-29 22:43 ` Andrew Lunn
2026-01-29 23:29 ` Abdurrahman Hussain
2026-01-31 10:12 ` Andy Shevchenko
2026-02-01 1:30 ` Abdurrahman Hussain
2026-02-02 13:21 ` Andrew Lunn [this message]
2026-02-02 18:26 ` Abdurrahman Hussain
2026-01-31 10:10 ` Andy Shevchenko
2026-01-29 21:43 ` [PATCH v7 2/6] i2c: xiic: switch to devres managed APIs Abdurrahman Hussain via B4 Relay
2026-01-30 10:48 ` Jonathan Cameron
2026-01-31 10:31 ` Andy Shevchenko
2026-01-29 21:43 ` [PATCH v7 3/6] i2c: xiic: remove duplicate error message Abdurrahman Hussain via B4 Relay
2026-01-30 10:49 ` Jonathan Cameron
2026-01-29 21:43 ` [PATCH v7 4/6] i2c: xiic: switch to generic device property accessors Abdurrahman Hussain via B4 Relay
2026-01-29 21:43 ` [PATCH v7 5/6] i2c: xiic: cosmetic cleanup Abdurrahman Hussain via B4 Relay
2026-01-31 14:35 ` Dan Carpenter
2026-02-01 2:14 ` Abdurrahman Hussain
2026-02-01 22:23 ` Uwe Kleine-König
2026-02-02 2:06 ` Abdurrahman Hussain
2026-01-29 21:43 ` [PATCH v7 6/6] i2c xiic: cosmetic: use resource format specifier in debug log Abdurrahman Hussain via B4 Relay
2026-01-31 10:55 ` Andy Shevchenko
2026-01-29 22:36 ` [PATCH v7 0/6] i2c: xiic: use generic device property accessors Andrew Lunn
2026-01-31 10:57 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8be34da2-bf0e-47a0-bf91-3329ed0ec8ab@lunn.ch \
--to=andrew@lunn.ch \
--cc=abdurrahman@nexthop.ai \
--cc=andi.shyti@kernel.org \
--cc=andriy.shevchenko@intel.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®