* Re: [PATCH] slip: fix NOHZ local_softirq_pending 08 warning
From: Oliver Hartkopp @ 2011-08-10 14:33 UTC (permalink / raw)
To: Alan Cox, matvejchikov; +Cc: netdev
In-Reply-To: <20110810102824.4c4eaefe@lxorguk.ukuu.org.uk>
On 10.08.2011 11:28, Alan Cox wrote:
>> 2) From tty_flip_buffer_push() which schedules the flush_to_ldisc to
>> work or calls it directly if the tty->low_latency set.
>>
>> So the only thing we must take into account that with tty->low_latency
>> set we can be in IRQ context when doing with netif_rx_ni(). But if we
>
> A driver is not permitted to directly call into flush_to_ldisc from an
> interrupt so that case doesn't happen.
>
Thanks to both of you for the explanation!
I'll send a patch for slcan.c then.
Best regards,
Oliver
^ permalink raw reply
* Re: [PATCH v10 3/5] [flexcan] Add of_match to platform_device definition.
From: Robin Holt @ 2011-08-10 14:33 UTC (permalink / raw)
To: Robin Holt, Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Marc Kleine-Budde, PPC list,
U Bhaskar-B22300
In-Reply-To: <1312945564-6626-4-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
On Tue, Aug 09, 2011 at 10:06:02PM -0500, Robin Holt wrote:
> On powerpc, the OpenFirmware devices are not matched without specifying
> an of_match array. Introduce that array as that is used for matching
> on the Freescale P1010 processor.
>
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> ---
> drivers/net/can/flexcan.c | 13 ++++++++++++-
> 1 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
> index 68cbe52..662f832 100644
> --- a/drivers/net/can/flexcan.c
> +++ b/drivers/net/can/flexcan.c
> @@ -1027,8 +1027,19 @@ static int __devexit flexcan_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static struct of_device_id flexcan_of_match[] = {
> + {
> + .compatible = "fsl,flexcan",
Let me make sure I have this correct. At this point, we would want it
to be fsl,flexcan here. If, at some point, we find the i.MX-wonderful
has diverged from the -p1010, we would, at that point in the code, use
of_device_is_compatible to differentiate the two, correct? That would
mean we should make no change to this patch for the fsl,flexcan-p1010,
right?
Robin
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-10 14:15 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
Scott Wood, PPC list
In-Reply-To: <4E428BFF.7060402-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Wed, Aug 10, 2011 at 03:47:43PM +0200, Wolfgang Grandegger wrote:
> Hi Robin,
>
> On 08/10/2011 05:06 AM, Robin Holt wrote:
> > In working with the socketcan developers, we have come to the conclusion
> > the Documentation...fsl-flexcan.txt device tree documentation needs to
> > be cleaned up. The driver does not depend upon any properties other
>
> Your first sentence could be misleading. Please just describe what the
> patch does and why, something like:
>
> "This patch cleans up the documentation of the device-tree binding for
> the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
> properties are not needed as the frequency of the source clock is
> fixed..." and so on.
I borrowed heavily from your message. ;)
> > than the required properties so we are removing the file. Additionally,
> > the p1010*dts* files are not following the standard for node naming in
> > that they have a trailing -v1.0.
>
> > Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> > To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> > To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> > To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> > Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> > Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> > Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> > ---
> > .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 --------------------
> > arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
> > arch/powerpc/boot/dts/p1010si.dtsi | 8 +-
> > 3 files changed, 4 insertions(+), 73 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > deleted file mode 100644
> > index 1a729f0..0000000
> > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > +++ /dev/null
> > @@ -1,61 +0,0 @@
> > -CAN Device Tree Bindings
> > -------------------------
> > -2011 Freescale Semiconductor, Inc.
> > -
> > -fsl,flexcan-v1.0 nodes
> > ------------------------
> > -In addition to the required compatible-, reg- and interrupt-properties, you can
> > -also specify which clock source shall be used for the controller.
> > -
> > -CPI Clock- Can Protocol Interface Clock
> > - This CLK_SRC bit of CTRL(control register) selects the clock source to
> > - the CAN Protocol Interface(CPI) to be either the peripheral clock
> > - (driven by the PLL) or the crystal oscillator clock. The selected clock
> > - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> > - The PRESDIV field of CTRL(control register) controls a prescaler that
> > - generates the Serial Clock (Sclock), whose period defines the
> > - time quantum used to compose the CAN waveform.
> > -
> > -Can Engine Clock Source
> > - There are two sources for CAN clock
> > - - Platform Clock It represents the bus clock
> > - - Oscillator Clock
> > -
> > - Peripheral Clock (PLL)
> > - --------------
> > - |
> > - --------- -------------
> > - | |CPI Clock | Prescaler | Sclock
> > - | |---------------->| (1.. 256) |------------>
> > - --------- -------------
> > - | |
> > - -------------- ---------------------CLK_SRC
> > - Oscillator Clock
> > -
> > -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
> > - the peripheral clock. PLL clock is fed to the
> > - prescaler to generate the Serial Clock (Sclock).
> > - Valid values are "oscillator" and "platform"
> > - "oscillator": CAN engine clock source is oscillator clock.
> > - "platform" The CAN engine clock source is the bus clock
> > - (platform clock).
> > -
> > -- fsl,flexcan-clock-divider : for the reference and system clock, an additional
> > - clock divider can be specified.
> > -- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
> > -
> > -Note:
> > - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
> > - - P1010 does not have oscillator as the Clock Source.So the default
> > - Clock Source is platform clock.
> > -Examples:
> > -
> > - can0@1c000 {
> > - compatible = "fsl,flexcan-v1.0";
> > - reg = <0x1c000 0x1000>;
> > - interrupts = <48 0x2>;
> > - interrupt-parent = <&mpic>;
> > - fsl,flexcan-clock-source = "platform";
> > - fsl,flexcan-clock-divqider = <2>;
> > - clock-frequency = <fixed by u-boot>;
> > - };
>
> Do we really want to drop the documentation for that binding. I think
> something like the following text would be still useful:
>
> ------------------------
> Flexcan CAN contoller on Freescale's ARM and PowerPC processors
>
> Required properties:
>
> - compatible : Should be "fsl,flexcan" and optionally
> "fsl,flexcan-<processor>"
> - reg : Offset and length of the register set for this device
> - interrupts : Interrupt tuple for this device
>
> Example:
>
> can@1c000 {
> compatible = "fsl,p1010-flexcan", "fsl,flexcan";
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> };
> -------------------------
Done, except the
> compatible = "fsl,p1010-flexcan", "fsl,flexcan";
line is
compatible = "fsl,flexcan", "fsl,flexcan-p1010";
>
> What do you think?
>
> > diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> > index 6b33b73..d6a0bb2 100644
> > --- a/arch/powerpc/boot/dts/p1010rdb.dts
> > +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> > @@ -169,14 +169,6 @@
> > };
> > };
> >
> > - can0@1c000 {
> > - fsl,flexcan-clock-source = "platform";
> > - };
> > -
> > - can1@1d000 {
> > - fsl,flexcan-clock-source = "platform";
> > - };
> > -
> > usb@22000 {
> > phy_type = "utmi";
> > };
> > diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi
> > index 7f51104..20c396d 100644
> > --- a/arch/powerpc/boot/dts/p1010si.dtsi
> > +++ b/arch/powerpc/boot/dts/p1010si.dtsi
> > @@ -141,19 +141,19 @@
> > };
> >
> > can0@1c000 {
> > - compatible = "fsl,flexcan-v1.0";
> > + compatible = "fsl,p1010-flexcan",
> > + "fsl,flexcan";
>
> Does fit on one line.
>
> > reg = <0x1c000 0x1000>;
> > interrupts = <48 0x2>;
> > interrupt-parent = <&mpic>;
> > - fsl,flexcan-clock-divider = <2>;
> > };
> >
> > can1@1d000 {
> > - compatible = "fsl,flexcan-v1.0";
> > + compatible = "fsl,p1010-flexcan",
> > + "fsl,flexcan";
>
> Ditto
>
> > reg = <0x1d000 0x1000>;
> > interrupts = <61 0x2>;
> > interrupt-parent = <&mpic>;
> > - fsl,flexcan-clock-divider = <2>;
> > };
> >
> > L2: l2-cache-controller@20000 {
>
> Please also correct the node names (not using the number suffix).
So the node names should be
can@1c000 {
can@1d000 {
correct?
Robin
^ permalink raw reply
* Re: Use of 802.3ad bonding for increasing link throughput
From: Simon Farnsworth @ 2011-08-10 13:50 UTC (permalink / raw)
To: netdev
In-Reply-To: <4E427499.8060108@cyconix.com>
Tom Brown wrote:
> [couldn't thread with '802.3ad bonding brain damaged', as I've just
> signed up]
>
> So, under what circumstances would a user actually use 802.3ad mode to
> "increase" link throughput, rather than just for redundancy? Are there
> any circumstances in which a single file, for example, could be
> transferred at multiple-NIC speed? The 3 hashing options are:
>
As an example, from my server room here; I have an install server (TFTP, FTP
and HTTP) connected by a 2x1G LACP bond to the switch. When I have multiple
clients installing simultaneously, the layer2 hash distributes the load
nicely across both NICs - I can reach saturation on both NICs together.
If I had routers between my clients and the install server, I'd need
layer2+3 hashing to spread the clients over the links, but I'd still be able
to push over a gigabit per second to the clients, despite being limited to
1GBit/s to each individual client by the packet distribution.
I'm sure that you can think of lots of other situations in which you have
multiple conversations sharing a link - those are the situations that gain
speed from 802.3ad.
--
Simon Farnsworth
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Wolfgang Grandegger @ 2011-08-10 13:47 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
Scott Wood, PPC list
In-Reply-To: <1312945564-6626-6-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
Hi Robin,
On 08/10/2011 05:06 AM, Robin Holt wrote:
> In working with the socketcan developers, we have come to the conclusion
> the Documentation...fsl-flexcan.txt device tree documentation needs to
> be cleaned up. The driver does not depend upon any properties other
Your first sentence could be misleading. Please just describe what the
patch does and why, something like:
"This patch cleans up the documentation of the device-tree binding for
the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
properties are not needed as the frequency of the source clock is
fixed..." and so on.
> than the required properties so we are removing the file. Additionally,
> the p1010*dts* files are not following the standard for node naming in
> that they have a trailing -v1.0.
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
> To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
> To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
> Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> ---
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 --------------------
> arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
> arch/powerpc/boot/dts/p1010si.dtsi | 8 +-
> 3 files changed, 4 insertions(+), 73 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>
> diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> deleted file mode 100644
> index 1a729f0..0000000
> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> +++ /dev/null
> @@ -1,61 +0,0 @@
> -CAN Device Tree Bindings
> -------------------------
> -2011 Freescale Semiconductor, Inc.
> -
> -fsl,flexcan-v1.0 nodes
> ------------------------
> -In addition to the required compatible-, reg- and interrupt-properties, you can
> -also specify which clock source shall be used for the controller.
> -
> -CPI Clock- Can Protocol Interface Clock
> - This CLK_SRC bit of CTRL(control register) selects the clock source to
> - the CAN Protocol Interface(CPI) to be either the peripheral clock
> - (driven by the PLL) or the crystal oscillator clock. The selected clock
> - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> - The PRESDIV field of CTRL(control register) controls a prescaler that
> - generates the Serial Clock (Sclock), whose period defines the
> - time quantum used to compose the CAN waveform.
> -
> -Can Engine Clock Source
> - There are two sources for CAN clock
> - - Platform Clock It represents the bus clock
> - - Oscillator Clock
> -
> - Peripheral Clock (PLL)
> - --------------
> - |
> - --------- -------------
> - | |CPI Clock | Prescaler | Sclock
> - | |---------------->| (1.. 256) |------------>
> - --------- -------------
> - | |
> - -------------- ---------------------CLK_SRC
> - Oscillator Clock
> -
> -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
> - the peripheral clock. PLL clock is fed to the
> - prescaler to generate the Serial Clock (Sclock).
> - Valid values are "oscillator" and "platform"
> - "oscillator": CAN engine clock source is oscillator clock.
> - "platform" The CAN engine clock source is the bus clock
> - (platform clock).
> -
> -- fsl,flexcan-clock-divider : for the reference and system clock, an additional
> - clock divider can be specified.
> -- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
> -
> -Note:
> - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
> - - P1010 does not have oscillator as the Clock Source.So the default
> - Clock Source is platform clock.
> -Examples:
> -
> - can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> - reg = <0x1c000 0x1000>;
> - interrupts = <48 0x2>;
> - interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-source = "platform";
> - fsl,flexcan-clock-divqider = <2>;
> - clock-frequency = <fixed by u-boot>;
> - };
Do we really want to drop the documentation for that binding. I think
something like the following text would be still useful:
------------------------
Flexcan CAN contoller on Freescale's ARM and PowerPC processors
Required properties:
- compatible : Should be "fsl,flexcan" and optionally
"fsl,flexcan-<processor>"
- reg : Offset and length of the register set for this device
- interrupts : Interrupt tuple for this device
Example:
can@1c000 {
compatible = "fsl,p1010-flexcan", "fsl,flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
};
-------------------------
What do you think?
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> index 6b33b73..d6a0bb2 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dts
> +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> @@ -169,14 +169,6 @@
> };
> };
>
> - can0@1c000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> - can1@1d000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> usb@22000 {
> phy_type = "utmi";
> };
> diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi
> index 7f51104..20c396d 100644
> --- a/arch/powerpc/boot/dts/p1010si.dtsi
> +++ b/arch/powerpc/boot/dts/p1010si.dtsi
> @@ -141,19 +141,19 @@
> };
>
> can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> + compatible = "fsl,p1010-flexcan",
> + "fsl,flexcan";
Does fit on one line.
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> can1@1d000 {
> - compatible = "fsl,flexcan-v1.0";
> + compatible = "fsl,p1010-flexcan",
> + "fsl,flexcan";
Ditto
> reg = <0x1d000 0x1000>;
> interrupts = <61 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> L2: l2-cache-controller@20000 {
Please also correct the node names (not using the number suffix).
Wolfgang.
^ permalink raw reply
* Re: [PATCH v2] pch ieee1588 driver for Intel EG20T PCH
From: Joe Perches @ 2011-08-10 13:40 UTC (permalink / raw)
To: Toshiharu Okada
Cc: richard.cochran, netdev, linux-kernel, qi.wang, yong.y.wang,
joel.clark, kok.howg.ewe, tomoya-linux
In-Reply-To: <1312956783-11460-1-git-send-email-toshiharu-linux@dsn.okisemi.com>
On Wed, 2011-08-10 at 15:13 +0900, Toshiharu Okada wrote:
> This patch is for IEEE1588 driver of Intel EG20T PCH.
> EG20T PCH is the platform controller hub that is used in Intel's
> general embedded platform.
> This driver adds support for using the EG20T PCH as a PTP clock.
> Would you review this patch, although this driver has not been tested yet?
Just trivia...
> diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
[]
> +/**
> + * struct ch_1588_params_ - 1588 module paramter
parameter
> + */
> +struct pch_params_ {
> + u8 station[STATION_ADDR_LEN];
> +};
names for struct types ending in _ are pretty unusual.
[]
> +/**
> + * get_decimal() - Returns the decimal value of the passed hexadecimal value
> + * @ch: The hexadecimal value that has to be converted.
> + */
> +static s32 get_decimal(u8 ch)
> +{
> + s32 ret;
> +
> + if ((ch >= '0') && (ch <= '9'))
> + ret = ch - '0';
> + else if ((ch >= 'A') && (ch <= 'F'))
> + ret = 10 + ch - 'A';
> + else if ((ch >= 'a') && (ch <= 'f'))
> + ret = 10 + ch - 'a';
> + else
> + return -1;
> +
> + return ret;
> +}
hex_to_bin
> +pch_probe(struct pci_dev *pdev, const struct pci_device_id *id)
[]
> + if (ret != 0) {
> + dev_err(&pdev->dev,
> + "%s:could not enable the pci device\n", __func__);
> + goto err_pci_en;
> + }
It seems all of the dev_<level> logging messages include __func__.
I think these __func__ uses are not particularly valuable and could
be removed.
> + /* retreive the available length of the IO memory space */
retrieve
> + if (!request_mem_region(chip->mem_base, chip->mem_size, "1588_regs")) {
> + dev_err(&pdev->dev, "%s: could not allocate register memory "
> + "space\n", __func__);
Please don't split format strings.
dev_err(&pdev->dev, "could not allocate register memory space\n");
or if you must
dev_err(&pdev->dev, "%s: could not allocate register memory space\n",
__func__);
[]
> + if (strcmp(pch_param.station, "00:00:00:00:00:00") != 0) {
> + if (pch_set_station_address(pch_param.station, pdev) != 0) {
> + dev_err(&pdev->dev,
> + "%s: Invalid station address parameter\n"
> + "Module loaded; But, station address not set "
> + "correctly\n", __func__);
dev_err(&pdev->dev,
"%s: Invalid station address parameter\n"
"Module loaded but station address not set correctly\n",
__func__);
^ permalink raw reply
* Re: Use of 802.3ad bonding for increasing link throughput
From: Chris Adams @ 2011-08-10 13:23 UTC (permalink / raw)
To: netdev
In-Reply-To: <4E427499.8060108@cyconix.com>
Once upon a time, Tom Brown <sa212+glibc@cyconix.com> said:
> So, under what circumstances would a user actually use 802.3ad mode to
> "increase" link throughput, rather than just for redundancy? Are there
> any circumstances in which a single file, for example, could be
> transferred at multiple-NIC speed? The 3 hashing options are:
It isn't going to increase the rate for a single stream. However, few
setups have only a single TCP stream going across a segment, so this is
still quite useful for real-world setups to increase the total
throughput.
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
^ permalink raw reply
* Use of 802.3ad bonding for increasing link throughput
From: Tom Brown @ 2011-08-10 12:07 UTC (permalink / raw)
To: netdev
[couldn't thread with '802.3ad bonding brain damaged', as I've just
signed up]
So, under what circumstances would a user actually use 802.3ad mode to
"increase" link throughput, rather than just for redundancy? Are there
any circumstances in which a single file, for example, could be
transferred at multiple-NIC speed? The 3 hashing options are:
- layer 2: presumably this always puts traffic on the same NIC, even in
a LAG with multiple NICs? Should layer 2 ever be used?
- layer2+3: can't be used for a single file, since it still hashes to
the same NIC, and can't be used for load-balancing, since different IP
endpoints go unintelligently to different NICs
- layer3+4: seems to have exactly the same issue as layer2+3, as well as
being non-compliant
I guess my problem is in understanding whether the 802.3/802.1AX spec
has any use at all beyond redundancy. Given the requirement to maintain
frame order at the distributor, I can't immediately see how having a
bonded group of, say, 3 NICs is any better than having 3 separate NICs.
Have I missed something obvious?
And, having said that, the redundancy features seem limited. For hot
standby, when the main link fails, you have to wait for both ends to
timeout, and re-negotiate via LACP, and hopefully pick up the same
lower-priority NIC, and then rely on a higher layer to request
retransmission of the missing frame. Do any of you have any experience
of using 802.1AX for anything useful and non-trivial?
So, to get multiple-NIC speed, are we stuck with balance-rr? But
presumably this only works if the other end of the link is also running
the bonding driver?
Thanks -
Tom
^ permalink raw reply
* Fwd: [PATCH] gianfar: reduce stack usage in gianfar_ethtool.c
From: Sebastian Pöhn @ 2011-08-10 13:11 UTC (permalink / raw)
To: Linux Netdev, wangshaoyan.pt
I was annoyed by the compiler warning for quite a long time ...
Patch seems to work. Please put version information in your email header on future patches.
Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
Reviewed-and-tested-by: Sebastian Pöhn <sebastian.poehn@belden.com>
---
drivers/net/gianfar_ethtool.c | 26 +++++++++++++++++++++-----
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 6e35069..25a8c2a 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -686,10 +686,21 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
{
unsigned int last_rule_idx = priv->cur_filer_idx;
unsigned int cmp_rqfpr;
- unsigned int local_rqfpr[MAX_FILER_IDX + 1];
- unsigned int local_rqfcr[MAX_FILER_IDX + 1];
+ unsigned int *local_rqfpr;
+ unsigned int *local_rqfcr;
int i = 0x0, k = 0x0;
int j = MAX_FILER_IDX, l = 0x0;
+ int ret = 1;
+
+ local_rqfpr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ local_rqfcr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ if (!local_rqfpr || !local_rqfcr) {
+ pr_err("Out of memory\n");
+ ret = 0;
+ goto err;
+ }
switch (class) {
case TCP_V4_FLOW:
@@ -706,7 +717,8 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
break;
default:
pr_err("Right now this class is not supported\n");
- return 0;
+ ret = 0;
+ goto err;
}
for (i = 0; i < MAX_FILER_IDX + 1; i++) {
@@ -721,7 +733,8 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
if (i == MAX_FILER_IDX + 1) {
pr_err("No parse rule found, can't create hash rules\n");
- return 0;
+ ret = 0;
+ goto err;
}
/* If a match was found, then it begins the starting of a cluster rule
@@ -765,7 +778,10 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
priv->cur_filer_idx = priv->cur_filer_idx - 1;
}
- return 1;
+err:
+ kfree(local_rqfcr);
+ kfree(local_rqfpr);
+ return ret;
}
static int gfar_set_hash_opts(struct gfar_private *priv, struct ethtool_rxnfc *cmd)
^ permalink raw reply related
* Re: [linux-firmware v2 1/2] rtl_nic: update firmware for RTL8111E-VL
From: Ben Hutchings @ 2011-08-10 12:54 UTC (permalink / raw)
To: Hayes Wang; +Cc: dwmw2, romieu, netdev
In-Reply-To: <1312978979-1808-1-git-send-email-hayeswang@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
On Wed, 2011-08-10 at 20:22 +0800, Hayes Wang wrote:
> Updated firmware with stability fixes.
> Version: rtl8168e-3_0.0.1.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> WHENCE | 2 +-
> rtl_nic/rtl8168e-3.fw | Bin 2804 -> 3264 bytes
> 2 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/WHENCE b/WHENCE
> index 4b88f1f..a463417 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -1626,7 +1626,7 @@ File: rtl_nic/rtl8168d-2.fw
> File: rtl_nic/rtl8105e-1.fw
> File: rtl_nic/rtl8168e-1.fw
> File: rtl_nic/rtl8168e-2.fw
> -File: rtl_nic/rtl8168e-3.fw
> +File: rtl_nic/rtl8168e-3.fw (Version: rtl8168e-3_0.0.1)
[...]
Please don't write the version in yet another way. It should be:
File: rtl_nic/rtl8168e-3.fw
Version: 0.0.1
Or, if you insist on duplicating the name in the version:
File: rtl_nic/rtl8168e-3.fw
Version: rtl8168e-3_0.0.1
Ben.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] Security: define security_sk_getsecid.
From: Stephen Smalley @ 2011-08-10 12:49 UTC (permalink / raw)
To: Rongqing Li; +Cc: Casey Schaufler, netdev, selinux, linux-security-module
In-Reply-To: <4E41DDEB.9040904@windriver.com>
On Wed, 2011-08-10 at 09:24 +0800, Rongqing Li wrote:
> On 08/10/2011 08:57 AM, Casey Schaufler wrote:
> > On 8/9/2011 5:43 PM, Rongqing Li wrote:
> >> On 08/10/2011 12:13 AM, Casey Schaufler wrote:
> >>> On 8/9/2011 12:28 AM, rongqing.li@windriver.com wrote:
> >>>> From: Roy.Li<rongqing.li@windriver.com>
> >>>>
> >>>> Define security_sk_getsecid to get the security id of a sock.
> >>>
> >>> Why are you requesting the secid when you're just going to
> >>> use it to get the secctx? Why not ask for that directly?
> >>> Is there ever a case where you only want the secid?
> >>>
> >> Hi:
> >>
> >> As I know, we have not method to get secctx directly.
> >
> > You are defining the method! Ask for what you want!
> >
> > The whole notion of secids is a holdover from the bad old
> > days when SELinux was a user space based enforcement mechanism.
> > The audit system was implemented when SELinux was the lone LSM
> > and unfortunately and unnecessarily propagated the use of secids.
> > If an object has a secid it must also have a secctx. The
> > interfaces that use secids could just as well use the secctx.
> > It is wasteful to create a new interface that fetches a secid
> > just to turn around and ask for the secctx in all cases.
> >
>
> Do you means I should write a method like below
> security_sk_getsecctx(struct sock *sk, char *secctx, int *len)?
>
> But secctx only is used to user. secid is used to source code to
> compute and compare the access permission.
>
> And I do not see the same method like
> security_task_getsecctx(). but security_task_getsecid() has been
> implemented in kernel source code.
Unlike Casey, I don't think secids are a bad idea or just a holdover -
we find them to be quite useful and efficient in SELinux. But in this
instance, he is correct that there is no reason to first fetch a secid
only to convert it into a context. There are other cases where you do
in fact want to avoid generating and managing the life cycle of a
security context string until you truly need it, and thus a secid makes
sense. So if you want to add a security_sk_getsecctx() hook, feel free.
There are some existing examples, e.g. security_inode_getsecctx() for
inodes, security_getprocattr() for tasks. Note that they use a slightly
different interface than what you describe above.
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Ben Hutchings @ 2011-08-10 12:48 UTC (permalink / raw)
To: Michael Guntsche
Cc: Jiri Pirko, shemminger, sebastian.belden, netdev, linux-kernel,
davem
In-Reply-To: <CAMvAeqOZ9OoV5KxTbn0+sPxJ=AkSrb__31GShVshDkX6NUXgNw@mail.gmail.com>
On Wed, 2011-08-10 at 13:51 +0200, Michael Guntsche wrote:
[...]
> Jiri, there seems to be another bug lingering in the bridge code,
> which might cause this problem in the first place but I am not really
> sure. I looked at the ethtool output some more and I noticed that some
> features were enabled on the Bridge which should be off.
[...]
That's an intentional change. There are software fallbacks for TX
checksumming and VLAN tag insertion. Bridge devices (and some other
software devices) now always advertise them so that the fallback is not
used until and unless it is known that the real output device doesn't
support the feature.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [linux-firmware v2 1/2] rtl_nic: update firmware for RTL8111E-VL
From: Hayes Wang @ 2011-08-10 12:22 UTC (permalink / raw)
To: dwmw2; +Cc: romieu, netdev, Hayes Wang
Updated firmware with stability fixes.
Version: rtl8168e-3_0.0.1.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
WHENCE | 2 +-
rtl_nic/rtl8168e-3.fw | Bin 2804 -> 3264 bytes
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/WHENCE b/WHENCE
index 4b88f1f..a463417 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1626,7 +1626,7 @@ File: rtl_nic/rtl8168d-2.fw
File: rtl_nic/rtl8105e-1.fw
File: rtl_nic/rtl8168e-1.fw
File: rtl_nic/rtl8168e-2.fw
-File: rtl_nic/rtl8168e-3.fw
+File: rtl_nic/rtl8168e-3.fw (Version: rtl8168e-3_0.0.1)
Licence:
* Copyright © 2011, Realtek Semiconductor Corporation
diff --git a/rtl_nic/rtl8168e-3.fw b/rtl_nic/rtl8168e-3.fw
index cb494071d0273c7b3102b97552f4bc7b756c0e17..43d1b8641fb09d2f8dd91998ed78c1deb7c71a7a 100644
GIT binary patch
literal 3264
zcmaKvYiyKd7RR4XJEv1F2Cx-|%P_rAM4+9iSgT*G$Qn#^V@Nhxb+hmRKA3FcMoAX$
zr$R?<l^E|avDV%FqB0d(q94pMd@!2qCYvonBD=bIr?%kknwf+^%cW)foq68TS3{iS
z&3T^loXh{*p7$N+oO^Kh@A|U6eY-YZzdh5H>B^=vz1=-M-PtT>_Pd*BdA)N<x9!f}
zo@{3G_HDP`wf(jScJA7q&1QPDnRIs3%{_fLXEW{v=T@s*=G3_sS1G$R^r+kFv=M%{
zOTl-)uX8SNZlwvO)x}14I@611YPu%d{v+9?4xO|^wmFoIBQsrzt2(LLHhHPPMjLtF
zcP+Z3KdA?yZckD_F#1GN4?zz;nAE@6{>h{sw*5m%t*dL%xJzn1v>qCV&SjD+(3v-r
z+6euWJ+V}MIDEt`&hXjMy0nU+9}Ep{nI3OirVjs;MiWUrYqXNohIyXfY;-|VJB-5L
zZFCyB<^H^31r)tzqjSg^#oi{P=xqu4FB?U#iX(!-fx&pu962RdG0~Z=q5(OZsfg;R
z=oq}%v}jA6Xq~OwL`OAT-y(VseAA2lRrFu*hXc{#GosH9Ba>oZ6ip4mLvA?Ad(QKo
zkMj0o8@bP%=*MHC1II-tkBPpB%<z=x_)DUNdeQbl(HrqO-p(G{8SYE$6FJcmGV_e?
z5M5*xdy7MQ1T3XS^o%|v`U=!+JcAGSt>`;R(HB^kE(rbObuAa;myyHH@~CgHt_t@J
z_zupC4xyXQqu1=$F?8NoO&kI7c8ac@WL+W#){|4Bvuj1qH~75epBHUTv*z5f9zti&
zy`m$;6KfLvcU<%-%k`t8*&fk`S?_ay=yQ4%Hqp2JfXV$v^zZ9MH`;og=wa+M*!mUG
zzjcZ3v-M}957hkc7oFcK+Dg5L!5L$}iL({R1>bnPZNxSWj>$H^w|eK1OAvp1L~ms_
zjES>&hiFH57O*#bYif4Z{KO7<>5SMpw=rUeT&<0qJ!0{YgA3%nd=ZTIi#{FZ;@B=<
zum5(7_JTi!UV+%oh5H5UQ;R+Ce3ZAu^DaesS9{)T)X{8Jb*Zn}OAkhP*MI@ubM#aU
z*|rgCc#8bc>&@gNL(FA-{u&!23*gg-iC*~BxZy44WgNXRY7gx$us%ahZxnsCEILR3
z)nfezv0A(riMNg!Is7ZIaK0hLa)8+8Un@FjHmLhFKCV5$EZ>3LPSJG{x%-fF|MY!z
zU<b7Vf1AmIvG7aLPpEJ1i0Com{eoUN$$T{OB){bOia95S^0T79#cqZ5u7&h7eV1~g
zU*0bI6|#qTj!%FUUJaAQwTf5+Y!^NuKRM!K){|fGoJ1E}rfa^=9s(nA+WZ-IoBhl5
zo8{$G;<ntx>4S+2qW=SL@U`f@|EEsaNYNvw(joseXYglDrik90pS=LR0s5wsxP#?>
z-D+!M9<+Y4^;Le|ZtH~avkumlr&5pT%1J2sSp}VdJ{IB#9vAHk{pD|Bmbyf5q7TN&
zQ=v}u1o^gjV#IUoDe6W}`a-)g5nZxZbT8*~)+5ANq}R{VU)8xAAns1;#re#i!9^`C
zj#li);@oA}TsITSlD9Z{Xg1mRki9O9CzL(CM09;k_Gx50yx*A*MW;4+pSAm@nk&;I
zw^QJ+VQFG*ch-TkqV@P{$5-%rm_y`)CU3`bYr2=1tEw*8n!x(KZX0o%E<JAZ+!4{W
z{G0B_d#{|21o_wthCIC#TSMP73pIT6z_*XH>3O_o)^bjc*456zkN~q`$bZ8bve!k=
zz-M+wkum@4YiHytL9TLk24*|kz}e80=-cEW;ru+e+AN;%^K5y{mEa@){oRk9RK!jk
zJ*)fJ1a{9+kGgPwhW&i@oZ0<7MqiHN)A5+yi}c6+%!Qqmh(E?$mC?QYsy{Dr-UQFy
zOZV;byhZe!Gn_y3*t^Z%t+}G;YU((G&Bel=ILFvq@0+h#_!iSeX3B6BF5v_I!>k=O
zu{ln)!3W>B-M;q=?V@Ms1-n}plDm6;0p``r|7-aCT=XSoatU|MAD4>$2ixU}k7qWV
z-<q!yz6`?&a-qbMBj;t4e;9w*ypq2>{$lh(Wsi?-1-<buF_gQw>+tW;T|WYr0s7c#
z*yC$hy{n07!6MOv-02I+eF54%82L5<Lv3&0CWg)Ki>tvj{3p@R4-=RAxbjzs%kCw+
zf9zcuY~{XV?uUxpErtu*H-Kx%`iR<ADSYeS;t{YQo0|~*8hrNcW4X;+9@Ad7KGgXL
zooX*4SEa<Tn0`3b;=i48r@;)b#GM!YmYTzV^*)0Bp<lEgTmd!eX%oGhb#XU2-NH9v
z0H1noJBkfkp9JrnqMM6xi^0Cz7eSBq|72hLK6T;$fl9?W6w>y8p!SV#{{uGL|A2P?
OJ^RD|0{iy%zwZF4*F!x3
literal 2804
zcmaKuS!|S56vyvuXDEwdX=z8WolZ+xrAP=!Vq#-Nc`(M9m<Srf13vJiQ4@-BIfa&`
zMS>d`6R?UeXp0DaGtxc~Ow<@#AOWSxH%JAQw21-A(sulv@B5~F;_~q2-gE9*{^x(s
zJu}W#sjG16T$w8jxh!jsTkSNBzTQ=$cQ3}A^PHP)Mp<?7_Vv!~b}qHVg}!E6^Ecaa
zhfmgFTN>J?u(?)9sXFmvo4q7vYMSp0SElP4GJ2TRHD>fnTi?j&5!S;mW%Q`YZ)UX1
z<d-uVi<N20Wi-K>U`?@(F3G5{4)4oon)L)SwfH$4IpT&j{MJ>M`xqL)kaQJVo32nd
zmeFOlj%KvBf^`JhR%G8V;^Xi!U9={r)D{;VUM=cT<8VP#+eHtdi(eBhi;2c;pA)Sw
z?jICg!`}SjJ4FwwXqzXR-!8hN4f{&uyl7=BI_%n_I_ypNR#dl3v>n|y<p1iBXwxat
z3;RXi!KQ6MwD(=n?u6*u&7v#F*;|9m`d%mxB1?<tAT|?NyVr?s$Jbp3TSjy@`@tK+
zJ+hL+YU~}uj{Wv%Ov4(=Nn(1}1Dx4T{7QqpakQ4Y5{;rIU`!bYKZ`!FS#&A;k^4li
zCyC>Uc2d{fS<x&!wq3vud0vy~Li71fbpE}>v3-~5`}i!j{kNhoMEoaJi&jVcmvJ@=
zJMWU{F6zpG?OF=Ha)DgTI|2MP5x?2sDxRfkMQg(|4@?$kPBG4$JL1%d)<xo61@m~E
zxuSC;XRpG4azyk7ybaw1;|9@f#5Vr=o)7r`tzL9F_$%@2rnal0JQ=xiTA;fg)lCm{
zx1zckfo^YA5X<-Fek|Uu=7?@47|`wHzT(*CxUbe<xfgn{6h4-KYlxgrgJ=I_^lAEM
zIr_EK@ezI8iy!^ySnIpl{|TonME4Adj?zEHT7RHctM?}L#^~Lyr@+Gbhar|uYI}5^
zXtTxG%YBh!UWe$9&mhxJ)tmW{JGe)CXOEN9!}i#5aBd|}pJ?U`-&xUfVC<)-(|kL2
zh^_}q`Z>`l1<_~W*uniHmDrx+>lZzL1Ra>VW1@S(WAEn>y>aXw(c|>!R`T@0-I=85
z*)VR=_XxR8UBMrWMeJ7p5Vei%;X6UUk8<DO_Rfp`^1J9C#7x6q0zR|g@ZkGmsP{O_
z(;uU(N%I4%^-@O@@1*YbzLY!j^(~@zWpD4Tr+xi4c&g>S!PA97V$BX$YVvWsCi*&Y
z{e1U}u4KQMyY8F?Pb-6at+u;39o*+;<AfR0F$o>^LR{0uPx98b1U1^5Zp{-DKAPz1
zI^xBt`_mkEIUL~Xq>dEWYw#UDi0ypQmazZL_H%e%P_(7C6!lCu+l$yP4Bkp@7<VIi
z7h&5vKz?$L&lGYb;Hnxwk2AwkjgMC%dWAmE(ns-x=m*3$t~$w60*9^aJBX72-wgA;
z6=180_~t_2o4h&S7oJPtdEA$nTksu$-+$x7n?Nst+n*(tgPtG9H&JwAb1*Mb?Ysdy
zkMLu@m%wke_-6|u_&Cc_XQJpA;mZ6RH5ShX76m-GkD2kD*^EC;&DQrL;2-23%|40V
z=DW=&<J_ZHP4CEIcXfa|uF?mwP(F%02{|6hUn3`wE$@g6_^=re-@u#UtYr{i^foI-
zcrV76=^SsW*|5;FzRu%K2ycemu_}6Rzvuun$>b#Qi*bsx#&X;uM+^NsM4Y}&<Redx
zFHQ~qoVpzJ^$hEAW|qyHRZ~Q()-VIWbF!cJ1~>im{8Vz-`~JVLoPJ1tB3k(VpR;cq
z549yM4sWVk$qW8X<XXk|Uzp~?dm}aE3&HPpjQ6?tvjF3!v&>}THF4M7;BBXOiog9s
zF>vEIZ8AI_W~DZNKJ5$Yws{?ujYFHW#^(WkJG!`Y<!z7G1&-)U&tto>L9`)HUyyrg
zPV@=(`B&iJVbPyF^k9Cnhkmj>Slwfy59L$Fqy2}R%G%R#hg|&c<--4_g@POZZ(97n
VdHX+Uxf?6kf6?+D|9>1#e*sYqwB!H)
--
1.7.3.2
^ permalink raw reply related
* [linux-firmware v2 2/2] rtl_nic: add new firmware for RTL8111F
From: Hayes Wang @ 2011-08-10 12:22 UTC (permalink / raw)
To: dwmw2; +Cc: romieu, netdev, Hayes Wang
In-Reply-To: <1312978979-1808-1-git-send-email-hayeswang@realtek.com>
Add new firmware:
1. rtl_nic/rtl8168f-1.fw
version: rtl8168f-1_0.0.1
2. rtl_nic/rtl8168f-2.fw
version: rtl8168f-2_0.0.1
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
WHENCE | 2 ++
rtl_nic/rtl8168f-1.fw | Bin 0 -> 2928 bytes
rtl_nic/rtl8168f-2.fw | Bin 0 -> 256 bytes
3 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 rtl_nic/rtl8168f-1.fw
create mode 100644 rtl_nic/rtl8168f-2.fw
diff --git a/WHENCE b/WHENCE
index a463417..7290828 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1627,6 +1627,8 @@ File: rtl_nic/rtl8105e-1.fw
File: rtl_nic/rtl8168e-1.fw
File: rtl_nic/rtl8168e-2.fw
File: rtl_nic/rtl8168e-3.fw (Version: rtl8168e-3_0.0.1)
+File: rtl_nic/rtl8168f-1.fw (Version: rtl8168f-1_0.0.1)
+File: rtl_nic/rtl8168f-2.fw (Version: rtl8168f-2_0.0.1)
Licence:
* Copyright © 2011, Realtek Semiconductor Corporation
diff --git a/rtl_nic/rtl8168f-1.fw b/rtl_nic/rtl8168f-1.fw
new file mode 100644
index 0000000000000000000000000000000000000000..a0dd2e5dec0a73968b26e0d81b4542240dbc719d
GIT binary patch
literal 2928
zcmbuBdx+Fk6vyw(I>$BBd~Le9uCou{kDb|YUG1OMD2%K`h{z;^G!TTMj8rs^u8TUG
zB3VWRvKa)4vxEqRfxC)i`bYQ*l(c@U>w}V60^3#Fb^4sSzgfrdzXmS%ywCTXd+z;>
zbI!fHdR2Y0uKukV$z_R|iJ8fGqP`}Xs7WT#*>4f+c+|NKZt=pp+S<gtWsB#%u<Yr#
zm#<isOeSVMnTRKob8GA7CTF{y&W%?$#;J29F5Bhe?CoxW(}BoqTsd<0PQ<yuxiT|~
ztBbZQcjgyM<bBPy>H*s^4xhNgc2sB^!=^hMQ+1MyZT3?1xDI4}5-HIQ4W)!H$;lit
zi(TmB6yK<5&jQha7(H20Z4qrn7VQ=t6A_IVJwbG*hV*>VrO3@Mnif5Yyg3l<*ebfM
z8JlwW4$<-yGVGcQWgmIj_CnbX(H88EJJBCnMK_-l?W`017@Ov+qM2QyKM^ZaL@wLk
z5N)>|`y=6g*!F><ZMMHB`YC%G__h+m-4y+%6#UScJ3_y_uhn|`9(Kg}eY0pi_NO<%
zgXMC_4}cGDi>C06Q)_0Fr=$2h9|vbZJrhMIbwX!EtDrl<+&fA1_5k0P^mfrv*fyhg
z&?$V@ED_y9J<&m;H)5h2t(Px}uBsIs(Cc&V2y=FiBPRaF*O(nX-%b^sZuC&mL&O<i
z^cSLk%@A!g8r<*a^Y0KHTp?P)c{YPH3V*6mv<$o8b04>o+PaI$Q|b9xrhC)VRe4>N
z=aZ&;#naWM1Ak|==WPzs#E(r7oe<^=;0^o4d>ndY{0xgz=IKfKIP}eQMd*6f_b}kh
zHk$u_?4R&-h0&Zv6Y{vxLp@z(G<9r2UJY$?oS~;>)SaOp<Jd2=uLoyvg+-t0jqU*V
z9MQ2eMdyI!^bkJ>>ni<RSU<nsNFQ6_!?;lqy@G5LIr=91bL(JMZZUhgKA?+I>*SvM
ze5^vW68j!{5=;s4lP^jSzo(w5dD|v>NWVvz?JaDlg*An?A8z9Ou}xj2Pw4w+jhv30
z`TT>(XY;lno1(bSZ8himMy!BYGQ8H$Xpv|!7;?VkA4L9s-%8PuU<tTmx!xA|TF=e5
z5ll9_5AA`?0yxs(djw34(A_t=_nf!YJ|(XwZ!tJ6Z~6v0Y^N6Lz+`b+u(6!e^13bf
zReQgdqh2>1o%QESYA<&5<uvuTp<5@qq26OnWsqav-#_A%7sQF-XXo3xkDPyVCXtXo
z1V0!aT~2=t9z2d^J-EvptnBi-%&($H>2Vjn_jY@I2K@<S_Kpm1^fG&A?43(>h>kzO
z`+)s$X3T16g}3>&IK9XX?_KVN<!Jjy^ceEB(C!TD95qxT2U~T*&u<%No*n7wA&W#`
zeFi+^MK66uZ_bMD;$DroB)WIB=x@aC;%zjny?qbn%8<)2{6d}f%}LSEE^6;uOFm*g
zEMJ;@QO-HL#@9CXr070s=;E$jAiu+R+8(fM<n6cf;oR+fBAi#0njRg-dpBHk2z_m1
zzq;Aik$bDbkmobhXxQw|kEDj?uSCxtq%QS!r5{q4y)AYZCfGbL5Z#Tx^?$wLBK9nB
z<z|Fl<aXpXn;nP2Vz!rg1KRy}Xf}D%tH~Glwnd@OcjjYrhFxwy!nwAJUMun6vD9@i
zBg+&&_+9IB56)5?AH(#2RuF)l7!h`Ra|7PS2I`OZ(63HvY7k8zvu~lDTg7B-%qI@b
zZr{LQOz6|?eKPnwMT~%%NrnCEgm>5n%x>Y_-(kjozKe`?cO^KO)q^jSm+x>n-vZ0K
zpS**~TV}H`R&)`wFxlSR=dfGO8(m=c8g}j!b7OwTxQ`XwakGVQdy#tqh9=JH3|P-|
z{ufI5pTsJ?$YS2N4Ft<J(btKag<dg)d0z?^CwlQ&W)j;2taF#aiY$-G=5rk95!f7%
zx4Vh6;_j86XI;RTSmtZFZXEz4b=v=oJobCc>TYKHN9yil#d`TJ-4Xo*y!KsM@+Wgo
zjB@VTwRkAMjt+UR*)XGh+)YPK4bUAQh%RnmhD=9(w@`F`N6co${xc3^Z*TYypZ_oD
z!vCV#taCWT?Z0UL|K<Jvprc(h7iV<4`4zDq+dBwzPp4`l{j_tX?q1gZr<P(nETo4)
K^Pf1kock9M(ey3=
literal 0
HcmV?d00001
diff --git a/rtl_nic/rtl8168f-2.fw b/rtl_nic/rtl8168f-2.fw
new file mode 100644
index 0000000000000000000000000000000000000000..f8b48c3b5d4d4a040dc9703235bce4799c1fb106
GIT binary patch
literal 256
zcmY+7!3qIU6ox+}+gXsA61S`@n0u~FlO48{Y%OMkl_Gh7c?3&KkK$3hfj7XpBKhld
zPXGV?9e~4en@W;yx-PRl+Y@8cSZpk!nb%yWqqAf&O`NmiY%!W;lig~aiP)rXjmXd?
zLpR_At(=e?YCP{4-B-@!74>79>a#Dv4H_OYImOEg-z(d1*R$<EHbgrHWvd_d$J8l8
a0QIZym;8Ss9#79l>II)Wc<1jQ{PY6x_bUMa
literal 0
HcmV?d00001
--
1.7.3.2
^ permalink raw reply related
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Jiri Pirko @ 2011-08-10 11:59 UTC (permalink / raw)
To: Michael Guntsche
Cc: shemminger, sebastian.belden, netdev, linux-kernel, davem
In-Reply-To: <CAMvAeqOZ9OoV5KxTbn0+sPxJ=AkSrb__31GShVshDkX6NUXgNw@mail.gmail.com>
Wed, Aug 10, 2011 at 01:51:54PM CEST, mguntsche@gmail.com wrote:
>On Wed, Aug 10, 2011 at 1:19 PM, Jiri Pirko <jpirko@redhat.com> wrote:
>> Wed, Aug 10, 2011 at 12:30:16PM CEST, mguntsche@gmail.com wrote:
>>>On Wed, Aug 10, 2011 at 11:59 AM, Michael Guntsche <mguntsche@gmail.com> wrote:
>>><snip>
>>>>>>Offload parameters for lan_wire:
>>>>>>rx-checksumming: off
>>>>>>tx-checksumming: off
>>>>>>scatter-gather: off
>>>>>>tcp-segmentation-offload: off
>>>>>>udp-fragmentation-offload: off
>>>>>>generic-segmentation-offload: off
>>>>>>generic-receive-offload: on
>>>>>>large-receive-offload: off
>>>>>>rx-vlan-offload: off
>>>>>>tx-vlan-offload: off
>>>>>>ntuple-filters: off
>>>>>>receive-hashing: off
>>>>>>
>>>>>>The Bridge device on the other hand....
>>>>>>
>>>>>>Offload parameters for lan:
>>>>>>rx-checksumming: on
>>>>>>tx-checksumming: on
>>>>>>scatter-gather: off
>>>>>>tcp-segmentation-offload: off
>>>>>>udp-fragmentation-offload: off
>>>>>>generic-segmentation-offload: off
>>>>>>generic-receive-offload: on
>>>>>>large-receive-offload: off
>>>>>>rx-vlan-offload: off
>>>>>>tx-vlan-offload: on
>>>>> ^^^^^^^^^^^^^^^^^^^ is this gfar?
>>>> No the "Lan" nic is the bridge itself. The gfar in question is lan_wire.
>>>>
>>>> /Michael
>>>>
>>>
>>>Ok I would have saved hours of bisecting if I had just used the -e
>>>switch with tcpdump from the beginning.
>>>Jiri first of all the patch makes the connection work again. I can
>>>ping the client on the wlan from the server and vice-versa. Taking a
>>>look at the tcpdump (WITH -e) makes it obvious why it fails with the
>>>non patched version...
>>>
>>>This is a capture from the gfar lan port on the bridge with no patch applied
>>>12:13:24.011492 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
>>>(oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 19, p 0,
>>>ethertype IPv4, gibson.comsick.at > 192.168.42.55: ICMP echo request,
>>>id 23567, seq 74, length 64
>>>
>>>As you can see we get a VLAN package????
>>
>> Ugh, this is what I expected. Patch to fix:
>>
>> Subject: [patch net-2.6] gianfar: prevent buggy hw rx vlan tagging
>>
>> On some buggy chips, "vlan tag present" flag is set which causes packet
>> loss. Fix this by checking if rx vlan accel is enabled in features.
>>
>> Reported-by: Michael Guntsche <mguntsche@gmail.com>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>> ---
>> drivers/net/gianfar.c | 9 +++++++--
>> 1 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
>> index 2659daa..31d5c57 100644
>> --- a/drivers/net/gianfar.c
>> +++ b/drivers/net/gianfar.c
>> @@ -2710,8 +2710,13 @@ static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
>> /* Tell the skb what kind of packet this is */
>> skb->protocol = eth_type_trans(skb, dev);
>>
>> - /* Set vlan tag */
>> - if (fcb->flags & RXFCB_VLN)
>> + /*
>> + * There's need to check for NETIF_F_HW_VLAN_RX here.
>> + * Even if vlan rx accel is disabled, on some chips
>> + * RXFCB_VLN is pseudo randomly set.
>> + */
>> + if (dev->features & NETIF_F_HW_VLAN_RX &&
>> + fcb->flags & RXFCB_VLN)
>> __vlan_hwaccel_put_tag(skb, fcb->vlctl);
>>
>> /* Send the packet up the stack */
>> --
>> 1.7.6
>>
>>
>
>Jiri, there seems to be another bug lingering in the bridge code,
>which might cause this problem in the first place but I am not really
>sure. I looked at the ethtool output some more and I noticed that some
>features were enabled on the Bridge which should be off.
>
>With 3.1-rc1
>Offload parameters for lan (This is the bridge interface itself):
>rx-checksumming: on <---- ON
>tx-checksumming: on <---- ON
>scatter-gather: off
>tcp-segmentation-offload: off
>udp-fragmentation-offload: off
>generic-segmentation-offload: off
>generic-receive-offload: on
>large-receive-offload: off
>rx-vlan-offload: off
>tx-vlan-offload: on <---- ON
>
>I booted an older kernel on the same hardware (2.6.39) and the output differs.
>
>Offload parameters for lan:
>rx-checksumming: off
>tx-checksumming: off
>scatter-gather: off
>tcp-segmentation-offload: off
>udp-fragmentation-offload: off
>generic-segmentation-offload: off
>generic-receive-offload: off
>large-receive-offload: off
>rx-vlan-offload: off
>tx-vlan-offload: off
>ntuple-filters: off
>receive-hashing: off
>
>As you can see all the values are OFF which is correct, since no
>attached interface supports these features.
>Is it possible that this is tripping up the now changed gianfar code somehow?
>What I am trying to say. Could it be that your patch is hiding a
>problem that is now surfacing with a change in the bridge code?
Well this seems unrelated. The problem is that gianfar hw is indicating
it received vlan tagged packet even in case it did not.
>
>I am thinking about this commit:
>c4d27ef95: bridge: convert br_features_recompute() to ndo_fix_features
>
>Of course this could also be a totally separate bug as well.
>
>Any thoughts, Dave, Stephen?
>
>Kind regards,
>Michael Guntsche
^ permalink raw reply
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Michael Guntsche @ 2011-08-10 11:51 UTC (permalink / raw)
To: Jiri Pirko; +Cc: shemminger, sebastian.belden, netdev, linux-kernel, davem
In-Reply-To: <20110810111947.GC1909@minipsycho.brq.redhat.com>
On Wed, Aug 10, 2011 at 1:19 PM, Jiri Pirko <jpirko@redhat.com> wrote:
> Wed, Aug 10, 2011 at 12:30:16PM CEST, mguntsche@gmail.com wrote:
>>On Wed, Aug 10, 2011 at 11:59 AM, Michael Guntsche <mguntsche@gmail.com> wrote:
>><snip>
>>>>>Offload parameters for lan_wire:
>>>>>rx-checksumming: off
>>>>>tx-checksumming: off
>>>>>scatter-gather: off
>>>>>tcp-segmentation-offload: off
>>>>>udp-fragmentation-offload: off
>>>>>generic-segmentation-offload: off
>>>>>generic-receive-offload: on
>>>>>large-receive-offload: off
>>>>>rx-vlan-offload: off
>>>>>tx-vlan-offload: off
>>>>>ntuple-filters: off
>>>>>receive-hashing: off
>>>>>
>>>>>The Bridge device on the other hand....
>>>>>
>>>>>Offload parameters for lan:
>>>>>rx-checksumming: on
>>>>>tx-checksumming: on
>>>>>scatter-gather: off
>>>>>tcp-segmentation-offload: off
>>>>>udp-fragmentation-offload: off
>>>>>generic-segmentation-offload: off
>>>>>generic-receive-offload: on
>>>>>large-receive-offload: off
>>>>>rx-vlan-offload: off
>>>>>tx-vlan-offload: on
>>>> ^^^^^^^^^^^^^^^^^^^ is this gfar?
>>> No the "Lan" nic is the bridge itself. The gfar in question is lan_wire.
>>>
>>> /Michael
>>>
>>
>>Ok I would have saved hours of bisecting if I had just used the -e
>>switch with tcpdump from the beginning.
>>Jiri first of all the patch makes the connection work again. I can
>>ping the client on the wlan from the server and vice-versa. Taking a
>>look at the tcpdump (WITH -e) makes it obvious why it fails with the
>>non patched version...
>>
>>This is a capture from the gfar lan port on the bridge with no patch applied
>>12:13:24.011492 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
>>(oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 19, p 0,
>>ethertype IPv4, gibson.comsick.at > 192.168.42.55: ICMP echo request,
>>id 23567, seq 74, length 64
>>
>>As you can see we get a VLAN package????
>
> Ugh, this is what I expected. Patch to fix:
>
> Subject: [patch net-2.6] gianfar: prevent buggy hw rx vlan tagging
>
> On some buggy chips, "vlan tag present" flag is set which causes packet
> loss. Fix this by checking if rx vlan accel is enabled in features.
>
> Reported-by: Michael Guntsche <mguntsche@gmail.com>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> ---
> drivers/net/gianfar.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 2659daa..31d5c57 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -2710,8 +2710,13 @@ static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
> /* Tell the skb what kind of packet this is */
> skb->protocol = eth_type_trans(skb, dev);
>
> - /* Set vlan tag */
> - if (fcb->flags & RXFCB_VLN)
> + /*
> + * There's need to check for NETIF_F_HW_VLAN_RX here.
> + * Even if vlan rx accel is disabled, on some chips
> + * RXFCB_VLN is pseudo randomly set.
> + */
> + if (dev->features & NETIF_F_HW_VLAN_RX &&
> + fcb->flags & RXFCB_VLN)
> __vlan_hwaccel_put_tag(skb, fcb->vlctl);
>
> /* Send the packet up the stack */
> --
> 1.7.6
>
>
Jiri, there seems to be another bug lingering in the bridge code,
which might cause this problem in the first place but I am not really
sure. I looked at the ethtool output some more and I noticed that some
features were enabled on the Bridge which should be off.
With 3.1-rc1
Offload parameters for lan (This is the bridge interface itself):
rx-checksumming: on <---- ON
tx-checksumming: on <---- ON
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: off
tx-vlan-offload: on <---- ON
I booted an older kernel on the same hardware (2.6.39) and the output differs.
Offload parameters for lan:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
rx-vlan-offload: off
tx-vlan-offload: off
ntuple-filters: off
receive-hashing: off
As you can see all the values are OFF which is correct, since no
attached interface supports these features.
Is it possible that this is tripping up the now changed gianfar code somehow?
What I am trying to say. Could it be that your patch is hiding a
problem that is now surfacing with a change in the bridge code?
I am thinking about this commit:
c4d27ef95: bridge: convert br_features_recompute() to ndo_fix_features
Of course this could also be a totally separate bug as well.
Any thoughts, Dave, Stephen?
Kind regards,
Michael Guntsche
^ permalink raw reply
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Jiri Pirko @ 2011-08-10 11:19 UTC (permalink / raw)
To: Michael Guntsche
Cc: shemminger, sebastian.belden, netdev, linux-kernel, davem
In-Reply-To: <CAMvAeqM-oH1UzxEp9PgO6ZP-AKtqosuMg5za25_X8DpPJMDX2w@mail.gmail.com>
Wed, Aug 10, 2011 at 12:30:16PM CEST, mguntsche@gmail.com wrote:
>On Wed, Aug 10, 2011 at 11:59 AM, Michael Guntsche <mguntsche@gmail.com> wrote:
><snip>
>>>>Offload parameters for lan_wire:
>>>>rx-checksumming: off
>>>>tx-checksumming: off
>>>>scatter-gather: off
>>>>tcp-segmentation-offload: off
>>>>udp-fragmentation-offload: off
>>>>generic-segmentation-offload: off
>>>>generic-receive-offload: on
>>>>large-receive-offload: off
>>>>rx-vlan-offload: off
>>>>tx-vlan-offload: off
>>>>ntuple-filters: off
>>>>receive-hashing: off
>>>>
>>>>The Bridge device on the other hand....
>>>>
>>>>Offload parameters for lan:
>>>>rx-checksumming: on
>>>>tx-checksumming: on
>>>>scatter-gather: off
>>>>tcp-segmentation-offload: off
>>>>udp-fragmentation-offload: off
>>>>generic-segmentation-offload: off
>>>>generic-receive-offload: on
>>>>large-receive-offload: off
>>>>rx-vlan-offload: off
>>>>tx-vlan-offload: on
>>> ^^^^^^^^^^^^^^^^^^^ is this gfar?
>> No the "Lan" nic is the bridge itself. The gfar in question is lan_wire.
>>
>> /Michael
>>
>
>Ok I would have saved hours of bisecting if I had just used the -e
>switch with tcpdump from the beginning.
>Jiri first of all the patch makes the connection work again. I can
>ping the client on the wlan from the server and vice-versa. Taking a
>look at the tcpdump (WITH -e) makes it obvious why it fails with the
>non patched version...
>
>This is a capture from the gfar lan port on the bridge with no patch applied
>12:13:24.011492 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
>(oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 19, p 0,
>ethertype IPv4, gibson.comsick.at > 192.168.42.55: ICMP echo request,
>id 23567, seq 74, length 64
>
>As you can see we get a VLAN package????
Ugh, this is what I expected. Patch to fix:
Subject: [patch net-2.6] gianfar: prevent buggy hw rx vlan tagging
On some buggy chips, "vlan tag present" flag is set which causes packet
loss. Fix this by checking if rx vlan accel is enabled in features.
Reported-by: Michael Guntsche <mguntsche@gmail.com>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/gianfar.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 2659daa..31d5c57 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2710,8 +2710,13 @@ static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
/* Tell the skb what kind of packet this is */
skb->protocol = eth_type_trans(skb, dev);
- /* Set vlan tag */
- if (fcb->flags & RXFCB_VLN)
+ /*
+ * There's need to check for NETIF_F_HW_VLAN_RX here.
+ * Even if vlan rx accel is disabled, on some chips
+ * RXFCB_VLN is pseudo randomly set.
+ */
+ if (dev->features & NETIF_F_HW_VLAN_RX &&
+ fcb->flags & RXFCB_VLN)
__vlan_hwaccel_put_tag(skb, fcb->vlctl);
/* Send the packet up the stack */
--
1.7.6
^ permalink raw reply related
* Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
From: Marc Kleine-Budde @ 2011-08-10 11:09 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list,
Wolfgang Grandegger
In-Reply-To: <1312945564-6626-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1049 bytes --]
On 08/10/2011 05:05 AM, Robin Holt wrote:
> With all the patches applied, my p1010rdb works for communicating between
> its two can ports and also can communicate with an external PSOC. I have
> done no testing beyond compile testing on an arm system as I have no
> access to an arm based system.
>
> For the first three patches in the series, I believe they are all ready
> for forwarding to David S. Miller for the netdev tree. I think patch
> 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed
> from the previous post by adding a second compatible string for the
> fsl,p1010_flexcan.
This patch series is working on phytec's pcm043 (mx35) based on current
net-next. Feel free to add my Acked-by to all patches.
good work,
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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Michael Guntsche @ 2011-08-10 10:30 UTC (permalink / raw)
To: Jiri Pirko; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <CAMvAeqO2bLaPwmdW+c+7hz-ec=-tF6Z0EFBv=FA7+rU_QZ_wDA@mail.gmail.com>
On Wed, Aug 10, 2011 at 11:59 AM, Michael Guntsche <mguntsche@gmail.com> wrote:
<snip>
>>>Offload parameters for lan_wire:
>>>rx-checksumming: off
>>>tx-checksumming: off
>>>scatter-gather: off
>>>tcp-segmentation-offload: off
>>>udp-fragmentation-offload: off
>>>generic-segmentation-offload: off
>>>generic-receive-offload: on
>>>large-receive-offload: off
>>>rx-vlan-offload: off
>>>tx-vlan-offload: off
>>>ntuple-filters: off
>>>receive-hashing: off
>>>
>>>The Bridge device on the other hand....
>>>
>>>Offload parameters for lan:
>>>rx-checksumming: on
>>>tx-checksumming: on
>>>scatter-gather: off
>>>tcp-segmentation-offload: off
>>>udp-fragmentation-offload: off
>>>generic-segmentation-offload: off
>>>generic-receive-offload: on
>>>large-receive-offload: off
>>>rx-vlan-offload: off
>>>tx-vlan-offload: on
>> ^^^^^^^^^^^^^^^^^^^ is this gfar?
> No the "Lan" nic is the bridge itself. The gfar in question is lan_wire.
>
> /Michael
>
Ok I would have saved hours of bisecting if I had just used the -e
switch with tcpdump from the beginning.
Jiri first of all the patch makes the connection work again. I can
ping the client on the wlan from the server and vice-versa. Taking a
look at the tcpdump (WITH -e) makes it obvious why it fails with the
non patched version...
This is a capture from the gfar lan port on the bridge with no patch applied
12:13:24.011492 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
(oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 19, p 0,
ethertype IPv4, gibson.comsick.at > 192.168.42.55: ICMP echo request,
id 23567, seq 74, length 64
As you can see we get a VLAN package????
With the patched version:
12:16:33.756966 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
(oui Unknown), ethertype IPv4 (0x0800), length 98: gibson.comsick.at >
192.168.42.55: ICMP echo request, id 23669, seq 2, length 64
12:16:33.843289 b4:07:f9:70:b7:c1 (oui Unknown) > 00:13:d4:4f:a2:dc
(oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.42.55 >
gibson.comsick.at: ICMP echo reply, id 23669, seq 2, length 64
No VLAN and I get my replies.
All that is left to do now is to find out why the current driver
thinks that it is on a VLAN when it isn't.
Any ideas Jiri?
Kind regards,
Michael
^ permalink raw reply
* Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
From: Marc Kleine-Budde @ 2011-08-10 10:24 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list,
Wolfgang Grandegger
In-Reply-To: <20110810101113.GN4926-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1317 bytes --]
On 08/10/2011 12:11 PM, Robin Holt wrote:
> On Wed, Aug 10, 2011 at 12:01:58PM +0200, Marc Kleine-Budde wrote:
>> On 08/10/2011 05:05 AM, Robin Holt wrote:
>>> With all the patches applied, my p1010rdb works for communicating between
>>> its two can ports and also can communicate with an external PSOC. I have
>>> done no testing beyond compile testing on an arm system as I have no
>>> access to an arm based system.
>>>
>>> For the first three patches in the series, I believe they are all ready
>>> for forwarding to David S. Miller for the netdev tree. I think patch
>>> 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed
>>> from the previous post by adding a second compatible string for the
>>> fsl,p1010_flexcan.
>>
>> One remark for the subjects. It seems no one is using "[$subsystem]"
>> anymore, but rather "$subsystem:".
>
> I will, one day, get these patches subject lines correct ;)
>
> Did you happen to get a chance to test the patches on arm?
It's still compiling...
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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* RE: [PATCH net-next 0/6] be2net: fixes
From: Sathya.Perla @ 2011-08-10 10:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1312906987.2371.51.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
>From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>Sent: Tuesday, August 09, 2011 9:53 PM
>> >
>>
>> Not sure which recent be2net patch is problematic on 32bit arches :
>>
>> Kernel: arch/x86/boot/bzImage is ready (#280)
>> Building modules, stage 2.
>> MODPOST 1854 modules
>> ERROR: "__udivdi3" [drivers/net/benet/be2net.ko] undefined!
>> make[1]: *** [__modpost] Erreur 1
>> make: *** [modules] Erreur 2
>>
>> Please fix this, thanks.
>>
>>
>
>Comes from commit ac124ff973e27802797
>(be2net: cleanup and refactor stats code)
>
>be_rx_eqd_update() now performs u64 divides.
>
>Following patch should be enough, there is no way packet count can
>overwrap a long anyway between two samples...
>
>
>
>[PATCH] benet: fix build error on 32bit arch
>
Thanks for the quick patch.
-Sathya
^ permalink raw reply
* Re: [PATCH v10 4/5] [powerpc] Add flexcan device support for p1010rdb.
From: Robin Holt @ 2011-08-10 10:15 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list,
Wolfgang Grandegger
In-Reply-To: <4E4255B1.6050001-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Wed, Aug 10, 2011 at 11:56:01AM +0200, Marc Kleine-Budde wrote:
> On 08/10/2011 05:06 AM, Robin Holt wrote:
> > diff --git a/arch/powerpc/platforms/85xx/clock.c b/arch/powerpc/platforms/85xx/clock.c
> > new file mode 100644
> > index 0000000..16fae04
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/85xx/clock.c
> > @@ -0,0 +1,53 @@
...
> > +void __init mpc85xx_clk_init(void)
> > +{
> > + clk_functions = mpc85xx_clk_functions;
> > +}
> > +
>
> git is even picker then me: "new blank line at EOF."
> please fix
That reminded me that I have slacked on using checkpatch.pl in a few
resends and it really does not like this patch at all so I will rework
the patch with its concerns. I am going to hold off on resending until
there are more substantial changes.
Thanks,
Robin
^ permalink raw reply
* Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
From: Robin Holt @ 2011-08-10 10:11 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list,
Wolfgang Grandegger
In-Reply-To: <4E425716.4010104-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Wed, Aug 10, 2011 at 12:01:58PM +0200, Marc Kleine-Budde wrote:
> On 08/10/2011 05:05 AM, Robin Holt wrote:
> > With all the patches applied, my p1010rdb works for communicating between
> > its two can ports and also can communicate with an external PSOC. I have
> > done no testing beyond compile testing on an arm system as I have no
> > access to an arm based system.
> >
> > For the first three patches in the series, I believe they are all ready
> > for forwarding to David S. Miller for the netdev tree. I think patch
> > 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed
> > from the previous post by adding a second compatible string for the
> > fsl,p1010_flexcan.
>
> One remark for the subjects. It seems no one is using "[$subsystem]"
> anymore, but rather "$subsystem:".
I will, one day, get these patches subject lines correct ;)
Did you happen to get a chance to test the patches on arm?
Thanks,
Robin
^ permalink raw reply
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-10 10:09 UTC (permalink / raw)
To: Grant Likely, devicetree-discuss
Cc: socketcan-core, netdev, PPC list, Kumar Gala, Marc Kleine-Budde,
Wolfgang Grandegger, U Bhaskar-B22300, Scott Wood
In-Reply-To: <1312945564-6626-6-git-send-email-holt@sgi.com>
Grant,
Do you need this patch resent with you on the Cc: list or can you pick
up the discussion from here? I am just trying to minimize noise on
the mailing lists if it is not needed.
The essence of the discussion to this point is:
1) Freescale built a board support package for a new processor and eval
board (p1010) based upon some older boards.
2) As part of that effort, they made changes as they saw fit to get it
working without submitting those changes to the community.
3) In the case of the flexcan device, that included defining a device
tree node for the integrated Controller Area Network device and set
.compatible="fsl,flexcan-v1.0". Apparently this was copied from
another device, possibly mscan.
4) In an effort to get my p1010rdb eval board working with a community
kernel, I started submitting patches for flexcan which have evolved
to the point of nearly being accepted with the exception of we need
to settle on the node's .compatible= strings and whether it should
be documented.
5) To this point, I believe the concensus has settled on
"fsl,p1010-flexcan" and "fsl,flexcan" as the compatible strings.
This leaves the most flexibility for segragating future specific
revisions of the flexcan interface if needed.
6) I failed to Cc: you or the device tree list when I submitted version
10 of the patches. I have added both to the patch header so they
will be included in the next pass.
Thanks,
Robin Holt
On Tue, Aug 09, 2011 at 10:06:04PM -0500, Robin Holt wrote:
> In working with the socketcan developers, we have come to the conclusion
> the Documentation...fsl-flexcan.txt device tree documentation needs to
> be cleaned up. The driver does not depend upon any properties other
> than the required properties so we are removing the file. Additionally,
> the p1010*dts* files are not following the standard for node naming in
> that they have a trailing -v1.0.
>
> Signed-off-by: Robin Holt <holt@sgi.com>
> To: Marc Kleine-Budde <mkl@pengutronix.de>,
> To: Wolfgang Grandegger <wg@grandegger.com>,
> To: U Bhaskar-B22300 <B22300@freescale.com>
> To: Scott Wood <scottwood@freescale.com>
> Cc: socketcan-core@lists.berlios.de,
> Cc: netdev@vger.kernel.org,
> Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> ---
> .../devicetree/bindings/net/can/fsl-flexcan.txt | 61 --------------------
> arch/powerpc/boot/dts/p1010rdb.dts | 8 ---
> arch/powerpc/boot/dts/p1010si.dtsi | 8 +-
> 3 files changed, 4 insertions(+), 73 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>
> diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> deleted file mode 100644
> index 1a729f0..0000000
> --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> +++ /dev/null
> @@ -1,61 +0,0 @@
> -CAN Device Tree Bindings
> -------------------------
> -2011 Freescale Semiconductor, Inc.
> -
> -fsl,flexcan-v1.0 nodes
> ------------------------
> -In addition to the required compatible-, reg- and interrupt-properties, you can
> -also specify which clock source shall be used for the controller.
> -
> -CPI Clock- Can Protocol Interface Clock
> - This CLK_SRC bit of CTRL(control register) selects the clock source to
> - the CAN Protocol Interface(CPI) to be either the peripheral clock
> - (driven by the PLL) or the crystal oscillator clock. The selected clock
> - is the one fed to the prescaler to generate the Serial Clock (Sclock).
> - The PRESDIV field of CTRL(control register) controls a prescaler that
> - generates the Serial Clock (Sclock), whose period defines the
> - time quantum used to compose the CAN waveform.
> -
> -Can Engine Clock Source
> - There are two sources for CAN clock
> - - Platform Clock It represents the bus clock
> - - Oscillator Clock
> -
> - Peripheral Clock (PLL)
> - --------------
> - |
> - --------- -------------
> - | |CPI Clock | Prescaler | Sclock
> - | |---------------->| (1.. 256) |------------>
> - --------- -------------
> - | |
> - -------------- ---------------------CLK_SRC
> - Oscillator Clock
> -
> -- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
> - the peripheral clock. PLL clock is fed to the
> - prescaler to generate the Serial Clock (Sclock).
> - Valid values are "oscillator" and "platform"
> - "oscillator": CAN engine clock source is oscillator clock.
> - "platform" The CAN engine clock source is the bus clock
> - (platform clock).
> -
> -- fsl,flexcan-clock-divider : for the reference and system clock, an additional
> - clock divider can be specified.
> -- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
> -
> -Note:
> - - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
> - - P1010 does not have oscillator as the Clock Source.So the default
> - Clock Source is platform clock.
> -Examples:
> -
> - can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> - reg = <0x1c000 0x1000>;
> - interrupts = <48 0x2>;
> - interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-source = "platform";
> - fsl,flexcan-clock-divider = <2>;
> - clock-frequency = <fixed by u-boot>;
> - };
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
> index 6b33b73..d6a0bb2 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dts
> +++ b/arch/powerpc/boot/dts/p1010rdb.dts
> @@ -169,14 +169,6 @@
> };
> };
>
> - can0@1c000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> - can1@1d000 {
> - fsl,flexcan-clock-source = "platform";
> - };
> -
> usb@22000 {
> phy_type = "utmi";
> };
> diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi
> index 7f51104..20c396d 100644
> --- a/arch/powerpc/boot/dts/p1010si.dtsi
> +++ b/arch/powerpc/boot/dts/p1010si.dtsi
> @@ -141,19 +141,19 @@
> };
>
> can0@1c000 {
> - compatible = "fsl,flexcan-v1.0";
> + compatible = "fsl,p1010-flexcan",
> + "fsl,flexcan";
> reg = <0x1c000 0x1000>;
> interrupts = <48 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> can1@1d000 {
> - compatible = "fsl,flexcan-v1.0";
> + compatible = "fsl,p1010-flexcan",
> + "fsl,flexcan";
> reg = <0x1d000 0x1000>;
> interrupts = <61 0x2>;
> interrupt-parent = <&mpic>;
> - fsl,flexcan-clock-divider = <2>;
> };
>
> L2: l2-cache-controller@20000 {
> --
> 1.7.2.1
^ permalink raw reply
* Re: [PATCH v10 0/5] [flexcan/powerpc] Add support for powerpc flexcan (freescale p1010)
From: Marc Kleine-Budde @ 2011-08-10 10:01 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list,
Wolfgang Grandegger
In-Reply-To: <1312945564-6626-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1022 bytes --]
On 08/10/2011 05:05 AM, Robin Holt wrote:
> With all the patches applied, my p1010rdb works for communicating between
> its two can ports and also can communicate with an external PSOC. I have
> done no testing beyond compile testing on an arm system as I have no
> access to an arm based system.
>
> For the first three patches in the series, I believe they are all ready
> for forwarding to David S. Miller for the netdev tree. I think patch
> 4 is ready for submission to the PPC85xx maintainer. Patch 5 changed
> from the previous post by adding a second compatible string for the
> fsl,p1010_flexcan.
One remark for the subjects. It seems no one is using "[$subsystem]"
anymore, but rather "$subsystem:".
cheers, 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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ 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