All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister
Date: Fri, 10 Oct 2014 04:23:02 +0200	[thread overview]
Message-ID: <201410100423.02346.marex@denx.de> (raw)
In-Reply-To: <CAPnjgZ2-fyKVOn0VQmgjXmeRsKS6+k7BYzhkyiXTBUi88RBnXA@mail.gmail.com>

On Friday, October 10, 2014 at 04:00:00 AM, Simon Glass wrote:
> Hi Marek,
> 
> On 9 October 2014 17:59, Marek Vasut <marex@denx.de> wrote:
> > On Thursday, October 09, 2014 at 08:04:29 PM, Simon Glass wrote:
> >> Hi Marek,
> > 
> > Hi Simon,
> > 
> > [..]
> > 
> >> > I mean more continuous integration (build testing) of the code before
> >> > a PR is submitted to the ML. Right now, we all do our own thing when
> >> > it comes to testing before PR, but it would be nice to have one easy
> >> > way of doing the build testing before submitting the PR, don't you
> >> > think ? This might apply to Linux too.
> >> 
> >> Sure it would be useful. Before submitting my pull request I get all the
> >> patches in a branch and run:
> >> 
> >> ./tools/buildman/buildman -b x86-push
> >> 
> >> This checks every commit for every board that I build, and gives me good
> >> confidence that no patch introduces new breakages.
> > 
> > I agree that buildman solves the CI part nicely, but we also have the
> > part where one has to install the myriad of toolchains for all the
> > architectures to be able to do the compile testing. I wonder if this
> > cannot be made easy in some way -- maybe through a re-usable docker
> > image with all the parts in it already.
> 
> It would be create if we could download all the toolchains from one
> place. Maybe we need a toolchain maintainer?

What about [1], this is where we can source the more exotic toolchains from,
can we not? I think it was even you who pointed me to this site and it really
is a nice one ;-)

[1] https://www.kernel.org/pub/tools/crosstool/

Best regards,
Marek Vasut

  reply	other threads:[~2014-10-10  2:23 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-20 14:54 [U-Boot] [PATCH fix for v2014.10 0/5] USB keyboard: don't crash on "usb reset" Hans de Goede
2014-09-20 14:54 ` [U-Boot] [PATCH fix for v2014.10 1/5] usb: kbd: Do not treat -ENODEV as an error for usb_kbd_deregister Hans de Goede
2014-09-20 14:54 ` [U-Boot] [PATCH fix for v2014.10 2/5] usb: kbd: On a "usb reset" call usb_kbd_deregister() before calling usb_stop() Hans de Goede
2014-09-22 12:01   ` Marek Vasut
2014-09-23  9:10     ` Hans de Goede
2014-09-23 12:15       ` Marek Vasut
2014-09-23 12:51         ` Hans de Goede
2014-09-20 14:54 ` [U-Boot] [PATCH fix for v2014.10 3/5] usb: kbd: Remove check for already being registered Hans de Goede
2014-09-20 14:54 ` [U-Boot] [PATCH fix for v2014.10 4/5] stdio: Add force parameter to stdio_deregister Hans de Goede
2014-10-09  2:18   ` Rommel Custodio
2014-10-09  6:18   ` Simon Glass
2014-10-09 15:12     ` Marek Vasut
2014-10-09 16:14       ` Simon Glass
2014-10-09 16:27         ` Marek Vasut
2014-10-09 17:03           ` Simon Glass
2014-10-09 17:32             ` Marek Vasut
2014-10-09 18:04               ` Simon Glass
2014-10-09 23:59                 ` Marek Vasut
2014-10-10  2:00                   ` Simon Glass
2014-10-10  2:23                     ` Marek Vasut [this message]
2014-10-10  2:26                       ` Fabio Estevam
2014-10-10  2:35                         ` Simon Glass
2014-10-10 10:42                           ` Marek Vasut
2014-10-10  2:06                   ` Fabio Estevam
2014-10-10  2:07                     ` Simon Glass
2014-10-10  2:16                       ` Fabio Estevam
2014-10-09 16:23       ` Tom Rini
2014-10-09 17:03         ` Simon Glass
2014-10-09 17:26           ` Tom Rini
2014-09-20 14:54 ` [U-Boot] [PATCH fix for v2014.10 5/5] usb: kbd: Allow "usb reset" to continue when an usb kbd is used Hans de Goede
2014-09-21 10:26 ` [U-Boot] [PATCH fix for v2014.10 0/5] USB keyboard: don't crash on "usb reset" Marek Vasut

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=201410100423.02346.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /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.