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=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 9DDEAC169C4 for ; Wed, 6 Feb 2019 21:44:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6B1F8218D3 for ; Wed, 6 Feb 2019 21:44:38 +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="vmEFi9o9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726641AbfBFVoh (ORCPT ); Wed, 6 Feb 2019 16:44:37 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:41599 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726037AbfBFVoh (ORCPT ); Wed, 6 Feb 2019 16:44:37 -0500 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=2UFFMcxiYxIoKYfylSRpVwwNQ4zea8qQu1ot8K2wPoM=; b=vmEFi9o9pKowN8R7RPnSlWMBdo NG59sAvvdHrTH6o7U7W52OR3xtXNYYODdXMxJx1lAnLB1dcGqMoDm1dPmNJcpdnNrC7deT7d377qX eJ8dgYLNtoyzrqE3v/NXZbpn3O/8iBToWozhr4dHhXiysh8RaaA72APieNt3lp3nBU90=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1grUzg-0001aT-OP; Wed, 06 Feb 2019 22:44:32 +0100 Date: Wed, 6 Feb 2019 22:44:32 +0100 From: Andrew Lunn To: Leo Li Cc: Pankaj Bansal , Shawn Guo , Florian Fainelli , "netdev@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v2] arm64: dts: lx2160aqds: Add mdio mux nodes Message-ID: <20190206214432.GB32483@lunn.ch> References: <20190204141641.18272-1-pankaj.bansal@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > > > > &i2c0 { > > > > status = "okay"; > > > > > > > > + fpga@66 { > > > > + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c"; > > > > + reg = <0x66>; > > > > + #address-cells = <1>; > > > > + #size-cells = <0>; > > > > + > > > > + mdio-mux-1@54 { > > > > > > Still no compatible string defined for the node. Probably should be > > > "mdio-mux- mmioreg", "mdio-mux" > > > > it is not a specific device. MDIO mux is meant to be controlled by some > > registers of parent device (FPGA). > > Therefore, IMO this should not be a device and there should not be any > > "compatible" property for it. > If it is not a device why we are defining a device node for it? It > is probably not a physical device per se, but it can be considered a > virtual device provided by FPGA. It is a physical device. But it happens to be embedded inside another device. And that embedded is not performed as a bus with devices on it, so the device tree concepts don't fit directly. > This also bring up another question that why this device cannot > reuse the existing drivers/net/phy/mdio-mux-mmioreg.c driver? Because it is on an i2c bus, not an mmio bus. > If we think regmap is a better solution, shall we replace the > mmioreg driver with the regmap driver? regmap can be used with mmio. But for a single MMIO register it is a huge framework. So it makes sense to keep mdio-mux-mmioreg simple. If however the device is already using regmap, adding one more register is very little overhead. And it might be possible to use this new mux with an mmio regmap, or an spi regmap, etc. So we seem to be covering the best of both worlds. Andrew