The bodies of the if and else sections are the same, so just remove the
check.
Signed-off-by: Alex Dewar
---
.../staging/media/atomisp/pci/atomisp_cmd.c | 27 +--
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
b
The function ia_css_mipi_frame_specify() is not called from anywhere and
the comment above its declaration states that it should be removed when
there are no more users. So remove it.
Signed-off-by: Alex Dewar
---
drivers/staging/media/atomisp/pci/ia_css_mipi.h | 17 -
drivers
esource leaks")
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Alex Dewar
Reviewed-by: Dan Carpenter
---
v5: Check for error, not success (Dan), but do it correctly cf. v4 :)
v4: Rebase
v3: No changes
v2: Fix a couple more leaks on error p
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
---
.../staging/media/atomisp/i2c
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
b/drivers/staging/media/atomisp/i2c/at
Hi Mauro,
I'm reposting this series [1] as, following the merge window, it now
cleanly applies to both Linus' tree and to linux-next. I've made a minor
fix to patch #1 (see patch for details) but the other two patches have
just been rebased.
Best,
Alex
[1] See
https://lore.kernel.org/lkml/20200
[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 lm3554_platform_data_func(
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: medi
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 confl
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
---
.../staging/media/atomisp/i2c
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
b/drivers/staging/media/atomisp/i2c/at
esource leaks")
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Alex Dewar
Reviewed-by: Dan Carpenter
---
.../media/atomisp/i2c/atomisp-lm3554.c| 48 +++
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/
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 th
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
---
.../staging/media/atomisp/i2c
-off-by: Alex Dewar
---
.../staging/media/atomisp/pci/atomisp_cmd.c | 5 ++---
drivers/staging/media/atomisp/pci/sh_css.c| 20 +--
.../media/atomisp/pci/sh_css_firmware.c | 2 +-
3 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/media
In a few places in pci/sh_css_params.c, memset is used to zero memory
immediately before it is freed. As none of these structs appear to
contain sensitive information, just remove the calls to memset.
Suggested-by: Dan Carpenter
Signed-off-by: Alex Dewar
---
drivers/staging/media/atomisp/pci
esource leaks")
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Alex Dewar
Reviewed-by: Dan Carpenter
---
.../media/atomisp/i2c/atomisp-lm3554.c| 53 +++
1 file changed, 30 insertions(+), 23 deletions(-)
diff --git a/
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
b/drivers/staging/media/atomisp/i2c/at
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. If you do have any feedback that'd be great :)
Best,
Alex
__
97107: Incorrect expression (COPY_PASTE_ERROR)
Signed-off-by: Alex Dewar
---
v2: Fix my email address and a typo in title
drivers/staging/hikey9xx/phy-hi3670-usb3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/hikey9xx/phy-hi3670-usb3.c
b/drivers/staging/hik
97107: Incorrect expression (COPY_PASTE_ERROR)
Signed-off-by: Alex Dewar
---
drivers/staging/hikey9xx/phy-hi3670-usb3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/hikey9xx/phy-hi3670-usb3.c
b/drivers/staging/hikey9xx/phy-hi3670-usb3.c
index 42dbc20a0b9a..4fc
On 2020-09-03 19:24, Alex Dewar wrote:
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
Ping?
Fix it up and give the labels more memorable names.
This issue
On 2020-09-03 19:31, Alex Dewar wrote:
We don't really need to know that the LED pin reset successfully.
Ping?
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/at
On 2020-09-09 21:48, Alex Dewar wrote:
In a few places in pci/sh_css_params.c, memset is used to zero memory
immediately before it is freed. As none of these structs appear to
contain sensitive information, just remove the calls to memset.
Friendly ping?
Suggested-by: Dan Carpenter
Signed
In a few places in pci/sh_css_params.c, memset is used to zero memory
immediately before it is freed. As none of these structs appear to
contain sensitive information, just remove the calls to memset.
Suggested-by: Dan Carpenter
Signed-off-by: Alex Dewar
---
drivers/staging/media/atomisp/pci
On 2020-09-09 21:06, Dan Carpenter wrote:
On Wed, Sep 09, 2020 at 08:53:50PM +0100, Alex Dewar wrote:
In the file pci/sh_css_params.c, there are a number of places where
memset+kvfree is used, where kvfree_sensitive could be used instead. Fix
these occurrences.
This doesn't say *why
In the file pci/sh_css_params.c, there are a number of places where
memset+kvfree is used, where kvfree_sensitive could be used instead. Fix
these occurrences.
Issue identified with Coccinelle.
Signed-off-by: Alex Dewar
---
.../staging/media/atomisp/pci/sh_css_params.c | 19
-off-by: Alex Dewar
---
.../staging/media/atomisp/pci/atomisp_cmd.c | 5 ++---
drivers/staging/media/atomisp/pci/sh_css.c| 20 +--
.../media/atomisp/pci/sh_css_firmware.c | 2 +-
3 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/media
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. Print a warning instead
and free flash unconditionally.
Signed-off-by: Alex Dewar
---
.../staging/media/atomisp/i2c
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
b/drivers/staging/media/atomisp/i2c/at
esource leaks")
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Alex Dewar
---
.../media/atomisp/i2c/atomisp-lm3554.c| 53 +++
1 file changed, 30 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/media/ato
> You're right. I wonder if there is really any need for the
> lm3554_gpio_uninit() function at all? It's basically the same as
> lm3554_gpio_init() except for the order of function calls. Probably
> we could just rename lm3554_gpio_init() to something like
> lm3554_gpio_set_default() and use it
Good point about the timer!
> >
> > - err = lm3554_gpio_init(client);
> > - if (err) {
> > + ret = lm3554_gpio_init(client);
> > + if (ret) {
> > dev_err(&client->dev, "gpio request/direction_output fail");
> > - goto fail2;
> > + goto err_cleanup_entity;
eak")
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Alex Dewar
---
.../media/atomisp/i2c/atomisp-lm3554.c| 47 ++-
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/ato
In a number of places in emxx_udc.c, there are variables which are
assigned to without that value ever being used. Remove these pointless
assignments.
Reported-by: kernel test robot
Fixes: 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile USB Gadget driver")
Signed-off-by:
On Wed, Sep 02, 2020 at 11:15:47AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> staging-testing
> head: 4c6491a343e91a5a2a699b0b545f8ba1ec1e8c65
> commit: fbcfdfab4a2c4ec5e2195929528506fec39388f3 [62/88] staging: emxx_udc:
> Allo
ot;staging: emxx_udc: Add Emma Mobile USB Gadget driver")
Reported-by: Dan Carpenter
Signed-off-by: Alex Dewar
---
v2: also fix call to dma_free_coherent() (Dan)
@Magnus: I noticed you contributed this code back in 2014... I don't
suppose you happen to have the hardware lying around to test
On Tue, Aug 25, 2020 at 10:37:13AM +0300, Dan Carpenter wrote:
> On Mon, Aug 24, 2020 at 04:57:12PM +0100, Alex Dewar wrote:
> > On Mon, Aug 24, 2020 at 04:19:17PM +0100, Alex Dewar wrote:
> > > In nbu2ss_eq_queue() memory is allocated with dma_alloc_coherent(),
> > >
On Mon, Aug 24, 2020 at 04:19:17PM +0100, Alex Dewar wrote:
> In nbu2ss_eq_queue() memory is allocated with dma_alloc_coherent(),
> though, strangely, NULL is passed as the struct device* argument. Pass
> the UDC's device instead.
>
> Build-tested on x86 only.
>
> Fix
In nbu2ss_eq_queue() memory is allocated with dma_alloc_coherent(),
though, strangely, NULL is passed as the struct device* argument. Pass
the UDC's device instead.
Build-tested on x86 only.
Fixes: 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile USB Gadget driver")
Signed-off
Currently the module can only be test built on ARM, although it seems to
build fine on x86. Change this to allow for broader test coverage.
Signed-off-by: Alex Dewar
---
drivers/staging/emxx_udc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/emxx_udc
On Tue, Aug 18, 2020 at 07:29:02AM -0700, Randy Dunlap wrote:
> On 8/18/20 6:49 AM, Alex Dewar wrote:
> > Currently emxx_udc.h defines bit values using local macros. Use the
> > standard one instead.
> >
> > Also, combine bit values with bitwise-or rather than ad
Currently emxx_udc.h defines bit values using local macros. Use the
standard one instead.
Also, combine bit values with bitwise-or rather than addition, as
suggested by Coccinelle.
Signed-off-by: Alex Dewar
---
drivers/staging/emxx_udc/emxx_udc.h | 456 +---
1 file
On 13/07/2019 16:17, Heiko Stuebner wrote:
Hi,
Am Samstag, 13. Juli 2019, 13:38:45 CEST schrieb Alex Dewar:
I initially thought my machine was failing to boot entirely, but it
turns out it was just failing to start the display manager. I managed to
escape to a tty by hammering the keyboard a
Hi all,
I initially thought my machine was failing to boot entirely, but it
turns out it was just failing to start the display manager. I managed to
escape to a tty by hammering the keyboard a bit.
I suspect the culprit is the rockchip_vpu driver (in staging/media),
which has been renamed to han
45 matches
Mail list logo
