The virtio PCI capabilities describe regions of memory that should be
mapped. Map those with dm_pci_map_bar() which will ensure they are valid
PCI regions.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Prepare for calls to `virtio_pci_map_capability()` failing by returning
NULL on error. If this happens, later accesses to the pointers would be
unsafe so cause the probe to fail if such an error occurs.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a mask parameter to control the lookup of the PCI region from which
the mapping can be made.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Evolve dm_pci_map_bar() to include an offset and length parameter. These
allow a portion of the memory to be mapped and range checks to be
applied.
Passing both the offset and length as zero results in the previous
behaviour and this is used to migrate the previous callers.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Read the virtio PCI capability out of the device configuration space to
a struct rather than accessing fields directly from the configuration
space as they are needed. This both makes access to the fields easier
and avoids re-reading fields.
Re-reading fields could result in time-of-check to time-of-use problems,
should the value in the configuration space change. The range check of
the `bar` field and the later call to `dm_pci_read_bar32()` is an
example of where this could happen.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Ensure the virtio PCI capabilities are contained within the bounds of
the device's configuration space. The expected size of the capability is
passed when searching for the capability to enforce this check.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Check that the common config is at least as large as the struct it is
expected to contain. Only then is it safe to cast the pointer and be
safe from out-of-bounds accesses.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Make sure virtio notifications are written within their allocated
buffer.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The device config is optional, so check it was present and mapped before
trying to use the pointer. Bounds violations are an error, not just a
warning, so bail if the checks fail.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The length of the device config was erroneously being taken from the
notify capability. Correct this by finding the length in the device
capability.
Fixes: 550435edf8 ("virtio: pci: Support non-legacy PCI transport device")
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a new config to control whether the driver for legacy virtio PCI
devices is included in the build. VIRTIO_PCI_LEGACY is included by
default when VIRTIO_PCI is selected, but it can also be independently
toggled.
Signed-off-by: Andrew Scull <ascull@google.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Define LOG_CATEGORY for all uclass to allow filtering with
log command.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The VirtIO BLK driver depends on the blk uclass driver.
Add the dependency in the Kconfig.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
VIRTIO_ID_MAX_NUM is the largest device ID plus 1. Therefore a device id
cannot be greater or equal to VIRTIO_ID_MAX_NUM. Fix the comparison
accordingly.
Fixes: 8fb49b4c7a ("dm: Add a new uclass driver for VirtIO transport devices")
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
At present various drivers etc. access the device's 'seq' member directly.
This makes it harder to change the meaning of that member. Change access
to go through a function instead.
The drivers/i2c/lpc32xx_i2c.c file is left unchanged for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.
Signed-off-by: Simon Glass <sjg@chromium.org>
We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.
Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
'log2blksz' in blk_desc structure must always be initialized, otherwise
it will cause a lot of weird failures in file operations.
For example, fs_set_blk_dev[_with_part]() examines a block device against
every file system with its probe function. In particular, ext4 file
system's ext4_probe() will calls fs_devread() to fetch a super block.
If log2blksz is 0, the actual 'read' size, i.e. block_len >> log2blksz, is
much bigger than a buffer's size, and it can end up with memory corruption.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Fixes: f4802209e5 ("virtio: Add block driver support")
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add the missing Kconfig dependency and let VIRTIO_RNG default to yes.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.
Move the compatibility features into a separate header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present devres.h is included in all files that include dm.h but few
make use of it. Also this pulls in linux/compat which adds several more
headers. Drop the automatic inclusion and require files to include devres
themselves. This provides a good indication of which files use devres.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Add a driver for the virtio-rng device on the qemu platform. The
device uses pci as a transport medium. The driver can be enabled with
the following configs
CONFIG_VIRTIO
CONFIG_DM_RNG
CONFIG_VIRTIO_PCI
CONFIG_VIRTIO_RNG
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
This driver provides support for Sandbox implementation of virtio
transport driver which is used for testing purpose only.
Two drivers are provided. The 2nd one is a driver that lacks the
'notify' op.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
For v1.0 compliant device, it always assumes the member 'num_buffers'
exists in the struct virtio_net_hdr while the legacy driver only
presented 'num_buffers' when VIRTIO_NET_F_MRG_RXBUF was negotiated.
Without that feature the structure was 2 bytes shorter.
Update the driver to support the non-legacy device.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
By default QEMU creates legacy PCI transport devices, but we can
ask QEMU to create non-legacy one if we pass additional device
property/value pairs in the command line:
-device virtio-blk-pci,disable-legacy=true,disable-modern=false
This adds a new driver driver to support non-legacy (modern) device
mode. Previous driver/file name is changed accordingly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds a transport driver that implements UCLASS_VIRTIO for
virtio over pci, which is commonly used on x86.
It only supports the legacy interface of the pci transport, which
is the default device that QEMU emulates.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds virtio block device driver support.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds virtio net device driver support.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
VirtIO can use various different buses and virtio devices are
commonly implemented as PCI devices. But virtual environments
without PCI support (a common situation in embedded devices
models) might use simple memory mapped device (“virtio-mmio”)
instead of the PCI device.
This adds a transport driver that implements UCLASS_VIRTIO for
virtio over mmio.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds support for managing virtual queue/ring, the channel
for high performance I/O between host and guest.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds a new virtio uclass driver for “virtio” [1] family of
devices that are are found in virtual environments like QEMU,
yet by design they look like physical devices to the guest.
The uclass driver provides child_pre_probe() and child_post_probe()
methods to do some common operations for virtio device drivers like
device and driver supported feature negotiation, etc.
[1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
