From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/8] drm: msm: module rework
Date: Mon, 22 Feb 2016 23:44:09 +0100 [thread overview]
Message-ID: <2809632.WiXCV6JuAB@wuerfel> (raw)
In-Reply-To: <CAF6AEGuYQqsH9TEoc-_cgMRNRvB99SveTqW3gSwJJvsvhaqNmw@mail.gmail.com>
On Monday 22 February 2016 17:36:36 Rob Clark wrote:
> On Mon, Feb 22, 2016 at 4:08 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > I saw some regressions on today's Linux-next kernel after
> > the Makefiles got reworked and tried to come up with a quick
> > fix. This ended up taking much longer, but the new version should
> > be cleaner and I no longer get any build errors in this
> > driver.
>
> fyi, for the time being, I've already kicked out the kconfig/makefile
> splitup patches..
>
> I'll go ahead and pull in the hdmi symbol rename patch, since that is
> a sane thing to do.
Ok, thanks
> I'm less sure about splitting things up into separate .ko's.
I think it's generally a good idea to split it up like that, though
it could be taken a little further. Having one .ko file per
platform_driver seems to be a very sensible split here, the
main advantage being that you enforce a strict layering between
the subdrivers.
> And I think having the .ko name not match the drm
> driver name (ie. what is passed in to drmOpen() in userspace) would
> cause issues since libdrm could try to modprobe $drivername.ko. (I
> *think* that only matters in the non-udev case? Which is at least not
> a common case, but breaking userspace is breaking userspace...)
Ah, I see. Yes, that is unfortunate, but patch 2 then definitely has
to be dropped even if you decide to take the others.
With udev, the autoloading purely depends on the MODULE_DEVICE_TABLE
in the top module, which should work fine, and without patch 2, all
the other drivers get loaded automatically when the main driver
gets probed.
Arnd
prev parent reply other threads:[~2016-02-22 22:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 21:08 [PATCH 0/8] drm: msm: module rework Arnd Bergmann
2016-02-22 21:08 ` [PATCH 1/8] drm: msm: rename hdmi symbols Arnd Bergmann
2016-02-22 21:08 ` [PATCH 2/8] drm: msm: rename module Arnd Bergmann
2016-02-22 21:08 ` [PATCH 3/8] drm: msm: split out fence and iotrace modules Arnd Bergmann
2016-02-22 21:08 ` [PATCH 4/8] drm: msm: split out GEM code into helper module Arnd Bergmann
2016-02-22 21:08 ` [PATCH 5/8] drm: msm: move DSI into separate module Arnd Bergmann
2016-02-22 21:08 ` [PATCH 6/8] drm: msm: move EDP " Arnd Bergmann
2016-02-22 21:08 ` [PATCH 7/8] drm: msm: move HDMI " Arnd Bergmann
2016-02-22 21:08 ` [PATCH 8/8] drm: msm: separate out module driver registration Arnd Bergmann
2016-02-22 22:36 ` [PATCH 0/8] drm: msm: module rework Rob Clark
2016-02-22 22:44 ` Arnd Bergmann [this message]
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=2809632.WiXCV6JuAB@wuerfel \
--to=arnd@arndb.de \
--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