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 76545C77B72 for ; Thu, 20 Apr 2023 03:46:44 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4CB7785ED2; Thu, 20 Apr 2023 05:46:42 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=andestech.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 1ABA185F22; Thu, 20 Apr 2023 05:46:41 +0200 (CEST) Received: from Atcsqr.andestech.com (60-248-80-70.hinet-ip.hinet.net [60.248.80.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 9CEA185DC9 for ; Thu, 20 Apr 2023 05:46:37 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=andestech.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ycliang@andestech.com Received: from mail.andestech.com (ATCPCS16.andestech.com [10.0.1.222]) by Atcsqr.andestech.com with ESMTP id 33K3k9YW029662; Thu, 20 Apr 2023 11:46:09 +0800 (+08) (envelope-from ycliang@andestech.com) Received: from ubuntu01 (10.0.12.75) by ATCPCS16.andestech.com (10.0.1.222) with Microsoft SMTP Server id 14.3.498.0; Thu, 20 Apr 2023 11:46:08 +0800 Date: Thu, 20 Apr 2023 03:45:59 +0000 From: Leo Liang To: yanhong wang , , CC: Torsten Duwe , , Rick Chen , Lukasz Majewski , Sean Anderson , Lee Kuan Lim , "Jianlong Huang" , Emil Renner Berthing , Subject: Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support Message-ID: References: <20230329034224.26545-1-yanhong.wang@starfivetech.com> <20230329114138.3458974f@blackhole.lan> <20230412195047.60243174@blackhole.lan> <20230413110317.42581eaa@blackhole.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.5 (2021-01-21) X-Originating-IP: [10.0.12.75] X-DNSRBL: X-MAIL: Atcsqr.andestech.com 33K3k9YW029662 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.8 at phobos.denx.de X-Virus-Status: Clean Hi YanHong, Torsten, Matthias, On Thu, Apr 13, 2023 at 06:05:56PM +0800, yanhong wang wrote: > > > On 2023/4/13 17:03, Torsten Duwe wrote: > > On Thu, 13 Apr 2023 10:05:28 +0800 > > yanhong wang wrote: > > > >> the definition of DT refers to Linux and is consistent with the definition framework of Linux. > > > > This is one of the desired goals, to avoid confusion, usually. But note there are already the > > -u-boot.dtsi files; in this case it would be vice-versa: U-Boot could be simple, the kernel > > required a different treatment. As long as the resulting tree matches the hardware! > > > >> The difference between 1.2A and 1.3B is the PHY type and phy clock delay configuration, > >> which are reflected in DT, and the difference in defconfig is the configuration of the DT file. > >> > >> Is defconfig defined separately or merged? > > > > You are the implementer, this is your decision. You make a proposal, and it will get accepted > > or not. We only make suggestions, with the intention to improve the code. > > > > Thanks. A defconfig matches a piece of hardware, which is more developer-friendly and less confusing, > so defconfig is better defined separately. > > >> The EEPROM is being prepared and will be submitted as soon as possible. Is it necessary to > >> incorporate EEPROM into this submission? > >> > >> When eeprom is supported, the MAC address will be read from eeprom. The board reversion > >> can be read from eeprom, but phy clock delay configuration cannot be read from eeprom, only in DT. > > > > But the board revision number in EEPROM can be used to differentiate between 1.2 and 1.3, right? > > > > Yes, board reversion read from eeprom can distinguish between 1.2A and 1.3B. > > 1.2A and 1.3B are two sets of hardware, and the differences between the hardware are defined > by DT, which is more concise and clear. > > > When I look at the code and my test results, this is my proposal to pull this in, in order to > > simplify things and avoid duplication. Whether you do so is up to you, see above. Let me recap: > > > > * the device tree *must* match the hardware at hand. > > > > * the differences are minor and could be patched, Copy&Waste is error prone and causes extra work. > > > > It is my firm conviction that this patch set does not introduce hardware variants, and it would be > > the task of the ethernet driver patch set to split the code (DT+defconfig) OR to provide a patching > > method. Maybe I find a few cycles to look at the EEPROM. > > > > Torsten Agree with Torsten. I too IMHO think it makes much sense that whether "to split the (DT + defconfig)" or "patching DT" should be the task of ethernet driver patch. However, this patch set is rather complete and stay on the ML for quite a time. And also Torsten has sent out the RFC patch that is going for the patching method. In that sense, I think I could probably merge this v5 patch set with [v4 17/17] patch that only introduces a single defconfig, and wait for Torsten's DT patches if you guys agree. Any thoughts? Best regards, Leo