linux-kernel - Re: [PATCH 1/2] Re: [PATCH 1/1] phy: rockchip: naneng-combphy: compatible with old DT for RK3568

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: <0b5eaa41745209a5a5368516d8433bb3319ca9b5.camel@pengutronix.de>
Date: Mon, 06 Jan 2025 10:19:36 +0100
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Chukun Pan <amadeus@....edu.cn>
Cc: heiko@...ech.de, kishon@...nel.org,
 linux-arm-kernel@...ts.infradead.org,  linux-kernel@...r.kernel.org,
 linux-phy@...ts.infradead.org,  linux-rockchip@...ts.infradead.org,
 liujianfeng1994@...il.com, vkoul@...nel.org
Subject: Re: [PATCH 1/2] Re: [PATCH 1/1] phy: rockchip: naneng-combphy:
 compatible with old DT for RK3568

On Mo, 2025-01-06 at 15:50 +0800, Chukun Pan wrote:
> Hi,
> > > diff --git a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> > > index a1532ef8bbe9..372f5c07b5bd 100644
> > > --- a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> > > +++ b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> > > @@ -325,6 +325,10 @@ static int rockchip_combphy_parse_dt(struct device *dev, struct rockchip_combphy
> > >  	priv->ext_refclk = device_property_present(dev, "rockchip,ext-refclk");
> > >  
> > >  	priv->phy_rst = devm_reset_control_get(dev, "phy");
> > 
> > This should be devm_reset_control_get_exclusive().
> 
> I will change this.
> 
> > > +	/* fallback to old behaviour */
> > > +	if (IS_ERR(ERR_PTR(priv->phy_rst)))
> > 
> > Drop superfluous ERR_PTR().
> 
> I think it would be better if I changed it to this?
> 
> if (PTR_ERR(priv->phy_rst) == -ENOENT)
> 	priv->phy_rst = devm_reset_control_array_get_exclusive(dev);

I agree, otherwise this would ignore a broken reset-names property in
the device tree. When the resets property is broken, the fallback would
fail anyway.

regards
Philipp