From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756058AbcJGGYv (ORCPT ); Fri, 7 Oct 2016 02:24:51 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:37417 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750974AbcJGGYk (ORCPT ); Fri, 7 Oct 2016 02:24:40 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org BEE5360314 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=vivek.gautam@codeaurora.org Subject: Re: [PATCH] phy: nop: Add a new phy driver for No-Op transceiver To: Kishon Vijay Abraham I References: <1475577817-28500-1-git-send-email-vivek.gautam@codeaurora.org> <57F4EE05.8000407@ti.com> Cc: robh+dt@kernel.org, mark.rutland@arm.com, linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Felipe Balbi From: Vivek Gautam Message-ID: Date: Fri, 7 Oct 2016 11:53:06 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57F4EE05.8000407@ti.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kishon, On 10/05/2016 05:41 PM, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 04 October 2016 04:13 PM, Vivek Gautam wrote: >> No-Op phy transceiver can be used on platforms that have >> controllers which themselves provide PHY functionality and >> there's no separate PHY controller available. >> >> This driver provides a basic skeleton for a nop-phy driver. >> This can be further extended to add required features. >> >> Inspired by phy-generic driver in drivers/usb/phy. >> >> Signed-off-by: Vivek Gautam >> Cc: Kishon Vijay Abraham I >> Cc: Felipe Balbi >> --- >> >> Hi Kishon, Felipe, >> >> This patch has been lying in my tree for sometime. >> This introduces a skeletal nop-phy driver based on generic >> phy framework. >> I mainly use this driver when I have only one phy driver available >> for testing for a controller that uses more than one phy. >> >> But this can be further extended to add any feature support for >> controllers that don't have a separate PHY controller and that >> themselves provide the PHY functionality, a purpose similar >> to what drivers/usb/phy/phy-generic.c driver serves. >> >> Do you think we have a requirement for such a driver in the generic >> phy layer? I hope this driver can do some good. >> Let me know your comments on this. >> >> Thanks >> Vivek >> >> Documentation/devicetree/bindings/phy/phy-nop.txt | 22 +++ >> drivers/phy/Kconfig | 10 ++ >> drivers/phy/Makefile | 1 + >> drivers/phy/phy-nop.c | 193 ++++++++++++++++++++++ >> 4 files changed, 226 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/phy/phy-nop.txt >> create mode 100644 drivers/phy/phy-nop.c >> >> diff --git a/Documentation/devicetree/bindings/phy/phy-nop.txt b/Documentation/devicetree/bindings/phy/phy-nop.txt >> new file mode 100644 >> index 0000000..6cb6779 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/phy/phy-nop.txt [snip] >> + >> +Example: >> + phy_nop: phy_nop { >> + compatible = "phy-nop"; >> + #phy-cells = <0>; >> + }; > I don't think this qualifies to be modeled as dt. device tree should try to > represent HW and not workaround SW issues by creating dummy nodes. For such > cases phy_optional_get should suffice? You are right. The device tree should model the hardware on the platform. But what i am trying to model here is a simple phy binding that the users can use taking a phandle for this PHY in their device nodes. > > I'm more towards having a simple-phy, along the lines of [1] > > [1] -> https://patchwork.kernel.org/patch/8153691/ Cool, the above patch looks good, and is quite similar to what i meant to do. I will drop this one. But that patch hasn't move forward. I will ping in that thread, so that we can have a re-spin of that patch that can be reviewed further and merged. > > Thanks > Kishon [snip] Thanks Vivek