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 04EE81D27BF; Mon, 7 Oct 2024 13:01:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.67.10.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728306117; cv=none; b=IzJuTwYTvxhVUf9/7ZjtAxnv34ZISV/x5yfQ4s4LbcTFZjPt9/wpBxJ7CZba8McAo7kBJBjVTPIt7emWM1EMxaZDXLaITENyAFPF1q3NXqQ2ASWFsFMgf3t4UzzP0bpVIigyK3CYPuqysa6J572eEPhPasWo9XJUZRy/StJcmA0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728306117; c=relaxed/simple; bh=VRoIVYavvWEQ/zjPpxRTJx/tHkOU8kaWQGlvqYSDb5s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XYvtbqTPnFJ9tiC46rKa7CpERuxR40+wTTjlZHaUjQLAuYfq0JoyB7Rug+E42joRYBsdIt07ZXj/rAQPf0WvOuy8pEERzKFeT1NXWbQeiL13HGlmTgGN/xEorYIb2VBfvMtlkEARUaVsCy3ksfJm2/AKpk4AmXqwBQrDzrWCV8I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch; spf=pass smtp.mailfrom=lunn.ch; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b=oQ+J5Tuw; arc=none smtp.client-ip=156.67.10.101 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="oQ+J5Tuw" 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=9vsE/JZpOUgZS9rfiGMJoEt1zwSQezxy7A2bI0xxF/k=; b=oQ+J5Tuwf3kpgn8LsbwVlXAvBR YUKy2CedCNSIcOt5tGut5WmtyFri7L3K1P3X1DN7S3QYAXkNl78t3vHjd9e2jFYVfRuTR/Dn0KbQ1 FwsAjeeQ3w4OEQgJJIS9FoIEu8XNoo+u/MQszHVKhL5JxIqPiEG861jNrRlKtabnjhlk=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1sxnN0-009GJL-IW; Mon, 07 Oct 2024 15:01:50 +0200 Date: Mon, 7 Oct 2024 15:01:50 +0200 From: Andrew Lunn To: Maxime Chevallier Cc: "Russell King (Oracle)" , davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com, Jakub Kicinski , Eric Dumazet , Paolo Abeni , linux-arm-kernel@lists.infradead.org, Christophe Leroy , Herve Codina , Florian Fainelli , Heiner Kallweit , Vladimir Oltean , Marek =?iso-8859-1?Q?Beh=FAn?= , =?iso-8859-1?Q?K=F6ry?= Maincent , Oleksij Rempel Subject: Re: [PATCH net-next v2 7/9] net: phy: introduce ethtool_phy_ops to get and set phy configuration Message-ID: <6bdaf8de-8f7e-42db-8c29-1e8a48c4ddda@lunn.ch> References: <20241004161601.2932901-1-maxime.chevallier@bootlin.com> <20241004161601.2932901-8-maxime.chevallier@bootlin.com> <4d4c0c85-ec27-4707-9613-2146aa68bf8c@lunn.ch> <20241007123751.3df87430@device-21.home> 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: <20241007123751.3df87430@device-21.home> > It seems I am missing details in my cover and the overall work I'm > trying to achieve. > > This series focuses on isolating the PHY in the case where only one > PHY is attached to the MAC. I can understand implementing building blocks, but this patchset seems to be more than that, it seems to be a use case of its own. But is isolating a single PHY a useful use case? Do we want a kAPI for this? > I have followup work to support multi-PHY > interfaces. I will do my best to send the RFC this week so that you can > take a look. I'm definitely not saying the current code supports that. > > To tell you some details, it indeed works as Russell says, I > detach/re-attach the PHYs, ndev->phydev is the "currently active" PHY. > > I'm using a new dedicated "struct phy_mux" for that, which has : > > - Parent ops (that would be filled either by the MAC, or by phylink, > in the same spirit as phylink can be an sfp_upstream), which manages > PHY attach / detach to the netdev, but also the state-machine or the > currently inactive PHY. > > - multiplexer ops, that implement the switching logic, if any (drive a > GPIO, write a register, this is in the case of real multiplexers like > we have on some of the Turris Omnia boards, which the phy_mux framework > would support) > > - child ops, that would be hooks to activate/deactivate a PHY itself > (isoalte/unisolate, power-up/power-down). Does the kAPI for a single PHY get used, and extended, in this setup? > I'll send the RFC ASAP, I still have a few rough edges that I will > mention in the cover. > > > However, I still want to hear whether multiple PHYs can be on the same > > MII bus from a functional electrical perspective. > > Yup, I have that hardware. Can you talk a bit more about that hardware? What PHYs do you have? What interface modes are they using? Andrew