* Re: [PATCH] staging: sm750fb: modify function name to kernel code style
From: Richard Akintola @ 2025-04-04 7:36 UTC (permalink / raw)
To: Greg KH
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel, julia.lawall
In-Reply-To: <2025040443-serrated-flying-c329@gregkh>
On Fri, Apr 4, 2025 at 7:22 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
>
> A: http://en.wikipedia.org/wiki/Top_post
> Q: Were do I find info about this thing called top-posting?
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> A: No.
> Q: Should I include quotations after my reply?
>
>
> http://daringfireball.net/2007/07/on_top
Thank you for educating me on top-posting, and I really appreciate that it was
given in a top-posting style making me realise the consequences by experience.
> Please send it as a patch series.
I will send in the patch series as advised.
Richard Akintola
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: modify function name to kernel code style
From: Greg KH @ 2025-04-04 6:21 UTC (permalink / raw)
To: Richard Akintola
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel, julia.lawall
In-Reply-To: <CAMyr_bL3sh3HyL0=Qb1h21_-5dqJy0M0Ewo0JMFPNr=x28oNgw@mail.gmail.com>
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Thu, Apr 03, 2025 at 11:37:48PM +0100, Richard Akintola wrote:
> Hi,
>
> Yes I did send two different patches (part of the reason I used
> different subject lines),
> they did similar things (change camelCase to snake_case, I wanted to
> get all done in the file,
> but I learnt it is best done one at a time.
>
> So should I have it all done in the file (there are more than 2
> camelCase CHECKs), or send it
> one after the other? (but you could take the first).
Please send it as a patch series.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: modify function name to kernel code style
From: Richard Akintola @ 2025-04-03 22:37 UTC (permalink / raw)
To: Greg KH
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel, julia.lawall
In-Reply-To: <2025040301-tightness-giveaway-a568@gregkh>
Hi,
Yes I did send two different patches (part of the reason I used
different subject lines),
they did similar things (change camelCase to snake_case, I wanted to
get all done in the file,
but I learnt it is best done one at a time.
So should I have it all done in the file (there are more than 2
camelCase CHECKs), or send it
one after the other? (but you could take the first).
Thanks
Richard Akintola
On Thu, Apr 3, 2025 at 3:18 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Mar 31, 2025 at 09:53:36AM +0100, Richard Akintola wrote:
> > Change camelCase function name sii164ResetChip to sii164_reset_chip
> > as reported by checkpatch.pl
> >
> > CHECK: Avoid camelCase: <sii164ResetChip>
> >
> > Signed-off-by: Richard Akintola <princerichard17a@gmail.com>
> > ---
> > drivers/staging/sm750fb/ddk750_dvi.c | 2 +-
> > drivers/staging/sm750fb/ddk750_sii164.c | 4 ++--
> > drivers/staging/sm750fb/ddk750_sii164.h | 2 +-
> > 3 files changed, 4 insertions(+), 4 deletions(-)
>
> You sent 2 different patches with different subject lines, yet they
> almost did the same thing? Which one should I take or review? Please
> send a new one, as a version 3, and properly document what changed
> between this one and the last 2 submissions.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH AUTOSEL 5.4 8/9] fbdev: omapfb: Add 'plane' value check
From: Sasha Levin @ 2025-04-03 19:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Leonid Arapov, Helge Deller, Sasha Levin, krzysztof.kozlowski,
tzimmermann, u.kleine-koenig, linux, linux-omap, linux-fbdev,
dri-devel
In-Reply-To: <20250403192050.2682427-1-sashal@kernel.org>
From: Leonid Arapov <arapovl839@gmail.com>
[ Upstream commit 3e411827f31db7f938a30a3c7a7599839401ec30 ]
Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.
The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.
For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.
For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.
Add check for this value.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Signed-off-by: Leonid Arapov <arapovl839@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index 34e8171856e95..5570f2359d073 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -2787,9 +2787,13 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool mem_to_mem)
{
int r;
- enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
+ enum omap_overlay_caps caps;
enum omap_channel channel;
+ if (plane == OMAP_DSS_WB)
+ return -EINVAL;
+
+ caps = dss_feat_get_overlay_caps(plane);
channel = dispc_ovl_get_channel_out(plane);
DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d ->"
--
2.39.5
^ permalink raw reply related
* [PATCH AUTOSEL 5.10 8/8] fbdev: omapfb: Add 'plane' value check
From: Sasha Levin @ 2025-04-03 19:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Leonid Arapov, Helge Deller, Sasha Levin, krzysztof.kozlowski,
u.kleine-koenig, linux, linux-omap, linux-fbdev, dri-devel
In-Reply-To: <20250403192031.2682315-1-sashal@kernel.org>
From: Leonid Arapov <arapovl839@gmail.com>
[ Upstream commit 3e411827f31db7f938a30a3c7a7599839401ec30 ]
Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.
The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.
For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.
For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.
Add check for this value.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Signed-off-by: Leonid Arapov <arapovl839@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index b2d6e6df21615..d852bef1d507f 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -2751,9 +2751,13 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool mem_to_mem)
{
int r;
- enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
+ enum omap_overlay_caps caps;
enum omap_channel channel;
+ if (plane == OMAP_DSS_WB)
+ return -EINVAL;
+
+ caps = dss_feat_get_overlay_caps(plane);
channel = dispc_ovl_get_channel_out(plane);
DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d ->"
--
2.39.5
^ permalink raw reply related
* [PATCH AUTOSEL 5.15 11/12] fbdev: omapfb: Add 'plane' value check
From: Sasha Levin @ 2025-04-03 19:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Leonid Arapov, Helge Deller, Sasha Levin, krzysztof.kozlowski,
linux, u.kleine-koenig, linux-omap, linux-fbdev, dri-devel
In-Reply-To: <20250403192001.2682149-1-sashal@kernel.org>
From: Leonid Arapov <arapovl839@gmail.com>
[ Upstream commit 3e411827f31db7f938a30a3c7a7599839401ec30 ]
Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.
The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.
For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.
For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.
Add check for this value.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Signed-off-by: Leonid Arapov <arapovl839@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index b2d6e6df21615..d852bef1d507f 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -2751,9 +2751,13 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool mem_to_mem)
{
int r;
- enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
+ enum omap_overlay_caps caps;
enum omap_channel channel;
+ if (plane == OMAP_DSS_WB)
+ return -EINVAL;
+
+ caps = dss_feat_get_overlay_caps(plane);
channel = dispc_ovl_get_channel_out(plane);
DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d ->"
--
2.39.5
^ permalink raw reply related
* [PATCH AUTOSEL 6.1 18/20] fbdev: omapfb: Add 'plane' value check
From: Sasha Levin @ 2025-04-03 19:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Leonid Arapov, Helge Deller, Sasha Levin, krzysztof.kozlowski,
u.kleine-koenig, tzimmermann, linux, linux-omap, linux-fbdev,
dri-devel
In-Reply-To: <20250403191913.2681831-1-sashal@kernel.org>
From: Leonid Arapov <arapovl839@gmail.com>
[ Upstream commit 3e411827f31db7f938a30a3c7a7599839401ec30 ]
Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.
The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.
For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.
For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.
Add check for this value.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Signed-off-by: Leonid Arapov <arapovl839@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index 92fb6b7e1f681..a6225f9621902 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -2749,9 +2749,13 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool mem_to_mem)
{
int r;
- enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
+ enum omap_overlay_caps caps;
enum omap_channel channel;
+ if (plane == OMAP_DSS_WB)
+ return -EINVAL;
+
+ caps = dss_feat_get_overlay_caps(plane);
channel = dispc_ovl_get_channel_out(plane);
DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d ->"
--
2.39.5
^ permalink raw reply related
* [PATCH AUTOSEL 6.6 20/23] fbdev: omapfb: Add 'plane' value check
From: Sasha Levin @ 2025-04-03 19:18 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Leonid Arapov, Helge Deller, Sasha Levin, krzysztof.kozlowski,
linux, tzimmermann, u.kleine-koenig, linux-omap, linux-fbdev,
dri-devel
In-Reply-To: <20250403191816.2681439-1-sashal@kernel.org>
From: Leonid Arapov <arapovl839@gmail.com>
[ Upstream commit 3e411827f31db7f938a30a3c7a7599839401ec30 ]
Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.
The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.
For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.
For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.
Add check for this value.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Signed-off-by: Leonid Arapov <arapovl839@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index 21fef9db90d26..4f09111f8b57e 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -2749,9 +2749,13 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool mem_to_mem)
{
int r;
- enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
+ enum omap_overlay_caps caps;
enum omap_channel channel;
+ if (plane == OMAP_DSS_WB)
+ return -EINVAL;
+
+ caps = dss_feat_get_overlay_caps(plane);
channel = dispc_ovl_get_channel_out(plane);
DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d ->"
--
2.39.5
^ permalink raw reply related
* [PATCH AUTOSEL 6.12 29/33] fbdev: omapfb: Add 'plane' value check
From: Sasha Levin @ 2025-04-03 19:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Leonid Arapov, Helge Deller, Sasha Levin, krzysztof.kozlowski,
linux, u.kleine-koenig, linux-omap, linux-fbdev, dri-devel
In-Reply-To: <20250403191656.2680995-1-sashal@kernel.org>
From: Leonid Arapov <arapovl839@gmail.com>
[ Upstream commit 3e411827f31db7f938a30a3c7a7599839401ec30 ]
Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.
The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.
For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.
For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.
Add check for this value.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Signed-off-by: Leonid Arapov <arapovl839@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index 5832485ab998c..c29b6236952b3 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -2749,9 +2749,13 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool mem_to_mem)
{
int r;
- enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
+ enum omap_overlay_caps caps;
enum omap_channel channel;
+ if (plane == OMAP_DSS_WB)
+ return -EINVAL;
+
+ caps = dss_feat_get_overlay_caps(plane);
channel = dispc_ovl_get_channel_out(plane);
DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d ->"
--
2.39.5
^ permalink raw reply related
* [PATCH AUTOSEL 6.13 33/37] fbdev: omapfb: Add 'plane' value check
From: Sasha Levin @ 2025-04-03 19:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Leonid Arapov, Helge Deller, Sasha Levin, krzysztof.kozlowski,
linux, tzimmermann, u.kleine-koenig, linux-omap, linux-fbdev,
dri-devel
In-Reply-To: <20250403191513.2680235-1-sashal@kernel.org>
From: Leonid Arapov <arapovl839@gmail.com>
[ Upstream commit 3e411827f31db7f938a30a3c7a7599839401ec30 ]
Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.
The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.
For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.
For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.
Add check for this value.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Signed-off-by: Leonid Arapov <arapovl839@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index c3329c8b4c169..7ddbb3422ea8b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -2738,9 +2738,13 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool mem_to_mem)
{
int r;
- enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
+ enum omap_overlay_caps caps;
enum omap_channel channel;
+ if (plane == OMAP_DSS_WB)
+ return -EINVAL;
+
+ caps = dss_feat_get_overlay_caps(plane);
channel = dispc_ovl_get_channel_out(plane);
DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d ->"
--
2.39.5
^ permalink raw reply related
* [PATCH AUTOSEL 6.14 39/44] fbdev: omapfb: Add 'plane' value check
From: Sasha Levin @ 2025-04-03 19:13 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Leonid Arapov, Helge Deller, Sasha Levin, krzysztof.kozlowski,
u.kleine-koenig, tzimmermann, linux, linux-omap, linux-fbdev,
dri-devel
In-Reply-To: <20250403191313.2679091-1-sashal@kernel.org>
From: Leonid Arapov <arapovl839@gmail.com>
[ Upstream commit 3e411827f31db7f938a30a3c7a7599839401ec30 ]
Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.
The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.
For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.
For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.
Add check for this value.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Signed-off-by: Leonid Arapov <arapovl839@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index ccb96a5be07e4..139476f9d9189 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -2738,9 +2738,13 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool mem_to_mem)
{
int r;
- enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
+ enum omap_overlay_caps caps;
enum omap_channel channel;
+ if (plane == OMAP_DSS_WB)
+ return -EINVAL;
+
+ caps = dss_feat_get_overlay_caps(plane);
channel = dispc_ovl_get_channel_out(plane);
DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d ->"
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: modify function name to kernel code style
From: Greg KH @ 2025-04-03 14:16 UTC (permalink / raw)
To: Richard Akintola
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, linux-staging,
linux-kernel, julia.lawall
In-Reply-To: <67ea5813.5d0a0220.293276.775e@mx.google.com>
On Mon, Mar 31, 2025 at 09:53:36AM +0100, Richard Akintola wrote:
> Change camelCase function name sii164ResetChip to sii164_reset_chip
> as reported by checkpatch.pl
>
> CHECK: Avoid camelCase: <sii164ResetChip>
>
> Signed-off-by: Richard Akintola <princerichard17a@gmail.com>
> ---
> drivers/staging/sm750fb/ddk750_dvi.c | 2 +-
> drivers/staging/sm750fb/ddk750_sii164.c | 4 ++--
> drivers/staging/sm750fb/ddk750_sii164.h | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
You sent 2 different patches with different subject lines, yet they
almost did the same thing? Which one should I take or review? Please
send a new one, as a version 3, and properly document what changed
between this one and the last 2 submissions.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/1] fbdev: atyfb: Fix buffer overflow
From: Ville Syrjälä @ 2025-04-01 16:26 UTC (permalink / raw)
To: Denis Arefev
Cc: deller, dri-devel, jani.nikula, linux-fbdev, linux-kernel,
lvc-project, tzimmermann
In-Reply-To: <20250401102330.7759-1-arefev@swemel.ru>
On Tue, Apr 01, 2025 at 01:23:30PM +0300, Denis Arefev wrote:
> > It's old, but still runs in some configurations and people
> > still (although probably not on daily bases) use it.
> > Also don't forget about the various old non-x86 hardware machines
> > which often used ATI cards too, and those machines are still
> > supported by Linux as well.
>
> Hi Helge.
> Thanks for the reply.
>
> Ok. Everyone agrees that there is an error (buffer overflow
> lt_lcd_regs[LCD_MISC_CNTL]).
As I said, that will never happen.
> Ok. Everyone agrees that this code is still needed.
>
> Then I propose to fix this error. :)
>
> Unfortunately, I can't do everything by the rules, I didn't save
> the chip datasheet. (I didn't think I would ever need it again.).
>
> Regards Denis.
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH] drivers: video: backlight: Fix NULL Pointer Dereference in backlight_device_register()
From: Daniel Thompson @ 2025-04-01 14:29 UTC (permalink / raw)
To: Haoyu Li
Cc: danielt, chenyuan0y, deller, dri-devel, jani.nikula, jingoohan1,
lee, linux-fbdev, linux-kernel, robh, stable, zichenxie0106
In-Reply-To: <20250219122950.7416-1-lihaoyu499@gmail.com>
Hi Haoyu
On Wed, Feb 19, 2025 at 08:29:50PM +0800, Haoyu Li wrote:
> As per Jani and Daniel's feedback, I have updated the patch so that
> the `wled->name` null check now occurs in the `wled_configure`
> function, right after the `devm_kasprintf` callsite. This should
> resolve the issue.
I'm afraid this patch got swamped in my mailbox and I missed it.
Worse, we've just been discussing and reviewing a patch for the same
issue from another developer:
https://lore.kernel.org/all/20250401091647.22784-1-bsdhenrymartin@gmail.com/
So, I just wanted to acknowlege the mistake. Sorry.
Daniel.
^ permalink raw reply
* Re: [PATCH v2 4/9] Input: pcf50633-input - Remove
From: Dr. David Alan Gilbert @ 2025-04-01 11:31 UTC (permalink / raw)
To: arnd, lee, dmitry.torokhov, sre, lgirdwood, broonie,
alexandre.belloni, danielt, jingoohan1, deller, linus.walleij,
brgl, tsbogend
Cc: linux-mips, linux-input, linux-pm, linux-rtc, dri-devel,
linux-fbdev, linux-gpio, linux-kernel
In-Reply-To: <20250311014959.743322-5-linux@treblig.org>
* linux@treblig.org (linux@treblig.org) wrote:
> From: "Dr. David Alan Gilbert" <linux@treblig.org>
>
> The pcf50633 was used as part of the OpenMoko devices but
> the support for its main chip was recently removed in:
> commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
>
> See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
>
> Remove it.
>
> Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Has anyone got this input patch lined up?
I think most of the other parts are there; the rtc I see in next.
Then once those go there is a core.h that needs nuking.
Dave
> ---
> drivers/input/misc/Kconfig | 7 --
> drivers/input/misc/Makefile | 1 -
> drivers/input/misc/pcf50633-input.c | 113 ----------------------------
> 3 files changed, 121 deletions(-)
> delete mode 100644 drivers/input/misc/pcf50633-input.c
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 13d135257e06..62819144bd8c 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -584,13 +584,6 @@ config INPUT_PALMAS_PWRBUTTON
> To compile this driver as a module, choose M here. The module will
> be called palmas_pwrbutton.
>
> -config INPUT_PCF50633_PMU
> - tristate "PCF50633 PMU events"
> - depends on MFD_PCF50633
> - help
> - Say Y to include support for delivering PMU events via input
> - layer on NXP PCF50633.
> -
> config INPUT_PCF8574
> tristate "PCF8574 Keypad input device"
> depends on I2C
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index 6d91804d0a6f..d468c8140b93 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -59,7 +59,6 @@ obj-$(CONFIG_INPUT_MC13783_PWRBUTTON) += mc13783-pwrbutton.o
> obj-$(CONFIG_INPUT_MMA8450) += mma8450.o
> obj-$(CONFIG_INPUT_PALMAS_PWRBUTTON) += palmas-pwrbutton.o
> obj-$(CONFIG_INPUT_PCAP) += pcap_keys.o
> -obj-$(CONFIG_INPUT_PCF50633_PMU) += pcf50633-input.o
> obj-$(CONFIG_INPUT_PCF8574) += pcf8574_keypad.o
> obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o
> obj-$(CONFIG_INPUT_PM8941_PWRKEY) += pm8941-pwrkey.o
> diff --git a/drivers/input/misc/pcf50633-input.c b/drivers/input/misc/pcf50633-input.c
> deleted file mode 100644
> index 6d046e236ba6..000000000000
> --- a/drivers/input/misc/pcf50633-input.c
> +++ /dev/null
> @@ -1,113 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-or-later
> -/* NXP PCF50633 Input Driver
> - *
> - * (C) 2006-2008 by Openmoko, Inc.
> - * Author: Balaji Rao <balajirrao@openmoko.org>
> - * All rights reserved.
> - *
> - * Broken down from monstrous PCF50633 driver mainly by
> - * Harald Welte, Andy Green and Werner Almesberger
> - */
> -
> -#include <linux/kernel.h>
> -#include <linux/module.h>
> -#include <linux/device.h>
> -#include <linux/platform_device.h>
> -#include <linux/input.h>
> -#include <linux/slab.h>
> -
> -#include <linux/mfd/pcf50633/core.h>
> -
> -#define PCF50633_OOCSTAT_ONKEY 0x01
> -#define PCF50633_REG_OOCSTAT 0x12
> -#define PCF50633_REG_OOCMODE 0x10
> -
> -struct pcf50633_input {
> - struct pcf50633 *pcf;
> - struct input_dev *input_dev;
> -};
> -
> -static void
> -pcf50633_input_irq(int irq, void *data)
> -{
> - struct pcf50633_input *input;
> - int onkey_released;
> -
> - input = data;
> -
> - /* We report only one event depending on the key press status */
> - onkey_released = pcf50633_reg_read(input->pcf, PCF50633_REG_OOCSTAT)
> - & PCF50633_OOCSTAT_ONKEY;
> -
> - if (irq == PCF50633_IRQ_ONKEYF && !onkey_released)
> - input_report_key(input->input_dev, KEY_POWER, 1);
> - else if (irq == PCF50633_IRQ_ONKEYR && onkey_released)
> - input_report_key(input->input_dev, KEY_POWER, 0);
> -
> - input_sync(input->input_dev);
> -}
> -
> -static int pcf50633_input_probe(struct platform_device *pdev)
> -{
> - struct pcf50633_input *input;
> - struct input_dev *input_dev;
> - int ret;
> -
> -
> - input = kzalloc(sizeof(*input), GFP_KERNEL);
> - if (!input)
> - return -ENOMEM;
> -
> - input_dev = input_allocate_device();
> - if (!input_dev) {
> - kfree(input);
> - return -ENOMEM;
> - }
> -
> - platform_set_drvdata(pdev, input);
> - input->pcf = dev_to_pcf50633(pdev->dev.parent);
> - input->input_dev = input_dev;
> -
> - input_dev->name = "PCF50633 PMU events";
> - input_dev->id.bustype = BUS_I2C;
> - input_dev->evbit[0] = BIT(EV_KEY) | BIT(EV_PWR);
> - set_bit(KEY_POWER, input_dev->keybit);
> -
> - ret = input_register_device(input_dev);
> - if (ret) {
> - input_free_device(input_dev);
> - kfree(input);
> - return ret;
> - }
> - pcf50633_register_irq(input->pcf, PCF50633_IRQ_ONKEYR,
> - pcf50633_input_irq, input);
> - pcf50633_register_irq(input->pcf, PCF50633_IRQ_ONKEYF,
> - pcf50633_input_irq, input);
> -
> - return 0;
> -}
> -
> -static void pcf50633_input_remove(struct platform_device *pdev)
> -{
> - struct pcf50633_input *input = platform_get_drvdata(pdev);
> -
> - pcf50633_free_irq(input->pcf, PCF50633_IRQ_ONKEYR);
> - pcf50633_free_irq(input->pcf, PCF50633_IRQ_ONKEYF);
> -
> - input_unregister_device(input->input_dev);
> - kfree(input);
> -}
> -
> -static struct platform_driver pcf50633_input_driver = {
> - .driver = {
> - .name = "pcf50633-input",
> - },
> - .probe = pcf50633_input_probe,
> - .remove = pcf50633_input_remove,
> -};
> -module_platform_driver(pcf50633_input_driver);
> -
> -MODULE_AUTHOR("Balaji Rao <balajirrao@openmoko.org>");
> -MODULE_DESCRIPTION("PCF50633 input driver");
> -MODULE_LICENSE("GPL");
> -MODULE_ALIAS("platform:pcf50633-input");
> --
> 2.48.1
>
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
* Re: [PATCH 1/1] fbdev: atyfb: Fix buffer overflow
From: Denis Arefev @ 2025-04-01 10:23 UTC (permalink / raw)
To: deller
Cc: arefev, dri-devel, jani.nikula, linux-fbdev, linux-kernel,
lvc-project, tzimmermann, ville.syrjala
In-Reply-To: <e04f012b-cf10-4a84-8fbe-ece1a06f0f66@gmx.de>
> It's old, but still runs in some configurations and people
> still (although probably not on daily bases) use it.
> Also don't forget about the various old non-x86 hardware machines
> which often used ATI cards too, and those machines are still
> supported by Linux as well.
Hi Helge.
Thanks for the reply.
Ok. Everyone agrees that there is an error (buffer overflow
lt_lcd_regs[LCD_MISC_CNTL]).
Ok. Everyone agrees that this code is still needed.
Then I propose to fix this error. :)
Unfortunately, I can't do everything by the rules, I didn't save
the chip datasheet. (I didn't think I would ever need it again.).
Regards Denis.
^ permalink raw reply
* Re: [v4?] backlight: pm8941: Add NULL check in wled_configure()
From: Markus Elfring @ 2025-04-01 10:00 UTC (permalink / raw)
To: Daniel Thompson, Henry Martin, linux-fbdev, linux-arm-msm,
dri-devel
Cc: LKML, Dmitry Baryshkov, Helge Deller, Jingoo Han, Lee Jones
In-Reply-To: <Z-uqpxcge0J99IPI@aspen.lan>
…
> patch description ;-). I think the original v3 was better worded.
…
Can you find the mentioning of adjustments helpful for better error handling?
Regards,
Markus
^ permalink raw reply
* [PATCH v4] backlight: pm8941: Add NULL check in wled_configure()
From: Henry Martin @ 2025-04-01 9:16 UTC (permalink / raw)
To: danielt
Cc: lee, jingoohan1, deller, linux-arm-msm, dri-devel, linux-fbdev,
linux-kernel, Henry Martin, Dmitry Baryshkov
In-Reply-To: <Z-uqpxcge0J99IPI@aspen.lan>
devm_kasprintf() returns NULL when memory allocation fails. Currently,
wled_configure() does not check for this case, which results in a NULL
pointer dereference.
Add NULL check after devm_kasprintf() to prevent this issue.
Fixes: f86b77583d88 ("backlight: pm8941: Convert to using %pOFn instead of device_node.name")
Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
---
V3 -> V4: No functional changes, just correcting the version number
V2 -> V3: Correct commit meessage and confirm this patch has considered
resource cleanup to avoid any subsequent issues, ensuring that errors
are handled properly and no resources are left in an inconsistent
state.
V1 -> V2: Fix commit message to use imperative mood and wrap lines to 75
characters.
drivers/video/backlight/qcom-wled.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c
index 9afe701b2a1b..a63bb42c8f8b 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -1406,9 +1406,11 @@ static int wled_configure(struct wled *wled)
wled->ctrl_addr = be32_to_cpu(*prop_addr);
rc = of_property_read_string(dev->of_node, "label", &wled->name);
- if (rc)
+ if (rc) {
wled->name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn", dev->of_node);
-
+ if (!wled->name)
+ return -ENOMEM;
+ }
switch (wled->version) {
case 3:
u32_opts = wled3_opts;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/1] fbdev: atyfb: Fix buffer overflow
From: Helge Deller @ 2025-04-01 9:03 UTC (permalink / raw)
To: Denis Arefev, ville.syrjala
Cc: dri-devel, jani.nikula, linux-fbdev, linux-kernel, lvc-project,
tzimmermann
In-Reply-To: <20250401084010.5886-1-arefev@swemel.ru>
On 4/1/25 10:40, Denis Arefev wrote:
> One small question.
> This chip (3D RAGE LT (Mach64 LG)) is very old it is 25 or
> maybe 30 years old, why is it not removed from the core?
It's old, but still runs in some configurations and people
still (although probably not on daily bases) use it.
Also don't forget about the various old non-x86 hardware machines
which often used ATI cards too, and those machines are still
supported by Linux as well.
Helge
^ permalink raw reply
* Re: [PATCH v3] backlight: pm8941: Add NULL check in wled_configure()
From: Daniel Thompson @ 2025-04-01 8:58 UTC (permalink / raw)
To: Henry Martin
Cc: Markus.Elfring, lee, jingoohan1, deller, linux-arm-msm, dri-devel,
linux-fbdev, linux-kernel, Dmitry Baryshkov
In-Reply-To: <20250401082950.21698-1-bsdhenrymartin@gmail.com>
On Tue, Apr 01, 2025 at 04:29:50PM +0800, Henry Martin wrote:
> The function wled_configure() uses devm_kasprintf() without checking for
> allocation failures, which could lead to NULL pointer dereferences.
>
> Add proper error handling when devm_kasprintf() fails by:
> - Returning -ENOMEM immediately
> - Ensuring no resources are left allocated (none need cleanup in this case)
Two things have gone wrong here:
1. This patch has been incorrectly posted with the wrong patch number.
2. You've let Markus bully you into adding some pointless text in the
patch description ;-). I think the original v3 was better worded.
IMHO the bulleted list adds nothing useful.
When you get the chance please send a v4 of the patch so we can pick it
up without any confusion (I suspect it might be a week or two before
this gets pulled so clean mail threads help a lot). It's up to you but
I'd recommend keeping the original v3 wording and label it something
like:
V3 -> V4: No functional changes, just correcting the version number
Daniel.
>
> Fixes: f86b77583d88 ("backlight: pm8941: Convert to using %pOFn instead of device_node.name")
> Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> V2 -> V3: Fix commit message and verify proper error handling with
> resource cleanup.
> V1 -> V2: Fix commit message to use imperative mood and wrap lines to 75
> characters.
>
> drivers/video/backlight/qcom-wled.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c
> index 9afe701b2a1b..a63bb42c8f8b 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -1406,9 +1406,11 @@ static int wled_configure(struct wled *wled)
> wled->ctrl_addr = be32_to_cpu(*prop_addr);
>
> rc = of_property_read_string(dev->of_node, "label", &wled->name);
> - if (rc)
> + if (rc) {
> wled->name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn", dev->of_node);
> -
> + if (!wled->name)
> + return -ENOMEM;
> + }
> switch (wled->version) {
> case 3:
> u32_opts = wled3_opts;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v3] backlight: pm8941: Add NULL check in wled_configure()
From: Daniel Thompson @ 2025-04-01 8:44 UTC (permalink / raw)
To: Henry Martin
Cc: lee, jingoohan1, deller, linux-arm-msm, dri-devel, linux-fbdev,
linux-kernel, Dmitry Baryshkov
In-Reply-To: <20250401025737.16753-1-bsdhenrymartin@gmail.com>
On Tue, Apr 01, 2025 at 10:57:37AM +0800, Henry Martin wrote:
> devm_kasprintf() returns NULL when memory allocation fails. Currently,
> wled_configure() does not check for this case, which results in a NULL
> pointer dereference.
>
> Add NULL check after devm_kasprintf() to prevent this issue.
>
> Fixes: f86b77583d88 ("backlight: pm8941: Convert to using %pOFn instead of device_node.name")
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH 1/1] fbdev: atyfb: Fix buffer overflow
From: Denis Arefev @ 2025-04-01 8:40 UTC (permalink / raw)
To: ville.syrjala
Cc: arefev, deller, dri-devel, jani.nikula, linux-fbdev, linux-kernel,
lvc-project, tzimmermann
In-Reply-To: <Z-rzIfUMmOq1UZY1@intel.com>
Hi Ville. Hi Jani.
Thank you for your answers.
One small question.
This chip (3D RAGE LT (Mach64 LG)) is very old it is 25 or
maybe 30 years old, why is it not removed from the core?
Regards Denis.
^ permalink raw reply
* [PATCH v3] backlight: pm8941: Add NULL check in wled_configure()
From: Henry Martin @ 2025-04-01 8:29 UTC (permalink / raw)
To: Markus.Elfring
Cc: lee, danielt, jingoohan1, deller, linux-arm-msm, dri-devel,
linux-fbdev, linux-kernel, Henry Martin, Dmitry Baryshkov
In-Reply-To: <d5f2aa49-27e2-4cc1-91be-4e195ed5249e@web.de>
The function wled_configure() uses devm_kasprintf() without checking for
allocation failures, which could lead to NULL pointer dereferences.
Add proper error handling when devm_kasprintf() fails by:
- Returning -ENOMEM immediately
- Ensuring no resources are left allocated (none need cleanup in this case)
Fixes: f86b77583d88 ("backlight: pm8941: Convert to using %pOFn instead of device_node.name")
Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
V2 -> V3: Fix commit message and verify proper error handling with
resource cleanup.
V1 -> V2: Fix commit message to use imperative mood and wrap lines to 75
characters.
drivers/video/backlight/qcom-wled.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c
index 9afe701b2a1b..a63bb42c8f8b 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -1406,9 +1406,11 @@ static int wled_configure(struct wled *wled)
wled->ctrl_addr = be32_to_cpu(*prop_addr);
rc = of_property_read_string(dev->of_node, "label", &wled->name);
- if (rc)
+ if (rc) {
wled->name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn", dev->of_node);
-
+ if (!wled->name)
+ return -ENOMEM;
+ }
switch (wled->version) {
case 3:
u32_opts = wled3_opts;
--
2.34.1
^ permalink raw reply related
* [PATCH v3] backlight: pm8941: Add NULL check in wled_configure()
From: Henry Martin @ 2025-04-01 6:53 UTC (permalink / raw)
To: markus
Cc: lee, danielt, jingoohan1, deller, linux-arm-msm, dri-devel,
linux-fbdev, linux-kernel
In-Reply-To: <d5f2aa49-27e2-4cc1-91be-4e195ed5249e@web.de>
Thanks for your review. No further improvements needed for this implementation
- it already handles all error cases appropriately.
Best regards,
Henry
^ permalink raw reply
* Re: [PATCH v3] backlight: pm8941: Add NULL check in wled_configure()
From: Markus Elfring @ 2025-04-01 6:18 UTC (permalink / raw)
To: Henry Martin, linux-fbdev, linux-arm-msm, dri-devel
Cc: LKML, Daniel Thompson, Helge Deller, Jingoo Han, Lee Jones
In-Reply-To: <20250401025737.16753-1-bsdhenrymartin@gmail.com>
> devm_kasprintf() return NULL if memory allocation fails. Currently,
…
call? failed?
> Add NULL check after devm_kasprintf() to prevent this issue.
Do you propose to improve this function implementation a bit more?
Regards,
Markus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox