Hi Piotr,
piotr.wojtaszc...@timesys.com wrote on Fri, 21 Jun 2024 14:44:21 +0200:
> On Fri, Jun 21, 2024 at 10:30 AM Miquel Raynal
> wrote:
> >
> > Hi Piotr,
> >
> > piotr.wojtaszc...@timesys.com wrote on Thu, 20 Jun 2024 19:56:39 +0200:
> >
> > > Move away from pl08x platform data towards dev
Hi Arnd,
On Fri, 2024-06-21 at 11:41 +0200, Arnd Bergmann wrote:
> On Fri, Jun 21, 2024, at 10:44, John Paul Adrian Glaubitz wrote:
> > On Thu, 2024-06-20 at 18:23 +0200, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > The unusual function calling conventions on superh ended up causin
Hi Piotr,
Any reason why dmaengine parts cant be sent separately, why are they
clubbed together, I dont see any obvious dependencies...
On 20-06-24, 19:56, Piotr Wojtaszczyk wrote:
> LPC32XX connects few of its peripherals to pl08x DMA thru a multiplexer,
> this driver allows to route a signal re
Arnd Bergmann writes:
> From: Arnd Bergmann
>
> A couple of system calls were inadventently removed from the table during
> a bugfix for 32-bit powerpc entry. Restore the original behavior.
>
> Fixes: e23750623835 ("powerpc/32: fix syscall wrappers with 64-bit arguments
> of unaligned register-p
On 6/18/24 19:33, Athira Rajeev wrote:
Perf test for perf probe of function from different CU fails
as below:
./perf test -vv "test perf probe of function from different CU"
116: test perf probe of function from different CU:
--- start ---
test child forked, pid
Michael!
On Thu, Jun 13 2024 at 21:34, Michael Ellerman wrote:
> IIUIC the regression was in the ppc64_cpu userspace tool, which switched
> to using the new kernel interface without taking into account the way it
> behaves.
>
> Or are you saying the kernel behaviour changed on x86 after the powerp
On Fri, Jun 21, 2024 at 12:24 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Both of these architectures require u64 function arguments to be
> passed in even/odd pairs of registers or stack slots, which in case of
> sync_file_range would result in a seven-argument system call that is
> not
On Fri, Jun 21, 2024 at 09:11:56AM -0700, Dave Hansen wrote:
> It's in the "Determination of Access Rights" section.
>
> A linear address is a shadow-stack address if the following are
> true of the translation of the linear address: (1) the R/W flag
> (bit 1) is 0 and the dirty
The pull request you sent on Sun, 23 Jun 2024 12:07:28 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-6.10-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d1505b5cd0426bbddbbc99f10e3ae0b52aaa1d1f
Thank you!
--
Deet-doot-d
On 20/06/2024 15:25, Elinor Montmasson wrote:
> Following merge of imx-spdif driver into fsl-asoc-card:
> * update properties to match those used by fsl-asoc-card.
> * S/PDIF in/out dummy codecs must now be declared explicitly, add and
> use them.
>
> These modifications were tested only on an i
On 20/06/2024 15:25, Elinor Montmasson wrote:
> imx-audio-spdif was merged into the fsl-asoc-card driver, and therefore
> removed.
So what happens with all existing users (e.g. DTS)? They become
invalid/not supported?
After quick look, I do not see backwards compatibility in the driver and
above
On 20/06/2024 15:25, Elinor Montmasson wrote:
> The S/PDIF audio card support was merged from imx-spdif into the
> fsl-asoc-card driver, making it possible to use an S/PDIF with an ASRC.
> Add the new compatible and update properties.
Please use standard email subjects, so with the PATCH keyword i
12 matches
Mail list logo
