On Tue, Jan 21, 2003 at 10:43:43PM +0100, Jaroslav Kysela wrote:
> On Tue, 21 Jan 2003, Adam Belay wrote:
> > 1.) If a driver attaches to the pnpbios card all other card-based drivers will
> > be unable to use the pnpbios. One will attach and cause the others to fail. It
> > is possible for the user to have more than one pnpbios sound card but with this
> > approach such a user would only be able to use one sound device from the entire
> > pnpbios.
> I see. I think it's a design problem then. The rule card -> one driver is
> bad. We need something between card and device which will take care about
> drivers. Unfortunately, this information is dynamic (only driver knows
> which devices have to be attached).
> I think that we need to discuss this thing very carefully.
I agree that we need to discuss this carefully and that there is a need for this
change. Here are a few ideas to get a discussion started.
How does this sound...
1.) detach pnp card service matching from the driver model, the driver model is
what is imposing this one card per driver limit.
2.) create a special pnp_driver that handles cards and forwards driver model calls
to the pnp card services, we can use attach_driver to avoid matching problems.
design goals for these changes should be as follows:
1.) multiple drivers can bind to one card
2.) pnp_attach, pnp_detach, and pnp status should be phased out and replaced with
the special card driver, in other words the driver model can take care of this.
This will solve the one device limit but I'm not sure how to handle the pnpbios
stuff yet. I want it to be with as little overhead as possible and would prefer we
don't use fake cards, any ideas? All that comes to mind for me is a unique pnpbios
ID that the pnp layer will interpret and grant special exceptions.
> > 2.) Doing so would misrepresent the pnpbios topology because it physically
> > doesn't have any cards.
> > 3.) The opl3sa2 driver doesn't need a card because it is only asking for one
> > device anyway. Using the card interface puts unnecessary overhead on both the
> > driver and the pnp layer.
> Yes, but IT SHOULD WORK. Although it isn't an most efficient way. (I
> personally think that it's better to keep as much IDs as possible to avoid
> clashes in future).
Hmm, I'm not sure what you mean by clashes in the future. Nearly all of
these isapnp devices are no longer manufactured, hence these devices will
not have many future changes.
Still I do see value in describing as many ids as possible but I worry that the
extra overhead may not be worth it. This also needs to be further discussed.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 23 2003 - 22:00:28 EST