linux-kernel - Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210324060907.nwilmghg2xcdz7nv@vireshk-i7>
Date:   Wed, 24 Mar 2021 11:39:07 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Jie Deng <jie.deng@...el.com>
Cc:     linux-i2c@...r.kernel.org,
        virtualization@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org, mst@...hat.com, wsa@...nel.org,
        jasowang@...hat.com, wsa+renesas@...g-engineering.com,
        andriy.shevchenko@...ux.intel.com, conghui.chen@...el.com,
        arnd@...db.de, kblaiech@...lanox.com,
        jarkko.nikula@...ux.intel.com, Sergey.Semin@...kalelectronics.ru,
        rppt@...nel.org, loic.poulain@...aro.org, tali.perry1@...il.com,
        u.kleine-koenig@...gutronix.de, bjorn.andersson@...aro.org,
        yu1.wang@...el.com, shuo.a.liu@...el.com, stefanha@...hat.com,
        pbonzini@...hat.com
Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver

On 24-03-21, 14:05, Jie Deng wrote:
> For simplicity, the original patch sent only 1 message to vq each time . I
> changed the way to send

I missed those earlier discussions :)

> a batch of requests in one time in order to improve efficiency according to
> Jason' suggestion.

I agree.

> As we discussed in the previous emails, the device can raise interrupt when
> some requests are still not completed
> 
> though this is not a good operation.  In this case, the remaining requests
> in the vq will be ignored and
> 
> the i2c_algorithm. master_xfer will return 1 for your example. I will
> clarify this in the specs.

Right, this needs to be clarified that the receiver shall generate the interrupt
only once the virtqueue is empty, not in the middle of it.

Or, now that I think about it a bit more, another thing we can do here is see if
virtqueue_get_buf() returns NULL, if it does then we should keep expecting more
messages as it may be early interrupt. What do you say ?


-- 
viresh