All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Peter Chen <peter.chen@nxp.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: RE: No message is showed after USB gadget has configured
Date: Tue, 21 Jan 2020 14:08:20 +0200	[thread overview]
Message-ID: <8736c957wr.fsf@kernel.org> (raw)
In-Reply-To: <VI1PR04MB53273947E7B3DE9949DBB94D8B0D0@VI1PR04MB5327.eurprd04.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]


Hi,

Peter Chen <peter.chen@nxp.com> writes:
>> On Mon, Jan 20, 2020 at 09:48:24AM +0000, Peter Chen wrote:
>> >
>> > > On Mon, Jan 20, 2020 at 09:03:59AM +0000, Peter Chen wrote:
>> > > > Hi all,
>> > > >
>> > > > >From commit 1cbfb8c4f62d ("usb: gadget: Quieten gadget config
>> > > > >message"),
>> > > > there is no any message from gadget side after it connects to host
>> > > > and works correctly. Although we could cat "state" under
>> > > > /sys/class/udc/$CONTROLLER/ to know its state, we can't easily
>> > > > know if the gadget works or not from console, USB host could have
>> > > > many messages after one device has connected, why we can't keep
>> > > > one for USB gadget?
>> > >
>> > > Why not make "normal" USB devices quieter too? :)
>> > >
>> > > Surely you do not have tools that watch syslog to determine if a
>> > > device is working properly or not, right?  That's what sysfs is for, not syslog
>> entries.
>> > >
>> >
>> > Yes, we use our eyes during the hot plug test for device or count the
>> > number of messages for it, with this change, it may cause difficult
>> > for hot plug test. For other tests, we could judge sysfs before later tests.
>> >
>> > Since this message in there many years, we (and tester) may need time
>> > to adapt for this change.
>> 
>> Can you just turn on dynamic debugging for that one line with a simple echo to the
>> debugfs file so that you still see this in your test framework?
>  
> No, most released kernel or end user's kernel doesn't enable dynamic debug.
> In fact, we use this message in formal release product to quick judge if the
> device function is ok, not just in development periods.

While I agree that dynamic debug is usually disabled, almost 100% of all
product kernels have sysfs enabled. The only exception I know of is
Microsoft Azure Sphere (downloadable from
https://3rdpartysource.microsoft.com/), but that doesn't support USB
anyway.

It should be very easy to figure out if a new device was attached and is
working, no?

From a peripheral stack point of view, at least dwc3 prints *nothing*
unless there's an error. And that's okay since I only want to see
messages if I get an error condition or a bug report, which case I'll
enable trace events.

I agree with Greg here, we should actually make Host stack quieter too,
including HCD drivers.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

      reply	other threads:[~2020-01-21 12:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20  9:03 No message is showed after USB gadget has configured Peter Chen
2020-01-20  9:29 ` Greg Kroah-Hartman
2020-01-20  9:48   ` Peter Chen
2020-01-20 10:48     ` Greg Kroah-Hartman
2020-01-21  2:04       ` Peter Chen
2020-01-21 12:08         ` Felipe Balbi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8736c957wr.fsf@kernel.org \
    --to=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=peter.chen@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.