Re: [PATCH v2 0/6] wl1251: Fix MAC address for Nokia N900

[Luis R. Rodriguez]

On Tue, Jan 02, 2018 at 08:23:45PM +0100, Pali Rohár wrote:
> On Friday 10 November 2017 00:38:22 Pali Rohár wrote:
> > This patch series fix processing MAC address for wl1251 chip found in Nokia 
> > N900.
> > 
> > Changes since v1:
> > * Added Acked-by for Pavel Machek
> > * Fixed grammar
> > * Magic numbers for NVS offsets are replaced by defines
> > * Check for validity of mac address NVS data is moved into function
> > * Changed order of patches as Pavel requested
> > 
> > Pali Rohár (6):
> >   wl1251: Update wl->nvs_len after wl->nvs is valid
> >   wl1251: Generate random MAC address only if driver does not have
> > valid
> >   wl1251: Parse and use MAC address from supplied NVS data
> >   wl1251: Set generated MAC address back to NVS data
> >   firmware: Add request_firmware_prefer_user() function
> >   wl1251: Use request_firmware_prefer_user() for loading NVS
> > calibration data
> > 
> >  drivers/base/firmware_class.c  |   45 +-
> >  drivers/net/wireless/ti/wl1251/Kconfig |1 +
> >  drivers/net/wireless/ti/wl1251/main.c  |  104 
> > ++--
> >  include/linux/firmware.h   |9 +++
> >  4 files changed, 138 insertions(+), 21 deletions(-)
> 
> Hi! Are there any comments for first 4 patches? If not, could they be
> accepted and merged?

Since the first 4 patches do not touch the firmware API they seem fine to me so
long as the maintainer accepts them. Maybe resend and clarify you have dropped
the other ones and amend with the new tags.

  Luis

Re: [PATCH v2 1/3] cfg80211/nl80211: Optional authentication offload to userspace

[Denis Kenzior]

Hi Jouni, Johannes,

> + *	User space uses the %NL80211_CMD_CONNECT command to the host 
driver for

+ * triggering a connection. The host driver selects a BSS and further uses
+ * this interface to offload only the authentication part to the user
+ * space. Authentication frames are passed between the driver and user
+ * space through the %NL80211_CMD_FRAME interface. The status of


So this implies userspace must pre-register for authentication 
management frames, correct?  And other applications could register to 
receive these frames as well?  Would it not be easier (and more secure) 
to simply forward these directly to the application that triggered 
CMD_CONNECT instead?



+ * authentication is further indicated by user space to the host driver
+ * with the %NL80211_CMD_EXTERNAL_AUTH command through
+ * %NL80211_ATTR_STATUS_CODE attribute. This enables the driver to proceed
+ * with association on successful authentication. Driver shall use this
+ * %NL80211_ATTR_STATUS_CODE attribute to report the connect result to
+ * user space on an authentication failure.
+ *
   * @NL80211_CMD_MAX: highest used command number
   * @__NL80211_CMD_AFTER_LAST: internal use
   */




  
+int cfg80211_external_auth_request(struct net_device *dev,

+  struct cfg80211_external_auth_params *params,
+  gfp_t gfp)
+{
+   struct wireless_dev *wdev = dev->ieee80211_ptr;
+   struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy);
+   struct sk_buff *msg;
+   void *hdr;
+
+   msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
+   if (!msg)
+   return -ENOMEM;
+
+   hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_EXTERNAL_AUTH);
+   if (!hdr) {
+   nlmsg_free(msg);
+   return -ENOMEM;
+   }
+
+   if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) ||
+   nla_put_u32(msg, NL80211_ATTR_IFINDEX, dev->ifindex) ||
+   nla_put_u32(msg, NL80211_ATTR_AKM_SUITES, params->key_mgmt_suite) ||
+   nla_put_u32(msg, NL80211_ATTR_EXTERNAL_AUTH_ACTION,
+   params->action) ||
+   nla_put(msg, NL80211_ATTR_BSSID, ETH_ALEN, params->bssid) ||
+   nla_put(msg, NL80211_ATTR_SSID, params->ssid.ssid_len,
+   params->ssid.ssid))
+   goto nla_put_failure;
+
+   genlmsg_end(msg, hdr);
+
+   genlmsg_multicast_netns(_fam, wiphy_net(>wiphy), msg, 0,
+   NL80211_MCGRP_MLME, gfp);


