Hi Guy,
The bus number is 0 based and the port numbers are 1 based.
I decided to implement isochronous transfers today and changed the structure
slightly:
struct
{
// Control information
uint32_t frameHeaderLength; // 28
// Frame information
uint32_t frameLength; // Amount of data sent/received this frame
uint32_t frameStatus; // IOReturn result of the I/O this frame
uint64_t frameNumber; // Frame number on which this was scheduled/executed
by the controller
uint64_t ioTimestamp; // Time in which the frame completed
} __attribute__((packed, aligned (sizeof(uint32_t))));
Therefore, the isochronous format for a request with type
kAppleUSBHostPacketFilterRequestComplete is as follows:
Link Header
padding, if required to force 4-byte alignment
Isochronous Frame[0] Header (frameHeaderLength bytes in length)
Isochronous Frame[0] Data (frameLength bytes)
…
padding, if required to force 4-byte alignment
Isochronous Frame[linkHeader.ioFrameCount - 1] Header (aligned to 4 bytes,
frameHeaderLength bytes in length)
Isochronous Frame[linkHeader.ioFrameCount - 1] Data (frameLength bytes)
The isochronous format for a request with type
kAppleUSBHostPacketFilterRequestSubmit is similar (no data following the
isochronous frame header):
Link Header
padding, if required to force 4-byte alignment
Isochronous Frame[0] Header (frameHeaderLength bytes in length)
…
padding, if required to force 4-byte alignment
Isochronous Frame[linkHeader.ioFrameCount - 1] Header (aligned to 4 bytes,
frameHeaderLength bytes in length)
Non-ischronous endpoints will always have an ioFrameCount of 0.
—scott
> On Dec 11, 2016, at 6:37 PM, Guy Harris <g...@alum.mit.edu> wrote:
>
> On Dec 11, 2016, at 8:32 AM, Scott Deandrea <sdeand...@apple.com> wrote:
>
>> The deviceLocation is an Apple specific property that describes the bus
>> topology to which the device is connected. The most significant byte
>> contains the bus number; a unique value given to a host controller and also
>> used when generating the interface numbers. The following nibbles
>> correspond to the port number(s) through which the device is connected. For
>> example:
>>
>> FaceTime HD Camera (Built-in)@1a110000 <class IOUSBHostDevice, id
>> 0x10000f263, registered, matched, active, busy 0 (9 ms), retain 24>
>> The bus number is 0x1a and the camera is connected to port 1 of the hub that
>> is connected to root port 1 on the host controller.
>
> So are ports numbered from 0 or from 1? If I'm reading 8.9.3 "Port Number"
> correctly:
>
> The specific port on a hub to which the packet is directed is
> identified by the value in the Route String Port field. When addressing the
> hub controller then the Port Number field at the hub’s tier level shall be
> set to zero in the Route String. The hub’s downstream ports are addressed
> beginning with one and count up sequentially.
>
> that would indicate that they're numbered from 1, so that a port number of 0
> indicates the end of the route.
>
>> The ioFrameCount field, though not currently supported, is intended to be
>> used for isochronous endpoints as their I/O model is slightly different in
>> that you pass down a vector describing I/O for multiple USB frames. On
>> completion you would receive the header followed by and ioFrameCount array
>> of isochronous header followed by the packet data. The isochronous header
>> is currently defined as follows:
>> struct
>> {
>> // Control information
>> uint32_t frameHeaderLength;
>>
>> // Frame information
>> uint32_t frameLength;
>> uint64_t frameNumber;
>> uint64_t ioTimestamp;
>> } __attribute__((packed, aligned (sizeof(uint32_t))));
>
> So the frameHeaderLength would be 24 in the current version (the length of
> that structure), and the data for the first frame would start right after the
> header and go on for array[0].frameLength bytes, with the data for the second
> frame starting right after than and going on for array[1].frameLength bytes,
> and so on?
>
> Presumably that field would be ignored if the endpoint isn't an isochronous
> endpoint, right?
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
