* [PATCH v2 2/6] mv643xx.c: Remove magic numbers.
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
replace magic number with RX_CSUM_WITH_HEADER.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 4fbba57..92497eb 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -86,6 +86,7 @@ static char mv643xx_eth_driver_version[] = "1.4";
* port #0, 0x0800 for port #1, and 0x0c00 for port #2.
*/
#define PORT_CONFIG 0x0000
+#define RX_CSUM_WITH_HEADER 0x02000000
#define UNICAST_PROMISCUOUS_MODE 0x00000001
#define PORT_CONFIG_EXT 0x0004
#define MAC_ADDR_LOW 0x0014
@@ -1607,7 +1608,7 @@ mv643xx_eth_set_features(struct net_device *dev, netdev_features_t features)
struct mv643xx_eth_private *mp = netdev_priv(dev);
bool rx_csum = features & NETIF_F_RXCSUM;
- wrlp(mp, PORT_CONFIG, rx_csum ? 0x02000000 : 0x00000000);
+ wrlp(mp, PORT_CONFIG, rx_csum ? RX_CSUM_WITH_HEADER : 0x00000000);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 6/6] DT: Convert all kirkwood boards with mv643xx that use DT
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
This patch converts all present DT capable kirkwood board configurations
to use DT to configure the mv643xx ethernet controller.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 9 +++++++++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 18 ++++++++++++++++++
arch/arm/boot/dts/kirkwood-goflexnet.dts | 8 ++++++++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 10 ++++++++++
arch/arm/boot/dts/kirkwood-iconnect.dts | 10 ++++++++++
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/kirkwood-ts219-6281.dts | 8 +++++++-
arch/arm/boot/dts/kirkwood-ts219-6282.dts | 8 +++++++-
arch/arm/boot/dts/kirkwood-ts219.dtsi | 3 +++
arch/arm/mach-kirkwood/board-dnskw.c | 7 +------
arch/arm/mach-kirkwood/board-dreamplug.c | 13 ++-----------
arch/arm/mach-kirkwood/board-goflexnet.c | 7 +------
arch/arm/mach-kirkwood/board-ib62x0.c | 7 +------
arch/arm/mach-kirkwood/board-iconnect.c | 7 +------
arch/arm/mach-kirkwood/board-lsxl.c | 13 ++-----------
arch/arm/mach-kirkwood/board-ts219.c | 10 +---------
16 files changed, 98 insertions(+), 57 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 7408655..214fe0b 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -65,5 +65,14 @@
reg = <0x7b00000 0x500000>;
};
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
};
};
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 26e281f..c27ed1c 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -53,6 +53,24 @@
status = "okay";
nr-ports = <1>;
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ smi1: mdio@76000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+
+ egiga1 {
+ phy_addr = <1>;
+ status = "ok";
+ };
};
gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-goflexnet.dts b/arch/arm/boot/dts/kirkwood-goflexnet.dts
index 7c8238f..f03dbd0 100644
--- a/arch/arm/boot/dts/kirkwood-goflexnet.dts
+++ b/arch/arm/boot/dts/kirkwood-goflexnet.dts
@@ -50,6 +50,14 @@
nr-ports = <2>;
};
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
};
gpio-leds {
compatible = "gpio-leds";
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index 66794ed..8c462a1 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -45,6 +45,16 @@
};
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
+
};
gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 52d9470..9fc82be 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -30,6 +30,16 @@
clock-frequency = <200000000>;
status = "ok";
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <b>;
+ status = "ok";
+ };
+
};
gpio-leds {
compatible = "gpio-leds";
diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
index 8ac51c0..2f47661 100644
--- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
@@ -40,6 +40,23 @@
};
};
};
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ smi1: mdio@76000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+
+ egiga1 {
+ phy_addr = <8>;
+ status = "ok";
+ };
};
gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
index ccbf327..4ca49b5 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -3,6 +3,12 @@
/include/ "kirkwood-ts219.dtsi"
/ {
+ ocp@f1000000 {
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
+ };
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -18,4 +24,4 @@
gpios = <&gpio0 16 1>;
};
};
-};
\ No newline at end of file
+};
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index fbe9932..40f3c61 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -3,6 +3,12 @@
/include/ "kirkwood-ts219.dtsi"
/ {
+ ocp@f1000000 {
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+ };
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -18,4 +24,4 @@
gpios = <&gpio1 5 1>;
};
};
-};
\ No newline at end of file
+};
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 64ea27c..06caf41 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -74,5 +74,8 @@
status = "okay";
nr-ports = <2>;
};
+ smi0: mdio@72000 {
+ status = "ok";
+ };
};
};
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c b/arch/arm/mach-kirkwood/board-dnskw.c
index 4ab3506..4d8216b 100644
--- a/arch/arm/mach-kirkwood/board-dnskw.c
+++ b/arch/arm/mach-kirkwood/board-dnskw.c
@@ -15,7 +15,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/gpio.h>
#include <linux/input.h>
@@ -29,10 +28,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data dnskw_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int dnskw_mpp_config[] __initdata = {
MPP13_UART1_TXD, /* Custom ... */
MPP14_UART1_RXD, /* ... Controller (DNS-320 only) */
@@ -112,7 +107,7 @@ void __init dnskw_init(void)
kirkwood_mpp_conf(dnskw_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&dnskw_ge00_data);
+ kirkwood_ge00_init(NULL);
platform_device_register(&dnskw_fan_device);
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-kirkwood/board-dreamplug.c
index aeb234d..b97a112 100644
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ b/arch/arm/mach-kirkwood/board-dreamplug.c
@@ -15,7 +15,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_fdt.h>
@@ -34,14 +33,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data dreamplug_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data dreamplug_ge01_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(1),
-};
-
static struct mvsdio_platform_data dreamplug_mvsdio_data = {
/* unfortunately the CD signal has not been connected */
};
@@ -65,7 +56,7 @@ void __init dreamplug_init(void)
kirkwood_mpp_conf(dreamplug_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&dreamplug_ge00_data);
- kirkwood_ge01_init(&dreamplug_ge01_data);
+ kirkwood_ge00_init(NULL);
+ kirkwood_ge01_init(NULL);
kirkwood_sdio_init(&dreamplug_mvsdio_data);
}
diff --git a/arch/arm/mach-kirkwood/board-goflexnet.c b/arch/arm/mach-kirkwood/board-goflexnet.c
index 413e2c8..be7437d 100644
--- a/arch/arm/mach-kirkwood/board-goflexnet.c
+++ b/arch/arm/mach-kirkwood/board-goflexnet.c
@@ -20,7 +20,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_fdt.h>
@@ -36,10 +35,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data goflexnet_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
static unsigned int goflexnet_mpp_config[] __initdata = {
MPP29_GPIO, /* USB Power Enable */
MPP47_GPIO, /* LED Orange */
@@ -67,5 +62,5 @@ void __init goflexnet_init(void)
pr_err("can't setup GPIO 29 (USB Power Enable)\n");
kirkwood_ehci_init();
- kirkwood_ge00_init(&goflexnet_ge00_data);
+ kirkwood_ge00_init(NULL);
}
diff --git a/arch/arm/mach-kirkwood/board-ib62x0.c b/arch/arm/mach-kirkwood/board-ib62x0.c
index cfc47f8..0a29183 100644
--- a/arch/arm/mach-kirkwood/board-ib62x0.c
+++ b/arch/arm/mach-kirkwood/board-ib62x0.c
@@ -16,7 +16,6 @@
#include <linux/platform_device.h>
#include <linux/mtd/partitions.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/input.h>
#include <asm/mach-types.h>
@@ -27,10 +26,6 @@
#define IB62X0_GPIO_POWER_OFF 24
-static struct mv643xx_eth_platform_data ib62x0_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int ib62x0_mpp_config[] __initdata = {
MPP0_NF_IO2,
MPP1_NF_IO3,
@@ -62,7 +57,7 @@ void __init ib62x0_init(void)
kirkwood_mpp_conf(ib62x0_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&ib62x0_ge00_data);
+ kirkwood_ge00_init(NULL);
if (gpio_request(IB62X0_GPIO_POWER_OFF, "ib62x0:power:off") == 0 &&
gpio_direction_output(IB62X0_GPIO_POWER_OFF, 0) == 0)
pm_power_off = ib62x0_power_off;
diff --git a/arch/arm/mach-kirkwood/board-iconnect.c b/arch/arm/mach-kirkwood/board-iconnect.c
index d7a9198..220f0d4 100644
--- a/arch/arm/mach-kirkwood/board-iconnect.c
+++ b/arch/arm/mach-kirkwood/board-iconnect.c
@@ -17,7 +17,6 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/mtd/partitions.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/input.h>
#include <linux/gpio_keys.h>
@@ -26,10 +25,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data iconnect_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(11),
-};
-
static unsigned int iconnect_mpp_config[] __initdata = {
MPP12_GPIO,
MPP35_GPIO,
@@ -92,7 +87,7 @@ void __init iconnect_init(void)
kirkwood_nand_init(ARRAY_AND_SIZE(iconnect_nand_parts), 25);
kirkwood_ehci_init();
- kirkwood_ge00_init(&iconnect_ge00_data);
+ kirkwood_ge00_init(NULL);
platform_device_register(&iconnect_button_device);
}
diff --git a/arch/arm/mach-kirkwood/board-lsxl.c b/arch/arm/mach-kirkwood/board-lsxl.c
index 83d8975..60331d1 100644
--- a/arch/arm/mach-kirkwood/board-lsxl.c
+++ b/arch/arm/mach-kirkwood/board-lsxl.c
@@ -18,7 +18,6 @@
#include <linux/ata_platform.h>
#include <linux/spi/flash.h>
#include <linux/spi/spi.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/gpio-fan.h>
#include <linux/input.h>
@@ -28,14 +27,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data lsxl_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data lsxl_ge01_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int lsxl_mpp_config[] __initdata = {
MPP10_GPO, /* HDD Power Enable */
MPP11_GPIO, /* USB Vbus Enable */
@@ -126,8 +117,8 @@ void __init lsxl_init(void)
gpio_set_value(LSXL_GPIO_HDD_POWER, 1);
kirkwood_ehci_init();
- kirkwood_ge00_init(&lsxl_ge00_data);
- kirkwood_ge01_init(&lsxl_ge01_data);
+ kirkwood_ge00_init(NULL);
+ kirkwood_ge01_init(NULL);
platform_device_register(&lsxl_fan_device);
/* register power-off method */
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
index 1750e68..7e7fe6c 100644
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -18,7 +18,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
#include <linux/ata_platform.h>
#include <linux/gpio_keys.h>
#include <linux/input.h>
@@ -29,10 +28,6 @@
#include "mpp.h"
#include "tsx1x-common.h"
-static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int qnap_ts219_mpp_config[] __initdata = {
MPP0_SPI_SCn,
MPP1_SPI_MOSI,
@@ -62,10 +57,7 @@ void __init qnap_dt_ts219_init(void)
kirkwood_mpp_conf(qnap_ts219_mpp_config);
kirkwood_pcie_id(&dev, &rev);
- if (dev == MV88F6282_DEV_ID)
- qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
-
- kirkwood_ge00_init(&qnap_ts219_ge00_data);
+ kirkwood_ge00_init(NULL);
kirkwood_ehci_init();
pm_power_off = qnap_tsx1x_power_off;
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: chetan loke @ 2012-07-31 16:02 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Jon Mason, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAErSpo6gjMf4C3RMn5YLNg5JtJ8CjHvTw1iqsKPa6YuRqPe90g@mail.gmail.com>
On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@intel.com> wrote:
>>
>> I've tried to make it all generic enough that non-Intel NTBs should plug in with
>> minimal changes to ntb_hw.c. If their design is too divergent, then a slight
>> redesign of ntb_hw.c might be necessary. But from what I've seen of other
>> designs on the internet, they appear to be extremely similar. The transport and
>> client drivers were written with the hardware abstracted away as much as
>> possible to prevent the need to modify it for different hardware. If there is
>> anything which is Intel hardware specific, I'd be happy to change it to make it
>> more generic.
>
> That makes sense from a technical point of view, but I think it's
> going to cause maintenance issues. For example, assume PLX NTB
> support is added. Will PLX be happy about having to convince you to
> accept changes? Will Intel be happy about having to release a new
Do you mean convince Intel? Well, if we think of ntb as the class
driver then the onus is on the community to vet the changes and NOT
intel.
And since this is the first NTB part for which the support is
introduced the class driver design could be a moving target. As
someone else mentioned, the async/sync tx-dma is another hook that
could change the class driver's design.
> driver for their hardware just to incorporate a PLX bug fix? Will
> users of PLX hardware accept a new driver release that only benefits
> Intel users?
May be till the class driver is stable, the client(intel/PLX) drivers
might have to be modified. This is a cue for other vendors to
chime-in and review this design?
Just thinking if this could sit in staging for some time(so that
others get a chance to review/suggest changes as well) and then get
promoted out of staging.
Chetan Loke
^ permalink raw reply
* 802.15.4 Issues
From: Alan Ott @ 2012-07-31 16:04 UTC (permalink / raw)
To: netdev, linux-zigbee-devel, Alexander Smirnov, Tony Cheneau
Hello,
I'm trying to follow the directions at linux-wsn[1] and am not having
much luck. Since I don't have the at91sam9g20ek board, I'm trying this
on my desktop PC with an Econotag[2] (using the serial.c driver I pulled
from [3]) and on a BeagleBone with an MRF24J40 (using a driver I made [4]).
I know this sounds like a big mess, and it is, but let me first start by
staying that all this worked with the code in the linux-zigbee repo at
[3]. With the code in that repo I could run the steps at [5] and
communicate between devices using izchat. (Yes, I know that izchat and
the workflow at [5] are not supported in the -next code yet, which is
why I'm using [1])
Currently, I'm trying to follow the steps at [1] to start using the
latest mainline functionality and I'm not having very much success. I'm
using linux-next, which in looking at the log should currently be the
same as net-next with respect to ieee802154 and 6lowpan.
On the destkop PC, there are several issues. The first is that I'm
getting __schedule_bug errors caused by lowpan_header_create() calling
kzalloc(..., GFP_KERNEL) from interrupt context (see [schedule_log]
below). Replacing kzalloc() calls in lowpan_header_create() and in
ieee802154_header_create() with stack arrays (since they were small
static lengths anyway), I'm able to run the commands at [1] without
stack dumps in the log. This is good, I suppose. The issue now is, once
I've set up the lowpan0 device on the Econotag, when I issue a ping, I
don't see its .xmit() function getting called at all
(ieee802154_serial_xmit() in this case).
I can certainly investigate further, but before doing so, I'd like to
know if what I'm doing, the way I'm doing it, is even _expected_ to
work, or if there's something fundamental that I'm missing.
Also, the instructions at [1] say:
"no platform data merged to the mainline, please apply the last patch
from wpan series manually"
Those instructions[1] were updated July 4, which is before the most
recent 802.15.4 related commits made it into -next. Is that sentence
still valid? If so, where is this wpan series of which it speaks? I'm
assuming platform data may mean for the at91sam9g20ek and that it
doesn't affect me since I'm not using that hardware. Please correct me
if I'm wrong.
Also, interestingly, on my embedded configuration (Beagle Bone +
MRF24J40), ping6 _will_ cause packets to get sent. The kernel I have on
that system is mainline (linux.git) still, and I haven't moved it to
-next yet because of the issues on the desktop PC.
Like I said, I feel like there's something fundamental I'm doing wrong.
Please let me know if you see it.
Alan.
[1] http://code.google.com/p/linux-wsn/wiki/Mainline
[2] http://www.redwirellc.com/store/node/1
[3]
http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;a=summary
[4] http://permalink.gmane.org/gmane.linux.network.zigbee.devel/1135
[5] http://sourceforge.net/apps/trac/linux-zigbee/wiki/GettingStarted-0.2
[schedule_log]
[ 87.605763] Call Trace:
[ 87.605764] <IRQ> [<ffffffff81084992>] __schedule_bug+0x52/0x60
[ 87.605772] [<ffffffff815e303d>] __schedule+0x6cd/0x7c0
[ 87.605774] [<ffffffff8108875a>] __cond_resched+0x2a/0x40
[ 87.605776] [<ffffffff815e31c0>] _cond_resched+0x30/0x40
[ 87.605779] [<ffffffff81159740>] __kmalloc+0x60/0x170
[ 87.605781] [<ffffffffa02fe28f>] ? kzalloc+0xf/0x20 [6lowpan]
[ 87.605783] [<ffffffffa02fe28f>] kzalloc+0xf/0x20 [6lowpan]
[ 87.605785] [<ffffffffa02fe50e>] lowpan_header_create+0x7e/0x570
[6lowpan]
[ 87.605788] [<ffffffff814de84b>] ? __kmalloc_reserve+0x3b/0xa0
[ 87.605790] [<ffffffff811597d5>] ? __kmalloc+0xf5/0x170
[ 87.605792] [<ffffffff814f711d>] neigh_connected_output+0xad/0x110
[ 87.605795] [<ffffffff8158438d>] ip6_finish_output2+0xfd/0x310
[ 87.605797] [<ffffffff8159041b>] ? rt6_bind_peer+0x4b/0x90
[ 87.605799] [<ffffffff81584638>] ip6_finish_output+0x98/0xc0
[ 87.605801] [<ffffffff815846d8>] ip6_output+0x78/0xb0
[ 87.605803] [<ffffffff8159843e>] ndisc_send_skb+0x1be/0x1f0
[ 87.605805] [<ffffffff815984d1>] __ndisc_send+0x61/0x80
[ 87.605807] [<ffffffff81598d89>] ndisc_send_rs+0x39/0x40
[ 87.605809] [<ffffffff81589df3>] ? ipv6_ifa_notify+0x43/0x50
[ 87.605810] [<ffffffff81589ea0>] addrconf_dad_completed+0xa0/0xf0
[ 87.605812] [<ffffffff8158a08f>] addrconf_dad_timer+0x19f/0x1c0
[ 87.605814] [<ffffffff81064338>] run_timer_softirq+0x178/0x3a0
[ 87.605816] [<ffffffff81589ef0>] ? addrconf_dad_completed+0xf0/0xf0
[ 87.605818] [<ffffffff8101a639>] ? read_tsc+0x9/0x20
[ 87.605819] [<ffffffff8105bfff>] __do_softirq+0xcf/0x250
[ 87.605822] [<ffffffff810a6b34>] ? clockevents_program_event+0x74/0xf0
[ 87.605824] [<ffffffff8107be9e>] ? hrtimer_interrupt+0x13e/0x240
[ 87.605826] [<ffffffff815ed5bc>] call_softirq+0x1c/0x30
[ 87.605829] [<ffffffff810152d5>] do_softirq+0x65/0xa0
[ 87.605830] [<ffffffff8105bded>] irq_exit+0xbd/0xe0
[ 87.605832] [<ffffffff815edefe>] smp_apic_timer_interrupt+0x6e/0x99
[ 87.605833] [<ffffffff815ececa>] apic_timer_interrupt+0x6a/0x70
[ 87.605834] <EOI> [<ffffffff81041436>] ? native_safe_halt+0x6/0x10
[ 87.605838] [<ffffffff8101c54d>] default_idle+0x5d/0x1b0
[ 87.605840] [<ffffffff8101bb98>] cpu_idle+0xd8/0x120
[ 87.605842] [<ffffffff815dcc1e>] start_secondary+0x1cf/0x1d6
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: chetan loke @ 2012-07-31 16:14 UTC (permalink / raw)
To: Jon Mason; +Cc: linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <1343607994-32415-2-git-send-email-jon.mason@intel.com>
On Sun, Jul 29, 2012 at 8:26 PM, Jon Mason <jon.mason@intel.com> wrote:
<snip>
> +static void ntb_tx_copy_task(struct ntb_transport_qp *qp,
> + struct ntb_queue_entry *entry,
> + void *offset)
> +{
> + struct ntb_payload_header *hdr = offset;
> +
> + offset += sizeof(struct ntb_payload_header);
> + memcpy_toio(offset, entry->buf, entry->len);
> +
> + hdr->len = entry->len;
> + hdr->ver = qp->tx_pkts;
> +
> + /* Ensure that the data is fully copied out before setting the flag */
> + wmb();
> + hdr->flags = entry->flags | DESC_DONE_FLAG;
> +
> + ntb_ring_sdb(qp->ndev, qp->qp_num);
> +
> + /* The entry length can only be zero if the packet is intended to be a
> + * "link down" or similar. Since no payload is being sent in these
> + * cases, there is nothing to add to the completion queue.
> + */
> + if (entry->len > 0) {
> + qp->tx_bytes += entry->len;
> +
> + /* Add fully transmitted data to completion queue */
> + ntb_list_add_tail(&qp->ntb_tx_comp_q_lock, &entry->entry,
> + &qp->tx_comp_q);
> +
> + if (qp->tx_handler)
> + qp->tx_handler(qp->cb_data, qp);
> + } else
> + ntb_list_add_tail(&qp->ntb_tx_free_q_lock, &entry->entry,
> + &qp->tx_free_q);
> +}
I know you talked about a fixed array. But it's not here yet. So at
all the call-sites, for [r/t]x_free_q , add the 'entry' to the head -
change to ntb_list_add_head here and else where.
Chetan Loke
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Jon Mason @ 2012-07-31 16:33 UTC (permalink / raw)
To: Jianbin Kang; +Cc: Bjorn Helgaas, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAF8raN6M0_TWyCCzjyXZcFYP=vgFaqQg4hNmNpBxSM+D0C_Bpg@mail.gmail.com>
On Tue, Jul 31, 2012 at 11:35:33AM +0800, Jianbin Kang wrote:
> > I've tried to make it all generic enough that non-Intel NTBs should plug in with
> > minimal changes to ntb_hw.c. If their design is too divergent, then a slight
> > redesign of ntb_hw.c might be necessary. But from what I've seen of other
> > designs on the internet, they appear to be extremely similar. The transport and
> > client drivers were written with the hardware abstracted away as much as
> > possible to prevent the need to modify it for different hardware. If there is
> > anything which is Intel hardware specific, I'd be happy to change it to make it
> > more generic.
> In ntb_process_tx(), ntb uses hard-coding 'memcpy_toio' to copy data
> to remote.
> Is it better to provide a function pointer like 'tx()' and call qp->tx().
> memcpy_toio is a slow operation. Some hardware can setup a dma
> transfer and wait.
>
> IMHO, the best way is to handle tx in async mode. But it requires
> lots of modification.
Actually this is what I'm working on now, using async_tx to replace the
memcpy. I believe the changes shouldn't be that significant.
Is the "hardware that can setup dma" you refer to something that does
not use this interface?
Thanks,
Jon
^ permalink raw reply
* Re: [PATCH v2 1/6] Initial csb1724 board support (FDT)
From: Andrew Lunn @ 2012-07-31 16:43 UTC (permalink / raw)
To: Ian Molton
Cc: linux-arm-kernel, andrew, thomas.petazzoni, ben.dooks, arnd,
netdev
In-Reply-To: <1343749529-17571-2-git-send-email-ian.molton@codethink.co.uk>
On Tue, Jul 31, 2012 at 04:45:24PM +0100, Ian Molton wrote:
> This patch adds support for the csb1724 SoM.
>
> It includes serial and SATA support.
>
> Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
> ---
> arch/arm/boot/dts/kirkwood-csb1724.dts | 30 ++++++++++++++++
> arch/arm/configs/csb1724_defconfig | 47 +++++++++++++++++++++++++
I'm unlikely to accept csb1724_defconfig. Please keep it for yourself.
If there is anything you want adding to kirkwood_defconfig, please let
me know.
Jason planned to rework kirkwood_defconfig, but he got sidetracked. I
hope we can get to this soon and enable the building of all DT
platforms by default.
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/6] mv643xx.c: Add basic device tree support.
From: Andrew Lunn @ 2012-07-31 16:46 UTC (permalink / raw)
To: Ian Molton
Cc: linux-arm-kernel, andrew, thomas.petazzoni, ben.dooks, arnd,
netdev
In-Reply-To: <1343749529-17571-4-git-send-email-ian.molton@codethink.co.uk>
On Tue, Jul 31, 2012 at 04:45:26PM +0100, Ian Molton wrote:
> This patch adds basic device tree support to the mv643xx ethernet driver.
>
> It should be enough for most current users of the device, and should allow
> a fairly painless migration once proper support for clk devices is available
> to those platforms.
>
> Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
> ---
> Documentation/devicetree/bindings/net/mv643xx.txt | 75 +++++++++++++
> arch/arm/mach-kirkwood/board-dt.c | 5 +
Hi Ian
Probably the driver change will get upstream by netdev. The rest will
go via the Orion maintainers into arm-soc. So you should probably move
this board-dt.c change into a patch of its own, or make it part of:
csb1724: Enable device tree based mv643xx ethernet support.
Thanks
Andrew
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Bjorn Helgaas @ 2012-07-31 17:03 UTC (permalink / raw)
To: chetan loke; +Cc: Jon Mason, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAAsGZS5kOyQ5FQ7Jg3HxOmmPNYS+F6XcB-_3tm=rcgDV7wAvRQ@mail.gmail.com>
On Tue, Jul 31, 2012 at 10:02 AM, chetan loke <loke.chetan@gmail.com> wrote:
> On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@intel.com> wrote:
>>>
>>> I've tried to make it all generic enough that non-Intel NTBs should plug in with
>>> minimal changes to ntb_hw.c. If their design is too divergent, then a slight
>>> redesign of ntb_hw.c might be necessary. But from what I've seen of other
>>> designs on the internet, they appear to be extremely similar. The transport and
>>> client drivers were written with the hardware abstracted away as much as
>>> possible to prevent the need to modify it for different hardware. If there is
>>> anything which is Intel hardware specific, I'd be happy to change it to make it
>>> more generic.
>>
>> That makes sense from a technical point of view, but I think it's
>> going to cause maintenance issues. For example, assume PLX NTB
>> support is added. Will PLX be happy about having to convince you to
>> accept changes? Will Intel be happy about having to release a new
>
> Do you mean convince Intel? Well, if we think of ntb as the class
> driver then the onus is on the community to vet the changes and NOT
> intel.
No, I said convince "you," meaning *Jon*. Intel doesn't apply
patches. "The community" doesn't apply patches. Jon applies patches.
This has nothing to do with the fact that Jon is employed by Intel.
The point is that when you have multiple organizations involved, they
have different goals, markets, customers, and schedules. If one
module contains both Intel-specific and PLX-specific things, that's a
place where these organizational differences may cause issues,
regardless of who is applying the patches.
Obviously it's not a problem now, and maybe it will never be. But I
think there's a possibility. Since I have no direct interest in any
of these devices, I'm only raising that possibility, not trying to
force any particular direction.
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Jon Mason @ 2012-07-31 17:10 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAErSpo6gjMf4C3RMn5YLNg5JtJ8CjHvTw1iqsKPa6YuRqPe90g@mail.gmail.com>
On Tue, Jul 31, 2012 at 07:45:29AM -0600, Bjorn Helgaas wrote:
> On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@intel.com> wrote:
> > On Mon, Jul 30, 2012 at 10:50:13AM -0600, Bjorn Helgaas wrote:
> >> On Sun, Jul 29, 2012 at 6:26 PM, Jon Mason <jon.mason@intel.com> wrote:
> >> > A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
> >> > connecting 2 systems, providing electrical isolation between the two subsystems.
> >> > A non-transparent bridge is functionally similar to a transparent bridge except
> >> > that both sides of the bridge have their own independent address domains. The
> >> > host on one side of the bridge will not have the visibility of the complete
> >> > memory or I/O space on the other side of the bridge. To communicate across the
> >> > non-transparent bridge, each NTB endpoint has one (or more) apertures exposed to
> >> > the local system. Writes to these apertures are mirrored to memory on the
> >> > remote system. Communications can also occur through the use of doorbell
> >> > registers that initiate interrupts to the alternate domain, and scratch-pad
> >> > registers accessible from both sides.
> >> >
> >> > The NTB device driver is needed to configure these memory windows, doorbell, and
> >> > scratch-pad registers as well as use them in such a way as they can be turned
> >> > into a viable communication channel to the remote system. ntb_hw.[ch]
> >> > determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
> >> > the underlying hardware to provide access and a common interface to the doorbell
> >> > registers, scratch pads, and memory windows. These hardware interfaces are
> >> > exported so that other, non-mainlined kernel drivers can access these.
> >> > ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a
> >> > communication channel(s) and provide a reliable way of transferring data from
> >> > one side to the other, which it then exports so that "client" drivers can access
> >> > them. These client drivers are used to provide a standard kernel interface
> >> > (i.e., Ethernet device) to NTB, such that Linux can transfer data from one
> >> > system to the other in a standard way.
> >> >
> >> > Signed-off-by: Jon Mason <jon.mason@intel.com>
> >> > ---
> >> > MAINTAINERS | 6 +
> >> > drivers/Kconfig | 2 +
> >> > drivers/Makefile | 1 +
> >> > drivers/ntb/Kconfig | 13 +
> >> > drivers/ntb/Makefile | 3 +
> >> > drivers/ntb/ntb_hw.c | 1178 ++++++++++++++++++++++++++++++++++++
> >> > drivers/ntb/ntb_hw.h | 206 +++++++
> >> > drivers/ntb/ntb_regs.h | 150 +++++
> >> > drivers/ntb/ntb_transport.c | 1387 +++++++++++++++++++++++++++++++++++++++++++
> >> > include/linux/ntb.h | 92 +++
> >>
> >> Where will drivers for non-Intel NTBs fit in this hierarchy? It seems
> >> a bit presumptuous to claim the generic "ntb" names just for Intel
> >> devices.
> >
> > I've tried to make it all generic enough that non-Intel NTBs should plug in with
> > minimal changes to ntb_hw.c. If their design is too divergent, then a slight
> > redesign of ntb_hw.c might be necessary. But from what I've seen of other
> > designs on the internet, they appear to be extremely similar. The transport and
> > client drivers were written with the hardware abstracted away as much as
> > possible to prevent the need to modify it for different hardware. If there is
> > anything which is Intel hardware specific, I'd be happy to change it to make it
> > more generic.
>
> That makes sense from a technical point of view, but I think it's
> going to cause maintenance issues. For example, assume PLX NTB
> support is added. Will PLX be happy about having to convince you to
> accept changes? Will Intel be happy about having to release a new
> driver for their hardware just to incorporate a PLX bug fix? Will
> users of PLX hardware accept a new driver release that only benefits
> Intel users?
Firstly, I don't believe this is an issue. The amount of hardware
specific code is small (<150 loc), and the design of the PLX hardware
appears to be the same as Intel (from what I've read on the internet).
Assuming Intel is me, I am always happy to do whatever I can to help
PLX or any other NTB vendor. I am willing to make internal releases
(which I am assuming is the issue you are referring to) for any change
to the driver.
If necessary, refactoring the driver shouldn't be a significant issue.
However, I would prefer to do it if/when another NTB driver wants to
be added. PLX (and those who are using their NTB hardware) hasn't
pushed an NTB driver yet, and may never (as their design docs on the
web are from '05). Why complicate the driver for them if they never
come?
Thanks,
Jon
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Jon Mason @ 2012-07-31 17:27 UTC (permalink / raw)
To: chetan loke; +Cc: Bjorn Helgaas, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAAsGZS5kOyQ5FQ7Jg3HxOmmPNYS+F6XcB-_3tm=rcgDV7wAvRQ@mail.gmail.com>
On Tue, Jul 31, 2012 at 12:02:20PM -0400, chetan loke wrote:
> On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@intel.com> wrote:
> >>
> >> I've tried to make it all generic enough that non-Intel NTBs should plug in with
> >> minimal changes to ntb_hw.c. If their design is too divergent, then a slight
> >> redesign of ntb_hw.c might be necessary. But from what I've seen of other
> >> designs on the internet, they appear to be extremely similar. The transport and
> >> client drivers were written with the hardware abstracted away as much as
> >> possible to prevent the need to modify it for different hardware. If there is
> >> anything which is Intel hardware specific, I'd be happy to change it to make it
> >> more generic.
> >
> > That makes sense from a technical point of view, but I think it's
> > going to cause maintenance issues. For example, assume PLX NTB
> > support is added. Will PLX be happy about having to convince you to
> > accept changes? Will Intel be happy about having to release a new
>
> Do you mean convince Intel? Well, if we think of ntb as the class
> driver then the onus is on the community to vet the changes and NOT
> intel.
> And since this is the first NTB part for which the support is
> introduced the class driver design could be a moving target. As
> someone else mentioned, the async/sync tx-dma is another hook that
> could change the class driver's design.
>
>
> > driver for their hardware just to incorporate a PLX bug fix? Will
> > users of PLX hardware accept a new driver release that only benefits
> > Intel users?
>
> May be till the class driver is stable, the client(intel/PLX) drivers
> might have to be modified. This is a cue for other vendors to
> chime-in and review this design?
> Just thinking if this could sit in staging for some time(so that
> others get a chance to review/suggest changes as well) and then get
> promoted out of staging.
I don't see the benefit of having the driver in staging. Any vendors
who would notice the ntb driver in staging would be sitting on these
mailing lists and hopefully have planety of comments on the design.
Stashing the driver in staging while waiting for these comments (which
may never come) doesn't seem the best course of action.
Thanks,
Jon
>
> Chetan Loke
^ permalink raw reply
* Re: [PATCH 0/7] Deconstruct struct fib_result
From: Alexander Duyck @ 2012-07-31 17:27 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20120727.211814.1628871775065221675.davem@davemloft.net>
On Fri, Jul 27, 2012 at 9:18 PM, David Miller <davem@davemloft.net> wrote:
>
> This patch set tries to move towards reducing struct fib_result down
> to it's absolute minimum.
>
> The eventual idea is to make it so that fib_lookup() simply
> returns a "struct fib_nh *" and pointer encoded errnos, instead
> of writing into a complicated structure as the return value on
> the stack as is done now.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
I tested these patches most of yesterday and I haven't seen any
issues. Then again I haven't seen much of an improvement either.
Tested-by: Alexander Duyck <alexander.h.duyck@intel.com>
^ permalink raw reply
* inquiry
From: roboth roli company @ 2012-07-31 9:31 UTC (permalink / raw)
i am robothroli, Purchase manager from roli Merchant Ltd. We are
Import/export Company based in taiwan. We are interested in purchasing
your product and I would like to make an inquiry. Please inform me on:
Sample availability and price
Minimum order quantity
FOB Prices
Sincerely
Purchase Manager
robothroli
^ permalink raw reply
* Re: CPU: 0 Not tainted (3.1.9+ #1) when ifconfig rose0 down
From: folkert @ 2012-07-31 17:56 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: linux-hams, Linux Netdev List
In-Reply-To: <5017E786.5000102@free.fr>
> I observe systematically a kernel panic when I try to shutdown rose0
> device using ifconfig rose0 down
That's funny: I always get a kernel panic(!) when doing an ifconfig
rose0 up!
Folkert van Heusden
--
Nagios user? Check out CoffeeSaint - the versatile Nagios status
viewer! http://www.vanheusden.com/java/CoffeeSaint/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
^ permalink raw reply
* Re: CPU: 0 Not tainted (3.1.9+ #1) when ifconfig rose0 down
From: folkert @ 2012-07-31 17:58 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: linux-hams, Linux Netdev List
In-Reply-To: <5017F96B.1060701@free.fr>
> Here is a complementary observation.
> Trying to remove rose module with rmmod rose did not create any
> kernel panic.
A while ago I wrote a script that at random removed and inserted modules
into the system and that gave surprising results: not only crashing
system, also corrupt filesystems etc. Filed a bug-report and I was told
that removing a module might work but there's no guarantee.
Folkert van Heusden
--
Feeling generous? -> http://www.vanheusden.com/wishlist.php
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: chetan loke @ 2012-07-31 18:02 UTC (permalink / raw)
To: Jon Mason; +Cc: Bjorn Helgaas, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <20120731172709.GB14080@jonmason-lab>
On Tue, Jul 31, 2012 at 1:27 PM, Jon Mason <jon.mason@intel.com> wrote:
>
> I don't see the benefit of having the driver in staging. Any vendors
> who would notice the ntb driver in staging would be sitting on these
> mailing lists and hopefully have planety of comments on the design.
> Stashing the driver in staging while waiting for these comments (which
> may never come) doesn't seem the best course of action.
>
I thought that since others are talking about it then may be there is
some WIP code for foo-NTB. Seems like that's not the case. So no need
to stage.
Correct me if I'm wrong but wouldn't apps just open a socket and route
data via ntb_vir_eth_dev? So I don't see an ABI breakage issue and
hence nothing would prevent us from changing the kernel parts(for
accommodating some foo-NTB part) in future.
It may not be a bad idea to prefix intel-specific(if any)
ntb_structs/variables/logic with the 'intc'(Intel ticker or pick your
string) keyword.
Chetan Loke
^ permalink raw reply
* Re: [PATCH v2 3/6] mv643xx.c: Add basic device tree support.
From: Arnd Bergmann @ 2012-07-31 18:23 UTC (permalink / raw)
To: Ian Molton; +Cc: linux-arm-kernel, andrew, thomas.petazzoni, ben.dooks, netdev
In-Reply-To: <1343749529-17571-4-git-send-email-ian.molton@codethink.co.uk>
On Tuesday 31 July 2012, Ian Molton wrote:
> @@ -33,6 +34,10 @@ struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
> OF_DEV_AUXDATA("marvell,orion-wdt", 0xf1020300, "orion_wdt", NULL),
> OF_DEV_AUXDATA("marvell,orion-sata", 0xf1080000, "sata_mv.0", NULL),
> OF_DEV_AUXDATA("marvell,orion-nand", 0xf4000000, "orion_nand", NULL),
> + OF_DEV_AUXDATA("marvell,mv643xx", 0xf1072000, MV643XX_ETH_NAME ".0",
> + NULL),
> + OF_DEV_AUXDATA("marvell,mv643xx", 0xf1076000, MV643XX_ETH_NAME ".1",
> + NULL),
> {},
> };
Please don't do string concatenation like this, it just makes it harder to grep for the
strings.
> @@ -2654,15 +2677,22 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
> /*
> * Check whether the error interrupt is hooked up.
> */
> - res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> - if (res != NULL) {
> + if (pdev->dev.of_node) {
> + irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
> + } else {
> + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> + if (res)
> + irq = res->start;
> + }
> +
Why is this necessary? In theory, the old code should be the same as the new one,
unless something goes wrong in the domain registration.
Arnd
^ permalink raw reply
* wlcore: might_sleep operation in interrupt handler
From: Denis Yefremov @ 2012-07-31 18:28 UTC (permalink / raw)
To: Luciano Coelho
Cc: John W. Linville, Eliad Peller, Arik Nemtsov, Eyal Shapira,
linux-wireless, netdev, linux-kernel, ldv-project
Interrupt handler wlcore_irq in wlcore/main.c file
invokes mutex_lock that is might sleep operation.
Found by Linux Driver Verification project (linuxtesting.org)
within my participation in the GSoC 2012 program.
drivers/net/wireless/ti/wlcore/main.c
static irqreturn_t wlcore_irq(int irq, void *cookie)
{
int ret;
unsigned long flags;
struct wl1271 *wl = cookie;
/* TX might be handled here, avoid redundant work */
set_bit(WL1271_FLAG_TX_PENDING, &wl->flags);
cancel_work_sync(&wl->tx_work);
mutex_lock(&wl->mutex);
...
}
int __devinit wlcore_probe(struct wl1271 *wl, struct platform_device *pdev)
{
...
ret = request_threaded_irq(wl->irq, wl12xx_hardirq, wlcore_irq,
irqflags,
pdev->name, wl);
...
}
^ permalink raw reply
* cpu usage on blocking network call
From: Robert Engels @ 2012-07-31 19:14 UTC (permalink / raw)
To: netdev
I have a strange problem, and was hoping the developers could provide
some insight.
I have tested with ubuntu 12.04, with the 3.2.0-23 lowlatency kernel.
I also tested with a 3.0.31 vanilla realtime kernel on a different
machine.
I open a blocking socket (and connect to a remote client), and start
two threads, a reader and a writer.
I pump LOTS of data down the writer, but do not receive any data on
the reader (by design).
The reader thread is reporting some CPU usage (not a lot, about 10% of
the writer cpu). I determine this using "top", and other profiling
tools.
I also run strace on the thread, and it shows that it is blocked in
read() call, and that is doesn't return.
Why/How is the reader thread consuming CPU? Poorly written driver?
Kernel bug? Or is this expected behavior or the kernel?
I am more than willing to spend more time tracking it down in the
kernel, but I'd like some direction.
--
Robert Engels
OptionsCity Software Inc.
Chicago, IL
^ permalink raw reply
* Re: [PATCH v2 3/6] mv643xx.c: Add basic device tree support.
From: Andrew Lunn @ 2012-07-31 19:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Ian Molton, linux-arm-kernel, andrew, thomas.petazzoni, ben.dooks,
netdev
In-Reply-To: <201207311823.54857.arnd@arndb.de>
On Tue, Jul 31, 2012 at 06:23:54PM +0000, Arnd Bergmann wrote:
> On Tuesday 31 July 2012, Ian Molton wrote:
> > @@ -33,6 +34,10 @@ struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
> > OF_DEV_AUXDATA("marvell,orion-wdt", 0xf1020300, "orion_wdt", NULL),
> > OF_DEV_AUXDATA("marvell,orion-sata", 0xf1080000, "sata_mv.0", NULL),
> > OF_DEV_AUXDATA("marvell,orion-nand", 0xf4000000, "orion_nand", NULL),
> > + OF_DEV_AUXDATA("marvell,mv643xx", 0xf1072000, MV643XX_ETH_NAME ".0",
> > + NULL),
> > + OF_DEV_AUXDATA("marvell,mv643xx", 0xf1076000, MV643XX_ETH_NAME ".1",
> > + NULL),
> > {},
> > };
>
> Please don't do string concatenation like this, it just makes it harder to grep for the
> strings.
Hi Arnd
This pattern is used in other places, e.g. when creating the
clocks. The macro MV643XX_ETH_NAME is also used when creating the
platform data, and in the driver itself.
Are you suggested we replace this with "mv643xx_eth.0"? Or is adding
the macro
#define MV643XX_ETH_NAME0 "mv643xx_eth.0"
in include/linux/mv643xx_eth.h O.K, since grep will find it, and
induce the grep'er to perform a second grep on the macro?
Andrew
^ permalink raw reply
* Re: [PATCH v2] ipv4: percpu nh_rth_output cache
From: Alexander Duyck @ 2012-07-31 20:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1343749530.21269.336.camel@edumazet-glaptop>
On 07/31/2012 08:45 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Input path is mostly run under RCU and doesnt touch dst refcnt
>
> But output path on forwarding or UDP workloads hits
> badly dst refcount, and we have lot of false sharing, for example
> in ipv4_mtu() when reading rt->rt_pmtu
>
> Using a percpu cache for nh_rth_output gives a nice performance
> increase at a small cost.
>
> 24 udpflood test on my 24 cpu machine (dummy0 output device)
> (each process sends 1.000.000 udp frames, 24 processes are started)
>
> before : 5.24 s
> after : 2.06 s
> For reference, time on linux-3.5 : 6.60 s
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> v2: use __this_cpu_ptr() and slighly better annotations to avoid
> ugly casts
>
> On top on previous "ipv4: Restore old dst_free() behavior" patch
>
> We probably can remove all paddings in struct dst_entry
>
I've done some quick testing and it looks like it has little to no
effect on routing performance in my system, but for UDP workloads it is
making a huge difference. I just ran a simple test with 16 sessions of
netperf all sending UDP small packets. Without your patch it runs at
just over 2.7Mpps, with your patch it is runs at over 10.5Mpps.
Tested-by: Alexander Duyck <alexander.h.duyck@intel.com>
^ permalink raw reply
* Re: wlcore: might_sleep operation in interrupt handler
From: Johannes Berg @ 2012-07-31 20:14 UTC (permalink / raw)
To: Denis Yefremov
Cc: Luciano Coelho, John W. Linville, Eliad Peller, Arik Nemtsov,
Eyal Shapira, linux-wireless, netdev, linux-kernel, ldv-project
In-Reply-To: <CADKZ3FKDw78ac9JPXJuw0s7Mqg1RrVfonbjXZ6zHmtwF2i5HoQ@mail.gmail.com>
On Tue, 2012-07-31 at 22:28 +0400, Denis Yefremov wrote:
> Interrupt handler wlcore_irq in wlcore/main.c file
> invokes mutex_lock that is might sleep operation.
> int __devinit wlcore_probe(struct wl1271 *wl, struct platform_device *pdev)
> {
> ...
> ret = request_threaded_irq(wl->irq, wl12xx_hardirq, wlcore_irq,
> irqflags,
> pdev->name, wl);
Yes, umm, why do you think they're using a *threaded* IRQ? :-)
johannes
^ permalink raw reply
* Re: [PATCH v2 3/6] mv643xx.c: Add basic device tree support.
From: Arnd Bergmann @ 2012-07-31 20:18 UTC (permalink / raw)
To: Andrew Lunn
Cc: Ian Molton, linux-arm-kernel, thomas.petazzoni, ben.dooks, netdev
In-Reply-To: <20120731192458.GE28852@lunn.ch>
On Tuesday 31 July 2012, Andrew Lunn wrote:
> This pattern is used in other places, e.g. when creating the
> clocks. The macro MV643XX_ETH_NAME is also used when creating the
> platform data, and in the driver itself.
>
> Are you suggested we replace this with "mv643xx_eth.0"? Or is adding
> the macro
>
> #define MV643XX_ETH_NAME0 "mv643xx_eth.0"
>
> in include/linux/mv643xx_eth.h O.K, since grep will find it, and
> induce the grep'er to perform a second grep on the macro?
I meant the former. Just remove the macro entirely, or at least
don't add new users.
Arnd
^ permalink raw reply
* Re: [PATCH] igb: correct hardware type (i210/i211) check in igb_loopback_test()
From: Jesper Juhl @ 2012-07-31 20:23 UTC (permalink / raw)
To: Wyborny, Carolyn, David S. Miller
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Rick Jones, Allan, Bruce W, linux-kernel@vger.kernel.org,
Brandeburg, Jesse, Ronciak, John
In-Reply-To: <9BBC4E0CF881AA4299206E2E1412B62630D64753@ORSMSX102.amr.corp.intel.com>
On Wed, 25 Jul 2012, Wyborny, Carolyn wrote:
>
> > -----Original Message-----
> > From: Jesper Juhl [mailto:jj@chaosbits.net]
> > Sent: Wednesday, July 25, 2012 12:06 PM
> > To: linux-kernel@vger.kernel.org
> > Cc: netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net; Wyborny, Carolyn; Pieper, Jeffrey E; Kirsher, Jeffrey T; Rick Jones; Ronciak, John; Brandeburg, Jesse; Allan, Bruce W; Skidmore, Donald C; Rose, Gregory V; Waskiewicz Jr, Peter P; Duyck, Alexander H; David S. Miller
> > Subject: [PATCH] igb: correct hardware type (i210/i211) check in igb_loopback_test()
> >
> > In the original code
> > ...
> > if ((adapter->hw.mac.type == e1000_i210)
> > || (adapter->hw.mac.type == e1000_i210)) { ...
> > the second check of 'adapter->hw.mac.type' is pointless since it tests for the exact same value as the first.
> >
> > After reading through a few other parts of the driver I believe that the second check was actually intended to check for 'e1000_i211'
> > rather than 'e1000_i210', but I admit that I'm not certain so someone with more knowledge about this driver should ACK the patch before it gets merged.
> >
> > Unfortunately I have no hardware to actually test this on, so it is compile tested only.
> >
> > Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> > ---
> > drivers/net/ethernet/intel/igb/igb_ethtool.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> > index a19c84c..ad489b7 100644
> > --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> > +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> > @@ -1783,7 +1783,7 @@ static int igb_loopback_test(struct igb_adapter *adapter, u64 *data)
> > goto out;
> > }
> > if ((adapter->hw.mac.type == e1000_i210)
> > - || (adapter->hw.mac.type == e1000_i210)) {
> > + || (adapter->hw.mac.type == e1000_i211)) {
> > dev_err(&adapter->pdev->dev,
> > "Loopback test not supported "
> > "on this part at this time.\n");
> > --
> > 1.7.11.3
> >
>
> ACK.
>
> Good catch. Thanks Jesper!
>
> Carolyn
>
> Carolyn Wyborny
> Linux Development
> LAN Access Division
> Intel Corporation
>
Thank you for the ack Carolyn.
David: will you take this in the networking tree?
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: wlcore: might_sleep operation in interrupt handler
From: Denis Yefremov @ 2012-07-31 20:48 UTC (permalink / raw)
To: Johannes Berg
Cc: Luciano Coelho, John W. Linville, Eliad Peller, Arik Nemtsov,
Eyal Shapira, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ldv-project-ufN2psIa012HXe+LvDLADg
In-Reply-To: <1343765698.4474.10.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
More precise (IRQF_ONESHOT flag may be used):
int __devinit wlcore_probe(struct wl1271 *wl, struct platform_device *pdev)
{
...
if (wl->platform_quirks & WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
irqflags = IRQF_TRIGGER_RISING;
else
irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
ret = request_threaded_irq(wl->irq, wl12xx_hardirq, wlcore_irq,
irqflags,
pdev->name, wl);
2012/8/1 Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
> On Tue, 2012-07-31 at 22:28 +0400, Denis Yefremov wrote:
>> Interrupt handler wlcore_irq in wlcore/main.c file
>> invokes mutex_lock that is might sleep operation.
>
>> int __devinit wlcore_probe(struct wl1271 *wl, struct platform_device *pdev)
>> {
>> ...
>> ret = request_threaded_irq(wl->irq, wl12xx_hardirq, wlcore_irq,
>> irqflags,
>> pdev->name, wl);
>
> Yes, umm, why do you think they're using a *threaded* IRQ? :-)
>
> johannes
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox