From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0631B8488; Mon, 26 May 2025 13:49:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748267395; cv=none; b=XxFgG2eQ7vuhgzl8DS+AaYPGzxdk2wbNsW99uGNLMCEb1pz6tOn7wnEtjeAaPTIRRQ03ForDwQST6tSlQjuIAM+S4Pz04EwqEwLGzcUsTV3IUjeUsWP2n4m9zq9bzXbc6blQV/bARMDCc0isRLKZ3cDdQMds0PbIZfIkEuDl7Hc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748267395; c=relaxed/simple; bh=Qc4Sgqbf2T+yrQX/XT1DFUJuEi5rT++6daAYaJZkZgc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZxdUJ4ubqEBm5jOdlmCrfV4/Yw1vo4e+c3aZkOTEpZl82FzZlK5BAxAEzu+kgHckyEnGfIZLPHuIiVNW62k05642nnspYci3VxLGlJ2sPn1EsOoFnWHovdqcEQYgrcMrZAWhnTQuZNGH8AD4ZjW+m+YfMw5ml+BU7GfjbPuYKRM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=L0sHN1eX; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="L0sHN1eX" Received: from pendragon.ideasonboard.com (237.69-130-109.adsl-dyn.isp.belgacom.be [109.130.69.237]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 4882F982; Mon, 26 May 2025 15:49:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1748267367; bh=Qc4Sgqbf2T+yrQX/XT1DFUJuEi5rT++6daAYaJZkZgc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L0sHN1eXhZbvtpyVwO2ePCFZ7PV07C9komJeK7ZYoFN5jFzLjsh6Lm+K7VonVqVGm sF3nRc19/CZTtM/UHRGJR8pCcB6TjHrq3Ol+KFsjxAvG+4SB3aqYmaotjRSyeg5Boq D1xTp/Uu/zh8LMqCGHh45YPnjkVon9sLKZ9uNBYA= Date: Mon, 26 May 2025 15:49:46 +0200 From: Laurent Pinchart To: Ricardo Ribalda Cc: Hans de Goede , Mauro Carvalho Chehab , Guennadi Liakhovetski , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 2/4] media: Documentation: Add note about UVCH length field Message-ID: <20250526134946.GN17743@pendragon.ideasonboard.com> References: <20250404-uvc-meta-v5-0-f79974fc2d20@chromium.org> <20250404-uvc-meta-v5-2-f79974fc2d20@chromium.org> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250404-uvc-meta-v5-2-f79974fc2d20@chromium.org> Hi Ricardo, On Fri, Apr 04, 2025 at 06:37:35AM +0000, Ricardo Ribalda wrote: > The documentation currently describes the UVC length field as the "length > of the rest of the block", which can be misleading. The driver limits the > data copied to a maximum of 12 bytes. > > This change adds a clarifying sentence to the documentation to make this > restriction explicit. > > Signed-off-by: Ricardo Ribalda > --- > Documentation/userspace-api/media/v4l/metafmt-uvc.rst | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/userspace-api/media/v4l/metafmt-uvc.rst b/Documentation/userspace-api/media/v4l/metafmt-uvc.rst > index 784346d14bbdbf28348262084d5b0646d30bd1da..42599875331c0066cf529153caccb731148023b9 100644 > --- a/Documentation/userspace-api/media/v4l/metafmt-uvc.rst > +++ b/Documentation/userspace-api/media/v4l/metafmt-uvc.rst > @@ -44,7 +44,9 @@ Each individual block contains the following fields: > them > * - :cspan:`1` *The rest is an exact copy of the UVC payload header:* > * - __u8 length; > - - length of the rest of the block, including this field > + - length of the rest of the block, including this field. Please note that > + regardless of the this value, for V4L2_META_FMT_UVC the kernel will "the this value" looks like a typo. > + never copy more than 2-12 bytes. Are you saying here that length can be larger than 12, but only up to 12 bytes will be copied (when both SCR and PTS are present) ? If that's the case, it would be better to fix the driver to clamp the length value to the number of bytes actually present in the buffer. > * - __u8 flags; > - Flags, indicating presence of other standard UVC fields > * - __u8 buf[]; -- Regards, Laurent Pinchart