On Mon, 2014-12-22 at 19:10 +0100, Paul Bolle wrote:
> Commit 24a0aa212ee2 ("cfg80211: make WEXT compatibility unselectable")
> made it impossible to depend on CFG80211_WEXT. It does still allow to
> select that symbol. (Yes, the commit summary is confusing.)
>
> So make IPW2200 select CFG80211_WE
On Fri, 2014-12-12 at 12:35 +0100, Krzysztof Konopko wrote:
> I'm _far_ from being a wireless expert but doesn't data coming out of
> the wire/air have the endianess defined explicitly? And both `AC_param`
> and `ADDBA_request` come out of air?
In general, data in 802.11 frames is little endian.
On Mon, 2014-12-01 at 21:34 +0100, Julia Lawall wrote:
> > So this kind of evolution is no problem for the (automated) backports
> > using the backports project - although it can be difficult to detect
> > such a thing is needed.
>
> That is exactly the problem...
I'm not convinced though that i
On Mon, 2014-12-01 at 02:34 +0100, SF Markus Elfring wrote:
> > Some of those NULL pointer checks on input parameters may have been
> > added subsequently to functions. So there may be older kernel versions
> > out there in which those checks dont exists in some cases. If some of
> > the now "clea
From: Johannes Berg
The change from \d+ to .+ inside __aligned() means that the following
structure:
struct test {
u8 a __aligned(2);
u8 b __aligned(2);
};
essentially gets modified to
struct test {
u8 a;
};
for purposes of kernel-doc, thus dropping a struct member
On Fri, 2014-11-14 at 12:52 -0800, Luis R. Rodriguez wrote:
> On Fri, Nov 14, 2014 at 12:50 PM, Johannes Berg
> wrote:
> > On Tue, 2014-11-11 at 00:14 -0800, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez"
> >>
> >> This third ser
On Tue, 2014-11-11 at 00:14 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This third series should hopefully address all pending feedback.
> I've split out patches even more, but more importantly have
> made the parser simpler by both integrating the logic required
> to understa
On Tue, 2014-11-11 at 00:15 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> When using backports against for packaging with --gitdebug you either
> have to use --clean or assume the directory is empty already. In either
> case you start fresh. With integration this will be a bit d
On Thu, 2014-11-13 at 13:56 -0800, Kees Cook wrote:
> > + /*
> > +* This essentially makes the attribute write-once, since you can't
> > +* go back to not having it disabled. This is intentional, it serves
> > +* as a system lockdown feature.
> > +*/
> > +
From: Johannes Berg
Since device/firmware coredumps can contain private data, it can
be desirable to turn them off unconditionally to be certain that
no such data will be collected by the system.
To achieve this, provide a "disabled" sysfs class attribute that
can only be changed f
On Tue, 2014-11-11 at 11:35 +0100, Arend van Spriel wrote:
> What did pop up is the wiphy flags vs. nl80211 feature flags. When that
> comes up it looks like 'potAtoes, potaetoes' to me.
>
> So is there are clear design rule for when to use which flag. For me the
> wiphy object represents the dev
On Tue, 2014-11-11 at 10:54 +0100, Arend van Spriel wrote:
> > Also, there's a competing approach from QCA that's far more suited.
>
> I probably was not paying attention to it, but would you have a
> reference to this.
... digs around in email ...
http://mid.gmane.org/1343907187-6686-1-git-sen
On Tue, 2014-11-11 at 05:56 +, Gautam (Gautam Kumar) Shukla wrote:
> For offloading 4 way handshake to driver, currently we don't have any
> member of struct cfg80211_connect_params to pass PSK from supplicant
> to driver. I have added psk for the same and added rest of the code
> needed in nl
On Wed, 2014-11-05 at 21:29 +0100, Luis R. Rodriguez wrote:
> > What difference does this make? It'll break some scripting that we have
> > for sure (assuming the BACKPORTED_ prefix), so naturally I'd like to see
> > why it is necessary.
>
> Sure, let me explain. So if we don't unify we will have
On Wed, 2014-11-05 at 21:11 +0100, Luis R. Rodriguez wrote:
> This does mean that bp_prefix topic *can* also be tied down
> with this other directory prefix as a form of 'builder' for
> integration. Making the prefix configurable would make sense
> then only if also making the directory prefix sho
On Wed, 2014-11-05 at 21:13 +0100, Luis R. Rodriguez wrote:
> On Wed, Nov 05, 2014 at 08:54:11AM +0100, Johannes Berg wrote:
> > On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez"
> > >
> > > During d
On Wed, 2014-11-05 at 20:42 +0100, Luis R. Rodriguez wrote:
> > No, I mean if bp_prefix were to contain some special character like [.
> > This can't actually happen though.
>
> OK if that can't happen then I don't see the point.
Where by "can't happen" I mean that Kconfig probably wouldn't be h
On Wed, 2014-11-05 at 10:16 +0100, Luis R. Rodriguez wrote:
> > IMHO this would be better handled in the code that uses the return value
> > to add things to the Kconfig dependencies, there you could just go
> > if integrate:
> > deplist[sym] = ["BACKPORT_" + x for x in new]
> > else:
> >
On Wed, 2014-11-05 at 09:02 +0100, Luis R. Rodriguez wrote:
> > But the *code* changes
> > you're making here that check whether bp_prefix is being duplicated
> > aren't necessary for that, and are in fact confusing and dangerous.
>
> Understood, thanks for the review, hopefully this is addressed
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> In order to help unify the naming scheme for shared
> backports versioning information rely on the CPTCFG_
> prefix, when integration support gets added that will
> translate to the respective CONFIG_BACKP
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> +++ b/backport/Kconfig.package
> @@ -0,0 +1,32 @@
> +mainmenu "Backports from $BACKPORTED_KERNEL_NAME $BACKPORTED_KERNEL_VERSION
> (backports $BACKPORTS_VERSION)"
> +
> +config BACKPORT_DIR
> + string
> + option env="BACKPORT_D
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> During development of kernel integration support using CONFIG_BACKPORT
> was evaluated as a prefix over CPTCFG even for packaging backports,
> for some reason this change lifted some restrictions one some
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> @@ -21,23 +22,53 @@ class ConfigTree(object):
> yield f
> for l in open(os.path.join(self.basedir, f), 'r'):
> m = src_line.match(l)
> -if m and os.path.exists(os.path.join(self.basedir,
> m.g
On Tue, 2014-11-04 at 19:18 -0800, Luis R. Rodriguez wrote:
> @@ -71,6 +71,9 @@ def read_dependencies(depfilename):
> ret[sym].append(kconfig_exp)
> else:
> sym, dep = item.split()
> +if bp_prefix != 'CPTCFG_':
> +dep_prefix = re.s
On Wed, 2014-11-05 at 01:21 +0100, Luis R. Rodriguez wrote:
> > > I did at one point have BACKPORT_BPAUTO_* stuff on the compat/Kconfig for
> > > the auto stuff but figured that was superfluous. I'll respin with it.
> >
> > Not sure what you mean? It seems to me you should just drop the changes
>
On Tue, 2014-11-04 at 22:50 +0100, Luis R. Rodriguez wrote:
> On Tue, Nov 04, 2014 at 11:14:52AM +0100, Johannes Berg wrote:
> > On Tue, 2014-11-04 at 00:43 -0800, Luis R. Rodriguez wrote:
> >
> > > -mf.write('compat-$(%s%s) += %s\n' % (bp_pr
On Tue, 2014-11-04 at 13:49 +0100, Rostislav Lisovy wrote:
> Use the same ordering in the comments section as it
> is in the structure below.
Well, I think I confused you :-)
The report from Fengguang's build bot was actually when there was no
documentation, and then I added it and I guess you tho
On Tue, 2014-11-04 at 00:43 -0800, Luis R. Rodriguez wrote:
> -mf.write('compat-$(%s%s) += %s\n' % (bp_prefix, sym, '
> '.join(o_files)))
> +if bp_prefix not in sym:
> +mf.write('compat-$(%s%s) += %s\n' % (bp_prefix, sym, '
> '.join(o_files)))
> +
On Tue, 2014-11-04 at 00:43 -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Instead of relying on Makefile hacks just use Kconfig for
> defining the variables needed. We can do this since these
> variables are all known at packaging time. The exception
> is BACKPORTS_GIT_TRACKED,
On Tue, 2014-11-04 at 00:42 -0800, Luis R. Rodriguez wrote:
> --- a/devel/ckmake
> +++ b/devel/ckmake
> @@ -165,6 +165,7 @@ def process_kernel(num, kset, cmdline_args):
> all_config_name = os.path.join(work_dir, 'all.config')
> all_config = open(all_config_name, 'w')
> a
On Tue, 2014-11-04 at 00:42 -0800, Luis R. Rodriguez wrote:
> +#ifndef MODULE
> +/*
> + * Forcing the backports module to load allows us to easily
> + * identify the backport.
> + */
That comment is wrong really, making the dependency on the symbol forced
the backport module to load but if it's b
On Mon, 2014-11-03 at 10:33 +0100, Rostislav Lisovy wrote:
> The IEEE 802.11p amendment (already part of IEEE 802.11-2012)
> specifies usage of 5 and 10 MHz wide channels in 5.9GHz band for
> vehicular environment. All the 802.11p compliant devices should
> be set to the newly added operation mode
On Mon, 2014-11-03 at 12:21 -0800, Luis R. Rodriguez wrote:
> OK I'll prefix the stuff we copy over with something else then, BPAUTO.
I still want to keep CPTCFG though :)
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
On Mon, 2014-11-03 at 11:56 -0800, Luis R. Rodriguez wrote:
> With my current code I end up with on a package (not integration):
>
> config BACKPORT_BUILD_AVERAGE
> bool
> depends on !AVERAGE
> default y if BACKPORT_USERSEL_BUILD_ALL
> default y if BACKPORT_AVERAGE
On Mon, 2014-11-03 at 11:30 -0800, Luis R. Rodriguez wrote:
> On Fri, Oct 31, 2014 at 1:33 PM, Luis R. Rodriguez wrote:
> >> That also makes me think of something else - we currently use BACKPORT_
> >> as a prefix for some of the other stuff under compat/Kconfig, and in
> >> fact rename some thing
On Fri, 2014-10-31 at 20:34 +0100, Luis R. Rodriguez wrote:
> > I really think you need to make this optional for the in-tree
> > generation, otherwise it will complicate things a lot for anyone who's
> > already using backports in a way that doesn't have it regenerated all
> > the time.
>
> Logi
On Fri, 2014-10-31 at 16:12 +0100, Rostislav Lisovy wrote:
> On Fri, 2014-10-31 at 14:13 +0100, Johannes Berg wrote:
> > On Thu, 2014-10-30 at 11:42 +0100, Rostislav Lisovy wrote:
> > > @@ -2093,6 +2102,7 @@ enum nl80211_iftype {
> > > NL80211_IFTYPE_P2P_CLIENT,
&g
On Thu, 2014-10-30 at 11:42 +0100, Rostislav Lisovy wrote:
> +int ieee80211_ocb_join(struct ieee80211_sub_if_data *sdata,
> +struct ocb_setup *setup)
> +{
> + struct ieee80211_local *local = sdata->local;
> + struct ieee80211_if_ocb *ifocb = &sdata->u.ocb;
> + u32 c
On Thu, 2014-10-30 at 11:42 +0100, Rostislav Lisovy wrote:
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -263,6 +263,7 @@ struct ieee80211_vif_chanctx_switch {
> * @BSS_CHANGED_BANDWIDTH: The bandwidth used by this interface changed,
> * note that this is only called whe
On Fri, 2014-10-31 at 10:06 +0100, Paul Bolle wrote:
> On Fri, 2014-10-31 at 09:45 +0100, Johannes Berg wrote:
> > On Fri, 2014-10-31 at 09:40 +0100, Paul Bolle wrote:
> > > Your commit aadede6e9f4c ("iwlwifi: mvm: port to devcoredump framework")
> > > landed
On Fri, 2014-10-31 at 09:40 +0100, Paul Bolle wrote:
> Your commit aadede6e9f4c ("iwlwifi: mvm: port to devcoredump framework")
> landed in today's linux-next (next-20141031). It adds a select statement
> for BACKPORT_WANT_DEV_COREDUMP. There's no Kconfig symbol
> BACKPORT_WANT_DEV_COREDUMP so thi
On Wed, 2014-10-29 at 17:00 +0100, Luis R. Rodriguez wrote:
> backport/Kconfig | 54
> backport/Kconfig.package | 31 +
> backport/Kconfig.sources | 23
I think you should do this split as a separate patch
On Wed, 2014-10-29 at 01:21 -0700, Luis R. Rodriguez wrote:
> src_line = re.compile(r'^\s*source\s+"?(?P[^\s"]*)"?\s*$')
> +bk_src_line =
> re.compile(r'^\s*source\s+"?\$BACKPORT_DIR/(?P[^\s"]*)"?\s*$')
> tri_line = re.compile(r'^(?P\s+)tristate')
> bool_line = re.compile(r'^(?P\s+)bool')
> c
On Wed, 2014-10-29 at 01:21 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This will also be used for built-in kernel integration, by
> using this we can share more code with the built-in kernel
> approach.
I see no issues with this, looks like a straight rename.
johannes
--
T
On Wed, 2014-10-29 at 01:21 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> In order to support built-in kernel integration we want to use
> a more generic approach to defining symbols, CPTCFG was nice as
> it was short and relied on the fact that kconfig can work with
> a getenv(
From: Johannes Berg
The ENABLE_DEV_COREDUMP option is misleading as it implies that
it gets the framework enabled, this isn't true it just allows it
to get enabled if a driver needs it.
Rename it to ALLOW_DEV_COREDUMP to better capture its semantics.
Signed-off-by: Johannes Berg
---
dr
On Tue, 2014-10-21 at 06:18 +0800, Greg Kroah-Hartman wrote:
> > I've added this to the tiny/reverse-dev-coredump branch of my
> > tinification tree at
> > https://git.kernel.org/cgit/linux/kernel/git/josh/linux.git/ , with
> > Johannes' review, and I'll push it upstream during the 3.19 merge
> >
On Sat, 2014-10-25 at 17:57 +0200, Fabian Frederick wrote:
> radar_detect_width is unused since commit 97dc94f1d933
> ("cfg80211: remove channel_switch combination check")
Applied, thanks.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
On Tue, 2014-10-28 at 09:31 +0800, Junjie Mao wrote:
> The driver is not released when ieee80211_register_hw fails in
> mac80211_hwsim_create_radio, leading to the access to the unregistered (and
> possibly freed) device in platform_driver_unregister:
Applied.
johannes
--
To unsubscribe from thi
rge it
> with the rest of the device-properties patches. Thanks.
Acked-by: Johannes Berg
Reviewed-by: Johannes Berg
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 read the FAQ at http://www.tux.org/lkml/
On Tue, 2014-10-21 at 22:05 +0200, Fabian Frederick wrote:
> I can also resubmit patch if necessary.
No worries, I've already applied the patch (with a modified commit
message).
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
On Tue, 2014-10-21 at 18:20 +0200, Fabian Frederick wrote:
> Fix checkpatch warnings:
>
> WARNING: debugfs_remove(NULL) is safe this check is probably not required
I'll apply this; however, I think that checkpatch is a just tool, and
the commit message should reflect why you're changing the c
REDUMP.
>
> This patch renames the option to ENABLE_DEV_COREDUMP and setting it to
> 'n' (as in allnconfig or tinyconfig) will effectively disable device
> coredump.
>
> Cc: Greg Kroah-Hartman
> Cc: Josh Triplett
> Cc: Johannes Berg
Reviewed-by: Johannes Berg
On Thu, 2014-10-16 at 19:20 +0200, Rostislav Lisovy wrote:
> Now I realized it is not that easy (and I confused "interface running"
> and being "connected to the network"). There seems not to be a solid
> indication that we are no longer "connected" to the network.
Oops, ignore my previous reply.
On Thu, 2014-10-16 at 18:33 +0200, Rostislav Lisovy wrote:
> You are right. I hope the following is a reasonable solution (in form of
> a patch to my previous patch; comment stolen from some prehistoric
> version of mesh.c):
>
> @@ -127,6 +127,9 @@ void ieee80211_ocb_work(struct ieee80211_sub_if_
On Thu, 2014-10-09 at 20:36 +0200, Fabian Frederick wrote:
> No need to store ieee80211_vif_use_reserved_context result and test it before
> returning.
Makes sense, applied. Please break commit log lines to <=72 characters
in the future though.
johannes
--
To unsubscribe from this list: send th
On Thu, 2014-10-09 at 11:33 -0400, John W. Linville wrote:
> On Thu, Oct 09, 2014 at 11:16:53AM +0200, Johannes Berg wrote:
> > Applied, with a somewhat better changelog.
>
> FWIW, I had already merged that one as-is -- sorry!
Hmm? That can't be right - then I shouldn'
Applied, with a somewhat better changelog.
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 read the FAQ at http://www.tux.org/lkml/
On Thu, 2014-09-11 at 16:30 +0200, Rostislav Lisovy wrote:
> Signed-off-by: Rostislav Lisovy
same comment about commit log here - also this patch should either go
first in the series, or just be squashed with the cfg80211 patch,
there's no real need to distinguish between the two. I guess it can'
On Thu, 2014-09-11 at 16:30 +0200, Rostislav Lisovy wrote:
> Signed-off-by: Rostislav Lisovy
A bit more commit log would be good :)
> +++ b/include/net/cfg80211.h
> @@ -375,6 +375,8 @@ static inline enum nl80211_channel_type
> cfg80211_get_chandef_type(const struct cfg80211_chan_def *chandef)
>
On Thu, 2014-09-11 at 16:30 +0200, Rostislav Lisovy wrote:
[...]
Nice work. Let me (finally) look in more detail ...
> +++ b/include/uapi/linux/nl80211.h
> @@ -2031,6 +2031,8 @@ enum nl80211_attrs {
> * and therefore can't be created in the normal ways, use the
> * %NL80211_CMD_START_P2
From: Johannes Berg
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware sta
On Thu, 2014-09-11 at 10:36 +, Sharma, Sanjeev wrote:
> > - ZD_ASSERT(!spin_is_locked(&mac->lock));
> > + lockdep_assert_held(&mac->lock);
> >Look closely at this again.
>
> I didn't understand where I put wrong logic ?
Ok, that's fine. But please send a new patch only when you've und
On Thu, 2014-09-11 at 15:39 +0530, Sanjeev Sharma wrote:
> on some architecture spin_is_locked() always return false in
> uniprocessor configuration and therefore it would be advise
> to replace with lockdep_assert_held().
>
> Signed-off-by: Sanjeev Sharma
> ---
> Changes in v2:
> - corrected t
On Thu, 2014-09-11 at 04:02 +, Sharma, Sanjeev wrote:
> -Original Message-
> From: Johannes Berg [mailto:johan...@sipsolutions.net]
> Sent: Friday, August 22, 2014 5:01 PM
> To: Sharma, Sanjeev
> Cc: d...@gentoo.org; k...@deine-taler.de; linvi...@tuxdriver.com;
On Wed, 2014-09-10 at 19:21 +0530, Sudip Mukherjee wrote:
> as pr_* macros are more preffered over printk, so printk replaced
> with corresponding pr_* macros.
Are you simply running checkpatch on every file and decided to do
something about it? :)
I'll let Takashi decide whether to take this or
On Fri, 2014-09-05 at 15:13 -0700, Greg Kroah-Hartman wrote:
> > + /*
> > +* this seems racy, but I don't see a notifier or such on
> > +* a struct device to know when it goes away?
> > +*/
> > + if (devcd->failing_dev->kobj.sd)
> > + sysfs_delete_link(&devcd->failing_dev
On Fri, 2014-09-05 at 15:13 -0700, Greg Kroah-Hartman wrote:
> > +MODULE_AUTHOR("Johannes Berg ");
> > +MODULE_DESCRIPTION("Device Coredump support");
> > +MODULE_LICENSE("GPL");
>
> As you only allow Y or N as build options, it's no
On Fri, 2014-09-05 at 11:40 +0200, Jonas Gorski wrote:
> On Fri, Sep 5, 2014 at 10:50 AM, Johannes Berg
> wrote:
> > From: Johannes Berg
>
> Can't you just send from the correct address? ;p
Not easily :)
> How about the following to avoid negative options
From: Johannes Berg
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware sta
On Wed, 2014-09-03 at 12:15 -0700, Greg Kroah-Hartman wrote:
> On Wed, Sep 03, 2014 at 09:00:42PM +0200, Johannes Berg wrote:
> > On Wed, 2014-09-03 at 09:38 -0500, Seth Forshee wrote:
> >
> > > Overall I think this looks pretty sensible. The thing that worries me
> &
On Wed, 2014-09-03 at 16:19 +0200, Daniel Vetter wrote:
> [super-embarrassing resend, the previous one contained html gunk.]
>
> If the idea is to also convert gpu crash dumps to this we should add
> dri-devel. And there the crashes are usually not due to firmware, but
> because the shaders and co
On Wed, 2014-09-03 at 09:38 -0500, Seth Forshee wrote:
> Overall I think this looks pretty sensible. The thing that worries me
> though is firmware which might crash repeatedly in a short period of
> time, resulting in a proliferation of coredumps and eating up all
> available RAM. How about a lim
From: Johannes Berg
Many devices run firmware, and as other software such firmware has
bugs. When it misbehaves, however, it is often much harder to debug
than software running on the host.
Introduce a "firmware coredump" mechanism to allow dumping internal
firmware state through a g
On Mon, 2014-09-01 at 08:33 -0400, Shakil A Khan wrote:
> On Monday 01 September 2014 08:07:38 Johannes Berg wrote:
> > > + u64 wdev_id = 0;
> >
> > it's not used uninitialized, NACK.
> >
> > johannes
> >
>
> wdev_id can be used uninitia
> + u64 wdev_id = 0;
it's not used uninitialized, NACK.
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 read the FAQ at http:/
On Mon, 2014-08-25 at 09:52 +0200, Rostislav Lisovy wrote:
> If I am not mistaken it is not possible to say that this feature may be
> useful as the general method for monitor-mode injection with datarate
> until there is some user-space utility really using/needing it?
Yes, this wasn't as much a
On Tue, 2014-08-19 at 15:41 +0300, Mika Westerberg wrote:
> This adds one more ACPI ID of a Broadcom bluetooth chip.
Applied, thanks.
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
On Sun, 2014-08-17 at 16:18 +0300, Andreea-Cristina Bernat wrote:
> The "rcu_dereference()" calls are used directly in conditions.
> Since their return values are never dereferenced it is recommended to
> use "rcu_access_pointer()" instead of "rcu_dereference()".
> Therefore, this patch makes the r
On Tue, 2014-08-26 at 11:17 +0200, Samuel Thibault wrote:
> - led_trigger_event(&vt_led_triggers[led], !!brightness);
> + vt_led_state[led] = !!brightness;
> + schedule_work(&vt_led_work[led]);
> +static int __init input_led_init(void)
> +{
> + unsigned i;
> +
> + for (i = 0;
On Fri, 2014-08-22 at 16:14 +0300, Andreea-Cristina Bernat wrote:
> The use of "rcu_assign_pointer()" is NULLing out the pointer.
> According to RCU_INIT_POINTER()'s block comment:
> "1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
> it is better to use it instead of rcu_assign_poin
On Tue, 2014-08-26 at 03:54 +0200, Samuel Thibault wrote:
> + vt_led_wq = alloc_workqueue("input_leds", WQ_UNBOUND, 0);
> + if (!vt_led_wq)
> + return -ENOMEM;
Does this really need a separate workqueue rather than just using
schedule_work()? There doesn't seem to be much poin
On Tue, 2014-08-19 at 06:39 +, Sharma, Sanjeev wrote:
> Ping for review the patch.
Make sure it compiles ...
--
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/majord
On Thu, 2014-07-24 at 14:43 +0200, Rostislav Lisovy wrote:
> Current code checks if at least 20MHz bandwidth is allowed for
> particular channel -- if it is not, the channel is disabled.
> This disables usage of 5/10 MHz channels.
> Another issue with the current code is that it may allow a channel
On Thu, 2014-07-10 at 15:25 +0200, Rostislav Lisovy wrote:
> const struct ieee80211_reg_rule *freq_reg_info(struct wiphy *wiphy,
> -u32 center_freq);
> +u32 center_freq,
> +
On Tue, 2014-07-22 at 14:43 -0700, Andrew Bresticker wrote:
> The dividend in do_div() is expected to be an unsigned 64-bit integer,
> which leads to the following warning when building for 32-bit MIPS:
>
> drivers/net/wireless/mac80211_hwsim.c: In function 'mac80211_hwsim_set_tsf':
> drivers/
On Mon, 2014-07-21 at 17:01 -0400, Steven Rostedt wrote:
> Cc'd my python gurus.
>
> Acks?
> > When trying to use the python library it was giving me an error about not
> > being
> > able to resolve tracecmd_stat_cpu. This is because we weren't linking
> > trace-record.o to ctracecmd.so. Fix t
On Mon, 2014-07-14 at 14:19 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Since "wireless-regdb: remove antenna gain" was merged in the
> wireless-regdb tree, the awk script parser has been incompatible
> with the 'official' regulatory database. This fixes that up.
> Without th
On Thu, 2014-07-10 at 14:27 +0200, Rostislav Lisovy wrote:
> Add support for parsing radiotap field IEEE80211_RADIOTAP_RATE
> for transmitted frames. Use the provided datarate value in
> info->control.rates[] array so it will be used for transmission.
>
> Signed-off-by: Rostislav Lisovy
> ---
> T
On Thu, 2014-07-10 at 10:17 +0200, Tom Gundersen wrote:
> Pass the value down and set it at the same place the name itself is set.
Is this going to be applied as part of one bigger series?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
On Thu, 2014-07-17 at 11:16 +0200, Tom Gundersen wrote:
> >> static struct wireless_dev *ath6kl_cfg80211_add_iface(struct wiphy *wiphy,
> >> const char *name,
> >> + unsigned char
> >> name_assi
On Thu, 2014-07-17 at 10:06 +0200, Tom Gundersen wrote:
> Pass the value down and set it at the same place the name itself is set.
Huh? What's this? Can you explain why?
> static struct wireless_dev *ath6kl_cfg80211_add_iface(struct wiphy *wiphy,
>
On Tue, 2014-06-24 at 09:27 +1000, Julian Calaby wrote:
> > - x = (T)pci_alloc_consistent(E1,E2,E3);
> > + x = pci_zalloc_consistent(E1,E2,E3);
> > if ((x==NULL) || ...) S
> > - memset((T2)x,0,E2);
>
> I don't know much about SmPL, but wouldn't having that if statement
> there reduce your match
On Mon, 2014-06-23 at 14:04 -0400, Steven Rostedt wrote:
> Ah! I see what you are saying. You are saying that once you are full
> you need to flush. Honestly, the trace_puts() should check the return.
> Perhaps it wants to try again with a shorter string?
Perhaps, but perhaps not? I don't remembe
On Mon, 2014-06-23 at 12:08 -0400, Steven Rostedt wrote:
> On Sun, 22 Jun 2014 09:38:05 +0200
> Johannes Berg wrote:
>
>
> > Looking at the code though, I'm not sure it's a pure optimisation - if
> > you do say putc() after a failed puts(), without this co
On Mon, 2014-06-23 at 12:04 +0200, Felix Fietkau wrote:
> On 2014-06-23 11:08, Johannes Berg wrote:
> > On Sun, 2014-06-22 at 13:41 +0200, Felix Fietkau wrote:
> >> On 2014-04-15 14:37, Rostislav Lisovy wrote:
> >> > Current code checks if the 20MHz bandwidth is
On Sun, 2014-06-22 at 13:41 +0200, Felix Fietkau wrote:
> On 2014-04-15 14:37, Rostislav Lisovy wrote:
> > Current code checks if the 20MHz bandwidth is allowed for
> > particular channel -- if it is not, the channel is disabled.
> > Since we need to use 5/10 MHz channels, this code is modified in
xplains the design is needed.
>
> Comment? What? Git blame isn't good enough for ya? ;-)
>
> >
> > Is this test really needed? trace_seq_putmem() will handle this.
>
> It was added as an optimization, because once it filled up, you could
> still have multiple cal
On Thu, 2014-06-12 at 16:09 +0200, Thomas Gleixner wrote:
> Fair enough. Still the timespec is silly. Here is an updated version.
Makes sense, thanks. I've applied this (mac80211-next)
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Thu, 2014-06-12 at 23:13 -0400, Steven Rostedt wrote:
> While doing my synchronization between trace-cmd and lib traceevent, I
> noticed that the mac80211 driver is quite different.
>
> Johannes, Jiri states that this plugin no longer works with the latest
> kernels. Is that true?
It's very w
801 - 900 of 1314 matches
Mail list logo
