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 5457xx39470tel:+380%2044%20390%205457;ext=x39470 Cell: +380 93 080 6457tel:+380%2093%20080%206457 Email: anastasiia_lukianenko@epam.commailto:Anastasiia_Lukianenko@epam.com
Kyiv, Ukraine epam.comhttp://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.