On Thu, Jun 7, 2012 at 12:15 PM, Girish K S <girish.shivananjappa@xxxxxxxxxx> wrote: > On 7 June 2012 10:21, vinayak holikatti <vinholikatti@xxxxxxxxx> wrote: >> On Mon, May 14, 2012 at 4:38 PM, Girish K S >> <girish.shivananjappa@xxxxxxxxxx> wrote: >>> The existing UFS driver is tightly bound to only pci specific devices. >>> It cannot work for non-pci devices. >>> >>> "SCSI: UFS: remove all pci code from core driver" patch removes all the >>> pci specific code from the core driver to make it generic >>> >>> "SCSI: UFS: Add support for pci probe" patch adds a new file to support >>> pci probing. >>> >>> "SCSI: UFS: Add platform support for ufs host controller" patch adds a new >>> file to support platform device probe >>> >>> "SCSI: UFS: Added support of PCI/PLTFM for UFS" patch adds the menu option >>> in Kconfig and Makefile to enable/disable the specific option >>> >>> Girish K S (4): >>> SCSI: UFS: remove all pci code from core driver >>> SCSI: UFS: Add support for pci probe >>> SCSI: UFS: Add platform support for ufs host controller >>> SCSI: UFS: Added support of PCI/PLTFM for UFS >>> >>> drivers/scsi/ufs/Kconfig | 32 +++- >>> drivers/scsi/ufs/Makefile | 2 + >>> drivers/scsi/ufs/ufs.h | 103 +++++++++++ >>> drivers/scsi/ufs/ufshcd-pci.c | 217 ++++++++++++++++++++++ >>> drivers/scsi/ufs/ufshcd-pltfm.c | 191 ++++++++++++++++++++ >>> drivers/scsi/ufs/ufshcd.c | 377 +++++++++------------------------------ >>> 6 files changed, 623 insertions(+), 299 deletions(-) >>> create mode 100644 drivers/scsi/ufs/ufshcd-pci.c >>> create mode 100644 drivers/scsi/ufs/ufshcd-pltfm.c >>> >>> -- >>> 1.7.4.1 >>> >> >> Hi Girish, >> >> It was already communicated to you internally that the the platform >> support for UFSHCD has been implemented, PCI and Platform code has > Only informed after i had sent the initial code internally. After > effort has been spent > on making the draft copy. I had informed you about the work on platform support before you sent the patches internally. >> been segregated and we are in the final stages of testing. We would >> send the code for internal review before posting the patches to SCSI > waited for more than 2 months time. when there was no reply, i did the > above mentioned draft and sent. Reply to what? as I have mentioned above I had already informed you about the work on platform support.Also you are well aware of the internal review process before posting the patches. If not, then read the mail that was sent, even you are in the CC. > But still i didnt get reply for that internal mail. Immediate reply was sent to your mail. Stop covering the facts. I still have the email records. > Why didnt you object on the 1st RFC. Why did you wait for 4 revisions. We had informed you before posting the patches itself this is the result of your negligence. >> mailing list. So the reason for posting your untested patches within > pls test this patch and then claim that it doesnt work. And the RFC > was to push the > pci and non pci separate framework. Hope its clear. >> few days after you were informed is not clear. We don't want to put >> effort reviewing and testing these patch again, since we already have > Above statement shows the negligence of not testing the patch. > I can post all the log messages of the test. still the intent of the reply doesn't seem clear to you. Its simple, since every one is busy, we don't want to do the same work twice. We don't have any hidden agenda for not accepting your patches. If some one without the knowledge of the internal work had posted the patches it would make sense. >> working code. Working platform patches for UFSHCD will be posted soon. > waiting for the same. and let experts in this list decide on that (for > pci/non pci) framework >> >> >> -- >> Regards, >> Vinayak Holikatti -- 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
