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.
