Hi, On 1/8/2016 2:20 PM, Akinobu Mita wrote: > 2016-01-07 18:44 GMT+09:00 Christoph Hellwig <hch@xxxxxxxxxxxxx>: >>> This driver patch includes a core driver and glue drivers for pci and platform >>> for the DesignWare UFS Host IP. >> >> Why doesn't this use the existing ufs core? The architecture looks >> completely backwards to me. > > I agree. The existing ufs driver can have variant specific operations > (hba->vops) and also can define quirks. So if DesignWare UFS host > controller requires vendor specific register settings or DME operations > in initialization, or needs special workarounds for the specific versions, > it can use those mechanisms and shares common parts between other host > controllers. > I am planning to make some tests with the ufs kernel existing core driver in our setup, but I noticed that despite the scsi/ufs driver package contains a platform driver, this is not the typical platform driver (glue driver) which can be addressed from device tree. The only one available is the qcom's. Would I need to submit a designware platform glue driver also as done by QCom? We also need a pci glue driver, but you already have one. In your opinion the best approach is to add synopsys device id to the pci device list in the driver and add quirks or add a new designware pci glue driver? Thanks, Joao -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
