Page MenuHomeFreeBSD

mpi3mr: Add controller state check before enabling PEL
ClosedPublic

Authored by chandrakanth.patil_broadcom.com on Mar 19 2024, 11:29 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Jul 1, 11:19 PM
Unknown Object (File)
Sun, Jun 30, 7:38 AM
Unknown Object (File)
Thu, Jun 27, 2:25 AM
Unknown Object (File)
Wed, Jun 26, 10:43 PM
Unknown Object (File)
Mon, Jun 24, 12:05 PM
Unknown Object (File)
Mon, Jun 24, 11:55 AM
Unknown Object (File)
Mon, Jun 24, 3:51 AM
Unknown Object (File)
Mon, Jun 24, 3:11 AM
Subscribers
None

Details

Summary

Added controller state check before issuing the PEL enable to
firmware for sanitization.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Mar 21 2024, 7:59 AM

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 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.

ok. I will move those prints under debug flag and will be taken care in the cleanup patch.