Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp382390pxf; Thu, 8 Apr 2021 05:16:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzPq+ViZSi0q4x6Xtf+m9GgjXm5xaESZTHFSqxaZTfpnFi97b57kF1h3usAFIRiTCKP514U X-Received: by 2002:a05:6402:5211:: with SMTP id s17mr11008571edd.327.1617884218061; Thu, 08 Apr 2021 05:16:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617884218; cv=none; d=google.com; s=arc-20160816; b=QS+8JAjh7zESLR2cbmQwBeJjQCn5Ij3iXpuJOFeUU/H+HVaeGb4LtH1wBhovSvkbkg OIgom0/Y7fqdnIc1g18dDtmMX5SuopUIoljp6OWo9dhR1rrs/BdrKMm2vUMn3rE+UIwt aFL/Cdh6lvERBJFq3zQCJJY1emLjbj9olsAxGbU8TKNJowiJrTLNwyPB2NFDz8ru7MR6 T4GjO4ks07UrbjfJKySEBGCMGLQC53PVy6Lpm7oL02PRsU5pB+y91gxDxmeYyjlcggGJ tnaJFwVUdB9+rI6Yn5CXbsDos2UsjbgVg4PVNwC4KtiAN4uwooqKSv/dIsvW4C4PUTcp 8OLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=3MCeGsv7mG7So4MX4L7OswL3L/F+D7RQ+0TvRLAMh2M=; b=Nrm4QQlO3Gjp4rryIVXK01FaHrcyArQey3Hhkj90UjzVJGRDw7M2Q5vBqsx3Jlqnm6 C71qLA83T8ifbpPyj46f6b9FSa8ytKntHfnL4nxz8IgMEHfl0sSrgg0ZBDYpYn1hYpsU 2WmsvM0nxHZPo7WfFadoK4gTJ0p59HhKE3eID/dYiYNjr8niwZMyiNME5XXtW80zBWjf celeTYLcBptj6q35AjG8CS+WG7z0UguZQY61SlXcvUJ/HloXS8kScoDV1uQQFfugwq4X eUhlwfKqtyYfcsiIPYu8svxXdKnh0gG3i8Fa69hEuawu+oaw+QlGyLNmreFjDlPLyRAi czKA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i10si24489528ejd.137.2021.04.08.05.16.34; Thu, 08 Apr 2021 05:16:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231239AbhDHMPw (ORCPT + 99 others); Thu, 8 Apr 2021 08:15:52 -0400 Received: from verein.lst.de ([213.95.11.211]:35078 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229921AbhDHMPv (ORCPT ); Thu, 8 Apr 2021 08:15:51 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id B70EE68B05; Thu, 8 Apr 2021 14:15:38 +0200 (CEST) Date: Thu, 8 Apr 2021 14:15:38 +0200 From: Christoph Hellwig To: Javier =?iso-8859-1?Q?Gonz=E1lez?= Cc: Christoph Hellwig , Keith Busch , Dmitry Monakhov , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, Chaitanya.Kulkarni@wdc.com Subject: Re: [PATCH 1/1] nvme-pci: add the DISABLE_WRITE_ZEROES quirk for a Samsung PM1725a Message-ID: <20210408121538.GA12948@lst.de> References: <1615377076-3251-1-git-send-email-dmtrmonakhov@yandex-team.ru> <20210310132156.GA12145@lst.de> <20210310134110.GA13063@lst.de> <20210310200030.GA3377333@dhcp-10-100-145-180.wdc.com> <20210311104712.GA16218@lst.de> <20210323083749.r272grolxozf3w2f@mpHalley.local> <20210323123121.GA31105@lst.de> <20210323124322.qchyk7boyzklwv3v@mpHalley.local> <20210408103016.5girhv5ctkucovmd@mpHalley.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210408103016.5girhv5ctkucovmd@mpHalley.local> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 08, 2021 at 12:30:16PM +0200, Javier Gonz?lez wrote: >>> Aligning to MDTS is our current behavior, although all kernels up to >>> 5.11 had a bug in the calculation. >> >> I see. Let me check internally and see what's going on with >> write-zeroes on this model. > > We still need to confirm, but it seems like MDTS for write-zeroes is > reported wrong in the FW that Dmitry is using. We can at least reproduce > it. > > Would it be a possibility to add quirk infrastructure to hardcode MDTS > for FW versions prior TP4040? > > Another possibility is to add quirks to the TP4040 support patches to > enable this - it might also help reduce the list of models currently > blacklisted for write-zeroes. I'm not sure I understand you. Before TP4040 there is only the MDTS, which only applies to data transfer commands, although we also "volunarily" apply it to Write Zeroes. If MDTS is wrong this would also affect normal I/O, so we really either need a firmware update or a quirk. Or is the Write Zeroes limit even smaller than MTDS? I'd rather not add another quirk with a specific limit in that case, as well grow way too many of those. TP4040 is the way to go for that case.