* Re: [RFC][PATCHES] iov_iter.c rewrite
From: Linus Torvalds @ 2014-12-08 22:23 UTC (permalink / raw)
To: Theodore Ts'o, Kirill A. Shutemov, Linus Torvalds, Al Viro,
Linux Kernel Mailing List, linux-fsdevel, Network Development
In-Reply-To: <20141208221401.GA4991@thunk.org>
On Mon, Dec 8, 2014 at 2:14 PM, Theodore Ts'o <tytso@mit.edu> wrote:
>
> running trinity as root should be quite safe in a VM. :-)
It's not so much the safety that I'd worry about, it's the "you can
legitimately just reboot it or cause kernel corruption as root". You
may not cause any problems outside of the VM, but any oopses inside
the VM might be due to trinity just doing bad things as root, rather
than kernel bugs..
Of course, it's probably hard to hit things like laoding random
modules etc, since even without signature requirements there are tons
of ELF sanity checks and other things. So it might be hard to actually
do those kinds of "corrupt kernel memory as root" things with trinity.
Linus
^ permalink raw reply
* Re: [bisected] xfrm: TCP connection initiating PMTU discovery stalls on v3.12+
From: Wolfgang Walter @ 2014-12-08 22:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Thomas Jarosch, Eric Dumazet, Herbert Xu,
Steffen Klassert
In-Reply-To: <1417785985.4322.1.camel@edumazet-glaptop2.roam.corp.google.com>
Am Freitag, 5. Dezember 2014, 05:26:25 schrieb Eric Dumazet:
> On Fri, 2014-12-05 at 13:09 +0100, Wolfgang Walter wrote:
> > Hello,
> >
> > as reverting this patch fixes this rather annoying problem: is it
> > dangerous to revert it as a workaround until the root cause is found?
>
> Unfortunately no, this patch fixes a serious issue.
>
> We need to find the root cause of your problem instead of trying to work
> around it.
>
I only wanted to use it as local workaround here.
I looked a bit at at code. I'm not familiar with the network code, though :-).
When exactly should the gso handling with esp tunnel mode happen?
esp_output_done() calls xfrm_output_resume() and no gso handling is done.
Would be to late anyway.
esp_output() does not handle gso.
xfrm4_mode_tunnel_output() does not do any gso handling as far as I can see.
xfrm_output() (from net/xfrm/xfrm_output) does but is it called with esp
tunnel mode?
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
^ permalink raw reply
* Re: [RFC][PATCHES] iov_iter.c rewrite
From: Theodore Ts'o @ 2014-12-08 22:14 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Linus Torvalds, Al Viro, Linux Kernel Mailing List, linux-fsdevel,
Network Development
In-Reply-To: <20141208192358.GB25867@node.dhcp.inet.fi>
On Mon, Dec 08, 2014 at 09:23:58PM +0200, Kirill A. Shutemov wrote:
> > I guess you're running it in a VM, but still.. Doing random system
> > calls as root sounds like a bad bad idea.
>
> I'm doing this for a long time and didn't see any problem bigger than qemu
> crash[1]. ;)
>
> [1] http://thread.gmane.org/gmane.comp.emulators.qemu/194845/
If you use something like this:
-drive file=root_fs.img,if=virtio,snapshot=on
running trinity as root should be quite safe in a VM. :-)
- Ted
^ permalink raw reply
* [PATCH net-next v5 3/3] bridge: remove mode BRIDGE_MODE_SWDEV
From: roopa @ 2014-12-08 22:04 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
linville, vyasevic
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch removes bridge mode swdev.
Users can use BRIDGE_FLAGS_SELF to indicate swdev offload
if needed.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
include/uapi/linux/if_bridge.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
index 05f0869..b03ee8f 100644
--- a/include/uapi/linux/if_bridge.h
+++ b/include/uapi/linux/if_bridge.h
@@ -105,7 +105,6 @@ struct __fdb_entry {
#define BRIDGE_MODE_VEB 0 /* Default loopback mode */
#define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
-#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
#define BRIDGE_MODE_UNDEF 0xFFFF /* mode undefined */
/* Bridge management nested attributes
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v5 2/3] rocker: remove swdev mode
From: roopa @ 2014-12-08 22:04 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
linville, vyasevic
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Remove use of 'swdev' mode in rocker. rocker dev offloads
can use the BRIDGE_FLAGS_SELF to indicate offload to hardware.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
net/core/rtnetlink.c | 10 ++++++++--
2 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
index fded127..a841f7a 100644
--- a/drivers/net/ethernet/rocker/rocker.c
+++ b/drivers/net/ethernet/rocker/rocker.c
@@ -3700,27 +3700,11 @@ static int rocker_port_bridge_setlink(struct net_device *dev,
{
struct rocker_port *rocker_port = netdev_priv(dev);
struct nlattr *protinfo;
- struct nlattr *afspec;
struct nlattr *attr;
- u16 mode;
int err;
protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg),
IFLA_PROTINFO);
- afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
-
- if (afspec) {
- attr = nla_find_nested(afspec, IFLA_BRIDGE_MODE);
- if (attr) {
- if (nla_len(attr) < sizeof(mode))
- return -EINVAL;
-
- mode = nla_get_u16(attr);
- if (mode != BRIDGE_MODE_SWDEV)
- return -EINVAL;
- }
- }
-
if (protinfo) {
attr = nla_find_nested(protinfo, IFLA_BRPORT_LEARNING);
if (attr) {
@@ -3755,7 +3739,7 @@ static int rocker_port_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
u32 filter_mask)
{
struct rocker_port *rocker_port = netdev_priv(dev);
- u16 mode = BRIDGE_MODE_SWDEV;
+ u16 mode = BRIDGE_MODE_UNDEF;
u32 mask = BR_LEARNING | BR_LEARNING_SYNC;
return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode,
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 61cb7e7..3863e3b 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2734,11 +2734,17 @@ int ndo_dflt_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
if (!br_afspec)
goto nla_put_failure;
- if (nla_put_u16(skb, IFLA_BRIDGE_FLAGS, BRIDGE_FLAGS_SELF) ||
- nla_put_u16(skb, IFLA_BRIDGE_MODE, mode)) {
+ if (nla_put_u16(skb, IFLA_BRIDGE_FLAGS, BRIDGE_FLAGS_SELF)) {
nla_nest_cancel(skb, br_afspec);
goto nla_put_failure;
}
+
+ if (mode != BRIDGE_MODE_UNDEF) {
+ if (nla_put_u16(skb, IFLA_BRIDGE_MODE, mode)) {
+ nla_nest_cancel(skb, br_afspec);
+ goto nla_put_failure;
+ }
+ }
nla_nest_end(skb, br_afspec);
protinfo = nla_nest_start(skb, IFLA_PROTINFO | NLA_F_NESTED);
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v5 1/3] bridge: new mode flag to indicate mode 'undefined'
From: roopa @ 2014-12-08 22:04 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
linville, vyasevic
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds mode BRIDGE_MODE_UNDEF for cases where mode is not needed.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
include/uapi/linux/if_bridge.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
index 296a556..05f0869 100644
--- a/include/uapi/linux/if_bridge.h
+++ b/include/uapi/linux/if_bridge.h
@@ -106,6 +106,7 @@ struct __fdb_entry {
#define BRIDGE_MODE_VEB 0 /* Default loopback mode */
#define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
+#define BRIDGE_MODE_UNDEF 0xFFFF /* mode undefined */
/* Bridge management nested attributes
* [IFLA_AF_SPEC] = {
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next v5 0/3] remove bridge mode BRIDGE_MODE_SWDEV
From: roopa @ 2014-12-08 22:04 UTC (permalink / raw)
To: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
linville, vyasevic
Cc: netdev, davem, shm, gospo, Roopa Prabhu
From: Roopa Prabhu <roopa@cumulusnetworks.com>
BRIDGE_MODE_SWDEV was introduced to indicate switchdev offloads
for bridging from user space (In other words to call into the hw switch
port driver directly). But user can use existing BRIDGE_FLAGS_SELF
to call into the hw switch port driver today. swdev mode is not required
anymore. So, this patch removes it.
v4 - v5
incorporate comments
- Define BRIDGE_MODE_UNDEF to handle cases where mode is not defined
- reverse the order of patches
- include patch comments in all patches
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Roopa Prabhu (3):
bridge: new mode flag to indicate mode 'undefined'
rocker: remove swdev mode
bridge: remove mode 'swdev'
drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
include/uapi/linux/if_bridge.h | 2 +-
net/core/rtnetlink.c | 10 ++++++++--
3 files changed, 10 insertions(+), 20 deletions(-)
--
1.7.10.4
^ permalink raw reply
* Re: [patch iproute2 1/6] iproute2: ipa: show switch id
From: Eric W. Biederman @ 2014-12-08 21:56 UTC (permalink / raw)
To: David Laight
Cc: Jiri Pirko, netdev@vger.kernel.org, davem@davemloft.net,
nhorman@tuxdriver.com, andy@greyhouse.net, tgraf@suug.ch,
dborkman@redhat.com, ogerlitz@mellanox.com, jesse@nicira.com,
pshelar@nicira.com, azhou@nicira.com, ben@decadent.org.uk,
stephen@networkplumber.org, jeffrey.t.kirsher@intel.com,
vyasevic@redhat.com, xiyou.wangcong@gmail.com,
john.r.fastabend@intel.com, edumazet@google.com,
"jhs\@mojatatu.com" <jhs@
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA0339B@AcuExch.aculab.com>
David Laight <David.Laight@ACULAB.COM> writes:
> From: Eric W. Biederman
>> Jiri Pirko <jiri@resnulli.us> writes:
>>
>> > Thu, Dec 04, 2014 at 09:06:14PM CET, ebiederm@xmission.com wrote:
>> >>ebiederm@xmission.com (Eric W. Biederman) writes:
>> >>
>> >>> Jiri Pirko <jiri@resnulli.us> writes:
>> >>>
>> >>>>>So this id needs to be globally unique?
>> >>>>
>> >>>> No. It is enough to be unique within a single system. It serves for no
>> >>>> more than to find out 2 ids are same or not, no other info value.
>> >>>>
>> >>>> So when the drivers uses sane ids (like mac for example, or in case of
>> >>>> rocker an id which is passed by qemu command line), the chances of
>> >>>> collision are very very close to none (never say never).
>> >>
>> >>Thinking about what you said a little more.
>> >>
>> >>Two different sources of persistent numbers picking numbers by
>> >>completely different algorithms can give you no assurance that you don't
>> >>produce conflicts.
>> >>
>> >>The switch id as desisgned can not work.
>> >>
>> >>There are expected to be between 2**36 to 2**40 devices in this world.
>> >>Your first switch id is a 64it number. At the very best by the birthday
>> >>pardox predicts there will be a conflict ever 2**32 devices or between
>> >>2**4 and 2**8 devices in the world with conflicts. If the ids are not
>> >>randomly distributed (which they won't be) things could easily be much
>> >>much worse.
>> >>
>> >>That is just good enough the code could get out there and run for years
>> >>before you have the nightmare of having to fix all of userspace. That
>> >>is a nightmare no one needs.
>> >>
>> >>So please remove this broken code, and this broken concept from the
>> >>kernel and go back to the drawing board.
>> >
>> > In that case the phys port id is broken in the same way. Let's rather
>> > think about how to avoid conflicts for both. Given the fact the
>> > conflicts should be avoided only on a single baremetal, that should be
>> > doable (for (bad) example using driver name mixed with driver created
>> > id).
>>
>> No. phys_port_id is not broken in the same way, and phys_port_id does
>> not have the same set of properties.
>>
>> phys_port_id's in practice all have an IEEE prefix that identifies the
>> manufacturer and a manufacture assigned serial number. Aka a mac
>> address or a EUID-64. What the mlx4 ethernet driver is doing retunring
>> a 64bit EUID-64 I don't know. If there are problems in the worst
>> case issues with phys_port_id are fixable by simple driver tweaks,
>> because fundamentally we are working with globally uniuqe identifiers.
>> Well globally unique baring manufacturing bugs in eeproms.
>
> Manufacturers have to generate unique MAC addresses - otherwise people complain.
> But can't be assumed to put different 'serial numbers' in other devices.
> If you look at USB memory sticks you are likely to find that the serial
> number in the (equivalent of the) ATA identify response isn't unique.
> So I doubt you can use the value to distinguish between devices.
When I said serial number I was talking about MAC addresses.
> You also get the situation where ethernet MAC addresses only have to be
> unique within a collision domain. Many old sun systems used a single MAC
> address - valid because they assumed/required that multiple interfaces
> be connected to different networks.
> So even MAC addresses aren't per-interface.
The old sun system issue does not apply to switches and switch like
devices.
There are common layer two protocls (Spanning Tree? LACP?) that require
each switch port to have a unique mac address. So people will complain
and software will break if there is not a mac address per port. So for
switches and things that strongly resemble switches assuming a unique
mac address per port is a reasonable assumption.
Eric
^ permalink raw reply
* Re: [ovs-discuss] kernel panic receiving flooded VXLAN traffic with OVS
From: Nicholas Bastin @ 2014-12-08 21:14 UTC (permalink / raw)
To: Jesse Gross; +Cc: discuss-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, netdev
In-Reply-To: <CAEP_g=86QKL_Oxxj0mo8CZs8+fyBZuYw2fQTMGow_bSJbk+8AQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 826 bytes --]
On Mon, Dec 8, 2014 at 7:33 AM, Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org> wrote:
> If you look at the implementation of GRO/TSO, I think you will see
> that it does in fact faithfully reconstruct the original message and
> path MTU discovery is preserved. On Linux systems, GRO is enabled by
> default for all workloads - including those that do not result in
> local termination such as bridging.
I will go back and test this again (it's been a while - we just run with
all offloads turned off by default now). When we were having problems with
this we would find segmented TCP flows getting reassembled along the path
and then output with the local egress MTU (which was considerably larger
than that at the end stations), resulting in performance-crushing IP
fragmentation later in the path.
--
Nick
[-- Attachment #1.2: Type: text/html, Size: 1302 bytes --]
[-- Attachment #2: Type: text/plain, Size: 141 bytes --]
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-08 21:11 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Ming Lei, Pavel Machek, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141208205721.GA14895@kroah.com>
[-- Attachment #1: Type: Text/Plain, Size: 2777 bytes --]
On Monday 08 December 2014 21:57:21 Greg Kroah-Hartman wrote:
> On Mon, Dec 08, 2014 at 05:47:30PM +0100, Pali Rohár wrote:
> > On Monday 08 December 2014 17:37:14 Greg Kroah-Hartman wrote:
> > > On Mon, Dec 08, 2014 at 11:18:18PM +0800, Ming Lei wrote:
> > > > On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár
> >
> > <pali.rohar@gmail.com> wrote:
> > > > > On Saturday 06 December 2014 13:49:54 Pavel Machek
wrote:
> > > > > /**
> > > > >
> > > > > + * request_firmware_prefer_user: - prefer usermode
> > > > > helper for loading firmware + * @firmware_p: pointer
> > > > > to firmware image
> > > > > + * @name: name of firmware file
> > > > > + * @device: device for which firmware is being loaded
> > > > > + *
> > > > > + * This function works pretty much like
> > > > > request_firmware(), but it prefer + * usermode helper.
> > > > > If usermode helper fails then it fallback to direct
> > > > > access. + * Usefull for dynamic or model specific
> > > > > firmware data. + **/
> > > > > +int request_firmware_prefer_user(const struct
> > > > > firmware **firmware_p, +
> > > > > const char *name, struct device *device) +{
> > > > > + int ret;
> > > > > + __module_get(THIS_MODULE);
> > > > > + ret = _request_firmware(firmware_p, name,
> > > > > device, + FW_OPT_UEVENT
> > > > > | FW_OPT_PREFER_USER); +
> > > > > module_put(THIS_MODULE); + return ret;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
> > > >
> > > > I'd like to introduce request_firmware_user() which only
> > > > requests firmware from user space, and this way is
> > > > simpler and more flexible since we have
> > > > request_firmware_direct() already.
> > >
> > > Why would a driver care about what program provides the
> > > firmware? It shouldn't at all, and we want to get rid of
> > > the userspace firmware loader, not encourage drivers to
> > > use it "exclusively" at all.
> >
> > Do not remove it! Without userspace firmware loader it is
> > impossible to load dynamic firmware files.
>
> You should not be loading "dynamic" firmware files with the
> firmware interface, as that's not a "firmware" file anymore,
> it's a "special binary file that my driver needs to be
> created and sent into the kernel."
>
> Use your own custom usermode helper for stuff like this, not
> the firmware interface. But use a binary sysfs file if you
> want, that seems to make sense for it...
>
> greg k-h
Nokia for this problem invented its own netlink interface into
wl1251 driver. But because it was specific for N900 device it was
rejected for inclusion into mainline kernel.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-08 21:08 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Marcel Holtmann, Ming Lei, Pavel Machek, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141208210018.GB14895@kroah.com>
[-- Attachment #1: Type: Text/Plain, Size: 2445 bytes --]
On Monday 08 December 2014 22:00:18 Greg Kroah-Hartman wrote:
> On Mon, Dec 08, 2014 at 08:15:18PM +0100, Pali Rohár wrote:
> > On Nokia N900 NVS data are generated on-the-fly from some
> > bytes from CAL (/dev/mtd1), from state of cellular network
> > and from some other regulation settings.
>
> When is this "generated"? At boot time? Or by the firmware
> loader program you have hooked into being called by the
> kernel at "load the firmware now please" call time?
>
When userspace system network daemon is started.
> > So I think that files stored in linux-firmware.git tree
> > (which are also installed into /lib/firmware/) should be
> > loaded with request_firmware function. Or not? Do you think
> > something else? What other developers think?
> >
> > I'm against kernel driver for CAL (/dev/mtd1) for more
> > reasons:
> >
> > 1) we have userspace open source code, but licensed under
> > GPLv3. And until kernel change license, we cannot include
> > it.
>
> You can change the license of your code if you want to, don't
> make this type of nonsense argument.
>
Code is not mine, so I cannot change license.
> > 2) NVS data are (probably) not in one place, plus they
> > depends on something other.
>
> What is "something other"? Where are they located? Why would
> the firmware interface know or care anything about this?
>
fcc bit and some other data retrieved from daemon which
communicating with cellular modem.
> > 3) If manufacture XYZ create new device with its own storage
> > format of calibration data this means that correct solution
> > for XYZ is also to implement new kernel fs driver for its
> > own format.
>
> Yes, as it is doing it's own custom thing, why overload an
> existing interface to do something it was never designed to
> do?
>
> > Do you really want to have in kernel all those drivers for
> > all different (proprietary) storage formats?
>
> Yes, we are not afraid of lots of different drivers. That is
> not even a valid argument, you know better than this :)
>
> > 4) It does not help us with existence of generic file
> > /lib/firmware/ti-connectivity/wl1251-nvs.bin which comes
> > from linux-firmware.git tree.
>
> Again, not an issue. If you don't want that file in the repo,
> ask for it to be removed, and it will be, just send a patch
> to do it.
>
> greg k-h
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Greg Kroah-Hartman @ 2014-12-08 21:00 UTC (permalink / raw)
To: Pali Rohár
Cc: Marcel Holtmann, Ming Lei, Pavel Machek, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201412082015.18501@pali>
On Mon, Dec 08, 2014 at 08:15:18PM +0100, Pali Rohár wrote:
> On Nokia N900 NVS data are generated on-the-fly from some bytes
> from CAL (/dev/mtd1), from state of cellular network and from
> some other regulation settings.
When is this "generated"? At boot time? Or by the firmware loader
program you have hooked into being called by the kernel at "load the
firmware now please" call time?
> So I think that files stored in linux-firmware.git tree (which
> are also installed into /lib/firmware/) should be loaded with
> request_firmware function. Or not? Do you think something else?
> What other developers think?
>
> I'm against kernel driver for CAL (/dev/mtd1) for more reasons:
>
> 1) we have userspace open source code, but licensed under GPLv3.
> And until kernel change license, we cannot include it.
You can change the license of your code if you want to, don't make this
type of nonsense argument.
> 2) NVS data are (probably) not in one place, plus they depends on
> something other.
What is "something other"? Where are they located? Why would the
firmware interface know or care anything about this?
> 3) If manufacture XYZ create new device with its own storage
> format of calibration data this means that correct solution for
> XYZ is also to implement new kernel fs driver for its own format.
Yes, as it is doing it's own custom thing, why overload an existing
interface to do something it was never designed to do?
> Do you really want to have in kernel all those drivers for all
> different (proprietary) storage formats?
Yes, we are not afraid of lots of different drivers. That is not even a
valid argument, you know better than this :)
> 4) It does not help us with existence of generic file
> /lib/firmware/ti-connectivity/wl1251-nvs.bin which comes from
> linux-firmware.git tree.
Again, not an issue. If you don't want that file in the repo, ask for
it to be removed, and it will be, just send a patch to do it.
greg k-h
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Greg Kroah-Hartman @ 2014-12-08 20:57 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Pavel Machek, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201412081747.30965@pali>
On Mon, Dec 08, 2014 at 05:47:30PM +0100, Pali Rohár wrote:
> On Monday 08 December 2014 17:37:14 Greg Kroah-Hartman wrote:
> > On Mon, Dec 08, 2014 at 11:18:18PM +0800, Ming Lei wrote:
> > > On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
> > > > On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
> > > > /**
> > > >
> > > > + * request_firmware_prefer_user: - prefer usermode helper
> > > > for loading firmware + * @firmware_p: pointer to firmware
> > > > image
> > > > + * @name: name of firmware file
> > > > + * @device: device for which firmware is being loaded
> > > > + *
> > > > + * This function works pretty much like
> > > > request_firmware(), but it prefer + * usermode helper. If
> > > > usermode helper fails then it fallback to direct access.
> > > > + * Usefull for dynamic or model specific firmware data.
> > > > + **/
> > > > +int request_firmware_prefer_user(const struct firmware
> > > > **firmware_p, + const char
> > > > *name, struct device *device) +{
> > > > + int ret;
> > > > + __module_get(THIS_MODULE);
> > > > + ret = _request_firmware(firmware_p, name, device,
> > > > + FW_OPT_UEVENT |
> > > > FW_OPT_PREFER_USER); + module_put(THIS_MODULE);
> > > > + return ret;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
> > >
> > > I'd like to introduce request_firmware_user() which only
> > > requests firmware from user space, and this way is simpler
> > > and more flexible since we have request_firmware_direct()
> > > already.
> >
> > Why would a driver care about what program provides the
> > firmware? It shouldn't at all, and we want to get rid of the
> > userspace firmware loader, not encourage drivers to use it
> > "exclusively" at all.
> >
>
> Do not remove it! Without userspace firmware loader it is
> impossible to load dynamic firmware files.
You should not be loading "dynamic" firmware files with the firmware
interface, as that's not a "firmware" file anymore, it's a "special
binary file that my driver needs to be created and sent into the
kernel."
Use your own custom usermode helper for stuff like this, not the
firmware interface. But use a binary sysfs file if you want, that seems
to make sense for it...
greg k-h
^ permalink raw reply
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Julian Anastasov @ 2014-12-08 20:40 UTC (permalink / raw)
To: Smart Weblications GmbH - Florian Wiessner
Cc: Steffen Klassert, netdev, LKML, stable, Simon Horman, lvs-devel
In-Reply-To: <54858948.2060007@smart-weblications.de>
Hello,
On Mon, 8 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
> Am 07.12.2014 19:27, schrieb Julian Anastasov:>
> >
> > I'm attaching a patch that avoids rerouting in
> > IPVS for LOCAL_IN. Please test it in your setup. My tests
> > were with NAT on today's net tree. I checked that it
> > compiles for 3.12.33. You can use the default snat_reroute=1.
> >
>
> I'm sorry to tell you that your patch does not fix the problem. The BUG happens
> as soon as the client sends PASV, the ftp server does not return "Entering
> Passive Mode":
Patch is to avoid the xfrm_selector_match crash,
may be caused when using local client (mail?).
For nf_ct_seqadj_set you have to use commit b25adce16064
("ipvs: correct usage/allocation of seqadj ext in ipvs").
I'll send it to you privately...
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* RE: AW: ixgbe: Regression, unsupported SFP+ modules on 10Gbit/s X520 NIC no longer work with allow_unsupported_sfp=1
From: Tantilov, Emil S @ 2014-12-08 20:16 UTC (permalink / raw)
To: Martin Bosner, netdev@vger.kernel.org
In-Reply-To: <loom.20141206T180736-199@post.gmane.org>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-
>owner@vger.kernel.org] On Behalf Of Martin Bosner
>Sent: Saturday, December 06, 2014 9:08 AM
>To: netdev@vger.kernel.org
>Subject: Re: AW: ixgbe: Regression, unsupported SFP+ modules
>on 10Gbit/s X520 NIC no longer work with
>allow_unsupported_sfp=1
>
>Jeff Kirsher <jeffrey.t.kirsher <at> intel.com> writes:
>
>>
>> We are currently working on the resolution to your issue.
>I have also
>> added your patch to my queue of ixgbe patches.
>>
>> Cheers,
>> Jeff
>>
>
>Any news on this?
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/drivers/net/ethernet/intel/ixgbe?id=345be204dcbb2cc7580a63bc377a185125a6f822
Thanks,
Emil
>
>
>
>--
>To unsubscribe from this list: send the line "unsubscribe
>netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-
>info.html
^ permalink raw reply
* [3.13.y-ckt stable] Patch "net/ping: handle protocol mismatching scenario" has been added to staging queue
From: Kamal Mostafa @ 2014-12-08 20:10 UTC (permalink / raw)
To: Jane Zhou
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, Yiwei Zhao,
Kamal Mostafa, kernel-team
This is a note to let you know that I have just added a patch titled
net/ping: handle protocol mismatching scenario
to the linux-3.13.y-queue branch of the 3.13.y-ckt extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
This patch is scheduled to be released in version 3.13.11-ckt13.
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.13.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Kamal
------
>From 5b59ecf35f846d7207881461a0a86736838d502e Mon Sep 17 00:00:00 2001
From: Jane Zhou <a17711@motorola.com>
Date: Mon, 24 Nov 2014 11:44:08 -0800
Subject: net/ping: handle protocol mismatching scenario
commit 91a0b603469069cdcce4d572b7525ffc9fd352a6 upstream.
ping_lookup() may return a wrong sock if sk_buff's and sock's protocols
dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's
sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong
sock will be returned.
the fix is to "continue" the searching, if no matching, return NULL.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Jane Zhou <a17711@motorola.com>
Signed-off-by: Yiwei Zhao <gbjc64@motorola.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
---
net/ipv4/ping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 3ef2919..8e0f65c 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -213,6 +213,8 @@ static struct sock *ping_lookup(struct net *net, struct sk_buff *skb, u16 ident)
&ipv6_hdr(skb)->daddr))
continue;
#endif
+ } else {
+ continue;
}
if (sk->sk_bound_dev_if && sk->sk_bound_dev_if != dif)
--
1.9.1
^ permalink raw reply related
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-08 19:56 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Dan Williams, Greg Kroah-Hartman, Ming Lei, Pavel Machek,
John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <508290C6-B3D7-4E07-BE5E-EF6BDE568E92@holtmann.org>
[-- Attachment #1: Type: Text/Plain, Size: 10243 bytes --]
On Monday 08 December 2014 20:46:07 Marcel Holtmann wrote:
> Hi Pali,
>
> >>>>>>>>>> On Saturday 06 December 2014 13:49:54 Pavel Machek
> >>>>>>>>>> wrote: /**
> >>>>>>>>>>
> >>>>>>>>>> + * request_firmware_prefer_user: - prefer usermode
> >>>>>>>>>> helper for loading firmware + * @firmware_p:
> >>>>>>>>>> pointer to firmware image
> >>>>>>>>>> + * @name: name of firmware file
> >>>>>>>>>> + * @device: device for which firmware is being
> >>>>>>>>>> loaded + *
> >>>>>>>>>> + * This function works pretty much like
> >>>>>>>>>> request_firmware(), but it prefer + * usermode
> >>>>>>>>>> helper. If usermode helper fails then it fallback
> >>>>>>>>>> to direct access. + * Usefull for dynamic or model
> >>>>>>>>>> specific firmware data. + **/
> >>>>>>>>>> +int request_firmware_prefer_user(const struct
> >>>>>>>>>> firmware **firmware_p, +
> >>>>>>>>>> const char *name, struct device *device) +{
> >>>>>>>>>> + int ret;
> >>>>>>>>>> + __module_get(THIS_MODULE);
> >>>>>>>>>> + ret = _request_firmware(firmware_p, name,
> >>>>>>>>>> device, +
> >>>>>>>>>> FW_OPT_UEVENT
> >>>>>>>>>>
> >>>>>>>>>> | FW_OPT_PREFER_USER); +
> >>>>>>>>>>
> >>>>>>>>>> module_put(THIS_MODULE); + return ret;
> >>>>>>>>>> +}
> >>>>>>>>>> +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
> >>>>>>>>>
> >>>>>>>>> I'd like to introduce request_firmware_user() which
> >>>>>>>>> only requests firmware from user space, and this
> >>>>>>>>> way is simpler and more flexible since we have
> >>>>>>>>> request_firmware_direct() already.
> >>>>>>>>
> >>>>>>>> Why would a driver care about what program provides
> >>>>>>>> the firmware? It shouldn't at all, and we want to
> >>>>>>>> get rid of the userspace firmware loader, not
> >>>>>>>> encourage drivers to use it "exclusively" at all.
> >>>>>>>
> >>>>>>> Do not remove it! Without userspace firmware loader it
> >>>>>>> is impossible to load dynamic firmware files.
> >>>>>>
> >>>>>> why is this dynamic in the first place. It does not
> >>>>>> sound like dynamic data to me at all. This is like the
> >>>>>> WiFi MAC address(es) or Bluetooth BD_ADDR. They are
> >>>>>> all static information. The only difference is that
> >>>>>> they are on the host accessibly filesystem or storage
> >>>>>> and not on the device itself.
> >>>>>>
> >>>>>> To be honest, for Bluetooth we solved this now. If the
> >>>>>> device is missing key information like the calibration
> >>>>>> data or BD_ADDR, then it comes up unconfigured. A
> >>>>>> userspace process can then go and load the right data
> >>>>>> into it and then the device becomes available as
> >>>>>> Bluetooth device.
> >>>>>>
> >>>>>> Trying to use request_firmware to load some random data
> >>>>>> and insist on going through userspace helper for that
> >>>>>> sounds crazy to me. Especially since we are trying
> >>>>>> hard to get away from the userspace loader. Forcing to
> >>>>>> keep it for new stuff sounds backwards to me.
> >>>>>>
> >>>>>> With the special Nokia partition in mind, why hasn't
> >>>>>> this been turned into a mountable filesystem or into a
> >>>>>> driver/subsystem that can access the data direct from
> >>>>>> the kernel. I advocated for this some time ago. Maybe
> >>>>>> there should be a special subsystem for access to
> >>>>>> these factory persistent information that drivers then
> >>>>>> just can access. I seem to remember that some systems
> >>>>>> provide these via ACPI. Why does the ARM platform has
> >>>>>> to be special here?
> >>>>>>
> >>>>>> And the problem of getting Ethernet and WiFi MAC
> >>>>>> address and Bluetooth BD_ADDR comes up many many
> >>>>>> times. Why not have something generic here. And don't
> >>>>>> tell me request_firmware is that generic solution ;)
> >>>>>>
> >>>>>> Regards
> >>>>>>
> >>>>>> Marcel
> >>>>>
> >>>>> Hi Marcel. I think you did not understand this problem.
> >>>>> This discussion is not about mac address. Please read
> >>>>> email thread again and if there are some unclear pars,
> >>>>> then ask. Thanks!
> >>>>
> >>>> I think that I pretty clearly understand the problem.
> >>>> Calibration data, MAC address, what is the difference?
> >>>> For me this is all the same. It is data that is specific
> >>>> to a device or type of devices and it is stored
> >>>> somewhere else. In most cases in some immutable
> >>>> memory/flash area.
> >>>
> >>> Those calibration data (in form of binary NVS firmware
> >>> file) needs to be sent to wl1251 chip. Mac address is not
> >>> needed at this step (and kernel generate some random if
> >>> is not provided).
> >>>
> >>> (Just to note wl1271 driver loads both MAC address and NVS
> >>> data via one firmware file which is prepared by userspace,
> >>> but this discussion is about wl1251...)
> >>>
> >>>> What you want is access to this data since the kernel
> >>>> driver needs it. Do I get this so far ;)
> >>>
> >>> Yes, we need to provide NVS data to kernel when kernel ask
> >>> for them.
> >>>
> >>>> So my take is that request_firmware is not the right way
> >>>> to get this data. Or more precisely make sure that this
> >>>> data is available to kernel drivers. And what I am seeing
> >>>> here is that instead of actually solving the bigger
> >>>> problem, we just hack around it with request_firmware.
> >>>> Now surprisingly the request_firmware loads files
> >>>> directly from the kernel and all the hacks do not work
> >>>> anymore.
> >>>>
> >>>> Regards
> >>>>
> >>>> Marcel
> >>>
> >>> Just read emails again...
> >>>
> >>> Our problem is:
> >>>
> >>> linux-firmware.git tree provides two binary firmware
> >>> files:
> >>>
> >>> ti-connectivity/wl1251-fw.bin
> >>> ti-connectivity/wl1251-nvs.bin
> >>>
> >>> First is firmware file, second NVS file with generic
> >>> calibration data. Kernel driver wl1251 now loads both
> >>> firmware files via request_firmware. Generic calibration
> >>> data are enough for wl1251 chip (it should work). But
> >>> devices have own calibration data stored somewhere else.
> >>>
> >>> On Nokia N900 NVS data are generated on-the-fly from some
> >>> bytes from CAL (/dev/mtd1), from state of cellular network
> >>> and from some other regulation settings.
> >>>
> >>> So I think that files stored in linux-firmware.git tree
> >>> (which are also installed into /lib/firmware/) should be
> >>> loaded with request_firmware function. Or not? Do you
> >>> think something else? What other developers think?
> >>>
> >>> I'm against kernel driver for CAL (/dev/mtd1) for more
> >>> reasons:
> >>>
> >>> 1) we have userspace open source code, but licensed under
> >>> GPLv3. And until kernel change license, we cannot include
> >>> it.
> >>>
> >>> 2) NVS data are (probably) not in one place, plus they
> >>> depends on something other.
> >>>
> >>> 3) If manufacture XYZ create new device with its own
> >>> storage format of calibration data this means that
> >>> correct solution for XYZ is also to implement new kernel
> >>> fs driver for its own format. Do you really want to have
> >>> in kernel all those drivers for all different
> >>> (proprietary) storage formats?
> >>>
> >>> 4) It does not help us with existence of generic file
> >>> /lib/firmware/ti-connectivity/wl1251-nvs.bin which comes
> >>> from linux-firmware.git tree.
> >>
> >> a) change driver to prefer a new "wl1251-nvs-n900.bin"
> >> file,
> >
> > Why to "*-n900.bin" ? wl1251 driver is used on other devices
> > too.
> >
> >> but fall back to "wl1251-nvs.bin" if the first one isn't
> >> present
> >>
> >> b) have a "wl1251-cal-nvs-update" service that, if
> >> wl1521-nvs-n900.bin is *not* present mounts the CAL MTD,
> >> reads the data, writes it out into wl1521-nvs-n900.bin, and
> >> the rmmod/modprobes the driver
> >
> > Quote:
> >> On Nokia N900 NVS data are generated on-the-fly from some
> >> bytes from CAL (/dev/mtd1), from state of cellular network
> >> and from some other regulation settings.
> >
> > This basically means to rewrite it every boot or everytime
> > when country was changed (for regulation settings). And Ii
> > really do not want to do that.
> >
> > And rmmod is not working on statically linked drivers into
> > zImage. So this is not solution.
>
> actually module removal is still considered a race condition.
> If re-loading a module is part of your solution, then you are
> already heading into the wrong direction.
>
No, I'm not doing it and I want to have driver still loaded.
> WiFi subsystem have a solution for handling regulatory
> enforcement. I don't know why would you try to invent that
> same via NVS files.
>
Both firmware and NVS files are sent to chip as blob data. And
they are sent every time when userspace ask to bring interface
up.
So looks like modprobing driver works without data. Kernel ask
for them once userspace want to use wifi network.
> >> and done? Stuff that's not N900 just wouldn't ship the
> >> update service and would proceed like none of this
> >> happened.
> >>
> >> Dan
> >
> > Again, what is wrong with userspace firmware helper? I think
> > that it fix this problem in a clean way without any hacks
> > (like CAL in kernel or creating new FS specially for
> > parsing NVS and so on) in kernel. And in userspace we can
> > implement program which generate NVS firmware data
> > on-the-fly and send them to kernel in compatible format of
> > ti-connectivity/wl1251-nvs.bin
>
> How do you run a userspace firmware helper if the root
> filesystem has not yet been mounted? How do you run userspace
> helper during resume?
>
I cannot do that.
> Honestly for drivers linked statically into the kernel, the
> best approach is that they stay unconfigured until userspace
> is available and can run a tool to provide the correct data.
>
> Regards
>
> Marcel
So ifconfig wlan0 should fail? In our case for wl1251 I think we
should fallback to generic NVS data if are available (and maybe
later when request will be there again, userspace can provide
data).
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-08 19:52 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Greg Kroah-Hartman, Ming Lei, Pavel Machek, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <9E6DD65F-8AF4-49C6-85EE-AA2BB4C6C39D@holtmann.org>
[-- Attachment #1: Type: Text/Plain, Size: 11342 bytes --]
On Monday 08 December 2014 20:41:13 Marcel Holtmann wrote:
> Hi Pali,
>
> >>>>>>>> On Saturday 06 December 2014 13:49:54 Pavel Machek
> >>>>>>>> wrote: /**
> >>>>>>>>
> >>>>>>>> + * request_firmware_prefer_user: - prefer usermode
> >>>>>>>> helper for loading firmware + * @firmware_p: pointer
> >>>>>>>> to firmware image
> >>>>>>>> + * @name: name of firmware file
> >>>>>>>> + * @device: device for which firmware is being
> >>>>>>>> loaded + *
> >>>>>>>> + * This function works pretty much like
> >>>>>>>> request_firmware(), but it prefer + * usermode
> >>>>>>>> helper. If usermode helper fails then it fallback to
> >>>>>>>> direct access. + * Usefull for dynamic or model
> >>>>>>>> specific firmware data. + **/
> >>>>>>>> +int request_firmware_prefer_user(const struct
> >>>>>>>> firmware **firmware_p, +
> >>>>>>>> const char *name, struct device *device) +{
> >>>>>>>> + int ret;
> >>>>>>>> + __module_get(THIS_MODULE);
> >>>>>>>> + ret = _request_firmware(firmware_p, name,
> >>>>>>>> device, + FW_OPT_UEVENT
> >>>>>>>>
> >>>>>>>> | FW_OPT_PREFER_USER); +
> >>>>>>>>
> >>>>>>>> module_put(THIS_MODULE); + return ret;
> >>>>>>>> +}
> >>>>>>>> +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
> >>>>>>>
> >>>>>>> I'd like to introduce request_firmware_user() which
> >>>>>>> only requests firmware from user space, and this way
> >>>>>>> is simpler and more flexible since we have
> >>>>>>> request_firmware_direct() already.
> >>>>>>
> >>>>>> Why would a driver care about what program provides the
> >>>>>> firmware? It shouldn't at all, and we want to get rid
> >>>>>> of the userspace firmware loader, not encourage
> >>>>>> drivers to use it "exclusively" at all.
> >>>>>
> >>>>> Do not remove it! Without userspace firmware loader it
> >>>>> is impossible to load dynamic firmware files.
> >>>>
> >>>> why is this dynamic in the first place. It does not sound
> >>>> like dynamic data to me at all. This is like the WiFi MAC
> >>>> address(es) or Bluetooth BD_ADDR. They are all static
> >>>> information. The only difference is that they are on the
> >>>> host accessibly filesystem or storage and not on the
> >>>> device itself.
> >>>>
> >>>> To be honest, for Bluetooth we solved this now. If the
> >>>> device is missing key information like the calibration
> >>>> data or BD_ADDR, then it comes up unconfigured. A
> >>>> userspace process can then go and load the right data
> >>>> into it and then the device becomes available as
> >>>> Bluetooth device.
> >>>>
> >>>> Trying to use request_firmware to load some random data
> >>>> and insist on going through userspace helper for that
> >>>> sounds crazy to me. Especially since we are trying hard
> >>>> to get away from the userspace loader. Forcing to keep
> >>>> it for new stuff sounds backwards to me.
> >>>>
> >>>> With the special Nokia partition in mind, why hasn't this
> >>>> been turned into a mountable filesystem or into a
> >>>> driver/subsystem that can access the data direct from the
> >>>> kernel. I advocated for this some time ago. Maybe there
> >>>> should be a special subsystem for access to these factory
> >>>> persistent information that drivers then just can access.
> >>>> I seem to remember that some systems provide these via
> >>>> ACPI. Why does the ARM platform has to be special here?
> >>>>
> >>>> And the problem of getting Ethernet and WiFi MAC address
> >>>> and Bluetooth BD_ADDR comes up many many times. Why not
> >>>> have something generic here. And don't tell me
> >>>> request_firmware is that generic solution ;)
> >>>>
> >>>> Regards
> >>>>
> >>>> Marcel
> >>>
> >>> Hi Marcel. I think you did not understand this problem.
> >>> This discussion is not about mac address. Please read
> >>> email thread again and if there are some unclear pars,
> >>> then ask. Thanks!
> >>
> >> I think that I pretty clearly understand the problem.
> >> Calibration data, MAC address, what is the difference? For
> >> me this is all the same. It is data that is specific to a
> >> device or type of devices and it is stored somewhere else.
> >> In most cases in some immutable memory/flash area.
> >
> > Those calibration data (in form of binary NVS firmware file)
> > needs to be sent to wl1251 chip. Mac address is not needed
> > at this step (and kernel generate some random if is not
> > provided).
>
> the MAC address is just an example or similar data. And to be
> clear the kernel generating some random address is not a good
> idea either. If you get a new random address on every boot
> that is total disaster. Because it sort of works does not
> mean it is the right way to do it. That is why I am including
> MAC address in the list here. It is same kind of data that is
> needed before a device can be declared fully functional.
>
> > (Just to note wl1271 driver loads both MAC address and NVS
> > data via one firmware file which is prepared by userspace,
> > but this discussion is about wl1251...)
>
> There is no difference between any drivers here. I do not know
> why are you trying to tie this to a specific driver. Why does
> it matter what kind of information these are. The point is
> they are not static, they are device specific and come from
> different sources. And the kernel driver needs them.
>
Right.
> >> What you want is access to this data since the kernel
> >> driver needs it. Do I get this so far ;)
> >
> > Yes, we need to provide NVS data to kernel when kernel ask
> > for them.
> >
> >> So my take is that request_firmware is not the right way to
> >> get this data. Or more precisely make sure that this data
> >> is available to kernel drivers. And what I am seeing here
> >> is that instead of actually solving the bigger problem, we
> >> just hack around it with request_firmware. Now
> >> surprisingly the request_firmware loads files directly
> >> from the kernel and all the hacks do not work anymore.
> >>
> >> Regards
> >>
> >> Marcel
> >
> > Just read emails again...
> >
> > Our problem is:
> >
> > linux-firmware.git tree provides two binary firmware files:
> >
> > ti-connectivity/wl1251-fw.bin
> > ti-connectivity/wl1251-nvs.bin
> >
> > First is firmware file, second NVS file with generic
> > calibration data. Kernel driver wl1251 now loads both
> > firmware files via request_firmware. Generic calibration
> > data are enough for wl1251 chip (it should work). But
> > devices have own calibration data stored somewhere else.
>
> Loading generic data that is static and stored on the
> filesystem via request_firmware is totally fine. If you have
> the NVS data in that file, then great. If you have specific
> data, then overwrite the file, link it to the real file or do
> something with it. As long as it is a file on the filesystem,
> you will be just fine.
>
I think that I should be able to rsync disk image of system and
then copy it into another device (of same type). So I do not want
to store device specific files into /lib/firmware/...
> If you however want to hook into some magic userspace helper
> to build the content of the file and somehow load it, then
> that sounds like the wrong approach to me.
>
If data depends on something from userspace (location of device
or type of sim card, etc, ...) then there is needed some
userspace program which prepare data. It cannot be automatically
done from kernel.
> > On Nokia N900 NVS data are generated on-the-fly from some
> > bytes from CAL (/dev/mtd1), from state of cellular network
> > and from some other regulation settings.
> >
> > So I think that files stored in linux-firmware.git tree
> > (which are also installed into /lib/firmware/) should be
> > loaded with request_firmware function. Or not? Do you think
> > something else? What other developers think?
> >
> > I'm against kernel driver for CAL (/dev/mtd1) for more
> > reasons:
> >
> > 1) we have userspace open source code, but licensed under
> > GPLv3. And until kernel change license, we cannot include
> > it.
> >
> > 2) NVS data are (probably) not in one place, plus they
> > depends on something other.
> >
> > 3) If manufacture XYZ create new device with its own storage
> > format of calibration data this means that correct solution
> > for XYZ is also to implement new kernel fs driver for its
> > own format. Do you really want to have in kernel all those
> > drivers for all different (proprietary) storage formats?
> >
> > 4) It does not help us with existence of generic file
> > /lib/firmware/ti-connectivity/wl1251-nvs.bin which comes
> > from linux-firmware.git tree.
>
> As I said before, I think that a driver should not register
> with its subsystem until it has all data that it needs. Or if
> it can tell the subsystem that it is missing data and the
> subsystem knows how to provide hooks for getting this data.
>
> We all know that many embedded devices need extra data to
> operation properly. This data is normally programmed onto the
> device in the factory. So if someone would now build a
> subsystem that can retrieve magic blobs of data from magic
> places like ACPI, devicetree, userspace or whatever that
> would help. I can see that request_firmware looks a lot like
> this. However the reality is that you have a race condition
> here. request_firmware relies on the fact that it is file in
> userspace. That is what it was designed for in the first
> place. Firmware files that are place on the hosts filesystem.
> It does not have the option to start a notifier when blob xyz
> becomes available. And that is what you essentially need for
> the drivers. The driver finds the hardware and goes, now I
> need blob xyz to function and then it sits and waits until it
> gets told that blob is now available. Then it initializes the
> hardware and registers it to the subsystem.
>
> I fully realize that request_firmware is pretty close in this
> regard, but the semantics and timing that many of these NVS
> data like addresses, our calibration information are
> different. It is more than just this specific drivers
> problem. There are many devices out there that have certain
> settings stored somewhere and it needs these based on how the
> device is build or how it is provisioning in the factory.
>
> What I would actually prefer to see that the driver just
> requests this blob of information and then a separate
> subsystem deals with getting it. As I said, in some cases the
> information might be in ACPI or devicetree or accessible by a
> special driver. In that case no userspace interaction would
> be needed at all. However the driver has to deal with the
> fact that the data blob might not be available for a certain
> period of time. If you mention cellular modem, then that one
> has to boot up first and get its data. More reason to
> actually design this cleanly so that there are no race
> conditions.
>
> Regards
>
> Marcel
Yes, this sounds good. Some subsystem which reads needed data (or
generate them or wait until something other provide them) sounds
good.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [RFC][PATCHES] iov_iter.c rewrite
From: Linus Torvalds @ 2014-12-08 19:48 UTC (permalink / raw)
To: Al Viro
Cc: Kirill A. Shutemov, Linux Kernel Mailing List, linux-fsdevel,
Network Development, linux-arch@vger.kernel.org
In-Reply-To: <20141208192816.GH22149@ZenIV.linux.org.uk>
On Mon, Dec 8, 2014 at 11:28 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On x86 it does, but I don't see anything obvious in generic version in
> mm/gup.c, so the old code might still have a problem on some architectures.
> What am I missing here?
Hmm. You may be right. The "access_ok()" is supposed to protect
things, but for cases like finit_module() that has explicitly said
"kernel addresses are ok", that check doesn't work.
Maybe something like this..
diff --git a/mm/gup.c b/mm/gup.c
index cd62c8c90d4a..6234b1e6ced9 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -951,6 +951,9 @@ int __get_user_pages_fast(unsigned long start,
int nr_pages, int write,
len = (unsigned long) nr_pages << PAGE_SHIFT;
end = start + len;
+ if (unlikely(segment_eq(get_fs(), KERNEL_DS)))
+ return 0;
+
if (unlikely(!access_ok(write ? VERIFY_WRITE : VERIFY_READ,
start, len)))
return 0;
Completely untested, obviously. That code isn't even compiled on x86.
Adding linux-arch for more comments.
(Background: the generic non-x86 "get_user_pages_fast()" function
cannot check that the page tables are actually *user* page tables,
so..)
Linus
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Marcel Holtmann @ 2014-12-08 19:46 UTC (permalink / raw)
To: Pali Rohár
Cc: Dan Williams, Greg Kroah-Hartman, Ming Lei, Pavel Machek,
John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201412082036.14609@pali>
Hi Pali,
>>>>>>>>>> On Saturday 06 December 2014 13:49:54 Pavel Machek
>>>>>>>>>> wrote: /**
>>>>>>>>>>
>>>>>>>>>> + * request_firmware_prefer_user: - prefer usermode
>>>>>>>>>> helper for loading firmware + * @firmware_p:
>>>>>>>>>> pointer to firmware image
>>>>>>>>>> + * @name: name of firmware file
>>>>>>>>>> + * @device: device for which firmware is being
>>>>>>>>>> loaded + *
>>>>>>>>>> + * This function works pretty much like
>>>>>>>>>> request_firmware(), but it prefer + * usermode
>>>>>>>>>> helper. If usermode helper fails then it fallback
>>>>>>>>>> to direct access. + * Usefull for dynamic or model
>>>>>>>>>> specific firmware data. + **/
>>>>>>>>>> +int request_firmware_prefer_user(const struct
>>>>>>>>>> firmware **firmware_p, +
>>>>>>>>>> const char *name, struct device *device) +{
>>>>>>>>>> + int ret;
>>>>>>>>>> + __module_get(THIS_MODULE);
>>>>>>>>>> + ret = _request_firmware(firmware_p, name,
>>>>>>>>>> device, +
>>>>>>>>>> FW_OPT_UEVENT
>>>>>>>>>>
>>>>>>>>>> | FW_OPT_PREFER_USER); +
>>>>>>>>>>
>>>>>>>>>> module_put(THIS_MODULE); + return ret;
>>>>>>>>>> +}
>>>>>>>>>> +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
>>>>>>>>>
>>>>>>>>> I'd like to introduce request_firmware_user() which
>>>>>>>>> only requests firmware from user space, and this
>>>>>>>>> way is simpler and more flexible since we have
>>>>>>>>> request_firmware_direct() already.
>>>>>>>>
>>>>>>>> Why would a driver care about what program provides
>>>>>>>> the firmware? It shouldn't at all, and we want to
>>>>>>>> get rid of the userspace firmware loader, not
>>>>>>>> encourage drivers to use it "exclusively" at all.
>>>>>>>
>>>>>>> Do not remove it! Without userspace firmware loader it
>>>>>>> is impossible to load dynamic firmware files.
>>>>>>
>>>>>> why is this dynamic in the first place. It does not
>>>>>> sound like dynamic data to me at all. This is like the
>>>>>> WiFi MAC address(es) or Bluetooth BD_ADDR. They are
>>>>>> all static information. The only difference is that
>>>>>> they are on the host accessibly filesystem or storage
>>>>>> and not on the device itself.
>>>>>>
>>>>>> To be honest, for Bluetooth we solved this now. If the
>>>>>> device is missing key information like the calibration
>>>>>> data or BD_ADDR, then it comes up unconfigured. A
>>>>>> userspace process can then go and load the right data
>>>>>> into it and then the device becomes available as
>>>>>> Bluetooth device.
>>>>>>
>>>>>> Trying to use request_firmware to load some random data
>>>>>> and insist on going through userspace helper for that
>>>>>> sounds crazy to me. Especially since we are trying
>>>>>> hard to get away from the userspace loader. Forcing to
>>>>>> keep it for new stuff sounds backwards to me.
>>>>>>
>>>>>> With the special Nokia partition in mind, why hasn't
>>>>>> this been turned into a mountable filesystem or into a
>>>>>> driver/subsystem that can access the data direct from
>>>>>> the kernel. I advocated for this some time ago. Maybe
>>>>>> there should be a special subsystem for access to
>>>>>> these factory persistent information that drivers then
>>>>>> just can access. I seem to remember that some systems
>>>>>> provide these via ACPI. Why does the ARM platform has
>>>>>> to be special here?
>>>>>>
>>>>>> And the problem of getting Ethernet and WiFi MAC
>>>>>> address and Bluetooth BD_ADDR comes up many many
>>>>>> times. Why not have something generic here. And don't
>>>>>> tell me request_firmware is that generic solution ;)
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Marcel
>>>>>
>>>>> Hi Marcel. I think you did not understand this problem.
>>>>> This discussion is not about mac address. Please read
>>>>> email thread again and if there are some unclear pars,
>>>>> then ask. Thanks!
>>>>
>>>> I think that I pretty clearly understand the problem.
>>>> Calibration data, MAC address, what is the difference? For
>>>> me this is all the same. It is data that is specific to a
>>>> device or type of devices and it is stored somewhere
>>>> else. In most cases in some immutable memory/flash area.
>>>
>>> Those calibration data (in form of binary NVS firmware file)
>>> needs to be sent to wl1251 chip. Mac address is not needed
>>> at this step (and kernel generate some random if is not
>>> provided).
>>>
>>> (Just to note wl1271 driver loads both MAC address and NVS
>>> data via one firmware file which is prepared by userspace,
>>> but this discussion is about wl1251...)
>>>
>>>> What you want is access to this data since the kernel
>>>> driver needs it. Do I get this so far ;)
>>>
>>> Yes, we need to provide NVS data to kernel when kernel ask
>>> for them.
>>>
>>>> So my take is that request_firmware is not the right way
>>>> to get this data. Or more precisely make sure that this
>>>> data is available to kernel drivers. And what I am seeing
>>>> here is that instead of actually solving the bigger
>>>> problem, we just hack around it with request_firmware.
>>>> Now surprisingly the request_firmware loads files
>>>> directly from the kernel and all the hacks do not work
>>>> anymore.
>>>>
>>>> Regards
>>>>
>>>> Marcel
>>>
>>> Just read emails again...
>>>
>>> Our problem is:
>>>
>>> linux-firmware.git tree provides two binary firmware files:
>>>
>>> ti-connectivity/wl1251-fw.bin
>>> ti-connectivity/wl1251-nvs.bin
>>>
>>> First is firmware file, second NVS file with generic
>>> calibration data. Kernel driver wl1251 now loads both
>>> firmware files via request_firmware. Generic calibration
>>> data are enough for wl1251 chip (it should work). But
>>> devices have own calibration data stored somewhere else.
>>>
>>> On Nokia N900 NVS data are generated on-the-fly from some
>>> bytes from CAL (/dev/mtd1), from state of cellular network
>>> and from some other regulation settings.
>>>
>>> So I think that files stored in linux-firmware.git tree
>>> (which are also installed into /lib/firmware/) should be
>>> loaded with request_firmware function. Or not? Do you think
>>> something else? What other developers think?
>>>
>>> I'm against kernel driver for CAL (/dev/mtd1) for more
>>> reasons:
>>>
>>> 1) we have userspace open source code, but licensed under
>>> GPLv3. And until kernel change license, we cannot include
>>> it.
>>>
>>> 2) NVS data are (probably) not in one place, plus they
>>> depends on something other.
>>>
>>> 3) If manufacture XYZ create new device with its own storage
>>> format of calibration data this means that correct solution
>>> for XYZ is also to implement new kernel fs driver for its
>>> own format. Do you really want to have in kernel all those
>>> drivers for all different (proprietary) storage formats?
>>>
>>> 4) It does not help us with existence of generic file
>>> /lib/firmware/ti-connectivity/wl1251-nvs.bin which comes
>>> from linux-firmware.git tree.
>>
>> a) change driver to prefer a new "wl1251-nvs-n900.bin" file,
>
> Why to "*-n900.bin" ? wl1251 driver is used on other devices too.
>
>> but fall back to "wl1251-nvs.bin" if the first one isn't
>> present
>
>> b) have a "wl1251-cal-nvs-update" service that, if
>> wl1521-nvs-n900.bin is *not* present mounts the CAL MTD,
>> reads the data, writes it out into wl1521-nvs-n900.bin, and
>> the rmmod/modprobes the driver
>>
>
> Quote:
>> On Nokia N900 NVS data are generated on-the-fly from some bytes
>> from CAL (/dev/mtd1), from state of cellular network and from
>> some other regulation settings.
>
> This basically means to rewrite it every boot or everytime when
> country was changed (for regulation settings). And Ii really do
> not want to do that.
>
> And rmmod is not working on statically linked drivers into
> zImage. So this is not solution.
actually module removal is still considered a race condition. If re-loading a module is part of your solution, then you are already heading into the wrong direction.
WiFi subsystem have a solution for handling regulatory enforcement. I don't know why would you try to invent that same via NVS files.
>
>> and done? Stuff that's not N900 just wouldn't ship the update
>> service and would proceed like none of this happened.
>>
>> Dan
>
> Again, what is wrong with userspace firmware helper? I think that
> it fix this problem in a clean way without any hacks (like CAL in
> kernel or creating new FS specially for parsing NVS and so on) in
> kernel. And in userspace we can implement program which generate
> NVS firmware data on-the-fly and send them to kernel in
> compatible format of ti-connectivity/wl1251-nvs.bin
How do you run a userspace firmware helper if the root filesystem has not yet been mounted? How do you run userspace helper during resume?
Honestly for drivers linked statically into the kernel, the best approach is that they stay unconfigured until userspace is available and can run a tool to provide the correct data.
Regards
Marcel
^ permalink raw reply
* pull request: wireless-next 2014-12-08
From: John W. Linville @ 2014-12-08 19:32 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
[-- Attachment #1: Type: text/plain, Size: 58561 bytes --]
Dave,
Please pull this last batch of pending wireless updates for the 3.19 tree...
For the wireless bits, Johannes says:
"This time I have Felix's no-status rate control work, which will allow
drivers to work better with rate control even if they don't have perfect
status reporting. In addition to this, a small hwsim fix from Patrik,
one of the regulatory patches from Arik, and a number of cleanups and
fixes I did myself.
Of note is a patch where I disable CFG80211_WEXT so that compatibility
is no longer selectable - this is intended as a wake-up call for anyone
who's still using it, and is still easily worked around (it's a one-line
patch) before we fully remove the code as well in the future."
For the Bluetooth bits, Johan says:
"Here's one more bluetooth-next pull request for 3.19:
- Minor cleanups for ieee802154 & mac802154
- Fix for the kernel warning with !TASK_RUNNING reported by Kirill A.
Shutemov
- Support for another ath3k device
- Fix for tracking link key based security level
- Device tree bindings for btmrvl + a state update fix
- Fix for wrong ACL flags on LE links"
And...
"In addition to the previous one this contains two more cleanups to
mac802154 as well as support for some new HCI features from the
Bluetooth 4.2 specification.
From the original request:
'Here's what should be the last bluetooth-next pull request for 3.19.
It's rather large but the majority of it is the Low Energy Secure
Connections feature that's part of the Bluetooth 4.2 specification. The
specification went public only this week so we couldn't publish the
corresponding code before that. The code itself can nevertheless be
considered fairly mature as it's been in development for over 6 months
and gone through several interoperability test events.
Besides LE SC the pull request contains an important fix for command
complete events for mgmt sockets which also fixes some leaks of hci_conn
objects when powering off or unplugging Bluetooth adapters.
A smaller feature that's part of the pull request is service discovery
support. This is like normal device discovery except that devices not
matching specific UUIDs or strong enough RSSI are filtered out.
Other changes that the pull request contains are firmware dump support
to the btmrvl driver, firmware download support for Broadcom BCM20702A0
variants, as well as some coding style cleanups in 6lowpan &
ieee802154/mac802154 code.'"
For the NFC bits, Samuel says:
"With this one we get:
- NFC digital improvements for DEP support: Chaining, NACK and ATN
support added.
- NCI improvements: Support for p2p target, SE IO operand addition,
SE operands extensions to support proprietary implementations, and
a few fixes.
- NFC HCI improvements: OPEN_PIPE and NOTIFY_ALL_CLEARED support,
and SE IO operand addition.
- A bunch of minor improvements and fixes for STMicro st21nfcb and
st21nfca"
For the iwlwifi bits, Emmanuel says:
"Major works are CSA and TDLS. On top of that I have a new
firmware API for scan and a few rate control improvements.
Johannes find a few tricks to improve our CPU utilization
and adds support for a new spin of 7265 called 7265D.
Along with this a few random things that don't stand out."
And...
"I deprecate here -8.ucode since -9 has been published long ago.
Along with that I have a new activity, we have now better
a infrastructure for firmware debugging. This will allow to
have configurable probes insides the firmware.
Luca continues his work on NetDetect, this feature is now
complete. All the rest is minor fixes here and there."
For the Atheros bits, Kalle says:
"Only ath10k changes this time and no major changes. Most visible are:
o new debugfs interface for runtime firmware debugging (Yanbo)
o fix shared WEP (Sujith)
o don't rebuild whenever kernel version changes (Johannes)
o lots of refactoring to make it easier to add new hw support (Michal)
There's also smaller fixes and improvements with no point of listing
here."
In addition, there are a few last minute updates to ath5k,
ath9k, brcmfmac, brcmsmac, mwifiex, rt2x00, rtlwifi, and wil6210.
Also included is a pull of the wireless tree to pick-up the fixes
originally included in "pull request: wireless 2014-12-03"...
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 7d63a5f9b25ba6b130da8eb2d32a72b1462d0249:
rtlwifi: Change order in device startup (2014-11-25 14:22:22 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git tags/master-2014-12-08
for you to fetch changes up to 81c412600f946fc1c8731685cb6c6fae8002043a:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless (2014-12-08 13:58:58 -0500)
----------------------------------------------------------------
Amitkumar Karwar (9):
Bluetooth: btmrvl: add DT bindings documentation
Bluetooth: btmrvl: add DT-bindings for gpio-gap
Bluetooth: btmrvl: update hs_state in interrupt handler
mwifiex: fix sparse warning
mwifiex: fix scan problem on big endian platforms
mwifiex: skip delay main work logic for USB interface.
mwifiex: add Tx status support for EAPOL packets
mwifiex: add Tx status support for ACTION frames
Bluetooth: btmrvl: remove extra newline character
Andreas Ruprecht (2):
net: wireless: rtlwifi: Do not always include drivers in obj-m
net: wireless: rtlwifi: rtl8192ee: Fix compilation of the driver
Andrei Otcheretianski (2):
iwlwifi: mvm: Insert DS Parameter Set placeholder in probes
iwlwifi: mvm: Handle failed beacon transmissions during CSA
Andrey Skvortsov (1):
SSB / B44: fix WOL for BCM4401
Arend van Spriel (4):
brcmfmac: fix static checker warning in pmklist handling
brcmfmac: correct .disconnect() callback while connecting
brcmutil: add helper function to format board revision
brcmsmac: extend hardware info shown in debugfs
Arik Nemtsov (11):
iwlwifi: mvm: expose some static APIs for use by TDLS code
iwlwifi: pcie: support loading FW with extended mem range
iwlwifi: mvm: declare TDLS support
iwlwifi: mvm: add TDLS channel switch FW APIs
iwlwifi: mvm: configure TDLS peers to FW
iwlwifi: mvm: allow private per-STA TFD queues
iwlwifi: mvm: disconnect TDLS peers on reconfig
iwlwifi: mvm: use private TFD queues for TDLS stations
iwlwifi: mvm: implement mac80211 TDLS channel-switch APIs
iwlwifi: mvm: disconnect TDLS peers before channel switch
cfg80211: leave invalid channels on regdomain change
Avinash Patil (4):
mwifiex: do not delete station entries in del_sta handler
mwifiex: delete peer station's RA list upon deauthentication
mwifiex: guard station nodes access by station list lock
mwifiex: do not process broadcast mac address for del_sta
Avri Altman (2):
iwlwifi: mvm: New skip over dtim policy
iwlwifi: mvm: Fix the keep_alive calculation
Axel Lin (1):
NFC: llcp: Use list_for_each_entry in llcp_accept_poll
Ben Greear (3):
ath10k: add ATH10K_DBG_WMI_PRINT debug level
ath10k: apply chainmask settings to vdev on creation
ath10k: use configured nss instead of max nss
Chaya Rachel Ivgy (1):
iwlwifi: mvm: add support to MFUART loading notification
Christophe Ricard (25):
NFC: st21nfca: Add of_st21nfca_i2c_match to MODULE_DEVICE_TABLE
NFC: st21nfca: Remove gpio_irq field in static and dts configuration
NFC: st21nfcb: Add of_st21nfcb_i2c_match to MODULE_DEVICE_TABLE
NFC: st21nfcb: Remove gpio_irq field in static and dts configuration
NFC: hci: Add se_io HCI operand
NFC: nci: Fix sparse: symbol 'nci_get_prop_rf_protocol' was not declared.
NFC: nci: Update nci_discover_se to run proprietary commands to discover all available secure element
NFC: nci: Update nci_enable_se to run proprietary commands to enable a secure element
NFC: nci: Update nci_disable_se to run proprietary commands to disable a secure element
NFC: nci: Add se_io NCI operand
NFC: st21nfca: Rework st21nfca_hci_event_received to route event to relevent gate.
NFC: st21nfcb: Improve ndlc comment
NFC: hci: Add open pipe command handler
NFC: hci: Add support for NOTIFY_ALL_PIPE_CLEARED
NFC: st21nfcb: Remove useless pr_info
NFC: nci: Add status byte management in case of error.
NFC: nci: Add management for NCI state for machine rf_deactivate_ntf
NFC: nci: Add support for different NCI_DEACTIVATE_TYPE
NFC: netlink: Add new netlink command NFC_CMD_ACTIVATE_TARGET
NFC: Add se_io NFC operand
NFC: hci: Add specific hci macro to not create a pipe
NFC: st21nfca: Report error returned by functions instead of -ENODEV
NFC: st21nfcb: Fix reported error
NFC: Fix warning "warning: incorrect type in assignment"
NFC: nci: Fix warning: cast to restricted __le16
Dan Carpenter (1):
brcmsmac: NULL dereferences in brcms_c_detach_mfree()
David Spinadel (4):
iwlwifi: mvm: implement UMAC scan API
iwlwifi: mvm: go to umac scan even if lmac tlv bit is on
iwlwifi: mvm: remove warning on unknown scan complete
iwlwifi: mvm: remove a dangling line of documentation
Dmitry Tunin (1):
Bluetooth: ath3k: Add support of MCI 13d3:3408 bt device
Eliad Peller (9):
iwlwifi: mvm/trans: abort d0i3_enter in case of held ref
iwlwifi: mvm: wake up d0i3_exit_waitq when aborting d0i3
iwlwifi: mvm: move deferred d0i3 exit to resume_complete op
iwlwifi: mvm: disable beacon filtering escape timer
iwlwifi: trans: add suspend/resume ops
iwlwifi: mvm: call iwl_trans_suspend/resume
iwlwifi: declare d0i3 support for IWL_DEVICE_8000
iwlwifi: mvm: add missing mvm ref debug print
iwlwifi: pcie: refactor cmd_in_flight set/clear code
Emmanuel Grumbach (19):
iwlwfifi: fix WANT_DEV_COREDUMP selection in Kconfig
iwlwifi: mvm: rs - don't use the shared antenna when BT load is high
iwlwifi: pcie: introduce delay when waking up the device
iwlwifi: pcie: newer platform needs a OS alive indication
Merge remote-tracking branch 'wireless-next/master' into iwlwifi-next
iwlwifi: mvm: add support for WMM Access Control
iwlwifi: mvm: BT Coex - add support for TTC / RRC
iwlwifi: pcie: properly reset the device
iwlwifi: update the secure mem space and for the CPUs
Merge remote-tracking branch 'iwlwifi-fixes/master' into iwlwifi-next
iwlwifi: deprecate -8.ucode for 3160 / 7260 / 7265
iwlwifi: mvm: remove IWL_UCODE_TLV_CAPA_EXTENDED_BEACON
iwlwifi: mvm: remove IWL_UCODE_TLV_API_WOWLAN_CONFIG_TID
iwlwifi: mvm: remove IWL_UCODE_TLV_API_CSA_FLOW
iwlwifi: mvm: BT Coex - change the MPLUT registers' value
iwlwifi: don't load on 7265D with old NVM
iwlwifi: pcie: claim ownership on the device after stop_device()
iwlwifi: dvm: fix flush support for old firmware
iwlwifi: mvm: update values for Smart Fifo
Eran Harary (3):
iwlwifi: change max HT and VHT A-MPDU exponent
iwlwifi: mvm: support ucode load for family_8000 B0 only
iwlwifi: mvm: Ability to work with packed usniffer image
Eyal Shapira (5):
iwlwifi: mvm: handle error from iwl_trans_update_sf
iwlwifi: mvm: rs: fix a WARNING in case of STBC and VHT
iwlwifi: mvm: rs: fix getting stuck in a test window
iwlwifi: mvm: rs: consider a missing BA as a single tx failure
iwlwifi: mvm: declare support for VHT BF info in radiotap
Felix Fietkau (15):
mac80211: copy chandef from AP vif to VLANs
mac80211: add more missing checks for VHT tx rates
mac80211: minstrel_ht: move aggregation check to .get_rate()
mac80211: add tx_status_noskb to rate_control_ops
mac80211: minstrel: switch to .tx_status_noskb
mac80211: minstrel_ht: switch to .tx_status_noskb
mac80211: pass tx info to ieee80211_lost_packet instead of an skb
mac0211: add a helper function for fixing up tx status rates
mac80211: add ieee80211_tx_status_noskb
ath9k_hw: fix hardware queue allocation
ath9k: fix BE/BK queue order
ath5k: fix hardware queue index assignment
ath9k: prevent early IRQs from accessing hardware
ath9k: set ATH_OP_INVALID before disabling hardware
ath9k: do not access hardware on IRQs during reset
Franky Lin (1):
brcmfmac: switch to single message MSI
Hante Meuleman (6):
brcmfmac: Fix bitmap malloc bug in msgbuf.
brcmfmac: Fix ifidx for rx data by msgbuf.
brcmfmac: Add PCIE ids for 43602 devices.
brcmfmac: Fix vendor cmds used interface.
brcmfmac: Add ifidx to logging of fwil cmds.
brcmfmac: add multiple BSS support.
Heinrich Siebmanns (1):
Bluetooth: Add support for Broadcom BCM20702A0 variants firmware download
Idan Kahlon (1):
iwlwifi: mvm: support NVM file with header
Jakub Pawlowski (4):
Bluetooth: Add definitions for MGMT_OP_START_SERVICE_DISCOVERY
Bluetooth: Add extra discovery fields for storing filter information
Bluetooth: Add logic for UUID filter handling
Bluetooth: Add support for Start Service Discovery command
Johan Hedberg (65):
Bluetooth: Fix setting state back to TASK_RUNNING
Bluetooth: Fix setting conn->pending_sec_level value from link key
Bluetooth: Convert link keys list to use RCU
Bluetooth: Track both local and remote L2CAP fixed channel mask
Bluetooth: Simplify Link Key Notification event handling logic
Bluetooth: Add basic SMP defines for LE Secure Connections
Bluetooth: Make auth_req mask dependent on SC enabled or not
Bluetooth: Add SMP flag for SC and set it when necessary.
Bluetooth: Update SMP security level to/from auth_req for SC
Bluetooth: Add mgmt support for LE Secure Connections LTK types
Bluetooth: Set the correct security level for SC LTKs
Bluetooth: Use custom macro for testing BR/EDR SC enabled
Bluetooth: Add mgmt_set_secure_conn support for any LE adapter
Bluetooth: Update LTK lookup to correctly deal with SC LTKs
Bluetooth: Remove unused hci_find_ltk function
Bluetooth: Rename hci_find_ltk_by_addr to hci_find_ltk
Bluetooth: Set link key generation bit if necessary for LE SC
Bluetooth: Add basic support for AES-CMAC
Bluetooth: Add ECC library for LE Secure Connections
Bluetooth: Add basic support for sending our LE SC public key
Bluetooth: Add handler function for receiving LE SC public key
Bluetooth: Add support for sending LE SC Confirm value
Bluetooth: Add LE SC support for responding to Pairing Confirm PDU
Bluetooth: Add support for LE SC numeric comparison
Bluetooth: Add support for handling LE SC user response
Bluetooth: Add support for LE SC DHKey check PDU
Bluetooth: Add support for LE SC key generation
Bluetooth: Track authentication method in SMP context
Bluetooth: Add selection of the SC authentication method
Bluetooth: Detect SMP SC debug keys
Bluetooth: Add check for accidentally generating a debug key
Bluetooth: Set correct LTK type and authentication for SC
Bluetooth: Add support for SC just-works pairing
Bluetooth: Fix BR/EDR Link Key type when derived through LE SC
Bluetooth: Add passkey entry support for LE SC
Bluetooth: Fix DHKey Check sending order for slave role
Bluetooth: Add dummy handler for LE SC keypress notification
Bluetooth: Use debug keys for SMP when HCI_USE_DEBUG_KEYS is set
Bluetooth: Add hci_conn flag for new link key generation
Bluetooth: Add debugfs switch for forcing SMP over BR/EDR
Bluetooth: Add skeleton for BR/EDR SMP channel
Bluetooth: Add full SMP BR/EDR support
Bluetooth: Add SC-only mode support for SMP
Bluetooth: Unify remote OOB data functions
Bluetooth: Store address type with OOB data
Bluetooth: Add support for adding remote OOB data for LE
Bluetooth: Set SMP OOB flag if OOB data is available
Bluetooth: Add basic LE SC OOB support for remote OOB data
Bluetooth: Introduce SMP_DBG macro for low-level debuging
Bluetooth: Fix missing const declarations in SMP functions
Bluetooth: Organize SMP crypto functions to logical sections
Bluetooth: Fix SMP debug key handling
Bluetooth: Fix minor coding style issue in smp.c
Bluetooth: Fix false-positive "uninitialized" compiler warning
Bluetooth: Add callback to create proper cmd_complete events
Bluetooth: Store parameter length with pending mgmt commands
Bluetooth: Convert Disconnect mgmt command to use cmd_complete callback
Bluetooth: Use cmd_complete callback for authentication mgmt commands
Bluetooth: Convert Pair Device to use cmd_complete callback
Bluetooth: Convert Unpair Device to use cmd_complete callback
Bluetooth: Convert discovery commands to use cmd_complete callback
Bluetooth: Convert Get Clock Info to use cmd_complete callback
Bluetooth: Fix initializing hci_conn RSSI to invalid value
Bluetooth: Fix Get Conn Info to use cmd_complete callback
Bluetooth: Remove redundant reverse_base_uuid variable
Johannes Berg (23):
iwlwifi: mvm: use correct type for firmware status
iwlwifi: mvm: rs: don't use shadowing variable
iwlwifi: mvm: don't capture firmware coredump for D3->D0 reconfig
iwlwifi: mvm: support random MAC address for scanning
iwlwifi: pcie: support 7265-D devices
iwlwifi: mvm: use unsigned for ssid_bitmap
iwlwifi: mvm: refactor key add/remove functions
iwlwifi: mvm: add WEP RX hardware offload support
iwlwifi: build mac80211 rx_status in place
iwlwifi: mvm: pull crypto header into skb->head
iwlwifi: mvm: pull SNAP header into skb->head
ath10k: don't rebuild all the time
Revert "mac80211_hwsim: VHT add 160MHz width support"
mac80211: disable 80+80/160 in VHT correctly
cfg80211: remove pointless channel lookup in survey code
mac80211: check if channels allow 80 MHz for VHT probe requests
cfg80211: refactor the various CQM event sending code
cfg80211: clean up beacon loss CQM event
nl80211: don't crash sending invalid chandef
cfg80211: make WEXT compatibility unselectable
NFC: Don't include linux/unaligned/access_ok.h
cfg80211: remove unneeded initialisations in nl80211_set_reg
iwlwifi: move firmware file format definitions to correct header
John W. Linville (9):
Merge tag 'iwlwifi-next-for-john-2014-11-24' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next
Merge branch 'for-linville' of git://github.com/kvalo/ath
Merge tag 'iwlwifi-next-for-john-2014-12-02' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge tag 'nfc-next-3.19-1' of git://git.kernel.org/.../sameo/nfc-next
Merge git://git.kernel.org/.../jberg/mac80211-next
MAINTAINERS: orphan rtl8180
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth-next
Merge branch 'master' of git://git.kernel.org/.../linville/wireless
Julien Lefrique (10):
NFC: NCI: Add passive Listen modes in discover request
NFC: NCI: Enable NFC-DEP in Listen A and Listen F
NFC: NCI: Handle Target mode activation
NFC: NCI: Configure ATR_RES general bytes
NFC: NCI: Implement Target mode send function
NFC: NCI: Forward data received in Target mode to nfc core
NFC: Fix a memory leak
NFC: NCI: Handle Discovery deactivation type
NFC: NCI: Signal deactivation in Target mode
NFC: NCI: Fix max length of General Bytes in ATR_RES
Larry Finger (3):
rtlwifi: rtl8192ce: Fix editing error that causes silent memory corruption
rtlwifi: rtl8192ce: Fix kernel crashes due to missing callback entry
rtlwifi: rtl8192ce: Fix missing interrupt ready flag
Liad Kaufman (8):
iwlwifi: mvm: fix init_dbg flow to work as expected
iwlwifi: mvm: block TID when using TDLS
iwlwifi: pcie: add fh registers to dump data
iwlwifi: use correct fw file in 8000 b-step
iwlwifi: define the .ucode file format for debug
iwlwifi: mvm: send dbg config hcmds to fw if set in tlv
iwlwifi: pcie: config regs according to fw tlv
iwlwifi: pcie: support more monitor types dumping
Lino Sanfilippo (1):
wil6210: Fix potential memory leaks on error paths
Lorenzo Bianconi (3):
rtlwifi: update RCR register in rtl_op_configure_filter()
ath9k: add TX power per-rate tables
ath9k: add TPC capability to TX descriptor path
Luciano Coelho (24):
iwlwifi: mvm: refactor temperature notification handling
iwlwifi: mvm: handle unsolicited DTS_MEASUREMENT_NOTIFICATIONs
iwlwifi: mvm: make nd_ies part of the mvm struct
iwlwifi: mvm: use new pre_channel_switch op instead of channel_switch_beacon
iwlwifi: mvm: only save csa_vif in AP/GO mode
iwlwifi: mvm: refactor iwl_mvm_switch_vif_chanctx to support other modes
iwlwifi: mvm: add support for CHANCTX_SWMODE_REASSIGN_VIF
iwlwifi: mvm: return the actual error code when switch_vif_chanctx fails
iwlwifi: mvm: disable PS during channel switch
iwlwifi: mvm: use switching_chanctx argument instead of csa_active
iwlwifi: mvm: add CSA absent time event for clients
iwlwifi: mvm: schedule CSA time event a bit before beacon 1
iwlwifi: mvm: finalize on post_switch instead of unassign
iwlwifi: mvm: add a channel_switch op to bypass mac80211 timer
iwlwifi: mvm: disable beacon filtering during CSA
iwlwifi: mvm: clear TE data if CSA time event fails to start
iwlwifi: mvm: protect session during CSA
iwlwifi: mvm: add support for net detect
iwlwifi: mvm: refactor wowlan and netdetect configuration when suspending
iwlwifi: mvm: refactor iwl_mvm_query_wakeup_reasons()
iwlwifi: mvm: treat netdetect wake up separately
iwlwifi: mvm: check and report if wake up was due to net detect
iwlwifi: mvm: add SSID match information for net-detect
iwlwifi: mvm: add channel information to the netdetect notifications
Marcel Holtmann (19):
Bluetooth: Increase minor version of core module
Bluetooth: Increment management interface revision
Bluetooth: Simplify the error handling of Start Discovery command
Bluetooth: Use {start,stop}_discovery_complete handler for cmd_complete
Bluetooth: Split triggering of discovery commands into separate function
Bluetooth: Add HCI_RSSI_INVALID for unknown RSSI value
Bluetooth: Filter device found events based on RSSI threshold
Bluetooth: Add framework for device found filtering based on UUID
Bluetooth: Add helper function for clearing the discovery filter
Bluetooth: Fix memory leaks from discovery filter UUID list
Bluetooth: Clear discovery filter before starting background scan
Bluetooth: Fix discovery filter when no RSSI is available
Bluetooth: Report invalid RSSI for service discovery and background scan
Bluetooth: Move LE advertising report defines to the right location
Bluetooth: Add definitions for LE Direct Advertising Report event
Bluetooth: Enabled LE Direct Advertising Report event if supported
Bluetooth: Add support for handling LE Direct Advertising Report events
Bluetooth: Add support for enabling Extended Scanner Filter Policies
Bluetooth: Enable events for P-256 Public Key and DHKey commands
Mark A. Greer (13):
NFC: digital: Fix potential skb leaks in NFC-DEP code
NFC: digital: Rearrange NFC-DEP DEP_REQ/DEP_RES Code
NFC: digital: Ensure no DID in NFC-DEP responses
NFC: digital: Add Target-mode NFC-DEP DID Support
NFC: digital: Ensure no NAD byte in DEP_REQ and DEP_RES frames
NFC: digital: Enforce NFC-DEP PNI sequencing
NFC: digital: Implement NFC-DEP max payload lengths
NFC: digital: Add NFC-DEP Send Chaining Support
NFC: digital: Add NFC-DEP Receive Chaining Support
NFC: digital: Add NFC-DEP Initiator-side NACK Support
NFC: digital: Add NFC-DEP Target-side NACK Support
NFC: digital: Add NFC-DEP Initiator-side ATN Support
NFC: digital: Add NFC-DEP Target-side ATN Support
Matti Gottlieb (1):
iwlwifi: mvm: add remove flow for AUX ROC time events
Michal Kazior (23):
ath10k: start using sk_buff_head
ath10k: simplify Rx loop
ath10k: refactor htt->rx_confused
ath10k: unify rx undecapping
ath10k: remove unused function argument
ath10k: use rx descriptor for ppdu status extraction
ath10k: report rx rate and signal for fragmented Rx
ath10k: remove extra_tx_headroom
ath10k: fix offchan reliability
ath10k: make hw roc more reliable
ath10k: fix offchannel cancel failures
ath10k: don't drop corrupted mgmt frames
ath10k: add missing goto
ath10k: clean up num_peers locking
ath10k: fix station count enforcement
ath10k: add pointer constness to traces
ath10k: fix wmi svc bitmap dbg print
ath10k: add sanity checks for service bmap parsing
ath10k: make wmi service bitmap non-debug
ath10k: remove unused callback argument from struct ath10k_hif_cb::rx_completion
ath10k: remove transfer_id from ath10k_hif_cb::tx_completion
ath10k: prevent pci tx/rx starvation
ath10k: simplify rx ring size/fill calculation
Oren Givon (2):
iwlwifi: sdio: new SDIO card id for 4165 series
iwlwifi: fix 4165 series name
Patrik Flykt (1):
mac80211_hwsim: Send alpha2 only if non-zero
Ricardo Ribalda Delgado (1):
wireless/p54: Remove duplicated net2280 header
Stanislaw Gruszka (5):
rt2800: calculate tx power temperature compensation on selected chips
rt2x00: use timeout in rt2x00usb_vendor_request
rt2x00: change REGISTER_BUSY_COUNT for USB
rt2x00: change REGISTER_TIMEOUT
Revert "rt2x00: Endless loop on hub port power down"
Stefan Schmidt (5):
net/6lowpan: Remove FSF address from GPL statement.
net/ieee802154: Make sure alignment matches parenthesis..
net/ieee802154: Remove and add extra blank lines as needed.
net/mac802154: Remove extra blank lines.
net/mac802154: No need for an extra space when casting
Steven Walter (1):
Bluetooth: Automatically flushable packets aren't allowed on LE links
Sujith Manoharan (3):
ath10k: fix shared WEP
ath10k: fix locking for WEP keys
ath10k: fix bug reported by lockdep
Varka Bhadram (4):
ieee802154: fix spelling mistakes
mac802154: remove unnecessary if statement
mac802154: use goto label on failure
cc2520: adds terminating newline
Vivek Natarajan (2):
ath: Fix a false radar detection pattern
ath10k: do not limit RTS threshold value to 2347
Vladimir Kondratiev (9):
wil6210: propagate disconnect reason
wil6210: add handling of RX HTRSH interrupt
wil6210: fix recovery after scan timeout
wil6210: remove wil_to_pcie_dev()
wil6210: configurable vring sizes
wil6210: fix warning in pointer arithmetic
wil6210: Rate limit "ring full" error message
wil6210: reset flow update
wil6210: remove TODO wrt buffer alignment
Xinming Hu (1):
Bluetooth: btmrvl add firmware dump support
Yanbo Li (2):
ath10k: add register access debugfs interface
ath10k: add memory dump debugfs interface
Documentation/devicetree/bindings/btmrvl.txt | 29 +
Documentation/devicetree/bindings/bus/bcma.txt | 21 +
MAINTAINERS | 18 +-
drivers/bcma/bcma_private.h | 1 +
drivers/bcma/driver_chipcommon.c | 2 +-
drivers/bcma/driver_gpio.c | 4 +-
drivers/bcma/driver_mips.c | 11 +-
drivers/bcma/driver_pci_host.c | 4 +-
drivers/bcma/main.c | 79 +-
drivers/bcma/scan.c | 1 +
drivers/bluetooth/Kconfig | 1 +
drivers/bluetooth/ath3k.c | 4 +
drivers/bluetooth/btmrvl_debugfs.c | 31 +
drivers/bluetooth/btmrvl_drv.h | 20 +
drivers/bluetooth/btmrvl_main.c | 68 +-
drivers/bluetooth/btmrvl_sdio.c | 304 +++-
drivers/bluetooth/btmrvl_sdio.h | 5 +
drivers/bluetooth/btusb.c | 14 +-
drivers/bluetooth/hci_ath.c | 2 +-
drivers/bluetooth/hci_h5.c | 25 +
drivers/net/ethernet/broadcom/b44.c | 2 +
drivers/net/ieee802154/Kconfig | 10 -
drivers/net/ieee802154/Makefile | 1 -
drivers/net/ieee802154/at86rf230.c | 445 +++---
drivers/net/ieee802154/cc2520.c | 73 +-
drivers/net/ieee802154/fakehard.c | 427 -----
drivers/net/ieee802154/fakelb.c | 91 +-
drivers/net/ieee802154/mrf24j40.c | 104 +-
drivers/net/wireless/ath/ath.h | 13 +-
drivers/net/wireless/ath/ath10k/ce.c | 92 +-
drivers/net/wireless/ath/ath10k/ce.h | 21 +-
drivers/net/wireless/ath/ath10k/core.c | 154 +-
drivers/net/wireless/ath/ath10k/core.h | 100 +-
drivers/net/wireless/ath/ath10k/debug.c | 1154 +++++++++++---
drivers/net/wireless/ath/ath10k/debug.h | 46 +-
drivers/net/wireless/ath/ath10k/hif.h | 53 +-
drivers/net/wireless/ath/ath10k/htc.c | 13 +-
drivers/net/wireless/ath/ath10k/htt.h | 9 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 1256 +++++++--------
drivers/net/wireless/ath/ath10k/htt_tx.c | 11 +-
drivers/net/wireless/ath/ath10k/hw.h | 32 +-
drivers/net/wireless/ath/ath10k/mac.c | 746 +++++----
drivers/net/wireless/ath/ath10k/mac.h | 6 +
drivers/net/wireless/ath/ath10k/pci.c | 579 ++++---
drivers/net/wireless/ath/ath10k/spectral.c | 34 +-
drivers/net/wireless/ath/ath10k/spectral.h | 8 +-
drivers/net/wireless/ath/ath10k/trace.h | 207 ++-
drivers/net/wireless/ath/ath10k/txrx.c | 4 +-
drivers/net/wireless/ath/ath10k/wmi.c | 1179 ++++++++------
drivers/net/wireless/ath/ath10k/wmi.h | 401 ++---
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 6 +-
drivers/net/wireless/ath/ath5k/qcu.c | 8 +-
drivers/net/wireless/ath/ath6kl/cfg80211.c | 4 +-
drivers/net/wireless/ath/ath6kl/common.h | 2 +-
drivers/net/wireless/ath/ath6kl/debug.c | 28 +-
drivers/net/wireless/ath/ath6kl/debug.h | 13 +-
drivers/net/wireless/ath/ath6kl/usb.c | 9 -
drivers/net/wireless/ath/ath9k/Kconfig | 7 +
drivers/net/wireless/ath/ath9k/Makefile | 9 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 7 +-
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 42 +-
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 8 +-
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 9 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 11 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 56 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 54 +-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 8 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 181 ++-
drivers/net/wireless/ath/ath9k/ar9003_rtt.h | 36 +
drivers/net/wireless/ath/ath9k/ar953x_initvals.h | 498 +++++-
.../net/wireless/ath/ath9k/ar955x_1p0_initvals.h | 8 +-
.../net/wireless/ath/ath9k/ar9580_1p0_initvals.h | 144 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 27 +-
drivers/net/wireless/ath/ath9k/beacon.c | 5 +-
drivers/net/wireless/ath/ath9k/calib.c | 6 +-
drivers/net/wireless/ath/ath9k/calib.h | 2 +-
drivers/net/wireless/ath/ath9k/channel.c | 338 ++--
.../ath/ath9k/{spectral.c => common-spectral.c} | 165 +-
.../ath/ath9k/{spectral.h => common-spectral.h} | 29 +-
drivers/net/wireless/ath/ath9k/common.c | 2 +-
drivers/net/wireless/ath/ath9k/common.h | 1 +
drivers/net/wireless/ath/ath9k/debug.c | 60 +-
drivers/net/wireless/ath/ath9k/debug.h | 1 +
drivers/net/wireless/ath/ath9k/eeprom_def.c | 31 +-
drivers/net/wireless/ath/ath9k/gpio.c | 9 +-
drivers/net/wireless/ath/ath9k/htc.h | 5 +
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 6 +
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 25 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 13 +-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 16 +-
drivers/net/wireless/ath/ath9k/hw-ops.h | 7 +-
drivers/net/wireless/ath/ath9k/hw.c | 98 +-
drivers/net/wireless/ath/ath9k/hw.h | 43 +-
drivers/net/wireless/ath/ath9k/init.c | 73 +-
drivers/net/wireless/ath/ath9k/link.c | 12 +-
drivers/net/wireless/ath/ath9k/mac.c | 9 +-
drivers/net/wireless/ath/ath9k/mac.h | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 361 +++--
drivers/net/wireless/ath/ath9k/pci.c | 10 +-
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
drivers/net/wireless/ath/ath9k/reg.h | 38 +-
drivers/net/wireless/ath/ath9k/tx99.c | 4 +-
drivers/net/wireless/ath/ath9k/xmit.c | 37 +-
drivers/net/wireless/ath/carl9170/phy.c | 4 +-
drivers/net/wireless/ath/dfs_pattern_detector.c | 4 +-
drivers/net/wireless/ath/wcn36xx/main.c | 7 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 5 +-
drivers/net/wireless/ath/wil6210/debug.c | 17 +
drivers/net/wireless/ath/wil6210/debugfs.c | 8 +-
drivers/net/wireless/ath/wil6210/fw.c | 1 -
drivers/net/wireless/ath/wil6210/fw_inc.c | 4 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 30 +-
drivers/net/wireless/ath/wil6210/main.c | 136 +-
drivers/net/wireless/ath/wil6210/netdev.c | 2 +-
drivers/net/wireless/ath/wil6210/txrx.c | 18 +-
drivers/net/wireless/ath/wil6210/txrx.h | 4 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 26 +-
drivers/net/wireless/ath/wil6210/wmi.c | 10 +-
drivers/net/wireless/b43/main.c | 7 +-
drivers/net/wireless/brcm80211/brcmfmac/Makefile | 10 +-
drivers/net/wireless/brcm80211/brcmfmac/bcdc.c | 6 +-
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 51 +-
drivers/net/wireless/brcm80211/brcmfmac/btcoex.c | 6 +-
.../brcm80211/brcmfmac/{dhd_bus.h => bus.h} | 11 +-
.../brcmfmac/{wl_cfg80211.c => cfg80211.c} | 338 +++-
.../brcmfmac/{wl_cfg80211.h => cfg80211.h} | 11 +-
drivers/net/wireless/brcm80211/brcmfmac/chip.c | 2 +-
drivers/net/wireless/brcm80211/brcmfmac/common.c | 168 ++
.../net/wireless/brcm80211/brcmfmac/commonring.c | 2 +-
.../brcm80211/brcmfmac/{dhd_linux.c => core.c} | 47 +-
.../wireless/brcm80211/brcmfmac/{dhd.h => core.h} | 10 +-
.../brcm80211/brcmfmac/{dhd_dbg.c => debug.c} | 6 +-
.../brcm80211/brcmfmac/{dhd_dbg.h => debug.h} | 6 +-
.../net/wireless/brcm80211/brcmfmac/dhd_common.c | 400 -----
drivers/net/wireless/brcm80211/brcmfmac/feature.c | 34 +-
drivers/net/wireless/brcm80211/brcmfmac/feature.h | 1 +
drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 5 +-
drivers/net/wireless/brcm80211/brcmfmac/flowring.c | 6 +-
drivers/net/wireless/brcm80211/brcmfmac/fweh.c | 10 +-
drivers/net/wireless/brcm80211/brcmfmac/fwil.c | 102 +-
.../net/wireless/brcm80211/brcmfmac/fwil_types.h | 95 +-
drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c | 8 +-
drivers/net/wireless/brcm80211/brcmfmac/msgbuf.c | 19 +-
drivers/net/wireless/brcm80211/brcmfmac/of.c | 4 +-
drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 6 +-
drivers/net/wireless/brcm80211/brcmfmac/pcie.c | 10 +-
drivers/net/wireless/brcm80211/brcmfmac/proto.c | 6 +-
.../brcm80211/brcmfmac/{dhd_sdio.c => sdio.c} | 55 +-
.../brcm80211/brcmfmac/{sdio_host.h => sdio.h} | 8 +-
.../net/wireless/brcm80211/brcmfmac/tracepoint.c | 15 +
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 142 +-
drivers/net/wireless/brcm80211/brcmfmac/usb_rdl.h | 75 -
drivers/net/wireless/brcm80211/brcmfmac/vendor.c | 21 +-
drivers/net/wireless/brcm80211/brcmsmac/debug.c | 180 ++-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 7 +-
drivers/net/wireless/brcm80211/brcmsmac/main.c | 29 +-
drivers/net/wireless/brcm80211/brcmutil/utils.c | 16 +
.../net/wireless/brcm80211/include/brcm_hw_ids.h | 2 +
.../net/wireless/brcm80211/include/brcmu_utils.h | 2 +
drivers/net/wireless/cw1200/scan.c | 2 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 2 +-
drivers/net/wireless/ipw2x00/libipw.h | 5 -
drivers/net/wireless/ipw2x00/libipw_module.c | 15 +-
drivers/net/wireless/ipw2x00/libipw_rx.c | 21 +-
drivers/net/wireless/iwlegacy/4965-mac.c | 2 +-
drivers/net/wireless/iwlegacy/4965.h | 5 +-
drivers/net/wireless/iwlwifi/Kconfig | 1 +
drivers/net/wireless/iwlwifi/dvm/commands.h | 31 +-
drivers/net/wireless/iwlwifi/dvm/lib.c | 51 +-
drivers/net/wireless/iwlwifi/dvm/mac80211.c | 1 +
drivers/net/wireless/iwlwifi/iwl-7000.c | 48 +-
drivers/net/wireless/iwlwifi/iwl-8000.c | 28 +-
drivers/net/wireless/iwlwifi/iwl-config.h | 23 +
drivers/net/wireless/iwlwifi/iwl-csr.h | 39 +-
drivers/net/wireless/iwlwifi/iwl-debug.h | 3 +-
drivers/net/wireless/iwlwifi/iwl-drv.c | 198 ++-
drivers/net/wireless/iwlwifi/iwl-eeprom-parse.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-fw-error-dump.h | 3 +
drivers/net/wireless/iwlwifi/iwl-fw-file.h | 308 ++++
drivers/net/wireless/iwlwifi/iwl-fw.h | 244 +--
drivers/net/wireless/iwlwifi/iwl-nvm-parse.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-op-mode.h | 3 +-
drivers/net/wireless/iwlwifi/iwl-prph.h | 10 +-
drivers/net/wireless/iwlwifi/iwl-trans.h | 25 +-
drivers/net/wireless/iwlwifi/mvm/coex.c | 29 +-
drivers/net/wireless/iwlwifi/mvm/coex_legacy.c | 33 +-
drivers/net/wireless/iwlwifi/mvm/constants.h | 7 +
drivers/net/wireless/iwlwifi/mvm/d3.c | 618 +++++---
drivers/net/wireless/iwlwifi/mvm/debugfs.c | 200 ++-
drivers/net/wireless/iwlwifi/mvm/fw-api-coex.h | 9 +-
drivers/net/wireless/iwlwifi/mvm/fw-api-d3.h | 6 +-
drivers/net/wireless/iwlwifi/mvm/fw-api-power.h | 2 +-
drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h | 297 ++++
drivers/net/wireless/iwlwifi/mvm/fw-api.h | 179 ++-
drivers/net/wireless/iwlwifi/mvm/fw.c | 74 +-
drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c | 106 +-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 531 +++++--
drivers/net/wireless/iwlwifi/mvm/mvm.h | 154 +-
drivers/net/wireless/iwlwifi/mvm/nvm.c | 31 +-
drivers/net/wireless/iwlwifi/mvm/offloading.c | 2 +-
drivers/net/wireless/iwlwifi/mvm/ops.c | 87 +-
drivers/net/wireless/iwlwifi/mvm/phy-ctxt.c | 4 +-
drivers/net/wireless/iwlwifi/mvm/power.c | 40 +-
drivers/net/wireless/iwlwifi/mvm/rs.c | 123 +-
drivers/net/wireless/iwlwifi/mvm/rs.h | 2 +
drivers/net/wireless/iwlwifi/mvm/rx.c | 150 +-
drivers/net/wireless/iwlwifi/mvm/scan.c | 786 ++++++++-
drivers/net/wireless/iwlwifi/mvm/sta.c | 303 +++-
drivers/net/wireless/iwlwifi/mvm/sta.h | 5 +
drivers/net/wireless/iwlwifi/mvm/tdls.c | 569 ++++++-
drivers/net/wireless/iwlwifi/mvm/time-event.c | 146 +-
drivers/net/wireless/iwlwifi/mvm/time-event.h | 4 +-
drivers/net/wireless/iwlwifi/mvm/tt.c | 75 +-
drivers/net/wireless/iwlwifi/mvm/tx.c | 45 +-
drivers/net/wireless/iwlwifi/mvm/utils.c | 37 +
drivers/net/wireless/iwlwifi/pcie/drv.c | 20 +
drivers/net/wireless/iwlwifi/pcie/trans.c | 404 +++--
drivers/net/wireless/iwlwifi/pcie/tx.c | 99 +-
drivers/net/wireless/mac80211_hwsim.c | 660 +++++++-
drivers/net/wireless/mac80211_hwsim.h | 28 +-
drivers/net/wireless/mwifiex/11n.c | 4 +
drivers/net/wireless/mwifiex/11n.h | 4 +
drivers/net/wireless/mwifiex/11n_rxreorder.c | 6 +
drivers/net/wireless/mwifiex/Kconfig | 2 +-
drivers/net/wireless/mwifiex/cfg80211.c | 130 +-
drivers/net/wireless/mwifiex/decl.h | 19 +
drivers/net/wireless/mwifiex/fw.h | 34 +-
drivers/net/wireless/mwifiex/init.c | 22 +-
drivers/net/wireless/mwifiex/join.c | 4 +-
drivers/net/wireless/mwifiex/main.c | 123 +-
drivers/net/wireless/mwifiex/main.h | 63 +-
drivers/net/wireless/mwifiex/scan.c | 78 +-
drivers/net/wireless/mwifiex/sdio.c | 2 +
drivers/net/wireless/mwifiex/sdio.h | 7 +
drivers/net/wireless/mwifiex/sta_cmdresp.c | 2 +-
drivers/net/wireless/mwifiex/sta_event.c | 14 +-
drivers/net/wireless/mwifiex/sta_ioctl.c | 4 +-
drivers/net/wireless/mwifiex/sta_rx.c | 3 +
drivers/net/wireless/mwifiex/sta_tx.c | 6 +
drivers/net/wireless/mwifiex/tdls.c | 288 ++++
drivers/net/wireless/mwifiex/txrx.c | 35 +-
drivers/net/wireless/mwifiex/uap_cmd.c | 2 +-
drivers/net/wireless/mwifiex/uap_event.c | 5 +
drivers/net/wireless/mwifiex/uap_txrx.c | 11 +-
drivers/net/wireless/mwifiex/usb.c | 51 +-
drivers/net/wireless/mwifiex/usb.h | 3 +
drivers/net/wireless/mwifiex/util.c | 38 +
drivers/net/wireless/mwifiex/wmm.c | 42 +-
drivers/net/wireless/mwl8k.c | 7 +-
drivers/net/wireless/p54/net2280.h | 451 ------
drivers/net/wireless/p54/p54usb.h | 13 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 18 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 45 +-
drivers/net/wireless/rt2x00/rt2x00.h | 12 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 7 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 28 +-
drivers/net/wireless/rt2x00/rt2x00usb.h | 41 +-
drivers/net/wireless/rt2x00/rt73usb.c | 2 +-
drivers/net/wireless/rtlwifi/core.c | 21 +-
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 3 +-
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 3 +
drivers/net/wireless/rtlwifi/rtl8192ce/trx.c | 24 +-
drivers/net/wireless/rtlwifi/rtl8192ce/trx.h | 2 +
drivers/net/wireless/rtlwifi/rtl8192ee/Makefile | 5 +-
drivers/net/wireless/rtlwifi/rtl8723ae/Makefile | 3 -
drivers/net/wireless/rtlwifi/rtl8723be/Makefile | 3 -
drivers/net/wireless/rtlwifi/rtl8821ae/Makefile | 3 -
drivers/net/wireless/rtlwifi/rtl8821ae/phy.c | 12 +-
drivers/net/wireless/ti/wl1251/main.c | 2 +-
drivers/net/wireless/ti/wlcore/cmd.c | 15 +-
drivers/net/wireless/ti/wlcore/cmd.h | 2 -
drivers/net/wireless/ti/wlcore/event.c | 5 +-
drivers/net/wireless/ti/wlcore/main.c | 23 +-
drivers/nfc/pn544/i2c.c | 2 +-
drivers/nfc/st21nfca/i2c.c | 41 +-
drivers/nfc/st21nfca/st21nfca.c | 32 +-
drivers/nfc/st21nfca/st21nfca.h | 2 -
drivers/nfc/st21nfca/st21nfca_dep.c | 47 +-
drivers/nfc/st21nfca/st21nfca_dep.h | 4 +-
drivers/nfc/st21nfcb/i2c.c | 39 +-
drivers/nfc/st21nfcb/ndlc.c | 2 +-
drivers/ssb/pcihost_wrapper.c | 33 +-
drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c | 4 +-
drivers/staging/vt6656/main_usb.c | 7 +-
include/linux/ath9k_platform.h | 3 +
include/linux/bcma/bcma.h | 2 +
include/linux/bcma/bcma_driver_mips.h | 4 +-
include/linux/ieee80211.h | 71 +-
include/{net => linux}/ieee802154.h | 61 +-
include/linux/netdevice.h | 3 +
include/linux/nl802154.h | 4 -
include/linux/platform_data/st21nfca.h | 1 -
include/linux/platform_data/st21nfcb.h | 1 -
include/net/6lowpan.h | 12 +-
include/net/af_ieee802154.h | 4 -
include/net/bluetooth/hci.h | 68 +-
include/net/bluetooth/hci_core.h | 78 +-
include/net/bluetooth/l2cap.h | 21 +-
include/net/bluetooth/mgmt.h | 24 +-
include/net/cfg80211.h | 241 ++-
include/net/cfg802154.h | 161 ++
include/net/ieee802154_netdev.h | 18 +-
include/net/mac80211.h | 319 +++-
include/net/mac802154.h | 158 +-
include/net/nfc/digital.h | 13 +
include/net/nfc/hci.h | 4 +
include/net/nfc/nci.h | 37 +-
include/net/nfc/nci_core.h | 9 +
include/net/nfc/nfc.h | 2 +
include/net/nl802154.h | 226 ++-
include/net/regulatory.h | 12 +
include/net/wpan-phy.h | 105 --
include/uapi/linux/nfc.h | 23 +-
include/uapi/linux/nl80211.h | 147 +-
net/6lowpan/iphc.c | 103 +-
net/bluetooth/6lowpan.c | 300 ++--
net/bluetooth/Kconfig | 21 +-
net/bluetooth/Makefile | 2 +-
net/bluetooth/af_bluetooth.c | 2 +-
net/bluetooth/amp.c | 25 +-
net/bluetooth/bnep/Kconfig | 2 +-
net/bluetooth/cmtp/Kconfig | 2 +-
net/bluetooth/ecc.c | 816 ++++++++++
net/bluetooth/ecc.h | 54 +
net/bluetooth/hci_conn.c | 15 +-
net/bluetooth/hci_core.c | 415 +++--
net/bluetooth/hci_event.c | 296 +++-
net/bluetooth/hci_sock.c | 2 +-
net/bluetooth/hidp/Kconfig | 2 +-
net/bluetooth/hidp/core.c | 10 +-
net/bluetooth/l2cap_core.c | 97 +-
net/bluetooth/l2cap_sock.c | 29 +-
net/bluetooth/mgmt.c | 1000 ++++++++----
net/bluetooth/rfcomm/Kconfig | 2 +-
net/bluetooth/rfcomm/core.c | 12 +-
net/bluetooth/smp.c | 1670 +++++++++++++++++---
net/bluetooth/smp.h | 60 +-
net/ieee802154/6lowpan_rtnl.c | 149 +-
net/ieee802154/Makefile | 4 +-
net/ieee802154/af802154.h | 4 -
net/ieee802154/af_ieee802154.c | 8 +-
net/ieee802154/core.c | 321 ++++
net/ieee802154/core.h | 46 +
net/ieee802154/dgram.c | 7 +-
net/ieee802154/header_ops.c | 3 +-
net/ieee802154/ieee802154.h | 6 +-
net/ieee802154/netlink.c | 11 +-
net/ieee802154/nl-mac.c | 269 +---
net/ieee802154/nl-phy.c | 32 +-
net/ieee802154/nl802154.c | 957 +++++++++++
net/ieee802154/nl802154.h | 7 +
net/ieee802154/nl_policy.c | 4 -
net/ieee802154/raw.c | 5 -
net/ieee802154/rdev-ops.h | 89 ++
net/ieee802154/reassembly.c | 8 +-
net/ieee802154/reassembly.h | 4 +-
net/ieee802154/sysfs.c | 128 ++
net/ieee802154/sysfs.h | 9 +
net/ieee802154/wpan-class.c | 230 ---
net/mac80211/Kconfig | 18 +
net/mac80211/Makefile | 3 +-
net/mac80211/agg-tx.c | 12 +-
net/mac80211/cfg.c | 193 ++-
net/mac80211/chan.c | 28 +-
net/mac80211/debug.h | 10 +
net/mac80211/debugfs_key.c | 12 +-
net/mac80211/debugfs_sta.c | 11 +-
net/mac80211/driver-ops.h | 157 +-
net/mac80211/ieee80211_i.h | 122 +-
net/mac80211/iface.c | 33 +-
net/mac80211/key.c | 11 +-
net/mac80211/main.c | 44 +-
net/mac80211/mesh.h | 3 +
net/mac80211/mesh_pathtbl.c | 31 +
net/mac80211/mlme.c | 333 +++-
net/mac80211/ocb.c | 250 +++
net/mac80211/rate.c | 8 +-
net/mac80211/rate.h | 24 +-
net/mac80211/rc80211_minstrel.c | 7 +-
net/mac80211/rc80211_minstrel_ht.c | 334 +++-
net/mac80211/rc80211_minstrel_ht.h | 40 +-
net/mac80211/rc80211_minstrel_ht_debugfs.c | 43 +-
net/mac80211/rx.c | 181 ++-
net/mac80211/scan.c | 129 +-
net/mac80211/sta_info.c | 19 +-
net/mac80211/sta_info.h | 11 +
net/mac80211/status.c | 171 +-
net/mac80211/tdls.c | 800 +++++++++-
net/mac80211/trace.h | 248 ++-
net/mac80211/tx.c | 316 +++-
net/mac80211/util.c | 203 ++-
net/mac80211/vht.c | 2 +
net/mac80211/wep.c | 2 -
net/mac80211/wme.c | 72 +-
net/mac80211/wme.h | 2 -
net/mac80211/wpa.c | 5 -
net/mac802154/Kconfig | 2 +-
net/mac802154/Makefile | 4 +-
net/mac802154/cfg.c | 210 +++
net/mac802154/cfg.h | 9 +
net/mac802154/driver-ops.h | 222 +++
net/mac802154/ieee802154_dev.c | 415 -----
net/mac802154/{mac802154.h => ieee802154_i.h} | 132 +-
net/mac802154/iface.c | 586 +++++++
net/mac802154/llsec.c | 23 +-
net/mac802154/mac_cmd.c | 88 +-
net/mac802154/main.c | 217 +++
net/mac802154/mib.c | 271 +---
net/mac802154/monitor.c | 117 --
net/mac802154/rx.c | 310 +++-
net/mac802154/tx.c | 154 +-
net/mac802154/util.c | 84 +
net/mac802154/wpan.c | 599 -------
net/nfc/digital_dep.c | 834 +++++++++-
net/nfc/hci/command.c | 3 +
net/nfc/hci/core.c | 56 +
net/nfc/llcp_commands.c | 6 +-
net/nfc/llcp_core.c | 5 +-
net/nfc/llcp_sock.c | 6 +-
net/nfc/nci/core.c | 150 +-
net/nfc/nci/data.c | 24 +-
net/nfc/nci/ntf.c | 152 +-
net/nfc/netlink.c | 77 +-
net/wireless/Kconfig | 2 +-
net/wireless/Makefile | 2 +-
net/wireless/chan.c | 10 +-
net/wireless/core.c | 95 +-
net/wireless/core.h | 13 +
net/wireless/nl80211.c | 978 +++++++++---
net/wireless/ocb.c | 88 ++
net/wireless/rdev-ops.h | 79 +-
net/wireless/reg.c | 156 +-
net/wireless/sme.c | 13 +-
net/wireless/trace.h | 155 +-
net/wireless/util.c | 5 +-
435 files changed, 29693 insertions(+), 11237 deletions(-)
create mode 100644 Documentation/devicetree/bindings/btmrvl.txt
delete mode 100644 drivers/net/ieee802154/fakehard.c
rename drivers/net/wireless/ath/ath9k/{spectral.c => common-spectral.c} (73%)
rename drivers/net/wireless/ath/ath9k/{spectral.h => common-spectral.h} (85%)
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd_bus.h => bus.h} (98%)
rename drivers/net/wireless/brcm80211/brcmfmac/{wl_cfg80211.c => cfg80211.c} (95%)
rename drivers/net/wireless/brcm80211/brcmfmac/{wl_cfg80211.h => cfg80211.h} (98%)
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/common.c
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd_linux.c => core.c} (96%)
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd.h => core.h} (96%)
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd_dbg.c => debug.c} (98%)
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd_dbg.h => debug.h} (98%)
delete mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c
rename drivers/net/wireless/brcm80211/brcmfmac/{dhd_sdio.c => sdio.c} (98%)
rename drivers/net/wireless/brcm80211/brcmfmac/{sdio_host.h => sdio.h} (98%)
delete mode 100644 drivers/net/wireless/brcm80211/brcmfmac/usb_rdl.h
delete mode 100644 drivers/net/wireless/p54/net2280.h
rename include/{net => linux}/ieee802154.h (79%)
create mode 100644 include/net/cfg802154.h
delete mode 100644 include/net/wpan-phy.h
create mode 100644 net/bluetooth/ecc.c
create mode 100644 net/bluetooth/ecc.h
create mode 100644 net/ieee802154/core.c
create mode 100644 net/ieee802154/core.h
create mode 100644 net/ieee802154/nl802154.c
create mode 100644 net/ieee802154/nl802154.h
create mode 100644 net/ieee802154/rdev-ops.h
create mode 100644 net/ieee802154/sysfs.c
create mode 100644 net/ieee802154/sysfs.h
delete mode 100644 net/ieee802154/wpan-class.c
create mode 100644 net/mac80211/ocb.c
create mode 100644 net/mac802154/cfg.c
create mode 100644 net/mac802154/cfg.h
create mode 100644 net/mac802154/driver-ops.h
delete mode 100644 net/mac802154/ieee802154_dev.c
rename net/mac802154/{mac802154.h => ieee802154_i.h} (63%)
create mode 100644 net/mac802154/iface.c
create mode 100644 net/mac802154/main.c
delete mode 100644 net/mac802154/monitor.c
create mode 100644 net/mac802154/util.c
delete mode 100644 net/mac802154/wpan.c
create mode 100644 net/wireless/ocb.c
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Ivaylo Dimitrov @ 2014-12-08 19:42 UTC (permalink / raw)
To: Dan Williams, Pali Rohár
Cc: Marcel Holtmann, Greg Kroah-Hartman, Ming Lei, Pavel Machek,
John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Aaro Koskinen, Kalle Valo,
Sebastian Reichel, David Gnedt
In-Reply-To: <1418066813.1350.18.camel@dcbw.local>
On 8.12.2014 21:26, Dan Williams wrote:
>
> a) change driver to prefer a new "wl1251-nvs-n900.bin" file, but fall
> back to "wl1251-nvs.bin" if the first one isn't present
> b) have a "wl1251-cal-nvs-update" service that, if wl1521-nvs-n900.bin
> is *not* present mounts the CAL MTD, reads the data, writes it out into
> wl1521-nvs-n900.bin, and the rmmod/modprobes the driver
>
> and done? Stuff that's not N900 just wouldn't ship the update service
> and would proceed like none of this happened.
>
> Dan
>
>
That would mean that the driver should not be built-in, as afaik we
cannot rmmod built-in drivers. Sure, it will work after a reboot, but
this is a bit hacky, agree?
Also, new NVS file needs to be loaded when fcc regulation changes(flying
abroad), so that would mean that the device would be outside of those
until reboot (in case of built-in driver)
Ivo
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Marcel Holtmann @ 2014-12-08 19:41 UTC (permalink / raw)
To: Pali Rohár
Cc: Greg Kroah-Hartman, Ming Lei, Pavel Machek, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201412082015.18501@pali>
Hi Pali,
>>>>>>>> On Saturday 06 December 2014 13:49:54 Pavel Machek
>>>>>>>> wrote: /**
>>>>>>>>
>>>>>>>> + * request_firmware_prefer_user: - prefer usermode
>>>>>>>> helper for loading firmware + * @firmware_p: pointer to
>>>>>>>> firmware image
>>>>>>>> + * @name: name of firmware file
>>>>>>>> + * @device: device for which firmware is being loaded
>>>>>>>> + *
>>>>>>>> + * This function works pretty much like
>>>>>>>> request_firmware(), but it prefer + * usermode helper.
>>>>>>>> If usermode helper fails then it fallback to direct
>>>>>>>> access. + * Usefull for dynamic or model specific
>>>>>>>> firmware data. + **/
>>>>>>>> +int request_firmware_prefer_user(const struct firmware
>>>>>>>> **firmware_p, + const char
>>>>>>>> *name, struct device *device) +{
>>>>>>>> + int ret;
>>>>>>>> + __module_get(THIS_MODULE);
>>>>>>>> + ret = _request_firmware(firmware_p, name,
>>>>>>>> device, + FW_OPT_UEVENT
>>>>>>>> | FW_OPT_PREFER_USER); +
>>>>>>>> module_put(THIS_MODULE); + return ret;
>>>>>>>> +}
>>>>>>>> +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
>>>>>>>
>>>>>>> I'd like to introduce request_firmware_user() which only
>>>>>>> requests firmware from user space, and this way is
>>>>>>> simpler and more flexible since we have
>>>>>>> request_firmware_direct() already.
>>>>>>
>>>>>> Why would a driver care about what program provides the
>>>>>> firmware? It shouldn't at all, and we want to get rid of
>>>>>> the userspace firmware loader, not encourage drivers to
>>>>>> use it "exclusively" at all.
>>>>>
>>>>> Do not remove it! Without userspace firmware loader it is
>>>>> impossible to load dynamic firmware files.
>>>>
>>>> why is this dynamic in the first place. It does not sound
>>>> like dynamic data to me at all. This is like the WiFi MAC
>>>> address(es) or Bluetooth BD_ADDR. They are all static
>>>> information. The only difference is that they are on the
>>>> host accessibly filesystem or storage and not on the
>>>> device itself.
>>>>
>>>> To be honest, for Bluetooth we solved this now. If the
>>>> device is missing key information like the calibration
>>>> data or BD_ADDR, then it comes up unconfigured. A
>>>> userspace process can then go and load the right data into
>>>> it and then the device becomes available as Bluetooth
>>>> device.
>>>>
>>>> Trying to use request_firmware to load some random data and
>>>> insist on going through userspace helper for that sounds
>>>> crazy to me. Especially since we are trying hard to get
>>>> away from the userspace loader. Forcing to keep it for new
>>>> stuff sounds backwards to me.
>>>>
>>>> With the special Nokia partition in mind, why hasn't this
>>>> been turned into a mountable filesystem or into a
>>>> driver/subsystem that can access the data direct from the
>>>> kernel. I advocated for this some time ago. Maybe there
>>>> should be a special subsystem for access to these factory
>>>> persistent information that drivers then just can access.
>>>> I seem to remember that some systems provide these via
>>>> ACPI. Why does the ARM platform has to be special here?
>>>>
>>>> And the problem of getting Ethernet and WiFi MAC address
>>>> and Bluetooth BD_ADDR comes up many many times. Why not
>>>> have something generic here. And don't tell me
>>>> request_firmware is that generic solution ;)
>>>>
>>>> Regards
>>>>
>>>> Marcel
>>>
>>> Hi Marcel. I think you did not understand this problem. This
>>> discussion is not about mac address. Please read email
>>> thread again and if there are some unclear pars, then ask.
>>> Thanks!
>>
>> I think that I pretty clearly understand the problem.
>> Calibration data, MAC address, what is the difference? For me
>> this is all the same. It is data that is specific to a device
>> or type of devices and it is stored somewhere else. In most
>> cases in some immutable memory/flash area.
>>
>
> Those calibration data (in form of binary NVS firmware file)
> needs to be sent to wl1251 chip. Mac address is not needed at
> this step (and kernel generate some random if is not provided).
the MAC address is just an example or similar data. And to be clear the kernel generating some random address is not a good idea either. If you get a new random address on every boot that is total disaster. Because it sort of works does not mean it is the right way to do it. That is why I am including MAC address in the list here. It is same kind of data that is needed before a device can be declared fully functional.
> (Just to note wl1271 driver loads both MAC address and NVS data
> via one firmware file which is prepared by userspace, but this
> discussion is about wl1251...)
There is no difference between any drivers here. I do not know why are you trying to tie this to a specific driver. Why does it matter what kind of information these are. The point is they are not static, they are device specific and come from different sources. And the kernel driver needs them.
>> What you want is access to this data since the kernel driver
>> needs it. Do I get this so far ;)
>>
>
> Yes, we need to provide NVS data to kernel when kernel ask for
> them.
>
>> So my take is that request_firmware is not the right way to
>> get this data. Or more precisely make sure that this data is
>> available to kernel drivers. And what I am seeing here is
>> that instead of actually solving the bigger problem, we just
>> hack around it with request_firmware. Now surprisingly the
>> request_firmware loads files directly from the kernel and all
>> the hacks do not work anymore.
>>
>> Regards
>>
>> Marcel
>
> Just read emails again...
>
> Our problem is:
>
> linux-firmware.git tree provides two binary firmware files:
>
> ti-connectivity/wl1251-fw.bin
> ti-connectivity/wl1251-nvs.bin
>
> First is firmware file, second NVS file with generic calibration
> data. Kernel driver wl1251 now loads both firmware files via
> request_firmware. Generic calibration data are enough for wl1251
> chip (it should work). But devices have own calibration data
> stored somewhere else.
Loading generic data that is static and stored on the filesystem via request_firmware is totally fine. If you have the NVS data in that file, then great. If you have specific data, then overwrite the file, link it to the real file or do something with it. As long as it is a file on the filesystem, you will be just fine.
If you however want to hook into some magic userspace helper to build the content of the file and somehow load it, then that sounds like the wrong approach to me.
> On Nokia N900 NVS data are generated on-the-fly from some bytes
> from CAL (/dev/mtd1), from state of cellular network and from
> some other regulation settings.
>
> So I think that files stored in linux-firmware.git tree (which
> are also installed into /lib/firmware/) should be loaded with
> request_firmware function. Or not? Do you think something else?
> What other developers think?
>
> I'm against kernel driver for CAL (/dev/mtd1) for more reasons:
>
> 1) we have userspace open source code, but licensed under GPLv3.
> And until kernel change license, we cannot include it.
>
> 2) NVS data are (probably) not in one place, plus they depends on
> something other.
>
> 3) If manufacture XYZ create new device with its own storage
> format of calibration data this means that correct solution for
> XYZ is also to implement new kernel fs driver for its own format.
> Do you really want to have in kernel all those drivers for all
> different (proprietary) storage formats?
>
> 4) It does not help us with existence of generic file
> /lib/firmware/ti-connectivity/wl1251-nvs.bin which comes from
> linux-firmware.git tree.
As I said before, I think that a driver should not register with its subsystem until it has all data that it needs. Or if it can tell the subsystem that it is missing data and the subsystem knows how to provide hooks for getting this data.
We all know that many embedded devices need extra data to operation properly. This data is normally programmed onto the device in the factory. So if someone would now build a subsystem that can retrieve magic blobs of data from magic places like ACPI, devicetree, userspace or whatever that would help. I can see that request_firmware looks a lot like this. However the reality is that you have a race condition here. request_firmware relies on the fact that it is file in userspace. That is what it was designed for in the first place. Firmware files that are place on the hosts filesystem. It does not have the option to start a notifier when blob xyz becomes available. And that is what you essentially need for the drivers. The driver finds the hardware and goes, now I need blob xyz to function
and then it sits and waits until it gets told that blob is now available. Then it initializes the hardware and registers it to the subsystem.
I fully realize that request_firmware is pretty close in this regard, but the semantics and timing that many of these NVS data like addresses, our calibration information are different. It is more than just this specific drivers problem. There are many devices out there that have certain settings stored somewhere and it needs these based on how the device is build or how it is provisioning in the factory.
What I would actually prefer to see that the driver just requests this blob of information and then a separate subsystem deals with getting it. As I said, in some cases the information might be in ACPI or devicetree or accessible by a special driver. In that case no userspace interaction would be needed at all. However the driver has to deal with the fact that the data blob might not be available for a certain period of time. If you mention cellular modem, then that one has to boot up first and get its data. More reason to actually design this cleanly so that there are no race conditions.
Regards
Marcel
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-12-08 19:36 UTC (permalink / raw)
To: Dan Williams
Cc: Marcel Holtmann, Greg Kroah-Hartman, Ming Lei, Pavel Machek,
John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Ivaylo Dimitrov, Aaro Koskinen,
Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <1418066813.1350.18.camel@dcbw.local>
[-- Attachment #1: Type: Text/Plain, Size: 8876 bytes --]
On Monday 08 December 2014 20:26:53 Dan Williams wrote:
> On Mon, 2014-12-08 at 20:15 +0100, Pali Rohár wrote:
> > On Monday 08 December 2014 19:50:17 Marcel Holtmann wrote:
> > > Hi Pali,
> > >
> > > >>>>>> On Saturday 06 December 2014 13:49:54 Pavel Machek
> > > >>>>>> wrote: /**
> > > >>>>>>
> > > >>>>>> + * request_firmware_prefer_user: - prefer usermode
> > > >>>>>> helper for loading firmware + * @firmware_p:
> > > >>>>>> pointer to firmware image
> > > >>>>>> + * @name: name of firmware file
> > > >>>>>> + * @device: device for which firmware is being
> > > >>>>>> loaded + *
> > > >>>>>> + * This function works pretty much like
> > > >>>>>> request_firmware(), but it prefer + * usermode
> > > >>>>>> helper. If usermode helper fails then it fallback
> > > >>>>>> to direct access. + * Usefull for dynamic or model
> > > >>>>>> specific firmware data. + **/
> > > >>>>>> +int request_firmware_prefer_user(const struct
> > > >>>>>> firmware **firmware_p, +
> > > >>>>>> const char *name, struct device *device) +{
> > > >>>>>> + int ret;
> > > >>>>>> + __module_get(THIS_MODULE);
> > > >>>>>> + ret = _request_firmware(firmware_p, name,
> > > >>>>>> device, +
> > > >>>>>> FW_OPT_UEVENT
> > > >>>>>>
> > > >>>>>> | FW_OPT_PREFER_USER); +
> > > >>>>>>
> > > >>>>>> module_put(THIS_MODULE); + return ret;
> > > >>>>>> +}
> > > >>>>>> +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
> > > >>>>>
> > > >>>>> I'd like to introduce request_firmware_user() which
> > > >>>>> only requests firmware from user space, and this
> > > >>>>> way is simpler and more flexible since we have
> > > >>>>> request_firmware_direct() already.
> > > >>>>
> > > >>>> Why would a driver care about what program provides
> > > >>>> the firmware? It shouldn't at all, and we want to
> > > >>>> get rid of the userspace firmware loader, not
> > > >>>> encourage drivers to use it "exclusively" at all.
> > > >>>
> > > >>> Do not remove it! Without userspace firmware loader it
> > > >>> is impossible to load dynamic firmware files.
> > > >>
> > > >> why is this dynamic in the first place. It does not
> > > >> sound like dynamic data to me at all. This is like the
> > > >> WiFi MAC address(es) or Bluetooth BD_ADDR. They are
> > > >> all static information. The only difference is that
> > > >> they are on the host accessibly filesystem or storage
> > > >> and not on the device itself.
> > > >>
> > > >> To be honest, for Bluetooth we solved this now. If the
> > > >> device is missing key information like the calibration
> > > >> data or BD_ADDR, then it comes up unconfigured. A
> > > >> userspace process can then go and load the right data
> > > >> into it and then the device becomes available as
> > > >> Bluetooth device.
> > > >>
> > > >> Trying to use request_firmware to load some random data
> > > >> and insist on going through userspace helper for that
> > > >> sounds crazy to me. Especially since we are trying
> > > >> hard to get away from the userspace loader. Forcing to
> > > >> keep it for new stuff sounds backwards to me.
> > > >>
> > > >> With the special Nokia partition in mind, why hasn't
> > > >> this been turned into a mountable filesystem or into a
> > > >> driver/subsystem that can access the data direct from
> > > >> the kernel. I advocated for this some time ago. Maybe
> > > >> there should be a special subsystem for access to
> > > >> these factory persistent information that drivers then
> > > >> just can access. I seem to remember that some systems
> > > >> provide these via ACPI. Why does the ARM platform has
> > > >> to be special here?
> > > >>
> > > >> And the problem of getting Ethernet and WiFi MAC
> > > >> address and Bluetooth BD_ADDR comes up many many
> > > >> times. Why not have something generic here. And don't
> > > >> tell me request_firmware is that generic solution ;)
> > > >>
> > > >> Regards
> > > >>
> > > >> Marcel
> > > >
> > > > Hi Marcel. I think you did not understand this problem.
> > > > This discussion is not about mac address. Please read
> > > > email thread again and if there are some unclear pars,
> > > > then ask. Thanks!
> > >
> > > I think that I pretty clearly understand the problem.
> > > Calibration data, MAC address, what is the difference? For
> > > me this is all the same. It is data that is specific to a
> > > device or type of devices and it is stored somewhere
> > > else. In most cases in some immutable memory/flash area.
> >
> > Those calibration data (in form of binary NVS firmware file)
> > needs to be sent to wl1251 chip. Mac address is not needed
> > at this step (and kernel generate some random if is not
> > provided).
> >
> > (Just to note wl1271 driver loads both MAC address and NVS
> > data via one firmware file which is prepared by userspace,
> > but this discussion is about wl1251...)
> >
> > > What you want is access to this data since the kernel
> > > driver needs it. Do I get this so far ;)
> >
> > Yes, we need to provide NVS data to kernel when kernel ask
> > for them.
> >
> > > So my take is that request_firmware is not the right way
> > > to get this data. Or more precisely make sure that this
> > > data is available to kernel drivers. And what I am seeing
> > > here is that instead of actually solving the bigger
> > > problem, we just hack around it with request_firmware.
> > > Now surprisingly the request_firmware loads files
> > > directly from the kernel and all the hacks do not work
> > > anymore.
> > >
> > > Regards
> > >
> > > Marcel
> >
> > Just read emails again...
> >
> > Our problem is:
> >
> > linux-firmware.git tree provides two binary firmware files:
> >
> > ti-connectivity/wl1251-fw.bin
> > ti-connectivity/wl1251-nvs.bin
> >
> > First is firmware file, second NVS file with generic
> > calibration data. Kernel driver wl1251 now loads both
> > firmware files via request_firmware. Generic calibration
> > data are enough for wl1251 chip (it should work). But
> > devices have own calibration data stored somewhere else.
> >
> > On Nokia N900 NVS data are generated on-the-fly from some
> > bytes from CAL (/dev/mtd1), from state of cellular network
> > and from some other regulation settings.
> >
> > So I think that files stored in linux-firmware.git tree
> > (which are also installed into /lib/firmware/) should be
> > loaded with request_firmware function. Or not? Do you think
> > something else? What other developers think?
> >
> > I'm against kernel driver for CAL (/dev/mtd1) for more
> > reasons:
> >
> > 1) we have userspace open source code, but licensed under
> > GPLv3. And until kernel change license, we cannot include
> > it.
> >
> > 2) NVS data are (probably) not in one place, plus they
> > depends on something other.
> >
> > 3) If manufacture XYZ create new device with its own storage
> > format of calibration data this means that correct solution
> > for XYZ is also to implement new kernel fs driver for its
> > own format. Do you really want to have in kernel all those
> > drivers for all different (proprietary) storage formats?
> >
> > 4) It does not help us with existence of generic file
> > /lib/firmware/ti-connectivity/wl1251-nvs.bin which comes
> > from linux-firmware.git tree.
>
> a) change driver to prefer a new "wl1251-nvs-n900.bin" file,
Why to "*-n900.bin" ? wl1251 driver is used on other devices too.
> but fall back to "wl1251-nvs.bin" if the first one isn't
> present
> b) have a "wl1251-cal-nvs-update" service that, if
> wl1521-nvs-n900.bin is *not* present mounts the CAL MTD,
> reads the data, writes it out into wl1521-nvs-n900.bin, and
> the rmmod/modprobes the driver
>
Quote:
> On Nokia N900 NVS data are generated on-the-fly from some bytes
> from CAL (/dev/mtd1), from state of cellular network and from
> some other regulation settings.
This basically means to rewrite it every boot or everytime when
country was changed (for regulation settings). And Ii really do
not want to do that.
And rmmod is not working on statically linked drivers into
zImage. So this is not solution.
> and done? Stuff that's not N900 just wouldn't ship the update
> service and would proceed like none of this happened.
>
> Dan
Again, what is wrong with userspace firmware helper? I think that
it fix this problem in a clean way without any hacks (like CAL in
kernel or creating new FS specially for parsing NVS and so on) in
kernel. And in userspace we can implement program which generate
NVS firmware data on-the-fly and send them to kernel in
compatible format of ti-connectivity/wl1251-nvs.bin
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [RFC][PATCHES] iov_iter.c rewrite
From: Al Viro @ 2014-12-08 19:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: Kirill A. Shutemov, Linux Kernel Mailing List, linux-fsdevel,
Network Development
In-Reply-To: <CA+55aFyh0cV+ztK47mu1QN6aF4VvPE1V5zF7_X2TdYxZ38zZRA@mail.gmail.com>
On Mon, Dec 08, 2014 at 10:57:31AM -0800, Linus Torvalds wrote:
> So the whole "get_page()" thing is broken. Iterating over pages in a
> KVEC is simply wrong, wrong, wrong. It needs to fail.
Well, _that_ is easy to do, of course... E.g. by replacing that thing in
iov_iter_get_pages()/iov_iter_get_pages_alloc() with ({ return -EFAULT; })
will do it.
> Iterating over a KVEC to *copy* data is ok. But no page lookup stuff
> or page reference things.
>
> The old code that apparently used "get_user_pages_fast()" was ok
> almost by mistake, because it fails on all kernel pages.
On x86 it does, but I don't see anything obvious in generic version in
mm/gup.c, so the old code might still have a problem on some architectures.
What am I missing here?
^ 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