linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: 2.4.2 yenta_socket problems on ThinkPad 240
@ 2001-06-15 23:14 Eric Smith
  2001-06-15 23:25 ` Jeff Garzik
  0 siblings, 1 reply; 15+ messages in thread
From: Eric Smith @ 2001-06-15 23:14 UTC (permalink / raw)
  To: linux-kernel

On 6-Jun-2001, I reported:
> I upgraded my IBM ThinkPad 240 (Type 2609-31U) from Red Hat 7.0 to
> Red Hat 7.1, which uses the 2.4.2 kernel and the kernel PCMCIA drivers.
> Before the upgrade, all my CardBus and PCMCIA devices were working fine.
> Now the yenta_socket module seems to be causing problems, and none of
> the cards work.

Arjan van de Ven of Red Hat tracked my problem down to a broken BIOS,
which is not configuring the TI PC1211 CardBus bridge correctly.  Even
IBM's latest BIOS for the ThinkPad 240, IRET75WW released 17-May-2001,
has this problem.  Apparently IBM has issued fixes for other ThinkPads
because the problem occurs with Windows 2000, but since Windows 2000 is
not supported on the ThinkPad 240, it is unlikely that they will fix it.

A one line change to linux/include/asm-i386/pci.h fixes it:

-#define pcibios_assign_all_busses()	0
+#define pcibios_assign_all_busses()	1

Given that this macro exists, I surmise that other people have been
bitten by similar problems.  So now my question is:

Does it make sense to turn pcibios_assign_all_busses into a variable
with a default value of zero, and implement a kernel argument to set it?
That way people with broken BIOSes could solve it by simply adding the
argument in their lilo.conf.  In an ideal world the BIOSes would get
fixed and such a workaround would be unnecessary, but in my experience
trying to get a vendor to fix a BIOS problem is an exercise in futility.

If no one is opposed to my proposed change, I'll be happy to generate a
suitable patch and send it in.

Thanks!
Eric Smith

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-15 23:14 2.4.2 yenta_socket problems on ThinkPad 240 Eric Smith
@ 2001-06-15 23:25 ` Jeff Garzik
  2001-06-16 13:25   ` Alan Cox
  2001-06-16 18:10   ` Linus Torvalds
  0 siblings, 2 replies; 15+ messages in thread
From: Jeff Garzik @ 2001-06-15 23:25 UTC (permalink / raw)
  To: Eric Smith; +Cc: linux-kernel, Linus Torvalds, Alan Cox, arjanv, mj

Eric Smith wrote:
> 
> On 6-Jun-2001, I reported:
> > I upgraded my IBM ThinkPad 240 (Type 2609-31U) from Red Hat 7.0 to
> > Red Hat 7.1, which uses the 2.4.2 kernel and the kernel PCMCIA drivers.
> > Before the upgrade, all my CardBus and PCMCIA devices were working fine.
> > Now the yenta_socket module seems to be causing problems, and none of
> > the cards work.
> 
> Arjan van de Ven of Red Hat tracked my problem down to a broken BIOS,
> which is not configuring the TI PC1211 CardBus bridge correctly.  Even
> IBM's latest BIOS for the ThinkPad 240, IRET75WW released 17-May-2001,
> has this problem.  Apparently IBM has issued fixes for other ThinkPads
> because the problem occurs with Windows 2000, but since Windows 2000 is
> not supported on the ThinkPad 240, it is unlikely that they will fix it.
> 
> A one line change to linux/include/asm-i386/pci.h fixes it:
> 
> -#define pcibios_assign_all_busses()    0
> +#define pcibios_assign_all_busses()    1
> 
> Given that this macro exists, I surmise that other people have been
> bitten by similar problems.  So now my question is:
> 
> Does it make sense to turn pcibios_assign_all_busses into a variable
> with a default value of zero, and implement a kernel argument to set it?

I believe Alan had mentioned something on IRC about seeing a case where
the CardBus bridge's secondary and subordinate bridge numbers were 1 on
bootup, but 0 after the yenta driver got ahold of it.  So, there is the
potential that the yenta driver is not setting things up quite
correctly.

To answer your question, I wouldn't mind at all having a kernel command
line setting that turned the above into a variable...

I would love to just define it unconditionally for x86, but I believe
Martin said that causes problems with some hardware, and the way the
BIOS has set up that hardware.  (details anyone?)

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-15 23:25 ` Jeff Garzik
@ 2001-06-16 13:25   ` Alan Cox
  2001-06-16 17:55     ` Jeff Garzik
  2001-06-17  4:03     ` Albert D. Cahalan
  2001-06-16 18:10   ` Linus Torvalds
  1 sibling, 2 replies; 15+ messages in thread
From: Alan Cox @ 2001-06-16 13:25 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Eric Smith, linux-kernel, Linus Torvalds, Alan Cox, arjanv, mj

> I would love to just define it unconditionally for x86, but I believe
> Martin said that causes problems with some hardware, and the way the
> BIOS has set up that hardware.  (details anyone?)

Im not sure unconditionally is wise. However turning it into a routine that
walks the PCI bus tree and returns 1 if  a duplicate is found seems to be
a little bit less likely to cause suprises

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-16 13:25   ` Alan Cox
@ 2001-06-16 17:55     ` Jeff Garzik
  2001-06-16 18:02       ` Alan Cox
  2001-06-16 18:16       ` Linus Torvalds
  2001-06-17  4:03     ` Albert D. Cahalan
  1 sibling, 2 replies; 15+ messages in thread
