Previously, it was "dwc_otg", but this does not correspond to the
directory name and might cause confusion with the old out-of-tree
dwc_otg driver of which many versions circulate.
Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
Acked-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The work item has been added to the queue using INIT_WORK and scheduled
in interrupt handler. when module unloads that work item has not been
removed from the queue. remove and stop its further execution when the
module unloaded
Cc: Mark Einon <mark.einon@gmail.com>
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Before, this was initialized in pci.c, after the dwc2_hcd_init was
called and the interrupts were enabled. This opened up a small time
window where common interrupts could be triggered, but there was no
handler for them, causing them to keep triggering infinitely and locking
up the machine.
On my RT3052 board this bug could be easily reproduced by hardcoding
the console log level to 8, so that a bunch of debug output from the dwc2
driver was generated inside this time window. This caused the interrupt
lockup to occur almost every time.
By requesting the irq inside dwc2_core_init and by disabling interrupts
before calling dwc2_core_init instead of after, we can be sure the
handler is registered before the interrupts are enabled, which should
close this window.
Reported-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
Acked-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It seems this flag is intended to pass to irq_set_status_flags, not
request_irq, and is not available on all architectures. Its value
corresponds to IRQF_PROBE_SHARED, which shouldn't be needed for this
driver, so removing this flag should be safe.
Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
Acked-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
zero-filled pages won't be compressed and sent to remote system. Monitor
the number ephemeral and persistent pages that Ramster has sent make no
sense. This patch skip account foregin counters against zero-filled pages.
Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
One of the main things to do to the driver is to support
the common display famework (CDF) to hit mainline. As this will
make some changes to the devicetree bindings necessary it makes
sense to do it before we move out of staging.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When it is used, the entire PCI bar is ioremap'ed with pci_ioremap_bar().
The i_IorangeBase3 boardinfo is no longer needed.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use pci_ioremap_bar() to ioremap the PCI resources. That function
just takes the pci device and a bar number. It also has some
additional sanity checks to make sure the bar is actually a
memory resource.
This also makes sure that the entire PCI bar is ioremap'ed instead
of assuming the size of the bar.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use pci_ioremap_bar() to ioremap the PCI resources. That function
just takes the pci device and a bar number. It also has some
additional sanity checks to make sure the bar is actually a
memory resource.
This also makes sure that the entire PCI bar is ioremap'ed instead
of assuming the size of the bar.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use pci_ioremap_bar() to ioremap the PCI resources. That function
just takes the pci device and a bar number. It also has some
additional sanity checks to make sure the bar is actually a
memory resource.
This also makes sure that the entire PCI bar is ioremap'ed instead
of assuming the size of a bar.
For aesthetic reasons, don't set the private data phys_addr vars
until after the ioremap is successful.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use pci_ioremap_bar() to ioremap the PCI resources. That function
just takes the pci device and a bar number. It also has some
additional sanity checks to make sure the bar is actually a
memory resource.
This also makes sure that the entire PCI bar is ioremap'ed instead
of assuming the size of the bar.
Also, since this driver only uses memory mapped I/O it is not
necessary to set the dev->iobase.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use pci_ioremap_bar() to ioremap the PCI resources. That function
just takes the pci device and a bar number. It also has some
additional sanity checks to make sure the bar is actually a
memory resource.
Refactor the code a bit. The dev->iobase only needs to be set
when the board does not use memory mapped I/O. And the 'iobase'
passed to subdev_8255_init() is an unsigned long.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use pci_ioremap_bar() to ioremap the PCI resources. That function
just takes the pci device and a bar number. It also has some
additional sanity checks to make sure the bar is actually a
memory resource.
This also makes sure that the entire PCI bar is ioremap'ed instead
of assuming the size of the bar.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This driver does not use the dev->iobase so don't bother initializing
it.
The plx9080_phys_iobase is not used in the driver. Remove it from the
private data.
Tidy up the initialization of the other phy_iobase variables.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use pci_ioremap_bar() to ioremap the PCI resources. That function
just takes the pci device and a bar number. It also has some
additional sanity checks to make sure the bar is actually a
memory resource.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use pci_ioremap_bar() to ioremap the PCI resources. That function
just takes the pci device and a bar number. It also has some
additional sanity checks to make sure the bar is actually a
memory resource.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use pci_ioremap_bar() to ioremap the PCI resources. That function
just takes the pci device and a bar number. It also has some
additional sanity checks to make sure the bar is actually a
memory resource.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use pci_ioremap_bar() to ioremap the PCI resources. That function
just takes the pci device and a bar number. It also has some
additional sanity checks to make sure the bar is actually a
memory resource.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>