From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 98EEEC04A68 for ; Wed, 27 Jul 2022 17:18:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=A1g8wsK4l/BcOG6Z+09Ma2Xcug/DrxLZ+l3g6ev0BOE=; b=kIAM1UpO3K8AGURKjMy53ypjjd /WSEKaFcGitdk/jLal99Au261M876yfeKSq0Vs6a31z+/faxXVTJ1D7S8UyXgXe+a+kE2GbQiTSCl n/qylkglA8W29A9rKobL5sDqHbjpKLst5sURXys2rSv1ZMqjXBnUmKhHFRZwUjClzrN3fGdNeEZ9u 7AgapRSKMcF17gc5GvjdlHvcYGjMvOb8mokwHMZJgIub1SEY8MQ55V1a4Q4Szbi+Gvd5Nxjrdcskv 586hEDlBTHa40AjM92sdxnB8HeFr3hYzGPYjrcFAf+/63azW5dDR5HweJyoe/4mDj2/ug6cMCoT9p WYFrb8NQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGkf4-00G09w-UI; Wed, 27 Jul 2022 17:17:31 +0000 Received: from relay1-d.mail.gandi.net ([217.70.183.193]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGkf0-00G05I-8n for linux-arm-kernel@lists.infradead.org; Wed, 27 Jul 2022 17:17:28 +0000 Received: (Authenticated sender: paul.kocialkowski@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id BBFC7240008; Wed, 27 Jul 2022 17:17:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1658942240; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pD+6JsLJZ79rYHRmRP+N5CK2RU/2PPAI0GVGYlpGjrI=; b=MHkMXCFzwyOhigfD3fOn/vHnUXWQXKZE5lLCgbSY5U8ix16n/ghnZwBhOS+nVxy+zcd+YN xh2QTLt6dA0cersxQauh43bC5S5ngrf5x7/qiIb1WaMuZKUlzVkvb7PBPbmWhBxLiMVUxh 4vs3wo7kGjJTOvyzsbgyvSyzTnCsjcPkaJ9ir6lo1FIHgqCXrqYJJWMBzDVP46DKWB/KiA S1ScOD4yFDYf4mWZmcX8xXjEeD6XeU11fhenGaq4gmuMlYH02ehjR6RSXRS/Pt0h7mrx3V BqNqd25Nx4wU99qo0qnilMKa2h9JHH++LS03z8YvKbw3F90k0scqinCZzjnxYw== Date: Wed, 27 Jul 2022 19:17:15 +0200 From: Paul Kocialkowski To: Saravana Kannan Cc: Maxime Ripard , Rob Herring , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Michael Turquette , Stephen Boyd , Frank Rowand , Laurent Pinchart , Thomas Petazzoni Subject: Re: [PATCH RFC v3 1/8] of: Mark interconnects property supplier as optional Message-ID: References: <20220302211100.65264-1-paul.kocialkowski@bootlin.com> <20220302211100.65264-2-paul.kocialkowski@bootlin.com> <20220727120631.iefzititedahdsdt@houat> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220727_101726_919106_FB7006E6 X-CRM114-Status: GOOD ( 39.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7576326560394870757==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============7576326560394870757== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YI4hFKeTpPz6LydI" Content-Disposition: inline --YI4hFKeTpPz6LydI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed 27 Jul 22, 09:06, Saravana Kannan wrote: > On Wed, Jul 27, 2022 at 5:06 AM Maxime Ripard wrote: > > > > Hi, > > > > On Mon, Mar 07, 2022 at 07:34:22PM -0800, Saravana Kannan wrote: > > > On Mon, Mar 7, 2022 at 3:21 PM Rob Herring wrote: > > > > > > > > +Saravana > > > > > > > > On Wed, Mar 02, 2022 at 10:10:53PM +0100, Paul Kocialkowski wrote: > > > > > In order to set their correct DMA address offset, some devices re= ly on > > > > > the device-tree interconnects property which identifies an > > > > > interconnect node that provides a dma-ranges property that can be= used > > > > > to set said offset. > > > > > > > > > > Since that logic is all handled by the generic openfirmware and d= river > > > > > code, the device-tree description could be enough to properly set > > > > > the offset. > > > > > > > > > > However the interconnects property is currently not marked as > > > > > optional, which implies that a driver for the corresponding node > > > > > must be loaded as a requirement. When no such driver exists, this > > > > > results in an endless EPROBE_DEFER which gets propagated to the > > > > > calling driver. This ends up in the driver never loading. > > > > > > > > > > Marking the interconnects property as optional makes it possible > > > > > to load the driver in that situation, since the EPROBE_DEFER retu= rn > > > > > code will no longer be propagated to the driver. > > > > > > > > > > There might however be undesirable consequences with this change, > > > > > which I do not fully grasp at this point. > > > > > > Temporary NACK till I get a bit more time to take a closer look. I > > > really don't like the idea of making interconnects optional. IOMMUs > > > and DMAs were exceptions. Also, we kinda discuss similar issues in > > > LPC. We had some consensus on how to handle these and I noted them all > > > down with a lot of details -- let me go take a look at those notes > > > again and see if I can send a more generic patch. > > > > > > Paul, > > > > > > Can you point to the DTS (not DTSI) file that corresponds to this? > > > Also, if it's a builtin kernel, I'd recommend setting > > > deferred_probe_timeout=3D1 and that should take care of it too. > > > > For the record, I also encountered this today on next-20220726 with this > > device: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree= /arch/arm/boot/dts/sun5i.dtsi#n775 > > > > The driver won't probe without fw_devlink=3Doff >=20 > Really? I basically ended up doing what I mentioned in my original > reply. next-20220726 should have my changes that'll make sure > fw_devlink doesn't block any probe (it'll still try to create as many > device links as possible) after 10s (default deferred probe timeout). > Can you try to find more info on why it's not probing? > /devices_deferred should give more details. By the way last time I checked the initial issue that I reported appeared t= o be fixed by the patch (Extend deferred probe timeout on driver registration). Cheers, Paul --=20 Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com --YI4hFKeTpPz6LydI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJZpWjZeIetVBefti3cLmz3+fv9EFAmLhcxsACgkQ3cLmz3+f v9FD3Qf/f9BJLCBNeLkg1/FJs/uq8AROdDgAOOIp6h0jojREfp9mzOJZLiwolT2a cibrCYabq1rvssN9wI0S5i57IRa3ZcUEdZTu8th5zLPMKv96o0iFcp0DjoAQ1K2A mvhRcdI7q6tFhAEMoDbJjmRg1qCpCMpVmW0B+PQcafq5K2y0TpnxLjeEUdRrmjxY M8Ddn1Ui6Ymne0Rj3Io4f4jxDIm5WQTFk+iYA6OcaA490loeYI9CfvCqx8NDyJF+ 1e92FYkmpTyvgi48Diqs2k7VGooJ1pjsMVYqlFAtz3DYFUh/i/nCaVAk6RNOicqU Dz0DKgon9pUOsbZjFCSd6jiWpjTu9Q== =ncXW -----END PGP SIGNATURE----- --YI4hFKeTpPz6LydI-- --===============7576326560394870757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============7576326560394870757==--