Trying to keep track of free trbs in a ring by adding and subtracting
deltas each time a enqueue or dequeue is increased or moved has proven to
be buggy and complicated, especially over long periods of time.
Recently a bug in counting free trbs was fixed, now taking into account
cancelled URBs that were turned into no-ops, preventing free_trbs to
slowly wander off causing unnecessary ring expansion. See
commit fe82f16aaf ("xhci: Fix incorrect tracking of free space on
transfer rings")
Turns out its a lot easier to just calculate the numer of free TRB
based on ring size and the current enqueue and dequeue pointer values.
This is currently only needed for the command ring as multi segment
transfer rings already ensures there is enough room the ring during
the ring expansion check.
We could get rid of the ring->num_trbs_free entry completely, but as
the xhci DbC code also uses it we don't clean that up in this patch.
Reported-by: Miller Hunter <MillerH@hearthnhome.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217242
Tested-by: Miller Hunter <MillerH@hearthnhome.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Message-ID: <20230602144009.1225632-8-mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The amount of new TRBs needed is calculated incorrectly when expanding a
transfer ring.
The room_on_ring() helper will correctly report that the ring needs
expansion if the enqueue pointer is about to reach the dequeue segment.
If enqueue reaches the dequeue segment then there is no easy way
to expand the ring by adding new segments between enqueue and dequeue.
This leads to ring expansion even if num_trbs_free is larger than
num_trbs we are queueing.
As a result we try to store a negative number in a unsigned int, leading
to a huge percieved trb need, and doubling of ring size.
Rework and rename the room_on_ring() to a helper that checks if ring
needs expansion, and return number of new segments needed. Don't rely on
the tracked ring->num_trbs_free value as turns out it has been unreliable.
Use ring enqueue and dequeue positions to determine expansion need.
The unsigned int issue was first reported first Chao zeng, and a bit
later seen in a real world bug.
Reported-by: chao zeng <chao.zengup@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217242
Tested-by: Miller Hunter <MillerH@hearthnhome.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Message-ID: <20230602144009.1225632-7-mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The current function that both allocates and adds the interrupter isn't
optimal when using several interrupters. The array of interrupters need
to be protected with a lock while adding or removing interrupters.
If memory is allocated under the default xhci spinlock then GFP_KERNEL
can't be used.
There is no need to allocate the interrupter memory under the lock, so
split this code into separate unlocked allocate part, and a lock
protected add part.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Message-ID: <20230602144009.1225632-6-mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The XHCI_PLAT quirk was only needed to ensure non-PCI xHC host avoided
setting up MSI interrupts in generic xhci codepaths.
The MSI setup code is now moved to PCI specific xhci-pci.c file so
the quirk is no longer needed.
Remove setting the XHCI_PLAT quirk for HiSilocon SoC xHC, NVIDIA Tegra xHC,
MediaTek xHC, the generic xhci-plat driver, and the checks for XHCI_PLAT
in xhci-pci.c MSI setup code.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Message-ID: <20230602144009.1225632-5-mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Not all platforms drivers need to set up custom quirks during the xhci
generic setup. Allow them to pass NULL as the function pointer when
calling xhci_gen_setup()
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Message-ID: <20230602144009.1225632-4-mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Check for the cold attach (CAS) bit while checking for other usb3
roothub port changes during host resume.
The CAS bit is set if a USB 3 device is connected while the host is
suspended in such a way it can't perform proper link training and
progress the link to the enabled U0 state.
If the CAS bit set we want to resume the root hub, and reset and
enumerate the newly connected device.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Message-ID: <20230602144009.1225632-3-mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The KVM_S390_GET_CMMA_BITS ioctl may return incorrect values when userspace
specifies a start_gfn outside of memslots.
This can occur when a VM has multiple memslots with a hole in between:
+-----+----------+--------+--------+
| ... | Slot N-1 | <hole> | Slot N |
+-----+----------+--------+--------+
^ ^ ^ ^
| | | |
GFN A A+B | |
A+B+C |
A+B+C+D
When userspace specifies a GFN in [A+B, A+B+C), it would expect to get the
CMMA values of the first dirty page in Slot N. However, userspace may get a
start_gfn of A+B+C+D with a count of 0, hence completely skipping over any
dirty pages in slot N.
The error is in kvm_s390_next_dirty_cmma(), which assumes
gfn_to_memslot_approx() will return the memslot _below_ the specified GFN
when the specified GFN lies outside a memslot. In reality it may return
either the memslot below or above the specified GFN.
When a memslot above the specified GFN is returned this happens:
- ofs is calculated, but since the memslot's base_gfn is larger than the
specified cur_gfn, ofs will underflow to a huge number.
- ofs is passed to find_next_bit(). Since ofs will exceed the memslot's
number of pages, the number of pages in the memslot is returned,
completely skipping over all bits in the memslot userspace would be
interested in.
Fix this by resetting ofs to zero when a memslot _above_ cur_gfn is
returned (cur_gfn < ms->base_gfn).
Signed-off-by: Nico Boehr <nrb@linux.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Fixes: afdad61615 ("KVM: s390: Fix storage attributes migration with memory slots")
Message-Id: <20230324145424.293889-2-nrb@linux.ibm.com>
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Memory allocated for firmware pdev, vdev and beacon statistics
are not released during rmmod.
Fix it by calling ath11k_fw_stats_free() function before hardware
unregister.
While at it, avoid calling ath11k_fw_stats_free() while processing
the firmware stats received in the WMI event because the local list
is getting spliced and reinitialised and hence there are no elements
in the list after splicing.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Signed-off-by: P Praneesh <quic_ppranees@quicinc.com>
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230606091128.14202-1-quic_adisi@quicinc.com
Add a new debug level for CE so that we don't need to use AHB level in ce.c.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-16-kvalo@kernel.org
Cleanup HTC debug messages to follow the preferred style and try to make them
more readable. Also add a few more and remove unnecessary.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-15-kvalo@kernel.org
According to Documentation/core-api/printk-formats.rst %pK should not be used
with printk(), so switch back to using just %p. printk() will hash the address
so addresses are not leaked to user space.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-14-kvalo@kernel.org
Fix the debug message to follow the preferred style.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-13-kvalo@kernel.org
Somehow the character 'k' in ATH11k_DBG_HAL was in lower case. Change it to
upper case.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-12-kvalo@kernel.org
Merge the two debug messages into and fix them to follow the preferred style.
Also change the log level to ATH11K_DBG_DP_TX to match the filename.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-11-kvalo@kernel.org
For better readability fix PCI debug messages to follow the preferred style.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-10-kvalo@kernel.org
Add debug messages for every command and cleanup the existing ones to make them
all follow the same style. For better readability start every message with
"cmd". Print the debug message after a successful ath11k_wmi_cmd_send() call.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-9-kvalo@kernel.org
Also these functions don't follow the preferred style so fix those.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-8-kvalo@kernel.org
The error handling doesn't follow the preferred style so fix that.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-7-kvalo@kernel.org
Now that we have a default handler there's no need anymore to list every
unsupported event id anymore, so remove that to clean this up.
While at it remove the pointless todo comment and change the debug message to
follow the preferred style.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-6-kvalo@kernel.org
Add a debug message for every WMI event to make it easier track what's
happening in WMI. For better readability start every debug message with
"event".
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-5-kvalo@kernel.org
Now that the previous patch changed ath11k_dbg() to print the debug level
there's no need to have the level in the actual message anymore. So remove those.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-4-kvalo@kernel.org
To make it easier understand the context of a debug message print the debug
level before the actual message. An example:
[21867.231900] ath11k_pci 0000:06:00.0: wmi processed regulatory ext channel list
The tracepoint call is not modified, it's better to userspace print the debug
level if needed.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-3-kvalo@kernel.org
It's not used anywhere so can be easily removed.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609142440.24643-2-kvalo@kernel.org
On EDMA capable hardware, ath9k_txq_list_has_key() can enter infinite
loop if it is called while all txq_fifos have packets that use different
key that the one we are looking for. Fix it by exiting the loop if all
txq_fifos have been checked already.
Because this loop is called under spin_lock_bh() (see ath_txq_lock) it
causes the following rcu stall:
rcu: INFO: rcu_sched self-detected stall on CPU
ath10k_pci 0000:01:00.0: failed to read temperature -11
rcu: 1-....: (5254 ticks this GP) idle=189/1/0x4000000000000002 softirq=8442983/8442984 fqs=2579
(t=5257 jiffies g=17983297 q=334)
Task dump for CPU 1:
task:hostapd state:R running task stack: 0 pid: 297 ppid: 289 flags:0x0000000a
Call trace:
dump_backtrace+0x0/0x170
show_stack+0x1c/0x24
sched_show_task+0x140/0x170
dump_cpu_task+0x48/0x54
rcu_dump_cpu_stacks+0xf0/0x134
rcu_sched_clock_irq+0x8d8/0x9fc
update_process_times+0xa0/0xec
tick_sched_timer+0x5c/0xd0
__hrtimer_run_queues+0x154/0x320
hrtimer_interrupt+0x120/0x2f0
arch_timer_handler_virt+0x38/0x44
handle_percpu_devid_irq+0x9c/0x1e0
handle_domain_irq+0x64/0x90
gic_handle_irq+0x78/0xb0
call_on_irq_stack+0x28/0x38
do_interrupt_handler+0x54/0x5c
el1_interrupt+0x2c/0x4c
el1h_64_irq_handler+0x14/0x1c
el1h_64_irq+0x74/0x78
ath9k_txq_has_key+0x1bc/0x250 [ath9k]
ath9k_set_key+0x1cc/0x3dc [ath9k]
drv_set_key+0x78/0x170
ieee80211_key_replace+0x564/0x6cc
ieee80211_key_link+0x174/0x220
ieee80211_add_key+0x11c/0x300
nl80211_new_key+0x12c/0x330
genl_family_rcv_msg_doit+0xbc/0x11c
genl_rcv_msg+0xd8/0x1c4
netlink_rcv_skb+0x40/0x100
genl_rcv+0x3c/0x50
netlink_unicast+0x1ec/0x2c0
netlink_sendmsg+0x198/0x3c0
____sys_sendmsg+0x210/0x250
___sys_sendmsg+0x78/0xc4
__sys_sendmsg+0x4c/0x90
__arm64_sys_sendmsg+0x28/0x30
invoke_syscall.constprop.0+0x60/0x100
do_el0_svc+0x48/0xd0
el0_svc+0x14/0x50
el0t_64_sync_handler+0xa8/0xb0
el0t_64_sync+0x158/0x15c
This rcu stall is hard to reproduce as is, but changing ATH_TXFIFO_DEPTH
from 8 to 2 makes it reasonably easy to reproduce.
Fixes: ca2848022c ("ath9k: Postpone key cache entry deletion for TXQ frames reference it")
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Tested-by: Nicolas Escande <nico.escande@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20230609093744.1985-1-repk@triplefau.lt
Naveen Mamindlapalli says:
====================
RVU NIX AF driver updates
This patch series includes a few enhancements and other updates to the
RVU NIX AF driver.
The first patch adds devlink option to configure NPC MCAM high priority
zone entries reservation. This is useful when the requester needs more
high priority entries than default reserved entries.
The second patch adds support for RSS hash computation using L3 SRC or
DST only, or L4 SRC or DST only.
The third patch updates DWRR MTU configuration for CN10KB silicon. HW uses
the DWRR MTU to compute DWRR weight.
Patch 4 configures the LBK link in TL3_TL2 configuration only when switch
mode is enabled.
Patch 5 adds an option in the mailbox request to enable/disable DROP_RE bit
which drops packets with L2 errors when set.
Patch 6 updates SMQ flush mechanism to stop other child nodes from
enqueuing any packets while SMQ flush is active. Otherwise SMQ flush may
timeout.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When multiple transmit scheduler queues feed a TL1 transmit link, the
SMQ flush initiated on a low priority queue might get stuck when a high
priority queue fully subscribes the transmit link. This inturn effects
interface teardown. To avoid this, temporarily XOFF all TL1's other
immediate child transmit scheduler queues and also clear any rate limit
configuration on all the scheduler queues in SMQ(flush) hierarchy.
Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add option to toggle DROP_RE bit in rx cfg mbox. This helps in
modifying the config runtime as opposed to setting available via
nix_lf_alloc() mbox at NIX LF init time.
Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com>
Signed-off-by: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, all the TL3_TL2 nodes are being configured to enable
switch LBK channel 63 in them. Instead enable them only when switch
mode is enabled.
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The DWRR MTU config added for SDP and RPM/LBK links on CN10K
silicon is further extended on CK10KB silicon variant and made
it configurable. Now there are 4 DWRR MTU config to choose while
setting transmit scheduler's RR_WEIGHT.
Here we are reserving one config for each of RPM, SDP and LBK.
NIXX_AF_DWRR_MTUX(0) ---> RPM
NIXX_AF_DWRR_MTUX(1) ---> SDP
NIXX_AF_DWRR_MTUX(2) ---> LBK
PF/VF drivers can choose the DWRR_MTU to be used by setting
SMQX_CFG[pkt_link_type] to one of above. TLx_SCHEDULE[RR_WEIGHT]
is to be as configured 'quantum / 2^DWRR_MTUX[MTU]'. DWRR_MTU
of each link is exposed to PF/VF drivers via mailbox for
RR_WEIGHT calculation.
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add support to select L3 SRC or DST only, L4 SRC or DST only for RSS
calculation.
AF consumer may have requirement as we can select only SRC or DST data for
RSS calculation in L3, L4 layers. With this requirement there will be
following combinations, IPV[4,6]_SRC_ONLY, IPV[4,6]_DST_ONLY,
[TCP,UDP,SCTP]_SRC_ONLY, [TCP,UDP,SCTP]_DST_ONLY. So, instead of creating
a bit for each combination, we are using upper 4 bits (31:28) in the
flow_key_cfg to represent the SRC, DST selection. 31 => L3_SRC,
30 => L3_DST, 29 => L4_SRC, 28 => L4_DST. These won't be part of flow_cfg,
so that we don't need to change the existing ABI.
Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The NPC MCAM entries are currently divided into three priority zones
in AF driver: high, mid, and low. The high priority zone and low priority
zone take up 1/8th (each) of the available MCAM entries, and remaining
going to the mid priority zone.
The current allocation scheme may not meet certain requirements, such
as when a requester needs more high priority zone entries than are
reserved. This patch adds a devlink configurable option to increase the
number of high priority zone entries that can be allocated by requester.
The max number of entries that can be reserved for high priority usage
is 100% of available MCAM entries.
Usage:
1) Change high priority zone percentage to 75%:
devlink -p dev param set pci/0002:01:00.0 name npc_mcam_high_zone_percent \
value 75 cmode runtime
2) Read high priority zone percentage:
devlink -p dev param show pci/0002:01:00.0 name npc_mcam_high_zone_percent
The devlink set configuration is only permitted when no MCAM entries
are assigned, i.e., all MCAM entries are free, indicating that no PF/VF
driver is loaded. So user must unload/unbind PF/VF driver/devices before
modifying the high priority zone percentage.
Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge the mmc fixes for v6.4-rc[n] into the next branch, to allow them to
get tested together with the new mmc changes that are targeted for v6.5.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The test currently specifies "l2_miss" as "true" / "false", but the
version that eventually landed in iproute2 uses "1" / "0" [1]. Align the
test accordingly.
[1] https://lore.kernel.org/netdev/20230607153550.3829340-1-idosch@nvidia.com/
Fixes: 8c33266ae2 ("selftests: forwarding: Add layer 2 miss test cases")
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This flaw is detected by smatch:
drivers/net/wireless/realtek/rtw88/mac.c:748 __rtw_download_firmware()
warn: missing unwind goto?
Though most things of dlfw_fail have been done by
download_firmware_end_flow() and wlan_cpu_enable(), an exception is that
download_firmware_end_flow() clear BIT_MCUFWDL_EN bit conditionally.
So, make this change to clear the bit.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202306052310.OVhcUjZ3-lkp@intel.com/
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230607012741.10353-1-pkshih@realtek.com
Document the status quo and add myself and Peter as CPU hotplug
maintainers.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/87o7ll6ogo.ffs@tglx
Use the recently added of_property_read_reg() helper to get the
untranslated "reg" address value.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
The file is called spdif-in, but we abused it to show only sample rates
from various sources. Rectify it as far as possible (the FPGA doesn't
give us a lot of information).
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-10-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some info-querying code still used hw.resolution directly instead of
calling snd_timer_hw_resolution(), thus missing a possible
hw.c_resolution callback. This patch rectifies that.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is only a very partial fix - the frequency-dependent envelope & LFO
register values aren't adjusted.
But I'm not sure they were even correct at 48 kHz to start with, as most
of them are precalculated by common code which assumes an EMU8K-specific
44.1 kHz word clock, and it seems somewhat unlikely that the hardware's
register interpretation was adjusted to compensate for the different
word clock.
In any case I'm not going to spend time on fixing that, as this code is
unlikely to be actually used by anyone today.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that we know the actual word clock, we can:
- Put the resulting rate into the hardware info
- At 44.1 kHz word clock shift the rate for the pitch calculations,
which presume a 48 kHz word clock
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The value isn't used yet; the subsequent commits will do that.
This ignores the existence of rates above 48 kHz, which is fine, as the
hardware will just switch to the fallback clock source when fed with a
rate which is incompatible with the base clock multiplier, which
currently is always x1.
The sample rate display in /proc spdif-in is adjusted to reflect our
understanding of the input rates.
This is tested only with an 0404b card without sync card, so there is a
lot of room for improvement.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The actually available clock sources depend on the available audio input
ports and dedicated clock input ports.
This includes refactoring the code to be data-driven to remain
manageable.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
So far, we set the fallback as a side effect of setting the source. But
the fallback makes no sense at all when an internal clock is selected.
Defaulting to 48k for S/PDIF & ADAT makes sense, but as that is the
global default and we're not changing it automatically any more, it's
just fine to leave it entirely to the explicit setting.
This changes the name of the pre-existing control to something more
appropriate (regardless of the split), so users will need to adjust
their mixer settings.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As the updated MIDI 2.0 spec has been published freshly, this is a
catch up to add the support for new specs, especially UMP v1.1
features, on Linux kernel.
The new UMP v1.1 introduced the concept of Function Blocks (FB), which
is a kind of superset of USB MIDI 2.0 Group Terminal Blocks (GTB).
The patch set adds the support for FB as the primary information
source while keeping the parse of GTB as fallback. Also UMP v1.1
supports the groupless messages, the protocol switch, static FBs, and
other new fundamental features, and those are supported as well.
Link: https://www.midi.org/midi-articles/details-about-midi-2-0-midi-ci-profiles-and-property-exchange
Link: https://lore.kernel.org/r/20230612081054.17200-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The kernel already has a helper to print a hexdump of a small
buffer via pointer extension. Use that instead of open coded
variant.
In long term it helps to kill pr_cont() or at least narrow down
its use.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230612212336.4961-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
David Howells says:
====================
splice, net: Some miscellaneous MSG_SPLICE_PAGES changes
Now that the splice_to_socket() has been rewritten so that nothing now uses
the ->sendpage() file op[1], some further changes can be made, so here are
some miscellaneous changes that can now be done.
(1) Remove the ->sendpage() file op.
(2) Remove hash_sendpage*() from AF_ALG.
(3) Make sunrpc send multiple pages in single sendmsg() call rather than
calling sendpage() in TCP (or maybe TLS).
(4) Make tcp_bpf_sendpage() a wrapper around tcp_bpf_sendmsg().
(5) Make AF_KCM use sendmsg() when calling down to TCP and then make it
send entire fragment lists in single sendmsg calls.
Link: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=fd5f4d7da29218485153fd8b4c08da7fc130c79f [1]
====================
Link: https://lore.kernel.org/r/20230609100221.2620633-1-dhowells@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Rewrite the AF_KCM transmission loop to send all the fragments in a single
skb or frag_list-skb in one sendmsg() with MSG_SPLICE_PAGES set. The list
of fragments in each skb is conveniently a bio_vec[] that can just be
attached to a BVEC iter.
Note: I'm working out the size of each fragment-skb by adding up bv_len for
all the bio_vecs in skb->frags[] - but surely this information is recorded
somewhere? For the skbs in head->frag_list, this is equal to
skb->data_len, but not for the head. head->data_len includes all the tail
frags too.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Tom Herbert <tom@herbertland.com>
cc: Tom Herbert <tom@quantonium.net>
cc: Jens Axboe <axboe@kernel.dk>
cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
