| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 24 May 2007 21:43:22 +0900
From: Tomohiro Kusumi <kusumi.tomohiro@...fujitsu.com>
To: "Kok, Auke" <sofar@...-projects.org>
Cc: "Kok, Auke" <auke-jan.h.kok@...el.com>, cramerj@...el.com,
john.ronciak@...el.com, jesse.brandeburg@...el.com,
jeffrey.t.kirsher@...el.com, gregkh@...e.de,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI legacy I/O port free driver - Making Intel e1000
driver legacy I/O port free
Dear Auke
I'm sorry for being so late. Let me answer your questions.
> 82545's:
> 82545EM_COPPER
> 82545EM_FIBER
> Here you skip 3 other 82545 device ID's, was that intentional?
Maybe my understanding on the e1000 driver was wrong. I looked up the
following code, and thought the device IDs whose chipset are 82545 rev3
do not use I/O port. That's why I only put the first two device IDs on the
USE_IOPORT list I submitted previously.
> 82546's:
> 82546EB_COPPER
> 82546EB_FIBER
> 82546EB_QUAD_COPPER
> Here you skip over 9 82546 device ID's... same question.
Same answer for the 82546. From the following code, I thought the device
IDs whose chipset are 82546 rev3 do not use I/O port.
> Do you think you can accomodate these changes?
Yes I'll try it. But before I accomodate those changes, could you just tell
me which device IDs I should use for this function?
You said 82540, 82541, 82544 are okay, and I'm gonna add those 3 IDs for
82545, and 6 IDs for 82546. Are there any other IDs that I'm missing?
Thanks
Tomohiro Kusumi
drivers/net/e1000/e1000_hw.c
303 /******************************************************************************
304 * Set the mac type member in the hw struct.
305 *
306 * hw - Struct containing variables accessed by shared code
307 *****************************************************************************/
308 int32_t
309 e1000_set_mac_type(struct e1000_hw *hw)
310 {
...
344 case E1000_DEV_ID_82545EM_COPPER:
345 case E1000_DEV_ID_82545EM_FIBER:
346 hw->mac_type = e1000_82545;
347 break;
348 case E1000_DEV_ID_82545GM_COPPER: /* skipped */
349 case E1000_DEV_ID_82545GM_FIBER: /* skipped */
350 case E1000_DEV_ID_82545GM_SERDES: /* skipped */
351 hw->mac_type = e1000_82545_rev_3;
352 break;
353 case E1000_DEV_ID_82546EB_COPPER:
354 case E1000_DEV_ID_82546EB_FIBER:
355 case E1000_DEV_ID_82546EB_QUAD_COPPER:
356 hw->mac_type = e1000_82546;
357 break;
358 case E1000_DEV_ID_82546GB_COPPER: /* skipped */
359 case E1000_DEV_ID_82546GB_FIBER: /* skipped */
360 case E1000_DEV_ID_82546GB_SERDES: /* skipped */
361 case E1000_DEV_ID_82546GB_PCIE: /* skipped */
362 case E1000_DEV_ID_82546GB_QUAD_COPPER: /* skipped */
363 case E1000_DEV_ID_82546GB_QUAD_COPPER_KSP3: /* skipped */
364 hw->mac_type = e1000_82546_rev_3;
365 break;
drivers/net/e1000/e1000_hw.c
519 /******************************************************************************
520 * Reset the transmit and receive units; mask and clear all interrupts.
521 *
522 * hw - Struct containing variables accessed by shared code
523 *****************************************************************************/
524 int32_t
525 e1000_reset_hw(struct e1000_hw *hw)
526 {
...
618 switch (hw->mac_type) {
619 case e1000_82544:
620 case e1000_82540:
621 case e1000_82545:
622 case e1000_82546:
623 case e1000_82541:
624 case e1000_82541_rev_2:
625 /* These controllers can't ack the 64-bit write when issuing the
626 * reset, so use IO-mapping as a workaround to issue the reset */
627 E1000_WRITE_REG_IO(hw, CTRL, (ctrl | E1000_CTRL_RST));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/* Are these the ones using the I/O port? */
628 break;
629 case e1000_82545_rev_3:
630 case e1000_82546_rev_3:
631 /* Reset is performed on a shadow of the control register */
632 E1000_WRITE_REG(hw, CTRL_DUP, (ctrl | E1000_CTRL_RST));
633 break;
drivers/net/e1000/e1000_hw.h
451 #define E1000_DEV_ID_82545EM_COPPER 0x100F
452 #define E1000_DEV_ID_82545EM_FIBER 0x1011
453 #define E1000_DEV_ID_82545GM_COPPER 0x1026
454 #define E1000_DEV_ID_82545GM_FIBER 0x1027
455 #define E1000_DEV_ID_82545GM_SERDES 0x1028
456 #define E1000_DEV_ID_82546EB_COPPER 0x1010
457 #define E1000_DEV_ID_82546EB_FIBER 0x1012
458 #define E1000_DEV_ID_82546EB_QUAD_COPPER 0x101D
...
467 #define E1000_DEV_ID_82546GB_COPPER 0x1079
468 #define E1000_DEV_ID_82546GB_FIBER 0x107A
469 #define E1000_DEV_ID_82546GB_SERDES 0x107B
470 #define E1000_DEV_ID_82546GB_PCIE 0x108A
471 #define E1000_DEV_ID_82546GB_QUAD_COPPER 0x1099
...
486 #define E1000_DEV_ID_82546GB_QUAD_COPPER_KSP3 0x10B5
Kok, Auke wrote:
> Kok, Auke wrote:
>> Tomohiro Kusumi wrote:
>>> Dear Auke
>>>
>>> > I'm ok with the bottom part of the patch, but I do not like
>>> > the modification of the pci device ID table in this way. As
>>> > Arjan van der Ven previously commented as well, this makes
>>> > it hard for future device ID's to be bound to the driver.
>>>
>>> I googled the previous comment by Arjan. Now I understand
>>> that the patch makes it difficult to add PCI ID's to the
>>> driver at runtime.
>>>
>>> > On top of that, there is no logical correlation between the
>>> > mapping and chipsets, so a lot of information is lost in that
>>> > table. It really does not show which _chipsets_ support this
>>> > functionality.
>>>
>>> Thanks for pointing out the problem, but I can't quite understand
>>> what you are trying to say. What do you mean by the chipset?
>>> Are you talking about the chipset of the NIC? or the South bridge?
>>> I'd be glad if you can explain it to me.
>>
>> perhaps my wording was poor. I was referring to the NIC chip. Since
>> there are about 12 different physical e1000 NIC chips (and lots of
>> different pci IDs per e1000 NIC chip), it would be best to correlate
>> the capability of each NIC chip number to be able to work without
>> legacy IO mode instead of providing this mapping based on the PCI
>> device ID.
>>
>> It would serve two purposes: new pci id's for a chipset of which we
>> already know that it can work without legacy IO can automatically
>> inherit this property from the NIC chipset properties, and new e1000
>> chips would automatically get a default property for this value.
>>
>> I will (time permitting) try to reverse your matrix to chip numbers
>> and see if we can add this property in a much easier way.
>
> Okay, you appear to enable io for the following chipsets:
>
> 82540 chips:
> 82540EM
> 82540EM_LOM
> 82540EP
> 82540EP_LOM
> 82540EP_LP
> those are all the 82540's, OK
>
> 82541 chips:
> 82541EI
> 82541EI_MOBILE
> 82541ER
> 82541ER_LOM
> 82541GI
> 82541GI_LF
> 82541GI_MOBILE
> Those are all the 82541's, OK too
>
> 82544 chips:
> 82544EI_COPPER
> 82544EI_FIBER
> 82544GC_COPPER
> 82544GC_LOM
> Those are all the 82543's, OK too
>
> 82545's:
> 82545EM_COPPER
> 82545EM_FIBER
> Here you skip 3 other 82545 device ID's, was that intentional?
>
> 82546's:
> 82546EB_COPPER
> 82546EB_FIBER
> 82546EB_QUAD_COPPER
> Here you skip over 9 82546 device ID's... same question.
>
> It appears that probably the 82543's would also work under ioport, 82547
> might be the odd one out that might work without IOport. I think 82542
> definately needs it...
>
> can you tell me how you created the initial list?
>
> Summarizing, it appears that we should condense the list to: (sketch)
>
> switch (adapter->hw.mac.type) {
> case e1000_82542 ... e1000_82541_rev_2:
> adapter->ioport_capable = 1;
> break;
> default:
> break;
> }
>
> I also would like this option to be non-default, IOW use legacy IO by
> default, and allow the user to specify a module load option to disable
> use of this feature:
>
> static unsigned int use_ioport = 1;
> module_param(use_ioport, uint, 0644);
> MODULE_PARM_DESC(use_ioport, "Use Legacy IO port mapping (default: 1)");
>
> or something like this to allow the feature to be tested before we turn
> legacy ioport off for all adapters and everyone.
>
> Do you think you can accomodate these changes?
>
> Cheers,
>
> Auke
>
>
>
>
>>
>> Auke
>>
>>> Tomohiro Kusumi
>>>
>>>
>>> Kok, Auke wrote:
>>>> Tomohiro Kusumi wrote:
>>>>> Hi
>>>>>
>>>>> As you can see in the "10. pci_enable_device_bars() and Legacy I/O
>>>>> Port space" of the Documentation/pci.txt, the latest kernel has
>>>>> interfaces for PCI device drivers to tell the kernel which resource
>>>>> the driver want to use, ex. I/O port or MMIO.
>>>>>
>>>>> I've made a patch which makes Intel e1000 driver legacy I/O port
>>>>> free by using the PCI core changes I mentioned above. The Intel
>>>>> e1000 driver can handle some of its devices without using I/O port.
>>>>> So this patch changes the driver not to enable/request I/O port
>>>>> region depending on the device id.
>>>>>
>>>>> As a result, the driver can handle its device even when there are
>>>>> huge number of PCI devices being used on the system and no I/O
>>>>> port region assigned to the device.
>>>> Tomohiro,
>>>>
>>>> I'm ok with the bottom part of the patch, but I do not like the
>>>> modification of the pci device ID table in this way. As Arjan van
>>>> der Ven previously commented as well, this makes it hard for future
>>>> device ID's to be bound to the driver.
>>>>
>>>> On top of that, there is no logical correlation between the mapping
>>>> and chipsets, so a lot of information is lost in that table. It
>>>> really does not show which _chipsets_ support this functionality.
>>>>
>>>> I think if we want to work with this, we need some way of mapping
>>>> the device ID's back to chipsets, and enable the feature on that basis.
>>>>
>>>> Auke
>>>>
>>>>> Tomohiro Kusumi
>>>>>
>>>>> Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@...fujitsu.com>
>>>>>
>>>>> ---
>>>>> e1000.h | 6 +-
>>>>> e1000_main.c | 152
>>>>> +++++++++++++++++++++++++++++++----------------------------
>>>>> 2 files changed, 86 insertions(+), 72 deletions(-)
>>>>>
>>>>> diff -uprN linux-2.6.21.orig/drivers/net/e1000/e1000.h
>>>>> linux-2.6.21/drivers/net/e1000/e1000.h
>>>>> --- linux-2.6.21.orig/drivers/net/e1000/e1000.h 2007-05-09
>>>>> 18:02:26.000000000 +0900
>>>>> +++ linux-2.6.21/drivers/net/e1000/e1000.h 2007-05-09
>>>>> 18:02:59.000000000 +0900
>>>>> @@ -74,8 +74,9 @@
>>>>> #define BAR_1 1
>>>>> #define BAR_5 5
>>>>>
>>>>> -#define INTEL_E1000_ETHERNET_DEVICE(device_id) {\
>>>>> - PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
>>>>> +#define E1000_USE_IOPORT (1 << 0)
>>>>> +#define INTEL_E1000_ETHERNET_DEVICE(device_id, flags) {\
>>>>> + PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id), .driver_data =
>>>>> flags}
>>>>>
>>>>> struct e1000_adapter;
>>>>>
>>>>> @@ -347,6 +348,7 @@ struct e1000_adapter {
>>>>> boolean_t quad_port_a;
>>>>> unsigned long flags;
>>>>> uint32_t eeprom_wol;
>>>>> + int bars; /* BARs to be enabled */
>>>>> };
>>>>>
>>>>> enum e1000_state_t {
>>>>> diff -uprN linux-2.6.21.orig/drivers/net/e1000/e1000_main.c
>>>>> linux-2.6.21/drivers/net/e1000/e1000_main.c
>>>>> --- linux-2.6.21.orig/drivers/net/e1000/e1000_main.c 2007-05-09
>>>>> 18:02:27.000000000 +0900
>>>>> +++ linux-2.6.21/drivers/net/e1000/e1000_main.c 2007-05-09
>>>>> 18:03:00.000000000 +0900
>>>>> @@ -48,65 +48,65 @@ static char e1000_copyright[] = "Copyrig
>>>>> * {PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
>>>>> */
>>>>> static struct pci_device_id e1000_pci_tbl[] = {
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1000),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1001),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1004),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1008),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1009),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x100C),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x100D),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x100E),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x100F),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1010),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1011),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1012),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1013),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1014),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1015),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1016),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1017),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1018),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1019),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x101A),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x101D),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x101E),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1026),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1027),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1028),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1049),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x104A),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x104B),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x104C),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x104D),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x105E),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x105F),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1060),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1075),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1076),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1077),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1078),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1079),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x107A),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x107B),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x107C),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x107D),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x107E),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x107F),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x108A),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x108B),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x108C),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1096),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1098),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x1099),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x109A),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x10A4),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x10B5),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x10B9),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x10BA),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x10BB),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x10BC),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x10C4),
>>>>> - INTEL_E1000_ETHERNET_DEVICE(0x10C5),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1000, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1001, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1004, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1008, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1009, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x100C, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x100D, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x100E, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x100F, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1010, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1011, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1012, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1013, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1014, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1015, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1016, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1017, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1018, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1019, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x101A, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x101D, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x101E, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1026, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1027, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1028, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1049, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x104A, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x104B, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x104C, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x104D, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x105E, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x105F, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1060, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1075, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1076, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1077, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1078, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1079, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x107A, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x107B, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x107C, E1000_USE_IOPORT),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x107D, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x107E, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x107F, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x108A, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x108B, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x108C, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1096, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1098, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x1099, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x109A, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x10A4, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x10B5, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x10B9, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x10BA, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x10BB, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x10BC, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x10C4, 0),
>>>>> + INTEL_E1000_ETHERNET_DEVICE(0x10C5, 0),
>>>>> /* required last entry */
>>>>> {0,}
>>>>> };
>>>>> @@ -879,7 +879,14 @@ e1000_probe(struct pci_dev *pdev,
>>>>> int i, err, pci_using_dac;
>>>>> uint16_t eeprom_data = 0;
>>>>> uint16_t eeprom_apme_mask = E1000_EEPROM_APME;
>>>>> - if ((err = pci_enable_device(pdev)))
>>>>> + int bars;
>>>>> +
>>>>> + if (ent->driver_data & E1000_USE_IOPORT)
>>>>> + bars = pci_select_bars(pdev, IORESOURCE_MEM | IORESOURCE_IO);
>>>>> + else
>>>>> + bars = pci_select_bars(pdev, IORESOURCE_MEM);
>>>>> +
>>>>> + if ((err = pci_enable_device_bars(pdev, bars)))
>>>>> return err;
>>>>>
>>>>> if (!(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK)) &&
>>>>> @@ -894,7 +901,8 @@ e1000_probe(struct pci_dev *pdev,
>>>>> pci_using_dac = 0;
>>>>> }
>>>>>
>>>>> - if ((err = pci_request_regions(pdev, e1000_driver_name)))
>>>>> + err = pci_request_selected_regions(pdev, bars,
>>>>> e1000_driver_name);
>>>>> + if (err)
>>>>> goto err_pci_reg;
>>>>>
>>>>> pci_set_master(pdev);
>>>>> @@ -913,6 +921,7 @@ e1000_probe(struct pci_dev *pdev,
>>>>> adapter->pdev = pdev;
>>>>> adapter->hw.back = adapter;
>>>>> adapter->msg_enable = (1 << debug) - 1;
>>>>> + adapter->bars = bars;
>>>>>
>>>>> mmio_start = pci_resource_start(pdev, BAR_0);
>>>>> mmio_len = pci_resource_len(pdev, BAR_0);
>>>>> @@ -922,12 +931,15 @@ e1000_probe(struct pci_dev *pdev,
>>>>> if (!adapter->hw.hw_addr)
>>>>> goto err_ioremap;
>>>>>
>>>>> - for (i = BAR_1; i <= BAR_5; i++) {
>>>>> - if (pci_resource_len(pdev, i) == 0)
>>>>> - continue;
>>>>> - if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
>>>>> - adapter->hw.io_base = pci_resource_start(pdev, i);
>>>>> - break;
>>>>> + if (ent->driver_data & E1000_USE_IOPORT) {
>>>>> + for (i = BAR_1; i <= BAR_5; i++) {
>>>>> + if (pci_resource_len(pdev, i) == 0)
>>>>> + continue;
>>>>> + if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
>>>>> + adapter->hw.io_base =
>>>>> + pci_resource_start(pdev, i);
>>>>> + break;
>>>>> + }
>>>>> }
>>>>> }
>>>>>
>>>>> @@ -1190,7 +1202,7 @@ err_sw_init:
>>>>> err_ioremap:
>>>>> free_netdev(netdev);
>>>>> err_alloc_etherdev:
>>>>> - pci_release_regions(pdev);
>>>>> + pci_release_selected_regions(pdev, bars);
>>>>> err_pci_reg:
>>>>> err_dma:
>>>>> pci_disable_device(pdev);
>>>>> @@ -1242,7 +1254,7 @@ e1000_remove(struct pci_dev *pdev)
>>>>> iounmap(adapter->hw.hw_addr);
>>>>> if (adapter->hw.flash_address)
>>>>> iounmap(adapter->hw.flash_address);
>>>>> - pci_release_regions(pdev);
>>>>> + pci_release_selected_regions(pdev, adapter->bars);
>>>>>
>>>>> free_netdev(netdev);
>>>>>
>>>>> @@ -5172,7 +5184,7 @@ e1000_resume(struct pci_dev *pdev)
>>>>>
>>>>> pci_set_power_state(pdev, PCI_D0);
>>>>> pci_restore_state(pdev);
>>>>> - if ((err = pci_enable_device(pdev))) {
>>>>> + if ((err = pci_enable_device_bars(pdev, adapter->bars))) {
>>>>> printk(KERN_ERR "e1000: Cannot enable PCI device from
>>>>> suspend\n");
>>>>> return err;
>>>>> }
>> -
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists