* Re: [PATCH v3] drivers: gpio: add virtio-gpio guest driver
[not found] <20201207204838.21406-1-info@metux.net>
@ 2020-12-07 22:13 ` kernel test robot
2020-12-07 22:40 ` kernel test robot
` (2 subsequent siblings)
3 siblings, 0 replies; 4+ messages in thread
From: kernel test robot @ 2020-12-07 22:13 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult, linux-kernel
Cc: kbuild-all, mst, linus.walleij, corbet, linux-doc, virtualization,
bgolaszewski, linux-gpio, info
[-- Attachment #1: Type: text/plain, Size: 4374 bytes --]
Hi "Enrico,
I love your patch! Yet something to improve:
[auto build test ERROR on gpio/for-next]
[also build test ERROR on linux/master linus/master v5.10-rc7 next-20201207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Enrico-Weigelt-metux-IT-consult/drivers-gpio-add-virtio-gpio-guest-driver/20201208-045646
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: h8300-randconfig-r032-20201207 (attached as .config)
compiler: h8300-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/fff1ac3789d850604f11c95b185116bea68e26a9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Enrico-Weigelt-metux-IT-consult/drivers-gpio-add-virtio-gpio-guest-driver/20201208-045646
git checkout fff1ac3789d850604f11c95b185116bea68e26a9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=h8300
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/i2c/Kconfig:8:error: recursive dependency detected!
drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC
drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB
drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU
drivers/gpu/drm/virtio/Kconfig:2: symbol DRM_VIRTIO_GPU depends on VIRTIO
drivers/virtio/Kconfig:2: symbol VIRTIO is selected by GPIO_VIRTIO
drivers/gpio/Kconfig:1628: symbol GPIO_VIRTIO depends on GPIOLIB
drivers/gpio/Kconfig:14: symbol GPIOLIB is selected by I2C_MUX_LTC4306
drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
vim +8 drivers/i2c/Kconfig
da3c6647ee0871 Lan Tianyu 2014-05-20 7
da3c6647ee0871 Lan Tianyu 2014-05-20 @8 config I2C
^1da177e4c3f41 Linus Torvalds 2005-04-16 9 tristate "I2C support"
194684e596af4b Mika Kuoppala 2009-12-06 10 select RT_MUTEXES
4d5538f5882a6b Benjamin Tissoires 2016-10-13 11 select IRQ_DOMAIN
a7f7f6248d9740 Masahiro Yamada 2020-06-14 12 help
622e040d577dc8 Michael Witten 2011-07-08 13 I2C (pronounce: I-squared-C) is a slow serial bus protocol used in
^1da177e4c3f41 Linus Torvalds 2005-04-16 14 many micro controller applications and developed by Philips. SMBus,
^1da177e4c3f41 Linus Torvalds 2005-04-16 15 or System Management Bus is a subset of the I2C protocol. More
^1da177e4c3f41 Linus Torvalds 2005-04-16 16 information is contained in the directory <file:Documentation/i2c/>,
^1da177e4c3f41 Linus Torvalds 2005-04-16 17 especially in the file called "summary" there.
^1da177e4c3f41 Linus Torvalds 2005-04-16 18
^1da177e4c3f41 Linus Torvalds 2005-04-16 19 Both I2C and SMBus are supported here. You will need this for
^1da177e4c3f41 Linus Torvalds 2005-04-16 20 hardware sensors support, and also for Video For Linux support.
^1da177e4c3f41 Linus Torvalds 2005-04-16 21
^1da177e4c3f41 Linus Torvalds 2005-04-16 22 If you want I2C support, you should say Y here and also to the
^1da177e4c3f41 Linus Torvalds 2005-04-16 23 specific driver for your bus adapter(s) below.
^1da177e4c3f41 Linus Torvalds 2005-04-16 24
^1da177e4c3f41 Linus Torvalds 2005-04-16 25 This I2C support can also be built as a module. If so, the module
^1da177e4c3f41 Linus Torvalds 2005-04-16 26 will be called i2c-core.
^1da177e4c3f41 Linus Torvalds 2005-04-16 27
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 16144 bytes --]
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH v3] drivers: gpio: add virtio-gpio guest driver
[not found] <20201207204838.21406-1-info@metux.net>
2020-12-07 22:13 ` [PATCH v3] drivers: gpio: add virtio-gpio guest driver kernel test robot
@ 2020-12-07 22:40 ` kernel test robot
2020-12-07 23:03 ` Randy Dunlap
2020-12-08 1:20 ` Randy Dunlap
3 siblings, 0 replies; 4+ messages in thread
From: kernel test robot @ 2020-12-07 22:40 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult, linux-kernel
Cc: kbuild-all, mst, linus.walleij, corbet, linux-doc, virtualization,
bgolaszewski, linux-gpio, info
[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]
Hi "Enrico,
I love your patch! Yet something to improve:
[auto build test ERROR on gpio/for-next]
[also build test ERROR on linux/master linus/master v5.10-rc7 next-20201207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Enrico-Weigelt-metux-IT-consult/drivers-gpio-add-virtio-gpio-guest-driver/20201208-045646
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: i386-randconfig-m021-20201207 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# https://github.com/0day-ci/linux/commit/fff1ac3789d850604f11c95b185116bea68e26a9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Enrico-Weigelt-metux-IT-consult/drivers-gpio-add-virtio-gpio-guest-driver/20201208-045646
git checkout fff1ac3789d850604f11c95b185116bea68e26a9
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/Kconfig:74:error: recursive dependency detected!
drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU
drivers/gpu/drm/virtio/Kconfig:2: symbol DRM_VIRTIO_GPU depends on VIRTIO
drivers/virtio/Kconfig:2: symbol VIRTIO is selected by GPIO_VIRTIO
drivers/gpio/Kconfig:1628: symbol GPIO_VIRTIO depends on GPIOLIB
drivers/gpio/Kconfig:14: symbol GPIOLIB is selected by I2C_MUX_LTC4306
drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C
drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC
drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB
drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
vim +74 drivers/gpu/drm/Kconfig
6fcefd56f5060c Dave Airlie 2009-09-08 @74 config DRM_KMS_HELPER
13a8195b148615 Dave Airlie 2009-09-07 75 tristate
13a8195b148615 Dave Airlie 2009-09-07 76 depends on DRM
92b6f89f6b85f4 Daniel Vetter 2013-10-08 77 help
92b6f89f6b85f4 Daniel Vetter 2013-10-08 78 CRTC helpers for KMS drivers.
92b6f89f6b85f4 Daniel Vetter 2013-10-08 79
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 36582 bytes --]
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH v3] drivers: gpio: add virtio-gpio guest driver
[not found] <20201207204838.21406-1-info@metux.net>
2020-12-07 22:13 ` [PATCH v3] drivers: gpio: add virtio-gpio guest driver kernel test robot
2020-12-07 22:40 ` kernel test robot
@ 2020-12-07 23:03 ` Randy Dunlap
2020-12-08 1:20 ` Randy Dunlap
3 siblings, 0 replies; 4+ messages in thread
From: Randy Dunlap @ 2020-12-07 23:03 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult, linux-kernel
Cc: corbet, mst, linus.walleij, linux-doc, virtualization,
bgolaszewski, linux-gpio, linux-riscv
On 12/7/20 12:48 PM, Enrico Weigelt, metux IT consult wrote:
> Introducing new GPIO driver for virtual GPIO devices via virtio.
Introduce
>
> The driver allows routing GPIO control into VM guests, eg. brigding
> virtual gpios to specific host gpios, or attaching simulators for
> automatic application testing.
>
These ...
> Changes v3:
> * spec: fixed type names
> * spec: replace "host"/"guest" by "device"/"cpu"
> * spec: change terminology from "events" to "messages"
> * driver: fixed missing can_sleep flag
> * driver: select VIRTIO instead of depends on
> * driver: drop references to qemu in Kconfig
> * driver: fixed incomplete error handling and possible deadlock
> in case of sending buf failed
> * driver: dropped unneeded WARN_ON
> * driver: fixed retval of virtio_gpio_xmit()
> * driver: dynamically allocate virtio buffers
> * driver: added locking on gpio operations
> * driver: added irq_chip functions
>
> Changes v2:
> * uapi: fixed header license
> * driver: sorted include's
> * driver: fixed formatting
> * driver: fixed unneeded devm allocation - plain kzalloc/kfree is enough
> * driver: fixed missing devm_kzalloc fail check
> * driver: use devm_kcalloc() for array allocation
> * spec: added virtio-gpio protocol specification
... Vx change descriptions go after the following "---" line.
I usually put them before the diffstat, with one blank line
separating them.
>
> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> ---
> Documentation/gpio/virtio-gpio.rst | 176 +++++++++++++++++
> MAINTAINERS | 6 +
> drivers/gpio/Kconfig | 7 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-virtio.c | 381 +++++++++++++++++++++++++++++++++++++
> include/uapi/linux/virtio_gpio.h | 39 ++++
> include/uapi/linux/virtio_ids.h | 1 +
> 7 files changed, 611 insertions(+)
> create mode 100644 Documentation/gpio/virtio-gpio.rst
> create mode 100644 drivers/gpio/gpio-virtio.c
> create mode 100644 include/uapi/linux/virtio_gpio.h
>
> diff --git a/Documentation/gpio/virtio-gpio.rst b/Documentation/gpio/virtio-gpio.rst
> new file mode 100644
> index 000000000000..e7bf01ec1ce7
> --- /dev/null
> +++ b/Documentation/gpio/virtio-gpio.rst
> @@ -0,0 +1,176 @@
> +"""""""""""""""""
> +Virtio-GPIO protocol specification
> +"""""""""""""""""
> +...........
> +Specification for virtio-based virtiual GPIO devices
virtual
although it seems redundant.
> +...........
> +
> ++------------
> ++Version_ 1.0
> ++------------
> +
> +===================
> +General
> +===================
> +
> +The virtio-gpio protocol provides access to general purpose IO devices
> +to virtual machine guests. These virtualized GPIOs could be either provided
in (?)
> +by some simulator (eg. virtual HIL), routed to some external device or
(e.g.
> +routed to real GPIOs on the host (eg. virtualized embedded applications).
(e.g.
> +
> +Instead of simulating some existing real GPIO chip within an VMM, this
within a
and why not just "VM"?
> +protocol provides an hardware independent interface between host and guest
a hardware
> +that solely relies on an active virtio connection (no matter which transport
> +actually used), no other buses or additional platform driver logic required.
> +
> +===================
> +Protocol layout
> +===================
> +
> +----------------------
> +Configuration space
> +----------------------
> +
> ++--------+----------+-------------------------------+
> +| Offset | Type | Description |
> ++========+==========+===============================+
> +| 0x00 | u8 | version |
> ++--------+----------+-------------------------------+
> +| 0x02 | u16 | number of GPIO lines |
> ++--------+----------+-------------------------------+
> +| 0x04 | u32 | size of gpio name block |
> ++--------+----------+-------------------------------+
> +| 0x20 | char[32] | device name (0-terminated) |
> ++--------+----------+-------------------------------+
> +| 0x40 | char[] | line names block |
> ++--------+----------+-------------------------------+
> +
> +- for version field currently only value 1 supported.
> +- the line names block holds a stream of zero-terminated strings,
> + holding the individual line names.
> +- unspecified fields are reserved for future use and should be zero.
> +
> +------------------------
> +Virtqueues and messages:
> +------------------------
> +
> +- Queue #0: transmission from device to cpu
CPU
> +- Queue #1: transmission from cpu to device
CPU
> +
> +The queues transport messages of the struct virtio_gpio_msg:
> +
> +Message format:
> +---------------
> +
> ++--------+----------+---------------+
> +| Offset | Type | Description |
> ++========+==========+===============+
> +| 0x00 | uint16 | event type |
> ++--------+----------+---------------+
> +| 0x02 | uint16 | line id |
> ++--------+----------+---------------+
> +| 0x04 | uint32 | value |
> ++--------+----------+---------------+
> +
> +Message types:
> +--------------
Do the Message types go into the "event type" field above?
Please clarify.
> +
> ++-------+----------------------------------------+-----------------------------+
> +| Code | Symbol | |
> ++=======+========================================+=============================+
> +| 0x01 | VIRTIO_GPIO_MSG_GUEST_REQUEST | request gpio line |
> ++-------+---------------------------------------+-----------------------------+
> +| 0x02 | VIRTIO_GPIO_MSG_GUEST_DIRECTION_INPUT | set direction to input |
> ++-------+---------------------------------------+-----------------------------+
> +| 0x03 | VIRTIO_GPIO_MSG_GUEST_DIRECTION_OUTPUT | set direction to output |
> ++-------+---------------------------------------+-----------------------------+
> +| 0x04 | VIRTIO_GPIO_MSG_GUEST_GET_DIRECTION | read current direction |
> ++-------+---------------------------------------+-----------------------------+
> +| 0x05 | VIRTIO_GPIO_MSG_GUEST_GET_VALUE | read current level |
> ++-------+---------------------------------------+-----------------------------+
> +| 0x06 | VIRTIO_GPIO_MSG_GUEST_SET_VALUE | set current (out) level |
> ++-------+---------------------------------------+-----------------------------+
> +| 0x11 | VIRTIO_GPIO_MSG_HOST_LEVEL | state changed (host->guest) |
> ++-------+----------------+-----------------------+-----------------------------+
> +
> +----------------------
> +Data flow:
> +----------------------
> +
> +- all operations, except ``VIRTIO_GPIO_MSG_HOST_LEVEL``, are guest-initiated
> +- host replies ``VIRTIO_GPIO_MSG_HOST_LEVEL`` OR'ed to the ``type`` field
> +- ``VIRTIO_GPIO_MSG_HOST_LEVEL`` is only sent asynchronically from host to guest
asynchronously
> +- in replies, a negative ``value`` field denotes an unix-style errno code
a Unix-style
> +- valid direction values are:> + * 0 = output
> + * 1 = input
> +- valid line state values are:
> + * 0 = inactive
> + * 1 = active
> +
> +VIRTIO_GPIO_MSG_GUEST_REQUEST
> +----------------------------
> +
> +- notify the host that given line# is going to be used
> +- request:
> + * ``line`` field: line number
> + * ``value`` field: unused
> +- reply:
> + * ``value`` field: errno code (0 = success)
> +
> +VIRTIO_GPIO_MSG_GUEST_DIRECTION_INPUT
> +------------------------------------
> +
> +- set line line direction to input
> +- request:
> + * ``line`` field: line number
> + * ``value`` field: unused
> +- reply: value field holds errno
> + * ``value`` field: errno code (0 = success)
> +
> +VIRTIO_GPIO_MSG_GUEST_DIRECTION_OUTPUT
> +-------------------------------------
> +
> +- set line direction to output and given line state
> +- request:
> + * ``line`` field: line number
> + * ``value`` field: output state (0=inactive, 1=active)
> +- reply:
> + * ``value`` field: holds errno
> +
> +VIRTIO_GPIO_MSG_GUEST_GET_DIRECTION
> +----------------------------------
> +
> +- retrieve line direction
> +- request:
> + * ``line`` field: line number
> + * ``value`` field: unused
> +- reply:
> + * ``value`` field: direction (0=output, 1=input) or errno code
> +
> +VIRTIO_GPIO_MSG_GUEST_GET_VALUE
> +------------------------------
> +
> +- retrieve line state value
> +- request:
> + * ``line`` field: line number
> + * ``value`` field: unused
> +- reply:
> + * ``value`` field: line state (0=inactive, 1=active) or errno code
> +
> +VIRTIO_GPIO_MSG_GUEST_SET_VALUE
> +------------------------------
> +
> +- set line state value (output only)
> +- request:
> + * ``line`` field: line number
> + * ``value`` field: line state (0=inactive, 1=active)
> +- reply:
> + * ``value`` field: new line state or errno code
> +
> +VIRTIO_GPIO_MSG_HOST_LEVEL
> +-------------------------
> +
> +- async notification from host to gues: line state changed
guest:
> +- ``line`` field: line number
> +- ``value`` field: new line state (0=inactive, 1=active)
--
~Randy
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH v3] drivers: gpio: add virtio-gpio guest driver
[not found] <20201207204838.21406-1-info@metux.net>
` (2 preceding siblings ...)
2020-12-07 23:03 ` Randy Dunlap
@ 2020-12-08 1:20 ` Randy Dunlap
3 siblings, 0 replies; 4+ messages in thread
From: Randy Dunlap @ 2020-12-08 1:20 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult, linux-kernel
Cc: corbet, mst, linus.walleij, linux-doc, virtualization,
bgolaszewski, linux-gpio, linux-riscv
On 12/7/20 12:48 PM, Enrico Weigelt, metux IT consult wrote:
> Introducing new GPIO driver for virtual GPIO devices via virtio.
>
Oops, I missed one thing:
>
> diff --git a/Documentation/gpio/virtio-gpio.rst b/Documentation/gpio/virtio-gpio.rst
> new file mode 100644
> index 000000000000..e7bf01ec1ce7
> --- /dev/null
> +++ b/Documentation/gpio/virtio-gpio.rst
> @@ -0,0 +1,176 @@
> +"""""""""""""""""
> +Virtio-GPIO protocol specification
> +"""""""""""""""""
In Documentation/doc-guide/sphinx.rst, it says to please use the
following heading adornments....
and """""...""""" is not one of them.
Neither is "..........".
Also, only use an overline for the document title and not for
lower level headings.
Here are the expected heading adornments:
1. ``=`` with overline for document title::
==============
Document title
==============
2. ``=`` for chapters::
Chapters
========
3. ``-`` for sections::
Section
-------
4. ``~`` for subsections::
Subsection
~~~~~~~~~~
> +...........
> +Specification for virtio-based virtiual GPIO devices
> +...........
> +
> ++------------
> ++Version_ 1.0
> ++------------
> +
> +===================
> +General
> +===================
> +
> +The virtio-gpio protocol provides access to general purpose IO devices
> +to virtual machine guests. These virtualized GPIOs could be either provided
> +by some simulator (eg. virtual HIL), routed to some external device or
> +routed to real GPIOs on the host (eg. virtualized embedded applications).
> +
> +Instead of simulating some existing real GPIO chip within an VMM, this
> +protocol provides an hardware independent interface between host and guest
> +that solely relies on an active virtio connection (no matter which transport
> +actually used), no other buses or additional platform driver logic required.
> +
> +===================
> +Protocol layout
> +===================
> +
> +----------------------
> +Configuration space
> +----------------------
thanks.
--
~Randy
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 4+ messages in thread