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

[Linux-stable-mirror] Patch "thermal/drivers/hisi: Simplify the temperature/step computation" 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 thermal/drivers/hisi: Simplify the temperature/step computation 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: thermal-drivers-hisi-simplify-the-temperature-step-computation.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 48880b979cdc9ef5a70af020f42b8ba1e51dbd34 Mon Sep 17 00:00:00 2001 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:46 +0200 Subject: thermal/drivers/hisi: Simplify the temperature/step computation From: Daniel Lezcano <daniel.lezcano(a)linaro.org> commit 48880b979cdc9ef5a70af020f42b8ba1e51dbd34 upstream. The step and the base temperature are fixed values, we can simplify the computation by converting the base temperature to milli celsius and use a pre-computed step value. That saves us a lot of mult + div for nothing at runtime. Take also the opportunity to change the function names to be consistent with the rest of the code. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Reviewed-by: Leo Yan <leo.yan(a)linaro.org> Tested-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 41 ++++++++++++++++++++++++++++------------- 1 file changed, 28 insertions(+), 13 deletions(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -35,8 +35,9 @@ #define TEMP0_RST_MSK (0x1C) #define TEMP0_VALUE (0x28) -#define HISI_TEMP_BASE (-60) +#define HISI_TEMP_BASE (-60000) #define HISI_TEMP_RESET (100000) +#define HISI_TEMP_STEP (784) #define HISI_MAX_SENSORS 4 @@ -61,19 +62,32 @@ struct hisi_thermal_data { void __iomem *regs; }; -/* in millicelsius */ -static inline int _step_to_temp(int step) +/* + * The temperature computation on the tsensor is as follow: + * Unit: millidegree Celsius + * Step: 255/200 (0.7843) + * Temperature base: -60°C + * + * The register is programmed in temperature steps, every step is 784 + * millidegree and begins at -60 000 m°C + * + * The temperature from the steps: + * + * Temp = TempBase + (steps x 784) + * + * and the steps from the temperature: + * + * steps = (Temp - TempBase) / 784 + * + */ +static inline int hisi_thermal_step_to_temp(int step) { - /* - * Every step equals (1 * 200) / 255 celsius, and finally - * need convert to millicelsius. - */ - return (HISI_TEMP_BASE * 1000 + (step * 200000 / 255)); + return HISI_TEMP_BASE + (step * HISI_TEMP_STEP); } -static inline long _temp_to_step(long temp) +static inline long hisi_thermal_temp_to_step(long temp) { - return ((temp - HISI_TEMP_BASE * 1000) * 255) / 200000; + return (temp - HISI_TEMP_BASE) / HISI_TEMP_STEP; } static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data, @@ -99,7 +113,7 @@ static long hisi_thermal_get_sensor_temp usleep_range(3000, 5000); val = readl(data->regs + TEMP0_VALUE); - val = _step_to_temp(val); + val = hisi_thermal_step_to_temp(val); mutex_unlock(&data->thermal_lock); @@ -126,10 +140,11 @@ static void hisi_thermal_enable_bind_irq writel((sensor->id << 12), data->regs + TEMP0_CFG); /* enable for interrupt */ - writel(_temp_to_step(sensor->thres_temp) | 0x0FFFFFF00, + writel(hisi_thermal_temp_to_step(sensor->thres_temp) | 0x0FFFFFF00, data->regs + TEMP0_TH); - writel(_temp_to_step(HISI_TEMP_RESET), data->regs + TEMP0_RST_TH); + writel(hisi_thermal_temp_to_step(HISI_TEMP_RESET), + data->regs + TEMP0_RST_TH); /* enable module */ writel(0x1, data->regs + TEMP0_RST_MSK); Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-4.9/thermal-drivers-hisi-fix-kernel-panic-on-alarm-interrupt.patch queue-4.9/thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.patch queue-4.9/thermal-drivers-hisi-simplify-the-temperature-step-computation.patch queue-4.9/thermal-drivers-hisi-fix-missing-interrupt-enablement.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal/drivers/hisi: Simplify the temperature/step computation" 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 thermal/drivers/hisi: Simplify the temperature/step computation 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: thermal-drivers-hisi-simplify-the-temperature-step-computation.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 48880b979cdc9ef5a70af020f42b8ba1e51dbd34 Mon Sep 17 00:00:00 2001 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:46 +0200 Subject: thermal/drivers/hisi: Simplify the temperature/step computation From: Daniel Lezcano <daniel.lezcano(a)linaro.org> commit 48880b979cdc9ef5a70af020f42b8ba1e51dbd34 upstream. The step and the base temperature are fixed values, we can simplify the computation by converting the base temperature to milli celsius and use a pre-computed step value. That saves us a lot of mult + div for nothing at runtime. Take also the opportunity to change the function names to be consistent with the rest of the code. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Reviewed-by: Leo Yan <leo.yan(a)linaro.org> Tested-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 41 ++++++++++++++++++++++++++++------------- 1 file changed, 28 insertions(+), 13 deletions(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -35,8 +35,9 @@ #define TEMP0_RST_MSK (0x1C) #define TEMP0_VALUE (0x28) -#define HISI_TEMP_BASE (-60) +#define HISI_TEMP_BASE (-60000) #define HISI_TEMP_RESET (100000) +#define HISI_TEMP_STEP (784) #define HISI_MAX_SENSORS 4 @@ -61,19 +62,32 @@ struct hisi_thermal_data { void __iomem *regs; }; -/* in millicelsius */ -static inline int _step_to_temp(int step) +/* + * The temperature computation on the tsensor is as follow: + * Unit: millidegree Celsius + * Step: 255/200 (0.7843) + * Temperature base: -60°C + * + * The register is programmed in temperature steps, every step is 784 + * millidegree and begins at -60 000 m°C + * + * The temperature from the steps: + * + * Temp = TempBase + (steps x 784) + * + * and the steps from the temperature: + * + * steps = (Temp - TempBase) / 784 + * + */ +static inline int hisi_thermal_step_to_temp(int step) { - /* - * Every step equals (1 * 200) / 255 celsius, and finally - * need convert to millicelsius. - */ - return (HISI_TEMP_BASE * 1000 + (step * 200000 / 255)); + return HISI_TEMP_BASE + (step * HISI_TEMP_STEP); } -static inline long _temp_to_step(long temp) +static inline long hisi_thermal_temp_to_step(long temp) { - return ((temp - HISI_TEMP_BASE * 1000) * 255) / 200000; + return (temp - HISI_TEMP_BASE) / HISI_TEMP_STEP; } static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data, @@ -99,7 +113,7 @@ static long hisi_thermal_get_sensor_temp usleep_range(3000, 5000); val = readl(data->regs + TEMP0_VALUE); - val = _step_to_temp(val); + val = hisi_thermal_step_to_temp(val); mutex_unlock(&data->thermal_lock); @@ -126,10 +140,11 @@ static void hisi_thermal_enable_bind_irq writel((sensor->id << 12), data->regs + TEMP0_CFG); /* enable for interrupt */ - writel(_temp_to_step(sensor->thres_temp) | 0x0FFFFFF00, + writel(hisi_thermal_temp_to_step(sensor->thres_temp) | 0x0FFFFFF00, data->regs + TEMP0_TH); - writel(_temp_to_step(HISI_TEMP_RESET), data->regs + TEMP0_RST_TH); + writel(hisi_thermal_temp_to_step(HISI_TEMP_RESET), + data->regs + TEMP0_RST_TH); /* enable module */ writel(0x1, data->regs + TEMP0_RST_MSK); Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-4.14/thermal-drivers-hisi-fix-kernel-panic-on-alarm-interrupt.patch queue-4.14/thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.patch queue-4.14/thermal-drivers-hisi-simplify-the-temperature-step-computation.patch queue-4.14/thermal-drivers-hisi-fix-missing-interrupt-enablement.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] [PATCH 3/3] usb: xhci: Add XHCI_TRUST_TX_LENGTH for Renesas uPD720201

by Mathias Nyman

From: Daniel Thompson <daniel.thompson(a)linaro.org> When plugging in a USB webcam I see the following message: xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? handle_tx_event: 913 callbacks suppressed All is quiet again with this patch (and I've done a fair but of soak testing with the camera since). Cc: <stable(a)vger.kernel.org> Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-pci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 7ef1274..1aad89b 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -178,6 +178,9 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) xhci->quirks |= XHCI_BROKEN_STREAMS; } if (pdev->vendor == PCI_VENDOR_ID_RENESAS && + pdev->device == 0x0014) + xhci->quirks |= XHCI_TRUST_TX_LENGTH; + if (pdev->vendor == PCI_VENDOR_ID_RENESAS && pdev->device == 0x0015) xhci->quirks |= XHCI_RESET_ON_RESUME; if (pdev->vendor == PCI_VENDOR_ID_VIA) -- 2.7.4

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] [PATCH] tools/gpio: Fix build error with musl libc

by Joel Stanley

The GPIO tools build fails when using a buildroot toolchain that uses musl as it's C library: arm-broomstick-linux-musleabi-gcc -Wp,-MD,./.gpio-event-mon.o.d \ -Wp,-MT,gpio-event-mon.o -O2 -Wall -g -D_GNU_SOURCE \ -Iinclude -D"BUILD_STR(s)=#s" -c -o gpio-event-mon.o gpio-event-mon.c gpio-event-mon.c:30:6: error: unknown type name ‘u_int32_t’; did you mean ‘uint32_t’? u_int32_t handleflags, ^~~~~~~~~ uint32_t The glibc headers installed on my laptop include sys/types.h in unistd.h, but it appears that musl does not. Fixes: 97f69747d8b1 ("tools/gpio: add the gpio-event-mon tool") Cc: stable(a)vger.kernel.org Signed-off-by: Joel Stanley <joel(a)jms.id.au> --- tools/gpio/gpio-event-mon.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c index 1c14c2595158..4b36323ea64b 100644 --- a/tools/gpio/gpio-event-mon.c +++ b/tools/gpio/gpio-event-mon.c @@ -23,6 +23,7 @@ #include <getopt.h> #include <inttypes.h> #include <sys/ioctl.h> +#include <sys/types.h> #include <linux/gpio.h> int monitor_device(const char *device_name, -- 2.15.1

7 years, 10 months

2
1
0 0

[Linux-stable-mirror] Patch "thermal/drivers/hisi: Fix multiple alarm interrupts firing" 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 thermal/drivers/hisi: Fix multiple alarm interrupts firing 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: thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.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 db2b0332608c8e648ea1e44727d36ad37cdb56cb Mon Sep 17 00:00:00 2001 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:47 +0200 Subject: thermal/drivers/hisi: Fix multiple alarm interrupts firing From: Daniel Lezcano <daniel.lezcano(a)linaro.org> commit db2b0332608c8e648ea1e44727d36ad37cdb56cb upstream. The DT specifies a threshold of 65000, we setup the register with a value in the temperature resolution for the controller, 64656. When we reach 64656, the interrupt fires, the interrupt is disabled. Then the irq thread runs and calls thermal_zone_device_update() which will call in turn hisi_thermal_get_temp(). The function will look if the temperature decreased, assuming it was more than 65000, but that is not the case because the current temperature is 64656 (because of the rounding when setting the threshold). This condition being true, we re-enable the interrupt which fires immediately after exiting the irq thread. That happens again and again until the temperature goes to more than 65000. Potentially, there is here an interrupt storm if the temperature stabilizes at this temperature. A very unlikely case but possible. In any case, it does not make sense to handle dozens of alarm interrupt for nothing. Fix this by rounding the threshold value to the controller resolution so the check against the threshold is consistent with the one set in the controller. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Reviewed-by: Leo Yan <leo.yan(a)linaro.org> Tested-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -76,6 +76,12 @@ static inline long _temp_to_step(long te return ((temp - HISI_TEMP_BASE * 1000) * 255) / 200000; } +static inline long hisi_thermal_round_temp(int temp) +{ + return hisi_thermal_step_to_temp( + hisi_thermal_temp_to_step(temp)); +} + static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data, struct hisi_thermal_sensor *sensor) { @@ -230,7 +236,7 @@ static irqreturn_t hisi_thermal_alarm_ir sensor = &data->sensors[data->irq_bind_sensor]; dev_crit(&data->pdev->dev, "THERMAL ALARM: T > %d\n", - sensor->thres_temp / 1000); + sensor->thres_temp); mutex_unlock(&data->thermal_lock); for (i = 0; i < HISI_MAX_SENSORS; i++) { @@ -269,7 +275,7 @@ static int hisi_thermal_register_sensor( for (i = 0; i < of_thermal_get_ntrips(sensor->tzd); i++) { if (trip[i].type == THERMAL_TRIP_PASSIVE) { - sensor->thres_temp = trip[i].temperature; + sensor->thres_temp = hisi_thermal_round_temp(trip[i].temperature); break; } } Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-4.9/thermal-drivers-hisi-fix-kernel-panic-on-alarm-interrupt.patch queue-4.9/thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.patch queue-4.9/thermal-drivers-hisi-fix-missing-interrupt-enablement.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal: hisilicon: Handle return value of clk_prepare_enable" 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 thermal: hisilicon: Handle return value of clk_prepare_enable 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: thermal-hisilicon-handle-return-value-of-clk_prepare_enable.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 919054fdfc8adf58c5512fe9872eb53ea0f5525d Mon Sep 17 00:00:00 2001 From: Arvind Yadav <arvind.yadav.cs(a)gmail.com> Date: Tue, 6 Jun 2017 15:04:46 +0530 Subject: thermal: hisilicon: Handle return value of clk_prepare_enable From: Arvind Yadav <arvind.yadav.cs(a)gmail.com> commit 919054fdfc8adf58c5512fe9872eb53ea0f5525d upstream. clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -397,8 +397,11 @@ static int hisi_thermal_suspend(struct d static int hisi_thermal_resume(struct device *dev) { struct hisi_thermal_data *data = dev_get_drvdata(dev); + int ret; - clk_prepare_enable(data->clk); + ret = clk_prepare_enable(data->clk); + if (ret) + return ret; data->irq_enabled = true; hisi_thermal_enable_bind_irq_sensor(data); Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are queue-4.9/thermal-hisilicon-handle-return-value-of-clk_prepare_enable.patch queue-4.9/staging-greybus-light-release-memory-obtained-by-kasprintf.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal/drivers/hisi: Fix missing interrupt enablement" 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 thermal/drivers/hisi: Fix missing interrupt enablement 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: thermal-drivers-hisi-fix-missing-interrupt-enablement.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 c176b10b025acee4dc8f2ab1cd64eb73b5ccef53 Mon Sep 17 00:00:00 2001 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:43 +0200 Subject: thermal/drivers/hisi: Fix missing interrupt enablement From: Daniel Lezcano <daniel.lezcano(a)linaro.org> commit c176b10b025acee4dc8f2ab1cd64eb73b5ccef53 upstream. The interrupt for the temperature threshold is not enabled at the end of the probe function, enable it after the setup is complete. On the other side, the irq_enabled is not correctly set as we are checking if the interrupt is masked where 'yes' means irq_enabled=false. irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED, &data->irq_enabled); As we are always enabling the interrupt, it is pointless to check if the interrupt is masked or not, just set irq_enabled to 'true'. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Reviewed-by: Leo Yan <leo.yan(a)linaro.org> Tested-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -345,8 +345,7 @@ static int hisi_thermal_probe(struct pla } hisi_thermal_enable_bind_irq_sensor(data); - irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED, - &data->irq_enabled); + data->irq_enabled = true; for (i = 0; i < HISI_MAX_SENSORS; ++i) { ret = hisi_thermal_register_sensor(pdev, data, @@ -358,6 +357,8 @@ static int hisi_thermal_probe(struct pla hisi_thermal_toggle_sensor(&data->sensors[i], true); } + enable_irq(data->irq); + return 0; } Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-4.9/thermal-drivers-hisi-fix-kernel-panic-on-alarm-interrupt.patch queue-4.9/thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.patch queue-4.9/thermal-drivers-hisi-fix-missing-interrupt-enablement.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal/drivers/hisi: Fix kernel panic on alarm interrupt" 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 thermal/drivers/hisi: Fix kernel panic on alarm interrupt 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: thermal-drivers-hisi-fix-kernel-panic-on-alarm-interrupt.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 2cb4de785c40d4a2132cfc13e63828f5a28c3351 Mon Sep 17 00:00:00 2001 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:45 +0200 Subject: thermal/drivers/hisi: Fix kernel panic on alarm interrupt From: Daniel Lezcano <daniel.lezcano(a)linaro.org> commit 2cb4de785c40d4a2132cfc13e63828f5a28c3351 upstream. The threaded interrupt for the alarm interrupt is requested before the temperature controller is setup. This one can fire an interrupt immediately leading to a kernel panic as the sensor data is not initialized. In order to prevent that, move the threaded irq after the Tsensor is setup. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Reviewed-by: Leo Yan <leo.yan(a)linaro.org> Tested-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -317,15 +317,6 @@ static int hisi_thermal_probe(struct pla if (data->irq < 0) return data->irq; - ret = devm_request_threaded_irq(&pdev->dev, data->irq, - hisi_thermal_alarm_irq, - hisi_thermal_alarm_irq_thread, - 0, "hisi_thermal", data); - if (ret < 0) { - dev_err(&pdev->dev, "failed to request alarm irq: %d\n", ret); - return ret; - } - platform_set_drvdata(pdev, data); data->clk = devm_clk_get(&pdev->dev, "thermal_clk"); @@ -357,6 +348,15 @@ static int hisi_thermal_probe(struct pla hisi_thermal_toggle_sensor(&data->sensors[i], true); } + ret = devm_request_threaded_irq(&pdev->dev, data->irq, + hisi_thermal_alarm_irq, + hisi_thermal_alarm_irq_thread, + 0, "hisi_thermal", data); + if (ret < 0) { + dev_err(&pdev->dev, "failed to request alarm irq: %d\n", ret); + return ret; + } + enable_irq(data->irq); return 0; Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-4.9/thermal-drivers-hisi-fix-kernel-panic-on-alarm-interrupt.patch queue-4.9/thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.patch queue-4.9/thermal-drivers-hisi-fix-missing-interrupt-enablement.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal: hisilicon: Handle return value of clk_prepare_enable" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled thermal: hisilicon: Handle return value of clk_prepare_enable to the 4.4-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: thermal-hisilicon-handle-return-value-of-clk_prepare_enable.patch and it can be found in the queue-4.4 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 919054fdfc8adf58c5512fe9872eb53ea0f5525d Mon Sep 17 00:00:00 2001 From: Arvind Yadav <arvind.yadav.cs(a)gmail.com> Date: Tue, 6 Jun 2017 15:04:46 +0530 Subject: thermal: hisilicon: Handle return value of clk_prepare_enable From: Arvind Yadav <arvind.yadav.cs(a)gmail.com> commit 919054fdfc8adf58c5512fe9872eb53ea0f5525d upstream. clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -389,8 +389,11 @@ static int hisi_thermal_suspend(struct d static int hisi_thermal_resume(struct device *dev) { struct hisi_thermal_data *data = dev_get_drvdata(dev); + int ret; - clk_prepare_enable(data->clk); + ret = clk_prepare_enable(data->clk); + if (ret) + return ret; data->irq_enabled = true; hisi_thermal_enable_bind_irq_sensor(data); Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are queue-4.4/thermal-hisilicon-handle-return-value-of-clk_prepare_enable.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal/drivers/hisi: Fix multiple alarm interrupts firing" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled thermal/drivers/hisi: Fix multiple alarm interrupts firing to the 4.4-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: thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.patch and it can be found in the queue-4.4 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 db2b0332608c8e648ea1e44727d36ad37cdb56cb Mon Sep 17 00:00:00 2001 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:47 +0200 Subject: thermal/drivers/hisi: Fix multiple alarm interrupts firing From: Daniel Lezcano <daniel.lezcano(a)linaro.org> commit db2b0332608c8e648ea1e44727d36ad37cdb56cb upstream. The DT specifies a threshold of 65000, we setup the register with a value in the temperature resolution for the controller, 64656. When we reach 64656, the interrupt fires, the interrupt is disabled. Then the irq thread runs and calls thermal_zone_device_update() which will call in turn hisi_thermal_get_temp(). The function will look if the temperature decreased, assuming it was more than 65000, but that is not the case because the current temperature is 64656 (because of the rounding when setting the threshold). This condition being true, we re-enable the interrupt which fires immediately after exiting the irq thread. That happens again and again until the temperature goes to more than 65000. Potentially, there is here an interrupt storm if the temperature stabilizes at this temperature. A very unlikely case but possible. In any case, it does not make sense to handle dozens of alarm interrupt for nothing. Fix this by rounding the threshold value to the controller resolution so the check against the threshold is consistent with the one set in the controller. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Reviewed-by: Leo Yan <leo.yan(a)linaro.org> Tested-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -76,6 +76,12 @@ static inline long _temp_to_step(long te return ((temp / 1000 - HISI_TEMP_BASE) * 255 / 200); } +static inline long hisi_thermal_round_temp(int temp) +{ + return hisi_thermal_step_to_temp( + hisi_thermal_temp_to_step(temp)); +} + static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data, struct hisi_thermal_sensor *sensor) { @@ -223,7 +229,7 @@ static irqreturn_t hisi_thermal_alarm_ir sensor = &data->sensors[data->irq_bind_sensor]; dev_crit(&data->pdev->dev, "THERMAL ALARM: T > %d\n", - sensor->thres_temp / 1000); + sensor->thres_temp); mutex_unlock(&data->thermal_lock); for (i = 0; i < HISI_MAX_SENSORS; i++) @@ -256,7 +262,7 @@ static int hisi_thermal_register_sensor( for (i = 0; i < of_thermal_get_ntrips(sensor->tzd); i++) { if (trip[i].type == THERMAL_TRIP_PASSIVE) { - sensor->thres_temp = trip[i].temperature; + sensor->thres_temp = hisi_thermal_round_temp(trip[i].temperature); break; } } Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-4.4/thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal/drivers/hisi: Fix multiple alarm interrupts firing" 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 thermal/drivers/hisi: Fix multiple alarm interrupts firing 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: thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.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 db2b0332608c8e648ea1e44727d36ad37cdb56cb Mon Sep 17 00:00:00 2001 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:47 +0200 Subject: thermal/drivers/hisi: Fix multiple alarm interrupts firing From: Daniel Lezcano <daniel.lezcano(a)linaro.org> commit db2b0332608c8e648ea1e44727d36ad37cdb56cb upstream. The DT specifies a threshold of 65000, we setup the register with a value in the temperature resolution for the controller, 64656. When we reach 64656, the interrupt fires, the interrupt is disabled. Then the irq thread runs and calls thermal_zone_device_update() which will call in turn hisi_thermal_get_temp(). The function will look if the temperature decreased, assuming it was more than 65000, but that is not the case because the current temperature is 64656 (because of the rounding when setting the threshold). This condition being true, we re-enable the interrupt which fires immediately after exiting the irq thread. That happens again and again until the temperature goes to more than 65000. Potentially, there is here an interrupt storm if the temperature stabilizes at this temperature. A very unlikely case but possible. In any case, it does not make sense to handle dozens of alarm interrupt for nothing. Fix this by rounding the threshold value to the controller resolution so the check against the threshold is consistent with the one set in the controller. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Reviewed-by: Leo Yan <leo.yan(a)linaro.org> Tested-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -76,6 +76,12 @@ static inline long _temp_to_step(long te return ((temp - HISI_TEMP_BASE * 1000) * 255) / 200000; } +static inline long hisi_thermal_round_temp(int temp) +{ + return hisi_thermal_step_to_temp( + hisi_thermal_temp_to_step(temp)); +} + static long hisi_thermal_get_sensor_temp(struct hisi_thermal_data *data, struct hisi_thermal_sensor *sensor) { @@ -230,7 +236,7 @@ static irqreturn_t hisi_thermal_alarm_ir sensor = &data->sensors[data->irq_bind_sensor]; dev_crit(&data->pdev->dev, "THERMAL ALARM: T > %d\n", - sensor->thres_temp / 1000); + sensor->thres_temp); mutex_unlock(&data->thermal_lock); for (i = 0; i < HISI_MAX_SENSORS; i++) { @@ -269,7 +275,7 @@ static int hisi_thermal_register_sensor( for (i = 0; i < of_thermal_get_ntrips(sensor->tzd); i++) { if (trip[i].type == THERMAL_TRIP_PASSIVE) { - sensor->thres_temp = trip[i].temperature; + sensor->thres_temp = hisi_thermal_round_temp(trip[i].temperature); break; } } Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-4.14/thermal-drivers-hisi-fix-kernel-panic-on-alarm-interrupt.patch queue-4.14/thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.patch queue-4.14/thermal-drivers-hisi-fix-missing-interrupt-enablement.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal/drivers/hisi: Fix kernel panic on alarm interrupt" 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 thermal/drivers/hisi: Fix kernel panic on alarm interrupt 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: thermal-drivers-hisi-fix-kernel-panic-on-alarm-interrupt.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 2cb4de785c40d4a2132cfc13e63828f5a28c3351 Mon Sep 17 00:00:00 2001 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:45 +0200 Subject: thermal/drivers/hisi: Fix kernel panic on alarm interrupt From: Daniel Lezcano <daniel.lezcano(a)linaro.org> commit 2cb4de785c40d4a2132cfc13e63828f5a28c3351 upstream. The threaded interrupt for the alarm interrupt is requested before the temperature controller is setup. This one can fire an interrupt immediately leading to a kernel panic as the sensor data is not initialized. In order to prevent that, move the threaded irq after the Tsensor is setup. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Reviewed-by: Leo Yan <leo.yan(a)linaro.org> Tested-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -317,15 +317,6 @@ static int hisi_thermal_probe(struct pla if (data->irq < 0) return data->irq; - ret = devm_request_threaded_irq(&pdev->dev, data->irq, - hisi_thermal_alarm_irq, - hisi_thermal_alarm_irq_thread, - 0, "hisi_thermal", data); - if (ret < 0) { - dev_err(&pdev->dev, "failed to request alarm irq: %d\n", ret); - return ret; - } - platform_set_drvdata(pdev, data); data->clk = devm_clk_get(&pdev->dev, "thermal_clk"); @@ -357,6 +348,15 @@ static int hisi_thermal_probe(struct pla hisi_thermal_toggle_sensor(&data->sensors[i], true); } + ret = devm_request_threaded_irq(&pdev->dev, data->irq, + hisi_thermal_alarm_irq, + hisi_thermal_alarm_irq_thread, + 0, "hisi_thermal", data); + if (ret < 0) { + dev_err(&pdev->dev, "failed to request alarm irq: %d\n", ret); + return ret; + } + enable_irq(data->irq); return 0; Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-4.14/thermal-drivers-hisi-fix-kernel-panic-on-alarm-interrupt.patch queue-4.14/thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.patch queue-4.14/thermal-drivers-hisi-fix-missing-interrupt-enablement.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "thermal/drivers/hisi: Fix missing interrupt enablement" 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 thermal/drivers/hisi: Fix missing interrupt enablement 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: thermal-drivers-hisi-fix-missing-interrupt-enablement.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 c176b10b025acee4dc8f2ab1cd64eb73b5ccef53 Mon Sep 17 00:00:00 2001 From: Daniel Lezcano <daniel.lezcano(a)linaro.org> Date: Thu, 19 Oct 2017 19:05:43 +0200 Subject: thermal/drivers/hisi: Fix missing interrupt enablement From: Daniel Lezcano <daniel.lezcano(a)linaro.org> commit c176b10b025acee4dc8f2ab1cd64eb73b5ccef53 upstream. The interrupt for the temperature threshold is not enabled at the end of the probe function, enable it after the setup is complete. On the other side, the irq_enabled is not correctly set as we are checking if the interrupt is masked where 'yes' means irq_enabled=false. irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED, &data->irq_enabled); As we are always enabling the interrupt, it is pointless to check if the interrupt is masked or not, just set irq_enabled to 'true'. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> Reviewed-by: Leo Yan <leo.yan(a)linaro.org> Tested-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Kevin Wangtao <kevin.wangtao(a)hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/thermal/hisi_thermal.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/thermal/hisi_thermal.c +++ b/drivers/thermal/hisi_thermal.c @@ -345,8 +345,7 @@ static int hisi_thermal_probe(struct pla } hisi_thermal_enable_bind_irq_sensor(data); - irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED, - &data->irq_enabled); + data->irq_enabled = true; for (i = 0; i < HISI_MAX_SENSORS; ++i) { ret = hisi_thermal_register_sensor(pdev, data, @@ -358,6 +357,8 @@ static int hisi_thermal_probe(struct pla hisi_thermal_toggle_sensor(&data->sensors[i], true); } + enable_irq(data->irq); + return 0; } Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are queue-4.14/thermal-drivers-hisi-fix-kernel-panic-on-alarm-interrupt.patch queue-4.14/thermal-drivers-hisi-fix-multiple-alarm-interrupts-firing.patch queue-4.14/thermal-drivers-hisi-fix-missing-interrupt-enablement.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] [PATCH] drop percpu-don-t-forget-to-free-the-temporary-struct-pcpu_alloc_info.patch

by alexander.levin＠verizon.com

Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- ...free-the-temporary-struct-pcpu_alloc_info.patch | 43 ---------------------- queue-4.14/series | 1 - 2 files changed, 44 deletions(-) delete mode 100644 queue-4.14/percpu-don-t-forget-to-free-the-temporary-struct-pcpu_alloc_info.patch diff --git a/queue-4.14/percpu-don-t-forget-to-free-the-temporary-struct-pcpu_alloc_info.patch b/queue-4.14/percpu-don-t-forget-to-free-the-temporary-struct-pcpu_alloc_info.patch deleted file mode 100644 index 3f5b55599..000000000 --- a/queue-4.14/percpu-don-t-forget-to-free-the-temporary-struct-pcpu_alloc_info.patch +++ /dev/null @@ -1,43 +0,0 @@ -From foo@baz Wed Dec 20 18:17:52 CET 2017 -From: Nicolas Pitre <nicolas.pitre(a)linaro.org> -Date: Tue, 3 Oct 2017 18:29:49 -0400 -Subject: percpu: don't forget to free the temporary struct pcpu_alloc_info - -From: Nicolas Pitre <nicolas.pitre(a)linaro.org> - - -[ Upstream commit 438a50618095061920d3a30d4c5ca1ef2e0ff860 ] - -Unlike the SMP case, the !SMP case does not free the memory for struct -pcpu_alloc_info allocated in setup_per_cpu_areas(). And to give it a -chance of being reused by the page allocator later, align it to a page -boundary just like its size. - -Signed-off-by: Nicolas Pitre <nico(a)linaro.org> -Acked-by: Dennis Zhou <dennisszhou(a)gmail.com> -Signed-off-by: Tejun Heo <tj(a)kernel.org> -Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> -Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> ---- - mm/percpu.c | 3 ++- - 1 file changed, 2 insertions(+), 1 deletion(-) - ---- a/mm/percpu.c -+++ b/mm/percpu.c -@@ -1856,7 +1856,7 @@ struct pcpu_alloc_info * __init pcpu_all - __alignof__(ai->groups[0].cpu_map[0])); - ai_size = base_size + nr_units * sizeof(ai->groups[0].cpu_map[0]); - -- ptr = memblock_virt_alloc_nopanic(PFN_ALIGN(ai_size), 0); -+ ptr = memblock_virt_alloc_nopanic(PFN_ALIGN(ai_size), PAGE_SIZE); - if (!ptr) - return NULL; - ai = ptr; -@@ -2719,6 +2719,7 @@ void __init setup_per_cpu_areas(void) - - if (pcpu_setup_first_chunk(ai, fc) < 0) - panic("Failed to initialize percpu areas."); -+ pcpu_free_alloc_info(ai); - } - - #endif /* CONFIG_SMP */ diff --git a/queue-4.14/series b/queue-4.14/series index 45ea08c57..57c224e24 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -35,7 +35,6 @@ bluetooth-hci_bcm-fix-setting-of-irq-trigger-type.patch i40e-i40evf-spread-cpu-affinity-hints-across-online-cpus-only.patch pci-aer-report-non-fatal-errors-only-to-the-affected-endpoint.patch tracing-exclude-generic-fields-from-histograms.patch -percpu-don-t-forget-to-free-the-temporary-struct-pcpu_alloc_info.patch asoc-codecs-msm8916-wcd-analog-fix-micbias-level.patch asoc-img-parallel-out-add-pm_runtime_get-put-to-set_fmt-callback.patch powerpc-xmon-avoid-tripping-smp-hardlockup-watchdog.patch -- 2.11.0

7 years, 10 months

2
1
0 0

[Linux-stable-mirror] Patch "usb: gadget: f_uvc: Sanity check wMaxPacketSize for SuperSpeed" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: f_uvc: Sanity check wMaxPacketSize for SuperSpeed to the 3.18-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: usb-gadget-f_uvc-sanity-check-wmaxpacketsize-for-superspeed.patch and it can be found in the queue-3.18 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 foo@baz Thu Dec 21 10:55:04 CET 2017 From: Roger Quadros <rogerq(a)ti.com> Date: Wed, 8 Mar 2017 16:05:44 +0200 Subject: usb: gadget: f_uvc: Sanity check wMaxPacketSize for SuperSpeed From: Roger Quadros <rogerq(a)ti.com> [ Upstream commit 16bb05d98c904a4f6c5ce7e2d992299f794acbf2 ] As per USB3.0 Specification "Table 9-20. Standard Endpoint Descriptor", for interrupt and isochronous endpoints, wMaxPacketSize must be set to 1024 if the endpoint defines bMaxBurst to be greater than zero. Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Roger Quadros <rogerq(a)ti.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/function/f_uvc.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/usb/gadget/function/f_uvc.c +++ b/drivers/usb/gadget/function/f_uvc.c @@ -612,6 +612,14 @@ uvc_function_bind(struct usb_configurati opts->streaming_maxpacket = clamp(opts->streaming_maxpacket, 1U, 3072U); opts->streaming_maxburst = min(opts->streaming_maxburst, 15U); + /* For SS, wMaxPacketSize has to be 1024 if bMaxBurst is not 0 */ + if (opts->streaming_maxburst && + (opts->streaming_maxpacket % 1024) != 0) { + opts->streaming_maxpacket = roundup(opts->streaming_maxpacket, 1024); + INFO(cdev, "overriding streaming_maxpacket to %d\n", + opts->streaming_maxpacket); + } + /* Fill in the FS/HS/SS Video Streaming specific descriptors from the * module parameters. * Patches currently in stable-queue which might be from rogerq(a)ti.com are queue-3.18/usb-gadget-f_uvc-sanity-check-wmaxpacketsize-for-superspeed.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "xhci: plat: Register shutdown for xhci_plat" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xhci: plat: Register shutdown for xhci_plat to the 3.18-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: xhci-plat-register-shutdown-for-xhci_plat.patch and it can be found in the queue-3.18 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 foo@baz Thu Dec 21 10:55:04 CET 2017 From: Adam Wallis <awallis(a)codeaurora.org> Date: Tue, 28 Mar 2017 15:55:28 +0300 Subject: xhci: plat: Register shutdown for xhci_plat From: Adam Wallis <awallis(a)codeaurora.org> [ Upstream commit b07c12517f2aed0add8ce18146bb426b14099392 ] Shutdown should be called for xhci_plat devices especially for situations where kexec might be used by stopping DMA transactions. Signed-off-by: Adam Wallis <awallis(a)codeaurora.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/host/xhci-plat.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -252,6 +252,7 @@ MODULE_DEVICE_TABLE(of, usb_xhci_of_matc static struct platform_driver usb_xhci_driver = { .probe = xhci_plat_probe, .remove = xhci_plat_remove, + .shutdown = usb_hcd_platform_shutdown, .driver = { .name = "xhci-hcd", .pm = DEV_PM_OPS, Patches currently in stable-queue which might be from awallis(a)codeaurora.org are queue-3.18/xhci-plat-register-shutdown-for-xhci_plat.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: gadget: udc: remove pointer dereference after free" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: udc: remove pointer dereference after free to the 3.18-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: usb-gadget-udc-remove-pointer-dereference-after-free.patch and it can be found in the queue-3.18 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 foo@baz Thu Dec 21 10:55:04 CET 2017 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Fri, 10 Mar 2017 15:39:32 -0600 Subject: usb: gadget: udc: remove pointer dereference after free From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> [ Upstream commit 1f459262b0e1649a1e5ad12fa4c66eb76c2220ce ] Remove pointer dereference after free. Addresses-Coverity-ID: 1091173 Acked-by: Michal Nazarewicz <mina86(a)mina86.com> Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/pch_udc.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/usb/gadget/udc/pch_udc.c +++ b/drivers/usb/gadget/udc/pch_udc.c @@ -1533,7 +1533,6 @@ static void pch_udc_free_dma_chain(struc td = phys_to_virt(addr); addr2 = (dma_addr_t)td->next; pci_pool_free(dev->data_requests, td, addr); - td->next = 0x00; addr = addr2; } req->chain_len = 1; Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-3.18/usb-gadget-udc-remove-pointer-dereference-after-free.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: lpfc: Fix PT2PT PRLI reject" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: lpfc: Fix PT2PT PRLI reject to the 3.18-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: scsi-lpfc-fix-pt2pt-prli-reject.patch and it can be found in the queue-3.18 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 foo@baz Thu Dec 21 10:55:04 CET 2017 From: Dick Kennedy <dick.kennedy(a)broadcom.com> Date: Thu, 23 Mar 2017 08:47:18 -0400 Subject: scsi: lpfc: Fix PT2PT PRLI reject From: Dick Kennedy <dick.kennedy(a)broadcom.com> [ Upstream commit a71e3cdcfce4880a4578915e110e3eaed1659765 ] lpfc cannot establish connection with targets that send PRLI in P2P configurations. If lpfc rejects a PRLI that is sent from a target the target will not resend and will reject the PRLI send from the initiator. [mkp: applied by hand] Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/lpfc/lpfc_els.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/scsi/lpfc/lpfc_els.c +++ b/drivers/scsi/lpfc/lpfc_els.c @@ -6870,7 +6870,8 @@ lpfc_els_unsol_buffer(struct lpfc_hba *p did, vport->port_state, ndlp->nlp_flag); phba->fc_stat.elsRcvPRLI++; - if (vport->port_state < LPFC_DISC_AUTH) { + if ((vport->port_state < LPFC_DISC_AUTH) && + (vport->fc_flag & FC_FABRIC)) { rjt_err = LSRJT_UNABLE_TPC; rjt_exp = LSEXP_NOTHING_MORE; break; Patches currently in stable-queue which might be from dick.kennedy(a)broadcom.com are queue-3.18/scsi-lpfc-fix-pt2pt-prli-reject.patch queue-3.18/scsi-lpfc-plogi-failures-during-npiv-testing.patch queue-3.18/scsi-lpfc-fix-secure-firmware-updates.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: lpfc: PLOGI failures during NPIV testing" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: lpfc: PLOGI failures during NPIV testing to the 3.18-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: scsi-lpfc-plogi-failures-during-npiv-testing.patch and it can be found in the queue-3.18 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 foo@baz Thu Dec 21 10:55:04 CET 2017 From: Dick Kennedy <dick.kennedy(a)broadcom.com> Date: Fri, 29 Sep 2017 17:34:32 -0700 Subject: scsi: lpfc: PLOGI failures during NPIV testing From: Dick Kennedy <dick.kennedy(a)broadcom.com> [ Upstream commit e8bcf0ae4c0346fdc78ebefe0eefcaa6a6622d38 ] Local Reject/Invalid RPI errors seen during discovery. Temporary RPI cleanup was occurring regardless of SLI rev. It's only necessary on SLI-4. Adjust the test for whether cleanup is necessary. Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.de> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/lpfc/lpfc_hbadisc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/scsi/lpfc/lpfc_hbadisc.c +++ b/drivers/scsi/lpfc/lpfc_hbadisc.c @@ -4737,7 +4737,8 @@ lpfc_nlp_remove(struct lpfc_vport *vport lpfc_cancel_retry_delay_tmo(vport, ndlp); if ((ndlp->nlp_flag & NLP_DEFER_RM) && !(ndlp->nlp_flag & NLP_REG_LOGIN_SEND) && - !(ndlp->nlp_flag & NLP_RPI_REGISTERED)) { + !(ndlp->nlp_flag & NLP_RPI_REGISTERED) && + phba->sli_rev != LPFC_SLI_REV4) { /* For this case we need to cleanup the default rpi * allocated by the firmware. */ Patches currently in stable-queue which might be from dick.kennedy(a)broadcom.com are queue-3.18/scsi-lpfc-fix-pt2pt-prli-reject.patch queue-3.18/scsi-lpfc-plogi-failures-during-npiv-testing.patch queue-3.18/scsi-lpfc-fix-secure-firmware-updates.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: lpfc: Fix secure firmware updates" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: lpfc: Fix secure firmware updates to the 3.18-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: scsi-lpfc-fix-secure-firmware-updates.patch and it can be found in the queue-3.18 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 foo@baz Thu Dec 21 10:55:04 CET 2017 From: Dick Kennedy <dick.kennedy(a)broadcom.com> Date: Fri, 29 Sep 2017 17:34:42 -0700 Subject: scsi: lpfc: Fix secure firmware updates From: Dick Kennedy <dick.kennedy(a)broadcom.com> [ Upstream commit 184fc2b9a8bcbda9c14d0a1e7fbecfc028c7702e ] Firmware update fails with: status x17 add_status x56 on the final write If multiple DMA buffers are used for the download, some firmware revs have difficulty with signatures and crcs split across the dma buffer boundaries. Resolve by making all writes be a single 4k page in length. Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> Reviewed-by: Johannes Thumshirn <jthumshirn(a)suse.de> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/lpfc/lpfc_hw4.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/scsi/lpfc/lpfc_hw4.h +++ b/drivers/scsi/lpfc/lpfc_hw4.h @@ -2951,7 +2951,7 @@ struct lpfc_mbx_get_port_name { #define MB_CEQ_STATUS_QUEUE_FLUSHING 0x4 #define MB_CQE_STATUS_DMA_FAILED 0x5 -#define LPFC_MBX_WR_CONFIG_MAX_BDE 8 +#define LPFC_MBX_WR_CONFIG_MAX_BDE 1 struct lpfc_mbx_wr_object { struct mbox_header header; union { Patches currently in stable-queue which might be from dick.kennedy(a)broadcom.com are queue-3.18/scsi-lpfc-fix-pt2pt-prli-reject.patch queue-3.18/scsi-lpfc-plogi-failures-during-npiv-testing.patch queue-3.18/scsi-lpfc-fix-secure-firmware-updates.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "s390/qeth: no ETH header for outbound AF_IUCV" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled s390/qeth: no ETH header for outbound AF_IUCV to the 3.18-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: s390-qeth-no-eth-header-for-outbound-af_iucv.patch and it can be found in the queue-3.18 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 foo@baz Thu Dec 21 10:55:04 CET 2017 From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com> Date: Thu, 23 Mar 2017 14:55:09 +0100 Subject: s390/qeth: no ETH header for outbound AF_IUCV From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com> [ Upstream commit acd9776b5c45ef02d1a210969a6fcc058afb76e3 ] With AF_IUCV traffic, the skb passed to hard_start_xmit() has a 14 byte slot at skb->data, intended for an ETH header. qeth_l3_fill_af_iucv_hdr() fills this ETH header... and then immediately moves it to the skb's headroom, where it disappears and is never seen again. But it's still possible for us to return NETDEV_TX_BUSY after the skb has been modified. Since we didn't get a private copy of the skb, the next time the skb is delivered to hard_start_xmit() it no longer has the expected layout (we moved the ETH header to the headroom, so skb->data now starts at the IUCV_TRANS header). So when qeth_l3_fill_af_iucv_hdr() does another round of rebuilding, the resulting qeth header ends up all wrong. On transmission, the buffer is then rejected by the HiperSockets device with SBALF15 = x'04'. When this error is passed back to af_iucv as TX_NOTIFY_UNREACHABLE, it tears down the offending socket. As the ETH header for AF_IUCV serves no purpose, just align the code to what we do for IP traffic on L3 HiperSockets: keep the ETH header at skb->data, and pass down data_offset = ETH_HLEN to qeth_fill_buffer(). When mapping the payload into the SBAL elements, the ETH header is then stripped off. This avoids the skb manipulations in qeth_l3_fill_af_iucv_hdr(), and any buffer re-entering hard_start_xmit() after NETDEV_TX_BUSY is now processed properly. Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com> Signed-off-by: Ursula Braun <ubraun(a)linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/s390/net/qeth_l3_main.c | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) --- a/drivers/s390/net/qeth_l3_main.c +++ b/drivers/s390/net/qeth_l3_main.c @@ -2769,17 +2769,13 @@ static void qeth_l3_fill_af_iucv_hdr(str char daddr[16]; struct af_iucv_trans_hdr *iucv_hdr; - skb_pull(skb, 14); - card->dev->header_ops->create(skb, card->dev, 0, - card->dev->dev_addr, card->dev->dev_addr, - card->dev->addr_len); - skb_pull(skb, 14); - iucv_hdr = (struct af_iucv_trans_hdr *)skb->data; memset(hdr, 0, sizeof(struct qeth_hdr)); hdr->hdr.l3.id = QETH_HEADER_TYPE_LAYER3; hdr->hdr.l3.ext_flags = 0; - hdr->hdr.l3.length = skb->len; + hdr->hdr.l3.length = skb->len - ETH_HLEN; hdr->hdr.l3.flags = QETH_HDR_IPV6 | QETH_CAST_UNICAST; + + iucv_hdr = (struct af_iucv_trans_hdr *) (skb->data + ETH_HLEN); memset(daddr, 0, sizeof(daddr)); daddr[0] = 0xfe; daddr[1] = 0x80; @@ -2962,10 +2958,7 @@ static int qeth_l3_hard_start_xmit(struc if ((card->info.type == QETH_CARD_TYPE_IQD) && (!large_send) && (skb_shinfo(skb)->nr_frags == 0)) { new_skb = skb; - if (new_skb->protocol == ETH_P_AF_IUCV) - data_offset = 0; - else - data_offset = ETH_HLEN; + data_offset = ETH_HLEN; hdr = kmem_cache_alloc(qeth_core_header_cache, GFP_ATOMIC); if (!hdr) goto tx_drop; Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are queue-3.18/s390-qeth-no-eth-header-for-outbound-af_iucv.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "scsi: cxgb4i: fix Tx skb leak" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: cxgb4i: fix Tx skb leak to the 3.18-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: scsi-cxgb4i-fix-tx-skb-leak.patch and it can be found in the queue-3.18 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 foo@baz Thu Dec 21 10:55:04 CET 2017 From: Varun Prakash <varun(a)chelsio.com> Date: Wed, 11 Oct 2017 19:33:07 +0530 Subject: scsi: cxgb4i: fix Tx skb leak From: Varun Prakash <varun(a)chelsio.com> [ Upstream commit 9b3a081fb62158b50bcc90522ca2423017544367 ] In case of connection reset Tx skb queue can have some skbs which are not transmitted so purge Tx skb queue in release_offload_resources() to avoid skb leak. Signed-off-by: Varun Prakash <varun(a)chelsio.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c +++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c @@ -1262,6 +1262,7 @@ static void release_offload_resources(st csk, csk->state, csk->flags, csk->tid); cxgbi_sock_free_cpl_skbs(csk); + cxgbi_sock_purge_write_queue(csk); if (csk->wr_cred != csk->wr_max_cred) { cxgbi_sock_purge_wr_queue(csk); cxgbi_sock_reset_wr_list(csk); Patches currently in stable-queue which might be from varun(a)chelsio.com are queue-3.18/scsi-cxgb4i-fix-tx-skb-leak.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "r8152: fix the list rx_done may be used without initialization" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled r8152: fix the list rx_done may be used without initialization to the 3.18-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: r8152-fix-the-list-rx_done-may-be-used-without-initialization.patch and it can be found in the queue-3.18 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 foo@baz Thu Dec 21 10:55:04 CET 2017 From: hayeswang <hayeswang(a)realtek.com> Date: Tue, 14 Mar 2017 14:15:20 +0800 Subject: r8152: fix the list rx_done may be used without initialization From: hayeswang <hayeswang(a)realtek.com> [ Upstream commit 98d068ab52b4b11d403995ed14154660797e7136 ] The list rx_done would be initialized when the linking on occurs. Therefore, if a napi is scheduled without any linking on before, the following kernel panic would happen. BUG: unable to handle kernel NULL pointer dereference at 000000000000008 IP: [<ffffffffc085efde>] r8152_poll+0xe1e/0x1210 [r8152] PGD 0 Oops: 0002 [#1] SMP Signed-off-by: Hayes Wang <hayeswang(a)realtek.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/r8152.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -1252,6 +1252,7 @@ static int alloc_all_mem(struct r8152 *t spin_lock_init(&tp->tx_lock); INIT_LIST_HEAD(&tp->rx_done); INIT_LIST_HEAD(&tp->tx_free); + INIT_LIST_HEAD(&tp->rx_done); skb_queue_head_init(&tp->tx_queue); for (i = 0; i < RTL8152_MAX_RX; i++) { Patches currently in stable-queue which might be from hayeswang(a)realtek.com are queue-3.18/r8152-fix-the-list-rx_done-may-be-used-without-initialization.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "PCI: Create SR-IOV virtfn/physfn links before attaching driver" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: Create SR-IOV virtfn/physfn links before attaching driver to the 3.18-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: pci-create-sr-iov-virtfn-physfn-links-before-attaching-driver.patch and it can be found in the queue-3.18 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 foo@baz Thu Dec 21 10:55:04 CET 2017 From: Stuart Hayes <stuart.w.hayes(a)gmail.com> Date: Wed, 4 Oct 2017 10:57:52 -0500 Subject: PCI: Create SR-IOV virtfn/physfn links before attaching driver From: Stuart Hayes <stuart.w.hayes(a)gmail.com> [ Upstream commit 27d6162944b9b34c32cd5841acd21786637ee743 ] When creating virtual functions, create the "virtfn%u" and "physfn" links in sysfs *before* attaching the driver instead of after. When we attach the driver to the new virtual network interface first, there is a race when the driver attaches to the new sends out an "add" udev event, and the network interface naming software (biosdevname or systemd, for example) tries to look at these links. Signed-off-by: Stuart Hayes <stuart.w.hayes(a)gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/iov.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/pci/iov.c +++ b/drivers/pci/iov.c @@ -106,7 +106,6 @@ static int virtfn_add(struct pci_dev *de pci_device_add(virtfn, virtfn->bus); mutex_unlock(&iov->dev->sriov->lock); - pci_bus_add_device(virtfn); sprintf(buf, "virtfn%u", id); rc = sysfs_create_link(&dev->dev.kobj, &virtfn->dev.kobj, buf); if (rc) @@ -117,6 +116,8 @@ static int virtfn_add(struct pci_dev *de kobject_uevent(&virtfn->dev.kobj, KOBJ_CHANGE); + pci_bus_add_device(virtfn); + return 0; failed2: Patches currently in stable-queue which might be from stuart.w.hayes(a)gmail.com are queue-3.18/pci-create-sr-iov-virtfn-physfn-links-before-attaching-driver.patch

7 years, 10 months

1
0
0 0

[Linux-stable-mirror] Patch "percpu: don't forget to free the temporary struct pcpu_alloc_info" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled percpu: don't forget to free the temporary struct pcpu_alloc_info to the 3.18-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: percpu-don-t-forget-to-free-the-temporary-struct-pcpu_alloc_info.patch and it can be found in the queue-3.18 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 foo@baz Thu Dec 21 10:55:04 CET 2017 From: Nicolas Pitre <nicolas.pitre(a)linaro.org> Date: Tue, 3 Oct 2017 18:29:49 -0400 Subject: percpu: don't forget to free the temporary struct pcpu_alloc_info From: Nicolas Pitre <nicolas.pitre(a)linaro.org> [ Upstream commit 438a50618095061920d3a30d4c5ca1ef2e0ff860 ] Unlike the SMP case, the !SMP case does not free the memory for struct pcpu_alloc_info allocated in setup_per_cpu_areas(). And to give it a chance of being reused by the page allocator later, align it to a page boundary just like its size. Signed-off-by: Nicolas Pitre <nico(a)linaro.org> Acked-by: Dennis Zhou <dennisszhou(a)gmail.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/percpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/mm/percpu.c +++ b/mm/percpu.c @@ -1402,7 +1402,7 @@ struct pcpu_alloc_info * __init pcpu_all __alignof__(ai->groups[0].cpu_map[0])); ai_size = base_size + nr_units * sizeof(ai->groups[0].cpu_map[0]); - ptr = memblock_virt_alloc_nopanic(PFN_ALIGN(ai_size), 0); + ptr = memblock_virt_alloc_nopanic(PFN_ALIGN(ai_size), PAGE_SIZE); if (!ptr) return NULL; ai = ptr; @@ -2268,6 +2268,7 @@ void __init setup_per_cpu_areas(void) if (pcpu_setup_first_chunk(ai, fc) < 0) panic("Failed to initialize percpu areas."); + pcpu_free_alloc_info(ai); } #endif /* CONFIG_SMP */ Patches currently in stable-queue which might be from nicolas.pitre(a)linaro.org are queue-3.18/percpu-don-t-forget-to-free-the-temporary-struct-pcpu_alloc_info.patch

7 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror