Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1281108
| From | Peter Huewe <peterhuewe@gmx.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [tpmdd-devel] [PATCH] base/platform: fix panic when probe function is NULL |
| Date | 2015-12-01 19:40 +0100 |
| Message-ID | <qAY0j-4MF-27@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <qzoie-1vq-13@gated-at.bofh.it> <qAQFt-8sH-41@gated-at.bofh.it> <qATai-1KL-21@gated-at.bofh.it> <qAUSJ-2T0-3@gated-at.bofh.it> <qAWUy-49J-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH] base/platform: fix panic when probe function is NULL "Wilck, Martin" <martin.wilck@ts.fujitsu.com> - 2015-12-01 11:50 +0100
Re: [PATCH] base/platform: fix panic when probe function is NULL Uwe Kleine-König <u.kleine-koenig@pengutronix.de> - 2015-12-01 14:30 +0100
Re: [PATCH] base/platform: fix panic when probe function is NULL "Wilck, Martin" <martin.wilck@ts.fujitsu.com> - 2015-12-01 16:20 +0100
Re: [tpmdd-devel] [PATCH] base/platform: fix panic when probe function is NULL Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2015-12-01 18:30 +0100
Re: [tpmdd-devel] [PATCH] base/platform: fix panic when probe function is NULL Peter Huewe <peterhuewe@gmx.de> - 2015-12-01 19:40 +0100
Re: [tpmdd-devel] [PATCH] base/platform: fix panic when probe function is NULL Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2015-12-01 19:50 +0100
Aw: Re: [tpmdd-devel] [PATCH] base/platform: fix panic when probe function is NULL "Peter Huewe" <PeterHuewe@gmx.de> - 2015-12-01 20:00 +0100
Re: Re: [tpmdd-devel] [PATCH] base/platform: fix panic when probe function is NULL Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2015-12-01 20:10 +0100
csiph-web