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 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FAKE_REPLY_C,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73EFDC34048 for ; Tue, 18 Feb 2020 17:32:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4EF382464E for ; Tue, 18 Feb 2020 17:32:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582047162; bh=Hs3mtj72oHAhcOKlb/lLWg8W10Q2iAludK8Rt699D0Q=; h=Date:From:To:Cc:Subject:In-Reply-To:List-ID:From; b=WI7y2ynz2TM8opn1rWdD+OAFc2lDV28u1ofcx6zbYWddZb5KTJDabcop62Npj7Nz5 tcFgTiP8mZlISsBmFkFNefF4WlcBLnhl0ihbYjdB9Y5VOKMbfWh8aoE4lcMXCdZFpI NkHDF8q2QyNjXKwoloBlRt5GjyGl+nTlBw8oJyPM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727211AbgBRRcl (ORCPT ); Tue, 18 Feb 2020 12:32:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:52838 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726638AbgBRRck (ORCPT ); Tue, 18 Feb 2020 12:32:40 -0500 Received: from localhost (odyssey.drury.edu [64.22.249.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B2B5722B48; Tue, 18 Feb 2020 17:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582047159; bh=Hs3mtj72oHAhcOKlb/lLWg8W10Q2iAludK8Rt699D0Q=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=G95I/cQmNoWVRms0Y9738Q8oz3LoDZYUNq/qzUgKtlrmu5Vm3WTg8ZsgX2BYkSp9l NOcXyrcLG2zO9NMErHWJ6iN/ns0DPFTf1cYAr1HH3Ma34GyILSvyqTOdjp1iqROUi0 tjOXB1tfyMeXfRPmgv5EQASLD+dBnTq8aNAEdNn0= Date: Tue, 18 Feb 2020 11:32:38 -0600 From: Bjorn Helgaas To: Lukas Wunner Cc: Stuart Hayes , Austin Bolen , keith.busch@intel.com, Alexandru Gagniuc , "Rafael J . Wysocki" , Mika Westerberg , Andy Shevchenko , "Gustavo A . R . Silva" , Sinan Kaya , Oza Pawandeep , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Libor Pechacek Subject: Re: [PATCH v4 0/3] PCI: pciehp: Do not turn off slot if presence comes up after link Message-ID: <20200218173238.GA214360@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200211143202.2sgryye4m234pymq@wunner.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 11, 2020 at 03:32:02PM +0100, Lukas Wunner wrote: > On Tue, Feb 11, 2020 at 08:14:44AM -0600, Bjorn Helgaas wrote: > > Feels like sort of a > > double-negative situation, too. Obviously the hardware bit has to be > > "1 means disabled" to be compatible with previous spec versions, but > > the code is usually easier to read if we test for something being > > *enabled*. > > It's a similar situation with the "DisINTx" bit in the Command > register, which, if disabled, is shown as "DisINTx-" in lspci even > though the more intuitive notion is that INTx is *enabled*. I think > you did the right thing by showing it as "IbPresDis-" because it's > consistent with how it's done elsewhere for similar bits. Everything else we decode is *capability* bits and IBPD is another one. So by the principle of least surprise, I propose this: + ctrl_info(ctrl, "Slot #%d AttnBtn%c PwrCtrl%c MRL%c AttnInd%c PwrInd%c HotPlug%c Surprise%c Interlock%c NoCompl%c IbPresDis%c LLActRep%c%s\n", + FLAG(slot_cap2, PCI_EXP_SLTCAP2_IBPD), That works out to be the same as printing inbound_presence_disabled ? '+' : '-' because we always set inbound_presence_disabled when PCI_EXP_SLTCAP2_IBPD is supported.