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]
Date:	Fri, 23 Mar 2012 09:53:02 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Giuseppe CAVALLARO" <peppe.cavallaro@...com>,
	<netdev@...r.kernel.org>
Cc:	<davem@...emloft.net>, <srinivas.kandagatla@...com>,
	<deepak.sikri@...com>, <spear-devel@...t.st.com>,
	<shiraz.hashim@...com>, <viresh.kumar@...com>,
	<bhutchings@...arflare.com>
Subject: RE: [PATCH 09/10] stmmac: MDC clock dynamically based on the csr clock input

 

> -----Original Message-----
> From: netdev-owner@...r.kernel.org 
> [mailto:netdev-owner@...r.kernel.org] On Behalf Of Giuseppe CAVALLARO
> Sent: 23 March 2012 09:09
> To: netdev@...r.kernel.org
> Cc: davem@...emloft.net; srinivas.kandagatla@...com; 
> deepak.sikri@...com; spear-devel@...t.st.com; 
> shiraz.hashim@...com; viresh.kumar@...com; 
> bhutchings@...arflare.com; Giuseppe Cavallaro
> Subject: [PATCH 09/10] stmmac: MDC clock dynamically based on 
> the csr clock input
> 
> If a specific clk_csr value is passed from the platform
> this means that the CSR Clock Range selection cannot be
> changed at run-time and it is fixed (as reported in the driver
> documentation). Viceversa the driver will try to set the MDC
> clock dynamically according to the actual clock input.
> 
> Signed-off-by: Deepak Sikri <deepak.sikri@...com>
> Reviewed-by: Francesco Virlinzi <francesco.virlinzi@...com>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@...com>
> ---
>  Documentation/networking/stmmac.txt               |    2 +-
>  drivers/net/ethernet/stmicro/stmmac/common.h      |   10 +++++
>  drivers/net/ethernet/stmicro/stmmac/stmmac.h      |    1 +
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |   40 
> +++++++++++++++++++++
>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |    4 +-
>  5 files changed, 54 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/networking/stmmac.txt 
> b/Documentation/networking/stmmac.txt
> index eacb640..ab1e8d7 100644
> --- a/Documentation/networking/stmmac.txt
> +++ b/Documentation/networking/stmmac.txt
> @@ -137,7 +137,7 @@ Where:
>   o pbl: the Programmable Burst Length is maximum number of beats to
>         be transferred in one DMA transaction.
>         GMAC also enables the 4xPBL by default.
> - o clk_csr: CSR Clock range selection.
> + o clk_csr: fixed CSR Clock range selection.
>   o has_gmac: uses the GMAC core.
>   o enh_desc: if sets the MAC will use the enhanced 
> descriptor structure.
>   o tx_coe: core is able to perform the tx csum in HW.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
> b/drivers/net/ethernet/stmicro/stmmac/common.h
> index f4df1eb..312e3f1 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> @@ -97,6 +97,16 @@ struct stmmac_extra_stats {
>  	unsigned long normal_irq_n;
>  };
>  
> +/* CSR Frequency Access Defines*/
> +#define CSR_F_35M	35000000
> +#define CSR_F_60M	60000000
> +#define CSR_F_100M	100000000
> +#define CSR_F_150M	150000000
> +#define CSR_F_250M	50000000
> +#define CSR_F_300M	300000000

The value of CSR_F_250M looks like a typo.
These defines look rather pointless to me though!

Another patch has:
> -----------------------------------------
> 	Selection	MDC Clock
> -----------------------------------------
>	1000 		clk_csr_i/4
>	1001 		clk_csr_i/6
>	1010 		clk_csr_i/8
>	1011 		clk_csr_i/10
>	1100 		clk_csr_i/12
>	1101	 	clk_csr_i/14
>	1110 		clk_csr_i/16
>	1111 		clk_csr_i/18
I detect a pattern ...

	David



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