Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp2187828pxb; Mon, 23 Aug 2021 14:13:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJybwdnHInVUP7r+l4MEsTg5eYQgNbuAA5MkYrGhcocxR4emf1+f50ezByg1za1cNysM6lcF X-Received: by 2002:a05:6402:10d6:: with SMTP id p22mr39064776edu.168.1629753194762; Mon, 23 Aug 2021 14:13:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629753194; cv=none; d=google.com; s=arc-20160816; b=Q9a9IswIcNjcQzdG8qCsj1ZgGPpfELyzKlA9WALMaWPlkVXck4yNiXQ6RwWjzfKkKd fLHKMUFV73riyygKNXQji4ShLU0jBZrpr5khBW9rBw9SFdU1s47j/bYyIhBy1QC0kfj9 5n9mC8h1VZ0O30wxq1poDg/pWVkRffNhBUAul3hfS159hFceAHWgDwoXLv/Rd6yT3bpg 7D8m9fTxpgLtQM+rYs5Ar99GDdnmKK/XaRFby4/NYFdjD0wiNRE+c1GQJzjHPVg3XOVZ JzmmH/bSqMogpFBQSTCRy3gklHrHzjcWuz2LBvznCqJKm3AN+7kZ68DlwQ0VbOTOC5S0 gAHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Eh3vYm3eLn8NcWUUW9yF7mFk/GMtLT60Z6dTNG0PJ+g=; b=vUrYsA7uqRDeacKxgo562MBliEkgupZHp8jHfVMwB5/7BJ3G3Io2qFrQTvR8/NPs3m P/dDnv1gkYagF5bUGEKYwa440ZmABmG3SMhqdqtEHAVS1PcegAfsMQCSrF9izoU3S2jo 2GuV5ACeIHix6xOszMVBYCHvZeLol/MvM2l7g/rSTtbr37NJuZ69Is2EHMQ6HQ2xnaYC j7/4pNF/U9sIehxn5RiVMMJaeKvZJx0JH3KwElf4jKNY9lIqEhi5iY/WcAmIeiKdBrJR UEjwMpqU+C4w4hQnA746LT5bngfqig4FpT69Ahuuhz0zwu5S+M9YTnNJPEIoLnQT471N cumQ== 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=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g22si4832404edr.172.2021.08.23.14.12.51; Mon, 23 Aug 2021 14:13:14 -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=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232713AbhHWVMD (ORCPT + 99 others); Mon, 23 Aug 2021 17:12:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232503AbhHWVMC (ORCPT ); Mon, 23 Aug 2021 17:12:02 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6BCCEC061575 for ; Mon, 23 Aug 2021 14:11:19 -0700 (PDT) Received: from maud (unknown [IPv6:2600:8800:8c06:1000::c8f3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: alyssa) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 4FC031F416C0; Mon, 23 Aug 2021 22:11:14 +0100 (BST) Date: Mon, 23 Aug 2021 17:11:09 -0400 From: Alyssa Rosenzweig To: Steven Price Cc: Alyssa Rosenzweig , dri-devel@lists.freedesktop.org, Rob Herring , Tomeu Vizoso , David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org, Chris Morgan Subject: Re: [PATCH 2/3] drm/panfrost: Use u64 for size in lock_region Message-ID: References: <20210820213117.13050-1-alyssa.rosenzweig@collabora.com> <20210820213117.13050-3-alyssa.rosenzweig@collabora.com> <71392001-a5a9-fee2-79a5-91df55ba3081@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71392001-a5a9-fee2-79a5-91df55ba3081@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure > > we can express the "lock everything" condition as ~0ULL without relying > > on platform-specific behaviour. > > 'platform-specific behaviour' makes it sound like this is something to > do with a particular board. This is 32bit/64bit - it's going to be > broken on 32bit: large lock regions are not going to work. Oh, my. I used the term as a weasel word since the spec is loose on how big a size_t actually is. But if this is causing actual breakage on armv7 we're in trouble. I'll add a Cc stable tag on v2, unless the Fixes implies that? Thanks for pointing this out.