linux-kernel - Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x

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: <20140617112353.GB4139@lee--X1>
Date:	Tue, 17 Jun 2014 12:23:53 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Kishon Vijay Abraham I <kishon@...com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the
 MiPHY365x

> > The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> > devices. It has 2 ports which it can use for either; both SATA, both
> > PCIe or one of each in any configuration.
> 
> I've asked others who wrote multi-phy PHY providers to model each individual
> PHY as sub-node of the PHY provider. So It's only fair I ask you the same to
> do. So in this case the dt node should look something like:
> 
> 	miphy365x_phy: miphy365x@...82000 {
> 		compatible = "st,miphy365x-phy";
> 		#phy-cells = <2>;
> 		st,syscfg = <&syscfg_rear>;
> 		channel@0 {
> 			reg =	<0xfe382000 0x100>, <0xfe394000 0x100>;
> 			reg-names = "sata", "pcie";
> 		}
> 
> 		channel@1{
> 			reg =	<0xfe38a000 0x100>, <0xfe804000 0x100>;
> 			reg-names = "sata", "pcie";
> 		}
> 
> 	};

I'm interested to know why you've taken this approach, as it makes the
code much more complex.  The DT framework goes to the trouble of
converting all addresses to to resources so drivers can easily pull
them out using platform_get_resource() and friends.  Pushing the reg
properties down into a child node means that we have to now iterate
over the sub-nodes and pull them out manually.  This will lead to a
pretty messy implementation IMHO.

Can you point me in the direction of previous implementations where you
have stipulated the same set of constraints please?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/