public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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

      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