In D45011#1028836, @imp wrote:

The build is good, modulo one quibble.
The rest looks OK, but is really too large for me to review.

In D45011#1028825, @markj wrote:

Could you please add a manual page for the new drivers, or extend the existing share/man/man4/bnxt.4?

Thanks for the feedback! I'll create a new man page for the new RoCE drivers and submit it accordingly.

In D45009#1028830, @imp wrote:

ah, mechanically generated code.

In D45007#1028826, @imp wrote:

This looks straight forward enough that I'm happy ...

Thanks for the review! I will update the Makefile.

In D45005#1028822, @imp wrote:

The build stuff looks good.

Thank you. I am glad that the build changes are acceptable.

I can't speak to the hardware.

Thanks for the input! Regarding the hardware, I've tested the patch on relevant hardware and haven't encountered any issues. While I don't currently have documentation detailing the testing process, I can assure you that thorough testing has been conducted. If there's any specific information you need or if further testing is required on certain hardware configurations, please let me know, and I'll be happy to provide it

The extraneous (white space) changes are relatively low for vendor updates and don't get too much .

Thanks for your input! We'll address the whitespace in a separate cleanup patch after this patchset accepted.

In D44494#1014836, @imp wrote:

Change looks good, but you'll want to edit the 'subject' of the commit message to be < 70 characters

In D44422#1013860, @mav wrote:

I am not a big fan of kernel printing something in response to arbitrary user requests, it makes logs messy. Is the error reporting to user is not enough here?

If we keep the printfs, while device_printf() is better than just printf() used in other places (that is dirty), shouldn't we better use mpi3mr_dprint(), respecting configured driver debug level? I see there even special MPI3MR_DEBUG_IOCTL level for IOCTL's.

In D44426#1013880, @mav wrote:

I don't have any chip documentation to know what is right here, so just wonder if unconditional printing a bunch of raw hex numbers is expected here. It feels mpi3mr_print_fault_info() is another candidate for mpi3mr_dprint().

In D44423#1013705, @imp wrote:

Fine as it is if the same sort of redundancy is done elsewhere

In D44423#1013689, @sumit.saxena_broadcom.com wrote:

Need to adjust patch description a bit to keep code changes and description better aligned.

Hi Warner,