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] [thread-next>] [day] [month] [year] [list]

Message-ID: <44ef5c93448a3625fcfd003b47a516e8ba795b62.camel@ozlabs.org>
Date: Wed, 10 Sep 2025 15:25:05 +0800
From: Jeremy Kerr <jk@...abs.org>
To: Krzysztof Kozlowski <krzk@...nel.org>, Ryan Chen
 <ryan_chen@...eedtech.com>
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 Ryan & Krzysztof,

[my response is intended to make progress on the newer v18 submission,
but we still have this item from v16 to resolve, hence picking up this
thread]

> Your compatible already expressed that there are two interfaces, so
> your drivers can just choose whichever they want. If you need to toggle a
> bit in system controller, it is fine. If you need different compatible,
> then that's a NAK.

I think the mention of "two register interfaces" is a bit misleading
here; it implies that it's just two interfaces to the same hardware.

>From reading between the lines on the datasheet, it seems that this is
two completely separate IP cores, that:

 * are mapped to the same MMIO space; but
 * both happen to be I2C controllers.

- where the single "global register" (which you mention above) provides
the facility to mux the MMIO mapping between the two. Some versions of
the overall SoC have only the old core, some have only the new, and some
have both, selectable via this register.

Ryan, can you confirm whether this is the case?

Given there are actual behavioural differences between the two
peripherals - beyond just the register set - that would seem to indicate
separate binding types (+ a syscon mux control) to me, but I'm keen to
hear any other options.

Krzysztof, if that is the case, any thoughts on the representation of
separate bindings?

Cheers,


Jeremy