* Re: [PATCH v2 0/7] arch/mm/fault: accelerate pagefault when badaccess
From: Andrew Morton @ 2024-04-03 20:45 UTC (permalink / raw)
To: Kefeng Wang
Cc: Russell King, Catalin Marinas, Will Deacon, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexander Gordeev, Gerald Schaefer, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, x86, linux-arm-kernel,
linuxppc-dev, linux-riscv, linux-s390, surenb, linux-mm
In-Reply-To: <20240403083805.1818160-1-wangkefeng.wang@huawei.com>
On Wed, 3 Apr 2024 16:37:58 +0800 Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> After VMA lock-based page fault handling enabled, if bad access met
> under per-vma lock, it will fallback to mmap_lock-based handling,
> so it leads to unnessary mmap lock and vma find again. A test from
> lmbench shows 34% improve after this changes on arm64,
>
> lat_sig -P 1 prot lat_sig 0.29194 -> 0.19198
>
> Only build test on other archs except arm64.
Thanks. So we now want a bunch of architectures to runtime test this. Do
we have a selftest in place which will adequately do this?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 31/34] spi: remove incorrect of_match_ptr annotations
From: Uwe Kleine-König @ 2024-04-03 21:05 UTC (permalink / raw)
To: Mark Brown
Cc: Arnd Bergmann, linux-kernel, Neil Armstrong, Kevin Hilman,
Heiko Stuebner, Andi Shyti, Krzysztof Kozlowski, Arnd Bergmann,
Jerome Brunet, Martin Blumenstingl, Alim Akhtar, Li Zetao,
Jonathan Cameron, Rob Herring, Yang Yingliang, Andy Shevchenko,
Luis de Arquer, Tudor Ambarus, Sam Protsenko, Peter Griffin,
Jaewon Kim, linux-spi, linux-arm-kernel, linux-amlogic,
linux-rockchip, linux-samsung-soc
In-Reply-To: <b4418ac1-10ba-4932-be6e-93282707024f@sirena.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1241 bytes --]
On Wed, Apr 03, 2024 at 10:56:58AM +0100, Mark Brown wrote:
> On Wed, Apr 03, 2024 at 10:06:49AM +0200, Arnd Bergmann wrote:
>
> > These appear to all be copied from the same original driver, so fix them at the
> > same time by removing the unnecessary of_match_ptr() annotation. As far as I
> > can tell, all these drivers are only actually used on configurations that
> > have CONFIG_OF enabled.
>
> Why are we not fixing of_match_ptr() here, or at least adding the ifdefs
> in case someone does end up wanting to run without OF?
Fixing of_match_ptr =
diff --git a/include/linux/of.h b/include/linux/of.h
index a0bedd038a05..d980bccffda0 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -890,7 +890,7 @@ static inline const void *of_device_get_match_data(const struct device *dev)
return NULL;
}
-#define of_match_ptr(_ptr) NULL
+#define of_match_ptr(_ptr) (0 ? (_ptr) : NULL)
#define of_match_node(_matches, _node) NULL
#endif /* CONFIG_OF */
?
Assuming this helps, I agree this would be the better fix.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 31/34] spi: remove incorrect of_match_ptr annotations
From: Andy Shevchenko @ 2024-04-03 21:13 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mark Brown, Arnd Bergmann, linux-kernel, Neil Armstrong,
Kevin Hilman, Heiko Stuebner, Andi Shyti, Krzysztof Kozlowski,
Arnd Bergmann, Jerome Brunet, Martin Blumenstingl, Alim Akhtar,
Li Zetao, Jonathan Cameron, Rob Herring, Yang Yingliang,
Andy Shevchenko, Luis de Arquer, Tudor Ambarus, Sam Protsenko,
Peter Griffin, Jaewon Kim, linux-spi, linux-arm-kernel,
linux-amlogic, linux-rockchip, linux-samsung-soc
In-Reply-To: <5f3qvhasho4mfnf6f7i6djak3ankje375mt4fzvv3gqrlj242o@zdk2ajvha6hx>
Wed, Apr 03, 2024 at 11:05:51PM +0200, Uwe Kleine-König kirjoitti:
> On Wed, Apr 03, 2024 at 10:56:58AM +0100, Mark Brown wrote:
> > On Wed, Apr 03, 2024 at 10:06:49AM +0200, Arnd Bergmann wrote:
> >
> > > These appear to all be copied from the same original driver, so fix them at the
> > > same time by removing the unnecessary of_match_ptr() annotation. As far as I
> > > can tell, all these drivers are only actually used on configurations that
> > > have CONFIG_OF enabled.
> >
> > Why are we not fixing of_match_ptr() here, or at least adding the ifdefs
> > in case someone does end up wanting to run without OF?
>
> Fixing of_match_ptr =
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index a0bedd038a05..d980bccffda0 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -890,7 +890,7 @@ static inline const void *of_device_get_match_data(const struct device *dev)
> return NULL;
> }
>
> -#define of_match_ptr(_ptr) NULL
> +#define of_match_ptr(_ptr) (0 ? (_ptr) : NULL)
FWIW, we have PTR_IF() (with a side note to split it from kernel.h in a
separate header or less twisted one).
> #define of_match_node(_matches, _node) NULL
> #endif /* CONFIG_OF */
>
> ?
>
> Assuming this helps, I agree this would be the better fix.
Why? I mean why do we need to even have this API? It's always
good to know which devices are supported by the module even
if you have no need in such support or it's not compiled in.
One of the reasons why is to be able to google for compatible hardware,
for example.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Deborah Brouwer @ 2024-04-03 21:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Shreeya Patel, mchehab, hverkuil, hverkuil-cisco, heiko, robh,
krzysztof.kozlowski+dt, conor+dt, mturquette, sboyd, p.zabel,
shawn.wen, kernel, linux-kernel, linux-media, devicetree,
linux-arm-kernel, linux-rockchip, linux-clk, linux-arm
In-Reply-To: <86150c89-11d5-4d52-987e-974b1a03018f@linaro.org>
On Wed, Apr 03, 2024 at 01:24:05PM +0200, Krzysztof Kozlowski wrote:
> On 03/04/2024 13:20, Shreeya Patel wrote:
> > On Wednesday, April 03, 2024 15:51 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> >
> >> On 03/04/2024 11:24, Shreeya Patel wrote:
> >>> On Thursday, March 28, 2024 04:20 IST, Shreeya Patel <shreeya.patel@collabora.com> wrote:
> >>>
> >>>> This series implements support for the Synopsys DesignWare
> >>>> HDMI RX Controller, being compliant with standard HDMI 1.4b
> >>>> and HDMI 2.0.
> >>>>
> >>>
> >>> Hi Mauro and Hans,
> >>>
> >>> I haven't received any reviews so far. Hence, this is just a gentle reminder to review this patch series.
> >>
> >> Why did you put clk changes here? These go via different subsystem. That
> >> might be one of obstacles for your patchset.
> >>
> >
> > I added clock changes in this patch series because HDMIRX driver depends on it.
> > I thought it is wrong to send the driver patches which don't even compile?
>
> Hm, why HDMIRX driver depends on clock? How? This sounds really wrong.
> Please get it reviewed internally first.
>
> >
> > Since you are a more experienced developer, can you help me understand what would
> > be the right way to send patches in such scenarios?
>
> I am not the substitute for your Collabora engineers and peers. You do
> not get free work from the community. First, do the work and review
> internally, to solve all trivial things, like how to submit patches
> upstream or how to make your driver buildable, and then ask community
> for the review.
I don't think Shreeya was asking for "free" work from the community.
Her question wasn't trivial or obvious since reasonable people seem to sometimes
disagree about where to send a patch especially if it's needed to make a series compile.
I heard the issue was already resolved but had to say something since this accusation
seemed so unfair.
>
> Best regards,
> Krzysztof
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 00/15] Add support for suppressing warning backtraces
From: Kees Cook @ 2024-04-03 21:20 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kselftest, David Airlie, Arnd Bergmann, Maíra Canal,
Dan Carpenter, Daniel Diaz, David Gow, Arthur Grillo,
Brendan Higgins, Naresh Kamboju, Maarten Lankhorst, Andrew Morton,
Maxime Ripard, Ville Syrjälä, Daniel Vetter,
Thomas Zimmermann, dri-devel, kunit-dev, linux-arch,
linux-arm-kernel, linux-doc, linux-kernel, linux-parisc,
linuxppc-dev, linux-riscv, linux-s390, linux-sh, loongarch,
netdev, x86
In-Reply-To: <20240403131936.787234-1-linux@roeck-us.net>
On Wed, Apr 03, 2024 at 06:19:21AM -0700, Guenter Roeck wrote:
> Some unit tests intentionally trigger warning backtraces by passing bad
> parameters to kernel API functions. Such unit tests typically check the
> return value from such calls, not the existence of the warning backtrace.
>
> Such intentionally generated warning backtraces are neither desirable
> nor useful for a number of reasons.
> - They can result in overlooked real problems.
> - A warning that suddenly starts to show up in unit tests needs to be
> investigated and has to be marked to be ignored, for example by
> adjusting filter scripts. Such filters are ad-hoc because there is
> no real standard format for warnings. On top of that, such filter
> scripts would require constant maintenance.
>
> One option to address problem would be to add messages such as "expected
> warning backtraces start / end here" to the kernel log. However, that
> would again require filter scripts, it might result in missing real
> problematic warning backtraces triggered while the test is running, and
> the irrelevant backtrace(s) would still clog the kernel log.
>
> Solve the problem by providing a means to identify and suppress specific
> warning backtraces while executing test code. Support suppressing multiple
> backtraces while at the same time limiting changes to generic code to the
> absolute minimum. Architecture specific changes are kept at minimum by
> retaining function names only if both CONFIG_DEBUG_BUGVERBOSE and
> CONFIG_KUNIT are enabled.
>
> The first patch of the series introduces the necessary infrastructure.
> The second patch introduces support for counting suppressed backtraces.
> This capability is used in patch three to implement unit tests.
> Patch four documents the new API.
> The next two patches add support for suppressing backtraces in drm_rect
> and dev_addr_lists unit tests. These patches are intended to serve as
> examples for the use of the functionality introduced with this series.
> The remaining patches implement the necessary changes for all
> architectures with GENERIC_BUG support.
>
> With CONFIG_KUNIT enabled, image size increase with this series applied is
> approximately 1%. The image size increase (and with it the functionality
> introduced by this series) can be avoided by disabling
> CONFIG_KUNIT_SUPPRESS_BACKTRACE.
>
> This series is based on the RFC patch and subsequent discussion at
> https://patchwork.kernel.org/project/linux-kselftest/patch/02546e59-1afe-4b08-ba81-d94f3b691c9a@moroto.mountain/
> and offers a more comprehensive solution of the problem discussed there.
>
> Design note:
> Function pointers are only added to the __bug_table section if both
> CONFIG_KUNIT_SUPPRESS_BACKTRACE and CONFIG_DEBUG_BUGVERBOSE are enabled
> to avoid image size increases if CONFIG_KUNIT is disabled. There would be
> some benefits to adding those pointers all the time (reduced complexity,
> ability to display function names in BUG/WARNING messages). That change,
> if desired, can be made later.
>
> Checkpatch note:
> Remaining checkpatch errors and warnings were deliberately ignored.
> Some are triggered by matching coding style or by comments interpreted
> as code, others by assembler macros which are disliked by checkpatch.
> Suggestions for improvements are welcome.
>
> Changes since RFC:
> - Introduced CONFIG_KUNIT_SUPPRESS_BACKTRACE
> - Minor cleanups and bug fixes
> - Added support for all affected architectures
> - Added support for counting suppressed warnings
> - Added unit tests using those counters
> - Added patch to suppress warning backtraces in dev_addr_lists tests
>
> Changes since v1:
> - Rebased to v6.9-rc1
> - Added Tested-by:, Acked-by:, and Reviewed-by: tags
> [I retained those tags since there have been no functional changes]
> - Introduced KUNIT_SUPPRESS_BACKTRACE configuration option, enabled by
> default.
>
> Changes since v2:
> - Rebased to v6.9-rc2
> - Added comments to drm warning suppression explaining why it is needed.
> - Added patch to move conditional code in arch/sh/include/asm/bug.h
> to avoid kerneldoc warning
> - Added architecture maintainers to Cc: for architecture specific patches
> - No functional changes
>
> ----------------------------------------------------------------
> Guenter Roeck (15):
> bug/kunit: Core support for suppressing warning backtraces
> kunit: bug: Count suppressed warning backtraces
> kunit: Add test cases for backtrace warning suppression
> kunit: Add documentation for warning backtrace suppression API
> drm: Suppress intentional warning backtraces in scaling unit tests
> net: kunit: Suppress lock warning noise at end of dev_addr_lists tests
> x86: Add support for suppressing warning backtraces
> arm64: Add support for suppressing warning backtraces
> loongarch: Add support for suppressing warning backtraces
> parisc: Add support for suppressing warning backtraces
> s390: Add support for suppressing warning backtraces
> sh: Add support for suppressing warning backtraces
> sh: Move defines needed for suppressing warning backtraces
> riscv: Add support for suppressing warning backtraces
> powerpc: Add support for suppressing warning backtraces
Tested-by: Kees Cook <keescook@chromium.org>
(for x86 and um)
I was planning to add warning suppression for the "overflow" KUnit
tests, but it seems the vmalloc routines aren't calling warn_alloc() any
more for impossible sizes. So, I think, no patches needed for
lib/overflow_kunit.c, but at the end of the day, I've tested this series
is working for me. :P
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ath9k: use unmanaged PCI functions in ath9k_pci_owl_loader
From: Toke Høiland-Jørgensen @ 2024-04-03 21:23 UTC (permalink / raw)
To: Heiner Kallweit, Kalle Valo, Andreas Färber,
Manivannan Sadhasivam, Martin Blumenstingl
Cc: linux-wireless, linux-arm-kernel@lists.infradead.org,
linux-actions, linux-pci@vger.kernel.org
In-Reply-To: <cd66af0c-835e-4222-b362-e2e9cafdeb40@gmail.com>
Heiner Kallweit <hkallweit1@gmail.com> writes:
> Using the device-managed versions has no benefit here, because
> resources are released as part of the asynchronous fw loading.
>
> Actual reason why I got here is that I was looking for places with
> dubious use of pcim_pin_device().
Could you please expand the commit message to explain what this means in
a bit more detail? That will be helpful to someone who wants to
understand what the difference between these versions is and why this
change makes sense, but who is not that familiar with how these internal
bits are really supposed to work. Someone like myself, in other words :)
-Toke
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: Provide an AMU-based version of arch_freq_get_on_cpu
From: Beata Michalska @ 2024-04-03 21:28 UTC (permalink / raw)
To: Sumit Gupta
Cc: linux-arm-kernel, ionela.voinescu, sudeep.holla, will,
catalin.marinas, vincent.guittot, yang, lihuisong, vanshikonda,
linux-kernel@vger.kernel.org, linux-tegra
In-Reply-To: <370c98a5-30f7-917e-8fe8-10d2c48e4222@nvidia.com>
On Wed, Mar 20, 2024 at 10:13:18PM +0530, Sumit Gupta wrote:
>
>
> On 12/03/24 14:04, Beata Michalska wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > With the Frequency Invariance Engine (FIE) being already wired up with
> > sched tick and making use of relevant (core counter and constant
> > counter) AMU counters, getting the current frequency for a given CPU
> > on supported platforms can be achieved by utilizing the frequency scale
> > factor which reflects an average CPU frequency for the last tick period
> > length.
> >
> > The solution is partially based on APERF/MPERF implementation of
> > arch_freq_get_on_cpu.
> >
> > Suggested-by: Ionela Voinescu <ionela.voinescu@arm.com>
> > Signed-off-by: Beata Michalska <beata.michalska@arm.com>
> > ---
> > arch/arm64/kernel/topology.c | 103 +++++++++++++++++++++++++++++++----
> > 1 file changed, 92 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> > index 1a2c72f3e7f8..42cb19c31719 100644
> > --- a/arch/arm64/kernel/topology.c
> > +++ b/arch/arm64/kernel/topology.c
> > @@ -17,6 +17,8 @@
> > #include <linux/cpufreq.h>
> > #include <linux/init.h>
> > #include <linux/percpu.h>
> > +#include <linux/sched/isolation.h>
> > +#include <linux/seqlock_types.h>
> >
> > #include <asm/cpu.h>
> > #include <asm/cputype.h>
> > @@ -88,18 +90,31 @@ int __init parse_acpi_topology(void)
> > * initialized.
> > */
> > static DEFINE_PER_CPU_READ_MOSTLY(unsigned long, arch_max_freq_scale) = 1UL << (2 * SCHED_CAPACITY_SHIFT);
> > -static DEFINE_PER_CPU(u64, arch_const_cycles_prev);
> > -static DEFINE_PER_CPU(u64, arch_core_cycles_prev);
> > static cpumask_var_t amu_fie_cpus;
> >
> > +struct amu_cntr_sample {
> > + u64 arch_const_cycles_prev;
> > + u64 arch_core_cycles_prev;
> > + unsigned long last_update;
> > + seqcount_t seq;
> > +};
> > +
> > +static DEFINE_PER_CPU_SHARED_ALIGNED(struct amu_cntr_sample, cpu_amu_samples) = {
> > + .seq = SEQCNT_ZERO(cpu_amu_samples.seq)
> > +};
> > +
> > void update_freq_counters_refs(void)
> > {
> > - this_cpu_write(arch_core_cycles_prev, read_corecnt());
> > - this_cpu_write(arch_const_cycles_prev, read_constcnt());
> > + struct amu_cntr_sample *amu_sample = this_cpu_ptr(&cpu_amu_samples);
> > +
> > + amu_sample->arch_core_cycles_prev = read_corecnt();
> > + amu_sample->arch_const_cycles_prev = read_constcnt();
> > }
> >
> > static inline bool freq_counters_valid(int cpu)
> > {
> > + struct amu_cntr_sample *amu_sample = per_cpu_ptr(&cpu_amu_samples, cpu);
> > +
> > if ((cpu >= nr_cpu_ids) || !cpumask_test_cpu(cpu, cpu_present_mask))
> > return false;
> >
> > @@ -108,8 +123,8 @@ static inline bool freq_counters_valid(int cpu)
> > return false;
> > }
> >
> > - if (unlikely(!per_cpu(arch_const_cycles_prev, cpu) ||
> > - !per_cpu(arch_core_cycles_prev, cpu))) {
> > + if (unlikely(!amu_sample->arch_const_cycles_prev ||
> > + !amu_sample->arch_core_cycles_prev)) {
> > pr_debug("CPU%d: cycle counters are not enabled.\n", cpu);
> > return false;
> > }
> > @@ -152,20 +167,27 @@ void freq_inv_set_max_ratio(int cpu, u64 max_rate)
> >
> > static void amu_scale_freq_tick(void)
> > {
> > + struct amu_cntr_sample *amu_sample = this_cpu_ptr(&cpu_amu_samples);
> > u64 prev_core_cnt, prev_const_cnt;
> > u64 core_cnt, const_cnt, scale;
> >
> > - prev_const_cnt = this_cpu_read(arch_const_cycles_prev);
> > - prev_core_cnt = this_cpu_read(arch_core_cycles_prev);
> > + prev_const_cnt = amu_sample->arch_const_cycles_prev;
> > + prev_core_cnt = amu_sample->arch_core_cycles_prev;
> > +
> > + write_seqcount_begin(&amu_sample->seq);
> >
> > update_freq_counters_refs();
> >
> > - const_cnt = this_cpu_read(arch_const_cycles_prev);
> > - core_cnt = this_cpu_read(arch_core_cycles_prev);
> > + const_cnt = amu_sample->arch_const_cycles_prev;
> > + core_cnt = amu_sample->arch_core_cycles_prev;
> >
> > + /*
> > + * This should not happen unless the AMUs have been reset and the
> > + * counter values have not been resroted - unlikely
> > + */
> > if (unlikely(core_cnt <= prev_core_cnt ||
> > const_cnt <= prev_const_cnt))
> > - return;
> > + goto leave;
> >
> > /*
> > * /\core arch_max_freq_scale
> > @@ -182,6 +204,10 @@ static void amu_scale_freq_tick(void)
> >
> > scale = min_t(unsigned long, scale, SCHED_CAPACITY_SCALE);
> > this_cpu_write(arch_freq_scale, (unsigned long)scale);
> > +
> > + amu_sample->last_update = jiffies;
> > +leave:
> > + write_seqcount_end(&amu_sample->seq);
> > }
> >
> > static struct scale_freq_data amu_sfd = {
> > @@ -189,6 +215,61 @@ static struct scale_freq_data amu_sfd = {
> > .set_freq_scale = amu_scale_freq_tick,
> > };
> >
> > +#define AMU_SAMPLE_EXP_MS 20
> > +
> > +unsigned int arch_freq_get_on_cpu(int cpu)
> > +{
> > + struct amu_cntr_sample *amu_sample;
> > + unsigned long last_update;
> > + unsigned int seq;
> > + unsigned int freq;
> > + u64 scale;
> > +
> > + if (!cpumask_test_cpu(cpu, amu_fie_cpus) || !arch_scale_freq_ref(cpu))
> > + return 0;
> > +
> > +retry:
> > + amu_sample = per_cpu_ptr(&cpu_amu_samples, cpu);
> > +
> > + do {
> > + seq = raw_read_seqcount_begin(&amu_sample->seq);
> > + last_update = amu_sample->last_update;
> > + } while (read_seqcount_retry(&amu_sample->seq, seq));
> > +
> > + /*
> > + * For those CPUs that are in full dynticks mode,
> > + * and those that have not seen tick for a while
> > + * try an alternative source for the counters (and thus freq scale),
> > + * if available for given policy
> > + */
> > + if (time_is_before_jiffies(last_update + msecs_to_jiffies(AMU_SAMPLE_EXP_MS))) {
> > + struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
> > + int ref_cpu = nr_cpu_ids;
> > +
> > + if (cpumask_intersects(housekeeping_cpumask(HK_TYPE_TICK),
> > + policy->cpus))
> > + ref_cpu = cpumask_nth_and(cpu, policy->cpus,
> > + housekeeping_cpumask(HK_TYPE_TICK));
> > +
>
> This is looking for any other HK CPU within same policy for counters.
> AFAIU, cpumask_nth_and() will return small_cpumask_bits/nr_cpu_ids
> if the number of bits in both masks is different. Could you check
> again if the current change is fine or needs something like below.
> BTW, we have one CPU per policy.
>
> cpumask_and(&mask, policy->cpus, housekeeping_cpumask(HK_TYPE_TICK));
> retry:
> ....
> cpumask_andnot(&mask, &mask, cpumask_of(cpu));
> ref_cpu = cpumask_any(&mask);
>
At this point this is indeed bogus though for a different reason.
I've rewritten that part a bit, though still, this will bail out for single-cpu
policies.
---
BR
Beata
> Thank you,
> Sumit Gupta
>
> > + cpufreq_cpu_put(policy);
> > + if (ref_cpu >= nr_cpu_ids || ref_cpu == cpu)
> > + /* No alternative to pull info from */
> > + return 0;
> > + cpu = ref_cpu;
> > + goto retry;
> > + }
> > + /*
> > + * Reversed computation to the one used to determine
> > + * the arch_freq_scale value
> > + * (see amu_scale_freq_tick for details)
> > + */
> > + scale = arch_scale_freq_capacity(cpu);
> > + freq = scale * arch_scale_freq_ref(cpu);
> > + freq >>= SCHED_CAPACITY_SHIFT;
> > +
> > + return freq;
> > +}
> > +
> > static void amu_fie_setup(const struct cpumask *cpus)
> > {
> > int cpu;
> > --
> > 2.25.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/3] Add support for AArch64 AMUv1-based arch_freq_get_on_cpu
From: Beata Michalska @ 2024-04-03 21:30 UTC (permalink / raw)
To: Sumit Gupta
Cc: Ionela Voinescu, linux-kernel, linux-arm-kernel, vanshikonda,
sudeep.holla, will, catalin.marinas, vincent.guittot, yang,
lihuisong, linux-tegra
In-Reply-To: <21a78951-2d4a-1d6e-0cd8-6a4a75ccb142@nvidia.com>
On Wed, Mar 20, 2024 at 10:22:22PM +0530, Sumit Gupta wrote:
> Hi Beata,
>
> > > On Tuesday 12 Mar 2024 at 08:34:28 (+0000), Beata Michalska wrote:
> > > > Introducing arm64 specific version of arch_freq_get_on_cpu, cashing on
> > > > existing implementation for FIE and AMUv1 support: the frequency scale
> > > > factor, updated on each sched tick, serves as a base for retrieving
> > > > the frequency for a given CPU, representing an average frequency
> > > > reported between the ticks - thus its accuracy is limited.
> > > >
> > > > The changes have been rather lightly (due to some limitations) tested on
> > > > an FVP model.
> > > >
> > > > Relevant discussions:
> > > > [1] https://lore.kernel.org/all/20240229162520.970986-1-vanshikonda@os.amperecomputing.com/
> > > > [2] https://lore.kernel.org/all/7eozim2xnepacnnkzxlbx34hib4otycnbn4dqymfziqou5lw5u@5xzpv3t7sxo3/
> > > > [3] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
> > > > [4] https://lore.kernel.org/lkml/ZIHpd6unkOtYVEqP@e120325.cambridge.arm.com/T/#m4e74cb5a0aaa353c60fedc6cfb95ab7a6e381e3c
> > > >
> > > > v3:
> > > > - dropping changes to cpufreq_verify_current_freq
> > > > - pulling in changes from Ionela initializing capacity_freq_ref to 0
> > > > (thanks for that!) and applying suggestions made by her during last review:
> > > > - switching to arch_scale_freq_capacity and arch_scale_freq_ref when
> > > > reversing freq scale factor computation
> > > > - swapping shift with multiplication
> > > > - adding time limit for considering last scale update as valid
> > > > - updating frequency scale factor upon entering idle
> > > >
> > > > v2:
> > > > - Splitting the patches
> > > > - Adding comment for full dyntick mode
> > > > - Plugging arch_freq_get_on_cpu into cpufreq_verify_current_freq instead
> > > > of in show_cpuinfo_cur_freq to allow the framework to stay more in sync
> > > > with potential freq changes
> > > >
> > > > Beata Michalska (2):
> > > > arm64: Provide an AMU-based version of arch_freq_get_on_cpu
> > > > arm64: Update AMU-based frequency scale factor on entering idle
> > > >
> > > > Ionela Voinescu (1):
> > > > arch_topology: init capacity_freq_ref to 0
> > > >
> > >
> > > Should there have been a patch that adds a call to
> > > arch_freq_get_on_cpu() from show_cpuinfo_cur_freq() as well?
> > >
> > > My understanding from this [1] thread and others referenced there is
> > > that was something we wanted.
> > >
> > Right, so I must have missunderstood that, as the way I did read it was that
> > it is acceptable to keep things as they are wrt cpufreq sysfs entries.
> >
> > ---
> > BR
> > Beata
> > > [1] https://lore.kernel.org/lkml/2cfbc633-1e94-d741-2337-e1b0cf48b81b@nvidia.com/
> > >
> > > Thanks,
> > > Ionela.
> > >
>
> Yes, the change to show_cpuinfo_cur_freq from [1] is needed.
>
Noted. Will send an update including fixes and this requested change.
---
BR
Beata
> [1]
> https://lore.kernel.org/lkml/20230606155754.245998-1-beata.michalska@arm.com/
>
> Thank you,
> Sumit Gupta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/3] Add support for AArch64 AMUv1-based arch_freq_get_on_cpu
From: Beata Michalska @ 2024-04-03 21:34 UTC (permalink / raw)
To: Vanshidhar Konda
Cc: linux-kernel, linux-arm-kernel, ionela.voinescu, sudeep.holla,
will, catalin.marinas, vincent.guittot, sumitg, yang, lihuisong
In-Reply-To: <5bdlm4kzni6x2bdy7kmmomf7cmyohjhr4nr7v2mb2pchuhkulj@moakmpptnbg5>
On Mon, Mar 25, 2024 at 09:10:26AM -0700, Vanshidhar Konda wrote:
> On Tue, Mar 12, 2024 at 08:34:28AM +0000, Beata Michalska wrote:
> > Introducing arm64 specific version of arch_freq_get_on_cpu, cashing on
> > existing implementation for FIE and AMUv1 support: the frequency scale
> > factor, updated on each sched tick, serves as a base for retrieving
> > the frequency for a given CPU, representing an average frequency
> > reported between the ticks - thus its accuracy is limited.
> >
> > The changes have been rather lightly (due to some limitations) tested on
> > an FVP model.
> >
>
> I tested these changes on an Ampere system. The results from reading
> scaling_cur_freq look reasonable in the majority of cases I tested. I
> only saw some unexpected behavior with cores that were configured for
> no_hz full.
>
> I observed the unexplained behavior when I tested as follows:
> 1. Run stress on all cores
> stress-ng --cpu 186 --timeout 10m --metrics-brief
> 2. Observe scaling_cur_freq and cpuinfo_cur_freq for all cores
> scaling_cur_freq values were within a few % of cpuinfo_cur_freq
> 3. Kill stress test
> 4. Observe scaling_cur_freq and cpuinfo_cur_freq for all cores
> scaling_cur_freq values were within a few % of cpuinfo_cur_freq for
> most cores except the ones configured with no_hz full.
>
> no_hz full = 122-127
> core scaling_cur_freq cpuinfo_cur_freq
> [122]: 2997070 1000000
> [123]: 2997070 1000000
> [124]: 3000038 1000000
> [125]: 2997070 1000000
> [126]: 2997070 1000000
> [127]: 2997070 1000000
>
> These values were reflected for multiple seconds. I suspect the cores
> entered WFI and there was no update to the scale while those cores were
> idle.
>
Right, so the problem is with updating the counters upon entering idle, which at
this point is being done for all CPUs, and it should exclude the full dynticks
ones - otherwise it leads to such bad readings. So for nohz_full cores cpufreq
driver will have to take care of getting the current frequency.
Will be sending a fix for that.
Thank you very much for testing - appreciate that!
---
BR
Beata
> Thanks,
> Vanshi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v9 0/4] PCI: brcmstb: Configure appropriate HW CLKREQ# mode
From: Jim Quinlan @ 2024-04-03 21:38 UTC (permalink / raw)
To: linux-pci, Nicolas Saenz Julienne, Bjorn Helgaas,
Lorenzo Pieralisi, Cyril Brulebois, Phil Elwell,
bcm-kernel-feedback-list, james.quinlan
Cc: Conor Dooley,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Jim Quinlan, Krzysztof Kozlowski,
Krzysztof Wilczyński,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Lorenzo Pieralisi, Rob Herring
[-- Attachment #1.1: Type: text/plain, Size: 5702 bytes --]
v9 -- v8 was setting an internal bus timeout to accomodate large L1 exit
latencies. After meeting the PCIe HW team it was revealed that the
HW default timeout value was set low for the purposes of HW debugging
convenience; for nominal operation it needs to be set to a higher
value independent of this submission's purpose. This is now a
separate commit.
-- With v8, Bjorne asked what was preventing a device from exceeding the
time required for the above internal bus timeout. The answer to this
is for us to set the endpoints' max latency {no-,}snoop value to
something below this internal timeout value. If the endpoint
respects this value as it should, it will not send an LTR request
with a larger latency value and not put itself in a situation
that requires more latency than is possible for the platform.
Typically, ACPI or FW sets these max latency values. In most of our
systems we do not have this happening so it is up to the RC driver to
set these values in the endpoint devices. If the endpoints already
have non-zero values that are lower than what we are setting, we let
them be, as it is possible ACPI or FW set them and knows something
that we do not.
-- The "clkreq" commit has only been changed to remove the code that was
setting the timeout value, as this code is now its own commit.
v8 -- Un-advertise L1SS capability when in "no-l1ss" mode (Bjorn)
-- Squashed last two commits of v7 (Bjorn)
-- Fix DT binding description text wrapping (Bjorn)
-- Fix incorrect Spec reference (Bjorn)
s/PCIe Spec/PCIe Express Mini CEM 2.1 specification/
-- Text substitutions (Bjorn)
s/WRT/With respect to/
s/Tclron/T_CLRon/
v7 -- Manivannan Sadhasivam suggested (a) making the property look like a
network phy-mode and (b) keeping the code simple (not counting clkreq
signal appearances, un-advertising capabilites, etc). This is
what I have done. The property is now "brcm,clkreq-mode" and
the values may be one of "safe", "default", and "no-l1ss". The
default setting is to employ the most capable power savings mode.
v6 -- No code has been changed.
-- Changed commit subject and comment in "#PERST" commit (Bjorn, Cyril)
-- Changed sign-off and author email address for all commits.
This was due to a change in Broadcom's upstreaming policy.
v5 -- Remove DT property "brcm,completion-timeout-us" from
"DT bindings" commit. Although this error may be reported
as a completion timeout, its cause was traced to an
internal bus timeout which may occur even when there is
no PCIe access being processed. We set a timeout of four
seconds only if we are operating in "L1SS CLKREQ#" mode.
-- Correct CEM 2.0 reference provided by HW engineer,
s/3.2.5.2.5/3.2.5.2.2/ (Bjorn)
-- Add newline to dev_info() string (Stefan)
-- Change variable rval to unsigned (Stefan)
-- s/implementaion/implementation/ (Bjorn)
-- s/superpowersave/powersupersave/ (Bjorn)
-- Slightly modify message on "PERST#" commit.
-- Rebase to torvalds master
v4 -- New commit that asserts PERST# for 2711/RPi SOCs at PCIe RC
driver probe() time. This is done in Raspian Linux and its
absence may be the cause of a failing test case.
-- New commit that removes stale comment.
v3 -- Rewrote commit msgs and comments refering panics if L1SS
is enabled/disabled; the code snippet that unadvertises L1SS
eliminates the panic scenario. (Bjorn)
-- Add reference for "400ns of CLKREQ# assertion" blurb (Bjorn)
-- Put binding names in DT commit Subject (Bjorn)
-- Add a verb to a commit's subject line (Bjorn)
-- s/accomodat(\w+)/accommodat$1/g (Bjorn)
-- Rewrote commit msgs and comments refering panics if L1SS
is enabled/disabled; the code snippet that unadvertises L1SS
eliminates the panic scenario. (Bjorn)
v2 -- Changed binding property 'brcm,completion-timeout-msec' to
'brcm,completion-timeout-us'. (StefanW for standard suffix).
-- Warn when clamping timeout value, and include clamped
region in message. Also add min and max in YAML. (StefanW)
-- Qualify description of "brcm,completion-timeout-us" so that
it refers to PCIe transactions. (StefanW)
-- Remvove mention of Linux specifics in binding description. (StefanW)
-- s/clkreq#/CLKREQ#/g (Bjorn)
-- Refactor completion-timeout-us code to compare max and min to
value given by the property (as opposed to the computed value).
v1 -- The current driver assumes the downstream devices can
provide CLKREQ# for ASPM. These commits accomodate devices
w/ or w/o clkreq# and also handle L1SS-capable devices.
-- The Raspian Linux folks have already been using a PCIe RC
property "brcm,enable-l1ss". These commits use the same
property, in a backward-compatible manner, and the implementaion
adds more detail and also automatically identifies devices w/o
a clkreq# signal, i.e. most devices plugged into an RPi CM4
IO board.
Jim Quinlan (4):
dt-bindings: PCI: brcmstb: Add property "brcm,clkreq-mode"
PCI: brcmstb: Set reasonable value for internal bus timeout
PCI: brcmstb: Set downstream maximum {no-}snoop LTR values
PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream
device
.../bindings/pci/brcm,stb-pcie.yaml | 18 ++
drivers/pci/controller/pcie-brcmstb.c | 161 +++++++++++++++++-
2 files changed, 170 insertions(+), 9 deletions(-)
base-commit: 9f8413c4a66f2fb776d3dc3c9ed20bf435eb305e
--
2.17.1
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4210 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v9 1/4] dt-bindings: PCI: brcmstb: Add property "brcm,clkreq-mode"
From: Jim Quinlan @ 2024-04-03 21:38 UTC (permalink / raw)
To: linux-pci, Nicolas Saenz Julienne, Bjorn Helgaas,
Lorenzo Pieralisi, Cyril Brulebois, Phil Elwell,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Florian Fainelli, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20240403213902.26391-1-james.quinlan@broadcom.com>
[-- Attachment #1.1: Type: text/plain, Size: 2171 bytes --]
The Broadcom STB/CM PCIe HW -- a core that is also used by RPi SOCs --
requires the driver to deliberately place the RC HW one of three CLKREQ#
modes. The "brcm,clkreq-mode" property allows the user to override the
default setting. If this property is omitted, the default mode shall be
"default".
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/pci/brcm,stb-pcie.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index 7e15aae7d69e..22491f7f8852 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -64,6 +64,24 @@ properties:
aspm-no-l0s: true
+ brcm,clkreq-mode:
+ description: A string that determines the operating
+ clkreq mode of the PCIe RC HW with respect to controlling the refclk
+ signal. There are three different modes -- "safe", which drives the
+ refclk signal unconditionally and will work for all devices but does
+ not provide any power savings; "no-l1ss" -- which provides Clock
+ Power Management, L0s, and L1, but cannot provide L1 substate (L1SS)
+ power savings. If the downstream device connected to the RC is L1SS
+ capable AND the OS enables L1SS, all PCIe traffic may abruptly halt,
+ potentially hanging the system; "default" -- which provides L0s, L1,
+ and L1SS, but not compliant to provide Clock Power Management;
+ specifically, may not be able to meet the T_CLRon max timing of 400ns
+ as specified in "Dynamic Clock Control", section 3.2.5.2.2 PCI
+ Express Mini CEM 2.1 specification. This situation is atypical and
+ should happen only with older devices.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ safe, no-l1ss, default ]
+
brcm,scb-sizes:
description: u64 giving the 64bit PCIe memory
viewport size of a memory controller. There may be up to
--
2.17.1
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4210 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 2/4] PCI: brcmstb: Set reasonable value for internal bus timeout
From: Jim Quinlan @ 2024-04-03 21:38 UTC (permalink / raw)
To: linux-pci, Nicolas Saenz Julienne, Bjorn Helgaas,
Lorenzo Pieralisi, Cyril Brulebois, Phil Elwell,
bcm-kernel-feedback-list, james.quinlan
Cc: Florian Fainelli, Jim Quinlan, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
In-Reply-To: <20240403213902.26391-1-james.quinlan@broadcom.com>
[-- Attachment #1.1: Type: text/plain, Size: 1564 bytes --]
HW initializes an internal bus timeout register to a small value for
debugging convenience. Set this to something reasonable, i.e. in the
vicinity of 10 msec.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index f9dd6622fe10..e3480ca4cd57 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -664,6 +664,21 @@ static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
return 0;
}
+/*
+ * An internal HW bus timer value is set to a small value for debugging
+ * convenience. Set this to something reasonable, i.e. somewhere around
+ * 10ms.
+ */
+static void brcm_extend_internal_bus_timeout(struct brcm_pcie *pcie, u32 nsec)
+{
+ /* TIMEOUT register is two registers before RGR1_SW_INIT_1 */
+ const unsigned int REG_OFFSET = PCIE_RGR1_SW_INIT_1(pcie) - 8;
+ u32 timeout_us = nsec / 1000;
+
+ /* Each unit in timeout register is 1/216,000,000 seconds */
+ writel(216 * timeout_us, pcie->base + REG_OFFSET);
+}
+
/* The controller is capable of serving in both RC and EP roles */
static bool brcm_pcie_rc_mode(struct brcm_pcie *pcie)
{
@@ -1059,6 +1074,9 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
return -ENODEV;
}
+ /* Extend internal bus timeout to 8ms or so */
+ brcm_extend_internal_bus_timeout(pcie, SZ_8M);
+
if (pcie->gen)
brcm_pcie_set_gen(pcie, pcie->gen);
--
2.17.1
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4210 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 3/4] PCI: brcmstb: Set downstream maximum {no-}snoop LTR values
From: Jim Quinlan @ 2024-04-03 21:39 UTC (permalink / raw)
To: linux-pci, Nicolas Saenz Julienne, Bjorn Helgaas,
Lorenzo Pieralisi, Cyril Brulebois, Phil Elwell,
bcm-kernel-feedback-list, james.quinlan
Cc: Florian Fainelli, Jim Quinlan, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
In-Reply-To: <20240403213902.26391-1-james.quinlan@broadcom.com>
[-- Attachment #1.1: Type: text/plain, Size: 3929 bytes --]
Most of our systems do not have FW or ACPI, so it is up to the RC driver to
set the maximum LTR {no-}snoop latency values of downstream devices. We
set them to a value that is slightly smaller than the value of our internal
bus timeout register.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 68 ++++++++++++++++++++++++++-
1 file changed, 66 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index e3480ca4cd57..3d08b92d5bb8 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -182,6 +182,20 @@
#define DATA_ADDR(pcie) (pcie->reg_offsets[EXT_CFG_DATA])
#define PCIE_RGR1_SW_INIT_1(pcie) (pcie->reg_offsets[RGR1_SW_INIT_1])
+/*
+ * What we call "LTR_FMT" is the 16 bit latency field format:
+ * [15:15] Requirement bit
+ * [12:10] Latency scale
+ * [09:00] Latency value
+ */
+#define LTR_FMT_TO_NS(p) (FIELD_GET(GENMASK(15, 15), (p)) \
+ * ((unsigned long long)FIELD_GET(GENMASK(9, 0), (p)) \
+ << (FIELD_GET(GENMASK(12, 10), (p)) * 5)))
+#define BRCM_LTR_MAX_SCALE 4 /* Scale==4 => Each unit is 1,048,576ns */
+#define BRCM_LTR_MAX_VALUE 9 /* Using the above scale, roughly 9.4 ms */
+#define BRCM_LTR_MAX_NS ((unsigned long long)(BRCM_LTR_MAX_VALUE \
+ << (5 * BRCM_LTR_MAX_SCALE)))
+
/* Rescal registers */
#define PCIE_DVT_PMU_PCIE_PHY_CTRL 0xc700
#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS 0x3
@@ -679,6 +693,49 @@ static void brcm_extend_internal_bus_timeout(struct brcm_pcie *pcie, u32 nsec)
writel(216 * timeout_us, pcie->base + REG_OFFSET);
}
+/* Sets downstream device latency tolerance registers to max we can handle */
+static int brcm_set_dev_ltr_max(struct pci_dev *dev, void *data)
+{
+ u16 ltr_cap_offset = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_LTR);
+ u16 ltr_fmt_cur, ltr_fmt = *(u16 *)data;
+ unsigned long long cur_nsec;
+ static const u16 reg_offsets[2] = {
+ PCI_LTR_MAX_SNOOP_LAT,
+ PCI_LTR_MAX_NOSNOOP_LAT,
+ };
+ unsigned int i;
+
+ if (!ltr_cap_offset || !dev->ltr_path)
+ return 0;
+
+ /*
+ * FW may have already written a value so we want to respect that
+ * value if it is lower than ltr_fmt. Update the current value if
+ * it is 0 or if the new value is less than the current.
+ */
+ for (i = 0; i < ARRAY_SIZE(reg_offsets); i++) {
+ pci_read_config_word(dev, ltr_cap_offset + reg_offsets[i],
+ <r_fmt_cur);
+ cur_nsec = LTR_FMT_TO_NS(ltr_fmt_cur);
+ if (cur_nsec == 0 || cur_nsec > BRCM_LTR_MAX_NS)
+ pci_write_config_word(dev, ltr_cap_offset
+ + reg_offsets[i], ltr_fmt);
+ }
+
+ return 0;
+}
+
+void brcm_set_downstream_devs_ltr_max(struct brcm_pcie *pcie)
+{
+ struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
+ u16 ltr_fmt = FIELD_PREP(GENMASK(9, 0), BRCM_LTR_MAX_VALUE)
+ | FIELD_PREP(GENMASK(12, 10), BRCM_LTR_MAX_SCALE)
+ | GENMASK(15, 15);
+
+ if (bridge->native_ltr)
+ pci_walk_bus(bridge->bus, brcm_set_dev_ltr_max, <r_fmt);
+}
+
/* The controller is capable of serving in both RC and EP roles */
static bool brcm_pcie_rc_mode(struct brcm_pcie *pcie)
{
@@ -1074,8 +1131,12 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
return -ENODEV;
}
- /* Extend internal bus timeout to 8ms or so */
- brcm_extend_internal_bus_timeout(pcie, SZ_8M);
+ /*
+ * Extend internal bus timeout to 8-10ms, specifically to a value
+ * that is slightly larger than what we are using for the max
+ * {no-}snoop latency we will set in downstream devices.
+ */
+ brcm_extend_internal_bus_timeout(pcie, BRCM_LTR_MAX_NS + 1000);
if (pcie->gen)
brcm_pcie_set_gen(pcie, pcie->gen);
@@ -1616,6 +1677,9 @@ static int brcm_pcie_probe(struct platform_device *pdev)
return ret;
}
+ if (IS_ENABLED(CONFIG_PCIEASPM))
+ brcm_set_downstream_devs_ltr_max(pcie);
+
return 0;
fail:
--
2.17.1
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4210 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v9 4/4] PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device
From: Jim Quinlan @ 2024-04-03 21:39 UTC (permalink / raw)
To: linux-pci, Nicolas Saenz Julienne, Bjorn Helgaas,
Lorenzo Pieralisi, Cyril Brulebois, Phil Elwell,
bcm-kernel-feedback-list, james.quinlan
Cc: Florian Fainelli, Jim Quinlan, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
In-Reply-To: <20240403213902.26391-1-james.quinlan@broadcom.com>
[-- Attachment #1.1: Type: text/plain, Size: 6260 bytes --]
The Broadcom STB/CM PCIe HW core, which is also used in RPi SOCs, must be
deliberately set by the PCIe RC HW into one of three mutually exclusive
modes:
"safe" -- No CLKREQ# expected or required, refclk is always provided. This
mode should work for all devices but is not be capable of any refclk
power savings.
"no-l1ss" -- CLKREQ# is expected to be driven by the downstream device for
CPM and ASPM L0s and L1. Provides Clock Power Management, L0s, and L1,
but cannot provide L1 substate (L1SS) power savings. If the downstream
device connected to the RC is L1SS capable AND the OS enables L1SS, all
PCIe traffic may abruptly halt, potentially hanging the system.
"default" -- Bidirectional CLKREQ# between the RC and downstream device.
Provides ASPM L0s, L1, and L1SS, but not compliant to provide Clock
Power Management; specifically, may not be able to meet the T_CLRon max
timing of 400ns as specified in "Dynamic Clock Control", section
3.2.5.2.2 of the PCIe Express Mini CEM 2.1 specification. This
situation is atypical and should happen only with older devices.
Previously, this driver always set the mode to "no-l1ss", as almost all
STB/CM boards operate in this mode. But now there is interest in
activating L1SS power savings from STB/CM customers, which requires
"default" mode. In addition, a bug was filed for RPi4 CM platform because
most devices did not work in "no-l1ss" mode (see link below).
Note that the mode is specified by the DT property "brcm,clkreq-mode". If
this property is omitted, then "default" mode is chosen.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217276
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 79 ++++++++++++++++++++++++---
1 file changed, 70 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 3d08b92d5bb8..3dc8511e6f58 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -48,6 +48,9 @@
#define PCIE_RC_CFG_PRIV1_LINK_CAPABILITY 0x04dc
#define PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_ASPM_SUPPORT_MASK 0xc00
+#define PCIE_RC_CFG_PRIV1_ROOT_CAP 0x4f8
+#define PCIE_RC_CFG_PRIV1_ROOT_CAP_L1SS_MODE_MASK 0xf8
+
#define PCIE_RC_DL_MDIO_ADDR 0x1100
#define PCIE_RC_DL_MDIO_WR_DATA 0x1104
#define PCIE_RC_DL_MDIO_RD_DATA 0x1108
@@ -121,9 +124,12 @@
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK 0x200000
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
#define PCIE_BMIPS_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x00800000
-
+#define PCIE_CLKREQ_MASK \
+ (PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK | \
+ PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK)
#define PCIE_INTR2_CPU_BASE 0x4300
#define PCIE_MSI_INTR2_BASE 0x4500
@@ -1100,13 +1106,73 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
return 0;
}
+static void brcm_config_clkreq(struct brcm_pcie *pcie)
+{
+ static const char err_msg[] = "invalid 'brcm,clkreq-mode' DT string\n";
+ const char *mode = "default";
+ u32 clkreq_cntl;
+ int ret, tmp;
+
+ ret = of_property_read_string(pcie->np, "brcm,clkreq-mode", &mode);
+ if (ret && ret != -EINVAL) {
+ dev_err(pcie->dev, err_msg);
+ mode = "safe";
+ }
+
+ /* Start out assuming safe mode (both mode bits cleared) */
+ clkreq_cntl = readl(pcie->base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
+ clkreq_cntl &= ~PCIE_CLKREQ_MASK;
+
+ if (strcmp(mode, "no-l1ss") == 0) {
+ /*
+ * "no-l1ss" -- Provides Clock Power Management, L0s, and
+ * L1, but cannot provide L1 substate (L1SS) power
+ * savings. If the downstream device connected to the RC is
+ * L1SS capable AND the OS enables L1SS, all PCIe traffic
+ * may abruptly halt, potentially hanging the system.
+ */
+ clkreq_cntl |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK;
+ /*
+ * We want to un-advertise L1 substates because if the OS
+ * tries to configure the controller into using L1 substate
+ * power savings it may fail or hang when the RC HW is in
+ * "no-l1ss" mode.
+ */
+ tmp = readl(pcie->base + PCIE_RC_CFG_PRIV1_ROOT_CAP);
+ u32p_replace_bits(&tmp, 2, PCIE_RC_CFG_PRIV1_ROOT_CAP_L1SS_MODE_MASK);
+ writel(tmp, pcie->base + PCIE_RC_CFG_PRIV1_ROOT_CAP);
+
+ } else if (strcmp(mode, "default") == 0) {
+ /*
+ * "default" -- Provides L0s, L1, and L1SS, but not
+ * compliant to provide Clock Power Management;
+ * specifically, may not be able to meet the Tclron max
+ * timing of 400ns as specified in "Dynamic Clock Control",
+ * section 3.2.5.2.2 of the PCIe spec. This situation is
+ * atypical and should happen only with older devices.
+ */
+ clkreq_cntl |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_L1SS_ENABLE_MASK;
+
+ } else {
+ /*
+ * "safe" -- No power savings; refclk is driven by RC
+ * unconditionally.
+ */
+ if (strcmp(mode, "safe") != 0)
+ dev_err(pcie->dev, err_msg);
+ mode = "safe";
+ }
+ writel(clkreq_cntl, pcie->base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
+
+ dev_info(pcie->dev, "clkreq-mode set to %s\n", mode);
+}
+
static int brcm_pcie_start_link(struct brcm_pcie *pcie)
{
struct device *dev = pcie->dev;
void __iomem *base = pcie->base;
u16 nlw, cls, lnksta;
bool ssc_good = false;
- u32 tmp;
int ret, i;
/* Unassert the fundamental reset */
@@ -1138,6 +1204,8 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
*/
brcm_extend_internal_bus_timeout(pcie, BRCM_LTR_MAX_NS + 1000);
+ brcm_config_clkreq(pcie);
+
if (pcie->gen)
brcm_pcie_set_gen(pcie, pcie->gen);
@@ -1156,13 +1224,6 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
pci_speed_string(pcie_link_speed[cls]), nlw,
ssc_good ? "(SSC)" : "(!SSC)");
- /*
- * Refclk from RC should be gated with CLKREQ# input when ASPM L0s,L1
- * is enabled => setting the CLKREQ_DEBUG_ENABLE field to 1.
- */
- tmp = readl(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
- tmp |= PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK;
- writel(tmp, base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
return 0;
}
--
2.17.1
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4210 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 31/34] spi: remove incorrect of_match_ptr annotations
From: Arnd Bergmann @ 2024-04-03 22:19 UTC (permalink / raw)
To: Andy Shevchenko, Uwe Kleine-König
Cc: Mark Brown, Arnd Bergmann, linux-kernel, Neil Armstrong,
Kevin Hilman, Heiko Stübner, Andi Shyti, Krzysztof Kozlowski,
Jerome Brunet, Martin Blumenstingl, Alim Akhtar, Li Zetao,
Jonathan Cameron, Rob Herring, Yang Yingliang, Andy Shevchenko,
Luis de Arquer, Tudor Ambarus, Sam Protsenko, Peter Griffin,
Jaewon Kim, linux-spi, linux-arm-kernel, linux-amlogic,
linux-rockchip, linux-samsung-soc
In-Reply-To: <Zg3GdUtBUKzB6NNZ@surfacebook.localdomain>
On Wed, Apr 3, 2024, at 23:13, Andy Shevchenko wrote:
> Wed, Apr 03, 2024 at 11:05:51PM +0200, Uwe Kleine-König kirjoitti:
>> On Wed, Apr 03, 2024 at 10:56:58AM +0100, Mark Brown wrote:
>> > On Wed, Apr 03, 2024 at 10:06:49AM +0200, Arnd Bergmann wrote:
>> >
>> > > These appear to all be copied from the same original driver, so fix them at the
>> > > same time by removing the unnecessary of_match_ptr() annotation. As far as I
>> > > can tell, all these drivers are only actually used on configurations that
>> > > have CONFIG_OF enabled.
>> >
>> > Why are we not fixing of_match_ptr() here, or at least adding the ifdefs
>> > in case someone does end up wanting to run without OF?
>>
>> Fixing of_match_ptr =
>>
>> diff --git a/include/linux/of.h b/include/linux/of.h
>> index a0bedd038a05..d980bccffda0 100644
>> --- a/include/linux/of.h
>> +++ b/include/linux/of.h
>> @@ -890,7 +890,7 @@ static inline const void *of_device_get_match_data(const struct device *dev)
>> return NULL;
>> }
>>
>> -#define of_match_ptr(_ptr) NULL
>> +#define of_match_ptr(_ptr) (0 ? (_ptr) : NULL)
This would require removing several hundred "#ifdef CONFIG_OF"
checks around the of_device_id tables at the same time
unfortunately. Most of those are completely unnecessary, so
if we wanted to remove those, we should remove the of_match_ptr()
instances at the same time.
>> #define of_match_node(_matches, _node) NULL
>> #endif /* CONFIG_OF */
>>
>> ?
>>
>> Assuming this helps, I agree this would be the better fix.
>
> Why? I mean why do we need to even have this API? It's always
> good to know which devices are supported by the module even
> if you have no need in such support or it's not compiled in.
> One of the reasons why is to be able to google for compatible hardware,
> for example.
As far as I can tell, the of_match_ptr() helper was a historic
mistake, it makes pretty much no sense in its current form.
The version that Uwe proposes would have made sense but we
can't change it now.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4] perf/marvell: Marvell PEM performance monitor support
From: Andrew Lunn @ 2024-04-03 22:40 UTC (permalink / raw)
To: Gowthami Thiagarajan
Cc: will, mark.rutland, linux-arm-kernel, linux-kernel, sgoutham,
gcherian, lcherian
In-Reply-To: <20240403054110.2057137-1-gthiagarajan@marvell.com>
> +config MARVELL_PEM_PMU
> + tristate "MARVELL PEM PMU Support"
> + depends on ARCH_THUNDER || (COMPILE_TEST && 64BIT)
Why the && 64BIT?
I expect any kernel function/macro should work on 32bit systems as
well, but might internally need a different implementation. But
drivers should not need to care.
If you get warning / errors with 32bit systems, it might suggests your
driver is not as clean as it could be.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Heiko Stübner @ 2024-04-03 22:48 UTC (permalink / raw)
To: Shreeya Patel, Krzysztof Kozlowski
Cc: mchehab, hverkuil, hverkuil-cisco, robh, krzysztof.kozlowski+dt,
conor+dt, mturquette, sboyd, p.zabel, shawn.wen, kernel,
linux-kernel, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-clk, linux-arm
In-Reply-To: <86150c89-11d5-4d52-987e-974b1a03018f@linaro.org>
Am Mittwoch, 3. April 2024, 13:24:05 CEST schrieb Krzysztof Kozlowski:
> On 03/04/2024 13:20, Shreeya Patel wrote:
> > On Wednesday, April 03, 2024 15:51 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> >
> >> On 03/04/2024 11:24, Shreeya Patel wrote:
> >>> On Thursday, March 28, 2024 04:20 IST, Shreeya Patel <shreeya.patel@collabora.com> wrote:
> >>>
> >>>> This series implements support for the Synopsys DesignWare
> >>>> HDMI RX Controller, being compliant with standard HDMI 1.4b
> >>>> and HDMI 2.0.
> >>>>
> >>>
> >>> Hi Mauro and Hans,
> >>>
> >>> I haven't received any reviews so far. Hence, this is just a gentle reminder to review this patch series.
> >>
> >> Why did you put clk changes here? These go via different subsystem. That
> >> might be one of obstacles for your patchset.
> >>
> >
> > I added clock changes in this patch series because HDMIRX driver depends on it.
> > I thought it is wrong to send the driver patches which don't even compile?
>
> Hm, why HDMIRX driver depends on clock? How? This sounds really wrong.
> Please get it reviewed internally first.
For the change in question, the clock controller on the soc also handles
the reset controls (hence its name CRU, clock-and-reset-unit) .
There are at least 660 reset lines in the unit and it seems the hdmi-rx one
was overlooked on the initial submission, hence patches 1+2 add the
reset-line.
Of course, here only the "arm64: dts:" patch depends on the clock
change, is it references the new reset-id.
Am Mittwoch, 3. April 2024, 12:22:57 CEST schrieb Krzysztof Kozlowski:
> Please do not engage multiple subsystems in one patchset, if not
> necessary. Especially do not mix DTS into media or USB subsystems. And
> do not put DTS in the middle!
picking up your reply from patch 4/6, there seem to be different "schools
of thought" for this. Some maintainers might want to really only see
patches that are explicitly for their subsystem - I guess networking
might be a prime example for that, who will essentially apply whole series'
if nobody protests in time (including dts patches)
On the other hand I also remember seeing requests for "the full picture"
and individual maintainers then just picking and applying the patches
meant for their subsystem.
The series as it stands right now is nice in that it allows (random)
developers to just pick it up, apply it to a tree and test the actual driver
without needing to hunt for multiple dependant series.
Of course you're right, the "arm64: dts:" patch should be the last in the
series and not be in the middle of it.
Regards
Heiko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/7] drm/display: Fix display helpers depends on fallouts
From: Mark Brown @ 2024-04-03 23:15 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Daniel Vetter,
Jani Nikula, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Javier Martinez Canillas, Russell King, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Chen-Yu Tsai,
Samuel Holland, Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
Alexander Stein, dri-devel, linux-kernel, linux-arm-kernel, imx,
linux-sunxi, linux-mips, kernel test robot
In-Reply-To: <20240403-fix-dw-hdmi-kconfig-v1-0-afbc4a835c38@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 472 bytes --]
On Wed, Apr 03, 2024 at 12:56:18PM +0200, Maxime Ripard wrote:
> Hi,
>
> Here's a series addressing the various regressions that were reported
> after the Kconfig rework for the DRM display helpers.
This makes sense to me and looks like it does the right thing for
multi_v7_defconfig so
Reviewed-by: Mark Brown <broonie@kernel.org>
Between the arm64 defconfig update not applying on -next and unrelated
breakage on arm I didn't actually do a proper test.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 01/11] mm/page_table_check: Reinstate address parameter in [__]page_table_check_pud_set()
From: Pasha Tatashin @ 2024-04-03 23:17 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-2-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:11 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> This reverts commit 6d144436d954 ("mm/page_table_check: remove unused
> parameter in [__]page_table_check_pud_set").
>
> Reinstate previously unused parameters for the purpose of supporting
> powerpc platforms, as many do not encode user/kernel ownership of the
> page in the pte, but instead in the address of the access.
>
> riscv: Respect change to delete mm, addr parameters from __set_pte_at()
>
> This commit also changed calls to __set_pte_at() to use fewer parameters
> on riscv. Keep that change rather than reverting it, as the signature of
> __set_pte_at() is changed in a different commit.
>
> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
For some reason this one was not delivered to the linux-mm mailing list.
Pasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 02/11] mm/page_table_check: Reinstate address parameter in [__]page_table_check_pmd_set()
From: Pasha Tatashin @ 2024-04-03 23:19 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-3-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:13 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> This reverts commit a3b837130b58 ("mm/page_table_check: remove unused
> parameter in [__]page_table_check_pmd_set").
>
> Reinstate previously unused parameters for the purpose of supporting
> powerpc platforms, as many do not encode user/kernel ownership of the
> page in the pte, but instead in the address of the access.
>
> riscv: Respect change to delete mm, addr parameters from __set_pte_at()
>
> This commit also changed calls to __set_pte_at() to use fewer parameters
> on riscv. Keep that change rather than reverting it, as the signature of
> __set_pte_at() is changed in a different commit.
>
> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 03/11] mm/page_table_check: Provide addr parameter to page_table_check_pte_set()
From: Pasha Tatashin @ 2024-04-03 23:20 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-4-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:11 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> To provide support for powerpc platforms, provide an addr parameter to
> the page_table_check_pte_set() routine. This parameter is needed on some
> powerpc platforms which do not encode whether a mapping is for user or
> kernel in the pte. On such platforms, this can be inferred form the
> addr parameter.
>
> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 04/11] mm/page_table_check: Reinstate address parameter in [__]page_table_check_pud_clear()
From: Pasha Tatashin @ 2024-04-03 23:21 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-5-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:13 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> This reverts commit 931c38e16499 ("mm/page_table_check: remove unused
> parameter in [__]page_table_check_pud_clear").
>
> Reinstate previously unused parameters for the purpose of supporting
> powerpc platforms, as many do not encode user/kernel ownership of the
> page in the pte, but instead in the address of the access.
>
> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 00/11] Support page table check PowerPC
From: Pasha Tatashin @ 2024-04-03 23:24 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-1-rmclure@linux.ibm.com>
All patches in this series should be also CC'd to linux-kernel@vger.kernel.org.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 05/11] mm/page_table_check: Reinstate address parameter in [__]page_table_check_pmd_clear()
From: Pasha Tatashin @ 2024-04-03 23:26 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-6-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:11 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> This reverts commit 1831414cd729 ("mm/page_table_check: remove unused
> parameter in [__]page_table_check_pmd_clear").
>
> Reinstate previously unused parameters for the purpose of supporting
> powerpc platforms, as many do not encode user/kernel ownership of the
> page in the pte, but instead in the address of the access.
>
> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 06/11] mm/page_table_check: Reinstate address parameter in [__]page_table_check_pte_clear()
From: Pasha Tatashin @ 2024-04-03 23:46 UTC (permalink / raw)
To: Rohan McLure
Cc: linuxppc-dev, mpe, christophe.leroy, linux-mm, linux-riscv,
linux-arm-kernel, x86
In-Reply-To: <20240402051154.476244-7-rmclure@linux.ibm.com>
On Tue, Apr 2, 2024 at 1:11 AM Rohan McLure <rmclure@linux.ibm.com> wrote:
>
> This reverts commit aa232204c468 ("mm/page_table_check: remove unused
> parameter in [__]page_table_check_pte_clear").
>
> Reinstate previously unused parameters for the purpose of supporting
> powerpc platforms, as many do not encode user/kernel ownership of the
> page in the pte, but instead in the address of the access.
>
> Signed-off-by: Rohan McLure <rmclure@linux.ibm.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox