From: Felipe Balbi <balbi@kernel.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Roger Quadros <rogerq@ti.com>, b-liu@ti.com, nsekhar@ti.com,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour
In-Reply-To: <2858481.CenWEf7Gbi@avalon>
References: <1488539835-11851-1-git-send-email-rogerq@ti.com> <3028836.5DEGZBmlnn@avalon> <87bmtd1hi3.fsf@linux.intel.com> <2858481.CenWEf7Gbi@avalon>
Date: Tue, 07 Mar 2017 14:56:31 +0200
Message-ID: <878toh454w.fsf@linux.intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha256; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3170
Lines: 80

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hi,

Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:
> Hi Felipe,
>
> On Tuesday 07 Mar 2017 12:57:40 Felipe Balbi wrote:
>> Laurent Pinchart writes:
>> > On Friday 03 Mar 2017 13:17:15 Roger Quadros wrote:
>> >> On alternate setting change, webcam gadget sends us a UVC_EVENT_STREA=
MON
>> >> or UVC_EVENT_STREAMOFF event. It expects delayed status response on
>> >> STREAMON event only but doesn't expect us to send that response over =
USB.
>> >> It sends the delayed response when we issue the VIDIOC_STREAMON ioctl.
>> >>=20
>> >> So we must not send UVCIOC_SEND_RESPONSE ioctl in these cases that too
>> >> with invalid response length.
>> >=20
>> > The commit message only explains why we should not call
>> > UVCIOC_SEND_RESPONSE in response to a STREAMON event, but not why we
>> > shouldn't either in response to a STREAMOFF event. The patch is correct
>> > changing both, but I propose wording the above two paragraphs as follo=
ws.
>> >=20
>> > "uvc-gadget: Do not send Set Interface (alternate setting) response tw=
ice
>> >=20
>> > On alternate setting change, the webcam gadget sends us a
>> > UVC_EVENT_STREAMON or UVC_EVENT_STREAMOFF event. In the first case, the
>> > driver will issue a delayed status response automatically when we call
>> > the VIDIOC_STREAMON ioctl. In the second case, the driver sends the
>> > status response immediately. We must thus not send the status response
>> > manually with UVCIOC_SEND_RESPONSE in any of those cases."
>> >=20
>> > If you're fine with that I'll change the message when applying, there'=
s no
>> > need to resend the patch.
>>=20
>> I have this in my testing/fixes and was planning to send it to Greg this
>> week. I can drop it from my queue, no problem, but then let me know as
>> you would need my acked-by.
>
> This is a userspace application patch. Feel free to send it to Greg, but =
I=20
> don't think he will know what to do with it :-) Were you maybe confusing =
this=20
> patch with the kernel fix that Roger sent a few days ago ? That one shoul=
d be=20
> queued, please keep it in your tree.

heh, my bad I got confused. I thought I was revieweing the kernel patch :-p

=2D-=20
balbi

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAli+rf8ACgkQzL64meEa
mQZJHw/+I7LxngVasv7PX0n+22sMc6XnXzwHhjKDRTwua3BEa6qx6Gsi/e/DbE1p
C1Xe+6FqcPRVYZfhl6agEcWwsgKIXkbaMcFtWx7fHcuGedhxqHbUng0aN5KoXxV+
a5yzjYRXeDzqfjyUJlh50mA4zcC8jEo+JOVQsb6Jcjq+dX/jlaBIUMm+R3KIlUJY
jy4zdXOQUldxGC+AojCt4sjIbXFUsjHm9wtJjNgm8Aug0hfes7SYp/+6hiqnXH4X
3xpBsyfkI4mQb/FqYKbWIgcdjBgoFMAhF9WKAEeQ+VaL5Zhh3aBbHfS64SEBfRY+
eB013+js7GE74vbh8+VjlEW3ypQnNsch4c6tFGkmpShXZ9icSgV5Wk9yH/74WZQf
q06bOgNKGxI3S8ap/wTHj+TqCEzzQeBE1g+1Xr0yPAVXYCKACeUqp627XaV/LyJx
a6k2N1zD5E8MfddHncgxd543OBhx0+myPXA8mNoPs3ohcbLR6EVoF3jaU3C/AnWk
f7h96eEiFLr0Md7Blh8LcQ/rkNvlfHlIIOZdqN90WFYjTAS+3NtV+/rqAcM90tPv
e5jEOi4/nI3/qWO6unx6ydjhFzC0nommDXZsp4thuKdyS+zL+5Clmxbtbl+NC3uS
A/GNp8JXGossmpD+6FbVGN/9U315ZTbDJHYf0EUGucMtI5SmioI=
=4peJ
-----END PGP SIGNATURE-----
--=-=-=--