* Re: [net-next PATCH v1 00/11] A flow API
From: John Fastabend @ 2015-01-05 5:17 UTC (permalink / raw)
To: Or Gerlitz
Cc: Thomas Graf, sfeldma, Jiří Pírko, Jamal Hadi Salim,
simon.horman, Linux Netdev List, David Miller, Andy Gospodarek
In-Reply-To: <CAJ3xEMikET4Yh88CYb1q5wsFQzakZsyqpPYxropQf2TwYdJg3w@mail.gmail.com>
On 01/04/2015 12:30 AM, Or Gerlitz wrote:
> On Wed, Dec 31, 2014 at 9:45 PM, John Fastabend
> <john.fastabend@gmail.com> wrote:
>> So... I could continue to mull over this and tweak bits and pieces
>> here and there but I decided its best to get a wider group of folks
>> looking at it and hopefulyl with any luck using it so here it is.
> [...]
>> I could use some help reviewing
> [...]
>
> Hi John,
>
> It would be very helpful to get access to the actual patches, I don't
> see them on the netdev patchwork queue, and assume
> it's b/c this is still in RFC stage. Cloning your github tree and
> looking there, I see some earlier/WIP versions of the code, but it's
> not
> the submitted patches.
>
The netdev mailed patches should be there (didn't check) I'm guessing
you just need to set the filters correctly. There is an "Action
Required" filter that you most likely need to remove I think it is on
by default. Seeing I already commented on the series indicating I would
need a v2 to address some fixes I'm guessing its already been cleared
from the queue.
> Or.
>
> [1] https://github.com/jrfastab/flow-net-next.git
>
That link is a bit out of date here I pushed the exact series I sent
to a git repo here,
https://github.com/jrfastab/rocker-net-next
All update it tomorrow with some feedback though.
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH] Fix an infinite retry-loop
From: David Miller @ 2015-01-05 4:48 UTC (permalink / raw)
To: me; +Cc: linux-kernel, jitendra.kalsaria, ron.mercer, linux-driver, netdev
In-Reply-To: <1420394696-20099-1-git-send-email-me@mortis.eu>
From: Giel van Schijndel <me@mortis.eu>
Date: Sun, 4 Jan 2015 19:04:55 +0100
> This was clearly intended as a retry-10-times loop, but due to the
> absence of code incrementing the loop-counter it was practically a
> retry-forever loop.
>
> Rewritten it as a for-loop as well to make the loop-counter increment
> (as well as its potential absence) easier to spot.
Besides missing the Signoff, you also did not write your
Subject line properly.
You should format it as:
Subject: [PATCH] ${SUBSYSTEM_PREFIX}: Description.
Where ${SUBSYSTEM_PREFIX} should be "qlogic: " in this
case.
Do not fix this by replying to this email, instead make a new
fresh patch posting to the lists.
This also applied to all of your other submissions, they all
need to be fixed up in this manner at the very least.
^ permalink raw reply
* Re: [PATCH net-next v3 1/4] net: bcmgenet: bcmgenet_init_tx_ring() cleanup
From: David Miller @ 2015-01-05 4:46 UTC (permalink / raw)
To: pgynther; +Cc: netdev, f.fainelli
In-Reply-To: <20150104074523.5CA9C22034C@puck.mtv.corp.google.com>
From: Petri Gynther <pgynther@google.com>
Date: Sat, 3 Jan 2015 23:45:23 -0800 (PST)
> Signed-off-by: Petri Gynther <pgynther@google.com>
I'm not applying patches like this with not even a minor
explanation of what kind of cleanups are happening.
> - /* Disable rate control for now */
> bcmgenet_tdma_ring_writel(priv, index, flow_period_val,
> TDMA_FLOW_PERIOD);
And I think this comment, and the others you are removing are
absolutely appropriate and should not be removed.
Also, what value is there in renaming the function argument
'write_ptr' to 'start_ptr'? I think both names are equally
clear.
You have to provide explanations and justifications in the commit log
message of your changes.
I'm not applying this series, sorry.
^ permalink raw reply
* Re: [PATCH net-next] tipc: convert tipc reference table to use generic rhashtable
From: David Miller @ 2015-01-05 4:43 UTC (permalink / raw)
To: tgraf
Cc: ying.xue, netdev, jon.maloy, Paul.Gortmaker, erik.hugne,
tipc-discussion
In-Reply-To: <20150104095320.GB15305@casper.infradead.org>
From: Thomas Graf <tgraf@suug.ch>
Date: Sun, 4 Jan 2015 09:53:20 +0000
> As a further optimization, you could add a new atomic function
> rhashtable_lookup_and_insert() which holds the per bucket lock during
> lookup and use that instead. This would allow you to get rid of the
> mutex alltogether.
This would definitely be a better implementation in my opinion.
^ permalink raw reply
* Re: [PATCH net-next] list_nulls: fix missing header
From: David Miller @ 2015-01-05 4:12 UTC (permalink / raw)
To: ying.xue; +Cc: netdev
In-Reply-To: <1420356275-7340-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Sun, 4 Jan 2015 15:24:35 +0800
> Fixup below build error:
>
> include/linux/list_nulls.h: In function ‘hlist_nulls_del’:
> include/linux/list_nulls.h:84:13: error: ‘LIST_POISON2’ undeclared (first use in this function)
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] rhashtable: fix missing header
From: David Miller @ 2015-01-05 4:12 UTC (permalink / raw)
To: tgraf; +Cc: ying.xue, netdev
In-Reply-To: <20150104091908.GA15305@casper.infradead.org>
From: Thomas Graf <tgraf@suug.ch>
Date: Sun, 4 Jan 2015 09:19:08 +0000
> On 01/04/15 at 03:25pm, Ying Xue wrote:
>> Fixup below build error:
>>
>> include/linux/rhashtable.h: At top level:
>> include/linux/rhashtable.h:118:34: error: field ???mutex??? has incomplete type
>
> Just wondering, is this your new code that didn't compile? The code
> compiled fine for me for the existing users.
>
>> Signed-off-by: Ying Xue <ying.xue@windriver.com>
>
> Fixes: 97defe1e ("rhashtable: Per bucket locks & deferred expansion/shrinking")
> Acked-by: Thomas Graf <tgraf@suug.ch>
I'm applying this now as rhashtable.h really needs to include mutex.h
as it does use it's interfaces, regardless of whether it does actually
introduce a build error currently or not.
^ permalink raw reply
* Re: [PATCH] net: wireless: rtlwifi: btcoexist: halbtc8821a2ant: Remove some unused functions
From: Julian Calaby @ 2015-01-05 4:05 UTC (permalink / raw)
To: Larry Finger
Cc: Rickard Strandqvist, Chaoming Li, Kalle Valo, Greg Kroah-Hartman,
Fengguang Wu,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development, Linux Kernel Mailing List
In-Reply-To: <54A9ECC7.6040900-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Hi Larry,
On Mon, Jan 5, 2015 at 12:45 PM, Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote:
> On 01/03/2015 06:03 AM, Rickard Strandqvist wrote:
>>
>> 2015-01-03 7:05 GMT+01:00 Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>:
>>
>>> On 01/02/2015 02:26 PM, Rickard Strandqvist wrote:
>>>
>>>> Removes some functions that are not used anywhere:
>>>> ex_halbtc8821a2ant_periodical() ex_halbtc8821a2ant_halt_notify()
>>>> ex_halbtc8821a2ant_bt_info_notify()
>>>> ex_halbtc8821a2ant_special_packet_notify()
>>>> ex_halbtc8821a2ant_connect_notify() ex_halbtc8821a2ant_scan_notify()
>>>> ex_halbtc8821a2ant_lps_notify() ex_halbtc8821a2ant_ips_notify()
>>>> ex_halbtc8821a2ant_display_coex_info() ex_halbtc8821a2ant_init_coex_dm()
>>>> ex_halbtc8821a2ant_init_hwconfig()
>>>>
>>>> This was partially found by using a static code analysis program called
>>>> cppcheck.
>>>>
>>>> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@
>>>> spectrumdigital.se>
>>>>
>>>
>>> I know that you have been told that including "net: wireless:" in the
>>> subject line is discouraged. Please do not do this again. The staging
>>> directory is different as GregKH uses "staging:" in the subject to route
>>> patches, but wireless does not.
>>>
>>> As to the patch, NACK for the simple reason that I am currently working
>>> on
>>> a number of changes to btcoexist. Some of these routines may end up being
>>> removed, but others will not. Having your patch remove them, and one of
>>> mine adding them back just constitutes a lot of churning of the source.
>>> In
>>> addition, it greatly increases the probability of the source trees
>>> becoming
>>> unsynchronized and getting merge conflicts.
>>>
>>> Larry
>>>
>>>
>>
>> Hi Larry
>>
>> I do not recognize that there has been no diskution on the subject of
>> "net:
>> wireless:"
>> I use some sed call for this, so it's easy to fix. You want the "net:
>> wireless:" part completely erased then?
>> I check in Documentation/ but find any clear info for this.
>>
>> Sorry for the patch, is there any way for me to see that this is something
>> that is being worked on?
>
>
> These patches are the result of private communications between the Realtek
> engineers and me. The only publication is in the "rock" branch of the git
> repo at http://github.com/lwfinger/rtlwifi_new.git.
>
> I do not understand the "use of some 'sed' call". If you edit the source and
> add it to the git repo with the add and commit operations, then format-patch
> gives you exactly what you need, and send-email does that operation.
I suspect he means how he makes the subject lines. I'm guessing something like:
echo $PATH | sed 's/^.*\/drivers\///;s/\//: /;s/\.c$/: Remove some
unused functions/;'
Thanks,
--
Julian Calaby
Email: julian.calaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2015-01-05 3:36 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-next, linux-kernel, richardcochran,
jeffrey.t.kirsher
In-Reply-To: <20150103.144530.1032237292364564169.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 792 bytes --]
Hi David,
On Sat, 03 Jan 2015 14:45:30 -0500 (EST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Sat, 3 Jan 2015 09:11:01 +1100
>
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/net/ethernet/mellanox/mlx4/en_clock.c: In function 'mlx4_en_init_timestamp':
> > drivers/net/ethernet/mellanox/mlx4/en_clock.c:249:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration]
> > mdev->cycles.mask = CLOCKSOURCE_MASK(48);
>
> Stephen please let me know if this failure is persisting.
All the ones I reported are fixed, thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] qlcnic: Fix dump_skb output
From: David Miller @ 2015-01-05 3:24 UTC (permalink / raw)
To: joe; +Cc: shahed.shaikh, netdev, linux-kernel
In-Reply-To: <1420336216.2619.9.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sat, 03 Jan 2015 17:50:16 -0800
> Use normal facilities to avoid printing each byte
> on a separate line.
>
> Now emits at KERN_DEBUG instead of KERN_INFO.
>
> Signed-off-by: Joe Perches <joe@perches.com>
This looks fine, applied, thanks Joe.
^ permalink raw reply
* Re: [PATCH net-next] enic: reconfigure resources for kdump crash kernel
From: David Miller @ 2015-01-05 3:24 UTC (permalink / raw)
To: _govind; +Cc: netdev, ssujith, benve
In-Reply-To: <1420293944-7614-1-git-send-email-_govind@gmx.com>
From: Govindarajulu Varadarajan <_govind@gmx.com>
Date: Sat, 3 Jan 2015 19:35:44 +0530
> When running in kdump kernel, reduce number of resources used by the driver.
> This will enable NIC to operate in low memory kdump kernel environment.
>
> Also change the driver version to .83
>
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/1 linux-next] hp100: simplify hp100_module_init
From: David Miller @ 2015-01-05 3:23 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, perex, netdev
In-Reply-To: <1420292656-14429-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Sat, 3 Jan 2015 14:44:16 +0100
> -Avoid double goto and directly return err where possible.
> -Remove unused labels which fixes:
>
> drivers/net/ethernet/hp/hp100.c:3047:2: warning: label
> 'out3' defined but not used [-Wunused-label]
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> This is untested.
Having a sole lone return statement that all flows of control
branch to makes the code easier to audit, than to have a huge
block where each return statement has to be audited independently
for potential cleanups.
Added to the fact that this patch is completely untested, I'm
not applying this, sorry.
^ permalink raw reply
* Re: [PATCH net-next 0/4] Geneve Cleanups
From: David Miller @ 2015-01-05 3:22 UTC (permalink / raw)
To: jesse; +Cc: netdev
In-Reply-To: <1420251965-44794-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Fri, 2 Jan 2015 18:26:01 -0800
> Much of the basis for the Geneve code comes from VXLAN. However,
> Geneve is quite a bit simpler than VXLAN and so this cleans up a
> lot of the infrastruction - particularly around locking - where the
> extra complexity is not necessary.
I like it, series applied, thanks Jesse.
^ permalink raw reply
* Re: [PATCH] GMAC: fix simple_return.cocci warnings
From: David Miller @ 2015-01-05 3:20 UTC (permalink / raw)
To: joe
Cc: fengguang.wu, roger.chen, kbuild-all, peppe.cavallaro, netdev,
linux-kernel
In-Reply-To: <1420246005.23591.7.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 02 Jan 2015 16:46:45 -0800
> On Sat, 2015-01-03 at 08:25 +0800, kbuild test robot wrote:
>> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c:425:1-4: WARNING: end returns can be simpified
>>
>> Simplify a trivial if-return sequence. Possibly combine with a
>> preceding function call.
>> Generated by: scripts/coccinelle/misc/simple_return.cocci
>>
>> CC: Roger Chen <roger.chen@rock-chips.com>
>> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
>> ---
>>
>> dwmac-rk.c | 6 +-----
>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> @@ -422,11 +422,7 @@ static int rk_gmac_init(struct platform_
>> if (ret)
>> return ret;
>>
>> - ret = gmac_clk_enable(bsp_priv, true);
>> - if (ret)
>> - return ret;
>> -
>> - return 0;
>> + return gmac_clk_enable(bsp_priv, true);
>
> I think this change is not particularly better.
>
> When the pattern is multiply repeated like:
...
> I think it's better to not change the last
> test in the sequence just to minimize overall
> line count.
I think it's a wash and that both ways are about the same to me.
I won't apply this, sorry.
^ permalink raw reply
* Re: [PATCH] net: ethernet: cpsw: fix hangs with interrupts
From: David Miller @ 2015-01-05 3:19 UTC (permalink / raw)
To: balbi; +Cc: mugunthanvnm, yegorslists, linux-omap, netdev, stable
In-Reply-To: <1420236959-32444-1-git-send-email-balbi@ti.com>
From: Felipe Balbi <balbi@ti.com>
Date: Fri, 2 Jan 2015 16:15:59 -0600
> The CPSW IP implements pulse-signaled interrupts. Due to
> that we must write a correct, pre-defined value to the
> CPDMA_MACEOIVECTOR register so the controller generates
> a pulse on the correct IRQ line to signal the End Of
> Interrupt.
>
> The way the driver is written today, all four IRQ lines
> are requested using the same IRQ handler and, because of
> that, we could fall into situations where a TX IRQ fires
> but we tell the controller that we ended an RX IRQ (or
> vice-versa). This situation triggers an IRQ storm on the
> reserved IRQ 127 of INTC which will in turn call ack_bad_irq()
> which will, then, print a ton of:
...
> Reported-by: Yegor Yefremov <yegorslists@googlemail.com>
> Fixes: 510a1e7 (drivers: net: davinci_cpdma: acknowledge interrupt properly)
> Cc: <stable@vger.kernel.org> # v3.9+
> Signed-off-by: Felipe Balbi <balbi@ti.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/3] swdev: add IPv4 routing offload
From: David Miller @ 2015-01-05 3:17 UTC (permalink / raw)
To: sfeldma; +Cc: netdev, jiri, john.fastabend, tgraf, jhs, andy, roopa
In-Reply-To: <1420169361-31767-1-git-send-email-sfeldma@gmail.com>
From: sfeldma@gmail.com
Date: Thu, 1 Jan 2015 19:29:18 -0800
> This patch set adds L3 routing offload support for IPv4 routes. The idea is to
> mirror routes installed in the kernel's FIB down to a hardware switch device to
> offload the data forwarding path for L3. Only the data forwarding path is
> intercepted. Control and management of the kernel's FIB remains with the
> kernel.
It looks like the design for this is still under discussion and that
new patches of whatever is decided upon will be forthcoming
eventually.
Can I ask you guys a huge favor? DO NOT quote the entire patch when
discussing these changes.
The thread for patch #1 was so time consuming to scan and read in
patchwork because you guys did this.
I know it takes a little bit more work to select and delete the patch
content in the quoted area, but you really have to do this because
otherwise it is a huge burden for reviewers trying to follow the
conversation.
Thanks.
^ permalink raw reply
* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Fu, Zhonghui @ 2015-01-05 2:37 UTC (permalink / raw)
To: Sergei Shtylyov, brudley, Arend van Spriel, Franky Lin, meuleman,
kvalo, linville, pieterpg, hdegoede, wens, linux-wireless,
brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <54A3DC80.1080505@cogentembedded.com>
Hi Sergei,
You are right, I will apply your advice in next version of this patch.
Thanks,
Zhonghui
On 2014/12/31 19:22, Sergei Shtylyov wrote:
> Hello.
>
> On 12/31/2014 11:20 AM, Fu, Zhonghui wrote:
>
>> From e34419970a07bfcd365f9c66bdfa552188a0cd26 Mon Sep 17 00:00:00 2001
>> From: Zhonghui Fu <zhonghui.fu@linux.intel.com>
>> Date: Mon, 29 Dec 2014 21:25:31 +0800
>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>
>> WiFi chip has 2 SDIO functions, and PM core will trigger
>> twice suspend/resume operations for one WiFi chip to do
>> the same things. This patch avoid this case.
>
>> Signed-off-by: Zhonghui Fu <zhonghui.fu@linux.intel.com>
>> ---
>> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 19 +++++++++++++++++--
>> 1 files changed, 17 insertions(+), 2 deletions(-)
>
>> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> index 3c06e93..eee7818 100644
>> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> @@ -1139,11 +1139,18 @@ void brcmf_sdio_wowl_config(struct device *dev, bool enabled)
>> static int brcmf_ops_sdio_suspend(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> mmc_pm_flag_t sdio_flags;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>>
>> + if (func->num == 2) {
>> + return 0;
>> + }
>
> {} not needed.
>
> [...]
>> @@ -1164,9 +1171,17 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
>> static int brcmf_ops_sdio_resume(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>> +
>> + if (func->num == 2) {
>> + return 0;
>> + }
>
> Same here.
>
> [...]
>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Fu, Zhonghui @ 2015-01-05 2:34 UTC (permalink / raw)
To: Arend van Spriel
Cc: brudley, Franky Lin, meuleman, kvalo, linville, pieterpg,
hdegoede, wens, linux-wireless, brcm80211-dev-list, netdev,
linux-kernel
In-Reply-To: <54A3C837.6040400@broadcom.com>
Hi Arend,
Where to find your patch for this?
Thanks,
Zhonghui
On 2014/12/31 17:56, Arend van Spriel wrote:
> On 12/31/14 09:20, Fu, Zhonghui wrote:
>> From e34419970a07bfcd365f9c66bdfa552188a0cd26 Mon Sep 17 00:00:00 2001
>> From: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>> Date: Mon, 29 Dec 2014 21:25:31 +0800
>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>>
>> WiFi chip has 2 SDIO functions, and PM core will trigger
>> twice suspend/resume operations for one WiFi chip to do
>> the same things. This patch avoid this case.
>
> We have a patch queued up for this as well, but this one looks good enough although I personally prefer container_of() instead of dev_to_sdio_func().
>
> Acked-by: Arend van Spriel <arend@broadcom.com>
>> Signed-off-by: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>> ---
>> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 19 +++++++++++++++++--
>> 1 files changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> index 3c06e93..eee7818 100644
>> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> @@ -1139,11 +1139,18 @@ void brcmf_sdio_wowl_config(struct device *dev, bool enabled)
>> static int brcmf_ops_sdio_suspend(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> mmc_pm_flag_t sdio_flags;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>>
>> + if (func->num == 2) {
>> + return 0;
>> + }
>> +
>> + sdiodev = bus_if->bus_priv.sdio;
>> +
>> atomic_set(&sdiodev->suspend, true);
>>
>> if (sdiodev->wowl_enabled) {
>> @@ -1164,9 +1171,17 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
>> static int brcmf_ops_sdio_resume(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>> +
>> + if (func->num == 2) {
>> + return 0;
>> + }
>> +
>> + sdiodev = bus_if->bus_priv.sdio;
>> +
>> if (sdiodev->pdata->oob_irq_supported)
>> disable_irq_wake(sdiodev->pdata->oob_irq_nr);
>> brcmf_sdio_wd_timer(sdiodev->bus, BRCMF_WD_POLL_MS);
>> -- 1.7.1
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v1 0/7] net: extend ethtool link mode bitmaps to 48 bits
From: Ben Hutchings @ 2015-01-05 2:30 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: David Decotigny, Amir Vadai, Florian Fainelli, Linux NetDev,
Linux Kernel Mailing List, linux-api, David Decotigny,
David S. Miller, Jason Wang, Michael S. Tsirkin, Herbert Xu,
Al Viro, Masatake YAMATO, Xi Wang, Neil Horman, WANG Cong,
Flavio Leitner, Tom Gundersen, Jiri Pirko, Vlad Yasevich,
Eric W. Biederman, Saeed Mahameed, Venkata Duvvuru, Govindaraj
In-Reply-To: <CAHo-Ooxi8V_58b456vePY9_7ChuBe0jxEVHvGkGvRBpAR744yA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]
On Mon, 2015-01-05 at 01:34 +0100, Maciej Żenczykowski wrote:
> >> I can send updates to other drivers, even though it's rather pointless
> >> to update 1G drivers at this point for example. Please let me know,
> >> but I'd prefer to do this in follow-up patches outside this first
> >> patch series.
> > [...]
> >
> > They should be changed to ensure they reject setting any of the high
> > advertising flags, but it's not urgent.
>
> if old drivers advertised a get/set_bits function while new drivers
> advertised a get/set_new_bits function,
> you could not updated any old drivers, and simply take care of
> rejecting invalid bits in core, by calling set_new_bits if provided,
> if not, rejecting bad bits and calling set_bits if no bad bits were
> set.
We've never checked that the reserved fields are zero before, and I
think there are still drivers that don't fully validate the existing 32
bits. So while I think drivers should fully validate the advertising
flags, userland generally can't assume they do. And therefore I don't
think it's worth adding complexity to the ethtool core that only partly
fixes this.
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC flow-net-next 02/10] net: flow: Add features to tables
From: Simon Horman @ 2015-01-05 2:18 UTC (permalink / raw)
To: Cong Wang; +Cc: John Fastabend, netdev
In-Reply-To: <CAHA+R7NmfUpYcKfW_Gck2HaANH3OQk-9BAYZCXnBtGO1eV13xg@mail.gmail.com>
On Mon, Dec 29, 2014 at 03:03:39PM -0800, Cong Wang wrote:
> On Sun, Dec 28, 2014 at 6:15 PM, Simon Horman
> <simon.horman@netronome.com> wrote:
> > +static struct net_flow_table *net_flow_table_get_table(struct net_device *dev,
> > + int table_uid)
> > +{
> > + struct net_flow_table **tables;
> > + int i;
> > +
> > + tables = net_flow_get_tables(dev);
> > + if (IS_ERR(tables))
> > + return ERR_PTR(PTR_ERR(tables));
>
> Seriously? :)
I was looking for a way to handle the type of tables being different
to the return type of net_flow_table_get_table().
Would you recommend a cast?
return (struct net_flow_table *)tables;
^ permalink raw reply
* Re: [PATCH/RFC flow-net-next 04/10] net: flow: Add counters to flows
From: Simon Horman @ 2015-01-05 2:10 UTC (permalink / raw)
To: Arad, Ronen; +Cc: Fastabend, John R, netdev@vger.kernel.org
In-Reply-To: <E4CD12F19ABA0C4D8729E087A761DC3505DD0E24@ORSMSX101.amr.corp.intel.com>
On Mon, Dec 29, 2014 at 07:31:41AM +0000, Arad, Ronen wrote:
>
>
> >-----Original Message-----
> >From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> >Behalf Of Simon Horman
> >Sent: Monday, December 29, 2014 4:16 AM
> >To: Fastabend, John R; netdev@vger.kernel.org
> >Cc: Simon Horman
> >Subject: [PATCH/RFC flow-net-next 04/10] net: flow: Add counters to flows
> >
> >It may be useful for hardware flow table support for counters to be exposed
> >via the flow API. One possible use case of this is for Open vSwitch to use
> >the flow API in conjunction with its existing datapath flow management
> >scheme which in a nutshell treats the datapath as a cache that times out
> >idle entries.
> >
> >This patch exposes optionally exposes three counters:
> >- Number of packets that have matched a flow
> >- Number of bytes of packets that have matched a flow
> >- The time in ms when the flow was last hit
> >
> >Inspired by the flow counters present in Open Flow.
> >
> >Signed-off-by: Simon Horman <simon.horman@netronome.com>
> >
> >---
> >
> >Compile tested only
> >---
> > include/uapi/linux/if_flow.h | 24 ++++++++++++++++++++++++
> > net/core/flow_table.c | 27 +++++++++++++++++++++++++++
> > 2 files changed, 51 insertions(+)
> >
> >diff --git a/include/uapi/linux/if_flow.h b/include/uapi/linux/if_flow.h
> >index 28da45b..18214ea 100644
> >--- a/include/uapi/linux/if_flow.h
> >+++ b/include/uapi/linux/if_flow.h
> >@@ -127,6 +127,9 @@
> > * [NET_FLOW_ATTR_PRIORITY]
> > * [NET_FLOW_ATTR_IDLE_TIMEOUT]
> > * [NET_FLOW_ATTR_HARD_TIMEOUT]
> >+ * [NET_FLOW_ATTR_BYTE_COUNT]
> >+ * [NET_FLOW_ATTR_PACKET_COUNT]
> >+ * [NET_FLOW_ATTR_LAST_USED]
> > * [NET_FLOW_ATTR_MATCHES]
> > * [NET_FLOW_FIELD_REF]
> > * [NET_FLOW_FIELD_REF]
> >@@ -153,6 +156,9 @@
> > * [NET_FLOW_ATTR_PRIORITY]
> > * [NET_FLOW_ATTR_IDLE_TIMEOUT]
> > * [NET_FLOW_ATTR_HARD_TIMEOUT]
> >+ * [NET_FLOW_ATTR_BYTE_COUNT]
> >+ * [NET_FLOW_ATTR_PACKET_COUNT]
> >+ * [NET_FLOW_ATTR_LAST_USED]
> > * [NET_FLOW_MATCHES]
> > * [NET_FLOW_FIELD_REF]
> > * [NET_FLOW_FIELD_REF]
> >@@ -365,6 +371,9 @@ enum {
> > * @idle_timeout idle timeout of flow in seconds. Zero for no timeout.
> > * @hard_timeout timeout of flow regardless of use in seconds.
> > * Zero for no timeout.
> >+ * @byte_count bytes recieved
> >+ * @byte_count packets recieved
> >+ * @last_used time of most recent use (msec since system initialisation)
> > *
> > * Flows must match all entries in match set.
> > */
> >@@ -374,6 +383,9 @@ struct net_flow_flow {
> > int priority;
> > __u32 idle_timeout;
> > __u32 hard_timeout;
> >+ __u64 byte_count;
> >+ __u64 packet_count;
> >+ __u64 last_used;
> > struct net_flow_field_ref *matches;
> > struct net_flow_action *actions;
> > };
> >@@ -414,6 +426,9 @@ enum {
> > NET_FLOW_ATTR_ACTIONS,
> > NET_FLOW_ATTR_IDLE_TIMEOUT,
> > NET_FLOW_ATTR_HARD_TIMEOUT,
> >+ NET_FLOW_ATTR_BYTE_COUNT,
> >+ NET_FLOW_ATTR_PACKET_COUNT,
> >+ NET_FLOW_ATTR_LAST_USED,
> > __NET_FLOW_ATTR_MAX,
> > };
> > #define NET_FLOW_ATTR_MAX (__NET_FLOW_ATTR_MAX - 1)
> >@@ -465,6 +480,15 @@ enum {
> >
> > /* Table supports idle timeout of flows */
> > NET_FLOW_TABLE_F_HARD_TIMEOUT = (1 << 1),
> >+
> >+ /* Table supports byte counter for flows */
> >+ NET_FLOW_TABLE_F_BYTE_COUNT = (1 << 2),
> >+
> >+ /* Table supports packet counter for flows */
> >+ NET_FLOW_TABLE_F_PACKET_COUNT = (1 << 3),
> >+
> >+ /* Table supports last used counter for flows */
> >+ NET_FLOW_TABLE_F_PACKET_LAST_USED = (1 << 4),
> > };
> >
> > #if 0
> >diff --git a/net/core/flow_table.c b/net/core/flow_table.c
> >index 89ba9bc..070e646 100644
> >--- a/net/core/flow_table.c
> >+++ b/net/core/flow_table.c
> >@@ -54,6 +54,9 @@ struct nla_policy net_flow_flow_policy[NET_FLOW_ATTR_MAX +
> >1] = {
> > [NET_FLOW_ATTR_PRIORITY] = { .type = NLA_U32 },
> > [NET_FLOW_ATTR_IDLE_TIMEOUT] = { .type = NLA_U32 },
> > [NET_FLOW_ATTR_HARD_TIMEOUT] = { .type = NLA_U32 },
> >+ [NET_FLOW_ATTR_BYTE_COUNT] = { .type = NLA_U64 },
> >+ [NET_FLOW_ATTR_PACKET_COUNT] = { .type = NLA_U64 },
> >+ [NET_FLOW_ATTR_LAST_USED] = { .type = NLA_U64 },
> > [NET_FLOW_ATTR_MATCHES] = { .type = NLA_NESTED },
> > [NET_FLOW_ATTR_ACTIONS] = { .type = NLA_NESTED },
> > };
> >@@ -206,6 +209,16 @@ int net_flow_put_flow(struct sk_buff *skb, struct
> >net_flow_flow *flow)
> > nla_put_u32(skb, NET_FLOW_ATTR_HARD_TIMEOUT, flow->hard_timeout))
> > goto flows_put_failure;
> >
> >+ if (flow->byte_count &&
> >+ nla_put_u32(skb, NET_FLOW_ATTR_BYTE_COUNT, flow->byte_count))
> >+ goto flows_put_failure;
> >+ if (flow->packet_count &&
> >+ nla_put_u32(skb, NET_FLOW_ATTR_PACKET_COUNT, flow->packet_count))
> >+ goto flows_put_failure;
> >+ if (flow->last_used &&
> >+ nla_put_u32(skb, NET_FLOW_ATTR_LAST_USED, flow->last_used))
> >+ goto flows_put_failure;
> >+
> The flow byte_count, packet_count, and last_used fields are defined as __u64 and related netlink attributes are of type NLA_U64 but nla_put_u32() is used to add them to the netlink msg.
Thanks, I will fix that up by using nla_put_u64().
> > matches = nla_nest_start(skb, NET_FLOW_ATTR_MATCHES);
> > if (!matches)
> > goto flows_put_failure;
> >@@ -536,6 +549,13 @@ static int net_flow_get_flow(struct net_flow_flow *flow,
> >struct nlattr *attr)
> > if (f[NET_FLOW_ATTR_HARD_TIMEOUT])
> > flow->hard_timeout = nla_get_u32(f[NET_FLOW_ATTR_HARD_TIMEOUT]);
> >
> >+ if (f[NET_FLOW_ATTR_BYTE_COUNT])
> >+ flow->byte_count = nla_get_u64(f[NET_FLOW_ATTR_BYTE_COUNT]);
> >+ if (f[NET_FLOW_ATTR_PACKET_COUNT])
> >+ flow->packet_count = nla_get_u64(f[NET_FLOW_ATTR_PACKET_COUNT]);
> >+ if (f[NET_FLOW_ATTR_LAST_USED])
> >+ flow->last_used = nla_get_u64(f[NET_FLOW_ATTR_LAST_USED]);
> >+
> > flow->matches = NULL;
> > flow->actions = NULL;
> >
> >@@ -1386,6 +1406,13 @@ static int net_flow_table_cmd_flows(struct sk_buff
> >*recv_skb,
> > if (this.hard_timeout)
> > used_features |= NET_FLOW_TABLE_F_HARD_TIMEOUT;
> >
> >+ if (this.byte_count)
> >+ used_features |= NET_FLOW_TABLE_F_BYTE_COUNT;
> >+ if (this.packet_count)
> >+ used_features |= NET_FLOW_TABLE_F_PACKET_COUNT;
> >+ if (this.last_used)
> >+ used_features |= NET_FLOW_TABLE_F_PACKET_LAST_USED;
> >+
> > err = net_flow_table_check_features(dev, this.table_id,
> > used_features);
> > if (err)
> >--
> >2.1.3
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: flow: Allow actions and matches to be NULL in net_flow_put_flow()
From: Simon Horman @ 2015-01-05 2:06 UTC (permalink / raw)
To: John Fastabend; +Cc: John Fastabend, netdev
In-Reply-To: <54A195C7.3010009@gmail.com>
On Mon, Dec 29, 2014 at 09:56:23AM -0800, John Fastabend wrote:
> On 12/28/2014 06:20 PM, Simon Horman wrote:
> >This makes the handing of the absence of actions or matches
> >symmetric with net_flow_get_flow().
> >
> >Signed-off-by: Simon Horman <simon.horman@netronome.com>
> >---
>
> Again thanks I actually just hit this with my rocker implementation
> so very timely fix. Same story here I'll roll it into the patch and
> submit it later today.
Thanks. I have hit a few more minor problems which I have fixes for.
What is the best way to handle them? Rebase them on v1 of your patchset
and post them for review if they are still relevant?
^ permalink raw reply
* Re: [PATCH] net: flow: Guard against accessing non-existent attributes
From: Simon Horman @ 2015-01-05 2:04 UTC (permalink / raw)
To: John Fastabend; +Cc: John Fastabend, netdev
In-Reply-To: <54A1951A.2070209@gmail.com>
On Mon, Dec 29, 2014 at 09:53:30AM -0800, John Fastabend wrote:
> On 12/28/2014 06:17 PM, Simon Horman wrote:
> >Signed-off-by: Simon Horman <simon.horman@netronome.com>
> >---
> > net/core/flow_table.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
>
> Great thanks. I rolled it into the patches I should hopefully have
> ready to submit later today.
>
> By the way I got this working on rocker now so we can test it easier,
> I'll post the driver updates as well.
Great, excellent news.
^ permalink raw reply
* Re: [PATCH] net: wireless: rtlwifi: btcoexist: halbtc8821a2ant: Remove some unused functions
From: Larry Finger @ 2015-01-05 1:45 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Chaoming Li, Kalle Valo, Greg Kroah-Hartman, Fengguang Wu,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List
In-Reply-To: <CAKXHbyOYO29uKA127qyYrCfpgQ2zoqBS9rAJME513oZ8JVdOug@mail.gmail.com>
On 01/03/2015 06:03 AM, Rickard Strandqvist wrote:
> 2015-01-03 7:05 GMT+01:00 Larry Finger <Larry.Finger@lwfinger.net>:
>
>> On 01/02/2015 02:26 PM, Rickard Strandqvist wrote:
>>
>>> Removes some functions that are not used anywhere:
>>> ex_halbtc8821a2ant_periodical() ex_halbtc8821a2ant_halt_notify()
>>> ex_halbtc8821a2ant_bt_info_notify()
>>> ex_halbtc8821a2ant_special_packet_notify()
>>> ex_halbtc8821a2ant_connect_notify() ex_halbtc8821a2ant_scan_notify()
>>> ex_halbtc8821a2ant_lps_notify() ex_halbtc8821a2ant_ips_notify()
>>> ex_halbtc8821a2ant_display_coex_info() ex_halbtc8821a2ant_init_coex_dm()
>>> ex_halbtc8821a2ant_init_hwconfig()
>>>
>>> This was partially found by using a static code analysis program called
>>> cppcheck.
>>>
>>> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@
>>> spectrumdigital.se>
>>>
>>
>> I know that you have been told that including "net: wireless:" in the
>> subject line is discouraged. Please do not do this again. The staging
>> directory is different as GregKH uses "staging:" in the subject to route
>> patches, but wireless does not.
>>
>> As to the patch, NACK for the simple reason that I am currently working on
>> a number of changes to btcoexist. Some of these routines may end up being
>> removed, but others will not. Having your patch remove them, and one of
>> mine adding them back just constitutes a lot of churning of the source. In
>> addition, it greatly increases the probability of the source trees becoming
>> unsynchronized and getting merge conflicts.
>>
>> Larry
>>
>>
>
> Hi Larry
>
> I do not recognize that there has been no diskution on the subject of "net:
> wireless:"
> I use some sed call for this, so it's easy to fix. You want the "net:
> wireless:" part completely erased then?
> I check in Documentation/ but find any clear info for this.
>
> Sorry for the patch, is there any way for me to see that this is something
> that is being worked on?
These patches are the result of private communications between the Realtek
engineers and me. The only publication is in the "rock" branch of the git repo
at http://github.com/lwfinger/rtlwifi_new.git.
I do not understand the "use of some 'sed' call". If you edit the source and add
it to the git repo with the add and commit operations, then format-patch gives
you exactly what you need, and send-email does that operation.
Larry
^ permalink raw reply
* Re: [PATCH net-next v1 0/7] net: extend ethtool link mode bitmaps to 48 bits
From: Maciej Żenczykowski @ 2015-01-05 0:34 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Decotigny, Amir Vadai, Florian Fainelli, Linux NetDev,
Linux Kernel Mailing List, linux-api-u79uwXL29TY76Z2rM5mHXA,
David Decotigny, David S. Miller, Jason Wang, Michael S. Tsirkin,
Herbert Xu, Al Viro, Masatake YAMATO, Xi Wang, Neil Horman,
WANG Cong, Flavio Leitner, Tom Gundersen, Jiri Pirko,
Vlad Yasevich, Eric W. Biederman, Saeed Mahameed, Venkata Duvvuru,
Govindaraj
In-Reply-To: <1420408540.5686.140.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
>> I can send updates to other drivers, even though it's rather pointless
>> to update 1G drivers at this point for example. Please let me know,
>> but I'd prefer to do this in follow-up patches outside this first
>> patch series.
> [...]
>
> They should be changed to ensure they reject setting any of the high
> advertising flags, but it's not urgent.
if old drivers advertised a get/set_bits function while new drivers
advertised a get/set_new_bits function,
you could not updated any old drivers, and simply take care of
rejecting invalid bits in core, by calling set_new_bits if provided,
if not, rejecting bad bits and calling set_bits if no bad bits were
set.
^ permalink raw reply
* Re: [PATCH 2/2] Fix copy-paste bug: assign from src struct not dest
From: Giel van Schijndel @ 2015-01-04 23:02 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1420394427-19509-2-git-send-email-me@mortis.eu>
[-- Attachment #1: Type: text/plain, Size: 210 bytes --]
On Sun, Jan 04, 2015 at 19:00:23 +0100, Giel van Schijndel wrote:
> ---
Forgot to:
Signed-off-by: Giel van Schijndel <me@mortis.eu>
--
Met vriendelijke groet,
With kind regards,
Giel van Schijndel
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ 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