linux-kernel - Re: [PATCH v2 00/18] USB/IP VHCI suspend fix and driver cleanup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3dd94c4f-0971-4744-91e1-3a5474e1576c@collabora.com>
Date: Mon, 28 Jul 2025 12:41:46 +0300
From: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Valentina Manea <valentina.manea.m@...il.com>,
 Shuah Khan <shuah@...nel.org>, Hongren Zheng <i@...ithal.me>,
 "Brian G. Merrell" <bgmerrell@...ell.com>, kernel@...labora.com,
 Greg Kroah-Hartman <gregkh@...e.de>, linux-usb@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/18] USB/IP VHCI suspend fix and driver cleanup

Hi Greg,

On 7/26/25 9:43 AM, Greg Kroah-Hartman wrote:
> On Sat, Jul 26, 2025 at 01:08:02AM +0300, Cristian Ciocaltea wrote:
>> The USB/IP Virtual Host Controller (VHCI) platform driver is expected to
>> prevent entering system suspend when at least one remote device is
>> attached to the virtual USB root hub.
>>
>> However, in some cases, the detection logic for active USB/IP
>> connections doesn't seem to work reliably, e.g. when all devices
>> attached to the virtual hub have been already suspended.  This will
>> normally lead to a broken suspend state, with unrecoverable resume.
>>
>> The first patch of the series provides a workaround to ensure the
>> virtually attached devices do not enter suspend.  Note this is currently
>> limited to the client side (vhci_hcd) only, since the server side
>> (usbip_host) doesn't implement system suspend prevention.
>>
>> Additionally, during the investigation I noticed and fixed a bunch of
>> coding style issues, hence the subsequent patches contain all the
>> changes needed to make checkpatch happy for the entire driver.
> 
> You are doing two major things here, fixing suspend, and cleaning up
> checkpatch issues.  Please make that two different patch sets as those
> are not logical things to put together at all.  Work on the suspend
> issue first, and after that is all done and working, then consider
> checkpatch cleanups, those are not that important overall :)

Yeah, the cleanup part ended up larger than initially anticipated, but I
don't really expect further changes on the fixup side.  I can handle the
split if another revision would be still required, or would you like me to
do this regardless?  I've just made a quick test moving the first patch to
the end of the series and it didn't cause any conflicts, hence there won't 
be any dependencies between the two patch sets.

Thanks,
Cristian