The current ext_csd in the debugfs shows 1024 chars in one line,
which is unreadable at least for humans (but perhaps it could be
handier if somebody is processing it by a tool).
This commit makes the output format more human-readable; shows 8 byte
in each line, with address in the left-most column:
0: 00 00 00 00 00 00 00 00
8: 00 00 00 00 00 00 00 00
16: 01 01 00 c0 6a 02 00 00
24: 00 00 00 00 00 00 00 00
32: 00 01 01 00 00 00 00 00
<snip>
496: 05 00 03 01 20 3c 01 01
504: 01 00 00 00 00 00 00 00
Signed-off-by: Masahiro Yamada <[email protected]>
---
drivers/mmc/core/block.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 663d87924e5e..79044b3cbd84 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -2728,8 +2728,8 @@ static int mmc_dbg_card_status_get(void *data, u64 *val)
DEFINE_DEBUGFS_ATTRIBUTE(mmc_dbg_card_status_fops, mmc_dbg_card_status_get,
NULL, "%08llx\n");
-/* That is two digits * 512 + 1 for newline */
-#define EXT_CSD_STR_LEN 1025
+/* 3 chars (2 digits + space) for each byte, 5 additional chars for each line */
+#define EXT_CSD_STR_LEN (512 * 3 + 512 / 8 * 5)
static int mmc_ext_csd_open(struct inode *inode, struct file *filp)
{
@@ -2740,7 +2740,7 @@ static int mmc_ext_csd_open(struct inode *inode, struct file *filp)
char *buf;
ssize_t n = 0;
u8 *ext_csd;
- int err, i;
+ int err, i, j;
buf = kmalloc(EXT_CSD_STR_LEN + 1, GFP_KERNEL);
if (!buf)
@@ -2762,9 +2762,12 @@ static int mmc_ext_csd_open(struct inode *inode, struct file *filp)
goto out_free;
}
- for (i = 0; i < 512; i++)
- n += sprintf(buf + n, "%02x", ext_csd[i]);
- n += sprintf(buf + n, "\n");
+ for (i = 0; i < 512; i += 8) {
+ n += sprintf(buf + n, "%3d:", i);
+ for (j = i; j < i + 8; j++)
+ n += sprintf(buf + n, " %02x", ext_csd[j]);
+ n += sprintf(buf + n, "\n");
+ }
if (n != EXT_CSD_STR_LEN) {
err = -EINVAL;
--
2.17.1
Hi,
>
>
> The current ext_csd in the debugfs shows 1024 chars in one line, which is
> unreadable at least for humans (but perhaps it could be handier if somebody
> is processing it by a tool).
I fail to see how re-arranging the bytes makes it more human-readable.
Plus you have mmc-utils parsing it for you.
Thanks,
Avri