Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755969AbbLAKl6 (ORCPT ); Tue, 1 Dec 2015 05:41:58 -0500 Received: from dgate10.ts.fujitsu.com ([80.70.172.49]:17409 "EHLO dgate10.ts.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755759AbbLAKl4 (ORCPT ); Tue, 1 Dec 2015 05:41:56 -0500 DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:Received:Received:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version; b=LdtTMaHzFk+RkAA9LWAGWeU5CG9t6FMyoh2fvI7Gn93GCFXPFZ3WWGFX +p4tQ5jKhT0m3ZqYKoj2ofFUTaVZS0o44KvtxozY7KAqv4yLqZIV9Zm9y YIUFJdgyGTmf0b3DFjAZCGkEOhUdthQL1e6P7t7kO13QVj4tYjC75ODwV QE5uhgDcMCMwUwC4XISxtV6CBrWWA7eDGlf1eKWcOjBVnXCVCuvRSLH4y 4WcL9cAQYkVLTj9+1tEn9kG5qxdN2; X-SBRSScore: None From: "Wilck, Martin" To: =?utf-8?B?VXdlIEtsZWluZS1Lw7ZuaWc=?= CC: "linux-kernel@vger.kernel.org" , "tpmdd-devel@lists.sourceforge.net" Date: Tue, 1 Dec 2015 11:41:53 +0100 Subject: Re: [PATCH] base/platform: fix panic when probe function is NULL Thread-Topic: [PATCH] base/platform: fix panic when probe function is NULL Thread-Index: AdEsJORUeNTYDj4YQpOKQDOpekgqUQ== Message-ID: References: <1448564494-23218-1-git-send-email-martin.wilck@ts.fujitsu.com> <20151127101125.GS19888@pengutronix.de> In-Reply-To: <20151127101125.GS19888@pengutronix.de> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tB1Ag13b026721 Content-Length: 1838 Lines: 41 Hello Uwe, > This sounds like a separate issue though. Looking at init_tis there is: > > rc = platform_driver_register(&tis_drv); > if (rc < 0) > return rc; > pdev = platform_device_register_simple("tpm_tis", -1, NULL, 0); > if (IS_ERR(pdev)) { > rc = PTR_ERR(pdev); > goto err_dev; > } > rc = tpm_tis_init(&pdev->dev, &tis_default_info, NULL); > > 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? As far as I understand the code, the assumption would be correct in 4.3.0 and earlier: platform_driver_register() registers a platform driver with name "tpm_tis". platform_device_register_simple() registers a device with the same name. This will call platform_device_add()/device_add() and start probing for a platform device. Platform bus probing in platform_match() falls back to a simple match between driver and device name if all else fails. That match succeeds for the "tpm_tis" driver. Thus driver_probe_device() will be called, and in the absence of a driver-specific probe routine, will succeed. Thus after platform_device_register_simple() returns, device and driver will be bound. This matches also actual behavior of the pre-4.4 code. Please explain what I am overlooking. I am just trying to understand. As far as tpm_tis is concerned, Jason's current patch set is going to fix this for good anyway. Regards Martin ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?