Subject: Re: CVS [email-masked]: linux

From: Jun Sun <[email-masked]>
Date: Tue, 20 Apr 2004 10:51:16 -0700

On Tue, Apr 20, 2004 at 05:32:25PM +0100, [email-masked] wrote:
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	[email-masked]	04/04/20 17:32:25
> 
> Modified files:
> 	arch/mips      : Tag: linux_2_4 config-shared.in 
> 
> Log message:
> 	Do not allow CONFIG_PCI_AUTO to be selectable to discourage new users
> 	from using this b0rked code.
> 

CONFIG_PCI_AUTO was meant to a board attribute.  It should not be changed
to be a choice at the first place.

And, the code is not bOrked.  In 2.4 it is a life saver for most MIPS boards
whose firmware do not do a proper or full PCI resource assignment.

Jun

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 20 Apr 2004 22:11:28 +0200

> whose firmware do not do a proper or full PCI resource assignment.

drivers/pci can do that, you just need to supply a few board specific
functions, see for example arch/alpha/kernel/pci.c.  So pci_auto.c isn't
only b0rked, it also duplicates code.

  Ralf

---

From: Pete Popov <[email-masked]>
Date: Tue, 20 Apr 2004 13:20:45 -0700

Ralf Baechle wrote:

>functions, see for example arch/alpha/kernel/pci.c.  
>
>So pci_auto.c isn't only b0rked, it also duplicates code.
>  
>
I guess I have different take on it, in line with Jun's. Before pci 
auto, I remember new boards going in without proper pci config support 
or with massive amounts of new board specific code. Take a look at the 
gt64xxx code (though I think it's been cleaned up a lot since then). 
After pci auto, adding pci support for a new board became trivial and I 
haven't seen anymore code duplication with new boards adding their own, 
complete, pci resource assignment routines.  Pci auto was added a long 
time ago. If it has outlived its purpose, that's fine, but back then it 
was a major improvement to the mips pci subsystem, imho.

Pete

---

From: Jun Sun <[email-masked]>
Date: Tue, 20 Apr 2004 15:31:08 -0700

> only b0rked, it also duplicates code.

Has anybody succssfully used pci_assign_unassigned_resources() in latest 2.4?
It was badly broken in early 2.4 kernels while pci_auto was the only 
option.

So at most you can only say "pci_assign_unassigned_resources() can
finally does what pci_auto does". :)

Jun

---

From: "Gleb O. Raiko" <[email-masked]>
Date: Wed, 21 Apr 2004 12:55:06 +0400

> It was badly broken in early 2.4 kernels while pci_auto was the only

In fact, I have used pci_assign_unassigned_resources() from early 2.4
days. The only code I had to supply was
fixup of PCI-PCI bridge spaces which was done in pcibios_fixup_bus,
something like
        if(!bus->self) /* Primary busses */
                bus->resource[0] = &ioport_resource;
                bus->resource[1] = &iomem_resource;
	else /* busses behind PCI-PCI bridges */
	    for IO, MEM, and PREFETCH spaces:
                bus->resource[i] =
&bus->self->resource[PCI_BRIDGE_RESOURCES+i];
                bus->resource[i]->start =
bus->parent->resource[i]->start;
                bus->resource[i]->end   = bus->parent->resource[i]->end;
                bus->resource[i]->flags =
bus->parent->resource[i]->flags;
                bus->resource[i]->name  = bus->name;

Ah, I had to disable ISA mapping in 2.4.25.

After that, pci_assign_unassigned_resources() assigns all resources
properly. If for some reason, you have to preserve PBAR's values
assigned by a BIOS, setup pci_dev.resource[].parent before invoking
pci_assign_unassigned_resources.
> finally does what pci_auto does". :)

Exactly.

Regards,
Gleb.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 21 Apr 2004 16:11:29 +0200 (CEST)

> It was badly broken in early 2.4 kernels while pci_auto was the only 

 In that case, fixing pci_assign_unassigned_resources() was the right way
to go, instead of implementing a system-specific workaround.  There are no
excuses -- the source is available.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Jun Sun <[email-masked]>
Date: Wed, 21 Apr 2004 10:20:13 -0700

On Wed, Apr 21, 2004 at 04:11:29PM +0200, Maciej W. Rozycki wrote:
> to go, instead of implementing a system-specific workaround.  

Using pci_auto() represented a different approach, which to many seems more
correct.  It does assignment first and then scanning.  It is supplied
as a replacement for broken firmware.

At one time a couple of pci_auto()'s existed in more than one arch.  And
there was a chance to make this approach the official one and completely 
eliminate pci_assign_unassigned_resources().

Having competing approaches co-existing in Linux is a norm.

> There are no

Please don't always assume other people are more ignorant ....

Jun

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 21 Apr 2004 20:04:50 +0200 (CEST)

> as a replacement for broken firmware.

 Well the Alpha port did resource management since its early days, due to
the complexity of Alpha setups (I'm pretty sure DEC was first to put
PCI-PCI bridges into their systems on a regular basis) and firmware
oddities (not necessarily due to brokenness but rather competing
assumptions, although there was an option to run MILO from the system
flash ROM and then the system wouldn't execute a lot of initialization
steps before passing control to Linux), like setting up I/O port
allocations above 0xffff, which would surprise some drivers.  That means
around 1995 or 1996.  So the code has been out there for a long time --
long enough to make any remaining problems resolved.

> eliminate pci_assign_unassigned_resources().

 But if it didn't happen, then it means it was not the right approach.

> Having competing approaches co-existing in Linux is a norm.

 Well, it's normal for development series.  For stable series there's an
established way of doing stuff and port maintainers should migrate.  
Actually, there's a "feature freeze" point in the development series
(which you probably know) to let maintainers finish before a stable
release.  In reality it does not always happen as depending on various 
factors maintainers may have more or less resources available, but better 
or worse they work on eliminating obsolete cruft.

 I'm writing of in-tree development here -- people can do research on
alternatives off-tree, of course, including working and testing in stable
series.  If proved to be good, the results are typically merged in the
early days of development series.

> Please don't always assume other people are more ignorant ....

 This is insulting -- I never assume that.  One has to prove that to me
first.

 In cases like this, I've noticed the trend is to think: "Well, Linus[1]
is too tough to be convinced to accept arbitrary changes, so let's just
code our stuff independently and keep it with system-specific bits."  But 
as I wrote, code is available and you have two proper choices:

1. Fix what's wrong in the existing code.

2. Propose a superior alternative.

#1 may be easier and #2 may provide better results.  But it doesn't happen
-- I hardly ever hear any voice in discussions on the LKML from people
involved in developing for the MIPS platform.

[1] Substitute a subsystem maintainer as needed.

  Maciej