From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2FF1610A1B; Sun, 7 Jan 2024 18:32:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lunn.ch Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="CNd4uLQZ" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=3ITLUw3/wwzNbCgnrBc39myl7J+F3NZ5Z7SwgjR2fQQ=; b=CNd4uLQZPqShcuU+wNi7F7AamO TJ50Wk/4AoY4GAayKb6qKIen+J3kf1sMDWzFNwkEiTJncIBb/JBcjnKAnMRoZkQWH/6cs+Y8TSZQg IV/+I6GhLRGCUGX8AnZjObGq5zVrHF/XnzKDlkQUIhq6Mqk6i93h+NO30OHI3hpohq2w=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1rMXwB-004aDT-G4; Sun, 07 Jan 2024 19:31:55 +0100 Date: Sun, 7 Jan 2024 19:31:55 +0100 From: Andrew Lunn To: Sergey Ryazanov Cc: Christian Marangi , Robert Marko , Vladimir Oltean , Rob Herring , Luo Jie , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Krzysztof Kozlowski , Conor Dooley , Andy Gross , Bjorn Andersson , Konrad Dybcio , Heiner Kallweit , Russell King , Matthias Brugger , AngeloGioacchino Del Regno , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: Re: [net-next PATCH RFC v3 1/8] dt-bindings: net: document ethernet PHY package nodes Message-ID: <1437d9df-2868-43f5-aebd-e0c57fe4d905@lunn.ch> References: <20231126015346.25208-1-ansuelsmth@gmail.com> <20231126015346.25208-2-ansuelsmth@gmail.com> <0926ea46-1ce4-4118-a04c-b6badc0b9e15@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0926ea46-1ce4-4118-a04c-b6badc0b9e15@gmail.com> > And I would like to ask you about another issue raised by Vladimir [1]. > These phy chips become SoC with all these built-in PHYs, PCSs, clocks, > interrupt controllers, etc. Should we address this now? Or should we go with > the proposed solution for now and postpone modeling of other peripherals > until we get a real hardware, as Andrew suggested? > > I'm asking because it looks like we have got a real hardware. Luo currently > trying to push QCA8084 (multi-phy/switch chip) support, and this chip > exactly contains a huge clock/reset controller [2,3]. Ideally the reset controller is modelled as a Linux reset controller. The clock part of it is modelled using the common clock framework. When done correctly, the PHY should not really care. All it does is ask for its clock to be enabled, and its reset to be disabled. Also, given how difficult it is proving to be to make any progress at all, i want to get one little part correctly described, the pure PHY. Once we have that, we can start on the next little part. So long as we keep to the Linux architecture of blocks or hardware with standard Linux drivers, and DT to glue them together, a small step by step approach should work out. Andrew