Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 15 Jul 2022 17:25:40 -0400
From:   Rodrigo Vivi <rodrigo.vivi@intel.com>
To:     Mauro Carvalho Chehab <mchehab@kernel.org>
CC:     Thomas =?iso-8859-1?Q?Hellstr=F6m?= 
        <thomas.hellstrom@linux.intel.com>,
        David Airlie <airlied@linux.ie>,
        <dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
        Chris Wilson <chris@chris-wilson.co.uk>,
        Matthew Auld <matthew.auld@intel.com>,
        <intel-gfx@lists.freedesktop.org>,
        Christian =?iso-8859-1?Q?K=F6nig?= <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [PATCH v2 20/39] drm/i915: i915_gem_wait.c: fix a
 kernel-doc markup
Message-ID: <YtHbVHVvHjLTMIe3@intel.com>
References: <cover.1657699522.git.mchehab@kernel.org>
 <7506a4fc57d2bf064f6a35d70c8cd7885082863e.1657699522.git.mchehab@kernel.org>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7506a4fc57d2bf064f6a35d70c8cd7885082863e.1657699522.git.mchehab@kernel.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?KsuUfPDHlVuR5Q8h9JeIoYbSx8LsCNuPGBvsneiV6nN5cceLROFshbRUqYjd?=
 =?us-ascii?Q?Wf09gtT2SF48KfCd80yTV+XOM3/eO1HlL8vrV7tga7JxApFJtNmUNsw0wJKA?=
 =?us-ascii?Q?QTGf+IFJrOdFjhyUh66qA5M1MQW/0/gM5F2WHIbsNbxNcpfBXlHEvkTPax2s?=
 =?us-ascii?Q?J5vTcwrvGlg1pewRfV2ORk5C/ZiugSCqdmypoobw87Xhq/Z9bBWf/53XCgBN?=
 =?us-ascii?Q?h54pevoCkvWCXbSy+nQOMfn11ORgduiRE0JNuJ4Wb9I67mfQWy+c1MyZwmpi?=
 =?us-ascii?Q?BBhs6a7ZUC1d465EeCbqyUqmt6Oaw6CRDokSgTDNJKfIbo04o/U67OK28Ffk?=
 =?us-ascii?Q?3ERCn20Ma+Wtk3RR6aK4o4nUl457KzbHyAA6/V9cF8KLkBuACK/tSz+L+DEz?=
 =?us-ascii?Q?ElnUZL81h+RaWkh/Uga9dNUg6cwEt3Btu+igzbEY2hLyVYLF3snBA6A38iwj?=
 =?us-ascii?Q?sCikrDHNY38sWzrdjmFw0x4vQvzviFNbK7ezqO0V3+Cmx7AE+PEnzsIjTuco?=
 =?us-ascii?Q?JKmjMVEC2+pxzsmzF4SRgL5H/teR6eTfl2iH1naM+/PZXe9t6s5+VZxPCYqx?=
 =?us-ascii?Q?V5SgRipds5THLjDFcgaTw4M9CNDSe5ucv3O/J8dKClDnIAJa1hFQWOVP6FWI?=
 =?us-ascii?Q?L8O02NU0L/y9xGtOO13rd3edFQmP5UQ4FZrKn3soD6oFZSmjyozPlxTvo6uX?=
 =?us-ascii?Q?lgH6kzU/dFh2FhINdxnyizWq7JRrH+MLeDRqniqHtV0WAIaDUn6C7KWqmAT6?=
 =?us-ascii?Q?VxETlfvHycUU9h0WaNASly53wz7o6dUHmSoefyy8qlj//PMsa5um/a6A3M8j?=
 =?us-ascii?Q?148dMszw/V5Y1BgBYvDlb5WqBFikTMS+lx8CZVOOYs+y4WzZgZ50Vb672cGd?=
 =?us-ascii?Q?j7+obMfKm/DWt1ALTNTtRPH0tGhrK6umCk2AqadU4ZY9eeqfFQl29T25VQE/?=
 =?us-ascii?Q?vMBwEg3VxQP6use5w5cH1GPhddOwXu7BMA1CE9G+oH1FG/ZyRTM70mnRdhIy?=
 =?us-ascii?Q?z8/sIdS+iUBfuu8pDXg42MI722sgwhy/B8RWK5RcFwgp2zNcaHRH+HbjOCud?=
 =?us-ascii?Q?Pfy5aMdXCgxGMxLnxx2ZT04d4R4/lRNUsvymNBl8A/7PNBUwVN6gXr0ctpFe?=
 =?us-ascii?Q?Tt0BJphE6HnpZB9wdLDATrwmxvJ8NIIrpJqS0YV6/Wr7eXr78Pq+nxE2LJWT?=
 =?us-ascii?Q?RyW2ERlkzz5mB+ZdnQZZ/eybptDCWyBBaloPIcQp26bvlbD10AaLlArcoI/u?=
 =?us-ascii?Q?plUfbA3bHZ597VNxQu4uDxWlmCjwphRIGKBx71T6J/KlCwPpiMnv+xQhob8t?=
 =?us-ascii?Q?8Yz3IafoEKNp92KFxDbmgDhKDHtToj+W9Qv/GWc2lIN0an7gFoQ/i9gmHKZk?=
 =?us-ascii?Q?ERasqnHjbBNpjZ/Ho1tWR3t6/X13IcrEB25Eyx/yz0SpO2tANb0OzmPlmWqT?=
 =?us-ascii?Q?Sdpcw6TojlSzMojlxM8MZaHKNG9VNDeZ0wGir/NeHhAuozWFa87huC895LSQ?=
 =?us-ascii?Q?GJ+3eThGJZhTpYEwd9GijD31SkE5+kRBlIqCBMI1T3E0KMe9IqnsNZmZ5/eb?=
 =?us-ascii?Q?V82V2Z9szQIv0LCG45HZAsU182SvwACLean5I4YXcjveMmnYDOpAhYGnykjO?=
 =?us-ascii?Q?9g=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 0fb68bd2-2458-4554-16b0-08da66a893d1
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6059.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2022 21:25:44.9494
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: l+WfxEZ0KlZ29uF/Ih147Af5yPN6IE5J1rkA2t+4MjEbu8XhYYRbBhuRgwWOMl8DgFJG+pKJC6Nqk95DuqHFcA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB2028
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jul 13, 2022 at 09:12:08AM +0100, Mauro Carvalho Chehab wrote:
> The return codes for i915_gem_wait_ioctl() have identation issues,
> and will be displayed on a very confusing way. Use lists to improve
> its output.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover.
> See [PATCH v2 00/39] at: https://lore.kernel.org/all/cover.1657699522.git.mchehab@kernel.org/
> 
>  drivers/gpu/drm/i915/gem/i915_gem_wait.c | 24 +++++++++++++-----------
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> index 4a33ad2d122b..1fd5cff552ed 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> @@ -210,23 +210,25 @@ static unsigned long to_wait_timeout(s64 timeout_ns)
>   * @data: ioctl data blob
>   * @file: drm file pointer
>   *
> - * Returns 0 if successful, else an error is returned with the remaining time in
> - * the timeout parameter.
> - *  -ETIME: object is still busy after timeout
> - *  -ERESTARTSYS: signal interrupted the wait
> - *  -ENONENT: object doesn't exist
> - * Also possible, but rare:
> - *  -EAGAIN: incomplete, restart syscall
> - *  -ENOMEM: damn
> - *  -ENODEV: Internal IRQ fail
> - *  -E?: The add request failed
> - *
>   * The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
>   * non-zero timeout parameter the wait ioctl will wait for the given number of
>   * nanoseconds on an object becoming unbusy. Since the wait itself does so
>   * without holding struct_mutex the object may become re-busied before this
>   * function completes. A similar but shorter * race condition exists in the busy
>   * ioctl
> + *
> + * Returns:
> + * 0 if successful, else an error is returned with the remaining time in
> + * the timeout parameter.
> + * * -ETIME: object is still busy after timeout
> + * * -ERESTARTSYS: signal interrupted the wait
> + * * -ENONENT: object doesn't exist
> + *
> + * Also possible, but rare:
> + * * -EAGAIN: incomplete, restart syscall
> + * * -ENOMEM: damn
> + * * -ENODEV: Internal IRQ fail
> + * * -E?: The add request failed
>   */
>  int
>  i915_gem_wait_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
> -- 
> 2.36.1
>