Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751656AbdH3KGK (ORCPT ); Wed, 30 Aug 2017 06:06:10 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33691 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751368AbdH3KGI (ORCPT ); Wed, 30 Aug 2017 06:06:08 -0400 MIME-Version: 1.0 In-Reply-To: <237eee82-2edb-56c0-d644-2e6253a178dc@gmail.com> References: <20170816075524.GA18532@amd> <20170816140451.GA13006@lunn.ch> <9235D6609DB808459E95D78E17F2E43D40AFF8C1@CHN-SV-EXMX02.mchp-main.com> <20170827123658.GA727@amd> <20170827163122.GG13622@lunn.ch> <20170828070232.GA18135@amd> <20170828140927.GD10418@lunn.ch> <20170829074130.GA31303@amd> <20170829122604.GA22093@lunn.ch> <20170829211519.GA24221@amd> <237eee82-2edb-56c0-d644-2e6253a178dc@gmail.com> From: Maxim Uvarov Date: Wed, 30 Aug 2017 13:06:06 +0300 Message-ID: Subject: Re: [PATCH] DSA support for Micrel KSZ8895 To: Florian Fainelli Cc: Pavel Machek , Andrew Lunn , Woojung.Huh@microchip.com, Nathan Conrad , Vivien Didelot , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Tristram.Ha@micrel.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2094 Lines: 76 2017-08-30 0:23 GMT+03:00 Florian Fainelli : > On 08/29/2017 02:15 PM, Pavel Machek wrote: >> On Tue 2017-08-29 14:26:04, Andrew Lunn wrote: >>>> But the MDIO emaulation code is from their driver, after lots of >>>> deletions. >>> >>> Is this driver supposed to run on lots of different OSs? That would >>> explain why they ignored the Linux MDIO and PHY layers. >> >> It did not look particulary portable. > > Part of the problem is that they need to duplicate the standard MII > definitions, whereas we could re-use those from include/linux/mii.h > and/or mdio.h. > >> >>> If possible, please make use of the Linux infrastructure. >> >> I did not find any infrastructure I could use instead >> ksz_mdio_emulation. > > fixed PHY/swphy.c is as close as it could get, but it is a highly > simplified version of this. > >> >> Now, drivers/net/phy/spi_ks8995.c can access the PHY registers, and I >> can not see any translation there, so there may be something I'm >> missing. > > I don't see anything in that driver that seems to access PHY registers > what makes you think it does? > > There's got to be a way to perform indirect accesses through SPI, > Woojung, do you know? > As I understand they just attach phy on spi bus with generic driver: phy_addr = 0; phy_mode = PHY_INTERFACE_MODE_MII; snprintf(bus_id, MII_BUS_ID_SIZE, "sw.%d", sw_device_present); snprintf(phy_id, MII_BUS_ID_SIZE, PHY_ID_FMT, bus_id, phy_addr); phydev = phy_attach(netdev, phy_id, 0, phy_mode); if (!IS_ERR(phydev)) { phydev->adjust_link = sw_adjust_link; return phydev; } Where is bus is: bus = mdiobus_alloc(); bus->read = ksz_mii_read; (spi read function) bus->write = ksz_mii_write; Then just generic reads: .config_aneg = genphy_config_aneg, .read_status = genphy_read_status, Maxim. >> >> Pointers would be welcome at this point. >> >> Thanks, >> Pavel >> > > > -- > Florian -- Best regards, Maxim Uvarov