Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6034494imu; Sun, 2 Dec 2018 08:37:30 -0800 (PST) X-Google-Smtp-Source: AFSGD/WigCfm6oIMokTO7HoRJifQoqECaOZcWa89J5mf4/wd+EqozkOPclzZA/hZLpZn0AVZtqpS X-Received: by 2002:a63:1b48:: with SMTP id b8mr9565334pgm.187.1543768650873; Sun, 02 Dec 2018 08:37:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543768650; cv=none; d=google.com; s=arc-20160816; b=GmUbZb284nRxjha+eHO1hFbkwytQYJzx/O9pj/JG6LJ99huR6yCUZj2+n9lK3TmEAP WKNBCXC3Cx1t/JlECuyy/fy3jq+TW021XPpJfBKnJiz6OXR2Y7X1osEDf5ZYDt2YjhRA znXdntYOFh9xw7j1pDNsNFFQEzV0GGH/lH0ESgJtpjrIUN9uKAJp46GKV1fiDjwSURXf MZq6vals0CmQd43ddsesH/Dm8ZRRIdKYRDLo3d7wrTAjUiGirzJ0CTOjW/tr83dG6+Ex aGzzGQ1H9TOMtQKFSYy5PkREElBIWiWXMEwbvFPSFmgbg0pYwnXrJ7gaTcOj44g2dNI0 qyaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=vcKRDEC96538NJ/ouXvOzSb/Iwj00+6wdPnY6BDkD8M=; b=AnFr1o4lB8H2AbE18V/PEknvUmCR31H3wLDb0DHskCK8V4fq+qk+cTOsoYPwk3xI70 LfcV2IlsIiS/nJp6RFfrKuIKU1YHkdevfOlKIslHSUmX7pz6hNMDKtrDmUUDtzecLFFv iyUPWJKClZXPNw4HmSNPv7RylY54mzZ1aCDqEsplwaO1/aOJluDmM6X/FR1U3xrz4WV9 FQgtek5NqDao8CAiptLk3JQXHq5ebvYtM9b5evZ9F+bDsIOzumuWd4lQzg82nvvphe4G q2rY6WPW9B9U/dU6zu1EDl1RTQHCiUvP5Cg5xSaL8qdVz6shg3erUyEffNALjdMCV5w2 n5nQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y3si11990739pfb.152.2018.12.02.08.37.16; Sun, 02 Dec 2018 08:37:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725939AbeLBQgW (ORCPT + 99 others); Sun, 2 Dec 2018 11:36:22 -0500 Received: from netrider.rowland.org ([192.131.102.5]:54227 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1725901AbeLBQgW (ORCPT ); Sun, 2 Dec 2018 11:36:22 -0500 Received: (qmail 17920 invoked by uid 500); 2 Dec 2018 11:36:20 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Dec 2018 11:36:20 -0500 Date: Sun, 2 Dec 2018 11:36:20 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Anurag Kumar Vulisha cc: Felipe Balbi , Greg Kroah-Hartman , Shuah Khan , Johan Hovold , Jaejoong Kim , Benjamin Herrenschmidt , Roger Quadros , Manu Gautam , , Bart Van Assche , Mike Christie , Matthew Wilcox , Colin Ian King , , , , Thinh Nguyen , Tejas Joglekar , Ajay Yugalkishore Pandey Subject: Re: [PATCH v7 01/10] usb: gadget: udc: Add timer support for usb requests In-Reply-To: <1543662811-5194-2-git-send-email-anurag.kumar.vulisha@xilinx.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 1 Dec 2018, Anurag Kumar Vulisha wrote: > In some corner cases the gadget controller may get out of sync > with host and may get into hang state, thus creating a dealock. > For example when bulk streams are enabled for an endpoint, there > can be a condition where the gadget controller waits for the host > to issue prime transaction and the host controller waits for the > gadget to issue ERDY. This condition could create a deadlock. > > To avoid such potential deadlocks, a timer is started after queuing > any request for the endpoint in usb_ep_queue(). The gadget driver > is expected to stop the timer if a valid event is found (ex: stream > event for stream capable endpoints). If no valid event is found, the > timer expires after the programmed timeout value and a timeout > callback function registered would be called. This callback function > dequeues the request and re-queues it again, doing so makes the > controller restart the transfer, thus avoiding deadlocks. > > This kind of behaviour is observed in dwc3 controller and expected > to be generic issue with other controllers supporting bulk streams. I find this whole approach rather dubious. First of all, if some sort of deadlock causes a transfer to fail to complete, the host is expected to cancel and restart it. Not the gadget. Second, if a request timer expires and the request is cancelled, the gadget driver's completion handler will be called. This is not what you want if the UDC core is going to resubmit the request automatically. Third, if a request timer expires and the timer handler calls usb_ep_dequeue() followed immediately by usb_ep_queue_timeout(), the resubmit will probably fail because the dequeue won't have completed yet. Fourth, the patch contains a race between the timer expiring and the request completing. Alan Stern