Date:   Thu, 2 Feb 2023 23:25:09 +0800
From:   Clay Chang <clayc@hpe.com>
To:     Andrew Jeffery <andrew@aj.id.au>
CC:     <linux-kernel@vger.kernel.org>, <soc@kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <devicetree@vger.kernel.org>, <verdun@hpe.com>,
        <nick.hawkins@hpe.com>, Arnd Bergmann <arnd@arndb.de>,
        "Rob Herring" <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Russell King <linux@armlinux.org.uk>,
        Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH 0/5] ARM: Add GXP SROM Support
Message-ID: <Y9vV1WFinNVpLhvi@enigma.ccjz.io>
References: <20230110042533.12894-1-clayc@hpe.com>
 <7734c165-5918-4677-b8d4-f7d5a3ed37d5@app.fastmail.com>
 <Y9kbsRsRcOnGS0ps@enigma.ccjz.io>
 <Y9ppGn0rLfnA3vz6@enigma.ccjz.io>
 <206f0e93-059d-4657-8359-0c5080797c76@app.fastmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <206f0e93-059d-4657-8359-0c5080797c76@app.fastmail.com>
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?5V5B3KLUd6K+5aw6UecdczaNZKeUNr1njhGgdl3gH4T+9PdufMOKY3dJyS9s?=
 =?us-ascii?Q?hGOEXlMenPpPyfBQeQELebUuAZvkwt+gmbNJXXpQGeExZPWfThQ4/FLUDOWj?=
 =?us-ascii?Q?1o+1amHlY7k+jeNP8IeCZZr2JbsyoswGjbHsSdOBYBhkyFjKhu/lG51/X4Uy?=
 =?us-ascii?Q?Fk5rlDdFmbRZ3IB64jSRgAtzpleqXzdbdI2taapjii12KgUQOMAKk6wo2HRS?=
 =?us-ascii?Q?HfZVvnexNSAjCqT9+d5GkX4tbuWuigBpwsDgFT/mZyF728tCLBoykkA5J0fm?=
 =?us-ascii?Q?xdf/Iodvz75LCVtzPyvX7FL9UyhuwQwQyc0uWE8Jmqfj7I8W+7R+E0P0303A?=
 =?us-ascii?Q?s34etECW5I2fF6SBSmIkJWCTA+cLhdLhW6PtbpAcxlYV7auaKnTSNkVYHQRU?=
 =?us-ascii?Q?OlSwd5XmF6RMJ+nGncqH5V4VeAGEyY+zHZcYzr/PO0cy4hRyCZw8YSRd+Rws?=
 =?us-ascii?Q?LSwJka6hLI4EuKxvw2psv+6A2wt0YMt3l3z0XtrNoPggiTmgssHPfQuemY0b?=
 =?us-ascii?Q?eb94dyMaECv0C9CHWRxsYESXxgoJmNUItthGEi6wolR+1mpFNmgkNeTYUlAp?=
 =?us-ascii?Q?QscP7kINvdwO0my/wlrhGyUfsJDPReMtDrWooP0C7UYUWExR1UZiIXX0O+7m?=
 =?us-ascii?Q?1DdtKtym/EAfHZ1zAYCe3p9a15IR6vTmOSwOTAhABQrYRRk3Z9bfs1J8Nkkp?=
 =?us-ascii?Q?xrr3bwUL5MIkRu4bmm/JVFxJfv8zix/KNsK9Sfx0KzSq9UtpNm1KlxaeUVRQ?=
 =?us-ascii?Q?SWnGo1G6e+fxxQCzbzPVP5RIVkvqucQMekdc3aWYFVcY7i0qtp5gXHLJFpEf?=
 =?us-ascii?Q?zk/PQyC3RwKA6qBxqn1kTVWl0cjJT2sQE1ZAA8zKtQYJ+0+mY/5GfGlFM4ee?=
 =?us-ascii?Q?OnqTB/Iak5m6nY9uIkJmahcNQGpa5mzOp5dx9ToIeC3HjccSuSYQSgyB+a45?=
 =?us-ascii?Q?1a2KPJdFWXpnNd3M1K52Bl48qcoVmp/62f7q0hjG4H6MQJzjCRYa9W0YSq2l?=
 =?us-ascii?Q?RHdU9E7gIpbJBjuaG4uloxPV/mDJeSkeAQXW5Q3QJ0OEJRER5D7PpAl7Dy1k?=
 =?us-ascii?Q?vY3CF30wHImcCjumrujsmU0GL8GrJ6g/CXES3xdstBVrV3DtKfGGwYpB8B4Q?=
 =?us-ascii?Q?S6dR8tf6ha55Jg63y+AcG1YNXowEO2sBhP8coIFk8ot2Q1YTFY5LztNN8vO1?=
 =?us-ascii?Q?re92Q6HLckrj0BIYr22vkMjTlFQi1z932yG0usZxgdg7cKTsOBeraZDBrVN/?=
 =?us-ascii?Q?+juovUBflfrSqDyNJJ+V9iBuE1PlUFmjIbNj4ibn8l7/L8dqonMy+VhoSY7E?=
 =?us-ascii?Q?xWu6yLErmsIkPD61BHN7UmrQPYKTLBcSk2QRzVrc1KKtiOf+KNwxrKvSxTc1?=
 =?us-ascii?Q?Ud+EcybV+MEQcMf0anHNrMTjEFSRgrs4i0j1ucdLhU6YVqPUq03ZdG1Ek+MP?=
 =?us-ascii?Q?fMLF0HNV1g2Tch5aArz8iomP9gV9HBTwfXhjGoVDng3JGfevTemRRCuzmuXA?=
 =?us-ascii?Q?gy8dVujdAR8jHE2/mhsZAzBp0pIpb9dWlymDOKsnCVJCWbcR8ifKUw4J199L?=
 =?us-ascii?Q?OKJfSuWzIos62yCAnaCaXyAo7eOgOQarX9kKG9Rj4ldEpdYA9/ojx3dkoVA5?=
 =?us-ascii?Q?lQ=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: d1e2f2b6-5299-465a-40c3-08db0531b1b9
X-MS-Exchange-CrossTenant-AuthSource: PH0PR84MB1480.NAMPRD84.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2023 15:25:19.9113
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: s2JvItBbYfdVJlaKsTBDf4VhyZwuy+VUa00bceSyd7TCnkJV5WntZfqqtbUYO2P7
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR84MB1388
X-OriginatorOrg: hpe.com
X-Proofpoint-ORIG-GUID: QZcVqlJrdNxa3-yk-Kc995iLN2gPvcP4
X-Proofpoint-GUID: QZcVqlJrdNxa3-yk-Kc995iLN2gPvcP4
X-Proofpoint-UnRewURL: 0 URL was un-rewritten
MIME-Version: 1.0
X-HPE-SCL: -1
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1
 definitions=2023-02-02_04,2023-02-02_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501
 impostorscore=0 suspectscore=0 bulkscore=0 mlxlogscore=930 malwarescore=0
 clxscore=1015 spamscore=0 phishscore=0 lowpriorityscore=0 adultscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2302020138
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Feb 02, 2023 at 11:42:49AM +1030, Andrew Jeffery wrote:
> 
> 
> On Wed, 1 Feb 2023, at 23:58, Clay Chang wrote:
> > Hi Andrew,
> >
> > On Tue, Jan 31, 2023 at 09:46:42PM +0800, Clay Chang wrote:
> >> > I'm trying to understand whether we can find some common ground with
> >> > controlling e.g. Aspeed's BMCs LPC peripherals based on Arnd's query[1],
> >> > but the description is a bit too vague right now for me to be able to do
> >> > that.
> >> > 
> >> > [1] https://lore.kernel.org/all/66ef9643-b47e-428d-892d-7c1cbd358a5d@app.fastmail.com/
> >> > 
> >> > Andrew
> >
> > I briefly studied driver/soc/aspeed/aspeed-lpc-ctrl.c, and IMO the
> > similarity between HPE GXP driver and Aspeed's could be that we both
> > expose the LPC memory addresses or registers for configuration purposes.
> > However, the functions to be configured could vary. There are a few sets
> > of registers that HPE wants to expose for configuration in the future.
> 
> The talk of "exposing registers" feels concerning - we're trying not to 
> do that directly. Instead we want to lift out an API that constrains 
> the behaviour a bit but works for both of us if there's overlap in 
> functionality.
> 

Let me describe it more clearly. We don't expose the registers directly
to the user. We describe those registers in the device tree, and then
the driver exposes them though sysfs interfaces. Users access the
registers through the device attributes defined under the sysfs
structure (e.g. /sys/class/soc/srom/vromoff) exposed by the driver. In
the show/store function pair, we get or set the regmap or memory,
validate input, do sanity check, synchronization, and so on.

I learned that in the drivers/soc/aspeed/aspeed-lpc-ctrl.c, both mmap
and ioctl were used, and revelant ioctl commands were defined in
include/uapi/linux/aspeed-lpc-ctrl.h. Is this what you mean an API for
aspeed? And we are trying to see if there are commonalities among us?
If yes, yeah I think it is good to see a common abstraction for BMC
chips.

Accroding to [1], I'd comment that, in terms of flash update, what we
want to do is similar to what was described in [1]. The SROM driver I
am working on partially layouts the registers for flash update for HPE
GXP hardware.

BTW, the way for user to access the registers is flexible - ioctl should
work as well.

> Can you point to any documentation of the behaviour of your hardware? 
> It's still a little vague to me.
> 
> Andrew

I wish I could, but there is not yet a technical document or datasheet
available to the public. Sorry.

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=v6.2-rc4&id=6c4e976785011dfbe461821d0bfc58cfd60eac56

Thanks,
Clay