Re: [PATCH] smsc-ircc2: Add PnP support.

[matthieu castet]

Jean Tourrilhes wrote:
> On Thu, Nov 18, 2004 at 07:42:07PM +0100, matthieu castet wrote:
>
> > Hi,
> >
> > I had also done a pnp patch for the smsc-ircc2 and irport 3 months ago.
> > Unfortunaly I don't remember where I put the patches, certainly on the 
> > laptop that it is in my parent home.
>
>
> 	I've never seen you patches on the irda mailing list...
When I wanted to send them, I didn't find them, and after that I forgot 
them...

if you are still interested for the irport, I could try to ask someone 
to send it to me.
> > > I have a machine with nsc-ircc here so I think I'll try that too.
> > >
> > >
> > > > OnThe issue there is that if a smsc chipset has a valid PnP ID
> > > > but somehow the pnp_probe fails to set it up, then the regular probe
> > > > won't be able to configure it. This makes me nervous.
> >
> > Yes that's the problem this pnp, if the probe failed it disable the 
> > device resource.
> > When I do my patch I encounter the problem : I called pnp driver after 
> > smsc_ircc_look_for_chips, so all the resources where already reserved, 
> > and the pnp probe failed and it disable the resource, and the device 
> > found with the traditional smsc_ircc_look_for_chips doesn't work.
> >
> > So in my patch if I register pnp devices, I don't run 
> > smsc_ircc_look_for_chips like it is done for (ircc_fir>0)&&(ircc_sir>0) 
> > case.
>
>
> 	smsc_ircc_look_for_chips won't re-register the devices
> configured via PnP, as smsc_ircc_present won't be able to request the
> region. So, I don't see the problem. And you could imagine having
> multiple SMSC in the box, some PnP, some not.
Yes, it was just because it produce some warning message.
> 	Note that we could put the region check earlier, but I like
> the fact that the driver is still able to probe completely the chip
> even if the serial driver has grabbed the regions. Maybe we could
> split the difference and request the FIR region early on (so to fail
> on SMC devices already registered) and request the other ressources
> late (so as to completely probe even when serial is loaded).
>
>
> > > > On3) If the ressources are markes as disabled, you just quit
> > > > with an error. Compouded with (2), this makes me doubly
> > > > nervous. Wouldn't it be possible to forcefully enable those 
> >
> > ressources ?
> > pnp should call automatiquely pnp_activate_dev() before probing the 
> > driver, so the resource should be activated. Have you got an example 
> > where the resource wheren't activated ?
>
>
> 	No, it was more that I don't understand what PnP does for
> us. I don't have a SMS chipset to test on. Also, I would like to know
> if it remove the need of smcinit.
PnP is easy to understand ;)
When you probe a device, it will activate a device with the best 
configuration available.
When removing a device it will disable the resource of the device.
A driver could play a little with the resources configuration : try 
another configuration, but it is not really need.

Also PnP can provide several id for a device : for example for my smsc 
device, I have SMCf010 and PNP0510 or PNP0511. So in this case we should 
load the smsc driver first, otherwise for example a pnp version of 
irport could register the device and it is not available for smsc (PnP 
will see that there is a driver attached, and not give it to the smsc 
probe).


> 	Thanks, have fun...
>
> 	Jean

Matthieu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/