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 EFF2CC4332F for ; Wed, 12 Oct 2022 17:31:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tEEu/nbvV0gwAC2qtVoaB9X0Q53LLmrWAbk8XuAM/0E=; b=KQ6Wmoz4vBdxJ2 zmbhySgt8/x1hj946kVOoytm00L7gfykG3anBznoGavYtdscAY/jUaiAg67yMa4bmy/Y3gtKvaKgQ LXzkLq3I5dsGOogawAGrTNz1wPsqXQpII7pkigUSYzi6xSCYF8U3+A6InUE8GPlTAn4aLXHGQWiLF tm/ucZLm/lMyPTn6cPpLYA2NGwQyXGNBEeLEALP/8j9qu3VZablFPIyDHq9yOOKbu86bnC/YlilWI Zl8iFWAsMXxqDmzYVZTFxTUaLJgIViNyT0fusv3ZKXERuMwHN58TKnDXOyGpPn6PHZDezKRlhyh0A PZOYjQHE063PaNDPzMdg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oifXy-008qtr-1A; Wed, 12 Oct 2022 17:29:34 +0000 Received: from mail.skyhub.de ([2a01:4f8:190:11c2::b:1457]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oifXu-008qst-E8 for linux-arm-kernel@lists.infradead.org; Wed, 12 Oct 2022 17:29:32 +0000 Received: from zn.tnic (p200300ea9733e705329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e705:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 8D4501EC0304; Wed, 12 Oct 2022 19:29:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1665595762; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=yQ3NJCYhGzQnwvOx2Fbc1ZbVY18C8OhIiN6ipKV7+4Y=; b=JZOAjQ0shdBqZOR9jqUdFuqz2kiUEYIEFgLRh+D6pM3KurzGFbfhqt3gopRykRl42J/303 6cNHZeSM8eHtTeZwMCFsQ7F6X3F7/ZjQlK1bRzAQJYpvKtDAD5frQiu9GXNxzWaBoFZNPP SWMwHhjbMtFNXCNM2a5jgiKfjyiVBfw= Date: Wed, 12 Oct 2022 19:29:22 +0200 From: Borislav Petkov To: Serge Semin Cc: Michal Simek , Mauro Carvalho Chehab , Tony Luck , James Morse , Robert Richter , Serge Semin , Alexey Malahov , Michail Ivanov , Pavel Parkhomenko , Punnaiah Choudary Kalluri , Manish Narani , Dinh Nguyen , Rob Herring , Krzysztof Kozlowski , Rob Herring , Krzysztof Kozlowski , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND v3 13/17] EDAC/mc: Add MC unique index allocation procedure Message-ID: References: <20220929232712.12202-1-Sergey.Semin@baikalelectronics.ru> <20220929232712.12202-14-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220929232712.12202-14-Sergey.Semin@baikalelectronics.ru> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221012_102930_654379_BDCD64BB X-CRM114-Status: GOOD ( 20.03 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Sep 30, 2022 at 02:27:08AM +0300, Serge Semin wrote: > In case of the unique index allocation it's not that optimal to always > rely on the low-level device drivers (platform drivers), because they get > to start to implement either the same design pattern (for instance global > static MC counter) or may end-up with having non-unique index eventually > at runtime. Needless to say that having a generic unique index > allocation/tracking procedure will make code more readable and safer. I guess this is trying to say that the current memory controller index thing doesn't work. But why doesn't it work? It works just fine with the x86 drivers - there the memory controller number is the same as the node number where it is located so that works just fine. If that scheme cannot work on other systems, then I need to see an explanation why it cannot work first. > The suggested implementation is based on the kernel IDA infrastructure > exposed by the lib/idr.c driver with API described in linux/idr.h header > file. It's used to create an ID resource descriptor "mc_idr", which then > is utilized either to track the custom MC idx specified by EDAC LLDDs or > to allocate the next-free MC idx. This is talking about the "what" and not the "why". > A new special MC index is introduced here. It's defined by the > EDAC_AUTO_MC_NUM macro with a value specifically chosen as the least > probable value used for the real MC index. In case if the EDAC_AUTO_MC_NUM > index is specified by the EDAC LLDD, the MC index will be either retrieved > from the MC device OF-node alias index ("mc[:number:]") or automatically > generated as the next-free MC index found by the ID allocation procedure. This is also talking about the "what" and not the "why". At best, what you're doing should be visible from the patch itself. Here's a longer explanation of how a commit message should look like: https://kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel