David Brownell wrote:
>
> Roman,
>
> > There are a lot of things that are endpoint specific:
>
> (endpoint in a given config/altsetting ...)
>
> > e.g. maxpacketsize, toggle bit, startingpoint and intervall
> > of INTR transfers, queueingpoint for URBs,...
> > And all that information is spread around. Some bits are in the
> > device struct some bits are in the URBs pipe slot. This can cause
> > a lot of inconsistency. E.g. the urb->dev field and the
> > usb_pipedevice (urb->pipe) can address two different devices within
> > the same URB and so on.
>
> Yes, I suspect there's trouble lurking there somewhere.
> But I suspect that phasing out the "pipe" data structure
> can't be an all-at-once thing.
>
> One could start by identifying troublesome duplication
> in the "pipe", such as usb_pipedevice(), and gradually
> replacing them with safer fields, urb->dev->devnum
> in that example, finally removing the pipe macro.
>
On the driver side the only information that has to be
supplied is the endpoint number and the direction of the
endpoint to identify the endpoint.
So the drivers should just fill in that two fields into the
pipe. Or the HCD should just read that two fields and
ignore all the others
(so there are no changes on the driver side).
To the device structure we add an array of 32 pointers to
endpoint_descriptors. This array points to the set of
all endpoints of an configuration/altsetting.
Then we extend the endpoint descriptors with some
additional fields
(hcpriv (ED for OHCI), toggle, list_head urbqueue, ...)
Now the HCDs can use endpointnumber+direction(pipe) as
an index for the endpoint descriptor array and get all the
information about the endpoint from there.
> > I think it would be better to use a more socket like approach
> > (maybe in 2.5):
>
> Major URB API cleanups, not before 2.5 for sure!
>
> > An URB is like a socket_buffer and an endpoint is like a socket.
>
> I think better analogies would be
>
> URB ~= sk_buff
> endpoint ~= port
> pipe [usb architecture] ~= connected socket
> device ~= host/peer
>
> I'm not sure what the "pipe" in the URB API corresponds to
> in either the USB architecture or the socket analogy. As you
> pointed out, it's got a mix of port, host, and QOS options ...
>
> > So the endpoint-entries would hold all that static information of an USB
> > endpoint and the URBs just points to the data blocks.
>
> That is, you're suggesting to think about replacing the "pipe" in
> an URB with a pointer to the endpoint descriptor in the current
> config+altsetting? I've had the same thought. But converting
> all the code would be a rather large job ...
>
I would replace both the pipe and the dev slots with a pointer
to the extended endpoint descriptor (ED).
(The ED has a pointer to dev)
Also the intr-interval and most of the flags are properties
of the extended endpoint descriptor.
Converting of the code is not such a large job because most
of the information of an URB/pipe is redundant. So the devices
need not care about it. USB core/HCDs should
know about it by looking at the endpoint descriptors.
- Roman
> - Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
