Sorry, I totally missed responding to your mail in March. Seeing the most recent mails on this topic, let me answer the open questions: > Am 27.03.2023 um 10:05 schrieb Oliver Neukum <oneukum@xxxxxxxx>: > > On 23.03.23 22:32, Michael Laß wrote: >> Am Donnerstag, dem 23.03.2023 um 14:53 +0100 schrieb Oliver Neukum: > >>> I am asking because the device says that it is bus powered. >>> That is, are we putting the device into some sleep state? >> This got me thinking. I am observing the behavior on a ZedBoard, a >> development board that contains a Xilinx Zynq SoC and the Cypress UART >> chip connected to that SoC. I now looked into the schematic of that >> board. > > Are those devices out in the wild? That is can one buy them or did > you get it through development channels? Those are development boards for the first generation of Xilinx/AMD Zynq SoCs. The board is still listed in some online shops and should be readily available, however it's now nearly ten years old and probably not used a lot anymore as there are more modern SoCs available by now. >> The chip is a CY7C64225-28PVXC and the datasheet has a section on USB >> suspend and resume: When suspended, a separate WAKE input pin has to be >> set high to issue a remote wake-up. The designers of the ZedBoard have >> tied this pin to ground... > > That is technically allowed, though disappointing, but then you cannot advertise > "remote wakeup" in the device descriptor. Right. Although I'm not sure if the board vendor has any chance to disable advertisement of that feature using that specific chip. >> So the chip behaves as documented. If any, this is an issue with the >> board design. Nothing the kernel could work around. Sorry, I hope I >> haven't stolen too much of your time. > > The kernel could work around it. We could quirk the device to ignore > the remote wakeup bit from this particular device based on ID. > RESET_RESUME would do that, albeit with side effects. > > If such devices are found on sale we need to do something. Seeing that there is now at least a second device suffering from this issue, it's maybe more wide spread than I thought. Introducing the proposed quirk for those chips would of course mean that other devices that use them and implement remote wakeup properly will not be able to make use of auto suspend. But that may be a smaller issue compared to having broken functionality on some devices. I'll test your proposed patch with my board in the next couple of days. Best regards, Michael
