* Re: [PATCH] staging: rtl8723bs: fix CamelCase style warnings in rtw_efuse.c
From: Dan Carpenter @ 2026-06-23 12:32 UTC (permalink / raw)
To: Bruce Ou; +Cc: Greg Kroah-Hartman, linux-staging, linux-kernel
In-Reply-To: <20260623112629.4953-1-oubruce1234@gmail.com>
On Tue, Jun 23, 2026 at 07:26:29PM +0800, Bruce Ou wrote:
> Fix coding style warnings reported by checkpatch.pl regarding
> CamelCase local variable names in rtw_efuse.c. This includes
> variables like contentLen, mapLen, efuseType, Bytetemp, bResult,
> and Address.
>
> No functional changes are introduced.
>
> Signed-off-by: Bruce Ou <oubruce1234@gmail.com>
> ---
There are a whole series of rules to follow for v2 patches.
https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/
But mainly please slow down and wait a day between resends...
regards,
dan carpenter
^ permalink raw reply
* [PATCH v2 3/3] staging: rtl8723bs: fix remaining CamelCase local variables
From: Bruce Ou @ 2026-06-23 12:08 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Dan Carpenter, linux-staging, linux-kernel, Bruce Ou
In-Reply-To: <20260623120815.14737-1-oubruce1234@gmail.com>
Fix coding style warnings reported by checkpatch.pl regarding
the remaining CamelCase local variables in rtw_efuse.c. This includes
variables like contentLen, mapLen, efuseType, and Bytetemp.
No functional changes are introduced.
Signed-off-by: Bruce Ou <oubruce1234@gmail.com>
---
Changes in v2:
- Split from a single comprehensive patch into a standalone patch.
drivers/staging/rtl8723bs/core/rtw_efuse.c | 38 +++++++++++-----------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c b/drivers/staging/rtl8723bs/core/rtw_efuse.c
index 6767c6bbaa1b..b1d32f211102 100644
--- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
+++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
@@ -46,31 +46,31 @@ rtw_efuse_read_1_byte(
struct adapter *Adapter,
u16 address)
{
- u8 Bytetemp = {0x00};
+ u8 byte_temp = {0x00};
u8 temp = {0x00};
u32 k = 0;
- u16 contentLen = 0;
+ u16 content_len = 0;
- Hal_GetEfuseDefinition(Adapter, EFUSE_WIFI, TYPE_EFUSE_REAL_CONTENT_LEN, &contentLen);
+ Hal_GetEfuseDefinition(Adapter, EFUSE_WIFI, TYPE_EFUSE_REAL_CONTENT_LEN, &content_len);
- if (address < contentLen) {/* E-fuse 512Byte */
+ if (address < content_len) {/* E-fuse 512Byte */
/* Write E-fuse Register address bit0~7 */
temp = address & 0xFF;
rtw_write8(Adapter, EFUSE_CTRL + 1, temp);
- Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 2);
+ byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 2);
/* Write E-fuse Register address bit8~9 */
temp = ((address >> 8) & 0x03) | (byte_temp & 0xFC);
rtw_write8(Adapter, EFUSE_CTRL + 2, temp);
/* Write 0x30[31]= 0 */
- Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 3);
- temp = Bytetemp & 0x7F;
+ byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 3);
+ temp = byte_temp & 0x7F;
rtw_write8(Adapter, EFUSE_CTRL + 3, temp);
/* Wait Write-ready (0x30[31]= 1) */
- Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 3);
- while (!(Bytetemp & 0x80)) {
- Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 3);
+ byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 3);
+ while (!(byte_temp & 0x80)) {
+ byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 3);
k++;
if (k == 1000)
break;
@@ -139,15 +139,15 @@ u8 *data)
* 11/11/2008 MHC Create Version 0.
*
*/
-static void Efuse_ReadAllMap(struct adapter *padapter, u8 efuseType, u8 *Efuse)
+static void Efuse_ReadAllMap(struct adapter *padapter, u8 efuse_type, u8 *Efuse)
{
- u16 mapLen = 0;
+ u16 map_len = 0;
Hal_EfusePowerSwitch(padapter, true);
- Hal_GetEfuseDefinition(padapter, efuseType, TYPE_EFUSE_MAP_LEN, &mapLen);
+ Hal_GetEfuseDefinition(padapter, efuse_type, TYPE_EFUSE_MAP_LEN, &map_len);
- Hal_ReadEFuse(padapter, efuseType, 0, mapLen, Efuse);
+ Hal_ReadEFuse(padapter, efuse_type, 0, map_len, Efuse);
Hal_EfusePowerSwitch(padapter, false);
}
@@ -216,20 +216,20 @@ static void efuse_ShadowRead4Byte(struct adapter *padapter, u16 Offset, u32 *Val
* 11/13/2008 MHC Create Version 0.
*
*/
-void rtw_efuse_shadow_map_update(struct adapter *padapter, u8 efuseType)
+void rtw_efuse_shadow_map_update(struct adapter *padapter, u8 efuse_type)
{
struct eeprom_priv *pEEPROM = GET_EEPROM_EFUSE_PRIV(padapter);
- u16 mapLen = 0;
+ u16 map_len = 0;
- Hal_GetEfuseDefinition(padapter, efuseType, TYPE_EFUSE_MAP_LEN, &mapLen);
+ Hal_GetEfuseDefinition(padapter, efuse_type, TYPE_EFUSE_MAP_LEN, &map_len);
if (pEEPROM->bautoload_fail_flag)
- memset(pEEPROM->efuse_eeprom_data, 0xFF, mapLen);
+ memset(pEEPROM->efuse_eeprom_data, 0xFF, map_len);
else
- Efuse_ReadAllMap(padapter, efuseType, pEEPROM->efuse_eeprom_data);
+ Efuse_ReadAllMap(padapter, efuse_type, pEEPROM->efuse_eeprom_data);
/* PlatformMoveMemory((void *)&pHalData->EfuseMap[EFUSE_MODIFY_MAP][0], */
- /* void *)&pHalData->EfuseMap[EFUSE_INIT_MAP][0], mapLen); */
+ /* void *)&pHalData->EfuseMap[EFUSE_INIT_MAP][0], map_len); */
} /* rtw_efuse_shadow_map_update */
/*-----------------------------------------------------------------------------
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] staging: rtl8723bs: fix CamelCase warning for Address
From: Bruce Ou @ 2026-06-23 12:08 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Dan Carpenter, linux-staging, linux-kernel, Bruce Ou
In-Reply-To: <20260623120815.14737-1-oubruce1234@gmail.com>
Fix the coding style warning reported by checkpatch.pl regarding
the CamelCase local variable Address by renaming it to address.
No functional changes are introduced.
Signed-off-by: Bruce Ou <oubruce1234@gmail.com>
---
Changes in v2:
- Split from a single comprehensive patch into a standalone patch.
drivers/staging/rtl8723bs/core/rtw_efuse.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c b/drivers/staging/rtl8723bs/core/rtw_efuse.c
index 4bf205e078e7..6767c6bbaa1b 100644
--- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
+++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
@@ -44,7 +44,7 @@ rtw_efuse_calculate_word_counts(u8 word_en)
u8
rtw_efuse_read_1_byte(
struct adapter *Adapter,
-u16 Address)
+u16 address)
{
u8 Bytetemp = {0x00};
u8 temp = {0x00};
@@ -53,13 +53,13 @@ u16 Address)
Hal_GetEfuseDefinition(Adapter, EFUSE_WIFI, TYPE_EFUSE_REAL_CONTENT_LEN, &contentLen);
- if (Address < contentLen) {/* E-fuse 512Byte */
+ if (address < contentLen) {/* E-fuse 512Byte */
/* Write E-fuse Register address bit0~7 */
- temp = Address & 0xFF;
+ temp = address & 0xFF;
rtw_write8(Adapter, EFUSE_CTRL + 1, temp);
Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 2);
/* Write E-fuse Register address bit8~9 */
- temp = ((Address >> 8) & 0x03) | (Bytetemp & 0xFC);
+ temp = ((address >> 8) & 0x03) | (Bytetemp & 0xFC);
rtw_write8(Adapter, EFUSE_CTRL + 2, temp);
/* Write 0x30[31]= 0 */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] staging: rtl8723bs: fix CamelCase warning for bResult
From: Bruce Ou @ 2026-06-23 12:08 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Dan Carpenter, linux-staging, linux-kernel, Bruce Ou
In-Reply-To: <20260623120815.14737-1-oubruce1234@gmail.com>
Fix the coding style warning reported by checkpatch.pl regarding
the CamelCase local variable bResult by renaming it to result.
No functional changes are introduced.
Signed-off-by: Bruce Ou <oubruce1234@gmail.com>
---
Changes in v2:
- Split from a single comprehensive patch into a standalone patch.
drivers/staging/rtl8723bs/core/rtw_efuse.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c b/drivers/staging/rtl8723bs/core/rtw_efuse.c
index a40d6eab7249..4bf205e078e7 100644
--- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
+++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
@@ -89,7 +89,7 @@ u16 addr,
u8 *data)
{
u32 tmpidx = 0;
- u8 bResult;
+ u8 result;
u8 readbyte;
/* <20130121, Kordan> For SMIC EFUSE specificatoin. */
@@ -114,13 +114,13 @@ u8 *data)
}
if (tmpidx < 100) {
*data = rtw_read8(padapter, EFUSE_CTRL);
- bResult = true;
+ result = true;
} else {
*data = 0xff;
- bResult = false;
+ result = false;
}
- return bResult;
+ return result;
}
/*-----------------------------------------------------------------------------
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/3] staging: rtl8723bs: clean up CamelCase style warnings
From: Bruce Ou @ 2026-06-23 12:08 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Dan Carpenter, linux-staging, linux-kernel, Bruce Ou
Changes in v2:
- Split the single comprehensive patch into a patchset of 3 logical
parts as requested by Dan Carpenter.
- Worked against the latest staging/staging-next branch.
Bruce Ou (3):
staging: rtl8723bs: fix CamelCase warning for bResult
staging: rtl8723bs: fix CamelCase warning for Address
staging: rtl8723bs: fix remaining CamelCase local variables
drivers/staging/rtl8723bs/core/rtw_efuse.c | 54 +++++++++++-----------
1 file changed, 27 insertions(+), 27 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH] staging: rtl8723bs: fix CamelCase style warnings in rtw_efuse.c
From: Greg Kroah-Hartman @ 2026-06-23 11:38 UTC (permalink / raw)
To: Bruce Ou; +Cc: Dan Carpenter, linux-staging, linux-kernel
In-Reply-To: <20260623112629.4953-1-oubruce1234@gmail.com>
On Tue, Jun 23, 2026 at 07:26:29PM +0800, Bruce Ou wrote:
> Fix coding style warnings reported by checkpatch.pl regarding
> CamelCase local variable names in rtw_efuse.c. This includes
> variables like contentLen, mapLen, efuseType, Bytetemp, bResult,
> and Address.
>
> No functional changes are introduced.
>
> Signed-off-by: Bruce Ou <oubruce1234@gmail.com>
> ---
> drivers/staging/rtl8723bs/core/rtw_efuse.c | 54 +++++++++++-----------
> 1 file changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c b/drivers/staging/rtl8723bs/core/rtw_efuse.c
> index a40d6eab7249..b1d32f211102 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
> @@ -44,33 +44,33 @@ rtw_efuse_calculate_word_counts(u8 word_en)
> u8
> rtw_efuse_read_1_byte(
> struct adapter *Adapter,
> -u16 Address)
> +u16 address)
> {
> - u8 Bytetemp = {0x00};
> + u8 byte_temp = {0x00};
> u8 temp = {0x00};
> u32 k = 0;
> - u16 contentLen = 0;
> + u16 content_len = 0;
>
> - Hal_GetEfuseDefinition(Adapter, EFUSE_WIFI, TYPE_EFUSE_REAL_CONTENT_LEN, &contentLen);
> + Hal_GetEfuseDefinition(Adapter, EFUSE_WIFI, TYPE_EFUSE_REAL_CONTENT_LEN, &content_len);
>
> - if (Address < contentLen) {/* E-fuse 512Byte */
> + if (address < content_len) {/* E-fuse 512Byte */
> /* Write E-fuse Register address bit0~7 */
> - temp = Address & 0xFF;
> + temp = address & 0xFF;
> rtw_write8(Adapter, EFUSE_CTRL + 1, temp);
> - Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 2);
> + byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 2);
> /* Write E-fuse Register address bit8~9 */
> - temp = ((Address >> 8) & 0x03) | (Bytetemp & 0xFC);
> + temp = ((address >> 8) & 0x03) | (byte_temp & 0xFC);
> rtw_write8(Adapter, EFUSE_CTRL + 2, temp);
>
> /* Write 0x30[31]= 0 */
> - Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 3);
> - temp = Bytetemp & 0x7F;
> + byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 3);
> + temp = byte_temp & 0x7F;
> rtw_write8(Adapter, EFUSE_CTRL + 3, temp);
>
> /* Wait Write-ready (0x30[31]= 1) */
> - Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 3);
> - while (!(Bytetemp & 0x80)) {
> - Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 3);
> + byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 3);
> + while (!(byte_temp & 0x80)) {
> + byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 3);
> k++;
> if (k == 1000)
> break;
> @@ -89,7 +89,7 @@ u16 addr,
> u8 *data)
> {
> u32 tmpidx = 0;
> - u8 bResult;
> + u8 result;
> u8 readbyte;
>
> /* <20130121, Kordan> For SMIC EFUSE specificatoin. */
> @@ -114,13 +114,13 @@ u8 *data)
> }
> if (tmpidx < 100) {
> *data = rtw_read8(padapter, EFUSE_CTRL);
> - bResult = true;
> + result = true;
> } else {
> *data = 0xff;
> - bResult = false;
> + result = false;
> }
>
> - return bResult;
> + return result;
> }
>
> /*-----------------------------------------------------------------------------
> @@ -139,15 +139,15 @@ u8 *data)
> * 11/11/2008 MHC Create Version 0.
> *
> */
> -static void Efuse_ReadAllMap(struct adapter *padapter, u8 efuseType, u8 *Efuse)
> +static void Efuse_ReadAllMap(struct adapter *padapter, u8 efuse_type, u8 *Efuse)
> {
> - u16 mapLen = 0;
> + u16 map_len = 0;
>
> Hal_EfusePowerSwitch(padapter, true);
>
> - Hal_GetEfuseDefinition(padapter, efuseType, TYPE_EFUSE_MAP_LEN, &mapLen);
> + Hal_GetEfuseDefinition(padapter, efuse_type, TYPE_EFUSE_MAP_LEN, &map_len);
>
> - Hal_ReadEFuse(padapter, efuseType, 0, mapLen, Efuse);
> + Hal_ReadEFuse(padapter, efuse_type, 0, map_len, Efuse);
>
> Hal_EfusePowerSwitch(padapter, false);
> }
> @@ -216,20 +216,20 @@ static void efuse_ShadowRead4Byte(struct adapter *padapter, u16 Offset, u32 *Val
> * 11/13/2008 MHC Create Version 0.
> *
> */
> -void rtw_efuse_shadow_map_update(struct adapter *padapter, u8 efuseType)
> +void rtw_efuse_shadow_map_update(struct adapter *padapter, u8 efuse_type)
> {
> struct eeprom_priv *pEEPROM = GET_EEPROM_EFUSE_PRIV(padapter);
> - u16 mapLen = 0;
> + u16 map_len = 0;
>
> - Hal_GetEfuseDefinition(padapter, efuseType, TYPE_EFUSE_MAP_LEN, &mapLen);
> + Hal_GetEfuseDefinition(padapter, efuse_type, TYPE_EFUSE_MAP_LEN, &map_len);
>
> if (pEEPROM->bautoload_fail_flag)
> - memset(pEEPROM->efuse_eeprom_data, 0xFF, mapLen);
> + memset(pEEPROM->efuse_eeprom_data, 0xFF, map_len);
> else
> - Efuse_ReadAllMap(padapter, efuseType, pEEPROM->efuse_eeprom_data);
> + Efuse_ReadAllMap(padapter, efuse_type, pEEPROM->efuse_eeprom_data);
>
> /* PlatformMoveMemory((void *)&pHalData->EfuseMap[EFUSE_MODIFY_MAP][0], */
> - /* void *)&pHalData->EfuseMap[EFUSE_INIT_MAP][0], mapLen); */
> + /* void *)&pHalData->EfuseMap[EFUSE_INIT_MAP][0], map_len); */
> } /* rtw_efuse_shadow_map_update */
>
> /*-----------------------------------------------------------------------------
> --
> 2.43.0
>
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/process/submitting-patches.rst for what
needs to be done here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* [PATCH] staging: rtl8723bs: fix CamelCase style warnings in rtw_efuse.c
From: Bruce Ou @ 2026-06-23 11:26 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Dan Carpenter, linux-staging, linux-kernel, Bruce Ou
Fix coding style warnings reported by checkpatch.pl regarding
CamelCase local variable names in rtw_efuse.c. This includes
variables like contentLen, mapLen, efuseType, Bytetemp, bResult,
and Address.
No functional changes are introduced.
Signed-off-by: Bruce Ou <oubruce1234@gmail.com>
---
drivers/staging/rtl8723bs/core/rtw_efuse.c | 54 +++++++++++-----------
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c b/drivers/staging/rtl8723bs/core/rtw_efuse.c
index a40d6eab7249..b1d32f211102 100644
--- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
+++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
@@ -44,33 +44,33 @@ rtw_efuse_calculate_word_counts(u8 word_en)
u8
rtw_efuse_read_1_byte(
struct adapter *Adapter,
-u16 Address)
+u16 address)
{
- u8 Bytetemp = {0x00};
+ u8 byte_temp = {0x00};
u8 temp = {0x00};
u32 k = 0;
- u16 contentLen = 0;
+ u16 content_len = 0;
- Hal_GetEfuseDefinition(Adapter, EFUSE_WIFI, TYPE_EFUSE_REAL_CONTENT_LEN, &contentLen);
+ Hal_GetEfuseDefinition(Adapter, EFUSE_WIFI, TYPE_EFUSE_REAL_CONTENT_LEN, &content_len);
- if (Address < contentLen) {/* E-fuse 512Byte */
+ if (address < content_len) {/* E-fuse 512Byte */
/* Write E-fuse Register address bit0~7 */
- temp = Address & 0xFF;
+ temp = address & 0xFF;
rtw_write8(Adapter, EFUSE_CTRL + 1, temp);
- Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 2);
+ byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 2);
/* Write E-fuse Register address bit8~9 */
- temp = ((Address >> 8) & 0x03) | (Bytetemp & 0xFC);
+ temp = ((address >> 8) & 0x03) | (byte_temp & 0xFC);
rtw_write8(Adapter, EFUSE_CTRL + 2, temp);
/* Write 0x30[31]= 0 */
- Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 3);
- temp = Bytetemp & 0x7F;
+ byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 3);
+ temp = byte_temp & 0x7F;
rtw_write8(Adapter, EFUSE_CTRL + 3, temp);
/* Wait Write-ready (0x30[31]= 1) */
- Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 3);
- while (!(Bytetemp & 0x80)) {
- Bytetemp = rtw_read8(Adapter, EFUSE_CTRL + 3);
+ byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 3);
+ while (!(byte_temp & 0x80)) {
+ byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 3);
k++;
if (k == 1000)
break;
@@ -89,7 +89,7 @@ u16 addr,
u8 *data)
{
u32 tmpidx = 0;
- u8 bResult;
+ u8 result;
u8 readbyte;
/* <20130121, Kordan> For SMIC EFUSE specificatoin. */
@@ -114,13 +114,13 @@ u8 *data)
}
if (tmpidx < 100) {
*data = rtw_read8(padapter, EFUSE_CTRL);
- bResult = true;
+ result = true;
} else {
*data = 0xff;
- bResult = false;
+ result = false;
}
- return bResult;
+ return result;
}
/*-----------------------------------------------------------------------------
@@ -139,15 +139,15 @@ u8 *data)
* 11/11/2008 MHC Create Version 0.
*
*/
-static void Efuse_ReadAllMap(struct adapter *padapter, u8 efuseType, u8 *Efuse)
+static void Efuse_ReadAllMap(struct adapter *padapter, u8 efuse_type, u8 *Efuse)
{
- u16 mapLen = 0;
+ u16 map_len = 0;
Hal_EfusePowerSwitch(padapter, true);
- Hal_GetEfuseDefinition(padapter, efuseType, TYPE_EFUSE_MAP_LEN, &mapLen);
+ Hal_GetEfuseDefinition(padapter, efuse_type, TYPE_EFUSE_MAP_LEN, &map_len);
- Hal_ReadEFuse(padapter, efuseType, 0, mapLen, Efuse);
+ Hal_ReadEFuse(padapter, efuse_type, 0, map_len, Efuse);
Hal_EfusePowerSwitch(padapter, false);
}
@@ -216,20 +216,20 @@ static void efuse_ShadowRead4Byte(struct adapter *padapter, u16 Offset, u32 *Val
* 11/13/2008 MHC Create Version 0.
*
*/
-void rtw_efuse_shadow_map_update(struct adapter *padapter, u8 efuseType)
+void rtw_efuse_shadow_map_update(struct adapter *padapter, u8 efuse_type)
{
struct eeprom_priv *pEEPROM = GET_EEPROM_EFUSE_PRIV(padapter);
- u16 mapLen = 0;
+ u16 map_len = 0;
- Hal_GetEfuseDefinition(padapter, efuseType, TYPE_EFUSE_MAP_LEN, &mapLen);
+ Hal_GetEfuseDefinition(padapter, efuse_type, TYPE_EFUSE_MAP_LEN, &map_len);
if (pEEPROM->bautoload_fail_flag)
- memset(pEEPROM->efuse_eeprom_data, 0xFF, mapLen);
+ memset(pEEPROM->efuse_eeprom_data, 0xFF, map_len);
else
- Efuse_ReadAllMap(padapter, efuseType, pEEPROM->efuse_eeprom_data);
+ Efuse_ReadAllMap(padapter, efuse_type, pEEPROM->efuse_eeprom_data);
/* PlatformMoveMemory((void *)&pHalData->EfuseMap[EFUSE_MODIFY_MAP][0], */
- /* void *)&pHalData->EfuseMap[EFUSE_INIT_MAP][0], mapLen); */
+ /* void *)&pHalData->EfuseMap[EFUSE_INIT_MAP][0], map_len); */
} /* rtw_efuse_shadow_map_update */
/*-----------------------------------------------------------------------------
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] staging: rtl8723bs: fix CamelCase warnings in rtw_efuse.c
From: Dan Carpenter @ 2026-06-23 11:28 UTC (permalink / raw)
To: bruce ou; +Cc: Greg Kroah-Hartman, linux-staging, linux-kernel
In-Reply-To: <CA+h2PQjd8D7yiF8N8R-FwtTFfT7gJH-z9jMOA84esykGP4J+bw@mail.gmail.com>
On Tue, Jun 23, 2026 at 07:25:55PM +0800, bruce ou wrote:
> Hi Dan,
>
> Thank you for your review and guidance!
>
> I have switched my local tree to the latest staging/staging-next branch
> and squashed all the CamelCase local variable cleanups in rtw_efuse.c
> into a single, comprehensive patch with a proper commit message.
>
> I will send the new patch shortly.
Not as one patch, but as a collection of patches in a patchset.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] staging: rtl8723bs: fix CamelCase warnings in rtw_efuse.c
From: bruce ou @ 2026-06-23 11:25 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Greg Kroah-Hartman, linux-staging, linux-kernel
In-Reply-To: <ajpQD7LyfKNopii6@stanley.mountain>
Hi Dan,
Thank you for your review and guidance!
I have switched my local tree to the latest staging/staging-next branch
and squashed all the CamelCase local variable cleanups in rtw_efuse.c
into a single, comprehensive patch with a proper commit message.
I will send the new patch shortly.
Regards,
Bruce Ou
Dan Carpenter <error27@gmail.com> 于2026年6月23日周二 17:21写道：
>
> On Tue, Jun 23, 2026 at 03:55:07PM +0800, Bruce Ou wrote:
> > Signed-off-by: Bruce Ou <oubruce1234@gmail.com>
> > ---
>
> No commit message. You're working against an old tree as well. You
> need to work against linux-next or devel-next.
>
> Please, don't send a patch at a time, one by one throughout the day.
> Send them as a patchset.
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH] staging: media: atomisp: constify pmic_name array
From: Andy Shevchenko @ 2026-06-23 10:58 UTC (permalink / raw)
To: Mohammad Abbasi
Cc: hansg, mchehab, andy, gregkh, sakari.ailus, linux-media,
linux-kernel, linux-staging, Mohammad Abbasi
In-Reply-To: <20260619111907.242382-1-mail@mohammad-abbasi.me>
On Fri, Jun 19, 2026 at 02:49:07PM +0330, Mohammad Abbasi wrote:
> Fix the following checkpatch warning:
>
> WARNING: static const char * array should probably be static const char * const
Missing blank line here.
> Signed-off-by: Mohammad Abbasi <mohammad.v184@gmail.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 2/3] staging: media: atomisp: use kvmalloc_objs() for overflow-safe allocation
From: Andy Shevchenko @ 2026-06-23 10:22 UTC (permalink / raw)
To: Rodrigo Gobbi
Cc: andy, hansg, mchehab, sakari.ailus, gregkh, ~lkcamp/patches,
linux-kernel-mentees, linux-kernel, linux-media, linux-staging
In-Reply-To: <20260622224402.34001-3-rodrigo.gobbi.7@gmail.com>
On Mon, Jun 22, 2026 at 07:42:43PM -0300, Rodrigo Gobbi wrote:
> Several allocations in sh_css_params.c still size their buffers with
> open-coded multiplication (e.g. width * height * sizeof(*p)), which can
> silently overflow and under-allocate.
>
> Convert them to kvmalloc_objs() with array_size(), which saturate to
> SIZE_MAX on overflow so kvmalloc() returns NULL instead of allocating
> too few bytes.
...
> + me->hor_coefs = kvmalloc_objs(*me->hor_coefs,
> + array_size(grid->num_hor_coefs,
> + IA_CSS_DVS_NUM_COEF_TYPES));
Here and elsewhere with long line, do like you have done in one case
with a temporary variable cnt. It makes same number of lines of code,
but readability is better.
> if (!me->hor_coefs)
> goto err;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 2/2] staging: rtl8723bs: put logical continuation on previous line
From: Dan Carpenter @ 2026-06-23 10:10 UTC (permalink / raw)
To: Serhat Kumral; +Cc: linux-staging, gregkh, linux-kernel, lgs201920130244
In-Reply-To: <20260623100535.5752-2-serhatkumral1@gmail.com>
On Tue, Jun 23, 2026 at 01:05:35PM +0300, Serhat Kumral wrote:
> Move the logical operator '&&' to the previous line in os_intfs.c
> to conform to the Linux kernel coding style guidelines.
> This fixes the checkpatch.pl warning:
> CHECK: Logical continuations should be on the previous line
>
> Signed-off-by: Serhat Kumral <serhatkumral1@gmail.com>
> ---
> Changes in v2:
> - Dropped the third patch of the v1 series (msleep to usleep_range conversion)
> based on feedback from Dan Carpenter.
Thanks!
Reviewed-by: Dan Carpenter <error27@gmail.com>
regards,
dan carpenter
^ permalink raw reply
* [PATCH v2 2/2] staging: rtl8723bs: put logical continuation on previous line
From: Serhat Kumral @ 2026-06-23 10:05 UTC (permalink / raw)
To: linux-staging
Cc: gregkh, linux-kernel, lgs201920130244, error27, Serhat Kumral
In-Reply-To: <20260623100535.5752-1-serhatkumral1@gmail.com>
Move the logical operator '&&' to the previous line in os_intfs.c
to conform to the Linux kernel coding style guidelines.
This fixes the checkpatch.pl warning:
CHECK: Logical continuations should be on the previous line
Signed-off-by: Serhat Kumral <serhatkumral1@gmail.com>
---
Changes in v2:
- Dropped the third patch of the v1 series (msleep to usleep_range conversion)
based on feedback from Dan Carpenter.
drivers/staging/rtl8723bs/os_dep/os_intfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/os_intfs.c b/drivers/staging/rtl8723bs/os_dep/os_intfs.c
index a545c3338..89e41c26e 100644
--- a/drivers/staging/rtl8723bs/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8723bs/os_dep/os_intfs.c
@@ -1018,8 +1018,8 @@ static int rtw_suspend_free_assoc_resource(struct adapter *padapter)
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
if (rtw_chk_roam_flags(padapter, RTW_ROAM_ON_RESUME)) {
- if (check_fwstate(pmlmepriv, WIFI_STATION_STATE)
- && check_fwstate(pmlmepriv, _FW_LINKED)) {
+ if (check_fwstate(pmlmepriv, WIFI_STATION_STATE) &&
+ check_fwstate(pmlmepriv, _FW_LINKED)) {
rtw_set_to_roam(padapter, 1);
}
}
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/2] staging: rtl8723bs: remove multiple blank lines
From: Serhat Kumral @ 2026-06-23 10:05 UTC (permalink / raw)
To: linux-staging
Cc: gregkh, linux-kernel, lgs201920130244, error27, Serhat Kumral
Remove multiple blank lines in os_intfs.c to conform to the
Linux kernel coding style guidelines.
This fixes the checkpatch.pl warnings:
CHECK: Please don't use multiple blank lines
Signed-off-by: Serhat Kumral <serhatkumral1@gmail.com>
---
Changes in v2:
- Dropped the third patch of the v1 series (msleep to usleep_range conversion)
based on feedback from Dan Carpenter.
drivers/staging/rtl8723bs/os_dep/os_intfs.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/os_intfs.c b/drivers/staging/rtl8723bs/os_dep/os_intfs.c
index f31196f54..a545c3338 100644
--- a/drivers/staging/rtl8723bs/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8723bs/os_dep/os_intfs.c
@@ -18,7 +18,6 @@ static int rtw_chip_version;
static int rtw_rfintfs = HWPI;
static int rtw_lbkmode;/* RTL8712_AIR_TRX; */
-
static int rtw_network_mode = Ndis802_11IBSS;/* Ndis802_11Infrastructure;infra, ad-hoc, auto */
/* struct ndis_802_11_ssid ssid; */
static int rtw_channel = 1;/* ad-hoc support requirement */
@@ -143,7 +142,6 @@ module_param(rtw_wifi_spec, int, 0644);
module_param(rtw_antdiv_cfg, int, 0644);
module_param(rtw_antdiv_type, int, 0644);
-
module_param(rtw_hw_wps_pbc, int, 0644);
static uint rtw_max_roaming_times = 2;
@@ -238,7 +236,6 @@ static void loadparam(struct adapter *padapter, struct net_device *pnetdev)
registry_par->lowrate_two_xmit = (u8)rtw_lowrate_two_xmit;
registry_par->low_power = (u8)rtw_low_power;
-
registry_par->wifi_spec = (u8)rtw_wifi_spec;
registry_par->channel_plan = (u8)rtw_channel_plan;
@@ -335,7 +332,6 @@ static unsigned int rtw_classify8021d(struct sk_buff *skb)
return dscp >> 5;
}
-
static u16 rtw_select_queue(struct net_device *dev, struct sk_buff *skb,
struct net_device *sb_dev)
{
@@ -633,7 +629,6 @@ void rtw_reset_drv_sw(struct adapter *padapter)
rtw_set_signal_stat_timer(&padapter->recvpriv);
}
-
u8 rtw_init_drv_sw(struct adapter *padapter)
{
int res;
@@ -891,7 +886,6 @@ static int ips_netdrv_open(struct adapter *padapter)
return _FAIL;
}
-
int rtw_ips_pwr_up(struct adapter *padapter)
{
return ips_netdrv_open(padapter);
--
2.54.0
^ permalink raw reply related
* [PATCH] staging: rtl8723bs: fix CamelCase warning for OnAssoc
From: Dalvin-Ehinoma Noah Aiguobas @ 2026-06-23 9:51 UTC (permalink / raw)
To: gregkh; +Cc: linux-staging, linux-kernel
Rename OnAssoc values from CamelCase to snake_case to conform to
linux kernel coding style:
OnAssocReq -> on_assoc_req
OnAssocRsp -> on_assoc_rsp
WMMOnAssocRsp -> WMM_on_assoc_rsp
HTOnAssocRsp -> HT_on_assoc_rsp
OnAssocReqFail -> on_assoc_req_fail
Signed-off-by: Dalvin-Ehinoma Noah Aiguobas <fliegbert2@gmail.com>
---
drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 +-
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 38 +++++++++----------
.../staging/rtl8723bs/core/rtw_wlan_util.c | 4 +-
.../staging/rtl8723bs/include/rtw_mlme_ext.h | 8 ++--
4 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index 1196ec011455..f7662c918473 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -1496,7 +1496,7 @@ void rtw_cpwm_event_callback(struct adapter *padapter, u8 *pbuf)
void rtw_wmm_event_callback(struct adapter *padapter, u8 *pbuf)
{
- WMMOnAssocRsp(padapter);
+ WMM_on_assoc_rsp(padapter);
}
/*
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index a86d6f97cf02..b32e1e7ac4ba 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -12,10 +12,10 @@
#include <linux/unaligned.h>
static struct mlme_handler mlme_sta_tbl[] = {
- {WIFI_ASSOCREQ, "OnAssocReq", &OnAssocReq},
- {WIFI_ASSOCRSP, "OnAssocRsp", &OnAssocRsp},
- {WIFI_REASSOCREQ, "OnReAssocReq", &OnAssocReq},
- {WIFI_REASSOCRSP, "OnReAssocRsp", &OnAssocRsp},
+ {WIFI_ASSOCREQ, "on_assoc_req", &on_assoc_req},
+ {WIFI_ASSOCRSP, "on_assoc_rsp", &on_assoc_rsp},
+ {WIFI_REASSOCREQ, "OnReAssocReq", &on_assoc_req},
+ {WIFI_REASSOCRSP, "OnReAssocRsp", &on_assoc_rsp},
{WIFI_PROBEREQ, "OnProbeReq", &OnProbeReq},
{WIFI_PROBERSP, "OnProbeRsp", &OnProbeRsp},
@@ -908,7 +908,7 @@ unsigned int OnAuthClient(struct adapter *padapter, union recv_frame *precv_fram
return _FAIL;
}
-unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
+unsigned int on_assoc_req(struct adapter *padapter, union recv_frame *precv_frame)
{
u16 capab_info;
struct rtw_ieee802_11_elems elems;
@@ -974,7 +974,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
if (rtw_ieee802_11_parse_elems(pos, left, &elems, 1) == PARSE_FAILED ||
!elems.ssid) {
status = WLAN_STATUS_CHALLENGE_FAIL;
- goto OnAssocReqFail;
+ goto on_assoc_req_fail;
}
/* now we should check all the fields... */
@@ -985,7 +985,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
if (!p || ie_len == 0) {
/* broadcast ssid, however it is not allowed in assocreq */
status = WLAN_STATUS_CHALLENGE_FAIL;
- goto OnAssocReqFail;
+ goto on_assoc_req_fail;
} else {
/* check if ssid match */
if (memcmp(p+2, cur->ssid.ssid, cur->ssid.ssid_length))
@@ -996,7 +996,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
}
if (status != WLAN_STATUS_SUCCESS)
- goto OnAssocReqFail;
+ goto on_assoc_req_fail;
/* check if the supported rate is ok */
p = rtw_get_ie(pframe + WLAN_HDR_A3_LEN + ie_offset, WLAN_EID_SUPP_RATES, &ie_len, pkt_len - WLAN_HDR_A3_LEN - ie_offset);
@@ -1006,7 +1006,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
/* support_rate_num = AP_BSSRATE_LEN; */
status = WLAN_STATUS_CHALLENGE_FAIL;
- goto OnAssocReqFail;
+ goto on_assoc_req_fail;
} else {
if (ie_len > sizeof(supportRate))
ie_len = sizeof(supportRate);
@@ -1091,7 +1091,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
}
if (status != WLAN_STATUS_SUCCESS)
- goto OnAssocReqFail;
+ goto on_assoc_req_fail;
pstat->flags &= ~(WLAN_STA_WPS | WLAN_STA_MAYBE_WPS);
if (!wpa_ie) {
@@ -1112,7 +1112,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
if (!selected_registrar) {
status = WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA;
- goto OnAssocReqFail;
+ goto on_assoc_req_fail;
}
}
}
@@ -1123,7 +1123,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
if (psecuritypriv->wpa_psk == 0) {
status = WLAN_STATUS_INVALID_IE;
- goto OnAssocReqFail;
+ goto on_assoc_req_fail;
}
if (elems.wps_ie) {
@@ -1210,14 +1210,14 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
if (!pmlmepriv->htpriv.ht_option && (pstat->flags&WLAN_STA_HT)) {
status = WLAN_STATUS_CHALLENGE_FAIL;
- goto OnAssocReqFail;
+ goto on_assoc_req_fail;
}
if ((pstat->flags & WLAN_STA_HT) &&
((pstat->wpa2_pairwise_cipher&WPA_CIPHER_TKIP) ||
(pstat->wpa_pairwise_cipher&WPA_CIPHER_TKIP))) {
/* status = WLAN_STATUS_CIPHER_SUITE_REJECTED; */
- /* goto OnAssocReqFail; */
+ /* goto on_assoc_req_fail; */
}
pstat->flags |= WLAN_STA_NONERP;
for (i = 0; i < pstat->bssratelen; i++) {
@@ -1250,7 +1250,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
status = WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA;
- goto OnAssocReqFail;
+ goto on_assoc_req_fail;
} else {
pstapriv->sta_aid[pstat->aid - 1] = pstat;
@@ -1308,7 +1308,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
return _FAIL;
-OnAssocReqFail:
+on_assoc_req_fail:
pstat->aid = 0;
if (frame_type == WIFI_ASSOCREQ)
@@ -1319,7 +1319,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame)
return _FAIL;
}
-unsigned int OnAssocRsp(struct adapter *padapter, union recv_frame *precv_frame)
+unsigned int on_assoc_rsp(struct adapter *padapter, union recv_frame *precv_frame)
{
uint i;
int res;
@@ -4672,10 +4672,10 @@ void mlmeext_joinbss_event_callback(struct adapter *padapter, int join_res)
update_capinfo(padapter, pmlmeinfo->capability);
/* WMM, Update EDCA param */
- WMMOnAssocRsp(padapter);
+ WMM_on_assoc_rsp(padapter);
/* HT */
- HTOnAssocRsp(padapter);
+ HT_on_assoc_rsp(padapter);
/* Set cur_channel&cur_bwmode&cur_ch_offset */
set_channel_bwmode(padapter, pmlmeext->cur_channel, pmlmeext->cur_ch_offset, pmlmeext->cur_bwmode);
diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
index 1d37c2d5b10d..68801977d54f 100644
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@ -701,7 +701,7 @@ static void sort_wmm_ac_params(u32 *inx, u32 *edca)
}
}
-void WMMOnAssocRsp(struct adapter *padapter)
+void WMM_on_assoc_rsp(struct adapter *padapter)
{
u8 ACI, ACM, AIFS, ECWMin, ECWMax, aSifsTime;
u8 acm_mask;
@@ -977,7 +977,7 @@ void HT_info_handler(struct adapter *padapter, struct ndis_80211_var_ie *pIE)
memcpy(&(pmlmeinfo->HT_info), pIE->data, pIE->length);
}
-void HTOnAssocRsp(struct adapter *padapter)
+void HT_on_assoc_rsp(struct adapter *padapter)
{
unsigned char max_AMPDU_len;
unsigned char min_MPDU_spacing;
diff --git a/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h b/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h
index cb23c6939bfc..1395a82a33e1 100644
--- a/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h
+++ b/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h
@@ -483,11 +483,11 @@ int is_IBSS_empty(struct adapter *padapter);
unsigned char check_assoc_AP(u8 *pframe, uint len);
int WMM_param_handler(struct adapter *padapter, struct ndis_80211_var_ie *pIE);
-void WMMOnAssocRsp(struct adapter *padapter);
+void WMM_on_assoc_rsp(struct adapter *padapter);
void HT_caps_handler(struct adapter *padapter, struct ndis_80211_var_ie *pIE);
void HT_info_handler(struct adapter *padapter, struct ndis_80211_var_ie *pIE);
-void HTOnAssocRsp(struct adapter *padapter);
+void HT_on_assoc_rsp(struct adapter *padapter);
void ERP_IE_handler(struct adapter *padapter, struct ndis_80211_var_ie *pIE);
void VCS_update(struct adapter *padapter, struct sta_info *psta);
@@ -558,8 +558,8 @@ void start_clnt_auth(struct adapter *padapter);
void start_clnt_join(struct adapter *padapter);
void start_create_ibss(struct adapter *padapter);
-unsigned int OnAssocReq(struct adapter *padapter, union recv_frame *precv_frame);
-unsigned int OnAssocRsp(struct adapter *padapter, union recv_frame *precv_frame);
+unsigned int on_assoc_req(struct adapter *padapter, union recv_frame *precv_frame);
+unsigned int on_assoc_rsp(struct adapter *padapter, union recv_frame *precv_frame);
unsigned int OnProbeReq(struct adapter *padapter, union recv_frame *precv_frame);
unsigned int OnProbeRsp(struct adapter *padapter, union recv_frame *precv_frame);
unsigned int DoReserved(struct adapter *padapter, union recv_frame *precv_frame);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 3/4] drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support
From: Andy Shevchenko @ 2026-06-23 9:37 UTC (permalink / raw)
To: Amit Barzilai
Cc: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam,
chintanlike, dri-devel, devicetree, linux-kernel, linux-fbdev,
linux-staging
In-Reply-To: <20260622152506.78627-4-amit.barzilai22@gmail.com>
On Mon, Jun 22, 2026 at 06:25:05PM +0300, Amit Barzilai wrote:
> The Solomon SSD1351 is a 128x128 RGB color OLED controller. It shares
> the SSD133X data path: a column/row addressing window followed by a bulk
> RGB565 pixel write. Add it as a new SSD135X_FAMILY rather than a separate
> driver, reusing the SSD133X plane, CRTC and blit/clear helpers.
>
> The only data-path difference is that the SSD1351 requires an explicit
> Write RAM command (0x5c) after the address window is programmed, before
> pixel data is accepted, whereas the SSD133X enters data mode implicitly.
> This is emitted from a shared ssd133x_write_pixels() helper so both the
> damage-update and clear-screen paths cover it.
>
> The SSD1351 also needs its own init sequence (ssd135x_init), dispatched
> via ssd135x_encoder_atomic_enable, and a longer post-reset settle delay.
> The re-map byte is fixed at 0 degrees, 65k color, COM split, BGR
> sub-pixel order; rotation is not supported.
>
> The SSD1351 is SPI-only, so only the SPI transport match tables gain an
> entry; no new config symbol is needed.
...
> const struct ssd130x_deviceinfo ssd130x_variants[] = {
> .default_height = 64,
> .format_rgb565 = 1,
> .family_id = SSD133X_FAMILY,
> + },
> + /* ssd135x family */
> + [SSD1351_ID] = {
> + .default_width = 128,
> + .default_height = 128,
> + .format_rgb565 = 1,
> + .family_id = SSD135X_FAMILY,
> }
While it's not a problem _in this case_, the rule of thumb is always to have a
trailing comma for non-terminator entry.
...
> /*
> * Helper to write data (SSD13XX_DATA) to the device.
> */
> -static int ssd130x_write_data(struct ssd130x_device *ssd130x, u8 *values, int count)
> +static int ssd130x_write_data(struct ssd130x_device *ssd130x, const u8 *values, int count)
> {
> return regmap_bulk_write(ssd130x->regmap, SSD13XX_DATA, values, count);
> }
Stray change. If needed, either explain in the commit message or create
a separate patch (depending on the dependencies).
...
> unsigned int i;
> int ret;
>
> + /*
> + * The SSD135X family latches command parameters with D/C# HIGH (i.e.
> + * clocked in as data), unlike the other families where the opcode and
> + * all of its parameters are sent as commands (D/C# LOW). Send the
> + * opcode as a command and any following parameter bytes as data.
> + */
> + if (ssd130x->device_info->family_id == SSD135X_FAMILY) {
> + if (len == 0)
> + return 0;
> + ret = regmap_write(ssd130x->regmap, SSD13XX_COMMAND, cmd[0]);
> + if (ret || len == 1)
> + return ret;
> +
> + return ssd130x_write_data(ssd130x, cmd + 1, len - 1);
> + }
> for (i = 0; i < len; i++) {
This loop seems for the len, so it will be the same for both devices as far as
I can see the context. I can't find this piece in the original driver, perhaps
it's some dependency?
> ret = regmap_write(ssd130x->regmap, SSD13XX_COMMAND, cmd[i]);
> if (ret)
...
> +/*
> + * Variadic wrapper around ssd130x_write_cmds(). The first variadic argument is
> + * the command opcode and the following ones are its options/parameters.
> + */
> +static int ssd130x_write_cmd(struct ssd130x_device *ssd130x, int count,
> + /* u8 cmd, u8 option, ... */...)
> +{
> + u8 buf[8];
> + va_list ap;
> + int i;
> +
> + if (count > ARRAY_SIZE(buf))
> + return -EINVAL;
> +
> + va_start(ap, count);
> + for (i = 0; i < count; i++)
Can be
for (int i = 0; i < count; i++)
> + buf[i] = va_arg(ap, int);
> + va_end(ap);
> +
> + return ssd130x_write_cmds(ssd130x, buf, count);
> +}
...
> +static int ssd135x_init(struct ssd130x_device *ssd130x)
> +{
> + /*
> + * Horizontal address increment, COM split, reversed COM scan direction,
> + * BGR sub-pixel order and 65k (RGB565) color depth. Rotation is not
> + * supported, so the remap byte is fixed.
> + */
> + u8 remap = SSD135X_SET_REMAP_65K | SSD135X_SET_REMAP_COM_SPLIT |
> + SSD135X_SET_REMAP_COLOR_BGR | SSD135X_SET_REMAP_COM_SCAN;
> + const u8 cmds[] = {
Why not static?
> + 2, SSD135X_SET_COMMAND_LOCK, 0x12,
> + 2, SSD135X_SET_COMMAND_LOCK, 0xb1,
> + 1, SSD13XX_DISPLAY_OFF,
> + 2, SSD135X_SET_CLOCK_FREQ, 0xf1,
> + 2, SSD135X_SET_MUX_RATIO, ssd130x->height - 1,
> + 3, SSD135X_SET_COL_RANGE, 0x00, ssd130x->width - 1,
> + 3, SSD135X_SET_ROW_RANGE, 0x00, ssd130x->height - 1,
> + 2, SSD135X_SET_DISPLAY_START, 0x00,
> + 2, SSD135X_SET_DISPLAY_OFFSET, 0x00,
> + 2, SSD135X_SET_GPIO, 0x00,
> + 2, SSD135X_SET_FUNCTION, 0x01,
> + 2, SSD135X_SET_PHASE_LENGTH, 0x32,
> + 4, SSD135X_SET_VSL, 0xa0, 0xb5, 0x55,
> + 2, SSD135X_SET_PRECHARGE, 0x17,
> + 2, SSD135X_SET_VCOMH_VOLTAGE, 0x05,
> + 4, SSD135X_SET_CONTRAST, 0xc8, 0x80, 0xc8,
> + 2, SSD135X_SET_CONTRAST_MASTER, 0x0f,
> + 2, SSD135X_SET_PRECHARGE2, 0x01,
> + 1, SSD135X_SET_DISPLAY_NORMAL,
> + 2, SSD13XX_SET_SEG_REMAP, remap,
> + 0,
No trailing comma for the terminator entry.
> + };
> +
> + /*
> + * ssd130x_power_on() issues a short reset pulse, but the SSD1351 is not
> + * ready to accept commands immediately afterwards. Give the controller
> + * time to settle before sending the init sequence.
> + */
Any reference to the datasheet?
> + msleep(120);
> +
> + return ssd130x_run_cmd_seq(ssd130x, cmds);
> +}
...
> +/*
> + * Write a run of pixel data to the controller's display RAM. The SSD135X
> + * family requires an explicit Write RAM command once the address window has
> + * been set, before any pixel data is accepted; the SSD133X family enters data
> + * mode implicitly after the column/row range is programmed.
> + */
> +static int ssd133x_write_pixels(struct ssd130x_device *ssd130x,
> + u8 *data_array, unsigned int count)
> +{
> + if (ssd130x->device_info->family_id == SSD135X_FAMILY) {
> + int ret = ssd130x_write_cmd(ssd130x, 1, SSD135X_WRITE_RAM);
> +
> + if (ret < 0)
> + return ret;
This style is discouraged as it's harder to maintain. Better to split
assignment and definition
int ret;
ret = ssd130x_write_cmd(ssd130x, 1, SSD135X_WRITE_RAM);
if (ret < 0)
return ret;
> + }
> +
> + return ssd130x_write_data(ssd130x, data_array, count);
> +}
...
> static const struct drm_plane_helper_funcs ssd130x_primary_plane_helper_funcs[]
> .atomic_check = ssd133x_primary_plane_atomic_check,
> .atomic_update = ssd133x_primary_plane_atomic_update,
> .atomic_disable = ssd133x_primary_plane_atomic_disable,
> + },
> + [SSD135X_FAMILY] = {
> + DRM_GEM_SHADOW_PLANE_HELPER_FUNCS,
> + .atomic_check = ssd133x_primary_plane_atomic_check,
> + .atomic_update = ssd133x_primary_plane_atomic_update,
> + .atomic_disable = ssd133x_primary_plane_atomic_disable,
> }
As per another similar case.
> };
...
> static const struct drm_encoder_helper_funcs ssd130x_encoder_helper_funcs[] = {
> [SSD133X_FAMILY] = {
> .atomic_enable = ssd133x_encoder_atomic_enable,
> .atomic_disable = ssd130x_encoder_atomic_disable,
> + },
> + [SSD135X_FAMILY] = {
> + .atomic_enable = ssd135x_encoder_atomic_enable,
> + .atomic_disable = ssd130x_encoder_atomic_disable,
> }
> };
Ditto.
...
> diff --git a/drivers/gpu/drm/solomon/ssd130x.h b/drivers/gpu/drm/solomon/ssd130x.h
> index b0b487c06e04..da89d4455270 100644
> --- a/drivers/gpu/drm/solomon/ssd130x.h
> +++ b/drivers/gpu/drm/solomon/ssd130x.h
> @@ -26,7 +26,8 @@
> enum ssd130x_family_ids {
> SSD130X_FAMILY,
> SSD132X_FAMILY,
> - SSD133X_FAMILY
> + SSD133X_FAMILY,
> + SSD135X_FAMILY
Ditto, and this is exactly the whole point why non-terminator entries should
have a trailing comma.
> };
...
> enum ssd130x_variants {
> SSD1327_ID,
> /* ssd133x family */
> SSD1331_ID,
> + /* ssd135x family */
> + SSD1351_ID,
> NR_SSD130X_VARIANTS
See the difference? Here is terminator, which is clear. The above cases are
not.
> };
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 0/3] staging: media: atomisp: use kvmalloc_objs() and drop redundant OOM messages
From: Andy Shevchenko @ 2026-06-23 9:29 UTC (permalink / raw)
To: Rodrigo Gobbi
Cc: andy, hansg, mchehab, sakari.ailus, gregkh, ~lkcamp/patches,
linux-kernel-mentees, linux-kernel, linux-media, linux-staging
In-Reply-To: <20260622224402.34001-1-rodrigo.gobbi.7@gmail.com>
On Mon, Jun 22, 2026 at 07:42:41PM -0300, Rodrigo Gobbi wrote:
> Several allocations in the atomisp driver still size their buffers with
> open-coded multiplication, e.g. width * height * sizeof(*p). When the
> dimensions are large the product can silently wrap, causing kvmalloc()
> to allocate an undersized buffer.
>
> Convert the remaining sites to kvmalloc_objs() with array_size(), which
> saturate to SIZE_MAX on overflow so kvmalloc() returns NULL instead of
> allocating too few bytes.
>
> This continues the work started in commit [2], and picks up the stalled
> sites from [1], unifying with [3].
>
> While here, drop the redundant IA_CSS_ERROR("out of memory") messages on
> the touched allocation paths: the memory management core already emits a
> far more detailed warning on allocation failure as raised at [1].
> [1] https://lore.kernel.org/all/20260413112904.98864-1-feng@innora.ai/
> [2] https://github.com/torvalds/linux/commit/d178c7ca8fefc28115d35b94c3b1f4d653e34182
> [3] https://lore.kernel.org/all/20260609215110.118860-1-rodrigo.gobbi.7@gmail.com/
> ---
> Hi, all,
> Regarding a comment from Andy at [3]:
> > There is a ongoing effort like this for other files from atomisp
> > at [1], yet, it is not covering the same file.
> > [1] https://lore.kernel.org/all/20260413112904.98864-1-feng@innora.ai/
>
> > Yeah, the problem is that the activity seems stale. Can you pickup all
> > the patches from the mailing list that have not been yet applied (regarding
> > k*alloc() uses) and combine them into series or so and update regarding to
> > Sakari's comments?
> The only patches that I found from stale threads were added in this series,
> hope that is fine now.
You need to preserve the original authors.
Also see individual comments.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3] staging: media: atomisp: anr: move trailing statement to its own line
From: Andy Shevchenko @ 2026-06-23 9:26 UTC (permalink / raw)
To: Mani Bharadwaj
Cc: hansg, mchehab, sakari.ailus, andy, gregkh, linux-media,
linux-kernel, linux-staging
In-Reply-To: <20260622184100.33490-1-manibharadwajcr@gmail.com>
On Tue, Jun 23, 2026 at 12:11:00AM +0530, Mani Bharadwaj wrote:
> Move the return statement in ia_css_anr_dump() to its own line
> to fix the following checkpatch error:
>
> ERROR: trailing statements should be on next line
>
> No functional change.
>
> Changes in v3:
> - Fix subject prefix: add missing 'media:' subsystem tag
> per Media CI bot feedback.
No. Take your time and read the linux-media mailing list archive for last a few
months in regard to this driver. Only _after_ think about contribution (what to
contribute and how).
...
Also read the process documentation. Do your homework before, please.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: rtl8723bs: fix CamelCase warnings in rtw_efuse.c
From: Dan Carpenter @ 2026-06-23 9:21 UTC (permalink / raw)
To: Bruce Ou; +Cc: Greg Kroah-Hartman, linux-staging, linux-kernel
In-Reply-To: <20260623075507.6157-1-oubruce1234@gmail.com>
On Tue, Jun 23, 2026 at 03:55:07PM +0800, Bruce Ou wrote:
> Signed-off-by: Bruce Ou <oubruce1234@gmail.com>
> ---
No commit message. You're working against an old tree as well. You
need to work against linux-next or devel-next.
Please, don't send a patch at a time, one by one throughout the day.
Send them as a patchset.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2 3/4] drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support
From: Markus Elfring @ 2026-06-23 9:05 UTC (permalink / raw)
To: Amit Barzilai, dri-devel, devicetree, linux-fbdev, linux-staging,
Andy Shevchenko, Conor Dooley, David Airlie, Greg Kroah-Hartman,
Helge Deller, Javier Martinez Canillas, Krzysztof Kozlowski,
Maarten Lankhorst, Maxime Ripard, Rob Herring, Simona Vetter,
Thomas Zimmermann
Cc: LKML, Adam Azuddin, Chintan Patel
In-Reply-To: <20260622152506.78627-4-amit.barzilai22@gmail.com>
…
> +++ b/drivers/gpu/drm/solomon/ssd130x.c
> @@ -146,6 +146,33 @@
> #define SSD133X_COLOR_DEPTH_256 0x0
> #define SSD133X_COLOR_DEPTH_65K 0x1
>
> +/* ssd135x commands */
> +#define SSD135X_SET_COL_RANGE 0x15
> +#define SSD135X_WRITE_RAM 0x5c
> +#define SSD135X_SET_ROW_RANGE 0x75
…
How do you think about to use an enumeration for such data?
https://en.wikipedia.org/wiki/Enumerated_type#C_and_syntactically_similar_languages
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 2/4] drm/ssd130x: Add RGB565 support to SSD133X family
From: Andy Shevchenko @ 2026-06-23 9:03 UTC (permalink / raw)
To: Amit Barzilai
Cc: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam,
chintanlike, dri-devel, devicetree, linux-kernel, linux-fbdev,
linux-staging
In-Reply-To: <20260622152506.78627-3-amit.barzilai22@gmail.com>
On Mon, Jun 22, 2026 at 06:25:04PM +0300, Amit Barzilai wrote:
> SSD133X screens were getting 8bpp (RGB332) instead of the 16bpp
> (RGB565) that they support. This change adds a boolean to the
> deviceinfo struct selecting whether the variant is driven at
> DRM_FORMAT_RGB565.
>
> Changed SSD133X to now utilize 65k color (RGB565).
...
> - * Each Segment has a 8-bit pixel and each Common output has a
> - * row of pixels. When using the (default) horizontal address
> - * increment mode, each byte of data sent to the controller has
> - * a Segment (e.g: SEG0).
> + * Each Segment holds one pixel and each Common output has a row
> + * of pixels. A pixel is 8 bits (one byte) in the 256 color
> + * (RGB332) format or 16 bits (two bytes) in the 65k color
> + * (RGB565) format. When using the (default) horizontal address
> + * increment mode, the pixel data is sent Segment by Segment
> + * (e.g: SEG0 first).
> *
> * When using the 256 color depth format, each pixel contains 3
> * sub-pixels for color A, B and C. These have 3 bit, 3 bit and
> * 2 bits respectively.
Something wrong with the plural. There is a difference between "3-bit" and
"3 bits", but "3 bit" is odd.
> + *
> + * When using the 65k color depth format, each pixel contains 3
> + * sub-pixels for color A, B and C. These have 5 bit, 6 bit and
> + * 5 bits respectively.
Same mistake is repeated here.
...
> + /*
> + * Per-variant output format selector for the SSD133X data path. The
> + * hardware can drive the panel in RGB332 (1 byte/pixel) or RGB565
> + * (2 bytes/pixel); this is a policy choice per variant, not a
In other comments it was spelled fully, be consistent "1 byte per pixel",
"2 bytes per pixel".
> + * capability probe. When set, the variant is driven at RGB565.
> + */
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: rtl8723bs: remove unused function declarations
From: Dan Carpenter @ 2026-06-23 9:00 UTC (permalink / raw)
To: Aditya Chari; +Cc: gregkh, linux-staging, linux-kernel
In-Reply-To: <20260622052543.61590-1-adi25charis@gmail.com>
On Mon, Jun 22, 2026 at 10:55:43AM +0530, Aditya Chari wrote:
> rtl8192c_translate_rx_signal_stuff() and rtl8192c_query_rx_desc_status()
> are declared in rtl8192c_recv.h but have no implementation and no
> caller anywhere in the kernel tree. They are leftover from when this
> driver was derived from Realtek's shared vendor codebase covering
> multiple chip families.
>
> Verified via grep across the full tree that neither symbol is
> referenced outside this declaration, and confirmed via a full build
> of the module before and after removal that no warnings or errors
> are introduced.
>
> This addresses the "find and remove any code for other chips that is
> left over" item in the driver's TODO file.
>
> Signed-off-by: Aditya Chari <adi25charis@gmail.com>
> ---
You're working against an old tree. Work against linux-next or
devel-next.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] staging: rtl8723bs: fix CamelCase warnings for bResult and Address in rtw_efuse.c
From: Bruce Ou @ 2026-06-23 8:56 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-staging, linux-kernel, Bruce Ou
Signed-off-by: Bruce Ou <oubruce1234@gmail.com>
---
drivers/staging/rtl8723bs/core/rtw_efuse.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c b/drivers/staging/rtl8723bs/core/rtw_efuse.c
index b5dc5892f..355ac2004 100644
--- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
+++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
@@ -44,7 +44,7 @@ Efuse_CalculateWordCnts(u8 word_en)
u8
EFUSE_Read1Byte(
struct adapter *Adapter,
-u16 Address)
+u16 address)
{
u8 byte_temp = {0x00};
u8 temp = {0x00};
@@ -53,13 +53,13 @@ u16 Address)
Hal_GetEfuseDefinition(Adapter, EFUSE_WIFI, TYPE_EFUSE_REAL_CONTENT_LEN, &content_len);
- if (Address < content_len) {/* E-fuse 512Byte */
+ if (address < content_len) {/* E-fuse 512Byte */
/* Write E-fuse Register address bit0~7 */
- temp = Address & 0xFF;
+ temp = address & 0xFF;
rtw_write8(Adapter, EFUSE_CTRL + 1, temp);
byte_temp = rtw_read8(Adapter, EFUSE_CTRL + 2);
/* Write E-fuse Register address bit8~9 */
- temp = ((Address >> 8) & 0x03) | (byte_temp & 0xFC);
+ temp = ((address >> 8) & 0x03) | (byte_temp & 0xFC);
rtw_write8(Adapter, EFUSE_CTRL + 2, temp);
/* Write 0x30[31]= 0 */
@@ -89,7 +89,7 @@ u16 addr,
u8 *data)
{
u32 tmpidx = 0;
- u8 bResult;
+ u8 result;
u8 readbyte;
/* <20130121, Kordan> For SMIC EFUSE specificatoin. */
@@ -114,13 +114,13 @@ u8 *data)
}
if (tmpidx < 100) {
*data = rtw_read8(padapter, EFUSE_CTRL);
- bResult = true;
+ result = true;
} else {
*data = 0xff;
- bResult = false;
+ result = false;
}
- return bResult;
+ return result;
}
/*-----------------------------------------------------------------------------
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] staging: rtl8723bs: fix timer rescheduling in rtw_cmd callbacks
From: Dan Carpenter @ 2026-06-23 8:58 UTC (permalink / raw)
To: Ganesh Harshan
Cc: gregkh, linux-staging, linux-kernel, khushalchitturi,
dennylin0707
In-Reply-To: <20260622230448.4138-1-ganeshredcobra@gmail.com>
On Mon, Jun 22, 2026 at 07:04:48PM -0400, Ganesh Harshan wrote:
> Ensure scan and association timers are deleted before being
> rescheduled when command execution fails.
>
> Without deleting the existing timer, multiple timer instances
> may be active simultaneously, potentially leading to duplicate
> timeout handling or unexpected behavior.
>
> Use timer_delete_sync() to safely stop active timers before
> rescheduling.
>
> Signed-off-by: Ganesh Harshan <ganeshredcobra@gmail.com>
> ---
> drivers/staging/rtl8723bs/core/rtw_cmd.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c b/drivers/staging/rtl8723bs/core/rtw_cmd.c
> index b932670f5d63..967c3258e0b8 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c
> @@ -1801,7 +1801,9 @@ void rtw_survey_cmd_callback(struct adapter *padapter, struct cmd_obj *pcmd)
> struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
>
> if (pcmd->res != H2C_SUCCESS) {
> - /* TODO: cancel timer and do timeout handler directly... */
> + /* Ensure timer is safely rescheduled */
> + if (timer_pending(&pmlmepriv->scan_to_timer))
> + timer_delete_sync(&pmlmepriv->scan_to_timer);
> _set_timer(&pmlmepriv->scan_to_timer, 1);
Sorry, but this seems like a pointless change.
The _set_timer(&pmlmepriv->scan_to_timer, 1) means we want the timer to
trigger in 1 ms. In the current code if it's already running, it will
run again in 1ms.
In your code, we test if it's running and if it is then we wait for it
to stop and then delete the timer so nothing else can run, and then we
run it again in 1ms.
The result is 100% the same either way. Either way we call the
rtw_scan_timeout_handler() function twice. And that's fine so far as
I can see.
You have misunderstood the comment. They wanted to disable the timer
and call rtw_scan_timeout_handler() right away instead of with a 1ms
delay. I don't know how much weight I would put in this comment. We
won't be able accept a change like that unless you are able to test it.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2 4/4] staging: fbtft: remove fb_ssd1351 driver
From: Javier Martinez Canillas @ 2026-06-23 8:50 UTC (permalink / raw)
To: Andy Shevchenko, Amit Barzilai
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, robh,
krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam, chintanlike,
dri-devel, devicetree, linux-kernel, linux-fbdev, linux-staging
In-Reply-To: <ajpGy7K4eM8oJIfD@ashevche-desk.local>
Andy Shevchenko <andriy.shevchenko@intel.com> writes:
> On Mon, Jun 22, 2026 at 06:25:06PM +0300, Amit Barzilai wrote:
>> The SSD1351 support was added to the ssd130x DRM driver. To avoid
>> confusion and irrelevant updates, the staging fb_ssd1351 driver is
>> removed.
>
> NAK, the fbtft has two drivers in one (SPI + parallel), plus as Maxime said,
> it has its own binding.
>
Yes, I agree that we don't want to delete the fbtft driver.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ 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