Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp780699imu; Wed, 23 Jan 2019 05:39:01 -0800 (PST) X-Google-Smtp-Source: ALg8bN4bKUYH0gpHNeqx1xc9DFI4zdgmNZQNkkTlcNeUMAb9CL2zF1PaiqYvOhtGINqJLHScQPKu X-Received: by 2002:a63:d104:: with SMTP id k4mr1933395pgg.227.1548250741039; Wed, 23 Jan 2019 05:39:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548250741; cv=none; d=google.com; s=arc-20160816; b=DaSB6YM17QeV3ze+GD7d0pZ8AN8iPlX0mUtn4NAATb3/XoKhhnT10LLluzVTiqkoZy VVNWWbk92ugqf83q/n0+y+Vvn669oPM9l0/atradyRP+OytR+mTYBXwYlla4c0ATBc6X XhnwXBvWf7otoDWPY49ds4+mnHPp+KbBElaA+vQWiXg8VIjJ4ADKBiu+TX27J8yNs2Ac JKKtrW9TzQ4Ztir8+V2SedJIyOyUwzwg7aNZltHjmCsiPW94czusCZ/s1p96T2faNyr1 oCpH0UHtuNin7+yvTWD2XomDRNLcIzmrtqQrllNKVDLOCV34dH8uJpdkY9PUyozLj2in XxZA== 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:dkim-signature; bh=K7RI2yksDeVsDbSOcg5ZPKPgvK2nJcRjjS1IYe4otCU=; b=kWmEHJDyYN8sdpFjVi353zssULGqs8dbRde+x4Nm91C0eIV4nRzki8Ar24hGuyycf5 mYcOcxxmbirDu2VwNRMfXz6TKGLdpdvdrH2dZDvSPQSu+Br1HEIMHG5GpBfRXbb87ygG TgOwapuKqFtbDdfnmYWq3SoU7uARnHhrY9IUOXuEhE3TZHYV1PkMV1z2IeZpgrepm3BH izaI21e4odIa17cn3XmIv2yKDuzGBxV992q7zREF1owbN6yYwwyO0eTHGtfSbib+8c36 a4yQyrElwejLbnvcgz/G7QPw6DGRlMsSB4TWktH5Cb4A/j0T09HERTpPMFZlsaaNMqOE efxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=HipdrgOS; 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 u24si6609350pgj.489.2019.01.23.05.38.44; Wed, 23 Jan 2019 05:39:01 -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; dkim=pass header.i=@kernel.org header.s=default header.b=HipdrgOS; 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 S1726200AbfAWNhh (ORCPT + 99 others); Wed, 23 Jan 2019 08:37:37 -0500 Received: from mail.kernel.org ([198.145.29.99]:54168 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726104AbfAWNhh (ORCPT ); Wed, 23 Jan 2019 08:37:37 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0FD1B20870; Wed, 23 Jan 2019 13:37:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548250656; bh=3a/MtQUpzEdTGF0DNHDAkp/SYrostyZCYJCi7oDxtKs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HipdrgOStFWDbf0zUs9zEET6zNCrPVlQXhqPWgmb+AY8g52S532G+mqnWYldfSoC6 cyc06EpUXiO045jVAu2mCe3i79IWqdc+jwNTxVmA2P6KMXf2dstb5ddzyQ7xNBhQvP SZWBTs+UTCSUchhARu7LppYhOqwpuPn1f6mjlr9g= Date: Wed, 23 Jan 2019 14:37:34 +0100 From: Greg Kroah-Hartman To: Gilad Ben-Yossef Cc: Herbert Xu , David Miller , Linux kernel mailing list , Linux Crypto Mailing List , Yael Chemla Subject: Re: [PATCH 2/7] crypto: ccrree: no need to check return value of debugfs_create functions Message-ID: <20190123133734.GA24700@kroah.com> References: <20190122151422.14204-1-gregkh@linuxfoundation.org> <20190122151422.14204-3-gregkh@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 23, 2019 at 02:58:22PM +0200, Gilad Ben-Yossef wrote: > Hi, > > On Tue, Jan 22, 2019 at 5:14 PM Greg Kroah-Hartman > wrote: > > > > When calling debugfs functions, there is no need to ever check the > > return value. The function can work or not, but the code logic should > > never do something different based on this. > > > > I get the part about not failing loading the driver just because some > debugs entry isn't available, but wont it be weird if > debugfs_create_dir() fails but debugfs_create_regset32() succeeds and > we suddenly have weird files in the debugfs root dir? > Not the end of the world of course but maybe it's better to avoid > trying to create the files if the directory is not available? See this patch to handle that theoretical issue: https://lore.kernel.org/lkml/20190123130917.GZ4087@dhcp22.suse.cz/T/#me91cc3d16185be13d64f85c8477c543cbda9baf6 thanks, greg k-h