<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/wireless/ath, branch linux-5.0.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>wil6210: fix return code of wmi_mgmt_tx and wmi_mgmt_tx_ext</title>
<updated>2019-05-31T13:45:12+00:00</updated>
<author>
<name>Lior David</name>
<email>liord@codeaurora.org</email>
</author>
<published>2019-02-28T09:35:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8dbae96a237f143909e2e6997f3a9b7d812a3c31'/>
<id>8dbae96a237f143909e2e6997f3a9b7d812a3c31</id>
<content type='text'>
[ Upstream commit 49122ec42634f73babb1dc96f170023e5228d080 ]

The functions that send management TX frame have 3 possible
results: success and other side acknowledged receive (ACK=1),
success and other side did not acknowledge receive(ACK=0) and
failure to send the frame. The current implementation
incorrectly reports the ACK=0 case as failure.

Signed-off-by: Lior David &lt;liord@codeaurora.org&gt;
Signed-off-by: Maya Erez &lt;merez@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 49122ec42634f73babb1dc96f170023e5228d080 ]

The functions that send management TX frame have 3 possible
results: success and other side acknowledged receive (ACK=1),
success and other side did not acknowledge receive(ACK=0) and
failure to send the frame. The current implementation
incorrectly reports the ACK=0 case as failure.

Signed-off-by: Lior David &lt;liord@codeaurora.org&gt;
Signed-off-by: Maya Erez &lt;merez@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath10k: Drop WARN_ON()s that always trigger during system resume</title>
<updated>2019-05-05T12:43:41+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2019-03-03T17:24:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d467f3acebc5c0d816b7e7008ea8ee07d1633e72'/>
<id>d467f3acebc5c0d816b7e7008ea8ee07d1633e72</id>
<content type='text'>
commit 9e80ad37f6788ed52b89a3cfcd593e0aa69b216d upstream.

ath10k_mac_vif_chan() always returns an error for the given vif
during system-wide resume which reliably triggers two WARN_ON()s
in ath10k_bss_info_changed() and they are not particularly
useful in that code path, so drop them.

Tested: QCA6174 hw3.2 PCI with WLAN.RM.2.0-00180-QCARMSWPZ-1
Tested: QCA6174 hw3.2 SDIO with WLAN.RMH.4.4.1-00007-QCARMSWP-1

Fixes: cd93b83ad927 ("ath10k: support for multicast rate control")
Fixes: f279294e9ee2 ("ath10k: add support for configuring management packet rate")
Cc: stable@vger.kernel.org
Reviewed-by: Brian Norris &lt;briannorris@chromium.org&gt;
Tested-by: Brian Norris &lt;briannorris@chromium.org&gt;
Tested-by: Claire Chang &lt;tientzu@chromium.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9e80ad37f6788ed52b89a3cfcd593e0aa69b216d upstream.

ath10k_mac_vif_chan() always returns an error for the given vif
during system-wide resume which reliably triggers two WARN_ON()s
in ath10k_bss_info_changed() and they are not particularly
useful in that code path, so drop them.

Tested: QCA6174 hw3.2 PCI with WLAN.RM.2.0-00180-QCARMSWPZ-1
Tested: QCA6174 hw3.2 SDIO with WLAN.RMH.4.4.1-00007-QCARMSWP-1

Fixes: cd93b83ad927 ("ath10k: support for multicast rate control")
Fixes: f279294e9ee2 ("ath10k: add support for configuring management packet rate")
Cc: stable@vger.kernel.org
Reviewed-by: Brian Norris &lt;briannorris@chromium.org&gt;
Tested-by: Brian Norris &lt;briannorris@chromium.org&gt;
Tested-by: Claire Chang &lt;tientzu@chromium.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ath10k: fix shadow register implementation for WCN3990</title>
<updated>2019-04-05T20:34:39+00:00</updated>
<author>
<name>Rakesh Pillai</name>
<email>pillair@codeaurora.org</email>
</author>
<published>2019-02-08T13:50:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=db5177729062ed8d38a6646ffdf94313e605b204'/>
<id>db5177729062ed8d38a6646ffdf94313e605b204</id>
<content type='text'>
[ Upstream commit 1863008369ae0407508033b4b00f98b985adeb15 ]

WCN3990 supports shadow registers write operation support
for copy engine for regular operation in powersave mode.

Since WCN3990 is a 64-bit target, the shadow register
implementation needs to be done in the copy engine handlers
for 64-bit target. Currently the shadow register implementation
is present in the 32-bit target handlers of copy engine.

Fix the shadow register copy engine write operation
implementation for 64-bit target(WCN3990).

Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1

Fixes: b7ba83f7c414 ("ath10k: add support for shadow register for WNC3990")
Signed-off-by: Rakesh Pillai &lt;pillair@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 1863008369ae0407508033b4b00f98b985adeb15 ]

WCN3990 supports shadow registers write operation support
for copy engine for regular operation in powersave mode.

Since WCN3990 is a 64-bit target, the shadow register
implementation needs to be done in the copy engine handlers
for 64-bit target. Currently the shadow register implementation
is present in the 32-bit target handlers of copy engine.

Fix the shadow register copy engine write operation
implementation for 64-bit target(WCN3990).

Tested HW: WCN3990
Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1

Fixes: b7ba83f7c414 ("ath10k: add support for shadow register for WNC3990")
Signed-off-by: Rakesh Pillai &lt;pillair@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath10k: don't report unset rssi values to mac80211</title>
<updated>2019-04-05T20:34:28+00:00</updated>
<author>
<name>Alagu Sankar</name>
<email>alagusankar@silex-india.com</email>
</author>
<published>2019-02-25T09:46:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5e91baea2c1fc8568fa149445e7714dcefb6cde5'/>
<id>5e91baea2c1fc8568fa149445e7714dcefb6cde5</id>
<content type='text'>
[ Upstream commit 7d444522303177f3a3c09b9abb104ddeea470a70 ]

The SDIO firmware does not provide RSSI value to the host, it's only set to
zero. In that case don't report the value to mac80211. One risk here is that
value zero might be a valid value with other firmware, currently there's no way
to detect that.

Without the fix, the rssi value indicated by iw changes between the actual
value and -95.

Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00005-QCARMSWP-1.

Co-developed-by: Wen Gong &lt;wgong@codeaurora.org&gt;
Signed-off-by: Alagu Sankar &lt;alagusankar@silex-india.com&gt;
Signed-off-by: Wen Gong &lt;wgong@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7d444522303177f3a3c09b9abb104ddeea470a70 ]

The SDIO firmware does not provide RSSI value to the host, it's only set to
zero. In that case don't report the value to mac80211. One risk here is that
value zero might be a valid value with other firmware, currently there's no way
to detect that.

Without the fix, the rssi value indicated by iw changes between the actual
value and -95.

Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00005-QCARMSWP-1.

Co-developed-by: Wen Gong &lt;wgong@codeaurora.org&gt;
Signed-off-by: Alagu Sankar &lt;alagusankar@silex-india.com&gt;
Signed-off-by: Wen Gong &lt;wgong@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath10k: Fix the wrong updation of BW in tx_stats debugfs entry</title>
<updated>2019-04-05T20:34:27+00:00</updated>
<author>
<name>Surabhi Vishnoi</name>
<email>svishnoi@codeaurora.org</email>
</author>
<published>2019-02-26T09:27:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a73713e533230b82122579e7d004ad26984dd48e'/>
<id>a73713e533230b82122579e7d004ad26984dd48e</id>
<content type='text'>
[ Upstream commit ef9051c72ab7bc664e8047c55ac74bdb1c7fa3ee ]

Currently, the bandwidth is updated wrongly in BW table in tx_stats
debugfs per sta as there is difference in number of bandwidth type
in mac80211 and driver stats table. This leads to bandwidth getting
updated at wrong index in bandwidth table in tx_stats.

Fix this index mismatch between mac80211 and driver stats table (BW table)
by making the number of bandwidth type in driver compatible with mac80211.

Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1

Fixes: a904417fc876 ("ath10k: add extended per sta tx statistics support")
Signed-off-by: Surabhi Vishnoi &lt;svishnoi@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ef9051c72ab7bc664e8047c55ac74bdb1c7fa3ee ]

Currently, the bandwidth is updated wrongly in BW table in tx_stats
debugfs per sta as there is difference in number of bandwidth type
in mac80211 and driver stats table. This leads to bandwidth getting
updated at wrong index in bandwidth table in tx_stats.

Fix this index mismatch between mac80211 and driver stats table (BW table)
by making the number of bandwidth type in driver compatible with mac80211.

Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1

Fixes: a904417fc876 ("ath10k: add extended per sta tx statistics support")
Signed-off-by: Surabhi Vishnoi &lt;svishnoi@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wil6210: check null pointer in _wil_cfg80211_merge_extra_ies</title>
<updated>2019-04-05T20:34:26+00:00</updated>
<author>
<name>Alexei Avshalom Lazar</name>
<email>ailizaro@codeaurora.org</email>
</author>
<published>2019-02-22T14:21:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=96e2fec0fd8cf9e8b6d9fff087d2e40d4d9ab71b'/>
<id>96e2fec0fd8cf9e8b6d9fff087d2e40d4d9ab71b</id>
<content type='text'>
[ Upstream commit de77a53c2d1e8fb3621e63e8e1f0f0c9a1a99ff7 ]

ies1 or ies2 might be null when code inside
_wil_cfg80211_merge_extra_ies access them.
Add explicit check for null and make sure ies1/ies2 are not
accessed in such a case.

spos might be null and be accessed inside
_wil_cfg80211_merge_extra_ies.
Add explicit check for null in the while condition statement
and make sure spos is not accessed in such a case.

Signed-off-by: Alexei Avshalom Lazar &lt;ailizaro@codeaurora.org&gt;
Signed-off-by: Maya Erez &lt;merez@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit de77a53c2d1e8fb3621e63e8e1f0f0c9a1a99ff7 ]

ies1 or ies2 might be null when code inside
_wil_cfg80211_merge_extra_ies access them.
Add explicit check for null and make sure ies1/ies2 are not
accessed in such a case.

spos might be null and be accessed inside
_wil_cfg80211_merge_extra_ies.
Add explicit check for null in the while condition statement
and make sure spos is not accessed in such a case.

Signed-off-by: Alexei Avshalom Lazar &lt;ailizaro@codeaurora.org&gt;
Signed-off-by: Maya Erez &lt;merez@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom</title>
<updated>2019-03-13T21:01:31+00:00</updated>
<author>
<name>Daniel F. Dickinson</name>
<email>cshored@thecshore.com</email>
</author>
<published>2018-12-22T06:09:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3dfe7538f80acf0edf33ae4ae4f639c86e3a3be5'/>
<id>3dfe7538f80acf0edf33ae4ae4f639c86e3a3be5</id>
<content type='text'>
commit ce938231bd3b1d7af3cbd8836f084801090470e1 upstream.

ath9k_of_init() function[0] was initially written on the assumption that
if someone had an explicit ath9k OF node that "there must be something
wrong, why would someone add an OF node if everything is fine"[1]
(Quoting Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;)

"it turns out it's not that simple. with your requirements I'm now aware
of two use-cases where the current code in ath9k_of_init() doesn't work
without modifications"[1]

The "your requirements" Martin speaks of is the result of the fact that I
have a device (PowerCloud Systems CR5000) has some kind of default - not
unique mac address - set and requires to set the correct MAC address via
mac-address devicetree property, however:

"some cards come with a physical EEPROM chip [or OTP] so "qca,no-eeprom"
should not be set (your use-case). in this case AH_USE_EEPROM should be
set (which is the default when there is no OF node)"[1]

The other use case is:

the firmware on some PowerMac G5 seems to add a OF node for the ath9k
card automatically. depending on the EEPROM on the card AH_NO_EEP_SWAP
should be unset (which is the default when there is no OF node). see [3]

After this patch to ath9k_of_init() the new behavior will be:

    if there's no OF node then everything is the same as before
    if there's an empty OF node then ath9k will use the hardware EEPROM
      (before ath9k would fail to initialize because no EEPROM data was
      provided by userspace)
    if there's an OF node with only a MAC address then ath9k will use
      the MAC address and the hardware EEPROM (see the case above)
    with "qca,no-eeprom" EEPROM data from userspace will be requested.
      the behavior here will not change
[1]

Martin provides additional background on EEPROM swapping[1].

Thanks to Christian Lamparter &lt;chunkeey@gmail.com&gt; for all his help on
troubleshooting this issue and the basis for this patch.

[0]https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/net/wireless/ath/ath9k/init.c#L615
[1]https://github.com/openwrt/openwrt/pull/1645#issuecomment-448027058
[2]https://github.com/openwrt/openwrt/pull/1613
[3]https://patchwork.kernel.org/patch/10241731/

Fixes: 138b41253d9c ("ath9k: parse the device configuration from an OF node")
Reviewed-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Tested-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Signed-off-by: Daniel F. Dickinson &lt;cshored@thecshore.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Cc: Christian Lamparter &lt;chunkeey@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ce938231bd3b1d7af3cbd8836f084801090470e1 upstream.

ath9k_of_init() function[0] was initially written on the assumption that
if someone had an explicit ath9k OF node that "there must be something
wrong, why would someone add an OF node if everything is fine"[1]
(Quoting Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;)

"it turns out it's not that simple. with your requirements I'm now aware
of two use-cases where the current code in ath9k_of_init() doesn't work
without modifications"[1]

The "your requirements" Martin speaks of is the result of the fact that I
have a device (PowerCloud Systems CR5000) has some kind of default - not
unique mac address - set and requires to set the correct MAC address via
mac-address devicetree property, however:

"some cards come with a physical EEPROM chip [or OTP] so "qca,no-eeprom"
should not be set (your use-case). in this case AH_USE_EEPROM should be
set (which is the default when there is no OF node)"[1]

The other use case is:

the firmware on some PowerMac G5 seems to add a OF node for the ath9k
card automatically. depending on the EEPROM on the card AH_NO_EEP_SWAP
should be unset (which is the default when there is no OF node). see [3]

After this patch to ath9k_of_init() the new behavior will be:

    if there's no OF node then everything is the same as before
    if there's an empty OF node then ath9k will use the hardware EEPROM
      (before ath9k would fail to initialize because no EEPROM data was
      provided by userspace)
    if there's an OF node with only a MAC address then ath9k will use
      the MAC address and the hardware EEPROM (see the case above)
    with "qca,no-eeprom" EEPROM data from userspace will be requested.
      the behavior here will not change
[1]

Martin provides additional background on EEPROM swapping[1].

Thanks to Christian Lamparter &lt;chunkeey@gmail.com&gt; for all his help on
troubleshooting this issue and the basis for this patch.

[0]https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/net/wireless/ath/ath9k/init.c#L615
[1]https://github.com/openwrt/openwrt/pull/1645#issuecomment-448027058
[2]https://github.com/openwrt/openwrt/pull/1613
[3]https://patchwork.kernel.org/patch/10241731/

Fixes: 138b41253d9c ("ath9k: parse the device configuration from an OF node")
Reviewed-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Tested-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Signed-off-by: Daniel F. Dickinson &lt;cshored@thecshore.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Cc: Christian Lamparter &lt;chunkeey@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'wireless-drivers-for-davem-2019-02-04' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers</title>
<updated>2019-02-04T17:12:06+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2019-02-04T17:12:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3e5a7c981464fd592f10a62c911001c174d46c12'/>
<id>3e5a7c981464fd592f10a62c911001c174d46c12</id>
<content type='text'>
Kalle Valo says:

====================
wireless-drivers fixes for 5.0

First set of small, but importnat, fixes for 5.0.

iwlwifi

* fix a build regression introduced in 5.0-rc1

wlcore

* fix a firmware regression from v4.18-rc1

mt76x0

* fix for configuring tx power from user space

ath10k

* fix wcn3990 regression from v4.20-rc1
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Kalle Valo says:

====================
wireless-drivers fixes for 5.0

First set of small, but importnat, fixes for 5.0.

iwlwifi

* fix a build regression introduced in 5.0-rc1

wlcore

* fix a firmware regression from v4.18-rc1

mt76x0

* fix for configuring tx power from user space

ath10k

* fix wcn3990 regression from v4.20-rc1
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath10k: correct bus type for WCN3990</title>
<updated>2019-01-31T16:56:50+00:00</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2019-01-29T23:12:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2c2008a63e482654ab137c84d3c61c03b75e7df6'/>
<id>2c2008a63e482654ab137c84d3c61c03b75e7df6</id>
<content type='text'>
WCN3990 is SNOC, not PCI. This prevents probing WCN3990.

Fixes: 367c899f622c ("ath10k: add bus type check in ath10k_init_hw_params")
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Reviewed-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
WCN3990 is SNOC, not PCI. This prevents probing WCN3990.

Fixes: 367c899f622c ("ath10k: add bus type check in ath10k_init_hw_params")
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Reviewed-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cross-tree: phase out dma_zalloc_coherent()</title>
<updated>2019-01-08T12:58:37+00:00</updated>
<author>
<name>Luis Chamberlain</name>
<email>mcgrof@kernel.org</email>
</author>
<published>2019-01-04T08:23:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=750afb08ca71310fcf0c4e2cb1565c63b8235b60'/>
<id>750afb08ca71310fcf0c4e2cb1565c63b8235b60</id>
<content type='text'>
We already need to zero out memory for dma_alloc_coherent(), as such
using dma_zalloc_coherent() is superflous. Phase it out.

This change was generated with the following Coccinelle SmPL patch:

@ replace_dma_zalloc_coherent @
expression dev, size, data, handle, flags;
@@

-dma_zalloc_coherent(dev, size, handle, flags)
+dma_alloc_coherent(dev, size, handle, flags)

Suggested-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
[hch: re-ran the script on the latest tree]
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We already need to zero out memory for dma_alloc_coherent(), as such
using dma_zalloc_coherent() is superflous. Phase it out.

This change was generated with the following Coccinelle SmPL patch:

@ replace_dma_zalloc_coherent @
expression dev, size, data, handle, flags;
@@

-dma_zalloc_coherent(dev, size, handle, flags)
+dma_alloc_coherent(dev, size, handle, flags)

Suggested-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
[hch: re-ran the script on the latest tree]
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
