- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch ".gitignore: sort normal pattern rules alphabetically" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled .gitignore: sort normal pattern rules alphabetically to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: gitignore-sort-normal-pattern-rules-alphabetically.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1377dd3e29878b8f5d9f5c9000975f50a428a0cd Mon Sep 17 00:00:00 2001 From: Masahiro Yamada <yamada.masahiro(a)socionext.com> Date: Tue, 31 Oct 2017 00:33:45 +0900 Subject: .gitignore: sort normal pattern rules alphabetically From: Masahiro Yamada <yamada.masahiro(a)socionext.com> commit 1377dd3e29878b8f5d9f5c9000975f50a428a0cd upstream. We are having more and more ignore patterns. Sort the list alphabetically. We will easily catch duplicated patterns if any. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Signed-off-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- .gitignore | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) --- a/.gitignore +++ b/.gitignore @@ -7,38 +7,38 @@ # command after changing this file, to see if there are # any tracked files which get ignored after the change. # -# Normal rules +# Normal rules (sorted alphabetically) # .* +*.a +*.bin +*.bz2 +*.c.[012]*.* +*.dwo +*.elf +*.gcno +*.gz +*.i +*.ko +*.ll +*.lst +*.lz4 +*.lzma +*.lzo +*.mod.c *.o *.o.* -*.a +*.order +*.patch *.s -*.ko *.so *.so.dbg -*.mod.c -*.i -*.lst +*.su *.symtypes -*.order -*.elf -*.bin *.tar -*.gz -*.bz2 -*.lzma *.xz -*.lz4 -*.lzo -*.patch -*.gcno -*.ll -modules.builtin Module.symvers -*.dwo -*.su -*.c.[012]*.* +modules.builtin # # Top-level generic files Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are queue-4.14/gitignore-move-.dtb-and-.dtb.s-patterns-to-the-top-level-.gitignore.patch queue-4.14/kbuild-rpm-pkg-keep-spec-file-until-make-mrproper.patch queue-4.14/gitignore-sort-normal-pattern-rules-alphabetically.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch ".gitignore: move *.dtb and *.dtb.S patterns to the top-level .gitignore" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled .gitignore: move *.dtb and *.dtb.S patterns to the top-level .gitignore to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: gitignore-move-.dtb-and-.dtb.s-patterns-to-the-top-level-.gitignore.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 10b62a2f785ab55857380f0c63d9fa468fd8c676 Mon Sep 17 00:00:00 2001 From: Masahiro Yamada <yamada.masahiro(a)socionext.com> Date: Tue, 31 Oct 2017 00:33:46 +0900 Subject: .gitignore: move *.dtb and *.dtb.S patterns to the top-level .gitignore From: Masahiro Yamada <yamada.masahiro(a)socionext.com> commit 10b62a2f785ab55857380f0c63d9fa468fd8c676 upstream. Most of DT files are compiled under arch/*/boot/dts/, but we have some other directories, like drivers/of/unittest-data/. We often miss to add gitignore patterns per directory. Since there are no source files that end with .dtb or .dtb.S, we can ignore the patterns globally. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Signed-off-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- .gitignore | 2 ++ arch/arc/boot/.gitignore | 1 - arch/arm/boot/.gitignore | 1 - arch/arm64/boot/dts/.gitignore | 1 - arch/metag/boot/.gitignore | 1 - arch/microblaze/boot/.gitignore | 1 - arch/mips/boot/.gitignore | 1 - arch/nios2/boot/.gitignore | 1 - arch/powerpc/boot/.gitignore | 1 - arch/xtensa/boot/.gitignore | 1 - drivers/of/unittest-data/.gitignore | 2 -- 11 files changed, 2 insertions(+), 11 deletions(-) --- a/.gitignore +++ b/.gitignore @@ -14,6 +14,8 @@ *.bin *.bz2 *.c.[012]*.* +*.dtb +*.dtb.S *.dwo *.elf *.gcno --- a/arch/arc/boot/.gitignore +++ b/arch/arc/boot/.gitignore @@ -1,2 +1 @@ -*.dtb* uImage --- a/arch/arm/boot/.gitignore +++ b/arch/arm/boot/.gitignore @@ -3,4 +3,3 @@ zImage xipImage bootpImage uImage -*.dtb --- a/arch/arm64/boot/dts/.gitignore +++ /dev/null @@ -1 +0,0 @@ -*.dtb --- a/arch/metag/boot/.gitignore +++ b/arch/metag/boot/.gitignore @@ -1,4 +1,3 @@ vmlinux* uImage* ramdisk.* -*.dtb* --- a/arch/microblaze/boot/.gitignore +++ b/arch/microblaze/boot/.gitignore @@ -1,3 +1,2 @@ -*.dtb linux.bin* simpleImage.* --- a/arch/mips/boot/.gitignore +++ b/arch/mips/boot/.gitignore @@ -5,4 +5,3 @@ zImage zImage.tmp calc_vmlinuz_load_addr uImage -*.dtb --- a/arch/nios2/boot/.gitignore +++ b/arch/nios2/boot/.gitignore @@ -1,2 +1 @@ -*.dtb vmImage --- a/arch/powerpc/boot/.gitignore +++ b/arch/powerpc/boot/.gitignore @@ -18,7 +18,6 @@ otheros.bld uImage cuImage.* dtbImage.* -*.dtb treeImage.* vmlinux.strip zImage --- a/arch/xtensa/boot/.gitignore +++ b/arch/xtensa/boot/.gitignore @@ -1,3 +1,2 @@ uImage zImage.redboot -*.dtb --- a/drivers/of/unittest-data/.gitignore +++ /dev/null @@ -1,2 +0,0 @@ -testcases.dtb -testcases.dtb.S Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are queue-4.14/gitignore-move-.dtb-and-.dtb.s-patterns-to-the-top-level-.gitignore.patch queue-4.14/kbuild-rpm-pkg-keep-spec-file-until-make-mrproper.patch queue-4.14/gitignore-sort-normal-pattern-rules-alphabetically.patch

