Linmodems Mailing list Archives

Google
 
Web archives.linmodems.org

Return-Path: <heby@heby.de>
Mailing-List: contact discuss-help@linmodems.org; run by ezmlm
Delivered-To: mailing list discuss@linmodems.org
Received: (qmail 6441 invoked from network); 11 Mar 2001 20:14:50 -0000
Received: from cr1024117-a.rct1.bc.wave.home.com (HELO defiant.heby.de) (root@24.115.229.128)
  by www.linmodems.org with SMTP; 11 Mar 2001 20:14:50 -0000
Received: from localhost (really [127.0.0.1]) by heby.de
	via in.smtpd with esmtp (ident heby using rfc1413)
	id <m14cCEJ-000Gx6C@defiant.heby.de> (Debian Smail3.2.0.111)
	for <discuss@linmodems.org>; Sun, 11 Mar 2001 12:14:15 -0800 (PST) 
Date: Sun, 11 Mar 2001 12:14:15 -0800 (PST)
From: christoph hebeisen <heby@heby.de>
To: Marvin Stodolsky <stodolsk@rcn.com>
cc: Eric Shattow <radoni@crosswinds.net>, discuss@linmodems.org
Subject: Re: ltmodem: (rant)    flaws in I/O logic?
In-Reply-To: <3AAB02B1.9838DA41@rcn.com>
Message-ID: <Pine.LNX.4.10.10103111146090.7708-100000@defiant.heby.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

hi,

> A knowledgeable answer will have to await return of coders Mark Spieth
> and Chris Hebiesen from conferences next week.  

i only had a very quick look because i'm pretty busy getting my stuff
for the conference together (as marvin said). the situation seems to be 
the following: on the one hand you're lucky - this stuff is in the open
source part of the driver (open source but unknown license - ltmodem.c).

-----
[...]
static struct pci_dev *dev = NULL;
[...]
BOOL lt_pci_find_device ( unsigned int id, unsigned int num )
{
        dev = pci_find_device ( id, num, dev );
[...]
-----

pci_find_device is a function from linux/drivers/pci/pci.c:

-----
/**
 * pci_find_device - begin or continue searching for a PCI device by vendor/device id
 * @vendor: PCI vendor id to match, or %PCI_ANY_ID to match all vendor ids
 * @device: PCI device id to match, or %PCI_ANY_ID to match all vendor ids   
 * @from: Previous PCI device found in search, or %NULL for new search.
 *
 * Iterates through the list of known PCI devices.  If a PCI device is
 * found with a matching @vendor and @device, a pointer to its device structure is
 * returned.  Otherwise, %NULL is returned.
 *
 * A new search is initiated by passing %NULL to the @from argument.   
 * Otherwise if @from is not null, searches continue from that point.
 */
struct pci_dev *
pci_find_device(unsigned int vendor, unsigned int device, const struct
pci_dev *from)
{ 
-----

so it looks like this does scan through all devices until it finds the
ltmodem but that's not the drivers fault but just the way things are done
in linux (and probably most other operating systems as well). if some of
your hardware is not reacting well to this scan there might be two reasons
for this: either your hardware does not conform to the pci standard or the
linux kernel uses a way to scan the bus which does not (but works with
most stuff without creating any odd effects).

by the way, which kernel are you using when this problem appears and does
it happen in the other branch (2.2. / 2.4. respectively) as well?

i don't think that not looking for all pci ids would really improve things
- it might provide a workaround in some cases because you can put your
hardware that reacts strangely to the scans after the modem and only scan
for your specific modem device/vendor id pair, then probably you will not
get whatever from your soundcard. but this is not in any way a clean
solution and not looking for all ids just unnecessarily splits the driver
in different id branches. by the way, this might be the reason that the
old driver didn't create the problem: afaik it was only looking for one
pci id. i don't think that this is a huge difference...

heby

--------------------------------------------------------------------------
Christoph Hebeisen             http://www.heby.de             heby@heby.de
4023 Hamilton Hall   SFU   Burnaby, BC V5A 1S6   Canada   (+1 604) 3200161
--------------------------------------------------------------------------

Webmaster: Russell Nelson
Last modified: Wed Jul 30 11:02:43 EDT 2003