lkml.org 
[lkml]   [2022]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH V2] scsi: ufs: Get boot device storage type from command line
From
On 7/28/22 10:30, Chetan C R wrote:
> 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/Kconfig | 10 ++++++++
> drivers/ufs/host/Makefile | 1 +
> drivers/ufs/host/ufs-cmdline.c | 54 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 65 insertions(+)
> create mode 100644 drivers/ufs/host/ufs-cmdline.c
>
> diff --git a/drivers/ufs/host/Kconfig b/drivers/ufs/host/Kconfig
> index 8259022..02fe817 100644
> --- a/drivers/ufs/host/Kconfig
> +++ b/drivers/ufs/host/Kconfig
> @@ -68,6 +68,16 @@ config SCSI_UFS_QCOM
> Select this if you have UFS controller on QCOM chipset.
> If unsure, say N.
>
> +config UFS_QCOM_CMDLINE
> + bool "Get the boot device type from kernel command line for Qcom devices"
> + default y if ARCH_QCOM
> + help
> + This selects the support of getting the boot device storage type
> + from kernel command line arguments and export this information
> + to the Qcom UFS controller platform driver.
> +
> + If unsure, say N.
> +
> config SCSI_UFS_MEDIATEK
> tristate "Mediatek specific hooks to UFS controller platform driver"
> depends on SCSI_UFSHCD_PLATFORM && ARCH_MEDIATEK
> diff --git a/drivers/ufs/host/Makefile b/drivers/ufs/host/Makefile
> index e4be542..a9463f1 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-$(CONFIG_UFS_QCOM_CMDLINE) += 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

I see a similar problem with this patch as with the previous version of
this patch: if CONFIG_SCSI_UFSHCD=m, __setup() will be an empty macro
and hence the androidboot.bootdevice parameter won't be parsed.

Bart.

\
 
 \ /
  Last update: 2022-07-28 20:14    [W:0.030 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site