[PATCH 0/6] [media] omap_vout: Adjustments for three function implementations

[PATCH 0/6] [media] omap_vout: Adjustments for three function implementations

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 12:06:54 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (6):
  Delete an error message for a failed memory allocation in omap_vout_create_video_devices()
  Improve a size determination in two functions
  Adjust a null pointer check in two functions
  Fix a possible null pointer dereference in omap_vout_open()
  Delete an unnecessary variable initialisation in omap_vout_open()
  Delete two unnecessary variable initialisations in omap_vout_probe()

 drivers/media/platform/omap/omap_vout.c | 23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

-- 
2.14.1

[PATCH 0/6] [media] omap_vout: Adjustments for three function implementations

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 12:06:54 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (6):
  Delete an error message for a failed memory allocation in omap_vout_create_video_devices()
  Improve a size determination in two functions
  Adjust a null pointer check in two functions
  Fix a possible null pointer dereference in omap_vout_open()
  Delete an unnecessary variable initialisation in omap_vout_open()
  Delete two unnecessary variable initialisations in omap_vout_probe()

 drivers/media/platform/omap/omap_vout.c | 23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

-- 
2.14.1

[PATCH 1/6] [media] omap_vout: Delete an error message for a failed memory allocation in omap_vout_create_video_devices()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 10:08:22 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index 4d29860d27b4..aebc1e628ac5 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -1948,7 +1948,5 @@ static int __init omap_vout_create_video_devices(struct platform_device *pdev)
-		if (!vout) {
-			dev_err(&pdev->dev, ": could not allocate memory\n");
+		if (!vout)
 			return -ENOMEM;
-		}
 
 		vout->vid = k;
 		vid_dev->vouts[k] = vout;
-- 
2.14.1

[PATCH 1/6] [media] omap_vout: Delete an error message for a failed memory allocation in omap_vout_c

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 10:08:22 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index 4d29860d27b4..aebc1e628ac5 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -1948,7 +1948,5 @@ static int __init omap_vout_create_video_devices(struct platform_device *pdev)
-		if (!vout) {
-			dev_err(&pdev->dev, ": could not allocate memory\n");
+		if (!vout)
 			return -ENOMEM;
-		}
 
 		vout->vid = k;
 		vid_dev->vouts[k] = vout;
-- 
2.14.1

Re: [PATCH 1/6] [media] omap_vout: Delete an error message for a failed memory allocation in omap_vout_create_video_devices()

[Joe Perches]

On Sun, 2017-09-24 at 12:22 +0200, SF Markus Elfring wrote:
> Omit an extra message for a memory allocation failure in this function.
[]
> diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
[]
> @@ -1948,7 +1948,5 @@ static int __init omap_vout_create_video_devices(struct platform_device *pdev)
> -		if (!vout) {
> -			dev_err(&pdev->dev, ": could not allocate memory\n");
> +		if (!vout)
>  			return -ENOMEM;
> -		}
>  
>  		vout->vid = k;
>  		vid_dev->vouts[k] = vout;

Use normal patch styles.
Fix your tools before you send any more patches.

Re: [PATCH 1/6] [media] omap_vout: Delete an error message for a failed memory allocation in omap_vo

[Joe Perches]

On Sun, 2017-09-24 at 12:22 +0200, SF Markus Elfring wrote:
> Omit an extra message for a memory allocation failure in this function.
[]
> diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
[]
> @@ -1948,7 +1948,5 @@ static int __init omap_vout_create_video_devices(struct platform_device *pdev)
> -		if (!vout) {
> -			dev_err(&pdev->dev, ": could not allocate memory\n");
> +		if (!vout)
>  			return -ENOMEM;
> -		}
>  
>  		vout->vid = k;
>  		vid_dev->vouts[k] = vout;

Use normal patch styles.
Fix your tools before you send any more patches.

[PATCH 2/6] [media] omap_vout: Improve a size determination in two functions

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 10:18:26 +0200

Replace the specification of data structures by variable references
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index aebc1e628ac5..4a4d171ca573 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -1943,8 +1943,7 @@ static int __init omap_vout_create_video_devices(struct platform_device *pdev)
 			struct omap2video_device, v4l2_dev);
 
 	for (k = 0; k < pdev->num_resources; k++) {
-
-		vout = kzalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
+		vout = kzalloc(sizeof(*vout), GFP_KERNEL);
 		if (!vout)
 			return -ENOMEM;
 
@@ -2095,7 +2094,7 @@ static int __init omap_vout_probe(struct platform_device *pdev)
 		goto err_dss_init;
 	}
 
-	vid_dev = kzalloc(sizeof(struct omap2video_device), GFP_KERNEL);
+	vid_dev = kzalloc(sizeof(*vid_dev), GFP_KERNEL);
 	if (vid_dev == NULL) {
 		ret = -ENOMEM;
 		goto err_dss_init;
-- 
2.14.1

[PATCH 2/6] [media] omap_vout: Improve a size determination in two functions

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 10:18:26 +0200

Replace the specification of data structures by variable references
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index aebc1e628ac5..4a4d171ca573 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -1943,8 +1943,7 @@ static int __init omap_vout_create_video_devices(struct platform_device *pdev)
 			struct omap2video_device, v4l2_dev);
 
 	for (k = 0; k < pdev->num_resources; k++) {
-
-		vout = kzalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
+		vout = kzalloc(sizeof(*vout), GFP_KERNEL);
 		if (!vout)
 			return -ENOMEM;
 
@@ -2095,7 +2094,7 @@ static int __init omap_vout_probe(struct platform_device *pdev)
 		goto err_dss_init;
 	}
 
-	vid_dev = kzalloc(sizeof(struct omap2video_device), GFP_KERNEL);
+	vid_dev = kzalloc(sizeof(*vid_dev), GFP_KERNEL);
 	if (vid_dev = NULL) {
 		ret = -ENOMEM;
 		goto err_dss_init;
-- 
2.14.1

[PATCH 3/6] [media] omap_vout: Adjust a null pointer check in two functions

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 10:30:29 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script “checkpatch.pl” pointed information out like the following.

Comparison to NULL could be written !…

Thus fix the affected source code places.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index 4a4d171ca573..2b55a8ebd1ad 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -1006,7 +1006,7 @@ static int omap_vout_open(struct file *file)
 	vout = video_drvdata(file);
 	v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, "Entering %s\n", __func__);
 
-	if (vout == NULL)
+	if (!vout)
 		return -ENODEV;
 
 	/* for now, we only support single open */
@@ -2095,7 +2095,7 @@ static int __init omap_vout_probe(struct platform_device *pdev)
 	}
 
 	vid_dev = kzalloc(sizeof(*vid_dev), GFP_KERNEL);
-	if (vid_dev == NULL) {
+	if (!vid_dev) {
 		ret = -ENOMEM;
 		goto err_dss_init;
 	}
-- 
2.14.1

[PATCH 3/6] [media] omap_vout: Adjust a null pointer check in two functions

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 10:30:29 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script “checkpatch.pl” pointed information out like the following.

Comparison to NULL could be written !…

Thus fix the affected source code places.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index 4a4d171ca573..2b55a8ebd1ad 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -1006,7 +1006,7 @@ static int omap_vout_open(struct file *file)
 	vout = video_drvdata(file);
 	v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, "Entering %s\n", __func__);
 
-	if (vout = NULL)
+	if (!vout)
 		return -ENODEV;
 
 	/* for now, we only support single open */
@@ -2095,7 +2095,7 @@ static int __init omap_vout_probe(struct platform_device *pdev)
 	}
 
 	vid_dev = kzalloc(sizeof(*vid_dev), GFP_KERNEL);
-	if (vid_dev = NULL) {
+	if (!vid_dev) {
 		ret = -ENOMEM;
 		goto err_dss_init;
 	}
-- 
2.14.1

[PATCH 4/6] [media] omap_vout: Fix a possible null pointer dereference in omap_vout_open()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 11:00:57 +0200

Move a debug message so that a null pointer access can not happen
for the variable "vout" in this function.

Fixes: 5c7ab6348e7b3fcca2b8ee548306c774472971e2 ("V4L/DVB: V4L2: Add support for OMAP2/3 V4L2 display driver on top of DSS2")

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index 2b55a8ebd1ad..71b77426271e 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -1004,11 +1004,11 @@ static int omap_vout_open(struct file *file)
 	struct omap_vout_device *vout = NULL;
 
 	vout = video_drvdata(file);
-	v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, "Entering %s\n", __func__);
-
 	if (!vout)
 		return -ENODEV;
 
+	v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, "Entering %s\n", __func__);
+
 	/* for now, we only support single open */
 	if (vout->opened)
 		return -EBUSY;
-- 
2.14.1

[PATCH 4/6] [media] omap_vout: Fix a possible null pointer dereference in omap_vout_open()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 11:00:57 +0200

Move a debug message so that a null pointer access can not happen
for the variable "vout" in this function.

Fixes: 5c7ab6348e7b3fcca2b8ee548306c774472971e2 ("V4L/DVB: V4L2: Add support for OMAP2/3 V4L2 display driver on top of DSS2")

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index 2b55a8ebd1ad..71b77426271e 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -1004,11 +1004,11 @@ static int omap_vout_open(struct file *file)
 	struct omap_vout_device *vout = NULL;
 
 	vout = video_drvdata(file);
-	v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, "Entering %s\n", __func__);
-
 	if (!vout)
 		return -ENODEV;
 
+	v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, "Entering %s\n", __func__);
+
 	/* for now, we only support single open */
 	if (vout->opened)
 		return -EBUSY;
-- 
2.14.1

[PATCH 5/6] [media] omap_vout: Delete an unnecessary variable initialisation in omap_vout_open()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 11:20:11 +0200

The local variable "vout" is reassigned by a statement at the beginning.
Thus omit the explicit initialisation.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index 71b77426271e..f446a37064f4 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -1001,7 +1001,7 @@ static int omap_vout_release(struct file *file)
 static int omap_vout_open(struct file *file)
 {
 	struct videobuf_queue *q;
-	struct omap_vout_device *vout = NULL;
+	struct omap_vout_device *vout;
 
 	vout = video_drvdata(file);
 	if (!vout)
-- 
2.14.1

[PATCH 5/6] [media] omap_vout: Delete an unnecessary variable initialisation in omap_vout_open()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 11:20:11 +0200

The local variable "vout" is reassigned by a statement at the beginning.
Thus omit the explicit initialisation.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index 71b77426271e..f446a37064f4 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -1001,7 +1001,7 @@ static int omap_vout_release(struct file *file)
 static int omap_vout_open(struct file *file)
 {
 	struct videobuf_queue *q;
-	struct omap_vout_device *vout = NULL;
+	struct omap_vout_device *vout;
 
 	vout = video_drvdata(file);
 	if (!vout)
-- 
2.14.1

[PATCH 6/6] [media] omap_vout: Delete two unnecessary variable initialisations in omap_vout_probe()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 11:33:39 +0200

The variables "dssdev" and "vid_dev" will eventually be set
to appropriate pointers a bit later.
Thus omit the explicit initialisations at the beginning.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index f446a37064f4..0efcea820007 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -2075,9 +2075,9 @@ static int __init omap_vout_probe(struct platform_device *pdev)
 {
 	int ret = 0, i;
 	struct omap_overlay *ovl;
-	struct omap_dss_device *dssdev = NULL;
+	struct omap_dss_device *dssdev;
 	struct omap_dss_device *def_display;
-	struct omap2video_device *vid_dev = NULL;
+	struct omap2video_device *vid_dev;
 
 	if (omapdss_is_initialized() == false)
 		return -EPROBE_DEFER;
-- 
2.14.1

[PATCH 6/6] [media] omap_vout: Delete two unnecessary variable initialisations in omap_vout_probe()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 24 Sep 2017 11:33:39 +0200

The variables "dssdev" and "vid_dev" will eventually be set
to appropriate pointers a bit later.
Thus omit the explicit initialisations at the beginning.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/media/platform/omap/omap_vout.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
index f446a37064f4..0efcea820007 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -2075,9 +2075,9 @@ static int __init omap_vout_probe(struct platform_device *pdev)
 {
 	int ret = 0, i;
 	struct omap_overlay *ovl;
-	struct omap_dss_device *dssdev = NULL;
+	struct omap_dss_device *dssdev;
 	struct omap_dss_device *def_display;
-	struct omap2video_device *vid_dev = NULL;
+	struct omap2video_device *vid_dev;
 
 	if (omapdss_is_initialized() = false)
 		return -EPROBE_DEFER;
-- 
2.14.1

Re: [PATCH 0/6] [media] omap_vout: Adjustments for three function implementations

[Hans Verkuil]

Hi Markus,

On 09/24/2017 12:20 PM, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 24 Sep 2017 12:06:54 +0200
> 
> A few update suggestions were taken into account
> from static source code analysis.
> 
> Markus Elfring (6):
>   Delete an error message for a failed memory allocation in omap_vout_create_video_devices()
>   Improve a size determination in two functions
>   Adjust a null pointer check in two functions
>   Fix a possible null pointer dereference in omap_vout_open()
>   Delete an unnecessary variable initialisation in omap_vout_open()
>   Delete two unnecessary variable initialisations in omap_vout_probe()
> 
>  drivers/media/platform/omap/omap_vout.c | 23 ++++++++++-------------
>  1 file changed, 10 insertions(+), 13 deletions(-)
> 

While we do not mind cleanup patches, the way you post them (one fix per file) is really
annoying and takes us too much time to review.

I'll take the "Fix a possible null pointer" patch since it is an actual bug fix, but
will reject the others, not just this driver but all of them that are currently pending
in our patchwork (https://patchwork.linuxtv.org).

Feel free to repost, but only if you organize the patch as either fixing the same type of
issue for a whole subdirectory (media/usb, media/pci, etc) or fixing all issues for a
single driver.

Actual bug fixes (like the null pointer patch in this series) can still be posted as
separate patches, but cleanups shouldn't.

So in this particular case I would expect two omap_vout patches: one for the bug fix,
one for the cleanups.

Just so you know, I'll reject any future patch series that do not follow these rules.
Just use common sense when posting these things in the future.

I would also suggest that your time might be spent more productively if you would
work on some more useful projects. There is more than enough to do. However, that's
up to you.

Regards,

	Hans

Re: [PATCH 0/6] [media] omap_vout: Adjustments for three function implementations

[Hans Verkuil]

Hi Markus,

On 09/24/2017 12:20 PM, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 24 Sep 2017 12:06:54 +0200
> 
> A few update suggestions were taken into account
> from static source code analysis.
> 
> Markus Elfring (6):
>   Delete an error message for a failed memory allocation in omap_vout_create_video_devices()
>   Improve a size determination in two functions
>   Adjust a null pointer check in two functions
>   Fix a possible null pointer dereference in omap_vout_open()
>   Delete an unnecessary variable initialisation in omap_vout_open()
>   Delete two unnecessary variable initialisations in omap_vout_probe()
> 
>  drivers/media/platform/omap/omap_vout.c | 23 ++++++++++-------------
>  1 file changed, 10 insertions(+), 13 deletions(-)
> 

While we do not mind cleanup patches, the way you post them (one fix per file) is really
annoying and takes us too much time to review.

I'll take the "Fix a possible null pointer" patch since it is an actual bug fix, but
will reject the others, not just this driver but all of them that are currently pending
in our patchwork (https://patchwork.linuxtv.org).

Feel free to repost, but only if you organize the patch as either fixing the same type of
issue for a whole subdirectory (media/usb, media/pci, etc) or fixing all issues for a
single driver.

Actual bug fixes (like the null pointer patch in this series) can still be posted as
separate patches, but cleanups shouldn't.

So in this particular case I would expect two omap_vout patches: one for the bug fix,
one for the cleanups.

Just so you know, I'll reject any future patch series that do not follow these rules.
Just use common sense when posting these things in the future.

I would also suggest that your time might be spent more productively if you would
work on some more useful projects. There is more than enough to do. However, that's
up to you.

Regards,

	Hans

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> While we do not mind cleanup patches, the way you post them (one fix per file)

I find it safer in this way  while I was browsing through the landscape of Linux
software components.


> is really annoying and takes us too much time to review.

It is just the case that there are so many remaining open issues.


> I'll take the "Fix a possible null pointer" patch since it is an actual bug fix,

Thanks for a bit of change acceptance.


> but will reject the others, not just this driver but all of them that are currently
> pending in our patchwork (https://patchwork.linuxtv.org).

Will any chances evolve to integrate 146 patches in any other combination?


> Feel free to repost, but only if you organize the patch as either fixing the same type of
> issue for a whole subdirectory (media/usb, media/pci, etc)

Can we achieve an agreement on the shown change patterns?

Is a consensus possible for involved update candidates?


> or fixing all issues for a single driver.

I find that I did this already.


> Actual bug fixes (like the null pointer patch in this series) can still be posted as
> separate patches, but cleanups shouldn't.

I got an other software development opinion.


> Just so you know, I'll reject any future patch series that do not follow these rules.
> Just use common sense when posting these things in the future.

Do we need to try any additional communication tools out?


> I would also suggest that your time might be spent more productively if you would
> work on some more useful projects.

I hope that various change possibilities (from my selection) will become useful
for more Linux users.
How will the clarification evolve further?


Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> While we do not mind cleanup patches, the way you post them (one fix per file)

I find it safer in this way  while I was browsing through the landscape of Linux
software components.


> is really annoying and takes us too much time to review.

It is just the case that there are so many remaining open issues.


> I'll take the "Fix a possible null pointer" patch since it is an actual bug fix,

Thanks for a bit of change acceptance.


> but will reject the others, not just this driver but all of them that are currently
> pending in our patchwork (https://patchwork.linuxtv.org).

Will any chances evolve to integrate 146 patches in any other combination?


> Feel free to repost, but only if you organize the patch as either fixing the same type of
> issue for a whole subdirectory (media/usb, media/pci, etc)

Can we achieve an agreement on the shown change patterns?

Is a consensus possible for involved update candidates?


> or fixing all issues for a single driver.

I find that I did this already.


> Actual bug fixes (like the null pointer patch in this series) can still be posted as
> separate patches, but cleanups shouldn't.

I got an other software development opinion.


> Just so you know, I'll reject any future patch series that do not follow these rules.
> Just use common sense when posting these things in the future.

Do we need to try any additional communication tools out?


> I would also suggest that your time might be spent more productively if you would
> work on some more useful projects.

I hope that various change possibilities (from my selection) will become useful
for more Linux users.
How will the clarification evolve further?


Regards,
Markus

Re: Adjustments for a lot of function implementations

[Julia Lawall]

On Mon, 30 Oct 2017, SF Markus Elfring wrote:

> > While we do not mind cleanup patches, the way you post them (one fix per file)
>
> I find it safer in this way  while I was browsing through the landscape of Linux
> software components.
>
>
> > is really annoying and takes us too much time to review.
>
> It is just the case that there are so many remaining open issues.
>
>
> > I'll take the "Fix a possible null pointer" patch since it is an actual bug fix,
>
> Thanks for a bit of change acceptance.
>
>
> > but will reject the others, not just this driver but all of them that are currently
> > pending in our patchwork (https://patchwork.linuxtv.org).
>
> Will any chances evolve to integrate 146 patches in any other combination?
>
>
> > Feel free to repost, but only if you organize the patch as either fixing the same type of
> > issue for a whole subdirectory (media/usb, media/pci, etc)

Just for the record, while this may work for media, it won't work for all
subsystems.  One will quickly get a complaint that the big patch needs to
go into multiple trees.

julia

>
> Can we achieve an agreement on the shown change patterns?
>
> Is a consensus possible for involved update candidates?
>
>
> > or fixing all issues for a single driver.
>
> I find that I did this already.
>
>
> > Actual bug fixes (like the null pointer patch in this series) can still be posted as
> > separate patches, but cleanups shouldn't.
>
> I got an other software development opinion.
>
>
> > Just so you know, I'll reject any future patch series that do not follow these rules.
> > Just use common sense when posting these things in the future.
>
> Do we need to try any additional communication tools out?
>
>
> > I would also suggest that your time might be spent more productively if you would
> > work on some more useful projects.
>
> I hope that various change possibilities (from my selection) will become useful
> for more Linux users.
> How will the clarification evolve further?
>
>
> Regards,
> Markus
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Adjustments for a lot of function implementations

[Julia Lawall]

On Mon, 30 Oct 2017, SF Markus Elfring wrote:

> > While we do not mind cleanup patches, the way you post them (one fix per file)
>
> I find it safer in this way  while I was browsing through the landscape of Linux
> software components.
>
>
> > is really annoying and takes us too much time to review.
>
> It is just the case that there are so many remaining open issues.
>
>
> > I'll take the "Fix a possible null pointer" patch since it is an actual bug fix,
>
> Thanks for a bit of change acceptance.
>
>
> > but will reject the others, not just this driver but all of them that are currently
> > pending in our patchwork (https://patchwork.linuxtv.org).
>
> Will any chances evolve to integrate 146 patches in any other combination?
>
>
> > Feel free to repost, but only if you organize the patch as either fixing the same type of
> > issue for a whole subdirectory (media/usb, media/pci, etc)

Just for the record, while this may work for media, it won't work for all
subsystems.  One will quickly get a complaint that the big patch needs to
go into multiple trees.

julia

>
> Can we achieve an agreement on the shown change patterns?
>
> Is a consensus possible for involved update candidates?
>
>
> > or fixing all issues for a single driver.
>
> I find that I did this already.
>
>
> > Actual bug fixes (like the null pointer patch in this series) can still be posted as
> > separate patches, but cleanups shouldn't.
>
> I got an other software development opinion.
>
>
> > Just so you know, I'll reject any future patch series that do not follow these rules.
> > Just use common sense when posting these things in the future.
>
> Do we need to try any additional communication tools out?
>
>
> > I would also suggest that your time might be spent more productively if you would
> > work on some more useful projects.
>
> I hope that various change possibilities (from my selection) will become useful
> for more Linux users.
> How will the clarification evolve further?
>
>
> Regards,
> Markus
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Adjustments for a lot of function implementations

[Hans Verkuil]

On 10/30/2017 10:47 AM, Julia Lawall wrote:
> 
> 
> On Mon, 30 Oct 2017, SF Markus Elfring wrote:
> 
>>> While we do not mind cleanup patches, the way you post them (one fix per file)
>>
>> I find it safer in this way  while I was browsing through the landscape of Linux
>> software components.
>>
>>
>>> is really annoying and takes us too much time to review.
>>
>> It is just the case that there are so many remaining open issues.
>>
>>
>>> I'll take the "Fix a possible null pointer" patch since it is an actual bug fix,
>>
>> Thanks for a bit of change acceptance.
>>
>>
>>> but will reject the others, not just this driver but all of them that are currently
>>> pending in our patchwork (https://patchwork.linuxtv.org).
>>
>> Will any chances evolve to integrate 146 patches in any other combination?
>>
>>
>>> Feel free to repost, but only if you organize the patch as either fixing the same type of
>>> issue for a whole subdirectory (media/usb, media/pci, etc)
> 
> Just for the record, while this may work for media, it won't work for all
> subsystems.  One will quickly get a complaint that the big patch needs to
> go into multiple trees.

For the record: this only applies to drivers/media. We discussed what do to with series
like this during our media summit last Friday and this was the conclusion of that.
Obviously I can't talk about other subsystems.

Regards,

	Hans

> 
> julia
> 
>>
>> Can we achieve an agreement on the shown change patterns?
>>
>> Is a consensus possible for involved update candidates?
>>
>>
>>> or fixing all issues for a single driver.
>>
>> I find that I did this already.
>>
>>
>>> Actual bug fixes (like the null pointer patch in this series) can still be posted as
>>> separate patches, but cleanups shouldn't.
>>
>> I got an other software development opinion.
>>
>>
>>> Just so you know, I'll reject any future patch series that do not follow these rules.
>>> Just use common sense when posting these things in the future.
>>
>> Do we need to try any additional communication tools out?
>>
>>
>>> I would also suggest that your time might be spent more productively if you would
>>> work on some more useful projects.
>>
>> I hope that various change possibilities (from my selection) will become useful
>> for more Linux users.
>> How will the clarification evolve further?
>>
>>
>> Regards,
>> Markus
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: Adjustments for a lot of function implementations

[Hans Verkuil]

On 10/30/2017 10:47 AM, Julia Lawall wrote:
> 
> 
> On Mon, 30 Oct 2017, SF Markus Elfring wrote:
> 
>>> While we do not mind cleanup patches, the way you post them (one fix per file)
>>
>> I find it safer in this way  while I was browsing through the landscape of Linux
>> software components.
>>
>>
>>> is really annoying and takes us too much time to review.
>>
>> It is just the case that there are so many remaining open issues.
>>
>>
>>> I'll take the "Fix a possible null pointer" patch since it is an actual bug fix,
>>
>> Thanks for a bit of change acceptance.
>>
>>
>>> but will reject the others, not just this driver but all of them that are currently
>>> pending in our patchwork (https://patchwork.linuxtv.org).
>>
>> Will any chances evolve to integrate 146 patches in any other combination?
>>
>>
>>> Feel free to repost, but only if you organize the patch as either fixing the same type of
>>> issue for a whole subdirectory (media/usb, media/pci, etc)
> 
> Just for the record, while this may work for media, it won't work for all
> subsystems.  One will quickly get a complaint that the big patch needs to
> go into multiple trees.

For the record: this only applies to drivers/media. We discussed what do to with series
like this during our media summit last Friday and this was the conclusion of that.
Obviously I can't talk about other subsystems.

Regards,

	Hans

> 
> julia
> 
>>
>> Can we achieve an agreement on the shown change patterns?
>>
>> Is a consensus possible for involved update candidates?
>>
>>
>>> or fixing all issues for a single driver.
>>
>> I find that I did this already.
>>
>>
>>> Actual bug fixes (like the null pointer patch in this series) can still be posted as
>>> separate patches, but cleanups shouldn't.
>>
>> I got an other software development opinion.
>>
>>
>>> Just so you know, I'll reject any future patch series that do not follow these rules.
>>> Just use common sense when posting these things in the future.
>>
>> Do we need to try any additional communication tools out?
>>
>>
>>> I would also suggest that your time might be spent more productively if you would
>>> work on some more useful projects.
>>
>> I hope that various change possibilities (from my selection) will become useful
>> for more Linux users.
>> How will the clarification evolve further?
>>
>>
>> Regards,
>> Markus
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

>>>> Feel free to repost, but only if you organize the patch as either fixing the same type of
>>>> issue for a whole subdirectory (media/usb, media/pci, etc)
>>
>> Just for the record, while this may work for media, it won't work for all
>> subsystems.  One will quickly get a complaint that the big patch needs to
>> go into multiple trees.
> 
> For the record: this only applies to drivers/media.

Interesting …


> We discussed what do to with series like this during our media summit last Friday

Would you like to share any more information from this meeting?


> and this was the conclusion of that.

I would appreciate further indications for a corresponding change acceptance.

I found a feedback by Mauro Carvalho Chehab more constructive.

[GIT,PULL,FOR,v4.15] Cleanup fixes
https://patchwork.linuxtv.org/patch/43957/

“…
This time, I was nice and I took some time doing:

	$ quilt fold < `quilt next` && quilt delete `quilt next`
…”


Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

>>>> Feel free to repost, but only if you organize the patch as either fixing the same type of
>>>> issue for a whole subdirectory (media/usb, media/pci, etc)
>>
>> Just for the record, while this may work for media, it won't work for all
>> subsystems.  One will quickly get a complaint that the big patch needs to
>> go into multiple trees.
> 
> For the record: this only applies to drivers/media.

Interesting …


> We discussed what do to with series like this during our media summit last Friday

Would you like to share any more information from this meeting?


> and this was the conclusion of that.

I would appreciate further indications for a corresponding change acceptance.

I found a feedback by Mauro Carvalho Chehab more constructive.

[GIT,PULL,FOR,v4.15] Cleanup fixes
https://patchwork.linuxtv.org/patch/43957/

“…
This time, I was nice and I took some time doing:

	$ quilt fold < `quilt next` && quilt delete `quilt next`
…”


Regards,
Markus

Re: Adjustments for a lot of function implementations

[Hans Verkuil]

On 10/30/2017 11:40 AM, SF Markus Elfring wrote:
>>>>> Feel free to repost, but only if you organize the patch as either fixing the same type of
>>>>> issue for a whole subdirectory (media/usb, media/pci, etc)
>>>
>>> Just for the record, while this may work for media, it won't work for all
>>> subsystems.  One will quickly get a complaint that the big patch needs to
>>> go into multiple trees.
>>
>> For the record: this only applies to drivers/media.
> 
> Interesting …
> 
> 
>> We discussed what do to with series like this during our media summit last Friday
> 
> Would you like to share any more information from this meeting?

??? I did that: either one patch per directory with the same type of change,
or one patch per driver combining all the changes for that driver.

> 
> 
>> and this was the conclusion of that.
> 
> I would appreciate further indications for a corresponding change acceptance.
> 
> I found a feedback by Mauro Carvalho Chehab more constructive.
> 
> [GIT,PULL,FOR,v4.15] Cleanup fixes
> https://patchwork.linuxtv.org/patch/43957/
> 
> “…
> This time, I was nice and I took some time doing:
> 
> 	$ quilt fold < `quilt next` && quilt delete `quilt next`
> …”

Yes, and you were told not to do it like that again.

Regards,

	Hans

Re: Adjustments for a lot of function implementations

[Hans Verkuil]

On 10/30/2017 11:40 AM, SF Markus Elfring wrote:
>>>>> Feel free to repost, but only if you organize the patch as either fixing the same type of
>>>>> issue for a whole subdirectory (media/usb, media/pci, etc)
>>>
>>> Just for the record, while this may work for media, it won't work for all
>>> subsystems.  One will quickly get a complaint that the big patch needs to
>>> go into multiple trees.
>>
>> For the record: this only applies to drivers/media.
> 
> Interesting …
> 
> 
>> We discussed what do to with series like this during our media summit last Friday
> 
> Would you like to share any more information from this meeting?

??? I did that: either one patch per directory with the same type of change,
or one patch per driver combining all the changes for that driver.

> 
> 
>> and this was the conclusion of that.
> 
> I would appreciate further indications for a corresponding change acceptance.
> 
> I found a feedback by Mauro Carvalho Chehab more constructive.
> 
> [GIT,PULL,FOR,v4.15] Cleanup fixes
> https://patchwork.linuxtv.org/patch/43957/
> 
> “…
> This time, I was nice and I took some time doing:
> 
> 	$ quilt fold < `quilt next` && quilt delete `quilt next`
> …”

Yes, and you were told not to do it like that again.

Regards,

	Hans

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> Yes, and you were told not to do it

I have got an other impression.


> like that again.

I continued with the presentation of suggestions from my selection
of change possibilities.
It seems that there are very different expectations for the
preferred patch granularity.

Can it happen again that you are going to use a development tool
like “quilt” (as a maintainer) for the desired recombination
of possible update steps?

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> Yes, and you were told not to do it

I have got an other impression.


> like that again.

I continued with the presentation of suggestions from my selection
of change possibilities.
It seems that there are very different expectations for the
preferred patch granularity.

Can it happen again that you are going to use a development tool
like “quilt” (as a maintainer) for the desired recombination
of possible update steps?

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> ??? I did that: either one patch per directory with the same type of change,
> or one patch per driver combining all the changes for that driver.

Would you like to answer my still remaining questions in any more
constructive ways?

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> ??? I did that: either one patch per directory with the same type of change,
> or one patch per driver combining all the changes for that driver.

Would you like to answer my still remaining questions in any more
constructive ways?

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> ??? I did that: either one patch per directory with the same type of change,
> or one patch per driver combining all the changes for that driver.

Are you going to answer any of my remaining questions in a more constructive way?

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> ??? I did that: either one patch per directory with the same type of change,
> or one patch per driver combining all the changes for that driver.

Are you going to answer any of my remaining questions in a more constructive way?

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> ??? I did that: either one patch per directory with the same type of change,
> or one patch per driver combining all the changes for that driver.

Do any contributors get into the mood to take another look at software updates
from my selection of change possibilities in a more constructive way?

Do you need any additional development resources?

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> ??? I did that: either one patch per directory with the same type of change,
> or one patch per driver combining all the changes for that driver.

Do any contributors get into the mood to take another look at software updates
from my selection of change possibilities in a more constructive way?

Do you need any additional development resources?

Regards,
Markus

Re: Adjustments for a lot of function implementations

[Hans Verkuil]

On 02/02/18 10:55, SF Markus Elfring wrote:
>> ??? I did that: either one patch per directory with the same type of change,
>> or one patch per driver combining all the changes for that driver.
> 
> Do any contributors get into the mood to take another look at software updates
> from my selection of change possibilities in a more constructive way?
> 
> Do you need any additional development resources?

One last time: either post per-driver patches with all the cleanups for a driver
in a single patch, or a per-directory patch (drivers/media/pci, usb, etc) doing
the same cleanup for all drivers in that directory.

I prefer the first approach, but it's up to you.

We don't have the time to wade through dozens of one-liner cleanup patches.

I don't understand what is so difficult about this.

Regards,

	Hans

Re: Adjustments for a lot of function implementations

[Hans Verkuil]

On 02/02/18 10:55, SF Markus Elfring wrote:
>> ??? I did that: either one patch per directory with the same type of change,
>> or one patch per driver combining all the changes for that driver.
> 
> Do any contributors get into the mood to take another look at software updates
> from my selection of change possibilities in a more constructive way?
> 
> Do you need any additional development resources?

One last time: either post per-driver patches with all the cleanups for a driver
in a single patch, or a per-directory patch (drivers/media/pci, usb, etc) doing
the same cleanup for all drivers in that directory.

I prefer the first approach, but it's up to you.

We don't have the time to wade through dozens of one-liner cleanup patches.

I don't understand what is so difficult about this.

Regards,

	Hans

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> One last time: either post per-driver patches with all the cleanups for a driver
> in a single patch,

I preferred to offer source code adjustments according to specific transformation
patterns mostly for each software module separately (also in small patch series).


> or a per-directory patch (drivers/media/pci, usb, etc) doing the same cleanup
> for all drivers in that directory.

I am curious if bigger patch packages would be easier to get accepted.

Or would you get frightened still by any other change combination?



> I prefer the first approach,

We have got different preferences for a safe patch granularity.


> but it's up to you.

I imagine that there are more development factors involved.


> We don't have the time to wade through dozens of one-liner cleanup patches.

It is usual that integration of update suggestions will take some time.
How would the situation change if I would dare to regroup possible update steps?


> I don't understand what is so difficult about this.

There are communication difficulties to consider since your terse information
from your conference meeting.

If you would insist on patch squashing, would you dare to use a development tool
like “quilt fold” also on your own once more?

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> One last time: either post per-driver patches with all the cleanups for a driver
> in a single patch,

I preferred to offer source code adjustments according to specific transformation
patterns mostly for each software module separately (also in small patch series).


> or a per-directory patch (drivers/media/pci, usb, etc) doing the same cleanup
> for all drivers in that directory.

I am curious if bigger patch packages would be easier to get accepted.

Or would you get frightened still by any other change combination?



> I prefer the first approach,

We have got different preferences for a safe patch granularity.


> but it's up to you.

I imagine that there are more development factors involved.


> We don't have the time to wade through dozens of one-liner cleanup patches.

It is usual that integration of update suggestions will take some time.
How would the situation change if I would dare to regroup possible update steps?


> I don't understand what is so difficult about this.

There are communication difficulties to consider since your terse information
from your conference meeting.

If you would insist on patch squashing, would you dare to use a development tool
like “quilt fold” also on your own once more?

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

>> Do any contributors get into the mood to take another look at software updates
>> from my selection of change possibilities in a more constructive way?
>>
>> Do you need any additional development resources?
> 
> One last time: either post per-driver patches with all the cleanups for a driver
> in a single patch,

I find such a change combination unsafe.


> or a per-directory patch (drivers/media/pci, usb, etc) doing the same cleanup
> for all drivers in that directory.

Would you dare to apply any (of my) scripts for the semantic patch language
directly on the whole directory for multi-media software?


> I prefer the first approach, but it's up to you.

Can you handle bigger patches really better than similar patch series?


> We don't have the time to wade through dozens of one-liner cleanup patches.

Are there any further possibilities to consider around consequences
from a general change resistance?

Will any development (or management) tools like “quilt fold” make the regrouping
of possible update steps more convenient and safer? 

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

>> Do any contributors get into the mood to take another look at software updates
>> from my selection of change possibilities in a more constructive way?
>>
>> Do you need any additional development resources?
> 
> One last time: either post per-driver patches with all the cleanups for a driver
> in a single patch,

I find such a change combination unsafe.


> or a per-directory patch (drivers/media/pci, usb, etc) doing the same cleanup
> for all drivers in that directory.

Would you dare to apply any (of my) scripts for the semantic patch language
directly on the whole directory for multi-media software?


> I prefer the first approach, but it's up to you.

Can you handle bigger patches really better than similar patch series?


> We don't have the time to wade through dozens of one-liner cleanup patches.

Are there any further possibilities to consider around consequences
from a general change resistance?

Will any development (or management) tools like “quilt fold” make the regrouping
of possible update steps more convenient and safer? 

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

>>>> but will reject the others, not just this driver but all of them
>>>> that are currently pending in our patchwork (https://patchwork.linuxtv.org).

I find it very surprising that you rejected 146 useful update suggestions
so easily.


>>>> Feel free to repost, but only if you organize the patch as either fixing
>>>> the same type of issue for a whole subdirectory (media/usb, media/pci, etc)
>>
>> Just for the record, while this may work for media, it won't work for all
>> subsystems.  One will quickly get a complaint that the big patch needs to
>> go into multiple trees.
> 
> For the record: this only applies to drivers/media.

What does this software area make it so special in comparison to
other Linux subsystems?


> We discussed what do to with series like this during our media summit
> last Friday and this was the conclusion of that.

* Have you taken any other solution approaches into account than
  a quick “rejection”?

* Could your reaction have been different if the remarkable number of
  change possibilities were sent by different authors (and not only me)?

* How should possibly remaining disagreements about affected implementation
  details be resolved now?

* Are you looking for further improvements around development tools
  like “patchwork” and “quilt”?

* Will you accept increasing risks because of bigger patch sizes?


>>>> or fixing all issues for a single driver.
>>>
>>> I find that I did this already.

* Can such an information lead to differences in the preferred patch granularity?

* How do you think about this detail?


>>>> Actual bug fixes (like the null pointer patch in this series) can still be posted as
>>>> separate patches, but cleanups shouldn't.
>>>
>>> I got an other software development opinion.

How would you ever like to clean up stuff in affected source files
which was accumulated (or preserved somehow) over years?


>>>> Just so you know, I'll reject any future patch series that do not follow these rules.

I guess that this handling will trigger more communication challenges.


>>>> Just use common sense when posting these things in the future.

Our “common sense” seems to be occasionally different in significant ways.


>>>> I would also suggest that your time might be spent more productively
>>>> if you would work on some more useful projects.

I distribute my software development capacity over several areas.
Does your wording indicate a questionable signal for further contributions?

Regards,
Markus

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

>>>> but will reject the others, not just this driver but all of them
>>>> that are currently pending in our patchwork (https://patchwork.linuxtv.org).

I find it very surprising that you rejected 146 useful update suggestions
so easily.


>>>> Feel free to repost, but only if you organize the patch as either fixing
>>>> the same type of issue for a whole subdirectory (media/usb, media/pci, etc)
>>
>> Just for the record, while this may work for media, it won't work for all
>> subsystems.  One will quickly get a complaint that the big patch needs to
>> go into multiple trees.
> 
> For the record: this only applies to drivers/media.

What does this software area make it so special in comparison to
other Linux subsystems?


> We discussed what do to with series like this during our media summit
> last Friday and this was the conclusion of that.

* Have you taken any other solution approaches into account than
  a quick “rejection”?

* Could your reaction have been different if the remarkable number of
  change possibilities were sent by different authors (and not only me)?

* How should possibly remaining disagreements about affected implementation
  details be resolved now?

* Are you looking for further improvements around development tools
  like “patchwork” and “quilt”?

* Will you accept increasing risks because of bigger patch sizes?


>>>> or fixing all issues for a single driver.
>>>
>>> I find that I did this already.

* Can such an information lead to differences in the preferred patch granularity?

* How do you think about this detail?


>>>> Actual bug fixes (like the null pointer patch in this series) can still be posted as
>>>> separate patches, but cleanups shouldn't.
>>>
>>> I got an other software development opinion.

How would you ever like to clean up stuff in affected source files
which was accumulated (or preserved somehow) over years?


>>>> Just so you know, I'll reject any future patch series that do not follow these rules.

I guess that this handling will trigger more communication challenges.


>>>> Just use common sense when posting these things in the future.

Our “common sense” seems to be occasionally different in significant ways.


>>>> I would also suggest that your time might be spent more productively
>>>> if you would work on some more useful projects.

I distribute my software development capacity over several areas.
Does your wording indicate a questionable signal for further contributions?

Regards,
Markus