Jeff Garzik wrote:
>
> Michael Reinelt wrote:
> >
> > Thats clear to me. But the probe and remove routine can only be called
> > if the module is already loaded. My question was: who will load the
> > module? (I'll call it 'netmos.o')
>
> typically a hotplug agent, cardmgr in this case.
huh? ca
Michael Reinelt wrote:
>
> Jeff Garzik wrote:
> >
> > > Another (design) question: How will such a driver/module deal with
> > > autodetection and/or devfs? I don't like to specify 'alias /dev/tts/4
> > > netmos', because thats pure junk to me. What about pci hotplugging?
> >
> > pci hotplugging
On Sun, Apr 08, 2001 at 02:05:36PM +0200, Michael Reinelt wrote:
> The simple solution: Gunters 'multifunction quirks'
> clean solution #1: a new module according to Jeffs sample code
> clean solution #2: 'invisible PCI bridge' from Linus
[...]
> Suggestion: multifunction quirks for 2.4, one of t
Tim Waugh wrote:
>
> On Sat, Apr 07, 2001 at 03:40:13PM -0400, Jeff Garzik wrote:
>
> > Who said you have to have a separate driver for every single multi-IO
> > card? A single driver could support all serial+parallel multi-IO cards,
> > for example.
>
> Okay, I misunderstood. I'll take a loo
Jeff Garzik wrote:
>
> > Another (design) question: How will such a driver/module deal with
> > autodetection and/or devfs? I don't like to specify 'alias /dev/tts/4
> > netmos', because thats pure junk to me. What about pci hotplugging?
>
> pci hotplugging happens pretty much transparently. Wh
[EMAIL PROTECTED] (Tim Waugh) wrote on 07.04.01 in <[EMAIL PROTECTED]>:
> On Sat, Apr 07, 2001 at 01:23:27PM -0400, Jeff Garzik wrote:
>
> > You asked in your last message to show you code, here is a short
> > example. Note that I would love to rip out the SUPERIO code in parport
> > and make i
Linus Torvalds wrote:
> It only means that you should probably approach it as being a special
> "invisible PCI bridge", and basically have a specific driver for that
> chip that acts as a _bridge_ driver.
>
> Writing a bridge driver is not that hard: your init routine will
> instantiate the devic
In article <[EMAIL PROTECTED]>,
Michael Reinelt <[EMAIL PROTECTED]> wrote:
>
>The card shows up on the PCI bus as one device. For the card provides
>both serial and parallel ports, it will be driven by two subsystems, the
>serial and the parallel driver.
Tough. The PCI specification has a perfe
On Sat, Apr 07, 2001 at 03:40:13PM -0400, Jeff Garzik wrote:
> Who said you have to have a separate driver for every single multi-IO
> card? A single driver could support all serial+parallel multi-IO cards,
> for example.
Okay, I misunderstood. I'll take a look at doing this for 2.4.
First of
Tim Waugh wrote:
> If we have to do this, then Gunther's approach (multifunc_quirks or
> whatever) looks a lot better than having a separate driver for every
> single multi-IO card.
Who said you have to have a separate driver for every single multi-IO
card? A single driver could support all seri
Tim Waugh wrote:
>
> On Sat, Apr 07, 2001 at 01:23:27PM -0400, Jeff Garzik wrote:
>
> > You asked in your last message to show you code, here is a short
> > example. Note that I would love to rip out the SUPERIO code in parport
> > and make it a separate driver like this short, contrived exampl
On Sat, Apr 07, 2001 at 03:01:57PM +0200, Gérard Roudier wrote:
> PCI multi I/O boards _shall_ provide a separate function for each kind of
> IO. Those that donnot are kind of PCI messy IO boards.
But they don't. What are you going to do about it?
> Cheap for whom?
For the guys who make them,
On Sat, Apr 07, 2001 at 01:23:27PM -0400, Jeff Garzik wrote:
> You asked in your last message to show you code, here is a short
> example. Note that I would love to rip out the SUPERIO code in parport
> and make it a separate driver like this short, contrived example. Much
> more modular than t
On Sat, Apr 07, 2001 at 11:04:38AM +0200, Gérard Roudier wrote:
> Given your description, this board is certainly not a multi-fonction PCI
> device. Multi-function PCI devices provide separate resources for each
> function in a way that allows each function to be driven by separate
&
Michael Reinelt wrote:
> But what I want to know before I spend time (and not-earning-money :-)
> into this, I want to know: Is this the right way (TM)? How do other
> multiport cards deal with this issue?
>
> This is a specific question to the serial and parallel maintainers: are
> there cards s
Gérard Roudier wrote:
>
> > Tim Waugh wrote:
> > > > Adding PCI entries to both serial.c and parport_pc.c was that easy
> > >
> > > And that's how it should be, IMHO. There needs to be provision for
> > > more than one driver to be able to talk to any given PCI device.
> >
> > True, true, tr
Brian Gerst wrote:
> Gérard Roudier wrote:
> > Given your description, this board is certainly not a multi-fonction PCI
> > device. Multi-function PCI devices provide separate resources for each
> > function in a way that allows each function to be driven by separate
&g
Tim Waugh wrote:
>
> On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote:
>
> > Adding PCI entries to both serial.c and parport_pc.c was that easy
>
> And that's how it should be, IMHO. There needs to be provision for
> more than one driver to be able to talk to any given PCI d
On Sat, 7 Apr 2001, Michael Reinelt wrote:
> Tim Waugh wrote:
> >
> > On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote:
> >
> > > Adding PCI entries to both serial.c and parport_pc.c was that easy
> >
> > And that's how it should be, IMHO. There needs to be provision for
gt; > > both serial and parallel ports, it will be driven by two subsystems, the
> > > > serial and the parallel driver.
> > >
> > > Given your description, this board is certainly not a multi-fonction PCI
> > > device. Multi-function PCI devices provi
Tim Waugh wrote:
>
> On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote:
>
> > Adding PCI entries to both serial.c and parport_pc.c was that easy
>
> And that's how it should be, IMHO. There needs to be provision for
> more than one driver to be able to talk to any given PCI d
, the
> > > serial and the parallel driver.
> >
> > Given your description, this board is certainly not a multi-fonction PCI
> > device. Multi-function PCI devices provide separate resources for each
> > function in a way that allows each function to be driven by separa
to reboot to load
> > the new kernel), and I think I found the reason:
> >
> > The card shows up on the PCI bus as one device. For the card provides
> > both serial and parallel ports, it will be driven by two subsystems, the
> > serial and the parallel driver.
>
&g
On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote:
> Adding PCI entries to both serial.c and parport_pc.c was that easy
And that's how it should be, IMHO. There needs to be provision for
more than one driver to be able to talk to any given PCI device.
Tim.
*/
PGP signature
up on the PCI bus as one device. For the card provides
> both serial and parallel ports, it will be driven by two subsystems, the
> serial and the parallel driver.
Given your description, this board is certainly not a multi-fonction PCI
device. Multi-function PCI devices provide separate
Jeff Garzik wrote:
>
> Michael Reinelt wrote:
> > basically an extension of the pci id tables; and I hope it's in the
> > queue for the official kernel.
>
> Where is this patch available? I haven't heard of an extension to the
> pci id tables, so I wonder if it's really in the queue for the off
On Sat, Apr 07, 2001 at 04:57:29AM -0400, Jeff Garzik wrote:
> Where is this patch available? I haven't heard of an extension to the
> pci id tables, so I wonder if it's really in the queue for the official
> kernel.
It is. http://people.redhat.com/twaugh/patches/> The
'extension' is just 'mo
Michael Reinelt wrote:
> I've got a problem with my communication card: It's a PCI card with a
> NetMos chip, and it provides two serial and one parallel port. It's not
> officially supported by the linux kernel, so I wrote my own patch and
> sent it to the parallel, serial and pci maintainer. The
Hi there,
I've got a problem with my communication card: It's a PCI card with a
NetMos chip, and it provides two serial and one parallel port. It's not
officially supported by the linux kernel, so I wrote my own patch and
sent it to the parallel, serial and pci maintainer. The patch itself is
bas
29 matches
Mail list logo
