linux-kernel - Re: fw_devlink=on and sunxi HDMI

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]

Date:   Tue, 18 May 2021 16:04:42 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Ondřej Jirman <megous@...ous.com>,
        Saravana Kannan <saravanak@...gle.com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-sunxi@...ts.linux.dev, wens@...e.org,
        jernej.skrabec@...il.com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, andre.przywara@....com
Subject: Re: fw_devlink=on and sunxi HDMI

On Mon, May 17, 2021 at 10:29:57AM +0200, Ondřej Jirman wrote:
> On Sun, May 16, 2021 at 11:32:47PM -0700, Saravana Kannan wrote:
> > On Sun, May 16, 2021 at 10:05 AM Ondřej Jirman <megi@....cz> wrote:
> > >
> > > Hello,
> > >
> > > Linux 5.13-rc1 again has fw_devlink=on enabled by default. I've found that this
> > > breaks probing display pipeline and HDMI output on sunxi boards, because of
> > > fwnode_link between hdmi and hdmi-phy nodes.
> > >
> > > HDMI device probe keeps being avoided with these repeated messages in dmesg:
> > >
> > >   platform 1ee0000.hdmi: probe deferral - supplier 1ef0000.hdmi-phy not ready
> > >
> > > Both nodes have their own compatible, but are implemented by a single
> > > struct device.
> > >
> > > This looks like a kind of situation that's expected to break fw_devlink
> > > expectations by my reading of the the e-mails about trying the fw_devlink=on
> > > during 5.12 cycle.
> > >
> > > Is this supposed to be solved by implementing the PHY node as it's own
> > > device or by breaking the fwnode_link between the hdmi phy and hdmi nodes?
> > > Seems like second solution would be quicker now that rc1 is out.
> > 
> > Seems like sun8i_hdmi_phy_probe() already does 95% of the work to make
> > the PHY a separate driver. Why not just finish it up by really making
> > it a separate driver? I'd really prefer doing that because this seems
> > unnecessarily messed up. The phy will have a struct device created for
> > it already. You are just not probing it.
> 
> Currently it's all just a glue code for dw-hdmi, which is not using a phy
> framework and handles both the controller and phy parts. dw-hdmi needs passing
> platform data around
> (https://elixir.bootlin.com/linux/latest/source/include/drm/bridge/dw_hdmi.h#L115)
> to get a specific set of phy glue callbacks hooked into platform data of dw-hdmi
> prior to calling dw_hdmi_probe.
> 
> Looking at other users of dw_hdmi_probe this is the only one that has this
> unfortunate issue due to using phys binding internally as a part of one device.
> 
> Just making it a platform driver will also change the probe order of phy and the
> controller, which I've heard from Jernej needs to have the current order of
> (controller and then phy) perserved, for some reason, and will make things
> still a bit more convoluted.
> 
> So this looks like needs quite a bit of thought.

Yep, and even if it was simple (which it really isn't), it wouldn't be
-rc* material.

Maxime

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