Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751560AbbDIE1O (ORCPT ); Thu, 9 Apr 2015 00:27:14 -0400 Received: from mail-qk0-f177.google.com ([209.85.220.177]:35755 "EHLO mail-qk0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751070AbbDIE1L (ORCPT ); Thu, 9 Apr 2015 00:27:11 -0400 MIME-Version: 1.0 In-Reply-To: <1428549459.18187.56.camel@kernel.crashing.org> References: <1427857069-6789-1-git-send-email-yinghai@kernel.org> <1427857069-6789-4-git-send-email-yinghai@kernel.org> <20150406220638.GH10892@google.com> <20150406.203533.1356187749826485194.davem@davemloft.net> <20150408154759.GN10892@google.com> <1428527527.18187.28.camel@kernel.crashing.org> <1428549459.18187.56.camel@kernel.crashing.org> From: Bjorn Helgaas Date: Wed, 8 Apr 2015 23:26:50 -0500 Message-ID: Subject: Re: [PATCH 3/3] PCI: Set pref for mem64 resource of pcie device To: Benjamin Herrenschmidt Cc: Yinghai Lu , David Miller , David Ahern , "linux-pci@vger.kernel.org" , "sparclinux@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1885 Lines: 41 On Wed, Apr 8, 2015 at 10:17 PM, Benjamin Herrenschmidt wrote: > On Wed, 2015-04-08 at 17:06 -0700, Yinghai Lu wrote: >> On Wed, Apr 8, 2015 at 2:12 PM, Benjamin Herrenschmidt >> wrote: >> >> > Thanks Bjorn. We can fix Yinghai patch for 4.2, it would be indeed handy >> > even for us to be able to support putting 64-bit NP BARs in prefetch >> > windows (For some SR-IOV adapters for example) too, but we need to do it >> > right. >> >> Please check if you are ok with attached. > > I'll let Bjorn be the final judge here but I am not fan of the way you > set/clear/set/clear the IORESOURCE_PREFETCH bit with > pci_set_pref_under_pref(). It's error prone and confusing, the code is > already barely readable as it is ... > > I would rather you replace those various masks compares with a helper > that does something like pci_resource_compatible(parent_res, child_res), > which has the logic to test. That or a helper that does something like > pci_calc_compatible_res_flags() which returns a "flags" that has > PREFETCH set, which you use in place of res->flags in the various > allocation path. I'm not planning to review this until after the merge window opens, but I took a quick glance, and I agree with Ben. I don't want to add a new IORESOURCE_ flag. I think a pci_resource_compatible() helper is a great idea. I am absolutely not in favor of "minimally intrusive" as a goal. "Minimally intrusive" sounds good but it is often used to justify clever hacks which end up being an anti-maintainer strategy in the long term. "Maximum readability" is what I'm looking for. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/