Hi,
On 1/14/2016 2:54 AM, Akinobu Mita wrote:
> 2016-01-14 3:41 GMT+09:00 Joao Pinto <Joao.Pinto@xxxxxxxxxxxx>:
>> 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?
>
> Yes. ufs-pltfrm.c only contains APIs for UFS platform driver since
> commit 47555a5c8a11a423e6767f942941c745766c99a2 ("scsi: ufs: make the
> UFS variant a platform device"). Just as you said, you need to add
> ufs-abc.c as a real platform driver.
I am going to test the platform I already have and if everything is ok then I
will submit the patch.
>
>> 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?
>
> I think you can just add a new device id with vops like this
>
> {
> PCI_DEVICE(PCI_VENDOR_ID_SNPS, PCI_DEVICE_ID_SNPS_HAPS_UFS),
> .driver_data = (void *)&ufs_hba_dwc_vops,
> },
>
> then bind to hba->vops in ufshcd_pci_probe(). If there is remaining
> host controller specific initialization stuff, let vops->init() do that
> by ufshcd_init().
>
Ok, that's what I thought.
Thanks for the help!
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
