On Fri, 2014-06-13 at 06:48 +, Linus Torvalds wrote:
> On Thu, Jun 12, 2014 at 12:14 PM, David Miller wrote:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
>
> Hmm. I get *lots* of the appended messages from iwlwifi now. Things
> still seem to work, but ...
On Thu, 2014-06-12 at 10:57 +0200, Thomas Gleixner wrote:
> > > Right, but isn't that odd? Suddenly your delay measurement here might be
> > > minutes, hours, or years if you settimeofday() between timestamping and
> > > calculating the delta. That seems very strange to me, why would that be
> > >
On Thu, 2014-06-12 at 10:35 +0200, Johannes Berg wrote:
> +netdev, Stephen
Well, stupid me. Fixing that netdev address.
> On Thu, 2014-06-12 at 10:19 +0200, Thomas Gleixner wrote:
> > On Thu, 12 Jun 2014, Johannes Berg wrote:
> >
> > > On Wed, 2014-06-11 at 23:59 +
On Thu, 2014-06-12 at 10:31 +0200, Thomas Gleixner wrote:
> + u32 queue_delay = ktime_to_ms(net_timedelta(skb->tstamp));
FWIW, I think the same as patch 12 applies here. net_timedelta() doesn't
really seem to be a good way to calculate time deltas.
And yes - I've seen situations where this m
+netdev, Stephen
On Thu, 2014-06-12 at 10:19 +0200, Thomas Gleixner wrote:
> On Thu, 12 Jun 2014, Johannes Berg wrote:
>
> > On Wed, 2014-06-11 at 23:59 +, Thomas Gleixner wrote:
> >
> > > + msrmnt = ktime_to_ms(net_timedelta(skb_arv));
> >
> > Th
On Wed, 2014-06-11 at 23:59 +, Thomas Gleixner wrote:
> do_posix_clock_monotonic_gettime() is a leftover from the initial
> posix timer implementation which maps to ktime_get_ts().
I didn't even know we *had* such code, heh.
I've applied it to my tree - note that some code moved into sta_inf
On Wed, 2014-06-11 at 23:59 +, Thomas Gleixner wrote:
> + msrmnt = ktime_to_ms(net_timedelta(skb_arv));
This is probably more of a question about net_timedelta(), but is
ktime_get_real() really appropriate for duration measurements? Isn't
that non-monotonic?
johannes
--
To unsubscribe f
On Mon, 2014-06-09 at 16:09 +0200, Rostislav Lisovy wrote:
> On Tue, 2014-06-03 at 22:15 +0200, Johannes Berg wrote:
> > it's unclear to me how the bitrate is
> > selected, are there even different bitrates?
>
> My understanding is that since we are using OFDM we have
On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote:
> This patchset presents work in progress. Patches adding *_leave_ocb()
> functions and modifying RX/TX path in mac80211 to work with OCB
> mode will come in near future.
Oh, sorry - I commented on that but failed to read the cover letter
On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote:
> + static u8 bssid_wildcard[ETH_ALEN] = { 0xff, 0xff, 0xff,
> +0xff, 0xff, 0xff };
const
that doesn't actually exist anywhere already? Maybe not I guess.
> +int ieee80211_start_ocb(struct
On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote:
> Add new OCB mode (outside the context of the BSS) interface
> type as well as functions necessary to configure the interface
> when 'joining' such network.
I think you also want some API to leave (stop operating in) the network
again, an
On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote:
> IEEE 802.11p operates in its own 5.9GHz band. When there will
> be a record for the 5.9GHz band in the regulatory daemon,
> it must be limited to the OCB mode only -- using the newly
> added flags.
Is this really a *regulatory* limitatio
On Tue, 2014-05-27 at 08:54 +0200, Fabian Frederick wrote:
> 'texts' is only used as source in strcpy
Looks fine to me, but you should probably send it to the alsa list and
the audio maintainer, not lkml and Andrew.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
On Mon, 2014-05-26 at 11:06 +0200, Rostislav Lisovy wrote:
> On Mon, 2014-05-19 at 16:51 +0200, Johannes Berg wrote:
> > This patch is fine, but insufficient - you should also do something
> > with
> > the new flags?
>
> That's definitely a good point. I thi
From: Johannes Berg
Prior to
commit 4266129964b8238526936d723de65b419d8069c6
Author: Mauro Carvalho Chehab
Date: Tue May 31 16:27:44 2011 -0300
[media] DocBook: Move all media docbook stuff into its own directory
it was possible to build only a single (or more)
book(s) by calling, for
On Mon, 2014-05-19 at 16:49 +0200, Rostislav Lisovy wrote:
> include/uapi/linux/nl80211.h | 3 ++
> net/mac80211/Makefile| 3 +-
> net/mac80211/cfg.c | 1 +
> net/mac80211/chan.c | 2 +
> net/mac80211/driver-ops.h| 3 +-
> net/mac80211/ieee80211_i.h | 3
On Mon, 2014-05-19 at 16:49 +0200, Rostislav Lisovy wrote:
> IEEE 802.11p operates in its own 5.9GHz band. When there will
> be a record for the 5.9GHz band in the regulatory daemon,
> it must be limited to the OCB mode only -- using the newly
> added flags.
This patch is fine, but insufficient -
On Mon, 2014-05-12 at 19:51 +0200, Fabian Frederick wrote:
> Cc: Johannes Berg
> Cc: "John W. Linville"
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
> ---
> net/wireless/util.c | 42 +-
> 1 file changed,
_compiletime_error_fallback which
> uses the potentially negative size array to trigger a conditional
> compiler error, so that sparse doesn't see it.
>
> Signed-off-by: James Hogan
> Cc: Johannes Berg
> Cc: Daniel Santos
> Cc: Luciano Coelho
> Cc: Peter Zijlstr
On Mon, 2014-05-12 at 14:16 -0700, Andrew Morton wrote:
> > I don't understand why your patch should break things, I suspect it's
> > related to the sparse behaviour you're trying to work around, but can we
> > please drop this patch until a more portable workaround can be found?
>
> Older gcc's
On Mon, 2014-05-12 at 12:17 -0700, Joe Perches wrote:
> > I certainly don't see the benefit in changing all those other files,
> > particularly since it's not just that we have to verify alignment *now*,
> > we also have to add alignment attributes so that we don't break
> > alignment in the futur
On Mon, 2014-05-12 at 11:07 -0700, Joe Perches wrote:
> On Mon, 2014-05-12 at 20:00 +0200, Fabian Frederick wrote:
> > On Mon, 12 May 2014 10:50:25 -0700
> > Joe Perches wrote:
> >
> > > On Mon, 2014-05-12 at 19:30 +0200, Fabian Frederick wrote:
> > > > This patch also fixes some comment checkpat
Hi,
> Unfortunately this breaks the build of today's linux-next for the Meta
> architecture (arch/metag), which happens to use a fairly old compiler
> (based on gcc 4.2.4) which I presume is the reason why.
That's very odd.
Unfortunately, I don't have most of arch/metag, it seems, where could I
From: Johannes Berg
Usually, BUG_ON and friends aren't even evaluated in sparse, but
recently compiletime_assert_atomic_type() was added, and that now
results in a sparse warning every time it is used.
The reason turns out to be the temporary variable, after it sparse
no longer consider
On Tue, 2014-04-15 at 14:37 +0200, Rostislav Lisovy wrote:
> The IEEE 802.11p amendment specifies usage of 5 and 10 MHz wide
> channels in 5.9GHz band for vehicular environment. This patch-set
> adds new channel attributes holding the information about the
> prohibited bandwidths. This is meant to
On Tue, 2014-04-22 at 19:58 +0200, Luis R. Rodriguez wrote:
> > > > +#if IS_ENABLED(CONFIG_IEEE802154_6LOWPAN)
> > > > [...]
> > > > +#else
> > > > +static inline struct netns_ieee802154_lowpan *
> > > > +net_ieee802154_lowpan(struct net *net)
> > > > +{
> > > > + return NULL;
> > > > +}
> >
On Tue, 2014-04-15 at 14:41 +0800, Chen-Yu Tsai wrote:
> The first 2 patches should go through the gpio tree. The 4 rfkill-gpio
> patches should go through the same tree that Heikki's patches are
> in. Maxime, can you take the last one?
Are there no dependencies? Maybe it'd be easier if you sent
On Thu, 2014-04-17 at 18:22 -0700, Luis R. Rodriguez wrote:
> +#if IS_ENABLED(CONFIG_IEEE802154_6LOWPAN)
> [...]
> +#else
> +static inline struct netns_ieee802154_lowpan *
> +net_ieee802154_lowpan(struct net *net)
> +{
> + return NULL;
> +}
> +#endif
Why would that be needed? If nobody compil
On Tue, 2014-04-01 at 17:02 +0300, Heikki Krogerus wrote:
> Hi,
>
> I hope this one is OK with everyone.
Looks good to me, all applied.
It's in jberg/mac80211-next.git rfkill-gpio-cleanups branch, in case
anybody needs this separately. John isn't taking pull requests for -next
until after -rc1,
On Wed, 2014-04-09 at 09:32 -0600, Stephen Warren wrote:
> > Stephen! Are you expecting any changes to board-paz00.c in this kernel
> > cycle? If not, I think it would be easiest if Johannes, you take the
> > whole set. What do you guys think?
>
> I can't predict the future, but the chances are p
On Thu, 2014-04-10 at 10:48 -0700, Luis R. Rodriguez wrote:
> You just pass it a cocci file, a target dir, and in git environments
> you always want --in-place enabled. Experiments and profiling random
> cocci files with the Linux kernel show that using just using number of
> CPUs doesn't scale we
On Thu, 2014-04-10 at 19:26 +0200, Felix Fietkau wrote:
> On 2014-04-10 19:16, Johannes Berg wrote:
> > On Wed, 2014-04-09 at 11:18 +0200, Felix Fietkau wrote:
> >
> >> I'm looking forward to getting rid of patches for older kernels that
> >> often get
On Wed, 2014-04-09 at 11:18 +0200, Felix Fietkau wrote:
> I'm looking forward to getting rid of patches for older kernels that
> often get in the way when using various wireless-testing versions ;)
What do you frequently get conflicts on? I haven't seen any for a long
time.
johannes
--
To unsub
On Wed, 2014-04-09 at 14:06 -0700, Greg Kroah-Hartman wrote:
> Why 3.0? That's not supported by anyone anymore for "new hardware", I'd
> move to 3.2 if you could, as that's the Debian stable release that will
> be maintained for quite some time yet:
> https://www.kernel.org/category/release
On Wed, 2014-04-02 at 15:31 +0200, Rostislav Lisovy wrote:
> Since there are frequency bands (e.g. 5.9GHz) allowing channels
> with only 10 or 5 MHz bandwidth, this patch adds attributes that
> allow keeping track about this information.
>
> When channel attributes are reported to user-space, make
On Wed, 2014-04-02 at 15:31 +0200, Rostislav Lisovy wrote:
> The channels with 5/10MHz bandwidth are not HT. We have to
> reflect this in conf_is_ht() function which returns whether the
> particular channel is HT or not.
Applied.
johannes
--
To unsubscribe from this list: send the line "unsubscr
On Tue, 2014-04-01 at 17:02 +0300, Heikki Krogerus wrote:
> Hi,
>
> I hope this one is OK with everyone.
It's fine with me. Are you expecting me to pick up any of these patches,
or do you want them to go through some other tree? Either way is fine
with me, but the first patch looks like something
On Tue, 2014-03-11 at 14:05 +0100, Rostislav Lisovy wrote:
> The IEEE 802.11p amendment specifies usage of 5 and 10 MHz wide
> channels in 5.9GHz band for vehicular environment. This patch-set adds
> new channel attributes holding the information about the prohibited
> bandwidths. This is meant to
Applied, but I rewrote the commit log and squashed the mac80211 patches
into one.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please rea
On Thu, 2014-03-20 at 23:39 -0700, beh...@converseincode.com wrote:
> From: Jan-Simon Möller
>
> Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
> compliant equivalent. This is the original VLAIS struct.
>
> struct {
> struct aead_request req;
> u8
I'm confused.
On Tue, 2014-03-18 at 20:32 -0700, beh...@converseincode.com wrote:
> struct scatterlist assoc, pt, ct[2];
> - struct {
> - struct aead_request req;
> - u8 priv[crypto_aead_reqsize(tfm)];
> - } aead_req;
>
> - mem
On Sat, 2014-03-15 at 21:03 +0530, Krishna Chaitanya wrote:
> > > what RC are u using? Default should be minstrel, i dont see
> > > a reason for rc alloc to fail (remote reason kmalloc failure),
> > > so did you disable RC completely? No prints either w.r.t RC either in
> > > dmesg?
> >
> > Pay at
On Thu, 2014-03-13 at 02:15 +0530, Krishna Chaitanya wrote:
> From the logs it looks like "rate_control_alloc" is failed,
> causing ieee80211_register_hw to fail triggering the crash.
Yes.
> what RC are u using? Default should be minstrel, i dont see
> a reason for rc alloc to fail (remote reaso
On Thu, 2014-03-06 at 11:52 -0800, beh...@converseincode.com wrote:
> From: Jan-Simon Möller
>
> Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
> compliant equivalent.
Fine, but
> + char aead_req_data[sizeof(struct aead_request)
> + + cr
On Thu, 2014-02-27 at 15:56 +0100, David Herrmann wrote:
> >> +++ b/net/mac80211/iface.c
> >> @@ -1620,6 +1620,7 @@ int ieee80211_if_add(struct ieee80211_local *local,
> >> const char *name,
> >> + IEEE80211_ENCRYPT_HEADROOM;
> >> ndev->needed_t
Given the premise of your patches,
> +++ b/net/mac80211/iface.c
> @@ -1620,6 +1620,7 @@ int ieee80211_if_add(struct ieee80211_local *local,
> const char *name,
> + IEEE80211_ENCRYPT_HEADROOM;
> ndev->needed_tailroom = IEEE80211_ENCRYPT_TAILROOM;
On Tue, 2014-02-25 at 14:22 +0200, Heikki Krogerus wrote:
> I was waiting for the DT support from Chen-Yu before sending these,
> but decided it makes no difference when I send them. I'm dropping the
> con ID in the second patch because Dan noticed the warning, but of
> course it will mean the "gp
On Tue, 2014-02-25 at 14:22 +0200, Heikki Krogerus wrote:
> After moving to description based gpio interface in
> rfkill-gpio, the gpio numbers are not used any more.
>
> Signed-off-by: Heikki Krogerus
> ---
> arch/arm/mach-tegra/board-paz00.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deleti
From: Johannes Berg
Since there are registration/unregistration functions and the
invocation is in the core code, there's no need to export the
notifier chain head, make it static instead.
Signed-off-by: Johannes Berg
---
This should probably go into 3.14 so it's not exported in t
On Thu, 2014-02-20 at 23:09 -0500, Steven Rostedt wrote:
> On Fri, 21 Feb 2014 09:39:18 +1030
> Rusty Russell wrote:
>
> > >> comment "Do not forget to sign required modules with scripts/sign-file"
> > >> depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
> > >>
> > >> Then you didn't do that. You
On Sat, 2014-02-15 at 12:55 +0100, Justin van Wijngaarden wrote:
> @@ -1,19 +1,17 @@
> -/*
> - * mac80211_hwsim - software simulator of 802.11 radio(s) for mac80211
> +/* mac80211_hwsim - software simulator of 802.11 radio(s) for mac80211
I don't see any point in this - lots of code exists both w
On Tue, 2014-02-11 at 12:36 -0600, Calvin Owens wrote:
> Create a function to return a descriptive string for each reason code,
> and print that in addition to the numeric value in the kernel log. These
> codes are easily found on popular search engines, but one is generally
> not able to access th
On Tue, 2014-02-11 at 17:48 +0100, Antonio Quartulli wrote:
> On 11/02/14 17:37, Calvin Owens wrote:
> > Create a function to return a descriptive string for each reason code,
> > and print that in addition to the numeric value in the kernel log. These
> > codes are easily found on popular search e
On Fri, 2014-02-07 at 15:28 -0500, Steven Rostedt wrote:
> I'm thinking no. And unless someone can give me a good reason that we
> should have such a thing, I will Nack my own patch!
:)
> What's up with trace_iwlwifi_dev_irq()? You are tracing it but not
> saving any information. There's obviou
Commit-ID: 980f88e414418bf65569a3b62b08b07e6fc2f4c6
Gitweb: http://git.kernel.org/tip/980f88e414418bf65569a3b62b08b07e6fc2f4c6
Author: Johannes Berg
AuthorDate: Thu, 6 Feb 2014 17:28:41 +0100
Committer: Ingo Molnar
CommitDate: Sun, 9 Feb 2014 13:11:49 +0100
sched/wait: Suppress Sparse
On Wed, 2014-02-05 at 20:44 -0800, Joe Perches wrote:
> Perhaps use a more common kernel style
>
> struct ieee80211_reason_descriptions {
> u16 code;
> const char *desc;
> }
>
> and enumerate the reason codes with #defines and use a
> macro to populate the description
On Fri, 2014-02-07 at 20:48 +0100, Marek Belisko wrote:
> +#define RFKILL_TYPE_ALL (0)
> +#define RFKILL_TYPE_WLAN (1)
> +#define RFKILL_TYPE_BLUETOOTH(2)
> +#define RFKILL_TYPE_UWB (3)
> +#define RFKILL_TYPE_WIMAX(4)
> +#define RFKILL_TYPE_WWAN (5)
>
From: Johannes Berg
This warning seems to show up a lot now, since ___wait_event()
is (indirectly) used inside wait_event_timeout(), which also
has a variable called __ret. Rename the one in ___wait_event()
to ___ret (another leading underscore) to suppress the warning.
Signed-off-by: Johannes
On Wed, 2014-02-05 at 19:44 -0600, Calvin Owens wrote:
> Create a function to return a descriptive string for each reason code,
> and print that instead of the numeric value in the kernel log. These
> codes are easily found on popular search engines, but one is generally
> not able to access the in
On Thu, 2014-01-30 at 15:08 -0800, Zoran Markovic wrote:
> From: Shaibal Dutta
>
> For better use of CPU idle time, allow the scheduler to select the CPU
> on which the timeout work of regulatory settings would be executed.
> This extends CPU idle residency time and saves power.
>
> This functio
On Thu, 2014-01-30 at 14:43 -0800, Zoran Markovic wrote:
> From: Shaibal Dutta
>
> This patch moves the rfkill poll_work to the power efficient workqueue.
> This work does not have to be bound to the CPU that scheduled it, hence
> the selection of CPU that executes it would be left to the schedul
On Fri, 2014-01-31 at 04:35 -0500, Tejun Heo wrote:
> Hello,
>
> On Fri, Jan 31, 2014 at 10:21:24AM +0100, Johannes Berg wrote:
> > I'm not sure if this is part of a larger patchset actually adding that
> > "system_power_efficient_wq", but maybe it'd be
On Thu, 2014-01-30 at 15:08 -0800, Zoran Markovic wrote:
> From: Shaibal Dutta
>
> For better use of CPU idle time, allow the scheduler to select the CPU
> on which the timeout work of regulatory settings would be executed.
> This extends CPU idle residency time and saves power.
>
> This functio
it didn't
cause you too much trouble. The problem was that I misplaced some code
because I didn't notice that the if () condition (see below) had no
braces.
I replaced that commit with
commit 091a69f86862454c282d4a64c9d66074e60514ea
Author: Johannes Berg
Date: Wed Jan 22 10:36:59 201
On Fri, 2014-01-17 at 14:47 +0800, Chen-Yu Tsai wrote:
> This patch series adds device tree support to rfkill-gpio, and
> fixes some issues I ran into. This is so we can define and control
> RF devices through the device tree, such as the Broadcom BCM20710
> UART-based Bluetooth device found on th
> > IMHO the context extension doesn't work well enough in sparse to
> > document and implement as is. It would be much better if it actually was
> > able to differentiate between contexts, rather than treating each one
> > the same.
>
> That would certainly be nice, but that's something actually
On Thu, 2014-01-16 at 21:27 -0800, H. Peter Anvin wrote:
> However, I would also like support for the context extensions, but I'm
> not knowledgeable enough to describe the semantics accurately. Would
> anyone be willing to file a ticket describing how the context extension
> works well enough th
On Tue, 2014-01-14 at 15:41 +0800, Ying Xue wrote:
> @@ -2218,10 +2194,6 @@ static int nl80211_set_wiphy(struct sk_buff *skb,
> struct genl_info *info)
> rdev->wiphy.coverage_class = old_coverage_class;
> }
> }
> -
> - bad_res:
> - if (netdev)
> -
On Mon, 2014-01-06 at 15:00 -0500, John W. Linville wrote:
> On Tue, Dec 31, 2013 at 10:47:29AM +0100, Pali Rohár wrote:
> > On Sunday 08 December 2013 10:24:58 Pali Rohár wrote:
> > > Hello, I'm sending wl1251 patches from linux-n900 tree [1] for
> > > comments. More patches come from David's moni
On Mon, 2013-12-23 at 13:10 +0800, Ding Tianhong wrote:
> Use the recently added and possibly more efficient
> ether_addr_equal_unaligned to instead of memcmp.
> - if (memcmp(local->hw.wiphy->addresses[i].addr,
> -sdata->vif.addr,
On Thu, 2013-12-26 at 19:40 +0800, Ding Tianhong wrote:
> Use the possibly more efficient ether_addr_equal
> to instead of memcmp.
This is a slow-path, I don't think that's really worth it. It kinda
makes sense, but relies on the struct mac_address allocation for
alignment and the fact that there
On Mon, 2014-01-06 at 15:01 +0100, Andreas Mohr wrote:
> config LIB80211
> tristate
> config LIB80211_CRYPT_WEP
> tristate
>
> config LIB80211_CRYPT_CCMP
> tristate
>
> config LIB80211_CRYPT_TKIP
> tristate
> make menuconfig
> showed these three crypt option
On Mon, 2014-01-06 at 10:09 +0100, Julia Lawall wrote:
> > BUILD_BUG_ON(sizeof(struct foo) - offsetof(struct foo, addr) < 8);
> >
> > with the user(s?) and that should catch the scenario I was worrying
> > about?
>
> OK, thanks. That is what I had in mind. But I was hoping to be able to
> put i
On Mon, 2014-01-06 at 10:04 +0100, Julia Lawall wrote:
> OK, the question was expressed badly. Is there any way to use the value
> to trigger an action at build time? The only way I kow to trigger an
> action is with #error, but #error is processed by cpp, which doesn't know
> about the size of
On Tue, 2013-12-31 at 17:40 +0100, Julia Lawall wrote:
> > If nothing else, then some run-time code that calculates the offset off
> > and asserts if it is broken in module initialization or similar might
> > be good enough.
>
> Could be OK. Something right in or after the structure declaration
On Mon, 2013-12-30 at 19:57 -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 30 Dec 2013, Johannes Berg wrote:
> > On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wrote:
> > > > Is there any way we could catch (sparse, or some other script?) that
> > > > st
On Mon, 2013-12-30 at 20:58 +0100, Julia Lawall wrote:
> > Is there any way we could catch (sparse, or some other script?) that
> > struct reorganising won't break the condition needed ("within a
> > structure that contains at least two more bytes")?
>
> What kind of reorganizing could happen? D
On Mon, 2013-12-30 at 19:15 +0100, Julia Lawall wrote:
> From: Julia Lawall
>
> Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be
> used when each argument is an array within a structure that contains at
> least two bytes of data beyond the array.
>
> The structures inv
On Mon, 2013-12-23 at 12:54 +0200, Mika Westerberg wrote:
> On Wed, Dec 11, 2013 at 01:00:18PM +0100, Linus Walleij wrote:
> > On Tue, Nov 26, 2013 at 11:05 AM, Mika Westerberg
> > wrote:
> >
> > > From: Heikki Krogerus
> > >
> > > Convert to the safer gpiod_* family of API functions.
> > >
> >
Hi all,
We really should be asking Luis to look at this who hasn't yet chimed
in, presumably because he's between jobs (and travelling IIRC)
On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote:
> On 12/17/2013 11:06 PM, Linus Torvalds wrote:
> > We have literally had this *exact* same issue
From: Johannes Berg
sparse complains about any __ksymtab symbols with the following:
warning: symbol '__ksymtab_...' was not declared. Should it be static?
due to Andi's patch making it non-static.
Mollify sparse by declaring the symbol extern, otherwise we get
drowned in spar
On Sun, 2013-12-08 at 09:45 +0100, Pali Rohár wrote:
> From: David Gnedt
>
> Count TX packets and bytes also for monitor interfaces.
> + dev->stats.tx_packets++;
> + dev->stats.tx_bytes += skb->len;
> +
> /*
>* fix up the pointers accounting for the radiotap
>* head
On Wed, 2013-12-04 at 16:41 +0800, Chen Gang wrote:
> According to our original discussion, it seems we agree that I am not
> the suitable member to finish it, so I suggest you or another members to
> try.
There's nothing to finish here. The code is fine. The compiler is wrong,
but we haven't fou
On Tue, 2013-12-03 at 10:29 -0800, Joe Perches wrote:
> Remove the unnecessary duplicate test of "if (skb) {"
> when !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
>
> Remove now unnecessary __maybe_unused, neaten comment
> Remove unnecessary parenthesis around align cast.
> Substitute reference to depr
On Wed, 2013-12-04 at 10:12 +0800, Chen Gang wrote:
> It is really not urgent, and for keeping quality, it is necessary to
> spend suitable time resource (e.g 1 hour or more) to make, review and
> test this kind of patch carefully by oneself.
>
> So could you please help improve it when you have
On Tue, 2013-12-03 at 15:52 +, John W. Linville wrote:
> > Today's linux-next merge of the wireless-next tree got a conflict in
> > net/mac80211/util.c between commit 3f718fd8401d ("mac80211: fix the mesh
> > channel switch support") from the wireless tree and commit ca91dc97b8a0
> > ("mac8021
On Sun, 2013-12-01 at 14:38 -0800, Joe Perches wrote:
> On Sun, 2013-12-01 at 10:35 +0100, Johannes Berg wrote:
> > Good try, but no, now ap_sdata isn't even assigned. :)
>
> Right. Oh well. There's no improving this without
> significant rewrite. Even then, the
On Sun, 2013-12-01 at 07:48 +0800, Chen Gang wrote:
> If ieee80211_subif_start_xmit() is not performance sensitive (I guess
> so), we can use some short static functions instead of some code blocks
> within ieee80211_subif_start_xmit().
>
> - ieee80211_subif_start_xmit() is a long function (600+
On Sat, 2013-11-30 at 12:39 -0800, Joe Perches wrote:
> +++ b/net/mac80211/tx.c
> @@ -1777,18 +1777,16 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff
> *skb,
> }
> ap_sdata = container_of(sdata->bss, struct
> ieee80211_sub_if_data,
>
On Sat, 2013-11-30 at 22:02 +0800, Chen Gang wrote:
> >>> case NL80211_IFTYPE_AP:
> >>> - if (sdata->vif.type == NL80211_IFTYPE_AP)
> >>> - chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
> >>> + chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
>
On Sat, 2013-11-30 at 19:59 +0800, Chen Gang wrote:
> On 11/29/2013 11:38 PM, Johannes Berg wrote:
> >
> >> +++ b/net/mac80211/tx.c
> >> @@ -1814,8 +1814,9 @@ netdev_tx_t ieee80211_subif_start_xmit(struct
> >> sk_buff *skb,
> >>
> +++ b/net/mac80211/tx.c
> @@ -1814,8 +1814,9 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff
> *skb,
> break;
> /* fall through */
> case NL80211_IFTYPE_AP:
> - if (sdata->vif.type == NL80211_IFTYPE_AP)
> - chanc
Please don't top-post. You're making a lot of obvious mistakes, to the
likely effect that soon enough people won't even read your email.
> Did you have a chance to look at this? Let me know how you want me to
> fix this.
By not "fixing" anything?
> >> Is is quite unlikely thats skb is NULL. So i
after resume
>
> This fixes bug 62491 (https://bugzilla.kernel.org/show_bug.cgi?id=62491).
> After resuming some users got the following error flooding the kernel log:
> alx :02:00.0: invalid PHY speed/duplex: 0xffff
Acked-by: Johannes Berg
> Signed-off-by: Jonas Hahnfeld
&g
On Mon, 2013-11-11 at 14:41 +0100, Johannes Berg wrote:
> > @@ -1150,7 +1149,14 @@ static irqreturn_t iwl_pcie_isr(int irq, void *data)
> > * or due to sporadic interrupts thrown from our NIC. */
> > if (!inta) {
> > IWL_DEBUG_ISR(trans, "
On Sun, 2013-11-10 at 21:17 +0100, Michal Nazarewicz wrote:
> inta is checked to be zero in a IRQ_NONE branch so afterwards it
> cannot be zero as it is never modified.
no signed-off-by
> @@ -1150,7 +1149,14 @@ static irqreturn_t iwl_pcie_isr(int irq, void *data)
>* or due to sporadic in
On Fri, 2013-11-01 at 17:19 -0400, Steven Rostedt wrote:
> Please Cc me on trace-cmd patches.
>
> Johannes and Darren,
>
> Since you handle the python bindings in trace-cmd, can you give me an
> ack or nack.
Looks fine to me, in that it would work on my system :)
johannes
--
To unsubscribe fro
On Mon, 2013-10-28 at 09:46 -0500, Dan Williams wrote:
> If the device doesn't actually *have* a permanent MAC address, then it
> shouldn't be returning one via ethtool, and should return an error for
> ETHTOOL_GPERMADDR.
There's currently no provision for that, but I agree it would be better
to
On Tue, 2013-10-22 at 22:02 +0200, Simon Wunderlich wrote:
> The wext internal chandefs for ibss should be created using the
> cfg80211_chandef_create() functions. Otherwise the center_freq1 field
> will not be set and cfg80211_chandef_valid() will spit a warning and
> report the chandef as invalid
On Mon, 2013-10-28 at 14:49 +0100, Pali Rohár wrote:
> On Monday 28 October 2013 14:45:05 Johannes Berg wrote:
> > On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> > > Driver wl1251 generating mac address randomly at startup and
> > > there is no way to se
901 - 1000 of 1314 matches
Mail list logo
