From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/7] drm/exynos: add super device support
Date: Sat, 5 Apr 2014 19:24:23 +0100 [thread overview]
Message-ID: <20140405182423.GL7528@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <53403E42.1010403@gmail.com>
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.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
next prev parent reply other threads:[~2014-04-05 18:24 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 [this message]
2014-04-05 18:31 ` Tomasz Figa
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=20140405182423.GL7528@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--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).