Re: [PATCH] MAINTAINERS: powerpc: Transfer PPC83XX to Christophe
On Tue, 2023-12-05 at 16:12 +1100, Michael Ellerman wrote: > Christophe volunteered[1] to maintain PPC83XX. > > 1: > https://lore.kernel.org/all/7b1bf4dc-d09d-35b8-f4df-16bf00429...@csgroup.eu/ > > Signed-off-by: Michael Ellerman > --- > MAINTAINERS | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 562d048863ee..d4efe48cc36a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -12287,21 +12287,21 @@ S:Orphan > F: arch/powerpc/platforms/40x/ > F: arch/powerpc/platforms/44x/ > > -LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX > +LINUX FOR POWERPC EMBEDDED PPC85XX > M: Scott Wood > L: linuxppc-dev@lists.ozlabs.org > S: Odd fixes > T: git > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git > F: Documentation/devicetree/bindings/cache/freescale-l2cache.txt > F: Documentation/devicetree/bindings/powerpc/fsl/ > -F: arch/powerpc/platforms/83xx/ > F: arch/powerpc/platforms/85xx/ > > -LINUX FOR POWERPC EMBEDDED PPC8XX > +LINUX FOR POWERPC EMBEDDED PPC8XX AND PPC83XX > M: Christophe Leroy > L: linuxppc-dev@lists.ozlabs.org > S: Maintained > F: arch/powerpc/platforms/8xx/ > +F: arch/powerpc/platforms/83xx/ Acked-by: Crystal Wood -Crystal
Re: [PATCH v3 2/2] soc: fsl: qbman: Use raw spinlock for cgr_lock
On Tue, 2023-04-11 at 11:09 -0400, Sean Anderson wrote:
> Hi Crystal,
>
> On 4/4/23 12:04, Sean Anderson wrote:
> > On 4/4/23 11:33, Crystal Wood wrote:
> > > On Tue, 2023-04-04 at 10:55 -0400, Sean Anderson wrote:
> > >
> > > > @@ -1456,11 +1456,11 @@ static void tqm_congestion_task(struct
> > > > work_struct
> > > > *work)
> > > > union qm_mc_result *mcr;
> > > > struct qman_cgr *cgr;
> > > >
> > > > - spin_lock_irq(>cgr_lock);
> > > > + raw_spin_lock_irq(>cgr_lock);
> > > > qm_mc_start(>p);
> > > > qm_mc_commit(>p, QM_MCC_VERB_QUERYCONGESTION);
> > > > if (!qm_mc_result_timeout(>p, )) {
> > > > - spin_unlock_irq(>cgr_lock);
> > > > + raw_spin_unlock_irq(>cgr_lock);
> > >
> > > qm_mc_result_timeout() spins with a timeout of 10 ms which is very
> > > inappropriate for a raw lock. What is the actual expected upper bound?
> >
> > Hm, maybe we can move this qm_mc stuff outside cgr_lock? In most other
> > places they're called without cgr_lock, which implies that its usage
> > here is meant to synchronize against some other function.
>
> Do you have any suggestions here? I think this should really be handled
> in a follow-up patch. If you think this code is waiting too long in a raw
> spinlock, the existing code can wait just as long with IRQs disabled.
> This patch doesn't change existing system responsiveness.
Well, AFAICT it expands the situations in which it happens from configuration
codepaths to stuff like congestion handling. The proper fix would probably be
to use some mechanism other than smp_call_function_single() to run code on the
target cpu so that it can run with irqs enabled (or get confirmation that the
actual worst case is short enough), but barring that I guess at least
acknowledge the situation in a comment?
-Crystal
Re: [PATCH v3 2/2] soc: fsl: qbman: Use raw spinlock for cgr_lock
On Tue, 2023-04-04 at 10:55 -0400, Sean Anderson wrote:
> @@ -1456,11 +1456,11 @@ static void qm_congestion_task(struct work_struct
> *work)
> union qm_mc_result *mcr;
> struct qman_cgr *cgr;
>
> - spin_lock_irq(>cgr_lock);
> + raw_spin_lock_irq(>cgr_lock);
> qm_mc_start(>p);
> qm_mc_commit(>p, QM_MCC_VERB_QUERYCONGESTION);
> if (!qm_mc_result_timeout(>p, )) {
> - spin_unlock_irq(>cgr_lock);
> + raw_spin_unlock_irq(>cgr_lock);
qm_mc_result_timeout() spins with a timeout of 10 ms which is very
inappropriate for a raw lock. What is the actual expected upper bound?
> dev_crit(p->config->dev, "QUERYCONGESTION timeout\n");
> qman_p_irqsource_add(p, QM_PIRQ_CSCI);
> return;
> @@ -1476,7 +1476,7 @@ static void qm_congestion_task(struct work_struct
> *work)
> list_for_each_entry(cgr, >cgr_cbs, node)
> if (cgr->cb && qman_cgrs_get(, cgr->cgrid))
> cgr->cb(p, cgr, qman_cgrs_get(, cgr->cgrid));
> - spin_unlock_irq(>cgr_lock);
> + raw_spin_unlock_irq(>cgr_lock);
> qman_p_irqsource_add(p, QM_PIRQ_CSCI);
> }
The callback loop is also a bit concerning...
-Crystal
Re: [RFC PATCH 0/4] Remove some e300/MPC83xx evaluation platforms
On Fri, 2023-03-03 at 10:14 +0100, Arnd Bergmann wrote: > On Fri, Mar 3, 2023, at 02:04, Paul Gortmaker wrote: > > 01/03/2023 (Wed 14:23) Christophe Leroy wrote: > > > Le 28/02/2023 ?? 18:51, Arnd Bergmann a ??crit??: > > > Hope it clarifies how those reference boards are used. > > > > It was really useful input and gave an insight into how things get used. > > > > But let me put a slightly different slant on things. If there is no > > maintainer for the platform/architecture/CPU, then where is the > > obligation for mainline to keep it up to date just for your company to > > use the code/BSP as a reference? > > > > Do they continue to do this for one more year, or three or ... ??? > > Does someone list themselves in MAINTAINERS for arch/powerpc/83xx ? > ... > > > > If you see change 0123abcdef breaks boot on your platform, you have a > > legit voice to gripe about it right then and there. Don't wait!!! > > I think the answer here is that Christophe is already the only person > that does this, so he is the de-facto maintainer for ppc32 regardless > of whether he wants himself listed in the file or not: > > $ git log --no-merges --format="%an" v5.0.. arch/powerpc/platforms/[458e]* | > sort | uniq -c | sort -rn | grep -vw 1 > 61 Christophe Leroy > 12 Michael Ellerman > 11 Thomas Gleixner > 11 Oliver O'Halloran > 11 Liang He > 7 Uwe Kleine-König > 6 Nick Child > 4 Rasmus Villemoes > 4 Randy Dunlap > 4 Mike Rapoport > 4 Julia Lawall > 4 Andy Shevchenko > 3 Xiaoming Ni > 3 Nicholas Piggin > 3 Marc Zyngier > 3 Christophe JAILLET > 3 Christoph Hellwig > 2 Paul Gortmaker > 2 Mathieu Malaterre > 2 Markus Elfring > 2 Jordan Niethe > 2 Dmitry Torokhov > 2 Arnd Bergmann > > Pretty much everyone else on the list above only did treewide > cleanups, dead code removal or compile-time fixes, while Christophe > is the one that fixed machine specific bugs and added new features. Speaking of that, I'd be fine with Christophe replacing me in the "LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX" entry, given that he's been way more involved than me lately. -Crystal
Re: [PATCH 4/4] powerpc: remove orphaned MPC85xx kernel config fragments.
On Tue, 2023-02-21 at 22:49 +0100, Pali Rohár wrote: > On Tuesday 21 February 2023 16:29:32 Paul Gortmaker wrote: > > [Re: [PATCH 4/4] powerpc: remove orphaned MPC85xx kernel config > > fragments.] On 21/02/2023 (Tue 21:03) Pali Roh??r wrote: > > > > > On Tuesday 21 February 2023 14:46:37 Paul Gortmaker wrote: > > > > None of these have a reference anymore anywhere, such as like this: > > > > > > > > arch/powerpc/Makefile: $(call > > > > merge_into_defconfig,mpc85xx_base.config,\ > > > > > > > > As such, we probably should just clean up and remove them. > > > > > > > > Cc: Scott Wood > > > > Cc: Michael Ellerman > > > > Cc: Benjamin Herrenschmidt > > > > Cc: Paul Mackerras > > > > Signed-off-by: Paul Gortmaker > > > > --- > > > > arch/powerpc/configs/85xx-32bit.config | 5 - > > > > arch/powerpc/configs/85xx-hw.config | 139 > > > > - > > > > arch/powerpc/configs/85xx-smp.config | 2 - > > > > 3 files changed, 146 deletions(-) > > > > delete mode 100644 arch/powerpc/configs/85xx-32bit.config > > > > delete mode 100644 arch/powerpc/configs/85xx-hw.config > > > > delete mode 100644 arch/powerpc/configs/85xx-smp.config > > > > > > This change is likely going to break mpc85xx platform because defconfig > > > files includes all these files which you are going to remove. For > > > example in arch/powerpc/Makefile is: > > > > > > PHONY += mpc85xx_smp_defconfig > > > mpc85xx_smp_defconfig: > > > $(call merge_into_defconfig,mpc85xx_base.config,\ > > > 85xx-32bit 85xx-smp 85xx-hw fsl-emb-nonhw) > > > > OK, it seems you've answered a question for me. That being "why didn't > > grep find a reference to these fragments?" > > > > It seems the ".config" extension is optional? > > I really do not know. (And I'm not sure if I want to know answer :D) It's not optional; you have to leave it off: # Used to create 'merged defconfigs' # To use it $(call) it with the first argument as the base defconfig # and the second argument as a space separated list of .config files to merge, # without the .config suffix. define merge_into_defconfig ... > > This seems inconsistent at best, to reference some files with the > > .config extension and others without it. Not blaming you for that, > > but it is probably something that needs looking into. > > I agree it is inconsistent. But it was there before I looked or touched > any powerpc code. So it looks like something which nobody wanted to > cleanup because "it works" and had no motivation. No, it's intentional to reduce verbosity. If by "inconsistent" you're referring to mpc85xx_base.config, that argument sometimes refers to _defconfig files (i.e. the pseries targets which were the initial user of merge_into_config) so that argument can't autoappend .config. -Crystal
Re: [RFC PATCH] Disable Book-E KVM support?
On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote: > BookE KVM is in a deep maintenance state, I'm not sure how much testing > it gets. I don't have a test setup, and it does not look like QEMU has > any HV architecture enabled. It hasn't been too painful but there are > some cases where it causes a bit of problem not being able to test, e.g., > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-November/251452.html > > Time to begin removal process, or are there still people using it? I'm > happy to to keep making occasional patches to try keep it going if > there are people testing upstream. Getting HV support into QEMU would > help with long term support, not sure how big of a job that would be. Not sure what you mean about QEMU not having e500 HV support? I don't know if it's bitrotted, but it's there. I don't know whether anyone is still using this, but if they are, it's probably e500mc and not e500v2 (which involved a bunch of hacks to get almost- sorta-usable performance out of hardware not designed for virtualization). I do see that there have been a few recent patches on QEMU e500 (beyond the treewide cleanup type stuff), though I don't know if they're using KVM. CCing them and the QEMU list. I have an e6500 I could occasionally test on, if it turns out people do still care about this. Don't count me as the use case, though. :-) FWIW, as far as the RECONCILE_IRQ_STATE issue, that used to be done in kvmppc_handle_exit(), but was moved in commit 9bd880a2c882 to be "cleaner and faster". :-P -Crystal
