On Wed, Jan 18, 2023 at 06:54:56PM +0100, Stefan Wahren wrote: > Hi Umang, > > [add Phil] > > Am 18.01.23 um 12:58 schrieb Umang Jain: > > Drop custom logging from the vchiq interface. > > Mostly of them are replaced with dev_dbg and friends > > and/or pr_info and friends. > > > > The debugfs log levels (in 4/4) are mapped to kernel > > logs levels (coming from include/linux/kern_levels.h) > > Would like some thoughts on it as I am not sure (hence > > marking this is RFC) > > > > From drivers/staging/vc04_services/interface/TODO: > > > > """ > > * Cleanup logging mechanism > > > > The driver should probably be using the standard kernel logging mechanisms > > such as dev_info, dev_dbg, and friends. > > i don't have any experience with vchiq logging/debug. So i'm not sure if > it's acceptable to lose the second log level dimension (like > vchiq_arm_log_level) completely. Complex drivers like brcmfmac have a debug > mask to avoid log spamming [1]. Maybe this is a compromise. > > Btw some loglevel locations has already been messed up during refactoring > :-( > > [1] - drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h > Kernel logging is actually has a bunch of features. You can turn them on for just a module or function or enable a specific message. See Documentation/admin-guide/dynamic-debug-howto.rst for more info. This vchiq logging is a re-implementation of a subset of the features that normal kernel logging infrastructure provides. Moving to normal logging will make it cleaner but also more flexible and powerful. It's better in every way. The broadcom stuff is different and more complicated than what this module is trying to do. They are sorting out their logging according to various components. I understand the motivation, but they would probably have been better just use standard logging like everyone else. regards, dan carpenter
