On Tue, Mar 30, 2021 at 2:17 AM Grant Grundler <grund...@chromium.org> wrote:
>
> This series introduces support for USB network devices that report
> speed as a part of their protocol, not emulating an MII to be accessed
> over MDIO.
>
> v2: rebased on recent upstream changes
> v3: incorporated hints on naming and comments
> v4: fix misplaced hunks; reword some commit messages;
>     add same change for cdc_ether


FTR I've reposted V4 with Andrew Lunn's Reviewed-by line and added
net-next to the subject line.
It will show up as a different thread and hopefully the automation can
pick this up now. :)

cheers,
grant

>
> I'm reposting Oliver Neukum's <oneu...@suse.com> patch series with
> fix ups for "misplaced hunks" (landed in the wrong patches).
> Please fixup the "author" if "git am" fails to attribute the
> patches 1-3 (of 4) to Oliver.
>
> I've tested v4 series with "5.12-rc3+" kernel on Intel NUC6i5SYB
> and + Sabrent NT-S25G. Google Pixelbook Go (chromeos-4.4 kernel)
> + Alpha Network AUE2500C were connected directly to the NT-S25G
> to get 2.5Gbps link rate:
> # ethtool enx002427880815
> Settings for enx002427880815:
>         Supported ports: [  ]
>         Supported link modes:   Not reported
>         Supported pause frame use: No
>         Supports auto-negotiation: No
>         Supported FEC modes: Not reported
>         Advertised link modes:  Not reported
>         Advertised pause frame use: No
>         Advertised auto-negotiation: No
>         Advertised FEC modes: Not reported
>         Speed: 2500Mb/s
>         Duplex: Half
>         Auto-negotiation: off
>         Port: Twisted Pair
>         PHYAD: 0
>         Transceiver: internal
>         MDI-X: Unknown
>         Current message level: 0x00000007 (7)
>                                drv probe link
>         Link detected: yes
>
>
> "Duplex" is a lie since we get no information about it.
>
> I expect "Auto-Negotiation" is always true for cdc_ncm and
> cdc_ether devices and perhaps someone knows offhand how
> to have ethtool report "true" instead.
>
> But this is good step in the right direction.
>
> base-commit: 1c273e10bc0cc7efb933e0ca10e260cdfc9f0b8c

Reply via email to