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 D59DAC4332F for ; Wed, 12 Oct 2022 21:32:25 +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=eiLVH6Xqz3cu58BEiwyO7AAgp2Pw38dpUAxlTt4VfPA=; b=Z4uKVLiHaYpuf5 0D/X5jK/qNBTYCO5OOtGu5mFJ7zHObcPtd+AffccR2uPVrKkYNsbMho0ak0ibDpBZcWtKUpsHmqx1 WLSLPIy+IXaZhhQZnZleemejlmPYnb4GSgccr29LryJHuUMBmhcfBkw6rREo85OgoFosdtSBUgYPc gQB1oGO23PaAoOiwwpNvu4Xw5phH/LKW/Iwa2UTp5y7kv4x97Dl04mTXIfy7B2ew/abhK7u4G4A6z 2orGNvTEWxLEggaWtNGUu675yP/uEhgQZPl4FKnWWkstOBL+qcQAc59tTv4J7eO83sPjaNZaHrJsr L3rUIadzVYdF4dFUeAQA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oijK5-009PJG-9m; Wed, 12 Oct 2022 21:31:29 +0000 Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oijJu-009PFs-TW for linux-arm-kernel@lists.infradead.org; Wed, 12 Oct 2022 21:31:20 +0000 Received: by mail-lj1-x232.google.com with SMTP id x18so112847ljm.1 for ; Wed, 12 Oct 2022 14:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+u5zTxsQpjiuj7kJ8NImmHJwlmXGjiHmqr7wGB9659Y=; b=SaKHthR+wG3Es3kmvRYC96e31d2/qYDWIOmiGR64bxw/8Lt4fTC/kE4uLXiyeboZNk twGw7vqpIpx4oGsX6MbkWCaA8NwOvtixhXZHPSd7BO8L0cWMcRkcREjQviGLVTXWLRiz pdmrvSGH+Pt/KP0e1njrrcYVWVcAMKHoiIyH5zwTgsoLR1P0ZAWs2PLZ1RDm3cdit4a9 CMVfKoYZt956B2Rg2W9vO0mwciR45C9t1LUpDehaDBFjouoF46YBpPLpzhYUR4CCJpYs qWzUC7S4RmG5DSfjR8KWie8jTR3qyEA8Gu2BIuL/oAzRaQRKQA0eR6zwMNSmvDs7w/m9 K6rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+u5zTxsQpjiuj7kJ8NImmHJwlmXGjiHmqr7wGB9659Y=; b=nDheYjCRH61S77lHIzVQ2Y85iqJWOY+QXGo8sc/GLqTAQuYcQmqSTS8OmbB0y+/3Ao 7JdEcWO5kT+kTfxUTZYU2hmdkxBQRfVJ04k8nHVGZegJSHrGrgDB4/8EQQdtGJkHMHEb KlML54w7BtAEB+I6VBWNWcO1HtLeQwGv4xaFV93JZOxxMMJ4/oSwOKMi8HJZT1VgyQ11 glh4xG8Ffqi5PsBnvJMgN+9dGuTypjO6CeQwvmNh2d8f6fGcmENwHlWJbG2aLf9WGgN/ ZHIf3qnMZcnFYf4c02CnOR9DKNLiT4rj1ZpxzvPEAipA3uKRdHi3QVR8/LOYnbDBv2WZ Olsg== X-Gm-Message-State: ACrzQf26L0WwyOjuK/lLVYlpsGZeXd/OWdvTG3oodssgS6r/bkyBSNOc A06SxCslDZGox6HUqUcfOlexG9x3nZtxZA== X-Google-Smtp-Source: AMsMyM5nPJG9As/+UNLN3CVpn76zI3Ad1+oKSu/NW+qfUWOTHWvdb5VmDyFjw0EgSUpbKK7OxzVZHg== X-Received: by 2002:a2e:a887:0:b0:26a:ba85:8fbe with SMTP id m7-20020a2ea887000000b0026aba858fbemr10875427ljq.14.1665610276205; Wed, 12 Oct 2022 14:31:16 -0700 (PDT) Received: from mobilestation ([95.79.133.202]) by smtp.gmail.com with ESMTPSA id t18-20020a056512209200b004946bec4e7fsm119652lfr.41.2022.10.12.14.31.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Oct 2022 14:31:15 -0700 (PDT) Date: Thu, 13 Oct 2022 00:31:13 +0300 From: Serge Semin To: Tony Luck Cc: Borislav Petkov , Serge Semin , Michal Simek , Mauro Carvalho Chehab , James Morse , Robert Richter , 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: <20221012213113.fop4kqqtu43hka4b@mobilestation> References: <20220929232712.12202-1-Sergey.Semin@baikalelectronics.ru> <20220929232712.12202-14-Sergey.Semin@baikalelectronics.ru> <20221012200154.7fq3i7igbgkcy2mx@mobilestation> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221012_143118_973906_8267A895 X-CRM114-Status: GOOD ( 20.83 ) 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 Wed, Oct 12, 2022 at 01:44:59PM -0700, Tony Luck wrote: > On Wed, Oct 12, 2022 at 10:33:35PM +0200, Borislav Petkov wrote: > > On Wed, Oct 12, 2022 at 11:01:54PM +0300, Serge Semin wrote: > > > "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." > > Just curious.If I have an EDAC driver using EDAC_AUTO_MC_NUM, and I > unload and reload the driver a bunch of times. Do I get the same memory > controller numbers each reload, or get an ever increasing set each time? You'll get the same numbers if no other device-driver allocated them (which we already established isn't relevant to EDAC since only one driver per system is supposed to work). In order to implement what you said I should have called idr_alloc_cyclic() instead. Here is what the suggested implementation implies: 1. If there is a particular ID assigned in the framework of the dts aliases (i.e. mcX = &ddr0) then that value will be selected for the controller. 2. If no particular ID is assigned but there are mcX-like aliases defined in DTS, then the next free id greater than the last mcX value will be assigned. 3. If none if the above is relevant the first free ID in the pool will be allocated. 4. On the driver unload the driver remove method will be called thus the allocated ID will be freed on the MC-controller de-registration. Thus on the next driver loading the freed IDs will be reused by the idr_alloc() method design. -Sergey > > -Tony _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel