Re: [PATCH v2 0/8] Add Keystone PCIe controller driver

From: Arnd Bergmann
Date: Fri Jun 20 2014 - 15:07:12 EST


On Friday 20 June 2014 13:11:37 Santosh Shilimkar wrote:
> >
> > 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
> >
> >>
> >> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/