[PATCH V3] scsi: ufs: Get boot device storage type from command line

[PATCH V3] scsi: ufs: Get boot device storage type from command line

[Chetan C R]

v1->v2:
- Made UFS_QCOM_CMDLINE as default 'Y' to get __setup() addressing review comments from Bart
v2->v3
- Made ufs-cmdline to build as core driver obj-y

Thanks for your response!

Chetan C R (1):
  scsi: ufs: Get boot device storage type from command line

 drivers/ufs/host/Makefile      |  1 +
 drivers/ufs/host/ufs-cmdline.c | 54 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+)
 create mode 100644 drivers/ufs/host/ufs-cmdline.c

-- 
2.7.4

[PATCH V3] scsi: ufs: Get boot device storage type from command line

[Chetan C R]

Get the boot device storage type by reading it from
kernel command line arguments and export the same
information to ufs modules.

Signed-off-by: Chetan C R <quic_cchinnad@quicinc.com>
---
 drivers/ufs/host/Makefile      |  1 +
 drivers/ufs/host/ufs-cmdline.c | 54 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+)
 create mode 100644 drivers/ufs/host/ufs-cmdline.c

diff --git a/drivers/ufs/host/Makefile b/drivers/ufs/host/Makefile
index e4be542..0bac3b1 100644
--- a/drivers/ufs/host/Makefile
+++ b/drivers/ufs/host/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
 obj-$(CONFIG_SCSI_UFS_QCOM) += ufs_qcom.o
 ufs_qcom-y += ufs-qcom.o
 ufs_qcom-$(CONFIG_SCSI_UFS_CRYPTO) += ufs-qcom-ice.o
+obj-y  += ufs-cmdline.o
 obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o
 obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
 obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/ufs/host/ufs-cmdline.c b/drivers/ufs/host/ufs-cmdline.c
new file mode 100644
index 0000000..408755c
--- /dev/null
+++ b/drivers/ufs/host/ufs-cmdline.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/init.h>
+#include <linux/printk.h>
+#include <linux/string.h>
+
+#ifdef CONFIG_BOOT_CONFIG
+#include <linux/bootconfig.h>
+#endif
+
+#define ANDROID_BOOT_DEV_MAX_V3    30
+
+static char android_boot_dev_v3[ANDROID_BOOT_DEV_MAX_V3];
+static const char *android_boot_dev_v4;
+
+const char *get_storage_boot_device(void)
+{
+	if (android_boot_dev_v4 && strlen(android_boot_dev_v4))
+		return android_boot_dev_v4;
+
+	else if (strlen(android_boot_dev_v3))
+		return android_boot_dev_v3;
+
+	pr_err("Not able to get Bootconfig or Kernel command line param\n");
+	return NULL;
+};
+EXPORT_SYMBOL_GPL(get_storage_boot_device);
+
+/* boot image header version 3 android boot device type */
+static int __init get_android_boot_dev_v3(char *str)
+{
+	strscpy(android_boot_dev_v3, str, ANDROID_BOOT_DEV_MAX_V3);
+	return 1;
+}
+__setup("androidboot.bootdevice=", get_android_boot_dev_v3);
+
+#ifdef CONFIG_BOOT_CONFIG
+/* boot image header version 4 android boot device type */
+static int __init get_android_boot_dev_v4(void)
+{
+	struct xbc_node *vnode = NULL;
+
+	android_boot_dev_v4 = xbc_find_value("androidboot.bootdevice", &vnode);
+
+	if (vnode && xbc_node_is_array(vnode))
+		xbc_array_for_each_value(vnode, android_boot_dev_v4);
+
+	return 0;
+}
+fs_initcall(get_android_boot_dev_v4);
+#endif
-- 
2.7.4

RE: [PATCH V3] scsi: ufs: Get boot device storage type from command line

[Avri Altman]

 
> Get the boot device storage type by reading it from kernel command line
> arguments and export the same information to ufs modules.
Who are the callers of get_storage_boot_device?
Is this code designated for ufs boot devices?
If yes, maybe we should call it get_ufs_boot_device?
Otherwise, why is it in the ufs core?

Thanks,
Avri 

Re: [PATCH V3] scsi: ufs: Get boot device storage type from command line

[Christoph Hellwig]

This code does not actually seem to have any user.  Why are you trying
to add dead code to the kernel?

Re: [PATCH V3] scsi: ufs: Get boot device storage type from command line

[Bart Van Assche]

On 7/28/22 12:00, Chetan C R wrote:
> v2->v3
> - Made ufs-cmdline to build as core driver obj-y

This is not sufficient to integrate the ufs-cmdline code in vmlinux so 
this patch has the same problem as the previous two versions.

Bart.

Re: [PATCH V3] scsi: ufs: Get boot device storage type from command line

[Chetan Chinnadagudihundi Ravindranath (Consultant) (QUIC)]

Hi Bart,

Thanks for your response!. For making ufs-cmdline code integrate in 
vmlinux we might need to remove the depends on for SCSI_UFSHCD(m)

