Received: by 10.223.176.5 with SMTP id f5csp1846907wra; Thu, 8 Feb 2018 04:34:07 -0800 (PST) X-Google-Smtp-Source: AH8x224SFRQX6gUzY+kEJbxt7qM7W6mkCHomJycHtOhZu/uvuPoL6AUOM3y9tylbFVGC8G5lTwKB X-Received: by 2002:a17:902:968d:: with SMTP id n13-v6mr526730plp.33.1518093247782; Thu, 08 Feb 2018 04:34:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518093247; cv=none; d=google.com; s=arc-20160816; b=zhiddHIA1XrQeBGIXLmlg7ToI3Oy8VRFmxQ4cs0YCm5BQAnTy3nKMDz7pH7+RBK2Lz DuFb+URSgJUtVkGYT4HyGQCLeohq0sK5MfoieT94hySfSCK7fGRY3H+dbEDNyL7ima7G Wchg1+4/WOiDR8PtgiOfDpfA9wM751KaFQV7B3hudZ0YHpzz64EM6t5Cn6PMYUHBuTtX 2TUkGQ/WFNHueMRpyoi6WiiuWhJIZZvDsvUFw1aTxQoLFxoVZ7y7fsFwqcQWetIJEHf4 3PKChagmSNxZZyLPooSpbLzWHTMowjB1ZnxRsmwsLO8bC3/NADfEx4JdSi55qVENFaqv wiqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=FHHWDyhVAzYLLKH4NeV3bWbHCTR8ObDmzO6rTQZ2Ob8=; b=P7tYND0RrQ6P0+CNWJBEFybW03S4hPjvADM6OEKPuo9zYbPTHDw0BCtLJOu6Kb0ftJ OQAUmwM25OtngHF5pjto3XQjOF+J39qQsgnl/lkj61IdxUUE32hgKHxV9xt2CB+etMa2 CmwP770wRVZ7SQAT6XYvXg1AeW9Kk4IOwu4rVD57+i3W2/1NxBjF33U3x0oN2lidoaEA l9eFepsqBZQDpz/3+ExMsVi53zqBy/QNo3iXNfnZVBUY4TWq30MrZRvQCDy32uk3rAws MticeBKQUr81eutnHolln5VKMDCm3OyPgYZdEzlEk9g4BBNIHOoR7Oo07fhfIjCeZ4DE ywLQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 20si1339471pfp.312.2018.02.08.04.33.54; Thu, 08 Feb 2018 04:34:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752092AbeBHMdH (ORCPT + 99 others); Thu, 8 Feb 2018 07:33:07 -0500 Received: from bastet.se.axis.com ([195.60.68.11]:48970 "EHLO bastet.se.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752026AbeBHMdF (ORCPT ); Thu, 8 Feb 2018 07:33:05 -0500 Received: from localhost (localhost [127.0.0.1]) by bastet.se.axis.com (Postfix) with ESMTP id 40A3D18897; Thu, 8 Feb 2018 13:33:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bastet.se.axis.com Received: from bastet.se.axis.com ([IPv6:::ffff:127.0.0.1]) by localhost (bastet.se.axis.com [::ffff:127.0.0.1]) (amavisd-new, port 10024) with LMTP id urCaWCJ0xPl5; Thu, 8 Feb 2018 13:33:02 +0100 (CET) Received: from boulder03.se.axis.com (boulder03.se.axis.com [10.0.8.17]) by bastet.se.axis.com (Postfix) with ESMTPS id 3959D1889D; Thu, 8 Feb 2018 13:33:02 +0100 (CET) Received: from boulder03.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1B85A1E077; Thu, 8 Feb 2018 13:33:02 +0100 (CET) Received: from boulder03.se.axis.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0F5801E076; Thu, 8 Feb 2018 13:33:02 +0100 (CET) Received: from seth.se.axis.com (unknown [10.0.2.172]) by boulder03.se.axis.com (Postfix) with ESMTP; Thu, 8 Feb 2018 13:33:02 +0100 (CET) Received: from lnxartpec1.se.axis.com (lnxartpec1.se.axis.com [10.88.4.10]) by seth.se.axis.com (Postfix) with ESMTP id 021D52D60; Thu, 8 Feb 2018 13:33:02 +0100 (CET) Received: by lnxartpec1.se.axis.com (Postfix, from userid 20283) id F0894401B8; Thu, 8 Feb 2018 13:33:01 +0100 (CET) Date: Thu, 8 Feb 2018 13:33:01 +0100 From: Niklas Cassel To: Andy Shevchenko Cc: Jingoo Han , Kishon Vijay Abraham I , Joao Pinto , Lorenzo Pieralisi , Bjorn Helgaas , linux-pci@vger.kernel.org, Linux Kernel Mailing List Subject: Re: [PATCH 3/3] PCI: designware-ep: Return an error when requesting a too large BAR size Message-ID: <20180208123301.GB9630@axis.com> References: <20180201161119.3852-1-niklas.cassel@axis.com> <20180201161119.3852-4-niklas.cassel@axis.com> <000601d39b8e$f58a76f0$e09f64d0$@gmail.com> <20180205162519.GA3044@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1+16 (8a41d1c2f267) (2017-09-22) X-TM-AS-GCONF: 00 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 06, 2018 at 09:38:09PM +0200, Andy Shevchenko wrote: > On Mon, Feb 5, 2018 at 6:25 PM, Niklas Cassel wrote: > > On Thu, Feb 01, 2018 at 02:00:40PM -0500, Jingoo Han wrote: > >> On Thursday, February 1, 2018 1:58 PM, Andy Shevchenko wrote: > >> > > >> > On Thu, Feb 1, 2018 at 6:11 PM, Niklas Cassel > >> > wrote: > >> > > >> > include/linux/sizes.h: > >> > > >> > +SZ_4G 0x100000000ULL > >> > > >> > > + if (size > 0x100000000ULL) { > >> > > >> > #include > >> > > >> > if (size > SZ_4G) { > >> > >> I like this one for the readability. > >> Thank you. > >> > > > > I liked it too, however both variants > > > > if (size > 0x100000000ULL) { > > > > if (size > SZ_4G) { > > > > result in: > > > > drivers/pci/dwc/pcie-designware-ep.c:131:11: warning: > > comparison is always false due to limited range of data type [-Wtype-limits] > > > > when compiling with W=1 on a platform with 32-bit size_t. > > > > > > The annoying thing here is that a BAR can be 64-bit, > > yet the parameter size is defined as a size_t, > > so the error will only show on 32-bit and not on 64-bit. > > Oh, indeed. And it looks moving to u64 or alike is not a solution > (because if would not describe real hardware in that case). > > > What do you think about: > > > if (upper_32_bits(size)) { > > dev_err(pci->dev, "can't handle BAR larger than 4GB\n"); > > return -EINVAL; > > } > > > > That should compile without warnings for both > > 32-bit size_t and 64-bit size_t. > > Can you derive some helper based on the code in __pci_read_base() code? Hello Andy, I guess that would be possible, however I think that simply checking upper_32_bits(size) is simpler. If someone is ever to fix dw_pcie_ep_set_bar() so that it works with 64-bit BARs, the function will probably need to check upper_32_bits(size) anyway. Regards, Niklas