W dniu 27.02.2015 o 21:55, Felipe Balbi pisze:
On Mon, Feb 23, 2015 at 04:02:09PM +0100, Andrzej Pietrasiewicz wrote:
Non-standard requests can encode the actual interface number in a
non-standard way. For example composite_setup() assumes
that it is w_index && 0xFF, but the printer function encodes the interface
number in a context-dependet way (either w_index or w_index >> 8).
This can lead to such requests being directed to wrong functions.
This patch adds req_match() method to usb_function. Its purpose is to
verify that a given request can be handled by a given function.
If any function within a configuration provides the method and it returns
true, then it is assumed that the right function is found.
If a function uses req_match(), it should try as hard as possible to
determine if the request is meant for it.
If no functions in a configuration provide req_match or none of them
returns true, then fall back to the usual approach.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@xxxxxxxxxxx>
this regresses testusb at least on am335x:
test 14: control writes
When I tried it on odroid u3 (with dwc2) at the host side it says:
/dev/bus/usb/002/009 test 14 --> 22 (Invalid argument)
(run as root at host)
but there is no problem at the device side.
On the same board with dummy hcd the result for test 14 is:
/dev/bus/usb/002/002 test 14 --> 25 (Inappropriate ioctl for device)
(run as root at "host")
but no problem with the device.
I'm running tools/usb/testusb with -a option. Do I need some
more preparation to actually run the tests? Perhaps I don't
experience the problem because there is no attempt to
actually trigger composite_setup() call?
On the other hand I'm thinking what could be wrong with the patch
adding req_match? With the patch applied usb_function structure
has one more member, which is (1) checked for not being NULL and,
if non-NULL it is (2) dereferenced in composite_setup(). The problem
you experience might be that (1) succeeds (req_match != NULL) and
then (2) explodes, because the pointer is actually either garbage or
some other data mis-interpreted. The struct usb_function in question
is allocated with kzalloc() in both f_loopback.c:loopback_alloc()
and f_sourcesink.c:source_sink_alloc_func() so there is no way
the pointer is not initialized to NULL, so (1) should fail
in the first place. But if (1) does not fail the member in question
is non-NULL, but how could it become non-NULL if properly initialized?
The only possibilities are: explicit assignment, unintentional memory
overwrite or mismatch between headers with which your modules/and or your
kernel have been built. If you did not add explicit assignment, and
indeed you didn't, explicit assignment is out of the question. Unintentional
memory overwrite might happen with e.g. memcpy() or variants of strcpy(),
but both f_sourcesink.c and f_loopback.c do not contain any "cpy" string.
However silly this might sound, would you be able to double check
that you used consistent headers+kernel binary+module binaries?
AP
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
