From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Hans de Goede <hdegoede@redhat.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Sakari Ailus <sakari.ailus@linux.intel.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v3 1/2] media: uvcvideo: Support partial control reads
Date: Wed, 20 Nov 2024 16:53:41 +0200 [thread overview]
Message-ID: <20241120145341.GX12409@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CANiDSCvazZ4Y3OZ9X7chU-_N-4HbeQKUh23eOWkmkAxGaks2QA@mail.gmail.com>
On Wed, Nov 20, 2024 at 03:43:22PM +0100, Ricardo Ribalda wrote:
> On Wed, 20 Nov 2024 at 15:05, Laurent Pinchart wrote:
> > On Mon, Nov 18, 2024 at 05:16:51PM +0000, Ricardo Ribalda wrote:
> > > Some cameras, like the ELMO MX-P3, do not return all the bytes
> > > requested from a control if it can fit in less bytes.
> > > Eg: Returning 0xab instead of 0x00ab.
> > > usb 3-9: Failed to query (GET_DEF) UVC control 3 on unit 2: 1 (exp. 2).
> > >
> > > Extend the returned value from the camera and return it.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: a763b9fb58be ("media: uvcvideo: Do not return positive errors in uvc_query_ctrl()")
> > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> > > ---
> > > drivers/media/usb/uvc/uvc_video.c | 16 +++++++++++++++-
> > > 1 file changed, 15 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > > index cd9c29532fb0..e165850397a0 100644
> > > --- a/drivers/media/usb/uvc/uvc_video.c
> > > +++ b/drivers/media/usb/uvc/uvc_video.c
> > > @@ -76,8 +76,22 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit,
> > >
> > > ret = __uvc_query_ctrl(dev, query, unit, intfnum, cs, data, size,
> > > UVC_CTRL_CONTROL_TIMEOUT);
> > > - if (likely(ret == size))
> > > + if (ret > 0) {
> > > + if (size == ret)
> > > + return 0;
> >
> > Why is this within the ret > 0 block ? I would write
> >
> > if (likely(ret == size))
> > return 0;
> >
> > if (ret > 0) {
> >
> > > +
> > > + /*
> > > + * In UVC the data is represented in little-endian by default.
> >
> > By default, or always ?
> >
> > > + * Some devices return shorter control packages that expected
> >
> > What's a "control package" ?
>
> usb control transfers.
Ah, did you mean "packet" instead of "package" ?
> > I think you meants "than expected", not "that expected".
> >
> > > + * if the return value can fit in less bytes.
> > > + * Zero all the bytes that the device have not written.
> > > + */
> >
> > Do we want to apply this workaround to GET_INFO and GET_LEN, or can we
> > restrict it to GET_CUR, GET_MIN, GET_MAX and GET_RES ?
>
> I believe that the original behaviour before
> a763b9fb58be ("media: uvcvideo: Do not return positive errors in
> uvc_query_ctrl()")
> was used for all types. I think the safest thing to do is to go back
> to the old behaviour.
I don't see how reverting that commit would help, or how that's related
to the question at hand.
I understand the device you're dealing with shortens transfers for
integer values when they would contain leading 0x00 bytes. The
workaround should be OK when retrieving the control value or its limits
and resolution. I wonder if it would be dangerous for GET_INFO, which
retrieves a bitmask. Does the device you've tested this with skip the
MSB for GET_INFO as well ?
Conceptually GET_LEN could be similarly excluded from the workaround,
but it will never take this code path as it's a 1 byte value.
> Let me know what you prefer.
>
> > > + memset(data + ret, 0, size - ret);
> > > + dev_warn_once(&dev->udev->dev,
> > > + "UVC non compliance: %s control %u on unit %u returned %d bytes when we expected %u.\n",
> > > + uvc_query_name(query), cs, unit, ret, size);
> > > return 0;
> > > + }
> > >
> > > if (ret != -EPIPE) {
> > > dev_err(&dev->udev->dev,
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2024-11-20 14:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 17:16 [PATCH v3 0/2] media: uvcvideo: Support partial control reads and minor changes Ricardo Ribalda
2024-11-18 17:16 ` [PATCH v3 1/2] media: uvcvideo: Support partial control reads Ricardo Ribalda
2024-11-20 13:35 ` Hans de Goede
2024-11-20 14:05 ` Laurent Pinchart
2024-11-20 14:43 ` Ricardo Ribalda
2024-11-20 14:53 ` Laurent Pinchart [this message]
2024-11-20 15:26 ` Ricardo Ribalda
2024-11-18 17:16 ` [PATCH v3 2/2] media: uvcvideo: Add more logging to uvc_query_ctrl() Ricardo Ribalda
2024-11-20 13:37 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241120145341.GX12409@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=ribalda@chromium.org \
--cc=sakari.ailus@linux.intel.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®