June 2018 - Linux-stable-mirror

[PATCH V5] scsi: hpsa: disable device during shutdown

by Sinan Kaya

'Commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")' has been added to kernel to shutdown pending PCIe port service interrupts during reboot so that a newly started kexec kernel wouldn't observe pending interrupts. pcie_port_device_remove() is disabling the root port and switches by calling pci_disable_device() after all PCIe service drivers are shutdown. This has been found to cause crashes on HP DL360 Gen9 machines during reboot due to hpsa driver not clearing the bus master bit during the shutdown procedure by calling pci_disable_device(). Disable device as part of the shutdown sequence. Signed-off-by: Sinan Kaya <okaya(a)codeaurora.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779 Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown") Cc: stable(a)vger.kernel.org Reported-by: Ryan Finnie <ryan(a)finnie.org> Tested-by: Don Brace <don.brace(a)microsemi.com> Acked-by: Don Brace <don.brace(a)microsemi.com> --- drivers/scsi/hpsa.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index 3a9eca1..b92f86a 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -8869,7 +8869,7 @@ static void hpsa_disable_rld_caching(struct ctlr_info *h) kfree(options); } -static void hpsa_shutdown(struct pci_dev *pdev) +static void __hpsa_shutdown(struct pci_dev *pdev) { struct ctlr_info *h; @@ -8884,6 +8884,12 @@ static void hpsa_shutdown(struct pci_dev *pdev) hpsa_disable_interrupt_mode(h); /* pci_init 2 */ } +static void hpsa_shutdown(struct pci_dev *pdev) +{ + __hpsa_shutdown(pdev); + pci_disable_device(pdev); +} + static void hpsa_free_device_info(struct ctlr_info *h) { int i; @@ -8927,7 +8933,7 @@ static void hpsa_remove_one(struct pci_dev *pdev) scsi_remove_host(h->scsi_host); /* init_one 8 */ /* includes hpsa_free_irqs - init_one 4 */ /* includes hpsa_disable_interrupt_mode - pci_init 2 */ - hpsa_shutdown(pdev); + __hpsa_shutdown(pdev); hpsa_free_device_info(h); /* scan */ -- 2.7.4

7 years

2
1
0 0

[PATCH 4/8] Drivers: hv: vmbus: Fix the offer_in_progress in vmbus_process_offer()

by kys＠linuxonhyperv.com

From: Dexuan Cui <decui(a)microsoft.com> I didn't really hit a real bug, but just happened to spot the bug: we have decreased the counter at the beginning of vmbus_process_offer(), so we mustn't decrease it again. Fixes: 6f3d791f3006 ("Drivers: hv: vmbus: Fix rescind handling issues") Signed-off-by: Dexuan Cui <decui(a)microsoft.com> Cc: stable(a)vger.kernel.org Cc: Stephen Hemminger <sthemmin(a)microsoft.com> Cc: K. Y. Srinivasan <kys(a)microsoft.com> Cc: Stable <stable(a)vger.kernel.org> # 4.14 and above Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com> --- drivers/hv/channel_mgmt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index ecc2bd275a73..f3b551a50653 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -527,10 +527,8 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel) struct hv_device *dev = newchannel->primary_channel->device_obj; - if (vmbus_add_channel_kobj(dev, newchannel)) { - atomic_dec(&vmbus_connection.offer_in_progress); + if (vmbus_add_channel_kobj(dev, newchannel)) goto err_free_chan; - } if (channel->sc_creation_callback != NULL) channel->sc_creation_callback(newchannel); -- 2.17.1

7 years

1
0
0 0

[Patch net v2] netdev-FAQ: clarify DaveM's position for stable backports

by Cong Wang

Per discussion with David at netconf 2018, let's clarify DaveM's position of handling stable backports in netdev-FAQ. This is important for people relying on upstream -stable releases. Cc: stable(a)vger.kernel.org Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> --- Documentation/networking/netdev-FAQ.txt | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt index 2a3278d5cf35..fa951b820b25 100644 --- a/Documentation/networking/netdev-FAQ.txt +++ b/Documentation/networking/netdev-FAQ.txt @@ -179,6 +179,15 @@ A: No. See above answer. In short, if you think it really belongs in dash marker line as described in Documentation/process/submitting-patches.rst to temporarily embed that information into the patch that you send. +Q: Are all networking bug fixes backported to all stable releases? + +A: Due to capacity, Dave could only take care of the backports for the last + 2 stable releases. For earlier stable releases, each stable branch maintainer + is supposed to take care of them. If you find any patch is missing from an + earlier stable branch, please notify stable(a)vger.kernel.org with either a + commit ID or a formal patch backported, and CC Dave and other relevant + networking developers. + Q: Someone said that the comment style and coding convention is different for the networking content. Is this true? -- 2.13.0

