From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 8AAEA3EFFC9; Fri, 15 May 2026 16:22:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778862157; cv=none; b=ebl4aSOA0aKDPqR4x17LOMpIHdaf305Pl2seC7NLjDGdJ5fFvvTZGQx9s9laOk97rZqLQpat1742qZjmORFtFZbSmvA6OD162SOtMZyW8y+4uChuj6rScpimhfK1OqGhJx0YALzlpRdQ7J7OUuQvDno4oep2iDnHywFv/M/MnU4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778862157; c=relaxed/simple; bh=RFIxxGupQOQAst8dpVpNkaa9M21OnXF1JMqigtKLPaM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lYm+O4Tixagvaow8mZqNtGF9BXXslMx6LTqLSVdcLH46SqYImd8JU2TTDjSyRg4u3X0aPDtCB/dUeA2JLtXnvgj1mW8RIonnH5W42qva4t46sNXaVnJfJNMPCVMWIXa0L1octPFQbIOO5+8Zswe8/M2DYWiD8JnWxX0UwjNtLUI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=EnyFIQ0z; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="EnyFIQ0z" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id E7FDA1A35EC; Fri, 15 May 2026 16:22:33 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id BA50B606FD; Fri, 15 May 2026 16:22:33 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id AD57511AF8D6E; Fri, 15 May 2026 18:22:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1778862152; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=QD4twp9ma9NDSyrwSFUQpy1DH5AFl+x5xI25hNp8S68=; b=EnyFIQ0z/r6H3zZxOeE6oZbKmzzgv6dSV8+IdSEHL6gxlotdBhnQNkuRtZ9xs9dbp4MqLj ItB/BP+GiFTxFElNaaMXLBRUnixZQxWA0x6iK4VMVcAtN3iNPPFY2wVZMbGaEtoRV4kSE5 1nVxslmOYtNovrAzsaJ9jblcCzpEBt600KINSf6ZdyvyqcigFdfcXe011CYPoDiboFk7Md JCuSwSDfJAhFQaX79/7jy7ZEyFxBNPGab/hz64gk2y1V529HHDpE2PtInmxLvCCkbGwStJ QYGkoWevavDmLfhl5pCDcBPr9oEUEwp6NCrG2sig0P6ngjRZEdjpSxkk+lsE+w== Message-ID: Date: Fri, 15 May 2026 18:22:21 +0200 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v10 6/9] net: phy: phy_port: Store information about a MII port's vacant state To: Andrew Lunn Cc: davem@davemloft.net, Jakub Kicinski , Eric Dumazet , Paolo Abeni , Russell King , Heiner Kallweit , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com, Christophe Leroy , Herve Codina , Florian Fainelli , Vladimir Oltean , =?UTF-8?Q?K=C3=B6ry_Maincent?= , =?UTF-8?Q?Marek_Beh=C3=BAn?= , Oleksij Rempel , =?UTF-8?Q?Nicol=C3=B2_Veronese?= , Simon Horman , mwojtas@chromium.org, Romain Gantois , Daniel Golle , Dimitri Fedrau , Frank Wunderlich References: <20260513130521.1064094-1-maxime.chevallier@bootlin.com> <20260513130521.1064094-7-maxime.chevallier@bootlin.com> <97cd33a0-ee74-4f64-b11a-bb5b88bce79a@lunn.ch> Content-Language: en-US From: Maxime Chevallier In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 On 5/15/26 15:12, Andrew Lunn wrote: > My comment is really about, what do we mean by vacant/empty? Ah yes got it :) > > Is it simply about there physically being a module in the cage, or is > it also about being able to drive that module? If it is just about > there being a module in the cage, then vacant/empty is good. If we > also want to say that we have been able to read out the EEPROM and > determined the module will work in combination with the PCS and MAC, > then i would probably use a different name. "usable", "compatible"? So the direction I have in mind in the first one. We have a device with a port that's an SFP cage. It has its set of capabilities, in this case they are a set of phy_interface_t that you can use in that cage. It's empty/vacane withouy any modue in it. Now you insert a module, the SFP cages is still there, same capabilities, but there's a new physical front-facing MDI, with its set of capabilities (baseT, 100FX, you name it). Now the SFP cage isn't vacant anymore. I'd say, if we can't read the eeprom, or if we insert an incompatible module (10G module on 1000BaseX port for example), the SFP cage stays non-vacant. The port corresponding to the module itself may or may not be created (depending on the error, the more we can tell the user the better IMO). > > Either way, i think the code either needs simplifying, or made more > complex. So, I think the direction will be "let's make it simpler" :) Maxime > > Andrew >