[Fwd: 2.4.0-test12-pre7]

[Fwd: 2.4.0-test12-pre7]

[Randy Dunlap]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

> From: Russell King [mailto:rmk@arm.linux.org.uk]
> 
> Linus Torvalds writes:
> >     - me: UHCI drivers really need to enable bus mastering.
> 
> But it'll already be turned on if pci_assign_unassigned_resources() is
> called.  This calls pdev_enable_device for every single device, which
> turns on the bus master bit in the PCI command register.
> 
> Is it intentional that pci_assign_unassigned_resources should:
> 1. enable all devices?
> 2. enable bus master on all devices?

Russell beat me to this question (must have something to do
with that .uk location).

I think that Linus's patch is correct and that
pci/setup_res.c::pdev_enable_device() shouldn't be doing this:

	/* ??? Always turn on bus mastering.  If the device doesn't support
	   it, the bit will go into the bucket. */
	cmd |= PCI_COMMAND_MASTER;

First, the ??? makes it iffy.

Second, if the device doesn't support it, OK, but if the device
does support bus mastering and the device has been programmed
from a previous kernel/driver bootup (i.e., the device isn't reset
by a soft boot), then the device still knows some memory addresses
to DMA into, but it shouldn't be using those.  This is addressed
in a Word .doc file at www.pcisig.com/developers/docs/ :
"Warm Boot on PCI Machines".  The short summary is that soft reset
should disable bus mastering and not re-enable it.
This doc says that device drivers (or expansion ROM code) are
responsible for setting the bus master bit.

Third, removing this will help find drivers that don't do
  pci_set_master() when they should (like UHCI HCDs).  :(

~Randy
-- 
_______________________________________________
|randy.dunlap_at_intel.com        503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
-----------------------------------------------

[-- Attachment #2: Type: message/rfc822, Size: 1103 bytes --]

To: Russell King <rmk@arm.linux.org.uk>, torvalds@transmeta.com
Cc: linux-kernel@vger.kernel.org
Subject: RE: 2.4.0-test12-pre7
Date: Thu, 7 Dec 2000 07:48:42 -0800
Message-ID: <D5E932F578EBD111AC3F00A0C96B1E6F063E0631@orsmsx31.jf.intel.com>

> From: Russell King [mailto:rmk@arm.linux.org.uk]
> 
> Linus Torvalds writes:
> >     - me: UHCI drivers really need to enable bus mastering.
> 
> But it'll already be turned on if pci_assign_unassigned_resources() is
> called.  This calls pdev_enable_device for every single device, which
> turns on the bus master bit in the PCI command register.
> 
> Is it intentional that pci_assign_unassigned_resources should:
> 1. enable all devices?
> 2. enable bus master on all devices?

Russell beat me to this question (must have something to do
with that .uk location).

I think that Linus's patch is correct and that
pci/setup_res.c::pdev_enable_device() shouldn't be doing this:

Re: [Fwd: 2.4.0-test12-pre7]

[Alan Cox]

> I think that Linus's patch is correct and that
> pci/setup_res.c::pdev_enable_device() shouldn't be doing this:
> 
> 	/* ??? Always turn on bus mastering.  If the device doesn't support
> 	   it, the bit will go into the bucket. */
> 	cmd |= PCI_COMMAND_MASTER;
> 
> First, the ??? makes it iffy.

I would agree. There is hardware you need to enable, reset, configure and
then enable the master bit on otherwise it simply starts spraying random
memory addresses with bus master transfers from uninitialised hardware
registers

> by a soft boot), then the device still knows some memory addresses
> to DMA into, but it shouldn't be using those.  This is addressed

Yep. Seen that happen with amd pcnet32 stuff when net booting. The net
booter left the chip prattling into main memory, not pretty

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/