7 years, 5 months

1
0
0 0

Re: [Linux-stable-mirror] Regression for ip6-in-ip4 IPsec tunnel in 4.14.16

by Mike Maloney

On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez <corsac(a)debian.org> wrote: > On Wed, 2018-02-07 at 18:05 +0100, Yves-Alexis Perez wrote: >> I'll try to printk the mtu before returning EINVAL to see why it's lower than >> 1280, but maybe the IP encapsulation is not correctly handled? > > I did: > > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c > index 3763dc01e374..d3c651158d35 100644 > --- a/net/ipv6/ip6_output.c > +++ b/net/ipv6/ip6_output.c > @@ -1215,7 +1215,7 @@ static int ip6_setup_cork(struct sock *sk, struct inet_cork_full *cork, > mtu = np->frag_size; > } > if (mtu < IPV6_MIN_MTU) > - return -EINVAL; > + printk("mtu: %d\n", mtu); > cork->base.fragsize = mtu; > if (dst_allfrag(rt->dst.path)) > cork->base.flags |= IPCORK_ALLFRAG; > > and I get: > > févr. 07 18:19:50 scapa kernel: mtu: 1218 > > and it doesn't depend on the original packet size (same thing happens with > ping -s 100). It also happens with UDP (DNS) traffic, but apparently not with > TCP. > > Regards, > -- > Yves-Alexis Hi Yves-Alexis - I apologize for the problem. It seems to me that tunneling with an outer MTU that causes the inner MTU to be smaller than the min, is potentially problematic in other ways as well. But also it could seem unfortunate that the code with my fix does not look at actual packet size, but instead only looks at the MTU and then fails, even if no packet was going to be so large. The intention of my patch was to prevent a negative number while calculating the maxfraglen in __ip6_append_data(). An alternative fix maybe to instead return an error only if the mtu is less than or equal to the fragheaderlen. Something like: diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 3763dc01e374..5d912a289b95 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1214,8 +1214,6 @@ static int ip6_setup_cork(struct sock *sk, struct inet_cork_full *cork, if (np->frag_size) mtu = np->frag_size; } - if (mtu < IPV6_MIN_MTU) - return -EINVAL; cork->base.fragsize = mtu; if (dst_allfrag(rt->dst.path)) cork->base.flags |= IPCORK_ALLFRAG; @@ -1264,6 +1262,8 @@ static int __ip6_append_data(struct sock *sk, fragheaderlen = sizeof(struct ipv6hdr) + rt->rt6i_nfheader_len + (opt ? opt->opt_nflen : 0); + if (mtu < fragheaderlen + 8) + return -EINVAL; maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen - sizeof(struct frag_hdr); (opt ? opt->opt_nflen : 0); But then we also have to convince ourselves that maxfraglen can never be <= 0. I'd have to think about that. I am not sure if others have thoughts on supporting MTUs configured below the min in the spec. Thanks. -- Mike Maloney

7 years, 5 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 3.18 00/36] 3.18.94-stable review

by Greg Kroah-Hartman

On Tue, Feb 06, 2018 at 11:42:15AM +0000, Harsh Shandilya wrote: > On Tue 6 Feb, 2018, 4:04 PM Greg Kroah-Hartman, <gregkh(a)linuxfoundation.org> > wrote: > > > On Tue, Feb 06, 2018 at 06:48:53AM +0000, Harsh Shandilya wrote: > > > On Tue 6 Feb, 2018, 12:09 AM Greg Kroah-Hartman, < > > gregkh(a)linuxfoundation.org> > > > wrote: > > > > > > > This is the start of the stable review cycle for the 3.18.94 release. > > > > There are 36 patches in this series, all will be posted as a response > > > > to this one. If anyone has any issues with these being applied, please > > > > let me know. > > > > > > > > Responses should be made by Wed Feb 7 18:23:41 UTC 2018. > > > > Anything received after that time might be too late. > > > > > > > > The whole patch series can be found in one patch at: > > > > > > > > kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.94-rc1.gz > > > > or in the git tree and branch at: > > > > git:// > > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > > linux-3.18.y > > > > and the diffstat can be found below. > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > > > > > Builds and boots on the OnePlus 3T, no regressions noticed. > > > > Yeah! That device is the only reason I keep this tree alive :) > > > > thanks for testing and letting me know. > > > > greg k-h > > > > Guess I should drop my kernel tree for the device and save you the pain of > maintaining 3.18 :P Heh, maybe :) > Atleast CAF has been keeping up with upstream now thanks to your > kernel-common merges so there's still hope for MSM platform users :) That's good to see. Now if only those platform users would actually update their kernels to these new versions :( > P.S. common merge should go in cleanly, both the merge conflicts I had were > from CAF changes. Thanks for letting me know, that's great to hear as I just had a question from some companies who are worried that taking stable patches will cause tons of merge issues. It hasn't in my experience, and seeing reports of this from others is great news. thanks, greg k-h

7 years, 5 months

2
3
0 0

[Linux-stable-mirror] Patch "x86/microcode/AMD: Do not load when running on a hypervisor" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/AMD: Do not load when running on a hypervisor to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-microcode-amd-do-not-load-when-running-on-a-hypervisor.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a15a753539eca8ba243d576f02e7ca9c4b7d7042 Mon Sep 17 00:00:00 2001 From: Borislav Petkov <bp(a)suse.de> Date: Sun, 18 Dec 2016 17:44:13 +0100 Subject: x86/microcode/AMD: Do not load when running on a hypervisor From: Borislav Petkov <bp(a)suse.de> commit a15a753539eca8ba243d576f02e7ca9c4b7d7042 upstream. Doing so is completely void of sense for multiple reasons so prevent it. Set dis_ucode_ldr to true and thus disable the microcode loader by default to address xen pv guests which execute the AP path but not the BSP path. By having it turned off by default, the APs won't run into the loader either. Also, check CPUID(1).ECX[31] which hypervisors set. Well almost, not the xen pv one. That one gets the aforementioned "fix". Also, improve the detection method by caching the final decision whether to continue loading in dis_ucode_ldr and do it once on the BSP. The APs then simply test that value. Signed-off-by: Borislav Petkov <bp(a)suse.de> Tested-by: Juergen Gross <jgross(a)suse.com> Tested-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Acked-by: Juergen Gross <jgross(a)suse.com> Link: http://lkml.kernel.org/r/20161218164414.9649-4-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Rolf Neugebauer <rolf.neugebauer(a)docker.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/core.c | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-) --- a/arch/x86/kernel/cpu/microcode/core.c +++ b/arch/x86/kernel/cpu/microcode/core.c @@ -43,7 +43,7 @@ #define MICROCODE_VERSION "2.01" static struct microcode_ops *microcode_ops; -static bool dis_ucode_ldr; +static bool dis_ucode_ldr = true; /* * Synchronization. @@ -73,6 +73,7 @@ struct cpu_info_ctx { static bool __init check_loader_disabled_bsp(void) { static const char *__dis_opt_str = "dis_ucode_ldr"; + u32 a, b, c, d; #ifdef CONFIG_X86_32 const char *cmdline = (const char *)__pa_nodebug(boot_command_line); @@ -85,8 +86,23 @@ static bool __init check_loader_disabled bool *res = &dis_ucode_ldr; #endif - if (cmdline_find_option_bool(cmdline, option)) - *res = true; + if (!have_cpuid_p()) + return *res; + + a = 1; + c = 0; + native_cpuid(&a, &b, &c, &d); + + /* + * CPUID(1).ECX[31]: reserved for hypervisor use. This is still not + * completely accurate as xen pv guests don't see that CPUID bit set but + * that's good enough as they don't land on the BSP path anyway. + */ + if (c & BIT(31)) + return *res; + + if (cmdline_find_option_bool(cmdline, option) <= 0) + *res = false; return *res; } @@ -118,9 +134,6 @@ void __init load_ucode_bsp(void) if (check_loader_disabled_bsp()) return; - if (!have_cpuid_p()) - return; - vendor = x86_cpuid_vendor(); family = x86_cpuid_family(); @@ -154,9 +167,6 @@ void load_ucode_ap(void) if (check_loader_disabled_ap()) return; - if (!have_cpuid_p()) - return; - vendor = x86_cpuid_vendor(); family = x86_cpuid_family(); Patches currently in stable-queue which might be from bp(a)suse.de are queue-4.9/x86-microcode-amd-do-not-load-when-running-on-a-hypervisor.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH] rtlwifi: rtl8821ae: Fix connection lost problem correctly

by Larry Finger

There has been a coding error in rtl8821ae since it was first introduced, namely that an 8-bit register was read using a 16-bit read in _rtl8821ae_dbi_read(). This error was fixed with commit 40b368af4b75 ("rtlwifi: Fix alignment issues"); however, this change led to instability in the connection. To restore stability, this change was reverted in commit b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem"). Unfortunately, the unaligned access causes machine checks in ARM architecture, and we were finally forced to find the actual cause of the problem on x86 platforms. Following a suggestion from Pkshih <pkshih(a)realtek.com>, it was found that increasing the ASPM L1 latency from 0 to 7 fixed the instability. This parameter was varied to see if a smaller value would work; however, it appears that 7 is the safest value. A new symbol is defined for this quantity, thus it can be easily changed if necessary. Fixes: b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem") Cc: Stable <stable(a)vger.kernel.org> # 4.14+ Fix-suggested-by: Pkshih <pkshih(a)realtek.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> --- Kalle, This patch should be submitted to 4.16. Larry --- drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 +++-- drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c index f20e77b4bb65..317c1b3101da 100644 --- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c @@ -1123,7 +1123,7 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, u16 addr) } if (0 == tmp) { read_addr = REG_DBI_RDATA + addr % 4; - ret = rtl_read_word(rtlpriv, read_addr); + ret = rtl_read_byte(rtlpriv, read_addr); } return ret; } @@ -1165,7 +1165,8 @@ static void _rtl8821ae_enable_aspm_back_door(struct ieee80211_hw *hw) } tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f); - _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7)); + _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) | + ASPM_L1_LATENCY << 3); tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719); _rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4)); diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h index 1c9ed28b42da..4f48b934ec01 100644 --- a/drivers/net/wireless/realtek/rtlwifi/wifi.h +++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h @@ -99,6 +99,7 @@ #define RTL_USB_MAX_RX_COUNT 100 #define QBSS_LOAD_SIZE 5 #define MAX_WMMELE_LENGTH 64 +#define ASPM_L1_LATENCY 7 #define TOTAL_CAM_ENTRY 32 -- 2.16.1

7 years, 5 months

3
3
0 0

[Linux-stable-mirror] [PATCH] drm/i915/breadcrumbs: Ignore unsubmitted signalers

by Chris Wilson

When a request is preempted, it is unsubmitted from the HW queue and removed from the active list of breadcrumbs. In the process, this however triggers the signaler and it may see the clear rbtree with the old, and still valid, seqno. This confuses the signaler into action and signaling the fence. Fixes: d6a2289d9d6b ("drm/i915: Remove the preempted request from the execution queue") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # v4.12+ --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c index efbc627a2a25..b955f7d7bd0f 100644 --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c @@ -588,29 +588,16 @@ void intel_engine_remove_wait(struct intel_engine_cs *engine, spin_unlock_irq(&b->rb_lock); } -static bool signal_valid(const struct drm_i915_gem_request *request) -{ - return intel_wait_check_request(&request->signaling.wait, request); -} - static bool signal_complete(const struct drm_i915_gem_request *request) { if (!request) return false; - /* If another process served as the bottom-half it may have already - * signalled that this wait is already completed. - */ - if (intel_wait_complete(&request->signaling.wait)) - return signal_valid(request); - - /* Carefully check if the request is complete, giving time for the + /* + * Carefully check if the request is complete, giving time for the * seqno to be visible or if the GPU hung. */ - if (__i915_request_irq_complete(request)) - return true; - - return false; + return __i915_request_irq_complete(request); } static struct drm_i915_gem_request *to_signaler(struct rb_node *rb) @@ -712,6 +699,7 @@ static int intel_breadcrumbs_signaler(void *arg) &request->fence.flags)) { local_bh_disable(); dma_fence_signal(&request->fence); + GEM_BUG_ON(!i915_gem_request_completed(request)); local_bh_enable(); /* kick start the tasklets */ } -- 2.15.1

7 years, 5 months

2
5
0 0

[Linux-stable-mirror] [PATCH 3.18] ARM: exynos_defconfig: enable CONFIG_ROOT_NFS and dependencies

by Guillaume Tucker

Enable CONFIG_ROOT_NFS and dependencies (CONFIG_NFS_*, CONFIG_IP_PNP) in order to be able to boot the Exynos devices with NFS root. Tested on exynos4412-odroidx2. Signed-off-by: Guillaume Tucker <guillaume.tucker(a)collabora.com> --- arch/arm/configs/exynos_defconfig | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index e21ef830a483..999ea477be54 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -33,6 +33,10 @@ CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_NET_KEY=y CONFIG_INET=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y CONFIG_RFKILL_REGULATOR=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y @@ -170,6 +174,10 @@ CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_CRAMFS=y CONFIG_ROMFS_FS=y +CONFIG_NFS_FS=y +CONFIG_NFS_V3_ACL=y +CONFIG_NFS_V4=y +CONFIG_ROOT_NFS=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y -- 2.11.0

7 years, 5 months

2
5
0 0

[Linux-stable-mirror] [PATCH] ALSA: hda - Fix headset mic detection problem for two Dell machines

by Hui Wang

One of them has the codec of alc256 and the other one has the codec of alc289. Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2347588..b791efe 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6735,6 +6735,11 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = { {0x14, 0x90170110}, {0x21, 0x02211020}), SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0x90a60130}, + {0x14, 0x90170110}, + {0x14, 0x01011020}, + {0x21, 0x0221101f}), + SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ALC256_STANDARD_PINS), SND_HDA_PIN_QUIRK(0x10ec0256, 0x1043, "ASUS", ALC256_FIXUP_ASUS_MIC, {0x14, 0x90170110}, @@ -6803,6 +6808,10 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = { {0x12, 0x90a60120}, {0x14, 0x90170110}, {0x21, 0x0321101f}), + SND_HDA_PIN_QUIRK(0x10ec0289, 0x1028, "Dell", ALC225_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0xb7a60130}, + {0x14, 0x90170110}, + {0x21, 0x04211020}), SND_HDA_PIN_QUIRK(0x10ec0290, 0x103c, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC1, ALC290_STANDARD_PINS, {0x15, 0x04211040}, -- 2.7.4

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] [PATCH 4.4.y 1/2] drm: rcar-du: Use the VBK interrupt for vblank events

by Nhan Nguyen

From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> commit cbbb90b0c084d7dfb2ed8e3fecf8df200fbdd2a0 upstream. When implementing support for interlaced modes, the driver switched from reporting vblank events on the vertical blanking (VBK) interrupt to the frame end interrupt (FRM). This incorrectly divided the reported refresh rate by two. Fix it by moving back to the VBK interrupt. Fixes: 906eff7fcada ("drm: rcar-du: Implement support for interlaced modes") Cc: stable(a)vger.kernel.org Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Signed-off-by: thongsyho <thong.ho.px(a)rvc.renesas.com> Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com> --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 9befd62..25bdab6 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -531,7 +531,7 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg) status = rcar_du_crtc_read(rcrtc, DSSR); rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK); - if (status & DSSR_FRM) { + if (status & DSSR_VBK) { drm_handle_vblank(rcrtc->crtc.dev, rcrtc->index); rcar_du_crtc_finish_page_flip(rcrtc); ret = IRQ_HANDLED; -- 1.9.1

7 years, 5 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror