"Maciej W. Rozycki" wrote:

On Mon, 13 Aug 2001, Gleb O. Raiko wrote:

quoted

quoted

 Note that for PCI-based systems, there is usually no problem -- PCI IDs
can be used instead in most cases.

How? In fact, I've got two different boards with the same Ethernet chip.
Moreover, mach type shall be known as early as possible, early than pci
init for sure. Just imagine, I need a way to identify PCI controller by
mach type, so I need to scan pci busses for specific ID. Boom. :-) Did I
miss something in your proposal?

 The PCI ID of a host bridge is usually sufficient to differentiate most
systems for onboard devices that are not reported on PCI.  If it is not
for your one, you just fall outside of the scope of "most cases" and you
need a different way to identify a system.  Note I do not promote
mips_machtype removal.

In order to read a PCI ID, you need to know how to do it. In pc world,
you may rely on configuation access types, at least, ports are known. On
other arches, you need to know where such "ports" are. Even if hardware
supports, say, configuration type 1 accesses, developers are free to put
port addresses anywhere.

quoted

BTW, in my Baget case, I just need a number for mach type. I can ask to
change my prom in worst case.

 How do you set up mips_machtype on your system in the first place?  At
kernel_entry the code does not know what machine it's running on anyway,
so it has to set mips_machtype based on a detection algorithm.

First, mips_machtype is accessed far later than kernel_entry is
executed. Personally, I am lucky :-), I may read firmware environment
variables.

Regards,
Gleb.