linux-kernel - Re: [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 4 Aug 2013 10:36:11 +0200
From:	Pali Rohár <pali.rohar@...il.com>
To:	Tomi Valkeinen <tomi.valkeinen@...com>
Cc:	Pavel Machek <pavel@....cz>,
	"Jean-Christophe Plagniol-Villard" <plagnioj@...osoft.com>,
	linux-omap@...r.kernel.org, linux-fbdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Aaro Koskinen <aaro.koskinen@....fi>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet

Hello,

On Tuesday 23 July 2013 12:01:39 Tomi Valkeinen wrote:
> On 13/07/13 21:27, Pavel Machek wrote:
> > On Wed 2013-07-10 15:08:59, Pali Rohár wrote:
> >> * On RX-51 probing for acx565akm driver is later then for
> >> omapfb which cause that omapfb probe fail and framebuffer
> >> is not working * EPROBE_DEFER causing that kernel try to
> >> probe for omapfb later again which fixing this problem
> >> 
> >> * Without this patch display on Nokia RX-51 (N900) phone
> >> not working
> >> 
> >> Signed-off-by: Pali Rohár <pali.rohar@...il.com>
> > 
> > Tested-by: Pavel Machek <pavel@....cz>
> 
> Which kernel version is this? Does it have
> dfbc32316c6991010328c21e6046b05bac57eb84 (OMAPFB: defer probe
> if no displays)?
> 

Kernel 3.10, so it have above commit.

> Then again, rx51 has tv-output, which probably gets probed
> early. So omapfb does see one functional display, and starts,
> even if the LCD is not available yet.
> 
> > (Actually, do we know which commit broke the ordering? We
> > may want to simply revert that one...)
> 
> Well, my understand that this is how it's supposed to work.
> There's no defined order with the driver probes, and the
> drivers just have to deal with their dependencies not being
> there yet.
> 
> I don't have a perfect solution for this problem for omapfb.
> omapfb doesn't support dynamically adding displays, so all
> the displays it uses have to be probed before omapfb. And
> omapfb doesn't know which displays will be probed.
> 
> The patch below was added for 3.11. Does it fix the issue for
> you? Perhaps it should be added for 3.10 also.
> 
>  Tomi
> 

I tested patch below and it fixing our problem too. So it could be 
added to 3.10.

> commit e9f322b4913e5d3e5c5d21dc462ca6f8a86e1df1
> Author: Tomi Valkeinen <tomi.valkeinen@...com>
> Date:   Thu May 23 16:41:25 2013 +0300
> 
>     OMAPFB: use EPROBE_DEFER if default display is not present
> 
>     Currently omapfb returns EPROBE_DEFER if no displays have
> been probed at the time omapfb is probed. However, sometimes
> some of the displays have been probed at that time, but not
> all. We can't return EPROBE_DEFER in that case, because then
> one missing driver would cause omapfb to defer always,
> preventing any display from working.
> 
>     However, if the user has defined a default display, we can
> presume that the driver for that display is eventually
> loaded. Thus, this patch changes omapfb to return
> EPROBE_DEFER in case default display is not found.
> 
>     Signed-off-by: Tomi Valkeinen <tomi.valkeinen@...com>
> 
> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
> b/drivers/video/omap2/omapfb/omapfb-main.c index
> 528e453..27d6905 100644
> --- a/drivers/video/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> @@ -2503,7 +2503,7 @@ static int omapfb_probe(struct
> platform_device *pdev)
> 
>         if (def_display == NULL) {
>                 dev_err(fbdev->dev, "failed to find default
> display\n"); -               r = -EINVAL;
> +               r = -EPROBE_DEFER;
>                 goto cleanup;
>         }

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)