From patchwork Tue Mar 22 10:30:29 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans Verkuil X-Patchwork-Id: 8639351 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 8406F9F36E for ; Tue, 22 Mar 2016 10:30:07 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id F40BE2039D for ; Tue, 22 Mar 2016 10:30:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 187B820397 for ; Tue, 22 Mar 2016 10:30:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758502AbcCVK35 (ORCPT ); Tue, 22 Mar 2016 06:29:57 -0400 Received: from aer-iport-2.cisco.com ([173.38.203.52]:31452 "EHLO aer-iport-2.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758376AbcCVK34 (ORCPT ); Tue, 22 Mar 2016 06:29:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2595; q=dns/txt; s=iport; t=1458642595; x=1459852195; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=2/66LUKw0xCMkjRT2fJbfeLZQ9zuR1EHK8hu6AWAlTI=; b=He/KgLCwn1ndZikQ70+11Blzp3EaUJBtiUn6NuGqgj6KKY98Oejj8BMO bddKWPoFZDqcD1tzs2svquQE5vN6e+VT5kNfu1Vsa5shntLYn7eYJWCti jgRFfwTERZeZzZqKAqg3j628QOaR01I7uj9fCdDHXkPvITggPw+rYheEo 4=; X-IronPort-AV: E=Sophos;i="5.24,376,1454976000"; d="scan'208";a="633630575" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2016 10:29:54 +0000 Received: from cobaltpc1.rd.cisco.com ([10.47.79.81]) (authenticated bits=0) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u2MATrYl001203 (version=TLSv1/SSLv3 cipher=AES128-SHA256 bits=128 verify=NO); Tue, 22 Mar 2016 10:29:54 GMT From: Hans Verkuil To: linux-media@vger.kernel.org Cc: Hans Verkuil Subject: [PATCH 3/3] vidioc-dv-timings-cap.xml: explicitly state that pad and reserved should be zeroed Date: Tue, 22 Mar 2016 11:30:29 +0100 Message-Id: <1458642629-15742-4-git-send-email-hans.verkuil@cisco.com> X-Mailer: git-send-email 2.7.0 In-Reply-To: <1458642629-15742-1-git-send-email-hans.verkuil@cisco.com> References: <1458642629-15742-1-git-send-email-hans.verkuil@cisco.com> X-Authenticated-User: hansverk Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Spam-Status: No, score=-14.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY, USER_IN_DEF_DKIM_WL autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The DV_TIMINGS_CAP documentation didn't state clearly that the pad and reserved fields should be zeroed by the application. For subdev pad can be other values as well. It also mistakenly said that only drivers would have to zero the reserved field, that's not correct. Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml index a2017bf..b6f47a6 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml @@ -55,8 +55,9 @@ interface and may change in the future. - To query the capabilities of the DV receiver/transmitter applications -can call the VIDIOC_DV_TIMINGS_CAP ioctl on a video node + To query the capabilities of the DV receiver/transmitter applications initialize the +pad field to 0, zero the reserved array of &v4l2-dv-timings-cap; +and call the VIDIOC_DV_TIMINGS_CAP ioctl on a video node and the driver will fill in the structure. Note that drivers may return different values after switching the video input or output. @@ -65,8 +66,8 @@ queried by calling the VIDIOC_SUBDEV_DV_TIMINGS_CAP ioctl directly on a subdevice node. The capabilities are specific to inputs (for DV receivers) or outputs (for DV transmitters), applications must specify the desired pad number in the &v4l2-dv-timings-cap; pad -field. Attempts to query capabilities on a pad that doesn't support them will -return an &EINVAL;. +field and zero the reserved array. Attempts to query +capabilities on a pad that doesn't support them will return an &EINVAL;. struct <structname>v4l2_bt_timings_cap</structname> @@ -145,7 +146,8 @@ return an &EINVAL;. __u32 reserved[2] - Reserved for future extensions. Drivers must set the array to zero. + Reserved for future extensions. Drivers and applications must + set the array to zero. union