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:   Mon, 17 May 2021 10:29:57 +0200
From:   Ondřej Jirman <megous@...ous.com>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     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 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.

regards,
	o.

> Thanks,
> Saravana
> 
> >
> > Where would be a good place to break that fwnode_link in code?
> >
> > Or can the fw_devlink code be made aware of this situation, where two fwnodes
> > are implemented by the same Linux device, somehow?
> >
> > Relevant references:
> >
> > https://elixir.bootlin.com/linux/v5.13-rc1/source/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c#L600
> > https://elixir.bootlin.com/linux/v5.13-rc1/source/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c#L212
> > https://elixir.bootlin.com/linux/v5.13-rc1/source/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#L1176
> >
> > kind regards,
> >         o.