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
Software Engineer
Office: +380 44 390 5457xx39470<tel:+380%2044%20390%205457;ext=x39470> Cell:
+380 93 080 6457<tel:+380%2093%20080%206457> Email:
anastasiia_lukiane...@epam.com<mailto:anastasiia_lukiane...@epam.com>
Kyiv, Ukraine epam.com<http://www.epam.com>
CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s) or entity(ies)
to which it is addressed and contains information that is legally privileged
and confidential. If you are not the intended recipient, or the person
responsible for delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited. All unintended recipients are obliged to
delete this message and destroy any printed copies.
