OSDN Git Service
Takashi Iwai [Sat, 16 May 2020 06:28:53 +0000 (08:28 +0200)]
ALSA: hda: Drop unused snd_hda_queue_unsol_event()
The inline function is nowhere used. Drop it.
Link: https://lore.kernel.org/r/20200516062854.22141-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Sat, 16 May 2020 06:25:56 +0000 (08:25 +0200)]
ALSA: hda: Fix potential race in unsol event handler
The unsol event handling code has a loop retrieving the read/write
indices and the arrays without locking while the append to the array
may happen concurrently. This may lead to some inconsistency.
Although there hasn't been any proof of this bad results, it's still
safer to protect the racy accesses.
This patch adds the spinlock protection around the unsol handling loop
for addressing it. Here we take bus->reg_lock as the writer side
snd_hdac_bus_queue_event() is also protected by that lock.
Link: https://lore.kernel.org/r/20200516062556.30951-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Erwin Burema [Sun, 10 May 2020 18:29:11 +0000 (20:29 +0200)]
ALSA: usb-audio: Add duplex sound support for USB devices using implicit feedback
For USB sound devices using implicit feedback the endpoint used for
this feedback should be able to be opened twice, once for required
feedback and second time for audio data. This way these devices can be
put in duplex audio mode. Since this only works if the settings of the
endpoint don't change a check is included for this.
This fixes bug 207023 ("MOTU M2 regression on duplex audio") and
should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device
will not operate full-duplex")
Fixes:
c249177944b6 ("ALSA: usb-audio: add implicit fb quirk for MOTU M Series")
Signed-off-by: Erwin Burema <e.burema@gmail.com>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207023
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=103751
Link: https://lore.kernel.org/r/2410739.SCZni40SNb@alpha-wolf
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Thomas Ebeling [Fri, 15 May 2020 11:46:05 +0000 (13:46 +0200)]
ALSA: usb-audio: fixing upper volume limit for RME Babyface Pro routing crosspoints
In my initial patch, these were set too low.
Fixes:
3e8f3bd04716 ("ALSA: usb-audio: RME Babyface Pro mixer patch")
Signed-off-by: Thomas Ebeling <penguins@bollie.de>
Link: https://lore.kernel.org/r/20200515114556.vtspnonzvp4xp44m@bollie.ca9.eu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Mon, 11 May 2020 02:25:40 +0000 (11:25 +0900)]
ALSA: firewire-motu: fulfill missing entries in Kconfig
This is trivial commit but fulfill missing entries in Kconfig for devices
supported by ALSA firewire-motu driver.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200511022540.161363-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Sun, 10 May 2020 07:43:01 +0000 (16:43 +0900)]
ALSA: fireface: add support for RME Fireface UFX (untested)
Fireface UFX was shipped by RME GmbH in 2010, and now discontinued.
Although this model has some enhanced feature which Fireface 802
doesn't have (e.g. on-board USB mass storage device class, configuration
interface with color display), the functionality relevant to
packet communication on IEEE 1394 bus seems to be the same as
Fireface 802 (e.g. available number of channels for PCM frame in
each sampling transfer frequency).
With the assumption, this commit adds support for Fireface UFX. In ALSA
fireface driver, these two models are handled as the same one.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Sun, 10 May 2020 07:43:00 +0000 (16:43 +0900)]
ALSA: fireface: add support for RME FireFace 802
Fireface 802 was shipped by RME GmbH in 2014. This model supports later
protocol for management of isochronous communication and synchronization
of sampling transmission frequency.
This model consists of below ICs:
* TI TSB41AB2
* Xilinx Spartan-6 FPGA XC6SLX16
* TI TMS320 C6747
* SMSC USB3250
Especially, this model just supports IEEE 1394a, against its name which
evokes Fireface 800.
This commit adds support for Fireface 802 (tested). Userspace applications
can transfer PCM frames and MIDI messages via ALSA PCM/Rawmidi interface.
I note that 4 channels for ADAt1 and ADAT2 are disabled at higher sampling
transfer frequency since isochronous resources reservation fails due to
bandwidth limitation of IEEE 1394a.
The value read from LATTER_SYNC_STATUS register is slightly different
from the one of Fireface UCX. The higher 4 bits and lower 4 bits are
swapped within the same byte.
Without any assist of userspace application, transmitted MIDI messages
from the device are not going to be processed. For detail, please refer
to my comment in code of latter protocol.
$ python crpp < /sys/bus/firewire/devices/fw1/config_rom
ROM header and bus information block
-----------------------------------------------------------------
400
0404ffff bus_info_length 4, crc_length 4, crc 65535 (should be 26805)
404
31333934 bus_name "1394"
408
20008000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 0, max_rec 8 (512)
40c
000a3504 company_id 000a35 |
410
38077423 device_id
0438077423 | EUI-64
000a350438077423
root directory
-----------------------------------------------------------------
414
0005ffff directory_length 5, crc 65535 (should be 9514)
418
0c0083c0 node capabilities per IEEE 1394
41c
03000a35 vendor
420
8100000b --> descriptor leaf at 44c
424
8d000007 --> eui-64 leaf at 440
428
d1000001 --> unit directory at 42c
unit directory at 42c
-----------------------------------------------------------------
42c
0004ffff directory_length 4, crc 65535 (should be 45134)
430
12000a35 specifier id
434
13000005 version
438
17101800 model
43c
81000008 --> descriptor leaf at 45c
eui-64 leaf at 440
-----------------------------------------------------------------
440
0002ffff leaf_length 2, crc 65535 (should be 60131)
444
000a3504 company_id 000a35 |
448
38077423 device_id
0438077423 | EUI-64
000a350438077423
descriptor leaf at 44c
-----------------------------------------------------------------
44c
0003ffff leaf_length 3, crc 65535 (should be 469)
450
00000000 textual descriptor
454
00000000 minimal ASCII
458
524d4521 "RME!"
descriptor leaf at 45c
-----------------------------------------------------------------
45c
0005ffff leaf_length 5, crc 65535 (should be 10561)
460
00000000 textual descriptor
464
00000000 minimal ASCII
468
46697265 "Fire"
46c
66616365 "face"
470
20383032 " 802"
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Sun, 10 May 2020 07:42:59 +0000 (16:42 +0900)]
ALSA: fireface: code refactoring to decide name of sound card
This commit uses enumeration constants as index of table for the
list of name of sound card.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Sun, 10 May 2020 07:42:58 +0000 (16:42 +0900)]
ALSA: fireface: code refactoring to add enumeration constants for model identification
In RME fireface series, version field of unit directory in configuration
ROM is used to distinguish each model. The value of field is known and
it's better to use enumeration constants for code representation.
This commit adds enumeration constants for model identification.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Sun, 10 May 2020 07:42:57 +0000 (16:42 +0900)]
ALSA: fireface: start IR context immediately
In the latter models of RME Fireface series, device start to transfer
packets several dozens of milliseconds. On the other hand, ALSA fireface
driver starts IR context 2 milliseconds after the start. This results
in loss to handle incoming packets on the context.
This commit changes to start IR context immediately instead of
postponement. For Fireface 800, this affects nothing because the device
transfer packets 100 milliseconds or so after the start and this is
within wait timeout.
Cc: <stable@vger.kernel.org>
Fixes:
acfedcbe1ce4 ("ALSA: firewire-lib: postpone to start IR context")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Sun, 10 May 2020 07:42:56 +0000 (16:42 +0900)]
ALSA: fireface: fix configuration error for nominal sampling transfer frequency
128000 and 192000 are congruence modulo 32000, thus it's wrong to
distinguish them as multiple of 32000 and 48000 by modulo 32000 at
first.
Additionally, used condition statement to detect quadruple speed can
cause missing bit flag.
Furthermore, counter to ensure the configuration is wrong and it
causes false positive.
This commit fixes the above three bugs.
Cc: <stable@vger.kernel.org>
Fixes:
60aec494b389 ("ALSA: fireface: support allocate_resources operation in latter protocol")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200510074301.116224-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Fri, 8 May 2020 04:36:35 +0000 (13:36 +0900)]
ALSA: firewire-lib: use sequence of syt offset and data block on pool in AMDTP domain
In previous commit, the sequence of syt offset and the number of data
blocks per packet is calculated for pool in AMDTP domain structure in
advance of processing outgoing packets.
This commit uses the sequence for outgoing packet processing to obsolete
per-stream processing of the sequence.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-11-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Fri, 8 May 2020 04:36:34 +0000 (13:36 +0900)]
ALSA: firewire-lib: pool ideal sequence of syt offset and data block
In current implementation, sequence of syt offset and the number of data
blocks is generated when packets for outgoing stream are going to be
queued.
This commit generates and pools the sequence independently of the
processing of outgoing packets for future extension.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-10-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Fri, 8 May 2020 04:36:33 +0000 (13:36 +0900)]
ALSA: firewire-lib: add cache for packet sequence to AMDTP domain structure
For future extension, storage is required to store packet sequence in
incoming AMDTP stream to recover media clock for outgoing AMDTP stream.
This commit adds the storage to AMDTP domain for this purpose. The
packet sequence is represented by 'struct seq_desc' which has two
members; syt_offset and the number of data blocks. The size of storage
is decided according to the size of packet queue.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Fri, 8 May 2020 04:36:32 +0000 (13:36 +0900)]
ALSA: firewire-lib: code refactoring for data block calculation
When calculating the number of data blocks per packet, some states are
stored in AMDTP stream structure. This is inconvenient when reuse the
calculation from non-stream structure.
This commit applies refactoring to helper function for the calculation
so that the function doesn't touch AMDTP stream structure.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Fri, 8 May 2020 04:36:31 +0000 (13:36 +0900)]
ALSA: firewire-lib: code refactoring for syt offset calculation
When calculating syt offset, some states are stored in AMDTP stream
structure. This is inconvenient when reuse the calculation from
non-stream structure.
This commit applies refactoring to helper function for the calculation
so that the function doesn't touch AMDTP stream structure.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Fri, 8 May 2020 04:36:30 +0000 (13:36 +0900)]
ALSA: firewire-lib: code refactoring for syt computation
In current implementation for outgoing AMDTP packet, the value of syt
field in CIP header is computed when calculating syt offset. For
future extension, it's convenient to split the computation and
calculation.
This commit splits them.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Fri, 8 May 2020 04:36:29 +0000 (13:36 +0900)]
ALSA: firewire-lib: code refactoring for parameters of packet queue and IRQ timing
Although the parameter for packet queue and IRQ timing is calculated when
AMDTP stream starts, the calculated parameters are the same between
streams in AMDTP domain.
This commit moves the calculation and decide the parameters when AMDTP
domain starts.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Fri, 8 May 2020 04:36:28 +0000 (13:36 +0900)]
ALSA: firewire-lib: add reference to domain structure from stream structure
In current implementation, AMDTP domain structure and AMDTP stream
structure has one way of reference from the former to the latter. For
future extension, bidirectional reference is needed.
This commit adds a member into stream structure to refer to domain
structure to which the stream belongs.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Fri, 8 May 2020 04:36:27 +0000 (13:36 +0900)]
ALSA: firewire-lib: use macro for maximum value of second in 1394 OHCI isoc descriptor
In descriptor of isochronous context in 1394 OHCI, the field of second
has 3 bit, thus the maximum value is 8. The value is used for correct
cycle calculation.
This commit replaces hard-coded value with macro to obsolete magic
number.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Sakamoto [Fri, 8 May 2020 04:36:26 +0000 (13:36 +0900)]
ALSA: firewire-lib: fix invalid assignment to union data for directional parameter
Although the value of FDF is used just for outgoing stream, the assignment
to union member is done for both directions of stream. At present this
causes no issue because the value of same position is reassigned later for
opposite stream. However, it's better to add if statement.
Fixes:
d3d10a4a1b19 ("ALSA: firewire-lib: use union for directional parameters")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Gustavo A. R. Silva [Thu, 7 May 2020 18:52:45 +0000 (13:52 -0500)]
ALSA: fireworks: Replace zero-length array with flexible-array
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200507185245.GA14270@embeddedor
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Gustavo A. R. Silva [Thu, 7 May 2020 19:22:23 +0000 (14:22 -0500)]
ALSA: Replace zero-length array with flexible-array
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200507192223.GA16335@embeddedor
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cezary Rojewski [Wed, 6 May 2020 20:39:51 +0000 (22:39 +0200)]
ALSA: hda: Allow SST driver on SKL and KBL platforms with DMIC
Update intel-dspcfg with FLAG_SST_ONLY_IF_DMIC option and use it for
Skylake and Kabylake platforms when DMIC is present.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200506203951.6369-1-cezary.rojewski@intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Samuel Zou [Thu, 7 May 2020 06:48:55 +0000 (14:48 +0800)]
ALSA: portman2x4: Use bitwise instead of arithmetic operator for flags
Fix the following coccinelle warning:
sound/drivers/portman2x4.c:460:34-35: WARNING: sum of probable bitmasks, consider |
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Samuel Zou <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1588834135-14842-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Samuel Zou [Thu, 7 May 2020 03:54:07 +0000 (11:54 +0800)]
ALSA: sound/ppc: Use bitwise instead of arithmetic operator for flags
Fix the following coccinelle warnings:
sound/ppc/pmac.c:729:57-58: WARNING: sum of probable bitmasks, consider |
sound/ppc/pmac.c:229:37-38: WARNING: sum of probable bitmasks, consider |
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Samuel Zou <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1588823647-12480-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Jason Yan [Wed, 6 May 2020 06:17:16 +0000 (14:17 +0800)]
ALSA: hda: Return true,false for return type bool
Fix the following coccicheck warning:
include/sound/hdaudio.h:210:73-74: WARNING: return of 0/1 in function
'snd_hdac_is_in_pm' with return type bool
include/sound/hdaudio.h:211:76-77: WARNING: return of 0/1 in function
'snd_hdac_is_power_on' with return type bool
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200506061716.19209-1-yanaijie@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Kai-Heng Feng [Tue, 5 May 2020 03:03:53 +0000 (11:03 +0800)]
ALSA: hda: Use hdac_to_hda_codec macro
Use hdac_to_hda_codec() instead of container_of().
No functional change intended.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200505030357.28004-2-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Kai-Heng Feng [Tue, 5 May 2020 03:03:52 +0000 (11:03 +0800)]
ALSA: hda: Use dev_to_hdac_dev macro
Use dev_to_hdac_dev() instead of container_of().
No functional change intended.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200505030357.28004-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Sameer Pujar [Mon, 4 May 2020 08:16:16 +0000 (13:46 +0530)]
ALSA: hda/tegra: workaround playback failure on Tegra194
Tegra194 has 4 SDO lines and with this configuration playback fails
for 44.1K/48K, 2-channel and 16-bps. It results in below print,
"aplay: pcm_write:2011: write error: Input/output error"
Below relation is used to derive stripe control and is referenced
from HD Audio Specification: Revision 1.0a.
{ ((num_channels * bits_per_sample) / number of SDOs) >= 8 }
Due to a legacy HW design problem, playback issue is hit while using
a stripe value resulting from above formula when ratio is '8'. Thus
it is recommended that the ratio must be greater than '8'. Since the
number of SDO lines is in powers of 2, next available ratio '16' is
used as a limiting factor on Tegra194 to workaround the problem.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1588580176-2801-4-git-send-email-spujar@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Sameer Pujar [Mon, 4 May 2020 08:16:15 +0000 (13:46 +0530)]
ALSA: hda: add member to store ratio for stripe control
Stripe control programming is governed by following formula, which is
referenced from the HD Audio specification(Revision 1.0a).
{ ((num_channels * bits_per_sample) / number of SDOs) >= 8 }
Currently above is implemented in snd_hdac_get_stream_stripe_ctl().
This patch introduces a structure member to store the default factor
of '8'. If any HW wants to use a different value, this member can be
easily updated.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1588580176-2801-3-git-send-email-spujar@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Sameer Pujar [Mon, 4 May 2020 08:16:14 +0000 (13:46 +0530)]
ALSA: hda/tegra: correct number of SDO lines for Tegra194
Tegra194 supports 4 SDO lines but GCAP register indicates 2 lines. Thus it
does not reflect the true capability of the HW. This patch presents a
workaround by updating NSDO value accordingly in T_AZA_DBG_CFG_2 register.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1588580176-2801-2-git-send-email-spujar@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Vasily Khoruzhick [Sat, 2 May 2020 19:31:20 +0000 (12:31 -0700)]
ALSA: line6: Add poll callback for hwdep
At least POD HD500 uses message-based communication, both sides can
send messages. Add poll callback so application can wait for device
messages without using busy loop.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://lore.kernel.org/r/20200502193120.79115-3-anarsoul@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Vasily Khoruzhick [Sat, 2 May 2020 19:31:19 +0000 (12:31 -0700)]
ALSA: line6: hwdep: add support for O_NONBLOCK opening mode
Currently line6 hwdep interface ignores O_NONBLOCK flag when
opening device and it renders it somewhat useless when using poll.
Check for O_NONBLOCK flag when opening device and don't block read()
if it is set.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://lore.kernel.org/r/20200502193120.79115-2-anarsoul@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Dan Carpenter [Fri, 1 May 2020 09:40:11 +0000 (12:40 +0300)]
ALSA: isa/wavefront: prevent out of bounds write in ioctl
The "header->number" comes from the ioctl and it needs to be clamped to
prevent out of bounds writes.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200501094011.GA960082@mwanda
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Fri, 1 May 2020 07:28:56 +0000 (09:28 +0200)]
ALSA: hda/realtek - Fix unused variable warning w/o CONFIG_LEDS_TRIGGER_AUDIO
Cover with a proper ifdef around the variable declaration for fixing
the following compilation warning without CONFIG_LEDS_TRIGGER_AUDIO:
sound/pci/hda/patch_realtek.c: In function 'alc_fixup_hp_gpio_led':
sound/pci/hda/patch_realtek.c:4134:6: warning: unused variable 'err' [-Wunused-variable]
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes:
87dc36482cab ("ALSA: hda/realtek - Add LED class support for micmute LED")
Link: https://lore.kernel.org/r/20200501072857.13720-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Kai-Heng Feng [Thu, 30 Apr 2020 13:52:07 +0000 (21:52 +0800)]
ALSA: hda/realtek - Add LED class support for micmute LED
Currently DMIC controls micmute LED via "audio mute LED trigger".
However, unlike Dell and Lenovo platforms, HP platforms don't provide a
way to control micmute LED via ACPI, it's controlled by HDA codec
instead.
So let's register an LED class for micmute so other subsystems like DMIC
can facilitate the codec-controlled LED.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200430135209.14703-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Kai-Heng Feng [Thu, 30 Apr 2020 08:32:52 +0000 (16:32 +0800)]
ALSA: hda/realtek - Enable micmute LED on and HP system
Though the system uses DMIC, headset mic still uses the HDA, let's use
GPIO 0x1 to control the micmute LED.
The micmute LED GPIO has a different polarity to the mute LED GPIO, we
can use the newly added micmute_led_polarity to indicate that.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200430083255.5093-2-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Kai-Heng Feng [Thu, 30 Apr 2020 08:32:51 +0000 (16:32 +0800)]
ALSA: hda/realtek - Introduce polarity for micmute LED GPIO
Currently mute LED and micmute LED share the same GPIO polarity.
So split the polarity for mute and micmute, in case they have different
polarities.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200430083255.5093-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
YueHaibing [Wed, 29 Apr 2020 13:28:05 +0000 (21:28 +0800)]
ALSA: seq: oss: remove unused inline function snd_seq_oss_timer_is_realtime
There's no callers in-tree.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200429132805.18712-1-yuehaibing@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Fri, 24 Apr 2020 07:40:16 +0000 (09:40 +0200)]
ALSA: usb-audio: Fix racy list management in output queue
The linked list entry from FIFO is peeked at
queue_pending_output_urbs() but the actual element pop-out is
performed outside the spinlock, and it's potentially racy.
Do delete the link at the right place inside the spinlock.
Fixes:
8fdff6a319e7 ("ALSA: snd-usb: implement new endpoint streaming model")
Link: https://lore.kernel.org/r/20200424074016.14301-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Alexander Tsoy [Fri, 24 Apr 2020 02:24:49 +0000 (05:24 +0300)]
ALSA: usb-audio: Remove async workaround for Scarlett 2nd gen
Frame size computation has been fixed and the workaround is no longer
needed.
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Link: https://lore.kernel.org/r/20200424022449.14972-2-alexander@tsoy.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Alexander Tsoy [Fri, 24 Apr 2020 02:24:48 +0000 (05:24 +0300)]
ALSA: usb-audio: Improve frames size computation
For computation of the the next frame size current value of fs/fps and
accumulated fractional parts of fs/fps are used, where values are stored
in Q16.16 format. This is quite natural for computing frame size for
asynchronous endpoints driven by explicit feedback, since in this case
fs/fps is a value provided by the feedback endpoint and it's already in
the Q format. If an error is accumulated over time, the device can
adjust fs/fps value to prevent buffer overruns/underruns.
But for synchronous endpoints the accuracy provided by these computations
is not enough. Due to accumulated error the driver periodically produces
frames with incorrect size (+/- 1 audio sample).
This patch fixes this issue by implementing a different algorithm for
frame size computation. It is based on accumulating of the remainders
from division fs/fps and it doesn't accumulate errors over time. This
new method is enabled for synchronous and adaptive playback endpoints.
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Link: https://lore.kernel.org/r/20200424022449.14972-1-alexander@tsoy.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Fri, 24 Apr 2020 06:24:39 +0000 (08:24 +0200)]
Merge branch 'for-linus' into for-next
Back-merge 5.7-rc devel branch for further changes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Fri, 24 Apr 2020 06:12:22 +0000 (08:12 +0200)]
ALSA: hda: Match both PCI ID and SSID for driver blacklist
The commit
3c6fd1f07ed0 ("ALSA: hda: Add driver blacklist") added a
new blacklist for the devices that are known to have empty codecs, and
one of the entries was ASUS ROG Zenith II (PCI SSID 1043:874f).
However, it turned out that the very same PCI SSID is used for the
previous model that does have the valid HD-audio codecs and the change
broke the sound on it.
Since the empty codec problem appear on the certain AMD platform (PCI
ID 1022:1487), this patch changes the blacklist matching to both PCI
ID and SSID using pci_match_id(). Also, the entry that was removed by
the previous fix for ASUS ROG Zenigh II is re-added.
Link: https://lore.kernel.org/r/20200424061222.19792-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Fri, 24 Apr 2020 06:22:16 +0000 (08:22 +0200)]
Merge branch 'topic/nhlt' into for-next
Merge NHLT init cleanup.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cezary Rojewski [Thu, 23 Apr 2020 16:03:10 +0000 (18:03 +0200)]
ALSA: hda: Refactor Intel NHLT init
NHLT fetch based on _DSM prevents ACPI table override mechanism from
being utilized. Make use of acpi_get_table to enable it and get rid of
redundant code. In consequence, NHLT can be overridden just like any
other ACPI table, e.g.: DSDT or SSDT.
Change has been verified on all Intel AVS architecture platforms, RVP
and production laptops both.
Change possible due to addition of NHLT signature to the list of
standard ACPI tables:
https://patchwork.kernel.org/patch/
11463235/
Override helps not only with debug purposes but also allows user for
table adjustment when one found on their production hardware is invalid.
Shared official NHLT spec is now available to community at:
https://01.org/blogs/intel-smart-sound-technology-audio-dsp
NHLT support for iASL is still ongoing subject but should be available
in nearest future.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200423160310.28019-1-cezary.rojewski@intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Wed, 22 Apr 2020 20:37:44 +0000 (22:37 +0200)]
ALSA: hda: Always use jackpoll helper for jack update after resume
HD-audio codec driver applies a tricky procedure to forcibly perform
the runtime resume by mimicking the usage count even if the device has
been runtime-suspended beforehand. This was needed to assure to
trigger the jack detection update after the system resume.
And recently we also applied the similar logic to the HD-audio
controller side. However this seems leading to some inconsistency,
and eventually PCI controller gets screwed up.
This patch is an attempt to fix and clean up those behavior: instead
of the tricky runtime resume procedure, the existing jackpoll work is
scheduled when such a forced codec resume is required. The jackpoll
work will power up the codec, and this alone should suffice for the
jack status update in usual cases. If the extra polling is requested
(by checking codec->jackpoll_interval), the manual update is invoked
after that, and the codec is powered down again.
Also, we filter the spurious wake up of the codec from the controller
runtime resume by checking codec->relaxed_resume flag. If this flag
is set, basically we don't need to wake up explicitly, but it's
supposed to be done via the audio component notifier.
Fixes:
c4c8dd6ef807 ("ALSA: hda: Skip controller resume if not needed")
Link: https://lore.kernel.org/r/20200422203744.26299-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Kailang Yang [Thu, 23 Apr 2020 06:18:31 +0000 (14:18 +0800)]
ALSA: hda/realtek - Add new codec supported for ALC245
Enable new codec supported for ALC245.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/8c0804738b2c42439f59c39c8437817f@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Xiyu Yang [Thu, 23 Apr 2020 04:54:19 +0000 (12:54 +0800)]
ALSA: usb-audio: Fix usb audio refcnt leak when getting spdif
snd_microii_spdif_default_get() invokes snd_usb_lock_shutdown(), which
increases the refcount of the snd_usb_audio object "chip".
When snd_microii_spdif_default_get() returns, local variable "chip"
becomes invalid, so the refcount should be decreased to keep refcount
balanced.
The reference counting issue happens in several exception handling paths
of snd_microii_spdif_default_get(). When those error scenarios occur
such as usb_ifnum_to_if() returns NULL, the function forgets to decrease
the refcnt increased by snd_usb_lock_shutdown(), causing a refcnt leak.
Fix this issue by jumping to "end" label when those error scenarios
occur.
Fixes:
447d6275f0c2 ("ALSA: usb-audio: Add sanity checks for endpoint accesses")
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1587617711-13200-1-git-send-email-xiyuyang19@fudan.edu.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Wed, 22 Apr 2020 11:33:20 +0000 (13:33 +0200)]
ALSA: usb-audio: Add connector notifier delegation
It turned out that ALC1220-VB USB-audio device gives the interrupt
event to some PCM terminals while those don't allow the connector
state request but only the actual I/O terminals return the request.
The recent commit
7dc3c5a0172e ("ALSA: usb-audio: Don't create jack
controls for PCM terminals") excluded those phantom terminals, so
those events are ignored, too.
My first thought was that this could be easily deduced from the
associated terminals, but some of them have even no associate terminal
ID, hence it's not too trivial to figure out.
Since the number of such terminals are small and limited, this patch
implements another quirk table for the simple mapping of the
connectors. It's not really scalable, but let's hope that there will
be not many such funky devices in future.
Fixes:
7dc3c5a0172e ("ALSA: usb-audio: Don't create jack controls for PCM terminals")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873
Link: https://lore.kernel.org/r/20200422113320.26664-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Jason Yan [Wed, 22 Apr 2020 07:16:46 +0000 (15:16 +0800)]
ALSA: oxygen: use true,false for bool variables
Fix the following coccicheck warning:
sound/pci/oxygen/xonar_pcm179x.c:463:1-17: WARNING: Assignment of 0/1 to
bool variable
sound/pci/oxygen/xonar_pcm179x.c:505:1-17: WARNING: Assignment of 0/1 to
bool variable
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200422071646.48436-1-yanaijie@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Dan Carpenter [Wed, 22 Apr 2020 09:22:55 +0000 (12:22 +0300)]
ALSA: usb-audio: Fix a limit check in proc_dump_substream_formats()
This should be ARRAY_SIZE() instead of sizeof(). The sizeof() limit is
too high so it doesn't work.
Fixes:
093b8494f299 ("ALSA: usb-audio: Print more information in stream proc files")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200422092255.GB195357@mwanda
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Tue, 21 Apr 2020 19:41:36 +0000 (21:41 +0200)]
Merge tag 'asoc-fix-v5.7-rc2' of https://git./linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v5.7
Quite a lot of fixes here, a lot of driver specific ones but the biggest
one is the revert of changes to the startup and shutdown sequence for
DAIs that went in during the merge window - they broke some older x86
platforms and attempts to fix them didn't succeed so it's safer to just
roll them back and try to make sure those platforms are handled properly
in any future attempt.
The rockchip S/PDIF DT stuff was IIRC for validation issues.
Alexander Tsoy [Tue, 21 Apr 2020 19:09:08 +0000 (22:09 +0300)]
ALSA: usb-audio: Apply async workaround for Scarlett 2i4 2nd gen
Due to rounding error driver sometimes incorrectly calculate next packet
size, which results in audible clicks on devices with synchronous playback
endpoints. For example on a high speed bus and a sample rate 44.1 kHz it
loses one sample every ~40.9 seconds. Fortunately playback interface on
Scarlett 2i4 2nd gen has a working explicit feedback endpoint, so we can
switch playback data endpoint to asynchronous mode as a workaround.
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Link: https://lore.kernel.org/r/20200421190908.462860-1-alexander@tsoy.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Shengjiu Wang [Tue, 21 Apr 2020 11:28:45 +0000 (19:28 +0800)]
ASoC: wm8960: Fix wrong clock after suspend & resume
After suspend & resume, wm8960_hw_params may be called when
bias_level is not SND_SOC_BIAS_ON, then wm8960_configure_clocking
is not called. But if sample rate is changed at that time, then
the output clock rate will be not correct.
So judgement of bias_level is SND_SOC_BIAS_ON in wm8960_hw_params
is not necessary and it causes above issue.
Fixes:
3176bf2d7ccd ("ASoC: wm8960: update pll and clock setting function")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/1587468525-27514-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Takashi Iwai [Mon, 20 Apr 2020 07:55:29 +0000 (09:55 +0200)]
ALSA: usx2y: Fix potential NULL dereference
The error handling code in usX2Y_rate_set() may hit a potential NULL
dereference when an error occurs before allocating all us->urb[].
Add a proper NULL check for fixing the corner case.
Reported-by: Lin Yi <teroincn@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200420075529.27203-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Gregor Pintar [Mon, 20 Apr 2020 21:40:30 +0000 (23:40 +0200)]
ALSA: usb-audio: Add quirk for Focusrite Scarlett 2i2
Force it to use asynchronous playback.
Same quirk has already been added for Focusrite Scarlett Solo (2nd gen)
with a commit
46f5710f0b88 ("ALSA: usb-audio: Add quirk for Focusrite
Scarlett Solo").
This also seems to prevent regular clicks when playing at 44100Hz
on Scarlett 2i2 (2nd gen). I did not notice any side effects.
Moved both quirks to snd_usb_audioformat_attributes_quirk() as suggested.
Signed-off-by: Gregor Pintar <grpintar@gmail.com>
Reviewed-by: Alexander Tsoy <alexander@tsoy.me>
Link: https://lore.kernel.org/r/20200420214030.2361-1-grpintar@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
YueHaibing [Mon, 20 Apr 2020 12:53:43 +0000 (20:53 +0800)]
ASoC: wm89xx: Add missing dependency
sound/soc/codecs/wm8900.o: In function `wm8900_i2c_probe':
wm8900.c:(.text+0xa36): undefined reference to `__devm_regmap_init_i2c'
sound/soc/codecs/wm8900.o: In function `wm8900_modinit':
wm8900.c:(.init.text+0xb): undefined reference to `i2c_register_driver'
sound/soc/codecs/wm8900.o: In function `wm8900_exit':
wm8900.c:(.exit.text+0x8): undefined reference to `i2c_del_driver'
sound/soc/codecs/wm8988.o: In function `wm8988_i2c_probe':
wm8988.c:(.text+0x857): undefined reference to `__devm_regmap_init_i2c'
sound/soc/codecs/wm8988.o: In function `wm8988_modinit':
wm8988.c:(.init.text+0xb): undefined reference to `i2c_register_driver'
sound/soc/codecs/wm8988.o: In function `wm8988_exit':
wm8988.c:(.exit.text+0x8): undefined reference to `i2c_del_driver'
sound/soc/codecs/wm8995.o: In function `wm8995_i2c_probe':
wm8995.c:(.text+0x1c4f): undefined reference to `__devm_regmap_init_i2c'
sound/soc/codecs/wm8995.o: In function `wm8995_modinit':
wm8995.c:(.init.text+0xb): undefined reference to `i2c_register_driver'
sound/soc/codecs/wm8995.o: In function `wm8995_exit':
wm8995.c:(.exit.text+0x8): undefined reference to `i2c_del_driver'
Add SND_SOC_I2C_AND_SPI dependency to fix this.
Fixes:
ea00d95200d02ece ("ASoC: Use imply for SND_SOC_ALL_CODECS")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200420125343.20920-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown [Mon, 20 Apr 2020 13:35:08 +0000 (14:35 +0100)]
Merge series "ASoC: rsnd: multi-SSI setup fixes" from Matthias Blankertz <matthias.blankertz@cetitec.com>:
Fix rsnd_dai_call() operations being performed twice for the master SSI
in multi-SSI setups, and fix the rsnd_ssi_stop operation for multi-SSI
setups.
The only visible effect of these issues was some "status check failed"
spam when the rsnd_ssi_stop was called, but overall the code is cleaner
now, and some questionable writes to the SSICR register which did not
lead to any observable misbehaviour but were contrary to the datasheet
are fixed.
Mark:
The first patch kind of reverts my "ASoC: rsnd: Fix parent SSI
start/stop in multi-SSI mode" from a few days ago and achieves the same
effect in a simpler fashion, if you would prefer a clean patch series
based on v5.6 drop me a note.
Greetings,
Matthias
Matthias Blankertz (2):
ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent
ASoC: rsnd: Fix "status check failed" spam for multi-SSI
sound/soc/sh/rcar/ssi.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
base-commit:
15a5760cb8b6d5c1ebbf1d2e1f0b77380ab68a82
--
2.26.1
Mark Brown [Mon, 20 Apr 2020 13:35:07 +0000 (14:35 +0100)]
Merge series "ASoC: meson: fix codec-to-codec link setup" from Jerome Brunet <jbrunet@baylibre.com>:
This patchset fixes the problem reported by Marc in this thread [0]
The problem was due to an error in the meson card drivers which had
the "no_pcm" dai_link property set on codec-to-codec links
[0]: https://lore.kernel.org/r/
20200417122732.GC5315@sirena.org.uk
Jerome Brunet (2):
ASoC: meson: axg-card: fix codec-to-codec link setup
ASoC: meson: gx-card: fix codec-to-codec link setup
sound/soc/meson/axg-card.c | 4 +++-
sound/soc/meson/gx-card.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
--
2.25.2
Gyeongtaek Lee [Sat, 18 Apr 2020 04:13:20 +0000 (13:13 +0900)]
ASoC: dapm: fixup dapm kcontrol widget
snd_soc_dapm_kcontrol widget which is created by autodisable control
should contain correct on_val, mask and shift because it is set when the
widget is powered and changed value is applied on registers by following
code in dapm_seq_run_coalesced().
mask |= w->mask << w->shift;
if (w->power)
value |= w->on_val << w->shift;
else
value |= w->off_val << w->shift;
Shift on the mask in dapm_kcontrol_data_alloc() is removed to prevent
double shift.
And, on_val in dapm_kcontrol_set_value() is modified to get correct
value in the dapm_seq_run_coalesced().
Signed-off-by: Gyeongtaek Lee <gt82.lee@samsung.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/000001d61537$b212f620$1638e260$@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Matthias Blankertz [Fri, 17 Apr 2020 15:30:17 +0000 (17:30 +0200)]
ASoC: rsnd: Fix "status check failed" spam for multi-SSI
Fix the rsnd_ssi_stop function to skip disabling the individual SSIs of
a multi-SSI setup, as the actual stop is performed by rsnd_ssiu_stop_gen2
- the same logic as in rsnd_ssi_start. The attempt to disable these SSIs
was harmless, but caused a "status check failed" message to be printed
for every SSI in the multi-SSI setup.
The disabling of interrupts is still performed, as they are enabled for
all SSIs in rsnd_ssi_init, but care is taken to not accidentally set the
EN bit for an SSI where it was not set by rsnd_ssi_start.
Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200417153017.1744454-3-matthias.blankertz@cetitec.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Matthias Blankertz [Fri, 17 Apr 2020 15:30:16 +0000 (17:30 +0200)]
ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent
The master SSI of a multi-SSI setup was attached both to the
RSND_MOD_SSI slot and the RSND_MOD_SSIP slot of the rsnd_dai_stream.
This is not correct wrt. the meaning of being "parent" in the rest of
the SSI code, where it seems to indicate an SSI that provides clock and
word sync but is not transmitting/receiving audio data.
Not treating the multi-SSI master as parent allows removal of various
special cases to the rsnd_ssi_is_parent conditions introduced in commit
a09fb3f28a60 ("ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode").
It also fixes the issue that operations performed via rsnd_dai_call()
were performed twice for the master SSI. This caused some "status check
failed" spam when stopping a multi-SSI stream as the driver attempted to
stop the master SSI twice.
Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200417153017.1744454-2-matthias.blankertz@cetitec.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Jerome Brunet [Mon, 20 Apr 2020 11:45:11 +0000 (13:45 +0200)]
ASoC: meson: gx-card: fix codec-to-codec link setup
Since the addition of commit
9b5db059366a ("ASoC: soc-pcm: dpcm: Only allow
playback/capture if supported"), meson-axg cards which have codec-to-codec
links fail to init and Oops.
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000128
Internal error: Oops:
96000044 [#1] PREEMPT SMP
CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1
pc : invalidate_paths_ep+0x30/0xe0
lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8
Call trace:
invalidate_paths_ep+0x30/0xe0
snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8
dpcm_path_get+0x38/0xd0
dpcm_fe_dai_open+0x70/0x920
snd_pcm_open_substream+0x564/0x840
snd_pcm_open+0xfc/0x228
snd_pcm_capture_open+0x4c/0x78
snd_open+0xac/0x1a8
...
While this error was initially reported the axg-card type, it also applies
to the gx-card type.
While initiliazing the links, ASoC treats the codec-to-codec links of this
card type as a DPCM backend. This error eventually leads to the Oops.
Most of the card driver code is shared between DPCM backends and
codec-to-codec links. The property "no_pcm" marking DCPM BE was left set on
codec-to-codec links, leading to this problem. This commit fixes that.
Fixes:
e37a0c313a0f ("ASoC: meson: gx: add sound card support")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200420114511.450560-3-jbrunet@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Jerome Brunet [Mon, 20 Apr 2020 11:45:10 +0000 (13:45 +0200)]
ASoC: meson: axg-card: fix codec-to-codec link setup
Since the addition of commit
9b5db059366a ("ASoC: soc-pcm: dpcm: Only allow
playback/capture if supported"), meson-axg cards which have codec-to-codec
links fail to init and Oops:
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000128
Internal error: Oops:
96000044 [#1] PREEMPT SMP
CPU: 3 PID: 1582 Comm: arecord Not tainted 5.7.0-rc1
pc : invalidate_paths_ep+0x30/0xe0
lr : snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8
Call trace:
invalidate_paths_ep+0x30/0xe0
snd_soc_dapm_dai_get_connected_widgets+0x170/0x1a8
dpcm_path_get+0x38/0xd0
dpcm_fe_dai_open+0x70/0x920
snd_pcm_open_substream+0x564/0x840
snd_pcm_open+0xfc/0x228
snd_pcm_capture_open+0x4c/0x78
snd_open+0xac/0x1a8
...
While initiliazing the links, ASoC treats the codec-to-codec links of this
card type as a DPCM backend. This error eventually leads to the Oops.
Most of the card driver code is shared between DPCM backends and
codec-to-codec links. The property "no_pcm" marking DCPM BE was left set on
codec-to-codec links, leading to this problem. This commit fixes that.
Fixes:
0a8f1117a680 ("ASoC: meson: axg-card: add basic codec-to-codec link support")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20200420114511.450560-2-jbrunet@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Takashi Iwai [Mon, 20 Apr 2020 06:20:36 +0000 (08:20 +0200)]
ALSA: usb-audio: Add static mapping table for ALC1220-VB-based mobos
TRX40 mobos from MSI and others with ALC1220-VB USB-audio device need
yet more quirks for the proper control names.
This patch provides the mapping table for those boards, correcting the
FU names for volume and mute controls as well as the terminal names
for jack controls. It also improves build_connector_control() not to
add the directional suffix blindly if the string is given from the
mapping table.
With this patch applied, the new UCM profiles will be effective.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873
Link: https://lore.kernel.org/r/20200420062036.28567-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai [Sun, 19 Apr 2020 21:21:34 +0000 (23:21 +0200)]
ALSA: usb-audio: Print more information in stream proc files
For more debug and usability information, add the entry showing the
DSD raw states and the channel mapping in each stream proc file.
Link: https://lore.kernel.org/r/20200419212134.14200-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Linus Torvalds [Sun, 19 Apr 2020 21:35:30 +0000 (14:35 -0700)]
Linux 5.7-rc2
Takashi Iwai [Sun, 19 Apr 2020 07:19:26 +0000 (09:19 +0200)]
ALSA: hda: Remove ASUS ROG Zenith from the blacklist
The commit
3c6fd1f07ed0 ("ALSA: hda: Add driver blacklist") added a
new blacklist for the devices that are known to have empty codecs, and
one of the entries was ASUS ROG Zenith II (PCI SSID 1043:874f).
However, it turned out that the very same PCI SSID is used for the
previous model that does have the valid HD-audio codecs and the change
broke the sound on it.
This patch reverts the corresponding entry as a temporary solution.
Although Zenith II and co will see get the empty HD-audio bus again,
it'd be merely resource wastes and won't affect the functionality,
so it's no end of the world. We'll need to address this later,
e.g. by either switching to DMI string matching or using PCI ID &
SSID pairs.
Fixes:
3c6fd1f07ed0 ("ALSA: hda: Add driver blacklist")
Reported-by: Johnathan Smithinovic <johnathan.smithinovic@gmx.at>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200419071926.22683-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Brian Geffon [Fri, 17 Apr 2020 17:25:56 +0000 (10:25 -0700)]
mm: Fix MREMAP_DONTUNMAP accounting on VMA merge
When remapping a mapping where a portion of a VMA is remapped
into another portion of the VMA it can cause the VMA to become
split. During the copy_vma operation the VMA can actually
be remerged if it's an anonymous VMA whose pages have not yet
been faulted. This isn't normally a problem because at the end
of the remap the original portion is unmapped causing it to
become split again.
However, MREMAP_DONTUNMAP leaves that original portion in place which
means that the VMA which was split and then remerged is not actually
split at the end of the mremap. This patch fixes a bug where
we don't detect that the VMAs got remerged and we end up
putting back VM_ACCOUNT on the next mapping which is completely
unreleated. When that next mapping is unmapped it results in
incorrectly unaccounting for the memory which was never accounted,
and eventually we will underflow on the memory comittment.
There is also another issue which is similar, we're currently
accouting for the number of pages in the new_vma but that's wrong.
We need to account for the length of the remap operation as that's
all that is being added. If there was a mapping already at that
location its comittment would have been adjusted as part of
the munmap at the start of the mremap.
A really simple repro can be seen in:
https://gist.github.com/bgaff/
e101ce99da7d9a8c60acc641d07f312c
Fixes:
e346b3813067 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Brian Geffon <bgeffon@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sun, 19 Apr 2020 20:59:06 +0000 (13:59 -0700)]
Merge tag 'clk-fixes-for-linus' of git://git./linux/kernel/git/clk/linux
Pull clk fixes from Stephen Boyd:
"Two build fixes for a couple clk drivers and a fix for the Unisoc
serial clk where we want to keep it on for earlycon"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: sprd: don't gate uart console clock
clk: mmp2: fix link error without mmp2
clk: asm9260: fix __clk_hw_register_fixed_rate_with_accuracy typo
Linus Torvalds [Sun, 19 Apr 2020 18:58:32 +0000 (11:58 -0700)]
Merge tag 'x86-urgent-2020-04-19' of git://git./linux/kernel/git/tip/tip
Pull x86 and objtool fixes from Thomas Gleixner:
"A set of fixes for x86 and objtool:
objtool:
- Ignore the double UD2 which is emitted in BUG() when
CONFIG_UBSAN_TRAP is enabled.
- Support clang non-section symbols in objtool ORC dump
- Fix switch table detection in .text.unlikely
- Make the BP scratch register warning more robust.
x86:
- Increase microcode maximum patch size for AMD to cope with new CPUs
which have a larger patch size.
- Fix a crash in the resource control filesystem when the removal of
the default resource group is attempted.
- Preserve Code and Data Prioritization enabled state accross CPU
hotplug.
- Update split lock cpu matching to use the new X86_MATCH macros.
- Change the split lock enumeration as Intel finaly decided that the
IA32_CORE_CAPABILITIES bits are not architectural contrary to what
the SDM claims. !@#%$^!
- Add Tremont CPU models to the split lock detection cpu match.
- Add a missing static attribute to make sparse happy"
* tag 'x86-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/split_lock: Add Tremont family CPU models
x86/split_lock: Bits in IA32_CORE_CAPABILITIES are not architectural
x86/resctrl: Preserve CDP enable over CPU hotplug
x86/resctrl: Fix invalid attempt at removing the default resource group
x86/split_lock: Update to use X86_MATCH_INTEL_FAM6_MODEL()
x86/umip: Make umip_insns static
x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE
objtool: Make BP scratch register warning more robust
objtool: Fix switch table detection in .text.unlikely
objtool: Support Clang non-section symbols in ORC generation
objtool: Support Clang non-section symbols in ORC dump
objtool: Fix CONFIG_UBSAN_TRAP unreachable warnings
Linus Torvalds [Sun, 19 Apr 2020 18:46:21 +0000 (11:46 -0700)]
Merge tag 'timers-urgent-2020-04-19' of git://git./linux/kernel/git/tip/tip
Pull time namespace fix from Thomas Gleixner:
"An update for the proc interface of time namespaces: Use symbolic
names instead of clockid numbers. The usability nuisance of numbers
was noticed by Michael when polishing the man page"
* tag 'timers-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
proc, time/namespace: Show clock symbolic names in /proc/pid/timens_offsets
Linus Torvalds [Sun, 19 Apr 2020 18:28:01 +0000 (11:28 -0700)]
Merge tag 'perf-urgent-2020-04-19' of git://git./linux/kernel/git/tip/tip
Pull perf tooling fixes and updates from Thomas Gleixner:
- Fix the header line of perf stat output for '--metric-only --per-socket'
- Fix the python build with clang
- The usual tools UAPI header synchronization
* tag 'perf-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tools headers: Synchronize linux/bits.h with the kernel sources
tools headers: Adopt verbatim copy of compiletime_assert() from kernel sources
tools headers: Update x86's syscall_64.tbl with the kernel sources
tools headers UAPI: Sync drm/i915_drm.h with the kernel sources
tools headers UAPI: Update tools's copy of drm.h headers
tools headers kvm: Sync linux/kvm.h with the kernel sources
tools headers UAPI: Sync linux/fscrypt.h with the kernel sources
tools include UAPI: Sync linux/vhost.h with the kernel sources
tools arch x86: Sync asm/cpufeatures.h with the kernel sources
tools headers UAPI: Sync linux/mman.h with the kernel
tools headers UAPI: Sync sched.h with the kernel
tools headers: Update linux/vdso.h and grab a copy of vdso/const.h
perf stat: Fix no metric header if --per-socket and --metric-only set
perf python: Check if clang supports -fno-semantic-interposition
tools arch x86: Sync the msr-index.h copy with the kernel sources
Linus Torvalds [Sun, 19 Apr 2020 18:23:33 +0000 (11:23 -0700)]
Merge tag 'irq-urgent-2020-04-19' of git://git./linux/kernel/git/tip/tip
Pull irq fixes from Thomas Gleixner:
"A set of fixes/updates for the interrupt subsystem:
- Remove setup_irq() and remove_irq(). All users have been converted
so remove them before new users surface.
- A set of bugfixes for various interrupt chip drivers
- Add a few missing static attributes to address sparse warnings"
* tag 'irq-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/irq-bcm7038-l1: Make bcm7038_l1_of_init() static
irqchip/irq-mvebu-icu: Make legacy_bindings static
irqchip/meson-gpio: Fix HARDIRQ-safe -> HARDIRQ-unsafe lock order
irqchip/sifive-plic: Fix maximum priority threshold value
irqchip/ti-sci-inta: Fix processing of masked irqs
irqchip/mbigen: Free msi_desc on device teardown
irqchip/gic-v4.1: Update effective affinity of virtual SGIs
irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling
genirq: Remove setup_irq() and remove_irq()
Linus Torvalds [Sun, 19 Apr 2020 18:18:20 +0000 (11:18 -0700)]
Merge tag 'sched-urgent-2020-04-19' of git://git./linux/kernel/git/tip/tip
Pull scheduler fixes from Thomas Gleixner:
"Two fixes for the scheduler:
- Work around an uninitialized variable warning where GCC can't
figure it out.
- Allow 'isolcpus=' to skip unknown subparameters so that older
kernels work with the commandline of a newer kernel. Improve the
error output while at it"
* tag 'sched-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/vtime: Work around an unitialized variable warning
sched/isolation: Allow "isolcpus=" to skip unknown sub-parameters
Linus Torvalds [Sun, 19 Apr 2020 18:16:00 +0000 (11:16 -0700)]
Merge tag 'core-urgent-2020-04-19' of git://git./linux/kernel/git/tip/tip
Pull RCU fix from Thomas Gleixner:
"A single bugfix for RCU to prevent taking a lock in NMI context"
* tag 'core-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
rcu: Don't acquire lock in NMI handler in rcu_nmi_enter_common()
Linus Torvalds [Sun, 19 Apr 2020 18:05:15 +0000 (11:05 -0700)]
Merge tag 'ext4_for_linus_stable' of git://git./linux/kernel/git/tytso/ext4
Pull ext4 fixes from Ted Ts'o:
"Miscellaneous bug fixes and cleanups for ext4, including a fix for
generic/388 in data=journal mode, removing some BUG_ON's, and cleaning
up some compiler warnings"
* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: convert BUG_ON's to WARN_ON's in mballoc.c
ext4: increase wait time needed before reuse of deleted inode numbers
ext4: remove set but not used variable 'es' in ext4_jbd2.c
ext4: remove set but not used variable 'es'
ext4: do not zeroout extents beyond i_disksize
ext4: fix return-value types in several function comments
ext4: use non-movable memory for superblock readahead
ext4: use matching invalidatepage in ext4_writepage
Linus Torvalds [Sun, 19 Apr 2020 18:00:27 +0000 (11:00 -0700)]
Merge tag '5.7-rc-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6
Pull cifs fixes from Steve French:
"Three small smb3 fixes: two debug related (helping network tracing for
SMB2 mounts, and the other removing an unintended debug line on
signing failures), and one fixing a performance problem with 64K
pages"
* tag '5.7-rc-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
smb3: remove overly noisy debug line in signing errors
cifs: improve read performance for page size 64KB & cache=strict & vers=2.1+
cifs: dump the session id and keys also for SMB2 sessions
Linus Torvalds [Sun, 19 Apr 2020 17:34:30 +0000 (10:34 -0700)]
Merge tag 'flexible-array-member-5.7-rc2' of git://git./linux/kernel/git/gustavoars/linux
Pull flexible-array member conversion from Gustavo Silva:
"The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array
member[1][2], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof
operator may not be applied. As a quirk of the original
implementation of zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible
array members have incomplete type[1]. There are some instances of
code in which the sizeof operator is being incorrectly/erroneously
applied to zero-length arrays and the result is zero. Such instances
may be hiding some bugs. So, this work (flexible-array member
convertions) will also help to get completely rid of those sorts of
issues.
Notice that all of these patches have been baking in linux-next for
quite a while now and, 238 more of these patches have already been
merged into 5.7-rc1.
There are a couple hundred more of these issues waiting to be
addressed in the whole codebase"
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
* tag 'flexible-array-member-5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux: (28 commits)
xattr.h: Replace zero-length array with flexible-array member
uapi: linux: fiemap.h: Replace zero-length array with flexible-array member
uapi: linux: dlm_device.h: Replace zero-length array with flexible-array member
tpm_eventlog.h: Replace zero-length array with flexible-array member
ti_wilink_st.h: Replace zero-length array with flexible-array member
swap.h: Replace zero-length array with flexible-array member
skbuff.h: Replace zero-length array with flexible-array member
sched: topology.h: Replace zero-length array with flexible-array member
rslib.h: Replace zero-length array with flexible-array member
rio.h: Replace zero-length array with flexible-array member
posix_acl.h: Replace zero-length array with flexible-array member
platform_data: wilco-ec.h: Replace zero-length array with flexible-array member
memcontrol.h: Replace zero-length array with flexible-array member
list_lru.h: Replace zero-length array with flexible-array member
lib: cpu_rmap: Replace zero-length array with flexible-array member
irq.h: Replace zero-length array with flexible-array member
ihex.h: Replace zero-length array with flexible-array member
igmp.h: Replace zero-length array with flexible-array member
genalloc.h: Replace zero-length array with flexible-array member
ethtool.h: Replace zero-length array with flexible-array member
...
Linus Torvalds [Sat, 18 Apr 2020 21:03:12 +0000 (14:03 -0700)]
Merge tag 'scsi-fixes' of git://git./linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Seven fixes: three in target, one on a sg error leg, two in qla2xxx
fixing warnings introduced in the last merge window and updating
MAINTAINERS and one in hisi_sas fixing a problem introduced by libata"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: sg: add sg_remove_request in sg_common_write
scsi: target: tcmu: reset_ring should reset TCMU_DEV_BIT_BROKEN
scsi: target: fix PR IN / READ FULL STATUS for FC
scsi: target: Write NULL to *port_nexus_ptr if no ISID
scsi: MAINTAINERS: Update qla2xxx FC-SCSI driver maintainer
scsi: qla2xxx: Fix regression warnings
scsi: hisi_sas: Fix build error without SATA_HOST
Gustavo A. R. Silva [Tue, 24 Mar 2020 00:41:14 +0000 (19:41 -0500)]
xattr.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Tue, 24 Mar 2020 02:30:22 +0000 (21:30 -0500)]
uapi: linux: fiemap.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Tue, 24 Mar 2020 00:51:46 +0000 (19:51 -0500)]
uapi: linux: dlm_device.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Tue, 24 Mar 2020 00:38:18 +0000 (19:38 -0500)]
tpm_eventlog.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Tue, 24 Mar 2020 00:25:06 +0000 (19:25 -0500)]
ti_wilink_st.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Tue, 24 Mar 2020 00:23:10 +0000 (19:23 -0500)]
swap.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Tue, 24 Mar 2020 00:22:24 +0000 (19:22 -0500)]
skbuff.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Tue, 24 Mar 2020 00:14:37 +0000 (19:14 -0500)]
sched: topology.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Tue, 24 Mar 2020 00:13:20 +0000 (19:13 -0500)]
rslib.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Tue, 24 Mar 2020 00:12:17 +0000 (19:12 -0500)]
rio.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Tue, 24 Mar 2020 00:08:58 +0000 (19:08 -0500)]
posix_acl.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Tue, 24 Mar 2020 00:07:49 +0000 (19:07 -0500)]
platform_data: wilco-ec.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Mon, 23 Mar 2020 23:36:10 +0000 (18:36 -0500)]
memcontrol.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Mon, 23 Mar 2020 23:32:01 +0000 (18:32 -0500)]
list_lru.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Mon, 23 Mar 2020 21:58:49 +0000 (16:58 -0500)]
lib: cpu_rmap: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Mon, 23 Mar 2020 23:01:11 +0000 (18:01 -0500)]
irq.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Mon, 23 Mar 2020 23:00:04 +0000 (18:00 -0500)]
ihex.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Gustavo A. R. Silva [Mon, 23 Mar 2020 22:59:00 +0000 (17:59 -0500)]
igmp.h: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>