All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jie Deng <jie.deng@intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Wolfram Sang <wsa@kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Vincent Whitchurch <vincent.whitchurch@axis.com>,
	virtualization@lists.linux-foundation.org,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel@axis.com
Subject: Re: [PATCH 1/2] i2c: virtio: disable timeout handling
Date: Wed, 20 Oct 2021 14:35:49 +0800	[thread overview]
Message-ID: <8e182ea8-5016-fa78-3d77-eefba7d58612@intel.com> (raw)
In-Reply-To: <YW+q1yQ8MuhHINAs@kroah.com>

On 2021/10/20 13:36, Greg KH wrote:

> On Wed, Oct 20, 2021 at 12:20:13PM +0800, Jie Deng wrote:
>> On 2021/10/20 2:14, Wolfram Sang wrote:
>>>> I think it is set to HZ currently, though I haven't tried big
>>>> transfers but I still get into some issues with Qemu based stuff.
>>>> Maybe we can bump it up to few seconds :)
>>> If you use adapter->timeout, this can even be set at runtime using a
>>> ioctl. So, it can adapt to use cases. Of course, the driver should
>>> initialize it to a sane default if the automatic default (HZ) is not
>>> suitable.
>>
>> I think a big value may solve most cases. but the driver never know how big
>> is enough by static configuration.
>>
>> Can we make this value to be configurable, just let the other side provide
>> this value ?
> If an ioctl can change it, that would mean it is configurable, right?


Yes, but we need to know what's the best value to be configured for a 
specific "other side".

I think the "other side" should be more aware of what value is 
reasonable to be used.




WARNING: multiple messages have this Message-ID (diff)
From: Jie Deng <jie.deng@intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Vincent Whitchurch <vincent.whitchurch@axis.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Wolfram Sang <wsa@kernel.org>,
	kernel@axis.com, linux-i2c@vger.kernel.org
Subject: Re: [PATCH 1/2] i2c: virtio: disable timeout handling
Date: Wed, 20 Oct 2021 14:35:49 +0800	[thread overview]
Message-ID: <8e182ea8-5016-fa78-3d77-eefba7d58612@intel.com> (raw)
In-Reply-To: <YW+q1yQ8MuhHINAs@kroah.com>

On 2021/10/20 13:36, Greg KH wrote:

> On Wed, Oct 20, 2021 at 12:20:13PM +0800, Jie Deng wrote:
>> On 2021/10/20 2:14, Wolfram Sang wrote:
>>>> I think it is set to HZ currently, though I haven't tried big
>>>> transfers but I still get into some issues with Qemu based stuff.
>>>> Maybe we can bump it up to few seconds :)
>>> If you use adapter->timeout, this can even be set at runtime using a
>>> ioctl. So, it can adapt to use cases. Of course, the driver should
>>> initialize it to a sane default if the automatic default (HZ) is not
>>> suitable.
>>
>> I think a big value may solve most cases. but the driver never know how big
>> is enough by static configuration.
>>
>> Can we make this value to be configurable, just let the other side provide
>> this value ?
> If an ioctl can change it, that would mean it is configurable, right?


Yes, but we need to know what's the best value to be configured for a 
specific "other side".

I think the "other side" should be more aware of what value is 
reasonable to be used.



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

  reply	other threads:[~2021-10-20  6:35 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-19  7:46 [PATCH 0/2] virtio-i2c: Fix buffer handling Vincent Whitchurch
2021-10-19  7:46 ` Vincent Whitchurch
2021-10-19  7:46 ` [PATCH 1/2] i2c: virtio: disable timeout handling Vincent Whitchurch
2021-10-19  7:46   ` Vincent Whitchurch
2021-10-19  8:09   ` Viresh Kumar
2021-10-19  8:09     ` Viresh Kumar
2021-10-19  9:36     ` Greg KH
2021-10-19  9:36       ` Greg KH
2021-10-19  9:42       ` Viresh Kumar
2021-10-19  9:42         ` Viresh Kumar
2021-10-19 11:15         ` Wolfram Sang
2021-10-19 14:14           ` Viresh Kumar
2021-10-19 14:14             ` Viresh Kumar
2021-10-19 11:16         ` Greg KH
2021-10-19 11:16           ` Greg KH
2021-10-19 14:37           ` Viresh Kumar
2021-10-19 14:37             ` Viresh Kumar
2021-10-19 18:14             ` Wolfram Sang
2021-10-20  4:20               ` Jie Deng
2021-10-20  4:20                 ` Jie Deng
2021-10-20  5:36                 ` Greg KH
2021-10-20  5:36                   ` Greg KH
2021-10-20  6:35                   ` Jie Deng [this message]
2021-10-20  6:35                     ` Jie Deng
2021-10-20  6:41                     ` Viresh Kumar
2021-10-20  6:41                       ` Viresh Kumar
2021-10-20  7:04                       ` Jie Deng
2021-10-20  7:04                         ` Jie Deng
2021-10-20 10:55                         ` Vincent Whitchurch
2021-10-20 10:55                           ` Vincent Whitchurch
2021-10-20 11:03                           ` Viresh Kumar
2021-10-20 11:03                             ` Viresh Kumar
2021-10-21  3:30                             ` Jie Deng
2021-10-21  3:30                               ` Jie Deng
2021-10-29 12:24                               ` Vincent Whitchurch
2021-10-29 12:24                                 ` Vincent Whitchurch
2021-11-01  5:23                                 ` Jie Deng
2021-11-01  5:23                                   ` Jie Deng
2021-11-03  6:18                                   ` Chen, Conghui
2021-11-03  6:37                                     ` Viresh Kumar
2021-11-03  6:37                                       ` Viresh Kumar
2021-11-03 14:42                                       ` Vincent Whitchurch
2021-11-03 14:42                                         ` Vincent Whitchurch
2021-11-09  4:52                                         ` Viresh Kumar
2021-11-09  4:52                                           ` Viresh Kumar
2021-10-20  3:36     ` Jie Deng
2021-10-20  3:36       ` Jie Deng
2021-10-19  7:46 ` [PATCH 2/2] i2c: virtio: fix completion handling Vincent Whitchurch
2021-10-19  7:46   ` Vincent Whitchurch
2021-10-19  8:22   ` Viresh Kumar
2021-10-19  8:22     ` Viresh Kumar
2021-10-20  8:54     ` Jie Deng
2021-10-20  8:54       ` Jie Deng
2021-10-20  9:17       ` Viresh Kumar
2021-10-20  9:17         ` Viresh Kumar
2021-10-20 10:38         ` Vincent Whitchurch
2021-10-20 10:38           ` Vincent Whitchurch
2021-10-20 10:47           ` Viresh Kumar
2021-10-20 10:47             ` Viresh Kumar
2021-10-29 11:54             ` Vincent Whitchurch
2021-10-29 11:54               ` Vincent Whitchurch
2021-10-21  5:55   ` Jie Deng
2021-10-21  5:55     ` Jie Deng
2021-10-21  5:58     ` Viresh Kumar
2021-10-21  5:58       ` Viresh Kumar
2021-11-02  4:32   ` Viresh Kumar
2021-11-02  4:32     ` Viresh Kumar

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=8e182ea8-5016-fa78-3d77-eefba7d58612@intel.com \
    --to=jie.deng@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel@axis.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vincent.whitchurch@axis.com \
    --cc=viresh.kumar@linaro.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wsa@kernel.org \
    /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.