Received-SPF: pass (google.com: domain of linux-kernel+bounces-203336-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Thu, 6 Jun 2024 01:10:43 +0300
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Chia-I Wu <olvaffe@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Dave Jiang <dave.jiang@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] resource: add a simple test for walk_iomem_res_desc()
Message-ID: <ZmDiYze9MEFxn50C@smile.fi.intel.com>
References: <20240605212840.3227774-1-olvaffe@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240605212840.3227774-1-olvaffe@gmail.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

On Wed, Jun 05, 2024 at 02:28:26PM -0700, Chia-I Wu wrote:
> This mainly tests that find_next_iomem_res() does not miss resources.

...

> v2: update subject, use DEFINE_RES_NAMED and hardcoded offsets
> v3: really hardcode offsets, with 4KB intervals since 0x1000 is easier
>     to read than 0x400

Right, but...

> v4: use RESOURCE_SIZE_MAX, split allocate_resource and KUNIT_ASSERT_EQ,
>     and other cosmetic changes

...

> +	ret = allocate_resource(&iomem_resource, &root, 0x100000,
> +			0, RESOURCE_SIZE_MAX, 0x100000, NULL, NULL);

Just double check that limits.h is included.

...

> +	/* build the resource tree */
> +	res[0] = DEFINE_RES_NAMED(root.start + 0x0000, 0x1000, "SYSRAM 1",
> +			IORESOURCE_SYSTEM_RAM);
> +	res[1] = DEFINE_RES_NAMED(root.start + 0x1000, 0x1000, "OTHER", 0);
> +
> +	res[2] = DEFINE_RES_NAMED(root.start + 0x3000, 0x1000, "NESTED", 0);
> +	res[3] = DEFINE_RES_NAMED(root.start + 0x3800, 0x0400, "SYSRAM 2",
> +			IORESOURCE_SYSTEM_RAM);

...here is overlap with the previous resource.

And here is the gap to the next one, in case we make that overlapping gone.

> +	res[4] = DEFINE_RES_NAMED(root.start + 0x4000, 0x1000, "SYSRAM 3",
> +			IORESOURCE_SYSTEM_RAM);

It wasn't the case in previous data. Please, elaborate what's going on here?

...

And rather sending one version per 12h, take your time and think more about
test data. What are we testing? Are the testing data correct? Shouldn't we also
have negative test cases?

-- 
With Best Regards,
Andy Shevchenko