linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/7] drm/exynos: add super device support
Date: Sat, 05 Apr 2014 20:31:15 +0200	[thread overview]
Message-ID: <53404BF3.2010409@gmail.com> (raw)
In-Reply-To: <20140405182423.GL7528@n2100.arm.linux.org.uk>



On 05.04.2014 20:24, Russell King - ARM Linux wrote:
> On Sat, Apr 05, 2014 at 07:32:50PM +0200, Tomasz Figa wrote:
>> Not exactly. The approach we found does mostly the same as componentized
>> subsystem framework but without _any_ extra data in Device Tree. Just
>> based on the list of subsystem sub-drivers that is already available to
>> the master driver.
>
> The existing approach is fundamentally broken.  Yes, your solution may
> work for the probing case, but have you tried unbinding any of your
> sub-drivers?
>
>  From what I can see, that causes a kernel oops for one very simple reason -
> you destroy stuff while it's still in use.  Let's look at an example:
>
> struct platform_driver ipp_driver = {
>          .probe          = ipp_probe,
>          .remove         = ipp_remove,
>          .driver         = {
>                  .name   = "exynos-drm-ipp",
>                  .owner  = THIS_MODULE,
>                  .pm     = &ipp_pm_ops,
>          },
> };
>
> static int ipp_remove(struct platform_device *pdev)
> {
>          struct ipp_context *ctx = platform_get_drvdata(pdev);
>
>          /* unregister sub driver */
>          exynos_drm_subdrv_unregister(&ctx->subdrv);
>
>          /* remove,destroy ipp idr */
>          idr_destroy(&ctx->ipp_idr);
>          idr_destroy(&ctx->prop_idr);
>
>          mutex_destroy(&ctx->ipp_lock);
>          mutex_destroy(&ctx->prop_lock);
>
>          /* destroy command, event work queue */
>          destroy_workqueue(ctx->cmd_workq);
>          destroy_workqueue(ctx->event_workq);
>
>          return 0;
> }
>
> int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
> {
>          if (!subdrv)
>                  return -EINVAL;
>
>          list_del(&subdrv->list);
>
>          return 0;
> }
>
> Oh dear, that destroys a whole pile of resources which could already
> be in use without telling anything that it's about to do that.
>
> I'm sure if I continue looking at the exynos stuff, it'll show similar
> crap all over the place.
>
> What you have now in mainline is not a solution.  It's a crappy bodge.
>

Undoubtedly. Nobody here is trying to state the opposite.

Maybe my words have been misinterpreted, but all I'm suggesting here is 
that there is no need to add any new data to DT to solve the same issue 
to the same extent as componentized subsystem framework, at least in 
Exynos case.

Best regards,
Tomasz

  reply	other threads:[~2014-04-05 18:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1396355882-17010-1-git-send-email-inki.dae@samsung.com>
     [not found] ` <1396355882-17010-2-git-send-email-inki.dae@samsung.com>
     [not found]   ` <533EB9C6.80302@samsung.com>
     [not found]     ` <CAAQKjZPbzb+qvJA5y+Kco9BRv4j3iVatM_0bd+ugyuVZUbfFFg@mail.gmail.com>
2014-04-05 17:32       ` [PATCH v2 1/7] drm/exynos: add super device support Tomasz Figa
2014-04-05 18:24         ` Russell King - ARM Linux
2014-04-05 18:31           ` Tomasz Figa [this message]
2014-04-05 18:52             ` Russell King - ARM Linux
2014-04-05 19:01               ` Tomasz Figa
2014-04-06  4:21             ` Inki Dae
2014-04-06  8:47               ` Russell King - ARM Linux
2014-04-06  9:38                 ` Inki Dae
2014-04-06  3:15         ` Inki Dae
2014-04-07 14:18           ` Andrzej Hajda
2014-04-07 14:24             ` Tomasz Figa
2014-04-07 15:16             ` Inki Dae
2014-04-07 15:40               ` Tomasz Figa
2014-04-08  8:37                 ` Inki Dae

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=53404BF3.2010409@gmail.com \
    --to=tomasz.figa@gmail.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).