Hello Simon,
We are adding support for Xen [1] para-virtualized block device as a u-boot
driver and have some questions with respect to driver model and
instantiation of new devices.
Because of the nature of the device driver we cannot use device tree or
define statically the device instances beforehand and those get known
during some device enumeration.
So, this makes us bind the new devices to the driver at run-time. For that we
use:
(init)
device_bind_by_name(gd->dm_root, false, &info, &udev);
...
ret = uclass_get(UCLASS_BLK, &uc);
if (ret) {
printk("UCLASS_BLK class has no registered entities\n");
return;
}
uclass_foreach_dev(udev, uc) {
ret = device_probe(udev);
if (ret < 0)
printk("Failed to probe " DRV_NAME " device\n");
}
...
(probe)
struct blkfront_platdata *platdata = dev_get_platdata(udev);
struct blkfront_dev *blk_dev = dev_get_priv(udev);
struct blk_desc *desc = dev_get_uclass_platdata(udev);
We create a device with [IF_TYPE_PVBLOCK] = "pvblock" (UCLASS_BLK)
typename and UCLASS. Everything goes smooth, driver's probe is
called, but the problem we are seeing is that when we call
"part list pvblock 0" command with the device description and udev's
parent not set or set to gd->dm_root then we see
<** Bad device pvblock 0 **> from blk_get_device_by_str function.
Digging into the code shows that there is a check (equality of block
device's interface type and the uclass of the block device's parent) in
blk_get_devnum_by_typename function in drivers/blk-uclass.c file,
which makes us think that we should somehow set our parent to
UCLASS_BLK or something. At the same time setting udev to
udev->parent makes things work, but it doesn't seem to be correct.
(For example, "pvblock part 0" command works properly, because it
doesn't use blk_get_devnum_by_typename.)
1. What is the right procedure to bind a device to a driver in such
cases as ours? Can we still use what we have? (Is it okay to use
device_bind_by_name function in init stage?)
2. How can we become a child of UCLASS_BLK or any other entity, so
we are recognized by the framework properly? (Do we need to create
child from our udev device in probe stage by using blk_create_devicef
function?)
3. Why parent's and device's U_CLASS must be the same? For what
cases this check has been implemented?
4. According to blk uclass implementation is it okay to have parent with
UCLASS_ROOT for block device? If no, then what parent should we assign?
[1] - https://xenproject.org/
Regards,
ANASTASIIA LUKIANENKO
