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:
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
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 @@
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)
>
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
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)
> > > {
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
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:
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
> > +++
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
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
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
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
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
>
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:
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
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
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
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
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:
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
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
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:
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
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
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:
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
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
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:
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
> 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
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
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:
>
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
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
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
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%
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
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
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?
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
41 matches
Mail list logo
