Martin Husemann <martin%duskware.de@localhost> writes: > However, it can not work with the way NetBSD uses ugen devices: > > uftdi0 at uhub3 port 2 > uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, addr 3 > ucom0 at uftdi0 portno 1 > ucom1 at uftdi0 portno 2 > > I can disable the ucom at uftdi0 portno 1, but there is no way to get a ugen > device to attach there. > > The uftdi chip itself offers a separate interface for each of the ports, > at that layer there should not be a problem. I wonder if we should be attaching drivers to endpoints, rather than devices. It seems fairly common to have multiple endpoints doing different things (among more-than-one-thing devices), rather than multiple devices behind a hub. Letting ugen attach to endpoints that drivers don't deal with seems like an entirely reasonable solution, and it seems to have lower risk of problems from things we can't predict. I also wonder what other operating systems do here (beyond point solutions that they've had to do).
Attachment:
signature.asc
Description: PGP signature