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 X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B260DC433DF for ; Thu, 8 Oct 2020 22:53:53 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 058FD22247 for ; Thu, 8 Oct 2020 22:53:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UcanyVXf"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IpMzov0X" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 058FD22247 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=m6fChj6GAPQLjXqi2+eU1lYbzv5ddT1/WKiUhXrejes=; b=UcanyVXfe2SRqubC4T7Hi3aHJ cf4aZdrnH61JVRlwh44GqBar+h3/4sg+Xt+1F/hcqBtScxKDejAj2EbSux6Ym4VR9AIll/IzDRXay 6cDD4SypfvhtZnx/K/06xNuxdimVSF6VP0LMV26pVoAmAIHmn4Wfxg9bMm09BGNm2S4GaXsaZeOk9 xoULtA5Nd7kep08hnAlGaM+o/S1qRJvg8/RtyNYfIB3lotmyDpXEeosACpEs5YQhLWXOhLSsZjXa4 sLR8fWAFw0IUVrC6X/CNCBzIBdKG9+ZzoWtstPyCWtSDDVT9qqvmq/CU8AOYj1aqHlv9PpKUd5O7P KZastwamA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQelD-0004db-Qk; Thu, 08 Oct 2020 22:51:43 +0000 Received: from mail-lf1-x143.google.com ([2a00:1450:4864:20::143]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQelB-0004cu-TD for linux-arm-kernel@lists.infradead.org; Thu, 08 Oct 2020 22:51:42 +0000 Received: by mail-lf1-x143.google.com with SMTP id u8so8567364lff.1 for ; Thu, 08 Oct 2020 15:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+VlAI1YSrsYI6fzVFb3g9FcKulcdSQODpndVq6tk5uk=; b=IpMzov0XwVz6y2DN9VpJrCf8gcG44HJ6YkUwVt3g2DMHLVTYxKt4HkK+Ocj9EKaif0 z6bqK6aXY9KloOilUcrWnUrIpZLfVq6/UAO7bypcCeAQiUaCyGuRxNsp2dO2Zu9IvG17 UTK7/ut3eg0UIkCZyCIqTE1WEfWj61xVyJmkTlLI4E4+xaQi4qILEtSREaSFhg7YckZX Oqenk5GPhrTvjX87AUQoEFJ1XhcU15D+FuFNJJOfP6bfs5GozlVznCNV+o4RmipZD9UJ yiEwgw0ccGWNCj+Wu7qcf3Di6OHpgJPQiUyLvlYXt9/T97HcsSabAPp2Wi4ljcKdIZ7h xzvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+VlAI1YSrsYI6fzVFb3g9FcKulcdSQODpndVq6tk5uk=; b=IaIvCxqv/1wIYV1lKIs9CkzeoFcZnasu282f56ortcM9t6pnWz/aucHgdnI+c0IKIp Jw37oWTWI0PgTydL2IKz4fPZ9f+KOjFLpB/RJ4meJ/ZG7e4vd+eVc+K7P//eZLhmjPAT HSnBDxeHPatpj+1Wai89aDKZuHupyq44JjSBaeBq2jJAB7JKcDGZom+TMHRawm898oUn 5hFhp1oWwmE2CWRedJnQPyPBF56XqNA6WTSyt4Sh9eu1ftu4nRYRXX67gSGn8ChDLtHE HOmKwDRxImxxewezAVSLj6/fzkhWz/E7PhdRtjVJQi+0D4guTQ1GbNgiYtzhb1fcZn50 Vnuw== X-Gm-Message-State: AOAM530ubPH6M3LRJvImoONo6/30NHzTyHqZ0I/7e7kmwxS6yN/4Kgm9 yOt8kfTaZI0Z6k4iaNbQ36Y= X-Google-Smtp-Source: ABdhPJz8peLdBnw2a3w8E0KNLkKDaDyZrhi00t6H64Vw12F6R9mSo/sp2NbTJj+KC9Ql17fdfHdCbg== X-Received: by 2002:a19:ca1e:: with SMTP id a30mr3180759lfg.575.1602197500497; Thu, 08 Oct 2020 15:51:40 -0700 (PDT) Received: from mobilestation ([95.79.141.114]) by smtp.gmail.com with ESMTPSA id z19sm662792lfr.46.2020.10.08.15.51.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2020 15:51:39 -0700 (PDT) Date: Fri, 9 Oct 2020 01:51:37 +0300 From: Serge Semin To: "Maciej W. Rozycki" Subject: Re: [PATCH v2] MIPS: replace add_memory_region with memblock Message-ID: <20201008225137.rbb7b6rogv3bbvi7@mobilestation> References: <20201008084357.42780-1-tsbogend@alpha.franken.de> <20201008152006.4khkbzsxqmmz76rw@mobilestation> <20201008155454.kaal2bchjq7wusqr@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-20201008_185141_983078_D95A9E6D X-CRM114-Status: GOOD ( 31.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Fainelli , Hauke Mehrtens , =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , linux-mips@vger.kernel.org, Jiaxun Yang , linux-kernel@vger.kernel.org, Thomas Bogendoerfer , bcm-kernel-feedback-list@broadcom.com, John Crispin , Keguang Zhang , linux-arm-kernel@lists.infradead.org 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 Thu, Oct 08, 2020 at 05:56:17PM +0100, Maciej W. Rozycki wrote: > On Thu, 8 Oct 2020, Serge Semin wrote: > > > > > At least I don't see a decent reason to preserve them. The memory registration > > > > method does nearly the same sanity checks. The memory reservation function > > > > defers a bit in adding the being reserved memory first. That seems redundant, > > > > since the reserved memory won't be available for the system anyway. Do I miss > > > > something? > > > > > > > > At the very least it serves informational purposes as it shows up in > > > /proc/iomem. > > > > I thought about that, but /proc/iomem prints the System RAM up. Adding the reserved > > memory regions to be just memory region first still seem redundant, since > > reserving a non-reflected in memory region most likely indicates an erroneous > > dts. I failed to find that, but do the kernel or DTC make sure that the reserved > > memory regions has actual memory behind? (At least in the framework of the > > memblock.memory vs memblock.reserved arrays or in the DT source file) > > Reserved regions need not be RAM or a memory-like device. Agree. My statement about considering as error the situation when the reserved-memory is declared with no backed DRAM region was most likely wrong. But in this case what we currently do and what Thomas suggest to keep doing in the framework of the MIPS-specific early_init_dt_reserve_memory_arch() is probably incorrect, since the method makes sure that any added reserved memory region is actually backed with DRAM (called both memblock_add() and memblock_reserve() for such regions). None of the other platforms is noticed to execute the same pattern. > They could be > floating bus even. Here's an example from my x86 laptop where all kinds > of stuff is marked reserved: > > 00000000-00000fff : Reserved > 00001000-0009cfff : System RAM > 0009d000-0009ffff : Reserved AFAICS from the ./arch/x86/kernel/e820.c code, the regions marked as "Reserved" aren't mem-mapped by the kernel, since they are skipped in the method e820__memblock_setup(), which is responsible for the x86-specific memory mapping data conversion to the memblock. So the system doesn't consider them as a RAM resource. Note each normal memory is supposed to be added to the memblock, so to be then used by the buddy allocator for normal memory allocations. Basically the x86-specific "Reserved" regions are similar to the regions added by means of the "reserved-memory" DT sub-node with "no-map" property specified. The problem in the topic is whether we must or must not make sure that each reserved-memory region with no "no-map" property considered as normal memory region backed with DRAM. The rest of the platforms currently just register the "reserved-memory" regions in memblock.reserved with no checking whether they are backed with corresponding DRAM region and with no adding them to the memblock.memory pool. So most likely we ought to do the same in MIPS. > ... > > > Actually another reason to mark regions reserved is to prevent them from > being claimed by the wrong driver or, perhaps more importantly, used for > assigning bus address ranges to hardware resources (BAR programming). Right, AFAICS that's what the "reserved-memory" DT node has been introduced for. By using it we can create a DMA/CMA memory pool fully dedicated for a particular device, or just completely remove a memory region from the kernel virtual mapping framework if instead of providing an access to the System RAM a region is remapped to IO to/from some hardware resource. -Sergey > > > I also don't see the other platforms doing that, since the MIPS arch only > > redefines these methods. So if a problem of adding a reserved memory with > > possible no real memory behind exist, it should be fixed in the cross-platform > > basis, don't you think? > > I think doing things in a generic way where possible is surely desired, > however platforms have different ways to discover resources and I can't > see offhand how this could be unified. I haven't look at that code for a > while now, so I can't be more specific offhand. > > Maciej > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel