
Hi Ken,
On 5 April 2017 at 02:47, Ken Ma make@marvell.com wrote:
Hi Simon
Please see my inline reply, thanks a lot!
Yours, Ken
-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: 2017年4月1日 12:22 To: Ken Ma Cc: U-Boot Mailing List; Stefan Roese; Michal Simek Subject: [EXT] Re: [PATCH 3/7] scsi: call children devices' probe functions automatically
External Email
Hi,
On 23 March 2017 at 03:29, make@marvell.com wrote:
From: Ken Ma make@marvell.com
- For the purpose of accessing peripheral devices through SCSI, the peripheral devices need to be probed to finish low level initialization, for example, ahci controller needs to do the ahci initialization;
- scsi_low_level_init() calling is removed since the detailed scsi low level initialization work is up to the peripheral scsi devices, for example, sata controller may do AHCI initialization while scanner controller may do ISIS initialization; the work should be done in children devices probe when scsi controller acts as bus or be done in the pure SAS controller's probe when SCSI controller is a SAS and works as an on-board component on the motherboard;
- Since u-boot initialization does not probe devices by default, SCSI children devices can be probed automatically in SCSI post probe function when SCSI controller acts as a bus.
Do you have to probe everything? The idea in DM is to probe devices only when they are first used. [Ken] If we do not probe SCSI' children nodes such as sata hdds scsi devices, then "scsi scan" will fail since command "scsi scan" only probes SCSI host controllers but not SCSI devices which are SCSI node's children nodes; otherwise we should add SCSI node's children devices' probe to "scsi scan". How do you think about it? Thanks!
I think that probing the scsi driver should be done at the start, then scanning should be an operation which can be performed afterwards. I'm not saying you shouldn't do both, but conceptually they are different and I think we should keep them separate.
Probing a SCSI controller just means that the hardware is prepared so we can use it..
(Also please use 'U-Boot' everywhere consistently) [Ken] got it, thanks!
Signed-off-by: Ken Ma make@marvell.com Cc: Simon Glass sjg@chromium.org Cc: Stefan Roese sr@denx.de Cc: Michal Simek michal.simek@xilinx.com Reviewed-on: http://vgitil04.il.marvell.com:8080/35426 Tested-by: iSoC Platform CI ykjenk@marvell.com Reviewed-by: Omri Itach omrii@marvell.com Reviewed-by: Kostya Porotchkin kostap@marvell.com
drivers/block/scsi-uclass.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/block/scsi-uclass.c b/drivers/block/scsi-uclass.c index 86eddfc..119ba53 100644 --- a/drivers/block/scsi-uclass.c +++ b/drivers/block/scsi-uclass.c @@ -18,8 +18,26 @@ DECLARE_GLOBAL_DATA_PTR;
static int scsi_post_probe(struct udevice *dev) {
struct udevice *child_dev;
int ret;
debug("%s: device %p\n", __func__, dev);
scsi_low_level_init(0, dev);
/*
* For the purpose of accessing peripheral devices through SCSI, the
* peripheral devices need to be probed to finish low level
* initialization, for example, ahci controller needs to do the ahci
* initialization;
* Since u-boot initialization does not probe devices by
- default, SCSI
U-Boot
* children devices can be probed automatically in SCSI post probe
* function when SCSI controller acts as a bus.
*/
list_for_each_entry(child_dev, &dev->child_head, sibling_node) {
ret = device_probe(child_dev);
if (ret)
return ret;
}
return 0;
}
@@ -54,6 +72,6 @@ UCLASS_DRIVER(scsi) = { .id = UCLASS_SCSI, .name = "scsi", .post_bind = scsi_post_bind,
.post_probe = scsi_post_probe,
.post_probe = scsi_post_probe, .per_device_platdata_auto_alloc_size = sizeof(struct
scsi_platdata), };
1.9.1
Regards, Simon