RE: [EXT] [PATCH v1 1/2] scsi: ufs: Fix unbalanced scsi_block_reqs_cnt caused by ufshcd_hold()

> > Signed-off-by: Can Guo > Reviewed-by: Hongwu Su Reviewed-by: Bean Huo

RE: [PATCH] scsi: ufs: Fix unexpected values get from ufshcd_read_desc_param()

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.

RE: [EXT] [PATCH v2] scsi: ufs: Disable WriteBooster capability in non-supported UFS device

> > 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

RE: RE: [EXT] [PATCH] scsi: ufs-bsg: Fix runtime PM imbalance on error

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 >

RE: [EXT] [PATCH] scsi: ufs-bsg: Fix runtime PM imbalance on error

> 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

RE: [EXT] [PATCH v6 6/8] scsi: ufs: add LU Dedicated buffer mode support for WriteBooster

> 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..

RE: [EXT] [PATCH v2 1/5] scsi: ufs: Allow UFS 3.0 as a valid version

> > > @@ -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) && > > > -

RE: [EXT] [PATCH v1 3/4] scsi: ufs: add LU Dedicated buffer type support for WriteBooster

> > +/* 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

RE: [EXT] [PATCH v1 4/4] scsi: ufs-mediatek: enable WriteBooster capability

> -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)

RE: [EXT] [PATCH v1 1/4] scsi: ufs: allow legacy UFS devices to enable WriteBooster

> -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)

RE: [EXT] [PATCH v1 2/4] scsi: ufs: add "index" in parameter list of ufshcd_query_flag()

> -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)

RE: [EXT] [PATCH v1 1/2] scsi: ufs: Introduce a vops for resetting host controller

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

RE: [EXT] [PATCH v4 1/3] scsi: ufs: Introduce vops for resetting device

> >Reviewed-by: Alim Akhtar >Signed-off-by: Bjorn Andersson Reviewed-by: Bean Huo //Bean Huo

[PATCH v1] scsi: ufs: change msleep to usleep_range

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

[PATCH v2 3/3] scsi: ufs-bsg: complete ufs-bsg job only if no error

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.

[PATCH v2 2/3] scsi: ufs-bsg: fix typo in ufs_bsg_request

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

[PATCH v2 0/3] scsi: ufs: typo fixes and improvement

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

[PATCH V1] scsi: ufs-bsg: complete ufs-bsg job only if no error

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. [

RE: [EXT] [PATCH v3 2/3] scsi: ufs-qcom: Implement device_reset vops

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

RE: [EXT] [PATCH v3 2/3] scsi: ufs-qcom: Implement device_reset vops

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

RE: [EXT] [PATCH 2/3] scsi: ufs: Allow resetting the UFS device

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) >> &

RE: [EXT] [PATCH 2/3] scsi: ufs: Allow resetting the UFS device

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

RE: [EXT] [PATCH] scsi: ufs: Check that space was properly alloced in copy_query_response

Hi, Avri > >Signed-off-by: Avri Altman Acked-by: Bean Huo Thanks, //Bean

RE: [EXT] [PATCH v6 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller

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

RE: [EXT] Re: [PATCH v2] mtd: spi-nor: Fix wrong abbreviation HWCPAS

>> 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

RE: [EXT] Re: [PATCH v2] mtd: spi-nor: Fix wrong abbreviation HWCPAS

r: 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 (beanhuo)" wrote: > >> Hi, T

[RESEND PATCH v2] mtd: spi-nor: Fix wrong abbreviation HWCPAS

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 ---

RE: [EXT] Re: [PATCH v2] mtd: spi-nor: Fix wrong abbreviation HWCPAS

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 change. Thanks

RE: [EXT] Re: [PATCH v2] mtd: spi-nor: Fix wrong abbreviation HWCPAS

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)' between user name an

RE: [EXT] Re: [PATCH v2] mtd: spi-nor: Fix wrong abbreviation HWCPAS

: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

[PATCH v2] mtd: spi-nor: Fix wrong abbreviation HWCPAS

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 ---

RE: [EXT] Re: [PATCH] include: mtd: spi-nor: change HWCPAS to HWCAPS

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. >

[PATCH] include: mtd: spi-nor: change HWCPAS to HWCAPS

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 ---

RE: [EXT] [PATCH v4 3/3] scsi: ufs-bsg: Allow reading descriptors

>-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

RE: [EXT] [PATCH v4 2/3] scsi: ufs: Allow reading descriptor via raw upiu

> >Signed-off-by: Avri Altman >Reviewed-by: Evan Green Reviewed-by: Bean Huo

RE: [PATCH v4 1/3] scsi: ufs-bsg: Change the calling convention for write descriptor

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

Re: [PATCH v6 0/6] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

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

Re: [PATCH v6 0/6] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

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

Re: [PATCH v6 0/6] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

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

Re: [PATCH v6 0/6] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

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

Re: [PATCH v6 0/6] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

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 >> >

Re: [PATCH v6 0/6] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

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 >> >

Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

>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

Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

>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

Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

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

Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

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

Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

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

Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

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

Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

>>> 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

Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

>>> 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

Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

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 <rost...@goodmis.org> >wrote: >> > On Mon, 16 Apr 2018 14:31:49 +0000 >> > "Bean Huo (beanhuo)" <bean...@micron.com> wrote

Re: [RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

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

[RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

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

[RESEND PATCH v1 1/2] trace: events: scsi: Add tag in SCSI trace events

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

[RESEND PATCH v1 2/2] trace: events: block: Add tag in block trace events

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

[RESEND PATCH v1 2/2] trace: events: block: Add tag in block trace events

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

[RESEND PATCH v1 0/2] Print the request tag in Block/SCSI trace events

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",

[RESEND PATCH v1 0/2] Print the request tag in Block/SCSI trace events

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",

Re: UFS writing request failure handling

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

Re: UFS writing request failure handling

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

UFS writing request failure handling

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

UFS writing request failure handling

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: UFS utilities

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,

Re: UFS utilities

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,

RE: [EXT] Re: UFS utilities

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

RE: [EXT] Re: UFS utilities

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

RE: [PATCH v2] drivers:mtd:spi-nor:checkup FSR error bits

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

RE: [PATCH v2] drivers:mtd:spi-nor:checkup FSR error bits

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

[PATCH v2] drivers:mtd:spi-nor:checkup FSR error bits

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

[PATCH v2] drivers:mtd:spi-nor:checkup FSR error bits

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

Re: [PATCH V1] drivers:mtd:spi-nor:checkup FSR error bits

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" words

Re: [PATCH V1] drivers:mtd:spi-nor:checkup FSR error bits

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" words

Re: UFS utilities

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

Re: UFS utilities

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

[PATCH] [RESEND] drivers:mtd:spi-nor:checkup FSR error bits

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

[PATCH] [RESEND] drivers:mtd:spi-nor:checkup FSR error bits

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

RE: [PATCH V1] drivers:mtd:spi-nor:checkup FSR error bits

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' <cyrille.pitc...@wedev4u.fr>; >>marek.va

RE: [PATCH V1] drivers:mtd:spi-nor:checkup FSR error bits

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: 'dw...@infradead

UFS utilities

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

UFS utilities

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

RE: [PATCH V1] drivers:mtd:spi-nor:checkup FSR error bits

Ping SPI-NOR maintainers >-Original Message- >From: Bean Huo (beanhuo) >Sent: Samstag, 11. November 2017 21:49 >To: 'cyrille.pitc...@wedev4u.fr' <cyrille.pitc...@wedev4u.fr>; >marek.va...@gmail.com >Cc: 'dw...@infradead.org' <dw...@infradead.org>; >co

RE: [PATCH V1] drivers:mtd:spi-nor:checkup FSR error bits

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-...@lists.infradead.org' m..

[PATCH V1] drivers:mtd:spi-nor:checkup FSR error bits

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

[PATCH V1] drivers:mtd:spi-nor:checkup FSR error bits

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

RE: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off

Hi, Uffe >>>On 19 March 2017 at 01:45, Bean Huo (beanhuo) <bean...@micron.com> >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 >&

RE: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off

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. >>>

RE: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off

Hi, >On 19 March 2017 at 01:45, Bean Huo (beanhuo) <bean...@micron.com> 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 car

RE: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off

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

RE: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off

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

RE: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off

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

[PATCH V1] mmc: core: fix still flush cache when eMMC cache off

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

[PATCH V1] mmc: core: fix still flush cache when eMMC cache off

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

RE: ftrace function_graph causes system crash

> -Original Message- > From: Steven Rostedt [mailto:rost...@goodmis.org] > Sent: Mittwoch, 21. September 2016 20:17 > To: Jisheng Zhang <jszh...@marvell.com> > Cc: Bean Huo (beanhuo) <bean...@micron.com>; Zoltan Szubbocsev > (zszubbocsev) <zszubboc...@mic

RE: ftrace function_graph causes system crash

> -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

RE: ftrace function_graph causes system crash

> 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) <bean...@micron.com> > Cc: Zoltan Szubbocsev (zszubbocsev) <zszubboc...@micron.com>; > cat

RE: ftrace function_graph causes system crash

> 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

ftrace function_graph causes system crash

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

ftrace function_graph causes system crash

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