[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <628CCE44.6020007@gmail.com>
Date: Tue, 24 May 2022 15:23:32 +0300
From: Eli Billauer <eli.billauer@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: Zheyu Ma <zheyuma97@...il.com>, arnd@...db.de,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] char: xillybus: Check endpoint type before allocing
On 23/05/22 20:15, Greg KH wrote:
>> Rather, it works like this: The driver uses the EP 1 IN and OUT endpoints to
>> > query the device for a data structure, which contains information on the
>> > device's communication channels. The driver sets up device files
>> > accordingly, and it also gets informed on which bulk OUT endpoints are
>> > present.
>> >
>> > For what it's worth, I think it's fairly safe to assume that if a device
>> > returns a legal data structure (which passes a CRC test), it's a XillyUSB
>> > device.
>>
> Why? You still need to verify that the requested endpoints match up
> with what the device really has.
>
OK. So to summarize:
EP 1 IN and EP 1 OUT are always present in XillyUSB devices.
On top of these, there might be additional bulk OUT endpoints. The
driver resolves which ones in setup_channels(), by scanning a data blob
it has received from the device. This takes place in the for-loop inside
this function. When (out_desc & 0x80) is true for a given @i in the
loop, the device has a bulk OUT endpoint with address i+2 (e.g. if this
condition is met for i==2, the device has a bulk OUT EP 4).
So it seems like setup_channels() would be the right place to make this
check, since it's called during the device's probe.
I guess it would likewise make sense to check for EP 1 IN and OUT in
xillyusb_setup_base_eps().
Thanks,
Eli
Powered by blists - more mailing lists