On Fri, Aug 12, 2011 at 12:06:55PM -0700, Bernie Thompson wrote: > On Fri, Aug 12, 2011 at 8:56 AM, Greg KH <gregkh@xxxxxxx> wrote: > > You can do the same for your calls to pr_debug() and other pr_* calls. > If you note in the header file for those functions, it suggests that > drivers should always call the dev_* versions instead of teh "raw" pr_* > functions, as you do have access to a struct device within your driver. > > > A little background from udlfb: we weren't able to stick with dev_* calls 100%, > because udlfb needed to survive USB device removal and the freeing of the > USB-initiated device structure. This is because the framebuffer device needed > to outlive it if a client was holding on to it. In other words, it's born a > two-headed beast (usb and fbdev), but the two faces of the device are killed > off independently based on remaining ref counts. So there are prints in there > which will fault if converted to dev_* without this in mind. > > Because of this, we had originally created our own dl_* wrapper around the pr_ > macros. > > Then a later patch initiated by Paul (fbdev maintainer) changed those to > uncustomized pr_ macros with a goal of uniformity with other drivers. And that > code is what SMSC started from. > > So there's some complexity behind the choices here. It might be good to keep > common strategies between udlfb and smsc's driver, as the issues to consider > are the same. Ok, thanks for the background information, that makes sense. But for stuff like the usb probe() call, that should always be dev_* as you really do have a proper pointer. So when you do have a valid struct device, you should use it. Although a lot of the pr_info() calls should be downgraded to pr_debug() I imagine, to keep things from being so noisy. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
