linux-kernel - Re: [PATCH v16 1/3] dt-bindings: i2c: aspeed: support for AST2600-i2cv2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ecefaed7ed0fe83442021c0bfee0a49111269aad.camel@ozlabs.org>
Date: Thu, 11 Sep 2025 17:03:39 +0800
From: Jeremy Kerr <jk@...abs.org>
To: Ryan Chen <ryan_chen@...eedtech.com>, Krzysztof Kozlowski
 <krzk@...nel.org>
Cc: "robh@...nel.org" <robh@...nel.org>, "conor+dt@...nel.org"
	 <conor+dt@...nel.org>, "andriy.shevchenko@...ux.intel.com"
	 <andriy.shevchenko@...ux.intel.com>, "andi.shyti@...nel.org"
	 <andi.shyti@...nel.org>, "linux-aspeed@...ts.ozlabs.org"
	 <linux-aspeed@...ts.ozlabs.org>, "devicetree@...r.kernel.org"
	 <devicetree@...r.kernel.org>, "openbmc@...ts.ozlabs.org"
	 <openbmc@...ts.ozlabs.org>, Mo Elbadry <elbadrym@...gle.com>, 
	"linux-kernel@...r.kernel.org"
	 <linux-kernel@...r.kernel.org>, "joel@....id.au" <joel@....id.au>, 
	"p.zabel@...gutronix.de"
	 <p.zabel@...gutronix.de>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>, 
	"linux-arm-kernel@...ts.infradead.org"
	 <linux-arm-kernel@...ts.infradead.org>, "linux-i2c@...r.kernel.org"
	 <linux-i2c@...r.kernel.org>
Subject: Re: [PATCH v16 1/3] dt-bindings: i2c: aspeed: support for
 AST2600-i2cv2

Hi all,

After a bit of a chat with Ryan, some updates on this:

> The question was more: it sounds like you're switching between
> *fundamentally different* hardware units with the mux switch - not just
> a different register interface for the same peripheral hardware. Is that
> the case?

Turns out: no. The controller core is the same, but what gets muxed
in/out is more of a compatibility interface. This provides an
ast2500-like register set to the ast2600 i2c peripheral.

So, the plan to use the same aspeed,ast2600-i2c-bus binding for the
controllers (ie, as in v18) seems mostly sensible to me.

The newly-introduced driver can make use of the non-compat interface to
the peripheral (using the existing compatible value), but needs the
introduction of support for the global register set to do so. Ideally,
this would have been included on the original spec for the
aspeed,ast2600-i2c-bus binding (since that's how the hardware is laid
out), but that wasn't the case.

We may want to split the aspeed,ast2600-i2c-bus binding out from the
existing spec, as we currently have:

  compatible:
    enum:
      - aspeed,ast2400-i2c-bus
      - aspeed,ast2500-i2c-bus
      - aspeed,ast2600-i2c-bus

- but the former two do not have a global register-set.

We may have better syscon-like options for handling that global register
set, but that's more of a conversation for the v18 thread.

Cheers,

Jeremy