14 Feb, 2018

1 commit

  • This driver is no longer used on any supported platform in U-Boot and
    there is no interest in maintaining it further from people that have
    used it historically.

    Cc: Simon Glass
    Cc: Michal Simek
    c: Alexey Brodkin
    Signed-off-by: Tom Rini
    Acked-by: Michal Simek

    Tom Rini
     

09 Feb, 2018

2 commits

  • config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE
    based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to
    Kconfig allows us to drastically shrink the logic in
    config_fallbacks.h

    Signed-off-by: Adam Ford
    [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE]
    Signed-off-by: Tom Rini

    Adam Ford
     
  • Migrate the base and sub-options to Kconfig. Note that we only enable
    this in the base sandbox config now.

    Cc: Alexey Brodkin
    Cc: Michal Simek
    Signed-off-by: Tom Rini
    ---
    Is this driver still used anywhere? It's fishy that it's only enabled
    in sandbox anymore.

    Tom Rini
     

23 Jan, 2018

1 commit

  • This patch provides
    * a uclass for EFI drivers
    * a EFI driver for block devices

    For each EFI driver the uclass
    * creates a handle
    * adds the driver binding protocol

    The uclass provides the bind, start, and stop entry points for the driver
    binding protocol.

    In bind() and stop() it checks if the controller implements the protocol
    supported by the EFI driver. In the start() function it calls the bind()
    function of the EFI driver. In the stop() function it destroys the child
    controllers.

    The EFI block driver binds to controllers implementing the block io
    protocol.

    When the bind function of the EFI block driver is called it creates a
    new U-Boot block device. It installs child handles for all partitions and
    installs the simple file protocol on these.

    The read and write functions of the EFI block driver delegate calls to the
    controller that it is bound to.

    A usage example is as following:

    U-Boot loads the iPXE snp.efi executable. iPXE connects an iSCSI drive and
    exposes a handle with the block IO protocol. It calls ConnectController.

    Now the EFI block driver installs the partitions with the simple file
    protocol.

    iPXE uses the simple file protocol to load Grub or the Linux Kernel.

    Signed-off-by: Heinrich Schuchardt
    [agraf: add comment on calloc len]
    Signed-off-by: Alexander Graf

    Heinrich Schuchardt
     

13 Dec, 2017

1 commit

  • This patch changes the calls to uclass_first/next_device() in blk_first/
    next_device() to use uclass_find_first/next_device() instead. These functions
    don't prepare the devices, which is correct in this case.

    With this patch applied, the "usb storage" command now works again as
    expected:

    => usb storage
    Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
    Type: Removable Hard Disk
    Capacity: 58656.0 MB = 57.2 GB (120127488 x 512)

    Without this patch, it used to generate this buggy output:

    => usb storage
    Card did not respond to voltage select!
    mmc_init: -95, time 26
    No storage devices, perhaps not 'usb start'ed..?

    Signed-off-by: Stefan Roese
    Suggested-by: Simon Glass
    Cc: Simon Glass
    Cc: Bin Meng
    Reviewed-by: Bin Meng
    Reviewed-by: Simon Glass

    Stefan Roese
     

15 Sep, 2017

1 commit

  • All these places seem to inherit the codes from the MMC driver where
    a FIXME was put in the comment. However the correct operation after
    read should be cache invalidate, not flush.

    The underlying drivers should be responsible for the cache operation.
    Remove these codes completely.

    Signed-off-by: Bin Meng
    Reviewed-by: Stefan Roese
    Reviewed-by: York Sun
    Reviewed-by: Joe Hershberger
    Reviewed-by: Simon Glass
    Tested-by: York Sun

    Bin Meng
     

12 Sep, 2017

1 commit


11 Sep, 2017

2 commits


04 Sep, 2017

3 commits


17 Aug, 2017

2 commits


14 Aug, 2017

1 commit


02 Aug, 2017

1 commit


01 Aug, 2017

2 commits

  • Add missing #ifndef CONFIG_BLK to wrap dev_desc->block_read.

    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     
  • At present if U-Boot proper uses driver model for MMC, then SPL has to
    also. While this is desirable, it places a significant barrier to moving
    to driver model in some cases. For example, with a space-constrained SPL
    it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves
    adjusting some drivers.

    Add new SPL versions of the options for DM_MMC, DM_MMC_OPS and BLK. By
    default these follow their non-SPL versions, but this can be changed by
    boards which need it.

    Signed-off-by: Simon Glass

    Simon Glass
     

12 Jul, 2017

6 commits


04 Jul, 2017

1 commit


20 Jun, 2017

1 commit


12 Jun, 2017

1 commit

  • There was for long time no activity in the 8xx area.
    We need to go further and convert to Kconfig, but it
    turned out, nobody is interested anymore in 8xx,
    so remove it (with a heavy heart, knowing that I remove
    here the root of U-Boot).

    Signed-off-by: Heiko Schocher

    Heiko Schocher
     

09 Jun, 2017

1 commit


01 Jun, 2017

5 commits

  • The intention with block devices is that the device number (devnum field
    in its descriptor) matches the alias of its parent device. For example,
    with:

    aliases {
    mmc0 = "/sdhci@700b0600";
    mmc1 = "/sdhci@700b0400";
    }

    we expect that the block devices for mmc0 and mmc1 would have device
    numbers of 0 and 1 respectively.

    Unfortunately this does not currently always happen. If there is another
    MMC device earlier in the driver model data structures its block device
    will be created first. It will therefore get device number 0 and mmc0
    will therefore miss out. In this case the MMC device will have sequence
    number 0 but its block device will not.

    To avoid this, allow a device to request a device number and bump any
    existing device number that is using it. This all happens during the
    binding phase so it is safe to change these numbers around. This allows
    device numbers to match the aliases in all circumstances.

    Add a test to verify the behaviour.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • At present this code is inline. Move it into a function to allow it to
    be used elsewhere.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • Sometimes it is useful to be able to find a block device without also
    probing it. Add a function for this as well as the associated test.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • At present devices use a simple integer offset to record the device tree
    node associated with the device. In preparation for supporting a live
    device tree, which uses a node pointer instead, refactor existing code to
    access this field through an inline function.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • These support the flat device tree. We want to use the dev_read_..()
    prefix for functions that support both flat tree and live tree. So rename
    the existing functions to avoid confusion.

    In the end we will have:

    1. dev_read_addr...() - works on devices, supports flat/live tree
    2. devfdt_get_addr...() - current functions, flat tree only
    3. of_get_address() etc. - new functions, live tree only

    All drivers will be written to use 1. That function will in turn call
    either 2 or 3 depending on whether the flat or live tree is in use.

    Note this involves changing some dead code - the imx_lpi2c.c file.

    Signed-off-by: Simon Glass

    Simon Glass
     

23 May, 2017

1 commit

  • At present IDE support is controlled by CONFIG_CMD_IDE. Add a separate
    CONFIG_IDE option so that IDE support can be enabled without requiring
    the 'ide' command.

    Update existing users and move the ide driver into drivers/block since
    it should not be in common/.

    Signed-off-by: Simon Glass

    Simon Glass
     

10 May, 2017

1 commit


18 Apr, 2017

2 commits


05 Apr, 2017

1 commit

  • This patch adds the flags parameter to device_remove() and changes all
    calls to this function to provide the default value of DM_REMOVE_NORMAL
    for "normal" device removal.

    This is in preparation for the driver specific pre-OS (e.g. DMA
    cancelling) remove support.

    Signed-off-by: Stefan Roese
    Cc: Simon Glass
    Acked-by: Simon Glass

    Stefan Roese
     

20 Dec, 2016

2 commits

  • This patch also includes ARM64 zynqmp changes:
    - Remove platform non DM initialization
    - Remove hardcoded sata base address

    Signed-off-by: Michal Simek
    Reviewed-by: Simon Glass

    Michal Simek
     
  • All sata based drivers are bind and corresponding block
    device is created. Based on this find_scsi_device() is able
    to get back block device based on scsi_curr_dev pointer.

    intr_scsi() is commented now but it can be replaced by calling
    find_scsi_device() and scsi_scan().

    scsi_dev_desc[] is commented out but common/scsi.c heavily depends on
    it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol
    is reassigned to a block description allocated by uclass.
    There is only one block description by device now but it doesn't need to
    be correct when more devices are present.

    scsi_bind() ensures corresponding block device creation.
    uclass post_probe (scsi_post_probe()) is doing low level init.

    SCSI/SATA DM based drivers requires to have 64bit base address as
    the first entry in platform data structure to setup mmio_base.

    Signed-off-by: Michal Simek
    Reviewed-by: Simon Glass

    Michal Simek