The BDC PCI driver was only used for design verification with
an PCI/FPGA board. The board no longer exists and is not in use
anywhere. All instances of this core now exist as a memory mapped
device on the platform bus.
NOTE: This only removes the PCI driver and does not remove the
platform driver.
Signed-off-by: Al Cooper <[email protected]>
---
drivers/usb/gadget/udc/bdc/Kconfig | 11 ---
drivers/usb/gadget/udc/bdc/Makefile | 2 -
drivers/usb/gadget/udc/bdc/bdc_pci.c | 128 ---------------------------
3 files changed, 141 deletions(-)
delete mode 100644 drivers/usb/gadget/udc/bdc/bdc_pci.c
diff --git a/drivers/usb/gadget/udc/bdc/Kconfig b/drivers/usb/gadget/udc/bdc/Kconfig
index 3e88c7670b2e..8bedb7f64eba 100644
--- a/drivers/usb/gadget/udc/bdc/Kconfig
+++ b/drivers/usb/gadget/udc/bdc/Kconfig
@@ -11,14 +11,3 @@ config USB_BDC_UDC
Say "y" here to link the driver statically, or "m" to build a dynamically
linked module called "bdc".
-
-if USB_BDC_UDC
-
-comment "Platform Support"
-config USB_BDC_PCI
- tristate "BDC support for PCIe based platforms"
- depends on USB_PCI
- default USB_BDC_UDC
- help
- Enable support for platforms which have BDC connected through PCIe, such as Lego3 FPGA platform.
-endif
diff --git a/drivers/usb/gadget/udc/bdc/Makefile b/drivers/usb/gadget/udc/bdc/Makefile
index 52cb5ea48bbe..1b21c9518efc 100644
--- a/drivers/usb/gadget/udc/bdc/Makefile
+++ b/drivers/usb/gadget/udc/bdc/Makefile
@@ -5,5 +5,3 @@ bdc-y := bdc_core.o bdc_cmd.o bdc_ep.o bdc_udc.o
ifneq ($(CONFIG_USB_GADGET_VERBOSE),)
bdc-y += bdc_dbg.o
endif
-
-obj-$(CONFIG_USB_BDC_PCI) += bdc_pci.o
diff --git a/drivers/usb/gadget/udc/bdc/bdc_pci.c b/drivers/usb/gadget/udc/bdc/bdc_pci.c
deleted file mode 100644
index 6dbc489513cd..000000000000
--- a/drivers/usb/gadget/udc/bdc/bdc_pci.c
+++ /dev/null
@@ -1,128 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * bdc_pci.c - BRCM BDC USB3.0 device controller PCI interface file.
- *
- * Copyright (C) 2014 Broadcom Corporation
- *
- * Author: Ashwini Pahuja
- *
- * Based on drivers under drivers/usb/
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/slab.h>
-#include <linux/pci.h>
-#include <linux/pci_ids.h>
-#include <linux/platform_device.h>
-
-#include "bdc.h"
-
-#define BDC_PCI_PID 0x1570
-
-struct bdc_pci {
- struct device *dev;
- struct platform_device *bdc;
-};
-
-static int bdc_setup_msi(struct pci_dev *pci)
-{
- int ret;
-
- ret = pci_enable_msi(pci);
- if (ret) {
- pr_err("failed to allocate MSI entry\n");
- return ret;
- }
-
- return ret;
-}
-
-static int bdc_pci_probe(struct pci_dev *pci, const struct pci_device_id *id)
-{
- struct resource res[2];
- struct platform_device *bdc;
- struct bdc_pci *glue;
- int ret = -ENOMEM;
-
- glue = devm_kzalloc(&pci->dev, sizeof(*glue), GFP_KERNEL);
- if (!glue)
- return -ENOMEM;
-
- glue->dev = &pci->dev;
- ret = pci_enable_device(pci);
- if (ret) {
- dev_err(&pci->dev, "failed to enable pci device\n");
- return -ENODEV;
- }
- pci_set_master(pci);
-
- bdc = platform_device_alloc(BRCM_BDC_NAME, PLATFORM_DEVID_AUTO);
- if (!bdc)
- return -ENOMEM;
-
- memset(res, 0x00, sizeof(struct resource) * ARRAY_SIZE(res));
- bdc_setup_msi(pci);
-
- res[0].start = pci_resource_start(pci, 0);
- res[0].end = pci_resource_end(pci, 0);
- res[0].name = BRCM_BDC_NAME;
- res[0].flags = IORESOURCE_MEM;
-
- res[1].start = pci->irq;
- res[1].name = BRCM_BDC_NAME;
- res[1].flags = IORESOURCE_IRQ;
-
- ret = platform_device_add_resources(bdc, res, ARRAY_SIZE(res));
- if (ret) {
- dev_err(&pci->dev,
- "couldn't add resources to bdc device\n");
- platform_device_put(bdc);
- return ret;
- }
-
- pci_set_drvdata(pci, glue);
-
- dma_set_coherent_mask(&bdc->dev, pci->dev.coherent_dma_mask);
-
- bdc->dev.dma_mask = pci->dev.dma_mask;
- bdc->dev.dma_parms = pci->dev.dma_parms;
- bdc->dev.parent = &pci->dev;
- glue->bdc = bdc;
-
- ret = platform_device_add(bdc);
- if (ret) {
- dev_err(&pci->dev, "failed to register bdc device\n");
- platform_device_put(bdc);
- return ret;
- }
-
- return 0;
-}
-
-static void bdc_pci_remove(struct pci_dev *pci)
-{
- struct bdc_pci *glue = pci_get_drvdata(pci);
-
- platform_device_unregister(glue->bdc);
- pci_disable_msi(pci);
-}
-
-static struct pci_device_id bdc_pci_id_table[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BDC_PCI_PID), },
- {} /* Terminating Entry */
-};
-
-MODULE_DEVICE_TABLE(pci, bdc_pci_id_table);
-
-static struct pci_driver bdc_pci_driver = {
- .name = "bdc-pci",
- .id_table = bdc_pci_id_table,
- .probe = bdc_pci_probe,
- .remove = bdc_pci_remove,
-};
-
-MODULE_AUTHOR("Ashwini Pahuja <[email protected]>");
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("BRCM BDC USB3 PCI Glue layer");
-module_pci_driver(bdc_pci_driver);
--
2.17.1
On 1/15/2021 1:31 PM, Al Cooper wrote:
> The BDC PCI driver was only used for design verification with
> an PCI/FPGA board. The board no longer exists and is not in use
> anywhere. All instances of this core now exist as a memory mapped
> device on the platform bus.
>
> NOTE: This only removes the PCI driver and does not remove the
> platform driver.
>
> Signed-off-by: Al Cooper <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
--
Florian
On Mon, Jan 18, 2021 at 01:30:36PM +0200, Felipe Balbi wrote:
>
> Hi,
>
> Al Cooper <[email protected]> writes:
> > The BDC PCI driver was only used for design verification with
> > an PCI/FPGA board. The board no longer exists and is not in use
> > anywhere. All instances of this core now exist as a memory mapped
> > device on the platform bus.
> >
> > NOTE: This only removes the PCI driver and does not remove the
> > platform driver.
> >
> > Signed-off-by: Al Cooper <[email protected]>
>
> It sounds like it could be used for pre-silicon verification of newer
> Core Releases, much like Synopsys still uses the HAPS (with mainline
> linux, mind you) for silicon validation.
>
> Why would we delete this small shim if it *could* still be useful?
It ends up conflicting with the PCI id of a device that is actually in
the wild (a camera on Apple laptops). So it's good to drop this driver
so the wrong driver doesn't get constantly bound to the wrong device.
thnaks,
greg k-h
Hi,
Greg Kroah-Hartman <[email protected]> writes:
>> Al Cooper <[email protected]> writes:
>> > The BDC PCI driver was only used for design verification with
>> > an PCI/FPGA board. The board no longer exists and is not in use
>> > anywhere. All instances of this core now exist as a memory mapped
>> > device on the platform bus.
>> >
>> > NOTE: This only removes the PCI driver and does not remove the
>> > platform driver.
>> >
>> > Signed-off-by: Al Cooper <[email protected]>
>>
>> It sounds like it could be used for pre-silicon verification of newer
>> Core Releases, much like Synopsys still uses the HAPS (with mainline
>> linux, mind you) for silicon validation.
>>
>> Why would we delete this small shim if it *could* still be useful?
>
> It ends up conflicting with the PCI id of a device that is actually in
> the wild (a camera on Apple laptops). So it's good to drop this driver
> so the wrong driver doesn't get constantly bound to the wrong device.
I see. Oh well...
--
balbi
On Mon, Jan 18, 2021 at 1:22 PM Felipe Balbi <[email protected]> wrote:
>
>
> Hi,
>
> Greg Kroah-Hartman <[email protected]> writes:
> >> Al Cooper <[email protected]> writes:
> >> > The BDC PCI driver was only used for design verification with
> >> > an PCI/FPGA board. The board no longer exists and is not in use
> >> > anywhere. All instances of this core now exist as a memory mapped
> >> > device on the platform bus.
> >> >
> >> > NOTE: This only removes the PCI driver and does not remove the
> >> > platform driver.
> >> >
> >> > Signed-off-by: Al Cooper <[email protected]>
> >>
> >> It sounds like it could be used for pre-silicon verification of newer
> >> Core Releases, much like Synopsys still uses the HAPS (with mainline
> >> linux, mind you) for silicon validation.
> >>
> >> Why would we delete this small shim if it *could* still be useful?
> >
> > It ends up conflicting with the PCI id of a device that is actually in
> > the wild (a camera on Apple laptops). So it's good to drop this driver
> > so the wrong driver doesn't get constantly bound to the wrong device.
>
> I see. Oh well...
It would also help if this got disabled in stable so existing kernels
stop loading bdc.
Can this patch go directly into stable or should I send a patch that
adds "depends on BROKEN"?
-Patrik
Hi,
Al Cooper <[email protected]> writes:
> The BDC PCI driver was only used for design verification with
> an PCI/FPGA board. The board no longer exists and is not in use
> anywhere. All instances of this core now exist as a memory mapped
> device on the platform bus.
>
> NOTE: This only removes the PCI driver and does not remove the
> platform driver.
>
> Signed-off-by: Al Cooper <[email protected]>
It sounds like it could be used for pre-silicon verification of newer
Core Releases, much like Synopsys still uses the HAPS (with mainline
linux, mind you) for silicon validation.
Why would we delete this small shim if it *could* still be useful?
--
balbi
On Mon, Jan 18, 2021 at 01:54:16PM +0100, Patrik Jakobsson wrote:
> On Mon, Jan 18, 2021 at 1:22 PM Felipe Balbi <[email protected]> wrote:
> >
> >
> > Hi,
> >
> > Greg Kroah-Hartman <[email protected]> writes:
> > >> Al Cooper <[email protected]> writes:
> > >> > The BDC PCI driver was only used for design verification with
> > >> > an PCI/FPGA board. The board no longer exists and is not in use
> > >> > anywhere. All instances of this core now exist as a memory mapped
> > >> > device on the platform bus.
> > >> >
> > >> > NOTE: This only removes the PCI driver and does not remove the
> > >> > platform driver.
> > >> >
> > >> > Signed-off-by: Al Cooper <[email protected]>
> > >>
> > >> It sounds like it could be used for pre-silicon verification of newer
> > >> Core Releases, much like Synopsys still uses the HAPS (with mainline
> > >> linux, mind you) for silicon validation.
> > >>
> > >> Why would we delete this small shim if it *could* still be useful?
> > >
> > > It ends up conflicting with the PCI id of a device that is actually in
> > > the wild (a camera on Apple laptops). So it's good to drop this driver
> > > so the wrong driver doesn't get constantly bound to the wrong device.
> >
> > I see. Oh well...
>
> It would also help if this got disabled in stable so existing kernels
> stop loading bdc.
>
> Can this patch go directly into stable or should I send a patch that
> adds "depends on BROKEN"?
A patch for that, that I can take now for 5.11-final and backport to
stable kernels would be fine.
thanks,
greg k-h