Patchwork [U-Boot] Please pull u-boot-x86.git

login
register
mail settings
Submitter Simon Glass
Date Feb. 16, 2013, 12:14 a.m.
Message ID <CAPnjgZ2P6sBDXiwXW2TeCdjADMhkN5iNBGrpZbtvwMqUtYVVxA@mail.gmail.com>
Download mbox
Permalink /patch/220907/
State Rejected, archived
Delegated to: Tom Rini
Headers show

Pull-request

git://git.denx.de/u-boot-x86.git master

Comments

Simon Glass - Feb. 16, 2013, 12:14 a.m.
Hi Tom,

This series includes the sandbox map_sysmem() feature, and gets the
memory and hashing functions running on sandbox to allow testing/code
coverage. I have run it through buildman and it seems clean, with the
proviso that I don't have fully-working toolchains for all
architectures.


The following changes since commit 9f024f62e4604274a23213dcee30016092e32e7b:

  Merge branch 'fixes' of git://git.denx.de/u-boot-mips (2013-02-15
12:23:42 -0500)

are available in the git repository at:


  git://git.denx.de/u-boot-x86.git master

for you to fetch changes up to d76bd1c2d5e75db16b239bd2d4a642673974e250:

  sandbox: Allow hash functions to work correctly (2013-02-15 16:06:06 -0800)

----------------------------------------------------------------
Allen Martin (1):
      sandbox: fix compiler warning

Simon Glass (19):
      Tidy up error checking and fix bug in hash command
      Update print_buffer() to use const
      sandbox: Add un/map_sysmen() to deal with sandbox's ram_buf
      sandbox: Change memory commands to use map_physmem
      Split out the memory tests into separate functions
      Use common mtest iteration counting
      Fix mtest indenting
      Bring mtest putc() into common code
      Reduce casting in mtest
      Update set_working_fdt_addr() to use setenv_addr()
      common: Use new numeric setenv functions
      drivers: Use new numeric setenv functions
      net: Use new numeric setenv functions
      image: Use crc header file instead of C prototypes
      Roll crc32 into hash infrastructure
      sandbox: config: Enable hash functions and mtest
      Move CONFIG_SYS_MEMTEST_SCRATCH #ifdef to top of file
      sandbox: Update mtest to fix crashes
      sandbox: Allow hash functions to work correctly

Taylor Hutt (1):
      sandbox: Improve sandbox serial port keyboard interface

 README                        |   9 +
 arch/sandbox/config.mk        |   1 +
 arch/sandbox/cpu/os.c         |   8 +
 arch/sandbox/cpu/start.c      |   3 +
 arch/sandbox/include/asm/io.h |  10 +
 common/cmd_bootm.c            |  11 +-
 common/cmd_cbfs.c             |   4 +-
 common/cmd_cramfs.c           |   4 +-
 common/cmd_fdos.c             |   4 +-
 common/cmd_fdt.c              |  11 +-
 common/cmd_hash.c             |   4 +
 common/cmd_jffs2.c            |   4 +-
 common/cmd_load.c             |  12 +-
 common/cmd_mem.c              | 798 +++++++++++++++++++++---------------------
 common/cmd_mtdparts.c         |   4 +-
 common/cmd_nand.c             |  12 +-
 common/cmd_nvedit.c           |  11 +-
 common/cmd_reiser.c           |   4 +-
 common/cmd_setexpr.c          |  39 ++-
 common/cmd_unzip.c            |   4 +-
 common/cmd_ximg.c             |   7 +-
 common/cmd_zfs.c              |   3 +-
 common/cmd_zip.c              |   4 +-
 common/hash.c                 |  31 +-
 common/image.c                |   4 +-
 drivers/net/fm/fm.c           |   4 +-
 drivers/serial/sandbox.c      |  44 ++-
 fs/fs.c                       |   4 +-
 fs/ubifs/ubifs.c              |   4 +-
 include/common.h              |  29 +-
 include/configs/sandbox.h     |   9 +-
 include/hash.h                |   2 +-
 include/os.h                  |  10 +
 include/u-boot/crc.h          |  11 +
 lib/crc32.c                   |   9 +
 lib/display_options.c         |   3 +-
 net/net.c                     |   8 +-
 37 files changed, 615 insertions(+), 528 deletions(-)

Regards,
Simon
Wolfgang Denk - Feb. 17, 2013, 8:58 p.m.
Dear Simon Glass,

In message <CAPnjgZ2P6sBDXiwXW2TeCdjADMhkN5iNBGrpZbtvwMqUtYVVxA@mail.gmail.com> you wrote:
> Hi Tom,
> 
> This series includes the sandbox map_sysmem() feature, and gets the
> memory and hashing functions running on sandbox to allow testing/code
> coverage. I have run it through buildman and it seems clean, with the
> proviso that I don't have fully-working toolchains for all
> architectures.

NAK. It is not correct to push changes that affect global code
through a arch-specific custodian tree, especially if the submitter
of the patche(es) is identical to the custodian of the very tree, and
even more so if there have been not ANY independent Acked-by: or at
least Tested-by: messages.

This is NOT how the peer review process is supposed to work!!

Especially as a custodian you must not do such things.


Best regards,

Wolfgang Denk
Simon Glass - Feb. 17, 2013, 9:32 p.m.
Hi Wolfgang,

On Sun, Feb 17, 2013 at 12:58 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ2P6sBDXiwXW2TeCdjADMhkN5iNBGrpZbtvwMqUtYVVxA@mail.gmail.com> you wrote:
>> Hi Tom,
>>
>> This series includes the sandbox map_sysmem() feature, and gets the
>> memory and hashing functions running on sandbox to allow testing/code
>> coverage. I have run it through buildman and it seems clean, with the
>> proviso that I don't have fully-working toolchains for all
>> architectures.
>
> NAK. It is not correct to push changes that affect global code
> through a arch-specific custodian tree, especially if the submitter
> of the patche(es) is identical to the custodian of the very tree, and
> even more so if there have been not ANY independent Acked-by: or at
> least Tested-by: messages.
>
> This is NOT how the peer review process is supposed to work!!
>
> Especially as a custodian you must not do such things.

OK, I was not quite sure what to do, so may have misunderstood Tom's
instructions - there is a short thread here
http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/153342

I have created a patchwork bundle instead.

http://patchwork.ozlabs.org/bundle/sjg/sandbox-mem/

Only one patch was Acked, so it could certainly use a few more eyes.
However, it has been on the list for nearly two months, and I feel
that applying things too close to the next release doesn't give people
a lot of time to find problems.

Regards,
Simon

>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Pray to God, but keep rowing to shore. - Russian Proverb
Tom Rini - Feb. 18, 2013, 10:52 p.m.
On Sun, Feb 17, 2013 at 01:32:58PM -0800, Simon Glass wrote:
> Hi Wolfgang,
> 
> On Sun, Feb 17, 2013 at 12:58 PM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Simon Glass,
> >
> > In message <CAPnjgZ2P6sBDXiwXW2TeCdjADMhkN5iNBGrpZbtvwMqUtYVVxA@mail.gmail.com> you wrote:
> >> Hi Tom,
> >>
> >> This series includes the sandbox map_sysmem() feature, and gets the
> >> memory and hashing functions running on sandbox to allow testing/code
> >> coverage. I have run it through buildman and it seems clean, with the
> >> proviso that I don't have fully-working toolchains for all
> >> architectures.
> >
> > NAK. It is not correct to push changes that affect global code
> > through a arch-specific custodian tree, especially if the submitter
> > of the patche(es) is identical to the custodian of the very tree, and
> > even more so if there have been not ANY independent Acked-by: or at
> > least Tested-by: messages.
> >
> > This is NOT how the peer review process is supposed to work!!
> >
> > Especially as a custodian you must not do such things.
> 
> OK, I was not quite sure what to do, so may have misunderstood Tom's
> instructions - there is a short thread here
> http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/153342
> 
> I have created a patchwork bundle instead.
> 
> http://patchwork.ozlabs.org/bundle/sjg/sandbox-mem/

OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree,
but _not_ the master branch,  u-boot-x86/sandbox would have been fine.
Otavio Salvador - Feb. 18, 2013, 11:30 p.m.
On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini <trini@ti.com> wrote:
> OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree,
> but _not_ the master branch,  u-boot-x86/sandbox would have been fine.

Personally I'd prefer another tree as done for other custodians. It
makes life of new developers easier.
Tom Rini - Feb. 18, 2013, 11:45 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/18/2013 06:30 PM, Otavio Salvador wrote:
> On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini <trini@ti.com> wrote:
>> OK, I thought I said, but maybe I didn't, I'm OK with re-using
>> the tree, but _not_ the master branch,  u-boot-x86/sandbox would
>> have been fine.
> 
> Personally I'd prefer another tree as done for other custodians.
> It makes life of new developers easier.

It doesn't scale, however.  If I had my wish and we were starting this
afresh, I'd go with user repositories rather than subject
repositories.  Using Simon as the example, I don't think he needs one
for sandbox, one for patman (and other tools) and one for x86.  I'd
rather pull .../sjc/for-trini/x86-whatever-vs-something.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRIr00AAoJENk4IS6UOR1W5BsP/0XxGgvNqvp/Od5k1JnrR9EW
mqf6xRV7IZ6MXwPBAK7/WBaAerEZ79vx2KSezQxejkxzJlTYVgiltJHf9GNCM3xh
aenk/RGsyjjPmvZXTY/kR79x3/tMMdEu3xHaLb9F2a62qWfOAjQAcjqWtfwN1mSP
TOgnEenxYovihC8hqQA+Qo6PjRwTQJStGapUCwxWinXAD1CWxcp3QdlHr8I2T6Ib
TYIBSzT5iM/9LSdexh0Z8HOqQ0Mdu91znbJZCROkSWN5E9PM/oRaiXoWfSF6zWZy
mjhmI9V+Egl9SOhJU3XL6Q2Zjs98jsnQMIELczHrHFxidWjbdopYD5GOEfx59A+z
R8zZc59TSe1ocWdoJOkToy33iiXhWSUJR3ig6fmofVV7IXF/i9yO07GrlpW+CUip
GVxAUaZdSgPfNtIKXQ10zwzO3VGRgxk2eLs5zb+cMR/wc/gy8cqQY9J9GJwF/k7t
cysCzTW+iaSBaXwYSgVIscO7e7B9x+rt7Py+1MkkYegVE5N5Z2Igh8J5Z/tHe1Fi
A+GuvkcX9aytvSiBtKjqBbe0pSc10h1EfsmAfhH1F/Go94RA+58cPMNPmzN9KkBj
6+TahbMkzk5vsHcLosio6Oj0ZNS0Xo6w/XAZGyhep0gl61YSZNwUGx5pBbcQ6OPi
2I6hs4o9GUZV2id6IZU9
=dJRp
-----END PGP SIGNATURE-----
Otavio Salvador - Feb. 18, 2013, 11:48 p.m.
On Mon, Feb 18, 2013 at 8:45 PM, Tom Rini <trini@ti.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/18/2013 06:30 PM, Otavio Salvador wrote:
>> On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini <trini@ti.com> wrote:
>>> OK, I thought I said, but maybe I didn't, I'm OK with re-using
>>> the tree, but _not_ the master branch,  u-boot-x86/sandbox would
>>> have been fine.
>>
>> Personally I'd prefer another tree as done for other custodians.
>> It makes life of new developers easier.
>
> It doesn't scale, however.  If I had my wish and we were starting this
> afresh, I'd go with user repositories rather than subject
> repositories.  Using Simon as the example, I don't think he needs one
> for sandbox, one for patman (and other tools) and one for x86.  I'd
> rather pull .../sjc/for-trini/x86-whatever-vs-something.

The hassle to send to separated branches is the same for different
remotes; what concerns me is a new developer to try to find patman or
sandbox pending patches and do not realize it is at x86 tree. This is
confusing.
Tom Rini - Feb. 18, 2013, 11:51 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/18/2013 06:48 PM, Otavio Salvador wrote:
> On Mon, Feb 18, 2013 at 8:45 PM, Tom Rini <trini@ti.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 02/18/2013 06:30 PM, Otavio Salvador wrote:
>>> On Mon, Feb 18, 2013 at 7:52 PM, Tom Rini <trini@ti.com>
>>> wrote:
>>>> OK, I thought I said, but maybe I didn't, I'm OK with
>>>> re-using the tree, but _not_ the master branch,
>>>> u-boot-x86/sandbox would have been fine.
>>> 
>>> Personally I'd prefer another tree as done for other
>>> custodians. It makes life of new developers easier.
>> 
>> It doesn't scale, however.  If I had my wish and we were starting
>> this afresh, I'd go with user repositories rather than subject 
>> repositories.  Using Simon as the example, I don't think he needs
>> one for sandbox, one for patman (and other tools) and one for
>> x86.  I'd rather pull
>> .../sjc/for-trini/x86-whatever-vs-something.
> 
> The hassle to send to separated branches is the same for different 
> remotes; what concerns me is a new developer to try to find patman
> or sandbox pending patches and do not realize it is at x86 tree.
> This is confusing.

