提交 · 66d06c84730c8b148d93909ffbddf074fd771a48 · openeuler / Kernel

06 11月, 2020 40 次提交

mac80211: adhere to Tx control flag that prevents frame reordering · 66d06c84

由 Mathy Vanhoef 提交于 11月 04, 2020

When the Tx control flag is set to prevent frame reordering, send
all frames that have this flag set on the same queue. This assures
that frames that have this flag set are not reordered relative to
other frames that have this flag set.
Signed-off-by: NMathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
Link: https://lore.kernel.org/r/20201104061823.197407-3-Mathy.Vanhoef@kuleuven.beSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

66d06c84

mac80211: add radiotap flag to assure frames are not reordered · 30df8130

由 Mathy Vanhoef 提交于 11月 04, 2020

Add a new radiotap flag to indicate injected frames must not be
reordered relative to other frames that also have this flag set,
independent of priority field values in the transmitted frame.
Parse this radiotap flag and define and set a corresponding Tx
control flag. Note that this flag has recently been standardized
as part of an update to radiotap.
Signed-off-by: NMathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
Link: https://lore.kernel.org/r/20201104061823.197407-2-Mathy.Vanhoef@kuleuven.beSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

30df8130

mac80211: save HE oper info in BSS config for mesh · 70debba3

由 Pradeep Kumar Chitrapu 提交于 10月 20, 2020

Currently he_support is set only for AP mode. Storing this
information for mesh BSS as well helps driver to determine
HE support. Also save HE operation element params in BSS
conf so that drivers can access this for any configurations
instead of having to parse the beacon to fetch that info.
Signed-off-by: NPradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Link: https://lore.kernel.org/r/20201020183111.25458-2-pradeepc@codeaurora.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

70debba3

cfg80211: add support to configure HE MCS for beacon rate · c4a30446

由 Rajkumar Manoharan 提交于 10月 16, 2020

This allows an option to configure a single HE MCS beacon tx rate.
Signed-off-by: NRajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/1602879327-29488-2-git-send-email-rmanohar@codeaurora.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

c4a30446

nl80211: fix beacon tx rate mask validation · 857b34c4

由 Rajkumar Manoharan 提交于 10月 16, 2020

While adding HE MCS beacon tx rate support, it is observed that legacy
beacon tx rate in VHT hwsim test suite is failed. Whenever the
application doesn't explicitly set VHT/MCS rate attribute in fixed rate
command, by default all HE MCS masks are enabled in cfg80211. In beacon
fixed rate, more than one rate mask is not allowed. Fix that by not
setting all rate mask by default in case of beacon tx rate.
Signed-off-by: NRajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/1602879327-29488-1-git-send-email-rmanohar@codeaurora.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

857b34c4

nl80211/cfg80211: fix potential infinite loop · ba5c2523

由 Colin Ian King 提交于 10月 29, 2020

The for-loop iterates with a u8 loop counter and compares this
with the loop upper limit of request->n_ssids which is an int type.
There is a potential infinite loop if n_ssids is larger than the
u8 loop counter, so fix this by making the loop counter an int.

Addresses-Coverity: ("Infinite loop")
Fixes: c8cb5b85 ("nl80211/cfg80211: support 6 GHz scanning")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20201029222407.390218-1-colin.king@canonical.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

ba5c2523

cfg80211: Add support to calculate and report 4096-QAM HE rates · 9c97c88d

由 Vamsi Krishna 提交于 10月 29, 2020

Drivers supporting 4096-QAM rates as a vendor extension in HE mode need
to update the correct rate info to userspace while using 4096-QAM (MCS12
and MCS13) in HE mode. Add support to calculate bitrates of HE-MCS12 and
HE-MCS13 which represent the 4096-QAM modulation schemes. The MCS12 and
MCS13 bitrates are defined in IEEE P802.11be/D0.1.

In addition, scale up the bitrates by 3*2048 in order to accommodate
calculations for the new MCS12 and MCS13 rates without losing fraction
values.
Signed-off-by: NVamsi Krishna <vamsin@codeaurora.org>
Signed-off-by: NJouni Malinen <jouni@codeaurora.org>
Link: https://lore.kernel.org/r/20201029183457.7005-1-jouni@codeaurora.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

9c97c88d

cfg80211: Add support to configure SAE PWE value to drivers · 9f0ffa41

由 Rohan Dutta 提交于 10月 27, 2020

Add support to configure SAE PWE preference from userspace to drivers in
both AP and STA modes. This is needed for cases where the driver takes
care of Authentication frame processing (SME in the driver) so that
correct enforcement of the acceptable PWE derivation mechanism can be
performed.

The userspace applications can pass the sae_pwe value using the
NL80211_ATTR_SAE_PWE attribute in the NL80211_CMD_CONNECT and
NL80211_CMD_START_AP commands to the driver. This allows selection
between the hunting-and-pecking loop and hash-to-element options for PWE
derivation. For backwards compatibility, this new attribute is optional
and if not included, the driver is notified of the value being
unspecified.
Signed-off-by: NRohan Dutta <drohan@codeaurora.org>
Signed-off-by: NJouni Malinen <jouni@codeaurora.org>
Link: https://lore.kernel.org/r/20201027100910.22283-1-jouni@codeaurora.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

9f0ffa41

ieee80211: Add definition for WFA DPP · 8280c07e

由 Kurt Lee 提交于 10月 12, 2020

Add Wi-Fi Alliance definition for DPP (Device Provisioning Protocol).
Signed-off-by: NKurt Lee <kurt.lee@cypress.com>
Signed-off-by: NWright Feng <wright.feng@cypress.com>
Link: https://lore.kernel.org/r/20201012084347.121557-2-wright.feng@cypress.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

8280c07e

mac80211: use semicolons rather than commas to separate statements · c7287cb8

由 Julia Lawall 提交于 10月 11, 2020

Replace commas with semicolons.  Commas introduce unnecessary
variability in the code structure and are hard to see.  What is done
is essentially described by the following Coccinelle semantic patch
(http://coccinelle.lip6.fr/):

// <smpl>
@@ expression e1,e2; @@
e1
-,
+;
e2
... when any
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@inria.fr>
Link: https://lore.kernel.org/r/1602412498-32025-3-git-send-email-Julia.Lawall@inria.frSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

c7287cb8

Merge tag 'mlx5-updates-2020-11-03' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · c9448e82

由 Jakub Kicinski 提交于 11月 05, 2020

Saeed Mahameed says:

====================
mlx5-updates-2020-11-03

This series includes updates to mlx5 software steering component.

1) Few improvements in the DR area, such as removing unneeded checks,
  renaming to better general names, refactor in some places, etc.

2) Software steering (DR) Memory management improvements

This patch series contains SW Steering memory management improvements:
using buddy allocator instead of an existing bucket allocator, and
several other optimizations.

The buddy system is a memory allocation and management algorithm
that manages memory in power of two increments.

The algorithm is well-known and well-described, such as here:
https://en.wikipedia.org/wiki/Buddy_memory_allocation

Linux uses this algorithm for managing and allocating physical pages,
as described here:
https://www.kernel.org/doc/gorman/html/understand/understand009.html

In our case, although the algorithm in principal is similar to the
Linux physical page allocator, the "building blocks" and the circumstances
are different: in SW steering, buddy allocator doesn't really allocates
a memory, but rather manages ICM (Interconnect Context Memory) that was
previously allocated and registered.

The ICM memory that is used in SW steering is always power
of 2 (order), so buddy system is a good fit for this.

Patches in this series:

[PATH 4] net/mlx5: DR, Add buddy allocator utilities
  This patch adds a modified implementation of a well-known buddy allocator,
  adjusted for SW steering needs: the algorithm in principal is similar to
  the Linux physical page allocator, but in our case buddy allocator doesn't
  really allocate a memory, but rather manages ICM memory that was previously
  allocated and registered.

[PATH 5] net/mlx5: DR, Handle ICM memory via buddy allocation instead of bucket management
  This patch changes ICM management of SW steering to use buddy-system mechanism
  Instead of the previous bucket management.

[PATH 6] net/mlx5: DR, Sync chunks only during free
  This patch makes syncing happen only when freeing memory chunks.

[PATH 7] net/mlx5: DR, ICM memory pools sync optimization
  This patch adds tracking of pool's "hot" memory and makes the
  check whether steering sync is required much shorter and faster.

[PATH 8] net/mlx5: DR, Free buddy ICM memory if it is unused
  This patch adds tracking buddy's used ICM memory,
  and frees the buddy if all its memory becomes unused.

3) Misc code cleanups

* tag 'mlx5-updates-2020-11-03' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux:
  net: mlx5: Replace in_irq() usage
  net/mlx5: Cleanup kernel-doc warnings
  net/mlx4: Cleanup kernel-doc warnings
  net/mlx5e: Validate stop_room size upon user input
  net/mlx5: DR, Free unused buddy ICM memory
  net/mlx5: DR, ICM memory pools sync optimization
  net/mlx5: DR, Sync chunks only during free
  net/mlx5: DR, Handle ICM memory via buddy allocation instead of buckets
  net/mlx5: DR, Add buddy allocator utilities
  net/mlx5: DR, Rename matcher functions to be more HW agnostic
  net/mlx5: DR, Rename builders HW specific names
  net/mlx5: DR, Remove unused member of action struct
====================

Link: https://lore.kernel.org/r/20201105201242.21716-1-saeedm@nvidia.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

c9448e82

net/usb/r8153_ecm: support ECM mode for RTL8153 · c1aedf01

由 Hayes Wang 提交于 11月 04, 2020

Support ECM mode based on cdc_ether with relative mii functions,
when CONFIG_USB_RTL8152 is not set, or the device is not supported
by r8152 driver.

Both r8152 and r8153_ecm would check the return value of
rtl8152_get_version() in porbe(). If rtl8152_get_version()
return none zero value, the r8152 is used for the device
with vendor mode. Otherwise, the r8153_ecm is used for the
device with ECM mode.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Link: https://lore.kernel.org/r/1394712342-15778-392-Taiwan-albertk@realtek.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

c1aedf01

net: Add mhi-net driver · 3ffec6a1

由 Loic Poulain 提交于 11月 03, 2020

This patch adds a new network driver implementing MHI transport for
network packets. Packets can be in any format, though QMAP (rmnet)
is the usual protocol (flow control + PDN mux).

It support two MHI devices, IP_HW0 which is, the path to the IPA
(IP accelerator) on qcom modem, And IP_SW0 which is the software
driven IP path (to modem CPU).
Signed-off-by: NLoic Poulain <loic.poulain@linaro.org>
Reviewed-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/1604424234-24446-2-git-send-email-loic.poulain@linaro.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

3ffec6a1

bus: mhi: Add mhi_queue_is_full function · d8c4a223

由 Loic Poulain 提交于 11月 03, 2020

This function can be used by client driver to determine whether it's
possible to queue new elements in a channel ring.
Signed-off-by: NLoic Poulain <loic.poulain@linaro.org>
Reviewed-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/1604424234-24446-1-git-send-email-loic.poulain@linaro.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

d8c4a223

Merge branch 'net-phy-add-support-for-shared-interrupts-part-1' · 5aee9484

由 Jakub Kicinski 提交于 11月 05, 2020

Ioana Ciornei says:

====================
net: phy: add support for shared interrupts (part 1)

This patch set aims to actually add support for shared interrupts in
phylib and not only for multi-PHY devices. While we are at it,
streamline the interrupt handling in phylib.

For a bit of context, at the moment, there are multiple phy_driver ops
that deal with this subject:

- .config_intr() - Enable/disable the interrupt line.

- .ack_interrupt() - Should quiesce any interrupts that may have been
  fired.  It's also used by phylib in conjunction with .config_intr() to
  clear any pending interrupts after the line was disabled, and before
  it is going to be enabled.

- .did_interrupt() - Intended for multi-PHY devices with a shared IRQ
  line and used by phylib to discern which PHY from the package was the
  one that actually fired the interrupt.

- .handle_interrupt() - Completely overrides the default interrupt
  handling logic from phylib. The PHY driver is responsible for checking
  if any interrupt was fired by the respective PHY and choose
  accordingly if it's the one that should trigger the link state machine.

From my point of view, the interrupt handling in phylib has become
somewhat confusing with all these callbacks that actually read the same
PHY register - the interrupt status.  A more streamlined approach would
be to just move the responsibility to write an interrupt handler to the
driver (as any other device driver does) and make .handle_interrupt()
the only way to deal with interrupts.

Another advantage with this approach would be that phylib would gain
support for shared IRQs between different PHY (not just multi-PHY
devices), something which at the moment would require extending every
PHY driver anyway in order to implement their .did_interrupt() callback
and duplicate the same logic as in .ack_interrupt(). The disadvantage
of making .did_interrupt() mandatory would be that we are slightly
changing the semantics of the phylib API and that would increase
confusion instead of reducing it.

What I am proposing is the following:

- As a first step, make the .ack_interrupt() callback optional so that
  we do not break any PHY driver amid the transition.

- Every PHY driver gains a .handle_interrupt() implementation that, for
  the most part, would look like below:

	irq_status = phy_read(phydev, INTR_STATUS);
	if (irq_status < 0) {
		phy_error(phydev);
		return IRQ_NONE;
	}

	if (!(irq_status & irq_mask))
		return IRQ_NONE;

	phy_trigger_machine(phydev);

	return IRQ_HANDLED;

- Remove each PHY driver's implementation of the .ack_interrupt() by
  actually taking care of quiescing any pending interrupts before
  enabling/after disabling the interrupt line.

- Finally, after all drivers have been ported, remove the
  .ack_interrupt() and .did_interrupt() callbacks from phy_driver.

This patch set is part 1 and it addresses the changes needed in phylib
and 7 PHY drivers. The rest can be found on my Github branch here:
https://github.com/IoanaCiornei/linux/commits/phylib-shared-irq

I do not have access to most of these PHY's, therefore I Cc-ed the
latest contributors to the individual PHY drivers in order to have
access, hopefully, to more regression testing.

Changes in v2:
 - Rework the .handle_interrupt() implementation for each driver so that
   only the enabled interrupts are taken into account when
   IRQ_NONE/IRQ_HANDLED it returned. The main idea is so that we avoid
   falsely blaming a device for triggering an interrupt when this is not
   the case.
   The only devices for which I was unable to make this adjustment were
   the BCM8706, BCM8727, BCMAC131 and BCM5241 since I do not have access
   to their datasheets.
 - I also updated the pseudo-code added in the cover-letter so that it's
   more clear how a .handle_interrupt() callback should look like.
====================
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20201101125114.1316879-1-ciorneiioana@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

5aee9484

net: phy: realtek: remove the use of .ack_interrupt() · 8b43357f