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 D23E0C433EF for ; Fri, 22 Apr 2022 11:47:48 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id EE8A183C70; Fri, 22 Apr 2022 13:47:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="W0Rhcpnq"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id EEF9783CF7; Fri, 22 Apr 2022 13:47:43 +0200 (CEST) Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) (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 E43CA83AE6 for ; Fri, 22 Apr 2022 13:47:40 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 40246CE28E5; Fri, 22 Apr 2022 11:47:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30E7DC385A0; Fri, 22 Apr 2022 11:47:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650628056; bh=y9UNrnD5ZhCmt1+SeyYxt1y6C6cuLzf4DED73PCkRyo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W0RhcpnqLD2u7JT2S/1wW80cpCsg1qDGjrqrUli9PDOqQGp8qHYXH8/awjf92TN2l jpV4HKiEi7EAaVAmIstle4iQfPyqeROzk3Du15G3gJNRuuGK3BMR9eqsyTw0o7D9Ri QAP6MnHPHCyPKMr33zMAGS33Dw9dx2FrEQkIQduyb+lqz6yCM0GdMvHgdkjEu6dngs /G2EEtWSqWJmlmV/bcqAXOZ1Wuux6tY6wsX96+JbFJaoze9ToV2rZ2Zek99ByEV56a IlL7sxghxrGUo6x6nQqvRzGuF7DTy4C7h1hS4wMmoq4inBk9z+iAgcvk7g+mNnGnTx RwKYNQ4bmKm7A== Received: by pali.im (Postfix) id 66BD9A09; Fri, 22 Apr 2022 13:47:33 +0200 (CEST) Date: Fri, 22 Apr 2022 13:47:33 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Marek =?utf-8?B?QmVow7pu?= 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: <20220422114733.njko5bfbs3qfhmwm@pali> References: <20220302114758.21787-1-pali@kernel.org> <20220302114758.21787-9-pali@kernel.org> <20220302134607.69f4a36c@dellmb> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220302134607.69f4a36c@dellmb> User-Agent: NeoMutt/20180716 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 Wednesday 02 March 2022 13:46:07 Marek Behún wrote: > On Wed, 2 Mar 2022 12:47:58 +0100 > Pali Rohár wrote: > > > PCIe Mini CEM 2.1 spec added support for USB3.0 mode on MiniPCIe cards. > > USB3.0 and PCIe share same pins and only one function can be active at 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 could > > say if card is USB3.0-based or PCIe-based. > > > > Implement this platform specific decision (USB3.0 vs PCIe) for WWAN > > MiniPCIe slot on Turris Omnia via U-Boot env variable "omnia_wwan_slot", > > similarly like is implemented forced mode for MiniPCIe/mSATA slot via > > "omnia_msata_slot" env variable. Value "usb3" for "omnia_wwan_slot" would > > mean to set USB3.0 mode and value "pcie" original PCIe mode. > > > > A385 SoC on Turris Omnia has configurable fifth SerDes line (exported to > > MiniPCIe WWAN slot with SIM card) either to USB3.0 or PCIe functionality, > > so implementation of this new PCIe Mini CEM 2.1 feature is simple, by just > > configuring SerDes to USB 3.0 mode. > > > > Other twos MiniPCIe slots on Turris Omnia do not have this new > > functionality as their SerDes lines cannot be switched to USB3.0 > > functionality. > > > > 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 loose > > USB3.0 functionality and would be downgraded just to USB2.0. > > > > By default this MiniPCIe WWAN slot is in PCIe mode, like before. > > > > To set this MiniPCIe WWAN slot to USB3.0 mode, call U-Boot commands: > > > > => setenv omnia_wwan_slot usb3 > > => saveenv > > => reset > > > > Signed-off-by: Pali Rohár > > --- > > board/CZ.NIC/turris_omnia/turris_omnia.c | 57 ++++++++++++++++++++++++ > > 1 file changed, 57 insertions(+) > > > > 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; > > } > > > > +static bool omnia_detect_wwan_usb3(const char *wwan_slot) > > +{ > > + puts("WWAN slot configuration... "); > > + > > + if (wwan_slot && strcmp(wwan_slot, "usb3") == 0) { > > + puts("USB3.0\n"); > > + return true; > > + } > > + > > + if (wwan_slot && strcmp(wwan_slot, "pcie") != 0) > > + printf("unsupported env value '%s', fallback to... ", wwan_slot); > > If I recall correctly, Linux' and U-Boot's code style (in contrast to > TF-A) normally wants > if (expr) instead of if (expr != 0) > and > if (!expr) instead of if (expr == 0) 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. > Sometimes in spite of this style it is better to use == or != operator, > for example in cases where one wants to compare a character to multiple > literals: > if (c == 0x13 || c == 0x12 || c == 0x00) > > But for strcmp() and friends, we normaly just use > if (!strcmp()) > > This is just a nitpick, I don't mind that much. Just saying this so > you are aware of this in the future... > > > > + > > + puts("PCIe+USB2.0\n"); > > + return false; > > +} > > + > > void *env_sf_get_env_addr(void) > > { > > /* SPI Flash is mapped to address 0xD4000000 only in SPL */ > > @@ -276,6 +292,20 @@ int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count) > > board_serdes_map[0].serdes_mode = SERDES_DEFAULT_MODE; > > } > > > > +#ifdef CONFIG_SPL_ENV_SUPPORT > > + /* beware that env_get() returns static allocated memory */ > > + env_value = has_env ? env_get("omnia_wwan_slot") : NULL; > > +#endif > > Use > if (IS_ENABLED(CONFIG_SPL_ENV_SUPPORT)) > instead of macro wherever possible, so that an error can be caught by > the compiler even if it is in the disabled part of the code. > > Marek