Messages in this thread | | | Date | Wed, 29 Aug 2001 23:20:28 +0200 | Subject | Re: [PATCH] yenta resource allocation fix | From | Andreas Bombe <> |
| |
On Wed, Aug 29, 2001 at 06:48:26AM -0700, Linus Torvalds wrote: > > On Wed, 29 Aug 2001, Andreas Bombe wrote: > > > > I have no idea why the 0xfff was in place. Or, on second thought, this > > might be to allocate memory space behind official end as slack? This > > would defy the end > start check then, anyway. Linus? > > I've looked more at the issue. > > 0xfff is definitely right for memory windows and is generally right for > PCI-PCI bridges too - they cannot have IO or memory windows that are > anything but 4kB aligned. > > But it turns out that the Yenta specification actually expanded on the > PCI-PCI bridge window specs for IO space - a Yenta bridge is supposed to > be able to handle IO windows at 4-byte granularity, not the 4kB a regular > PCI bridge does.
Even then the old code would have been incorrect. Further down the yenta_allocate_res() function, allocate_resource() is called with align = 1024 and size = 256 for IO port windows. It also promptly got 0x1000-0x10ff and 0x1400-0x14ff allocated.
> Does this alternate patch work for you?
Ignoring the unrelated vmscan.c patch, yes, it works as it should, thanks (I never hit the memory window case anyway, since that is allocated fine before yenta.c gets to it).
About the other thing with missed card insertion events there is nothing new. I tried a few things but nothing helped. There is the suspicious thing that CB_SOCKET_STATE has CB_CBCARD always set, whether there is a card or not, but I don't know enough of the code to see where it matters.
-- Andreas E. Bombe <andreas.bombe@munich.netsurf.de> DSA key 0x04880A44 - 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/
| |