From patchwork Fri May 16 06:28:23 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: colin@horizon.com X-Patchwork-Id: 4187711 Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 0E5C2BFF02 for ; Fri, 16 May 2014 06:28:40 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 57F8A202EB for ; Fri, 16 May 2014 06:28:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8C23F202E6 for ; Fri, 16 May 2014 06:28:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754725AbaEPG2Z (ORCPT ); Fri, 16 May 2014 02:28:25 -0400 Received: from ns.horizon.com ([71.41.210.147]:59755 "HELO ns.horizon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1754517AbaEPG2Z (ORCPT ); Fri, 16 May 2014 02:28:25 -0400 Received: (qmail 15106 invoked by uid 1000); 16 May 2014 02:28:23 -0400 Date: 16 May 2014 02:28:23 -0400 Message-ID: <20140516062823.15105.qmail@ns.horizon.com> From: colin@horizon.com To: alex.williamson@redhat.com, iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org Subject: Re: [PATCH v3 00/15] PCI/iommu: Fix DMA alias problems Cc: acooks@gmail.com, bhelgaas@google.com, linux-kernel@vger.kernel.org, linux@horizon.com In-Reply-To: <400175834.3289.65.camel@ul30vt.home> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Alex Williamson wrote: > Wow, I didn't think that kind of broken was possible. Maybe instead of > a bitmap of function aliases we could have a single devfn alias for a > device. That means we'd only be able to support a single alias for a > device, but since I don't think we've seen devices that use more than a > single alias, maybe that's ok. In my (never finished) patch set for the same problem, the first thing I did was I encoded "devfn_quirk" as a delta to devfn, so that zero would mean "no quirk", and no existing intialization would need changing. --- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/include/linux/pci.h b/include/linux/pci.h index a13d6825..7788870a 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -251,12 +251,13 @@ struct pci_dev { struct proc_dir_entry *procent; /* device entry in /proc/bus/pci */ struct pci_slot *slot; /* Physical slot this device is in */ - unsigned int devfn; /* encoded device & function index */ unsigned short vendor; unsigned short device; unsigned short subsystem_vendor; unsigned short subsystem_device; unsigned int class; /* 3 bytes: (base,sub,prog-if) */ + u8 devfn; /* encoded device & function index */ + u8 devfn_quirk; /* zero is non-quirky */ u8 revision; /* PCI revision, low byte of class word */ u8 hdr_type; /* PCI header type (`multi' flag masked out) */ u8 pcie_cap; /* PCIe capability offset */