Re: [PATCH v2 1/2] powerpc/ps3: Change updateboltedpp panic to info

[Christophe Leroy]

Le 16/01/2023 à 21:08, Geoff Levand a écrit :
> Hi,
> 
> On 1/15/23 16:06, Michael Ellerman wrote:
>> Geoff Levand  writes:
>>> On 1/9/23 09:41, Christophe Leroy wrote:


 Le 03/01/2023 à 18:51, Geoff Levand a écrit :
> Commit fdacae8a84024474afff234bdd1dbe19ad597a10 (powerpc: Activate
> CONFIG_STRICT_KERNEL_RWX by default) causes ps3_hpte_updateboltedpp()
> to be called.  Change the panic statment in ps3_hpte_updateboltedpp()
> to a pr_info statement so that bootup can continue.

 But if I understand correctly, it means that CONFIG_STRICT_KERNEL_RWX
 won't work then.

 So, shouldn't we keep the panic and forbid CONFIG_STRICT_KERNEL_RWX on PS3 
 ?
>>>
>>> mmu_hash_ops.updateboltedpp returns void, so I can't return an error code to
>>> indicate the feature is not supported.
>>
>> We could change that in the medium term.
>>
>>> I could do something like this in arch/powerpc/Kconfig:
>>>
>>> -   select ARCH_HAS_STRICT_KERNEL_RWX   if (PPC_BOOK3S || PPC_8xx 
>>> || 40x) && !HIBERNATION
>>> +   select ARCH_HAS_STRICT_KERNEL_RWX   if (PPC_BOOK3S || PPC_8xx 
>>> || 40x) && !PPC_PS3 && !HIBERNATION
>>>
>>> But then the ppc64_defconfig would be built without STRICT_KERNEL_RWX.
>>
>> Yeah that would be a pity.
>>
>> We could do the above and disable PS3 in ppc64_defconfig, allowing
>> ppc64_defconfig to still have STRICT_KERNEL_RWX.
> 
> I really want to keep PS3 included in ppc64_defconfig.  Not that I expect
> anyone to boot a ppc64_defconfig kernel on PS3, but that is one of the
> 'standard' configs that is built by some automated builders, and generally by
> anyone doing changes to the powerpc arch, and I want to keep getting those
> build tests for PS3.
> 
>> I assume actual PS3 users would use a ps3_defconfig anyway right?
> 
> Yeah, a derivative of it.  They are most likely are using 'Jailbreak' firmware
> that allows them to run Linux in the gameos partition.
> 
>> Relatedly are there any actual PS3 users left? ;)
> 
> It seems there are more users now than a few years ago.  I think they buy PS5s
> to play the latest games, and use their old console to mess around with Linux.
> I generally get a private inquiry every 3 or 4 weeks.  Usually asking how to
> update their kernel, or how to install a modern distro.
> 
>>> What other 'clean' way is there?
>>
>> If we want to have a multi-platform kernel image that can boot on PS3
>> and other platforms, and have strict kernel RWX, then we need some
>> runtime logic to deal with that.
>>
>> I'd rather not do that though, because it adds complexity to deal with a
>> pretty obscure corner case, and I suspect no one really boots a
>> ppc64_defconfig on actual PS3 hardware these days.
>>
>> So my preference is we disable PS3 in ppc64_defconfig, and make PS3
>> incompatible with STRICT_KERNEL_RWX.
> 
> As mentioned, I'd really like to keep PS3 included in ppc64_defconfig.  My
> original patch that basically just ignores the call to
> mmu_hash_ops.updateboltedpp allows that, and I haven't experienced any 
> problems
> with it yet.

When you say you have not experienced any problems with it, do you mean 
that STRICT_RWX works for you ? When you select CONFIG_DEBUG_RODATA_TEST 
it tells you that it works ? Otherwise it looks incorrect to enable 
something that doesn't work.

> 
> My preference would be to keep PS3 in ppc64_defconfig, and either apply my
> original patch, or I keep that patch in my ps3-linux repo on kernel.org. Then,
> if we end up adding runtime support for RWX I then fixup PS3 to use that.
> 

In that case I see two solutions:
1/ Implement updateboltedpp for PS3.
2/ Implement arch_parse_debug_rodata() to always set rodata_enabled = 
false on PS3, and update free_initmem() to only call mark_initmem_nx() 
when strict_kernel_rwx_enabled() returns true.

Christophe

Re: [PATCH] powerpc/secvar: Use u64 in secvar_operations

[Andrew Donnellan]

On Thu, 2023-01-12 at 13:38 +1100, Michael Ellerman wrote:
> There's no reason for secvar_operations to use uint64_t vs the more
> common kernel type u64.
> 
> The types are compatible, but they require different printk format
> strings which can lead to confusion.
> 
> Change all the secvar related routines to use u64.
> 
> Signed-off-by: Michael Ellerman 

We're going to include this patch in the next revision of our dynamic
key management series.

-- 
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com   IBM Australia Limited

Re: [PATCH 41/41] mm: replace rw_semaphore with atomic_t in vma_lock

[Suren Baghdasaryan]

On Mon, Jan 16, 2023 at 9:46 PM Matthew Wilcox  wrote:
>
> On Mon, Jan 16, 2023 at 08:34:36PM -0800, Suren Baghdasaryan wrote:
> > On Mon, Jan 16, 2023 at 8:14 PM Matthew Wilcox  wrote:
> > >
> > > On Mon, Jan 16, 2023 at 11:14:38AM +, Hyeonggon Yoo wrote:
> > > > > @@ -643,20 +647,28 @@ static inline void vma_write_lock(struct 
> > > > > vm_area_struct *vma)
> > > > >  static inline bool vma_read_trylock(struct vm_area_struct *vma)
> > > > >  {
> > > > > /* Check before locking. A race might cause false locked result. 
> > > > > */
> > > > > -   if (vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
> > > > > +   if (vma->vm_lock->lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
> > > > > return false;
> > > > >
> > > > > -   if (unlikely(down_read_trylock(>vm_lock->lock) == 0))
> > > > > +   if (unlikely(!atomic_inc_unless_negative(>vm_lock->count)))
> > > > > return false;
> > > > >
> > > > > +   /* If atomic_t overflows, restore and fail to lock. */
> > > > > +   if (unlikely(atomic_read(>vm_lock->count) < 0)) {
> > > > > +   if (atomic_dec_and_test(>vm_lock->count))
> > > > > +   wake_up(>vm_mm->vma_writer_wait);
> > > > > +   return false;
> > > > > +   }
> > > > > +
> > > > > /*
> > > > >  * Overflow might produce false locked result.
> > > > >  * False unlocked result is impossible because we modify and check
> > > > >  * vma->vm_lock_seq under vma->vm_lock protection and 
> > > > > mm->mm_lock_seq
> > > > >  * modification invalidates all existing locks.
> > > > >  */
> > > > > -   if (unlikely(vma->vm_lock_seq == 
> > > > > READ_ONCE(vma->vm_mm->mm_lock_seq))) {
> > > > > -   up_read(>vm_lock->lock);
> > > > > +   if (unlikely(vma->vm_lock->lock_seq == 
> > > > > READ_ONCE(vma->vm_mm->mm_lock_seq))) {
> > > > > +   if (atomic_dec_and_test(>vm_lock->count))
> > > > > +   wake_up(>vm_mm->vma_writer_wait);
> > > > > return false;
> > > > > }
> > > >
> > > > With this change readers can cause writers to starve.
> > > > What about checking waitqueue_active() before or after increasing
> > > > vma->vm_lock->count?
> > >
> > > I don't understand how readers can starve a writer.  Readers do
> > > atomic_inc_unless_negative() so a writer can always force readers
> > > to fail.
> >
> > I think the point here was that if page faults keep occuring and they
> > prevent vm_lock->count from reaching 0 then a writer will be blocked
> > and there is no reader throttling mechanism (no max time that writer
> > will be waiting).
>
> Perhaps I misunderstood your description; I thought that a _waiting_
> writer would make the count negative, not a successfully acquiring
> writer.

A waiting writer does not modify the counter, instead it's placed on
the wait queue and the last reader which sets the count to 0 while
releasing its read lock will wake it up. Once the writer is woken it
will try to set the count to negative and if successful will own the
lock, otherwise it goes back to sleep.

Re: [PATCH 41/41] mm: replace rw_semaphore with atomic_t in vma_lock

[Matthew Wilcox]

On Mon, Jan 16, 2023 at 08:34:36PM -0800, Suren Baghdasaryan wrote:
> On Mon, Jan 16, 2023 at 8:14 PM Matthew Wilcox  wrote:
> >
> > On Mon, Jan 16, 2023 at 11:14:38AM +, Hyeonggon Yoo wrote:
> > > > @@ -643,20 +647,28 @@ static inline void vma_write_lock(struct 
> > > > vm_area_struct *vma)
> > > >  static inline bool vma_read_trylock(struct vm_area_struct *vma)
> > > >  {
> > > > /* Check before locking. A race might cause false locked result. */
> > > > -   if (vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
> > > > +   if (vma->vm_lock->lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
> > > > return false;
> > > >
> > > > -   if (unlikely(down_read_trylock(>vm_lock->lock) == 0))
> > > > +   if (unlikely(!atomic_inc_unless_negative(>vm_lock->count)))
> > > > return false;
> > > >
> > > > +   /* If atomic_t overflows, restore and fail to lock. */
> > > > +   if (unlikely(atomic_read(>vm_lock->count) < 0)) {
> > > > +   if (atomic_dec_and_test(>vm_lock->count))
> > > > +   wake_up(>vm_mm->vma_writer_wait);
> > > > +   return false;
> > > > +   }
> > > > +
> > > > /*
> > > >  * Overflow might produce false locked result.
> > > >  * False unlocked result is impossible because we modify and check
> > > >  * vma->vm_lock_seq under vma->vm_lock protection and 
> > > > mm->mm_lock_seq
> > > >  * modification invalidates all existing locks.
> > > >  */
> > > > -   if (unlikely(vma->vm_lock_seq == 
> > > > READ_ONCE(vma->vm_mm->mm_lock_seq))) {
> > > > -   up_read(>vm_lock->lock);
> > > > +   if (unlikely(vma->vm_lock->lock_seq == 
> > > > READ_ONCE(vma->vm_mm->mm_lock_seq))) {
> > > > +   if (atomic_dec_and_test(>vm_lock->count))
> > > > +   wake_up(>vm_mm->vma_writer_wait);
> > > > return false;
> > > > }
> > >
> > > With this change readers can cause writers to starve.
> > > What about checking waitqueue_active() before or after increasing
> > > vma->vm_lock->count?
> >
> > I don't understand how readers can starve a writer.  Readers do
> > atomic_inc_unless_negative() so a writer can always force readers
> > to fail.
> 
> I think the point here was that if page faults keep occuring and they
> prevent vm_lock->count from reaching 0 then a writer will be blocked
> and there is no reader throttling mechanism (no max time that writer
> will be waiting).

Perhaps I misunderstood your description; I thought that a _waiting_
writer would make the count negative, not a successfully acquiring
writer.

Re: [PATCH v3 35/51] trace,hardirq: No moar _rcuidle() tracing

[Google]

Hi Peter,

On Thu, 12 Jan 2023 20:43:49 +0100
Peter Zijlstra  wrote:

> Robot reported that trace_hardirqs_{on,off}() tickle the forbidden
> _rcuidle() tracepoint through local_irq_{en,dis}able().
> 
> For 'sane' configs, these calls will only happen with RCU enabled and
> as such can use the regular tracepoint. This also means it's possible
> to trace them from NMI context again.
> 
> Signed-off-by: Peter Zijlstra (Intel) 

The code looks good to me. I just have a question about comment.

> ---
>  kernel/trace/trace_preemptirq.c |   21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> --- a/kernel/trace/trace_preemptirq.c
> +++ b/kernel/trace/trace_preemptirq.c
> @@ -20,6 +20,15 @@
>  static DEFINE_PER_CPU(int, tracing_irq_cpu);
>  
>  /*
> + * ...

Is this intended? Wouldn't you leave any comment here?

Thank you,

> + */
> +#ifdef CONFIG_ARCH_WANTS_NO_INSTR
> +#define trace(point) trace_##point
> +#else
> +#define trace(point) if (!in_nmi()) trace_##point##_rcuidle
> +#endif
> +
> +/*
>   * Like trace_hardirqs_on() but without the lockdep invocation. This is
>   * used in the low level entry code where the ordering vs. RCU is important
>   * and lockdep uses a staged approach which splits the lockdep hardirq
> @@ -28,8 +37,7 @@ static DEFINE_PER_CPU(int, tracing_irq_c
>  void trace_hardirqs_on_prepare(void)
>  {
>   if (this_cpu_read(tracing_irq_cpu)) {
> - if (!in_nmi())
> - trace_irq_enable(CALLER_ADDR0, CALLER_ADDR1);
> + trace(irq_enable)(CALLER_ADDR0, CALLER_ADDR1);
>   tracer_hardirqs_on(CALLER_ADDR0, CALLER_ADDR1);
>   this_cpu_write(tracing_irq_cpu, 0);
>   }
> @@ -40,8 +48,7 @@ NOKPROBE_SYMBOL(trace_hardirqs_on_prepar
>  void trace_hardirqs_on(void)
>  {
>   if (this_cpu_read(tracing_irq_cpu)) {
> - if (!in_nmi())
> - trace_irq_enable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> + trace(irq_enable)(CALLER_ADDR0, CALLER_ADDR1);
>   tracer_hardirqs_on(CALLER_ADDR0, CALLER_ADDR1);
>   this_cpu_write(tracing_irq_cpu, 0);
>   }
> @@ -63,8 +70,7 @@ void trace_hardirqs_off_finish(void)
>   if (!this_cpu_read(tracing_irq_cpu)) {
>   this_cpu_write(tracing_irq_cpu, 1);
>   tracer_hardirqs_off(CALLER_ADDR0, CALLER_ADDR1);
> - if (!in_nmi())
> - trace_irq_disable(CALLER_ADDR0, CALLER_ADDR1);
> + trace(irq_disable)(CALLER_ADDR0, CALLER_ADDR1);
>   }
>  
>  }
> @@ -78,8 +84,7 @@ void trace_hardirqs_off(void)
>   if (!this_cpu_read(tracing_irq_cpu)) {
>   this_cpu_write(tracing_irq_cpu, 1);
>   tracer_hardirqs_off(CALLER_ADDR0, CALLER_ADDR1);
> - if (!in_nmi())
> - trace_irq_disable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> + trace(irq_disable)(CALLER_ADDR0, CALLER_ADDR1);
>   }
>  }
>  EXPORT_SYMBOL(trace_hardirqs_off);
> 
> 


-- 
Masami Hiramatsu (Google) 

Re: [PATCH 41/41] mm: replace rw_semaphore with atomic_t in vma_lock

[Suren Baghdasaryan]

On Mon, Jan 16, 2023 at 8:14 PM Matthew Wilcox  wrote:
>
> On Mon, Jan 16, 2023 at 11:14:38AM +, Hyeonggon Yoo wrote:
> > > @@ -643,20 +647,28 @@ static inline void vma_write_lock(struct 
> > > vm_area_struct *vma)
> > >  static inline bool vma_read_trylock(struct vm_area_struct *vma)
> > >  {
> > > /* Check before locking. A race might cause false locked result. */
> > > -   if (vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
> > > +   if (vma->vm_lock->lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
> > > return false;
> > >
> > > -   if (unlikely(down_read_trylock(>vm_lock->lock) == 0))
> > > +   if (unlikely(!atomic_inc_unless_negative(>vm_lock->count)))
> > > return false;
> > >
> > > +   /* If atomic_t overflows, restore and fail to lock. */
> > > +   if (unlikely(atomic_read(>vm_lock->count) < 0)) {
> > > +   if (atomic_dec_and_test(>vm_lock->count))
> > > +   wake_up(>vm_mm->vma_writer_wait);
> > > +   return false;
> > > +   }
> > > +
> > > /*
> > >  * Overflow might produce false locked result.
> > >  * False unlocked result is impossible because we modify and check
> > >  * vma->vm_lock_seq under vma->vm_lock protection and mm->mm_lock_seq
> > >  * modification invalidates all existing locks.
> > >  */
> > > -   if (unlikely(vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))) 
> > > {
> > > -   up_read(>vm_lock->lock);
> > > +   if (unlikely(vma->vm_lock->lock_seq == 
> > > READ_ONCE(vma->vm_mm->mm_lock_seq))) {
> > > +   if (atomic_dec_and_test(>vm_lock->count))
> > > +   wake_up(>vm_mm->vma_writer_wait);
> > > return false;
> > > }
> >
> > With this change readers can cause writers to starve.
> > What about checking waitqueue_active() before or after increasing
> > vma->vm_lock->count?
>
> I don't understand how readers can starve a writer.  Readers do
> atomic_inc_unless_negative() so a writer can always force readers
> to fail.

I think the point here was that if page faults keep occuring and they
prevent vm_lock->count from reaching 0 then a writer will be blocked
and there is no reader throttling mechanism (no max time that writer
will be waiting).

Re: [PATCH 41/41] mm: replace rw_semaphore with atomic_t in vma_lock

[Matthew Wilcox]

On Mon, Jan 16, 2023 at 11:14:38AM +, Hyeonggon Yoo wrote:
> > @@ -643,20 +647,28 @@ static inline void vma_write_lock(struct 
> > vm_area_struct *vma)
> >  static inline bool vma_read_trylock(struct vm_area_struct *vma)
> >  {
> > /* Check before locking. A race might cause false locked result. */
> > -   if (vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
> > +   if (vma->vm_lock->lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
> > return false;
> >  
> > -   if (unlikely(down_read_trylock(>vm_lock->lock) == 0))
> > +   if (unlikely(!atomic_inc_unless_negative(>vm_lock->count)))
> > return false;
> >  
> > +   /* If atomic_t overflows, restore and fail to lock. */
> > +   if (unlikely(atomic_read(>vm_lock->count) < 0)) {
> > +   if (atomic_dec_and_test(>vm_lock->count))
> > +   wake_up(>vm_mm->vma_writer_wait);
> > +   return false;
> > +   }
> > +
> > /*
> >  * Overflow might produce false locked result.
> >  * False unlocked result is impossible because we modify and check
> >  * vma->vm_lock_seq under vma->vm_lock protection and mm->mm_lock_seq
> >  * modification invalidates all existing locks.
> >  */
> > -   if (unlikely(vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))) {
> > -   up_read(>vm_lock->lock);
> > +   if (unlikely(vma->vm_lock->lock_seq == 
> > READ_ONCE(vma->vm_mm->mm_lock_seq))) {
> > +   if (atomic_dec_and_test(>vm_lock->count))
> > +   wake_up(>vm_mm->vma_writer_wait);
> > return false;
> > }
> 
> With this change readers can cause writers to starve.
> What about checking waitqueue_active() before or after increasing
> vma->vm_lock->count?

I don't understand how readers can starve a writer.  Readers do
atomic_inc_unless_negative() so a writer can always force readers
to fail.

linux-next: build failure after merge of the crypto tree

[Stephen Rothwell]

Hi all,

After merging the crypto tree, today's linux-next build (powerpc
pseries_le_defconfig) failed like this:

arch/powerpc/crypto/p10_aes_gcm.o: warning: objtool: .text+0x884: unannotated 
intra-function call
arch/powerpc/crypto/aesp8-ppc.o: warning: objtool: aes_p8_set_encrypt_key+0x44: 
unannotated intra-function call
ld: arch/powerpc/crypto/p10_aes_gcm.o: ABI version 1 is not compatible with ABI 
version 2 output
ld: failed to merge target specific data of file 
arch/powerpc/crypto/p10_aes_gcm.o

Caused by commit

  ca68a96c37eb ("crypto: p10-aes-gcm - An accelerated AES/GCM stitched 
implementation")

I have applied the following hack for today.

From: Stephen Rothwell 
Date: Tue, 17 Jan 2023 14:41:10 +1100
Subject: [PATCH] crypto: p10-aes-gcm - only ABIv1 code has been implemented

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/crypto/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig
index db7d99383993..36928ad14a6b 100644
--- a/arch/powerpc/crypto/Kconfig
+++ b/arch/powerpc/crypto/Kconfig
@@ -97,6 +97,7 @@ config CRYPTO_AES_PPC_SPE
 config CRYPTO_P10_AES_GCM
tristate "Stitched AES/GCM acceleration support on P10+ CPU (PPC)"
depends on PPC64
+   depends on PPC64_ELF_ABI_V1
select CRYPTO_LIB_AES
select CRYPTO_ALGAPI
select CRYPTO_AEAD
-- 
2.35.1

-- 
Cheers,
Stephen Rothwell


pgpjb5RKa4Mi1.pgp
Description: OpenPGP digital signature

Re: [PATCH 41/41] mm: replace rw_semaphore with atomic_t in vma_lock

[Suren Baghdasaryan]

On Mon, Jan 16, 2023 at 3:15 AM Hyeonggon Yoo <42.hye...@gmail.com> wrote:
>
> On Mon, Jan 09, 2023 at 12:53:36PM -0800, Suren Baghdasaryan wrote:
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index d40bf8a5e19e..294dd44b2198 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -627,12 +627,16 @@ static inline void vma_write_lock(struct 
> > vm_area_struct *vma)
> >* mm->mm_lock_seq can't be concurrently modified.
> >*/
> >   mm_lock_seq = READ_ONCE(vma->vm_mm->mm_lock_seq);
> > - if (vma->vm_lock_seq == mm_lock_seq)
> > + if (vma->vm_lock->lock_seq == mm_lock_seq)
> >   return;
> >
> > - down_write(>vm_lock->lock);
> > - vma->vm_lock_seq = mm_lock_seq;
> > - up_write(>vm_lock->lock);
> > + if (atomic_cmpxchg(>vm_lock->count, 0, -1))
> > + wait_event(vma->vm_mm->vma_writer_wait,
> > +atomic_cmpxchg(>vm_lock->count, 0, -1) == 0);
> > + vma->vm_lock->lock_seq = mm_lock_seq;
> > + /* Write barrier to ensure lock_seq change is visible before count */
> > + smp_wmb();
> > + atomic_set(>vm_lock->count, 0);
> >  }
> >
> >  /*
> > @@ -643,20 +647,28 @@ static inline void vma_write_lock(struct 
> > vm_area_struct *vma)
> >  static inline bool vma_read_trylock(struct vm_area_struct *vma)
> >  {
> >   /* Check before locking. A race might cause false locked result. */
> > - if (vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
> > + if (vma->vm_lock->lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
> >   return false;
> >
> > - if (unlikely(down_read_trylock(>vm_lock->lock) == 0))
> > + if (unlikely(!atomic_inc_unless_negative(>vm_lock->count)))
> >   return false;
> >
> > + /* If atomic_t overflows, restore and fail to lock. */
> > + if (unlikely(atomic_read(>vm_lock->count) < 0)) {
> > + if (atomic_dec_and_test(>vm_lock->count))
> > + wake_up(>vm_mm->vma_writer_wait);
> > + return false;
> > + }
> > +
> >   /*
> >* Overflow might produce false locked result.
> >* False unlocked result is impossible because we modify and check
> >* vma->vm_lock_seq under vma->vm_lock protection and mm->mm_lock_seq
> >* modification invalidates all existing locks.
> >*/
> > - if (unlikely(vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))) 
> > {
> > - up_read(>vm_lock->lock);
> > + if (unlikely(vma->vm_lock->lock_seq == 
> > READ_ONCE(vma->vm_mm->mm_lock_seq))) {
> > + if (atomic_dec_and_test(>vm_lock->count))
> > + wake_up(>vm_mm->vma_writer_wait);
> >   return false;
> >   }
>
> With this change readers can cause writers to starve.
> What about checking waitqueue_active() before or after increasing
> vma->vm_lock->count?

The readers are in page fault path, which is the fast path, while
writers performing updates are in slow path. Therefore I *think*
starving writers should not be a big issue. So far in benchmarks I
haven't seen issues with that but maybe there is such a case?

>
> --
> Thanks,
> Hyeonggon
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to kernel-team+unsubscr...@android.com.
>

Re: [PATCH 1/2] tools/perf/tests: Fix string substitutions in build id test

[Ian Rogers]

On Mon, Jan 16, 2023 at 4:00 AM Athira Rajeev
 wrote:
>
>
>
> > On 16-Jan-2023, at 11:47 AM, Ian Rogers  wrote:
> >
> > On Sun, Jan 15, 2023 at 9:03 PM Athira Rajeev
> >  wrote:
> >>
> >>
> >>
> >>> On 28-Sep-2022, at 10:24 AM, Athira Rajeev  
> >>> wrote:
> >>>
> >>> Hi All,
> >>>
> >>> Looking for what direction we can take here.
> >>> Do we want to change all tests in tools/perf/tests/shell except 
> >>> test_intel_pt.sh to use "bash" or go with
> >>> the approach in the patch ? Please share your comments
> >>>
> >>> Thanks
> >>> Athira
> >>>
> >>
> >> Hi All,
> >>
> >> Looking for what direction we can take here.
> >> Do we want to change all tests in tools/perf/tests/shell except 
> >> test_intel_pt.sh to use "bash" or go with
> >> the approach in the patch ? Please share your comments
> >>
> >> Thanks
> >> Athira
> >
>
> Thanks Ian for the response.
>
> > I think some of what the patch is doing is good, some of it the
>
> Ian, can I take this as an ack for the patch so that Arnaldo can pick this in 
> acme git ?

Acked-by: Ian Rogers 

Thanks,
Ian

> > readability becomes a little harder by not being bash. I'm agnostic as
> > to which approach to take for the fix.
>
> May be we can take this as separate mail thread to get everyone’s opinion on 
> changing all tests in "tools/perf/tests/shell" except test_intel_pt.sh to use 
> “bash" ?
>
> >
> > An aside, I noticed that we do run some tests at build time:
> > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/lib/Makefile?h=perf/core#n390
> > So perhaps we can have a shellcheck build option, defaulted off but
> > enabled as part of Arnaldo's regular test scripts. The shellcheck
> > build option would run shellcheck to make sure that there weren't
> > errors in the shell code, which it is far too easy to introduce.
>
> Sure, that is a good option to have. I will check on having “shellcheck" as a 
> build option.
>
> Thanks
> Athira
>
> >
> > Thanks,
> > Ian
> >
>  On 23-Sep-2022, at 11:54 AM, Adrian Hunter  
>  wrote:
> 
>  On 22/09/22 22:15, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Sep 21, 2022 at 10:38:38PM +0530, Athira Rajeev escreveu:
> >> The perf test named “build id cache operations” skips with below
> >> error on some distros:
> >
> > I wonder if we shouldn't instead state that bash is needed?
> >
> > ⬢[acme@toolbox perf-urgent]$ head -1 tools/perf/tests/shell/*.sh | grep 
> > ^#
> > #!/bin/sh
> > #!/bin/bash
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/bash
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/bash
> > #!/bin/sh
> > #!/bin/bash
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > #!/bin/sh
> > ⬢[acme@toolbox perf-urgent]$
> >
> > Opinions?
> >
> 
>  Please don't change tools/perf/tests/shell/test_intel_pt.sh
> 
>  I started using shellcheck on that with the "perf test:
>  test_intel_pt.sh: Add per-thread test" patch set that I sent.
> 
>  FYI, if you use shellcheck on buildid.sh, it shows up issues even
>  after changing to bash:
> 
>  *** Before ***
> 
>  $ shellcheck -S warning tools/perf/tests/shell/buildid.sh
> 
>  In tools/perf/tests/shell/buildid.sh line 69:
>   link=${build_id_dir}/.build-id/${id:0:2}/${id:2}
>  ^---^ SC2039: In POSIX sh, 
>  string indexing is undefined.
>    ^-^ SC2039: In POSIX 
>  sh, string indexing is undefined.
> 
> 
>  In tools/perf/tests/shell/buildid.sh line 77:
>   file=${build_id_dir}/.build-id/${id:0:2}/`readlink ${link}`/elf
>  ^---^ SC2039: In POSIX sh, 
>  string indexing is undefined.
> 
> 
>  In tools/perf/tests/shell/buildid.sh line 123:
>   echo "running: perf record $@"
>  ^-- SC2145: Argument mixes string and 
>  array. Use * or separate argument.
> 
> 
>  In tools/perf/tests/shell/buildid.sh line 124:
>   ${perf} record --buildid-all -o ${data} $@ &> ${log}
>   ^-- SC2068: Double quote 
>  array expansions to avoid re-splitting elements.
>  ^---^ SC2039: In 
>  POSIX sh, &> is undefined.
> 
> 
>  In tools/perf/tests/shell/buildid.sh line 126:
>   echo "failed: record $@"
>    ^-- SC2145: Argument mixes string and 
>  array. Use * or separate argument.
> 
> 
>  In tools/perf/tests/shell/buildid.sh line 131:
>   check ${@: -1}
> ^--^ 

Re: [PATCH v3 00/51] cpuidle,rcu: Clean up the mess

[Mark Rutland]

On Thu, Jan 12, 2023 at 08:43:14PM +0100, Peter Zijlstra wrote:
> Hi All!

Hi Peter,

> The (hopefully) final respin of cpuidle vs rcu cleanup patches. Barring any
> objections I'll be queueing these patches in tip/sched/core in the next few
> days.

I'm sorry to have to bear some bad news on that front. :(

I just had a go at testing this on a Juno dev board, using your queue.git
sched/idle branch and defconfig + CONFIG_PROVE_LOCKING=y +
CONFIG_DEBUG_LOCKDEP=y + CONFIG_DEBUG_ATOMIC_SLEEP=y.

With that I consistently see RCU at boot time (log below).

| =
| WARNING: suspicious RCU usage
| 6.2.0-rc3-00051-gced9b6eecb31 #1 Not tainted
| -
| include/trace/events/ipi.h:19 suspicious rcu_dereference_check() usage!
| 
| other info that might help us debug this:
| 
| 
| rcu_scheduler_active = 2, debug_locks = 1
| RCU used illegally from extended quiescent state!
| no locks held by swapper/0/0.
| 
| stack backtrace:
| CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.2.0-rc3-00051-gced9b6eecb31 #1
| Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development 
Platform, BIOS EDK II May 16 2021
| Call trace:
|  dump_backtrace.part.0+0xe4/0xf0
|  show_stack+0x18/0x30
|  dump_stack_lvl+0x98/0xd4
|  dump_stack+0x18/0x34
|  lockdep_rcu_suspicious+0xf8/0x10c
|  trace_ipi_raise+0x1a8/0x1b0
|  arch_irq_work_raise+0x4c/0x70
|  __irq_work_queue_local+0x48/0x80
|  irq_work_queue+0x50/0x80
|  __wake_up_klogd.part.0+0x98/0xe0
|  defer_console_output+0x20/0x30
|  vprintk+0x98/0xf0
|  _printk+0x5c/0x84
|  lockdep_rcu_suspicious+0x34/0x10c
|  trace_lock_acquire+0x174/0x180
|  lock_acquire+0x3c/0x8c
|  _raw_spin_lock_irqsave+0x70/0x150
|  down_trylock+0x18/0x50
|  __down_trylock_console_sem+0x3c/0xd0
|  console_trylock+0x28/0x90
|  vprintk_emit+0x11c/0x354
|  vprintk_default+0x38/0x4c
|  vprintk+0xd4/0xf0
|  _printk+0x5c/0x84
|  lockdep_rcu_suspicious+0x34/0x10c
|  printk_sprint+0x238/0x240
|  vprintk_store+0x32c/0x4b0
|  vprintk_emit+0x104/0x354
|  vprintk_default+0x38/0x4c
|  vprintk+0xd4/0xf0
|  _printk+0x5c/0x84
|  lockdep_rcu_suspicious+0x34/0x10c
|  trace_irq_disable+0x1ac/0x1b0
|  trace_hardirqs_off+0xe8/0x110
|  cpu_suspend+0x4c/0xfc
|  psci_cpu_suspend_enter+0x58/0x6c
|  psci_enter_idle_state+0x70/0x170
|  cpuidle_enter_state+0xc4/0x464
|  cpuidle_enter+0x38/0x50
|  do_idle+0x230/0x2c0
|  cpu_startup_entry+0x24/0x30
|  rest_init+0x110/0x190
|  arch_post_acpi_subsys_init+0x0/0x18
|  start_kernel+0x6f8/0x738
|  __primary_switched+0xbc/0xc4

IIUC what's happenign here is the PSCI cpuidle driver has entered idle and RCU
is no longer watching when arm64's cpu_suspend() manipulates DAIF. Our
local_daif_*() helpers poke lockdep and tracing, hence the call to
trace_hardirqs_off() and the RCU usage.

I think we need RCU to be watching all the way down to cpu_suspend(), and it's
cpu_suspend() that should actually enter/exit idle context. That and we need to
make cpu_suspend() and the low-level PSCI invocation noinstr.

I'm not sure whether 32-bit will have a similar issue or not.

I'm surprised no-one else who has tested has seen this; I suspect people
haven't enabled lockdep and friends. :/

Thanks,
Mark. 

Re: [PATCH v2 1/2] powerpc/ps3: Change updateboltedpp panic to info

[Geoff Levand]

Hi,

On 1/15/23 16:06, Michael Ellerman wrote:
> Geoff Levand  writes:
>> On 1/9/23 09:41, Christophe Leroy wrote:
>>>
>>>
>>> Le 03/01/2023 à 18:51, Geoff Levand a écrit :
 Commit fdacae8a84024474afff234bdd1dbe19ad597a10 (powerpc: Activate
 CONFIG_STRICT_KERNEL_RWX by default) causes ps3_hpte_updateboltedpp()
 to be called.  Change the panic statment in ps3_hpte_updateboltedpp()
 to a pr_info statement so that bootup can continue.
>>>
>>> But if I understand correctly, it means that CONFIG_STRICT_KERNEL_RWX 
>>> won't work then.
>>>
>>> So, shouldn't we keep the panic and forbid CONFIG_STRICT_KERNEL_RWX on PS3 ?
>>
>> mmu_hash_ops.updateboltedpp returns void, so I can't return an error code to
>> indicate the feature is not supported.
> 
> We could change that in the medium term.
> 
>> I could do something like this in arch/powerpc/Kconfig:
>>
>> -   select ARCH_HAS_STRICT_KERNEL_RWX   if (PPC_BOOK3S || PPC_8xx || 
>> 40x) && !HIBERNATION
>> +   select ARCH_HAS_STRICT_KERNEL_RWX   if (PPC_BOOK3S || PPC_8xx || 
>> 40x) && !PPC_PS3 && !HIBERNATION
>>
>> But then the ppc64_defconfig would be built without STRICT_KERNEL_RWX.
> 
> Yeah that would be a pity.
> 
> We could do the above and disable PS3 in ppc64_defconfig, allowing
> ppc64_defconfig to still have STRICT_KERNEL_RWX.

I really want to keep PS3 included in ppc64_defconfig.  Not that I expect
anyone to boot a ppc64_defconfig kernel on PS3, but that is one of the
'standard' configs that is built by some automated builders, and generally by
anyone doing changes to the powerpc arch, and I want to keep getting those
build tests for PS3.

> I assume actual PS3 users would use a ps3_defconfig anyway right?

Yeah, a derivative of it.  They are most likely are using 'Jailbreak' firmware
that allows them to run Linux in the gameos partition.

> Relatedly are there any actual PS3 users left? ;)

It seems there are more users now than a few years ago.  I think they buy PS5s
to play the latest games, and use their old console to mess around with Linux.
I generally get a private inquiry every 3 or 4 weeks.  Usually asking how to
update their kernel, or how to install a modern distro.

>> What other 'clean' way is there?
> 
> If we want to have a multi-platform kernel image that can boot on PS3
> and other platforms, and have strict kernel RWX, then we need some
> runtime logic to deal with that.
> 
> I'd rather not do that though, because it adds complexity to deal with a
> pretty obscure corner case, and I suspect no one really boots a
> ppc64_defconfig on actual PS3 hardware these days.
> 
> So my preference is we disable PS3 in ppc64_defconfig, and make PS3
> incompatible with STRICT_KERNEL_RWX.

As mentioned, I'd really like to keep PS3 included in ppc64_defconfig.  My
original patch that basically just ignores the call to
mmu_hash_ops.updateboltedpp allows that, and I haven't experienced any problems
with it yet.

My preference would be to keep PS3 in ppc64_defconfig, and either apply my
original patch, or I keep that patch in my ps3-linux repo on kernel.org. Then,
if we end up adding runtime support for RWX I then fixup PS3 to use that.

-Geoff

Re: Memory transaction instructions

[Linus Torvalds]

On Mon, Jan 16, 2023 at 6:08 AM David Howells  wrote:
>
> I'm not sure how relevant it is to the topic, but I seem to remember you
> having a go at implementing spinlocks with x86_64 memory transaction
> instructions a while back.  Do you have any thoughts on whether these
> instructions are ever likely to become something we can use?

Nope.

Not only are they buggy, the actual cost of them was prohibitive too.

The only implementation I ever did was what then became 'lockref' (so
this was about a decade ago), and using transactional memory was
actually quite noticeably *slower* than just using a spinlock in the
common cases (particularly the uncontended case - which is actually
the common one by far, despite some benchmarks).

And while the argument could be that transactional memory has improved
in the last decade (narrator: "It hasn't"), the problem is actually
quite fundamental.

The whole "best case scenario" for transactional memory concept is
literally optimized and designed for the rare circumstance - the case
where you have contention, but where the locking part is basically an
idempotent operation (so "lock+unlock" ends up undoing each other and
can use shared cachelines rather than bouncing the cacheline).

And contention pretty much happens in one situation, and one situation
only: in a combination of (a) bad locking and (b) benchmarks.

And for the kernel, where we don't have bad locking, and where we
actually use fine-grained locks that are _near_ the data that we are
locking (the lockref of the dcache is obviously one example of that,
but the skbuff queue you mention is almost certainly exactly the same
situation): the lock is right by the data that the lock protects, and
the "shared lock cacheline" model simply does not work. You'll bounce
the data, and most likely you'll also touch the same lock cacheline
too.

I was quite excited about transactional memory, but have (obviously)
come to the conclusion that it was one of those "looks good in theory,
but is just garbage in reality".

So this isn't an "the x86 implementation was bad" issue. This is a
"transactional memory is a bad idea" situation. It complicates the
most important part of the core CPU (the memory pipeline) enormously,
and it doesn't actually really work.

Now, with that "transactional memory is garbage" in mind, let me just
mention that there are obviously other circumstances:

 (a) horrendously bad locking

If you have a single centralized lock, and you really have serious
contention on it in real life all the time (and not just under
microbenchmarks), and the data that gets touched is spread out all
over, and you simply cannot fix the locking, then all those
theoretical advantages of transactional memory can actually come into
play.

But again: even then, there's an absolutely huge cost to the memory
pipeline.  So that advantage really doesn't come free. Nobody has ever
gotten transactional memory to actually work well in real life. Not
Intel, not IBM with powerpc HTM.

That should tell you something. The hw complexity cost is very very real.

But Intel actually had some loads where TSX helped. I think it was SAP
HANA, and I really think that what you should take away from that is
that SAP HANA locking is likely horrible garbage inside. But maybe I'm
biased, and maybe SAP HANA is lovely, and maybe it just happened to
work really well for TSX. I've never actually looked at that load, but
if I were a betting man...

 (b) very *limited* transactions are probably a great idea

LL/SC is arguably a form of "transactional memory", just with a single
word. Now, I think atomics are generally usually better than LL/SC
when it really is just a single word (because most of the time,
"single word" also means "simple semantics", and while CMPXCHG loops
aren't lovely when the semantics are a bit more complex, it's actually
nice and portable and works at a higher level than assembler sequences
and as such is actually a *lot* better than LL/SC in practice).

But a "N-word LL/SC with forward progress guarantees" would be
objectively stronger than atomics, and would allow for doing low-level
data structures in ways that atomics don't. Doubly linked lists
together with a lock check would argue for "N" being ~5 memory
operations. So I do believe in potentially *limited* memory
transactions, when they can be made limited enough that you have

 (1) forward progress guarantees with no "separate fallback on
contention" garbage

 (2) can keep the hw implementation simple enough with just a store
buffer and an (architecturally) very limited number of cacheline
accesses that you can actually order in HW so that you don't have ABBA
situations.

But the generic kind of transactional memory that Intel tried with TSX
(and IBM with HTM) is pure garbage, and almost certainly always will
be.

And all of the above is obviously just my opinionated input on it. But
I just happen to be right.

Linus

Re: Memory transaction instructions

[Matthew Wilcox]

On Mon, Jan 16, 2023 at 02:08:15PM +, David Howells wrote:
> Hi Linus,
> 
> I'm not sure how relevant it is to the topic, but I seem to remember you
> having a go at implementing spinlocks with x86_64 memory transaction
> instructions a while back.  Do you have any thoughts on whether these
> instructions are ever likely to become something we can use?

Ever is a long time, but not while they're still buggy:

https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions

and not while they're not actually available on a vast majority of
x86 hardware.  ie AMD needs to implement them, make them available as
standard, forcing Intel to enable them globally instead of restricting
them to those who pay the $2.50/month subscription fee.

Re: [PATCH 1/1] ASoC: fsl_sai: Use dev_err_probe

[Mark Brown]

On Wed, 11 Jan 2023 17:11:44 +0100, Alexander Stein wrote:
> This helps figuring out why the device probe is deferred, e.g. missing
> FSL_EDMA driver.
> 
> 

Applied to

   broonie/sound.git for-next

Thanks!

[1/1] ASoC: fsl_sai: Use dev_err_probe
  commit: aea11bcddcafc7f548c4fa574cb6019e7690008d

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH] ASoC: fsl_sai: initialize is_dsp_mode flag

[Mark Brown]

On Mon, 16 Jan 2023 15:07:54 +0800, Shengjiu Wang wrote:
> Initialize is_dsp_mode flag in the beginning of function
> fsl_sai_set_dai_fmt_tr().
> 
> When the DAIFMT is DAIFMT_DSP_B the first time, is_dsp_mode is
> true, then the second time DAIFMT is DAIFMT_I2S, is_dsp_mode
> still true, which is a wrong state. So need to initialize
> is_dsp_mode flag every time.
> 
> [...]

Applied to

   broonie/sound.git for-next

Thanks!

[1/1] ASoC: fsl_sai: initialize is_dsp_mode flag
  commit: a23924b7dd7b748fff8e305e1daf590fed2af21b

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Memory transaction instructions

[David Howells]

Hi Linus,

I'm not sure how relevant it is to the topic, but I seem to remember you
having a go at implementing spinlocks with x86_64 memory transaction
instructions a while back.  Do you have any thoughts on whether these
instructions are ever likely to become something we can use?

I was looking specifically at the skbuff queue stuff which does {
spin_lock_irq, add to list, inc count, spin_unlock_irq } and thinking that
might be a good place to use such a thing.

David

[PATCH AUTOSEL 5.4 07/16] ASoC: fsl_ssi: Rename AC'97 streams to avoid collisions with AC'97 CODEC

[Sasha Levin]

From: Mark Brown 

[ Upstream commit 8c6a42b5b0ed6f96624f56954e93eeae107440a6 ]

The SSI driver calls the AC'97 playback and transmit streams "AC97 Playback"
and "AC97 Capture" respectively. This is the same name used by the generic
AC'97 CODEC driver in ASoC, creating confusion for the Freescale ASoC card
when it attempts to use these widgets in routing. Add a "CPU" in the name
like the regular DAIs registered by the driver to disambiguate.

Acked-by: Shengjiu Wang 
Signed-off-by: Mark Brown 
Link: 
https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-1-a5d7469d4...@kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 8 
 sound/soc/fsl/fsl_ssi.c   | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 39ea9bda1394..d78eb9f9d24c 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -112,11 +112,11 @@ static const struct snd_soc_dapm_route audio_map[] = {
 
 static const struct snd_soc_dapm_route audio_map_ac97[] = {
/* 1st half -- Normal DAPM routes */
-   {"Playback",  NULL, "AC97 Playback"},
-   {"AC97 Capture",  NULL, "Capture"},
+   {"Playback",  NULL, "CPU AC97 Playback"},
+   {"CPU AC97 Capture",  NULL, "Capture"},
/* 2nd half -- ASRC DAPM routes */
-   {"AC97 Playback",  NULL, "ASRC-Playback"},
-   {"ASRC-Capture",  NULL, "AC97 Capture"},
+   {"CPU AC97 Playback",  NULL, "ASRC-Playback"},
+   {"ASRC-Capture",  NULL, "CPU AC97 Capture"},
 };
 
 /* Add all possible widgets into here without being redundant */
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index ed18bc69e095..0ab35c3dc7d2 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1147,14 +1147,14 @@ static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
.symmetric_channels = 1,
.probe = fsl_ssi_dai_probe,
.playback = {
-   .stream_name = "AC97 Playback",
+   .stream_name = "CPU AC97 Playback",
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_48000,
.formats = SNDRV_PCM_FMTBIT_S16 | SNDRV_PCM_FMTBIT_S20,
},
.capture = {
-   .stream_name = "AC97 Capture",
+   .stream_name = "CPU AC97 Capture",
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_48000,
-- 
2.35.1

[PATCH AUTOSEL 5.4 08/16] ASoC: fsl-asoc-card: Fix naming of AC'97 CODEC widgets

[Sasha Levin]

From: Mark Brown 

[ Upstream commit 242fc66ae6e1e2b8519daacc7590a73cd0e8a6e4 ]

The fsl-asoc-card AC'97 support currently tries to route to Playback and
Capture widgets provided by the AC'97 CODEC. This doesn't work since the
generic AC'97 driver registers with an "AC97" at the front of the stream
and hence widget names, update to reflect reality. It's not clear to me
if or how this ever worked.

Acked-by: Shengjiu Wang 
Signed-off-by: Mark Brown 
Link: 
https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-2-a5d7469d4...@kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index d78eb9f9d24c..db663e7d17a4 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -112,8 +112,8 @@ static const struct snd_soc_dapm_route audio_map[] = {
 
 static const struct snd_soc_dapm_route audio_map_ac97[] = {
/* 1st half -- Normal DAPM routes */
-   {"Playback",  NULL, "CPU AC97 Playback"},
-   {"CPU AC97 Capture",  NULL, "Capture"},
+   {"AC97 Playback",  NULL, "CPU AC97 Playback"},
+   {"CPU AC97 Capture",  NULL, "AC97 Capture"},
/* 2nd half -- ASRC DAPM routes */
{"CPU AC97 Playback",  NULL, "ASRC-Playback"},
{"ASRC-Capture",  NULL, "CPU AC97 Capture"},
-- 
2.35.1

[PATCH AUTOSEL 5.4 02/16] ASoC: fsl_micfil: Correct the number of steps on SX controls

[Sasha Levin]

From: Chancel Liu 

[ Upstream commit cdfa92eb90f5770b26a79824ef213ebdbbd988b1 ]

The parameter "max" of SOC_SINGLE_SX_TLV() means the number of steps
rather than maximum value. This patch corrects the minimum value to -8
and the number of steps to 15.

Signed-off-by: Chancel Liu 
Acked-by: Shengjiu Wang 
Link: https://lore.kernel.org/r/20230104025754.3019235-1-chancel@nxp.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl_micfil.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
index f7f2d29f1bfe..b33746d58633 100644
--- a/sound/soc/fsl/fsl_micfil.c
+++ b/sound/soc/fsl/fsl_micfil.c
@@ -87,21 +87,21 @@ static DECLARE_TLV_DB_SCALE(gain_tlv, 0, 100, 0);
 
 static const struct snd_kcontrol_new fsl_micfil_snd_controls[] = {
SOC_SINGLE_SX_TLV("CH0 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(0), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(0), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH1 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(1), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(1), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH2 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(2), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(2), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH3 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(3), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(3), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH4 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(4), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(4), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH5 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(5), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(5), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH6 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(6), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(6), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH7 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(7), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(7), 0x8, 0xF, gain_tlv),
SOC_ENUM_EXT("MICFIL Quality Select",
 fsl_micfil_quality_enum,
 snd_soc_get_enum_double, snd_soc_put_enum_double),
-- 
2.35.1

[PATCH AUTOSEL 5.10 10/17] ASoC: fsl-asoc-card: Fix naming of AC'97 CODEC widgets

[Sasha Levin]

From: Mark Brown 

[ Upstream commit 242fc66ae6e1e2b8519daacc7590a73cd0e8a6e4 ]

The fsl-asoc-card AC'97 support currently tries to route to Playback and
Capture widgets provided by the AC'97 CODEC. This doesn't work since the
generic AC'97 driver registers with an "AC97" at the front of the stream
and hence widget names, update to reflect reality. It's not clear to me
if or how this ever worked.

Acked-by: Shengjiu Wang 
Signed-off-by: Mark Brown 
Link: 
https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-2-a5d7469d4...@kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 8c976fde44f0..9a756d0a6032 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -117,8 +117,8 @@ static const struct snd_soc_dapm_route audio_map[] = {
 
 static const struct snd_soc_dapm_route audio_map_ac97[] = {
/* 1st half -- Normal DAPM routes */
-   {"Playback",  NULL, "CPU AC97 Playback"},
-   {"CPU AC97 Capture",  NULL, "Capture"},
+   {"AC97 Playback",  NULL, "CPU AC97 Playback"},
+   {"CPU AC97 Capture",  NULL, "AC97 Capture"},
/* 2nd half -- ASRC DAPM routes */
{"CPU AC97 Playback",  NULL, "ASRC-Playback"},
{"ASRC-Capture",  NULL, "CPU AC97 Capture"},
-- 
2.35.1

[PATCH AUTOSEL 5.10 09/17] ASoC: fsl_ssi: Rename AC'97 streams to avoid collisions with AC'97 CODEC

[Sasha Levin]

From: Mark Brown 

[ Upstream commit 8c6a42b5b0ed6f96624f56954e93eeae107440a6 ]

The SSI driver calls the AC'97 playback and transmit streams "AC97 Playback"
and "AC97 Capture" respectively. This is the same name used by the generic
AC'97 CODEC driver in ASoC, creating confusion for the Freescale ASoC card
when it attempts to use these widgets in routing. Add a "CPU" in the name
like the regular DAIs registered by the driver to disambiguate.

Acked-by: Shengjiu Wang 
Signed-off-by: Mark Brown 
Link: 
https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-1-a5d7469d4...@kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 8 
 sound/soc/fsl/fsl_ssi.c   | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 7cd14d6b9436..8c976fde44f0 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -117,11 +117,11 @@ static const struct snd_soc_dapm_route audio_map[] = {
 
 static const struct snd_soc_dapm_route audio_map_ac97[] = {
/* 1st half -- Normal DAPM routes */
-   {"Playback",  NULL, "AC97 Playback"},
-   {"AC97 Capture",  NULL, "Capture"},
+   {"Playback",  NULL, "CPU AC97 Playback"},
+   {"CPU AC97 Capture",  NULL, "Capture"},
/* 2nd half -- ASRC DAPM routes */
-   {"AC97 Playback",  NULL, "ASRC-Playback"},
-   {"ASRC-Capture",  NULL, "AC97 Capture"},
+   {"CPU AC97 Playback",  NULL, "ASRC-Playback"},
+   {"ASRC-Capture",  NULL, "CPU AC97 Capture"},
 };
 
 static const struct snd_soc_dapm_route audio_map_tx[] = {
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 1d774c876c52..94229ce1a30e 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1161,14 +1161,14 @@ static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
.symmetric_channels = 1,
.probe = fsl_ssi_dai_probe,
.playback = {
-   .stream_name = "AC97 Playback",
+   .stream_name = "CPU AC97 Playback",
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_48000,
.formats = SNDRV_PCM_FMTBIT_S16 | SNDRV_PCM_FMTBIT_S20,
},
.capture = {
-   .stream_name = "AC97 Capture",
+   .stream_name = "CPU AC97 Capture",
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_48000,
-- 
2.35.1

[PATCH AUTOSEL 5.10 04/17] ASoC: fsl_micfil: Correct the number of steps on SX controls

[Sasha Levin]

From: Chancel Liu 

[ Upstream commit cdfa92eb90f5770b26a79824ef213ebdbbd988b1 ]

The parameter "max" of SOC_SINGLE_SX_TLV() means the number of steps
rather than maximum value. This patch corrects the minimum value to -8
and the number of steps to 15.

Signed-off-by: Chancel Liu 
Acked-by: Shengjiu Wang 
Link: https://lore.kernel.org/r/20230104025754.3019235-1-chancel@nxp.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl_micfil.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
index 6c794605e33c..97f83c63e765 100644
--- a/sound/soc/fsl/fsl_micfil.c
+++ b/sound/soc/fsl/fsl_micfil.c
@@ -87,21 +87,21 @@ static DECLARE_TLV_DB_SCALE(gain_tlv, 0, 100, 0);
 
 static const struct snd_kcontrol_new fsl_micfil_snd_controls[] = {
SOC_SINGLE_SX_TLV("CH0 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(0), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(0), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH1 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(1), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(1), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH2 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(2), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(2), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH3 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(3), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(3), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH4 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(4), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(4), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH5 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(5), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(5), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH6 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(6), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(6), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH7 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(7), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(7), 0x8, 0xF, gain_tlv),
SOC_ENUM_EXT("MICFIL Quality Select",
 fsl_micfil_quality_enum,
 snd_soc_get_enum_double, snd_soc_put_enum_double),
-- 
2.35.1

[PATCH AUTOSEL 5.15 14/24] ASoC: fsl_ssi: Rename AC'97 streams to avoid collisions with AC'97 CODEC

[Sasha Levin]

From: Mark Brown 

[ Upstream commit 8c6a42b5b0ed6f96624f56954e93eeae107440a6 ]

The SSI driver calls the AC'97 playback and transmit streams "AC97 Playback"
and "AC97 Capture" respectively. This is the same name used by the generic
AC'97 CODEC driver in ASoC, creating confusion for the Freescale ASoC card
when it attempts to use these widgets in routing. Add a "CPU" in the name
like the regular DAIs registered by the driver to disambiguate.

Acked-by: Shengjiu Wang 
Signed-off-by: Mark Brown 
Link: 
https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-1-a5d7469d4...@kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 8 
 sound/soc/fsl/fsl_ssi.c   | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index c72a156737e6..978496c2fc09 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -120,11 +120,11 @@ static const struct snd_soc_dapm_route audio_map[] = {
 
 static const struct snd_soc_dapm_route audio_map_ac97[] = {
/* 1st half -- Normal DAPM routes */
-   {"Playback",  NULL, "AC97 Playback"},
-   {"AC97 Capture",  NULL, "Capture"},
+   {"Playback",  NULL, "CPU AC97 Playback"},
+   {"CPU AC97 Capture",  NULL, "Capture"},
/* 2nd half -- ASRC DAPM routes */
-   {"AC97 Playback",  NULL, "ASRC-Playback"},
-   {"ASRC-Capture",  NULL, "AC97 Capture"},
+   {"CPU AC97 Playback",  NULL, "ASRC-Playback"},
+   {"ASRC-Capture",  NULL, "CPU AC97 Capture"},
 };
 
 static const struct snd_soc_dapm_route audio_map_tx[] = {
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index ecbc1c365d5b..0c73c2e9dce0 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1160,14 +1160,14 @@ static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
.symmetric_channels = 1,
.probe = fsl_ssi_dai_probe,
.playback = {
-   .stream_name = "AC97 Playback",
+   .stream_name = "CPU AC97 Playback",
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_48000,
.formats = SNDRV_PCM_FMTBIT_S16 | SNDRV_PCM_FMTBIT_S20,
},
.capture = {
-   .stream_name = "AC97 Capture",
+   .stream_name = "CPU AC97 Capture",
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_48000,
-- 
2.35.1

[PATCH AUTOSEL 5.15 15/24] ASoC: fsl-asoc-card: Fix naming of AC'97 CODEC widgets

[Sasha Levin]

From: Mark Brown 

[ Upstream commit 242fc66ae6e1e2b8519daacc7590a73cd0e8a6e4 ]

The fsl-asoc-card AC'97 support currently tries to route to Playback and
Capture widgets provided by the AC'97 CODEC. This doesn't work since the
generic AC'97 driver registers with an "AC97" at the front of the stream
and hence widget names, update to reflect reality. It's not clear to me
if or how this ever worked.

Acked-by: Shengjiu Wang 
Signed-off-by: Mark Brown 
Link: 
https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-2-a5d7469d4...@kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 978496c2fc09..5000d779aade 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -120,8 +120,8 @@ static const struct snd_soc_dapm_route audio_map[] = {
 
 static const struct snd_soc_dapm_route audio_map_ac97[] = {
/* 1st half -- Normal DAPM routes */
-   {"Playback",  NULL, "CPU AC97 Playback"},
-   {"CPU AC97 Capture",  NULL, "Capture"},
+   {"AC97 Playback",  NULL, "CPU AC97 Playback"},
+   {"CPU AC97 Capture",  NULL, "AC97 Capture"},
/* 2nd half -- ASRC DAPM routes */
{"CPU AC97 Playback",  NULL, "ASRC-Playback"},
{"ASRC-Capture",  NULL, "CPU AC97 Capture"},
-- 
2.35.1

[PATCH AUTOSEL 5.15 05/24] ASoC: fsl_micfil: Correct the number of steps on SX controls

[Sasha Levin]

From: Chancel Liu 

[ Upstream commit cdfa92eb90f5770b26a79824ef213ebdbbd988b1 ]

The parameter "max" of SOC_SINGLE_SX_TLV() means the number of steps
rather than maximum value. This patch corrects the minimum value to -8
and the number of steps to 15.

Signed-off-by: Chancel Liu 
Acked-by: Shengjiu Wang 
Link: https://lore.kernel.org/r/20230104025754.3019235-1-chancel@nxp.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl_micfil.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
index d1cd104f8584..38d4d1b7cfe3 100644
--- a/sound/soc/fsl/fsl_micfil.c
+++ b/sound/soc/fsl/fsl_micfil.c
@@ -88,21 +88,21 @@ static DECLARE_TLV_DB_SCALE(gain_tlv, 0, 100, 0);
 
 static const struct snd_kcontrol_new fsl_micfil_snd_controls[] = {
SOC_SINGLE_SX_TLV("CH0 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(0), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(0), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH1 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(1), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(1), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH2 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(2), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(2), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH3 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(3), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(3), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH4 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(4), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(4), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH5 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(5), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(5), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH6 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(6), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(6), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH7 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(7), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(7), 0x8, 0xF, gain_tlv),
SOC_ENUM_EXT("MICFIL Quality Select",
 fsl_micfil_quality_enum,
 snd_soc_get_enum_double, snd_soc_put_enum_double),
-- 
2.35.1

[PATCH AUTOSEL 6.1 32/53] ASoC: fsl_ssi: Rename AC'97 streams to avoid collisions with AC'97 CODEC

[Sasha Levin]

From: Mark Brown 

[ Upstream commit 8c6a42b5b0ed6f96624f56954e93eeae107440a6 ]

The SSI driver calls the AC'97 playback and transmit streams "AC97 Playback"
and "AC97 Capture" respectively. This is the same name used by the generic
AC'97 CODEC driver in ASoC, creating confusion for the Freescale ASoC card
when it attempts to use these widgets in routing. Add a "CPU" in the name
like the regular DAIs registered by the driver to disambiguate.

Acked-by: Shengjiu Wang 
Signed-off-by: Mark Brown 
Link: 
https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-1-a5d7469d4...@kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 8 
 sound/soc/fsl/fsl_ssi.c   | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index c836848ef0a6..1dfd0341e487 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -121,11 +121,11 @@ static const struct snd_soc_dapm_route audio_map[] = {
 
 static const struct snd_soc_dapm_route audio_map_ac97[] = {
/* 1st half -- Normal DAPM routes */
-   {"Playback",  NULL, "AC97 Playback"},
-   {"AC97 Capture",  NULL, "Capture"},
+   {"Playback",  NULL, "CPU AC97 Playback"},
+   {"CPU AC97 Capture",  NULL, "Capture"},
/* 2nd half -- ASRC DAPM routes */
-   {"AC97 Playback",  NULL, "ASRC-Playback"},
-   {"ASRC-Capture",  NULL, "AC97 Capture"},
+   {"CPU AC97 Playback",  NULL, "ASRC-Playback"},
+   {"ASRC-Capture",  NULL, "CPU AC97 Capture"},
 };
 
 static const struct snd_soc_dapm_route audio_map_tx[] = {
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index c9e0e31d5b34..46a53551b955 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1189,14 +1189,14 @@ static struct snd_soc_dai_driver fsl_ssi_ac97_dai = {
.symmetric_channels = 1,
.probe = fsl_ssi_dai_probe,
.playback = {
-   .stream_name = "AC97 Playback",
+   .stream_name = "CPU AC97 Playback",
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_8000_48000,
.formats = SNDRV_PCM_FMTBIT_S16 | SNDRV_PCM_FMTBIT_S20,
},
.capture = {
-   .stream_name = "AC97 Capture",
+   .stream_name = "CPU AC97 Capture",
.channels_min = 2,
.channels_max = 2,
.rates = SNDRV_PCM_RATE_48000,
-- 
2.35.1

[PATCH AUTOSEL 6.1 33/53] ASoC: fsl-asoc-card: Fix naming of AC'97 CODEC widgets

[Sasha Levin]

From: Mark Brown 

[ Upstream commit 242fc66ae6e1e2b8519daacc7590a73cd0e8a6e4 ]

The fsl-asoc-card AC'97 support currently tries to route to Playback and
Capture widgets provided by the AC'97 CODEC. This doesn't work since the
generic AC'97 driver registers with an "AC97" at the front of the stream
and hence widget names, update to reflect reality. It's not clear to me
if or how this ever worked.

Acked-by: Shengjiu Wang 
Signed-off-by: Mark Brown 
Link: 
https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-2-a5d7469d4...@kernel.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl-asoc-card.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 1dfd0341e487..8d14b5593658 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -121,8 +121,8 @@ static const struct snd_soc_dapm_route audio_map[] = {
 
 static const struct snd_soc_dapm_route audio_map_ac97[] = {
/* 1st half -- Normal DAPM routes */
-   {"Playback",  NULL, "CPU AC97 Playback"},
-   {"CPU AC97 Capture",  NULL, "Capture"},
+   {"AC97 Playback",  NULL, "CPU AC97 Playback"},
+   {"CPU AC97 Capture",  NULL, "AC97 Capture"},
/* 2nd half -- ASRC DAPM routes */
{"CPU AC97 Playback",  NULL, "ASRC-Playback"},
{"ASRC-Capture",  NULL, "CPU AC97 Capture"},
-- 
2.35.1

[PATCH AUTOSEL 6.1 15/53] ASoC: fsl_micfil: Correct the number of steps on SX controls

[Sasha Levin]

From: Chancel Liu 

[ Upstream commit cdfa92eb90f5770b26a79824ef213ebdbbd988b1 ]

The parameter "max" of SOC_SINGLE_SX_TLV() means the number of steps
rather than maximum value. This patch corrects the minimum value to -8
and the number of steps to 15.

Signed-off-by: Chancel Liu 
Acked-by: Shengjiu Wang 
Link: https://lore.kernel.org/r/20230104025754.3019235-1-chancel@nxp.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/fsl/fsl_micfil.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
index 4b86ef82fd93..4b8fe9b8be40 100644
--- a/sound/soc/fsl/fsl_micfil.c
+++ b/sound/soc/fsl/fsl_micfil.c
@@ -154,21 +154,21 @@ static int micfil_quality_set(struct snd_kcontrol 
*kcontrol,
 
 static const struct snd_kcontrol_new fsl_micfil_snd_controls[] = {
SOC_SINGLE_SX_TLV("CH0 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(0), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(0), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH1 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(1), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(1), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH2 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(2), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(2), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH3 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(3), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(3), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH4 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(4), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(4), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH5 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(5), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(5), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH6 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(6), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(6), 0x8, 0xF, gain_tlv),
SOC_SINGLE_SX_TLV("CH7 Volume", REG_MICFIL_OUT_CTRL,
- MICFIL_OUTGAIN_CHX_SHIFT(7), 0xF, 0x7, gain_tlv),
+ MICFIL_OUTGAIN_CHX_SHIFT(7), 0x8, 0xF, gain_tlv),
SOC_ENUM_EXT("MICFIL Quality Select",
 fsl_micfil_quality_enum,
 micfil_quality_get, micfil_quality_set),
-- 
2.35.1

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

[Matthew Wilcox]

On Mon, Jan 16, 2023 at 10:41:14AM +0100, John Paul Adrian Glaubitz wrote:
> On 1/15/23 01:27, Matthew Wilcox wrote:
> > More useful perhaps is to look at https://popcon.debian.org/
> > 
> > There are three machines reporting popcon results.  It's dead.
> 
> It's an opt-in mechanism that reports 190,000 machines running Debian
> on x86_64. Do you think that there are only 190,000 servers world-wide
> running Debian?

No.  I think there are so few ia64 machines still in operation that the
effort required to continue to support them is now too high relative
to the benefits.  We've dropped support for hardware that still exists
before, and we'll do it again.  The only question is when.

I still have two ia64 machines in my basement.  I've turned one of them
on once since 2009.  And that was because I had a bug I needed to track
down and fix (2018, commits 4b664e739f77 and 2879b65f9de8).

Re: [PATCH 1/2] tools/perf/tests: Fix string substitutions in build id test

[Athira Rajeev]

> On 16-Jan-2023, at 11:47 AM, Ian Rogers  wrote:
> 
> On Sun, Jan 15, 2023 at 9:03 PM Athira Rajeev
>  wrote:
>> 
>> 
>> 
>>> On 28-Sep-2022, at 10:24 AM, Athira Rajeev  
>>> wrote:
>>> 
>>> Hi All,
>>> 
>>> Looking for what direction we can take here.
>>> Do we want to change all tests in tools/perf/tests/shell except 
>>> test_intel_pt.sh to use "bash" or go with
>>> the approach in the patch ? Please share your comments
>>> 
>>> Thanks
>>> Athira
>>> 
>> 
>> Hi All,
>> 
>> Looking for what direction we can take here.
>> Do we want to change all tests in tools/perf/tests/shell except 
>> test_intel_pt.sh to use "bash" or go with
>> the approach in the patch ? Please share your comments
>> 
>> Thanks
>> Athira
> 

Thanks Ian for the response.

> I think some of what the patch is doing is good, some of it the

Ian, can I take this as an ack for the patch so that Arnaldo can pick this in 
acme git ?

> readability becomes a little harder by not being bash. I'm agnostic as
> to which approach to take for the fix.

May be we can take this as separate mail thread to get everyone’s opinion on 
changing all tests in "tools/perf/tests/shell" except test_intel_pt.sh to use 
“bash" ?

> 
> An aside, I noticed that we do run some tests at build time:
> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/lib/Makefile?h=perf/core#n390
> So perhaps we can have a shellcheck build option, defaulted off but
> enabled as part of Arnaldo's regular test scripts. The shellcheck
> build option would run shellcheck to make sure that there weren't
> errors in the shell code, which it is far too easy to introduce.

Sure, that is a good option to have. I will check on having “shellcheck" as a 
build option.

Thanks
Athira

> 
> Thanks,
> Ian
> 
 On 23-Sep-2022, at 11:54 AM, Adrian Hunter  wrote:
 
 On 22/09/22 22:15, Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 21, 2022 at 10:38:38PM +0530, Athira Rajeev escreveu:
>> The perf test named “build id cache operations” skips with below
>> error on some distros:
> 
> I wonder if we shouldn't instead state that bash is needed?
> 
> ⬢[acme@toolbox perf-urgent]$ head -1 tools/perf/tests/shell/*.sh | grep ^#
> #!/bin/sh
> #!/bin/bash
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/bash
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/bash
> #!/bin/sh
> #!/bin/bash
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> #!/bin/sh
> ⬢[acme@toolbox perf-urgent]$
> 
> Opinions?
> 
 
 Please don't change tools/perf/tests/shell/test_intel_pt.sh
 
 I started using shellcheck on that with the "perf test:
 test_intel_pt.sh: Add per-thread test" patch set that I sent.
 
 FYI, if you use shellcheck on buildid.sh, it shows up issues even
 after changing to bash:
 
 *** Before ***
 
 $ shellcheck -S warning tools/perf/tests/shell/buildid.sh
 
 In tools/perf/tests/shell/buildid.sh line 69:
  link=${build_id_dir}/.build-id/${id:0:2}/${id:2}
 ^---^ SC2039: In POSIX sh, string 
 indexing is undefined.
   ^-^ SC2039: In POSIX sh, 
 string indexing is undefined.
 
 
 In tools/perf/tests/shell/buildid.sh line 77:
  file=${build_id_dir}/.build-id/${id:0:2}/`readlink ${link}`/elf
 ^---^ SC2039: In POSIX sh, string 
 indexing is undefined.
 
 
 In tools/perf/tests/shell/buildid.sh line 123:
  echo "running: perf record $@"
 ^-- SC2145: Argument mixes string and 
 array. Use * or separate argument.
 
 
 In tools/perf/tests/shell/buildid.sh line 124:
  ${perf} record --buildid-all -o ${data} $@ &> ${log}
  ^-- SC2068: Double quote 
 array expansions to avoid re-splitting elements.
 ^---^ SC2039: In POSIX 
 sh, &> is undefined.
 
 
 In tools/perf/tests/shell/buildid.sh line 126:
  echo "failed: record $@"
   ^-- SC2145: Argument mixes string and 
 array. Use * or separate argument.
 
 
 In tools/perf/tests/shell/buildid.sh line 131:
  check ${@: -1}
^--^ SC2068: Double quote array expansions to avoid 
 re-splitting elements.
^--^ SC2039: In POSIX sh, string indexing is undefined.
 
 
 In tools/perf/tests/shell/buildid.sh line 158:
 exit ${err}
   ^^ SC2154: err is referenced but not assigned.
 
 For more information:
 https://www.shellcheck.net/wiki/SC2068 -- 

Re: [PATCH 41/41] mm: replace rw_semaphore with atomic_t in vma_lock

[Hyeonggon Yoo]

On Mon, Jan 09, 2023 at 12:53:36PM -0800, Suren Baghdasaryan wrote:
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index d40bf8a5e19e..294dd44b2198 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -627,12 +627,16 @@ static inline void vma_write_lock(struct vm_area_struct 
> *vma)
>* mm->mm_lock_seq can't be concurrently modified.
>*/
>   mm_lock_seq = READ_ONCE(vma->vm_mm->mm_lock_seq);
> - if (vma->vm_lock_seq == mm_lock_seq)
> + if (vma->vm_lock->lock_seq == mm_lock_seq)
>   return;
>  
> - down_write(>vm_lock->lock);
> - vma->vm_lock_seq = mm_lock_seq;
> - up_write(>vm_lock->lock);
> + if (atomic_cmpxchg(>vm_lock->count, 0, -1))
> + wait_event(vma->vm_mm->vma_writer_wait,
> +atomic_cmpxchg(>vm_lock->count, 0, -1) == 0);
> + vma->vm_lock->lock_seq = mm_lock_seq;
> + /* Write barrier to ensure lock_seq change is visible before count */
> + smp_wmb();
> + atomic_set(>vm_lock->count, 0);
>  }
>  
>  /*
> @@ -643,20 +647,28 @@ static inline void vma_write_lock(struct vm_area_struct 
> *vma)
>  static inline bool vma_read_trylock(struct vm_area_struct *vma)
>  {
>   /* Check before locking. A race might cause false locked result. */
> - if (vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
> + if (vma->vm_lock->lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))
>   return false;
>  
> - if (unlikely(down_read_trylock(>vm_lock->lock) == 0))
> + if (unlikely(!atomic_inc_unless_negative(>vm_lock->count)))
>   return false;
>  
> + /* If atomic_t overflows, restore and fail to lock. */
> + if (unlikely(atomic_read(>vm_lock->count) < 0)) {
> + if (atomic_dec_and_test(>vm_lock->count))
> + wake_up(>vm_mm->vma_writer_wait);
> + return false;
> + }
> +
>   /*
>* Overflow might produce false locked result.
>* False unlocked result is impossible because we modify and check
>* vma->vm_lock_seq under vma->vm_lock protection and mm->mm_lock_seq
>* modification invalidates all existing locks.
>*/
> - if (unlikely(vma->vm_lock_seq == READ_ONCE(vma->vm_mm->mm_lock_seq))) {
> - up_read(>vm_lock->lock);
> + if (unlikely(vma->vm_lock->lock_seq == 
> READ_ONCE(vma->vm_mm->mm_lock_seq))) {
> + if (atomic_dec_and_test(>vm_lock->count))
> + wake_up(>vm_mm->vma_writer_wait);
>   return false;
>   }

With this change readers can cause writers to starve.
What about checking waitqueue_active() before or after increasing
vma->vm_lock->count?

--
Thanks,
Hyeonggon

Re: [PATCH 1/1] ASoC: fsl_sai: Use dev_err_probe

[Shengjiu Wang]

On Thu, Jan 12, 2023 at 12:11 AM Alexander Stein <
alexander.st...@ew.tq-group.com> wrote:

> This helps figuring out why the device probe is deferred, e.g. missing
> FSL_EDMA driver.
>
> Signed-off-by: Alexander Stein 
>

Acked-by: Shengjiu Wang 

Best regards
Wang Shengjiu

> ---
> Old:
> root@ls1021:~# cat /sys/kernel/debug/devices_deferred
> sound   fsl-asoc-card: snd_soc_register_card failed: -517
> 2b5.sai
>
> New:
> root@ls1021:~# cat /sys/kernel/debug/devices_deferred
> sound   fsl-asoc-card: snd_soc_register_card failed: -517
> 2b5.sai fsl-sai: Registering PCM dmaengine failed
>
>  sound/soc/fsl/fsl_sai.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index 1c9be8a5dcb13..2a38e2bdf9893 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -1458,14 +1458,17 @@ static int fsl_sai_probe(struct platform_device
> *pdev)
> if (sai->soc_data->use_imx_pcm) {
> ret = imx_pcm_dma_init(pdev);
> if (ret) {
> +   dev_err_probe(dev, ret, "PCM DMA init failed\n");
> if (!IS_ENABLED(CONFIG_SND_SOC_IMX_PCM_DMA))
> dev_err(dev, "Error: You must enable the
> imx-pcm-dma support!\n");
> goto err_pm_get_sync;
> }
> } else {
> ret = devm_snd_dmaengine_pcm_register(dev, NULL, 0);
> -   if (ret)
> +   if (ret) {
> +   dev_err_probe(dev, ret, "Registering PCM dmaengine
> failed\n");
> goto err_pm_get_sync;
> +   }
> }
>
> ret = devm_snd_soc_register_component(dev, _component,
> --
> 2.34.1
>
>

Re: [PATCH] ASoC: fsl_sai: initialize is_dsp_mode flag

[Iuliana Prodan]

On 1/16/2023 9:07 AM, Shengjiu Wang wrote:

Initialize is_dsp_mode flag in the beginning of function
fsl_sai_set_dai_fmt_tr().

When the DAIFMT is DAIFMT_DSP_B the first time, is_dsp_mode is
true, then the second time DAIFMT is DAIFMT_I2S, is_dsp_mode
still true, which is a wrong state. So need to initialize
is_dsp_mode flag every time.

Fixes: a3f7dcc9cc03 ("ASoC: fsl-sai: Add SND_SOC_DAIFMT_DSP_A/B support.")
Signed-off-by: Shengjiu Wang 


Reviewed-by: Iuliana Prodan 

Thanks,

Iulia


---
  sound/soc/fsl/fsl_sai.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 1c9be8a5dcb1..355ef29af48c 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -281,6 +281,7 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai 
*cpu_dai,
val_cr4 |= FSL_SAI_CR4_MF;
  
  	sai->is_pdm_mode = false;

+   sai->is_dsp_mode = false;
/* DAI mode */
switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
case SND_SOC_DAIFMT_I2S:

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

[Ard Biesheuvel]

On Mon, 16 Jan 2023 at 10:33, John Paul Adrian Glaubitz
 wrote:
>
> Hi Ard!
>
> On 1/14/23 00:25, Ard Biesheuvel wrote:
> > Thanks for reporting back. I (mis)read the debian ports page [3],
> > which mentions Debian 7 as the highest Debian version that supports
> > IA64, and so I assumed that support had been dropped from Debian.
>
> This page talks about officially supported ports. Debian Ports is an
> unofficial spin maintained by a number of Debian Developers and external
> developers that are volunteering to maintain these ports.
>
> > However, if only a handful of people want to keep this port alive for
> > reasons of nostalgia, it is obviously obsolete, and we should ask
> > ourselves whether it is reasonable to expect Linux contributors to
> > keep spending time on this.
>
> You could say this about a lot of hardware, can't you?
>

Uhm, yes. Linux contributor effort is a scarce resource, and spending
it on architectures that nobody actually uses, such as alpha or ia64,
means it is not spent on things that are useful to more people.

I really do sympathize with the enthusiast/hobbyist PoV - I am also an
engineer that likes to tinker. So 'use' can be defined liberally here,
and cover running the latest Linux on ancient hardware just for
entertainment.

However, the question is not how you or I choose to spend (or waste)
their time. The question is whether it is reasonable *as a community*
to insist that everyone who contributes a cross-architecture change
also has to ensure that obsolete architectures such as i64 or alpha
are not left behind.

The original thread is an interesting example here - removing a
cpu_relax() in cmpxchg() that was only there because of IA64's clunky
SMT implementation. Perhaps this means that IA64 performance is going
to regress substantially for some workloads? Should anyone care?
Should we test such changes first? And how should we do that if there
is no maintainer and nobody has access to the hardware?

The other example is EFI, which i maintain. Should I require from
contributors that they build and boot test EFI changes on ia64 if I
myself don't even have access to the hardware? It is good to know that
things don't seem to be broken today, but if it is going to fall over,
it may take a while before anybody notices. What happens then?

> > Does the Debian ia64 port have any users? Or is the system that builds
> > the packages the only one that consumes them?
>
> There is the popcon statistics. However, that is opt-on and the numbers are
> not really trustworthy. We are getting feedback from time to time from people
> using it.
>
> Is there any problem with the ia64 port at the moment that would justify 
> removal?
>

I would argue that we should mark it obsolete at the very least, so
that it is crystal clear that regressing IA64 (either knowingly or
unknowingly) by a generic or cross-architecture change is not a
showstopper, even at build time. Then, if someone has the skill set
and the time on their hands, as well as access to actual hardware,
they can keep it alive if they want to.

Re: [PATCH v4] arch: rename all internal names __xchg to __arch_xchg

[Geert Uytterhoeven]

On Thu, Jan 5, 2023 at 10:54 AM Andrzej Hajda  wrote:
> __xchg will be used for non-atomic xchg macro.
>
> Signed-off-by: Andrzej Hajda 
> Reviewed-by: Arnd Bergmann 
> ---
> v2: squashed all arch patches into one
> v3: fixed alpha/xchg_local, thx to l...@intel.com
> v4: adjusted indentation (Heiko)

>  arch/m68k/include/asm/cmpxchg.h  |  6 +++---

Acked-by: Geert Uytterhoeven  [m68k]

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

[John Paul Adrian Glaubitz]

On 1/15/23 13:04, Sedat Dilek wrote:

Exactly, Debian Popularity Contest was what I was looking for yesterday.

Thanks Matthew.

[1] says in Inst (204701):

Name  || Number  || %
==
binutils-x86-64-linux-gnu || 101548  || 49.61%
binutils-ia64-linux-gnu ||  11  || 0.01%

HELP: Inst. is the number of people who installed this package (sum of
the four categories below)

There may be more popular packages than binutils.
( binutils might tell something about development happening or not. )

Anyway, I am not a popcon expert and never participated in Debian's
Popularity Contest.


And that's the point, it's opt-in!

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

[John Paul Adrian Glaubitz]

On 1/15/23 01:27, Matthew Wilcox wrote:

More useful perhaps is to look at https://popcon.debian.org/

There are three machines reporting popcon results.  It's dead.


It's an opt-in mechanism that reports 190,000 machines running Debian
on x86_64. Do you think that there are only 190,000 servers world-wide
running Debian?

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

[John Paul Adrian Glaubitz]

On 1/14/23 12:28, Sedat Dilek wrote:

[ ... ]


Best is to ask the Debian release-team or (if there exist) maintainers
or responsibles for the IA64 port - which is an ***unofficial*** port.



Here we go:

https://lists.debian.org/debian-ia64/

Posting address: debian-i...@lists.debian.org

Found via 


And the wiki lists Jason Duerstock, Jessica Clarke and me as maintainers:


https://wiki.debian.org/Ports/ia64


Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

[John Paul Adrian Glaubitz]

On 1/14/23 12:24, Sedat Dilek wrote:

Example #1: binutils packages

Checking available binutils package for Debian/unstable IA64 (version:
2.39.90.20230110-1):

https://packages.debian.org/sid/binutils <--- Clearly states IA64 as
"unofficial port"


And?


https://packages.debian.org/sid/ia64/binutils/filelist

Example #2: linux-image packages

Cannot say what this means...

https://packages.debian.org/search?arch=amd64=linux-image
(AMD64 - matches)

https://packages.debian.org/search?arch=ia64=linux-image
(IA64 - no matches)

https://packages.debian.org/search?arch=ia64=linux (IA64 -
matches - but no linux-image which ships normally a bootable
Linux-kernel)


No, the package is called "linux-image-$ARCH-$FLAVOR". There is no "linux-image"
package for amd64 either. Does that prove amd64 is dead?

What you are looking for can be found here:


http://ftp.ports.debian.org/debian-ports/pool-ia64/main/l/linux/



As stated I have no expertise in Debian whatever release for IA64 arch.


Well, maybe let me answer the questions then since I am maintaining the port
in Debian.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

[John Paul Adrian Glaubitz]

Hi Ard!

On 1/14/23 00:25, Ard Biesheuvel wrote:

Thanks for reporting back. I (mis)read the debian ports page [3],
which mentions Debian 7 as the highest Debian version that supports
IA64, and so I assumed that support had been dropped from Debian.


This page talks about officially supported ports. Debian Ports is an
unofficial spin maintained by a number of Debian Developers and external
developers that are volunteering to maintain these ports.


However, if only a handful of people want to keep this port alive for
reasons of nostalgia, it is obviously obsolete, and we should ask
ourselves whether it is reasonable to expect Linux contributors to
keep spending time on this.


You could say this about a lot of hardware, can't you?


Does the Debian ia64 port have any users? Or is the system that builds
the packages the only one that consumes them?


There is the popcon statistics. However, that is opt-on and the numbers are
not really trustworthy. We are getting feedback from time to time from people
using it.

Is there any problem with the ia64 port at the moment that would justify 
removal?

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913