From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
To: alan@lxorguk.ukuu.org.uk (Alan Cox)
Cc: jgarzik@mandrakesoft.com (Jeff Garzik),
eric@brouhaha.com (Eric Smith),
linux-kernel@vger.kernel.org,
torvalds@transmeta.com (Linus Torvalds),
alan@lxorguk.ukuu.org.uk (Alan Cox),
arjanv@redhat.com, mj@ucw.cz
Subject: Re: 2.4.2 yenta_socket problems on ThinkPad 240
Date: Sun, 17 Jun 2001 00:03:59 -0400 (EDT) [thread overview]
Message-ID: <200106170403.f5H43x869307@saturn.cs.uml.edu> (raw)
In-Reply-To: <E15BG4h-000842-00@the-village.bc.nu> from "Alan Cox" at Jun 16, 2001 02:25:15 PM
Alan Cox writes:
> [lost]
>> I would love to just define it unconditionally for x86, but I
>> believe Martin said that causes problems with some hardware, and
>> the way the BIOS has set up that hardware. (details anyone?)
>
> Im not sure unconditionally is wise. However turning it into a
> routine that walks the PCI bus tree and returns 1 if a duplicate
> is found seems to be a little bit less likely to cause suprises
That could hurt.
I have a device that can serve as a bridge, and also as a
network card. Sometimes the bridge feature is not used, so
the bus numbers get set to 0xfd, 0xfe, 0xff or just all 0xff.
Multiple cards get the same values just to keep them out of
the way.
(this is a PCI-over-network thing)
Depending on EEPROM config data, it might not have a bridge
class code at boot. It has to be turned into a bridge via config
space writes though, so that the network feature will work.
This means I need to allocate some bus numbers after boot,
perhaps renumbering other bridges to make room. (BTW if there
is an API for this that I missed, please let me know)
In case I do want to really use the bridge feature, there is
a little bug to deal with. The primary bus number must be set
equal to the secondary bus number. No problem I hope?
Right now Linux seems happy, with lspci complaining a bit.
If the generic code were to "fix" my bus number assignment,
all Hell would break loose.
next prev parent reply other threads:[~2001-06-17 4:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-15 23:14 2.4.2 yenta_socket problems on ThinkPad 240 Eric Smith
2001-06-15 23:25 ` Jeff Garzik
2001-06-16 13:25 ` Alan Cox
2001-06-16 17:55 ` Jeff Garzik
2001-06-16 18:02 ` Alan Cox
2001-06-16 18:15 ` Linus Torvalds
2001-06-22 23:14 ` Eric Smith
2001-06-22 23:27 ` Jeff Garzik
2001-06-16 18:16 ` Linus Torvalds
2001-06-17 4:03 ` Albert D. Cahalan [this message]
2001-06-16 18:10 ` Linus Torvalds
2001-06-16 18:23 ` Alan Cox
2001-06-16 19:22 ` Linus Torvalds
2001-06-16 21:11 ` [PATCH] " Jeff Garzik
-- strict thread matches above, loose matches on Subject: below --
2001-06-07 0:09 Eric Smith
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=200106170403.f5H43x869307@saturn.cs.uml.edu \
--to=acahalan@cs.uml.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjanv@redhat.com \
--cc=eric@brouhaha.com \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mj@ucw.cz \
--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).