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]

Message-ID: <CAGETcx-UgSCn9V5W0EgOBbdNGxsXR+ZGPNLL1MMJfHN35WCLRw@mail.gmail.com>
Date:   Wed, 19 May 2021 14:29:48 -0700
From:   Saravana Kannan <saravanak@...gle.com>
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, mripard@...nel.org, 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 1:29 AM Ondřej Jirman <megous@...ous.com> 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.

Nothing in sun8i_hdmi_phy_probe() depends on anything from
sun8i_dw_hdmi.c other than getting a struct device pointer to use with
dev_err and some devm_* APIs. So it seems pretty straightforward to
fix this so that you don't have one struct device trying to represent
two distinct hardware blocks. What am I missing?

Anyway, I took a swing at fixing this while preserving the ordering of
the important bits. The changes are fairly trivial/straightforward and
not meant to be final code, but can you test this out please?

-Saravana

Download attachment "0001-Try-fixing-HDMI-probe.patch" of type "application/x-patch" (4440 bytes)