Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2321259pxb; Thu, 3 Feb 2022 04:16:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJx5/apkJqzP3cISx8YYWFNkZq6cPcOTKUrS4eeVoycBLHeYohRiLQPqRxdUCzspS5PAN0DY X-Received: by 2002:a17:907:96a6:: with SMTP id hd38mr29360210ejc.38.1643890600729; Thu, 03 Feb 2022 04:16:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643890600; cv=none; d=google.com; s=arc-20160816; b=icg/0yk1pVgCYeXu/pldQjwuzG/qneSnEyUHKm+7GyenYGswEKrxQqip0r7ckkzfdk kLEw3iz2EtOMefgq6dcG+8kbjRWuIrCUghpeIh2U/xelXxxhrKZclkLD3o3widOVd+2H jsFxPW2nmp3I6NpJw/hhb+DP6DPpr4DpLozqd1KpWsnIi9apx/ya9LLYKXBytTVwiQns 3z0iP+ONNpoVLKg8fqpNIM2pIcXoCTUPNRztEkLwaF9wBGw7R+uxNS+oCgWAzZV8mIyI z5DOZLL9hmUAgdEJCapiWGFdBkROETBEHTxZqRFjms9plFgTquCW/MmigmLJxwnvKuIv mowQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=z9K4qRxp7D7uOEMt6lt2SpgZ3gAIvP6efbH3CbggO5g=; b=AqWTt4kXrifJ0EMTjQQithaTeEVSBa+cYRv3G7y3p3YKNUbOwSeyAn2SWZEtiHxArZ 8HkSTrGz9DtWP54HOUg39H97RvwCDPQcpyPySbUFu8UOnCtT7x/e1/x6RWpwbuVl8Jti 38fZN0uaSCEjPjoM9aCYEiwgxjqHnBZoJN4ahknsIoWam6fwqOZMqOLUissAoVRkkI7U FK8ATpUrhVP5irR275pkVZAvX4OpiLiHXtv+Lo5dzqLrP+ywj0E2O73TY88zNOghKEqS aC4RdNOdVJOIcdotT1UTc5cTr0ECs6qNDVIsLDoIZmBSfDzy5YH5pJKn92gddODiqyQq AwdQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l1si14871961ejo.949.2022.02.03.04.16.14; Thu, 03 Feb 2022 04:16:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235814AbiBAJAO convert rfc822-to-8bit (ORCPT + 99 others); Tue, 1 Feb 2022 04:00:14 -0500 Received: from mout.kundenserver.de ([212.227.126.133]:43831 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230333AbiBAJAN (ORCPT ); Tue, 1 Feb 2022 04:00:13 -0500 Received: from mail-oi1-f171.google.com ([209.85.167.171]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1N1u2b-1mD4OT0fPt-012EHw; Tue, 01 Feb 2022 10:00:12 +0100 Received: by mail-oi1-f171.google.com with SMTP id r27so9795019oiw.4; Tue, 01 Feb 2022 01:00:11 -0800 (PST) X-Gm-Message-State: AOAM531afx/pf8aVLUrOet4V65+C+KLZcDCQjILz5LTBeowldr+MmLW5 6CDjmlfltBIdsyvjBXJuMPZGc4LFChDK1z2Oiig= X-Received: by 2002:a05:6808:1a26:: with SMTP id bk38mr537794oib.291.1643706010707; Tue, 01 Feb 2022 01:00:10 -0800 (PST) MIME-Version: 1.0 References: <20220125194609.32314-1-nick.hawkins@hpe.com> <2f4dd91a-e4ad-2559-f65e-914561de4047@canonical.com> <015EB9CD-ADB9-4C12-BD3F-78268E849884@hpe.com> In-Reply-To: <015EB9CD-ADB9-4C12-BD3F-78268E849884@hpe.com> From: Arnd Bergmann Date: Tue, 1 Feb 2022 09:59:54 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel. To: "Verdun, Jean-Marie" Cc: Krzysztof Kozlowski , Arnd Bergmann , "Hawkins, Nick" , Rob Herring , Russell King , Shawn Guo , Stanislav Jakubek , Sam Ravnborg , Linus Walleij , Hao Fang , "Russell King (Oracle)" , Geert Uytterhoeven , Mark Rutland , Ard Biesheuvel , Anshuman Khandual , Lukas Bulwahn , Masahiro Yamada , DTML , Linux Kernel Mailing List , Linux ARM , Joel Stanley , OpenBMC Maillist Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K1:25kZqhuAYtnLmP1bfYSuPzRdeyPptmlRgbeWuTpyhSp+3BslXI7 3kK7Pk61V8aIyQyXOKdfjjGiML+pizAWs8EWUqPp9COcMfBJ78jHeYnZ74bIqyyyyHxRg5m paOjAzfrv17tr9fz7JpKDuW6xG8LkvDfyYaiZI0g2b4o1IrLFs4iicoywOZ2E3a8i0deBrQ q0uZttHDqKgF0xvw4T8MA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:cyeu6G5QG5E=:6eFvbbesaTDFSU31NiS+Ya KBhpZgUW/vLr1CMta+jHdrH80cspfe7cWBAuzBCfSJGyZqSdPEdPBysRX7YAvcOBlN1ljX4dq xzTXj5s/6Dh2j54uVPMUK0QelmRyZmkwgooNk4Grq28MCX9vLJpRSjFkYfw4AZskxzMTquuf+ sVI1b8pqcwzF3ECNBup/HewPqbglJWRd2cNIBC8rJbZFwm/NK6vcHq90JfbabWioFNnkcUknG Vo/c4SXTmvMR1xl+6jtqOOW/84xb7SwvFCFF6lICa4cyuXdWV5VcVE0bVFk6anIXqa+GcaCpv I741oWyNVZ2/tkGH3+hjvGv5sJSn6BwA7Ti8Q9eI0V9lzDSNrDILoGh90Jq0bJIChsXnwkCLq aKRZrpL0iJpkACp/pqfr4CWNzAsjCLJV67pphDYgp6m/GWdvl3wy3eRI6Tow5VPqx7d8YBJw3 5jEJRBgwHpFTC60yvYAHjw7W96ZSusblTjmZE9HWfNv4j3xxze7QtgE8qU6goqiLfBFH2Qbav yWDZi2Zo8a69l1X8IBjSyYmk2CohEI0iov8fM3Me+FqciqA7j5V8AO3k4BWa/IWNvA29Y57h5 0Mkrs0UsAuCxJt0TEP61Ji7Jl6FKZH2eRFpXkfYgGNZliMRSdnfKF3IERBmLwUlv9aucdZ7SI HvcYalIrBrm4ksSGCKVg1WEeZ1g2tcWuy1CalMoPCWiyceiVLgQzE/DfLLWmkM/RZGk8= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 31, 2022 at 7:52 PM Verdun, Jean-Marie wrote: > > - GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough. > - This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines) Is there any more specific name of the chip that can be used to identify the exact generation after a new one comes out? The normal way we handle compatible strings for devices is to start with a specific model number of the chip that integrates it, and then have later chips refer to the device by its new name, with the old one as a fallback. This makes drivers work out of the box when the device is unchanged, but gives you a way to distinguish them if a difference gets noticed after both revisions are already used. As with some of points that Krzysztof and others made previously, the goal here is to avoid binding incompatibilities in the future: anything that works in an upstream kernel should keep working in later versions, ideally allowing any combination of old and new dtb blobs in the bootloader with old or new kernel versions. > It does support many features including: > - ARMv7 architecture, and it is based on a Cortex A9 core > - Use an AXI bus to which > - a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII > - Multiple I2C engines to drive connectivity with a host infrastructure > - A video engine which support VGA and DP, as well as an hardware video encder > - Multiple PCIe ports > - A PECI interface, and LPC eSPI > - Multiple UART for debug purpose, and Virtual UART for host connectivity > - A GPIO engine Thanks for the description. This seems quite normal then, similar to the aspeed and npcm BMC platforms that we support already. You can probably drop some of the people on the Cc list, but I would suggest you add the openbmc list and Joel Stanley (Cc'd now) in your next submissions, Joel would be the best person to review the parts that are BMC specific. > vejmarie > > On 1/26/22, 12:41 AM, "Krzysztof Kozlowski" wrote: >... Please follow the normal quoting style when replying to mailing list messages: reply below the part you are quoting, and trim the parts of the original message you are not quoting. Arnd