these functions in,
> independently of any Kconfig option. Thanks to that, bugs and other
> regressions are subsequently easier to catch.
>
> Signed-off-by: Paul Cercueil
>
> ---
> Cc: Conghui Chen
> Cc: Viresh Kumar
> Cc: virtualization@lists.linux-foundation.org
&g
it was
primarily developed by Intel engineers.
Acked-by: Viresh Kumar
--
viresh
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
dex a8c8f6b42436..44747f4641a6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21920,7 +21920,7 @@ F:include/uapi/linux/virtio_snd.h
> F: sound/virtio/*
>
> VIRTIO I2C DRIVER
> -M: Conghui Chen
> +M: Jian Jun Chen
> M: Viresh Kumar
> L:
n/devicetree/bindings/opp/opp-v2-base.yaml | 2 +-
> Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml | 2 +-
> Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml| 2 +-
> Documentation/devicetree/bindings/opp/opp-v2.yaml | 2 +-
A
Hi Oleksandr,
On Mon, Jun 6, 2022 at 10:16 AM Oleksandr Tyshchenko
wrote:
> The high level idea is to create new Xen’s grant table based DMA-mapping
> layer for the guest Linux whose main
> purpose is to provide a special 64-bit DMA address which is formed by using
> the grant reference (for a
;
>
> if (unlikely(res->status != VIRTIO_GPIO_STATUS_OK)) {
> dev_err(dev, "GPIO request failed: %d\n", gpio);
Acked-by: Viresh Kumar
--
viresh
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
s to be
> completed.
>
> Fixes: 3cfc88380413d20f ("i2c: virtio: add a virtio i2c frontend driver")
> Acked-by: Viresh Kumar
> Signed-off-by: Vincent Whitchurch
> ---
>
> Notes:
> v3: Wait for all completions instead of only the last one.
LGTM, thanks.
-
On 25-11-21, 07:24, Wolfram Sang wrote:
>
> > Wolfram, you can apply that one as well, it looks okay.
>
> Is it? I read that the code only waits for the last request while
> Michael suggested to wait for all of them? And he did not ack patch 2
> while he acked patch 1. Did I misunderstand?
On 24-11-21, 18:55, Michael S. Tsirkin wrote:
> On Thu, Nov 11, 2021 at 05:04:10PM +0100, Vincent Whitchurch wrote:
> > This fixes a couple of bugs in the buffer handling in virtio-i2c which can
> > result in incorrect data on the I2C bus or memory corruption in the guest.
> >
> > I tested this
no simple fix for this (the driver would have to always create
> > bounce buffers and hold on to them until the device eventually returns
> > the buffers), so just disable the timeout support for now.
> >
> > Fixes: 3cfc88380413d20f ("i2c: virtio: add a virtio i2c frontend dri
On 11-11-21, 17:04, Vincent Whitchurch wrote:
> If a timeout is hit, it can result is incorrect data on the I2C bus
> and/or memory corruptions in the guest since the device can still be
> operating on the buffers it was given while the guest has freed them.
>
> Here is, for example, the start of
On 09-11-21, 08:23, cgel@gmail.com wrote:
> From: chiminghao
>
> Fix the following coccicheck REVIEW:
> ./drivers/gpio/gpio-virtio.c:437:2-3 REVIEW Unneeded semicolon
>
> Reported-by: Zeal Robot
> Signed-off-by: chiminghao
> ---
> drivers/gpio/gpio-virtio.c | 2 +-
> 1 file changed, 1
On 03-11-21, 15:42, Vincent Whitchurch wrote:
> The suggested timeout is not meant to take into account the overhead of
> virtualization, but to be used by the virtio device as a timeout for the
> transaction on the I2C bus (presumably by programming this value to the
> physical I2C controller, if
ret = generic_handle_domain_irq(vgpio->gc.irq.domain, gpio);
> if (ret)
> dev_err(dev, "failed to handle interrupt: %d\n", ret);
> - };
> + }
> }
>
> static void vi
On 04-11-21, 16:37, Bartosz Golaszewski wrote:
> I picked up the v7 I see in patchwork (but not in my inbox :( )
I did send it to and can see both in the --to field:
Bartosz Golaszewski ,
Bartosz Golaszewski ,
Anything wrong there ?
--
viresh
___
On 03-11-21, 06:18, Chen, Conghui wrote:
> >>> Over the long term, I think the backend should provide that timeout
> >>> value and guarantee that its processing time should not exceed that
> >>> value.
> >> If you mean that the spec should be changed to allow the virtio driver
> >> to be able to
fers to be
> completed.
>
Add a fixes tag here please, so it can get picked to the buggy kernel
version as well.
> Signed-off-by: Vincent Whitchurch
Acked-by: Viresh Kumar
--
viresh
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
ude/uapi/linux/virtio_gpio.h
> @@ -25,7 +25,7 @@ struct virtio_gpio_config {
> __le16 ngpio;
> __u8 padding[2];
> __le32 gpio_names_size;
> -} __packed;
> +};
Acked-by: Viresh Kumar
--
viresh
___
Virtualizati
MAINTAINERS
> index 3b79fd4..8c9a677 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19944,7 +19944,7 @@ F:include/uapi/linux/virtio_snd.h
> F: sound/virtio/*
>
> VIRTIO I2C DRIVER
> -M: Jie Deng
> +M: Conghui Chen
> M: Viresh Kumar
> L:
On 21-10-21, 15:17, Viresh Kumar wrote:
> The virtio specification received a new mandatory feature
> (VIRTIO_I2C_F_ZERO_LENGTH_REQUEST) for zero length requests. Fail if the
> feature isn't offered by the device.
>
> For each read-request, set the VIRTIO_I2C_FLAGS_M_RD fl
On 22-10-21, 06:11, Michael S. Tsirkin wrote:
> On Thu, Oct 21, 2021 at 04:34:19PM +0530, Viresh Kumar wrote:
> > This patch adds IRQ support for the virtio GPIO driver. Note that this
> > uses the irq_bus_lock/unlock() callbacks, since those operations over
> > virtio may sle
On 22-10-21, 14:51, Jie Deng wrote:
> > + if (!virtio_has_feature(vdev, VIRTIO_I2C_F_ZERO_LENGTH_REQUEST)) {
> > + dev_err(>dev, "Zero-length request feature is
> > mandatory\n");
> > + return -EINVAL;
>
>
> It might be better to return -EOPNOTSUPP ?
Maybe that or one of
This patch adds IRQ support for the virtio GPIO driver. Note that this
uses the irq_bus_lock/unlock() callbacks, since those operations over
virtio may sleep.
Reviewed-by: Linus Walleij
Signed-off-by: Viresh Kumar
---
Bartosz,
The spec changes are close to merging now, I will let you know once
On 21-10-21, 13:02, Geert Uytterhoeven wrote:
> Exactly. And on CRIS (no longer supported by Linux), there won't
> be any padding.
>
> So I recommend to always add explicit padding, to make sure all
> members are aligned naturally on all systems.
Right.
--
viresh
On 21-10-21, 12:07, Geert Uytterhoeven wrote:
> On Thu, Oct 21, 2021 at 11:52 AM Viresh Kumar wrote:
> > The structure will get aligned to the size of largest element and each
> > element will be aligned to itself. I don't see how this will break
> > even in case of 32
On 21-10-21, 12:58, Andy Shevchenko wrote:
> I admit I haven't looked into the specification, but in the past we
> had had quite an issue exactly in GPIO on kernel side because of this
> kind of design mistake.
> The problem here if in the future one wants to
> supply more than one item at a
On 21-10-21, 12:42, Andy Shevchenko wrote:
> On Thu, Oct 21, 2021 at 7:34 AM Viresh Kumar wrote:
> > On 20-10-21, 18:10, Andy Shevchenko wrote:
> > > IIRC you add dead code. IRQ framework never calls this if type is not set.
> >
> > Yes, but it is allowed to cal
.
This allows us to support zero length requests, like SMBUS Quick, where
the buffer need not be sent anymore.
Signed-off-by: Viresh Kumar
---
Hi Wolfram,
Please do not apply this until the spec changes [1] are merged, sending it early
to get review done. I will ping you later once the spec is merged.
[1
On 21-10-21, 13:55, Jie Deng wrote:
> Can the backend driver control the time point of interrupt injection ? I
> can't think of
>
> why the backend has to send an early interrupt. This operation should be
> avoided
>
> in the backend driver if possible. However, this change make sense if early
>
On 20-10-21, 18:10, Andy Shevchenko wrote:
> On Wednesday, October 20, 2021, Viresh Kumar
> wrote:
> > +static int virtio_gpio_irq_set_type(struct irq_data *d, unsigned int
> > type)
> > +{
> > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> &g
On 20-10-21, 12:55, Vincent Whitchurch wrote:
> If the timeout cannot be disabled, then the driver should be fixed to
> always copy buffers and hold on to them to avoid memory corruption in
> the case of timeout, as I mentioned in my commit message. That would be
> quite a substantial change to
On 20-10-21, 12:38, Vincent Whitchurch wrote:
> I don't quite understand how that would be safe since
> virtqueue_add_sgs() can fail after a few iterations and all queued
> request buffers can have FAIL_NEXT set. In such a case, we would end up
> waiting forever with your proposed change,
This patch adds IRQ support for the virtio GPIO driver. Note that this
uses the irq_bus_lock/unlock() callbacks, since those operations over
virtio may sleep.
Reviewed-by: Linus Walleij
Signed-off-by: Viresh Kumar
---
Bartosz,
The spec changes are close to merging now, I will let you know once
On 20-10-21, 16:54, Jie Deng wrote:
>
> On 2021/10/19 16:22, Viresh Kumar wrote:
> > On 19-10-21, 09:46, Vincent Whitchurch wrote:
> > > static void virtio_i2c_msg_done(struct virtqueue *vq)
> > > {
> > > - struct virtio_i2c *vi = vq->vdev
On 20-10-21, 14:35, Jie Deng wrote:
> 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.
If we _really_ need that, then it would require an update to the
On 19-10-21, 13:16, Greg KH wrote:
> On Tue, Oct 19, 2021 at 03:12:03PM +0530, Viresh Kumar wrote:
> > On 19-10-21, 11:36, Greg KH wrote:
> > > What is the "other side" here? Is it something that you trust or not?
> >
> > Other side can be a remo
On 19-10-21, 13:15, Wolfram Sang wrote:
>
> > The other side is the software that has access to the _Real_ hardware,
> > and so we should trust it. So we can have a actually have a completion
> > without timeout here, interesting.
>
> So, if the other side gets a timeout talking to the HW, then
On 19-10-21, 11:36, Greg KH wrote:
> What is the "other side" here? Is it something that you trust or not?
Other side can be a remote processor (for remoteproc over virtio or
something similar), or traditionally it can be host OS or host
firmware providing virtualisation to a Guest running Linux
On 19-10-21, 09:46, Vincent Whitchurch wrote:
> static void virtio_i2c_msg_done(struct virtqueue *vq)
> {
> - struct virtio_i2c *vi = vq->vdev->priv;
> + struct virtio_i2c_req *req;
> + unsigned int len;
>
> - complete(>completion);
> + while ((req = virtqueue_get_buf(vq,
+Greg.
On 19-10-21, 09:46, Vincent Whitchurch wrote:
> If a timeout is hit, it can result is incorrect data on the I2C bus
> and/or memory corruptions in the guest since the device can still be
> operating on the buffers it was given while the guest has freed them.
>
> Here is, for example, the
d-off-by: Michael S. Tsirkin
> ---
> drivers/gpio/gpio-virtio.c | 2 +-
> drivers/i2c/busses/i2c-virtio.c | 2 +-
Reviewed-by: Viresh Kumar
--
viresh
___
Virtualization mailing list
Virtualization@lists.linux-foundation.
On 04-10-21, 14:44, Geert Uytterhoeven wrote:
> Currently the GPIO Aggregator does not support interrupts. This means
> that kernel drivers going from a GPIO to an IRQ using gpiod_to_irq(),
> and userspace applications using line events do not work.
>
> Add interrupt support by providing a
y PCI vendor/device ids.
>
> Let's just skip of_node setup but proceed with initialization like we
> did previously.
>
> Fixes: 694a1116b405 ("virtio: Bind virtio device to device-tree node")
> Reported-by: Alexey Kardashevskiy
> Cc: Arnd Bergmann
> Cc: Viresh Kumar
On 04-09-21, 16:01, Michael S. Tsirkin wrote:
> Same as with qemu bits, I am confused as to what is the status
> of proposed spec changes and whether the driver will work
> with them.
This is already merged as well.
The current version simply fails to transmit the messages in case the
length of
Add gpio and virtualization lists in the MAINTAINERS entry for Virtio
gpio driver.
Reported-by: "Michael S. Tsirkin"
Signed-off-by: Viresh Kumar
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f632acd7d98c..da5896493
On 31-08-21, 02:25, Michael S. Tsirkin wrote:
> On Tue, Aug 31, 2021 at 10:59:25AM +0530, Viresh Kumar wrote:
> > Fix warnings reported by sparse, related to type mismatch between u16
> > and __le16.
> >
> > Reported-by: kernel test robot
> > Fixes: 3a29355a22
On 27-07-21, 10:53, Viresh Kumar wrote:
> Hi,
>
> Currently the DT only provides support for following node types for
> virtio-mmio
> nodes:
>
> virtio_mmio@a00 {
> dma-coherent;
> interrupts = <0x00 0x10 0x01>;
>
Fix warnings reported by sparse, related to type mismatch between u16
and __le16.
Reported-by: kernel test robot
Fixes: 3a29355a22c0 ("gpio: Add virtio-gpio driver")
Signed-off-by: Viresh Kumar
---
drivers/gpio/gpio-virtio.c | 41
include/
Reviewed-by: Linus Walleij
Signed-off-by: Viresh Kumar
---
Bartosz,
Can you please pick this up for 5.15, the specification is already merged now:
https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-gpio.tex
I will follow up with the IRQ stuff separately.
V6->V7:
- Fixed a cocci
));
> + ACPI_COMPANION_SET(>adap.dev, ACPI_COMPANION(vdev->dev.parent));
>
> ret = i2c_add_adapter(>adap);
> if (ret)
Acked-by: Viresh Kumar
--
viresh
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Reviewed-by: Linus Walleij
Signed-off-by: Viresh Kumar
---
Bartosz,
Can you please pick this up for 5.15, the specification is already merged now:
https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-gpio.tex
I will follow up with the IRQ stuff separately.
V5->V6:
- Sent separately
On 10-08-21, 15:55, Viresh Kumar wrote:
> This patch adds IRQ support for the virtio GPIO driver. Note that this
> uses the irq_bus_lock/unlock() callbacks, since those operations over
> virtio may sleep. Also the notifications for the eventq are processed
> using a work item to allo
Set of-node of the adapter to the virtio device's of-node to enable
automatic parsing the of the I2C devices, if present in the DT.
Signed-off-by: Viresh Kumar
---
drivers/i2c/busses/i2c-virtio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c
On 04-08-21, 09:26, Viresh Kumar wrote:
> Michael,
>
> I hope you will be picking this series (Now that it is reviewed by
> others) ? Just so you know, Wolfram needs the 4th patch, 4/5, to base
> the virtio-i2c driver over it and has requested an immutable branch
> for the same.
This patch adds IRQ support for the virtio GPIO driver. Note that this
uses the irq_bus_lock/unlock() callbacks, since those operations over
virtio may sleep. Also the notifications for the eventq are processed
using a work item to allow sleep-able operations.
Signed-off-by: Viresh Kumar
.
Signed-off-by: Viresh Kumar
---
Enrico, lemme know if you want me to add your co-developed by and
signed-off-by. Didn't want to add without checking with you first.
---
MAINTAINERS | 7 +
drivers/gpio/Kconfig | 9 +
drivers/gpio/Makefile| 1 +
dr
Better forget
everything we have done until now :)
--
Viresh
[1] https://lists.oasis-open.org/archives/virtio-dev/202107/msg00232.html
Viresh Kumar (2):
gpio: Add virtio-gpio driver
gpio: virtio: Add IRQ support
MAINTAINERS | 7 +
drivers/gpio/Kconfig
On 09-08-21, 13:19, Arnd Bergmann wrote:
> I don't see anything wrong with this version,
Great.
> but let's see what
> Marc thinks. I expect that he can still poke some holes in it, or
> at least find some simplifications.
Right, though I may resend the patches properly first to make it less
On 09-08-21, 09:55, Arnd Bergmann wrote:
> Ah, right. There is already a flag that gets checked by the caller.
>
> It does feel odd to have an empty 'irq_mask' callback though, so
> maybe there is still something missing, just not what I thought.
>
> It's probably the result of calling
On 06-08-21, 10:00, Arnd Bergmann wrote:
> On Fri, Aug 6, 2021 at 9:44 AM Viresh Kumar via Stratos-dev
> wrote:
> >
> > On 05-08-21, 15:10, Arnd Bergmann wrote:
> > > I hope this can still be simplified by working out better which state
> > > transitions are ne
On 05-08-21, 15:10, Arnd Bergmann wrote:
> I hope this can still be simplified by working out better which state
> transitions are needed exactly. In particular, I would expect that we
> can get away with not sending a VIRTIO_GPIO_MSG_IRQ_TYPE
> for 'mask' state changes at all, but use that only
On 05-08-21, 14:03, Arnd Bergmann wrote:
> On Thu, Aug 5, 2021 at 1:26 PM Viresh Kumar via Stratos-dev
> > Based on discussion we had today (offline), I changed the design a bit
> > and used handle_level_irq() instead, as it provides consistent calls
> > to mask/unmas
On 03-08-21, 17:01, Arnd Bergmann wrote:
> As far as I can tell, the update_irq_type() message would lead to the
> interrupt getting delivered when it was armed and is now getting disabled,
> but I don't see why we would call update_irq_type() as a result of the
> eventq notification.
Based on
On 04-08-21, 10:27, Arnd Bergmann wrote:
> On Wed, Aug 4, 2021 at 9:05 AM Viresh Kumar wrote:
> > On 03-08-21, 17:01, Arnd Bergmann wrote:
> > > >
> > > > +static void virtio_gpio_irq_unmask(struct irq_data *d)
> > > > +{
> > > > +
On 03-08-21, 17:01, Arnd Bergmann wrote:
> On Tue, Aug 3, 2021 at 1:36 PM Viresh Kumar wrote:
> > +struct vgpio_irq_line {
> > + u8 type;
> > + bool masked;
> > + bool update_pending;
> > + bool queued;
> > +
> >
On 27-07-21, 10:53, Viresh Kumar wrote:
> Hi,
>
> Currently the DT only provides support for following node types for
> virtio-mmio
> nodes:
>
> virtio_mmio@a00 {
> dma-coherent;
> interrupts = <0x00 0x10 0x01>;
>
On 03-08-21, 09:47, Rob Herring wrote:
> n Mon, Aug 2, 2021 at 10:30 PM Viresh Kumar wrote:
> >
> > On 02-08-21, 13:40, Rob Herring wrote:
> > > Humm, how does one implement interrupts without a parent interrupt? It
> > > uses the parent virtio,mmio
This patch adds IRQ support for the virtio GPIO driver. Note that this
uses the irq_bus_lock/unlock() callbacks, since those operations over
virtio may sleep. Also the notifications for the eventq are processed
using a work item to allow sleep-able operations.
Signed-off-by: Viresh Kumar
.
Signed-off-by: Viresh Kumar
---
Enrico, lemme know if you want me to add your co-developed by and
signed-off-by. Didn't want to add without checking with you first.
---
MAINTAINERS | 7 +
drivers/gpio/Kconfig | 9 +
drivers/gpio/Makefile| 1 +
dr
107/msg00232.html
Viresh Kumar (2):
gpio: Add virtio-gpio driver
gpio: virtio: Add IRQ support
MAINTAINERS | 7 +
drivers/gpio/Kconfig | 10 +
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-virtio.c |
On 02-08-21, 13:40, Rob Herring wrote:
> Humm, how does one implement interrupts without a parent interrupt? It
> uses the parent virtio,mmio interrupt?
Kind of, yeah, but not necessarily.
The interrupt information is passed over buffers shared between host and guest.
Now the guest may process
.
Reviewed-by: Arnd Bergmann
Signed-off-by: Viresh Kumar
---
drivers/virtio/virtio.c | 57 ++---
1 file changed, 54 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 4b15c00c0a0a..5f80786c2aa2 100644
--- a/drivers/virtio
This synchronizes the virtio ids with the latest list from virtio
specification.
Signed-off-by: Viresh Kumar
---
include/uapi/linux/virtio_ids.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/uapi/linux/virtio_ids.h b/include/uapi/linux/virtio_ids.h
index 70a8057ad4bb
This patch adds binding for virtio GPIO controller, it is based on
virtio-device bindings.
Reviewed-by: Arnd Bergmann
Signed-off-by: Viresh Kumar
---
.../devicetree/bindings/gpio/gpio-virtio.yaml | 59 +++
1 file changed, 59 insertions(+)
create mode 100644 Documentation
This patch adds binding for virtio I2C device, it is based on
virtio-device bindings.
Acked-by: Wolfram Sang
Reviewed-by: Arnd Bergmann
Signed-off-by: Viresh Kumar
---
.../devicetree/bindings/i2c/i2c-virtio.yaml | 51 +++
1 file changed, 51 insertions(+)
create mode 100644
Allow virtio device sub-nodes to be added to the virtio mmio or pci
nodes. The compatible property for virtio device must be of the format
"virtio,device", where ID is virtio device ID in hexadecimal format.
Signed-off-by: Viresh Kumar
---
.../devicetree/bindings/virtio/mmio.yaml
virtio-mmio. This allows the same to be used by all device types, irrespective
of the transport mechanism.
- Dropped the reg property and used compatible in the form "virtio,".
- Dropped dt-bindings/virtio/virtio_ids.h.
- Add a patch to sync virtio-ids from spec, required for t
On 26-07-21, 08:57, Rob Herring wrote:
> On Sun, Jul 25, 2021 at 10:52 PM Viresh Kumar wrote:
> > +description: |
> > + Exactly one node describing the virtio device. The name of the node
> > isn't
> > + significant but its phandle can be used to by a use
On 27-07-21, 10:15, Jie Deng wrote:
>
> On 2021/7/23 17:03, Arnd Bergmann wrote:
> > On Fri, Jul 23, 2021 at 7:44 AM Jie Deng wrote:
> >
> > > +
> > > + ret = virtio_i2c_setup_vqs(vi);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + vi->adap.owner =
On 26-07-21, 10:11, Arnd Bergmann wrote:
> On Mon, Jul 26, 2021 at 10:06 AM Arnd Bergmann wrote:
> >
> > On Mon, Jul 26, 2021 at 6:52 AM Viresh Kumar
> > wrote:
> > >
> > > This patch adds binding for virtio I2C device, it is based on
> > > virti
.
Reviewed-by: Arnd Bergmann
Signed-off-by: Viresh Kumar
---
drivers/virtio/virtio.c | 57 ++---
1 file changed, 54 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 4b15c00c0a0a..d001e84a5b23 100644
--- a/drivers/virtio
This synchronizes the virtio ids with the latest list from virtio
specification.
Signed-off-by: Viresh Kumar
---
include/uapi/linux/virtio_ids.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/uapi/linux/virtio_ids.h b/include/uapi/linux/virtio_ids.h
index 70a8057ad4bb
This patch adds binding for virtio GPIO controller, it is based on
virtio-device bindings.
Signed-off-by: Viresh Kumar
---
.../devicetree/bindings/gpio/gpio-virtio.yaml | 60 +++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio
This patch adds binding for virtio I2C device, it is based on
virtio-device bindings.
Acked-by: Wolfram Sang
Signed-off-by: Viresh Kumar
---
.../devicetree/bindings/i2c/i2c-virtio.yaml | 51 +++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree
Allow virtio device sub-nodes to be added to the virtio mmio or pci
nodes. The compatible property for virtio device must be of format
"virtio,", where DID is virtio device ID in hexadecimal format.
Signed-off-by: Viresh Kumar
---
.../devicetree/bindings/virtio/mmio.yaml
lows the same to be used by all device types, irrespective
of the transport mechanism.
- Dropped the reg property and used compatible in the form "virtio,".
- Dropped dt-bindings/virtio/virtio_ids.h.
- Add a patch to sync virtio-ids from spec, required for the last patch.
--
Viresh
Vir
On 23-07-21, 11:03, Arnd Bergmann wrote:
> > index 70a8057a..99aa27b 100644
> > --- a/include/uapi/linux/virtio_ids.h
> > +++ b/include/uapi/linux/virtio_ids.h
> > @@ -55,6 +55,7 @@
> > #define VIRTIO_ID_FS 26 /* virtio filesystem */
> > #define VIRTIO_ID_PMEM
-off-by: Viresh Kumar
---
V2->V2.1
- Remove list of virtio device and use of_device_is_compatible() instead.
drivers/virtio/virtio.c | 56 ++---
1 file changed, 53 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virti
On 23-07-21, 07:58, Viresh Kumar wrote:
> Would need a spec update, which I am going to send.
>
> We would also need another update to spec to make the Quick thing
> working. Lemme do it separately and we merge the latest version of the
> driver for linux-next until then.
>
&g
Hi Wolfram,
On 22-07-21, 17:15, Wolfram Sang wrote:
> Nope, I think you misinterpreted that. SMBUS_QUICK will not send any
> byte. After the address phase (with the RW bit as data), a STOP will
> immediately follow. len = 0 will ensure that.
>
> msgbuf0[0] is set to 'command' because every mode
On 23-07-21, 10:21, Jie Deng wrote:
> I think we can add an i2c_adapter_quirks for this moment. Support for
> I2C_FUNC_SMBUS_QUICK
> can be added incrementally if needed.
+1.
We just need to get this merged :)
> I will play this role. I see Viresh also spend a lot of time on this driver.
>
>
On 22-07-21, 16:52, Arnd Bergmann wrote:
> On Thu, Jul 22, 2021 at 11:56 AM Viresh Kumar wrote:
> >
> > +/* Virtio device compatibles and IDs */
> > +static const struct of_device_id of_virtio_devices[] = {
> > + { .compatible = "virtio,22",
On 22-07-21, 12:28, Arnd Bergmann wrote:
> On Thu, Jul 22, 2021 at 11:57 AM Viresh Kumar wrote:
> >
> > Allow virtio device sub-nodes to be added to the virtio mmio or pci
> > nodes. The compatible property for virtio device must be of format
> > "virtio,
-off-by: Viresh Kumar
---
drivers/virtio/virtio.c | 67 +++--
1 file changed, 64 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 4b15c00c0a0a..87bee5b966c3 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers
This synchronizes the virtio ids with the latest list from virtio
specification.
Signed-off-by: Viresh Kumar
---
Replaces:
https://lore.kernel.org/lkml/7c716c2eb7ace5b5a560d8502af93101dbb53d24.1626170146.git.viresh.ku...@linaro.org/
include/uapi/linux/virtio_ids.h | 12
1 file
This patch adds binding for virtio GPIO controller, it is based on
virtio-device bindings.
Signed-off-by: Viresh Kumar
---
.../devicetree/bindings/gpio/gpio-virtio.yaml | 60 +++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio
This patch adds binding for virtio I2C device, it is based on
virtio-device bindings.
Cc: Wolfram Sang
Signed-off-by: Viresh Kumar
---
.../devicetree/bindings/i2c/i2c-virtio.yaml | 51 +++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings
Allow virtio device sub-nodes to be added to the virtio mmio or pci
nodes. The compatible property for virtio device must be of format
"virtio,", where DID is virtio device ID in hexadecimal format.
Signed-off-by: Viresh Kumar
---
.../devicetree/bindings/virtio/mmio.yaml
used by all device types, irrespective
of the transport mechanism.
- Dropped the reg property and used compatible in the form "virtio,".
- Dropped dt-bindings/virtio/virtio_ids.h.
- Add a patch to sync virtio-ids from spec, required for the last patch.
--
Viresh
Viresh Kumar (5):
dt-bindi
On 22-07-21, 08:06, Greg KH wrote:
> No new features are allowed for 5.14, you know this. It's but fixes
> only now.
I was trying to be (overly) optimistic here since this was a fairly
independent driver which won't break anything else, and had been
pending on the list since many months now.
1 - 100 of 160 matches
Mail list logo
