Messages in this thread |  | | Subject | Re: [PATCH v2 2/3] scsi: ufs: Modulize ufs-bsg | From | Bart Van Assche <> | Date | Tue, 17 Dec 2019 10:19:50 -0800 |
| |
On 12/17/19 12:56 AM, cang@codeaurora.org wrote: > Even in the current ufs_bsg.c, it creates two devices, one is ufs-bsg, > one is the char dev node under /dev/bsg. Why this becomes a problem > after make it a module? > > I took a look into the pci_driver, it is no different than making ufs-bsg > a plain device. The only special place about pci_driver is that it has its > own probe() and remove(), and the probe() in its bus_type calls the > probe() in pci_driver. Meaning the bus->probe() is an intermediate call > used to pass whatever needed by pci_driver->probe(). > > Of course we can also do this, but isn't it too much for ufs-bsg? > For our case, calling set_dev_drvdata(bsg_dev, hba) to pass hba to > ufs_bsg.c would be enough. > > If you take a look at the V3 patch, the change makes the ufs_bsg.c > much conciser. platform_device_register_data() does everything for us, > initialize the device, set device name, provide the match func, > bus type and release func. > > Since ufs-bsg is somewhat not a platform device, we can still add it > as a plain device, just need a few more lines to get it initialized. > This allows us leverage kernel's device driver model. Just like Greg > commented, we don't need to re-implement the mechanism again.
Hi Can,
Since ufs-bsg is not a platform device I think it would be wrong to model ufs-bsg devices as platform devices.
Please have a look at the bus_register() and bus_unregister() functions as Greg KH asked. Using the bus abstraction is not that hard. An example is e.g. available in the scsi_debug driver, namely the pseudo_lld_bus.
Thanks,
Bart.
|  |