All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jie Deng <jie.deng@intel.com>
To: Viresh Kumar <viresh.kumar@linaro.org>, Arnd Bergmann <arnd@arndb.de>
Cc: "Linux I2C" <linux-i2c@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Wolfram Sang" <wsa@kernel.org>,
	"Jason Wang" <jasowang@redhat.com>,
	"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	conghui.chen@intel.com, kblaiech@mellanox.com,
	jarkko.nikula@linux.intel.com,
	"Sergey Semin" <Sergey.Semin@baikalelectronics.ru>,
	"Mike Rapoport" <rppt@kernel.org>,
	loic.poulain@linaro.org, "Tali Perry" <tali.perry1@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	yu1.wang@intel.com, shuo.a.liu@intel.com,
	"Stefan Hajnoczi" <stefanha@redhat.com>
Subject: Re: [PATCH v5] i2c: virtio: add a virtio i2c frontend driver
Date: Tue, 2 Mar 2021 13:06:49 +0800	[thread overview]
Message-ID: <5e66fc1b-81d3-341e-4864-adb021e9ce1e@intel.com> (raw)
In-Reply-To: <20210302042233.7ppagwjk3rah3uh3@vireshk-i7>


On 2021/3/2 12:22, Viresh Kumar wrote:
> On 02-03-21, 09:31, Viresh Kumar wrote:
>> On 01-03-21, 16:19, Arnd Bergmann wrote:
>>> On Mon, Mar 1, 2021 at 7:41 AM Jie Deng <jie.deng@intel.com> wrote:
>>>
>>>> --- /dev/null
>>>> +++ b/include/uapi/linux/virtio_i2c.h
>>>> @@ -0,0 +1,56 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0-or-later WITH Linux-syscall-note */
>>>> +/*
>>>> + * Definitions for virtio I2C Adpter
>>>> + *
>>>> + * Copyright (c) 2021 Intel Corporation. All rights reserved.
>>>> + */
>>>> +
>>>> +#ifndef _UAPI_LINUX_VIRTIO_I2C_H
>>>> +#define _UAPI_LINUX_VIRTIO_I2C_H
>>> Why is this a uapi header? Can't this all be moved into the driver
>>> itself?
>>>
>>>> +/**
>>>> + * struct virtio_i2c_req - the virtio I2C request structure
>>>> + * @out_hdr: the OUT header of the virtio I2C message
>>>> + * @write_buf: contains one I2C segment being written to the device
>>>> + * @read_buf: contains one I2C segment being read from the device
>>>> + * @in_hdr: the IN header of the virtio I2C message
>>>> + */
>>>> +struct virtio_i2c_req {
>>>> +       struct virtio_i2c_out_hdr out_hdr;
>>>> +       u8 *write_buf;
>>>> +       u8 *read_buf;
>>>> +       struct virtio_i2c_in_hdr in_hdr;
>>>> +};
>>> In particular, this structure looks like it is only ever usable between
>>> the transfer functions in the driver itself, it is shared with neither
>>> user space nor the virtio host side.
>> Why is it so ? Won't you expect hypervisors or userspace apps to use
>> these ?
> This comment applies only for the first two structures as the third
> one is never exchanged over virtio.
Yeah. Actually, the backend only needs "struct virtio_i2c_out_hdr out_hdr"
and "struct virtio_i2c_in_hdr in_hdr" for communication. So we only need 
to keep
the first two in uapi and move "struct virtio_i2c_req" into the driver.

But Jason wanted to include "struct virtio_i2c_req" in uapi. He 
explained in this link
https://lists.linuxfoundation.org/pipermail/virtualization/2020-October/050222.html.
Do you agree with that explanation ?

WARNING: multiple messages have this Message-ID (diff)
From: Jie Deng <jie.deng@intel.com>
To: Viresh Kumar <viresh.kumar@linaro.org>, Arnd Bergmann <arnd@arndb.de>
Cc: "Sergey Semin" <Sergey.Semin@baikalelectronics.ru>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	loic.poulain@linaro.org, "Tali Perry" <tali.perry1@gmail.com>,
	yu1.wang@intel.com, "Michael S. Tsirkin" <mst@redhat.com>,
	shuo.a.liu@intel.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	"Wolfram Sang" <wsa@kernel.org>,
	"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
	jarkko.nikula@linux.intel.com,
	"Linux I2C" <linux-i2c@vger.kernel.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	kblaiech@mellanox.com,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	conghui.chen@intel.com, "Mike Rapoport" <rppt@kernel.org>
Subject: Re: [PATCH v5] i2c: virtio: add a virtio i2c frontend driver
Date: Tue, 2 Mar 2021 13:06:49 +0800	[thread overview]
Message-ID: <5e66fc1b-81d3-341e-4864-adb021e9ce1e@intel.com> (raw)
In-Reply-To: <20210302042233.7ppagwjk3rah3uh3@vireshk-i7>


On 2021/3/2 12:22, Viresh Kumar wrote:
> On 02-03-21, 09:31, Viresh Kumar wrote:
>> On 01-03-21, 16:19, Arnd Bergmann wrote:
>>> On Mon, Mar 1, 2021 at 7:41 AM Jie Deng <jie.deng@intel.com> wrote:
>>>
>>>> --- /dev/null
>>>> +++ b/include/uapi/linux/virtio_i2c.h
>>>> @@ -0,0 +1,56 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0-or-later WITH Linux-syscall-note */
>>>> +/*
>>>> + * Definitions for virtio I2C Adpter
>>>> + *
>>>> + * Copyright (c) 2021 Intel Corporation. All rights reserved.
>>>> + */
>>>> +
>>>> +#ifndef _UAPI_LINUX_VIRTIO_I2C_H
>>>> +#define _UAPI_LINUX_VIRTIO_I2C_H
>>> Why is this a uapi header? Can't this all be moved into the driver
>>> itself?
>>>
>>>> +/**
>>>> + * struct virtio_i2c_req - the virtio I2C request structure
>>>> + * @out_hdr: the OUT header of the virtio I2C message
>>>> + * @write_buf: contains one I2C segment being written to the device
>>>> + * @read_buf: contains one I2C segment being read from the device
>>>> + * @in_hdr: the IN header of the virtio I2C message
>>>> + */
>>>> +struct virtio_i2c_req {
>>>> +       struct virtio_i2c_out_hdr out_hdr;
>>>> +       u8 *write_buf;
>>>> +       u8 *read_buf;
>>>> +       struct virtio_i2c_in_hdr in_hdr;
>>>> +};
>>> In particular, this structure looks like it is only ever usable between
>>> the transfer functions in the driver itself, it is shared with neither
>>> user space nor the virtio host side.
>> Why is it so ? Won't you expect hypervisors or userspace apps to use
>> these ?
> This comment applies only for the first two structures as the third
> one is never exchanged over virtio.
Yeah. Actually, the backend only needs "struct virtio_i2c_out_hdr out_hdr"
and "struct virtio_i2c_in_hdr in_hdr" for communication. So we only need 
to keep
the first two in uapi and move "struct virtio_i2c_req" into the driver.

But Jason wanted to include "struct virtio_i2c_req" in uapi. He 
explained in this link
https://lists.linuxfoundation.org/pipermail/virtualization/2020-October/050222.html.
Do you agree with that explanation ?
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2021-03-02  8:21 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-01  6:41 [PATCH v5] i2c: virtio: add a virtio i2c frontend driver Jie Deng
2021-03-01  6:41 ` Jie Deng
2021-03-01 11:54 ` Viresh Kumar
2021-03-01 12:09   ` Andy Shevchenko
2021-03-01 12:09     ` Andy Shevchenko
2021-03-01 12:10     ` Andy Shevchenko
2021-03-01 12:10       ` Andy Shevchenko
2021-03-01 15:46       ` Arnd Bergmann
2021-03-01 15:46         ` Arnd Bergmann
2021-03-02  3:46         ` Viresh Kumar
2021-03-02  3:44       ` Viresh Kumar
2021-03-02  2:21   ` Jie Deng
2021-03-02  2:21     ` Jie Deng
2021-03-02  3:43     ` Viresh Kumar
2021-03-02  6:24       ` Jie Deng
2021-03-02  7:24         ` Viresh Kumar
2021-03-02  8:17           ` Jie Deng
2021-03-02  8:17             ` Jie Deng
2021-03-02  6:28       ` Jie Deng
2021-03-02  6:28         ` Jie Deng
2021-03-01 12:07 ` Andy Shevchenko
2021-03-01 12:07   ` Andy Shevchenko
2021-03-02  7:16   ` Jie Deng
2021-03-02  7:16     ` Jie Deng
2021-03-01 15:19 ` Arnd Bergmann
2021-03-01 15:19   ` Arnd Bergmann
2021-03-02  2:42   ` Jie Deng
2021-03-02  9:51     ` Stefan Hajnoczi
2021-03-02  9:51       ` Stefan Hajnoczi
2021-03-02 10:54       ` Arnd Bergmann
2021-03-02 10:54         ` Arnd Bergmann
2021-03-03 17:48         ` Stefan Hajnoczi
2021-03-03 17:48           ` Stefan Hajnoczi
2021-03-02  4:01   ` Viresh Kumar
2021-03-02  4:22     ` Viresh Kumar
2021-03-02  5:06       ` Jie Deng [this message]
2021-03-02  5:06         ` Jie Deng
2021-03-02  5:16         ` Viresh Kumar
2021-03-02  5:42           ` Jason Wang
2021-03-02  5:42             ` Jason Wang
2021-03-02  4:42 ` Viresh Kumar
2021-03-02  5:21   ` Jie Deng
2021-03-02  5:21     ` Jie Deng
2021-03-02  5:25     ` Viresh Kumar
2021-03-03  7:54 ` Viresh Kumar
2021-03-03  8:46   ` Jie Deng
2021-03-03  8:46     ` Jie Deng
2021-03-03  9:38     ` Viresh Kumar
2021-03-04  1:47       ` Jie Deng
2021-03-04  1:47         ` Jie Deng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5e66fc1b-81d3-341e-4864-adb021e9ce1e@intel.com \
    --to=jie.deng@intel.com \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=conghui.chen@intel.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=jasowang@redhat.com \
    --cc=kblaiech@mellanox.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=mst@redhat.com \
    --cc=rppt@kernel.org \
    --cc=shuo.a.liu@intel.com \
    --cc=stefanha@redhat.com \
    --cc=tali.perry1@gmail.com \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=viresh.kumar@linaro.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=wsa@kernel.org \
    --cc=yu1.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.