Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp2217530pxb; Mon, 23 Aug 2021 15:04:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxoxmiOczv5cRZd93ObkeiT6aEvzH68T8rR3PW++67gvYvjRkG3No4okMcKDzdpvHodCzGF X-Received: by 2002:a50:9a84:: with SMTP id p4mr2690512edb.189.1629756256094; Mon, 23 Aug 2021 15:04:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629756256; cv=none; d=google.com; s=arc-20160816; b=Y2YgDmB50Ooo3Cp6BE8l3SCALhVHK0HjCMms40Bs9/8xfS3E/OyMwNvYoXfNUPlbnr yB0rk2VNrNMOM98yXHlMc+mi8glZgzS4b3sSr4XkCXLCMQBZ6miAmrv+cIWtsHOOq8O6 RiW1WxK3zI5gcJ5rSTyFuupa/bVsFQHotzeG2BuACkZQt9F4IdrEyJVgU6lIFck11Xh+ i5CQCcJ2pA7Xfe+80wsVEOk2ge13y7VCfb4qKyH0y7iVo3r51/nbdZhXdvPCtLat03np SM3mPhnIyAyW1vJSleQnTDhK4vPySAfrAZ+KvQWW25HvpNqHHBqx6XQ5C4/nyk675rk3 MrSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:references:in-reply-to:user-agent:subject:cc:to:from :date; bh=yQX7/cNbqC/0x00dNIv/fq7UwJn0X4OW8eNFNzRhni4=; b=Q5CTdDlGU43Y0qpWI6OyMD4CfSZwZ/aIFJmnvrQV0NgdO9oJFZVpoOMyCqHSC5MOD/ KvWwp6rBNo0bRcltVRLUthfC4vA+Jj0g4wmjKhNz6FrkwJM6RQWBFOh/C8hyBXxlsxua 0OyocJAXj4H7a6kKTli1vzxLiC3WiXanSba5iHnA+0XRgJNzTUilcFQlnRoq8H2NCUn8 JClzh2JYtoDpYR/lf/AktMyO2vuXAWY+W+hesTgP80oarVqsIcv9cqN8orfT1KT1RKlg 4v2gkeq+O8qxm7Onokh8BVWimEaR708nZsHrC3744wtaGIdu5xf7/UlKtKwm8cTPsieW WAKQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x13si14466167edd.446.2021.08.23.15.03.53; Mon, 23 Aug 2021 15:04:16 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233045AbhHWWCy convert rfc822-to-8bit (ORCPT + 99 others); Mon, 23 Aug 2021 18:02:54 -0400 Received: from foss.arm.com ([217.140.110.172]:57484 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233042AbhHWWCx (ORCPT ); Mon, 23 Aug 2021 18:02:53 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4CA611042; Mon, 23 Aug 2021 15:02:10 -0700 (PDT) Received: from [127.0.0.1] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D198B3F766; Mon, 23 Aug 2021 15:02:09 -0700 (PDT) Date: Mon, 23 Aug 2021 23:02:05 +0100 From: Steven Price To: dri-devel@lists.freedesktop.org, Alyssa Rosenzweig CC: Alyssa Rosenzweig , Rob Herring , Tomeu Vizoso , David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org, Chris Morgan , stable@vger.kernel.org Subject: Re: [PATCH 3/3] drm/panfrost: Clamp lock region to Bifrost minimum User-Agent: K-9 Mail for Android In-Reply-To: References: <20210820213117.13050-1-alyssa.rosenzweig@collabora.com> <20210820213117.13050-4-alyssa.rosenzweig@collabora.com> <818b1a15-ddf4-461b-1d6a-cea539deaf76@arm.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23 August 2021 22:13:45 BST, Alyssa Rosenzweig wrote: >> > When locking a region, we currently clamp to a PAGE_SIZE as the minimum >> > lock region. While this is valid for Midgard, it is invalid for Bifrost, >> >> While the spec does seem to state it's invalid for Bifrost - kbase >> didn't bother with a lower clamp for a long time. I actually think this >> is in many ways more of a spec bug: i.e. implementation details of the >> round-up that the hardware does. But it's much safer following the spec >> ;) And it seems like kbase eventually caught up too. > >Yeah, makes sense. Should I drop the Cc: stable in that case? If the >issue is purely theoretical. I think it might still be worth fixing. Early Bifrost should be fine, but something triggered a bug report that caused kbase to be fixed, so I'm less confident that there's nothing out there that cares. Following both kbase and the spec seems the safest approach. Thanks, Steve