From patchwork Mon Jun 19 09:43:03 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: PrasannaKumar Muralidharan X-Patchwork-Id: 9795611 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7E46A6020B for ; Mon, 19 Jun 2017 09:43:06 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A750B27EE2 for ; Mon, 19 Jun 2017 09:43:06 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9A2F627F92; Mon, 19 Jun 2017 09:43:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1F83527EE2 for ; Mon, 19 Jun 2017 09:43:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751864AbdFSJnF (ORCPT ); Mon, 19 Jun 2017 05:43:05 -0400 Received: from mail-vk0-f67.google.com ([209.85.213.67]:35152 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751834AbdFSJnE (ORCPT ); Mon, 19 Jun 2017 05:43:04 -0400 Received: by mail-vk0-f67.google.com with SMTP id 19so6643970vkd.2 for ; Mon, 19 Jun 2017 02:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HGP0ijHqcjK4n7t32ufyKipX3y2cNJzJQkRvYwi0cXY=; b=E7SPvomm+bPoxH2PICH+EUW+NoP8+166jVSGbSR6o/shLlQPITlZTHfokWhc3JahoW g4B2s6i6N1FydgIYWBzWd3bELTnDOgpx3dTNO2x6DNJQD9C8MVa5pRBailsmabvM/8Ne w/2CQ3NuAmdodNYKhswo4xq5UDBaj8TF2w8cOoqe9oXPXoGz/qh7BIEUmsKbbBSjeqHu /ULOTB8P9p2Dzu40p3EfPJYpeglUoq8aVCu2AVKVewYnOkq/B9yuWy8wNEf/yL3rACTT rwXyp0t6tl12Ov+FIJ4wb4XtbbXL98kTOCwcRvr+UpnpLe/+MUZ+d5YdlV70DObToKsm YN0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HGP0ijHqcjK4n7t32ufyKipX3y2cNJzJQkRvYwi0cXY=; b=Lcr+YzQIJznd3C742pxJXeCfzCkaBnfIgqxOermZZiS7ps65g+Ph4gQFgt0F3d+Pkl jbxL538utjUXEujwZ0jPQ27gvevfULklcyMgkplLNnsYkG58D9HpfRhf1hCmxKPgSeKR UZphGZlRhQRgo1sVMwglnJcyW02O4iDKtVUGyF4Qdzj9rdCvVA4a8lURT8nhJFxjwJ2b WNIzKOXfN94YzZ/atxo7W8YydI9uFszxX/y/52qa1/xnkMGB2Wt+kObSoq7HazgGxVmV pbDdzhgZDKE+JpqzAkfjeFCf8ge9gti2av0rOZtgKMXGLERYUkaqw7BKCjpe3fKIdyC2 tskQ== X-Gm-Message-State: AKS2vOzCz2Yvbgd0QJKvglqP955lCwVcW5DWlr2BNuMwffrAU4AAcme9 fhipQ9uLDzxEYmH9T1JXZqH0DnZTUN0n X-Received: by 10.31.159.5 with SMTP id i5mr12691562vke.116.1497865383559; Mon, 19 Jun 2017 02:43:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.142.9 with HTTP; Mon, 19 Jun 2017 02:43:03 -0700 (PDT) In-Reply-To: <20170619062115.GA13498@gondor.apana.org.au> References: <20170512041734.31945-1-vapier@gentoo.org> <20170619041234.GA12984@gondor.apana.org.au> <20170619062115.GA13498@gondor.apana.org.au> From: PrasannaKumar Muralidharan Date: Mon, 19 Jun 2017 15:13:03 +0530 Message-ID: Subject: Re: [PATCH] hwrng: do not warn when there are no devices To: Herbert Xu Cc: Mike Frysinger , Matt Mackall , linux-crypto@vger.kernel.org Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 19 June 2017 at 11:51, Herbert Xu wrote: > On Sun, Jun 18, 2017 at 10:00:17PM -0700, Mike Frysinger wrote: >> >> in order to make tpm-rng react in the way you're implying, the TPM >> subsystem would need to add a notification chain for transitions from >> none<->some devices, then tpm-rng could subscribe to that, and during >> those transition points, it would call hwrng_register/hwrng_unregister >> to make itself visible accordingly to the hwrng subsystem. maybe >> someone on the TPM side would be interested in writing all that logic, >> but it sounds excessive for this minor usage. the current tpm-rng >> driver is *extremely* simple -- it's 3 funcs, each of which are 1 >> line. > > It's simple and it's broken, as far as the way it hooks into the > hwrng is concerned. ********************************************************************************************* ********************************************************************************************* Why not something like this? Patch is completely untested. If this idea seems useful I can clean the code but would require help in testing. Regards, PrasannaKumar diff --git a/drivers/char/hw_random/tpm-rng.c b/drivers/char/hw_random/tpm-rng.c index d6d4482..4861b35 100644 --- a/drivers/char/hw_random/tpm-rng.c +++ b/drivers/char/hw_random/tpm-rng.c @@ -22,6 +22,10 @@ #include #define MODULE_NAME "tpm-rng" +#define MAX_RETRIES 30 + +static struct delayed_work check_tpm_work; +static int retry_count; static int tpm_rng_read(struct hwrng *rng, void *data, size_t max, bool wait) { @@ -33,9 +37,27 @@ static struct hwrng tpm_rng = { .read = tpm_rng_read, }; +static void check_tpm_presence(struct work_struct *work) +{ + u8 data = 0; + if (tpm_get_random(TPM_ANY_NUM, &data, 1) > 0) { + hwrng_register(&tpm_rng); + } else { + if (retry_count < MAX_RETRIES) { + retry_count++; + schedule_delayed_work(&check_tpm_work, HZ * 10); + } else { + pr_err("Could not find any TPM chip, not registering rng"); + } + } +} + static int __init rng_init(void) { - return hwrng_register(&tpm_rng); + INIT_DELAYED_WORK(&check_tpm_work, check_tpm_presence); + check_tpm_presence(NULL); + + return 0; } module_init(rng_init);