Linux 7.2に向けたネットワーク更新は、派手な単一機能の追加よりも、Linuxが扱える接続形態を広げる内容として読むべきものだ。Wi-Fi側では、近くの端末やサービスをアクセスポイントなしで見つけるWi-Fi Awareの基盤が厚くなり、WiFi 8世代で使われるUHRの準備も進んだ。有線側では、RealtekのUSB EthernetドライバがRTL8159世代の10GbEアダプタを扱えるようになり、Intel E610向けにはEnergy Efficient Ethernetの制御が入った。
Phoronixは2026年6月19日、Linux 7.2のマージウィンドウでネットワークサブシステムの変更が取り込まれたと報じた。最終リリースの機能一覧ではなく、開発中kernelへ入ったネットワーク更新のまとまりである。無線LAN、USB Ethernet、PHY、古いプロトコルの削除が並ぶ幅広い更新だが、中身を追うと、Linuxのネットワーク層が「次世代規格への準備」と「現実に売られている周辺機器への対応」を同時に進めていることが分かる。
Wi-Fi Awareは近距離接続をLinuxの標準経路へ近づける
Wi-Fi Awareは、規格上はNeighbor Awareness Networking（NAN）として扱われる近距離検出の仕組みである。端末同士が同じルーターにぶら下がっていなくても、近くにあるサービスを見つけ、必要な相手と通信の準備を進められる。スマートホーム機器、ローカル共有、近距離ゲーム、産業機器の初期設定などでは、Bluetoothやクラウド経由の探索だけに頼らない経路を作れる。
Linux側の更新で目を引くのは、NANを「機能名」として置くだけではなく、ユーザー空間とドライバがやり取りするための細かい入口が広がっている点だ。nl80211.hには、NANの開始と停止、NAN functionの追加と削除、match通知、ローカルスケジュール、peerスケジュール、ULW更新、チャンネル退避、NAN data interface、capability報告といった項目が並ぶ。Wi-Fi Aware 4.0の表を参照するNAN channel entryやavailability blobも定義されており、単発の検出ではなく、時間窓やチャンネルを含めた運用へ踏み込んでいる。
この種の更新は、ユーザーがすぐに「Linux 7.2にすると近くの機器が何でも見つかる」と受け取るものではない。実際に使える体験には、対応チップ、ファームウェア、ドライバ、NetworkManagerやwpa_supplicantのようなユーザー空間側の実装が必要になる。それでもkernel APIが整う意味は大きい。各ベンダーやデスクトップ環境が同じ土台の上で機能を実装できるため、独自拡張だけに閉じた近距離接続から抜け出しやすくなる。
UHR対応はWiFi 7の土台の上に積み上がる
Linux 7.2の無線更新では、Ultra High Reliability（UHR）も前に出ている。UHRはIEEE 802.11bn、一般にはWiFi 8世代と結び付けて語られる要素で、Linuxのソース上でもUHR capability、UHR operation、UHR rate情報、UHR向けのelement IDが追加されている。Intel iwlwifiのfirmware APIにも、UHR対応を示す項目や、HE/EHT/UHRをまとめて扱うwifi_gen、UHR multi-link PMやDUOに関するlink flagが見える。
ここで押さえるべきなのは、Linux 7.2がWiFi 8対応を完成させたわけではないことだ。mac80211側には「UHRにはEHT対応が必要」という扱いがあり、WiFi 7世代のEHTを土台に、その先の規格要素を積み上げる形になっている。つまり今回の更新は、将来のWiFi 8製品をLinuxで扱うための名前、能力情報、操作情報、ドライバ側の受け口を増やす段階である。
この段階の変更は地味だが、無線ドライバでは後から一気に埋めるのが難しい。規格が見えてきた段階でkernel API、firmware API、rate情報、capability表現を前もって整えることで、実チップが出てきたときにドライバ固有の場当たり的な表現を減らせる。Linux 7.2のUHR対応は、将来の速度や遅延を約束する更新ではなく、次世代無線をLinuxの既存スタックで扱うための準備と見るのが自然である。
USB 10GbEは高価な拡張カードだけの領域ではなくなってきた
有線側で実用的な意味が大きいのは、Realtek R8152系ドライバの更新である。Phoronixは、R8152ドライバが10Gbit link speedとEnergy Efficient Ethernetをサポートし、Realtek RTL8159にも対応したと報じている。net-nextのr8152.cを見ると、RTL version 17に対して10G、5G、2.5Gのサポートフラグを立てる処理があり、rtl_nic/rtl8159-1.fwというファームウェア名も追加されている。リンク速度の広告にも10Gbpsが入るため、少なくともドライバはRTL8159世代を10GbE級のUSB Ethernetとして扱う準備に入っている。
これが効いてくるのは、10GbEがサーバー用NICやThunderboltドックだけの話ではなくなっているからだ。Phoronixは、RTL8159を使うUSB接続の10GbEアダプタが100ドル未満でも見つかると伝えている。Linuxでこうした製品を使う場合、ベンダー提供の外部ドライバや配布元ごとのパッチに依存すると、kernel更新のたびに使い勝手が揺れやすい。mainline側のドライバが対応すれば、ユーザーはより標準的な更新経路で高速な有線接続を使える。
Energy Efficient Ethernetの対応も、速度競争とは別の意味を持つ。EEEはアイドル時や対応リンクで消費電力を抑えるための仕組みであり、ノートPC、ミニPC、NAS、常時稼働の小型サーバーでは扱いが軽くない。R8152側には100M、1G、2.5G、5G、10GのEEE広告が見え、Intel ixgbeのE610向け実装にもEEEのget/set処理と対応リンクモードが追加されている。ただしE610側のコードには、対応速度やデバイス/NVM条件に関する制限もある。Linux 7.2の更新は、どの環境でも自動的に省電力化するものではなく、対応ハードウェアでOSが適切に制御できる範囲を広げる更新である。
無線チップと組み込み向けドライバも対応範囲を広げる
個別デバイスの対応も広い。MediaTek MT76系では、mt792x.hにMT7927向けのファームウェア名とROM patch名が追加されている。Realtek RTW89系では、RTL8922AやRTL8922Dのchip IDが見え、PhoronixはRTL8922AUの対応とRTL8922DEに向けた準備を挙げている。Qualcomm ath12kでは、thermal cooling deviceを登録し、最大/現在のthrottle stateを扱い、thermal mitigation commandを送る実装が入っている。
ath12kのthermal対応は、Wi-Fi 7世代の高性能チップを積む機器で特に意味がある。無線チップは小型筐体や組み込み機器の中で熱の影響を受けやすく、発熱時に通信品質や消費電力をどう制御するかが実運用に効く。Linuxのthermal frameworkに冷却デバイスとして見えるようになれば、温度情報とthrottle stateをOS側の管理に乗せやすくなる。
新規ドライバ群では、Alibaba Elastic Ethernet AdapterのKconfig項目が追加され、PHY側ではAiroha AN8801 Gigabit PHYがAN8801Rをサポートする形で入っている。Phoronixはこれに加えてNXP i.MX94 NETC switchも新規ドライバとして挙げている。こうした項目はデスクトップ利用者には目立ちにくいが、クラウド事業者、組み込みボード、ルーター、産業機器のLinux対応では重要になる。mainlineに入ることで、各社のBSPや独自kernelに閉じていたネットワーク機能が、長期的にはディストリビューションや上流kernelの保守対象に近づく。
古い接続方式の整理は、対応範囲を広げる更新の裏側にある
Linux 7.2のネットワーク更新は、追加だけではない。PhoronixはAppleTalk protocolの削除、TCP Offload EngineにおけるTLS offload対応の削除、cfg80211/mac80211からの5/10MHzサポート整理を挙げている。net-nextのツリー状態でも、net/appletalk配下は見つからず、AppleTalkが現役のネットワーク機能として残る段階は終わったと見てよい。
古いプロトコルや特殊なoffloadを落とす判断は、利用者から見れば後ろ向きにも見える。しかしネットワークスタックは、古い互換性を抱えたまま新しい無線規格、クラウドNIC、USB高速アダプタ、組み込みスイッチを受け入れ続けることが難しい。使われなくなった経路や保守負荷の高い機能を整理することで、テストやレビューの重心を現役の接続方式へ移しやすくなる。
今回の更新は、Linux 7.2がWiFi 8や10GbEを一気に完成させたという話ではない。Wi-Fi Awareの運用に必要なAPI、UHRのcapability表現、RTL8159世代のUSB Ethernet、E610のEEE、ath12kのthermal連携といった部品が、同じ周期でmainlineへ近づいていることに意味がある。次に焦点になるのは、各ハードウェアベンダーがどの機能を実機で有効にし、ユーザー空間のツールがそれをどれだけ自然に扱えるかである。