On Wed, Apr 8, 2015 at 10:17 PM, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 2015-04-08 at 17:06 -0700, Yinghai Lu wrote: >> On Wed, Apr 8, 2015 at 2:12 PM, Benjamin Herrenschmidt >> <benh@xxxxxxxxxxxxxxxxxxx> 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-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
