[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<OS8PR06MB75416F7F1B5DBC95A5E87FD1F21CA@OS8PR06MB7541.apcprd06.prod.outlook.com>
Date: Wed, 24 Sep 2025 05:31:47 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Rob Herring <robh@...nel.org>, Jeremy Kerr <jk@...econstruct.com.au>
CC: "benh@...nel.crashing.org" <benh@...nel.crashing.org>, "joel@....id.au"
<joel@....id.au>, "andi.shyti@...nel.org" <andi.shyti@...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
> Subject: Re: [PATCH v18 1/3] dt-bindings: i2c: aspeed,i2c.yaml: add
> transfer-mode and global-regs properties and update example
>
> On Mon, Sep 15, 2025 at 11:41:31AM +0800, Jeremy Kerr wrote:
> > 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
>
> About the only place we use version numbers (without regret) is when the
> version can be traced back to the actual verilog. This is typically only IP
> targeted to FPGAs. The reality in SoCs is h/w designers can't help themselves to
> not change things. In reality, there are almost always some changes.
>
> Rob
Thanks, I think I will work on new yaml aspeed,ast2600-i2c.yaml for ast2600 i2c driver.
That support global regs, transfer-mode properties.
Then will add ast2700-i2c.yaml for ast2700 i2c.
Ryan.
Powered by blists - more mailing lists