On Tue, Feb 16, 2016 at 03:45:39PM -0800, Victor Dodon wrote: > On Sun, Feb 14, 2016 at 05:20:21PM -0800, Greg Kroah-Hartman wrote: > > On Wed, Feb 10, 2016 at 04:13:43PM -0800, Victor Dodon wrote: > > > The US_DEBUGPX macro uses printk without specifying a kernel log level, so > > > the default kernel log level is used, which may not match LOGLEVEL_DEBUG > > > used in usb_stor_dbg. Use printk_emit with LOGLEVEL_DEBUG instead. > > > > > > Signed-off-by: Victor Dodon <printesoi@xxxxxxxxxxxx> > > > --- > > > drivers/usb/storage/debug.h | 10 ++++++++-- > > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > Can you just get rid of US_DEBUGPX() entirely please? It shouldn't be > > needed anymore, just use usb_stor_dbg() instead. > > Using usb_stor_dbg() instead of US_DEBUGPX() in > usb_stor_show_command() prints one byte per line with the full syslog > header, like this: > > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876236] Command > TEST_UNIT_READY (6 bytes) > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876242] bytes: > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876249] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876255] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876261] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876267] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876273] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876279] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876285] > > instead of the desired: > > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876236] Command > TEST_UNIT_READY (6 bytes) > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876242] bytes: > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876249] 00 00 00 00 00 00 > > this is why I think the US_DEBUGPX() macro is still needed. Nope, fix the call to use the proper printk % modifier instead and you will be fine. No need to keep reinventing the wheel, we have had support for byte streams in messages for probably over a decade now... Nice try though :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
