History log of /linux/drivers/net/pse-pd/realtek-pse-mcu-uart.c (Results 1 – 3 of 3)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 91ec2035 20-Aug-2026 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'net-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next

Pull networking updates from Jakub Kicinski:
"One of the 'small improvements all over the place' releases f

Merge tag 'net-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next

Pull networking updates from Jakub Kicinski:
"One of the 'small improvements all over the place' releases for us.

It's hard to draw any direct comparisons because summer vacations
disrupted our patch processing (and presumably - generation) quite a
bit.

Quick and dirty count suggests we (Paolo and I) merged a very similar
number of net (632) and net-next (648) patches. This is not telling
the full story either because 1/3 to 1/2 of the net-next patches also
*seem* like AI-driven low priority fixes, cleanups and clarifications.

We are completely overwhelmed, of course. The glimmer of hope is that
we secured sufficient LLM budget and access (thank you Meta!) to run
reviews with multiple frontier models on each patch. This eliminates
some hallucinations. That said, in terms of review, the LLMs can only
do so much.

The sad truth is that our APIs (especially for rare events like PCIe
errors, timeouts etc) have always been racy, and now LLMs don't let us
ignore that. I expect our direction for the next release will be to
tweak the reviews a little bit more, but start shifting focus to
letting the LLMs take care of the busy work - managing patchwork,
automating common process complaints, editing commit messages, and
maybe applying patches which already got "reviewed-by" tags from
people we trust...

Core & protocols:

- A few steps lowering rtnl_lock dependence:
- per-netns netdev unregistration for select SW drivers (e.g.
veth, ipvlan, tunnels)
- rtnl_lock-less FIB rule changes (RTM_NEWRULE and RTM_DELRULE)
- prepare software drivers and TC qdiscs for rtnl_lock-less GET

- Support BIG TCP (>64kB TSO) in UDP tunnels (vxlan, geneve)

- Support buffers larger than PAGE_SIZE in devmem zero-copy API

- Improve MPTCP handling of extreme memory pressure handling, when
out-of-order queue had to be pruned

- Report the per-group user count via RTM_GETMULTICAST

- Expose the route deletion reason in RTM_DELROUTE

- Add a SO_RIGHTS_NOTRUNC option to UNIX sockets to enable more
useful handling of LSM denials when receiving SCM_RIGHTS messages:
instead of truncating the message at the first blocked fd, keep
every fd slot and store the LSM errno in the blocked slot

- IPv6 Segment Routing - support looking up the post-encap SID
(address) in a different/specified routing table

- Support PRP RedBox (interlink) creation

- Support per-nexthop UDP dst port in VXLAN

- Continue converting getsockopt callbacks in a number of protocols
to iov_iter

Ethernet:

- Merge initial CXL support for AMD/Solarflare NICs (shared branch
with the CXL tree)

- New drivers:
- ADIN1140 10BASE-T1S MACPHY
- Initial skeleton of Intel iXD and ZTE Dinghai drivers

- High-speed NICs:
- AMD/Pensando:
- support firmware flashing
- Cisco (enic):
- SR-IOV V2 admin channel and MBOX protocol
- Huawei (hns3):
- support for ethtool pfc_prevention_tout
- nVidia/Mellanox:
- support sharing bandwidth control across interfaces
of the same device
- Marvell (octeontx2-pf):
- link RQ page pools to netdev for Netlink stats
- Google vNIC:
- XDP metadata support for DQ RDA
- Microsoft vNIC:
- support forcing full-page RX buffers

- Other NICs:
- Synopsys IP:
- eic7700: support for eth1
- Microchip (lan743x):
- support for RMII interface
- Wangxun:
- support for ethtool -G and -C for VFs
- add Tx timeout and PCIe error handling
- Intel (igb/igc):
- RSS key get/set support
- support for forcing link speed without auto-negotiation

