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: <e1555f6c-63e2-60c8-9a7d-808545de01e0@canonical.com>
Date:   Sun, 31 Oct 2021 21:56:01 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     David Virag <virag.david003@...il.com>
Cc:     linux-arm-kernel@...ts.infradead.org,
        linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] samsung: exynos-chipid: add Exynos7885 SoC support

On 31/10/2021 18:53, David Virag wrote:
> Exynos 7885 has product id "0xE7885000". Add this id to the ids with
> the name.
> 

Thanks for the patch!

> The downstream driver sets sub_rev to 2 if we are on Exynos 7885, we
> detected sub_rev 1 and the 27th bit of the revision register is set.

There is no revision register in older Exynos boards, so it seems you
speak about new version, but please mention it explicitly.

> This is presumably because Samsung might have set the wrong bits on
> rev2 of the SoC in the chipid, but we may never know as we have no
> manual.
> 
> Both the SM-A530F/jackpotlte with Exynos7885 and the SM-M305/m30lte
> with Exynos7904 (rebranded Exynos7885 with lower clock speeds) seem
> to have this bit set to 1 and have a sub_rev of 1 otherwise, but the
> downstream driver corrects it to 2.
> Let's replicate this behaviour in upstream too!

No, let's don't replicate weird vendor behavior without understanding
it, unless there is reason to. Please describe the reason or drop it.

> 
> Signed-off-by: David Virag <virag.david003@...il.com>
> ---
>  drivers/soc/samsung/exynos-chipid.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> index a28053ec7e6a..ec8c76275aec 100644
> --- a/drivers/soc/samsung/exynos-chipid.c
> +++ b/drivers/soc/samsung/exynos-chipid.c
> @@ -55,6 +55,7 @@ static const struct exynos_soc_id {
>  	{ "EXYNOS5440", 0xE5440000 },
>  	{ "EXYNOS5800", 0xE5422000 },
>  	{ "EXYNOS7420", 0xE7420000 },
> +	{ "EXYNOS7885", 0xE7885000 },

This looks good, but please rebase on:
https://lore.kernel.org/linux-samsung-soc/20211031205212.59505-1-krzysztof.kozlowski@canonical.com/T/#u
because we use one compatible for entire family and I would like to have
it documented which family is this here.

>  	{ "EXYNOS850", 0xE3830000 },
>  	{ "EXYNOSAUTOV9", 0xAAA80000 },
>  };
> @@ -88,6 +89,14 @@ static int exynos_chipid_get_chipid_info(struct regmap *regmap,
>  	}
>  	main_rev = (val >> data->main_rev_shift) & EXYNOS_REV_PART_MASK;
>  	sub_rev = (val >> data->sub_rev_shift) & EXYNOS_REV_PART_MASK;
> +
> +	//Exynos 7885 revision 2 apparently has the 27th bit set instead of having
> +	//a sub_rev of 2. Correct for this!

Not a Linux kernel comment. This will go away anyway, but please read
the coding style and use scripts/checkpatch.pl for future patches.

> +	if (soc_info->product_id == 0xE7885000) {
> +		if ((sub_rev == 1) && (val & 0x04000000))
> +			sub_rev = 2;
> +	}
> +
>  	soc_info->revision = (main_rev << EXYNOS_REV_PART_SHIFT) | sub_rev;
>  
>  	return 0;
> 


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