Re: [Outreachy kernel] [PATCH] staging: sm750fb: align arguments with open parenthesis
On Fri, 11 Oct 2019, Gabriela Bittencourt wrote:
> Cleans up checks of "Alignment should match open parenthesis" in tree sm750fb
>
> Signed-off-by: Gabriela Bittencourt
> ---
> drivers/staging/sm750fb/ddk750_display.c | 2 +-
> drivers/staging/sm750fb/sm750_accel.c| 2 +-
> drivers/staging/sm750fb/sm750_accel.h| 8
> drivers/staging/sm750fb/sm750_cursor.h | 10 +-
> 4 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_display.c
> b/drivers/staging/sm750fb/ddk750_display.c
> index 887ea8aef43f..8be98a1058d6 100644
> --- a/drivers/staging/sm750fb/ddk750_display.c
> +++ b/drivers/staging/sm750fb/ddk750_display.c
> @@ -148,7 +148,7 @@ void ddk750_set_logical_disp_out(enum disp_output output)
> if (output & PNL_SEQ_USAGE) {
> /* set panel sequence */
> sw_panel_power_sequence((output & PNL_SEQ_MASK) >>
> PNL_SEQ_OFFSET,
> - 4);
> + 4);
> }
>
> if (output & DAC_USAGE)
> diff --git a/drivers/staging/sm750fb/sm750_accel.c
> b/drivers/staging/sm750fb/sm750_accel.c
> index dbcbbd1055da..1a9555bb9edd 100644
> --- a/drivers/staging/sm750fb/sm750_accel.c
> +++ b/drivers/staging/sm750fb/sm750_accel.c
> @@ -289,7 +289,7 @@ static unsigned int deGetTransparency(struct lynx_accel
> *accel)
> }
>
> int sm750_hw_imageblit(struct lynx_accel *accel,
> - const char *pSrcbuf, /* pointer to start of source buffer in
> system memory */
> +const char *pSrcbuf, /* pointer to start of source
> buffer in system memory */
>u32 srcDelta, /* Pitch value (in bytes) of the source
> buffer, +ive means top down and -ive mean button up */
>u32 startBit, /* Mono data can start at any bit in a byte,
> this value should be 0 to 7 */
>u32 dBase,/* Address of destination: offset in frame
> buffer */
It is strange that the change is only does for the firsr parameter, and
not for all of them.
The kernel also uses a doc format for describing function patameters in a
single comment before the function. Look around in other files to see the
format. That would look much nicer than these comments going over 80
columns.
> diff --git a/drivers/staging/sm750fb/sm750_accel.h
> b/drivers/staging/sm750fb/sm750_accel.h
> index c4f42002a50f..8fb79b09fdd0 100644
> --- a/drivers/staging/sm750fb/sm750_accel.h
> +++ b/drivers/staging/sm750fb/sm750_accel.h
> @@ -190,9 +190,9 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int
> fmt);
> void sm750_hw_de_init(struct lynx_accel *accel);
>
> int sm750_hw_fillrect(struct lynx_accel *accel,
> - u32 base, u32 pitch, u32 Bpp,
> - u32 x, u32 y, u32 width, u32 height,
> - u32 color, u32 rop);
> + u32 base, u32 pitch, u32 Bpp,
> + u32 x, u32 y, u32 width, u32 height,
> + u32 color, u32 rop);
>
> int sm750_hw_copyarea(
> struct lynx_accel *accel,
> @@ -210,7 +210,7 @@ unsigned int height, /* width and height of rectangle in
> pixel value */
> unsigned int rop2);
>
> int sm750_hw_imageblit(struct lynx_accel *accel,
> - const char *pSrcbuf, /* pointer to start of source buffer in
> system memory */
> +const char *pSrcbuf, /* pointer to start of source
> buffer in system memory */
>u32 srcDelta, /* Pitch value (in bytes) of the source
> buffer, +ive means top down and -ive mean button up */
>u32 startBit, /* Mono data can start at any bit in a byte,
> this value should be 0 to 7 */
>u32 dBase,/* Address of destination: offset in frame
> buffer */
Same here.
> diff --git a/drivers/staging/sm750fb/sm750_cursor.h
> b/drivers/staging/sm750fb/sm750_cursor.h
> index 16ac07eb58d6..039ebfdf0bd9 100644
> --- a/drivers/staging/sm750fb/sm750_cursor.h
> +++ b/drivers/staging/sm750fb/sm750_cursor.h
> @@ -6,13 +6,13 @@
> void sm750_hw_cursor_enable(struct lynx_cursor *cursor);
> void sm750_hw_cursor_disable(struct lynx_cursor *cursor);
> void sm750_hw_cursor_setSize(struct lynx_cursor *cursor,
> - int w, int h);
> + int w, int h);
> void sm750_hw_cursor_setPos(struct lynx_cursor *cursor,
> - int x, int y);
> + int x, int y);
Perhaps these could just be all on one line?
julia
> void sm750_hw_cursor_setColor(struct lynx_cursor *cursor,
> - u32 fg, u32 bg);
> + u32 fg, u32 bg);
> void sm750_hw_cursor_setData(struct lynx_cursor *cursor,
> - u16 rop, const u8 *data, const u8 *mask);
> + u16 rop, const u8 *data, const u8 *mask);
> void sm750_hw_cursor_setData2(
Re: [PATCH] staging: sm750fb: align arguments with open parenthesis
On Fri, 2019-10-11 at 22:19 -0300, Gabriela Bittencourt wrote: > Cleans up checks of "Alignment should match open parenthesis" in tree sm750fb [] > diff --git a/drivers/staging/sm750fb/sm750_accel.c > b/drivers/staging/sm750fb/sm750_accel.c [] > @@ -289,7 +289,7 @@ static unsigned int deGetTransparency(struct lynx_accel > *accel) > } > > int sm750_hw_imageblit(struct lynx_accel *accel, > - const char *pSrcbuf, /* pointer to start of source buffer in > system memory */ > +const char *pSrcbuf, /* pointer to start of source > buffer in system memory */ >u32 srcDelta, /* Pitch value (in bytes) of the source > buffer, +ive means top down and -ive mean button up */ checkpatch only warns on the first unaligned argument, but all statement lines are meant to align to the open parenthesis. >u32 startBit, /* Mono data can start at any bit in a byte, > this value should be 0 to 7 */ >u32 dBase,/* Address of destination: offset in frame > buffer */ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: sm750fb: align arguments with open parenthesis
Cleans up checks of "Alignment should match open parenthesis" in tree sm750fb
Signed-off-by: Gabriela Bittencourt
---
drivers/staging/sm750fb/ddk750_display.c | 2 +-
drivers/staging/sm750fb/sm750_accel.c| 2 +-
drivers/staging/sm750fb/sm750_accel.h| 8
drivers/staging/sm750fb/sm750_cursor.h | 10 +-
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_display.c
b/drivers/staging/sm750fb/ddk750_display.c
index 887ea8aef43f..8be98a1058d6 100644
--- a/drivers/staging/sm750fb/ddk750_display.c
+++ b/drivers/staging/sm750fb/ddk750_display.c
@@ -148,7 +148,7 @@ void ddk750_set_logical_disp_out(enum disp_output output)
if (output & PNL_SEQ_USAGE) {
/* set panel sequence */
sw_panel_power_sequence((output & PNL_SEQ_MASK) >>
PNL_SEQ_OFFSET,
- 4);
+ 4);
}
if (output & DAC_USAGE)
diff --git a/drivers/staging/sm750fb/sm750_accel.c
b/drivers/staging/sm750fb/sm750_accel.c
index dbcbbd1055da..1a9555bb9edd 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -289,7 +289,7 @@ static unsigned int deGetTransparency(struct lynx_accel
*accel)
}
int sm750_hw_imageblit(struct lynx_accel *accel,
-const char *pSrcbuf, /* pointer to start of source buffer in
system memory */
+ const char *pSrcbuf, /* pointer to start of source
buffer in system memory */
u32 srcDelta, /* Pitch value (in bytes) of the source
buffer, +ive means top down and -ive mean button up */
u32 startBit, /* Mono data can start at any bit in a byte,
this value should be 0 to 7 */
u32 dBase,/* Address of destination: offset in frame
buffer */
diff --git a/drivers/staging/sm750fb/sm750_accel.h
b/drivers/staging/sm750fb/sm750_accel.h
index c4f42002a50f..8fb79b09fdd0 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -190,9 +190,9 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int
fmt);
void sm750_hw_de_init(struct lynx_accel *accel);
int sm750_hw_fillrect(struct lynx_accel *accel,
- u32 base, u32 pitch, u32 Bpp,
- u32 x, u32 y, u32 width, u32 height,
- u32 color, u32 rop);
+ u32 base, u32 pitch, u32 Bpp,
+ u32 x, u32 y, u32 width, u32 height,
+ u32 color, u32 rop);
int sm750_hw_copyarea(
struct lynx_accel *accel,
@@ -210,7 +210,7 @@ unsigned int height, /* width and height of rectangle in
pixel value */
unsigned int rop2);
int sm750_hw_imageblit(struct lynx_accel *accel,
-const char *pSrcbuf, /* pointer to start of source buffer in
system memory */
+ const char *pSrcbuf, /* pointer to start of source
buffer in system memory */
u32 srcDelta, /* Pitch value (in bytes) of the source
buffer, +ive means top down and -ive mean button up */
u32 startBit, /* Mono data can start at any bit in a byte,
this value should be 0 to 7 */
u32 dBase,/* Address of destination: offset in frame
buffer */
diff --git a/drivers/staging/sm750fb/sm750_cursor.h
b/drivers/staging/sm750fb/sm750_cursor.h
index 16ac07eb58d6..039ebfdf0bd9 100644
--- a/drivers/staging/sm750fb/sm750_cursor.h
+++ b/drivers/staging/sm750fb/sm750_cursor.h
@@ -6,13 +6,13 @@
void sm750_hw_cursor_enable(struct lynx_cursor *cursor);
void sm750_hw_cursor_disable(struct lynx_cursor *cursor);
void sm750_hw_cursor_setSize(struct lynx_cursor *cursor,
- int w, int h);
+int w, int h);
void sm750_hw_cursor_setPos(struct lynx_cursor *cursor,
- int x, int y);
+ int x, int y);
void sm750_hw_cursor_setColor(struct lynx_cursor *cursor,
- u32 fg, u32 bg);
+ u32 fg, u32 bg);
void sm750_hw_cursor_setData(struct lynx_cursor *cursor,
- u16 rop, const u8 *data, const u8 *mask);
+u16 rop, const u8 *data, const u8 *mask);
void sm750_hw_cursor_setData2(struct lynx_cursor *cursor,
- u16 rop, const u8 *data, const u8 *mask);
+ u16 rop, const u8 *data, const u8 *mask);
#endif
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: vc04_services: fix warnings of lines should not end with open parenthesis
On Fri, 2019-10-11 at 23:23 +0200, Julia Lawall wrote:
> On Fri, 11 Oct 2019, Jules Irenge wrote:
> > Fix warning of lines should not end with open parenthesis.
> > Issue detected by checkpatch tool.
[]
> > diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> > b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
[]
> > @@ -337,9 +337,8 @@ static void buffer_cb(struct vchiq_mmal_instance
> > *instance,
> > if (is_capturing(dev)) {
> > v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
> > "Grab another frame");
> > - vchiq_mmal_port_parameter_set(
> > - instance,
> > - dev->capture.camera_port,
> > + vchiq_mmal_port_parameter_set(instance,
> > + dev->capture.camera_port,
> > MMAL_PARAMETER_CAPTURE,
> > &dev->capture.frame_count,
> > sizeof(dev->capture.frame_count));
>
> You can't reduce the indentation on the function call. It has to stay
> clearly in the if branch.
>
> If you adjust the indentation of some of the arguments, you have to do so
> to all of the arguments.
>
> Similar issues arise below. There may be no way to make some of the calls
> look nice without a more severe reorganization of the code.
My suggestion would be to shorten the vchiq_mmal_port_parameter_set
function name (29 chars is just too long) and pass dev instead of
dev->instance as the first argument to this function.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH] staging: vc04_services: fix warning of Logical continuations should be on the previous line
On Fri, 11 Oct 2019, Jules Irenge wrote:
> Fix warning of logical continuations should be on the previous line.
> Issue detected by checkpatch tool.
There seem to be several changes mixed together in this patch.
Don't have a subject line that is identical to a line in the log message.
The subject line should be short.
Keeping the arguments of && on the same line, but breaking the line after
a == doesn't seem to be a good idea. It would be better to have the left
argument of == on one line and the right argument on another, if that is
needed.
julia
>
> Signed-off-by: Jules Irenge
> ---
> .../bcm2835-camera/bcm2835-camera.c | 41 ---
> 1 file changed, 17 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> index d4d1e44b16b2..365bcd97e19d 100644
> --- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> +++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> @@ -337,9 +337,8 @@ static void buffer_cb(struct vchiq_mmal_instance
> *instance,
> if (is_capturing(dev)) {
> v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
>"Grab another frame");
> - vchiq_mmal_port_parameter_set(
> - instance,
> - dev->capture.camera_port,
> + vchiq_mmal_port_parameter_set(instance,
> + dev->capture.camera_port,
> MMAL_PARAMETER_CAPTURE,
> &dev->capture.frame_count,
> sizeof(dev->capture.frame_count));
> @@ -392,9 +391,8 @@ static void buffer_cb(struct vchiq_mmal_instance
> *instance,
> is_capturing(dev)) {
> v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
>"Grab another frame as buffer has EOS");
> - vchiq_mmal_port_parameter_set(
> - instance,
> - dev->capture.camera_port,
> + vchiq_mmal_port_parameter_set(instance,
> + dev->capture.camera_port,
> MMAL_PARAMETER_CAPTURE,
> &dev->capture.frame_count,
> sizeof(dev->capture.frame_count));
> @@ -1090,8 +1088,7 @@ static int mmal_setup_components(struct bm2835_mmal_dev
> *dev,
>
> ret = vchiq_mmal_port_set_format(dev->instance, camera_port);
>
> - if (!ret
> - && camera_port ==
> + if (!ret && camera_port ==
> &dev->component[COMP_CAMERA]->output[CAM_PORT_VIDEO]) {
> bool overlay_enabled =
> !!dev->component[COMP_PREVIEW]->enabled;
> @@ -1124,9 +1121,8 @@ static int mmal_setup_components(struct bm2835_mmal_dev
> *dev,
> dev->capture.timeperframe.numerator;
> ret = vchiq_mmal_port_set_format(dev->instance, preview_port);
> if (overlay_enabled) {
> - ret = vchiq_mmal_port_connect_tunnel(
> - dev->instance,
> - preview_port,
> + ret = vchiq_mmal_port_connect_tunnel(dev->instance,
> + preview_port,
> &dev->component[COMP_PREVIEW]->input[0]);
> if (!ret)
> ret = vchiq_mmal_port_enable(dev->instance,
> @@ -1154,9 +1150,8 @@ static int mmal_setup_components(struct bm2835_mmal_dev
> *dev,
> camera_port->recommended_buffer.num;
>
> ret =
> - vchiq_mmal_port_connect_tunnel(
> - dev->instance,
> - camera_port,
> + vchiq_mmal_port_connect_tunnel(dev->instance,
> +camera_port,
> &encode_component->input[0]);
> if (ret) {
> v4l2_dbg(1, bcm2835_v4l2_debug,
> @@ -1655,8 +1650,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
> dev->capture.enc_level = V4L2_MPEG_VIDEO_H264_LEVEL_4_0;
>
> /* get the preview component ready */
> - ret = vchiq_mmal_component_init(
> - dev->instance, "ril.video_render",
> + ret = vchiq_mmal_component_init(dev->instance,
> + "ril.video_render",
> &dev->component[COMP_PREVIEW]);
> if (ret < 0)
> goto unreg_camera;
> @@ -1669,8 +1664,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
> }
>
> /*
[PATCH] staging: vc04_services: fix warning of Logical continuations should be on the previous line
Fix warning of logical continuations should be on the previous line.
Issue detected by checkpatch tool.
Signed-off-by: Jules Irenge
---
.../bcm2835-camera/bcm2835-camera.c | 41 ---
1 file changed, 17 insertions(+), 24 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index d4d1e44b16b2..365bcd97e19d 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -337,9 +337,8 @@ static void buffer_cb(struct vchiq_mmal_instance *instance,
if (is_capturing(dev)) {
v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
"Grab another frame");
- vchiq_mmal_port_parameter_set(
- instance,
- dev->capture.camera_port,
+ vchiq_mmal_port_parameter_set(instance,
+ dev->capture.camera_port,
MMAL_PARAMETER_CAPTURE,
&dev->capture.frame_count,
sizeof(dev->capture.frame_count));
@@ -392,9 +391,8 @@ static void buffer_cb(struct vchiq_mmal_instance *instance,
is_capturing(dev)) {
v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
"Grab another frame as buffer has EOS");
- vchiq_mmal_port_parameter_set(
- instance,
- dev->capture.camera_port,
+ vchiq_mmal_port_parameter_set(instance,
+ dev->capture.camera_port,
MMAL_PARAMETER_CAPTURE,
&dev->capture.frame_count,
sizeof(dev->capture.frame_count));
@@ -1090,8 +1088,7 @@ static int mmal_setup_components(struct bm2835_mmal_dev
*dev,
ret = vchiq_mmal_port_set_format(dev->instance, camera_port);
- if (!ret
- && camera_port ==
+ if (!ret && camera_port ==
&dev->component[COMP_CAMERA]->output[CAM_PORT_VIDEO]) {
bool overlay_enabled =
!!dev->component[COMP_PREVIEW]->enabled;
@@ -1124,9 +1121,8 @@ static int mmal_setup_components(struct bm2835_mmal_dev
*dev,
dev->capture.timeperframe.numerator;
ret = vchiq_mmal_port_set_format(dev->instance, preview_port);
if (overlay_enabled) {
- ret = vchiq_mmal_port_connect_tunnel(
- dev->instance,
- preview_port,
+ ret = vchiq_mmal_port_connect_tunnel(dev->instance,
+preview_port,
&dev->component[COMP_PREVIEW]->input[0]);
if (!ret)
ret = vchiq_mmal_port_enable(dev->instance,
@@ -1154,9 +1150,8 @@ static int mmal_setup_components(struct bm2835_mmal_dev
*dev,
camera_port->recommended_buffer.num;
ret =
- vchiq_mmal_port_connect_tunnel(
- dev->instance,
- camera_port,
+ vchiq_mmal_port_connect_tunnel(dev->instance,
+ camera_port,
&encode_component->input[0]);
if (ret) {
v4l2_dbg(1, bcm2835_v4l2_debug,
@@ -1655,8 +1650,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
dev->capture.enc_level = V4L2_MPEG_VIDEO_H264_LEVEL_4_0;
/* get the preview component ready */
- ret = vchiq_mmal_component_init(
- dev->instance, "ril.video_render",
+ ret = vchiq_mmal_component_init(dev->instance,
+ "ril.video_render",
&dev->component[COMP_PREVIEW]);
if (ret < 0)
goto unreg_camera;
@@ -1669,8 +1664,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
}
/* get the image encoder component ready */
- ret = vchiq_mmal_component_init(
- dev->instance, "ril.image_encode",
+ ret = vchiq_mmal_component_init(dev->instance,
+ "ril.image_encode",
&dev->component[COMP_IMAGE_ENCODE]);
if (ret < 0)
goto unreg_preview;
@@ -1731,15 +1726,13 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
unreg_vid_encoder:
pr_err("Cleanup: Destroy video encoder\n");
Re: [Outreachy kernel] [PATCH] staging: vc04_services: fix warnings of lines should not end with open parenthesis
On Fri, 11 Oct 2019, Jules Irenge wrote:
> Fix warning of lines should not end with open parenthesis.
> Issue detected by checkpatch tool.
>
> Signed-off-by: Jules Irenge
> ---
> .../bcm2835-camera/bcm2835-camera.c | 38 ---
> 1 file changed, 16 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> index d4d1e44b16b2..c7bb6e3f529c 100644
> --- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> +++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
> @@ -337,9 +337,8 @@ static void buffer_cb(struct vchiq_mmal_instance
> *instance,
> if (is_capturing(dev)) {
> v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
>"Grab another frame");
> - vchiq_mmal_port_parameter_set(
> - instance,
> - dev->capture.camera_port,
> + vchiq_mmal_port_parameter_set(instance,
> + dev->capture.camera_port,
> MMAL_PARAMETER_CAPTURE,
> &dev->capture.frame_count,
> sizeof(dev->capture.frame_count));
You can't reduce the indentation on the function call. It has to stay
clearly in the if branch.
If you adjust the indentation of some of the arguments, you have to do so
to all of the arguments.
Similar issues arise below. There may be no way to make some of the calls
look nice without a more severe reorganization of the code.
julia
> @@ -392,9 +391,8 @@ static void buffer_cb(struct vchiq_mmal_instance
> *instance,
> is_capturing(dev)) {
> v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
>"Grab another frame as buffer has EOS");
> - vchiq_mmal_port_parameter_set(
> - instance,
> - dev->capture.camera_port,
> + vchiq_mmal_port_parameter_set(instance,
> + dev->capture.camera_port,
> MMAL_PARAMETER_CAPTURE,
> &dev->capture.frame_count,
> sizeof(dev->capture.frame_count));
> @@ -1124,9 +1122,8 @@ static int mmal_setup_components(struct bm2835_mmal_dev
> *dev,
> dev->capture.timeperframe.numerator;
> ret = vchiq_mmal_port_set_format(dev->instance, preview_port);
> if (overlay_enabled) {
> - ret = vchiq_mmal_port_connect_tunnel(
> - dev->instance,
> - preview_port,
> + ret = vchiq_mmal_port_connect_tunnel(dev->instance,
> + preview_port,
> &dev->component[COMP_PREVIEW]->input[0]);
> if (!ret)
> ret = vchiq_mmal_port_enable(dev->instance,
> @@ -1154,9 +1151,8 @@ static int mmal_setup_components(struct bm2835_mmal_dev
> *dev,
> camera_port->recommended_buffer.num;
>
> ret =
> - vchiq_mmal_port_connect_tunnel(
> - dev->instance,
> - camera_port,
> + vchiq_mmal_port_connect_tunnel(dev->instance,
> +camera_port,
> &encode_component->input[0]);
> if (ret) {
> v4l2_dbg(1, bcm2835_v4l2_debug,
> @@ -1655,8 +1651,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
> dev->capture.enc_level = V4L2_MPEG_VIDEO_H264_LEVEL_4_0;
>
> /* get the preview component ready */
> - ret = vchiq_mmal_component_init(
> - dev->instance, "ril.video_render",
> + ret = vchiq_mmal_component_init(dev->instance,
> + "ril.video_render",
> &dev->component[COMP_PREVIEW]);
> if (ret < 0)
> goto unreg_camera;
> @@ -1669,8 +1665,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
> }
>
> /* get the image encoder component ready */
> - ret = vchiq_mmal_component_init(
> - dev->instance, "ril.image_encode",
> + ret = vchiq_mmal_component_init(dev->instance,
> + "ril.image_encode",
> &dev->component[COMP_IMAGE_ENCODE]);
> if (ret < 0)
> goto unreg_preview;
> @@ -1731,15 +1727,13 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
>
> unreg_vid_encoder:
> pr_err("Cleanup: Destroy v
[PATCH] staging: vc04_services: fix warnings of lines should not end with open parenthesis
Fix warning of lines should not end with open parenthesis.
Issue detected by checkpatch tool.
Signed-off-by: Jules Irenge
---
.../bcm2835-camera/bcm2835-camera.c | 38 ---
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index d4d1e44b16b2..c7bb6e3f529c 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -337,9 +337,8 @@ static void buffer_cb(struct vchiq_mmal_instance *instance,
if (is_capturing(dev)) {
v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
"Grab another frame");
- vchiq_mmal_port_parameter_set(
- instance,
- dev->capture.camera_port,
+ vchiq_mmal_port_parameter_set(instance,
+ dev->capture.camera_port,
MMAL_PARAMETER_CAPTURE,
&dev->capture.frame_count,
sizeof(dev->capture.frame_count));
@@ -392,9 +391,8 @@ static void buffer_cb(struct vchiq_mmal_instance *instance,
is_capturing(dev)) {
v4l2_dbg(1, bcm2835_v4l2_debug, &dev->v4l2_dev,
"Grab another frame as buffer has EOS");
- vchiq_mmal_port_parameter_set(
- instance,
- dev->capture.camera_port,
+ vchiq_mmal_port_parameter_set(instance,
+ dev->capture.camera_port,
MMAL_PARAMETER_CAPTURE,
&dev->capture.frame_count,
sizeof(dev->capture.frame_count));
@@ -1124,9 +1122,8 @@ static int mmal_setup_components(struct bm2835_mmal_dev
*dev,
dev->capture.timeperframe.numerator;
ret = vchiq_mmal_port_set_format(dev->instance, preview_port);
if (overlay_enabled) {
- ret = vchiq_mmal_port_connect_tunnel(
- dev->instance,
- preview_port,
+ ret = vchiq_mmal_port_connect_tunnel(dev->instance,
+preview_port,
&dev->component[COMP_PREVIEW]->input[0]);
if (!ret)
ret = vchiq_mmal_port_enable(dev->instance,
@@ -1154,9 +1151,8 @@ static int mmal_setup_components(struct bm2835_mmal_dev
*dev,
camera_port->recommended_buffer.num;
ret =
- vchiq_mmal_port_connect_tunnel(
- dev->instance,
- camera_port,
+ vchiq_mmal_port_connect_tunnel(dev->instance,
+ camera_port,
&encode_component->input[0]);
if (ret) {
v4l2_dbg(1, bcm2835_v4l2_debug,
@@ -1655,8 +1651,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
dev->capture.enc_level = V4L2_MPEG_VIDEO_H264_LEVEL_4_0;
/* get the preview component ready */
- ret = vchiq_mmal_component_init(
- dev->instance, "ril.video_render",
+ ret = vchiq_mmal_component_init(dev->instance,
+ "ril.video_render",
&dev->component[COMP_PREVIEW]);
if (ret < 0)
goto unreg_camera;
@@ -1669,8 +1665,8 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
}
/* get the image encoder component ready */
- ret = vchiq_mmal_component_init(
- dev->instance, "ril.image_encode",
+ ret = vchiq_mmal_component_init(dev->instance,
+ "ril.image_encode",
&dev->component[COMP_IMAGE_ENCODE]);
if (ret < 0)
goto unreg_preview;
@@ -1731,15 +1727,13 @@ static int mmal_init(struct bm2835_mmal_dev *dev)
unreg_vid_encoder:
pr_err("Cleanup: Destroy video encoder\n");
- vchiq_mmal_component_finalise(
- dev->instance,
- dev->component[COMP_VIDEO_ENCODE]);
+ vchiq_mmal_component_finalise(dev->instance,
+ dev->component[COMP_VIDEO_ENCODE]);
unreg_image_encoder:
pr_err("Cleanup: Destroy image encoder\n");
- vchiq_mmal_component_finalise(
- dev->instance,
- dev->com
Re: [PATCH] staging: isdn: remove assignment in if conditionals
On Fri, Oct 11, 2019 at 02:00:20PM +0300, Dan Carpenter wrote: > This ISDN stuff is going to be deleted soon. Just leave it as is. > > regards, > dan carpenter > Noted, thanks wambui karuga ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] Re: [PATCH v3 1/4] staging: rtl8723bs: Remove comparisons to NULL in conditionals
On Fri, Oct 11, 2019 at 02:08:47PM +0200, Greg KH wrote:
> On Fri, Oct 11, 2019 at 02:07:17PM +0200, Greg KH wrote:
> > On Fri, Oct 11, 2019 at 01:54:04PM +0300, Dan Carpenter wrote:
> > > On Thu, Oct 10, 2019 at 04:15:29PM +0300, Wambui Karuga wrote:
> > > > psetauthparm = rtw_zmalloc(sizeof(struct setauth_parm));
> > > > - if (psetauthparm == NULL) {
> > > > - kfree(pcmd);
> > > > + if (!psetauthparm) {
> > > > + kfree((unsigned char *)pcmd);
> > >
> > > This new cast is unnecessary and weird.
> >
> > Ah, I missed that, good catch. I'll go drop this patch now.
>
> And that caused the second patch to get dropped as well. I'll just drop
> them all, can you redo the whole series please?
>
> thanks,
>
> greg k-h
>
The cast seems to have been removed earlier by Nachammai Karuppiah and
added to staging-testing, but I added it back when I cherry-picked my changes
to the new
file.
Sorry. :(
I can remove the cast and send a new series.
Thanks.
wambui karuga
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: wfx: fix potential vulnerability to spectre
From: Jérôme Pouiller
array_index_nospec() should be applied after a bound check.
Fixes: 9bca45f3d692 ("staging: wfx: allow to send 802.11 frames")
Reported-by: kbuild test robot
Reported-by: Dan Carpenter
Signed-off-by: Jérôme Pouiller
---
v2: cut down commit-id to 12 characters
v3: fix missing include
drivers/staging/wfx/wfx.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/wfx/wfx.h b/drivers/staging/wfx/wfx.h
index 489836837b0a..d678b5a08873 100644
--- a/drivers/staging/wfx/wfx.h
+++ b/drivers/staging/wfx/wfx.h
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include "bh.h"
@@ -138,6 +139,7 @@ static inline struct wfx_vif *wdev_to_wvif(struct wfx_dev
*wdev, int vif_id)
dev_dbg(wdev->dev, "requesting non-existent vif: %d\n", vif_id);
return NULL;
}
+ vif_id = array_index_nospec(vif_id, ARRAY_SIZE(wdev->vif));
if (!wdev->vif[vif_id]) {
dev_dbg(wdev->dev, "requesting non-allocated vif: %d\n",
vif_id);
return NULL;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
staging: wlan-ng: Checking a kmemdup() call in prism2sta_inf_hostscanresults()
Hello, I have tried another script for the semantic patch language out. This source code analysis approach points out that the implementation of the function “prism2sta_inf_hostscanresults” contains still an unchecked call of the function “kmemdup”. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/wlan-ng/prism2sta.c?id=26a7ae2949a86e1b74e2485d725efb528e2a81bb#n1086 https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/staging/wlan-ng/prism2sta.c#L1086 How do you think about to improve it? Regards, Markus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: fix potential vulnerability to spectre
On Fri, Oct 11, 2019 at 12:35:36PM +, Jerome Pouiller wrote:
> On Friday 11 October 2019 14:10:35 CEST Greg Kroah-Hartman wrote:
> > On Fri, Oct 11, 2019 at 10:15:54AM +, Jerome Pouiller wrote:
> > > From: Jérôme Pouiller
> > >
> > > array_index_nospec() should be applied after a bound check.
> > >
> > > Fixes: 9bca45f3d6924f19f29c0d019e961af3f41bdc9e ("staging: wfx: allow to
> > > send 802.11 frames")
> >
> > No need for the full sha1, this should be:
> > Fixes: 9bca45f3d692 ("staging: wfx: allow to send 802.11 frames")
>
> I copy-pasted information from kbuild robot notification.
>
> I suggest that commit-id in robot notification is also cut down to 12
> characters. Or even better, to use this snippet:
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
> Fixes: 9bca45f3d692 ("staging: wfx: allow to send 802.11 frames")
>
> (I added l...@lists.01.org in CC but, I am not sure it is the correct
> ML. I am sorry if it is not the case)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
staging-testing
head: d49d1c76b96ebf39539e93d5ab7943a01ef70e4f
commit: 9bca45f3d6924f19f29c0d019e961af3f41bdc9e [55/111] staging: wfx: allow
to send 802.11 frames
If you cut and paste then you the "[55/111] " text isn't right either.
Also kbuild works on rebase-able trees as well as non-rebase/published
trees so the hash could change as well.
I am a little bit surprised that checkpatch.pl doesn't complain about
this, though. You could consider adding that?
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
Hi Andrzej,
On Fri, Oct 11, 2019 at 01:21:43PM +0200, Andrzej Hajda wrote:
> On 11.10.2019 04:21, Xin Ji wrote:
> > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> > for portable device. It converts MIPI to DisplayPort 1.3 4K.
> >
> > You can add support to your board with binding.
> >
> > Example:
> > anx7625_bridge: encoder@58 {
> > compatible = "analogix,anx7625";
> > reg = <0x58>;
> > status = "okay";
> > panel-flags = <1>;
> > enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> > reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > port@0 {
> > reg = <0>;
> > anx_1_in: endpoint {
> > remote-endpoint = <&mipi_dsi>;
> > };
> > };
> >
> > port@3 {
> > reg = <3>;
> > anx_1_out: endpoint {
> > remote-endpoint = <&panel_in>;
> > };
> > };
> > };
> >
> > Signed-off-by: Xin Ji
> > ---
> > .../bindings/display/bridge/anx7625.yaml | 96
> > ++
> > 1 file changed, 96 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> > b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> > new file mode 100644
> > index 000..fc84683
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> > @@ -0,0 +1,96 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright 2019 Analogix Semiconductor, Inc.
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#";
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> > +
> > +title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
> > +
> > +maintainers:
> > + - Xin Ji
> > +
> > +description: |
> > + The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> > + designed for portable devices.
> > +
> > +properties:
> > + "#address-cells": true
> > + "#size-cells": true
> > +
> > + compatible:
> > +items:
> > + - const: analogix,anx7625
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + panel-flags:
> > +description: indicate the panel is internal or external
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + enable-gpios:
> > +description: used for power on chip control, POWER_EN pin D2.
> > +maxItems: 1
> > +
> > + reset-gpios:
> > +description: used for reset chip control, RESET_N pin B7.
> > +maxItems: 1
> > +
> > + port@0:
> > +type: object
> > +description:
> > + A port node pointing to MIPI DSI host port node.
> > +
> > + port@1:
> > +type: object
> > +description:
> > + A port node pointing to MIPI DPI host port node.
> > +
> > + port@2:
> > +type: object
> > +description:
> > + A port node pointing to external connector port node.
> > +
> > + port@3:
> > +type: object
> > +description:
> > + A port node pointing to eDP port node.
>
>
> Decrypting available product brief[1], there are following physical lines:
>
> Input:
>
> - MIPI DSI/DPI - video data, are DSI and DPI lines shared?
It would be much easier if we could have access to more complete
information. I believe the DSI and DPI pins could be muxed, but there
should be more DPI pins than DSI pins.
>
> - I2S - audio data,
>
> - I2C - control line,
>
> - ALERT/INTP - interrupt,
>
> - USB 3.1 SSRc/Tx - for USB forwarding,
>
> Output:
>
> - SS1, SS2,
>
> - SBU/AUX,
>
> - CC1/2.
>
>
> Having this information I try to understand ports defined by you:
>
> - port@2 you have defined as pointing to external port, but here the
> port should be rather subnode of ANX7625 - the chip has CC lines, see
> beginning of [2].
>
> - port@3 describes SS1, SS2 and SBU/AUX lines together, am I right? In
> USB-C binding SBU and SS lines are represented by different ports,
> different approach, but maybe better in this case.
I believe that, when connected to a DP display (either DP or eDP), the
DisplayPort signals are output on SS1 and/or SS2. I this really wonder
if we need two separate ports for this, it seems that port@2 and port@3
should be merged.
> Maybe it would be good to add 2nd example with USB-C port.
That would help with the discussion, yes.
> [1]:
> https://www.analogix.com/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
>
> [2]: Documentation/devicetree/bindings/connector/usb-connector.txt
>
> > +
> > +required:
> > + - "#address-cells"
> > + - "#size-cells"
> > + - compatible
> > + - reg
> > + - port@0
> > + - port@3
> > +
> > +example:
> > + - |
> > +anx7625_bridge: encoder@58 {
> > +compatible = "analogix,anx7625";
> > +reg = <0x58>;
> > +
Re: [PATCH] staging: wfx: fix potential vulnerability to spectre
On Friday 11 October 2019 14:10:35 CEST Greg Kroah-Hartman wrote:
> On Fri, Oct 11, 2019 at 10:15:54AM +, Jerome Pouiller wrote:
> > From: Jérôme Pouiller
> >
> > array_index_nospec() should be applied after a bound check.
> >
> > Fixes: 9bca45f3d6924f19f29c0d019e961af3f41bdc9e ("staging: wfx: allow to
> > send 802.11 frames")
>
> No need for the full sha1, this should be:
> Fixes: 9bca45f3d692 ("staging: wfx: allow to send 802.11 frames")
I copy-pasted information from kbuild robot notification.
I suggest that commit-id in robot notification is also cut down to 12
characters. Or even better, to use this snippet:
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
Fixes: 9bca45f3d692 ("staging: wfx: allow to send 802.11 frames")
(I added l...@lists.01.org in CC but, I am not sure it is the correct
ML. I am sorry if it is not the case)
--
Jérôme Pouiller
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: wfx: fix potential vulnerability to spectre
From: Jérôme Pouiller
array_index_nospec() should be applied after a bound check.
Fixes: 9bca45f3d692 ("staging: wfx: allow to send 802.11 frames")
Reported-by: kbuild test robot
Reported-by: Dan Carpenter
Signed-off-by: Jérôme Pouiller
---
v2: cut down commit-id to 12 characters
drivers/staging/wfx/wfx.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/wfx/wfx.h b/drivers/staging/wfx/wfx.h
index 489836837b0a..4c0f2836015c 100644
--- a/drivers/staging/wfx/wfx.h
+++ b/drivers/staging/wfx/wfx.h
@@ -138,6 +138,7 @@ static inline struct wfx_vif *wdev_to_wvif(struct wfx_dev
*wdev, int vif_id)
dev_dbg(wdev->dev, "requesting non-existent vif: %d\n", vif_id);
return NULL;
}
+ vif_id = array_index_nospec(vif_id, ARRAY_SIZE(wdev->vif));
if (!wdev->vif[vif_id]) {
dev_dbg(wdev->dev, "requesting non-allocated vif: %d\n",
vif_id);
return NULL;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wfx: fix potential vulnerability to spectre
On Fri, Oct 11, 2019 at 10:15:54AM +, Jerome Pouiller wrote:
> From: Jérôme Pouiller
>
> array_index_nospec() should be applied after a bound check.
>
> Fixes: 9bca45f3d6924f19f29c0d019e961af3f41bdc9e ("staging: wfx: allow to send
> 802.11 frames")
No need for the full sha1, this should be:
Fixes: 9bca45f3d692 ("staging: wfx: allow to send 802.11 frames")
The command:
git show -s --abbrev-commit --abbrev=12 --pretty=format:"%h (\"%s\")%n"
will provide it in the correct format.
Can you fix this up and resend?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/4] staging: rtl8723bs: Remove comparisons to NULL in conditionals
On Fri, Oct 11, 2019 at 02:07:17PM +0200, Greg KH wrote:
> On Fri, Oct 11, 2019 at 01:54:04PM +0300, Dan Carpenter wrote:
> > On Thu, Oct 10, 2019 at 04:15:29PM +0300, Wambui Karuga wrote:
> > > psetauthparm = rtw_zmalloc(sizeof(struct setauth_parm));
> > > - if (psetauthparm == NULL) {
> > > - kfree(pcmd);
> > > + if (!psetauthparm) {
> > > + kfree((unsigned char *)pcmd);
> >
> > This new cast is unnecessary and weird.
>
> Ah, I missed that, good catch. I'll go drop this patch now.
And that caused the second patch to get dropped as well. I'll just drop
them all, can you redo the whole series please?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/4] staging: rtl8723bs: Remove comparisons to NULL in conditionals
On Fri, Oct 11, 2019 at 01:54:04PM +0300, Dan Carpenter wrote:
> On Thu, Oct 10, 2019 at 04:15:29PM +0300, Wambui Karuga wrote:
> > psetauthparm = rtw_zmalloc(sizeof(struct setauth_parm));
> > - if (psetauthparm == NULL) {
> > - kfree(pcmd);
> > + if (!psetauthparm) {
> > + kfree((unsigned char *)pcmd);
>
> This new cast is unnecessary and weird.
Ah, I missed that, good catch. I'll go drop this patch now.
Wambui, please fix up and resend.
thanks
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fbtft: fbtft-core: Fix last line displayed on fbcon
From: Michael Hennerich
For the special case when fbtft_mkdirty() is called with with -1 for the y
coordinate, the height is truncated by 1.
This isn't required, and causes the last line to not update.
Signed-off-by: Michael Hennerich
Signed-off-by: Alexandru Ardelean
---
drivers/staging/fbtft/fbtft-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index cf5700a2ea66..90eec45d11fc 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -317,7 +317,7 @@ static void fbtft_mkdirty(struct fb_info *info, int y, int
height)
/* special case, needed ? */
if (y == -1) {
y = 0;
- height = info->var.yres - 1;
+ height = info->var.yres;
}
/* Mark display lines/area as dirty */
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
On 11.10.2019 04:21, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI to DisplayPort 1.3 4K.
>
> You can add support to your board with binding.
>
> Example:
> anx7625_bridge: encoder@58 {
> compatible = "analogix,anx7625";
> reg = <0x58>;
> status = "okay";
> panel-flags = <1>;
> enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> anx_1_in: endpoint {
> remote-endpoint = <&mipi_dsi>;
> };
> };
>
> port@3 {
> reg = <3>;
> anx_1_out: endpoint {
> remote-endpoint = <&panel_in>;
> };
> };
> };
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/anx7625.yaml | 96
> ++
> 1 file changed, 96 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/anx7625.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> new file mode 100644
> index 000..fc84683
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 Analogix Semiconductor, Inc.
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
> +
> +maintainers:
> + - Xin Ji
> +
> +description: |
> + The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> + designed for portable devices.
> +
> +properties:
> + "#address-cells": true
> + "#size-cells": true
> +
> + compatible:
> +items:
> + - const: analogix,anx7625
> +
> + reg:
> +maxItems: 1
> +
> + panel-flags:
> +description: indicate the panel is internal or external
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + enable-gpios:
> +description: used for power on chip control, POWER_EN pin D2.
> +maxItems: 1
> +
> + reset-gpios:
> +description: used for reset chip control, RESET_N pin B7.
> +maxItems: 1
> +
> + port@0:
> +type: object
> +description:
> + A port node pointing to MIPI DSI host port node.
> +
> + port@1:
> +type: object
> +description:
> + A port node pointing to MIPI DPI host port node.
> +
> + port@2:
> +type: object
> +description:
> + A port node pointing to external connector port node.
> +
> + port@3:
> +type: object
> +description:
> + A port node pointing to eDP port node.
Decrypting available product brief[1], there are following physical lines:
Input:
- MIPI DSI/DPI - video data, are DSI and DPI lines shared?
- I2S - audio data,
- I2C - control line,
- ALERT/INTP - interrupt,
- USB 3.1 SSRc/Tx - for USB forwarding,
Output:
- SS1, SS2,
- SBU/AUX,
- CC1/2.
Having this information I try to understand ports defined by you:
- port@2 you have defined as pointing to external port, but here the
port should be rather subnode of ANX7625 - the chip has CC lines, see
beginning of [2].
- port@3 describes SS1, SS2 and SBU/AUX lines together, am I right? In
USB-C binding SBU and SS lines are represented by different ports,
different approach, but maybe better in this case.
Maybe it would be good to add 2nd example with USB-C port.
[1]:
https://www.analogix.com/system/files/AA-002291-PB-6-ANX7625_ProductBrief.pdf
[2]: Documentation/devicetree/bindings/connector/usb-connector.txt
Regards
Andrzej
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - compatible
> + - reg
> + - port@0
> + - port@3
> +
> +example:
> + - |
> +anx7625_bridge: encoder@58 {
> +compatible = "analogix,anx7625";
> +reg = <0x58>;
> +status = "okay";
> +panel-flags = <1>;
> +enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> +reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> + reg = <0>;
> + anx_1_in: endpoint {
> +remote-endpoint = <&mipi_dsi>;
> + };
> +};
> +
> +port@3 {
> + reg = <3>;
> + anx_1_out: endpoint {
> +remote-endpoint = <&panel_in>;
> + };
> +};
> +};
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: isdn: remove assignment in if conditionals
This ISDN stuff is going to be deleted soon. Just leave it as is. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH 1/5] staging: octeon: remove typedef declaration for cvmx_wqe_t
On Fri, Oct 11, 2019 at 11:59:52AM +0300, Wambui Karuga wrote: > On Fri, Oct 11, 2019 at 08:18:25AM +0200, Julia Lawall wrote: > > > > > > On Fri, 11 Oct 2019, Wambui Karuga wrote: > > > > > Remove typedef declaration from struct cvmx_wqe_t in > > > > You can remove the _t from the name as well. > Should I remove the _t from all the enums/structs? The _t means typedef (sort of, generally). regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/4] staging: rtl8723bs: Remove comparisons to NULL in conditionals
On Thu, Oct 10, 2019 at 04:15:29PM +0300, Wambui Karuga wrote:
> psetauthparm = rtw_zmalloc(sizeof(struct setauth_parm));
> - if (psetauthparm == NULL) {
> - kfree(pcmd);
> + if (!psetauthparm) {
> + kfree((unsigned char *)pcmd);
This new cast is unnecessary and weird.
> res = _FAIL;
> goto exit;
> }
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/2] Add initial support for slimport anx7625
On Fri, Oct 11, 2019 at 02:20:47AM +, Xin Ji wrote: > Hi all, > > The following series add initial support for the Slimport ANX7625 > transmitter, a > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > device. > > This is the initial version, any mistakes, please let me know, I will fix it > in > the next series. > > Thanks, > Xin > I'm not a domain expert but I like these patches now. Reviewed-by: Dan Carpenter regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wfx: fix error handling in wfx_tx_get_raw_link_id()
From: Jérôme Pouiller
Since wfx_tx_get_raw_link_id() return an unsigned, it makes no sense to
return a negative value. "15" is a better value since it is used by
firmware for stations that have not yet associated link-ids.
Note that this should never happens since driver set max_ap_assoc_sta
to 14.
Fixes: 9bca45f3d692 ("staging: wfx: allow to send 802.11 frames")
Reported-by: kbuild test robot
Reported-by: Dan Carpenter
Signed-off-by: Jérôme Pouiller
---
drivers/staging/wfx/data_tx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c
index 6e4dd4ac5544..8ed38cac19f6 100644
--- a/drivers/staging/wfx/data_tx.c
+++ b/drivers/staging/wfx/data_tx.c
@@ -17,6 +17,7 @@
#include "hif_tx_mib.h"
#define WFX_INVALID_RATE_ID (0xFF)
+#define WFX_LINK_ID_NO_ASSOC 15
#define WFX_LINK_ID_GC_TIMEOUT ((unsigned long)(10 * HZ))
static int wfx_get_hw_rate(struct wfx_dev *wdev, const struct
ieee80211_tx_rate *rate)
@@ -480,7 +481,7 @@ static uint8_t wfx_tx_get_raw_link_id(struct wfx_vif *wvif,
struct ieee80211_sta
ret = wfx_alloc_link_id(wvif, da);
if (!ret) {
dev_err(wvif->wdev->dev, "no more link-id available\n");
- return -ENOENT;
+ return WFX_LINK_ID_NO_ASSOC;
}
return ret;
}
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wfx: fix potential vulnerability to spectre
From: Jérôme Pouiller
array_index_nospec() should be applied after a bound check.
Fixes: 9bca45f3d6924f19f29c0d019e961af3f41bdc9e ("staging: wfx: allow to send
802.11 frames")
Reported-by: kbuild test robot
Reported-by: Dan Carpenter
Signed-off-by: Jérôme Pouiller
---
drivers/staging/wfx/wfx.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/wfx/wfx.h b/drivers/staging/wfx/wfx.h
index 489836837b0a..4c0f2836015c 100644
--- a/drivers/staging/wfx/wfx.h
+++ b/drivers/staging/wfx/wfx.h
@@ -138,6 +138,7 @@ static inline struct wfx_vif *wdev_to_wvif(struct wfx_dev
*wdev, int vif_id)
dev_dbg(wdev->dev, "requesting non-existent vif: %d\n", vif_id);
return NULL;
}
+ vif_id = array_index_nospec(vif_id, ARRAY_SIZE(wdev->vif));
if (!wdev->vif[vif_id]) {
dev_dbg(wdev->dev, "requesting non-allocated vif: %d\n",
vif_id);
return NULL;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] KPC2000: kpc2000_spi.c: Fix style issues (line length)
On Thu, Oct 10, 2019 at 02:54:59PM +, Matt Sickler wrote:
> > static struct mtd_partition p2kr0_spi1_parts[] = {
> >- { .name = "SLOT_4", .size = 7798784,.offset = 0,
> > },
> >- { .name = "SLOT_5", .size = 7798784,.offset =
> >MTDPART_OFS_NXTBLK},
> >- { .name = "SLOT_6", .size = 7798784,.offset =
> >MTDPART_OFS_NXTBLK},
> >- { .name = "SLOT_7", .size = 7798784,.offset =
> >MTDPART_OFS_NXTBLK},
> >- { .name = "CS1_EXTRA", .size = MTDPART_SIZ_FULL, .offset =
> >MTDPART_OFS_NXTBLK},
> >+ { .name = "SLOT_4", .size = 7798784, .offset = 0,},
> >+ { .name = "SLOT_5", .size = 7798784, .offset = MTDPART_OFS_NXTBLK},
> >+ { .name = "SLOT_6", .size = 7798784, .offset = MTDPART_OFS_NXTBLK},
> >+ { .name = "SLOT_7", .size = 7798784, .offset = MTDPART_OFS_NXTBLK},
> >+ { .name = "CS1_EXTRA", .size = MTDPART_SIZ_FULL, .offset =
> >MTDPART_OFS_NXTBLK},
> > };
> >
> > static struct flash_platform_data p2kr0_spi0_pdata = {
>
> Is the line length limit a hard rule or can exceptions be made? I
> really feel that these data tables are more easily read when they're
> formatted like tables...
Exceptions can be made. It's probably not worth it though because
you have to be really aggressive about shooting down patches. Ask
yourself if there aren't more important battles to fight when human
lifespans are so short? I already rejected one change for you. To me
the new table looks okay, though.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/5] staging: octeon: remove typedef declaration for cvmx_helper_link_info_t
On Fri, Oct 11, 2019 at 11:02:13AM +0200, Greg KH wrote:
> On Fri, Oct 11, 2019 at 09:02:39AM +0300, Wambui Karuga wrote:
> > -typedef union {
> > +union cvmx_helper_link_info_t {
>
> I agree with Julia, all of the "_t" needs to be dropped as that is
> pointless. It's a holdover from the original name where "_t" was trying
> to say that this is a typedef. Gotta love abuse of hungarian notation
> :(
>
> Please redo this patch series and resend.
>
Great, I'll send an updated patch.
Thanks,
Wambui
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/5] Remove declarations of new typedef in
On Fri, Oct 11, 2019 at 11:01:00AM +0200, Greg KH wrote: > On Fri, Oct 11, 2019 at 09:02:37AM +0300, Wambui Karuga wrote: > > This patchset removes various typedef declarations of new data types > > in drivers/staging/octeon/octeon-stubs.h. > > The series also changes their old uses with the new declaration > > format. > > The subject line of this email seems to be lacking something :) > > thanks, > > greg k-h The ending of this sentence seems to have been cut-off. Sorry! Thanks. Wambui Karuga ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/5] KPC2000: kpc2000_spi.c: Fix style issues (missing blank line)
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Fri, Oct 11, 2019 at 02:02:32AM -0700, Chandra Annamaneni wrote: > The first set of patches were in a single commit. I started from scratch > and built these patches from 5 different commits. Don't know if the first > set of patches are relevant anymore. They are not relevant to being applied, but this patch series has changed based on the comments you received from the previous patch(s). So it is relevant to how you got to this set of patches. This makes it easier for reviewers to understand what changed and what they need to focus on, or ignore, in your new set of patches. This isn't for you, it is for the people you are sending these patches to. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/5] staging: octeon: remove typedef declaration for cvmx_helper_link_info_t
On Fri, Oct 11, 2019 at 09:02:39AM +0300, Wambui Karuga wrote:
> -typedef union {
> +union cvmx_helper_link_info_t {
I agree with Julia, all of the "_t" needs to be dropped as that is
pointless. It's a holdover from the original name where "_t" was trying
to say that this is a typedef. Gotta love abuse of hungarian notation
:(
Please redo this patch series and resend.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/5] Remove declarations of new typedef in
On Fri, Oct 11, 2019 at 09:02:37AM +0300, Wambui Karuga wrote: > This patchset removes various typedef declarations of new data types > in drivers/staging/octeon/octeon-stubs.h. > The series also changes their old uses with the new declaration > format. The subject line of this email seems to be lacking something :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Outreachy kernel] [PATCH 1/5] staging: octeon: remove typedef declaration for cvmx_wqe_t
On Fri, Oct 11, 2019 at 08:18:25AM +0200, Julia Lawall wrote: > > > On Fri, 11 Oct 2019, Wambui Karuga wrote: > > > Remove typedef declaration from struct cvmx_wqe_t in > > You can remove the _t from the name as well. Should I remove the _t from all the enums/structs? > > > drivers/staging/octeon/octeon-stubs.h. > > It's not really necessary to give the name of the file in the log message, > as it can easily be seen below. > > julia > Okay, thought it would be clearer for the commit messages/git log. Thanks ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/2] Add initial support for slimport anx7625
Hi Andrzej, OK, I'll increment patchset version number next time. Thanks, Xin On Fri, Oct 11, 2019 at 08:12:53AM +0200, Andrzej Hajda wrote: > On 11.10.2019 04:20, Xin Ji wrote: > > Hi all, > > > > The following series add initial support for the Slimport ANX7625 > > transmitter, a > > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > > device. > > > > This is the initial version, any mistakes, please let me know, I will fix > > it in > > the next series. > > > > Thanks, > > Xin > > > Next time please increment patchset version number - this is third > iteration of v2. > > > Regards > > Andrzej > > > > > > > > Xin Ji (2): > > dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding > > drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver > > > > .../bindings/display/bridge/anx7625.yaml | 96 + > > drivers/gpu/drm/bridge/Makefile|2 +- > > drivers/gpu/drm/bridge/analogix/Kconfig|6 + > > drivers/gpu/drm/bridge/analogix/Makefile |1 + > > drivers/gpu/drm/bridge/analogix/anx7625.c | 2153 > > > > drivers/gpu/drm/bridge/analogix/anx7625.h | 406 > > 6 files changed, 2663 insertions(+), 1 deletion(-) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/anx7625.yaml > > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c > > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: isdn: remove assignment in if conditionals
Remove variable assignment in if statements in
drivers/staging/isdn/avm/b1.c.
Issues reported by checkpatch.pl as:
ERROR: do not use assignment in if condition
Also refactor code around some if statements to remove comparisons
to NULL and unnecessary braces in single statement blocks.
Signed-off-by: Wambui Karuga
---
drivers/staging/isdn/avm/b1.c | 41 ---
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/isdn/avm/b1.c b/drivers/staging/isdn/avm/b1.c
index 40ca1e8fa09f..32ec8cf31fd0 100644
--- a/drivers/staging/isdn/avm/b1.c
+++ b/drivers/staging/isdn/avm/b1.c
@@ -261,9 +261,10 @@ int b1_loaded(avmcard *card)
b1_put_byte(base, SEND_POLL);
for (stop = jiffies + tout * HZ; time_before(jiffies, stop);) {
if (b1_rx_full(base)) {
- if ((ans = b1_get_byte(base)) == RECEIVE_POLL) {
+ ans = b1_get_byte(base);
+ if (ans == RECEIVE_POLL)
return 1;
- }
+
printk(KERN_ERR "%s: b1_loaded: got 0x%x, firmware not
running\n",
card->name, ans);
return 0;
@@ -284,8 +285,9 @@ int b1_load_firmware(struct capi_ctr *ctrl, capiloaddata
*data)
int retval;
b1_reset(port);
+ retval = b1_load_t4file(card, &data->firmware);
- if ((retval = b1_load_t4file(card, &data->firmware))) {
+ if (retval) {
b1_reset(port);
printk(KERN_ERR "%s: failed to load t4file!!\n",
card->name);
@@ -295,7 +297,8 @@ int b1_load_firmware(struct capi_ctr *ctrl, capiloaddata
*data)
b1_disable_irq(port);
if (data->configuration.len > 0 && data->configuration.data) {
- if ((retval = b1_load_config(card, &data->configuration))) {
+ retval = b1_load_config(card, &data->configuration);
+ if (retval) {
b1_reset(port);
printk(KERN_ERR "%s: failed to load config!!\n",
card->name);
@@ -525,7 +528,9 @@ irqreturn_t b1_interrupt(int interrupt, void *devptr)
MsgLen = 30;
CAPIMSG_SETLEN(card->msgbuf, 30);
}
- if (!(skb = alloc_skb(DataB3Len + MsgLen, GFP_ATOMIC))) {
+
+ skb = alloc_skb(DataB3Len + MsgLen, GFP_ATOMIC);
+ if (!skb) {
printk(KERN_ERR "%s: incoming packet dropped\n",
card->name);
} else {
@@ -539,7 +544,9 @@ irqreturn_t b1_interrupt(int interrupt, void *devptr)
ApplId = (unsigned) b1_get_word(card->port);
MsgLen = b1_get_slice(card->port, card->msgbuf);
- if (!(skb = alloc_skb(MsgLen, GFP_ATOMIC))) {
+ skb = alloc_skb(MsgLen, GFP_ATOMIC);
+
+ if (!skb) {
printk(KERN_ERR "%s: incoming packet dropped\n",
card->name);
spin_unlock_irqrestore(&card->lock, flags);
@@ -663,11 +670,17 @@ int b1_proc_show(struct seq_file *m, void *v)
seq_printf(m, "%-16s %s\n", "type", s);
if (card->cardtype == avm_t1isa)
seq_printf(m, "%-16s %d\n", "cardnr", card->cardnr);
- if ((s = cinfo->version[VER_DRIVER]) != NULL)
+
+ s = cinfo->version[VER_DRIVER];
+ if (s)
seq_printf(m, "%-16s %s\n", "ver_driver", s);
- if ((s = cinfo->version[VER_CARDTYPE]) != NULL)
+
+ s = cinfo->version[VER_CARDTYPE];
+ if (s)
seq_printf(m, "%-16s %s\n", "ver_cardtype", s);
- if ((s = cinfo->version[VER_SERIAL]) != NULL)
+
+ s = cinfo->version[VER_SERIAL];
+ if (s)
seq_printf(m, "%-16s %s\n", "ver_serial", s);
if (card->cardtype != avm_m1) {
@@ -784,13 +797,15 @@ static int __init b1_init(void)
char *p;
char rev[32];
- if ((p = strchr(revision, ':')) != NULL && p[1]) {
+ p = strchr(revision, ':');
+ if (p && p[1]) {
strlcpy(rev, p + 2, 32);
- if ((p = strchr(rev, '$')) != NULL && p > rev)
+ p = strchr(rev, '$');
+ if (p && p > rev)
*(p - 1) = 0;
- } else
+ } else {
strcpy(rev, "1.0");
-
+ }
printk(KERN_INFO "b1: revision %s\n", rev);
return 0;
--
2.23.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
