On Wed, 05 Jun 2019, Johan Hovold wrote: > On Wed, Jun 05, 2019 at 09:20:47AM +0100, Lee Jones wrote: > > On Wed, 05 Jun 2019, Johan Hovold wrote: > > > > No, we don't add noise like this to the logs just because it may be > > > useful while debugging. Even one-liners add up. > > > > One line per device is should not cause an issue. > > > > Problems occur when developers try to print all kinds of device > > specifics to the boot log. A simple, single line for such an > > important device/controller has more benefits than drawbacks. > > What about the thousands of probe functions which do not currently spam > the logs? If you want to see all successful probes reliably, you tell > driver core to print it. > > > > There are plenty of options for debugging already ranging from adding a > > > temporary dev_info() to the probe function in question to using dynamic > > > debugging to have driver core log every successful probe. > > > > This is what I ended up doing. It was time consuming to parse though > > a log of that size when you have no paging or keyboard. > > With the right command-line option to enable dynamic debugging you get > one line per successful probe, just like you wanted. Or are you now > saying that one-line per device is too much after all? ;) Which command line option are you pertaining to? > > > And in this case you say the driver was in fact already bound; that can > > > easily be verified through sysfs too in case things aren't behaving the > > > way you expect. > > > > Not in a non-booting system with no keyboard you can't. ;) > > Fair enough, but the above would still work. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
