ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Vinod Koul <vinod.koul@intel.com>
Cc: ksummit-discuss@lists.linuxfoundation.org,
	Dave Airlie <airlied@linux.ie>,
	"Nikula, Jani" <jani.nikula@linux.intel.com>,
	Grant Likely <grant.likely@linaro.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models
Date: Wed, 27 Jul 2016 15:22:21 +0100	[thread overview]
Message-ID: <20160727142221.GK11806@sirena.org.uk> (raw)
In-Reply-To: <20160727125751.GC9681@localhost>

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

On Wed, Jul 27, 2016 at 06:27:51PM +0530, Vinod Koul wrote:
> On Wed, Jul 27, 2016 at 09:53:24AM +0200, Arnd Bergmann wrote:

> > We should be at the point where an 'allmodconfig' build on ARM
> > gets you most of the drivers and builds without warnings (using
> > gcc-4.9 or higher).

> The problem is drivers depend on various ARM sub arch's. That is the
> sole reason why I have multiple configs now.

That shouldn't be the case at least for any new code, things should at
least build OK with an || COMPILE_TEST normally.  Old code may need
fixing up for this.

> Which brings me to another problem :-) why should individual drivers
> depend on ARM sub arch's. Depends on ARM, yes. First look at code tells
> me they shouldn't!, probably sometime back that was true, but I don't
> think that should be the case now, ofcourse you would know better!

The dependencies are there to improve UX when people are configuring
their kernels - it stops them being asked about hardware they can't
possibly have in their system.  If there's no build time reason for it
then it should be (ARCH_FOO || COMPILE_TEST) so people can do build
tests.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-07-27 14:22 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-20 12:11 Daniel Vetter
2016-07-22 20:02 ` Darren Hart
2016-07-25  5:57   ` Daniel Vetter
2016-07-26 16:22     ` Darren Hart
2016-07-28 22:13       ` Bjorn Helgaas
2016-07-26 16:45 ` Olof Johansson
2016-07-27  3:04   ` Vinod Koul
2016-07-27  5:34     ` Wolfram Sang
2016-07-27  7:53     ` Arnd Bergmann
2016-07-27 12:57       ` Vinod Koul
2016-07-27 14:22         ` Mark Brown [this message]
2016-07-27 17:15           ` Vinod Koul
2016-07-28  8:44             ` Arnd Bergmann
2016-07-28 23:48               ` Alexandre Belloni
2016-07-29  0:06                 ` Stephen Rothwell
2016-07-31 17:57               ` Vinod Koul
2016-08-01  6:56                 ` Arnd Bergmann
2016-08-01  7:36                   ` Laurent Pinchart
2016-08-01 14:10                     ` Arnd Bergmann
2016-08-02  4:46                       ` Vinod Koul
2016-08-02  6:48                         ` Peter Ujfalusi
2016-08-02  7:27                           ` Arnd Bergmann
2016-08-02  8:29                             ` Peter Ujfalusi
2016-08-02  8:33                           ` Laurent Pinchart
2016-08-02  9:49                             ` Tony Lindgren
2016-08-02  8:41                           ` Russell King - ARM Linux
2016-08-02  9:21                             ` Laurent Pinchart
2016-08-02  9:27                               ` Russell King - ARM Linux
2016-09-02 10:46                   ` Vinod Koul
2016-09-02 17:25                     ` Linus Torvalds
2016-09-02 20:06                       ` Arnd Bergmann
2016-09-02 20:26                         ` Linus Torvalds
2016-09-02 20:43                           ` Julia Lawall
2016-09-02 20:50                             ` Linus Torvalds
2016-09-02 22:16                           ` Benjamin Herrenschmidt
2016-09-03 14:02                           ` Michael Ellerman
2016-09-02 23:35                         ` Arnd Bergmann
2016-09-04 17:45                       ` Geert Uytterhoeven
2016-09-04 17:59                         ` Linus Torvalds
2016-09-03  0:07                     ` Mark Brown
2016-07-27 12:59     ` Daniel Vetter
2016-07-27 13:03   ` Daniel Vetter
2016-08-01 14:42 ` Jani Nikula
2016-09-07  5:03 Leon Romanovsky

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=20160727142221.GK11806@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=airlied@linux.ie \
    --cc=grant.likely@linaro.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vinod.koul@intel.com \
    /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