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

From: matthieu castet (castet.matthieu_at_free.fr)
Date: 11/18/04

  • Next message: Adam Heath: "Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0"
    Date:	Thu, 18 Nov 2004 20:49:50 +0100
    To: jt@hpl.hp.com
    
    

    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/


  • Next message: Adam Heath: "Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.28-0"

    Relevant Pages