* [PATCH v2 1/7] rt2x00: allow to specify watchdog interval
From: Stanislaw Gruszka @ 2019-06-15 10:00 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
In-Reply-To: <20190615100100.29800-1-sgruszka@redhat.com>
Allow subdriver to change watchdog interval by intialize
link->watchdog_interval value before rt2x00link_register().
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2x00link.c | 13 +++++++++----
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index 64a792a8fb2c..2b551dbe9844 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -325,6 +325,7 @@ struct link {
* to bring the device/driver back into the desired state.
*/
struct delayed_work watchdog_work;
+ unsigned int watchdog_interval;
/*
* Work structure for scheduling periodic AGC adjustments.
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00link.c b/drivers/net/wireless/ralink/rt2x00/rt2x00link.c
index 939cfa5141c6..15ebebf88e72 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00link.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00link.c
@@ -387,7 +387,7 @@ void rt2x00link_start_watchdog(struct rt2x00_dev *rt2x00dev)
rt2x00dev->ops->lib->watchdog)
ieee80211_queue_delayed_work(rt2x00dev->hw,
&link->watchdog_work,
- WATCHDOG_INTERVAL);
+ link->watchdog_interval);
}
void rt2x00link_stop_watchdog(struct rt2x00_dev *rt2x00dev)
@@ -413,11 +413,16 @@ static void rt2x00link_watchdog(struct work_struct *work)
if (test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
ieee80211_queue_delayed_work(rt2x00dev->hw,
&link->watchdog_work,
- WATCHDOG_INTERVAL);
+ link->watchdog_interval);
}
void rt2x00link_register(struct rt2x00_dev *rt2x00dev)
{
- INIT_DELAYED_WORK(&rt2x00dev->link.watchdog_work, rt2x00link_watchdog);
- INIT_DELAYED_WORK(&rt2x00dev->link.work, rt2x00link_tuner);
+ struct link *link = &rt2x00dev->link;
+
+ INIT_DELAYED_WORK(&link->work, rt2x00link_tuner);
+ INIT_DELAYED_WORK(&link->watchdog_work, rt2x00link_watchdog);
+
+ if (link->watchdog_interval == 0)
+ link->watchdog_interval = WATCHDOG_INTERVAL;
}
--
2.20.1
^ permalink raw reply related
* [PATCH v2 0/7] rt2800: add experimental watchdog implementation
From: Stanislaw Gruszka @ 2019-06-15 10:00 UTC (permalink / raw)
To: linux-wireless
Cc: Tomislav Požega, Daniel Golle, Felix Fietkau, Mathias Kresin
Add watchdog to address some remaining problems of Ralink devices
random hungs.
RFC -> v1
- better description for module parameter
- fix white space
v1 -> v2:
- rebase on latest tree.
Stanislaw Gruszka (7):
rt2x00: allow to specify watchdog interval
rt2800: add helpers for reading dma done index
rt2800: initial watchdog implementation
rt2800: add pre_reset_hw callback
rt2800: do not nullify initialization vector data
rt2x00: add restart hw
rt2800: do not enable watchdog by default
.../net/wireless/ralink/rt2x00/rt2800lib.c | 96 ++++++++++++++++++-
.../net/wireless/ralink/rt2x00/rt2800lib.h | 11 +++
.../net/wireless/ralink/rt2x00/rt2800mmio.c | 31 ++++++
.../net/wireless/ralink/rt2x00/rt2800mmio.h | 2 +
.../net/wireless/ralink/rt2x00/rt2800pci.c | 3 +
.../net/wireless/ralink/rt2x00/rt2800soc.c | 3 +
.../net/wireless/ralink/rt2x00/rt2800usb.c | 11 +++
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 10 ++
.../net/wireless/ralink/rt2x00/rt2x00debug.c | 35 +++++++
.../net/wireless/ralink/rt2x00/rt2x00dev.c | 10 +-
.../net/wireless/ralink/rt2x00/rt2x00link.c | 15 ++-
.../net/wireless/ralink/rt2x00/rt2x00queue.h | 6 ++
12 files changed, 221 insertions(+), 12 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH] p54: remove dead branch in op_conf_tx callback
From: Christian Lamparter @ 2019-06-15 10:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Kalle Valo
In-Reply-To: <20190615100009.14654-1-chunkeey@gmail.com>
This patch removes the error branch for (queue > dev->queues).
It is no longer needed anymore as the "queue" value is validated by
cfg80211's parse_txq_params() before the driver code gets called.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
drivers/net/wireless/intersil/p54/main.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/intersil/p54/main.c b/drivers/net/wireless/intersil/p54/main.c
index 1c6d428515a4..4cc0ece0cd0e 100644
--- a/drivers/net/wireless/intersil/p54/main.c
+++ b/drivers/net/wireless/intersil/p54/main.c
@@ -414,12 +414,9 @@ static int p54_conf_tx(struct ieee80211_hw *dev,
int ret;
mutex_lock(&priv->conf_mutex);
- if (queue < dev->queues) {
- P54_SET_QUEUE(priv->qos_params[queue], params->aifs,
- params->cw_min, params->cw_max, params->txop);
- ret = p54_set_edcf(priv);
- } else
- ret = -EINVAL;
+ P54_SET_QUEUE(priv->qos_params[queue], params->aifs,
+ params->cw_min, params->cw_max, params->txop);
+ ret = p54_set_edcf(priv);
mutex_unlock(&priv->conf_mutex);
return ret;
}
--
2.20.1
^ permalink raw reply related
* [PATCH] carl9170: remove dead branch in op_conf_tx callback
From: Christian Lamparter @ 2019-06-15 10:00 UTC (permalink / raw)
To: linux-wireless; +Cc: Kalle Valo
This patch removes the error branch for (queue > ar->hw->queues).
It is no longer needed anymore as the "queue" value is validated by
cfg80211's parse_txq_params() before the driver code gets called.
Some background:
In the old days (linux 2.6 and early 3.x), the parse_txq_params()
function did not verify the "queue" value. That's why these drivers
had to do it.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
drivers/net/wireless/ath/carl9170/main.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
index 7f1bdea742b8..40a8054f8aa6 100644
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -1387,13 +1387,8 @@ static int carl9170_op_conf_tx(struct ieee80211_hw *hw,
int ret;
mutex_lock(&ar->mutex);
- if (queue < ar->hw->queues) {
- memcpy(&ar->edcf[ar9170_qmap[queue]], param, sizeof(*param));
- ret = carl9170_set_qos(ar);
- } else {
- ret = -EINVAL;
- }
-
+ memcpy(&ar->edcf[ar9170_qmap[queue]], param, sizeof(*param));
+ ret = carl9170_set_qos(ar);
mutex_unlock(&ar->mutex);
return ret;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v3 wireless-drivers 3/3] mt76: usb: do not always copy the first part of received frames
From: Stanislaw Gruszka @ 2019-06-15 9:40 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Lorenzo Bianconi, kvalo, linux-wireless, nbd
In-Reply-To: <20190614124635.GD2669@localhost.localdomain>
On Fri, Jun 14, 2019 at 02:46:36PM +0200, Lorenzo Bianconi wrote:
> > >
> > > ack, right. I think patch 2/3 and 3/3 can go directly in Felix's tree
> > >
> > > >
> > > > > + int i, data_size;
> > > > >
> > > > > + data_size = rounddown(SKB_WITH_OVERHEAD(q->buf_size),
> > > > > + dev->usb.in_ep[MT_EP_IN_PKT_RX].max_packet);
> > > > > for (i = 0; i < nsgs; i++) {
> > > > > struct page *page;
> > > > > void *data;
> > > > > @@ -302,7 +304,7 @@ mt76u_fill_rx_sg(struct mt76_dev *dev, struct mt76_queue *q, struct urb *urb,
> > > > >
> > > > > page = virt_to_head_page(data);
> > > > > offset = data - page_address(page);
> > > > > - sg_set_page(&urb->sg[i], page, q->buf_size, offset);
> > > > > + sg_set_page(&urb->sg[i], page, data_size, offset);
> > > > <snip>
> > > > > - q->buf_size = dev->usb.sg_en ? MT_RX_BUF_SIZE : PAGE_SIZE;
> > > > > q->ndesc = MT_NUM_RX_ENTRIES;
> > > > > + q->buf_size = PAGE_SIZE;
> > > > > +
> > > >
> > > > This should be associated with decrease of MT_SG_MAX_SIZE to value that
> > > > is actually needed and currently this is 2 for 4k AMSDU.
> > >
> > > MT_SG_MAX_SIZE is used even on tx side and I do not think we will end up with a
> > > huge difference here
> >
> > So use different value as argument for mt76u_fill_rx_sg() in
> > mt76u_rx_urb_alloc(). After changing buf_size to PAGE_SIZE we will
> > allocate 8 pages per rx queue entry, but only 2 pages will be used
> > (with data_size change, 1 without data_size change). Or I'm wrong?
>
> yes, it is right (we will use two pages with data_size change). Maybe better to
> use 4 pages for each rx queue entry? (otherwise we will probably change it in
> the future)
We should not allocate more than is required. If support for bigger
rx AMSDUs will be added and announced in vht/ht capabilities to remote
stations, then increase of number of segments will be needed.
> > > > However I don't think allocating 2 pages to avoid ieee80211 header and SNAP
> > > > copy is worth to do. For me best approach would be allocate 1 page for
> > > > 4k AMSDU, 2 for 8k and 3 for 12k (still using sg, but without data_size
> > > > change to avoid 32B copying).
> > >
> > > From my point of view it is better to avoid copying if it is possible. Are you
> > > sure there is no difference?
> >
> > I do not understand what you mean by difference here.
>
> tpt differences, not sure if there are any
I would not expect any measurable difference in tpt nor in cpu usage
either way.
But I think, if some AMSDU subframe will be spited into two fragments,
data most likely will need to be linearised/copied, at some point before
passed to application, what will overcome any benefit of avoiding coping
802.11 header. Thought, I don't think this somehow will be visible in
benchmarking.
Stanislaw
^ permalink raw reply
* Re: [PATCH 2/2] mwifiex: Abort at too short BSS descriptor element
From: Brian Norris @ 2019-06-15 0:19 UTC (permalink / raw)
To: Takashi Iwai
Cc: linux-wireless, Amitkumar Karwar, Nishant Sarmukadam,
Ganapathi Bhat, Xinming Hu, Kalle Valo, huangwen, Solar Designer,
Marcus Meissner
In-Reply-To: <20190613174938.GA260350@google.com>
Hi,
On Thu, Jun 13, 2019 at 10:49 AM Brian Norris <briannorris@chromium.org> wrote:
> "element_len + 2" would be much more readable as "total_ie_len". (Same for
> several other usages in this patch.) I can send such a patch myself as a
> follow-up I suppose.
[...]
> It seems like we should only be validating the standard pieces (e.g., up to the
> length/OUI), and only after an appropriate OUI match, *then* validating the rest of
> the vendor element (the pieces we'll use later).
So I just decided to send some patches myself, for both of my notes:
[PATCH 5.2 1/2] mwifiex: Don't abort on small, spec-compliant vendor IEs
https://patchwork.kernel.org/patch/10996895/
[PATCH 2/2] mwifiex: use 'total_ie_len' in mwifiex_update_bss_desc_with_ie()
https://patchwork.kernel.org/patch/10996893/
I'd appreciate your review.
Regards,
Brian
^ permalink raw reply
* [PATCH 5.2 1/2] mwifiex: Don't abort on small, spec-compliant vendor IEs
From: Brian Norris @ 2019-06-15 0:13 UTC (permalink / raw)
To: Ganapathi Bhat, Nishant Sarmukadam, Amitkumar Karwar, Xinming Hu
Cc: linux-kernel, linux-wireless, Takashi Iwai, Guenter Roeck,
Brian Norris
Per the 802.11 specification, vendor IEs are (at minimum) only required
to contain an OUI. A type field is also included in ieee80211.h (struct
ieee80211_vendor_ie) but doesn't appear in the specification. The
remaining fields (subtype, version) are a convention used in WMM
headers.
Thus, we should not reject vendor-specific IEs that have only the
minimum length (3 bytes) -- we should skip over them (since we only want
to match longer IEs, that match either WMM or WPA formats). We can
reject elements that don't have the minimum-required 3 byte OUI.
While we're at it, move the non-standard subtype and version fields into
the WMM structs, to avoid this confusion in the future about generic
"vendor header" attributes.
Fixes: 685c9b7750bf ("mwifiex: Abort at too short BSS descriptor element")
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
It appears that commit 685c9b7750bf is on its way to 5.2, so I labeled
this bugfix for 5.2 as well.
drivers/net/wireless/marvell/mwifiex/fw.h | 12 +++++++++---
drivers/net/wireless/marvell/mwifiex/scan.c | 18 +++++++++++-------
.../net/wireless/marvell/mwifiex/sta_ioctl.c | 4 ++--
drivers/net/wireless/marvell/mwifiex/wmm.c | 2 +-
4 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index b73f99dc5a72..1fb76d2f5d3f 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -1759,9 +1759,10 @@ struct mwifiex_ie_types_wmm_queue_status {
struct ieee_types_vendor_header {
u8 element_id;
u8 len;
- u8 oui[4]; /* 0~2: oui, 3: oui_type */
- u8 oui_subtype;
- u8 version;
+ struct {
+ u8 oui[3];
+ u8 oui_type;
+ } __packed oui;
} __packed;
struct ieee_types_wmm_parameter {
@@ -1775,6 +1776,9 @@ struct ieee_types_wmm_parameter {
* Version [1]
*/
struct ieee_types_vendor_header vend_hdr;
+ u8 oui_subtype;
+ u8 version;
+
u8 qos_info_bitmap;
u8 reserved;
struct ieee_types_wmm_ac_parameters ac_params[IEEE80211_NUM_ACS];
@@ -1792,6 +1796,8 @@ struct ieee_types_wmm_info {
* Version [1]
*/
struct ieee_types_vendor_header vend_hdr;
+ u8 oui_subtype;
+ u8 version;
u8 qos_info_bitmap;
} __packed;
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index c269a0de9413..e2786ab612ca 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1361,21 +1361,25 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter,
break;
case WLAN_EID_VENDOR_SPECIFIC:
- if (element_len + 2 < sizeof(vendor_ie->vend_hdr))
- return -EINVAL;
-
vendor_ie = (struct ieee_types_vendor_specific *)
current_ptr;
- if (!memcmp
- (vendor_ie->vend_hdr.oui, wpa_oui,
- sizeof(wpa_oui))) {
+ /* 802.11 requires at least 3-byte OUI. */
+ if (element_len < sizeof(vendor_ie->vend_hdr.oui.oui))
+ return -EINVAL;
+
+ /* Not long enough for a match? Skip it. */
+ if (element_len < sizeof(wpa_oui))
+ break;
+
+ if (!memcmp(&vendor_ie->vend_hdr.oui, wpa_oui,
+ sizeof(wpa_oui))) {
bss_entry->bcn_wpa_ie =
(struct ieee_types_vendor_specific *)
current_ptr;
bss_entry->wpa_offset = (u16)
(current_ptr - bss_entry->beacon_buf);
- } else if (!memcmp(vendor_ie->vend_hdr.oui, wmm_oui,
+ } else if (!memcmp(&vendor_ie->vend_hdr.oui, wmm_oui,
sizeof(wmm_oui))) {
if (total_ie_len ==
sizeof(struct ieee_types_wmm_parameter) ||
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index ebc0e41e5d3b..74e50566db1f 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -1351,7 +1351,7 @@ mwifiex_set_gen_ie_helper(struct mwifiex_private *priv, u8 *ie_data_ptr,
/* Test to see if it is a WPA IE, if not, then
* it is a gen IE
*/
- if (!memcmp(pvendor_ie->oui, wpa_oui,
+ if (!memcmp(&pvendor_ie->oui, wpa_oui,
sizeof(wpa_oui))) {
/* IE is a WPA/WPA2 IE so call set_wpa function
*/
@@ -1361,7 +1361,7 @@ mwifiex_set_gen_ie_helper(struct mwifiex_private *priv, u8 *ie_data_ptr,
goto next_ie;
}
- if (!memcmp(pvendor_ie->oui, wps_oui,
+ if (!memcmp(&pvendor_ie->oui, wps_oui,
sizeof(wps_oui))) {
/* Test to see if it is a WPS IE,
* if so, enable wps session flag
diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index 407b9932ca4d..64916ba15df5 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -240,7 +240,7 @@ mwifiex_wmm_setup_queue_priorities(struct mwifiex_private *priv,
mwifiex_dbg(priv->adapter, INFO,
"info: WMM Parameter IE: version=%d,\t"
"qos_info Parameter Set Count=%d, Reserved=%#x\n",
- wmm_ie->vend_hdr.version, wmm_ie->qos_info_bitmap &
+ wmm_ie->version, wmm_ie->qos_info_bitmap &
IEEE80211_WMM_IE_AP_QOSINFO_PARAM_SET_CNT_MASK,
wmm_ie->reserved);
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH 2/2] mwifiex: use 'total_ie_len' in mwifiex_update_bss_desc_with_ie()
From: Brian Norris @ 2019-06-15 0:13 UTC (permalink / raw)
To: Ganapathi Bhat, Nishant Sarmukadam, Amitkumar Karwar, Xinming Hu
Cc: linux-kernel, linux-wireless, Takashi Iwai, Guenter Roeck,
Brian Norris
In-Reply-To: <20190615001321.241808-1-briannorris@chromium.org>
This is clearer than copy/pasting the magic number '+ 2' around, and it
even saves the need for one existing comment.
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/scan.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index e2786ab612ca..707e5159262f 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1269,7 +1269,7 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter,
break;
case WLAN_EID_FH_PARAMS:
- if (element_len + 2 < sizeof(*fh_param_set))
+ if (total_ie_len < sizeof(*fh_param_set))
return -EINVAL;
fh_param_set =
(struct ieee_types_fh_param_set *) current_ptr;
@@ -1279,7 +1279,7 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter,
break;
case WLAN_EID_DS_PARAMS:
- if (element_len + 2 < sizeof(*ds_param_set))
+ if (total_ie_len < sizeof(*ds_param_set))
return -EINVAL;
ds_param_set =
(struct ieee_types_ds_param_set *) current_ptr;
@@ -1292,7 +1292,7 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter,
break;
case WLAN_EID_CF_PARAMS:
- if (element_len + 2 < sizeof(*cf_param_set))
+ if (total_ie_len < sizeof(*cf_param_set))
return -EINVAL;
cf_param_set =
(struct ieee_types_cf_param_set *) current_ptr;
@@ -1302,7 +1302,7 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter,
break;
case WLAN_EID_IBSS_PARAMS:
- if (element_len + 2 < sizeof(*ibss_param_set))
+ if (total_ie_len < sizeof(*ibss_param_set))
return -EINVAL;
ibss_param_set =
(struct ieee_types_ibss_param_set *)
@@ -1459,10 +1459,8 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter,
break;
}
- current_ptr += element_len + 2;
-
- /* Need to account for IE ID and IE Len */
- bytes_left -= (element_len + 2);
+ current_ptr += total_ie_len;
+ bytes_left -= total_ie_len;
} /* while (bytes_left > 2) */
return ret;
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* Re: [PATCH v5] docs: power: convert docs to ReST and rename to *.rst
From: Bjorn Helgaas @ 2019-06-14 21:14 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel, Sebastian Reichel,
Rafael J. Wysocki, Viresh Kumar, Len Brown, Pavel Machek,
Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown,
Mathieu Poirier, Suzuki K Poulose, Harry Wei, Alex Shi,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
x86, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie,
Daniel Vetter, Johannes Berg, David S. Miller, linux-pm,
linux-arm-kernel, intel-gfx, dri-devel, linux-pci, linux-wireless,
netdev, Srivatsa S . Bhat
In-Reply-To: <20190614143631.7c99719f@lwn.net>
On Fri, Jun 14, 2019 at 02:36:31PM -0600, Jonathan Corbet wrote:
> On Thu, 13 Jun 2019 07:10:36 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > Convert the PM documents to ReST, in order to allow them to
> > build with Sphinx.
> >
> > The conversion is actually:
> > - add blank lines and identation in order to identify paragraphs;
> > - fix tables markups;
> > - add some lists markups;
> > - mark literal blocks;
> > - adjust title markups.
> >
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> > Acked-by: Mark Brown <broonie@kernel.org>
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> > Acked-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
>
> So I can't apply this one due to conflicts in include/linux/pci.h. Bjorn,
> perhaps the easiest thing is for you to take this one through your tree?
OK, I applied this to pci/docs for v5.3. I applied this entire patch,
but if you would prefer that I only apply the PCI-related parts, let
me know and I'll split those out.
Bjorn
^ permalink raw reply
* Re: [PATCH] wl18xx: Fix Wunused-const-variable
From: Nick Desaulniers @ 2019-06-14 20:57 UTC (permalink / raw)
To: Nathan Huckleberry, eliad, arik
Cc: Kalle Valo, David S. Miller, linux-wireless, netdev, LKML,
clang-built-linux
In-Reply-To: <CAKwvOd=jFYn=7NGPD8UDx3_g30qD+40bCjzmWJJSzmb6pNUusQ@mail.gmail.com>
On Fri, Jun 14, 2019 at 1:54 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
> Looking at drivers/net/wireless/ti/wl18xx/main.c, there 4 globally
> declared `struct ieee80211_iface_limit` but as your patch notes, only
> 2 are used. The thing is, their uses are in a `struct
> ieee80211_iface_limit []`.
Sorry, that's not quite right; it's not a `struct
ieee80211_iface_limit []` but a `struct ieee80211_iface_combination
[]`. No idea what other values we'd put to add these limits to the
array.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH] wl18xx: Fix Wunused-const-variable
From: Nick Desaulniers @ 2019-06-14 20:54 UTC (permalink / raw)
To: Nathan Huckleberry, eliad, arik
Cc: Kalle Valo, David S. Miller, linux-wireless, netdev, LKML,
clang-built-linux
In-Reply-To: <20190614171713.89262-1-nhuck@google.com>
On Fri, Jun 14, 2019 at 10:17 AM 'Nathan Huckleberry' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
>
> Clang produces the following warning
>
> drivers/net/wireless/ti/wl18xx/main.c:1850:43: warning: unused variable
> 'wl18xx_iface_ap_cl_limits' [-Wunused-const-variable] static const struct
> ieee80211_iface_limit wl18xx_iface_ap_cl_limits[] = { ^
> drivers/net/wireless/ti/wl18xx/main.c:1869:43: warning: unused variable
> 'wl18xx_iface_ap_go_limits' [-Wunused-const-variable] static const struct
> ieee80211_iface_limit wl18xx_iface_ap_go_limits[] = { ^
>
> The commit that added these variables never used them. Removing them.
Previous thread, for context:
https://groups.google.com/forum/#!topic/clang-built-linux/1Lu1GT9ic94
Looking at drivers/net/wireless/ti/wl18xx/main.c, there 4 globally
declared `struct ieee80211_iface_limit` but as your patch notes, only
2 are used. The thing is, their uses are in a `struct
ieee80211_iface_limit []`.
Looking at
$ git blame drivers/net/wireless/ti/wl18xx/main.c -L 1850
points to
commit 7845af35e0de ("wlcore: add p2p device support")
Adding Eliad and Arik to the thread; it's not clear to me what the
these variables were supposed to do, but seeing as the code in
question was already dead, this is no functional change from a user's
perspective. With that in mind:
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
So I'd at least add the tag.
Fixes: 7845af35e0de ("wlcore: add p2p device support")
> --- a/drivers/net/wireless/ti/wl18xx/main.c
> +++ b/drivers/net/wireless/ti/wl18xx/main.c
> @@ -1847,44 +1847,6 @@ static const struct ieee80211_iface_limit wl18xx_iface_ap_limits[] = {
> },
> };
>
> -static const struct ieee80211_iface_limit wl18xx_iface_ap_cl_limits[] = {
> - {
> - .max = 1,
> - .types = BIT(NL80211_IFTYPE_STATION),
> - },
> - {
> - .max = 1,
> - .types = BIT(NL80211_IFTYPE_AP),
> - },
> - {
> - .max = 1,
> - .types = BIT(NL80211_IFTYPE_P2P_CLIENT),
> - },
> - {
> - .max = 1,
> - .types = BIT(NL80211_IFTYPE_P2P_DEVICE),
> - },
> -};
> -
> -static const struct ieee80211_iface_limit wl18xx_iface_ap_go_limits[] = {
> - {
> - .max = 1,
> - .types = BIT(NL80211_IFTYPE_STATION),
> - },
> - {
> - .max = 1,
> - .types = BIT(NL80211_IFTYPE_AP),
> - },
> - {
> - .max = 1,
> - .types = BIT(NL80211_IFTYPE_P2P_GO),
> - },
> - {
> - .max = 1,
> - .types = BIT(NL80211_IFTYPE_P2P_DEVICE),
> - },
> -};
> -
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
From: Johannes Berg @ 2019-06-14 20:37 UTC (permalink / raw)
To: Tom Psyborg; +Cc: Manikanta Pubbisetty, linux-wireless
In-Reply-To: <CAKR_QVLyxBdqJAN6CsVG3ts41NOED56MvWdgvgVKPm-GRJXo-g@mail.gmail.com>
On Fri, 2019-06-14 at 22:27 +0200, Tom Psyborg wrote:
>
> If you don't want to read posts but only topic title, in short, no
> data pass thorugh with v2/v3 of this patch. Only v1 works.
I can read what you're saying, but I cannot understand it.
This patch doesn't modify any TX/RX path in any way. It only affects
whether you can or can not create certain interfaces.
johannes
^ permalink raw reply
* Re: [PATCH v5] docs: power: convert docs to ReST and rename to *.rst
From: Jonathan Corbet @ 2019-06-14 20:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Sebastian Reichel, Rafael J. Wysocki, Viresh Kumar, Len Brown,
Pavel Machek, Nishanth Menon, Stephen Boyd, Liam Girdwood,
Mark Brown, Mathieu Poirier, Suzuki K Poulose, Harry Wei,
Alex Shi, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, x86, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
David Airlie, Daniel Vetter, Bjorn Helgaas, Johannes Berg,
David S. Miller, linux-pm, linux-arm-kernel, intel-gfx, dri-devel,
linux-pci, linux-wireless, netdev, Srivatsa S . Bhat
In-Reply-To: <72d1f8f360d395958dd0b49165fc51b58801f57e.1560420621.git.mchehab+samsung@kernel.org>
On Thu, 13 Jun 2019 07:10:36 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Acked-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu>
So I can't apply this one due to conflicts in include/linux/pci.h. Bjorn,
perhaps the easiest thing is for you to take this one through your tree?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
From: Tom Psyborg @ 2019-06-14 20:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: Manikanta Pubbisetty, linux-wireless
In-Reply-To: <309ba2702f6b553a3dd08262efe34c4cecc4e445.camel@sipsolutions.net>
On 14/06/2019, Johannes Berg <johannes@sipsolutions.net> wrote:
> I'm also not convinced how this patch would affect *staying*
> connected... it should affect connecting to start with?
>
> johannes
>
>
If you don't want to read posts but only topic title, in short, no
data pass thorugh with v2/v3 of this patch. Only v1 works.
^ permalink raw reply
* Re: [PATCH-v3 1/2] wireless: Support assoc-at-ms timer in sta-info
From: Johannes Berg @ 2019-06-14 18:46 UTC (permalink / raw)
To: Ben Greear, linux-wireless
In-Reply-To: <7d606df7-bb8e-c454-1eaf-24fd454eab8e@candelatech.com>
On Fri, 2019-06-14 at 08:14 -0700, Ben Greear wrote:
>
>
> So, maybe I return instead the elapsed time in the netlink API instead of a
> timestamp. I think that will give me the value that I am looking for,
> and I can still print out the 'real' time in iw so any tools reading that
> output and do some simple math and figure out the 'real' associated-at time.
I don't think that's good. There's a delay between filling the message
and then processing it in userspace. We had this in the scan code and
learned that was full of races.
The better thing is to use CLOCK_BOOTTIME nanoseconds, and then
userspace can use clock_gettime() to get the current time etc. and then
do whatever calculations it needs. If it wants to print the realtime
timestamp, it could even calculate that (with some jitter) by doing
clock_gettime() on both realtime and boottime clocks...
johannes
^ permalink raw reply
* Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
From: Johannes Berg @ 2019-06-14 18:43 UTC (permalink / raw)
To: Tom Psyborg; +Cc: Manikanta Pubbisetty, linux-wireless
In-Reply-To: <CAKR_QV+5oY-5z4UB+HKV_57r5NneDme+TBg_c26h4C7Sy8R+UQ@mail.gmail.com>
On Fri, 2019-06-14 at 19:45 +0200, Tom Psyborg wrote:
>
> Never got reply. So I checked and definitely wrong version is applied
> (v2 or v3).
Why would that be wrong? I shouldn't apply v1 when v2 and v3 fix
comments I had ...
> Try to reproduce this yourself, I've posted details here:
> https://forum.openwrt.org/t/wds-client-wont-stay-connected-prev-auth-not-valid-using-recent-snapshot-builds/38194/20?u=psyborg
I might even have the requisite hardware, but not the required time now,
sorry.
I'm also not convinced how this patch would affect *staying*
connected... it should affect connecting to start with?
johannes
^ permalink raw reply
* Re: pull-request: mac80211-next 2019-06-14
From: David Miller @ 2019-06-14 18:27 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190614141638.30018-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 14 Jun 2019 16:16:37 +0200
> And ... here's a -next pull request. Nothing really major here,
> see more details below.
>
> Please pull and let me know if there's any problem.
Pulled and build testing, thank you.
^ permalink raw reply
* Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
From: Tom Psyborg @ 2019-06-14 17:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: Manikanta Pubbisetty, linux-wireless
In-Reply-To: <dc9039be42df8d241b14d4f673f3c472dc113991.camel@sipsolutions.net>
On 12/06/2019, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Thu, 2019-06-06 at 20:41 +0200, Tom Psyborg wrote:
>>
>> Applying this patch instead of v1 broke WDS operation between two
>> Litebeam AC Gen2 devices:
>
> I'm confused, and not even sure which version I applied now.
>
> Manikanta, can you please check this and which version I have and which
> changes I might need?
>
> Thanks,
> Johannes
>
>
>
Never got reply. So I checked and definitely wrong version is applied
(v2 or v3). Try to reproduce this yourself, I've posted details here:
https://forum.openwrt.org/t/wds-client-wont-stay-connected-prev-auth-not-valid-using-recent-snapshot-builds/38194/20?u=psyborg
^ permalink raw reply
* Re: [PATCH v4 4/5] mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()
From: Arend Van Spriel @ 2019-06-14 17:17 UTC (permalink / raw)
To: Doug Anderson, Ulf Hansson, Adrian Hunter
Cc: Kalle Valo, brcm80211-dev-list.pdl, open list:ARM/Rockchip SoC...,
Double Lo, Brian Norris, linux-wireless, Naveen Gupta,
Madhan Mohan R, Matthias Kaehlcke, Wright Feng, Chi-Hsien Lin,
netdev, brcm80211-dev-list, linux-mmc, Linux Kernel Mailing List,
Thomas Gleixner, Greg Kroah-Hartman, Avri Altman
In-Reply-To: <CAD=FV=Wuj=gANR2im_o4ZnoLEB+U6FqzKe4noLdQyi1vw+K2xw@mail.gmail.com>
On June 14, 2019 6:38:51 PM Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Fri, Jun 14, 2019 at 5:10 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>> On Fri, 14 Jun 2019 at 01:42, Douglas Anderson <dianders@chromium.org> wrote:
>> >
>> > We want SDIO drivers to be able to temporarily stop retuning when the
>> > driver knows that the SDIO card is not in a state where retuning will
>> > work (maybe because the card is asleep). We'll move the relevant
>> > functions to a place where drivers can call them.
>> >
>> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
>>
>> This looks good to me.
>>
>> BTW, seems like this series is best funneled via my mmc tree, no? In
>> such case, I need acks for the brcmfmac driver patches.
>
> For patch #1 I think it could just go in directly to the wireless
> tree. It should be fine to land the rest of the patches separately.
Agree.
> For patch #2 - #5 then what you say makes sense to me. I suppose
> you'd want at least a Reviewed-by from Arend and an Ack from Kalle on
> the Broadcom patches?
Will do.
> I'd also suggest that we Cc stable explicitly when applying. That's
> easy for #2 and #3 since they have a Fixes tag. For #4 and #5 I guess
> the question is how far back to go. Maybe Adrian has an opinion here
> since I think he's the one who experienced these problems.
I see if I can come up wit a fixes tag for #5.
Regards,
Arend
^ permalink raw reply
* [PATCH] wl18xx: Fix Wunused-const-variable
From: Nathan Huckleberry @ 2019-06-14 17:17 UTC (permalink / raw)
To: kvalo, davem
Cc: linux-wireless, netdev, linux-kernel, Nathan Huckleberry,
clang-built-linux
Clang produces the following warning
drivers/net/wireless/ti/wl18xx/main.c:1850:43: warning: unused variable
'wl18xx_iface_ap_cl_limits' [-Wunused-const-variable] static const struct
ieee80211_iface_limit wl18xx_iface_ap_cl_limits[] = { ^
drivers/net/wireless/ti/wl18xx/main.c:1869:43: warning: unused variable
'wl18xx_iface_ap_go_limits' [-Wunused-const-variable] static const struct
ieee80211_iface_limit wl18xx_iface_ap_go_limits[] = { ^
The commit that added these variables never used them. Removing them.
Cc: clang-built-linux@googlegroups.com
Link: https://github.com/ClangBuiltLinux/linux/issues/530
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
---
drivers/net/wireless/ti/wl18xx/main.c | 38 ---------------------------
1 file changed, 38 deletions(-)
diff --git a/drivers/net/wireless/ti/wl18xx/main.c b/drivers/net/wireless/ti/wl18xx/main.c
index a5e0604d3009..0b3cf8477c6c 100644
--- a/drivers/net/wireless/ti/wl18xx/main.c
+++ b/drivers/net/wireless/ti/wl18xx/main.c
@@ -1847,44 +1847,6 @@ static const struct ieee80211_iface_limit wl18xx_iface_ap_limits[] = {
},
};
-static const struct ieee80211_iface_limit wl18xx_iface_ap_cl_limits[] = {
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_STATION),
- },
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_AP),
- },
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_P2P_CLIENT),
- },
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_P2P_DEVICE),
- },
-};
-
-static const struct ieee80211_iface_limit wl18xx_iface_ap_go_limits[] = {
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_STATION),
- },
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_AP),
- },
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_P2P_GO),
- },
- {
- .max = 1,
- .types = BIT(NL80211_IFTYPE_P2P_DEVICE),
- },
-};
-
static const struct ieee80211_iface_combination
wl18xx_iface_combinations[] = {
{
--
2.22.0.rc2.383.gf4fbbf30c2-goog
^ permalink raw reply related
* Re: [PATCH v4 2/5] mmc: core: API to temporarily disable retuning for SDIO CRC errors
From: Doug Anderson @ 2019-06-14 16:41 UTC (permalink / raw)
To: Ulf Hansson
Cc: Kalle Valo, Adrian Hunter, Arend van Spriel,
brcm80211-dev-list.pdl, open list:ARM/Rockchip SoC..., Double Lo,
Brian Norris, linux-wireless, Naveen Gupta, Madhan Mohan R,
Matthias Kaehlcke, Wright Feng, Chi-Hsien Lin, netdev,
brcm80211-dev-list, Jiong Wu, Ritesh Harjani, Allison Randal,
linux-mmc@vger.kernel.org, Linux Kernel Mailing List,
Thomas Gleixner, Greg Kroah-Hartman, Shawn Lin, Wolfram Sang,
Avri Altman
In-Reply-To: <CAPDyKFrgXGf_9=H7G40fiUQj=da5WWRys_oim2azgL4FEOeUVA@mail.gmail.com>
Hi,
On Fri, Jun 14, 2019 at 5:04 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Fri, 14 Jun 2019 at 01:42, Douglas Anderson <dianders@chromium.org> wrote:
> >
> > Normally when the MMC core sees an "-EILSEQ" error returned by a host
> > controller then it will trigger a retuning of the card. This is
> > generally a good idea.
> >
> > However, if a command is expected to sometimes cause transfer errors
> > then these transfer errors shouldn't cause a re-tuning. This
> > re-tuning will be a needless waste of time. One example case where a
> > transfer is expected to cause errors is when transitioning between
> > idle (sometimes referred to as "sleep" in Broadcom code) and active
> > state on certain Broadcom WiFi SDIO cards. Specifically if the card
> > was already transitioning between states when the command was sent it
> > could cause an error on the SDIO bus.
> >
> > Let's add an API that the SDIO function drivers can call that will
> > temporarily disable the auto-tuning functionality. Then we can add a
> > call to this in the Broadcom WiFi driver and any other driver that
> > might have similar needs.
> >
> > NOTE: this makes the assumption that the card is already tuned well
> > enough that it's OK to disable the auto-retuning during one of these
> > error-prone situations. Presumably the driver code performing the
> > error-prone transfer knows how to recover / retry from errors. ...and
> > after we can get back to a state where transfers are no longer
> > error-prone then we can enable the auto-retuning again. If we truly
> > find ourselves in a case where the card needs to be retuned sometimes
> > to handle one of these error-prone transfers then we can always try a
> > few transfers first without auto-retuning and then re-try with
> > auto-retuning if the first few fail.
> >
> > Without this change on rk3288-veyron-minnie I periodically see this in
> > the logs of a machine just sitting there idle:
> > dwmmc_rockchip ff0d0000.dwmmc: Successfully tuned phase to XYZ
> >
> > Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> > Changes in v4:
> > - Moved to SDIO API only (Adrian, Ulf).
> > - Renamed to make it less generic, now retune_crc_disable (Ulf).
> > - Function header makes it clear host must be claimed (Ulf).
> > - No more WARN_ON (Ulf).
> >
> > Changes in v3:
> > - Took out the spinlock since I believe this is all in one context.
> >
> > Changes in v2:
> > - Updated commit message to clarify based on discussion of v1.
> >
> > drivers/mmc/core/core.c | 5 +++--
> > drivers/mmc/core/sdio_io.c | 36 +++++++++++++++++++++++++++++++++++
> > include/linux/mmc/core.h | 2 ++
> > include/linux/mmc/host.h | 1 +
> > include/linux/mmc/sdio_func.h | 3 +++
> > 5 files changed, 45 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> > index 6db36dc870b5..9020cb2490f7 100644
> > --- a/drivers/mmc/core/core.c
> > +++ b/drivers/mmc/core/core.c
> > @@ -144,8 +144,9 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
> > int err = cmd->error;
> >
> > /* Flag re-tuning needed on CRC errors */
> > - if ((cmd->opcode != MMC_SEND_TUNING_BLOCK &&
> > - cmd->opcode != MMC_SEND_TUNING_BLOCK_HS200) &&
> > + if (cmd->opcode != MMC_SEND_TUNING_BLOCK &&
> > + cmd->opcode != MMC_SEND_TUNING_BLOCK_HS200 &&
> > + !host->retune_crc_disable &&
> > (err == -EILSEQ || (mrq->sbc && mrq->sbc->error == -EILSEQ) ||
> > (mrq->data && mrq->data->error == -EILSEQ) ||
> > (mrq->stop && mrq->stop->error == -EILSEQ)))
> > diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
> > index f79f0b0caab8..f822a9630b0e 100644
> > --- a/drivers/mmc/core/sdio_io.c
> > +++ b/drivers/mmc/core/sdio_io.c
> > @@ -734,3 +734,39 @@ int sdio_set_host_pm_flags(struct sdio_func *func, mmc_pm_flag_t flags)
> > return 0;
> > }
> > EXPORT_SYMBOL_GPL(sdio_set_host_pm_flags);
> > +
> > +/**
> > + * sdio_retune_crc_disable - temporarily disable retuning on CRC errors
> > + * @func: SDIO function attached to host
> > + *
> > + * If the SDIO card is known to be in a state where it might produce
> > + * CRC errors on the bus in response to commands (like if we know it is
> > + * transitioning between power states), an SDIO function driver can
> > + * call this function to temporarily disable the SD/MMC core behavior of
> > + * triggering an automatic retuning.
> > + *
> > + * This function should be called while the host is claimed and the host
> > + * should remain claimed until sdio_retune_crc_enable() is called.
> > + * Specifically, the expected sequence of calls is:
> > + * - sdio_claim_host()
> > + * - sdio_retune_crc_disable()
> > + * - some number of calls like sdio_writeb() and sdio_readb()
>
> sdio_retune_crc_enable()
>
> > + * - sdio_release_host()
> > + */
> > +void sdio_retune_crc_disable(struct sdio_func *func)
> > +{
> > + func->card->host->retune_crc_disable = true;
> > +}
> > +EXPORT_SYMBOL_GPL(sdio_retune_crc_disable);
> > +
> > +/**
> > + * sdio_retune_crc_enable - reneable retuning on CRC errors
>
> /s/reneable/re-enable
>
> > + * @func: SDIO function attached to host
> > + *
> > + * This is the compement to sdio_retune_crc_disable().
> > + */
> > +void sdio_retune_crc_enable(struct sdio_func *func)
> > +{
> > + func->card->host->retune_crc_disable = false;
> > +}
> > +EXPORT_SYMBOL_GPL(sdio_retune_crc_enable);
> > diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
> > index 134a6483347a..02a13abf0cda 100644
> > --- a/include/linux/mmc/core.h
> > +++ b/include/linux/mmc/core.h
> > @@ -178,6 +178,8 @@ int mmc_wait_for_cmd(struct mmc_host *host, struct mmc_command *cmd,
> >
> > int mmc_hw_reset(struct mmc_host *host);
> > int mmc_sw_reset(struct mmc_host *host);
> > +void mmc_expect_errors_begin(struct mmc_host *host);
> > +void mmc_expect_errors_end(struct mmc_host *host);
>
> Leftovers for earlier versions.
Oops!
> > void mmc_set_data_timeout(struct mmc_data *data, const struct mmc_card *card);
> >
> > #endif /* LINUX_MMC_CORE_H */
> > diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> > index 43d0f0c496f6..ecb7972e2423 100644
> > --- a/include/linux/mmc/host.h
> > +++ b/include/linux/mmc/host.h
> > @@ -398,6 +398,7 @@ struct mmc_host {
> > unsigned int retune_now:1; /* do re-tuning at next req */
> > unsigned int retune_paused:1; /* re-tuning is temporarily disabled */
> > unsigned int use_blk_mq:1; /* use blk-mq */
> > + unsigned int retune_crc_disable:1; /* don't trigger retune upon crc */
> >
> > int rescan_disable; /* disable card detection */
> > int rescan_entered; /* used with nonremovable devices */
> > diff --git a/include/linux/mmc/sdio_func.h b/include/linux/mmc/sdio_func.h
> > index e9dfdd501cd1..4820e6d09dac 100644
> > --- a/include/linux/mmc/sdio_func.h
> > +++ b/include/linux/mmc/sdio_func.h
> > @@ -167,4 +167,7 @@ extern void sdio_f0_writeb(struct sdio_func *func, unsigned char b,
> > extern mmc_pm_flag_t sdio_get_host_pm_caps(struct sdio_func *func);
> > extern int sdio_set_host_pm_flags(struct sdio_func *func, mmc_pm_flag_t flags);
> >
> > +extern void sdio_retune_crc_disable(struct sdio_func *func);
> > +extern void sdio_retune_crc_enable(struct sdio_func *func);
> > +
> > #endif /* LINUX_MMC_SDIO_FUNC_H */
> > --
> > 2.22.0.rc2.383.gf4fbbf30c2-goog
> >
>
> Besides the minor comments, this looks good to me.
Thank you for the reviews!
I'll plan to send a v5 on my Monday with the fixes assuming no new
heated discussion starts up. If it's less work for you, I'm also
happy if you just want to make the trivial fixes yourself when
applying.
-Doug
^ permalink raw reply
* Re: [PATCH v4 4/5] mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()
From: Doug Anderson @ 2019-06-14 16:38 UTC (permalink / raw)
To: Ulf Hansson, Arend van Spriel, Adrian Hunter
Cc: Kalle Valo, brcm80211-dev-list.pdl, open list:ARM/Rockchip SoC...,
Double Lo, Brian Norris, linux-wireless, Naveen Gupta,
Madhan Mohan R, Matthias Kaehlcke, Wright Feng, Chi-Hsien Lin,
netdev, brcm80211-dev-list, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Thomas Gleixner, Greg Kroah-Hartman,
Avri Altman
In-Reply-To: <CAPDyKFrJ4+zn7Ak0tYHkBfXUtH3N7erb5R7Q+hgugchZmCRGrw@mail.gmail.com>
Hi,
On Fri, Jun 14, 2019 at 5:10 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Fri, 14 Jun 2019 at 01:42, Douglas Anderson <dianders@chromium.org> wrote:
> >
> > We want SDIO drivers to be able to temporarily stop retuning when the
> > driver knows that the SDIO card is not in a state where retuning will
> > work (maybe because the card is asleep). We'll move the relevant
> > functions to a place where drivers can call them.
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
>
> This looks good to me.
>
> BTW, seems like this series is best funneled via my mmc tree, no? In
> such case, I need acks for the brcmfmac driver patches.
For patch #1 I think it could just go in directly to the wireless
tree. It should be fine to land the rest of the patches separately.
For patch #2 - #5 then what you say makes sense to me. I suppose
you'd want at least a Reviewed-by from Arend and an Ack from Kalle on
the Broadcom patches?
I'd also suggest that we Cc stable explicitly when applying. That's
easy for #2 and #3 since they have a Fixes tag. For #4 and #5 I guess
the question is how far back to go. Maybe Adrian has an opinion here
since I think he's the one who experienced these problems.
Thanks!
-Doug
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 03/16] drm/i915: stop using drm_pci_alloc
From: Ville Syrjälä @ 2019-06-14 16:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: 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, Chris Wilson
In-Reply-To: <20190614134726.3827-4-hch@lst.de>
On Fri, Jun 14, 2019 at 03:47:13PM +0200, Christoph Hellwig wrote:
> Remove usage of the legacy drm PCI DMA wrappers, and with that the
> incorrect usage cocktail of __GFP_COMP, virt_to_page on DMA allocation
> and SetPageReserved.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 30 +++++++++++++-------------
> drivers/gpu/drm/i915/i915_gem_object.h | 3 ++-
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 3 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index ad01c92aaf74..8f2053c91aff 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -228,7 +228,6 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
> static int i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
> {
> struct address_space *mapping = obj->base.filp->f_mapping;
> - drm_dma_handle_t *phys;
> struct sg_table *st;
> struct scatterlist *sg;
> char *vaddr;
> @@ -242,13 +241,13 @@ static int i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
> * to handle all possible callers, and given typical object sizes,
> * the alignment of the buddy allocation will naturally match.
> */
> - phys = drm_pci_alloc(obj->base.dev,
> - roundup_pow_of_two(obj->base.size),
> - roundup_pow_of_two(obj->base.size));
> - if (!phys)
> + obj->phys_vaddr = dma_alloc_coherent(&obj->base.dev->pdev->dev,
> + roundup_pow_of_two(obj->base.size),
> + &obj->phys_handle, GFP_KERNEL);
> + if (!obj->phys_vaddr)
> return -ENOMEM;
>
> - vaddr = phys->vaddr;
> + vaddr = obj->phys_vaddr;
> for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
> struct page *page;
> char *src;
> @@ -286,18 +285,17 @@ static int i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
> sg->offset = 0;
> sg->length = obj->base.size;
>
> - sg_dma_address(sg) = phys->busaddr;
> + sg_dma_address(sg) = obj->phys_handle;
> sg_dma_len(sg) = obj->base.size;
>
> - obj->phys_handle = phys;
> -
> __i915_gem_object_set_pages(obj, st, sg->length);
>
> return 0;
>
> err_phys:
> - drm_pci_free(obj->base.dev, phys);
> -
> + dma_free_coherent(&obj->base.dev->pdev->dev,
> + roundup_pow_of_two(obj->base.size), obj->phys_vaddr,
> + obj->phys_handle);
Need to undo the damage to obj->phys_vaddr here since
i915_gem_pwrite_ioctl() will now use that to determine if it's
dealing with a phys obj.
> return err;
> }
>
> @@ -335,7 +333,7 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj,
>
> if (obj->mm.dirty) {
> struct address_space *mapping = obj->base.filp->f_mapping;
> - char *vaddr = obj->phys_handle->vaddr;
> + char *vaddr = obj->phys_vaddr;
> int i;
>
> for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
> @@ -363,7 +361,9 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj,
> sg_free_table(pages);
> kfree(pages);
>
> - drm_pci_free(obj->base.dev, obj->phys_handle);
> + dma_free_coherent(&obj->base.dev->pdev->dev,
> + roundup_pow_of_two(obj->base.size), obj->phys_vaddr,
> + obj->phys_handle);
This one is fine I think since the object remains a phys obj once
turned into one. At least the current code isn't clearing
phys_handle here. But my memory is a bit hazy on the details. Chris?
Also maybe s/phys_handle/phys_busaddr/ all over?
> }
>
> static void
> @@ -603,7 +603,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
> struct drm_i915_gem_pwrite *args,
> struct drm_file *file)
> {
> - void *vaddr = obj->phys_handle->vaddr + args->offset;
> + void *vaddr = obj->phys_vaddr + args->offset;
> char __user *user_data = u64_to_user_ptr(args->data_ptr);
>
> /* We manually control the domain here and pretend that it
> @@ -1431,7 +1431,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
> ret = i915_gem_gtt_pwrite_fast(obj, args);
>
> if (ret == -EFAULT || ret == -ENOSPC) {
> - if (obj->phys_handle)
> + if (obj->phys_vaddr)
> ret = i915_gem_phys_pwrite(obj, args, file);
> else
> ret = i915_gem_shmem_pwrite(obj, args);
> diff --git a/drivers/gpu/drm/i915/i915_gem_object.h b/drivers/gpu/drm/i915/i915_gem_object.h
> index ca93a40c0c87..14bd2d61d0f6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> @@ -290,7 +290,8 @@ struct drm_i915_gem_object {
> };
>
> /** for phys allocated objects */
> - struct drm_dma_handle *phys_handle;
> + dma_addr_t phys_handle;
> + void *phys_vaddr;
>
> struct reservation_object __builtin_resv;
> };
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 5098228f1302..4f8b368ac4e2 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10066,7 +10066,7 @@ static u32 intel_cursor_base(const struct intel_plane_state *plane_state)
> u32 base;
>
> if (INTEL_INFO(dev_priv)->display.cursor_needs_physical)
> - base = obj->phys_handle->busaddr;
> + base = obj->phys_handle;
> else
> base = intel_plane_ggtt_offset(plane_state);
>
> --
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: pull-request: mac80211 2019-06-14
From: David Miller @ 2019-06-14 16:37 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190614135042.28352-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 14 Jun 2019 15:50:41 +0200
> Here's a round of fixes for the current tree, things are all over
> and the only really important thing is the TDLS and MFP fix, both
> of which allow a security bypass in MFP.
>
> Please pull and let me know if there's any problem.
Pulled, thanks a lot.
^ permalink raw reply
* Re: [PATCH] nfc: Ensure presence of required attributes in the deactivate_target handler
From: David Miller @ 2019-06-14 15:48 UTC (permalink / raw)
To: 92siuyang; +Cc: sameo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1560496382-32532-1-git-send-email-92siuyang@gmail.com>
From: Young Xiao <92siuyang@gmail.com>
Date: Fri, 14 Jun 2019 15:13:02 +0800
> Check that the NFC_ATTR_TARGET_INDEX attributes (in addition to
> NFC_ATTR_DEVICE_INDEX) are provided by the netlink client prior to
> accessing them. This prevents potential unhandled NULL pointer dereference
> exceptions which can be triggered by malicious user-mode programs,
> if they omit one or both of these attributes.
>
> Signed-off-by: Young Xiao <92siuyang@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox