<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/wireless/realtek/rtlwifi/base.c, branch linux-6.2.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.2.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.2.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2022-04-11T14:42:03Z</updated>
<entry>
<title>mac80211: prepare sta handling for MLO support</title>
<updated>2022-04-11T14:42:03Z</updated>
<author>
<name>Sriram R</name>
<email>quic_srirrama@quicinc.com</email>
</author>
<published>2022-04-04T15:41:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=046d2e7c50e3087a32a85fd384c21f896dbccf83'/>
<id>urn:sha1:046d2e7c50e3087a32a85fd384c21f896dbccf83</id>
<content type='text'>
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.

With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.

To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.

For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.

For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.

Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.

Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.

  @ieee80211_sta@
  struct ieee80211_sta *s;
  struct sta_info *si;
  identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
  @@

  (
    s-&gt;
  -    var
  +    deflink.var
  |
   si-&gt;sta.
  -    var
  +    deflink.var
  )

  @sta_info@
  struct sta_info *si;
  identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
  @@

  (
    si-&gt;
  -    var
  +    deflink.var
  )

Signed-off-by: Sriram R &lt;quic_srirrama@quicinc.com&gt;
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>rtlwifi: replace usage of found with dedicated list iterator variable</title>
<updated>2022-04-06T12:11:58Z</updated>
<author>
<name>Jakob Koschel</name>
<email>jakobkoschel@gmail.com</email>
</author>
<published>2022-03-24T07:21:24Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a0ff2a87194a968b9547fd4d824a09092171d1ea'/>
<id>urn:sha1:a0ff2a87194a968b9547fd4d824a09092171d1ea</id>
<content type='text'>
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.

To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boolean [1].

This removes the need to use a found variable and simply checking if
the variable was set, can determine if the break/goto was hit.

Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/
Signed-off-by: Jakob Koschel &lt;jakobkoschel@gmail.com&gt;
Acked-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20220324072124.62458-1-jakobkoschel@gmail.com
</content>
</entry>
<entry>
<title>net: rtlwifi: properly check for alloc_workqueue() failure</title>
<updated>2021-05-13T15:30:26Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2021-05-03T11:56:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=30b0e0ee9d02b97b68705c46b41444786effc40c'/>
<id>urn:sha1:30b0e0ee9d02b97b68705c46b41444786effc40c</id>
<content type='text'>
If alloc_workqueue() fails, properly catch this and propagate the error
to the calling functions, so that the devuce initialization will
properly error out.

Cc: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Cc: Bryan Brattlof &lt;hello@bryanbrattlof.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20210503115736.2104747-14-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "rtlwifi: fix a potential NULL pointer dereference"</title>
<updated>2021-05-13T15:30:24Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2021-05-03T11:56:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=68c5634c4a7278672a3bed00eb5646884257c413'/>
<id>urn:sha1:68c5634c4a7278672a3bed00eb5646884257c413</id>
<content type='text'>
This reverts commit 765976285a8c8db3f0eb7f033829a899d0c2786e.

Because of recent interactions with developers from @umn.edu, all
commits from them have been recently re-reviewed to ensure if they were
correct or not.

Upon review, this commit was found to be incorrect for the reasons
below, so it must be reverted.  It will be fixed up "correctly" in a
later kernel change.

This commit is not correct, it should not have used unlikely() and is
not propagating the error properly to the calling function, so it should
be reverted at this point in time.  Also, if the check failed, the
work queue was still assumed to be allocated, so further accesses would
have continued to fail, meaning this patch does nothing to solve the
root issues at all.

Cc: Kangjie Lu &lt;kjlu@umn.edu&gt;
Cc: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Cc: Bryan Brattlof &lt;hello@bryanbrattlof.com&gt;
Fixes: 765976285a8c ("rtlwifi: fix a potential NULL pointer dereference")
Cc: stable &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20210503115736.2104747-13-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rtlwifi: Simplify locking of a skb list accesses</title>
<updated>2021-04-17T17:32:04Z</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2021-04-05T07:57:14Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1186006adee97ebb5b16db0e4ae64e8efb2c8f76'/>
<id>urn:sha1:1186006adee97ebb5b16db0e4ae64e8efb2c8f76</id>
<content type='text'>
The 'c2hcmd_lock' spinlock is only used to protect some __skb_queue_tail()
and __skb_dequeue() calls.
Use the lock provided in the skb itself and call skb_queue_tail() and
skb_dequeue(). These functions already include the correct locking.

Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Acked-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/99cf8894fd52202cb7ce2ec6e3200eef400bc071.1617609346.git.christophe.jaillet@wanadoo.fr
</content>
</entry>
<entry>
<title>net: rtlwifi: Replace in_interrupt() for context detection</title>
<updated>2020-09-29T21:02:55Z</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2020-09-29T20:25:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=920872e08391a8efb83077a3b3d9b1097682ca80'/>
<id>urn:sha1:920872e08391a8efb83077a3b3d9b1097682ca80</id>
<content type='text'>
rtl_lps_enter() and rtl_lps_leave() are using in_interrupt() to detect
whether it is safe to acquire a mutex or if it is required to defer to a
workqueue.

