linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: s.nawrocki@samsung.com (Sylwester Nawrocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/5] exynos4-is: Remove requirement for "simple-bus" compatible
Date: Thu, 17 Apr 2014 11:29:00 +0200	[thread overview]
Message-ID: <534F9EDC.4030202@samsung.com> (raw)
In-Reply-To: <CAL_JsqKH8o-0H4+2jv-6xh96Twh9UCXZV+LtmiUGHJmhUxCUVA@mail.gmail.com>

(restoring the Cc list I cleared accidentally in previous reply)

On 16/04/14 21:29, Rob Herring wrote:
> On Wed, Apr 16, 2014 at 12:19 PM, Sylwester Nawrocki
> <s.nawrocki@samsung.com> wrote:
>> On 16/04/14 17:34, Rob Herring wrote:
>>> On Tue, Apr 15, 2014 at 12:34 PM, Sylwester Nawrocki
>>> <s.nawrocki@samsung.com> wrote:
>>>>> This patch makes the driver instantiating its child devices itself,
>>>>> rather than relying on an OS to instantiate devices as children
>>>>> of "simple-bus". This removes an incorrect usage of "simple-bus"
>>>>> compatible.
>>>
>>> Good, but why can't you use of_platform_populate with the root being
>>> the "samsung,fimc" node? The code to instantiate the devices belongs
>>> in the core OF code.
>>
>> As I mentioned in other thread, I couldn't see anything like
>> of_platform_unpopulate(), which would allow to destroy any created
>> devices. I can't have of_platform_populate() called as last thing
>> in probe() as some drivers do, so at least deferred probe works.
>> Anyway, it wouldn't be a solution since on a driver removal the
>> created devices must be unregistered.
> 
> I think the deferred probe will get fixed in 3.16, but I'm not
> following how deferred probe is relevant here.

What I meant was that when something fails in the middle of probe() 
callback and of_platform_populate() was already called any devices 
created by it must be destroyed before returning an error from probe().
And some drivers seem to never free their devices created by 
of_platform_populate().

>> I read through thread [1] and I didn't immediately have an idea how
>> to fix the core OF code. So I thought I'd come up with this partial
>> solution.
>>
>> I was wondering if creating functions like of_platform_device_delete(),
>> of_amba_device_delete() and a function that would walk device tree and
>> call them would be a way to go ? I could spend some time on that, any
>> suggestions would be appreciated.
> 
> I need to look at the other removal case, but perhaps the way you did
> using children of the struct device parent is the right way. I'm fine
> with that, but I just want to see this in the core code.

All right, I'll have a closer look then if it can be done that way.
 
> Rob
> 
>>
>> --
>> Regards,
>> Sylwester
>>
>> [1] http://www.spinics.net/lists/linux-omap/msg94484.html

--
Thanks,
Sylwester

  parent reply	other threads:[~2014-04-17  9:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 17:34 [PATCH 0/5] Exynos4 SoC camera subsystem driver cleanups Sylwester Nawrocki
2014-04-15 17:34 ` [PATCH 1/5] ARM: S5PV210: Remove camera support from mach-goni.c Sylwester Nawrocki
2014-05-02  6:07   ` Kukjin Kim
2014-05-08 16:09     ` Sylwester Nawrocki
2014-04-15 17:34 ` [PATCH 2/5] exynos4-is: Fix compilation for !CONFIG_COMMON_CLK Sylwester Nawrocki
2014-04-15 17:34 ` [PATCH 3/5] exynos4-is: Remove support for non-dt platforms Sylwester Nawrocki
2014-04-15 17:34 ` [PATCH 4/5] exynos4-is: Remove requirement for "simple-bus" compatible Sylwester Nawrocki
2014-04-16 15:34   ` Rob Herring
     [not found]     ` <534EBB88.9020109@samsung.com>
     [not found]       ` <CAL_JsqKH8o-0H4+2jv-6xh96Twh9UCXZV+LtmiUGHJmhUxCUVA@mail.gmail.com>
2014-04-17  9:29         ` Sylwester Nawrocki [this message]
2014-04-15 17:34 ` [PATCH 5/5] ARM: dts: exynos4: Remove simple-bus compatible from camera subsystem nodes Sylwester Nawrocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=534F9EDC.4030202@samsung.com \
    --to=s.nawrocki@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).