From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5483BC433F5 for ; Thu, 18 Nov 2021 13:32:31 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 21D736140A for ; Thu, 18 Nov 2021 13:32:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 21D736140A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=V33kdig84yNLkOISjihglQl4R1ysqfPmXZgcBK9z1wE=; b=vT24pp0ulXDeut HqMdGRDcimP8oWdZ4hRWsXq1NXalS5lssDY9y/zohqHUUkQ9TpeqaNtzwpIm4VRuTtrZ6z3/PQ6Od lh4d0omrJCy9YoZLlXC9dlJ9Tn/jFxg3pWBwTcJCZpCtRBcbVxnBpXAHW+dRyBhnwFFPyl6GhTLDv +gKvDwbORZaX3uXz+yH0bDUDzAYVQNVH/4T5N2UkTSqBsM0Ilk1GgNIQaUgTCSN+wt4NKldQuwS9l 5wTgj55kgtJTKczfQD4bntk6uxbclcGSa7wOxZODYODkwELbnS13yoQUlboulJ5DJLPfnNe4VE2dF XFBfduFtwdBhTqUbAmIg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mnhVK-007vJY-4K; Thu, 18 Nov 2021 13:31:06 +0000 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mnhVC-007vHJ-J3; Thu, 18 Nov 2021 13:31:00 +0000 Received: by mail-pl1-x631.google.com with SMTP id v19so5242426plo.7; Thu, 18 Nov 2021 05:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Rri8CgMU3iUgw+czpevbWjMbr1UWm75xhAwXD02I6xU=; b=FDEnvL+UtpoLRk6Q1zJ5TWKgN3pkejoc+c1lfiUwMmvGmldi6KxwZO1grB8bUwgggl NxymJ9lCNeYeShRKPCEoAFb/qyeXIlHXW6H9LhjrDZVVUGNirPbyJuI24LirczSzl/Na OK380QfTTMyJLsiytjnQRYSmo9aAci9N0vFC8VP0JB29tQt8eoW/ggKIxCPmK5+dxsXW XwurEenZVOh5wEwUMaPPAASeHd9USOigFhhHFenuvMmC1EPdDlgUL2LZwm9an0CE8meS Rv6YcVKeQnHd4N1kacEKQoyflUzVHPAi/1nTgQ8d8eBhHJHyNrVBYPckBm/kGT11HH/L 8L/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Rri8CgMU3iUgw+czpevbWjMbr1UWm75xhAwXD02I6xU=; b=2aLDb7JiUmgJYhxoWjB/siG3rS9CpSXVlChTZ7Klytb54bODR58GX1wTsv5Gej/Pzn /pKIDJoYDrwWVyAU17AnuugESrlC+ek9ivlnqYDPtZOZ0/JniEHuFuGpSWGoZMM0OWne fmItbnct6VNuHJeoMPGV0q82K98rOQKAY/PO1lNDlRZ+AfENTriMMK5HXXTEWIRtg5ne NUnDz+AnfxCCTUqOmAV3xItP+rnoIhaUazPDEJRfbRoef/tLCOz70wZ7GaiCnExjv1xo W2UqD5njHiviqpVZAAcjO2PlI0SY6nV88RbkrXOH69yxSMJ1hWqLsD0j4jWiSRMghVFx jTbQ== X-Gm-Message-State: AOAM533Z4Fgaatjch6/MAd055fDIjZf8C2BxHIoLhwLDIfw6lgSS29OE fadrdvyWE3EHDIEVLkmy0fM= X-Google-Smtp-Source: ABdhPJw603nbU+O/fPHP8RoT4nn8P5boytORpwShOu3KLVJrVk3lFo3z0RQCNEqj18u5XFcu5Q1lpg== X-Received: by 2002:a17:90a:df14:: with SMTP id gp20mr10690696pjb.186.1637242256451; Thu, 18 Nov 2021 05:30:56 -0800 (PST) Received: from theprophet ([2406:7400:63:2c47:5ffe:fc34:61f0:f1ea]) by smtp.gmail.com with ESMTPSA id z19sm3624615pfe.181.2021.11.18.05.30.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Nov 2021 05:30:56 -0800 (PST) Date: Thu, 18 Nov 2021 19:00:20 +0530 From: Naveen Naidu To: Bjorn Helgaas Cc: bhelgaas@google.com, Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , linux-hyperv@vger.kernel.org, Heiko Stuebner , linux-pci@vger.kernel.org, Shawn Lin , Binghui Wang , Kuppuswamy Sathyanarayanan , Oliver O'Halloran , Thomas Petazzoni , Russell Currey , Lorenzo Pieralisi , Toan Le , "K. Y. Srinivasan" , Nirmal Patel , Marek Vasut , Rob Herring , Wei Liu , linux-samsung-soc@vger.kernel.org, Marc Zyngier , Joyce Ooi , Dexuan Cui , Jianjun Wang , linux-rockchip@lists.infradead.org, "maintainer:BROADCOM IPROC ARM ARCHITECTURE" , Jonathan Derrick , Xiaowei Song , linux-kernel-mentees@lists.linuxfoundation.org, Robert Richter , Sean V Kelley , Ray Jui , Haiyang Zhang , Ryder Lee , linux-mediatek@lists.infradead.org, Matthias Brugger , Stephen Hemminger , linux-arm-kernel@lists.infradead.org, Qiuxu Zhuo , Scott Branden , linuxppc-dev@lists.ozlabs.org, Yoshihiro Shimoda , Krzysztof Kozlowski , linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Lukas Wunner , Jingoo Han , Shawn Guo , Pali =?utf-8?B?Um9ow6Fy?= Subject: Re: [PATCH v3 01/25] PCI: Add PCI_ERROR_RESPONSE and it's related definitions Message-ID: <20211118133020.nkr3xzbzonxtrqbw@theprophet> References: <20211117235812.GA1786428@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211117235812.GA1786428@bhelgaas> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211118_053058_686170_E6AC3C72 X-CRM114-Status: GOOD ( 42.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 17/11, Bjorn Helgaas wrote: > On Thu, Oct 21, 2021 at 08:37:26PM +0530, Naveen Naidu wrote: > > An MMIO read from a PCI device that doesn't exist or doesn't respond > > causes a PCI error. There's no real data to return to satisfy the > > CPU read, so most hardware fabricates ~0 data. > > > > Add a PCI_ERROR_RESPONSE definition for that and use it where > > appropriate to make these checks consistent and easier to find. > > > > Also add helper definitions SET_PCI_ERROR_RESPONSE and > > RESPONSE_IS_PCI_ERROR to make the code more readable. > > > > Suggested-by: Bjorn Helgaas > > Signed-off-by: Naveen Naidu > > --- > > include/linux/pci.h | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/include/linux/pci.h b/include/linux/pci.h > > index cd8aa6fce204..689c8277c584 100644 > > --- a/include/linux/pci.h > > +++ b/include/linux/pci.h > > @@ -154,6 +154,15 @@ enum pci_interrupt_pin { > > /* The number of legacy PCI INTx interrupts */ > > #define PCI_NUM_INTX 4 > > > > +/* > > + * Reading from a device that doesn't respond typically returns ~0. A > > + * successful read from a device may also return ~0, so you need additional > > + * information to reliably identify errors. > > + */ > > +#define PCI_ERROR_RESPONSE (~0ULL) > > +#define SET_PCI_ERROR_RESPONSE(val) (*(val) = ((typeof(*(val))) PCI_ERROR_RESPONSE)) > > +#define RESPONSE_IS_PCI_ERROR(val) ((val) == ((typeof(val)) PCI_ERROR_RESPONSE)) > > Beautiful! I really like this. > Thank you very much for the review ^^ > I would prefer the macros to start with "PCI_", e.g., > PCI_SET_ERROR_RESPONSE(). > ACK > I think "RESPONSE_IS_PCI_ERROR()" is too strong because (as the > comment says), ~0 *may* indicate an error. Or it may be a successful > read of a register that happens to contain ~0. > > Possibilities to convey the idea that this isn't definitive: > > PCI_POSSIBLE_ERROR_RESPONSE(val) # a little long > PCI_LIKELY_ERROR(val) # we really have no idea whether > PCI_PROBABLE_ERROR(val) # likely or probable > PCI_POSSIBLE_ERROR(val) # promising? > ACK. Will use PCI_POSSIBLE_ERROR() > Can you rebase to my "main" branch (v5.16-rc1), tweak the above, and > collect up the acks/reviews? > ACK > We should also browse drivers outside drivers/pci for places we could > use these. Not necessarily as part of this series, although if > authors there object, it would be good to learn that earlier than > later. > > Drivers that implement pci_error_handlers might be a fruitful place to > start. But you've done a great job finding users of ~0 and 0xffff... > in drivers/pci/, too. > A quick grep showed that there are around 80 drivers which have pci_error_handlers. I was thinking that it would be better if we handle these drivers in another patch series since the current patch series is itself 25 patches long. And in my short tenure reading LKML, I gathered that folks generally are not so kind to a long list of patches in a single patch series ^^' (I might be wrong though, Apologies) The consensus on the patch series does seem slightly positive so ideally, I was hoping that we would not have the case where a author does not like the way we are handling this patch. Then again, I'm pretty sure that I might be wrong ^^' I hope it would be okay that I send in a new patch series with the suggested changes and handle the other changes in another patch series ^^ Thanks, Naveen > > + > > /* > > * pci_power_t values must match the bits in the Capabilities PME_Support > > * and Control/Status PowerState fields in the Power Management capability. > > -- > > 2.25.1 > > > > _______________________________________________ > > Linux-kernel-mentees mailing list > > Linux-kernel-mentees@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel