Re: [PATCH] ath9k_hw: fix channel maximum power level test

On 22 March 2017 at 15:42, Felix Fietkau wrote: > The tx power applied by set_txpower is limited by the CTL (conformance > test limit) entries in the EEPROM. These can change based on the user > configured regulatory domain. > Depending on the EEPROM data this can cause the tx

[PATCH] staging: wilc1000: fix incorrect strncasecmp length

From: Colin Ian King The strncasecmp of buff against the literal string RSSI is using variable length which is zero. This should be instead using the variable size instead. Also remove the redundant variable length. Detected by PVS-Studio, warning: V575

Re: brcmfmac: don't warn user if requested nvram fails

On 6-4-2017 14:14, Hans de Goede wrote: > Hi, > > I noticed your patch-series on the lwn.net kernel page, > and I took a peek :) > > I don't think that this patch: > >

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 12:55 -0700, David Miller wrote: > > One idea.  We use the macro thing to generate a "netlink.pot" file > and then some userland tree can contain the latest netlink.pot and > the translations. Right. For the record - since we just talked about it - I was thinking of putting

Re: [RFC 0/3] netlink: extended error reporting

From: Johannes Berg Date: Fri, 07 Apr 2017 21:46:46 +0200 > On Fri, 2017-04-07 at 12:43 -0700, David Miller wrote: >> I suspect that someone will eventually give us a hard time about the >> strings wrt. internationalization. :-) It's solvable at least >> partially in

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:45 +0200, Pablo Neira Ayuso wrote: > > We only need to store the pointer to the attribute in the error > container structure. We can calculate the offset from nl_err() by > pasing the skbuff as parameter there, right? Ah, that's a good point, we could store the nlattr

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 12:43 -0700, David Miller wrote: > > I have no strong opinions about string length. > > In my opinion, I would like to believe that if someone tried to get a > networking patch applied that emitted a rediculously long string then > we would give them feedback about how that

Re: [RFC 0/3] netlink: extended error reporting

On Fri, Apr 07, 2017 at 09:29:17PM +0200, Johannes Berg wrote: > On Fri, 2017-04-07 at 21:21 +0200, Pablo Neira Ayuso wrote: > > I think the most flexible way is to pass the container error > > structure to nla_parse() so it sets this for you. This would also > > save tons of "malformed attribute"

[RFC] netlink: send exterr cookie on success

From: Johannes Berg This is for Jamal, it allows the subsystem to return an arbitrary cookie to identify a new object/operation, perhaps to delete or cancel it later. This is actually something we use a lot in wifi too, though I'm not sure how we could do the backport

Re: [RFC 0/3] netlink: extended error reporting

From: Pablo Neira Ayuso Date: Fri, 7 Apr 2017 21:35:50 +0200 > On Fri, Apr 07, 2017 at 12:20:53PM -0700, David Miller wrote: > [...] >> Let's just discuss the UAPI, since people complain we don't talk >> about that enough :-) For those playing at home it is three new >>

Re: [RFC 1/3] netlink: extended error reporting

On Fri, 2017-04-07 at 20:26 +0200, Johannes Berg wrote: > > + if (nlk->flags & NETLINK_F_EXT_ACK) { > + if (exterr && exterr->msg) > + WARN_ON(nla_put_string(skb, > NLMSGERR_ATTR_MSG, > +    exterr->msg)); > +

Re: [RFC 0/3] netlink: extended error reporting

On Fri, Apr 07, 2017 at 12:20:53PM -0700, David Miller wrote: [...] > Let's just discuss the UAPI, since people complain we don't talk > about that enough :-) For those playing at home it is three new > attributes returned in a netlink ACK when the application asks > for the extended response: >

Re: [RFC 0/3] netlink: extended error reporting

From: Pablo Neira Ayuso Date: Fri, 7 Apr 2017 21:21:34 +0200 > For my usecases in netfilter, the attributes and an specific error > code should be enough to figure out what is wrong. Will not need > strings. > > BTW, we may not have an offset, eg. EINVAL because of missing

Re: [RFC 0/3] netlink: extended error reporting

From: Pablo Neira Ayuso Date: Fri, 7 Apr 2017 21:27:14 +0200 > On Fri, Apr 07, 2017 at 12:22:23PM -0700, David Miller wrote: >> From: Johannes Berg >> Date: Fri, 07 Apr 2017 21:09:45 +0200 >> >> > On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:27 +0200, Pablo Neira Ayuso wrote: > > > Also another way to look at this is that we're providing a lot of > > new power and expressability.  So even if only one aspect of the > > new error reporting is used it's a positive step forward. True. > > So allow offset "0"

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:21 +0200, Pablo Neira Ayuso wrote: > > For my usecases in netfilter, the attributes and an specific error > code should be enough to figure out what is wrong. Will not need > strings. Fair enough. > BTW, we may not have an offset, eg. EINVAL because of missing >

Re: [RFC 0/3] netlink: extended error reporting

On Fri, Apr 07, 2017 at 12:22:23PM -0700, David Miller wrote: > From: Johannes Berg > Date: Fri, 07 Apr 2017 21:09:45 +0200 > > > On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote: > >> On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote: > >> [...]

Re: [RFC 2/3] genetlink: pass extended error report down

On 04/07/2017 12:12 PM, Johannes Berg wrote: On Fri, 2017-04-07 at 11:37 -0700, Ben Greear wrote: I guess the error string must be constant and always available in memory in this implementation? Yes. I think it would be nice to dynamically create strings (malloc, snprintf, etc) and have

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 12:20 -0700, David Miller wrote: > But what it lacks fundamentally is context.  Therefore it can't be > used to provide the offset or the bad attribute number.  So it can't > meet our requirements. Yes, it doesn't address the requirements here, and in a sense I suspect this

Re: [RFC 0/3] netlink: extended error reporting

From: Johannes Berg Date: Fri, 07 Apr 2017 21:09:45 +0200 > On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote: >> On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote: >> [...] >> > Heh. I think I really want to solve - at least partially - >> >

Re: [RFC 0/3] netlink: extended error reporting

On Fri, Apr 07, 2017 at 09:09:45PM +0200, Johannes Berg wrote: > On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote: > > On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote: > > [...] > > > Heh. I think I really want to solve - at least partially - > > > nla_parse() > > > to see

Re: [RFC 0/3] netlink: extended error reporting

From: Johannes Berg Date: Fri, 07 Apr 2017 20:59:12 +0200 > Alexander Shishkin's patch > https://patchwork.kernel.org/patch/7162421/ > > was nice in a way because you could get away without passing the error > structure down all the time, but like I said it doesn't

Re: [RFC 2/3] genetlink: pass extended error report down

On Fri, 2017-04-07 at 11:37 -0700, Ben Greear wrote: > > I guess the error string must be constant and always available in > memory in this implementation? Yes. > I think it would be nice to dynamically create strings (malloc, > snprintf, etc) and have the err_str logic free it when done? We

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote: > On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote: > [...] > > Heh. I think I really want to solve - at least partially - > > nla_parse() > > to see that it can be done this way. It'd be nice to even transform > > all > >

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 21:02 +0200, Pablo Neira Ayuso wrote: > > > I'm tempted to apply this as-is just to show that person that > > things do in fact happen eventually :-) > > We can just send follow up patches to refine, I think it's a good > start, Johannes? I guess we can. Like I just

Re: [RFC 0/3] netlink: extended error reporting

On Fri, Apr 07, 2017 at 11:53:15AM -0700, David Miller wrote: > From: Johannes Berg > Date: Fri, 7 Apr 2017 20:26:17 +0200 > > > So this is my first draft of what we'd talked about at netconf. > > I'm not super happy with the way we have to pass the extended > > error

Re: [RFC 0/3] netlink: extended error reporting

On Fri, 2017-04-07 at 11:53 -0700, David Miller wrote: > > Alexander Shishkin had a nice way of reporting static extended > > error data, but that isn't really suitable for reporting the > > offset or even reporting the broken attribute from nla_parse(). > >  > > Speaking of nla_parse(), that'll

Re: [RFC 0/3] netlink: extended error reporting

From: Johannes Berg Date: Fri, 7 Apr 2017 20:26:17 +0200 > So this is my first draft of what we'd talked about at netconf. > I'm not super happy with the way we have to pass the extended > error struct, but I don't see a way to implement reporting any > dynamic

Re: [RFC 2/3] genetlink: pass extended error report down

On 04/07/2017 11:26 AM, Johannes Berg wrote: From: Johannes Berg Signed-off-by: Johannes Berg --- include/net/genetlink.h | 27 +++ net/netlink/genetlink.c | 6 -- 2 files changed, 31 insertions(+), 2 deletions(-)

[RFC 2/3] genetlink: pass extended error report down

From: Johannes Berg Signed-off-by: Johannes Berg --- include/net/genetlink.h | 27 +++ net/netlink/genetlink.c | 6 -- 2 files changed, 31 insertions(+), 2 deletions(-) diff --git a/include/net/genetlink.h

[RFC 0/3] netlink: extended error reporting

So this is my first draft of what we'd talked about at netconf. I'm not super happy with the way we have to pass the extended error struct, but I don't see a way to implement reporting any dynamic information (like error offsets) in any other way. Alexander Shishkin had a nice way of reporting

[RFC 3/3] nl80211: add a few extended error strings

From: Johannes Berg Signed-off-by: Johannes Berg --- net/wireless/nl80211.c | 33 ++--- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index

[RFC 1/3] netlink: extended error reporting

From: Johannes Berg Signed-off-by: Johannes Berg --- crypto/crypto_user.c | 3 +- drivers/infiniband/core/netlink.c | 3 +- drivers/scsi/scsi_netlink.c | 2 +- include/linux/netlink.h | 10 ++-

Re: [PATCH v2 2/4] mwifiex: fall back mwifiex_dbg to pr_info when adapter->dev not set

Hi Xinming, On Fri, Apr 7, 2017 at 3:51 AM, Xinming Hu wrote: > From: Xinming Hu > > mwifiex_dbg will do nothing before adapter->dev get assigned. several logs > lost in this case. it can be avoided by fall back to pr_info. > > Signed-off-by: Xinming Hu

pull-request: wireless-drivers-next 2017-04-07

Hi Dave, here's a pull request for net-next, more info in the signed tag below. Please let me know if there are any problems. Kalle The following changes since commit 9c28286b1b4b9bce6e35dd4c8a1265f03802a89a: decnet: Use TCP nagle macro instead of literal number in decnet (2017-03-07

[PATCH] staging: wilc1000: Fix problem with wrong vif index

The vif->idx value is always 0 for two interfaces. wl->vif_num = 0; loop { ... vif->idx = wl->vif_num; ... wl->vif_num = i; i++; ... } At present, vif->idx is assigned the value of wl->vif_num at the beginning of this block and device is initialized

[PATCH] staging: wilc1000: Update handler assignment logic

With this update, the host driver is consistent with the implementation on the firmware side with respect to obtaining the driver handler for all modes. With this new format, the calls to set the wilc operation mode is simplified. Signed-off-by: Aditya Shankar ---

[PATCH] staging: wilc1000: Use new format for configuring firmware

The configuration packet format has changed in the newer wilc firmware versions 14.2 and up. This update ensures that the firmware is initialized correctly by the host and configured in the required mode. Signed-off-by: Aditya Shankar ---

[PATCH v2 4/4] mwifiex: pcie: extract wifi part from combo firmware during function level reset

From: Xinming Hu A seperate wifi-only firmware was download during pcie function level reset. It is in fact the tail part of wifi/bt combo firmware. Per Brian's and Dmitry's suggestion, this patch extract the wifi part from combo firmware. After that, we can discard the

[PATCH v2 2/4] mwifiex: fall back mwifiex_dbg to pr_info when adapter->dev not set

From: Xinming Hu mwifiex_dbg will do nothing before adapter->dev get assigned. several logs lost in this case. it can be avoided by fall back to pr_info. Signed-off-by: Xinming Hu --- v2: enhance adapter->dev null case.(Brain) ---

[PATCH v2 1/4] mwifiex: remove unnecessary wakeup interrupt number sanity check

From: Xinming Hu If wakeup interrupt handler is called, we know that the wakeup interrupt number is valid, there is no need to check it. Signed-off-by: Xinming Hu Signed-off-by: Cathy Luo Reviewed-by: Dmitry Torokhov

[PATCH v2 3/4] mwifiex: pcie: correct scratch register name

From: Xinming Hu This patch correct pcie scratch register name, to keep the same with chipset side definition. Signed-off-by: Xinming Hu --- v2: code clean and prepare for next patch 4/4 --- drivers/net/wireless/marvell/mwifiex/pcie.c | 4 ++--

Re: [PATCH 00/10] cfg80211: support multiple scheduled scans

On 7-4-2017 11:23, Arend van Spriel wrote: > After the RFC rounds here is multi-scheduled scan submission. What > has been added since the RFC is support for user-space to specify a > BSSID in the matchset (PATCH 3/10). As example this could be used for > roaming algorithm done in user-space. The

[PATCH 01/10] nl80211: add request id in scheduled scan event messages

For multi-scheduled scan support in subsequent patch a request id will be added. This patch add this request id to the scheduled scan event messages. For now the request id will always be zero. With multi-scheduled scan its value will inform user-space to which scan the event relates.

[PATCH 05/10] cfg80211: add request id to cfg80211_sched_scan_*() api

Have proper request id filled in the SCHED_SCAN_RESULTS and SCHED_SCAN_STOPPED notifications toward user-space by having the driver provide it through the api. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts

[PATCH 08/10] brcmfmac: add support multi-scheduled scan

This change adds support for multi-scheduled scan in the driver. It currently relies on g-scan support in firmware and will set struct wiphy::max_sched_scan_reqs accordingly. This is limited to 16 concurrent requests. The firmware currently has a limit of 64 channels that can be configured for

[PATCH 00/10] cfg80211: support multiple scheduled scans

After the RFC rounds here is multi-scheduled scan submission. What has been added since the RFC is support for user-space to specify a BSSID in the matchset (PATCH 3/10). As example this could be used for roaming algorithm done in user-space. The patches for scheduled scan notification api have

[PATCH 06/10] brcmfmac: add firmware feature detection for gscan feature

From: Arend van Spriel Detect gscan support in firmware by doing pfn_gscan_cfg iovar with invalid version. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin

[PATCH 04/10] cfg80211: add request id parameter to .sched_scan_stop() signature

For multiple scheduled scan support the driver needs to know which scheduled scan request is being stopped. Pass the request id in the .sched_scan_stop() callback. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts

[PATCH 03/10] nl80211: add support for BSSIDs in scheduled scan matchsets

This patch allows for the scheduled scan request to specify matchsets for specific BSSIDs. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van

[PATCH 10/10] brcmfmac: add scheduled scan support for specified BSSIDs

Add support to handle scheduled scan request containing BSSID in the matchsets. The firmware can send event upon finding BSSIDs and SSIDs. To get these in one event the bit REPORT_SEPERATELY needed to be removed from the flags in brcmf_pno_config(). Reviewed-by: Hante Meuleman

[PATCH 07/10] brcmfmac: move scheduled scan wiphy param setting to pno module

As pno module is providing scheduled scan functionality have it taking care of setting related wiphy parameters as well. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin

[PATCH 02/10] nl80211: allow multiple active scheduled scan requests

This patch implements the idea to have multiple scheduled scan requests running concurrently. It mainly illustrates how to deal with the incoming request from user-space in terms of backward compatibility. In order to use multiple scheduled scans user-space needs to provide a flag attribute

Re: [PATCH] nfc: fix get_unaligned_...() misuses

Hi Al, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc5 next-20170406] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Al-Viro/nfc-fix-get_unaligned_-misuses/20170407

Re: [PATCH] nfc: fix get_unaligned_...() misuses

Hi Al, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc5 next-20170406] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Al-Viro/nfc-fix-get_unaligned_-misuses/20170407