Re: [PATCH 0/4] PCI legacy I/O port free driver (take4)

[Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>]

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?
>