From: Alan Stern <stern@rowland.harvard.edu> To: Anurag Kumar Vulisha <anuragku@xilinx.com> Cc: Felipe Balbi <balbi@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Shuah Khan <shuah@kernel.org>, Johan Hovold <johan@kernel.org>, Jaejoong Kim <climbbb.kim@gmail.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Roger Quadros <rogerq@ti.com>, Manu Gautam <mgautam@codeaurora.org>, "martin.petersen@oracle.com" <martin.petersen@oracle.com>, Bart Van Assche <bvanassche@acm.org>, Mike Christie <mchristi@redhat.com>, Matthew Wilcox <willy@infradead.org>, Colin Ian King <colin.king@canonical.com>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "v.anuragkumar@gmail.com" <v.anuragkumar@gmail.com>, Thinh Nguyen <thinhn@synopsys.com>, Tejas Joglekar <tejas.joglekar@synopsys.com>, Ajay Yugalkishore Pandey <APANDEY@xilinx.com> Subject: RE: [PATCH v7 01/10] usb: gadget: udc: Add timer support for usb requests Date: Tue, 4 Dec 2018 14:28:50 -0500 (EST) [thread overview] Message-ID: <Pine.LNX.4.44L0.1812041420200.1537-100000@iolanthe.rowland.org> (raw) In-Reply-To: <SN6PR02MB56484B8D1F891926DA7D7900A7AF0@SN6PR02MB5648.namprd02.prod.outlook.com> On Tue, 4 Dec 2018, Anurag Kumar Vulisha wrote: > >Is there any way for the device controller driver to detect the problem without relying > >on a timeout? > > > >In fact, is this problem a known bug in the existing device controller hardware? Have > >the controller manufacturers published a suggested scheme for working around it? > > > > Yes, this problem is mentioned in dwc3 controller data book and the workaround > mentioned is the same that we are doing , to implement timeout and if no valid > stream event is found , after timeout issue end transfer followed by start transfer. Okay. But this implies that the problem is confined to DWC3 and doesn't affect other types of controllers, which would mean modifying the UDC core would be inappropriate. Does the data book suggest a value for the timeout? > >At this point, it seems that the generic approach will be messier than having every > >controller driver implement its own fix. At least, that's how it appears to me. (Especially if dwc3 is the only driver affected.) > With the dequeue approach there is an advantage(not related to this issue) that the > class driver can have control of the timed out transfer whether to requeue it or consider > it as an error (based on implementation). This approach gives more flexibility to the class > drivers. This may be out of context of this issue but wanted to point out that we may lose > this advantage on switching to older implementation. Class drivers can cancel and requeue requests at any time. There's no extra flexibility. > >Ideally it would not be necessary to rely on a timeout at all. > > > >Also, maintainers dislike module parameters. It would be better not to add one. > > Okay. I would be happy if any alternative for this issue is present but unfortunately > I am not able to figure out any alternative other than timers. If not module_params() > we can add an configfs entry in stream gadget to update the timeout. Please provide > your opinion on this approach. Since the purpose of the timeout is to detect a deadlock caused by a hardware bug, I suggest a fixed and relatively short timeout value such as one second. Cancelling and requeuing a few requests at 1-second intervals shouldn't add very much overhead. Alan Stern
WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern@rowland.harvard.edu> To: Anurag Kumar Vulisha <anuragku@xilinx.com> Cc: Felipe Balbi <balbi@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Shuah Khan <shuah@kernel.org>, Johan Hovold <johan@kernel.org>, Jaejoong Kim <climbbb.kim@gmail.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Roger Quadros <rogerq@ti.com>, Manu Gautam <mgautam@codeaurora.org>, "martin.petersen@oracle.com" <martin.petersen@oracle.com>, Bart Van Assche <bvanassche@acm.org>, Mike Christie <mchristi@redhat.com>, Matthew Wilcox <willy@infradead.org>, Colin Ian King <colin.king@canonical.com>, "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "v.anuragkumar@gmail.com" <v.anuragkumar@gmail.com>, Thinh Nguyen <thinhn@synopsys.com>, Tejas Joglekar <tejas.joglekar@synopsys.com>, Ajay Yugalkishore Pandey <APANDEY@xilinx.com> Subject: [v7,01/10] usb: gadget: udc: Add timer support for usb requests Date: Tue, 4 Dec 2018 14:28:50 -0500 (EST) [thread overview] Message-ID: <Pine.LNX.4.44L0.1812041420200.1537-100000@iolanthe.rowland.org> (raw) On Tue, 4 Dec 2018, Anurag Kumar Vulisha wrote: > >Is there any way for the device controller driver to detect the problem without relying > >on a timeout? > > > >In fact, is this problem a known bug in the existing device controller hardware? Have > >the controller manufacturers published a suggested scheme for working around it? > > > > Yes, this problem is mentioned in dwc3 controller data book and the workaround > mentioned is the same that we are doing , to implement timeout and if no valid > stream event is found , after timeout issue end transfer followed by start transfer. Okay. But this implies that the problem is confined to DWC3 and doesn't affect other types of controllers, which would mean modifying the UDC core would be inappropriate. Does the data book suggest a value for the timeout? > >At this point, it seems that the generic approach will be messier than having every > >controller driver implement its own fix. At least, that's how it appears to me. (Especially if dwc3 is the only driver affected.) > With the dequeue approach there is an advantage(not related to this issue) that the > class driver can have control of the timed out transfer whether to requeue it or consider > it as an error (based on implementation). This approach gives more flexibility to the class > drivers. This may be out of context of this issue but wanted to point out that we may lose > this advantage on switching to older implementation. Class drivers can cancel and requeue requests at any time. There's no extra flexibility. > >Ideally it would not be necessary to rely on a timeout at all. > > > >Also, maintainers dislike module parameters. It would be better not to add one. > > Okay. I would be happy if any alternative for this issue is present but unfortunately > I am not able to figure out any alternative other than timers. If not module_params() > we can add an configfs entry in stream gadget to update the timeout. Please provide > your opinion on this approach. Since the purpose of the timeout is to detect a deadlock caused by a hardware bug, I suggest a fixed and relatively short timeout value such as one second. Cancelling and requeuing a few requests at 1-second intervals shouldn't add very much overhead. Alan Stern
next prev parent reply other threads:[~2018-12-04 19:29 UTC|newest] Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-12-01 11:13 [PATCH v7 00/10] usb: dwc3: Fix broken BULK stream support to dwc3 gadget driver Anurag Kumar Vulisha 2018-12-01 11:13 ` [PATCH v7 01/10] usb: gadget: udc: Add timer support for usb requests Anurag Kumar Vulisha 2018-12-01 11:13 ` [v7,01/10] " Anurag Kumar Vulisha 2018-12-02 16:36 ` [PATCH v7 01/10] " Alan Stern 2018-12-02 16:36 ` [v7,01/10] " Alan Stern 2018-12-03 10:23 ` [PATCH v7 01/10] " Anurag Kumar Vulisha 2018-12-03 10:23 ` [v7,01/10] " Anurag Kumar Vulisha 2018-12-03 14:51 ` [PATCH v7 01/10] " Alan Stern 2018-12-03 14:51 ` [v7,01/10] " Alan Stern 2018-12-03 16:05 ` [PATCH v7 01/10] " Anurag Kumar Vulisha 2018-12-03 16:05 ` [v7,01/10] " Anurag Kumar Vulisha 2018-12-03 23:08 ` [PATCH v7 01/10] " Alan Stern 2018-12-03 23:08 ` [v7,01/10] " Alan Stern 2018-12-04 16:18 ` [PATCH v7 01/10] " Anurag Kumar Vulisha 2018-12-04 16:18 ` [v7,01/10] " Anurag Kumar Vulisha 2018-12-04 16:46 ` [PATCH v7 01/10] " Alan Stern 2018-12-04 16:46 ` [v7,01/10] " Alan Stern 2018-12-04 19:07 ` [PATCH v7 01/10] " Anurag Kumar Vulisha 2018-12-04 19:07 ` [v7,01/10] " Anurag Kumar Vulisha 2018-12-04 19:28 ` Alan Stern [this message] 2018-12-04 19:28 ` Alan Stern 2018-12-05 15:43 ` [PATCH v7 01/10] " Anurag Kumar Vulisha 2018-12-05 15:43 ` [v7,01/10] " Anurag Kumar Vulisha 2018-12-07 6:05 ` [PATCH v7 01/10] " Felipe Balbi 2018-12-07 6:05 ` [v7,01/10] " Felipe Balbi 2018-12-07 17:09 ` [PATCH v7 01/10] " Alan Stern 2018-12-07 17:09 ` [v7,01/10] " Alan Stern 2018-12-12 15:11 ` [PATCH v7 01/10] " Anurag Kumar Vulisha 2018-12-12 15:11 ` [v7,01/10] " Anurag Kumar Vulisha 2019-01-04 14:17 ` [PATCH v7 01/10] " Anurag Kumar Vulisha 2019-01-04 14:17 ` [v7,01/10] " Anurag Kumar Vulisha 2018-12-01 11:13 ` [PATCH v7 02/10] usb: gadget: function: tcm: Add timeout for stream capable endpoints Anurag Kumar Vulisha 2018-12-01 11:13 ` [v7,02/10] " Anurag Kumar Vulisha 2018-12-01 11:13 ` [PATCH v7 03/10] usb: dwc3: gadget: handle stream events Anurag Kumar Vulisha 2018-12-01 11:13 ` [v7,03/10] " Anurag Kumar Vulisha 2018-12-01 11:13 ` [PATCH v7 04/10] usb: dwc3: update stream id in depcmd Anurag Kumar Vulisha 2018-12-01 11:13 ` [v7,04/10] " Anurag Kumar Vulisha 2018-12-01 11:13 ` [PATCH v7 05/10] usb: dwc3: make controller clear transfer resources after complete Anurag Kumar Vulisha 2018-12-01 11:13 ` [v7,05/10] " Anurag Kumar Vulisha 2018-12-05 9:01 ` [PATCH v7 05/10] " Felipe Balbi 2018-12-05 9:01 ` [v7,05/10] " Felipe Balbi 2018-12-05 19:05 ` [PATCH v7 05/10] " Anurag Kumar Vulisha 2018-12-05 19:05 ` [v7,05/10] " Anurag Kumar Vulisha 2018-12-01 11:13 ` [PATCH v7 06/10] usb: dwc3: don't issue no-op trb for stream capable endpoints Anurag Kumar Vulisha 2018-12-01 11:13 ` [v7,06/10] " Anurag Kumar Vulisha 2018-12-01 11:13 ` [PATCH v7 07/10] usb: dwc3: check for requests in started list " Anurag Kumar Vulisha 2018-12-01 11:13 ` [v7,07/10] " Anurag Kumar Vulisha 2018-12-01 11:13 ` [PATCH v7 08/10] usb: dwc3: Correct the logic for checking TRB full in __dwc3_prepare_one_trb() Anurag Kumar Vulisha 2018-12-01 11:13 ` [v7,08/10] " Anurag Kumar Vulisha 2018-12-01 11:13 ` [PATCH v7 09/10] usb: dwc3: Check for IOC/LST bit in both event->status and TRB->ctrl fields Anurag Kumar Vulisha 2018-12-01 11:13 ` [v7,09/10] " Anurag Kumar Vulisha 2018-12-05 9:07 ` [PATCH v7 09/10] " Felipe Balbi 2018-12-05 9:07 ` [v7,09/10] " Felipe Balbi 2018-12-05 19:01 ` [PATCH v7 09/10] " Anurag Kumar Vulisha 2018-12-05 19:01 ` [v7,09/10] " Anurag Kumar Vulisha 2018-12-07 6:11 ` [PATCH v7 09/10] " Felipe Balbi 2018-12-07 6:11 ` [v7,09/10] " Felipe Balbi 2018-12-08 19:03 ` [PATCH v7 09/10] " Anurag Kumar Vulisha 2018-12-08 19:03 ` [v7,09/10] " Anurag Kumar Vulisha 2018-12-10 6:54 ` [PATCH v7 09/10] " Felipe Balbi 2018-12-10 6:54 ` [v7,09/10] " Felipe Balbi 2018-12-10 8:56 ` [PATCH v7 09/10] " Anurag Kumar Vulisha 2018-12-10 8:56 ` [v7,09/10] " Anurag Kumar Vulisha 2018-12-10 9:03 ` [PATCH v7 09/10] " Felipe Balbi 2018-12-10 9:03 ` [v7,09/10] " Felipe Balbi 2018-12-01 11:13 ` [PATCH v7 10/10] usb: dwc3: Check MISSED ISOC bit only for ISOC endpoints Anurag Kumar Vulisha 2018-12-01 11:13 ` [v7,10/10] " Anurag Kumar Vulisha
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=Pine.LNX.4.44L0.1812041420200.1537-100000@iolanthe.rowland.org \ --to=stern@rowland.harvard.edu \ --cc=APANDEY@xilinx.com \ --cc=anuragku@xilinx.com \ --cc=balbi@kernel.org \ --cc=benh@kernel.crashing.org \ --cc=bvanassche@acm.org \ --cc=climbbb.kim@gmail.com \ --cc=colin.king@canonical.com \ --cc=gregkh@linuxfoundation.org \ --cc=johan@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=mchristi@redhat.com \ --cc=mgautam@codeaurora.org \ --cc=rogerq@ti.com \ --cc=shuah@kernel.org \ --cc=tejas.joglekar@synopsys.com \ --cc=thinhn@synopsys.com \ --cc=v.anuragkumar@gmail.com \ --cc=willy@infradead.org \ /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: linkBe 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.