From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CE894C433EF for ; Thu, 21 Apr 2022 07:10:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:MIME-Version:Content-Type: References:Message-ID:In-Reply-To:Subject:cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wRm+tEK3o2u/uZ8eGddNLn0NVXDljijAFpt6LK4p4Uo=; b=snfocnMMmfV2ENXfprYluoc1Ox /pnih5T/s1WTMQY+M3M65OHHYUXKbDEHBkVbtQkfC5ogx+D8MAs88Het99THJUwy6y1/M2ynf8w6z lm8rE71o823bQw7ITmkim95JV2IkOhAVTD1L3XnbRXpZcUTjo8qbP+YD2dHb5rIOJyTVEX7O+NWa8 2j2aIKHFzYVwJe97ykZ3pxm4/51u1jbt+612GVu+Lv60TMCMx6ZPgZIoj5B8b26l3bvNhaqdvItVq u5pmU2GtSpqO65DwIDjO4Ao6Z8MqvW0CAJ1UljlOTv4oIAvQX7okqCUIFbBFJJFS0ztGxvuRIcLmH xV+0akcw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhQwY-00Bx7y-Rx; Thu, 21 Apr 2022 07:09:35 +0000 Received: from mail-mw2nam08on20705.outbound.protection.outlook.com ([2a01:111:f400:7e8c::705] helo=NAM04-MW2-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhQwV-00Bx7I-Jk for linux-arm-kernel@lists.infradead.org; Thu, 21 Apr 2022 07:09:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PVyBe5zZwXdaXcUtWtgK5uLc5LAA1SAZ7KA18G+rxmStJajBpVYAwDURSsF2sj0R/etQgqBbP6lZWje0fIK+kX4Gui581axeL2y6sLQcj9tEl2Jft9BLZgThmxa3rPa3zAE4NB7YJgnBMCNJzaHtMgStcFs6U1iNQTZ/6cGCUVoD9iGqVnjGfhSJeEygi4AZbHZxowE1bRpslo+xuRSzc7ft2rVsIWhTGlXnUKs8WNOfw7xc3Id+Ax1PqL4CyPdMS04e+HvxRcW8BM/xgJsELsNGy4gf3j97a5EM0IjxEXKsV9J08veEbJizGow40H4zGDXaROvZXoOG+xDV5XRU1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VeXoyV9dDsZS8KGTrwxFpLXTl9Npsdg7ONsA1tMDPnU=; b=P4cl6ZMaYDjdRYu30lR2Ojtlr+vitxiJRwtFf8lvRwcjv3aXOt6A1ZtN/91auBLcPmcu2rKbbmo0+LgCOIFzwJp1T3Rr0twht8Mz5B8BPmFTjaJR0QHhxLrzp3d6F9GMwaSd5GsOIV+YsXlIUkaNdqYyISex7C4iLQNEPBt2OfNUr+CMS7YB9ZfZV441+ydWDmxgG+vchupziNU60PIXLmk0/IRQC1RLkpH/b1Sz6sR7iI+hRZNB4iLDqKRAoLI9GuWqSsUu6eyV9n5j8XphPMkQWInuFINyO2Ke7Y/xHnlwzFJfA2z9WC63Go/8RK6Fa9uKmiDb1hXHeM6sACg4JQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=os.amperecomputing.com; dmarc=pass action=none header.from=os.amperecomputing.com; dkim=pass header.d=os.amperecomputing.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=os.amperecomputing.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VeXoyV9dDsZS8KGTrwxFpLXTl9Npsdg7ONsA1tMDPnU=; b=kiV3er0+z5fxU92iyufUV3AdzJTxwPP6FioFHoT9/Ur08gD4bFUdyvoY3A4ObfHRAf/EpA4+PbOjCggJwQZPMvOsF6kAGHnibpDiohZEi4HC+RNJS/JgeT/Cin0KS9M+aPiFlhPzOE8l/hpHuz1VX0JXsLAmTlgL6btW2pKO3DY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=os.amperecomputing.com; Received: from DM5PR0102MB3590.prod.exchangelabs.com (2603:10b6:4:a4::25) by DM6PR01MB4922.prod.exchangelabs.com (2603:10b6:5:9::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.25; Thu, 21 Apr 2022 07:09:26 +0000 Received: from DM5PR0102MB3590.prod.exchangelabs.com ([fe80::5015:1ef4:46b6:5b34]) by DM5PR0102MB3590.prod.exchangelabs.com ([fe80::5015:1ef4:46b6:5b34%7]) with mapi id 15.20.5164.025; Thu, 21 Apr 2022 07:09:26 +0000 Date: Thu, 21 Apr 2022 00:09:09 -0700 (PDT) From: Ilkka Koskinen X-X-Sender: ikoskine@ubuntu200401 To: Robin Murphy cc: Ilkka Koskinen , will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/4] perf/arm-cmn: Add CMN-650 support In-Reply-To: <5d66eb8c-56ef-dc32-ed2d-cf1cb801e224@arm.com> Message-ID: References: <5d66eb8c-56ef-dc32-ed2d-cf1cb801e224@arm.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) Content-Type: multipart/mixed; boundary="2088271309-475416472-1650524966=:3744" X-ClientProxiedBy: MW4PR04CA0101.namprd04.prod.outlook.com (2603:10b6:303:83::16) To DM5PR0102MB3590.prod.exchangelabs.com (2603:10b6:4:a4::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ae2c1ab4-40a7-441c-2a19-08da2365dec4 X-MS-TrafficTypeDiagnostic: DM6PR01MB4922:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qIBq/qyy5sn8UoMFJajj9Se58gnzhpXJ9A6w7M1eWN9CSYqkIeRA4/GoAw6ovGnzw8pijfeOSCOmF48kNRQhvT3l3c9hF2FWok/YCkg4vrAdaHpaQghSuYOSWQelr0WqdbFzV69ckc+fMw/NtoMibe+pFi4JMNPGEoTycbvsYP6YH3jFJo9F0gz1V88pK7NRXsDZ4wdE5CYg7z/Fpq+3bcI6+fttDgkCB9Lr3HgpyHtp2rgZ5ppi7nOKfcZOIsIyXxwtIzyvc5HY8nXTtb5HjzXhBmWhfmdFHhI9dJ9D/Bk/LOZuRW2Au3/flBymjmssgOeArDP1w/I+IJQnspWpNFtAt5eDp8SpTiEieIntja1erv9sCuQqzkwIydVNIA+hNOS9rmmbJ3Wq65+iRzFPAnl24aq5rqbhs2g4qOu1X3va/KeqDG1cRxiv7qnJCL/fH4VAjc3ENVS8/FqnLZ/imlX2xaFBnQ9ifswbtMCpstxCxEKGUNmWn+zo/1/yWKvokGHHn2jkSV92V6Rxg0h8bNRbRdrIMkY5d5M3AROiB6kw3+fP9UO/QPM2COXgxJ0H7oOm9YTx1bYQww79eq+/3OMF1aEfaU7jLxmlhAH64ZzyEVitFRbpCHM9pSU85X5DTDy0BoIY0YLVWBg9lmEfyo5q00eqjXcrXmJu4m5gqBXmxQl5SEepMktVNJv9UoAvNb0yi89DBjE1COS2sdWYHQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0102MB3590.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(13230001)(7916004)(4636009)(366004)(86362001)(38350700002)(52116002)(53546011)(8936002)(38100700002)(66946007)(33716001)(316002)(508600001)(6486002)(66556008)(66476007)(6916009)(6666004)(186003)(33964004)(4326008)(8676002)(5660300002)(9686003)(6512007)(26005)(2906002)(6506007)(83380400001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VUw5MXQ4cmVid3RDVUNMd1ZpYzZhQVB1anJjeXNaUGFoc0tuMFhoVDQwQkQ5?= =?utf-8?B?NU5laDNJZkl0WUQ5dE5xMS9aK2xiWTMzb0NDanZjV1dGNGhGSm00WFN6WU1D?= =?utf-8?B?SGpnSU14WnAzcGpqdDlGVFVLSGZkNUlYNGJiL3N2UXBDVllIbnlBZVdxdTFs?= =?utf-8?B?ZHFWQVF4S1ZpUkdMRVNNRVp6MFhPY012UXppcWJsWUFxNGVlNXRWUEdFd1Zm?= =?utf-8?B?eHBaY1gyMUdiaEJVaWRtWWI1UzdMd093em1zOXVvK09YZFl3VnloaXVQeTc0?= =?utf-8?B?cEJWdGpEMHQxSVJiRHFNMVlPK1hqcTc0eUpjYWpOUUNZQ1ZFSnA1bnRNWHV0?= =?utf-8?B?T3dEV0tKL2tDRExLYmZVUFZReWE2b3ZpVmtod04wblZ6MC9WMWZVcXdyTHc4?= =?utf-8?B?OEtRODY0VUFyZjFLT3l1UmJkM2thanQwb0orcHBDVHhFUmVya3lkb25PTFJW?= =?utf-8?B?cGVwTzF4ZllQQUk1cjdYVURrVnQrc1czck4xdGVhQmNKYk1oVVJENHBMT3hM?= =?utf-8?B?QjNuSVpLa1g0R3p0bEsrWXJFTExVT1Y3NkxaV2Q0NDVZOEVoZFZpWGs1aVRW?= =?utf-8?B?Z1p3eGZJVkV5MUhKUlBiMVordlJWdmx6VkVoS1JIMFdyT1E4d1NSOW5tSkFR?= =?utf-8?B?T0hzeElGSjFiSnVrOFlGMW1IQm5ES05Oc21lWitpcWQyTjBUL3U4SGFqay9X?= =?utf-8?B?QVA0NXoxS3FGZjFoWHh6N3Vma2NDcis2cEpwbTBRV2RnNXRsdXpYQ1c0bGU0?= =?utf-8?B?Nk5ZTFUzZTdFWkhMTEhzQ21ZeFQzdEJmUVcxNmhndFJzR2pBR3gwN0hKU1Jp?= =?utf-8?B?eC9JNU5wWUpGSytUaXp2K1UzMGFqeTBtbXhXblRyTS9hZUEwOHVlK3FEckxh?= =?utf-8?B?cFZabDVUbVBQVmZGaHNpTTBGVjg1Y1NPRWtwcTNITFN0NWdLQXpmNUcwOVpS?= =?utf-8?B?YkhWN1prNGdwNEhPdnd6NmdJWGZKM29Gdy9CT0plTE1zRTV6WDJwcDdxY00z?= =?utf-8?B?aXVjVEd1ZUdJczFUbUUrQjUvcG9tUlVkeXorZVFjWDdvK1Bjd3Rmd01CYXFQ?= =?utf-8?B?ams3bUJicUxRcDRrY0pQeEFma1E3MDBOcmxLMkRUV2Y4K2dFL3F6VDBieVZH?= =?utf-8?B?dHE1ZU9hVDA0U1k3eHRxc1RocDBmTEN3TnhQQzNvQmVnUHZ1UHJTemRCWTJq?= =?utf-8?B?MzRjcHlzNVVBN1hHMXRiYVgwYzlJNzdJUlEyODVXaWhBZmRwMHVHTWJsWWxK?= =?utf-8?B?Qlp0ekZWQ3JNSVBucDdCdXZ4d0FSZ3RxVFU4Ri80S081NmRONjVxOTllNEla?= =?utf-8?B?SWxnNlBCNzNuUm85MWs4Mk1QN2dPc1ZERFFkNE5PeU8xYU9qSkVMVEErc21u?= =?utf-8?B?b29tYnBMbzluMmJQQUxocllXcngzSDg5ZUxKV0h2cmMxRzJnRU9IYk0rS2hX?= =?utf-8?B?VGxoR0xzZ2NTL2ZETWFGWStyVUZJTFk4TW96N3RZMmtSS3N4Z1Q0dTFORG1C?= =?utf-8?B?ZDhCVVY1ei9IeS9EZFRpSnUxT2daN2E5Zmw5dWloMXV0SGlFbXB3TWJRVmNK?= =?utf-8?B?ZTJTbXJkT094czNnNkxZUElmYTIxdmdiUGpESE5nZ2pscDdCU0liZi9FNTZ1?= =?utf-8?B?OXFDWGhsSS8zNWZnYUFQY21MeS9HNkVwcDk2N1FTYm9KMjdEcngxOVlxS3Bz?= =?utf-8?B?dStnLzU5bUNvQVhmWTBKbm9vZ1dGcENCb2tsclVOYTcxbUtZZk00R0VvVWQw?= =?utf-8?B?dVR6YjRFTEZUYTduTFJQUlcxMDFCaGlZWFhGaDBrQjB0eVRFNHhYRkZaREUz?= =?utf-8?B?TEtjdVA0NkVuK0RVZ05pZ1RaTDVjZEZ4MU1CWlRraUNUL0I1WTJPNXJKejE3?= =?utf-8?B?dmtzSnEveHg0L2NZSWhtcXFWS2NzbHIvbGIvSDJveHg0akpibEx6NmdGelY4?= =?utf-8?B?YUVrVkxlVU1FbHhHMDI1aUJZUkltZUpXSEdydFg2RTVwNnZJYUV2ZHRrTTBv?= =?utf-8?B?TGxUcGNnT2o2bitSSXBnZmNtbTdoMkJ1andSR1NwVFpxNlNlajNBOUY2QU55?= =?utf-8?B?c1g3ZnFHSzlpY3FPc3BReDdIa282alJuWGtkVEN4bkFnZCtURlpnK0wvM2pE?= =?utf-8?B?TVUvbnA2ZmZHQVBhY1IzVTY4bmtFamVRTTkwSUk4NVFkRlNBMGR4cXU0SVoy?= =?utf-8?B?SEsxeTJLSnBDNUlHaVRIZTFqRjZFZmtCSnorL0h2Uzl6MlY4MU5uNWMvN2Vr?= =?utf-8?B?K2Zwakx2WUFaZzFOUzFSbzRHTXRDZGl5bURyYVFhVExXb20rN3htOWVpTGEv?= =?utf-8?B?SnRxWjkyKzU2cjh0cERjYXlTTlVQYlRFdmtPeTJUWjVad3lsOU96cnB2YTVo?= =?utf-8?Q?b9onUfcp5K5Z4t6DrBhEg8rDnkmW3i9E/RGur?= X-OriginatorOrg: os.amperecomputing.com X-MS-Exchange-CrossTenant-Network-Message-Id: ae2c1ab4-40a7-441c-2a19-08da2365dec4 X-MS-Exchange-CrossTenant-AuthSource: DM5PR0102MB3590.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2022 07:09:26.3822 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: r6v9Avl+URiIyVLGw3n49tPxttkOXt/Cxy7HzqC/Bk7SV8fssitPXUFL3c2mytmFJK8NxU6CleYZsBIu8r+keHQoGkvF96+/bDj9jVEPGwehvtZFIHCREha+ebTQ+ySx X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB4922 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220421_000931_916601_A000787C X-CRM114-Status: GOOD ( 38.78 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --2088271309-475416472-1650524966=:3744 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 20 Apr 2022, Robin Murphy wrote: > On 2022-04-20 00:05, Ilkka Koskinen wrote: >> >> Hi Robin, >> >> I need to go through your patches more carefully, but I do have a couple of >> comments already: > > Thanks for having a look! > >> On Mon, 18 Apr 2022, Robin Murphy wrote: >>> Add the identifiers and events for CMN-650, which slots into its >>> evolutionary position between CMN-600 and the 700-series products. >>> Imagine CMN-600 made bigger, and with most of the rough edges smoothed >>> off, but that then balanced out by some bonkers PMU functionality for >>> the new HN-P enhancement in CMN-650r2. >>> >>> Most of the CXG events are actually common to newer revisions of CMN-600 >>> too, so they're arguably a little late; oh well. >>> >>> Signed-off-by: Robin Murphy >>> --- >>> drivers/perf/arm-cmn.c | 222 ++++++++++++++++++++++++++++++++--------- >>> 1 file changed, 176 insertions(+), 46 deletions(-) >>> >>> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c >>> index 9c1d82be7a2f..cce8516d465c 100644 >>> --- a/drivers/perf/arm-cmn.c >>> +++ b/drivers/perf/arm-cmn.c >>> @@ -39,7 +39,7 @@ >>> #define CMN_CHILD_NODE_ADDR        GENMASK(27, 0) >>> #define CMN_CHILD_NODE_EXTERNAL        BIT(31) >>> >>> -#define CMN_MAX_DIMENSION        8 >>> +#define CMN_MAX_DIMENSION        12 >> >> I wonder if it made sense to dynamically allocate the arrays later in the >> code instead of allocating them in stack, especially if mesh topologies >> keeps growing fast. That would probably avoid setting max dimension >> altogether if one could use num_xps, num_dns etc. Just for future >> thoughts... > > Note that the group validation structure *is* dynamically allocated since the > last update, since it was already getting a bit big for the stack; it's just > not dynamically *sized*. That's a compromise to keep the validation code as > simple and efficient as it reasonably can be. I'm not entirely convinced that > extra complexity and runtime overhead for everyone is worth it for the sake > of making it slightly easier to catch an obvious bug if someone makes > out-of-tree hacks to the driver. This is not the only place which needs > updating (or at least checking) if the maximum number of possible DTMs really > does increase again. Probably not. If the mesh size grows remarkably, then it might make sense to revisit but it should be ok now. > >>> #define CMN_MAX_XPS            (CMN_MAX_DIMENSION * CMN_MAX_DIMENSION) >>> #define CMN_MAX_DTMS            (CMN_MAX_XPS + (CMN_MAX_DIMENSION - 1) * >>> 4) >> >> >> >>> @@ -1692,8 +1802,13 @@ static int arm_cmn_discover(struct arm_cmn *cmn, >>> unsigned int rgn_offset) >>>         cmn->num_dns += FIELD_GET(CMN_CI_CHILD_COUNT, reg); >> >> How about checking if child count is bigger than the maximum mesh size >> before this for loop? It would help in case someone would work on enabling >> support for new, bigger models and would forget to update >> CMN_MAX_DIMENSION... > > Hmm, I guess we do already warn and bail out if we find a mystery node type > that implies we're being lied to, but TBH that was always more to avoid > compilers moaning about the switch statement lacking a default case than > because I thought it's a necessary check in itself. Ultimately if someone > lies to the driver and claims that a CMN product is a different CMN product, > it's already not going to work properly due to the subtle differences in the > hardware, so I'd argue that potential memory corruption due to overrunning > array bounds in various places is really just part and parcel of "not working > properly". > > CMN-700 r0 and r2 seemed clear that 12x12 is the largest supported dimension; > r1 seemed a bit ambiguous between what the TRM said and what I could find in > the actual product deliverables, so I can double-check with the hardware team > if you like - or if you already know better, please do feel free to correct > my assumption :) That's fair point. I'm fine as it is now. Cheers, Ilkka >>>     } >>> >>> -    /* Cheeky +1 to help terminate pointer-based iteration later */ >>> -    dn = devm_kcalloc(cmn->dev, cmn->num_dns + 1, sizeof(*dn), >>> GFP_KERNEL); >>> +    /* >>> +     * Some nodes effectively have two separate types, which we'll handle >>> +     * by creating one of each internally. For a (very) safe initial >>> upper >>> +     * bound, account for double the number of non-XP nodes. >>> +     */ >>> +    dn = devm_kcalloc(cmn->dev, cmn->num_dns * 2 - cmn->num_xps, >>> +              sizeof(*dn), GFP_KERNEL); >>>     if (!dn) >>>         return -ENOMEM; >>> >> >> >> >>> @@ -1970,6 +2098,7 @@ static int arm_cmn_remove(struct platform_device >>> *pdev) >>> #ifdef CONFIG_OF >>> static const struct of_device_id arm_cmn_of_match[] = { >>>     { .compatible = "arm,cmn-600", .data = (void *)CMN600 }, >>> +    { .compatible = "arm,cmn-650", .data = (void *)CMN650 }, >>>     { .compatible = "arm,ci-700", .data = (void *)CI700 }, >>>     {} >>> }; >>> @@ -1979,6 +2108,7 @@ MODULE_DEVICE_TABLE(of, arm_cmn_of_match); >>> #ifdef CONFIG_ACPI >>> static const struct acpi_device_id arm_cmn_acpi_match[] = { >>>     { "ARMHC600", CMN600 }, >>> +    { "ARMHC650", CMN650 }, >> >> Not the great place for this comment but there probably isn't any better. >> >> Based on DEN0093 v1.1, CMN's DSDT entries have been changed since CMN-600. >> ROOTNODEBASE seems to be specific for CMN-600. Moreover, if you compare the >> address maps in TRMs' Discovery chapters, you can see the difference. >> >> I'm thinking, at the minimal the second platform_get_resource() call has to >> be skipped and zero returned in arm_cmn600_acpi_probe(), if the model is >> cmn650 (probably also for cmn-700) > > As you've already found, things prefixed with "arm_cmn600_" vs. "arm_cmn_" > *are* specific to CMN-600, and the CI-700 update reworked this area such that > everything else simply probes in a firmware-agnostic manner. It may have been > a bit subtle since CI-700 doesn't have an ACPI binding, but it was very much > intended to cover these future ACPI additions as well. > > Thanks, > Robin. > --2088271309-475416472-1650524966=:3744 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --2088271309-475416472-1650524966=:3744--