Messages in this thread | | | Subject | Re: [PATCH v6] i2c: virtio: add a virtio i2c frontend driver | From | Jie Deng <> | Date | Thu, 11 Mar 2021 13:59:42 +0800 |
| |
On 2021/3/10 16:27, Arnd Bergmann wrote: > On Wed, Mar 10, 2021 at 4:59 AM Jason Wang <jasowang@redhat.com> wrote: >> On 2021/3/10 10:22 上午, Jie Deng wrote: >>> On 2021/3/4 17:15, Jason Wang wrote: >>>> >>>>> + } >>>>> + >>>>> + if (msgs[i].flags & I2C_M_RD) >>>>> + memcpy(msgs[i].buf, req->buf, msgs[i].len); >>>> >>>> Sorry if I had asked this before but any rason not to use msg[i].buf >>>> directly? >>>> >>>> >>> The msg[i].buf is passed by the I2C core. I just noticed that these >>> bufs are not >>> always allocated by kmalloc. They may come from the stack, which may >>> cause >>> the check "sg_init_one -> sg_set_buf -> virt_addr_valid" to fail. >>> Therefore the >>> msg[i].buf is not suitable for direct use here. >> Right, stack is virtually mapped. > Maybe there is (or should be) a way to let the i2c core code handle > the bounce buffering in this case. This is surely not a problem that > is unique to this driver, and I'm sure it has come up many times in > the past. > > I see that there is a i2c_get_dma_safe_msg_buf() helper for this > purpose, but it has to be called by the driver rather than the core, > so the driver still needs to keep track of each address when it > sends multiple i2c_msg at once, but maybe it can all be done > inside the sg_table instead of yet another structure. > > At least this one avoids copying data that is marked with the > I2C_M_DMA_SAFE flag. > > Arnd
Make sense. Thanks Arnd. I will try to use those helper functions.
Regards, Jie
| |