lib: optee: Remove CONFIG_OPTEE_LOAD_ADDR

This value is not used by u-boot, and it should not. The load address
of an OPTEE image is defined by said image. Either a uImage or a FIT
will have a defined load address and entry point. Those values are the
correct ones, not CONFIG_OPTEE_LOAD_ADDR.

Commit f25006b96e ("optee: Add CONFIG_OPTEE_LOAD_ADDR") justifies
this config by requiring its presence in u-boot's .config for other
images as part of a larger build, claiming it is "the best way".

This argument is not persuasive. U-boot's configuration is driven by
platform requirements, not the other way around. It seems more likely
that the argument is conflating tooling issues with Kconfig. Yocto and
buildroot have excellent mechanisms for defining values across the
board (pun intended). u-boot's Kconfig is the wrong place to do it.

Furthermore, it is not "best" for u-boot because it hardcodes a value
which is then not used. In fact the load address that u-boot uses is
the one derived from the OPTEE image.

Confused yet? I sure was. To prevent future confusion, remove
CONFIG_OPTEE_LOAD_ADDR.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

include/configs/warp7.h

@@ -28,10 +28,6 @@
 #define BOOT_SCR_STRING "source ${bootscriptaddr}\0"
 #endif
 
-#ifndef CONFIG_OPTEE_LOAD_ADDR
-#define CONFIG_OPTEE_LOAD_ADDR 0
-#endif
-
 #define CONFIG_EXTRA_ENV_SETTINGS \
 	CONFIG_DFU_ENV_SETTINGS \
 	"script=boot.scr\0" \
@@ -46,7 +42,6 @@
 	"fdt_file=imx7s-warp.dtb\0" \
 	"fdt_addr=" __stringify(CONFIG_SYS_FDT_ADDR)"\0" \
 	"fdtovaddr=0x83100000\0" \
-	"optee_addr=" __stringify(CONFIG_OPTEE_LOAD_ADDR)"\0" \
 	"boot_fdt=try\0" \
 	"ip_dyn=yes\0" \
 	"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \