UFS maximum access unit is 8KB

Hi, I am now using one hikey960, and Linux kernel version is 4.4.77. And found that for UFS driver version, the maximum transformation is 8KB. Means that if I using 128KB chuck size to program in the user space, but, from ftrace/blktrace, It shows that it always programs by 8KB in kernel. please

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: 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: [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: 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: [RFC] sg3_utils: sgp_dd: work around on pthread_cancel for android

Hi, Doug and Bart Thanks so much for your prompt response. See below my action: >On 2017-12-22 01:24 PM, Bart Van Assche wrote: >> On Fri, 2017-12-22 at 17:00 +0000, Bean Huo (beanhuo) wrote: >>> case "${host}" in >>> +*-*-android*) >>> +

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 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: [PATCH for sg3_utils 1/4] configure.ac: Suppress an autoconf warning

>a/configure.ac b/configure.ac index 1cce0b25f583..129c2f9d4d4d 100644 >--- a/configure.ac >+++ b/configure.ac >@@ -7,13 +7,13 @@ AM_CONFIG_HEADER(config.h) AC_PROG_CC # >AC_PROG_CXX AC_PROG_INSTALL >- >-# Adding libtools to the build seems to bring in C++ environment - >AC_PROG_LIBTOOL > > #

RE: [PATCH for sg3_utils 0/4] Simplify the sg3_utils configure script

Hi, Bart and Dong Do you think we need to submit all changed diff including some generated files by automake? Such as config.h.in, Makefile.in..., in fact, we only manually did a few modificaiton on Some files such as configura.ac,makefile.am. > >Hello Doug, > >The four patches in this series

[RFC] sg3_utils: sgp_dd: work around on pthread_cancel for android

pthread_cancel is not supported by Android Bionic C library pthread. Based on my searched information online, pthread_cancel sometimes is likely to lead to memory leaks and dead locks. If we use android NDK or standalone toolchain to cross complile sg3_utils, below failure appeared.

Re: [RFC] sg3_utils: sgp_dd: work around on pthread_cancel for android

Hi, Bart > >On Sat, 2017-12-23 at 10:19 +, Bean Huo (beanhuo) wrote: >> Doug wrote: >> > This seems to work in Linux but may not work in Android: >> > AC_SEARCH_LIBS([pthread_cancel], [pthread], >> > [AC_DEFINE(HAVE_PTHREAD_CANCEL, 1, [Found pthread_c

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

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

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 >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: [PATCH v1] sg3_utils: sg_write_buffer: convert string to integer while reading from stdio

Hi, Doug Gilbert >>On 2018-11-09 7:18 p.m., Bean Huo (beanhuo) wrote: >> This patch is to convert inputted string to the integer when read data >> from stdin. While entering data, the data between bytes can be >> separated by space, or by ',' or by '.'. > >Could

[PATCH V2] sg3_utils: sg_write_buffer: convert string to integer while reading from stdio

This patch is to convert inputted string to the integer when read data from stdin. While entering data flow, the data between bytes can be separated by either space, or ',' (or by '.'). V1-V2: 1. Rebased the patch on the latest sg_write_buffer.c 2. Added the wrong input checkup,

[PATCH v1] sg3_utils: sg_write_buffer: convert string to integer while reading from stdio

This patch is to convert inputted string to the integer when read data from stdin. While entering data, the data between bytes can be separated by space, or by ',' or by '.'. Signed-off-by: Bean Huo --- src/sg_write_buffer.c | 31 +++ 1 file changed, 31 insertions(+)

RE: [PATCH v8 0/8] scsi: Add ufs bsg endpoint

Hi, Avri >We tested it on a Hikey-960 platform with a V4.14 kernel, "modernized" by >recent bsg and ufs patches. Which kernel version is V8 based on? I patched to 4.14-rc7, it failed.

Re: [PATCH v8 0/8] scsi: Add ufs bsg endpoint

list on Sunday. > >Thanks, >Avri >____________ >From: Bean Huo (beanhuo) >Sent: Friday, October 5, 2018 12:28 AM >To: Avri Altman; Christoph Hellwig; Johannes Thumshirn; Hannes Reinecke; >Bart Van Assche; James E.J. Bottomley; Martin K. Petersen; linu