Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing
From: Doug Anderson <dianders@chromium.org>
Date: 2019-07-10 22:40:14
Also in:
dri-devel, linux-rockchip, lkml
Sam, On Mon, Jul 8, 2019 at 10:50 AM Sam Ravnborg [off-list ref] wrote:
Hi Dough. On Mon, Jul 01, 2019 at 09:39:24AM -0700, Doug Anderson wrote:quoted
Hi, On Sun, Jun 30, 2019 at 1:22 PM Sam Ravnborg [off-list ref] wrote:quoted
quoted
@@ -91,6 +92,8 @@ struct panel_simple { struct i2c_adapter *ddc; struct gpio_desc *enable_gpio; + + struct drm_display_mode override_mode;I fail to see where this poiter is assigned.In panel_simple_parse_override_mode(). Specifically: drm_display_mode_from_videomode(&vm, &panel->override_mode);The above code-snippet is only called in the panel has specified display timings using display_timings - it is not called when display_mode is used. So override_mode is only assigned in some cases and not all cases. This needs to be fixed so we do not reference override_mode unless it is set.
I'm afraid I'm not following you here. * override_mode is a structure that's directly part of "struct panel_simple". * The panel is allocated in panel_simple_probe() with devm_kzalloc(). * The "z" in kzalloc means that this memory will be zero-initialized. From the points above, "override_mode" will always be set to something. If we didn't run "drm_display_mode_from_videomode(&vm, &panel->override_mode);" then we know the entire override_mode structure will be zero. While it took a while for me to get used to it, the kernel convention is to rely on zero-initialization and not to explicitly init things to zero. As an example of this being codified in the source, you can see that "checkpatch.pl" will yell at you for a similar thing: "do not initialise globals to 0".
quoted
quoted
@@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)quoted
num++; } + return num; +} + +static int panel_simple_get_non_edid_modes(struct panel_simple *panel) +{ + struct drm_connector *connector = panel->base.connector; + struct drm_device *drm = panel->base.drm; + struct drm_display_mode *mode; + bool has_override = panel->override_mode.type;This looks suspicious. panel->override_mode.type is an unsigned int that may have a number of bits set. So the above code implicitly convert a .type != 0 to a true. This can be expressed in a much more reader friendly way.You would suggest that I add a boolean field to a structure to indicate whether an override mode is present?A simple bool has_override = panel->override_mode.type != 0; would do the trick here. Then there is no hidden conversion from int to a bool.
I will change this to "panel->override_mode.type != 0" if you're really sure, but this seems both against the general Linux style feedback I've received over the years (though there is definitely not 100% consistency) and also against the local convention in this file. Examples in this file of treating ints as bools without an explicit "!= 0": * panel_simple_get_fixed_modes checks "if (panel->desc->bus_format)" * panel_simple_disable checks "if (p->desc->delay.disable)" * panel_simple_unprepare checks "if (p->desc->delay.unprepare)" * panel_simple_prepare checks "if (delay)" * panel_simple_enable checks "if (p->desc->delay.enable)" ...and, although slightly different, pointers in this file are checked for NULL vs. non-NULL without an explicit "== NULL". Of course just because all the other examples in the file do it one way doesn't mean that new code has to do it another way, but I wanted to be really sure you wanted me to go against the existing convention before changing this.
But as override_mode can be NULL something more needs to be done.
I'm afraid I don't understand how override_mode can be NULL since it's not a pointer. Can you clarify? -Doug _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel