12 Nov, 2020

1 commit


08 Oct, 2020

1 commit

  • * tag 'v5.4.70': (3051 commits)
    Linux 5.4.70
    netfilter: ctnetlink: add a range check for l3/l4 protonum
    ep_create_wakeup_source(): dentry name can change under you...
    ...

    Conflicts:
    arch/arm/mach-imx/pm-imx6.c
    arch/arm64/boot/dts/freescale/imx8mm-evk.dts
    arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
    drivers/crypto/caam/caamalg.c
    drivers/gpu/drm/imx/dw_hdmi-imx.c
    drivers/gpu/drm/imx/imx-ldb.c
    drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
    drivers/mmc/host/sdhci-esdhc-imx.c
    drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
    drivers/net/ethernet/freescale/enetc/enetc.c
    drivers/net/ethernet/freescale/enetc/enetc_pf.c
    drivers/thermal/imx_thermal.c
    drivers/usb/cdns3/ep0.c
    drivers/xen/swiotlb-xen.c
    sound/soc/fsl/fsl_esai.c
    sound/soc/fsl/fsl_sai.c

    Signed-off-by: Jason Liu

    Jason Liu
     

07 Oct, 2020

2 commits

  • commit 2b8bd423614c595540eaadcfbc702afe8e155e50 upstream.

    Currently io_ticks is approximated by adding one at each start and end of
    requests if jiffies counter has changed. This works perfectly for requests
    shorter than a jiffy or if one of requests starts/ends at each jiffy.

    If disk executes just one request at a time and they are longer than two
    jiffies then only first and last jiffies will be accounted.

    Fix is simple: at the end of request add up into io_ticks jiffies passed
    since last update rather than just one jiffy.

    Example: common HDD executes random read 4k requests around 12ms.

    fio --name=test --filename=/dev/sdb --rw=randread --direct=1 --runtime=30 &
    iostat -x 10 sdb

    Note changes of iostat's "%util" 8,43% -> 99,99% before/after patch:

    Before:

    Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
    sdb 0,00 0,00 82,60 0,00 330,40 0,00 8,00 0,96 12,09 12,09 0,00 1,02 8,43

    After:

    Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
    sdb 0,00 0,00 82,50 0,00 330,00 0,00 8,00 1,00 12,10 12,10 0,00 12,12 99,99

    Now io_ticks does not loose time between start and end of requests, but
    for queue-depth > 1 some I/O time between adjacent starts might be lost.

    For load estimation "%util" is not as useful as average queue length,
    but it clearly shows how often disk queue is completely empty.

    Fixes: 5b18b5a73760 ("block: delete part_round_stats and switch to less precise counting")
    Signed-off-by: Konstantin Khlebnikov
    Reviewed-by: Ming Lei
    Signed-off-by: Jens Axboe
    From: "Banerjee, Debabrata"
    Signed-off-by: Greg Kroah-Hartman

    Konstantin Khlebnikov
     
  • [ Upstream commit ac67b07e268d46eba675a60c37051bb3e59fd201 ]

    Currently, the aspeed-sgpio driver exposes up to 80 GPIO lines,
    corresponding to the 80 status bits available in hardware. Each of these
    lines can be configured as either an input or an output.

    However, each of these GPIOs is actually an input *and* an output; we
    actually have 80 inputs plus 80 outputs.

    This change expands the maximum number of GPIOs to 160; the lower half
    of this range are the input-only GPIOs, the upper half are the outputs.
    We fix the GPIO directions to correspond to this mapping.

    This also fixes a bug when setting GPIOs - we were reading from the
    input register, making it impossible to set more than one output GPIO.

    Signed-off-by: Jeremy Kerr
    Fixes: 7db47faae79b ("gpio: aspeed: Add SGPIO driver")
    Reviewed-by: Joel Stanley
    Reviewed-by: Andrew Jeffery
    Acked-by: Rob Herring
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Jeremy Kerr
     

01 Oct, 2020

