linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: zhuyinbo <zhuyinbo@loongson.cn>
To: Oliver Neukum <oneukum@suse.com>,
	gregkh@linuxfoundation.org, Jiri Kosina <jikos@kernel.org>,
	benjamin.tissoires@redhat.com, Thinh.Nguyen@synopsys.com,
	mathias.nyman@linux.intel.com, stern@rowland.harvard.edu,
	rajatja@google.com, chris.chiu@canonical.com,
	linux-usb@vger.kernel.org, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org, zhuyinbo@loongson.cn,
	benjamin.tissoires@redhat.com, Thinh.Nguyen@synopsys.com,
	mathias.nyman@linux.intel.com, stern@rowland.harvard.edu,
	rajatja@google.com, chris.chiu@canonical.com,
	linux-usb@vger.kernel.org, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/2] HID: usbhid: enable remote wakeup function for usbhid device
Date: Tue, 4 Jan 2022 19:44:10 +0800	[thread overview]
Message-ID: <a3cffd50-ffb7-ce09-70ab-964e74669e68@loongson.cn> (raw)
In-Reply-To: <78229065-61e6-3d61-8cf3-3c24c0f96ae2@suse.com>



在 2021/12/16 下午8:42, Oliver Neukum 写道:
> 
> On 16.12.21 11:59, zhuyinbo wrote:
>>
>>
> Hi,
> 
> 
>> if you only talk about wakeup source you can think that usb-wakeup
>> source and acpi-lid wakeup source was different things. but if you
>> talk about laptop and distinguish lid and other event and you shoud
>> know the cannotation why system still continue sleep when lid closed
>> then system by other event wakeup. if you need test usb-wakeup for
>> laptop and that lid shouldn't be closed.
> I am sorry, I am not sure what you wish to say here. Could you rephrase it?
>>> from the default.
That connotation lid was closed represent human will not use laptop and 
system must keep it was sleep and even though the laptop was 
accidentally awakened.
>>>
>>> In general any HID device must have wakeup capability to be usable for
>>> selective suspend. You cannot draw conclusions from that.
>> you still can has wakeup capability, but it should be keep enabled by
>> default. because the hid device should be convenient for human,
> 
> Well, no. We are talking about a kernel default. That needs to be so that it
> always works on all systems. Convinience is secondary.
if system can doesn't consider lid open event and ignore the connotation 
about lid open event I think that system behavior is inappropriate. you 
don't think my patch was inapproriate that on some system doesn't 
consider lid open event.

In additon, if it doesn't include my patch and non-keyboard hid device 
doesn't make system wakeup by ohci. because ohci driver doesn't export 
wakeup property for usb slave device.
> 
> 
>> if you don't think so and I think HID definition is ridiculous.
> It does have its weaknesses, in particular with respect to differentiating
> between events for wakeups. But we cannot change it.
>>
>>
>> In addition, I had said that laptop usb wakeup was disabled in system
>> bios by default and if user want enable usb wakeup that was only by
>> configure bios and doesn't need enable wakeup node if my patch was
>> applied
> If you deviate from the default, you deviate. That is reducing the number of
> changes is worth little. The default must be above everything else safe.
> 
>      Regards
>          Oliver
bios and kernel was two sets of things and they should has their own 
indepdent configuration.  if bios enable usb wakeup but wakeup is still 
not work well. Do you think it is appropriate?

in additon, The keyboard device is enabled by default, and other hid 
devices should also be enabled. Otherwise, it will be treated differently.

> 


  reply	other threads:[~2022-01-04 11:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08  9:39 [PATCH v1 1/2] HID: usbhid: enable remote wakeup function for usbhid device Yinbo Zhu
2021-12-08  9:39 ` [PATCH v1 2/2] usb: core: enable remote wakeup function for usb controller Yinbo Zhu
2021-12-08 14:10   ` kernel test robot
2021-12-08 22:04   ` Alan Stern
2021-12-10  9:27     ` zhuyinbo
2021-12-10 16:35       ` Alan Stern
2021-12-08 10:03 ` [PATCH v1 1/2] HID: usbhid: enable remote wakeup function for usbhid device Oliver Neukum
2021-12-10  9:50   ` zhuyinbo
2021-12-14 14:21     ` Oliver Neukum
2021-12-16 10:59       ` zhuyinbo
2021-12-16 12:42         ` Oliver Neukum
2022-01-04 11:44           ` zhuyinbo [this message]
2021-12-08 11:55 ` Greg Kroah-Hartman
2021-12-10  9:54   ` zhuyinbo
2021-12-10 10:45     ` Greg Kroah-Hartman
2021-12-16 11:40       ` zhuyinbo

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=a3cffd50-ffb7-ce09-70ab-964e74669e68@loongson.cn \
    --to=zhuyinbo@loongson.cn \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=chris.chiu@canonical.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=oneukum@suse.com \
    --cc=rajatja@google.com \
    --cc=stern@rowland.harvard.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).