[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201030104033.GA2392682@kroah.com>
Date: Fri, 30 Oct 2020 11:40:33 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Christoph Hellwig <hch@....de>
Cc: Jens Axboe <axboe@...nel.dk>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Denis Efremov <efremov@...ux.com>,
"David S. Miller" <davem@...emloft.net>,
Song Liu <song@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
Finn Thain <fthain@...egraphics.com.au>,
Michael Schmitz <schmitzmic@...il.com>,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-ide@...r.kernel.org, linux-raid@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-m68k@...ts.linux-m68k.org
Subject: Re: [PATCH 02/18] block: open code kobj_map into in block/genhd.c
On Thu, Oct 29, 2020 at 08:32:42PM +0100, Christoph Hellwig wrote:
> On Thu, Oct 29, 2020 at 08:22:36PM +0100, Greg Kroah-Hartman wrote:
> > After this, you want me to get rid of kobj_map, right? Or you don't
> > care as block doesn't use it anymore? :)
>
> I have a patch to kill it, but it causes odd regressions with the
> tpm driver according to the kernel test. As I have grand plans that
> build on the block Ń•ide of this series for 5.11, I plan to defer the
> chardev side and address it for 5.12.
Ok, sounds good.
Wow, I just looked at the tpm code, and it is, um, "interesting" in how
it thinks device lifespans work. Nothing like having 4 different
structures with different lifespans embedded within a single structure.
Good thing that no one can dynamically remove a TPM device during
"normal" operation.
greg k-h
Powered by blists - more mailing lists