Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp135664ybl; Fri, 9 Aug 2019 03:45:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqxGhEC9qyITzht4qWcI+2rm2LugXPtN8OPBoj2Y2VlxwOsmNYB+oVZALYOyyy57S4XtdJWF X-Received: by 2002:a17:90a:8c18:: with SMTP id a24mr8559734pjo.111.1565347548583; Fri, 09 Aug 2019 03:45:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565347548; cv=none; d=google.com; s=arc-20160816; b=TLUwekjVyHQ5vqiprHy3eQpSs7r1vk62XFj8bUlTs11rt9pEQ9UH1jIVzMl/arNQpg TqART2yg8WbK/UwSFRciHndmC8o6iqzm+hE6G8/OlgVsE1Mq50j9Ivuymml75oEUGPEd AKuRbkXyeXDp7vicZeC5ZjvCBQOYJ67xoVMIqibD30PuL5l/+8sxSDBBNgMNYwrfyV6R 91+8HYiN9tfmOGX+PRMheTebi4YyYrCIorjDhIZqROzrQ8C+Mpf8bBGhbLPBeAzNn4JP RMlD3+fG/8jrEQMfbOROIvfKjudjRSdF5kxQXrGso2NNFbkI3u+zbotpTV0AQ3xL3zSj iIXQ== 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:date:references :in-reply-to:subject:cc:to:from; bh=FOcb8dO7pVvjk2lTrh+nE1+pIox87XkyyOkbWg2WS+o=; b=c5ki2HWTi8kPGbUyeGztdEib/0t6qq0G+bQ7ahDESUtiD0dZwzLpQgamjP+DkmOYdm nlP2OgdBMD8qOwXILIAGIqBJEjwM8cVJp2Wah5QN5Fmo0w4pxEz42Dx11ti2nQ69s6lM xQi6N9x79Ws5+BiU/WifjLpwXJRG5XIk0MLo++GsYzViE/iNJibYqB+JN0c+kp5udbhD putNTbe9Kj0oXJcO0Vc7pFANl28W45N/FWgkcSKpc34Nkakz1i5ygBiz/yn+UjLUUXvM WPsD6o6K2gtknhlQIwgjf8ydJGyR2AYBH4HUntzSw/Bs+8t+Ev38Py74gEHj+f2K0Jqu K4sA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r10si52854008pgv.530.2019.08.09.03.45.32; Fri, 09 Aug 2019 03:45:48 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406081AbfHIKoT (ORCPT + 99 others); Fri, 9 Aug 2019 06:44:19 -0400 Received: from mga01.intel.com ([192.55.52.88]:6052 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726140AbfHIKoT (ORCPT ); Fri, 9 Aug 2019 06:44:19 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2019 03:44:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,364,1559545200"; d="scan'208";a="176788402" Received: from pipin.fi.intel.com (HELO pipin) ([10.237.72.175]) by fmsmga007.fm.intel.com with ESMTP; 09 Aug 2019 03:44:16 -0700 From: Felipe Balbi To: Roger Quadros , Pawel Laszczak , Pavel Machek Cc: "gregkh\@linuxfoundation.org" , "linux-usb\@vger.kernel.org" , "linux-kernel\@vger.kernel.org" , "jbergsagel\@ti.com" , "nsekhar\@ti.com" , "nm\@ti.com" , Suresh Punnoose , Jayshri Dajiram Pawar , Rahul Kumar , Anil Joy Varughese Subject: Re: [PATCH v10 0/6] Introduced new Cadence USBSS DRD Driver. In-Reply-To: <3fce07ee-5e69-58a9-58f6-750f60b66296@ti.com> References: <1563733939-21214-1-git-send-email-pawell@cadence.com> <20190721190335.GA19831@xo-6d-61-c0.localdomain> <20190722114839.GA10515@kroah.com> <20190722115644.GA12069@amd> <20190722210021.GA25235@amd> <93b4a702-227b-0410-a414-76873088ad72@ti.com> <3fce07ee-5e69-58a9-58f6-750f60b66296@ti.com> Date: Fri, 09 Aug 2019 13:44:15 +0300 Message-ID: <87wofmty80.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Roger Quadros writes: >> It allows me for testing some functionality using only single board >> and even with lacking right cable for proper otg detection. >> >> So, removing this can cause that testing some functionality >> will be limited on my boards. >> >> If you rely want to remove this, maybe we could do this >> after putting this driver to kernel ?. > > I don't want you to remove the user based role change functionality. > I'm just asking to rely on role switch framework for that and not debugfs. I agree with Roger. Use role switch framework for production, not debugfs. -- balbi