/drivers/ufs/Kconfig
  menuconfig SCSI_UFSHCD

-       depends on SCSI && SCSI_DMA

does this looks good? Instead of this Please suggest any efficient way 
of making ufs-cmdline part of vmlinux.

Thanks,

Chetan

On 7/29/2022 2:01 AM, Bart Van Assche wrote:
> On 7/28/22 12:00, Chetan C R wrote:
>> v2->v3
>> - Made ufs-cmdline to build as core driver obj-y
>
> This is not sufficient to integrate the ufs-cmdline code in vmlinux so 
> this patch has the same problem as the previous two versions.
>
> Bart.

Re: [PATCH V3] scsi: ufs: Get boot device storage type from command line

[Bart Van Assche]

On 7/29/22 05:54, Chetan Chinnadagudihundi Ravindranath (Consultant) 
(QUIC) wrote:
> Please suggest any efficient way of making ufs-cmdline part of vmlinux.

A patch description should not only explain what has been changed but 
also why a change is being made. Information about why support is being 
added for the androidboot.bootdevice parameter in the Qualcomm UFS host 
controller driver is missing from the patch description.

Please also address Christoph's comment about this new command-line 
parameter not being used anywhere in the upstream kernel tree.

Thanks,

Bart.

Re: [PATCH V3] scsi: ufs: Get boot device storage type from command line

[Chetan Chinnadagudihundi Ravindranath (Consultant) (QUIC)]

 > why a change is being made:
There are 2 variants of the android bootdev device. One is EMMC and 
other is UFS. We would be not knowing the android boot storage type at 
build time. So, we need to know the storage type at run time(bootup 
time) by reading the  "androidboot.bootdevice=". We need to distinguish 
between EMMC and UFS at bootup time and take appropriate action.

 > Information about why support is being added for the 
androidboot.bootdevice parameter in the Qualcomm UFS host controller driver:

We will get the "androidboot.bootdevice=" by reading cmdline
case 1: if the boot image header version is 3
         We get the bootdevice info by reading /proc/cmdline ( 
__setup("androidboot.bootdevice=", get_android_boot_dev_v3);

Case 2: if the boot image header version is 4
         We get the bootdevice info by reading /proc/bootconfig 
(android_boot_dev_v4 = xbc_find_value("androidboot.bootdevice", &vnode))

Qualcomm UFS modules(ufs-qcom.c) calls this 
get_storage_boot_device()(ufs-cmdline.c)   and get the bootdevice info 
and take appropriate action. This code is yet to be upstreamed. Please 
let me know if this info convincing.

Thanks,

Chetan

On 7/30/2022 1:36 AM, Bart Van Assche wrote:
> On 7/29/22 05:54, Chetan Chinnadagudihundi Ravindranath (Consultant) 
> (QUIC) wrote:
>> Please suggest any efficient way of making ufs-cmdline part of vmlinux.
>
> A patch description should not only explain what has been changed but 
> also why a change is being made. Information about why support is 
> being added for the androidboot.bootdevice parameter in the Qualcomm 
> UFS host controller driver is missing from the patch description.
>
> Please also address Christoph's comment about this new command-line 
> parameter not being used anywhere in the upstream kernel tree.
>
> Thanks,
>
> Bart.

Re: [PATCH V3] scsi: ufs: Get boot device storage type from command line

[Bart Van Assche]

On 7/30/22 00:54, Chetan Chinnadagudihundi Ravindranath (Consultant) 
(QUIC) wrote:
>  > why a change is being made:
> There are 2 variants of the android bootdev device. One is EMMC and 
> other is UFS. We would be not knowing the android boot storage type at 
> build time. So, we need to know the storage type at run time(bootup 
> time) by reading the  "androidboot.bootdevice=". We need to distinguish 
> between EMMC and UFS at bootup time and take appropriate action.
> 
>  > Information about why support is being added for the 
> androidboot.bootdevice parameter in the Qualcomm UFS host controller 
> driver:
> 
> We will get the "androidboot.bootdevice=" by reading cmdline
> case 1: if the boot image header version is 3
>          We get the bootdevice info by reading /proc/cmdline ( 
> __setup("androidboot.bootdevice=", get_android_boot_dev_v3);
> 
> Case 2: if the boot image header version is 4
>          We get the bootdevice info by reading /proc/bootconfig 
> (android_boot_dev_v4 = xbc_find_value("androidboot.bootdevice", &vnode))
> 
> Qualcomm UFS modules(ufs-qcom.c) calls this 
> get_storage_boot_device()(ufs-cmdline.c)   and get the bootdevice info 
> and take appropriate action. This code is yet to be upstreamed. Please 
> let me know if this info convincing.

Instead of posting the above information on the linux-scsi mailing list, 
it should be integrated in the description of the patch. Please do that 
before reposting this patch and also make sure that the code that uses 
this new kernel command line parameter is included in the same patch series.

Thanks,

Bart.