On Thu, Mar 31, 2022 at 08:07:02PM +0200, Stefan Sperling wrote:
> 
> On Thu, Mar 31, 2022 at 09:41:09PM +0800, Kevin Lo wrote:
> > This diff adds preliminary support for RTL8156B to ure(4) and
> > bug fixes for RTL8153/RTL8156.
> > 
> > Tested:
> > ure0 at uhub0 port 12 configuration 1 interface 0 "Realtek USB 
> > 10/100/1G/2.5G LAN" rev 3.20/31.00 addr 3
> > ure0: RTL8156B (0x7410), address 00:e0:4c:xx:xx:xx
> 
> Works for me. ok stsp@, with one question about the diff below:

Thanks for testing!

> > Index: sys/dev/usb/if_ure.c
> > ===================================================================
> > RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
> > retrieving revision 1.28
> > diff -u -p -u -p -r1.28 if_ure.c
> > --- sys/dev/usb/if_ure.c    20 Aug 2021 04:54:10 -0000      1.28
> > +++ sys/dev/usb/if_ure.c    31 Mar 2022 08:35:04 -0000
> > @@ -197,7 +197,8 @@ void            ure_rtl8153_init(struct ure_softc 
> >  void               ure_rtl8153b_init(struct ure_softc *);
> >  void               ure_rtl8152_nic_reset(struct ure_softc *);
> >  void               ure_rtl8153_nic_reset(struct ure_softc *);
> > -void               ure_rtl8153_phy_status(struct ure_softc *, int);
> > +uint16_t   ure_rtl8153_phy_status(struct ure_softc *, int);
> 
> The function ure_rtl8153_phy_status() now returns a value,
> but no caller is checking this value. Is this intentional?

Yes, it's intentional.  Vendor's Linux driver needs microcode patches
for nearly every chipsets and PHYs, it accesses/programs large set of 
registers unknown to ure(4).  Currently ure(4) heavily relies on power
on default settings, I plan to add microcode patches although it contains 
many magic numbers.

> Tested with xhci(4) and:
> 
> ure0 at uhub2 port 1 configuration 1 interface 0 "Lenovo Thinkpad USB LAN" 
> rev 3.00/30.00 addr 6
> ure0: RTL8153 (0x5c20), address 3c:18:a0:a0:95:2b
> rgephy0 at ure0 phy 0: RTL8251 PHY, rev. 0
> 
> This chip still works fine:
> 
> Conn:   1 Mbps:       91.315 Peak Mbps:       92.233 Avg Mbps:       91.315
>        27086       10557368       84.459  100.00%
> Conn:   1 Mbps:       84.459 Peak Mbps:       92.233 Avg Mbps:       84.459
>        28089        9950656       79.367  100.00%
> Conn:   1 Mbps:       79.367 Peak Mbps:       92.233 Avg Mbps:       79.367
>        29091        9335256       74.607  100.00%
> Conn:   1 Mbps:       74.607 Peak Mbps:       92.233 Avg Mbps:       74.607
>        30091       10476280       83.810  100.00%
> Conn:   1 Mbps:       83.810 Peak Mbps:       92.233 Avg Mbps:       83.810
>        31094        9746488       77.739  100.00%
> Conn:   1 Mbps:       77.739 Peak Mbps:       92.233 Avg Mbps:       77.739
>        32095        9582864       76.663  100.00%
> Conn:   1 Mbps:       76.663 Peak Mbps:       92.233 Avg Mbps:       76.663
>        33098       10091112       80.487  100.00%
> Conn:   1 Mbps:       80.487 Peak Mbps:       92.233 Avg Mbps:       80.487
>        34101        8650352       68.996  100.00%
> Conn:   1 Mbps:       68.996 Peak Mbps:       92.233 Avg Mbps:       68.996
>        35106        9438064       75.204  100.00%
> Conn:   1 Mbps:       75.204 Peak Mbps:       92.233 Avg Mbps:       75.204
> ^C
> --- 192.168.1.1 tcpbench statistics ---
> 350301608 bytes sent over 35.602 seconds
> bandwidth min/avg/max/std-dev = 26.875/78.824/92.233/11.918 Mbps

Reply via email to