From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D73D4C2D0BF for ; Thu, 5 Dec 2019 14:26:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AA25121835 for ; Thu, 5 Dec 2019 14:26:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1575556001; bh=B44m5w38XqeeZeyxOxvTz4RjVYRgjbWKm12VoLmYVt4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=X1ttYQlUP5ffNM9xuC7al56AFFZ+bRW8RXZuaxrU/1E+Y1r+KgzbtXglrcwsA0DZz 5hTuN/gfWZMny2N8Q7IoNcJCPX2nyccUwGZi9QVqJU4vni7zACWJ5sobvZYblvVh+9 Dgy7dEAyb+eb/qumB+TAEVd3LPprnEptvhaWrusk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729519AbfLEO0h (ORCPT ); Thu, 5 Dec 2019 09:26:37 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:45116 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729402AbfLEO0h (ORCPT ); Thu, 5 Dec 2019 09:26:37 -0500 Received: by mail-lj1-f196.google.com with SMTP id d20so3761253ljc.12; Thu, 05 Dec 2019 06:26:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FPiOMjJ2rQ9P8n4Ma3k63SEaCRn4xx4awe4inxl+t/I=; b=aN3wqPjMXvVUeLwYiWDFQgknsauXIVhiRmKFhuUwjKM8TXtkBYr42qJv9nVUiOCsoC pGPvVON/Hy9K7wvQvm6un9dAFB6CPLkK458w4GwgRr2+yFgDoG0ERsUf3BoULCRaO+Tj WkjW41jKYCISxActDbz1Tal5cjQ/F6bSexV7590+sWSR3hAbk5l5888/kNqVMpqZA1GY DAgodg0KrFGhub9KfvsFf8MpAGMA6C8BZ1r+aNE8mlkfVVYA/SKSEeVBCqXqp9HkNeQv 3dFgE8f/DetikoqMttME7wqSjjbq38ALW4QDzJTtB/A8ilgTXFuSHbMm9YO2WHIeq3iE l+Cg== X-Gm-Message-State: APjAAAX49iYT6acaHrTpAyalWGarr6Kq4BjICoHT1cMpV9hnLPN8plTs hRrQKMHHf2oy/34tpoxd7Aw= X-Google-Smtp-Source: APXvYqzb4cLM/qctOgqo1PA/b3FzFA5gxEnEqCCSI8qwFiyJ8WN0zrZ3X7VCu0P4Lh5tl2rFEtEQRA== X-Received: by 2002:a2e:3312:: with SMTP id d18mr5836966ljc.222.1575555994820; Thu, 05 Dec 2019 06:26:34 -0800 (PST) Received: from xi.terra (c-14b8e655.07-184-6d6c6d4.bbcust.telenor.se. [85.230.184.20]) by smtp.gmail.com with ESMTPSA id x29sm5866487lfg.45.2019.12.05.06.26.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Dec 2019 06:26:34 -0800 (PST) Received: from johan by xi.terra with local (Exim 4.92.3) (envelope-from ) id 1ics5Z-0001Kf-0i; Thu, 05 Dec 2019 15:26:41 +0100 Date: Thu, 5 Dec 2019 15:26:41 +0100 From: Johan Hovold To: Ikjoon Jang Cc: Johan Hovold , linux-usb@vger.kernel.org, GregKroah-Hartman , RobHerring , MarkRutland , AlanStern , SuwanKim , "GustavoA . R . Silva" , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Nicolas Boichat Subject: Re: [PATCH v4 2/2] usb: overridable hub bInterval by device node Message-ID: <20191205142641.GL10631@localhost> References: <20191203101552.199339-1-ikjn@chromium.org> <20191203165301.GH10631@localhost> <20191204075533.GI10631@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Thu, Dec 05, 2019 at 03:32:38PM +0800, Ikjoon Jang wrote: > On Wed, Dec 4, 2019 at 3:55 PM Johan Hovold wrote: > > But related to my question above, why do you need to do this during > > enumeration? Why not just set the lower interval value in the hub > > driver? > > Because I want device tree's bInterval to be checked against the same rules > defined in usb_parse_endpoint(). e.g. although hardware says its maximum > is 255, but the practical limit is still 0 to 16, so the code can > print warnings when bInterval from device node is too weird. But that could be handled refactoring the code in question or similar. The fundamental problem here is that you're using devicetree, which is supposed to only describe the hardware, to encode policy which should be deferred to user space. So I think you need to figure out an interface that allows user space to set the polling interval for any hub at runtime instead. Johan