From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 A62562A1AA for ; Wed, 13 Aug 2025 01:15:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755047716; cv=none; b=rLdbVc7V+VYWpanSFNzn+IrgwiiQCg1BcJOwvz2Vd98dTnIeIRGyBLxM1TcLcjBo2upMEWe1gyQ9/hUf5dDXXQwc8R5hbjdPUHqNVL3aHc7gh3DR4kwY8nhlTwHjyIj5ifzT5ly145ywbOxGADiy8Xc+w2XLtb4yaKAPleRkohU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755047716; c=relaxed/simple; bh=MJ9VWpz1qUr5xoTXEcGHgxXNuvgQFJoO8s2+y+R7Rm0=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=Ybiu7qk7Cwz1a4V0oyYfQawzw5rmsjDwA37jVi7MQMFuqw4oUcYWukl6prpTYYNEvOnwY4lN8+tRx4nSpiK0jjF4pjnBQhJLG1OtigVO4byRqDFZ+ltqa3+JkHSnJbGdKN3RP08fTEt+4A3q2/SpDoix5shmmNl8iT6atlD6u1A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=t9EW8JTP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="t9EW8JTP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C07AAC4CEF0; Wed, 13 Aug 2025 01:15:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1755047716; bh=MJ9VWpz1qUr5xoTXEcGHgxXNuvgQFJoO8s2+y+R7Rm0=; h=Date:From:To:Cc:Subject:From; b=t9EW8JTPYcjKb7bjHaV/vAtwr+R+9ZghuNXt0lnTFplKrHLt5iVRMRqqOP4uqeTFz pBFBBwoniAwU+oDAbZAVdakPYMplKMmlyFpTR7HnvPAuiZYdUn1DSwiCYbH4FIlfCr K11/rC+1Q1qOymVmOZ5AX5Hn3gO90aMvma1Hu3p6fdBCKR5K9OYPx7yONON9F2V1Hs D/8iW2grCKUfzq85BGcMm/jp0zRsOF4uInsdVxD97eXsId2CWAqRCI6dIcMfQXhyGS r7m3zvGM4IIxHNLns8SoriYJaN/ET55AGgOkMl38aWrVuPfP0f2/P550JYL7JoQtMo BArt1S9qerr/w== Date: Wed, 13 Aug 2025 08:58:06 +0800 From: Jisheng Zhang To: Andrew Lunn , Russell King , Florian Fainelli , Jakub Kicinski , "David S. Miller" Cc: netdev@vger.kernel.org Subject: [RFC] mdio demux multiplexer driver Message-ID: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hi, Assume we have the following implementation: ---------- |mmio reg| ---------- | -------- | ------- | MAC0 |--MDIO-----| PHY | -------- | | ------- | | -------- | | ------- | MAC1 |-- ----| PHY | -------- ------- Both MAC0 and MAC1 have MDIO bus masters, and tie together to a single set of clock and data lines, which go to some PHYs. While there's a mmio reg to control which MAC mdio master can operate the single mdio clock and data lines, so only one MAC can operate the mdio clock and data lines. We also need to fully support three use cases: only MAC0 + PHY is used on board; only MAC1 + PHY is used on board; MAC0 + MAC1 + PHYs are all used. How can this be modeled in current mdio? It looks like a kind of demux, so my initial plan is implement a mdio-demux driver, which firstly switch mdio master then call the master's corresponding ops such as read, write, read_c45, write_c45 and so on. What do you think about this RFC? Any comment/suggestion is appreciated! thanks