From: Bean Huo <huobean@gmail.com>
To: Huan Tang <tanghuan@vivo.com>, beanhuo@micron.com, bvanassche@acm.org
Cc: cang@qti.qualcomm.com, linux-scsi@vger.kernel.org,
opensource.kernel@vivo.com, richardp@quicinc.com
Subject: Re: [EXT] Re: [PATCH v2] ufs: core: Add WB buffer resize support
Date: Tue, 29 Oct 2024 11:17:15 +0100 [thread overview]
Message-ID: <330e0b7fce03b2970db80c4b73b611af220b6349.camel@gmail.com> (raw)
In-Reply-To: <20241029031114.517-1-tanghuan@vivo.com>
On Tue, 2024-10-29 at 11:11 +0800, Huan Tang wrote:
> > On 10/28/24 1:04 PM, Bean Huo wrote:
> > > Even though I don't think it's necessary to enable a Sysfs node
> > > entry
> > > for this configuration.
> >
> > Right, a motivation of why this functionality should be available
> > in sysfs is
> > missing. An explanation should be added in the patch description.
> >
> > Thanks,
> >
> > Bart.
>
> Hi Bean & Bart,
>
> Motivation: Through the sysfs upper layer code, the WB resize
> function can be used in some scenarios, or related information can be
> obtained indirectly to implement different strategies;
> What is your suggestion? sysfs? exception event? or?
>
> Thanks
> Huan
hey Huan,
What specific scenarios would require enabling a sysfs node to control
this function? Dynamically adjusting the WriteBooster (WB) size on the
fly doesn’t seem ideal to me. From my perspective, the main case for
this feature is if the OEM didn’t correctly define or set the
WriteBooster Buffer size during manufacturing. Even then, adjusting the
WB buffer size wouldn’t be a frequent need. If JEDEC has found a reason
for this feature to be accepted, isn’t there already an interface
available to configure it? Why would we need a duplicate interface for
the same purpose?
Kind regards,
Bean
next prev parent reply other threads:[~2024-10-29 10:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-26 0:44 [PATCH v2] ufs: core: Add WB buffer resize support Huan Tang
2024-10-26 17:03 ` kernel test robot
2024-10-26 17:44 ` kernel test robot
2024-10-26 19:40 ` Bean Huo
2024-10-28 18:37 ` Bart Van Assche
2024-10-28 20:04 ` [EXT] " Bean Huo
2024-10-28 20:10 ` Bart Van Assche
2024-10-28 20:17 ` Bean Huo
2024-10-29 2:53 ` Huan Tang
2024-10-29 3:11 ` Huan Tang
2024-10-29 10:17 ` Bean Huo [this message]
2024-10-29 12:03 ` Huan Tang
2024-10-29 13:18 ` Bean Huo
2024-10-29 16:56 ` Bart Van Assche
2024-10-29 18:44 ` Bean Huo
2024-10-30 9:37 ` Huan Tang
2024-10-30 15:13 ` Bean Huo
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=330e0b7fce03b2970db80c4b73b611af220b6349.camel@gmail.com \
--to=huobean@gmail.com \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=cang@qti.qualcomm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=opensource.kernel@vivo.com \
--cc=richardp@quicinc.com \
--cc=tanghuan@vivo.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