| Message ID | 20160107081102.GA6243@localhost.localdomain (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Richard, On Thursday 07 January 2016 01:41 PM, Richard Cochran wrote: > This patch marks the dra7xx pci host driver as broken. This driver > was first merged in v3.17 and has never worked. Although the driver > compiles just fine, it is missing an essential device reset. If the > driver is included, the kernel locks up hard shortly after booting, > before any console output appears. > > Signed-off-by: Richard Cochran <richardcochran@gmail.com> > > --- > drivers/pci/host/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig > index d5e58ba..d83e8f0 100644 > --- a/drivers/pci/host/Kconfig > +++ b/drivers/pci/host/Kconfig > @@ -5,6 +5,7 @@ config PCI_DRA7XX > bool "TI DRA7xx PCIe controller" > select PCIE_DW > depends on OF && HAS_IOMEM && TI_PIPE3 > + depends on BROKEN In my point of view the driver is not broken as such but an independent piece (reset) which is missing, since this driver compiles and works fine if that reset piece is added. You are right in that this shouldn't have been probed since it's known that the reset piece is missing. Maybe we should just set "status = disabled" in dra7.dtsi and when that reset piece is added enable it back in dra7-evm.dts? Thanks Kishon > help > Enables support for the PCIe controller in the DRA7xx SoC. There > are two instances of PCIe controller in DRA7xx. This controller can >
On Thu, Jan 07, 2016 at 02:14:22PM +0530, Kishon Vijay Abraham I wrote: > In my point of view the driver is not broken as such but an independent piece > (reset) which is missing, since this driver compiles and works fine if that > reset piece is added. You are right in that this shouldn't have been probed > since it's known that the reset piece is missing. Maybe we should just set > "status = disabled" in dra7.dtsi and when that reset piece is added enable it > back in dra7-evm.dts? That isn't strong enough, IMHO, since status=disabled is the default for most every DTS item. Maybe you could comment the PCI block out or remove it and put a comment in about the missing piece and the lock up behavior. It is really a nasty bug to have the machine freeze up with no output at all. It took me some time to figure out what was going on, and it would be a shame if someone else sets status=okay in their board file and has to repeat the whole exercise. Thanks, Richard
On Thu, Jan 7, 2016 at 3:25 AM, Richard Cochran <richardcochran@gmail.com> wrote: > On Thu, Jan 07, 2016 at 02:14:22PM +0530, Kishon Vijay Abraham I wrote: >> In my point of view the driver is not broken as such but an independent piece >> (reset) which is missing, since this driver compiles and works fine if that >> reset piece is added. You are right in that this shouldn't have been probed >> since it's known that the reset piece is missing. Maybe we should just set >> "status = disabled" in dra7.dtsi and when that reset piece is added enable it >> back in dra7-evm.dts? > > That isn't strong enough, IMHO, since status=disabled is the default > for most every DTS item. Maybe you could comment the PCI block out or > remove it and put a comment in about the missing piece and the lock up > behavior. It is really a nasty bug to have the machine freeze up with > no output at all. It took me some time to figure out what was going > on, and it would be a shame if someone else sets status=okay in their > board file and has to repeat the whole exercise. It sounds like dra7xx is missing a piece of essential functionality. If that's the case, what is the benefit of having it in the kernel at all? It makes work for everybody else (adapting to changes outside the driver), but it sounds like nobody gets any benefit. If somebody posts a patch to remove the driver entirely to linux-pci@vger.kernel.org, we can discuss whether that's the right thing to do. Bjorn
Hi Bjorn, On Thursday 07 January 2016 08:12 PM, Bjorn Helgaas wrote: > On Thu, Jan 7, 2016 at 3:25 AM, Richard Cochran > <richardcochran@gmail.com> wrote: >> On Thu, Jan 07, 2016 at 02:14:22PM +0530, Kishon Vijay Abraham I wrote: >>> In my point of view the driver is not broken as such but an independent piece >>> (reset) which is missing, since this driver compiles and works fine if that >>> reset piece is added. You are right in that this shouldn't have been probed >>> since it's known that the reset piece is missing. Maybe we should just set >>> "status = disabled" in dra7.dtsi and when that reset piece is added enable it >>> back in dra7-evm.dts? >> >> That isn't strong enough, IMHO, since status=disabled is the default >> for most every DTS item. Maybe you could comment the PCI block out or >> remove it and put a comment in about the missing piece and the lock up >> behavior. It is really a nasty bug to have the machine freeze up with >> no output at all. It took me some time to figure out what was going >> on, and it would be a shame if someone else sets status=okay in their >> board file and has to repeat the whole exercise. > > It sounds like dra7xx is missing a piece of essential functionality. > If that's the case, what is the benefit of having it in the kernel at > all? It makes work for everybody else (adapting to changes outside > the driver), but it sounds like nobody gets any benefit. During the time pci-dra7xx driver was merged, the reset controller driver was already being discussed in the list. And I didn't think it'll take this long for it to be merged. And I didn't want pci driver development to be hampered by these external pieces. That's why I sent the pci-dra7xx patches for merging. IMHO merging pci-dra7xx helped to keep active development of the driver, though I agree we should have kept mechanisms to keep the driver disabled either from dt or in Kconfig and a way to tell that reset piece is missing if someone has to enable the driver. > > If somebody posts a patch to remove the driver entirely to > linux-pci@vger.kernel.org, we can discuss whether that's the right > thing to do. I think that's not required now since Tony agreed to have pdata approach to perform reset till reset controller is merged. I'll be posting patch for it soon. Thanks Kishon
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index d5e58ba..d83e8f0 100644 --- a/drivers/pci/host/Kconfig +++ b/drivers/pci/host/Kconfig @@ -5,6 +5,7 @@ config PCI_DRA7XX bool "TI DRA7xx PCIe controller" select PCIE_DW depends on OF && HAS_IOMEM && TI_PIPE3 + depends on BROKEN help Enables support for the PCIe controller in the DRA7xx SoC. There are two instances of PCIe controller in DRA7xx. This controller can
This patch marks the dra7xx pci host driver as broken. This driver was first merged in v3.17 and has never worked. Although the driver compiles just fine, it is missing an essential device reset. If the driver is included, the kernel locks up hard shortly after booting, before any console output appears. Signed-off-by: Richard Cochran <richardcochran@gmail.com> --- drivers/pci/host/Kconfig | 1 + 1 file changed, 1 insertion(+)