> From: Bjorn Helgaas [mailto:bhelgaas@xxxxxxxxxx] > Sent: Friday, January 31, 2014 9:59 AM > To: Brown, Aaron F > Cc: linux-pci@xxxxxxxxxxxxxxx; e1000-devel@xxxxxxxxxxxxxxxxxxxxx; Arjan > van de Ven; linux-kernel@xxxxxxxxxxxxxxx > Subject: Re: [E1000-devel] [PATCH 0/2] Remove dead code > > On Fri, Jan 31, 2014 at 2:10 AM, Brown, Aaron F <aaron.f.brown@xxxxxxxxx> > wrote: > >> From: Bjorn Helgaas [mailto:bhelgaas@xxxxxxxxxx] > >> Sent: Thursday, January 30, 2014 11:21 AM > >> To: linux-pci@xxxxxxxxxxxxxxx > >> Cc: e1000-devel@xxxxxxxxxxxxxxxxxxxxx; Arjan van de Ven; linux- > >> kernel@xxxxxxxxxxxxxxx > >> Subject: [E1000-devel] [PATCH 0/2] Remove dead code > >> > >> This is a rework of part of Stephen's patch [1]. > >> > >> This removes the MMIO exclusivity support that was added as part of > >> an e1000e bug hunt. > >> > >> The e1000e driver still uses > >> pci_request_selected_regions_exclusive(), but there are no callers of > >> pci_request_region_exclusive() and pci_request_regions_exclusive(). > >> I thought it was cleaner to remove the whole thing than to leave > >> parts of it in place. But I could easily be convinced to leave part > >> or all of this in place if people think it's still useful. > > > > Thanks Bjorn, I have added these to Jeff's queue. > > Let's wait for a bit more discussion on this. > > For one thing, Fengguang's autobuilder found a handful of issues, > including a couple more users of the exclusive mappings. For another, > Arjan reminded me that the e1000e bug hung was for a problem that bricked > the device, requiring replacement of the part or significant effort to fix > the EEPROM. I *suspect* this is a potential issue for many devices, but > if the e1000e is particularly susceptible for some reason, we might want > to keep the exclusive mappings for it. > > If you want to apply just the e1000e part that removes its use of > pci_request_selected_regions_exclusive(), I would have no complaints about > that, of course. Yes, that was my main intent. I did pull them both in but the second was more as a heads up to our virtualization guys then as a request to test. > But we can't apply the whole thing as-is without at > least fixing the build issues. Thanks for the heads up on that. I'll sort out something that builds with the e1000e parts removed on my end. > > >> It also removes SR-IOV migration support, which is completely unused, > >> as far as I can tell. > >> > >> [1] > >> http://lkml.kernel.org/r/20131227132710.7190647c@nehalam.linuxnetplum > >> ber.n > >> et > >> > >> --- > >> > >> Bjorn Helgaas (2): > >> PCI: Remove unused MMIO exclusivity support > >> PCI: Remove unused SR-IOV VF Migration support > >> > >> > >> Documentation/PCI/pci-iov-howto.txt | 4 - > >> Documentation/kernel-parameters.txt | 4 - > >> arch/x86/mm/init.c | 2 > >> drivers/net/ethernet/intel/e1000e/netdev.c | 3 - > >> drivers/pci/iov.c | 119 -------------------- > --- > >> ----- > >> drivers/pci/pci-sysfs.c | 3 - > >> drivers/pci/pci.c | 112 +++----------------- > --- > >> --- > >> drivers/pci/pci.h | 4 - > >> include/linux/ioport.h | 5 - > >> include/linux/pci.h | 7 -- > >> kernel/resource.c | 54 ------------- > >> 11 files changed, 14 insertions(+), 303 deletions(-) > >> > >> --------------------------------------------------------------------- > >> ----- > >> ---- > >> WatchGuard Dimension instantly turns raw network data into actionable > >> security intelligence. It gives you real-time visual feedback on key > >> security issues and trends. Skip the complicated setup - simply > >> import a virtual appliance and go from zero to informed in seconds. > >> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg > >> .clkt > >> rk > >> _______________________________________________ > >> E1000-devel mailing list > >> E1000-devel@xxxxxxxxxxxxxxxxxxxxx > >> https://lists.sourceforge.net/lists/listinfo/e1000-devel > >> To learn more about Intel® Ethernet, visit > >> http://communities.intel.com/community/wired ��.n��������+%������w��{.n�����{���"�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