Is there a reason this is being multicast and not unicast to the 
application that triggered the CONNECT?  Who else besides the supplicant 
daemon might find this information useful?



+   return 0;
+
+ nla_put_failure:
+   genlmsg_cancel(msg, hdr);
+   nlmsg_free(msg);
+   return -ENOBUFS;
+}
+EXPORT_SYMBOL(cfg80211_external_auth_request);
+
  /* initialisation/exit functions */
  
  int __init nl80211_init(void)


Regards,
-Denis

Re: [PATCH][V2] wcn36xx: fix incorrect assignment to msg_body.min_ch_time

[Bjorn Andersson]

On Fri 29 Dec 01:07 PST 2017, Colin King wrote:

> From: Colin Ian King 
> 
> The second assignment to msg_body.min_ch_time is incorrect, it
> should actually be to msg_body.max_ch_time.
> 
> Thanks to Bjorn Andersson for identifying the correct way to fix
> this as my original fix was incorrect.
> 
> Detected by CoverityScan, CID#1463042 ("Unused Value")
> 
> Fixes: 2f3bef4b247e ("wcn36xx: Add hardware scan offload support")
> Signed-off-by: Colin Ian King 

Thanks Colin,

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/net/wireless/ath/wcn36xx/smd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
> b/drivers/net/wireless/ath/wcn36xx/smd.c
> index 2914618a0335..2a4871ca9c72 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -626,7 +626,7 @@ int wcn36xx_smd_start_hw_scan(struct wcn36xx *wcn, struct 
> ieee80211_vif *vif,
>  
>   msg_body.scan_type = WCN36XX_HAL_SCAN_TYPE_ACTIVE;
>   msg_body.min_ch_time = 30;
> - msg_body.min_ch_time = 100;
> + msg_body.max_ch_time = 100;
>   msg_body.scan_hidden = 1;
>   memcpy(msg_body.mac, vif->addr, ETH_ALEN);
>   msg_body.p2p_search = vif->p2p;
> -- 
> 2.14.1
> 

Re: [v2] wcn36xx: Fix dynamic power saving

[Kalle Valo]

Loic Poulain  wrote:

> Since driver does not report hardware dynamic power saving cap,
> this is up to the mac80211 to manage power saving timeout and
> state machine, using the ieee80211 config callback to report
> PS changes. This patch enables/disables PS mode according to
> the new configuration.
> 
> Remove old behaviour enabling PS mode in a static way, this make
> the device unusable when power save is enabled since device is
> forced to PS regardless RX/TX traffic.
> 
> Acked-by: Bjorn Andersson 
> Signed-off-by: Loic Poulain 
> Signed-off-by: Kalle Valo 

Patch applied to ath-current branch of ath.git, thanks.

0856655a2547 wcn36xx: Fix dynamic power saving

-- 
https://patchwork.kernel.org/patch/10104441/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Business Possibility

[Peter Deng]

Hello there, My name is Peter Deng a South African citizen and a friend to Mrs 
Mugabe sister . I got your contact through Korean business online directory. I 
represent the interest of Mrs Mugabe who wishes to move a total amount of $19 
million  into a safe account owns by a trusted business man who is capable of 
accommodating such volume of funds with absolute trust & confidentiality.

We are willing to give 5-10 percent of the total money for this efforts . A non 
disclosure non circumvent agreement will be signed before the eventual transfer 
of funds. It is important for to know that the fund owner is going through a 
period of political turmoil and she is in a precarious position, so this 
transaction has to be highly secretive & very confidential.

Kindly respond back to me if this is what you can handle .

Regards,

Peter.

Re: pull-request: mac80211 2018-01-04

[David Miller]

From: Johannes Berg 
Date: Thu,  4 Jan 2018 15:56:31 +0100

> It's probably getting quite late for the current cycle, but
> these fixes seemed important enough to send them to you
> separately anyway.
> 
> Please pull and let me know if there's any problem.

Sure, no problem, pulled.

Re: [PATCH v4 31/36] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

[Thomas Gleixner]

On Thu, 4 Jan 2018, Johannes Berg wrote:

> On Thu, 2017-12-21 at 11:42 +0100, Anna-Maria Gleixner wrote:
> > From: Thomas Gleixner 
> > 
> > Switch the timer to HRTIMER_MODE_SOFT, which executed the timer
> 
> I've pointed out before that this should say HRTIMER_MODE_REL_SOFT.
> 
> Anyway, since it still doesn't apply on my tree, somebody else will
> have to pick it up.

Yes. I'm going to do that or decide to postpone the conversion
patches. Have not yet thought about it as I was distracted for the last 2
month by something unpleasant

Thanks,

tglx

Re: UBSAN: Undefined behaviour in net/wireless/nl80211.c:718:4: -1665903437 * 100 cannot be represented in type 'int'

[Johannes Berg]

Hi,

Can you reproduce this?

> [   54.426491] UBSAN: Undefined behaviour in net/wireless/nl80211.c:718:4
> [   54.426492] signed integer overflow:
> [   54.426493] -1665903437 * 100 cannot be represented in type 'int'

Obviously.

However, it looks like the real reason is that there's some garbage (-
1665903437) in chan->max_power, which is just stack memory being leaked
out...

