* [RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered
From: Denis Kenzior @ 2016-08-03 22:02 UTC (permalink / raw)
To: linux-wireless; +Cc: Denis Kenzior
This patch allows GET_INTERFACE dumps to be filtered based on
NL80211_ATTR_WIPHY or NL80211_ATTR_WDEV. The documentation for
GET_INTERFACE mentions that this is possible:
"Request an interface's configuration; either a dump request on
a %NL80211_ATTR_WIPHY or ..."
However, this behavior has not been implemented until now.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/nl80211.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 46417f9..ac19eb8 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2519,15 +2519,47 @@ static int nl80211_send_iface(struct sk_buff *msg, u32 portid, u32 seq, int flag
return -EMSGSIZE;
}
+static int nl80211_dump_interface_parse(struct sk_buff *skb,
+ struct netlink_callback *cb,
+ int *filter_wiphy)
+{
+ struct nlattr **tb = nl80211_fam.attrbuf;
+ int ret = nlmsg_parse(cb->nlh, GENL_HDRLEN + nl80211_fam.hdrsize,
+ tb, nl80211_fam.maxattr, nl80211_policy);
+ /* ignore parse errors for backward compatibility */
+ if (ret)
+ return 0;
+
+ if (tb[NL80211_ATTR_WIPHY])
+ *filter_wiphy = nla_get_u32(tb[NL80211_ATTR_WIPHY]);
+ if (tb[NL80211_ATTR_WDEV])
+ *filter_wiphy = nla_get_u64(tb[NL80211_ATTR_WDEV]) >> 32;
+
+ return 0;
+}
+
static int nl80211_dump_interface(struct sk_buff *skb, struct netlink_callback *cb)
{
int wp_idx = 0;
int if_idx = 0;
int wp_start = cb->args[0];
int if_start = cb->args[1];
+ int filter_wiphy = cb->args[2];
struct cfg80211_registered_device *rdev;
struct wireless_dev *wdev;
+ if (!wp_start && !if_start && !filter_wiphy) {
+ int ret;
+
+ filter_wiphy = -1;
+
+ ret = nl80211_dump_interface_parse(skb, cb, &filter_wiphy);
+ if (ret)
+ return ret;
+
+ cb->args[2] = filter_wiphy;
+ }
+
rtnl_lock();
list_for_each_entry(rdev, &cfg80211_rdev_list, list) {
if (!net_eq(wiphy_net(&rdev->wiphy), sock_net(skb->sk)))
@@ -2536,6 +2568,10 @@ static int nl80211_dump_interface(struct sk_buff *skb, struct netlink_callback *
wp_idx++;
continue;
}
+
+ if (filter_wiphy != -1 && filter_wiphy != rdev->wiphy_idx)
+ continue;
+
if_idx = 0;
list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
--
2.7.3
^ permalink raw reply related
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Dmitry Torokhov @ 2016-08-03 15:35 UTC (permalink / raw)
To: Arend van Spriel
Cc: Luis R. Rodriguez, Daniel Wagner, Bjorn Andersson, Daniel Wagner,
Bastien Nocera, Greg Kroah-Hartman, Johannes Berg, Kalle Valo,
Ohad Ben-Cohen, Mimi Zohar, David Howells, Andy Lutomirski,
David Woodhouse, Julia Lawall, linux-input@vger.kernel.org,
linux-kselftest, linux-wireless, lkml
In-Reply-To: <0e20a2dc-ed76-b209-5c01-387f1c444b19@broadcom.com>
On Wed, Aug 03, 2016 at 01:43:31PM +0200, Arend van Spriel wrote:
> On 03-08-16 09:42, Dmitry Torokhov wrote:
> > On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> >> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
> >>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
> >>>> On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
> >>>>>> The sysdata API's main goal rather is to provide a flexible API first,
> >>>>>> compartamentalizing the usermode helper was secondary. But now it seems
> >>>>>> I may just also add devm support too to help simplify code further.
> >>>>>
> >>>>> I missed the point that you plan to add usermode helper support to
> >>>>> the sysdata API.
> >>>>
> >>>> I had no such plans, when I have asked folks so far about "hey are you
> >>>> really in need for it, OK what for? " and "what extended uses do you
> >>>> envision?" so I far I have not gotten any replies at all. So -- instead
> >>>> sysdata currently ignores it.
> >>>
> >>> So you argue for the remoteproc use case with 100+ MB firmware that
> >>> if there is a way to load after pivot_root() (or other additional
> >>> firmware partition shows up) then there is no need at all for
> >>> usermode helper?
> >>
> >> No, I'm saying I'd like to hear valid uses cases for the usermode helper and so
> >> far I have only found using coccinelle grammar 2 explicit users, that's it. My
> >> patch series (not yet merge) then annotates these as valid as I've verified
> >> through their documentation they have some quirky requirement.
> >
> > In certain configurations (embedded) people do not want to use
> > initramfs nor modules nor embed firmware into the kernel. In this case
> > usermode helper + firmware calss timeout handling provides necessary
> > wait for the root filesystem to be mounted.
>
> And there are people who don't have a usermode helper running at all in
> their configuration, but I guess they should disable the helper.
Right, if they don't that means their system is misconfigured.
>
> In my opinion the kernel should provide functionality to user-space and
> user-space providing functionality to the kernel should be avoided.
Why? We have bunch of stuff running in userspace for the kernel. Fuse
for example. I am sure there are more.
>
> > If we solve waiting for rootfs (or something else that may contain
> > firmware) then these cases will not need to use usermode helper.
>
> If firmware (or whatever) API could get notification of mount syscall it
> could be used to retry firmware loading instead of periodic polling.
> That leaves the question raised by you about when to stop trying. The
> initlevel stuff is probably a user-space only concept, right? So no
> ideas how the kernel itself could decide except for a "long" timeout.
The kernel really does not know, it can only guess. The firmware may get
delivered by motorized carrier pidgeons. But distribution does know how
they set up, so they are in position to tell the kernel "go" or "give
up".
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Luis R. Rodriguez @ 2016-08-03 15:18 UTC (permalink / raw)
To: Arend van Spriel, Andrew Morton
Cc: Dmitry Torokhov, Luis R. Rodriguez, Daniel Wagner,
Bjorn Andersson, Daniel Wagner, Bastien Nocera,
Greg Kroah-Hartman, Johannes Berg, Kalle Valo, Ohad Ben-Cohen,
Mimi Zohar, David Howells, Andy Lutomirski, David Woodhouse,
Julia Lawall, linux-input@vger.kernel.org, linux-kselftest,
linux-wireless, lkml
In-Reply-To: <0e20a2dc-ed76-b209-5c01-387f1c444b19@broadcom.com>
On Wed, Aug 03, 2016 at 01:43:31PM +0200, Arend van Spriel wrote:
> On 03-08-16 09:42, Dmitry Torokhov wrote:
> > On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> >> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
> >>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
> >>>> On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
> >>>>>> The sysdata API's main goal rather is to provide a flexible API first,
> >>>>>> compartamentalizing the usermode helper was secondary. But now it seems
> >>>>>> I may just also add devm support too to help simplify code further.
> >>>>>
> >>>>> I missed the point that you plan to add usermode helper support to
> >>>>> the sysdata API.
> >>>>
> >>>> I had no such plans, when I have asked folks so far about "hey are you
> >>>> really in need for it, OK what for? " and "what extended uses do you
> >>>> envision?" so I far I have not gotten any replies at all. So -- instead
> >>>> sysdata currently ignores it.
> >>>
> >>> So you argue for the remoteproc use case with 100+ MB firmware that
> >>> if there is a way to load after pivot_root() (or other additional
> >>> firmware partition shows up) then there is no need at all for
> >>> usermode helper?
> >>
> >> No, I'm saying I'd like to hear valid uses cases for the usermode helper and so
> >> far I have only found using coccinelle grammar 2 explicit users, that's it. My
> >> patch series (not yet merge) then annotates these as valid as I've verified
> >> through their documentation they have some quirky requirement.
> >
> > In certain configurations (embedded) people do not want to use
> > initramfs nor modules nor embed firmware into the kernel. In this case
> > usermode helper + firmware calss timeout handling provides necessary
> > wait for the root filesystem to be mounted.
>
> And there are people who don't have a usermode helper running at all
Correction: most Linux distributions these days have
CONFIG_FW_LOADER_USER_HELPER but disable CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
And then let me re-iterate from my patches then the implications:
+When CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled request_firmware()
+*always* calls the usermode helpers. When CONFIG_FW_LOADER_USER_HELPER is
+enabled, only if you specifically ask for it will the usermode helper be
+called. If CONFIG_FW_LOADER_USER_HELPER_FALLBACK is disabled drivers can
+still require the usermode helper by using request_firmware_nowait().
The issues with CONFIG_FW_LOADER_USER_HELPER_FALLBACK are so much so
(the kmod timeout was an engineering mishap refer to my post with
details about it [0]) that these days most distributions disable it
and there have been huge efforts to ensure its not even called
explicitly, to the point now we only have TWO explicit users for it.
Keep in mind as well that in my series of patches to help clarify the
situation with the usermode helper I also proposed a fix to the firmware_class
to avoid the usermode helper completely when the firmware cache, this is
because the firmware cache purposely *kills* any pending usermode helpers
on the way to suspend anyway, so calling a new instance would be an error
and just delay suspend further.
[0] http://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html
> in
> their configuration, but I guess they should disable the helper.
Yes. I have gone to good lengths to ask why the hell its needed and so
far I have not gotten any technical reason for it.
> > If we solve waiting for rootfs (or something else that may contain
> > firmware) then these cases will not need to use usermode helper.
>
> If firmware (or whatever) API could get notification of mount syscall it
> could be used to retry firmware loading instead of periodic polling.
> That leaves the question raised by you about when to stop trying. The
> initlevel stuff is probably a user-space only concept, right?
No init levels here refer to include/linux/init.h init calls that one
wraps the kernel module inits, or subsystem inits. If it wasn't for
pivot_root() existing and also the fact that systems can be complex
I would have suggested simply that we make firmware_class move to
late_initcall() -- this however would not solve all races given how
complex systems could be set up with a partition.
> So no
> ideas how the kernel itself could decide except for a "long" timeout.
If we wanted to learn from history -- the timeout for this would be a bad idea
so this makes it a bit more complex. I proposed a technical idea here which
would avoid this and I think enable making this deterministic as well for new
systems that want that.
Luis
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Valo, Kalle @ 2016-08-03 15:04 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Arend van Spriel, Stanislaw Gruszka, Prarit Bhargava,
Greg Kroah-Hartman, Ming Lei, linux-wireless, ath10k,
mmarek@suse.com, michal.kazior@tieto.com, Arend van Spriel,
Emmanuel Grumbach
In-Reply-To: <20160803142119.GL3296@wotan.suse.de>
"Luis R. Rodriguez" <mcgrof@kernel.org> writes:
> On Wed, Aug 03, 2016 at 01:33:31PM +0200, Arend van Spriel wrote:
>> On 02-08-16 16:16, Luis R. Rodriguez wrote:
>> > On Tue, Aug 02, 2016 at 11:10:22AM +0000, Valo, Kalle wrote:
>> >> "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
>> >>
>> >>> I was considering this as a future extension to the firmware API
>> >>> through the new extensible firmware API, the sysdata API.
>> >>
>> >> I think Linus mentioned this already, but I want to reiterate anyway.
>> >> The name "sysdata" is horrible, I didn't have any idea what it means
>> >> until I read your description. Please continue to use the term
>> >> "firmware", anyone already know what it means.
>> >
>> > We've gone well past using the firmware API for firmware though, if
>> > we use it for 802.11 to replace CRDA for instance its really odd to
>> > be calling it firmware. But sure... I will rebrand again to firmware...
>>
>> I tend to agree. Although some people even call an OpenWrt image
>> firmware. Guess it is just in the eye of the beholder.
>
> Sure...
>
> Come to think of it I'll still go with "sysdata", this is a very minor
> detail, do let me know if there is anything technical rather than
> the color of the bikeshed [0] over the patches.
Well, you don't seem to care but I prefer that the terminology is clear
and I don't want to waste people's time browsing the source to find out
what something means. Even "driverdata" would be more descriptive for me
than "sysdata".
Actually, what does the "sys" refer here, system? And what system is
that exactly?
--
Kalle Valo
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Luis R. Rodriguez @ 2016-08-03 14:21 UTC (permalink / raw)
To: Arend van Spriel
Cc: Luis R. Rodriguez, Valo, Kalle, Stanislaw Gruszka,
Prarit Bhargava, Greg Kroah-Hartman, Ming Lei, linux-wireless,
ath10k, mmarek@suse.com, michal.kazior@tieto.com,
Arend van Spriel, Emmanuel Grumbach
In-Reply-To: <ae734397-6179-d0ba-3d8a-0cffc63a0fd8@broadcom.com>
On Wed, Aug 03, 2016 at 01:33:31PM +0200, Arend van Spriel wrote:
> On 02-08-16 16:16, Luis R. Rodriguez wrote:
> > On Tue, Aug 02, 2016 at 11:10:22AM +0000, Valo, Kalle wrote:
> >> "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
> >>
> >>> I was considering this as a future extension to the firmware API
> >>> through the new extensible firmware API, the sysdata API.
> >>
> >> I think Linus mentioned this already, but I want to reiterate anyway.
> >> The name "sysdata" is horrible, I didn't have any idea what it means
> >> until I read your description. Please continue to use the term
> >> "firmware", anyone already know what it means.
> >
> > We've gone well past using the firmware API for firmware though, if
> > we use it for 802.11 to replace CRDA for instance its really odd to
> > be calling it firmware. But sure... I will rebrand again to firmware...
>
> I tend to agree. Although some people even call an OpenWrt image
> firmware. Guess it is just in the eye of the beholder.
Sure...
Come to think of it I'll still go with "sysdata", this is a very minor
detail, do let me know if there is anything technical rather than
the color of the bikeshed [0] over the patches.
If you'd like another color in my bikeshed please let me know what
color exactly you prefer and I'll consider it.
[0] http://phk.freebsd.dk/sagas/bikeshed.html
Luis
^ permalink raw reply
* RE: [PATCH] mwifiex: handle edmac vendor command
From: Amitkumar Karwar @ 2016-08-03 11:20 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <87zirg8qxo.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Tuesday, May 24, 2016 1:53 AM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org
> Subject: Re: [PATCH] mwifiex: handle edmac vendor command
>
> Amitkumar Karwar <akarwar@marvell.com> writes:
>
> > Hi Kalle,
> >
> >> From: Amitkumar Karwar [mailto:akarwar@marvell.com]
> >> Sent: Friday, April 29, 2016 9:28 PM
> >> To: linux-wireless@vger.kernel.org
> >> Cc: Jeff CF Chen; Amitkumar Karwar
> >> Subject: [PATCH] mwifiex: handle edmac vendor command
> >>
> >> From: chunfan chen <jeffc@marvell.com>
> >>
> >> Userspace can configure edmac values through a custom vendor command.
> >> They will be used by hardware for adaptivity.
> >>
> >> Signed-off-by: chunfan chen <jeffc@marvell.com>
> >> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
>
> [deleted over 200 lines of unnecessary quotes]
>
> > This patch seems to have deferred. We basically want a way to download
> > a vendor specific configuration to our firmware. Do you have any
> > suggestions on how can achieve this in better way?
> >
> > I can see below iw command suits our requirement.
> >
> > iw dev <devname> vendor send <oui> <subcmd> <filename|-|hex data>
> >
> > Please guide.
>
> It was deferred because use of the nl80211 vendor interface (which I
> don't think belong to upstream drivers). I'll take a look at this patch
> in detail after the merge window.
>
Did you get a chance to check this patch?
Please let me know if you have any suggestions.
Regards,
Amitkumar
^ permalink raw reply
* [PATCH v3 0/3] Improve wireless netdev detection
From: Denis Kenzior @ 2016-08-03 21:58 UTC (permalink / raw)
To: linux-wireless; +Cc: Denis Kenzior
The current mechanism to detect hot-plug / unplug of wireless devices is
somewhat arcane. One has to listen to NEW_WIPHY/DEL_WIPHY events over
nl80211 as well as RTM_NEWLINK / RTM_DELLINK events over rtnl, then
somehow find a correlation between these events. This involves userspace
sending GET_INTERFACE or GET_WIPHY commands to the kernel, which incurs
additional roundtrips.
This patch series proposes that NEW_INTERFACE and DEL_INTERFACE events are
always emitted, regardless of whether a netdev was added/removed by the
driver or explicitly via NEW_INTERFACE/DEL_INTERFACE commands.
v2: Squished patches 2+3, 4+5. DEL_INTERFACE event notification is now
sent inside cfg80211_unregister_wdev instead of nl80211_del_interface.
v3: No changes, non-RFC version.
Denis Kenzior (3):
nl80211: Add nl80211_notify_iface
core: Always notify of new wireless netdevs
core: Always notify when wireless netdev is removed
net/wireless/core.c | 6 +++++
net/wireless/nl80211.c | 69 +++++++++++++++++++++++++++-----------------------
net/wireless/nl80211.h | 3 +++
3 files changed, 47 insertions(+), 31 deletions(-)
--
2.7.3
^ permalink raw reply
* [PATCH v3 2/3] core: Always notify of new wireless netdevs
From: Denis Kenzior @ 2016-08-03 21:58 UTC (permalink / raw)
To: linux-wireless; +Cc: Denis Kenzior
In-Reply-To: <1470261515-2830-1-git-send-email-denkenz@gmail.com>
This change alters the semantics of NL80211_CMD_NEW_INTERFACE events
by always sending this event whenever a new net_device object
associated with a wdev is registered. Prior to this change, this event
was only sent as a result of NL80211_CMD_NEW_INTERFACE command sent
from userspace. This allows userspace to reliably detect new wireless
interfaces (e.g. due to hardware hot-plug events, etc).
For wdevs created without an associated net_device object (e.g.
NL80211_IFTYPE_P2P_DEVICE), the NL80211_CMD_NEW_INTERFACE event is
still generated inside the relevant nl80211 command handler.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/core.c | 2 ++
net/wireless/nl80211.c | 23 +++++++++--------------
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7645e97..7758c0f 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1079,6 +1079,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
wdev->iftype == NL80211_IFTYPE_P2P_CLIENT ||
wdev->iftype == NL80211_IFTYPE_ADHOC) && !wdev->use_4addr)
dev->priv_flags |= IFF_DONT_BRIDGE;
+
+ nl80211_notify_iface(rdev, wdev, NL80211_CMD_NEW_INTERFACE);
break;
case NETDEV_GOING_DOWN:
cfg80211_leave(rdev, wdev);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c174770..591c3ab 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2787,7 +2787,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
struct cfg80211_registered_device *rdev = info->user_ptr[0];
struct vif_params params;
struct wireless_dev *wdev;
- struct sk_buff *msg, *event;
+ struct sk_buff *msg;
int err;
enum nl80211_iftype type = NL80211_IFTYPE_UNSPECIFIED;
u32 flags;
@@ -2891,20 +2891,15 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
return -ENOBUFS;
}
- event = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
- if (event) {
- if (nl80211_send_iface(event, 0, 0, 0,
- rdev, wdev, false) < 0) {
- nlmsg_free(event);
- goto out;
- }
-
- genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy),
- event, 0, NL80211_MCGRP_CONFIG,
- GFP_KERNEL);
- }
+ /*
+ * For wdevs which have no associated netdev object (e.g. of type
+ * NL80211_IFTYPE_P2P_DEVICE), emit the NEW_INTERFACE event here.
+ * For all other types, the event will be generated from the
+ * netdev notifier
+ */
+ if (!wdev->netdev)
+ nl80211_notify_iface(rdev, wdev, NL80211_CMD_NEW_INTERFACE);
-out:
return genlmsg_reply(msg, info);
}
--
2.7.3
^ permalink raw reply related
* [PATCH v3 3/3] core: Always notify when wireless netdev is removed
From: Denis Kenzior @ 2016-08-03 21:58 UTC (permalink / raw)
To: linux-wireless; +Cc: Denis Kenzior
In-Reply-To: <1470261515-2830-1-git-send-email-denkenz@gmail.com>
This change alters the semantics of NL80211_CMD_DEL_INTERFACE events
by always sending this event whenever a net_device object associated
with a wdev is destroyed. Prior to this change, this event was only
emitted as a result of NL80211_CMD_DEL_INTERFACE command sent from
userspace. This allows userspace to reliably detect when wireless
interfaces have been removed, e.g. due to USB removal events, etc.
For wireless device objects without an associated net_device (e.g.
NL80211_IFTYPE_P2P_DEVICE), the NL80211_CMD_DEL_INTERFACE event is
now generated inside cfg80211_unregister_wdev.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/core.c | 4 ++++
net/wireless/nl80211.c | 18 +-----------------
2 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 7758c0f..fccead7 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -906,6 +906,8 @@ void cfg80211_unregister_wdev(struct wireless_dev *wdev)
if (WARN_ON(wdev->netdev))
return;
+ nl80211_notify_iface(rdev, wdev, NL80211_CMD_DEL_INTERFACE);
+
list_del_rcu(&wdev->list);
rdev->devlist_generation++;
@@ -1159,6 +1161,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
* remove and clean it up.
*/
if (!list_empty(&wdev->list)) {
+ nl80211_notify_iface(rdev, wdev,
+ NL80211_CMD_DEL_INTERFACE);
sysfs_remove_link(&dev->dev.kobj, "phy80211");
list_del_rcu(&wdev->list);
rdev->devlist_generation++;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 591c3ab..4fa7175 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2907,18 +2907,10 @@ static int nl80211_del_interface(struct sk_buff *skb, struct genl_info *info)
{
struct cfg80211_registered_device *rdev = info->user_ptr[0];
struct wireless_dev *wdev = info->user_ptr[1];
- struct sk_buff *msg;
- int status;
if (!rdev->ops->del_virtual_intf)
return -EOPNOTSUPP;
- msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
- if (msg && nl80211_send_iface(msg, 0, 0, 0, rdev, wdev, true) < 0) {
- nlmsg_free(msg);
- msg = NULL;
- }
-
/*
* If we remove a wireless device without a netdev then clear
* user_ptr[1] so that nl80211_post_doit won't dereference it
@@ -2929,15 +2921,7 @@ static int nl80211_del_interface(struct sk_buff *skb, struct genl_info *info)
if (!wdev->netdev)
info->user_ptr[1] = NULL;
- status = rdev_del_virtual_intf(rdev, wdev);
- if (status >= 0 && msg)
- genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy),
- msg, 0, NL80211_MCGRP_CONFIG,
- GFP_KERNEL);
- else
- nlmsg_free(msg);
-
- return status;
+ return rdev_del_virtual_intf(rdev, wdev);
}
static int nl80211_set_noack_map(struct sk_buff *skb, struct genl_info *info)
--
2.7.3
^ permalink raw reply related
* [PATCH v3 1/3] nl80211: Add nl80211_notify_iface
From: Denis Kenzior @ 2016-08-03 21:58 UTC (permalink / raw)
To: linux-wireless; +Cc: Denis Kenzior
In-Reply-To: <1470261515-2830-1-git-send-email-denkenz@gmail.com>
This function emits NL80211_CMD_NEW_INTERFACE or
NL80211_CMD_DEL_INTERFACE events. This is meant to be used by the core
to notify userspace applications such as wpa_supplicant when a netdev
related to a wireless device has been added or removed.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/nl80211.c | 28 ++++++++++++++++++++++++++++
net/wireless/nl80211.h | 3 +++
2 files changed, 31 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ac19eb8..c174770 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -11855,6 +11855,34 @@ void nl80211_notify_wiphy(struct cfg80211_registered_device *rdev,
NL80211_MCGRP_CONFIG, GFP_KERNEL);
}
+void nl80211_notify_iface(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev,
+ enum nl80211_commands cmd)
+{
+ struct sk_buff *msg;
+ bool removal;
+
+ WARN_ON(cmd != NL80211_CMD_NEW_INTERFACE &&
+ cmd != NL80211_CMD_DEL_INTERFACE);
+
+ if (cmd == NL80211_CMD_DEL_INTERFACE)
+ removal = true;
+ else
+ removal = false;
+
+ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (!msg)
+ return;
+
+ if (nl80211_send_iface(msg, 0, 0, 0, rdev, wdev, removal) < 0) {
+ nlmsg_free(msg);
+ return;
+ }
+
+ genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy), msg, 0,
+ NL80211_MCGRP_CONFIG, GFP_KERNEL);
+}
+
static int nl80211_add_scan_req(struct sk_buff *msg,
struct cfg80211_registered_device *rdev)
{
diff --git a/net/wireless/nl80211.h b/net/wireless/nl80211.h
index a63f402..6f6b73c 100644
--- a/net/wireless/nl80211.h
+++ b/net/wireless/nl80211.h
@@ -7,6 +7,9 @@ int nl80211_init(void);
void nl80211_exit(void);
void nl80211_notify_wiphy(struct cfg80211_registered_device *rdev,
enum nl80211_commands cmd);
+void nl80211_notify_iface(struct cfg80211_registered_device *rdev,
+ struct wireless_dev *wdev,
+ enum nl80211_commands cmd);
void nl80211_send_scan_start(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev);
struct sk_buff *nl80211_build_scan_msg(struct cfg80211_registered_device *rdev,
--
2.7.3
^ permalink raw reply related
* Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.
From: arvind Yadav @ 2016-08-03 13:55 UTC (permalink / raw)
To: Scott Wood, Arnd Bergmann, linuxppc-dev@lists.ozlabs.org
Cc: qiang.zhao@freescale.com, viresh.kumar@linaro.org,
zajec5@gmail.com, linux-wireless@vger.kernel.org,
David.Laight@aculab.com, netdev@vger.kernel.org,
scottwood@freescale.com, akpm@linux-foundation.org,
davem@davemloft.net, linux@roeck-us.net, Li Yang
In-Reply-To: <DB5PR0401MB1928DE1F195A57160DED735D91050@DB5PR0401MB1928.eurprd04.prod.outlook.com>
On Wednesday 03 August 2016 01:27 AM, Scott Wood wrote:
> On 08/02/2016 10:34 AM, arvind Yadav wrote:
>>
>> On Tuesday 02 August 2016 01:15 PM, Arnd Bergmann wrote:
>>> On Monday, August 1, 2016 4:55:43 PM CEST Scott Wood wrote:
>>>> On 08/01/2016 02:02 AM, Arnd Bergmann wrote:
>>>>>> diff --git a/include/linux/err.h b/include/linux/err.h
>>>>>> index 1e35588..c2a2789 100644
>>>>>> --- a/include/linux/err.h
>>>>>> +++ b/include/linux/err.h
>>>>>> @@ -18,7 +18,17 @@
>>>>>>
>>>>>> #ifndef __ASSEMBLY__
>>>>>>
>>>>>> -#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
>>>>>> +#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
>>>>>> +
>>>>>> +static inline int is_error_check(unsigned long error)
>>>>> Please leave the existing macro alone. I think you were looking for
>>>>> something specific to the return code of qe_muram_alloc() function,
>>>>> so please add a helper in that subsystem if you need it, not in
>>>>> the generic header files.
>>>> qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long. The
>>>> problem is certain callers that store the return value in a u32. Why
>>>> not just fix those callers to store it in unsigned long (at least until
>>>> error checking is done)?
>>>>
>>> Yes, that would also address another problem with code like
>>>
>>> kfree((void *)ugeth->tx_bd_ring_offset[i]);
>>>
>>> which is not 64-bit safe when tx_bd_ring_offset is a 32-bit value
>>> that also holds the return value of qe_muram_alloc.
> Well, hopefully it doesn't hold a return of qe_muram_alloc() when it's
> being passed to kfree()...
>
> There's also the code that casts kmalloc()'s return to u32, etc.
> ucc_geth is not 64-bit clean in general.
>
>>> Arnd
>> Yes, we will fix caller. Caller api is not safe on 64bit.
> The API is fine (or at least, I haven't seen a valid issue pointed out
> yet). The problem is the ucc_geth driver.
>
>> Even qe_muram_addr(a.k.a. cpm_muram_addr )passing value unsigned int,
>> but it should be unsigned long.
> cpm_muram_addr takes unsigned long as a parameter, not that it matters
> since you can't pass errors into it and a muram offset should never
> exceed 32 bits.
>
> -Scott
Yes, It will work for 32bit machine. But will not safe for 64bit.
Example :
ugeth->tx_bd_ring_offset[j] =
qe_muram_alloc(length UCC_GETH_TX_BD_RING_ALIGNMENT);
if (!IS_ERR_VALUE(ugeth->tx_bd_ring_offset[j]))
ugeth->p_tx_bd_ring[j] =
(u8 __iomem *) qe_muram_addr(ugeth-> tx_bd_ring_offset[j]);
If qe_muram_alloc will return any error, IS_ERR_VALUE will
always return 0 (IS_ERR_VALUE will always pass for 'unsigned int').
Now qe_muram_addr will return wrong virtual address. Which
can cause an error.
-Arvind
^ permalink raw reply
* Re: [PATCH] ath9k: fix GPIO mask for AR9462 and AR9565
From: Valo, Kalle @ 2016-08-03 13:54 UTC (permalink / raw)
To: Stefan Lippers-Hollmann, miaoqing@codeaurora.org
Cc: linux-wireless@vger.kernel.org, ath9k-devel,
sudipm.mukherjee@gmail.com
In-Reply-To: <20160717230519.46e3a661@mir>
Stefan Lippers-Hollmann <s.l-h@gmx.de> writes:
> Hi
>
> On 2016-06-03, miaoqing@codeaurora.org wrote:
>> From: Miaoqing Pan <miaoqing@codeaurora.org>
>>
>> The incorrect GPIO mask cause kernel warning, when AR9462 access GPIO11.
>> Also fix the mask for AR9565.
> [...]
>
> I think I'm seeing a very similar issue on AR5008/ AR5416+AR2133 and
> 4.7-rc7 (mainline v4.7-rc7-92-g47ef4ad, to be exact).
>
> [ 4.958874] ath9k 0000:02:02.0: enabling device (0000 -> 0002)
> [...]
> [ 5.401086] ------------[ cut here ]------------
> [ 5.401093] WARNING: CPU: 1 PID: 1159 at /build/linux-aptosid-4.7~rc7/drivers/net/wireless/ath/ath9k/hw.c:2776 ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw]
[...]
> Reverting this, and the other patches depending on it, fixes the
> problem for me:
>
> e024111f6946f45cf1559a8c6fd48d2d0f696d07 Revert "ath9k: fix GPIO mask for AR9462 and AR9565"
> db2221901fbded787daed153281ed875de489692 Revert "ath9k: free GPIO resource for SOC GPIOs"
> c7212b7136ba69efb9785df68b669381cb893920 Revert "ath9k: fix BTCoex configuration for SOC chips"
> dfcf02cd2998e2240b2bc7b4f4412578b8070bdb Revert "ath9k: fix BTCoex access invalid registers for SOC chips"
> 668ae0a3e48ac6811f431915b466514bf167e2f4 Revert "ath9k: add bits definition of BTCoex MODE2/3 for SOC chips"
> c8770bcf5cefa8cbfae21c07c4fe3428f5a9d42a Revert "ath9k: Allow platform override BTCoex pin"
> 79d4db1214a0c7b1818aaf64d0606b17ff1acea7 Revert "ath9k: cleanup led_pin initial"
> b2d70d4944c1789bc64376ad97a811f37e230c87 Revert "ath9k: make GPIO API to support both of WMAC and SOC"
> a01ab81b09c55025365c1de1345b941a18e05529 Revert "ath9k: define correct GPIO numbers and bits mask"
>
> AR9285 (168c:002b) is fine either way.
Miaoqing, have you looked at this? Looks like another regression which
should be fixed.
--
Kalle Valo
^ permalink raw reply
* Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
From: Christian Lamparter @ 2016-08-03 12:43 UTC (permalink / raw)
To: Alan Curry
Cc: Al Viro, alexmcwhirter, David Miller, chunkeey, linux-wireless,
netdev, linux-kernel
In-Reply-To: <201608030349.u733nRPn000595@sdf.org>
On Wednesday, August 3, 2016 3:49:26 AM CEST Alan Curry wrote:
> Al Viro wrote:
> >
> > Which just might mean that we have *three* issues here -
> > (1) buggered __copy_to_user_inatomic() (and friends) on some sparcs
> > (2) your ssl-only corruption
> > (3) Alan's x86_64 corruption on plain TCP read - no ssl *or* sparc
> > anywhere, and no multi-segment recvmsg(). Which would strongly argue in
> > favour of some kind of copy_page_to_iter() breakage triggered when handling
> > a fragmented skb, as in (1). Except that I don't see anything similar in
> > x86_64 uaccess primitives...
> >
>
> I think I've solved (3) at least...
>
> Using the twin weapons of printk and stubbornness, I have built a working
> theory of the bug. I haven't traced it all the way through, so my explanation
> may be partly wrong. I do have a patch that eliminates the symptom in all my
> tests though. Here's what happens:
>
> A corrupted packet somehow arrives in skb_copy_and_csum_datagram_msg().
> During downloads at reasonably high speed, about 0.1% of my incoming
> packets are bad. Probably because the access point is that suspicious
> Comcast thing.
Thanks for being very persistent with this. I think I'm able to reproduce
this now (on any hardware... like r8169 ethernet) as long as the following
"traffic policy" is enacted on the HTTP - Server:
# tc qdisc add dev eth0 root netem corrupt 0.1%
(This needs the "Network Emulation" Sched CONFIG_NET_SCH_NETEM [0].)
With your tool (changed to point to my apache local server). I'm seeing
corruptions in the "noselect" case. Running it in "select" mode however
and the resulting files have no corruptions.
About AR9170 corruption issues: I know of one report that the AR9170's
Encryption Engine can cause corruptions [1]. In this case outgoing
data was corrupted which lead to deauths/disassocs since the AP was
basically sending out multicast deauths/disassocs with bad addresses.
However, "nohwcrypt" should have made a difference there since the
software decryption would discard the faulty package due the message
integrety checks.
Another source for corruptions could be the USB-PHY (FUSB200) in the
AR9170 [2]. I know it's causing problems for the ath9k_htc. However
not everyone is affected.
One thing I noticed in your previous post is that you "might" not have
draft-802.11n enabled. Do you see any "disabling HT/VHT due to WEP/TKIP use."
in your dmesg logs? If so, check if you can force your AP to use WPA2
with CCMP/AES only.
Regards,
Christian
[0] <http://www.spinics.net/lists/linux-wireless/msg60104.html>
[1] <https://wiki.linuxfoundation.org/networking/netem>
[2] <https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues>
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Arend van Spriel @ 2016-08-03 11:43 UTC (permalink / raw)
To: Dmitry Torokhov, Luis R. Rodriguez
Cc: Daniel Wagner, Bjorn Andersson, Daniel Wagner, Bastien Nocera,
Greg Kroah-Hartman, Johannes Berg, Kalle Valo, Ohad Ben-Cohen,
Mimi Zohar, David Howells, Andy Lutomirski, David Woodhouse,
Julia Lawall, linux-input@vger.kernel.org, linux-kselftest,
linux-wireless, lkml
In-Reply-To: <CAKdAkRR=NC4Agen9ad3CK8hgZh+zbZhzhr2MP169JwisgWvP_w@mail.gmail.com>
On 03-08-16 09:42, Dmitry Torokhov wrote:
> On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
>>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
>>>> On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
>>>>>> The sysdata API's main goal rather is to provide a flexible API first,
>>>>>> compartamentalizing the usermode helper was secondary. But now it seems
>>>>>> I may just also add devm support too to help simplify code further.
>>>>>
>>>>> I missed the point that you plan to add usermode helper support to
>>>>> the sysdata API.
>>>>
>>>> I had no such plans, when I have asked folks so far about "hey are you
>>>> really in need for it, OK what for? " and "what extended uses do you
>>>> envision?" so I far I have not gotten any replies at all. So -- instead
>>>> sysdata currently ignores it.
>>>
>>> So you argue for the remoteproc use case with 100+ MB firmware that
>>> if there is a way to load after pivot_root() (or other additional
>>> firmware partition shows up) then there is no need at all for
>>> usermode helper?
>>
>> No, I'm saying I'd like to hear valid uses cases for the usermode helper and so
>> far I have only found using coccinelle grammar 2 explicit users, that's it. My
>> patch series (not yet merge) then annotates these as valid as I've verified
>> through their documentation they have some quirky requirement.
>
> In certain configurations (embedded) people do not want to use
> initramfs nor modules nor embed firmware into the kernel. In this case
> usermode helper + firmware calss timeout handling provides necessary
> wait for the root filesystem to be mounted.
And there are people who don't have a usermode helper running at all in
their configuration, but I guess they should disable the helper.
In my opinion the kernel should provide functionality to user-space and
user-space providing functionality to the kernel should be avoided.
> If we solve waiting for rootfs (or something else that may contain
> firmware) then these cases will not need to use usermode helper.
If firmware (or whatever) API could get notification of mount syscall it
could be used to retry firmware loading instead of periodic polling.
That leaves the question raised by you about when to stop trying. The
initlevel stuff is probably a user-space only concept, right? So no
ideas how the kernel itself could decide except for a "long" timeout.
Regards,
Arend
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Arend van Spriel @ 2016-08-03 11:33 UTC (permalink / raw)
To: Luis R. Rodriguez, Valo, Kalle
Cc: Stanislaw Gruszka, Prarit Bhargava, Greg Kroah-Hartman, Ming Lei,
linux-wireless, ath10k, mmarek@suse.com, michal.kazior@tieto.com,
Arend van Spriel, Emmanuel Grumbach
In-Reply-To: <20160802141610.GJ3296@wotan.suse.de>
On 02-08-16 16:16, Luis R. Rodriguez wrote:
> On Tue, Aug 02, 2016 at 11:10:22AM +0000, Valo, Kalle wrote:
>> "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
>>
>>> I was considering this as a future extension to the firmware API
>>> through the new extensible firmware API, the sysdata API.
>>
>> I think Linus mentioned this already, but I want to reiterate anyway.
>> The name "sysdata" is horrible, I didn't have any idea what it means
>> until I read your description. Please continue to use the term
>> "firmware", anyone already know what it means.
>
> We've gone well past using the firmware API for firmware though, if
> we use it for 802.11 to replace CRDA for instance its really odd to
> be calling it firmware. But sure... I will rebrand again to firmware...
I tend to agree. Although some people even call an OpenWrt image
firmware. Guess it is just in the eye of the beholder.
Regards,
Arend
^ permalink raw reply
* [bug report] NFC: nfcsim: Make use of the Digital layer
From: Dan Carpenter @ 2016-08-03 11:40 UTC (permalink / raw)
To: thierry.escande; +Cc: linux-wireless
Hello Thierry Escande,
The patch 204bddcb508f: "NFC: nfcsim: Make use of the Digital layer"
from Jun 23, 2016, leads to the following static checker warning:
drivers/nfc/nfcsim.c:485 nfcsim_init()
error: we previously assumed 'link0' could be null (see line 457)
drivers/nfc/nfcsim.c
450 static int __init nfcsim_init(void)
451 {
452 struct nfcsim_link *link0, *link1;
453 int rc;
454
455 link0 = nfcsim_link_new();
456 link1 = nfcsim_link_new();
457 if (!link0 || !link1) {
Say link0 is NULL here.
458 rc = -ENOMEM;
459 goto exit_err;
460 }
461
462 nfcsim_debugfs_init();
463
464 dev0 = nfcsim_device_new(link0, link1);
465 if (IS_ERR(dev0)) {
466 rc = PTR_ERR(dev0);
467 goto exit_err;
468 }
469
470 dev1 = nfcsim_device_new(link1, link0);
471 if (IS_ERR(dev1)) {
472 nfcsim_device_free(dev0);
473
474 rc = PTR_ERR(dev1);
475 goto exit_err;
476 }
477
478 pr_info("nfcsim " NFCSIM_VERSION " initialized\n");
479
480 return 0;
481
482 exit_err:
483 pr_err("Failed to initialize nfcsim driver (%d)\n", rc);
484
485 nfcsim_link_free(link0);
We oops inside the call to nfcsim_link_free().
486 nfcsim_link_free(link1);
487
488 return rc;
489 }
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/1 v2] rtlwifi: remove superfluous condition
From: Kalle Valo @ 2016-08-03 6:01 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Larry Finger, Chaoming Li, linux-wireless, netdev, linux-kernel
In-Reply-To: <1470165981-6241-1-git-send-email-xypron.glpk@gmx.de>
Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
> If sta == NULL, the changed line will not be reached.
> So no need to check that sta != NULL here.
>
> v2:
> fix typo
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
The change log goes under the "---" line so that git can automatically
strip it away while committing the patch. I can fix it this time but
please keep this in mind in the future.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC v2 0/3] Improve wireless netdev detection
From: Johannes Berg @ 2016-08-03 6:59 UTC (permalink / raw)
To: Denis Kenzior, linux-wireless
In-Reply-To: <1468044967-9236-1-git-send-email-denkenz@gmail.com>
On Sat, 2016-07-09 at 01:16 -0500, Denis Kenzior wrote:
> The current mechanism to detect hot-plug / unplug of wireless devices
> is
> somewhat arcane. One has to listen to NEW_WIPHY/DEL_WIPHY events
> over
> nl80211 as well as RTM_NEWLINK / RTM_DELLINK events over rtnl, then
> somehow find a correlation between these events. This involves
> userspace
> sending GET_INTERFACE or GET_WIPHY commands to the kernel, which
> incurs
> additional roundtrips.
>
> This patch series proposes that NEW_INTERFACE and DEL_INTERFACE
> events are
> always emitted, regardless of whether a netdev was added/removed by
> the
> driver or explicitly via NEW_INTERFACE/DEL_INTERFACE commands.
>
> v2: Squished patches 2+3, 4+5. DEL_INTERFACE event notification is
> now
> sent inside cfg80211_unregister_wdev instead of
> nl80211_del_interface.
>
Looks fine to me, care to resend as [PATCH]?
johannes
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Dmitry Torokhov @ 2016-08-03 7:42 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Daniel Wagner, Arend van Spriel, Bjorn Andersson, Daniel Wagner,
Bastien Nocera, Greg Kroah-Hartman, Johannes Berg, Kalle Valo,
Ohad Ben-Cohen, Mimi Zohar, David Howells, Andy Lutomirski,
David Woodhouse, Julia Lawall, linux-input@vger.kernel.org,
linux-kselftest, linux-wireless, lkml
In-Reply-To: <20160802074106.GI3296@wotan.suse.de>
On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
>> >On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
>> >>>The sysdata API's main goal rather is to provide a flexible API first,
>> >>>compartamentalizing the usermode helper was secondary. But now it seems
>> >>>I may just also add devm support too to help simplify code further.
>> >>
>> >>I missed the point that you plan to add usermode helper support to
>> >>the sysdata API.
>> >
>> >I had no such plans, when I have asked folks so far about "hey are you
>> >really in need for it, OK what for? " and "what extended uses do you
>> >envision?" so I far I have not gotten any replies at all. So -- instead
>> >sysdata currently ignores it.
>>
>> So you argue for the remoteproc use case with 100+ MB firmware that
>> if there is a way to load after pivot_root() (or other additional
>> firmware partition shows up) then there is no need at all for
>> usermode helper?
>
> No, I'm saying I'd like to hear valid uses cases for the usermode helper and so
> far I have only found using coccinelle grammar 2 explicit users, that's it. My
> patch series (not yet merge) then annotates these as valid as I've verified
> through their documentation they have some quirky requirement.
In certain configurations (embedded) people do not want to use
initramfs nor modules nor embed firmware into the kernel. In this case
usermode helper + firmware calss timeout handling provides necessary
wait for the root filesystem to be mounted.
If we solve waiting for rootfs (or something else that may contain
firmware) then these cases will not need to use usermode helper.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] ath10k: Allow setting coverage class
From: Michal Kazior @ 2016-08-03 7:09 UTC (permalink / raw)
To: Ben Greear
Cc: Benjamin Berg, Kalle Valo, linux-wireless, Mathias Kretschmer,
Sebastian Gottschall, ath10k@lists.infradead.org,
Simon Wunderlich
In-Reply-To: <579B71B4.7080206@candelatech.com>
On 29 July 2016 at 17:09, Ben Greear <greearb@candelatech.com> wrote:
> On 07/29/2016 07:52 AM, Benjamin Berg wrote:
[...]
>> Yeah, I am aware of the fact that the firmware may do internal resets
>> from time to time. The interesting question (and one for which I do not
>> know the answer) is whether we get a wmi or other event under all
>> conditions where the register may be rewritten due to a reset.
>>
>> The current code will re-set the register value after any wmi event
>> including debug messages. If this is not enough, then the only solution
>> might be to periodically poll the register values instead of relying on
>> a received event.
>
> You will get a dbglog event at least most of the time, so maybe that
> will be good enough.
But you need to remember you need to enable dbglog first to get these
events. I guess when coverage class is set the driver could,
internally, override dbglog mask so that these events are guaranteed
to be reported for the purpose of properly refreshing registers on
channel programming.
At that point I guess the update hook could be just placed in dbglog
handler alone instead of all over wmi_rx variants.
Michał
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Daniel Wagner @ 2016-08-03 6:57 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Dmitry Torokhov, Arend van Spriel, Bjorn Andersson, Daniel Wagner,
Bastien Nocera, Greg Kroah-Hartman, Johannes Berg, Kalle Valo,
Ohad Ben-Cohen, Mimi Zohar, David Howells, Andy Lutomirski,
David Woodhouse, Julia Lawall, linux-input, linux-kselftest,
linux-wireless, linux-kernel
In-Reply-To: <20160802074106.GI3296@wotan.suse.de>
On 08/02/2016 09:41 AM, Luis R. Rodriguez wrote:
> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
>>> On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
>> So you argue for the remoteproc use case with 100+ MB firmware that
>> if there is a way to load after pivot_root() (or other additional
>> firmware partition shows up) then there is no need at all for
>> usermode helper?
>
> No, I'm saying I'd like to hear valid uses cases for the usermode helper and so
> far I have only found using coccinelle grammar 2 explicit users, that's it. My
> patch series (not yet merge) then annotates these as valid as I've verified
> through their documentation they have some quirky requirement.
I got that question wrong. It should read something like 'for the
remoteproc 100+MB there is no need for the user help?'. I've gone
through your patches and they make perfectly sense too. Maybe I can
convince you to take a better version of my patch 3 into your queue. And
I help you converting the exiting drivers. Obviously if you like my help
at all.
> Other than these two drivers I'd like hear to valid requirements for it.
>
> The existential issue is a real issue but it does not look impossible to
> resolve. It may be a solution to bloat up the kernel with 100+ MB size just to
> stuff built-in firmware to avoid this issue, but it does not mean a solution
> is not possible.
>
> Remind me -- why can remoteproc not stuff the firmware in initramfs ?
I don't know. I was just bringing it up with the hope that Bjorn will
defend it. It seems my tactics didn't work out :)
> Anyway, here's a simple suggestion: fs/exec.c gets a sentinel file monitor
> support per enum kernel_read_file_id. For instance we'd have one for
> READING_FIRMWARE, one for READING_KEXEC_IMAGE, perhaps READING_POLICY, and this
> would in turn be used as the system configurable deterministic file for
> which to wait for to be present before enabling each enum kernel_read_file_id
> type read.
>
> Thoughts ?
Not sure if I get you here correctly. Is the 'system configurable
deterministic file' is a knob which controlled by user space? Or it this
something you define at compile time?
Hmm, so it would allow to decided to ask a userspace helper or load the
firmware directly (to be more precised the kernel_read_file_id type). If
yes, than it is what currently already have just integrated nicely into
the new sysdata API.
cheers,
daniel
^ permalink raw reply
* Re: [PATCH v2] mac80211: End the MPSP even if EOSP frame was not acked
From: Johannes Berg @ 2016-08-03 6:56 UTC (permalink / raw)
To: Masashi Honma; +Cc: linux-wireless, j, me
In-Reply-To: <1470125817-4461-1-git-send-email-masashi.honma@gmail.com>
On Tue, 2016-08-02 at 17:16 +0900, Masashi Honma wrote:
> If QoS frame with EOSP (end of service period) subfield=1 sent by
> local
> peer was not acked by remote peer, local peer did not end the MPSP.
> This
> prevents local peer from going to DOZE state. And if the remote peer
> goes away without closing connection, local peer continues AWAKE
> state
> and wastes battery.
>
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix purging multicast PS buffer queue
From: Johannes Berg @ 2016-08-03 6:54 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless
In-Reply-To: <20160802091341.64330-1-nbd@nbd.name>
On Tue, 2016-08-02 at 11:13 +0200, Felix Fietkau wrote:
> The code currently assumes that buffered multicast PS frames don't
> have
> a pending ACK frame for tx status reporting.
> However, hostapd sends a broadcast deauth frame on teardown for which
> tx
> status is requested. This can lead to the "Have pending ack frames"
> warning on module reload.
> Fix this by using ieee80211_free_txskb/ieee80211_purge_tx_queue.
>
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH v2] nl80211: Receive correct value for NL80211_MESHCONF_HT_OPMODE command
From: Johannes Berg @ 2016-08-03 6:52 UTC (permalink / raw)
To: Masashi Honma; +Cc: linux-wireless, j, me
In-Reply-To: <9967cc0f-777e-31f6-0c4a-a788e92b9049@gmail.com>
> This patch could over write cfg->ht_opmode even though EINVAL.
> I will modify this.
>
Don't think that actually matters since then it shouldn't be used, but
the v3 patch looks good.
I'm not sure we should bother to do cross-setting validation? Like, I
mean, validating that non-GF and non-HT aren't set together, etc. Those
are somewhat nonsense configurations, but we can't prevent them all.
I'm actually half thinking that we could just remove all restrictions
on this and allow any u16 value of this field, and rely on
wpa_supplicant to do the right thing... Then we don't have to update
this if we ever want to do something new either.
What do you think? What does the validation actually help us with?
johannes
^ permalink raw reply
* Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Johannes Berg @ 2016-08-03 6:50 UTC (permalink / raw)
To: Masashi Honma
Cc: Yaniv Machani, linux-kernel, Meirav Kama, David S. Miller,
linux-wireless, netdev
In-Reply-To: <bb69b031-53ad-4649-bd1d-e95ca7a0cc70@gmail.com>
On Wed, 2016-08-03 at 11:51 +0900, Masashi Honma wrote:
> On 2016年08月02日 16:27, Johannes Berg wrote:
> > This explicitly configures *HT capability* though - that's even the
> > name of the parameter. If you enable HT40 in the capability, the
> > resulting BSS might still not actually *use* 40 MHz bandwidth, as
> > required by overlapping BSS detection.
>
> OK, I see.
>
> HT Capabilities element = Defined by hardware and software spec of
> the node. So it does not be modified after boot.
It shouldn't really need to be modified, but perhaps for
interoperability reasons one might want to, like for example we do in
assoc request (we restrict our own capabilities to what the AP
supports, because some APs are stupid.)
That said, I'm basically only objecting to calling this a bugfix. If
the behaviour of restricting the information is desired, I see no real
problem with that, I just don't see how it could possibly be a bugfix.
> HT Operation element = Defined by surrounding environment and
> configuration of the node. So it could be modified after boot.
>
> So, if the node supports HT40, HT Capabilities shows HT40 is capable.
> Now, I understand why you rejected this patch.
>
> But now, when disable_ht=1, no HT Capabilities element in beacon even
> though the node supports HT.
>
> My trailing patch could solve the issue.
Actually, *this* one I'm not sure is correct. If you want to disable HT
completely, then HT operation can't actually indicate that, and having
HT capabilities without HT operation would likely just confuse peers,
so I think in this case it's quite possibly necessary to remove HT
capabilities.
johannes
^ 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