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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox