Add the missing unlock before return from function
gbaudio_dapm_free_controls() in the error handling case.
Fixes: 510e340efe0c ("staging: greybus: audio: Add helper APIs for dynamic
audio module")
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
---
drivers/staging/greybus/audio_helper.c | 1 +
From: Arnd Bergmann
When the MMAL code is built-in but the vchiq core config is
set to =m, the mmal code never gets built, which in turn can
lead to link errors:
ERROR: modpost: "vchiq_mmal_port_set_format"
[drivers/staging/vc04_services/bcm2835-camera/bcm2835-v4l2.ko] undefined!
ERROR: modpost
Good Day
I am JABER AL-GHAFRI, Pleasant greetings to you as i seek your indulgence to
introduce to you the desire of my principal’s wish, to make huge financial
investment in your home country on areas of oil and gas, real estate, tourism
and hotel, manufacturing and production company, agricult
On Fri, Dec 4, 2020 at 12:25 AM Martin Cerveny wrote:
>
> Hello.
>
> On Thu, 3 Dec 2020, Chen-Yu Tsai wrote:
>
> > Hi,
> >
> > On Mon, Nov 16, 2020 at 8:57 PM Martin Cerveny
> > wrote:
> >>
> >> Allwinner V3s has system control and SRAM C1 region similar to H3.
> >>
> >> Signed-off-by: Martin Ce
Hello.
On Thu, 3 Dec 2020, Chen-Yu Tsai wrote:
Hi,
On Mon, Nov 16, 2020 at 8:57 PM Martin Cerveny wrote:
Allwinner V3s has system control and SRAM C1 region similar to H3.
Signed-off-by: Martin Cerveny
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 14 ++
1 file changed, 14 insertion
On Tue, 2020-12-01 at 22:03 -0800, Dmitry Torokhov wrote:
> Hi Nicolas,
>
> On Mon, Nov 23, 2020 at 07:38:29PM +0100, Nicolas Saenz Julienne wrote:
> > Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
> > interface when unbinding the device.
>
> I do not believe this comme
On Thu, Dec 03, 2020 at 02:25:15PM +0100, Greg KH wrote:
> On Thu, Dec 03, 2020 at 01:47:53PM +0100, Enrico Weigelt, metux IT consult
> wrote:
> > Remove MODULE_VERSION(), as it doesn't seem to serve any practical
> > purpose. For in-tree drivers, the kernel version matters.
> >
> > The drivers h
From: Hao Si
[ Upstream commit 2663b3388551230cbc4606a40fabf3331ceb59e4 ]
The local variable 'cpumask_t mask' is in the stack memory, and its address
is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'.
But the memory area where this variable is located is at risk of being
modified.
Du
On Thu, Dec 03, 2020 at 01:47:53PM +0100, Enrico Weigelt, metux IT consult
wrote:
> Remove MODULE_VERSION(), as it doesn't seem to serve any practical
> purpose. For in-tree drivers, the kernel version matters.
>
> The drivers have received lots of changes, without the module version
> (or the un
Remove MODULE_VERSION(), as it doesn't seem to serve any practical purpose.
For in-tree drivers, the kernel version really matters. The module version
doesn't seem to be maintained and having much practical meaning anymore.
Signed-off-by: Enrico Weigelt
---
drivers/staging/qlge/qlge_main.c | 1 -
Remove MODULE_VERSION(), as it doesn't seem to have much practical purpose.
For in-kernel drivers, the kernel version matters. The driver received lots
of changes, but version number has remained the same since it's introducing
into mainline, seven years ago. So, it doesn't seem to have much practi
Remove MODULE_VERSION(), as it doesn't seem to serve any practical purpose.
For in-kernel drivers, the kernel version matters. And the code has received
lots of changes, without the version ever been touched (remained constant
since landing in the mainline tree), so it doesn't seem to have any prac
Remove MODULE_VERSION(), as it doesn't seem to have any practical purpose:
the driver has received lots of changes, while the module version remained
constant. Unmaintained version numbers aren't actually useful.
Signed-off-by: Enrico Weigelt
---
drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 1
Remove MODULE_VERSION(), as it doesn't seem to have any pratical purpose.
The code received lots of huge changes, but module version remained constant,
since it landed in mainline tree, back 11 years go. Unmaintained version
numbers aren't actually useful. For in-tree drivers, the kernel version
re
Remove MODULE_VERSION(), as it doesn't seem to serve any practical purpose.
For in-kernel drivers, the kernel version matters most. The driver received
lots of changes, while module version remained constant, since it landed
in mainline, back 7 years ago.
Signed-off-by: Enrico Weigelt
---
driver
Remove MODULE_VERSION(), as it doesn't seem to serve any practical
purpose. For in-tree drivers, the kernel version matters.
The drivers have received lots of changes, without the module version
(or the underlying DRV_VERSION macro) ever changed, since the code
landed in the kernel tree. So, it do
Remove MODULE_VERSION(), as it doesn't seem to serve any practical purpose.
For in-tree drivers, the kernel version matters. The code has received lots
of changes, w/o the versions being actively maintained, so it doesn't seem
to have much practical meaning.
Signed-off-by: Enrico Weigelt
---
dri
Remove MODULE_VERSION(), as it doesn't seem to serve any practical purpose.
For in-tree drivers, the kernel version matters. The code received lots of
changes, but module version remained constant, since the driver landed in
mainline. So, this version doesn't seem have any practical meaning anymore
Remove MODULE_VERSION(), as it doesn't seem to serve any practical purpose.
The driver received lots of changes, but module remained constant since
it landed in mainline, several years ago.
Signed-off-by: Enrico Weigelt
---
drivers/staging/rtl8723bs/os_dep/os_intfs.c | 1 -
1 file changed, 1 del
Remove MODULE_VERSION(), as it doesn't seem to have any practical purpose.
For in-tree drivers, the kernel version really matters. OTOH, the module
version doesn't seem to be actively maintained - the code received changes
while the version remained constant.
Signed-off-by: Enrico Weigelt
---
dr
On Thu, 2020-12-03 at 09:05 +0100, Bartosz Golaszewski wrote:
> On Mon, Nov 23, 2020 at 7:38 PM Nicolas Saenz Julienne
> wrote:
> >
> > When unbinding the firmware device we need to make sure it has no
> > consumers left. Otherwise we'd leave them with a firmware handle
> > pointing at freed memo
On Mon, Nov 23, 2020 at 7:38 PM Nicolas Saenz Julienne
wrote:
>
> When unbinding the firmware device we need to make sure it has no
> consumers left. Otherwise we'd leave them with a firmware handle
> pointing at freed memory.
>
> Keep a reference count of all consumers and introduce rpi_firmware_
22 matches
Mail list logo
