Re: [PATCH v4 20/36] powerpc: Implement the new page table range API
On Wed, Mar 15, 2023 at 10:18:22AM +, Christophe Leroy wrote:
> I investigated a bit further and can confirm now that the above won't
> always work, see comment
> https://elixir.bootlin.com/linux/v6.3-rc2/source/arch/powerpc/include/asm/nohash/32/pgtable.h#L147
>
> And then you see
> https://elixir.bootlin.com/linux/v6.3-rc2/source/arch/powerpc/include/asm/nohash/pte-e500.h#L63
Got it. Here's what I intend to fold in for the next version:
diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
b/arch/powerpc/include/asm/book3s/32/pgtable.h
index 7bf1fe7297c6..5f12b9382909 100644
--- a/arch/powerpc/include/asm/book3s/32/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
@@ -462,11 +462,6 @@ static inline pte_t pfn_pte(unsigned long pfn, pgprot_t
pgprot)
pgprot_val(pgprot));
}
-static inline unsigned long pte_pfn(pte_t pte)
-{
- return pte_val(pte) >> PTE_RPN_SHIFT;
-}
-
/* Generic modifiers for PTE bits */
static inline pte_t pte_wrprotect(pte_t pte)
{
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 4acc9690f599..c5baa3082a5a 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -104,6 +104,7 @@
* and every thing below PAGE_SHIFT;
*/
#define PTE_RPN_MASK (((1UL << _PAGE_PA_MAX) - 1) & (PAGE_MASK))
+#define PTE_RPN_SHIFT PAGE_SHIFT
/*
* set of bits not changed in pmd_modify. Even though we have hash specific
bits
* in here, on radix we expect them to be zero.
@@ -569,11 +570,6 @@ static inline pte_t pfn_pte(unsigned long pfn, pgprot_t
pgprot)
return __pte(((pte_basic_t)pfn << PAGE_SHIFT) | pgprot_val(pgprot) |
_PAGE_PTE);
}
-static inline unsigned long pte_pfn(pte_t pte)
-{
- return (pte_val(pte) & PTE_RPN_MASK) >> PAGE_SHIFT;
-}
-
/* Generic modifiers for PTE bits */
static inline pte_t pte_wrprotect(pte_t pte)
{
diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
b/arch/powerpc/include/asm/nohash/pgtable.h
index 69a7dd47a9f0..03be8b22aaea 100644
--- a/arch/powerpc/include/asm/nohash/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/pgtable.h
@@ -101,8 +101,6 @@ static inline bool pte_access_permitted(pte_t pte, bool
write)
static inline pte_t pfn_pte(unsigned long pfn, pgprot_t pgprot) {
return __pte(((pte_basic_t)(pfn) << PTE_RPN_SHIFT) |
pgprot_val(pgprot)); }
-static inline unsigned long pte_pfn(pte_t pte) {
- return pte_val(pte) >> PTE_RPN_SHIFT; }
/* Generic modifiers for PTE bits */
static inline pte_t pte_exprotect(pte_t pte)
@@ -279,7 +277,7 @@ static inline int pud_huge(pud_t pud)
void update_mmu_cache_range(struct vm_area_struct *vma, unsigned long address,
pte_t *ptep, unsigned int nr);
#else
-static inline void update_mmu_cache(struct vm_area_struct *vma,
+static inline void update_mmu_cache_range(struct vm_area_struct *vma,
unsigned long address, pte_t *ptep, unsigned int nr) {}
#endif
diff --git a/arch/powerpc/include/asm/pgtable.h
b/arch/powerpc/include/asm/pgtable.h
index 656ecf2b10cd..491a2720f835 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -54,6 +54,12 @@ void set_ptes(struct mm_struct *mm, unsigned long addr,
pte_t *ptep,
/* Keep these as a macros to avoid include dependency mess */
#define pte_page(x)pfn_to_page(pte_pfn(x))
#define mk_pte(page, pgprot) pfn_pte(page_to_pfn(page), (pgprot))
+
+static inline unsigned long pte_pfn(pte_t pte)
+{
+ return (pte_val(pte) & PTE_RPN_MASK) >> PTE_RPN_SHIFT;
+}
+
/*
* Select all bits except the pfn
*/
diff --git a/arch/powerpc/mm/nohash/e500_hugetlbpage.c
b/arch/powerpc/mm/nohash/e500_hugetlbpage.c
index f3cb91107a47..583b3098763f 100644
--- a/arch/powerpc/mm/nohash/e500_hugetlbpage.c
+++ b/arch/powerpc/mm/nohash/e500_hugetlbpage.c
@@ -178,7 +178,7 @@ book3e_hugetlb_preload(struct vm_area_struct *vma, unsigned
long ea, pte_t pte)
*
* This must always be called with the pte lock held.
*/
-void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
+void update_mmu_cache_range(struct vm_area_struct *vma, unsigned long address,
pte_t *ptep, unsigned int nr)
{
if (is_vm_hugetlb_page(vma))
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index b3c7b874a7a2..db236b494845 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -208,7 +208,7 @@ void set_ptes(struct mm_struct *mm, unsigned long addr,
pte_t *ptep,
if (--nr == 0)
break;
ptep++;
- pte = __pte(pte_val(pte) + PAGE_SIZE);
+ pte = __pte(pte_val(pte) + (1UL << PTE_RPN_SHIFT));
addr += PAGE_SIZE;
}
}
[GIT PULL] Please pull powerpc/linux.git powerpc-6.3-3 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 6.3: The following changes since commit eeac8ede17557680855031c6f305ece2378af326: Linux 6.3-rc2 (2023-03-12 16:36:44 -0700) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.3-3 for you to fetch changes up to f2c7e3562b4c4f1699acc1538ebf3e75f5cced35: powerpc/mm: Fix false detection of read faults (2023-03-15 20:48:53 +1100) - -- powerpc fixes for 6.3 #3 - Fix false detection of read faults, introduced by execute-only support. - Fix a build failure when GENERIC_ALLOCATOR is not selected. Thanks to: Russell Currey, Randy Dunlap, Michal Suchánek, Nathan Lynch, Benjamin Gray. - -- Randy Dunlap (1): powerpc/pseries: RTAS work area requires GENERIC_ALLOCATOR Russell Currey (1): powerpc/mm: Fix false detection of read faults arch/powerpc/mm/fault.c| 11 --- arch/powerpc/platforms/pseries/Kconfig | 1 + 2 files changed, 9 insertions(+), 3 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmQT3ToACgkQUevqPMjh pYApfA/5AdTCYQx6dLZOvYbLWLnfq9V1W1EREx8QzLNyKfgJ8gTdDr8ogBZLvg42 KDpxWjzY2eLNC3Ip9rXjUDu8n06YcpqTzPK/kvJR7RfWtOnMzsY9FqRALrQdz+BO nr/rSxMVJN4we1Rc2iaVuSXhGV65kWJ2X0j9kVx5LrG4LOWSWMr1Y61J9GJi/Emv 44eiIfcfHNILxHpm7QBYGNBhQpRyOzh8feNTnKxxHr+qQS3GQ0+QdGk21MwCtVHM A2cPmpSW5cvGGsDOxjyNn5B4Mrkgbp9vW182XqqxMCC0KZf2PSksQVp3LTTua2GP HPX9peeiiTO1ct2/HeL+EiLrshAghmE9J7DFhuhXZpdDQY68iej/sUQhMfrmj+/W UTA2qHi63Yv7VcflT7mtFUoqdFH33fuyzkFB1+R9FBzR7nYHpDs8osKbIkXNX4Fr O9eiv/A1cbwN2tr6bnXUoILPMU0rc6EZgQqq8qaGrvxDDdVPcgsmDaHxLaV/OWGS Uh4KB79WmYr3MIqXF7Ehb7Svh8G+8oTJ7OAaO6ev8f7izBzjf1RY8o1LF8hn1AJd jpkclCwVulP/t9rb9BpX7iUBref4JwWBE3LDASM02WPJR9ykW3QPlbWmyPVjXvCS 0rex8gU8ki2lWUvoeq29DDasRbTIEjkOYLnWp6A0yd00HA/sNm4= =AMyS -END PGP SIGNATURE-
[powerpc:next-test] BUILD SUCCESS e760955c9f285eb8fec0d83ae001fae7714e5121
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test branch HEAD: e760955c9f285eb8fec0d83ae001fae7714e5121 powerpc: Remove memcpy_page_flushcache() elapsed time: 732m configs tested: 82 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-r026-20230315 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-r004-20230313 clang arm randconfig-r021-20230315 gcc arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r005-20230312 clang cskydefconfig gcc hexagon randconfig-r001-20230313 clang i386 allyesconfig gcc i386 debian-10.3-func gcc i386 debian-10.3-kselftests gcc i386debian-10.3-kunit gcc i386 debian-10.3-kvm gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-a001-20230313 gcc i386 randconfig-a002-20230313 gcc i386 randconfig-a003-20230313 gcc i386 randconfig-a004-20230313 gcc i386 randconfig-a005-20230313 gcc i386 randconfig-a006-20230313 gcc i386 randconfig-a011-20230313 clang i386 randconfig-a012-20230313 clang i386 randconfig-a013-20230313 clang i386 randconfig-a014-20230313 clang i386 randconfig-a015-20230313 clang i386 randconfig-a016-20230313 clang i386 randconfig-c001 gcc ia64 allmodconfig gcc ia64defconfig gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68kdefconfig gcc m68k randconfig-r023-20230315 gcc mips allmodconfig gcc mips allyesconfig gcc nios2 defconfig gcc openrisc randconfig-r022-20230315 gcc parisc defconfig gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc riscvallmodconfig gcc riscv allnoconfig gcc riscv defconfig gcc riscvrandconfig-r002-20230312 clang riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc s390defconfig gcc sh allmodconfig gcc sparc defconfig gcc sparcrandconfig-r025-20230315 gcc um i386_defconfig gcc um x86_64_defconfig gcc x86_64allnoconfig gcc x86_64 allyesconfig gcc x86_64 defconfig gcc x86_64 kexec gcc x86_64 randconfig-a001-20230313 gcc x86_64 randconfig-a002-20230313 gcc x86_64 randconfig-a003-20230313 gcc x86_64 randconfig-a004-20230313 gcc x86_64 randconfig-a005-20230313 gcc x86_64 randconfig-a006-20230313 gcc x86_64 randconfig-a011-20230313 clang x86_64 randconfig-a012-20230313 clang x86_64 randconfig-a013-20230313 clang x86_64 randconfig-a014-20230313 clang x86_64 randconfig-a015-20230313 clang x86_64 randconfig-a016-20230313 clang x86_64randconfig-k001 clang x86_64 rhel-8.3 gcc -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
[powerpc:next] BUILD SUCCESS 3c1d9f36e985af84b9ba31b850d683c81ae96e8d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: 3c1d9f36e985af84b9ba31b850d683c81ae96e8d powerpc: Simplify sysctl registration for nmi_wd_lpm_factor_ctl_table elapsed time: 732m configs tested: 82 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-r026-20230315 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-r004-20230313 clang arm randconfig-r021-20230315 gcc arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r005-20230312 clang cskydefconfig gcc hexagon randconfig-r001-20230313 clang i386 allyesconfig gcc i386 debian-10.3-func gcc i386 debian-10.3-kselftests gcc i386debian-10.3-kunit gcc i386 debian-10.3-kvm gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-a001-20230313 gcc i386 randconfig-a002-20230313 gcc i386 randconfig-a003-20230313 gcc i386 randconfig-a004-20230313 gcc i386 randconfig-a005-20230313 gcc i386 randconfig-a006-20230313 gcc i386 randconfig-a011-20230313 clang i386 randconfig-a012-20230313 clang i386 randconfig-a013-20230313 clang i386 randconfig-a014-20230313 clang i386 randconfig-a015-20230313 clang i386 randconfig-a016-20230313 clang i386 randconfig-c001 gcc ia64 allmodconfig gcc ia64defconfig gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68kdefconfig gcc m68k randconfig-r023-20230315 gcc mips allmodconfig gcc mips allyesconfig gcc nios2 defconfig gcc openrisc randconfig-r022-20230315 gcc parisc defconfig gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc riscvallmodconfig gcc riscv allnoconfig gcc riscv defconfig gcc riscvrandconfig-r002-20230312 clang riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc s390defconfig gcc sh allmodconfig gcc sparc defconfig gcc sparcrandconfig-r025-20230315 gcc um i386_defconfig gcc um x86_64_defconfig gcc x86_64allnoconfig gcc x86_64 allyesconfig gcc x86_64 defconfig gcc x86_64 kexec gcc x86_64 randconfig-a001-20230313 gcc x86_64 randconfig-a002-20230313 gcc x86_64 randconfig-a003-20230313 gcc x86_64 randconfig-a004-20230313 gcc x86_64 randconfig-a005-20230313 gcc x86_64 randconfig-a006-20230313 gcc x86_64 randconfig-a011-20230313 clang x86_64 randconfig-a012-20230313 clang x86_64 randconfig-a013-20230313 clang x86_64 randconfig-a014-20230313 clang x86_64 randconfig-a015-20230313 clang x86_64 randconfig-a016-20230313 clang x86_64randconfig-k001 clang x86_64 rhel-8.3 gcc -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
Re: [PATCH v2] net: Use of_property_read_bool() for boolean properties
On Tue, 14 Mar 2023 14:18:27 -0500 Rob Herring wrote: > It is preferred to use typed property access functions (i.e. > of_property_read_ functions) rather than low-level > of_get_property/of_find_property functions for reading properties. > Convert reading boolean properties to of_property_read_bool(). > > Reviewed-by: Simon Horman > Acked-by: Marc Kleine-Budde # for net/can > Acked-by: Kalle Valo > Acked-by: Nicolas Ferre > Acked-by: Francois Romieu > Reviewed-by: Wei Fang > Signed-off-by: Rob Herring Applied, to net(?), thanks!
Re: [PATCH 0/3] COVER: Remove memcpy_page_flushcache()
Ira Weiny writes:
> + Konstantin
>
> Michael Ellerman wrote:
>> Ira Weiny writes:
>> > Dave Hansen wrote:
>> >> On 3/15/23 16:20, Ira Weiny wrote:
>> >> > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
>> >> > callbacks") removed the calls to memcpy_page_flushcache().
>> >> >
>> >> > kmap_atomic() is deprecated and used in the x86 version of
>> >> > memcpy_page_flushcache().
>> >> >
>> >> > Remove the unnecessary memcpy_page_flushcache() call from all arch's.
>> >>
>> >> Hi Ira,
>> >>
>> >> Since the common code user is already gone these three patches seem
>> >> quite independent. It seems like the right thing to do is have
>> >> individual arch maintainers cherry pick their arch patch and carry it
>> >> independently.
>> >
>> > Yes.
>> >
>> >>
>> >> Is there a compelling reason to have someone pick up and carry these all
>> >> together that I'm missing?
>> >
>> > No reason. Would you like me to submit them individually?
>>
>> I'll just grab the powerpc one from the thread, no need to resend.
>
> Thanks.
>
>>
>> > Sorry, submitting them separately crossed my mind when I wrote them but I
>> > kind of forgot as they were all on the same branch and I was waiting for
>> > after the merge window to submit them.
>>
>> It's also much easier to run git-send-email HEAD^^^, rather than running
>> it three separate times, let alone if it's a 20 patch series.
>
> Exactly. And I'm using b4 which would have forced me to create a separate
> branch for each of the patches to track. So I was keeping them around in
> a single branch to let 0day run after the merge window. Then I forgot
> about the idea of splitting them because b4 had it all packaged up nice!
>
>>
>> I wonder if we could come up with some convention to indicate that a
>> series is made up of independent patches, and maintainers are free to
>> pick them individually - but still sent as a single series.
>
> Maybe. But perhaps b4 could have a send option which would split them
> out? I'll see about adding an option to b4 but I've Cc'ed Konstantin as
> well for the idea.
Yes you're right that's probably a better idea. b4 to the rescue!
cheers
Re: [PATCH 000/173] ALSA/ASoC: Convert to platform remove callback returning void
On Wed, 15 Mar 2023 16:04:52 +0100, Uwe Kleine-König wrote: > > Hello, > > this series adapts the platform drivers below sound/ to use the .remove_new() > callback. Compared to the traditional .remove() callback .remove_new() returns > no value. This is a good thing because the driver core doesn't (and cannot) > cope for errors during remove. The only effect of a non-zero return value in > .remove() is that the driver core emits a warning. The device is removed > anyhow > and an early return from .remove() usually yields a resource leak. > > By changing the remove callback to return void driver authors cannot > reasonably assume any more that there is some kind of cleanup later. > > The first two patches simplify a driver each to return zero unconditionally, > and then all drivers are trivially converted to .remove_new(). > > There are nearly no interdependencies in this patch set---only 1 <- 11 and > 2 <- 16. So even if some individual problems are found (I don't expect that), > the other patches can (and from my POV should) still be applied. > > Best regards > Uwe > > Uwe Kleine-König (173): (snip) For the whole series, Acked-by: Takashi Iwai thanks, Takashi
[PATCH 4/4] powerpc/4xx: Delete unnecessary variable initialisations in four functions
Date: Thu, 16 Mar 2023 19:56:21 +0100
Some local variables will be set to an appropriate value before usage.
Thus omit explicit initialisations at the beginning of these functions.
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/4xx/pci.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/4xx/pci.c b/arch/powerpc/platforms/4xx/pci.c
index 0c0848f0c819..ebc030e12663 100644
--- a/arch/powerpc/platforms/4xx/pci.c
+++ b/arch/powerpc/platforms/4xx/pci.c
@@ -323,8 +323,8 @@ static void __init ppc4xx_probe_pci_bridge(struct
device_node *np)
struct resource rsrc_cfg;
struct resource rsrc_reg;
struct resource dma_window;
- struct pci_controller *hose = NULL;
- void __iomem *reg = NULL;
+ struct pci_controller *hose;
+ void __iomem *reg;
const int *bus_range;
int primary = 0;
@@ -523,8 +523,8 @@ static void __init ppc4xx_probe_pcix_bridge(struct
device_node *np)
struct resource rsrc_cfg;
struct resource rsrc_reg;
struct resource dma_window;
- struct pci_controller *hose = NULL;
- void __iomem *reg = NULL;
+ struct pci_controller *hose;
+ void __iomem *reg;
const int *bus_range;
int big_pim = 0, msi = 0, primary = 0;
@@ -1403,7 +1403,7 @@ static struct ppc4xx_pciex_hwops ppc_476fpe_pcie_hwops
__initdata =
static int __init ppc4xx_pciex_check_core_init(struct device_node *np)
{
static int core_init;
- int count = -ENODEV;
+ int count;
if (core_init++)
return 0;
@@ -1905,10 +1905,10 @@ static void __init ppc4xx_configure_pciex_PIMs(struct
ppc4xx_pciex_port *port,
static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
{
struct resource dma_window;
- struct pci_controller *hose = NULL;
+ struct pci_controller *hose;
const int *bus_range;
int primary = 0, busses;
- void __iomem *mbase = NULL, *cfg_data = NULL;
+ void __iomem *mbase, *cfg_data = NULL;
const u32 *pval;
u32 val;
--
2.39.2
[PATCH 3/4] powerpc/4xx: Fix exception handling in ppc4xx_probe_pci_bridge()
Date: Thu, 16 Mar 2023 19:12:10 +0100
The label “fail” was used to jump to another pointer check despite of
the detail in the implementation of the function “ppc4xx_probe_pci_bridge”
that it was determined already that the corresponding variable contained
a null pointer (because of a failed function call in two cases).
1. Thus return directly after a call of the function “ioremap” failed.
2. Use a more appropriate label instead.
3. Delete two questionable checks.
4. Adjust the exception handling for another if branch a bit more.
5. Remove a return statement at the end.
This issue was detected by using the Coccinelle software.
Fixes: c839e0eff500af03de65e560c2e21c3831586e6e ("[POWERPC] 4xx: PLB to PCI 2.x
support")
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/4xx/pci.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/4xx/pci.c b/arch/powerpc/platforms/4xx/pci.c
index fdf13e12ca9d..0c0848f0c819 100644
--- a/arch/powerpc/platforms/4xx/pci.c
+++ b/arch/powerpc/platforms/4xx/pci.c
@@ -358,13 +358,13 @@ static void __init ppc4xx_probe_pci_bridge(struct
device_node *np)
reg = ioremap(rsrc_reg.start, resource_size(_reg));
if (reg == NULL) {
printk(KERN_ERR "%pOF: Can't map registers !", np);
- goto fail;
+ return;
}
/* Allocate the host controller data structure */
hose = pcibios_alloc_controller(np);
if (!hose)
- goto fail;
+ goto unmap_io;
hose->first_busno = bus_range ? bus_range[0] : 0x0;
hose->last_busno = bus_range ? bus_range[1] : 0xff;
@@ -383,8 +383,10 @@ static void __init ppc4xx_probe_pci_bridge(struct
device_node *np)
pci_process_bridge_OF_ranges(hose, np, primary);
/* Parse inbound mapping resources */
- if (ppc4xx_parse_dma_ranges(hose, reg, _window) != 0)
- goto fail;
+ if (ppc4xx_parse_dma_ranges(hose, reg, _window) {
+ pcibios_free_controller(hose);
+ goto unmap_io;
+ }
/* Configure outbound ranges POMs */
ppc4xx_configure_pci_PMMs(hose, reg);
@@ -393,14 +395,8 @@ static void __init ppc4xx_probe_pci_bridge(struct
device_node *np)
ppc4xx_configure_pci_PTMs(hose, reg, _window);
/* We don't need the registers anymore */
+unmap_io:
iounmap(reg);
- return;
-
- fail:
- if (hose)
- pcibios_free_controller(hose);
- if (reg)
- iounmap(reg);
}
/*
--
2.39.2
[PATCH 2/4] powerpc/4xx: Fix exception handling in ppc4xx_probe_pcix_bridge()
Date: Thu, 16 Mar 2023 19:09:33 +0100
The label “fail” was used to jump to another pointer check despite of
the detail in the implementation of the function “ppc4xx_probe_pcix_bridge”
that it was determined already that the corresponding variable contained
a null pointer (because of a failed function call in two cases).
1. Thus return directly after a call of the function “ioremap” failed.
2. Use a more appropriate label instead.
3. Delete two questionable checks.
4. Adjust the exception handling for another if branch a bit more.
5. Remove a return statement at the end.
This issue was detected by using the Coccinelle software.
Fixes: 5738ec6d00b7abbcd4cd342af83fd18d192b0979 ("[POWERPC] 4xx: PLB to PCI-X
support")
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/4xx/pci.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/4xx/pci.c b/arch/powerpc/platforms/4xx/pci.c
index 7336c7039b10..fdf13e12ca9d 100644
--- a/arch/powerpc/platforms/4xx/pci.c
+++ b/arch/powerpc/platforms/4xx/pci.c
@@ -564,13 +564,13 @@ static void __init ppc4xx_probe_pcix_bridge(struct
device_node *np)
reg = ioremap(rsrc_reg.start, resource_size(_reg));
if (reg == NULL) {
printk(KERN_ERR "%pOF: Can't map registers !", np);
- goto fail;
+ return;
}
/* Allocate the host controller data structure */
hose = pcibios_alloc_controller(np);
if (!hose)
- goto fail;
+ goto unmap_io;
hose->first_busno = bus_range ? bus_range[0] : 0x0;
hose->last_busno = bus_range ? bus_range[1] : 0xff;
@@ -595,8 +595,10 @@ static void __init ppc4xx_probe_pcix_bridge(struct
device_node *np)
pci_process_bridge_OF_ranges(hose, np, primary);
/* Parse inbound mapping resources */
- if (ppc4xx_parse_dma_ranges(hose, reg, _window) != 0)
- goto fail;
+ if (ppc4xx_parse_dma_ranges(hose, reg, _window)) {
+ pcibios_free_controller(hose);
+ goto unmap_io;
+ }
/* Configure outbound ranges POMs */
ppc4xx_configure_pcix_POMs(hose, reg);
@@ -605,14 +607,8 @@ static void __init ppc4xx_probe_pcix_bridge(struct
device_node *np)
ppc4xx_configure_pcix_PIMs(hose, reg, _window, big_pim, msi);
/* We don't need the registers anymore */
+unmap_io:
iounmap(reg);
- return;
-
- fail:
- if (hose)
- pcibios_free_controller(hose);
- if (reg)
- iounmap(reg);
}
#ifdef CONFIG_PPC4xx_PCI_EXPRESS
--
2.39.2
[PATCH 0/4] powerpc/4xx: Adjustments for four function implementations
Date: Thu, 16 Mar 2023 20:15:43 +0100 Some update suggestions were taken into account from static source code analysis. Markus Elfring (4): Fix exception handling in ppc4xx_pciex_port_setup_hose() Fix exception handling in ppc4xx_probe_pcix_bridge() Fix exception handling in ppc4xx_probe_pci_bridge() Delete unnecessary variable initialisations in four functions arch/powerpc/platforms/4xx/pci.c | 69 ++-- 1 file changed, 31 insertions(+), 38 deletions(-) -- 2.39.2
[PATCH 1/4] powerpc/4xx: Fix exception handling in ppc4xx_pciex_port_setup_hose()
Date: Thu, 16 Mar 2023 19:00:57 +0100
The label “fail” was used to jump to another pointer check despite of
the detail in the implementation of the function “ppc4xx_pciex_port_setup_hose”
that it was determined already that the corresponding variable contained
a null pointer (because of a failed function call in three cases).
1. Thus return directly after a call of the function “pcibios_alloc_controller”
failed.
2. Use more appropriate labels instead.
3. Reorder jump targets at the end.
4. Delete two questionable checks.
This issue was detected by using the Coccinelle software.
Fixes: a2d2e1ec07a80946cbe812dc8c73291cad8214b2 ("[POWERPC] 4xx: PLB to PCI
Express support")
Fixes: 80daac3f86d4f5aafc9d3e79addb90fa118244e2 ("[POWERPC] 4xx: Add endpoint
support to 4xx PCIe driver")
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/4xx/pci.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/4xx/pci.c b/arch/powerpc/platforms/4xx/pci.c
index ca5dd7a5842a..7336c7039b10 100644
--- a/arch/powerpc/platforms/4xx/pci.c
+++ b/arch/powerpc/platforms/4xx/pci.c
@@ -1930,7 +1930,7 @@ static void __init ppc4xx_pciex_port_setup_hose(struct
ppc4xx_pciex_port *port)
/* Allocate the host controller data structure */
hose = pcibios_alloc_controller(port->node);
if (!hose)
- goto fail;
+ return;
/* We stick the port number in "indirect_type" so the config space
* ops can retrieve the port data structure easily
@@ -1962,7 +1962,7 @@ static void __init ppc4xx_pciex_port_setup_hose(struct
ppc4xx_pciex_port *port)
if (cfg_data == NULL) {
printk(KERN_ERR "%pOF: Can't map external config space !",
port->node);
- goto fail;
+ goto free_controller;
}
hose->cfg_data = cfg_data;
}
@@ -1974,7 +1974,7 @@ static void __init ppc4xx_pciex_port_setup_hose(struct
ppc4xx_pciex_port *port)
if (mbase == NULL) {
printk(KERN_ERR "%pOF: Can't map internal config space !",
port->node);
- goto fail;
+ goto recheck_cfg_data;
}
hose->cfg_addr = mbase;
@@ -2007,7 +2007,7 @@ static void __init ppc4xx_pciex_port_setup_hose(struct
ppc4xx_pciex_port *port)
/* Parse inbound mapping resources */
if (ppc4xx_parse_dma_ranges(hose, mbase, _window) != 0)
- goto fail;
+ goto unmap_io_mbase;
/* Configure outbound ranges POMs */
ppc4xx_configure_pciex_POMs(port, hose, mbase);
@@ -2064,13 +2064,14 @@ static void __init ppc4xx_pciex_port_setup_hose(struct
ppc4xx_pciex_port *port)
}
return;
- fail:
- if (hose)
- pcibios_free_controller(hose);
+
+unmap_io_mbase:
+ iounmap(mbase);
+recheck_cfg_data:
if (cfg_data)
iounmap(cfg_data);
- if (mbase)
- iounmap(mbase);
+free_controller:
+ pcibios_free_controller(hose);
}
static void __init ppc4xx_probe_pciex_bridge(struct device_node *np)
--
2.39.2
Re: [PATCH v5 1/4] PCI: Introduce pci_dev_for_each_resource()
Hi Andy,
I love your patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on pci/for-linus powerpc/next powerpc/fixes linus/master
v6.3-rc2 next-20230316]
[cannot apply to soc/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Andy-Shevchenko/PCI-Introduce-pci_dev_for_each_resource/20230315-032821
base: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link:
https://lore.kernel.org/r/20230314192634.63531-2-andriy.shevchenko%40linux.intel.com
patch subject: [PATCH v5 1/4] PCI: Introduce pci_dev_for_each_resource()
config: powerpc-randconfig-r032-20230312
(https://download.01.org/0day-ci/archive/20230317/202303170223.v0xqhs1v-...@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project
67409911353323ca5edf2049ef0df54132fa1ca7)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
#
https://github.com/intel-lab-lkp/linux/commit/85cdf4746b716f7b6c14d7dc5cd907c3c2a1fb0c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Andy-Shevchenko/PCI-Introduce-pci_dev_for_each_resource/20230315-032821
git checkout 85cdf4746b716f7b6c14d7dc5cd907c3c2a1fb0c
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=powerpc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=powerpc SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202303170223.v0xqhs1v-...@intel.com/
All errors (new ones prefixed by >>):
>> arch/powerpc/platforms/52xx/mpc52xx_pci.c:331:6: error: unused variable 'i'
>> [-Werror,-Wunused-variable]
int i;
^
1 error generated.
vim +/i +331 arch/powerpc/platforms/52xx/mpc52xx_pci.c
f42963f8646540 Grant Likely2006-12-12 326
f42963f8646540 Grant Likely2006-12-12 327 static void
f42963f8646540 Grant Likely2006-12-12 328
mpc52xx_pci_fixup_resources(struct pci_dev *dev)
f42963f8646540 Grant Likely2006-12-12 329 {
85cdf4746b716f Mika Westerberg 2023-03-14 330 struct resource *res;
f42963f8646540 Grant Likely2006-12-12 @331 int i;
f42963f8646540 Grant Likely2006-12-12 332
59510820fff76f Randy Dunlap2021-04-28 333 pr_debug("%s()
%.4x:%.4x\n", __func__, dev->vendor, dev->device);
f42963f8646540 Grant Likely2006-12-12 334
f42963f8646540 Grant Likely2006-12-12 335 /* We don't rely on
boot loader for PCI and resets all
f42963f8646540 Grant Likely2006-12-12 336 devices */
85cdf4746b716f Mika Westerberg 2023-03-14 337
pci_dev_for_each_resource_p(dev, res) {
f42963f8646540 Grant Likely2006-12-12 338 if (res->end >
res->start) {/* Only valid resources */
f42963f8646540 Grant Likely2006-12-12 339
res->end -= res->start;
f42963f8646540 Grant Likely2006-12-12 340
res->start = 0;
f42963f8646540 Grant Likely2006-12-12 341
res->flags |= IORESOURCE_UNSET;
f42963f8646540 Grant Likely2006-12-12 342 }
f42963f8646540 Grant Likely2006-12-12 343 }
f42963f8646540 Grant Likely2006-12-12 344
f42963f8646540 Grant Likely2006-12-12 345 /* The PCI Host bridge
of MPC52xx has a prefetch memory resource
f42963f8646540 Grant Likely2006-12-12 346 fixed to 1Gb.
Doesn't fit in the resource system so we remove it */
f42963f8646540 Grant Likely2006-12-12 347 if ( (dev->vendor ==
PCI_VENDOR_ID_MOTOROLA) &&
f42963f8646540 Grant Likely2006-12-12 348 ( dev->device ==
PCI_DEVICE_ID_MOTOROLA_MPC5200
f42963f8646540 Grant Likely2006-12-12 349|| dev->device ==
PCI_DEVICE_ID_MOTOROLA_MPC5200B) ) {
f42963f8646540 Grant Likely2006-12-12 350 struct resource
*res = >resource[1];
f42963f8646540 Grant Likely2006-12-12 351 res->start =
res->end = res->flags = 0;
f42963f8646540 Grant Likely2006-12-12 352 }
f42963f8646540 Grant Likely2006-12-12 353 }
f42963f8646540 Grant Likely2006-12-12 354
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH v2] net: Use of_property_read_bool() for boolean properties
Hello: This patch was applied to netdev/net.git (main) by David S. Miller : On Tue, 14 Mar 2023 14:18:27 -0500 you wrote: > It is preferred to use typed property access functions (i.e. > of_property_read_ functions) rather than low-level > of_get_property/of_find_property functions for reading properties. > Convert reading boolean properties to of_property_read_bool(). > > Reviewed-by: Simon Horman > Acked-by: Marc Kleine-Budde # for net/can > Acked-by: Kalle Valo > Acked-by: Nicolas Ferre > Acked-by: Francois Romieu > Reviewed-by: Wei Fang > Signed-off-by: Rob Herring > > [...] Here is the summary with links: - [v2] net: Use of_property_read_bool() for boolean properties https://git.kernel.org/netdev/net/c/1a87e641d8a5 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH 0/3] COVER: Remove memcpy_page_flushcache()
+ Konstantin
Michael Ellerman wrote:
> Ira Weiny writes:
> > Dave Hansen wrote:
> >> On 3/15/23 16:20, Ira Weiny wrote:
> >> > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
> >> > callbacks") removed the calls to memcpy_page_flushcache().
> >> >
> >> > kmap_atomic() is deprecated and used in the x86 version of
> >> > memcpy_page_flushcache().
> >> >
> >> > Remove the unnecessary memcpy_page_flushcache() call from all arch's.
> >>
> >> Hi Ira,
> >>
> >> Since the common code user is already gone these three patches seem
> >> quite independent. It seems like the right thing to do is have
> >> individual arch maintainers cherry pick their arch patch and carry it
> >> independently.
> >
> > Yes.
> >
> >>
> >> Is there a compelling reason to have someone pick up and carry these all
> >> together that I'm missing?
> >
> > No reason. Would you like me to submit them individually?
>
> I'll just grab the powerpc one from the thread, no need to resend.
Thanks.
>
> > Sorry, submitting them separately crossed my mind when I wrote them but I
> > kind of forgot as they were all on the same branch and I was waiting for
> > after the merge window to submit them.
>
> It's also much easier to run git-send-email HEAD^^^, rather than running
> it three separate times, let alone if it's a 20 patch series.
Exactly. And I'm using b4 which would have forced me to create a separate
branch for each of the patches to track. So I was keeping them around in
a single branch to let 0day run after the merge window. Then I forgot
about the idea of splitting them because b4 had it all packaged up nice!
>
> I wonder if we could come up with some convention to indicate that a
> series is made up of independent patches, and maintainers are free to
> pick them individually - but still sent as a single series.
Maybe. But perhaps b4 could have a send option which would split them
out? I'll see about adding an option to b4 but I've Cc'ed Konstantin as
well for the idea.
Thanks for picking this up!
Ira
>
> cheers
[PATCH 2/2] ASoC: fsl: Specify driver name in ASoC card
Set the snd_soc_card driver name which fixes the warning:
fsl-asoc-card sound: ASoC: driver name too long 'imx-audio-tlv320aic32x4'
-> 'imx-audio-tlv32'
Signed-off-by: Alexander Stein
---
These patches could be squashed, but I opted for separation this patch
is the actual functional change. Patch 1 is just preparation.
sound/soc/fsl/fsl-asoc-card.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index e956abfd50f8..bffa1048d31e 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -609,6 +609,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
priv->card.dapm_routes = audio_map;
priv->card.num_dapm_routes = ARRAY_SIZE(audio_map);
+ priv->card.driver_name = DRIVER_NAME;
/* Diversify the card configurations */
if (of_device_is_compatible(np, "fsl,imx-audio-cs42888")) {
codec_dai_name = "cs42888";
--
2.34.1
[PATCH 1/2] ASoC: fsl: define a common DRIVER_NAME
Instead of copying the driver name manually, use a common define.
No functional change.
Signed-off-by: Alexander Stein
---
sound/soc/fsl/fsl-asoc-card.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index cdfca9fd1eb0..e956abfd50f8 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -28,6 +28,8 @@
#include "../codecs/wm8994.h"
#include "../codecs/tlv320aic31xx.h"
+#define DRIVER_NAME "fsl-asoc-card"
+
#define CS427x_SYSCLK_MCLK 0
#define RX 0
@@ -915,7 +917,7 @@ MODULE_DEVICE_TABLE(of, fsl_asoc_card_dt_ids);
static struct platform_driver fsl_asoc_card_driver = {
.probe = fsl_asoc_card_probe,
.driver = {
- .name = "fsl-asoc-card",
+ .name = DRIVER_NAME,
.pm = _soc_pm_ops,
.of_match_table = fsl_asoc_card_dt_ids,
},
@@ -924,5 +926,5 @@ module_platform_driver(fsl_asoc_card_driver);
MODULE_DESCRIPTION("Freescale Generic ASoC Sound Card driver with ASRC");
MODULE_AUTHOR("Nicolin Chen ");
-MODULE_ALIAS("platform:fsl-asoc-card");
+MODULE_ALIAS("platform:" DRIVER_NAME);
MODULE_LICENSE("GPL");
--
2.34.1
Re: [PATCH 0/2] KVM: PPC: support kvm selftests
Nicholas Piggin writes: > Hi, > > This series adds initial KVM selftests support for powerpc > (64-bit, BookS). Awesome. > It spans 3 maintainers but it does not really > affect arch/powerpc, and it is well contained in selftests > code, just touches some makefiles and a tiny bit headers so > conflicts should be unlikely and trivial. > > I guess Paolo is the best point to merge these, if no comments > or objections? Yeah. If it helps: Acked-by: Michael Ellerman (powerpc) cheers
Re: [PATCH 0/3] COVER: Remove memcpy_page_flushcache()
Ira Weiny writes:
> Dave Hansen wrote:
>> On 3/15/23 16:20, Ira Weiny wrote:
>> > Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
>> > callbacks") removed the calls to memcpy_page_flushcache().
>> >
>> > kmap_atomic() is deprecated and used in the x86 version of
>> > memcpy_page_flushcache().
>> >
>> > Remove the unnecessary memcpy_page_flushcache() call from all arch's.
>>
>> Hi Ira,
>>
>> Since the common code user is already gone these three patches seem
>> quite independent. It seems like the right thing to do is have
>> individual arch maintainers cherry pick their arch patch and carry it
>> independently.
>
> Yes.
>
>>
>> Is there a compelling reason to have someone pick up and carry these all
>> together that I'm missing?
>
> No reason. Would you like me to submit them individually?
I'll just grab the powerpc one from the thread, no need to resend.
> Sorry, submitting them separately crossed my mind when I wrote them but I
> kind of forgot as they were all on the same branch and I was waiting for
> after the merge window to submit them.
It's also much easier to run git-send-email HEAD^^^, rather than running
it three separate times, let alone if it's a 20 patch series.
I wonder if we could come up with some convention to indicate that a
series is made up of independent patches, and maintainers are free to
pick them individually - but still sent as a single series.
cheers
