On Friday 20 June 2014 13:11:37 Santosh Shilimkar wrote:

quoted

Unfortunately I lost Jingoo's email from my Inbox. So I cut-n-paste the comment from
internet and respond.

Jingoo Han wrote:-
=============================================================================
I think so, too.

DT maintainers and arch maintainers should review the following
dt bindings.
  .../devicetree/bindings/pci/designware-pcie.txt    |   42 ++
  .../devicetree/bindings/pci/pci-keystone.txt       |   56 +++
Generic PHY maintainer (Kishon Vijay Abraham I) should review the
following phy driver.
  drivers/phy/phy-keystone-serdes.c

quoted

I'm looking for acks from Mohit and/or Jingoo for the pci/host
changes, and from Arnd for the devicetree/bindings changes.

Adding these "-dw-3_64" files is sort of ugly.  If that code is only
used by keystone, maybe it could just be moved to pci-keystone.c?  But
I'll defer to Mohit and Jingoo on that and the way you modify
pcie-designware.c.

I agree with Bjorn Helgaas's opinion. These three "-dw-3_64" files
look terrible! I don't have a good way to handle this; however,
moving this code to pci-keystone.c looks better.
======================================================================

The original RFC I had submitted had all of the application space register
handling code as part of the Keystone PCI driver. As per Arnd's comment (See
my change log against v1), the code was moved to a separate file so that
the next driver that has same version of the DW hw could re-use this code.
I agree with Arnd and moved the code to v_3_65 specific files.  What is
your proposal?  Do you have objection to the file name? or it's content?

If objection is on the file name,  please suggest alternate names. If you
are okay with the file name, and doesn't like the code, it will be helpful
to review the code and provide specific comments against the patch itself
so that I can address the same.

Arnd suggestion was to have the version 3.65 code in generic place since
its IP specific and just in case some other vendor using the same version
can leverage the code.

Concern here seems toe really those name of the files. I can't think of
any other appropriate name. 

We should definitely keep the version in the DT "compatible" strings
wherever we know it. Regarding a better file name, I have no idea.

	Arnd