Am 12.11.18 um 19:29 schrieb rgrimes:

rgrimes added a comment.

In D17935#383667 <https://reviews.freebsd.org/D17935#383667>, @imp wrote:
> I'd do a separate commit that just says 'CTM will move to ports in
> FreeBSD 13' in the ctm man page and get that merged before 12.0R (so
> ASAP).
Please do both the man page, and actually more importantly make the binary
spit out a warning that it is going away in 13, this to be merged to
stable/12 asap.  Man pages simply do not get peoples attention.  Also make
sure to mark this commits as relnotes: y.
Since I am involved now I can not approve it as re@, but it should see no
resistance.

In D17935#383667, @imp wrote:

I'd do a separate commit that just says 'CTM will move to ports in FreeBSD 13' in the ctm man page and get that merged before 12.0R (so ASAP).

Looks good to me. I'd do a separate commit that just says 'CTM will move to ports in FreeBSD 13' in the ctm man page and get that merged before 12.0R (so ASAP).
I agree with Rob we should have an updating entry, and a line in the release notes (relnotes: yes should do that).
I don't think we need to do anything more other than commit this review after a few month (there's no rush, and safely after the turbulence 12.0R is mildly better), but I'll give that feedback and leave the timing to your discretion.

OK from manpages.

There should be an UPDATING entry to tell people to go get the port.. This has a 0 length deprecation notice if we just go rip it out now. I would support first adding a gonein(13) and merging that to release 12 or 12.1. That should be done first, before this. Have the ports builders made a pkg avaliable for ^/head yet, I see that you can build it, but can pkg get one yet? I would not want to remove it until a binary can be fetched via pkg.

Fixed a bug in the SRCTOP variable, for some reason it was .SRCTOP with a preceding period character.

Please stop adding redundant prototypes for the same function — it breaks the GCC build. The tagged lines below are not exhaustive.

I have no objections.

Incorporated the changes according to review comments.

Hi all,
Has anyone had a chance to review this?

On a quick look I spotted number of style issues you may fix.

Hi all, any views done on this? Its been a little less than a month :)

Hey @s3erios_gmail.com, have you had a chance to poke at this again?

The previous commit was a diff from the previous diff.
That was a mistake, I am still getting used to the tooling.
This is a diff from HEAD.

Attached Tx methods from rtl8192ce

Attached Tx methods from rtl8192ce

Can you attach next patches with context (like it is described in https://wiki.freebsd.org/action/show/Phabricator?action=show&redirect=CodeReview )

I retrieved the rtl8188efw.bin firmware from here: https://github.com/lwfinger/rtlwifi_new/tree/master/firmware/rtlwifi
I uuencoded it with the following command:
uuencode rtl8188efw.bin rtwn-rtl8188eefw.fw.uu > rtwn-rtl8188eefw.fw.uu

For the record, his patch first appeared in PR 217560, it's unrelated to the Bug, so I asked for an independent CR.
I will take care of it.

Approved.
Hoping someone else can do the honors though .. I did somethig dumb with my partition table.

I have a cardbus 3G modem which I can try it with. If only I could find it. :)

Apart from the one minor issue I do not see problems (which does not mean there aren't any).

Abandoning in favor of D5471

I've thought about having a RF_WC for WC mappings as well, but I'd really rather finish bus_map_resource() and use that for handling non-default memory attributes instead.