Hi Andrew,
On 07/03/24 5:49 am, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>> enum oa_tc6_register_op {
>> + OA_TC6_CTRL_REG_READ = 0,
>> OA_TC6_CTRL_REG_WRITE = 1,
>> };
>
> I thought it looked a little odd when the enum was added in the
> previous patch with the first value of 1, and only one value. Now it
> makes more sense.
Ok.
>
> The actual value appears to not matter? It is always
>
>> + if (reg_op == OA_TC6_CTRL_REG_WRITE)
>
> So i would drop the numbering, and leave it to the compiler. The
> patches will then look less odd.
"drop the numbering", do you refer to this patch alone or previous patch
also? If it is for this patch alone then it makes sense as they are
going to be 0 and 1 anyway. But if we drop the numbering in the previous
patch it will become 0 which will create an issue in the below line as
it needs 1,
FIELD_PREP(OA_TC6_CTRL_HEADER_WRITE, reg_op)
Could you clarify? or do I have any misunderstanding here?
>
>> +static int oa_tc6_check_ctrl_read_reply(struct oa_tc6 *tc6, u8 size)
>> +{
>> + u32 *tx_buf = tc6->spi_ctrl_tx_buf;
>> + u32 *rx_buf = tc6->spi_ctrl_rx_buf + OA_TC6_CTRL_IGNORED_SIZE;
>> +
>> + /* The echoed control read header must match with the one that was
>> + * transmitted.
>> + */
>> + if (*tx_buf != *rx_buf)
>> + return -ENODEV;
>
> Another case where -EPROTO might be better?
Yes, I will use -EPROTO in the next version as it is likely "Protocol error"
Best regards,
Parthiban V
>
> Andrew
>
