From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 40B7110A19; Sun, 16 Jun 2024 23:01:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718578870; cv=none; b=Mocb2AbQaHfL1fvTZr+SJZKcWYjT+k5uOHiJM7PM84a4bRIYbQR06V7xu9CeKM5GVIj36lvFgh/3FxtLOxa5dXPCweIvLRYpJ9Fk/tH6tjjzUIBCLZkRKTl5tysVxSj/aoZ+gY0R3T7Y91Qqcwuw8jQnX/3lIEnqMLKwV5psDOg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718578870; c=relaxed/simple; bh=K48GiByJehCmQjwi20pmfnU+WsCyr4S6WxHNS+fcYIA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uh6pMmiFu5xqPR7Z/U1lymQeYPmCkA6GxGpBfT67r8jaQUVClVksoz0lp+nYju99c+cKHW9xhaz03bvBZhnlePOD2Tlitc4SDB4nD08kZSly4NpuSZ4js4wy35ORJjqJH0l4GEF4Ovb36l9Xuq/iNyLAmi2qiE+C3XDN8bn13NY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gczAGXT2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gczAGXT2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CAA0C2BD10; Sun, 16 Jun 2024 23:01:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718578869; bh=K48GiByJehCmQjwi20pmfnU+WsCyr4S6WxHNS+fcYIA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=gczAGXT2JgNBboue0aH6XDCajaGt0Tn9T6RNwUC8NdBoTEgjtTbwpmUfCPkjFQ9wM MM968k+DIaMHgn73yxqDo9X2C3EJ5/755Y+99nXMZx497l32DWuxyKEgkUS1Mfauzi zlSFlVj6tWpctoPTJ+wOY0xCMexSj4HtxdjXI3+rZfPjj6bie6Cukz6u7sVo5A7bEU 9rKTuHOjY9Tr5Ii5b3jprMmIgspdDlLslR4qSbgMPqGu86/2ypBmGpS+m4Lh9tPaWA jbUd1obFjKTKufNm0BQAftChaDznmaK4Iq8S3q+7ZRNQrBkFu3/tvjG2xwv4gQQlB4 JHm9Ls++1gm6g== Message-ID: <5a697233-0611-459d-b889-2e0133bbb541@kernel.org> Date: Mon, 17 Jun 2024 08:01:04 +0900 Precedence: bulk X-Mailing-List: linux-bcache@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 02/26] sd: move zone limits setup out of sd_read_block_characteristics To: Christoph Hellwig Cc: Jens Axboe , Geert Uytterhoeven , Richard Weinberger , Philipp Reisner , Lars Ellenberg , =?UTF-8?Q?Christoph_B=C3=B6hmwalder?= , Josef Bacik , Ming Lei , "Michael S. Tsirkin" , Jason Wang , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alasdair Kergon , Mike Snitzer , Mikulas Patocka , Song Liu , Yu Kuai , Vineeth Vijayan , "Martin K. Petersen" , linux-m68k@lists.linux-m68k.org, linux-um@lists.infradead.org, drbd-dev@lists.linbit.com, nbd@other.debian.org, linuxppc-dev@lists.ozlabs.org, ceph-devel@vger.kernel.org, virtualization@lists.linux.dev, xen-devel@lists.xenproject.org, linux-bcache@vger.kernel.org, dm-devel@lists.linux.dev, linux-raid@vger.kernel.org, linux-mmc@vger.kernel.org, linux-mtd@lists.infradead.org, nvdimm@lists.linux.dev, linux-nvme@lists.infradead.org, linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org, linux-block@vger.kernel.org References: <20240611051929.513387-1-hch@lst.de> <20240611051929.513387-3-hch@lst.de> <40ca8052-6ac1-4c1b-8c39-b0a7948839f8@kernel.org> <20240613093918.GA27629@lst.de> From: Damien Le Moal Content-Language: en-US Organization: Western Digital Research In-Reply-To: <20240613093918.GA27629@lst.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/13/24 18:39, Christoph Hellwig wrote: > On Tue, Jun 11, 2024 at 02:51:24PM +0900, Damien Le Moal wrote: >>> + if (sdkp->device->type == TYPE_ZBC) >> >> Nit: use sd_is_zoned() here ? > > Actually - is there much in even keeping sd_is_zoned now that the > host aware support is removed? Just open coding the type check isn't > any more code, and probably easier to follow. Removing this helper is fine by me. There are only 2 call sites in sd.c and the some of 4 calls in sd_zbc.c are not really needed: 1) The call in sd_zbc_print_zones() is not needed at all since this function is called only for a zoned drive from sd_zbc_revalidate_zones(). 2) The calls in sd_zbc_report_zones() and sd_zbc_cmnd_checks() are probably useless as these are called only for zoned drives in the first place. The checks would be useful only for passthrough commands, but then we do not really care about these and the user will get a failure anyway if it tries to do ZBC commands on non-ZBC drives. 3) That leaves only the call in sd_zbc_read_zones() but that check can probably be moved to sd.c to conditionally call sd_zbc_read_zones(). -- Damien Le Moal Western Digital Research