On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote:
>
> Michael S. Tsirkin writes:
>
> > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote:
> >>
> >> Michael S. Tsirkin writes:
> >>
> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wro
On 04/14/2019 08:41 PM, Sam Bobroff wrote:
> On Thu, Apr 11, 2019 at 05:55:33PM -0700, Tyrel Datwyler wrote:
>> On 03/19/2019 07:58 PM, Sam Bobroff wrote:
>>> Hi all,
>>>
>>> This patch set adds support for EEH recovery of hot plugged devices on
>>> pSeries
>>> machines. Specifically, devices disc
On Thu, 18 Apr 2019 09:42:23 -0300
Mauro Carvalho Chehab wrote:
> After thinking a little bit and doing some tests, I think a good solution
> would be to add ":orphan:" markup to the new .rst files that were not
> added yet into the main body (e. g. something like the enclosed example).
Interest
Changes from v1:
* Fix compile errors on UML and non-x86 arches
* Clarify commit message and Fixes about the origin of the
bug and add the impact to powerpc / uml / unicore32
--
This is a bit of a mess, to put it mildly. But, it's a bug
that only seems to have showed up in 4.20 but wasn't
On Fri, Apr 19, 2019 at 10:23:56AM +, S.j. Wang wrote:
> Unify the supported input and output rate, add the
> 12kHz/24kHz/128kHz to the support list
>
> Signed-off-by: Shengjiu Wang
> ---
> sound/soc/fsl/fsl_asrc.c | 32 +++-
> 1 file changed, 19 insertions(+), 13
On Fri, Apr 19, 2019 at 10:23:53AM +, S.j. Wang wrote:
> @@ -289,6 +318,12 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair
> *pair)
> return -EINVAL;
> }
>
> + ret = fsl_asrc_sel_proc(inrate, outrate, &pre_proc, &post_proc);
Since the function always return
On Fri, Apr 19, 2019 at 10:23:50AM +, S.j. Wang wrote:
> When the output sample rate is [8kHz, 30kHz], the limitation
> of the supported ratio range is (1/24, 8). In the driver
> we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
> So this patch is to fix this issue and the potential rounding
> iss
On Fri, Apr 19, 2019 at 6:33 AM Martin Schwidefsky
wrote:
>
> That problem got stuck in my head and I thought more about it. Why not
> emulate the static folding sequence in the s390 page table code?
So this model seems much closer to what x86 does in its folding, where
the pattern is basically
Hi Jerome,
Thanks a lot for reviewing this series.
Le 19/04/2019 à 00:48, Jerome Glisse a écrit :
On Tue, Apr 16, 2019 at 03:45:00PM +0200, Laurent Dufour wrote:
From: Peter Zijlstra
Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence
counts such that we can easily test if
Hi,
On Fri, Apr 19, 2019 at 12:06 PM Masahiro Yamada
wrote:
>
> This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
> place. We need to eliminate potential issues beforehand.
>
> If it is enabled for mips, the following errors are reported:
>
> arch/mips/mm/sc-mips.o: In function
If vfio_pci_register_dev_region() fails then we should rollback
previous changes, ie. unmap the ATSD registers.
Signed-off-by: Greg Kurz
---
drivers/vfio/pci/vfio_pci_nvlink2.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_nvlink2.c
b/drivers/vfio/pci/vfio_p
Since 902bdc57451c, get_pci_dev() calls pci_get_domain_bus_and_slot(). This
has the effect of incrementing the reference count of the PCI device, as
explained in drivers/pci/search.c:
* Given a PCI domain, bus, and slot/function number, the desired PCI
* device is located in the list of PCI devi
On Fri, Apr 19, 2019 at 11:01:21AM +, S.j. Wang wrote:
> > fsl_esai_probe(struct platform_device *pdev)
> > return ret;
> > }
> >
> > + pm_runtime_enable(&pdev->dev);
> > +
> I just have a question, do I need to add pm_runtime_idle(&pdev->dev)?
It gets used to
On Fri, Apr 19, 2019 at 4:19 PM Thomas Gleixner wrote:
>
> On Fri, 19 Apr 2019, Pingfan Liu wrote:
>
> > At present, both return and crash_size should be checked to guarantee the
> > success of parse_crashkernel().
> > Simplify the way by returning negative if fail, positive if success. In
> > cas
Hi Robin,
> -Original Message-
> From: Robin Murphy
> Sent: Friday, March 29, 2019 4:51 PM
>
> On 29/03/2019 14:00, laurentiu.tu...@nxp.com wrote:
> > From: Laurentiu Tudor
> >
> > Add a one-to-one iommu mapping for bman private data memory (FBPR).
> > This is required for BMAN to work
On Thu, 18 Apr 2019 20:41:44 +0200
Martin Schwidefsky wrote:
> On Thu, 18 Apr 2019 08:49:32 -0700
> Linus Torvalds wrote:
>
> > On Thu, Apr 18, 2019 at 1:02 AM Martin Schwidefsky
> > wrote:
> > >
> > > The problematic lines in the generic gup code are these three:
> > >
> > > 1845: pmdp =
Hi
>
>
> Add pm runtime support and move clock handling there.
> fsl_esai_suspend is replaced by pm_runtime_force_suspend.
> fsl_esai_resume is replaced by pm_runtime_force_resume.
>
> Signed-off-by: Shengjiu Wang
> ---
> Changes in v2
> -refine the commit comments.
> -move regcache_mark_dir
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_asrc.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.
We got a function fsl_asrc_sel_proc to replace the table, which can
give the pre-p
When the output sample rate is [8kHz, 30kHz], the limitation
of the supported ratio range is (1/24, 8). In the driver
we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
So this patch is to fix this issue and the potential rounding
issue with divider.
Fixes: fff6e03c7b65 ("ASoC: fsl_asrc: add support f
Support more sample rate in asrc
Shengjiu Wang (3):
ASoC: fsl_asrc: Fix the issue about unsupported rate
ASoC: fsl_asrc: replace the process_option table with function
ASoC: fsl_asrc: Unify the supported input and output rate
Changes in v4
- add patch to Fix the [8kHz, 30kHz] open set issue
Hi
>
>
> On Thu, Apr 18, 2019 at 09:37:06AM +, S.j. Wang wrote:
> > > > > And this is according to IMX6DQRM:
> > > > > Limited support for the case when output sampling rates is
> > > > > between 8kHz and 30kHz. The limitation is the supported ratio
> > > > > (Fsin/Fsout) range a
Has this slipped through?
On 3/20/2019 2:57 PM, Horia Geantă wrote:
> crypto node alias is needed by U-boot to identify the node and
> perform fix-ups, like adding "fsl,sec-era" property.
>
> Signed-off-by: Horia Geantă
> ---
> arch/powerpc/boot/dts/fsl/b4qds.dtsi | 1 +
> 1 file changed, 1 ins
Commit 60a3cdd06394 ("x86: add optimized inlining") introduced
CONFIG_OPTIMIZE_INLINING, but it has been available only for x86.
The idea is obviously arch-agnostic. This commit moves the config
entry from arch/x86/Kconfig.debug to lib/Kconfig.debug so that all
architectures can benefit from it.
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for mips, the following errors are reported:
arch/mips/mm/sc-mips.o: In function `mips_sc_prefetch_enable.part.2':
sc-mips.c:(.text+0x98): undefined refere
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for powerpc, the following errors are reported:
arch/powerpc/mm/tlb-radix.c: In function '__tlbie_lpid':
arch/powerpc/mm/tlb-radix.c:148:2: warning: asm op
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
Kbuild test robot has never reported -Wmaybe-uninitialized warning
for this probably because vf610_nfc_run() is inlined by the x86
compiler's inlining heuristic.
If CONFIG_
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for powerpc, the following error is reported:
arch/powerpc/mm/tlb-radix.c: In function '__radix__flush_tlb_range_psize':
arch/powerpc/mm/tlb-radix.c:104:2:
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for arm, Clang build results in the following modpost
warning:
WARNING: vmlinux.o(.text+0x1124): Section mismatch in reference from the
function setup_mac
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for powerpc, the following modpost warnings are
reported:
WARNING: vmlinux.o(.text.unlikely+0x20): Section mismatch in reference from the
function .prom_g
Major changes in v2:
- Eliminate more errors and warnings
- Delete 'depends on !MIPS'
- Split into separate patches
Arnd Bergmann (1):
ARM: prevent tracing IPI_CPU_BACKTRACE
Masahiro Yamada (10):
arm64: mark (__)cpus_have_const_cap as __always_inline
MIPS: mark mult_sh_align_mod() as _
From: Arnd Bergmann
When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():
arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array b
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for s390, the following error is reported:
In file included from arch/s390/crypto/des_s390.c:19:
./arch/s390/include/asm/cpacf.h: In function 'cpacf_query'
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for mips, the following error is reported:
arch/mips/kernel/cpu-bugs64.c: In function 'mult_sh_align_mod.constprop':
arch/mips/kernel/cpu-bugs64.c:33:2: er
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for arm64, the following errors are reported:
In file included from ././include/linux/compiler_types.h:68,
from :
./arch/arm64/include/asm
On Fri, 19 Apr 2019, Pingfan Liu wrote:
> At present, both return and crash_size should be checked to guarantee the
> success of parse_crashkernel().
> Simplify the way by returning negative if fail, positive if success. In
> case of failure, -EINVAL for bad syntax, -1 for the parsing results in
>
At present, both return and crash_size should be checked to guarantee the
success of parse_crashkernel().
Simplify the way by returning negative if fail, positive if success. In
case of failure, -EINVAL for bad syntax, -1 for the parsing results in
crash_size=0.
Signed-off-by: Pingfan Liu
Cc: Rus
37 matches
Mail list logo
