linux-kernel - Re: [PATCH v18 1/3] dt-bindings: i2c: aspeed,i2c.yaml: add transfer-mode and global-regs properties and update example

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: <03abda47219b8b0b476a3740c7ed2acc4b2b16dc.camel@codeconstruct.com.au>
Date: Mon, 15 Sep 2025 11:41:31 +0800
From: Jeremy Kerr <jk@...econstruct.com.au>
To: Ryan Chen <ryan_chen@...eedtech.com>, "benh@...nel.crashing.org"
 <benh@...nel.crashing.org>, "joel@....id.au" <joel@....id.au>, 
 "andi.shyti@...nel.org" <andi.shyti@...nel.org>, "robh@...nel.org"
 <robh@...nel.org>,  "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
 "conor+dt@...nel.org" <conor+dt@...nel.org>,  "andrew@...econstruct.com.au"
 <andrew@...econstruct.com.au>, "p.zabel@...gutronix.de"
 <p.zabel@...gutronix.de>,  "andriy.shevchenko@...ux.intel.com"
 <andriy.shevchenko@...ux.intel.com>, "naresh.solanki@...ements.com"
 <naresh.solanki@...ements.com>, "linux-i2c@...r.kernel.org"
 <linux-i2c@...r.kernel.org>, "openbmc@...ts.ozlabs.org"
 <openbmc@...ts.ozlabs.org>, "devicetree@...r.kernel.org"
 <devicetree@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
 <linux-aspeed@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v18 1/3] dt-bindings: i2c: aspeed,i2c.yaml: add
 transfer-mode and global-regs properties and update example

Hi Ryan,

> > OK, but the ast2400 and ast2500 I2C peripherals - which this binding also
> > describes - do not have that facility. Given the 2600 is a distinct peripheral (as
> > discussed on the v16 series), this would seem to warrant a distinct binding.
> > 
> > Should this be split out into an ast2600-specific binding, to reflect that it is
> > different hardware? The reference to the global registers and transfer modes
> > would then be added only to the ast2600-i2c-bus binding.
> 
> I agree it would be cleaner to split out a new binding file specifically for AST2600,
> for example: `aspeed,ast2600-i2c.yaml`
> But also I think `aspeed,i2cv2.yaml` more better name, that compatible will 
> support next generation such like AST2700 .....

The ship may have already sailed on that one, as you already have the
existing compatible string describing existing hardware.

I would assume that the compatible string should be fixed for an
instance of the specific hardware, but the DT maintainers may be able to
provide some input/precedence on changing an existing binding, if
necessary.

If this does get changed, I would expect that you would need a
corresponding update in the old driver too.

Or, another option may be to keep the current generation ("v2 core with
compat registers") as-is (ie., at ast2600-i2c-bus), and introduce a new
string for the next - where the primary hardware change might be the
removal of compat registers, but it's still new hardware

Cheers,


Jeremy