User-Agent: K-9 Mail for Android
In-Reply-To: <20151201172537.GA541@obsidianresearch.com>
References: <1448564494-23218-1-git-send-email-martin.wilck@ts.fujitsu.com> <20151127101125.GS19888@pengutronix.de> <C5A28EF7B98F574C85C70238C8E9ECC04E682BF148@ABGEX74E.FSC.NET> <20151201132436.GC5072@pengutronix.de> <C5A28EF7B98F574C85C70238C8E9ECC04E682BF154@ABGEX74E.FSC.NET> <20151201172537.GA541@obsidianresearch.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8BIT
Subject: Re: [tpmdd-devel] [PATCH] base/platform: fix panic when probe function is NULL
From: Peter Huewe <peterhuewe@gmx.de>
Date: Tue, 01 Dec 2015 10:26:17 -0800
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
        "Wilck, Martin" <martin.wilck@ts.fujitsu.com>
CC: "tpmdd-devel@lists.sourceforge.net" 
	<tpmdd-devel@lists.sourceforge.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        =?ISO-8859-1?Q?Uwe_Kleine-K=F6nig?= 
	<u.kleine-koenig@pengutronix.de>
Message-ID: <BFC9031E-E471-4EF6-832C-D6E05E2AAAC2@gmx.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2143
Lines: 54


Am 1. Dezember 2015 09:25:37 PST, schrieb Jason Gunthorpe <jgunthorpe@obsidianresearch.com>:
>On Tue, Dec 01, 2015 at 04:19:25PM +0100, Wilck, Martin wrote:
>> > > > tpm_tis_init calls tpmm_chip_alloc which barfs when pdev (i.e.
>the return value
>> > > > of platform_device_register_simple above) isn't bound. It is
>not allowed
>> > > > to assume that the device is bound after the above function
>calls.
>> > > 
>> > > Can you please explain again why you think that assumption is
>invalid? 
>> > 
>> > You can unbind a device from a driver via sysfs, you can also
>prevent
>> > binding somehow I think, probing can fail for different reasons,
>probing
>> > might wait for userspace interaction to load firmware which wasn't
>> > scheduled yet. I'm sure there are still more things that break the
>> > assumption.
>> 
>> Thanks. Out of these, "prevent binding somehow" would be the only
>> problem that applies to tpm_tis, as probing can't fail (no probe()
>> routine), there's no FW to load, and unbinding via sysfs would
>require
>> nearly impossible timing (not sure if it could be done with udev).
>> 
>> Anyway, the Right Thing to do is to create a probe() routine and
>that's
>> what Jason did.
>
>That fixes tpm_tis, but there are other ancient TPM drivers that use
>the old, now broken way.
>
>So, we still need to do something here. Either fixup b8b2c7d845d5 as
>you have proposed, remove the now broken obsolete TPM drivers, or try
>and fix them..

How broken are they and since when?

I thought multiple times about deprecating and finally removing the 1.1b stuff - tpm 1.2 is out for 10? years now? With an expected life span of a TPM of roughly 5years... 
And also unfortunately the 1.1b legacy drivers usually get loaded first :( (atleast for slb9635)

Mark them as obsolete , default them to No and remove them by 4.10 if there are no objections?

Peter
-- 
Sent from my mobile
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/