The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be seperated or the context be conveyed in an argument passed by the
caller, which usually knows the context.

in_interrupt() also is only partially correct because it fails to chose the
correct code path when just preemption or interrupts are disabled.

Add an argument 'may_block' to both functions and adjust the callers to
pass the context information.

The following call chains were analyzed to be safe to block:

    rtl_watchdog_wq_callback()
      rlf_lps_leave/enter()

    rtl_op_suspend()
      rtl_lps_leave()

    rtl_op_bss_info_changed()
      rtl_lps_leave()

    rtl_op_sw_scan_start()
      rtl_lps_leave()

The following call chains were analyzed to be unsafe to block:

    _rtl_pci_interrupt()
      _rtl_pci_rx_interrupt()
	  rtl_lps_leave()

    _rtl_pci_interrupt()
      _rtl_pci_rx_interrupt()
        rtl_is_special_data()
	  rtl_lps_leave()

    _rtl_pci_interrupt()
      _rtl_pci_rx_interrupt()
        rtl_is_special_data()
	  setup_special_tx()
	    rtl_lps_leave()

    _rtl_pci_interrupt()
      _rtl_pci_tx_isr
        rtl_lps_leave()

      halbtc_leave_lps()
        rtl_lps_leave()

This leaves four callers of rtl_lps_enter/leave() where the analyzis
stopped dead in the maze of several nested pointer based callchains and
lack of rtlwifi hardware to debug this via tracing:

     halbtc_leave_lps(), halbtc_enter_lps(), halbtc_normal_lps(),
     halbtc_pre_normal_lps()

These four have been cautionally marked to be unable to block which is the
safe option, but the rtwifi wizards should be able to clarify that.

Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: rtlwifi: Remove void* casts related to delayed work</title>
<updated>2020-09-29T21:02:55Z</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2020-09-29T20:25:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a3b7b227f1250a90c8a9542ea6398a61e1708174'/>
<id>urn:sha1:a3b7b227f1250a90c8a9542ea6398a61e1708174</id>
<content type='text'>
INIT_DELAYED_WORK() takes two arguments: A pointer to the delayed work and
a function reference for the callback.

The rtl code casts all function references to (void *) because the
callbacks in use are not matching the required function signature. That's
error prone and bad pratice.

Some of the callback functions are also global, but only used in a single
file.

Clean the mess up by:

  - Adding the proper arguments to the callback functions and using them in
    the container_of() constructs correctly which removes the hideous
    container_of_dwork_rtl() macro as well.

  - Removing the type cast at the initializers

  - Making the unnecessary global functions static

Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>rtlwifi: Use fallthrough pseudo-keyword</title>
<updated>2020-09-01T09:35:38Z</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavoars@kernel.org</email>
</author>
<published>2020-08-21T06:18:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=765be4459d92382068fe3ac7620a72b649f8e21f'/>
<id>urn:sha1:765be4459d92382068fe3ac7620a72b649f8e21f</id>
<content type='text'>
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1].

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva &lt;gustavoars@kernel.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200821061807.GA8412@embeddedor
</content>
</entry>
<entry>
<title>rtlwifi: Replace RT_TRACE with rtl_dbg</title>
<updated>2020-08-31T15:25:43Z</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2020-07-23T20:42:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f108a420e50a62e0bc5cdcd7d4a2440986b526e3'/>
<id>urn:sha1:f108a420e50a62e0bc5cdcd7d4a2440986b526e3</id>
<content type='text'>
The macro name RT_TRACE makes it seem that it is used for tracing, when
is actually used for debugging. Change the name to rtl_dbg. Any Sparse
errors exposed by this change were also fixed.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200723204244.24457-3-Larry.Finger@lwfinger.net
</content>
</entry>
<entry>
<title>rtlwifi: use true,false for bool variable in rtl_init_rfkill()</title>
<updated>2020-05-06T08:32:30Z</updated>
<author>
<name>Jason Yan</name>
<email>yanaijie@huawei.com</email>
</author>
<published>2020-04-26T09:41:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fb1a9fc550cf748ba1225d734539ae97b5699b02'/>
<id>urn:sha1:fb1a9fc550cf748ba1225d734539ae97b5699b02</id>
<content type='text'>
The 'blocked' is a bool variable, and '==' expression itself is bool
too. So no need to convert it to 0/1.

This fixes the following coccicheck warning:

drivers/net/wireless/realtek/rtlwifi/base.c:508:13-41: WARNING:
Comparison of 0/1 to bool variable

Signed-off-by: Jason Yan &lt;yanaijie@huawei.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200426094115.23294-1-yanaijie@huawei.com
</content>
</entry>
</feed>
