* Re: [PATCHv3 6/6] mISDN: Help to identify the card
From: Karsten Keil @ 2012-05-04 15:58 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: David Miller, netdev, Karsten Keil
In-Reply-To: <CAP=VYLpKjFHx7b3oTjz7a8wvxQmPME-sK147n8CX6y8+Pii2rg@mail.gmail.com>
Am 04.05.2012 16:48, schrieb Paul Gortmaker:
> On Fri, May 4, 2012 at 10:15 AM, Karsten Keil <kkeil@linux-pingi.de> wrote:
>> From: Karsten Keil <isdn@linux-pingi.de>
>>
>> With multiple cards is hard to figure out which port caused trouble
>> int the layer2 routines (e.g. got a timeout).
>> Now we have the informations in the log output.
>
> If you are in here changing all these printk(KERN_LEVEL ...) lines anyway,
> then perhaps it is a good time to make use of pr_warn() and friends to
> help avoid some multi-line fragmentation things like this:
>
>> printk(KERN_WARNING
>> "%s: windowar[%d] is NULL\n",
>> - __func__, p1);
>> + mISDNDevName4ch(&l2->ch), p1);
>> l2->windowar[p1] = NULL;
>
Good point, but this should be consolidated over the complete project.
Will put this on TODO, after the current issues are solved.
Thanks
Karsten
^ permalink raw reply
* Re: [PATCH net-next] tcp: be more strict before accepting ECN negociation
From: David Miller @ 2012-05-04 16:06 UTC (permalink / raw)
To: eric.dumazet
Cc: netdev, perryl, mattmathis, ycheng, ncardwell, therbert, wilmer,
dave.taht, jankur
In-Reply-To: <1336144442.3752.348.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 04 May 2012 17:14:02 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> It appears some networks play bad games with the two bits reserved for
> ECN. This can trigger false congestion notifications and very slow
> transferts.
>
> Since RFC 3168 (6.1.1) forbids SYN packets to carry CT bits, we can
> disable TCP ECN negociation if it happens we receive mangled CT bits in
> the SYN packet.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [net v2 0/4][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2012-05-04 16:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, gospo, sassmann
In-Reply-To: <20120504.105815.2251328360345706986.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 927 bytes --]
On Fri, 2012-05-04 at 10:58 -0400, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Fri, 4 May 2012 04:05:00 -0700
>
> > This series of patches contains fixes for ixgbe, igb and e1000.
> >
> > v2: Added e1000 patch to fix sparse warnings and igb/ixgbe to
> > correct an issue of calling function to reset Tx queue in
> > init path.
> >
> > The following are changes since commit 5a8887d39e1ba5ee2d4ccb94b14d6f2dce5ddfca:
> > sungem: Fix WakeOnLan
> > and are available in the git repository at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master`
>
> I pulled, but what is that "`" character doing at the end of that GIT url?
> I removed it when I pulled as you don't seem to have a "master`" branch in
> your tree as far as I can tell.
Sorry about that, not sure what happened there. Guess I missed the ESC
key when editing the cover...
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks
From: Mark A. Greer @ 2012-05-04 16:35 UTC (permalink / raw)
To: Bedia, Vaibhav
Cc: Hilman, Kevin, Ben Hutchings, netdev@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EA81B04@DBDE01.ent.ti.com>
On Fri, May 04, 2012 at 01:55:58PM +0000, Bedia, Vaibhav wrote:
Hi Vaibhav.
> Hi Kevin,
>
> On Fri, May 04, 2012 at 03:02:16, Hilman, Kevin wrote:
> > Ben Hutchings <bhutchings@solarflare.com> writes:
> >
> > > On Thu, 2012-05-03 at 19:25 +0000, Bedia, Vaibhav wrote:
> > >> On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote:
> > >> [...]
> > >> > >
> > >> > > So, if I understood this correctly, it's effectively like blocking a low power
> > >> > > state transition (here wfi execution) when EMAC is active?
> > >> >
> > >> > Assuming "it" is my patch, correct.
> > >> >
> > >>
> > >> Recently I was thinking about how to get certain drivers to disallow some or all
> > >> low power states and to me this also seems to fall in a similar category.
> > >>
> > >> One of the suggestions that I got was to check if the 'wakeup' entry associated with
> > >> the device under sysfs could be leveraged for this. The PM code could maintain
> > >> a whitelist (or blacklist) of devices and it decides the low power state to enter
> > >> based on the 'wakeup' entries associated with these devices. In this particular case,
> > >> maybe the driver could simply set this entry to non-wakeup capable when necessary and
> > >> then let the PM code take care of skipping the wfi execution.
> > >>
> > >> Thoughts/brickbats welcome :)
> > >
> > > You can maybe (ab)use the pm_qos mechanism for this.
> >
> > I thought of using this too, but it doesn't actually solve the problem:
> >
> > Using PM QoS, you can avoid hitting the deeper idle states by setting a
> > very low wakeup latency. However, on ARM platforms, even the shallowest
> > idle states use the WFI instruction, and the EMAC would still not be
> > able to wake the system from WFI. A possibility would be define the
> > shallowest idle state to be one that doesn't call WFI and just does
> > cpu_relax(). However, that would only work for CPUidle since PM QoS
> > constraints are only checked by CPUidle. So, a non-CPUidle kernel would
> > still have this bug. :(
> >
> > Ultimately, this is just broken HW. This network HW was bolted onto an
> > existing SoC without consideration for wakeup capabilities. The result
> > is that any use of this device with networking has to completely disable
> > SoC power management.
> >
>
> I was checking with internally with some folks on the issue being addressed
> in this patch and unfortunately no one seems to be aware of this :(
This is from the TI hardware engineer that I talked to after spending many
hours trying to get the EMAC to wake up the system. It was a private
conversation so I won't share his name/email here. If you want to contact
him, please reach me privately.
"No, AM35x can't be waken up from CPGMAC. If customer need to wake AM35x
up from Ethernet, a wake up interrupt signal from Ethernet phy should be
connected to one of wakeup capable GPIO pins."
> Mark mentioned nfs mounted rootfs being slow but in my limited testing I
> didn't observe this on an AM3517 board. I am yet to go through the PSP code
> to be fully sure that wfi instruction is indeed being executed but I wanted
> to check if I need to do something specific to reproduce this at my end.
When you go through the PSP code, look for the definition & use of
omap3_can_sleep(). That routine returns '0' when either cpu_is_omap3505()
or cpu_is_omap3517() ruturns true (among other conditions). You will see
that its used in omap3_pm_idle() to exit early so pm_idle never executes
the wfi.
I expect that you don't have CONFIG_CPU_IDLE enabled, so cpuidle has no
opportunity to execute a wfi. If it is enabled, omap3_can_sleep() is
used in omap3_idle_bm_check() which is used in omap3_enter_idle_bm()
so the wfi won't be executed when omap3_enter_idle_bm() is called.
omap3_enter_idle() isn't called (in my testing--the code is very
different from current k.o.) so it doesn't execute the wfi either.
Therefore, you don't see an issue when running PSP code.
> Irrespective of the above problem being present in the h/w, I feel the approach
> of adding platform callbacks for blocking deeper idle states will create problems
> when this is required for multiple peripherals. I agree that the default behavior
> should be to support the deepest idle state based on the peripherals being used but
> IMO the user should have the flexibility to change this behavior if he wishes
> to do so.
I agree but hopefully this doesn't become common. The real issue is a
missing hardware feature that--again, hopefully--won't become common.
Mark
^ permalink raw reply
* Re: [PATCH net-next] tcp: be more strict before accepting ECN negociation
From: Rick Jones @ 2012-05-04 18:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Perry Lorier, Matt Mathis, Yuchung Cheng,
Neal Cardwell, Tom Herbert, Wilmer van der Gaast, Dave Täht,
Ankur Jain
In-Reply-To: <1336144442.3752.348.camel@edumazet-glaptop>
On 05/04/2012 08:14 AM, Eric Dumazet wrote:
> From: Eric Dumazet<edumazet@google.com>
>
> It appears some networks play bad games with the two bits reserved for
> ECN. This can trigger false congestion notifications and very slow
> transferts.
>
> Since RFC 3168 (6.1.1) forbids SYN packets to carry CT bits, we can
> disable TCP ECN negociation if it happens we receive mangled CT bits in
> the SYN packet.
What sort of networks were these? Any chance it was some sort of
attempt to add ECN to FastOpen?
rick jones
^ permalink raw reply
* Re: [PATCH 04/15] drivers/net: Do not free an IRQ if its request failed
From: Linus Walleij @ 2012-05-04 18:22 UTC (permalink / raw)
To: Lee Jones
Cc: linux, linus.walleij, arnd, netdev, grant.likely, cjb,
linux-arm-kernel
In-Reply-To: <4FA3E35B.3000604@linaro.org>
On Fri, May 4, 2012 at 4:10 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On 19/04/12 21:36, Lee Jones wrote:
>> - goto out_free_irq;
>> + goto out_disable_resources;
>> }
>>
>> retval = register_netdev(dev);
>
>
> Anything on this from the Net guys?
This was merged for 3.4-rc5, check:
https://lkml.org/lkml/2012/4/29/2
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next] tcp: be more strict before accepting ECN negociation
From: Eric Dumazet @ 2012-05-04 18:23 UTC (permalink / raw)
To: Rick Jones
Cc: David Miller, netdev, Perry Lorier, Matt Mathis, Yuchung Cheng,
Neal Cardwell, Tom Herbert, Wilmer van der Gaast, Dave Täht,
Ankur Jain
In-Reply-To: <4FA41B5B.5080103@hp.com>
On Fri, 2012-05-04 at 11:09 -0700, Rick Jones wrote:
> On 05/04/2012 08:14 AM, Eric Dumazet wrote:
> > From: Eric Dumazet<edumazet@google.com>
> >
> > It appears some networks play bad games with the two bits reserved for
> > ECN. This can trigger false congestion notifications and very slow
> > transferts.
> >
> > Since RFC 3168 (6.1.1) forbids SYN packets to carry CT bits, we can
> > disable TCP ECN negociation if it happens we receive mangled CT bits in
> > the SYN packet.
>
> What sort of networks were these? Any chance it was some sort of
> attempt to add ECN to FastOpen?
Nothing to do with fastopen.
Just take a look at a random http server and sample all SYN packets it
receives.
Some of them have TOS bits 0 or 1 set, or even both bits set.
^ permalink raw reply
* Re: [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks
From: Mark A. Greer @ 2012-05-04 18:29 UTC (permalink / raw)
To: Kevin Hilman
Cc: Bedia, Vaibhav, nsekhar, Ben Hutchings, netdev@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <87fwbgdnlp.fsf@ti.com>
On Fri, May 04, 2012 at 07:31:30AM -0700, Kevin Hilman wrote:
> "Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes:
Hi Kevin.
> > If it does, perhaps there should some other mechanism for letting
> > users control the system behavior.
>
> Come to think of it, the right solution here is probably to use runtime
> PM. We could then to add some custom hooks for davinci_emac in the
> device code to use enable_hlt/disable_hlt based on activity.
That was my first thought, actually, but that only works if its
okay for the driver to call enable_hlt/disable_hlt directly (i.e.,
have runtime_suspend() call enable_hlt() and runtime_resume() call
disable_hlt()). However, I assumed it would _not_ be acceptable for
the driver to issue those calls directly. Its a platform-specific
issue that we shouldn't be polluting the driver with and there are
currently no drivers that call them under the drivers directory.
If its not okay to call enable_hlt/disable_hlt directly, then we still
need callback hooks to the plaform code (i.e., some version of this
patch).
> In order to do that though, the davinci_emac driver needs to be runtime
> PM converted.
We probably should pm_runtime-ize the driver either way but we need
to resolve the question of whether its okay for the driver to call
enable_hlt/disable_hlt directly or not. If it is okay, we call them
in runtime_suspend/resume. If it isn't okay, then we still need
platform callback hooks.
Mark
^ permalink raw reply
* Re: [PATCH v3 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board
From: Sekhar Nori @ 2012-05-04 18:36 UTC (permalink / raw)
To: hs-ynQEQJNshbs
Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
David Woodhouse, Ben Dooks, Wolfram Sang, Kevin Hilman,
Wolfgang Denk, Sergei Shtylyov, Grant Likely, Rob Herring
In-Reply-To: <4FA3F6C2.9010602-ynQEQJNshbs@public.gmane.org>
Hi Heiko,
On 5/4/2012 9:03 PM, Heiko Schocher wrote:
> Hello,
>
> this v3 patchset is now pending for more than 1 month without
> seeing comments for it. Are there no more issues?
I am yet to get to them. I have mostly cleared my backlog and will be
looking into these next. Sorry about the delay.
> Should I rebase it (if no further comments occur), as it is
> pending so long? (If so, against which tree?)
The series touches multiple subsystems, so may be each patch will go
through individual subsystem maintainer.
Also copying Grant and Rob as device tree maintainers.
Thanks,
Sekhar
>
> Thanks.
>
> bye,
> Heiko
>
> Heiko Schocher wrote:
>> This patchserie add support for the davinci am1808 based
>> enbw_cmc board.
>>
>> Important: I rebased this patchserie against the irqdomain/next
>> branch from grant likely, as he suggested to rework the OF
>> intcontroller changes to the irqdomain work, branch found here:
>>
>> http://git.secretlab.ca/?p=linux-2.6.git;a=shortlog;h=refs/heads/irqdomain/next
>>
>> git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
>>
>> commit 280ad7fda5f95211857fda38960f2b6fdf6edd3e
>> Author: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
>> Date: Fri Feb 24 14:58:54 2012 -0700
>>
>> mfd: twl-core: Add IRQ_DOMAIN dependency
>>
>> changes for v2:
>> Post this patchserie now as v2, as reworked in the
>> comments I got for the RFC serie.
>>
>> changes for v3:
>> - Interrupt Controller:
>> - comment from Sergei Shtylyov:
>> - rename compatible" prop to "ti,cp_intc"
>> - cp_intc_init() is now also for the of case
>> the name of the init function (it calls the
>> "new" __cp_intc_init() function, which was
>> the "old" cp_intc_init()). Through this
>> rework the changes for OF is better visible.
>> As the OF case uses the irq_domain rework from
>> Grant Likely, maybe the none OF case can use
>> this also, but this should be tested on a hw ...
>>
>> Got no comments to the following points, I noted in the
>> RFC series, so posting this patchseries with them:
>>
>> - ARM: davinci: configure davinci aemif chipselects through OF
>> not moved to mfd, as mentioned in this discussion:
>> http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-td7059739.html
>> instead use a phandle in the DTS, so drivers which
>> uses the davinci aemif, can call davinci_aemif_setup_timing_of()
>>
>> This is just thought as an RFC ... The enbw_cmc board
>> support not really need to setup this bus timings, as
>> they are setup in U-Boot ... but I want to post this,
>> as I think, it is a nice to have, and I am not really
>> sure, if this has to be a MFD device (If so, all bus
>> interfaces for other SoCs should be converted also to
>> MFD devices) ... as an example how this can be used
>> I add this to the davinci nand controller OF support
>> patch, in this patchserie.
>>
>> - ARM: davinci: mux: add OF support
>> I want to get rid of the pin setup code in board code ...
>> This patch introduces a davinci_cfg_reg_of() function,
>> which davinci drivers can call, if they found a
>> "pinmux-handle", so used in the following drivers in
>> this patchserie:
>>
>> drivers/net/ethernet/ti/davinci_emac
>> drivers/i2c/busses/i2c-davinci.c
>> drivers/mtd/nand/davinci_nand.c
>>
>> - post this board support with USB support, even though
>> USB is only working with the 10 ms "workaround", posted here:
>> http://comments.gmane.org/gmane.linux.usb.general/54505
>> I see this issue also on the AM1808 TMDXEXP1808L evalboard.
>>
>> - MMC and USB are not using OF support yet, ideas how to port
>> this are welcome. I need for USB and MMC board specific
>> callbacks, how to solve this with OF support?
>>
>> Signed-off-by: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
>> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
>> Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
>> Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
>> Cc: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
>> Cc: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> Cc: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
>> Cc: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>
>> Cc: Wolfgang Denk <wd-ynQEQJNshbs@public.gmane.org>
>> Cc: Sergei Shtylyov <sshtylyov-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
>>
>> Heiko Schocher (7):
>> ARM: davinci, intc: Add OF support for TI interrupt controller
>> ARM: davinci: configure davinci aemif chipselects through OF
>> ARM: davinci: mux: add OF support
>> ARM: davinci: net: davinci_emac: add OF support
>> ARM: davinci: i2c: add OF support
>> ARM: mtd: nand: davinci: add OF support for davinci nand controller
>> ARM: davinci: add support for the am1808 based enbw_cmc board
>>
>> .../devicetree/bindings/arm/davinci/aemif.txt | 119 ++++++
>> .../bindings/arm/davinci/davinci_emac.txt | 43 +++
>> .../devicetree/bindings/arm/davinci/i2c.txt | 33 ++
>> .../devicetree/bindings/arm/davinci/intc.txt | 27 ++
>> .../devicetree/bindings/arm/davinci/mux.txt | 40 ++
>> .../devicetree/bindings/arm/davinci/nand.txt | 74 ++++
>> arch/arm/boot/dts/enbw_cmc.dts | 268 ++++++++++++++
>> arch/arm/configs/enbw_cmc_defconfig | 123 +++++++
>> arch/arm/mach-davinci/Kconfig | 9 +
>> arch/arm/mach-davinci/Makefile | 1 +
>> arch/arm/mach-davinci/aemif.c | 86 +++++-
>> arch/arm/mach-davinci/board-enbw-cmc.c | 380 ++++++++++++++++++++
>> arch/arm/mach-davinci/cp_intc.c | 87 ++++-
>> arch/arm/mach-davinci/include/mach/aemif.h | 1 +
>> arch/arm/mach-davinci/include/mach/mux.h | 2 +
>> arch/arm/mach-davinci/include/mach/uncompress.h | 1 +
>> arch/arm/mach-davinci/mux.c | 73 ++++-
>> drivers/i2c/busses/i2c-davinci.c | 37 ++
>> drivers/mtd/nand/davinci_nand.c | 85 +++++-
>> drivers/net/ethernet/ti/davinci_emac.c | 94 +++++-
>> 20 files changed, 1569 insertions(+), 14 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt
>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt
>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/mux.txt
>> create mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt
>> create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
>> create mode 100644 arch/arm/configs/enbw_cmc_defconfig
>> create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c
>>
>
^ permalink raw reply
* Re: [PATCH net-next] tcp: be more strict before accepting ECN negociation
From: Rick Jones @ 2012-05-04 18:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Perry Lorier, Matt Mathis, Yuchung Cheng,
Neal Cardwell, Tom Herbert, Wilmer van der Gaast, Dave Täht,
Ankur Jain
In-Reply-To: <1336155815.3752.365.camel@edumazet-glaptop>
On 05/04/2012 11:23 AM, Eric Dumazet wrote:
> On Fri, 2012-05-04 at 11:09 -0700, Rick Jones wrote:
>> What sort of networks were these? Any chance it was some sort of
>> attempt to add ECN to FastOpen?
>
> Nothing to do with fastopen.
>
> Just take a look at a random http server and sample all SYN packets it
> receives.
>
> Some of them have TOS bits 0 or 1 set, or even both bits set.
I'll fire-up tcpdump on netperf.org:
tcpdump -i eth0 -vvv '(tcp[tcpflags] & tcp-syn != 0) && (ip[1] != 0x0)'
and see what appears.
rick
^ permalink raw reply
* Re: [PATCH net-next] tcp: be more strict before accepting ECN negociation
From: Eric Dumazet @ 2012-05-04 19:05 UTC (permalink / raw)
To: Rick Jones
Cc: David Miller, netdev, Perry Lorier, Matt Mathis, Yuchung Cheng,
Neal Cardwell, Tom Herbert, Wilmer van der Gaast, Dave Täht,
Ankur Jain
In-Reply-To: <4FA42491.2020104@hp.com>
On Fri, 2012-05-04 at 11:48 -0700, Rick Jones wrote:
> On 05/04/2012 11:23 AM, Eric Dumazet wrote:
> > On Fri, 2012-05-04 at 11:09 -0700, Rick Jones wrote:
> >> What sort of networks were these? Any chance it was some sort of
> >> attempt to add ECN to FastOpen?
> >
> > Nothing to do with fastopen.
> >
> > Just take a look at a random http server and sample all SYN packets it
> > receives.
> >
> > Some of them have TOS bits 0 or 1 set, or even both bits set.
>
> I'll fire-up tcpdump on netperf.org:
>
> tcpdump -i eth0 -vvv '(tcp[tcpflags] & tcp-syn != 0) && (ip[1] != 0x0)'
>
> and see what appears.
>
> rick
of (ip[1] & 3 != 0)
Note that you could catch SYNACK with this filter (if your machine
initiates some active TCP sessions), since SYNACK might have ECT bits,
if some stacks implemented :
http://tools.ietf.org/html/draft-kuzmanovic-ecn-syn-00 ( Adding
Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK
Packets )
http://tools.ietf.org/id/draft-ietf-tcpm-ecnsyn-04.txt
^ permalink raw reply
* Re: [PATCH] bnx2x: bug fix when loading after SAN boot
From: Eilon Greenstein @ 2012-05-04 19:15 UTC (permalink / raw)
To: David Miller; +Cc: ariele, netdev
In-Reply-To: <20120504.115753.1701261151183409987.davem@davemloft.net>
On Fri, 2012-05-04 at 11:57 -0400, David Miller wrote:
> From: "Ariel Elior" <ariele@broadcom.com>
> Date: Thu, 3 May 2012 11:22:00 +0300
>
> > + /* clear hw from errors which mnay have resulted from an interrupted
> > + * dmae transaction.
> > + */
>
> Please fix the typos in this comment.
>
Sure - thanks for pointing that out:
Subject: [PATCH net v2] bnx2x: bug fix when loading after SAN boot
From: Ariel Elior <ariele@broadcom.com>
This is a bug fix for an "interface fails to load" issue.
The issue occurs when bnx2x driver loads after UNDI driver was previously
loaded over the chip. In such a scenario the UNDI driver is loaded and operates
in the pre-boot kernel, within its own specific host memory address range.
When the pre-boot stage is complete, the real kernel is loaded, in a new and
distinct host memory address range. The transition from pre-boot stage to boot
is asynchronous from UNDI point of view.
A race condition occurs when UNDI driver triggers a DMAE transaction to valid
host addresses in the pre-boot stage, when control is diverted to the real
kernel. This results in access to illegal addresses by our HW as the addresses
which were valid in the preboot stage are no longer considered valid.
Specifically, the 'was_error' bit in the pci glue of our device is set. This
causes all following pci transactions from chip to host to timeout (in
accordance to the pci spec).
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 23 +++++++++++++++++++++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index e077d25..795fc49 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9122,13 +9122,34 @@ static int __devinit bnx2x_prev_unload_common(struct bnx2x *bp)
return bnx2x_prev_mcp_done(bp);
}
+/* previous driver DMAE transaction may have occurred when pre-boot stage ended
+ * and boot began, or when kdump kernel was loaded. Either case would invalidate
+ * the addresses of the transaction, resulting in was-error bit set in the pci
+ * causing all hw-to-host pcie transactions to timeout. If this happened we want
+ * to clear the interrupt which detected this from the pglueb and the was done
+ * bit
+ */
+static void __devinit bnx2x_prev_interrupted_dmae(struct bnx2x *bp)
+{
+ u32 val = REG_RD(bp, PGLUE_B_REG_PGLUE_B_INT_STS);
+ if (val & PGLUE_B_PGLUE_B_INT_STS_REG_WAS_ERROR_ATTN) {
+ BNX2X_ERR("was error bit was found to be set in pglueb upon startup. Clearing");
+ REG_WR(bp, PGLUE_B_REG_WAS_ERROR_PF_7_0_CLR, 1 << BP_FUNC(bp));
+ }
+}
+
static int __devinit bnx2x_prev_unload(struct bnx2x *bp)
{
int time_counter = 10;
u32 rc, fw, hw_lock_reg, hw_lock_val;
BNX2X_DEV_INFO("Entering Previous Unload Flow\n");
- /* Release previously held locks */
+ /* clear hw from errors which may have resulted from an interrupted
+ * dmae transaction.
+ */
+ bnx2x_prev_interrupted_dmae(bp);
+
+ /* Release previously held locks */
hw_lock_reg = (BP_FUNC(bp) <= 5) ?
(MISC_REG_DRIVER_CONTROL_1 + BP_FUNC(bp) * 8) :
(MISC_REG_DRIVER_CONTROL_7 + (BP_FUNC(bp) - 6) * 8);
^ permalink raw reply related
* Re: [REGRESSION][PATCH] Fix an old sky2 WOL regression
From: dilieto @ 2012-05-04 20:17 UTC (permalink / raw)
To: Knut_Petersen
Cc: Linus Torvalds, Andrew Morton, Stephen Hemminger, David S. Miller,
arekm, Jared, linux-kernel, netdev
Dear Knut,
I am sorry it took a while to try it due to other
commitments, however I can now confirm the patch works on my ASUS P5LD2
motherboard.
Many thanks
Nicola
On 2012-03-21 12:40, Knut Petersen
wrote:
> Sky2 Wake on LAN is broken since February 2010 on a number of
systems.
> Yes. More than two years.
>
> We know about the problem and
the cause since October 2010
> (Bugzilla bug #19492). It´s commit
87b09f1f25cd1e01d7c50bf423c7fe33027d7511.
>
> Stephen, David: You
signed off that commit.
>
> Andrew: You called it a regression in
October 2010.
>
> It has been proposed to revert the commit that caused
the problem.
> Nothing happened.
>
> I proposed to re-establish the old
code for dmi_match()ed systems.
> Without success.
>
> Now it is
proposed to re-establish the old code as a configuration option.
> If
nothing happens again I will propose a module parameter ;-)
>
>
Stephen, I don´t want to be a pain in the neck, and it is not my
intention
> to offend you by my "attitude". But I simply cannot
understand why this
> know regression is not fixed. The bit we talk
about is documented,
> and in fact it was set for a number of kernel
versions unconditionally.
> Nobody complained about ruined hardware or
minor problems.
>
> The systems affected are old enough that no
manufacturer cares about
> them, but they are still quite usable for a
lot of jobs (kernel 3.3 compile
> time here is below 15 minutes).
>
>
If there is a problem in the kernel and if we do know an easy solution,
> that solution should be commited to the kernel, no matter what is
written
> in some random documentation, no matter if we could blame
some
> BIOS authors. That´s the way Linux works - at least I thought
so.
>
> cu,
> Knut
^ permalink raw reply
* Re: [PATCH net-next] tcp: be more strict before accepting ECN negociation
From: Rick Jones @ 2012-05-04 20:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Perry Lorier, Matt Mathis, Yuchung Cheng,
Neal Cardwell, Tom Herbert, Wilmer van der Gaast, Dave Täht,
Ankur Jain
In-Reply-To: <1336158359.3752.382.camel@edumazet-glaptop>
On 05/04/2012 12:05 PM, Eric Dumazet wrote:
> On Fri, 2012-05-04 at 11:48 -0700, Rick Jones wrote:
>> I'll fire-up tcpdump on netperf.org:
>>
>> tcpdump -i eth0 -vvv '(tcp[tcpflags]& tcp-syn != 0)&& (ip[1] != 0x0)'
>>
>> and see what appears.
>>
>> rick
>
> of (ip[1]& 3 != 0)
True, I'm looking at more than the ECN bits, but in the 90 minutes the
tcpdump has been running there have been no packets with the any of the
8 bits at ip[1] being 1 anyway :) Netperf.org doesn't get a massive
quantity of traffic. It may go the entire week-end or longer without
seeing such a packet.
> Note that you could catch SYNACK with this filter (if your machine
> initiates some active TCP sessions), since SYNACK might have ECT bits,
> if some stacks implemented :
>
> http://tools.ietf.org/html/draft-kuzmanovic-ecn-syn-00 ( Adding
> Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK
> Packets )
>
> http://tools.ietf.org/id/draft-ietf-tcpm-ecnsyn-04.txt
True. I suspect that 99 times out of 10, the outbound connections
established by netperf.org are in response to traffic to netperf-talk,
which is itself a rather quiet list, so I'm not too worried about the
output being cluttered with false hits.
rick
^ permalink raw reply
* Re: [PATCH net-next] tcp: be more strict before accepting ECN negociation
From: Rick Jones @ 2012-05-04 20:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Perry Lorier, Matt Mathis, Yuchung Cheng,
Neal Cardwell, Tom Herbert, Wilmer van der Gaast, Dave Täht,
Ankur Jain
In-Reply-To: <4FA43A03.4090707@hp.com>
On 05/04/2012 01:20 PM, Rick Jones wrote:
> True, I'm looking at more than the ECN bits, but in the 90 minutes the
> tcpdump has been running there have been no packets with the any of the
> 8 bits at ip[1] being 1 anyway :) Netperf.org doesn't get a massive
> quantity of traffic. It may go the entire week-end or longer without
> seeing such a packet.
I see fate is working as intended, or someone decided to try to feed me
my words :) for within 6 minutes of my sending the above I got:
13:26:16.866007 IP (tos 0x3,CE, ttl 41, id 28850, offset 0, flags [DF],
proto TCP (6), length 64)
somesystemin.de.55363 > www.netperf.org.www: Flags [S], cksum
0x4cfc (correct), seq 304457158, win 65535, options [mss 1460,nop,wscale
3,nop,nop,TS val 288116308 ecr 0,sackOK,eol], length 0
13:26:17.831880 IP (tos 0x3,CE, ttl 41, id 6911, offset 0, flags [DF],
proto TCP (6), length 64)
somesystemin.de.55367 > www.netperf.org.www: Flags [S], cksum
0x17aa (correct), seq 586073737, win 65535, options [mss 1460,nop,wscale
3,nop,nop,TS val 288117270 ecr 0,sackOK,eol], length 0
13:26:17.831929 IP (tos 0x3,CE, ttl 41, id 28924, offset 0, flags [DF],
proto TCP (6), length 64)
somesystemin.de.55368 > www.netperf.org.www: Flags [S], cksum
0x07cc (correct), seq 1513398047, win 65535, options [mss
1460,nop,wscale 3,nop,nop,TS val 288117271 ecr 0,sackOK,eol], length 0
13:26:17.831952 IP (tos 0x3,CE, ttl 41, id 2494, offset 0, flags [DF],
proto TCP (6), length 64)
somesystemin.de.55366 > www.netperf.org.www: Flags [S], cksum
0x75f4 (correct), seq 1153058420, win 65535, options [mss
1460,nop,wscale 3,nop,nop,TS val 288117270 ecr 0,sackOK,eol], length 0
13:26:17.832177 IP (tos 0x3,CE, ttl 41, id 6854, offset 0, flags [DF],
proto TCP (6), length 64)
somesystemin.de.55365 > www.netperf.org.www: Flags [S], cksum
0xfca0 (correct), seq 2332522875, win 65535, options [mss
1460,nop,wscale 3,nop,nop,TS val 288117270 ecr 0,sackOK,eol], length 0
13:26:17.832239 IP (tos 0x3,CE, ttl 41, id 64733, offset 0, flags [DF],
proto TCP (6), length 64)
somesystemin.de.55364 > www.netperf.org.www: Flags [S], cksum
0x7414 (correct), seq 1544827132, win 65535, options [mss
1460,nop,wscale 3,nop,nop,TS val 288117270 ecr 0,sackOK,eol], length 0
13:26:38.649126 IP (tos 0x3,CE, ttl 41, id 9860, offset 0, flags [DF],
proto TCP (6), length 64)
somesystemin.de.55369 > www.netperf.org.www: Flags [S], cksum
0x6270 (correct), seq 683091230, win 65535, options [mss 1460,nop,wscale
3,nop,nop,TS val 288137968 ecr 0,sackOK,eol], length 0
13:26:39.417589 IP (tos 0x3,CE, ttl 41, id 13478, offset 0, flags [DF],
proto TCP (6), length 64)
somesystemin.de.55370 > www.netperf.org.www: Flags [S], cksum
0x2862 (correct), seq 3168323595, win 65535, options [mss
1460,nop,wscale 3,nop,nop,TS val 288138734 ecr 0,sackOK,eol], length 0
rick
^ permalink raw reply
* Re: [PATCH net-next] tcp: be more strict before accepting ECN negociation
From: Eric Dumazet @ 2012-05-04 20:49 UTC (permalink / raw)
To: Rick Jones
Cc: David Miller, netdev, Perry Lorier, Matt Mathis, Yuchung Cheng,
Neal Cardwell, Tom Herbert, Wilmer van der Gaast, Dave Täht,
Ankur Jain
In-Reply-To: <4FA43DCE.8040901@hp.com>
On Fri, 2012-05-04 at 13:36 -0700, Rick Jones wrote:
> On 05/04/2012 01:20 PM, Rick Jones wrote:
> > True, I'm looking at more than the ECN bits, but in the 90 minutes the
> > tcpdump has been running there have been no packets with the any of the
> > 8 bits at ip[1] being 1 anyway :) Netperf.org doesn't get a massive
> > quantity of traffic. It may go the entire week-end or longer without
> > seeing such a packet.
>
> I see fate is working as intended, or someone decided to try to feed me
> my words :) for within 6 minutes of my sending the above I got:
>
> 13:26:16.866007 IP (tos 0x3,CE, ttl 41, id 28850, offset 0, flags [DF],
> proto TCP (6), length 64)
> somesystemin.de.55363 > www.netperf.org.www: Flags [S], cksum
> 0x4cfc (correct), seq 304457158, win 65535, options [mss 1460,nop,wscale
> 3,nop,nop,TS val 288116308 ecr 0,sackOK,eol], length 0
> 13:26:17.831880 IP (tos 0x3,CE, ttl 41, id 6911, offset 0, flags [DF],
> proto TCP (6), length 64)
> somesystemin.de.55367 > www.netperf.org.www: Flags [S], cksum
> 0x17aa (correct), seq 586073737, win 65535, options [mss 1460,nop,wscale
> 3,nop,nop,TS val 288117270 ecr 0,sackOK,eol], length 0
> 13:26:17.831929 IP (tos 0x3,CE, ttl 41, id 28924, offset 0, flags [DF],
> proto TCP (6), length 64)
> somesystemin.de.55368 > www.netperf.org.www: Flags [S], cksum
> 0x07cc (correct), seq 1513398047, win 65535, options [mss
> 1460,nop,wscale 3,nop,nop,TS val 288117271 ecr 0,sackOK,eol], length 0
> 13:26:17.831952 IP (tos 0x3,CE, ttl 41, id 2494, offset 0, flags [DF],
> proto TCP (6), length 64)
> somesystemin.de.55366 > www.netperf.org.www: Flags [S], cksum
> 0x75f4 (correct), seq 1153058420, win 65535, options [mss
> 1460,nop,wscale 3,nop,nop,TS val 288117270 ecr 0,sackOK,eol], length 0
> 13:26:17.832177 IP (tos 0x3,CE, ttl 41, id 6854, offset 0, flags [DF],
> proto TCP (6), length 64)
> somesystemin.de.55365 > www.netperf.org.www: Flags [S], cksum
> 0xfca0 (correct), seq 2332522875, win 65535, options [mss
> 1460,nop,wscale 3,nop,nop,TS val 288117270 ecr 0,sackOK,eol], length 0
> 13:26:17.832239 IP (tos 0x3,CE, ttl 41, id 64733, offset 0, flags [DF],
> proto TCP (6), length 64)
> somesystemin.de.55364 > www.netperf.org.www: Flags [S], cksum
> 0x7414 (correct), seq 1544827132, win 65535, options [mss
> 1460,nop,wscale 3,nop,nop,TS val 288117270 ecr 0,sackOK,eol], length 0
> 13:26:38.649126 IP (tos 0x3,CE, ttl 41, id 9860, offset 0, flags [DF],
> proto TCP (6), length 64)
> somesystemin.de.55369 > www.netperf.org.www: Flags [S], cksum
> 0x6270 (correct), seq 683091230, win 65535, options [mss 1460,nop,wscale
> 3,nop,nop,TS val 288137968 ecr 0,sackOK,eol], length 0
> 13:26:39.417589 IP (tos 0x3,CE, ttl 41, id 13478, offset 0, flags [DF],
> proto TCP (6), length 64)
> somesystemin.de.55370 > www.netperf.org.www: Flags [S], cksum
> 0x2862 (correct), seq 3168323595, win 65535, options [mss
> 1460,nop,wscale 3,nop,nop,TS val 288138734 ecr 0,sackOK,eol], length 0
>
> rick
Interesting indeed ;)
Did you check if it was spoofed ?
(did the 3WHS really completed)
^ permalink raw reply
* Re: [PATCH v2] RPS: Sparse connection optimizations - v2
From: Eric Dumazet @ 2012-05-04 20:53 UTC (permalink / raw)
To: Tom Herbert; +Cc: Deng-Cheng Zhu, davem, netdev
In-Reply-To: <1336146448.3752.349.camel@edumazet-glaptop>
On Fri, 2012-05-04 at 17:47 +0200, Eric Dumazet wrote:
> On Fri, 2012-05-04 at 08:31 -0700, Tom Herbert wrote:
> > > I think the mechanisms of rps_dev_flow_table and cpu_flow (in this
> > > patch) are different: The former works along with rps_sock_flow_table
> > > whose CPU info is based on recvmsg by the application. But for the tests
> > > like what I did, there's no application involved.
> > >
> > While rps_sock_flow_table is currently only managed by recvmsg, it
> > still is the general mechanism that maps flows to CPUs for steering.
> > There should be nothing preventing you from populating and managing
> > entries in other ways.
>
> It might be done from a netfilter module, activated in FORWARD chain for
> example.
>
>
A good indicator of the network load of a cpu would be to gather
&per_cpu(softnet_data, cpu)->input_pkt_queue.qlen in an EWMA.
We could dynamically adjust active cpus in RPS set given the load of the
machine.
On low load, cpu handling NIC interrupt could also bypass RPS and avoid
IPI to other cpus for low overhead.
tcpu = map->cpus[((u64) skb->rxhash * map->len) >> 32];
->
if (map->curlen) {
tcpu = map->cpus[((u64) skb->rxhash * map->curlen) >> 32];
if (cpu_online(tcpu))
return tcpu;
}
return -1;
Every second or so (to reduce Out Of Order impact), allow curlen to be
incremented/decremented in [0 .. map->len] if load is
increasing/lowering.
^ permalink raw reply
* Re: [PATCH net-next] tcp: be more strict before accepting ECN negociation
From: Rick Jones @ 2012-05-04 21:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Perry Lorier, Matt Mathis, Yuchung Cheng,
Neal Cardwell, Tom Herbert, Wilmer van der Gaast, Dave Täht,
Ankur Jain
In-Reply-To: <1336164546.3752.460.camel@edumazet-glaptop>
>
> Interesting indeed ;)
>
> Did you check if it was spoofed ?
>
> (did the 3WHS really completed)
Well, the tcpdump command was still:
tcpdump -i eth0 -vvv '(tcp[tcpflags]& tcp-syn != 0)&& (ip[1] != 0x0)'
I didn't see any SYN|ACKs go out, but netperf.org would have had to set
ECT for me to see a SYN|ACK going out. FWIW, this is on a 2.6.31-15
(Ubuntu) kernel with net.ipv4.tcp_ecn = 2 and I don't think the SYNs
themselves were negotiating ECN:
13:26:16.866007 IP (tos 0x3,CE, ttl 41, id 28850, offset 0, flags [DF],
proto TCP (6), length 64)
somesystemin.de.55363 > www.netperf.org.www: Flags [S], cksum
0x4cfc (correct), seq 304457158, win 65535, options [mss 1460,nop,wscale
rick
^ permalink raw reply
* Re: [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks
From: Kevin Hilman @ 2012-05-04 21:02 UTC (permalink / raw)
To: Mark A. Greer
Cc: Bedia, Vaibhav, nsekhar, Ben Hutchings, netdev@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20120504182938.GB28910@animalcreek.com>
"Mark A. Greer" <mgreer@animalcreek.com> writes:
> On Fri, May 04, 2012 at 07:31:30AM -0700, Kevin Hilman wrote:
[...]
>> Come to think of it, the right solution here is probably to use runtime
>> PM. We could then to add some custom hooks for davinci_emac in the
>> device code to use enable_hlt/disable_hlt based on activity.
>
> That was my first thought, actually, but that only works if its
> okay for the driver to call enable_hlt/disable_hlt directly (i.e.,
> have runtime_suspend() call enable_hlt() and runtime_resume() call
> disable_hlt()). However, I assumed it would _not_ be acceptable for
> the driver to issue those calls directly.
I agree.
> Its a platform-specific issue that we shouldn't be polluting the
> driver with and there are currently no drivers that call them under
> the drivers directory.
Using runtime PM we don't have to have any platform specific calls in
the driver. We handle it inside the platform-specific runtime PM
implementation.
IOW, we don't have to call enable_hlt/disable_hlt in the driver. It can
be completely transparent to the driver. We can call
enable_hlt/disable_hlt in device specific code. That way, davinci
platforms with this same IP won't use
To demonstrate, assume the davinci_emac is runtime PM converted and does
a pm_runtime_get_sync() instead of clk_enable().
For the first call to pm_runtime_get_sync() (when runtime PM count goes
from zero to 1), this will trigger the runtime PM core to runtime PM
enable the device. Using the driver model's 'PM domain' layer, we've
plugged in our omap_device layer, so the omap_device layer is called for
runtime PM transitions. (c.f. omap_device_pm_domain in plat-omap/omap_device.c)
Specifically, on a a runtime PM 'get', the PM domain's
->runtime_resume() callback is called. For an omap_device, that is
_od_runtime_resume(). After enabling the device using
omap_device_enable() the driver's ->runtime_resume callback is called.
So, to summarize, the (simplified) flow looks like this:
pm_runtime_get_sync()
<PM domain>->runtime_resume() /* _od_runtime_resume() */
omap_device_enable()
pm_generic_runtime_resume()
<driver>->runtime_resume()
However, you're still wondering where we would sneak in the call to
disable_hlt. Well, I'm glad you asked....
Looking closer at omap_device_enable(), you'll see that it calls
_omap_device_activate() which uses a function pointer in the
omap_device_pm_latency structure to actually enable the device.
By default, this function is omap_device_enable_hwmods() for all
omap_devices, which in turn uses the hwmod layer to enable the HW
(including clock enable, PM init, etc.)
Now, here's the magic....
On a per-device basis, that activate function can be customized. In the
custom function, you can add custom calls (e.g. disable_hlt) and then
call the normal omap_device_* functions to continue the default
behavior.
This is getting messy, so let me give a concrete example in the form of
a patch. Starting from the GPIO driver, which is already runtime PM
converted. If I wanted to add disable_hlt/enable_hlt whenver the device
is runtime PM enabled/disabled, it would be as simple as the patch below.
So in summary, whever pm_runtime_get_sync() is called (and the usecount
goes from zero to 1), the omap_device 'activate' function is called
(which can call disable_hlt()), and whenever pm_runtime_put() is called
(and the usecount reaches zero), the omap_device 'deactivate' function
is called, and enable_hlt() can be called.
The example I give below customizes the hooks for *all* SoCs, but in the
specific case we're trying to solve, we would only need to add custom
hooks for the devices without wakeups.
Note that all of this presumes that the driver is runtime PM converted
*and* the device itself is built using omap_device_build(). That means
that the device init code in am35xx_emac.c needs to be converted to use
omap_device_build instead of the normal platform_device_* calls. (note
though that omap_device_build() will also create/register the
platform_device.
Kevin
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index a80e093..3acd1eb 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -26,8 +26,30 @@
#include <plat/omap_device.h>
#include <plat/omap-pm.h>
+#include <asm/system.h>
+
#include "powerdomain.h"
+static int omap2_gpio_deactivate_func(struct omap_device *od)
+{
+ enable_hlt();
+ return omap_device_idle_hwmods(od);
+}
+
+static int omap2_gpio_activate_func(struct omap_device *od)
+{
+ disable_hlt();
+ return omap_device_enable_hwmods(od);
+}
+
+struct omap_device_pm_latency pm_lats[] __initdata = {
+ {
+ .activate_func = omap2_gpio_activate_func,
+ .deactivate_func = omap2_gpio_deactivate_func,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
static int __init omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
{
struct platform_device *pdev;
@@ -128,7 +150,8 @@ static int __init omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
pdata->loses_context = pwrdm_can_ever_lose_context(pwrdm);
pdev = omap_device_build(name, id - 1, oh, pdata,
- sizeof(*pdata), NULL, 0, false);
+ sizeof(*pdata), pm_lats,
+ ARRAY_SIZE(pm_lats), false);
kfree(pdata);
if (IS_ERR(pdev)) {
^ permalink raw reply related
* [RFC] MTU discovery not working over GRE
From: Stephen Hemminger @ 2012-05-04 21:04 UTC (permalink / raw)
To: Herbert Xu, David Miller; +Cc: netdev
When using gretap, I am seeing that Path MTU discovery is not
working for packets going out over the tunnel interface. What happens
is that the driver correctly identifies the DF bit, and see IPv4
but since skb_dst(skb) is NULL, the icmp_send() ends up doing nothing.
The following fixes the problem but does not seem like the correct general
solution. IPv6 almost certainly has the same problem.
Perhaps we should just set the skb_dst() earlier (before the
MTU checks).
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 1017460..da57bb0 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -838,8 +838,9 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
if ((old_iph->frag_off&htons(IP_DF)) &&
mtu < ntohs(old_iph->tot_len)) {
+ skb_dst_drop(skb);
+ skb_dst_set(skb, &rt->dst);
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu));
- ip_rt_put(rt);
goto tx_error;
}
}
^ permalink raw reply related
* Re: [PATCH net-next] tcp: be more strict before accepting ECN negociation
From: Eric Dumazet @ 2012-05-04 21:14 UTC (permalink / raw)
To: Rick Jones
Cc: David Miller, netdev, Perry Lorier, Matt Mathis, Yuchung Cheng,
Neal Cardwell, Tom Herbert, Wilmer van der Gaast, Dave Täht,
Ankur Jain
In-Reply-To: <4FA443B6.9010106@hp.com>
On Fri, 2012-05-04 at 14:01 -0700, Rick Jones wrote:
> >
> > Interesting indeed ;)
> >
> > Did you check if it was spoofed ?
> >
> > (did the 3WHS really completed)
>
>
> Well, the tcpdump command was still:
>
>
> tcpdump -i eth0 -vvv '(tcp[tcpflags]& tcp-syn != 0)&& (ip[1] != 0x0)'
>
> I didn't see any SYN|ACKs go out, but netperf.org would have had to set
> ECT for me to see a SYN|ACK going out. FWIW, this is on a 2.6.31-15
> (Ubuntu) kernel with net.ipv4.tcp_ecn = 2 and I don't think the SYNs
> themselves were negotiating ECN:
>
> 13:26:16.866007 IP (tos 0x3,CE, ttl 41, id 28850, offset 0, flags [DF],
> proto TCP (6), length 64)
> somesystemin.de.55363 > www.netperf.org.www: Flags [S], cksum
> 0x4cfc (correct), seq 304457158, win 65535, options [mss 1460,nop,wscale
Probably not, or else you would see :
13:26:16.866007 IP (tos 0x3,CE, ttl 41, id 28850, offset 0, flags
[DF],proto TCP (6), length 64)
somesystemin.de.55363 > www.netperf.org.www: Flags [SEW], cksum ...
^ permalink raw reply
* Re: [PATCH 04/15] drivers/net: Do not free an IRQ if its request failed
From: Lee Jones @ 2012-05-04 21:18 UTC (permalink / raw)
To: Linus Walleij
Cc: linux, linus.walleij, arnd, netdev, grant.likely, cjb,
linux-arm-kernel
In-Reply-To: <CACRpkdaB+mAmo50uSDvVcq=V9_BF01-zu2WHUU+cc2WPU1NEXA@mail.gmail.com>
On 04/05/12 19:22, Linus Walleij wrote:
> On Fri, May 4, 2012 at 4:10 PM, Lee Jones<lee.jones@linaro.org> wrote:
>> On 19/04/12 21:36, Lee Jones wrote:
>
>>> - goto out_free_irq;
>>> + goto out_disable_resources;
>>> }
>>>
>>> retval = register_netdev(dev);
>>
>>
>> Anything on this from the Net guys?
>
> This was merged for 3.4-rc5, check:
> https://lkml.org/lkml/2012/4/29/2
I actually found that out a few hours ago by accident.
Thanks for letting me know though.
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [patch 1/1] connector/userns: replace netlink uses of cap_raised() with capable()
From: akpm @ 2012-05-04 21:34 UTC (permalink / raw)
To: davem
Cc: netdev, akpm, ebiederm, dhowells, james.l.morris, kaber, morgan,
philipp.reisner, segoon, serge.hallyn
From: Eric W. Biederman <ebiederm@xmission.com>
Subject: connector/userns: replace netlink uses of cap_raised() with capable()
In 2009 Philip Reiser notied that a few users of netlink connector
interface needed a capability check and added the idiom
cap_raised(nsp->eff_cap, CAP_SYS_ADMIN) to a few of them, on the premise
that netlink was asynchronous.
In 2011 Patrick McHardy noticed we were being silly because netlink is
synchronous and removed eff_cap from the netlink_skb_params and changed
the idiom to cap_raised(current_cap(), CAP_SYS_ADMIN).
Looking at those spots with a fresh eye we should be calling
capable(CAP_SYS_ADMIN). The only reason I can see for not calling capable
is that it once appeared we were not in the same task as the caller which
would have made calling capable() impossible.
In the initial user_namespace the only difference between between
cap_raised(current_cap(), CAP_SYS_ADMIN) and capable(CAP_SYS_ADMIN) are a
few sanity checks and the fact that capable(CAP_SYS_ADMIN) sets
PF_SUPERPRIV if we use the capability.
Since we are going to be using root privilege setting PF_SUPERPRIV seems
the right thing to do.
The motivation for this that patch is that in a child user namespace
cap_raised(current_cap(),...) tests your capabilities with respect to that
child user namespace not capabilities in the initial user namespace and
thus will allow processes that should be unprivielged to use the kernel
services that are only protected with cap_raised(current_cap(),..).
To fix possible user_namespace issues and to just clean up the code
replace cap_raised(current_cap(), CAP_SYS_ADMIN) with
capable(CAP_SYS_ADMIN).
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Philipp Reisner <philipp.reisner@linbit.com>
Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Acked-by: Andrew G. Morgan <morgan@kernel.org>
Cc: Vasiliy Kulikov <segoon@openwall.com>
Cc: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/block/drbd/drbd_nl.c | 2 +-
drivers/md/dm-log-userspace-transfer.c | 2 +-
drivers/video/uvesafb.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff -puN drivers/block/drbd/drbd_nl.c~connector-userns-replace-netlink-uses-of-cap_raised-with-capable drivers/block/drbd/drbd_nl.c
--- a/drivers/block/drbd/drbd_nl.c~connector-userns-replace-netlink-uses-of-cap_raised-with-capable
+++ a/drivers/block/drbd/drbd_nl.c
@@ -2297,7 +2297,7 @@ static void drbd_connector_callback(stru
return;
}
- if (!cap_raised(current_cap(), CAP_SYS_ADMIN)) {
+ if (!capable(CAP_SYS_ADMIN)) {
retcode = ERR_PERM;
goto fail;
}
diff -puN drivers/md/dm-log-userspace-transfer.c~connector-userns-replace-netlink-uses-of-cap_raised-with-capable drivers/md/dm-log-userspace-transfer.c
--- a/drivers/md/dm-log-userspace-transfer.c~connector-userns-replace-netlink-uses-of-cap_raised-with-capable
+++ a/drivers/md/dm-log-userspace-transfer.c
@@ -134,7 +134,7 @@ static void cn_ulog_callback(struct cn_m
{
struct dm_ulog_request *tfr = (struct dm_ulog_request *)(msg + 1);
- if (!cap_raised(current_cap(), CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_ADMIN))
return;
spin_lock(&receiving_list_lock);
diff -puN drivers/video/uvesafb.c~connector-userns-replace-netlink-uses-of-cap_raised-with-capable drivers/video/uvesafb.c
--- a/drivers/video/uvesafb.c~connector-userns-replace-netlink-uses-of-cap_raised-with-capable
+++ a/drivers/video/uvesafb.c
@@ -73,7 +73,7 @@ static void uvesafb_cn_callback(struct c
struct uvesafb_task *utask;
struct uvesafb_ktask *task;
- if (!cap_raised(current_cap(), CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_ADMIN))
return;
if (msg->seq >= UVESAFB_TASKS_MAX)
_
^ permalink raw reply
* [PATCH] irda: irda-usb.c URL to sigmatel stir 4210/4220/4116 fw from archive.org
From: Xose Vazquez Perez @ 2012-05-04 21:37 UTC (permalink / raw)
To: xose.vazquez, samuel, netdev, linux-kernel
Sigmatel was bought by Freescale, the web is dead and the firmware was lost.
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
drivers/net/irda/irda-usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/irda/irda-usb.c b/drivers/net/irda/irda-usb.c
index 72f687b..0c929f2 100644
--- a/drivers/net/irda/irda-usb.c
+++ b/drivers/net/irda/irda-usb.c
@@ -1081,6 +1081,7 @@ static int stir421x_patch_device(struct irda_usb_cb *self)
/*
* Known firmware patch file names for STIR421x dongles
* are "42101001.sb" or "42101002.sb"
+ * http://web.archive.org/web/http://www.sigmatel.com/documents/stir4210_4220_4116_patch_files.tar.gz
*/
sprintf(stir421x_fw_name, "4210%4X.sb",
self->usbdev->descriptor.bcdDevice);
--
1.7.10.1
^ permalink raw reply related
* Re: [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks
From: Mark A. Greer @ 2012-05-04 21:47 UTC (permalink / raw)
To: Kevin Hilman
Cc: Bedia, Vaibhav, nsekhar, Ben Hutchings, netdev@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <87397faccs.fsf@ti.com>
On Fri, May 04, 2012 at 02:02:43PM -0700, Kevin Hilman wrote:
> "Mark A. Greer" <mgreer@animalcreek.com> writes:
>
> > On Fri, May 04, 2012 at 07:31:30AM -0700, Kevin Hilman wrote:
>
> [...]
>
> >> Come to think of it, the right solution here is probably to use runtime
> >> PM. We could then to add some custom hooks for davinci_emac in the
> >> device code to use enable_hlt/disable_hlt based on activity.
> >
> > That was my first thought, actually, but that only works if its
> > okay for the driver to call enable_hlt/disable_hlt directly (i.e.,
> > have runtime_suspend() call enable_hlt() and runtime_resume() call
> > disable_hlt()). However, I assumed it would _not_ be acceptable for
> > the driver to issue those calls directly.
>
> I agree.
>
> > Its a platform-specific issue that we shouldn't be polluting the
> > driver with and there are currently no drivers that call them under
> > the drivers directory.
>
> Using runtime PM we don't have to have any platform specific calls in
> the driver. We handle it inside the platform-specific runtime PM
> implementation.
FYI, with some further discussion via IRC, I'm going to implement what
Kevin has laid out here. There is a dependency on davinci adding support
too but I'll coordinate with the people/person doing that.
Please disregard this patch.
Thanks for the help everyone.
Mark
^ 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