From: Michael Tokarev <mjt@tls.msk.ru>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: lkml <linux-kernel@vger.kernel.org>, linux-parport@lists.infradead.org
Subject: Re: [PATCH] Netmos parallel/serial/combo support
Date: Fri, 25 Mar 2005 03:21:16 +0300 [thread overview]
Message-ID: <4243597C.7090800@tls.msk.ru> (raw)
In-Reply-To: <1111702349.25455.15.camel@eeyore>
Bjorn Helgaas wrote:
[]
>>I've a 9835 card with two serial and no parallel ports:
>>
>>0000:01:00.0 0700: 9710:9835 (rev 01) (prog-if 02)
>> Subsystem: 1000:0002
[]
>>But after reloading parport_pc, it does not see the built-in
>>port anymore; more, after unloading 8250_pci and 8250,
>>parport_pc finds one parallel port -- on this netmos
>>card only (there's no parallel port on this card):
>>
>>PCI parallel port detected: 9710:9835, I/O at 0x9800(0x9400)
>>parport0: PC-style at 0x9800 (0x9400) [PCSPP,TRISTATE]
>
> Hmmm... Do you have an init script or something that pokes
> 9835 into /sys/bus/pci/drivers/parport_pc/new_id? If not,
> I don't see how parport_pc could claim your 9835, since it's
> not compiled into parport_pc_pci_tbl. It looks like you
> should be able to turn off the new_id functionality by
> disabling CONFIG_HOTPLUG.
Well, I do see how parport_pc is claiming the device.
This is the chunk from your patch I applied manually,
or, rather, didn't apply at all because the change was
about re-ordering stuff only.
It did not apply because the two IDs - 9735 and 9835 -
are still present in 2.6.11 kernel. Your mention about
parport_pc_pci_tbl[] made me realize that I applied the
patch incorrectly. So I finally found the two devices
aren't present in Linus rc1 tree, and removed them here
too (so that parport_pc.c reordering of your patch now
applies too).
With that change, parport_pc does not claim the device
anymore, which is the right behaviour, -- ie, for 9835
card, looks like everything works just fine now. So
please treat this my report as a success story about
netmos cards support... and thank you for your work!..
The problem with built-in port and parport_pc reloading
still exists (or seems to be), even after applying the
rest of parport_pc changes which are in Linus rc1. But..
after modifying all those files several times, I can't
be sure it wasn't my fault again. I will try to repatch
and recompile it all tomorrow. Here's how it looks
like now:
# modprobe parport_pc
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP]
# rmmod parport_pc
pnp: Device 00:07 disabled.
# modprobe parport_pc
pnp: Device 00:07 activated.
parport: PnPBIOS parport detected.
pnp: Device 00:07 disabled.
... and so on - no parport0 anymore.
/mjt
prev parent reply other threads:[~2005-03-25 0:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-22 23:14 [PATCH] Netmos parallel/serial/combo support Bjorn Helgaas
2005-03-24 20:40 ` Michael Tokarev
2005-03-24 22:12 ` Bjorn Helgaas
2005-03-25 0:21 ` Michael Tokarev [this message]
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=4243597C.7090800@tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=bjorn.helgaas@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parport@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.