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

[Michal Simek]

Hi,

On 7/29/22 17:00, Jae Hyun Yoo wrote:
> Hello Michal,
> 
> On 7/29/2022 7:38 AM, Jae Hyun Yoo wrote:
>> On 7/29/2022 4:13 AM, Michal Simek wrote:
>>> 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.
>>
>> Yes, I realized that the Xilinx specific customization was added into
>> the standard board info area so actually it breaks the spec.
>>
>> struct fru_board_data {
>>          [....]
>>
>>      /* Xilinx custom fields */
>>      u8 rev_type_len;
>>      u8 rev[FRU_BOARD_MAX_LEN];
>>      u8 pcie_type_len;
>>      u8 pcie[FRU_BOARD_MAX_LEN];
>>      u8 uuid_type_len;
>>      u8 uuid[FRU_BOARD_MAX_LEN];
>> };
>>
>> I think, this type of customization should be added using multirecords
>> instead of expanding the common board info structure, and it's the
>> reason why the FRU spec provides OEM multirecord types (0xc0 - 0xff).
>> Do you have any plan to replace them with OEM multirecords?
> 
> I reviewed the spec again and checked that adding additional info fields
> is also acceptable by the spec. Let me try to refine the current code to
> make it parse the additional custom info fields in a generic way.

Replied previous email before this one. Good that you also found it.

M