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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 4FE28C1975A for ; Sun, 22 Mar 2020 21:10:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 14B34206F8 for ; Sun, 22 Mar 2020 21:10:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="p2avgSfS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726872AbgCVVKA (ORCPT ); Sun, 22 Mar 2020 17:10:00 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:50814 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726741AbgCVVKA (ORCPT ); Sun, 22 Mar 2020 17:10:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ptdzuTNWiWg0jVMZ4VrC6zBgD5Vp7gRPxVGGykUOgno=; b=p2avgSfSRLAx0Qc22GEhPx4ZLs WP+71pOHSFxOrynsrtUdNZC2yEHrp+au/RLxGvP1U1n28C+s3Qj4DuARauhQ2T91xUCMHLp7JjvFu 6w9TKjT0rQsWeOc27TY0O3xH2CKGOVhdHJccxZID+w3fSVyaw9AtaibmMdda6BIoXzZU=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1jG7r4-0002iX-Ls; Sun, 22 Mar 2020 22:09:58 +0100 Date: Sun, 22 Mar 2020 22:09:58 +0100 From: Andrew Lunn To: Andreas =?iso-8859-1?Q?B=F6hler?= Cc: netdev@vger.kernel.org Subject: Re: [RFC] MDIO firmware upload for offloading CPU Message-ID: <20200322210958.GF3819@lunn.ch> References: <27780925-4a60-f922-e1ed-e8e43a9cc8a2@aboehler.at> <20200322144306.GI11481@lunn.ch> <96bfdd47-80ce-b7fd-75f7-d2ad0705f8bb@aboehler.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96bfdd47-80ce-b7fd-75f7-d2ad0705f8bb@aboehler.at> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > > Hi Andreas > > > > You say there is no PHY. So is the MDIO bus used for anything other > > than firmware upload? > > Yes - there are four other PHYs on the bus, everything is attached to > the Lantiq Gigabit switch. I wasn't clear enough in this regard. O.K. That makes it more difficult. Does probing just these four PHYs upset the firmware upload? You need to probe them in order to use them. > > This two stage firmware upload is messy. If it had been just MDIO i > > would of said do it from the kernel, as part of the Atheros SoC WiFi > > driver. MDIO is a nice simple interface. Sending Ethernet frames is a > > bit harder. Still, if you can do it all in the wifi driver, i > > would. You can use phandle's to get references to the MDIO bus and the > > Ehernet interface. There are examples of this in net/dsa/dsa2.c. > > A bit more info on the two-stage firmware upload: The Atheros SoC is a > complete AR9342 or QCA9558 SoC with 64MB or 128MB RAM. The stage 1 > firmware only initializes the Ethernet connection and waits for the > stage 2 firmware. The latter consists in the vendor implementation of a > Linux kernel and minimal user space, the wireless cards are then somehow > "exported" over Ethernet to the Lantiq SoC. On the Lantiq, they look > like local Atheros interfaces - it looks a lot like ath9k-htc with a > different transport So the traditional model would be, the driver on the Lantiq for the interfaces would be responsible for downloading the firmware to the Atheros. Is there a driver for the ath9k-htc transport? That transport is probably specific to the Atheros chip. So you can do the firmware download from there. Do you only use one address on the MDIO bus for firmware download? Another option would be to have an mdio 'device' with a driver. When the MDIO bus is enumerated by of_mdiobus_register(), it would find this 'device' in DT, and load the driver for it. That driver could then download the firmware over MDIO, and then later Ethernet. All the infrastructure is in place for this. It is used by Ethernet switches on MDIO busses. Andrew