linux-stable.git, branch v5.11.4

Linux 5.11.4

2021-03-07T11:35:58+00:00

Tested-by: Jon Hunter 
Tested-by: Jason Self 
Tested-by: Guenter Roeck 
Tested-by: Linux Kernel Functional Testing 
Link: https://lore.kernel.org/r/20210305120903.166929741@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman

ALSA: hda/realtek: Apply dual codec quirks for MSI Godlike X570 board

2021-03-07T11:35:58+00:00

commit 26af17722a07597d3e556eda92c6fce8d528bc9f upstream.

There is another MSI board (1462:cc34) that has dual Realtek codecs,
and we need to apply the existing quirk for fixing the conflicts of
Master control.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211743
Cc: 
Link: https://lore.kernel.org/r/20210303142346.28182-1-tiwai@suse.de
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda/realtek: Add quirk for Intel NUC 10

2021-03-07T11:35:58+00:00

commit 73e7161eab5dee98114987239ec9c87fe8034ddb upstream.

This adds a new SND_PCI_QUIRK(...) and applies it to the Intel NUC 10
devices. This fixes the issue of the devices not having audio input and
output on the headset jack because the kernel does not recognize when
something is plugged in.

The new quirk was inspired by the quirk for the Intel NUC 8 devices, but
it turned out that the NUC 10 uses another pin. This information was
acquired by black box testing likely pins.

Co-developed-by: Eckhart Mohr 
Signed-off-by: Eckhart Mohr 
Signed-off-by: Werner Sembach 
Cc: 
Link: https://lore.kernel.org/r/20210302180414.23194-1-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda/realtek: Add quirk for Clevo NH55RZQ

2021-03-07T11:35:57+00:00

commit 48698c973e6b4dde94d87cd1ded56d9436e9c97d upstream.

This applies a SND_PCI_QUIRK(...) to the Clevo NH55RZQ barebone. This
fixes the issue of the device not recognizing a pluged in microphone.

The device has both, a microphone only jack, and a speaker + microphone
combo jack. The combo jack already works. The microphone-only jack does
not recognize when a device is pluged in without this patch.

Signed-off-by: Eckhart Mohr 
Co-developed-by: Werner Sembach 
Signed-off-by: Werner Sembach 
Cc: 
Link: https://lore.kernel.org/r/0eee6545-5169-ef08-6cfa-5def8cd48c86@tuxedocomputers.com
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

phy: mediatek: Add missing MODULE_DEVICE_TABLE()

2021-03-07T11:35:57+00:00

commit 9a8b9434c60f40e4d2603c822a68af6a9ca710df upstream.

This patch adds the missing MODULE_DEVICE_TABLE definitions on different
Mediatek phy drivers which generates correct modalias for automatic loading
when these drivers are compiled as an external module.

Signed-off-by: Boris Brezillon 
Signed-off-by: Enric Balletbo i Serra 
Link: https://lore.kernel.org/r/20210203110631.686003-1-enric.balletbo@collabora.com
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

tty: teach the n_tty ICANON case about the new "cookie continuations" too

2021-03-07T11:35:57+00:00

commit d7fe75cbc23c7d225eee2ef04def239b6603dce7 upstream.

The ICANON case is a bit messy, since it has to look for the line
ending, and has special code to then suppress line ending characters if
they match the __DISABLED_CHAR.  So it actually looks up the line ending
even past the point where it knows it won't copy it to the result
buffer.

That said, apart from all those odd legacy N_TTY ICANON cases, the
actual "should we continue copying" logic isn't really all that
complicated or different from the non-canon case.  In fact, the lack of
"wait for at least N characters" arguably makes the repeat case slightly
simpler.  It really just boils down to "there's more of the line to be
copied".

So add the necessarily trivial logic, and now the N_TTY case will give
long result lines even when in canon mode.

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

tty: teach n_tty line discipline about the new "cookie continuations"

2021-03-07T11:35:57+00:00

commit 15ea8ae8e03fdb845ed3ff5d9f11dd5f4f60252c upstream.

With the conversion to do the tty ldisc read operations in small chunks,
the n_tty line discipline became noticeably slower for throughput
oriented loads, because rather than read things in up to 2kB chunks, it
would return at most 64 bytes per read() system call.

The cost is mainly all in the "do system calls over and over", not
really in the new "copy to an extra kernel buffer".

This can be fixed by teaching the n_tty line discipline about the
"cookie continuation" model, which the chunking code supports because
things like hdlc need to be able to handle packets up to 64kB in size.

Doing that doesn't just get us back to the old performace, but to much
better performance: my stupid "copy 10MB of data over a pty" test
program is now almost twice as fast as it used to be (going down from
0.1s to 0.054s).

This is entirely because it now creates maximal chunks (which happens to
be "one byte less than one page" due to how we do the circular tty
buffers).

NOTE! This case only handles the simpler non-icanon case, which is the
one where people may care about throughput.  I'm going to do the icanon
case later too, because while performance isn't a major issue for that,
there may be programs that think they'll always get a full line and
don't like the 64-byte chunking for that reason.

Such programs are arguably buggy (signals etc can cause random partial
results from tty reads anyway), and good programs will handle such
partial reads, but expecting everybody to write "good programs" has
never been a winning policy for the kernel..

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

tty: clean up legacy leftovers from n_tty line discipline

2021-03-07T11:35:57+00:00

commit 64a69892afadd6fffaeadc65427bb7601161139d upstream.

Back when the line disciplines did their own direct user accesses, they
had to deal with the data copy possibly failing in the middle.

Now that the user copy is done by the tty_io.c code, that failure case
no longer exists.

Remove the left-over error handling code that cannot trigger.

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

tty: fix up hung_up_tty_read() conversion

2021-03-07T11:35:57+00:00

commit ddc5fda7456178e2cbc87675b370920d98360daf upstream.

In commit "tty: implement read_iter", I left the read_iter conversion of
the hung up tty case alone, because I incorrectly thought it didn't
matter.

Jiri showed me the errors of my ways, and pointed out the problems with
that incomplete conversion.  Fix it all up.

Reported-by: Jiri Slaby 
Signed-off-by: Linus Torvalds 
Reviewed-by: Jiri Slaby 
Link: https://lore.kernel.org/r/CAHk-=wh+-rGsa=xruEWdg_fJViFG8rN9bpLrfLz=_yBYh2tBhA@mail.gmail.com
Signed-off-by: Greg Kroah-Hartman

tty: fix up iterate_tty_read() EOVERFLOW handling

2021-03-07T11:35:57+00:00

commit e71a8d5cf4b4f274740e31b601216071e2a11afa upstream.

When I converted the tty_ldisc_ops 'read()' function to take a kernel
pointer, I was a bit too aggressive about the ldisc returning EOVERFLOW.

Yes, we want to have EOVERFLOW override any partially read data (because
the whole point is that the buffer was too small for the whole packet,
and we don't want to see partial packets), but it shouldn't override a
previous EFAULT.

And in fact, it really is just EOVERFLOW that is special and should
throw away any partially read data, not "any error".  Admittedly
EOVERFLOW is currently the only one that can happen for a continuation
read - and if the first read iteration returns an error we won't have this issue.

So this is more of a technicality, but let's just make the intent very
explicit, and re-organize the error handling a bit so that this is all
clearer.

Reported-by: Jiri Slaby 
Signed-off-by: Linus Torvalds 
Reviewed-by: Jiri Slaby 
Link: https://lore.kernel.org/r/CAHk-=wh+-rGsa=xruEWdg_fJViFG8rN9bpLrfLz=_yBYh2tBhA@mail.gmail.com
Signed-off-by: Greg Kroah-Hartman