A system may have multiple SATA controller. Removing the controller with
the lowest sequence number before probing all SATA controllers makes no
sense.

In sata_rescan we remove all block devices which are children of SATA
controllers. We also have to remove the bootdev devices as they will be
created when scanning for block devices.

After probing all SATA controllers we must scan for block devices otherwise
we end up without any SATA block device.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

Remove <common.h> from this driver directory and when needed
add missing include files directly.

Reviewed-by: Tony Dinh <mibodhi@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

Prepare v2024.01-rc3

During bootstd scanning for bootdevs, if bootdev_hunt_drv() encounters
a device not found error (e.g. ENOENT), let it return a successful status
so that bootstd will continue scanning the next devices, not stopping
prematurely.

Background:

During scanning for bootflows, it's possible for bootstd to encounter a
faulty device controller. Also when the same u-boot is used for another
variant of the same board, some device controller such as SATA might
not exist.

I've found this issue while converting the Marvell Sheevaplug board to
use bootstd. This board has 2 variants, the original Sheevaplug has MMC and
USB only, but the later variant comes with USB, MMC, and eSATA ports. We
have been using the same u-boot (starting with CONFIG_IDE and later with DM
CONFIG_SATA) for both variants. This worked well with the old
envs-scripting booting scheme.

Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The migration deadline for moving to DM_SCSI was v2023.04. A further
reminder was sent out in August 2023 to the remaining platforms that had
not migrated already, and that a few more over the line (or configs
deleted).

With this commit we:
- Rename CONFIG_DM_SCSI to CONFIG_SCSI.
- Remove all of the non-DM SCSI code. This includes removing other
  legacy symbols and code and removes some legacy non-DM AHCI code.
- Some platforms that had previously been DM_SCSI=y && SCSI=n are now
  fully migrated to DM_SCSI as a few corner cases in the code assumed
  DM_SCSI=y meant SCSI=y.

Signed-off-by: Tom Rini <trini@konsulko.com>

It's normal to have no SATA drive attached to the controller, so return a
successful status when there is no block device found after probing.

Note: this patch depends on the previous patch
https://patchwork.ozlabs.org/project/uboot/patch/20230917230649.30357-1-mibodhi@gmail.com/

Resend the right patch.

Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Add ahci sata bootdev and corresponding hunting function.

Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Use the word 'uclass' instead of 'if_type' to complete the conversion.

Signed-off-by: Simon Glass <sjg@chromium.org>