Received: by 10.223.185.116 with SMTP id b49csp572836wrg; Tue, 20 Feb 2018 04:25:21 -0800 (PST) X-Google-Smtp-Source: AH8x224+cbRjA8ATjPYTvI0glVjCaZfIfr3vnM/bNa8PHfkv8QfkgCLoduGh6PcLBun9TkUzdIUk X-Received: by 2002:a17:902:b942:: with SMTP id h2-v6mr17320834pls.45.1519129521055; Tue, 20 Feb 2018 04:25:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519129521; cv=none; d=google.com; s=arc-20160816; b=Gofm8MMNMh+rzdwuUsJ1bd3Q3axENTWgg0ujr16c3J6IGydrpA7VsDRMjlQzbjfeA6 Wk+fZwe6zvfcMMyDlQy9rGMRJHfYYQjt8HH1HXHTn+N7dq7QNc2oKOlQQ5WzDseLyodD O4/y7YZ+Uez2uYAn28R+kl38l1pPQp5gleqUrrg9SbMZoFprOAuMvePoTez9jGXjIICV Gj4cNInKJLThePhx83hWFegVPpA0EtE/SdjnCz0gadBfaO0d7lG0VKpSsxlAAuzVnByp Rh/S6b562nZ2hf4z1TPhU5JkXSh0P6ElEwZrOkee/FFIXOfUlvXaNqmj9WtpGNFjOS+7 cheQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=VDg0C5dPgU5ixlOTgfqaQPqhyErBoHT9GLOGKp8tOWs=; b=riuhozVbEyuu8yjQT6s8NlhRr3744Pa5+Kifa9m63x3t7EnjiDKBPEu1IgiRFn/f1T rQh9OMWIdS5Nhbna+Z14TCaoQmMA2fBjYLNGf9Ec5QARAGSR+91aqYWUyKxgxKZXkwnn Yl6eZcTjGm/jBnBEigJzrN3DCbwBaX7zI2lprJgG0rnG6KZidmS5m4EILBQldhV5eoMg papnJWBmcpKW6nI+1IA41LElG6KrS5cR9Yr4I2Gf0eKdUPvnI30ddGh86a7q5EgZDqDN ctTWGxgVM9wXk5/xcJEBr0buaaXxBwkcPL1Ukke1IVfrjK67GoAKNLS5Yh16XTOyvWH7 7uJQ== 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 m30-v6si6920224pli.386.2018.02.20.04.25.06; Tue, 20 Feb 2018 04:25:21 -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 S1751590AbeBTMY0 (ORCPT + 99 others); Tue, 20 Feb 2018 07:24:26 -0500 Received: from mail2.skidata.com ([91.230.2.91]:40519 "EHLO mail2.skidata.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751447AbeBTMYZ (ORCPT ); Tue, 20 Feb 2018 07:24:25 -0500 X-Greylist: delayed 592 seconds by postgrey-1.27 at vger.kernel.org; Tue, 20 Feb 2018 07:24:24 EST X-IronPort-AV: E=Sophos;i="5.46,539,1511823600"; d="scan'208";a="1285288" Subject: Re: [PATCH v2] usb: core: introduce per-port over-current counters To: Felipe Balbi , Richard Leitner , , CC: , , , , , , , , References: <20180220115033.29496-1-dev@g0hl1n.net> <87k1v7q3hx.fsf@linux.intel.com> From: Richard Leitner Message-ID: <5c398870-08ea-e0ec-5fd4-101255e2b727@skidata.com> Date: Tue, 20 Feb 2018 13:14:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <87k1v7q3hx.fsf@linux.intel.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [192.168.111.252] X-ClientProxiedBy: sdex5srv.skidata.net (192.168.111.83) To sdex5srv.skidata.net (192.168.111.83) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/20/2018 12:55 PM, Felipe Balbi wrote: > > 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. Thank you for that suggestion! Generally speaking that would be possible. Nonetheless we a) don't have the possibility to change the firmware or the USB configuration of the device. b) in those corner-cases (where the over-current situation occurs) the device consumes more than 500mA (which couldn't be configured in bMaxPower AFAIK?). Nonetheless most hubs don't detect the over-current (AFAIK) due to electrical tolerances of their components. Our problem are the hubs which trigger the over-current situation (which is fine from a USB perspective). I know it's probably not a very nice solution, so if anybody has a better proposal please let me know :-) Thanks! regards;Richard.L