![]() | ||||||||||
Messages in this thread |
Hi,
It seems we need a little more discussion.
Please don't apply my patches >> Andrew, Greg
Russel, I'm sorry, but could you wait some hours for my reply?
I noticed the email from you when I was about to go to bed...
Thanks,
Kenji Kaneshige
Russell King wrote:
> On Fri, Mar 03, 2006 at 12:12:34AM +0900, Kenji Kaneshige wrote:
>
>>Hi Andrew, Greg,
>>
>>Here is an updated set of patches for PCI legacy I/O port free
>>driver. It incorporates all of the feedbacks. I rebased it against the
>>latest -mm kernel (2.6.16-rc5-mm1).
>>
>>Could you consider applying this to -mm tree?
>
>
> I've been wondering whether this "no_ioport" flag is the correct approach,
> or whether it's adding to complexity when it isn't really required.
>
> In the non-Intel world, the kernel itself sets up the PCI bus mappings,
> and any IO bars which it can't satisfy might also need to be gracefully
> handled. Currently, we just go 'printk("whoops, didn't allocate
> resource")' and leave the BAR containing whatever random junk it
> contained before, along with the resource containing whatever random
> junk pci_bus_alloc_resource() decided to leave in it.
>
> In such cases, I would suggest that the method of signalling that IO
> should not be used is to have the IO resource structures cleared out -
> if the IO resources aren't valid, they should not contain something
> which could be interpreted as valid.
>
> Maybe something like this should be done for the "legacy IO port" case
> as well?
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
| |||||||||
| Last update: 2006-03-02 16:27 [from the cache] ©2003-2008 | ||||||||||