>
> Signed-off-by: Can Guo
> Reviewed-by: Hongwu Su
Reviewed-by: Bean Huo
Can,
> Since WB feature has been added, WB related sysfs entries can be accessed
> even when an UFS device does not support WB feature. In that case, the
> descriptors which are not supported by the UFS device may be wrongly reported
> when they are accessed from their corrsponding sysfs entries.
>
> If UFS device is not qualified to enter the detection of WriteBooster probing
> by
> disallowed UFS version or device quirks, then WriteBooster capability in host
> shall be disabled to prevent any WriteBooster operations in the future.
>
> Fixes: 3d17b9b5ab11 ("scsi: ufs: Add write booster
Hi, Dinghao
> Thank you for your advice! Moving original pm_runtime_put_sync() to after
> "out" label will influence an error path branched from
> ups_bsg_verify_query_size(). So I think changing "goto out" to "break" is a
> good
> idea. But in this case we may execute an extra
> sg_copy_from_buf
> 1 file changed, 3 insertions(+), 1 deletion(-)
Hi, Dinghao
>
> diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c index
> 53dd87628cbe..516a7f573942 100644
> --- a/drivers/scsi/ufs/ufs_bsg.c
> +++ b/drivers/scsi/ufs/ufs_bsg.c
> @@ -106,8 +106,10 @@ static int ufs_bsg_request(s
> From: Stanley Chu
> Sent: Monday, May 4, 2020 4:56 PM
> To: linux-s...@vger.kernel.org; martin.peter...@oracle.com;
> avri.alt...@wdc.com; alim.akh...@samsung.com; j...@linux.ibm.com;
> asuto...@codeaurora.org
> Cc: Bean Huo (beanhuo) ; c...@codeaurora.org;
> matthias..
> > > @@ -8441,7 +8441,8 @@ int ufshcd_init(struct ufs_hba *hba, void
> > > __iomem *mmio_base, unsigned int irq)
> > > if ((hba->ufs_version != UFSHCI_VERSION_10) &&
> > > (hba->ufs_version != UFSHCI_VERSION_11) &&
> > > (hba->ufs_version != UFSHCI_VERSION_20) &&
> > > - (hba->uf
>
> +/* WriteBooster buffer type */
> +enum {
> + WB_TYPE_LU_DEDICATED= 0x0,
> + WB_TYPE_SINGLE_SHARED = 0x1
> +};
Hi, Stanly
WB_TYPE_SINGLE_SHARED might be WB_TYPE_SHARED_BUFFER. I think,
we should try to make the name definition correspond to Spec
thanks,
Bean
> -Original Message-
> From: Stanley Chu
> Sent: Tuesday, April 28, 2020 1:14 PM
> To: linux-s...@vger.kernel.org; martin.peter...@oracle.com;
> avri.alt...@wdc.com; alim.akh...@samsung.com; j...@linux.ibm.com;
> asuto...@codeaurora.org
> Cc: Bean Huo (beanhuo)
> -Original Message-
> From: Stanley Chu
> Sent: Tuesday, April 28, 2020 1:14 PM
> To: linux-s...@vger.kernel.org; martin.peter...@oracle.com;
> avri.alt...@wdc.com; alim.akh...@samsung.com; j...@linux.ibm.com;
> asuto...@codeaurora.org
> Cc: Bean Huo (beanhuo)
> -Original Message-
> From: Stanley Chu
> Sent: Tuesday, April 28, 2020 1:14 PM
> To: linux-s...@vger.kernel.org; martin.peter...@oracle.com;
> avri.alt...@wdc.com; alim.akh...@samsung.com; j...@linux.ibm.com;
> asuto...@codeaurora.org
> Cc: Bean Huo (beanhuo)
Hi, Can Guo
Actually, we already have DME_RESET, this is not enough for Qualcomm host?
Thanks,
//Bean
>
> Some UFS host controllers need their specific implementations of resetting to
> get them into a good state. Provide a new vops to allow the platform driver to
> implement this own reset op
>
>Reviewed-by: Alim Akhtar
>Signed-off-by: Bjorn Andersson
Reviewed-by: Bean Huo
//Bean Huo
From: Bean Huo
This patch is to change msleep() to usleep_range() based on
Documentation/timers/timers-howto.txt. It suggests using
usleep_range() for small msec(1ms - 20ms) since msleep()
will often sleep longer than desired value.
After changing, booting time will be 5ms-10ms faster than befor
From: Bean Huo
In the case of UPIU/DME request execution failed in UFS device,
ufs_bsg_request() will complete this failed bsg job by calling
bsg_job_done(). Meanwhile, it returns this error status to blk-mq
layer, then triggers blk-mq completing this request again, this will
cause below panic.
From: Bean Huo
Correct dev_dbg to dev_err, so as to print out the error
information in case of DME command failed.
Signed-off-by: Bean Huo
---
drivers/scsi/ufs/ufs_bsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.
From: Bean Huo
This series patch is to fix several typos and fix one issue of twice
completing ufs-bsg job in case of UPIU/DME command failed.
Changed since v1:
- split v1 patch
- add fixes tag
- delete needless blank line
Bean Huo (3):
scsi: ufs: fix typos in comment of ufshcd_
From: Bean Huo
In the case of UPIU/DME request execution failed in UFS device,
ufs_bsg_request() will complete this failed bsg job by calling
bsg_job_done(). Meanwhile, it returns this error status to blk-mq
layer, then trigger blk-mq complete this request again, this will
cause below panic.
[
Hi, Bjorn
Sorry just saw your message.
You can use UIC command,through function ufshcd_send_uic_cmd( ) with
UIC_CMD_DME_END_PT_RST command.
DME_ENDPOINTRESET: It is used when UFS host wants the UFS device to perform a
reset.
//bean
>On Tue 11 Jun 09:08 PDT 2019, Bean Huo (beanhuo) wr
Hi, Bjorn
This HW reset is dedicated to QUALCOMM based platform case.
how about adding a SW reset as to be default reset routine if platform doesn't
support HW reset?
>-Original Message-
>From: linux-scsi-ow...@vger.kernel.org
>On Behalf Of Bjorn Andersson
>Sent: Saturday, June 8, 2019 7
vger.kernel.org
>Subject: Re: [EXT] [PATCH 2/3] scsi: ufs: Allow resetting the UFS device
>
>On Tue 04 Jun 01:13 PDT 2019, Bean Huo (beanhuo) wrote:
>> >@@ -6159,6 +6179,9 @@ static int ufshcd_reset_and_restore(struct
>> >ufs_hba
>> >*hba)
>> &
Hi, Bjorn
>Acquire the device-reset GPIO and toggle this to reset the UFS device during
>initialization and host reset.
>
>+/**
>+ ufshcd_device_reset() - toggle the (optional) device reset line
>+ * @hba: per-adapter instance
>+ *
>+ * Toggles the (optional) reset line to reset the attached devic
Hi, Avri
>
>Signed-off-by: Avri Altman
Acked-by: Bean Huo
Thanks,
//Bean
Hi, Vignesh
>
>Cadence OSPI controller IP supports Octal IO (x8 IO lines), It also has an
>integrated PHY. IP register layout is very similar to existing QSPI IP except
>for
>additional bits to support Octal and Octal DDR mode. Therefore, extend
>current driver to support Octal mode. Only Octal S
>> git send-email 0001-mtd-spi-nor-Fix-wrong-abbreviation-HWCPAS.patch
>> 0001-mtd-spi-nor-Fix-wrong-abbreviation-HWCPAS.patch
>
>git send-email --annotate --to=... --cc=... --cc=... 000*patch
>
>This will likely make your life easier, rather than having to paste various
>email
>addresses to git s
Subject: [RESEND PATCH v2] mtd: spi-nor: Fix wrong abbreviation HWCPAS
Date: Fri, 8 Feb 2019 18:00:12 +
Message-Id: <20190208180012.25852-1-bean...@micron.com>
X-Mailer: git-send-email 2.17.1
Result: OK
>
>Hi Bean,
>
>On Fri, 8 Feb 2019 17:13:52 +
>"Bean Huo (be
From: Bean Huo
Change SNOR_HWCPAS_READ_OCTAL to SNOR_HWCAPS_READ_OCTAL.
Signed-off-by: Bean Huo
---
include/linux/mtd/spi-nor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
2353af8..b3d360b 100644
--- a/inc
Hi, Tutor
Thanks. unfortunately, it doesn't work on my side. Problem is on our email
server side, not my local setting.
I followed your configuration, then git-email failed.
Please just change my S-o-b to 'Bean Huo (beanhuo) ' in my
patch to please checkpacth.pl. It is not huge
Hi, Tutor
>$ ./scripts/checkpatch.pl --strict
>v2-mtd-spi-nor-Fix-wrong-abbreviation-HWCPAS.patch
>WARNING: Missing Signed-off-by: line by nominal patch author 'Bean Huo
>(beanhuo) '
>
I think, this is because of our email system, it always adds '(xxx)' betwee
:23 PM, Bean Huo (beanhuo) wrote:
>> Change SNOR_HWCPAS_READ_OCTAL to SNOR_HWCAPS_READ_OCTAL.
>>
>> Signed-off-by: Bean Huo
>
>$ ./scripts/checkpatch.pl --strict
>v2-mtd-spi-nor-Fix-wrong-abbreviation-HWCPAS.patch
>WARNING: Missing Signed-off-by: line by nominal patch au
Change SNOR_HWCPAS_READ_OCTAL to SNOR_HWCAPS_READ_OCTAL.
Signed-off-by: Bean Huo
---
include/linux/mtd/spi-nor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 2353af8..b3d360b 100644
--- a/include/linux/mtd/spi
t, you can check how were prefixed previous patches on the same file by
>running something like:
>
>git log --oneline include/linux/mtd/spi-nor.h
>
>On 02/07/2019 03:46 PM, Bean Huo (beanhuo) wrote:
>>
>
>This looks like a blank line, it's not needed, remove it please
Maybe this is wrong abbreviation, change from HWCPAS to HWCAPS.
Signed-off-by: Bean Huo
---
include/linux/mtd/spi-nor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index fa2d89e..5e12bf9 100644
--- a/include/linu
>-Original Message-
>From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>ow...@vger.kernel.org] On Behalf Of Avri Altman
>Sent: Sunday, January 27, 2019 8:08 AM
>To: James E.J. Bottomley ; Martin K. Petersen
>; linux-s...@vger.kernel.org; linux-
>ker...@vger.kernel.org; Evan Green
>
>Signed-off-by: Avri Altman
>Reviewed-by: Evan Green
Reviewed-by: Bean Huo
t;- uint8_t *desc_buff, int *desc_len,
>- enum query_opcode desc_op)
>+static int ufs_bsg_alloc_desc_buffer(struct ufs_hba *hba, struct bsg_job *job,
>+ uint8_t **desc_buff, int *desc_len,
Maybe here also we should use 'u8'.
Reviewed-by: Bean Huo
//Beanhuo
Hi, Boris
>>
>
>Okay. Can you have a look at the patches I sent an let me know if I do the
>right thing?
I am doing today. And will back to you I could give some advice.
I encounter one question as below when I reply the email of linux-mtd, but If I
reply other mail list
Such as scsi mail list
Hi, Boris
>>
>> Okay, I think we already had this discussion, but I'm asking it again.
>> What are the possible values for that field and what do they mean?
>
>Still, it's not clear to me what "Internal ECC level" means. It seems that NAND
>chips having on-die ECC have this field set to 10b (0x2),
Hi, Boris and Chris
>>
>> I see 2 solutions to this problem:
>> 1/ Bean provides us a solution to reliably detect when ECC can be
>>de-actived and when it can't
>> 2/ We only ever expose 64 bytes of OOB to the user and consider that
>>ECC can be disabled, even if it can't in reality
>>
>
>
>On Mon, 2018-04-16 at 20:27 +0000, Bean Huo (beanhuo) wrote:
>> By the way, these patches are not to add new feature, they are just to
>> add print tag along with the other exist printed request parameters.
>
>Are you aware that there are two tag fields in struct reque
Hi, Steve
Right, Please see below portion log from ftrace and blktrace,
There is no any impact on blktrace.
>
>Looking at the code from
>git://git.kernel.org/pub/scm/linux/kernel/git/axboe/blktrace.git
>
>It appears that it does not rely on the ftrace ring buffers.
>
>So I'm guessing blktrace is
Hi, Bart
>mi...@redhad.com; linux-bl...@vger.kernel.org; raja...@google.com
>Subject: [EXT] Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI
>trace events
>
>On Mon, 2018-04-16 at 14:31 +0000, Bean Huo (beanhuo) wrote:
>> TP_printk("host_no=%u channe
>>> This patch is not acceptable because it adds support for tag tracing
>>> to the legacy block layer only. Any patch that adds a new feature to
>>> the legacy block layer must also add it to blk-mq.
>>>
>> To be honest, I don't understand your point, can you give me more
>explanation?
>
>The lega
Hi, Bart
>On Mon, 2018-04-16 at 09:41 -0700, Rajat Jain wrote:
>> On Mon, Apr 16, 2018 at 8:28 AM, Steven Rostedt
>wrote:
>> > On Mon, 16 Apr 2018 14:31:49 +
>> > "Bean Huo (beanhuo)" wrote:
>> >
>> > > Print the request ta
Print the request tag along with other information
while tracing a command.
Signed-off-by: Bean Huo
---
include/trace/events/scsi.h | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/include/trace/events/scsi.h b/include/trace/events/scsi.h
index f624969..a
Print the request tag along with other information in block trace events
when tracing request , and unplug type (Sync / Async).
Signed-off-by: Bean Huo
---
include/trace/events/block.h | 36 +---
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/incl
These patches are to add the printout of the request tag in Block/SCSI trace
events when tracing one request or command, this is very useful for tracing
the task running status in the storage device which supports multiple command
queue.
As for the first patch " Add tag in SCSI trace events", copi
Hi Bart
Thanks for your answer.
I looked at SCSI core source codes these days, UFS also follows SCSI core error
handling.
There is already re-issue behavior, and assign 5 retries for each UFS request
if there is error.
>
>On 02/12/18 04:21, Bean Huo (beanhuo) wrote
>> I am looking
Hi,
I am looking at UFS error handling, but I didn't notice re-issues requests with
UTP error to the host controller.
According UFS host spec, "host software either completes the request that had
the error and requests still outstanding
with error to higher level software, or re-issues these re
Hi, greg k-h
>
>So what UFS commands are you missing that you need to see implemented?
>
>And again, have you checked the different forks of the driver?
>
Seems there is something misunderstood, I want to use UPIU, rather than CDB.
Maybe it is not possible based on current UFS stacks. Of course,
Hi, Bart
Sorry for later!
>
>Hello Bean,
>
>Please be more specific. What is inconvenient about sg3_utils on embedded
>ARM systems?
>
Exactly, I don't know how to compile sg3_utils with static library, instead of
sharing library. I used following configuration
Parameter:
./configure --enable-stati
Hi, Cyrille
>Hi Bean,
>
>Le 04/12/2017 à 13:34, Bean Huo (beanhuo) a écrit :
>> For Micron spi nor device, when erase/program operation fails,
>> especially the failure results from intending to modify protected
>> space, spi-nor upper layers still get the return w
For Micron spi nor device, when erase/program operation
fails, especially the failure results from intending to
modify protected space, spi-nor upper layers still get
the return which shows the operation succeeds. This is
because current spi_nor_fsr_ready() only uses FSR bit.7
(flag status register
Hi, Cyrille
Finally, I get your comments, thanks.
>Hi Bean,
>
>Le 11/11/2017 à 21:49, Bean Huo (beanhuo) a écrit :
>> For the Micron SPI NOR, when the erase/program operation fails,
>> especially,
>
>To be verified but I think you'd rather remove "the"
Hi, Greg
>On Mon, Nov 27, 2017 at 11:25:47AM +0000, Bean Huo (beanhuo) wrote:
>> Hi, all
>> Is there someone knows if exists one utilis dedicated to UFS device, rather
>than SCSI utils?
>> I have tried sg3-utils, but it is not convenient for the embedded ARM-based
>sys
For the Micron SPI NOR, when the erase/program operation fails, especially,
for the failure results from intending to modify protected space, spi-nor
upper layers still get the return which shows the operation succeeds.
This because spi_nor_fsr_ready() only uses bit.7 to device whether ready.
For t
Ping SPI-NOR maintainers again
>
>Ping SPI-NOR maintainers
>
>>-Original Message-----
>>From: Bean Huo (beanhuo)
>>Sent: Samstag, 11. November 2017 21:49
>>To: 'cyrille.pitc...@wedev4u.fr' ;
>>marek.va...@gmail.com
>>Cc: '
Hi, all
Is there someone knows if exists one utilis dedicated to UFS device, rather
than SCSI utils?
I have tried sg3-utils, but it is not convenient for the embedded ARM-based
system.
And also it doesn't support several UFS special command.
If we don't have this kind of tool for UFS, is it nec
Ping SPI-NOR maintainers
>-Original Message-
>From: Bean Huo (beanhuo)
>Sent: Samstag, 11. November 2017 21:49
>To: 'cyrille.pitc...@wedev4u.fr' ;
>marek.va...@gmail.com
>Cc: 'dw...@infradead.org' ;
>computersforpe...@gmail.com; 'linux-...
For the Micron SPI NOR, when the erase/program operation fails, especially,
for the failure results from intending to modify protected space, spi-nor
upper layers still get the return which shows the operation succeeds.
this because spi_nor_fsr_ready() only uses bit.7 to device whether ready.
For t
Hi, Uffe
>>>On 19 March 2017 at 01:45, Bean Huo (beanhuo)
>wrote:
>>>> This patch fixes the issue that mmc_blk_issue_rq still flushes cache
>>>> when eMMC cache has already been off through user space tool, such
>>>> as mmc-utils.
>>>
Hi,
>On 19 March 2017 at 01:45, Bean Huo (beanhuo) wrote:
>> This patch fixes the issue that mmc_blk_issue_rq still flushes cache
>> when eMMC cache has already been off through user space tool, such as
>> mmc-utils.
>> The reason is that card->ext_csd.cache_ctrl
Ping Linux-mmc maintainer...
Tested-by: Shawn Lin
Reviewed-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Shawn Lin
>On Sunday, March 19, 2017 12:45:40 AM Bean Huo wrote:
>> This patch fixes the issue that mmc_blk_issue_rq still flushes cache
>> when eMMC cache has already been off through user sp
This patch fixes the issue that mmc_blk_issue_rq still
flushes cache when eMMC cache has already been off
through user space tool, such as mmc-utils.
The reason is that card->ext_csd.cache_ctrl isn't reset.
Signed-off-by: beanhuo
---
drivers/mmc/core/block.c | 9 +
1 file changed, 9 inse
> -Original Message-
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> Sent: Mittwoch, 21. September 2016 20:17
> To: Jisheng Zhang
> Cc: Bean Huo (beanhuo) ; Zoltan Szubbocsev
> (zszubbocsev) ; catalin.mari...@arm.com;
> will.dea...@arm.com; r...@lists.rocketboa
> From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On Behalf Of Steven Rostedt
> Sent: Dienstag, 20. September 2016 16:07
> To: Bean Huo (beanhuo)
> Cc: Zoltan Szubbocsev (zszubbocsev) ;
> catalin.mari...@arm.com; will.dea...@arm.com; r...@list
Hi, all
I just use ftrace to do some latency study, found that function_graph can not
Work, as long as enable it, will cause kernel panic. I searched this online.
Found that there are also some cause the same as mine. I am a newer of ftrace.
I want to know who know what root cause? Here is some p
67 matches
Mail list logo