* Re: [PATCH v2 15/16] powerpc/powernv/sriov: Make single PE mode a per-BAR setting
From: Segher Boessenkool @ 2020-08-03 21:00 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Nathan Chancellor, Oliver O'Halloran,
clang-built-linux
In-Reply-To: <87k0yg1dc8.fsf@mpe.ellerman.id.au>
On Mon, Aug 03, 2020 at 03:57:11PM +1000, Michael Ellerman wrote:
> > I would assume the function should still be generated since those checks
> > are relevant, just the return value is bogus.
>
> Yeah, just sometimes missing warnings boil down to the compiler eliding
> whole sections of code, if it can convince itself they're unreachable.
Including when the compiler considers they must be unreachable because
they would perform undefined behaviour, like, act on uninitialised
values. Such code is removed by cddce ("control dependence dead code
elimination", enabled by -ftree-dce at -O2 or above).
> AFAICS there's nothing weird going on here that should confuse GCC, it's
> about as straight forward as it gets.
Yes. Please open a bug?
> Actually I can reproduce it with:
>
> $ cat > test.c <<EOF
> int foo(void *p)
> {
> unsigned align;
>
> if (!p)
> return align;
>
> return 0;
> }
> EOF
>
> $ gcc -Wall -Wno-maybe-uninitialized -c test.c
> $
>
> No warning.
The whole if() is deleted pretty early.
===
static int foo(void *p)
{
unsigned align;
if (!p)
return align;
return 42;
}
int bork(void) { return foo(0); }
===
doesn't warn either, although that always uses the uninitialised var
(actually, that code is *removed*, and it always does that "return 42").
> But I guess that's behaving as documented. The compiler can't prove that
> foo() will be called with p == NULL, so it doesn't warn.
-Wmaybe-uninitialized doesn't warn for this either, btw.
Segher
^ permalink raw reply
* Re: [PATCHv4 2/2] powerpc/pseries: update device tree before ejecting hotplug uevents
From: Laurent Dufour @ 2020-08-03 16:28 UTC (permalink / raw)
To: Pingfan Liu, linuxppc-dev
Cc: Nathan Lynch, Nathan Fontenot, kexec, Hari Bathini
In-Reply-To: <1596116005-27511-2-git-send-email-kernelfans@gmail.com>
Le 30/07/2020 à 15:33, Pingfan Liu a écrit :
> A bug is observed on pseries by taking the following steps on rhel:
> -1. drmgr -c mem -r -q 5
> -2. echo c > /proc/sysrq-trigger
>
> And then, the failure looks like:
> kdump: saving to /sysroot//var/crash/127.0.0.1-2020-01-16-02:06:14/
> kdump: saving vmcore-dmesg.txt
> kdump: saving vmcore-dmesg.txt complete
> kdump: saving vmcore
> Checking for memory holes : [ 0.0 %] / Checking for memory holes : [100.0 %] | Excluding unnecessary pages : [100.0 %] \ Copying data : [ 0.3 %] - eta: 38s[ 44.337636] hash-mmu: mm: Hashing failure ! EA=0x7fffba400000 access=0x8000000000000004 current=makedumpfile
> [ 44.337663] hash-mmu: trap=0x300 vsid=0x13a109c ssize=1 base psize=2 psize 2 pte=0xc000000050000504
> [ 44.337677] hash-mmu: mm: Hashing failure ! EA=0x7fffba400000 access=0x8000000000000004 current=makedumpfile
> [ 44.337692] hash-mmu: trap=0x300 vsid=0x13a109c ssize=1 base psize=2 psize 2 pte=0xc000000050000504
> [ 44.337708] makedumpfile[469]: unhandled signal 7 at 00007fffba400000 nip 00007fffbbc4d7fc lr 000000011356ca3c code 2
> [ 44.338548] Core dump to |/bin/false pipe failed
> /lib/kdump-lib-initramfs.sh: line 98: 469 Bus error $CORE_COLLECTOR /proc/vmcore $_mp/$KDUMP_PATH/$HOST_IP-$DATEDIR/vmcore-incomplete
> kdump: saving vmcore failed
>
> * Root cause *
> After analyzing, it turns out that in the current implementation,
> when hot-removing lmb, the KOBJ_REMOVE event ejects before the dt updating as
> the code __remove_memory() comes before drmem_update_dt().
> So in kdump kernel, when read_from_oldmem() resorts to
> pSeries_lpar_hpte_insert() to install hpte, but fails with -2 due to
> non-exist pfn. And finally, low_hash_fault() raise SIGBUS to process, as it
> can be observed "Bus error"
>
> From a viewpoint of listener and publisher, the publisher notifies the
> listener before data is ready. This introduces a problem where udev
> launches kexec-tools (due to KOBJ_REMOVE) and loads a stale dt before
> updating. And in capture kernel, makedumpfile will access the memory based
> on the stale dt info, and hit a SIGBUS error due to an un-existed lmb.
>
> * Fix *
> This bug is introduced by commit 063b8b1251fd
> ("powerpc/pseries/memory-hotplug: Only update DT once per memory DLPAR
> request"), which tried to combine all the dt updating into one.
>
> To fix this issue, meanwhile not to introduce a quadratic runtime
> complexity by the model:
> dlpar_memory_add_by_count
> for_each_drmem_lmb <--
> dlpar_add_lmb
> drmem_update_dt(_v1|_v2)
> for_each_drmem_lmb <--
> The dt should still be only updated once, and just before the last memory
> online/offline event is ejected to user space. Achieve this by tracing the
> num of lmb added or removed.
>
> Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Nathan Lynch <nathanl@linux.ibm.com>
> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> Cc: kexec@lists.infradead.org
> To: linuxppc-dev@lists.ozlabs.org
> ---
> v3 -> v4: resolve a quadratic runtime complexity issue.
> This series is applied on next-test branch
> arch/powerpc/platforms/pseries/hotplug-memory.c | 88 ++++++++++++++++++-------
> 1 file changed, 66 insertions(+), 22 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 1a3ac3b..e07d5b1 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -350,13 +350,13 @@ static bool lmb_is_removable(struct drmem_lmb *lmb)
> return true;
> }
>
> -static int dlpar_add_lmb(struct drmem_lmb *);
> +static int dlpar_add_lmb(struct drmem_lmb *lmb, bool dt_update);
>
> -static int dlpar_remove_lmb(struct drmem_lmb *lmb)
> +static int dlpar_remove_lmb(struct drmem_lmb *lmb, bool dt_update)
> {
> unsigned long block_sz;
> phys_addr_t base_addr;
> - int rc, nid;
> + int rc, ret, nid;
>
> if (!lmb_is_removable(lmb))
> return -EINVAL;
> @@ -372,6 +372,11 @@ static int dlpar_remove_lmb(struct drmem_lmb *lmb)
> invalidate_lmb_associativity_index(lmb);
> lmb_clear_nid(lmb);
> lmb->flags &= ~DRCONF_MEM_ASSIGNED;
> + if (dt_update) {
> + ret = drmem_update_dt();
> + if (ret)
> + pr_warn("%s fail to update dt, but continue\n", __func__);
> + }
>
> __remove_memory(nid, base_addr, block_sz);
>
> @@ -387,6 +392,7 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
> int lmbs_removed = 0;
> int lmbs_available = 0;
> int rc;
> + bool dt_update = false;
>
> pr_info("Attempting to hot-remove %d LMB(s)\n", lmbs_to_remove);
>
> @@ -409,7 +415,7 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
> }
>
> for_each_drmem_lmb(lmb) {
> - rc = dlpar_remove_lmb(lmb);
> + rc = dlpar_remove_lmb(lmb, dt_update);
> if (rc)
> continue;
>
> @@ -421,16 +427,27 @@ static int dlpar_memory_remove_by_count(u32 lmbs_to_remove)
> lmbs_removed++;
> if (lmbs_removed == lmbs_to_remove)
> break;
> + /* combine dt updating */
> + else if (lmbs_removed == lmbs_to_remove - 1)
> + dt_update = true;
> }
>
> if (lmbs_removed != lmbs_to_remove) {
> + bool rollback_dt_update = false;
> +
> pr_err("Memory hot-remove failed, adding LMB's back\n");
>
> for_each_drmem_lmb(lmb) {
> if (!drmem_lmb_reserved(lmb))
> continue;
>
> - rc = dlpar_add_lmb(lmb);
> + /*
> + * Even if dlpar_remove_lmb() fails to update dt, it is
> + * harmless to update dt here.
> + */
> + if (--lmbs_removed == 0 && dt_update)
> + rollback_dt_update = true;
> + rc = dlpar_add_lmb(lmb, rollback_dt_update);
> if (rc)
> pr_err("Failed to add LMB back, drc index %x\n",
> lmb->drc_index);
> @@ -468,7 +485,7 @@ static int dlpar_memory_remove_by_index(u32 drc_index)
> for_each_drmem_lmb(lmb) {
> if (lmb->drc_index == drc_index) {
> lmb_found = 1;
> - rc = dlpar_remove_lmb(lmb);
> + rc = dlpar_remove_lmb(lmb, true);
> if (!rc)
> dlpar_release_drc(lmb->drc_index);
>
> @@ -493,6 +510,7 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
> struct drmem_lmb *lmb, *start_lmb, *end_lmb;
> int lmbs_available = 0;
> int rc;
> + bool dt_update = false;
>
> pr_info("Attempting to hot-remove %u LMB(s) at %x\n",
> lmbs_to_remove, drc_index);
> @@ -519,7 +537,9 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
> if (!(lmb->flags & DRCONF_MEM_ASSIGNED))
> continue;
>
> - rc = dlpar_remove_lmb(lmb);
> + if (lmb == end_lmb)
> + dt_update = true;
> + rc = dlpar_remove_lmb(lmb, dt_update);
> if (rc)
> break;
>
> @@ -527,14 +547,17 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
> }
>
> if (rc) {
> - pr_err("Memory indexed-count-remove failed, adding any removed LMBs\n");
> + bool rollback_dt_update = false;
>
> + pr_err("Memory indexed-count-remove failed, adding any removed LMBs\n");
>
> for_each_drmem_lmb_in_range(lmb, start_lmb, end_lmb) {
> if (!drmem_lmb_reserved(lmb))
> continue;
> -
> - rc = dlpar_add_lmb(lmb);
> + /* Since in removing path, dt is only updated if lmb == end_lmb */
> + if (lmb == end_lmb)
> + rollback_dt_update = true;
> + rc = dlpar_add_lmb(lmb, rollback_dt_update);
> if (rc)
> pr_err("Failed to add LMB, drc index %x\n",
> lmb->drc_index);
> @@ -572,7 +595,7 @@ static inline int dlpar_memory_remove(struct pseries_hp_errorlog *hp_elog)
> {
> return -EOPNOTSUPP;
> }
> -static int dlpar_remove_lmb(struct drmem_lmb *lmb)
> +static int dlpar_remove_lmb(struct drmem_lmb *lmb, bool dt_update)
> {
> return -EOPNOTSUPP;
> }
> @@ -591,10 +614,10 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
> }
> #endif /* CONFIG_MEMORY_HOTREMOVE */
>
> -static int dlpar_add_lmb(struct drmem_lmb *lmb)
> +static int dlpar_add_lmb(struct drmem_lmb *lmb, bool dt_update)
> {
> unsigned long block_sz;
> - int rc;
> + int rc, ret;
>
> if (lmb->flags & DRCONF_MEM_ASSIGNED)
> return -EINVAL;
> @@ -607,6 +630,11 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
>
> lmb_set_nid(lmb);
> lmb->flags |= DRCONF_MEM_ASSIGNED;
> + if (dt_update) {
> + ret = drmem_update_dt();
> + if (ret)
> + pr_warn("%s fail to update dt, but continue\n", __func__);
> + }
>
> block_sz = memory_block_size_bytes();
In the case the call to __add_memory is failing, the flag DRCONF_MEM_ASSIGNED
should be cleared as I mentioned in your previous patch. In addition to this,
the DT should be updated, or the caller should manage that but that will be hard
since it doesn't know where the error happened in this function.
>
> @@ -625,7 +653,11 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
> invalidate_lmb_associativity_index(lmb);
> lmb_clear_nid(lmb);
> lmb->flags &= ~DRCONF_MEM_ASSIGNED;
> -
> + if (dt_update) {
> + ret = drmem_update_dt();
> + if (ret)
> + pr_warn("%s fail to update dt during rollback, but continue\n", __func__);
> + }
> __remove_memory(nid, base_addr, block_sz);
> }
>
> @@ -638,6 +670,7 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
> int lmbs_available = 0;
> int lmbs_added = 0;
> int rc;
> + bool dt_update = false;
>
> pr_info("Attempting to hot-add %d LMB(s)\n", lmbs_to_add);
>
> @@ -664,7 +697,7 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
> if (rc)
> continue;
>
> - rc = dlpar_add_lmb(lmb);
> + rc = dlpar_add_lmb(lmb, dt_update);
> if (rc) {
> dlpar_release_drc(lmb->drc_index);
> continue;
> @@ -678,16 +711,23 @@ static int dlpar_memory_add_by_count(u32 lmbs_to_add)
> lmbs_added++;
> if (lmbs_added == lmbs_to_add)
> break;
> + else if (lmbs_added == lmbs_to_add - 1)
> + dt_update = true;
In the case the number of LMB to add is 1, dt_update is never set to true, and
the device tree is never updated. You need to set dt_update to true earlier in
the loop block.
> }
>
> if (lmbs_added != lmbs_to_add) {
> + bool rollback_dt_update = false;
> +
> pr_err("Memory hot-add failed, removing any added LMBs\n");
>
> for_each_drmem_lmb(lmb) {
> if (!drmem_lmb_reserved(lmb))
> continue;
>
> - rc = dlpar_remove_lmb(lmb);
> + if (--lmbs_added == 0 && dt_update)
> + rollback_dt_update = true;
That test may have to be review to deal with error during the last LMB addition,
the DT may have been updated before __add_memory() is failing in
dlpar_add_lmb(). In that case, lmbs_added == 0 and that branch is not covered.
That's not an issue if dlpar_add_lmb() is handling that case (see my comment above).
> +
> + rc = dlpar_remove_lmb(lmb, rollback_dt_update);
> if (rc)
> pr_err("Failed to remove LMB, drc index %x\n",
> lmb->drc_index);
> @@ -725,7 +765,7 @@ static int dlpar_memory_add_by_index(u32 drc_index)
> lmb_found = 1;
> rc = dlpar_acquire_drc(lmb->drc_index);
> if (!rc) {
> - rc = dlpar_add_lmb(lmb);
> + rc = dlpar_add_lmb(lmb, true);
> if (rc)
> dlpar_release_drc(lmb->drc_index);
> }
> @@ -751,6 +791,7 @@ static int dlpar_memory_add_by_ic(u32 lmbs_to_add, u32 drc_index)
> struct drmem_lmb *lmb, *start_lmb, *end_lmb;
> int lmbs_available = 0;
> int rc;
> + bool dt_update = false;
>
> pr_info("Attempting to hot-add %u LMB(s) at index %x\n",
> lmbs_to_add, drc_index);
> @@ -781,7 +822,9 @@ static int dlpar_memory_add_by_ic(u32 lmbs_to_add, u32 drc_index)
> if (rc)
> break;
>
> - rc = dlpar_add_lmb(lmb);
> + if (lmb == end_lmb)
> + dt_update = true;
> + rc = dlpar_add_lmb(lmb, dt_update);
> if (rc) {
> dlpar_release_drc(lmb->drc_index);
> break;
> @@ -794,10 +837,14 @@ static int dlpar_memory_add_by_ic(u32 lmbs_to_add, u32 drc_index)
> pr_err("Memory indexed-count-add failed, removing any added LMBs\n");
>
> for_each_drmem_lmb_in_range(lmb, start_lmb, end_lmb) {
> + bool rollback_dt_update = false;
> +
> if (!drmem_lmb_reserved(lmb))
> continue;
>
> - rc = dlpar_remove_lmb(lmb);
> + if (lmb == end_lmb)
> + rollback_dt_update = true;
> + rc = dlpar_remove_lmb(lmb, rollback_dt_update);
> if (rc)
> pr_err("Failed to remove LMB, drc index %x\n",
> lmb->drc_index);
> @@ -877,9 +924,6 @@ int dlpar_memory(struct pseries_hp_errorlog *hp_elog)
> break;
> }
>
> - if (!rc)
> - rc = drmem_update_dt();
> -
> unlock_device_hotplug();
> return rc;
> }
>
^ permalink raw reply
* Re: [PATCH v3] ASoC: fsl-asoc-card: Remove fsl_asoc_card_set_bias_level function
From: Mark Brown @ 2020-08-03 15:52 UTC (permalink / raw)
To: tiwai, festevam, nicoleotsuka, perex, Xiubo.Lee, linuxppc-dev,
Shengjiu Wang, timur, lgirdwood, alsa-devel, linux-kernel
In-Reply-To: <1596420811-16690-1-git-send-email-shengjiu.wang@nxp.com>
On Mon, 3 Aug 2020 10:13:31 +0800, Shengjiu Wang wrote:
> With this case:
> aplay -Dhw:x 16khz.wav 24khz.wav
> There is sound distortion for 24khz.wav. The reason is that setting
> PLL of WM8962 with set_bias_level function, the bias level is not
> changed when 24khz.wav is played, then the PLL won't be reset, the
> clock is not correct, so distortion happens.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl-asoc-card: Remove fsl_asoc_card_set_bias_level function
commit: f36e8edb95734c03134db628afa25ee23b8e0d95
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
^ permalink raw reply
* RE: [PATCH v2] selftests/powerpc: Fix pkey syscall redefinitions
From: David Laight @ 2020-08-03 14:42 UTC (permalink / raw)
To: 'Michael Ellerman', Sandipan Das
Cc: sachinp@linux.vnet.ibm.com, aneesh.kumar@linux.ibm.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <8736540z3w.fsf@mpe.ellerman.id.au>
> > +#undef SYS_pkey_mprotect
> > #define SYS_pkey_mprotect 386
>
> We shouldn't undef them.
>
> They should obviously never change, but if the system headers already
> have a definition then we should use that, so I think it should be:
>
> #ifndef SYS_pkey_mprotect
> #define SYS_pkey_mprotect 386
> #endif
If the definitions are identical the compiler won't complain.
So you probably actually want a matching definition so that,
provided at least one compile picks up both headers, you know
that the definitions actually match.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH v3] selftests/powerpc: Fix pkey syscall redefinitions
From: Sachin Sant @ 2020-08-03 14:07 UTC (permalink / raw)
To: Sandipan Das; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <1bb744b0c7ed3985a5b73289f4de629ac0aeaf7c.1596453627.git.sandipan@linux.ibm.com>
> On 03-Aug-2020, at 4:53 PM, Sandipan Das <sandipan@linux.ibm.com> wrote:
>
> On some distros, there are conflicts w.r.t to redefinition
> of pkey syscall numbers which cause build failures. This
> fixes them.
>
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
> —
Thanks for the fix.
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCHv4 1/2] powerpc/pseries: group lmb operation and memblock's
From: Laurent Dufour @ 2020-08-03 13:52 UTC (permalink / raw)
To: linuxppc-dev, Pingfan Liu
Cc: Nathan Lynch, Nathan Fontenot, kexec, Hari Bathini
In-Reply-To: <1596116005-27511-1-git-send-email-kernelfans@gmail.com>
> @@ -603,6 +606,8 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
> }
>
> lmb_set_nid(lmb);
> + lmb->flags |= DRCONF_MEM_ASSIGNED;
> +
> block_sz = memory_block_size_bytes();
>
> /* Add the memory */
Since the lmb->flags is now set earlier, you should unset it in the case the
call to __add_memory() fails, something like:
@@ -614,6 +614,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
rc = __add_memory(lmb->nid, lmb->base_addr, block_sz);
if (rc) {
invalidate_lmb_associativity_index(lmb);
+ lmb->flags &= ~DRCONF_MEM_ASSIGNED;
return rc;
}
> @@ -614,11 +619,14 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
>
> rc = dlpar_online_lmb(lmb);
> if (rc) {
> - __remove_memory(lmb->nid, lmb->base_addr, block_sz);
> + int nid = lmb->nid;
> + phys_addr_t base_addr = lmb->base_addr;
> +
> invalidate_lmb_associativity_index(lmb);
> lmb_clear_nid(lmb);
> - } else {
> - lmb->flags |= DRCONF_MEM_ASSIGNED;
> + lmb->flags &= ~DRCONF_MEM_ASSIGNED;
> +
> + __remove_memory(nid, base_addr, block_sz);
> }
>
> return rc;
^ permalink raw reply
* Re: [PATCH] powerpc: Fix P10 PVR revision in /proc/cpuinfo for SMT4 cores
From: Michael Ellerman @ 2020-08-03 12:41 UTC (permalink / raw)
To: Michael Neuling; +Cc: grimm, linuxppc-dev, Michael Neuling
In-Reply-To: <20200803035600.1820371-1-mikey@neuling.org>
Michael Neuling <mikey@neuling.org> writes:
> On POWER10 bit 12 in the PVR indicates if the core is SMT4 or
> SMT8. Bit 12 is set for SMT4.
>
> Without this patch, /proc/cpuinfo on a SMT4 DD1 POWER10 looks like
> this:
> cpu : POWER10, altivec supported
> revision : 17.0 (pvr 0080 1100)
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> arch/powerpc/kernel/setup-common.c | 1 +
> 1 file changed, 1 insertion(+)
This should have a Fixes: pointing at something so it gets backported.
cheers
^ permalink raw reply
* Re: powerpc: build failures in Linus' tree
From: Stephen Rothwell @ 2020-08-03 12:31 UTC (permalink / raw)
To: Michael Ellerman
Cc: Linux-kernel Mailing List, Linus Torvalds, Paul Mackerras,
PowerPC, Willy Tarreau
In-Reply-To: <87v9i0yo47.fsf@mpe.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]
Hi Michael,
On Mon, 03 Aug 2020 21:18:00 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> If we just move the include of asm/paca.h below asm-generic/percpu.h
> then it avoids the bad circular dependency and we still have paca.h
> included from percpu.h as before.
>
> eg:
>
> diff --git a/arch/powerpc/include/asm/percpu.h b/arch/powerpc/include/asm/percpu.h
> index dce863a7635c..8e5b7d0b851c 100644
> --- a/arch/powerpc/include/asm/percpu.h
> +++ b/arch/powerpc/include/asm/percpu.h
> @@ -10,8 +10,6 @@
>
> #ifdef CONFIG_SMP
>
> -#include <asm/paca.h>
> -
> #define __my_cpu_offset local_paca->data_offset
>
> #endif /* CONFIG_SMP */
> @@ -19,4 +17,6 @@
>
> #include <asm-generic/percpu.h>
>
> +#include <asm/paca.h>
> +
> #endif /* _ASM_POWERPC_PERCPU_H_ */
>
>
> So I think I'm inclined to merge that as a minimal fix that's easy to
> backport.
>
> cheers
Looks ok, except does it matter that the include used to be only done
if __powerpc64__ and CONFIG_SMP are defined?
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: powerpc: build failures in Linus' tree
From: Willy Tarreau @ 2020-08-03 12:17 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, Linus Torvalds, Linux-kernel Mailing List,
Paul Mackerras, PowerPC
In-Reply-To: <87v9i0yo47.fsf@mpe.ellerman.id.au>
On Mon, Aug 03, 2020 at 09:18:00PM +1000, Michael Ellerman wrote:
> If we just move the include of asm/paca.h below asm-generic/percpu.h
> then it avoids the bad circular dependency and we still have paca.h
> included from percpu.h as before.
>
> eg:
>
> diff --git a/arch/powerpc/include/asm/percpu.h b/arch/powerpc/include/asm/percpu.h
> index dce863a7635c..8e5b7d0b851c 100644
> --- a/arch/powerpc/include/asm/percpu.h
> +++ b/arch/powerpc/include/asm/percpu.h
> @@ -10,8 +10,6 @@
>
> #ifdef CONFIG_SMP
>
> -#include <asm/paca.h>
> -
> #define __my_cpu_offset local_paca->data_offset
>
> #endif /* CONFIG_SMP */
> @@ -19,4 +17,6 @@
>
> #include <asm-generic/percpu.h>
>
> +#include <asm/paca.h>
> +
> #endif /* _ASM_POWERPC_PERCPU_H_ */
>
>
> So I think I'm inclined to merge that as a minimal fix that's easy to
> backport.
This totally makes sense indeed!
Willy
^ permalink raw reply
* Re: [PATCH v2] selftests/powerpc: Fix pkey syscall redefinitions
From: Sandipan Das @ 2020-08-03 11:35 UTC (permalink / raw)
To: Michael Ellerman; +Cc: sachinp, aneesh.kumar, linuxppc-dev
In-Reply-To: <8736540z3w.fsf@mpe.ellerman.id.au>
On 03/08/20 4:34 pm, Michael Ellerman wrote:
> Sandipan Das <sandipan@linux.ibm.com> writes:
>> On some distros, there are conflicts w.r.t to redefinition
>> of pkey syscall numbers which cause build failures. This
>> fixes them.
>>
>> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
>> Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
>> ---
>> Previous versions can be found at:
>> v1: https://lore.kernel.org/linuxppc-dev/20200803074043.466809-1-sandipan@linux.ibm.com/
>>
>> Changes in v2:
>> - Fix incorrect commit message.
>>
>> ---
>> tools/testing/selftests/powerpc/include/pkeys.h | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/tools/testing/selftests/powerpc/include/pkeys.h b/tools/testing/selftests/powerpc/include/pkeys.h
>> index 6ba95039a034..26eef5c1f8ea 100644
>> --- a/tools/testing/selftests/powerpc/include/pkeys.h
>> +++ b/tools/testing/selftests/powerpc/include/pkeys.h
>> @@ -31,8 +31,13 @@
>>
>> #define SI_PKEY_OFFSET 0x20
>>
>> +#undef SYS_pkey_mprotect
>> #define SYS_pkey_mprotect 386
>
> We shouldn't undef them.
>
> They should obviously never change, but if the system headers already
> have a definition then we should use that, so I think it should be:
>
> #ifndef SYS_pkey_mprotect
> #define SYS_pkey_mprotect 386
> #endif
>
Agreed. This had me confused.
$ grep -nr "#define __NR_pkey_" /usr/include/
/usr/include/asm-generic/unistd.h:767:#define __NR_pkey_mprotect 288
/usr/include/asm-generic/unistd.h:769:#define __NR_pkey_alloc 289
/usr/include/asm-generic/unistd.h:771:#define __NR_pkey_free 290
/usr/include/powerpc64le-linux-gnu/asm/unistd_32.h:374:#define __NR_pkey_alloc 384
/usr/include/powerpc64le-linux-gnu/asm/unistd_32.h:375:#define __NR_pkey_free 385
/usr/include/powerpc64le-linux-gnu/asm/unistd_32.h:376:#define __NR_pkey_mprotect 386
/usr/include/powerpc64le-linux-gnu/asm/unistd_64.h:365:#define __NR_pkey_alloc 384
/usr/include/powerpc64le-linux-gnu/asm/unistd_64.h:366:#define __NR_pkey_free 385
/usr/include/powerpc64le-linux-gnu/asm/unistd_64.h:367:#define __NR_pkey_mprotect 386
...
But it looks like including unistd.h from a C program picks the
right values.
- Sandipan
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Use address-of operator on section symbols
From: Geert Uytterhoeven @ 2020-08-03 11:32 UTC (permalink / raw)
To: Michael Ellerman
Cc: Arnd Bergmann, Geoff Levand, Linux Kernel Mailing List,
clang-built-linux, Paul Mackerras, Joel Stanley,
Nathan Chancellor, linuxppc-dev
In-Reply-To: <87zh7cyoi7.fsf@mpe.ellerman.id.au>
Hi Michael,
On Mon, Aug 3, 2020 at 1:09 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
> > On Mon, Jul 20, 2020 at 11:03 PM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> >> On Sat, Jul 18, 2020 at 09:50:50AM +0200, Geert Uytterhoeven wrote:
> >> > On Wed, Jun 24, 2020 at 6:02 AM Nathan Chancellor
> >> > <natechancellor@gmail.com> wrote:
> >> > > /* If we have an image attached to us, it overrides anything
> >> > > * supplied by the loader. */
> >> > > - if (_initrd_end > _initrd_start) {
> >> > > + if (&_initrd_end > &_initrd_start) {
> >> >
> >> > Are you sure that fix is correct?
> >> >
> >> > extern char _initrd_start[];
> >> > extern char _initrd_end[];
> >> > extern char _esm_blob_start[];
> >> > extern char _esm_blob_end[];
> >> >
> >> > Of course the result of their comparison is a constant, as the addresses
> >> > are constant. If clangs warns about it, perhaps that warning should be moved
> >> > to W=1?
> >> >
> >> > But adding "&" is not correct, according to C.
> >>
> >> Why not?
> >>
> >> 6.5.3.2/3
> >> The unary & operator yields the address of its operand. [...]
> >> Otherwise, the result is a pointer to the object or function designated
> >> by its operand.
> >>
> >> This is the same as using the name of an array without anything else,
> >> yes. It is a bit clearer if it would not be declared as array, perhaps,
> >> but it is correct just fine like this.
> >
> > Thanks, I stand corrected.
> >
> > Regardless, the comparison is still a comparison between two constant
> > addresses, so my fear is that the compiler will start generating
> > warnings for that in the near or distant future, making this change
> > futile.
>
> They're not constant at compile time though. So I don't think the
> compiler could (sensibly) warn about that? (surely!)
They're constant, but the compiler doesn't know their value.
That doesn't change by (not) using the address-of operator.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
* Re: [merge] Build failure selftest/powerpc/mm/pkey_exec_prot
From: Sandipan Das @ 2020-08-03 11:27 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Sachin Sant, linuxppc-dev
In-Reply-To: <875za00z75.fsf@mpe.ellerman.id.au>
Hi Michael,
On 03/08/20 4:32 pm, Michael Ellerman wrote:
> Sachin Sant <sachinp@linux.vnet.ibm.com> writes:
>>> On 02-Aug-2020, at 10:58 PM, Sandipan Das <sandipan@linux.ibm.com> wrote:
>>> On 02/08/20 4:45 pm, Sachin Sant wrote:
>>>> pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
>>>> build due to following error:
>>>>
>>>> gcc -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1276-g3f68564f1f5a"' -I/home/sachin/linux/tools/testing/selftests/powerpc/include -m64 pkey_exec_prot.c /home/sachin/linux/tools/testing/selftests/kselftest_harness.h /home/sachin/linux/tools/testing/selftests/kselftest.h ../harness.c ../utils.c -o /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_exec_prot
>>>> In file included from pkey_exec_prot.c:18:
>>>> /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:34: error: "SYS_pkey_mprotect" redefined [-Werror]
>>>> #define SYS_pkey_mprotect 386
>>>>
>>>> In file included from /usr/include/sys/syscall.h:31,
>>>> from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
>>>> from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
>>>> from pkey_exec_prot.c:18:
>>>> /usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
>>>> # define SYS_pkey_mprotect __NR_pkey_mprotect
>>>>
>>>> commit 128d3d021007 introduced this error.
>>>> selftests/powerpc: Move pkey helpers to headers
>>>>
>>>> Possibly the # defines for sys calls can be retained in pkey_exec_prot.c or
>>>>
>>>
>>> I am unable to reproduce this on the latest merge branch (HEAD at f59195f7faa4).
>>> I don't see any redefinitions in pkey_exec_prot.c either.
>>>
>>
>> I can still see this problem on latest merge branch.
>> I have following gcc version
>>
>> gcc version 8.3.1 20191121
>
> What libc version? Or just the distro & version?
>
Sachin observed this on RHEL 8.2 with glibc-2.28.
I couldn't reproduce it on Ubuntu 20.04 and Fedora 32 and both these distros
are using glibc-2.31.
- Sandipan
^ permalink raw reply
* [PATCH v3] selftests/powerpc: Fix pkey syscall redefinitions
From: Sandipan Das @ 2020-08-03 11:23 UTC (permalink / raw)
To: mpe; +Cc: sachinp, aneesh.kumar, linuxppc-dev
On some distros, there are conflicts w.r.t to redefinition
of pkey syscall numbers which cause build failures. This
fixes them.
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
Previous versions can be found at:
v2: https://lore.kernel.org/linuxppc-dev/566dde119ce71f00f9642807ba30ceb7f54c9bfa.1596441105.git.sandipan@linux.ibm.com/
v1: https://lore.kernel.org/linuxppc-dev/20200803074043.466809-1-sandipan@linux.ibm.com/
Changes in v3:
- Use ifndef...endif instead of undef as suggested by
Michael.
Changes in v2:
- Fix incorrect commit message.
---
tools/testing/selftests/powerpc/include/pkeys.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/tools/testing/selftests/powerpc/include/pkeys.h b/tools/testing/selftests/powerpc/include/pkeys.h
index 6ba95039a034..54bf9aa9e1e1 100644
--- a/tools/testing/selftests/powerpc/include/pkeys.h
+++ b/tools/testing/selftests/powerpc/include/pkeys.h
@@ -31,9 +31,17 @@
#define SI_PKEY_OFFSET 0x20
+#ifndef SYS_pkey_mprotect
#define SYS_pkey_mprotect 386
+#endif
+
+#ifndef SYS_pkey_alloc
#define SYS_pkey_alloc 384
+#endif
+
+#ifndef SYS_pkey_free
#define SYS_pkey_free 385
+#endif
#define PKEY_BITS_PER_PKEY 2
#define NR_PKEYS 32
--
2.25.1
^ permalink raw reply related
* Re: powerpc: build failures in Linus' tree
From: Michael Ellerman @ 2020-08-03 11:18 UTC (permalink / raw)
To: Willy Tarreau, Stephen Rothwell
Cc: PowerPC, Paul Mackerras, Linux-kernel Mailing List,
Linus Torvalds
In-Reply-To: <20200803034547.GA15501@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
> On Sun, Aug 02, 2020 at 07:20:19PM +0200, Willy Tarreau wrote:
>> On Sun, Aug 02, 2020 at 08:48:42PM +1000, Stephen Rothwell wrote:
>> > Hi all,
>> >
>> > We are getting build failures in some PowerPC configs for Linus' tree.
>> > See e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/14306515/
>> >
>> > In file included from /kisskb/src/arch/powerpc/include/asm/paca.h:18,
>> > from /kisskb/src/arch/powerpc/include/asm/percpu.h:13,
>> > from /kisskb/src/include/linux/random.h:14,
>> > from /kisskb/src/include/linux/net.h:18,
>> > from /kisskb/src/net/ipv6/ip6_fib.c:20:
>> > /kisskb/src/arch/powerpc/include/asm/mmu.h:139:22: error: unknown type name 'next_tlbcam_idx'
>> > 139 | DECLARE_PER_CPU(int, next_tlbcam_idx);
>> >
>> > I assume this is caused by commit
>> >
>> > 1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
>> >
>> > But I can't see how, sorry.
>>
>> So there, asm/mmu.h includes asm/percpu.h, which includes asm/paca.h, which
>> includes asm/mmu.h.
>>
>> I suspect that we can remove asm/paca.h from asm/percpu.h as it *seems*
>> to be only used by the #define __my_cpu_offset but I don't know if anything
>> will break further, especially if this __my_cpu_offset is used anywhere
>> without this paca definition.
>
> I tried this and it fixed 5.8 for me with your config above. I'm appending
> a patch that does just this. I didn't test other configs as I don't know
> which ones to test though. If it fixes the problem for you, maybe it can
> be picked by the PPC maintainers.
>
> Willy
> From bcd64a7d0f3445c9a75d3b4dc4837d2ce61660c9 Mon Sep 17 00:00:00 2001
> From: Willy Tarreau <w@1wt.eu>
> Date: Mon, 3 Aug 2020 05:27:57 +0200
> Subject: powerpc: fix circular dependency in percpu.h
>
> After random.h started to include percpu.h (commit f227e3e), several
> archs broke in circular dependencies around percpu.h.
>
> In https://lore.kernel.org/lkml/20200802204842.36bca162@canb.auug.org.au/
> Stephen Rothwell reported breakage for powerpc with CONFIG_PPC_FSL_BOOK3E.
>
> It turns out that asm/percpu.h includes asm/paca.h, which itself
> includes mmu.h, which includes percpu.h when CONFIG_PPC_FSL_BOOK3E=y.
>
> Percpu seems to include asm/paca.h only for local_paca which is used in
> the __my_cpu_offset macro. Removing this include solves the issue for
> this config.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Fixes: f227e3e ("random32: update the net random state on interrupt and activity")
> Link: https://lore.kernel.org/lkml/20200802204842.36bca162@canb.auug.org.au/
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> arch/powerpc/include/asm/percpu.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/percpu.h b/arch/powerpc/include/asm/percpu.h
> index dce863a..cd3f6e5 100644
> --- a/arch/powerpc/include/asm/percpu.h
> +++ b/arch/powerpc/include/asm/percpu.h
> @@ -10,8 +10,6 @@
>
> #ifdef CONFIG_SMP
>
> -#include <asm/paca.h>
> -
> #define __my_cpu_offset local_paca->data_offset
>
> #endif /* CONFIG_SMP */
If we just move the include of asm/paca.h below asm-generic/percpu.h
then it avoids the bad circular dependency and we still have paca.h
included from percpu.h as before.
eg:
diff --git a/arch/powerpc/include/asm/percpu.h b/arch/powerpc/include/asm/percpu.h
index dce863a7635c..8e5b7d0b851c 100644
--- a/arch/powerpc/include/asm/percpu.h
+++ b/arch/powerpc/include/asm/percpu.h
@@ -10,8 +10,6 @@
#ifdef CONFIG_SMP
-#include <asm/paca.h>
-
#define __my_cpu_offset local_paca->data_offset
#endif /* CONFIG_SMP */
@@ -19,4 +17,6 @@
#include <asm-generic/percpu.h>
+#include <asm/paca.h>
+
#endif /* _ASM_POWERPC_PERCPU_H_ */
So I think I'm inclined to merge that as a minimal fix that's easy to
backport.
cheers
^ permalink raw reply related
* Re: [PATCH] powerpc/boot: Use address-of operator on section symbols
From: Michael Ellerman @ 2020-08-03 11:09 UTC (permalink / raw)
To: Geert Uytterhoeven, Segher Boessenkool
Cc: Arnd Bergmann, Geoff Levand, Linux Kernel Mailing List,
clang-built-linux, Paul Mackerras, Joel Stanley,
Nathan Chancellor, linuxppc-dev
In-Reply-To: <CAMuHMdUmHE-KVQuo=b2rn9EPgmnqSDi4i16NPbL5rXLLSCoyKg@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Mon, Jul 20, 2020 at 11:03 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
>> On Sat, Jul 18, 2020 at 09:50:50AM +0200, Geert Uytterhoeven wrote:
>> > On Wed, Jun 24, 2020 at 6:02 AM Nathan Chancellor
>> > <natechancellor@gmail.com> wrote:
>> > > /* If we have an image attached to us, it overrides anything
>> > > * supplied by the loader. */
>> > > - if (_initrd_end > _initrd_start) {
>> > > + if (&_initrd_end > &_initrd_start) {
>> >
>> > Are you sure that fix is correct?
>> >
>> > extern char _initrd_start[];
>> > extern char _initrd_end[];
>> > extern char _esm_blob_start[];
>> > extern char _esm_blob_end[];
>> >
>> > Of course the result of their comparison is a constant, as the addresses
>> > are constant. If clangs warns about it, perhaps that warning should be moved
>> > to W=1?
>> >
>> > But adding "&" is not correct, according to C.
>>
>> Why not?
>>
>> 6.5.3.2/3
>> The unary & operator yields the address of its operand. [...]
>> Otherwise, the result is a pointer to the object or function designated
>> by its operand.
>>
>> This is the same as using the name of an array without anything else,
>> yes. It is a bit clearer if it would not be declared as array, perhaps,
>> but it is correct just fine like this.
>
> Thanks, I stand corrected.
>
> Regardless, the comparison is still a comparison between two constant
> addresses, so my fear is that the compiler will start generating
> warnings for that in the near or distant future, making this change
> futile.
They're not constant at compile time though. So I don't think the
compiler could (sensibly) warn about that? (surely!)
cheers
^ permalink raw reply
* Re: [PATCH v2] selftests/powerpc: Fix pkey syscall redefinitions
From: Michael Ellerman @ 2020-08-03 11:04 UTC (permalink / raw)
To: Sandipan Das; +Cc: sachinp, aneesh.kumar, linuxppc-dev
In-Reply-To: <566dde119ce71f00f9642807ba30ceb7f54c9bfa.1596441105.git.sandipan@linux.ibm.com>
Sandipan Das <sandipan@linux.ibm.com> writes:
> On some distros, there are conflicts w.r.t to redefinition
> of pkey syscall numbers which cause build failures. This
> fixes them.
>
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
> ---
> Previous versions can be found at:
> v1: https://lore.kernel.org/linuxppc-dev/20200803074043.466809-1-sandipan@linux.ibm.com/
>
> Changes in v2:
> - Fix incorrect commit message.
>
> ---
> tools/testing/selftests/powerpc/include/pkeys.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/tools/testing/selftests/powerpc/include/pkeys.h b/tools/testing/selftests/powerpc/include/pkeys.h
> index 6ba95039a034..26eef5c1f8ea 100644
> --- a/tools/testing/selftests/powerpc/include/pkeys.h
> +++ b/tools/testing/selftests/powerpc/include/pkeys.h
> @@ -31,8 +31,13 @@
>
> #define SI_PKEY_OFFSET 0x20
>
> +#undef SYS_pkey_mprotect
> #define SYS_pkey_mprotect 386
We shouldn't undef them.
They should obviously never change, but if the system headers already
have a definition then we should use that, so I think it should be:
#ifndef SYS_pkey_mprotect
#define SYS_pkey_mprotect 386
#endif
cheers
^ permalink raw reply
* Re: [merge] Build failure selftest/powerpc/mm/pkey_exec_prot
From: Michael Ellerman @ 2020-08-03 11:02 UTC (permalink / raw)
To: Sachin Sant, Sandipan Das; +Cc: linuxppc-dev
In-Reply-To: <C44DC5C2-5133-49AA-BAA6-58E334EB70BA@linux.vnet.ibm.com>
Sachin Sant <sachinp@linux.vnet.ibm.com> writes:
>> On 02-Aug-2020, at 10:58 PM, Sandipan Das <sandipan@linux.ibm.com> wrote:
>> On 02/08/20 4:45 pm, Sachin Sant wrote:
>>> pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
>>> build due to following error:
>>>
>>> gcc -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1276-g3f68564f1f5a"' -I/home/sachin/linux/tools/testing/selftests/powerpc/include -m64 pkey_exec_prot.c /home/sachin/linux/tools/testing/selftests/kselftest_harness.h /home/sachin/linux/tools/testing/selftests/kselftest.h ../harness.c ../utils.c -o /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_exec_prot
>>> In file included from pkey_exec_prot.c:18:
>>> /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:34: error: "SYS_pkey_mprotect" redefined [-Werror]
>>> #define SYS_pkey_mprotect 386
>>>
>>> In file included from /usr/include/sys/syscall.h:31,
>>> from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
>>> from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
>>> from pkey_exec_prot.c:18:
>>> /usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
>>> # define SYS_pkey_mprotect __NR_pkey_mprotect
>>>
>>> commit 128d3d021007 introduced this error.
>>> selftests/powerpc: Move pkey helpers to headers
>>>
>>> Possibly the # defines for sys calls can be retained in pkey_exec_prot.c or
>>>
>>
>> I am unable to reproduce this on the latest merge branch (HEAD at f59195f7faa4).
>> I don't see any redefinitions in pkey_exec_prot.c either.
>>
>
> I can still see this problem on latest merge branch.
> I have following gcc version
>
> gcc version 8.3.1 20191121
What libc version? Or just the distro & version?
cheers
> # git show
> commit f59195f7faa4896b7c1d947ac2dba29ec18ad569 (HEAD -> merge, origin/merge)
> Merge: 70ce795dac09 ac3a0c847296
> Author: Michael Ellerman <mpe@ellerman.id.au>
> Date: Sun Aug 2 23:18:03 2020 +1000
>
> Automatic merge of 'master', 'next' and 'fixes' (2020-08-02 23:18)
>
> # make -C powerpc
> ……
> …...
> BUILD_TARGET=/home/sachin/linux/tools/testing/selftests/powerpc/mm; mkdir -p $BUILD_TARGET; make OUTPUT=$BUILD_TARGET -k -C mm all
> make[1]: Entering directory '/home/sachin/linux/tools/testing/selftests/powerpc/mm'
> gcc -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1456-gf59195f7faa4"' -I/home/sachin/linux/tools/testing/selftests/powerpc/include -m64 pkey_exec_prot.c /home/sachin/linux/tools/testing/selftests/kselftest_harness.h /home/sachin/linux/tools/testing/selftests/kselftest.h ../harness.c ../utils.c -o /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_exec_prot
> In file included from pkey_exec_prot.c:18:
> /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:34: error: "SYS_pkey_mprotect" redefined [-Werror]
> #define SYS_pkey_mprotect 386
>
> In file included from /usr/include/sys/syscall.h:31,
> from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
> from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
> from pkey_exec_prot.c:18:
> /usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
> # define SYS_pkey_mprotect __NR_pkey_mprotect
^ permalink raw reply
* Re: [PATCH] powerpc: Fix P10 PVR revision in /proc/cpuinfo for SMT4 cores
From: Vaidyanathan Srinivasan @ 2020-08-03 10:32 UTC (permalink / raw)
To: Michael Neuling; +Cc: grimm, linuxppc-dev
In-Reply-To: <20200803035600.1820371-1-mikey@neuling.org>
* Michael Neuling <mikey@neuling.org> [2020-08-03 13:56:00]:
> On POWER10 bit 12 in the PVR indicates if the core is SMT4 or
> SMT8. Bit 12 is set for SMT4.
>
> Without this patch, /proc/cpuinfo on a SMT4 DD1 POWER10 looks like
> this:
> cpu : POWER10, altivec supported
> revision : 17.0 (pvr 0080 1100)
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com>
> ---
> arch/powerpc/kernel/setup-common.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> index b198b0ff25..808ec9fab6 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -311,6 +311,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
> min = pvr & 0xFF;
> break;
> case 0x004e: /* POWER9 bits 12-15 give chip type */
> + case 0x0080: /* POWER10 bit 12 gives SMT8/4 */
Correct. P9 and P10 have chip type (smt4 vs smt8 core) encoded in bits
PVR chip type bits 12-15.
Thanks for the fix.
--Vaidy
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Use address-of operator on section symbols
From: Geert Uytterhoeven @ 2020-08-03 10:06 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Arnd Bergmann, Geoff Levand, Linux Kernel Mailing List,
clang-built-linux, Paul Mackerras, Joel Stanley,
Nathan Chancellor, linuxppc-dev
In-Reply-To: <20200720210252.GO30544@gate.crashing.org>
Hi Segher,
On Mon, Jul 20, 2020 at 11:03 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> On Sat, Jul 18, 2020 at 09:50:50AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Jun 24, 2020 at 6:02 AM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > > /* If we have an image attached to us, it overrides anything
> > > * supplied by the loader. */
> > > - if (_initrd_end > _initrd_start) {
> > > + if (&_initrd_end > &_initrd_start) {
> >
> > Are you sure that fix is correct?
> >
> > extern char _initrd_start[];
> > extern char _initrd_end[];
> > extern char _esm_blob_start[];
> > extern char _esm_blob_end[];
> >
> > Of course the result of their comparison is a constant, as the addresses
> > are constant. If clangs warns about it, perhaps that warning should be moved
> > to W=1?
> >
> > But adding "&" is not correct, according to C.
>
> Why not?
>
> 6.5.3.2/3
> The unary & operator yields the address of its operand. [...]
> Otherwise, the result is a pointer to the object or function designated
> by its operand.
>
> This is the same as using the name of an array without anything else,
> yes. It is a bit clearer if it would not be declared as array, perhaps,
> but it is correct just fine like this.
Thanks, I stand corrected.
Regardless, the comparison is still a comparison between two constant
addresses, so my fear is that the compiler will start generating
warnings for that in the near or distant future, making this change
futile.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
* Re: Build regressions/improvements in v5.8
From: Geert Uytterhoeven @ 2020-08-03 9:57 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: sparclinux, linuxppc-dev
In-Reply-To: <20200803095048.20102-1-geert@linux-m68k.org>
On Mon, Aug 3, 2020 at 11:53 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> JFYI, when comparing v5.8[1] to v5.8-rc7[3], the summaries are:
> - build errors: +2/-3
+ /kisskb/src/arch/powerpc/include/asm/mmu.h: error: unknown type
name 'next_tlbcam_idx': => 139:22
v5.8/powerpc-gcc4.9/corenet64_smp_defconfig
v5.8/powerpc-gcc4.9/ppc64_book3e_allmodconfig
v5.8/powerpc-gcc4.9/ppc64e_defconfig
v5.8/powerpc-gcc9/ppc64_book3e_allmodconfig
(fix available)
+ /kisskb/src/arch/sparc/include/asm/trap_block.h: error: 'NR_CPUS'
undeclared here (not in a function): => 54:39
v5.8/sparc64/sparc64-allmodconfig
v5.8/sparc64/sparc64-defconfig
> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/bcf876870b95592b52519ed4aafcf9d95999bc9c/ (192 out of 194 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/92ed301919932f777713b9172e525674157e983d/ (192 out of 194 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Clean code for synchronize mode
From: Shengjiu Wang @ 2020-08-03 8:04 UTC (permalink / raw)
To: Nicolin Chen
Cc: Linux-ALSA, Timur Tabi, Xiubo Li, Fabio Estevam, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, Mark Brown, linuxppc-dev,
linux-kernel
In-Reply-To: <20200803054037.GA1056@Asurada-Nvidia>
On Mon, Aug 3, 2020 at 1:42 PM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> On Mon, Aug 03, 2020 at 11:17:54AM +0800, Shengjiu Wang wrote:
> > TX synchronous with RX: The RMR is no need to be changed when
> > Tx is enabled, the other configuration in hw_params() is enough for
>
> Probably you should explain why RMR can be removed, like what
> it really does so as to make it clear that there's no such a
> relationship between RMR and clock generating.
>
> Anyway, this is against the warning comments in the driver:
> /*
> * For SAI master mode, when Tx(Rx) sync with Rx(Tx) clock, Rx(Tx) will
> * generate bclk and frame clock for Tx(Rx), we should set RCR4(TCR4),
> * RCR5(TCR5) and RMR(TMR) for playback(capture), or there will be sync
> * error.
> */
>
> So would need to update it.
>
> > clock generation. The TCSR.TE is no need to enabled when only RX
> > is enabled.
>
> You are correct if there's only RX running without TX joining.
> However, that's something we can't guarantee. Then we'd enable
> TE after RE is enabled, which is against what RM recommends:
>
> # From 54.3.3.1 Synchronous mode in IMX6SXRM
> # If the receiver bit clock and frame sync are to be used by
> # both the transmitter and receiver, it is recommended that
> # the receiver is the last enabled and the first disabled.
>
> I remember I did this "ugly" design by strictly following what
> RM says. If hardware team has updated the RM or removed this
> limitation, please quote in the commit logs.
There is no change in RM and same recommandation.
My change does not violate the RM. The direction which generates
the clock is still last enabled.
>
> > + if (!sai->synchronous[TX] && sai->synchronous[RX] && !tx) {
> > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR((!tx), ofs),
> > + FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
> > + } else if (!sai->synchronous[RX] && sai->synchronous[TX] && tx) {
> > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR((!tx), ofs),
> > + FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
>
> Two identical regmap_update_bits calls -- both on !tx (RX?)
The content for regmap_update_bits is the same, but the precondition
is different.
The first one is for tx=false and enable TCSR.TE. (TX generate clock)
The second one is for tx=true and enable RSCR.RE (RX generate clock)
best regards
wang shengjiu
^ permalink raw reply
* [PATCH v2] selftests/powerpc: Fix pkey syscall redefinitions
From: Sandipan Das @ 2020-08-03 7:55 UTC (permalink / raw)
To: mpe; +Cc: sachinp, aneesh.kumar, linuxppc-dev
On some distros, there are conflicts w.r.t to redefinition
of pkey syscall numbers which cause build failures. This
fixes them.
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
Previous versions can be found at:
v1: https://lore.kernel.org/linuxppc-dev/20200803074043.466809-1-sandipan@linux.ibm.com/
Changes in v2:
- Fix incorrect commit message.
---
tools/testing/selftests/powerpc/include/pkeys.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tools/testing/selftests/powerpc/include/pkeys.h b/tools/testing/selftests/powerpc/include/pkeys.h
index 6ba95039a034..26eef5c1f8ea 100644
--- a/tools/testing/selftests/powerpc/include/pkeys.h
+++ b/tools/testing/selftests/powerpc/include/pkeys.h
@@ -31,8 +31,13 @@
#define SI_PKEY_OFFSET 0x20
+#undef SYS_pkey_mprotect
#define SYS_pkey_mprotect 386
+
+#undef SYS_pkey_alloc
#define SYS_pkey_alloc 384
+
+#undef SYS_pkey_free
#define SYS_pkey_free 385
#define PKEY_BITS_PER_PKEY 2
--
2.25.1
^ permalink raw reply related
* [PATCH] powerpc/powernv/sriov: Fix use of uninitialised variable
From: Oliver O'Halloran @ 2020-08-03 7:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nathan Chancellor, Oliver O'Halloran
Initialising the value before using it is generally regarded as a good
idea so do that.
Fixes: 4c51f3e1e870 ("powerpc/powernv/sriov: Make single PE mode a per-BAR setting")
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
---
arch/powerpc/platforms/powernv/pci-sriov.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-sriov.c b/arch/powerpc/platforms/powernv/pci-sriov.c
index 7894745fd4f8..c4434f20f42f 100644
--- a/arch/powerpc/platforms/powernv/pci-sriov.c
+++ b/arch/powerpc/platforms/powernv/pci-sriov.c
@@ -253,9 +253,9 @@ void pnv_pci_ioda_fixup_iov(struct pci_dev *pdev)
resource_size_t pnv_pci_iov_resource_alignment(struct pci_dev *pdev,
int resno)
{
+ resource_size_t align = pci_iov_resource_size(pdev, resno);
struct pnv_phb *phb = pci_bus_to_pnvhb(pdev->bus);
struct pnv_iov_data *iov = pnv_iov_get(pdev);
- resource_size_t align;
/*
* iov can be null if we have an SR-IOV device with IOV BAR that can't
@@ -266,8 +266,6 @@ resource_size_t pnv_pci_iov_resource_alignment(struct pci_dev *pdev,
if (!iov)
return align;
- align = pci_iov_resource_size(pdev, resno);
-
/*
* If we're using single mode then we can just use the native VF BAR
* alignment. We validated that it's possible to use a single PE
--
2.26.2
^ permalink raw reply related
* [PATCH] selftests/powerpc: Fix pkey syscall redefinitions
From: Sandipan Das @ 2020-08-03 7:40 UTC (permalink / raw)
To: mpe; +Cc: sachinp, aneesh.kumar, linuxppc-dev
Some distros have the pkey syscall numbers defined under
unistd.h. This conflicts with the definitions in the pkeys
selftest header and causes build failures.
E.g. this works
$ grep -nr "SYS_pkey" /usr/include/
/usr/include/bits/syscall.h:1575:# define SYS_pkey_alloc __NR_pkey_alloc
/usr/include/bits/syscall.h:1579:# define SYS_pkey_free __NR_pkey_free
/usr/include/bits/syscall.h:1583:# define SYS_pkey_mprotect __NR_pkey_mprotect
While this does not
$ grep -nr "SYS_pkey" /usr/include/
/usr/include/bits/syscall.h:1575:# define SYS_pkey_alloc __NR_pkey_alloc
/usr/include/bits/syscall.h:1579:# define SYS_pkey_free __NR_pkey_free
/usr/include/bits/syscall.h:1583:# define SYS_pkey_mprotect __NR_pkey_mprotect
/usr/include/asm-generic/unistd.h:728:__SYSCALL(__NR_pkey_mprotect, sys_pkey_mprotect)
/usr/include/asm-generic/unistd.h:730:__SYSCALL(__NR_pkey_alloc, sys_pkey_alloc)
/usr/include/asm-generic/unistd.h:732:__SYSCALL(__NR_pkey_free, sys_pkey_free)
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
tools/testing/selftests/powerpc/include/pkeys.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tools/testing/selftests/powerpc/include/pkeys.h b/tools/testing/selftests/powerpc/include/pkeys.h
index 6ba95039a034..26eef5c1f8ea 100644
--- a/tools/testing/selftests/powerpc/include/pkeys.h
+++ b/tools/testing/selftests/powerpc/include/pkeys.h
@@ -31,8 +31,13 @@
#define SI_PKEY_OFFSET 0x20
+#undef SYS_pkey_mprotect
#define SYS_pkey_mprotect 386
+
+#undef SYS_pkey_alloc
#define SYS_pkey_alloc 384
+
+#undef SYS_pkey_free
#define SYS_pkey_free 385
#define PKEY_BITS_PER_PKEY 2
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 2/2 v2] powerpc/powernv: Enable and setup PCI P2P
From: Oliver O'Halloran @ 2020-08-03 7:35 UTC (permalink / raw)
To: Max Gurtovoy
Cc: vladimirk, Carol L Soto, linux-pci, shlomin, israelr,
Frederic Barrat, idanw, linuxppc-dev, Christoph Hellwig, aneela
In-Reply-To: <20200430131520.51211-2-maxg@mellanox.com>
On Thu, Apr 30, 2020 at 11:15 PM Max Gurtovoy <maxg@mellanox.com> wrote:
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 57d3a6a..9ecc576 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -3706,18 +3706,208 @@ static void pnv_pci_ioda_dma_bus_setup(struct pci_bus *bus)
> }
> }
>
> +#ifdef CONFIG_PCI_P2PDMA
> +static DEFINE_MUTEX(p2p_mutex);
> +
> +static bool pnv_pci_controller_owns_addr(struct pci_controller *hose,
> + phys_addr_t addr, size_t size)
> +{
> + int i;
> +
> + /*
> + * It seems safe to assume the full range is under the same PHB, so we
> + * can ignore the size.
> + */
> + for (i = 0; i < ARRAY_SIZE(hose->mem_resources); i++) {
> + struct resource *res = &hose->mem_resources[i];
> +
> + if (res->flags && addr >= res->start && addr < res->end)
> + return true;
> + }
> + return false;
> +}
> +
> +/*
> + * find the phb owning a mmio address if not owned locally
> + */
> +static struct pnv_phb *pnv_pci_find_owning_phb(struct pci_dev *pdev,
> + phys_addr_t addr, size_t size)
> +{
> + struct pci_controller *hose;
> +
> + /* fast path */
> + if (pnv_pci_controller_owns_addr(pdev->bus->sysdata, addr, size))
> + return NULL;
Do we actually need this fast path? It's going to be slow either way.
Also if a device is doing p2p to another device under the same PHB
then it should not be happening via the root complex. Is this a case
you've tested?
> + list_for_each_entry(hose, &hose_list, list_node) {
> + struct pnv_phb *phb = hose->private_data;
> +
> + if (phb->type != PNV_PHB_NPU_NVLINK &&
> + phb->type != PNV_PHB_NPU_OCAPI) {
> + if (pnv_pci_controller_owns_addr(hose, addr, size))
> + return phb;
> + }
> + }
> + return NULL;
> +}
> +
> +static u64 pnv_pci_dma_dir_to_opal_p2p(enum dma_data_direction dir)
> +{
> + if (dir == DMA_TO_DEVICE)
> + return OPAL_PCI_P2P_STORE;
> + else if (dir == DMA_FROM_DEVICE)
> + return OPAL_PCI_P2P_LOAD;
> + else if (dir == DMA_BIDIRECTIONAL)
> + return OPAL_PCI_P2P_LOAD | OPAL_PCI_P2P_STORE;
> + else
> + return 0;
> +}
> +
> +static int pnv_pci_ioda_enable_p2p(struct pci_dev *initiator,
> + struct pnv_phb *phb_target,
> + enum dma_data_direction dir)
> +{
> + struct pci_controller *hose;
> + struct pnv_phb *phb_init;
> + struct pnv_ioda_pe *pe_init;
> + u64 desc;
> + int rc;
> +
> + if (!opal_check_token(OPAL_PCI_SET_P2P))
> + return -ENXIO;
> +
> + hose = pci_bus_to_host(initiator->bus);
> + phb_init = hose->private_data;
You can use the pci_bus_to_pnvhb() helper
> +
> + pe_init = pnv_ioda_get_pe(initiator);
> + if (!pe_init)
> + return -ENODEV;
> +
> + if (!pe_init->tce_bypass_enabled)
> + return -EINVAL;
> +
> + /*
> + * Configuring the initiator's PHB requires to adjust its TVE#1
> + * setting. Since the same device can be an initiator several times for
> + * different target devices, we need to keep a reference count to know
> + * when we can restore the default bypass setting on its TVE#1 when
> + * disabling. Opal is not tracking PE states, so we add a reference
> + * count on the PE in linux.
> + *
> + * For the target, the configuration is per PHB, so we keep a
> + * target reference count on the PHB.
> + */
This irks me a bit because configuring the DMA address limits for the
TVE is the kernel's job. What we really should be doing is using
opal_pci_map_pe_dma_window_real() to set the bypass-mode address limit
for the TVE to something large enough to hit the MMIO ranges rather
than having set_p2p do it as a side effect. Unfortunately, for some
reason skiboot doesn't implement support for enabling 56bit addressing
using opal_pci_map_pe_dma_window_real() and we do need to support
older kernel's which used this stuff so I guess we're stuck with it
for now. It'd be nice if we could fix this in the longer term
though...
> + mutex_lock(&p2p_mutex);
> +
> + desc = OPAL_PCI_P2P_ENABLE | pnv_pci_dma_dir_to_opal_p2p(dir);
> + /* always go to opal to validate the configuration */
> + rc = opal_pci_set_p2p(phb_init->opal_id, phb_target->opal_id, desc,
> + pe_init->pe_number);
> + if (rc != OPAL_SUCCESS) {
> + rc = -EIO;
> + goto out;
> + }
> +
> + pe_init->p2p_initiator_count++;
> + phb_target->p2p_target_count++;
> +
> + rc = 0;
> +out:
> + mutex_unlock(&p2p_mutex);
> + return rc;
> +}
> +
> +static int pnv_pci_dma_map_resource(struct pci_dev *pdev,
> + phys_addr_t phys_addr, size_t size,
> + enum dma_data_direction dir)
> +{
> + struct pnv_phb *target_phb;
> +
> + target_phb = pnv_pci_find_owning_phb(pdev, phys_addr, size);
> + if (!target_phb)
> + return 0;
> +
> + return pnv_pci_ioda_enable_p2p(pdev, target_phb, dir);
> +}
> +
> +static int pnv_pci_ioda_disable_p2p(struct pci_dev *initiator,
> + struct pnv_phb *phb_target)
> +{
> + struct pci_controller *hose;
> + struct pnv_phb *phb_init;
> + struct pnv_ioda_pe *pe_init;
> + int rc;
> +
> + if (!opal_check_token(OPAL_PCI_SET_P2P))
> + return -ENXIO;
This should probably have a WARN_ON() since we can't hit this path
unless the initial map succeeds.
> + hose = pci_bus_to_host(initiator->bus);
> + phb_init = hose->private_data;
pci_bus_to_pnvhb()
> + pe_init = pnv_ioda_get_pe(initiator);
> + if (!pe_init)
> + return -ENODEV;
> +
> + mutex_lock(&p2p_mutex);
> +
> + if (!pe_init->p2p_initiator_count || !phb_target->p2p_target_count) {
> + rc = -EINVAL;
> + goto out;
> + }
> +
> + if (--pe_init->p2p_initiator_count == 0)
> + pnv_pci_ioda2_set_bypass(pe_init, true);
> +
> + if (--phb_target->p2p_target_count == 0) {
> + rc = opal_pci_set_p2p(phb_init->opal_id, phb_target->opal_id,
> + 0, pe_init->pe_number);
> + if (rc != OPAL_SUCCESS) {
> + rc = -EIO;
> + goto out;
> + }
> + }
> +
> + rc = 0;
> +out:
> + mutex_unlock(&p2p_mutex);
> + return rc;
> +}
> +
> +static void pnv_pci_dma_unmap_resource(struct pci_dev *pdev,
> + dma_addr_t addr, size_t size,
> + enum dma_data_direction dir)
> +{
> + struct pnv_phb *target_phb;
> + int rc;
> +
> + target_phb = pnv_pci_find_owning_phb(pdev, addr, size);
> + if (!target_phb)
> + return;
> +
> + rc = pnv_pci_ioda_disable_p2p(pdev, target_phb);
> + if (rc)
> + dev_err(&pdev->dev, "Failed to undo PCI peer-to-peer setup for address %llx: %d\n",
> + addr, rc);
Use pci_err() or pe_err().
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox