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

by Jack Wang

From: Jack Wang <jinpu.wang(a)profitbricks.com> Hi Greg, I noticed 2 fixes for kvm are missing in your queue-4.14, both are bugfix, can be cherry pick cleanly. The patch from Tianyu should close bug below, also included in 3.16 https://bugzilla.kernel.org/show_bug.cgi?id=198991 Eric Biggers (1): KVM/x86: remove WARN_ON() for when vm_munmap() fails Tianyu Lan (1): KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs() arch/x86/kvm/x86.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) -- 2.7.4

7 years, 6 months

3
4
0 0

[PATCH] kbuild: Handle builtin dtb files containing hyphens

by James Hogan

On dtb files which contain hyphens, the dt_S_dtb command to build the dtb.S files (which allow DTB files to be built into the kernel) results in errors like the following: bcm3368-netgear-cvg834g.dtb.S: Assembler messages: bcm3368-netgear-cvg834g.dtb.S:5: Error: : no such section bcm3368-netgear-cvg834g.dtb.S:5: Error: junk at end of line, first unrecognized character is `-' bcm3368-netgear-cvg834g.dtb.S:6: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_begin:' bcm3368-netgear-cvg834g.dtb.S:8: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_end:' bcm3368-netgear-cvg834g.dtb.S:9: Error: : no such section bcm3368-netgear-cvg834g.dtb.S:9: Error: junk at end of line, first unrecognized character is `-' This is due to the hyphen being used in symbol names. Replace all hyphens with underscores in the dt_S_dtb command to avoid this problem. Quite a lot of dts files have hyphens, but its only a problem on MIPS where such files can be built into the kernel. For example when CONFIG_DT_NETGEAR_CVG834G=y, or on BMIPS kernels when the dtbs target is used (in the latter case it admitedly shouldn't really build all the dtb.o files, but thats a separate issue). Fixes: 695835511f96 ("MIPS: BMIPS: rename bcm96358nb4ser to bcm6358-neufbox4-sercom") Signed-off-by: James Hogan <jhogan(a)kernel.org> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Frank Rowand <frowand.list(a)gmail.com> Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com> Cc: Michal Marek <michal.lkml(a)markovi.net> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Kevin Cernekee <cernekee(a)gmail.com> Cc: devicetree(a)vger.kernel.org Cc: linux-kbuild(a)vger.kernel.org Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # 4.9+ --- scripts/Makefile.lib | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 5589bae34af6..a6f538b31ad6 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -297,11 +297,11 @@ cmd_dt_S_dtb= \ echo '\#include <asm-generic/vmlinux.lds.h>'; \ echo '.section .dtb.init.rodata,"a"'; \ echo '.balign STRUCT_ALIGNMENT'; \ - echo '.global __dtb_$(*F)_begin'; \ - echo '__dtb_$(*F)_begin:'; \ + echo '.global __dtb_$(subst -,_,$(*F))_begin'; \ + echo '__dtb_$(subst -,_,$(*F))_begin:'; \ echo '.incbin "$<" '; \ - echo '__dtb_$(*F)_end:'; \ - echo '.global __dtb_$(*F)_end'; \ + echo '__dtb_$(subst -,_,$(*F))_end:'; \ + echo '.global __dtb_$(subst -,_,$(*F))_end'; \ echo '.balign STRUCT_ALIGNMENT'; \ ) > $@ -- 2.13.6

7 years, 6 months

2
2
0 0

[PATCH AUTOSEL for 3.18 01/53] usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control()

by Sasha Levin

From: Yuyang Du <yuyang.du(a)intel.com> [ Upstream commit 9f20dfb44d03745d0d3cef2ffb3abf8d8024fa61 ] This fixes the commit: 1cd8fd2887e1 ("usb: gadget: dummy_hcd: add SuperSpeed support"). In the case of ClearPortFeature and USB_PORT_FEAT_POWER, simply clear the right bit regardless of what the wValue is. Acked-by: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Yuyang Du <yuyang.du(a)intel.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/usb/gadget/udc/dummy_hcd.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/usb/gadget/udc/dummy_hcd.c b/drivers/usb/gadget/udc/dummy_hcd.c index 783715a9e399..215441690d32 100644 --- a/drivers/usb/gadget/udc/dummy_hcd.c +++ b/drivers/usb/gadget/udc/dummy_hcd.c @@ -2001,16 +2001,13 @@ static int dummy_hub_control( } break; case USB_PORT_FEAT_POWER: - if (hcd->speed == HCD_USB3) { - if (dum_hcd->port_status & USB_PORT_STAT_POWER) - dev_dbg(dummy_dev(dum_hcd), - "power-off\n"); - } else - if (dum_hcd->port_status & - USB_SS_PORT_STAT_POWER) - dev_dbg(dummy_dev(dum_hcd), - "power-off\n"); - /* FALLS THROUGH */ + dev_dbg(dummy_dev(dum_hcd), "power-off\n"); + if (hcd->speed == HCD_USB3) + dum_hcd->port_status &= ~USB_SS_PORT_STAT_POWER; + else + dum_hcd->port_status &= ~USB_PORT_STAT_POWER; + set_link_state(dum_hcd); + break; default: dum_hcd->port_status &= ~(1 << wValue); set_link_state(dum_hcd); @@ -2181,14 +2178,13 @@ static int dummy_hub_control( if ((dum_hcd->port_status & USB_SS_PORT_STAT_POWER) != 0) { dum_hcd->port_status |= (1 << wValue); - set_link_state(dum_hcd); } } else if ((dum_hcd->port_status & USB_PORT_STAT_POWER) != 0) { dum_hcd->port_status |= (1 << wValue); - set_link_state(dum_hcd); } + set_link_state(dum_hcd); } break; case GetPortErrorCount: -- 2.14.1

7 years, 6 months

1
52
0 0

[PATCH AUTOSEL for 4.4 001/101] usb: dwc2: Make sure we disconnect the gadget state

by Sasha Levin

From: John Stultz <john.stultz(a)linaro.org> [ Upstream commit dad3f793f20fbb5c0c342f0f5a0bdf69a4d76089 ] I had seen some odd behavior with HiKey's usb-gadget interface that I finally seemed to have chased down. Basically every other time I plugged in the OTG port, the gadget interface would properly initialize. The other times, I'd get a big WARN_ON in dwc2_hsotg_init_fifo() about the fifo_map not being clear. Ends up if we don't disconnect the gadget state, the fifo-map doesn't get cleared properly, which causes WARN_ON messages and also results in the device not properly being setup as a gadget every other time the OTG port is connected. So this patch adds a call to dwc2_hsotg_disconnect() in the reset path so the state is properly cleared. With it, the gadget interface initializes properly on every plug in. Cc: Wei Xu <xuwei5(a)hisilicon.com> Cc: Guodong Xu <guodong.xu(a)linaro.org> Cc: Amit Pundir <amit.pundir(a)linaro.org> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: John Youn <johnyoun(a)synopsys.com> Cc: Douglas Anderson <dianders(a)chromium.org> Cc: Chen Yu <chenyu56(a)huawei.com> Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: linux-usb(a)vger.kernel.org Acked-by: John Youn <johnyoun(a)synopsys.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/usb/dwc2/hcd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index 571c21727ff9..88bd950665fa 100644 --- a/drivers/usb/dwc2/hcd.c +++ b/drivers/usb/dwc2/hcd.c @@ -1385,6 +1385,7 @@ static void dwc2_conn_id_status_change(struct work_struct *work) dwc2_core_init(hsotg, false, -1); dwc2_enable_global_interrupts(hsotg); spin_lock_irqsave(&hsotg->lock, flags); + dwc2_hsotg_disconnect(hsotg); dwc2_hsotg_core_init_disconnected(hsotg, false); spin_unlock_irqrestore(&hsotg->lock, flags); dwc2_hsotg_core_connect(hsotg); -- 2.14.1

7 years, 6 months

1
100
0 0

Patch "platform/x86: dell-laptop: fix kbd_get_state's request value" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/x86: dell-laptop: fix kbd_get_state's request value to the 4.15-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: platform-x86-dell-laptop-fix-kbd_get_state-s-request-value.patch and it can be found in the queue-4.15 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 eca39e7f0cdb9bde4003a29149fa695e876c6f73 Mon Sep 17 00:00:00 2001 From: Laszlo Toth <laszlth(a)gmail.com> Date: Tue, 13 Feb 2018 21:43:43 +0100 Subject: platform/x86: dell-laptop: fix kbd_get_state's request value MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Laszlo Toth <laszlth(a)gmail.com> commit eca39e7f0cdb9bde4003a29149fa695e876c6f73 upstream. Commit 9862b43624a5 ("platform/x86: dell-laptop: Allocate buffer on heap rather than globally") broke one request, changed it back to the original value. Tested on a Dell E6540, backlight came back. Fixes: 9862b43624a5 ("platform/x86: dell-laptop: Allocate buffer on heap rather than globally") Signed-off-by: Laszlo Toth <laszlth(a)gmail.com> Reviewed-by: Pali Rohár <pali.rohar(a)gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)dell.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/dell-laptop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/platform/x86/dell-laptop.c +++ b/drivers/platform/x86/dell-laptop.c @@ -1254,7 +1254,7 @@ static int kbd_get_state(struct kbd_stat struct calling_interface_buffer buffer; int ret; - dell_fill_request(&buffer, 0, 0, 0, 0); + dell_fill_request(&buffer, 0x1, 0, 0, 0); ret = dell_send_request(&buffer, CLASS_KBD_BACKLIGHT, SELECT_KBD_BACKLIGHT); if (ret) Patches currently in stable-queue which might be from laszlth(a)gmail.com are queue-4.15/platform-x86-dell-laptop-fix-kbd_get_state-s-request-value.patch

7 years, 6 months

1
0
0 0

Re: [PATCH] ubi: Reject MLC NAND

by Pavel Machek

On Wed 2018-03-07 22:11:13, David Woodhouse wrote: > > > On Wed, 2018-03-07 at 14:08 -0800, Steve deRosier wrote: > > > > To clarify one thing: the reason for this is MLC has actually never > > been supported, nor worked properly. The fact that it kinda worked was > > incidental and the cause of major problems for people due to that not > > being clear. This patch only makes it explicit and avoids people > > mistakenly trying to use UBIFS on MLC flash and risking their data and > > products. To me, that's what's important. > > > > This is an important patch, even if all it does is keep people from > > loosing data. It also changes the conversation from "I have a > > corrupted UBIFS device, BTW it's on MLC..." to "What can we do to get > > UBIFS to work on MLC". Well, for -stable I'd suggest printk(KERN_ALERT ...) but keep the system running. > This is a bug fix. > > UBI on MLC never worked. It was a bug that we ever permitted it. This > is now fixed. Yeah, well, so lets say I have a working hardware (maybe using read-only UBI on MLC), update to next stable kernel, and now kernel refuses to see the partition. I'll certainly not consider this patch a bug fix. Removing support for hardware that "only works by mistake" may be good idea, but maybe it is slightly too surprising for a -stable. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

7 years, 6 months

3
2
0 0

Re: [PATCH] kbuild: Handle builtin dtb files containing hyphens

by Frank Rowand

On 03/07/18 12:25, James Hogan wrote: > On Wed, Mar 07, 2018 at 12:11:41PM -0800, Frank Rowand wrote: >> I initially misread the patch description (and imagined an entirely >> different problem). >> >> >> On 03/07/18 06:06, James Hogan wrote: >>> On dtb files which contain hyphens, the dt_S_dtb command to build the> dtb.S files (which allow DTB files to be built into the kernel) results> in errors like the following:> > bcm3368-netgear-cvg834g.dtb.S: Assembler messages:> bcm3368-netgear-cvg834g.dtb.S:5: Error: : no such section> bcm3368-netgear-cvg834g.dtb.S:5: Error: junk at end of line, first unrecognized character is `-'> bcm3368-netgear-cvg834g.dtb.S:6: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_begin:'> bcm3368-netgear-cvg834g.dtb.S:8: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_end:'> bcm3368-netgear-cvg834g.dtb.S:9: Error: : no such section> bcm3368-netgear-cvg834g.dtb.S:9: Error: junk at end of line, first unrecognized character is `-' >> Please replace the following section: >> >>> This is due to the hyphen being used in symbol names. Replace all >>> hyphens >>> with underscores in the dt_S_dtb command to avoid this problem. >>> >>> Quite a lot of dts files have hyphens, but its only a problem on MIPS >>> where such files can be built into the kernel. For example when >>> CONFIG_DT_NETGEAR_CVG834G=y, or on BMIPS kernels when the dtbs target is >>> used (in the latter case it admitedly shouldn't really build all the >>> dtb.o files, but thats a separate issue). >> >> with: >> >> cmd_dt_S_dtb constructs the assembly source to incorporate a devicetree >> FDT (that is, the .dtb file) as binary data in the kernel image. >> This assembly source contains labels before and after the binary data. >> The label names incorporate the file name of the corresponding .dtb >> file. Hyphens are not legal characters in labels, so transform all >> hyphens from the file name to underscores when constructing the labels. > > Thanks, that is clearer. > > I'll keep the paragraph about MIPS and the example configuration though, > as I think its important information to reproduce the problem, and to > justify why it wouldn't be appropriate to just rename the files (which > was my first reaction). Other than the part that says "its only a problem on MIPS". That is pedantically correct because no other architecture (that I am aware of, not that I searched) currently has a devicetree source file name with a hyphen in it, where that file is compiled into the kernel as an asm file. But it is potentially a problem on any architecture to it is misleading to label it as MIPS only. > >> Reviewed-by: Frank Rowand <frowand.list(a)gmail.com> > > Thanks > James >

7 years, 6 months

1
0
0 0

Re: [PATCH] ubi: Reject MLC NAND

by Boris Brezillon

On Wed, 7 Mar 2018 22:43:42 +0100 Pavel Machek <pavel(a)ucw.cz> wrote: > On Wed 2018-03-07 09:01:16, Richard Weinberger wrote: > > Pavel, > > > > Am Mittwoch, 7. März 2018, 00:18:05 CET schrieb Pavel Machek: > > > On Sat 2018-03-03 11:45:54, Richard Weinberger wrote: > > > > While UBI and UBIFS seem to work at first sight with MLC NAND, you will > > > > most likely lose all your data upon a power-cut or due to read/write > > > > disturb. > > > > In order to protect users from bad surprises, refuse to attach to MLC > > > > NAND. > > > > > > > > Cc: stable(a)vger.kernel.org > > > > > > That sounds like _really_ bad idea for stable. All it does is it > > > removes support for hardware that somehow works. > > > > MLC is not supported and does not work. Full stop. > > If someone manages to get it somehow work, either with hardware or software > > hacks they are on their own. > > Having it in stable is the only chance we have to get it into vendor > > kernels. > > Can you show how it meets the stable kernel criteria? They are > documented in tree. This should not be in stable. > > And I'd like to see changelog improved. Real reason MLC is not > supported is upper/lower page parts on MLC. And real fix to work with > bigger pages in UBI. Come on! Don't you think this would have been fixed already if it was that easy?! Have you looked at an MLC datasheet to see how paired pages are combined? If you had you would now that paired pages are almost all the time not contiguous, thus preventing the trick you're suggesting here. Please document yourself before doing such presumptuous statements (you can have a look at these slides if you want some details about why this is not so simple [1]). I'm definitely not saying supporting MLC NANDs in Linux is impossible, and if you're interested in working on this topic I'd be happy to help. But please don't block this patch without understanding what supporting MLC NANDs implies. [1]https://events.static.linuxfound.org/sites/events/files/slides/ubi-mlc.pdf -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com

7 years, 6 months

1
0
0 0

Re: [PATCH] ubi: Reject MLC NAND

by Steve deRosier

Hi Pavel, On Wed, Mar 7, 2018 at 1:43 PM, Pavel Machek <pavel(a)ucw.cz> wrote: > On Wed 2018-03-07 09:01:16, Richard Weinberger wrote: >> Pavel, >> >> Am Mittwoch, 7. März 2018, 00:18:05 CET schrieb Pavel Machek: >> > On Sat 2018-03-03 11:45:54, Richard Weinberger wrote: >> > > While UBI and UBIFS seem to work at first sight with MLC NAND, you will >> > > most likely lose all your data upon a power-cut or due to read/write >> > > disturb. >> > > In order to protect users from bad surprises, refuse to attach to MLC >> > > NAND. >> > > >> > > Cc: stable(a)vger.kernel.org >> > >> > That sounds like _really_ bad idea for stable. All it does is it >> > removes support for hardware that somehow works. >> >> MLC is not supported and does not work. Full stop. >> If someone manages to get it somehow work, either with hardware or software >> hacks they are on their own. >> Having it in stable is the only chance we have to get it into vendor >> kernels. > > Can you show how it meets the stable kernel criteria? They are > documented in tree. This should not be in stable. > > And I'd like to see changelog improved. Real reason MLC is not > supported is upper/lower page parts on MLC. And real fix to work with > bigger pages in UBI. > To clarify one thing: the reason for this is MLC has actually never been supported, nor worked properly. The fact that it kinda worked was incidental and the cause of major problems for people due to that not being clear. This patch only makes it explicit and avoids people mistakenly trying to use UBIFS on MLC flash and risking their data and products. To me, that's what's important. This is an important patch, even if all it does is keep people from loosing data. It also changes the conversation from "I have a corrupted UBIFS device, BTW it's on MLC..." to "What can we do to get UBIFS to work on MLC". I don't know what the stable criteria is with re: to this patch. But what I do know is if it doesn't go back into the various stables, there will be manufacturers who will continue to try to use UBIFS on MLC in ignorance for the next several years until the current stable kernels EOL, despite there being a known patch that would make it immediately obvious they shouldn't. Thanks, - Steve

7 years, 6 months

1
0
0 0

Re: [PATCH] staging: android: ashmem: Remove deadlock

by Greg Kroah-Hartman

On Wed, Mar 07, 2018 at 02:02:13PM -0800, Paul Lawrence wrote: > Great! We need to make sure this gets backported to 4.4 and 4.9, and to > 3.18 with the original dependency, please. That will happen when it lands in Linus's tree, which should be later this week if all goes well. thanks, greg k-h

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror