이더넷 PHY (Physical Layer)

이더넷 PHY는 MAC이 만든 프레임을 실제 전기·광 신호로 바꾸고, 반대로 선로에서 들어온 신호를 디지털 비트스트림으로 복원하는 계층입니다. 이 문서는 PHY의 역할과 계층 경계, MDIO 레지스터(Register) 접근, Clause 22/45와 MMD, phylib/phylink 수명주기, 분리형 PCS와 phylink_pcs, SerDes/SFP, EEE·downshift·EDPD·FEC 같은 기능 튜닝, Device Tree와 보드 bring-up, 신호 무결성(Integrity), 링크 장애 디버깅(Debugging) 절차를 커널 드라이버와 하드웨어 설계 관점에서 최대한 상세히 정리합니다.

개요

이더넷 PHY의 핵심 임무는 세 가지입니다. 첫째, MAC이 제공한 병렬 또는 직렬 디지털 데이터를 선로 규격에 맞는 전기·광 신호로 변환합니다. 둘째, 상대편 장치와 링크 속도, 듀플렉스, pause, FEC 같은 능력을 협상합니다. 셋째, 온도·전압·신호 품질 변화에 따라 CDR(Clock and Data Recovery), equalization, amplitude 설정을 조정해 실제 배선 위에서 동작하도록 만듭니다.

즉 PHY는 단순한 "포트"가 아니라, 아날로그 회로와 디지털 상태 머신이 결합된 독립 장치입니다. 링크가 안 올라오거나 CRC가 증가할 때는 소프트웨어만 볼 일이 아니라, PHY 내부 지연 보상, reference clock, magnetics, 케이블 품질, 상대편 포트의 협상 정책까지 같이 봐야 합니다.

MAC과 PHY의 경계

문제를 빨리 좁히려면 "어디까지가 MAC이고 어디부터 PHY인가"를 먼저 구분해야 합니다. MAC은 프레임 헤더, 주소 필터, pause 처리, DMA와 큐를 담당하고, PHY는 부호화/직렬화(Serialization)/클럭 복구/매체 송수신을 맡습니다. 1G 이하 임베디드 보드에서는 MAC과 외부 PHY가 RGMII로 연결되는 경우가 많고, 서버 NIC에서는 MAC/PCS가 SoC나 NIC 내부에 있고 외부 모듈은 PMD 역할만 하는 경우도 흔합니다.

• MDIO는 제어면입니다. 데이터 패킷(Packet)은 RGMII/SGMII 같은 MAC-PHY 인터페이스를 지나고, 설정과 상태 조회만 MDIO를 통합니다.
• PCS와 PMA는 종종 MAC 안에도 존재합니다. 특히 10G 이상 SerDes 기반 장비에서는 PHY가 외부 칩이 아니라 모듈이나 PMD 수준으로 축소될 수 있습니다.
• 링크 품질 문제는 경계에 걸쳐 나타납니다. 잘못된 phy-mode는 MAC 로그로 보이고, 원인은 PHY 내부 지연 혹은 PCB 스큐일 수 있습니다.

PHY 내부 하위 계층

이더넷 PHY를 깊게 이해하려면 PHY를 단일 칩으로 보지 말고 PCS, PMA, PMD, MDI로 나눠 생각해야 합니다. 1000BASE-T 같은 구리 PHY는 PCS에서 부호화와 auto-negotiation control word 처리를 하고, PMA/PMD에서 echo cancellation, NEXT/FEXT 제거, adaptive equalization, timing recovery 같은 DSP 처리를 수행합니다. 반면 광 링크는 PMD가 레이저 드라이버, CDR, 광 수신기와 더 강하게 결합됩니다.

즉 "링크가 안 붙는다"는 하나의 증상도 PCS 문제인지, PMA의 CDR lock 실패인지, PMD의 광 세기 부족인지, MDI 쪽 배선 문제인지에 따라 전혀 다른 디버깅 절차가 필요합니다. 초기에 이 구분을 해 두면 드라이버와 보드 설계 문제를 훨씬 빠르게 분리할 수 있습니다.

MDIO와 표준 레지스터

MDIO(Management Data Input/Output)는 PHY를 설정하고 상태를 읽는 가장 기본적인 관리 경로입니다. 10/100/1000 PHY에서는 Clause 22가, 고속 PHY와 복잡한 서브블록을 가진 장치에서는 Clause 45가 많이 쓰입니다. Clause 22는 5비트 PHY 주소와 5비트 레지스터 번호만 다루지만, Clause 45는 MMD(devad) 개념을 도입해 PMA/PCS/AN 등 기능 블록별 레지스터 공간을 분리합니다.

MDIO 물리 인터페이스

MDIO 버스는 두 개의 신호선으로 구성됩니다. MDC(Management Data Clock)는 MAC(또는 MDIO 컨트롤러)이 생성하는 단방향 클럭이고, MDIO(Management Data I/O)는 양방향 데이터 선입니다. 전기적으로 MDIO 선은 open-drain 방식이며 외부 pull-up 저항(1.5 kΩ ~ 10 kΩ)이 필요합니다. MDC의 최대 주파수는 IEEE 802.3에서 2.5 MHz로 규정하지만, 많은 PHY가 12.5 MHz 이상도 허용합니다. 보드 설계 시 pull-up 저항 값과 배선 길이가 잘못되면 특정 PHY만 간헐적으로 읽히지 않는 문제가 발생합니다.

MDIO 프레임 포맷

하나의 MDIO 트랜잭션은 직렬(serial)로 전송되는 프레임으로 구성됩니다. Clause 22 프레임은 총 64비트(프리앰블(Preamble) 32비트 + 프레임 32비트)이며, Clause 45는 주소 프레임과 데이터 프레임을 두 번에 나눠 보내 16비트 레지스터 주소 공간을 확보합니다.

리눅스 커널 MDIO API

리눅스 커널에서 MDIO 버스는 struct mii_bus로 추상화됩니다. MAC 드라이버나 전용 MDIO 컨트롤러 드라이버가 이 구조체를 등록하고, read와 write 콜백을 통해 실제 하드웨어 접근을 수행합니다. PHY 드라이버는 phy_read() / phy_write()를 통해 간접적으로 이 버스를 사용하며, Clause 45 접근은 phy_read_mmd() / phy_write_mmd()로 분리되어 있습니다.

/* MDIO 버스 등록 — MAC 또는 MDIO 컨트롤러 드라이버 */
struct mii_bus *bus = mdiobus_alloc();
bus->name   = "my-mdio";
bus->read   = my_mdio_read;    /* Clause 22 read 콜백 */
bus->write  = my_mdio_write;   /* Clause 22 write 콜백 */
bus->read_c45  = my_mdio_c45_read;  /* Clause 45 read 콜백 (v5.18+) */
bus->write_c45 = my_mdio_c45_write; /* Clause 45 write 콜백 (v5.18+) */
bus->parent = &pdev->dev;
bus->phy_mask = 0;  /* 0이면 모든 주소 스캔, 비트마스크로 특정 주소 제외 */
mdiobus_register(bus);

/* PHY 드라이버에서 레지스터 접근 */
int val = phy_read(phydev, MII_BMSR);            /* Clause 22 */
int pcs = phy_read_mmd(phydev, MDIO_MMD_PCS, 0x0001); /* Clause 45 */
phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x8000, 0x0001);  /* Clause 45 쓰기 */

/* Clause 22만 지원하는 PHY에서 간접 Clause 45 접근 (MII_MMD_CTRL/DATA) */
phy_write(phydev, MII_MMD_CTRL, devad);
phy_write(phydev, MII_MMD_DATA, reg);
phy_write(phydev, MII_MMD_CTRL, devad | MII_MMD_CTRL_NOINCR);
val = phy_read(phydev, MII_MMD_DATA);

mii_bus 수명주기와 등록 API

struct mii_bus는 MDIO 컨트롤러를 커널에 등록하는 핵심 구조체입니다. 할당부터 해제까지의 전체 수명주기와 각 필드의 역할을 이해해야 PHY 탐색, 주소 마스킹, reset 타이밍 같은 실무 문제를 올바르게 처리할 수 있습니다.

/* mii_bus 주요 필드 (include/linux/mdio.h, include/linux/phy.h) */
struct mii_bus {
    const char  *name;       /* 버스 이름 (sysfs에 표시) */
    char        id[MII_BUS_ID_SIZE]; /* 고유 ID (Device Tree에서 자동 생성) */
    struct device *parent;   /* 부모 디바이스 (MAC 또는 MDIO 컨트롤러) */
    void        *priv;       /* 드라이버 전용 데이터 */

    /* Clause 22 콜백: 반드시 구현해야 합니다 */
    int (*read)(struct mii_bus *bus, int addr, int regnum);
    int (*write)(struct mii_bus *bus, int addr, int regnum, u16 val);

    /* Clause 45 콜백 (v5.18+): NULL이면 Clause 45 미지원 */
    int (*read_c45)(struct mii_bus *bus, int addr, int devad, int regnum);
    int (*write_c45)(struct mii_bus *bus, int addr, int devad, int regnum, u16 val);

    /* PHY reset 콜백: 버스 등록 시 한 번 호출됩니다 */
    int (*reset)(struct mii_bus *bus);

    u32  phy_mask;   /* 비트가 1인 주소는 스캔에서 제외됩니다 */
    u32  phy_ignore; /* (v6.1+) phy_mask와 유사, 별도 용도 */

    struct mdio_device *mdio_map[PHY_MAX_ADDR]; /* 주소별 장치 맵 */
    struct mutex mdio_lock;  /* 버스 접근 직렬화 */
};

/* 완전한 mii_bus 등록/해제 수명주기 */
static int my_mdio_read(struct mii_bus *bus, int addr, int regnum)
{
    struct my_priv *priv = bus->priv;
    u32 cmd;

    /* MDIO 컨트롤러 레지스터에 읽기 명령 구성 */
    cmd = MDIO_CMD_READ | (addr << 5) | regnum;
    writel(cmd, priv->regs + MDIO_CMD_REG);

    /* 완료 대기 — 보통 수 us, 최대 수백 us */
    if (readl_poll_timeout(priv->regs + MDIO_STATUS_REG,
                          cmd, cmd & MDIO_DONE, 10, 10000))
        return -ETIMEDOUT;

    return readl(priv->regs + MDIO_DATA_REG) & 0xffff;
}

static int my_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 val)
{
    struct my_priv *priv = bus->priv;
    u32 cmd;

    cmd = MDIO_CMD_WRITE | (addr << 5) | regnum;
    writel(val, priv->regs + MDIO_DATA_REG);
    writel(cmd, priv->regs + MDIO_CMD_REG);

    return readl_poll_timeout(priv->regs + MDIO_STATUS_REG,
                              cmd, cmd & MDIO_DONE, 10, 10000)
           ? -ETIMEDOUT : 0;
}

static int my_probe(struct platform_device *pdev)
{
    struct mii_bus *bus;
    struct my_priv *priv;

    /* mdiobus_alloc_size(): priv 크기를 인자로 받아 한 번에 할당합니다 */
    bus = mdiobus_alloc_size(sizeof(*priv));
    if (!bus)
        return -ENOMEM;

    priv = bus->priv;     /* mdiobus_alloc_size가 priv 포인터를 설정합니다 */
    priv->regs = devm_ioremap_resource(&pdev->dev, ...);

    bus->name    = "my-soc-mdio";
    bus->parent  = &pdev->dev;
    bus->read    = my_mdio_read;
    bus->write   = my_mdio_write;
    bus->phy_mask = 0;  /* 모든 주소 스캔 */

    /* Device Tree 기반이면 of_mdiobus_register()로 DT 노드에서 PHY를 탐색합니다 */
    snprintf(bus->id, MII_BUS_ID_SIZE, "%s", pdev_name(pdev));
    return of_mdiobus_register(bus, pdev->dev.of_node);
}

static void my_remove(struct platform_device *pdev)
{
    struct mii_bus *bus = platform_get_drvdata(pdev);

    mdiobus_unregister(bus);  /* PHY 장치들을 모두 해제합니다 */
    mdiobus_free(bus);        /* mii_bus 메모리를 해제합니다 */
}

MDIO 버스 락킹과 직접 접근 API

MDIO 버스는 mdio_lock 뮤텍스로 보호됩니다. PHY 드라이버가 사용하는 phy_read()/phy_write()는 내부에서 이 락을 잡고 풀지만, 여러 레지스터를 원자적으로 읽거나 써야 하는 경우에는 락을 직접 관리해야 합니다.

/* 버스 레벨 접근 — 락 자동 관리 (일반적인 경우) */
int val = mdiobus_read(bus, phy_addr, regnum);      /* 락 잡기 → read → 풀기 */
mdiobus_write(bus, phy_addr, regnum, val);           /* 락 잡기 → write → 풀기 */

/* 버스 레벨 접근 — 락 없음 (호출자가 이미 락을 잡은 상태) */
int val = __mdiobus_read(bus, phy_addr, regnum);
__mdiobus_write(bus, phy_addr, regnum, val);

/* PHY 레벨 접근 — 락 자동 관리 */
int val = phy_read(phydev, regnum);                   /* 내부에서 mdio_lock 획득 */
phy_write(phydev, regnum, val);

/* 여러 레지스터를 원자적으로 접근해야 할 때 — 직접 락 관리 */
mutex_lock(&phydev->mdio.bus->mdio_lock);

/* 락 보유 중에는 __mdiobus_read/write 사용 */
int page = __mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, 0x1f);
__mdiobus_write(phydev->mdio.bus, phydev->mdio.addr, 0x1f, 0x0a43);
val = __mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, 0x19);
__mdiobus_write(phydev->mdio.bus, phydev->mdio.addr, 0x1f, page); /* 원래 페이지 복원 */

mutex_unlock(&phydev->mdio.bus->mdio_lock);

레지스터 수정 헬퍼 API

PHY 레지스터의 특정 비트만 변경하는 작업은 매우 빈번합니다. 매번 read-modify-write를 직접 구현하면 코드가 반복되고 실수가 생기므로, 커널은 phy_modify() 계열의 헬퍼를 제공합니다. 이 함수들은 내부에서 락을 잡고, 읽기-수정-쓰기를 원자적으로 수행합니다.

/* phy_modify(phydev, regnum, mask, set)
 * 동작: val = phy_read(reg); val = (val & ~mask) | set; phy_write(reg, val);
 * 반환값: 변경 전 원래 값 (음수면 에러) */

/* 예: BMCR에서 AN enable 비트를 끄고 강제 100M full duplex 설정 */
phy_modify(phydev, MII_BMCR,
           BMCR_ANENABLE | BMCR_SPEED100 | BMCR_FULLDPLX,  /* 클리어할 비트 마스크 */
           BMCR_SPEED100 | BMCR_FULLDPLX);                    /* 세팅할 비트 */

/* phy_set_bits(): 특정 비트만 세팅 (mask = set = bits) */
phy_set_bits(phydev, MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART);

/* phy_clear_bits(): 특정 비트만 클리어 (mask = bits, set = 0) */
phy_clear_bits(phydev, MII_BMCR, BMCR_PDOWN);

/* Clause 45 MMD 버전도 동일 패턴입니다 */
phy_modify_mmd(phydev, MDIO_MMD_PCS, 0x0001, mask, set);
phy_set_bits_mmd(phydev, MDIO_MMD_VEND1, 0x8000, BIT(3));
phy_clear_bits_mmd(phydev, MDIO_MMD_AN, 0x0010, BIT(0));

벤더 페이지 전환 API

Clause 22만 지원하는 PHY에서도 벤더 확장 레지스터에 접근해야 하는 경우가 흔합니다. 대부분의 벤더 PHY(Realtek, Marvell, Microchip 등)는 "페이지 전환 레지스터"(보통 reg 0x1f 또는 reg 0x16)를 통해 레지스터 공간을 확장합니다. 커널은 이를 안전하게 처리하기 위해 phy_read_paged() 계열 API를 제공합니다.

/* PHY 드라이버가 페이지 전환 방식을 선언합니다 (probe 시) */
static int my_phy_read_page(struct phy_device *phydev)
{
    return __phy_read(phydev, 0x1f);  /* 현재 페이지 번호 반환 */
}

static int my_phy_write_page(struct phy_device *phydev, int page)
{
    return __phy_write(phydev, 0x1f, page);  /* 페이지 전환 */
}

/* phy_driver 구조체에서 콜백 등록 */
static struct phy_driver my_phy_drivers[] = {{
    .phy_id      = 0x001cc840,
    .phy_id_mask = 0xffffff00,
    .name        = "My Vendor PHY",
    .read_page   = my_phy_read_page,
    .write_page  = my_phy_write_page,
    /* ... 기타 콜백 ... */
}};

/* 페이지 전환 API 사용 — 자동으로 페이지 전환 → 접근 → 원래 페이지 복원 */
int val = phy_read_paged(phydev, 0x0a43, 0x19);   /* 페이지 0x0a43, 레지스터 0x19 읽기 */
phy_write_paged(phydev, 0x0d08, 0x15, 0x1234);    /* 페이지 0x0d08, 레지스터 0x15 쓰기 */
phy_modify_paged(phydev, 0x0a46, 0x14, BIT(5), 0); /* 페이지 0x0a46에서 bit 5 클리어 */

/* 여러 레지스터를 같은 페이지에서 접근할 때 — 수동 페이지 선택 */
int old_page = phy_select_page(phydev, 0x0a43);  /* 락 획득 + 페이지 전환 */
if (old_page >= 0) {
    val = __phy_read(phydev, 0x19);               /* 락 보유 중이므로 __ 접두사 사용 */
    __phy_write(phydev, 0x1a, 0x00ff);
}
phy_restore_page(phydev, old_page, val);          /* 원래 페이지 복원 + 락 해제 */

MDIO 디바이스 모델과 mdio_driver

모든 PHY(phy_device)는 mdio_device를 내장하고 있으며, mdio_device는 MDIO 버스 위의 일반 장치입니다. PHY가 아닌 MDIO 장치(예: 이더넷 스위치, SFP 모듈 관리 칩, retimer)를 다룰 때는 mdio_driver를 사용합니다.

/* mdio_device: MDIO 버스 위 모든 장치의 기본 구조체 */
struct mdio_device {
    struct device   dev;
    struct mii_bus *bus;         /* 소속 MDIO 버스 */
    int            addr;         /* MDIO 주소 (0..31) */
    int            flags;        /* MDIO_DEVICE_FLAG_* */
    struct gpio_desc *reset_gpio; /* reset GPIO (DT에서 파싱) */
    unsigned int   reset_assert_delay;   /* reset assert 유지 시간 (us) */
    unsigned int   reset_deassert_delay; /* reset deassert 후 대기 시간 (us) */
};

/* phy_device는 mdio_device를 내장합니다 */
struct phy_device {
    struct mdio_device mdio;     /* 첫 번째 멤버 — 구조체 캐스팅 가능 */
    struct phy_driver *drv;
    u32  phy_id;
    int  speed, duplex;
    int  link;
    /* ... 수십 개의 상태 필드 ... */
};

/* PHY가 아닌 MDIO 장치를 위한 드라이버 등록 예시 */
static int my_switch_probe(struct mdio_device *mdiodev)
{
    /* mdiodev->bus, mdiodev->addr를 사용해 레지스터 접근 */
    int id = mdiobus_read(mdiodev->bus, mdiodev->addr, 0x00);
    dev_info(&mdiodev->dev, "switch ID: 0x%04x\n", id);
    return 0;
}

static const struct of_device_id my_switch_of_match[] = {
    { .compatible = "my,switch-chip" },
    { }
};

static struct mdio_driver my_switch_driver = {
    .mdiodrv.driver = {
        .name           = "my-switch",
        .of_match_table = my_switch_of_match,
    },
    .probe = my_switch_probe,
};
mdio_module_driver(my_switch_driver);

MDIO API 실전 패턴

PHY 드라이버와 MAC 드라이버에서 가장 자주 사용되는 MDIO 접근 패턴들을 정리합니다. 각 패턴은 실제 커널 드라이버에서 반복적으로 나타나는 코드를 단순화한 것입니다.

/* ━━━━━━ 패턴 1: PHY ID 읽기와 검증 ━━━━━━ */
static u32 read_phy_id(struct phy_device *phydev)
{
    int id1 = phy_read(phydev, MII_PHYSID1);  /* reg 0x02 */
    int id2 = phy_read(phydev, MII_PHYSID2);  /* reg 0x03 */

    if (id1 < 0 || id2 < 0)
        return 0xffffffff;    /* 읽기 실패 — 버스 미연결 가능 */

    return (id1 << 16) | id2;   /* 예: RTL8211F = 0x001cc916 */
}

/* ━━━━━━ 패턴 2: 소프트 리셋과 완료 대기 ━━━━━━ */
static int my_phy_soft_reset(struct phy_device *phydev)
{
    int ret;

    phy_set_bits(phydev, MII_BMCR, BMCR_RESET);

    /* BMCR_RESET 비트가 자동으로 0이 될 때까지 대기 (최대 500ms) */
    ret = phy_read_poll_timeout(phydev, MII_BMCR, ret,
                                !(ret & BMCR_RESET),
                                1000, 500000, false);
    if (ret)
        phydev_err(phydev, "soft reset timeout\n");

    return ret;
}

/* ━━━━━━ 패턴 3: 링크 상태 확인 (래치 비트 고려) ━━━━━━ */
static bool check_link_status(struct phy_device *phydev)
{
    int bmsr;

    /* 첫 번째 읽기: 래치된 값을 소모합니다 */
    bmsr = phy_read(phydev, MII_BMSR);
    if (bmsr < 0)
        return false;

    /* 두 번째 읽기: 현재 링크 상태가 반영됩니다 */
    bmsr = phy_read(phydev, MII_BMSR);
    return bmsr >= 0 && (bmsr & BMSR_LSTATUS);
}

/* ━━━━━━ 패턴 4: AN 재시작과 완료 대기 ━━━━━━ */
static int restart_and_wait_an(struct phy_device *phydev)
{
    int ret;

    /* AN enable + restart AN 비트를 동시에 세팅합니다 */
    phy_set_bits(phydev, MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART);

    /* AN complete 비트 대기 — 케이블 길이와 상대편 PHY에 따라 수 초 */
    ret = phy_read_poll_timeout(phydev, MII_BMSR, ret,
                                ret & BMSR_ANEGCOMPLETE,
                                50000, 5000000, false);
    return ret;
}

/* ━━━━━━ 패턴 5: loopback 설정 (PHY 내부 루프백) ━━━━━━ */
static int set_phy_loopback(struct phy_device *phydev, bool enable)
{
    if (enable)
        return phy_set_bits(phydev, MII_BMCR, BMCR_LOOPBACK);
    else
        return phy_clear_bits(phydev, MII_BMCR, BMCR_LOOPBACK);
}

/* ━━━━━━ 패턴 6: 벤더 확장 레지스터로 RGMII 지연 설정 ━━━━━━ */
/* Realtek RTL8211F 기준 예시 */
static int rtl8211f_set_rgmii_delay(struct phy_device *phydev, bool tx, bool rx)
{
    u16 val = 0;

    if (tx) val |= BIT(1);   /* TX delay enable */
    if (rx) val |= BIT(0);   /* RX delay enable */

    return phy_modify_paged(phydev, 0x0d08, 0x11,
                            BIT(1) | BIT(0), val);
}

/* ━━━━━━ 패턴 7: Clause 45 EEE 광고 능력 설정 ━━━━━━ */
static int set_eee_advertisement(struct phy_device *phydev, bool enable_1g)
{
    u16 adv = 0;

    if (enable_1g)
        adv = MDIO_EEE_1000T;

    /* MMD 7 (AN), 레지스터 0x003c: EEE Advertisement */
    return phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, adv);
}

MDIO 에러 처리와 디버깅 패턴

MDIO 접근은 실패할 수 있습니다. 버스 타임아웃, PHY 미응답(0xffff), reset 미완료 등이 흔한 원인입니다. 커널 MDIO API는 에러 시 음수를 반환하고, 일부 PHY는 미연결 주소에서 0xffff를 돌려줍니다. 올바른 에러 처리 패턴을 따르지 않으면 잘못된 레지스터 값으로 PHY를 설정해 버리는 사고가 생깁니다.

/* 올바른 에러 처리 패턴 */
static int my_phy_config(struct phy_device *phydev)
{
    int ret;

    /* phy_read()는 에러 시 음수, 성공 시 0..0xffff */
    ret = phy_read(phydev, MII_BMSR);
    if (ret < 0) {
        phydev_err(phydev, "BMSR read failed: %d\n", ret);
        return ret;
    }

    /* 0xffff는 PHY 미연결 또는 버스 문제를 의미할 수 있습니다 */
    if (ret == 0xffff) {
        phydev_warn(phydev, "BMSR all-ones — PHY not responding\n");
        return -ENODEV;
    }

    /* phy_modify()는 에러 시 음수, 성공 시 변경 전 원래 값 */
    ret = phy_modify(phydev, MII_BMCR, BMCR_PDOWN, 0);
    if (ret < 0)
        return ret;

    /* phy_write()는 에러 시 음수, 성공 시 0 */
    ret = phy_write(phydev, MII_ADVERTISE, ADVERTISE_ALL | ADVERTISE_CSMA);
    return ret;
}

/* 디버깅 시 레지스터 덤프 패턴 */
static void dump_phy_regs(struct phy_device *phydev)
{
    int i, val;

    phydev_info(phydev, "=== PHY register dump (Clause 22) ===\n");
    for (i = 0; i < 32; i++) {
        val = phy_read(phydev, i);
        if (val < 0)
            phydev_info(phydev, "  reg[0x%02x] = ERROR (%d)\n", i, val);
        else
            phydev_info(phydev, "  reg[0x%02x] = 0x%04x\n", i, val);
    }
}

BMCR과 BMSR 비트 맵

BMCR(Basic Mode Control Register, 0x00)과 BMSR(Basic Mode Status Register, 0x01)은 모든 Clause 22 PHY가 반드시 구현해야 하는 핵심 레지스터입니다. BMCR은 PHY 동작을 제어하고, BMSR은 현재 상태와 PHY의 능력을 보고합니다. 특히 BMSR의 링크 상태 비트(bit 2)는 래치(Latch) 동작을 하는 PHY가 많아서, 링크가 한 번이라도 끊어지면 0으로 래치되고 다시 읽어야 현재 상태가 반영됩니다.

# 네트워크 인터페이스가 어떤 PHY에 연결되었는지 확인
readlink -f /sys/class/net/eth0/phydev

# MDIO 버스에 보이는 PHY 목록과 ID 확인
grep . /sys/bus/mdio_bus/devices/*/phy_id

# 기본 링크 정보와 광고 능력 확인
ethtool eth0

# 드라이버가 찍는 PHY 로그 확인
dmesg | grep -i -E "phy|mdio|link"

Clause 45와 MMD 주소 공간

Clause 45의 핵심은 PHY를 하나의 납작한 레지스터 맵으로 보지 않고, 기능 블록별 MMD(Manageable Device)로 나누는 데 있습니다. 10G 이상 PHY나 복합 SerDes는 PMA/PMD, PCS, Auto-Negotiation, vendor-specific 블록이 분리되어 있어야 디버깅과 기능 확장이 가능합니다. 리눅스 커널도 이를 mdiobus_c45_read() 같은 API와 MDIO_MMD_* 매크로(Macro)로 반영합니다.

/* 개념 예시: Clause 45 MMD 직접 읽기 */
struct mii_bus *bus = phydev->mdio.bus;
int phy_addr = phydev->mdio.addr;

/* PCS status 1 */
int pcs_stat = mdiobus_c45_read(bus, phy_addr, MDIO_MMD_PCS, 0x0001);

/* AN status 1 */
int an_stat = mdiobus_c45_read(bus, phy_addr, MDIO_MMD_AN, 0x0001);

/* 벤더 확장 레지스터 */
int vend = mdiobus_c45_read(bus, phy_addr, MDIO_MMD_VEND1, 0x8050);

MDIO 버스 토폴로지(Topology)와 다중 PHY

실제 보드에서는 PHY가 하나만 있는 경우보다, 하나의 MDIO 버스에 여러 PHY와 스위치 내부 포트 PHY, retimer, 별도 PCS, SFP 관리 장치가 함께 매달리는 경우가 더 많습니다. MDIO는 I2C처럼 주소 기반 공유 버스이므로, 주소 충돌과 버스 길이, pull-up, reset 순서를 동시에 관리해야 합니다. 보드 bring-up에서 PHY 하나는 보이고 나머지는 안 보인다면 드라이버보다 먼저 버스 토폴로지를 확인해야 합니다.

특히 스위치 칩은 외부 포트의 copper PHY와 별개로 내부 포트용 PHY 또는 PCS를 또 가지고 있을 수 있습니다. 이 경우 운영체제는 "인터페이스 하나당 PHY 하나"라고 단순화해서 볼 수 없고, MDIO 버스 아래에 여러 개의 mdio_device와 phy_device가 계층적으로 배치됩니다. 주소가 겹치거나 reset 순서가 꼬이면 전혀 다른 장치에 레지스터를 쓰는 사고가 발생할 수 있습니다.

/* 개념 예시: 하나의 MDIO 버스에 다중 PHY가 매달린 경우 */
&mdio0 {
    #address-cells = <1>;
    #size-cells = <0>;

    phy0: ethernet-phy@1 {
        reg = <1>;
    };

    phy1: ethernet-phy@2 {
        reg = <2>;
    };

    switch0: ethernet-switch@10 {
        reg = <0x10>;
    };
};

• 주소는 0..31 범위만 있으므로, 슬롯 구조에서는 물리적으로 같은 주소를 재사용하고 mux로 분리하는 설계가 흔합니다.
• 0xffff / 0x0000 읽힘이 한 포트에서만 발생하면 전체 드라이버보다 해당 포트의 reset, pull-up, mux 선택 상태를 먼저 의심하세요.
• DSA 스위치가 개입되면 CPU 포트용 PCS, 사용자 포트용 PHY, 내부 MDIO 주소 맵을 각각 분리해서 이해해야 합니다.

MDIO mux 프레임워크

MDIO 주소 공간이 5비트(0~31)로 제한되기 때문에, 대규모 장비에서는 MDIO mux(멀티플렉서(Multiplexer))로 버스를 분할합니다. 리눅스 커널은 mdio-mux 프레임워크를 제공하며, GPIO mux(mdio-mux-gpio), MMIO mux(mdio-mux-mmio), I2C mux 등 다양한 구현이 있습니다. mux 뒤의 각 세그먼트(Segment)는 독립적인 MDIO 버스로 취급되므로, 같은 PHY 주소를 세그먼트마다 재사용할 수 있습니다.

/* Device Tree 예시: GPIO 기반 MDIO mux */
mdio-mux {
    compatible = "mdio-mux-gpio";
    gpios = <&gpio0 3 0>, <&gpio0 4 0>;  /* 2비트 선택선 → 4개 세그먼트 */
    mdio-parent-bus = <&mdio0>;
    #address-cells = <1>;
    #size-cells = <0>;

    mdio_seg0: mdio@0 {
        reg = <0>;
        #address-cells = <1>;
        #size-cells = <0>;
        phy_slot0: ethernet-phy@1 { reg = <1>; };
    };

    mdio_seg1: mdio@1 {
        reg = <1>;
        #address-cells = <1>;
        #size-cells = <0>;
        phy_slot1: ethernet-phy@1 { reg = <1>; }; /* 같은 주소 재사용 */
    };
};

PHY 탐지와 링크 수명주기

커널 관점에서 PHY 수명주기는 "발견, attach, 광고 설정, 상태 머신 시작, 링크 변화 통지, stop"의 반복입니다. probe 단계에서는 PHY 노드를 찾고 드라이버를 매칭합니다. 인터페이스가 올라갈 때는 phy_start() 또는 phylink_start()가 상태 머신을 돌리고, 링크가 변하면 드라이버는 speed, duplex, pause, interface mode를 MAC에 다시 적용해야 합니다.

1. 발견 — phy-handle 또는 firmware node를 통해 PHY를 찾고 ID를 읽어 드라이버를 매칭합니다.
2. attach — of_phy_connect() 또는 phylink 연결 함수로 MAC과 PHY를 연결합니다.
3. 정책 설정 — 지원 속도, EEE, pause, advertisement, in-band status 정책을 설정합니다.
4. 상태 머신 시작 — 인터페이스 up 시 PHY state machine이 주기적으로 링크를 확인합니다.
5. 링크 변화 통지 — adjust_link 혹은 mac_link_up() 경로에서 MAC 레지스터가 재설정됩니다.
6. 정지 — 인터페이스 down 시 queue 정지 후 PHY polling 또는 IRQ를 멈춥니다.

/* 개념 예시: phylib attach와 링크 수명주기 */
static void my_adjust_link(struct net_device *ndev)
{
    struct phy_device *phydev = ndev->phydev;

    if (!phydev->link) {
        my_mac_link_down(ndev);
        return;
    }

    my_mac_link_up(ndev, phydev->speed, phydev->duplex);
}

static int my_probe(struct platform_device *pdev)
{
    struct net_device *ndev = platform_get_drvdata(pdev);
    struct device_node *phy_np;
    struct phy_device *phydev;

    phy_np = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
    if (!phy_np)
        return -ENODEV;

    phydev = of_phy_connect(ndev, phy_np, &my_adjust_link, 0,
                            PHY_INTERFACE_MODE_RGMII_ID);
    of_node_put(phy_np);
    if (!phydev)
        return -ENODEV;

    phy_set_max_speed(phydev, SPEED_1000);
    phy_attached_info(phydev);
    return 0;
}

static int my_open(struct net_device *ndev)
{
    phy_start(ndev->phydev);
    netif_start_queue(ndev);
    return 0;
}

static int my_stop(struct net_device *ndev)
{
    netif_stop_queue(ndev);
    phy_stop(ndev->phydev);
    return 0;
}

PHY 상태 머신 내부 상태와 전이 규칙

커널 phylib는 phy_state 열거형(enum)으로 PHY의 수명 주기를 관리합니다. 각 상태는 phy_state_machine() 폴링 루프와 phy_start()/phy_stop() 등의 제어 호출에 의해 전이됩니다. 상태를 정확히 이해하면 드라이버 개발 시 발생하는 링크 불안정, 무한 재시도, 장치 미해제 같은 문제를 빠르게 진단할 수 있습니다.

phy_state 열거형 정의

/* include/linux/phy.h (v6.x 기준, 일부 커널 버전에서 이름이 다를 수 있음) */
enum phy_state {
    PHY_DOWN        = 0,  /* PHY가 비활성화됨 — 드라이버 미연결 또는 phy_detach() 완료 */
    PHY_READY       = 1,  /* phy_attach() 완료, phy_start() 대기 중 */
    PHY_HALTED      = 2,  /* phy_stop() 호출됨 — 폴링 중단, MAC 링크 다운 알림 완료 */
    PHY_ERROR       = 3,  /* config_init / read_status 등에서 복구 불가 오류 발생 */
    PHY_UP          = 4,  /* phy_start() 호출됨 — config_init 수행 후 협상 대기 */
    PHY_RUNNING     = 5,  /* 링크 UP — MAC이 속도/듀플렉스로 설정 완료 */
    PHY_NOLINK      = 6,  /* 협상 완료 후 링크 신호 없음 — 재협상 또는 케이블 대기 */
    PHY_CABLETEST   = 7,  /* ethtool cable test 진행 중 — 완료 후 PHY_UP 또는 PHY_HALTED로 복귀 */
};

각 상태의 상세 설명

다음은 각 상태가 실제로 의미하는 바와 전이 조건입니다.

• PHY_DOWN: phy_device가 시스템에 등록되었지만 MAC 드라이버와 아직 연결(attach)되지 않았거나, phy_detach()가 호출된 직후의 상태입니다. 이 상태에서는 폴링 타이머가 동작하지 않으며 MDIO 접근도 수행되지 않습니다.
• PHY_READY: phy_attach_direct() 완료 후 진입합니다. config_init()은 아직 호출되지 않았으므로 PHY 레지스터 초기화가 완료되지 않은 상태입니다. MAC 드라이버가 phy_start()를 호출할 때까지 대기합니다.
• PHY_HALTED: phy_stop() 호출에 의해 진입합니다. 폴링이 중단되고 MAC에는 링크 다운이 통보됩니다. 인터페이스가 ifconfig eth0 down 또는 드라이버 제거(rmmod) 시에 나타납니다.
• PHY_ERROR: config_init(), config_aneg(), read_status() 등에서 복구 불가능한 오류가 발생한 경우에 진입합니다. 드라이버는 이 상태를 감지해 재초기화를 시도하거나 에러 로그를 남겨야 합니다.
• PHY_UP: phy_start()가 호출된 후 phy_state_machine()이 config_init()과 config_aneg()를 실행하는 단계입니다. 아직 링크가 확립되지 않은 상태이므로 MAC에 링크 업 통보는 없습니다.
• PHY_RUNNING: read_status()가 링크 UP을 확인하고 MAC 드라이버의 adjust_link()를 통해 속도와 듀플렉스 설정이 완료된 상태입니다. 실제 패킷 송수신이 이루어집니다.
• PHY_NOLINK: 협상은 완료되었으나 물리적 신호(링크 비트)가 감지되지 않는 상태입니다. 케이블 미연결, SFP 모듈 문제, 원격 장치 다운 등이 원인이 됩니다. 폴링 주기마다 read_status()를 반복 호출합니다.
• PHY_CABLETEST: ethtool --cable-test 명령 또는 phy_start_cable_test() 호출 시 진입합니다. 케이블 진단이 완료되면 결과에 따라 PHY_UP 또는 PHY_HALTED로 전이됩니다.

상태 전이 다이어그램

phy_state_machine() 핵심 폴링 루프

phy_state_machine()은 PHY_POLL 모드에서 주기적으로 호출되며(기본 PHY_STATE_TIME = 1 Hz), 인터럽트 모드에서는 인터럽트 핸들러가 대신 트리거합니다. 현재 상태를 읽고 다음 상태를 결정하는 구조입니다.

/* drivers/net/phy/phy.c — 핵심 로직 요약 (실제 코드 단순화) */
void phy_state_machine(struct work_struct *work)
{
    struct delayed_work *dwork = to_delayed_work(work);
    struct phy_device *phydev =
        container_of(dwork, struct phy_device, state_queue);
    bool needs_aneg = false, do_suspend = false;
    enum phy_state old_state;
    int err = 0;

    mutex_lock(&phydev->lock);
    old_state = phydev->state;

    switch (phydev->state) {
    case PHY_DOWN:
    case PHY_READY:
        break;  /* 폴링 비활성 — 아무 동작 없음 */

    case PHY_UP:
        needs_aneg = true;  /* config_aneg() 호출 예약 */
        break;

    case PHY_NOLINK:
    case PHY_RUNNING:
        err = phy_check_link_status(phydev);  /* read_status() → adjust_link() */
        break;

    case PHY_HALTED:
        do_suspend = true;
        break;

    case PHY_ERROR:
        phy_error(phydev);  /* 오류 상태 유지 또는 리셋 시도 */
        break;

    default:
        break;
    }

    mutex_unlock(&phydev->lock);

    if (needs_aneg)
        err = phy_start_aneg(phydev);  /* config_init → config_aneg 순서로 호출 */

    if (do_suspend)
        phy_suspend(phydev);

    if (err == -ENODEV)
        phy_error(phydev);

    /* 다음 폴링 스케줄 (인터럽트 모드가 아닐 때만) */
    if (phy_polling_mode(phydev) && phy_is_started(phydev))
        phy_queue_state_machine(phydev, PHY_STATE_TIME);
}

phy_start() / phy_stop() 흐름

phy_start()와 phy_stop()은 MAC 드라이버가 인터페이스를 올리거나 내릴 때 직접 호출하는 진입점입니다. 두 함수는 뮤텍스(mutex)로 보호된 상태에서 phydev->state를 변경하고 phy_state_machine()을 즉시 스케줄합니다.

/* drivers/net/phy/phy.c */
void phy_start(struct phy_device *phydev)
{
    mutex_lock(&phydev->lock);

    if (phydev->state != PHY_READY &&
        phydev->state != PHY_HALTED) {
        WARN_ONCE(true, "phy_start() called in unexpected state %d\n",
                   phydev->state);
        mutex_unlock(&phydev->lock);
        return;
    }

    if (phydev->state == PHY_HALTED) {
        phydev->state = PHY_UP;
        phy_resume(phydev);    /* 드라이버 resume 훅 호출 */
    } else {
        phydev->state = PHY_UP;
    }

    phy_queue_state_machine(phydev, 0);  /* 즉시 state_machine 트리거 */
    mutex_unlock(&phydev->lock);
}
EXPORT_SYMBOL(phy_start);

void phy_stop(struct phy_device *phydev)
{
    mutex_lock(&phydev->lock);

    if (!phy_is_started(phydev) && phydev->state != PHY_DOWN) {
        WARN_ONCE(true, "phy_stop() called in unexpected state\n");
        mutex_unlock(&phydev->lock);
        return;
    }

    phydev->state = PHY_HALTED;
    phy_process_queued_link_change(phydev);  /* 펜딩 링크 이벤트 처리 */
    mutex_unlock(&phydev->lock);

    phy_stop_machine(phydev);      /* 폴링 워크큐 취소 */
    phy_disable_interrupts(phydev);
    phy_link_down(phydev);         /* MAC adjust_link(link=0) 호출 */
}
EXPORT_SYMBOL(phy_stop);

상태 전이 조건 요약 테이블

리눅스 커널 객체 모델

리눅스에서 PHY 관련 코드를 읽을 때는 mii_bus, mdio_device, phy_device, phy_driver, phylink, net_device가 어떤 관계인지 먼저 잡아야 합니다. mii_bus는 실제 MDIO 컨트롤러이고, phy_device는 그 버스 위에 매달린 PHY 인스턴스, phy_driver는 특정 PHY ID에 매칭되는 동작 구현, phylink는 MAC과 PHY 사이 정책 오케스트레이터입니다.

/* 개념 예시: PHY 관련 커널 객체의 대표 필드 */
struct mii_bus {
    char id[MII_BUS_ID_SIZE];
    int (*read)(...);
    int (*write)(...);
    int (*reset)(...);
    struct device *parent;
};

struct phy_device {
    struct mdio_device mdio;
    phy_interface_t interface;
    int link;
    int speed;
    int duplex;
    int pause;
    int asym_pause;
    int irq;
    linkmode_t supported;
    linkmode_t advertising;
    linkmode_t lp_advertising;
};

struct phy_driver {
    u32 phy_id;
    u32 phy_id_mask;
    const char *name;
    int (*config_init)(...);
    int (*config_aneg)(...);
    int (*read_status)(...);
    irqreturn_t (*handle_interrupt)(...);
};

PHY 드라이버 콜백을 어디까지 구현해야 하나

많은 PHY는 genphy_config_aneg(), genphy_read_status() 같은 공통 헬퍼만으로도 동작합니다. 하지만 RGMII 지연, downshift, EEE, LED, strap override, 온도 센서, FEC 정책처럼 벤더 확장 기능이 필요한 경우에는 전용 콜백 구현이 필요합니다.

/* 개념 예시: 벤더 페이지 전환 레지스터 접근 패턴 */
static int myphy_set_rgmii_delay(struct phy_device *phydev)
{
    int oldpage, ret;

    oldpage = phy_select_page(phydev, 0xd08);
    if (oldpage < 0)
        return oldpage;

    ret = phy_modify(phydev, 0x11, 0x0300, 0x0200);
    return phy_restore_page(phydev, oldpage, ret);
}

genphy 헬퍼 함수 상세 분석

대부분의 PHY 드라이버는 벤더 전용 레지스터 접근이 필요한 일부 콜백만 직접 구현하고, 나머지는 커널이 제공하는 genphy_* 계열 함수에 위임합니다. 이 함수들은 IEEE 802.3 표준 레지스터(BMCR, BMSR, ANAR, ANLPAR, GBCR, GBSR)만을 사용해 동작하므로, 표준 Clause 22를 준수하는 PHY라면 드라이버 없이도 링크를 올릴 수 있습니다. 이 절에서는 각 함수가 어떤 레지스터를 어떤 순서로 다루는지 실제 커널 로직에 근거해 상세히 살펴봅니다.

genphy_config_aneg() — Auto-Negotiation 광고 설정

genphy_config_aneg()는 phy_device의 advertising 링크모드(Linkmode) 비트맵을 읽어 ANAR(Auto-Negotiation Advertisement Register, 레지스터 4번)와 GBCR(1000BASE-T Control Register, 레지스터 9번)에 기록한 뒤, BMCR(Basic Mode Control Register, 레지스터 0번)에서 재시작 비트를 세트합니다. PHY가 AN을 지원하지 않는 경우에는 강제 속도/듀플렉스(duplex) 경로로 폴백합니다.

/* drivers/net/phy/phy_device.c 참조 — 개념 재현 */
int genphy_config_aneg(struct phy_device *phydev)
{
    int err, changed = 0;

    /* (1) 1000BASE-T 마스터/슬레이브(Master/Slave) 광고 — 레지스터 9 */
    if (genphy_config_eee_advert(phydev) &&
        linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
                          phydev->advertising)) {
        err = genphy_config_advert(phydev);
        if (err < 0)
            return err;
        changed |= err;
    }

    if (linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
                          phydev->advertising)) {
        /* (2) BMCR 에 AN_ENABLE + RESTART_AN 세트 */
        if (changed) {
            err = phy_modify(phydev, MII_BMCR,
                              BMCR_ANRESTART | BMCR_ANENABLE,
                              BMCR_ANENABLE | BMCR_ANRESTART);
            if (err < 0)
                return err;
        }
    } else {
        /* (3) AN 비활성: 강제 속도/듀플렉스 적용 */
        err = genphy_setup_forced(phydev);
        if (err < 0)
            return err;
    }
    return 0;
}

/* genphy_config_advert: ANAR(reg4)와 GBCR(reg9)를 advertising 비트맵으로 갱신 */
static int genphy_config_advert(struct phy_device *phydev)
{
    int err, adv, changed = 0;

    /* ANAR: 10/100 half/full + pause 비트 */
    adv = ethtool_adv_to_mii_adv_t(
            linkmode_adv_to_lcl_adv_t(phydev->advertising));
    err = phy_modify_changed(phydev, MII_ADVERTISE,
                              ADVERTISE_ALL | ADVERTISE_100BASE4 |
                              ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM,
                              adv);
    if (err < 0)
        return err;
    changed |= err;

    /* GBCR(reg9): 1000BASE-T half/full 광고 */
    if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
                          phydev->advertising) ||
        linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
                          phydev->advertising)) {
        adv = ethtool_adv_to_mii_ctrl1000_t(
                linkmode_adv_to_lcl_adv_t(phydev->advertising));
        err = phy_modify_changed(phydev, MII_CTRL1000,
                                  CTL1000_ENABLE_MASTER |
                                  CTL1000_AS_MASTER |
                                  ADVERTISE_1000FULL |
                                  ADVERTISE_1000HALF, adv);
        if (err < 0)
            return err;
        changed |= err;
    }
    return changed;
}

주목할 점은 phy_modify_changed()가 기존 레지스터 값과 비교해 실제로 비트가 달라졌을 때만 쓰기를 수행하고 1을 반환한다는 것입니다. 광고 내용이 변하지 않았다면 불필요한 AN 재시작을 생략해 링크 순간 끊김을 방지합니다.

genphy_read_status() — 링크 상태 판독

genphy_read_status()는 링크가 올라온 후 커널 폴러(Poller) 또는 인터럽트 핸들러에서 주기적으로 호출되어, PHY 레지스터를 읽고 phydev의 link, speed, duplex, pause 필드를 갱신합니다. MAC 드라이버는 이 필드를 보고 MAC 속도를 재설정합니다.

int genphy_read_status(struct phy_device *phydev)
{
    int err;

    /* (1) BMSR 읽기 — sticky 비트이므로 두 번 읽어 래치 해제 */
    err = genphy_update_link(phydev);
    if (err)
        return err;

    /* 링크가 없으면 속도/듀플렉스 정보는 의미 없음 */
    phydev->speed = SPEED_UNKNOWN;
    phydev->duplex = DUPLEX_UNKNOWN;
    phydev->pause = 0;
    phydev->asym_pause = 0;

    if (phydev->autoneg == AUTONEG_ENABLE && phydev->link) {
        /* (2) ANLPAR(reg5): 파트너 광고 읽기 */
        err = genphy_read_lpa(phydev);
        if (err < 0)
            return err;

        /* (3) GBSR(reg10): 1000BASE-T 마스터/슬레이브 결과 */
        if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
                              phydev->supported) ||
            linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
                              phydev->supported)) {
            err = genphy_read_1000t_status(phydev);
            if (err < 0)
                return err;
        }

        /* (4) 협상 결과로 speed/duplex/pause 결정 */
        phy_resolve_aneg_linkmode(phydev);
    } else if (phydev->autoneg == AUTONEG_DISABLE) {
        /* (5) 강제 모드: BMCR 비트로 speed/duplex 직접 판독 */
        err = genphy_read_status_fixed(phydev);
        if (err < 0)
            return err;
    }
    return 0;
}

genphy_update_link()는 BMSR(Basic Mode Status Register, 레지스터 1번)의 비트 2(Link Status)를 확인합니다. 이 비트는 스티키(sticky) 비트여서 링크 다운 이벤트를 기록하고 나면 읽어야 클리어되므로, 래치 해제를 위해 BMSR을 두 번 연속으로 읽습니다. phy_resolve_aneg_linkmode()는 자신의 advertising과 파트너의 lp_advertising 비트맵을 AND 연산해 최대 공통 모드를 선택합니다.

genphy_suspend() / genphy_resume() — 전원 관리

genphy_suspend()는 BMCR의 비트 11(Power Down)을 세트해 PHY 아날로그 회로를 저전력 상태로 전환합니다. genphy_resume()는 해당 비트를 클리어해 정상 동작 상태로 복귀시킵니다. 드라이버가 이 콜백을 오버라이드하는 일반적인 이유는 WoL(Wake-on-LAN) 활성화 여부를 확인하거나, Power Down 시에도 유지해야 하는 벤더 레지스터 상태가 있을 때입니다.

int genphy_suspend(struct phy_device *phydev)
{
    return phy_set_bits(phydev, MII_BMCR, BMCR_PDOWN);
}
EXPORT_SYMBOL(genphy_suspend);

int genphy_resume(struct phy_device *phydev)
{
    return phy_clear_bits(phydev, MII_BMCR, BMCR_PDOWN);
}
EXPORT_SYMBOL(genphy_resume);

/* 오버라이드 예시: WoL이 활성화된 경우 Power Down 생략 */
static int myphy_suspend(struct phy_device *phydev)
{
    if (phy_interrupt_is_valid(phydev) && phydev->wol_enabled)
        return 0;  /* WoL 활성: Power Down 금지 */
    return genphy_suspend(phydev);
}

