On Mon, Feb 08, 2016 at 10:45:34AM -0700, Simon Glass wrote:
Hi Muganthan,
On 8 February 2016 at 04:23, Mugunthan V N mugunthanvnm@ti.com wrote:
On Sunday 07 February 2016 01:59 AM, Simon Glass wrote:
Hi Bin,
On 3 February 2016 at 04:59, Mugunthan V N mugunthanvnm@ti.com wrote:
Implement scsi_init() api to probe driver model based sata devices.
Signed-off-by: Mugunthan V N mugunthanvnm@ti.com
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?
I have been working on a block uclass and tidying up the partition stuff. I'll see if I can get patches out next week. In the meantime I'd like to get comments from Bin and others about this too.
I suspect we will end up apply what you have (or similar) for this release, but I'd like to figure out the best approach here.
OK. I had marked the series deferred this morning, and moved it back to new now. Given the caveat of needing higher level rework after can you review/ack/nack 3 and 5 as much as you feel comfortable with? Thanks!