From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (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 1F60A3C28 for ; Wed, 5 Jun 2024 22:10:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717625450; cv=none; b=QboURizBue4lTAzCdjd9UR/Vca0/5RQ+iqhFYBqwAGXbkNBj376m8MwaFXlqdKZ9tUsYFnjlhzrMNhrCb4eFGBmR9EWVA6qSLTOXzDeveOSj+hr7JoN4+Z3XSUCPa+odIlxGjvB2Smajs/BjZecuHW3CxuKWpLLYLvz+UrxhOOY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717625450; c=relaxed/simple; bh=tCyXM0NybvB2VFYCWYFtH2Ul4E7dIl0waEGFFsUqOok=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Biu6/JfhZ/2zjd/J5FPz4huHux4+ln+AXpCqC6WDiNCnWToia7OVMuOWnB3ywE+T8kT0iSCvJlPTsQ9BU+HYJc0EZTQwqbuJ+19D3Jpms49ZLzkASIkSEW7GXqkpA1yfbA71vGQCG4yKw7cWID6DLtjf478LDP2ZsDn5wn01Kdc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=PheCa5Cg; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="PheCa5Cg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1717625450; x=1749161450; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=tCyXM0NybvB2VFYCWYFtH2Ul4E7dIl0waEGFFsUqOok=; b=PheCa5CgohGtnm7j1trpP7//j53h2tOz715CTtYkiiIbym18Ygl3/fOq Zn10/I/TkUPwPxTT0kgQc+pLBxRzSJhS3vPqTVKGB+kpTmbldNEgz0AfK X52JnjkiNZnQjaFBaWjxtWa3Bo4G7lAQYZWOXdz9hrH/+1PQvIpETZhtX jhJRvG4QWAC4vjg4RxckugOnfusZq7BFr/iLRDTAJ+9oV4JrATPmfMNYy +FlWebDTmcBTAVWBxv1eg2Hy7QErCCI4R9UCK2rxqNIEpLLfb+yx+DcJ7 8Iw1MZ003Q6T+7ch+DTUDN/Wk7u3LUErFP67hvfPoL64JWzVSu1vLL6DG Q==; X-CSE-ConnectionGUID: AUCzep+CQAqIRIdon6cdQw== X-CSE-MsgGUID: /RKRJpd3SWqvxI4HBq63QA== X-IronPort-AV: E=McAfee;i="6600,9927,11094"; a="14103428" X-IronPort-AV: E=Sophos;i="6.08,217,1712646000"; d="scan'208";a="14103428" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jun 2024 15:10:49 -0700 X-CSE-ConnectionGUID: bW6GitTgQZqpARu09CsCkA== X-CSE-MsgGUID: J9Ky4YJvT4WlTyYNBahZhA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,217,1712646000"; d="scan'208";a="37813273" Received: from smile.fi.intel.com ([10.237.72.54]) by orviesa009.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jun 2024 15:10:47 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.97) (envelope-from ) id 1sEyqB-0000000DyuJ-3TNX; Thu, 06 Jun 2024 01:10:43 +0300 Date: Thu, 6 Jun 2024 01:10:43 +0300 From: Andy Shevchenko To: Chia-I Wu Cc: Greg Kroah-Hartman , Dan Williams , AKASHI Takahiro , Dave Jiang , Alison Schofield , Baoquan He , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] resource: add a simple test for walk_iomem_res_desc() Message-ID: References: <20240605212840.3227774-1-olvaffe@gmail.com> 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-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