It's not that great in kernel-land, I agree.  But at least for U-Boot
I hope we would be able to keep the number, and possibly as/more
importantly, the time trees are not in master (or next) but have good
things in them.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRIr6WAAoJENk4IS6UOR1WOOsP/2mxdE/HHOF0GMhDAo9xDPqm
24NHn5286PCGbQIizbbwBIOnb0/suFLbqNIhIXaE587z4veDFwiTR74Ns85NrDvi
2IUavB0QwpSO8dwpjykOHvo5aA8DUaM6jYxXhrgnm3fsvlZJIgrOcEHtBd3xKerq
LdGrHybmjPZFhC9kK04JoICVAJb8svnWH9C+ql56QLn1/ZjwHVP3OlYv3bmx+iKG
QuBtx30CmLwciJBAq6x3LlVasm76naA9S444RFPwxH0s3Eqlsl111Z9FdtAnc2HW
VCgzU+GPgowayLSnMCf0RdXL5ho23vpOYsABOd+jKVCoK3VgEkSpyQXWk52vKD5h
pRTqBNOl7KrVaCYcB5NC+xB/5dTUpem3qfvQ6UAbElehLDfHvI82Dd7ttPl0GMsH
+aUTNdqubHtU6DmApGQDrfOyzi4u4vLSy3CX6Am/7pGpfd3h1M+gLChhLNH010H0
b9BMOWRRc8TolydImTFHuibCtEfx7HcleIujlThodTocU4aTkaUMoi3nSeJ58KcA
vPJl1Y/vR8MmuS5mQr//Lzvf+nsSxQYg18crkasPqbqiiAeCAKHBkHd7ZD+ALCxY
k9Plxpa/sx8DUqQUdgFxyDz5kAPCOli/BLdC6h/+7Yflp6HAwa/Ly6QoFYT6yGA3
79hxzWjtJ5/uravy4eKl
=5qPb
-----END PGP SIGNATURE-----
Simon Glass - Feb. 19, 2013, 5:22 a.m.
Hi Tom,

On Mon, Feb 18, 2013 at 2:52 PM, Tom Rini <trini@ti.com> wrote:
> On Sun, Feb 17, 2013 at 01:32:58PM -0800, Simon Glass wrote:
>> Hi Wolfgang,
>>
>> On Sun, Feb 17, 2013 at 12:58 PM, Wolfgang Denk <wd@denx.de> wrote:
>> > Dear Simon Glass,
>> >
>> > In message <CAPnjgZ2P6sBDXiwXW2TeCdjADMhkN5iNBGrpZbtvwMqUtYVVxA@mail.gmail.com> you wrote:
>> >> Hi Tom,
>> >>
>> >> This series includes the sandbox map_sysmem() feature, and gets the
>> >> memory and hashing functions running on sandbox to allow testing/code
>> >> coverage. I have run it through buildman and it seems clean, with the
>> >> proviso that I don't have fully-working toolchains for all
>> >> architectures.
>> >
>> > NAK. It is not correct to push changes that affect global code
>> > through a arch-specific custodian tree, especially if the submitter
>> > of the patche(es) is identical to the custodian of the very tree, and
>> > even more so if there have been not ANY independent Acked-by: or at
>> > least Tested-by: messages.
>> >
>> > This is NOT how the peer review process is supposed to work!!
>> >
>> > Especially as a custodian you must not do such things.
>>
>> OK, I was not quite sure what to do, so may have misunderstood Tom's
>> instructions - there is a short thread here
>> http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/153342
>>
>> I have created a patchwork bundle instead.
>>
>> http://patchwork.ozlabs.org/bundle/sjg/sandbox-mem/
>
> OK, I thought I said, but maybe I didn't, I'm OK with re-using the tree,
> but _not_ the master branch,  u-boot-x86/sandbox would have been fine.

Yes, you said "toss it into a branch in u-boot-x86.git". It did cross
my mind to use something other than master, but I wasn't sure if that
was OK in U-Boot. I know for next time.

Regards,
Simon

>
> --
> Tom