Re: [PATCH] pci: drop link_reset
ivers/infiniband/hw/qib/qib_pcie.c
> @@ -682,13 +682,6 @@ qib_pci_slot_reset(struct pci_dev *pdev)
> return PCI_ERS_RESULT_CAN_RECOVER;
> }
>
> -static pci_ers_result_t
> -qib_pci_link_reset(struct pci_dev *pdev)
> -{
> - qib_devinfo(pdev, "QIB link_reset function called,
> ignored\n");
> - return PCI_ERS_RESULT_CAN_RECOVER;
> -}
> -
> static void
> qib_pci_resume(struct pci_dev *pdev)
> {
> @@ -707,7 +700,6 @@ qib_pci_resume(struct pci_dev *pdev)
> const struct pci_error_handlers qib_pci_err_handler = {
> .error_detected = qib_pci_error_detected,
> .mmio_enabled = qib_pci_mmio_enabled,
> - .link_reset = qib_pci_link_reset,
> .slot_reset = qib_pci_slot_reset,
> .resume = qib_pci_resume,
> };
> diff --git a/drivers/media/pci/ngene/ngene-cards.c
> b/drivers/media/pci/ngene/ngene-cards.c
> index 423e8c8..8438c1c 100644
> --- a/drivers/media/pci/ngene/ngene-cards.c
> +++ b/drivers/media/pci/ngene/ngene-cards.c
> @@ -781,12 +781,6 @@ static pci_ers_result_t
> ngene_error_detected(struct pci_dev *dev,
> return PCI_ERS_RESULT_CAN_RECOVER;
> }
>
> -static pci_ers_result_t ngene_link_reset(struct pci_dev *dev)
> -{
> - printk(KERN_INFO DEVICE_NAME ": link reset\n");
> - return 0;
> -}
> -
> static pci_ers_result_t ngene_slot_reset(struct pci_dev *dev)
> {
> printk(KERN_INFO DEVICE_NAME ": slot reset\n");
> @@ -800,7 +794,6 @@ static void ngene_resume(struct pci_dev *dev)
>
> static const struct pci_error_handlers ngene_errors = {
> .error_detected = ngene_error_detected,
> - .link_reset = ngene_link_reset,
> .slot_reset = ngene_slot_reset,
> .resume = ngene_resume,
> };
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 30d6c16..316379c 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -661,9 +661,6 @@ struct pci_error_handlers {
> /* MMIO has been re-enabled, but not DMA */
> pci_ers_result_t (*mmio_enabled)(struct pci_dev *dev);
>
> - /* PCI Express link has been reset */
> - pci_ers_result_t (*link_reset)(struct pci_dev *dev);
> -
> /* PCI slot has been reset */
> pci_ers_result_t (*slot_reset)(struct pci_dev *dev);
>
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
Re: [RESEND PATCH v2 1/2] x86/mm/pat, drivers/infiniband/ipath: replace WARN() with pr_warn()
On Jul 17, 2015, at 5:07 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com WARN() may confuse users, fix that. ipath_init_one() is part the device's probe so this would only be triggered if a corresponding device was found. Signed-off-by: Luis R. Rodriguez mcg...@suse.com Acked-by: Doug Ledford dledf...@redhat.com — Doug Ledford dledf...@redhat.com GPG Key ID: 0E572FDD signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PATCH v6 2/3] IB/ipath: add counting for MTRR
On 06/11/2015 03:54 PM, Borislav Petkov wrote:
On Thu, Jun 11, 2015 at 10:50:01AM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani toshi.k...@hp.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
index 4ad0b93..70c1f3a 100644
--- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
+++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
@@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
(addr %llx, len=0x%llx)\n,
(unsigned long long) pioaddr,
(unsigned long long) piolen);
-cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie 0) {
{
dev_info(dd-pcidev-dev,
--
Doug, ack?
Ack.
signature.asc
Description: OpenPGP digital signature
Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR
On Wed, 2015-04-22 at 10:17 -0600, Jason Gunthorpe wrote: On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote: On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote: On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote: Mike, do you think the time is right to just remove the iPath driver? With PAT now being default the driver effectively won't work with write-combining on modern kernels. Even if systems are old they likely had PAT support, when upgrading kernels PAT will work but write-combing won't on ipath. Sorry, do you mean the driver already doesn't get WC? Or do you mean after some more pending patches are applied? No, you have to consider the system used and the effects of calls used on the driver in light of this table: So, just to be clear: At some point Linux started setting the PAT bits during ioremap_nocache, which overrides MTRR, and at that point the driver became broken on all PAT capable systems? Not only that, but we've only just noticed it now, and no user ever complained? So that means either no users exist, or all users are on non-PAT systems? This driver only works on x86-64 systems. Are there any x86-64 systems that are not PAT capable? IIRC even the first Opteron had PAT, but my memory is fuzzy from back then :| Another option in order to enable this type of checks at run time and still be able to build the driver on standard distributions and just prevent if from loading on PAT systems is to have some code in place which would prevent the driver from loading if PAT was enabled, this would enable folks to disable PAT via a kernel command line option, and if that was used then the driver probe would complete. This seems like a reasonble option to me. At the very least we might learn if anyone is still using these cards. I'd also love to remove the driver if it turns out there are actually no users. qib substantially replaces it except for a few very old cards. To be precise, the split is that ipath powers the old HTX bus cards that only work in AMD systems, qib is all PCI-e cards. I still have a few HTX cards, but I no longer have any systems with HTX slots, so we haven't even used this driver in testing for 3 or 4 years now. And these are all old SDR cards, where the performance numbers were 800MB/s with WC enabled, 50MB/s without it. Mike? Jason -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Doug Ledford dledf...@redhat.com GPG KeyID: 0E572FDD signature.asc Description: This is a digitally signed message part
Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR
On Wed, 2015-04-22 at 21:05 +0200, Luis R. Rodriguez wrote: I'd also love to remove the driver if it turns out there are actually no users. qib substantially replaces it except for a few very old cards. To be precise, the split is that ipath powers the old HTX bus cards that only work in AMD systems, Do those systems have PAT support? CAn anyone check if PAT is enabled if booted on a recent kernel? I don't have one of these systems any more. The *only* one I ever had was a monster IBM box...I can't even find a reference to it any more. -- Doug Ledford dledf...@redhat.com GPG KeyID: 0E572FDD signature.asc Description: This is a digitally signed message part
Re: ioremap_uc() followed by set_memory_wc() - burrying MTRR
On Wed, 2015-04-22 at 14:46 -0600, Jason Gunthorpe wrote: On Wed, Apr 22, 2015 at 02:53:11PM -0400, Doug Ledford wrote: To be precise, the split is that ipath powers the old HTX bus cards that only work in AMD systems, qib is all PCI-e cards. I still have a few HTX cards, but I no longer have any systems with HTX slots, so we haven't even used this driver in testing for 3 or 4 years now. And these are all old SDR cards, where the performance numbers were 800MB/s with WC enabled, 50MB/s without it. Wow, I doubt any HTX systems are still in any kind of use. It would be a nice clean up to drop the PPC support out of this driver too. PPC never had HTX. commit f6d60848baf9f4015c76c665791875ed623cd5b7 Author: Ralph Campbell ralph.campb...@qlogic.com Date: Thu May 6 17:03:19 2010 -0700 IB/ipath: Remove support for QLogic PCIe QLE devices The ib_qib driver is taking over support for QLogic PCIe QLE devices, so remove support for them from ib_ipath. The ib_ipath driver now supports only the obsolete QLogic Hyper-Transport IB host channel adapter (model QHT7140). Signed-off-by: Ralph Campbell ralph.campb...@qlogic.com Signed-off-by: Roland Dreier rola...@cisco.com There you go. It's been HTX only since 2010, and those cards were already old then. I think we should seriously consider deprecating and then removing the driver. -- Doug Ledford dledf...@redhat.com GPG KeyID: 0E572FDD signature.asc Description: This is a digitally signed message part
