* SMP Affinity and 3.12.7
From: Nieścierowicz Adam @ 2014-02-10 9:18 UTC (permalink / raw)
To: Netdev
Hi,
i use 3.12.7 kernel when i set smp_affinity for network device kernel
hangs.
SMP Affinity
---
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
CPU6 CPU7
67: 826 810 3962750 3962737 729 649
729 744 PCI-MSI-edge eth1
70: 4430 4476 4411 4431 4500 4466
3706636 3706649 PCI-MSI-edge eth4
--
My network device
---
05:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
Ethernet Controller (Copper) (rev 01)
05:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
Ethernet Controller (Copper) (rev 01)
0a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (Copper) (rev 06)
0a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (Copper) (rev 06)
0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (Copper) (rev 06)
0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (Copper) (rev 06)
---
Can anyone help?
---
Thanks,
Adam N.
^ permalink raw reply
* Re: [PATCH v3 1/2] ASoC: atmel_ssc_dai: make option to choose clock
From: Nicolas Ferre @ 2014-02-10 9:22 UTC (permalink / raw)
To: Bo Shen, broonie
Cc: plagnioj, linux-sound, alsa-devel, linux-arm-kernel,
Arnd Bergmann, Greg Kroah-Hartman, Chas Williams, Liam Girdwood,
Jaroslav Kysela, Takashi Iwai, Lars-Peter Clausen, linux-kernel,
linux-atm-general, netdev
In-Reply-To: <1392012586-30790-2-git-send-email-voice.shen@atmel.com>
On 10/02/2014 07:09, Bo Shen :
> When SSC works in slave mode, according to the hardware design, the
> clock can get from TK pin, also can get from RK pin. So, add one
> parameter to choose where the clock from.
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> Changes in v3:
> - New, move clk-from-rk-pin property from card to ssc device
>
> drivers/misc/atmel-ssc.c | 6 ++++++
> include/linux/atmel-ssc.h | 1 +
> sound/soc/atmel/atmel_ssc_dai.c | 13 +++++++++----
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index 5be80840..22de137 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -150,6 +150,12 @@ static int ssc_probe(struct platform_device *pdev)
> return -ENODEV;
> ssc->pdata = (struct atmel_ssc_platform_data *)plat_dat;
>
> + if (pdev->dev.of_node) {
> + struct device_node *np = pdev->dev.of_node;
> + ssc->clk_from_rk_pin =
> + of_property_read_bool(np, "atmel,clk-from-rk-pin");
> + }
> +
> regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> ssc->regs = devm_ioremap_resource(&pdev->dev, regs);
> if (IS_ERR(ssc->regs))
> diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
> index 66a0e53..571a12e 100644
> --- a/include/linux/atmel-ssc.h
> +++ b/include/linux/atmel-ssc.h
> @@ -18,6 +18,7 @@ struct ssc_device {
> struct clk *clk;
> int user;
> int irq;
> + bool clk_from_rk_pin;
> };
>
> struct ssc_device * __must_check ssc_request(unsigned int ssc_num);
> diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
> index 8697ced..ca1d8a3 100644
> --- a/sound/soc/atmel/atmel_ssc_dai.c
> +++ b/sound/soc/atmel/atmel_ssc_dai.c
> @@ -341,6 +341,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
> {
> int id = dai->id;
> struct atmel_ssc_info *ssc_p = &ssc_info[id];
> + struct ssc_device *ssc = ssc_p->ssc;
> struct atmel_pcm_dma_params *dma_params;
> int dir, channels, bits;
> u32 tfmr, rfmr, tcmr, rcmr;
> @@ -466,7 +467,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
> | SSC_BF(RCMR_START, start_event)
> | SSC_BF(RCMR_CKI, SSC_CKI_RISING)
> | SSC_BF(RCMR_CKO, SSC_CKO_NONE)
> - | SSC_BF(RCMR_CKS, SSC_CKS_CLOCK);
> + | SSC_BF(RCMR_CKS, ssc->clk_from_rk_pin ?
> + SSC_CKS_PIN : SSC_CKS_CLOCK);
>
> rfmr = SSC_BF(RFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
> | SSC_BF(RFMR_FSOS, SSC_FSOS_NONE)
> @@ -481,7 +483,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
> | SSC_BF(TCMR_START, start_event)
> | SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
> | SSC_BF(TCMR_CKO, SSC_CKO_NONE)
> - | SSC_BF(TCMR_CKS, SSC_CKS_PIN);
> + | SSC_BF(TCMR_CKS, ssc->clk_from_rk_pin ?
> + SSC_CKS_CLOCK : SSC_CKS_PIN);
>
> tfmr = SSC_BF(TFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
> | SSC_BF(TFMR_FSDEN, 0)
> @@ -550,7 +553,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
> | SSC_BF(RCMR_START, SSC_START_RISING_RF)
> | SSC_BF(RCMR_CKI, SSC_CKI_RISING)
> | SSC_BF(RCMR_CKO, SSC_CKO_NONE)
> - | SSC_BF(RCMR_CKS, SSC_CKS_PIN);
> + | SSC_BF(RCMR_CKS, ssc->clk_from_rk_pin ?
> + SSC_CKS_PIN : SSC_CKS_CLOCK);
>
> rfmr = SSC_BF(RFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
> | SSC_BF(RFMR_FSOS, SSC_FSOS_NONE)
> @@ -565,7 +569,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
> | SSC_BF(TCMR_START, SSC_START_RISING_RF)
> | SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
> | SSC_BF(TCMR_CKO, SSC_CKO_NONE)
> - | SSC_BF(TCMR_CKS, SSC_CKS_PIN);
> + | SSC_BF(RCMR_CKS, ssc->clk_from_rk_pin ?
> + SSC_CKS_CLOCK : SSC_CKS_PIN);
>
> tfmr = SSC_BF(TFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
> | SSC_BF(TFMR_FSDEN, 0)
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH iproute2 net-next-for-3.13 0/2] iproute2: display bonding slave info
From: Jiri Pirko @ 2014-02-10 9:49 UTC (permalink / raw)
To: Michal Kubecek; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20140210081136.66C22E5697@unicorn.suse.cz>
Already queued in patchwork:
http://patchwork.ozlabs.org/patch/313656/
http://patchwork.ozlabs.org/patch/313657/
Mon, Feb 10, 2014 at 09:11:36AM CET, mkubecek@suse.cz wrote:
>Since v3.14-rc1, kernel provides rtnetlink interface for read-only
>access to bonding slave parameters. Show this info in the output of
>"ip -d link show" command. The implementation is divided into generic
>part (add a callback to struct link_util and call it from
>print_linktype()) and bonding specific part (provide the callback in
>iplink_bond.c).
>
>Michal Kubecek (2):
> iplink: display slave information
> iplink_bond: add support for displaying bond slave attributes
>
> ip/ip_common.h | 3 +++
> ip/ipaddress.c | 27 +++++++++++++++++++++++--
> ip/iplink_bond.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
> 3 files changed, 85 insertions(+), 6 deletions(-)
>
>--
>1.8.1.4
>
>--
>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
* SCTP and MSG_MORE
From: David Laight @ 2014-02-10 10:11 UTC (permalink / raw)
To: netdev@vger.kernel.org
I hadn't realised that linux had a MSG_MORE exposed to userland...
The sctp stack could usefully use it to get multiple data chunks
into a single ethernet frame.
Currently it is very difficult to get more than one data chunk in
an ethernet frame which means that the ethernet packet rate is
much higher than it would be if the same traffic were sent using TCP.
I don't know enough about the SCTP code to even start looking for
where this might be implemented. It might be almost trivial...
David
^ permalink raw reply
* Re: [PATCH] net: rfkill-regulator: Add devicetree support.
From: Mark Rutland @ 2014-02-10 10:18 UTC (permalink / raw)
To: Marek Belisko
Cc: robh+dt@kernel.org, Pawel Moll, ijc+devicetree@hellion.org.uk,
galak@codeaurora.org, rob@landley.net, linville@tuxdriver.com,
johannes@sipsolutions.net, davem@davemloft.net,
grant.likely@linaro.org, neilb@suse.de, hns@goldelico.com,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <1391802529-29861-1-git-send-email-marek@goldelico.com>
On Fri, Feb 07, 2014 at 07:48:49PM +0000, Marek Belisko wrote:
> Signed-off-by: NeilBrown <neilb@suse.de>
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
> Based on Neil's patch and extend for documentation and bindings include.
>
> .../bindings/net/rfkill/rfkill-relugator.txt | 28 ++++++++++++++++
> include/dt-bindings/net/rfkill-regulator.h | 23 +++++++++++++
> net/rfkill/rfkill-regulator.c | 38 ++++++++++++++++++++++
> 3 files changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> create mode 100644 include/dt-bindings/net/rfkill-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> new file mode 100644
> index 0000000..cdb7dd7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> @@ -0,0 +1,28 @@
> +Regulator consumer for rfkill devices
What exactly is an "rfkill" device? How is it used? How does it relate
to other devices in the DT?
To me, this looks like a leak of a Linux abstraction.
> +
> +Required properties:
> +- compatible : Must be "rfkill-regulator".
> +- label : Name of rfkill device.
What's this for? Why does this need a label in the DT? Surely this can
be implied by the relationship to a particular radio device?
> +- type : Type of rfkill device.
> +
> +Possible values (defined in include/dt-bindings/net/rfkill-regulator.h):
> + RFKILL_TYPE_ALL
> + RFKILL_TYPE_WLAN
> + RFKILL_TYPE_BLUETOOTH
> + RFKILL_TYPE_UWB
> + RFKILL_TYPE_WIMAX
> + RFKILL_TYPE_WWAN
> + RFKILL_TYPE_GPS
> + RFKILL_TYPE_FM
> + RFKILL_TYPE_NFC
What do these mean? Why can these not be implied by a relationship to
any devices of these particular types?
> +
> +- vrfkill-supply - regulator device.
Why isn't this described on the radio revice node? It's a supply to the
radio, not to the rfkill concept.
> +
> +Example:
> + gps-rfkill {
> + compatible = "rfkill-regulator";
> + label = "GPS";
> + type = <RFKILL_TYPE_GPS>;
> + vrfkill-supply = <®>;
> + };
Why is this not bound to the particular GPS device in some way?
What if I have more than one of any of the types of device this
supports, which device is this expected to control?
Why is it described as a separate device in the device tree at all?
I do not think this binding is the right way to describe this.
Thanks,
Mark.
> +
> diff --git a/include/dt-bindings/net/rfkill-regulator.h b/include/dt-bindings/net/rfkill-regulator.h
> new file mode 100644
> index 0000000..ae32273
> --- /dev/null
> +++ b/include/dt-bindings/net/rfkill-regulator.h
> @@ -0,0 +1,23 @@
> +/*
> + * This header provides macros for rfkill-regulator bindings.
> + *
> + * Copyright (C) 2014 Marek Belisko <marek@goldelico.com>
> + *
> + * GPLv2 only
> + */
> +
> +#ifndef __DT_BINDINGS_RFKILL_REGULATOR_H__
> +#define __DT_BINDINGS_RFKILL_REGULATOR_H__
> +
> +
> +#define RFKILL_TYPE_ALL (0)
> +#define RFKILL_TYPE_WLAN (1)
> +#define RFKILL_TYPE_BLUETOOTH (2)
> +#define RFKILL_TYPE_UWB (3)
> +#define RFKILL_TYPE_WIMAX (4)
> +#define RFKILL_TYPE_WWAN (5)
> +#define RFKILL_TYPE_GPS (6)
> +#define RFKILL_TYPE_FM (7)
> +#define RFKILL_TYPE_NFC (8)
> +
> +#endif /* __DT_BINDINGS_RFKILL_REGULATOR_H__ */
> diff --git a/net/rfkill/rfkill-regulator.c b/net/rfkill/rfkill-regulator.c
> index cf5b145..a04aff8 100644
> --- a/net/rfkill/rfkill-regulator.c
> +++ b/net/rfkill/rfkill-regulator.c
> @@ -19,6 +19,7 @@
> #include <linux/regulator/consumer.h>
> #include <linux/rfkill.h>
> #include <linux/rfkill-regulator.h>
> +#include <linux/of_platform.h>
>
> struct rfkill_regulator_data {
> struct rfkill *rf_kill;
> @@ -57,6 +58,31 @@ static struct rfkill_ops rfkill_regulator_ops = {
> .set_block = rfkill_regulator_set_block,
> };
>
> +#ifdef CONFIG_OF
> +static struct rfkill_regulator_platform_data *
> +rfkill_regulator_parse_pdata(struct device *dev)
> +{
> + struct rfkill_regulator_platform_data *pdata;
> + struct device_node *np = dev->of_node;
> + u32 num;
> + if (!np)
> + return NULL;
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return NULL;
> + if (of_property_read_u32(np, "type", &num) == 0)
> + pdata->type = num;
> + of_property_read_string(np, "label", &pdata->name);
> + return pdata;
> +}
> +#else
> +static inline struct rfkill_regulator_platform_data *
> +rfkill_regulator_parse_pdata(struct device *dev)
> +{
> + return NULL;
> +}
> +#endif
> +
> static int rfkill_regulator_probe(struct platform_device *pdev)
> {
> struct rfkill_regulator_platform_data *pdata = pdev->dev.platform_data;
> @@ -65,6 +91,9 @@ static int rfkill_regulator_probe(struct platform_device *pdev)
> struct rfkill *rf_kill;
> int ret = 0;
>
> + if (!pdata)
> + pdata = rfkill_regulator_parse_pdata(&pdev->dev);
> +
> if (pdata == NULL) {
> dev_err(&pdev->dev, "no platform data\n");
> return -ENODEV;
> @@ -137,12 +166,21 @@ static int rfkill_regulator_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id rfkill_regulator_match[] = {
> + {.compatible = "rfkill-regulator"},
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, rfkill_regulator_match);
> +#endif
> +
> static struct platform_driver rfkill_regulator_driver = {
> .probe = rfkill_regulator_probe,
> .remove = rfkill_regulator_remove,
> .driver = {
> .name = "rfkill-regulator",
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(rfkill_regulator_match),
> },
> };
>
> --
> 1.8.3.2
>
>
^ permalink raw reply
* Re: [RFC PATCHv2 0/4] Add DT support for fixed PHYs
From: Christian Gmeiner @ 2014-02-10 10:30 UTC (permalink / raw)
To: Thomas Petazzoni, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA, Florian Fainelli, Lior Amsalem,
Gregory Clement, Ezequiel Garcia,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Mark Rutland, Christian Gmeiner
In-Reply-To: <CAH9NwWfBGHmZ+HfUndeh18NW+HyZ=c82W=O_4hJSOH-oZuM9jA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-09-25 9:12 GMT+02:00 Christian Gmeiner <christian.gmeiner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Hi
>
>>> Hello,
>>>
>>> Here is a second version of the patch set that adds a Device Tree
>>> binding and the related code to support fixed PHYs. Marked as RFC,
>>> this patch set is obviously not intended for merging in 3.12.
>>>
>>> Since the first version, the changes have been:
>>>
>>> * Instead of using a 'fixed-link' property inside the Ethernet device
>>> DT node, with a fairly cryptic succession of integer values, we now
>>> use a PHY subnode under the Ethernet device DT node, with explicit
>>> properties to configure the duplex, speed, pause and other PHY
>>> properties.
>>>
>>> * The PHY address is automatically allocated by the kernel and no
>>> longer visible in the Device Tree binding.
>>>
>>> * The PHY device is created directly when the network driver calls
>>> of_phy_connect_fixed_link(), and associated to the PHY DT node,
>>> which allows the existing of_phy_connect() function to work,
>>> without the need to use the deprecated of_phy_connect_fixed_link().
>>>
>>> The things I am not entirely happy with yet are:
>>>
>>> * The PHY ID is hardcoded to 0xdeadbeef. Ideally, it should be a
>>> properly reserved vendor/device identifier, but it isn't clear how
>>> to get one allocated for this purpose.
>>>
>>> * The fixed_phy_register() function in drivers/net/phy/fixed.c has
>>> some OF references. So ideally, I would have preferred to put this
>>> code in drivers/of/of_mdio.c, but to call get_phy_device(), we need
>>> a reference to the mii_bus structure that represents the fixed MDIO
>>> bus.
>>>
>>> * There is some error management missing in fixed_phy_register(), but
>>> it can certainly be added easily. This RFC is meant to sort out the
>>> general idea.
>>
>> +1 for the general idea. This really looks good now. I've not much more
>> to say. Maybe someone from the devicetree corner has a few words for the
>> binding?
>>
>
> I tested the whole series with an I.MX6D board with the FEC driver:
> fec 2188000.ethernet eth0: Freescale FEC PHY driver [Generic PHY]
> (mii_bus:phy_addr=fixed-0:00, irq=-1)
>
> For me binding looks nice and I hope to see this patch series in 3.13.
>
> Tested-by: Christian Gmeiner <christian.gmeiner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Is there any update on this patch series?
--
Christian Gmeiner, MSc
https://soundcloud.com/christian-gmeiner
--
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: [PATCH 1/2 v2] usbnet: fix bad header length bug
From: Emil Goode @ 2014-02-10 12:00 UTC (permalink / raw)
To: Oliver Neukum
Cc: David S. Miller, Ming Lei, Mark Brown, Jeff Kirsher, Glen Turner,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392014458.21271.6.camel-B2T3B9s34ElbnMAlSieJcQ@public.gmane.org>
On Mon, Feb 10, 2014 at 07:40:58AM +0100, Oliver Neukum wrote:
> On Mon, 2014-02-10 at 00:06 +0100, Emil Goode wrote:
> > The AX88772B occasionally send rx packets that cross urb boundaries
> > and the remaining partial packet is sent with no hardware header.
> > When the buffer with a partial packet is of less number of octets
> > than the value of hard_header_len the buffer is discarded by the
> > usbnet module. This is causing dropped packages and error messages
> > in dmesg.
> >
> > This can be reproduced by using ping with a packet size
> > between 1965-1976.
>
> Well, then how about simply removing the check?
> It seems to have outlived its usefulness.
>
> Regards
> Oliver
>
>
I did consider that and I think it is probably the best thing to do.
However, I think the removal of the check could have negative effects
on the other minidrivers, at least the qmi_wwan minidriver explicitly
states that it is depending on this check to be made in rx_complete().
For safety the check could be added at the top of the rx_fixup callback
of the affected minidrivers.
There are devices that depend on the usbnet module that do not have
a rx_fixup callback assigned to it's driver_info struct, the check
could be added for these in the rx_process function.
This led me to think it would be a lot of noise about a small check :)
My conclusion is that 12 rx_fixup callbacks might need the check
to be added. There are 18 driver_info structs with no rx_fixup
callback assigned, these devices might need the check to be added
to the rx_process function.
Patches could be sent out to notify the affected minidrivers of the
change and hopefully someone has the hardware to test if it's
necessary to add the check to the minidriver?
I'm happy to do this if it seem like a good idea.
Best regards,
Emil Goode
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [PATCH 09/28] Remove ATHEROS_AR231X
From: Sergey Ryazanov @ 2014-02-10 12:05 UTC (permalink / raw)
To: Richard Weinberger, Oleksij Rempel, Jonathan Bither,
OpenWrt Development List
Cc: Hauke Mehrtens, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
John W. Linville, open list:ATHEROS ATH5K WIR...,
open list:ATHEROS ATH5K WIR..., open,
list@hauke-m.de:NETWORKING DRIVERS, open list
In-Reply-To: <52F7DF21.70207@nod.at>
2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>:
> Am 09.02.2014 20:18, schrieb Hauke Mehrtens:
>> On 02/09/2014 07:47 PM, Richard Weinberger wrote:
>>> The symbol is an orphan, get rid of it.
>>>
>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>> ---
>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++-----
>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ----------------------------
>>> drivers/net/wireless/ath/ath5k/base.c | 14 --------------
>>> drivers/net/wireless/ath/ath5k/led.c | 7 -------
>>> 4 files changed, 5 insertions(+), 54 deletions(-)
>>>
>>
>> This code is used in OpenWrt with an out of tree arch code for the
>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding
>> this code to mainline Linux kernel, because of lack of time/interest.
>
> Sorry, we don't maintain out of tree code.
>
Oleksij, Jonathan do you still working to make ar231x devices work
with upstream, since your posts [1, 2]? Or may be someone from OpenWRT
team would like to add upstream support?
1. https://lkml.org/lkml/2013/5/13/321
2. https://lkml.org/lkml/2013/5/13/358
--
BR,
Sergey
^ permalink raw reply
* Re: [PATCH 0/2] sctp: fix a problem with net_namespace
From: Neil Horman @ 2014-02-10 12:08 UTC (permalink / raw)
To: Wang Weidong; +Cc: davem, vyasevich, dborkman, netdev
In-Reply-To: <52F83FF3.6010307@huawei.com>
On Mon, Feb 10, 2014 at 10:56:51AM +0800, Wang Weidong wrote:
> On 2014/1/28 19:57, Neil Horman wrote:
> > On Tue, Jan 28, 2014 at 04:13:44PM +0800, Wang Weidong wrote:
> >> On 2014/1/27 19:49, Neil Horman wrote:
> >>> On Mon, Jan 27, 2014 at 11:49:01AM +0800, Wang Weidong wrote:
> >>>> fix a problem with net_namespace, and optimize
> >>>> the sctp_sysctl_net_register.
> >>>>
> >>>> Wang Weidong (2):
> >>>> sctp: fix a missed .data initialization
> >>>> sctp: optimize the sctp_sysctl_net_register
> >>>>
> >>>> net/sctp/sysctl.c | 17 ++++++++++-------
> >>>> 1 file changed, 10 insertions(+), 7 deletions(-)
> >>>>
> >>>> --
> >>>> 1.7.12
> >>>>
> >>>>
> >>>>
> >>> I don't see that either of these patches are needed. In sctp_init_net, the
> >>> sctp_hmac_alg pointer gets initalized before calling sctp_sysctl_net_register,
> >>> and sctp_proc_do_hmac_alg is written to specifically expect NULL values, so this
> >>> code may change behavior regarding default cookie selection.
> >>>
> >> Hi Neil,
> >>
> >> Here, I think the sctp_proc_do_hmac_alg will be called only when we change the
> >> /proc/sys/net/cookie_hmac_alg. So add the .data won't effect the default value.
> >> and the data isn't equal to the "cookie_hmac_alg"?
> >>
> >>> This was coded so that poniters to entires in the string table could be used,
> >>> rather than needing to allocate or maintain character buffers. That said, it
> >>> does look like that for loop in sctp_sysctl_register_table might compute an odd
> >>> offset when cloning the table. I think the right fix for that is likely to just
> >>> move the sysctl value initalization in sctp_init_net to below the sysctl
> >>> register function.
> >>>
> >>> Neil
> >>>
> >>
> >> I found the problem is that:
> >> I use "ip netns add netns1/netns2"
> >> In any netns(netns1 or netns2 or init_net) when I change the value of the entry
> >> such as "addip_enable" "max_autoclose" which after the cookie_hmac_alg (contain it),
> >> and the other netns will be effected.
> >>
> >> In sctp_sysctl_net_register, kmemdup does cloning the table. The offset of netns1 and
> >> init_net's clt_table.data is the same as two netns offset. So the for(){...} would do
> >> add the offset for every clt_table.data.
> >>
> >> The code:
> >> for (i = 0; table[i].data; i++)
> >> table[i].data += (char *)(&net->sctp) - (char *)&init_net.sctp;
> >>
> >> And I add a pr_info into the for(){...} in sctp_sysctl_net_register and only print 7 times for each ns.
> >> 7 is the index of "cookie_preserve_enable" which before the "cookie_hmac_alg".
> >>
> >> As the "cookie_hmac_alg" data is NULL, so we can't add offset to the rest, and all the netns use the same
> >> address of clt_table entry after the "cookie_hmac_alg".
> >>
> >> So I think only "move the sysctl value initalization in sctp_init_net to below the sysctl
> >> register function" won't solve the problem, because the problem is at the for() {...}.
> >>
> > I'm sorry, you're right, the kmemdup duplicates the table, not the structure in
> > which the table points to with its .data pointers. I was looking at it
> > backwards.
> >
>
> Hi Neil,
>
> Should I resend "sctp: fix a problem with net_namespace" series again?
>
Not sure. I agree with your assesment on the table adjustments, but I think the
discussion below is holding things up. You probably want to get to the root
cause of whats causing the lockdep issue before that patch goes in
for 1/2 though
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [RFC PATCHv2 0/4] Add DT support for fixed PHYs
From: Thomas Petazzoni @ 2014-02-10 12:09 UTC (permalink / raw)
To: Christian Gmeiner
Cc: David S. Miller, netdev@vger.kernel.org, devicetree,
Florian Fainelli, Lior Amsalem, Gregory Clement, Ezequiel Garcia,
linux-arm-kernel@lists.infradead.org, Mark Rutland
In-Reply-To: <CAH9NwWfutp6MitSuG-LNH=0Y0ffewuSawLXJOe2JUL7=tz7BWQ@mail.gmail.com>
Dear Christian Gmeiner,
On Mon, 10 Feb 2014 11:30:30 +0100, Christian Gmeiner wrote:
> >> +1 for the general idea. This really looks good now. I've not much more
> >> to say. Maybe someone from the devicetree corner has a few words for the
> >> binding?
> >>
> >
> > I tested the whole series with an I.MX6D board with the FEC driver:
> > fec 2188000.ethernet eth0: Freescale FEC PHY driver [Generic PHY]
> > (mii_bus:phy_addr=fixed-0:00, irq=-1)
> >
> > For me binding looks nice and I hope to see this patch series in 3.13.
> >
> > Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com>
>
> Is there any update on this patch series?
I'll try to send a new version in the next few days. It's still part of
my TODO list.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/2] mm/vmalloc: export is_vmalloc_or_module_addr
From: Mel Gorman @ 2014-02-10 12:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Kleikamp, Richard Yao, Andrew Morton, Rik van Riel,
Eric Van Hensbergen, Ron Minnich, Latchesar Ionkov,
David S. Miller, V9FS Develooper Mailing List,
Linux Netdev Mailing List, Linux Kernel Mailing List,
Aneesh Kumar K.V, Will Deacon, Christopher Covington,
Matthew Thode
In-Reply-To: <CA+55aFx8TzOnW9xPFA4Ox-yFiSUo=cEqeQUmgw_JWjDNEZep8Q@mail.gmail.com>
On Sat, Feb 08, 2014 at 11:45:53AM -0800, Linus Torvalds wrote:
> On Sat, Feb 8, 2014 at 11:12 AM, Richard Yao <ryao@gentoo.org> wrote:
> > 9p-virtio needs is_vmalloc_or_module_addr exported before a patch can be
> > merged to prevent the virtio zero-copy routines from triggering a
> > hypervisor page fault when loading kernel modules:
> >
> > https://groups.google.com/forum/#!topic/linux.kernel/eRR7AyLE29Y
> >
> > Without this export, the kernel build breaks with that patch applied and
> > CONFIG_NET_9P_VIRTIO=m. With this export in place, all is well.
>
> I absolutely *detest* this patch.
>
> Not so much because is_vmalloc_or_module_addr() should never be used,
> but because the particular use in question is pure and utter garbage.
>
> There are valid reasons to use "is_vmalloc_or_module_addr()", but
> those are along the lines of drivers/char/mem.c, which says "return
> -ENXIO for this crap".
>
> And btw, that horrid crap called "kmap_to_page()" needs to die too.
> When is it *ever* valid to use a kmap'ed page for IO? Here's a clue:
> never.
>
> <SNIP>
>
> Those *disgusting* get_kernel_page[s]() functions came with a
> commentary about "The initial user is expected to be NFS.." and that
> is still the *only* user. The fact that *everybody* else has been able
> to avoid that crap should tell us something.
kmap_to_page, get_kernel_page and the NFS user for it are already scheduled
for death. Dave Kleikamp has been working on a series "Issue O_DIRECT aio
using bio_vec" that replaces what NFS currently does with something far
more sane. The series does not remove the helpers on top, probably because
of the 9P use of it, but if that was changed then the helpers would finally
die. I'm not sure why Dave's series never got merged so added him to the
cc to find out.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [PATCH 09/28] Remove ATHEROS_AR231X
From: Oleksij Rempel @ 2014-02-10 12:17 UTC (permalink / raw)
To: Sergey Ryazanov, Richard Weinberger, Jonathan Bither,
OpenWrt Development List
Cc: Hauke Mehrtens, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
John W. Linville, open list:ATHEROS ATH5K WIR...,
open list:ATHEROS ATH5K WIR..., open,
list@hauke-m.de:NETWORKING DRIVERS, open list,
antonynpavlov@gmail.com
In-Reply-To: <CAHNKnsS7Mv4ZhBWZa53go9L9nZimJ7_FG5HFJ9C3kkGMAEz-mA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]
Am 10.02.2014 13:05, schrieb Sergey Ryazanov:
> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>:
>> Am 09.02.2014 20:18, schrieb Hauke Mehrtens:
>>> On 02/09/2014 07:47 PM, Richard Weinberger wrote:
>>>> The symbol is an orphan, get rid of it.
>>>>
>>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>>> ---
>>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++-----
>>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ----------------------------
>>>> drivers/net/wireless/ath/ath5k/base.c | 14 --------------
>>>> drivers/net/wireless/ath/ath5k/led.c | 7 -------
>>>> 4 files changed, 5 insertions(+), 54 deletions(-)
>>>>
>>>
>>> This code is used in OpenWrt with an out of tree arch code for the
>>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding
>>> this code to mainline Linux kernel, because of lack of time/interest.
>>
>> Sorry, we don't maintain out of tree code.
>>
>
> Oleksij, Jonathan do you still working to make ar231x devices work
> with upstream, since your posts [1, 2]? Or may be someone from OpenWRT
> team would like to add upstream support?
>
> 1. https://lkml.org/lkml/2013/5/13/321
> 2. https://lkml.org/lkml/2013/5/13/358
>
Hi,
my current target was to provide barebox and openocd support.
- ar2313 is already upstream on barebox.
- ar2315-2318 (barebox) awaiting review by Anthony Pavlov.
- openocd (EJTAG) support is ready and i'll push it ASUP.
I hope Jonathan do kernel part. If not, i can provide some work, since i
have testing boards and expiriance on this hardware.
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 278 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2 v2] usbnet: fix bad header length bug
From: Oliver Neukum @ 2014-02-10 12:22 UTC (permalink / raw)
To: Emil Goode
Cc: David S. Miller, Ming Lei, Mark Brown, Jeff Kirsher, Glen Turner,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140210115812.GA4278@lianli>
On Mon, 2014-02-10 at 13:00 +0100, Emil Goode wrote:
> On Mon, Feb 10, 2014 at 07:40:58AM +0100, Oliver Neukum wrote:
> > On Mon, 2014-02-10 at 00:06 +0100, Emil Goode wrote:
> > > The AX88772B occasionally send rx packets that cross urb boundaries
> > > and the remaining partial packet is sent with no hardware header.
> > > When the buffer with a partial packet is of less number of octets
> > > than the value of hard_header_len the buffer is discarded by the
> > > usbnet module. This is causing dropped packages and error messages
> > > in dmesg.
> > >
> > > This can be reproduced by using ping with a packet size
> > > between 1965-1976.
> >
> > Well, then how about simply removing the check?
> > It seems to have outlived its usefulness.
> >
> > Regards
> > Oliver
> >
> >
>
> I did consider that and I think it is probably the best thing to do.
> However, I think the removal of the check could have negative effects
> on the other minidrivers, at least the qmi_wwan minidriver explicitly
> states that it is depending on this check to be made in rx_complete().
<censored>. Oh well. But how about merging it with FLAG_MULTI_PACKET?
I really don't want to add more flags. There is a point where enough
flags make absurd having a common code. We are closing in on that point.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Florian Westphal @ 2014-02-10 12:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: Eric Dumazet, Florian Westphal, netdev
In-Reply-To: <20140209025504.GB17395@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > > static void ip_gso_adjust_seglen(struct sk_buff *skb)
> > > {
> > > unsigned int mtu;
> > >
> > > if (!skb_is_gso(skb))
> > > return;
> > >
> > > mtu = ip_dst_mtu_maybe_forward(skb_dst(skb), true);
> > > skb_shinfo(skb)->gso_size = mtu - sizeof(struct iphdr);
> > > }
> > >
> > > But this yields
> > >
> > > [ 28.644776] kernel BUG at net/net/core/skbuff.c:2984!
> >
> > Yep, lets CC Herbert Xu, as he 'owns' skb_segment()
>
> IMHO we should just stop merging ~DF packets altogether, at least
> for TCP.
Eric, you added DF aggregation in db8caf3dbc77599dc90f4ea0a803cd1d97116f30
(gro: should aggregate frames without DF).
I guess you don't want to revert this commit?
Any other ideas?
skb_gso_segment() is already very complex, I don't want to add more code
to it. And that seems unavoidable if we need to de-couple nr_frags and
gso_size.
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Herbert Xu @ 2014-02-10 12:31 UTC (permalink / raw)
To: Florian Westphal; +Cc: Eric Dumazet, netdev
In-Reply-To: <20140210122331.GA25153@breakpoint.cc>
On Mon, Feb 10, 2014 at 01:23:31PM +0100, Florian Westphal wrote:
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > > > static void ip_gso_adjust_seglen(struct sk_buff *skb)
> > > > {
> > > > unsigned int mtu;
> > > >
> > > > if (!skb_is_gso(skb))
> > > > return;
> > > >
> > > > mtu = ip_dst_mtu_maybe_forward(skb_dst(skb), true);
> > > > skb_shinfo(skb)->gso_size = mtu - sizeof(struct iphdr);
> > > > }
> > > >
> > > > But this yields
> > > >
> > > > [ 28.644776] kernel BUG at net/net/core/skbuff.c:2984!
> > >
> > > Yep, lets CC Herbert Xu, as he 'owns' skb_segment()
> >
> > IMHO we should just stop merging ~DF packets altogether, at least
> > for TCP.
>
> Eric, you added DF aggregation in db8caf3dbc77599dc90f4ea0a803cd1d97116f30
> (gro: should aggregate frames without DF).
>
> I guess you don't want to revert this commit?
> Any other ideas?
>
> skb_gso_segment() is already very complex, I don't want to add more code
> to it. And that seems unavoidable if we need to de-couple nr_frags and
> gso_size.
I don't think adding all this complexity just to be able to
aggregate ~DF packets (which are just wrong to begin with) is
worth it.
If aggregating ~DF packets was a one-liner then sure, but there
is a reason why I didn't aggregate them in the first place and
you've found it :)
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 09/28] Remove ATHEROS_AR231X
From: Sergey Ryazanov @ 2014-02-10 12:38 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Richard Weinberger, Jonathan Bither, OpenWrt Development List,
Hauke Mehrtens, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
John W. Linville, open list:ATHEROS ATH5K WIR...,
open list:ATHEROS ATH5K WIR..., open,
list@hauke-m.de:NETWORKING DRIVERS, open list,
antonynpavlov@gmail.com
In-Reply-To: <52F8C373.9060108@rempel-privat.de>
2014-02-10 16:17 GMT+04:00 Oleksij Rempel <linux@rempel-privat.de>:
> Am 10.02.2014 13:05, schrieb Sergey Ryazanov:
>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>:
>>> Am 09.02.2014 20:18, schrieb Hauke Mehrtens:
>>>> On 02/09/2014 07:47 PM, Richard Weinberger wrote:
>>>>> The symbol is an orphan, get rid of it.
>>>>>
>>>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>>>> ---
>>>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++-----
>>>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ----------------------------
>>>>> drivers/net/wireless/ath/ath5k/base.c | 14 --------------
>>>>> drivers/net/wireless/ath/ath5k/led.c | 7 -------
>>>>> 4 files changed, 5 insertions(+), 54 deletions(-)
>>>>>
>>>>
>>>> This code is used in OpenWrt with an out of tree arch code for the
>>>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding
>>>> this code to mainline Linux kernel, because of lack of time/interest.
>>>
>>> Sorry, we don't maintain out of tree code.
>>>
>>
>> Oleksij, Jonathan do you still working to make ar231x devices work
>> with upstream, since your posts [1, 2]? Or may be someone from OpenWRT
>> team would like to add upstream support?
>>
>> 1. https://lkml.org/lkml/2013/5/13/321
>> 2. https://lkml.org/lkml/2013/5/13/358
>>
>
> Hi,
> my current target was to provide barebox and openocd support.
> - ar2313 is already upstream on barebox.
> - ar2315-2318 (barebox) awaiting review by Anthony Pavlov.
> - openocd (EJTAG) support is ready and i'll push it ASUP.
>
WOW, Impressive.
> I hope Jonathan do kernel part. If not, i can provide some work, since i
> have testing boards and expiriance on this hardware.
>
If you need, I can test kernel part, or even do some porting work. I
have some AR231x based boards, e.g. Ubnt LS2 and NS2.
--
BR,
Sergey
^ permalink raw reply
* RE: [PATCH 1/2 v2] usbnet: fix bad header length bug
From: David Laight @ 2014-02-10 12:39 UTC (permalink / raw)
To: 'Oliver Neukum', Emil Goode
Cc: David S. Miller, Ming Lei, Mark Brown, Jeff Kirsher, Glen Turner,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1392034947.2082.30.camel-B2T3B9s34ElbnMAlSieJcQ@public.gmane.org>
From: Oliver Neukum
> <censored>. Oh well. But how about merging it with FLAG_MULTI_PACKET?
> I really don't want to add more flags. There is a point where enough
> flags make absurd having a common code. We are closing in on that point.
Any sub-driver that supports multi-packet either has to use stupidly
long URB and/or set the rx_urb_size to a multiple of the usb transfer
size.
It will also have to detect illegal short headers.
Actually it might be worth double-checking the encapsulations used.
IIRC the ax88179_178a uses different headers for tx and rx.
So there might be some that support multi-packet but still have
a short(ish) limit on the bulk receive size (before the short fragment).
I'm sat at the wrong desk to look at the code...
David
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Florian Westphal @ 2014-02-10 12:43 UTC (permalink / raw)
To: Herbert Xu; +Cc: Florian Westphal, Eric Dumazet, netdev
In-Reply-To: <20140210123124.GA28752@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Feb 10, 2014 at 01:23:31PM +0100, Florian Westphal wrote:
> > Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > > > > static void ip_gso_adjust_seglen(struct sk_buff *skb)
> > > > > {
> > > > > unsigned int mtu;
> > > > >
> > > > > if (!skb_is_gso(skb))
> > > > > return;
> > > > >
> > > > > mtu = ip_dst_mtu_maybe_forward(skb_dst(skb), true);
> > > > > skb_shinfo(skb)->gso_size = mtu - sizeof(struct iphdr);
> > > > > }
> > > > >
> > > > > But this yields
> > > > >
> > > > > [ 28.644776] kernel BUG at net/net/core/skbuff.c:2984!
> > > >
> > > > Yep, lets CC Herbert Xu, as he 'owns' skb_segment()
> > >
> > > IMHO we should just stop merging ~DF packets altogether, at least
> > > for TCP.
> >
> > Eric, you added DF aggregation in db8caf3dbc77599dc90f4ea0a803cd1d97116f30
> > (gro: should aggregate frames without DF).
> >
> > I guess you don't want to revert this commit?
> > Any other ideas?
> >
> > skb_gso_segment() is already very complex, I don't want to add more code
> > to it. And that seems unavoidable if we need to de-couple nr_frags and
> > gso_size.
>
> I don't think adding all this complexity just to be able to
> aggregate ~DF packets (which are just wrong to begin with) is
> worth it.
>
> If aggregating ~DF packets was a one-liner then sure, but there
> is a reason why I didn't aggregate them in the first place and
> you've found it :)
Well we could go with my original patch that will do software
segmentation on ~DF packets in the forwarding path if the outmtu is too
small for the individual packets. The output path then simply
creates fragments.
Eric suggested to shrink gso_size instead to avoid segmentation+fragments.
I think its nice idea, but skb_gso_segment makes certain assumptions about
nr_frags and gso_size (it can't handle frag size > desired mss).
Hannes pointed out that we'd also need to deal with
SKB_MAX_FRAGS * gso_size exceeding fragments.
Quite frankly, I'd prefer to go with
skb_gso_segment(skb, features & ~NETIF_F_GSO_MASK);
The scenario is rare anyway given the number of bug reports (or lack
thereof) about '~DF tcp doesn't work with gro in fwd path when output
mtu is too small'.
Its not like this could never be improved later on.
Best regards,
Florian
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Herbert Xu @ 2014-02-10 12:50 UTC (permalink / raw)
To: Florian Westphal; +Cc: Eric Dumazet, netdev
In-Reply-To: <20140210124346.GA6329@breakpoint.cc>
On Mon, Feb 10, 2014 at 01:43:46PM +0100, Florian Westphal wrote:
>
> Eric suggested to shrink gso_size instead to avoid segmentation+fragments.
> I think its nice idea, but skb_gso_segment makes certain assumptions about
> nr_frags and gso_size (it can't handle frag size > desired mss).
This breaks the most important assumption behind GRO which is
to preserve end-to-end connectivity. Resegmenting packets as
suggested on a router/bridge is just wrong.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH/RESEND] 3c59x: Remove unused pointer in vortex_eisa_cleanup()
From: Steffen Klassert @ 2014-02-10 12:50 UTC (permalink / raw)
To: Christian Engelmayer; +Cc: netdev
In-Reply-To: <20140208201023.731538cf@spike>
On Sat, Feb 08, 2014 at 08:10:23PM +0100, Christian Engelmayer wrote:
> Remove unused network device private data pointer 'vp' in function
> vortex_eisa_cleanup(). Detected by Coverity: CID 139826.
>
> Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
> ---
> Resend using address steffen@klassert.de as retrieved from the mail delivery
> fail notification by tu-chemnitz.de. Information in MAINTAINERS seems to be
> outdated on that point.
Oh yes, it expired at the beginning of the year. I'll do a
patch to update the maintainers entry. Thanks for the info!
^ permalink raw reply
* [PATCH] dp83640: Get gpio and master/slave configuration from DT
From: Stefan Sørensen @ 2014-02-10 13:00 UTC (permalink / raw)
To: richardcochran, grant.likely, robh+dt, netdev, linux-kernel,
devicetree
Cc: Stefan Sørensen
This patch removes the module parameters gpio_tab and chosen_phy in favour of
retrieving the configuration from DT through the properties
dp83640,slave
dp83640,calibrate-gpio
dp83640,perout-gpios
dp83640,extts-gpios
The configuration is now stored for each master clock device, allowing different
gpio setups for each master.
Furthermore the code is enhanced to handle more than one periodic output.
Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
---
The slave configuration code is totally untested as I only have access to
boards with a single DP3640.
drivers/net/phy/dp83640.c | 195 ++++++++++++++++++++++++++++++----------------
1 file changed, 128 insertions(+), 67 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 547725f..118403d 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -30,6 +30,7 @@
#include <linux/phy.h>
#include <linux/ptp_classify.h>
#include <linux/ptp_clock_kernel.h>
+#include <linux/of_device.h>
#include "dp83640_reg.h"
@@ -38,15 +39,11 @@
#define LAYER4 0x02
#define LAYER2 0x01
#define MAX_RXTS 64
-#define N_EXT_TS 6
+#define N_EXT 8
#define PSF_PTPVER 2
#define PSF_EVNT 0x4000
#define PSF_RX 0x2000
#define PSF_TX 0x1000
-#define EXT_EVENT 1
-#define CAL_EVENT 7
-#define CAL_TRIGGER 7
-#define PER_TRIGGER 6
#define MII_DP83640_MICR 0x11
#define MII_DP83640_MISR 0x12
@@ -123,6 +120,8 @@ struct dp83640_private {
/* queues of incoming and outgoing packets */
struct sk_buff_head rx_queue;
struct sk_buff_head tx_queue;
+ /* is this phyter a slave */
+ bool slave;
};
struct dp83640_clock {
@@ -144,35 +143,9 @@ struct dp83640_clock {
struct list_head phylist;
/* reference to our PTP hardware clock */
struct ptp_clock *ptp_clock;
+ u32 perout_gpios[N_EXT], extts_gpios[N_EXT], calibrate_gpio;
};
-/* globals */
-
-enum {
- CALIBRATE_GPIO,
- PEROUT_GPIO,
- EXTTS0_GPIO,
- EXTTS1_GPIO,
- EXTTS2_GPIO,
- EXTTS3_GPIO,
- EXTTS4_GPIO,
- EXTTS5_GPIO,
- GPIO_TABLE_SIZE
-};
-
-static int chosen_phy = -1;
-static ushort gpio_tab[GPIO_TABLE_SIZE] = {
- 1, 2, 3, 4, 8, 9, 10, 11
-};
-
-module_param(chosen_phy, int, 0444);
-module_param_array(gpio_tab, ushort, NULL, 0444);
-
-MODULE_PARM_DESC(chosen_phy, \
- "The address of the PHY to use for the ancillary clock features");
-MODULE_PARM_DESC(gpio_tab, \
- "Which GPIO line to use for which purpose: cal,perout,extts1,...,extts6");
-
/* a list of clocks and a mutex to protect it */
static LIST_HEAD(phyter_clocks);
static DEFINE_MUTEX(phyter_clocks_lock);
@@ -267,15 +240,16 @@ static u64 phy2txts(struct phy_txts *p)
}
static void periodic_output(struct dp83640_clock *clock,
- struct ptp_clock_request *clkreq, bool on)
+ struct ptp_clock_request *clkreq, int index,
+ bool on)
{
struct dp83640_private *dp83640 = clock->chosen;
struct phy_device *phydev = dp83640->phydev;
u32 sec, nsec, period;
u16 gpio, ptp_trig, trigger, val;
- gpio = on ? gpio_tab[PEROUT_GPIO] : 0;
- trigger = PER_TRIGGER;
+ gpio = on ? clock->perout_gpios[index] : 0;
+ trigger = clock->caps.n_ext_ts + index;
ptp_trig = TRIG_WR |
(trigger & TRIG_CSEL_MASK) << TRIG_CSEL_SHIFT |
@@ -430,12 +404,12 @@ static int ptp_dp83640_enable(struct ptp_clock_info *ptp,
switch (rq->type) {
case PTP_CLK_REQ_EXTTS:
index = rq->extts.index;
- if (index < 0 || index >= N_EXT_TS)
+ if (index < 0 || index >= clock->caps.n_ext_ts)
return -EINVAL;
- event_num = EXT_EVENT + index;
+ event_num = index;
evnt = EVNT_WR | (event_num & EVNT_SEL_MASK) << EVNT_SEL_SHIFT;
if (on) {
- gpio_num = gpio_tab[EXTTS0_GPIO + index];
+ gpio_num = clock->extts_gpios[index];
evnt |= (gpio_num & EVNT_GPIO_MASK) << EVNT_GPIO_SHIFT;
evnt |= EVNT_RISE;
}
@@ -443,9 +417,10 @@ static int ptp_dp83640_enable(struct ptp_clock_info *ptp,
return 0;
case PTP_CLK_REQ_PEROUT:
- if (rq->perout.index != 0)
+ index = rq->perout.index;
+ if (index < 0 || index >= clock->caps.n_per_out)
return -EINVAL;
- periodic_output(clock, rq, on);
+ periodic_output(clock, rq, index, on);
return 0;
default:
@@ -538,10 +513,9 @@ static void recalibrate(struct dp83640_clock *clock)
struct list_head *this;
struct dp83640_private *tmp;
struct phy_device *master = clock->chosen->phydev;
- u16 cal_gpio, cfg0, evnt, ptp_trig, trigger, val;
+ u16 cfg0, evnt, ptp_trig, trigger, val;
- trigger = CAL_TRIGGER;
- cal_gpio = gpio_tab[CALIBRATE_GPIO];
+ trigger = clock->caps.n_ext_ts + clock->caps.n_per_out;
mutex_lock(&clock->extreg_lock);
@@ -564,8 +538,8 @@ static void recalibrate(struct dp83640_clock *clock)
* enable an event timestamp
*/
evnt = EVNT_WR | EVNT_RISE | EVNT_SINGLE;
- evnt |= (CAL_EVENT & EVNT_SEL_MASK) << EVNT_SEL_SHIFT;
- evnt |= (cal_gpio & EVNT_GPIO_MASK) << EVNT_GPIO_SHIFT;
+ evnt |= (trigger & EVNT_SEL_MASK) << EVNT_SEL_SHIFT;
+ evnt |= (clock->calibrate_gpio & EVNT_GPIO_MASK) << EVNT_GPIO_SHIFT;
list_for_each(this, &clock->phylist) {
tmp = list_entry(this, struct dp83640_private, list);
@@ -578,7 +552,7 @@ static void recalibrate(struct dp83640_clock *clock)
*/
ptp_trig = TRIG_WR | TRIG_IF_LATE | TRIG_PULSE;
ptp_trig |= (trigger & TRIG_CSEL_MASK) << TRIG_CSEL_SHIFT;
- ptp_trig |= (cal_gpio & TRIG_GPIO_MASK) << TRIG_GPIO_SHIFT;
+ ptp_trig |= (clock->calibrate_gpio & TRIG_GPIO_MASK) << TRIG_GPIO_SHIFT;
ext_write(0, master, PAGE5, PTP_TRIG, ptp_trig);
/* load trigger */
@@ -642,7 +616,7 @@ static void recalibrate(struct dp83640_clock *clock)
static inline u16 exts_chan_to_edata(int ch)
{
- return 1 << ((ch + EXT_EVENT) * 2);
+ return 1 << ((ch) * 2);
}
static int decode_evnt(struct dp83640_private *dp83640,
@@ -676,14 +650,14 @@ static int decode_evnt(struct dp83640_private *dp83640,
parsed = words + 2;
} else {
parsed = words + 1;
- i = ((ests >> EVNT_NUM_SHIFT) & EVNT_NUM_MASK) - EXT_EVENT;
+ i = ((ests >> EVNT_NUM_SHIFT) & EVNT_NUM_MASK);
ext_status = exts_chan_to_edata(i);
}
event.type = PTP_CLOCK_EXTTS;
event.timestamp = phy2txts(&dp83640->edata);
- for (i = 0; i < N_EXT_TS; i++) {
+ for (i = 0; i < dp83640->clock->caps.n_ext_ts; i++) {
if (ext_status & exts_chan_to_edata(i)) {
event.index = i;
ptp_clock_event(dp83640->clock->ptp_clock, &event);
@@ -889,8 +863,6 @@ static void dp83640_clock_init(struct dp83640_clock *clock, struct mii_bus *bus)
sprintf(clock->caps.name, "dp83640 timer");
clock->caps.max_adj = 1953124;
clock->caps.n_alarm = 0;
- clock->caps.n_ext_ts = N_EXT_TS;
- clock->caps.n_per_out = 1;
clock->caps.pps = 0;
clock->caps.adjfreq = ptp_dp83640_adjfreq;
clock->caps.adjtime = ptp_dp83640_adjtime;
@@ -903,18 +875,6 @@ static void dp83640_clock_init(struct dp83640_clock *clock, struct mii_bus *bus)
get_device(&bus->dev);
}
-static int choose_this_phy(struct dp83640_clock *clock,
- struct phy_device *phydev)
-{
- if (chosen_phy == -1 && !clock->chosen)
- return 1;
-
- if (chosen_phy == phydev->addr)
- return 1;
-
- return 0;
-}
-
static struct dp83640_clock *dp83640_clock_get(struct dp83640_clock *clock)
{
if (clock)
@@ -960,6 +920,100 @@ static void dp83640_clock_put(struct dp83640_clock *clock)
mutex_unlock(&clock->clock_lock);
}
+#ifdef CONFIG_OF
+static int dp83640_probe_dt(struct device_node *node,
+ struct dp83640_private *dp83640)
+{
+ struct dp83640_clock *clock = dp83640->clock;
+ struct property *prop;
+ int err, proplen;
+
+ if (!node)
+ return 0;
+
+ if (of_find_property(node, "dp83640,slave", NULL))
+ dp83640->slave = true;
+ if (!dp83640->slave && clock->chosen) {
+ pr_err("dp83640,slave must be set if more than one device on the same bus");
+ return -EINVAL;
+ }
+
+ prop = of_find_property(node, "dp83640,perout-gpios", &proplen);
+ if (prop) {
+ if (dp83640->slave) {
+ pr_err("dp83640,perout-gpios property can not be set together with dp83640,slave");
+ return -EINVAL;
+ }
+
+ clock->caps.n_per_out = proplen / sizeof(u32);
+ if (clock->caps.n_per_out > N_EXT) {
+ pr_err("dp83640,perout-gpios may not have more than %d entries",
+ N_EXT);
+ return -EINVAL;
+ }
+ err = of_property_read_u32_array(node, "dp83640,perout-gpios",
+ clock->perout_gpios,
+ clock->caps.n_per_out);
+ if (err < 0)
+ return err;
+ }
+
+ prop = of_find_property(node, "dp83640,extts-gpios", &proplen);
+ if (prop) {
+ if (dp83640->slave) {
+ pr_err("dp83640,extts-gpios property can not be set together with dp83640,slave");
+ return -EINVAL;
+ }
+
+ clock->caps.n_ext_ts = proplen / sizeof(u32);
+ if (clock->caps.n_ext_ts > N_EXT) {
+ pr_err("dp83640,extts-gpios may not have more than %d entries",
+ N_EXT);
+ return -EINVAL;
+ }
+ err = of_property_read_u32_array(node, "dp83640,extts-gpios",
+ clock->extts_gpios,
+ clock->caps.n_ext_ts);
+ if (err < 0)
+ return err;
+ }
+
+ prop = of_find_property(node, "dp83640,calibrate-gpio", &proplen);
+ if (prop) {
+ if (dp83640->slave) {
+ pr_err("dp83640,calibrate-gpio property can not be set together with dp83640,slave");
+ return -EINVAL;
+ }
+ clock->calibrate_gpio = -1;
+ of_property_read_u32(node, "dp83640,calibrate-gpio",
+ &clock->calibrate_gpio);
+ }
+
+ if (!dp83640->slave) {
+ if (clock->caps.n_per_out + clock->caps.n_ext_ts +
+ (clock->calibrate_gpio != -1 ? 1 : 0) > N_EXT) {
+ pr_err("Too many gpios configured");
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+static const struct of_device_id dp83640_of_match_table[] = {
+ { .compatible = "national,dp83640", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, dp83640_of_match_table);
+#else
+
+static inline int dp83640_probe_dt(struct device_node *node,
+ struct dp83640_private *dp83640)
+{
+ return 0;
+}
+#endif
+
static int dp83640_probe(struct phy_device *phydev)
{
struct dp83640_clock *clock;
@@ -977,7 +1031,13 @@ static int dp83640_probe(struct phy_device *phydev)
if (!dp83640)
goto no_memory;
+ dp83640->clock = clock;
dp83640->phydev = phydev;
+
+ err = dp83640_probe_dt(phydev->dev.of_node, dp83640);
+ if (err)
+ return err;
+
INIT_WORK(&dp83640->ts_work, rx_timestamp_work);
INIT_LIST_HEAD(&dp83640->rxts);
@@ -991,9 +1051,7 @@ static int dp83640_probe(struct phy_device *phydev)
skb_queue_head_init(&dp83640->rx_queue);
skb_queue_head_init(&dp83640->tx_queue);
- dp83640->clock = clock;
-
- if (choose_this_phy(clock, phydev)) {
+ if (!clock->chosen && !dp83640->slave) {
clock->chosen = dp83640;
clock->ptp_clock = ptp_clock_register(&clock->caps, &phydev->dev);
if (IS_ERR(clock->ptp_clock)) {
@@ -1338,7 +1396,10 @@ static struct phy_driver dp83640_driver = {
.hwtstamp = dp83640_hwtstamp,
.rxtstamp = dp83640_rxtstamp,
.txtstamp = dp83640_txtstamp,
- .driver = {.owner = THIS_MODULE,}
+ .driver = {
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(dp83640_of_match_table),
+ }
};
static int __init dp83640_init(void)
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH 1/2 v2] usbnet: fix bad header length bug
From: Bjørn Mork @ 2014-02-10 13:05 UTC (permalink / raw)
To: Oliver Neukum
Cc: Emil Goode, David S. Miller, Ming Lei, Mark Brown, Jeff Kirsher,
Glen Turner, netdev, linux-usb, linux-kernel
In-Reply-To: <1392034947.2082.30.camel@linux-fkkt.site>
Oliver Neukum <oliver@neukum.org> writes:
> On Mon, 2014-02-10 at 13:00 +0100, Emil Goode wrote:
>> On Mon, Feb 10, 2014 at 07:40:58AM +0100, Oliver Neukum wrote:
>
>> > Well, then how about simply removing the check?
>> > It seems to have outlived its usefulness.
>> >
>> > Regards
>> > Oliver
>> >
>> >
>>
>> I did consider that and I think it is probably the best thing to do.
>> However, I think the removal of the check could have negative effects
>> on the other minidrivers, at least the qmi_wwan minidriver explicitly
>> states that it is depending on this check to be made in rx_complete().
>
> <censored>.
No need to do that. I had the exact same reaction myself :-)
Anyway, I put that comment there mostly as a note to myself why the
check would be redundant at that point. I don't see any problem with
removing the generic check in usbnet as long as we add similar checks
whereever they are needed, like in qmi_wwan.
Note that usbnet_skb_return will be one of those places. It calls
eth_type_trans() on the skb, so it should verify that the length is at
least ETH_HLEN first.
> Oh well. But how about merging it with FLAG_MULTI_PACKET?
> I really don't want to add more flags. There is a point where enough
> flags make absurd having a common code. We are closing in on that point.
Agreed. I would even say we are past that point...
Bjørn
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Eric Dumazet @ 2014-02-10 13:08 UTC (permalink / raw)
To: Herbert Xu; +Cc: Florian Westphal, netdev
In-Reply-To: <20140210125049.GB28752@gondor.apana.org.au>
On Mon, 2014-02-10 at 20:50 +0800, Herbert Xu wrote:
> On Mon, Feb 10, 2014 at 01:43:46PM +0100, Florian Westphal wrote:
> >
> > Eric suggested to shrink gso_size instead to avoid segmentation+fragments.
> > I think its nice idea, but skb_gso_segment makes certain assumptions about
> > nr_frags and gso_size (it can't handle frag size > desired mss).
>
> This breaks the most important assumption behind GRO which is
> to preserve end-to-end connectivity. Resegmenting packets as
> suggested on a router/bridge is just wrong.
Yeah, this is the old mantra.
Sending TCP packets without DF means the sender do not care by
definition.
If you disable GRO for such packets, it slows down receivers and
increase packet drops.
I've added the segmentation for these packets for a reason, that you are
free to not understand, but there is absolutely no need reason to not
aggregate TCP packets without DF. This is what you suggested to ignore
the problem on skb_segment() being so limited.
Instead of a router being forced to segment all incoming fragments into
X+Y
X+Y
X+Y
X+Y
Its reasonable to send X+X+X+X+X
And we should be reasonable, not trying to enforce a particular view of
what _should_ the traffic looks like on the Internet.
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Eric Dumazet @ 2014-02-10 13:12 UTC (permalink / raw)
To: Herbert Xu; +Cc: Florian Westphal, netdev
In-Reply-To: <20140210123124.GA28752@gondor.apana.org.au>
On Mon, 2014-02-10 at 20:31 +0800, Herbert Xu wrote:
> On Mon, Feb 10, 2014 at 01:23:31PM +0100, Florian Westphal wrote:
> > Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > > > > static void ip_gso_adjust_seglen(struct sk_buff *skb)
> > > > > {
> > > > > unsigned int mtu;
> > > > >
> > > > > if (!skb_is_gso(skb))
> > > > > return;
> > > > >
> > > > > mtu = ip_dst_mtu_maybe_forward(skb_dst(skb), true);
> > > > > skb_shinfo(skb)->gso_size = mtu - sizeof(struct iphdr);
> > > > > }
> > > > >
> > > > > But this yields
> > > > >
> > > > > [ 28.644776] kernel BUG at net/net/core/skbuff.c:2984!
> > > >
> > > > Yep, lets CC Herbert Xu, as he 'owns' skb_segment()
> > >
> > > IMHO we should just stop merging ~DF packets altogether, at least
> > > for TCP.
> >
> > Eric, you added DF aggregation in db8caf3dbc77599dc90f4ea0a803cd1d97116f30
> > (gro: should aggregate frames without DF).
> >
> > I guess you don't want to revert this commit?
> > Any other ideas?
> >
> > skb_gso_segment() is already very complex, I don't want to add more code
> > to it. And that seems unavoidable if we need to de-couple nr_frags and
> > gso_size.
>
> I don't think adding all this complexity just to be able to
> aggregate ~DF packets (which are just wrong to begin with) is
> worth it.
Wrong by your standards. Which are not universal.
>
> If aggregating ~DF packets was a one-liner then sure, but there
> is a reason why I didn't aggregate them in the first place and
> you've found it :)
I sent months ago a solution for skb_segment() that you ignored.
I understand you never hit cases where DF was not set, I can tell you
its happening in the real world.
GRO stack already breaks reversibility by definition since day-0
Recent tunneling support breaks it as well.
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Eric Dumazet @ 2014-02-10 13:15 UTC (permalink / raw)
To: Florian Westphal; +Cc: Herbert Xu, netdev
In-Reply-To: <20140210124346.GA6329@breakpoint.cc>
On Mon, 2014-02-10 at 13:43 +0100, Florian Westphal wrote:
> Well we could go with my original patch that will do software
> segmentation on ~DF packets in the forwarding path if the outmtu is too
> small for the individual packets. The output path then simply
> creates fragments.
Most linux routers disable GRO anyway.
GRO is mostly used on linux hosts to improve performance, so most GRO
packets are consumed on the receiving host.
^ 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