From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751527AbaI2G2Z (ORCPT ); Mon, 29 Sep 2014 02:28:25 -0400 Received: from devils.ext.ti.com ([198.47.26.153]:53891 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750768AbaI2G2Y (ORCPT ); Mon, 29 Sep 2014 02:28:24 -0400 Message-ID: <5428FBFF.6050804@ti.com> Date: Mon, 29 Sep 2014 11:58:15 +0530 From: Kishon Vijay Abraham I User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Heikki Krogerus CC: Greg Kroah-Hartman , Felipe Balbi , Vivek Gautam , , Subject: Re: [PATCH 2/6] phy: improved lookup method References: <5411C0B2.3060505@ti.com> <20140912140720.GC30816@xps8300> <54130729.5010206@ti.com> <20140915123508.GA16653@xps8300> <20140918102505.GB8567@xps8300> <54200A13.6050201@ti.com> <20140923105311.GB18814@xps8300> <5421536D.4050601@ti.com> <20140923114353.GC18814@xps8300> <54229276.5050000@ti.com> <20140925070034.GA15854@xps8300> In-Reply-To: <20140925070034.GA15854@xps8300> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 25 September 2014 12:30 PM, Heikki Krogerus wrote: >>>>>>>>> Assume you have 2 phys in your system.. >>>>>>>>> static struct phy_lookup usb_lookup = { >>>>>>>>> .phy_name = "phy-usb.0", >>>>>>>>> .dev_id = "usb.0", >>>>>>>>> .con_id = "usb", >>>>>>>>> }; >>>>>>>>> >>>>>>>>> static struct phy_lookup sata_lookup = { >>>>>>>>> .phy_name = "sata-usb.1", >>>>>>>>> .dev_id = "sata.0", >>>>>>>>> .con_id = "sata", >>>>>>>>> }; >>>>>>>>> >>>>>>>>> First you do modprobe phy-usb, the probe of USB PHY driver gets invoked and it >>>>>>>>> creates the PHY. The phy-core will find a free id (now it will be 0) and then >>>>>>>>> name the phy as phy-usb.0. >>>>>>>>> Then with modprobe phy-sata, the phy-core will create phy-sata.1. >>>>>>>>> >>>>>>>>> This is an ideal case where the .phy_name in phy_lookup matches. >>>>>>>>> >>>>>>>>> Consider if the order is flipped and the user does modprobe phy-sata first. The >>>>>>>>> phy_names won't match anymore (the sata phy device name would be "sata-usb.0"). >>>>>>> >>>>>>> Actually, I don't think there would be this problem if we used the >>>>>>> name of the actual device which is the parent of phy devices, right? >>>>>> >>>>>> hmm.. but if the parent is a multi-phy phy provider (like pipe3 PHY driver), we >>>>>> might end up with the same problem. >>>>> >>>>> I'm not completely sure what you mean? If you are talking about >>>>> platforms with multiple instances of a single phy, I don't see how >>>>> there could ever be a scenario where we did not know the order in >>>>> which they were enumerated. Can you give an example again? >>>> >>>> If a single IP implements multiple PHYs (phy-miphy365x.c in linux-phy next), >>>> the parent for all the phy devices would be the same. > > Hold on... > > Let's take a step back here. Where could we actually have a scenario > where the phy device, the dev_id (consumer) and the con_id would all > be the same? There can't be such a case. > > It's not like you could ever have a driver requesting multiple phys > with the same con_id. You would just get the same phy handle even if > you used dt. > > phy1 = phy_get(dev, "phy"); > ... > phy2 = phy_get(dev, "phy"); > > And if the drivers requesting those phys are different, your consumers > are different. sounds right to me. Cheers Kishon