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] [day] [month] [year] [list]
Date:	Thu, 24 Mar 2016 16:35:16 +0100
From:	Heiko Stübner <heiko@...ech.de>
To:	Shawn Lin <shawn.lin@...k-chips.com>
Cc:	kishon@...com, linux-rockchip@...ts.infradead.org,
	linux-kernel@...r.kernel.org, ykk@...k-chips.com,
	devicetree@...r.kernel.org, robh+dt@...nel.org, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org
Subject: Re: [PATCH 2/2] phy: rockchip-emmc: should be a child device of the GRF

Hi Shawn,

Am Donnerstag, 24. März 2016, 21:36:05 schrieb Shawn Lin:
> 在 2016/3/24 21:22, Heiko Stuebner 写道:
> > The emmc-phy is fully enclosed in the general register files (GRF).
> > Therefore as seen from the device-tree it shouldn't be a separate
> > platform-
> > device but instead a sub-device of the GRF - using the simply-mfd
> > mechanism.
> > 
> > The driver entered the kernel in the current merge-window, so we can still
> > adapt the binding without needing a fallback, as the binding hasn't been
> > released with a full kernel yet.
> > 
> > Signed-off-by: Heiko Stuebner <heiko@...ech.de>
> > ---
> > Hi Shawn, Kishon,
> > 
> > I didn't see this new phy driver until now, so I'd really like to get
> > this sorted before the old binding solidifies :-).
> > 
> > I'll convert the usbphy as well, but that has to have the fallback for
> > the old binding, so is not as urgent as these two.
> > 
> > As mentioned in the patch description above, this is meant as a fixup for
> > kernel 4.6.
> > 
> > 
> > One thing I noticed, the emmc phy is occupying the range 0xf780-0xf7a0,
> > so shouldn't the reg property reflect that, like
> > 
> >      reg = <0xf780 0x20>;
> > 
> > to stay with common conventions?
> 
> yes, and I had a fix[0] for it waiting for Kishon's reviewing.

please try to always include both me and the linux-rockchip list for Rockchip 
specific changes in the future :-) .

In any case, I do think going with a reg property might be more standard 
conformant, once it is under the GRF. Of course only for sub-devices that 
actually occupy a real block inside the GRF like your emmc phy or the new 
usbphy blocks.

So I guess the dts should probably look like:


grf: syscon@...70000 {
	compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
	#address-cells = <1>;
	#size-cells = <1>;

	emmcphy: phy@...0 {
		compatible = "rockchip,rk3399-emmc-phy";
		reg = <0xf780 0x20>;
		#phy-cells = <0>;
	};
 };


> [0]:
> http://lkml.org/lkml/2016/3/8/114
> 
> >   .../devicetree/bindings/phy/rockchip-emmc-phy.txt     | 19
> >   ++++++++++++------- drivers/phy/phy-rockchip-emmc.c                    
> >     |  5 ++++-
> >   2 files changed, 16 insertions(+), 8 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> > b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt index
> > 61916f1..d711259 100644
> > --- a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> > +++ b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> > @@ -3,17 +3,22 @@ Rockchip EMMC PHY
> > 
> >   Required properties:
> >    - compatible: rockchip,rk3399-emmc-phy
> > 
> > - - rockchip,grf : phandle to the syscon managing the "general
> > -   register files"
> > 
> >    - #phy-cells: must be 0
> >    - reg: PHY configure reg address offset in "general
> >    
> >      register files"
> >   
> >   Example:
> > -emmcphy: phy {
> > -	compatible = "rockchip,rk3399-emmc-phy";
> > -	rockchip,grf = <&grf>;
> > -	reg = <0xf780>;
> > -	#phy-cells = <0>;
> > +
> > +grf: syscon@...70000 {
> > +	compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
> > +
> > +...
> > +
> > +	emmcphy: phy@...0 {
> > +		compatible = "rockchip,rk3399-emmc-phy";
> > +		rockchip,grf = <&grf>;

I just saw I missed to remove that now obsolete rockchip,grf property.


> > +		reg = <0xf780>;
> > +		#phy-cells = <0>;
> > +	};
> > 
> >   };
> > 
> > diff --git a/drivers/phy/phy-rockchip-emmc.c
> > b/drivers/phy/phy-rockchip-emmc.c index 887b4c2..6ebcf3e 100644
> > --- a/drivers/phy/phy-rockchip-emmc.c
> > +++ b/drivers/phy/phy-rockchip-emmc.c
> > @@ -176,7 +176,10 @@ static int rockchip_emmc_phy_probe(struct
> > platform_device *pdev)> 
> >   	struct regmap *grf;
> >   	unsigned int reg_offset;
> > 
> > -	grf = syscon_regmap_lookup_by_phandle(dev->of_node, "rockchip,grf");
> > +	if (!dev->parent || !dev->parent->of_node)
> > +		return -ENODEV;
> > +
> > +	grf = syscon_node_to_regmap(dev->parent->of_node);
> > 
> >   	if (IS_ERR(grf)) {
> >   	
> >   		dev_err(dev, "Missing rockchip,grf property\n");
> >   		return PTR_ERR(grf);

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