linux-kernel - Re: [RFT] ufs: qcom: drop custom Android boot parameters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <CIPJ0CT6EQI9.2C0T9KAHDODH2@otso>
Date:   Mon, 21 Mar 2022 12:58:45 +0100
From:   "Luca Weiss" <luca.weiss@...rphone.com>
To:     "Krzysztof Kozlowski" <krzk@...nel.org>,
        "Andy Gross" <agross@...nel.org>,
        "Bjorn Andersson" <bjorn.andersson@...aro.org>,
        "Alim Akhtar" <alim.akhtar@...sung.com>,
        "Avri Altman" <avri.altman@....com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        <linux-arm-msm@...r.kernel.org>, <linux-scsi@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [RFT] ufs: qcom: drop custom Android boot parameters

Hi Krzysztof,

On Sun Mar 20, 2022 at 12:06 PM CET, Krzysztof Kozlowski wrote:
> The QCOM UFS driver requires an androidboot.bootdevice command line
> argument matching the UFS device name.  If the name is different, it
> refuses to probe.  Thise androidboot.bootdevice is provided by
> stock/vendor (from an Android-based device) bootloader.
>
> This does not make sense from Linux point of view.  Driver should be
> able to boot regardless of bootloader.  Driver should not depend on some
> Android custom environment data.
>
> Cc: Luca Weiss <luca.weiss@...rphone.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@...nel.org>

As expected this makes UFS probe even if the node is named ufs@...4000
on my device.

While I don't know why the code existed in the first place, it was added
back in 2015 with the introduction of the driver, so probably it's just
some remains from downstream that weren't cleaned up back then.

With this commit also 6b9afd8f96c6 ("arm64: dts: qcom: sm8250: change
ufs node name to ufshc") could be reverted (but it would probably make
more sense to rename all ufshc@ to ufs@ in a new commit).

Tested-by: Luca Weiss <luca.weiss@...rphone.com>

Regards
Luca

>
> ---
>
> Not tested, please kindly provide tests.
>
> See also:
> https://lore.kernel.org/linux-devicetree/f61abc2b-3ce8-7b1f-3d28-8a4a03ec58eb@kernel.org/T/#u
> ---
>  drivers/scsi/ufs/ufs-qcom.c | 15 ---------------
>  1 file changed, 15 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> index 0d2e950d0865..586c0e567ff9 100644
> --- a/drivers/scsi/ufs/ufs-qcom.c
> +++ b/drivers/scsi/ufs/ufs-qcom.c
> @@ -957,18 +957,6 @@ static const struct reset_control_ops ufs_qcom_reset_ops = {
>  	.deassert = ufs_qcom_reset_deassert,
>  };
>  
> -#define	ANDROID_BOOT_DEV_MAX	30
> -static char android_boot_dev[ANDROID_BOOT_DEV_MAX];
> -
> -#ifndef MODULE
> -static int __init get_android_boot_dev(char *str)
> -{
> -	strlcpy(android_boot_dev, str, ANDROID_BOOT_DEV_MAX);
> -	return 1;
> -}
> -__setup("androidboot.bootdevice=", get_android_boot_dev);
> -#endif
> -
>  /**
>   * ufs_qcom_init - bind phy with controller
>   * @hba: host controller instance
> @@ -988,9 +976,6 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>  	struct resource *res;
>  	struct ufs_clk_info *clki;
>  
> -	if (strlen(android_boot_dev) && strcmp(android_boot_dev, dev_name(dev)))
> -		return -ENODEV;
> -
>  	host = devm_kzalloc(dev, sizeof(*host), GFP_KERNEL);
>  	if (!host) {
>  		err = -ENOMEM;
> -- 
> 2.32.0