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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170206173407.GK27312@n2100.armlinux.org.uk>
Date:   Mon, 6 Feb 2017 17:34:07 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Liviu Dudau <liviu.dudau@....com>
Cc:     Rob Herring <robh@...nel.org>, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Sean Paul <seanpaul@...omium.org>,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Frank Rowand <frowand.list@...il.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Archit Taneja <architt@...eaurora.org>,
        Jingoo Han <jingoohan1@...il.com>,
        Inki Dae <inki.dae@...sung.com>,
        Joonyoung Shim <jy0922.shim@...sung.com>,
        Seung-Woo Kim <sw0312.kim@...sung.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        Kukjin Kim <kgene@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Stefan Agner <stefan@...er.ch>,
        Alison Wang <alison.wang@...escale.com>,
        Xinliang Liu <z.liuxinliang@...ilicon.com>,
        Rongrong Zou <zourongrong@...il.com>,
        Xinwei Kong <kong.kongxinwei@...ilicon.com>,
        Chen Feng <puck.chen@...ilicon.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        CK Hu <ck.hu@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Marek Vasut <marex@...x.de>,
        Mark Yao <mark.yao@...k-chips.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Mali DP Maintainers <malidp@...s.arm.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Carlo Caione <carlo@...one.org>,
        Kevin Hilman <khilman@...libre.com>,
        Rob Clark <robdclark@...il.com>, Jyri Sarha <jsarha@...com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Eric Anholt <eric@...olt.net>
Subject: Re: [PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node

On Mon, Feb 06, 2017 at 05:23:06PM +0000, Liviu Dudau wrote:
> On Mon, Feb 06, 2017 at 11:09:49AM -0600, Rob Herring wrote:
> > On Mon, Feb 06, 2017 at 10:29:33AM +0000, Liviu Dudau wrote:
> > > On Fri, Feb 03, 2017 at 09:36:33PM -0600, Rob Herring wrote:
> > > > -	/* add the remote encoder port as component */
> > > > -	port = of_graph_get_remote_port_parent(ep);
> > > > -	of_node_put(ep);
> > > > -	if (!port || !of_device_is_available(port)) {
> > > > -		of_node_put(port);
> > > > -		return -EAGAIN;
> > > 
> > > The HDLCD change looks reasonable except for this -EAGAIN business. I'll have to
> > > test your changes on my setup to see how this affects having the encoder as a module.
> > 
> > What are you expecting to happen with -EAGAIN? This one was a bit of an 
> > oddball.
> 
> When both the HDLCD and the TDA998x drivers are compiled as modules, the
> order in which they are inserted can be somewhat random (due to testing).

Not really "due to testing" but if you run a real distro, they tend to
have a multi-threaded behaviour when loading kernel modules at boot.

> It is at that time when you want the probe of HDLCD to be retried on the
> insmod-ing of the tda998x.ko rather than fail entirely.

-EAGAIN doesn't get you that, and in any case, solving that problem is
exactly why the component API exists - so that DRM only comes up once
all the necessary components are available.

-EAGAIN also doesn't get you that from inside a probe function - such
an error will be reported in the kernel log, and no further action
will be taken (the device driver probe will be failed, and not
automatically retried.

The only case that we automatically retry is if a driver returns
-EPROBE_DEFER.  Everything else causes a probe failure.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