On Friday, October 10, 2014 at 04:35:11 AM, Simon Glass wrote:
Hi,
Hi,
On 9 October 2014 20:26, Fabio Estevam feste...@gmail.com wrote:
On Thu, Oct 9, 2014 at 11:23 PM, Marek Vasut ma...@denx.de wrote:
What about [1], this is where we can source the more exotic toolchains
from, can we
Hi,
On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote:
In some cases we really want to move forward with a deregister, add a force
parameter to allow this, and replace the dev with a nulldev in this case.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
common/stdio.c
On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote:
Hi,
On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote:
In some cases we really want to move forward with a deregister, add a
force parameter to allow this, and replace the dev with a nulldev in
this case.
Hi Marek,
On 9 October 2014 09:12, Marek Vasut ma...@denx.de wrote:
On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote:
Hi,
On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote:
In some cases we really want to move forward with a deregister, add a
force
On Thu, Oct 09, 2014 at 05:12:03PM +0200, Marek Vasut wrote:
On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote:
Hi,
On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote:
In some cases we really want to move forward with a deregister, add a
force parameter
On Thursday, October 09, 2014 at 06:14:11 PM, Simon Glass wrote:
Hi Marek,
On 9 October 2014 09:12, Marek Vasut ma...@denx.de wrote:
On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote:
Hi,
On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote:
In some
Hi Tom,
On 9 October 2014 10:23, Tom Rini tr...@ti.com wrote:
On Thu, Oct 09, 2014 at 05:12:03PM +0200, Marek Vasut wrote:
On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote:
Hi,
On 20 September 2014 08:54, Hans de Goede hdego...@redhat.com wrote:
In some cases we really
Hi Marek,
On 9 October 2014 10:27, Marek Vasut ma...@denx.de wrote:
On Thursday, October 09, 2014 at 06:14:11 PM, Simon Glass wrote:
Hi Marek,
On 9 October 2014 09:12, Marek Vasut ma...@denx.de wrote:
On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote:
Hi,
On 20
On Thu, Oct 09, 2014 at 11:03:02AM -0600, Simon Glass wrote:
Hi Tom,
On 9 October 2014 10:23, Tom Rini tr...@ti.com wrote:
On Thu, Oct 09, 2014 at 05:12:03PM +0200, Marek Vasut wrote:
On Thursday, October 09, 2014 at 08:18:14 AM, Simon Glass wrote:
Hi,
On 20 September 2014 08:54,
On Thursday, October 09, 2014 at 07:03:42 PM, Simon Glass wrote:
Hi Marek,
On 9 October 2014 10:27, Marek Vasut ma...@denx.de wrote:
On Thursday, October 09, 2014 at 06:14:11 PM, Simon Glass wrote:
Hi Marek,
On 9 October 2014 09:12, Marek Vasut ma...@denx.de wrote:
On Thursday,
Hi Marek,
On 9 October 2014 11:32, Marek Vasut ma...@denx.de wrote:
On Thursday, October 09, 2014 at 07:03:42 PM, Simon Glass wrote:
Hi Marek,
On 9 October 2014 10:27, Marek Vasut ma...@denx.de wrote:
On Thursday, October 09, 2014 at 06:14:11 PM, Simon Glass wrote:
Hi Marek,
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
Hi Marek,
On 9 October 2014 17:59, Marek Vasut ma...@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
Hi Marek,
On Thu, Oct 9, 2014 at 8:59 PM, Marek Vasut ma...@denx.de wrote:
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
Hi,
On 9 October 2014 20:06, Fabio Estevam feste...@gmail.com wrote:
Hi Marek,
On Thu, Oct 9, 2014 at 8:59 PM, Marek Vasut ma...@denx.de wrote:
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
On Thu, Oct 9, 2014 at 11:07 PM, Simon Glass s...@chromium.org wrote:
It's not really the builder that is the problem - we have one. It's
all the different toolchains that no one knows about. I still can't
build all the boards successfully.
Aren't all the toolchains U-boot need included in
On Friday, October 10, 2014 at 04:00:00 AM, Simon Glass wrote:
Hi Marek,
On 9 October 2014 17:59, Marek Vasut ma...@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
On Thu, Oct 9, 2014 at 11:23 PM, Marek Vasut ma...@denx.de wrote:
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/
Hi,
On 9 October 2014 20:26, Fabio Estevam feste...@gmail.com wrote:
On Thu, Oct 9, 2014 at 11:23 PM, Marek Vasut ma...@denx.de wrote:
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
Dear Hans de Goede,
Typographical error here:
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
at at -197,7 +197,7 at at static int serial_pre_remove(struct
udevice *dev)
#ifdef CONFIG_SYS_STDIO_DEREGISTER
struct serial_dev_priv *upriv =
In some cases we really want to move forward with a deregister, add a force
parameter to allow this, and replace the dev with a nulldev in this case.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
common/stdio.c | 13 ++---
common/usb_kbd.c | 2 +-
21 matches
Mail list logo
