From: Daniil Lunev <dlunev@chromium.org>
To: Arthur Simchaev <Arthur.Simchaev@wdc.com>
Cc: James@vger.kernel.org, E.J.Bottomley@vger.kernel.org,
jejb@linux.vnet.ibm.com, Martin@vger.kernel.org,
K.Petersen@vger.kernel.org, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
Bean@vger.kernel.org, Huo@vger.kernel.org, beanhuo@micron.com
Subject: Re: [PATCH] scsi: ufs-bsg: Remove ufs_bsg_get_query_desc_size function
Date: Mon, 8 Aug 2022 09:30:07 +1000 [thread overview]
Message-ID: <YvBK/8yeohLhu2Za@google.com> (raw)
In-Reply-To: <1655727966-31584-1-git-send-email-Arthur.Simchaev@wdc.com>
On Mon, Jun 20, 2022 at 03:26:06PM +0300, Arthur Simchaev wrote:
> The bsg driver allows user space to send device management commands.
> As such, it is often used by field application engineers to debug various problems,
> and as a test bed for new features as well.
>
> Let's not bound ourself to hard coded descriptor sizes, as the new
> Descriptors that supports new features are not defined yet.
Can you clarify what you mean "hard-coded"? The descriptor size is initialized
as QUERY_DESC_MAX_SIZE, and updated in `ufshcd_update_desc_length`, which is
called with the actual size upon finishing `ufshcd_read_desc_param`.
The function you are removing - `ufs_bsg_get_query_desc_size` - doesn't seem to
reject requests on incompatible size, only to restrict the size of the query.
The way the code is written - if I read it right - will lead to truncation of
the response if the size of the requested response is less than the actual
descriptor size, but otherwise you should get full descriptor back.
Can you provide a specific example where you see the problem to arise?
Thanks,
Daniil
next prev parent reply other threads:[~2022-08-07 23:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-20 12:26 [PATCH] scsi: ufs-bsg: Remove ufs_bsg_get_query_desc_size function Arthur Simchaev
2022-07-17 11:28 ` Arthur Simchaev
2022-07-19 2:53 ` Martin K. Petersen
2022-08-07 23:30 ` Daniil Lunev [this message]
2022-08-16 14:32 ` Arthur Simchaev
2022-08-16 14:44 ` Arthur Simchaev
2022-08-24 9:36 ` Daniil Lunev
2022-09-11 10:35 ` Arthur Simchaev
2022-09-19 8:33 ` Arthur Simchaev
2022-09-20 3:16 ` Martin K. Petersen
2022-09-20 9:38 ` Bean Huo
2022-09-21 9:53 ` Arthur Simchaev
2022-09-28 8:33 ` Arthur Simchaev
2022-09-28 10:36 ` Bean Huo
2022-09-28 14:42 ` Arthur Simchaev
2022-09-28 17:01 ` Arthur Simchaev
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=YvBK/8yeohLhu2Za@google.com \
--to=dlunev@chromium.org \
--cc=Arthur.Simchaev@wdc.com \
--cc=Bean@vger.kernel.org \
--cc=E.J.Bottomley@vger.kernel.org \
--cc=Huo@vger.kernel.org \
--cc=James@vger.kernel.org \
--cc=K.Petersen@vger.kernel.org \
--cc=Martin@vger.kernel.org \
--cc=beanhuo@micron.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).