From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4CE6B315785; Wed, 10 Sep 2025 13:41:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757511703; cv=none; b=frsfJ/aZS7tnpu8CDEA0wjQps8ohiYT0/R+OpWtPAxp2DcG5UhMN7QSIO6cGKhpnTa9NYJkGr3ePZPbuwOnKxTzvq5aLAPQMJ0Zvo1pJztStqSX17emCBOtQwkv5hokaj6cl2i87KFq5O48+RpZQ3f8LngD8RN4fV8HesoCe1HA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757511703; c=relaxed/simple; bh=/60SYAM/5dBbuXfohlZHRDxhelvt0nUOOqE7eCNk7RI=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WpTu5qfGw1r2KgV/abdJHTULG4dzXWhcnXkgC2MMQx1zCziR6KMiePPEGqPj5tGB42yF3qxD9+o3pV1D/TUEf7VLuIX+9w8XaZ1epxkQUWYG0X7eByvaTFTa5E4GaAp4cmDNCIyGzx17RrJAR2jiOUri5uahbz+HZgwelgNA+lc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4cMMGr0P6xz6LDJl; Wed, 10 Sep 2025 21:39:00 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id 7B30F1404FD; Wed, 10 Sep 2025 21:41:38 +0800 (CST) Received: from localhost (10.203.177.15) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 10 Sep 2025 15:41:37 +0200 Date: Wed, 10 Sep 2025 14:41:36 +0100 From: Jonathan Cameron To: Smita Koralahalli CC: , , , , , Davidlohr Bueso , Dave Jiang , Alison Schofield , Vishal Verma , Ira Weiny , Dan Williams , Matthew Wilcox , Jan Kara , "Rafael J . Wysocki" , Len Brown , Pavel Machek , Li Ming , Jeff Johnson , Ying Huang , Yao Xingtao , "Peter Zijlstra" , Greg KH , Nathan Fontenot , Terry Bowman , Robert Richter , "Benjamin Cheatham" , PradeepVineshReddy Kodamati , Zhijian Li Subject: Re: [PATCH 5/6] dax/hmem: Reintroduce Soft Reserved ranges back into the iomem tree Message-ID: <20250910144136.000002e2@huawei.com> In-Reply-To: <20250822034202.26896-6-Smita.KoralahalliChannabasappa@amd.com> References: <20250822034202.26896-1-Smita.KoralahalliChannabasappa@amd.com> <20250822034202.26896-6-Smita.KoralahalliChannabasappa@amd.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml100009.china.huawei.com (7.191.174.83) To frapeml500008.china.huawei.com (7.182.85.71) On Fri, 22 Aug 2025 03:42:01 +0000 Smita Koralahalli wrote: > Reworked from a patch by Alison Schofield > > Reintroduce Soft Reserved range into the iomem_resource tree for dax_hmem > to consume. > > This restores visibility in /proc/iomem for ranges actively in use, while > avoiding the early-boot conflicts that occurred when Soft Reserved was > published into iomem before CXL window and region discovery. > > Link: https://lore.kernel.org/linux-cxl/29312c0765224ae76862d59a17748c8188fb95f1.1692638817.git.alison.schofield@intel.com/ > Co-developed-by: Alison Schofield > Signed-off-by: Alison Schofield > Signed-off-by: Smita Koralahalli A few trivial things inline. Not are important enough to need a change though. Reviewed-by: Jonathan Cameron > --- > drivers/dax/hmem/hmem.c | 38 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 38 insertions(+) > > diff --git a/drivers/dax/hmem/hmem.c b/drivers/dax/hmem/hmem.c > index 90978518e5f4..24a6e7e3d916 100644 > --- a/drivers/dax/hmem/hmem.c > +++ b/drivers/dax/hmem/hmem.c > @@ -93,6 +93,40 @@ static void process_defer_work(struct work_struct *_work) > walk_hmem_resources(&pdev->dev, handle_deferred_cxl); > } > > +static void remove_soft_reserved(void *data) > +{ > + struct resource *r = data; > + > + remove_resource(r); Type doesn't really help us here so why not skip the local variable. remove_resource(data); kfree(data); Though I'd rename data to r. > + kfree(r); > +} > + > +static int add_soft_reserve_into_iomem(struct device *host, > + const struct resource *res) > +{ > + struct resource *soft = kzalloc(sizeof(*soft), GFP_KERNEL); > + int rc; > + > + if (!soft) > + return -ENOMEM; > + > + *soft = DEFINE_RES_NAMED_DESC(res->start, (res->end - res->start + 1), > + "Soft Reserved", IORESOURCE_MEM, > + IORES_DESC_SOFT_RESERVED); > + > + rc = insert_resource(&iomem_resource, soft); > + if (rc) { > + kfree(soft); Could use __free() magic here and steal the pointer when you setup the devm action below. Only a small simplification in this case, so up to you. > + return rc; > + } > + > + rc = devm_add_action_or_reset(host, remove_soft_reserved, soft); > + if (rc) > + return rc; > + > + return 0; Trivial: return dev_add_action_or_reset(host...) > +}