"Enrico Weigelt, metux IT consult" writes:
> On 04.12.20 04:35, Jason Wang wrote:
>
> Hi,
>
>> Is the plan to keep this doc synced with the one in the virtio
>> specification?
>
> Yes, of course. I'm still in progress of doing the beaurocratic stuff w/
> virtio-tc folks (ID registration, ...)
On 09/12/2020 22:38, Arnd Bergmann wrote:
On Wed, Dec 9, 2020 at 9:22 PM Grygorii Strashko
wrote:
On 09/12/2020 14:53, Linus Walleij wrote:
On Wed, Dec 9, 2020 at 12:19 PM Arnd Bergmann wrote:
On Wed, Dec 9, 2020 at 9:51 AM Linus Walleij wrote:
On Tue, Dec 8, 2020 at 3:07 PM Enrico
On Wed, Dec 9, 2020 at 9:22 PM Grygorii Strashko
wrote:
> On 09/12/2020 14:53, Linus Walleij wrote:
> > On Wed, Dec 9, 2020 at 12:19 PM Arnd Bergmann wrote:
> >> On Wed, Dec 9, 2020 at 9:51 AM Linus Walleij
> >> wrote:
> >>> On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult
>
On 09/12/2020 14:53, Linus Walleij wrote:
On Wed, Dec 9, 2020 at 12:19 PM Arnd Bergmann wrote:
On Wed, Dec 9, 2020 at 9:51 AM Linus Walleij wrote:
On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult
wrote:
What we need to understand is if your new usecase is an outlier
so
On Wed, Dec 9, 2020 at 12:19 PM Arnd Bergmann wrote:
> On Wed, Dec 9, 2020 at 9:51 AM Linus Walleij wrote:
> > On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult
> > wrote:
>
> > What we need to understand is if your new usecase is an outlier
> > so it is simplest modeled by a
On Wed, Dec 9, 2020 at 9:51 AM Linus Walleij wrote:
> On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult
> wrote:
> What we need to understand is if your new usecase is an outlier
> so it is simplest modeled by a "mock" irq_chip or we have to design
> something new altogether like
On Tue, Dec 08, 2020 at 01:33:02PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 08.12.20 11:10, Michal Suchánek wrote:
>
> Hi,
>
> > The console driver provides early console which should initialize
> > without any transport. I have not tested it actually works but the code
> > seems to
On 09.12.20 10:31, Jason Wang wrote:
Hi,
>> 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.
Great, so does everybody aggree on my patch ?
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.
On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult
wrote:
> I've been looking for some more direct notification callback for gpio
> consumers: here the consumer would register itself as a listener on
> some gpio_desc and called back when something changes (with data what
> exactly
On 08/12/2020 16:04, Enrico Weigelt, metux IT consult wrote:
On 08.12.20 10:38, Linus Walleij wrote:
Hi,
This is Bartosz territory, but the gpio-mockup.c driver will insert
IRQs into the system, he went and added really core stuff
into kernel/irq to make this happen. Notice that in Kconfig
On 08.12.20 10:38, Linus Walleij wrote:
Hi,
> This is Bartosz territory, but the gpio-mockup.c driver will insert
> IRQs into the system, he went and added really core stuff
> into kernel/irq to make this happen. Notice that in Kconfig
> it does:
>
> select IRQ_SIM
>
> Then this is used:
>
On 08.12.20 11:10, Michal Suchánek wrote:
Hi,
> The console driver provides early console which should initialize
> without any transport. I have not tested it actually works but the code
> seems to be there to support this use case.
What does it do if it hasn't got any transport yet ?
Just
Hello
On Sat, Dec 05, 2020 at 02:32:04PM -0500, Michael S. Tsirkin wrote:
> On Sat, Dec 05, 2020 at 08:59:55AM +0100, Enrico Weigelt, metux IT consult
> wrote:
> > On 04.12.20 04:35, Jason Wang wrote:
> >
> > >
> > > Let's use select, since there's no prompt for VIRTIO and it doesn't have
> >
On Sat, Dec 5, 2020 at 9:15 PM Enrico Weigelt, metux IT consult
wrote:
> The virtio-gpio device/host can raise a signal on line state change.
> Kinda IRQ, but not actually running through real IRQs, instead by a
> message running though queue. (hmm, kida MSI ? :o).
>
> I've tried allocating an
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
On 2020/12/7 下午5:33, Enrico Weigelt, metux IT consult wrote:
On 07.12.20 04:48, Jason Wang wrote:
Hi,
Not a native speaker but event sounds like something driver read from
device. Looking at the below lists, most of them except for
VIRTIO_GPIO_EV_HOST_LEVEL looks more like a command.
okay,
On 2020/12/7 下午9:53, Michael S. Tsirkin wrote:
On Mon, Dec 07, 2020 at 11:12:50AM +0800, Jason Wang wrote:
On 2020/12/6 上午3:32, Michael S. Tsirkin wrote:
On Sat, Dec 05, 2020 at 08:59:55AM +0100, Enrico Weigelt, metux IT consult
wrote:
On 04.12.20 04:35, Jason Wang wrote:
---
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
On Mon, Dec 07, 2020 at 11:12:50AM +0800, Jason Wang wrote:
>
> On 2020/12/6 上午3:32, Michael S. Tsirkin wrote:
> > On Sat, Dec 05, 2020 at 08:59:55AM +0100, Enrico Weigelt, metux IT consult
> > wrote:
> > > On 04.12.20 04:35, Jason Wang wrote:
> > >
> > > > > --- a/drivers/gpio/Kconfig
> > > >
On Sat, Dec 05, 2020 at 09:05:16PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 05.12.20 20:32, Michael S. Tsirkin wrote:
>
> Hi,
>
> > It seems a bit of a mess, at this point I'm not entirely sure when
> > should drivers select VIRTIO and when depend on it.
>
> if VIRTIO just enables
On 07.12.20 04:48, Jason Wang wrote:
Hi,
>>> Not a native speaker but event sounds like something driver read from
>>> device. Looking at the below lists, most of them except for
>>> VIRTIO_GPIO_EV_HOST_LEVEL looks more like a command.
>> okay, shall I name it "message" ?
>
>
> It might be
On 2020/12/4 下午5:36, Enrico Weigelt, metux IT consult wrote:
On 04.12.20 04:35, Jason Wang wrote:
Hi,
Is the plan to keep this doc synced with the one in the virtio
specification?
Yes, of course. I'm still in progress of doing the beaurocratic stuff w/
virtio-tc folks (ID registration,
On 2020/12/6 上午4:05, Enrico Weigelt, metux IT consult wrote:
On 05.12.20 20:32, Michael S. Tsirkin wrote:
Hi,
It seems a bit of a mess, at this point I'm not entirely sure when
should drivers select VIRTIO and when depend on it.
if VIRTIO just enables something that could be seen as
On 2020/12/6 上午3:32, Michael S. Tsirkin wrote:
On Sat, Dec 05, 2020 at 08:59:55AM +0100, Enrico Weigelt, metux IT consult
wrote:
On 04.12.20 04:35, Jason Wang wrote:
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1615,6 +1615,15 @@ config GPIO_MOCKUP
      Â
On 03.12.20 20:11, Enrico Weigelt, metux IT consult wrote:
Friends,
I've still got a problem w/ signal/irq handling:
The virtio-gpio device/host can raise a signal on line state change.
Kinda IRQ, but not actually running through real IRQs, instead by a
message running though queue. (hmm, kida
On 05.12.20 20:32, Michael S. Tsirkin wrote:
Hi,
> It seems a bit of a mess, at this point I'm not entirely sure when
> should drivers select VIRTIO and when depend on it.
if VIRTIO just enables something that could be seen as library
functions, then select should be right, IMHO.
> The text
On Sat, Dec 05, 2020 at 08:59:55AM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 04.12.20 04:35, Jason Wang wrote:
>
> >> --- a/drivers/gpio/Kconfig
> >> +++ b/drivers/gpio/Kconfig
> >> @@ -1615,6 +1615,15 @@ config GPIO_MOCKUP
> >> tools/testing/selftests/gpio/gpio-mockup.sh.
On 04.12.20 04:35, Jason Wang wrote:
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -1615,6 +1615,15 @@ config GPIO_MOCKUP
>> tools/testing/selftests/gpio/gpio-mockup.sh. Reference the
>> usage in
>> it.
>> +config GPIO_VIRTIO
>> + tristate "VirtIO GPIO
On 04.12.20 04:35, Jason Wang wrote:
Hi,
> Is the plan to keep this doc synced with the one in the virtio
> specification?
Yes, of course. I'm still in progress of doing the beaurocratic stuff w/
virtio-tc folks (ID registration, ...) - yet have to see whether they
wanna add it to their spec
On 2020/12/4 上午3:11, Enrico Weigelt, metux IT consult wrote:
Introducing new gpio driver for virtual GPIO devices via virtio.
The driver allows routing gpio control into VM guests, eg. brigding
virtual gpios to specific host gpios, or attaching simulators for
automatic application testing.
Introducing new gpio driver for virtual GPIO devices via virtio.
The driver allows routing gpio control into VM guests, eg. brigding
virtual gpios to specific host gpios, or attaching simulators for
automatic application testing.
Changes v2:
* fixed uapi header license
* sorted include's
32 matches
Mail list logo
