Re: [PATCH v12] i2c: virtio: add a virtio i2c frontend driver

On 2021/7/5 12:38, Viresh Kumar wrote:

On 05-07-21, 11:45, Jie Deng wrote:

quoted

On 2021/7/5 10:40, Viresh Kumar wrote:

quoted

On 02-07-21, 16:46, Jie Deng wrote:
The right way of doing this is is making this function return - Error on failure
and 0 on success. There is no point returning number of successful additions
here.

We need the number for virtio_i2c_complete_reqs to do cleanup. We don't have
to

do cleanup "num" times every time. Just do it as needed.

If you do full cleanup here, then you won't required that at the caller site.

quoted

quoted

Moreover, on failures this needs to clean up (free the dmabufs) itself, just
like you did i2c_put_dma_safe_msg_buf() at the end. The caller shouldn't be
required to handle the error cases by freeing up resources.

This function will return the number of requests being successfully prepared
and make sure

resources of the failed request being freed. And virtio_i2c_complete_reqs
will free the

resources of those successful request.

It just looks cleaner to give such responsibility to each and every function,
i.e. if they fail, they should clean stuff up instead of the caller. That's the
normal philosophy you will find across kernel in most of the cases.
  

quoted

quoted

quoted

+		/*
+		 * Condition (req && req == &reqs[i]) should always meet since
+		 * we have total nr requests in the vq.
+		 */
+		if (!failed && (WARN_ON(!(req && req == &reqs[i])) ||
+		    (req->in_hdr.status != VIRTIO_I2C_MSG_OK)))

What about writing this as:

		if (!failed && (WARN_ON(req != &reqs[i]) ||
		    (req->in_hdr.status != VIRTIO_I2C_MSG_OK)))

We don't need to check req here since if req is NULL, we will not do req->in_hdr
at all.

It's right here just because the &reqs[i] will never be NULL in our case.
But if you see

"virtio_i2c_complete_reqs" as an independent function, you need to check the

req. From the perspective of the callee, you can't ask the caller always
give you

the non-NULL parameters.

We need to keep this driver optimized in its current form. If you see your own
argument here, then why don't you test vq or msgs for a valid pointer ? And even
reqs.

If we know for certain that this will never happen, then it should be optimized.
But if you see a case where reqs[i] can be NULL here, then it would be fine.
ot the driver. And we don't need to take care of that.

This is still not enough to convince me.  So I won't change them for now 
until I see it

is the consensus of the majority.

Thank you.


_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization