re other problems with attaching binaries (although
I'd say we should fix them too) [1].
BR,
Jani.
[1] http://lkml.kernel.org/r/02a78907-933d-3f61-572e-28154b16b...@redhat.com
--
Jani Nikula, Intel Open Source Technology Center
I had the same conclusion for math:: directives pulling in latex
dependency [1]. Hopefully Markus can help here.
BR,
Jani.
[1] http://lkml.kernel.org/r/877f93qdd2@intel.com
--
Jani Nikula, Intel Open Source Technology Center
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
include/net/mac80211.h | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index a810dfcb83c2..e2dba93e374f 100644
--- a/include/net/mac80211.h
It's easier to manage the kernel-doc for the fields when they
documentation is next to the field.
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
The same treatment is sorely needed for struct ieee80211_ops also, but I
don't have the time... this would get rid of the rest of the wa
On Fri, 21 Oct 2016, Johannes Berg <johan...@sipsolutions.net> wrote:
> On Fri, 2016-10-21 at 15:57 +0300, Jani Nikula wrote:
>> Signed-off-by: Jani Nikula <jani.nik...@intel.com>
>> ---
>> include/net/mac80211.h | 21 +
>> 1 file
On Wed, 26 Oct 2016, Johannes Berg <johan...@sipsolutions.net> wrote:
> On Fri, 2016-10-21 at 15:57 +0300, Jani Nikula wrote:
>> It's easier to manage the kernel-doc for the fields when they
>> documentation is next to the field.
>
> Ok, actually, this doesn
' in self.options:
> +for f in _used_fns_this_file:
> +cmd += ['-nofunction', f]
> elif 'functions' in self.options:
> for f in str(self.options.get('functions')).split():
> cmd += ['-function', f]
> +_used_fns_this_file.append(f)
>
> for pattern in export_file_patterns:
> for f in glob.glob(env.config.kerneldoc_srctree + '/' + pattern):
--
Jani Nikula, Intel Open Source Technology Center
On Mon, 03 Apr 2017, Johannes Berg <johan...@sipsolutions.net> wrote:
> On Fri, 2017-03-31 at 15:54 +0300, Jani Nikula wrote:
>>
>> I'm sure the parameter name could be improved to capture what you
>> mean better; alas I don't have a suggestion.
>
> Yes, that's
