From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938864AbcLVJS5 (ORCPT ); Thu, 22 Dec 2016 04:18:57 -0500 Received: from mga09.intel.com ([134.134.136.24]:41653 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750750AbcLVJSz (ORCPT ); Thu, 22 Dec 2016 04:18:55 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,387,1477983600"; d="scan'208";a="1085418547" Date: Thu, 22 Dec 2016 11:18:50 +0200 From: Mika Westerberg To: "Rafael J. Wysocki" Cc: Chen Yu , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Len Brown , Rui Zhang , Linux ACPI Subject: Re: [PATCH] platform: Print the resource range if device failed to claim Message-ID: <20161222091850.GH1460@lahna.fi.intel.com> References: <1482312295-13373-1-git-send-email-yu.c.chen@intel.com> <3581108.InxQuoaF8Q@aspire.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3581108.InxQuoaF8Q@aspire.rjw.lan> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 22, 2016 at 02:19:22AM +0100, Rafael J. Wysocki wrote: > [CC Mika and linux-acpi] > > On Wednesday, December 21, 2016 05:24:55 PM Chen Yu wrote: > > Sometimes we have the following error message: > > platform MSFT0101:00: failed to claim resource 1 > > acpi MSFT0101:00: platform device creation failed: -16 > > But there is not enough information to figure out which resource range > > failed to claim. > > > > Thus print the resource range at first-place thus /proc/iomem or > > ioports should tell us who already claimed this resource, then > > the driver bug or incorrect resource assignment which is running > > into this conflict can be diagnosed: > > platform MSFT0101:00: failed to claim resource 1: [mem 0xfed40000-0xfed40fff] > > acpi MSFT0101:00: platform device creation failed: -16 > > > > Suggested-by: Len Brown > > Reported-by: Wendy Wang > > Signed-off-by: Chen Yu > > --- > > drivers/base/platform.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c > > index c4af003..22a6430 100644 > > --- a/drivers/base/platform.c > > +++ b/drivers/base/platform.c > > @@ -396,7 +396,7 @@ int platform_device_add(struct platform_device *pdev) > > } > > > > if (p && insert_resource(p, r)) { > > - dev_err(&pdev->dev, "failed to claim resource %d\n", i); > > + dev_err(&pdev->dev, "failed to claim resource %d: %pR\n", i, r); > > Do we still need the resource number? It may still be useful. For example some BIOSes fill MMIO resources based on variables in memory in which case the resource in DSDT is filled with zeroes when disassembled. With the number you can find out the right MMIO resource. Either way, this is a good change. I had it on my list as well but never got a chance to write a patch. Reviewed-by: Mika Westerberg