[PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver

Enrico Weigelt, metux IT consult lkml at metux.net
Mon Dec 7 15:34:55 EST 2020


On 07.12.20 14:52, Michael S. Tsirkin wrote:

>> See above: NAK. because it can't even be enabled directly (by the user).
>> If it wasn't meant otherwise, we'd have to add an menu text.
> 
> The point is that user enables one of the bindings.
> That in turn enables drivers. If we merely select VIRTIO
> there's a chance user won't remember to select any bindings
> and will be surprised not to see any devices.

Not sure what you mean by "bindings" ... transports ?

IMHO, transports and device drivers are entirely orthogonal. Both *use*
the core, but I don't think they shall only show up, after the core was
enabled explicitly. Any combination of transports is valid (having none
at all, of course, isn't actually useful).

>> When using other transports ?
> 
> Any transport selects VIRTIO so if you enable that, you get
> VIRTIO and thus it's enough to depend on it.

The combination of 'select VIRTIO' and 'depends on VIRTIO' is what
caused the recursive dependency. Chaning everything to 'select VIRTIO'
fixed that.

>> I don't thinkt that would be good - instead everybody should just select
>> VIRTIO, never depend on it (maybe depend on VIRTIO_MENU instead)
> 
> GPU depends on VIRTIO and on VIRTIO_MENU ... which seems even messier
> ...

See:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2404871.html


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info at metux.net -- +49-151-27565287



More information about the linux-riscv mailing list