Re: [PATCH 20/22] usb: fsl-mph-dr-of: mark fsl_usb2_mpc5121_init() static
On Wed, Nov 08, 2023 at 01:58:41PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This function is only called locally and should always have been static:
>
> drivers/usb/host/fsl-mph-dr-of.c:291:5: error: no previous prototype for
> 'fsl_usb2_mpc5121_init' [-Werror=missing-prototypes]
>
> Fixes: 230f7ede6c2f ("USB: add USB EHCI support for MPC5121 SoC")
> Signed-off-by: Arnd Bergmann
Acked-by: Greg Kroah-Hartman
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH tty v1 00/74] serial: wrappers for uart port lock
On Mon, Sep 18, 2023 at 10:29:30AM +0206, John Ogness wrote: > On 2023-09-14, John Ogness wrote: > > Provide and use wrapper functions for spin_[un]lock*(port->lock) > > invocations so that the console mechanics can be applied later on at a > > single place and does not require to copy the same logic all over the > > drivers. > > For the full 74-patch series: > > Signed-off-by: John Ogness > > Sorry that my SoB was missing from the initial posting. Thanks for this, I'll rebuild my tree with this added. greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5.10 18/63] arc: add support for TIF_NOTIFY_SIGNAL
From: Jens Axboe [ Upstream commit 53855e12588743ea128ee31f913d1c6e2f1d32c8 ] Wire up TIF_NOTIFY_SIGNAL handling for arc. Cc: linux-snps-arc@lists.infradead.org Acked-by: Vineet Gupta Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- arch/arc/include/asm/thread_info.h |4 +++- arch/arc/kernel/entry.S|3 ++- arch/arc/kernel/signal.c |2 +- 3 files changed, 6 insertions(+), 3 deletions(-) --- a/arch/arc/include/asm/thread_info.h +++ b/arch/arc/include/asm/thread_info.h @@ -79,6 +79,7 @@ static inline __attribute_const__ struct #define TIF_SIGPENDING 2 /* signal pending */ #define TIF_NEED_RESCHED 3 /* rescheduling necessary */ #define TIF_SYSCALL_AUDIT 4 /* syscall auditing active */ +#define TIF_NOTIFY_SIGNAL 5 /* signal notifications exist */ #define TIF_SYSCALL_TRACE 15 /* syscall trace active */ /* true if poll_idle() is polling TIF_NEED_RESCHED */ @@ -89,11 +90,12 @@ static inline __attribute_const__ struct #define _TIF_SIGPENDING(1<http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 27/44] arc: iounmap() arg is volatile
From: Randy Dunlap
[ Upstream commit c44f15c1c09481d50fd33478ebb5b8284f8f5edb ]
Add 'volatile' to iounmap()'s argument to prevent build warnings.
This make it the same as other major architectures.
Placates these warnings: (12 such warnings)
../drivers/video/fbdev/riva/fbdev.c: In function 'rivafb_probe':
../drivers/video/fbdev/riva/fbdev.c:2067:42: error: passing argument 1 of
'iounmap' discards 'volatile' qualifier from pointer target type
[-Werror=discarded-qualifiers]
2067 | iounmap(default_par->riva.PRAMIN);
Fixes: 1162b0701b14b ("ARC: I/O and DMA Mappings")
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Arnd Bergmann
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/include/asm/io.h | 2 +-
arch/arc/mm/ioremap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 2f39d9b3886e..19d0cab60a39 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -35,7 +35,7 @@ static inline void ioport_unmap(void __iomem *addr)
{
}
-extern void iounmap(const void __iomem *addr);
+extern void iounmap(const volatile void __iomem *addr);
#define ioremap_nocache(phy, sz) ioremap(phy, sz)
#define ioremap_wc(phy, sz)ioremap(phy, sz)
diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
index 9881bd740ccc..0719b1280ef8 100644
--- a/arch/arc/mm/ioremap.c
+++ b/arch/arc/mm/ioremap.c
@@ -95,7 +95,7 @@ void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long
size,
EXPORT_SYMBOL(ioremap_prot);
-void iounmap(const void __iomem *addr)
+void iounmap(const volatile void __iomem *addr)
{
/* weird double cast to handle phys_addr_t > 32 bits */
if (arc_uncached_addr_space((phys_addr_t)(u32)addr))
--
2.35.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.14 37/60] arc: iounmap() arg is volatile
From: Randy Dunlap
[ Upstream commit c44f15c1c09481d50fd33478ebb5b8284f8f5edb ]
Add 'volatile' to iounmap()'s argument to prevent build warnings.
This make it the same as other major architectures.
Placates these warnings: (12 such warnings)
../drivers/video/fbdev/riva/fbdev.c: In function 'rivafb_probe':
../drivers/video/fbdev/riva/fbdev.c:2067:42: error: passing argument 1 of
'iounmap' discards 'volatile' qualifier from pointer target type
[-Werror=discarded-qualifiers]
2067 | iounmap(default_par->riva.PRAMIN);
Fixes: 1162b0701b14b ("ARC: I/O and DMA Mappings")
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Arnd Bergmann
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/include/asm/io.h | 2 +-
arch/arc/mm/ioremap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 2f39d9b3886e..19d0cab60a39 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -35,7 +35,7 @@ static inline void ioport_unmap(void __iomem *addr)
{
}
-extern void iounmap(const void __iomem *addr);
+extern void iounmap(const volatile void __iomem *addr);
#define ioremap_nocache(phy, sz) ioremap(phy, sz)
#define ioremap_wc(phy, sz)ioremap(phy, sz)
diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
index 9881bd740ccc..0719b1280ef8 100644
--- a/arch/arc/mm/ioremap.c
+++ b/arch/arc/mm/ioremap.c
@@ -95,7 +95,7 @@ void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long
size,
EXPORT_SYMBOL(ioremap_prot);
-void iounmap(const void __iomem *addr)
+void iounmap(const volatile void __iomem *addr)
{
/* weird double cast to handle phys_addr_t > 32 bits */
if (arc_uncached_addr_space((phys_addr_t)(u32)addr))
--
2.35.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.19 50/78] arc: iounmap() arg is volatile
From: Randy Dunlap
[ Upstream commit c44f15c1c09481d50fd33478ebb5b8284f8f5edb ]
Add 'volatile' to iounmap()'s argument to prevent build warnings.
This make it the same as other major architectures.
Placates these warnings: (12 such warnings)
../drivers/video/fbdev/riva/fbdev.c: In function 'rivafb_probe':
../drivers/video/fbdev/riva/fbdev.c:2067:42: error: passing argument 1 of
'iounmap' discards 'volatile' qualifier from pointer target type
[-Werror=discarded-qualifiers]
2067 | iounmap(default_par->riva.PRAMIN);
Fixes: 1162b0701b14b ("ARC: I/O and DMA Mappings")
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Arnd Bergmann
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/include/asm/io.h | 2 +-
arch/arc/mm/ioremap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 2f39d9b3886e..19d0cab60a39 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -35,7 +35,7 @@ static inline void ioport_unmap(void __iomem *addr)
{
}
-extern void iounmap(const void __iomem *addr);
+extern void iounmap(const volatile void __iomem *addr);
#define ioremap_nocache(phy, sz) ioremap(phy, sz)
#define ioremap_wc(phy, sz)ioremap(phy, sz)
diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
index 9881bd740ccc..0719b1280ef8 100644
--- a/arch/arc/mm/ioremap.c
+++ b/arch/arc/mm/ioremap.c
@@ -95,7 +95,7 @@ void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long
size,
EXPORT_SYMBOL(ioremap_prot);
-void iounmap(const void __iomem *addr)
+void iounmap(const volatile void __iomem *addr)
{
/* weird double cast to handle phys_addr_t > 32 bits */
if (arc_uncached_addr_space((phys_addr_t)(u32)addr))
--
2.35.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5.4 33/64] arc: iounmap() arg is volatile
From: Randy Dunlap
[ Upstream commit c44f15c1c09481d50fd33478ebb5b8284f8f5edb ]
Add 'volatile' to iounmap()'s argument to prevent build warnings.
This make it the same as other major architectures.
Placates these warnings: (12 such warnings)
../drivers/video/fbdev/riva/fbdev.c: In function 'rivafb_probe':
../drivers/video/fbdev/riva/fbdev.c:2067:42: error: passing argument 1 of
'iounmap' discards 'volatile' qualifier from pointer target type
[-Werror=discarded-qualifiers]
2067 | iounmap(default_par->riva.PRAMIN);
Fixes: 1162b0701b14b ("ARC: I/O and DMA Mappings")
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Arnd Bergmann
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/include/asm/io.h | 2 +-
arch/arc/mm/ioremap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 72f7929736f8..94ef71b38b69 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -32,7 +32,7 @@ static inline void ioport_unmap(void __iomem *addr)
{
}
-extern void iounmap(const void __iomem *addr);
+extern void iounmap(const volatile void __iomem *addr);
#define ioremap_nocache(phy, sz) ioremap(phy, sz)
#define ioremap_wc(phy, sz)ioremap(phy, sz)
diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
index 95c649fbc95a..d3b1ea16e9cd 100644
--- a/arch/arc/mm/ioremap.c
+++ b/arch/arc/mm/ioremap.c
@@ -93,7 +93,7 @@ void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long
size,
EXPORT_SYMBOL(ioremap_prot);
-void iounmap(const void __iomem *addr)
+void iounmap(const volatile void __iomem *addr)
{
/* weird double cast to handle phys_addr_t > 32 bits */
if (arc_uncached_addr_space((phys_addr_t)(u32)addr))
--
2.35.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5.10 40/91] arc: iounmap() arg is volatile
From: Randy Dunlap
[ Upstream commit c44f15c1c09481d50fd33478ebb5b8284f8f5edb ]
Add 'volatile' to iounmap()'s argument to prevent build warnings.
This make it the same as other major architectures.
Placates these warnings: (12 such warnings)
../drivers/video/fbdev/riva/fbdev.c: In function 'rivafb_probe':
../drivers/video/fbdev/riva/fbdev.c:2067:42: error: passing argument 1 of
'iounmap' discards 'volatile' qualifier from pointer target type
[-Werror=discarded-qualifiers]
2067 | iounmap(default_par->riva.PRAMIN);
Fixes: 1162b0701b14b ("ARC: I/O and DMA Mappings")
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Arnd Bergmann
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/include/asm/io.h | 2 +-
arch/arc/mm/ioremap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 8f777d6441a5..80347382a380 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -32,7 +32,7 @@ static inline void ioport_unmap(void __iomem *addr)
{
}
-extern void iounmap(const void __iomem *addr);
+extern void iounmap(const volatile void __iomem *addr);
/*
* io{read,write}{16,32}be() macros
diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
index 95c649fbc95a..d3b1ea16e9cd 100644
--- a/arch/arc/mm/ioremap.c
+++ b/arch/arc/mm/ioremap.c
@@ -93,7 +93,7 @@ void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long
size,
EXPORT_SYMBOL(ioremap_prot);
-void iounmap(const void __iomem *addr)
+void iounmap(const volatile void __iomem *addr)
{
/* weird double cast to handle phys_addr_t > 32 bits */
if (arc_uncached_addr_space((phys_addr_t)(u32)addr))
--
2.35.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5.15 063/132] arc: iounmap() arg is volatile
From: Randy Dunlap
[ Upstream commit c44f15c1c09481d50fd33478ebb5b8284f8f5edb ]
Add 'volatile' to iounmap()'s argument to prevent build warnings.
This make it the same as other major architectures.
Placates these warnings: (12 such warnings)
../drivers/video/fbdev/riva/fbdev.c: In function 'rivafb_probe':
../drivers/video/fbdev/riva/fbdev.c:2067:42: error: passing argument 1 of
'iounmap' discards 'volatile' qualifier from pointer target type
[-Werror=discarded-qualifiers]
2067 | iounmap(default_par->riva.PRAMIN);
Fixes: 1162b0701b14b ("ARC: I/O and DMA Mappings")
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Arnd Bergmann
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/include/asm/io.h | 2 +-
arch/arc/mm/ioremap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 8f777d6441a5..80347382a380 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -32,7 +32,7 @@ static inline void ioport_unmap(void __iomem *addr)
{
}
-extern void iounmap(const void __iomem *addr);
+extern void iounmap(const volatile void __iomem *addr);
/*
* io{read,write}{16,32}be() macros
diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
index 0ee75aca6e10..712c2311daef 100644
--- a/arch/arc/mm/ioremap.c
+++ b/arch/arc/mm/ioremap.c
@@ -94,7 +94,7 @@ void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long
size,
EXPORT_SYMBOL(ioremap_prot);
-void iounmap(const void __iomem *addr)
+void iounmap(const volatile void __iomem *addr)
{
/* weird double cast to handle phys_addr_t > 32 bits */
if (arc_uncached_addr_space((phys_addr_t)(u32)addr))
--
2.35.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 6.0 143/240] arc: iounmap() arg is volatile
From: Randy Dunlap
[ Upstream commit c44f15c1c09481d50fd33478ebb5b8284f8f5edb ]
Add 'volatile' to iounmap()'s argument to prevent build warnings.
This make it the same as other major architectures.
Placates these warnings: (12 such warnings)
../drivers/video/fbdev/riva/fbdev.c: In function 'rivafb_probe':
../drivers/video/fbdev/riva/fbdev.c:2067:42: error: passing argument 1 of
'iounmap' discards 'volatile' qualifier from pointer target type
[-Werror=discarded-qualifiers]
2067 | iounmap(default_par->riva.PRAMIN);
Fixes: 1162b0701b14b ("ARC: I/O and DMA Mappings")
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Arnd Bergmann
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/include/asm/io.h | 2 +-
arch/arc/mm/ioremap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 8f777d6441a5..80347382a380 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -32,7 +32,7 @@ static inline void ioport_unmap(void __iomem *addr)
{
}
-extern void iounmap(const void __iomem *addr);
+extern void iounmap(const volatile void __iomem *addr);
/*
* io{read,write}{16,32}be() macros
diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
index 0ee75aca6e10..712c2311daef 100644
--- a/arch/arc/mm/ioremap.c
+++ b/arch/arc/mm/ioremap.c
@@ -94,7 +94,7 @@ void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long
size,
EXPORT_SYMBOL(ioremap_prot);
-void iounmap(const void __iomem *addr)
+void iounmap(const volatile void __iomem *addr)
{
/* weird double cast to handle phys_addr_t > 32 bits */
if (arc_uncached_addr_space((phys_addr_t)(u32)addr))
--
2.35.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/2] Fix console probe delay when stdout-path isn't set
On Tue, Sep 27, 2022 at 03:17:59PM +0300, Andy Shevchenko wrote: > On Mon, Sep 26, 2022 at 01:25:05PM -0500, Rob Herring wrote: > > On Mon, Sep 19, 2022 at 5:56 PM Olof Johansson wrote: > > > > > > On Mon, Sep 19, 2022 at 1:44 AM Greg Kroah-Hartman > > > wrote: > > > > > > > > On Sun, Sep 18, 2022 at 08:44:27PM -0700, Olof Johansson wrote: > > > > > On Tue, Aug 23, 2022 at 8:37 AM Greg Kroah-Hartman > > > > > wrote: > > > > > > > > > > > > On Thu, Jun 30, 2022 at 06:26:38PM -0700, Saravana Kannan wrote: > > > > > > > These patches are on top of driver-core-next. > > > > > > > > > > > > > > Even if stdout-path isn't set in DT, this patch should take > > > > > > > console > > > > > > > probe times back to how they were before the > > > > > > > deferred_probe_timeout > > > > > > > clean up series[1]. > > > > > > > > > > > > Now dropped from my queue due to lack of a response to other > > > > > > reviewer's > > > > > > questions. > > > > > > > > > > What happened to this patch? I have a 10 second timeout on console > > > > > probe on my SiFive Unmatched, and I don't see this flag being set for > > > > > the serial driver. In fact, I don't see it anywhere in-tree. I can't > > > > > seem to locate another patchset from Saravana around this though, so > > > > > I'm not sure where to look for a missing piece for the sifive serial > > > > > driver. > > > > > > > > > > This is the second boot time regression (this one not fatal, unlike > > > > > the Layerscape PCIe one) from the fw_devlink patchset. > > > > > > > > > > Greg, can you revert the whole set for 6.0, please? It's obviously > > > > > nowhere near tested enough to go in and I expect we'll see a bunch of > > > > > -stable fixups due to this if we let it remain in. > > > > > > > > What exactly is "the whole set"? I have the default option fix queued > > > > up and will send that to Linus later this week (am traveling back from > > > > Plumbers still), but have not heard any problems about any other issues > > > > at all other than your report. > > > > > > I stand corrected in this case, the issue on the Hifive Unmatched was > > > a regression due to a PWM clock change -- I just sent a patch for that > > > (serial driver fix). > > > > > > So it seems like as long as the fw_devlink.strict=1 patch is reverted, > > > things are back to a working state here. > > > > > > I still struggle with how the fw_devlink patchset is expected to work > > > though, since DT is expected to describe the hardware configuration, > > > and it has no knowledge of whether there are drivers that will be > > > bound to any referenced supplier devnodes. It's not going to work well > > > to assume that they will always be bound, and to add 10 second > > > timeouts for those cases isn't a good solution. Seems like the number > > > of special cases will keep adding up. > > > > Since the introduction of deferred probe, the kernel has always > > assumed if there is a device described, then there is or will be a > > driver for it. The result is you can't use new DTs (if they add > > providers) with older kernels. > > > > We've ended up with a timeout because no one has come up with a better > > way to handle it. What the kernel needs is userspace saying "I'm done > > loading modules", but it's debatable whether that's a good solution > > too. > > In my opinion the deferred probe is a big hack and that is the root > cause of the issues we have here and there. It has to be redesigned > to be mathematically robust. It was an attempt by Andrzej Hajda to > solve this [1]. > > [1]: > https://events19.linuxfoundation.org/wp-content/uploads/2017/12/Deferred-Problem-Issues-With-Complex-Dependencies-Between-Devices-in-Linux-Kernel-Andrzej-Hajda-Samsung.pdf deferred probe has _ALWAYS_ been known to be a hack, way back when we accepted it, but it was the best hack we had to solve a real problem that we had, so it was accepted. It's been polished over the years, but yes, it does break down at times, due to the crazy complexity of hardware systems that we have no control over. If you have concrete solutions for how to solve the issue, wonderful, please submit patches :) thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/2] Fix console probe delay when stdout-path isn't set
On Sun, Sep 18, 2022 at 08:44:27PM -0700, Olof Johansson wrote: > On Tue, Aug 23, 2022 at 8:37 AM Greg Kroah-Hartman > wrote: > > > > On Thu, Jun 30, 2022 at 06:26:38PM -0700, Saravana Kannan wrote: > > > These patches are on top of driver-core-next. > > > > > > Even if stdout-path isn't set in DT, this patch should take console > > > probe times back to how they were before the deferred_probe_timeout > > > clean up series[1]. > > > > Now dropped from my queue due to lack of a response to other reviewer's > > questions. > > What happened to this patch? I have a 10 second timeout on console > probe on my SiFive Unmatched, and I don't see this flag being set for > the serial driver. In fact, I don't see it anywhere in-tree. I can't > seem to locate another patchset from Saravana around this though, so > I'm not sure where to look for a missing piece for the sifive serial > driver. > > This is the second boot time regression (this one not fatal, unlike > the Layerscape PCIe one) from the fw_devlink patchset. > > Greg, can you revert the whole set for 6.0, please? It's obviously > nowhere near tested enough to go in and I expect we'll see a bunch of > -stable fixups due to this if we let it remain in. What exactly is "the whole set"? I have the default option fix queued up and will send that to Linus later this week (am traveling back from Plumbers still), but have not heard any problems about any other issues at all other than your report. thnaks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/2] Fix console probe delay when stdout-path isn't set
On Thu, Jun 30, 2022 at 06:26:38PM -0700, Saravana Kannan wrote: > These patches are on top of driver-core-next. > > Even if stdout-path isn't set in DT, this patch should take console > probe times back to how they were before the deferred_probe_timeout > clean up series[1]. Now dropped from my queue due to lack of a response to other reviewer's questions. thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 08/17] all: replace bitmap_weight with bitmap_weight_{eq,gt,ge,lt,le} where appropriate
On Sat, Dec 18, 2021 at 01:20:04PM -0800, Yury Norov wrote:
> Kernel code calls bitmap_weight() to compare the weight of bitmap with
> a given number. We can do it more efficiently with bitmap_weight_{eq, ...}
> because conditional bitmap_weight may stop traversing the bitmap earlier,
> as soon as condition is met.
>
> This patch replaces bitmap_weight with conditional versions where possible,
> except for small bitmaps which size is not configurable and known at
> constant time. In that case conditional version of bitmap_weight would not
> benefit due to small_const_nbits() optimization; but readability may
> suffer.
>
> Signed-off-by: Yury Norov
> ---
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 2 +-
> drivers/iio/dummy/iio_simple_dummy_buffer.c| 4 ++--
> drivers/iio/industrialio-trigger.c | 2 +-
> drivers/memstick/core/ms_block.c | 4 ++--
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
> .../net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 2 +-
> .../net/ethernet/marvell/octeontx2/nic/otx2_flows.c| 4 ++--
> drivers/net/ethernet/mellanox/mlx4/cmd.c | 10 +++---
> drivers/net/ethernet/mellanox/mlx4/eq.c| 4 ++--
> drivers/net/ethernet/mellanox/mlx4/fw.c| 4 ++--
> drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
> drivers/perf/thunderx2_pmu.c | 4 ++--
> drivers/staging/media/tegra-video/vi.c | 2 +-
> 13 files changed, 21 insertions(+), 25 deletions(-)
"all" is not how to submit changes to the kernel. Please break them up
into subsystem-specific patches, and send them after your core changes
are accepted.
good luck!
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 3/9] all: replace bitmap_weigth() with bitmap_{empty,full,eq,gt,le}
On Sat, Nov 27, 2021 at 07:56:58PM -0800, Yury Norov wrote:
> bitmap_weight() counts all set bits in the bitmap unconditionally.
> However in some cases we can traverse a part of bitmap when we
> only need to check if number of set bits is greater, less or equal
> to some number.
>
> This patch replaces bitmap_weight() with one of
> bitmap_{empty,full,eq,gt,le), as appropriate.
>
> In some places driver code has been optimized further, where it's
> trivial.
>
> Signed-off-by: Yury Norov
> ---
> arch/nds32/kernel/perf_event_cpu.c | 4 +---
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 4 ++--
> arch/x86/kvm/hyperv.c | 8
> drivers/crypto/ccp/ccp-dev-v5.c| 5 +
> drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 2 +-
> drivers/iio/adc/mxs-lradc-adc.c| 3 +--
> drivers/iio/dummy/iio_simple_dummy_buffer.c| 4 ++--
> drivers/iio/industrialio-buffer.c | 2 +-
> drivers/iio/industrialio-trigger.c | 2 +-
> drivers/memstick/core/ms_block.c | 4 ++--
> drivers/net/dsa/b53/b53_common.c | 2 +-
> drivers/net/ethernet/broadcom/bcmsysport.c | 6 +-
> drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 4 ++--
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
> .../ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 2 +-
> .../ethernet/marvell/octeontx2/nic/otx2_flows.c| 8
> .../net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 2 +-
> drivers/net/ethernet/mellanox/mlx4/cmd.c | 10 +++---
> drivers/net/ethernet/mellanox/mlx4/eq.c| 4 ++--
> drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
> .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 2 +-
> drivers/net/ethernet/qlogic/qed/qed_dev.c | 3 +--
> drivers/net/ethernet/qlogic/qed/qed_rdma.c | 4 ++--
> drivers/net/ethernet/qlogic/qed/qed_roce.c | 2 +-
> drivers/perf/arm-cci.c | 2 +-
> drivers/perf/arm_pmu.c | 4 ++--
> drivers/perf/hisilicon/hisi_uncore_pmu.c | 2 +-
> drivers/perf/thunderx2_pmu.c | 3 +--
> drivers/perf/xgene_pmu.c | 2 +-
> drivers/pwm/pwm-pca9685.c | 2 +-
> drivers/staging/media/tegra-video/vi.c | 2 +-
> drivers/thermal/intel/intel_powerclamp.c | 10 --
> fs/ocfs2/cluster/heartbeat.c | 14 +++---
> 33 files changed, 57 insertions(+), 75 deletions(-)
After you get the new functions added to the kernel tree, this patch
should be broken up into one-patch-per-subsystem and submitted through
the various subsystem trees.
thanks,
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5.14 139/168] ARC: export clear_user_page() for modules
From: Randy Dunlap
[ Upstream commit 6b5ff0405e4190f23780362ea324b250bc495683 ]
0day bot reports a build error:
ERROR: modpost: "clear_user_page"
[drivers/media/v4l2-core/videobuf-dma-sg.ko] undefined!
so export it in arch/arc/ to fix the build error.
In most ARCHes, clear_user_page() is a macro. OTOH, in a few
ARCHes it is a function and needs to be exported.
PowerPC exported it in 2004. It looks like nds32 and nios2
still need to have it exported.
Fixes: 4102b53392d63 ("ARC: [mm] Aliasing VIPT dcache support 2/4")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Guenter Roeck
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/mm/cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index a2fbea3ee07c..102418ac5ff4 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -1123,7 +1123,7 @@ void clear_user_page(void *to, unsigned long u_vaddr,
struct page *page)
clear_page(to);
clear_bit(PG_dc_clean, >flags);
}
-
+EXPORT_SYMBOL(clear_user_page);
/**
* Explicit Cache flush request from user space via syscall
--
2.30.2
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5.10 096/122] ARC: export clear_user_page() for modules
From: Randy Dunlap
[ Upstream commit 6b5ff0405e4190f23780362ea324b250bc495683 ]
0day bot reports a build error:
ERROR: modpost: "clear_user_page"
[drivers/media/v4l2-core/videobuf-dma-sg.ko] undefined!
so export it in arch/arc/ to fix the build error.
In most ARCHes, clear_user_page() is a macro. OTOH, in a few
ARCHes it is a function and needs to be exported.
PowerPC exported it in 2004. It looks like nds32 and nios2
still need to have it exported.
Fixes: 4102b53392d63 ("ARC: [mm] Aliasing VIPT dcache support 2/4")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Guenter Roeck
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/mm/cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index a2fbea3ee07c..102418ac5ff4 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -1123,7 +1123,7 @@ void clear_user_page(void *to, unsigned long u_vaddr,
struct page *page)
clear_page(to);
clear_bit(PG_dc_clean, >flags);
}
-
+EXPORT_SYMBOL(clear_user_page);
/**
* Explicit Cache flush request from user space via syscall
--
2.30.2
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5.4 253/260] ARC: export clear_user_page() for modules
From: Randy Dunlap
[ Upstream commit 6b5ff0405e4190f23780362ea324b250bc495683 ]
0day bot reports a build error:
ERROR: modpost: "clear_user_page"
[drivers/media/v4l2-core/videobuf-dma-sg.ko] undefined!
so export it in arch/arc/ to fix the build error.
In most ARCHes, clear_user_page() is a macro. OTOH, in a few
ARCHes it is a function and needs to be exported.
PowerPC exported it in 2004. It looks like nds32 and nios2
still need to have it exported.
Fixes: 4102b53392d63 ("ARC: [mm] Aliasing VIPT dcache support 2/4")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Guenter Roeck
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/mm/cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index a2fbea3ee07c..102418ac5ff4 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -1123,7 +1123,7 @@ void clear_user_page(void *to, unsigned long u_vaddr,
struct page *page)
clear_page(to);
clear_bit(PG_dc_clean, >flags);
}
-
+EXPORT_SYMBOL(clear_user_page);
/**
* Explicit Cache flush request from user space via syscall
--
2.30.2
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.19 287/293] ARC: export clear_user_page() for modules
From: Randy Dunlap
[ Upstream commit 6b5ff0405e4190f23780362ea324b250bc495683 ]
0day bot reports a build error:
ERROR: modpost: "clear_user_page"
[drivers/media/v4l2-core/videobuf-dma-sg.ko] undefined!
so export it in arch/arc/ to fix the build error.
In most ARCHes, clear_user_page() is a macro. OTOH, in a few
ARCHes it is a function and needs to be exported.
PowerPC exported it in 2004. It looks like nds32 and nios2
still need to have it exported.
Fixes: 4102b53392d63 ("ARC: [mm] Aliasing VIPT dcache support 2/4")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Guenter Roeck
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/mm/cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index cf9619d4efb4..c5254c5967ed 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -1112,7 +1112,7 @@ void clear_user_page(void *to, unsigned long u_vaddr,
struct page *page)
clear_page(to);
clear_bit(PG_dc_clean, >flags);
}
-
+EXPORT_SYMBOL(clear_user_page);
/**
* Explicit Cache flush request from user space via syscall
--
2.30.2
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.14 213/217] ARC: export clear_user_page() for modules
From: Randy Dunlap
[ Upstream commit 6b5ff0405e4190f23780362ea324b250bc495683 ]
0day bot reports a build error:
ERROR: modpost: "clear_user_page"
[drivers/media/v4l2-core/videobuf-dma-sg.ko] undefined!
so export it in arch/arc/ to fix the build error.
In most ARCHes, clear_user_page() is a macro. OTOH, in a few
ARCHes it is a function and needs to be exported.
PowerPC exported it in 2004. It looks like nds32 and nios2
still need to have it exported.
Fixes: 4102b53392d63 ("ARC: [mm] Aliasing VIPT dcache support 2/4")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Guenter Roeck
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/mm/cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index d14499500106..bf02efbee5e1 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -1118,7 +1118,7 @@ void clear_user_page(void *to, unsigned long u_vaddr,
struct page *page)
clear_page(to);
clear_bit(PG_dc_clean, >flags);
}
-
+EXPORT_SYMBOL(clear_user_page);
/**
* Explicit Cache flush request from user space via syscall
--
2.30.2
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 172/175] ARC: export clear_user_page() for modules
From: Randy Dunlap
[ Upstream commit 6b5ff0405e4190f23780362ea324b250bc495683 ]
0day bot reports a build error:
ERROR: modpost: "clear_user_page"
[drivers/media/v4l2-core/videobuf-dma-sg.ko] undefined!
so export it in arch/arc/ to fix the build error.
In most ARCHes, clear_user_page() is a macro. OTOH, in a few
ARCHes it is a function and needs to be exported.
PowerPC exported it in 2004. It looks like nds32 and nios2
still need to have it exported.
Fixes: 4102b53392d63 ("ARC: [mm] Aliasing VIPT dcache support 2/4")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Guenter Roeck
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/mm/cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index fefe357c3d31..076b5e8c8562 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -923,7 +923,7 @@ void clear_user_page(void *to, unsigned long u_vaddr,
struct page *page)
clear_page(to);
clear_bit(PG_dc_clean, >flags);
}
-
+EXPORT_SYMBOL(clear_user_page);
/**
* Explicit Cache flush request from user space via syscall
--
2.30.2
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.4 131/133] ARC: export clear_user_page() for modules
From: Randy Dunlap
[ Upstream commit 6b5ff0405e4190f23780362ea324b250bc495683 ]
0day bot reports a build error:
ERROR: modpost: "clear_user_page"
[drivers/media/v4l2-core/videobuf-dma-sg.ko] undefined!
so export it in arch/arc/ to fix the build error.
In most ARCHes, clear_user_page() is a macro. OTOH, in a few
ARCHes it is a function and needs to be exported.
PowerPC exported it in 2004. It looks like nds32 and nios2
still need to have it exported.
Fixes: 4102b53392d63 ("ARC: [mm] Aliasing VIPT dcache support 2/4")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Guenter Roeck
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/mm/cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 017fb440bba4..f425405a8a76 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -904,7 +904,7 @@ void clear_user_page(void *to, unsigned long u_vaddr,
struct page *page)
clear_page(to);
clear_bit(PG_dc_clean, >flags);
}
-
+EXPORT_SYMBOL(clear_user_page);
/**
* Explicit Cache flush request from user space via syscall
--
2.30.2
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/3] arch: Export machine_restart() instances so they can be called from modules
On Thu, Aug 05, 2021 at 06:36:25PM +0100, Catalin Marinas wrote:
> On Thu, Aug 05, 2021 at 08:50:30AM +0100, Lee Jones wrote:
> > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > index b4bb67f17a2ca..cf89ce91d7145 100644
> > --- a/arch/arm64/kernel/process.c
> > +++ b/arch/arm64/kernel/process.c
> > @@ -212,6 +212,7 @@ void machine_restart(char *cmd)
> > printk("Reboot failed -- System halted\n");
> > while (1);
> > }
> > +EXPORT_SYMBOL(machine_restart);
>
> Should we make this EXPORT_SYMBOL_GPL? I suppose it's not for general
> use by out of tree drivers and it matches the other pm_power_off symbol
> we export in this file.
Yes please.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.14 15/50] arch/arc: add copy_user_page() to to fix build error on ARC
From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration] Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: linux-snps-arc@lists.infradead.org Cc: Dan Williams #Acked-by: Vineet Gupta # v1 Cc: Andrew Morton Cc: Matthew Wilcox Cc: Jan Kara Cc: linux-fsde...@vger.kernel.org Cc: linux-nvd...@lists.01.org #Reviewed-by: Ira Weiny # v2 Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin --- arch/arc/include/asm/page.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h index 09f71cc50..a70fef79c4055 100644 --- a/arch/arc/include/asm/page.h +++ b/arch/arc/include/asm/page.h @@ -13,6 +13,7 @@ #ifndef __ASSEMBLY__ #define clear_page(paddr) memset((paddr), 0, PAGE_SIZE) +#define copy_user_page(to, from, vaddr, pg)copy_page(to, from) #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE) struct vm_area_struct; -- 2.27.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 10/35] arch/arc: add copy_user_page() to to fix build error on ARC
From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration] Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: linux-snps-arc@lists.infradead.org Cc: Dan Williams #Acked-by: Vineet Gupta # v1 Cc: Andrew Morton Cc: Matthew Wilcox Cc: Jan Kara Cc: linux-fsde...@vger.kernel.org Cc: linux-nvd...@lists.01.org #Reviewed-by: Ira Weiny # v2 Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin --- arch/arc/include/asm/page.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h index ffb5f33475f19..f0f43eb709d2f 100644 --- a/arch/arc/include/asm/page.h +++ b/arch/arc/include/asm/page.h @@ -13,6 +13,7 @@ #ifndef __ASSEMBLY__ #define clear_page(paddr) memset((paddr), 0, PAGE_SIZE) +#define copy_user_page(to, from, vaddr, pg)copy_page(to, from) #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE) struct vm_area_struct; -- 2.27.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.4 07/31] arch/arc: add copy_user_page() to to fix build error on ARC
From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration] Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: linux-snps-arc@lists.infradead.org Cc: Dan Williams #Acked-by: Vineet Gupta # v1 Cc: Andrew Morton Cc: Matthew Wilcox Cc: Jan Kara Cc: linux-fsde...@vger.kernel.org Cc: linux-nvd...@lists.01.org #Reviewed-by: Ira Weiny # v2 Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin --- arch/arc/include/asm/page.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h index 8f1145ed0046f..fd2c88ef2e2b8 100644 --- a/arch/arc/include/asm/page.h +++ b/arch/arc/include/asm/page.h @@ -17,6 +17,7 @@ #define free_user_page(page, addr) free_page(addr) #define clear_page(paddr) memset((paddr), 0, PAGE_SIZE) +#define copy_user_page(to, from, vaddr, pg)copy_page(to, from) #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE) struct vm_area_struct; -- 2.27.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5.10 081/152] arch/arc: add copy_user_page() to to fix build error on ARC
From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration] Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: linux-snps-arc@lists.infradead.org Cc: Dan Williams #Acked-by: Vineet Gupta # v1 Cc: Andrew Morton Cc: Matthew Wilcox Cc: Jan Kara Cc: linux-fsde...@vger.kernel.org Cc: linux-nvd...@lists.01.org #Reviewed-by: Ira Weiny # v2 Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin --- arch/arc/include/asm/page.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h index b0dfed0f12be0..d9c264dc25fcb 100644 --- a/arch/arc/include/asm/page.h +++ b/arch/arc/include/asm/page.h @@ -10,6 +10,7 @@ #ifndef __ASSEMBLY__ #define clear_page(paddr) memset((paddr), 0, PAGE_SIZE) +#define copy_user_page(to, from, vaddr, pg)copy_page(to, from) #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE) struct vm_area_struct; -- 2.27.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5.4 38/76] arch/arc: add copy_user_page() to to fix build error on ARC
From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration] Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: linux-snps-arc@lists.infradead.org Cc: Dan Williams #Acked-by: Vineet Gupta # v1 Cc: Andrew Morton Cc: Matthew Wilcox Cc: Jan Kara Cc: linux-fsde...@vger.kernel.org Cc: linux-nvd...@lists.01.org #Reviewed-by: Ira Weiny # v2 Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin --- arch/arc/include/asm/page.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h index 0a32e8cfd074d..bcd1920ae75a3 100644 --- a/arch/arc/include/asm/page.h +++ b/arch/arc/include/asm/page.h @@ -10,6 +10,7 @@ #ifndef __ASSEMBLY__ #define clear_page(paddr) memset((paddr), 0, PAGE_SIZE) +#define copy_user_page(to, from, vaddr, pg)copy_page(to, from) #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE) struct vm_area_struct; -- 2.27.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.19 19/43] arch/arc: add copy_user_page() to to fix build error on ARC
From: Randy Dunlap [ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in . ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration] Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: linux-snps-arc@lists.infradead.org Cc: Dan Williams #Acked-by: Vineet Gupta # v1 Cc: Andrew Morton Cc: Matthew Wilcox Cc: Jan Kara Cc: linux-fsde...@vger.kernel.org Cc: linux-nvd...@lists.01.org #Reviewed-by: Ira Weiny # v2 Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin --- arch/arc/include/asm/page.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h index 09f71cc50..a70fef79c4055 100644 --- a/arch/arc/include/asm/page.h +++ b/arch/arc/include/asm/page.h @@ -13,6 +13,7 @@ #ifndef __ASSEMBLY__ #define clear_page(paddr) memset((paddr), 0, PAGE_SIZE) +#define copy_user_page(to, from, vaddr, pg)copy_page(to, from) #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE) struct vm_area_struct; -- 2.27.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] Revert "ARC: entry: fix potential EFA clobber when TIF_SYSCALL_TRACE"
On Sat, Nov 07, 2020 at 03:10:06PM +0100, Greg Kroah-Hartman wrote: > On Fri, Nov 06, 2020 at 08:27:44PM +, Vineet Gupta wrote: > > Hi Stable Team, > > > > On 10/19/20 7:19 PM, Vineet Gupta wrote: > > > This reverts commit 00fdec98d9881bf5173af09aebd353ab3b9ac729. > > > (but only from 5.2 and prior kernels) > > > > > > The original commit was a preventive fix based on code-review and was > > > auto-picked for stable back-port (for better or worse). > > > It was OK for v5.3+ kernels, but turned up needing an implicit change > > > 68e5c6f073bcf70 "(ARC: entry: EV_Trap expects r10 (vs. r9) to have > > > exception cause)" merged in v5.3 which itself was not backported. > > > So to summarize the stable backport of this patch for v5.2 and prior > > > kernels is busted and it won't boot. > > > > > > The obvious solution is backport 68e5c6f073bcf70 but that is a pain as > > > it doesn't revert cleanly and each of affected kernels (so far v4.19, > > > v4.14, v4.9, v4.4) needs a slightly different massaged varaint. > > > So the easier fix is to simply revert the backport from 5.2 and prior. > > > The issue was not a big deal as it would cause strace to sporadically > > > not work correctly. > > > > > > Waldemar Brodkorb first reported this when running ARC uClibc regressions > > > on latest stable kernels (with offending backport). Once he bisected it, > > > the analysis was trivial, so thx to him for this. > > > > > > Reported-by: Waldemar Brodkorb > > > Bisected-by: Waldemar Brodkorb > > > Cc: stable # 5.2 and prior > > > Signed-off-by: Vineet Gupta > > > > Can this revert be please applied to 4.19 and older kernels for the next > > cycle. > > > > Or is there is a procedural issue given this revert is not in mainline. I've > > described the issue in detail above so if there's a better/desirable way of > > reverting it from backports, please let me know. > > THis is fine, sorry, it's just in a backlog of lots of stable patches... > > We will get to it soon. Now queued up, thanks. gre gk-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] Revert "ARC: entry: fix potential EFA clobber when TIF_SYSCALL_TRACE"
On Fri, Nov 06, 2020 at 08:27:44PM +, Vineet Gupta wrote: > Hi Stable Team, > > On 10/19/20 7:19 PM, Vineet Gupta wrote: > > This reverts commit 00fdec98d9881bf5173af09aebd353ab3b9ac729. > > (but only from 5.2 and prior kernels) > > > > The original commit was a preventive fix based on code-review and was > > auto-picked for stable back-port (for better or worse). > > It was OK for v5.3+ kernels, but turned up needing an implicit change > > 68e5c6f073bcf70 "(ARC: entry: EV_Trap expects r10 (vs. r9) to have > > exception cause)" merged in v5.3 which itself was not backported. > > So to summarize the stable backport of this patch for v5.2 and prior > > kernels is busted and it won't boot. > > > > The obvious solution is backport 68e5c6f073bcf70 but that is a pain as > > it doesn't revert cleanly and each of affected kernels (so far v4.19, > > v4.14, v4.9, v4.4) needs a slightly different massaged varaint. > > So the easier fix is to simply revert the backport from 5.2 and prior. > > The issue was not a big deal as it would cause strace to sporadically > > not work correctly. > > > > Waldemar Brodkorb first reported this when running ARC uClibc regressions > > on latest stable kernels (with offending backport). Once he bisected it, > > the analysis was trivial, so thx to him for this. > > > > Reported-by: Waldemar Brodkorb > > Bisected-by: Waldemar Brodkorb > > Cc: stable # 5.2 and prior > > Signed-off-by: Vineet Gupta > > Can this revert be please applied to 4.19 and older kernels for the next > cycle. > > Or is there is a procedural issue given this revert is not in mainline. I've > described the issue in detail above so if there's a better/desirable way of > reverting it from backports, please let me know. THis is fine, sorry, it's just in a backlog of lots of stable patches... We will get to it soon. thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.14 18/89] arc: eznps: fix allmodconfig kconfig warning
From: Randy Dunlap [ Upstream commit 1928b36cfa4df1aeedf5f2644d0c33f3a1fcfd7b ] Fix kconfig warning for arch/arc/plat-eznps/Kconfig allmodconfig: WARNING: unmet direct dependencies detected for CLKSRC_NPS Depends on [n]: GENERIC_CLOCKEVENTS [=y] && !PHYS_ADDR_T_64BIT [=y] Selected by [y]: - ARC_PLAT_EZNPS [=y] Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: Ofer Levi Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin --- arch/arc/plat-eznps/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/plat-eznps/Kconfig b/arch/arc/plat-eznps/Kconfig index 8eff057efcaeb..ce908e2c52824 100644 --- a/arch/arc/plat-eznps/Kconfig +++ b/arch/arc/plat-eznps/Kconfig @@ -7,7 +7,7 @@ menuconfig ARC_PLAT_EZNPS bool "\"EZchip\" ARC dev platform" select CPU_BIG_ENDIAN - select CLKSRC_NPS + select CLKSRC_NPS if !PHYS_ADDR_T_64BIT select EZNPS_GIC select EZCHIP_NPS_MANAGEMENT_ENET if ETHERNET help -- 2.20.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 17/68] arc: eznps: fix allmodconfig kconfig warning
From: Randy Dunlap [ Upstream commit 1928b36cfa4df1aeedf5f2644d0c33f3a1fcfd7b ] Fix kconfig warning for arch/arc/plat-eznps/Kconfig allmodconfig: WARNING: unmet direct dependencies detected for CLKSRC_NPS Depends on [n]: GENERIC_CLOCKEVENTS [=y] && !PHYS_ADDR_T_64BIT [=y] Selected by [y]: - ARC_PLAT_EZNPS [=y] Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: Ofer Levi Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin --- arch/arc/plat-eznps/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/plat-eznps/Kconfig b/arch/arc/plat-eznps/Kconfig index 1d175cc6ad6d3..86f844caa405d 100644 --- a/arch/arc/plat-eznps/Kconfig +++ b/arch/arc/plat-eznps/Kconfig @@ -7,7 +7,7 @@ menuconfig ARC_PLAT_EZNPS bool "\"EZchip\" ARC dev platform" select ARC_HAS_COH_CACHES if SMP select CPU_BIG_ENDIAN - select CLKSRC_NPS + select CLKSRC_NPS if !PHYS_ADDR_T_64BIT select EZNPS_GIC select EZCHIP_NPS_MANAGEMENT_ENET if ETHERNET help -- 2.20.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.19 26/55] arc: eznps: fix allmodconfig kconfig warning
From: Randy Dunlap [ Upstream commit 1928b36cfa4df1aeedf5f2644d0c33f3a1fcfd7b ] Fix kconfig warning for arch/arc/plat-eznps/Kconfig allmodconfig: WARNING: unmet direct dependencies detected for CLKSRC_NPS Depends on [n]: GENERIC_CLOCKEVENTS [=y] && !PHYS_ADDR_T_64BIT [=y] Selected by [y]: - ARC_PLAT_EZNPS [=y] Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: Ofer Levi Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin --- arch/arc/plat-eznps/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/plat-eznps/Kconfig b/arch/arc/plat-eznps/Kconfig index 8eff057efcaeb..ce908e2c52824 100644 --- a/arch/arc/plat-eznps/Kconfig +++ b/arch/arc/plat-eznps/Kconfig @@ -7,7 +7,7 @@ menuconfig ARC_PLAT_EZNPS bool "\"EZchip\" ARC dev platform" select CPU_BIG_ENDIAN - select CLKSRC_NPS + select CLKSRC_NPS if !PHYS_ADDR_T_64BIT select EZNPS_GIC select EZCHIP_NPS_MANAGEMENT_ENET if ETHERNET help -- 2.20.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5.4 045/110] arc: eznps: fix allmodconfig kconfig warning
From: Randy Dunlap [ Upstream commit 1928b36cfa4df1aeedf5f2644d0c33f3a1fcfd7b ] Fix kconfig warning for arch/arc/plat-eznps/Kconfig allmodconfig: WARNING: unmet direct dependencies detected for CLKSRC_NPS Depends on [n]: GENERIC_CLOCKEVENTS [=y] && !PHYS_ADDR_T_64BIT [=y] Selected by [y]: - ARC_PLAT_EZNPS [=y] Signed-off-by: Randy Dunlap Cc: Vineet Gupta Cc: Ofer Levi Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin --- arch/arc/plat-eznps/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/plat-eznps/Kconfig b/arch/arc/plat-eznps/Kconfig index a376a50d3fea8..a931d0a256d01 100644 --- a/arch/arc/plat-eznps/Kconfig +++ b/arch/arc/plat-eznps/Kconfig @@ -7,7 +7,7 @@ menuconfig ARC_PLAT_EZNPS bool "\"EZchip\" ARC dev platform" select CPU_BIG_ENDIAN - select CLKSRC_NPS + select CLKSRC_NPS if !PHYS_ADDR_T_64BIT select EZNPS_GIC select EZCHIP_NPS_MANAGEMENT_ENET if ETHERNET help -- 2.20.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: perf: Accommodate big-endian CPU
On Wed, Nov 27, 2019 at 11:01:23AM +0300, Alexey Brodkin wrote:
> 8-letter strings representing ARC perf events are stores in two
> 32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc.
>
> And the same order of bytes in the word is used regardless CPU endianness.
>
> Which means in case of big-endian CPU core we need to swap bytes to get
> the same order as if it was on little-endian CPU.
>
> Otherwise we're seeing the following error message on boot:
> ->8--
> ARC perf: 8 counters (32 bits), 40 conditions, [overflow IRQ support]
> sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji'
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
> Stack Trace:
> arc_unwind_core+0xd4/0xfc
> dump_stack+0x64/0x80
> sysfs_warn_dup+0x46/0x58
> sysfs_add_file_mode_ns+0xb2/0x168
> create_files+0x70/0x2a0
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144
> perf_event_sysfs_init+0x70/0xa0
> Failed to register pmu: arc_pct, reason -17
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
> Stack Trace:
> arc_unwind_core+0xd4/0xfc
> dump_stack+0x64/0x80
> __warn+0x9c/0xd4
> warn_slowpath_fmt+0x22/0x2c
> perf_event_sysfs_init+0x70/0xa0
> ---[ end trace a75fb9a9837bd1ec ]---
> ->8--
>
> What happens here we're trying to register more than one raw perf event
> with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters
> and encoded into two 32-bit words. In this particular case we deal with 2
> events:
> * "IJMP" which counts all jump & branch instructions
> * "IJMPC___" which counts only conditional jumps & branches
>
> Those strings are split in two 32-bit words this way "IJMP" + "" &
> "IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core
> being big-endian then we read "PMJI" + "" & "PMJI" + "___C".
>
> And since we interpret read array of ASCII letters as a null-terminated string
> on big-endian CPU we end up with 2 events of the same name "PMJI".
>
> Signed-off-by: Alexey Brodkin
> Cc: sta...@vger.kernel.org
> ---
>
> Greg, Sasha, this is the same patch as
> commit 5effc09c4907 ("ARC: perf: Accommodate big-endian CPU")
> but fine-tuned to be applicable to kernels 4.19 and older.
Thanks, now queued up.
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: perf: Accommodate big-endian CPU
On Tue, Nov 05, 2019 at 07:52:16PM +, Alexey Brodkin wrote:
> Hi Sasha, Greg,
>
> > -Original Message-
> > From: Sasha Levin
> > Sent: Saturday, October 26, 2019 4:11 PM
> > To: Sasha Levin ; Alexey Brodkin
> > ; linux-snps-
> > a...@lists.infradead.org
> > Cc: linux-ker...@vger.kernel.org; sta...@vger.kernel.org;
> > sta...@vger.kernel.org
> > Subject: Re: [PATCH] ARC: perf: Accommodate big-endian CPU
> >
> > Hi,
> >
> > [This is an automated email]
> >
> > This commit has been processed because it contains a -stable tag.
> > The stable tag indicates that it's relevant for the following trees: all
> >
> > The bot has tested the following trees: v5.3.7, v4.19.80, v4.14.150,
> > v4.9.197, v4.4.197.
> >
> > v5.3.7: Build OK!
> > v4.19.80: Failed to apply! Possible dependencies:
> > 0e956150fe09f ("ARC: perf: introduce Kernel PMU events support")
> > 14f81a91ad29a ("ARC: perf: trivial code cleanup")
> > baf9cc85ba01f ("ARC: perf: move HW events mapping to separate function")
> > v4.14.150: Failed to apply! Possible dependencies:
> > v4.9.197: Failed to apply! Possible dependencies:
> > v4.4.197: Failed to apply! Possible dependencies:
>
> Indeed the clash is due to
> commit baf9cc85ba01f ("ARC: perf: move HW events mapping to separate
> function") as tmp variable "j" was changed on "i". So that's a fixed hunk:
> >8--
> diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c
> index 8aec462d90fb..30f66b123541 100644
> --- a/arch/arc/kernel/perf_event.c
> +++ b/arch/arc/kernel/perf_event.c
> @@ -490,8 +490,8 @@ static int arc_pmu_device_probe(struct platform_device
> *pdev)
> /* loop thru all available h/w condition indexes */
> for (j = 0; j < cc_bcr.c; j++) {
> write_aux_reg(ARC_REG_CC_INDEX, j);
> - cc_name.indiv.word0 = read_aux_reg(ARC_REG_CC_NAME0);
> - cc_name.indiv.word1 = read_aux_reg(ARC_REG_CC_NAME1);
> + cc_name.indiv.word0 =
> le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME0));
> + cc_name.indiv.word1 =
> le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME1));
>
> /* See if it has been mapped to a perf event_id */
> for (i = 0; i < ARRAY_SIZE(arc_pmu_ev_hw_map); i++) {
> >8--
>
> Should I send a formal patch with it or it's OK for now?
We need a "formal" patch that we can apply if you want it applied.
thanks,
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: stable backport for dc8635b78cd8669
On Wed, Sep 18, 2019 at 01:10:04PM -0700, Vineet Gupta wrote: > On 9/18/19 11:56 AM, Greg Kroah-Hartman wrote: > > So is this only needed in 4.9.y and 4.4.y? > > Yes indeed ! It doesn't apply there at all, can you provide a working backport for those kernels so that I can queue it up? thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: stable backport for dc8635b78cd8669
On Wed, Sep 18, 2019 at 10:40:32AM -0700, Vineet Gupta wrote:
> Hi Stable team,
>
> Can we please backport dc8635b78cd8669c37e230058d18c33af7451ab1
> ("kernel/exit.c:
> export abort() to modules")
>
> 0-Day kernel test infra reports ARC 4.x.y builds failing after backport of
> af1be2e21203867cb958aace ("ARC: handle gcc generated __builtin_trap for older
> compiler")
So is this only needed in 4.9.y and 4.4.y?
thanks,
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/2] ARC: enable uboot support unconditionally
On Fri, Aug 02, 2019 at 04:25:39PM +, Alexey Brodkin wrote: > Hi Greg, > > > > May we have this one back-ported to linux-4.19.y? > > > > > > It was initially applied to Linus' tree during 5.0 development > > > cycle [1] but was never back-ported. > > > > > > Now w/o that patch in KernelCI we see boot failure on ARC HSDK > > > board [2] as opposed to normally working later kernel versions. > > > > > > [1] > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=493a2f812446e92bcb1e69a77381b4d39808d730 > > > [2] > > > https://storage.kernelci.org/stable/linux-4.19.y/v4.19.59/arc/hsdk_defconfig/gcc-8/lab-baylibre/boot-hsdk.txt > > > > > > Below is that same patch but rebased on linux-4.19 as in its pristine > > > form it won't apply due to offset of one of hunks. > > > > Why is this patch ok for stable kernel trees? Are you not removing > > existing support in 4.19 for a feature that people might be using there? > > What bug is this fixing that requires this removal? > > This patch removes a Kconfig option in a trade for properly working > detection of arguments passed from U-Boot. > > Back in the day [3] we had to add that option to get kernel reliably working > in use-cases w/o U-Boot (those were typically loading kernel image via JTAG). > But with a couple of fixes applied to linux-4.19.y already we no longer need > that explicit toggle as we may rely on data passed via dedicated registers > and thus automatically know if there was U-Boot which passed some info to > the kernel or there was no U-Boot and we don't need to mess with garbage in > those registers. > > Main reason is to make vanilla 4.19.y kernels usable on HSDK board in KernelCI > environment. Now they don't boot, see [2] as in HSDK's defconfig > ARC_UBOOT_SUPPORT > is not set. So we have 2 solutions: > > 1. Add ARC_UBOOT_SUPPORT to arch/arc/configs/hsdk_defconfig >But we cannot do it for vanilla kernel because we simply cannot even > submit that >change to the Linus' tree as that Kconfig option was removed. >Which means we cannot back-port it, right :) > > 2. Back-port proposed patch which already exists in the Linus'tree and thus is >perfectly back-portable. > > Makes sense? Ok, it's your arch, you get to deal with the angry users if you have any :) now queued up. greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/2] ARC: enable uboot support unconditionally
On Thu, Jul 18, 2019 at 08:51:23PM +, Alexey Brodkin wrote: > Hi Greg, > > > -Original Message- > > From: Eugeniy Paltsev > > Sent: Thursday, February 14, 2019 6:08 PM > > To: linux-snps-arc@lists.infradead.org; Vineet Gupta > > Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; > > Corentin Labbe > > ; khil...@baylibre.com; Eugeniy Paltsev > > > > Subject: [PATCH v2 2/2] ARC: enable uboot support unconditionally > > > > After reworking U-boot args handling code and adding paranoid > > arguments check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and > > enable uboot support unconditionally. > > > > For JTAG case we can assume that core registers will come up > > reset value of 0 or in worst case we rely on user passing > > '-on=clear_regs' to Metaware debugger. > > > > Signed-off-by: Eugeniy Paltsev > > May we have this one back-ported to linux-4.19.y? > > It was initially applied to Linus' tree during 5.0 development > cycle [1] but was never back-ported. > > Now w/o that patch in KernelCI we see boot failure on ARC HSDK > board [2] as opposed to normally working later kernel versions. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=493a2f812446e92bcb1e69a77381b4d39808d730 > [2] > https://storage.kernelci.org/stable/linux-4.19.y/v4.19.59/arc/hsdk_defconfig/gcc-8/lab-baylibre/boot-hsdk.txt > > Below is that same patch but rebased on linux-4.19 as in its pristine > form it won't apply due to offset of one of hunks. Why is this patch ok for stable kernel trees? Are you not removing existing support in 4.19 for a feature that people might be using there? What bug is this fixing that requires this removal? thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.4 071/241] perf bench numa: Add define for RUSAGE_THREAD if not present
[ Upstream commit bf561d3c13423fc54daa19b5d49dc15fafdb7acc ] While cross building perf to the ARC architecture on a fedora 30 host, we were failing with: CC /tmp/build/perf/bench/numa.o bench/numa.c: In function ‘worker_thread’: bench/numa.c:1261:12: error: ‘RUSAGE_THREAD’ undeclared (first use in this function); did you mean ‘SIGEV_THREAD’? getrusage(RUSAGE_THREAD, ); ^ SIGEV_THREAD bench/numa.c:1261:12: note: each undeclared identifier is reported only once for each function it appears in [perfbuilder@60d5802468f6 perf]$ /arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-gcc --version | head -1 arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225 [perfbuilder@60d5802468f6 perf]$ Trying to reproduce a report by Vineet, I noticed that, with just cross-built zlib and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define, check for that and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define in the system headers, check if it is defined in the 'perf bench numa' sources and define it if not. Now it builds and I have to figure out if the problem reported by Vineet only takes place if we have libelf or some other library available. Cc: Arnd Bergmann Cc: Jiri Olsa Cc: linux-snps-arc@lists.infradead.org Cc: Namhyung Kim Cc: Vineet Gupta Link: https://lkml.kernel.org/n/tip-2wb4r1gir9xrevbpq7qp0...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin --- tools/perf/bench/numa.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c index 73d192f57dc34..df41deed0320e 100644 --- a/tools/perf/bench/numa.c +++ b/tools/perf/bench/numa.c @@ -32,6 +32,10 @@ #include #include +#ifndef RUSAGE_THREAD +# define RUSAGE_THREAD 1 +#endif + /* * Regular printout to the terminal, supressed if -q is specified: */ -- 2.20.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 5.0 131/139] perf bench numa: Add define for RUSAGE_THREAD if not present
[ Upstream commit bf561d3c13423fc54daa19b5d49dc15fafdb7acc ] While cross building perf to the ARC architecture on a fedora 30 host, we were failing with: CC /tmp/build/perf/bench/numa.o bench/numa.c: In function ‘worker_thread’: bench/numa.c:1261:12: error: ‘RUSAGE_THREAD’ undeclared (first use in this function); did you mean ‘SIGEV_THREAD’? getrusage(RUSAGE_THREAD, ); ^ SIGEV_THREAD bench/numa.c:1261:12: note: each undeclared identifier is reported only once for each function it appears in [perfbuilder@60d5802468f6 perf]$ /arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-gcc --version | head -1 arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225 [perfbuilder@60d5802468f6 perf]$ Trying to reproduce a report by Vineet, I noticed that, with just cross-built zlib and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define, check for that and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define in the system headers, check if it is defined in the 'perf bench numa' sources and define it if not. Now it builds and I have to figure out if the problem reported by Vineet only takes place if we have libelf or some other library available. Cc: Arnd Bergmann Cc: Jiri Olsa Cc: linux-snps-arc@lists.infradead.org Cc: Namhyung Kim Cc: Vineet Gupta Link: https://lkml.kernel.org/n/tip-2wb4r1gir9xrevbpq7qp0...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin --- tools/perf/bench/numa.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c index 44195514b19e6..fa56fde6e8d80 100644 --- a/tools/perf/bench/numa.c +++ b/tools/perf/bench/numa.c @@ -38,6 +38,10 @@ #include #include +#ifndef RUSAGE_THREAD +# define RUSAGE_THREAD 1 +#endif + /* * Regular printout to the terminal, supressed if -q is specified: */ -- 2.20.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.19 106/114] perf bench numa: Add define for RUSAGE_THREAD if not present
[ Upstream commit bf561d3c13423fc54daa19b5d49dc15fafdb7acc ] While cross building perf to the ARC architecture on a fedora 30 host, we were failing with: CC /tmp/build/perf/bench/numa.o bench/numa.c: In function ‘worker_thread’: bench/numa.c:1261:12: error: ‘RUSAGE_THREAD’ undeclared (first use in this function); did you mean ‘SIGEV_THREAD’? getrusage(RUSAGE_THREAD, ); ^ SIGEV_THREAD bench/numa.c:1261:12: note: each undeclared identifier is reported only once for each function it appears in [perfbuilder@60d5802468f6 perf]$ /arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-gcc --version | head -1 arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225 [perfbuilder@60d5802468f6 perf]$ Trying to reproduce a report by Vineet, I noticed that, with just cross-built zlib and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define, check for that and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define in the system headers, check if it is defined in the 'perf bench numa' sources and define it if not. Now it builds and I have to figure out if the problem reported by Vineet only takes place if we have libelf or some other library available. Cc: Arnd Bergmann Cc: Jiri Olsa Cc: linux-snps-arc@lists.infradead.org Cc: Namhyung Kim Cc: Vineet Gupta Link: https://lkml.kernel.org/n/tip-2wb4r1gir9xrevbpq7qp0...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin --- tools/perf/bench/numa.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c index 44195514b19e6..fa56fde6e8d80 100644 --- a/tools/perf/bench/numa.c +++ b/tools/perf/bench/numa.c @@ -38,6 +38,10 @@ #include #include +#ifndef RUSAGE_THREAD +# define RUSAGE_THREAD 1 +#endif + /* * Regular printout to the terminal, supressed if -q is specified: */ -- 2.20.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.14 71/77] perf bench numa: Add define for RUSAGE_THREAD if not present
[ Upstream commit bf561d3c13423fc54daa19b5d49dc15fafdb7acc ] While cross building perf to the ARC architecture on a fedora 30 host, we were failing with: CC /tmp/build/perf/bench/numa.o bench/numa.c: In function ‘worker_thread’: bench/numa.c:1261:12: error: ‘RUSAGE_THREAD’ undeclared (first use in this function); did you mean ‘SIGEV_THREAD’? getrusage(RUSAGE_THREAD, ); ^ SIGEV_THREAD bench/numa.c:1261:12: note: each undeclared identifier is reported only once for each function it appears in [perfbuilder@60d5802468f6 perf]$ /arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-gcc --version | head -1 arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225 [perfbuilder@60d5802468f6 perf]$ Trying to reproduce a report by Vineet, I noticed that, with just cross-built zlib and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define, check for that and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define in the system headers, check if it is defined in the 'perf bench numa' sources and define it if not. Now it builds and I have to figure out if the problem reported by Vineet only takes place if we have libelf or some other library available. Cc: Arnd Bergmann Cc: Jiri Olsa Cc: linux-snps-arc@lists.infradead.org Cc: Namhyung Kim Cc: Vineet Gupta Link: https://lkml.kernel.org/n/tip-2wb4r1gir9xrevbpq7qp0...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin --- tools/perf/bench/numa.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c index 0afcc7eccc619..997875c770b10 100644 --- a/tools/perf/bench/numa.c +++ b/tools/perf/bench/numa.c @@ -38,6 +38,10 @@ #include #include +#ifndef RUSAGE_THREAD +# define RUSAGE_THREAD 1 +#endif + /* * Regular printout to the terminal, supressed if -q is specified: */ -- 2.20.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 50/53] perf bench numa: Add define for RUSAGE_THREAD if not present
[ Upstream commit bf561d3c13423fc54daa19b5d49dc15fafdb7acc ] While cross building perf to the ARC architecture on a fedora 30 host, we were failing with: CC /tmp/build/perf/bench/numa.o bench/numa.c: In function ‘worker_thread’: bench/numa.c:1261:12: error: ‘RUSAGE_THREAD’ undeclared (first use in this function); did you mean ‘SIGEV_THREAD’? getrusage(RUSAGE_THREAD, ); ^ SIGEV_THREAD bench/numa.c:1261:12: note: each undeclared identifier is reported only once for each function it appears in [perfbuilder@60d5802468f6 perf]$ /arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-gcc --version | head -1 arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225 [perfbuilder@60d5802468f6 perf]$ Trying to reproduce a report by Vineet, I noticed that, with just cross-built zlib and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define, check for that and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define in the system headers, check if it is defined in the 'perf bench numa' sources and define it if not. Now it builds and I have to figure out if the problem reported by Vineet only takes place if we have libelf or some other library available. Cc: Arnd Bergmann Cc: Jiri Olsa Cc: linux-snps-arc@lists.infradead.org Cc: Namhyung Kim Cc: Vineet Gupta Link: https://lkml.kernel.org/n/tip-2wb4r1gir9xrevbpq7qp0...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin --- tools/perf/bench/numa.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c index ee9565a033f47..e58be7eeced83 100644 --- a/tools/perf/bench/numa.c +++ b/tools/perf/bench/numa.c @@ -35,6 +35,10 @@ #include #include +#ifndef RUSAGE_THREAD +# define RUSAGE_THREAD 1 +#endif + /* * Regular printout to the terminal, supressed if -q is specified: */ -- 2.20.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 07/12] dma-mapping: move CONFIG_DMA_CMA to kernel/dma/Kconfig
On Mon, Feb 11, 2019 at 02:35:49PM +0100, Christoph Hellwig wrote: > This is where all the related code already lives. > > Signed-off-by: Christoph Hellwig > --- > drivers/base/Kconfig | 77 > kernel/dma/Kconfig | 77 > 2 files changed, 77 insertions(+), 77 deletions(-) Much nicer, thanks! Reviewed-by: Greg Kroah-Hartman ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability
On Mon, Feb 11, 2019 at 02:35:48PM +0100, Christoph Hellwig wrote: > This API is primarily used through DT entries, but two architectures > and two drivers call it directly. So instead of selecting the config > symbol for random architectures pull it in implicitly for the actual > users. Also rename the Kconfig option to describe the feature better. > > Signed-off-by: Christoph Hellwig Reviewed-by: Greg Kroah-Hartman ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 09/12] dma-mapping: remove the DMA_MEMORY_EXCLUSIVE flag
On Mon, Feb 11, 2019 at 02:35:51PM +0100, Christoph Hellwig wrote: > All users of dma_declare_coherent want their allocations to be > exclusive, so default to exclusive allocations. > > Signed-off-by: Christoph Hellwig > --- > Documentation/DMA-API.txt | 9 +-- > arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 12 +++-- > arch/arm/mach-imx/mach-mx31moboard.c | 3 +-- > arch/sh/boards/mach-ap325rxa/setup.c | 5 ++-- > arch/sh/boards/mach-ecovec24/setup.c | 6 ++--- > arch/sh/boards/mach-kfr2r09/setup.c | 5 ++-- > arch/sh/boards/mach-migor/setup.c | 5 ++-- > arch/sh/boards/mach-se/7724/setup.c | 6 ++--- > arch/sh/drivers/pci/fixups-dreamcast.c| 3 +-- > .../soc_camera/sh_mobile_ceu_camera.c | 3 +-- > drivers/usb/host/ohci-sm501.c | 3 +-- > drivers/usb/host/ohci-tmio.c | 2 +- > include/linux/dma-mapping.h | 7 ++ > kernel/dma/coherent.c | 25 ++- > 14 files changed, 29 insertions(+), 65 deletions(-) Reviewed-by: Greg Kroah-Hartman ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/12] device.h: dma_mem is only needed for HAVE_GENERIC_DMA_COHERENT
On Mon, Feb 11, 2019 at 02:35:44PM +0100, Christoph Hellwig wrote: > No need to carry an unused field around. > > Signed-off-by: Christoph Hellwig > --- > include/linux/device.h | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Greg Kroah-Hartman ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 21/21] memblock: drop memblock_alloc_*_nopanic() variants
On Wed, Jan 16, 2019 at 03:44:21PM +0200, Mike Rapoport wrote: > As all the memblock allocation functions return NULL in case of error > rather than panic(), the duplicates with _nopanic suffix can be removed. > > Signed-off-by: Mike Rapoport > --- > arch/arc/kernel/unwind.c | 3 +-- > arch/sh/mm/init.c | 2 +- > arch/x86/kernel/setup_percpu.c | 10 +- > arch/x86/mm/kasan_init_64.c| 14 -- > drivers/firmware/memmap.c | 2 +- > drivers/usb/early/xhci-dbc.c | 2 +- > include/linux/memblock.h | 35 --- > kernel/dma/swiotlb.c | 2 +- > kernel/printk/printk.c | 17 +++-- > mm/memblock.c | 35 --- > mm/page_alloc.c| 10 +- > mm/page_ext.c | 2 +- > mm/percpu.c| 11 --- > mm/sparse.c| 6 ++ > 14 files changed, 37 insertions(+), 114 deletions(-) Acked-by: Greg Kroah-Hartman ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [GIT PULL] ARC updates for 4.19-rc8
On Mon, Oct 08, 2018 at 07:54:50PM +, Vineet Gupta wrote: > Hi Greg, > > Late in the cycle, but please pull ARC updates. We could have waited for next > release had it not been for the the clone syscall fix which is stable > material. > > Thx, > -Vineet > > ---> > The following changes since commit 11da3a7f84f19c26da6f86af878298694ede0804: > > Linux 4.19-rc3 (2018-09-09 17:26:43 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ > tags/arc-4.19-rc8 Now merged, thanks. greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.14 065/165] arc: [plat-eznps] fix data type errors in platform headers
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Randy Dunlap [ Upstream commit b1f32ce1c3d2c11959b7e6a2c58dc5197c581966 ] Add to fix build errors. Both ctop.h and use u32 types and cause many errors. Examples: ../include/soc/nps/common.h:71:4: error: unknown type name 'u32' u32 __reserved:20, cluster:4, core:4, thread:4; ../include/soc/nps/common.h:76:3: error: unknown type name 'u32' u32 value; ../include/soc/nps/common.h:124:4: error: unknown type name 'u32' u32 base:8, cl_x:4, cl_y:4, ../include/soc/nps/common.h:127:3: error: unknown type name 'u32' u32 value; ../arch/arc/plat-eznps/include/plat/ctop.h:83:4: error: unknown type name 'u32' u32 gen:1, gdis:1, clk_gate_dis:1, asb:1, ../arch/arc/plat-eznps/include/plat/ctop.h:86:3: error: unknown type name 'u32' u32 value; ../arch/arc/plat-eznps/include/plat/ctop.h:93:4: error: unknown type name 'u32' u32 csa:22, dmsid:6, __reserved:3, cs:1; ../arch/arc/plat-eznps/include/plat/ctop.h:95:3: error: unknown type name 'u32' u32 value; Cc: linux-snps-arc@lists.infradead.org Cc: Ofer Levi Reviewed-by: Leon Romanovsky Signed-off-by: Randy Dunlap Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- arch/arc/plat-eznps/include/plat/ctop.h |1 + 1 file changed, 1 insertion(+) --- a/arch/arc/plat-eznps/include/plat/ctop.h +++ b/arch/arc/plat-eznps/include/plat/ctop.h @@ -21,6 +21,7 @@ #error "Incorrect ctop.h include" #endif +#include #include /* core auxiliary registers */ ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.14 067/165] arc: fix build errors in arc/include/asm/delay.h
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 2423665ec53f2a29191b35382075e9834288a975 ]
Fix build errors in arch/arc/'s delay.h:
- add "extern unsigned long loops_per_jiffy;"
- add for "u64"
In file included from ../drivers/infiniband/hw/cxgb3/cxio_hal.c:32:
../arch/arc/include/asm/delay.h: In function '__udelay':
../arch/arc/include/asm/delay.h:61:12: error: 'u64' undeclared (first use in
this function)
loops = ((u64) usecs * 4295 * HZ * loops_per_jiffy) >> 32;
^~~
In file included from ../drivers/infiniband/hw/cxgb3/cxio_hal.c:32:
../arch/arc/include/asm/delay.h: In function '__udelay':
../arch/arc/include/asm/delay.h:63:37: error: 'loops_per_jiffy' undeclared
(first use in this function)
loops = ((u64) usecs * 4295 * HZ * loops_per_jiffy) >> 32;
^~~
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Elad Kanfi
Cc: Leon Romanovsky
Cc: Ofer Levi
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arc/include/asm/delay.h |3 +++
1 file changed, 3 insertions(+)
--- a/arch/arc/include/asm/delay.h
+++ b/arch/arc/include/asm/delay.h
@@ -17,8 +17,11 @@
#ifndef __ASM_ARC_UDELAY_H
#define __ASM_ARC_UDELAY_H
+#include
#include /* HZ */
+extern unsigned long loops_per_jiffy;
+
static inline void __delay(unsigned long loops)
{
__asm__ __volatile__(
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.14 066/165] arc: [plat-eznps] fix printk warning in arc/plat-eznps/mtm.c
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 9e2ea405543d9ddfe05b351f1679e53bd9c11f80 ]
Fix printk format warning in arch/arc/plat-eznps/mtm.c:
In file included from ../include/linux/printk.h:7,
from ../include/linux/kernel.h:14,
from ../include/linux/list.h:9,
from ../include/linux/smp.h:12,
from ../arch/arc/plat-eznps/mtm.c:17:
../arch/arc/plat-eznps/mtm.c: In function 'set_mtm_hs_ctr':
../include/linux/kern_levels.h:5:18: warning: format '%d' expects argument of
type 'int', but argument 2 has type 'long int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^~
../include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
../include/linux/printk.h:308:9: note: in expansion of macro 'KERN_ERR'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
../arch/arc/plat-eznps/mtm.c:166:3: note: in expansion of macro 'pr_err'
pr_err("** Invalid @nps_mtm_hs_ctr [%d] needs to be [%d:%d] (incl)\n",
^~
../arch/arc/plat-eznps/mtm.c:166:40: note: format string is defined here
pr_err("** Invalid @nps_mtm_hs_ctr [%d] needs to be [%d:%d] (incl)\n",
~^
%ld
The hs_ctr variable can just be int instead of long, so also change
kstrtol() to kstrtoint() and leave the format string as %d.
Also add 2 header files since they are used in mtm.c and we prefer
not to depend on accidental/indirect #includes.
Cc: linux-snps-arc@lists.infradead.org
Cc: Ofer Levi
Reviewed-by: Leon Romanovsky
Signed-off-by: Randy Dunlap
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arc/plat-eznps/mtm.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/arc/plat-eznps/mtm.c
+++ b/arch/arc/plat-eznps/mtm.c
@@ -15,6 +15,8 @@
*/
#include
+#include
+#include
#include
#include
#include
@@ -157,10 +159,10 @@ void mtm_enable_core(unsigned int cpu)
/* Verify and set the value of the mtm hs counter */
static int __init set_mtm_hs_ctr(char *ctr_str)
{
- long hs_ctr;
+ int hs_ctr;
int ret;
- ret = kstrtol(ctr_str, 0, _ctr);
+ ret = kstrtoint(ctr_str, 0, _ctr);
if (ret || hs_ctr > MT_HS_CNT_MAX || hs_ctr < MT_HS_CNT_MIN) {
pr_err("** Invalid @nps_mtm_hs_ctr [%d] needs to be [%d:%d]
(incl)\n",
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.14 068/165] arc: fix type warnings in arc/mm/cache.c
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit ec837d620c750c0d4996a907c8c4f7febe1bbeee ]
Fix type warnings in arch/arc/mm/cache.c.
../arch/arc/mm/cache.c: In function 'flush_anon_page':
../arch/arc/mm/cache.c:1062:55: warning: passing argument 2 of
'__flush_dcache_page' makes integer from pointer without a cast
[-Wint-conversion]
__flush_dcache_page((phys_addr_t)page_address(page), page_address(page));
^~
../arch/arc/mm/cache.c:1013:59: note: expected 'long unsigned int' but argument
is of type 'void *'
void __flush_dcache_page(phys_addr_t paddr, unsigned long vaddr)
~~^
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Elad Kanfi
Cc: Leon Romanovsky
Cc: Ofer Levi
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arc/mm/cache.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -1035,7 +1035,7 @@ void flush_cache_mm(struct mm_struct *mm
void flush_cache_page(struct vm_area_struct *vma, unsigned long u_vaddr,
unsigned long pfn)
{
- unsigned int paddr = pfn << PAGE_SHIFT;
+ phys_addr_t paddr = pfn << PAGE_SHIFT;
u_vaddr &= PAGE_MASK;
@@ -1055,8 +1055,9 @@ void flush_anon_page(struct vm_area_stru
unsigned long u_vaddr)
{
/* TBD: do we really need to clear the kernel mapping */
- __flush_dcache_page(page_address(page), u_vaddr);
- __flush_dcache_page(page_address(page), page_address(page));
+ __flush_dcache_page((phys_addr_t)page_address(page), u_vaddr);
+ __flush_dcache_page((phys_addr_t)page_address(page),
+ (phys_addr_t)page_address(page));
}
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 038/107] arc: [plat-eznps] fix data type errors in platform headers
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Randy Dunlap [ Upstream commit b1f32ce1c3d2c11959b7e6a2c58dc5197c581966 ] Add to fix build errors. Both ctop.h and use u32 types and cause many errors. Examples: ../include/soc/nps/common.h:71:4: error: unknown type name 'u32' u32 __reserved:20, cluster:4, core:4, thread:4; ../include/soc/nps/common.h:76:3: error: unknown type name 'u32' u32 value; ../include/soc/nps/common.h:124:4: error: unknown type name 'u32' u32 base:8, cl_x:4, cl_y:4, ../include/soc/nps/common.h:127:3: error: unknown type name 'u32' u32 value; ../arch/arc/plat-eznps/include/plat/ctop.h:83:4: error: unknown type name 'u32' u32 gen:1, gdis:1, clk_gate_dis:1, asb:1, ../arch/arc/plat-eznps/include/plat/ctop.h:86:3: error: unknown type name 'u32' u32 value; ../arch/arc/plat-eznps/include/plat/ctop.h:93:4: error: unknown type name 'u32' u32 csa:22, dmsid:6, __reserved:3, cs:1; ../arch/arc/plat-eznps/include/plat/ctop.h:95:3: error: unknown type name 'u32' u32 value; Cc: linux-snps-arc@lists.infradead.org Cc: Ofer Levi Reviewed-by: Leon Romanovsky Signed-off-by: Randy Dunlap Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- arch/arc/plat-eznps/include/plat/ctop.h |1 + 1 file changed, 1 insertion(+) --- a/arch/arc/plat-eznps/include/plat/ctop.h +++ b/arch/arc/plat-eznps/include/plat/ctop.h @@ -21,6 +21,7 @@ #error "Incorrect ctop.h include" #endif +#include #include /* core auxiliary registers */ ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 039/107] arc: fix build errors in arc/include/asm/delay.h
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 2423665ec53f2a29191b35382075e9834288a975 ]
Fix build errors in arch/arc/'s delay.h:
- add "extern unsigned long loops_per_jiffy;"
- add for "u64"
In file included from ../drivers/infiniband/hw/cxgb3/cxio_hal.c:32:
../arch/arc/include/asm/delay.h: In function '__udelay':
../arch/arc/include/asm/delay.h:61:12: error: 'u64' undeclared (first use in
this function)
loops = ((u64) usecs * 4295 * HZ * loops_per_jiffy) >> 32;
^~~
In file included from ../drivers/infiniband/hw/cxgb3/cxio_hal.c:32:
../arch/arc/include/asm/delay.h: In function '__udelay':
../arch/arc/include/asm/delay.h:63:37: error: 'loops_per_jiffy' undeclared
(first use in this function)
loops = ((u64) usecs * 4295 * HZ * loops_per_jiffy) >> 32;
^~~
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Elad Kanfi
Cc: Leon Romanovsky
Cc: Ofer Levi
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arc/include/asm/delay.h |3 +++
1 file changed, 3 insertions(+)
--- a/arch/arc/include/asm/delay.h
+++ b/arch/arc/include/asm/delay.h
@@ -17,8 +17,11 @@
#ifndef __ASM_ARC_UDELAY_H
#define __ASM_ARC_UDELAY_H
+#include
#include /* HZ */
+extern unsigned long loops_per_jiffy;
+
static inline void __delay(unsigned long loops)
{
__asm__ __volatile__(
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 040/107] arc: fix type warnings in arc/mm/cache.c
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit ec837d620c750c0d4996a907c8c4f7febe1bbeee ]
Fix type warnings in arch/arc/mm/cache.c.
../arch/arc/mm/cache.c: In function 'flush_anon_page':
../arch/arc/mm/cache.c:1062:55: warning: passing argument 2 of
'__flush_dcache_page' makes integer from pointer without a cast
[-Wint-conversion]
__flush_dcache_page((phys_addr_t)page_address(page), page_address(page));
^~
../arch/arc/mm/cache.c:1013:59: note: expected 'long unsigned int' but argument
is of type 'void *'
void __flush_dcache_page(phys_addr_t paddr, unsigned long vaddr)
~~^
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Elad Kanfi
Cc: Leon Romanovsky
Cc: Ofer Levi
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arc/mm/cache.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -840,7 +840,7 @@ void flush_cache_mm(struct mm_struct *mm
void flush_cache_page(struct vm_area_struct *vma, unsigned long u_vaddr,
unsigned long pfn)
{
- unsigned int paddr = pfn << PAGE_SHIFT;
+ phys_addr_t paddr = pfn << PAGE_SHIFT;
u_vaddr &= PAGE_MASK;
@@ -860,8 +860,9 @@ void flush_anon_page(struct vm_area_stru
unsigned long u_vaddr)
{
/* TBD: do we really need to clear the kernel mapping */
- __flush_dcache_page(page_address(page), u_vaddr);
- __flush_dcache_page(page_address(page), page_address(page));
+ __flush_dcache_page((phys_addr_t)page_address(page), u_vaddr);
+ __flush_dcache_page((phys_addr_t)page_address(page),
+ (phys_addr_t)page_address(page));
}
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.4 36/80] arc: fix type warnings in arc/mm/cache.c
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit ec837d620c750c0d4996a907c8c4f7febe1bbeee ]
Fix type warnings in arch/arc/mm/cache.c.
../arch/arc/mm/cache.c: In function 'flush_anon_page':
../arch/arc/mm/cache.c:1062:55: warning: passing argument 2 of
'__flush_dcache_page' makes integer from pointer without a cast
[-Wint-conversion]
__flush_dcache_page((phys_addr_t)page_address(page), page_address(page));
^~
../arch/arc/mm/cache.c:1013:59: note: expected 'long unsigned int' but argument
is of type 'void *'
void __flush_dcache_page(phys_addr_t paddr, unsigned long vaddr)
~~^
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Elad Kanfi
Cc: Leon Romanovsky
Cc: Ofer Levi
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arc/mm/cache.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -821,7 +821,7 @@ void flush_cache_mm(struct mm_struct *mm
void flush_cache_page(struct vm_area_struct *vma, unsigned long u_vaddr,
unsigned long pfn)
{
- unsigned int paddr = pfn << PAGE_SHIFT;
+ phys_addr_t paddr = pfn << PAGE_SHIFT;
u_vaddr &= PAGE_MASK;
@@ -841,8 +841,9 @@ void flush_anon_page(struct vm_area_stru
unsigned long u_vaddr)
{
/* TBD: do we really need to clear the kernel mapping */
- __flush_dcache_page(page_address(page), u_vaddr);
- __flush_dcache_page(page_address(page), page_address(page));
+ __flush_dcache_page((phys_addr_t)page_address(page), u_vaddr);
+ __flush_dcache_page((phys_addr_t)page_address(page),
+ (phys_addr_t)page_address(page));
}
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.4 35/80] arc: fix build errors in arc/include/asm/delay.h
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 2423665ec53f2a29191b35382075e9834288a975 ]
Fix build errors in arch/arc/'s delay.h:
- add "extern unsigned long loops_per_jiffy;"
- add for "u64"
In file included from ../drivers/infiniband/hw/cxgb3/cxio_hal.c:32:
../arch/arc/include/asm/delay.h: In function '__udelay':
../arch/arc/include/asm/delay.h:61:12: error: 'u64' undeclared (first use in
this function)
loops = ((u64) usecs * 4295 * HZ * loops_per_jiffy) >> 32;
^~~
In file included from ../drivers/infiniband/hw/cxgb3/cxio_hal.c:32:
../arch/arc/include/asm/delay.h: In function '__udelay':
../arch/arc/include/asm/delay.h:63:37: error: 'loops_per_jiffy' undeclared
(first use in this function)
loops = ((u64) usecs * 4295 * HZ * loops_per_jiffy) >> 32;
^~~
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Elad Kanfi
Cc: Leon Romanovsky
Cc: Ofer Levi
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arc/include/asm/delay.h |3 +++
1 file changed, 3 insertions(+)
--- a/arch/arc/include/asm/delay.h
+++ b/arch/arc/include/asm/delay.h
@@ -17,8 +17,11 @@
#ifndef __ASM_ARC_UDELAY_H
#define __ASM_ARC_UDELAY_H
+#include
#include /* HZ */
+extern unsigned long loops_per_jiffy;
+
static inline void __delay(unsigned long loops)
{
__asm__ __volatile__(
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 3.18 30/56] arc: fix build errors in arc/include/asm/delay.h
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 2423665ec53f2a29191b35382075e9834288a975 ]
Fix build errors in arch/arc/'s delay.h:
- add "extern unsigned long loops_per_jiffy;"
- add for "u64"
In file included from ../drivers/infiniband/hw/cxgb3/cxio_hal.c:32:
../arch/arc/include/asm/delay.h: In function '__udelay':
../arch/arc/include/asm/delay.h:61:12: error: 'u64' undeclared (first use in
this function)
loops = ((u64) usecs * 4295 * HZ * loops_per_jiffy) >> 32;
^~~
In file included from ../drivers/infiniband/hw/cxgb3/cxio_hal.c:32:
../arch/arc/include/asm/delay.h: In function '__udelay':
../arch/arc/include/asm/delay.h:63:37: error: 'loops_per_jiffy' undeclared
(first use in this function)
loops = ((u64) usecs * 4295 * HZ * loops_per_jiffy) >> 32;
^~~
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Elad Kanfi
Cc: Leon Romanovsky
Cc: Ofer Levi
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arc/include/asm/delay.h |3 +++
1 file changed, 3 insertions(+)
--- a/arch/arc/include/asm/delay.h
+++ b/arch/arc/include/asm/delay.h
@@ -17,8 +17,11 @@
#ifndef __ASM_ARC_UDELAY_H
#define __ASM_ARC_UDELAY_H
+#include
#include /* HZ */
+extern unsigned long loops_per_jiffy;
+
static inline void __delay(unsigned long loops)
{
__asm__ __volatile__(
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 3.18 31/56] arc: fix type warnings in arc/mm/cache.c
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit ec837d620c750c0d4996a907c8c4f7febe1bbeee ]
Fix type warnings in arch/arc/mm/cache.c.
../arch/arc/mm/cache.c: In function 'flush_anon_page':
../arch/arc/mm/cache.c:1062:55: warning: passing argument 2 of
'__flush_dcache_page' makes integer from pointer without a cast
[-Wint-conversion]
__flush_dcache_page((phys_addr_t)page_address(page), page_address(page));
^~
../arch/arc/mm/cache.c:1013:59: note: expected 'long unsigned int' but argument
is of type 'void *'
void __flush_dcache_page(phys_addr_t paddr, unsigned long vaddr)
~~^
Signed-off-by: Randy Dunlap
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Cc: Elad Kanfi
Cc: Leon Romanovsky
Cc: Ofer Levi
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/arc/mm/cache_arc700.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/arch/arc/mm/cache_arc700.c
+++ b/arch/arc/mm/cache_arc700.c
@@ -642,7 +642,7 @@ void flush_cache_mm(struct mm_struct *mm
void flush_cache_page(struct vm_area_struct *vma, unsigned long u_vaddr,
unsigned long pfn)
{
- unsigned int paddr = pfn << PAGE_SHIFT;
+ phys_addr_t paddr = pfn << PAGE_SHIFT;
u_vaddr &= PAGE_MASK;
@@ -662,8 +662,9 @@ void flush_anon_page(struct vm_area_stru
unsigned long u_vaddr)
{
/* TBD: do we really need to clear the kernel mapping */
- __flush_dcache_page(page_address(page), u_vaddr);
- __flush_dcache_page(page_address(page), page_address(page));
+ __flush_dcache_page((phys_addr_t)page_address(page), u_vaddr);
+ __flush_dcache_page((phys_addr_t)page_address(page),
+ (phys_addr_t)page_address(page));
}
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.4 25/92] futex: Remove duplicated code and fix undefined behaviour
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby <jsl...@suse.cz>
commit 30d6e0a4190d37740e9447e4e4815f06992dd8c3 upstream.
There is code duplicated over all architecture's headers for
futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
and comparison of the result.
Remove this duplication and leave up to the arches only the needed
assembly which is now in arch_futex_atomic_op_inuser.
This effectively distributes the Will Deacon's arm64 fix for undefined
behaviour reported by UBSAN to all architectures. The fix was done in
commit 5f16a046f8e1 (arm64: futex: Fix undefined behaviour with
FUTEX_OP_OPARG_SHIFT usage). Look there for an example dump.
And as suggested by Thomas, check for negative oparg too, because it was
also reported to cause undefined behaviour report.
Note that s390 removed access_ok check in d12a29703 ("s390/uaccess:
remove pointless access_ok() checks") as access_ok there returns true.
We introduce it back to the helper for the sake of simplicity (it gets
optimized away anyway).
Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Acked-by: Russell King <rmk+ker...@armlinux.org.uk>
Acked-by: Michael Ellerman <m...@ellerman.id.au> (powerpc)
Acked-by: Heiko Carstens <heiko.carst...@de.ibm.com> [s390]
Acked-by: Chris Metcalf <cmetc...@mellanox.com> [for tile]
Reviewed-by: Darren Hart (VMware) <dvh...@infradead.org>
Reviewed-by: Will Deacon <will.dea...@arm.com> [core/arm64]
Cc: linux-m...@linux-mips.org
Cc: Rich Felker <dal...@libc.org>
Cc: linux-i...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: pet...@infradead.org
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Max Filippov <jcmvb...@gmail.com>
Cc: Paul Mackerras <pau...@samba.org>
Cc: sparcli...@vger.kernel.org
Cc: Jonas Bonn <jo...@southpole.se>
Cc: linux-s...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: Yoshinori Sato <ys...@users.sourceforge.jp>
Cc: linux-hexa...@vger.kernel.org
Cc: Helge Deller <del...@gmx.de>
Cc: "James E.J. Bottomley" <j...@parisc-linux.org>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Matt Turner <matts...@gmail.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: Fenghua Yu <fenghua...@intel.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: linux-xte...@linux-xtensa.org
Cc: Stefan Kristiansson <stefan.kristians...@saunalahti.fi>
Cc: openr...@lists.librecores.org
Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
Cc: Stafford Horne <sho...@gmail.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: Richard Henderson <r...@twiddle.net>
Cc: Chris Zankel <ch...@zankel.net>
Cc: Michal Simek <mon...@monstr.eu>
Cc: Tony Luck <tony.l...@intel.com>
Cc: linux-par...@vger.kernel.org
Cc: Vineet Gupta <vgu...@synopsys.com>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: Richard Kuo <r...@codeaurora.org>
Cc: linux-al...@vger.kernel.org
Cc: Martin Schwidefsky <schwidef...@de.ibm.com>
Cc: linuxppc-...@lists.ozlabs.org
Cc: "David S. Miller" <da...@davemloft.net>
Link: http://lkml.kernel.org/r/20170824073105.3901-1-jsl...@suse.cz
Cc: Ben Hutchings <ben.hutchi...@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/alpha/include/asm/futex.h | 26 +++---
arch/arc/include/asm/futex.h| 40 +++-
arch/arm/include/asm/futex.h| 26 ++
arch/arm64/include/asm/futex.h | 26 ++
arch/frv/include/asm/futex.h|3 +-
arch/frv/kernel/futex.c | 27 ++-
arch/hexagon/include/asm/futex.h| 38 ++-
arch/ia64/include/asm/futex.h | 25 ++
arch/microblaze/include/asm/futex.h | 38 ++-
arch/mips/include/asm/futex.h | 25 ++
arch/parisc/include/asm/futex.h | 25 ++
arch/powerpc/include/asm/futex.h| 26 +++---
arch/s390/include/asm/futex.h | 23 +++-
arch/sh/include/asm/futex.h | 26 ++
arch/sparc/include/asm/futex_64.h | 26 +++---
arch/tile/include/asm/futex.h | 40 +++-
arch/x86/include/asm/futex.h| 40 +++-
arch/xtensa/include/asm/futex.h | 27 +++
include/asm-generic/futex.h | 50 ++--
kernel/futex.c | 39
20 files changed, 126 insertions(+), 470 deletions(-)
--- a/arch/alpha/include/asm/futex.h
+++ b/arch/alpha/include/asm/futex.h
@@ -29,18 +29,10 @@
: "r" (uaddr), "r"(oparg)
Re: [PATCH 4.9 27/33] futex: Remove duplicated code and fix undefined behaviour
On Fri, May 18, 2018 at 10:30:24AM +0200, Jiri Slaby wrote:
> On 05/18/2018, 10:16 AM, Greg Kroah-Hartman wrote:
> > 4.9-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Jiri Slaby <jsl...@suse.cz>
> >
> > commit 30d6e0a4190d37740e9447e4e4815f06992dd8c3 upstream.
> ...
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -1458,6 +1458,45 @@ out:
> > return ret;
> > }
> >
> > +static int futex_atomic_op_inuser(unsigned int encoded_op, u32 __user
> > *uaddr)
> > +{
> > + unsigned int op = (encoded_op & 0x7000) >> 28;
> > + unsigned int cmp =(encoded_op & 0x0f00) >> 24;
> > + int oparg = sign_extend32((encoded_op & 0x00fff000) >> 12, 12);
> > + int cmparg = sign_extend32(encoded_op & 0x0fff, 12);
>
> 12 is wrong here – wherever you apply this, you need also a follow-up fix:
> commit d70ef22892ed6c066e51e118b225923c9b74af34
> Author: Jiri Slaby <jsl...@suse.cz>
> Date: Thu Nov 30 15:35:44 2017 +0100
>
> futex: futex_wake_op, fix sign_extend32 sign bits
Thanks for letting me know, I've now queued it up to the needed trees.
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 27/33] futex: Remove duplicated code and fix undefined behaviour
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby <jsl...@suse.cz>
commit 30d6e0a4190d37740e9447e4e4815f06992dd8c3 upstream.
There is code duplicated over all architecture's headers for
futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
and comparison of the result.
Remove this duplication and leave up to the arches only the needed
assembly which is now in arch_futex_atomic_op_inuser.
This effectively distributes the Will Deacon's arm64 fix for undefined
behaviour reported by UBSAN to all architectures. The fix was done in
commit 5f16a046f8e1 (arm64: futex: Fix undefined behaviour with
FUTEX_OP_OPARG_SHIFT usage). Look there for an example dump.
And as suggested by Thomas, check for negative oparg too, because it was
also reported to cause undefined behaviour report.
Note that s390 removed access_ok check in d12a29703 ("s390/uaccess:
remove pointless access_ok() checks") as access_ok there returns true.
We introduce it back to the helper for the sake of simplicity (it gets
optimized away anyway).
Signed-off-by: Jiri Slaby <jsl...@suse.cz>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Acked-by: Russell King <rmk+ker...@armlinux.org.uk>
Acked-by: Michael Ellerman <m...@ellerman.id.au> (powerpc)
Acked-by: Heiko Carstens <heiko.carst...@de.ibm.com> [s390]
Acked-by: Chris Metcalf <cmetc...@mellanox.com> [for tile]
Reviewed-by: Darren Hart (VMware) <dvh...@infradead.org>
Reviewed-by: Will Deacon <will.dea...@arm.com> [core/arm64]
Cc: linux-m...@linux-mips.org
Cc: Rich Felker <dal...@libc.org>
Cc: linux-i...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: pet...@infradead.org
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Max Filippov <jcmvb...@gmail.com>
Cc: Paul Mackerras <pau...@samba.org>
Cc: sparcli...@vger.kernel.org
Cc: Jonas Bonn <jo...@southpole.se>
Cc: linux-s...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: Yoshinori Sato <ys...@users.sourceforge.jp>
Cc: linux-hexa...@vger.kernel.org
Cc: Helge Deller <del...@gmx.de>
Cc: "James E.J. Bottomley" <j...@parisc-linux.org>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Matt Turner <matts...@gmail.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: Fenghua Yu <fenghua...@intel.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: linux-xte...@linux-xtensa.org
Cc: Stefan Kristiansson <stefan.kristians...@saunalahti.fi>
Cc: openr...@lists.librecores.org
Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
Cc: Stafford Horne <sho...@gmail.com>
Cc: linux-arm-ker...@lists.infradead.org
Cc: Richard Henderson <r...@twiddle.net>
Cc: Chris Zankel <ch...@zankel.net>
Cc: Michal Simek <mon...@monstr.eu>
Cc: Tony Luck <tony.l...@intel.com>
Cc: linux-par...@vger.kernel.org
Cc: Vineet Gupta <vgu...@synopsys.com>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: Richard Kuo <r...@codeaurora.org>
Cc: linux-al...@vger.kernel.org
Cc: Martin Schwidefsky <schwidef...@de.ibm.com>
Cc: linuxppc-...@lists.ozlabs.org
Cc: "David S. Miller" <da...@davemloft.net>
Link: http://lkml.kernel.org/r/20170824073105.3901-1-jsl...@suse.cz
Cc: Ben Hutchings <ben.hutchi...@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/alpha/include/asm/futex.h | 26 +++---
arch/arc/include/asm/futex.h| 40 +++-
arch/arm/include/asm/futex.h| 26 ++
arch/arm64/include/asm/futex.h | 27 ++-
arch/frv/include/asm/futex.h|3 +-
arch/frv/kernel/futex.c | 27 ++-
arch/hexagon/include/asm/futex.h| 38 ++-
arch/ia64/include/asm/futex.h | 25 ++
arch/microblaze/include/asm/futex.h | 38 ++-
arch/mips/include/asm/futex.h | 25 ++
arch/parisc/include/asm/futex.h | 26 ++
arch/powerpc/include/asm/futex.h| 26 +++---
arch/s390/include/asm/futex.h | 23 +++-
arch/sh/include/asm/futex.h | 26 ++
arch/sparc/include/asm/futex_64.h | 26 +++---
arch/tile/include/asm/futex.h | 40 +++-
arch/x86/include/asm/futex.h| 40 +++-
arch/xtensa/include/asm/futex.h | 27 +++
include/asm-generic/futex.h | 50 ++--
kernel/futex.c | 39
20 files changed, 126 insertions(+), 472 deletions(-)
--- a/arch/alpha/include/asm/futex.h
+++ b/arch/alpha/include/asm/futex.h
@@ -29,18 +29,10 @@
: "r" (uaddr), "r"(oparg)
[PATCH 4.15 021/105] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs
4.15-stable review patch. If anyone has any objections, please let me know.
--
From: Evgeniy Didin <evgeniy.di...@synopsys.com>
commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream.
It was found that in IDMAC mode after soft-reset driver switches
to PIO mode.
That's what happens in case of DTO timeout overflow calculation failure:
1. soft-reset is called
2. driver restarts dma
3. descriptors states are checked, one of descriptor is owned by the IDMAC.
4. driver can't use DMA and then switches to PIO mode.
Failure was already fixed in:
https://www.spinics.net/lists/linux-mmc/msg48125.html.
Behaviour while soft-reset is not something we except or
even want to happen. So we switch from dw_mci_idmac_reset
to dw_mci_idmac_init, so descriptors are cleaned before starting dma.
And while at it explicitly zero des0 which otherwise might
contain garbage as being allocated by dmam_alloc_coherent().
Signed-off-by: Evgeniy Didin <evgeniy.di...@synopsys.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Ulf Hansson <ulf.hans...@linaro.org>
Cc: Andy Shevchenko <andy.shevche...@gmail.com>
Cc: Jisheng Zhang <jisheng.zh...@synaptics.com>
Cc: Shawn Lin <shawn@rock-chips.com>
Cc: Alexey Brodkin <abrod...@synopsys.com>
Cc: Eugeniy Paltsev <eugeniy.palt...@synopsys.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: <sta...@vger.kernel.org> # 4.4+
Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/mmc/host/dw_mmc.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -564,6 +564,7 @@ static int dw_mci_idmac_init(struct dw_m
(sizeof(struct idmac_desc_64addr) *
(i + 1))) >> 32;
/* Initialize reserved and buffer size fields to "0" */
+ p->des0 = 0;
p->des1 = 0;
p->des2 = 0;
p->des3 = 0;
@@ -586,6 +587,7 @@ static int dw_mci_idmac_init(struct dw_m
i++, p++) {
p->des3 = cpu_to_le32(host->sg_dma +
(sizeof(struct idmac_desc) * (i + 1)));
+ p->des0 = 0;
p->des1 = 0;
}
@@ -1801,8 +1803,8 @@ static bool dw_mci_reset(struct dw_mci *
}
if (host->use_dma == TRANS_MODE_IDMAC)
- /* It is also recommended that we reset and reprogram idmac */
- dw_mci_idmac_reset(host);
+ /* It is also required that we reinit idmac */
+ dw_mci_idmac_init(host);
ret = true;
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.14 021/101] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Evgeniy Didin <evgeniy.di...@synopsys.com>
commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream.
It was found that in IDMAC mode after soft-reset driver switches
to PIO mode.
That's what happens in case of DTO timeout overflow calculation failure:
1. soft-reset is called
2. driver restarts dma
3. descriptors states are checked, one of descriptor is owned by the IDMAC.
4. driver can't use DMA and then switches to PIO mode.
Failure was already fixed in:
https://www.spinics.net/lists/linux-mmc/msg48125.html.
Behaviour while soft-reset is not something we except or
even want to happen. So we switch from dw_mci_idmac_reset
to dw_mci_idmac_init, so descriptors are cleaned before starting dma.
And while at it explicitly zero des0 which otherwise might
contain garbage as being allocated by dmam_alloc_coherent().
Signed-off-by: Evgeniy Didin <evgeniy.di...@synopsys.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Ulf Hansson <ulf.hans...@linaro.org>
Cc: Andy Shevchenko <andy.shevche...@gmail.com>
Cc: Jisheng Zhang <jisheng.zh...@synaptics.com>
Cc: Shawn Lin <shawn@rock-chips.com>
Cc: Alexey Brodkin <abrod...@synopsys.com>
Cc: Eugeniy Paltsev <eugeniy.palt...@synopsys.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: <sta...@vger.kernel.org> # 4.4+
Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/mmc/host/dw_mmc.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -564,6 +564,7 @@ static int dw_mci_idmac_init(struct dw_m
(sizeof(struct idmac_desc_64addr) *
(i + 1))) >> 32;
/* Initialize reserved and buffer size fields to "0" */
+ p->des0 = 0;
p->des1 = 0;
p->des2 = 0;
p->des3 = 0;
@@ -586,6 +587,7 @@ static int dw_mci_idmac_init(struct dw_m
i++, p++) {
p->des3 = cpu_to_le32(host->sg_dma +
(sizeof(struct idmac_desc) * (i + 1)));
+ p->des0 = 0;
p->des1 = 0;
}
@@ -1801,8 +1803,8 @@ static bool dw_mci_reset(struct dw_mci *
}
if (host->use_dma == TRANS_MODE_IDMAC)
- /* It is also recommended that we reset and reprogram idmac */
- dw_mci_idmac_reset(host);
+ /* It is also required that we reinit idmac */
+ dw_mci_idmac_init(host);
ret = true;
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 07/67] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Evgeniy Didin <evgeniy.di...@synopsys.com>
commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream.
It was found that in IDMAC mode after soft-reset driver switches
to PIO mode.
That's what happens in case of DTO timeout overflow calculation failure:
1. soft-reset is called
2. driver restarts dma
3. descriptors states are checked, one of descriptor is owned by the IDMAC.
4. driver can't use DMA and then switches to PIO mode.
Failure was already fixed in:
https://www.spinics.net/lists/linux-mmc/msg48125.html.
Behaviour while soft-reset is not something we except or
even want to happen. So we switch from dw_mci_idmac_reset
to dw_mci_idmac_init, so descriptors are cleaned before starting dma.
And while at it explicitly zero des0 which otherwise might
contain garbage as being allocated by dmam_alloc_coherent().
Signed-off-by: Evgeniy Didin <evgeniy.di...@synopsys.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Ulf Hansson <ulf.hans...@linaro.org>
Cc: Andy Shevchenko <andy.shevche...@gmail.com>
Cc: Jisheng Zhang <jisheng.zh...@synaptics.com>
Cc: Shawn Lin <shawn@rock-chips.com>
Cc: Alexey Brodkin <abrod...@synopsys.com>
Cc: Eugeniy Paltsev <eugeniy.palt...@synopsys.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: <sta...@vger.kernel.org> # 4.4+
Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/mmc/host/dw_mmc.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -490,6 +490,7 @@ static int dw_mci_idmac_init(struct dw_m
(sizeof(struct idmac_desc_64addr) *
(i + 1))) >> 32;
/* Initialize reserved and buffer size fields to "0" */
+ p->des0 = 0;
p->des1 = 0;
p->des2 = 0;
p->des3 = 0;
@@ -512,6 +513,7 @@ static int dw_mci_idmac_init(struct dw_m
i++, p++) {
p->des3 = cpu_to_le32(host->sg_dma +
(sizeof(struct idmac_desc) * (i + 1)));
+ p->des0 = 0;
p->des1 = 0;
}
@@ -2878,8 +2880,8 @@ static bool dw_mci_reset(struct dw_mci *
}
if (host->use_dma == TRANS_MODE_IDMAC)
- /* It is also recommended that we reset and reprogram idmac */
- dw_mci_idmac_reset(host);
+ /* It is also required that we reinit idmac */
+ dw_mci_idmac_init(host);
ret = true;
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.4 07/43] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Evgeniy Didin <evgeniy.di...@synopsys.com>
commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream.
It was found that in IDMAC mode after soft-reset driver switches
to PIO mode.
That's what happens in case of DTO timeout overflow calculation failure:
1. soft-reset is called
2. driver restarts dma
3. descriptors states are checked, one of descriptor is owned by the IDMAC.
4. driver can't use DMA and then switches to PIO mode.
Failure was already fixed in:
https://www.spinics.net/lists/linux-mmc/msg48125.html.
Behaviour while soft-reset is not something we except or
even want to happen. So we switch from dw_mci_idmac_reset
to dw_mci_idmac_init, so descriptors are cleaned before starting dma.
And while at it explicitly zero des0 which otherwise might
contain garbage as being allocated by dmam_alloc_coherent().
Signed-off-by: Evgeniy Didin <evgeniy.di...@synopsys.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Ulf Hansson <ulf.hans...@linaro.org>
Cc: Andy Shevchenko <andy.shevche...@gmail.com>
Cc: Jisheng Zhang <jisheng.zh...@synaptics.com>
Cc: Shawn Lin <shawn@rock-chips.com>
Cc: Alexey Brodkin <abrod...@synopsys.com>
Cc: Eugeniy Paltsev <eugeniy.palt...@synopsys.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: <sta...@vger.kernel.org> # 4.4+
Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/mmc/host/dw_mmc.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -619,6 +619,7 @@ static int dw_mci_idmac_init(struct dw_m
(sizeof(struct idmac_desc_64addr) *
(i + 1))) >> 32;
/* Initialize reserved and buffer size fields to "0" */
+ p->des0 = 0;
p->des1 = 0;
p->des2 = 0;
p->des3 = 0;
@@ -640,6 +641,7 @@ static int dw_mci_idmac_init(struct dw_m
i++, p++) {
p->des3 = cpu_to_le32(host->sg_dma +
(sizeof(struct idmac_desc) * (i + 1)));
+ p->des0 = 0;
p->des1 = 0;
}
@@ -2807,8 +2809,8 @@ static bool dw_mci_reset(struct dw_mci *
}
if (host->use_dma == TRANS_MODE_IDMAC)
- /* It is also recommended that we reset and reprogram idmac */
- dw_mci_idmac_reset(host);
+ /* It is also required that we reinit idmac */
+ dw_mci_idmac_init(host);
ret = true;
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.4 15/56] usb: Make sure usb/phy/of gets built-in
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Alexey Brodkin <alexey.brod...@synopsys.com> commit 3d6159640da9c9175d1ca42f151fc1a14caded59 upstream. DWC3 driver uses of_usb_get_phy_mode() which is implemented in drivers/usb/phy/of.c and in bare minimal configuration it might not be pulled in kernel binary. In case of ARC or ARM this could be easily reproduced with "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m. On building all ends-up with: -->8-- Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Building modules, stage 2. MODPOST 5 modules ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 -->8-- Signed-off-by: Alexey Brodkin <abrod...@synopsys.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Masahiro Yamada <yamada.masah...@socionext.com> Cc: Geert Uytterhoeven <geert+rene...@glider.be> Cc: Nicolas Pitre <nicolas.pi...@linaro.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Felipe Balbi <ba...@kernel.org> Cc: Felix Fietkau <n...@nbd.name> Cc: Jeremy Kerr <j...@ozlabs.org> Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/Makefile |1 + 1 file changed, 1 insertion(+) --- a/drivers/Makefile +++ b/drivers/Makefile @@ -98,6 +98,7 @@ obj-$(CONFIG_USB_PHY) += usb/ obj-$(CONFIG_USB) += usb/ obj-$(CONFIG_PCI) += usb/ obj-$(CONFIG_USB_GADGET) += usb/ +obj-$(CONFIG_OF) += usb/ obj-$(CONFIG_SERIO)+= input/serio/ obj-$(CONFIG_GAMEPORT) += input/gameport/ obj-$(CONFIG_INPUT)+= input/ ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 17/80] usb: Make sure usb/phy/of gets built-in
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Alexey Brodkin <alexey.brod...@synopsys.com> commit 3d6159640da9c9175d1ca42f151fc1a14caded59 upstream. DWC3 driver uses of_usb_get_phy_mode() which is implemented in drivers/usb/phy/of.c and in bare minimal configuration it might not be pulled in kernel binary. In case of ARC or ARM this could be easily reproduced with "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m. On building all ends-up with: -->8-- Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Building modules, stage 2. MODPOST 5 modules ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 -->8-- Signed-off-by: Alexey Brodkin <abrod...@synopsys.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Masahiro Yamada <yamada.masah...@socionext.com> Cc: Geert Uytterhoeven <geert+rene...@glider.be> Cc: Nicolas Pitre <nicolas.pi...@linaro.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Felipe Balbi <ba...@kernel.org> Cc: Felix Fietkau <n...@nbd.name> Cc: Jeremy Kerr <j...@ozlabs.org> Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/Makefile |1 + 1 file changed, 1 insertion(+) --- a/drivers/Makefile +++ b/drivers/Makefile @@ -101,6 +101,7 @@ obj-$(CONFIG_USB_PHY) += usb/ obj-$(CONFIG_USB) += usb/ obj-$(CONFIG_PCI) += usb/ obj-$(CONFIG_USB_GADGET) += usb/ +obj-$(CONFIG_OF) += usb/ obj-$(CONFIG_SERIO)+= input/serio/ obj-$(CONFIG_GAMEPORT) += input/gameport/ obj-$(CONFIG_INPUT)+= input/ ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.10 18/93] usb: Make sure usb/phy/of gets built-in
4.10-stable review patch. If anyone has any objections, please let me know. -- From: Alexey Brodkin <alexey.brod...@synopsys.com> commit 3d6159640da9c9175d1ca42f151fc1a14caded59 upstream. DWC3 driver uses of_usb_get_phy_mode() which is implemented in drivers/usb/phy/of.c and in bare minimal configuration it might not be pulled in kernel binary. In case of ARC or ARM this could be easily reproduced with "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m. On building all ends-up with: -->8-- Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Building modules, stage 2. MODPOST 5 modules ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 -->8-- Signed-off-by: Alexey Brodkin <abrod...@synopsys.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Masahiro Yamada <yamada.masah...@socionext.com> Cc: Geert Uytterhoeven <geert+rene...@glider.be> Cc: Nicolas Pitre <nicolas.pi...@linaro.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Felipe Balbi <ba...@kernel.org> Cc: Felix Fietkau <n...@nbd.name> Cc: Jeremy Kerr <j...@ozlabs.org> Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/Makefile |1 + 1 file changed, 1 insertion(+) --- a/drivers/Makefile +++ b/drivers/Makefile @@ -101,6 +101,7 @@ obj-$(CONFIG_USB_PHY) += usb/ obj-$(CONFIG_USB) += usb/ obj-$(CONFIG_PCI) += usb/ obj-$(CONFIG_USB_GADGET) += usb/ +obj-$(CONFIG_OF) += usb/ obj-$(CONFIG_SERIO)+= input/serio/ obj-$(CONFIG_GAMEPORT) += input/gameport/ obj-$(CONFIG_INPUT)+= input/ ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.11 019/114] usb: Make sure usb/phy/of gets built-in
4.11-stable review patch. If anyone has any objections, please let me know. -- From: Alexey Brodkin <alexey.brod...@synopsys.com> commit 3d6159640da9c9175d1ca42f151fc1a14caded59 upstream. DWC3 driver uses of_usb_get_phy_mode() which is implemented in drivers/usb/phy/of.c and in bare minimal configuration it might not be pulled in kernel binary. In case of ARC or ARM this could be easily reproduced with "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m. On building all ends-up with: -->8-- Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready Building modules, stage 2. MODPOST 5 modules ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 -->8-- Signed-off-by: Alexey Brodkin <abrod...@synopsys.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Masahiro Yamada <yamada.masah...@socionext.com> Cc: Geert Uytterhoeven <geert+rene...@glider.be> Cc: Nicolas Pitre <nicolas.pi...@linaro.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Felipe Balbi <ba...@kernel.org> Cc: Felix Fietkau <n...@nbd.name> Cc: Jeremy Kerr <j...@ozlabs.org> Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/Makefile |1 + 1 file changed, 1 insertion(+) --- a/drivers/Makefile +++ b/drivers/Makefile @@ -104,6 +104,7 @@ obj-$(CONFIG_USB_PHY) += usb/ obj-$(CONFIG_USB) += usb/ obj-$(CONFIG_PCI) += usb/ obj-$(CONFIG_USB_GADGET) += usb/ +obj-$(CONFIG_OF) += usb/ obj-$(CONFIG_SERIO)+= input/serio/ obj-$(CONFIG_GAMEPORT) += input/gameport/ obj-$(CONFIG_INPUT)+= input/ ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces
On Mon, Mar 13, 2017 at 03:14:12PM -0700, Till Smejkal wrote:
There's no way with that many cc: lists and people that this is really
making it through very many people's filters and actually on a mailing
list. Please trim them down.
Minor sysfs questions/issues:
> +struct vas {
> + struct kobject kobj;/* < the internal kobject that we use *
> + * for reference counting and sysfs *
> + * handling.*/
> +
> + int id; /* < ID */
> + char name[VAS_MAX_NAME_LENGTH]; /* < name */
The kobject has a name, why not use that?
> +
> + struct mutex mtx; /* < lock for parallel access.*/
> +
> + struct mm_struct *mm; /* < a partial memory map containing *
> + * all mappings of this VAS.*/
> +
> + struct list_head link; /* < the link in the global VAS list. */
> + struct rcu_head rcu;/* < the RCU helper used for *
> + * asynchronous VAS deletion. */
> +
> + u16 refcount; /* < how often is the VAS attached. */
The kobject has a refcount, use that? Don't have 2 refcounts in the
same structure, that way lies madness. And bugs, lots of bugs...
And if this really is a refcount (hint, I don't think it is), you should
use the refcount_t type.
> +/**
> + * The sysfs structure we need to handle attributes of a VAS.
> + **/
> +struct vas_sysfs_attr {
> + struct attribute attr;
> + ssize_t (*show)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> + char *buf);
> + ssize_t (*store)(struct vas *vas, struct vas_sysfs_attr *vsattr,
> + const char *buf, size_t count);
> +};
> +
> +#define VAS_SYSFS_ATTR(NAME, MODE, SHOW, STORE)
> \
> +static struct vas_sysfs_attr vas_sysfs_attr_##NAME = \
> + __ATTR(NAME, MODE, SHOW, STORE)
__ATTR_RO and __ATTR_RW should work better for you. If you really need
this.
Oh, and where is the Documentation/ABI/ updates to try to describe the
sysfs structure and files? Did I miss that in the series?
> +static ssize_t __show_vas_name(struct vas *vas, struct vas_sysfs_attr
> *vsattr,
> +char *buf)
> +{
> + return scnprintf(buf, PAGE_SIZE, "%s", vas->name);
It's a page size, just use sprintf() and be done with it. No need to
ever check, you "know" it will be correct.
Also, what about a trailing '\n' for these attributes?
Oh wait, why have a name when the kobject name is already there in the
directory itself? Do you really need this?
> +/**
> + * The ktype data structure representing a VAS.
> + **/
> +static struct kobj_type vas_ktype = {
> + .sysfs_ops = _sysfs_ops,
> + .release = __vas_release,
Why the odd __vas* naming? What's wrong with vas_release?
> + .default_attrs = vas_default_attr,
> +};
> +
> +
> +/***
> + * Internally visible functions
> + ***/
> +
> +/**
> + * Working with the global VAS list.
> + **/
> +static inline void vas_remove(struct vas *vas)
You have a ton of inline functions, for no good reason. Make them all
"real" functions please. Unless you can measure the size/speed
differences? If so, please say so.
thanks,
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.4 01/20] ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vineet Gupta <vineet.gup...@synopsys.com>
commit a524c218bc94c705886a0e0fedeee45d1931da32 upstream.
Reported-by: Jo-Philipp Wich <j...@mein.io>
Fixes: 9aed02feae57bf7 ("ARC: [arcompact] handle unaligned access delay slot")
Cc: linux-ker...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta <vgu...@synopsys.com>
Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/arc/kernel/unaligned.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arc/kernel/unaligned.c
+++ b/arch/arc/kernel/unaligned.c
@@ -243,7 +243,7 @@ int misaligned_fixup(unsigned long addre
/* clear any remanants of delay slot */
if (delay_mode(regs)) {
- regs->ret = regs->bta ~1U;
+ regs->ret = regs->bta & ~1U;
regs->status32 &= ~STATUS_DE_MASK;
} else {
regs->ret += state.instr_len;
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.9 12/60] ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Vineet Gupta <vineet.gup...@synopsys.com>
commit a524c218bc94c705886a0e0fedeee45d1931da32 upstream.
Reported-by: Jo-Philipp Wich <j...@mein.io>
Fixes: 9aed02feae57bf7 ("ARC: [arcompact] handle unaligned access delay slot")
Cc: linux-ker...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Vineet Gupta <vgu...@synopsys.com>
Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/arc/kernel/unaligned.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arc/kernel/unaligned.c
+++ b/arch/arc/kernel/unaligned.c
@@ -243,7 +243,7 @@ int misaligned_fixup(unsigned long addre
/* clear any remanants of delay slot */
if (delay_mode(regs)) {
- regs->ret = regs->bta ~1U;
+ regs->ret = regs->bta & ~1U;
regs->status32 &= ~STATUS_DE_MASK;
} else {
regs->ret += state.instr_len;
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/9] Move dma_ops from archdata into struct device
On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote: > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to > transfer data between memory and PCIe adapter. Because of performance > reasons it is important that the CPU cache is not flushed when such > drivers transfer data. Make this possible by allowing these drivers to > override the dma_map_ops pointer. Additionally, introduce the function > set_dma_ops() that will be used by a later patch in this series. When you say things like "additionally", that's a huge flag that this needs to be split up into multiple patches. No need to add set_dma_ops() here in this patch. And I'd argue that it should be dma_ops_set(), and dma_ops_get(), just to keep the namespace sane, but that's probably a different set of patches... thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/9] Move dma_ops from archdata into struct device
On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> transfer data between memory and PCIe adapter. Because of performance
> reasons it is important that the CPU cache is not flushed when such
> drivers transfer data. Make this possible by allowing these drivers to
> override the dma_map_ops pointer. Additionally, introduce the function
> set_dma_ops() that will be used by a later patch in this series.
>
> Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Cc: Aurelien Jacquiot <a-jacqu...@ti.com>
> Cc: Catalin Marinas <catalin.mari...@arm.com>
> Cc: Chris Zankel <ch...@zankel.net>
> Cc: David Howells <dhowe...@redhat.com>
> Cc: David S. Miller <da...@davemloft.net>
> Cc: Fenghua Yu <fenghua...@intel.com>
> Cc: Geert Uytterhoeven <ge...@linux-m68k.org>
> Cc: Geoff Levand <ge...@infradead.org>
> Cc: H. Peter Anvin <h...@zytor.com>
> Cc: Haavard Skinnemoen <hskinnem...@gmail.com>
> Cc: Hans-Christian Egtvedt <egtv...@samfundet.no>
> Cc: Helge Deller <del...@gmx.de>
> Cc: Ingo Molnar <mi...@redhat.com>
> Cc: James E.J. Bottomley <j...@parisc-linux.org>
> Cc: Jesper Nilsson <jesper.nils...@axis.com>
> Cc: Joerg Roedel <j...@8bytes.org>
> Cc: Jon Mason <jdma...@kudzu.us>
> Cc: Jonas Bonn <jo...@southpole.se>
> Cc: Ley Foon Tan <lf...@altera.com>
> Cc: Mark Salter <msal...@redhat.com>
> Cc: Max Filippov <jcmvb...@gmail.com>
> Cc: Mikael Starvik <star...@axis.com>
> Cc: Muli Ben-Yehuda <mu...@mulix.org>
> Cc: Rich Felker <dal...@libc.org>
> Cc: Russell King <li...@armlinux.org.uk>
> Cc: Stafford Horne <sho...@gmail.com>
> Cc: Stefan Kristiansson <stefan.kristians...@saunalahti.fi>
> Cc: Thomas Gleixner <t...@linutronix.de>
> Cc: Tony Luck <tony.l...@intel.com>
> Cc: Will Deacon <will.dea...@arm.com>
> Cc: x...@kernel.org
> Cc: Yoshinori Sato <ys...@users.sourceforge.jp>
> Cc: adi-buildroot-de...@lists.sourceforge.net
> Cc: io...@lists.linux-foundation.org
> Cc: linux-al...@vger.kernel.org
> Cc: linux-am33-l...@redhat.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-c6x-...@linux-c6x.org
> Cc: linux-cris-ker...@axis.com
> Cc: linux-hexa...@vger.kernel.org
> Cc: linux-i...@vger.kernel.org
> Cc: linux-m...@lists.linux-m68k.org
> Cc: linux-me...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: linux-par...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-r...@vger.kernel.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux-xte...@linux-xtensa.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: nios2-...@lists.rocketboards.org
> Cc: openr...@lists.librecores.org
> Cc: sparcli...@vger.kernel.org
> Cc: uclinux-h8-de...@lists.sourceforge.jp
That's a crazy cc: list, you should break this up into smaller pieces,
otherwise it's going to bounce...
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 491b4c0ca633..c7cb225d36b0 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -885,6 +885,8 @@ struct dev_links_info {
> * a higher-level representation of the device.
> */
> struct device {
> + const struct dma_map_ops *dma_ops; /* See also get_dma_ops() */
> +
> struct device *parent;
>
> struct device_private *p;
Why not put this new pointer down with the other dma fields in this
structure? Any specific reason it needs to be first?
thanks,
greg k-h
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 4.4 099/118] ARC: uaccess: get_user to zero out dest in cause of fault
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vineet Gupta <vineet.gup...@synopsys.com>
commit 05d9d0b96e53c52a113fd783c0c97c830c8dc7af upstream.
Al reported potential issue with ARC get_user() as it wasn't clearing
out destination pointer in case of fault due to bad address etc.
Verified using following
| {
| u32 bogus1 = 0xdeadbeef;
| u64 bogus2 = 0xdead;
| int rc1, rc2;
|
| pr_info("Orig values %x %llx\n", bogus1, bogus2);
| rc1 = get_user(bogus1, (u32 __user *)0x4000);
| rc2 = get_user(bogus2, (u64 __user *)0x5000);
| pr_info("access %d %d, new values %x %llx\n",
| rc1, rc2, bogus1, bogus2);
| }
| [ARCLinux]# insmod /mnt/kernel-module/qtn.ko
| Orig values deadbeef dead
| access -14 -14, new values 0 0
Reported-by: Al Viro <v...@zeniv.linux.org.uk>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Vineet Gupta <vgu...@synopsys.com>
Signed-off-by: Al Viro <v...@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
arch/arc/include/asm/uaccess.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/arch/arc/include/asm/uaccess.h
+++ b/arch/arc/include/asm/uaccess.h
@@ -83,7 +83,10 @@
"2: ;nop\n" \
" .section .fixup, \"ax\"\n" \
" .align 4\n" \
- "3: mov %0, %3\n" \
+ "3: # return -EFAULT\n" \
+ " mov %0, %3\n" \
+ " # zero out dst ptr\n" \
+ " mov %1, 0\n" \
" j 2b\n" \
" .previous\n"\
" .section __ex_table, \"a\"\n" \
@@ -101,7 +104,11 @@
"2: ;nop\n" \
" .section .fixup, \"ax\"\n" \
" .align 4\n" \
- "3: mov %0, %3\n" \
+ "3: # return -EFAULT\n" \
+ " mov %0, %3\n" \
+ " # zero out dst ptr\n" \
+ " mov %1, 0\n" \
+ " mov %R1, 0\n" \
" j 2b\n" \
" .previous\n"\
" .section __ex_table, \"a\"\n" \
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
