| Age | Commit message (Collapse) | Author |
|---|
|
To prepare for interrupt spreading reduce the storage size of
irq_info::spurious_cnt to u8 so the required flag for the spreading logic
will not increase the storage size.
Protect the usage site against overruns.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Link: https://lore.kernel.org/r/20201210194045.360198201@linutronix.de
|
|
All event channel setups bind the interrupt on CPU0 or the target CPU for
percpu interrupts and overwrite the affinity mask with the corresponding
cpumask. That does not make sense.
The XEN implementation of irqchip::irq_set_affinity() already picks a
single target CPU out of the affinity mask and the actual target is stored
in the effective CPU mask, so destroying the user chosen affinity mask
which might contain more than one CPU is wrong.
Change the implementation so that the channel is bound to CPU0 at the XEN
level and leave the affinity mask alone. At startup of the interrupt
affinity will be assigned out of the affinity mask and the XEN binding will
be updated. Only keep the enforcement for real percpu interrupts.
On resume the overwrite is not required either because info->cpu and the
affinity mask are still the same as at the time of suspend. Same for
rebind_evtchn_irq().
This also prepares for proper interrupt spreading.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Link: https://lore.kernel.org/r/20201210194045.250321315@linutronix.de
|
|
There is absolutely no reason to mimic the x86 deferred affinity
setting. This mechanism is required to handle the hardware induced issues
of IO/APIC and MSI and is not in use when the interrupts are remapped.
XEN does not need this and can simply change the affinity from the calling
context. The core code invokes this with the interrupt descriptor lock held
so it is fully serialized against any other operation.
Mark the interrupts with IRQ_MOVE_PCNTXT to disable the deferred affinity
setting. The conditional mask/unmask operation is already handled in
xen_rebind_evtchn_to_cpu().
This makes XEN on x86 use the same mechanics as on e.g. ARM64 where
deferred affinity setting is not required and not implemented and the code
path in the ack functions is compiled out.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Link: https://lore.kernel.org/r/20201210194045.157601122@linutronix.de
|
|
This function can only ever work when the event channels:
- are already established
- interrupts assigned to them
- the affinity has been set by user space already
because any newly set up event channel is forced to be bound to CPU0 and
the affinity mask of the interrupt is forced to contain cpumask_of(0).
As the CPU0 enforcement was in place _before_ this was implemented it's
entirely unclear how that can ever have worked at all.
Remove it as preparation for doing it proper.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Link: https://lore.kernel.org/r/20201210194045.065115500@linutronix.de
|
|
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Link: https://lore.kernel.org/r/20201210194044.972064156@linutronix.de
|
|
Using the interrupt affinity mask for checking locality is not really
working well on architectures which support effective affinity masks.
The affinity mask is either the system wide default or set by user space,
but the architecture can or even must reduce the mask to the effective set,
which means that checking the affinity mask itself does not really tell
about the actual target CPUs.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Saeed Mahameed <saeedm@nvidia.com>
Link: https://lore.kernel.org/r/20201210194044.876342330@linutronix.de
|
|
No driver has any business with the internals of an interrupt
descriptor. Storing a pointer to it just to use yet another helper at the
actual usage site to retrieve the affinity mask is creative at best. Just
because C does not allow encapsulation does not mean that the kernel has no
limits.
Retrieve a pointer to the affinity mask itself and use that. It's still
using an interface which is usually not for random drivers, but definitely
less hideous than the previous hack.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Saeed Mahameed <saeedm@nvidia.com>
Link: https://lore.kernel.org/r/20201210194044.769458162@linutronix.de
|
|
Using the interrupt affinity mask for checking locality is not really
working well on architectures which support effective affinity masks.
The affinity mask is either the system wide default or set by user space,
but the architecture can or even must reduce the mask to the effective set,
which means that checking the affinity mask itself does not really tell
about the actual target CPUs.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Tariq Toukan <tariqt@nvidia.com>
Link: https://lore.kernel.org/r/20201210194044.672935978@linutronix.de
|
|
No driver has any business with the internals of an interrupt
descriptor. Storing a pointer to it just to use yet another helper at the
actual usage site to retrieve the affinity mask is creative at best. Just
because C does not allow encapsulation does not mean that the kernel has no
limits.
Retrieve a pointer to the affinity mask itself and use that. It's still
using an interface which is usually not for random drivers, but definitely
less hideous than the previous hack.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Tariq Toukan <tariqt@nvidia.com>
Link: https://lore.kernel.org/r/20201210194044.580936243@linutronix.de
|
|
Going through a full irq descriptor lookup instead of just using the proper
helper function which provides direct access is suboptimal.
In fact it _is_ wrong because the chip callback needs to get the chip data
which is relevant for the chip while using the irq descriptor variant
returns the irq chip data of the top level chip of a hierarchy. It does not
matter in this case because the chip is the top level chip, but that
doesn't make it more correct.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20201210194044.473308721@linutronix.de
|
|
Going through a full irq descriptor lookup instead of just using the proper
helper function which provides direct access is suboptimal.
In fact it _is_ wrong because the chip callback needs to get the chip data
which is relevant for the chip while using the irq descriptor variant
returns the irq chip data of the top level chip of a hierarchy. It does not
matter in this case because the chip is the top level chip, but that
doesn't make it more correct.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20201210194044.364211860@linutronix.de
|
|
Use the proper core function.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Link: https://lore.kernel.org/r/20201210194044.255887860@linutronix.de
|
|
First of all drivers have absolutely no business to dig into the internals
of an irq descriptor. That's core code and subject to change. All of this
information is readily available to /proc/interrupts in a safe and race
free way.
Remove the inspection code which is a blatant violation of subsystem
boundaries and racy against concurrent modifications of the interrupt
descriptor.
Print the irq line instead so the information can be looked up in a sane
way in /proc/interrupts.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20201210194044.157283633@linutronix.de
|
|
Let the core code do the fiddling with irq_desc.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201210194044.065003856@linutronix.de
|
|
Driver code has no business with the internals of the irq descriptor.
Aside of that the count is per interrupt line and therefore takes
interrupts from other devices into account which share the interrupt line
and are not handled by the graphics driver.
Replace it with a pmu private count which only counts interrupts which
originate from the graphics card.
To avoid atomics or heuristics of some sort make the counter field
'unsigned long'. That limits the count to 4e9 on 32bit which is a lot and
postprocessing can easily deal with the occasional wraparound.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: https://lore.kernel.org/r/20201210194043.957046529@linutronix.de
|
|
Nothing uses the result and nothing should ever use it in driver code.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20201210194043.862572239@linutronix.de
|
|
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Link: https://lore.kernel.org/r/20201210194043.769108348@linutronix.de
|
|
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-parisc@vger.kernel.org
Link: https://lore.kernel.org/r/20201210194043.659522455@linutronix.de
|
|
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201210194043.546326568@linutronix.de
|
|
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20201210194043.454288890@linutronix.de
|
|
Most users of kstat_irqs_cpu() have the irq descriptor already. No point in
calling into the core code and looking it up once more.
Use it in per_cpu_count_show() to start with.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201210194043.362094758@linutronix.de
|
|
No more users outside the core code.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201210194043.268774449@linutronix.de
|
|
The SMP variant works perfectly fine on UP as well.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-parisc@vger.kernel.org
Link: https://lore.kernel.org/r/20201210194043.172893840@linutronix.de
|
|
Both the per cpu stats and the accumulated count are accessed lockless and
can be concurrently modified. That's intentional and the stats are a rough
estimate anyway. Annotate them with data_race().
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201210194043.067097663@linutronix.de
|
|
Provide an accessor to the effective interrupt affinity mask. Going to be
used to replace open coded fiddling with the irq descriptor.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201210194042.967177918@linutronix.de
|
|
irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
be exported. Move it into the core code which lifts another requirement for
the export.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201210194042.860029489@linutronix.de
|
|
These checks are used by modules and prevent the removal of the export of
irq_to_desc(). Move the accessor into the core.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201210194042.703779349@linutronix.de
|
|
This function uses irq_to_desc() and is going to be used by modules to
replace the open coded irq_to_desc() (ab)usage. The final goal is to remove
the export of irq_to_desc() so driver cannot fiddle with it anymore.
Move it into the core code and fixup the usage sites to include the proper
header.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201210194042.548936472@linutronix.de
|
|
Commit e1c92a7fbbc5 ("perf tests: Add another metric parsing test") add
another test for metric parsing. The test goes through all metrics
compiled for arch within pmu events and try to parse them.
Right now this test is failing in powerpc machine.
Result in power9 platform:
[command]# ./perf test 10
10: PMU events :
10.1: PMU event table sanity : Ok
10.2: PMU event map aliases : Ok
10.3: Parsing of PMU event table metrics : Skip (some metrics failed)
10.4: Parsing of PMU event table metrics with fake PMUs : FAILED!
Issue is we are passing different runtime parameter value in
"expr__find_other" and "expr__parse" function which is called from
function `metric_parse_fake`. And because of this parsing of hv-24x7
metrics is failing.
[command]# ./perf test 10 -vv
.....
hv_24x7/pm_mcs01_128b_rd_disp_port01,chip=1/ not found
expr__parse failed
test child finished with -1
---- end ----
PMU events subtest 4: FAILED!
This patch fix this issue and change runtime parameter value to '0' in
expr__parse function.
Result in power9 platform after this patch:
[command]# ./perf test 10
10: PMU events :
10.1: PMU event table sanity : Ok
10.2: PMU event map aliases : Ok
10.3: Parsing of PMU event table metrics : Skip (some metrics failed)
10.4: Parsing of PMU event table metrics with fake PMUs : Ok
Fixes: e1c92a7fbbc5 ("perf tests: Add another metric parsing test")
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
Acked-by: Ian Rogers <irogers@google.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Link: http://lore.kernel.org/lkml/20201119152411.46041-1-kjain@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
* acpi-ec:
ACPI: EC: Clean up status flags checks in advance_transaction()
ACPI: EC: Untangle error handling in advance_transaction()
ACPI: EC: Simplify error handling in advance_transaction()
ACPI: EC: Rename acpi_ec_is_gpe_raised()
ACPI: EC: Fold acpi_ec_clear_gpe() into its caller
ACPI: EC: Eliminate in_interrupt() usage
|
|
* acpi-apei:
ACPI, APEI: make apei_resources_all static
* acpi-misc:
ACPI: acpi_drivers.h: Update the kernel doc
ACPI: acpi_drivers.h: Remove the leftover dead code
ACPI: tiny-power-button: Simplify the code using module_acpi_driver()
ACPI: SBS: Simplify the code using module_acpi_driver()
ACPI: SBS: Simplify the driver init code
ACPI: debug: Remove the not used function
ACPI: processor: Remove the duplicated ACPI_PROCESSOR_CLASS macro
* acpi-processor:
ACPI: processor: Drop duplicate setting of shared_cpu_map
|
|
* acpi-resources:
Revert "ACPI / resources: Use AE_CTRL_TERMINATE to terminate resources walks"
resource: provide meaningful MODULE_LICENSE() in test suite
ASoC: Intel: catpt: Replace open coded variant of resource_intersection()
ACPI: watchdog: Replace open coded variant of resource_union()
PCI/ACPI: Replace open coded variant of resource_union()
resource: Add test cases for new resource API
resource: Introduce resource_intersection() for overlapping resources
resource: Introduce resource_union() for overlapping resources
resource: Group resource_overlaps() with other inline helpers
resource: Simplify region_intersects() by reducing conditionals
* acpi-docs:
Documentation: ACPI: enumeration: add PCI hierarchy representation
Documentation: ACPI: _DSD: enable hyperlink in final references
Documentation: ACPI: explain how to use gpio-line-names
|
|
* acpica:
ACPICA: Update version to 20201113
ACPICA: Interpreter: fix memory leak by using existing buffer
ACPICA: Add function trace macros to improve debugging
ACPICA: Also handle "orphan" _REG methods for GPIO OpRegions
ACPICA: Remove extreaneous "the" in comments
ACPICA: Add 5 new UUIDs to the known UUID table
* acpi-scan:
ACPI: scan: Fix up _DEP-related terminology with supplier/consumer
ACPI: scan: Drop INT3396 from acpi_ignore_dep_ids[]
ACPI: scan: Add PNP0D80 to the _DEP exceptions list
ACPI: scan: Call acpi_get_object_info() from acpi_add_single_object()
ACPI: scan: Add acpi_info_matches_hids() helper
|
|
In order for tracepoints to export their enums to user space, the use of the
TRACE_DEFINE_ENUM() macro is used. On boot up, the strings shown in the
tracefs "print fmt" lines are processed, and all the enums registered by
TRACE_DEFINE_ENUM are replaced with the interger value. This way, userspace
tools that read the raw binary data, knows how to evaluate the raw events.
This is currently done in an initcall, but it has been noticed that slow
embedded boards that have tracing may take a few seconds to process them
all, and a few seconds slow down on an embedded device is detrimental to the
system.
Instead, offload the work to a work queue and make sure that its finished by
destroying the work queue (which flushes all work) in a late initcall. This
will allow the system to continue to boot and run the updates in the
background, and this speeds up the boot time. Note, the strings being
updated are only used by user space, so finishing the process before the
system is fully booted will prevent any race issues.
Link: https://lore.kernel.org/r/68d7b3327052757d0cd6359a6c9015a85b437232.camel@pengutronix.de
Reported-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
|
|
* pm-devfreq:
PM / devfreq: tegra30: Separate configurations per-SoC generation
PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver
PM / devfreq: exynos-bus: Add registration of interconnect child device
dt-bindings: devfreq: Add documentation for the interconnect properties
soc/tegra: fuse: Add stub for tegra_sku_info
soc/tegra: fuse: Export tegra_read_ram_code()
clk: tegra: Export Tegra20 EMC kernel symbols
PM / devfreq: tegra30: Silence deferred probe error
PM / devfreq: tegra20: Relax Kconfig dependency
PM / devfreq: tegra20: Silence deferred probe error
PM / devfreq: Remove redundant governor_name from struct devfreq
PM / devfreq: Add governor attribute flag for specifc sysfs nodes
PM / devfreq: Add governor feature flag
PM / devfreq: Add tracepoint for frequency changes
PM / devfreq: Unify frequency change to devfreq_update_target func
trace: events: devfreq: Use fixed indentation size to improve readability
* pm-tools:
pm-graph v5.8
cpupower: Provide online and offline CPU information
|
|
* pm-sleep:
PM: sleep: Add dev_wakeup_path() helper
PM / suspend: fix kernel-doc markup
PM: sleep: Print driver flags for all devices during suspend/resume
* pm-acpi:
PM: ACPI: Refresh wakeup device power configuration every time
PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup()
PM: ACPI: reboot: Use S5 for reboot
* pm-domains:
PM: domains: create debugfs nodes when adding power domains
PM: domains: replace -ENOTSUPP with -EOPNOTSUPP
* powercap:
powercap: Adjust printing the constraint name with new line
powercap: RAPL: Add AMD Fam19h RAPL support
powercap: Add AMD Fam17h RAPL support
powercap/intel_rapl_msr: Convert rapl_msr_priv into pointer
x86/msr-index: sort AMD RAPL MSRs by address
|
|
* pm-cpuidle:
cpuidle: Select polling interval based on a c-state with a longer target residency
cpuidle: psci: Enable suspend-to-idle for PSCI OSI mode
PM: domains: Enable dev_pm_genpd_suspend|resume() for suspend-to-idle
PM: domains: Rename pm_genpd_syscore_poweroff|poweron()
* pm-em:
PM / EM: Micro optimization in em_cpu_energy
PM: EM: Update Energy Model with new flag indicating power scale
PM: EM: update the comments related to power scale
PM: EM: Clarify abstract scale usage for power values in Energy Model
|
|
* pm-cpufreq: (31 commits)
cpufreq: Fix cpufreq_online() return value on errors
cpufreq: Fix up several kerneldoc comments
cpufreq: stats: Use local_clock() instead of jiffies
cpufreq: schedutil: Simplify sugov_update_next_freq()
cpufreq: intel_pstate: Simplify intel_cpufreq_update_pstate()
cpufreq: arm_scmi: Discover the power scale in performance protocol
firmware: arm_scmi: Add power_scale_mw_get() interface
cpufreq: tegra194: Rename tegra194_get_speed_common function
cpufreq: tegra194: Remove unnecessary frequency calculation
cpufreq: tegra186: Simplify cluster information lookup
cpufreq: tegra186: Fix sparse 'incorrect type in assignment' warning
cpufreq: imx: fix NVMEM_IMX_OCOTP dependency
cpufreq: vexpress-spc: Add missing MODULE_ALIAS
cpufreq: scpi: Add missing MODULE_ALIAS
cpufreq: loongson1: Add missing MODULE_ALIAS
cpufreq: sun50i: Add missing MODULE_DEVICE_TABLE
cpufreq: st: Add missing MODULE_DEVICE_TABLE
cpufreq: qcom: Add missing MODULE_DEVICE_TABLE
cpufreq: mediatek: Add missing MODULE_DEVICE_TABLE
cpufreq: highbank: Add missing MODULE_DEVICE_TABLE
...
|
|
When building with W=1, GCC complains that we haven't defined prototypes
for a number of non-static functions in entry-common.c:
| arch/arm64/kernel/entry-common.c:203:25: warning: no previous prototype for 'el1_sync_handler' [-Wmissing-prototypes]
| 203 | asmlinkage void noinstr el1_sync_handler(struct pt_regs *regs)
| | ^~~~~~~~~~~~~~~~
| arch/arm64/kernel/entry-common.c:377:25: warning: no previous prototype for 'el0_sync_handler' [-Wmissing-prototypes]
| 377 | asmlinkage void noinstr el0_sync_handler(struct pt_regs *regs)
| | ^~~~~~~~~~~~~~~~
| arch/arm64/kernel/entry-common.c:447:25: warning: no previous prototype for 'el0_sync_compat_handler' [-Wmissing-prototypes]
| 447 | asmlinkage void noinstr el0_sync_compat_handler(struct pt_regs *regs)
| | ^~~~~~~~~~~~~~~~~~~~~~~
... and so automated build systems using W=1 end up sending a number of
emails, despite this not being a real problem as the only callers are in
entry.S where prototypes cannot matter.
For similar cases in entry-common.c we added prototypes to
asm/exception.h, so let's do the same thing here for consistency.
Note that there are a number of other warnings printed with W=1, both
under arch/arm64 and in core code, and this patch only addresses the
cases in entry-common.c. Automated build systems typically filter these
warnings such that they're only reported when changes are made nearby,
so we don't need to solve them all at once.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20201214113353.44417-1-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
The previous call to update_freq_counters_refs() has already updated the
per-cpu variables, don't overwrite them with the same value again.
Fixes: 4b9cf23c179a ("arm64: wrap and generalise counter read functions")
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/7a171f710cdc0f808a2bfbd7db839c0d265527e7.1607579234.git.viresh.kumar@linaro.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
This makes it easy to disable building with -Werror:
$ make defconfig
$ grep WERROR .config
# CONFIG_PPC_DISABLE_WERROR is not set
CONFIG_PPC_WERROR=y
$ make disable-werror.config
GEN Makefile
Using .config as base
Merging arch/powerpc/configs/disable-werror.config
Value of CONFIG_PPC_DISABLE_WERROR is redefined by fragment arch/powerpc/configs/disable-werror.config:
Previous value: # CONFIG_PPC_DISABLE_WERROR is not set
New value: CONFIG_PPC_DISABLE_WERROR=y
...
$ grep WERROR .config
CONFIG_PPC_DISABLE_WERROR=y
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201023040002.3313371-1-mpe@ellerman.id.au
|
|
Add a phony target for ppc64le_allnoconfig, which tests some
combinations of CONFIG symbols that aren't covered by any of our
defconfigs.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201125031551.2112715-1-mpe@ellerman.id.au
|
|
Sometimes we can't read an error log from OPAL, and we print an error
message accordingly. But the OPAL userspace tools seem to like retrying a
lot, in which case we flood the kernel log with a lot of messages.
Change pr_err() to pr_err_ratelimited() to help with this.
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201211021140.28402-1-ajd@linux.ibm.com
|
|
When attempting to remove by index a set of LMBs a lot of messages are
displayed on the console, even when everything goes fine:
pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 8000002d
Offlined Pages 4096
pseries-hotplug-mem: Memory at 2d0000000 was hot-removed
The 2 messages prefixed by "pseries-hotplug-mem" are not really
helpful for the end user, they should be debug outputs.
In case of error, because some of the LMB's pages couldn't be
offlined, the following is displayed on the console:
pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 8000003e
pseries-hotplug-mem: Failed to hot-remove memory at 3e0000000
dlpar: Could not handle DLPAR request "memory remove index 0x8000003e"
Again, the 2 messages prefixed by "pseries-hotplug-mem" are useless,
and the generic DLPAR prefixed message should be enough.
These 2 first changes are mainly triggered by the changes introduced
in drmgr:
https://groups.google.com/g/powerpc-utils-devel/c/Y6ef4NB3EzM/m/9cu5JHRxAQAJ
Also, when adding a bunch of LMBs, a message is displayed in the console per LMB
like these ones:
pseries-hotplug-mem: Memory at 7e0000000 (drc index 8000007e) was hot-added
pseries-hotplug-mem: Memory at 7f0000000 (drc index 8000007f) was hot-added
pseries-hotplug-mem: Memory at 800000000 (drc index 80000080) was hot-added
pseries-hotplug-mem: Memory at 810000000 (drc index 80000081) was hot-added
When adding 1TB of memory and LMB size is 256MB, this leads to 4096
messages to be displayed on the console. These messages are not really
helpful for the end user, so moving them to the DEBUG level.
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
[mpe: Tweak change log wording]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201211145954.90143-1-ldufour@linux.ibm.com
|
|
The DMA address returned by dma_map_single() should be checked with
dma_mapping_error(). Fix the ps3stor_setup() function accordingly.
Fixes: 80071802cb9c ("[POWERPC] PS3: Storage Driver Core")
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201213182622.23047-1-vincent.stehle@laposte.net
|
|
with GCC10
ppc-linux-objdump -d vmlinux | grep -e "<csum_partial>" -e "<__csum_partial>"
With gcc9 I get:
c0017ef8 <__csum_partial>:
c00182fc: 4b ff fb fd bl c0017ef8 <__csum_partial>
c0018478: 4b ff fa 80 b c0017ef8 <__csum_partial>
c03e8458: 4b c2 fa a0 b c0017ef8 <__csum_partial>
c03e8518: 4b c2 f9 e1 bl c0017ef8 <__csum_partial>
c03ef410: 4b c2 8a e9 bl c0017ef8 <__csum_partial>
c03f0b24: 4b c2 73 d5 bl c0017ef8 <__csum_partial>
c04279a4: 4b bf 05 55 bl c0017ef8 <__csum_partial>
c0429820: 4b be e6 d9 bl c0017ef8 <__csum_partial>
c0429944: 4b be e5 b5 bl c0017ef8 <__csum_partial>
c042b478: 4b be ca 81 bl c0017ef8 <__csum_partial>
c042b554: 4b be c9 a5 bl c0017ef8 <__csum_partial>
c045f15c: 4b bb 8d 9d bl c0017ef8 <__csum_partial>
c0492190: 4b b8 5d 69 bl c0017ef8 <__csum_partial>
c0492310: 4b b8 5b e9 bl c0017ef8 <__csum_partial>
c0495594: 4b b8 29 65 bl c0017ef8 <__csum_partial>
c049c420: 4b b7 ba d9 bl c0017ef8 <__csum_partial>
c049c870: 4b b7 b6 89 bl c0017ef8 <__csum_partial>
c049c930: 4b b7 b5 c9 bl c0017ef8 <__csum_partial>
c04a9ca0: 4b b6 e2 59 bl c0017ef8 <__csum_partial>
c04bdde4: 4b b5 a1 15 bl c0017ef8 <__csum_partial>
c04be480: 4b b5 9a 79 bl c0017ef8 <__csum_partial>
c04be710: 4b b5 97 e9 bl c0017ef8 <__csum_partial>
c04c969c: 4b b4 e8 5d bl c0017ef8 <__csum_partial>
c04ca2fc: 4b b4 db fd bl c0017ef8 <__csum_partial>
c04cf5bc: 4b b4 89 3d bl c0017ef8 <__csum_partial>
c04d0440: 4b b4 7a b9 bl c0017ef8 <__csum_partial>
With gcc10 I get:
c0018d08 <__csum_partial>:
c0019020 <csum_partial>:
c0019020: 4b ff fc e8 b c0018d08 <__csum_partial>
c001914c: 4b ff fe d4 b c0019020 <csum_partial>
c0019250: 4b ff fd d1 bl c0019020 <csum_partial>
c03e404c <csum_partial>:
c03e404c: 4b c3 4c bc b c0018d08 <__csum_partial>
c03e4050: 4b ff ff fc b c03e404c <csum_partial>
c03e40fc: 4b ff ff 51 bl c03e404c <csum_partial>
c03e6680: 4b ff d9 cd bl c03e404c <csum_partial>
c03e68c4: 4b ff d7 89 bl c03e404c <csum_partial>
c03e7934: 4b ff c7 19 bl c03e404c <csum_partial>
c03e7bf8: 4b ff c4 55 bl c03e404c <csum_partial>
c03eb148: 4b ff 8f 05 bl c03e404c <csum_partial>
c03ecf68: 4b c2 bd a1 bl c0018d08 <__csum_partial>
c04275b8 <csum_partial>:
c04275b8: 4b bf 17 50 b c0018d08 <__csum_partial>
c0427884: 4b ff fd 35 bl c04275b8 <csum_partial>
c0427b18: 4b ff fa a1 bl c04275b8 <csum_partial>
c0427bd8: 4b ff f9 e1 bl c04275b8 <csum_partial>
c0427cd4: 4b ff f8 e5 bl c04275b8 <csum_partial>
c0427e34: 4b ff f7 85 bl c04275b8 <csum_partial>
c045a1c0: 4b bb eb 49 bl c0018d08 <__csum_partial>
c0489464 <csum_partial>:
c0489464: 4b b8 f8 a4 b c0018d08 <__csum_partial>
c04896b0: 4b ff fd b5 bl c0489464 <csum_partial>
c048982c: 4b ff fc 39 bl c0489464 <csum_partial>
c0490158: 4b b8 8b b1 bl c0018d08 <__csum_partial>
c0492f0c <csum_partial>:
c0492f0c: 4b b8 5d fc b c0018d08 <__csum_partial>
c049326c: 4b ff fc a1 bl c0492f0c <csum_partial>
c049333c: 4b ff fb d1 bl c0492f0c <csum_partial>
c0493b18: 4b ff f3 f5 bl c0492f0c <csum_partial>
c0493f50: 4b ff ef bd bl c0492f0c <csum_partial>
c0493ffc: 4b ff ef 11 bl c0492f0c <csum_partial>
c04a0f78: 4b b7 7d 91 bl c0018d08 <__csum_partial>
c04b3e3c: 4b b6 4e cd bl c0018d08 <__csum_partial>
c04b40d0 <csum_partial>:
c04b40d0: 4b b6 4c 38 b c0018d08 <__csum_partial>
c04b4448: 4b ff fc 89 bl c04b40d0 <csum_partial>
c04b46f4: 4b ff f9 dd bl c04b40d0 <csum_partial>
c04bf448: 4b b5 98 c0 b c0018d08 <__csum_partial>
c04c5264: 4b b5 3a a5 bl c0018d08 <__csum_partial>
c04c61e4: 4b b5 2b 25 bl c0018d08 <__csum_partial>
gcc10 defines multiple versions of csum_partial() which are just
an unconditionnal branch to __csum_partial().
To enforce inlining of that branch to __csum_partial(),
mark csum_partial() as __always_inline.
With this patch with gcc10:
c0018d08 <__csum_partial>:
c0019148: 4b ff fb c0 b c0018d08 <__csum_partial>
c001924c: 4b ff fa bd bl c0018d08 <__csum_partial>
c03e40ec: 4b c3 4c 1d bl c0018d08 <__csum_partial>
c03e4120: 4b c3 4b e8 b c0018d08 <__csum_partial>
c03eb004: 4b c2 dd 05 bl c0018d08 <__csum_partial>
c03ecef4: 4b c2 be 15 bl c0018d08 <__csum_partial>
c0427558: 4b bf 17 b1 bl c0018d08 <__csum_partial>
c04286e4: 4b bf 06 25 bl c0018d08 <__csum_partial>
c0428cd8: 4b bf 00 31 bl c0018d08 <__csum_partial>
c0428d84: 4b be ff 85 bl c0018d08 <__csum_partial>
c045a17c: 4b bb eb 8d bl c0018d08 <__csum_partial>
c0489450: 4b b8 f8 b9 bl c0018d08 <__csum_partial>
c0491860: 4b b8 74 a9 bl c0018d08 <__csum_partial>
c0492eec: 4b b8 5e 1d bl c0018d08 <__csum_partial>
c04a0eac: 4b b7 7e 5d bl c0018d08 <__csum_partial>
c04b3e34: 4b b6 4e d5 bl c0018d08 <__csum_partial>
c04b426c: 4b b6 4a 9d bl c0018d08 <__csum_partial>
c04b463c: 4b b6 46 cd bl c0018d08 <__csum_partial>
c04c004c: 4b b5 8c bd bl c0018d08 <__csum_partial>
c04c0368: 4b b5 89 a1 bl c0018d08 <__csum_partial>
c04c5254: 4b b5 3a b5 bl c0018d08 <__csum_partial>
c04c60d4: 4b b5 2c 35 bl c0018d08 <__csum_partial>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/a1d31f84ddb0926813b17fcd5cc7f3fa7b4deac2.1602759123.git.christophe.leroy@csgroup.eu
|
|
Threshold Event Counter Multiplier (TECM) is part of Monitor Mode
Control Register A (MMCRA). This field along with Threshold Event
Counter Exponent (TECE) is used to get threshould counter value.
In Power10, this is a 8bit field, so patch fixes the
current code to modify the MMCRA[TECM] extraction macro to
handle this change. ISA v3.1 says this is a 7 bit field but
POWER10 it's actually 8 bits which will hopefully be fixed
in ISA v3.1 update.
Fixes: 170a315f41c6 ("powerpc/perf: Support to export MMCRA[TEC*] field to userspace")
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1608022578-1532-1-git-send-email-atrajeev@linux.vnet.ibm.com
|
|
Commit 7bfe54b5f165 ("powerpc/mm: Refactor the floor/ceiling check in
hugetlb range freeing functions") inadvertely removed the mask
applied to start parameter in those two functions, leading to the
following crash on power9.
LTP: starting hugemmap05_1 (hugemmap05 -m)
------------[ cut here ]------------
kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:387!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 NUMA PowerNV
...
CPU: 99 PID: 308 Comm: ksoftirqd/99 Tainted: G O 5.10.0-rc7-next-20201211 #1
NIP: c00000000005dbec LR: c0000000003352f4 CTR: 0000000000000000
REGS: c00020000bb6f830 TRAP: 0700 Tainted: G O (5.10.0-rc7-next-20201211)
MSR: 900000000282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002284 XER: 20040000
GPR00: c0000000003352f4 c00020000bb6fad0 c000000007f70b00 c0002000385b3ff0
GPR04: 0000000000000000 0000000000000003 c00020000bb6f8b4 0000000000000001
GPR08: 0000000000000001 0000000000000009 0000000000000008 0000000000000002
GPR12: 0000000024002488 c000201fff649c00 c000000007f2a20c 0000000000000000
GPR16: 0000000000000007 0000000000000000 c000000000194d10 c000000000194d10
GPR24: 0000000000000014 0000000000000015 c000201cc6e72398 c000000007fac4b4
GPR28: c000000007f2bf80 c000000007fac2f8 0000000000000008 c000200033870000
NIP [c00000000005dbec] __tlb_remove_table+0x1dc/0x1e0
pgtable_free at arch/powerpc/mm/book3s64/pgtable.c:387
(inlined by) __tlb_remove_table at arch/powerpc/mm/book3s64/pgtable.c:405
LR [c0000000003352f4] tlb_remove_table_rcu+0x54/0xa0
Call Trace:
__tlb_remove_table+0x13c/0x1e0 (unreliable)
tlb_remove_table_rcu+0x54/0xa0
__tlb_remove_table_free at mm/mmu_gather.c:101
(inlined by) tlb_remove_table_rcu at mm/mmu_gather.c:156
rcu_core+0x35c/0xbb0
rcu_do_batch at kernel/rcu/tree.c:2502
(inlined by) rcu_core at kernel/rcu/tree.c:2737
__do_softirq+0x480/0x704
run_ksoftirqd+0x74/0xd0
run_ksoftirqd at kernel/softirq.c:651
(inlined by) run_ksoftirqd at kernel/softirq.c:642
smpboot_thread_fn+0x278/0x320
kthread+0x1c4/0x1d0
ret_from_kernel_thread+0x5c/0x80
Properly apply the masks before calling pmd_free_tlb() and
pud_free_tlb() respectively.
Fixes: 7bfe54b5f165 ("powerpc/mm: Refactor the floor/ceiling check in hugetlb range freeing functions")
Reported-by: Qian Cai <qcai@redhat.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/56feccd7b6fcd98e353361a233fa7bb8e67c3164.1607780469.git.christophe.leroy@csgroup.eu
|
|
According to ISAv3.1 and ISAv3.0b, the msgsndp is described to split
RB in:
msgtype <- (RB) 32:36
payload <- (RB) 37:63
t <- (RB) 57:63
The current way of getting 'msgtype', and 't' is missing their MSB:
msgtype: ((arg >> 27) & 0xf) : Gets (RB) 33:36, missing bit 32
t: (arg &= 0x3f) : Gets (RB) 58:63, missing bit 57
Fixes this by applying the correct mask.
Signed-off-by: Leonardo Bras <leobras.c@gmail.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201208215707.31149-1-leobras.c@gmail.com
|
|
Fix the following coccicheck warning:
./arch/powerpc/kvm/booke.c:503:6-16: WARNING: Comparison to bool
./arch/powerpc/kvm/booke.c:505:6-17: WARNING: Comparison to bool
./arch/powerpc/kvm/booke.c:507:6-16: WARNING: Comparison to bool
Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1604764178-8087-1-git-send-email-kaixuxia@tencent.com
|
