ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: Mark Brown <broonie@kernel.org>
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 22:45:51 +0530	[thread overview]
Message-ID: <20160727171551.GE9681@localhost> (raw)
In-Reply-To: <20160727142221.GK11806@sirena.org.uk>

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

On Wed, Jul 27, 2016 at 03:22:21PM +0100, Mark Brown wrote:
> 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.

That's right, this is problematic mostly with older code and for ARMv5 and
below. As I said later code & sub-ARCHs seems to be well covered with
current multi-vx-configs...

> > 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.

That is a valid point as well. This seems better suggestion to me.

-- 
~Vinod

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-07-27 17:08 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
2016-07-27 17:15           ` Vinod Koul [this message]
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=20160727171551.GE9681@localhost \
    --to=vinod.koul@intel.com \
    --cc=airlied@linux.ie \
    --cc=broonie@kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=torvalds@linux-foundation.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