search for: f_multiport

...space), we won't have config > space. I'm still not sure whether we should pull in this patch before actually seeing a failure. You do have a dev_err which tells why the probe failed, so it's an acceptable compromise I suppose. > > Also, just the console functionality (i.e. F_MULTIPORT is unset) is > > available w/o config space access. > > Supporting this by gracefully disabling F_MULTIPORT > would require getting this info from driver before > features are finalized. > Alternatively, check F_MULTIPORT and only fail if set? > Let me know, I'll cook u...

...space), we won't have config > space. I'm still not sure whether we should pull in this patch before actually seeing a failure. You do have a dev_err which tells why the probe failed, so it's an acceptable compromise I suppose. > > Also, just the console functionality (i.e. F_MULTIPORT is unset) is > > available w/o config space access. > > Supporting this by gracefully disabling F_MULTIPORT > would require getting this info from driver before > features are finalized. > Alternatively, check F_MULTIPORT and only fail if set? > Let me know, I'll cook u...

...make it > fail gracefully if not there. Do we know any such devices? Wondering what prompted this patch. If it's just theoretical, I'd rather let it be like this, and pull this in when there's a device that doesn't have config space. Also, just the console functionality (i.e. F_MULTIPORT is unset) is available w/o config space access. In fact, getting this patch in would mean remoteproc wouldn't even run in its pre-config days... > diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c > index de03df9..26afb56 100644 > --- a/drivers/char/virtio_co...

...make it > fail gracefully if not there. Do we know any such devices? Wondering what prompted this patch. If it's just theoretical, I'd rather let it be like this, and pull this in when there's a device that doesn't have config space. Also, just the console functionality (i.e. F_MULTIPORT is unset) is available w/o config space access. In fact, getting this patch in would mean remoteproc wouldn't even run in its pre-config days... > diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c > index de03df9..26afb56 100644 > --- a/drivers/char/virtio_co...

...be like this, and pull this > in when there's a device that doesn't have config space. Yes, with virtio 1.0 config space can be in a separate BAR now. If that's not enabled by BIOS (e.g. out of space), we won't have config space. > Also, just the console functionality (i.e. F_MULTIPORT is unset) is > available w/o config space access. Supporting this by gracefully disabling F_MULTIPORT would require getting this info from driver before features are finalized. Alternatively, check F_MULTIPORT and only fail if set? Let me know, I'll cook up a patch. > In fact, getting t...

...be like this, and pull this > in when there's a device that doesn't have config space. Yes, with virtio 1.0 config space can be in a separate BAR now. If that's not enabled by BIOS (e.g. out of space), we won't have config space. > Also, just the console functionality (i.e. F_MULTIPORT is unset) is > available w/o config space access. Supporting this by gracefully disabling F_MULTIPORT would require getting this info from driver before features are finalized. Alternatively, check F_MULTIPORT and only fail if set? Let me know, I'll cook up a patch. > In fact, getting t...

Changes since v2: handling for devices without config space (e.g. rng) reduce # of mappings for VQs These patches seem to work fine on my virtio-1.0 qemu branch. There haven't been any bugs since v2: just minor cleanups and enhancements. QEMU side is still undergoing polishing, but is already testable. Rusty, what do you think? Let's merge these for 3.20? Also - will you be doing that

Changes since v2: handling for devices without config space (e.g. rng) reduce # of mappings for VQs These patches seem to work fine on my virtio-1.0 qemu branch. There haven't been any bugs since v2: just minor cleanups and enhancements. QEMU side is still undergoing polishing, but is already testable. Rusty, what do you think? Let's merge these for 3.20? Also - will you be doing that