[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9e11f1ab-6b7c-d50e-d7db-633ebc3d358c@redhat.com>
Date: Wed, 9 Dec 2020 17:31:41 +0800
From: Jason Wang <jasowang@...hat.com>
To: "Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
"Michael S. Tsirkin" <mst@...hat.com>
Cc: "Enrico Weigelt, metux IT consult" <info@...ux.net>,
linux-kernel@...r.kernel.org, corbet@....net,
linus.walleij@...aro.org, bgolaszewski@...libre.com,
linux-doc@...r.kernel.org, linux-gpio@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
linux-riscv@...ts.infradead.org, stefanha@...hat.com,
msuchanek@...e.de
Subject: Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
On 2020/12/8 下午3:02, Enrico Weigelt, metux IT consult wrote:
> On 08.12.20 03:36, Jason Wang wrote:
>
> Hi,
>
>> So we endup with two solutions (without a prompt):
>>
>> 1) using select, user may end up with driver without transport
> IMHO not an entirely unusual situation in other places of the kernel,
> eg. one can enable USB devices, w/o having an usb host adapter enabled.
>
> And even if some USB-HA driver is enabled, the actualy machine doesn't
> necessarily have the corresponding device.
Ok, then select works for me.
>
>> 2) using depends, user need to enable at least one transport
>>
>> 2) looks a little bit better I admit.
> So, all virtio devices should depend on TRANSPORT_A || TRANSPORT_B ||
> TRANSPORT_C || ... ? (and also change all these places if another
> transport is added) ?
I think not. The idea is, if none of the transport (select VIRTIO) is
enabled, user can not enable any virtio drivers (depends on VIRTIO).
Thanks
>
> --mtx
>
Powered by blists - more mailing lists