Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755195AbbFLOBR (ORCPT ); Fri, 12 Jun 2015 10:01:17 -0400 Received: from mail-la0-f54.google.com ([209.85.215.54]:34778 "EHLO mail-la0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754923AbbFLOBP (ORCPT ); Fri, 12 Jun 2015 10:01:15 -0400 MIME-Version: 1.0 In-Reply-To: <1433686811-12303-3-git-send-email-grant.likely@linaro.org> References: <1433686811-12303-1-git-send-email-grant.likely@linaro.org> <1433686811-12303-3-git-send-email-grant.likely@linaro.org> From: Ricardo Ribalda Delgado Date: Fri, 12 Jun 2015 16:00:53 +0200 Message-ID: Subject: Re: [PATCH 2/2] drivercore: Fix unregistration path of platform devices To: Grant Likely Cc: "devicetree@vger.kernel.org" , LKML , Pantelis Antoniou , Wolfram Sang , Rob Herring , Greg Kroah-Hartman Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3435 Lines: 90 Hello Tested-by: Ricardo Ribalda Delgado Some runtime warnings, but no oops [ 46.348911] Trying to free nonexistent resource <00000000b0050000-00000000b005ffff> [ 46.351979] Trying to free nonexistent resource <00000000b9000000-00000000b900ffff> [ 46.351993] Trying to free nonexistent resource <00000000b0000000-00000000b000ffff> [ 46.352003] Trying to free nonexistent resource <00000000b9000000-00000000b900ffff> [ 46.352009] Trying to free nonexistent resource <00000000b0000000-00000000b000ffff> Thanks! On Sun, Jun 7, 2015 at 4:20 PM, Grant Likely wrote: > The unregister path of platform_device is broken. On registration, it > will register all resources with either a parent already set, or > type==IORESOURCE_{IO,MEM}. However, on unregister it will release > everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There > are also cases where resources don't get registered in the first place, > like with devices created by of_platform_populate()*. > > Fix the unregister path to be symmetrical with the register path by > checking the parent pointer instead of the type field to decide which > resources to unregister. This is safe because the upshot of the > registration path algorithm is that registered resources have a parent > pointer, and non-registered resources do not. > > * It can be argued that of_platform_populate() should be registering > it's resources, and they argument has some merit. However, there are > quite a few platforms that end up broken if we try to do that due to > overlapping resources in the device tree. Until that is fixed, we need > to solve the immediate problem. > > Cc: Pantelis Antoniou > Cc: Wolfram Sang > Cc: Rob Herring > Cc: Greg Kroah-Hartman > Cc: Ricardo Ribalda Delgado > Signed-off-by: Grant Likely > --- > drivers/base/platform.c | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c > index ebf034b97278..7403de94832c 100644 > --- a/drivers/base/platform.c > +++ b/drivers/base/platform.c > @@ -375,9 +375,7 @@ int platform_device_add(struct platform_device *pdev) > > while (--i >= 0) { > struct resource *r = &pdev->resource[i]; > - unsigned long type = resource_type(r); > - > - if (type == IORESOURCE_MEM || type == IORESOURCE_IO) > + if (r->parent) > release_resource(r); > } > > @@ -408,9 +406,7 @@ void platform_device_del(struct platform_device *pdev) > > for (i = 0; i < pdev->num_resources; i++) { > struct resource *r = &pdev->resource[i]; > - unsigned long type = resource_type(r); > - > - if (type == IORESOURCE_MEM || type == IORESOURCE_IO) > + if (r->parent) > release_resource(r); > } > } > -- > 2.1.4 > -- Ricardo Ribalda -- 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/