From: Jeff Garzik @ 2001-06-16 17:55 UTC (permalink / raw)
  To: Alan Cox; +Cc: Eric Smith, linux-kernel, Linus Torvalds, arjanv, mj

Alan Cox wrote:
> 
> > I would love to just define it unconditionally for x86, but I believe
> > Martin said that causes problems with some hardware, and the way the
> > BIOS has set up that hardware.  (details anyone?)
> 
> Im not sure unconditionally is wise. However turning it into a routine that
> walks the PCI bus tree and returns 1 if  a duplicate is found seems to be
> a little bit less likely to cause suprises

That would work, but is really a bandaid because we don't know what the
real problem is...  this still smells vaguely like yenta and pci bus
core should be more than just the kissing cousins they are now.  OTOH I
still don't like how much we trust firmware PCI bus setup on x86..

I am pretty lucky on Alpha, we already trust the kernel PCI code
implicitly by unconditionally defining pcibios_assign_all_busses to one.
:)

	Jeff


-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-16 17:55     ` Jeff Garzik
@ 2001-06-16 18:02       ` Alan Cox
  2001-06-16 18:15         ` Linus Torvalds
  2001-06-16 18:16       ` Linus Torvalds
  1 sibling, 1 reply; 15+ messages in thread
From: Alan Cox @ 2001-06-16 18:02 UTC (permalink / raw)
  To: Jeff Garzik
  Cc: Alan Cox, Eric Smith, linux-kernel, Linus Torvalds, arjanv, mj

> core should be more than just the kissing cousins they are now.  OTOH I
> still don't like how much we trust firmware PCI bus setup on x86..

The BIOS may make assumptions we dont know about such as the bus layout. What
minimises the problem is effectively to validate the firmware provided PCI
setup and if its crap, then do the job ourselves. That minimizes the problems

Hence I think it should not be a define but an __init validator for the bus
setup


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-15 23:25 ` Jeff Garzik
  2001-06-16 13:25   ` Alan Cox
@ 2001-06-16 18:10   ` Linus Torvalds
  2001-06-16 18:23     ` Alan Cox
  1 sibling, 1 reply; 15+ messages in thread
From: Linus Torvalds @ 2001-06-16 18:10 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: Eric Smith, linux-kernel, Alan Cox, arjanv, mj


On Fri, 15 Jun 2001, Jeff Garzik wrote:
> 
> I believe Alan had mentioned something on IRC about seeing a case where
> the CardBus bridge's secondary and subordinate bridge numbers were 1 on
> bootup, but 0 after the yenta driver got ahold of it.  So, there is the
> potential that the yenta driver is not setting things up quite
> correctly.

Cardbus shouldn't be touching the bus stuff at all, BUT there may be
strange hardware that doesn't like the following:

        config_writeb(socket, PCI_SEC_LATENCY_TIMER, 176); 
	config_writeb(socket, PCI_PRIMARY_BUS, dev->bus->number);
        config_writeb(socket, PCI_SECONDARY_BUS, dev->subordinate->number);
        config_writeb(socket, PCI_SUBORDINATE_BUS, dev->subordinate->number);

I have heard rumors of PCI devices that want all these set with a single
double-word write.

That's how drivers/pci/pci.c does it, and it kind of makes sense (setting
all bus details in one atomic go, so that there can be no question of how
the config space accesses get forwarded or what the bus routing is).

So it is probable that yenta _should_ do

	unsigned int buses =
		(latency << 24) |
		(subordinate << 16) |
		(secondary << 8) |
		primary;
	config_writel(socket, PCI_PRIMARY_BUS, buses);

although I believe that any device that gets this wrong is really broken,
as it just re-programs the old values (needed in case of a suspend event).

> To answer your question, I wouldn't mind at all having a kernel command
> line setting that turned the above into a variable...

Agreed. That would make sense regardless.

> I would love to just define it unconditionally for x86, but I believe
> Martin said that causes problems with some hardware, and the way the
> BIOS has set up that hardware.  (details anyone?)

One of the main problems we used to have was (and will still probably be)
bridges that we don't recognize as such or that are invisible for some
other reason. The BIOS has set them up correctly, and if we reprogram
other stuff, we may have serious problems.

In particular, a lot of PCI bridges - notably the host bridges - have
"extra" bridging information in the extended part of the PCI config space.
Just see the problems we had with serverworks and compaq host bridges and
the "last bus" information.

