There is a constraint for the channel number setting on the
asrc of older version (e.g. imx35), the channel number should
be even, odd number isn't valid.
So add this constraint when the asrc of older version is used.
Acked-by: Nicolin Chen
Signed-off-by: Shengjiu Wang
---
Changes in v3
- fix c
Hi
> On Fri, Mar 01, 2019 at 08:37:08AM +, S.j. Wang wrote:
> > There is constraint for the channel number setting on the
>
> nit: "a constraint"
>
> > asrc of older version (e.g. imx35), the channel number should be even,
> > odd number isn't valid.
>
> > +static int fsl_asrc_dai_startup(s
Hi
> On 3/1/19 12:32 AM, S.j. Wang wrote:
> > This case is covered by S24_LE I think. The S32_LE means the data is
> > 32bit and slot width Is 32bit, this is not in data sheet.
>
> The problem is that if you have 32-bit samples in your audio file, and you
> want to play them, then software (e.g.
On Wed, 2019-02-27 at 15:57 +1100, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Use %# instead of using a literal '0x'
I think it's better not to change this unless
the compilation unit already uses a mix of styles.
Overall, the kernel uses "0x%" over "%#"
by ~8:1
$ git grep -P '0x%\
On Sat, 2 Mar 2019, Michael Ellerman wrote:
> > The problem seems to be in vDSO code in
> > arch/powerpc/kernel/vdso64/gettimeofday.S.
>
> You're right, the wall-to-monotonic offset (wtom_clock_sec) is a signed
> 32-bit value, so that seems like it's going to have problems.
>
> If I do `date -s
Here are the generic command line changes for powerpc.
These changes have been in linux-next for two cycles, with few problems
reported.
It's also been used at Cisco Systems, Inc. in production products for many many
years with no problems.
Please pull these changes.
The following changes sin
This code allows architectures to use a generic builtin command line.
The state of the builtin command line options across architecture is
diverse. On x86 and mips they have pretty much the same code and the
code prepends the builtin command line onto the boot loader provided
one. On powerpc there
This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
option.
[maksym.kok...@globallogic.com: add strlcat to prom_init_check.sh
whitelist]
Cc: Daniel Walker
Cc: Daniel Walker
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Daniel Walker
Signed-off-by: Maksym Kokhan
---
arch/powerpc/K
This is a scripted mass convert of the config files to use
the new generic cmdline. There is a bit of a trim effect here.
It would seems that some of the config haven't been trimmed in
a while.
The script used to convert is as follows,
if [[ -z "$1" || -z "$2" ]]; then
echo "Two arguments
As tglx points out, there are no in-tree module users of
save_stack_trace_tsk_reliable() and its x86 counterpart is not exported,
so remove the powerpc symbol export.
Suggested-by: Thomas Gleixner
Signed-off-by: Joe Lawrence
---
arch/powerpc/kernel/stacktrace.c | 1 -
1 file changed, 1 deletion
On Fri, Mar 01, 2019 at 08:37:08AM +, S.j. Wang wrote:
> There is constraint for the channel number setting on the
nit: "a constraint"
> asrc of older version (e.g. imx35), the channel number should
> be even, odd number isn't valid.
> +static int fsl_asrc_dai_startup(struct snd_pcm_substrea
On 3/1/19 5:21 AM, Alexandre Ghiti wrote:
> On 03/01/2019 07:25 AM, Alex Ghiti wrote:
>> On 2/28/19 5:26 PM, Mike Kravetz wrote:
>>> On 2/28/19 12:23 PM, Dave Hansen wrote:
On 2/28/19 11:50 AM, Mike Kravetz wrote:
> On 2/28/19 11:13 AM, Dave Hansen wrote:
>>> +if (hstate_is_giganti
Writing a new value to the PCI_SECONDARY_BUS register of the bridge means
that its children will become addressable on another address (new B in BDF)
or even un-addressable if the secondary bus is set to zero.
On PowerNV, device PEs are heavily BDF-dependent, so they must be updated
on every such
When the pci=realloc command line switch is enabled (which should only be
set when working on on top of the skiboot with the "core/pci: Sync VFs and
the changes of bdfns between the firmware and the OS" patch serie applied),
PowerNV will not depend on PCIe topology info from DT anymore.
This makes
When called within pcibios_sriov_enable(), the pci_sriov_get_totalvfs(pdev)
returns zero, because the device is yet preparing to enable the VFs.
With this patch it becomes possible to enable VFs via sysfs "sriov_numvfs"
on PowerNV.
Signed-off-by: Sergey Miroshnichenko
---
arch/powerpc/include/a
If supported by the platform, endpoint's pci_dn can be created dynamically,
without need to wait for DT updates from the firmware.
Signed-off-by: Sergey Miroshnichenko
---
arch/powerpc/kernel/pci_dn.c | 6 --
arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +-
2 files change
It is possible now to allocate and fill a new pdn with add_one_dev_pci_data
Signed-off-by: Sergey Miroshnichenko
---
arch/powerpc/kernel/pci_dn.c | 38 +++-
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/kernel/pci_dn.c b/arch/powerpc
Otherwise there will be a NULL pointer dereferencing in iommu_add_device()
later during activating a newly created VF.
Signed-off-by: Sergey Miroshnichenko
---
arch/powerpc/platforms/powernv/pci-ioda.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda
This patchset allows switching from the pnv_php module to the standard
pciehp driver for PCIe hotplug functionality, if the platform supports it:
PowerNV working on on top of the skiboot with the "core/pci: Sync VFs and
the changes of bdfns between the firmware and the OS" patch serie applied.
The
Reading an empty slot returns all ones, which triggers a false
EEH error event on PowerNV. This patch unfreezes the bus where
it has happened.
Signed-off-by: Sergey Miroshnichenko
---
arch/powerpc/include/asm/ppc-pci.h | 1 +
arch/powerpc/kernel/pci_dn.c | 2 +-
arch/powerpc/platform
To fetch an updated DT for the newly hotplugged device, OS must explicitly
request it from the firmware via the pnv_php driver.
If pnv_php wasn't triggered/loaded, it is still possible to discover new
devices if PCIe I/O will not stop in absence of the pci_dn structure.
Signed-off-by: Sergey Miro
If a struct pci_dn hasn't yet been created for the PCIe device (there was
no DT node for it), allocate this structure and fill with info read from
the device directly.
Signed-off-by: Sergey Miroshnichenko
---
arch/powerpc/kernel/pci_dn.c | 79
1 file changed,
On 3/1/19 12:32 AM, S.j. Wang wrote:
This case is covered by S24_LE I think. The S32_LE means the data is 32bit and
slot width
Is 32bit, this is not in data sheet.
The problem is that if you have 32-bit samples in your audio file, and
you want to play them, then software (e.g. alsalib) will
The commit 24b6d4164348 ("mm: pass the vmem_altmap to vmemmap_free")
removed a line in vmemmap_free(),
altmap = to_vmem_altmap((unsigned long) section_base);
but left a variable no longer used.
arch/powerpc/mm/init_64.c: In function 'vmemmap_free':
arch/powerpc/mm/init_64.c:277:16: error: variab
On 03/01/2019 02:33 PM, Vlastimil Babka wrote:
On 3/1/19 2:21 PM, Alexandre Ghiti wrote:
I collected mistakes here: domain name expired and no mailing list added :)
Really sorry about that, I missed the whole discussion (if any).
Could someone forward it to me (if any) ? Thanks !
Bounced you Da
On 3/1/19 2:21 PM, Alexandre Ghiti wrote:
> I collected mistakes here: domain name expired and no mailing list added :)
> Really sorry about that, I missed the whole discussion (if any).
> Could someone forward it to me (if any) ? Thanks !
Bounced you David and Mike's discussion (4 messages total)
Hi,
>> Decreasing the realtime clock across the y2k38 threshold is one reliable way
>> to reproduce.
>> Allegedly this can also happen just by running ntpd, I have not managed to
>> reproduce that other
>> than booting with rtc at >2038 and then running ntp.
> Isn't it the expected behavior. He
Hi Jakub,
[Cc += Timekeeping maintainers]
"Jakub Drnec" writes:
> Hi all,
>
> I think I observed a potential problem, is this the correct place to report
> it? (CC me, not on list)
>
> [1.] One line summary: monotonic clock can be made to decrease on ppc64
> [2.] Full description:
> Setting the
On 03/01/2019 07:25 AM, Alex Ghiti wrote:
On 2/28/19 5:26 PM, Mike Kravetz wrote:
On 2/28/19 12:23 PM, Dave Hansen wrote:
On 2/28/19 11:50 AM, Mike Kravetz wrote:
On 2/28/19 11:13 AM, Dave Hansen wrote:
+ if (hstate_is_gigantic(h) &&
!IS_ENABLED(CONFIG_CONTIG_ALLOC)) {
+ spin_lock(
The recent commit got this test wrong, it declared the assembler
symbols the wrong way, and also used the wrong symbol name
(xxx_start rather than start_xxx, see asm/head-64.h).
Fixes: ccd477028a ("powerpc/64s: Fix HV NMI vs HV interrupt recoverability
test")
Signed-off-by: Nicholas Piggin
---
On Fri, Mar 01, 2019 at 06:55:25AM +, S.j. Wang wrote:
> > Alternatively, I feel instead of error-out at here, should we add a HW
> > constraint or at least fence it off at the beginning of the hw_params()?
> > This
> > is actually nothing specific to the pair-request function but a hardware
KASAN requires early activation of hash table, before memblock()
functions are available.
This patch implements an early hash_table statically defined in
__initdata.
During early boot, a single page table is used.
For hash32, when doing the final init, one page table is allocated
for each PGD en
For KASAN, hash table handling will be activated early for
accessing to KASAN shadow areas.
In order to avoid any modification of the hash functions while
they are still used with the early hash table, the code patching
is moved out of MMU_init_hw() and put close to the big-bang switch
to the fina
This patch prepares a shadow area for KASAN.
The shadow area will be at the top of the kernel virtual
memory space above the fixmap area and will occupy one
eighth of the total kernel virtual memory space.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig.debug| 5 +
arch/po
This patch adds KASAN support for PPC32. The following patch
will add an early activation of hash table for book3s. Until
then, a warning will be raised if trying to use KASAN on an
hash 6xx.
To support KASAN, this patch initialises that MMU mapings for
accessing to the KASAN shadow area defined i
All files containing functions run before kasan_early_init() is called
must have KASAN instrumentation disabled.
For those file, branch profiling also have to be disabled otherwise
each if () generates a call to ftrace_likely_update().
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/Mak
When we add KASAN shadow area, KVIRT_TOP can't be anymore fixed
at 0xfe00.
This patch uses FIXADDR_START to define KVIRT_TOP.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 13 ++---
arch/powerpc/include/asm/nohash/32/pgtable.h | 13 ++---
Since commit 400c47d81ca38 ("powerpc32: memset: only use dcbz once cache is
enabled"), memset() can be used before activation of the cache,
so no need to use memset_io() for zeroing the BSS.
Acked-by: Dmitry Vyukov
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/early_32.c | 4 ++--
1 f
In preparation of KASAN, move early_init() into a separate
file in order to allow deactivation of KASAN for that function.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/early_32.c | 36
arch/powerpc/kernel/set
This series adds KASAN support to powerpc/32
Tested on nohash/32 (8xx) and book3s/32 (mpc832x ie 603).
Boot tested on qemu mac99
Changes in v9:
- Fixed fixmap IMMR alignment issue on 8xx with KASAN enabled.
- Set up final shadow page tables before switching to the final hash table on
hash32
- Us
When KASAN is active, the string functions in lib/ are doing the
KASAN checks. This is too early for prom_init.
This patch implements dedicated string functions for prom_init,
which will be compiled in with KASAN disabled.
Size of prom_init before the patch:
textdata bss dec he
CONFIG_KASAN implements wrappers for memcpy() memmove() and memset()
Those wrappers are doing the verification then call respectively
__memcpy() __memmove() and __memset(). The arches are therefore
expected to rename their optimised functions that way.
For files on which KASAN is inhibited, #defin
In kernel/cputable.c, explicitly use memcpy() instead of *y = *x;
This will allow GCC to replace it with __memcpy() when KASAN is
selected.
Acked-by: Dmitry Vyukov
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/cputable.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletion
I'm sorry for previous email content without greeting.
A bit more description… We are working on enabling RDMA over PCIe NTB on
OpenPOWER using https://github.com/ntrdma project. During initialization
dma_request_channel() founds no available channels. We also found that there no
channels at al
There is constraint for the channel number setting on the
asrc of older version (e.g. imx35), the channel number should
be even, odd number isn't valid.
So add this constraint when the asrc of older version is used.
Signed-off-by: Shengjiu Wang
---
changes in v2
- switch to add constraint in sta
Hi
>
> On Fri, Mar 01, 2019 at 06:55:25AM +, S.j. Wang wrote:
>
> > > Alternatively, I feel instead of error-out at here, should we add a
> > > HW constraint or at least fence it off at the beginning of the
> > > hw_params()? This is actually nothing specific to the pair-request
> > > functi
On Fri, Mar 01, 2019 at 06:55:25AM +, S.j. Wang wrote:
> > Alternatively, I feel instead of error-out at here, should we add a HW
> > constraint or at least fence it off at the beginning of the hw_params()?
> > This
> > is actually nothing specific to the pair-request function but a hardware
On Fri, Mar 01, 2019 at 05:52:51PM +1100, Michael Ellerman wrote:
> Suraj Jitindar Singh writes:
>
> > Add KVM_PPC_CPU_CHAR_BCCTR_FLUSH_ASSIST &
> > KVM_PPC_CPU_BEHAV_FLUSH_COUNT_CACHE to the characteristics returned from
> > the H_GET_CPU_CHARACTERISTICS H-CALL, as queried from either the
> > hy
48 matches
Mail list logo