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

[matthieu castet <castet.matthieu@free.fr>]

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