In D28167#629541, @kevans wrote:

In D28167#629540, @kib wrote:

In D28167#629468, @kevans wrote:

I should revise the message to mention this, but this is accounted for in the form of what we'd typically call a port revision:

root@viper:/usr/src# make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 _BRANCH=RELEASE -V PKG_VERSION
13.0
root@viper:/usr/src# make -f Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 _BRANCH=RELEASE-p1 -V PKG_VERSION
13.0_1
root@viper:/usr/src# pkg version -t 13.0 13.0_1
<

This is not how ports collection typically works, from my (user) perspective. _N only means some change to the package itself, and not to the software that was packaged. Glen' suggestion is more aligned and allows to clearly see that there was a patch on RELEASE branch vs. some (minor) fix to some packaging issue.

It could mean both if we end up backporting a fix or optimization that's worth importing without hopping forward to the version it's backported from -- that said, I have no objection to making this 13.0p1 instead to more closely match SA/EN literature since 13.0 < 13.0p1 < 13.1 still holds true, and it's still clear what it means.

TBH this is to big for me to review, if you could split the review based on the commits (as I hope you didn't commit this whole thing in one commit) that would be easier to review.

In D27414#629460, @bz wrote:

@manu, did we come to the conclusion last year that currently doing this all natively was not always working and we are going with this one as the next (first) step? I'd love to commit this as soon as firmware(9) changes are in and D26598 is updated and accepted, so that we don't have to update DRM ports too often.

Push with a rebase and a few modif (PRERELEASE didn't worked).

Yeah I remember now.
RSB isn't really i2c and we can't use those (I was sure that I tested at some point).
using this code will boot but will fail as soon as we try to change the cpu freq (when we try to talk to the PMIC)
root@pine64-lts:~ # sysctl dev.cpu.0.freq=1152
dev.cpu.0.freq: iichb0: RTA not known for address 0x23
axp8xx_pmu0: Setting vdd-cpux (dcdc2) to 1300000<->1300000
<hang here>
Since we cannot communicate with the PMIC we will hang as soon as the CPU reaches the desired freq and not have the correct needed voltage.

Not tested but LGTM

Mhm, I don't remember if there was a reason I didn't do that or if iicdev_read/write didn't exists at the time.
Looks ok but give me a few days to test.

Thanks, will comit this today.

Works for me.

In D27960#625278, @hselasky wrote:

@kib We have a special flag for the DRM case. See pdrv->isdrm .

I would have prefered the first solution that you posted TBH but ok.

In D27709#624257, @emaste wrote:

My general preference is that we don't go too far down the path of a huge number of small packages, but even so I think zoneinfo makes sense to be in a separate package since it will be updated relatively frequently.

In D27711#624261, @emaste wrote:

OK, although IMO we could just put ppp and natd in the same package - I just don't know what we should name it then.

In D27550#624206, @hselasky wrote:

I'm good with the changes, but please wait for Konstantin to accept it too. He is the PCI expert.

@kib @hselasky is the code ok for you now ?
I think I've address everything ARI related.

In D26853#623275, @manu wrote:

In D26853#623262, @maciphone2_googlemail.com wrote:

reclaimed and reopened since, as far as I know and according to the mailing list , this issue isn't yet solved.
if I'm wrong, you can just close it again :-)

Still wrong since this dtb isn't used for the images.
Also mail on the ML seems to indicate a u-boot problem and u-boot will never use this DTB.

In D26853#623262, @maciphone2_googlemail.com wrote:

reclaimed and reopened since, as far as I know and according to the mailing list , this issue isn't yet solved.
if I'm wrong, you can just close it again :-)