From: sashiko-bot@kernel.org
To: "Shawn Lin" <shawn.lin@rock-chips.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v3 1/2] scsi: ufs: core: Move the device initialization sequence into a new function
Date: Mon, 02 Nov 2026 02:37:26 +0000 [thread overview]
Message-ID: <sashiko-outbox-192840@kernel.org> (raw)
In-Reply-To: <20261102022154.3903115-2-shawn.lin@rock-chips.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] scsi: ufs: core: inaccurate return doc on ufshcd_full_device_init()
--
commit 92840cc6e92324af86954d841a38c89351f13122
Author: Shawn Lin <shawn.lin@rock-chips.com>
scsi: ufs: core: Move the device initialization sequence into a new function
This commit factors the link startup and device initialization steps out of
ufshcd_init() into a new helper function, ufshcd_full_device_init(), so that
the sequence can be retried as a unit.
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index fd52deb72d21c..8a8083a8f024e 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -11215,6 +11215,55 @@ static int ufshcd_add_scsi_host(struct ufs_hba *hba)
> return err;
> }
>
> +/**
> + * ufshcd_full_device_init - Link startup and full device initialization
> + * @hba: per-adapter instance
> + *
> + * Execute the whole device initialization sequence used during driver
> + * probe: link startup, MCQ configuration, device verification, device
> + * initialization completion and device parameter setup.
> + *
> + * Return: 0 upon success; < 0 upon failure.
> + */
> +static int ufshcd_full_device_init(struct ufs_hba *hba)
[Severity: Low]
This isn't a bug, but is the Return description accurate?
ufshcd_full_device_init() directly returns the status of
ufshcd_link_startup(), ufshcd_verify_dev_init(), ufshcd_complete_dev_init(),
ufshcd_device_params_init(), and ufshcd_post_device_init(). Several of these
callees can return positive (> 0) UFS OCS or UIC hardware status codes on
failure, which is why ufshcd_init() normalizes positive error codes at
out_error:
drivers/ufs/core/ufshcd.c:ufshcd_init() {
...
out_error:
return err > 0 ? -EIO : err;
}
Should the kernel-doc comment note that non-zero (or < 0 and > 0) values are
returned upon failure?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261102022154.3903115-1-shawn.lin@rock-chips.com?part=1
next prev parent reply other threads:[~2026-11-02 2:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 2:21 [PATCH v3 0/2] Retry the full device init on fatal link loss Shawn Lin
2026-11-02 2:21 ` Shawn Lin
2026-11-02 2:21 ` [PATCH v3 1/2] scsi: ufs: core: Move the device initialization sequence into a new function Shawn Lin
2026-11-02 2:21 ` Shawn Lin
2026-11-02 2:37 ` sashiko-bot [this message]
2026-11-02 2:21 ` [PATCH v3 2/2] scsi: ufs: core: Retry the full device init on fatal link loss Shawn Lin
2026-11-02 2:21 ` Shawn Lin
2026-11-02 2:50 ` sashiko-bot
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=sashiko-outbox-192840@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shawn.lin@rock-chips.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.