This should help?

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 78e71b0390be..7b42f0bacfd8 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1769,8 +1769,7 @@ static void handle_reg_beacon(struct wiphy *wiphy, 
unsigned int chan_idx,
if (wiphy->regulatory_flags & REGULATORY_DISABLE_BEACON_HINTS)
return;
 
-   chan_before.center_freq = chan->center_freq;
-   chan_before.flags = chan->flags;
+   chan_before = *chan;
 
if (chan->flags & IEEE80211_CHAN_NO_IR) {
chan->flags &= ~IEEE80211_CHAN_NO_IR;

johannes

Re: [PATCH v4 31/36] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

[Johannes Berg]

On Thu, 2017-12-21 at 11:42 +0100, Anna-Maria Gleixner wrote:
> From: Thomas Gleixner 
> 
> Switch the timer to HRTIMER_MODE_SOFT, which executed the timer

I've pointed out before that this should say HRTIMER_MODE_REL_SOFT.

Anyway, since it still doesn't apply on my tree, somebody else will
have to pick it up.

johannes

Re: [PATCH] nl80211: Check for the required netlink attribute presence

[Johannes Berg]

On Wed, 2018-01-03 at 11:00 +0800, Hao Chen wrote:
> nl80211_nan_add_func() does not check if the required attribute
> NL80211_NAN_FUNC_FOLLOW_UP_DEST is present when processing
> NL80211_CMD_ADD_NAN_FUNCTION request. This request can be issued
> by users with CAP_NET_ADMIN privilege and may result in NULL dereference
> and a system crash. Add a check for the required attribute presence.

Applied, thanks.

johannes

[PATCH] [linux-next] rt2x00: Fix a typo in printk

[Masanari Iida]

This patch fix a typo in rt2800lib.c

Signed-off-by: Masanari Iida 
---
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index d2c289446c00..429d07b651dd 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -4903,7 +4903,7 @@ void rt2800_vco_calibration(struct rt2x00_dev *rt2x00dev)
min_sleep = 2000;
break;
default:
-   WARN_ONCE(1, "Not supported RF chipet %x for VCO recalibration",
+   WARN_ONCE(1, "Not supported RF chipset %x for VCO 
recalibration",
  rt2x00dev->chip.rf);
return;
}
-- 
2.15.1.433.g936d1b989416

pull-request: mac80211-next 2018-01-04

[Johannes Berg]

Hi Dave,

And here's a set for -next. It's not really big, and things
are all over the place. I'm thinking that Luca hasn't flushed
his queue out, but perhaps that'll then wait for the next
release, unless there are fixes that he still has.

Please pull and let me know if there's any problem.

Thanks,
johannes



The following changes since commit 51e18a453f5f59a40c721d4aeab082b4e2e9fac6:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-12-09 
22:09:55 -0500)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
tags/mac80211-next-for-davem-2018-01-04

for you to fetch changes up to 3a3713ec360138f806c6fc368d1de570f692b347:

  mac80211: Fix setting TX power on monitor interfaces (2018-01-04 15:27:48 
+0100)


We have things all over the place, no point listing them.

One thing is notable: I applied two patches and later
reverted them - we'll get back to that once all the driver
situation is sorted out.


Adiel Aloni (1):
  mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED

David Spinadel (2):
  mac80211: Add MIC space only for TX key option
  nl80211: send deauth reason if locally generated

Emmanuel Grumbach (1):
  mac80211: always update the PM state of a peer on MGMT / DATA frames

Gustavo A. R. Silva (1):
  mac80211: mark expected switch fall-throughs

Johannes Berg (6):
  mac80211: avoid looking up tid_tx/tid_rx from timers
  mac80211: make __ieee80211_start_rx_ba_session static
  nl80211: add a few extended error strings to key parsing
  mac80211: don't warn on AID field without top two MSBs set
  Revert "mac80211: Add airtime account and scheduling to TXQs"
  Revert "mac80211: Add TXQ scheduling API"

Luca Coelho (1):
  mac80211: remove BUG() when interface type is invalid

Peter Große (1):
  mac80211: Fix setting TX power on monitor interfaces

Sara Sharon (1):
  mac80211: call synchronize_net once in the restart flow

Sergey Matyukevich (1):
  cfg80211: cleanup signal strength units notation

Sunil Dutt (1):
  cfg80211: Scan results to also report the per chain signal strength

Toke Høiland-Jørgensen (2):
  mac80211: Add TXQ scheduling API
  mac80211: Add airtime account and scheduling to TXQs

Tova Mussai (1):
  cfg80211: IBSS: Add support for static WEP in driver for IBSS

Yingying Tang (1):
  mac80211: enable TDLS peer buffer STA feature

 drivers/net/wireless/mac80211_hwsim.c | 17 +
 include/net/cfg80211.h| 17 +++--
 include/net/mac80211.h| 10 +-
 include/uapi/linux/nl80211.h  |  4 +++
 net/mac80211/agg-rx.c | 26 +-
 net/mac80211/agg-tx.c | 34 ++
 net/mac80211/cfg.c| 31 +++-
 net/mac80211/debugfs.c|  1 +
 net/mac80211/driver-ops.h |  3 +-
 net/mac80211/ht.c |  1 +
 net/mac80211/ieee80211_i.h|  4 ---
 net/mac80211/iface.c  |  4 +--
 net/mac80211/key.c| 12 +--
 net/mac80211/main.c   |  3 ++
 net/mac80211/mesh.c   |  2 ++
 net/mac80211/mesh_hwmp.c  |  1 +
 net/mac80211/mesh_plink.c |  2 +-
 net/mac80211/mlme.c   | 10 +++---
 net/mac80211/offchannel.c |  4 +--
 net/mac80211/rx.c | 17 +++--
 net/mac80211/tdls.c   |  6 +++-
 net/mac80211/tx.c |  4 ++-
 net/mac80211/util.c   | 19 +-
 net/mac80211/wme.c|  1 +
 net/mac80211/wpa.c| 16 ++---
 net/wireless/ibss.c   |  5 +++
 net/wireless/mlme.c   |  6 ++--
 net/wireless/nl80211.c| 68 ---
 net/wireless/scan.c   |  5 +++
 net/wireless/trace.h  | 12 +++
 30 files changed, 219 insertions(+), 126 deletions(-)

pull-request: mac80211 2018-01-04

[Johannes Berg]

Hi Dave,

It's probably getting quite late for the current cycle, but
these fixes seemed important enough to send them to you
separately anyway.

Please pull and let me know if there's any problem.

Thanks,
johannes



The following changes since commit 820d1d5eba5e0db88432f4b19149d87523ee193c:

  Merge branch '40GbE' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue (2018-01-03 
13:49:24 -0500)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
tags/mac80211-for-davem-2018-01-04

for you to fetch changes up to 736a80bbfda709fb3631f5f62056f250a38e5804:

  mac80211: mesh: drop frames appearing to be from us (2018-01-04 15:51:53 
+0100)


Two fixes:
 * drop mesh frames appearing to be from ourselves
 * check another netlink attribute for existence


Hao Chen (1):
  nl80211: Check for the required netlink attribute presence

Johannes Berg (1):
  mac80211: mesh: drop frames appearing to be from us

 net/mac80211/rx.c  | 2 ++
 net/wireless/nl80211.c | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

[PATCH] mac80211: mesh: drop frames appearing to be from us

[Johannes Berg]

From: Johannes Berg 

If there are multiple mesh stations with the same MAC address,
they will both get confused and start throwing warnings.

Obviously in this case nothing can actually work anyway, so just
drop frames that look like they're from ourselves early on.

Reported-by: Gui Iribarren 
Signed-off-by: Johannes Berg 
---
 net/mac80211/rx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 70e9d2ca8bbe..4daafb07602f 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3632,6 +3632,8 @@ static bool ieee80211_accept_frame(struct 
ieee80211_rx_data *rx)
}
return true;
case NL80211_IFTYPE_MESH_POINT:
+   if (ether_addr_equal(sdata->vif.addr, hdr->addr2))
+   return false;
if (multicast)
return true;
return ether_addr_equal(sdata->vif.addr, hdr->addr1);
-- 
2.15.1

Re: [PATCH v2 3/3] nl80211: Introduce scan flags to emphasize requested scan behavior

[Johannes Berg]

On Fri, 2017-12-22 at 18:33 +0200, Jouni Malinen wrote:
> From: Sunil Dutt 
> 
> This commit defines new scan flags (LOW_SPAN, LOW_POWER, HIGH_LATENCY)
> to emphasize the requested scan behavior for the driver. These flags are
> optional and are mutually exclusive. The implementation of the
> respective functionality can be driver/hardware specific.
> 
> These flags can be used to control the compromise between how long a
> scan takes, how much power it uses, and high accurate/complete the scan
> is in finding the BSSs.
> 
> Signed-off-by: Sunil Dutt 
> Signed-off-by: Jouni Malinen 
> ---
>  include/uapi/linux/nl80211.h | 28 +++-
>  net/wireless/nl80211.c   | 13 +++--
>  2 files changed, 38 insertions(+), 3 deletions(-)
> 
> v2:
> - added driver capability flags to indicate which of the options are
>   supported
> - added to this patch series due to a new dependency in one of the
>   header files

Looks fine, but I guess I should wait for a rebase.

johannes

Re: [PATCH v2 2/3] nl80211: Allow SAE Authentication for NL80211_CMD_CONNECT

[Johannes Berg]

On Fri, 2017-12-22 at 18:33 +0200, Jouni Malinen wrote:
> From: Srinivas Dasari 
> 
> This commit allows SAE Authentication for NL80211_CMD_CONNECT
> interface, provided this is supported by the host driver.

Now this is interesting - there could potentially be a case where you
request SAE, but don't set NL80211_ATTR_EXTERNAL_AUTH_SUPP[ORT], and
then SAE *isn't* supported, right?

What happens then? Do we expect the driver to reject it? Better at
least document the expected behaviour...

johannes

Re: [PATCH v2 1/3] cfg80211/nl80211: Optional authentication offload to userspace

[Johannes Berg]

Hi,


Sorry for the delay - mostly was on vacation while/since you sent this.

>   * @ASSOC_REQ_USE_RRM: Declare RRM capability in this association
> + * @CONNECT_REQ_EXTERNAL_AUTH_SUPP: User space indicates external 
> authentication
> + * capability. Drivers can offload authentication to userspace if this flag 
> is
> + * set. Only applicable for cfg80211_connect() request (connect callback).

That should be indented by a tab, not just a space, for the
continuation lines. I'd have fixed this, but now that I'm commenting on
other things please fix it when you respin.

>  /**
> + * struct cfg80211_external_auth_params - External authentication
> + * trigger parameters. Commonly used across the external auth request and
> + * event interfaces.

This doesn't work - short description has to fit on a single line

> + * @action: action type / trigger for external authentication. Only 
> significant
> + * for the event interface (from driver to user space).
> + * @bssid: BSSID of the peer with which the authentication has
> + *  to happen. Used by both the request and event interface.
> + * @ssid: SSID of the AP. Used by both the request and event interface.
> + * @key_mgmt_suite: AKM suite of the respective authentication. Optional for
> + *   the request interface.

Here it looks indented confusingly - sometimes tab maybe?, sometimes
spaces, sometimes nothing. Please use tabs.

> + * @status: status code, %WLAN_STATUS_SUCCESS for successful authentication,
> + *   use %WLAN_STATUS_UNSPECIFIED_FAILURE if user space cannot give you
> + *   the real status code for failures. Used only for the request
> + *   interface from user space to the driver.

The patch is called "offload to userspace", yet you speak about 
"request from user space". I'm thinking that's confusing? You also
speak about request/event a lot above, and when it's hard to figure out
which is which, that's not very helpful.

I suggest you rephrase this to something like "authentication [request]
event" and "authentication response [command/call]", or so?


You also completely neglected to document how the authentication even
happens. Using NL80211_CMD_AUTHENTICATE? But would a driver needing
this even support that? Or somehow using this new operation?


> + * @NL80211_CMD_EXTERNAL_AUTH: This command/event interface is exclusively
> + *   defined for host drivers that do not define separate commands for
> + *   authentication and association, bute rely on user space SME (e.g., in

typo: "but"

> + *   wpa_supplicant for the ~WPA_DRIVER_FLAGS_SME case) for the
> + *   authentication to happen.

But anyway this can't really be right - you mean use device SME? Please
don't use WPA_DRIVER_FLAGS_SME as documentation here, even as an
example, reword so you don't need the example.

> + *   User space uses the %NL80211_CMD_CONNECT command to the host driver for
> + *   triggering a connection. The host driver selects a BSS and further uses
> + *   this interface to offload only the authentication part to the user
> + *   space.

Yep, this contradicts what you said above.

>  Authentication frames are passed between the driver and user
> + *   space through the %NL80211_CMD_FRAME interface.

Ah, ok, so you did document that here a bit. I guess that works.

>  The status of
> + *   authentication is further indicated by user space to the host driver
> + *   with the %NL80211_CMD_EXTERNAL_AUTH command through
> + *   %NL80211_ATTR_STATUS_CODE attribute. This enables the driver to proceed
> + *   with association on successful authentication. 

Sure, that seems OK, except I don't see why the driver needs a status
code, vs. just "oops, something failed"?

> Driver shall use this
> + *   %NL80211_ATTR_STATUS_CODE attribute to report the connect result to
> + *   user space on an authentication failure.

I don't understand this part.

Ah, actually, ok - I get it - you feed that back to userspace as the
connect result.

Ok, fine, but please reword to make that more evident.

> + * @NL80211_ATTR_EXTERNAL_AUTH_SUPP: Flag attribute indicating that the user

I'd prefer you spell out "SUPPORT". It's just 3 more characters after
all.

> + * @NL80211_EXT_FEATURE_EXTERNAL_AUTH: Driver supports external 
> authentication

Ok, so I seem to remember that I requested this, but does that even
make sense? After all, userspace can set the "I can do it" attribute
all it wants, if the driver never uses it then userspace will never
know whether or not it's because it just wasn't necessary, or because
the driver can't really do it, right?

> +static int nl80211_external_auth(struct sk_buff *skb, struct genl_info *info)
> +{
> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
> + struct net_device *dev = info->user_ptr[1];
> + struct cfg80211_external_auth_params params;
> +
> + if (!wiphy_ext_feature_isset(>wiphy,
> +  NL80211_EXT_FEATURE_EXTERNAL_AUTH) ||
> + !rdev->ops->external_auth)
> + return 

Re: [PATCH] iwlwifi: pcie: fix DMA memory mapping / unmapping

[Kalle Valo]

Emmanuel Grumbach  writes:

> 22000 devices (previously referenced as A000) can support
> short transmit queues. This means that we have less DMA
> descriptors (TFD) for those shorter queues.
> Previous devices must still have 256 TFDs for each queue
> even if those 256 TFDs point to fewer buffers.
>
> When I introduced support for the short queues for 22000
> I broke older devices by assuming that they can also have
> less TFDs in their queues. This led to several problems:
>
> 1) the payload of the commands weren't unmapped properly
>which caused the SWIOTLB to complain at some point.
> 2) the hardware could get confused and we get hardware
>crashes.
>
> The corresponding bugzilla entries are:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=198201
> https://bugzilla.kernel.org/show_bug.cgi?id=198265
>
> Cc: sta...@vger.kernel.org # 4.14+
> Fixes: 4ecab5616023 ("iwlwifi: pcie: support short Tx queues for A000 device 
> family")
> Reviewed-by: Sharon, Sara 
> Signed-off-by: Emmanuel Grumbach 
> ---
> Hi Kalle,
>
> Luca is on vacation is 4.15 will be closed soon.
> I am fixing here a bug that caused much troube on our side.
> There are two bugzillas on it. Users on both bugs validated
> this fix.
> Please apply this on wireless-drivers.git directly and I'll sync
> with Luca when he'll be back.

Ok, I'll queue this for 4.15.

-- 
Kalle Valo

Hallo mein lieber Freund,

[57618852]

Hallo mein lieber Freund,

Ich schreibe dir diese Post mit schweren Tränen In meinen Augen und großem 
Kummer in meinem Herzen, Mein Name ist Vera Hollin Kvan, und ich kontaktiere 
dich aus meinem Land Indien Ich möchte dir das sagen, weil ich keine habe Eine 
andere Möglichkeit, als Ihnen zu sagen, wie ich berührt war, um Sie zu öffnen, 
heiratete ich mit Herrn Hollin Kvan, der für neun Jahre mit der tunesischen 
Botschaft in Madrid Spanien arbeitete, bevor er im Jahr 2005 starb. Wir waren 
elf Jahre ohne verheiratet Kind.

Er starb nach einer kurzen Krankheit, die nur fünf Tage dauerte. Seit seinem 
Tod entschied ich mich, nicht wieder zu heiraten. Als mein verstorbener Mann 
noch am Leben war, hinterlegte er die Summe von $ 4.850.000,00USD (Vier 
Millionen achthundertundfünfzigtausend Dollar) in einer Bank hier in Indien 
Neu-Delhi, der Hauptstadt Indiens, gegenwärtig dieses Geld ist immer noch in 
der Bank.

Er stellte dieses Geld für den Export von Gold aus dem Minenfactory in Madrid 
Spanien zur Verfügung. In letzter Zeit sagte mir mein Doktor, dass ich wegen 
der Krebserkrankung für die Dauer von sieben Monaten nicht überleben würde. 
Derjenige, der mich am meisten stört, ist meine Schlaganfall-Krankheit. Nachdem 
ich meinen Zustand gekannt habe, habe ich beschlossen, dir dieses Geld 
auszuhändigen, um auf die weniger privilegierten Menschen aufzupassen, du wirst 
dieses Geld auf die Art und Weise benutzen, wie ich es hier unterrichten werde.

Ich möchte, dass Sie 30 Prozent des gesamten Geldes für Ihren persönlichen 
Gebrauch aufwenden, während 70% des Geldes an wohltätige Zwecke gehen, Menschen 
auf der Straße und dem Waisenhaus helfen. Ich bin als Waise aufgewachsen und 
habe keinen Körper als mein Familienmitglied, nur um zu beenden, dass das Haus 
Gottes auch erhalten wird. Mache dies, damit Gott meine Sünden vergibt und 
meine Seele akzeptiert, weil diese Krankheiten mich so sehr leiden. Sobald ich 
Ihre Antwort erhalten habe, werde ich Ihnen den Kontakt der Bank hier in Delhi 
Indien geben und ich werde auch den Bankmanager beauftragen, Ihnen einen 
Vollmachtenbrief auszustellen, der Ihnen den gegenwärtigen Begünstigten des 
Geldes in der Bank beweisen wird, wenn Sie versichern mir, dass Sie 
entsprechend handeln werden, wie ich hier angegeben habe.

Ich hoffe auf Ihre Antwort.
Von Vera Hollin kVan

Odp: Re: iwlwifi: mvm: rx ops with kernel >= 4.14

[Dawid Stawiarski]

> > after updating to kernel >= 4.14 (from 4.13.X) my wifi stops working every 
> > couple hours with the following stacktrace (I've already updated firmware 
> > to latest version):
> >
> > jan 03 13:28:17 tmi kernel: iwlwifi :3b:00.0: loaded firmware version 
> > 17.608620.0 op_mode iwlmvm
> > jan 03 13:28:17 tmi kernel: iwlwifi :3b:00.0: Detected Intel(R) Dual 
> > Band Wireless AC 7260, REV=0x144
> > jan 03 13:28:17 tmi kernel: iwlwifi :3b:00.0: base HW address: 
> > d8:fc:93:14:cc:15
> > jan 03 13:28:17 tmi kernel: ieee80211 phy0: Selected rate control algorithm 
> > 'iwl-mvm-rs'
> > [...]
> > jan 03 16:14:05 tmi kernel: iwlwifi :3b:00.0: iwl_pcie_cmdq_reclaim: 
> > Read index for DMA queue txq id (0), index 0 is out of range [0-256] 70 70.
> > jan 03 16:14:05 tmi kernel: iwlwifi :3b:00.0: HCMD_ACTIVE already clear 
> > for command LQ_CMD
> > jan 03 16:14:05 tmi kernel: frame on invalid queue - is on 0 and indicates 1
> > jan 03 16:14:05 tmi kernel: [ cut here ]
>  
> Can you please check if the patch in
> https://bugzilla.kernel.org/show_bug.cgi?id=198265 helps?

I've been testing it since yesterday, and so far so good - no ops. Thanks.

Re: [PATCH v3 00/27] kill devm_ioremap_nocache

[Christophe LEROY]

Le 25/12/2017 à 02:34, Yisheng Xie a écrit :



On 2017/12/24 17:05, christophe leroy wrote:



Le 23/12/2017 à 14:48, Greg KH a écrit :

On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:

Hi all,

When I tried to use devm_ioremap function and review related code, I found
devm_ioremap and devm_ioremap_nocache is almost the same with each other,
except one use ioremap while the other use ioremap_nocache.


For all arches?  Really?  Look at MIPS, and x86, they have different
functions.


While ioremap's
default function is ioremap_nocache, so devm_ioremap_nocache also have the
same function with devm_ioremap, which can just be killed to reduce the size
of devres.o(from 20304 bytes to 18992 bytes in my compile environment).

I have posted two versions, which use macro instead of function for
devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
devm_ioremap_nocache for no need to keep a macro around for the duplicate
thing. So here comes v3 and please help to review.


I don't think this can be done, what am I missing?  These functions are
not identical, sorry for missing that before.


devm_ioremap() and devm_ioremap_nocache() are quite similar, both use 
devm_ioremap_release() for the release, why not just defining:

static void __iomem *__devm_ioremap(struct device *dev, resource_size_t offset,
resource_size_t size, bool nocache)
{
[...]
 if (nocache)
 addr = ioremap_nocache(offset, size);
 else
 addr = ioremap(offset, size);
[...]
}

then in include/linux/io.h

static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t 
offset,
resource_size_t size)
{return __devm_ioremap(dev, offset, size, false);}

static inline void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
resource_size_t size);
{return __devm_ioremap(dev, offset, size, true);}


Yeah, this seems good to me, right now we have devm_ioremap, devm_ioremap_wc, 
devm_ioremap_nocache
May be we can use an enum like:
typedef enum {
DEVM_IOREMAP = 0,
DEVM_IOREMAP_NOCACHE,
DEVM_IOREMAP_WC,
} devm_ioremap_type;

static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t 
offset,
 resource_size_t size)
  {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP);}

  static inline void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
 resource_size_t size);
  {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_NOCACHE);}

  static inline void __iomem *devm_ioremap_wc(struct device *dev, 
resource_size_t offset,
 resource_size_t size);
  {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_WC);}

  static void __iomem *__devm_ioremap(struct device *dev, resource_size_t 
offset,
 resource_size_t size, devm_ioremap_type type)
  {
  void __iomem **ptr, *addr = NULL;
  [...]
  switch (type){
  case DEVM_IOREMAP:
  addr = ioremap(offset, size);
  break;
  case DEVM_IOREMAP_NOCACHE:
  addr = ioremap_nocache(offset, size);
  break;
  case DEVM_IOREMAP_WC:
  addr = ioremap_wc(offset, size);
  break;
  }
  [...]
  }



That looks good to me, will you submit a v4 ?

Christophe



Thanks
Yisheng



Christophe



thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


.