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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox