From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mugunthan V N Date: Mon, 8 Feb 2016 16:53:42 +0530 Subject: [U-Boot] [PATCH v2 3/7] drivers: block: disk-uclass: implement scsi_init() In-Reply-To: References: <1454500780-20751-1-git-send-email-mugunthanvnm@ti.com> <1454500780-20751-4-git-send-email-mugunthanvnm@ti.com> Message-ID: <56B87ABE.1000503@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sunday 07 February 2016 01:59 AM, Simon Glass wrote: > Hi Bin, > > On 3 February 2016 at 04:59, Mugunthan V N wrote: >> >> Implement scsi_init() api to probe driver model based sata >> devices. >> >> Signed-off-by: Mugunthan V N >> --- >> drivers/block/disk-uclass.c | 39 +++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 39 insertions(+) > > This patch seems odd to me. I would hope that scsi_init() would go > away with driver model and it would happen as part of the controller > probe. But of course we cannot probe SCSI from UCLASS_DISK. I think > the uclass 'disk' is too broad to be useful. > > So I am wondering whether the decision to use UCLASS_DISK instead of > UCLASS_AHCI was a mistake. > > Perhaps instead we should have: > > UCLASS_AHCI > UCLASS_SCSI > UCLASS_MMC > etc... > > and each of these devices can have a UCLASS_BLK under them (the block device). > > Possibly we could even have a dummy UCLASS_DISK device under each of > the above, but I'm not sure that is useful. > > What do you think? > Hmmm, this sounds a better approach to me also. So that we can abstract all bulk related activities to UCLASS_BLK. I can do an RFC if you are okay? Regards Mugunthan V N