[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whxaSHcHeo10JGz3EMJZBfC1LarcrerLos7uHbE1URhtQ@mail.gmail.com>
Date: Thu, 5 Jan 2023 13:58:48 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: Thorsten Leemhuis <regressions@...mhuis.info>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Peter Huewe <peterhuewe@....de>,
Jarkko Sakkinen <jarkko@...nel.org>,
Jason Gunthorpe <jgg@...pe.ca>, Jan Dabros <jsd@...ihalf.com>,
regressions@...ts.linux.dev, LKML <linux-kernel@...r.kernel.org>,
linux-integrity@...r.kernel.org,
Dominik Brodowski <linux@...inikbrodowski.net>,
Herbert Xu <herbert@...dor.apana.org.au>,
Johannes Altmanninger <aclopte@...il.com>,
stable@...r.kernel.org
Subject: Re: [PATCH] tpm: Disable hwrng for TPM 1 if PM_SLEEP is enabled
On Thu, Jan 5, 2023 at 6:48 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> TPM 1's support for its hardware RNG is broken across system suspends,
> due to races or locking issues or something else that haven't been
> diagnosed or fixed yet. These issues prevent the system from actually
> suspending. So disable the driver in this case. Later, when this is
> fixed properly, we can remove this.
How about just keeping it enabled, but not making it a fatal error if
the TPM saving doesn't work? IOW, just print the warning, and then
"return 0" from the suspend function.
I doubt anybody cares, but your patch disables that TPM device just
because PM is *enabled*. That's basically "all the time".
Imagine being on a desktop with a distro kernel that enables suspend -
because that kernel obviously is expected to work on laptops too.
You're never actually going to suspend things on that machine, but
maybe you still want to register it as a source of hw random data?
Linus
Powered by blists - more mailing lists