Subject: Re: [PATCH v1 1/2] HID: usbhid: enable remote wakeup function for
 usbhid device
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
References: <1638956391-20149-1-git-send-email-zhuyinbo@loongson.cn>
 <caf93951-4c63-d0f1-e3f4-d0d49dec6a47@suse.com>
 <d2e4a97a-b89b-eaf4-5aaf-89af22227746@loongson.cn>
 <654e90fb-2f04-1f87-f56c-792757e140a0@suse.com>
 <8ed3dbee-c51c-db54-37b7-182d5a75fff8@loongson.cn>
 <78229065-61e6-3d61-8cf3-3c24c0f96ae2@suse.com>
From:   zhuyinbo <zhuyinbo@loongson.cn>
Message-ID: <a3cffd50-ffb7-ce09-70ab-964e74669e68@loongson.cn>
Date:   Tue, 4 Jan 2022 19:44:10 +0800
User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <78229065-61e6-3d61-8cf3-3c24c0f96ae2@suse.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


在 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.

>