Received: by 10.213.65.68 with SMTP id h4csp1178163imn; Wed, 14 Mar 2018 11:57:48 -0700 (PDT) X-Google-Smtp-Source: AG47ELuufQq8FssyHuDNLvdregbTR79JGmESC+M9lYZ4xZcuYhhPb6ZaAgh5KzCSjpTh9wVJ5qcO X-Received: by 10.101.82.139 with SMTP id y11mr4590004pgp.68.1521053868159; Wed, 14 Mar 2018 11:57:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521053868; cv=none; d=google.com; s=arc-20160816; b=rhlYcJVDWDTneCCm4knj5GrGK76Po8ILzDtI3GncX918jFrpSTYvqqbwC0rhRR+b6s mtT/thwjXpaQrv98ut44u+Vty6OHUBi32ic4c4dDKXvwkyD0KSQhtybgDag2+eicb/c4 zmZ7VSS/79n11inK+6WX7CC3KW+Mz61mKk4Y5s7VEUdO2dukp8fBGQNdHH5sIr53GpW8 TFFAXERt3bD6S/IIvaQNpp0rwmvAMBlCwh28n0tIRXhABtYlnRPvM+bcy2jkiZEfqeJ4 4P7la4etS+Ex/xEdhnyCSc7y2H/JGKc1XX6L8u70ACGiF4nYOsCFZIPZ9EKqWZQK5GPG sm7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=mBkFHK+6f/EQoJO78E5zUdXmH6X9J46/mPBSBpTB+lo=; b=emKxzP0kjFZ9zy3jjkLZTwDCxbHpR4j+pqkPWonmh9AN3fNrf24ma5D7pC3KbmCdZ0 34i/Wng9fwly/T0N0QKryQX+VFfK1/3whioLTlXfpWlGJWu5qKwtEAjBDYRn7j8WiCg4 OymJW6g7o0KLczNlIKwqTMQNoYcK+suBRt2KEqaaWlbv46zx7+NHKq6M5wJ8Ln+RMTiZ S2DAjkTttAGNXHNw4FuE1TDxzN2MQmmWpR+Dlblf/pMCgOZuROVaRY+pzeWjpU/9SVTX zGqmcL92j8WPtWPNHq87SQ7UYGPIlZbAgNDrnrX4W/W7FzGIKT1Q+Ao5g3fx3ZenQTIi QkfQ== 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 e93-v6si2386257plk.159.2018.03.14.11.57.33; Wed, 14 Mar 2018 11:57: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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751869AbeCNS4h (ORCPT + 99 others); Wed, 14 Mar 2018 14:56:37 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:59798 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751405AbeCNS4f (ORCPT ); Wed, 14 Mar 2018 14:56:35 -0400 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id D8703E8E; Wed, 14 Mar 2018 18:56:34 +0000 (UTC) Date: Wed, 14 Mar 2018 19:56:34 +0100 From: Greg KH To: "Luis R. Rodriguez" Cc: akpm@linux-foundation.org, cantabile.desu@gmail.com, kubakici@wp.pl, linux-wireless@vger.kernel.org, keescook@chromium.org, shuah@kernel.org, mfuzzey@parkeon.com, zohar@linux.vnet.ibm.com, dhowells@redhat.com, pali.rohar@gmail.com, tiwai@suse.de, arend.vanspriel@broadcom.com, zajec5@gmail.com, nbroeking@me.com, markivx@codeaurora.org, broonie@kernel.org, dmitry.torokhov@gmail.com, dwmw2@infradead.org, torvalds@linux-foundation.org, Abhay_Salunke@dell.com, bjorn.andersson@linaro.org, jewalt@lgsinnovations.com, oneukum@suse.com, ast@fb.com, andresx7@gmail.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v3 07/20] firmware: move loading timeout under struct firmware_fallback_config Message-ID: <20180314185634.GC15837@kroah.com> References: <20180310141501.2214-1-mcgrof@kernel.org> <20180310141501.2214-8-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180310141501.2214-8-mcgrof@kernel.org> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 10, 2018 at 06:14:48AM -0800, Luis R. Rodriguez wrote: > The timeout is a fallback construct, so we can just stuff the > timeout configuration under struct firmware_fallback_config. Why? What does it matter? > While at it, add a few helpers which vets the use of getting or > setting the timeout as an int. The main use of the timeout is > to set a timeout for completion, and that is used as an unsigned > long. There a few cases however where it makes sense to get or > set the timeout as an int, the helpers annotate these use cases > have been properly vetted for. This feels really odd to me. Why would you want to use it as an int, just keep it the same "size" everywhere and it should be simpler and easier to keep working correctly over time. thanks, greg k-h