| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Since commit ea426c2a7de8 ("mm: memcg: prepare for byte-sized vmstat
items") the write side of slab counters accepts a value in bytes and
converts it to pages. It happens in __mod_node_page_state().
However a non-SMP version of __mod_node_page_state() doesn't perform
this conversion. It leads to incorrect (unrealistically high) slab
counters values. Fix this by adding a similar conversion to the non-SMP
version of __mod_node_page_state().
Signed-off-by: Roman Gushchin <[email protected]>
Reported-and-tested-by: Bastian Bittorf <[email protected]>
Fixes: ea426c2a7de8 ("mm: memcg: prepare for byte-sized vmstat items")
Acked-by: Vlastimil Babka <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
maintainers
Darren Hart and Andy Shevchenko lately have not had enough time to
maintain the x86 platform drivers, dropping their status to:
"Odd Fixes".
Mark Gross and Hans de Goede will take over maintainership of
the x86 platform drivers. Replace Darren and Andy's entries with
theirs and change the status to "Maintained".
Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Mark Gross <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
|
|
2 recent commits:
cfae58ed681c ("platform/x86: intel-vbtn: Only blacklist SW_TABLET_MODE
on the 9 / "Laptop" chasis-type")
1fac39fd0316 ("platform/x86: intel-vbtn: Also handle tablet-mode switch on
"Detachable" and "Portable" chassis-types")
Enabled reporting of SW_TABLET_MODE on more devices since the vbtn ACPI
interface is used by the firmware on some of those devices to report this.
Testing has shown that unconditionally enabling SW_TABLET_MODE reporting
on all devices with a chassis type of 8 ("Portable") or 10 ("Notebook")
which support the VGBS method is a very bad idea.
Many of these devices are normal laptops (non 2-in-1) models with a VGBS
which always returns 0, which we translate to SW_TABLET_MODE=1. This in
turn causes userspace (libinput) to suppress events from the builtin
keyboard and touchpad, making the laptop essentially unusable.
Since the problem of wrongly reporting SW_TABLET_MODE=1 in combination
with libinput, leads to a non-usable system. Where as OTOH many people will
not even notice when SW_TABLET_MODE is not being reported, this commit
changes intel_vbtn_has_switches() to use a DMI based allow-list.
The new DMI based allow-list matches on the 31 ("Convertible") and
32 ("Detachable") chassis-types, as these clearly are 2-in-1s and
so far if they support the intel-vbtn ACPI interface they all have
properly working SW_TABLET_MODE reporting.
Besides these 2 generic matches, it also contains model specific matches
for 2-in-1 models which use a different chassis-type and which are known
to have properly working SW_TABLET_MODE reporting.
This has been tested on the following 2-in-1 devices:
Dell Venue 11 Pro 7130 vPro
HP Pavilion X2 10-p002nd
HP Stream x360 Convertible PC 11
Medion E1239T
Fixes: cfae58ed681c ("platform/x86: intel-vbtn: Only blacklist SW_TABLET_MODE on the 9 / "Laptop" chasis-type")
BugLink: https://forum.manjaro.org/t/keyboard-and-touchpad-only-work-on-kernel-5-6/22668
BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1175599
Cc: Barnabás Pőcze <[email protected]>
Cc: Takashi Iwai <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
|
|
the HP Pavilion 11 x360"
After discussion, see the Link tag, it appears that this is not good enough.
So, revert it now and apply a better fix.
This reverts commit d823346876a970522ff9e4d2b323c9b734dcc4de.
Link: https://lore.kernel.org/platform-driver-x86/[email protected]/
Signed-off-by: Andy Shevchenko <[email protected]>
|
|
In ieee80211_determine_chantype(), the sband->ht_cap was
being processed before S1G Operation element. Since the
HT capability element should not be present on the S1G
band, avoid processing potential garbage by moving the
call to ieee80211_apply_htcap_overrides() to after the S1G
block.
Also, in case of a missing S1G Operation element, we would
continue trying to process non-S1G elements (and return
with a channel width of 20MHz). Instead, just assume
primary channel is equal to operating and infer the
operating width from the BSS channel, then return.
Signed-off-by: Thomas Pedersen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
|
|
When dumping wiphy information, we try to split the data into
many submessages, but for old userspace we still support the
old mode where this doesn't happen.
However, in this case we were not resetting our state correctly
and dumping multiple messages for each wiphy, which would have
broken such older userspace.
This was broken pretty much immediately afterwards because it
only worked in the original commit where non-split dumps didn't
have any more data than split dumps...
Fixes: fe1abafd942f ("nl80211: re-add channel width and extended capa advertising")
Signed-off-by: Johannes Berg <[email protected]>
Link: https://lore.kernel.org/r/20200928130717.3e6d9c6bada2.Ie0f151a8d0d00a8e1e18f6a8c9244dd02496af67@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
When wiphy dumps cannot be split, such as in events or with
older userspace that doesn't support it, the size can today
be too big.
Reduce it, by doing two things:
1) remove data that couldn't have been present before the
split capability was introduced since it's new, such as
HE capabilities
2) as suggested by Martin Willi, remove management frame
subtypes from the split dumps, as just (1) isn't even
enough due to other new code capabilities. This is fine
as old consumers (really just wpa_supplicant) didn't
check this data before they got support for split dumps.
Reported-by: Martin Willi <[email protected]>
Suggested-by: Martin Willi <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Tested-by: Martin Willi <[email protected]>
Link: https://lore.kernel.org/r/20200928130655.53bce7873164.I71f06c9a221cd0630429a1a56eeae68a13beca61@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
The pipe splice code still used the old model of waiting for pipe IO by
using a non-specific "pipe_wait()" that waited for any pipe event to
happen, which depended on all pipe IO being entirely serialized by the
pipe lock. So by checking the state you were waiting for, and then
adding yourself to the wait queue before dropping the lock, you were
guaranteed to see all the wakeups.
Strictly speaking, the actual wakeups were not done under the lock, but
the pipe_wait() model still worked, because since the waiter held the
lock when checking whether it should sleep, it would always see the
current state, and the wakeup was always done after updating the state.
However, commit 0ddad21d3e99 ("pipe: use exclusive waits when reading or
writing") split the single wait-queue into two, and in the process also
made the "wait for event" code wait for _two_ wait queues, and that then
showed a race with the wakers that were not serialized by the pipe lock.
It's only splice that used that "pipe_wait()" model, so the problem
wasn't obvious, but Josef Bacik reports:
"I hit a hang with fstest btrfs/187, which does a btrfs send into
/dev/null. This works by creating a pipe, the write side is given to
the kernel to write into, and the read side is handed to a thread that
splices into a file, in this case /dev/null.
The box that was hung had the write side stuck here [pipe_write] and
the read side stuck here [splice_from_pipe_next -> pipe_wait].
[ more details about pipe_wait() scenario ]
The problem is we're doing the prepare_to_wait, which sets our state
each time, however we can be woken up either with reads or writes. In
the case above we race with the WRITER waking us up, and re-set our
state to INTERRUPTIBLE, and thus never break out of schedule"
Josef had a patch that avoided the issue in pipe_wait() by just making
it set the state only once, but the deeper problem is that pipe_wait()
depends on a level of synchonization by the pipe mutex that it really
shouldn't. And the whole "wait for any pipe state change" model really
isn't very good to begin with.
So rather than trying to work around things in pipe_wait(), remove that
legacy model of "wait for arbitrary pipe event" entirely, and actually
create functions that wait for the pipe actually being readable or
writable, and can do so without depending on the pipe lock serializing
everything.
Fixes: 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")
Link: https://lore.kernel.org/linux-fsdevel/bfa88b5ad6f069b2b679316b9e495a970130416c.1601567868.git.josef@toxicpanda.com/
Reported-by: Josef Bacik <[email protected]>
Reviewed-and-tested-by: Josef Bacik <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Use netif_msg_init() to process param settings
and use only the proper initialized value of
ei_local->msg_level for later processing;
Signed-off-by: Armin Wolf <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Realtek single-chip Ethernet PHY solutions can be separated as below:
10M/100Mbps: RTL8201X
1Gbps: RTL8211X
2.5Gbps: RTL8226/RTL8221X
RTL8226 is the first version for realtek that compatible 2.5Gbps single PHY.
Since RTL8226 is single port only, realtek changes its name to RTL8221B from
the second version.
PHY ID for RTL8226 is 0x001cc800 and RTL8226B/RTL8221B is 0x001cc840.
RTL8125 is not a single PHY solution, it integrates PHY/MAC/PCIE bus
controller and embedded memory.
Signed-off-by: Willy Liu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
After commit a8c7687bf216 ("caif_virtio: Check that vringh_config is not
null"), the variable err is being initialized with '-EINVAL' that is
meaningless. So remove it.
Signed-off-by: Jing Xiangfeng <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Fix follow warnings:
[net/core/net-sysfs.c:1161]: (warning) %u in format string (no. 1)
requires 'unsigned int' but the argument type is 'int'.
[net/core/net-sysfs.c:1162]: (warning) %u in format string (no. 1)
requires 'unsigned int' but the argument type is 'int'.
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Ye Bin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Fix follow warnings:
[net/core/pktgen.c:925]: (warning) %u in format string (no. 1)
requires 'unsigned int' but the argument type is 'signed int'.
[net/core/pktgen.c:942]: (warning) %u in format string (no. 1)
requires 'unsigned int' but the argument type is 'signed int'.
[net/core/pktgen.c:962]: (warning) %u in format string (no. 1)
requires 'unsigned int' but the argument type is 'signed int'.
[net/core/pktgen.c:984]: (warning) %u in format string (no. 1)
requires 'unsigned int' but the argument type is 'signed int'.
[net/core/pktgen.c:1149]: (warning) %d in format string (no. 1)
requires 'int' but the argument type is 'unsigned int'.
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Ye Bin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The fr_hard_header function is used to prepend the header to skbs before
transmission. It is used in 3 situations:
1) When a control packet is generated internally in this driver;
2) When a user sends an skb on an Ethernet-emulating PVC device;
3) When a user sends an skb on a normal PVC device.
These 3 situations need to be handled differently by fr_hard_header.
Different headers should be prepended to the skb in different situations.
Currently fr_hard_header distinguishes these 3 situations using
skb->protocol. For situation 1 and 2, a special skb->protocol value
will be assigned before calling fr_hard_header, so that it can recognize
these 2 situations. All skb->protocol values other than these special ones
are treated by fr_hard_header as situation 3.
However, it is possible that in situation 3, the user sends an skb with
one of the special skb->protocol values. In this case, fr_hard_header
would incorrectly treat it as situation 1 or 2.
This patch tries to solve this issue by using skb->dev instead of
skb->protocol to distinguish between these 3 situations. For situation
1, skb->dev would be NULL; for situation 2, skb->dev->type would be
ARPHRD_ETHER; and for situation 3, skb->dev->type would be ARPHRD_DLCI.
This way fr_hard_header would be able to distinguish these 3 situations
correctly regardless what skb->protocol value the user tries to use in
situation 3.
Cc: Krzysztof Halasa <[email protected]>
Signed-off-by: Xie He <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Daniel Borkmann says:
====================
pull-request: bpf-next 2020-10-01
The following pull-request contains BPF updates for your *net-next* tree.
We've added 90 non-merge commits during the last 8 day(s) which contain
a total of 103 files changed, 7662 insertions(+), 1894 deletions(-).
Note that once bpf(/net) tree gets merged into net-next, there will be a small
merge conflict in tools/lib/bpf/btf.c between commit 1245008122d7 ("libbpf: Fix
native endian assumption when parsing BTF") from the bpf tree and the commit
3289959b97ca ("libbpf: Support BTF loading and raw data output in both endianness")
from the bpf-next tree. Correct resolution would be to stick with bpf-next, it
should look like:
[...]
/* check BTF magic */
if (fread(&magic, 1, sizeof(magic), f) < sizeof(magic)) {
err = -EIO;
goto err_out;
}
if (magic != BTF_MAGIC && magic != bswap_16(BTF_MAGIC)) {
/* definitely not a raw BTF */
err = -EPROTO;
goto err_out;
}
/* get file size */
[...]
The main changes are:
1) Add bpf_snprintf_btf() and bpf_seq_printf_btf() helpers to support displaying
BTF-based kernel data structures out of BPF programs, from Alan Maguire.
2) Speed up RCU tasks trace grace periods by a factor of 50 & fix a few race
conditions exposed by it. It was discussed to take these via BPF and
networking tree to get better testing exposure, from Paul E. McKenney.
3) Support multi-attach for freplace programs, needed for incremental attachment
of multiple XDP progs using libxdp dispatcher model, from Toke Høiland-Jørgensen.
4) libbpf support for appending new BTF types at the end of BTF object, allowing
intrusive changes of prog's BTF (useful for future linking), from Andrii Nakryiko.
5) Several BPF helper improvements e.g. avoid atomic op in cookie generator and add
a redirect helper into neighboring subsys, from Daniel Borkmann.
6) Allow map updates on sockmaps from bpf_iter context in order to migrate sockmaps
from one to another, from Lorenz Bauer.
7) Fix 32 bit to 64 bit assignment from latest alu32 bounds tracking which caused
a verifier issue due to type downgrade to scalar, from John Fastabend.
8) Follow-up on tail-call support in BPF subprogs which optimizes x64 JIT prologue
and epilogue sections, from Maciej Fijalkowski.
9) Add an option to perf RB map to improve sharing of event entries by avoiding remove-
on-close behavior. Also, add BPF_PROG_TEST_RUN for raw_tracepoint, from Song Liu.
10) Fix a crash in AF_XDP's socket_release when memory allocation for UMEMs fails,
from Magnus Karlsson.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull iommu fixes from Joerg Roedel:
- Fix a device reference counting bug in the Exynos IOMMU driver.
- Lockdep fix for the Intel VT-d driver.
- Fix a bug in the AMD IOMMU driver which caused corruption of the IVRS
ACPI table and caused IOMMU driver initialization failures in kdump
kernels.
* tag 'iommu-fixes-v5.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/vt-d: Fix lockdep splat in iommu_flush_dev_iotlb()
iommu/amd: Fix the overwritten field in IVMD header
iommu/exynos: add missing put_device() call in exynos_iommu_of_xlate()
|
|
onfiguration'
Geert Uytterhoeven says:
====================
net/ravb: Add support for explicit internal clock delay configuration
Some Renesas EtherAVB variants support internal clock delay
configuration, which can add larger delays than the delays that are
typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or
"[rt]xc-skew-ps" properties).
Historically, the EtherAVB driver configured these delays based on the
"rgmii-*id" PHY mode. This caused issues with PHY drivers that
implement PHY internal delays properly[1]. Hence a backwards-compatible
workaround was added by masking the PHY mode[2].
This patch series implements the next step of the plan outlined in [3],
and adds proper support for explicit configuration of the MAC internal
clock delays using new "[rt]x-internal-delay-ps" properties. If none of
these properties is present, the driver falls back to the old handling.
This can be considered the MAC counterpart of commit 9150069bf5fc0e86
("dt-bindings: net: Add tx and rx internal delays"), which applies to
the PHY. Note that unlike commit 92252eec913b2dd5 ("net: phy: Add a
helper to return the index for of the internal delay"), no helpers are
provided to parse the DT properties, as so far there is a single user
only, which supports only zero or a single fixed value. Of course such
helpers can be added later, when the need arises, or when deemed useful
otherwise.
This series consists of 3 parts:
1. DT binding updates documenting the new properties, for both the
generic ethernet-controller and the EtherAVB-specific bindings,
2. Conversion to json-schema of the Renesas EtherAVB DT bindings.
Technically, the conversion is independent of all of the above.
I included it in this series, as it shows how all sanity checks on
"[rt]x-internal-delay-ps" values are implemented as DT binding
checks,
3. EtherAVB driver update implementing support for the new properties.
Given Rob has provided his acks for the DT binding updates, all of this
can be merged through net-next.
Changes compared to v3[4]:
- Add Reviewed-by,
- Drop the DT updates, as they will be merged through renesas-devel and
arm-soc, and have a hard dependency on this series.
Changes compared to v2[5]:
- Update recently added board DTS files,
- Add Reviewed-by.
Changes compared to v1[6]:
- Added "[PATCH 1/7] dt-bindings: net: ethernet-controller: Add
internal delay properties",
- Replace "renesas,[rt]xc-delay-ps" by "[rt]x-internal-delay-ps",
- Incorporated EtherAVB DT binding conversion to json-schema,
- Add Reviewed-by.
Impacted, tested:
- Salvator-X(S) with R-Car H3 ES1.0 and ES2.0, M3-W, and M3-N.
Not impacted, tested:
- Ebisu with R-Car E3.
Impacted, not tested:
- Salvator-X(S) with other SoC variants,
- ULCB with R-Car H3/M3-W/M3-N variants,
- V3MSK and Eagle with R-Car V3M,
- Draak with R-Car V3H,
- HiHope RZ/G2[MN] with RZ/G2M or RZ/G2N,
- Beacon EmbeddedWorks RZ/G2M Development Kit.
To ease testing, I have pushed this series and the DT updates to the
topic/ravb-internal-clock-delays-v4 branch of my renesas-drivers
repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
Thanks for applying!
References:
[1] Commit bcf3440c6dd78bfe ("net: phy: micrel: add phy-mode support
for the KSZ9031 PHY")
[2] Commit 9b23203c32ee02cd ("ravb: Mask PHY mode to avoid inserting
delays twice").
https://lore.kernel.org/r/[email protected]/
[3] https://lore.kernel.org/r/CAMuHMdU+MR-2tr3-pH55G0GqPG9HwH3XUd=8HZxprFDMGQeWUw@mail.gmail.com/
[4] https://lore.kernel.org/linux-devicetree/[email protected]/
[5] https://lore.kernel.org/linux-devicetree/[email protected]/
[6] https://lore.kernel.org/linux-devicetree/[email protected]/
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
Some EtherAVB variants support internal clock delay configuration, which
can add larger delays than the delays that are typically supported by
the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps"
properties).
Historically, the EtherAVB driver configured these delays based on the
"rgmii-*id" PHY mode. This caused issues with PHY drivers that
implement PHY internal delays properly[1]. Hence a backwards-compatible
workaround was added by masking the PHY mode[2].
Add proper support for explicit configuration of the MAC internal clock
delays using the new "[rt]x-internal-delay-ps" properties.
Fall back to the old handling if none of these properties is present.
[1] Commit bcf3440c6dd78bfe ("net: phy: micrel: add phy-mode support for
the KSZ9031 PHY")
[2] Commit 9b23203c32ee02cd ("ravb: Mask PHY mode to avoid inserting
delays twice").
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Sergei Shtylyov <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Currently, full delay handling is done in both the probe and resume
paths. Split it in two parts, so the resume path doesn't have to redo
the parsing part over and over again.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Sergei Shtylyov <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Convert the Renesas Ethernet AVB (EthernetAVB-IF) Device Tree binding
documentation to json-schema.
Add missing properties.
Update the example to match reality.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Sergei Shtylyov <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Some EtherAVB variants support internal clock delay configuration, which
can add larger delays than the delays that are typically supported by
the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps"
properties).
Add properties for configuring the internal MAC delays.
These properties are mandatory, even when specified as zero, to
distinguish between old and new DTBs.
Update the (bogus) example accordingly.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Sergei Shtylyov <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Internal Receive and Transmit Clock Delays are a common setting for
RGMII capable devices.
While these delays are typically applied by the PHY, some MACs support
configuring internal clock delay settings, too. Hence add standardized
properties to configure this.
This is the MAC counterpart of commit 9150069bf5fc0e86 ("dt-bindings:
net: Add tx and rx internal delays"), which applies to the PHY.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
ath.git patches for v5.10. Major changes:
ath11k
* improvements to QCA6390 PCI support, adding essential missing
features: ELF board files, packet log handling to avoid data stalls
and crash fixes
|
|
Petr reported that after resume from suspend RTL8402 partially
truncates incoming packets, and re-initializing register RxConfig
before the actual chip re-initialization sequence is needed to avoid
the issue.
Reported-by: Petr Tesarik <[email protected]>
Proposed-by: Petr Tesarik <[email protected]>
Tested-by: Petr Tesarik <[email protected]>
Signed-off-by: Heiner Kallweit <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Petr reported that system freezes on r8169 driver load on a system
using ether_clk. The original change was done under the assumption
that the clock isn't needed for basic operations like chip register
access. But obviously that was wrong.
Therefore effectively revert the original change, and in addition
leave the clock active when suspending and WoL is enabled. Chip may
not be able to process incoming packets otherwise.
Fixes: 9f0b54cd1672 ("r8169: move switching optional clock on/off to pll power functions")
Reported-by: Petr Tesarik <[email protected]>
Tested-by: Petr Tesarik <[email protected]>
Signed-off-by: Heiner Kallweit <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
In bmps mode, beacons are filtered, and firmware is in charge
of monitoring the beacons and report changes or loss.
mac80211 must be advertised about such change to prevent it's
internal timer based beacon monitor to report beacon loss.
Fix that by setting/clearing the IEEE80211_VIF_BEACON_FILTER
vif flag on bmps entry/exit.
Signed-off-by: Loic Poulain <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
These casts are not needed. No changes in functionality.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Host sends wmi command to allow hardware enter idle power
save mode in ath11k_mac_op_start function.
hw parameter idle_ps indicates whether idle power save is supported.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
For QCA6390, Start a timer to update CE pipe 4 ring HP when shadow
register is enabled. Its' to avoid that HP isn't updated to target
register.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Start a timer to update REO HP if HP isn't updated to target.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The timer is to check if TCL HP isn't updated to target.
The timer will postpone itself if there are TX operations
during the interval, otherwise the timer handler updates
the HP again so the index value in HP register will be
forwarded to target register, and the timer stops afterwards.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
For QCA6390, set wmi credit to 1 to avoid back-to-back write to
shadow register when shadow register is enabled.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
To enable shadow register access, host needs to pass shadow
register configuration to firmware via qmi message. Host also
needs to update ring's HP or TP address to shadow register
address. The write operation to shadow register will be
forwarded to target register by hardware automatically, and
the write operation to shadow register is permitted even
when the target is in power save or sleep mode.
Update the shadow config whenever power up happens.
This feature is controlled by hw parameter supports_shadow_regs which is only
enabled for QCA6390.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
For QCA6390, host can read and write registers below unwindowed
address directly without programming the window register. For
registers below bar0 + 4k - 32, host can read and write regardless
of the power save state. Shadow registers are located below
bar0 + 4K - 32.
Before MHI power up, there is no need to wakeup MHI so ini_done is
added to indicate it.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
With QCA6390 when doing rmmod the kernel crashed. The reason was that the
destroy functions ath11k_debugfs_pdev_destroy() and ath11k_debugfs_soc_destroy()
accidentally had swapped the debugfs directories and
ath11k_debugfs_soc_destroy() was removing an already removed directory, which
crashed the kernel.
The source of confusion is badly named function and variable names. I think the
best way to clean this up is actually to merge the corresponding functions, but
that's for another patch. Let's first just fix the crash.
[ 43.430245] ------------[ cut here ]------------
[ 43.430247] DEBUG_LOCKS_WARN_ON(1)
[ 43.430253] WARNING: CPU: 4 PID: 2148 at kernel/locking/lockdep.c:183 check_wait_context+0x231/0x290
[ 43.430255] Modules linked in: ath11k_pci(-) ath11k qmi_helpers qrtr_mhi mhi qrtr ns nvme nvme_core
[ 43.430261] CPU: 4 PID: 2148 Comm: rmmod Not tainted 5.9.0-rc5-wt-ath+ #198
[ 43.430262] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018
[ 43.430265] RIP: 0010:check_wait_context+0x231/0x290
[ 43.430267] Code: ff ff e8 42 83 bf 00 85 c0 74 f0 44 8b 15 af 0d 90 01 45 85 d2 75 e4 48 c7 c6 7f e5 37 8d 48 c7 c7 8d 81 34 8d e8 c3 01 fa ff <0f> 0b 31 c0 e9 01 fe ff f
[ 43.430268] RSP: 0018:ffffa36140f23bf8 EFLAGS: 00010082
[ 43.430270] RAX: 0000000000000000 RBX: e7a8b0f303fcdbd7 RCX: 0000000000000000
[ 43.430272] RDX: 0000000000000016 RSI: ffffffff8bee5824 RDI: ffffffff8d66fd60
[ 43.430273] RBP: ffff936573551d80 R08: 0000000a1ca4fc0e R09: 0000000000000016
[ 43.430275] R10: 0000000000000046 R11: ffffa36140f23a35 R12: ffff936573552670
[ 43.430276] R13: 0000000000000000 R14: ffff936573552638 R15: 0000000000000001
[ 43.430278] FS: 00007f03e78c8700(0000) GS:ffff93659c800000(0000) knlGS:0000000000000000
[ 43.430280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 43.430282] CR2: 000056424768fee8 CR3: 00000001f7b46003 CR4: 00000000003706e0
[ 43.430283] Call Trace:
[ 43.430286] __lock_acquire+0x1c0/0x6e0
[ 43.430289] lock_acquire+0xb6/0x270
[ 43.430292] ? lockref_get+0x9/0x20
[ 43.430295] ? lock_acquire+0xb6/0x270
[ 43.430297] ? simple_pin_fs+0x1d/0xa0
[ 43.430299] ? find_held_lock+0x32/0x90
[ 43.430303] _raw_spin_lock+0x2c/0x70
[ 43.430305] ? lockref_get+0x9/0x20
[ 43.430306] lockref_get+0x9/0x20
[ 43.430308] simple_recursive_removal+0x31/0x2f0
[ 43.430310] ? debugfs_rename+0x40/0x40
[ 43.430312] debugfs_remove+0x3b/0x60
[ 43.430320] ath11k_debug_soc_destroy+0x10/0x20 [ath11k]
[ 43.430325] ath11k_core_deinit+0xab/0xd0 [ath11k]
[ 43.430327] ath11k_pci_remove+0x1b/0xb0 [ath11k_pci]
[ 43.430329] pci_device_remove+0x36/0x90
[ 43.430331] __device_release_driver+0x16c/0x220
[ 43.430333] driver_detach+0xcf/0x110
[ 43.430334] bus_remove_driver+0x4d/0xa2
[ 43.430336] pci_unregister_driver+0x25/0xa0
[ 43.430338] __do_sys_delete_module+0x163/0x240
[ 43.430340] ? lockdep_hardirqs_on_prepare.part.0+0x9f/0x140
[ 43.430342] ? syscall_enter_from_user_mode+0x1d/0x50
[ 43.430343] ? trace_hardirqs_on+0x1c/0x100
[ 43.430345] do_syscall_64+0x33/0x40
[ 43.430347] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 43.430348] RIP: 0033:0x7f03e73f89e7
[ 43.430350] Code: 73 01 c3 48 8b 0d b1 c4 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c
[ 43.430351] RSP: 002b:00007ffdb61d6198 EFLAGS: 00000202 ORIG_RAX: 00000000000000b0
[ 43.430352] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f03e73f89e7
[ 43.430353] RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000556f67d922e8
[ 43.430354] RBP: 0000556f67d92280 R08: 0000000000000000 R09: 1999999999999999
[ 43.430355] R10: 0000000000000883 R11: 0000000000000202 R12: 00007ffdb61d63b0
[ 43.430356] R13: 00007ffdb61d7917 R14: 0000000000000000 R15: 0000556f67d92280
[ 43.430358] irq event stamp: 240801
[ 43.430360] hardirqs last enabled at (240801): [<ffffffff8c02d0e5>] cmpxchg_double_slab.constprop.0+0x185/0x1a0
[ 43.430362] hardirqs last disabled at (240800): [<ffffffff8c02d03e>] cmpxchg_double_slab.constprop.0+0xde/0x1a0
[ 43.430364] softirqs last enabled at (240680): [<ffffffffc01eee37>] ath11k_pci_read32+0x87/0xe0 [ath11k_pci]
[ 43.430365] softirqs last disabled at (240678): [<ffffffffc01eedf8>] ath11k_pci_read32+0x48/0xe0 [ath11k_pci]
[ 43.430366] ---[ end trace dc96c4234c294fe8 ]---
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Fix warning caused by lockdep_assert_held when CONFIG_LOCKDEP is enabled.
[ 271.940647] WARNING: CPU: 6 PID: 0 at drivers/net/wireless/ath/ath11k/hal.c:818 ath11k_hal_srng_access_begin+0x31/0x40 [ath11k]
[ 271.940655] Modules linked in: qrtr_mhi qrtr ns ath11k_pci mhi ath11k qmi_helpers nvme nvme_core
[ 271.940675] CPU: 6 PID: 0 Comm: swapper/6 Kdump: loaded Tainted: G W 5.9.0-rc5-kalle-bringup-wt-ath+ #4
[ 271.940682] Hardware name: Dell Inc. Inspiron 7590/08717F, BIOS 1.3.0 07/22/2019
[ 271.940698] RIP: 0010:ath11k_hal_srng_access_begin+0x31/0x40 [ath11k]
[ 271.940708] Code: 48 89 f3 85 c0 75 11 48 8b 83 a8 00 00 00 8b 00 89 83 b0 00 00 00 5b c3 48 8d 7e 58 be ff ff ff ff e8 53 24 ec fa 85 c0 75 dd <0f> 0b eb d9 90 66 2e 0f 1f 84 00 00 00 00 00 55 53 48 89 f3 8b 35
[ 271.940718] RSP: 0018:ffffbdf0c0230df8 EFLAGS: 00010246
[ 271.940727] RAX: 0000000000000000 RBX: ffffa12b34e67680 RCX: ffffa12b57a0d800
[ 271.940735] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffffa12b34e676d8
[ 271.940742] RBP: ffffa12b34e60000 R08: 0000000000000001 R09: 0000000000000001
[ 271.940753] R10: 0000000000000001 R11: 0000000000000046 R12: 0000000000000000
[ 271.940763] R13: ffffa12b34e60000 R14: ffffa12b34e60000 R15: 0000000000000000
[ 271.940774] FS: 0000000000000000(0000) GS:ffffa12b5a400000(0000) knlGS:0000000000000000
[ 271.940788] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 271.940798] CR2: 00007f8bef282008 CR3: 00000001f4224004 CR4: 00000000003706e0
[ 271.940805] Call Trace:
[ 271.940813] <IRQ>
[ 271.940835] ath11k_dp_tx_completion_handler+0x9e/0x950 [ath11k]
[ 271.940847] ? lock_acquire+0xba/0x3b0
[ 271.940876] ath11k_dp_service_srng+0x5a/0x2e0 [ath11k]
[ 271.940893] ath11k_pci_ext_grp_napi_poll+0x1e/0x80 [ath11k_pci]
[ 271.940908] net_rx_action+0x283/0x4f0
[ 271.940931] __do_softirq+0xcb/0x499
[ 271.940950] asm_call_on_stack+0x12/0x20
[ 271.940963] </IRQ>
[ 271.940979] do_softirq_own_stack+0x4d/0x60
[ 271.940991] irq_exit_rcu+0xb0/0xc0
[ 271.941001] common_interrupt+0xce/0x190
[ 271.941014] asm_common_interrupt+0x1e/0x40
[ 271.941026] RIP: 0010:cpuidle_enter_state+0x115/0x500
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The conf_mutex is not use and lead below deadlock, remove it to solve
the deadlock issue.
[ 44.967496] NET: Registered protocol family 42
[ 45.119629] ath11k_pci 0000:06:00.0: WARNING: ath11k PCI support is experimental!
[ 45.120087] ath11k_pci 0000:06:00.0: BAR 0: assigned [mem 0xdc000000-0xdc0fffff 64bit]
[ 45.120108] ath11k_pci 0000:06:00.0: enabling device (0000 -> 0002)
[ 45.206525] ath11k_pci 0000:06:00.0: aspm 0x42 changed to 0x40
[ 45.207430] mhi 0000:06:00.0: Requested to power ON
[ 45.208609] mhi 0000:06:00.0: Power on setup success
[ 46.190711] ath11k_pci 0000:06:00.0: chip_id 0x0 chip_family 0xb board_id 0x101 soc_id 0xffffffff
[ 46.190729] ath11k_pci 0000:06:00.0: fw_version 0x306a70f fw_build_timestamp 2000-01-01 00:00 fw_build_id
1]: Starting Load/Save RF Kill Switch Status...
[ 46.385118] ath11k_pci 0000:06:00.0 wlp6s0: renamed from wlan0
1]: Started Load/Save RF Kill Switch Status.
[ 53.566669] wlp6s0: authenticate with 00:03:7f:48:dd:bf
[ 53.809092] wlp6s0: send auth to 00:03:7f:48:dd:bf (try 1/3)
[ 53.816490] wlp6s0: authenticated
[ 53.818618] wlp6s0: associate with 00:03:7f:48:dd:bf (try 1/3)
[ 53.820839] wlp6s0: RX AssocResp from 00:03:7f:48:dd:bf (capab=0x1 status=0 aid=2)
[ 53.834859]
[ 53.834861] ======================================================
[ 53.834862] WARNING: possible circular locking dependency detected
[ 53.834863] 5.9.0-rc5-wt-ath+ #198 Not tainted
[ 53.834864] ------------------------------------------------------
[ 53.834865] kworker/u16:3/166 is trying to acquire lock:
[ 53.834866] ffff8c4b37184f78 (&ar->conf_mutex){+.+.}-{3:3}, at: ath11k_mac_op_config+0x16/0x30 [ath11k]
[ 53.834875]
[ 53.834875] but task is already holding lock:
[ 53.834876] ffff8c4b37182808 (&local->iflist_mtx){+.+.}-{3:3}, at: ieee80211_set_associated+0x167/0x360
[ 53.834879]
[ 53.834879] which lock already depends on the new lock.
[ 53.834879]
[ 53.834880]
[ 53.834880] the existing dependency chain (in reverse order) is:
[ 53.834881]
[ 53.834881] -> #1 (&local->iflist_mtx){+.+.}-{3:3}:
[ 53.834884] __lock_acquire+0x3bf/0x6e0
[ 53.834886] lock_acquire+0xb6/0x270
[ 53.834887] __mutex_lock+0x88/0x8e0
[ 53.834890] ieee80211_set_hw_80211_encap+0x3e/0x1f0
[ 53.834895] ath11k_mac_op_add_interface+0x348/0x7f0 [ath11k]
[ 53.834897] drv_add_interface+0x7c/0x190
[ 53.834899] ieee80211_do_open+0x552/0x9a0
[ 53.834901] __dev_open+0xe5/0x190
[ 53.834902] __dev_change_flags+0x1c6/0x230
[ 53.834903] dev_change_flags+0x1c/0x50
[ 53.834905] do_setlink+0x246/0xc60
[ 53.834906] __rtnl_newlink+0x607/0x990
[ 53.834907] rtnl_newlink+0x3f/0x60
[ 53.834908] rtnetlink_rcv_msg+0x174/0x490
[ 53.834910] netlink_rcv_skb+0x42/0x100
[ 53.834911] netlink_unicast+0x18c/0x250
[ 53.834912] netlink_sendmsg+0x227/0x460
[ 53.834914] sock_sendmsg+0x59/0x60
[ 53.834915] ____sys_sendmsg+0x1f5/0x230
[ 53.834916] ___sys_sendmsg+0x70/0xb0
[ 53.834917] __sys_sendmsg+0x54/0xa0
[ 53.834919] do_syscall_64+0x33/0x40
[ 53.834920] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.834921]
[ 53.834921] -> #0 (&ar->conf_mutex){+.+.}-{3:3}:
[ 53.834923] check_prev_add+0x98/0x9f0
[ 53.834925] validate_chain+0x404/0x6c0
[ 53.834926] __lock_acquire+0x3bf/0x6e0
[ 53.834927] lock_acquire+0xb6/0x270
[ 53.834929] __mutex_lock+0x88/0x8e0
[ 53.834934] ath11k_mac_op_config+0x16/0x30 [ath11k]
[ 53.834935] ieee80211_hw_config+0xb3/0x270
[ 53.834937] ieee80211_set_associated+0x17c/0x360
[ 53.834938] ieee80211_assoc_success.constprop.0+0x5a2/0xc80
[ 53.834940] ieee80211_rx_mgmt_assoc_resp+0x16a/0x350
[ 53.834941] ieee80211_sta_rx_queued_mgmt+0xca/0x410
[ 53.834943] ieee80211_iface_work+0x1f3/0x350
[ 53.834945] process_one_work+0x265/0x5d0
[ 53.834946] worker_thread+0x49/0x300
[ 53.834948] kthread+0x135/0x150
[ 53.834949] ret_from_fork+0x22/0x30
[ 53.834950]
[ 53.834950] other info that might help us debug this:
[ 53.834950]
[ 53.834951] Possible unsafe locking scenario:
[ 53.834951]
[ 53.834952] CPU0 CPU1
[ 53.834952] ---- ----
[ 53.834953] lock(&local->iflist_mtx);
[ 53.834954] lock(&ar->conf_mutex);
[ 53.834955] lock(&local->iflist_mtx);
[ 53.834956] lock(&ar->conf_mutex);
[ 53.834957]
[ 53.834957] *** DEADLOCK ***
[ 53.834957]
[ 53.834958] 4 locks held by kworker/u16:3/166:
[ 53.834959] #0: ffff8c4b37c22948 ((wq_completion)phy0){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0
[ 53.834961] #1: ffffa98300abfe70 ((work_completion)(&sdata->work)){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0
[ 53.834963] #2: ffff8c4b371e4cd0 (&wdev->mtx){+.+.}-{3:3}, at: ieee80211_sta_rx_queued_mgmt+0x4b/0x410
[ 53.834965] #3: ffff8c4b37182808 (&local->iflist_mtx){+.+.}-{3:3}, at: ieee80211_set_associated+0x167/0x360
[ 53.834968]
[ 53.834968] stack backtrace:
[ 53.834969] CPU: 1 PID: 166 Comm: kworker/u16:3 Not tainted 5.9.0-rc5-wt-ath+ #198
[ 53.834970] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018
[ 53.834972] Workqueue: phy0 ieee80211_iface_work
[ 53.834974] Call Trace:
[ 53.834976] dump_stack+0x77/0xa0
[ 53.834978] check_noncircular+0x15d/0x180
[ 53.834980] check_prev_add+0x98/0x9f0
[ 53.834982] ? add_chain_cache+0x143/0x440
[ 53.834984] validate_chain+0x404/0x6c0
[ 53.834986] __lock_acquire+0x3bf/0x6e0
[ 53.834988] lock_acquire+0xb6/0x270
[ 53.834993] ? ath11k_mac_op_config+0x16/0x30 [ath11k]
[ 53.834999] ? ath11k_mac_op_config+0x16/0x30 [ath11k]
[ 53.835001] __mutex_lock+0x88/0x8e0
[ 53.835006] ? ath11k_mac_op_config+0x16/0x30 [ath11k]
[ 53.835007] ? sched_clock_cpu+0xc/0xb0
[ 53.835009] ? __lock_release+0x179/0x2c0
[ 53.835014] ath11k_mac_op_config+0x16/0x30 [ath11k]
[ 53.835016] ieee80211_hw_config+0xb3/0x270
[ 53.835018] ieee80211_set_associated+0x17c/0x360
[ 53.835019] ieee80211_assoc_success.constprop.0+0x5a2/0xc80
[ 53.835021] ? lockdep_hardirqs_on_prepare.part.0+0x9f/0x140
[ 53.835023] ? cmpxchg_double_slab.constprop.0+0x185/0x1a0
[ 53.835025] ? trace_hardirqs_on+0x1c/0x100
[ 53.835027] ? __slab_free+0x8f/0x330
[ 53.835029] ? slab_free_freelist_hook+0xf8/0x150
[ 53.835031] ? ieee802_11_parse_elems_crc+0x147/0x1d0
[ 53.835032] ? kfree+0x2b0/0x2d0
[ 53.835034] ? ieee802_11_parse_elems_crc+0x147/0x1d0
[ 53.835036] ieee80211_rx_mgmt_assoc_resp+0x16a/0x350
[ 53.835041] ieee80211_sta_rx_queued_mgmt+0xca/0x410
[ 53.835043] ? __lock_acquire+0x3bf/0x6e0
[ 53.835045] ? lock_acquire+0xb6/0x270
[ 53.835046] ? skb_dequeue+0x13/0x70
[ 53.835048] ? find_held_lock+0x32/0x90
[ 53.835049] ? sched_clock_cpu+0xc/0xb0
[ 53.835051] ? mark_held_locks+0x50/0x80
[ 53.835053] ? lockdep_hardirqs_on_prepare.part.0+0x9f/0x140
[ 53.835054] ? _raw_spin_unlock_irqrestore+0x34/0x40
[ 53.835056] ? trace_hardirqs_on+0x1c/0x100
[ 53.835058] ieee80211_iface_work+0x1f3/0x350
[ 53.835060] process_one_work+0x265/0x5d0
[ 53.835062] worker_thread+0x49/0x300
[ 53.835063] ? process_one_work+0x5d0/0x5d0
[ 53.835065] kthread+0x135/0x150
[ 53.835066] ? kthread_create_worker_on_cpu+0x60/0x60
[ 53.835068] ret_from_fork+0x22/0x30
[ 53.835075] wlp6s0: associated
[ 53.835132] IPv6: ADDRCONF(NETDEV_CHANGE): wlp6s0: link becomes ready
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Wen Gong <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
For QCA6390 we first need to call free_irq() and only then disable_msi(). Otherwise a
kernel BUG below will happen. Also free core, hal_srng and ce resources during
ath11k_pci_remove().
[ 1089.425506] ------------[ cut here ]------------
[ 1089.425510] kernel BUG at drivers/pci/msi.c:375!
[ 1089.425514] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
[ 1089.425517] CPU: 1 PID: 20539 Comm: rmmod Not tainted 5.9.0-rc5-wt-ath+ #198
[ 1089.425519] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018
[ 1089.425523] RIP: 0010:free_msi_irqs+0x184/0x1b0
[ 1089.425526] Code: 14 85 c0 0f 84 cc fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 bc fe ff ff 8b 7b 10 01 ef e8 c3 01 bf ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 b0 00 00 0
[ 1089.425528] RSP: 0018:ffffb128c0cf7dd0 EFLAGS: 00010282
[ 1089.425530] RAX: ffff947d67549000 RBX: ffff947cd2d25200 RCX: 0000000000000000
[ 1089.425532] RDX: ffff947d94a6f928 RSI: ffff947d94a6fa18 RDI: 0000000000000099
[ 1089.425533] RBP: 0000000000000000 R08: ffff947d67549000 R09: ffffffff86670050
[ 1089.425535] R10: 0000000000000000 R11: 0000000000000000 R12: ffff947d96c194f0
[ 1089.425537] R13: ffff947d96c19000 R14: 0000000000000000 R15: ffffffffc0225250
[ 1089.425539] FS: 00007f97c44ed700(0000) GS:ffff947d9c200000(0000) knlGS:0000000000000000
[ 1089.425541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1089.425543] CR2: 00007f97c408d701 CR3: 0000000192bc0006 CR4: 00000000003706e0
[ 1089.425544] Call Trace:
[ 1089.425549] ath11k_pci_remove+0x2b/0x90 [ath11k_pci]
[ 1089.425553] pci_device_remove+0x36/0x90
[ 1089.425556] __device_release_driver+0x16c/0x220
[ 1089.425559] driver_detach+0xcf/0x110
[ 1089.425561] bus_remove_driver+0x4d/0xa2
[ 1089.425564] pci_unregister_driver+0x25/0xa0
[ 1089.425568] __do_sys_delete_module+0x163/0x240
[ 1089.425571] ? trace_hardirqs_on+0x1c/0x100
[ 1089.425575] do_syscall_64+0x33/0x40
[ 1089.425577] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1089.425579] RIP: 0033:0x7f97c401d9e7
[ 1089.425581] Code: 73 01 c3 48 8b 0d b1 c4 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c
[ 1089.425583] RSP: 002b:00007fff1e0fb728 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[ 1089.425585] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f97c401d9e7
[ 1089.425587] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005585aad022e8
[ 1089.425589] RBP: 00005585aad02280 R08: 0000000000000000 R09: 1999999999999999
[ 1089.425591] R10: 0000000000000883 R11: 0000000000000206 R12: 00007fff1e0fb940
[ 1089.425592] R13: 00007fff1e0fd917 R14: 0000000000000000 R15: 00005585aad02280
[ 1089.425596] Modules linked in: ath11k_pci(-) ath11k qmi_helpers qrtr_mhi mhi qrtr ns nvme nvme_core [last unloaded: mhi]
[ 1089.425603] ---[ end trace 2a81926cc0708a38 ]---
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Add packet log support for QCA6390, otherwise the data connection will stall
within a minute or so. Enable it via debugfs and use trace-cmd to capture the
pktlogs.
echo 0xffff 1 > /sys/kernel/debug/ath11k/qca6390\ hw2.0/mac0/pktlog_filter
The mon status ring doesn't support interrupt so far, so host starts
a timer to reap this ring. The timer handler also reaps the
rxdma_err_dst_ring in case of monitor mode.
As QCA6390 requires bss created ahead of starting vdev, so check
vdev_start_delay for monitor mode.
For QCA6390, it uses wbm_desc_rel_ring to return descriptors.
It also uses rx_refill_buf_ring to fill mon buffer instead of
rxdma_mon_buf_ring.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
With SLUB DEBUG CONFIG below crash is seen as kmem_cache_alloc
is being called in non-atomic context.
To fix this issue, use GFP_ATOMIC instead of GFP_KERNEL in idr_alloc.
BUG: sleeping function called from invalid context at mm/slab.h:393
[ 59.805451] Call trace:
[ 59.807971] ___might_sleep+0x110/0x118
[ 59.811915] __might_sleep+0x50/0x84
[ 59.815593] kmem_cache_alloc+0x60/0x3e0
[ 59.819630] radix_tree_node_alloc+0x4c/0xe8
[ 59.824014] radix_tree_extend+0x8c/0x164
[ 59.828135] idr_get_free_cmn+0xa4/0x27c
[ 59.832167] idr_alloc_cmn+0x70/0xe8
[ 59.835856] ath11k_dp_rxbufs_replenish+0x1e8/0x310 [ath11k]
[ 59.841687] ath11k_dp_rxdma_ring_buf_setup+0x50/0x60 [ath11k]
[ 59.847693] ath11k_dp_rx_pdev_alloc+0x260/0x4d8 [ath11k]
[ 59.853248] ath11k_dp_pdev_alloc+0x40/0xc4 [ath11k]
[ 59.858357] ath11k_core_qmi_firmware_ready+0x3c4/0x490 [ath11k]
[ 59.864538] ath11k_qmi_driver_event_work+0x4c8/0x1178 [ath11k]
[ 59.870620] process_one_work+0x208/0x434
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Govind Singh <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
With SLUB DEBUG CONFIG below crash is seen as kmem_cache_alloc
is being called in non-atomic context.
To fix this issue, use GFP_ATOMIC instead of GFP_KERNEL kzalloc.
[ 357.217088] BUG: sleeping function called from invalid context at mm/slab.h:498
[ 357.217091] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/0
[ 357.217092] INFO: lockdep is turned off.
[ 357.217095] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.9.0-rc5-wt-ath+ #196
[ 357.217096] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018
[ 357.217097] Call Trace:
[ 357.217098] <IRQ>
[ 357.217107] ? ath11k_dp_htt_get_ppdu_desc+0xa9/0x170 [ath11k]
[ 357.217110] dump_stack+0x77/0xa0
[ 357.217113] ___might_sleep.cold+0xa6/0xb6
[ 357.217116] kmem_cache_alloc_trace+0x1f2/0x270
[ 357.217122] ath11k_dp_htt_get_ppdu_desc+0xa9/0x170 [ath11k]
[ 357.217129] ath11k_htt_pull_ppdu_stats.isra.0+0x96/0x270 [ath11k]
[ 357.217135] ath11k_dp_htt_htc_t2h_msg_handler+0xe7/0x1d0 [ath11k]
[ 357.217137] ? trace_hardirqs_on+0x1c/0x100
[ 357.217143] ath11k_htc_rx_completion_handler+0x207/0x370 [ath11k]
[ 357.217149] ath11k_ce_recv_process_cb+0x15e/0x1e0 [ath11k]
[ 357.217151] ? handle_irq_event+0x70/0xa8
[ 357.217154] ath11k_pci_ce_tasklet+0x10/0x30 [ath11k_pci]
[ 357.217157] tasklet_action_common.constprop.0+0xd4/0xf0
[ 357.217160] __do_softirq+0xc9/0x482
[ 357.217162] asm_call_on_stack+0x12/0x20
[ 357.217163] </IRQ>
[ 357.217166] do_softirq_own_stack+0x49/0x60
[ 357.217167] irq_exit_rcu+0x9a/0xd0
[ 357.217169] common_interrupt+0xa1/0x190
[ 357.217171] asm_common_interrupt+0x1e/0x40
[ 357.217173] RIP: 0010:cpu_idle_poll.isra.0+0x2e/0x60
[ 357.217175] Code: 8b 35 26 27 74 69 e8 11 c8 3d ff e8 bc fa 42 ff e8 e7 9f 4a ff fb 65 48 8b 1c 25 80 90 01 00 48 8b 03 a8 08 74 0b eb 1c f3 90 <48> 8b 03 a8 08 75 13 8b 0
[ 357.217177] RSP: 0018:ffffffff97403ee0 EFLAGS: 00000202
[ 357.217178] RAX: 0000000000000001 RBX: ffffffff9742b8c0 RCX: 0000000000b890ca
[ 357.217180] RDX: 0000000000b890ca RSI: 0000000000000001 RDI: ffffffff968d0c49
[ 357.217181] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
[ 357.217182] R10: ffffffff9742b8c0 R11: 0000000000000046 R12: 0000000000000000
[ 357.217183] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000066fdf520
[ 357.217186] ? cpu_idle_poll.isra.0+0x19/0x60
[ 357.217189] do_idle+0x5f/0xe0
[ 357.217191] cpu_startup_entry+0x14/0x20
[ 357.217193] start_kernel+0x443/0x464
[ 357.217196] secondary_startup_64+0xa4/0xb0
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Wen Gong <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
After base_lock which occupy by ath11k_regd_update, the softirq run for
WMI_REG_CHAN_LIST_CC_EVENTID maybe arrived and it also need to accuire
the spin lock, then deadlock happend, change to disable softirqis to solve it.
[ 235.576990] ================================
[ 235.576991] WARNING: inconsistent lock state
[ 235.576993] 5.9.0-rc5-wt-ath+ #196 Not tainted
[ 235.576994] --------------------------------
[ 235.576995] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
[ 235.576997] kworker/u16:1/98 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 235.576998] ffff9655f75cad98 (&ab->base_lock){+.?.}-{2:2}, at: ath11k_regd_update+0x28/0x1d0 [ath11k]
[ 235.577009] {IN-SOFTIRQ-W} state was registered at:
[ 235.577013] __lock_acquire+0x219/0x6e0
[ 235.577015] lock_acquire+0xb6/0x270
[ 235.577018] _raw_spin_lock+0x2c/0x70
[ 235.577023] ath11k_reg_chan_list_event.isra.0+0x10d/0x1e0 [ath11k]
[ 235.577028] ath11k_wmi_tlv_op_rx+0x3c3/0x560 [ath11k]
[ 235.577033] ath11k_htc_rx_completion_handler+0x207/0x370 [ath11k]
[ 235.577039] ath11k_ce_recv_process_cb+0x15e/0x1e0 [ath11k]
[ 235.577041] ath11k_pci_ce_tasklet+0x10/0x30 [ath11k_pci]
[ 235.577043] tasklet_action_common.constprop.0+0xd4/0xf0
[ 235.577045] __do_softirq+0xc9/0x482
[ 235.577046] asm_call_on_stack+0x12/0x20
[ 235.577048] do_softirq_own_stack+0x49/0x60
[ 235.577049] irq_exit_rcu+0x9a/0xd0
[ 235.577050] common_interrupt+0xa1/0x190
[ 235.577052] asm_common_interrupt+0x1e/0x40
[ 235.577053] cpu_idle_poll.isra.0+0x2e/0x60
[ 235.577055] do_idle+0x5f/0xe0
[ 235.577056] cpu_startup_entry+0x14/0x20
[ 235.577058] start_kernel+0x443/0x464
[ 235.577060] secondary_startup_64+0xa4/0xb0
[ 235.577061] irq event stamp: 432035
[ 235.577063] hardirqs last enabled at (432035): [<ffffffff968d12b4>] _raw_spin_unlock_irqrestore+0x34/0x40
[ 235.577064] hardirqs last disabled at (432034): [<ffffffff968d10d3>] _raw_spin_lock_irqsave+0x63/0x80
[ 235.577066] softirqs last enabled at (431998): [<ffffffff967115c1>] inet6_fill_ifla6_attrs+0x3f1/0x430
[ 235.577067] softirqs last disabled at (431996): [<ffffffff9671159f>] inet6_fill_ifla6_attrs+0x3cf/0x430
[ 235.577068]
[ 235.577068] other info that might help us debug this:
[ 235.577069] Possible unsafe locking scenario:
[ 235.577069]
[ 235.577070] CPU0
[ 235.577070] ----
[ 235.577071] lock(&ab->base_lock);
[ 235.577072] <Interrupt>
[ 235.577073] lock(&ab->base_lock);
[ 235.577074]
[ 235.577074] *** DEADLOCK ***
[ 235.577074]
[ 235.577075] 3 locks held by kworker/u16:1/98:
[ 235.577076] #0: ffff9655f75b1d48 ((wq_completion)ath11k_qmi_driver_event){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0
[ 235.577079] #1: ffffa33cc02f3e70 ((work_completion)(&ab->qmi.event_work)){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0
[ 235.577081] #2: ffff9655f75cad50 (&ab->core_lock){+.+.}-{3:3}, at: ath11k_core_qmi_firmware_ready.part.0+0x4e/0x160 [ath11k]
[ 235.577087]
[ 235.577087] stack backtrace:
[ 235.577088] CPU: 3 PID: 98 Comm: kworker/u16:1 Not tainted 5.9.0-rc5-wt-ath+ #196
[ 235.577089] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018
[ 235.577095] Workqueue: ath11k_qmi_driver_event ath11k_qmi_driver_event_work [ath11k]
[ 235.577096] Call Trace:
[ 235.577100] dump_stack+0x77/0xa0
[ 235.577102] mark_lock_irq.cold+0x15/0x3c
[ 235.577104] mark_lock+0x1d7/0x540
[ 235.577105] mark_usage+0xc7/0x140
[ 235.577107] __lock_acquire+0x219/0x6e0
[ 235.577108] ? sched_clock_cpu+0xc/0xb0
[ 235.577110] lock_acquire+0xb6/0x270
[ 235.577116] ? ath11k_regd_update+0x28/0x1d0 [ath11k]
[ 235.577118] ? atomic_notifier_chain_register+0x2d/0x40
[ 235.577120] _raw_spin_lock+0x2c/0x70
[ 235.577125] ? ath11k_regd_update+0x28/0x1d0 [ath11k]
[ 235.577130] ath11k_regd_update+0x28/0x1d0 [ath11k]
[ 235.577136] __ath11k_mac_register+0x3fb/0x480 [ath11k]
[ 235.577141] ath11k_mac_register+0x119/0x180 [ath11k]
[ 235.577146] ath11k_core_pdev_create+0x17/0xe0 [ath11k]
[ 235.577150] ath11k_core_qmi_firmware_ready.part.0+0x65/0x160 [ath11k]
[ 235.577155] ath11k_qmi_driver_event_work+0x1c5/0x230 [ath11k]
[ 235.577158] process_one_work+0x265/0x5d0
[ 235.577160] worker_thread+0x49/0x300
[ 235.577161] ? process_one_work+0x5d0/0x5d0
[ 235.577163] kthread+0x135/0x150
[ 235.577164] ? kthread_create_worker_on_cpu+0x60/0x60
[ 235.577166] ret_from_fork+0x22/0x30
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Wen Gong <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
QCA6390 does not support monitor mode at the moment so disable it altogether,
using a hack as mac80211 does not support disabling it otherwise. Add a boolean
to hw_params to know if hardware supports monitor mode.
IPQ8074 continues to support monitor mode normally.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
There are different versions of QCA6390. Check TCSR_SOC_HW_VERSION to make sure
that the device is hw2.0, all the rest are unsupported.
This needs to be checked after ath11k_pci_claim() so move the whole switch choosing hw_ver.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
As QCA6390 does not support mesh interfaces, move the interface_modes to
hw_params. Also create interface combinations dynamically so that it's easy to
change the values.
Now QCA6390 does not claim to support mesh interfaces to user space, but
IPQ8074 continues to do that.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
For QCA6390, station vdev needs to delay startup but not for AP mode. On AP
mode vdev starts up immediately after bss peer is created in chanctx assignment
context.
This patch does not affect IPQ8074 family of devices.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The QCA6390 board I have, model 8291M-PR comes with an ELF board file. To get
this to at least somewhat work, I renamed bdwlan.e04 to 'board.bin' and then
added this patch to check for ELF magic string in the beginning of the file.
If that is found, use type ELF. After this the driver loads.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Ben Greear <[email protected]>
[[email protected]: use elf.h, minor cleanup]
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
debugfs_create_dir() returns an ERR_PTR in case of error, but never a
null pointer. There are a number of places where error-checking code can
accordingly be simplified.
Addresses-Coverity: CID 1497150: Memory - illegal accesses (USE_AFTER_FREE)
Addresses-Coverity: CID 1497158: Memory - illegal accesses (USE_AFTER_FREE)
Addresses-Coverity: CID 1497160: Memory - illegal accesses (USE_AFTER_FREE)
Signed-off-by: Alex Dewar <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Commit 6aea26ce5a4c ("mac80211: rework tx encapsulation offload API")
introduced a new checkpatch warning:
drivers/net/wireless/ath/ath11k/mac.c:4354: Alignment should match open parenthesis
Fix that.
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5-updates-2020-09-30
Updates and cleanups for mlx5 driver:
1) From Ariel, Dan Carpenter and Gostavo, Fixes to the previous
mlx5 Connection track series.
2) From Yevgeny, trivial cleanups for Software steering
3) From Hamdan, Support for Flow source hint in software steering and
E-Switch
4) From Parav and Sunil, Small and trivial E-Switch updates and
cleanups in preparation for mlx5 Sub-functions support
====================
Signed-off-by: David S. Miller <[email protected]>
|