Both of these boards are still using the PIO API sans PCI, and will need
to be carefully converted. As conversion is out of scope for this merge
window, simply make sure NO_IOPORT doesn't get accidentally set for
these, joining a long list of other crap platforms.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Everything is using sparseirq these days, so we have no need to
arbitrarily size nr_irqs ahead of time. The legacy IRQ pre-allocation
likewise has no meaning for us, so that's killed off too. We now depend
on nr_irqs expansion by the generic hardirq layer instead.
It's also worth noting that the majority of boards had completely bogus
values for their nr_irqs relative to their CPU and configurations, so
this ends up correcting behaviour for quite a few platforms.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Attempt to "tidy" up some of the multi IRQ handling and base + IRQ
management. This should keep it limping along without too much hassle,
and no new parts should ever be enabling or using this API anyways.
It doesn't get any closer to lipstick on a pig as this.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
We don't support the ISA DMA API, so this is only ever misused. The
dma-sh case inadvertently broke the dreamcast case by testing the wrong
variable for the total number of channels, so this fixes that up too.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This has turned in to quite a mess, and with CPUs that care using
dmaengine now it's about time to start cleaning up after the legacy DMA
code. For starters, kill off the stubs for the CPUs that don't do
anything, as well as all of the unused definitions. This leaves us with a
set of IRQs and base addresses we can deal with later.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
cpu-sh4a headers take priority over cpu-sh4 ones by virtue of the build
system, there's no need to try and mingle sh4a stuff in cpu-sh4.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
With the previous attempt reverted this switches to conditionalizing the
end address. Nominally VMALLOC_END, but extended for P3_ADDR_MAX in the
store queue case.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This reverts commit 20e7c297ef.
With store queues enabled the area above P4SEG has special properties
from the MMU's point of view, which was causing fixmap failure. We'll
have to do something else to satisfy the vmalloc range check.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
In doing the evt2irq() + muxed vector conversion for various port types
it became apparent that some of the legacy port types will presently
error out due to the irq requesting logic attempting to acquire the
non-existent BRI IRQ. This adds some sanity checks to the request/free
path to ensure that non-existence of a source in itself is not an error.
This should restore functionality for legacy PORT_SCI ports.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This migrates SH7786 to evt2irq() backed hwirq lookup rather than
using an open-coded calculation. This will make it possible to reposition
the vector base at a later point in time.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Pull ARM fixes from Russell King:
"Small set of fixes again."
* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM: 7419/1: vfp: fix VFP flushing regression on sigreturn path
ARM: 7418/1: LPAE: fix access flag setup in mem_type_table
ARM: prevent VM_GROWSDOWN mmaps extending below FIRST_USER_ADDRESS
ARM: 7417/1: vfp: ensure preemption is disabled when enabling VFP access
Pull two networking fixes from David S. Miller:
1) Thanks to Willy Tarreau and Eric Dumazet, we've unlocked a bug that's
been present in do_tcp_sendpages() since that function was written in
2002.
When we block to wait for memory we have to unconditionally try and
push out pending TCP data, otherwise we can block for an unreasonably
long amount of time.
2) Fix deadlock in e1000, fixes kernel bugzilla 43132
From Tushar Dave.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
e1000: Prevent reset task killing itself.
tcp: do_tcp_sendpages() must try to push data out on oom conditions
Commit 1cc0c998fd ("ACPI: Fix D3hot v D3cold confusion") introduced a
bug in __acpi_bus_set_power() and changed the behavior of
acpi_pci_set_power_state() in such a way that it generally doesn't work
as expected if PCI_D3hot is passed to it as the second argument.
First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to
__acpi_bus_set_power() and the explicit_set flag is set for the D3cold
state, the function will try to execute AML method called "_PS4", which
doesn't exist.
Fix this by adding a check to ensure that the name of the AML method
to execute for transitions to ACPI_STATE_D3_COLD is correct in
__acpi_bus_set_power(). Also make sure that the explicit_set flag
for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify
acpi_power_transition() to avoid accessing power resources for
ACPI_STATE_D3_COLD, because they don't exist.
Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the
target state, the function will request a transition to
ACPI_STATE_D3_HOT instead of ACPI_STATE_D3. However,
ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML
method is defined for the given device, which is rare. This causes
problems to happen on systems where devices were successfully put
into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work
now. In particular, some unused graphics adapters are not turned
off as a result.
To fix this issue restore the old behavior of
acpi_pci_set_power_state(), which is to request a transition to
ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or
PCI_D3cold is passed to it as the argument.
This approach is not ideal, because generally power should not
be removed from devices if PCI_D3hot is the target power state,
but since this behavior is relied on, we have no choice but to
restore it at the moment and spend more time on designing a
better solution in the future.
References: https://bugzilla.kernel.org/show_bug.cgi?id=43228
Reported-by: rocko <rockorequin@hotmail.com>
Reported-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Reported-and-tested-by: Peter <lekensteyn@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
