Le 07/12/2021 à 07:41, Nathan Chancellor a écrit :
> On Tue, Dec 07, 2021 at 05:45:08AM +, Christophe Leroy wrote:
>>
>>
>> Le 07/12/2021 à 05:48, Nathan Chancellor a écrit :
>>> On Tue, Dec 07, 2021 at 02:37:26PM +1100, Michael Ellerman wrote:
Bill Wendling writes:
> On Tue, Nov 30
On Mon, Dec 06, 2021 at 11:28:00PM +0100, Thomas Gleixner wrote:
> The irqdomain code already returns the information. Move the loop to the
> legacy code.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:59PM +0100, Thomas Gleixner wrote:
> Get rid of yet another irqdomain callback and let the core code return the
> already available information of how many descriptors could be allocated.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: J
On Mon, Dec 06, 2021 at 11:27:57PM +0100, Thomas Gleixner wrote:
> No users outside of that file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:56PM +0100, Thomas Gleixner wrote:
> It's only required for PCI/MSI. So no point in having it in every struct
> device.
>
> Signed-off-by: Thomas Gleixner
Yes!!!
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:52PM +0100, Thomas Gleixner wrote:
> Move the irqdomain specific code into it's own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:51PM +0100, Thomas Gleixner wrote:
> Split out the non irqdomain code into its own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:49PM +0100, Thomas Gleixner wrote:
> These functions are required even when CONFIG_PCI_MSI is not set. Move them
> to their own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:46PM +0100, Thomas Gleixner wrote:
> No need to walk the descriptors and check for each one whether the entries
> pointer function argument is NULL. Do it once.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-b
On Mon, Dec 06, 2021 at 11:27:39PM +0100, Thomas Gleixner wrote:
> The unnamed struct sucks and is in the way of further cleanups. Stick the
> PCI related MSI data into a real data structure and cleanup all users.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen
On Mon, Dec 06, 2021 at 11:27:36PM +0100, Thomas Gleixner wrote:
> instead of fiddling with msi descriptors.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:31PM +0100, Thomas Gleixner wrote:
> Remove the kobject.h include from msi.h as it's not required and add a
> sysfs.h include to the core code instead.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg K
On Mon, Dec 06, 2021 at 11:27:28PM +0100, Thomas Gleixner wrote:
> No point in building unused code when CONFIG_SYSFS=n.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
Hello Thomas,
On 12/6/21 23:27, Thomas Gleixner wrote:
This code is broken since day one. ppc4xx_setup_msi_irqs() has the
following gems:
1) The handling of the result of msi_bitmap_alloc_hwirqs() is completely
broken:
When the result is greater than or equal 0 (bitmap allocat
On Tue, Dec 07, 2021 at 05:45:08AM +, Christophe Leroy wrote:
>
>
> Le 07/12/2021 à 05:48, Nathan Chancellor a écrit :
> > On Tue, Dec 07, 2021 at 02:37:26PM +1100, Michael Ellerman wrote:
> >> Bill Wendling writes:
> >>> On Tue, Nov 30, 2021 at 10:38 AM Bill Wendling wrote:
> On Tue,
Le 07/12/2021 à 06:50, Christophe Leroy a écrit :
Le 06/12/2021 à 16:48, Maxime Bizon a écrit :
On Mon, 2021-12-06 at 14:22 +, Christophe Leroy wrote:
Fixed both in v2.
Works fine, many thanks
Great.
Could you then reply to the patch with the following line ?
Reported-by: Maxi
Allthough kernel text is always mapped with BATs, we still have
inittext mapped with pages, so TLB miss handling is required
when CONFIG_DEBUG_PAGEALLOC or CONFIG_KFENCE is set.
The final solution should be to set a BAT that also maps inittext
but that BAT then needs to be cleared at end of init,
Le 05/12/2021 à 17:42, Maxime Bizon a écrit :
>
>
> On Saturday 04 Dec 2021 à 17:42:44 (+), Christophe Leroy wrote:
>
> Also when mem=2G, I have physical memory mapped twice:
>
> CONFIG_PAGE_OFFSET=0x8000
> CONFIG_LOWMEM_SIZE=0x6000
>
> 0: 0x8000-0x8fff 0x 2
Le 06/12/2021 à 16:48, Maxime Bizon a écrit :
>
> On Mon, 2021-12-06 at 14:22 +, Christophe Leroy wrote:
>
>> Fixed both in v2.
>
> Works fine, many thanks
>
Great.
Could you then reply to the patch with the following line ?
Reported-by: Maxime Bizon
That way it will be taken into ac
Le 07/12/2021 à 05:48, Nathan Chancellor a écrit :
> On Tue, Dec 07, 2021 at 02:37:26PM +1100, Michael Ellerman wrote:
>> Bill Wendling writes:
>>> On Tue, Nov 30, 2021 at 10:38 AM Bill Wendling wrote:
On Tue, Nov 30, 2021 at 10:17 AM Nathan Chancellor
wrote:
> On Tue, Nov 30, 2
On Tue, Dec 07, 2021 at 02:37:26PM +1100, Michael Ellerman wrote:
> Bill Wendling writes:
> > On Tue, Nov 30, 2021 at 10:38 AM Bill Wendling wrote:
> >> On Tue, Nov 30, 2021 at 10:17 AM Nathan Chancellor
> >> wrote:
> >> > On Tue, Nov 30, 2021 at 10:25:43PM +1100, Michael Ellerman wrote:
> >> >
Bill Wendling writes:
> On Tue, Nov 30, 2021 at 10:38 AM Bill Wendling wrote:
>> On Tue, Nov 30, 2021 at 10:17 AM Nathan Chancellor wrote:
>> > On Tue, Nov 30, 2021 at 10:25:43PM +1100, Michael Ellerman wrote:
>> > > Christophe Leroy writes:
>> > > > Le 29/11/2021 à 23:55, kernel test robot a é
The irqdomain code already returns the information. Move the loop to the
legacy code.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
drivers/pci/msi/legacy.c | 20 +++-
drivers/pci/msi/msi.c| 19 +--
2 files chan
Get rid of yet another irqdomain callback and let the core code return the
already available information of how many descriptors could be allocated.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
drivers/pci/msi/irqdomain.c | 13 -
includ
No users outside of that file.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
drivers/pci/msi/irqdomain.c |5 +++--
include/linux/msi.h |2 --
2 files changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/pci/msi/irqdomain.c
+++ b/dri
It's only required for PCI/MSI. So no point in having it in every struct
device.
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
drivers/base/core.c|1 -
drivers/pci/msi/msi.c |2 +-
drivers/pci/probe.c|4 +++-
include/linux/device.h |2 --
include/linux/pci.h|
Unmapping the MSIX base mapping in the loops which allocate/free MSI
desciptors is daft and in the way of allowing runtime expansion of MSI-X
descriptors.
Store the mapping in struct pci_dev and free it after freeing the MSI-X
descriptors.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Move the irqdomain specific code into it's own file.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
drivers/pci/msi/Makefile|1
drivers/pci/msi/irqdomain.c | 279 ++
drivers/pci/msi/legacy.c| 13 +
dr
Split out the non irqdomain code into its own file.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
V2: Add proper includes and fix variable name - Cedric
---
drivers/pci/msi/Makefile |5 ++--
drivers/pci/msi/legacy.c | 52
These functions are required even when CONFIG_PCI_MSI is not set. Move them
to their own file.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
drivers/pci/msi/Makefile |3 ++-
drivers/pci/msi/msi.c| 39 -
msi.c is getting larger and really could do with a splitup. Move it into
it's own directory to prepare for that.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
Documentation/driver-api/pci/pci.rst |2
drivers/pci/Makefile |3
No need to walk the descriptors and check for each one whether the entries
pointer function argument is NULL. Do it once.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
drivers/pci/msi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
---
Get rid of the pile of unneeded includes which accumulated over time.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
V2: Address build fail on powerpc - Cedric
---
drivers/pci/msi.c | 16
1 file changed, 4 insertions(+), 12 deletions
Make arch_restore_msi_irqs() return a boolean which indicates whether the
core code should restore the MSI message or not. Get rid of the indirection
in x86.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
Cc: x...@kernel.org
Cc: xen-de...@lists.xenproject.o
No point in looking up things over and over. Just look up the associated
irq data and work from there.
No functional change.
Signed-off-by: Thomas Gleixner
Reviewed-by: Jason Gunthorpe
Acked-by: Wei Liu
Cc: x...@kernel.org
Cc: linux-hyp...@vger.kernel.org
---
arch/x86/hyperv/irqdomain.c | 5
The unnamed struct sucks and is in the way of further cleanups. Stick the
PCI related MSI data into a real data structure and cleanup all users.
No functional change.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
Acked-by: Kalle Valo
Cc: Greg Kroah-Hartm
The core code provides the same loop code except for the MSI-X reject. Move
that to arch_setup_msi_irq() and remove the duplicated code.
No functional change.
Signed-off-by: Thomas Gleixner
Reviewed-by: Jason Gunthorpe
Acked-by: Thomas Bogendoerfer
Cc: linux-m...@vger.kernel.org
---
arch/mips
instead of fiddling with msi descriptors.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
drivers/pci/pci-sysfs.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -62,11 +62,
Last user is gone long ago.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
drivers/pci/msi.c |8
include/linux/msi.h |5 -
2 files changed, 13 deletions(-)
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1267,14 +1267,6 @@ s
There is no point to have this function public as it is set by the PCI core
anyway when a PCI/MSI irqdomain is created.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
drivers/irqchip/irq-gic-v2m.c|1 -
drivers/irqchip/irq-gic-v3-its-pci
Remove the kobject.h include from msi.h as it's not required and add a
sysfs.h include to the core code instead.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
include/linux/msi.h |2 +-
kernel/irq/msi.c|1 +
2 files changed, 2 insertions(+
No users and there is no need to grow them.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
Link: https://lore.kernel.org/r/20211126223824.322987...@linutronix.de
---
include/linux/msi.h | 11 ---
kernel/irq/msi.c|5 -
2 files changed,
The [PCI] MSI code has gained quite some warts over time. A recent
discussion unearthed a shortcoming: the lack of support for expanding
PCI/MSI-X vectors after initialization of MSI-X.
PCI/MSI-X has no requirement to setup all vectors when MSI-X is enabled in
the device. The non-used vectors have
pci_irq_vector() and pci_irq_get_affinity() use the list position to find the
MSI-X descriptor at a given index. That's correct for the normal case where
the entry number is the same as the list position.
But it's wrong for cases where MSI-X was allocated with an entries array
describing sparse en
No point in building unused code when CONFIG_SYSFS=n.
Signed-off-by: Thomas Gleixner
Tested-by: Juergen Gross
Reviewed-by: Jason Gunthorpe
---
include/linux/msi.h | 10 ++
kernel/irq/msi.c|2 ++
2 files changed, 12 insertions(+)
--- a/include/linux/msi.h
+++ b/include/linux/
This code is broken since day one. ppc4xx_setup_msi_irqs() has the
following gems:
1) The handling of the result of msi_bitmap_alloc_hwirqs() is completely
broken:
When the result is greater than or equal 0 (bitmap allocation
successful) then the loop terminates and the function
On Fri, 3 Dec 2021 14:50:17 -0300, Ariel D'Alessandro wrote:
> This is a follow up of patchsets:
>
> [RFC patch 0/5] Support BCLK input clock in tlv320aic31xx
> [PATCH 0/4] fsl-asoc-card: Add optional dt property for setting mclk-id
>
> Patch "ASoC: fsl-asoc-card: Support fsl,imx-audio-tlv320
On Mon, 2021-12-06 at 14:22 +, Christophe Leroy wrote:
> Fixed both in v2.
Works fine, many thanks
--
Maxime
Le 06/12/2021 à 11:32, Maxime Bizon a écrit :
>
>
> On Mon, 2021-12-06 at 09:07 +, Christophe Leroy wrote:
>
> Hello,
>
>> Looks like you can win something if you take the patch I just sent
>> and replace the memblock_phys_alloc(k_size, k_size) by
>> memblock_phys_alloc_range(k_size, k_si
It has been reported some configuration where the kernel doesn't
boot with KASAN enabled.
This is due to wrong BAT allocation for the KASAN area:
---[ Data Block Address Translation ]---
0: 0xc000-0xcfff 0x 256M Kernel rw m
1: 0xd000-0xdf
Unmapping a fixmap entry is done by calling __set_fixmap()
with FIXMAP_PAGE_CLEAR as flags.
Today, powerpc __set_fixmap() calls map_kernel_page().
map_kernel_page() is not happy when called a second time
for the same page.
WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194
set_pte_
On Mon, 2021-12-06 at 09:07 +, Christophe Leroy wrote:
Hello,
> Looks like you can win something if you take the patch I just sent
> and replace the memblock_phys_alloc(k_size, k_size) by
> memblock_phys_alloc_range(k_size, k_size, 0, MEMBLOCK_ALLOC_ANYWHERE)
I tried your patch without y
@Palmer, can I do anything for that to be pulled in 5.17?
Thanks,
Alex
On 10/27/21 07:04, Alexandre ghiti wrote:
Hi Palmer,
On 10/26/21 11:29 PM, Palmer Dabbelt wrote:
On Sat, 09 Oct 2021 10:20:20 PDT (-0700), a...@ghiti.fr wrote:
Arf, I have sent this patchset with the wrong email address.
The code represent memory/cache level data based on PERF_MEM_LVL_*
namespace, which is in the process of deprication in the favour of
newer composite PERF_MEM_{LVLNUM_,REMOTE_,SNOOPX_,HOPS_} fields.
Add data source encodings to represent cache/memory data based on
newer composite PERF_MEM_{LVLNUM_,
The code represent data coming from L1/L2/L3 cache hits based on
PERF_MEM_LVL_* namespace, which is in the process of deprecation in
the favour of newer composite PERF_MEM_{LVLNUM_,REMOTE_,SNOOPX_,HOPS_}
fields.
Add data source encodings to represent L1/L2/L3 cache hits based on
newer composite PE
Add new macros for mem_hops field which can be used to
represent remote-node, socket and board level details.
Currently the code had macro for HOPS_0 which, corresponds
to data coming from another core but same node.
Add new macros for HOPS_1 to HOPS_3 to represent
remote-node, socket and board le
Add new macros for mem_hops field which can be used to
represent remote-node, socket and board level details.
Currently the code had macro for HOPS_0, which corresponds
to data coming from another core but same node.
Add new macros for HOPS_1 to HOPS_3 to represent
remote-node, socket and board le
Patchset adds new macros for mem_hops field which can be
used to represent remote-node, socket and board level details.
Currently the code had macro for HOPS_0, which corresponds
to data coming from another core but same node.
Add new macros for HOPS_1 to HOPS_3 to represent
remote-node, socket an
Le 06/12/2021 à 09:47, Maxime Bizon a écrit :
>
> On Mon, 2021-12-06 at 07:03 +, Christophe Leroy wrote:
>
>> Is it worth it ? I have the feeling that's more a corner case.
>
> probably not since it's not an easy fix
>
> I'm running on the edge wrt BAT usage on my 2GB board, it's not that
On Mon, 2021-12-06 at 07:03 +, Christophe Leroy wrote:
> Is it worth it ? I have the feeling that's more a corner case.
probably not since it's not an easy fix
I'm running on the edge wrt BAT usage on my 2GB board, it's not that
common I guess.
--
Maxime
It has been reported some configuration where the kernel doesn't
boot with KASAN enabled.
This is due to wrong BAT allocation for the KASAN area:
---[ Data Block Address Translation ]---
0: 0xc000-0xcfff 0x 256M Kernel rw m
1: 0xd000-0xdf
61 matches
Mail list logo
