All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Nelson <eric.nelson@boundarydevices.com>
To: "Eric Bénard" <eric@eukrea.com>
Cc: "meta-freescale@yoctoproject.org"
	<meta-freescale@yoctoproject.org>,
	Otavio Salvador <otavio@ossystems.com.br>
Subject: Re: [meta-fsl-arm-extra][PATCH] linux-boundary: enable some PCIe drivers
Date: Wed, 15 May 2013 07:16:05 -0700	[thread overview]
Message-ID: <519398A5.9050501@boundarydevices.com> (raw)
In-Reply-To: <20130515095135.231262d1@e6520eb>

On 05/15/2013 12:51 AM, Eric Bénard wrote:
> Hi Otavio,
>
> Le Tue, 14 May 2013 17:22:35 -0300,
> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>> Can you take a look in Eric Benard patch?
>>
>> I think it'd be good to apply it in Boundary's GIT tree and sync it in
>> meta-fsl-arm.
>>
> this defconfig belongs to meta-fsl-arm-extra, not to Boundary's GIT
> tree.
>

Hi Eric and Otavio,

In general, I agree with Eric that the defconfig should belong to the
meta-fsl-arm-extra project, since there are (and should be) userspace
implications.

That said, I'm not really sure where Eric's headed by including somewhat
arbitrary PCIe devices. I'm not aware that these are commonly used and
could begin a slow march to allyesconfig. Do other users really want
to include support for PCIe 8250's, or is this just something important
for a project of yours?

I'm also hesitant to say that bringing in our defconfig is crucial.
There are important bits, like the inclusion of NAPI for ethernet
and single-touch for various multi-touch controllers, but there's
also likely some cruft that we pulled in from other Freescale designs
and that isn't useful in general.

Here's a good case in point:
	https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.0.35_1.1.1/arch/arm/configs/nitrogen6x_defconfig#L136

We're including a light sensor that isn't present on our boards.

We're also including some PCIe drivers for things we happen
to be working on:
	https://github.com/boundarydevices/linux-imx6/commit/b6e4be8783d66e288bda17d18281bdcb2d95be62

My sense is that we all have particular needs for the kernel
configuration, and that one-size really doesn't fit all.

We'll be re-basing our kernel on the new 4.0.0 release from
Freescale very soon. For my part, I'll try to clean up our
defconfig in the process.

	https://community.freescale.com/docs/DOC-94809

Regards,


Eric


  parent reply	other threads:[~2013-05-15 14:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-14 14:02 [meta-fsl-arm-extra][PATCH] linux-boundary: enable some PCIe drivers Eric Bénard
2013-05-14 14:08 ` Fabio Estevam
2013-05-14 14:20   ` Eric Bénard
2013-05-14 20:22     ` Otavio Salvador
2013-05-15  7:51       ` Eric Bénard
2013-05-15 11:48         ` Otavio Salvador
2013-05-15 14:16         ` Eric Nelson [this message]
2013-05-15 14:48           ` Eric Bénard
2013-05-15 16:55             ` Eric Nelson
2013-05-15 17:08               ` Otavio Salvador

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=519398A5.9050501@boundarydevices.com \
    --to=eric.nelson@boundarydevices.com \
    --cc=eric@eukrea.com \
    --cc=meta-freescale@yoctoproject.org \
    --cc=otavio@ossystems.com.br \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.