linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Bombe <andreas.bombe@munich.netsurf.de>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] yenta resource allocation fix
Date: Wed, 29 Aug 2001 23:20:28 +0200	[thread overview]
Message-ID: <20010829232028.A2411@storm.local> (raw)
In-Reply-To: <20010829013318.A16910@storm.local> <Pine.LNX.4.33.0108290645140.8173-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.33.0108290645140.8173-100000@penguin.transmeta.com>

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

  reply	other threads:[~2001-08-29 21:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-28 23:33 [PATCH] yenta resource allocation fix Andreas Bombe
2001-08-29  1:23 ` Linus Torvalds
2001-08-29 13:48 ` Linus Torvalds
2001-08-29 21:20   ` Andreas Bombe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-08-26 22:58 Andreas Bombe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010829232028.A2411@storm.local \
    --to=andreas.bombe@munich.netsurf.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).