[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150604052536.DA31EC40548@trevor.secretlab.ca>
Date: Thu, 04 Jun 2015 14:25:36 +0900
From: Grant Likely <grant.likely@...aro.org>
To: Rob Herring <robherring2@...il.com>,
Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
Cc: Rob Herring <robh+dt@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Vivek Goyal <vgoyal@...hat.com>,
Jakub Sitnicki <jsitnicki@...il.com>,
Mike Travis <travis@....com>,
Jiang Liu <jiang.liu@...ux.intel.com>,
Thierry Reding <treding@...dia.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2 v2] of/platform: Use platform_device interface
On Tue, 21 Apr 2015 18:01:00 -0500
, Rob Herring <robherring2@...il.com>
wrote:
> On Tue, Apr 21, 2015 at 4:09 PM, Ricardo Ribalda Delgado
> <ricardo.ribalda@...il.com> wrote:
> > Hello Rob
> >
> > On Tue, Apr 21, 2015 at 10:13 PM, Rob Herring <robherring2@...il.com> wrote:
> >> On Tue, Apr 21, 2015 at 3:25 AM, Ricardo Ribalda Delgado
> >> <ricardo.ribalda@...il.com> wrote:
> >>> of_platform_device_create_pdata() was using of_device_add() to create
> >>> the devices, but of_platform_device_destroy was using
> >>> of_platform_device_destroy().
> >>>
> >>> of_device_add(), do not call insert_resource(), which initializes the
> >>> parent field of the resource structure, needed by release_resource(),
> >>> called by of_platform_device_destroy().
> >>
> >> This is because some DTs have overlapping resources and doing this
> >> would break things. If you look at the git history, this was fixed and
> >> then reverted by Grant.
> >
> > I cannot find that commit sorry, could you give me the hash or a link
> > to the mailing list?
> >
> > ricardo@...ix:~/linux$ git shortlog drivers/of/platform.c | grep -i Revert
> > Revert "drivers: of: add initialization code for dma reserved memory"
>
> commit 02bbde7849e68e193cefaa1885fe0df0f03c9fcd
> Author: Grant Likely <grant.likely@...retlab.ca>
> Date: Sun Feb 17 20:03:27 2013 +0000
>
> Revert "of: use platform_device_add"
>
> This reverts commit aac73f34542bc7ae4317928d2eabfeb21d247323. That
> commit causes two kinds of breakage; it breaks registration of AMBA
> devices when one of the parent nodes already contains overlapping
> resource regions, and it breaks calls to request_region() by device
> drivers in certain conditions where there are overlapping memory
> regions. Both of these problems can probably be fixed, but it is better
> to back out the commit and get a proper fix designed before trying again.
>
> Signed-off-by: Grant Likely <grant.likely@...retlab.ca>
>
> >
> >
> > To give a litte context to this patch, the issue started with this
> > conversaion with Bjorn:
> > https://lkml.org/lkml/2015/4/20/435
> >
> >
> > What we have today is also wrong, it leads to a null pointer deference
> > (and therefore a whole crash).
> >
> > If we cannot use platform_device_add, then we cannot use
> > platform_device_destroy :)
> >
> > Shall I prepare a patch replacing platform_device_destroy()?
>
> Perhaps we make inserting resource failure non-fatal so by default we
> can have resources inserted but not break the cases Grant mentioned.
> Ideally we want to not have new platforms with overlapping resources
> in the DT.
I think I tried that too and then ran in to a problem where drivers will
fail if a different device 'owns' the resource.
For example, if device-a and device-b have overlapping regions, device-a
gets registered first and claims the region. device-b tries to claim the
region, fails, but is allowed to continue anyway. When driver-b tries to
bind to device-b, and does a request_resource(), it will fail because
device-a already owns it. I don't have a good solution for that other
than to completely disable insert_resource() when using devicetree.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists