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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB17EC433FE for ; Sat, 12 Nov 2022 09:53:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234751AbiKLJw5 (ORCPT ); Sat, 12 Nov 2022 04:52:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230170AbiKLJwz (ORCPT ); Sat, 12 Nov 2022 04:52:55 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C554A12AA0 for ; Sat, 12 Nov 2022 01:52:54 -0800 (PST) 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 ams.source.kernel.org (Postfix) with ESMTPS id 8B394B8070D for ; Sat, 12 Nov 2022 09:52:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3145C433C1; Sat, 12 Nov 2022 09:52:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668246772; bh=2kPa/ZuiFB8gSGUG16/GG8STK8RCPwk8XcTJpsGLJVc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cz2GG8EQsV4dQg3z/o7zcGb8T1vwou2eFe7buLDiJSgfQEmt938q5aCABu8QXAUn4 ifxyhd9co3TnXRzJgR2AE0ZpBCN4Ho3IDZ2QAh41x7cXojWSFJRmb3Q3bJ47KEwEEl INB6no0fCPB8ZUlM7exwyvsyRxJI/iy0I61wR/dDLY0BHCql/DOQ9DS49RxX80z7QG iQHRAAzFIZmsvwmZdLueQfV0EPBcKqQCTReMlXJCUEHRiScevvRhMTLrV25U9P7hWu G6JaF1HZbPI38IuYFr2qBSKeqz5E7pZ1SjjUdx6MlMMEOIet3qjfMtJrlsaKPcfvd3 +PJie3upCCxYw== Date: Sat, 12 Nov 2022 01:52:47 -0800 From: Saeed Mahameed To: Jakub Kicinski Cc: Andrew Lunn , David Thompson , davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, netdev@vger.kernel.org, cai.huoqing@linux.dev, brgl@bgdev.pl, limings@nvidia.com, chenhao288@hisilicon.com, huangguangbin2@huawei.com, Asmaa Mnebhi Subject: Re: [PATCH net-next v2 3/4] mlxbf_gige: add BlueField-3 Serdes configuration Message-ID: References: <20221109224752.17664-1-davthompson@nvidia.com> <20221109224752.17664-4-davthompson@nvidia.com> <20221111213418.6ad3b8e7@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20221111213418.6ad3b8e7@kernel.org> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 11 Nov 21:34, Jakub Kicinski wrote: >On Thu, 10 Nov 2022 14:33:47 +0100 Andrew Lunn wrote: >> On Wed, Nov 09, 2022 at 05:47:51PM -0500, David Thompson wrote: >> > The BlueField-3 out-of-band Ethernet interface requires >> > SerDes configuration. There are two aspects to this: >> > >> > Configuration of PLL: >> > 1) Initialize UPHY registers to values dependent on p1clk clock >> > 2) Load PLL best known values via the gateway register >> > 3) Set the fuses to tune up the SerDes voltage >> > 4) Lock the PLL >> > 5) Get the lanes out of functional reset. >> > 6) Configure the UPHY microcontroller via gateway reads/writes >> > >> > Configuration of lanes: >> > 1) Configure and open TX lanes >> > 2) Configure and open RX lanes >> >> I still don't like all these black magic tables in the driver. >> >> But lets see what others say. > >Well, the patch was marked as Changes Requested so it seems that DaveM >concurs :) (I'm slightly desensitized to those tables because they >happen in WiFi relatively often.) > >The recommendation is to come up with a format for a binary file, load >it via FW loader and then parse in the kernel? By FW loader you mean request_firmware() functionality ? I am not advocating for black magic tables of course :), but how do we avoid them if request_firmware() will be an overkill to configure such a simple device? Express such data in a developer friendly c structures with somewhat sensible field names? > >We did have a recommendation against parsing FW files in the kernel at >some point, too, but perhaps this is simple enough to pass. > >Should this be shared infra? The problem is fairly common. Infrastructure to parse vendor Firmware ? we can't get vendors to agree on ethtool interface, you want them to agree on one firmware format :)? BTW i don't think the issue here is firmware at all, this is device specific config space.