"Maciej W. Rozycki" wrote: > > On Mon, 13 Aug 2001, Gleb O. Raiko wrote: > > > > 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. > > > 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.
