On Tue, Sep 22, 2020 at 10:21:43PM +0200, Arnd Bergmann wrote:
> My earlier patches caused some new sparse warnings, but it turns out
> that a number of those are actual bugs, or at least suspicous code.
>
> Adding __user annotations to the data structures that are defined in
> uapi headers helps
On Tue, Sep 22, 2020 at 07:43:36PM -0600, Shuah Khan wrote:
> counter_atomic is introduced to be used when a variable is used as
> a simple counter and doesn't guard object lifetimes. This clearly
> differentiates atomic_t usages that guard object lifetimes.
>
> counter_atomic variables will wrap
-a001-20200923
i386 randconfig-a002-20200922
i386 randconfig-a006-20200922
i386 randconfig-a003-20200922
i386 randconfig-a004-20200922
i386 randconfig-a005-20200922
i386 randconfig-a001-20200922
i386
Hi Arnd,
I love your patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/staging-vchiq-fix-__user-annotations/20200923-042315
base:
counter_atomic is introduced to be used when a variable is used as
a simple counter and doesn't guard object lifetimes. This clearly
differentiates atomic_t usages that guard object lifetimes.
counter_atomic variables will wrap around to 0 when it overflows and
should not be used to guard
This patch series is a result of discussion at the refcount_t BOF
the Linux Plumbers Conference. In this discussion, we identifed
a need for looking closely and investigating atomic_t usages in
the kernel when it is used strictly as a counter wothout it
controlling object lifetimes and state
On Sat, 12 Sep 2020 16:30:51 +0200, Martin Cerveny wrote:
> Allwinner V3s SoC contains video engine. Add compatible for it.
>
> Signed-off-by: Martin Cerveny
> ---
> .../bindings/media/allwinner,sun4i-a10-video-engine.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob
On Sat, 12 Sep 2020 16:30:48 +0200, Martin Cerveny wrote:
> Allwinner V3s has system control similar to that in H3.
> Add compatibles for system control with SRAM C1 region.
>
> Signed-off-by: Martin Cerveny
> ---
> .../bindings/sram/allwinner,sun4i-a10-system-control.yaml | 6 ++
> 1
As found earlier, there is a problem in the create_pagelist() function
that takes a pointer argument that either points into vmalloc space or
into user space, with the pointer value controlled by user space allowing
a malicious user to trick the driver into accessing the kernel instead.
Avoid
My earlier patches caused some new sparse warnings, but it turns out
that a number of those are actual bugs, or at least suspicous code.
Adding __user annotations to the data structures that are defined in
uapi headers helps avoid the new warnings, but that causes a different
set of warnings to
randconfig-a005-20200921
x86_64 randconfig-a003-20200921
x86_64 randconfig-a004-20200921
x86_64 randconfig-a002-20200921
x86_64 randconfig-a006-20200921
x86_64 randconfig-a001-20200921
x86_64 randconfig-a011-20200922
On Tue, Sep 22, 2020 at 06:16:01AM +0100, Christoph Hellwig wrote:
> > + fh->buffers.buffer[i].v4l.fbuffer = mem;
> > + fh->buffers.buffer[i].v4l.fbuffer_phys = virt_to_phys(mem);
> > + fh->buffers.buffer[i].v4l.fbuffer_bus = virt_to_bus(mem);
> > + for (off
On Tue, Sep 22, 2020 at 09:52:24AM +0200, Greg Kroah-Hartman wrote:
> On Sun, Sep 20, 2020 at 10:30:00PM -0700, James Browning wrote:
> > Removed repeated words "the" and "in"
> >
> > Signed-off-by: James Browning
> > ---
> > drivers/staging/comedi/comedi.h | 4 ++--
> > 1 file changed, 2
On Wed, Jul 22, 2020 at 9:56 AM Helen Koike wrote:
>
> aclk_isp_wrap is a child of aclk_isp, and hclk_isp_wrap is a child of
> hclk_isp, thus we can remove parents from the list.
>
> Also, for the isp0, we only need the ISP clock, ACLK and HCLK.
> In the future we'll need a pixel clock for RK3288
[snip]
> > That sounds more sensible. I've also just noticed that I introduced a bug in
> > the first patch when rebasing it :-/, so let's hold off on the whole series
> > and I'll do a proper tidy and resend after the next merge window.
>
> Is the bug the memory leak if
On Tue, Sep 22, 2020 at 12:02:33PM +0100, Alex Dewar wrote:
> On 22/09/2020 10:27, Mauro Carvalho Chehab wrote:
> > Em Tue, 22 Sep 2020 10:09:07 +0100
> > Alex Dewar escreveu:
> >
> > > Hi Mauro,
> > >
> > > I've rebased the patches now, but there is a slight hiccup. For patches 2
> > > and 3
On 22/09/2020 10:27, Mauro Carvalho Chehab wrote:
Em Tue, 22 Sep 2020 10:09:07 +0100
Alex Dewar escreveu:
Hi Mauro,
I've rebased the patches now, but there is a slight hiccup. For patches 2
and 3 of this series there will now be a conflict with commit 9289cdf39992
("staging: media: atomisp:
Em Tue, 22 Sep 2020 10:09:07 +0100
Alex Dewar escreveu:
> Hi Mauro,
>
> I've rebased the patches now, but there is a slight hiccup. For patches 2
> and 3 of this series there will now be a conflict with commit 9289cdf39992
> ("staging: media: atomisp: Convert to GPIO descriptors") in Greg's
On Fri, Aug 28, 2020 at 07:09:53PM +0530, Shubhrajyoti Datta wrote:
> +
> + /* Check status register */
> + err= readl_poll_timeout(divider->base + WZRD_DR_STATUS_REG_OFFSET,
> value,
> + value & WZRD_DR_LOCK_BIT_MASK,
> +
Hi Mauro,
I've rebased the patches now, but there is a slight hiccup. For patches 2
and 3 of this series there will now be a conflict with commit 9289cdf39992
("staging: media: atomisp: Convert to GPIO descriptors") in Greg's tree.
I'm not sure what the best way to handle this is? The merge
The function lm3554_remove() checks for the return code for
lm3554_gpio_uninit() even though this is on the exit path and exits the
function, leaving the variable flash unfreed. Instead, print a warning and
free flash unconditionally.
Signed-off-by: Alex Dewar
---
We don't really need to know that the LED pin reset successfully.
Signed-off-by: Alex Dewar
---
drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
The error path for lm3554_probe() contains a number of bugs, including:
* resource leaks
* jumping to error labels out of sequence
* not setting the return value appropriately
Fix it up and give the labels more memorable names.
This issue has existed since the code was originally contributed
On 22/09/2020 09:11, Mauro Carvalho Chehab wrote:
Em Mon, 21 Sep 2020 22:53:49 +0100
Alex Dewar escreveu:
Hi Mauro,
Over the last month I've sent a few scattered patches to fix various
warnings from static analysers, but they seem to have fallen through the
cracks? I'm reposting them here as
Em Mon, 21 Sep 2020 22:53:49 +0100
Alex Dewar escreveu:
> Hi Mauro,
>
> Over the last month I've sent a few scattered patches to fix various
> warnings from static analysers, but they seem to have fallen through the
> cracks? I'm reposting them here as a series to make them easier to
> review.
On Sun, Sep 20, 2020 at 10:30:00PM -0700, James Browning wrote:
> Removed repeated words "the" and "in"
>
> Signed-off-by: James Browning
> ---
> drivers/staging/comedi/comedi.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
What tree did you make this against? It's already in my
Em Mon, 21 Sep 2020 22:21:47 +0100
Alex Dewar escreveu:
> In hi3670_phy_probe(), when reading property tx-vboost-lvl fails, its
> default value is assigned to priv->eye_diagram_param, rather than to
> priv->tx_vboost_lvl. Fix this.
>
> Fixes: 8971a3b880b2 ("staging: hikey9xx: add USB physical
27 matches
Mail list logo