2 commits

  • commit 95364f36701e62dd50eee91e1303187fd1a9f567 upstream.

    In case a driver wants to return an error from qc_prep, return enum
    ata_completion_errors. sata_mv is one of those drivers -- see the next
    patch. Other drivers return the newly defined AC_ERR_OK.

    [v2] use enum ata_completion_errors and AC_ERR_OK.

    Signed-off-by: Jiri Slaby
    Cc: Jens Axboe
    Cc: linux-ide@vger.kernel.org
    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    Jiri Slaby
     
  • [ Upstream commit 8c149b7d75e53be47648742f40fc90d9fc6fa63a ]

    The required supplies in bindings were actually not matching
    implementation making the bindings incorrect and misleading. The Linux
    kernel driver requires all supplies to be present. Also for wlf,wm8994
    uses just DBVDD-supply instead of DBVDDn-supply (n: ).

    Reported-by: Jonathan Bakker
    Signed-off-by: Krzysztof Kozlowski
    Link: https://lore.kernel.org/r/20200501133534.6706-1-krzk@kernel.org
    Signed-off-by: Mark Brown
    Signed-off-by: Sasha Levin

    Krzysztof Kozlowski
     

22 Sep, 2020

1 commit


10 Sep, 2020

2 commits

  • commit d3a84a8d0dde4e26bc084b36ffcbdc5932ac85e2 upstream.

    The basic permission bits (protection bits in AmigaOS) have been broken
    in Linux' AFFS - it would only set bits, but never delete them.
    Also, contrary to the documentation, the Archived bit was not handled.

    Let's fix this for good, and set the bits such that Linux and classic
    AmigaOS can coexist in the most peaceful manner.

    Also, update the documentation to represent the current state of things.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Max Staudt
    Signed-off-by: David Sterba
    Signed-off-by: Greg Kroah-Hartman

    Max Staudt
     
  • commit 65557383191de46611dd3d6b639cbcfbade43c4a upstream.

    Add description for resets/reset-names.

    Cc: # v5.4+
    Fixes: 966580ad236e ("mmc: mediatek: add support for MT7622 SoC")
    Signed-off-by: Wenbin Mei
    Tested-by: Frank Wunderlich
    Link: https://lore.kernel.org/r/20200814014346.6496-2-wenbin.mei@mediatek.com
    Signed-off-by: Ulf Hansson
    Signed-off-by: Greg Kroah-Hartman

    Wenbin Mei
     

05 Sep, 2020

1 commit

  • commit f7f86e8ac0ad7cd6792a80137f5a550924966916 upstream.

    commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")

    Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data
    timeout.

    So, this patch adds "tmclk" to Tegra sdhci clock property in the
    device tree binding.

    Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
    Cc: stable # 5.4
    Reviewed-by: Jon Hunter
    Signed-off-by: Sowjanya Komatineni
    Link: https://lore.kernel.org/r/1598548861-32373-4-git-send-email-skomatineni@nvidia.com
    Signed-off-by: Ulf Hansson
    Signed-off-by: Greg Kroah-Hartman

    Sowjanya Komatineni
     

26 Aug, 2020

4 commits

  • commit a0d1c951ef08ed24f35129267e3595d86f57f5d3 upstream.

    As Documentation/kbuild/llvm.rst implies, building the kernel with a
    full set of LLVM tools gets very verbose and unwieldy.

    Provide a single switch LLVM=1 to use Clang and LLVM tools instead
    of GCC and Binutils. You can pass it from the command line or as an
    environment variable.

    Please note LLVM=1 does not turn on the integrated assembler. You need
    to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the
    integrated assembler, I think we can make it default.

    We discussed what we need, and we agreed to go with a simple boolean
    flag that switches both target and host tools:

    https://lkml.org/lkml/2020/3/28/494
    https://lkml.org/lkml/2020/4/3/43

    Some items discussed, but not adopted:

    - LLVM_DIR

    When multiple versions of LLVM are installed, I just thought supporting
    LLVM_DIR=/path/to/my/llvm/bin/ might be useful.

    CC = $(LLVM_DIR)clang
    LD = $(LLVM_DIR)ld.lld
    ...

    However, we can handle this by modifying PATH. So, we decided to not do
    this.

    - LLVM_SUFFIX

    Some distributions (e.g. Debian) package specific versions of LLVM with
    naming conventions that use the version as a suffix.

    CC = clang$(LLVM_SUFFIX)
    LD = ld.lld(LLVM_SUFFIX)
    ...

    will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc.,
    but the suffixed versions in /usr/bin/ are symlinks to binaries in
    /usr/lib/llvm-#/bin/, so this can also be handled by PATH.

    Signed-off-by: Masahiro Yamada
    Reviewed-by: Nathan Chancellor
    Tested-by: Nathan Chancellor # build
    Tested-by: Nick Desaulniers
    Reviewed-by: Nick Desaulniers
    Signed-off-by: Nick Desaulniers
    Signed-off-by: Greg Kroah-Hartman

    Masahiro Yamada
     
  • commit 7e20e47c70f810d678d02941fa3c671209c4ca97 upstream.

    The 'AS' variable is unused for building the kernel. Only the remaining
    usage is to turn on the integrated assembler. A boolean flag is a better
    fit for this purpose.

    AS=clang was added for experts. So, I replaced it with LLVM_IAS=1,
    breaking the backward compatibility.

    Suggested-by: Nick Desaulniers
    Signed-off-by: Masahiro Yamada
    Reviewed-by: Nathan Chancellor
    Reviewed-by: Nick Desaulniers
    Signed-off-by: Nick Desaulniers
    Signed-off-by: Greg Kroah-Hartman

    Masahiro Yamada
     
  • commit 0f44fbc162b737ff6251ae248184390ae2279fee upstream.

    The tool is called llvm-size, not llvm-objsize.

    Fixes: fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/ Clang/LLVM")
    Signed-off-by: Fangrui Song
    Reviewed-by: Nick Desaulniers
    Reviewed-by: Nathan Chancellor
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Nick Desaulniers
    Signed-off-by: Greg Kroah-Hartman

    Fangrui Song
     
  • commit fcf1b6a35c16ac500fa908a4022238e5d666eabf upstream.

    added to kbuild documentation. Provides more official info on building
    kernels with Clang and LLVM than our wiki.

    Suggested-by: Kees Cook
    Reviewed-by: Kees Cook
    Reviewed-by: Nathan Chancellor
    Reviewed-by: Sedat Dilek
    Signed-off-by: Nick Desaulniers
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Greg Kroah-Hartman

    Nick Desaulniers
     

21 Aug, 2020

2 commits


20 Aug, 2020

1 commit


19 Aug, 2020

1 commit

  • [ Upstream commit df16c33a4028159d1ba8a7061c9fa950b58d1a61 ]

    IIO_CONCENTRATION together with INFO_RAW specifier is used for reporting
    raw concentrations of pollutants. Raw value should be meaningless
    before being properly scaled. Because of that description shouldn't
    mention raw value unit whatsoever.

    Fix this by rephrasing existing description so it follows conventions
    used throughout IIO ABI docs.

    Fixes: 8ff6b3bc94930 ("iio: chemical: Add IIO_CONCENTRATION channel type")
    Signed-off-by: Tomasz Duszynski
    Acked-by: Matt Ranostay
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Sasha Levin

    Tomasz Duszynski
     

13 Aug, 2020

1 commit


22 Jul, 2020

2 commits

  • [ Upstream commit 3d157c28d2289edf0439e8308e8de3a06acaaf0e ]

    This patch updates the documentation with the information related
    to the quirks that needs to be added for disabling all SuperSpeed XHCI
    instances in park mode.

    Cc: Dongjin Kim
    Cc: Jianxin Pan
    Cc: Thinh Nguyen
    Cc: Jun Li
    Reported-by: Tim
    Signed-off-by: Neil Armstrong
    Acked-by: Rob Herring
    Signed-off-by: Felipe Balbi
    Signed-off-by: Sasha Levin

    Neil Armstrong
     
  • [ Upstream commit 35b9c0fdb9f666628ecda02b1fc44306933a2d97 ]

    Fix unit address to match the first address specified in the reg
    property of the node in example.

    Signed-off-by: Kangmin Park
    Link: https://lore.kernel.org/r/20200625135158.5861-1-l4stpr0gr4m@gmail.com
    Signed-off-by: Rob Herring
    Signed-off-by: Sasha Levin

    Kangmin Park
     

10 Jul, 2020

1 commit

  • The DTS is for i.MX8MP DSP offload audio playback. DSP only use OCRAM
    and OCRAM_A when audio playback, so DRAM can enter retention mode to
    save Power. As the size limitation of OCRAM and OCRAM_A and the size
    audio decoder library, the LPA playback only can support MP3 and AAC.
    OCRAM address is 0x900000-0x990000. ATF will use 0x960000-0x980000.
    DSP LPA will use ocram(0x900000-0x960000) and ocram_e(0x980000-
    0x990000)

    Signed-off-by: Bing Song

    Bing Song
     

24 Jun, 2020

1 commit


22 Jun, 2020

2 commits

  • [ Upstream commit b0ff9b590733079f7f9453e5976a9dd2630949e3 ]

    Add property "pinctrl-names" to swap pin mode between gpio and dpi mode.
    Set the dpi pins to gpio mode and output-low to avoid leakage current
    when dpi disabled.

    Acked-by: Rob Herring
    Signed-off-by: Jitao Shi
    Signed-off-by: Chun-Kuang Hu
    Signed-off-by: Sasha Levin

    Jitao Shi
     
  • [ Upstream commit f7d31e65368aeef973fab788aa22c4f1d5a6af66 ]

    The problem the patch is trying to address is the fact that 'struct
    kvm_hyperv_exit' has different layout on when compiling in 32 and 64 bit
    modes.

    In 64-bit mode the default alignment boundary is 64 bits thus
    forcing extra gaps after 'type' and 'msr' but in 32-bit mode the
    boundary is at 32 bits thus no extra gaps.

    This is an issue as even when the kernel is 64 bit, the userspace using
    the interface can be both 32 and 64 bit but the same 32 bit userspace has
    to work with 32 bit kernel.

    The issue is fixed by forcing the 64 bit layout, this leads to ABI
    change for 32 bit builds and while we are obviously breaking '32 bit
    userspace with 32 bit kernel' case, we're fixing the '32 bit userspace
    with 64 bit kernel' one.

    As the interface has no (known) users and 32 bit KVM is rather baroque
    nowadays, this seems like a reasonable decision.

    Reviewed-by: Vitaly Kuznetsov
    Signed-off-by: Jon Doron
    Message-Id:
    Reviewed-by: Roman Kagan
    Signed-off-by: Paolo Bonzini
    Signed-off-by: Sasha Levin

    Jon Doron
     

19 Jun, 2020

1 commit

  • * tag 'v5.4.47': (2193 commits)
    Linux 5.4.47
    KVM: arm64: Save the host's PtrAuth keys in non-preemptible context
    KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception
    ...

    Conflicts:
    arch/arm/boot/dts/imx6qdl.dtsi
    arch/arm/mach-imx/Kconfig
    arch/arm/mach-imx/common.h
    arch/arm/mach-imx/suspend-imx6.S
    arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
    arch/powerpc/include/asm/cacheflush.h
    drivers/cpufreq/imx6q-cpufreq.c
    drivers/dma/imx-sdma.c
    drivers/edac/synopsys_edac.c
    drivers/firmware/imx/imx-scu.c
    drivers/net/ethernet/freescale/fec.h
    drivers/net/ethernet/freescale/fec_main.c
    drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
    drivers/net/phy/phy_device.c
    drivers/perf/fsl_imx8_ddr_perf.c
    drivers/usb/cdns3/gadget.c
    drivers/usb/dwc3/gadget.c
    include/uapi/linux/dma-buf.h

    Signed-off-by: Jason Liu

    Jason Liu
     

17 Jun, 2020

1 commit

  • commit b5265c813ce4efbfa2e46fd27cdf9a7f44a35d2e upstream.

    In some rare cases, for input data over 32 KB, lzo-rle could encode two
    different inputs to the same compressed representation, so that
    decompression is then ambiguous (i.e. data may be corrupted - although
    zram is not affected because it operates over 4 KB pages).

    This modifies the compressor without changing the decompressor or the
    bitstream format, such that:

    - there is no change to how data produced by the old compressor is
    decompressed

    - an old decompressor will correctly decode data from the updated
    compressor

    - performance and compression ratio are not affected

    - we avoid introducing a new bitstream format

    In testing over 12.8M real-world files totalling 903 GB, three files
    were affected by this bug. I also constructed 37M semi-random 64 KB
    files totalling 2.27 TB, and saw no affected files. Finally I tested
    over files constructed to contain each of the ~1024 possible bad input
    sequences; for all of these cases, updated lzo-rle worked correctly.

    There is no significant impact to performance or compression ratio.

    Signed-off-by: Dave Rodgman
    Signed-off-by: Andrew Morton
    Cc: Mark Rutland
    Cc: Dave Rodgman
    Cc: Willy Tarreau
    Cc: Sergey Senozhatsky
    Cc: Markus F.X.J. Oberhumer
    Cc: Minchan Kim
    Cc: Nitin Gupta
    Cc: Chao Yu
    Cc:
    Link: http://lkml.kernel.org/r/20200507100203.29785-1-dave.rodgman@arm.com
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Dave Rodgman
     

11 Jun, 2020

4 commits

  • Add the iMX PCIe endpoint mode supports.

    Signed-off-by: Richard Zhu
    Reviewed-by: Fugang Duan

    Richard Zhu
     
  • commit 3798cc4d106e91382bfe016caa2edada27c2bb3f upstream

    Make the docs match the code.

    Signed-off-by: Josh Poimboeuf
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     
  • commit 7222a1b5b87417f22265c92deea76a6aecd0fb0f upstream

    Add documentation for the SRBDS vulnerability and its mitigation.

    [ bp: Massage.
    jpoimboe: sysfs table strings. ]

    Signed-off-by: Mark Gross
    Signed-off-by: Borislav Petkov
    Reviewed-by: Tony Luck
    Reviewed-by: Josh Poimboeuf
    Signed-off-by: Greg Kroah-Hartman

    Mark Gross
     
  • commit 7e5b3c267d256822407a22fdce6afdf9cd13f9fb upstream

    SRBDS is an MDS-like speculative side channel that can leak bits from the
    random number generator (RNG) across cores and threads. New microcode
    serializes the processor access during the execution of RDRAND and
    RDSEED. This ensures that the shared buffer is overwritten before it is
    released for reuse.

    While it is present on all affected CPU models, the microcode mitigation
    is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the
    cases where TSX is not supported or has been disabled with TSX_CTRL.

    The mitigation is activated by default on affected processors and it
    increases latency for RDRAND and RDSEED instructions. Among other
    effects this will reduce throughput from /dev/urandom.

    * Enable administrator to configure the mitigation off when desired using
    either mitigations=off or srbds=off.

    * Export vulnerability status via sysfs

    * Rename file-scoped macros to apply for non-whitelist table initializations.

    [ bp: Massage,
    - s/VULNBL_INTEL_STEPPING/VULNBL_INTEL_STEPPINGS/g,
    - do not read arch cap MSR a second time in tsx_fused_off() - just pass it in,
    - flip check in cpu_set_bug_bits() to save an indentation level,
    - reflow comments.
    jpoimboe: s/Mitigated/Mitigation/ in user-visible strings
    tglx: Dropped the fused off magic for now
    ]

    Signed-off-by: Mark Gross
    Signed-off-by: Borislav Petkov
    Signed-off-by: Thomas Gleixner
    Reviewed-by: Tony Luck
    Reviewed-by: Pawan Gupta
    Reviewed-by: Josh Poimboeuf
    Tested-by: Neelima Krishnan
    Signed-off-by: Greg Kroah-Hartman

    Mark Gross
     

10 Jun, 2020

1 commit


27 May, 2020

1 commit


22 May, 2020

1 commit


29 Apr, 2020

2 commits

  • …t for high speed devices")

    commit 3155f4f40811c5d7e3c686215051acf504e05565 upstream.

    Commit bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for
    high speed devices") changed the way the hub driver enumerates
    high-speed devices. Instead of using the "new" enumeration scheme
    first and switching to the "old" scheme if that doesn't work, we start
    with the "old" scheme. In theory this is better because the "old"
    scheme is slightly faster -- it involves resetting the device only
    once instead of twice.

    However, for a long time Windows used only the "new" scheme. Zeng Tao
    said that Windows 8 and later use the "old" scheme for high-speed
    devices, but apparently there are some devices that don't like it.
    William Bader reports that the Ricoh webcam built into his Sony Vaio
    laptop not only doesn't enumerate under the "old" scheme, it gets hung
    up so badly that it won't then enumerate under the "new" scheme! Only
    a cold reset will fix it.

    Therefore we will revert the commit and go back to trying the "new"
    scheme first for high-speed devices.

    Reported-and-tested-by: William Bader <williambader@hotmail.com>
    Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207219
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Fixes: bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices")
    CC: Zeng Tao <prime.zeng@hisilicon.com>
    CC: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221611230.11262-100000@iolanthe.rowland.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Alan Stern
     
  • [ Upstream commit 05460849c3b51180d5ada3373d0449aea19075e4 ]

    Cores affected by Neoverse-N1 #1542419 could execute a stale instruction
    when a branch is updated to point to freshly generated instructions.

    To workaround this issue we need user-space to issue unnecessary
    icache maintenance that we can trap. Start by hiding CTR_EL0.DIC.

    Reviewed-by: Suzuki K Poulose
    Signed-off-by: James Morse
    Signed-off-by: Catalin Marinas
    Signed-off-by: James Morse
    Signed-off-by: Sasha Levin

    James Morse
     

23 Apr, 2020

2 commits

  • commit fb2511247dc4061fd122d0195838278a4a0b7b59 upstream.

    cmdlinepart.c has been moved to drivers/mtd/parsers/.

    Fixes: a3f12a35c91d ("mtd: parsers: Move CMDLINE parser")
    Signed-off-by: Jonathan Neuschäfer
    Signed-off-by: Jonathan Corbet
    Signed-off-by: Greg Kroah-Hartman

    Jonathan Neuschäfer
     
  • [ Upstream commit f9f711efd441ad0d22874be49986d92121862335 ]

    If the kernel configuration option CONFIG_PCIE_DW_PLAT_HOST is enabled
    then this can cause the kernel to incorrectly probe the generic
    designware PCIe platform driver instead of the Tegra194 designware PCIe
    driver. This causes a boot failure on Tegra194 because the necessary
    configuration to access the hardware is not performed.

    The order in which the compatible strings are populated in Device-Tree
    is not relevant in this case, because the kernel will attempt to probe
    the device as soon as a driver is loaded and if the generic designware
    PCIe driver is loaded first, then this driver will be probed first.
    Therefore, to fix this problem, remove the "snps,dw-pcie" string from
    the compatible string as we never want this driver to be probe on
    Tegra194.

    Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT")
    Signed-off-by: Jon Hunter
    Signed-off-by: Thierry Reding
    Signed-off-by: Sasha Levin

    Jon Hunter
     

22 Apr, 2020

1 commit


17 Apr, 2020

1 commit

  • commit f36938aa7440f46a0a365f1cfde5f5985af2bef3 upstream.

    patch_realtek.c has historically failed to properly configure the PC
    Beep Hidden Register for the ALC256 codec (among others). Depending on
    your kernel version, symptoms of this misconfiguration can range from
    chassis noise, picked up by a poorly-shielded PCBEEP trace, getting
    amplified and played on your internal speaker and/or headphones to loud
    feedback, which responds to the "Headphone Mic Boost" ALSA control,
    getting played through your headphones. For details of the problem, see
    the patch in this series titled "ALSA: hda/realtek - Set principled PC
    Beep configuration for ALC256", which fixes the configuration.

    These symptoms have been most noticed on the Dell XPS 13 9350 and 9360,
    popular laptops that use the ALC256. As a result, several model-specific
    fixups have been introduced to try and fix the problem, the most
    egregious of which locks the "Headphone Mic Boost" control as a hack to
    minimize noise from a feedback loop that shouldn't have been there in
    the first place.

    Now that the underlying issue has been fixed, remove all these fixups.
    Remaining fixups needed by the XPS 13 are all picked up by existing pin
    quirks.

    This change should, for the XPS 13 9350/9360

    - Significantly increase volume and audio quality on headphones
    - Eliminate headphone popping on suspend/resume
    - Allow "Headphone Mic Boost" to be set again, making the headphone
    jack fully usable as a microphone jack too.

    Fixes: 8c69729b4439 ("ALSA: hda - Fix headphone noise after Dell XPS 13 resume back from S3")
    Fixes: 423cd785619a ("ALSA: hda - Fix headphone noise on Dell XPS 13 9360")
    Fixes: e4c9fd10eb21 ("ALSA: hda - Apply headphone noise quirk for another Dell XPS 13 variant")
    Fixes: 1099f48457d0 ("ALSA: hda/realtek: Reduce the Headphone static noise on XPS 9350/9360")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Hebb
    Link: https://lore.kernel.org/r/b649a00edfde150cf6eebbb4390e15e0c2deb39a.1585584498.git.tommyhebb@gmail.com
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Thomas Hebb