Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp3944259imc; Thu, 14 Mar 2019 08:42:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqxQBpgVVvS6mJxO4gG+EfbJFeM7VLaBVTwB5DskvbI/g6FoLwMkZfdmgMrrXAS10FkG5aH/ X-Received: by 2002:a17:902:6b81:: with SMTP id p1mr52849988plk.106.1552578161538; Thu, 14 Mar 2019 08:42:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552578161; cv=none; d=google.com; s=arc-20160816; b=0ptI1lJ1QTYXBO9PoCcvwDdZOeM+Z/Fmu+C57cKUu9mG3mXsTBcdGQdLSj9O2+igqn i/htE9IQmMtkDo5YeZJro69jra5RBM0/tF6IUVai0QMyz3TVbmNJYP8KVm9rWgENsGR5 KOO0Vx3vcGVOWTYI5OI2XC1JGgxuF/Gf4wV0hdEPFDNQvIQkP1ZTP5VhWVMJxPhcmtWz jbHNuld6j7IcKZ/PEQpEus+G91JdP3bjTGxzgY/Yysj+ZfhyyV0Ch1+3qeZJG360DdNX 0KmA+Z5mO76F1SxyfUH9z5IUJGM9H96dte+3X3kDGDf9EIXRnGs+rQJQBDq5MBjFjVBt vjZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=HEsH84MdKmHlkyTUc8zOxai7e6PCdj9+CQbI9DDQNtI=; b=SHH4Ae2Ffbr8Fh6EbcDC69x1+SxXFqRKQ5wRsWZbtq+51O/Wjt2lEAugBC39tJejSG xsp8edHPGqPyoz+R5jx0KT7e2Ml2EVgCEd6fIH2s2uMGTml08+viE8rGxsWPOgeQ+9vO zbdWq6F8dH9gnkVlmyjdQtJM6vhh1Fbe/mem+ezRWw0zRy9GeN1zlVIVI4qlNNZwSvOs xs+7sxrDqUtlPWa3lz2fnNnxH3CP95XAm9YQunvnv0HgA9sT2KlBW+cvK4HB5cpEF9+W SOupIZrcrg9b7M2plPBiJJr74oeab8gAMKWhmf3Zu6M4kWujAN3/6kViBFVyQgLLwY9z KZ5g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 65si8969636plf.288.2019.03.14.08.42.26; Thu, 14 Mar 2019 08:42:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727222AbfCNPlP (ORCPT + 99 others); Thu, 14 Mar 2019 11:41:15 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:41673 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726155AbfCNPlJ (ORCPT ); Thu, 14 Mar 2019 11:41:09 -0400 X-Originating-IP: 185.94.189.187 Received: from localhost (unknown [185.94.189.187]) (Authenticated sender: maxime.ripard@bootlin.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 39DC060007; Thu, 14 Mar 2019 15:41:06 +0000 (UTC) Date: Thu, 14 Mar 2019 16:41:05 +0100 From: Maxime Ripard To: =?utf-8?B?TcOlbnMgUnVsbGfDpXJk?= Cc: David Airlie , Chen-Yu Tsai , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/sun4i: hdmi: add support for ddc-i2c-bus property Message-ID: <20190314154105.o6r7hzeuiyajxh7v@flea> References: <20190311134713.25876-1-mans@mansr.com> <20190311154702.eslw5ccol44vxcmy@flea> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gcsodpgszpjlaeow" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --gcsodpgszpjlaeow Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 11, 2019 at 04:11:06PM +0000, M=E5ns Rullg=E5rd wrote: > Maxime Ripard writes: >=20 > > Hi! > > > > On Mon, Mar 11, 2019 at 01:47:13PM +0000, Mans Rullgard wrote: > >> Sometimes it is desirabled to use a separate i2c controller for ddc > >> access. This adds support for the ddc-i2c-bus property of the > >> hdmi-connector node, using the specified controller if provided. > >>=20 > >> Signed-off-by: Mans Rullgard > >> --- > >> drivers/gpu/drm/sun4i/sun4i_hdmi.h | 1 + > >> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 37 +++++++++++++++++++++++--- > >> 2 files changed, 35 insertions(+), 3 deletions(-) > >>=20 > >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h b/drivers/gpu/drm/sun4= i/sun4i_hdmi.h > >> index b685ee11623d..b08c4453d47c 100644 > >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h > >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h > >> @@ -269,6 +269,7 @@ struct sun4i_hdmi { > >> struct clk *tmds_clk; > >> =20 > >> struct i2c_adapter *i2c; > >> + struct i2c_adapter *ddc_i2c; > >> =20 > >> /* Regmap fields for I2C adapter */ > >> struct regmap_field *field_ddc_en; > >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/= sun4i/sun4i_hdmi_enc.c > >> index 061d2e0d9011..5b2fac79f5d6 100644 > >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c > >> @@ -212,7 +212,7 @@ static int sun4i_hdmi_get_modes(struct drm_connect= or *connector) > >> struct edid *edid; > >> int ret; > >> =20 > >> - edid =3D drm_get_edid(connector, hdmi->i2c); > >> + edid =3D drm_get_edid(connector, hdmi->ddc_i2c ?: hdmi->i2c); > > > > You can't test whether ddc_i2c is NULL or not... > > > >> if (!edid) > >> return 0; > >> =20 > >> @@ -228,6 +228,28 @@ static int sun4i_hdmi_get_modes(struct drm_connec= tor *connector) > >> return ret; > >> } > >> =20 > >> +static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device *dev) > >> +{ > >> + struct device_node *phandle, *remote; > >> + struct i2c_adapter *ddc; > >> + > >> + remote =3D of_graph_get_remote_node(dev->of_node, 1, -1); > >> + if (!remote) > >> + return ERR_PTR(-EINVAL); > >> + > >> + phandle =3D of_parse_phandle(remote, "ddc-i2c-bus", 0); > >> + of_node_put(remote); > >> + if (!phandle) > >> + return NULL; > >> + > >> + ddc =3D of_get_i2c_adapter_by_node(phandle); > >> + of_node_put(phandle); > >> + if (!ddc) > >> + return ERR_PTR(-EPROBE_DEFER); > >> + > >> + return ddc; > > > > ... Since even in (most) error cases you're returning a !NULL pointer. > > > >> +} > >> + > >> static const struct drm_connector_helper_funcs sun4i_hdmi_connector_h= elper_funcs =3D { > >> .get_modes =3D sun4i_hdmi_get_modes, > >> }; > >> @@ -575,6 +597,12 @@ static int sun4i_hdmi_bind(struct device *dev, st= ruct device *master, > >> goto err_disable_mod_clk; > >> } > >> =20 > >> + hdmi->ddc_i2c =3D sun4i_hdmi_get_ddc(dev); > >> + if (IS_ERR(hdmi->ddc_i2c)) { >=20 > ... which is checked here. >=20 > The property is optional, so the idea was to return null in that case > and use the built-in controller. If the property exists but some error > occurs, we want to abort rather than proceed with the fallback which > almost certainly won't work. >=20 > Maybe I got something wrong in that logic. Indeed, I just got confused. I guess returning ENODEV in such a case, and testing for that, would make things more obvious. Thanks! Maxime --=20 Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --gcsodpgszpjlaeow Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXIp2EQAKCRDj7w1vZxhR xR1OAP4mtqKak2Z+ossjeOc/6kSQh38FJZCy/a/pcnxdFSn/vQD/cE0OB64w/N0M mGX4nyIM1UeXSQqR5DM3ppOYCbGYlAo= =mQ5p -----END PGP SIGNATURE----- --gcsodpgszpjlaeow--