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=-5.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 DC490C63697 for ; Thu, 26 Nov 2020 12:32:08 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 670BA20B80 for ; Thu, 26 Nov 2020 12:32:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lDmw6nHj"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="tulT464t" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 670BA20B80 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SlPm4BnSVlgBeXJcUDXUg9XACUv78WcjzhV7+Y4Rzh0=; b=lDmw6nHjVo/1x00sV2mRPWMcV z+sIcH+BUivc8O6gDSv5dU3gOlsAyL6HRgbU/6OswNGQEw5ZKE9vb6RXXSsn8aALvFTPjydWtD6bz sRsjlsRSRbSfdzssxayYZ+uYEuNMqSiDWjrTQEgJBXua02FOiyLMjm7Y9+cnVW88F6Wk+/36Is/HW Ym0jw1qudpQe9ldtpNz6MfbsavqRP/Q8o57HN7gF3KNJT2vDQJBS9b0haxUwFR6/jgkh25JI7nCHP rV6MAJXDHFi95myIX3BNZx9hfViPTV1thOnLTMSUjA7JHRd3x99ZwJ2FW/YsISmsvbbUY2wb13Rfr QcreQ8wEw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kiGQ0-00087Y-VJ; Thu, 26 Nov 2020 12:30:37 +0000 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kiGPy-00086t-44 for linux-arm-kernel@lists.infradead.org; Thu, 26 Nov 2020 12:30:35 +0000 Received: by mail-ej1-x62a.google.com with SMTP id bo9so2615451ejb.13 for ; Thu, 26 Nov 2020 04:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2m+lvGSR6BHsH9qKxh1TPWUrONGP2N8HIxUK/qJixF8=; b=tulT464tQTXRd7bYocc5gHqkSpzMlqWbXuOm1Ch/HU5XbNujpD/ZBcJmRGmccz+zQt Ddst5/a3Ldj9QhjlHqTuzDnF/D3gdXAtU00ZsWaK9ztomOaLFY69m7H9AsOosM9/UPZo uQ+4M7zrmf3pC/SFBZPprdPc4aFFyNCZ2S0EEj1RXBn00CxRZqOs5LSE2mCTAhsihG5S dbLu9jmgVrGOleUJGxjxPGqF2q/jpR7Oyl+NUKlW2qW/dy2NBC/S69HpKy89z6y+8fqp IRUDqGDaH6OTHzQkPeTktD/nu+cJ8ce0eDVas4smXA57HuveaLD8dVA2R4Orw43YZqo8 dieA== 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; bh=2m+lvGSR6BHsH9qKxh1TPWUrONGP2N8HIxUK/qJixF8=; b=jNHwUMO7sGWTB8wS7oTAd0utEHIcEOvAKaXMNF7a+dRFewN1wO/l+O99dKr4jxCqBk m5DMmgN+YOGolGoMQ6SvLNviC43D+py5FCZdb/8rQ6/hJzvWwmyrhyrL++rHRMwD1GM5 NEsj9KDndYgcapDe2tTuHp67umhBqfZSeXbpNuRp6ERaA+8S0PtNgZMQoXanhrfslLpK TR8O390rIthRjsYWtrdgG60HsgKD0uCdRGiLt2vjtbdoA4HDCWfWgOjR7cn2eBlx/ly3 uNsrzu+E+Y21lQT3jiQwXHkBwUzY/iNZK0mAkp0G41iQW293oOc6aK/PDGOOGLV6n4eN lVSQ== X-Gm-Message-State: AOAM5312s8yeX7xhAnZ3z3BvWhh8LKpb39KdNDXshRKmvLBKUzd0f+7/ a9kG5ASJtyoUi9kbadBFHOg2E9Qg6fU= X-Google-Smtp-Source: ABdhPJyky7aETAB1Auf4sTcYZY/tUTC2pIUCoYPJAyUotZ0x/OJjMuOEsL/kWsGW4j/YSdYTotvgaQ== X-Received: by 2002:a17:906:4410:: with SMTP id x16mr2125701ejo.536.1606393830953; Thu, 26 Nov 2020 04:30:30 -0800 (PST) Received: from skbuf ([188.25.2.120]) by smtp.gmail.com with ESMTPSA id y15sm3116327eds.56.2020.11.26.04.30.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Nov 2020 04:30:30 -0800 (PST) Date: Thu, 26 Nov 2020 14:30:27 +0200 From: Vladimir Oltean To: Lukasz Majewski Subject: Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC Message-ID: <20201126123027.ocsykutucnhpmqbt@skbuf> References: <20201125232459.378-1-lukma@denx.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201125232459.378-1-lukma@denx.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201126_073034_226816_0C3B1F99 X-CRM114-Status: GOOD ( 33.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Peng Fan , Florian Fainelli , Fugang Duan , Shawn Guo , stefan.agner@toradex.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, krzk@kernel.org, Vivien Didelot , NXP Linux Team , Jakub Kicinski , Fabio Estevam , "David S . Miller" , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Lukasz, On Thu, Nov 26, 2020 at 12:24:55AM +0100, Lukasz Majewski wrote: > This is the first attempt to add support for L2 switch available on some NXP > devices - i.e. iMX287 or VF610. This patch set uses common FEC and DSA code. > > This code provides _very_ basic switch functionality (packets are passed > between lan1 and lan2 ports and it is possible to send packets via eth0), > at its main purpose is to establish the way of reusing the FEC driver. When > this is done, one can add more advanced features to the switch (like vlan or > port separation). > > I also do have a request for testing on e.g. VF610 if this driver works on > it too. > The L2 switch documentation is very scant on NXP's User Manual [0] and most > understanding of how it really works comes from old (2.6.35) NXP driver [1]. > The aforementioned old driver [1] was monolitic and now this patch set tries > to mix FEC and DSA. > > Open issues: > - I do have a hard time on understanding how to "disable" ENET-MAC{01} ports > in DSA (via port_disable callback in dsa_switch_ops). > When I disable L2 switch port1,2 or the ENET-MAC{01} in control register, I > cannot simply re-enable it with enabling this bit again. The old driver reset > (and setup again) the whole switch. You don't have to disable the ports if that does more harm than good, of course. > - The L2 switch is part of the SoC silicon, so we cannot follow the "normal" DSA > pattern with "attaching" it via mdio device. The switch reuses already well > defined ENET-MAC{01}. For that reason the MoreThanIP switch driver is > registered as platform device That is not a problem. Also, I would not say that the "normal" DSA pattern is to have an MDIO-attached switch. Maybe that was true 10 years ago. But now, we have DSA switches registered as platform devices, I2C devices, SPI devices, PCI devices. That is not an issue under any circumstance. > - The question regarding power management - at least for my use case there > is no need for runtime power management. The L2 switch shall work always at > it connects other devices. > > - The FEC clock is also used for L2 switch management and configuration (as > the L2 switch is just in the same, large IP block). For now I just keep it > enabled so DSA code can use it. It looks a bit problematic to export > fec_enet_clk_enable() to be reused on DSA code. > > Links: > [0] - "i.MX28 Applications Processor Reference Manual, Rev. 2, 08/2013" > [1] - https://github.com/lmajewski/linux-imx28-l2switch/commit/e3c7a6eab73401e021aef0070e1935a0dba84fb5 Disclaimer: I don't know the details of imx28, it's just now that I downloaded the reference manual to see what it's about. I would push back and say that the switch offers bridge acceleration for the FEC. The fact that the bridge acceleration is provided by a different vendor and requires access to an extra set of register blocks is immaterial. To qualify as a DSA switch, you need to have indirect networking I/O through a different network interface. You do not have that. What I would do is I would expand the fec driver into something that, on capable SoCs, detects bridging of the ENET_MAC0 and ENETC_MAC1 ports and configures the switch accordingly to offload that in a seamless manner for the user. This would also solve your power management issues, since the entire Ethernet block would be handled by a single driver. DSA is a complication you do not need. Convince me otherwise. Also, side note. Please, please, please, stop calling it "l2 switch" and use something more specific. If everybody writing a driver for the Linux kernel called their L2 switch "L2 switch", we would go crazy. The kernel is not a deep silo like the hardware team that integrated this MTIP switching IP into imx28, and for whom this L2 switch is the only switch that exists, and therefore for whom no further qualification was necessary. Andy, Peng or Fabio might be able to give you a reference to an internal code name that you can use, or something. Otherwise, I don't care if you need to invent a name yourself - be as creative as you feel like. mtip-fec-switch, charlie, matilda, brunhild, all fine by me. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel