- 07 Jul, 2020 8 commits
-
-
Pierre-Louis Bossart authored
Fix W=1 warnings. The code certainly predates .rst syntax, adjust as needed. Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200702193604.169059-5-pierre-louis.bossart@linux.intel.comSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Pierre-Louis Bossart authored
Fix W=1 warnings by removing 2 unnecessary initializations and removing a variable that's not used. sound/pci/asihpi/asihpi.c: In function ‘snd_asihpi_tuner_band_get’: sound/pci/asihpi/asihpi.c:1907:6: warning: variable ‘num_bands’ set but not used [-Wunused-but-set-variable] 1907 | u32 num_bands = 0; | ^~~~~~~~~ sound/pci/asihpi/asihpi.c: In function ‘snd_asihpi_tuner_band_put’: sound/pci/asihpi/asihpi.c:1934:6: warning: variable ‘num_bands’ set but not used [-Wunused-but-set-variable] 1934 | u32 num_bands = 0; | ^~~~~~~~~ sound/pci/asihpi/asihpi.c: In function ‘snd_asihpi_mux_info’: sound/pci/asihpi/asihpi.c:2164:6: warning: variable ‘err’ set but not used [-Wunused-but-set-variable] 2164 | int err; | ^~~ Signed-off-by: -
Pierre-Louis Bossart authored
Fix W=1 warning by noting variable as __always_unused. sound/isa/gus/gus_uart.c: In function ‘snd_gf1_interrupt_midi_in’: sound/isa/gus/gus_uart.c:16:22: warning: variable ‘data’ set but not used [-Wunused-but-set-variable] 16 | unsigned char stat, data, byte; Signed-off-by:
-
Pierre-Louis Bossart authored
Fix W=1 warnings by adding prototypes to header file sound/isa/gus/gus_timer.c:141:6: warning: no previous prototype for ‘snd_gf1_timers_init’ [-Wmissing-prototypes] 141 | void snd_gf1_timers_init(struct snd_gus_card * gus) | ^~~~~~~~~~~~~~~~~~~ sound/isa/gus/gus_timer.c:177:6: warning: no previous prototype for ‘snd_gf1_timers_done’ [-Wmissing-prototypes] 177 | void snd_gf1_timers_done(struct snd_gus_card * gus) | ^~~~~~~~~~~~~~~~~~~ Signed-off-by: -
Vinod Koul authored
Also documented the galpess transitions. Please note that these are not really stream states, but show how the stream steps in gapless mode Signed-off-by:
Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200629134737.105993-3-vkoul@kernel.orgSigned-off-by:
-
Vinod Koul authored
So we had some discussions of the stream states, so I thought it is a good idea to document the state transitions, so add it documentation Reviewed-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Randy Dunlap authored
Fix kconfig warnings and lots of subsequent build errors by adding yet another ugly select statement: WARNING: unmet direct dependencies detected for LEDS_CLASS Depends on [n]: NEW_LEDS [=n] Selected by [y]: - SND_HDA_GENERIC [=y] && SOUND [=y] && !UML && SND [=y] && SND_HDA [=y] && SND_HDA_GENERIC_LEDS [=y] WARNING: unmet direct dependencies detected for LEDS_TRIGGERS Depends on [n]: NEW_LEDS [=n] && LEDS_CLASS [=y] Selected by [y]: - SND_HDA_GENERIC [=y] && SOUND [=y] && !UML && SND [=y] && SND_HDA [=y] && SND_HDA_GENERIC_LEDS [=y] Selected by [m]: - MAC80211_LEDS [=y] && NET [=y] && WIRELESS [=y] && MAC80211 [=m] && LEDS_CLASS [=y] - IWLWIFI_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_INTEL [=y] && IWLWIFI [=m] && (LEDS_CLASS [=y]=y || LEDS_CLASS [=y]=IWLWIFI [=m]) && (IWLMVM [=m] || IWLDVM [=m]) WARNING: unmet direct dependencies detected for LEDS_TRIGGER_AUDIO Depends on [n]: NEW_LEDS [=n] && LEDS_TRIGGERS [=y] Selected by [y]: - SND_HDA_GENERIC [=y] && SOUND [=y] && !UML && SND [=y] && SND_HDA [=y] && SND_HDA_GENERIC_LEDS [=y] Fixes: 7cdf8c49 ("ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/01233744-9625-38b3-0342-1b37250dbc72@infradead.orgSigned-off-by:
-
Pierre-Louis Bossart authored
Fix W=1 warning. The kernel doc uses the hwparams type instead of the argument name. Signed-off-by:
-
- 30 Jun, 2020 1 commit
-
-
Alexander Tsoy authored
Fix the following typos in comments and in the code: - KHz -> kHz - procssed -> processed Signed-off-by:
Alexander Tsoy <alexander@tsoy.me> Link: https://lore.kernel.org/r/20200629032607.255419-1-alexander@tsoy.meSigned-off-by:
-
- 25 Jun, 2020 1 commit
-
-
Takashi Iwai authored
The module argument passed to snd_card_new() must be a valid non-NULL pointer when the module support is enabled. Since ASoC driver passes the argument from each snd_soc_card definition, one may forget to set the owner field and lead to a NULL module easily. For catching such an overlook, add a WARN_ON() in snd_card_new(). Also, put the card->module assignment in the ifdef block for a very minor optimization. Link: https://lore.kernel.org/r/20200624160300.21703-1-tiwai@suse.deSigned-off-by:
-
- 19 Jun, 2020 2 commits
-
-
Takashi Iwai authored
This is a patch set inspired by the recent patch Kai-Heng posted about the HD-audio mic-mute LED control. Currently HD-audio driver deals with the mute and mic-mute LED in several different ways: primarily with the direct callback of vmaster hook and capture sync hook, while another with the LED class device binding. The latter has been used for binding with the platform device LEDs like Thinkpad, Dell, Huawei. And, yet, recently we added our own LED classdev for the mic-mute LED on some HP systems although they are controlled directly with the callback; it's exposed, however, for the DMIC that is governed by a different ASoC driver. This patch set is an attempt to sort out and make them consistent: namely, * All LEDs are now controlled via LED class device * The generic driver provides helper functions to easily build up the LED class dev and the relevant mixer controls * Conversion of the existing framework and clean ups The patches are lightly tested in my side with a couple of machines and also through hda-emu tests. Some devices receive new kcontrols for the mute LED behavior (that have been missing so far), but anything else look good though my tests. Link: https://lore.kernel.org/r/20200618110842.27238-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
In the end we already enabled the sync-write mode for most of HD-audio controllers including Intel, and it's no big merit to keep the async write mode for the rest. Let's make it as default and drop the superfluous AZX_DCAPS_SYNC_WRITE bit flag. Also, avoid to set the allow_bus_reset flag, which is a quite unstable and hackish behavior that was needed only for some early platforms (decades ago). The straight fallback to the single cmd mode is more robust. Link: https://lore.kernel.org/r/20200618144051.7415-1-tiwai@suse.deSigned-off-by:
-
- 18 Jun, 2020 13 commits
-
-
Takashi Iwai authored
Set LED_CORE_SUSPENDRESUME to LED cdev flags, so that the LED core would store and restore the LED status at suspend/resume. In theory, the codec driver should be responsible for all LED bits, but this might be safer and cover the overlooked cases. Tested-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20200618110842.27238-14-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Both mute and mic-mute LED callbacks do almost similar tasks with just different bits. Factor out the common code and use them from the callbacks for simplification. This ended up with covering the forgotten stuff, too; e.g. VREF LED handling required the temporary power up/down that was missing for the mute LED, or some forgotten polarity checks are added. Tested-by:
-
Takashi Iwai authored
Convert the mute LED handling in Sigmatel/IDT codec to the new vmaster mute helper. A point to be cautiously handled is that the value passed to the callback is inverted; the vmaster passes "enabled" (0 = mute), while LED classdev passes "brightness" (1 = mute). A positive side-effect by this change is that the driver gets also the enum controls for the mute behavior like other drivers already had. Tested-by:
-
Takashi Iwai authored
Convert the mute LED handling in Conexant codec to the new vmaster mute helper. A point to be cautiously handled is that the value passed to the callback is inverted; the vmaster passes "enabled" (0 = mute), while LED classdev passes "brightness" (1 = mute). Also the assignment of the default vmaster hook is moved at a later point after the mute hook is set up. This assures no nested hook. Finally, since we enable the mute-LED kcontrols always in the helper side, the extra vmaster_mute_enum flag set up is dropped. Tested-by:
-
Takashi Iwai authored
Convert the mute LED handling in Realtek codec to the new vmaster mute helper. A point to be cautiously handled is that the value passed to the callback is inverted; the vmaster passes "enabled" (0 = mute), while LED classdev passes "brightness" (1 = mute). The code in Thinkpad helper is also converted. In that case, just call the new function and remove the open-code. Tested-by:
-
Takashi Iwai authored
Like mic-mute LED handling, add a new helper to deal with the master mute LED with LED classdev. Unlike the mic-mute case, the playback master mute is hooked on vmaster, and we suppose no nested hooks allowed there. The classdev creation code is factored out to a common function that is called from both mute and mic-mute LED helpers. Tested-by:
-
Takashi Iwai authored
Now all users of the old snd_hda_gen_add_micmute_led() have been converted to the new LED-classdev variant, and we can make it local, and remove the unused hda_gen_spec.micmute_led.update callback field. Tested-by:
-
Takashi Iwai authored
The fixup function is no longer used. Let's drop. Tested-by:
-
Takashi Iwai authored
This patch converts the remaining user of snd_hda_gen_add_micmute_led() in IDT/Sigmatel codec driver into the new snd_hda_gen_add_micmute_led_cdev(). Tested-by:
-
Takashi Iwai authored
This patch converts the remaining user of snd_hda_gen_add_micmute_led() in Conexant codec driver into the new snd_hda_gen_add_micmute_led_cdev(). Tested-by:
-
Takashi Iwai authored
This patch converts the remaining user of snd_hda_gen_add_micmute_led() in Realtek codec driver into the new snd_hda_gen_add_micmute_led_cdev(). The Thinkpad helper code is updated accordingly, too. Also, the usage of snd_hda_gen_fixup_micmute_led() is replaced with either the local alc_fixup_micmute_led() or the explicit call of snd_hda_gen_add_micmute_led_cdev() with NULL callback. Tested-by:
-
Takashi Iwai authored
A new helper, snd_hda_gen_add_micmute_led_cdev(), is introduced here for creating a LED classdev and setting up the hook to the capture control for controlling the mic-mute LED to follow the capture switch change. This will replace the existing users of snd_hda_gen_add_micmute_led() in later patches. Also, introduce a new kconfig CONFIG_SND_HDA_GENERIC_LEDS, to indicate the usage of mute / mic-mute LED helpers. It's selected by the codec drivers (Realtek, Conexant and Sigmatel), while it selects the necessary LED class dependencies. Tested-by:
-
Takashi Iwai authored
Instead of adding a special hook to trigger the mic-mute LED device, call it always from the common callback function. It won't hurt even if no corresponding led cdev is present. This is basically a preliminary change for the later patches to convert the all mic-mute LED handling to LED class cdev. Tested-by:
-
- 17 Jun, 2020 1 commit
-
-
Takashi Iwai authored
Pull the fix for potential PCM SG-buffer problems. Link: https://lore.kernel.org/r/20200615160045.2703-1-tiwai@suse.deSigned-off-by:
-
- 15 Jun, 2020 8 commits
-
-
Takashi Iwai authored
The DMA-coherent SG-buffer is tricky to use, as it does need the mapping. It used to work stably on x86 over years (and that's why we had enabled SG-buffer on solely x86) with the default mmap handler and vmap(), but our luck seems no forever success. The chance of breakage is high when the special DMA handling is introduced in the arch side. In this patch, we change the buffer allocation to use the SG-buffer only when the device in question is with the direct DMA. It's a bit hackish, but it's currently the only condition that may work (more or less) reliably with the default mmap and vmap() for mapping the pages that are deduced via virt_to_page(). In theory, we can apply the similar hack in the sound/core memory allocation helper, too; but it's used by SOF for allocating SG pages without re-mapping via vmap() or mmap, and it's fine to use it in that way, so let's keep it and adds the workaround in PCM side. Link: https://lore.kernel.org/r/20200615160045.2703-5-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
We have a few helper functions for making the access to the buffer address easier on SG-buffer. Those are specific to the buffer that is allocated with SG-buffer type, and it makes hard to use both SG and non-SG buffers in the same code. This patch adds a few simple checks and lets the helpers to deal with both SG- and continuous buffers gracefully. It's a preliminary step for the upcoming patch that mimics the buffer type on the fly. Link: https://lore.kernel.org/r/20200615160045.2703-4-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Some fields in snd_dma_buffer aren't touched in snd_dma_alloc_pages() and might be left uninitialized. Let's clear all fields properly, so that we can use a NULL check (e.g. dmab->private_data) as conditional in a later patch. Link: https://lore.kernel.org/r/20200615160045.2703-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
We avoided the explicit use of dma_mmap_coherent() on x86 because of a spurious warning in x86 APT code in the past. However, this blindly assumes that the pages allocated via dma_alloc_coherent() on x86 are the ones convertible via virt_to_page() (that is used in the default mmap handler), and it's no longer true; with the indirect DMA ops, this can be handled differently. The only certain way for doing mmap such pages is the dma_mmap_coherent(), and the warning seems already gone in the recent code, so let's use it consistently. Link: https://lore.kernel.org/r/20200615160045.2703-2-tiwai@suse.deSigned-off-by:
-
Takashi Sakamoto authored
It costs expensive to change clock configuration for models of protocol version 3. In current implementation, speculative strategy is used to finish the operation; just waiting for 4 seconds. As long as I investigate, when accepting and changing clock status actually, the device sends notification with mask. This commit uses wise way to wait for the notification after changing sampling clock rate during 4 seconds. Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20200614141221.53527-1-o-takashi@sakamocchi.jpSigned-off-by:
-
Takashi Iwai authored
Signed-off-by: -
Christopher Swenson authored
Like the Line6 devices, the Rode Rodecaster Pro does not support UAC2_CS_RANGE and only supports a sample rate of 48 kHz. Tested against a Rode Rodecaster Pro. Tested-by:
Christopher Swenson <swenson@swenson.io> Signed-off-by:
-
Yick W. Tse authored
fix error "clock source 41 is not valid, cannot use" [] New USB device found, idVendor=154e, idProduct=1002, bcdDevice= 1.00 [] New USB device strings: Mfr=1, Product=2, SerialNumber=0 [] Product: DCD-1500RE [] Manufacturer: D & M Holdings Inc. [] [] clock source 41 is not valid, cannot use [] usbcore: registered new interface driver snd-usb-audio Signed-off-by:
Yick W. Tse <y_w_tse@yahoo.com.hk> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1373857985.210365.1592048406997@mail.yahoo.comSigned-off-by:
-
- 14 Jun, 2020 4 commits
-
-
Linus Torvalds authored
-
git://github.com/micah-morton/linuxLinus Torvalds authored
Pull SafeSetID update from Micah Morton: "Add additional LSM hooks for SafeSetID SafeSetID is capable of making allow/deny decisions for set*uid calls on a system, and we want to add similar functionality for set*gid calls. The work to do that is not yet complete, so probably won't make it in for v5.8, but we are looking to get this simple patch in for v5.8 since we have it ready. We are planning on the rest of the work for extending the SafeSetID LSM being merged during the v5.9 merge window" * tag 'LSM-add-setgid-hook-5.8-author-fix' of git://github.com/micah-morton/linux: security: Add LSM hooks to set*gid syscalls
-
Thomas Cedeno authored
The SafeSetID LSM uses the security_task_fix_setuid hook to filter set*uid() syscalls according to its configured security policy. In preparation for adding analagous support in the LSM for set*gid() syscalls, we add the requisite hook here. Tested by putting print statements in the security_task_fix_setgid hook and seeing them get hit during kernel boot. Signed-off-by:
Thomas Cedeno <thomascedeno@google.com> Signed-off-by:
Micah Morton <mortonm@chromium.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linuxLinus Torvalds authored
Pull btrfs updates from David Sterba: "This reverts the direct io port to iomap infrastructure of btrfs merged in the first pull request. We found problems in invalidate page that don't seem to be fixable as regressions or without changing iomap code that would not affect other filesystems. There are four reverts in total, but three of them are followup cleanups needed to revert a43a67a2 cleanly. The result is the buffer head based implementation of direct io. Reverts are not great, but under current circumstances I don't see better options" * tag 'for-5.8-part2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: Revert "btrfs: switch to iomap_dio_rw() for dio" Revert "fs: remove dio_end_io()" Revert "btrfs: remove BTRFS_INODE_READDIO_NEED_LOCK" Revert "btrfs: split btrfs_direct_IO to read and write part"
-
- 13 Jun, 2020 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Fix cfg80211 deadlock, from Johannes Berg. 2) RXRPC fails to send norigications, from David Howells. 3) MPTCP RM_ADDR parsing has an off by one pointer error, fix from Geliang Tang. 4) Fix crash when using MSG_PEEK with sockmap, from Anny Hu. 5) The ucc_geth driver needs __netdev_watchdog_up exported, from Valentin Longchamp. 6) Fix hashtable memory leak in dccp, from Wang Hai. 7) Fix how nexthops are marked as FDB nexthops, from David Ahern. 8) Fix mptcp races between shutdown and recvmsg, from Paolo Abeni. 9) Fix crashes in tipc_disc_rcv(), from Tuong Lien. 10) Fix link speed reporting in iavf driver, from Brett Creeley. 11) When a channel is used for XSK and then reused again later for XSK, we forget to clear out the relevant data structures in mlx5 which causes all kinds of problems. Fix from Maxim Mikityanskiy. 12) Fix memory leak in genetlink, from Cong Wang. 13) Disallow sockmap attachments to UDP sockets, it simply won't work. From Lorenz Bauer. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (83 commits) net: ethernet: ti: ale: fix allmulti for nu type ale net: ethernet: ti: am65-cpsw-nuss: fix ale parameters init net: atm: Remove the error message according to the atomic context bpf: Undo internal BPF_PROBE_MEM in BPF insns dump libbpf: Support pre-initializing .bss global variables tools/bpftool: Fix skeleton codegen bpf: Fix memlock accounting for sock_hash bpf: sockmap: Don't attach programs to UDP sockets bpf: tcp: Recv() should return 0 when the peer socket is closed ibmvnic: Flush existing work items before device removal genetlink: clean up family attributes allocations net: ipa: header pad field only valid for AP->modem endpoint net: ipa: program upper nibbles of sequencer type net: ipa: fix modem LAN RX endpoint id net: ipa: program metadata mask differently ionic: add pcie_print_link_status rxrpc: Fix race between incoming ACK parser and retransmitter net/mlx5: E-Switch, Fix some error pointer dereferences net/mlx5: Don't fail driver on failure to create debugfs net/mlx5e: CT: Fix ipv6 nat header rewrite actions ... -
David Sterba authored
This reverts commit a43a67a2. This patch reverts the main part of switching direct io implementation to iomap infrastructure. There's a problem in invalidate page that couldn't be solved as regression in this development cycle. The problem occurs when buffered and direct io are mixed, and the ranges overlap. Although this is not recommended, filesystems implement measures or fallbacks to make it somehow work. In this case, fallback to buffered IO would be an option for btrfs (this already happens when direct io is done on compressed data), but the change would be needed in the iomap code, bringing new semantics to other filesystems. Another problem arises when again the buffered and direct ios are mixed, invalidation fails, then -EIO is set on the mapping and fsync will fail, though there's no real error. There have been discussions how to fix that, but revert seems to be the least intrusive option. Link: https://lore.kernel.org/linux-btrfs/20200528192103.xm45qoxqmkw7i5yl@fiona/Signed-off-by:
David Sterba <dsterba@suse.com>
-