genphy_soft_reset() — PHY 소프트 리셋

genphy_soft_reset()은 BMCR의 비트 15(Reset)를 세트하고, PHY 내부가 리셋을 완료해 해당 비트를 자동으로 클리어할 때까지 폴링합니다. 최대 대기 시간은 500ms이며, 이 기간을 초과하면 -ETIMEDOUT을 반환합니다. 리셋 직후에는 PHY가 EEPROM 스트랩(strap) 또는 내부 기본값으로 레지스터를 복원하므로, 이후에 벤더 초기화 코드를 반드시 재실행해야 합니다.

int genphy_soft_reset(struct phy_device *phydev)
{
    u16 res = BMCR_RESET;
    int err;

    if (phydev->autoneg == AUTONEG_ENABLE)
        res |= BMCR_ANRESTART;

    /* BMCR bit15 = 1 → PHY 리셋 개시 */
    err = phy_modify(phydev, MII_BMCR, BMCR_ISOLATE, res);
    if (err < 0)
        return err;

    /* PHY가 리셋을 완료하면 bit15를 스스로 클리어함 */
    err = phy_poll_reset(phydev);
    if (err)
        return err;

    /* 리셋 후 일부 PHY는 추가 안정화 시간이 필요 */
    msleep(1);
    return 0;
}
EXPORT_SYMBOL(genphy_soft_reset);

phy_poll_reset() 내부는 최대 100ms 간격으로 BMCR bit15를 읽으면서 클리어를 기다립니다. 재시도 횟수 초과 시 -ETIMEDOUT을 반환합니다. 하드웨어 리셋 핀(reset-gpios)이 붙어 있는 경우에는 mdio_device_reset()이 GPIO를 토글하고, 그 다음 단계로 genphy_soft_reset()이 호출됩니다.

genphy_read_abilities() / genphy_c45_read_abilities() — PHY 능력 탐지

genphy_read_abilities()는 PHY 탐지 직후 phy_driver.get_features 콜백 위치에서 호출되어 phydev->supported 링크모드 비트맵을 채웁니다. BMSR의 능력 비트(10BASE-T, 100BASE-TX, 1000BASE-T, AN 지원)를 읽어 표준 비트맵으로 변환하고, GBSR(레지스터 10번)도 추가로 확인합니다.

int genphy_read_abilities(struct phy_device *phydev)
{
    int val;

    linkmode_set_bit_array(phy_basic_ports_array,
                            ARRAY_SIZE(phy_basic_ports_array),
                            phydev->supported);

    /* BMSR(reg1): 기본 속도/듀플렉스 능력 비트 */
    val = phy_read(phydev, MII_BMSR);
    if (val < 0)
        return val;
    linkmode_mod_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
                     phydev->supported, val & BMSR_ANEGCAPABLE);
    linkmode_mod_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT,
                     phydev->supported, val & BMSR_100FULL);
    linkmode_mod_bit(ETHTOOL_LINK_MODE_100baseT_Half_BIT,
                     phydev->supported, val & BMSR_100HALF);
    linkmode_mod_bit(ETHTOOL_LINK_MODE_10baseT_Full_BIT,
                     phydev->supported, val & BMSR_10FULL);
    linkmode_mod_bit(ETHTOOL_LINK_MODE_10baseT_Half_BIT,
                     phydev->supported, val & BMSR_10HALF);

    /* ESTATUS(reg15): 기가비트(Gigabit) 능력 확인 */
    if (val & BMSR_ESTATEN) {
        val = phy_read(phydev, MII_ESTATUS);
        if (val < 0)
            return val;
        linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
                         phydev->supported, val & ESTATUS_1000_TFULL);
        linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
                         phydev->supported, val & ESTATUS_1000_THALF);
        linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseX_Full_BIT,
                         phydev->supported, val & ESTATUS_1000_XFULL);
    }
    return 0;
}
EXPORT_SYMBOL(genphy_read_abilities);

Clause 45 PHY를 위한 genphy_c45_read_abilities()는 PMA/PMD MMD(레지스터 1.4, 1.7, 1.8 등)를 읽어 10GBASE-T, 25GBASE-KR, 40GBASE-CR4 같은 상위 속도 비트까지 채웁니다. PHY 드라이버가 get_features를 오버라이드하지 않으면 phylib이 Clause 22/45 여부를 자동으로 판단해 둘 중 하나를 기본으로 호출합니다.

/* Clause 45 PHY 능력 탐지 — MMD 1(PMA/PMD), MMD 3(PCS) 참조 */
int genphy_c45_read_abilities(struct phy_device *phydev)
{
    int val;

    /* PMA/PMD Ctrl2(1.7): 10G 능력 비트 */
    val = phy_read_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_PMA_CTRL2);
    if (val < 0)
        return val;

    linkmode_mod_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
                     phydev->supported,
                     (val & MDIO_PMA_CTRL2_10GBTR));

    /* PCS Status2(3.8): PCS 능력 확인 */
    val = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_PCS_STAT2);
    if (val < 0)
        return val;
    linkmode_mod_bit(ETHTOOL_LINK_MODE_10000baseR_FEC_BIT,
                     phydev->supported,
                     (val & MDIO_PCS_STAT2_10GBR));

    return 0;
}

genphy 함수 참조 테이블

ethtool 명령에서 MDIO 레지스터까지의 호출 체인

Auto-Negotiation

Auto-Negotiation은 "링크 업" 자체보다 "어떤 모드로 링크를 올릴지"를 결정하는 규칙입니다. 구리 PHY에서는 FLP(Fast Link Pulse) 기반 Clause 28이 기본이고, SerDes 기반 인터페이스에서는 Clause 37이나 Clause 73의 in-band status가 많이 쓰입니다. 현대 장비는 속도뿐 아니라 pause, FEC, EEE, master/slave 역할까지 협상에 포함할 수 있습니다.

Clause 28: FLP 기반 Auto-Negotiation 상세

Clause 28은 10/100/1000BASE-T 구리 이더넷에서 사용하는 Auto-Negotiation 규격입니다. 양단의 PHY가 FLP(Fast Link Pulse) 버스트를 교환하여 지원하는 속도, duplex, pause 능력을 알리고, 공통적으로 가능한 최고 모드를 선택합니다. FLP 버스트는 33개의 펄스로 구성되며, 그중 17개의 클럭 펄스 사이에 끼워진 16개의 데이터 펄스가 하나의 Link Code Word(16비트)를 운반합니다.

NLP에서 FLP로: Auto-Negotiation의 탄생 배경

Auto-Negotiation이 등장하기 전, 10BASE-T PHY는 링크 유지를 위해 NLP(Normal Link Pulse)를 사용했습니다. NLP는 16ms 간격으로 전송되는 단일 전압 펄스(100ns 폭)로, "나는 살아 있다"는 단순 신호에 불과하며 어떤 정보도 운반하지 않습니다. 10BASE-T 시대에는 속도가 하나뿐이었으므로 이것만으로도 충분했습니다.

100BASE-TX가 등장하면서 문제가 생겼습니다. 10M 포트와 100M 포트가 같은 RJ45 커넥터로 연결될 수 있게 되자, 케이블을 꽂는 순간 양단이 어떤 속도로 통신할지 자동으로 합의하는 메커니즘이 필요해졌습니다. IEEE 802.3u(1995)는 기존 NLP 타이밍 슬롯 사이에 데이터 펄스를 끼워 넣어 16비트 정보를 운반하는 FLP(Fast Link Pulse) 버스트를 정의했고, 이것이 Clause 28 Auto-Negotiation의 물리적 기반입니다.

FLP 물리 신호의 상세 구조

FLP 버스트 하나는 정확히 2ms 안에 33개의 펄스를 담고 있습니다. 홀수 번째 펄스(1, 3, 5, …, 33번)가 클럭 펄스이고, 짝수 번째 위치(2, 4, 6, …, 32번)가 데이터 펄스 슬롯입니다. 데이터 슬롯에 펄스가 있으면 비트 1, 없으면 비트 0으로 해석합니다.

이 타이밍은 선로 위의 감쇠와 반사를 고려하여 정의되었습니다. 클럭-데이터 간격이 62.5µs인 이유는, 이보다 좁으면 매체 위의 반사 신호와 실제 데이터 펄스를 구분하기 어렵고, 이보다 넓으면 버스트 전체 시간이 길어져 협상 지연이 증가하기 때문입니다.

Clause 28 Auto-Negotiation 상태 머신

IEEE 802.3 Clause 28은 Auto-Negotiation의 동작을 7개 주요 상태로 정의합니다. 이 상태 머신은 PHY 하드웨어 내부에서 실행되며, 커널이 BMCR의 AN Enable/Restart 비트를 세트하면 PHY가 자율적으로 상태를 전이합니다. 소프트웨어는 BMSR의 AN Complete 비트를 폴링하거나 인터럽트를 기다려 완료를 감지합니다.

Base Page 비트 필드 완전 해부

Clause 28 Base Page(ANAR, 레지스터 0x04)는 16비트이며, FLP 버스트 하나가 이 16비트를 통째로 운반합니다. 상대편이 보내는 Base Page는 ANLPAR(레지스터 0x05)에서 읽을 수 있습니다. 각 비트 필드의 역할을 정확히 이해해야 협상 결과를 해석할 수 있습니다.

# Base Page (ANAR, reg 4) 직접 읽기
phytool read eth0/0/4
# 예: 0x05e1 = 0000 0101 1110 0001
#   Selector=00001(802.3), 10T=1, 10T-FD=1, 100TX=1, 100TX-FD=1, Pause=0

# 상대편 Base Page (ANLPAR, reg 5) 읽기
phytool read eth0/0/5
# 양단의 교집합에서 최고 우선순위가 결과 모드

# ethtool로도 확인 가능
ethtool eth0 | grep -A20 "Advertised link modes"

우선순위 결정 알고리즘 (Priority Resolution)

양단이 Base Page를 교환한 후, 공통으로 지원하는 모드의 교집합에서 IEEE 802.3이 정의한 고정 우선순위 표에 따라 최고 모드가 선택됩니다. 이 우선순위는 PHY 하드웨어에 내장되어 있으며 소프트웨어로 변경할 수 없습니다.

우선순위 결정은 커널 코드에서는 genphy_read_status()가 협상 완료 후 결과를 읽어오는 방식으로 반영됩니다. PHY 하드웨어가 이미 최고 공통 모드를 선택하여 동작 중이므로, 소프트웨어는 그 결과를 BMSR, ANLPAR, GBSR 레지스터에서 읽어 phydev->speed, phydev->duplex에 기록할 뿐입니다.

Next Page 프로토콜

Base Page 16비트만으로는 모든 능력을 표현할 수 없습니다. EEE(Energy Efficient Ethernet), 추가적인 기술 광고, OUI(Organizationally Unique Identifier) 기반 벤더 확장 정보를 전달하려면 Next Page 메커니즘이 필요합니다. Base Page의 비트 15(NP)를 1로 세트하면, 상태 머신은 COMPLETE_ACK 이후 NEXT_PAGE_WAIT 상태로 진입하여 추가 페이지를 교환합니다.

Next Page 교환은 양단의 NP 비트가 모두 0이 될 때까지 반복됩니다. 한 쪽에 더 보낼 페이지가 없어도 상대가 NP=1을 보내면 Null Page(모두 0)로 응답해야 합니다. 이 프로토콜은 양방향이므로, 순서가 어긋나면 AN이 재시작됩니다.

# Next Page 교환 레지스터 확인 (Clause 22)
# ANNPTR (reg 7) — 로컬 Next Page 송신
phytool read eth0/0/7

# ANNPRR (reg 8) — 상대편 Next Page 수신
phytool read eth0/0/8

# EEE 광고 레지스터 (Clause 45, MMD 7 reg 60)
phytool read eth0/7/60
# bit 1: 100BASE-TX EEE, bit 2: 1000BASE-T EEE

# 상대편 EEE 능력 (MMD 7 reg 61)
phytool read eth0/7/61

Pause 프레임 해석 알고리즘 (Annex 28B)

Auto-Negotiation에서 pause 능력은 Base Page의 비트 10(PAUSE)과 비트 11(ASM_DIR)으로 교환됩니다. 양단의 이 두 비트 조합으로 실제 흐름 제어(Flow Control) 방향이 결정되는데, 이 해석 규칙은 IEEE 802.3 Annex 28B에 정의되어 있으며 직관적이지 않으므로 주의가 필요합니다.

핵심 포인트는 다음과 같습니다:

• PAUSE=1, ASM_DIR=0은 "대칭 pause만 지원"을 의미합니다 — 양방향 모두 가능하거나 모두 불가능합니다.
• PAUSE=0, ASM_DIR=1은 "나는 pause를 보내지 않지만, 상대가 보내면 처리할 수 있다"는 뜻입니다.
• PAUSE=1, ASM_DIR=1은 "대칭과 비대칭 모두 지원"으로, 가장 유연한 설정입니다.

/* 커널 내부 pause 해석 — drivers/net/phy/phy_device.c 참조 */
void phy_resolve_aneg_pause(struct phy_device *phydev)
{
    /* ANAR(reg 4)의 pause 비트와 ANLPAR(reg 5)의 pause 비트를 비교 */
    if (phydev->duplex == DUPLEX_FULL) {
        bool lcl_pause  = linkmode_test_bit(ETHTOOL_LINK_MODE_Pause_BIT,
                                              phydev->advertising);
        bool lcl_asym   = linkmode_test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
                                              phydev->advertising);
        bool rmt_pause  = linkmode_test_bit(ETHTOOL_LINK_MODE_Pause_BIT,
                                              phydev->lp_advertising);
        bool rmt_asym   = linkmode_test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
                                              phydev->lp_advertising);

        /* IEEE 802.3 Annex 28B 테이블 구현 */
        phydev->pause = lcl_pause && rmt_pause;
        phydev->asym_pause = lcl_pause ^ rmt_pause;
    }
}

1000BASE-T Master/Slave 결정 메커니즘 상세 (Clause 40)

1000BASE-T는 4쌍 모두를 동시에 사용하는 양방향 통신이므로, 한쪽이 master(타이밍 기준 송신), 다른 쪽이 slave(타이밍 추종 수신) 역할을 맡아야 합니다. 이 역할은 신호의 부호화(PAM-5)에서 클럭 복구 기준점을 결정하므로, 양쪽이 같은 역할을 선택하면 통신이 불가능합니다.

Master/slave 결정은 GBCR(Gigabit Control Register, 레지스터 0x09)의 비트 12:11로 설정하며, 4가지 모드가 있습니다:

자동 모드에서의 결정 과정은 다음과 같습니다:

1. 양단이 GBCR의 bit 11(MS Value)을 교환합니다. 하나가 1(master 선호)이고 다른 하나가 0(slave 선호)이면 즉시 역할이 결정됩니다.
2. 양쪽 모두 같은 값(둘 다 master 선호 또는 둘 다 slave 선호)이면, 각 PHY가 생성한 10비트 난수(seed)를 비교하여 큰 쪽이 master가 됩니다.
3. 난수까지 같으면(확률 1/1024) AN이 재시작됩니다.

# master/slave 상태 확인
ethtool eth0 | grep -i "master-slave"
# master-slave cfg:  preferred-master
# master-slave status:  master

# 강제 slave로 변경 (디버깅)
ethtool -s eth0 master-slave forced-slave

# GBCR(reg 0x09) 직접 확인
phytool read eth0/0/9
# bit 12:11 확인, bit 9: 1000FD 광고, bit 8: 1000HD 광고

# GBSR(reg 0x0A) — 협상 결과
phytool read eth0/0/10
# bit 14: master/slave config fault (양쪽 강제 동일 시 1)
# bit 13: local=master(1)/slave(0)

Auto-Negotiation 타이밍 파라미터

AN 완료까지 걸리는 시간은 고정값이 아니라, 매체 조건, PHY 구현, 교환할 페이지 수에 따라 달라집니다. 아래는 IEEE 802.3이 정의한 타이밍과 실측치입니다.

커널의 Auto-Negotiation 구현 흐름

리눅스 커널에서 AN은 크게 세 단계로 나뉩니다: 광고 설정, AN 시작, 결과 판독. 이 흐름은 phylib 상태 머신과 ethtool 인터페이스를 통해 제어됩니다.

/* AN 전체 흐름 요약 — 관련 커널 함수 */

/* 1단계: 광고 설정 + AN 시작 */
phy_ethtool_set_link_ksettings()
  → phydev->autoneg = AUTONEG_ENABLE;
  → linkmode_copy(phydev->advertising, ...);
  → phy_start_aneg(phydev);
    → phydev->drv->config_aneg(phydev);  /* 대부분 genphy_config_aneg */
      → genphy_config_advert(phydev);   /* ANAR, GBCR 기록 */
      → phy_modify(phydev, MII_BMCR, ..., BMCR_ANRESTART);

/* 2단계: 상태 머신 폴링 (1초 주기) */
phy_state_machine()
  → phydev->drv->read_status(phydev);  /* 대부분 genphy_read_status */
    → genphy_update_link(phydev);       /* BMSR.LINK_STATUS 확인 */
    → genphy_read_lpa(phydev);          /* ANLPAR, GBSR 판독 */
    → genphy_read_master_slave(phydev); /* GBSR bit 14:13 판독 */
    → phydev->speed, phydev->duplex 갱신

/* 3단계: MAC 통보 */
phy_adjust_link(phydev->attached_dev);
  → MAC 드라이버의 adjust_link() 콜백
  → 속도 변경, duplex 변경, pause 설정 반영

광고 비트 제어와 속도 제한 전략

AN을 유지하면서 특정 속도만 광고하는 것은, AN을 완전히 끄는 것보다 안전한 속도 제한 방법입니다. AN을 끄면 parallel detect 위험이 생기지만, 광고 비트만 조절하면 AN 프로토콜은 정상 동작하면서 원하는 속도로 합의할 수 있습니다.

# 현재 광고 확인
ethtool eth0 | grep -A5 "Advertised link modes"

# 100M Full만 광고 (AN은 유지)
ethtool -s eth0 autoneg on advertise 0x008

# 1000M Full만 광고
ethtool -s eth0 autoneg on advertise 0x020

# 100M + 1000M Full 광고 (10M 제외)
ethtool -s eth0 autoneg on advertise 0x028

# 모든 지원 속도 광고 복원
ethtool -s eth0 autoneg on advertise 0x03f

# advertise 비트맵 의미 (ethtool 비트)
#   0x001 = 10baseT Half
#   0x002 = 10baseT Full
#   0x004 = 100baseT Half
#   0x008 = 100baseT Full
#   0x010 = 1000baseT Half
#   0x020 = 1000baseT Full
#   0x1000 = 2500baseT Full (NBASE-T)
#   0x2000 = 5000baseT Full (NBASE-T)

Auto-Negotiation 실패 패턴과 체계적 디버깅

AN 관련 문제는 크게 네 가지 범주로 나뉩니다. 각 범주별 증상과 원인, 점검 순서를 정리합니다.

범주 1: AN 자체가 완료되지 않음

범주 2: AN 완료되나 기대와 다른 속도

범주 3: AN 완료되나 duplex mismatch

범주 4: AN 완료되나 pause 관련 문제

# AN 문제 체계적 디버깅 순서

# 1. 로컬 PHY 상태 확인
ethtool eth0
# Speed, Duplex, Autoneg, Link detected, master-slave status 확인

# 2. 광고/상대편 능력 비교
ethtool eth0 | grep -E "Supported|Advertised|Link partner"

# 3. 핵심 레지스터 직접 판독
phytool read eth0/0/0   # BMCR: AN enable? speed? duplex?
phytool read eth0/0/1   # BMSR: AN complete? link status?
phytool read eth0/0/4   # ANAR: 로컬 광고
phytool read eth0/0/5   # ANLPAR: 상대 광고
phytool read eth0/0/6   # ANER: AN 확장 상태
phytool read eth0/0/9   # GBCR: 1G 광고 + master/slave
phytool read eth0/0/10  # GBSR: 1G 결과 + config fault

# 4. 카운터로 증상 수치화
ethtool -S eth0 | grep -E "crc|collision|error|pause|drop"

# 5. 링크 flap 감시
ip -ts monitor link dev eth0

# 6. dmesg에서 PHY 이벤트 확인
dmesg | grep -i "link\|phy\|eth0"

NBASE-T (2.5G/5G/10GBASE-T) Auto-Negotiation 고려사항

NBASE-T(IEEE 802.3bz)는 기존 CAT-5e/6 케이블에서 1G 이상의 속도를 제공하기 위해 개발되었습니다. AN 관점에서 NBASE-T는 기존 Clause 28/40 프레임워크를 확장하여 2.5G와 5G 능력을 광고합니다.

NBASE-T AN의 핵심 차이점:

• 다단계 폴백(Downshift): 10G → 5G → 2.5G → 1G → 100M 순서로 자동 강등됩니다. downshift 횟수와 대상 속도는 PHY 벤더별 레지스터로 설정합니다.
• Clause 45 접근 필수: 2.5G/5G 능력 광고 레지스터는 Clause 22로는 접근할 수 없고, Clause 45 MMD(MDIO Manageable Device) 7번을 통해야 합니다. 커널에서는 genphy_c45_an_config_aneg()를 사용합니다.
• 훈련 시간 증가: 고속일수록 echo cancellation과 crosstalk 제거가 복잡해져 링크 훈련 시간이 길어집니다. 10GBASE-T는 최대 5~10초까지 걸릴 수 있습니다.

# 2.5G/5G 광고 레지스터 확인 (Clause 45, MMD 7 reg 32)
phytool read eth0/7/32
# bit 7: 2.5GBASE-T 광고, bit 8: 5GBASE-T 광고

# 상대편 NBASE-T 능력 (MMD 7 reg 33)
phytool read eth0/7/33

# ethtool로 확인
ethtool eth0 | grep "2500\|5000\|10000"

# downshift 설정 확인 (PHY 벤더별)
# Realtek: phytool read eth0/0/20 (page 0xa43)
# Marvell: phytool read eth0/7/0x8001

EEE와 Auto-Negotiation의 상호작용

EEE(Energy Efficient Ethernet, IEEE 802.3az)는 AN의 Next Page 메커니즘을 통해 협상되지만, 실제 EEE 능력 레지스터는 Clause 45 MMD 7에 별도로 존재합니다. AN 과정에서 EEE가 어떻게 처리되는지 이해하면 EEE 관련 링크 불안정 문제를 풀 수 있습니다.

1. AN 시작 전: 커널은 genphy_config_eee_advert()를 호출하여 MMD 7 레지스터 60(EEE Advertisement)에 지원 모드를 기록합니다.
2. AN 진행 중: PHY 하드웨어가 Base Page 교환 후 Next Page를 통해 EEE 능력을 교환합니다. 이 과정은 PHY 내부에서 자동으로 처리됩니다.
3. AN 완료 후: MMD 7 레지스터 61(EEE LP Ability)에서 상대편 EEE 능력을 확인할 수 있습니다. 양단 모두 지원하는 속도에서만 EEE가 활성화됩니다.
4. LPI(Low Power Idle) 진입: 링크 업 이후 트래픽이 없으면 PHY가 LPI 모드로 진입하여 전력을 절감합니다. 복귀 시간(wake time)은 100BASE-TX에서 30µs, 1000BASE-T에서 16.5µs입니다.

Auto-Negotiation 관련 레지스터 종합 참조표

AN 디버깅에 필요한 모든 레지스터를 한 곳에 모았습니다. Clause 22(기본)와 Clause 45(확장)로 구분합니다.

# 현재 링크 협상 결과
ethtool eth0

# 자동 협상 끄고 강제 설정
ethtool -s eth0 speed 1000 duplex full autoneg off

# EEE 상태 확인
ethtool --show-eee eth0

# 링크 업/다운 이벤트 실시간 감시
ip monitor link

협상 디버깅에서 중요한 것은 "로컬이 무엇을 광고했고 상대편이 무엇을 응답했는가"입니다. 단순히 속도 결과만 보면 중간 원인을 놓칩니다. 예를 들어 2.5G 포트가 1G로만 붙는다면 케이블 품질 문제일 수도 있지만, 상대편의 advertisement mask가 1G까지만 켜져 있는 정책 문제일 수도 있습니다.

Parallel Detect와 강제 모드의 위험

Auto-Negotiation이 실패하거나 상대편이 AN을 지원하지 않을 때, PHY는 Parallel Detect로 폴백(Fallback)합니다. 이 모드는 상대편이 보내는 신호의 패턴만으로 속도를 감지하되, duplex 정보는 교환하지 않습니다. 결과적으로 한쪽은 full duplex, 다른 쪽은 half duplex로 동작하는 duplex mismatch가 발생할 수 있습니다.

# 양단 광고 능력 비교 — 로컬
ethtool eth0 | grep -E "Supported|Advertised|Link partner"

# 특정 속도만 광고하도록 제한 (AN 유지)
ethtool -s eth0 autoneg on advertise 0x020   # 1000baseT Full만

# master/slave 역할 확인 (1000BASE-T 이상)
ethtool eth0 | grep -i "master"

Auto-Negotiation Off: 강제 모드 상세 동작과 조건

Auto-Negotiation을 비활성화하면 PHY는 BMCR(Basic Mode Control Register)의 비트 12(AN Enable)를 0으로 클리어하고, 비트 13(Speed Selection MSB), 비트 6(Speed Selection LSB), 비트 8(Duplex Mode)의 조합으로 속도와 듀플렉스를 직접 지정합니다. FLP(Fast Link Pulse) 교환이 중단되므로 상대편과 어떤 능력 정보도 주고받지 않습니다.

BMCR 강제 모드 비트 구성

AN을 끄면 BMCR의 속도/듀플렉스 비트가 직접 PHY 동작을 결정합니다. AN Enable(비트 12)이 1일 때는 이 비트들이 무시되지만, 0이 되면 즉시 유효해집니다.

커널 구현: genphy_setup_forced()

사용자가 ethtool -s eth0 autoneg off speed 1000 duplex full을 실행하면, 커널은 phy_ethtool_sset() → phy_start_aneg() → config_aneg() 경로를 타고, phydev->autoneg == AUTONEG_DISABLE이면 genphy_setup_forced()를 호출합니다. 이 함수는 BMCR에서 AN Enable 비트를 클리어하고 speed/duplex 비트를 직접 세트합니다.

/* drivers/net/phy/phy_device.c — 강제 모드 레지스터 설정 */
int genphy_setup_forced(struct phy_device *phydev)
{
    u16 ctl = 0;

    phydev->pause = 0;
    phydev->asym_pause = 0;

    /* speed 비트 설정 */
    if (phydev->speed == SPEED_1000)
        ctl |= BMCR_SPEED1000;
    else if (phydev->speed == SPEED_100)
        ctl |= BMCR_SPEED100;
    /* SPEED_10이면 두 비트 모두 0 */

    /* duplex 비트 설정 */
    if (phydev->duplex == DUPLEX_FULL)
        ctl |= BMCR_FULLDPLX;

    /* BMCR 쓰기: AN Enable 클리어, speed/duplex 적용 */
    return phy_modify(phydev, MII_BMCR,
                        BMCR_ANENABLE | BMCR_SPEED1000 |
                        BMCR_SPEED100 | BMCR_FULLDPLX, ctl);
}

phy_sanitize_settings()는 genphy_setup_forced() 호출 전에 실행되어, 요청된 speed/duplex 조합이 PHY의 supported 비트맵에 존재하는지 검증합니다. 지원하지 않는 조합이면 가능한 최고 속도로 자동 하향 조정합니다.

/* drivers/net/phy/phy.c — 강제 모드 설정값 검증 */
void phy_sanitize_settings(struct phy_device *phydev)
{
    const struct phy_setting *setting;

    /* speed/duplex 조합이 supported에 있는지 확인 */
    setting = phy_find_valid(phydev->speed, phydev->duplex,
                              phydev->supported);
    if (setting) {
        phydev->speed = setting->speed;
        phydev->duplex = setting->duplex;
    } else {
        /* 유효한 조합이 없으면 최저 속도로 폴백 */
        phydev->speed = SPEED_UNKNOWN;
        phydev->duplex = DUPLEX_UNKNOWN;
    }
}

속도별 강제 모드 제약 조건

모든 이더넷(Ethernet) 속도가 동일하게 강제 모드를 지원하는 것은 아닙니다. 물리 계층의 특성에 따라 속도별로 제약 사항이 크게 다릅니다.

# 1000BASE-T 강제 모드 — 양단 설정 예시
# 장비 A (master로 설정)
ethtool -s eth0 speed 1000 duplex full autoneg off
phytool write eth0/0/9 0x1800   # GBCR: manual M/S enable + master

# 장비 B (slave로 설정)
ethtool -s eth0 speed 1000 duplex full autoneg off
phytool write eth0/0/9 0x1000   # GBCR: manual M/S enable + slave

# master/slave 상태 확인
ethtool eth0 | grep -i "master"

강제 모드에서 상실되는 기능

AN을 끄면 FLP 교환이 중단되므로, AN의 Base Page와 Next Page를 통해 협상되던 여러 기능이 자동으로 비활성화됩니다. 이 영향은 단순한 속도/듀플렉스 고정보다 훨씬 광범위합니다.

강제 모드를 사용해야 하는 정당한 사유

대부분의 환경에서 AN on이 권장되지만, AN을 끄는 것이 올바른 선택인 구체적인 시나리오가 있습니다.

강제 모드 적용 전 체크리스트

강제 모드 설정과 검증 절차

# === 1단계: 현재 상태 기록 (원복용) ===
ethtool eth0 | tee /tmp/eth0-before.txt

# === 2단계: 강제 모드 적용 (양단 동시) ===
# 100M full duplex 강제 (가장 안전한 강제 설정)
ethtool -s eth0 speed 100 duplex full autoneg off

# === 3단계: 링크 상태 확인 ===
ethtool eth0 | grep -E "Speed|Duplex|Auto-negotiation|Link detected"
# 기대 출력:
#   Speed: 100Mb/s
#   Duplex: Full
#   Auto-negotiation: off
#   Link detected: yes

# === 4단계: duplex mismatch 징후 점검 ===
ethtool -S eth0 | grep -iE "collision|error|drop|carrier"
# late_collision이 증가하면 상대편 duplex 설정이 다른 것임

# === 5단계: pause 상태 확인 ===
ethtool -a eth0
# 강제 모드에서는 Autonegotiate: off, RX/TX: off로 표시됨
# 필요하면 수동 활성화:
ethtool -A eth0 rx on tx on

# === 원복 ===
ethtool -s eth0 autoneg on
# AN이 재시작되며 수 초 내에 최적 속도로 링크가 올라옴

커널의 강제 모드 상태 판독 경로

강제 모드에서는 AN이 꺼져 있으므로 ANLPAR(Link Partner Advertisement Register)을 읽을 수 없습니다. 대신 genphy_read_status_fixed()가 BMCR을 직접 읽어 현재 speed/duplex를 결정합니다.

/* drivers/net/phy/phy_device.c — 강제 모드 상태 판독 */
int genphy_read_status_fixed(struct phy_device *phydev)
{
    int bmcr = phy_read(phydev, MII_BMCR);

    if (bmcr < 0)
        return bmcr;

    /* BMCR speed 비트 해석 */
    if (bmcr & BMCR_SPEED1000)
        phydev->speed = SPEED_1000;
    else if (bmcr & BMCR_SPEED100)
        phydev->speed = SPEED_100;
    else
        phydev->speed = SPEED_10;

    /* BMCR duplex 비트 해석 */
    phydev->duplex = (bmcr & BMCR_FULLDPLX) ?
                      DUPLEX_FULL : DUPLEX_HALF;

    /* pause는 AN 결과가 아니므로 0으로 유지 */
    phydev->pause = 0;
    phydev->asym_pause = 0;

    return 0;
}

이 경로에서 pause와 asym_pause가 항상 0으로 설정되는 것을 주목하세요. 강제 모드에서는 AN이 수행되지 않았으므로 pause 능력 교환이 없고, 커널은 흐름 제어를 비활성으로 보고합니다. 이것이 ethtool -a에서 "Autonegotiate: off"로 표시되는 이유입니다.

# 1G full만 광고 — AN 유지, 속도 사실상 고정
ethtool -s eth0 autoneg on advertise 0x020
# 100M full만 광고
ethtool -s eth0 autoneg on advertise 0x008

비대칭 AN 설정: 한쪽 On / 한쪽 Off의 동작 메커니즘

실무에서 가장 빈번하고 진단이 어려운 문제는 한쪽은 AN on, 다른 쪽은 AN off인 비대칭 설정입니다. 이 조합에서 링크가 올라오기는 하지만 duplex mismatch가 거의 확실하게 발생하며, 겉으로는 정상처럼 보이기 때문에 문제를 인지하기까지 수주가 걸리는 경우도 있습니다. IEEE 802.3 Clause 28.2.3.1에 정의된 Parallel Detection 메커니즘이 이 상황의 핵심입니다.

Parallel Detection의 정확한 동작 원리

AN이 활성화된 PHY(이하 "A측")는 FLP(Fast Link Pulse) 버스트를 지속적으로 송신하면서 상대편의 FLP 응답을 기다립니다. 그런데 AN이 꺼진 PHY(이하 "B측")는 FLP를 송신하지 않고, 속도에 따라 다른 종류의 신호만 보냅니다.

핵심은 Parallel Detection이 속도만 감지하고 duplex 정보는 전달받지 못한다는 점입니다. IEEE 802.3은 Parallel Detection 시 duplex를 half duplex로 기본 설정하도록 규정합니다. 그런데 B측은 자신이 full duplex로 강제 설정되어 있으므로, 양단의 duplex가 불일치하게 됩니다.

속도별 비대칭 AN 결과 상세

비대칭 설정의 결과는 B측(AN off)의 강제 속도에 따라 크게 달라집니다. 아래 표는 A측이 항상 AN on(전체 속도 광고)일 때의 각 시나리오를 정리합니다.

Duplex Mismatch의 구체적 메커니즘

duplex mismatch가 왜 late collision을 유발하는지 이해하려면 half duplex와 full duplex의 근본적인 차이를 알아야 합니다.

비대칭 AN의 처리량 영향 분석

duplex mismatch 상태에서의 처리량 저하는 트래픽 패턴에 따라 크게 달라집니다.

비대칭 AN 상태의 진단 방법

# === 1단계: 양단 AN 상태 비교 ===
# A측 (의심되는 장비)
ethtool eth0 | grep -E "Speed|Duplex|Auto-negotiation|Link partner"
# 출력 예시:
#   Speed: 100Mb/s
#   Duplex: Half          ← half이면 의심
#   Auto-negotiation: on
#   Link partner advertised link modes: Not reported  ← 상대가 AN off인 증거

# === 2단계: 카운터 확인 (결정적 증거) ===
ethtool -S eth0 | grep -iE "late.?coll|coll|fcs|align|carrier"
# late_collision 카운터가 증가 중이면 duplex mismatch 확정
# 10초 간격으로 두 번 읽어 증가율 확인:
ethtool -S eth0 | grep late; sleep 10; ethtool -S eth0 | grep late

# === 3단계: 상대편 설정 확인 (접근 가능할 때) ===
# B측 (상대편 장비)
ethtool eth0 | grep -E "Speed|Duplex|Auto-negotiation"
# 출력 예시:
#   Speed: 100Mb/s
#   Duplex: Full           ← A측과 불일치!
#   Auto-negotiation: off  ← 원인

# === 4단계: 스위치 포트 확인 (상대가 스위치일 때) ===
# Cisco IOS
# show interface GigabitEthernet0/1 | include duplex|collision
# Juniper JunOS
# show interfaces ge-0/0/1 extensive | match "duplex|collision"

비대칭 AN의 해결 방법 (우선순위 순)

커널의 Parallel Detection 처리 경로

커널의 AN 상태 머신이 Parallel Detection을 어떻게 처리하는지, 코드 경로를 추적합니다. A측(AN on)에서 상대편의 FLP 응답이 없을 때의 흐름입니다.

/* genphy_read_status() — AN 완료 후 파트너 정보 판독 */
/* Parallel Detection으로 링크가 올라온 경우의 동작 */

if (phydev->autoneg == AUTONEG_ENABLE && phydev->link) {
    err = genphy_read_lpa(phydev);
    /*
     * genphy_read_lpa()는 ANLPAR(레지스터 5)을 읽음.
     * Parallel Detection 시 상대편이 FLP를 보내지 않았으므로
     * ANLPAR = 0x0000 (파트너 광고 없음).
     *
     * 이 경우 lp_advertising 비트맵이 비어 있고,
     * phy_resolve_aneg_linkmode()가 AND 연산 시
     * 공통 모드를 찾지 못함.
     *
     * PHY 하드웨어가 Parallel Detection으로 이미 결정한
     * 속도를 BMCR/BMSR에서 반영하되, duplex는 half로 설정됨.
     */

    phy_resolve_aneg_linkmode(phydev);
    /*
     * ANLPAR이 비어 있으면:
     * - speed: PHY 하드웨어가 감지한 값 (Parallel Detection 결과)
     * - duplex: HALF (파트너 duplex 정보 없음 → 보수적 기본값)
     * - pause: 0 (파트너 pause 능력 알 수 없음)
     */
}

비대칭 AN에서 흔히 간과되는 부차적 문제

비대칭 AN 발생 원인별 현실적 시나리오

비대칭 AN은 실무에서 주로 다음과 같은 상황에서 의도치 않게 발생합니다.

# 1. late_collision 카운터 증가율 감시 (0이어야 정상)
ethtool -S eth0 | awk '/late.?coll/{print $2}'

# 2. duplex가 half인 인터페이스 탐지
ethtool eth0 | grep "Duplex: Half" && echo "WARNING: half duplex detected on eth0"

# 3. AN on인데 Link partner advertised가 비어 있으면 Parallel Detection
ethtool eth0 | grep -A1 "Auto-negotiation: on" | grep "Not reported"

# 4. 전체 인터페이스 일괄 점검 스크립트
for iface in $(ls /sys/class/net/ | grep -v lo); do
  duplex=$(ethtool "$iface" 2>/dev/null | awk '/Duplex:/{print $2}')
  an=$(ethtool "$iface" 2>/dev/null | awk '/Auto-negotiation:/{print $2}')
  [ "$duplex" = "Half" ] && [ "$an" = "on" ] && \
    echo "ALERT: $iface — AN on but half duplex (possible parallel detect)"
done

AN 트리거 조건과 재시작 메커니즘

Auto-Negotiation은 PHY가 특정 이벤트를 감지했을 때 자동으로 시작되거나, 소프트웨어가 명시적으로 재시작할 수 있습니다. AN이 언제, 왜 시작되는지를 정확히 이해하면 링크 flap의 원인 분석이 훨씬 수월해집니다.

/* AN 재시작의 핵심: phy_start_aneg() — drivers/net/phy/phy.c */
int phy_start_aneg(struct phy_device *phydev)
{
    int err;

    if (!phydev->drv)
        return -EIO;

    mutex_lock(&phydev->lock);

    if (!__phy_is_started(phydev)) {
        WARN(1, "called from state %s\n",
             phy_state_to_str(phydev->state));
        err = -EBUSY;
        goto out;
    }

    /* AN 미지원이면 강제 모드로 전환 */
    if (AUTONEG_DISABLE == phydev->autoneg)
        phy_sanitize_settings(phydev);

    /* PHY 드라이버의 config_aneg 콜백 호출 */
    err = phydev->drv->config_aneg(phydev);
    if (err < 0)
        goto out;

    /* 상태를 AN으로 전환 — 상태 머신이 완료를 감시 */
    if (phydev->autoneg == AUTONEG_ENABLE) {
        err = phy_check_link_status(phydev);
    }
out:
    mutex_unlock(&phydev->lock);
    return err;
}

linkmode 비트맵과 MDIO 레지스터 매핑

커널의 phydev->advertising은 unsigned long 배열로 구현된 linkmode 비트맵이며, 이것이 실제 PHY 레지스터(ANAR, GBCR 등)로 변환되는 과정을 이해하면 AN 동작의 전체 그림이 보입니다. 변환은 양방향으로 이루어집니다: 설정 시에는 linkmode → 레지스터, 판독 시에는 레지스터 → linkmode입니다.

/* 변환 함수 체인 — include/linux/mii.h 기반 개념 재현 */

/* 1. linkmode → ANAR (설정 경로) */
static inline u32 linkmode_adv_to_lcl_adv_t(
    const unsigned long *advertising)
{
    u32 lcl_adv = 0;

    if (linkmode_test_bit(ETHTOOL_LINK_MODE_10baseT_Half_BIT, advertising))
        lcl_adv |= ADVERTISED_10baseT_Half;
    if (linkmode_test_bit(ETHTOOL_LINK_MODE_10baseT_Full_BIT, advertising))
        lcl_adv |= ADVERTISED_10baseT_Full;
    if (linkmode_test_bit(ETHTOOL_LINK_MODE_100baseTX_Half_BIT, advertising))
        lcl_adv |= ADVERTISED_100baseT_Half;
    if (linkmode_test_bit(ETHTOOL_LINK_MODE_100baseTX_Full_BIT, advertising))
        lcl_adv |= ADVERTISED_100baseT_Full;
    /* Pause 비트도 동일 패턴 */
    if (linkmode_test_bit(ETHTOOL_LINK_MODE_Pause_BIT, advertising))
        lcl_adv |= ADVERTISED_Pause;
    if (linkmode_test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, advertising))
        lcl_adv |= ADVERTISED_Asym_Pause;
    return lcl_adv;
}

static inline u32 ethtool_adv_to_mii_adv_t(u32 ethadv)
{
    u32 result = 0;
    /* ethtool 비트 → MII 레지스터 비트로 위치 변환 */
    if (ethadv & ADVERTISED_10baseT_Half)
        result |= ADVERTISE_10HALF;       /* ANAR bit 5 */
    if (ethadv & ADVERTISED_10baseT_Full)
        result |= ADVERTISE_10FULL;       /* ANAR bit 6 */
    if (ethadv & ADVERTISED_100baseT_Half)
        result |= ADVERTISE_100HALF;      /* ANAR bit 7 */
    if (ethadv & ADVERTISED_100baseT_Full)
        result |= ADVERTISE_100FULL;      /* ANAR bit 8 */
    if (ethadv & ADVERTISED_Pause)
        result |= ADVERTISE_PAUSE_CAP;    /* ANAR bit 10 */
    if (ethadv & ADVERTISED_Asym_Pause)
        result |= ADVERTISE_PAUSE_ASYM;   /* ANAR bit 11 */
    return result;
}

/* 2. ANLPAR → linkmode (판독 경로) — genphy_read_lpa() 내부 */
static inline u32 mii_lpa_to_ethtool_lpa_t(u32 lpa)
{
    u32 result = 0;
    /* MII 레지스터 비트 → ethtool 비트로 역변환 */
    if (lpa & LPA_10HALF)     result |= ADVERTISED_10baseT_Half;
    if (lpa & LPA_10FULL)     result |= ADVERTISED_10baseT_Full;
    if (lpa & LPA_100HALF)    result |= ADVERTISED_100baseT_Half;
    if (lpa & LPA_100FULL)    result |= ADVERTISED_100baseT_Full;
    if (lpa & LPA_PAUSE_CAP)  result |= ADVERTISED_Pause;
    if (lpa & LPA_PAUSE_ASYM) result |= ADVERTISED_Asym_Pause;
    return result;
}

/* 3. 결과 해석 — phy_resolve_aneg_linkmode() */
void phy_resolve_aneg_linkmode(struct phy_device *phydev)
{
    __ETHTOOL_DECLARE_LINK_MODE_MASK(common);

    /* 교집합: 로컬 advertising ∩ 상대편 lp_advertising */
    linkmode_and(common, phydev->advertising, phydev->lp_advertising);

    /* 우선순위에 따라 speed/duplex 결정 */
    if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT, common)) {
        phydev->speed = SPEED_1000;
        phydev->duplex = DUPLEX_FULL;
    } else if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT, common)) {
        phydev->speed = SPEED_1000;
        phydev->duplex = DUPLEX_HALF;
    } else if (linkmode_test_bit(ETHTOOL_LINK_MODE_100baseTX_Full_BIT, common)) {
        phydev->speed = SPEED_100;
        phydev->duplex = DUPLEX_FULL;
    } else if (linkmode_test_bit(ETHTOOL_LINK_MODE_100baseTX_Half_BIT, common)) {
        phydev->speed = SPEED_100;
        phydev->duplex = DUPLEX_HALF;
    } else {
        phydev->speed = SPEED_10;
        phydev->duplex = linkmode_test_bit(
            ETHTOOL_LINK_MODE_10baseT_Full_BIT, common)
            ? DUPLEX_FULL : DUPLEX_HALF;
    }

    /* Pause 해석 — Annex 28B 알고리즘 */
    phy_resolve_aneg_pause(phydev);
}

1000BASE-T PHY Training(링크 훈련) 상세

10/100BASE-T에서는 AN이 완료되면 곧바로 데이터 전송이 가능하지만, 1000BASE-T는 AN 완료 후 추가적인 PHY Training 단계가 필요합니다. 이 훈련 과정은 4쌍 양방향 PAM-5 부호화의 복잡성에서 비롯됩니다.

1000BASE-T의 핵심 문제는 같은 쌍(pair)으로 동시에 송신과 수신을 한다는 것입니다. 이를 위해 PHY 내부의 DSP(Digital Signal Processor)가 여러 간섭 성분을 제거해야 합니다:

# PHY Training 관련 진단

# 1. SNR(Signal-to-Noise Ratio) 확인 — 일부 PHY만 지원
# Marvell PHY: 페이지 5, 레지스터 21~24 (쌍별 SNR)
phytool write eth0/0/22 0x0005    # 페이지 5 선택
phytool read eth0/0/21             # Pair 0 SNR (dB 단위)
phytool read eth0/0/22             # Pair 1 SNR
phytool read eth0/0/23             # Pair 2 SNR
phytool read eth0/0/24             # Pair 3 SNR
# SNR > 20dB: 양호 | 15~20dB: 경계 | < 15dB: 불안정

# 2. 케이블 길이 추정 — TDR(Time Domain Reflectometry)
ethtool --cable-test eth0
# 또는 PHY 벤더별 TDR 레지스터 직접 접근

# 3. 심볼 에러 카운터
ethtool -S eth0 | grep -i "symbol\|phy_err\|frame"
# 심볼 에러가 지속 증가하면 Training 수렴이 불완전

# 4. Downshift 발생 여부 확인
ethtool eth0 | grep -i "downshift"
dmesg | grep -i "downshift"

# 5. PHY Training 시간 측정
# AN restart부터 link up까지의 dmesg 타임스탬프 차이
ethtool -r eth0    # AN 재시작
dmesg -w | grep "Link is"
# 1G: 보통 1~3초, 100M: 보통 0.5~1.5초

Clause 37 In-Band Auto-Negotiation 구현 상세

Clause 37은 1000BASE-X(광섬유) 및 SGMII(구리, MAC-PHY 간) 환경에서 사용되는 SerDes 기반 In-Band AN입니다. Clause 28이 별도의 FLP 펄스를 사용하는 것과 달리, Clause 37은 데이터 경로 자체(8B/10B 인코딩의 /C/ ordered set)를 통해 설정 정보를 교환합니다.

Clause 37의 Config Register(16비트)는 /C1/ 또는 /C2/ ordered set에 실려 전송됩니다. 이 ordered set는 8B/10B 인코딩에서 데이터와 구분되는 특수 심볼(/K28.5/)로 시작하므로, 데이터 전송 중에도 링크 상태를 교환할 수 있습니다.

/* Clause 37 AN 구현 — drivers/net/pcs/pcs-lynx.c 참조 (개념 재현) */

/* PCS에서 Clause 37 AN 설정 */
static int lynx_pcs_config_cl37(struct phylink_pcs *pcs,
                                  const unsigned long *advertising)
{
    u16 config_reg = 0;

    /* 1000BASE-X: speed 협상 없음, duplex + pause만 */
    if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseX_Full_BIT, advertising))
        config_reg |= ADVERTISE_1000XFULL;    /* bit 5 */
    if (linkmode_test_bit(ETHTOOL_LINK_MODE_Pause_BIT, advertising))
        config_reg |= ADVERTISE_1000XPAUSE;   /* bit 7 */
    if (linkmode_test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, advertising))
        config_reg |= ADVERTISE_1000XPSE_ASYM; /* bit 8 */

    /* PCS AN Advertisement 레지스터에 기록 (MII_ADVERTISE, reg 4) */
    mdiodev_modify(pcs->mdio, MII_ADVERTISE,
                    ADVERTISE_1000XFULL | ADVERTISE_1000XHALF |
                    ADVERTISE_1000XPAUSE | ADVERTISE_1000XPSE_ASYM,
                    config_reg);

    /* BMCR에서 AN 활성화 + 재시작 */
    mdiodev_modify(pcs->mdio, MII_BMCR,
                    BMCR_ANENABLE | BMCR_ANRESTART,
                    BMCR_ANENABLE | BMCR_ANRESTART);
    return 0;
}

/* SGMII AN 결과 판독 — PHY→MAC 방향 Control Word 해석 */
static void lynx_pcs_get_sgmii_state(struct phylink_pcs *pcs,
                                      struct phylink_link_state *state)
{
    int lpa = mdiodev_read(pcs->mdio, MII_LPA);  /* ANLPAR */

    /* SGMII Control Word 해석 */
    state->link   = !!(lpa & LPA_SGMII_LINK);     /* bit 15 */
    state->duplex = (lpa & LPA_SGMII_DPX_SPD_1000)
                    ? DUPLEX_FULL : DUPLEX_HALF;   /* bit 12 */

    /* Speed: bit 11:10 */
    switch (lpa & LPA_SGMII_SPEED) {
    case LPA_SGMII_10:
        state->speed = SPEED_10;
        break;
    case LPA_SGMII_100:
        state->speed = SPEED_100;
        break;
    case LPA_SGMII_1000:
        state->speed = SPEED_1000;
        break;
    }
}

AN 시퀀스 타임라인: 실제 교환 시나리오

Auto-Negotiation의 전체 과정을 시간 순서대로 추적하면, 각 단계에서 어떤 신호가 오가고 어떤 조건으로 다음 단계로 진행되는지 명확해집니다. 아래는 1000BASE-T 환경에서 NIC와 스위치가 연결되는 전형적인 시나리오입니다.

# AN 시퀀스 추적 체크리스트

# 1단계: AN 시작 확인 — BMCR 읽기
phytool read eth0/0/0
# bit 12(AN_ENABLE)=1, bit 9(AN_RESTART) 확인
# AN 시작 직후에는 bit 9가 1이었다가 PHY가 자동으로 0으로 클리어

# 2단계: Base Page 교환 확인 — BMSR, ANAR, ANLPAR 읽기
phytool read eth0/0/1   # BMSR: bit 5(AN_COMPLETE) 확인
phytool read eth0/0/4   # ANAR: 내가 무엇을 광고했는지
phytool read eth0/0/5   # ANLPAR: 상대가 무엇을 광고했는지
# ANLPAR이 0x0000이면 상대가 응답하지 않은 것

# 3단계: 1G 확장 확인 — GBCR, GBSR 읽기
phytool read eth0/0/9   # GBCR: bit 9(1G-FD 광고), bit 12:11(MS 설정)
phytool read eth0/0/10  # GBSR: bit 14(MS config fault), bit 13(master/slave)
# bit 14=1이면 양쪽 모두 같은 역할을 강제한 것

# 4단계: 결과 확인
ethtool eth0
# Speed, Duplex, Autoneg, Link detected, master-slave status 전체 확인

# 5단계: Training 성공 확인 — 에러 카운터
ethtool -S eth0 | grep -E "crc|symbol|error"
# Training 직후 symbol error가 잠깐 나올 수 있으나, 지속되면 문제

# 6단계: 타이밍 측정
ethtool -r eth0 && dmesg -w | grep "Link is"
# AN restart부터 Link Up까지 시간 확인
# 10/100M: 1~2초 | 1000M: 2~4초 | 5초 이상: 케이블/PHY 문제

AN 완료 인터럽트와 폴링 전환 메커니즘

PHY가 AN 완료를 커널에 알리는 방법은 인터럽트(IRQ)와 폴링(Polling) 두 가지입니다. 어떤 방식이 사용되는지는 하드웨어 설계와 PHY 드라이버에 따라 달라지며, 두 방식의 차이는 링크 감지 지연 시간에 직접 영향을 줍니다.

/* PHY 인터럽트 vs 폴링 — drivers/net/phy/phy.c 참조 */

/* 인터럽트 모드: PHY가 링크 변화를 IRQ로 통보 */
static irqreturn_t phy_interrupt(int irq, void *phy_dat)
{
    struct phy_device *phydev = phy_dat;

    /* PHY 드라이버의 handle_interrupt 콜백 호출 */
    if (phydev->drv->handle_interrupt)
        return phydev->drv->handle_interrupt(phydev);

    /* 레거시: did_interrupt + ack_interrupt */
    if (phydev->drv->did_interrupt &&
        !phydev->drv->did_interrupt(phydev))
        return IRQ_NONE;

    /* threaded IRQ에서 상태 갱신 예약 */
    phy_trigger_machine(phydev);
    return IRQ_HANDLED;
}

/* 폴링 모드: 1초 주기로 상태 확인 */
static void phy_state_machine(struct work_struct *work)
{
    struct phy_device *phydev = ...;

    mutex_lock(&phydev->lock);

    /* BMSR 읽기 → link/speed/duplex 갱신 */
    phy_check_link_status(phydev);

    mutex_unlock(&phydev->lock);

    /* 다음 폴링 예약 (PHY_STATE_TIME = 1초) */
    if (phy_polling_mode(phydev))
        phy_queue_state_machine(phydev, PHY_STATE_TIME);
}

/* phy_polling_mode() 판단 기준 */
static inline bool phy_polling_mode(struct phy_device *phydev)
{
    /* IRQ가 PHY_POLL이면 폴링 모드 */
    if (phydev->irq == PHY_POLL)
        return true;
    /* MAC이 in-band status를 사용하면 PHY 폴링 불필요 */
    if (phydev->drv->flags & PHY_IS_INTERNAL)
        return false;
    return false;
}

/* Realtek RTL8211F의 인터럽트 처리 예시 */
static int rtl8211f_config_intr(struct phy_device *phydev)
{
    int val;

    if (phydev->interrupts == PHY_INTERRUPT_ENABLED) {
        /* Link change, AN complete, speed change 인터럽트 활성화 */
        val = phy_read(phydev, RTL8211F_INER);
        val |= RTL8211F_INER_LINK_STATUS;  /* link change */
        return phy_write(phydev, RTL8211F_INER, val);
    } else {
        /* 모든 인터럽트 비활성화 */
        return phy_write(phydev, RTL8211F_INER, 0);
    }
}

static irqreturn_t rtl8211f_handle_interrupt(struct phy_device *phydev)
{
    int val;

    /* 인터럽트 상태 레지스터 읽기 (읽으면 자동 클리어) */
    val = phy_read(phydev, RTL8211F_INSR);
    if (val < 0)
        return IRQ_NONE;

    /* link change 비트가 세트되었으면 상태 머신 트리거 */
    if (val & RTL8211F_INSR_LINK_STATUS) {
        phy_trigger_machine(phydev);
        return IRQ_HANDLED;
    }
    return IRQ_NONE;
}

/* Device Tree: PHY 인터럽트 설정 예시 */
&mdio {
    phy0: ethernet-phy@0 {
        reg = <0>;
        /* IRQ 모드 — AN 완료를 즉시 감지 */
        interrupt-parent = <&gpio1>;
        interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
    };
};

/* 위 속성이 없으면 → PHY_POLL → 1초 간격 폴링 */

MAC-PHY 인터페이스 모드

phy-mode는 매체 종류가 아니라 MAC과 PHY 사이의 디지털 인터페이스 계약을 뜻합니다. 이 값이 틀리면 링크가 아예 안 올라오거나, 올라와도 CRC와 symbol error가 폭증합니다. 특히 RGMII 계열은 지연 보상 위치를 명확히 해야 하고, SGMII/1000BASE-X/2500BASE-X는 in-band status 처리 여부까지 맞아야 합니다.

phy-mode 선택 가이드

phy-mode는 보드 설계에 이미 결정되어 있는 물리적 연결을 소프트웨어에 알려 주는 설정이므로, "무엇이 더 좋은가"가 아니라 "회로도와 일치하는가"가 유일한 기준입니다. 회로도 확인이 어려운 경우에는 다음 순서로 추론할 수 있습니다.

1. SoC 데이터시트에서 해당 포트의 지원 인터페이스 목록을 확인합니다.
2. PHY 데이터시트에서 해당 SoC 포트와 연결된 핀이 RGMII인지 SGMII인지 확인합니다.
3. 클럭 연결을 봅니다. RGMII는 125MHz 참조 클럭이 별도로 있고, SGMII/SerDes는 차동 클럭 또는 CDR 내장입니다.
4. 기존 벤더 BSP의 Device Tree 설정을 참고하되, 벤더 실수가 있을 수 있으므로 실물 회로도와 교차 확인합니다.

RGMII DDR 타이밍과 지연 보상 상세

RGMII(Reduced Gigabit Media Independent Interface)는 125MHz 클럭을 사용하여 상승 에지와 하강 에지 모두에서 데이터를 전송하는 DDR(Double Data Rate) 방식입니다. 클럭 주기는 8ns이며, 상승/하강 에지 간격은 4ns입니다. IEEE 802.3 표준과 RGMII 사양은 데이터 유효 윈도우를 클럭 에지 기준으로 setup 시간 약 1.5ns, hold 시간 약 1.5ns로 규정합니다.

문제는 MAC이 클럭과 데이터를 동시에 출력한다는 점입니다. 클럭 에지가 데이터 천이(transition) 순간과 정확히 일치하면 수신 측 PHY는 데이터가 변하는 순간을 샘플링하게 되어 신뢰할 수 없는 결과를 읽습니다. 이를 해결하기 위해 클럭을 2ns 지연시켜 에지가 데이터 유효 구간의 중앙에 오도록 보정합니다.

RGMII 서브모드 상세

Device Tree에서 phy-mode와 rx-internal-delay-ps, tx-internal-delay-ps 속성을 조합하거나, 레거시 방식으로 아래 4가지 서브모드 문자열을 직접 지정합니다. 각 서브모드가 내부 지연을 어느 방향에 적용하는지 정확히 이해해야 이중 적용을 방지할 수 있습니다.

커널의 RGMII 지연 결정 흐름

커널은 Device Tree 속성을 읽어 PHY 드라이버에 요청할 지연 값을 결정합니다. phy_get_internal_delay() 함수는 rx-internal-delay-ps 또는 tx-internal-delay-ps 속성을 피코초 단위로 읽고, PHY 드라이버가 제공하는 지원 지연 테이블과 가장 가까운 값을 선택합니다.

/* drivers/net/phy/phy.c (개념 흐름 — 실제 함수 시그니처 요약) */

/* Device Tree 속성에서 피코초 단위 지연을 읽는다 */
int phy_get_internal_delay(struct phy_device *phydev,
                           struct device *dev,
                           const int *delay_values, /* PHY 지원 테이블 */
                           int size,
                           bool is_rx)
{
    /* "rx-internal-delay-ps" 또는 "tx-internal-delay-ps" 읽기 */
    u32 delay_ps;
    if (device_property_read_u32(dev,
            is_rx ? "rx-internal-delay-ps"
                  : "tx-internal-delay-ps",
            &delay_ps))
        return -EINVAL;   /* 속성 없음 → 레거시 phy-mode 문자열로 결정 */

    /* PHY 지원 테이블에서 가장 가까운 값 선택 */
    for (int i = 0; i < size - 1; i++) {
        if (delay_ps <= (delay_values[i] + delay_values[i + 1]) / 2)
            return i;
    }
    return size - 1;
}

/* PHY 드라이버 probe 시 호출 예시 */
static int my_phy_config_init(struct phy_device *phydev)
{
    /* rgmii-id / rgmii-txid → TX 내부 지연 활성화 */
    bool tx_delay = phy_interface_is_rgmii(phydev->interface) &&
                    (phydev->interface != PHY_INTERFACE_MODE_RGMII) &&
                    (phydev->interface != PHY_INTERFACE_MODE_RGMII_RXID);

    /* rgmii-id / rgmii-rxid → RX 내부 지연 활성화 */
    bool rx_delay = phy_interface_is_rgmii(phydev->interface) &&
                    (phydev->interface != PHY_INTERFACE_MODE_RGMII) &&
                    (phydev->interface != PHY_INTERFACE_MODE_RGMII_TXID);

    my_phy_set_delay(phydev, tx_delay, rx_delay);
    return 0;
}

지연 삽입 위치와 책임 분리

TX와 RX 각 방향에 대해 2ns 지연을 삽입할 수 있는 위치는 세 군데입니다. 세 위치 중 정확히 한 곳만 지연을 담당해야 합니다. 아래 다이어그램은 TX 방향을 기준으로 각 위치의 역할을 보여 줍니다.

흔한 실수 유형

PHY 드라이버의 지연 레지스터 설정 예시

Realtek 계열 PHY를 포함한 많은 Gigabit PHY는 내부 지연을 레지스터로 제어합니다. 아래는 개념적인 드라이버 패턴으로, 실제 비트 위치와 레지스터 번호는 각 PHY 데이터시트를 확인해야 합니다.

/* 개념적 Realtek 스타일 RGMII 지연 설정 */

#define PHY_PAGE_ADDR_REG    31
#define PHY_EXT_PAGE         7
#define PHY_RGMII_DELAY_REG  28   /* 확장 레지스터 (페이지 7) */
#define TX_DELAY_BIT         BIT(1)
#define RX_DELAY_BIT         BIT(0)

static int rtl_phy_set_rgmii_delay(struct phy_device *phydev,
                                   bool tx_delay, bool rx_delay)
{
    int ret, val;

    /* 확장 레지스터 페이지 진입 */
    ret = phy_write(phydev, PHY_PAGE_ADDR_REG, PHY_EXT_PAGE);
    if (ret)
        return ret;

    val = phy_read(phydev, PHY_RGMII_DELAY_REG);
    if (val < 0)
        goto restore_page;

    /* TX/RX 지연 비트 설정 */
    if (tx_delay)
        val |= TX_DELAY_BIT;
    else
        val &= ~TX_DELAY_BIT;

    if (rx_delay)
        val |= RX_DELAY_BIT;
    else
        val &= ~RX_DELAY_BIT;

    ret = phy_write(phydev, PHY_RGMII_DELAY_REG, val);

restore_page:
    /* 일반 레지스터 페이지 복귀 */
    phy_write(phydev, PHY_PAGE_ADDR_REG, 0);
    return ret;
}

static int rtl_phy_config_init(struct phy_device *phydev)
{
    bool tx = (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
               phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID);
    bool rx = (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
               phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID);

    return rtl_phy_set_rgmii_delay(phydev, tx, rx);
}

SerDes, PCS, SFP 모듈

구리 RJ45 PHY만 생각하면 PHY를 외부 칩 하나로 이해하기 쉽지만, 실제 장비에서는 host PCS, SerDes lane, SFP cage, 모듈 내부 PHY 또는 광 PMD가 나뉘어 있을 수 있습니다. 특히 1000BASE-X와 SGMII는 비슷한 1.25Gbaud 직렬 링크처럼 보여도 control word 의미와 in-band status 해석이 달라, 모드를 잘못 맞추면 링크 LED는 켜져도 실제 프레임 송수신이 안 될 수 있습니다.

• 광 모듈은 주로 PMD 성격이 강하고, host 쪽 PCS와 SerDes 설정이 맞아야 링크가 정상입니다.
• RJ45 copper SFP는 안에 별도 copper PHY가 들어 있어 발열, 전력, latency 특성이 일반 광 모듈과 다릅니다.
• LOS/TX_FAULT/MOD_ABS는 MDIO가 아니라 모듈 sideband 신호인 경우가 많습니다. PHY 레지스터만 봐서는 원인을 못 찾을 수 있습니다.

SFP sideband 신호를 같이 봐야 하는 이유

광 모듈 문제는 MDIO만으로 보이지 않는 경우가 많습니다. 모듈이 스스로 올리는 LOS, TX_FAULT, MOD_ABS, TX_DISABLE 같은 sideband는 host PCS와 phylink 정책에 직접 영향을 줍니다. 즉 광량과 DOM은 정상인데도 sideband 한 줄이 반대로 연결되어 전체 링크가 막힐 수 있습니다.

phylib과 phylink

phylib은 "PHY 칩을 커널이 공통 방식으로 다루기 위한 프레임워크"이고, phylink는 "MAC, PHY, PCS, fixed-link, SFP를 하나의 정책으로 묶는 상위 계층"입니다. 외부 PHY 하나를 단순히 연결하는 임베디드 보드라면 phylib만으로 충분할 수 있지만, SFP 모듈 핫플러그(Hotplug)나 in-band status, 고속 SerDes가 얽히면 phylink가 사실상 표준 선택입니다.

/* 개념 예시: PHY 드라이버가 구현하는 핵심 콜백 */
static int myphy_config_init(struct phy_device *phydev);
static int myphy_config_aneg(struct phy_device *phydev);
static int myphy_read_status(struct phy_device *phydev);

static struct phy_driver myphy_driver = {
    .phy_id       = 0x001cc916,
    .phy_id_mask  = 0xfffffff0,
    .name         = "Example PHY",
    .config_init  = myphy_config_init,
    .config_aneg  = myphy_config_aneg,
    .read_status  = myphy_read_status,
};

/* 개념 예시: phylink 초기화와 firmware 기반 PHY 연결 */
static const struct phylink_mac_ops my_phylink_ops = {
    .mac_config = my_mac_config,
    .mac_link_up = my_mac_link_up,
    .mac_link_down = my_mac_link_down,
};

static int my_phylink_init(struct my_priv *priv)
{
    struct phylink_config *cfg = &priv->phylink_config;
    struct fwnode_handle *fwnode = dev_fwnode(priv->dev);
    phy_interface_t iface = priv->phy_mode;

    priv->phylink = phylink_create(cfg, fwnode, iface, &my_phylink_ops);
    if (IS_ERR(priv->phylink))
        return PTR_ERR(priv->phylink);

    if (is_of_node(fwnode))
        return phylink_of_phy_connect(priv->phylink, to_of_node(fwnode), 0);
    return phylink_fwnode_phy_connect(priv->phylink, fwnode, 0);
}

phylink를 도입하면 링크 업/다운 알림, SFP 모듈 감지, PCS 선택, fixed-link 해석을 한 계층에서 정리할 수 있습니다. 반대로 mac_config(), mac_link_up(), mac_link_down() 구현이 느슨하면 링크는 오르는데 실제 MAC 레지스터가 이전 속도를 유지하는 문제가 생길 수 있습니다.

phylib vs phylink 선택 기준

새 MAC 드라이버를 작성할 때 어느 쪽을 선택할지는 보드의 PHY 토폴로지에 따라 결정됩니다. 아래 조건 중 하나라도 해당하면 phylink을 사용하는 것이 맞습니다.

분리형 PCS와 In-Band Status

고속 SerDes 기반 설계에서는 PHY가 모든 계층을 혼자 담당하지 않습니다. host MAC 안에 별도 PCS가 있고, 외부에는 PMA/PMD 성격이 강한 장치만 있거나, 반대로 외부 PHY는 있지만 링크 상태 결정은 host PCS가 수행하는 경우가 있습니다. 이때 커널은 단순한 phy_device만으로는 부족하고, phylink_pcs를 통해 "MAC 옆의 PCS"를 별도 객체로 다뤄야 합니다.

실무적으로는 SGMII, 1000BASE-X, 2500BASE-X, 10GBASE-R에서 이 구분이 중요합니다. 외부 copper PHY가 속도 협상을 끝냈더라도, host PCS가 그 결과를 in-band status로 받아 MAC 속도를 다시 맞추지 않으면 실제 데이터 경로가 잘못된 속도로 남을 수 있습니다.

/* 개념 예시: 분리형 PCS를 phylink에 등록 */
static void my_pcs_get_state(struct phylink_pcs *pcs,
                             struct phylink_link_state *state)
{
    /* host PCS의 block lock, speed code, duplex 상태 해석 */
}

static const struct phylink_pcs_ops my_pcs_ops = {
    .pcs_get_state = my_pcs_get_state,
    .pcs_config = my_pcs_config,
    .pcs_an_restart = my_pcs_restart_an,
    .pcs_link_up = my_pcs_link_up,
};

static int my_mac_select_pcs(struct phylink_config *config,
                                 phy_interface_t interface)
{
    return interface == PHY_INTERFACE_MODE_SGMII ? 0 : 0;
}

/* SFP/SerDes 경로에서 host PCS가 in-band status를 읽는 예시 */
&eth0 {
    phy-mode = "sgmii";
    managed = "in-band-status";
    sfp = <&sfp0>;
    status = "okay";
};

In-Band vs Out-of-Band 링크 상태 결정

PHY 링크 상태를 MAC에 전달하는 경로는 크게 두 가지입니다. Out-of-Band는 데이터 경로와 물리적으로 분리된 관리 채널을 통해 상태를 읽는 방식이고, In-Band는 데이터가 흐르는 직렬 링크 자체에 상태 정보를 실어 보내는 방식입니다. 두 방식은 배타적이지 않으며, 같은 포트에서 외부 PHY의 MDIO(out-of-band)와 host PCS의 in-band status가 동시에 존재할 수 있습니다. 이 경우 phylink이 양쪽 결과를 통합하여 MAC 속도를 결정합니다.

SGMII In-Band Control Word 형식

SGMII는 Cisco가 정의한 인터페이스로, Clause 37과 같은 1.25Gbaud 8B/10B 직렬 링크를 사용하지만 control word의 의미가 완전히 다릅니다. PHY→MAC 방향에서는 링크 상태, 속도, duplex 정보를 담은 16비트 word를 보내고, MAC→PHY 방향에서는 acknowledge만 돌려보냅니다. 이 비대칭 구조가 Clause 37(양쪽 대칭)과의 핵심 차이입니다.

/* 개념 예시: SGMII control word 해석 */
static void sgmii_decode_word(u16 word, struct phylink_link_state *state)
{
    state->link  = !!(word & BIT(15));
    state->duplex = (word & BIT(12)) ? DUPLEX_FULL : DUPLEX_HALF;
    switch ((word >> 10) & 3) {
    case 0:  state->speed = SPEED_10;   break;
    case 1:  state->speed = SPEED_100;  break;
    case 2:  state->speed = SPEED_1000; break;
    default: state->link = 0;          break;
    }
}
/* 참조: drivers/net/pcs/pcs-xpcs.c — xpcs_get_state_sgmii()
 *       drivers/net/pcs/pcs-lynx.c — lynx_pcs_get_state_sgmii() */

1000BASE-X Clause 37 Base Page 형식

Clause 37은 IEEE 802.3에서 정의한 1000BASE-X 전용 Auto-Negotiation입니다. 8B/10B 스트림 안에서 /C/ ordered set을 교환하여 16비트 base page를 주고받습니다. SGMII와 달리 양쪽이 대칭이며, 속도 정보가 없습니다(항상 1000Mbps). 협상의 주된 목적은 pause(흐름 제어) 능력과 duplex를 결정하는 것입니다.

/* 개념 예시: Clause 37 base page 해석 */
static void clause37_decode_page(u16 lpa, struct phylink_link_state *state)
{
    state->speed  = SPEED_1000;  /* 항상 1000Mbps */
    state->duplex = (lpa & BIT(5)) ? DUPLEX_FULL : DUPLEX_HALF;
    state->pause  = MLO_PAUSE_NONE;
    if (lpa & BIT(7))
        state->pause |= MLO_PAUSE_SYM;
    if (lpa & BIT(8))
        state->pause |= MLO_PAUSE_ASYM;
}
/* 참조: include/uapi/linux/mii.h — ADVERTISE_1000XFULL, ADVERTISE_1000XPAUSE */

Clause 73 백플레인 In-Band AN

10GBASE-KR, 25GBASE-KR, 40GBASE-KR4 등 고속 백플레인(Backplane) 링크에서는 Clause 73이 사용됩니다. Clause 37과 달리 multi-page 구조(base page 48비트 + next page)를 가지며, FEC 능력 광고와 AN 후 link training 시퀀스가 추가됩니다. AN이 완료된 뒤 양단이 SerDes equalizer를 최적화하는 훈련 과정을 거쳐야 비로소 데이터 경로가 열립니다.

phylink의 링크 상태 결정 경로

phylink은 초기화 시점에 Device Tree 설정과 MAC 드라이버 능력에 따라 링크 상태 결정 모드를 선택합니다. 세 가지 모드 — MLO_AN_PHY, MLO_AN_INBAND, MLO_AN_FIXED — 는 각각 다른 콜백 체인을 활성화하며, 이 선택이 링크 수명주기 전체를 결정합니다.

/* 개념 예시: phylink_resolve() 단순화 흐름
 * 참조: drivers/net/phy/phylink.c — phylink_resolve() */
static void phylink_resolve(struct work_struct *w)
{
    struct phylink *pl = container_of(w, struct phylink, resolve);
    struct phylink_link_state link_state;

    switch (pl->cur_link_an_mode) {
    case MLO_AN_PHY:
        /* 외부 PHY가 이미 읽어둔 상태를 복사 */
        link_state = pl->phy_state;
        break;
    case MLO_AN_INBAND:
        /* Host PCS에서 in-band 상태를 직접 읽음 */
        pl->pcs->ops->pcs_get_state(pl->pcs, &link_state);
        break;
    case MLO_AN_FIXED:
        /* DT에서 가져온 고정값 사용 */
        link_state = pl->link_config;
        link_state.link = 1;
        break;
    }

    /* 상태가 변경되었으면 MAC에 반영 */
    if (link_state.link && !pl->old_link_state)
        pl->mac_ops->mac_link_up(pl->config, pl->cur_link_an_mode,
                                   link_state.interface, ...);
}

/* 개념 예시: PCS 드라이버가 SGMII in-band 상태를 보고하는 콜백
 * 참조: drivers/net/pcs/pcs-xpcs.c, drivers/net/pcs/pcs-lynx.c */
static void my_pcs_get_state(struct phylink_pcs *pcs,
                             struct phylink_link_state *state)
{
    u32 status = readl(priv->pcs_base + PCS_STATUS);
    u16 lpa    = readl(priv->pcs_base + PCS_LP_ABILITY);

    state->an_complete = !!(status & PCS_AN_DONE);
    state->link = !!(status & PCS_LINK_UP);

    if (state->link) {
        if (state->interface == PHY_INTERFACE_MODE_SGMII) {
            /* SGMII: control word에서 speed/duplex 추출 */
            sgmii_decode_word(lpa, state);
        } else {
            /* 1000BASE-X: Clause 37 base page에서 pause/duplex 추출 */
            clause37_decode_page(lpa, state);
        }
    }
}

PHY 기능과 튜닝 포인트

PHY는 단순히 링크를 올리는 장치가 아니라, 운영 중 성능과 안정성을 좌우하는 여러 정책을 가집니다. 저전력 중심이면 EEE가 중요하고, 긴 케이블과 구형 배선이면 downshift와 cable diagnostics가 유용하며, 고속 광링크에서는 FEC 선택이 BER과 latency를 좌우합니다. 튜닝은 "항상 켠다/끈다"가 아니라 증상과 환경에 따라 선택해야 합니다.

# EEE 상태 조회와 비활성화
ethtool --show-eee eth0
ethtool --set-eee eth0 eee off

# Downshift 정책 설정 (지원 PHY만)
ethtool --set-phy-tunable eth0 downshift on count 3

# 케이블 테스트 (지원 PHY만)
ethtool --cable-test eth0

# FEC 상태 조회
ethtool --show-fec eth0

Master/Slave, downshift, EDPD를 함께 읽기

1000BASE-T 이상 구리 PHY에서는 링크 양단이 기준 클럭 제공자를 정해야 합니다. 이것이 master/slave 결정입니다. 동시에 배선 품질이 좋지 않으면 고속 협상에 반복 실패하고, 그 결과 downshift가 작동해 낮은 속도로만 링크가 붙습니다. 여기서 EDPD(Energy Detect Power Down)가 섞이면 idle 상태에서 PHY가 더 깊게 잠들었다가 복귀하면서 협상이 늦어지는 증상이 나타날 수 있습니다.

# PHY 튜너블 조회
ethtool --show-phy-tunable eth0

# 에너지 감지 파워다운 설정 (지원 PHY만)
ethtool --set-phy-tunable eth0 energy-detect-power-down on

Loopback과 자가 진단을 계층별로 분리하기

루프백은 "상대편 없이 내 경로만 검증"하는 가장 빠른 방법이지만, 어느 계층에서 되돌리는지에 따라 검증 범위가 달라집니다. MAC loopback은 MAC과 DMA까지만 확인하고, PCS loopback은 host PCS와 SerDes 일부까지, PHY loopback은 PMA/PMD까지 포함할 수 있습니다. 반대로 외부 케이블과 원격 포트는 빠지므로, 루프백이 통과했다고 실제 배선 문제가 사라지는 것은 아닙니다.

1. MAC loopback
   DMA, descriptor, netdev 경로를 빠르게 검증합니다.
2. PCS loopback
   SerDes encoding과 block lock 경로를 좁혀 봅니다.
3. PHY 내부 loopback
   외부 케이블 없이 PHY 내부 DSP 경로를 확인합니다.
4. 원격 loopback
   상대편 장비가 지원할 때 전체 선로까지 포함한 검증이 가능합니다.

PHY 하드웨어 타임스탬프와 시간 민감 네트워크

일부 PHY는 MAC보다 더 선로 가까운 위치에서 송수신 타임스탬프를 찍을 수 있습니다. 이런 PHY는 PTP(IEEE 1588)나 TSN 환경에서 유리할 수 있는데, 패킷이 실제 wire를 통과한 시점에 더 가까운 시각을 얻을 수 있기 때문입니다. 다만 시스템 전체에서는 MAC 쪽 PHC와 PHY 쪽 타임스탬프 경로를 혼동하지 않아야 하며, 사용자 공간(User Space)에서는 결국 SO_TIMESTAMPING과 ethtool -T로 노출된 능력으로 보게 됩니다.

# 인터페이스의 HW timestamping / PHC 지원 확인
ethtool -T eth0

PHY 인터럽트, 폴링(Polling), 전원 관리(Power Management)

PHY 상태 머신은 크게 폴링과 인터럽트 두 방식으로 링크 변화를 감시합니다. 폴링은 단순하고 안정적이지만 변화 감지가 느리고, 인터럽트는 빠르지만 마스크/ack 처리와 공유 IRQ 문제를 정확히 구현해야 합니다. 모바일·임베디드 장치에서는 여기에 suspend/resume, Wake-on-LAN, EEE, EDPD가 더해져 "전원이 꺼져 있을 때 PHY를 어디까지 살릴 것인가"가 추가 과제가 됩니다.

/* 개념 예시: IRQ 기반 PHY 링크 감지 */
static irqreturn_t myphy_handle_interrupt(struct phy_device *phydev)
{
    int irq_stat;

    irq_stat = phy_read(phydev, 0x13);
    if (irq_stat < 0)
        return IRQ_NONE;

    /* 벤더 IRQ status를 읽어 clear 한 뒤 상태 머신 재실행 */
    phy_trigger_machine(phydev);
    return IRQ_HANDLED;
}

static int myphy_suspend(struct phy_device *phydev)
{
    /* WoL, EEE, EDPD 정책에 따라 analog block 일부만 유지 */
    return genphy_suspend(phydev);
}

static int myphy_resume(struct phy_device *phydev)
{
    int ret = genphy_resume(phydev);
    if (ret)
        return ret;

    /* resume 뒤 strap override와 delay bit를 다시 써야 하는 PHY도 있다 */
    return myphy_set_rgmii_delay(phydev);
}

• IRQ가 있다고 항상 좋은 것은 아닙니다. 링크 변화가 잦은 환경에서는 잘못된 인터럽트 마스크가 오히려 CPU를 더 흔듭니다.
• resume 뒤 재설정이 필요한 PHY가 있습니다. strap 결과를 runtime에서 override한 경우 특히 resume에서 다시 써야 합니다.
• WoL을 켜려면 PHY analog rail과 magic packet 검출 경로를 살려야 하므로, 단순 regulator off와 충돌할 수 있습니다.

Device Tree와 보드 설계 포인트

보드 bring-up에서는 커널 코드보다 Device Tree와 하드웨어 배선이 더 자주 문제를 일으킵니다. PHY 주소가 틀리거나, reset GPIO hold 시간이 부족하거나, 25MHz reference clock이 안정되기 전에 MDIO 접근이 시작되면 드라이버는 정상이어도 PHY를 못 찾습니다. 특히 RGMII는 내부 지연과 PCB trace delay를 어느 한 곳에서만 넣어야 합니다.

/* 보드 .dts 예시: 외부 RGMII PHY 연결 */
&emac {
    pinctrl-names = "default";
    pinctrl-0 = <&ext_rgmii_pins>;
    phy-mode = "rgmii-id";
    phy-handle = <&ext_rgmii_phy>;
    phy-supply = <&reg_gmac_3v3>;
    status = "okay";
};

&mdio {
    ext_rgmii_phy: ethernet-phy@1 {
        compatible = "ethernet-phy-ieee802.3-c22";
        reg = <1>;
        reset-gpios = <&pio 3 14 GPIO_ACTIVE_LOW>;
        reset-assert-us = <15000>;
        reset-deassert-us = <40000>;
    };
};

strap pin과 reset 시퀀싱을 따로 점검하기

많은 PHY는 reset 해제 순간 strap pin을 샘플링해 주소, RGMII delay 기본값, LED 모드, SGMII/Fiber 선택 같은 초기 동작을 결정합니다. 이때 LED 핀과 strap 핀이 겸용인 설계가 흔해서, pull-up/pull-down 세기와 reset 폭이 기대와 조금만 어긋나도 PHY는 전혀 다른 모드로 부팅할 수 있습니다. 소프트웨어가 나중에 override할 수 있어도, 부팅 초기에 이미 잘못된 주소와 모드로 올라오면 MDIO 탐지부터 실패할 수 있습니다.

보드 Bring-up 체크리스트

외부 PHY가 달린 보드를 처음 올릴 때는 "드라이버가 로드됐는가"보다 "PHY가 물리적으로 살아 있는가"부터 확인해야 합니다. bring-up 초반에는 MDIO 읽기가 성공하는지만으로도 절반은 해결된 상태입니다. 이후에는 reset 타이밍, strap pin, 지연 보상, 상대편 링크 정책, 실제 트래픽 품질 순서로 범위를 좁히는 것이 좋습니다.

외부 PHY가 없는 경우: fixed-link

스위치 CPU 포트나 백플레인처럼 외부 PHY가 없이 PCS/SerDes만 존재하는 경우에는 phy-handle 대신 fixed-link를 사용하기도 합니다. 이 경우 MDIO로 읽을 PHY가 없으므로, 링크 정책과 상태 전달을 MAC/phylink 계층에서 처리해야 합니다.

/* 외부 PHY 없이 고정 링크를 선언하는 예시 */
&eth0 {
    phy-mode = "sgmii";
    fixed-link {
        speed = <1000>;
        full-duplex;
        pause;
    };
};

신호 무결성과 보드 레이아웃

PHY 문서가 소프트웨어 쪽으로만 흘러가기 쉽지만, 실제로는 보드 레이아웃이 링크 품질을 절반 이상 좌우합니다. 특히 RGMII 병렬 버스는 각 신호의 도착 시간 차이가 중요하고, SerDes는 임피던스와 return path, via stub, refclk 품질이 더 중요합니다. 같은 드라이버가 어떤 보드에서는 완벽하고 다른 보드에서는 CRC를 뿜는 이유가 여기에 있습니다.

중요한 점은 "숫자 하나"를 외우는 것이 아니라, PHY 데이터시트와 PCB stack-up, 커넥터 배치, 전원 분리 전략을 함께 보는 것입니다. RGMII는 지연 위치가 핵심이고, SGMII/USXGMII는 차동쌍 품질과 refclk 지터, 광 모듈 경로는 cage 접지와 전력 예산이 중요합니다.

대표 장애 패턴과 원인 분리

PHY 문제는 반복적으로 비슷한 모양으로 나타납니다. 아래 패턴을 외워 두면 "드라이버 버그인지, 보드 타이밍인지, 상대편 정책인지"를 빨리 구분할 수 있습니다.