* Re: [PATCH v6 5/7] can: kvaser_usb: Update interface state before exiting on OOM
From: Andri Yngvason @ 2015-01-26 10:52 UTC (permalink / raw)
To: Marc Kleine-Budde, Ahmed S. Darwish, Olivier Sobrie,
Oliver Hartkopp, Wolfgang Grandegger
Cc: Linux-CAN, netdev, LKML
In-Reply-To: <54C61BE4.8070105@pengutronix.de>
Quoting Marc Kleine-Budde (2015-01-26 10:50:12)
> On 01/26/2015 11:28 AM, Andri Yngvason wrote:
> > Quoting Ahmed S. Darwish (2015-01-26 05:27:19)
> >> From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> >>
> >> Update all of the can interface's state and error counters before
> >> trying any skb allocation that can actually fail with -ENOMEM.
> >>
> >> Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de>
> >> Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> >> ---
> >> drivers/net/can/usb/kvaser_usb.c | 181 ++++++++++++++++++++++----------------
> >> 1 files changed, 105 insertions(+), 76 deletions(-)
> [..]
>
> > Looks good to me.
>
> Can I add your Acked-by to 5-7?
>
Yes.
--
Andri
^ permalink raw reply
* Re: [PATCH v6 5/7] can: kvaser_usb: Update interface state before exiting on OOM
From: Marc Kleine-Budde @ 2015-01-26 10:53 UTC (permalink / raw)
To: Andri Yngvason, Ahmed S. Darwish, Olivier Sobrie, Oliver Hartkopp,
Wolfgang Grandegger
Cc: Linux-CAN, netdev, LKML
In-Reply-To: <20150126105250.19943.75012@shannon>
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
On 01/26/2015 11:52 AM, Andri Yngvason wrote:
> Quoting Marc Kleine-Budde (2015-01-26 10:50:12)
>> On 01/26/2015 11:28 AM, Andri Yngvason wrote:
>>> Quoting Ahmed S. Darwish (2015-01-26 05:27:19)
>>>> From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
>>>>
>>>> Update all of the can interface's state and error counters before
>>>> trying any skb allocation that can actually fail with -ENOMEM.
>>>>
>>>> Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de>
>>>> Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
>>>> ---
>>>> drivers/net/can/usb/kvaser_usb.c | 181 ++++++++++++++++++++++----------------
>>>> 1 files changed, 105 insertions(+), 76 deletions(-)
>> [..]
>>
>>> Looks good to me.
>>
>> Can I add your Acked-by to 5-7?
>>
> Yes.
Tnx.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v6 0/7] can: kvaser_usb: Leaf bugfixes and USBCan-II support
From: Marc Kleine-Budde @ 2015-01-26 10:56 UTC (permalink / raw)
To: Ahmed S. Darwish, Olivier Sobrie, Oliver Hartkopp,
Wolfgang Grandegger, Andri Yngvason
Cc: Linux-CAN, netdev, LKML
In-Reply-To: <54C611DA.8050500@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]
On 01/26/2015 11:07 AM, Marc Kleine-Budde wrote:
> On 01/26/2015 06:17 AM, Ahmed S. Darwish wrote:
>> Hi!
>>
>> This is an updated patch series for the Kvaser CAN/USB devices:
>>
>> 1- Extra patches are now added to the series. Most importantly
>> patch #1 which fixes a critical `sleep in atomic context' bug
>> in the current upstream driver. Patch #2 fixes a corruption in
>> the kernel logs, also affecting current upstream driver. Patch
>> #4 was originally USBCan-II only, but since it's a generic fix,
>> it's now retrofitted to the Leaf-only upstream driver first.
>>
>> 2- The series has been re-organized so that patches #1 -> #4
>> inclusive can go to linux-can/origin, while the rest can move
>> to -next.
>>
>> 3- There are some important updates regarding the USBCan-II
>> error counters, and how really erratic their heaviour is. All
>> the new details are covered at the bottom of this URL:
>>
>> http://article.gmane.org/gmane.linux.can/7481
>>
>> 4- Attached below is the new candump traces. Now
>> `back-to-error-active' states appear _if_ the hardware was
>> kind enough and decreased the error counters appropriately.
>> The earlier code did not recognize the error counters going
>> down, thus the `back-to-error-active' transitions did not
>> appear.
>
> For patches 5-7 I'm waiting for an Acked by Andri.
Applied to can-next, it's available as can-next-testing in the
linux-can-next repo.
Marc.
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] vlan: take link netns into account in vlan_newlink()
From: Nicolas Dichtel @ 2015-01-26 11:02 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <1422265455-4331-1-git-send-email-nicolas.dichtel@6wind.com>
Le 26/01/2015 10:44, Nicolas Dichtel a écrit :
> When IFLA_LINK_NETNSID is set, the ifindex from IFLA_LINK comes from another
> netns.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Please, discard this patch. It's not the right fix.
I will send an update later.
^ permalink raw reply
* Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
From: Stathis Voukelatos @ 2015-01-26 11:05 UTC (permalink / raw)
To: Stathis Voukelatos
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1817503.588aons8oi@radagast>
On 23/01/15 18:12, James Hogan wrote:
>> diff --git a/drivers/net/pkt-sniffer/Kconfig
>> b/drivers/net/pkt-sniffer/Kconfig
>> new file mode 100644
>> index 0000000..26b4f98
>> --- /dev/null
>> +++ b/drivers/net/pkt-sniffer/Kconfig
>> @@ -0,0 +1,23 @@
>> +menuconfig PKT_SNIFFER
>> + tristate "Linn packet sniffer support"
> Should the kconfig symbol have linn in the name, or should the prompt
> not have lin in the name?
No it should not actually, as this option enables the core (framework)
driver.
Anybody could add a backend using the framework. Will change the text.
>> +
>> +config PKT_SNIFFER_ETHER
>> + tristate "Ethernet packet sniffer"
>> + depends on MIPS
> worth adding || COMPILE_TEST to get compile coverage on x86 allmodconfig
> builds, or does it have hard dependencies on the MIPS arch?
>
No hard dependencies on MIPS arch. Will change as you suggest.
Will implement your other recommendations too in the next version
of the patchset.
Thank you,
Stathis
--
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
* Re: udp_diag: Fix socket skipping within chain
From: Pavel Emelyanov @ 2015-01-26 11:07 UTC (permalink / raw)
To: Herbert Xu, netdev
In-Reply-To: <20150123210240.GA1569@gondor.apana.org.au>
On 01/24/2015 12:02 AM, Herbert Xu wrote:
> While working on rhashtable walking I noticed that the UDP diag
> dumping code is buggy. In particular, the socket skipping within
> a chain never happens, even though we record the number of sockets
> that should be skipped.
>
> As this code was supposedly copied from TCP, this patch does what
> TCP does and resets num before we walk a chain.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Pavel Emelyanov <xemul@parallels.com>
Thanks,
Pavel
> diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
> index 7927db0..4a000f1 100644
> --- a/net/ipv4/udp_diag.c
> +++ b/net/ipv4/udp_diag.c
> @@ -99,11 +99,13 @@ static void udp_dump(struct udp_table *table, struct sk_buff *skb, struct netlin
> s_slot = cb->args[0];
> num = s_num = cb->args[1];
>
> - for (slot = s_slot; slot <= table->mask; num = s_num = 0, slot++) {
> + for (slot = s_slot; slot <= table->mask; s_num = 0, slot++) {
> struct sock *sk;
> struct hlist_nulls_node *node;
> struct udp_hslot *hslot = &table->hash[slot];
>
> + num = 0;
> +
> if (hlist_nulls_empty(&hslot->head))
> continue;
>
>
^ permalink raw reply
* Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
From: Stathis Voukelatos @ 2015-01-26 11:11 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, linux-kernel, devicetree, abrestic
In-Reply-To: <1422135432.18650.2.camel@perches.com>
On 24/01/15 21:37, Joe Perches wrote:
> On Fri, 2015-01-23 at 10:07 +0000, Stathis Voukelatos wrote:
>> This patch adds support the Ethernet Packet Sniffer H/W module
>> developed by Linn Products Ltd and found in the IMG Pistachio SoC.
>> The module allows Ethernet packets to be parsed, matched against
>> a user-defined pattern and timestamped. It sits between a 100M
>> Ethernet MAC and PHY and is completely passive with respect to
>> Ethernet frames.
> []
>> include/linux/pkt_sniffer.h | 89 +++++
> Why should this file be here?
> Why not in the drivers/net/pkt-sniffer directory?
>
Hi Joe,
Thank you for the feedback.
This header file is the public API for the driver.
Should it not live under the 'include' directory?
Several other drivers seem to follow that convention.
I will include your other suggestions in the next version
of the patch set.
Thank you,
Stathis
^ permalink raw reply
* Re: [PATCH] net: macb: Remove CONFIG_PM ifdef because of compilation warning
From: Nicolas Ferre @ 2015-01-26 11:11 UTC (permalink / raw)
To: Michal Simek, linux-kernel, monstr; +Cc: netdev
In-Reply-To: <7970145ad4d864eaf31d694d22f2fecbcf6825c9.1422002161.git.michal.simek@xilinx.com>
Le 23/01/2015 09:36, Michal Simek a écrit :
> Fix compilation warning:
> drivers/net/ethernet/cadence/macb.c:2415:12: warning: 'macb_suspend'
> defined but not used [-Wunused-function]
> static int macb_suspend(struct device *dev)
> drivers/net/ethernet/cadence/macb.c:2432:12: warning: 'macb_resume'
> defined but not used [-Wunused-function]
> static int macb_resume(struct device *dev)
>
> when CONFIG_PM=y, CONFIG_PM_SLEEP=n are used.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
okay:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
>
> drivers/net/ethernet/cadence/macb.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index 3767271c7667..23ae32f118c2 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -2411,8 +2411,7 @@ static int __exit macb_remove(struct platform_device *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM
> -static int macb_suspend(struct device *dev)
> +static int __maybe_unused macb_suspend(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> struct net_device *netdev = platform_get_drvdata(pdev);
> @@ -2429,7 +2428,7 @@ static int macb_suspend(struct device *dev)
> return 0;
> }
>
> -static int macb_resume(struct device *dev)
> +static int __maybe_unused macb_resume(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> struct net_device *netdev = platform_get_drvdata(pdev);
> @@ -2444,7 +2443,6 @@ static int macb_resume(struct device *dev)
>
> return 0;
> }
> -#endif
>
> static SIMPLE_DEV_PM_OPS(macb_pm_ops, macb_suspend, macb_resume);
>
> --
> 1.8.2.3
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v2 0/2] Add ACPI support for NXP PN544
From: Robert Dolca @ 2015-01-26 11:13 UTC (permalink / raw)
To: linux-nfc-hn68Rpc1hR1g9hUCZPvPmw, Lauro Ramos Venancio,
Aloisio Almeida Jr, Samuel Ortiz
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller, Berg Johannes,
Clement Perrochaud, Robert Dolca
This patch set introduces ACPI support for PN544.
gpio_set_value was replaced with gpio_set_value_cansleep in order
to allow GPIO access that may sleep. This is particularelly useful
when GPIO is accessed using busses like I2C, SPI, USB
Changes since v1:
- Added cover letter
- Removed debug define and Kconfig include
- Minor fixes to patch subjects
Links to v1:
- http://lkml.iu.edu/hypermail/linux/kernel/1501.1/00943.html
- http://lkml.iu.edu/hypermail/linux/kernel/1501.1/00944.html
Robert Dolca (2):
NFC: PN544: GPIO access that may sleep
NFC: Add ACPI support for NXP PN544
drivers/nfc/pn544/i2c.c | 137 +++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 124 insertions(+), 13 deletions(-)
--
1.9.1
--
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
* [PATCH v2 2/2] NFC: Add ACPI support for NXP PN544
From: Robert Dolca @ 2015-01-26 11:13 UTC (permalink / raw)
To: linux-nfc, Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz
Cc: linux-kernel, linux-wireless, netdev, David S. Miller,
Berg Johannes, Clement Perrochaud, Robert Dolca
In-Reply-To: <1422270817-10950-1-git-send-email-robert.dolca@intel.com>
Currently there is no support for ACPI.
This patch uses the following configuration:
- Device id: NXP5440
- Pin mapping:
- 0 IRQ pin
- 1 enable pin
- 2 firmware pin
Signed-off-by: Robert Dolca <robert.dolca@intel.com>
---
drivers/nfc/pn544/i2c.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 112 insertions(+), 3 deletions(-)
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index d9018cd..ae817b0 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -24,6 +24,7 @@
#include <linux/gpio.h>
#include <linux/of_gpio.h>
#include <linux/of_irq.h>
+#include <linux/acpi.h>
#include <linux/miscdevice.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
@@ -41,6 +42,11 @@
#define PN544_I2C_FRAME_HEADROOM 1
#define PN544_I2C_FRAME_TAILROOM 2
+/* GPIO names */
+#define PN544_GPIO_NAME_IRQ "pn544_irq"
+#define PN544_GPIO_NAME_FW "pn544_fw"
+#define PN544_GPIO_NAME_EN "pn544_en"
+
/* framing in HCI mode */
#define PN544_HCI_I2C_LLC_LEN 1
#define PN544_HCI_I2C_LLC_CRC 2
@@ -58,6 +64,13 @@ static struct i2c_device_id pn544_hci_i2c_id_table[] = {
MODULE_DEVICE_TABLE(i2c, pn544_hci_i2c_id_table);
+static const struct acpi_device_id pn544_hci_i2c_acpi_match[] = {
+ {"NXP5440", 0},
+ {}
+};
+
+MODULE_DEVICE_TABLE(acpi, pn544_hci_i2c_acpi_match);
+
#define PN544_HCI_I2C_DRIVER_NAME "pn544_hci_i2c"
/*
@@ -861,6 +874,90 @@ exit_state_wait_secure_write_answer:
}
}
+static int pn544_hci_i2c_acpi_request_resources(struct i2c_client *client)
+{
+ struct pn544_i2c_phy *phy = i2c_get_clientdata(client);
+ const struct acpi_device_id *id;
+ struct gpio_desc *gpiod_en, *gpiod_irq, *gpiod_fw;
+ struct device *dev;
+ int ret;
+
+ if (!client)
+ return -EINVAL;
+
+ dev = &client->dev;
+
+ /* Match the struct device against a given list of ACPI IDs */
+ id = acpi_match_device(dev->driver->acpi_match_table, dev);
+
+ if (!id)
+ return -ENODEV;
+
+ /* Get EN GPIO from ACPI */
+ gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1);
+ if (IS_ERR(gpiod_en)) {
+ nfc_err(dev,
+ "Unable to get EN GPIO\n");
+ return -ENODEV;
+ }
+
+ phy->gpio_en = desc_to_gpio(gpiod_en);
+
+ /* Configuration EN GPIO */
+ ret = gpiod_direction_output(gpiod_en, 0);
+ if (ret) {
+ nfc_err(dev, "Fail EN pin direction\n");
+ return ret;
+ }
+
+ /* Get FW GPIO from ACPI */
+ gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2);
+ if (IS_ERR(gpiod_fw)) {
+ nfc_err(dev,
+ "Unable to get FW GPIO\n");
+ return -ENODEV;
+ }
+
+ phy->gpio_fw = desc_to_gpio(gpiod_fw);
+
+ /* Configuration FW GPIO */
+ ret = gpiod_direction_output(gpiod_fw, 0);
+ if (ret) {
+ nfc_err(dev, "Fail FW pin direction\n");
+ return ret;
+ }
+
+ /* Get IRQ GPIO */
+ gpiod_irq = devm_gpiod_get_index(dev, PN544_GPIO_NAME_IRQ, 0);
+ if (IS_ERR(gpiod_irq)) {
+ nfc_err(dev,
+ "Unable to get IRQ GPIO\n");
+ return -ENODEV;
+ }
+
+ phy->gpio_irq = desc_to_gpio(gpiod_irq);
+
+ /* Configure IRQ GPIO */
+ ret = gpiod_direction_input(gpiod_irq);
+ if (ret) {
+ nfc_err(dev, "Fail IRQ pin direction\n");
+ return ret;
+ }
+
+ /* Map the pin to an IRQ */
+ ret = gpiod_to_irq(gpiod_irq);
+ if (ret < 0) {
+ nfc_err(dev, "Fail pin IRQ mapping\n");
+ return ret;
+ }
+
+ nfc_info(dev, "GPIO resource, no:%d irq:%d\n",
+ desc_to_gpio(gpiod_irq), ret);
+ client->irq = ret;
+
+ return 0;
+}
+
#ifdef CONFIG_OF
static int pn544_hci_i2c_of_request_resources(struct i2c_client *client)
@@ -886,7 +983,7 @@ static int pn544_hci_i2c_of_request_resources(struct i2c_client *client)
phy->gpio_en = ret;
/* Configuration of EN GPIO */
- ret = gpio_request(phy->gpio_en, "pn544_en");
+ ret = gpio_request(phy->gpio_en, PN544_GPIO_NAME_EN);
if (ret) {
nfc_err(&client->dev, "Fail EN pin\n");
goto err_dt;
@@ -908,7 +1005,7 @@ static int pn544_hci_i2c_of_request_resources(struct i2c_client *client)
phy->gpio_fw = ret;
/* Configuration of FW GPIO */
- ret = gpio_request(phy->gpio_fw, "pn544_fw");
+ ret = gpio_request(phy->gpio_fw, PN544_GPIO_NAME_FW);
if (ret) {
nfc_err(&client->dev, "Fail FW pin\n");
goto err_gpio_en;
@@ -1003,6 +1100,14 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
phy->gpio_en = pdata->get_gpio(NFC_GPIO_ENABLE);
phy->gpio_fw = pdata->get_gpio(NFC_GPIO_FW_RESET);
phy->gpio_irq = pdata->get_gpio(NFC_GPIO_IRQ);
+ /* Using ACPI */
+ } else if (ACPI_HANDLE(&client->dev)) {
+ r = pn544_hci_i2c_acpi_request_resources(client);
+ if (r) {
+ nfc_err(&client->dev,
+ "Cannot get ACPI data\n");
+ return r;
+ }
} else {
nfc_err(&client->dev, "No platform data\n");
return -EINVAL;
@@ -1022,9 +1127,12 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
PN544_I2C_FRAME_HEADROOM, PN544_I2C_FRAME_TAILROOM,
PN544_HCI_I2C_LLC_MAX_PAYLOAD,
pn544_hci_i2c_fw_download, &phy->hdev);
- if (r < 0)
+ if (r < 0) {
+ nfc_err(&client->dev, "HCI Probing error\n");
goto err_hci;
+ }
+ nfc_info(&client->dev, "NFC I2C driver loaded\n");
return 0;
err_hci:
@@ -1082,6 +1190,7 @@ static struct i2c_driver pn544_hci_i2c_driver = {
.name = PN544_HCI_I2C_DRIVER_NAME,
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(of_pn544_i2c_match),
+ .acpi_match_table = ACPI_PTR(pn544_hci_i2c_acpi_match),
},
.probe = pn544_hci_i2c_probe,
.id_table = pn544_hci_i2c_id_table,
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] NFC: PN544: GPIO access that may sleep
From: Robert Dolca @ 2015-01-26 11:13 UTC (permalink / raw)
To: linux-nfc, Lauro Ramos Venancio, Aloisio Almeida Jr, Samuel Ortiz
Cc: linux-kernel, linux-wireless, netdev, David S. Miller,
Berg Johannes, Clement Perrochaud, Robert Dolca
In-Reply-To: <1422270817-10950-1-git-send-email-robert.dolca@intel.com>
gpio_set_value was replaced with gpio_set_value_cansleep in order
to allow GPIO access that may sleep. This is particularelly useful
when GPIO is accessed using busses like I2C, SPI, USB
Signed-off-by: Robert Dolca <robert.dolca@intel.com>
---
drivers/nfc/pn544/i2c.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index fc02e8d..d9018cd 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -195,18 +195,19 @@ static void pn544_hci_i2c_platform_init(struct pn544_i2c_phy *phy)
nfc_info(&phy->i2c_dev->dev, "Detecting nfc_en polarity\n");
/* Disable fw download */
- gpio_set_value(phy->gpio_fw, 0);
+ gpio_set_value_cansleep(phy->gpio_fw, 0);
for (polarity = 0; polarity < 2; polarity++) {
phy->en_polarity = polarity;
retry = 3;
while (retry--) {
/* power off */
- gpio_set_value(phy->gpio_en, !phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_en,
+ !phy->en_polarity);
usleep_range(10000, 15000);
/* power on */
- gpio_set_value(phy->gpio_en, phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_en, phy->en_polarity);
usleep_range(10000, 15000);
/* send reset */
@@ -225,13 +226,14 @@ static void pn544_hci_i2c_platform_init(struct pn544_i2c_phy *phy)
"Could not detect nfc_en polarity, fallback to active high\n");
out:
- gpio_set_value(phy->gpio_en, !phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_en, !phy->en_polarity);
}
static void pn544_hci_i2c_enable_mode(struct pn544_i2c_phy *phy, int run_mode)
{
- gpio_set_value(phy->gpio_fw, run_mode == PN544_FW_MODE ? 1 : 0);
- gpio_set_value(phy->gpio_en, phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_fw,
+ run_mode == PN544_FW_MODE ? 1 : 0);
+ gpio_set_value_cansleep(phy->gpio_en, phy->en_polarity);
usleep_range(10000, 15000);
phy->run_mode = run_mode;
@@ -254,14 +256,14 @@ static void pn544_hci_i2c_disable(void *phy_id)
{
struct pn544_i2c_phy *phy = phy_id;
- gpio_set_value(phy->gpio_fw, 0);
- gpio_set_value(phy->gpio_en, !phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_fw, 0);
+ gpio_set_value_cansleep(phy->gpio_en, !phy->en_polarity);
usleep_range(10000, 15000);
- gpio_set_value(phy->gpio_en, phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_en, phy->en_polarity);
usleep_range(10000, 15000);
- gpio_set_value(phy->gpio_en, !phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_en, !phy->en_polarity);
usleep_range(10000, 15000);
phy->powered = 0;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
From: Stathis Voukelatos @ 2015-01-26 11:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org
In-Reply-To: <3515756.ch1oRd7PaS@wuerfel>
On 23/01/15 10:21, Arnd Bergmann wrote:
> On Friday 23 January 2015 10:07:01 Stathis Voukelatos wrote:
>> +- interrupts : sniffer interrupt specifier
>> +- clocks : specify the system clock for the peripheral
>> +- clock-names : must contain the "sys" entry
>> +- fifo-block-words : number of words in one data FIFO entry
>> +
>> +Example:
>> +
>> +sniffer@1814a000 {
>> + compatible = "linn,eth-sniffer";
>> + reg = <0x1814a000 0x100>, <0x1814a400 0x400>, <0x1814a800 0x400>;
>> + reg-names = "regs", "tx-ram", "rx-ram";
>> + interrupts = <GIC_SHARED 58 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "eth-sniffer-irq";
>> + clocks = <&system_clk>;
>> + clock-names = "sys";
>> + fifo-block-words = <4>;
>>
> The example contains an interrupt-names property that is not documented.
> If you want to name interrupts, the exact name strings need to
> be mandated by the binding. Alternatively just drop the name.
> I notice that the driver requests the first interrupt without giving
> a name anyway, and the description above suggests that there can
> only be one interrupt.
>
> Arnd
>
Hi Arnd,
Yes, we can probably just drop the interrupt name field.
It will be done in the next version of the patch set.
Thank you,
Stathis
--
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
* Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Marcelo Ricardo Leitner @ 2015-01-26 11:46 UTC (permalink / raw)
To: Sun Paul, Daniel Borkmann
Cc: Michael Tuexen, Vlad Yasevich, linux-sctp, netdev, linux-kernel
In-Reply-To: <CAFXGft+XZCmhuwj2QTCiU0MD10Uo+WZ3WCC+rfbsd_Lxbhk3iw@mail.gmail.com>
Hi,
On 25-01-2015 23:27, Sun Paul wrote:
> Hi
>
> sorry for the late reply. I am a bit confused. when side-A sends a
> request to side-B, and side-B return the response, but side-A keep
> re-transmit the same request to side-B, why side-B needed to send a
> ABORT to side-A?
That happens on data transfers. When A pushes data to B, A has to retry it
until B finally acknowledges it and A receive this signal. If the ack from B
gets dropped, A has no way to know if a) the ack was lost or b) its initial
message never actually made it to A, thus it retransmits. If it reaches a
limit, it gives up..
> If it is used in order to reestablish the connection, shoudn't it
> should be side-A to send ABORT instead?
Meant to reestablish it? Not really.. just to keep both sides in sync, as A
has given up by then.
Marcelo
> - PS
>
> On Sat, Jan 24, 2015 at 3:05 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> On 01/23/2015 07:36 PM, Michael Tuexen wrote:
>> ...
>>>
>>> Yepp. It might not reach the peer or it might. If it does it helps
>>> to keep the states in sync. If it doesn't it sometimes helps in
>>> analysing tracefiles. In BSD, we also send it. It is not required,
>>> doesn't harm and is useful in some cases...
>>
>>
>> Ok, as the TCB is destroyed in any case, should be fine then.
>>
>> Thanks,
>> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next v2 4/5] bonding: fix LACP PDU not sent on slave port sometimes
From: Sergei Shtylyov @ 2015-01-26 12:04 UTC (permalink / raw)
To: Jonathan Toppins, Jay Vosburgh, Veaceslav Falico, Andy Gospodarek
Cc: netdev, Satish Ashok, Andy Gospodarek
In-Reply-To: <1422253021-3798-5-git-send-email-jtoppins@cumulusnetworks.com>
Hello.
On 1/26/2015 9:17 AM, Jonathan Toppins wrote:
> From: Satish Ashok <sashok@cumulusnetworks.com>
> When a slave is added to a bond and it is not in full duplex mode,
> AD_PORT_LACP_ENABLED flag is cleared, due to this LACP PDU is not sent
s/is not/not being/.
> on slave. When the duplex is changed to full, the flag needs to be set
> to send LACP PDU.
> Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
> Reviewed-by: Nikolay Aleksandrov <nikolay@redhat.com>
> Signed-off-by: Satish Ashok <sashok@cumulusnetworks.com>
> Signed-off-by: Jonathan Toppins <jtoppins@cumulusnetworks.com>
> ---
> drivers/net/bonding/bond_3ad.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
> index e3c96b2..cfc4a9c 100644
> --- a/drivers/net/bonding/bond_3ad.c
> +++ b/drivers/net/bonding/bond_3ad.c
> @@ -2219,8 +2219,10 @@ static int bond_3ad_rx_indication(struct lacpdu *lacpdu, struct slave *slave,
> switch (lacpdu->subtype) {
> case AD_TYPE_LACPDU:
> ret = RX_HANDLER_CONSUMED;
> - netdev_dbg(slave->bond->dev, "Received LACPDU on port %d\n",
> - port->actor_port_number);
> + netdev_dbg(slave->bond->dev,
> + "Received LACPDU on port %d slave %s\n",
> + port->actor_port_number,
> + slave->dev->name);
> /* Protect against concurrent state machines */
> spin_lock(&slave->bond->mode_lock);
> ad_rx_machine(lacpdu, port);
> @@ -2312,7 +2314,10 @@ void bond_3ad_adapter_duplex_changed(struct slave *slave)
> port->actor_admin_port_key &= ~AD_DUPLEX_KEY_MASKS;
> port->actor_oper_port_key = port->actor_admin_port_key |=
> __get_duplex(port);
> - netdev_dbg(slave->bond->dev, "Port %d changed duplex\n", port->actor_port_number);
> + netdev_dbg(slave->bond->dev, "Port %d slave %s changed duplex\n",
> + port->actor_port_number, slave->dev->name);
The above 2 changes seem unrelated/undocumented in the change log...
[...]
WBR, Sergei
^ permalink raw reply
* Re: [net-next PATCH v3 00/12] Flow API
From: Jamal Hadi Salim @ 2015-01-26 12:26 UTC (permalink / raw)
To: Simon Horman
Cc: John Fastabend, Thomas Graf, Jiri Pirko, Pablo Neira Ayuso,
sfeldma, netdev, davem, gerlitz.or, andy, ast
In-Reply-To: <20150126082602.GB8408@vergenet.net>
On 01/26/15 03:26, Simon Horman wrote:
> On Sat, Jan 24, 2015 at 08:01:52AM -0500, Jamal Hadi Salim wrote:
>
> [snip]
>
>> Lets discuss at the meeting. I am just skimming these emails (the
>> conference is chewing a lot of my time so i will mostly be absent).
>> Sorry if i am not responding to some things.
>
> Is "the meeting" the Hardware Offloading BoF at Netdev 1.0?
> For the benefit of others: https://www.netdev01.org/sessions/10
>
Yes, that is the plan. Sorry - the statement was addressed at the usual
suspects who probably understood the context.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net] net: sctp: fix slab corruption from use after free on INIT collisions
From: Neil Horman @ 2015-01-26 12:33 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, vyasevich, netdev, linux-sctp
In-Reply-To: <1421947614-31407-1-git-send-email-dborkman@redhat.com>
On Thu, Jan 22, 2015 at 06:26:54PM +0100, Daniel Borkmann wrote:
> When hitting an INIT collision case during the 4WHS with AUTH enabled, as
> already described in detail in commit 1be9a950c646 ("net: sctp: inherit
> auth_capable on INIT collisions"), it can happen that we occasionally
> still remotely trigger the following panic on server side which seems to
> have been uncovered after the fix from commit 1be9a950c646 ...
>
> [ 533.876389] BUG: unable to handle kernel paging request at 00000000ffffffff
> [ 533.913657] IP: [<ffffffff811ac385>] __kmalloc+0x95/0x230
> [ 533.940559] PGD 5030f2067 PUD 0
> [ 533.957104] Oops: 0000 [#1] SMP
> [ 533.974283] Modules linked in: sctp mlx4_en [...]
> [ 534.939704] Call Trace:
> [ 534.951833] [<ffffffff81294e30>] ? crypto_init_shash_ops+0x60/0xf0
> [ 534.984213] [<ffffffff81294e30>] crypto_init_shash_ops+0x60/0xf0
> [ 535.015025] [<ffffffff8128c8ed>] __crypto_alloc_tfm+0x6d/0x170
> [ 535.045661] [<ffffffff8128d12c>] crypto_alloc_base+0x4c/0xb0
> [ 535.074593] [<ffffffff8160bd42>] ? _raw_spin_lock_bh+0x12/0x50
> [ 535.105239] [<ffffffffa0418c11>] sctp_inet_listen+0x161/0x1e0 [sctp]
> [ 535.138606] [<ffffffff814e43bd>] SyS_listen+0x9d/0xb0
> [ 535.166848] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b
>
> ... or depending on the the application, for example this one:
>
> [ 1370.026490] BUG: unable to handle kernel paging request at 00000000ffffffff
> [ 1370.026506] IP: [<ffffffff811ab455>] kmem_cache_alloc+0x75/0x1d0
> [ 1370.054568] PGD 633c94067 PUD 0
> [ 1370.070446] Oops: 0000 [#1] SMP
> [ 1370.085010] Modules linked in: sctp kvm_amd kvm [...]
> [ 1370.963431] Call Trace:
> [ 1370.974632] [<ffffffff8120f7cf>] ? SyS_epoll_ctl+0x53f/0x960
> [ 1371.000863] [<ffffffff8120f7cf>] SyS_epoll_ctl+0x53f/0x960
> [ 1371.027154] [<ffffffff812100d3>] ? anon_inode_getfile+0xd3/0x170
> [ 1371.054679] [<ffffffff811e3d67>] ? __alloc_fd+0xa7/0x130
> [ 1371.080183] [<ffffffff816149a9>] system_call_fastpath+0x16/0x1b
>
> With slab debugging enabled, we can see that the poison has been overwritten:
>
> [ 669.826368] BUG kmalloc-128 (Tainted: G W ): Poison overwritten
> [ 669.826385] INFO: 0xffff880228b32e50-0xffff880228b32e50. First byte 0x6a instead of 0x6b
> [ 669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 cpu=0 pid=18494
> [ 669.826424] __slab_alloc+0x4bf/0x566
> [ 669.826433] __kmalloc+0x280/0x310
> [ 669.826453] sctp_auth_create_key+0x23/0x50 [sctp]
> [ 669.826471] sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp]
> [ 669.826488] sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp]
> [ 669.826505] sctp_do_sm+0x29d/0x17c0 [sctp] [...]
> [ 669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494
> [ 669.826635] __slab_free+0x39/0x2a8
> [ 669.826643] kfree+0x1d6/0x230
> [ 669.826650] kzfree+0x31/0x40
> [ 669.826666] sctp_auth_key_put+0x19/0x20 [sctp]
> [ 669.826681] sctp_assoc_update+0x1ee/0x2d0 [sctp]
> [ 669.826695] sctp_do_sm+0x674/0x17c0 [sctp]
>
> Since this only triggers in some collision-cases with AUTH, the problem at
> heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice
> when having refcnt 1, once directly in sctp_assoc_update() and yet again
> from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on
> the already kzfree'd memory, which is also consistent with the observation
> of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected
> at a later point in time when poison is checked on new allocation).
>
> Reference counting of auth keys revisited:
>
> Shared keys for AUTH chunks are being stored in endpoints and associations
> in endpoint_shared_keys list. On endpoint creation, a null key is being
> added; on association creation, all endpoint shared keys are being cached
> and thus cloned over to the association. struct sctp_shared_key only holds
> a pointer to the actual key bytes, that is, struct sctp_auth_bytes which
> keeps track of users internally through refcounting. Naturally, on assoc
> or enpoint destruction, sctp_shared_key are being destroyed directly and
> the reference on sctp_auth_bytes dropped.
>
> User space can add keys to either list via setsockopt(2) through struct
> sctp_authkey and by passing that to sctp_auth_set_key() which replaces or
> adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes
> with refcount 1 and in case of replacement drops the reference on the old
> sctp_auth_bytes. A key can be set active from user space through setsockopt()
> on the id via sctp_auth_set_active_key(), which iterates through either
> endpoint_shared_keys and in case of an assoc, invokes (one of various places)
> sctp_auth_asoc_init_active_key().
>
> sctp_auth_asoc_init_active_key() computes the actual secret from local's
> and peer's random, hmac and shared key parameters and returns a new key
> directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops
> the reference if there was a previous one. The secret, which where we
> eventually double drop the ref comes from sctp_auth_asoc_set_secret() with
> intitial refcount of 1, which also stays unchanged eventually in
> sctp_assoc_update(). This key is later being used for crypto layer to
> set the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac().
>
> To close the loop: asoc->asoc_shared_key is freshly allocated secret
> material and independant of the sctp_shared_key management keeping track
> of only shared keys in endpoints and assocs. Hence, also commit 4184b2a79a76
> ("net: sctp: fix memory leak in auth key management") is independant of
> this bug here since it concerns a different layer (though same structures
> being used eventually). asoc->asoc_shared_key is reference dropped correctly
> on assoc destruction in sctp_association_free() and when active keys are
> being replaced in sctp_auth_asoc_init_active_key(), it always has a refcount
> of 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is
> to remove that sctp_auth_key_put() from there which fixes these panics.
>
> Fixes: 730fc3d05cd4 ("[SCTP]: Implete SCTP-AUTH parameter processing")
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
> net/sctp/associola.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index f791edd..26d06db 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -1182,7 +1182,6 @@ void sctp_assoc_update(struct sctp_association *asoc,
> asoc->peer.peer_hmacs = new->peer.peer_hmacs;
> new->peer.peer_hmacs = NULL;
>
> - sctp_auth_key_put(asoc->asoc_shared_key);
> sctp_auth_asoc_init_active_key(asoc, GFP_ATOMIC);
> }
>
> --
> 1.7.11.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Altera TSE (altera_tse) net_rx_action WARNING - polling bug in altera_tse_main.c?
From: Vlastimil Šetka @ 2015-01-26 12:39 UTC (permalink / raw)
To: vbridger, netdev
Hello,
I am using Altera TSE kernel driver (altera_tse module) on Altera
socfpga platform (Cyclone V SoC with ARM Cortex-A9) and I probably
discovered a bug in it. I have two TSE controllers instantiated in FPGA
- my FPGA HW design is based on this tutorial:
http://www.rocketboards.org/foswiki/Projects/AlteraSoCTripleSpeedEthernetDesignExample
The kernel version is 3.10.37-ltsi with RT patch, from
http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=commit;h=7ea94617cfae6a62ee963adc1ae340196dbe2b34
with backported some altera_tse fixes from current 3.19-rc5.
I was not able to get TSE ethernets working on vanilla 3.19-rc5,
probably because of some changes around interrupts and devicetree, but
it's another story.
After some time (minutes to hours) of exhaustive traffic generated by
iperf through altera_tse ethernet, I can see a kernel warning on console
like this:
------------[ cut here ]------------
WARNING: at net/core/dev.c:4255 net_rx_action+0x268/0x28c()
Modules linked in: gpio_altera altera_sysid altera_tse
CPU: 0 PID: 5885 Comm: irq/75-eth2 Not tainted
3.10.37-ltsi-rt37-vs-2-1-00062-g861955e #1
[<800166c4>] (unwind_backtrace+0x0/0x100) from [<80012edc>]
(show_stack+0x20/0x24)
[<80012edc>] (show_stack+0x20/0x24) from [<80503404>] (dump_stack+0x24/0x28)
[<80503404>] (dump_stack+0x24/0x28) from [<8002303c>]
(warn_slowpath_common+0x64/0x7c)
[<8002303c>] (warn_slowpath_common+0x64/0x7c) from [<80023110>]
(warn_slowpath_null+0x2c/0x34)
[<80023110>] (warn_slowpath_null+0x2c/0x34) from [<80404d48>]
(net_rx_action+0x268/0x28c)
[<80404d48>] (net_rx_action+0x268/0x28c) from [<8002bd18>]
(do_current_softirqs+0x1e4/0x388)
[<8002bd18>] (do_current_softirqs+0x1e4/0x388) from [<8002bf34>]
(local_bh_enable+0x78/0x90)
[<8002bf34>] (local_bh_enable+0x78/0x90) from [<80086c9c>]
(irq_forced_thread_fn+0x50/0x74)
[<80086c9c>] (irq_forced_thread_fn+0x50/0x74) from [<80086fbc>]
(irq_thread+0x16c/0x1c8)
[<80086fbc>] (irq_thread+0x16c/0x1c8) from [<80048104>] (kthread+0xb4/0xb8)
[<80048104>] (kthread+0xb4/0xb8) from [<8000e718>] (ret_from_fork+0x14/0x20)
---[ end trace 0000000000000002 ]---
The warning point is:
WARN_ON_ONCE(work > weight);
at
http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=blob;f=net/core/dev.c;h=2193b5dc276ad6aa54adb1ee15ef3de625915fcd;hb=7ea94617cfae6a62ee963adc1ae340196dbe2b34#l4255
After a warning, interface is still working without problems.
I am not much familiar with Linux network stack and device drivers. But
I probably found a root cause in:
# drivers/net/ethernet/altera/altera_tse_main.c.
#
http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=blob;f=drivers/net/ethernet/altera/altera_tse_main.c;h=07c0b193c55722d18ff2723f0a7e137671746ba1;hb=7ea94617cfae6a62ee963adc1ae340196dbe2b34#l368
static int tse_rx(struct altera_tse_private *priv, int limit)
the `limit` parameter is not used anywhere in the function! When
`tse_rx` is called from `tse_poll` it can return more frames than limit,
which in the end triggers the kernel warning as I think:
# drivers/net/ethernet/altera/altera_tse_main.c
#
http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=blob;f=drivers/net/ethernet/altera/altera_tse_main.c;h=07c0b193c55722d18ff2723f0a7e137671746ba1;hb=7ea94617cfae6a62ee963adc1ae340196dbe2b34#l488
static int tse_poll(struct napi_struct *napi, int budget)
{
...
txcomplete = tse_tx_complete(priv);
rxcomplete = tse_rx(priv, budget);
if (rxcomplete >= budget || txcomplete > 0)
return rxcomplete;
Condition `if (rxcomplete >= budget || txcomplete > 0) return
rxcomplete;` is also very weird for me. I am not sure if it's buggy, but
I think it should be at least commented how it works.
Vlastimil Setka
^ permalink raw reply
* Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Sun Paul @ 2015-01-26 13:17 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Daniel Borkmann, Michael Tuexen, Vlad Yasevich, linux-sctp,
netdev, linux-kernel
In-Reply-To: <54C62912.3040401@gmail.com>
When an ABORT is sent to side-A, side-A INIT a new connection again.
On Mon, Jan 26, 2015 at 7:46 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> Hi,
>
> On 25-01-2015 23:27, Sun Paul wrote:
>>
>> Hi
>>
>> sorry for the late reply. I am a bit confused. when side-A sends a
>> request to side-B, and side-B return the response, but side-A keep
>> re-transmit the same request to side-B, why side-B needed to send a
>> ABORT to side-A?
>
>
> That happens on data transfers. When A pushes data to B, A has to retry it
> until B finally acknowledges it and A receive this signal. If the ack from B
> gets dropped, A has no way to know if a) the ack was lost or b) its initial
> message never actually made it to A, thus it retransmits. If it reaches a
> limit, it gives up..
>
>> If it is used in order to reestablish the connection, shoudn't it
>> should be side-A to send ABORT instead?
>
>
> Meant to reestablish it? Not really.. just to keep both sides in sync, as A
> has given up by then.
>
> Marcelo
>
>> - PS
>>
>> On Sat, Jan 24, 2015 at 3:05 AM, Daniel Borkmann <dborkman@redhat.com>
>> wrote:
>>>
>>> On 01/23/2015 07:36 PM, Michael Tuexen wrote:
>>> ...
>>>>
>>>>
>>>> Yepp. It might not reach the peer or it might. If it does it helps
>>>> to keep the states in sync. If it doesn't it sometimes helps in
>>>> analysing tracefiles. In BSD, we also send it. It is not required,
>>>> doesn't harm and is useful in some cases...
>>>
>>>
>>>
>>> Ok, as the TCB is destroyed in any case, should be fine then.
>>>
>>> Thanks,
>>> Daniel
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Daniel Borkmann @ 2015-01-26 13:30 UTC (permalink / raw)
To: Sun Paul
Cc: Marcelo Ricardo Leitner, Michael Tuexen, Vlad Yasevich,
linux-sctp, netdev, linux-kernel
In-Reply-To: <CAFXGftJNZ48Qe4DLgf5TPBvNCnUH8wxon9+b3_i_GWVYqnphhg@mail.gmail.com>
On 01/26/2015 02:17 PM, Sun Paul wrote:
> When an ABORT is sent to side-A, side-A INIT a new connection again.
Even if the ABORT is not being sent, the peer (the one who would send
his ABORT) closes the TCB from his side silently then. Any messages that
would afterwards arrive on this dead connection would be answered with
an oob ABORT just as well. I'm still missing the bigger picture on your
use-case scenario here, I guess ... why is the recommended rtx limit not
sufficient?
^ permalink raw reply
* Fw: [Bug 91471] New: add and removing macvlan link caused this dump trace
From: Stephen Hemminger @ 2015-01-26 13:32 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Fri, 16 Jan 2015 19:16:28 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 91471] New: add and removing macvlan link caused this dump trace
https://bugzilla.kernel.org/show_bug.cgi?id=91471
Bug ID: 91471
Summary: add and removing macvlan link caused this dump trace
Product: Networking
Version: 2.5
Kernel Version: 3.13.0-32-generic
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: ray.qiu@gmail.com
Regression: No
It can be consistently reproduced.
- Bring up a docker container
- Create an ip link with type macvlan
- Move it to another netns for a container
- Bring it up and assign ip address
- Then, remove the link from the container and terminate the container.
- Repeat the process again will cause this crash dump.
------------[ cut here ]------------
[ 2307.593973] kernel BUG at /build/buildd/linux-3.13.0/net/core/dev.c:6437!
[ 2307.594461] invalid opcode: 0000 [#1] SMP
[ 2307.594883] Modules linked in: veth macvlan openvswitch gre vxlan ip_tunnel
libcrc32c xt_addrtype xt_conntrack ipt_MASQUERADE iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bridge stp llc aufs
iptable_filter ip_tables x_tables hid_generic ppdev coretemp kvm_intel kvm
crct10dif_pclmul crc32_pclmul btusb ghash_clmulni_intel bluetooth vmw_balloon
aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd snd_ens1371
serio_raw snd_ac97_codec ac97_bus gameport snd_rawmidi snd_seq_device snd_pcm
usbhid hid snd_page_alloc snd_timer snd soundcore vmwgfx ttm shpchp drm
i2c_piix4 vmw_vmci parport_pc mac_hid lp parport psmouse ahci libahci e1000
mptspi mptscsih floppy mptbase vmw_pvscsi vmxnet3
[ 2307.598952] CPU: 0 PID: 6778 Comm: ip Tainted: G W
3.13.0-32-generic #57-Ubuntu
[ 2307.599433] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 2307.600419] task: ffff8801353d5fc0 ti: ffff8801352f2000 task.ti:
ffff8801352f2000
[ 2307.600955] RIP: 0010:[<ffffffff8162447f>] [<ffffffff8162447f>]
free_netdev+0xff/0x110
[ 2307.601475] RSP: 0018:ffff8801352f38d8 EFLAGS: 00010293
[ 2307.602000] RAX: 0000000000000001 RBX: ffff8800b6bdb018 RCX:
0000000000000254
[ 2307.602498] RDX: 0000000000000001 RSI: 0000000000000282 RDI:
0000000000000282
[ 2307.602988] RBP: ffff8801352f38f0 R08: 00018608fffffee0 R09:
ffffff90ffffffb0
[ 2307.603477] R10: ffffff90ffffffb0 R11: 00001398ffffffd0 R12:
ffff8800b6bdb060
[ 2307.603967] R13: ffff8800b6bdb000 R14: ffff8801352f3900 R15:
ffffffffa0485000
[ 2307.604455] FS: 00007f0e72cff740(0000) GS:ffff880138400000(0000)
knlGS:0000000000000000
[ 2307.604947] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2307.605433] CR2: 00007fff9b91fe60 CR3: 0000000134b11000 CR4:
00000000001407f0
[ 2307.606043] Stack:
[ 2307.606578] 00000000ffffffef ffffffff81cda240 ffff8801352f3920
ffff8801352f3ae8
[ 2307.607259] ffffffff81632848 0000000000000000 ffff8800ba35c648
0000000000000000
[ 2307.607815] ffffffff8163240e ffffffff81cda240 ffff8800ba35c610
ffff8800b6bdb000
[ 2307.608444] Call Trace:
[ 2307.608982] [<ffffffff81632848>] rtnl_newlink+0x578/0x5d0
[ 2307.609809] [<ffffffff8163240e>] ? rtnl_newlink+0x13e/0x5d0
[ 2307.610858] [<ffffffff8162f0b9>] rtnetlink_rcv_msg+0x99/0x260
[ 2307.611868] [<ffffffff81610e7e>] ? __alloc_skb+0x7e/0x2b0
[ 2307.612922] [<ffffffff8162f020>] ? rtnetlink_rcv+0x30/0x30
[ 2307.613920] [<ffffffff8164d659>] netlink_rcv_skb+0xa9/0xc0
[ 2307.614987] [<ffffffff8162f018>] rtnetlink_rcv+0x28/0x30
[ 2307.615974] [<ffffffff8164cc85>] netlink_unicast+0xd5/0x1b0
[ 2307.616948] [<ffffffff8164d05f>] netlink_sendmsg+0x2ff/0x740
[ 2307.617957] [<ffffffff816079eb>] sock_sendmsg+0x8b/0xc0
[ 2307.619037] [<ffffffff811b1356>] ? __mem_cgroup_commit_charge+0x156/0x3d0
[ 2307.620042] [<ffffffff816076de>] ? move_addr_to_kernel.part.16+0x1e/0x60
[ 2307.620963] [<ffffffff816082a1>] ? move_addr_to_kernel+0x21/0x30
[ 2307.621874] [<ffffffff81608273>] ___sys_sendmsg+0x3c3/0x3d0
[ 2307.622691] [<ffffffff81727c64>] ? __do_page_fault+0x204/0x560
[ 2307.623572] [<ffffffff8111155c>] ? acct_account_cputime+0x1c/0x20
[ 2307.624061] [<ffffffff8109d7db>] ? account_user_time+0x8b/0xa0
[ 2307.624472] [<ffffffff81608972>] __sys_sendmsg+0x42/0x80
[ 2307.624864] [<ffffffff816089c2>] SyS_sendmsg+0x12/0x20
[ 2307.625265] [<ffffffff8172c87f>] tracesys+0xe1/0xe6
[ 2307.625628] Code: a7 e6 ff 5b 41 5c 41 5d 5d c3 66 90 e8 2b 3a b6 ff e9 53
ff ff ff 66 0f 1f 44 00 00 4c 89 ef e8 b8 fe ff ff 5b 41 5c 41 5d 5d c3 <0f> 0b
66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
[ 2307.626779] RIP [<ffffffff8162447f>] free_netdev+0xff/0x110
[ 2307.627392] RSP <ffff8801352f38d8>
[ 2307.629586] ---[ end trace 9c2a19ae6ba1d1f6 ]---
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Fw: [Bug 91491] New: trie_leaf_remove
From: Stephen Hemminger @ 2015-01-26 13:32 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sat, 17 Jan 2015 13:30:29 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 91491] New: trie_leaf_remove
https://bugzilla.kernel.org/show_bug.cgi?id=91491
Bug ID: 91491
Summary: trie_leaf_remove
Product: Networking
Version: 2.5
Kernel Version: 3.14-2-amd64 #1 Debian 3.14.15-2.1khz
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: blocking
Priority: P1
Component: IPV4
Assignee: shemminger@linux-foundation.org
Reporter: komur@bilkent.edu.tr
Regression: No
[690122.777855] BUG: unable to handle kernel paging request at ffff88b40504020c
[690122.777870] IP: [<ffffffff81454e7f>] trie_leaf_remove+0x1f/0xa0
[690122.777881] PGD 0
[690122.777886] Oops: 0000 [#1] SMP
[690122.777893] Modules linked in: bonding loop xt_CLASSIFY xt_TCPMSS
iptable_mangle xt_u32 ipt_REJECT xt_tcpudp xt_recent iptable_filter ip_tables
x_tables x86_pkg_temp_thermal intel_powerclamp intel_rapl coretemp kvm_intel
snd_hda_codec_hdmi kvm crc32_pclmul crc32c_intel snd_hda_intel snd_hda_codec
snd_hwdep ghash_clmulni_intel snd_pcm snd_timer aesni_intel snd aes_x86_64
soundcore lrw joydev gf128mul iTCO_wdt glue_helper iTCO_vendor_support
ablk_helper cryptd evdev mxm_wmi psmouse sb_edac pcspkr serio_raw edac_core
tpm_tis i2c_i801 tpm nuvoton_cir rc_core wmi button mei_me lpc_ich mei shpchp
mfd_core processor thermal_sys hid_generic usbhid hid ext4 crc16 mbcache jbd2
sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common ahci
libahci libata ehci_pci igb xhci_hcd scsi_mod i2c_algo_bit
[690122.778005] ehci_hcd i2c_core dca usbcore ptp pps_core usb_common
[690122.778005] CPU: 6 PID: 1557 Comm: zebra Not tainted 3.14-2-amd64 #1 Debian
3.14.15-2.1khz
[690122.778005] Hardware name: /DX79SI, BIOS
SIX7910J.86A.0525.2012.0709.1221 07/09/2012
[690122.778005] task: ffff880224960390 ti: ffff880225464000 task.ti:
ffff880225464000
[690122.778005] RIP: 0010:[<ffffffff81454e7f>] [<ffffffff81454e7f>]
trie_leaf_remove+0x1f/0xa0
[690122.778005] RSP: 0018:ffff880225465a58 EFLAGS: 00010286
[690122.778005] RAX: 0000000000000000 RBX: ffff88b405040200 RCX:
ffff8800baa153e8
[690122.778005] RDX: ffffffff818412c0 RSI: ffff8800baa153e8 RDI:
ffff88022505ab60
[690122.778005] RBP: ffff8800baa153e8 R08: 0000000000000000 R09:
0000000000000001
[690122.778005] R10: 0000000000000400 R11: ffff8800c9ebbc80 R12:
ffff88022505ab60
[690122.778005] R13: ffff88022505ab40 R14: ffff8800c9607998 R15:
ffff8800c2c39cd8
[690122.778005] FS: 00007fd6e82c8700(0000) GS:ffff88022fcc0000(0000)
knlGS:0000000000000000
[690122.778005] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[690122.778005] CR2: ffff88b40504020c CR3: 00000002228c1000 CR4:
00000000000407e0
[690122.778005] Stack:
[690122.778005] ffff8800c9607980 ffff880225465ad8 0000000000000018
ffffffff81455a70
[690122.778005] ffffffff00000000 ffff8800baa153e8 0000000000000000
ffff88022505ab60
[690122.778005] ffff8800c9607980 ffffffff81889180 ffff8800ca0b5bc0
0000000000000009
[690122.778005] Call Trace:
[690122.778005] [<ffffffff81455a70>] ? fib_table_delete+0x280/0x2d0
[690122.778005] [<ffffffff8144f75e>] ? inet_rtm_delroute+0x3e/0x50
[690122.778005] [<ffffffff813ed7ba>] ? rtnetlink_rcv_msg+0x8a/0x250
[690122.778005] [<ffffffff813d01e3>] ? __alloc_skb+0x43/0x2a0
[690122.778005] [<ffffffff813ed730>] ? rtnetlink_rcv+0x30/0x30
[690122.778005] [<ffffffff8140b5c9>] ? netlink_rcv_skb+0xa9/0xc0
[690122.778005] [<ffffffff813ed71f>] ? rtnetlink_rcv+0x1f/0x30
[690122.778005] [<ffffffff8140abc8>] ? netlink_unicast+0xe8/0x1f0
[690122.778005] [<ffffffff8140afec>] ? netlink_sendmsg+0x31c/0x740
[690122.778005] [<ffffffff813c7c96>] ? sock_sendmsg+0x86/0xc0
[690122.778005] [<ffffffff8119ab20>] ? poll_select_copy_remaining+0x130/0x130
[690122.778005] [<ffffffff813c7a24>] ? move_addr_to_kernel.part.18+0x14/0x60
[690122.778005] [<ffffffff813c83e3>] ? ___sys_sendmsg+0x373/0x380
[690122.778005] [<ffffffff8108871f>] ? update_rq_clock.part.85+0xf/0x30
[690122.778005] [<ffffffff8108e294>] ? task_sched_runtime+0x54/0xa0
[690122.778005] [<ffffffff8109273d>] ? cputime_adjust+0x1d/0x120
[690122.778005] [<ffffffff81092da5>] ? thread_group_cputime_adjusted+0x35/0x40
[690122.778005] [<ffffffff8105d329>] ? mmput+0x9/0x120
[690122.778005] [<ffffffff813c8a59>] ? __sys_sendmsg+0x39/0x70
[690122.778005] [<ffffffff814d30bd>] ? system_call_fast_compare_end+0x10/0x15
[690122.778005] Code: 00 45 31 ff eb c2 0f 0b 0f 1f 40 00 41 54 49 89 fc 55 48
89 f5 53 48 8b 1e 48 83 e3 fe f6 05 02 93 45 00 04 75 60 48 85 db 74 51 <0f> b6
4b 0c 31 f6 0f b6 43 0d 8b 55 08 80 f9 1f 77 0d d3 e2 b9
[690122.778005] RIP [<ffffffff81454e7f>] trie_leaf_remove+0x1f/0xa0
[690122.778005] RSP <ffff880225465a58>
[690122.778005] CR2: ffff88b40504020c
[690122.778005] ---[ end trace 5b32f2333bf1a5eb ]---
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* NetDev 0.1 conference post-CFP deadline weekly update
From: Richard Guy Briggs @ 2015-01-26 13:35 UTC (permalink / raw)
To: netdev, linux-wireless, lwn, netdev01, lartc, netfilter,
netfilter-devel
Cc: info, speakers, attendees
Fellow netheads:
New Sponsors (All listed at: https://www.netdev01.org/sponsors)
=============
We are pleased to announce a sixth sponsor:
CENGN http://www.cengn.ca/
Hotel earlybird special rates have expired as of this past Friday.
There are lots of big and small hotels in Ottawa, but they will fill up
fast as Winterlude approaches, so book something soon. There may be
some possibilities to billet locally, but don't leave it last minute.
The call for proposal deadline was this past Saturday, so expect a
schedule to be published this week.
Here is the post-CFP deadline update of the activity so far in NetDev
0.1 you may have missed if you aren't following the RSS feed or twitter:
Confirmed keynote speaker:
==========================
David S. Miller - The Current State of Linux kernel Networking.
Accepted talks: (All listed: https://www.netdev01.org/sessions )
==========================
The case for eliminating inconsistencies between Linux kernel IPv4/IPv6 API
https://www.netdev01.org/sessions/25
Roopa Prabhu
Networking in Containers and Container Clusters
https://www.netdev01.org/sessions/27
Victor Marmol
ipvlan
https://www.netdev01.org/sessions/28
Mahesh Bandewar
BIRD Internet Routing Daemon
https://www.netdev01.org/sessions/29
Ondrej Zajicek
Cooperative networking virtualization for the industrial server applications
https://www.netdev01.org/news/46
Vasiliy Tolstoy, Sergey Kovalev
Accepted Tutorials (All listed: https://www.netdev01.org/sessions )
===================
Hardware Accelerating Linux Network Functions
https://www.netdev01.org/sessions/24
Roopa Prabhu, Toshiaki Makita
nftables tutorial
https://www.netdev01.org/sessions/30
Pablo Neira Ayuso, Patrick McHardy
Accepted BoFs:
===================
Netfilter BoF
https://www.netdev01.org/sessions/26
Pete Bohmann, David Gervais, Josh Hunt
All of the accepted proposals are new work. A couple of proposals have been
returned for rework prior to acceptance. There are a few proposals
currently making their way through the technical committee vetting
process. The committee has so far been very impressed with the quality
of proposals submitted.
More coming in future updates.
If you've gotten this far reading - please go and register.
Registration https://onlineregistrations.ca/netdev01/
$100/day, or $350 for 4 days (Cdn dollars, reel cheep at the moment).
(online reg closes Feb 12th). Again:
Registering earlier rather than later helps us plan properly for numbers
of attendees, ensuring venue sizes and supplies are appropriate without
wasting resources.
Sponsors:
=========
NetDev 0.1 would like to gratefully acknowledge all our sponsors:
https://netdev01.org/sponsors
CENGN http://www.cengn.ca/
Google https://www.google.ca
Qualcomm https://www.qualcomm.com/
Verizon http://www.verizon.com/
Cumulus Networks http://cumulusnetworks.com/
Mojatatu Networks http://mojatatu.com/
Important Dates:
==========================
December 2, 2014 Call for Papers opens
December 10, 2014 Registration opens
January 23, 2015 Hotel discount rates deadline
January 24, 2015 Call for sessions deadline
February 12, 2015 On-line registration closes
February 14-17, 2015 Conference days
-------------------------------------------------------------------------------
THE Technical Conference on Linux Networking, February 14-17, 2015, Ottawa, Canada
https://netdev01.org/
Contact: info@netdev01.info
Main site: https://www.netdev01.org/
Announcement: https://www.netdev01.org/announce
CFP: https://www.netdev01.org/cfp
Travel/hotel/weather/clothing: https://www.netdev01.org/travel
RSS feed: https://netdev01.org/atom
Follow us on Twitter: @netdev01 https://twitter.com/netdev01
^ permalink raw reply
* Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached
From: Neil Horman @ 2015-01-26 13:47 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Daniel Borkmann, Sun Paul, linux-sctp, netdev, linux-kernel,
tuexen
In-Reply-To: <54C2935F.2000105@gmail.com>
On Fri, Jan 23, 2015 at 01:30:55PM -0500, Vlad Yasevich wrote:
> On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
> > On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
> >> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
> >>> On 01/23/2015 11:25 AM, Sun Paul wrote:
> >>> ...
> >>>> I would like to check the behave in LKSCTP.
> >>>>
> >>>> we are running DIAMETER message over SCTP, and we have set the
> >>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
> >>>>
> >>>> We noticed that when remote peer have retry to send the same request
> >>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
> >>>> "association exceeded its max_retrans count".
> >>>>
> >>>> We would like to know whether this is the correct behavior? is there
> >>>> any other option that we can alter in order to avoid the ABORT chunk
> >>>> being sent?
> >>>
> >>> I don't recall the RFC saying to send an ABORT, but let me double
> >>> check in the mean time.
> >>
> >> The RFC is silent on the matter. The abort got added in 3.8 so
> >> it's been there for a while.
> >
> > I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
> > exceeded") added the behaviour.
> >
> >>> Hmm, untested, but could you try something like that?
> >>>
> >>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> >>> index fef2acd..5ce198d 100644
> >>> --- a/net/sctp/sm_sideeffect.c
> >>> +++ b/net/sctp/sm_sideeffect.c
> >>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
> >>> sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
> >>> SCTP_ULPEVENT(event));
> >>>
> >>> - if (asoc->overall_error_count >= asoc->max_retrans) {
> >>> + if (asoc->overall_error_count >= asoc->max_retrans &&
> >>> + error != SCTP_ERROR_NO_ERROR) {
> >>> abort = sctp_make_violation_max_retrans(asoc, chunk);
> >>> if (abort)
> >>> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> >>
> >> This would pretty much stop all ABORTs due to excessive rtx. Might
> >> as well take the code out :).
> >>
> >> I was a bit concerned about this ABORT when it went in.
> >
> > So effectively, if I understand the argument from the commit, the
> > assumption is that the ABORT would never reach the peer anyway, but
> > is a way for tcpdump users to see on the wire that rtx limit has
> > been exceeded and since there's not mentioned anything in the RFC
> > about this, it doesn't break it. Hm.
> >
>
> Additionally I seem to recall BSD sending this type of ABORT for pretty
> much the same reason.
>
> -vlad
>
IIRC, BSD is where this patch came from initially.
Neil
> > Sun Paul, what exactly broke in your scenario? Can you be more explicit?
> >
> > Thanks,
> > Daniel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH bluetooth-next] ieee802154: cc2520: Replace shift operations by BIT macro
From: Varka Bhadram @ 2015-01-26 14:04 UTC (permalink / raw)
To: Mohammad Jamal, alex.aring, linux-wpan, netdev, linux-kernel
In-Reply-To: <1422021509-18877-1-git-send-email-md.jamalmohiuddin@gmail.com>
Hi Jamal,
On Friday 23 January 2015 07:28 PM, Mohammad Jamal wrote:
> This patch replaces the shifting operations by BIT macro
Thanks for the patch.
Acked-by: Varka Bhadram <varkabhadram@gmail.com>
> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
> ---
> drivers/net/ieee802154/cc2520.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
> index 665a3db..181b349 100644
> --- a/drivers/net/ieee802154/cc2520.c
> +++ b/drivers/net/ieee802154/cc2520.c
> @@ -44,9 +44,9 @@
> #define CC2520_FREG_MASK 0x3F
>
> /* status byte values */
> -#define CC2520_STATUS_XOSC32M_STABLE (1 << 7)
> -#define CC2520_STATUS_RSSI_VALID (1 << 6)
> -#define CC2520_STATUS_TX_UNDERFLOW (1 << 3)
> +#define CC2520_STATUS_XOSC32M_STABLE BIT(7)
> +#define CC2520_STATUS_RSSI_VALID BIT(6)
> +#define CC2520_STATUS_TX_UNDERFLOW BIT(3)
>
> /* IEEE-802.15.4 defined constants (2.4 GHz logical channels) */
> #define CC2520_MINCHANNEL 11
--
Thanks and Regards,
Varka Bhadram.
^ permalink raw reply
* Re: [PATCH bluetooth-next] ieee802154: cc2520: Fix space before , coding style issue
From: Varka Bhadram @ 2015-01-26 14:05 UTC (permalink / raw)
To: Mohammad Jamal, alex.aring, linux-wpan, netdev, linux-kernel
In-Reply-To: <1422021327-18815-1-git-send-email-md.jamalmohiuddin@gmail.com>
Hi Jamal,
On Friday 23 January 2015 07:25 PM, Mohammad Jamal wrote:
> This patch removes the warnings (space before , ) shown by
> checkpatch.pl
Thanks for the patch.
Acked-by: Varka Bhadram <varkabhadram@gmail.com>
>
> Signed-off-by: Mohammad Jamal <md.jamalmohiuddin@gmail.com>
> ---
> drivers/net/ieee802154/cc2520.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
> index a43c8ac..665a3db 100644
> --- a/drivers/net/ieee802154/cc2520.c
> +++ b/drivers/net/ieee802154/cc2520.c
> @@ -549,14 +549,14 @@ cc2520_ed(struct ieee802154_hw *hw, u8 *level)
> u8 rssi;
> int ret;
>
> - ret = cc2520_read_register(priv , CC2520_RSSISTAT, &status);
> + ret = cc2520_read_register(priv, CC2520_RSSISTAT, &status);
> if (ret)
> return ret;
>
> if (status != RSSI_VALID)
> return -EINVAL;
>
> - ret = cc2520_read_register(priv , CC2520_RSSI, &rssi);
> + ret = cc2520_read_register(priv, CC2520_RSSI, &rssi);
> if (ret)
> return ret;
>
--
Thanks and Regards,
Varka Bhadram.
^ 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