Skip to content
Snippets Groups Projects
  1. Jan 28, 2016
  2. Jan 27, 2016
  3. Jan 25, 2016
  4. Jan 23, 2016
  5. Jan 22, 2016
  6. Jan 21, 2016
  7. Jan 19, 2016
  8. Jan 16, 2016
    • Peng Fan's avatar
      common: usb: fix checking condition · 447b9cdf
      Peng Fan authored
      
      We support max USB_MAXENDPOINTS, so need to use
      "epno >= USB_MAXENDPOINTS", but not "epno > USB_MAXENDPOINTS".
      If use ">", we may exceeds the array of if_desc->ep_desc.
      
      Signed-off-by: default avatarPeng Fan <peng.fan@nxp.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Paul Kocialkowski <contact@paulk.fr>
      Cc: "Stefan Brüns" <stefan.bruens@rwth-aachen.de>
      Cc: Vincent Palatin <vpalatin@chromium.org>
      447b9cdf
  9. Jan 15, 2016
  10. Jan 14, 2016
    • Peng Fan's avatar
      common: env_flags: fix loop condition when using env_flags_varaccess_mask · db18f548
      Peng Fan authored
      
      We should use ARRAY_SIZE, but not sizeof. The size of
      env_flags_varaccess_mask is 16bytes, but we only need 4 loops.
      If using 16 as the end condition, we may access memory that
      not belong to array env_flags_varaccess_mask.
      
      Signed-off-by: default avatarPeng Fan <peng.fan@nxp.com>
      Cc: Joe Hershberger <joe.hershberger@ni.com>
      Cc: York Sun <yorksun@freescale.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Tom Rini <trini@konsulko.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      Acked-by: default avatarJoe Hershberger <joe.hershberger@ni.com>
      db18f548
    • Peng Fan's avatar
      common: cli_simple: use strlcpy instead of strcpy · bb08a6e7
      Peng Fan authored
      
      Report Coverity log:
      Destination buffer too small (STRING_OVERFLOW)
      string_overflow: You might overrun the 1024 byte destination string
      lastcommand by writing 1025 bytes from console_buffer
      
      Signed-off-by: default avatarPeng Fan <van.freenix@gmail.com>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Tom Rini <trini@konsulko.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      bb08a6e7
    • Michael van Slingerland's avatar
      cmd_boot: Add a poweroff command · 4e42e29f
      Michael van Slingerland authored
      
      Add a 'poweroff' command to boot commands, this only gets enabled if the
      board Kconfig does a "select CMD_POWEROFF".
      
      Signed-off-by: default avatarMichael van Slingerland <michael@deviousops.nl>
      [hdegoede@redhat.com: Make the cmd conditional on a CMD_POWEROFF Kconfig]
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      4e42e29f
    • Stephen Warren's avatar
      ums: support multiple LUNs at once · 02585eb3
      Stephen Warren authored
      
      Extend the ums command to accept a list of block devices. Each of these
      will be exported as a separate LUN. An example use-case would be:
      
      ums 0 mmc 0,0.1,0.2
      
      ... which would export LUNs for eMMC 0's user data, boot0, and boot1 HW
      partitions. This is useful since it allows the host access to everything
      on the eMMC without having to somehow stop the ums command from executing
      and restart it with different parameters.
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      02585eb3
    • Stephen Warren's avatar
      mmc: store hwpart in the block device · 873cc1d7
      Stephen Warren authored
      
      This will allow us to have multiple block device structs each referring
      to the same eMMC device, yet different HW partitions.
      
      For now, there is still a single block device per eMMC device. As before,
      this block device always accesses whichever HW partition was most recently
      selected. Clients wishing to make use of multiple block devices referring
      to different HW partitions can simply take a copy of this block device
      once it points at the correct HW partition, and use each one as they wish.
      This feature will be used by the next patch.
      
      In the future, perhaps get_device() could be enhanced to return a
      dynamically allocated block device struct, to avoid the client needing to
      copy it in order to maintain multiple block devices. However, this would
      require all users to be updated to free those block device structs at some
      point, which is rather a large change.
      
      Most callers of mmc_switch_part() wish to permanently switch the default
      MMC block device's HW partition. Enhance mmc_switch_part() so that it does
      this. This removes the need for callers to do this. However,
      common/env_mmc.c needs to save and restore the current HW partition. Make
      it do this more explicitly.
      
      Replace use of mmc_switch_part() with mmc_select_hwpart() in order to
      remove duplicate code that skips the call if that HW partition is already
      selected.
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      873cc1d7
    • Stephen Warren's avatar
      block: pass block dev not num to read/write/erase() · 7c4213f6
      Stephen Warren authored
      
      This will allow the implementation to make use of data in the block_dev
      structure beyond the base device number. This will be useful so that eMMC
      block devices can encompass the HW partition ID rather than treating this
      out-of-band. Equally, the existence of the priv field is crying out for
      this patch to exist.
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      7c4213f6
    • Albert ARIBAUD's avatar
      arm: move gd handling outside of C code · adc421e4
      Albert ARIBAUD authored
      
      As of gcc 5.2.1 for Thumb-1, it is not possible any
      more to assign gd from C code, as gd is mapped to r9,
      and r9 may now be saved in the prolog sequence, and
      restored in the epilog sequence, of any C functions.
      
      Therefore arch_setup_gd(), which is supposed to set
      r9, may actually have no effect, causing U-Boot to
      use a bad address to access GD.
      
      Fix this by never calling arch_setup_gd() for ARM,
      and instead setting r9 in arch/arm/lib/crt0.S, to
      the value returned by board_init_f_alloc_reserve().
      
      Signed-off-by: default avatarAlbert ARIBAUD <albert.u.boot@aribaud.net>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      adc421e4
    • Albert ARIBAUD's avatar
      Fix board init code to respect the C runtime environment · ecc30663
      Albert ARIBAUD authored
      
      board_init_f_mem() alters the C runtime environment's
      stack it is actually already using. This is not a valid
      behaviour within a C runtime environment.
      
      Split board_init_f_mem into C functions which do not alter
      their own stack and always behave properly with respect to
      their C runtime environment.
      
      Signed-off-by: default avatarAlbert ARIBAUD <albert.u.boot@aribaud.net>
      Acked-by: default avatarThomas Chou <thomas@wytron.com.tw>
      ecc30663
    • Tom Rini's avatar
      hash.c: Conditionally compile hash_command, static hash_show · 48ad68de
      Tom Rini authored
      
      The function hash_show is now only called by hash_command, so mark it as
      static (and drop from hash.h).  We only call hash_command when any of
      CONFIG_CMD_CRC32, CONFIG_CMD_SHA1SUM or CONFIG_CMD_HASH are set.  Since
      hash.c is linked in unconditionally we must take extra care with
      functions that bring in read-only strings as these will not be
      discarded.
      
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      48ad68de
  11. Jan 13, 2016
  12. Jan 12, 2016
Loading