7 years

2
1
0 0

[PATCH v3 2/2] tpm: self test failure should not cause suspend to fail

by Jarkko Sakkinen

From: Chris Chiu <chiu(a)endlessm.com> commit 0803d7befa15cab5717d667a97a66214d2a4c083 upstream The Acer Acer Veriton X4110G has a TPM device detected as: tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71) After the first S3 suspend, the following error appears during resume: tpm tpm0: A TPM error(38) occurred continue selftest Any following S3 suspend attempts will now fail with this error: tpm tpm0: Error (38) sending savestate before suspend PM: Device 00:0b failed to suspend: error 38 Error 38 is TPM_ERR_INVALID_POSTINIT which means the TPM is not in the correct state. This indicates that the platform BIOS is not sending the usual TPM_Startup command during S3 resume. >From this point onwards, all TPM commands will fail. The same issue was previously reported on Foxconn 6150BK8MC and Sony Vaio TX3. The platform behaviour seems broken here, but we should not break suspend/resume because of this. When the unexpected TPM state is encountered, set a flag to skip the affected TPM_SaveState command on later suspends. Cc: stable(a)vger.kernel.org Signed-off-by: Chris Chiu <chiu(a)endlessm.com> Signed-off-by: Daniel Drake <drake(a)endlessm.com> Link: http://lkml.kernel.org/r/CAB4CAwfSCvj1cudi+MWaB5g2Z67d9DwY1o475YOZD64ma23Ui… Link: https://lkml.org/lkml/2011/3/28/192 Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591031 Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 247dd2b6504a..be0547115d34 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -787,6 +787,10 @@ int tpm_do_selftest(struct tpm_chip *chip) loops = jiffies_to_msecs(duration) / delay_msec; rc = tpm_continue_selftest(chip); + if (rc == TPM_ERR_INVALID_POSTINIT) { + chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED; + dev_info(&chip->dev, "TPM not ready (%d)\n", rc); + } /* This may fail if there was no TPM driver during a suspend/resume * cycle; some may return 10 (BAD_ORDINAL), others 28 (FAILEDSELFTEST) */ -- 2.17.0

7 years

1
0
0 0

[Patch net-next] netdev-FAQ: clarify DaveM's position for stable backports

by Cong Wang

Per discussion with David at netconf 2018, let's clarify DaveM's position of handling stable backports in netdev-FAQ. This is important for people relying on upstream -stable releases. Cc: stable(a)vger.kernel.org Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> --- Documentation/networking/netdev-FAQ.txt | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt index 2a3278d5cf35..6dde6686c870 100644 --- a/Documentation/networking/netdev-FAQ.txt +++ b/Documentation/networking/netdev-FAQ.txt @@ -179,6 +179,15 @@ A: No. See above answer. In short, if you think it really belongs in dash marker line as described in Documentation/process/submitting-patches.rst to temporarily embed that information into the patch that you send. +Q: Are all networking bug fixes backported to all stable releases? + +A: Due to capacity, Dave could only take care of the backports for the last + 3 stable releases. For earlier stable releases, each stable branch maintainer + is supposed to take care of them. If you find any patch is missing from an + earlier stable branch, please notify stable(a)vger.kernel.org with either a + commit ID or a formal patch backported, and CC Dave and other relevant + networking developers. + Q: Someone said that the comment style and coding convention is different for the networking content. Is this true? -- 2.13.0

7 years

3
3
0 0

[git:media_tree/master] media: uvcvideo: Prevent setting unavailable flags

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: uvcvideo: Prevent setting unavailable flags Author: Kieran Bingham <kieran.bingham(a)ideasonboard.com> Date: Wed Mar 21 11:43:08 2018 -0400 The addition of an extra operation to use the GET_INFO command overwrites all existing flags from the uvc_ctrls table. This includes setting all controls as supporting GET_MIN, GET_MAX, GET_RES, and GET_DEF regardless of whether they do or not. Move the initialisation of these control capabilities directly to the uvc_ctrl_fill_xu_info() call where they were originally located in that use case, and ensure that the new functionality in uvc_ctrl_get_flags() will only set flags based on their reported capability from the GET_INFO call. Fixes: 859086ae3636 ("media: uvcvideo: Apply flags from device to actual properties") Cc: stable(a)vger.kernel.org Signed-off-by: Kieran Bingham <kieran.bingham(a)ideasonboard.com> Tested-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)intel.com> Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> drivers/media/usb/uvc/uvc_ctrl.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) --- diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c index 102594ec3e97..a36b4fb949fa 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -1607,14 +1607,12 @@ static int uvc_ctrl_get_flags(struct uvc_device *dev, ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum, info->selector, data, 1); if (!ret) - info->flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX - | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF - | (data[0] & UVC_CONTROL_CAP_GET ? - UVC_CTRL_FLAG_GET_CUR : 0) - | (data[0] & UVC_CONTROL_CAP_SET ? - UVC_CTRL_FLAG_SET_CUR : 0) - | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ? - UVC_CTRL_FLAG_AUTO_UPDATE : 0); + info->flags |= (data[0] & UVC_CONTROL_CAP_GET ? + UVC_CTRL_FLAG_GET_CUR : 0) + | (data[0] & UVC_CONTROL_CAP_SET ? + UVC_CTRL_FLAG_SET_CUR : 0) + | (data[0] & UVC_CONTROL_CAP_AUTOUPDATE ? + UVC_CTRL_FLAG_AUTO_UPDATE : 0); kfree(data); return ret; @@ -1689,6 +1687,9 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev, info->size = le16_to_cpup((__le16 *)data); + info->flags = UVC_CTRL_FLAG_GET_MIN | UVC_CTRL_FLAG_GET_MAX + | UVC_CTRL_FLAG_GET_RES | UVC_CTRL_FLAG_GET_DEF; + ret = uvc_ctrl_get_flags(dev, ctrl, info); if (ret < 0) { uvc_trace(UVC_TRACE_CONTROL,

7 years

1
0
0 0

[PATCH] kconfig: Avoid format overflow warning from GCC 8.1

by Nathan Chancellor

In file included from scripts/kconfig/zconf.tab.c:2485: scripts/kconfig/confdata.c: In function ‘conf_write’: scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(newname, "%s%s", dirname, basename); ^~ scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes sprintf(newname, "%s%s", dirname, basename); ^~~~~~ scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097 sprintf(newname, "%s%s", dirname, basename); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~ scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097 sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Increase the size of tmpname and newname to make GCC happy. Cc: stable(a)vger.kernel.org Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> --- scripts/kconfig/confdata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c index 5f87ad561b08..39e20974f4a3 100644 --- a/scripts/kconfig/confdata.c +++ b/scripts/kconfig/confdata.c @@ -720,7 +720,7 @@ int conf_write(const char *name) struct menu *menu; const char *basename; const char *str; - char dirname[PATH_MAX+1], tmpname[PATH_MAX+1], newname[PATH_MAX+1]; + char dirname[PATH_MAX+1], tmpname[PATH_MAX+22], newname[PATH_MAX+8]; char *env; dirname[0] = 0; -- 2.17.1

7 years

2
1
0 0

Re: [patch 2/8] genirq/generic_pending: Do not lose pending affinity update

by Dou Liyang

Hi Thomas, At 06/04/2018 11:33 PM, Thomas Gleixner wrote: > The generic pending interrupt mechanism moves interrupts from the interrupt > handler on the original target CPU to the new destination CPU. This is > required for x86 and ia64 due to the way the interrupt delivery and > acknowledge works if the interrupts are not remapped. > > However that update can fail for various reasons. Some of them are valid > reasons to discard the pending update, but the case, when the previous move > has not been fully cleaned up is not a legit reason to fail. > > Check the return value of irq_do_set_affinity() for -EBUSY, which indicates > a pending cleanup, and rearm the pending move in the irq dexcriptor so it's s/dexcriptor/descriptor > tried again when the next interrupt arrives. > > Fixes: 996c591227d9 ("x86/irq: Plug vector cleanup race") > Signed-off-by: Thomas Gleixner<tglx(a)linutronix.de> > Cc:stable@vger.kernel.org > --- > kernel/irq/migration.c | 24 ++++++++++++++++++------ > 1 file changed, 18 insertions(+), 6 deletions(-) > > --- a/kernel/irq/migration.c > +++ b/kernel/irq/migration.c > @@ -38,17 +38,18 @@ bool irq_fixup_move_pending(struct irq_d > void irq_move_masked_irq(struct irq_data *idata) > { > struct irq_desc *desc = irq_data_to_desc(idata); > - struct irq_chip *chip = desc->irq_data.chip; > + struct irq_data *data = &desc->irq_data; > + struct irq_chip *chip = data->chip; > > - if (likely(!irqd_is_setaffinity_pending(&desc->irq_data))) > + if (likely(!irqd_is_setaffinity_pending(data))) > return; > > - irqd_clr_move_pending(&desc->irq_data); > + irqd_clr_move_pending(data); > > /* > * Paranoia: cpu-local interrupts shouldn't be calling in here anyway. > */ > - if (irqd_is_per_cpu(&desc->irq_data)) { > + if (irqd_is_per_cpu(data)) { > WARN_ON(1); > return; > } > @@ -73,9 +74,20 @@ void irq_move_masked_irq(struct irq_data > * For correct operation this depends on the caller > * masking the irqs. > */ > - if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids) > - irq_do_set_affinity(&desc->irq_data, desc->pending_mask, false); > + if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids) { > + int ret; > > + ret = irq_do_set_affinity(data, desc->pending_mask, false); > + /* > + * If the there is a cleanup pending in the underlying s/If the there is/If there is/ Thanks, dou

7 years

1
0
0 0

Re: [PATCH 4.9 00/29] 4.9.106-stable review

by Mark Brown

On Mon, Jun 04, 2018 at 04:13:06PM -0700, Kevin Hilman wrote: > > defconfig > > synquacer-acpi: 1 failed lab > This is a newly added board, and hasn't ever passed on v4.9 yet. > @Matt Hart: Is this board expected to work as far bask as v4.9? or > should we blacklist it? Should be blacklisted.

7 years

1
0
0 0

[PATCH v4.9-stable] serial: pl011: add console matching function

by Ard Biesheuvel

From: Aleksey Makarov <aleksey.makarov(a)linaro.org> Commit 10879ae5f12e9cab3c4e8e9504c1aaa8a033bde7 upstream. This patch adds function pl011_console_match() that implements method match of struct console. It allows to match consoles against data specified in a string, for example taken from command line or compiled by ACPI SPCR table handler. This patch was merged to tty-next but then reverted because of conflict with commit 46e36683f433 ("serial: earlycon: Extend earlycon command line option to support 64-bit addresses") Now it is fixed. Signed-off-by: Aleksey Makarov <aleksey.makarov(a)linaro.org> Reviewed-by: Peter Hurley <peter(a)hurleysoftware.com> Acked-by: Russell King <rmk+kernel(a)armlinux.org.uk> Tested-by: Christopher Covington <cov(a)codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> --- Please consider for v4.9-stable. It is the missing puzzle piece for SPCR support on arm64 ACPI systems, which got merged for v4.9 [0]. Now that more systems are becoming available to people working in the kernel community, it turns out that v4.9 distro installers (e.g., Debian Stretch) won't work unless you pass a 'console=' parameter explicitly, which is annoying. Given that it was clearly the intent to include this code at the time, I hope it will be considered for backporting. [0] To quote the tty maintainer: Also in here is the long-suffering ACPI SPCR patchset, which was passed around from maintainer to maintainer like a hot-potato. Seems I was the sucker^Wlucky one. All of those patches have been acked by the various subsystem maintainers as well. drivers/tty/serial/amba-pl011.c | 55 ++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c index b42d7f1c9089..6b1863293fe1 100644 --- a/drivers/tty/serial/amba-pl011.c +++ b/drivers/tty/serial/amba-pl011.c @@ -2320,12 +2320,67 @@ static int __init pl011_console_setup(struct console *co, char *options) return uart_set_options(&uap->port, co, baud, parity, bits, flow); } +/** + * pl011_console_match - non-standard console matching + * @co: registering console + * @name: name from console command line + * @idx: index from console command line + * @options: ptr to option string from console command line + * + * Only attempts to match console command lines of the form: + * console=pl011,mmio|mmio32,<addr>[,<options>] + * console=pl011,0x<addr>[,<options>] + * This form is used to register an initial earlycon boot console and + * replace it with the amba_console at pl011 driver init. + * + * Performs console setup for a match (as required by interface) + * If no <options> are specified, then assume the h/w is already setup. + * + * Returns 0 if console matches; otherwise non-zero to use default matching + */ +static int __init pl011_console_match(struct console *co, char *name, int idx, + char *options) +{ + unsigned char iotype; + resource_size_t addr; + int i; + + if (strcmp(name, "pl011") != 0) + return -ENODEV; + + if (uart_parse_earlycon(options, &iotype, &addr, &options)) + return -ENODEV; + + if (iotype != UPIO_MEM && iotype != UPIO_MEM32) + return -ENODEV; + + /* try to match the port specified on the command line */ + for (i = 0; i < ARRAY_SIZE(amba_ports); i++) { + struct uart_port *port; + + if (!amba_ports[i]) + continue; + + port = &amba_ports[i]->port; + + if (port->mapbase != addr) + continue; + + co->index = i; + port->cons = co; + return pl011_console_setup(co, options); + } + + return -ENODEV; +} + static struct uart_driver amba_reg; static struct console amba_console = { .name = "ttyAMA", .write = pl011_console_write, .device = uart_console_device, .setup = pl011_console_setup, + .match = pl011_console_match, .flags = CON_PRINTBUFFER, .index = -1, .data = &amba_reg, -- 2.17.0

7 years

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2018