* [PATCH v2 1/8] staging: sm750fb: change sii164GetDeviceID to snake_case
From: Richard Akintola @ 2025-04-08 10:20 UTC (permalink / raw)
To: outreachy
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel, Richard Akintola
In-Reply-To: <cover.1744105388.git.princerichard17a@gmail.com>
Change camelCase function name sii164GetDeviceID to sii164_get_device_id
to conform to kernel code styles as reported by checkpatch.pl
CHECK: Avoid camelCase: <sii164GetDeviceID>
Signed-off-by: Richard Akintola <princerichard17a@gmail.com>
---
drivers/staging/sm750fb/ddk750_dvi.c | 2 +-
drivers/staging/sm750fb/ddk750_sii164.c | 6 +++---
drivers/staging/sm750fb/ddk750_sii164.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
index 8b81e8642f9e..3fb14eff2de1 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -16,7 +16,7 @@ static struct dvi_ctrl_device dcft_supported_dvi_controller[] = {
{
.init = sii164_init_chip,
.get_vendor_id = sii164_get_vendor_id,
- .get_device_id = sii164GetDeviceID,
+ .get_device_id = sii164_get_device_id,
#ifdef SII164_FULL_FUNCTIONS
.reset_chip = sii164ResetChip,
.get_chip_string = sii164GetChipString,
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
index 2532b60245ac..223c181dc649 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -48,13 +48,13 @@ unsigned short sii164_get_vendor_id(void)
}
/*
- * sii164GetDeviceID
+ * sii164_get_device_id
* This function gets the device ID of the DVI controller chip.
*
* Output:
* Device ID
*/
-unsigned short sii164GetDeviceID(void)
+unsigned short sii164_get_device_id(void)
{
unsigned short deviceID;
@@ -141,7 +141,7 @@ long sii164_init_chip(unsigned char edge_select,
/* Check if SII164 Chip exists */
if ((sii164_get_vendor_id() == SII164_VENDOR_ID) &&
- (sii164GetDeviceID() == SII164_DEVICE_ID)) {
+ (sii164_get_device_id() == SII164_DEVICE_ID)) {
/*
* Initialize SII164 controller chip.
*/
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
index 71a7c1cb42c4..a76091f6622b 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -28,7 +28,7 @@ long sii164_init_chip(unsigned char edgeSelect,
unsigned char pllFilterValue);
unsigned short sii164_get_vendor_id(void);
-unsigned short sii164GetDeviceID(void);
+unsigned short sii164_get_device_id(void);
#ifdef SII164_FULL_FUNCTIONS
void sii164ResetChip(void);
--
2.39.5
^ permalink raw reply related
* [PATCH v2 2/8] staging: sm750fb: change sii164ResetChip to snake_case
From: Richard Akintola @ 2025-04-08 10:20 UTC (permalink / raw)
To: outreachy
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel, Richard Akintola
In-Reply-To: <cover.1744105388.git.princerichard17a@gmail.com>
Change camelCase function name sii164ResetChip to sii164_reset_chip
to conform to kernel code styles 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(-)
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
index 3fb14eff2de1..6dee95e60a6e 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -18,7 +18,7 @@ static struct dvi_ctrl_device dcft_supported_dvi_controller[] = {
.get_vendor_id = sii164_get_vendor_id,
.get_device_id = sii164_get_device_id,
#ifdef SII164_FULL_FUNCTIONS
- .reset_chip = sii164ResetChip,
+ .reset_chip = sii164_reset_chip,
.get_chip_string = sii164GetChipString,
.set_power = sii164SetPower,
.enable_hot_plug_detection = sii164EnableHotPlugDetection,
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
index 223c181dc649..284c32f7e9b4 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -250,10 +250,10 @@ long sii164_init_chip(unsigned char edge_select,
#ifdef SII164_FULL_FUNCTIONS
/*
- * sii164ResetChip
+ * sii164_reset_chip
* This function resets the DVI Controller Chip.
*/
-void sii164ResetChip(void)
+void sii164_reset_chip(void)
{
/* Power down */
sii164SetPower(0);
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
index a76091f6622b..7a71f94a1e9b 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -31,7 +31,7 @@ unsigned short sii164_get_vendor_id(void);
unsigned short sii164_get_device_id(void);
#ifdef SII164_FULL_FUNCTIONS
-void sii164ResetChip(void);
+void sii164_reset_chip(void);
char *sii164GetChipString(void);
void sii164SetPower(unsigned char powerUp);
void sii164EnableHotPlugDetection(unsigned char enableHotPlug);
--
2.39.5
^ permalink raw reply related
* [PATCH v2 3/8] staging: sm750fb: change sii164SetPower to snake_case
From: Richard Akintola @ 2025-04-08 10:20 UTC (permalink / raw)
To: outreachy
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel, Richard Akintola
In-Reply-To: <cover.1744105388.git.princerichard17a@gmail.com>
Change camelCase function name sii164SetPower to sii164_set_power
to conform to kernel code styles as reported by checkpatch.pl
CHECK: Avoid camelCase: <sii164SetPower>
Signed-off-by: Richard Akintola <princerichard17a@gmail.com>
---
drivers/staging/sm750fb/ddk750_dvi.c | 2 +-
drivers/staging/sm750fb/ddk750_sii164.c | 8 ++++----
drivers/staging/sm750fb/ddk750_sii164.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
index 6dee95e60a6e..bb7538682b7d 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -20,7 +20,7 @@ static struct dvi_ctrl_device dcft_supported_dvi_controller[] = {
#ifdef SII164_FULL_FUNCTIONS
.reset_chip = sii164_reset_chip,
.get_chip_string = sii164GetChipString,
- .set_power = sii164SetPower,
+ .set_power = sii164_set_power,
.enable_hot_plug_detection = sii164EnableHotPlugDetection,
.is_connected = sii164IsConnected,
.check_interrupt = sii164CheckInterrupt,
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
index 284c32f7e9b4..b96f9369fab4 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -256,8 +256,8 @@ long sii164_init_chip(unsigned char edge_select,
void sii164_reset_chip(void)
{
/* Power down */
- sii164SetPower(0);
- sii164SetPower(1);
+ sii164_set_power(0);
+ sii164_set_power(1);
}
/*
@@ -273,13 +273,13 @@ char *sii164GetChipString(void)
}
/*
- * sii164SetPower
+ * sii164_set_power
* This function sets the power configuration of the DVI Controller Chip.
*
* Input:
* powerUp - Flag to set the power down or up
*/
-void sii164SetPower(unsigned char powerUp)
+void sii164_set_power(unsigned char powerUp)
{
unsigned char config;
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
index 7a71f94a1e9b..45a90489c95c 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -33,7 +33,7 @@ unsigned short sii164_get_device_id(void);
#ifdef SII164_FULL_FUNCTIONS
void sii164_reset_chip(void);
char *sii164GetChipString(void);
-void sii164SetPower(unsigned char powerUp);
+void sii164_set_power(unsigned char powerUp);
void sii164EnableHotPlugDetection(unsigned char enableHotPlug);
unsigned char sii164IsConnected(void);
unsigned char sii164CheckInterrupt(void);
--
2.39.5
^ permalink raw reply related
* [PATCH v2 4/8] staging: sm750fb: change sii164GetChipString to snake_case
From: Richard Akintola @ 2025-04-08 10:20 UTC (permalink / raw)
To: outreachy
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel, Richard Akintola
In-Reply-To: <cover.1744105388.git.princerichard17a@gmail.com>
Change camelCase function name sii164GetChipString to sii164_get_chip_string
to conform to kernel code styles as reported by checkpatch.pl
CHECK: Avoid camelCase: <sii164GetChipString>
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(-)
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
index bb7538682b7d..c12df1f9fb00 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -19,7 +19,7 @@ static struct dvi_ctrl_device dcft_supported_dvi_controller[] = {
.get_device_id = sii164_get_device_id,
#ifdef SII164_FULL_FUNCTIONS
.reset_chip = sii164_reset_chip,
- .get_chip_string = sii164GetChipString,
+ .get_chip_string = sii164_get_chip_string,
.set_power = sii164_set_power,
.enable_hot_plug_detection = sii164EnableHotPlugDetection,
.is_connected = sii164IsConnected,
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
index b96f9369fab4..d0b80b86a4d7 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -261,13 +261,13 @@ void sii164_reset_chip(void)
}
/*
- * sii164GetChipString
+ * sii164_get_chip_string
* This function returns a char string name of the current DVI Controller
* chip.
*
* It's convenient for application need to display the chip name.
*/
-char *sii164GetChipString(void)
+char *sii164_get_chip_string(void)
{
return gDviCtrlChipName;
}
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
index 45a90489c95c..c15cd6a5d53b 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -32,7 +32,7 @@ unsigned short sii164_get_device_id(void);
#ifdef SII164_FULL_FUNCTIONS
void sii164_reset_chip(void);
-char *sii164GetChipString(void);
+char *sii164_get_chip_string(void);
void sii164_set_power(unsigned char powerUp);
void sii164EnableHotPlugDetection(unsigned char enableHotPlug);
unsigned char sii164IsConnected(void);
--
2.39.5
^ permalink raw reply related
* [PATCH v2 5/8] staging: sm750fb: change sii164EnableHotPlugDetection to snake_case
From: Richard Akintola @ 2025-04-08 10:20 UTC (permalink / raw)
To: outreachy
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel, Richard Akintola
In-Reply-To: <cover.1744105388.git.princerichard17a@gmail.com>
Change camelCase function name sii164EnableHotPlugDetection to sii164_enable_hot_plug_detection
and it's parameter enableHotPlug to enable_hot_plug
to conform to kernel code styles as reported by checkpatch.pl
CHECK: Avoid camelCase: <sii164EnableHotPlugDetection>
Signed-off-by: Richard Akintola <princerichard17a@gmail.com>
---
drivers/staging/sm750fb/ddk750_dvi.c | 2 +-
drivers/staging/sm750fb/ddk750_sii164.c | 8 ++++----
drivers/staging/sm750fb/ddk750_sii164.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
index c12df1f9fb00..1ce44c50617a 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -21,7 +21,7 @@ static struct dvi_ctrl_device dcft_supported_dvi_controller[] = {
.reset_chip = sii164_reset_chip,
.get_chip_string = sii164_get_chip_string,
.set_power = sii164_set_power,
- .enable_hot_plug_detection = sii164EnableHotPlugDetection,
+ .enable_hot_plug_detection = sii164_enable_hot_plug_detection,
.is_connected = sii164IsConnected,
.check_interrupt = sii164CheckInterrupt,
.clear_interrupt = sii164ClearInterrupt,
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
index d0b80b86a4d7..c8db6ceee9af 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -329,12 +329,12 @@ void sii164SelectHotPlugDetectionMode(enum sii164_hot_plug_mode hotPlugMode)
}
/*
- * sii164EnableHotPlugDetection
+ * sii164_enable_hot_plug_detection
* This function enables the Hot Plug detection.
*
- * enableHotPlug - Enable (=1) / disable (=0) Hot Plug detection
+ * enable_hot_plug - Enable (=1) / disable (=0) Hot Plug detection
*/
-void sii164EnableHotPlugDetection(unsigned char enableHotPlug)
+void sii164_enable_hot_plug_detection(unsigned char enable_hot_plug)
{
unsigned char detectReg;
@@ -343,7 +343,7 @@ void sii164EnableHotPlugDetection(unsigned char enableHotPlug)
/* Depending on each DVI controller, need to enable the hot plug based
* on each individual chip design.
*/
- if (enableHotPlug != 0)
+ if (enable_hot_plug != 0)
sii164SelectHotPlugDetectionMode(SII164_HOTPLUG_USE_MDI);
else
sii164SelectHotPlugDetectionMode(SII164_HOTPLUG_DISABLE);
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
index c15cd6a5d53b..9e289bf4a78e 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -34,7 +34,7 @@ unsigned short sii164_get_device_id(void);
void sii164_reset_chip(void);
char *sii164_get_chip_string(void);
void sii164_set_power(unsigned char powerUp);
-void sii164EnableHotPlugDetection(unsigned char enableHotPlug);
+void sii164_enable_hot_plug_detection(unsigned char enable_hot_plug);
unsigned char sii164IsConnected(void);
unsigned char sii164CheckInterrupt(void);
void sii164ClearInterrupt(void);
--
2.39.5
^ permalink raw reply related
* [PATCH v2 6/8] staging: sm750fb: change sii164IsConnected to snake_case
From: Richard Akintola @ 2025-04-08 10:20 UTC (permalink / raw)
To: outreachy
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel, Richard Akintola
In-Reply-To: <cover.1744105388.git.princerichard17a@gmail.com>
Change camelCase function name sii164IsConnected to sii164_is_connected
to conform to kernel code styles as reported by checkpatch.pl
CHECK: Avoid camelCase: <sii164IsConnected>
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(-)
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
index 1ce44c50617a..ac1aab77da28 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -22,7 +22,7 @@ static struct dvi_ctrl_device dcft_supported_dvi_controller[] = {
.get_chip_string = sii164_get_chip_string,
.set_power = sii164_set_power,
.enable_hot_plug_detection = sii164_enable_hot_plug_detection,
- .is_connected = sii164IsConnected,
+ .is_connected = sii164_is_connected,
.check_interrupt = sii164CheckInterrupt,
.clear_interrupt = sii164ClearInterrupt,
#endif
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
index c8db6ceee9af..6ce15b7816d9 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -350,14 +350,14 @@ void sii164_enable_hot_plug_detection(unsigned char enable_hot_plug)
}
/*
- * sii164IsConnected
+ * sii164_is_connected
* Check if the DVI Monitor is connected.
*
* Output:
* 0 - Not Connected
* 1 - Connected
*/
-unsigned char sii164IsConnected(void)
+unsigned char sii164_is_connected(void)
{
unsigned char hotPlugValue;
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
index 9e289bf4a78e..90b7ae823a10 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -35,7 +35,7 @@ void sii164_reset_chip(void);
char *sii164_get_chip_string(void);
void sii164_set_power(unsigned char powerUp);
void sii164_enable_hot_plug_detection(unsigned char enable_hot_plug);
-unsigned char sii164IsConnected(void);
+unsigned char sii164_is_connected(void);
unsigned char sii164CheckInterrupt(void);
void sii164ClearInterrupt(void);
#endif
--
2.39.5
^ permalink raw reply related
* [PATCH v2 7/8] staging: sm750fb: change sii164CheckInterrupt to snake_case
From: Richard Akintola @ 2025-04-08 10:20 UTC (permalink / raw)
To: outreachy
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel, Richard Akintola
In-Reply-To: <cover.1744105388.git.princerichard17a@gmail.com>
Change camelCase function name sii164CheckInterrupt to
sii164_check_interrupt in order to conform to kernel code styles
as reported by checkpatch.pl
CHECK: Avoid camelCase: <sii164CheckInterrupt>
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(-)
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
index ac1aab77da28..1def02be4cce 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -23,7 +23,7 @@ static struct dvi_ctrl_device dcft_supported_dvi_controller[] = {
.set_power = sii164_set_power,
.enable_hot_plug_detection = sii164_enable_hot_plug_detection,
.is_connected = sii164_is_connected,
- .check_interrupt = sii164CheckInterrupt,
+ .check_interrupt = sii164_check_interrupt,
.clear_interrupt = sii164ClearInterrupt,
#endif
},
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
index 6ce15b7816d9..aebde3d8b903 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -370,14 +370,14 @@ unsigned char sii164_is_connected(void)
}
/*
- * sii164CheckInterrupt
+ * sii164_check_interrupt
* Checks if interrupt has occurred.
*
* Output:
* 0 - No interrupt
* 1 - Interrupt occurs
*/
-unsigned char sii164CheckInterrupt(void)
+unsigned char sii164_check_interrupt(void)
{
unsigned char detectReg;
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
index 90b7ae823a10..aa3f34c13979 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -36,7 +36,7 @@ char *sii164_get_chip_string(void);
void sii164_set_power(unsigned char powerUp);
void sii164_enable_hot_plug_detection(unsigned char enable_hot_plug);
unsigned char sii164_is_connected(void);
-unsigned char sii164CheckInterrupt(void);
+unsigned char sii164_check_interrupt(void);
void sii164ClearInterrupt(void);
#endif
/*
--
2.39.5
^ permalink raw reply related
* [PATCH v2 8/8] staging: sm750fb: change sii164ClearInterrupt to snake_case
From: Richard Akintola @ 2025-04-08 10:20 UTC (permalink / raw)
To: outreachy
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel, Richard Akintola
In-Reply-To: <cover.1744105388.git.princerichard17a@gmail.com>
Change camelCase function name sii164ClearInterrupt to
sii164_clear_interrupt in order to conform to kernel code styles
as reported by checkpatch.pl
CHECK: Avoid camelCase: <sii164ClearInterrupt>
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(-)
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
index 1def02be4cce..6fef1ab484c1 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -24,7 +24,7 @@ static struct dvi_ctrl_device dcft_supported_dvi_controller[] = {
.enable_hot_plug_detection = sii164_enable_hot_plug_detection,
.is_connected = sii164_is_connected,
.check_interrupt = sii164_check_interrupt,
- .clear_interrupt = sii164ClearInterrupt,
+ .clear_interrupt = sii164_clear_interrupt,
#endif
},
#endif
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
index aebde3d8b903..fc725a9952d4 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -390,10 +390,10 @@ unsigned char sii164_check_interrupt(void)
}
/*
- * sii164ClearInterrupt
+ * sii164_clear_interrupt
* Clear the hot plug interrupt.
*/
-void sii164ClearInterrupt(void)
+void sii164_clear_interrupt(void)
{
unsigned char detectReg;
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
index aa3f34c13979..ebc173658f0e 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -37,7 +37,7 @@ void sii164_set_power(unsigned char powerUp);
void sii164_enable_hot_plug_detection(unsigned char enable_hot_plug);
unsigned char sii164_is_connected(void);
unsigned char sii164_check_interrupt(void);
-void sii164ClearInterrupt(void);
+void sii164_clear_interrupt(void);
#endif
/*
* below register definition is used for
--
2.39.5
^ permalink raw reply related
* Re: [PATCH 0/8] staging: sm750fb: change function naming style
From: Richard Akintola @ 2025-04-08 10:38 UTC (permalink / raw)
To: Greg KH
Cc: Samuel Abraham, outreachy, sudipm.mukherjee, teddy.wang,
linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <2025040711-refutable-monetary-f0c4@gregkh>
On Mon, Apr 7, 2025 at 7:01 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Apr 07, 2025 at 06:57:38AM +0100, Richard Akintola wrote:
> > On Sat, Apr 5, 2025 at 3:16 PM Samuel Abraham
> > <abrahamadekunle50@gmail.com> wrote:
> >
> > > 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.
> >
> >
> > Hi Samuel,
> >
> > I sent the patches individually before, but I was instructed to send a
> > patch series.
> >
> > Given that I didn't change any code, should I still add version number
> > and sending
> > patch series as the difference?
>
> Yes.
>
> Think about it from our side, what would you want to see if you had to
> review hundreds of different patches a day?
>
> thanks,
>
> greg k-h
Hi Greg,
I have sent the new version, please do have a look at it.
Thank you.
Richard Akintola
^ permalink raw reply
* Re: [PATCH 0/8] staging: sm750fb: change function naming style
From: Greg KH @ 2025-04-08 10:47 UTC (permalink / raw)
To: Richard Akintola
Cc: Samuel Abraham, outreachy, sudipm.mukherjee, teddy.wang,
linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <CAMyr_bKgveKkpRdOWw+VfZDWridLirHp4VoeG_F-wwgSY5jpgQ@mail.gmail.com>
On Tue, Apr 08, 2025 at 11:38:28AM +0100, Richard Akintola wrote:
> On Mon, Apr 7, 2025 at 7:01 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Apr 07, 2025 at 06:57:38AM +0100, Richard Akintola wrote:
> > > On Sat, Apr 5, 2025 at 3:16 PM Samuel Abraham
> > > <abrahamadekunle50@gmail.com> wrote:
> > >
> > > > 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.
> > >
> > >
> > > Hi Samuel,
> > >
> > > I sent the patches individually before, but I was instructed to send a
> > > patch series.
> > >
> > > Given that I didn't change any code, should I still add version number
> > > and sending
> > > patch series as the difference?
> >
> > Yes.
> >
> > Think about it from our side, what would you want to see if you had to
> > review hundreds of different patches a day?
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
>
> I have sent the new version, please do have a look at it.
Again, please realize that some of us get hundreds, if not thousands, of
changes a day to review. A normal delay is about 1-2 weeks to get to a
review of a change. Ideally it would be faster, but there are only so
many hours in a day.
To help make this faster, please help out in reviewing other changes
submitted by other developers, that will cause your changes to bubble
up.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/8] staging: sm750fb: change function naming style
From: Richard Akintola @ 2025-04-08 11:03 UTC (permalink / raw)
To: Greg KH
Cc: Samuel Abraham, outreachy, sudipm.mukherjee, teddy.wang,
linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <2025040840-domain-boasting-81ec@gregkh>
On Tue, Apr 8, 2025 at 11:48 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Apr 08, 2025 at 11:38:28AM +0100, Richard Akintola wrote:
> > On Mon, Apr 7, 2025 at 7:01 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Mon, Apr 07, 2025 at 06:57:38AM +0100, Richard Akintola wrote:
> > > > On Sat, Apr 5, 2025 at 3:16 PM Samuel Abraham
> > > > <abrahamadekunle50@gmail.com> wrote:
> > > >
> > > > > 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.
> > > >
> > > >
> > > > Hi Samuel,
> > > >
> > > > I sent the patches individually before, but I was instructed to send a
> > > > patch series.
> > > >
> > > > Given that I didn't change any code, should I still add version number
> > > > and sending
> > > > patch series as the difference?
> > >
> > > Yes.
> > >
> > > Think about it from our side, what would you want to see if you had to
> > > review hundreds of different patches a day?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Hi Greg,
> >
> > I have sent the new version, please do have a look at it.
>
> Again, please realize that some of us get hundreds, if not thousands, of
> changes a day to review. A normal delay is about 1-2 weeks to get to a
> review of a change. Ideally it would be faster, but there are only so
> many hours in a day.
>
> To help make this faster, please help out in reviewing other changes
> submitted by other developers, that will cause your changes to bubble
> up.
>
> thanks,
>
> greg k-h
I really do understand the situation and to be candid, I am in no hurry
but won't mind helping out in the review, perhaps a help with Review 101?
thanks,
Richard Akintola
^ permalink raw reply
* [PATCH 0/3] fbdev: Add deferred I/O support for contiguous kernel memory framebuffers
From: mhkelley58 @ 2025-04-08 18:36 UTC (permalink / raw)
To: jayalk, simona, deller, haiyangz, kys, wei.liu, decui, akpm
Cc: weh, tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
From: Michael Kelley <mhklinux@outlook.com>
Current deferred I/O code works only for framebuffer memory that is
allocated with vmalloc(). The code assumes that the underlying page
refcount can be used by the mm subsystem to manage each framebuffer
page's lifecycle, which is consistent with vmalloc'ed memory, but not
with contiguous kernel memory from alloc_pages() or similar. When used
with contiguous kernel memory, current deferred I/O code eventually
causes the memory free lists to be scrambled, and a kernel panic ensues.
The problem is seen with the hyperv_fb driver when mmap'ing the
framebuffer into user space, as that driver uses alloc_pages() for the
framebuffer in some configurations. This patch set fixes the problem
by supporting contiguous kernel memory framebuffers with deferred I/O.
Patch 1 exports a 'mm' subsystem function needed by Patch 2.
Patch 2 is the changes to the fbdev deferred I/O code. More details
are in the commit message of Patch 2.
Patch 3 updates the hyperv_fb driver to use the new functionality
from Patch 2.
Michael Kelley (3):
mm: Export vmf_insert_mixed_mkwrite()
fbdev/deferred-io: Support contiguous kernel memory framebuffers
fbdev: hyperv_fb: Fix mmap of framebuffers allocated using
alloc_pages()
drivers/video/fbdev/core/fb_defio.c | 126 +++++++++++++++++++++++-----
drivers/video/fbdev/hyperv_fb.c | 1 +
include/linux/fb.h | 1 +
mm/memory.c | 1 +
4 files changed, 109 insertions(+), 20 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH 1/3] mm: Export vmf_insert_mixed_mkwrite()
From: mhkelley58 @ 2025-04-08 18:36 UTC (permalink / raw)
To: jayalk, simona, deller, haiyangz, kys, wei.liu, decui, akpm
Cc: weh, tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
In-Reply-To: <20250408183646.1410-1-mhklinux@outlook.com>
From: Michael Kelley <mhklinux@outlook.com>
Export vmf_insert_mixed_mkwrite() for use by fbdev deferred I/O code,
which can be built as a module. For consistency with the related function
vmf_insert_mixed(), export without the GPL qualifier.
Commit cd1e0dac3a3e ("mm: unexport vmf_insert_mixed_mkwrite") is
effectively reverted.
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
---
mm/memory.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/memory.c b/mm/memory.c
index 9d0ba6fe73c1..883ad53d077e 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2660,6 +2660,7 @@ vm_fault_t vmf_insert_mixed_mkwrite(struct vm_area_struct *vma,
{
return __vm_insert_mixed(vma, addr, pfn, true);
}
+EXPORT_SYMBOL(vmf_insert_mixed_mkwrite);
/*
* maps a range of physical memory into the requested pages. the old
--
2.25.1
^ permalink raw reply related
* [PATCH 2/3] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: mhkelley58 @ 2025-04-08 18:36 UTC (permalink / raw)
To: jayalk, simona, deller, haiyangz, kys, wei.liu, decui, akpm
Cc: weh, tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
In-Reply-To: <20250408183646.1410-1-mhklinux@outlook.com>
From: Michael Kelley <mhklinux@outlook.com>
Current defio code works only for framebuffer memory that is allocated
with vmalloc(). The code assumes that the underlying page refcount can
be used by the mm subsystem to manage each framebuffer page's lifecycle,
including freeing the page if the refcount goes to 0. This approach is
consistent with vmalloc'ed memory, but not with contiguous kernel memory
allocated via alloc_pages() or similar. The latter such memory pages
usually have a refcount of 0 when allocated, and would be incorrectly
freed page-by-page if used with defio. That free'ing corrupts the memory
free lists and Linux eventually panics. Simply bumping the refcount after
allocation doesn’t work because when the framebuffer memory is freed,
__free_pages() complains about non-zero refcounts.
Commit 37b4837959cb ("video: deferred io with physically contiguous
memory") from the year 2008 purported to add support for contiguous
kernel memory framebuffers. The motivating device, sh_mobile_lcdcfb, uses
dma_alloc_coherent() to allocate framebuffer memory, which is likely to
use alloc_pages(). It's unclear to me how this commit actually worked at
the time, unless dma_alloc_coherent() was pulling from a CMA pool instead
of alloc_pages(). Or perhaps alloc_pages() worked differently or on the
arm32 architecture on which sh_mobile_lcdcfb is used.
In any case, for x86 and arm64 today, commit 37b4837959cb9 is not
sufficient to support contiguous kernel memory framebuffers. The problem
can be seen with the hyperv_fb driver, which may allocate the framebuffer
memory using vmalloc() or alloc_pages(), depending on the configuration
of the Hyper-V guest VM (Gen 1 vs. Gen 2) and the size of the framebuffer.
Fix this limitation by adding defio support for contiguous kernel memory
framebuffers. A driver with a framebuffer allocated from contiguous
kernel memory must set the FBINFO_KMEMFB flag to indicate such.
Tested with the hyperv_fb driver in both configurations -- with a vmalloc()
framebuffer and with an alloc_pages() framebuffer on x86. Also verified a
vmalloc() framebuffer on arm64. Hardware is not available to me to verify
that the older arm32 devices still work correctly, but the path for
vmalloc() framebuffers is essentially unchanged.
Even with these changes, defio does not support framebuffers in MMIO
space, as defio code depends on framebuffer memory pages having
corresponding 'struct page's.
Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.")
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
---
drivers/video/fbdev/core/fb_defio.c | 126 +++++++++++++++++++++++-----
include/linux/fb.h | 1 +
2 files changed, 107 insertions(+), 20 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c
index 4fc93f253e06..0879973a4572 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -8,11 +8,38 @@
* for more details.
*/
+/*
+ * Deferred I/O ("defio") allows framebuffers that are mmap()'ed to user space
+ * to batch user space writes into periodic updates to the underlying
+ * framebuffer hardware or other implementation (such as with a virtualized
+ * framebuffer in a VM). At each batch interval, a callback is invoked in the
+ * framebuffer's kernel driver, and the callback is supplied with a list of
+ * pages that have been modified in the preceding interval. The callback can
+ * use this information to update the framebuffer hardware as necessary. The
+ * batching can improve performance and reduce the overhead of updating the
+ * hardware.
+ *
+ * Defio is supported on framebuffers allocated using vmalloc() and allocated
+ * as contiguous kernel memory using alloc_pages(), kmalloc(), or
+ * dma_alloc_coherent(), the latter of which might allocate from CMA. These
+ * memory allocations all have corresponding "struct page"s. Framebuffers
+ * in MMIO space are *not* supported because MMIO space does not have
+ * corrresponding "struct page"s.
+ *
+ * For framebuffers allocated using vmalloc(), struct fb_info must have
+ * "screen_buffer" set to the vmalloc address of the framebuffer. For
+ * framebuffers allocated from contiguous kernel memory, FBINFO_KMEMFB must
+ * be set, and "fix.smem_start" must be set to the physical address of the
+ * frame buffer. In both cases, "fix.smem_len" must be set to the framebuffer
+ * size in bytes.
+ */
+
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/mm.h>
+#include <linux/pfn_t.h>
#include <linux/vmalloc.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
@@ -37,7 +64,7 @@ static struct page *fb_deferred_io_get_page(struct fb_info *info, unsigned long
else if (info->fix.smem_start)
page = pfn_to_page((info->fix.smem_start + offs) >> PAGE_SHIFT);
- if (page)
+ if (page && !(info->flags & FBINFO_KMEMFB))
get_page(page);
return page;
@@ -137,6 +164,15 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault *vmf)
BUG_ON(!info->fbdefio->mapping);
+ if (info->flags & FBINFO_KMEMFB)
+ /*
+ * In this path, the VMA is marked VM_PFNMAP, so mm assumes
+ * there is no struct page associated with the page. The
+ * PFN must be directly inserted and the created PTE will be
+ * marked "special".
+ */
+ return vmf_insert_pfn(vmf->vma, vmf->address, page_to_pfn(page));
+
vmf->page = page;
return 0;
}
@@ -163,13 +199,14 @@ EXPORT_SYMBOL_GPL(fb_deferred_io_fsync);
/*
* Adds a page to the dirty list. Call this from struct
- * vm_operations_struct.page_mkwrite.
+ * vm_operations_struct.page_mkwrite or .pfn_mkwrite.
*/
-static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long offset,
+static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, struct vm_fault *vmf,
struct page *page)
{
struct fb_deferred_io *fbdefio = info->fbdefio;
struct fb_deferred_io_pageref *pageref;
+ unsigned long offset = vmf->pgoff << PAGE_SHIFT;
vm_fault_t ret;
/* protect against the workqueue changing the page list */
@@ -182,20 +219,34 @@ static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long
}
/*
- * We want the page to remain locked from ->page_mkwrite until
- * the PTE is marked dirty to avoid mapping_wrprotect_range()
- * being called before the PTE is updated, which would leave
- * the page ignored by defio.
- * Do this by locking the page here and informing the caller
- * about it with VM_FAULT_LOCKED.
+ * The PTE must be marked writable before the defio deferred work runs
+ * again and potentially marks the PTE write-protected. If the order
+ * should be switched, the PTE would become writable without defio
+ * tracking the page, leaving the page forever ignored by defio.
+ *
+ * For vmalloc() framebuffers, the associated struct page is locked
+ * before releasing the defio lock. mm will later mark the PTE writaable
+ * and release the struct page lock. The struct page lock prevents
+ * the page from being prematurely being marked write-protected.
+ *
+ * For FBINFO_KMEMFB framebuffers, mm assumes there is no struct page,
+ * so the PTE must be marked writable while the defio lock is held.
*/
- lock_page(pageref->page);
+ if (info->flags & FBINFO_KMEMFB) {
+ unsigned long pfn = page_to_pfn(pageref->page);
+
+ ret = vmf_insert_mixed_mkwrite(vmf->vma, vmf->address,
+ __pfn_to_pfn_t(pfn, PFN_SPECIAL));
+ } else {
+ lock_page(pageref->page);
+ ret = VM_FAULT_LOCKED;
+ }
mutex_unlock(&fbdefio->lock);
/* come back after delay to process the deferred IO */
schedule_delayed_work(&info->deferred_work, fbdefio->delay);
- return VM_FAULT_LOCKED;
+ return ret;
err_mutex_unlock:
mutex_unlock(&fbdefio->lock);
@@ -207,10 +258,10 @@ static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long
* @fb_info: The fbdev info structure
* @vmf: The VM fault
*
- * This is a callback we get when userspace first tries to
- * write to the page. We schedule a workqueue. That workqueue
- * will eventually mkclean the touched pages and execute the
- * deferred framebuffer IO. Then if userspace touches a page
+ * This is a callback we get when userspace first tries to write to a
+ * page. We schedule a workqueue. That workqueue will eventually do
+ * mapping_wrprotect_range() on the written pages and execute the
+ * deferred framebuffer IO. Then if userspace writes to a page
* again, we repeat the same scheme.
*
* Returns:
@@ -218,12 +269,11 @@ static vm_fault_t fb_deferred_io_track_page(struct fb_info *info, unsigned long
*/
static vm_fault_t fb_deferred_io_page_mkwrite(struct fb_info *info, struct vm_fault *vmf)
{
- unsigned long offset = vmf->pgoff << PAGE_SHIFT;
struct page *page = vmf->page;
file_update_time(vmf->vma->vm_file);
- return fb_deferred_io_track_page(info, offset, page);
+ return fb_deferred_io_track_page(info, vmf, page);
}
/* vm_ops->page_mkwrite handler */
@@ -234,9 +284,25 @@ static vm_fault_t fb_deferred_io_mkwrite(struct vm_fault *vmf)
return fb_deferred_io_page_mkwrite(info, vmf);
}
+/*
+ * Similar to fb_deferred_io_mkwrite(), but for first writes to pages
+ * in VMAs that have VM_PFNMAP set.
+ */
+static vm_fault_t fb_deferred_io_pfn_mkwrite(struct vm_fault *vmf)
+{
+ struct fb_info *info = vmf->vma->vm_private_data;
+ unsigned long offset = vmf->pgoff << PAGE_SHIFT;
+ struct page *page = phys_to_page(info->fix.smem_start + offset);
+
+ file_update_time(vmf->vma->vm_file);
+
+ return fb_deferred_io_track_page(info, vmf, page);
+}
+
static const struct vm_operations_struct fb_deferred_io_vm_ops = {
.fault = fb_deferred_io_fault,
.page_mkwrite = fb_deferred_io_mkwrite,
+ .pfn_mkwrite = fb_deferred_io_pfn_mkwrite,
};
static const struct address_space_operations fb_deferred_io_aops = {
@@ -246,11 +312,31 @@ static const struct address_space_operations fb_deferred_io_aops = {
int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+ vm_flags_t flags = VM_DONTEXPAND | VM_DONTDUMP;
vma->vm_ops = &fb_deferred_io_vm_ops;
- vm_flags_set(vma, VM_DONTEXPAND | VM_DONTDUMP);
- if (!(info->flags & FBINFO_VIRTFB))
- vm_flags_set(vma, VM_IO);
+ if (info->flags & FBINFO_KMEMFB) {
+ /*
+ * I/O fault path calls vmf_insert_pfn(), which bug checks
+ * if the vma is not marked shared. mmap'ing the framebuffer
+ * as PRIVATE doesn't really make sense anyway, though doing
+ * so isn't harmful for vmalloc() framebuffers. So there's
+ * no prohibition for that case.
+ */
+ if (!(vma->vm_flags & VM_SHARED))
+ return -EINVAL;
+ /*
+ * Set VM_PFNMAP so mm code will not try to manage the pages'
+ * lifecycles. We don't want individual pages to be freed
+ * based on refcount. Instead the memory must be returned to
+ * the free pool in the usual way. Cf. the implementation of
+ * remap_pfn_range() and remap_pfn_range_internal().
+ */
+ flags |= VM_PFNMAP | VM_IO;
+ } else if (!(info->flags & FBINFO_VIRTFB)) {
+ flags |= VM_IO;
+ }
+ vm_flags_set(vma, flags);
vma->vm_private_data = info;
return 0;
}
diff --git a/include/linux/fb.h b/include/linux/fb.h
index cd653862ab99..ea2092757a18 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -402,6 +402,7 @@ struct fb_tile_ops {
/* hints */
#define FBINFO_VIRTFB 0x0004 /* FB is System RAM, not device. */
+#define FBINFO_KMEMFB 0x0008 /* FB is allocated in contig kernel mem */
#define FBINFO_PARTIAL_PAN_OK 0x0040 /* otw use pan only for double-buffering */
#define FBINFO_READS_FAST 0x0080 /* soft-copy faster than rendering */
--
2.25.1
^ permalink raw reply related
* [PATCH 3/3] fbdev: hyperv_fb: Fix mmap of framebuffers allocated using alloc_pages()
From: mhkelley58 @ 2025-04-08 18:36 UTC (permalink / raw)
To: jayalk, simona, deller, haiyangz, kys, wei.liu, decui, akpm
Cc: weh, tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
In-Reply-To: <20250408183646.1410-1-mhklinux@outlook.com>
From: Michael Kelley <mhklinux@outlook.com>
Framebuffer memory allocated using alloc_pages() was added to hyperv_fb in
commit 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb
on HyperV Gen 1 VMs.") in kernel version 5.6. But mmap'ing such
framebuffers into user space has never worked due to limitations in the
kind of memory that fbdev deferred I/O works with. As a result of the
limitation, hyperv_fb's usage results in memory free lists becoming corrupt
and Linux eventually panics.
With support for framebuffers allocated using alloc_pages() recently added
to fbdev deferred I/O, fix the problem by setting the flag telling fbdev
deferred I/O to use the new support.
Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.")
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
---
drivers/video/fbdev/hyperv_fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 75338ffc703f..1698221f857e 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1020,6 +1020,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info)
info->fix.smem_len = screen_fb_size;
info->screen_base = par->mmio_vp;
info->screen_size = screen_fb_size;
+ info->flags |= FBINFO_KMEMFB;
par->need_docopy = false;
goto getmem_done;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 1/3] mm: Export vmf_insert_mixed_mkwrite()
From: Christoph Hellwig @ 2025-04-09 10:49 UTC (permalink / raw)
To: mhklinux
Cc: jayalk, simona, deller, haiyangz, kys, wei.liu, decui, akpm, weh,
tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
In-Reply-To: <20250408183646.1410-2-mhklinux@outlook.com>
On Tue, Apr 08, 2025 at 11:36:44AM -0700, mhkelley58@gmail.com wrote:
> From: Michael Kelley <mhklinux@outlook.com>
>
> Export vmf_insert_mixed_mkwrite() for use by fbdev deferred I/O code,
But they are using this on dma coherent memory, where you can't legally
get at the page. As told last time you need to fix that first before
hacking around that code.
> which can be built as a module. For consistency with the related function
> vmf_insert_mixed(), export without the GPL qualifier.
No. All advanced new Linux functionality must be _GPL. Don't try to
sneak around that.
^ permalink raw reply
* Re: [PATCH 2/3] fbdev/deferred-io: Support contiguous kernel memory framebuffers
From: Christoph Hellwig @ 2025-04-09 10:50 UTC (permalink / raw)
To: mhklinux
Cc: jayalk, simona, deller, haiyangz, kys, wei.liu, decui, akpm, weh,
tzimmermann, hch, dri-devel, linux-fbdev, linux-kernel,
linux-hyperv, linux-mm
In-Reply-To: <20250408183646.1410-3-mhklinux@outlook.com>
On Tue, Apr 08, 2025 at 11:36:45AM -0700, mhkelley58@gmail.com wrote:
> In any case, for x86 and arm64 today, commit 37b4837959cb9 is not
> sufficient to support contiguous kernel memory framebuffers. The problem
> can be seen with the hyperv_fb driver, which may allocate the framebuffer
> memory using vmalloc() or alloc_pages(), depending on the configuration
> of the Hyper-V guest VM (Gen 1 vs. Gen 2) and the size of the framebuffer.
And neither is this code. You need to provide the functionality at
the DMA layer as users must not poke into the returned DMA coherent
memory.
^ permalink raw reply
* RE: [PATCH 1/3] mm: Export vmf_insert_mixed_mkwrite()
From: Michael Kelley @ 2025-04-09 14:10 UTC (permalink / raw)
To: Christoph Hellwig
Cc: jayalk@intworks.biz, simona@ffwll.ch, deller@gmx.de,
haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, akpm@linux-foundation.org, weh@microsoft.com,
tzimmermann@suse.de, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <20250409104942.GA5572@lst.de>
From: Christoph Hellwig <hch@lst.de> Sent: Wednesday, April 9, 2025 3:50 AM
>
> On Tue, Apr 08, 2025 at 11:36:44AM -0700, mhkelley58@gmail.com wrote:
> > From: Michael Kelley <mhklinux@outlook.com>
> >
> > Export vmf_insert_mixed_mkwrite() for use by fbdev deferred I/O code,
>
> But they are using this on dma coherent memory, where you can't legally
> get at the page. As told last time you need to fix that first before
> hacking around that code.
Hmmm. What's the reference to "as told last time"? I don't think I've had
this conversation before.
For the hyperv_fb driver, the memory in question is allocated with a direct call
to alloc_pages(), not via dma_alloc_coherent(). There's no DMA in this scenario.
The memory is shared with the Hyper-V host and designated as the memory
for the virtual framebuffer device. It is then mapped into user space using the
mmap() system call against /dev/fb0. User space writes to the memory are
eventually (and I omit the details) picked up by the Hyper-V host and displayed.
Is your point that memory dma_alloc_coherent() memory must be treated as
a black box, and can't be deconstructed into individual pages? If so, that makes
sense to me. But must the same treatment be applied to memory from
alloc_pages()? This is where I need some education.
>
> > which can be built as a module. For consistency with the related function
> > vmf_insert_mixed(), export without the GPL qualifier.
>
> No. All advanced new Linux functionality must be _GPL. Don't try to
> sneak around that.
No problem. Just trying to be consistent, not sneak around anything.
Thanks,
Michael
^ permalink raw reply
* Re: [PATCH 1/3] mm: Export vmf_insert_mixed_mkwrite()
From: Christoph Hellwig @ 2025-04-10 7:42 UTC (permalink / raw)
To: Michael Kelley
Cc: Christoph Hellwig, jayalk@intworks.biz, simona@ffwll.ch,
deller@gmx.de, haiyangz@microsoft.com, kys@microsoft.com,
wei.liu@kernel.org, decui@microsoft.com,
akpm@linux-foundation.org, weh@microsoft.com, tzimmermann@suse.de,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-mm@kvack.org
In-Reply-To: <BN7PR02MB4148597D0495C631F6E3F8C0D4B42@BN7PR02MB4148.namprd02.prod.outlook.com>
On Wed, Apr 09, 2025 at 02:10:26PM +0000, Michael Kelley wrote:
> Hmmm. What's the reference to "as told last time"? I don't think I've had
> this conversation before.
Hmm, there was a conversation about deferred I/O, and I remember the
drm folks even defending their abuse of vmalloc_to_page on dma coherent
memory against the documentation in the most silly way. Maybe that was
a different discussion of the same thing.
>
> For the hyperv_fb driver, the memory in question is allocated with a direct call
> to alloc_pages(), not via dma_alloc_coherent(). There's no DMA in this scenario.
> The memory is shared with the Hyper-V host and designated as the memory
> for the virtual framebuffer device. It is then mapped into user space using the
> mmap() system call against /dev/fb0. User space writes to the memory are
> eventually (and I omit the details) picked up by the Hyper-V host and displayed.
Oh, great.
> Is your point that memory dma_alloc_coherent() memory must be treated as
> a black box, and can't be deconstructed into individual pages? If so, that makes
> sense to me.
Yes.
> But must the same treatment be applied to memory from
> alloc_pages()? This is where I need some education.
No, that's just fine.
^ permalink raw reply
* Re: [PATCH v4 00/11] backlight, lcd, led: Remove fbdev dependencies
From: Lee Jones @ 2025-04-10 9:39 UTC (permalink / raw)
To: lee, pavel, danielt, jingoohan1, deller, simona,
Thomas Zimmermann
Cc: linux-leds, dri-devel, linux-fbdev
In-Reply-To: <20250321095517.313713-1-tzimmermann@suse.de>
On Fri, 21 Mar 2025 10:53:53 +0100, Thomas Zimmermann wrote:
> This series removes the remaining dependencies on fbdev from the
> backlight, lcd and led subsystems. Each depends on fbdev events to
> track display state. Make fbdev inform each subsystem via a dedicated
> interface instead.
>
> Patches 1 to 3 make fbdev track blank state for each display, so that
> backlight code doesn't have to.
>
> [...]
Applied, thanks!
[01/11] fbdev: Rework fb_blank()
commit: 93e41f968d7c6ea1cedc6b365917cbb787ef08f6
[02/11] fbdev: Track display blanking state
commit: 7e3711eb87c584ed224a7ad7000eba36e6fa3a51
[03/11] fbdev: Send old blank state in FB_EVENT_BLANK
commit: dfb4bf1ac40162ff5ea3715a10f6af2dcf3030c5
[04/11] backlight: Implement fbdev tracking with blank state from event
commit: 726491f2038ec71122d45700f3abf36fdb277aaa
[05/11] backlight: Move blank-state handling into helper
commit: 4bfb77f3381627640e97e0e423c93a2ea93e7de7
[06/11] backlight: Replace fb events with a dedicated function call
commit: b01beb2f1f6bcda17634a5b529865ffc5a9b795f
[07/11] backlight: lcd: Move event handling into helpers
commit: e98696cea7e289447a5d2328546b947629301616
[08/11] backlight: lcd: Replace fb events with a dedicated function call
commit: bc70cc84f5a2ebfd7e7112e9b8837e0c7954fc65
[09/11] leds: backlight trigger: Move blank-state handling into helper
commit: 28f8bab711c0984005a6dd4cc980b4ba8409b817
[10/11] leds: backlight trigger: Replace fb events with a dedicated function call
commit: dc2139c0aa3283e5749109641af1878ed7bf7371
[11/11] fbdev: Remove constants of unused events
commit: d32a0b567a8a8b6e677d35c4f8eb8bd32b7029a0
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v4 00/11] backlight, lcd, led: Remove fbdev dependencies
From: Lee Jones @ 2025-04-10 9:41 UTC (permalink / raw)
To: pavel, danielt, jingoohan1, deller, simona, Thomas Zimmermann
Cc: linux-leds, dri-devel, linux-fbdev
In-Reply-To: <174427796227.1683312.16355490136227829122.b4-ty@kernel.org>
On Thu, 10 Apr 2025, Lee Jones wrote:
> On Fri, 21 Mar 2025 10:53:53 +0100, Thomas Zimmermann wrote:
> > This series removes the remaining dependencies on fbdev from the
> > backlight, lcd and led subsystems. Each depends on fbdev events to
> > track display state. Make fbdev inform each subsystem via a dedicated
> > interface instead.
> >
> > Patches 1 to 3 make fbdev track blank state for each display, so that
> > backlight code doesn't have to.
> >
> > [...]
>
> Applied, thanks!
>
> [01/11] fbdev: Rework fb_blank()
> commit: 93e41f968d7c6ea1cedc6b365917cbb787ef08f6
> [02/11] fbdev: Track display blanking state
> commit: 7e3711eb87c584ed224a7ad7000eba36e6fa3a51
> [03/11] fbdev: Send old blank state in FB_EVENT_BLANK
> commit: dfb4bf1ac40162ff5ea3715a10f6af2dcf3030c5
> [04/11] backlight: Implement fbdev tracking with blank state from event
> commit: 726491f2038ec71122d45700f3abf36fdb277aaa
> [05/11] backlight: Move blank-state handling into helper
> commit: 4bfb77f3381627640e97e0e423c93a2ea93e7de7
> [06/11] backlight: Replace fb events with a dedicated function call
> commit: b01beb2f1f6bcda17634a5b529865ffc5a9b795f
> [07/11] backlight: lcd: Move event handling into helpers
> commit: e98696cea7e289447a5d2328546b947629301616
> [08/11] backlight: lcd: Replace fb events with a dedicated function call
> commit: bc70cc84f5a2ebfd7e7112e9b8837e0c7954fc65
> [09/11] leds: backlight trigger: Move blank-state handling into helper
> commit: 28f8bab711c0984005a6dd4cc980b4ba8409b817
> [10/11] leds: backlight trigger: Replace fb events with a dedicated function call
> commit: dc2139c0aa3283e5749109641af1878ed7bf7371
> [11/11] fbdev: Remove constants of unused events
> commit: d32a0b567a8a8b6e677d35c4f8eb8bd32b7029a0
Okay, these have been submitted for build testing.
Once complete, I'll send out a PR.
Note to self: ib-backlight-leds-fbdev-6.16
--
Lee Jones [李琼斯]
^ permalink raw reply
* [syzbot] Monthly fbdev report (Apr 2025)
From: syzbot @ 2025-04-10 10:47 UTC (permalink / raw)
To: deller, dri-devel, linux-fbdev, linux-kernel, syzkaller-bugs
Hello fbdev maintainers/developers,
This is a 31-day syzbot report for the fbdev subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/fbdev
During the period, 0 new issues were detected and 0 were fixed.
In total, 6 issues are still open and 25 have already been fixed.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 1136 Yes KASAN: vmalloc-out-of-bounds Write in imageblit (4)
https://syzkaller.appspot.com/bug?extid=c4b7aa0513823e2ea880
<2> 42 Yes KASAN: slab-out-of-bounds Read in fbcon_prepare_logo
https://syzkaller.appspot.com/bug?extid=0c815b25cdb3678e7083
<3> 17 Yes KASAN: global-out-of-bounds Read in bit_putcs (3)
https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* RE: [PATCH 1/3] mm: Export vmf_insert_mixed_mkwrite()
From: Michael Kelley @ 2025-04-11 3:40 UTC (permalink / raw)
To: Christoph Hellwig
Cc: jayalk@intworks.biz, simona@ffwll.ch, deller@gmx.de,
haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, akpm@linux-foundation.org, weh@microsoft.com,
tzimmermann@suse.de, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <20250410074228.GA680@lst.de>
From: Christoph Hellwig <hch@lst.de> Sent: Thursday, April 10, 2025 12:42 AM
>
> On Wed, Apr 09, 2025 at 02:10:26PM +0000, Michael Kelley wrote:
> > Hmmm. What's the reference to "as told last time"? I don't think I've had
> > this conversation before.
>
> Hmm, there was a conversation about deferred I/O, and I remember the
> drm folks even defending their abuse of vmalloc_to_page on dma coherent
> memory against the documentation in the most silly way. Maybe that was
> a different discussion of the same thing.
Yes, must have been a different discussion.
Turns out the hyperv_fb driver in a different configuration *is* using
dma_alloc_coherent() to get framebuffer memory, which is then managed
by deferred I/O. dma_alloc_coherent() is used as a wrapper around
cma_alloc() but only when the framebuffer size is > 4 MiB. The deferred
I/O code doesn't do vmalloc_to_page() since the CPU address from
dma_alloc_coherent() isn't a vmalloc addr.
That combo works OK, so wasn't something to be fixed in this patch set.
I'll see about a separate patch to just use cma_alloc() directly for that
case, though cma_alloc() and cma_release() would need to be EXPORTed.
>
> >
> > For the hyperv_fb driver, the memory in question is allocated with a direct call
> > to alloc_pages(), not via dma_alloc_coherent(). There's no DMA in this scenario.
> > The memory is shared with the Hyper-V host and designated as the memory
> > for the virtual framebuffer device. It is then mapped into user space using the
> > mmap() system call against /dev/fb0. User space writes to the memory are
> > eventually (and I omit the details) picked up by the Hyper-V host and displayed.
>
> Oh, great.
>
> > Is your point that memory dma_alloc_coherent() memory must be treated as
> > a black box, and can't be deconstructed into individual pages? If so, that makes
> > sense to me.
>
> Yes.
I'll add some comments to the fbdev deferred I/O code saying not to use it
with a framebuffer allocated with dma_alloc_coherent().
Thanks,
Michael
>
> > But must the same treatment be applied to memory from
> > alloc_pages()? This is where I need some education.
>
> No, that's just fine.
^ permalink raw reply
* [PATCH] backlight: ktd2801: depend on GPIOLIB
From: Duje Mihanović via B4 Relay @ 2025-04-11 17:22 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller
Cc: Randy Dunlap, dri-devel, linux-fbdev, linux-kernel,
Duje Mihanović
From: Duje Mihanović <duje.mihanovic@skole.hr>
The ExpressWire library used by the driver depends on GPIOLIB, and by
extension the driver does as well. This is not reflected in the driver's
Kconfig entry, potentially causing Kconfig warnings. Fix this by adding
the dependency.
Link: https://lore.kernel.org/all/5cf231e1-0bba-4595-9441-46acc5255512@infradead.org
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
---
drivers/video/backlight/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index d9374d208ceebbf8b3c27976e9cb4d725939b942..37341474beb9982f7099711e5e2506081061df46 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -185,6 +185,7 @@ config BACKLIGHT_KTD253
config BACKLIGHT_KTD2801
tristate "Backlight Driver for Kinetic KTD2801"
+ depends on GPIOLIB || COMPILE_TEST
select LEDS_EXPRESSWIRE
help
Say Y to enable the backlight driver for the Kinetic KTD2801 1-wire
---
base-commit: 01c6df60d5d4ae00cd5c1648818744838bba7763
change-id: 20250411-ktd-fix-7a5e5d8657b8
Best regards,
--
Duje Mihanović <duje.mihanovic@skole.hr>
^ permalink raw reply related
* Re: [PATCH] backlight: ktd2801: depend on GPIOLIB
From: Randy Dunlap @ 2025-04-11 21:07 UTC (permalink / raw)
To: duje.mihanovic, Lee Jones, Daniel Thompson, Jingoo Han,
Helge Deller
Cc: dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20250411-ktd-fix-v1-1-e7425d273268@skole.hr>
On 4/11/25 10:22 AM, Duje Mihanović via B4 Relay wrote:
> From: Duje Mihanović <duje.mihanovic@skole.hr>
>
> The ExpressWire library used by the driver depends on GPIOLIB, and by
> extension the driver does as well. This is not reflected in the driver's
> Kconfig entry, potentially causing Kconfig warnings. Fix this by adding
> the dependency.
>
> Link: https://lore.kernel.org/all/5cf231e1-0bba-4595-9441-46acc5255512@infradead.org
s/Link:/Closes:/
> Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>o
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> drivers/video/backlight/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index d9374d208ceebbf8b3c27976e9cb4d725939b942..37341474beb9982f7099711e5e2506081061df46 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -185,6 +185,7 @@ config BACKLIGHT_KTD253
>
> config BACKLIGHT_KTD2801
> tristate "Backlight Driver for Kinetic KTD2801"
> + depends on GPIOLIB || COMPILE_TEST
> select LEDS_EXPRESSWIRE
> help
> Say Y to enable the backlight driver for the Kinetic KTD2801 1-wire
>
> ---
> base-commit: 01c6df60d5d4ae00cd5c1648818744838bba7763
> change-id: 20250411-ktd-fix-7a5e5d8657b8
>
> Best regards,
--
~Randy
^ 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