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
| ||
|
Date: Wed, 29 Jan 2014 15:24:35 +0100 From: Arnd Bergmann <arnd@...db.de> To: Pratyush Anand <pratyush.anand@...com> Cc: Kishon Vijay Abraham I <kishon@...com>, Mohit KUMAR DCG <Mohit.KUMAR@...com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, spear-devel@...t.st.com Subject: Re: Query: Phy: How to find consumer device on dt platform On Wednesday 29 January 2014, Pratyush Anand wrote: > On Wed, Jan 29, 2014 at 01:41:56PM +0800, Kishon Vijay Abraham I wrote: > > > > > > I would instead recommend making the mode of the PHY device the > > > argument to the phy handle in DT, so that the sata node uses > > > > > > phys = <&phyA 0>; > > > > > > and the PCIe node uses > > > > > > phys = <&phyB 1>; > > > > > > Then the binding for the phy defines that an argument of '0' means sata mode, > > > while '1' means pcie mode, plus you should define all other valid modes. > > Probably, it may not help in this case. How would *phys* defining as > above with PCIe/SATA node help phy driver to decide whether current > phy instance is associated with PCIe or SATA. Actually, there is no > way to pass information from phy consumer driver(pcie/sata driver in > this case) to phy driver. I don't understand what is unclear about my example where I do just that. The argument (0 or 1) gets passed into the driver's xlate function when the consumer calls of_phy_get(). > > Anyway phyA and phyB points to different nodes and just from phyA and phyB we > > should be able to tell whether it is sata or pcie. > > We have multiple instances (say 3) of same phy, which can be > programmed either for pcie or for sata. We have multiple instances of > ahci and pcie controller. phy_n will be connected to either ahci_n or > pcie_n. > > What Kishon has suggested here is exactly what I was thinking. > I think, we should go with this. I still find it highly inconsistent. Arnd -- 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/
Powered by blists - more mailing lists