Re: [RFC PATCH 5/8] qaic: Implement data path

From: Jeffrey Hugo
Date: Thu May 14 2020 - 18:06:30 EST


Thanks for the review.

On 5/14/2020 3:36 PM, Arnd Bergmann wrote:
On Thu, May 14, 2020 at 4:09 PM Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx> wrote:

+struct dbc_req { /* everything must be little endian encoded */

Instead of the comment, I suppose you want to use __le16 and __le32
types and let sparse check that you got it right.

Ah yes, I was curious if those should be applied here. Their use seems inconsistent. I will do that.


+ u16 req_id;
+ u8 seq_id;
+ u8 cmd;
+ u32 resv;
+ u64 src_addr;
+ u64 dest_addr;
+ u32 len;
+ u32 resv2;
+ u64 db_addr; /* doorbell address */
+ u8 db_len; /* not a raw value, special encoding */
+ u8 resv3;
+ u16 resv4;
+ u32 db_data;
+ u32 sem_cmd0;
+ u32 sem_cmd1;
+ u32 sem_cmd2;
+ u32 sem_cmd3;
+} __packed;

All members are naturally aligned, so better drop the __packed
annotation get better code, unless the structure itself is
at an unaligned offset in memory.

I'm going to have to disagree. While most "sane" compilers would not add extra padding, I've debugged enough issues in the past when sending/receiving data with foreign environments to never trust anything that isn't "packed".

Unless I missed something in the C spec that requires naturally aligned structures to have an identical layout in memory, I'll take safety and functional correctness over performance.


+struct dbc_rsp { /* everything must be little endian encoded */
+ u16 req_id;
+ u16 status;
+} __packed;

Same here.

+ init_completion(&mem->xfer_done);
+ list_add_tail(&mem->list, &dbc->xfer_list);
+ tail = (tail + mem->nents) % dbc->nelem;
+ __raw_writel(cpu_to_le32(tail), dbc->dbc_base + REQTP_OFF);

What is this __raw accessor for? This generally results in non-portable
code that should be replaced with writel() or something specific to
the bus on the architecture you deal with.

The barrier(s) that comes with writel are unnecessary in this case. Since this is part of our critical path, we are sensitive to its performance.

What are the portability issues around the __raw variant?


+ spin_lock_irqsave(&qdev->dbc[exec->dbc_id].xfer_lock, flags);
+ req_id = qdev->dbc[exec->dbc_id].next_req_id++;
+ queued = mem->queued;
+ mem->queued = true;
+ spin_unlock_irqrestore(&qdev->dbc[exec->dbc_id].xfer_lock, flags);

No need for 'irqsave' locks when you know that interrupts are enabled.

Fair enough.


+ head = le32_to_cpu(__raw_readl(dbc->dbc_base + RSPHP_OFF));
+ tail = le32_to_cpu(__raw_readl(dbc->dbc_base + RSPTP_OFF));

More __raw accessors to replace.

Same answer as before.


+ case QAIC_IOCTL_MEM_NR:
+ if (_IOC_DIR(cmd) != (_IOC_READ | _IOC_WRITE) ||
+ _IOC_SIZE(cmd) != sizeof(struct qaic_mem_req)) {
+ ret = -EINVAL;
+ break;

This looks like a very verbose way to check 'cmd' against a known
constant. Why not use 'switch (cmd)' like all other drivers?

Huh. That actually does sound more elegant. Will do.


--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.