* Re: [PATCH 2/2] Fix copy-paste bug: assign from src struct not dest
From: Giel van Schijndel @ 2015-01-07 19:18 UTC (permalink / raw)
To: Johannes Berg, Andy Shevchenko
Cc: linux-kernel, Kalle Valo, Eliad Peller, John W. Linville,
Arik Nemtsov, open list:TI WILINK WIRELES...,
open list:NETWORKING DRIVERS
In-Reply-To: <1420451671.9459.1.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]
On Mon, Jan 05, 2015 at 10:54:31 +0100, Johannes Berg wrote:
> On Sun, 2015-01-04 at 19:00 +0100, Giel van Schijndel wrote:
>> ---
>> drivers/net/wireless/ti/wlcore/acx.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ti/wlcore/acx.c b/drivers/net/wireless/ti/wlcore/acx.c
>> index beb354c..93a2fa8 100644
>> --- a/drivers/net/wireless/ti/wlcore/acx.c
>> +++ b/drivers/net/wireless/ti/wlcore/acx.c
>> @@ -1725,7 +1725,7 @@ int wl12xx_acx_config_hangover(struct wl1271 *wl)
>> acx->decrease_delta = conf->decrease_delta;
>> acx->quiet_time = conf->quiet_time;
>> acx->increase_time = conf->increase_time;
>> - acx->window_size = acx->window_size;
>> + acx->window_size = conf->window_size;
>
> It would be far better to fix the bug *first*, that way the bugfix can
> be cherry-picked/applied to trees that don't have the alignment.
I agree on the ordering.
As for:
> (And anyway I question the value of the alignment - if you really want
> to make this bug disappear you could perhaps use a macro)
And:
On Wed, Jan 07, 2015 at 20:40:57 +0200, Andy Shevchenko wrote:
> On Sun, Jan 4, 2015 at 8:00 PM, Giel van Schijndel <me@mortis.eu> wrote:
> > This highlights the differences (errors).
>
> Seems like patch for the patch. Just fix an error like it's done here:
> http://www.spinics.net/lists/linux-wireless/msg131667.html
IMO the aligned block of code has the significant advantage of taking
advantage of humans' ability to spot things that break a pattern. Which
in this case becomes *very* visible when properly aligned, because
without the alignment there is no (visual) pattern (or at least not one
very suitable for my "visual processing system", I know the same applies
to at least some others).
--
Met vriendelijke groet,
With kind regards,
Giel van Schijndel
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Greetings From China
From: Mr. Chiang @ 2015-01-07 18:47 UTC (permalink / raw)
To: Recipients
Good day and how do you do? I'm Mr.Chiang, and I work with Bank of China. I need your assistance in moving a sum of $28 Million USDollars. Kindly get back if interested.
^ permalink raw reply
* [PATCH RESEND] isdn: fix NUL (\0 or \x00) specification in string
From: Giel van Schijndel @ 2015-01-07 19:10 UTC (permalink / raw)
To: linux-kernel
Cc: David Sterba, Giel van Schijndel, Armin Schindler, Karsten Keil,
open list:ISDN SUBSYSTEM
In-Reply-To: <1420394722-20197-1-git-send-email-me@mortis.eu>
In C one can either use '\0' or '\x00' (or '\000') to add a NUL byte to
a string. '\0x00' isn't part of these and will in fact result in a
single NUL followed by "x00". This fixes that.
Signed-off-by: Giel van Schijndel <me@mortis.eu>
Reported-at: http://www.viva64.com/en/b/0299/
---
drivers/isdn/hardware/eicon/message.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/eicon/message.c b/drivers/isdn/hardware/eicon/message.c
index a82e542..0b38060 100644
--- a/drivers/isdn/hardware/eicon/message.c
+++ b/drivers/isdn/hardware/eicon/message.c
@@ -4880,7 +4880,7 @@ static void sig_ind(PLCI *plci)
byte SS_Ind[] = "\x05\x02\x00\x02\x00\x00"; /* Hold_Ind struct*/
byte CF_Ind[] = "\x09\x02\x00\x06\x00\x00\x00\x00\x00\x00";
byte Interr_Err_Ind[] = "\x0a\x02\x00\x07\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
- byte CONF_Ind[] = "\x09\x16\x00\x06\x00\x00\0x00\0x00\0x00\0x00";
+ byte CONF_Ind[] = "\x09\x16\x00\x06\x00\x00\x00\x00\x00\x00";
byte force_mt_info = false;
byte dir;
dword d;
--
2.1.4
^ permalink raw reply related
* [bisected] no traffic on ssl vpn with 3.19rc1 - 3.19rc3
From: Billy Shuman @ 2015-01-07 19:10 UTC (permalink / raw)
To: netdev
Hi,
Since 3.19rc1 I get 100% packet loss through SSL vpn. I bisected with
the following result:
0b46d0ee9c240c7430a47e9b0365674d4a04522 is the first bad commit
commit e0b46d0ee9c240c7430a47e9b0365674d4a04522
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri Nov 7 21:22:23 2014 +0800
tun: Use iovec iterators
This patch removes the use of skb_copy_datagram_const_iovec in
favour of the iovec iterator-based skb_copy_datagram_iter.
https://bugzilla.kernel.org/show_bug.cgi?id=90901
Thanks,
Billy Shuman
^ permalink raw reply
* FROM GRACE MANDA
From: FROM MRS GRACE MANDA @ 2015-01-07 18:45 UTC (permalink / raw)
In-Reply-To: <325415706.2959930.1420502856940.JavaMail.yahoo@jws10090.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 27 bytes --]
PLEASE VIEW THE ATTACHMENT.
[-- Attachment #2: From Mrs Grace manda.rtf --]
[-- Type: application/msword, Size: 9207 bytes --]
^ permalink raw reply
* Re: [patch iproute2 2/2] tc: add support for BPF based actions
From: Cong Wang @ 2015-01-07 18:50 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, David Miller, Jamal Hadi Salim, Stephen Hemminger
In-Reply-To: <1420649244-9574-2-git-send-email-jiri@resnulli.us>
On Wed, Jan 7, 2015 at 8:47 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> + fprintf(stderr, "Usage: ... bpf ...\n");
> + fprintf(stderr, "\n");
> + fprintf(stderr, " [inline]: run bytecode BPF_BYTECODE\n");
> + fprintf(stderr, " [from file]: run bytecode-file FILE\n");
> + fprintf(stderr, "\n");
> + fprintf(stderr, "Where BPF_BYTECODE := \'s,c t f k,c t f k,c t f k,...\'\n");
> + fprintf(stderr, " c,t,f,k and s are decimals; s denotes number of 4-tuples\n");
> + fprintf(stderr, "Where FILE points to a file containing the BPF_BYTECODE string\n");
> + fprintf(stderr, "\nACTION_SPEC := ... look at individual actions\n");
> + fprintf(stderr, "NOTE: CLASSID is parsed as hexadecimal input.\n");
Can we just use BPF transparently for gact? It is never user-friendly to
use this kind of bytecode even though I know there is a tool to "compile"
BPF.
^ permalink raw reply
* Re: [patch net-next] tc: add BPF based action
From: Cong Wang @ 2015-01-07 18:46 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jiri Pirko, netdev, David Miller, Jamal Hadi Salim,
Stephen Hemminger, Alexei Starovoitov
In-Reply-To: <54AD7C03.3010904@redhat.com>
On Wed, Jan 7, 2015 at 10:33 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> On 01/07/2015 05:43 PM, Jiri Pirko wrote:
>>
>> This action provides a possibility to exec custom BPF code.
>
>
> Can you elaborate a bit more on the particular use-case, and
> what scenarios are unsolveable with the BPF filter we already
> have in tc? Just wondering, since you're using BPF for the
> purpose of classifying (but just from the context of actions)
> what about a possibility of a generic container for reusing
> (any) classifier from the framework, so we would not need to
> duplicate code?
>
+1
Also as its name tells, BPF is a filter, why it could be used
as an action here? (I don't follow eBPF though.)
^ permalink raw reply
* Re: [PATCH] Fix NUL (\0 or \x00) specification in string
From: Andy Shevchenko @ 2015-01-07 18:45 UTC (permalink / raw)
To: dsterba, Giel van Schijndel, linux-kernel@vger.kernel.org,
Armin Schindler, Karsten Keil, open list:ISDN SUBSYSTEM
In-Reply-To: <20150107122258.GG24104@suse.cz>
On Wed, Jan 7, 2015 at 2:22 PM, David Sterba <dsterba@suse.cz> wrote:
> On Tue, Jan 06, 2015 at 08:28:04PM +0100, Giel van Schijndel wrote:
>> On Mon, Jan 05, 2015 at 16:00:26 +0100, David Sterba wrote:
>> > I'm replying to all your recent patches here as they are fixing things
>> > reported in http://www.viva64.com/en/b/0299/ . I'ts a good practice to
>> > give the credit the reporter.
>> >
>> > The blogpost also contains analyses of the issues so it could help
>> > reviewing the patches.
>>
>> I guess you suggest I use a 'Reported-(at|by)' line?
>
> A link in the changelog would be enough IMHO.
>
>> Would something like the below suffice? I found similar log entries in the
>> commit log, e.g. bf3204cb, except that those add an e-mail address for
>> the reporters, which I don't think is necessary in this case.
>
> If you don't have the emails, then rather do not use reported-by.
Andrey Karpov <karpov@viva64.com>
But it requires an additional effort to get it.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] Align member-assigns in a structure-copy block
From: Andy Shevchenko @ 2015-01-07 18:40 UTC (permalink / raw)
To: Giel van Schijndel
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kalle Valo,
Eliad Peller, John W. Linville, Arik Nemtsov,
open list:TI WILINK WIRELES..., open list:NETWORKING DRIVERS
In-Reply-To: <1420394427-19509-1-git-send-email-me-sZ9Uef1cvPWHXe+LvDLADg@public.gmane.org>
On Sun, Jan 4, 2015 at 8:00 PM, Giel van Schijndel <me-sZ9Uef1cvPWHXe+LvDLADg@public.gmane.org> wrote:
> This highlights the differences (errors).
Seems like patch for the patch. Just fix an error like it's done here:
http://www.spinics.net/lists/linux-wireless/msg131667.html
> ---
> drivers/net/wireless/ti/wlcore/acx.c | 22 +++++++++++-----------
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/acx.c b/drivers/net/wireless/ti/wlcore/acx.c
> index b924cea..beb354c 100644
> --- a/drivers/net/wireless/ti/wlcore/acx.c
> +++ b/drivers/net/wireless/ti/wlcore/acx.c
> @@ -1715,17 +1715,17 @@ int wl12xx_acx_config_hangover(struct wl1271 *wl)
> goto out;
> }
>
> - acx->recover_time = cpu_to_le32(conf->recover_time);
> - acx->hangover_period = conf->hangover_period;
> - acx->dynamic_mode = conf->dynamic_mode;
> - acx->early_termination_mode = conf->early_termination_mode;
> - acx->max_period = conf->max_period;
> - acx->min_period = conf->min_period;
> - acx->increase_delta = conf->increase_delta;
> - acx->decrease_delta = conf->decrease_delta;
> - acx->quiet_time = conf->quiet_time;
> - acx->increase_time = conf->increase_time;
> - acx->window_size = acx->window_size;
> + acx->recover_time = cpu_to_le32(conf->recover_time);
> + acx->hangover_period = conf->hangover_period;
> + acx->dynamic_mode = conf->dynamic_mode;
> + acx->early_termination_mode = conf->early_termination_mode;
> + acx->max_period = conf->max_period;
> + acx->min_period = conf->min_period;
> + acx->increase_delta = conf->increase_delta;
> + acx->decrease_delta = conf->decrease_delta;
> + acx->quiet_time = conf->quiet_time;
> + acx->increase_time = conf->increase_time;
> + acx->window_size = acx->window_size;
>
> ret = wl1271_cmd_configure(wl, ACX_CONFIG_HANGOVER, acx,
> sizeof(*acx));
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
With Best Regards,
Andy Shevchenko
--
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: [PATCH] Fix an infinite retry-loop
From: Andy Shevchenko @ 2015-01-07 18:39 UTC (permalink / raw)
To: Giel van Schijndel
Cc: linux-kernel@vger.kernel.org, Jitendra Kalsaria, Ron Mercer,
supporter:QLOGIC QLA3XXX NE..., open list:QLOGIC QLA3XXX NE...
In-Reply-To: <1420394696-20099-1-git-send-email-me@mortis.eu>
On Sun, Jan 4, 2015 at 8:04 PM, Giel van Schijndel <me@mortis.eu> wrote:
> 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.
It's already in upstream in better form.
> ---
> drivers/net/ethernet/qlogic/qla3xxx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/net/ethernet/qlogic/qla3xxx.c
> index c2f09af..35a26c9 100644
> --- a/drivers/net/ethernet/qlogic/qla3xxx.c
> +++ b/drivers/net/ethernet/qlogic/qla3xxx.c
> @@ -144,9 +144,9 @@ static int ql_sem_lock(struct ql3_adapter *qdev, u32 sem_mask, u32 sem_bits)
> */
> static int ql_wait_for_drvr_lock(struct ql3_adapter *qdev)
> {
> - int i = 0;
> + int i;
>
> - while (i < 10) {
> + for (i = 0; i < 10; ++i) {
> if (i)
> ssleep(1);
>
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [patch net-next] tc: add BPF based action
From: Daniel Borkmann @ 2015-01-07 18:33 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, jhs, stephen, ast
In-Reply-To: <1420649035-9522-1-git-send-email-jiri@resnulli.us>
On 01/07/2015 05:43 PM, Jiri Pirko wrote:
> This action provides a possibility to exec custom BPF code.
Can you elaborate a bit more on the particular use-case, and
what scenarios are unsolveable with the BPF filter we already
have in tc? Just wondering, since you're using BPF for the
purpose of classifying (but just from the context of actions)
what about a possibility of a generic container for reusing
(any) classifier from the framework, so we would not need to
duplicate code?
On the other hand, I would understand if it's at some point in
time eBPF which would f.e. mangle the packet, but the API you
propose is clearly classic BPF. ;)
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH iproute2 3/3] ip netns: Delete all netns
From: Vadim Kochan @ 2015-01-07 18:11 UTC (permalink / raw)
To: Brian Haley; +Cc: Vadim Kochan, netdev
In-Reply-To: <20150107173640.GA19586@angus-think.lan>
On Wed, Jan 07, 2015 at 07:36:40PM +0200, Vadim Kochan wrote:
> On Wed, Jan 07, 2015 at 10:44:24AM -0500, Brian Haley wrote:
> > On 01/07/2015 06:04 AM, Vadim Kochan wrote:
> > > From: Vadim Kochan <vadim4j@gmail.com>
> > >
> > > Allow delete all namespace names by:
> > >
> > > $ ip netns del all
> >
> > So I can still create a namespace called 'all', but can't exec in it or delete
> > it independently with this change. Perhaps you need to block that as well?
> > Unless there's some other patch I'm missing?
> >
> > -Brian
> Hm, I did not take it into account ...
> I will look if I can find another way ...
>
> Thanks,
what about this ?
$ ip netns exec / ip link
$ ip netns del /
so it make a sense to be as root directory of bound ns names in /var/run/netns/ ?
what do you think ?
Regards,
^ permalink raw reply
* NetDev 0.1 Deadline Extension(Jan 24) and Talk Summary
From: Richard Guy Briggs @ 2015-01-07 18:03 UTC (permalink / raw)
To: netdev, linux-wireless, lwn, netdev01, lartc, netfilter,
netfilter-devel
Fellow netheads:
Due to several submitter requests we would like to accomodate, we have extended
the proposal submission deadline to Jan 24. https://netdev01.org/cfp
A reminder that the Westin Hotel is holding a block of rooms for Netdev01 at a
guaranteed rate of $159.00 or $179.00 (depending on the type of room required)
and the rooms are going fast due to Winterlude bookings. That guarantee
expires on January 23, so book now to avoid disappointment and get the low
rate. The rooms are going faster than we expected!
Reservations: https://www.starwoodmeeting.com/StarGroupsWeb/res?id=1412035802&key=1AC9C1F8
Here is a post-holiday update of the activity so far in NetDev 0.1 you may have
missed if you aren't following the RSS feed or twitter:
Confirmed keynote speaker:
==========================
David S. Miller - The Current State of Linux kernel Networking.
Accepted talks: (All listed: https://www.netdev01.org/sessions )
===============
Rocker: switchdev prototyping vehicle
Scott Feldman
https://www.netdev01.org/sessions/2
How to not just do a demo with DPDK or Lessons learned making a software dataplane
Stephen Hemminger
https://www.netdev01.org/sessions/3
Picking low hanging fruit from the FIB tree
Alexander Duyck
https://www.netdev01.org/sessions/4
Rtnetlink dump filtering in the kernel
Roopa Prabhu
https://www.netdev01.org/sessions/5
Hardware Switches - The Opensource Approach
Jiri Pirko
https://www.netdev01.org/sessions/6
hello UML, meet LibOS and friends - h/w independent unadulterated reuse of Linux kernel networking code in userspace
Hajime Tazaki
https://www.netdev01.org/sessions/7
Distributing Linux tc filter-action packet processing across disparate nodes
Jamal Hadi Salim and Damascene M. Joachimpillai
https://www.netdev01.org/sessions/9
All About UDP Encapsulation
Tom Herbert
https://www.netdev01.org/sessions/11
Accepted workshops:
===================
Wireless Workshop
https://www.netdev01.org/sessions/1
Hardware Offloading BoF
https://www.netdev01.org/sessions/10
All of the accepted proposals are new work. A couple of proposals have been
returned for rework prior to acceptance. There are many more excellent
proposals currently making their way through the technical committee vetting
process. The committee has so far been very impressed with the quality of
proposals submitted.
Registration https://onlineregistrations.ca/netdev01/
$100/day, or $350 for 4 days (Cdn dollars). (online reg closes Feb 12th)
Registering helps us plan properly for numbers of attendees,
ensuring venue sizes and supplies are appropriate without
wasting resources.
Travel advice: https://netdev01.org/travel
Sponsors: https://netdev01.org/sponsors
Verizon http://www.verizon.com/
Cumulus Networks http://cumulusnetworks.com/
Mojatatu Networks http://mojatatu.com/
THE Technical Conference on Linux Networking, February 14-17, 2015, Ottawa, Canada
https://netdev01.org/
RSS feed: https://netdev01.org/atom
Follow us on Twitter: @netdev01 https://twitter.com/netdev01
^ permalink raw reply
* RE: [PATCH net-next 1/3] net: add IPv4 routing FIB support for swdev
From: Shrijeet Mukherjee @ 2015-01-07 17:54 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Scott Feldman, Netdev, Jiří Pírko, john fastabend,
Thomas Graf, Jamal Hadi Salim, Andy Gospodarek, Roopa Prabhu
In-Reply-To: <1420629792.26870.59.camel@stressinduktion.org>
>
>I could come up with several ways how to model hardware. Depending on that
>the integration with rules is easy or nearly impossible:
>
>1) it simply cannot deal with ip rules, so there is no way an ACL can
>influence the
>outcome of a routing table lookup - if the feature should be used, it has
>to use
>the slow-path in the kernel.
As Scott was saying, most hardware has table id's and the ability to
identify and prioritize that way.
>
>2) ACLs can influence which routing table will get queried - this sounds
>very much
>like the ip rule model and it seems not too hard to model that.
This clearly can be made to work .. the problem is really the space of
policy routing (i.e jump across VRF's incase of a lookup failure) when
combined with the space of ip rule flexibility.
>
>3) Routing implementations in the hardware have a single routing table and
>the
>leafs carry different actions with priorities: making this kind of model
>working
>with the ip rule concept will become very difficult and it might require
>lots of
>algorithmic code by every driver to adapt to a single API provided by
>Linux. It
>might be possible, if the hardware provides actions like backtrack and
>retrack and
>can keep state of priorities during walking the tree, I really doubt that.
In the short term .. this maybe a good way to go but with a simplication.
Some tables are offloaded and the rest at the full table level is in
software. Finally then you can put a "default route" in the hardware table
to punt to cpu and then keep the software model clever and the hardware
model fast ?
>
>Implementations of type 3) would look naturally to do in hardware (see
>different
>Cisco policy routing configurations or ipv6 subtree feature), so it seems
>it won't
>be possible to find a simple way to fuse rules and offloading in case of
>point 3).
>
>Rocker sounds a lot like model 2) and this seems possible and should be a
>matter
>of API design. It should merely be a matter of nicely model the data
>structures. ;)
>
>Also, @Scott: if you build drivers with l3 offloading as modules, don't you
>need to
>push the full routing tables to the hw once? Maybe we should think about
>the
>drivers pulling routing information from the kernel, the kernel only
>notifying
>something changed?
>
>Bye,
>Hannes
>
^ permalink raw reply
* Re: [PATCH 00/11 V2] rtlwifi: A set of patches that simplify the drivers
From: Kalle Valo @ 2015-01-07 17:57 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1420559892-12384-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> writes:
> Happy New Year.
>
> This set of patches, which are intended for the 3.20 stream, are intended to
> simplify the drivers. In particular, each of them has a separate routine that
> initilizes the dynamic power manipulation variables. Ten of these patches convert
> the drivers to use a common copy of this code. The other patch updates the
> parameter descriptions of rtl8723be to clarify usage.
>
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
>
> V2 - only patch 02/11 is changed to fix the problem noted by Sergei Shylyov
> <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> concerning a line that was dropped.
>
> Larry Finger (11):
> rtlwifi: Unify variable naming for all drivers
> rtlwifi: rtl8723be: Improve modinfo output
> rtlwifi: Create new routine to initialize the DM tables
> rtlwifi: rtl8188ee: Convert driver to use the common DM table init
> routine
> rtlwifi: rtl8192c-common: Convert driver to use common DM table
> initialization
> rtlwifi: rtl8192de: Convert driver to use common DM table
> initialization
> rtlwifi: rtl8192ee: Convert driver to use common DM table
> initialization
> rtlwifi: rtl8723ae: Convert driver to use common DM table
> initialization
> rtlwifi: rtl8723be: Convert driver to use common DM table
> initialization
> rtlwifi: rtl8821ae: Convert driver to use common DM table
> initialization
> rtlwifi: Move macro definitions to core
Thanks, all 11 applied to wireless-drivers-next.git.
--
Kalle Valo
--
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
* [PATCH net-next] Driver: Vmxnet3: Reinitialize vmxnet3 backend on wakeup from hibernate
From: Shrikrishna Khare @ 2015-01-07 17:56 UTC (permalink / raw)
To: sbhatewara, pv-drivers, netdev, linux-kernel
Cc: Shrikrishna Khare, Srividya Murali
Failing to reinitialize on wakeup results in loss of network connectivity for
vmxnet3 interface.
Signed-off-by: Srividya Murali <smurali@vmware.com>
Signed-off-by: Shrikrishna Khare <skhare@vmware.com>
Reviewed-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 50 +++++++++++++++++++++---------------
drivers/net/vmxnet3/vmxnet3_int.h | 4 +-
2 files changed, 31 insertions(+), 23 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 7af1f5c..124cb9f 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -3290,51 +3290,59 @@ skip_arp:
static int
vmxnet3_resume(struct device *device)
{
- int err, i = 0;
+ int err;
unsigned long flags;
struct pci_dev *pdev = to_pci_dev(device);
struct net_device *netdev = pci_get_drvdata(pdev);
struct vmxnet3_adapter *adapter = netdev_priv(netdev);
- struct Vmxnet3_PMConf *pmConf;
if (!netif_running(netdev))
return 0;
- /* Destroy wake-up filters. */
- pmConf = adapter->pm_conf;
- memset(pmConf, 0, sizeof(*pmConf));
-
- adapter->shared->devRead.pmConfDesc.confVer = cpu_to_le32(1);
- adapter->shared->devRead.pmConfDesc.confLen = cpu_to_le32(sizeof(
- *pmConf));
- adapter->shared->devRead.pmConfDesc.confPA =
- cpu_to_le64(adapter->pm_conf_pa);
-
- netif_device_attach(netdev);
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
err = pci_enable_device_mem(pdev);
if (err != 0)
- return err;
+ goto err;
pci_enable_wake(pdev, PCI_D0, 0);
+ vmxnet3_alloc_intr_resources(adapter);
+
+ /* During hibernate and suspend, device has to be reinitialized as the
+ * device state need not be preserved.
+ */
+
+ /* Need not check adapter state as other reset tasks cannot run during
+ * device resume.
+ */
spin_lock_irqsave(&adapter->cmd_lock, flags);
VMXNET3_WRITE_BAR1_REG(adapter, VMXNET3_REG_CMD,
- VMXNET3_CMD_UPDATE_PMCFG);
+ VMXNET3_CMD_QUIESCE_DEV);
spin_unlock_irqrestore(&adapter->cmd_lock, flags);
- vmxnet3_alloc_intr_resources(adapter);
- vmxnet3_request_irqs(adapter);
- for (i = 0; i < adapter->num_rx_queues; i++)
- napi_enable(&adapter->rx_queue[i].napi);
- vmxnet3_enable_all_intrs(adapter);
+ vmxnet3_tq_cleanup_all(adapter);
+ vmxnet3_rq_cleanup_all(adapter);
- return 0;
+ vmxnet3_reset_dev(adapter);
+ err = vmxnet3_activate_dev(adapter);
+ if (err) {
+ netdev_err(adapter->netdev,
+ "%s: failed to re-activate on resume, error: %d",
+ netdev->name, err);
+ vmxnet3_force_close(adapter);
+ goto err;
+ }
+ netif_device_attach(netdev);
+
+err:
+ return err;
}
static const struct dev_pm_ops vmxnet3_pm_ops = {
.suspend = vmxnet3_suspend,
.resume = vmxnet3_resume,
+ .freeze = vmxnet3_suspend,
+ .restore = vmxnet3_resume,
};
#endif
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 048f020..6297d9f 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.3.1.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.3.2.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01030100
+#define VMXNET3_DRIVER_VERSION_NUM 0x01030200
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 8/27] wireless: cw1200: Use setup_timer
From: Kalle Valo @ 2015-01-07 17:53 UTC (permalink / raw)
To: Julia Lawall
Cc: Solomon Peachy, kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1419604558-29743-7-git-send-email-Julia.Lawall-L2FTfq7BK8M@public.gmane.org>
Julia Lawall <Julia.Lawall-L2FTfq7BK8M@public.gmane.org> writes:
> Convert a call to init_timer and accompanying intializations of
> the timer's data and function fields to a call to setup_timer.
>
> A simplified version of the semantic match that fixes this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression t,f,d;
> @@
>
> -init_timer(&t);
> +setup_timer(&t,f,d);
> -t.data = d;
> -t.function = f;
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall-L2FTfq7BK8M@public.gmane.org>
Thanks, I applied the wireless-drivers patches below to
wireless-drivers-next.git.
e4a1c3f88e65 mwifiex: 11n_rxreorder: Use setup_timer
c6c33e772407 mwifiex: main: Use setup_timer
99a1b74395a5 orinoco_usb: Use setup_timer
1a94ace406ad iwl3945: Use setup_timer
af68b87f7211 iwl4965: Use setup_timer
0be01bf29721 cw1200: queue: Use setup_timer
dabefea6937d cw1200: main: Use setup_timer
983988ec0a24 wireless: cw1200: Use setup_timer
--
Kalle Valo
--
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: [PATCH] net: wireless: rt2x00: use helper to check capability/requirement
From: Kalle Valo @ 2015-01-07 17:52 UTC (permalink / raw)
To: Fred Chou
Cc: sgruszka, helmut.schaa, linux-wireless, users, netdev,
linux-kernel
In-Reply-To: <1419581958-5927-1-git-send-email-fred.chou.nd@gmail.com>
Fred Chou <fred.chou.nd@gmail.com> writes:
> From: Fred Chou <fred.chou.nd@gmail.com>
>
> Use rt2x00_has_cap_flag macro to check rt2x00dev->cap_flags.
>
> Signed-off-by: Fred Chou <fred.chou.nd@gmail.com>
Thanks, applied to wireless-drivers-next.git. But I simplified the
title:
b9d305cc4740 rt2x00: use helper to check capability/requirement
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH next v2] drivers/net/wireless/ath/wil6210/debugfs.c: Use 'uint64_t' instead of 'cycles_t' to avoid warnings
From: Kalle Valo @ 2015-01-07 17:51 UTC (permalink / raw)
To: Chen Gang; +Cc: qca_vkondrat, linux-wireless, wil6210, netdev, linux-next
In-Reply-To: <549AD6FC.8060706@gmail.com>
Chen Gang <gang.chen.5i5j@gmail.com> writes:
> do_div() checks the type strictly. 'cycles_t' may be 32-bit under quite
> a few architectures (parisc, arm, avr32 ...). So use 'uint64_t' instead
> of, the related warning (with allmodconfig under parisc):
>
> CC [M] drivers/net/wireless/ath/wil6210/debugfs.o
> In file included from arch/parisc/include/generated/asm/div64.h:1:0,
> from include/linux/kernel.h:124,
> from include/linux/list.h:8,
> from include/linux/module.h:9,
> from drivers/net/wireless/ath/wil6210/debugfs.c:17:
> drivers/net/wireless/ath/wil6210/debugfs.c: In function ‘wil_vring_debugfs_show’:
> include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast
> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> ^
> drivers/net/wireless/ath/wil6210/debugfs.c:107:4: note: in expansion of macro ‘do_div’
> do_div(idle, total);
> ^
> In file included from include/uapi/linux/stddef.h:1:0,
> from include/linux/stddef.h:4,
> from ./include/uapi/linux/posix_types.h:4,
> from include/uapi/linux/types.h:13,
> from include/linux/types.h:5,
> from include/linux/list.h:4,
> from include/linux/module.h:9,
> from drivers/net/wireless/ath/wil6210/debugfs.c:17:
> include/asm-generic/div64.h:44:18: warning: right shift count >= width of type [-Wshift-count-overflow]
> if (likely(((n) >> 32) == 0)) { \
> ^
> include/linux/compiler.h:159:40: note: in definition of macro ‘likely’
> # define likely(x) __builtin_expect(!!(x), 1)
> ^
> drivers/net/wireless/ath/wil6210/debugfs.c:107:4: note: in expansion of macro ‘do_div’
> do_div(idle, total);
> ^
> In file included from arch/parisc/include/generated/asm/div64.h:1:0,
> from include/linux/kernel.h:124,
> from include/linux/list.h:8,
> from include/linux/module.h:9,
> from drivers/net/wireless/ath/wil6210/debugfs.c:17:
> include/asm-generic/div64.h:48:22: warning: passing argument 1 of ‘__div64_32’ from incompatible pointer type [-Wincompatible-pointer-types]
> __rem = __div64_32(&(n), __base); \
> ^
> drivers/net/wireless/ath/wil6210/debugfs.c:107:4: note: in expansion of macro ‘do_div’
> do_div(idle, total);
> ^
> include/asm-generic/div64.h:35:17: note: expected ‘uint64_t * {aka long long unsigned int *}’ but argument is of type ‘cycles_t * {aka long unsigned int *}’
> extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
> ^
>
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Thanks, applied to wireless-drivers-next.git. But I simplified the
title:
c20e7789be9f wil6210: use 'uint64_t' instead of 'cycles_t' to avoid warnings
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH iproute2 3/3] ip netns: Delete all netns
From: Vadim Kochan @ 2015-01-07 17:36 UTC (permalink / raw)
To: Brian Haley; +Cc: Vadim Kochan, netdev
In-Reply-To: <54AD5458.6000400@hp.com>
On Wed, Jan 07, 2015 at 10:44:24AM -0500, Brian Haley wrote:
> On 01/07/2015 06:04 AM, Vadim Kochan wrote:
> > From: Vadim Kochan <vadim4j@gmail.com>
> >
> > Allow delete all namespace names by:
> >
> > $ ip netns del all
>
> So I can still create a namespace called 'all', but can't exec in it or delete
> it independently with this change. Perhaps you need to block that as well?
> Unless there's some other patch I'm missing?
>
> -Brian
Hm, I did not take it into account ...
I will look if I can find another way ...
Thanks,
^ permalink raw reply
* Re: [PATCH 2/6] vxlan: Group Policy extension
From: Alexei Starovoitov @ 2015-01-07 17:32 UTC (permalink / raw)
To: Thomas Graf
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Stephen Hemminger,
David S. Miller
On Wed, Jan 7, 2015 at 3:10 AM, Thomas Graf <tgraf@suug.ch> wrote:
> On 01/06/15 at 07:37pm, Alexei Starovoitov wrote:
>> Even it works ok, I think this struct layout is ugly.
>> imo would be much easier to read if you replace
>> the whole vxlanhdr with vxlanhdr_gbp
>> or split vxlanhdr into two 32-bit structs.
>> then __packed hacks won't be needed.
>
> The main reason why I merged it into vxlanhdr is for documentation
> purposes and to avoid duplicating the generic VXLAN header for every
> extension. The RCO and GPE extensions would need to duplicate this
> over and over. It gets messy in particular when multiple extensions
> can be used in combination (such as GBP and RCO) which then each
> have their own conflicting header definitions. This way, it is clear
> which extensions are compatible by just looking at the definition
> of the structure.
I'm afraid 'union' style with first u8 flags working as selector
won't work for the case you're describing, but since
md.gbp = ntohs(vxh->gbp.policy_id);
2652: 41 0f b7 55 0a movzwl 0xa(%r13),%edx
then at least from performance side it's ok at least on x86.
So this _packed stuff is fine, though not pretty.
It's internal header, so we can improve it later.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Kernel Panic ip6_xmit (screenshot)
From: Jérôme Poulin @ 2015-01-07 17:31 UTC (permalink / raw)
To: netdev
I'm submitting this screenshot in case it would affect something
important. I have no more details, I was using my desktop computer and
suddenly a kernel panic occured.
Here is the screenshot: http://postimg.org/image/9jhzcfqfd/
^ permalink raw reply
* Re: [PATCH 2/6] vxlan: Group Policy extension
From: Thomas Graf @ 2015-01-07 17:21 UTC (permalink / raw)
To: Tom Herbert
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Linux Netdev List,
Stephen Hemminger, David Miller
In-Reply-To: <CA+mtBx_A_M3+irq7w4nNCyPZBgM7ja+wfJT4w4Q0Yo6GMGYVgA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/07/15 at 08:56am, Tom Herbert wrote:
> On Wed, Jan 7, 2015 at 8:21 AM, Thomas Graf <tgraf@suug.ch> wrote:
> > If the VNI is not already used for another purpose, yes. The solution
> > as proposed can be integrated into existing VXLAN overlays separated by
> > VNI. It is also compatible with hardware VXLAN VTEPs which ignore the
> > reserved bits while continueing to maintain VNI separation.
>
> It seems like it should be relatively easy to group VNIs together to
> have the same mark with the current use of VNI. The works up to the
> point that all packets corresponding to a single VNI get the same
> mark.
This really depends on the network architecture and assumes that you
can remap the VNIs in the entire network. You might want to run L3
with group definitions across multiple L2 VNI segments. A second issue
is that many hardware VXLAN VTEPs do VNI based learning and will run
into capacity limits.
I'm not saying it's impossible but it's very tricky to intergrate if
you can't start from scratch. The whole point of this is to come up
with something that is painfully easy to use and integrate without
requiring to change much.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH v2] ath10k: fixup wait_for_completion_timeout return handling
From: Kalle Valo @ 2015-01-07 17:04 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: Chun-Yeow Yeoh, Sergei Shtylyov, netdev, linux-wireless,
linux-kernel, ath10k, Michal Kazior, Ben Greear, Yanbo Li
In-Reply-To: <1419968660-17404-1-git-send-email-der.herr@hofr.at>
Nicholas Mc Guire <der.herr@hofr.at> writes:
> wait_for_completion_timeout does not return negative values so the tests
> for <= 0 are not needed and the case differentiation in the error handling
> path unnecessary.
>
> v2: all wait_for_completion_timeout changes in a single patch
>
> patch was only compile tested x86_64_defconfig + CONFIG_ATH_CARDS=m
> CONFIG_ATH10K=m
>
> patch is against linux-next 3.19.0-rc1 -next-20141226
>
> None of the proposed cleanups are critical.
> All changes should only be removing unreachable cases.
>
> Signed-off-by: Nicholas Mc Guire <der.herr@hofr.at>
> ---
All the comments after "v2:" should be here, under the "---" line so
that git-am can automatically discard them.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] vxlan: Group Policy extension
From: Tom Herbert @ 2015-01-07 16:56 UTC (permalink / raw)
To: Thomas Graf
Cc: David Miller, Jesse Gross, Stephen Hemminger, Pravin B Shelar,
Linux Netdev List, dev@openvswitch.org
In-Reply-To: <20150107162129.GQ21820@casper.infradead.org>
On Wed, Jan 7, 2015 at 8:21 AM, Thomas Graf <tgraf@suug.ch> wrote:
> On 01/07/15 at 08:05am, Tom Herbert wrote:
>> Associating a sixteen bit field with security is worrisome, especially
>> considering that VXLAN provides no verification for any header fields
>> and doesn't even advocate use of outer UDP checksum so the field is
>> susceptible to an undetected single bit flip. The concept of a
>> "trusted underlay" is weak justification and hardly universal, so the
>> only way to actually secure this is through IPsec (this is mentioned
>> in the VXLAN-GPB draft).
>
> As you state correctly, this work requires a trusted underlay which can
> be achieved with IPsec, OpenVPN, SSH, ...
>
This can't be enforced. There's already a lot of deployment of VXLAN
in non-trusted networks, and there's nothing to prevent someone from
using this feature in those environments. Maybe there's an argument
that VXLAN already fundamentally lacks security and verification, so
adding this field might not make things worse :-/.
>> But if we have the security state of IPsec then why would we need
>> this field anyway?
>
> It's a separation of concern: the security label mechanism of the
> overlay should not depend on an eventual encryption layer in the
> underlay as not all of them provide a mechanism to label packets.
>
>> Could this same functionality be achieved if we just match the VNI to
>> a mark in IP tables?
>
> If the VNI is not already used for another purpose, yes. The solution
> as proposed can be integrated into existing VXLAN overlays separated by
> VNI. It is also compatible with hardware VXLAN VTEPs which ignore the
> reserved bits while continueing to maintain VNI separation.
It seems like it should be relatively easy to group VNIs together to
have the same mark with the current use of VNI. The works up to the
point that all packets corresponding to a single VNI get the same
mark.
Tom
^ 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