* 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
* Re: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
From: Michael Guntsche @ 2011-08-10 9:59 UTC (permalink / raw)
To: Jiri Pirko; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <20110810090014.GB1909@minipsycho.brq.redhat.com>
On Wed, Aug 10, 2011 at 11:00 AM, Jiri Pirko <jpirko@redhat.com> wrote:
> Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@gmail.com wrote:
>>Good evening/morning,
>>
>>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>>> testing. On a first look everything seemed to work fine, but when I
>>> tried to connect via openvpn to my internal network (tap0 being bridged
>>> with the internal network) I noticed that I was not able to access the
>>> server on my internal network. I could access the bridge (which is
>>> acting as the openvpn server as well) just fine though.
>>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>>> internal network. I could see the ARP requests being answered.....
>><snip>
>>
>>After much digging and testing I found the commit that causes the
>>problem for me here.
>>
>>87c288c6e gianfar: do vlan cleanup
>>
>>Before this commit my bridge works fine. I simplified the test case
>>and just tried to access the server from a local wireless device with
>>gets also bridged via
>>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>>device from the internal network afterwards it stops.
>>For testing purposes I reverted this commit (plus some others to make
>>the code compile) and it started working again.
>>The hardware is a routerboard with three onboard nics two of em gianfar.
>>The gianfar nics do not support any kind of offloading,
>>
>>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
^ permalink raw reply
* Re: [PATCH v10 4/5] [powerpc] Add flexcan device support for p1010rdb.
From: Marc Kleine-Budde @ 2011-08-10 9:56 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-5-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 4921 bytes --]
On 08/10/2011 05:06 AM, Robin Holt wrote:
> I added a simple clock source for the p1010rdb so the flexcan driver
> could determine a clock frequency. The p1010 can device only has an
> oscillator of system bus frequency divided by 2.
>
> Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
> Acked-by: 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>
> Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 2 +
> arch/powerpc/platforms/85xx/Makefile | 2 +
> arch/powerpc/platforms/85xx/clock.c | 53 ++++++++++++++++++++++++++++++++
> arch/powerpc/platforms/85xx/p1010rdb.c | 8 +++++
> 4 files changed, 65 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/85xx/clock.c
>
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index 498534c..c4304ae 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -70,6 +70,8 @@ config MPC85xx_RDB
> config P1010_RDB
> bool "Freescale P1010RDB"
> select DEFAULT_UIMAGE
> + select HAVE_CAN_FLEXCAN if NET && CAN
> + select PPC_CLOCK if CAN_FLEXCAN
> help
> This option enables support for the MPC85xx RDB (P1010 RDB) board
>
> diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
> index a971b32..cc7f381 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -3,6 +3,8 @@
> #
> obj-$(CONFIG_SMP) += smp.o
>
> +obj-$(CONFIG_PPC_CLOCK) += clock.o
> +
> obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
> obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
> obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o
> 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 @@
> +/*
> + * Copyright 2011 SGI, inc.
> + *
> + * This code is licensed for use under the GPL V2 as published by
> + * the Free Software Foundation.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/of.h>
> +
> +#include <asm/clk_interface.h>
> +
> +#include <sysdev/fsl_soc.h>
> +
> +/*
> + * p1010 needs to provide a clock source for the flexcan driver. The
> + * oscillator for the p1010 processor is only ever the system clock / 2.
> + */
> +
> +static struct clk *mpc85xx_clk_get(struct device *dev, const char *id)
> +{
> + if (!dev)
> + return ERR_PTR(-ENOENT);
> +
> + if (!dev->of_node ||
> + !of_device_is_compatible(dev->of_node, "fsl,flexcan"))
> + return ERR_PTR(-ENOENT);
> +
> + return NULL;
> +}
> +
> +static void mpc85xx_clk_put(struct clk *clk)
> +{
> + return;
> +}
> +
> +static unsigned long mpc85xx_clk_get_rate(struct clk *clk)
> +{
> + return fsl_get_sys_freq() / 2;
> +}
> +
> +static struct clk_interface mpc85xx_clk_functions = {
> + .clk_get = mpc85xx_clk_get,
> + .clk_get_rate = mpc85xx_clk_get_rate,
> + .clk_put = mpc85xx_clk_put,
> +};
> +
> +void __init mpc85xx_clk_init(void)
> +{
> + clk_functions = mpc85xx_clk_functions;
> +}
> +
git is even picker then me: "new blank line at EOF."
please fix
> diff --git a/arch/powerpc/platforms/85xx/p1010rdb.c b/arch/powerpc/platforms/85xx/p1010rdb.c
> index d7387fa..5e52122 100644
> --- a/arch/powerpc/platforms/85xx/p1010rdb.c
> +++ b/arch/powerpc/platforms/85xx/p1010rdb.c
> @@ -81,6 +81,13 @@ static void __init p1010_rdb_setup_arch(void)
> printk(KERN_INFO "P1010 RDB board from Freescale Semiconductor\n");
> }
>
> +extern void mpc85xx_clk_init(void);
> +
> +static void __init p1010_rdb_init(void)
> +{
> + mpc85xx_clk_init();
> +}
> +
> static struct of_device_id __initdata p1010rdb_ids[] = {
> { .type = "soc", },
> { .compatible = "soc", },
> @@ -111,6 +118,7 @@ define_machine(p1010_rdb) {
> .name = "P1010 RDB",
> .probe = p1010_rdb_probe,
> .setup_arch = p1010_rdb_setup_arch,
> + .init = p1010_rdb_init,
> .init_IRQ = p1010_rdb_pic_init,
> #ifdef CONFIG_PCI
> .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
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: [linux-firmware 1/2] rtl_nic: update firmware for RTL8111E-VL
From: David Woodhouse @ 2011-08-10 9:35 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1312954862-32708-1-git-send-email-hayeswang@realtek.com>
On Wed, 2011-08-10 at 13:41 +0800, Hayes Wang wrote:
> From: Albert Kuo <albertk@realtek.com>
>
> Updated firmware with stability fixes.
> Version: rtl8168e-3_0.0.1.
>
> Signed-off-by: Albert Kuo <albertk@realtek.com>
Please could you put that version information into the WHENCE file so
that it isn't lost in the git log?
--
dwmw2
^ permalink raw reply
* Re: gianfar.c null pointer deref in gfar_start_xmit().
From: Robin Holt @ 2011-08-10 9:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Robin Holt, Sandeep Gopalpet, David S. Miller, netdev
In-Reply-To: <1312956061.2547.74.camel@edumazet-laptop>
On Wed, Aug 10, 2011 at 08:01:01AM +0200, Eric Dumazet wrote:
> Le mardi 09 août 2011 à 08:06 -0500, Robin Holt a écrit :
> > On Tue, Aug 09, 2011 at 09:10:13AM +0200, Eric Dumazet wrote:
> > > Le mardi 09 août 2011 à 01:54 -0500, Robin Holt a écrit :
> > > > On Tue, Aug 02, 2011 at 09:44:38PM -0500, Robin Holt wrote:
> > > > >
> > > > > While using the v3.0 kernel on a Freescale P1010RDB with 3 minor patches
> > > > > (None which affect gianfar.c), I get a NULL pointer deref at:
> > > > >
> > > > > static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
> > > > > {
> > > > > ...
> > > > > regs = tx_queue->grp->regs;
> > > > >
> > > > > I put a BUG_ON(tx_queue->grp) just before this line and it did trip.
> > > > > I have not looked at this any more than that.
> > > > >
> > > > > Any suggestions would be welcome. To reproduce, all I need to do is
> > > > > a few sequences of pings.
> > > >
> > > > I was able to reproduce this with the net-next-2.6 kernel as well.
> > > >
> > >
> > > This driver incorrectly assumes a non dense txqueue array is possible
> > > for a netdev, but its not true.
> > >
> > > In the meantime, you could force it to use one tx_queue only.
> > >
> > > tx_queues = (u32 *)of_get_property(np, "fsl,num_tx_queues", NULL);
> > > num_tx_qs = tx_queues ? *tx_queues : 1;
> >
> > I fixed up the .dts file and now it works. I have not tested the RGMII
> > interface yet so I do not know if that supports multiple queues. I assume
> > I could find it in the documentation. What might I be looking for?
> >
>
> What exact change did you in dts ?
I changed arch/powerpc/boot/dts/p1010si.dtsi and modified all lines that
had fsl,num_rx_queues and fsl,num_tx_queues then recompiled and rebuilt
my multi-image boot file.
It looks like my boot loader might be missing something. The p1010
reference manual has a section 15.7.2 Multigroup Mode Initialization.
I assume that sections initialize before using multigroup mode steps are
not getting done in the boot loader. Does that possibly sound like the
right section of the manual?
>
> Assuming your p1010rdb is single core powerpc, I fail to see why 8
> queues should be enabled on NIC. It only increases number of interrupts
> if multiple flows are in use, and memory footprint.
Thanks,
Robin
^ permalink raw reply
* Re: [PATCH] slip: fix NOHZ local_softirq_pending 08 warning
From: Alan Cox @ 2011-08-10 9:28 UTC (permalink / raw)
To: matvejchikov; +Cc: Oliver Hartkopp, netdev
In-Reply-To: <CAKh5naayzp3ANwnE2Y9U2LEaiWNoZAuT3aOQbRYdoB5uNdrOPw@mail.gmail.com>
> 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.
Alan
^ 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 9:00 UTC (permalink / raw)
To: Michael Guntsche; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <CAMvAeqOA0=FnjB2oPPCEYpkXdKrmqOs+MwAqszV5sTGys_a3mQ@mail.gmail.com>
Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@gmail.com wrote:
>Good evening/morning,
>
>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>> testing. On a first look everything seemed to work fine, but when I
>> tried to connect via openvpn to my internal network (tap0 being bridged
>> with the internal network) I noticed that I was not able to access the
>> server on my internal network. I could access the bridge (which is
>> acting as the openvpn server as well) just fine though.
>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>> internal network. I could see the ARP requests being answered.....
><snip>
>
>After much digging and testing I found the commit that causes the
>problem for me here.
>
>87c288c6e gianfar: do vlan cleanup
>
>Before this commit my bridge works fine. I simplified the test case
>and just tried to access the server from a local wireless device with
>gets also bridged via
>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>device from the internal network afterwards it stops.
>For testing purposes I reverted this commit (plus some others to make
>the code compile) and it started working again.
>The hardware is a routerboard with three onboard nics two of em gianfar.
>The gianfar nics do not support any kind of offloading,
>
>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?
>ntuple-filters: off
>receive-hashing: off
>
>Is it possible that the new code is tripped up by the bridge offload
>parameters somehow and thinks that the gianfar nic supports it as
>well?
>As I wrote in my initial mail, connecting to the Bridge itself works,
>I can also see ARP requests and Broadcasts, the rest just seems to
>disappear.
>
>As for the commits I reverted:
>a4aeb2662 vlan: kill __vlan_hwaccel_rx and vlan_hwaccel_rx
>6dacaddd4 vlan: kill vlan_hwaccel_receive_skb
>7890a5b9c vlan: kill ndo_vlan_rx_register
>b852b7208 gianfar: fix bug caused by 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
>
>87c288c6e gianfar: do vlan cleanup
>
>I really think that there is only some small change in the gianfar
>code needed, but I could not figure it out myself.
>Please tell me if you need any more information.
>
>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 8:46 UTC (permalink / raw)
To: Jiri Pirko; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <20110810083732.GA1909@minipsycho.brq.redhat.com>
On Wed, Aug 10, 2011 at 10:37 AM, Jiri Pirko <jpirko@redhat.com> wrote:
> Wed, Aug 10, 2011 at 09:40:50AM CEST, mguntsche@gmail.com wrote:
>>On Wed, Aug 10, 2011 at 9:07 AM, Jiri Pirko <jpirko@redhat.com> wrote:
>>> Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@gmail.com wrote:
>>>>Good evening/morning,
>>>>
>>>>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>>>>> testing. On a first look everything seemed to work fine, but when I
>>>>> tried to connect via openvpn to my internal network (tap0 being bridged
>>>>> with the internal network) I noticed that I was not able to access the
>>>>> server on my internal network. I could access the bridge (which is
>>>>> acting as the openvpn server as well) just fine though.
>>>>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>>>>> internal network. I could see the ARP requests being answered.....
>>>><snip>
>>>>
>>>>After much digging and testing I found the commit that causes the
>>>>problem for me here.
>>>>
>>>>87c288c6e gianfar: do vlan cleanup
>>>>
>>>>Before this commit my bridge works fine. I simplified the test case
>>>>and just tried to access the server from a local wireless device with
>>>>gets also bridged via
>>>>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>>>>device from the internal network afterwards it stops.
>>>>For testing purposes I reverted this commit (plus some others to make
>>>>the code compile) and it started working again.
>>>>The hardware is a routerboard with three onboard nics two of em gianfar.
>>>>The gianfar nics do not support any kind of offloading,
>>>
>>> Thanks for testing/report. I'm not sure I understand your simplified
>>> case :(
>>Sorry if my explanation was confusing but it was late night/morning
>>when I wrote it.
>>
>>The setup is quite easy.
>>
>>WLAN ----->|Bridge|<----- Wired Lan (gianfar nic)
>>
>>Client (in WLAN): 192.168.42.55
>>Bridge: 192.168.42.1
>>Server (on Wired): 192.168.42.127
>>
>>With your patch the Bridge can ping the client and the server, but the
>>client cannot reach the server and vice-versa.
>
> This is very interesting. Can you please find out of packets get lost on
> tx or rx of gianfar? Please try to watch the trafic by tcpdump on bridge
> and on gianfar device.
I can try to do that this afternoon.
>>> Anyway, gianfar supports rx/tx vlan accel. Would you please try to turn
>>> it on/off manually by ethtool to see if it works in some setup?
>>The gianfar chip in this routerboard does NOT support vlan accel it is
>>a TSEC model.
>>ethtool complains that this feature is not supported.
>
> What routerboard is it? Maybe I can get one to see this myself. Thanks.
The model is a Rb600a which is no longer available
> Can you please send me output of following command?
> "cat /sys/class/net/[gianfar devname]/features"
There is no file called features under the gianfar devname
>
> Also, please try with following testing patch:
>
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 2659daa..2727bb7 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -2711,8 +2711,8 @@ static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
> skb->protocol = eth_type_trans(skb, dev);
>
> /* Set vlan tag */
> - if (fcb->flags & RXFCB_VLN)
> - __vlan_hwaccel_put_tag(skb, fcb->vlctl);
> + //if (fcb->flags & RXFCB_VLN)
> + // __vlan_hwaccel_put_tag(skb, fcb->vlctl);
>
> /* Send the packet up the stack */
> ret = netif_receive_skb(skb);
Will do.
Kind regards,
Michael
^ 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 8:37 UTC (permalink / raw)
To: Michael Guntsche; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <CAMvAeqNA9Wcr3bO+Vya4gt2YC47oe=-A8Fxnswdj0ozD5tfZtQ@mail.gmail.com>
Wed, Aug 10, 2011 at 09:40:50AM CEST, mguntsche@gmail.com wrote:
>On Wed, Aug 10, 2011 at 9:07 AM, Jiri Pirko <jpirko@redhat.com> wrote:
>> Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@gmail.com wrote:
>>>Good evening/morning,
>>>
>>>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>>>> testing. On a first look everything seemed to work fine, but when I
>>>> tried to connect via openvpn to my internal network (tap0 being bridged
>>>> with the internal network) I noticed that I was not able to access the
>>>> server on my internal network. I could access the bridge (which is
>>>> acting as the openvpn server as well) just fine though.
>>>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>>>> internal network. I could see the ARP requests being answered.....
>>><snip>
>>>
>>>After much digging and testing I found the commit that causes the
>>>problem for me here.
>>>
>>>87c288c6e gianfar: do vlan cleanup
>>>
>>>Before this commit my bridge works fine. I simplified the test case
>>>and just tried to access the server from a local wireless device with
>>>gets also bridged via
>>>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>>>device from the internal network afterwards it stops.
>>>For testing purposes I reverted this commit (plus some others to make
>>>the code compile) and it started working again.
>>>The hardware is a routerboard with three onboard nics two of em gianfar.
>>>The gianfar nics do not support any kind of offloading,
>>
>> Thanks for testing/report. I'm not sure I understand your simplified
>> case :(
>Sorry if my explanation was confusing but it was late night/morning
>when I wrote it.
>
>The setup is quite easy.
>
>WLAN ----->|Bridge|<----- Wired Lan (gianfar nic)
>
>Client (in WLAN): 192.168.42.55
>Bridge: 192.168.42.1
>Server (on Wired): 192.168.42.127
>
>With your patch the Bridge can ping the client and the server, but the
>client cannot reach the server and vice-versa.
This is very interesting. Can you please find out of packets get lost on
tx or rx of gianfar? Please try to watch the trafic by tcpdump on bridge
and on gianfar device.
>
>>
>> Anyway, gianfar supports rx/tx vlan accel. Would you please try to turn
>> it on/off manually by ethtool to see if it works in some setup?
>The gianfar chip in this routerboard does NOT support vlan accel it is
>a TSEC model.
>ethtool complains that this feature is not supported.
What routerboard is it? Maybe I can get one to see this myself. Thanks.
Can you please send me output of following command?
"cat /sys/class/net/[gianfar devname]/features"
Also, please try with following testing patch:
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 2659daa..2727bb7 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2711,8 +2711,8 @@ static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb,
skb->protocol = eth_type_trans(skb, dev);
/* Set vlan tag */
- if (fcb->flags & RXFCB_VLN)
- __vlan_hwaccel_put_tag(skb, fcb->vlctl);
+ //if (fcb->flags & RXFCB_VLN)
+ // __vlan_hwaccel_put_tag(skb, fcb->vlctl);
/* Send the packet up the stack */
ret = netif_receive_skb(skb);
>
>>
>> I presume you have no vlans involved in your setup, right?
>No, there are no vlans in my setup.
>
>
>>>Is it possible that the new code is tripped up by the bridge offload
>>>parameters somehow and thinks that the gianfar nic supports it as
>>>well?
>>
>> I don't see how now. Outside the bridge all is working correctly?
>Yes I can access the server from the bridge so the network is working.
>For me it looks like that the packets are just dropped when they
>should go through the bridge.
>
>Kind regards,
>Michael
^ permalink raw reply related
* Re: [PATCH v10 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Robert Schwebel @ 2011-08-10 8:15 UTC (permalink / raw)
To: Robin Holt
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
Scott Wood, PPC list, Wolfgang Grandegger
In-Reply-To: <1312945564-6626-6-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
Robin,
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-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
I suggest that you set devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org and Grant
Likely on Cc: for this patch.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH] slip: fix NOHZ local_softirq_pending 08 warning
From: Matvejchikov Ilya @ 2011-08-10 7:47 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: netdev, Alan Cox
In-Reply-To: <4E416951.4020207@hartkopp.net>
Oliver,
As I see it, there is the following call chain of the netif_rx_ni() in
the slip (or slcan) driver:
[flush_to_ldisc] -> [disc->ops->receive_buf] -> [slip_unesc] ->
[sl_bump] -> [netif_rx_ni]
So flush_to_ldisc() may be called:
1) From tty_flush_to_ldisc() with flush_work and as it mentioned
must not be called from IRQ context.
2) From input_available_p() which can be called from n_tty_read() or
n_tty_poll(), so it's the user's context.
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
are using netif_rx_ni() we can handle both IRQ and softirq contexts
well as if there are any softirq pending netif_rx_ni() calls
do_softirq() with preemtion disabled. Then do_softirq() checks if
there is an IRQ context and does nothing if so.
So, I think it's correct to change netif_rx() with the netif_rx_ni().
2011/8/9 Oliver Hartkopp <socketcan@hartkopp.net>:
> Hello Ilya,
>
> is the processing of characters in the tty input stream for line disciplines
> *always* done in softirq context???
>
> If so, i would send a patch for drivers/net/can/slcan.c too ...
>
> Thanks,
> Oliver
>
> On 05.08.2011 21:23, Matvejchikov Ilya wrote:
>> When using nanosleep() in an userspace application we get a ratelimit warning:
>>
>> NOHZ: local_softirq_pending 08
>>
>> According to 481a8199142c050b72bff8a1956a49fd0a75bbe0 the problem is caused by
>> netif_rx() function. This patch replaces netif_rx() with netif_rx_ni() which
>> has to be used from process/softirq context.
>>
>> Signed-off-by: Matvejchikov Ilya <matvejchikov@gmail.com>
>> ---
>> drivers/net/slip.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/slip.c b/drivers/net/slip.c
>> index f11b3f3..4c61753 100644
>> --- a/drivers/net/slip.c
>> +++ b/drivers/net/slip.c
>> @@ -367,7 +367,7 @@ static void sl_bump(struct slip *sl)
>> memcpy(skb_put(skb, count), sl->rbuff, count);
>> skb_reset_mac_header(skb);
>> skb->protocol = htons(ETH_P_IP);
>> - netif_rx(skb);
>> + netif_rx_ni(skb);
>> dev->stats.rx_packets++;
>> }
>>
>
>
^ 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 7:40 UTC (permalink / raw)
To: Jiri Pirko; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <20110810070722.GA2150@minipsycho>
On Wed, Aug 10, 2011 at 9:07 AM, Jiri Pirko <jpirko@redhat.com> wrote:
> Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@gmail.com wrote:
>>Good evening/morning,
>>
>>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>>> testing. On a first look everything seemed to work fine, but when I
>>> tried to connect via openvpn to my internal network (tap0 being bridged
>>> with the internal network) I noticed that I was not able to access the
>>> server on my internal network. I could access the bridge (which is
>>> acting as the openvpn server as well) just fine though.
>>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>>> internal network. I could see the ARP requests being answered.....
>><snip>
>>
>>After much digging and testing I found the commit that causes the
>>problem for me here.
>>
>>87c288c6e gianfar: do vlan cleanup
>>
>>Before this commit my bridge works fine. I simplified the test case
>>and just tried to access the server from a local wireless device with
>>gets also bridged via
>>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>>device from the internal network afterwards it stops.
>>For testing purposes I reverted this commit (plus some others to make
>>the code compile) and it started working again.
>>The hardware is a routerboard with three onboard nics two of em gianfar.
>>The gianfar nics do not support any kind of offloading,
>
> Thanks for testing/report. I'm not sure I understand your simplified
> case :(
Sorry if my explanation was confusing but it was late night/morning
when I wrote it.
The setup is quite easy.
WLAN ----->|Bridge|<----- Wired Lan (gianfar nic)
Client (in WLAN): 192.168.42.55
Bridge: 192.168.42.1
Server (on Wired): 192.168.42.127
With your patch the Bridge can ping the client and the server, but the
client cannot reach the server and vice-versa.
>
> Anyway, gianfar supports rx/tx vlan accel. Would you please try to turn
> it on/off manually by ethtool to see if it works in some setup?
The gianfar chip in this routerboard does NOT support vlan accel it is
a TSEC model.
ethtool complains that this feature is not supported.
>
> I presume you have no vlans involved in your setup, right?
No, there are no vlans in my setup.
>>Is it possible that the new code is tripped up by the bridge offload
>>parameters somehow and thinks that the gianfar nic supports it as
>>well?
>
> I don't see how now. Outside the bridge all is working correctly?
Yes I can access the server from the bridge so the network is working.
For me it looks like that the packets are just dropped when they
should go through the bridge.
Kind regards,
Michael
^ permalink raw reply
* Re: [PATCH] Add pch ieee1588 driver for Intel EG20T PCH
From: Richard Cochran @ 2011-08-10 7:28 UTC (permalink / raw)
To: Toshiharu Okada
Cc: tomoya-linux, kok.howg.ewe, joel.clark, yong.y.wang, qi.wang,
linux-kernel, netdev, richard.cochran
In-Reply-To: <817E42EB77CC464D9F0BA9D4CB92C152@hacdom.okisemi.com>
On Wed, Aug 10, 2011 at 02:03:32PM +0900, Toshiharu Okada wrote:
> Hi Richard
>
> I added comment below.
> Please confirm them
Thanks, I have a few questions, below.
I will also comment on the patch itself.
> >Section 14.6.1.10 in the data sheet seems to imply that the input
> >clock is 50 MHz. In that case you could use a nominal frequency of
> >31.25 MHz (period 32 ns, SHIFT 5). However, you need to find out
> >the actual input clock frequency. If this can vary, then the driver
> >should allow changing these values.
>
> modify as follows.
>
> #define DEFAULT_ADDEND 0xA0000000
> #define TICKS_NS_SHIFT 5
Have you determined the input clock frequency?
If so, what is it?
> >> + u32 ch_control;
> >
> >You never program this register. But I think the "Mode" field should
> >be set to 2. The other settings really make no sense at all. Or do
> >you set this in the MAC driver?
> >
> >(I wonder why Intel retained the very limited PTP V1 modes from the
> >IXP time stamping unit.)
>
> ch_control register was set as 0x80020000 (Version:1, mode:2 )
It might make more sense to set this register in the MAC driver in
connection with enabling and disabling packet time stamps (see below).
> >This ISR code (and much of the rest of the driver) is copied from the
> >IXP driver. It would be nice to know if it actually works on the atom
> >hardware. Do have any hardware to try it on?
>
> We have a board of atom(E600) and EG20T.
> However there is no environment for confirming auxiliary snapshot.
Well, if you plan to test the auxiliary snapshot on real hardware,
then we can leave the code as it is.
Otherwise, I would prefer to move the auxiliary snapshot code into a
separate patch. Then, we can wait to merge that code until someone
tests it.
I did test the auxiliary snapshot code on the IXP465, and probably it
will work just fine, but I want to be sure that it works on the atom
before merging.
> >I would also like to see how the time stamps are done in the MAC
> >driver. Have you already posted that?
>
> Mac driver already upstreamed. ( drivers/net/pch_gbe)
> However the code relevant to IEEE1588 is not contained into Ethernet driver.
> I have question about rx/tx snapshot.
> Is it necessary to use a snapshot within an Ethernet driver driver?
> I was indicated that there must not be any dependence of a device when the
> Ethernet driver was upstreamed.
(I assume that you mean "time stamp" when you say, "snapshot")
You will need to also add time stamping support into that driver. That
means supporting the SIOCSHWTSTAMP ioctl. As an example, you can take
a look at drivers/net/arm/ixp4xx_eth.c.
It would be nice to have a series of two patches, one adding the PHC
driver, and one adding SIOCSHWTSTAMP to the MAC driver.
Thanks,
Richard
^ 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 7:07 UTC (permalink / raw)
To: Michael Guntsche; +Cc: shemminger, sebastian.belden, netdev, linux-kernel
In-Reply-To: <CAMvAeqOA0=FnjB2oPPCEYpkXdKrmqOs+MwAqszV5sTGys_a3mQ@mail.gmail.com>
Wed, Aug 10, 2011 at 02:50:20AM CEST, mguntsche@gmail.com wrote:
>Good evening/morning,
>
>> I just upgraded my router/bridge combo to 3.1-rc1 from 3.0 for
>> testing. On a first look everything seemed to work fine, but when I
>> tried to connect via openvpn to my internal network (tap0 being bridged
>> with the internal network) I noticed that I was not able to access the
>> server on my internal network. I could access the bridge (which is
>> acting as the openvpn server as well) just fine though.
>> To debug this I ran tcpdump on the openvpn client and started a ping to the
>> internal network. I could see the ARP requests being answered.....
><snip>
>
>After much digging and testing I found the commit that causes the
>problem for me here.
>
>87c288c6e gianfar: do vlan cleanup
>
>Before this commit my bridge works fine. I simplified the test case
>and just tried to access the server from a local wireless device with
>gets also bridged via
>a gianfar nic to the wired lan. Before commit 87c288c6e I can ping the
>device from the internal network afterwards it stops.
>For testing purposes I reverted this commit (plus some others to make
>the code compile) and it started working again.
>The hardware is a routerboard with three onboard nics two of em gianfar.
>The gianfar nics do not support any kind of offloading,
Thanks for testing/report. I'm not sure I understand your simplified
case :(
Anyway, gianfar supports rx/tx vlan accel. Would you please try to turn
it on/off manually by ethtool to see if it works in some setup?
I presume you have no vlans involved in your setup, right?
>
>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
>ntuple-filters: off
>receive-hashing: off
>
>Is it possible that the new code is tripped up by the bridge offload
>parameters somehow and thinks that the gianfar nic supports it as
>well?
I don't see how now. Outside the bridge all is working correctly?
>As I wrote in my initial mail, connecting to the Bridge itself works,
>I can also see ARP requests and Broadcasts, the rest just seems to
>disappear.
>
>As for the commits I reverted:
>a4aeb2662 vlan: kill __vlan_hwaccel_rx and vlan_hwaccel_rx
>6dacaddd4 vlan: kill vlan_hwaccel_receive_skb
>7890a5b9c vlan: kill ndo_vlan_rx_register
>b852b7208 gianfar: fix bug caused by 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
>
>87c288c6e gianfar: do vlan cleanup
>
>I really think that there is only some small change in the gianfar
>code needed, but I could not figure it out myself.
>Please tell me if you need any more information.
>
>Kind regards,
>Michael Guntsche
^ permalink raw reply
* Intel 82599 ixgbe driver performance
From: J.Hwan Kim @ 2011-08-10 6:19 UTC (permalink / raw)
To: netdev
Hi, everyone
I'm testing our network card which includes intel 82599 based on ixgbe
driver.
I wonder what is the Rx performance of i82599 without network stack only
with 64Byte frames.
Our driver reads the packet directly from DMA packet buffer and push to
the application
without passing through linux kernel stack.
It seems that the intel 82599 cannot push 64B frames to DMA area in 10G.
Is it right?
If it is the case, what is the bottleneck of 82599?
Thanks in advance.
Best Regards,
J.Hwan KIm
^ permalink raw reply
* [PATCH] net: sh_eth: Fix build by forgot including linux/interrupt.h
From: Nobuhiro Iwamatsu @ 2011-08-10 6:15 UTC (permalink / raw)
To: netdev; +Cc: adobriyan, Nobuhiro Iwamatsu
By a6b7a407865aab9f849dd99a71072b7cd1175116, remove interrupt.h
from netdevice.h. But this forget to revise sh_eth.
This fix the build failure.
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'sh_eth_interrupt'
error: implicit declaration of function 'request_irq'
error: 'sh_eth_interrupt' undeclared (first use in this function)
error: (Each undeclared identifier is reported only once
drivers/net/sh_eth.c:1386: error: for each function it appears in.)
error: 'IRQF_SHARED' undeclared (first use in this function)
error: implicit declaration of function 'free_irq'
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
CC: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/net/sh_eth.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index ad35c21..190f619 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -21,6 +21,7 @@
*/
#include <linux/init.h>
+#include <linux/interrupt.h>
#include <linux/dma-mapping.h>
#include <linux/etherdevice.h>
#include <linux/delay.h>
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2] pch ieee1588 driver for Intel EG20T PCH
From: Toshiharu Okada @ 2011-08-10 6:13 UTC (permalink / raw)
To: richard.cochran, netdev, linux-kernel
Cc: qi.wang, yong.y.wang, joel.clark, kok.howg.ewe, tomoya-linux,
Toshiharu Okada
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?
[Post Ver2]
Modifyed this patch for Richard's comment.
- modifyed clock frequency
- added setting of ch_control register
- added setting of station address
etc
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
---
drivers/ptp/Kconfig | 13 +
drivers/ptp/Makefile | 1 +
drivers/ptp/ptp_pch.c | 668 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 682 insertions(+), 0 deletions(-)
create mode 100644 drivers/ptp/ptp_pch.c
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index 68d7201..cd9bc3b 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -72,4 +72,17 @@ config DP83640_PHY
In order for this to work, your MAC driver must also
implement the skb_tx_timetamp() function.
+config PTP_1588_CLOCK_PCH
+ tristate "Intel PCH EG20T as PTP clock"
+ depends on PTP_1588_CLOCK
+ depends on PCH_GBE
+ help
+ This driver adds support for using the PCH EG20T as a PTP
+ clock. This clock is only useful if your PTP programs are
+ getting hardware time stamps on the PTP Ethernet packets
+ using the SO_TIMESTAMPING API.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ptp_pch.
+
endmenu
diff --git a/drivers/ptp/Makefile b/drivers/ptp/Makefile
index f6933e8..8b58597 100644
--- a/drivers/ptp/Makefile
+++ b/drivers/ptp/Makefile
@@ -5,3 +5,4 @@
ptp-y := ptp_clock.o ptp_chardev.o ptp_sysfs.o
obj-$(CONFIG_PTP_1588_CLOCK) += ptp.o
obj-$(CONFIG_PTP_1588_CLOCK_IXP46X) += ptp_ixp46x.o
+obj-$(CONFIG_PTP_1588_CLOCK_PCH) += ptp_pch.o
diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
new file mode 100644
index 0000000..159576d
--- /dev/null
+++ b/drivers/ptp/ptp_pch.c
@@ -0,0 +1,668 @@
+/*
+ * PTP 1588 clock using the EG20T PCH
+ *
+ * Copyright (C) 2010 OMICRON electronics GmbH
+ * Copyright (C) 2010 OKI SEMICONDUCTOR Co., LTD.
+ *
+ * This code was derived from the IXP46X driver.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/ptp_clock_kernel.h>
+
+#define STATION_ADDR_LEN 20
+#define PCI_DEVICE_ID_PCH_1588 0x8819
+#define IO_MEM_BAR 1
+
+#define DEFAULT_ADDEND 0xA0000000
+#define TICKS_NS_SHIFT 5
+#define N_EXT_TS 2
+
+enum pch_status {
+ PCH_SUCCESS,
+ PCH_INVALIDPARAM,
+ PCH_NOTIMESTAMP,
+ PCH_INTERRUPTMODEINUSE,
+ PCH_FAILED,
+ PCH_UNSUPPORTED,
+};
+/**
+ * struct pch_ts_regs - IEEE 1588 registers
+ */
+struct pch_ts_regs {
+ u32 control;
+ u32 event;
+ u32 addend;
+ u32 accum;
+ u32 test;
+ u32 ts_compare;
+ u32 rsystime_lo;
+ u32 rsystime_hi;
+ u32 systime_lo;
+ u32 systime_hi;
+ u32 trgt_lo;
+ u32 trgt_hi;
+ u32 asms_lo;
+ u32 asms_hi;
+ u32 amms_lo;
+ u32 amms_hi;
+ u32 ch_control;
+ u32 ch_event;
+ u32 tx_snap_lo;
+ u32 tx_snap_hi;
+ u32 rx_snap_lo;
+ u32 rx_snap_hi;
+ u32 src_uuid_lo;
+ u32 src_uuid_hi;
+ u32 can_status;
+ u32 can_snap_lo;
+ u32 can_snap_hi;
+ u32 ts_sel;
+ u32 ts_st[6];
+ u32 reserve1[14];
+ u32 stl_max_set_en;
+ u32 stl_max_set;
+ u32 reserve2[13];
+ u32 srst;
+};
+
+#define PCH_TSC_RESET (1 << 0)
+#define PCH_TSC_TTM_MASK (1 << 1)
+#define PCH_TSC_ASMS_MASK (1 << 2)
+#define PCH_TSC_AMMS_MASK (1 << 3)
+#define PCH_TSC_PPSM_MASK (1 << 4)
+#define PCH_TSE_TTIPEND (1 << 1)
+#define PCH_TSE_SNS (1 << 2)
+#define PCH_TSE_SNM (1 << 3)
+#define PCH_TSE_PPS (1 << 4)
+#define PCH_CC_MM (1 << 0)
+#define PCH_CC_TA (1 << 1)
+
+#define PCH_CC_MODE_SHIFT 16
+#define PCH_CC_MODE_MASK 0x001F0000
+#define PCH_CC_VERSION (1 << 31)
+#define PCH_CE_TXS (1 << 0)
+#define PCH_CE_RXS (1 << 1)
+#define PCH_CE_OVR (1 << 0)
+#define PCH_CE_VAL (1 << 1)
+#define PCH_ECS_ETH (1 << 0)
+
+#define PCH_ECS_CAN (1 << 1)
+#define PCH_STATION_BYTES 6
+
+#define PCH_IEEE1588_ETH (1 << 0)
+#define PCH_IEEE1588_CAN (1 << 1)
+/**
+ * struct pch_dev - Driver private data
+ */
+struct pch_dev {
+ struct pch_ts_regs *regs;
+ struct ptp_clock *ptp_clock;
+ struct ptp_clock_info caps;
+ int exts0_enabled;
+ int exts1_enabled;
+
+ u32 mem_base;
+ u32 mem_size;
+ u32 irq;
+ struct pci_dev *pdev;
+ spinlock_t register_lock;
+};
+
+/**
+ * struct ch_1588_params_ - 1588 module paramter
+ */
+struct pch_params_ {
+ u8 station[STATION_ADDR_LEN];
+};
+
+/* structure to hold the module parameters */
+static struct pch_params_ pch_param = {
+ "00:00:00:00:00:00"
+};
+
+/*
+ * Register access functions
+ */
+static inline void pch_eth_enable_set(struct pch_dev *chip)
+{
+ u32 val;
+ /* SET the eth_enable bit */
+ val = ioread32(&chip->regs->ts_sel) | (PCH_ECS_ETH);
+ iowrite32(val, (&chip->regs->ts_sel));
+}
+
+static u64 pch_systime_read(struct pch_ts_regs *regs)
+{
+ u64 ns;
+ u32 lo, hi;
+
+ lo = ioread32(®s->systime_lo);
+ hi = ioread32(®s->systime_hi);
+
+ ns = ((u64) hi) << 32;
+ ns |= lo;
+ ns <<= TICKS_NS_SHIFT;
+
+ return ns;
+}
+
+static void pch_systime_write(struct pch_ts_regs *regs, u64 ns)
+{
+ u32 hi, lo;
+
+ ns >>= TICKS_NS_SHIFT;
+ hi = ns >> 32;
+ lo = ns & 0xffffffff;
+
+ iowrite32(lo, ®s->systime_lo);
+ iowrite32(hi, ®s->systime_hi);
+}
+
+static inline void pch_block_reset(struct pch_dev *chip)
+{
+ u32 val;
+ /* Reset Hardware Assist block */
+ val = ioread32(&chip->regs->control) | PCH_TSC_RESET;
+ iowrite32(val, (&chip->regs->control));
+ val = val & ~PCH_TSC_RESET;
+ iowrite32(val, (&chip->regs->control));
+}
+
+/* This function enables all 64 bits in system time registers [high & low].
+This is a work-around for non continuous value in the SystemTime Register*/
+static void pch_set_system_time_count(struct pch_dev *chip)
+{
+ iowrite32(0x01, &chip->regs->stl_max_set_en);
+ iowrite32(0xFFFFFFFF, &chip->regs->stl_max_set);
+ iowrite32(0x00, &chip->regs->stl_max_set_en);
+}
+
+static void pch_reset(struct pch_dev *chip)
+{
+ /* Reset Hardware Assist */
+ pch_block_reset(chip);
+
+ /* enable all 32 bits in system time registers */
+ pch_set_system_time_count(chip);
+}
+
+/**
+ * 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;
+}
+
+/**
+ * pch_set_station_address() - This API sets the station address used by
+ * IEEE 1588 hardware when looking at PTP
+ * traffic on the ethernet interface
+ * @addr: dress which contain the column separated address to be used.
+ */
+static int pch_set_station_address(u8 *addr, struct pci_dev *pdev)
+{
+ s32 i;
+ struct pch_dev *chip = pci_get_drvdata(pdev);
+
+ /* Verify the parameter */
+ if ((chip->regs == 0) || addr == (u8 *)NULL) {
+ dev_err(&pdev->dev,
+ "%s :invalid params returning PCH_INVALIDPARAM\n", __func__);
+ return PCH_INVALIDPARAM;
+ }
+
+ for (i = 0; i < PCH_STATION_BYTES; i++) { /* For all station
+ address bytes */
+ u32 val;
+ s32 tmp;
+
+ tmp = get_decimal(addr[i * 3]);
+ if (tmp < 0) {
+ dev_err(&pdev->dev,
+ "%s :invalid params returning PCH_INVALIDPARAM\n",
+ __func__);
+ return PCH_INVALIDPARAM;
+ }
+ val = tmp * 16;
+ tmp = get_decimal(addr[(i * 3) + 1]);
+ if (tmp < 0) {
+ dev_err(&pdev->dev,
+ "%s :invalid params returning PCH_INVALIDPARAM\n",
+ __func__);
+ return PCH_INVALIDPARAM;
+ }
+ val += tmp;
+ if ((i < 5) && (addr[(i * 3) + 2] != ':')) { /* Expects ':'
+ separated addresses */
+ dev_err(&pdev->dev,
+ "%s :invalid params returning PCH_INVALIDPARAM\n",
+ __func__);
+ return PCH_INVALIDPARAM;
+ }
+
+ /* Ideally we should set the address only after validating
+ entire string */
+ dev_dbg(&pdev->dev, "%s :invoking pch_station_set\n", __func__);
+ iowrite32(val, &chip->regs->ts_st[i]);
+ }
+ return 0;
+}
+
+/*
+ * Interrupt service routine
+ */
+static irqreturn_t isr(int irq, void *priv)
+{
+ struct pch_dev *pch_dev = priv;
+ struct pch_ts_regs *regs = pch_dev->regs;
+ struct ptp_clock_event event;
+ u32 ack = 0, lo, hi, val;
+
+ val = ioread32(®s->event);
+
+ if (val & PCH_TSE_SNS) {
+ ack |= PCH_TSE_SNS;
+ if (pch_dev->exts0_enabled) {
+ hi = ioread32(®s->asms_hi);
+ lo = ioread32(®s->asms_lo);
+ event.type = PTP_CLOCK_EXTTS;
+ event.index = 0;
+ event.timestamp = ((u64) hi) << 32;
+ event.timestamp |= lo;
+ event.timestamp <<= TICKS_NS_SHIFT;
+ ptp_clock_event(pch_dev->ptp_clock, &event);
+ }
+ }
+
+ if (val & PCH_TSE_SNM) {
+ ack |= PCH_TSE_SNM;
+ if (pch_dev->exts1_enabled) {
+ hi = ioread32(®s->amms_hi);
+ lo = ioread32(®s->amms_lo);
+ event.type = PTP_CLOCK_EXTTS;
+ event.index = 1;
+ event.timestamp = ((u64) hi) << 32;
+ event.timestamp |= lo;
+ event.timestamp <<= TICKS_NS_SHIFT;
+ ptp_clock_event(pch_dev->ptp_clock, &event);
+ }
+ }
+
+ if (val & PCH_TSE_TTIPEND)
+ ack |= PCH_TSE_TTIPEND; /* this bit seems to be always set */
+
+ if (ack) {
+ iowrite32(ack, ®s->event);
+ return IRQ_HANDLED;
+ } else
+ return IRQ_NONE;
+}
+
+/*
+ * PTP clock operations
+ */
+
+static int ptp_pch_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
+{
+ u64 adj;
+ u32 diff, addend;
+ int neg_adj = 0;
+ struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
+ struct pch_ts_regs *regs = pch_dev->regs;
+
+ if (ppb < 0) {
+ neg_adj = 1;
+ ppb = -ppb;
+ }
+ addend = DEFAULT_ADDEND;
+ adj = addend;
+ adj *= ppb;
+ diff = div_u64(adj, 1000000000ULL);
+
+ addend = neg_adj ? addend - diff : addend + diff;
+
+ iowrite32(addend, ®s->addend);
+
+ return 0;
+}
+
+static int ptp_pch_adjtime(struct ptp_clock_info *ptp, s64 delta)
+{
+ s64 now;
+ unsigned long flags;
+ struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
+ struct pch_ts_regs *regs = pch_dev->regs;
+
+ spin_lock_irqsave(&pch_dev->register_lock, flags);
+ now = pch_systime_read(regs);
+ now += delta;
+ pch_systime_write(regs, now);
+ spin_unlock_irqrestore(&pch_dev->register_lock, flags);
+
+ return 0;
+}
+
+static int ptp_pch_gettime(struct ptp_clock_info *ptp, struct timespec *ts)
+{
+ u64 ns;
+ u32 remainder;
+ unsigned long flags;
+ struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
+ struct pch_ts_regs *regs = pch_dev->regs;
+
+ spin_lock_irqsave(&pch_dev->register_lock, flags);
+ ns = pch_systime_read(regs);
+ spin_unlock_irqrestore(&pch_dev->register_lock, flags);
+
+ ts->tv_sec = div_u64_rem(ns, 1000000000, &remainder);
+ ts->tv_nsec = remainder;
+ return 0;
+}
+
+static int ptp_pch_settime(struct ptp_clock_info *ptp,
+ const struct timespec *ts)
+{
+ u64 ns;
+ unsigned long flags;
+ struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
+ struct pch_ts_regs *regs = pch_dev->regs;
+
+ ns = ts->tv_sec * 1000000000ULL;
+ ns += ts->tv_nsec;
+
+ spin_lock_irqsave(&pch_dev->register_lock, flags);
+ pch_systime_write(regs, ns);
+ spin_unlock_irqrestore(&pch_dev->register_lock, flags);
+
+ return 0;
+}
+
+static int ptp_pch_enable(struct ptp_clock_info *ptp,
+ struct ptp_clock_request *rq, int on)
+{
+ struct pch_dev *pch_dev = container_of(ptp, struct pch_dev, caps);
+
+ switch (rq->type) {
+ case PTP_CLK_REQ_EXTTS:
+ switch (rq->extts.index) {
+ case 0:
+ pch_dev->exts0_enabled = on ? 1 : 0;
+ break;
+ case 1:
+ pch_dev->exts1_enabled = on ? 1 : 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+ default:
+ break;
+ }
+
+ return -EOPNOTSUPP;
+}
+
+static struct ptp_clock_info ptp_pch_caps = {
+ .owner = THIS_MODULE,
+ .name = "PCH timer",
+ .max_adj = 50000000,
+ .n_ext_ts = N_EXT_TS,
+ .pps = 0,
+ .adjfreq = ptp_pch_adjfreq,
+ .adjtime = ptp_pch_adjtime,
+ .gettime = ptp_pch_gettime,
+ .settime = ptp_pch_settime,
+ .enable = ptp_pch_enable,
+};
+
+
+#ifdef CONFIG_PM
+static s32 pch_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ pci_disable_device(pdev);
+ pci_enable_wake(pdev, PCI_D3hot, 0);
+
+ if (pci_save_state(pdev) != 0) {
+ dev_err(&pdev->dev,
+ "%s: could not save PCI config state\n", __func__);
+ return -ENOMEM;
+ }
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
+
+ return 0;
+}
+
+static s32 pch_resume(struct pci_dev *pdev)
+{
+ s32 ret;
+
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+ ret = pci_enable_device(pdev);
+ if (ret) {
+ dev_err(&pdev->dev, "%s: pci_enable_device failed\n", __func__);
+ return ret;
+ }
+ pci_enable_wake(pdev, PCI_D3hot, 0);
+ return 0;
+}
+#else
+#define pch_suspend NULL
+#define pch_resume NULL
+#endif
+
+static void __devexit pch_remove(struct pci_dev *pdev)
+{
+ struct pch_dev *chip = pci_get_drvdata(pdev);
+
+ ptp_clock_unregister(chip->ptp_clock);
+ /* free the interrupt */
+ if (pdev->irq != 0)
+ free_irq(pdev->irq, chip);
+
+ /* unmap the virtual IO memory space */
+ if (chip->regs != 0) {
+ iounmap(chip->regs);
+ chip->regs = 0;
+ }
+ /* release the reserved IO memory space */
+ if (chip->mem_base != 0) {
+ release_mem_region(chip->mem_base, chip->mem_size);
+ chip->mem_base = 0;
+ }
+ pci_disable_device(pdev);
+ kfree(chip);
+ dev_info(&pdev->dev, "%s: complete\n", __func__);
+}
+
+static s32 __devinit
+pch_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+ s32 ret;
+ unsigned long flags;
+ struct pch_dev *chip;
+
+ chip = kzalloc(sizeof(struct pch_dev), GFP_KERNEL);
+ if (chip == NULL)
+ return -ENOMEM;
+
+ /* enable the 1588 pci device */
+ ret = pci_enable_device(pdev);
+ if (ret != 0) {
+ dev_err(&pdev->dev,
+ "%s:could not enable the pci device\n", __func__);
+ goto err_pci_en;
+ }
+
+ chip->mem_base = pci_resource_start(pdev, IO_MEM_BAR);
+ if (!chip->mem_base) {
+ dev_err(&pdev->dev,
+ "%s: could not locate IO memory address\n", __func__);
+ ret = -ENODEV;
+ goto err_pci_start;
+ }
+
+ /* retreive the available length of the IO memory space */
+ chip->mem_size = pci_resource_len(pdev, IO_MEM_BAR);
+
+ /* allocate the memory for the device registers */
+ 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__);
+ ret = -EBUSY;
+ goto err_req_mem_region;
+ }
+
+ /* get the virtual address to the 1588 registers */
+ chip->regs = ioremap(chip->mem_base, chip->mem_size);
+
+ if (!chip->regs) {
+ dev_err(&pdev->dev, "%s: Could not get virtual address\n",
+ __func__);
+ ret = -ENOMEM;
+ goto err_ioremap;
+ }
+
+ chip->caps = ptp_pch_caps;
+ chip->ptp_clock = ptp_clock_register(&chip->caps);
+
+ if (IS_ERR(chip->ptp_clock))
+ return PTR_ERR(chip->ptp_clock);
+
+ spin_lock_init(&chip->register_lock);
+
+ ret = request_irq(pdev->irq, &isr, IRQF_SHARED, KBUILD_MODNAME, chip);
+ if (ret != 0) {
+ dev_err(&pdev->dev, "%s: failed to get irq %d\n", __func__,
+ pdev->irq);
+ goto err_req_irq;
+ }
+
+ /* indicate success */
+ chip->irq = pdev->irq;
+ chip->pdev = pdev;
+ pci_set_drvdata(pdev, chip);
+
+ spin_lock_irqsave(&chip->register_lock, flags);
+ /* reset the ieee1588 h/w */
+ pch_reset(chip);
+
+ iowrite32(DEFAULT_ADDEND, &chip->regs->addend);
+ iowrite32(1, &chip->regs->trgt_lo);
+ iowrite32(0, &chip->regs->trgt_hi);
+ iowrite32(PCH_TSE_TTIPEND, &chip->regs->event);
+ /* Version: IEEE1588 v1 and IEEE1588-2008, Mode: All Evwnt, Locked */
+ iowrite32(0x80020000, &chip->regs->ch_control);
+
+ pch_eth_enable_set(chip);
+
+ 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__);
+ }
+ }
+ spin_unlock_irqrestore(&chip->register_lock, flags);
+ return 0;
+
+err_req_irq:
+ ptp_clock_unregister(chip->ptp_clock);
+ iounmap(chip->regs);
+ chip->regs = 0;
+
+err_ioremap:
+ release_mem_region(chip->mem_base, chip->mem_size);
+
+err_req_mem_region:
+ chip->mem_base = 0;
+
+err_pci_start:
+ pci_disable_device(pdev);
+
+err_pci_en:
+ kfree(chip);
+ dev_err(&pdev->dev, "%s: probe failed(ret=0x%x)\n", __func__, ret);
+
+ return ret;
+}
+
+static DEFINE_PCI_DEVICE_TABLE(pch_ieee1588_pcidev_id) = {
+ {
+ .vendor = PCI_VENDOR_ID_INTEL,
+ .device = PCI_DEVICE_ID_PCH_1588
+ },
+ {0}
+};
+
+static struct pci_driver pch_pcidev = {
+ .name = KBUILD_MODNAME,
+ .id_table = pch_ieee1588_pcidev_id,
+ .probe = pch_probe,
+ .remove = pch_remove,
+ .suspend = pch_suspend,
+ .resume = pch_resume,
+};
+
+static void __exit ptp_pch_exit(void)
+{
+ pci_unregister_driver(&pch_pcidev);
+}
+
+static s32 __init ptp_pch_init(void)
+{
+ s32 ret;
+
+ /* register the driver with the pci core */
+ ret = pci_register_driver(&pch_pcidev);
+
+ return ret;
+}
+
+module_init(ptp_pch_init);
+module_exit(ptp_pch_exit);
+
+module_param_string(station, pch_param.station, sizeof pch_param.station, 0444);
+MODULE_PARM_DESC(station,
+ "IEEE 1588 station address to use - column separated hex values");
+
+MODULE_AUTHOR("OKI SEMICONDUCTOR, <toshiharu-linux@dsn.okisemi.com>");
+MODULE_DESCRIPTION("PTP clock using the EG20T timer");
+MODULE_LICENSE("GPL");
+
--
1.7.4.4
^ permalink raw reply related
* Re: gianfar.c null pointer deref in gfar_start_xmit().
From: Eric Dumazet @ 2011-08-10 6:01 UTC (permalink / raw)
To: Robin Holt; +Cc: Sandeep Gopalpet, David S. Miller, netdev
In-Reply-To: <20110809130615.GT4926@sgi.com>
Le mardi 09 août 2011 à 08:06 -0500, Robin Holt a écrit :
> On Tue, Aug 09, 2011 at 09:10:13AM +0200, Eric Dumazet wrote:
> > Le mardi 09 août 2011 à 01:54 -0500, Robin Holt a écrit :
> > > On Tue, Aug 02, 2011 at 09:44:38PM -0500, Robin Holt wrote:
> > > >
> > > > While using the v3.0 kernel on a Freescale P1010RDB with 3 minor patches
> > > > (None which affect gianfar.c), I get a NULL pointer deref at:
> > > >
> > > > static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
> > > > {
> > > > ...
> > > > regs = tx_queue->grp->regs;
> > > >
> > > > I put a BUG_ON(tx_queue->grp) just before this line and it did trip.
> > > > I have not looked at this any more than that.
> > > >
> > > > Any suggestions would be welcome. To reproduce, all I need to do is
> > > > a few sequences of pings.
> > >
> > > I was able to reproduce this with the net-next-2.6 kernel as well.
> > >
> >
> > This driver incorrectly assumes a non dense txqueue array is possible
> > for a netdev, but its not true.
> >
> > In the meantime, you could force it to use one tx_queue only.
> >
> > tx_queues = (u32 *)of_get_property(np, "fsl,num_tx_queues", NULL);
> > num_tx_qs = tx_queues ? *tx_queues : 1;
>
> I fixed up the .dts file and now it works. I have not tested the RGMII
> interface yet so I do not know if that supports multiple queues. I assume
> I could find it in the documentation. What might I be looking for?
>
What exact change did you in dts ?
Assuming your p1010rdb is single core powerpc, I fail to see why 8
queues should be enabled on NIC. It only increases number of interrupts
if multiple flows are in use, and memory footprint.
^ permalink raw reply
* [linux-firmware 2/2] rtl_nic: add new firmware for RTL8111F
From: Hayes Wang @ 2011-08-10 5:41 UTC (permalink / raw)
To: dwmw2; +Cc: netdev, linux-kernel
In-Reply-To: <1312954862-32708-1-git-send-email-hayeswang@realtek.com>
From: Albert Kuo <albertk@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: Albert Kuo <albertk@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 4b88f1f..2b63594 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
+File: rtl_nic/rtl8168f-1.fw
+File: rtl_nic/rtl8168f-2.fw
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
* [linux-firmware 1/2] rtl_nic: update firmware for RTL8111E-VL
From: Hayes Wang @ 2011-08-10 5:41 UTC (permalink / raw)
To: dwmw2; +Cc: netdev, linux-kernel
From: Albert Kuo <albertk@realtek.com>
Updated firmware with stability fixes.
Version: rtl8168e-3_0.0.1.
Signed-off-by: Albert Kuo <albertk@realtek.com>
---
rtl_nic/rtl8168e-3.fw | Bin 2804 -> 3264 bytes
1 files changed, 0 insertions(+), 0 deletions(-)
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
* Re: [PATCH] Add pch ieee1588 driver for Intel EG20T PCH
From: Toshiharu Okada @ 2011-08-10 5:03 UTC (permalink / raw)
To: Richard Cochran
Cc: tomoya-linux, kok.howg.ewe, joel.clark, yong.y.wang, qi.wang,
linux-kernel, netdev, richard.cochran
In-Reply-To: <20110803192331.GA11166@riccoc20.at.omicron.at>
Hi Richard
I added comment below.
Please confirm them
> +/* Register read/write macros */
> +#define PCH_BIT_SET_CHECK(addr, bitmask) \
> + ((ioread32(addr) & (bitmask)) == (bitmask))
> +#define PCH_SET_ADDR_BIT(addr, bitmask)\
> + iowrite32((ioread32(addr) | (bitmask)), (addr))
> +#define PCH_CLR_ADDR_BIT(addr, bitmask)\
> + iowrite32((ioread32(addr) & ~(bitmask)), (addr))
>
>I don't really like macros of this sort, just to set and clear
>register bits. It doesn't make any fewer lines nor does it clarify the
>code. Every driver author will know what is meant by the plain old C,
>like:
>
> x = x | mask;
> x = x & ~mask;
>
>Also, you should consider whether you need to protect against
>concurrent access on a register.
modify
>> +
>> +#define DEFAULT_ADDEND 0xF0000029
>> +#define TICKS_NS_SHIFT 4
>
>This driver is based on my ixp46x driver, which is fine because,
>looking at the data sheet, it appears that the time stamping unit in
>the EG20T PCH is fairly similar.
>
>However, I doubt that these ADDEND and SHIFT values will work for you,
>since they were calculated for the frequency compensated clock on the
>IXP. They reflect an input clock frequency of 66.666666 MHz and a
>nominal frequency of 62.5 MHz (or a period of 16 nanoseconds, thus
>SHIFT is 4).
>
>Section 14.6.1.10 in the data sheet seems to imply that the input
>clock is 50 MHz. In that case you could use a nominal frequency of
>31.25 MHz (period 32 ns, SHIFT 5). However, you need to find out
>the actual input clock frequency. If this can vary, then the driver
>should allow changing these values.
modify as follows.
#define DEFAULT_ADDEND 0xA0000000
#define TICKS_NS_SHIFT 5
>> + u32 asms_hi;
>> + u32 amms_lo;
>> + u32 amms_hi;
>> + u32 ch_control;
>
>You never program this register. But I think the "Mode" field should
>be set to 2. The other settings really make no sense at all. Or do
>you set this in the MAC driver?
>
>(I wonder why Intel retained the very limited PTP V1 modes from the
>IXP time stamping unit.)
ch_control register was set as 0x80020000 (Version:1, mode:2 )
>> + u32 mem_base;
>> + u32 mem_size;
>> + u32 irq;
>> + u32 suspend:1;
>> + u32 initialized:1;
>> + struct pci_dev *pdev;
>> + spinlock_t lock;
>
>It would be nice to have a short comment telling what this lock
>protects. (Yes, I know what it protects, but still that is good
>practice to have a comment.)
It renames to "register_lock"
>> +static inline void pch_eth_enable_set(struct pch_dev *chip)
>> +{
>> + /* SET the eth_enable bit */
>> + PCH_SET_ADDR_BIT(&chip->regs->ts_sel, PCH_ECS_ETH);
>> +}
>
>I really don't like this or the other similar helper functions,
>below. They don't make the driver more understandable or shorter.
>This function is only used in one place. You need at least two callers
>to justify this.
modify
>I think the following helper functions ...
>
>> +static inline u32 pch_pps_evt_get(struct pch_dev *chip)
>> +{
>> + /* Poll for PPS event */
>> + return PCH_BIT_SET_CHECK(&chip->regs->event, PCH_TSE_PPS);
>> +}
:
:
>> +
>> +static inline void pch_ttm_evt_clear(struct pch_dev *chip)
>> +{
>> + /* Clear Target Time Reached event */
>> + PCH_SET_ADDR_BIT(&chip->regs->event, PCH_TSE_TTIPEND);
>> +}
>
>... are just noise and add nothing useful to the driver.
These functions are removed.
>> +static void pch_reset(struct pch_dev *chip)
>> +{
>> + /* Reset Hardware Assist */
>> + pch_block_reset(chip);
>> +
>> + /* enable all 32 bits in system time registers */
>> + pch_set_system_time_count(chip);
>> +}
>
>These three, above, are okay, since they encapsulate one logical
>operation that takes more than one register access.
>
>However, you might consider whether you need locking here.
add spin lock.
>> +static void pch_eth_enable(struct pch_dev *chip)
>> +{
>> + pch_eth_enable_set(chip);
>> +}
>
>Again, this helper only has one caller. Why not just set the bit that
>you need in line?
modify
> +
> +/*
> + * Interrupt service routine
> + */
> +static irqreturn_t isr(int irq, void *priv)
> +{
> + struct pch_dev *pch_dev = priv;
> + struct pch_ts_regs *regs = pch_dev->regs;
> + struct ptp_clock_event event;
> + u32 ack = 0, lo, hi, val;
> +
> + val = ioread32(®s->event);
> +
> + if (val & PCH_TSE_SNS) {
> + ack |= PCH_TSE_SNS;
> + if (pch_dev->exts0_enabled) {
> + hi = ioread32(®s->asms_hi);
> + lo = ioread32(®s->asms_lo);
> + event.type = PTP_CLOCK_EXTTS;
> + event.index = 0;
> + event.timestamp = ((u64) hi) << 32;
> + event.timestamp |= lo;
> + event.timestamp <<= TICKS_NS_SHIFT;
> + ptp_clock_event(pch_dev->ptp_clock, &event);
> + }
> + }
> +
> + if (val & PCH_TSE_SNM) {
> + ack |= PCH_TSE_SNM;
> + if (pch_dev->exts1_enabled) {
> + hi = ioread32(®s->amms_hi);
> + lo = ioread32(®s->amms_lo);
> + event.type = PTP_CLOCK_EXTTS;
> + event.index = 1;
> + event.timestamp = ((u64) hi) << 32;
> + event.timestamp |= lo;
> + event.timestamp <<= TICKS_NS_SHIFT;
> + ptp_clock_event(pch_dev->ptp_clock, &event);
> + }
> + }
> +
> + if (val & PCH_TSE_TTIPEND)
> + ack |= PCH_TSE_TTIPEND; /* this bit seems to be always set */
>
>This ISR code (and much of the rest of the driver) is copied from the
>IXP driver. It would be nice to know if it actually works on the atom
>hardware. Do have any hardware to try it on?
We have a board of atom(E600) and EG20T.
However there is no environment for confirming auxiliary snapshot.
>> +static struct ptp_clock_info ptp_pch_caps = {
>> + .owner = THIS_MODULE,
>> + .name = "PCH timer",
>> + .max_adj = 66666655,
>
>This should be recalculated once you figure out the input clock and
>nominal frequency.
modify to .max_adj = 50000000,
>> +#ifdef CONFIG_PM
>> +static s32 pch_suspend(struct pci_dev *pdev, pm_message_t state)
>> +{
>> + struct pch_dev *chip = pci_get_drvdata(pdev);
>> +
>> + chip->suspend = 1;
>
>You set this flag here ...
remove
>> + /* allocate the memory for the device registers */
>> + if (!request_mem_region
>> + (chip->mem_base, chip->mem_size, "1588_regs")) {
>
>Poor statement break (and this would fit all on one line).
modify
> + dev_err(&pdev->dev,
> + "%s: could not allocate register memory space\n", __func__);
>
>Bad indentation.
modify
>> + if (ret != 0) {
>> + dev_err(&pdev->dev,
>> + "%s: failed to get irq %d\n", __func__, pdev->irq);
>> + goto err_req_irq;
>> + }
>> +
>> + chip->initialized = 1;
>
>You set this flag, but never use it.
remove
>> +
>> +static DEFINE_PCI_DEVICE_TABLE(pch_gbe_pcidev_id) = {
>> + {.vendor = PCI_VENDOR_ID_INTEL,
>
>Needs a space (or newline) before the dot.
modify
>> +
>> +static struct pci_driver pch_pcidev = {
>> + .name = KBUILD_MODNAME,
>> + .id_table = pch_pcidev_id,
>
>Here you meant "pch_gbe_pcidev_id" instead (or no "gbe" in the PCI
>device table).
modify
>Overall, the driver looks okay. I would appreciate if you would take a
>look at the comments and submit a revised patch.
>
>I would also like to see how the time stamps are done in the MAC
>driver. Have you already posted that?
>
Mac driver already upstreamed. ( drivers/net/pch_gbe)
However the code relevant to IEEE1588 is not contained into Ethernet driver.
I have question about rx/tx snapshot.
Is it necessary to use a snapshot within an Ethernet driver driver?
I was indicated that there must not be any dependence of a device when the
Ethernet driver was upstreamed.
>Feature request: I notice in the data sheet that the time stamping
>unit can produce a PPS output. Any chance that you could program this
>feature?
Currently, there is no plan.
Best Regards
Toshiharu Okada
^ permalink raw reply
* Re: [PATCH] net_sched: prio: use qdisc_dequeue_peeked
From: David Miller @ 2011-08-10 4:52 UTC (permalink / raw)
To: fw; +Cc: netdev, eric.dumazet
In-Reply-To: <1312891483-30034-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Tue, 9 Aug 2011 14:04:43 +0200
> commit 07bd8df5df4369487812bf85a237322ff3569b77
> (sch_sfq: fix peek() implementation) changed sfq to use generic
> peek helper.
>
> This makes HFSC complain about a non-work-conserving child qdisc, if
> prio with sfq child is used within hfsc:
>
> hfsc peeks into prio qdisc, which will then peek into sfq.
> returned skb is stashed in sch->gso_skb.
>
> Next, hfsc tries to dequeue from prio, but prio will call sfq dequeue
> directly, which may return NULL instead of previously peeked-at skb.
>
> Have prio call qdisc_dequeue_peeked, so sfq->dequeue() is
> not called in this case.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied and queued up for -stable, thanks!
^ 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