Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp638133pxb; Mon, 16 Aug 2021 13:46:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVgl5TMgzQEv1GuP3xapvzhBZbT5xYOHryqSXB+KDR2umyFWqzXVwDAomrAzNyGO5kz51t X-Received: by 2002:a17:906:2414:: with SMTP id z20mr301741eja.363.1629146815928; Mon, 16 Aug 2021 13:46:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629146815; cv=none; d=google.com; s=arc-20160816; b=ecGyO0AVXkAEa1iOAzfbeSOK9Us9fP5E8EjPGtecFKmNzy+iCAn1ka57rCfJsuj9fj 2Qqcu9SIpPeWxG3xf7sdUBvs3ed/SUEkXPbjqz3Zqx58uCXevxPlLqaq+sd/TgfPdoJ5 APseGLuNsRW4NgAXwOkBbHnxwnCgj+GTjSZYeJWidLTP/sZwBWwzwddmYyeIhuaSloRt JKSzEBbpJsdpEv+8HbWNFjgCGHmveGPwPtbyiuFCVbk+jaHQbdqUjlLwvuyqxnCdR6Qr Kl/9bttZHRTOwW93a9VMEzzgoY3NRLul9TlWrXuzsAGJvvptxp2GguSOcSRc7IVBcFSB Kmdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=aveHwdz8XOLg5uedKS0PiRzGHECFylhR68z7BfBqvPc=; b=oud0/qrZ6Kgsgy0stODnAN1TE4olRUkpozeUU3dGdJ3UAMY7Gyl742ygYrzTNbCj+k h2a9SOhtgdB1K7tk50bMSR74alt327KA8TEtZ5VgE4bfIH0tmRS2fcA1+SjDckjtymYY RcCT+FDYYwHGU6Odcm6iPeiHXiK42gTe4PcFIxpVTScnEhwFkhUmWpsz9SJ2Ec4Zr5Tj 9Qq582WT2OzlgYDT9LmWAkCISma1Hsyes9tNcH4A1xyYW9Uf6xdj6eum5bAyhuNRUKcA bcgXC5usoPOOd4dCN7PA+WAJtiLLo0xPRGSXC1jCpXRwDFMeTXHKBL9/JcxfmtcMfjjR ACWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Yz3Debl4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w10si315107ejv.754.2021.08.16.13.46.28; Mon, 16 Aug 2021 13:46:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Yz3Debl4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232812AbhHPUo2 (ORCPT + 99 others); Mon, 16 Aug 2021 16:44:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231618AbhHPUo2 (ORCPT ); Mon, 16 Aug 2021 16:44:28 -0400 Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95089C0613C1 for ; Mon, 16 Aug 2021 13:43:56 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id g26so7809019ybe.0 for ; Mon, 16 Aug 2021 13:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aveHwdz8XOLg5uedKS0PiRzGHECFylhR68z7BfBqvPc=; b=Yz3Debl4URh7iBQaqrwvr789CHA3V1EyHDhxu2XXGYZJIW1xuqiOmqsa8Byx45dLlf CXOKnz5LtK6XekO3z8y1bvSyeBrgFe6/qIEQbKAGcPL955y2fPFKjj2Z4hrfViOcdcwp CavbCcXhnlVyIW3Ap26I6sWBeZXc5SsKn477q0/+xOjBJBRMMjpuduZRoFHWMeGZp4Q7 VXBn3wwENsqpLEBZER6LsgzlbIlc+a/+9xTiOFhh+I9+7q1N97QxBXsgsqpFGqLw3dUW Ep2lVPmlXZLhmK2l+nDcaOIKDLRJwAuUUylR80lmcDprUrQpumdWVRHbuQaDFM0i4OZI NtTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aveHwdz8XOLg5uedKS0PiRzGHECFylhR68z7BfBqvPc=; b=UJD+i2EqOOjom8GnyF3kDdkebN7zRRU+T3bGZe1FflZQBijDMiIc4QauIl1mNcwSdA TTtomUKsvrNc36arGYZMhhDSefVJRFf4n8EuuUyJNNibuLOCvyHPIbUEgZtznONaBAo/ P5eqZ5ZYYBagamcCwWADjZSQN8BgI6Dr/ECmnoYxbb9uSp3kFYQa/vlaz7MH9RvcQva8 FvWDSyMfv5CX7gQAPg2xIhh9OYAsiiuu2gJwsDSdeTRKlV/31orfsPiooVVXFcIrizS3 TQQkGuJ0woeYqz2wxPABMOFLR0ceGzPOTtvkVozJXeAb1OQDnxLGrWokvQPuz0scDnFd k66Q== X-Gm-Message-State: AOAM530uX/jEy4SH3OhXV4nYq6jGTpIOx7nGrx+6Bsoh+MA6pkfRy6Ft imuNOZYfkSdQwXhfX81fiZXDVjnZZJpb0eX0qv7qwA== X-Received: by 2002:a25:8445:: with SMTP id r5mr437513ybm.20.1629146635725; Mon, 16 Aug 2021 13:43:55 -0700 (PDT) MIME-Version: 1.0 References: <20210814023132.2729731-1-saravanak@google.com> <20210814023132.2729731-3-saravanak@google.com> In-Reply-To: From: Saravana Kannan Date: Mon, 16 Aug 2021 13:43:19 -0700 Message-ID: Subject: Re: [PATCH v1 2/2] of: property: fw_devlink: Add support for "phy-handle" property To: Andrew Lunn Cc: Rob Herring , Frank Rowand , kernel-team@android.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 14, 2021 at 8:22 AM Andrew Lunn wrote: > > Hi Saravana > > > Hi Andrew, > > > > > Also there > > are so many phy related properties that my head is spinning. Is there a > > "phy" property (which is different from "phys") that treated exactly as > > "phy-handle"? > > Sorry, i don't understand your question. Sorry. I was just saying I understand the "phy-handle" DT property (seems specific to ethernet PHY) and "phys" DT property (seems to be for generic PHYs -- used mostly by display and USB?). But I noticed there's yet another "phy" DT property which I'm not sure I understand. It seems to be used by display and ethernet and seems to be a deprecated property. If you can explain that DT property in the context of networking and how to interpret it as a human, that'd be nice. > > > + /* > > + * Device tree nodes pointed to by phy-handle never have struct devices > > + * created for them even if they have a "compatible" property. So > > + * return the parent node pointer. > > + */ > > We have a classic bus with devices on it. The bus master is registers > with linux using one of the mdiobus_register() calls. That then > enumerates the bus, looking at the 32 possible address on the bus, > using mdiobus_scan. It then gets a little complex, due to > history. > > Originally, the only thing you could have on an MDIO bus was a > PHY. But devices on MDIO busses are more generic, and Linux gained > support for Ethernet switches on an MDIO bus, and there are a few > other sort device. So to keep the PHY API untouched, but to add these > extra devices, we added the generic struct mdio_device which > represents any sort of device on an MDIO bus. This has a struct device > embedded in it. > > When we scan the bus and find a PHY, a struct phy_device is created, > which has an embedded struct mdio_device. The struct device in that is > then registered with the driver core. > > So a phy-handle does point to a device, but you need to do an object > orientated style look at the base class to find it. Thanks for the detailed explanation. I didn't notice a phy_device had an mdio_device inside it. Makes sense. I think my comment is not worded accurately and it really should be: Device tree nodes pointed to by phy-handle (even if they have a "compatible" property) will never have struct devices probed and bound to a driver through the driver framework. It's the parent node/device that gets bound to a driver and initializes the PHY. So return the parent node pointer instead. Does this sound right? As opposed to PHYs the other generic mdio devices seem to actually have drivers that'll bind to them through the driver framework. -Saravana