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)
Dec 11 2024, 10:46 PM
Unknown Object (File)
Dec 1 2024, 6:48 AM
Unknown Object (File)
Nov 25 2024, 7:27 PM
Unknown Object (File)
Nov 25 2024, 7:33 AM
Unknown Object (File)
Nov 24 2024, 3:16 AM
Unknown Object (File)
Nov 23 2024, 4:40 PM
Unknown Object (File)
Nov 21 2024, 1:49 PM
Unknown Object (File)
Nov 19 2024, 11:32 PM
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.