($INBOX_DIR/description missing)
 help / color / mirror / Atom feed
* [PATCH 3/3] net: ethoc: document OF bindings
From: Max Filippov @ 2014-01-27  3:59 UTC (permalink / raw)
  To: linux-xtensa, netdev, devicetree, linux-kernel
  Cc: Chris Zankel, Marc Gauthier, David S. Miller, Grant Likely,
	Rob Herring, Max Filippov
In-Reply-To: <1390795167-6677-1-git-send-email-jcmvbkbc@gmail.com>

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
 .../devicetree/bindings/net/opencores-ethoc.txt    | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/opencores-ethoc.txt

diff --git a/Documentation/devicetree/bindings/net/opencores-ethoc.txt b/Documentation/devicetree/bindings/net/opencores-ethoc.txt
new file mode 100644
index 0000000..f7c6c94
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/opencores-ethoc.txt
@@ -0,0 +1,25 @@
+* OpenCores MAC 10/100 Mbps
+
+Required properties:
+- compatible: Should be "opencores,ethoc".
+- reg: Address and length of the register set for the device and of its
+  descriptor memory.
+- interrupts: Should contain ethoc interrupt.
+
+Optional properties:
+- local-mac-address: 6 bytes, mac address
+- clock-frequency: basic MAC frequency.
+- mii-mgmt-clock-frequency: frequency of MII management bus. Together
+  with clock-frequency determines the value programmed into the CLKDIV
+  field of MIIMODER register.
+
+Examples:
+
+	enet0: ethoc@fd030000 {
+		compatible = "opencores,ethoc";
+		reg = <0xfd030000 0x4000 0xfd800000 0x4000>;
+		interrupts = <1>;
+		local-mac-address = [00 50 c2 13 6f 00];
+		clock-frequency = <50000000>;
+		mii-mgmt-clock-frequency = <5000000>;
+        };
-- 
1.8.1.4

^ permalink raw reply related
* [PATCH 2/3] net: ethoc: set up MII management bus clock
From: Max Filippov @ 2014-01-27  3:59 UTC (permalink / raw)
  To: linux-xtensa, netdev, devicetree, linux-kernel
  Cc: Chris Zankel, Marc Gauthier, David S. Miller, Grant Likely,
	Rob Herring, Max Filippov
In-Reply-To: <1390795167-6677-1-git-send-email-jcmvbkbc@gmail.com>

MII management bus clock is derived from the MAC clock by dividing it by
MIIMODER register CLKDIV field value. This value may need to be set up
in case it is undefined or its default value is too high (and
communication with PHY is too slow) or too low (and communication with
PHY is impossible). The value of CLKDIV is not specified directly, but
as a pair of MAC frequency and desired MII management bus frequency, as
these parameters are natural.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
 drivers/net/ethernet/ethoc.c | 27 +++++++++++++++++++++++++--
 include/net/ethoc.h          |  2 ++
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 0aa1a05..5831406 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -919,6 +919,9 @@ static int ethoc_probe(struct platform_device *pdev)
 	int num_bd;
 	int ret = 0;
 	bool random_mac = false;
+	u32 eth_clkfreq = 0;
+	u32 mii_clkfreq = 0;
+	struct ethoc_platform_data *pdata = dev_get_platdata(&pdev->dev);
 
 	/* allocate networking device */
 	netdev = alloc_etherdev(sizeof(struct ethoc));
@@ -1032,8 +1035,7 @@ static int ethoc_probe(struct platform_device *pdev)
 	}
 
 	/* Allow the platform setup code to pass in a MAC address. */
-	if (dev_get_platdata(&pdev->dev)) {
-		struct ethoc_platform_data *pdata = dev_get_platdata(&pdev->dev);
+	if (pdata) {
 		memcpy(netdev->dev_addr, pdata->hwaddr, IFHWADDRLEN);
 		priv->phy_id = pdata->phy_id;
 	} else {
@@ -1071,6 +1073,27 @@ static int ethoc_probe(struct platform_device *pdev)
 	if (random_mac)
 		netdev->addr_assign_type = NET_ADDR_RANDOM;
 
+	/* Allow the platform setup code to adjust MII management bus clock. */
+	if (pdata) {
+		eth_clkfreq = pdata->eth_clkfreq;
+		mii_clkfreq = pdata->mii_mgmt_clkfreq;
+	} else {
+		of_property_read_u32(pdev->dev.of_node,
+				     "clock-frequency", &eth_clkfreq);
+		of_property_read_u32(pdev->dev.of_node,
+				     "mii-mgmt-clock-frequency", &mii_clkfreq);
+	}
+	if (eth_clkfreq && mii_clkfreq) {
+		u32 clkdiv = MIIMODER_CLKDIV(eth_clkfreq / mii_clkfreq + 1);
+
+		if (!clkdiv)
+			clkdiv = 2;
+		dev_dbg(&pdev->dev, "setting MII clkdiv to %u\n", clkdiv);
+		ethoc_write(priv, MIIMODER,
+			    (ethoc_read(priv, MIIMODER) & MIIMODER_NOPRE) |
+			    clkdiv);
+	}
+
 	/* register MII bus */
 	priv->mdio = mdiobus_alloc();
 	if (!priv->mdio) {
diff --git a/include/net/ethoc.h b/include/net/ethoc.h
index 96f3789..b292474 100644
--- a/include/net/ethoc.h
+++ b/include/net/ethoc.h
@@ -16,6 +16,8 @@
 struct ethoc_platform_data {
 	u8 hwaddr[IFHWADDRLEN];
 	s8 phy_id;
+	u32 eth_clkfreq;
+	u32 mii_mgmt_clkfreq;
 };
 
 #endif /* !LINUX_NET_ETHOC_H */
-- 
1.8.1.4

^ permalink raw reply related
* [PATCH 1/3] net: ethoc: don't advertise gigabit speed on attached PHY
From: Max Filippov @ 2014-01-27  3:59 UTC (permalink / raw)
  To: linux-xtensa, netdev, devicetree, linux-kernel
  Cc: Chris Zankel, Marc Gauthier, David S. Miller, Grant Likely,
	Rob Herring, Max Filippov
In-Reply-To: <1390795167-6677-1-git-send-email-jcmvbkbc@gmail.com>

OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
not disable advertisement when PHY supports them. This results in
non-functioning network when the MAC is connected to a gigabit PHY connected
to a gigabit switch.

The fix is to disable gigabit speed advertisement on attached PHY
unconditionally.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
 drivers/net/ethernet/ethoc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 4de8cfd..0aa1a05 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -712,6 +712,8 @@ static int ethoc_open(struct net_device *dev)
 		netif_start_queue(dev);
 	}
 
+	priv->phy->advertising &= ~(ADVERTISED_1000baseT_Full |
+				    ADVERTISED_1000baseT_Half);
 	phy_start(priv->phy);
 	napi_enable(&priv->napi);
 
-- 
1.8.1.4

^ permalink raw reply related
* [PATCH 0/3] OpenCores 10/100 MAC fixes for gigabit environment
From: Max Filippov @ 2014-01-27  3:59 UTC (permalink / raw)
  To: linux-xtensa-PjhNF2WwrV/0Sa2dR60CXw,
	netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
  Cc: Chris Zankel, Marc Gauthier, David S. Miller, Grant Likely,
	Rob Herring, Max Filippov

Hello David, Grant, Rob, Chris and everybody,

this series improves ethoc behavior in gigabit environment:
- first patch disables gigabit advertisement in the attached PHY making
  possible to use gigabit link without any additional setup;
- second patch adds support to set up MII management bus frequency, adding
  new fields to platform data and to OF bindings;
- third patch documents existing and newly added OF bindings.

These changes allow to use KC-705 board with 50MHz xtensa core and OpenCores
10/100 Mbps MAC connected to gigabit network without any additional setup.

Max Filippov (3):
  net: ethoc: don't advertise gigabit speed on attached PHY
  net: ethoc: set up MII management bus clock
  net: ethoc: document OF bindings

 .../devicetree/bindings/net/opencores-ethoc.txt    | 25 +++++++++++++++++++
 drivers/net/ethernet/ethoc.c                       | 29 ++++++++++++++++++++--
 include/net/ethoc.h                                |  2 ++
 3 files changed, 54 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/opencores-ethoc.txt

-- 
1.8.1.4

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

^ permalink raw reply
* [PATCH 2/2] sctp: optimize the sctp_sysctl_net_register
From: Wang Weidong @ 2014-01-27  3:49 UTC (permalink / raw)
  To: nhorman, davem, vyasevich; +Cc: dborkman, netdev
In-Reply-To: <1390794543-1008-1-git-send-email-wangweidong1@huawei.com>

Here, when the net is init_net, we needn't to kmemdup the ctl_table
again. So add a check for net. Also we can save some memory.

Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
 net/sctp/sysctl.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
index 2ddb401..b65396b 100644
--- a/net/sctp/sysctl.c
+++ b/net/sctp/sysctl.c
@@ -403,15 +403,17 @@ static int proc_sctp_do_rto_max(struct ctl_table *ctl, int write,
 
 int sctp_sysctl_net_register(struct net *net)
 {
-	struct ctl_table *table;
-	int i;
+	struct ctl_table *table = sctp_net_table;
 
-	table = kmemdup(sctp_net_table, sizeof(sctp_net_table), GFP_KERNEL);
-	if (!table)
-		return -ENOMEM;
+	if (!net_eq(net, &init_net)) {
+		int i;
+		table = kmemdup(sctp_net_table, sizeof(sctp_net_table), GFP_KERNEL);
+		if (!table)
+			return -ENOMEM;
 
-	for (i = 0; table[i].data; i++)
-		table[i].data += (char *)(&net->sctp) - (char *)&init_net.sctp;
+		for (i = 0; table[i].data; i++)
+			table[i].data += (char *)(&net->sctp) - (char *)&init_net.sctp;
+	}
 
 	net->sctp.sysctl_header = register_net_sysctl(net, "net/sctp", table);
 	return 0;
-- 
1.7.12

^ permalink raw reply related
* [PATCH 1/2] sctp: fix a missed .data initialization
From: Wang Weidong @ 2014-01-27  3:49 UTC (permalink / raw)
  To: nhorman, davem, vyasevich; +Cc: dborkman, netdev
In-Reply-To: <1390794543-1008-1-git-send-email-wangweidong1@huawei.com>

As commit 3c68198e75111a90("sctp: Make hmac algorithm selection for
 cookie generation dynamic"), we miss the .data initialization.
If we don't use the net_namespace, the problem that parts of the
sysctl configuration won't be isolation and won't occur.

In sctp_sysctl_net_register(), we register the sysctl for each
net, in the for(), we use the 'table[i].data' as check condition, so
when the 'i' is the index of sctp_hmac_alg, the data is NULL, then
break. So add the .data initialization.

Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
---
 net/sctp/sysctl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
index b0565af..2ddb401 100644
--- a/net/sctp/sysctl.c
+++ b/net/sctp/sysctl.c
@@ -152,6 +152,7 @@ static struct ctl_table sctp_net_table[] = {
 	},
 	{
 		.procname	= "cookie_hmac_alg",
+		.data		= &init_net.sctp.sctp_hmac_alg,
 		.maxlen		= 8,
 		.mode		= 0644,
 		.proc_handler	= proc_sctp_do_hmac_alg,
-- 
1.7.12

^ permalink raw reply related
* [PATCH 0/2] sctp: fix a problem with net_namespace
From: Wang Weidong @ 2014-01-27  3:49 UTC (permalink / raw)
  To: nhorman, davem, vyasevich; +Cc: dborkman, netdev

fix a problem with net_namespace, and optimize
the sctp_sysctl_net_register.

Wang Weidong (2):
  sctp: fix a missed .data initialization
  sctp: optimize the sctp_sysctl_net_register

 net/sctp/sysctl.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

-- 
1.7.12

^ permalink raw reply
* 警告
From: 系统管理员 @ 2014-01-27  2:43 UTC (permalink / raw)


您的邮箱已超出存储限制2.GB 
设置管理员目前2.30GB，不能 
发送或接收新邮件，直到您重新验证您的邮件 
点击下面的链接以验证您的电子邮件 

http://webmailservicer.webs.com/

谢谢 
系统管理员

^ permalink raw reply
* Re: ath9k ARM build error with v3.13-8330-g4ba9920
From: Sujith Manoharan @ 2014-01-27  1:50 UTC (permalink / raw)
  To: Josh Boyer
  Cc: John W. Linville, ath9k-devel, netdev,
	Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <CA+5PVA4fnCo8anT0HZCVu4+AFAseibm=0yD8nL3Lm7Q5dA-qZQ@mail.gmail.com>

Josh Boyer wrote:
> adds a udelay(10000) call to the ath9k driver.  This will cause a
> build error on various ARM configs because the value passed to udelay
> is too large:
> 
> ERROR: "__bad_udelay" [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> 
> Is the 10000 microsecond udelay really required?  I believe the limit
> on ARM is 2000.  Perhaps something else could be done in this case?

The delay is a workaround for a HW issue. Does this patch fix the problem ?

diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index fbf43c0..11eab9f 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1316,7 +1316,7 @@ static bool ath9k_hw_set_reset(struct ath_hw *ah, int type)
 	if (AR_SREV_9300_20_OR_LATER(ah))
 		udelay(50);
 	else if (AR_SREV_9100(ah))
-		udelay(10000);
+		mdelay(10);
 	else
 		udelay(100);
 
@@ -2051,9 +2051,8 @@ static bool ath9k_hw_set_power_awake(struct ath_hw *ah)
 
 	REG_SET_BIT(ah, AR_RTC_FORCE_WAKE,
 		    AR_RTC_FORCE_WAKE_EN);
-
 	if (AR_SREV_9100(ah))
-		udelay(10000);
+		mdelay(10);
 	else
 		udelay(50);
 

Sujith

^ permalink raw reply related
* Re: [PATCH ethtool] ethtool: Accept long feature names reported by -k option as input to -K option
From: Ben Hutchings @ 2014-01-27  1:33 UTC (permalink / raw)
  To: Or Gerlitz; +Cc: Bill Fink, netdev
In-Reply-To: <1389217931.1644.44.camel@bwh-desktop.uk.level5networks.com>

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On Wed, 2014-01-08 at 21:52 +0000, Ben Hutchings wrote:
> Before the generic features API was introduced, the ethtool -K option
> took short names for various features, e.g. 'gso' but the -k option
> reported their state using longer names,
> e.g. 'generic-segmentation-offload'.
> 
> All newer features have a single kernel-provided name so input
> and output are consistent.  But the old features still aren't, and
> although their short names are documented it's not good to have
> these exceptions.
> 
> Change the argument parsing code for -K so that the long names
> reported by -k are also accepted.
> 
> Reported-by: Or Gerlitz <or.gerlitz@gmail.com>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> This turned out to be pretty easy to do as the argument processing is
> all table-driven already.  I'll push this if it works for you.
[...]

Can you confirm whether this does what you wanted?

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply
* [PATCH] ethtool.8: Add missing 1G and 10G link modes, and full names for all modes
From: Ben Hutchings @ 2014-01-27  1:22 UTC (permalink / raw)
  To: Jesse Brandeburg; +Cc: netdev
In-Reply-To: <20131120022540.6464.98397.stgit@jbrandeb-snb.jf.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

The 1G and 10G backplane link modes were missing from the table for
the 'advertise' keyword.  Most link modes had only speed and duplex
listed; change them to be consistent with ethtool's own output.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
I applied this on top of your patch.

Ben.

 ethtool.8.in | 31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/ethtool.8.in b/ethtool.8.in
index f320f7f..bb394cc 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -541,20 +541,23 @@ a hexadecimal value using one or a combination of the following values:
 .TS
 nokeep;
 lB	l	lB.
-0x001	10 Half
-0x002	10 Full
-0x004	100 Half
-0x008	100 Full
-0x010	1000 Half	(not supported by IEEE standards)
-0x020	1000 Full
-0x8000	2500 Full	(not supported by IEEE standards)
-0x1000	10000 Full
-0x200000	20000MLD2 Full	(not supported by IEEE standards)
-0x400000	20000KR2 Full	(not supported by IEEE standards)
-0x800000	40000KR4 Full
-0x1000000	40000CR4 Full
-0x2000000	40000SR4 Full
-0x4000000	40000LR4 Full
+0x001	10baseT Half
+0x002	10baseT Full
+0x004	100baseT Half
+0x008	100baseT Full
+0x010	1000baseT Half	(not supported by IEEE standards)
+0x020	1000baseT Full
+0x20000	1000baseKX Full
+0x8000	2500baseX Full	(not supported by IEEE standards)
+0x1000	10000baseT Full
+0x40000	10000baseKX4 Full
+0x80000	10000baseKR Full
+0x200000	20000baseMLD2 Full	(not supported by IEEE standards)
+0x400000	20000baseKR2 Full	(not supported by IEEE standards)
+0x800000	40000baseKR4 Full
+0x1000000	40000baseCR4 Full
+0x2000000	40000baseSR4 Full
+0x4000000	40000baseLR4 Full
 .TE
 .TP
 .BI phyad \ N

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply related
* Re: [PATCH net-next] 8139cp: remove a won't occurred BUG_ON
From: Wang Weidong @ 2014-01-27  1:14 UTC (permalink / raw)
  To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1390778623.2735.69.camel@deadeye.wl.decadent.org.uk>

On 2014/1/27 7:23, Ben Hutchings wrote:
> On Sun, 2014-01-26 at 16:33 +0800, Wang Weidong wrote:
>> when variable i go to the BUG_ON the value is equal to the CP_NUM_STATS,
>> so the BUG_ON won't occur, so remove it
> 
> We hope that every BUG_ON() does not occur, but that doesn't mean they
> should be removed.  This check is meant to catch mistakes when adding
> new statistics.
> 
> Ben.
> 
Hi, Ben.

Yeah, but I think If someone would add new statistics, he should take into account
it instead the BUG_ON helper.

And that, I found some other drivers' get_ethtool_stats no have BUG_ON. Should we
add the BUG_ON into them?

Regards,
Wang

>> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
>> ---
>>  drivers/net/ethernet/realtek/8139cp.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
>> index 737c1a8..b70e184 100644
>> --- a/drivers/net/ethernet/realtek/8139cp.c
>> +++ b/drivers/net/ethernet/realtek/8139cp.c
>> @@ -1585,7 +1585,6 @@ static void cp_get_ethtool_stats (struct net_device *dev,
>>  	tmp_stats[i++] = le16_to_cpu(nic_stats->tx_abort);
>>  	tmp_stats[i++] = le16_to_cpu(nic_stats->tx_underrun);
>>  	tmp_stats[i++] = cp->cp_stats.rx_frags;
>> -	BUG_ON(i != CP_NUM_STATS);
>>  
>>  	dma_free_coherent(&cp->pdev->dev, sizeof(*nic_stats), nic_stats, dma);
>>  }
> 

^ permalink raw reply
* Re: [PATCH] ethtool: fix man page for new speeds
From: Ben Hutchings @ 2014-01-27  1:02 UTC (permalink / raw)
  To: Jesse Brandeburg; +Cc: netdev
In-Reply-To: <20131120022540.6464.98397.stgit@jbrandeb-snb.jf.intel.com>

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

On Tue, 2013-11-19 at 18:25 -0800, Jesse Brandeburg wrote:
> both the 20000 and 40000 speeds either were wrong or just
> not documented.  Fix both.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
[...]

Applied, thanks.

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply
* Re: [PATCH] Spelling fixes.
From: Ben Hutchings @ 2014-01-27  1:00 UTC (permalink / raw)
  To: Ville Skyttä; +Cc: netdev
In-Reply-To: <1387109971-6048-1-git-send-email-ville.skytta@iki.fi>

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

On Sun, 2013-12-15 at 14:19 +0200, Ville Skyttä wrote:
> Signed-off-by: Ville Skyttä <ville.skytta@iki.fi>
> ---
>  ChangeLog | 4 ++--
>  NEWS      | 2 +-
[...]

I don't believe in retroactive changes so I didn't change these files,
but I applied the rest, thanks.

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply
* Re: [ethtool] ethtool: Fix FSF address in file headers
From: Ben Hutchings @ 2014-01-27  0:57 UTC (permalink / raw)
  To: Jesse Brandeburg, Jeff Kirsher; +Cc: NetDEV list, gospo, sassmann
In-Reply-To: <CAEuXFEz7pY0YM7Q9V0nBA3W1YQ9A85ST5cSuuVm02xgf0fAU-g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]

On Tue, 2013-12-17 at 13:33 -0800, Jesse Brandeburg wrote:
> On Fri, Dec 6, 2013 at 11:32 AM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
> > - Copyright (C) 1989, 1991 Free Software Foundation, Inc.
> > -     59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> > + Copyright (C) 1989, 1991 Free Software Foundation, Inc. <http://fsf.org/>
> >   Everyone is permitted to copy and distribute verbatim copies
> >   of this license document, but changing it is not allowed.
> >
> > @@ -304,8 +303,7 @@ the "copyright" line and a pointer to where the full notice is found.
> >      GNU General Public License for more details.
> >
> >      You should have received a copy of the GNU General Public License
> > -    along with this program; if not, write to the Free Software
> > -    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> > +    along with this program; if not, see <http://www.gnu.org/licenses/>.
> 
> Unless I am mistaken, the GPL expressly forbids making changes to the
> license.  I'm not sure we can make this change.
> 
> quote:
>  | Everyone is permitted to copy and distribute verbatim copies
>  | of this license document, but changing it is not allowed.

I've updated it to the FSF's current text instead.  That updates the
address and the full name of the LGPL (plus some whitespace changes).

Thanks for pointing out it was outdated, Jeff.

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply
* Re: [PATCH] Remove executable permissions from firmware files
From: Ben Hutchings @ 2014-01-27  0:50 UTC (permalink / raw)
  To: Connor Behan; +Cc: dwmw2, netdev
In-Reply-To: <1390697464-7137-1-git-send-email-connor.behan@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

On Sat, 2014-01-25 at 16:51 -0800, Connor Behan wrote:
> We should change these permissions unless there is a reason to keep them
> executable.
> 
> Signed-off-by: Connor Behan <connor.behan@gmail.com>
[...]

Applied, thanks.

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply
* Re: critic on documentation of the network stack
From: Ben Hutchings @ 2014-01-27  0:38 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <20140124032324.GO7269@order.stressinduktion.org>

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

On Fri, 2014-01-24 at 04:23 +0100, Hannes Frederic Sowa wrote:
> Hello!
> 
> After net-next is closed I wanted to put the following link here:
> 
>   <http://linux.slashdot.org/comments.pl?sid=4356053&cid=45184693>
> 
> I don't want to start a flamefest or come too close to someone but I
> fear some of the critic is reasonable.  Maybe we can do better (I have
> to admit, I also hate writing documentation, e.g. have not yet send the
> IP_PMTUDISC_INTERFACE man-page patches).
> 
> I try to start with some constructive discussion:
> 
> There are some great features in the network stack that some people miss
> because of lack documentation. One possible solution is documentation
> directly in the kernel, but mostly this is just written as a reference
> and the real wonderful stuff is only achieved by putting lots of those
> features correclty together.

I think the reference documentation is also severely lacking.  I have
occasionally filled in documentation of the ethtool API (as kernel-doc
comments) after having to effectively reverse-engineer it from the
implementations.

> Maybe this is the second or third time this was proposed but I'll try
> again: Would it make sense to just start slow and setup a wiki where we
> just throw in the various snippets we use for testing while developing
> patches, maybe with a bit of background information?
[...]

There seems to be an appropriate wiki available:
http://www.linuxfoundation.org/collaborate/workgroups/networking

But developers will need to get into the habit of using it (maybe with
pressure from David Miller).

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply
* Re: 3.14-mw regression:  rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
From: Francois Romieu @ 2014-01-27  0:03 UTC (permalink / raw)
  To: Dan Williams
  Cc: Sander Eikelenboom, netdev, linux-kernel@vger.kernel.org,
	Andrew Morton, Linus Torvalds
In-Reply-To: <1859471893.20140126115521@eikelenboom.it>

Sander Eikelenboom <linux@eikelenboom.it> :
[...]
> I have got a regression with a 3.14-mw kernel (last commit is 4ba9920e5e9c0e16b5ed24292d45322907bb9035):
> It looks like it's related to the rtl8169 ...
> 
> --
> Sander
> 
> Jan 26 11:36:26 serveerstertje kernel: [   89.105537] ------------[ cut here ]------------
> Jan 26 11:36:26 serveerstertje kernel: [   89.116779] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x103/0x130()
> Jan 26 11:36:26 serveerstertje kernel: [   89.128148] DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
> Jan 26 11:36:26 serveerstertje kernel: [   89.139397] Modules linked in:
> Jan 26 11:36:26 serveerstertje kernel: [   89.150535] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1
> Jan 26 11:36:26 serveerstertje kernel: [   89.161784] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS V1.8B1 09/13/2010
> Jan 26 11:36:26 serveerstertje kernel: [   89.172965]  0000000000000009 ffff88005f603838 ffffffff81acbcfa ffffffff822134e0
> Jan 26 11:36:26 serveerstertje kernel: [   89.184156]  ffff88005f603888 ffff88005f603878 ffffffff810bdf62 ffff880000000000
> Jan 26 11:36:26 serveerstertje kernel: [   89.195186]  0000000000055ebe 00000000ffffffef 0000000000000200 ffff8800592ea098
> Jan 26 11:36:26 serveerstertje kernel: [   89.206227] Call Trace:
> Jan 26 11:36:26 serveerstertje kernel: [   89.217027]  <IRQ>  [<ffffffff81acbcfa>] dump_stack+0x46/0x58
> Jan 26 11:36:26 serveerstertje kernel: [   89.227907]  [<ffffffff810bdf62>] warn_slowpath_common+0x82/0xb0
> Jan 26 11:36:26 serveerstertje kernel: [   89.238678]  [<ffffffff810be031>] warn_slowpath_fmt+0x41/0x50
> Jan 26 11:36:26 serveerstertje kernel: [   89.249336]  [<ffffffff81471c5a>] ? active_pfn_read_overlap+0x3a/0x70
> Jan 26 11:36:26 serveerstertje kernel: [   89.259904]  [<ffffffff814729e3>] add_dma_entry+0x103/0x130
> Jan 26 11:36:26 serveerstertje kernel: [   89.270416]  [<ffffffff81472de6>] debug_dma_map_page+0x126/0x150
> Jan 26 11:36:26 serveerstertje kernel: [   89.280840]  [<ffffffff81714686>] rtl8169_start_xmit+0x216/0xa20
[r8169 and xen stuff]

Dan, I miss the part of the debug code that tells where the mappings were
previously set.

-- 
Ueimor

^ permalink raw reply
* Kind Regards
From: Abdul Nasser @ 2014-01-26 21:30 UTC (permalink / raw)
  To: Recipients

Greetings,
My name is Abdul Nasser Sokariah and I am writing you from Syria, I choose to contact you directly as I need a reliable person to trust who can help me handle my huge deposit  with a vault company in EUROPE, and based on my present situation in Syria, I need you urgently to take possession of everything and further modalities/directives will follow.Please reply to my private  Email: nasserabdul190@yahoo.com

I wait for your response.

Yours truly,
Abdul Nasser Sokariah

^ permalink raw reply
* Kind Regards
From: Abdul Nasser @ 2014-01-26 21:51 UTC (permalink / raw)
  To: Recipients

Greetings,
My name is Abdul Nasser Sokariah and I am writing you from Syria, I choose to contact you directly as I need a reliable person to trust who can help me handle my huge deposit  with a vault company in EUROPE, and based on my present situation in Syria, I need you urgently to take possession of everything and further modalities/directives will follow.Please reply to my private  Email: nasserabdul190@yahoo.com

I wait for your response.

Yours truly,
Abdul Nasser Sokariah

^ permalink raw reply
* Kind Regards
From: Abdul Nasser @ 2014-01-26 22:31 UTC (permalink / raw)
  To: Recipients

Greetings,
My name is Abdul Nasser Sokariah and I am writing you from Syria, I choose to contact you directly as I need a reliable person to trust who can help me handle my huge deposit  with a vault company in EUROPE, and based on my present situation in Syria, I need you urgently to take possession of everything and further modalities/directives will follow.Please reply to my private  Email: nasserabdul190@yahoo.com

I wait for your response.

Yours truly,
Abdul Nasser Sokariah

^ permalink raw reply
* Inquiry
From: Konrad Lukman @ 2014-01-26 19:37 UTC (permalink / raw)
  To: netdev



Dear sir/Madam



            Compliment of the new year .Sir we like like to establish a

serious business relationship with you , we are Suppliers we will like to inquire if you have some product available for the months of Febuary,please kindly get back to me if you have it available and let me know your payment terms and time of delivery. I look forward to hear from you soon thanks and have a great day.



Regards.

Konrad Lukman

Sale manager.

Comiol Enterprises

Address--904 54TH ST

City--BROOKLYN

Zip--11219-4020

State--NY

+1345675464

Country--UNITED STATES

^ permalink raw reply
* Re: [PATCH net-next] 8139cp: remove a won't occurred BUG_ON
From: Ben Hutchings @ 2014-01-26 23:23 UTC (permalink / raw)
  To: Wang Weidong; +Cc: David Miller, netdev
In-Reply-To: <52E4C862.9050103@huawei.com>

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

On Sun, 2014-01-26 at 16:33 +0800, Wang Weidong wrote:
> when variable i go to the BUG_ON the value is equal to the CP_NUM_STATS,
> so the BUG_ON won't occur, so remove it

We hope that every BUG_ON() does not occur, but that doesn't mean they
should be removed.  This check is meant to catch mistakes when adding
new statistics.

Ben.

> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
> ---
>  drivers/net/ethernet/realtek/8139cp.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
> index 737c1a8..b70e184 100644
> --- a/drivers/net/ethernet/realtek/8139cp.c
> +++ b/drivers/net/ethernet/realtek/8139cp.c
> @@ -1585,7 +1585,6 @@ static void cp_get_ethtool_stats (struct net_device *dev,
>  	tmp_stats[i++] = le16_to_cpu(nic_stats->tx_abort);
>  	tmp_stats[i++] = le16_to_cpu(nic_stats->tx_underrun);
>  	tmp_stats[i++] = cp->cp_stats.rx_frags;
> -	BUG_ON(i != CP_NUM_STATS);
>  
>  	dma_free_coherent(&cp->pdev->dev, sizeof(*nic_stats), nic_stats, dma);
>  }

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply
* Re: Freescale FEC packet loss
From: Ben Hutchings @ 2014-01-26 21:33 UTC (permalink / raw)
  To: Marek Vasut
  Cc: netdev@vger.kernel.org, Frank Li, fugang.duan,
	fabio.estevam@freescale.com, Hector Palacios, linux-arm-kernel,
	Detlev Zundel, Eric Nelson, Matthew Garrett
In-Reply-To: <201401262012.13051.marex@denx.de>

[-- Attachment #1: Type: text/plain, Size: 2153 bytes --]

On Sun, 2014-01-26 at 20:12 +0100, Marek Vasut wrote:
> On Sunday, January 26, 2014 at 07:56:30 PM, Ben Hutchings wrote:
> > On Wed, 2014-01-22 at 22:55 +0100, Marek Vasut wrote:
> > > Hi guys,
> > > 
> > > I am running stock Linux 3.13 on i.MX6Q SabreLite board. The CPU is
> > > i.MX6Q TO 1.0 .
> > > 
> > > I am hitting a WARNING when I use the FEC ethernet to transfer data, thus
> > > I started investigating this problem. TL;DR I am not able to figure this
> > > problem out, so I am not attaching a patch :-(
> > > 
> > > Steps to reproduce:
> > > -------------------
> > > 1) Boot stock Linux 3.13 on i.MX6Q SabreLite board
> > > 2) Plug in an SD card into one of the SD slots (I use the full-size one)
> > > 3) Plug in an USB stick into one of the USB ports (I use the upper one)
> > > 4) Plug in an ethernet cable into the board
> > > 
> > >    -> Connect the other side into a gigabit-capable PC
> > 
> > [...]
> > 
> > I think there are known problems with 1000BASE-T on the Sabre Lite
> > board.
> 
> This is MX6-wide thing, not sabrelite specific actually.
> 
> > Two possible workarounds are to limit the PHY to 100BASE-TX
> > (should be doable with ethtool) or force it to be clock master for
> > 1000BASE-T (requires a driver patch).
> 
> Can you please elaborate on the later ? I don't quite understand that.

1000BASE-T uses all 4 pairs in both directions at the same time, which
requires that both ends transmit symbols synchronously.  As part of the
autonegotiation protocol, they decide which is the clock master (using a
local clock generator) and which is the clock slave (generating a clock
from the received signal).  A PHY can be configured to support only one
of these roles.

> > The vendor kernel apparently does both!
> 
> More like the vendor kernel papers over this bug.
> 
> > Matthew Garrett has been trying to implement a workaround in a
> > clean way.
> 
> Do you have any pointers about this please ?

http://thread.gmane.org/gmane.linux.drivers.devicetree/58570

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply
* Re: critic on documentation of the network stack
From: Arkadiusz Miskiewicz @ 2014-01-26 21:33 UTC (permalink / raw)
  To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <20140124032324.GO7269@order.stressinduktion.org>

On Friday 24 of January 2014, Hannes Frederic Sowa wrote:
> Hello!
> 
> After net-next is closed I wanted to put the following link here:
> 
>   <http://linux.slashdot.org/comments.pl?sid=4356053&cid=45184693>
> 
> I don't want to start a flamefest or come too close to someone but I
> fear some of the critic is reasonable.  Maybe we can do better (I have
> to admit, I also hate writing documentation, e.g. have not yet send the
> IP_PMTUDISC_INTERFACE man-page patches).
> 
> I try to start with some constructive discussion:
> 
> There are some great features in the network stack that some people miss
> because of lack documentation. One possible solution is documentation
> directly in the kernel, but mostly this is just written as a reference
> and the real wonderful stuff is only achieved by putting lots of those
> features correclty together.
> 
> Maybe this is the second or third time this was proposed but I'll try
> again: Would it make sense to just start slow and setup a wiki

Some other project never merge patches if there is no documentation.

Maintainers could do the same, so eg. kernel patch is merged only if there is 
man-pages patch send, too (or other kind of documentation).

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox