| Message ID | 20240804233835.223460-7-fujita.tomonori@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: phy: add Applied Micro QT2025 PHY driver | expand |
> +#[vtable] > +impl Driver for PhyQT2025 { > + const NAME: &'static CStr = c_str!("QT2025 10Gpbs SFP+"); > + const PHY_DEVICE_ID: phy::DeviceId = phy::DeviceId::new_with_exact_mask(0x0043A400); > + > + fn probe(dev: &mut phy::Device) -> Result<()> { > + // The hardware is configurable? > + let hw_id = dev.read(C45::new(Mmd::PMAPMD, 0xd001))?; > + if (hw_id >> 8) & 0xff != 0xb3 { > + return Ok(()); > + } I don't understand this bit of code. At a guess, if the upper bytes of that register is not 0xb3, the firmware has already been loaded into the device? > + > + // The 8051 will remain in the reset state. > + dev.write(C45::new(Mmd::PMAPMD, 0xC300), 0x0000)?; > + // Configure the 8051 clock frequency. > + dev.write(C45::new(Mmd::PMAPMD, 0xC302), 0x0004)?; > + // Non loopback mode. > + dev.write(C45::new(Mmd::PMAPMD, 0xC319), 0x0038)?; > + // Global control bit to select between LAN and WAN (WIS) mode. > + dev.write(C45::new(Mmd::PMAPMD, 0xC31A), 0x0098)?; > + dev.write(C45::new(Mmd::PCS, 0x0026), 0x0E00)?; > + dev.write(C45::new(Mmd::PCS, 0x0027), 0x0893)?; > + dev.write(C45::new(Mmd::PCS, 0x0028), 0xA528)?; > + dev.write(C45::new(Mmd::PCS, 0x0029), 0x0003)?; 802.3 says: 3.38 through 3.4110/25GBASE-R PCS test pattern seed B ???? > + // Configure transmit and recovered clock. > + dev.write(C45::new(Mmd::PMAPMD, 0xC30A), 0x06E1)?; > + // The 8051 will finish the reset state. > + dev.write(C45::new(Mmd::PMAPMD, 0xC300), 0x0002)?; > + // The 8051 will start running from the boot ROM. > + dev.write(C45::new(Mmd::PCS, 0xE854), 0x00C0)?; > + > + let fw = Firmware::request(c_str!("qt2025-2.0.3.3.fw"), dev.as_ref())?; > + if fw.data().len() > SZ_16K + SZ_8K { > + return Err(code::EFBIG); > + } > + > + // The 24kB of program memory space is accessible by MDIO. > + // The first 16kB of memory is located in the address range 3.8000h - 3.BFFFh. > + // The next 8kB of memory is located at 4.8000h - 4.9FFFh. > + let mut j = SZ_32K; > + for (i, val) in fw.data().iter().enumerate() { > + if i == SZ_16K { > + j = SZ_32K; > + } > + > + let mmd = if i < SZ_16K { Mmd::PCS } else { Mmd::PHYXS }; > + dev.write( > + C45::new(mmd, j as u16), > + <u8 as Into<u16>>::into(*val).to_le(), This is well past my level of Rust. I assume fw.data is a collection of bytes, and you enumerate it as bytes. A byte has no endiannes, so why do you need to convert it to little endian? Andrew
On Fri, 16 Aug 2024 03:45:09 +0200 Andrew Lunn <andrew@lunn.ch> wrote: >> +#[vtable] >> +impl Driver for PhyQT2025 { >> + const NAME: &'static CStr = c_str!("QT2025 10Gpbs SFP+"); >> + const PHY_DEVICE_ID: phy::DeviceId = phy::DeviceId::new_with_exact_mask(0x0043A400); >> + >> + fn probe(dev: &mut phy::Device) -> Result<()> { >> + // The hardware is configurable? >> + let hw_id = dev.read(C45::new(Mmd::PMAPMD, 0xd001))?; >> + if (hw_id >> 8) & 0xff != 0xb3 { >> + return Ok(()); >> + } > > I don't understand this bit of code. At a guess, if the upper bytes of > that register is not 0xb3, the firmware has already been loaded into > the device? I've just added debug code and found that the upper bytes of the register is 0xb3 even after loading the firmware. I checked the original code again and found that if the bytes isn't 0xb3, the driver initialization fails. I guess that the probe should return an error here (ENODEV?). >> + dev.write(C45::new(Mmd::PCS, 0x0026), 0x0E00)?; >> + dev.write(C45::new(Mmd::PCS, 0x0027), 0x0893)?; >> + dev.write(C45::new(Mmd::PCS, 0x0028), 0xA528)?; >> + dev.write(C45::new(Mmd::PCS, 0x0029), 0x0003)?; > > 802.3 says: > > 3.38 through 3.4110/25GBASE-R PCS test pattern seed B ???? Yeah, strange. But I can't find any hints on them in the datasheet or the original code. >> + let fw = Firmware::request(c_str!("qt2025-2.0.3.3.fw"), dev.as_ref())?; >> + if fw.data().len() > SZ_16K + SZ_8K { >> + return Err(code::EFBIG); >> + } >> + >> + // The 24kB of program memory space is accessible by MDIO. >> + // The first 16kB of memory is located in the address range 3.8000h - 3.BFFFh. >> + // The next 8kB of memory is located at 4.8000h - 4.9FFFh. >> + let mut j = SZ_32K; >> + for (i, val) in fw.data().iter().enumerate() { >> + if i == SZ_16K { >> + j = SZ_32K; >> + } >> + >> + let mmd = if i < SZ_16K { Mmd::PCS } else { Mmd::PHYXS }; >> + dev.write( >> + C45::new(mmd, j as u16), >> + <u8 as Into<u16>>::into(*val).to_le(), > > This is well past my level of Rust. I assume fw.data is a collection > of bytes, and you enumerate it as bytes. A byte has no endiannes, so > why do you need to convert it to little endian? I messed up here. No need. I'll remove the conversion in the next version. Thanks!
On Fri, Aug 16, 2024 at 06:17:10AM +0000, FUJITA Tomonori wrote: > On Fri, 16 Aug 2024 03:45:09 +0200 > Andrew Lunn <andrew@lunn.ch> wrote: > > >> +#[vtable] > >> +impl Driver for PhyQT2025 { > >> + const NAME: &'static CStr = c_str!("QT2025 10Gpbs SFP+"); > >> + const PHY_DEVICE_ID: phy::DeviceId = phy::DeviceId::new_with_exact_mask(0x0043A400); > >> + > >> + fn probe(dev: &mut phy::Device) -> Result<()> { > >> + // The hardware is configurable? > >> + let hw_id = dev.read(C45::new(Mmd::PMAPMD, 0xd001))?; > >> + if (hw_id >> 8) & 0xff != 0xb3 { > >> + return Ok(()); > >> + } > > > > I don't understand this bit of code. At a guess, if the upper bytes of > > that register is not 0xb3, the firmware has already been loaded into > > the device? > > I've just added debug code and found that the upper bytes of the > register is 0xb3 even after loading the firmware. > > I checked the original code again and found that if the bytes isn't > 0xb3, the driver initialization fails. I guess that the probe should > return an error here (ENODEV?). O.K. Maybe add a comment that the vendor driver does this, but we have no idea why. > > >> + dev.write(C45::new(Mmd::PCS, 0x0026), 0x0E00)?; > >> + dev.write(C45::new(Mmd::PCS, 0x0027), 0x0893)?; > >> + dev.write(C45::new(Mmd::PCS, 0x0028), 0xA528)?; > >> + dev.write(C45::new(Mmd::PCS, 0x0029), 0x0003)?; > > > > 802.3 says: > > > > 3.38 through 3.4110/25GBASE-R PCS test pattern seed B ???? > > Yeah, strange. But I can't find any hints on them in the datasheet or > the original code. Seems unlikely it is seeding anything. So i guess they have reused the registers for something else. This is actually a bit odd, because all the other registers are in the ranges reserved for vendor usage. If these were legitimate register usage, i would of suggested adding #define to include/uapi/linux/mdio.h for them. Andrew
On Fri, 16 Aug 2024 22:47:04 +0200 Andrew Lunn <andrew@lunn.ch> wrote: >> >> + fn probe(dev: &mut phy::Device) -> Result<()> { >> >> + // The hardware is configurable? >> >> + let hw_id = dev.read(C45::new(Mmd::PMAPMD, 0xd001))?; >> >> + if (hw_id >> 8) & 0xff != 0xb3 { >> >> + return Ok(()); >> >> + } >> > >> > I don't understand this bit of code. At a guess, if the upper bytes of >> > that register is not 0xb3, the firmware has already been loaded into >> > the device? >> >> I've just added debug code and found that the upper bytes of the >> register is 0xb3 even after loading the firmware. >> >> I checked the original code again and found that if the bytes isn't >> 0xb3, the driver initialization fails. I guess that the probe should >> return an error here (ENODEV?). > > O.K. Maybe add a comment that the vendor driver does this, but we have > no idea why. Yes, added the comment. >> >> + dev.write(C45::new(Mmd::PCS, 0x0026), 0x0E00)?; >> >> + dev.write(C45::new(Mmd::PCS, 0x0027), 0x0893)?; >> >> + dev.write(C45::new(Mmd::PCS, 0x0028), 0xA528)?; >> >> + dev.write(C45::new(Mmd::PCS, 0x0029), 0x0003)?; >> > >> > 802.3 says: >> > >> > 3.38 through 3.4110/25GBASE-R PCS test pattern seed B ???? >> >> Yeah, strange. But I can't find any hints on them in the datasheet or >> the original code. > > Seems unlikely it is seeding anything. So i guess they have reused the > registers for something else. This is actually a bit odd, because all > the other registers are in the ranges reserved for vendor usage. > > If these were legitimate register usage, i would of suggested adding > #define to include/uapi/linux/mdio.h for them. I see.
diff --git a/MAINTAINERS b/MAINTAINERS index f0639034ef96..d25a529f6e48 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1609,6 +1609,13 @@ F: Documentation/admin-guide/perf/xgene-pmu.rst F: Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt F: drivers/perf/xgene_pmu.c +APPLIED MICRO QT2025 PHY DRIVER +M: FUJITA Tomonori <fujita.tomonori@gmail.com> +L: netdev@vger.kernel.org +L: rust-for-linux@vger.kernel.org +S: Maintained +F: drivers/net/phy/qt2025.rs + APTINA CAMERA SENSOR PLL M: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> L: linux-media@vger.kernel.org diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 7fddc8306d82..e0ff386d90cd 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -109,6 +109,12 @@ config ADIN1100_PHY Currently supports the: - ADIN1100 - Robust,Industrial, Low Power 10BASE-T1L Ethernet PHY +config AMCC_QT2025_PHY + tristate "AMCC QT2025 PHY" + depends on RUST_PHYLIB_ABSTRACTIONS + help + Adds support for the Applied Micro Circuits Corporation QT2025 PHY. + source "drivers/net/phy/aquantia/Kconfig" config AX88796B_PHY diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile index 202ed7f450da..461d6a3b9997 100644 --- a/drivers/net/phy/Makefile +++ b/drivers/net/phy/Makefile @@ -36,6 +36,7 @@ obj-$(CONFIG_ADIN_PHY) += adin.o obj-$(CONFIG_ADIN1100_PHY) += adin1100.o obj-$(CONFIG_AIR_EN8811H_PHY) += air_en8811h.o obj-$(CONFIG_AMD_PHY) += amd.o +obj-$(CONFIG_AMCC_QT2025_PHY) += qt2025.o obj-$(CONFIG_AQUANTIA_PHY) += aquantia/ ifdef CONFIG_AX88796B_RUST_PHY obj-$(CONFIG_AX88796B_PHY) += ax88796b_rust.o diff --git a/drivers/net/phy/qt2025.rs b/drivers/net/phy/qt2025.rs new file mode 100644 index 000000000000..ef245e8d4161 --- /dev/null +++ b/drivers/net/phy/qt2025.rs @@ -0,0 +1,93 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (C) Tehuti Networks Ltd. +// Copyright (C) 2024 FUJITA Tomonori <fujita.tomonori@gmail.com> + +//! Applied Micro Circuits Corporation QT2025 PHY driver +use kernel::c_str; +use kernel::error::code; +use kernel::firmware::Firmware; +use kernel::net::phy::{ + self, + reg::{Mmd, C45}, + DeviceId, Driver, +}; +use kernel::prelude::*; +use kernel::sizes::{SZ_16K, SZ_32K, SZ_8K}; + +kernel::module_phy_driver! { + drivers: [PhyQT2025], + device_table: [ + DeviceId::new_with_driver::<PhyQT2025>(), + ], + name: "qt2025_phy", + author: "FUJITA Tomonori <fujita.tomonori@gmail.com>", + description: "AMCC QT2025 PHY driver", + license: "GPL", + firmware: ["qt2025-2.0.3.3.fw"], +} + +struct PhyQT2025; + +#[vtable] +impl Driver for PhyQT2025 { + const NAME: &'static CStr = c_str!("QT2025 10Gpbs SFP+"); + const PHY_DEVICE_ID: phy::DeviceId = phy::DeviceId::new_with_exact_mask(0x0043A400); + + fn probe(dev: &mut phy::Device) -> Result<()> { + // The hardware is configurable? + let hw_id = dev.read(C45::new(Mmd::PMAPMD, 0xd001))?; + if (hw_id >> 8) & 0xff != 0xb3 { + return Ok(()); + } + + // The 8051 will remain in the reset state. + dev.write(C45::new(Mmd::PMAPMD, 0xC300), 0x0000)?; + // Configure the 8051 clock frequency. + dev.write(C45::new(Mmd::PMAPMD, 0xC302), 0x0004)?; + // Non loopback mode. + dev.write(C45::new(Mmd::PMAPMD, 0xC319), 0x0038)?; + // Global control bit to select between LAN and WAN (WIS) mode. + dev.write(C45::new(Mmd::PMAPMD, 0xC31A), 0x0098)?; + dev.write(C45::new(Mmd::PCS, 0x0026), 0x0E00)?; + dev.write(C45::new(Mmd::PCS, 0x0027), 0x0893)?; + dev.write(C45::new(Mmd::PCS, 0x0028), 0xA528)?; + dev.write(C45::new(Mmd::PCS, 0x0029), 0x0003)?; + // Configure transmit and recovered clock. + dev.write(C45::new(Mmd::PMAPMD, 0xC30A), 0x06E1)?; + // The 8051 will finish the reset state. + dev.write(C45::new(Mmd::PMAPMD, 0xC300), 0x0002)?; + // The 8051 will start running from the boot ROM. + dev.write(C45::new(Mmd::PCS, 0xE854), 0x00C0)?; + + let fw = Firmware::request(c_str!("qt2025-2.0.3.3.fw"), dev.as_ref())?; + if fw.data().len() > SZ_16K + SZ_8K { + return Err(code::EFBIG); + } + + // The 24kB of program memory space is accessible by MDIO. + // The first 16kB of memory is located in the address range 3.8000h - 3.BFFFh. + // The next 8kB of memory is located at 4.8000h - 4.9FFFh. + let mut j = SZ_32K; + for (i, val) in fw.data().iter().enumerate() { + if i == SZ_16K { + j = SZ_32K; + } + + let mmd = if i < SZ_16K { Mmd::PCS } else { Mmd::PHYXS }; + dev.write( + C45::new(mmd, j as u16), + <u8 as Into<u16>>::into(*val).to_le(), + )?; + + j += 1; + } + // The 8051 will start running from SRAM. + dev.write(C45::new(Mmd::PCS, 0xE854), 0x0040)?; + + Ok(()) + } + + fn read_status(dev: &mut phy::Device) -> Result<u16> { + dev.genphy_read_status::<C45>() + } +}
This driver supports Applied Micro Circuits Corporation QT2025 PHY, based on a driver for Tehuti Networks TN40xx chips. The original driver for TN40xx chips supports multiple PHY hardware (AMCC QT2025, TI TLK10232, Aqrate AQR105, and Marvell 88X3120, 88X3310, and MV88E2010). This driver is extracted from the original driver and modified to a PHY driver in Rust. This has been tested with Edimax EN-9320SFP+ 10G network adapter. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> --- MAINTAINERS | 7 +++ drivers/net/phy/Kconfig | 6 +++ drivers/net/phy/Makefile | 1 + drivers/net/phy/qt2025.rs | 93 +++++++++++++++++++++++++++++++++++++++ 4 files changed, 107 insertions(+) create mode 100644 drivers/net/phy/qt2025.rs