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 X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F34CC2B9F4 for ; Sat, 19 Jun 2021 20:51:44 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1A0F261159 for ; Sat, 19 Jun 2021 20:51:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A0F261159 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 31CF081FD5; Sat, 19 Jun 2021 22:51:40 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="rkEnXD/b"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C0DA382B20; Sat, 19 Jun 2021 22:51:37 +0200 (CEST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 5393F81FD5 for ; Sat, 19 Jun 2021 22:51:34 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf34.google.com with SMTP id k9so5421049qvu.13 for ; Sat, 19 Jun 2021 13:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=5XS980I/6ySUDvq4yaYlbJeC+lJAATXZLUYns+juRNA=; b=rkEnXD/bYMYVy3L69eZBCbCIG1uE/7cZIIEZZP2RfCffm74340ivnsVkdMPBYOgETX Vlc58lreBK50O91J7K1qz3EaHNkE7FL+c7PA5KexOyZD8Nu9vvfuCCghhcF83vi6dVvC WkpKPLsXHnneeG9wvXbqju6mAlsRrnUDhndpk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=5XS980I/6ySUDvq4yaYlbJeC+lJAATXZLUYns+juRNA=; b=LKCawWm2/J8xu2a2b598fnG7Zxj4Gguc2ijtJRlfl/f3ajUCbimrAQ9bKPctfD97+s vnkPt4kA1B1fe6vA57jljXdYslclAgNXEAbNtnsSnH2eTpdTX4gdfEBKYAvhldq+YqNR Oh4eIX+c8V9jTzPJvu97hmXUWnm0U7DTZrTl4IxOWocwMtppOaBdJ6SegT1FKUsw4LH1 83wvWwovTMy0Oa1nG2IBKHAr3ca6/k8GcwbWqF7ahVhXk4yS+03NrwEC0VqxZXJuIax6 8FSxc9Bf5yyq+s09P9Hxos5QBh+GPD/nOq1sRopElM7vtptC0BWs6s0+FOM+mNNP7qVn ncvA== X-Gm-Message-State: AOAM533NrMbmS6Jirlky6/yqdYGuWqhTqxi/pMFwRTvP1rMgsBzR3H67 Vll2oL1MYmfvT2LSDiiRKcHuvQ== X-Google-Smtp-Source: ABdhPJwWTFExD36RRSeWthHVPl0m++CBUR7jAcTpIHnW98oauz7ZBSq7rKyIA4ti3xkoAUZA9h/Vew== X-Received: by 2002:a0c:fb12:: with SMTP id c18mr7501012qvp.40.1624135892975; Sat, 19 Jun 2021 13:51:32 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-78ca-7b54-f591-7b8a.res6.spectrum.com. [2603:6081:7b01:cbda:78ca:7b54:f591:7b8a]) by smtp.gmail.com with ESMTPSA id f193sm6731325qke.43.2021.06.19.13.51.31 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sat, 19 Jun 2021 13:51:31 -0700 (PDT) Date: Sat, 19 Jun 2021 16:51:29 -0400 From: Tom Rini To: Ivaylo Dimitrov Cc: Marek Vasut , Pali =?iso-8859-1?Q?Roh=E1r?= , Lokesh Vutla , Simon Glass , Merlijn Wajer , u-boot@lists.denx.de, Pavel Machek Subject: Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL Message-ID: <20210619205129.GA9516@bill-the-cat> References: <20210618145724.2558-1-pali@kernel.org> <20210618163812.GR9516@bill-the-cat> <3c44a3cf-b9ad-1b31-d0a4-54c896222d78@gmail.com> <0a8a9dab-ee44-fab7-d712-d66cb121c170@gmail.com> <249e8e4f-b5f7-1f97-adbd-a83d75883ef4@denx.de> <338bfdad-15f6-fbff-6fde-d0411e585bf4@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Cvw9JPw5vn6N7Cjk" Content-Disposition: inline In-Reply-To: <338bfdad-15f6-fbff-6fde-d0411e585bf4@gmail.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean --Cvw9JPw5vn6N7Cjk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 19, 2021 at 11:15:50PM +0300, Ivaylo Dimitrov wrote: >=20 >=20 > On 19.06.21 =D0=B3. 22:38 =D1=87., Marek Vasut wrote: > > On 6/19/21 9:33 PM, Ivaylo Dimitrov wrote: > > > Hi, > >=20 > > Hi, > >=20 > > > > > > > > Currently DM_USB requires OF_CONTROL to be > > > > > > > > enabled, otherwise link errors > > > > > > > > occur. On the other hand OF_CONTROL requires > > > > > > > > board code to be migrated to > > > > > > > > DT, which is not always possible or required. > > > > > > > >=20 > > > > > > > > Fix that by conditionally compiling OF_CONTROL > > > > > > > > specific sections in USB > > > > > > > > related drivers code in the same way like it is > > > > > > > > done in the other drivers. > > > > > > > > Also, auto select OF_LIBFDT if DM_USB is > > > > > > > > selected but OF_CONTROL is not. > > > > > > > > Introduce a new Kconfig option OF_NODE used to > > > > > > > > compile of_node.c in case > > > > > > > > OF_CONTROL is not enabled. Fix deprecation > > > > > > > > warning condition as well. > > > > > >=20 > > > > > > So, what is the use case of this? Why not just enable > > > > > > DM_USB and OF_CONTROL ? > > > > >=20 > > > > > OF_CONTROL requires migration to device-tree. > > > >=20 > > > > That's where the supported platforms are heading anyway. Or is > > > > there some issue with switching the platform you use over to DT > > > > ? > > >=20 > > > OK, let me elaborate: It is about enabling DM_USB on N900 (Nokia > > > rx-51 board). For various reasons I am not going to discuss (1), > > > migration to DM was delayed to the point where we saw "[PATCH] arm: > > > Remove nokia_rx51 board" with a commit message "This board has not > > > been converted to CONFIG_DM_USB by the deadline. Remove it." posted. > > > The missing pieces were WDT (a patch is already merged in -next) and > > > DM_USB. The board itself does not support host mode, but USB TTY is > > > very useful for debugging purposes. The particular task I am after > > > is USB DM migration and the $subject patch allows this to be > > > achieved with relatively little effort (a couple of defconfig > > > changes), incomparable with the effort needed for migration to DT. > > > As we are already past the DM migration deadline I think it makes > > > sense to fulfil its requirements before undertaking such a big task > > > like migration to DT. > >=20 > > This sounds like a workaround though. Can you instead do the full > > conversion of the board? I am sure the board removal patch can be > > postponed if there is plan to convert it. >=20 > Hard to say if migration to device-tree is even possible on N900 ATM, > enabling OF_CONTROL increases the size of the produced binary with some 1= 00k > (.dtb not included), making the size of the binary way above our budget of > ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51 > suffers from ARM errata 430973 and noone can guarantee we're not going to > see SIGILL faults if we enable it. Which it seems we are forced to do even > with DM_USB migration only. Note that yes, it should be safe to enable thumb mode, but run time confirmation would be good. > Re workaround - I took examples of #ifdef's from the current u-boot code > (mmc, i2c, etc.) so workaround or not, it is no different to what the oth= er > drivers are doing. >=20 > I don't really understand where this requirement to convert to DTS comes > from - will boards that are not converted be removed at some point? When = is > that deadline if exists? If there is no such deadline, why shall we spend > who knows how many hours just because "you know, it sounds like a good id= ea > to convert to DTS"? You understand this is not a trivial task and given t= he > pace rx-51 patches were reviewed lately, it will easily take 2 years to do > that conversion. >=20 > To sum it up - maybe I can do a full DTS migration, but I don't see a poi= nt > in doing it ATM. The $subject patch allows rx-51 to be fully migrated to = DM > and does nothing different to what already is done all over the place. So, there are deadlines for migration to device model. The argument being put forth by the Nokia RX51 folks is that to quote include/dm/platdata.h (and yes, they aren't using U_BOOT_DRVINFO in this case, but...): /** * NOTE: Avoid using these except in extreme circumstances, where device tr= ee * is not feasible (e.g. serial driver in SPL where <8KB of SRAM is * available). U-Boot's driver model uses device tree for configuration. * * When of-platdata is in use, U_BOOT_DRVINFO() cannot be used outside of t= he * dt-plat.c file created by dtoc */ that's them, and it's not an SPL case but full U-Boot and a fixed size amount of the flash that they can use, no arguing. So we need to make changes in subsystems they use so that they can continue to work. So, are the changes being proposed to the generic USB code, such that DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note, that's not set yet, but that's not to say never, it's just not been set, so getting ahead of problems here would be appreciated) that can also be enabled, OK? --=20 Tom --Cvw9JPw5vn6N7Cjk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmDOWM4ACgkQFHw5/5Y0 tyxMQAv7BE/HbtyST3ugM8sMVCgeP6Ek1G62N9WEmmw8kHgK1yc7v4JkSl5/xrqM Xaj3OQ18cJWgjCgo605sPiEpitYLL2pDZUeCjXlScEvpBHNvWE1Mt5CBpD4hNSV7 dPN92S5M6hYLv2GG690ke9Vq+/XWXjBIgpGCMVkFjOzHqUMOmGS+tfoayEt2Ltvd io7bWFNSebK+Zak/pprox160UpL8e8j18YX2raiJhw1+y/ipEH1y0idUdxVeJibh Y+Xkl+b3jPX1Onf8QdamN7p6el4jBwti3/TJ4KWx8YyXu47Bk4g5j7X7eGmSpoXx wTC9D/Hp2pLb4WmVsMfUEJBa0mkmUm+qNtPs/VDH9twuieJvnqkXdBp7f1ql+7Et GTUUe/Gd2tWKMYjqdZmCg5EYnrAakGw5pv7HflhgrXNrLjzqSLuJZuP6YnSvJqFr 1pQ4Z/cQGSKOM1qz7P7B9A25Qm8gtAGt5qDkUYMG2HlvzonJO31vIKrwW/H7iHfl 8NfCqE3k =boS7 -----END PGP SIGNATURE----- --Cvw9JPw5vn6N7Cjk--