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: Tue, 29 Aug 2017 17:55:06 +0530 From: Kishon Vijay Abraham I <kishon@...com> To: Antoine Tenart <antoine.tenart@...e-electrons.com> CC: <davem@...emloft.net>, <andrew@...n.ch>, <jason@...edaemon.net>, <sebastian.hesselbarth@...il.com>, <gregory.clement@...e-electrons.com>, <thomas.petazzoni@...e-electrons.com>, <nadavh@...vell.com>, <linux@...linux.org.uk>, <linux-kernel@...r.kernel.org>, <mw@...ihalf.com>, <stefanc@...vell.com>, <miquel.raynal@...e-electrons.com>, <netdev@...r.kernel.org> Subject: Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver Hi, On Tuesday 29 August 2017 04:53 PM, Antoine Tenart wrote: > Hi Kishon, > > On Tue, Aug 29, 2017 at 04:34:17PM +0530, Kishon Vijay Abraham I wrote: >> On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote: >>> >>> +config PHY_MVEBU_CP110_COMPHY >>> + tristate "Marvell CP110 comphy driver" >>> + depends on ARCH_MVEBU && OF >> >> (ARCH_MVEBU || COMPILE_TEST) above.. > > Sure, I'll update. > >>> +static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = { >>> + /* lane 0 */ >>> + MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1), >>> + /* lane 1 */ >>> + MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1), >>> + /* lane 2 */ >>> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1), >>> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1), >>> + /* lane 3 */ >>> + MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2), >>> + /* lane 4 */ >>> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2), >>> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2), >>> + MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1), >>> + /* lane 5 */ >>> + MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1), >>> +}; >> >> IMHO all the lane and mode configuration should come from dt. That would make >> it more reusable when comphy is configured differently. > > These connexions between engines and the comphy lanes are inside the > SoC. They won't change for a given SoC, and the actual configuration is > at the board level to know what is connected to the output of a given > lane, which is already described into the dt (the lane phandle). > > So I think we can keep this inside the driver, and we'll had other > tables if the same comphy is ever used in another SoC. > > What do you think? I'd like to avoid adding tables for every SoC. These are configuration details and can come from dt. Thanks Kishon
Powered by blists - more mailing lists