Document bindings for IMX8MQ VPU reset hardware block
Signed-off-by: Benjamin Gaignard
---
.../bindings/reset/fsl,imx8mq-vpu-reset.yaml | 54 +++
include/dt-bindings/reset/imx8mq-vpu-reset.h | 16 ++
2 files changed, 70 insertions(+)
create mode 100644
Documentation/devic
Document IMX8MQ VPU bindings to add the phandle to the reset driver.
Provide an independent reset driver allow to the both VPUs to share
their control/reset hardware block. The reset driver replace what
was previously done be using the 'ctrl' registers inside the driver.
This breaks the compatibi
IMX8MQ SoC got a dedicated hardware block to reset the video processor
units (G1 and G2).
Signed-off-by: Benjamin Gaignard
---
drivers/reset/Kconfig| 8 ++
drivers/reset/Makefile | 1 +
drivers/reset/reset-imx8mq-vpu.c | 169 +++
3 files chan
Rather use a reset like feature inside the driver use the reset
controller API to get the same result.
Signed-off-by: Benjamin Gaignard
---
drivers/staging/media/hantro/Kconfig| 1 +
drivers/staging/media/hantro/imx8m_vpu_hw.c | 61 -
2 files changed, 12 insertions(+
The two VPUs inside IMX8MQ share the same control block which can be see
as a reset hardware block.
In order to be able to add the second VPU (for HECV decoding) it will be
more handy if the both VPU drivers instance don't have to share the
control block registers. This lead to implement it as an i
Add a vpu reset hardware block node.
Signed-off-by: Benjamin Gaignard
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 ++-
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
Fixes this checkpatch warning
WARNING: Integer promotion: Using 'h' in '%04hx' is unnecessary
Signed-off-by: Lee Gibson
---
drivers/staging/fwserial/fwserial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fwserial/fwserial.c
b/drivers/staging/fwserial/fwse
Function _rtl92e_wx_set_scan calls memcpy without checking the length.
A user could control that length and trigger a buffer overflow.
Fix by checking the length is within the maximum allowed size.
Signed-off-by: Lee Gibson
---
drivers/staging/rtl8192e/rtl8192e/rtl_wx.c | 3 +++
1 file changed,
On Fri, Feb 26, 2021 at 11:48:29AM +, Lee Gibson wrote:
> Function _rtl92e_wx_set_scan calls memcpy without checking the length.
> A user could control that length and trigger a buffer overflow.
> Fix by checking the length is within the maximum allowed size.
>
> Signed-off-by: Lee Gibson
> -
On Fri, Feb 26, 2021 at 01:06:46PM +0100, Greg KH wrote:
> On Fri, Feb 26, 2021 at 11:48:29AM +, Lee Gibson wrote:
> > Function _rtl92e_wx_set_scan calls memcpy without checking the length.
> > A user could control that length and trigger a buffer overflow.
> > Fix by checking the length is wit
Function _rtl92e_wx_set_scan calls memcpy without checking the length.
A user could control that length and trigger a buffer overflow.
Fix by checking the length is within the maximum allowed size.
Changes in v2:
Changed to use min_t as per useful suggestions
Signed-off-by: Lee Gibson
-
On Fri, Feb 26, 2021 at 11:48:29AM +, Lee Gibson wrote:
> Function _rtl92e_wx_set_scan calls memcpy without checking the length.
> A user could control that length and trigger a buffer overflow.
> Fix by checking the length is within the maximum allowed size.
>
> Signed-off-by: Lee Gibson
> -
On Fri, Feb 26, 2021 at 01:27:25PM +, Lee Gibson wrote:
> Function _rtl92e_wx_set_scan calls memcpy without checking the length.
> A user could control that length and trigger a buffer overflow.
> Fix by checking the length is within the maximum allowed size.
>
> Changes in v2:
> Change
Here is a v2 of my check. I've changed it to mark all "->ssid" and
everything in "(struct ieee80211_network)" as protected. I'm just
playing around with it at this point to explore what works best. It's
impossible to know until after some results come back.
regards,
dan carpenter
#include "sma
From: Arnd Bergmann
The atomisp_set_fmt() function has multiple copies of the large
v4l2_format structure on its stack, resulting in a warning about
excessive stack usage in some rare randconfig builds.
drivers/staging/media/atomisp/pci/atomisp_cmd.c:5600:5: error: stack frame size
of 1084 byte
On Fri, Feb 26, 2021 at 03:05:02PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The atomisp_set_fmt() function has multiple copies of the large
> v4l2_format structure on its stack, resulting in a warning about
> excessive stack usage in some rare randconfig builds.
>
> drivers/staging/
Function _rtl92e_wx_set_scan calls memcpy without checking the length.
A user could control that length and trigger a buffer overflow.
Fix by checking the length is within the maximum allowed size.
Reviewed-by: Dan Carpenter
Signed-off-by: Lee Gibson
---
drivers/staging/rtl8192e/rtl8192e/rtl_wx
On Fri, Feb 26, 2021 at 02:51:57PM +, Lee Gibson wrote:
> Function _rtl92e_wx_set_scan calls memcpy without checking the length.
> A user could control that length and trigger a buffer overflow.
> Fix by checking the length is within the maximum allowed size.
>
> Reviewed-by: Dan Carpenter
>
allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a001-20210226
x86_64 randconfig-a002-20210226
x86_64 randconfig-a003
19 matches
Mail list logo
