Re: [PATCH] add PCI ROMs to sysfs

[Martin Mares]

Hello!

> That's why it works right now without the assign_resource. The BIOS has
> already set everything up.

Yes, it happens on some machines, but by far not on all.

> The code that accesses the ROM runs very early, before anything else is
> loaded. The only conflict I can think of is from the on-board BIOS of a
> disk cotroller with partial decoding. But I'm not sure if a care like
> that exists.

No, conflict can happen whenever the ROM and the BAR's are enabled
at the same time. The BAR's are usually already enabled when your code runs.

You either should disable the BAR's for a while or, much better, avoid
touching the ROM base register until somebody explicitly requests it.

I know the devices with shared decoders are rare, but I still prefer
a kernel which, given such a device, works fine if you don't touch
the sysfs files, to a kernel, which crashes during boot under such
circumstances.

Hence it is much better to avoid scanning the ROM for the real size
unless you are copying it. Using the size of the resource for the
sysfs file doesn't hurt anybody as the file itself shouldn't eat up
any space.

> If a card like this exists, I need to make the code use the BIOS SHADOW
> copy of the ROM.

Beware, such a copy needn't exist, you need to create your own shadow copy.

> The system shadow copy is one of the main motivators for this code. On
> some laptop the system and video ROMs are compressed. On these systems
> the boot ROM decompresses these ROM into the shadow memory at
> C0000-100000.

Is there any reliable way to find the address and size of such a shadow
image or we need to stick with the 0xc0000 + 256KB range?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@xxxxxx>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
A Bash poem: time for echo in canyon; do echo $echo $echo; done
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/