- Switches:
- NXP (dpaa2):
- support bonding/LAG offload
- Mediatek:
- mt7530: EN7528 support
- initial support for MT7628
- Micrel (ksz8/9):
- refactoring work to move towards library model
- PTP support for KSZ8463
- nVidia/Mellanox:
- support rtnl-lock-less ethtool callbacks
- Realtek:
- rtl8366rb: use generic RTL83xx code
- support SGMII and HSGMII for RTL8367S

- PHYs:
- Airoha:
- EcoNet EN7528 PHY support
- DAPU Telecom
- DAPU Telecom DAP8211R(I) Gigabit PHY support
- Realtek:
- support RTL8261C_CG
- support RTL8261D

Wireless:

- nl80211: per-link statistics support for multi-link operation

- mac80211: AQL/airtime-fairness support for multicast

- Merge Peripheral Authentication Service (PAS) / TEE support for
ath12k (shared branch with the firmware/qcom tree)

- New drivers:
- mm81x for Morse Micro Long-Range S1G devices
- nxpwifi for NXP devices (mostly forked off from mwifiex)

- Driver changes:
- Broadcom (brcmfmac):
- DPP support, some Cypress part update
- MediaTek (mt76):
- mt7928 support
- mt7925 NAN support
- mt7996 AP powersave improvements
- Qualcomm (ath12k):
- much kernel infrastructure integration work
- AHB platform MultiPD support
- Realtek (rt89):
- LED support
- RTL8922DE support
- dual-BT coex for RTL8922D
- Intel:
- new FW version support

Bluetooth:

- HCI: add support for Shorter Connection Interval (SCI) feature

- af_bluetooth: add minimal context analysis annotations

- Driver changes:
- Intel:
- add Bluetooth SAR revision 2 support
- add vendor_reset PCI sysfs for PLDR
- Mediatek:
- add USB IDs for MT7902 and MT7922 devices
- Realtek:
- add USB IDs for 8761CU and 8852BE devices
- NXP:
- add M.2 Bluetooth device support using pwrseq

Misc:

- DPLL support for manual/numerical oscillator control (NCO)
(implement in zl3073x)

- MCTP support for MCTP over USB v1.1 (DMTF DSP0283)

- Power-over-Ethernet: support Realtek PSE controllers

- Remove the IBM EHEA driver

- Remove tulip/xircom_cb driver"

* tag 'net-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1433 commits)
net/mlx5e: do not HW-GRO coalesce small frames
net: openvswitch: fix nf_connlabels leak in ovs_ct_init
net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs()
net: openvswitch: fix flow mask use-after-free on flow deletion
sctp: stop processing a packet once its association is deleted
dpll: zl3073x: add PTP clock support
dpll: zl3073x: add channel ToD, phase step and TIE operations
dpll: zl3073x: scale poll interval proportionally to timeout
ptp: vmclock: prevent read-only mappings from becoming writable
ipv4: reject undersized MTUs in ip_do_fragment()
bonding: initialize err for empty target lists
net: dsa: initial support for MT7628 embedded switch
net: dsa: initial MT7628 tagging driver
net: phy: mediatek: add phy driver for MT7628 built-in Fast Ethernet PHYs
dt-bindings: net: dsa: add MT7628 ESW
net: pse-pd: realtek-pse-mcu: add UART transport
net: pse-pd: realtek-pse-mcu: add I2C transport
net: pse-pd: add Realtek PSE MCU core
dt-bindings: net: pse-pd: add bindings for Realtek PSE MCU
vsock: use sock_error() to consume sk_err after a failed connect
...

show more ...


# 194e4ffd 18-Aug-2026 Paolo Abeni <pabeni@redhat.com>

Merge branch 'net-pse-pd-add-realtek-pse-mcu-support'

Jonas Jelonek says:

====================
net: pse-pd: add Realtek PSE MCU support

This series adds a PSE-PD driver for the microcontroller (MC

Merge branch 'net-pse-pd-add-realtek-pse-mcu-support'

Jonas Jelonek says:

====================
net: pse-pd: add Realtek PSE MCU support

This series adds a PSE-PD driver for the microcontroller (MCU) that
fronts the PSE silicon on a range of managed switches, together with its
DT binding.

Hardware model
==============

These boards do not expose the PSE chips to the host directly. A small
microcontroller sits on an I2C/SMBus or UART bus and manages one or more
PSE chips behind it; the host CPU only ever talks to that MCU, using a
fixed 12-byte request/response protocol with a trailing checksum. The
PSE silicon never appears on the bus.

Two generations of the protocol exist, both Realtek's: an older one on
boards with Broadcom PSE silicon (BCM59111, BCM59121) and a newer one
used with Realtek's own PSE silicon (RTL8238B, RTL8239, RTL8239C). They
diverge in opcode numbering and a few response layouts; the driver
abstracts that behind a per-dialect opcode table and parser hooks,
selected by the compatible. The specific PSE chip behind the MCU is
detected at runtime and only influences per-chip constants (power scaling
and the per-port cap).

The compatibles
===============

The protocol compatibles name two generations of the Realtek protocol,
with the I2C framing folded in:

realtek,pse-mcu-gen1 gen1, UART
realtek,pse-mcu-gen1-smbus gen1, I2C/SMBus
realtek,pse-mcu-gen2 gen2, UART
realtek,pse-mcu-gen2-smbus gen2, I2C/SMBus
realtek,pse-mcu-gen2-i2c gen2, raw I2C

and each board carries a device-specific compatible that falls back to one
of these, e.g.

compatible = "zyxel,xs1930-12hp-pse", "realtek,pse-mcu-gen2-smbus";

The naming is the part most likely to raise questions, so the reasoning up
front (the binding documents it too):

- The node describes the MCU together with its Realtek firmware, not a
PSE chip and not the microcontroller silicon. The PSE chips sit behind
the MCU, never appear on the bus, and are reported by the MCU and
detected at runtime; the microcontroller itself is a general-purpose
part (GigaDevice, Nuvoton, ...) that varies across boards. What is
fixed and Realtek's is the firmware and its host protocol - hence the
'realtek' prefix.

- gen1 and gen2 are two generations of that protocol, both Realtek's:
gen1 on older boards fronting Broadcom PSE silicon, gen2 the altered
protocol used once Realtek shipped their own PSE silicon. The
generation is fixed per board and is all the driver needs at DT-parse
time, so the compatible encodes it.

- On I2C the MCU firmware expects one of two framings - SMBus or raw
I2C - which is a genuine programming-model difference, so it is part
of the compatible ('-smbus' / '-i2c'). A UART attachment carries no
framing suffix; the transport is given structurally by the parent
'serial' node.

- Each board additionally carries a device-specific compatible that
falls back to the protocol one. The driver only ever binds on the
protocol compatible; the device-specific string keeps the binding
specific and reserves a place for a future per-board quirk without
having to retrofit device trees already deployed in the field.

Testing
=======

- Linksys LGS328MPCv2 (RTL8238B, I2C)
- Zyxel GS1900-10HP A1 (BCM59121, UART)
- Zyxel GS1900-10HP B1 (RTL8238B, UART)
- Zyxel GS1920-24HPv2 (BCM59121, SMBus)
- Zyxel XMG1915-10EP (RTL8239C, UART)
- Zyxel XS1930-12HP (RTL8239, SMBus)
====================

Link: https://patch.msgid.link/20260813222036.873930-1-jelonek.jonas@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

show more ...


Revision tags: v7.2
# 5cc93d98 14-Aug-2026 Jonas Jelonek <jelonek.jonas@gmail.com>

net: pse-pd: realtek-pse-mcu: add UART transport

Add the serdev (UART) transport for the Realtek PSE MCU core. It registers
the MCU as a serdev device and provides the send/recv callbacks the core
u

net: pse-pd: realtek-pse-mcu: add UART transport

Add the serdev (UART) transport for the Realtek PSE MCU core. It registers
the MCU as a serdev device and provides the send/recv callbacks the core
uses to exchange the 12-byte frames, receiving asynchronously via the
serdev receive_buf callback.

The baud rate defaults to 19200 and can be overridden per board with the
"current-speed" property.

Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Link: https://patch.msgid.link/20260813222036.873930-5-jelonek.jonas@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

show more ...