Forgot to uncomment a line, we need the stage-package dep.

Use pkg query '%X' to have the internal package checksum, any changes to a package except the version will produce a different hash.

In D26460#588728, @zeising wrote:

Mabye put a NOT_FOR_ARCHS=sparc64 and NOT_FOR_ARCHS_REASON=not supported or something in mesa-dri/Makefile.common. Just in case someone is brave enough to try building this on sparc64.

libepoxy is ok.
Why did you though there could be a problem ?

In D25793#588526, @rajesh1.kumar_amd.com wrote:

It's a logging mistake @manu. I will correct it accordingly. Each nibble in that value denotes a port status. When you say you are touching only ax0, I see the correct nibble reflecting the change (bits[15:12]). From the values you showed here, looks like your SFP module is detected, but Link is still not. Is the link connected?

Add support for GETINFO and free backlight data.

Add GETINFO support.

Add support for -i to query backlight info.

Add GETINFO ioctl to get the backlight name and type.

So I feel a bit dumb but I now know why I it didn't worked.
Naming of interfaces is of course not the same on the panel but what made me confuse is if I remove/insert the module in the slot that correspond to ax0 I have :
ax3: xgbe_phy_sfp_signals: sfp_gpio_inputs: 0x7220
ax3: xgbe_phy_sfp_signals: sfp_gpio_inputs: 0x2220
Which lead me to think that I was using the right interface.
So TLDR inserting/removing a module in any of the 4 slot always prints info for ax3.
Do you have any idea what's going on ?

Log with debug_level=3 : https://reviews.freebsd.org/P423

address @tcberner's comments.

In D25793#586930, @rajesh1.kumar_amd.com wrote:

Fine @manu .

I only have finisar ftlx8574d3bcl for now, do you have a known model that is supposed to work ?
Also can you make the printf not in a loop ?

We have tested with Finisar 10G SFP-to-Optical modules (not RJ45). Other than that, we have tested with 10G FS, Prolabs and 10GTek (all SFP-to-RJ45). I will make the change to print that log only once and other changes I mentioned before and submit a new patch tomorrow.

In D25793#586908, @rajesh1.kumar_amd.com wrote:

Hi @manu, Thanks for trying the patch and making other necessary changes. Sorry, I missed to make that change MPASS (nrxqs == 2) when I submitted the v4 patch.

Regarding the log

'ax0: xgbe_phy_reset: no phydev'

This is normal before the interface is brought up. Not an issue. This log may be confusing. I will change that to verbose level log in the future patches.

I've just tested on my machine, an IEI Puzzle. (Sorry it took so long).
I needed this to have the driver compiled and loading : https://reviews.freebsd.org/P422

Address @zeising's comments.

In D26367#586352, @zeising wrote:

In D26367#586347, @manu wrote:

In D26367#586341, @zeising wrote:

One small nit above, nothing important.

As a side note, I wonder if we really should keep the SOURCE option enabled, it has caused issues in the past when people first do a buildkernel (with the old sources) and then update ports and think they have the new stuff, while still loading the old module built with buildkernel.

Well, installing the source will always causes problems when you update ports/package after building kernel but can help (sometimes) if nothing in base breaks building the module but it needs to be recompiled. It's the best solution that we have right now.

We've had several support cases where there's been confusion as to which module was loaded because of this. But this discussion is bigger than this review, and not something that should prevent the update from happening. :)

In D26367#586345, @zeising wrote:

One more thing, can you update the version check in graphics/drm-kmod/Makefile as well?

In D26367#586341, @zeising wrote:

One small nit above, nothing important.

As a side note, I wonder if we really should keep the SOURCE option enabled, it has caused issues in the past when people first do a buildkernel (with the old sources) and then update ports and think they have the new stuff, while still loading the old module built with buildkernel.

Thanks !
My investigation of this problem 1 year ago lead me to think it was relocation related but I'm clueless on how that work.
I'll try to test that asap (especially arm where I don't think we had a problem).

LGTM

LGTM

I'll update this review so we use pkg query '%X' from pkg 1.15 to get the internal checksum of the package and check if we need to update it.

In D26338#585512, @lwhsu wrote:

BTW, why is the name of riscv32-unknown-elf-gcc different from others?

arm-none-eabi-gcc is missing

ping ?

No this is the right place for _if.h files.

Add backlight_if.h to LINUXKPI_GENSRC variable.

Add backlight.9 here.

Don't add the man9 page here

Address @hselasky's comments.

Ah, didn't knew that, thanks for finding this.

Mhm I was sure that the read was needed and I think it was H3 that I tested that with, but since you have H3 I guess I was wrong.

Thanks, I had no time to fix this.
abs is used on more clock drivers for allwinner so I think that adding the inline function to aw_clk.h would be better.

Thanks a lot.

In D26277#584197, @bz wrote:

In D26277#584196, @manu wrote:

In D26277#584194, @bz wrote:

In D26277#584193, @manu wrote:

In D26277#584190, @bz wrote:

In D26277#584185, @bz wrote:

In D26277#584141, @manu wrote:

Note that this commit, once approved, should be synced with ports update to drm-current-kmod and drm-devel-kmod.

I'll do the due-diligens based on the URL you gave me earlier to see what else we have as common code; which of the branches there do I need to check?

Then we can put it all up (either yours or mine) in here for review, cross-check that all still works and get it into FreeBSD in one go, which should make checking in ports for available functionality in base a lot easier. In other words, I'll not push this into head alone if there's other stuff.

Question: given the linux_firmware.c file there has no author or license on it, do I have to assume the files there are indeed as the directory tree suggests gplv2? Because if they are I don't want to go near their contents.

No, if you look at the history it was imported by markj from drm-next, mmacy is the author I think

Cool. Which branches should I all check or is the linuxkpi basically identical?

The firmware part is identical everywhere (even at https://github.com/FreeBSDDesktop/kms-drm)

And the rest of all the linuxkpi changes. I have a ton sitting here locally. Hence my question, which branches to all check in your trees.

In D26277#584194, @bz wrote:

In D26277#584193, @manu wrote:

In D26277#584190, @bz wrote:

In D26277#584185, @bz wrote:

In D26277#584141, @manu wrote:

Note that this commit, once approved, should be synced with ports update to drm-current-kmod and drm-devel-kmod.

I'll do the due-diligens based on the URL you gave me earlier to see what else we have as common code; which of the branches there do I need to check?

Then we can put it all up (either yours or mine) in here for review, cross-check that all still works and get it into FreeBSD in one go, which should make checking in ports for available functionality in base a lot easier. In other words, I'll not push this into head alone if there's other stuff.

Question: given the linux_firmware.c file there has no author or license on it, do I have to assume the files there are indeed as the directory tree suggests gplv2? Because if they are I don't want to go near their contents.

No, if you look at the history it was imported by markj from drm-next, mmacy is the author I think

Cool. Which branches should I all check or is the linuxkpi basically identical?

In D26277#584190, @bz wrote:

In D26277#584185, @bz wrote:

In D26277#584141, @manu wrote:

Note that this commit, once approved, should be synced with ports update to drm-current-kmod and drm-devel-kmod.

I'll do the due-diligens based on the URL you gave me earlier to see what else we have as common code; which of the branches there do I need to check?

Then we can put it all up (either yours or mine) in here for review, cross-check that all still works and get it into FreeBSD in one go, which should make checking in ports for available functionality in base a lot easier. In other words, I'll not push this into head alone if there's other stuff.

Question: given the linux_firmware.c file there has no author or license on it, do I have to assume the files there are indeed as the directory tree suggests gplv2? Because if they are I don't want to go near their contents.

Note that this commit, once approved, should be synced with ports update to drm-current-kmod and drm-devel-kmod.

In D26274#584056, @mmel wrote:

imho, also drm2 option should be moved to options.arm. otherwise, NOTES kernels may fail. I'm OK with rest

LGTM.
Note that it would be better to direct commit to 12, no need to first commit to 13.
This will be, anyway, removed by D26274

In D26153#583898, @ar_semihalf.com wrote:

In D26153#583890, @kibab wrote:

Regarding the partitions: it would be interesting to see the output of ls /dev/sdda* on MMCCAM kernel, probably the partitions got detected but not printed on boot.

With GENERIC-MMCCAM, my kernel failed to mount a rootfs located on an unrelated usb drive (perhaps this hints towards a bigger issue?), so I wasn't able to properly inspect the mmc partitions from userspace. I did however list all available drives via mountroot and there were no partitions listed for sdda0.