linux-kernel - Re: [PATCH 5/7] phy: qcom-qmp-combo: Introduce drm

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: <20230504031354.GE870858@hu-bjorande-lv.qualcomm.com>
Date:   Wed, 3 May 2023 20:13:54 -0700
From:   Bjorn Andersson <quic_bjorande@...cinc.com>
To:     Johan Hovold <johan@...nel.org>
CC:     Vinod Koul <vkoul@...nel.org>,
        Kishon Vijay Abraham I <kishon@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-phy@...ts.infradead.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/7] phy: qcom-qmp-combo: Introduce drm_bridge

On Tue, May 02, 2023 at 02:05:53PM +0200, Johan Hovold wrote:
> On Mon, Apr 24, 2023 at 08:40:08PM -0700, Bjorn Andersson wrote:
> > The QMP combo PHY sits in an of_graph connected between the DisplayPort
> > controller and a USB Type-C connector (or possibly a redriver).
> > 
> > The TCPM needs to be able to convey the HPD signal to the DisplayPort
> > controller, but no directly link is provided by DeviceTree so the signal
> > needs to "pass through" the QMP combo phy.
> > 
> > Handle this by introducing a drm_bridge which upon initialization finds
> > the next bridge (i.e. the usb-c-connector) and chain this together. This
> > way HPD changes in the connector will propagate to the DisplayPort
> > driver.
> > 
> > The connector bridge is resolved lazily, as the TCPM is expected to be
> > able to resolve the typec mux and switch at probe time, so the QMP combo
> > phy will probe before the TCPM.
> > 
> > Signed-off-by: Bjorn Andersson <quic_bjorande@...cinc.com>
> > ---
> >  drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 36 +++++++++++++++++++++++
> >  1 file changed, 36 insertions(+)
> > 
> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> > index 5d6d6ef3944b..84bc08002537 100644
> > --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> > @@ -22,6 +22,8 @@
> >  #include <linux/usb/typec.h>
> >  #include <linux/usb/typec_mux.h>
> >  
> > +#include <drm/drm_bridge.h>
> > +
> >  #include <dt-bindings/phy/phy-qcom-qmp.h>
> >  
> >  #include "phy-qcom-qmp.h"
> > @@ -1332,6 +1334,8 @@ struct qmp_combo {
> >  	struct clk_hw dp_link_hw;
> >  	struct clk_hw dp_pixel_hw;
> >  
> > +	struct drm_bridge bridge;
> > +
> >  	struct typec_switch_dev *sw;
> >  	enum typec_orientation orientation;
> >  };
> > @@ -3196,6 +3200,34 @@ static int qmp_combo_register_clocks(struct qmp_combo *qmp, struct device_node *
> >  	return devm_add_action_or_reset(qmp->dev, phy_clk_release_provider, dp_np);
> >  }
> >  
> > +static int qmp_combo_bridge_attach(struct drm_bridge *bridge,
> > +				   enum drm_bridge_attach_flags flags)
> > +{
> > +	struct qmp_combo *qmp = container_of(bridge, struct qmp_combo, bridge);
> > +	struct drm_bridge *next_bridge;
> > +
> > +	if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
> > +		return -EINVAL;
> > +
> > +	next_bridge = devm_drm_of_get_bridge(qmp->dev, qmp->dev->of_node, 0, 0);
> > +	if (IS_ERR(next_bridge))
> > +		return dev_err_probe(qmp->dev, PTR_ERR(next_bridge), "failed to acquire drm_bridge\n");
> 
> Using dev_err_probe() in an attach callback looks wrong as these
> functions should not be returning -EPROBE_DEFER (and this is not a probe
> function).
> 

The problem is that this might return EPROBE_DEFER, and at least today
propagates out to returning EPROBE_DEFER from our DP controller's
bind().

This is not optimal, but unfortunately we have a two way dependency
across the of_graph, so we need to make one of the sides lazy...

> > +
> > +	return drm_bridge_attach(bridge->encoder, next_bridge, bridge, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> 
> This line is over 100 chars, but there should be no reason not to break
> it before 80 here.
> 
> > +}
> > +
> > +static const struct drm_bridge_funcs qmp_combo_bridge_funcs = {
> > +	.attach	= qmp_combo_bridge_attach,
> > +};
> > +
> > +static int qmp_combo_dp_register_bridge(struct qmp_combo *qmp)
> > +{
> > +	qmp->bridge.funcs = &qmp_combo_bridge_funcs;
> > +	qmp->bridge.of_node = qmp->dev->of_node;
> > +
> > +	return devm_drm_bridge_add(qmp->dev, &qmp->bridge);
> > +}
> 
> Guess you need a dummy function also for qmp_combo_dp_register_bridge()
> in case of !CONFIG_DRM.
> 

Right, missed that dependency. Will wrap this and provide a dummy.

Thanks,
Bjorn

> > +
> >  static int qmp_combo_parse_dt_lecacy_dp(struct qmp_combo *qmp, struct device_node *np)
> >  {
> >  	struct device *dev = qmp->dev;
> > @@ -3459,6 +3491,10 @@ static int qmp_combo_probe(struct platform_device *pdev)
> >  	if (ret)
> >  		return ret;
> >  
> > +	ret = qmp_combo_dp_register_bridge(qmp);
> > +	if (ret)
> > +		return ret;
> > +
> >  	/* Check for legacy binding with child nodes. */
> >  	usb_np = of_get_child_by_name(dev->of_node, "usb3-phy");
> >  	if (usb_np) {
> 
> Johan