Generic code generally cannot get that right, and without full knowledge
of all bridges (which we'll never have even in theory - just think of
trying to boot a kernel on a chipset that is newer than the kernel) we're
much better off using the BIOS setup at least as a very strong HINT.

That said, we already have heuristics for stuff that we notice is broken
and we fix it up in that case. We could just try to add a new heuristic,
namely "if we notice that two PCI bridges have the same bus number, we'd
better allocate a new one somewhere".

		Linus


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-16 18:02       ` Alan Cox
@ 2001-06-16 18:15         ` Linus Torvalds
  2001-06-22 23:14           ` Eric Smith
  0 siblings, 1 reply; 15+ messages in thread
From: Linus Torvalds @ 2001-06-16 18:15 UTC (permalink / raw)
  To: Alan Cox; +Cc: Jeff Garzik, Eric Smith, linux-kernel, arjanv, mj


On Sat, 16 Jun 2001, Alan Cox wrote:
>
> > core should be more than just the kissing cousins they are now.  OTOH I
> > still don't like how much we trust firmware PCI bus setup on x86..
> 
> The BIOS may make assumptions we dont know about such as the bus layout. What
> minimises the problem is effectively to validate the firmware provided PCI
> setup and if its crap, then do the job ourselves. That minimizes the problems
> 
> Hence I think it should not be a define but an __init validator for the bus
> setup

Yes.

Regardless, it would certainly make sense to have a manual override, with
a kernel command line. If for no other reason than to allow for mistakes
and let the user force the old/new behaviour.

So the #define should be a variable with a kernel command line override,
along with a heuristic for the kernel to do a good guess on its own (and
the heuristic should probably not be as global as the current
"pcibios_assign_all_busses()" test - the heuristic will be able to tell on
a bridge basis on whether that bridge may need assignment. This might
imply giving the "pcibios_assign_all_busses()" thing the "dev" as an
argument).

		Linus


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-16 17:55     ` Jeff Garzik
  2001-06-16 18:02       ` Alan Cox
@ 2001-06-16 18:16       ` Linus Torvalds
  1 sibling, 0 replies; 15+ messages in thread
From: Linus Torvalds @ 2001-06-16 18:16 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: Alan Cox, Eric Smith, linux-kernel, arjanv, mj


On Sat, 16 Jun 2001, Jeff Garzik wrote:
> 
> I am pretty lucky on Alpha, we already trust the kernel PCI code
> implicitly by unconditionally defining pcibios_assign_all_busses to one.
> :)

Well, the _real_ advantage on the alpha side is that there are only a
handful of systems, and those systems tend to be designed by an even
smaller number of companies.

That, in turn, makes it so easy to trust the kernel to have enough
knowledge.

		Linus


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-16 18:10   ` Linus Torvalds
@ 2001-06-16 18:23     ` Alan Cox
  2001-06-16 19:22       ` Linus Torvalds
  0 siblings, 1 reply; 15+ messages in thread
From: Alan Cox @ 2001-06-16 18:23 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Jeff Garzik, Eric Smith, linux-kernel, Alan Cox, arjanv, mj

> Cardbus shouldn't be touching the bus stuff at all, BUT there may be
> strange hardware that doesn't like the following:
> 
>         config_writeb(socket, PCI_SEC_LATENCY_TIMER, 176); 
> 	config_writeb(socket, PCI_PRIMARY_BUS, dev->bus->number);
>         config_writeb(socket, PCI_SECONDARY_BUS, dev->subordinate->number);
>         config_writeb(socket, PCI_SUBORDINATE_BUS, dev->subordinate->number);
> 
> I have heard rumors of PCI devices that want all these set with a single
> double-word write.

That would be consistent with the behaviour in the bugzilla report - it went
from 0,0,0,1 to  176,0,0,0...

Alan


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-16 18:23     ` Alan Cox
@ 2001-06-16 19:22       ` Linus Torvalds
  2001-06-16 21:11         ` [PATCH] " Jeff Garzik
  0 siblings, 1 reply; 15+ messages in thread
From: Linus Torvalds @ 2001-06-16 19:22 UTC (permalink / raw)
  To: Alan Cox; +Cc: Jeff Garzik, Eric Smith, linux-kernel, arjanv, mj


On Sat, 16 Jun 2001, Alan Cox wrote:
>
> > Cardbus shouldn't be touching the bus stuff at all, BUT there may be
> > strange hardware that doesn't like the following:
> > 
> >         config_writeb(socket, PCI_SEC_LATENCY_TIMER, 176); 
> > 	config_writeb(socket, PCI_PRIMARY_BUS, dev->bus->number);
> >         config_writeb(socket, PCI_SECONDARY_BUS, dev->subordinate->number);
> >         config_writeb(socket, PCI_SUBORDINATE_BUS, dev->subordinate->number);
> > 
> > I have heard rumors of PCI devices that want all these set with a single
> > double-word write.
> 
> That would be consistent with the behaviour in the bugzilla report - it went
> from 0,0,0,1 to  176,0,0,0...

Hmm. It might be equally possible that we just get a bus number wrong
somewhere. In fact, looking at it more I think the yenta code is just
wrong - it uses the wrong bus numbers as far as I can see.

(And also, the generic PCI code _will_ write some of the bus information
with byte writes, so the "use a dword write" thing is not necessarily a
major requirement. See how the pci.c code writes the fixed-up subordinate
bus, for example).

As far as I can tell, the yenta code should _really_ do something like

	PCI_PROMARY_BUS:	dev->subordinate->primary
	PCI_SECONDARY_BUS:	dev->subordinate->secondary
	PCI_SUBORDINATE_BUS:	dev->subordinate->subordinate
	PCI_SEC_LATENCY_TIMER:	preferably settable, not just hardcoded to 176

instead of playing with "dev->bus->number" (which _should_ be the same as
it is now), and "subordinate->number" (which is _not_ the same as
"subordinate->subordinate".

So I think the bugzilla report just reflects the fact that we got
"PCI_SUBORDINATE_BUS" wrong.

Now, that is pretty much meaningless, as far as I can tell, because the
original 0,0,0,1 is _also_ bogus. No way should "secondary" be 0, as far
as I can tell - that would cause two buses to have bus # 0.

I suspect that the "fix" for this may be simpler than it initially
appears:

 - fix yenta.c to write the right values (ie get "subordinate" right -
   this will really only matter if/once we get PCI:PCI bridges on a
   cardbus card, and this is probably why nobody really reacted
   before). See above for the proper values.

 - Fix the "do I need to assign this bus" test in drivers/pci/pci.c. Right
   now it is:

	if ((buses & 0xffff00) && !pcibios_assign_all_busses()) {

   and from what I can tell it should really be more along the lines of

	primary = buses & 0xff;
	secondary = (buses >> 8) & 0xff;
	subordinate = (buses >> 16) & 0xff;

	assign = pcibios_assign_all_busses();

	/* Bus 0 should be the host bus */
	if (!secondary || !subordinate)
		assign = 1;

	/* Primary should be the same as the bus the bridge is on */
	if (primary != dev->bus->number)
		assing = 1;

	/* Subordinate should be larger or equal to secondary */
	if (secondary > subordinate)
		assign = 1;

#if 0
	/*
	 * We don't actually have full parent range - most of the time we
	 * don't understand host bridge ranges. Eventually we can do:
	 */

	/* The range [secondary:subordinate] must not contain the parent bus */
	if (secondary <= dev->bus->number && subordinate >= dev->bus->number)
		assign = 1;

	/* The range [secondary:subordinate] should be in the parent range */
	if (secondary < dev->bus->secondary)
		assign = 1;
	if (subordinate > dev->bus->subordinate)
		assign = 1;
#else
	/*
	 * In the meantime, we'll just _assume_ that all PCI bus numbers
	 * should be assigned in increasing order from the parent
	 */
	if (secondary <= dev->bus->number)
		assign = 1;
#endif

But the above is just my quick off-the-cuff "these are better
sanity-tests" thing, somebody else with PCI bus understanding should check
it out even more.

Jeff? Comments?

		Linus


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH] Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-16 19:22       ` Linus Torvalds
@ 2001-06-16 21:11         ` Jeff Garzik
  0 siblings, 0 replies; 15+ messages in thread
From: Jeff Garzik @ 2001-06-16 21:11 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Alan Cox, Eric Smith, linux-kernel, arjanv, mj

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

Linus Torvalds wrote:
> As far as I can tell, the yenta code should _really_ do something like
> 
>         PCI_PROMARY_BUS:        dev->subordinate->primary
>         PCI_SECONDARY_BUS:      dev->subordinate->secondary
>         PCI_SUBORDINATE_BUS:    dev->subordinate->subordinate
>         PCI_SEC_LATENCY_TIMER:  preferably settable, not just hardcoded to 176

Ah, nice.  That produces numbers on my laptop that look a bit better. 
Patch attached (which conflicts with the previous yenta.c patch).

I left 176 hardcoded for now, pending thinking on the rest of your
message...

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

[-- Attachment #2: yenta.patch --]
[-- Type: text/plain, Size: 868 bytes --]

Index: drivers/pcmcia/yenta.c
===================================================================
RCS file: /cvsroot/gkernel/linux_2_4/drivers/pcmcia/yenta.c,v
retrieving revision 1.1.1.25.4.1
diff -u -r1.1.1.25.4.1 yenta.c
--- drivers/pcmcia/yenta.c	2001/06/16 19:21:56	1.1.1.25.4.1
+++ drivers/pcmcia/yenta.c	2001/06/16 21:09:40
@@ -644,9 +644,9 @@
 	config_writeb(socket, PCI_LATENCY_TIMER, 168);
 	config_writel(socket, PCI_PRIMARY_BUS,
 		(176 << 24) |			   /* sec. latency timer */
-		(dev->subordinate->number << 16) | /* subordinate bus */
-		(dev->subordinate->number << 8) |  /* secondary bus */
-		dev->bus->number);		   /* primary bus */
+		(dev->subordinate->subordinate << 16) | /* subordinate bus */
+		(dev->subordinate->secondary << 8) |  /* secondary bus */
+		dev->subordinate->primary);		   /* primary bus */
 
 	/*
 	 * Set up the bridging state:

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-16 13:25   ` Alan Cox
  2001-06-16 17:55     ` Jeff Garzik
@ 2001-06-17  4:03     ` Albert D. Cahalan
  1 sibling, 0 replies; 15+ messages in thread
From: Albert D. Cahalan @ 2001-06-17  4:03 UTC (permalink / raw)
  To: Alan Cox
  Cc: Jeff Garzik, Eric Smith, linux-kernel, Linus Torvalds, Alan Cox,
	arjanv, mj

Alan Cox writes:
> [lost]

>> I would love to just define it unconditionally for x86, but I
>> believe Martin said that causes problems with some hardware, and
>> the way the BIOS has set up that hardware.  (details anyone?)
>
> Im not sure unconditionally is wise. However turning it into a
> routine that walks the PCI bus tree and returns 1 if a duplicate
> is found seems to be a little bit less likely to cause suprises

That could hurt.

I have a device that can serve as a bridge, and also as a
network card. Sometimes the bridge feature is not used, so
the bus numbers get set to 0xfd, 0xfe, 0xff or just all 0xff.
Multiple cards get the same values just to keep them out of
the way.

(this is a PCI-over-network thing)

Depending on EEPROM config data, it might not have a bridge
class code at boot. It has to be turned into a bridge via config
space writes though, so that the network feature will work.
This means I need to allocate some bus numbers after boot,
perhaps renumbering other bridges to make room. (BTW if there
is an API for this that I missed, please let me know)

In case I do want to really use the bridge feature, there is
a little bug to deal with. The primary bus number must be set
equal to the secondary bus number. No problem I hope?

Right now Linux seems happy, with lspci complaining a bit.

If the generic code were to "fix" my bus number assignment,
all Hell would break loose.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-16 18:15         ` Linus Torvalds
@ 2001-06-22 23:14           ` Eric Smith
  2001-06-22 23:27             ` Jeff Garzik
  0 siblings, 1 reply; 15+ messages in thread
From: Eric Smith @ 2001-06-22 23:14 UTC (permalink / raw)
  To: linux-kernel

I wrote:
> Does it make sense to turn pcibios_assign_all_busses into a variable
> with a default value of zero, and implement a kernel argument to set it?

After some discussion of various alternatives, including always turning it
on (bad for some systems), or writing a function to try to determine if
the configuration left by the BIOS is sane (maybe OK, but could still need
to be overridden), Linus wrote:
> Regardless, it would certainly make sense to have a manual override, with
> a kernel command line. If for no other reason than to allow for mistakes
> and let the user force the old/new behaviour.

Since I offered to generate a suitable patch, below find one against
2.4.5.  This patch ONLY tries to provide for the command line override.
I had to touch more files than I would have liked, and unfortunately can
only test it on x86 even though it potentially affects other
architectures.  It seems to do the right thing on my IBM ThinkPad 240.

What I've done is:

1)  Replaced the pcibios_assign_all_busses() macro in each architecture
    with a defined constant PCI_ASSIGN_ALL_BUSSES_DEFAULT.  Note that some
    architectures were using a function instead of a macro, but the function
    just returned the contents of a variable.

2)  Added the variable pci_assign_all_busses, which gets initialized from
    the defined constant PCI_ASSIGN_ALL_BUSSES_DEFAULT.

3)  Added a __setup macro and function to handle a command line argument
    "pci_assign_all_busses=1" (or zero), which sets the pci_assign_all_busses
    variable.

4)  Changed the code in drivers/pci/pci.c to use the variable rather than
    the old macro/function.

If code is added to attempt to automatically determine whether bus
configuration is needed, and if that code runs after the command line is
parsed, it might be necessary to add a second variable (or special
values of the existing one) to avoid changing the variable if the user
has specified a value on the command line, since the whole point is to
allow the user to override the default behavior.

If I've done this in a suboptimal manner, I'd be happy to hear
suggestions of better approaches.  As submitting kernel patches goes,
this is my first time, so please be gentle.  :-)

Thanks,
Eric



diff -uNr linux-2.4.5.orig/arch/parisc/kernel/inventory.c linux-2.4.5/arch/parisc/kernel/inventory.c
--- linux-2.4.5.orig/arch/parisc/kernel/inventory.c	Wed Dec  6 11:46:39 2000
+++ linux-2.4.5/arch/parisc/kernel/inventory.c	Thu Jun 21 18:26:52 2001
@@ -138,6 +138,7 @@
 	ulong pcell_loc;
 
 	pdc_pat = (pdc_pat_cell_get_number(&pdc_result) == PDC_OK);
+	pci_assign_all_busses = pdc_pat;
 	if (!pdc_pat)
 	{
 		return 0;
diff -uNr linux-2.4.5.orig/arch/ppc/kernel/pci.c linux-2.4.5/arch/ppc/kernel/pci.c
--- linux-2.4.5.orig/arch/ppc/kernel/pci.c	Mon May 21 17:04:47 2001
+++ linux-2.4.5/arch/ppc/kernel/pci.c	Thu Jun 21 18:26:52 2001
@@ -47,10 +47,6 @@
 static void pcibios_fixup_cardbus(struct pci_dev* dev);
 #endif
 
-/* By default, we don't re-assign bus numbers. We do this only on
- * some pmacs
- */
-int pci_assign_all_busses;
 
 struct pci_controller* hose_head;
 struct pci_controller** hose_tail = &hose_head;
@@ -752,11 +748,6 @@
 		ppc_md.pcibios_after_init();
 }
 
-int __init
-pcibios_assign_all_busses(void)
-{
-	return pci_assign_all_busses;
-}
 
 void __init
 pcibios_fixup_pbus_ranges(struct pci_bus * bus, struct pbus_set_ranges_data * ranges)
diff -uNr linux-2.4.5.orig/drivers/pci/pci.c linux-2.4.5/drivers/pci/pci.c
--- linux-2.4.5.orig/drivers/pci/pci.c	Sat May 19 17:43:06 2001
+++ linux-2.4.5/drivers/pci/pci.c	Thu Jun 21 18:26:52 2001
@@ -37,6 +37,19 @@
 LIST_HEAD(pci_root_buses);
 LIST_HEAD(pci_devices);
 
+
+int pci_assign_all_busses = PCI_ASSIGN_ALL_BUSSES_DEFAULT;
+
+
+static int __init pci_assign_all_busses_setup(char *str)
+{
+	pci_assign_all_busses = simple_strtol(str,NULL,0);
+	return 1;
+}
+
+__setup("pci_assign_all_busses=", pci_assign_all_busses_setup);
+
+
 /**
  * pci_find_slot - locate PCI device from a given PCI slot
  * @bus: number of PCI bus on which desired PCI device resides
@@ -957,7 +970,7 @@
 
 	pci_read_config_dword(dev, PCI_PRIMARY_BUS, &buses);
 	DBG("Scanning behind PCI bridge %s, config %06x, pass %d\n", dev->slot_name, buses & 0xffffff, pass);
-	if ((buses & 0xffff00) && !pcibios_assign_all_busses()) {
+	if ((buses & 0xffff00) && !pci_assign_all_busses) {
 		/*
 		 * Bus already configured by firmware, process it in the first
 		 * pass and just note the configuration.
diff -uNr linux-2.4.5.orig/include/asm-alpha/pci.h linux-2.4.5/include/asm-alpha/pci.h
--- linux-2.4.5.orig/include/asm-alpha/pci.h	Mon May 21 13:38:41 2001
+++ linux-2.4.5/include/asm-alpha/pci.h	Thu Jun 21 18:26:52 2001
@@ -46,7 +46,7 @@
 /* Override the logic in pci_scan_bus for skipping already-configured
    bus numbers.  */
 
-#define pcibios_assign_all_busses()	1
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 1
 
 #define PCIBIOS_MIN_IO		alpha_mv.min_io_address
 #define PCIBIOS_MIN_MEM		alpha_mv.min_mem_address
diff -uNr linux-2.4.5.orig/include/asm-arm/arch-ebsa285/hardware.h linux-2.4.5/include/asm-arm/arch-ebsa285/hardware.h
--- linux-2.4.5.orig/include/asm-arm/arch-ebsa285/hardware.h	Mon Nov 27 17:07:59 2000
+++ linux-2.4.5/include/asm-arm/arch-ebsa285/hardware.h	Thu Jun 21 18:26:52 2001
@@ -131,7 +131,7 @@
 extern void cpld_modify(int mask, int set);
 #endif
 
-#define pcibios_assign_all_busses()	1
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 1
 
 #define PCIBIOS_MIN_IO		0x6000
 #define PCIBIOS_MIN_MEM 	0x40000000
diff -uNr linux-2.4.5.orig/include/asm-i386/pci.h linux-2.4.5/include/asm-i386/pci.h
--- linux-2.4.5.orig/include/asm-i386/pci.h	Fri May 25 18:02:07 2001
+++ linux-2.4.5/include/asm-i386/pci.h	Thu Jun 21 18:26:52 2001
@@ -7,7 +7,7 @@
    already-configured bus numbers - to be used for buggy BIOSes
    or architectures with incomplete PCI setup by the loader */
 
-#define pcibios_assign_all_busses()	0
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 0
 
 extern unsigned long pci_mem_start;
 #define PCIBIOS_MIN_IO		0x1000
diff -uNr linux-2.4.5.orig/include/asm-ia64/pci.h linux-2.4.5/include/asm-ia64/pci.h
--- linux-2.4.5.orig/include/asm-ia64/pci.h	Wed May 16 10:31:27 2001
+++ linux-2.4.5/include/asm-ia64/pci.h	Thu Jun 21 18:26:52 2001
@@ -14,7 +14,7 @@
  * already-configured bus numbers - to be used for buggy BIOSes or
  * architectures with incomplete PCI setup by the loader.
  */
-#define pcibios_assign_all_busses()     0
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 0
 
 #define PCIBIOS_MIN_IO		0x1000
 #define PCIBIOS_MIN_MEM		0x10000000
diff -uNr linux-2.4.5.orig/include/asm-m68k/pci.h linux-2.4.5/include/asm-m68k/pci.h
--- linux-2.4.5.orig/include/asm-m68k/pci.h	Wed May 16 10:31:27 2001
+++ linux-2.4.5/include/asm-m68k/pci.h	Thu Jun 21 18:26:52 2001
@@ -33,7 +33,7 @@
 	void (*conf_device)(unsigned char bus, unsigned char device_fn);
 };
 
-#define pcibios_assign_all_busses()	0
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 0
 
 extern inline void pcibios_set_master(struct pci_dev *dev)
 {
diff -uNr linux-2.4.5.orig/include/asm-mips/pci.h linux-2.4.5/include/asm-mips/pci.h
--- linux-2.4.5.orig/include/asm-mips/pci.h	Wed May 16 10:31:27 2001
+++ linux-2.4.5/include/asm-mips/pci.h	Thu Jun 21 18:26:52 2001
@@ -13,7 +13,7 @@
    already-configured bus numbers - to be used for buggy BIOSes
    or architectures with incomplete PCI setup by the loader */
 
-#define pcibios_assign_all_busses()	0
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 0
 
 #define PCIBIOS_MIN_IO		0x1000
 #define PCIBIOS_MIN_MEM		0x10000000
diff -uNr linux-2.4.5.orig/include/asm-mips64/pci.h linux-2.4.5/include/asm-mips64/pci.h
--- linux-2.4.5.orig/include/asm-mips64/pci.h	Wed May 16 10:31:27 2001
+++ linux-2.4.5/include/asm-mips64/pci.h	Thu Jun 21 18:26:52 2001
@@ -13,7 +13,7 @@
    already-configured bus numbers - to be used for buggy BIOSes
    or architectures with incomplete PCI setup by the loader */
 
-#define pcibios_assign_all_busses()	0
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 0
 
 #define PCIBIOS_MIN_IO		0x1000
 #define PCIBIOS_MIN_MEM		0x10000000
diff -uNr linux-2.4.5.orig/include/asm-parisc/pci.h linux-2.4.5/include/asm-parisc/pci.h
--- linux-2.4.5.orig/include/asm-parisc/pci.h	Wed May 16 10:31:27 2001
+++ linux-2.4.5/include/asm-parisc/pci.h	Thu Jun 21 18:26:52 2001
@@ -204,9 +204,8 @@
 */
 #ifdef __LP64__
 extern int pdc_pat;  /* arch/parisc/kernel/inventory.c */
-#define pcibios_assign_all_busses()	pdc_pat
-#else
-#define pcibios_assign_all_busses()	0
+extern int pci_assign_all_busses;  /* drivers/pci/pci.c */
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 0
 #endif
 
 #define PCIBIOS_MIN_IO          0x10
diff -uNr linux-2.4.5.orig/include/asm-ppc/pci.h linux-2.4.5/include/asm-ppc/pci.h
--- linux-2.4.5.orig/include/asm-ppc/pci.h	Mon May 21 15:02:06 2001
+++ linux-2.4.5/include/asm-ppc/pci.h	Thu Jun 21 18:26:52 2001
@@ -13,7 +13,11 @@
 #define IOBASE_ISA_MEM		4
 
 
-extern int pcibios_assign_all_busses(void);
+/* By default, we don't re-assign bus numbers. We do this only on
+ * some pmacs
+ */
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 0
+extern int pci_assign_all_busses;  /* drivers/pci/pci.c */
 
 #define PCIBIOS_MIN_IO		0x1000
 #define PCIBIOS_MIN_MEM		0x10000000
diff -uNr linux-2.4.5.orig/include/asm-sh/pci.h linux-2.4.5/include/asm-sh/pci.h
--- linux-2.4.5.orig/include/asm-sh/pci.h	Wed May 16 10:31:27 2001
+++ linux-2.4.5/include/asm-sh/pci.h	Thu Jun 21 18:28:48 2001
@@ -7,7 +7,7 @@
    already-configured bus numbers - to be used for buggy BIOSes
    or architectures with incomplete PCI setup by the loader */
 
-#define pcibios_assign_all_busses()	1
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 1
 
 /* These are currently the correct values for the STM overdrive board. 
  * We need some way of setting this on a board specific way, it will 
diff -uNr linux-2.4.5.orig/include/asm-sparc/pci.h linux-2.4.5/include/asm-sparc/pci.h
--- linux-2.4.5.orig/include/asm-sparc/pci.h	Wed May 16 10:31:27 2001
+++ linux-2.4.5/include/asm-sparc/pci.h	Thu Jun 21 18:26:52 2001
@@ -7,7 +7,7 @@
  * already-configured bus numbers - to be used for buggy BIOSes
  * or architectures with incomplete PCI setup by the loader.
  */
-#define pcibios_assign_all_busses()	0
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 0
 
 #define PCIBIOS_MIN_IO		0UL
 #define PCIBIOS_MIN_MEM		0UL
diff -uNr linux-2.4.5.orig/include/asm-sparc64/pci.h linux-2.4.5/include/asm-sparc64/pci.h
--- linux-2.4.5.orig/include/asm-sparc64/pci.h	Wed May 16 10:31:27 2001
+++ linux-2.4.5/include/asm-sparc64/pci.h	Thu Jun 21 18:26:52 2001
@@ -10,7 +10,7 @@
  * already-configured bus numbers - to be used for buggy BIOSes
  * or architectures with incomplete PCI setup by the loader.
  */
-#define pcibios_assign_all_busses()	0
+#define PCI_ASSIGN_ALL_BUSSES_DEFAULT 0
 
 #define PCIBIOS_MIN_IO		0UL
 #define PCIBIOS_MIN_MEM		0UL

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: 2.4.2 yenta_socket problems on ThinkPad 240
  2001-06-22 23:14           ` Eric Smith
@ 2001-06-22 23:27             ` Jeff Garzik
  0 siblings, 0 replies; 15+ messages in thread
From: Jeff Garzik @ 2001-06-22 23:27 UTC (permalink / raw)
  To: Eric Smith; +Cc: Linux Kernel Mailing List

You should try 2.4.6-pre5, it already includes a patch for you :)

pci=assign-busses on the command line.

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

^ permalink raw reply	[flat|nested] 15+ messages in thread

* 2.4.2 yenta_socket problems on ThinkPad 240
@ 2001-06-07  0:09 Eric Smith
  0 siblings, 0 replies; 15+ messages in thread
From: Eric Smith @ 2001-06-07  0:09 UTC (permalink / raw)
  To: linux-kernel

I upgraded my IBM ThinkPad 240 (Type 2609-31U) from Red Hat 7.0 to
Red Hat 7.1, which uses the 2.4.2 kernel and the kernel PCMCIA drivers.

Before the upgrade, all my CardBus and PCMCIA devices were working fine.
Now the yenta_socket module seems to be causing problems, and none of
the cards work.

Before doing 'modprobe yenta_socket', the PCI stuff looks OK:

    % ls -l /proc/bus/pci
    total 0
    dr-xr-xr-x    2 root    root            0 Jun  1 12:52 00
    -r--r--r--    1 root    root            0 Jun  1 12:52 devices

    % ls /proc/bus/pci/00
    00.0  07.0  07.1  07.2  07.3  09.0  0a.0  0b.0  0c.0

and lspci -vvv gives normal-looking output (which I can send if it's
useful).

After the 'modprobe yenta_socket':

    % ls -l /proc/bus/pci
    total 0
    dr-xr-xr-x    2 root    root            0 Jun  1 12:44 00
    dr-xr-xr-x    2 root    root            0 Jun  1 12:44 00
    -r--r--r--    1 root    root            0 Jun  1 12:44 devices

Note the two directories with the same name.

    % ls -l /proc/bus/pci/00
    total 0
    -rw-r--r--    1 root    root            0 Jun  1 12:48 00.0

    % lspci -vvv
    pcilib: Cannot open /proc/bus/pci/00/0c.0

Has anyone seen similar behavior?  Is there any way to force
yenta_socket to assign the cardbus to be bus 01 rather than 00?

Thanks!
Eric Smith

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2001-06-22 23:28 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-15 23:14 2.4.2 yenta_socket problems on ThinkPad 240 Eric Smith
2001-06-15 23:25 ` Jeff Garzik
2001-06-16 13:25   ` Alan Cox
2001-06-16 17:55     ` Jeff Garzik
2001-06-16 18:02       ` Alan Cox
2001-06-16 18:15         ` Linus Torvalds
2001-06-22 23:14           ` Eric Smith
2001-06-22 23:27             ` Jeff Garzik
2001-06-16 18:16       ` Linus Torvalds
2001-06-17  4:03     ` Albert D. Cahalan
2001-06-16 18:10   ` Linus Torvalds
2001-06-16 18:23     ` Alan Cox
2001-06-16 19:22       ` Linus Torvalds
2001-06-16 21:11         ` [PATCH] " Jeff Garzik
  -- strict thread matches above, loose matches on Subject: below --
2001-06-07  0:09 Eric Smith

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).