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:	Wed, 10 Jul 2013 11:27:24 +0100
From:	Srinivas KANDAGATLA <srinivas.kandagatla@...com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Russell King <linux@....linux.org.uk>, kernel@...inux.com,
	linux-kernel@...r.kernel.org, Stuart Menefy <stuart.menefy@...com>,
	Olof Johansson <olof@...om.net>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support

Hi Arnd,
On 09/07/13 22:15, Arnd Bergmann wrote:
>> For DT case, At the moment I think callbacks at MACH level is one
>> > possible solution. But am open for any discussions.
> Ok, so a PHY driver might not be the best place to put this, but it's
> one option, since the PHY driver already has to know about the
> interface speed you are setting.
> 
> Having a global "*_setup_ethernet" callback is definitely not the
> right way to go. Please describe what the function actually does
> so we can come up with the right subsystem to move that functionality
> to. If you are setting clocks, you should use the clock subsystem,
> for taking the device out of reset, you should use the reset controller
> subsystem and for setting up the phy, you should use the phy subsystem,
> etc.

The purpose of this callback is to do three things.

	1> Configuring the MAC signals to select particular PHY interface mode.
MAC signals(wires) are wired up to this Ethernet Configuration register.

	2> Select synchronisation clock for data lines retiming. On High speed
interfaces track length/layouts on the boards can directly influence the
signal quality and introduce bit shifts or other errors. So SoC has
additional logic to retime these signals and improve the data
reliability. As there is possibility of multiple clock sources (MAC,
PHY) a correct choice of synchronization clock is made in Ethernet
configuration register. For 125 Mhz clock in Gbit mode, reference clock
is provided by the PHY in other case like 100bit and 10bit, 50MHz, 25MHz
clocks is provide by the MAC.
So this bits depend/driven based on the PHYMODEs and Link Speed.

	3> Ethernet Soft reset in Ethernet control register.
		Which can probably go into via reset controller driver.


For point 1 and 2, there is no subsystem in the kernel which can
accommodate these kind of SOC specific bits setup. Am not sure if other
platforms have similar SoC setup use cases?

For point 3, I can go for reset controller API.

Just for your reference (Sorry and Please ignore if Its too detailed),
Ethernet configuration register looks like:
Bit to configure signals connected to MAC.
	[5] ENMII1: when 1, MII mode
		when 0, Reverse MII mode
	[4:2] MII1_PHY_SEL:
		000: GMII/MII (default)
		001: RGMII
		010: SGMII
		100: RMII

Bit to configure retiming clock for retiming data lines:
	[8] ETH1_SEL_TX_RETIMING_CLK: Selection of the clock used to retime TX data
		0: clock selected by ETH1_SEL_TXCLK_NOT_CLK125 bit
		1: clock fed to or provided by MII_PHYCLK depending
		on eth1_sel_internal_notext_phyclk setting
	[7] ETH1_SEL_INTERNAL_NOTEXT_PHYCLK: Selection of internal clock or
external clock from MII_PHYCLK for retiming in RMII mode
		0: external clock (Beware that eth1_sel_tx_retiming_clk
		bit must also be programmed).
		1: internal clock (from clockgenA)
	[6] ETH1_SEL_TXCLK_NOT_CLK125: Selection of the clock used to
	retime TX data
		0: MII1_CLK_125 (beware that eth1_sel_tx_retiming_clk bit must also be
programmed)
		1: MII1_TXCLK

Thanks,
srini
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