Hi Rakesh,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5b7449810ae6d652629c550d3974c8453836d229
commit: 6bae5ea9498926440ffc883f3dbceb0adc65e492 ASoC: hdac_hda: add asoc
extension for legacy HDA codec drivers
Hi Rakesh,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5b7449810ae6d652629c550d3974c8453836d229
commit: 6bae5ea9498926440ffc883f3dbceb0adc65e492 ASoC: hdac_hda: add asoc
extension for legacy HDA codec drivers
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/bcm/pinctrl-bcm2835.c:707:40: warning: implicit
conversion from enumeration type 'enum bcm2835_pinconf_param' to
different enumeration type 'enum pin_config_param' [-Wenum-conversion]
configs[0] =
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/bcm/pinctrl-bcm2835.c:707:40: warning: implicit
conversion from enumeration type 'enum bcm2835_pinconf_param' to
different enumeration type 'enum pin_config_param' [-Wenum-conversion]
configs[0] =
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/sprd/pinctrl-sprd.c:845:19: warning: implicit conversion
from enumeration type 'enum sprd_pinconf_params' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
{"sprd,control",
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/sprd/pinctrl-sprd.c:845:19: warning: implicit conversion
from enumeration type 'enum sprd_pinconf_params' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
{"sprd,control",
On Oct 30, 2018, at 9:39 PM, Vasily Averin wrote:
>
> On 10/31/2018 04:30 AM, Andreas Dilger wrote:
>> Could you please explain your statement below that on-stack
>> initialization does not zero unspecified fields? According
>> to documents I found, for example:
>>
>>
On Oct 30, 2018, at 9:39 PM, Vasily Averin wrote:
>
> On 10/31/2018 04:30 AM, Andreas Dilger wrote:
>> Could you please explain your statement below that on-stack
>> initialization does not zero unspecified fields? According
>> to documents I found, for example:
>>
>>
IRQ_MATRIX_SIZE is the number of longs needed for a bitmap,
multiplied by the size of a long, yielding a byte count. But
it is used as the size of an array of longs, which is way more
memory than is needed. Change IRQ_MATRIX_SIZE so it is just the
number of longs needed and the arrays come out
IRQ_MATRIX_SIZE is the number of longs needed for a bitmap,
multiplied by the size of a long, yielding a byte count. But
it is used as the size of an array of longs, which is way more
memory than is needed. Change IRQ_MATRIX_SIZE so it is just the
number of longs needed and the arrays come out
Hello,
On 31/10/2018 19:12:06-0400, Sasha Levin wrote:
> - m->rtc = rtc_device_register(DRIVER_NAME,
> - >client->dev,
> - _rtc_ops, THIS_MODULE);
> - if (IS_ERR(m->rtc)) {
> + err = rtc_register_device(m->rtc);
This appeared in v4.13, this
Hello,
On 31/10/2018 19:12:06-0400, Sasha Levin wrote:
> - m->rtc = rtc_device_register(DRIVER_NAME,
> - >client->dev,
> - _rtc_ops, THIS_MODULE);
> - if (IS_ERR(m->rtc)) {
> + err = rtc_register_device(m->rtc);
This appeared in v4.13, this
ldsem_down_read() will sleep if there is pending writer in the queue.
If the writer times out, readers in the queue should be woken up,
otherwise they may miss a chance to acquire the semaphore until the last
active reader will do ldsem_up_read().
There was a couple of reports where there was one
From: Peter Zijlstra
For some reason ldsem has its own lockdep wrappers, make them go away.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Dmitry Safonov
---
drivers/tty/tty_ldsem.c | 51 +++--
1 file changed,
As notted by Jiri, tty_ldisc_reinit() shouldn't rely on tty counter.
Simplify math by increasing the counter after reinit success.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Link: lkml.kernel.org/r/<20180829022353.23568-2-d...@arista.com>
Suggested-by: Jiri Slaby
Reviewed-by: Jiri Slaby
Tested-by:
Make sure under CONFIG_LOCKDEP that each change to line discipline
is done with held write semaphor.
Otherwise potential reader will have a good time dereferencing
incomplete/uninitialized ldisc.
An exception here is tty_ldisc_open(), as it's called without ldisc_sem
locked by tty_init_dev() =>
It seems like when ldsem_down_read() fails with timeout, it misses
update for sem->wait_readers. By that reason, when writer finally
releases write end of the semaphore __ldsem_wake_readers() does adjust
sem->count with wrong value:
sem->wait_readers * (LDSEM_ACTIVE_BIAS - LDSEM_WAIT_BIAS)
I.e,
There might be situations where tty_ldisc_lock() has blocked, but there
is already IO on tty and it prevents line discipline changes.
It might theoretically turn into dead-lock.
Basically, provide more priority to pending tty_ldisc_lock() than to
servicing reads/writes over tty.
User-visible
ldsem_down_read() will sleep if there is pending writer in the queue.
If the writer times out, readers in the queue should be woken up,
otherwise they may miss a chance to acquire the semaphore until the last
active reader will do ldsem_up_read().
There was a couple of reports where there was one
From: Peter Zijlstra
For some reason ldsem has its own lockdep wrappers, make them go away.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Dmitry Safonov
---
drivers/tty/tty_ldsem.c | 51 +++--
1 file changed,
As notted by Jiri, tty_ldisc_reinit() shouldn't rely on tty counter.
Simplify math by increasing the counter after reinit success.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Link: lkml.kernel.org/r/<20180829022353.23568-2-d...@arista.com>
Suggested-by: Jiri Slaby
Reviewed-by: Jiri Slaby
Tested-by:
Make sure under CONFIG_LOCKDEP that each change to line discipline
is done with held write semaphor.
Otherwise potential reader will have a good time dereferencing
incomplete/uninitialized ldisc.
An exception here is tty_ldisc_open(), as it's called without ldisc_sem
locked by tty_init_dev() =>
It seems like when ldsem_down_read() fails with timeout, it misses
update for sem->wait_readers. By that reason, when writer finally
releases write end of the semaphore __ldsem_wake_readers() does adjust
sem->count with wrong value:
sem->wait_readers * (LDSEM_ACTIVE_BIAS - LDSEM_WAIT_BIAS)
I.e,
There might be situations where tty_ldisc_lock() has blocked, but there
is already IO on tty and it prevents line discipline changes.
It might theoretically turn into dead-lock.
Basically, provide more priority to pending tty_ldisc_lock() than to
servicing reads/writes over tty.
User-visible
tty_ldisc_reinit() doesn't race with neither tty_ldisc_hangup()
nor set_ldisc() nor tty_ldisc_release() as they use tty lock.
But it races with anyone who expects line discipline to be the same
after hoding read semaphore in tty_ldisc_ref().
We've seen the following crash on v4.9.108 stable:
tty_ldisc_reinit() doesn't race with neither tty_ldisc_hangup()
nor set_ldisc() nor tty_ldisc_release() as they use tty lock.
But it races with anyone who expects line discipline to be the same
after hoding read semaphore in tty_ldisc_ref().
We've seen the following crash on v4.9.108 stable:
Hi all,
Here are fixes that worth to have in the @stable, as they were hit by
different people, including Arista on v4.9 stable.
And for linux-next - adding lockdep asserts for line discipline changing
code, verifying that write ldisc sem will be held forthwith.
Mikulas, can you add your
Hi all,
Here are fixes that worth to have in the @stable, as they were hit by
different people, including Arista on v4.9 stable.
And for linux-next - adding lockdep asserts for line discipline changing
code, verifying that write ldisc sem will be held forthwith.
Mikulas, can you add your
When the OS registers to handle events from the display off hotkey the
EC will send a notification with 0x35 for every key press, independent
of the backlight state.
The behavior of this key on Windows, with the ATKACPI driver from Asus
installed, is turning off the backlight of all connected
According to Asus firmware engineers, the meaning of these codes is only
to notify the OS that the screen brightness has been turned on/off by
the EC. This does not match the meaning of KEY_DISPLAYTOGGLE /
KEY_DISPLAY_OFF, where userspace is expected to change the display
brightness.
When the OS registers to handle events from the display off hotkey the
EC will send a notification with 0x35 for every key press, independent
of the backlight state.
The behavior of this key on Windows, with the ATKACPI driver from Asus
installed, is turning off the backlight of all connected
According to Asus firmware engineers, the meaning of these codes is only
to notify the OS that the screen brightness has been turned on/off by
the EC. This does not match the meaning of KEY_DISPLAYTOGGLE /
KEY_DISPLAY_OFF, where userspace is expected to change the display
brightness.
Asus laptops have a hotkey function on the F7 key to turn the display
backlight OFF, labeled with a screen with a X inside, as shown on
https://dlcdnimgs.asus.com/websites/global/products/Xep1ZcSY8dyWXK11/images/keyboard.png
This hotkey worked on very few Asus models, where the EC acts on the
In the past, Asus firmwares would change the panel backlight directly
through the EC when the display off hotkey (Fn+F7) was pressed, and
only notify the OS of such change, with 0x33 when the LCD was ON and
0x34 when the LCD was OFF. These are currently mapped to
KEY_DISPLAYTOGGLE and
Asus laptops have a hotkey function on the F7 key to turn the display
backlight OFF, labeled with a screen with a X inside, as shown on
https://dlcdnimgs.asus.com/websites/global/products/Xep1ZcSY8dyWXK11/images/keyboard.png
This hotkey worked on very few Asus models, where the EC acts on the
In the past, Asus firmwares would change the panel backlight directly
through the EC when the display off hotkey (Fn+F7) was pressed, and
only notify the OS of such change, with 0x33 when the LCD was ON and
0x34 when the LCD was OFF. These are currently mapped to
KEY_DISPLAYTOGGLE and
Quoting Lina Iyer (2018-10-31 09:46:50)
> On Wed, Oct 31 2018 at 01:05 -0600, Stephen Boyd wrote:
> >Hi Lina,
> >
> >Quoting Lina Iyer (2018-10-10 17:29:58)
> >> QCOM SoC's that have Power Domain Controller (PDC) chip in the always-on
> >> domain can wakeup the SoC, when interrupts and GPIOs are
Quoting Lina Iyer (2018-10-31 09:46:50)
> On Wed, Oct 31 2018 at 01:05 -0600, Stephen Boyd wrote:
> >Hi Lina,
> >
> >Quoting Lina Iyer (2018-10-10 17:29:58)
> >> QCOM SoC's that have Power Domain Controller (PDC) chip in the always-on
> >> domain can wakeup the SoC, when interrupts and GPIOs are
From: Jonathan Marek
This patch adds an of_match for the usb-otg-vbus regulator to
bq24190_charger.
Signed-off-by: Jonathan Marek
Signed-off-by: Brian Masney
---
drivers/power/supply/bq24190_charger.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/supply/bq24190_charger.c
From: Jonathan Marek
This patch adds an of_match for the usb-otg-vbus regulator to
bq24190_charger.
Signed-off-by: Jonathan Marek
Signed-off-by: Brian Masney
---
drivers/power/supply/bq24190_charger.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/supply/bq24190_charger.c
Add support for the ti,bq24192 variant and a child node for the
usb-otg-vbus regulator.
Signed-off-by: Brian Masney
---
.../devicetree/bindings/power/supply/bq24190.txt | 9 +
1 file changed, 9 insertions(+)
diff --git
This adds the gpio-ranges property to pm8941_gpios so that the GPIO
pins are initialized by the GPIO framework and not pinctrl. This fixes
a circular dependency so GPIO hogging can be used on this board.
Signed-off-by: Brian Masney
---
arch/arm/boot/dts/qcom-pm8941.dtsi | 1 +
1 file changed, 1
Add support for the ti,bq24192 variant and a child node for the
usb-otg-vbus regulator.
Signed-off-by: Brian Masney
---
.../devicetree/bindings/power/supply/bq24190.txt | 9 +
1 file changed, 9 insertions(+)
diff --git
This adds the gpio-ranges property to pm8941_gpios so that the GPIO
pins are initialized by the GPIO framework and not pinctrl. This fixes
a circular dependency so GPIO hogging can be used on this board.
Signed-off-by: Brian Masney
---
arch/arm/boot/dts/qcom-pm8941.dtsi | 1 +
1 file changed, 1
Add extcon support so that we can notify USB drivers of cable state
changes. Based on work from Jonathan Marek. USB OTG was tested on a LG
Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
drivers/power/supply/bq24190_charger.c | 37 +-
1 file changed, 36
Add the device tree bindings for USB OTG support. Driver was tested
using on a LG Nexus 5 (hammerhead) phone. This patch is based on work
from Jonathan Marek and from the other msm8974 devices.
Signed-off-by: Brian Masney
---
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 60
From: Jonathan Marek
This patch adds support for the bq24192 variant to bq24190_charger.
Signed-off-by: Jonathan Marek
[masn...@onstation.org: Changed if statement to a switch based on
feedback from Sebastian Reichel.]
Signed-off-by: Brian Masney
---
drivers/power/supply/bq24190_charger.c |
When attempting to setup up a gpio hog, device probing would repeatedly
fail with -EPROBE_DEFERED errors. It was caused by a circular dependency
between the gpio and pinctrl frameworks. If the gpio-ranges property is
present in device tree, then the gpio framework will handle the gpio pin
Add extcon support so that we can notify USB drivers of cable state
changes. Based on work from Jonathan Marek. USB OTG was tested on a LG
Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
drivers/power/supply/bq24190_charger.c | 37 +-
1 file changed, 36
Add the device tree bindings for USB OTG support. Driver was tested
using on a LG Nexus 5 (hammerhead) phone. This patch is based on work
from Jonathan Marek and from the other msm8974 devices.
Signed-off-by: Brian Masney
---
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 60
From: Jonathan Marek
This patch adds support for the bq24192 variant to bq24190_charger.
Signed-off-by: Jonathan Marek
[masn...@onstation.org: Changed if statement to a switch based on
feedback from Sebastian Reichel.]
Signed-off-by: Brian Masney
---
drivers/power/supply/bq24190_charger.c |
When attempting to setup up a gpio hog, device probing would repeatedly
fail with -EPROBE_DEFERED errors. It was caused by a circular dependency
between the gpio and pinctrl frameworks. If the gpio-ranges property is
present in device tree, then the gpio framework will handle the gpio pin
This patch set adds USB OTG support for the LG Nexus 5 (hammerhead)
phone.
Changes in v2:
- Reworked patches to use gpio hogging as suggested in the bq24190
device tree documentation.
- bq24190_charger: changed to use a switch instead of an if as requested
by Sebastian Reichel.
-
This patch set adds USB OTG support for the LG Nexus 5 (hammerhead)
phone.
Changes in v2:
- Reworked patches to use gpio hogging as suggested in the bq24190
device tree documentation.
- bq24190_charger: changed to use a switch instead of an if as requested
by Sebastian Reichel.
-
On Wed, Oct 31, 2018 at 02:33:24PM +0100, Linus Walleij wrote:
> On Thu, Oct 25, 2018 at 11:04 PM Nathan Chancellor
> wrote:
>
> > In my opinion, there are enough of these warnings to warrant changing
> > the type of param globally (arm64 allyesconfig):
>
> Yeah as it is from the compiler, sure
On 31/10/18 23:10, Douglas Gilbert wrote:
> On 2018-10-31 4:57 p.m., Boaz Harrosh wrote:
>> On 30/10/18 09:45, Christoph Hellwig wrote:
>>> On Mon, Oct 29, 2018 at 02:42:12PM -0600, Jens Axboe wrote:
LGTM, for both:
>>>
>>> I also have this one on top as requested by Martin. The core block
On Wed, Oct 31, 2018 at 02:33:24PM +0100, Linus Walleij wrote:
> On Thu, Oct 25, 2018 at 11:04 PM Nathan Chancellor
> wrote:
>
> > In my opinion, there are enough of these warnings to warrant changing
> > the type of param globally (arm64 allyesconfig):
>
> Yeah as it is from the compiler, sure
On 31/10/18 23:10, Douglas Gilbert wrote:
> On 2018-10-31 4:57 p.m., Boaz Harrosh wrote:
>> On 30/10/18 09:45, Christoph Hellwig wrote:
>>> On Mon, Oct 29, 2018 at 02:42:12PM -0600, Jens Axboe wrote:
LGTM, for both:
>>>
>>> I also have this one on top as requested by Martin. The core block
On 31-10-18, Pierre-Louis Bossart wrote:
>
> > Just thought it worth mentioning, this new patch that fixes sound
> > again, seems to have ressurected an old issue with PLL unlock. I'm
> > seeing journal entries after fresh boot ..
> >
> > ```
> > picard kernel: max98090 i2c-193C9890:00: PLL
On 31-10-18, Pierre-Louis Bossart wrote:
>
> > Just thought it worth mentioning, this new patch that fixes sound
> > again, seems to have ressurected an old issue with PLL unlock. I'm
> > seeing journal entries after fresh boot ..
> >
> > ```
> > picard kernel: max98090 i2c-193C9890:00: PLL
Hi,
On Tue, Oct 30, 2018 at 10:23 AM Raju P.L.S.S.S.N
wrote:
>
> Add device bindings for cpuidle states for cpu devices.
>
> Cc:
> Signed-off-by: Raju P.L.S.S.S.N
> ---
> Changes in v2
> - Address comments from Doug
> ---
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 62
>
Hi,
On Tue, Oct 30, 2018 at 10:23 AM Raju P.L.S.S.S.N
wrote:
>
> Add device bindings for cpuidle states for cpu devices.
>
> Cc:
> Signed-off-by: Raju P.L.S.S.S.N
> ---
> Changes in v2
> - Address comments from Doug
> ---
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 62
>
From: Eric Dumazet
[ Upstream commit 4c16128b6271e70c8743178e90cccee147858503 ]
At least UDP / TCP stacks can now cook skbs with a tstamp using
MONOTONIC base (or arbitrary values with SCM_TXTIME)
Since loopback driver does not call (directly or indirectly)
skb_scrub_packet(), we need to clear
From: Eric Dumazet
[ Upstream commit 4c16128b6271e70c8743178e90cccee147858503 ]
At least UDP / TCP stacks can now cook skbs with a tstamp using
MONOTONIC base (or arbitrary values with SCM_TXTIME)
Since loopback driver does not call (directly or indirectly)
skb_scrub_packet(), we need to clear
From: Omar Sandoval
[ Upstream commit 71327f547ee3a46ec5c39fdbbd268401b2578d0e ]
Move queue allocation next to disk allocation to fix a couple of issues:
- If add_disk() hasn't been called, we should clear disk->queue before
calling put_disk().
- If we fail to allocate a request queue, we
From: Waiman Long
[ Upstream commit 9506a7425b094d2f1d9c877ed5a78f416669269b ]
It was found that when debug_locks was turned off because of a problem
found by the lockdep code, the system performance could drop quite
significantly when the lock_stat code was also configured into the
kernel. For
From: Omar Sandoval
[ Upstream commit 71327f547ee3a46ec5c39fdbbd268401b2578d0e ]
Move queue allocation next to disk allocation to fix a couple of issues:
- If add_disk() hasn't been called, we should clear disk->queue before
calling put_disk().
- If we fail to allocate a request queue, we
From: Waiman Long
[ Upstream commit 9506a7425b094d2f1d9c877ed5a78f416669269b ]
It was found that when debug_locks was turned off because of a problem
found by the lockdep code, the system performance could drop quite
significantly when the lock_stat code was also configured into the
kernel. For
From: Omar Sandoval
[ Upstream commit 1448a2a5360ae06f25e2edc61ae070dff5c0beb4 ]
If we fail to allocate the request queue for a disk, we still need to
free that disk, not just the previous ones. Additionally, we need to
cleanup the previous request queues.
Signed-off-by: Omar Sandoval
From: Omar Sandoval
[ Upstream commit 1448a2a5360ae06f25e2edc61ae070dff5c0beb4 ]
If we fail to allocate the request queue for a disk, we still need to
free that disk, not just the previous ones. Additionally, we need to
cleanup the previous request queues.
Signed-off-by: Omar Sandoval
From: Ryan C Goodfellow
[ Upstream commit 5948185b97fa1f83d7855e638a72982a1073ebf5 ]
This commit makes it possible to use devlink to split the 100G CXP
Netronome into two 40G interfaces. Currently when you ask for 2
interfaces, the math in src/nfp_devlink.c:nfp_devlink_port_split
calculates
From: Haiyang Zhang
[ Upstream commit 005479556197f80139771960dda0dfdcd2d2aad5 ]
The VF device's serial number is saved as a string in PCI slot's
kobj name, not the slot->number. This patch corrects the netvsc
driver, so the VF device can be successfully paired with synthetic
NIC.
Fixes:
From: Javier González
[ Upstream commit 44cdbdc657b23f75736eca3e88b781f009104363 ]
pblk exposes a sysfs interface that represents its internal state. Part
of this state is the map bitmap for the current open line, which should
be protected by the line lock to avoid a race when freeing the line
From: Serhey Popovych
[ Upstream commit df52eab23d703142c766ac00bdb8db19d71238d0 ]
Configuring generic network device parameters on tun will fail in
presence of IFLA_INFO_KIND attribute in IFLA_LINKINFO nested attribute
since tun_validate() always return failure.
This can be visualized with
From: Ryan C Goodfellow
[ Upstream commit 5948185b97fa1f83d7855e638a72982a1073ebf5 ]
This commit makes it possible to use devlink to split the 100G CXP
Netronome into two 40G interfaces. Currently when you ask for 2
interfaces, the math in src/nfp_devlink.c:nfp_devlink_port_split
calculates
From: Haiyang Zhang
[ Upstream commit 005479556197f80139771960dda0dfdcd2d2aad5 ]
The VF device's serial number is saved as a string in PCI slot's
kobj name, not the slot->number. This patch corrects the netvsc
driver, so the VF device can be successfully paired with synthetic
NIC.
Fixes:
From: Javier González
[ Upstream commit 44cdbdc657b23f75736eca3e88b781f009104363 ]
pblk exposes a sysfs interface that represents its internal state. Part
of this state is the map bitmap for the current open line, which should
be protected by the line lock to avoid a race when freeing the line
From: Serhey Popovych
[ Upstream commit df52eab23d703142c766ac00bdb8db19d71238d0 ]
Configuring generic network device parameters on tun will fail in
presence of IFLA_INFO_KIND attribute in IFLA_LINKINFO nested attribute
since tun_validate() always return failure.
This can be visualized with
From: Thierry Reding
[ Upstream commit 95dcd64bc5a27080beaa344edfe5bdcca3d2e7dc ]
Technically this is not required because disabling the PWM should be
enough. However, when support for atomic operations was implemented in
the PWM subsystem, only actual changes to the PWM channel are applied
From: Javier González
[ Upstream commit d8adaa3b86324c6186d0adf74bc256bdacfffdb6 ]
In pblk, when a new line is allocated, metadata for the previously
written line is scheduled. This is done through a fixed memory region
that is shared through time and contexts across different lines and
From: Javier González
[ Upstream commit d8adaa3b86324c6186d0adf74bc256bdacfffdb6 ]
In pblk, when a new line is allocated, metadata for the previously
written line is scheduled. This is done through a fixed memory region
that is shared through time and contexts across different lines and
From: Thierry Reding
[ Upstream commit 95dcd64bc5a27080beaa344edfe5bdcca3d2e7dc ]
Technically this is not required because disabling the PWM should be
enough. However, when support for atomic operations was implemented in
the PWM subsystem, only actual changes to the PWM channel are applied
From: Sanskriti Sharma
[ Upstream commit 9c8a182e5a73e01afd11742a2ab887bf338fdafd ]
parse_ftrace_printk() tokenizes and parses a line, calling strdup() each
iteration. Add code to free this temporary format string duplicate.
Fixes the following coverity complaints:
Error: RESOURCE_LEAK
From: Sanskriti Sharma
[ Upstream commit 9c8a182e5a73e01afd11742a2ab887bf338fdafd ]
parse_ftrace_printk() tokenizes and parses a line, calling strdup() each
iteration. Add code to free this temporary format string duplicate.
Fixes the following coverity complaints:
Error: RESOURCE_LEAK
On Wed, Oct 31, 2018 at 4:01 PM Richard Weinberger wrote:
>
> Okay, so my rebase was in vain, I thought you don't like pull requests
> with such an old base.
Some *really* old bases can cause problems, but generally that's if
it's more than a year old (or if there's been some major upheaval that
On Wed, Oct 31, 2018 at 4:01 PM Richard Weinberger wrote:
>
> Okay, so my rebase was in vain, I thought you don't like pull requests
> with such an old base.
Some *really* old bases can cause problems, but generally that's if
it's more than a year old (or if there's been some major upheaval that
From: Luca Coelho
[ Upstream commit 2e1976bb75263fbad918e82184b16a23bd721546 ]
When reading the profiles from the EWRD table in ACPI, we loop over
the data and set it into our internal table. We use the number of
profiles specified in ACPI without checking its validity, so if the
ACPI table is
From: Sanskriti Sharma
[ Upstream commit faedbf3fd19f2511a39397f76359e4cc6ee93072 ]
Free tracing_data structure in tracing_data_get() error paths.
Fixes the following coverity complaint:
Error: RESOURCE_LEAK (CWE-772):
leaked_storage: Variable "tdata" going out of scope leaks the storage
From: Emmanuel Grumbach
[ Upstream commit 155f7e0441cd121b1e673d465a35e99f4b9b2f0b ]
Fix a bug that happens in the following scenario:
1) suspend without WoWLAN
2) mac80211 calls drv_stop because of the suspend
3) __iwl_mvm_mac_stop deallocates the aux station
4) during drv_stop the firmware
From: Wang Dongsheng
[ Upstream commit c7eabbee3de99347105faa7fd925a500ccf43baf ]
The device specific resource can be free in free_slot after
removing host controller.
Signed-off-by: Wang Dongsheng
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin
---
From: Luca Coelho
[ Upstream commit 2e1976bb75263fbad918e82184b16a23bd721546 ]
When reading the profiles from the EWRD table in ACPI, we loop over
the data and set it into our internal table. We use the number of
profiles specified in ACPI without checking its validity, so if the
ACPI table is
From: Sanskriti Sharma
[ Upstream commit faedbf3fd19f2511a39397f76359e4cc6ee93072 ]
Free tracing_data structure in tracing_data_get() error paths.
Fixes the following coverity complaint:
Error: RESOURCE_LEAK (CWE-772):
leaked_storage: Variable "tdata" going out of scope leaks the storage
From: Emmanuel Grumbach
[ Upstream commit 155f7e0441cd121b1e673d465a35e99f4b9b2f0b ]
Fix a bug that happens in the following scenario:
1) suspend without WoWLAN
2) mac80211 calls drv_stop because of the suspend
3) __iwl_mvm_mac_stop deallocates the aux station
4) during drv_stop the firmware
From: Wang Dongsheng
[ Upstream commit c7eabbee3de99347105faa7fd925a500ccf43baf ]
The device specific resource can be free in free_slot after
removing host controller.
Signed-off-by: Wang Dongsheng
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin
---
From: Nathan Chancellor
[ Upstream commit a1108c7b2efb892350ba6a0e932dfd45622f4e2b ]
Clang warns when one enumerated type is implicitly converted to another.
drivers/spi/spi-ep93xx.c:342:62: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different
From: Nathan Chancellor
[ Upstream commit a1108c7b2efb892350ba6a0e932dfd45622f4e2b ]
Clang warns when one enumerated type is implicitly converted to another.
drivers/spi/spi-ep93xx.c:342:62: warning: implicit conversion from
enumeration type 'enum dma_transfer_direction' to different
From: Sanskriti Sharma
[ Upstream commit ce49d8436cffa9b7a6a5f110879d53e89dbc6746 ]
Ensure that all code paths in strbuf_addv() call va_end() on the
ap_saved copy that was made.
Fixes the following coverity complaint:
Error: VARARGS (CWE-237): [#def683]
tools/perf/util/strbuf.c:106:
From: Prarit Bhargava
[ Upstream commit f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6 ]
cpupower crashes on VMWare guests. The guests have the AMD PStateDef MSR
(0xC0010064 + state number) set to zero. As a result fid and did are zero
and the crash occurs because of a divide by zero (cof =
From: Sanskriti Sharma
[ Upstream commit ce49d8436cffa9b7a6a5f110879d53e89dbc6746 ]
Ensure that all code paths in strbuf_addv() call va_end() on the
ap_saved copy that was made.
Fixes the following coverity complaint:
Error: VARARGS (CWE-237): [#def683]
tools/perf/util/strbuf.c:106:
From: Prarit Bhargava
[ Upstream commit f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6 ]
cpupower crashes on VMWare guests. The guests have the AMD PStateDef MSR
(0xC0010064 + state number) set to zero. As a result fid and did are zero
and the crash occurs because of a divide by zero (cof =
101 - 200 of 2040 matches
Mail list logo
