In D50543#1173544, @ziaee wrote:

I just pushed the fix in 77757c54895081dd9cbce

Looks good to me, thanks.

In D46290#1160963, @tomek_cedro.info wrote:

Yup, I provided information "before", now the information "after" and all seems to work fine, the problem is gone, I can flash devkits with CH343 chip, baudrate change seems to work correctly BIG THANK YOU :-)

One note detailed at the bottom - RESET/RTS works, BOOT/DTR does not seem to work.

Fix DTR/RTS status.

In D46290#1159034, @tomek_cedro.info wrote:

Hello world :-)

I have some CH343 CH341 and probably some others / can get others.. how can I help testing? What are test steps to perform? :-)

So far I was able to work with CH343 currently on 14.2-RELEASE AMD64 but only in basic slow UART mode, control lines fail and some transfers fail (i.e. I have one in some ESP32-S3 devkit that I cannot program with esptool) so its unreliable.

FreeBSD hexagon 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC amd64

ugen1.8: <vendor 0x1a86 USB Single Serial> at usbus1
umodem0 on uhub8
umodem0: <vendor 0x1a86 USB Single Serial, class 2/0, rev 1.10/4.43, addr 7> on usbus1
umodem0: data interface 1, has no CM over data, has no break

In D46290#1149111, @ziaee wrote:

The hardware section is used to generate the supported hardware page in the release notes. Removing the hardware section would create a dead link there. It does need to be fixed though, I can fix it in another commit if you want.

The revised patch increases the buffer size from 4 to 16 bytes, this will avoid overrunning the buffer.

Add support for line modes other than 8-bit/no-parity/1-stop on
CH340/CH341 chips.

In D46290#1055959, @lwhsu wrote:

The only thing I would comment is don't forget to update the .Dd field in manual page. :)

Bump a date in .Dd field in man page.

In D45088#1055876, @concussious.bugzilla_runbox.com wrote:

Sorry I'm late. I am extremely interested in consistency across the freebsd manual and will definitely test every manual review tagging @manpages, but I don't understand how to find them when that is omitted. Thanks!

https://github.com/freebsd/freebsd-src/pull/1384

Remove unused sc_data_iface_no

In D45088#1028349, @lwhsu wrote:

Only mention 8156/8156B in 2500baseT

I haven't had time to look at the code, but tested on my Xiaomi mini USB WiFi:

Looks good to me. Tested:

Add a new RDC phy.

Looks good to me. Could you provide a full dmesg? Thanks.

In D27782#621560, @imp wrote:

In D27782#621556, @kevlo wrote:

In D27782#621399, @imp wrote:

Also, boot1.efi is obsolete. We retain it only for special needs users: those with the bogus tiny ESP partitions and some really weird edge cases that loader.efi doesn't work for.

I have Ubuntu 20.10 and FreeBSD -current installed on my thinkpad laptop.
Linux's Grub2 is unable to boot FreeBSD directly from UEFI, I have to copy
the FreeBSD UEFI loader (/boot/boot.efi) into EFI partition.

You should copy loader.efi instead of boot1.efi since boot1 use is deprecated is what I meant. We should teach grub about UFS and maybe ZFS...

In D27782#621399, @imp wrote:

Also, boot1.efi is obsolete. We retain it only for special needs users: those with the bogus tiny ESP partitions and some really weird edge cases that loader.efi doesn't work for.

Thanks for the detailed analysis.

Tested with a damaged FAT file system, seems to be working fine.