From: Oliver Neukum <oneukum@suse.com>
To: "Warren Togami" <wtogami@gmail.com>,
"Oliver Neukum" <oneukum@suse.com>,
"Michael Laß" <bevan@bi-co.net>,
linux-usb@vger.kernel.org
Subject: Re: Cypress CDC ACM serial port not working correctly with autosuspend
Date: Tue, 13 Jun 2023 10:36:10 +0200 [thread overview]
Message-ID: <d970e109-bf6a-badd-2e0f-6eb01015bee6@suse.com> (raw)
In-Reply-To: <76fadf60-86cd-91d7-1594-bbbaf75bc96e@gmail.com>
On 08.06.23 02:48, Warren Togami wrote:
> Thanks! Tested your patch against 6.4.0-rc5. Both usbcore.quirks=1a86:55d4:b and usbcore.quirks=1a86:55d4:p allow the device to be fully functional. It even works through suspend+resume of the host. Without the quirk the only other way for this device to function at all is to turn off autosuspend.
>
> How should we proceed? "p" would be the narrower quirk. Would this be appropriate for drivers/usb/core/quirks.c?
Hi,
having established that both work, it will be necessary to determine
which is better.
The reason I am not happy with the existing quirk is that it
does unnecessary resets and I don't think that they are harmless,
as they ought to reset values to their default.
Could you devise a test that basically looks like
echo "command that changes a setting the next command depends on" > /to/the/device
[wait 5 seconds - autosuspend will kick in]
echo "the next command that depends on the setting changed" > /to/the/device
Neither quirk disables autosuspend completely. They limit it to the
cases remote wakeup is not required. That fits the times while the device
not is not opened.
With 'b' (RESET_RESUME) the sequence would be:
open
write
close
suspend
resume
reset
open
write
close
I would like to check whether the reset, which 'p' omits, changes the outcome.
Regards
Oliver
next prev parent reply other threads:[~2023-06-13 8:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-29 11:44 Cypress CDC ACM serial port not working correctly with autosuspend Michael Laß
2023-01-30 13:03 ` Oliver Neukum
2023-01-30 13:08 ` Oliver Neukum
2023-01-30 15:44 ` Michael Laß
2023-02-07 19:35 ` Michael Laß
2023-03-14 13:16 ` Oliver Neukum
2023-03-18 12:09 ` Michael Laß
2023-03-23 9:51 ` Oliver Neukum
2023-03-23 12:52 ` Michael Laß
2023-03-23 13:53 ` Oliver Neukum
2023-03-23 21:32 ` Michael Laß
2023-03-27 8:05 ` Oliver Neukum
2023-06-03 23:59 ` Warren Togami
2023-06-07 13:10 ` Oliver Neukum
2023-06-08 0:48 ` Warren Togami
2023-06-13 8:36 ` Oliver Neukum [this message]
2023-06-12 18:39 ` Michael Laß
2023-06-07 14:33 ` Michael Laß
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=d970e109-bf6a-badd-2e0f-6eb01015bee6@suse.com \
--to=oneukum@suse.com \
--cc=bevan@bi-co.net \
--cc=linux-usb@vger.kernel.org \
--cc=wtogami@gmail.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.