linux-kernel - Re: [PATCH v4 2/5] dt-bindings: i2c: Add hpe,gxp-i2c

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]

Date:   Wed, 25 Jan 2023 21:31:26 +0000
From:   "Hawkins, Nick" <nick.hawkins@....com>
To:     Rob Herring <robh@...nel.org>
CC:     "Verdun, Jean-Marie" <verdun@....com>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "joel@....id.au" <joel@....id.au>
Subject: Re: [PATCH v4 2/5] dt-bindings: i2c: Add hpe,gxp-i2c

> > + hpe,sysreg:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + Phandle to the global status and enable interrupt registers shared
> > + between each I2C engine controller instance. It enables the I2C
> > + engine controller to act as both a master or slave by being able to
> > + arm and respond to interrupts from its engine. Each bit in the
> > + registers represent the respective bit position.


> Each bit represents the bit position?

Yes what I mean here is that bit 0 represents engine 0, bit 1 represents
engine 1 and so on. I will reword this how you have below.

> AIUI, each I2C instance has a bit in it needs to control. How does the 
> driver know what instance (and therefore the correct bit)? Typically you 
> would have a 2nd cell here with that information.

We are currently using the memory area designated reg to determine
which engine we are on.

Here is a snippet from patch 1 of this patchset that introduces the driver:
/* Use physical memory address to determine which I2C engine this is. */
+	drvdata->engine = ((u32)drvdata->base & 0xf00) >> 8;

This works because each engine is 0x100 apart.

I would however like to conform to a standard to designate the engine.
Is there an existing property I can leverage?

Thanks for your feedback,

-Nick Hawkins