[RFC PATCH 1/2] cmd/fru: cmd/fru: move FRU handling support to common region

[Michal Simek]

You should fix subject.

On 7/27/22 01:50, Jae Hyun Yoo wrote:
> From: Graeme Gregory <quic_ggregory at quicinc.com>
> 
> The FRU handling was added as a Xilinx board dependent support but it
> would be useful for other boards too, so this commit moves the FRU
> handling support to the common region to be enabled by CONFIG_CMD_FRU.
> Since the Multirecord parsing logic should be implemented on each OEM
> board specifically, it defines 'fru_parse_multirec' as a weak function
> so that it can be replaced with the board specific implementation.

Not entirely. Some multirecords are common and described by spec. But parising 
multirecord based on IANA ID is vendor specific.
It means boards shouldn't replicate code for hearder checking. Only handle that 
IANA specific part.


> 
> Signed-off-by: Graeme Gregory <quic_ggregory at quicinc.com>
> Signed-off-by: Jae Hyun Yoo <quic_jaehyoo at quicinc.com>
> ---
>   board/xilinx/Kconfig                      |  8 ---
>   board/xilinx/common/Makefile              |  3 --
>   board/xilinx/common/board.c               | 63 +++++++++++++++++++----
>   cmd/Kconfig                               |  8 +++
>   cmd/Makefile                              |  1 +
>   {board/xilinx/common => cmd}/fru.c        |  3 +-
>   common/Makefile                           |  2 +
>   {board/xilinx/common => common}/fru_ops.c | 37 ++++++-------
>   {board/xilinx/common => include}/fru.h    | 15 +-----
>   9 files changed, 82 insertions(+), 58 deletions(-)
>   rename {board/xilinx/common => cmd}/fru.c (99%)
>   rename {board/xilinx/common => common}/fru_ops.c (93%)
>   rename {board/xilinx/common => include}/fru.h (85%)

The main reason why I didn't added to generic location was that in board field 
there are xilinx specific custom fields.
With other vendor this won't work.
I think this should be solved before this code can be moved to generic location.

Also maybe make sense to move and spec that variable creation.

Thanks,
Michal