Received: by 10.223.185.116 with SMTP id b49csp545512wrg; Tue, 20 Feb 2018 03:59:23 -0800 (PST) X-Google-Smtp-Source: AH8x227M1vzRLUEG0eunBZl5gzKENflj4i6LtQ+hlD3aGS2kdrxxfececLByrQJw5yNynV9G1SY7 X-Received: by 2002:a17:902:ab8a:: with SMTP id f10-v6mr17501234plr.318.1519127963771; Tue, 20 Feb 2018 03:59:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519127963; cv=none; d=google.com; s=arc-20160816; b=izxeRsmsi/HvPp3foo7G4vt3TGfklpNvMpyoNdnt2Rjz+Bq8pHQ0SZ1n9Lr7UBcWqX SPBlQob9w8hIsvI4GAQtD3mUY/iRWB9aihEc2VeLMtD589VXjR+bXcPDAZdjL4FuTnSD S5nJS3mLVYeGtn+BHLd6LROPi6eAKUcYZU+OE23k4ob6DvBNUBgClq/RIEtAPzfxKzGO tEfzZoQnzJoNhW/4mjyeoAdSGVZjHXNLPaK1uUARbeym8SlTzWLRHjj3XfGOMA4OAOSk +Px0WVfMMX5E7hOEr7suxekhylbfVg+p0Nr9nNIfaVw/0VihYQU7fPrUigP7PNFd+Gfy PiIA== 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:arc-authentication-results; bh=eYVgci3JhknQZQ6QGFp4lZT27mpkuRgUeu2gPSggIdQ=; b=YgeZKb025OvfeECgxu/y8/v6FutoqcoceV652vuB3w17Jf8JfbOmrw8p/uS57698Ec OMg9TCmmjZp6E7kEw7vkVCKFdlWW1zsNm0O7EJcOvi+jeAIgaLmyfgr29Yzpe9BkAwUS LhxP6RDx64FWH9j5T08UL/KXfAb6Sj/AYIRpWmbm6B7CnaL4utJGAixHVxRicAwxW9ck HksipkfWySPVaBMrqOmTcIjW7j2nJ+Ph+VFt9c/qX5w4Ra7H7+s6HBEKn4qaHdm3FMkm JT1KUcNyDgCDJugDxeoi01gkrlW3niWaHKWJGGTGXIHBzAmXD3GGrh7kHk79F9+b0uXM 1cew== 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 l3si4760010pgu.518.2018.02.20.03.59.09; Tue, 20 Feb 2018 03:59:23 -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 S1751623AbeBTL4d (ORCPT + 99 others); Tue, 20 Feb 2018 06:56:33 -0500 Received: from mga03.intel.com ([134.134.136.65]:34314 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751567AbeBTL4c (ORCPT ); Tue, 20 Feb 2018 06:56:32 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2018 03:56:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,539,1511856000"; d="scan'208";a="202406582" Received: from pipin.fi.intel.com (HELO localhost) ([10.237.68.37]) by orsmga005.jf.intel.com with ESMTP; 20 Feb 2018 03:56:28 -0800 From: Felipe Balbi To: Richard Leitner , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Cc: gregkh@linuxfoundation.org, stern@rowland.harvard.edu, linux@roeck-us.net, mathias.nyman@linux.intel.com, johan@kernel.org, ekorenevsky@gmail.com, peter.chen@nxp.com, drake@endlessm.com, joe@perches.com, Richard Leitner Subject: Re: [PATCH v2] usb: core: introduce per-port over-current counters In-Reply-To: <20180220115033.29496-1-dev@g0hl1n.net> References: <20180220115033.29496-1-dev@g0hl1n.net> Date: Tue, 20 Feb 2018 13:55:54 +0200 Message-ID: <87k1v7q3hx.fsf@linux.intel.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, Richard Leitner writes: > From: Richard Leitner > > For some userspace applications information on the number of > over-current conditions at specific USB hub ports is relevant. > > In our case we have a series of USB hardware (using the cp210x driver) > which communicates using a proprietary protocol. These devices sometimes > trigger an over-current situation on some hubs. In case of such an > over-current situation the USB devices offer an interface for reducing > the max used power. As these conditions are quite rare and imply > performance reductions of the device we don't want to reduce the max > power always. > > Therefore give user-space applications the possibility to react > adequately by introducing an over_current_counter in the usb port struct > which is exported via sysfs. why don't you just provide more than one configuration with several bMaxPower fields? Then host OS should choose correct configuration based on power budget. -- balbi