* [PATCH 1/3] nl80211: Update uapi for CMD_FRAME_WAIT_CANCEL
From: Denis Kenzior @ 2019-06-19 22:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Denis Kenzior
1c38c7f2 added the possibility of NL80211_CMD_FRAME_WAIT_CANCEL
being sent whenever the off-channel wait time associated with a
CMD_FRAME completes. Document this in the uapi/linux/nl80211.h file.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
include/uapi/linux/nl80211.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 8fc3a43cac75..0d9aad98c983 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -657,7 +657,9 @@
* is used during CSA period.
* @NL80211_CMD_FRAME_WAIT_CANCEL: When an off-channel TX was requested, this
* command may be used with the corresponding cookie to cancel the wait
- * time if it is known that it is no longer necessary.
+ * time if it is known that it is no longer necessary. This command is
+ * also sent as an event whenever the driver has completed the off-channel
+ * wait time.
* @NL80211_CMD_ACTION: Alias for @NL80211_CMD_FRAME for backward compatibility.
* @NL80211_CMD_FRAME_TX_STATUS: Report TX status of a management frame
* transmitted with %NL80211_CMD_FRAME. %NL80211_ATTR_COOKIE identifies
--
2.21.0
^ permalink raw reply related
* [PATCH 2/3] nl80211: Limit certain commands to interface owner
From: Denis Kenzior @ 2019-06-19 22:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Denis Kenzior
In-Reply-To: <20190619223606.4575-1-denkenz@gmail.com>
If the wdev object has been created (via NEW_INTERFACE) with
SOCKET_OWNER attribute set, then limit certain commands only to the
process that created that wdev.
This can be used to make sure no other process on the system interferes
by sending unwanted scans, action frames or any other funny business.
This patch introduces a new internal flag, and checks that flag in the
pre_doit hook.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/nl80211.c | 80 ++++++++++++++++++++++++++++++++----------
1 file changed, 61 insertions(+), 19 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ff760ba83449..26bab9560c0f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -13587,6 +13587,7 @@ static int nl80211_probe_mesh_link(struct sk_buff *skb, struct genl_info *info)
#define NL80211_FLAG_NEED_WDEV_UP (NL80211_FLAG_NEED_WDEV |\
NL80211_FLAG_CHECK_NETDEV_UP)
#define NL80211_FLAG_CLEAR_SKB 0x20
+#define NL80211_FLAG_OWNER_ONLY 0x40
static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
struct genl_info *info)
@@ -13595,6 +13596,7 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
struct wireless_dev *wdev;
struct net_device *dev;
bool rtnl = ops->internal_flags & NL80211_FLAG_NEED_RTNL;
+ int ret;
if (rtnl)
rtnl_lock();
@@ -13602,10 +13604,10 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
if (ops->internal_flags & NL80211_FLAG_NEED_WIPHY) {
rdev = cfg80211_get_dev_from_info(genl_info_net(info), info);
if (IS_ERR(rdev)) {
- if (rtnl)
- rtnl_unlock();
- return PTR_ERR(rdev);
+ ret = PTR_ERR(rdev);
+ goto done;
}
+
info->user_ptr[0] = rdev;
} else if (ops->internal_flags & NL80211_FLAG_NEED_NETDEV ||
ops->internal_flags & NL80211_FLAG_NEED_WDEV) {
@@ -13614,32 +13616,33 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
wdev = __cfg80211_wdev_from_attrs(genl_info_net(info),
info->attrs);
if (IS_ERR(wdev)) {
- if (rtnl)
- rtnl_unlock();
- return PTR_ERR(wdev);
+ ret = PTR_ERR(wdev);
+ goto done;
}
dev = wdev->netdev;
rdev = wiphy_to_rdev(wdev->wiphy);
+ ret = -EINVAL;
if (ops->internal_flags & NL80211_FLAG_NEED_NETDEV) {
- if (!dev) {
- if (rtnl)
- rtnl_unlock();
- return -EINVAL;
- }
+ if (!dev)
+ goto done;
info->user_ptr[1] = dev;
} else {
info->user_ptr[1] = wdev;
}
+ ret = -ENETDOWN;
if (ops->internal_flags & NL80211_FLAG_CHECK_NETDEV_UP &&
- !wdev_running(wdev)) {
- if (rtnl)
- rtnl_unlock();
- return -ENETDOWN;
- }
+ !wdev_running(wdev))
+ goto done;
+
+ ret = -EPERM;
+ if (ops->internal_flags & NL80211_FLAG_OWNER_ONLY &&
+ wdev->owner_nlportid &&
+ wdev->owner_nlportid != info->snd_portid)
+ goto done;
if (dev)
dev_hold(dev);
@@ -13647,7 +13650,13 @@ static int nl80211_pre_doit(const struct genl_ops *ops, struct sk_buff *skb,
info->user_ptr[0] = rdev;
}
- return 0;
+ ret = 0;
+
+done:
+ if (rtnl && !ret)
+ rtnl_unlock();
+
+ return ret;
}
static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
@@ -13712,7 +13721,8 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_set_interface,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV |
- NL80211_FLAG_NEED_RTNL,
+ NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_OWNER_ONLY,
},
{
.cmd = NL80211_CMD_NEW_INTERFACE,
@@ -13728,7 +13738,8 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_del_interface,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV |
- NL80211_FLAG_NEED_RTNL,
+ NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_OWNER_ONLY,
},
{
.cmd = NL80211_CMD_GET_KEY,
@@ -13745,6 +13756,7 @@ static const struct genl_ops nl80211_ops[] = {
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_CLEAR_SKB,
},
{
@@ -13754,6 +13766,7 @@ static const struct genl_ops nl80211_ops[] = {
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_CLEAR_SKB,
},
{
@@ -13762,6 +13775,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_del_key,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13778,6 +13792,7 @@ static const struct genl_ops nl80211_ops[] = {
.flags = GENL_UNS_ADMIN_PERM,
.doit = nl80211_start_ap,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13786,6 +13801,7 @@ static const struct genl_ops nl80211_ops[] = {
.flags = GENL_UNS_ADMIN_PERM,
.doit = nl80211_stop_ap,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13802,6 +13818,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_set_station,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13810,6 +13827,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_new_station,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13818,6 +13836,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_del_station,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13921,6 +13940,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_trigger_scan,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13929,6 +13949,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_abort_scan,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13942,6 +13963,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_start_sched_scan,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13950,6 +13972,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_stop_sched_scan,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13958,6 +13981,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_authenticate,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
},
@@ -13967,6 +13991,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_associate,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
},
@@ -13976,6 +14001,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_deauthenticate,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13984,6 +14010,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_disassociate,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -13992,6 +14019,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_join_ibss,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14000,6 +14028,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_leave_ibss,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
#ifdef CONFIG_NL80211_TESTMODE
@@ -14019,6 +14048,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_connect,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
},
@@ -14028,6 +14058,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_update_connect_params,
.flags = GENL_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
},
@@ -14037,6 +14068,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_disconnect,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14083,6 +14115,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_remain_on_channel,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14091,6 +14124,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_cancel_remain_on_channel,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14115,6 +14149,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_tx_mgmt,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14123,6 +14158,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_tx_mgmt_cancel_wait,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14147,6 +14183,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_set_cqm,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14221,6 +14258,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_set_rekey_data,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL |
NL80211_FLAG_CLEAR_SKB,
},
@@ -14278,6 +14316,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_start_p2p_device,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14286,6 +14325,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_stop_p2p_device,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14371,6 +14411,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_crit_protocol_start,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
@@ -14379,6 +14420,7 @@ static const struct genl_ops nl80211_ops[] = {
.doit = nl80211_crit_protocol_stop,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WDEV_UP |
+ NL80211_FLAG_OWNER_ONLY |
NL80211_FLAG_NEED_RTNL,
},
{
--
2.21.0
^ permalink raw reply related
* [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Denis Kenzior @ 2019-06-19 22:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Denis Kenzior
In-Reply-To: <20190619223606.4575-1-denkenz@gmail.com>
Include wiphy address setup in wiphy dumps and new wiphy events. The
wiphy permanent address is exposed as ATTR_MAC. If addr_mask is setup,
then it is included as ATTR_MAC_MASK attribute. If multiple addresses
are available, then their are exposed in a nested ATTR_MAC_ADDRS array.
This information is already exposed via sysfs, but it makes sense to
include it in the wiphy dump as well.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
---
net/wireless/nl80211.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 26bab9560c0f..65f3d47d9b63 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1852,6 +1852,31 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
switch (state->split_start) {
case 0:
+ if (nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN,
+ rdev->wiphy.perm_addr))
+ goto nla_put_failure;
+
+ if (!is_zero_ether_addr(rdev->wiphy.addr_mask) &&
+ nla_put(msg, NL80211_ATTR_MAC_MASK, ETH_ALEN,
+ rdev->wiphy.addr_mask))
+ goto nla_put_failure;
+
+ if (rdev->wiphy.n_addresses > 1) {
+ void *attr;
+
+ attr = nla_nest_start_noflag(msg,
+ NL80211_ATTR_MAC_ADDRS);
+ if (!attr)
+ goto nla_put_failure;
+
+ for (i = 0; i < rdev->wiphy.n_addresses; i++)
+ if (nla_put(msg, i + 1, ETH_ALEN,
+ rdev->wiphy.addresses[i].addr))
+ goto nla_put_failure;
+
+ nla_nest_end(msg, attr);
+ }
+
if (nla_put_u8(msg, NL80211_ATTR_WIPHY_RETRY_SHORT,
rdev->wiphy.retry_short) ||
nla_put_u8(msg, NL80211_ATTR_WIPHY_RETRY_LONG,
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v3 0/7] Hexdump Enhancements
From: Alastair D'Silva @ 2019-06-19 23:15 UTC (permalink / raw)
To: Joe Perches
Cc: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie,
Daniel Vetter, Dan Carpenter, Karsten Keil, Jassi Brar,
Tom Lendacky, David S. Miller, Jose Abreu, Kalle Valo,
Stanislaw Gruszka, Benson Leung, Enric Balletbo i Serra,
James E.J. Bottomley, Martin K. Petersen, Greg Kroah-Hartman,
Alexander Viro, Petr Mladek, Sergey Senozhatsky, Steven Rostedt,
David Laight, Andrew Morton, intel-gfx, dri-devel, linux-kernel,
netdev, ath10k, linux-wireless, linux-scsi, linux-fbdev, devel,
linux-fsdevel
In-Reply-To: <9a000734375c0801fc16b71f4be1235f9b857772.camel@perches.com>
On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> > From: Alastair D'Silva <alastair@d-silva.org>
> >
> > Apologies for the large CC list, it's a heads up for those
> > responsible
> > for subsystems where a prototype change in generic code causes a
> > change
> > in those subsystems.
> >
> > This series enhances hexdump.
>
> Still not a fan of these patches.
I'm afraid there's not too much action I can take on that, I'm happy to
address specific issues though.
>
> > These improve the readability of the dumped data in certain
> > situations
> > (eg. wide terminals are available, many lines of empty bytes exist,
> > etc).
>
> Changing hexdump's last argument from bool to int is odd.
>
Think of it as replacing a single boolean with many booleans.
> Perhaps a new function should be added instead of changing
> the existing hexdump.
>
There's only a handful of consumers, I don't think there is a value-add
in creating more wrappers vs updating the existing callers.
--
Alastair D'Silva mob: 0423 762 819
skype: alastair_dsilva
Twitter: @EvilDeece
blog: http://alastair.d-silva.org
^ permalink raw reply
* Re: [PATCH v3 0/7] Hexdump Enhancements
From: Joe Perches @ 2019-06-20 0:35 UTC (permalink / raw)
To: Alastair D'Silva
Cc: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie,
Daniel Vetter, Dan Carpenter, Karsten Keil, Jassi Brar,
Tom Lendacky, David S. Miller, Jose Abreu, Kalle Valo,
Stanislaw Gruszka, Benson Leung, Enric Balletbo i Serra,
James E.J. Bottomley, Martin K. Petersen, Greg Kroah-Hartman,
Alexander Viro, Petr Mladek, Sergey Senozhatsky, Steven Rostedt,
David Laight, Andrew Morton, intel-gfx, dri-devel, linux-kernel,
netdev, ath10k, linux-wireless, linux-scsi, linux-fbdev, devel,
linux-fsdevel
In-Reply-To: <c68cb819257f251cbb66f8998a95c31cebe2d72e.camel@d-silva.org>
On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
> On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> > > From: Alastair D'Silva <alastair@d-silva.org>
> > >
> > > Apologies for the large CC list, it's a heads up for those
> > > responsible
> > > for subsystems where a prototype change in generic code causes a
> > > change
> > > in those subsystems.
> > >
> > > This series enhances hexdump.
> >
> > Still not a fan of these patches.
>
> I'm afraid there's not too much action I can take on that, I'm happy to
> address specific issues though.
>
> > > These improve the readability of the dumped data in certain
> > > situations
> > > (eg. wide terminals are available, many lines of empty bytes exist,
> > > etc).
I think it's generally overkill for the desired uses.
> > Changing hexdump's last argument from bool to int is odd.
> >
>
> Think of it as replacing a single boolean with many booleans.
I understand it. It's odd.
I would rather not have a mixture of true, false, and apparently
random collections of bitfields like 0xd or 0b1011 or their
equivalent or'd defines.
> There's only a handful of consumers, I don't think there is a value-add
> in creating more wrappers vs updating the existing callers.
Perhaps more reason not to modify the existing api.
^ permalink raw reply
* Re: [PATCH v3 0/7] Hexdump Enhancements
From: Alastair D'Silva @ 2019-06-20 1:14 UTC (permalink / raw)
To: Joe Perches
Cc: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie,
Daniel Vetter, Dan Carpenter, Karsten Keil, Jassi Brar,
Tom Lendacky, David S. Miller, Jose Abreu, Kalle Valo,
Stanislaw Gruszka, Benson Leung, Enric Balletbo i Serra,
James E.J. Bottomley, Martin K. Petersen, Greg Kroah-Hartman,
Alexander Viro, Petr Mladek, Sergey Senozhatsky, Steven Rostedt,
David Laight, Andrew Morton, intel-gfx, dri-devel, linux-kernel,
netdev, ath10k, linux-wireless, linux-scsi, linux-fbdev, devel,
linux-fsdevel
In-Reply-To: <d8316be322f33ea67640ff83f2248fe433078407.camel@perches.com>
On Wed, 2019-06-19 at 17:35 -0700, Joe Perches wrote:
> On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
> > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> > > > From: Alastair D'Silva <alastair@d-silva.org>
> > > >
> > > > Apologies for the large CC list, it's a heads up for those
> > > > responsible
> > > > for subsystems where a prototype change in generic code causes
> > > > a
> > > > change
> > > > in those subsystems.
> > > >
> > > > This series enhances hexdump.
> > >
> > > Still not a fan of these patches.
> >
> > I'm afraid there's not too much action I can take on that, I'm
> > happy to
> > address specific issues though.
> >
> > > > These improve the readability of the dumped data in certain
> > > > situations
> > > > (eg. wide terminals are available, many lines of empty bytes
> > > > exist,
> > > > etc).
>
> I think it's generally overkill for the desired uses.
I understand where you're coming from, however, these patches make it a
lot easier to work with large chucks of binary data. I think it makes
more sense to have these patches upstream, even though committed code
may not necessarily have all the features enabled, as it means that
devs won't have to apply out-of-tree patches during development to make
larger dumps manageable.
>
> > > Changing hexdump's last argument from bool to int is odd.
> > >
> >
> > Think of it as replacing a single boolean with many booleans.
>
> I understand it. It's odd.
>
> I would rather not have a mixture of true, false, and apparently
> random collections of bitfields like 0xd or 0b1011 or their
> equivalent or'd defines.
>
Where's the mixture? What would you propose instead?
--
Alastair D'Silva mob: 0423 762 819
skype: alastair_dsilva
Twitter: @EvilDeece
blog: http://alastair.d-silva.org
^ permalink raw reply
* Re: [PATCH v3 0/7] Hexdump Enhancements
From: Joe Perches @ 2019-06-20 2:00 UTC (permalink / raw)
To: Alastair D'Silva
Cc: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie,
Daniel Vetter, Dan Carpenter, Karsten Keil, Jassi Brar,
Tom Lendacky, David S. Miller, Jose Abreu, Kalle Valo,
Stanislaw Gruszka, Benson Leung, Enric Balletbo i Serra,
James E.J. Bottomley, Martin K. Petersen, Greg Kroah-Hartman,
Alexander Viro, Petr Mladek, Sergey Senozhatsky, Steven Rostedt,
David Laight, Andrew Morton, intel-gfx, dri-devel, linux-kernel,
netdev, ath10k, linux-wireless, linux-scsi, linux-fbdev, devel,
linux-fsdevel
In-Reply-To: <9456ca2a4ae827635bb6d864e5095a9e51f2ac45.camel@d-silva.org>
On Thu, 2019-06-20 at 11:14 +1000, Alastair D'Silva wrote:
> On Wed, 2019-06-19 at 17:35 -0700, Joe Perches wrote:
> > On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
> > > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> > > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> > > > > From: Alastair D'Silva <alastair@d-silva.org>
> > > > >
> > > > > Apologies for the large CC list, it's a heads up for those
> > > > > responsible
> > > > > for subsystems where a prototype change in generic code causes
> > > > > a
> > > > > change
> > > > > in those subsystems.
> > > > >
> > > > > This series enhances hexdump.
> > > >
> > > > Still not a fan of these patches.
> > >
> > > I'm afraid there's not too much action I can take on that, I'm
> > > happy to
> > > address specific issues though.
> > >
> > > > > These improve the readability of the dumped data in certain
> > > > > situations
> > > > > (eg. wide terminals are available, many lines of empty bytes
> > > > > exist,
> > > > > etc).
> >
> > I think it's generally overkill for the desired uses.
>
> I understand where you're coming from, however, these patches make it a
> lot easier to work with large chucks of binary data. I think it makes
> more sense to have these patches upstream, even though committed code
> may not necessarily have all the features enabled, as it means that
> devs won't have to apply out-of-tree patches during development to make
> larger dumps manageable.
>
> > > > Changing hexdump's last argument from bool to int is odd.
> > > >
> > >
> > > Think of it as replacing a single boolean with many booleans.
> >
> > I understand it. It's odd.
> >
> > I would rather not have a mixture of true, false, and apparently
> > random collections of bitfields like 0xd or 0b1011 or their
> > equivalent or'd defines.
> >
>
> Where's the mixture? What would you propose instead?
create a hex_dump_to_buffer_ext with a new argument
and a new static inline for the old hex_dump_to_buffer
without modifying the argument list that calls
hex_dump_to_buffer with whatever added argument content
you need.
Something like:
static inline
int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
int groupsize, char *linebuf, size_t linebuflen,
bool ascii)
{
return hex_dump_to_buffer_ext(buf, len, rowsize, groupsize,
linebuf, linebuflen, ascii, 0);
}
and remove EXPORT_SYMBOL(hex_dump_to_buffer)
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in p54u_load_firmware_cb
From: syzbot @ 2019-06-20 2:20 UTC (permalink / raw)
To: andreyknvl, chunkeey, davem, kvalo, linux-kernel, linux-usb,
linux-wireless, netdev, syzkaller-bugs
In-Reply-To: <00000000000001de810588363aaf@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 9939f56e usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=135e29faa00000
kernel config: https://syzkaller.appspot.com/x/.config?x=df134eda130bb43a
dashboard link: https://syzkaller.appspot.com/bug?extid=6d237e74cdc13f036473
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=175d946ea00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6d237e74cdc13f036473@syzkaller.appspotmail.com
usb 3-1: Direct firmware load for isl3887usb failed with error -2
usb 3-1: Firmware not found.
==================================================================
BUG: KASAN: slab-out-of-bounds in p54u_load_firmware_cb.cold+0x97/0x13d
drivers/net/wireless/intersil/p54/p54usb.c:936
Read of size 8 at addr ffff8881c9cf7588 by task kworker/1:5/2759
CPU: 1 PID: 2759 Comm: kworker/1:5 Not tainted 5.2.0-rc5+ #11
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events request_firmware_work_func
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x67/0x231 mm/kasan/report.c:188
__kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
kasan_report+0xe/0x20 mm/kasan/common.c:614
p54u_load_firmware_cb.cold+0x97/0x13d
drivers/net/wireless/intersil/p54/p54usb.c:936
request_firmware_work_func+0x126/0x242
drivers/base/firmware_loader/main.c:785
process_one_work+0x905/0x1570 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x30b/0x410 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Allocated by task 1612:
save_stack+0x1b/0x80 mm/kasan/common.c:71
set_track mm/kasan/common.c:79 [inline]
__kasan_kmalloc mm/kasan/common.c:489 [inline]
__kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:462
kmalloc include/linux/slab.h:547 [inline]
syslog_print kernel/printk/printk.c:1346 [inline]
do_syslog kernel/printk/printk.c:1519 [inline]
do_syslog+0x4f4/0x12e0 kernel/printk/printk.c:1493
kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
__vfs_read+0x76/0x100 fs/read_write.c:425
vfs_read+0x18e/0x3d0 fs/read_write.c:461
ksys_read+0x127/0x250 fs/read_write.c:587
do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 1612:
save_stack+0x1b/0x80 mm/kasan/common.c:71
set_track mm/kasan/common.c:79 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:451
slab_free_hook mm/slub.c:1421 [inline]
slab_free_freelist_hook mm/slub.c:1448 [inline]
slab_free mm/slub.c:2994 [inline]
kfree+0xd7/0x280 mm/slub.c:3949
syslog_print kernel/printk/printk.c:1405 [inline]
do_syslog kernel/printk/printk.c:1519 [inline]
do_syslog+0xff3/0x12e0 kernel/printk/printk.c:1493
kmsg_read+0x8a/0xb0 fs/proc/kmsg.c:40
proc_reg_read+0x1c1/0x280 fs/proc/inode.c:221
__vfs_read+0x76/0x100 fs/read_write.c:425
vfs_read+0x18e/0x3d0 fs/read_write.c:461
ksys_read+0x127/0x250 fs/read_write.c:587
do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8881c9cf7180
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 8 bytes to the right of
1024-byte region [ffff8881c9cf7180, ffff8881c9cf7580)
The buggy address belongs to the page:
page:ffffea0007273d00 refcount:1 mapcount:0 mapping:ffff8881dac02a00
index:0x0 compound_mapcount: 0
flags: 0x200000000010200(slab|head)
raw: 0200000000010200 dead000000000100 dead000000000200 ffff8881dac02a00
raw: 0000000000000000 00000000000e000e 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881c9cf7480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881c9cf7500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881c9cf7580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8881c9cf7600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881c9cf7680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
^ permalink raw reply
* Re: [PATCH 3/3] nl80211: Include wiphy address setup in NEW_WIPHY
From: Johannes Berg @ 2019-06-20 6:58 UTC (permalink / raw)
To: Denis Kenzior; +Cc: linux-wireless
In-Reply-To: <20190619223606.4575-3-denkenz@gmail.com>
Didn't really review all of this yet, but
switch (state->split_start) {
> case 0:
> + if (nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN,
> + rdev->wiphy.perm_addr))
> + goto nla_put_failure;
We generally can't add anything to any of the cases before the split was
allowed, for compatibility with old userspace.
johannes
^ permalink raw reply
* Re: [PATCH v2] Revert "cfg80211: fix processing world regdomain when non modular"
From: Kalle Valo @ 2019-06-20 7:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: Hodaszi, Robert, linux-wireless@vger.kernel.org
In-Reply-To: <6a9c7642a2fcca60658036c605438ff2ac982bd0.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2019-06-14 at 13:58 +0000, Hodaszi, Robert wrote:
>>
>> I didn't just resend that. I just realized, accidentally I forgot to fix
>> the debug message printing function, that define doesn't exist anymore.
>> Sorry for the confusion!
>
> Oops. I looked too superficially then and didn't even see the
> difference, sorry.
>
> I guess that's why Kalle always says you should have a patch changelog
> :-)
Indeed :) And the obligatory link:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/3] nl80211: Update uapi for CMD_FRAME_WAIT_CANCEL
From: Kalle Valo @ 2019-06-20 7:50 UTC (permalink / raw)
To: Denis Kenzior; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20190619223606.4575-1-denkenz@gmail.com>
Denis Kenzior <denkenz@gmail.com> writes:
> 1c38c7f2 added the possibility of NL80211_CMD_FRAME_WAIT_CANCEL
> being sent whenever the off-channel wait time associated with a
> CMD_FRAME completes. Document this in the uapi/linux/nl80211.h file.
The preferred format for referencing commits is:
Commit 1c38c7f22068 ("nl80211: send event when CMD_FRAME duration
expires") added...
--
Kalle Valo
^ permalink raw reply
* pull request: iwlwifi firmware updates 2019-06-20
From: Luca Coelho @ 2019-06-20 7:51 UTC (permalink / raw)
To: linux-firmware@kernel.org
Cc: linux-wireless@vger.kernel.org, linuxwifi, kyle@infradead.org,
jwboyer@kernel.org, ben@decadent.org.uk
[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]
Hi,
This contains some updated firmwares for the 9000 and 22000 series of
devices, and new firmwares for new integrated 22000 series devices.
Please pull or let me know if there are any issues.
--
Cheers,
Luca.
The following changes since commit acb56f2fae3235195bc99ecb7d09742fb4b65e63:
cavium: Add firmware for CNN55XX crypto driver. (2019-06-18 09:12:52 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2019-06-20
for you to fetch changes up to 90e6845190c2f32bb631f40a9d6c929eb504a82f:
iwlwifi: add new firmwares for integrated 22000 series (2019-06-20 10:41:13 +0300)
----------------------------------------------------------------
iwlwifi firmware updates
* Update version 46 FWs for 9260 and 9000;
* Add version 48 FWs for 22000 series;
* Add version 48 FWs for new integrated 22000 series;
----------------------------------------------------------------
Emmanuel Grumbach (1):
iwlwifi: udpate -36 firmware for 8000 series
Luca Coelho (4):
iwlwifi: update Core45 FWs for 22260, 9000 and 9260
iwlwifi: update FWs for 9000 series to Core45-96
iwlwifi: update FW for 22000 to Core45-96
iwlwifi: add new firmwares for integrated 22000 series
WHENCE | 29 +++++++++++++++++++++++++----
iwlwifi-8000C-36.ucode | Bin 2486572 -> 2400700 bytes
iwlwifi-8265-36.ucode | Bin 2498044 -> 2414296 bytes
iwlwifi-9000-pu-b0-jf-b0-46.ucode | Bin 1448644 -> 1460788 bytes
iwlwifi-9260-th-b0-jf-b0-46.ucode | Bin 1456088 -> 1462324 bytes
iwlwifi-Qu-b0-hr-b0-48.ucode | Bin 0 -> 1106208 bytes
iwlwifi-Qu-b0-jf-b0-48.ucode | Bin 0 -> 1053156 bytes
iwlwifi-Qu-c0-hr-b0-48.ucode | Bin 0 -> 1106228 bytes
iwlwifi-Qu-c0-jf-b0-48.ucode | Bin 0 -> 1053176 bytes
iwlwifi-QuZ-a0-hr-b0-48.ucode | Bin 0 -> 1105648 bytes
iwlwifi-QuZ-a0-jf-b0-48.ucode | Bin 0 -> 1052968 bytes
iwlwifi-cc-a0-48.ucode | Bin 0 -> 1096684 bytes
12 files changed, 25 insertions(+), 4 deletions(-)
create mode 100644 iwlwifi-Qu-b0-hr-b0-48.ucode
create mode 100644 iwlwifi-Qu-b0-jf-b0-48.ucode
create mode 100644 iwlwifi-Qu-c0-hr-b0-48.ucode
create mode 100644 iwlwifi-Qu-c0-jf-b0-48.ucode
create mode 100644 iwlwifi-QuZ-a0-hr-b0-48.ucode
create mode 100644 iwlwifi-QuZ-a0-jf-b0-48.ucode
create mode 100644 iwlwifi-cc-a0-48.ucode
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 09/11] mwifiex: update set_mac_address logic
From: Kalle Valo @ 2019-06-20 8:08 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Zhiyuan Yang,
James Cao, Rakesh Parmar, Sharvari Harisangam
In-Reply-To: <MN2PR18MB2637F76B11A51E34A8586208A0EC0@MN2PR18MB2637.namprd18.prod.outlook.com>
Ganapathi Bhat <gbhat@marvell.com> writes:
> This change is correct one, but I missed changing the .patch file name before sending. Let me know if this needs to be resend.
I don't understand your comment. Are you saying that even if this is
marked as "9/11" this was supposed to submitted as a single patch? If
that's the case, no need to resend.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH 09/11] mwifiex: update set_mac_address logic
From: Ganapathi Bhat @ 2019-06-20 8:18 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Zhiyuan Yang,
James Cao, Rakesh Parmar, Sharvari Harisangam
In-Reply-To: <875zp0u1ao.fsf@purkki.adurom.net>
Hi Kalle,
> I don't understand your comment. Are you saying that even if this is marked
> as "9/11" this was supposed to submitted as a single patch? If that's the case,
> no need to resend.
Yes; That is the case;
Thanks,
Ganapathi
^ permalink raw reply
* [PATCH] iwlwifi: add support for hr1 RF ID
From: Luca Coelho @ 2019-06-20 8:46 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Oren Givon, stable, Luciano Coelho
From: Oren Givon <oren.givon@intel.com>
The 22000 series FW that was meant to be used with hr is
also the FW that is used for hr1 and has a different RF ID.
Add support to load the hr FW when hr1 RF ID is detected.
Cc: stable@vger.kernel.org # 5.1+
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 1 +
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 8 +++++---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-csr.h b/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
index 553554846009..93da96a7247c 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
@@ -336,6 +336,7 @@ enum {
/* RF_ID value */
#define CSR_HW_RF_ID_TYPE_JF (0x00105100)
#define CSR_HW_RF_ID_TYPE_HR (0x0010A000)
+#define CSR_HW_RF_ID_TYPE_HR1 (0x0010c100)
#define CSR_HW_RF_ID_TYPE_HRCDB (0x00109F00)
#define CSR_HW_RF_ID_TYPE_GF (0x0010D000)
#define CSR_HW_RF_ID_TYPE_GF4 (0x0010E000)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index b93753233223..38ab24d96244 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -3575,9 +3575,11 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
trans->cfg = &iwlax411_2ax_cfg_so_gf4_a0;
}
} else if (cfg == &iwl_ax101_cfg_qu_hr) {
- if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
- CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
- trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0) {
+ if ((CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
+ CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
+ trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0) ||
+ (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
+ CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR1))) {
trans->cfg = &iwl22000_2ax_cfg_qnj_hr_b0;
} else if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR)) {
--
2.20.1
^ permalink raw reply related
* Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk
From: Arend Van Spriel @ 2019-06-20 9:44 UTC (permalink / raw)
To: Stefan Wahren, Chi-Hsien Lin, Marcel Holtmann
Cc: Stanley Hsu, Franky Lin, Hante Meuleman, Wright Feng,
linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list,
Jouni Malinen
In-Reply-To: <ab26ac30-e49c-8712-f124-8cf996b32a76@gmx.net>
On 6/18/2019 7:03 PM, Stefan Wahren wrote:
> Hi,
>
> Am 18.06.19 um 10:27 schrieb Arend Van Spriel:
>> + Jouni
>>
>> On 6/18/2019 7:33 AM, Chi-Hsien Lin wrote:
>>>
>>>
>>> On 06/17/2019 10:33, Marcel Holtmann wrote:
>>>> Hi Chi-hsien,
>>>>
>>>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA
>>>>>>> side and a
>>>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>>>
>>>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>>>
>>>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>>>
>>>>> Stefan,
>>>>>
>>>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>>>> upstream if it works for you.
> i've forward this patch to the Arch Linux board hoping someone else has
> currently more time.
>>>>
>>>> I hope that someone is also providing a kernel patch to fix the
>>>> issue. Hacking around a kernel issue in userspace is not enough. Fix
>>>> the root cause in the kernel.
>>>
>>> Marcel,
>>>
>>> This is a kernel warning for invalid application PMK set actions, so the
>>> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
>>> Arend added the WARN_ON() intentionally to catch application misuse of
>> > PMK setting.
>>>
>>> You may also remove the warnings with the attached patch, but let's see
>>> what Arend says first.
> Instead of removing the WARN_ON i suggest to replace it with a more user
> friendly dev_warn().
>>>
>>>
>>> Arend,
>>>
>>> Any comment?
>>
>> Hi Chi-Hsien, Marcel
>>
>> From the kernel side I do not see an issue. In order to use 802.1X
>> offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in
>> NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted.
>> The only improvement would be to document this more clearly in the
>> "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.
>
> I missed to add my expectation as a user. At first i assume this new
> behavior in wpa_supplicant 2.8 has been tested successful with at least
> one Linux wifi driver. So i'm curious if all drivers behave that way?
As a matter of fact it has been tested with brcmfmac.
> Another point is that in my wpa_supplicant.conf i never enforced 802.1X
> offload and i assume this feature is optional. So can't we do some kind
> of fallback in this case?
So when the driver indicates it supports the offload, wpa_supplicant opt
in. There is no possibility for the user to opt out.
Regards,
Arend
^ permalink raw reply
* Re: wpa_supplicant 2.8 fails in brcmf_cfg80211_set_pmk
From: Arend Van Spriel @ 2019-06-20 10:04 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Chi-Hsien Lin, Stefan Wahren, Stanley Hsu, Franky Lin,
Hante Meuleman, Wright Feng, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list,
Jouni Malinen
In-Reply-To: <0ABBF42F-1C9C-4564-A27C-511026EB733C@holtmann.org>
On 6/19/2019 7:26 AM, Marcel Holtmann wrote:
> Hi Arend,
>
>>>>>>> i was able to reproduce an (maybe older issue) with 4-way handshake
>>>>>>> offloading for 802.1X in the brcmfmac driver. My setup consists of
>>>>>>> Raspberry Pi 3 B (current linux-next, arm64/defconfig) on STA side and a
>>>>>>> Raspberry Pi 3 A+ (Linux 4.19) on AP side.
>>>>>>
>>>>>> Looks like Raspberry Pi isn't the only affected platform [3], [4].
>>>>>>
>>>>>> [3] - https://bugzilla.redhat.com/show_bug.cgi?id=1665608
>>>>>> [4] - https://bugzilla.kernel.org/show_bug.cgi?id=202521
>>>>>
>>>>> Stefan,
>>>>>
>>>>> Could you please try the attached patch for your wpa_supplicant? We'll
>>>>> upstream if it works for you.
>>>>
>>>> I hope that someone is also providing a kernel patch to fix the issue. Hacking around a kernel issue in userspace is not enough. Fix the root cause in the kernel.
>>> Marcel,
>>> This is a kernel warning for invalid application PMK set actions, so the
>>> fix is to only set PMK to wifi driver when 4-way is offloaded. I think
>>> Arend added the WARN_ON() intentionally to catch application misuse of
>>> PMK setting.
>>> You may also remove the warnings with the attached patch, but let's see
>>> what Arend says first.
>>> Arend,
>>> Any comment?
>>
>> Hi Chi-Hsien, Marcel
>>
>> From the kernel side I do not see an issue. In order to use 802.1X offload the NL80211_ATTR_WANT_1X_4WAY_HS flag must be set in NL80211_CMD_CONNECT. Otherwise, NL80211_CMD_SET_PMK is not accepted. The only improvement would be to document this more clearly in the "WPA/WPA2 EAPOL handshake offload" DOC section in nl80211.h.
>
> so nl80211 is an API. And an application can use that API wrongly (be that intentionally or unintentionally), the kernel can not just go WARN_ON and print a backtrace. That is your bug. So please handle wrong user input properly.
Hi Marcel,
You are right. However, the kernel does also return an error if the
WARN_ON is hit. We can improve by using the EXT_ACK functionality to
provide more info than just -EINVAL, eg. "PMK not accepted; no 802.1X
offload requested on connect".
> Frankly, I don’t get why nl80211 itself is not validating the input and this is left to the driver. I think we need a nl80211 fuzzer that really exercises this API with random values and parameters to provide invalid input.
That would mean nl80211 should keep state info between commands. From
what I remember that has been avoided from day one because of the
experiences with that in the WEXT days. I welcome any testing be it
fuzzer or something else.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] iwlwifi: add support for hr1 RF ID
From: Luciano Coelho @ 2019-06-20 10:30 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Oren Givon, stable
In-Reply-To: <20190620084623.12014-1-luca@coelho.fi>
Hi Kalle,
Please take this to 5.1-rc* as well.
--
Cheers,
Luca.
On Thu, 2019-06-20 at 11:46 +0300, Luca Coelho wrote:
> From: Oren Givon <oren.givon@intel.com>
>
> The 22000 series FW that was meant to be used with hr is
> also the FW that is used for hr1 and has a different RF ID.
> Add support to load the hr FW when hr1 RF ID is detected.
>
> Cc: stable@vger.kernel.org # 5.1+
> Signed-off-by: Oren Givon <oren.givon@intel.com>
> Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
> ---
> drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 1 +
> drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 8 +++++---
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-csr.h b/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
> index 553554846009..93da96a7247c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-csr.h
> @@ -336,6 +336,7 @@ enum {
> /* RF_ID value */
> #define CSR_HW_RF_ID_TYPE_JF (0x00105100)
> #define CSR_HW_RF_ID_TYPE_HR (0x0010A000)
> +#define CSR_HW_RF_ID_TYPE_HR1 (0x0010c100)
> #define CSR_HW_RF_ID_TYPE_HRCDB (0x00109F00)
> #define CSR_HW_RF_ID_TYPE_GF (0x0010D000)
> #define CSR_HW_RF_ID_TYPE_GF4 (0x0010E000)
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> index b93753233223..38ab24d96244 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> @@ -3575,9 +3575,11 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
> trans->cfg = &iwlax411_2ax_cfg_so_gf4_a0;
> }
> } else if (cfg == &iwl_ax101_cfg_qu_hr) {
> - if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
> - CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
> - trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0) {
> + if ((CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
> + CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR) &&
> + trans->hw_rev == CSR_HW_REV_TYPE_QNJ_B0) ||
> + (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
> + CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR1))) {
> trans->cfg = &iwl22000_2ax_cfg_qnj_hr_b0;
> } else if (CSR_HW_RF_ID_TYPE_CHIP_ID(trans->hw_rf_id) ==
> CSR_HW_RF_ID_TYPE_CHIP_ID(CSR_HW_RF_ID_TYPE_HR)) {
^ permalink raw reply
* Re: [PATCH] iwlwifi: add support for hr1 RF ID
From: Luciano Coelho @ 2019-06-20 10:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Oren Givon, stable
In-Reply-To: <26ffc4023329e2421e459837bdcb92672f26cb62.camel@intel.com>
On Thu, 2019-06-20 at 13:30 +0300, Luciano Coelho wrote:
> Hi Kalle,
>
> Please take this to 5.1-rc* as well.
I obviously meant 5.2-rc*.
Thanks!
--
Luca.
^ permalink raw reply
* [PATCH v4] mt76: mt76u: reduce rx memory footprint
From: Lorenzo Bianconi @ 2019-06-20 10:39 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sgruszka
Reduce rx memory footprint allocating just one SG buffer since for the
moment we support just 3839B as maximal size of an A-MSDU.
Introduce different SG_MAX_SIZE definitions for TX and RX sides.
Moreover set q->buf_size to PAGE_SIZE even for SG case.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes since v3:
- drop patch 2/3: mt76u: introduce mt76u_ep data structure
- do not align usb buffer size to usb max endpoint length
---
drivers/net/wireless/mediatek/mt76/mt76.h | 3 ++-
.../net/wireless/mediatek/mt76/mt76x0/usb.c | 2 +-
.../wireless/mediatek/mt76/mt76x2/usb_init.c | 2 +-
drivers/net/wireless/mediatek/mt76/usb.c | 18 +++++++++++-------
4 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 23a5ebefac3a..eee83c369a64 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -384,7 +384,8 @@ enum mt76u_out_ep {
__MT_EP_OUT_MAX,
};
-#define MT_SG_MAX_SIZE 8
+#define MT_TX_SG_MAX_SIZE 8
+#define MT_RX_SG_MAX_SIZE 1
#define MT_NUM_TX_ENTRIES 256
#define MT_NUM_RX_ENTRIES 128
#define MCU_RESP_URB_SIZE 1024
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
index 7c38ec4418db..5b9701ce6f37 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
@@ -191,7 +191,7 @@ static int mt76x0u_register_device(struct mt76x02_dev *dev)
/* check hw sg support in order to enable AMSDU */
if (dev->mt76.usb.sg_en)
- hw->max_tx_fragments = MT_SG_MAX_SIZE;
+ hw->max_tx_fragments = MT_TX_SG_MAX_SIZE;
else
hw->max_tx_fragments = 1;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
index f2c57d5b87f9..94f52f98019b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/usb_init.c
@@ -225,7 +225,7 @@ int mt76x2u_register_device(struct mt76x02_dev *dev)
/* check hw sg support in order to enable AMSDU */
if (dev->mt76.usb.sg_en)
- hw->max_tx_fragments = MT_SG_MAX_SIZE;
+ hw->max_tx_fragments = MT_TX_SG_MAX_SIZE;
else
hw->max_tx_fragments = 1;
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index dd90427b2d67..ecc1aa59f5c1 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -333,12 +333,13 @@ mt76u_refill_rx(struct mt76_dev *dev, struct urb *urb, int nsgs, gfp_t gfp)
}
static int
-mt76u_urb_alloc(struct mt76_dev *dev, struct mt76_queue_entry *e)
+mt76u_urb_alloc(struct mt76_dev *dev, struct mt76_queue_entry *e,
+ int sg_max_size)
{
unsigned int size = sizeof(struct urb);
if (dev->usb.sg_en)
- size += MT_SG_MAX_SIZE * sizeof(struct scatterlist);
+ size += sg_max_size * sizeof(struct scatterlist);
e->urb = kzalloc(size, GFP_KERNEL);
if (!e->urb)
@@ -357,11 +358,12 @@ mt76u_rx_urb_alloc(struct mt76_dev *dev, struct mt76_queue_entry *e)
{
int err;
- err = mt76u_urb_alloc(dev, e);
+ err = mt76u_urb_alloc(dev, e, MT_RX_SG_MAX_SIZE);
if (err)
return err;
- return mt76u_refill_rx(dev, e->urb, MT_SG_MAX_SIZE, GFP_KERNEL);
+ return mt76u_refill_rx(dev, e->urb, MT_RX_SG_MAX_SIZE,
+ GFP_KERNEL);
}
static void mt76u_urb_free(struct urb *urb)
@@ -605,8 +607,9 @@ static int mt76u_alloc_rx(struct mt76_dev *dev)
if (!q->entry)
return -ENOMEM;
- q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
q->ndesc = MT_NUM_RX_ENTRIES;
+ q->buf_size = PAGE_SIZE;
+
for (i = 0; i < q->ndesc; i++) {
err = mt76u_rx_urb_alloc(dev, &q->entry[i]);
if (err < 0)
@@ -763,7 +766,7 @@ mt76u_tx_setup_buffers(struct mt76_dev *dev, struct sk_buff *skb,
urb->transfer_buffer = skb->data;
return 0;
} else {
- sg_init_table(urb->sg, MT_SG_MAX_SIZE);
+ sg_init_table(urb->sg, MT_TX_SG_MAX_SIZE);
urb->num_sgs = skb_to_sgvec(skb, urb->sg, 0, skb->len);
if (urb->num_sgs == 0)
return -ENOMEM;
@@ -857,7 +860,8 @@ static int mt76u_alloc_tx(struct mt76_dev *dev)
q->ndesc = MT_NUM_TX_ENTRIES;
for (j = 0; j < q->ndesc; j++) {
- err = mt76u_urb_alloc(dev, &q->entry[j]);
+ err = mt76u_urb_alloc(dev, &q->entry[j],
+ MT_TX_SG_MAX_SIZE);
if (err < 0)
return err;
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v3 0/7] Hexdump Enhancements
From: Jani Nikula @ 2019-06-20 10:50 UTC (permalink / raw)
To: Joe Perches, Alastair D'Silva
Cc: Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Dan Carpenter, Karsten Keil, Jassi Brar, Tom Lendacky,
David S. Miller, Jose Abreu, Kalle Valo, Stanislaw Gruszka,
Benson Leung, Enric Balletbo i Serra, James E.J. Bottomley,
Martin K. Petersen, Greg Kroah-Hartman, Alexander Viro,
Petr Mladek, Sergey Senozhatsky, Steven Rostedt, David Laight,
Andrew Morton, intel-gfx, dri-devel, linux-kernel, netdev, ath10k,
linux-wireless, linux-scsi, linux-fbdev, devel, linux-fsdevel
In-Reply-To: <fcf57339aea60fb1744cea2a2593656c728c4ec4.camel@perches.com>
On Wed, 19 Jun 2019, Joe Perches <joe@perches.com> wrote:
> On Thu, 2019-06-20 at 11:14 +1000, Alastair D'Silva wrote:
>> On Wed, 2019-06-19 at 17:35 -0700, Joe Perches wrote:
>> > On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
>> > > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
>> > > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
>> > > > > From: Alastair D'Silva <alastair@d-silva.org>
>> > > > >
>> > > > > Apologies for the large CC list, it's a heads up for those
>> > > > > responsible
>> > > > > for subsystems where a prototype change in generic code causes
>> > > > > a
>> > > > > change
>> > > > > in those subsystems.
>> > > > >
>> > > > > This series enhances hexdump.
>> > > >
>> > > > Still not a fan of these patches.
>> > >
>> > > I'm afraid there's not too much action I can take on that, I'm
>> > > happy to
>> > > address specific issues though.
>> > >
>> > > > > These improve the readability of the dumped data in certain
>> > > > > situations
>> > > > > (eg. wide terminals are available, many lines of empty bytes
>> > > > > exist,
>> > > > > etc).
>> >
>> > I think it's generally overkill for the desired uses.
>>
>> I understand where you're coming from, however, these patches make it a
>> lot easier to work with large chucks of binary data. I think it makes
>> more sense to have these patches upstream, even though committed code
>> may not necessarily have all the features enabled, as it means that
>> devs won't have to apply out-of-tree patches during development to make
>> larger dumps manageable.
>>
>> > > > Changing hexdump's last argument from bool to int is odd.
>> > > >
>> > >
>> > > Think of it as replacing a single boolean with many booleans.
>> >
>> > I understand it. It's odd.
>> >
>> > I would rather not have a mixture of true, false, and apparently
>> > random collections of bitfields like 0xd or 0b1011 or their
>> > equivalent or'd defines.
>> >
>>
>> Where's the mixture? What would you propose instead?
>
> create a hex_dump_to_buffer_ext with a new argument
> and a new static inline for the old hex_dump_to_buffer
> without modifying the argument list that calls
> hex_dump_to_buffer with whatever added argument content
> you need.
>
> Something like:
>
> static inline
> int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
> int groupsize, char *linebuf, size_t linebuflen,
> bool ascii)
> {
> return hex_dump_to_buffer_ext(buf, len, rowsize, groupsize,
> linebuf, linebuflen, ascii, 0);
> }
>
> and remove EXPORT_SYMBOL(hex_dump_to_buffer)
If you decide to do something like this, I'd actually suggest you drop
the bool ascii parameter from hex_dump_to_buffer() altogether, and
replace the callers that do require ascii with
hex_dump_to_buffer_ext(..., HEXDUMP_ASCII). Even if that also requires
touching all callers.
But no strong opinions, really.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: use exact allocation for dma coherent memory
From: Christoph Hellwig @ 2019-06-20 10:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Christoph Hellwig, Potnuri Bharat Teja, Dan Carpenter,
Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Ian Abbott, H Hartley Sweeten, devel, linux-s390,
Intel Linux Wireless, linux-rdma, netdev, intel-gfx,
linux-wireless, linux-kernel, dri-devel, linux-mm, iommu,
moderated list:ARM PORT, linux-media
In-Reply-To: <20190619162903.GF9360@ziepe.ca>
On Wed, Jun 19, 2019 at 01:29:03PM -0300, Jason Gunthorpe wrote:
> > Yes. This will blow up badly on many platforms, as sq->queue
> > might be vmapped, ioremapped, come from a pool without page backing.
>
> Gah, this addr gets fed into io_remap_pfn_range/remap_pfn_range too..
>
> Potnuri, you should fix this..
>
> You probably need to use dma_mmap_from_dev_coherent() in the mmap ?
The function to use is dma_mmap_coherent, dma_mmap_from_dev_coherent is
just an internal helper.
That beiŋ said the drivers/infiniband code has a lot of
*remap_pfn_range, and a lot of them look like they might be for
DMA memory.
^ permalink raw reply
* Re: pull request: iwlwifi firmware updates 2019-06-20
From: Josh Boyer @ 2019-06-20 11:07 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
linuxwifi, kyle@infradead.org, ben@decadent.org.uk
In-Reply-To: <86eada55d771732ac0477a008d3c5f0a61570952.camel@coelho.fi>
On Thu, Jun 20, 2019 at 4:16 AM Luca Coelho <luca@coelho.fi> wrote:
>
> Hi,
>
> This contains some updated firmwares for the 9000 and 22000 series of
> devices, and new firmwares for new integrated 22000 series devices.
>
> Please pull or let me know if there are any issues.
>
> --
> Cheers,
> Luca.
>
>
> The following changes since commit acb56f2fae3235195bc99ecb7d09742fb4b65e63:
>
> cavium: Add firmware for CNN55XX crypto driver. (2019-06-18 09:12:52 -0400)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2019-06-20
Pulled and pushed out.
josh
^ permalink raw reply
* [GIT PULL] MMC fixes for v5.2-rc6
From: Ulf Hansson @ 2019-06-20 11:16 UTC (permalink / raw)
To: Linus, linux-mmc, linux-kernel
Cc: Ulf Hansson, Douglas Anderson, Kalle Valo, Arend van Spriel,
linux-wireless, Adrian Hunter
Hi Linus,
Here's a PR with quite a few MMC fixes intended for v5.2-rc6. This time the PR
also contains fixes for a WiFi driver, which device is attached to the SDIO
interface. Patches for the WiFi driver have been acked by the corresponding
maintainers. More details about the highlights are as usual found in the signed
tag.
Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:
Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.2-rc4
for you to fetch changes up to 83293386bc95cf5e9f0c0175794455835bd1cb4a:
mmc: core: Prevent processing SDIO IRQs when the card is suspended (2019-06-18 14:06:32 +0200)
----------------------------------------------------------------
MMC core:
- Make switch to eMMC HS400 more robust for some controllers
- Add two SDIO func API to manage re-tuning constraints
- Prevent processing SDIO IRQs when the card is suspended
MMC host:
- sdhi: Disallow broken HS400 for M3-W ES1.2, RZ/G2M and V3H
- mtk-sd: Fixup support for SDIO IRQs
- sdhci-pci-o2micro: Fixup support for tuning
Wireless BRCMFMAC (SDIO):
- Deal with expected transmission errors related to the idle states
(handled by the Always-On-Subsystem or AOS) on the SDIO-based WiFi on
rk3288-veyron-minnie, rk3288-veyron-speedy and rk3288-veyron-mickey.
----------------------------------------------------------------
Douglas Anderson (5):
Revert "brcmfmac: disable command decode in sdio_aos"
mmc: core: API to temporarily disable retuning for SDIO CRC errors
brcmfmac: sdio: Disable auto-tuning around commands expected to fail
mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()
brcmfmac: sdio: Don't tune while the card is off
Raul E Rangel (1):
mmc: sdhci: sdhci-pci-o2micro: Correctly set bus width when tuning
Ulf Hansson (1):
mmc: core: Prevent processing SDIO IRQs when the card is suspended
Wolfram Sang (2):
mmc: sdhi: disallow HS400 for M3-W ES1.2, RZ/G2M, and V3H
mmc: core: complete HS400 before checking status
jjian zhou (2):
mmc: mediatek: fix SDIO IRQ interrupt handle flow
mmc: mediatek: fix SDIO IRQ detection issue
drivers/mmc/core/core.c | 5 +-
drivers/mmc/core/mmc.c | 6 +-
drivers/mmc/core/sdio.c | 13 +++-
drivers/mmc/core/sdio_io.c | 77 ++++++++++++++++++++++
drivers/mmc/core/sdio_irq.c | 4 ++
drivers/mmc/host/mtk-sd.c | 39 ++++++-----
drivers/mmc/host/renesas_sdhi_core.c | 9 ++-
drivers/mmc/host/sdhci-pci-o2micro.c | 5 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 17 +++--
include/linux/mmc/host.h | 1 +
include/linux/mmc/sdio_func.h | 6 ++
11 files changed, 151 insertions(+), 31 deletions(-)
^ permalink raw reply
* [PATCH] Add SPDX identifiers
From: yegorslists @ 2019-06-20 13:01 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Yegor Yefremov
From: Yegor Yefremov <yegorslists@googlemail.com>
Software Package Data Exchange identifiers help to detect source file
licenses and hence simplify the FOSS compliance process.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
ap.c | 2 ++
bitrate.c | 2 ++
bloom.c | 2 ++
coalesce.c | 2 ++
connect.c | 2 ++
cqm.c | 2 ++
event.c | 2 ++
ftm.c | 2 ++
genl.c | 2 ++
hwsim.c | 2 ++
ibss.c | 2 ++
ieee80211.h | 2 ++
info.c | 2 ++
interface.c | 2 ++
iw.c | 2 ++
iw.h | 2 ++
link.c | 2 ++
measurements.c | 2 ++
mesh.c | 2 ++
mgmt.c | 2 ++
mpath.c | 2 ++
mpp.c | 2 ++
nan.c | 2 ++
nl80211.h | 2 ++
ocb.c | 2 ++
offch.c | 2 ++
p2p.c | 2 ++
phy.c | 2 ++
ps.c | 2 ++
reason.c | 2 ++
reg.c | 2 ++
roc.c | 2 ++
scan.c | 2 ++
sections.c | 2 ++
sha256.c | 2 ++
sha256.h | 2 ++
station.c | 2 ++
status.c | 2 ++
survey.c | 2 ++
util.c | 2 ++
vendor.c | 2 ++
wowlan.c | 2 ++
42 files changed, 84 insertions(+)
diff --git a/ap.c b/ap.c
index db9efb7..4b9157a 100644
--- a/ap.c
+++ b/ap.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
#include <netlink/genl/family.h>
diff --git a/bitrate.c b/bitrate.c
index 4a026a4..c0ff319 100644
--- a/bitrate.c
+++ b/bitrate.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include "nl80211.h"
diff --git a/bloom.c b/bloom.c
index 877a6b5..f697b94 100644
--- a/bloom.c
+++ b/bloom.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <inttypes.h>
#include "iw.h"
diff --git a/coalesce.c b/coalesce.c
index 36dcaef..f3826ca 100644
--- a/coalesce.c
+++ b/coalesce.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdio.h>
diff --git a/connect.c b/connect.c
index 3237a27..a486d21 100644
--- a/connect.c
+++ b/connect.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/cqm.c b/cqm.c
index 093b744..4e2e846 100644
--- a/cqm.c
+++ b/cqm.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/event.c b/event.c
index 100f644..a8b4611 100644
--- a/event.c
+++ b/event.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdint.h>
#include <stdbool.h>
#include <net/if.h>
diff --git a/ftm.c b/ftm.c
index 23be38e..03eaf38 100644
--- a/ftm.c
+++ b/ftm.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/genl.c b/genl.c
index 7dc27f7..f8dbac3 100644
--- a/genl.c
+++ b/genl.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
/*
* This ought to be provided by libnl
*/
diff --git a/hwsim.c b/hwsim.c
index 6f82207..fbfaed3 100644
--- a/hwsim.c
+++ b/hwsim.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/ibss.c b/ibss.c
index f6cbc4c..645639e 100644
--- a/ibss.c
+++ b/ibss.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <strings.h>
diff --git a/ieee80211.h b/ieee80211.h
index 8745608..0a7e205 100644
--- a/ieee80211.h
+++ b/ieee80211.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef __IEEE80211
#define __IEEE80211
diff --git a/info.c b/info.c
index e6270c8..fc0361d 100644
--- a/info.c
+++ b/info.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdbool.h>
#include <netlink/genl/genl.h>
diff --git a/interface.c b/interface.c
index b697482..de5546b 100644
--- a/interface.c
+++ b/interface.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdbool.h>
diff --git a/iw.c b/iw.c
index da71617..5bb22c4 100644
--- a/iw.c
+++ b/iw.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
/*
* nl80211 userspace tool
*
diff --git a/iw.h b/iw.h
index bc0b3ac..ea7bd6c 100644
--- a/iw.h
+++ b/iw.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef __IW_H
#define __IW_H
diff --git a/link.c b/link.c
index 1ed7f63..4e73279 100644
--- a/link.c
+++ b/link.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/measurements.c b/measurements.c
index 385143f..54ca402 100644
--- a/measurements.c
+++ b/measurements.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include "nl80211.h"
diff --git a/mesh.c b/mesh.c
index 0650d0c..2591a4b 100644
--- a/mesh.c
+++ b/mesh.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/mgmt.c b/mgmt.c
index 338435d..8639f9c 100644
--- a/mgmt.c
+++ b/mgmt.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <string.h>
#include <errno.h>
diff --git a/mpath.c b/mpath.c
index e39c24b..3cb465b 100644
--- a/mpath.c
+++ b/mpath.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/mpp.c b/mpp.c
index 58bf28e..23193a4 100644
--- a/mpp.c
+++ b/mpp.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
diff --git a/nan.c b/nan.c
index 1d8d795..a846b68 100644
--- a/nan.c
+++ b/nan.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/nl80211.h b/nl80211.h
index 6f09d15..750b116 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef __LINUX_NL80211_H
#define __LINUX_NL80211_H
/*
diff --git a/ocb.c b/ocb.c
index fc9579b..1678e49 100644
--- a/ocb.c
+++ b/ocb.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/offch.c b/offch.c
index 19e170e..684eea3 100644
--- a/offch.c
+++ b/offch.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <netlink/genl/genl.h>
diff --git a/p2p.c b/p2p.c
index 2d4bab0..1d12046 100644
--- a/p2p.c
+++ b/p2p.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <netlink/genl/genl.h>
#include <netlink/genl/family.h>
#include <netlink/genl/ctrl.h>
diff --git a/phy.c b/phy.c
index 716677e..a5159c7 100644
--- a/phy.c
+++ b/phy.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdbool.h>
#include <errno.h>
#include <strings.h>
diff --git a/ps.c b/ps.c
index de36d2b..67f7a38 100644
--- a/ps.c
+++ b/ps.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/reason.c b/reason.c
index f91c681..74f516b 100644
--- a/reason.c
+++ b/reason.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdint.h>
#include "iw.h"
diff --git a/reg.c b/reg.c
index a2368df..7a83df2 100644
--- a/reg.c
+++ b/reg.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdbool.h>
diff --git a/roc.c b/roc.c
index c6eda10..a159487 100644
--- a/roc.c
+++ b/roc.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/scan.c b/scan.c
index 6ad3ad4..1993f0b 100644
--- a/scan.c
+++ b/scan.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/sections.c b/sections.c
index 38095f6..3b0ec8b 100644
--- a/sections.c
+++ b/sections.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include "iw.h"
SECTION(get);
diff --git a/sha256.c b/sha256.c
index 4a43df8..da9d967 100644
--- a/sha256.c
+++ b/sha256.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include "sha256.h"
/**
diff --git a/sha256.h b/sha256.h
index d3eb3c0..4a32604 100644
--- a/sha256.h
+++ b/sha256.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#ifndef SHA256
#define SHA256
diff --git a/station.c b/station.c
index aaad079..d8f0ae3 100644
--- a/station.c
+++ b/station.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <errno.h>
#include <string.h>
diff --git a/status.c b/status.c
index 731727d..7529021 100644
--- a/status.c
+++ b/status.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <stdint.h>
#include "iw.h"
diff --git a/survey.c b/survey.c
index 9325353..ffaf85a 100644
--- a/survey.c
+++ b/survey.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <net/if.h>
#include <netlink/genl/genl.h>
diff --git a/util.c b/util.c
index 41277b5..55993c7 100644
--- a/util.c
+++ b/util.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <ctype.h>
#include <netlink/attr.h>
#include <errno.h>
diff --git a/vendor.c b/vendor.c
index d203d85..7610354 100644
--- a/vendor.c
+++ b/vendor.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
diff --git a/wowlan.c b/wowlan.c
index 778c0db..71392d1 100644
--- a/wowlan.c
+++ b/wowlan.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: ISC */
+
#include <errno.h>
#include <string.h>
#include <stdio.h>
--
2.17.0
^ permalink raw reply related
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