lkml.org 
[lkml]   [2004]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] smsc-ircc2: Add PnP support.
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.076 / U:1.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site