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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 11E35C2BB85 for ; Sat, 22 Jun 2024 20:45:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ZAx6xJEcAp2BzU+6jCZ3gQ0T/OrV48S/ARN8pl1rVcw=; b=ZOYMQLV8jvDVY4Z8zzCwyVy5pl oM83ZQaKvoIk7sTewPsZVpz0Na4ojeJjFDBjAWTtaClR/2Jr2HlvQXWO/oRjSFhflBE4SWS+0v3NJ Chcno9iveTPxQhef/itSu731FaUqbnW5uI7Tjdu0b3OGi+yegbyyRDS5F27cla2JWQdDYbNPuIqR2 3QdwJxcRwfKkS3C+Y25FUFJ4eimkWvBCBj8Zt5BoDLucwVrQWx2TuAgRN12l51g4doufZ++UV1Re1 VASC9pZMmGF9DsE58cgddxpPArgXHXbZ+4tJ3ZV5GB1rWLsQr1Qn/jAiQKSyrXZ+eblORC4IWfM6d zu5u9FbA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sL7c5-0000000CmEE-3GKv; Sat, 22 Jun 2024 20:45:34 +0000 Received: from mail.manjaro.org ([2a01:4f8:c0c:51f3::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sL7c0-0000000CmBF-1i7T; Sat, 22 Jun 2024 20:45:30 +0000 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manjaro.org; s=2021; t=1719089125; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZAx6xJEcAp2BzU+6jCZ3gQ0T/OrV48S/ARN8pl1rVcw=; b=yut8vwcxjmeGy4YmsZGRxYcx0knvQfa1RRPq0L8Y2dElH+KmWFRYK+BC8x9fQp5Dji4FRj Rg+/zD5pw1CSr7whGYO4CIuiY/52drtn8tpCZwZVJUYYRFaLggpDMs+NiiNq8EDXW5kHQQ 6+dEGFaVR8d95EdSohBI2qhlglNr0eeO/m5uas95//jDed91uFLFXxdgWASR2nxcdilWFt /EYmo1mcWO2M4wF+a/9ubAUq3MudExsN+bhjEgYXuFwbw4o0/OfTLSZ4pzaxC4/ueysE4X IONlh7c2olGV0pHdtZA0ZkrmwGQ7ZkuI1JQcUfmCmXu2W1ofoDs+m7umToCZ+g== Date: Sat, 22 Jun 2024 22:45:22 +0200 From: Dragan Simic To: =?UTF-8?Q?Heiko_St=C3=BCbner?= Cc: =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , Krzysztof Kozlowski , Daniel Golle , Aurelien Jarno , Olivia Mackall , Herbert Xu , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Philipp Zabel , Sebastian Reichel , Anand Moon , Sascha Hauer , Martin Kaiser , Ard Biesheuvel , linux-crypto@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/3] hwrng: add Rockchip SoC hwrng driver In-Reply-To: <3660160.WbyNdk4fJJ@diego> References: <07fba45d99e9eabf9bcca71b86651074@manjaro.org> <3660160.WbyNdk4fJJ@diego> Message-ID: X-Sender: dsimic@manjaro.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Authentication-Results: ORIGINATING; auth=pass smtp.auth=dsimic@manjaro.org smtp.mailfrom=dsimic@manjaro.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240622_134528_942142_D3073D75 X-CRM114-Status: GOOD ( 23.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Heiko, On 2024-06-22 22:26, Heiko Stübner wrote: > Am Samstag, 22. Juni 2024, 12:29:33 CEST schrieb Dragan Simic: >> On 2024-06-22 00:16, Uwe Kleine-König wrote: >> > On 6/21/24 20:13, Dragan Simic wrote: >> >> On 2024-06-21 11:57, Krzysztof Kozlowski wrote: >> >>> On 21/06/2024 03:25, Daniel Golle wrote: >> >>>> From: Aurelien Jarno >> >> >> >> [snip] >> >> >> >>>> + pm_runtime_set_autosuspend_delay(dev, >> >>>> RK_RNG_AUTOSUSPEND_DELAY); >> >>>> + pm_runtime_use_autosuspend(dev); >> >>>> + pm_runtime_enable(dev); >> >>>> + >> >>>> + ret = devm_hwrng_register(dev, &rk_rng->rng); >> >>>> + if (ret) >> >>>> + return dev_err_probe(&pdev->dev, ret, "Failed to register >> >>>> Rockchip hwrng\n"); >> >>>> + >> >>>> + dev_info(&pdev->dev, "Registered Rockchip hwrng\n"); >> >>> >> >>> Drop, driver should be silent on success. >> >> >> >> I respectfully disagree. Many drivers print a single line upon >> >> successful probing, which I find very useful. In this particular >> >> case, it's even more useful, because some people may be concerned >> >> about the use of hardware TRNGs, so we should actually make sure >> >> to announce it. >> > >> > I agree to Krzysztof here. From the POV of a driver author, your own >> > driver is very important and while you write it, it really interests >> > *you* if the driver is successfully probed. However from a system >> > perspective these are annoying: There are easily >50 devices[1] on a >> > system, if all of these print a message in probe, you have little >> > chance >> > to see the relevant messages. Even if every driver author thinks their >> > work is a special snow flake that is worth announcing, in practice >> > users >> > only care about your driver if there is a problem. Additionally each >> > message takes time and so delays the boot process. Additionally each >> > message takes place in the printk ring buffer and so edges out earlier >> > messages that might be more important. >> >> Well, I don't find those messages annoying, for the drivers I've had >> nothing to do with. Also, in my experience, 99.9% of users don't care >> about the kernel messages at all, be it everything hunky-dory, or be >> it something really wrong somewhere. >> >> > So +1 for dropping the dev_info() or at least using dev_debug() for it. > > Just for 2ct ... I'm also in the don't print too much camp ;-) . > When parsing kernel logs to see where things fail, messages just > telling me about sucesses make things more difficult. > > So really this message should be dropped or at least as Uwe suggests > made a dev_dbg. As a note, "dmesg --level=err,warn", for example, is rather useful when it comes to filtering the kernel messages to see only those that are signs of a trouble.