On Fri, Jun 14, 2024 at 10:56:20PM +0530, Athira Rajeev wrote:
> Currently, the perf tool infrastructure disasm_line__parse function to
> parse disassembled line.
>
> Example snippet from objdump:
> objdump --start-address= --stop-address= -d
> --no-show-raw-insn -C
>
> c10224b4:
On Fri, Jun 14, 2024 at 10:56:19PM +0530, Athira Rajeev wrote:
> perf annotate can be done in different ways. One way is to directly use
> "perf annotate" command, other way to annotate specific symbol is to do
> "perf report" and press "a" on the sample in UI mode. The approach
> preferred in
On Fri, Jun 14, 2024 at 10:56:18PM +0530, Athira Rajeev wrote:
> Add support to capture and parse raw instruction in powerpc.
> Currently, the perf tool infrastructure uses two ways to disassemble
> and understand the instruction. One is objdump and other option is
> via libcapstone.
>
>
Le 25/06/2024 à 06:49, Nicholas Piggin a écrit :
> On Tue Jun 25, 2024 at 12:45 AM AEST, Christophe Leroy wrote:
>> On book3s/64, the only user of hugepd is hash in 4k mode.
>>
>> All other setups (hash-64, radix-4, radix-64) use leaf PMD/PUD.
>>
>> Rework hash-4k to use contiguous PMD and PUD
Hello,
On Fri, Jun 14, 2024 at 10:56:16PM +0530, Athira Rajeev wrote:
> Data type profiling uses instruction tracking by checking each
> instruction and updating the register type state in some data
> structures. This is useful to find the data type in cases when the
> register state gets
On Tue Jun 25, 2024 at 12:45 AM AEST, Christophe Leroy wrote:
> On book3s/64, the only user of hugepd is hash in 4k mode.
>
> All other setups (hash-64, radix-4, radix-64) use leaf PMD/PUD.
>
> Rework hash-4k to use contiguous PMD and PUD instead.
>
> In that setup there are only two huge page
randconfig-002-20240625 clang-19
i386 buildonly-randconfig-001-20240624 gcc-8
i386 buildonly-randconfig-002-20240624 gcc-13
i386 buildonly-randconfig-003-20240624 clang-18
i386 buildonly-randconfig-004-20240624 gcc-10
i386 buildonly
On 2024/6/24 23:56, Ryan Roberts wrote:
+ Baolin Wang and Yin Fengwei, who maybe able to help with this.
Hi Kefeng,
Thanks for the report!
On 24/06/2024 15:30, Kefeng Wang wrote:
Hi Ryan,
A big regression on page-fault3("Separate file shared mapping page
fault") testcase from
Hello,
kernel test robot noticed a 22.6% improvement of aim7.jobs-per-min on:
commit: 1122c0c1cc71f740fa4d5f14f239194e06a1d5e7 ("block: move cache control
settings out of queue->flags")
https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git for-next
testcase: aim7
test machine:
On Wed Jun 19, 2024 at 4:39 AM AEST, Thomas Huth wrote:
> On 12/06/2024 07.23, Nicholas Piggin wrote:
> > Add some initial PMU testing.
> >
> > - PMC5/6 tests
> > - PMAE / PMI test
> > - BHRB basic tests
> >
> > Signed-off-by: Nicholas Piggin
> > ---
> ...
> > diff --git a/powerpc/pmu.c
On Tue, Jun 25 2024 at 00:41, Shrikanth Hegde wrote:
> On 6/24/24 1:44 AM, Thomas Gleixner wrote:
>> Right. So changing it not to online a thread when the full core is
>> offline should not really break stuff.
>>
>> OTH, the mechanism to figure that out on x86 is definitely different and
>> more
> -Original Message-
> From: Sean Christopherson
> Sent: Monday, June 24, 2024 4:32 PM
> To: Shameerali Kolothum Thodi
> Cc: Catalin Marinas ; Will Deacon
> ; Marc Zyngier ; Oliver Upton
> ; Huacai Chen ; Michael
> Ellerman ; Anup Patel ; Paul
> Walmsley ; Palmer Dabbelt
> ; Albert Ou
On 6/24/24 1:44 AM, Thomas Gleixner wrote:
> Michael!
>
> On Thu, Jun 13 2024 at 21:34, Michael Ellerman wrote:
>> IIUIC the regression was in the ppc64_cpu userspace tool, which switched
>> to using the new kernel interface without taking into account the way it
>> behaves.
>>
>> Or are you
On 6/13/24 12:20 AM, Nysal Jan K.A. wrote:
> From: "Nysal Jan K.A"
>
> topology_is_core_online() checks if the core a CPU belongs to
> is online. The core is online if at least one of the sibling
> CPUs is online. The first CPU of an online core is also online
> in the common case, so this
On Mon, Jun 24, 2024 at 11:08:16AM -0600, Keith Busch wrote:
> On Mon, Jun 17, 2024 at 08:04:41AM +0200, Christoph Hellwig wrote:
> > -#define blk_queue_nonrot(q)test_bit(QUEUE_FLAG_NONROT,
> > &(q)->queue_flags)
> > +#define blk_queue_nonrot(q)((q)->limits.features &
> >
On Mon, Jun 17, 2024 at 08:04:41AM +0200, Christoph Hellwig wrote:
> -#define blk_queue_nonrot(q) test_bit(QUEUE_FLAG_NONROT, &(q)->queue_flags)
> +#define blk_queue_nonrot(q) ((q)->limits.features & BLK_FEAT_ROTATIONAL)
This is inverted. Should be:
#define blk_queue_nonrot(q)
From: Arnd Bergmann
Both of these architectures require u64 function arguments to be
passed in even/odd pairs of registers or stack slots, which in case of
sync_file_range would result in a seven-argument system call that is
not currently possible. The system call is therefore incompatible with
From: Arnd Bergmann
The unusual function calling conventions on SuperH ended up causing
sync_file_range to have the wrong argument order, with the 'flags'
argument getting sorted before 'nbytes' by the compiler.
In userspace, I found that musl, glibc, uclibc and strace all expect the
normal
From: Arnd Bergmann
A couple of system calls were inadventently removed from the table during
a bugfix for 32-bit powerpc entry. Restore the original behavior.
Fixes: e23750623835 ("powerpc/32: fix syscall wrappers with 64-bit arguments of
unaligned register-pairs")
Acked-by: Michael Ellerman
From: Arnd Bergmann
The sys_fanotify_mark() syscall on parisc uses the reverse word order
for the two halves of the 64-bit argument compared to all syscalls on
all 32-bit architectures. As far as I can tell, the problem is that
the function arguments on parisc are sorted backwards (26, 25, 24,
From: Arnd Bergmann
Johannes missed parisc back when he introduced the compat version
of these syscalls, so receiving cmsg messages that require a compat
conversion is still broken.
Use the correct calls like the other architectures do.
Fixes: 1dacc76d0014 ("net/compat/wext: send different
From: Arnd Bergmann
sparc has the wrong compat version of recv() and recvfrom() for both the
direct syscalls and socketcall().
The direct syscalls just need to use the compat version. For socketcall,
the same thing could be done, but it seems better to completely remove
the custom assembler
From: Arnd Bergmann
sparc has two identical select syscalls at numbers 93 and 230, respectively.
During the conversion to the modern syscall.tbl format, the older one of the
two broke in compat mode, and now refers to the native 64-bit syscall.
Restore the correct behavior. This has very little
From: Arnd Bergmann
Using sys_io_pgetevents() as the entry point for compat mode tasks
works almost correctly, but misses the sign extension for the min_nr
and nr arguments.
This was addressed on parisc by switching to
compat_sys_io_pgetevents_time64() in commit 6431e92fc827 ("parisc:
From: Arnd Bergmann
The old ftruncate() syscall, using the 32-bit off_t misses a sign
extension when called in compat mode on 64-bit architectures. As a
result, passing a negative length accidentally succeeds in truncating
to file size between 2GiB and 4GiB.
Changing the type of the compat
From: Arnd Bergmann
This is a minor update to v1 of this series. If there are no new
concerns, I would like to send this as a pull request for v6.10-rc6,
which is a little late, but these are all bug fixes. Changes since
v1 are:
- collect acks
- minor fixes to the changelog text
- drop mips
Embedding net_device into structures prohibits the usage of flexible
arrays in the net_device structure. For more details, see the discussion
at [1].
Un-embed the net_devices from struct dpaa2_caam_priv_per_cpu by
converting them into pointers, and allocating them dynamically. Use the
leverage
Embedding net_device into structures prohibits the usage of flexible
arrays in the net_device structure. For more details, see the discussion
at [1].
Un-embed the net_devices from struct caam_qi_pcpu_priv by converting them
into pointers, and allocating them dynamically. Use the leverage
As most of the drivers that depend on ARCH_LAYERSCAPE, make FSL_DPAA
depend on COMPILE_TEST for compilation and testing.
# grep -r depends.\*ARCH_LAYERSCAPE.\*COMPILE_TEST | wc -l
29
Signed-off-by: Breno Leitao
---
drivers/soc/fsl/qbman/Kconfig | 2 +-
1 file changed, 1
As most of the drivers that depend on ARCH_LAYERSCAPE, make
CRYPTO_DEV_FSL_CAAM depend on COMPILE_TEST for compilation and testing.
# grep -r depends.\*ARCH_LAYERSCAPE.\*COMPILE_TEST | wc -l
29
Signed-off-by: Breno Leitao
---
drivers/crypto/caam/Kconfig | 2 +-
1 file changed, 1
+ Baolin Wang and Yin Fengwei, who maybe able to help with this.
Hi Kefeng,
Thanks for the report!
On 24/06/2024 15:30, Kefeng Wang wrote:
> Hi Ryan,
>
> A big regression on page-fault3("Separate file shared mapping page
> fault") testcase from will-it-scale on arm64, no issue on x86,
>
>
On Thu, Jun 20, 2024, Shameerali Kolothum Thodi wrote:
> > This is a borderline RFC series to hide KVM's internals from the rest of
> > the kernel, where "internals" means data structures, enums, #defines,
> > APIs, etc. that are intended to be KVM-only, but are exposed everywhere
> > due to
On Mon, Jun 24, 2024 at 03:45:57PM +0200, Niklas Cassel wrote:
> Seems to be ATA SSD:
> https://download.01.org/0day-ci/archive/20240624/202406241546.6bbd44a7-oliver.s...@intel.com/job.yaml
>
> ssd_partitions:
> "/dev/disk/by-id/ata-INTEL_SSDSC2BG012T4_BTHC428201ZX1P2OGN-par
On Fri, Jun 21, 2024 at 05:30:14PM -0400, Frank Li wrote:
> Convert qman, bman, qman-portals, bman-portals to yaml format.
>
> Additional Chang for fsl,q(b)man-portal:
typo
> - Only keep one example.
> - Add fsl,qman-channel-id property.
> - Use interrupt type macro.
> - Remove top level
Hi Ryan,
A big regression on page-fault3("Separate file shared mapping page
fault") testcase from will-it-scale on arm64, no issue on x86,
./page_fault3_processes -t 128 -s 5
1) large folio disabled on ext4:
92378735
2) large folio enabled on ext4 + CONTPTE enabled
16164943
3) large
powerpc was the only user of CONFIG_ARCH_HAS_HUGEPD and doesn't
use it anymore, so remove all related code.
Signed-off-by: Christophe Leroy
Acked-by: Oscar Salvador
---
v4: Rebased on v6.10-rc1
---
include/linux/hugetlb.h | 6 --
mm/Kconfig | 10 ---
mm/gup.c|
All targets have now opted out of CONFIG_ARCH_HAS_HUGEPD so
remove left over code.
Signed-off-by: Christophe Leroy
Acked-by: Oscar Salvador
---
v5: Fix a forgotten #endif which ended up in following patch
---
arch/powerpc/include/asm/hugetlb.h | 7 -
arch/powerpc/include/asm/page.h
On book3s/64, the only user of hugepd is hash in 4k mode.
All other setups (hash-64, radix-4, radix-64) use leaf PMD/PUD.
Rework hash-4k to use contiguous PMD and PUD instead.
In that setup there are only two huge page sizes: 16M and 16G.
16M sits at PMD level and 16G at PUD level.
pte_update
e500 supports many page sizes among which the following size are
implemented in the kernel at the time being: 4M, 16M, 64M, 256M, 1G.
On e500, TLB miss for hugepages is exclusively handled by SW even
on e6500 which has HW assistance for 4k pages, so there are no
constraints like on the 8xx.
On
Move r13 load after the call to FIND_PTE, and use r13 instead of
r10 for storing fault address. This will allow using r10 freely
in FIND_PTE in following patch to handle hugepage size.
Signed-off-by: Christophe Leroy
---
v5: New
---
arch/powerpc/kernel/head_85xx.S | 30
Don't pre-check write access on read-only pages on data TLB error.
Load the TLB anyway and take a DSI exception when it happens. This
avoids reading SPRN_ESR at every data TLB error exception.
Signed-off-by: Christophe Leroy
---
v5: New
---
arch/powerpc/kernel/head_85xx.S | 15 ---
Use PTE page size bits to encode hugepage size with the following
format corresponding to the values expected in bits 52-55 in MAS1
register. Those bits are called TSIZE:
00014 Kbyte
001016 Kbyte
001164 Kbyte
0100256 Kbyte
01011 Mbyte
At the time being when CONFIG_PTE_64BIT is selected, PTE entries are
64 bits but PGD entries are still 32 bits.
In order to allow leaf PMD entries, switch the PGD to 64 bits entries.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/pgtable-types.h | 4
enc field is hidden behind BOOK3E_PAGESZ_XX macros, and when you look
closer you realise that this field is nothing else than the value of
shift minus ten.
So remove enc field and calculate tsize from shift field.
Also remove inc field which is unused.
Signed-off-by: Christophe Leroy
On 8xx, only the shift field is used in struct mmu_psize_def
Remove other fields and related macros.
Signed-off-by: Christophe Leroy
Reviewed-by: Oscar Salvador
---
arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git
In order to fit better with standard Linux page tables layout, add
support for 8M pages using contiguous PTE entries in a standard
page table. Page tables will then be populated with 1024 similar
entries and two PMD entries will point to that page table.
The PMD entries also get a flag to tell it
set_huge_pte_at() expects the size of the hugepage as an int, not the
psize which is the index of the page definition in table mmu_psize_defs[]
Fixes: 935d4f0c6dc8 ("mm: hugetlb: add huge page size param to
set_huge_pte_at()")
Signed-off-by: Christophe Leroy
Reviewed-by: Oscar Salvador
---
In preparation of implementing huge pages on powerpc 8xx
without hugepd, enclose hugepd related code inside an
ifdef CONFIG_ARCH_HAS_HUGEPD
This also allows removing some stubs.
Signed-off-by: Christophe Leroy
Reviewed-by: Oscar Salvador
---
v3:
- Prepare huge_pte_alloc() for full standard
Building on 32 bits with pmd_leaf() not returning always false leads
to the following error:
CC arch/powerpc/mm/pgtable.o
arch/powerpc/mm/pgtable.c: In function '__find_linux_pte':
arch/powerpc/mm/pgtable.c:506:1: error: function may return address of local
variable
_PAGE_PSIZE macro is never used outside the place it is defined
and is used only on 8xx and e500.
Remove indirection, remove it and use its content directly.
Signed-off-by: Christophe Leroy
Reviewed-by: Oscar Salvador
---
v6: Removed the change to pte-40x.h to avoid conflict with the removal
On powerpc 8xx huge_ptep_get() will need to know whether the given
ptep is a PTE entry or a PMD entry. This cannot be known with the
PMD entry itself because there is no easy way to know it from the
content of the entry.
So huge_ptep_get() will need to know either the size of the page
or get the
On powerpc 8xx, when a page is 8M size, the information is in the PMD
entry. So allow architectures to provide __pte_leaf_size() instead of
pte_leaf_size() and provide the PMD entry to that function.
When __pte_leaf_size() is not defined, define it as a pte_leaf_size()
so that architectures not
From: Michael Ellerman
There are two possibilities for book3e_htw_mode, PPC_HTW_E6500 or
PPC_HTW_NONE.
The TLB miss handlers are patched to use, respectively:
- exc_[data|indstruction]_tlb_miss_e6500_book3e
- exc_[data|indstruction]_tlb_miss_bolted_book3e
Which means the default handlers
From: Michael Ellerman
The 64e TLB miss handler patching is done in setup_mmu_htw(), and then
again immediately afterward in early_init_mmu_global(). Consolidate it
into a single location.
Signed-off-by: Michael Ellerman
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/tlb_64e.c |
From: Michael Ellerman
All 64-bit Book3E have MMU_FTR_TYPE_FSL_E, since A2 was removed, so
remove checks for it in 64-bit only code.
Signed-off-by: Michael Ellerman
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/setup_64.c | 6 +-
arch/powerpc/mm/nohash/tlb_64e.c | 97
From: Michael Ellerman
All 64-bit Book3E have E500=y, so drop the unneeded ifdefs.
Signed-off-by: Michael Ellerman
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/tlb_64e.c | 12
1 file changed, 12 deletions(-)
diff --git a/arch/powerpc/mm/nohash/tlb_64e.c
From: Michael Ellerman
A reasonable chunk of nohash/tlb.c is 64-bit only code, split it out
into a separate file.
Signed-off-by: Michael Ellerman
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/Makefile | 2 +-
arch/powerpc/mm/nohash/tlb.c| 343
From: Michael Ellerman
The nohash HTW_IBM (Hardware Table Walk) code is unused since support
for A2 was removed in commit fb5a515704d7 ("powerpc: Remove platforms/
wsp and associated pieces") (2014).
The remaining supported CPUs use either no HTW (data_tlb_miss_bolted),
or the e6500 HTW
This series should have reached maturity for linux-next.
Also see https://github.com/linuxppc/issues/issues/483
Unlike most architectures, powerpc 8xx HW requires a two-level
pagetable topology for all page sizes. So a leaf PMD-contig approach
is not feasible as such.
Possible sizes on 8xx are
Le 13/06/2024 à 09:39, Oscar Salvador a écrit :
> On Mon, Jun 10, 2024 at 07:55:01AM +0200, Christophe Leroy wrote:
>> On book3s/64, the only user of hugepd is hash in 4k mode.
>>
>> All other setups (hash-64, radix-4, radix-64) use leaf PMD/PUD.
>>
>> Rework hash-4k to use contiguous PMD and
A SSD:
https://download.01.org/0day-ci/archive/20240624/202406241546.6bbd44a7-oliver.s...@intel.com/job.yaml
ssd_partitions:
"/dev/disk/by-id/ata-INTEL_SSDSC2BG012T4_BTHC428201ZX1P2OGN-part1"
Most likely btrfs does something different depending on the nonrot flag
being set or not. (And l
On Thu, Jun 20, 2024, at 18:23, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Using sys_io_pgetevents() as the entry point for compat mode tasks
> works almost correctly, but misses the sign extension for the min_nr
> and nr arguments.
>
> This was addressed on parisc by switching to
>
On Mon, Jun 24, 2024, at 08:14, John Paul Adrian Glaubitz wrote:
> On Fri, 2024-06-21 at 11:41 +0200, Arnd Bergmann wrote:
>> On Fri, Jun 21, 2024, at 10:44, John Paul Adrian Glaubitz wrote:
>> > Did you also check what order libc uses? I would expect libc on SuperH
>> > misordering the
>> >
PPC64 IOMMU API defines iommu_table_group_ops which handles DMA
windows for PEs, their ownership transfer, create/set/unset the TCE
tables for the Dynamic DMA wundows(DDW). VFIOS uses these APIs for
support on POWER.
The commit 9d67c9433509 ("powerpc/iommu: Add "borrowing"
iommu_table_group_ops")
Move function dev_has_iommu_table() to powerpc/kernel/iommu.c
as it is going to be used by machine specific iommu code as
well in subsequent patches.
Signed-off-by: Shivaprasad G Bhat
---
arch/powerpc/include/asm/iommu.h |6 ++
arch/powerpc/kernel/eeh.c| 16
The PAPR expects the TCE table to have no entries at the time of
unset window(i.e. remove-pe). The TCE clear right now is done
before freeing the iommu table. On pSeries, the unset window
makes those entries inaccessible to the OS and the H_PUT/GET calls
fail on them with H_CONSTRAINED.
On
This patch basically brings consistency with PowerNV approach
to use the first freely available iommu table when the default
window is removed.
The pSeries iommu code convention has been that the table[0] is
for the default 32 bit DMA window and the table[1] is for the
64 bit DDW.
With VFs
The ioctl VFIO_IOMMU_SPAPR_TCE_GET_INFO is not reporting the
actuals on the platform as not all the details are correctly
collected during the platform probe/scan into the iommu_table_group.
Collect the information during the device setup time as the DMA
window property is already looked up on
The PowerNV specific table_group_ops are defined in powernv/pci-ioda.c.
The pSeries specific table_group_ops are sitting in the generic powerpc
file. Move it to where it actually belong(pseries/iommu.c).
The functions are currently defined even for CONFIG_PPC_POWERNV
which are unused on PowerNV.
The patches reimplement the iommu table_group_ops for pSeries
for VFIO SPAPR TCE sub-driver thereby bringing consistency with
PowerNV implementation and getting rid of limitations/bugs which
were emanating from these differences on the earlier approach on
pSeries.
Structure of the patchset:
On Thu, Jun 20, 2024, at 18:23, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> arch/riscv/ appears to have accidentally enabled the compat time32
> syscalls in 64-bit kernels even though the native 32-bit ABI does
> not expose those.
>
> Address this by adding another level of indirection,
On Thu, 20 Jun 2024 10:41:50 +0800, Jinglin Wen wrote:
> According to the code logic, when the kernel is loaded to address 0,
> no copying operation should be performed, but it is currently being
> done.
>
> This patch fixes the issue where the kernel code was incorrectly
> duplicated to address
On Mon, 17 Jun 2024 19:32:40 +0530, Ganesh Goudar wrote:
> If a PCI device is removed during eeh_pe_report_edev(), edev->pdev
> will change and can cause a crash, hold the PCI rescan/remove lock
> while taking a copy of edev->pdev->bus.
>
>
Applied to powerpc/fixes.
[1/1] powerpc/eeh: avoid
On Fri, 14 Jun 2024 23:08:44 +0530, Anjali K wrote:
> Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
> results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
> shown below.
>
> kernel BUG at mm/usercopy.c:102!
> Oops: Exception in kernel mode,
From: Christophe Leroy
Only 44x uses 4xx now, so only keep one directory.
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/44x/Makefile | 6 -
arch/powerpc/platforms/{4xx => 44x}/cpm.c | 0
arch/powerpc/platforms/{4xx =>
From: Christophe Leroy
40x platforms have been orphaned for many years.
Remove them.
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
---
MAINTAINERS | 1 -
arch/powerpc/configs/40x/acadia_defconfig | 61
From: Christophe Leroy
Remove 40x platforms from the boot directory.
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
---
arch/powerpc/boot/4xx.c | 266 --
arch/powerpc/boot/4xx.h | 4 -
arch/powerpc/boot/Makefile | 11 -
Replace 4xx usage with 44x, and replace 4xx_SOC with 44x.
Also, as pointed out by Christophe, if 44x || BOOKE can be simplified to
just test BOOKE, because 44x always selects BOOKE.
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig | 5 +
Remove 40x from Kconfig, making the code unreachable.
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig | 12 ++--
arch/powerpc/Kconfig.debug | 13 -
arch/powerpc/Makefile | 5 -
arch/powerpc/configs/40x.config
Now that 40x is gone, replace CONFIG_BOOKE_OR_40x by CONFIG_BOOKE.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/hw_irq.h | 8
arch/powerpc/include/asm/irq.h | 2 +-
arch/powerpc/include/asm/kup.h | 2 +-
arch/powerpc/include/asm/processor.h | 2 +-
There is an issue with the hotplug operation when it's done on the
bridge/switch slot. The bridge-port and devices behind the bridge, which
become offline by hot-unplug operation, don't get hot-plugged/enabled by
doing hot-plug operation on that slot. Only the first port of the bridge
gets enabled
Description of the problem: The hotplug driver for powerpc
(pci/hotplug/pnv_php.c) gives kernel crash when we try to
hot-unplug/disable the PCIe switch/bridge from the PHB.
Root Cause of Crash: The crash is due to the reason that, though the msi
data structure has been released during
The fix of Powerpc hotplug driver (drivers/pci/hotplug/pnv_php.c)
addresses below two issues.
1. Kernel Crash during hot unplug of bridge/switch slot.
2. Bridge Support Enablement - Previously, when we do a hot-unplug
operation on a bridge slot, all the ports and devices behind the
bridge-ports
On Fri, Jun 21, 2024 at 12:24:03AM +0530, Naveen N Rao wrote:
> This is v3 of the patches posted here:
> http://lkml.kernel.org/r/cover.1718008093.git.nav...@kernel.org
>
> Since v2, I have addressed review comments from Steven and Masahiro
> along with a few fixes. Patches 7-11 are new in this
On 24/06/2024 11:18, Elinor Montmasson wrote:
>>>
>>> Previous `imx-spdif` driver used the dummy codec instead of
>>> using declared spdif codecs. It was discussed in previous version of this
>>> contribution
>>> that using the dummy codec isn't good practice. So one to one backward
>>>
From: "Krzysztof Kozlowski"
Sent: Monday, 24 June, 2024 10:55:31
> On 24/06/2024 10:51, Elinor Montmasson wrote:
>> From: "Krzysztof Kozlowski"
>> Sent: Sunday, 23 June, 2024 13:09:33
>>> On 20/06/2024 15:25, Elinor Montmasson wrote:
imx-audio-spdif was merged into the fsl-asoc-card driver,
On Mon, Jun 24, 2024 at 7:39 AM Vinod Koul wrote:
> Any reason why dmaengine parts cant be sent separately, why are they
> clubbed together, I dont see any obvious dependencies...
The I2S driver depends on the dmaengine parts
> On 20-06-24, 19:56, Piotr Wojtaszczyk wrote:
> > LPC32XX connects
On 24/06/2024 10:51, Elinor Montmasson wrote:
>
>> The compatible is already documented, so now you create duplicated binding.
>>
>> This is very confusing.
>
>
> The double compatible documentation is only temporary, next commit (7/9)
> removes the previous binding in
On 24/06/2024 10:51, Elinor Montmasson wrote:
> From: "Krzysztof Kozlowski"
> Sent: Sunday, 23 June, 2024 13:09:33
>> On 20/06/2024 15:25, Elinor Montmasson wrote:
>>> imx-audio-spdif was merged into the fsl-asoc-card driver, and therefore
>>> removed.
>>
>> So what happens with all existing
From: "Krzysztof Kozlowski"
Sent: Sunday, 23 June, 2024 13:10:48
> On 20/06/2024 15:25, Elinor Montmasson wrote:
>> Following merge of imx-spdif driver into fsl-asoc-card:
>> * update properties to match those used by fsl-asoc-card.
>> * S/PDIF in/out dummy codecs must now be declared explicitly,
From: "Krzysztof Kozlowski"
Sent: Sunday, 23 June, 2024 13:09:33
> On 20/06/2024 15:25, Elinor Montmasson wrote:
>> imx-audio-spdif was merged into the fsl-asoc-card driver, and therefore
>> removed.
>
> So what happens with all existing users (e.g. DTS)? They become
> invalid/not supported?
From: "Krzysztof Kozlowski"
Sent: Sunday, 23 June, 2024 13:07:46
> On 20/06/2024 15:25, Elinor Montmasson wrote:
>> The S/PDIF audio card support was merged from imx-spdif into the
>> fsl-asoc-card driver, making it possible to use an S/PDIF with an ASRC.
>> Add the new compatible and update
This is odd to say at least. Any chance you can check the value
of /sys/block/$DEVICE/queue/rotational for the relevant device before
and after this commit? And is this an ATA or NVMe SSD?
ble at:
https://download.01.org/0day-ci/archive/20240624/202406241546.6bbd44a7-oliver.s...@intel.com
=
compiler/cpufreq_governor/disk/filesize/fs2/fs/iterations/kconfig/nr_directories/nr_files_per_directory/nr_t
Hi Piotr,
piotr.wojtaszc...@timesys.com wrote on Fri, 21 Jun 2024 14:44:21 +0200:
> On Fri, Jun 21, 2024 at 10:30 AM Miquel Raynal
> wrote:
> >
> > Hi Piotr,
> >
> > piotr.wojtaszc...@timesys.com wrote on Thu, 20 Jun 2024 19:56:39 +0200:
> >
> > > Move away from pl08x platform data towards
Hi Arnd,
On Fri, 2024-06-21 at 11:41 +0200, Arnd Bergmann wrote:
> On Fri, Jun 21, 2024, at 10:44, John Paul Adrian Glaubitz wrote:
> > On Thu, 2024-06-20 at 18:23 +0200, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > The unusual function calling conventions on superh ended up
96 matches
Mail list logo
