linux-kernel - Re: [PATCH v7 15/19] phy: sun4i-usb: Add support for the H616 USB PHY

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]

Date:   Mon, 12 Jul 2021 19:50:22 +0300
From:   Evgeny Boger <boger@...enboard.com>
To:     andre.przywara@....com
Cc:     icenowy@...c.io, jernej.skrabec@...il.com, kishon@...com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-phy@...ts.infradead.org, linux-sunxi@...glegroups.com,
        linux-sunxi@...ts.linux.dev, linux-usb@...r.kernel.org,
        megous@...ous.com, mripard@...nel.org, robh@...nel.org,
        samuel@...lland.org, vkoul@...nel.org, wens@...e.org
Subject: Re: [PATCH v7 15/19] phy: sun4i-usb: Add support for the H616 USB PHY

Hi Andre!

> The USB PHY used in the Allwinner H616 SoC inherits some traits from its
> various predecessors: it has four full PHYs like the H3, needs some
> extra bits to be set like the H6, and puts SIDDQ on a different bit like
> the A100. Plus it needs this weird PHY2 quirk.
>
> Name all those properties in a new config struct and assign a new
> compatible name to it.
>
> Signed-off-by: Andre Przywara<andre.przywara@....com>
> ---
>   drivers/phy/allwinner/phy-sun4i-usb.c  <https://lore.kernel.org/linux-sunxi/20210615110636.23403-16-andre.przywara@arm.com/#Z30drivers:phy:allwinner:phy-sun4i-usb.c>  | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
>
> diff 
> <https://lore.kernel.org/linux-sunxi/20210615110636.23403-16-andre.przywara@arm.com/#iZ30drivers:phy:allwinner:phy-sun4i-usb.c> 
> --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
> b/drivers/phy/allwinner/phy-sun4i-usb.c index 
> 316ef5fca831..85a9771280b7 100644 --- 
> a/drivers/phy/allwinner/phy-sun4i-usb.c +++ 
> b/drivers/phy/allwinner/phy-sun4i-usb.c @@ -1024,6 +1024,17 @@ static 
> const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {   	.missing_phys = BIT(1) | BIT(2),
>   };
>   
> +static const struct sun4i_usb_phy_cfg sun50i_h616_cfg = { + .num_phys 
> = 4, + .type = sun50i_h6_phy,

Since this usb phy is considerable different from the one in H6, 
wouldn't it better to define a new phy type here? The way the driver is 
designed, I would expect the type to be shared by more or less identical 
parts.

Honestly, I think it would be better to get rid of .type in the 
sun4i_usb_phy_cfg completely replacing it by a couple more traits in 
.cfg. It's impossible to know for sure which Allwinner parts really 
share the identical revision of this hardware.

> + .disc_thresh = 3, + .phyctl_offset = REG_PHYCTL_A33, + 
> .dedicated_clocks = true, + .phy0_dual_route = true, + 
> .hci_phy_ctl_clear = PHY_CTL_SIDDQ, + .needs_phy2_siddq = true, +}; +   static const struct of_device_id sun4i_usb_phy_of_match[] = {
>   	{ .compatible = "allwinner,sun4i-a10-usb-phy", .data = &sun4i_a10_cfg },
>   	{ .compatible = "allwinner,sun5i-a13-usb-phy", .data = &sun5i_a13_cfg },
> @@ -1038,6 +1049,7 @@ static const struct of_device_id 
> sun4i_usb_phy_of_match[] = {   	{ .compatible = "allwinner,sun50i-a64-usb-phy",
>   	  .data = &sun50i_a64_cfg},
>   	{ .compatible = "allwinner,sun50i-h6-usb-phy", .data = &sun50i_h6_cfg },
> + { .compatible = "allwinner,sun50i-h616-usb-phy", .data = 
> &sun50i_h616_cfg },   	{ },
>   };
>   MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
> -- 
> 2.17.5
>