OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] Re: [PATCH V2] virtio: i2c: Allow zero-length transactions


On Wed, Aug 18, 2021 at 5:26 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 18-08-21, 10:38, Jie Deng wrote:
> >
> > From the perspective of specificationïI think we can allow zero-length
> > buffers in virtio.
> >
> > we can use the len of descriptor to see if it is a zero-length buffer.
> >
> > But for a specific implementation, I don't think "NULL" can be passed to
> > this API.
> >
> > There is a check "BUG_ON(!virt_addr_valid(buf))" in it.
>
> I tried to look at implementations of virt_addr_valid() and it doesn't
> check for NULL specifically (for the ones I looked at). I haven't
> tested it though.
>
> Though I am not sure what's better here, remove the need of sending
> buffer altogether, the way this patch proposed initially or what
> Michael has suggested. And all that to prevent just a single bit to be
> used in flags field, which will likely be used for more things later
> on.

I'd prefer your earlier approach.

My feeling is that changing the virtqueue code to allow zero-length
buffers is more fragile than having something in the virtio-i2c code
that has a special case for leaving out both read_buf and write_buf.

Even if we fix the linux virtqueue code to deal with zero-length
NULL buffers, there are other implementations that will require
similar workarounds for existing sanity checks.

       Arnd


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]