The kernel boot parameter 'nr_cpus=' allows one to specify number of
possible cpus in the system. In the normal scenario the first cpu (cpu0)
that shows up is the boot cpu and hence it gets covered under nr_cpus
limit.
But this assumption will be broken in kdump scenario where kdump kenrel
after a crash can boot up on an non-zero boot cpu. The paca structure
allocation depends on value of nr_cpus and is indexed using logical cpu
ids. This definetly will be an issue if boot cpu id > nr_cpus
This patch modifies allocate_pacas() and smp_setup_cpu_maps() to
accommodate boot cpu for the case where boot_cpuid > nr_cpu_ids.
This change would help to reduce the memory reservation requirement for
kdump on ppc64.
The domain/PHB field of PCI addresses has its value obtained from a
global variable, incremented each time a new domain (represented by
struct pci_controller) is added on the system. The domain addition
process happens during boot or due to PCI device hotplug.
As recent kernels are using predictable naming for network interfaces,
the network stack is more tied to PCI naming. This can be a problem in
hotplug scenarios, because PCI addresses will change if devices are
removed and then re-added. This situation seems unusual, but it can
happen if a user wants to replace a NIC without rebooting the machine,
for example.
This patch changes the way PCI domain values are generated: now, we use
device-tree properties to assign fixed PHB numbers to PCI addresses
when available (meaning pSeries and PowerNV cases). We also use a bitmap
to allow dynamic PHB numbering when device-tree properties are not
used. This bitmap keeps track of used PHB numbers and if a PHB is
released (by hotplug operations for example), it allows the reuse of
this PHB number, avoiding PCI address to change in case of device remove
and re-add soon after. No functional changes were introduced.
Reviewed-by: Gavin Shan <email address hidden>
Signed-off-by: Guilherme G. Piccoli <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
Previously we selected MDIO_OCTEON, which after creating the Thunder
specific MDIO bus driver is much less useful.
Signed-off-by: David Daney <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 9277a4f875adbeeb6209c0a3e3cf04c752522b2e)
Signed-off-by: dann frazier <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
When the code was factored out of mdio-octeon.c, the
MODULE_DESCRIPTION, MODULE_AUTHOR and MODULE_LICENSE annotations were
inadvertently omitted. Restore them so that we don't get kernel taint
warnings upon module loading.
Signed-off-by: David Daney <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 7091f01e8cf6989e63c4eacb59b654fcff057901)
Signed-off-by: dann frazier <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
The Cavium Thunder SoCs have multiple MIDO buses that are part of a
single PCI device. To model this in the device tree we call the PCI
parent device a "cavium,thunder-8890-mdio-nexus", it has several
children, one for each MDIO bus.
The MDIO bus hardware is identical to that found in the OCTEON SoCs,
so we use that code for things that are not part of the PCI driver
probe/remove
Signed-off-by: David Daney <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 379d7ac7ca31722a1fb488ae3e98b274c9db568c)
Signed-off-by: dann frazier <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
A follow-on patch uses PCI probing to find the Thunder MDIO hardware.
In preparation for this, split out the common code into a new file
mdio-cavium.c, which will be used by both the existing OCTEON driver,
and the new Thunder PCI based driver.
As part of the refactoring simplify the struct cavium_mdiobus by
removing fields that are only ever used in the probe function and can
just as well be local variables.
Use readq/writeq in preference to readq_relaxed/writeq_relaxed as the
relaxed form was an optimization for an early chip revision, and the
MDIO drivers are not performance bottlenecks that need optimization in
the first place.
Signed-off-by: David Daney <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 1eefee901fca0208b8a56f20cdc134e2b8638ae7)
[ dannf: backported to v4.4 ]
Signed-off-by: dann frazier <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
