Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

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>

mtd: Remove <common.h> and add needed includes

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

Reviewed-by: William Zhang <william.zhang@broadcom.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

drivers/mtd/nvmxip: Print phys_addr_t without warnings on both 32bit and 64bit systems

Cast the address such that it can be printed without warnings
on both 32bit and 64bit systems. This really should use some
better print formatter, but for the lack of it, do it this way.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

drivers/mtd/nvmxip: Trigger post bind as probe on driver level

Perform all the block device creation only once, after the driver itself
successfully bound. Do not do this in uclass post bind, as this might be
triggered multiple times. For example the ut_dm_host test triggers this
and triggers a memory leak that way, since there are now multiple block
devices created using the blk_create_devicef() .

To retain the old probe-on-boot behavior, set DM_FLAG_PROBE_AFTER_BIND
flag in uclass post_bind callback, so the driver model would probe the
driver at the right time.

Rename the function as well, to match similar functions in
other block-related subsystems, like the mmc one.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

drivers/mtd/nvmxip: introduce QSPI XIP driver

add nvmxip_qspi driver under UCLASS_NVMXIP

The device associated with this driver is the parent of the blk#<id> device
nvmxip_qspi can be reused by other platforms. If the platform
has custom settings to apply before using the flash, then the platform
can provide its own parent driver belonging to UCLASS_NVMXIP and reuse
nvmxip-blk driver. The custom driver can be implemented like nvmxip_qspi in
addition to the platform custom settings.

Platforms can use multiple NVM XIP devices at the same time by defining a
DT node for each one of them.

For more details please refer to doc/develop/driver-model/nvmxip_qspi.rst

Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>

mtd: Remove <common.h> and add needed includes

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

Reviewed-by: William Zhang <william.zhang@broadcom.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

drivers/mtd/nvmxip: Print phys_addr_t without warnings on both 32bit and 64bit systems

Cast the address such that it can be printed without warnings
on both 32bit and 64bit systems. This really should use some
better print formatter, but for the lack of it, do it this way.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

drivers/mtd/nvmxip: Trigger post bind as probe on driver level

Perform all the block device creation only once, after the driver itself
successfully bound. Do not do this in uclass post bind, as this might be
triggered multiple times. For example the ut_dm_host test triggers this
and triggers a memory leak that way, since there are now multiple block
devices created using the blk_create_devicef() .

To retain the old probe-on-boot behavior, set DM_FLAG_PROBE_AFTER_BIND
flag in uclass post_bind callback, so the driver model would probe the
driver at the right time.

Rename the function as well, to match similar functions in
other block-related subsystems, like the mmc one.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

drivers/mtd/nvmxip: introduce QSPI XIP driver

add nvmxip_qspi driver under UCLASS_NVMXIP

The device associated with this driver is the parent of the blk#<id> device
nvmxip_qspi can be reused by other platforms. If the platform
has custom settings to apply before using the flash, then the platform
can provide its own parent driver belonging to UCLASS_NVMXIP and reuse
nvmxip-blk driver. The custom driver can be implemented like nvmxip_qspi in
addition to the platform custom settings.

Platforms can use multiple NVM XIP devices at the same time by defining a
DT node for each one of them.

For more details please refer to doc/develop/driver-model/nvmxip_qspi.rst

Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>

drivers/mtd/nvmxip: Print phys_addr_t without warnings on both 32bit and 64bit systems

Cast the address such that it can be printed without warnings
on both 32bit and 64bit systems. This really should use some
better print formatter, but for the lack of it, do it this way.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

drivers/mtd/nvmxip: Trigger post bind as probe on driver level

Perform all the block device creation only once, after the driver itself
successfully bound. Do not do this in uclass post bind, as this might be
triggered multiple times. For example the ut_dm_host test triggers this
and triggers a memory leak that way, since there are now multiple block
devices created using the blk_create_devicef() .

To retain the old probe-on-boot behavior, set DM_FLAG_PROBE_AFTER_BIND
flag in uclass post_bind callback, so the driver model would probe the
driver at the right time.

Rename the function as well, to match similar functions in
other block-related subsystems, like the mmc one.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

drivers/mtd/nvmxip: introduce QSPI XIP driver

add nvmxip_qspi driver under UCLASS_NVMXIP

The device associated with this driver is the parent of the blk#<id> device
nvmxip_qspi can be reused by other platforms. If the platform
has custom settings to apply before using the flash, then the platform
can provide its own parent driver belonging to UCLASS_NVMXIP and reuse
nvmxip-blk driver. The custom driver can be implemented like nvmxip_qspi in
addition to the platform custom settings.

Platforms can use multiple NVM XIP devices at the same time by defining a
DT node for each one of them.

For more details please refer to doc/develop/driver-model/nvmxip_qspi.rst

Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>

drivers/mtd/nvmxip: introduce QSPI XIP driver

add nvmxip_qspi driver under UCLASS_NVMXIP

The device associated with this driver is the parent of the blk#<id> device
nvmxip_qspi can be reused by other platforms. If the platform
has custom settings to apply before using the flash, then the platform
can provide its own parent driver belonging to UCLASS_NVMXIP and reuse
nvmxip-blk driver. The custom driver can be implemented like nvmxip_qspi in
addition to the platform custom settings.

Platforms can use multiple NVM XIP devices at the same time by defining a
DT node for each one of them.

For more details please refer to doc/develop/driver-model/nvmxip_qspi.rst

Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>