* Re: [PATCH v10 2/3] tty: hvc: pass DMA capable memory to put_chars()
From: Greg KH @ 2021-10-10 5:33 UTC (permalink / raw)
To: Xianting Tian
Cc: arnd, amit, jirislaby, shile.zhang, linux-kernel, virtualization,
linuxppc-dev, osandov
In-Reply-To: <3516c58c-e8e6-2e5a-2bc8-ad80e2124d37@linux.alibaba.com>
On Sat, Oct 09, 2021 at 11:45:23PM +0800, Xianting Tian wrote:
>
> 在 2021/10/9 下午7:58, Greg KH 写道:
> > Did you look at the placement using pahole as to how this structure now
> > looks?
>
> thanks for all your commnts. for this one, do you mean I need to remove the
> blank line? thanks
>
No, I mean to use the tool 'pahole' to see the structure layout that you
just created and determine if it really is the best way to add these new
fields, especially as you are adding huge buffers with odd alignment.
thanks,
greg k-h
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.15-3 tag
From: Michael Ellerman @ 2021-10-10 12:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: songliubraving, johan.almbladh, aik, npiggin, linux-kernel,
mahesh, clg, naveen.n.rao, linuxppc-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.15.
A bit of a big batch, partly because I didn't send any last week, and also just because
the BPF fixes happened to land this week.
cheers
The following changes since commit e4e737bb5c170df6135a127739a9e6148ee3da82:
Linux 5.15-rc2 (2021-09-19 17:28:22 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.15-3
for you to fetch changes up to eb8257a12192f43ffd41bd90932c39dade958042:
pseries/eeh: Fix the kdump kernel crash during eeh_pseries_init (2021-10-07 23:37:22 +1100)
- ------------------------------------------------------------------
powerpc fixes for 5.15 #3
Fix a regression hit by the IPR SCSI driver, introduced by the recent addition of MSI
domains on pseries.
A big series including 8 BPF fixes, some with potential security impact and the rest
various code generation issues.
Fix our program check assembler entry path, which was accidentally jumping into a gas
macro and generating strange stack frames, which could confuse find_bug().
A couple of fixes, and related changes, to fix corner cases in our machine check handling.
Fix our DMA IOMMU ops, which were not always returning the optimal DMA mask, leading to
at least one device falling back to 32-bit DMA when it shouldn't.
A fix for KUAP handling on 32-bit Book3S.
Fix crashes seen when kdumping on some pseries systems.
Thanks to: Naveen N. Rao, Nicholas Piggin, Alexey Kardashevskiy, Cédric Le Goater,
Christophe Leroy, Mahesh Salgaonkar, Abdul Haleem, Christoph Hellwig, Johan Almbladh, Stan
Johnson.
- ------------------------------------------------------------------
Alexey Kardashevskiy (1):
powerpc/iommu: Report the correct most efficient DMA mask for PCI devices
Christophe Leroy (1):
powerpc/32s: Fix kuap_kernel_restore()
Cédric Le Goater (1):
powerpc/pseries/msi: Add an empty irq_write_msi_msg() handler
Mahesh Salgaonkar (1):
pseries/eeh: Fix the kdump kernel crash during eeh_pseries_init
Naveen N. Rao (10):
powerpc/lib: Add helper to check if offset is within conditional branch range
powerpc/bpf: Validate branch ranges
powerpc/bpf: Fix BPF_MOD when imm == 1
powerpc/bpf: Fix BPF_SUB when imm == 0x80000000
powerpc/security: Add a helper to query stf_barrier type
powerpc/bpf: Emit stf barrier instruction sequences for BPF_NOSPEC
powerpc/bpf ppc32: Fix ALU32 BPF_ARSH operation
powerpc/bpf ppc32: Fix JMP32_JSET_K
powerpc/bpf ppc32: Do not emit zero extend instruction for 64-bit BPF_END
powerpc/bpf ppc32: Fix BPF_SUB when imm == 0x80000000
Nicholas Piggin (5):
powerpc/64s: fix program check interrupt emergency stack path
powerpc/traps: do not enable irqs in _exception
powerpc/64: warn if local irqs are enabled in NMI or hardirq context
powerpc/64/interrupt: Reconcile soft-mask state in NMI and fix false BUG
powerpc/64s: Fix unrecoverable MCE calling async handler from NMI
arch/powerpc/include/asm/book3s/32/kup.h | 8 ++
arch/powerpc/include/asm/code-patching.h | 1 +
arch/powerpc/include/asm/interrupt.h | 18 ++--
arch/powerpc/include/asm/security_features.h | 5 +
arch/powerpc/kernel/dma-iommu.c | 9 ++
arch/powerpc/kernel/exceptions-64s.S | 25 +++--
arch/powerpc/kernel/irq.c | 6 ++
arch/powerpc/kernel/security.c | 5 +
arch/powerpc/kernel/traps.c | 43 +++++----
arch/powerpc/lib/code-patching.c | 7 +-
arch/powerpc/net/bpf_jit.h | 33 ++++---
arch/powerpc/net/bpf_jit64.h | 8 +-
arch/powerpc/net/bpf_jit_comp.c | 6 +-
arch/powerpc/net/bpf_jit_comp32.c | 16 ++--
arch/powerpc/net/bpf_jit_comp64.c | 100 ++++++++++++++++----
arch/powerpc/platforms/pseries/eeh_pseries.c | 4 +
arch/powerpc/platforms/pseries/msi.c | 15 +++
17 files changed, 234 insertions(+), 75 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmFi26IACgkQUevqPMjh
pYCMSxAAh40nmRryws4rJ6R6UQlp5eKKAitlFo5y/P3h/qNzu5kelwkS93tog5CA
9i/uznMlyu3jpauHiDaeZCU0WYBqs3AL3qE11pHeG4HkGCCQ/D5eX3KxFRYuqbWh
mfGvgRGxr4Rew3ACgQ/eUGwU9DkzmAr49CX9/5MR8chpNzeERpPMcq4jolEjkfJl
Jf74WoIhHkuDMXFWVC8Aj6AKuQM+Ia9bXhSAFUIk2yjKRdADFgnR8stjzebW8B5v
rSJ9WWNFt97UcgpTcvE+0gEuXFdD3cR16Ov6ObdZjsT1Y3ubC9jTZXy/pO8+YZbq
jjGjNfxp7eWr6umgd2bhO5RKDwu/PbKvhM3l8OPQxOkoGK4L8trPm2IGEFjVyV/1
/vhMa439vbPtT7eItmXEuEqgouUCzwA11Du7KhZu+IkdWyJCXsRzkExTI+rYGAYU
nokOmE6A9VI4sgqLXAOxVSWDQSURhBfXx5cGeu9sdWNZ1V/F1TCi9kslE4eSlJie
NjT5X1rEnM4HDMBKuiSkmu2GzcCAP5IktrkzAmWt1CbFWtLqdOExTmQGR/3DNMwp
SniCYTgAw9GdGz46Zkiprr1X8fEqyrGBY6kjrAJ6Yior2Oy5GxU23w7UmE5iddFx
jXsVMOh6dWIvJlhkeFEjLed3NezkpQuKehM0inOcAiPcCpnZhYc=
=hYTj
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v2 00/11] Add Apple M1 support to PASemi i2c driver
From: Sven Peter @ 2021-10-10 13:17 UTC (permalink / raw)
To: Christian Zigotzky, Wolfram Sang, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Olof Johansson,
Arnd Bergmann, Hector Martin, Mohamed Mediouni, Stan Skowronek,
Mark Kettenis, Alyssa Rosenzweig, linux-arm-kernel, linuxppc-dev,
linux-i2c, linux-kernel, R.T.Dickinson, Matthew Leaman,
Darren Stevens
In-Reply-To: <8a8afc73-3756-a305-ce5f-70b4bce6999f@xenosoft.de>
On Sat, Oct 9, 2021, at 15:57, Christian Zigotzky wrote:
> On 09 October 2021 at 12:10 pm, Wolfram Sang wrote:
>>> I still don't have access to any old PASemi hardware but the changes from
>>> v1 are pretty small and I expect them to still work. Would still be nice
>>> if someone with access to such hardware could give this a quick test.
>> Looks good to me. I will wait a few more days so that people can report
>> their tests. But it will be in the next merge window.
>>
> Series v2:
>
> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> [1]
thanks a lot, glad to hear everything works on P.A Semi CPUs as well!
And regarding that git am issue you wrote about: I think I based this series on
torvald's tree instead of 5.15-rc4 and there have been some changes to at least
MAINTAINERS. It'll probably apply cleanly to 5.15-rc5 but if that happens again
in the future you can try
git am -3 mbox
instead. It'll try to do a three way merge if the patch doesn't apply cleanly.
Sven
^ permalink raw reply
* [PATCH] scsi: ibmvscsi: Use dma_alloc_coherent() instead of get_zeroed_page/dma_map_single()
From: Cai Huoqing @ 2021-10-10 16:01 UTC (permalink / raw)
To: caihuoqing
Cc: Tyrel Datwyler, linux-scsi, Martin K. Petersen,
James E.J. Bottomley, linux-kernel, Paul Mackerras, linuxppc-dev
Replacing get_zeroed_page/free_page/dma_map_single/dma_unmap_single()
with dma_alloc_coherent/dma_free_coherent() helps to reduce
code size, and simplify the code, and coherent DMA will not
clear the cache every time.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
drivers/scsi/ibmvscsi/ibmvfc.c | 15 +++------------
drivers/scsi/ibmvscsi/ibmvscsi.c | 26 ++++++--------------------
2 files changed, 9 insertions(+), 32 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 1f1586ad48fe..f65d1a78b272 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -869,8 +869,7 @@ static void ibmvfc_free_queue(struct ibmvfc_host *vhost,
{
struct device *dev = vhost->dev;
- dma_unmap_single(dev, queue->msg_token, PAGE_SIZE, DMA_BIDIRECTIONAL);
- free_page((unsigned long)queue->msgs.handle);
+ dma_free_coherent(dev, PAGE_SIZE, queue->msgs.handle, queue->msg_token);
queue->msgs.handle = NULL;
ibmvfc_free_event_pool(vhost, queue);
@@ -5663,19 +5662,11 @@ static int ibmvfc_alloc_queue(struct ibmvfc_host *vhost,
return -ENOMEM;
}
- queue->msgs.handle = (void *)get_zeroed_page(GFP_KERNEL);
+ queue->msgs.handle = dma_alloc_coherent(dev, PAGE_SIZE,
+ &queue->msg_token, GFP_KERNEL);
if (!queue->msgs.handle)
return -ENOMEM;
- queue->msg_token = dma_map_single(dev, queue->msgs.handle, PAGE_SIZE,
- DMA_BIDIRECTIONAL);
-
- if (dma_mapping_error(dev, queue->msg_token)) {
- free_page((unsigned long)queue->msgs.handle);
- queue->msgs.handle = NULL;
- return -ENOMEM;
- }
-
queue->cur = 0;
queue->fmt = fmt;
queue->size = PAGE_SIZE / fmt_size;
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index ea8e01f49cba..61b315d1edbc 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -151,10 +151,7 @@ static void ibmvscsi_release_crq_queue(struct crq_queue *queue,
msleep(100);
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
} while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
- dma_unmap_single(hostdata->dev,
- queue->msg_token,
- queue->size * sizeof(*queue->msgs), DMA_BIDIRECTIONAL);
- free_page((unsigned long)queue->msgs);
+ dma_free_coherent(hostdata->dev, PAGE_SIZE, queue->msgs, queue->msg_token);
}
/**
@@ -331,18 +328,11 @@ static int ibmvscsi_init_crq_queue(struct crq_queue *queue,
int retrc;
struct vio_dev *vdev = to_vio_dev(hostdata->dev);
- queue->msgs = (struct viosrp_crq *)get_zeroed_page(GFP_KERNEL);
-
- if (!queue->msgs)
- goto malloc_failed;
queue->size = PAGE_SIZE / sizeof(*queue->msgs);
-
- queue->msg_token = dma_map_single(hostdata->dev, queue->msgs,
- queue->size * sizeof(*queue->msgs),
- DMA_BIDIRECTIONAL);
-
- if (dma_mapping_error(hostdata->dev, queue->msg_token))
- goto map_failed;
+ queue->msgs = dma_alloc_coherent(hostdata->dev, PAGE_SIZE,
+ &queue->msg_token, GFP_KERNEL);
+ if (!queue->msg)
+ goto malloc_failed;
gather_partition_info();
set_adapter_info(hostdata);
@@ -395,11 +385,7 @@ static int ibmvscsi_init_crq_queue(struct crq_queue *queue,
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
} while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
reg_crq_failed:
- dma_unmap_single(hostdata->dev,
- queue->msg_token,
- queue->size * sizeof(*queue->msgs), DMA_BIDIRECTIONAL);
- map_failed:
- free_page((unsigned long)queue->msgs);
+ dma_free_coherent(hostdata->dev, PAGE_SIZE, queue->msg, queue->msg_token);
malloc_failed:
return -1;
}
--
2.25.1
^ permalink raw reply related
* [PATCH] tpm: ibmvtpm: Make use of dma_alloc_coherent()
From: Cai Huoqing @ 2021-10-10 16:01 UTC (permalink / raw)
To: caihuoqing
Cc: linux-kernel, Jason Gunthorpe, Jarkko Sakkinen, Paul Mackerras,
Peter Huewe, linuxppc-dev, linux-integrity
Replacing kmalloc/kfree/get_zeroed_page/free_page/dma_map_single/
dma_unmap_single() with dma_alloc_coherent/dma_free_coherent()
helps to reduce code size, and simplify the code, and coherent
DMA will not clear the cache every time.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
drivers/char/tpm/tpm_ibmvtpm.c | 61 ++++++++++------------------------
1 file changed, 18 insertions(+), 43 deletions(-)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 3af4c07a9342..5f55a14ee824 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -356,15 +356,12 @@ static void tpm_ibmvtpm_remove(struct vio_dev *vdev)
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
} while (rc == H_BUSY || H_IS_LONG_BUSY(rc));
- dma_unmap_single(ibmvtpm->dev, ibmvtpm->crq_dma_handle,
- CRQ_RES_BUF_SIZE, DMA_BIDIRECTIONAL);
- free_page((unsigned long)ibmvtpm->crq_queue.crq_addr);
-
- if (ibmvtpm->rtce_buf) {
- dma_unmap_single(ibmvtpm->dev, ibmvtpm->rtce_dma_handle,
- ibmvtpm->rtce_size, DMA_BIDIRECTIONAL);
- kfree(ibmvtpm->rtce_buf);
- }
+ dma_free_coherent(ibmvtpm->dev, CRQ_RES_BUF_SIZE,
+ crq_q->crq_addr, crq_q->crq_dma_handle);
+
+ if (ibmvtpm->rtce_buf)
+ dma_free_coherent(ibmvtpm->dev, ibmvtpm->rtce_size,
+ ibmvtpm->rtce_buf, ibmvtpm->rtce_dma_handle);
kfree(ibmvtpm);
/* For tpm_ibmvtpm_get_desired_dma */
@@ -522,23 +519,12 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
return;
}
ibmvtpm->rtce_size = be16_to_cpu(crq->len);
- ibmvtpm->rtce_buf = kmalloc(ibmvtpm->rtce_size,
- GFP_ATOMIC);
- if (!ibmvtpm->rtce_buf) {
- dev_err(ibmvtpm->dev, "Failed to allocate memory for rtce buffer\n");
- return;
- }
-
- ibmvtpm->rtce_dma_handle = dma_map_single(ibmvtpm->dev,
- ibmvtpm->rtce_buf, ibmvtpm->rtce_size,
- DMA_BIDIRECTIONAL);
-
- if (dma_mapping_error(ibmvtpm->dev,
- ibmvtpm->rtce_dma_handle)) {
- kfree(ibmvtpm->rtce_buf);
- ibmvtpm->rtce_buf = NULL;
- dev_err(ibmvtpm->dev, "Failed to dma map rtce buffer\n");
- }
+ ibmvtpm->rtce_buf = dma_alloc_coherent(ibmvtpm->dev,
+ ibmvtpm->rtce_size,
+ &ibmvtpm->rtce_dma_handle,
+ GFP_ATOMIC);
+ if (!ibmvtpm->rtce_buf)
+ dev_err(ibmvtpm->dev, "Failed to dma allocate rtce buffer\n");
return;
case VTPM_GET_VERSION_RES:
@@ -618,22 +604,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
ibmvtpm->vdev = vio_dev;
crq_q = &ibmvtpm->crq_queue;
- crq_q->crq_addr = (struct ibmvtpm_crq *)get_zeroed_page(GFP_KERNEL);
- if (!crq_q->crq_addr) {
- dev_err(dev, "Unable to allocate memory for crq_addr\n");
- goto cleanup;
- }
crq_q->num_entry = CRQ_RES_BUF_SIZE / sizeof(*crq_q->crq_addr);
init_waitqueue_head(&crq_q->wq);
- ibmvtpm->crq_dma_handle = dma_map_single(dev, crq_q->crq_addr,
- CRQ_RES_BUF_SIZE,
- DMA_BIDIRECTIONAL);
-
- if (dma_mapping_error(dev, ibmvtpm->crq_dma_handle)) {
- dev_err(dev, "dma mapping failed\n");
+ crq_q->crq_addr = dma_alloc_coherent(dev, CRQ_RES_BUF_SIZE,
+ &ibmvtpm->crq_dma_handle, GFP_KERNEL);
+ if (!crq_q->crq_addr)
goto cleanup;
- }
rc = plpar_hcall_norets(H_REG_CRQ, vio_dev->unit_address,
ibmvtpm->crq_dma_handle, CRQ_RES_BUF_SIZE);
@@ -642,7 +619,7 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
if (rc) {
dev_err(dev, "Unable to register CRQ rc=%d\n", rc);
- goto reg_crq_cleanup;
+ goto cleanup;
}
rc = request_irq(vio_dev->irq, ibmvtpm_interrupt, 0,
@@ -704,13 +681,11 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
do {
rc1 = plpar_hcall_norets(H_FREE_CRQ, vio_dev->unit_address);
} while (rc1 == H_BUSY || H_IS_LONG_BUSY(rc1));
-reg_crq_cleanup:
- dma_unmap_single(dev, ibmvtpm->crq_dma_handle, CRQ_RES_BUF_SIZE,
- DMA_BIDIRECTIONAL);
cleanup:
if (ibmvtpm) {
if (crq_q->crq_addr)
- free_page((unsigned long)crq_q->crq_addr);
+ dma_free_coherent(dev, CRQ_RES_BUF_SIZE,
+ crq_q->crq_addr, crq_q->crq_dma_handle);
kfree(ibmvtpm);
}
--
2.25.1
^ permalink raw reply related
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.15-3 tag
From: pr-tracker-bot @ 2021-10-10 17:17 UTC (permalink / raw)
To: Michael Ellerman
Cc: songliubraving, johan.almbladh, aik, linuxppc-dev, npiggin,
linux-kernel, mahesh, clg, naveen.n.rao, Linus Torvalds
In-Reply-To: <87y271m5ft.fsf@mpe.ellerman.id.au>
The pull request you sent on Sun, 10 Oct 2021 23:26:30 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.15-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/efb52a7d9511df818391f1afa459507425833438
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: linux-next: build warnings in Linus' tree
From: Stephen Rothwell @ 2021-10-10 21:27 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Rob Herring
In-Reply-To: <20211008164728.30e3d3a3@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]
Hi all,
[Cc'ing Rob]
Rob: these warnings have been there for a long time ...
On Fri, 8 Oct 2021 16:47:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the origin tree, today's linux-next build (powerpc
> allyesconfig) produced these warnings (along with many others):
>
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
>
> Given that arch/powerpc/boot/dts/mpc5200b.dtsi is oncluded by several
> other dts files, fixing this one file would go quite a long way to
> silencing our allyesoncig build. Unfotunatley, I have no idea how to
> fix this file (ad maybe some fo the interactions it has with other files).
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS ece9c55cc2f2c408240cd5627ea46926e9d4e5eb
From: kernel test robot @ 2021-10-11 1:19 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: ece9c55cc2f2c408240cd5627ea46926e9d4e5eb Automatic merge of 'master' into merge (2021-10-10 22:52)
elapsed time: 723m
configs tested: 208
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211010
mips randconfig-c004-20211010
powerpc ge_imp3a_defconfig
m68k m5249evb_defconfig
arm viper_defconfig
openrisc simple_smp_defconfig
arm omap2plus_defconfig
m68k m5475evb_defconfig
sh allmodconfig
powerpc lite5200b_defconfig
arm imote2_defconfig
powerpc motionpro_defconfig
mips tb0219_defconfig
ia64 tiger_defconfig
arm milbeaut_m10v_defconfig
mips rb532_defconfig
s390 zfcpdump_defconfig
mips loongson2k_defconfig
mips maltaup_defconfig
sh apsh4ad0a_defconfig
powerpc ppc40x_defconfig
arm xcep_defconfig
arm badge4_defconfig
mips maltasmvp_defconfig
mips cobalt_defconfig
sh se7780_defconfig
arm cm_x300_defconfig
sh rts7751r2d1_defconfig
powerpc ep8248e_defconfig
powerpc ksi8560_defconfig
mips ip28_defconfig
arm bcm2835_defconfig
powerpc rainier_defconfig
arm exynos_defconfig
arm simpad_defconfig
arm imx_v4_v5_defconfig
powerpc redwood_defconfig
sparc64 defconfig
powerpc wii_defconfig
ia64 bigsur_defconfig
mips bcm63xx_defconfig
arm pleb_defconfig
arm mvebu_v7_defconfig
m68k multi_defconfig
mips sb1250_swarm_defconfig
powerpc64 defconfig
powerpc mvme5100_defconfig
powerpc warp_defconfig
xtensa defconfig
openrisc or1ksim_defconfig
sh sh7785lcr_32bit_defconfig
powerpc mpc836x_mds_defconfig
nios2 alldefconfig
powerpc adder875_defconfig
sh se7343_defconfig
h8300 defconfig
sh lboxre2_defconfig
powerpc sam440ep_defconfig
powerpc amigaone_defconfig
sh apsh4a3a_defconfig
sh j2_defconfig
powerpc eiger_defconfig
arm axm55xx_defconfig
arm sama7_defconfig
arm iop32x_defconfig
powerpc ps3_defconfig
riscv nommu_k210_defconfig
nds32 defconfig
h8300 alldefconfig
powerpc iss476-smp_defconfig
mips rt305x_defconfig
arm lpc18xx_defconfig
powerpc g5_defconfig
m68k amcore_defconfig
m68k bvme6000_defconfig
ia64 gensparse_defconfig
arm pxa_defconfig
sh se7206_defconfig
sh se7724_defconfig
arm oxnas_v6_defconfig
arm realview_defconfig
powerpc sequoia_defconfig
sparc sparc32_defconfig
arm orion5x_defconfig
arm colibri_pxa300_defconfig
powerpc acadia_defconfig
xtensa iss_defconfig
arm pxa910_defconfig
h8300 h8s-sim_defconfig
sh se7750_defconfig
powerpc mpc832x_rdb_defconfig
mips decstation_64_defconfig
sh shx3_defconfig
powerpc mgcoge_defconfig
mips malta_defconfig
riscv nommu_k210_sdcard_defconfig
powerpc cell_defconfig
arc axs103_defconfig
m68k mvme16x_defconfig
arm cns3420vb_defconfig
arm hisi_defconfig
arc tb10x_defconfig
arm vf610m4_defconfig
sh espt_defconfig
s390 alldefconfig
arm integrator_defconfig
sh ap325rxa_defconfig
arm pcm027_defconfig
arm colibri_pxa270_defconfig
um defconfig
arm randconfig-c002-20211010
x86_64 randconfig-c001-20211010
arm randconfig-c002-20211011
i386 randconfig-c001-20211011
x86_64 randconfig-c001-20211011
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k defconfig
m68k allmodconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
csky defconfig
alpha defconfig
alpha allyesconfig
nios2 allyesconfig
h8300 allyesconfig
arc defconfig
xtensa allyesconfig
parisc defconfig
parisc allyesconfig
s390 defconfig
s390 allyesconfig
s390 allmodconfig
i386 allyesconfig
sparc allyesconfig
i386 defconfig
sparc defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20211010
x86_64 randconfig-a006-20211010
x86_64 randconfig-a001-20211010
x86_64 randconfig-a005-20211010
x86_64 randconfig-a002-20211010
x86_64 randconfig-a003-20211010
i386 randconfig-a001-20211010
i386 randconfig-a003-20211010
i386 randconfig-a004-20211010
i386 randconfig-a005-20211010
i386 randconfig-a002-20211010
i386 randconfig-a006-20211010
x86_64 randconfig-a015-20211011
x86_64 randconfig-a012-20211011
x86_64 randconfig-a016-20211011
x86_64 randconfig-a014-20211011
x86_64 randconfig-a013-20211011
x86_64 randconfig-a011-20211011
arc randconfig-r043-20211010
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allyesconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
x86_64 allyesconfig
clang tested configs:
arm randconfig-c002-20211010
mips randconfig-c004-20211010
i386 randconfig-c001-20211010
s390 randconfig-c005-20211010
x86_64 randconfig-c007-20211010
powerpc randconfig-c003-20211010
riscv randconfig-c006-20211010
x86_64 randconfig-a015-20211010
x86_64 randconfig-a012-20211010
x86_64 randconfig-a016-20211010
x86_64 randconfig-a014-20211010
x86_64 randconfig-a013-20211010
x86_64 randconfig-a011-20211010
i386 randconfig-a016-20211010
i386 randconfig-a014-20211010
i386 randconfig-a011-20211010
i386 randconfig-a015-20211010
i386 randconfig-a012-20211010
i386 randconfig-a013-20211010
x86_64 randconfig-a004-20211011
x86_64 randconfig-a006-20211011
x86_64 randconfig-a001-20211011
x86_64 randconfig-a005-20211011
x86_64 randconfig-a002-20211011
x86_64 randconfig-a003-20211011
hexagon randconfig-r041-20211010
s390 randconfig-r044-20211010
riscv randconfig-r042-20211010
hexagon randconfig-r045-20211010
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v6 19/22] powerpc/book3s64/hash/kuap: Enable kuap on hash
From: Michael Ellerman @ 2021-10-11 3:28 UTC (permalink / raw)
To: Christophe Leroy, Aneesh Kumar K.V, linuxppc-dev; +Cc: Sandipan Das
In-Reply-To: <b2ab09a4-7f30-deee-e983-9459d93cb9b3@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
>> Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>> arch/powerpc/mm/book3s64/pkeys.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/book3s64/pkeys.c b/arch/powerpc/mm/book3s64/pkeys.c
>> index f747d66cc87d..84f8664ffc47 100644
>> --- a/arch/powerpc/mm/book3s64/pkeys.c
>> +++ b/arch/powerpc/mm/book3s64/pkeys.c
>> @@ -257,7 +257,12 @@ void __init setup_kuep(bool disabled)
>> #ifdef CONFIG_PPC_KUAP
>> void __init setup_kuap(bool disabled)
>> {
>> - if (disabled || !early_radix_enabled())
>> + if (disabled)
>> + return;
>> + /*
>> + * On hash if PKEY feature is not enabled, disable KUAP too.
>> + */
>> + if (!early_radix_enabled() && !early_mmu_has_feature(MMU_FTR_PKEY))
>
> pkey_early_init_devtree() bails out without setting MMU_FTR_PKEY with
> the following:
>
> /*
> * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
> */
> if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
> return;
>
>
>
> Why would it be impossible to do KUAP in that case ? KUAP doesn't
> require updating SPRN_AMR with MSR[PR] = 1
You're right, it would be possible to do KUAP in that case.
That's an artifact of KUAP being implemented using PKEYs on hash. For
the PKEYs user-visible API we want AMR to be user controlled.
It's possible we could untangle all that, allowing KUAP to be
implemented on earlier CPUs, but I'm not sure it's going to be high on
anyone's todo list.
cheers
^ permalink raw reply
* [PATCH] powerpc/xive: Discard disabled interrupts in get_irqchip_state()
From: Cédric Le Goater @ 2021-10-11 7:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Cédric Le Goater, stable
When an interrupt is passed through, the KVM XIVE device calls the
set_vcpu_affinity() handler which raises the P bit to mask the
interrupt and to catch any in-flight interrupts while routing the
interrupt to the guest.
On the guest side, drivers (like some Intels) can request at probe
time some MSIs and call synchronize_irq() to check that there are no
in flight interrupts. This will call the XIVE get_irqchip_state()
handler which will always return true as the interrupt P bit has been
set on the host side and lock the CPU in an infinite loop.
Fix that by discarding disabled interrupts in get_irqchip_state().
Fixes: da15c03b047d ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race")
Cc: stable@vger.kernel.org#v5.4+
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/powerpc/sysdev/xive/common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
index c732ce5a3e1a..c5d75c02ad8b 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -945,7 +945,8 @@ static int xive_get_irqchip_state(struct irq_data *data,
* interrupt to be inactive in that case.
*/
*state = (pq != XIVE_ESB_INVALID) && !xd->stale_p &&
- (xd->saved_p || !!(pq & XIVE_ESB_VAL_P));
+ (xd->saved_p || (!!(pq & XIVE_ESB_VAL_P) &&
+ !irqd_irq_disabled(data)));
return 0;
default:
return -EINVAL;
--
2.31.1
^ permalink raw reply related
* [PATCH] powerpc/boot: Use CONFIG_PPC_POWERNV to compile OPAL support
From: Cédric Le Goater @ 2021-10-11 7:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Cédric Le Goater
CONFIG_PPC64_BOOT_WRAPPER is selected by CPU_LITTLE_ENDIAN which is
used to compile support for other platforms such as Microwatt. There
is no need for OPAL calls on these.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/powerpc/boot/serial.c | 2 +-
arch/powerpc/boot/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index 9a19e5905485..54d2522be485 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -132,7 +132,7 @@ int serial_console_init(void)
else if (dt_is_compatible(devp, "fsl,mpc5200-psc-uart"))
rc = mpc5200_psc_console_init(devp, &serial_cd);
#endif
-#ifdef CONFIG_PPC64_BOOT_WRAPPER
+#ifdef CONFIG_PPC_POWERNV
else if (dt_is_compatible(devp, "ibm,opal-console-raw"))
rc = opal_console_init(devp, &serial_cd);
#endif
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 089ee3ea55c8..9993c6256ad2 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -123,7 +123,7 @@ src-wlib-y := string.S crt0.S stdio.c decompress.c main.c \
oflib.c ofconsole.c cuboot.c
src-wlib-$(CONFIG_PPC_MPC52xx) += mpc52xx-psc.c
-src-wlib-$(CONFIG_PPC64_BOOT_WRAPPER) += opal-calls.S opal.c
+src-wlib-$(CONFIG_PPC_POWERNV) += opal-calls.S opal.c
ifndef CONFIG_PPC64_BOOT_WRAPPER
src-wlib-y += crtsavres.S
endif
--
2.31.1
^ permalink raw reply related
* Re: [PATCH 1/2] firmware: include drivers/firmware/Kconfig unconditionally
From: Geert Uytterhoeven @ 2021-10-11 8:42 UTC (permalink / raw)
To: Paul Menzel
Cc: linux-ia64@vger.kernel.org, Geert Uytterhoeven, Catalin Marinas,
Linus Walleij, Bjorn Andersson, James E.J. Bottomley,
H. Peter Anvin, linux-riscv, Will Deacon, Helge Deller,
the arch/x86 maintainers, Russell King, Ingo Molnar,
open list:BROADCOM NVRAM DRIVER, Albert Ou, Charles Keepax,
Arnd Bergmann, Simon Trimmer, Mark Brown, Borislav Petkov,
Paul Walmsley, Thomas Gleixner, Linux ARM, Arnd Bergmann,
Thomas Bogendoerfer, Parisc List, Greg Kroah-Hartman,
Liam Girdwood, Linux Kernel Mailing List, Palmer Dabbelt,
Andrew Morton, linuxppc-dev
In-Reply-To: <9dedf9bb-5377-9f2c-cbb1-2a57b40493da@molgen.mpg.de>
On Sat, Oct 9, 2021 at 11:24 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
> [Cc: +linuxppc-dev@lists.ozlabs.org]
>
> Am 28.09.21 um 09:50 schrieb Arnd Bergmann:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > Compile-testing drivers that require access to a firmware layer
> > fails when that firmware symbol is unavailable. This happened
> > twice this week:
> >
> > - My proposed to change to rework the QCOM_SCM firmware symbol
> > broke on ppc64 and others.
> >
> > - The cs_dsp firmware patch added device specific firmware loader
> > into drivers/firmware, which broke on the same set of
> > architectures.
> >
> > We should probably do the same thing for other subsystems as well,
> > but fix this one first as this is a dependency for other patches
> > getting merged.
> >
> With this change, I have the new entries below in my .config:
>
> ```
> $ diff -u .config.old .config
> --- .config.old 2021-10-07 11:38:39.544000000 +0200
> +++ .config 2021-10-09 10:02:03.156000000 +0200
> @@ -1992,6 +1992,25 @@
>
> CONFIG_CONNECTOR=y
> CONFIG_PROC_EVENTS=y
> +
> +#
> +# Firmware Drivers
> +#
> +
> +#
> +# ARM System Control and Management Interface Protocol
> +#
> +# end of ARM System Control and Management Interface Protocol
> +
> +# CONFIG_FIRMWARE_MEMMAP is not set
> +# CONFIG_GOOGLE_FIRMWARE is not set
> +
> +#
> +# Tegra firmware driver
> +#
> +# end of Tegra firmware driver
> +# end of Firmware Drivers
> +
> # CONFIG_GNSS is not set
> CONFIG_MTD=m
> # CONFIG_MTD_TESTS is not set
> ```
>
> No idea if the entries could be hidden for platforms not supporting them.
>
> ARM System Control and Management Interface Protocol ----
> [ ] Add firmware-provided memory map to sysfs
> [ ] Google Firmware Drivers ----
> Tegra firmware driver ----
GOOGLE_FIRMWARE should probably depend on something.
I highly doubt Google is running servers on e.g. h8300 and nds32.
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 v2 00/11] Add Apple M1 support to PASemi i2c driver
From: Wolfram Sang @ 2021-10-11 8:54 UTC (permalink / raw)
To: Sven Peter
Cc: Hector Martin, Arnd Bergmann, Christian Zigotzky, linux-kernel,
linux-i2c, Darren Stevens, Paul Mackerras, linux-arm-kernel,
Olof Johansson, Mohamed Mediouni, R.T.Dickinson, Mark Kettenis,
linuxppc-dev, Matthew Leaman, Alyssa Rosenzweig, Stan Skowronek
In-Reply-To: <11d8f784-c90a-4e6c-9abd-564cb5241cb7@www.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
> MAINTAINERS. It'll probably apply cleanly to 5.15-rc5 but if that happens again
It doesn't because Linus' git doesn't have:
Documentation/devicetree/bindings/pci/apple,pcie.yaml
Because MAINTAINER dependencies can be a bit nasty, I suggest I drop the
MAINTAINER additions for now and we add them later. Then, you can add
the pasemi-core as well. D'accord?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/11] Add Apple M1 support to PASemi i2c driver
From: Wolfram Sang @ 2021-10-11 9:37 UTC (permalink / raw)
To: Hector Martin
Cc: Darren Stevens, Arnd Bergmann, Sven Peter, linux-kernel,
linux-i2c, Paul Mackerras, linux-arm-kernel, Christian Zigotzky,
Olof Johansson, Mohamed Mediouni, R.T.Dickinson, Mark Kettenis,
linuxppc-dev, Matthew Leaman, Alyssa Rosenzweig, Stan Skowronek
In-Reply-To: <5ae30425-d6d4-5688-36e3-58cc6c6ff264@marcan.st>
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
> > Because MAINTAINER dependencies can be a bit nasty, I suggest I drop the
> > MAINTAINER additions for now and we add them later. Then, you can add
> > the pasemi-core as well. D'accord?
> >
>
> We can just split the MAINTAINERS changes into a separate patch and I can
> push that one through the SoC tree, along with other MAINTAINERS updates.
> Does that work for everyone?
That would also work for me. Thank you!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] firmware: include drivers/firmware/Kconfig unconditionally
From: Arnd Bergmann @ 2021-10-11 9:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-ia64@vger.kernel.org, Geert Uytterhoeven, Catalin Marinas,
Linus Walleij, Bjorn Andersson, James E.J. Bottomley,
H. Peter Anvin, linux-riscv, Will Deacon, Helge Deller,
the arch/x86 maintainers, Russell King, Ingo Molnar,
open list:BROADCOM NVRAM DRIVER, Paul Menzel, Albert Ou,
Charles Keepax, Arnd Bergmann, Simon Trimmer, Mark Brown,
Borislav Petkov, Paul Walmsley, Thomas Gleixner, Linux ARM,
Thomas Bogendoerfer, Parisc List, Greg Kroah-Hartman,
Liam Girdwood, Linux Kernel Mailing List, Palmer Dabbelt,
Andrew Morton, linuxppc-dev
In-Reply-To: <CAMuHMdXspk27xd95YAsXa73ES8rfKxii3RUEtsBtxQTk9qLztA@mail.gmail.com>
On Mon, Oct 11, 2021 at 10:42 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Sat, Oct 9, 2021 at 11:24 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
> > Am 28.09.21 um 09:50 schrieb Arnd Bergmann:
> > > From: Arnd Bergmann <arnd@arndb.de>
> > +#
> > +# ARM System Control and Management Interface Protocol
> > +#
> > +# end of ARM System Control and Management Interface Protocol
> > +
> > +# CONFIG_FIRMWARE_MEMMAP is not set
> > +# CONFIG_GOOGLE_FIRMWARE is not set
> > +
> > +#
> > +# Tegra firmware driver
> > +#
> > +# end of Tegra firmware driver
> > +# end of Firmware Drivers
> > +
> > # CONFIG_GNSS is not set
> > CONFIG_MTD=m
> > # CONFIG_MTD_TESTS is not set
> > ```
> >
> > No idea if the entries could be hidden for platforms not supporting them.
> >
> > ARM System Control and Management Interface Protocol ----
> > [ ] Add firmware-provided memory map to sysfs
> > [ ] Google Firmware Drivers ----
> > Tegra firmware driver ----
>
> GOOGLE_FIRMWARE should probably depend on something.
> I highly doubt Google is running servers on e.g. h8300 and nds32.
GOOGLE_FIRMWARE is only the 'menuconfig' option that contains
the other options, but on architectures that have neither CONFIG_OF
nor CONFIG_ACPI, this is empty. Most architectures of course
do support or require CONFIG_OF, so it's unclear whether we should
show the options for coreboot. Since it's a software-only driver, I
would tend to keep showing it, given that coreboot can be ported
to every architecture. The DT binding [1] seems to be neither
Google nor Arm specific.
CONFIG_FIRMWARE_MEMMAP in turn can be used for
anything that has memory hotplug, and in theory additional
drivers that register with this interface.
I'd lean towards "leave as is" for both, to avoid having to
change the dependencies again whenever something else
can use these.
Arnd
[1] Documentation/devicetree/bindings/firmware/coreboot.txt
^ permalink raw reply
* Re: [PATCH v2 00/11] Add Apple M1 support to PASemi i2c driver
From: Wolfram Sang @ 2021-10-11 10:04 UTC (permalink / raw)
To: Sven Peter
Cc: Arnd Bergmann, Hector Martin, linux-kernel, linux-i2c,
Paul Mackerras, linux-arm-kernel, Christian Zigotzky,
Olof Johansson, Mohamed Mediouni, Mark Kettenis, linuxppc-dev,
Alyssa Rosenzweig, Stan Skowronek
In-Reply-To: <20211008163532.75569-1-sven@svenpeter.dev>
[-- Attachment #1: Type: text/plain, Size: 3100 bytes --]
On Fri, Oct 08, 2021 at 06:35:21PM +0200, Sven Peter wrote:
> Hi,
>
> v1: https://lore.kernel.org/linux-i2c/20210926095847.38261-1-sven@svenpeter.dev/
>
> Changes for v2:
> - Added reviewed-by/acks
> - Switched from ioport_map to pci_iomap as suggested by Arnd Bergmann
> - Renamed i2c-pasemi-apple.c to i2c-pasemi-platform.c as suggested by
> Wolfram Sang
> - Replaced the ioport number in the adapter name with dev_name to be
> able to identify separate busses in e.g. i2cdetect.
>
> I still don't have access to any old PASemi hardware but the changes from
> v1 are pretty small and I expect them to still work. Would still be nice
> if someone with access to such hardware could give this a quick test.
>
>
> And for those who didn't see v1 the (almost) unchanged original cover letter:
>
> This series adds support for the I2C controller found on Apple Silicon Macs
> which has quite a bit of history:
>
> Apple bought P.A. Semi in 2008 and it looks like a part of its legacy continues
> to live on in the M1. This controller has actually been used since at least the
> iPhone 4S and hasn't changed much since then.
> Essentially, there are only a few differences that matter:
>
> - The controller no longer is a PCI device
> - Starting at some iPhone an additional bit in one register
> must be set in order to start transmissions.
> - The reference clock and hence the clock dividers are different
>
> In order to add support for a platform device I first replaced PCI-specific
> bits and split out the PCI driver to its own file. Then I added support
> to make the clock divider configurable and converted the driver to use
> managed device resources to make it a bit simpler.
>
> The Apple and PASemi driver will never be compiled in the same kernel
> since the Apple one will run on arm64 while the original PASemi driver
> will only be useful on powerpc.
> I've thus followed the octeon (mips)/thunderx(arm64) approach to do the
> split: I created a -core.c file which contains the shared logic and just
> compile that one for both the PASemi and the new Apple driver.
>
>
> Best,
>
> Sven
>
> Sven Peter (11):
> dt-bindings: i2c: Add Apple I2C controller bindings
> i2c: pasemi: Use io{read,write}32
> i2c: pasemi: Use dev_name instead of port number
> i2c: pasemi: Remove usage of pci_dev
> i2c: pasemi: Split off common probing code
> i2c: pasemi: Split pci driver to its own file
> i2c: pasemi: Move common reset code to own function
> i2c: pasemi: Allow to configure bus frequency
> i2c: pasemi: Refactor _probe to use devm_*
> i2c: pasemi: Add Apple platform driver
> i2c: pasemi: Set enable bit for Apple variant
>
> .../devicetree/bindings/i2c/apple,i2c.yaml | 61 +++++++++
> MAINTAINERS | 2 +
> drivers/i2c/busses/Kconfig | 11 ++
> drivers/i2c/busses/Makefile | 3 +
Applied to for-next with MAINTAINER bits dropped and added tags from
Olof and Christian, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/11] Add Apple M1 support to PASemi i2c driver
From: Hector Martin @ 2021-10-11 9:23 UTC (permalink / raw)
To: Wolfram Sang, Sven Peter, Christian Zigotzky, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Olof Johansson,
Arnd Bergmann, Mohamed Mediouni, Stan Skowronek, Mark Kettenis,
Alyssa Rosenzweig, linux-arm-kernel, linuxppc-dev, linux-i2c,
linux-kernel, R.T.Dickinson, Matthew Leaman, Darren Stevens
In-Reply-To: <YWP71c8cXlE3PcIo@kunai>
On 11/10/2021 17.54, Wolfram Sang wrote:
>> MAINTAINERS. It'll probably apply cleanly to 5.15-rc5 but if that happens again
>
> It doesn't because Linus' git doesn't have:
>
> Documentation/devicetree/bindings/pci/apple,pcie.yaml
>
> Because MAINTAINER dependencies can be a bit nasty, I suggest I drop the
> MAINTAINER additions for now and we add them later. Then, you can add
> the pasemi-core as well. D'accord?
>
We can just split the MAINTAINERS changes into a separate patch and I
can push that one through the SoC tree, along with other MAINTAINERS
updates. Does that work for everyone?
--
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub
^ permalink raw reply
* Re: [PATCH] powerpc/xive: Discard disabled interrupts in get_irqchip_state()
From: seeteena @ 2021-10-11 9:47 UTC (permalink / raw)
To: clg; +Cc: linuxppc-dev, stable
In-Reply-To: <20211011070203.99726-1-clg@kaod.org>
[-- Attachment #1.1: Type: text/plain, Size: 158 bytes --]
Tested-by: seeteena<s1seetee@linux.vnet.ibm.com>
I have used a KVM guest with a passthrough ethernet adapter and the
lspci output to identify the adapter.
[-- Attachment #1.2: Type: text/html, Size: 2245 bytes --]
[-- Attachment #2: PATCH-powerpc-xive-Discard-disabled-interrupts-in-get_irqchip_state.txt --]
[-- Type: text/plain, Size: 6088 bytes --]
From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <SRS0=o3RY=O7=lists.ozlabs.org=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
by smtp.lore.kernel.org (Postfix) with ESMTP id 96058C433EF
for <linuxppc-dev@archiver.kernel.org>; Mon, 11 Oct 2021 07:11:10 +0000 (UTC)
Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail.kernel.org (Postfix) with ESMTPS id B21F760F24
for <linuxppc-dev@archiver.kernel.org>; Mon, 11 Oct 2021 07:11:09 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B21F760F24
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kaod.org
Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org
Received: from boromir.ozlabs.org (localhost [IPv6:::1])
by lists.ozlabs.org (Postfix) with ESMTP id 4HSVMH6wGdz3bjR
for <linuxppc-dev@archiver.kernel.org>; Mon, 11 Oct 2021 18:11:07 +1100 (AEDT)
Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized)
smtp.mailfrom=kaod.org (client-ip=79.137.123.220;
helo=smtpout2.mo529.mail-out.ovh.net; envelope-from=clg@kaod.org;
receiver=<UNKNOWN>)
X-Greylist: delayed 504 seconds by postgrey-1.36 at boromir;
Mon, 11 Oct 2021 18:10:42 AEDT
Received: from smtpout2.mo529.mail-out.ovh.net
(smtpout2.mo529.mail-out.ovh.net [79.137.123.220])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by lists.ozlabs.org (Postfix) with ESMTPS id 4HSVLp4Pwcz2yPv
for <linuxppc-dev@lists.ozlabs.org>; Mon, 11 Oct 2021 18:10:42 +1100 (AEDT)
Received: from mxplan5.mail.ovh.net (unknown [10.109.156.216])
by mo529.mail-out.ovh.net (Postfix) with ESMTPS id 0EC30C3BBB9B;
Mon, 11 Oct 2021 09:02:09 +0200 (CEST)
Received: from kaod.org (37.59.142.95) by DAG4EX1.mxp5.local (172.16.2.31)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Mon, 11 Oct
2021 09:02:09 +0200
Authentication-Results: garm.ovh; auth=pass
(GARM-95G0010762b5aa-8db3-4685-afb6-69febc946e19,
044DEDDE8B0E05FD49EE52B84AFD98BA54CEE260) smtp.auth=clg@kaod.org
X-OVh-ClientIp: 82.64.250.170
From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>
To: <linuxppc-dev@lists.ozlabs.org>
Subject: [PATCH] powerpc/xive: Discard disabled interrupts in
get_irqchip_state()
Date: Mon, 11 Oct 2021 09:02:03 +0200
Message-ID: <20211011070203.99726-1-clg@kaod.org>
X-Mailer: git-send-email 2.31.1
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [37.59.142.95]
X-ClientProxiedBy: DAG3EX1.mxp5.local (172.16.2.21) To DAG4EX1.mxp5.local
(172.16.2.31)
X-Ovh-Tracer-GUID: 1fcd0286-05cf-4e09-8d7f-6cb5e00e2edd
X-Ovh-Tracer-Id: 16244765333835647968
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvtddrvddthedgudduvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhephffvufffkffogggtgfhisehtkeertdertdejnecuhfhrohhmpeevrogurhhitgcunfgvucfiohgrthgvrhcuoegtlhhgsehkrghougdrohhrgheqnecuggftrfgrthhtvghrnhepfedvuedtvdeikeekuefhkedujeejgffggffhtefglefgveevfeeghfdvgedtleevnecukfhppedtrddtrddtrddtpdefjedrheelrddugedvrdelheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehmgihplhgrnhehrdhmrghilhdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomheptghlgheskhgrohgurdhorhhgpdhrtghpthhtoheptghlgheskhgrohgurdhorhhg
X-BeenThere: linuxppc-dev@lists.ozlabs.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Linux on PowerPC Developers Mail List <linuxppc-dev.lists.ozlabs.org>
List-Unsubscribe: <https://lists.ozlabs.org/options/linuxppc-dev>,
<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=unsubscribe>
List-Archive: <http://lists.ozlabs.org/pipermail/linuxppc-dev/>
List-Post: <mailto:linuxppc-dev@lists.ozlabs.org>
List-Help: <mailto:linuxppc-dev-request@lists.ozlabs.org?subject=help>
List-Subscribe: <https://lists.ozlabs.org/listinfo/linuxppc-dev>,
<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=subscribe>
Cc: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>,
stable@vger.kernel.org
Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org
Sender: "Linuxppc-dev"
<linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org>
When an interrupt is passed through, the KVM XIVE device calls the
set_vcpu_affinity() handler which raises the P bit to mask the
interrupt and to catch any in-flight interrupts while routing the
interrupt to the guest.
On the guest side, drivers (like some Intels) can request at probe
time some MSIs and call synchronize_irq() to check that there are no
in flight interrupts. This will call the XIVE get_irqchip_state()
handler which will always return true as the interrupt P bit has been
set on the host side and lock the CPU in an infinite loop.
Fix that by discarding disabled interrupts in get_irqchip_state().
Fixes: da15c03b047d ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race")
Cc: stable@vger.kernel.org#v5.4+
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/powerpc/sysdev/xive/common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
index c732ce5a3e1a..c5d75c02ad8b 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -945,7 +945,8 @@ static int xive_get_irqchip_state(struct irq_data *data,
* interrupt to be inactive in that case.
*/
*state = (pq != XIVE_ESB_INVALID) && !xd->stale_p &&
- (xd->saved_p || !!(pq & XIVE_ESB_VAL_P));
+ (xd->saved_p || (!!(pq & XIVE_ESB_VAL_P) &&
+ !irqd_irq_disabled(data)));
return 0;
default:
return -EINVAL;
--
2.31.1
^ permalink raw reply related
* Re: [PATCH] powerpc/xive: Discard disabled interrupts in get_irqchip_state()
From: seeteena @ 2021-10-11 9:50 UTC (permalink / raw)
To: clg; +Cc: linuxppc-dev, stable
In-Reply-To: <20211011070203.99726-1-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 158 bytes --]
Tested-by: seeteena<s1seetee@linux.vnet.ibm.com>
I have used a KVM guest with a passthrough ethernet adapter and the
lspci output to identify the adapter.
[-- Attachment #2: Type: text/html, Size: 2399 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] powerpc/numa: Fill distance_lookup_table for offline nodes
From: Michael Ellerman @ 2021-10-11 11:45 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Nathan Lynch, Gautham R Shenoy, Vincent Guittot,
kernel test robot, Peter Zijlstra, Geetika Moolchandani,
Valentin Schneider, Laurent Dufour, linuxppc-dev, Ingo Molnar
In-Reply-To: <20210923175748.GC2004@linux.vnet.ibm.com>
Srikar Dronamraju <srikar@linux.vnet.ibm.com> writes:
> * Michael Ellerman <mpe@ellerman.id.au> [2021-09-23 21:17:25]:
>
>> Srikar Dronamraju <srikar@linux.vnet.ibm.com> writes:
>> > * Michael Ellerman <mpe@ellerman.id.au> [2021-08-26 23:36:53]:
>> >
>> >> Srikar Dronamraju <srikar@linux.vnet.ibm.com> writes:
>> >> > Scheduler expects unique number of node distances to be available at
>> >> > boot.
>> ...
>> >
>> >> > Fake the offline node's distance_lookup_table entries so that all
>> >> > possible node distances are updated.
>> >>
>> >> Does this work if we have a single node offline at boot?
>> >>
>> >
>> > It should.
>> >
>> >> Say we start with:
>> >>
>> >> node distances:
>> >> node 0 1
>> >> 0: 10 20
>> >> 1: 20 10
>> >>
>> >> And node 2 is offline at boot. We can only initialise that nodes entries
>> >> in the distance_lookup_table:
>> >>
>> >> while (i--)
>> >> distance_lookup_table[node][i] = node;
>> >>
>> >> By filling them all with 2 that causes node_distance(2, X) to return the
>> >> maximum distance for all other nodes X, because we won't break out of
>> >> the loop in __node_distance():
>> >>
>> >> for (i = 0; i < distance_ref_points_depth; i++) {
>> >> if (distance_lookup_table[a][i] == distance_lookup_table[b][i])
>> >> break;
>> >>
>> >> /* Double the distance for each NUMA level */
>> >> distance *= 2;
>> >> }
>> >>
>> >> If distance_ref_points_depth was 4 we'd return 160.
>> >
>> > As you already know, distance 10, 20, .. are defined by Powerpc, form1
>> > affinity. PAPR doesn't define actual distances, it only provides us the
>> > associativity. If there are distance_ref_points_depth is 4,
>> > (distance_ref_points_depth doesn't take local distance into consideration)
>> > 10, 20, 40, 80, 160.
>> >
>> >>
>> >> That'd leave us with 3 unique distances at boot, 10, 20, 160.
>> >>
>> >
>> > So if there are unique distances, then the distances as per the current
>> > code has to be 10, 20, 40, 80.. I dont see a way in which we have a break in
>> > the series. like having 160 without 80.
>>
>> I'm confused what you mean there.
>
> At the outset, if we have a better probable solution, do let me know, I am
> willing to try that too.
I don't have one in mind no, I'm just trying to satisfy myself that this
solution will work in all cases we're likely to encounter.
>> If we have a node that's offline at boot then we get 160 for that node,
>> that's just the result of having no info for it, so we never break out
>> of the for loop.
>>
>> So if we have two nodes, one hop apart, and then an offline node we get
>> 10, 20, 160.
>>
>> Or if you're using depth = 3 then it's 10, 20, 80.
>
> My understanding is as below:
>
> device-tree provides the max hops by way of
> ibm,associativity-reference-points. This is mapped to
> distance_ref_points_depth in Linux-powerpc.
>
> Now Linux-powerpc encodes hops as (dis-regarding local distance) 20, 40, 80,
> 160, 320 ...
> So if the distance_ref_points_depth is 3, then the hops are 20, 40, 80.
>
> Do you disagree?
I'm not sure. You didn't really address my point.
You said that we can't have 160 without 80 (for depth = 4).
I gave an example where we could see a gap in the used distance values,
ie. 10, 20, 80 for a depth of 3.
Which is not to say that distance 40 doesn't exist in that scenario,
rather that it's not used by any node.
>> >> But when node 2 comes online it might introduce more than 1 new distance
>> >> value, eg. it could be that the actual distances are:
>> >>
>> >> node distances:
>> >> node 0 1 2
>> >> 0: 10 20 40
>> >> 1: 20 10 80
>> >> 2: 40 80 10
>> >>
>> >> ie. we now have 4 distances, 10, 20, 40, 80.
>> >>
>> >> What am I missing?
>> >
>> > As I said above, I am not sure how we can have a break in the series.
>> > If distance_ref_points_depth is 3, the distances has to be 10,20,40,80 as
>> > atleast for form1 affinity.
>>
>> I agree for depth 3 we have to see 10, 20, 40, 80. But nothing
>> guarantees we see each value (other than 10).
>
> The hop distances are not from the device-tree, the device-tree only gives
> us the max hops possible. Linux-powerpc is actually hard-coding the
> distances which each hop distance being 2x the previous.
Yes. I guess I was sloppy to say "see each value", I didn't mean we see
those values directly in the device-tree.
> So we may not see any nodes at a particular hop, but we know maximum hops.
> And if distance_ref_points_depth is 3, then hops are 20, 40, 80 only.
OK, so we agree that "we may not see any nodes at a particular hop".
Which is what I was trying to say above.
>> We can have two nodes one hop apart, so we have 10 and 20, then a third
>> node is added 3 hops away, so we get 10, 20, 80.
>>
>
>> The real problem is that the third node could be 3 hops from node 0
>> and 2 hops from node 1, and so the addition of the third node causes
>> two new distance values (40 & 80) to be required.
>
> So here the max hops as given by device-tree is 3. So we know that we are
> looking for max-distance of 80 by way of distance_ref_points_depth.
>
> Even if the 3rd node was at 4 hops, we would already know the max distance
> of 160, by way of distance_ref_points_depth.
I agree we know that the max value is, and therefore the total number of
possible distance values.
But I think there are topologies where we can not represent all the
possible distances in the distance table.
> However in the most unlikely scenarios where the number of possible
> nodes are less than the distance_ref_points_depth(aka max hops) +
> there are CPUless/memoryless nodes we may not have initialized to the
> right distances.
OK, so I think you're saying you agree that there are situations where
we might not be able to represent all the distances.
But you say that's an "unlikely scenario", why is it unlikely?
If you can convince me it's 100% unlikely then maybe we can forget about
it :)
>> I think maybe what you're saying is that in practice we don't see setups
>> like that. But I don't know if I'm happy with a solution that doesn't
>> work in the general case, and relies on the particular properties of our
>> current set of systems.
>
> But our current set of systems are having a problem (Systems can likely
> crash on adding a CPU to a node.)
Yes I agree that's bad, but also we don't want to merge a solution (and
presumably backport it everywhere) if it doesn't work for some cases.
> The only other way I can think of is the previous approach were we ask
> scheduler hook which tells how many unique node distances are
> possible. But then it was stuck down because, we didnt want to add a
> hook just for one arch.
OK.
> However isn't this is much much better than the current situation we are in?
> i.e This is not going to cause any regression for the other setups.
Yes that's true. But equally if we can find a 100% solution that would
save us having to fix the same issue again in future.
>> Possibly we just need to detect that case and WARN about it. The only
>> problem is we won't know until the system is already up and running, ie.
>> we can't know at boot that the onlining of the third node will cause 2
>> new distance values to be added.
>
> Yes, We should be able to detect this very easily.
> At the end of the function (v2 or v3) if cur_depth != max_depth then we
> havent initialized all possible node distances.
The only issue is what do we do when we detect that case?
We can't BUG/panic, because we don't know for sure that the offline
nodes will cause new distance values to be needed. So the system might
be completely fine, all we know is it might not be. If we print a scary
warning we'll end up with bugs filed for that.
cheers
^ permalink raw reply
* Re: [PATCH kernel v2] powerps/pseries/dma: Add support for 2M IOMMU page size
From: Michael Ellerman @ 2021-10-11 12:06 UTC (permalink / raw)
To: linuxppc-dev, Alexey Kardashevskiy; +Cc: Frederic Barrat, Leonardo Bras
In-Reply-To: <20211006044735.1114669-1-aik@ozlabs.ru>
On Wed, 6 Oct 2021 15:47:35 +1100, Alexey Kardashevskiy wrote:
> The upcoming PAPR spec adds a 2M page size, bit 23 right after 16G page
> size in the "ibm,query-pe-dma-window" call.
>
> This adds support for the new page size. Since the new page size is out
> of sorted order, this changes the loop to not assume that shift[] is
> sorted.
>
> [...]
Applied to powerpc/next.
[1/1] powerps/pseries/dma: Add support for 2M IOMMU page size
https://git.kernel.org/powerpc/c/3872731187141d5d0a5c4fb30007b8b9ec36a44d
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/476: Fix sparse report
From: Michael Ellerman @ 2021-10-11 12:06 UTC (permalink / raw)
To: Paul Mackerras, Christophe Leroy, Benjamin Herrenschmidt,
Michael Ellerman
Cc: Alistair Popple, linuxppc-dev, kernel test robot, linux-kernel
In-Reply-To: <aa6055769b92a5d8685b8d0adab99c48a0b0ef4b.1631956926.git.christophe.leroy@csgroup.eu>
On Sat, 18 Sep 2021 11:22:32 +0200, Christophe Leroy wrote:
> arch/powerpc/platforms/44x/ppc476.c:236:17: warning: cast removes address space '__iomem' of expression
> arch/powerpc/platforms/44x/ppc476.c:241:34: warning: incorrect type in argument 1 (different address spaces)
> arch/powerpc/platforms/44x/ppc476.c:241:34: expected void const volatile [noderef] __iomem *addr
> arch/powerpc/platforms/44x/ppc476.c:241:34: got unsigned char [usertype] *
> arch/powerpc/platforms/44x/ppc476.c:243:17: warning: incorrect type in argument 1 (different address spaces)
> arch/powerpc/platforms/44x/ppc476.c:243:17: expected void volatile [noderef] __iomem *addr
> arch/powerpc/platforms/44x/ppc476.c:243:17: got unsigned char [usertype] *[assigned] fpga
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/476: Fix sparse report
https://git.kernel.org/powerpc/c/494f238a3861863d908af7b98a369f6d8a986c85
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mem: Fix arch/powerpc/mm/mem.c:53:12: error: no previous prototype for 'create_section_mapping'
From: Michael Ellerman @ 2021-10-11 12:06 UTC (permalink / raw)
To: Paul Mackerras, Christophe Leroy, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, kernel test robot, linux-kernel
In-Reply-To: <025754fde3d027904ae9d0191f395890bec93369.1631541649.git.christophe.leroy@csgroup.eu>
On Mon, 13 Sep 2021 17:17:26 +0200, Christophe Leroy wrote:
> Commit 8e11d62e2e87 ("powerpc/mem: Add back missing header to fix 'no
> previous prototype' error") was supposed to fix the problem, but in
> the meantime commit a927bd6ba952 ("mm: fix phys_to_target_node() and*
> memory_add_physaddr_to_nid() exports") moved create_section_mapping()
> prototype from asm/sparsemem.h to asm/mmzone.h
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/mem: Fix arch/powerpc/mm/mem.c:53:12: error: no previous prototype for 'create_section_mapping'
https://git.kernel.org/powerpc/c/7eff9bc00ddf1e2281dff575884b7f676c85b006
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/powermac: Remove stale declaration of pmac_md
From: Michael Ellerman @ 2021-10-11 12:06 UTC (permalink / raw)
To: Paul Mackerras, Christophe Leroy, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <b2e52934e5a500f149e6d94db3cfa0569bc35081.1630657402.git.christophe.leroy@csgroup.eu>
On Fri, 3 Sep 2021 08:23:52 +0000 (UTC), Christophe Leroy wrote:
> pmac_md doesn't exist anymore, remove stall declaration.
>
Applied to powerpc/next.
[1/1] powerpc/powermac: Remove stale declaration of pmac_md
https://git.kernel.org/powerpc/c/9d7fb0643a156a5dddd887814e1263b648501cb0
cheers
^ permalink raw reply
* Re: [PATCH] video: fbdev: use memset_io() instead of memset()
From: Michael Ellerman @ 2021-10-11 12:06 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Andrew Morton
Cc: linux-fbdev, Finn Thain, Stan Johnson, linux-kernel, dri-devel,
linuxppc-dev
In-Reply-To: <884a54f1e5cb774c1d9b4db780209bee5d4f6718.1631712563.git.christophe.leroy@csgroup.eu>
On Wed, 15 Sep 2021 15:34:35 +0200, Christophe Leroy wrote:
> While investigating a lockup at startup on Powerbook 3400C, it was
> identified that the fbdev driver generates alignment exception at
> startup:
>
> --- interrupt: 600 at memset+0x60/0xc0
> NIP: c0021414 LR: c03fc49c CTR: 00007fff
> REGS: ca021c10 TRAP: 0600 Tainted: G W (5.14.2-pmac-00727-g12a41fa69492)
> MSR: 00009032 <EE,ME,IR,DR,RI> CR: 44008442 XER: 20000100
> DAR: cab80020 DSISR: 00017c07
> GPR00: 00000007 ca021cd0 c14412e0 cab80000 00000000 00100000 cab8001c 00000004
> GPR08: 00100000 00007fff 00000000 00000000 84008442 00000000 c0006fb4 00000000
> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00100000
> GPR24: 00000000 81800000 00000320 c15fa400 c14d1878 00000000 c14d1800 c094e19c
> NIP [c0021414] memset+0x60/0xc0
> LR [c03fc49c] chipsfb_pci_init+0x160/0x580
> --- interrupt: 600
> [ca021cd0] [c03fc46c] chipsfb_pci_init+0x130/0x580 (unreliable)
> [ca021d20] [c03a3a70] pci_device_probe+0xf8/0x1b8
> [ca021d50] [c043d584] really_probe.part.0+0xac/0x388
> [ca021d70] [c043d914] __driver_probe_device+0xb4/0x170
> [ca021d90] [c043da18] driver_probe_device+0x48/0x144
> [ca021dc0] [c043e318] __driver_attach+0x11c/0x1c4
> [ca021de0] [c043ad30] bus_for_each_dev+0x88/0xf0
> [ca021e10] [c043c724] bus_add_driver+0x190/0x22c
> [ca021e40] [c043ee94] driver_register+0x9c/0x170
> [ca021e60] [c0006c28] do_one_initcall+0x54/0x1ec
> [ca021ed0] [c08246e4] kernel_init_freeable+0x1c0/0x270
> [ca021f10] [c0006fdc] kernel_init+0x28/0x11c
> [ca021f30] [c0017148] ret_from_kernel_thread+0x14/0x1c
> Instruction dump:
> 7d4601a4 39490777 7d4701a4 39490888 7d4801a4 39490999 7d4901a4 39290aaa
> 7d2a01a4 4c00012c 4bfffe88 0fe00000 <4bfffe80> 9421fff0 38210010 48001970
>
> [...]
Applied to powerpc/next.
[1/1] video: fbdev: use memset_io() instead of memset()
https://git.kernel.org/powerpc/c/f2719b26ae27282c145202ffd656d5ff1fe737cc
cheers
^ 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