From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A37CFECAAA1 for ; Mon, 12 Sep 2022 01:22:27 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 532B710E09C; Mon, 12 Sep 2022 01:22:26 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 92A2B10E09C; Mon, 12 Sep 2022 01:22:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662945743; x=1694481743; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=d23CLNofMYNRbKJhNQOOuRrVPflbS1+3REmtjGgHoKs=; b=W3X5WV+0C6O2cbc9wm3UBmLwLcBJOldjU94/7/mimBHda26XtqycrScz xIsmx3+1ECGBOWc9AeFAi1D+URQUKlLVVMGk9TqcPLN4Tc6cRJ7apBH8m FUQxGlbmkXbCSJWpSs5uHR5OIGJ/JQRzebdKTqs1DlTx4u6KxENBpBDa4 ZlPEijfh6eMa4L4QhYAYeqBqvRwz6UqsccxNYTZlcrExQC0xUrEdZnDp8 Dd7/qwUo1/LxpoW2WyGUUxa4Ts3QX0hH1VU+O+vj7Bdpl6hjW4nQ7lJP4 gKiARCIrPhiEPWznKH6LJklndZ2cAzbw04n5PI2OH1+Qkce4MNdJJV3ou w==; X-IronPort-AV: E=McAfee;i="6500,9779,10467"; a="323994511" X-IronPort-AV: E=Sophos;i="5.93,308,1654585200"; d="scan'208";a="323994511" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2022 18:22:22 -0700 X-IronPort-AV: E=Sophos;i="5.93,308,1654585200"; d="scan'208";a="677895905" Received: from dasegal-mobl.amr.corp.intel.com (HELO intel.com) ([10.249.46.19]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2022 18:22:18 -0700 Date: Mon, 12 Sep 2022 03:22:16 +0200 From: Andi Shyti To: Mauro Carvalho Chehab Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Intel-gfx] [PATCH v3 17/37] drm/i915: i915_gem_wait.c: fix a kernel-doc markup X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thomas =?iso-8859-15?Q?Hellstr=F6m?= , David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, Chris Wilson , dri-devel@lists.freedesktop.org, Daniel Vetter , Rodrigo Vivi , Christian =?iso-8859-15?Q?K=F6nig?= Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Hi Mauro, On Fri, Sep 09, 2022 at 09:34:24AM +0200, 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. > > Reviewed-by: Rodrigo Vivi > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Andi Shyti Andi > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. > See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.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.37.3 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EBD24ECAAD3 for ; Mon, 12 Sep 2022 01:22:32 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 11FB410E0A7; Mon, 12 Sep 2022 01:22:27 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 92A2B10E09C; Mon, 12 Sep 2022 01:22:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662945743; x=1694481743; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=d23CLNofMYNRbKJhNQOOuRrVPflbS1+3REmtjGgHoKs=; b=W3X5WV+0C6O2cbc9wm3UBmLwLcBJOldjU94/7/mimBHda26XtqycrScz xIsmx3+1ECGBOWc9AeFAi1D+URQUKlLVVMGk9TqcPLN4Tc6cRJ7apBH8m FUQxGlbmkXbCSJWpSs5uHR5OIGJ/JQRzebdKTqs1DlTx4u6KxENBpBDa4 ZlPEijfh6eMa4L4QhYAYeqBqvRwz6UqsccxNYTZlcrExQC0xUrEdZnDp8 Dd7/qwUo1/LxpoW2WyGUUxa4Ts3QX0hH1VU+O+vj7Bdpl6hjW4nQ7lJP4 gKiARCIrPhiEPWznKH6LJklndZ2cAzbw04n5PI2OH1+Qkce4MNdJJV3ou w==; X-IronPort-AV: E=McAfee;i="6500,9779,10467"; a="323994511" X-IronPort-AV: E=Sophos;i="5.93,308,1654585200"; d="scan'208";a="323994511" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2022 18:22:22 -0700 X-IronPort-AV: E=Sophos;i="5.93,308,1654585200"; d="scan'208";a="677895905" Received: from dasegal-mobl.amr.corp.intel.com (HELO intel.com) ([10.249.46.19]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2022 18:22:18 -0700 Date: Mon, 12 Sep 2022 03:22:16 +0200 From: Andi Shyti To: Mauro Carvalho Chehab Subject: Re: [PATCH v3 17/37] drm/i915: i915_gem_wait.c: fix a kernel-doc markup Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thomas =?iso-8859-15?Q?Hellstr=F6m?= , Andi Shyti , Tvrtko Ursulin , David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, Chris Wilson , dri-devel@lists.freedesktop.org, Rodrigo Vivi , Christian =?iso-8859-15?Q?K=F6nig?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Mauro, On Fri, Sep 09, 2022 at 09:34:24AM +0200, 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. > > Reviewed-by: Rodrigo Vivi > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Andi Shyti Andi > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. > See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.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.37.3 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7944EC54EE9 for ; Mon, 12 Sep 2022 01:22:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229565AbiILBW1 (ORCPT ); Sun, 11 Sep 2022 21:22:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229459AbiILBWZ (ORCPT ); Sun, 11 Sep 2022 21:22:25 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 927E822512 for ; Sun, 11 Sep 2022 18:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662945743; x=1694481743; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=d23CLNofMYNRbKJhNQOOuRrVPflbS1+3REmtjGgHoKs=; b=W3X5WV+0C6O2cbc9wm3UBmLwLcBJOldjU94/7/mimBHda26XtqycrScz xIsmx3+1ECGBOWc9AeFAi1D+URQUKlLVVMGk9TqcPLN4Tc6cRJ7apBH8m FUQxGlbmkXbCSJWpSs5uHR5OIGJ/JQRzebdKTqs1DlTx4u6KxENBpBDa4 ZlPEijfh6eMa4L4QhYAYeqBqvRwz6UqsccxNYTZlcrExQC0xUrEdZnDp8 Dd7/qwUo1/LxpoW2WyGUUxa4Ts3QX0hH1VU+O+vj7Bdpl6hjW4nQ7lJP4 gKiARCIrPhiEPWznKH6LJklndZ2cAzbw04n5PI2OH1+Qkce4MNdJJV3ou w==; X-IronPort-AV: E=McAfee;i="6500,9779,10467"; a="284786729" X-IronPort-AV: E=Sophos;i="5.93,308,1654585200"; d="scan'208";a="284786729" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2022 18:22:22 -0700 X-IronPort-AV: E=Sophos;i="5.93,308,1654585200"; d="scan'208";a="677895905" Received: from dasegal-mobl.amr.corp.intel.com (HELO intel.com) ([10.249.46.19]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Sep 2022 18:22:18 -0700 Date: Mon, 12 Sep 2022 03:22:16 +0200 From: Andi Shyti To: Mauro Carvalho Chehab Cc: Christian =?iso-8859-15?Q?K=F6nig?= , Rodrigo Vivi , Thomas =?iso-8859-15?Q?Hellstr=F6m?= , Andi Shyti , Chris Wilson , Daniel Vetter , David Airlie , Jani Nikula , Joonas Lahtinen , Maarten Lankhorst , Tvrtko Ursulin , dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 17/37] drm/i915: i915_gem_wait.c: fix a kernel-doc markup Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mauro, On Fri, Sep 09, 2022 at 09:34:24AM +0200, 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. > > Reviewed-by: Rodrigo Vivi > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Andi Shyti Andi > --- > > To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. > See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.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.37.3