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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 1FB49C433EF for ; Fri, 22 Apr 2022 12:20:51 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3B862836A9; Fri, 22 Apr 2022 14:20:49 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=nic.cz 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; secure) header.d=nic.cz header.i=@nic.cz header.b="F1hB98xt"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4C33383AE6; Fri, 22 Apr 2022 14:20:47 +0200 (CEST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 48E1483D39 for ; Fri, 22 Apr 2022 14:20:44 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=nic.cz Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=marek.behun@nic.cz Received: from thinkpad (unknown [172.20.6.87]) by mail.nic.cz (Postfix) with ESMTPS id B5169151166; Fri, 22 Apr 2022 14:20:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1650630043; bh=2ETrN8imVPwG5DFqBRxoe4Th0JRMj4eY8ysIcihQOQs=; h=Date:From:To:Cc:Subject:From; b=F1hB98xtxK4nNYoQEz4XiFwwQiq4sybNW9X4E9p3tO58IOIxaIguYboLcX813qcZA 7XlDO/BVqRRQfNpgHoJ3KY6om7ggUymfci2QT7kOo3nDFtXJjc5+DSrn4HkkpVbSwd q4gWK0JMcuaDZtlE3b5e72K8NnYPbjvhpYFVYcz4= Date: Fri, 22 Apr 2022 14:20:43 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Pali =?UTF-8?B?Um9ow6Fy?= Cc: Stefan Roese , u-boot@lists.denx.de Subject: Re: [PATCH u-boot-marvell 8/8] arm: mvebu: turris_omnia: Add support for USB3.0 mode in WWAN MiniPCIe slot Message-ID: <20220422142043.676fd6ed@thinkpad> In-Reply-To: <20220422114733.njko5bfbs3qfhmwm@pali> References: <20220302114758.21787-1-pali@kernel.org> <20220302114758.21787-9-pali@kernel.org> <20220302134607.69f4a36c@dellmb> <20220422114733.njko5bfbs3qfhmwm@pali> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.5 at phobos.denx.de X-Virus-Status: Clean On Fri, 22 Apr 2022 13:47:33 +0200 Pali Roh=C3=A1r wrote: > On Wednesday 02 March 2022 13:46:07 Marek Beh=C3=BAn wrote: > > On Wed, 2 Mar 2022 12:47:58 +0100 > > Pali Roh=C3=A1r wrote: > > =20 > > > PCIe Mini CEM 2.1 spec added support for USB3.0 mode on MiniPCIe card= s. > > > USB3.0 and PCIe share same pins and only one function can be active a= t the > > > same time. PCIe Mini CEM 2.1 spec says that determining function is > > > platform specific and spec does not define any dedicated pin which co= uld > > > say if card is USB3.0-based or PCIe-based. > > >=20 > > > Implement this platform specific decision (USB3.0 vs PCIe) for WWAN > > > MiniPCIe slot on Turris Omnia via U-Boot env variable "omnia_wwan_slo= t", > > > similarly like is implemented forced mode for MiniPCIe/mSATA slot via > > > "omnia_msata_slot" env variable. Value "usb3" for "omnia_wwan_slot" w= ould > > > mean to set USB3.0 mode and value "pcie" original PCIe mode. > > >=20 > > > A385 SoC on Turris Omnia has configurable fifth SerDes line (exported= to > > > MiniPCIe WWAN slot with SIM card) either to USB3.0 or PCIe functional= ity, > > > so implementation of this new PCIe Mini CEM 2.1 feature is simple, by= just > > > configuring SerDes to USB 3.0 mode. > > >=20 > > > Other twos MiniPCIe slots on Turris Omnia do not have this new > > > functionality as their SerDes lines cannot be switched to USB3.0 > > > functionality. > > >=20 > > > Note that A385 SoC does not have too many USB3.0 blocks, so activating > > > USB3.0 in MiniPCIe cause that one external USB3.0 USB-A port would lo= ose > > > USB3.0 functionality and would be downgraded just to USB2.0. > > >=20 > > > By default this MiniPCIe WWAN slot is in PCIe mode, like before. > > >=20 > > > To set this MiniPCIe WWAN slot to USB3.0 mode, call U-Boot commands: > > > =20 > > > =3D> setenv omnia_wwan_slot usb3 > > > =3D> saveenv > > > =3D> reset =20 > > >=20 > > > Signed-off-by: Pali Roh=C3=A1r > > > --- > > > board/CZ.NIC/turris_omnia/turris_omnia.c | 57 ++++++++++++++++++++++= ++ > > > 1 file changed, 57 insertions(+) > > >=20 > > > diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c b/board/CZ.NIC/= turris_omnia/turris_omnia.c > > > index e2f4daa827ed..83cfc80d1930 100644 > > > --- a/board/CZ.NIC/turris_omnia/turris_omnia.c > > > +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c > > > @@ -246,6 +246,22 @@ static bool omnia_detect_sata(const char *msata_= slot) > > > return stsword & MSATA_IND_STSBIT ? true : false; > > > } > > > =20 > > > +static bool omnia_detect_wwan_usb3(const char *wwan_slot) > > > +{ > > > + puts("WWAN slot configuration... "); > > > + > > > + if (wwan_slot && strcmp(wwan_slot, "usb3") =3D=3D 0) { > > > + puts("USB3.0\n"); > > > + return true; > > > + } > > > + > > > + if (wwan_slot && strcmp(wwan_slot, "pcie") !=3D 0) > > > + printf("unsupported env value '%s', fallback to... ", wwan_slot); = =20 > >=20 > > If I recall correctly, Linux' and U-Boot's code style (in contrast to > > TF-A) normally wants > > if (expr) instead of if (expr !=3D 0) > > and > > if (!expr) instead of if (expr =3D=3D 0) =20 >=20 > I guess that this applies for functions which return boolean value. And > not for strcmp() function which is not failure expression. But instead > it returns comparison value. Again, this was an unimportant nitpick from me, feel free to ignore this. But since you replied, I shall entertain you with an opinion I have to share. I am sure that I remember people from TF-A requesting to use (x =3D=3D 0) or (x !=3D 0), while people from Linux requesting (x) or (!x), not only for functions which return boolean value. I am not sure now for what kind of function it may have been exactly, but I think it was someting like err =3D func(); if (err =3D=3D 0) .. and the request was to change it to if (!err) I guess that functions which return 0 on success and negative error code on failure may be considered returning "boolean" in a sense of success/failure boolean. But anyway if seems that in the usage of strcmp(), Linux uses both variants, although the one with the comparison operator is used a little bit less: $ git grep 'strcmp' | wc -l 6971 $ git grep 'strcmp.* [=3D!]=3D 0' | wc -l 2100 Mostly the strcmp() function is used to determine whether two strings are equal or not, which is a binary/boolean decision, and so I prefer to check the result as such. But strcmp() can be also used to compare strings for sorting, and that is the case where =3D=3D, < and > operators would make sense to me. Again, feel free to ignore, since this is a matter of personal preference. Marek