Re: [PATCH] opal-elog: Fix opal-elog interrupt handler
Alistair Popple alist...@popple.id.au writes:
The conversion of opal events to a proper irqchip means that handlers
are called until the relevant opal event has been cleared by
processing it. Events that queue work should therefore use a threaded
handler to mask the event until processing is complete.
Signed-off-by: Alistair Popple alist...@popple.id.au
Tested-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/opal-elog.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c
b/arch/powerpc/platforms/powernv/opal-elog.c
index 4949ef0..37f959b 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -237,7 +237,7 @@ static struct elog_obj *create_elog_obj(uint64_t id,
size_t size, uint64_t type)
return elog;
}
-static void elog_work_fn(struct work_struct *work)
+static irqreturn_t elog_event(int irq, void *data)
{
__be64 size;
__be64 id;
@@ -251,7 +251,7 @@ static void elog_work_fn(struct work_struct *work)
rc = opal_get_elog_size(id, size, type);
if (rc != OPAL_SUCCESS) {
pr_err(ELOG: OPAL log info read failed\n);
- return;
+ return IRQ_HANDLED;
}
elog_size = be64_to_cpu(size);
@@ -270,16 +270,10 @@ static void elog_work_fn(struct work_struct *work)
* entries.
*/
if (kset_find_obj(elog_kset, name))
- return;
+ return IRQ_HANDLED;
create_elog_obj(log_id, elog_size, elog_type);
-}
-
-static DECLARE_WORK(elog_work, elog_work_fn);
-static irqreturn_t elog_event(int irq, void *data)
-{
- schedule_work(elog_work);
return IRQ_HANDLED;
}
@@ -304,8 +298,8 @@ int __init opal_elog_init(void)
return irq;
}
- rc = request_irq(irq, elog_event,
- IRQ_TYPE_LEVEL_HIGH, opal-elog, NULL);
+ rc = request_threaded_irq(irq, NULL, elog_event,
+ IRQF_TRIGGER_HIGH | IRQF_ONESHOT, opal-elog, NULL);
if (rc) {
pr_err(%s: Can't request OPAL event irq (%d)\n,
__func__, rc);
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6] [RFC] crypto/testmgr: add null test for 842 algorithm
On Thu, Jul 02, 2015 at 03:41:19PM -0700, Nishanth Aravamudan wrote: Currently, when the nx-842-pseries driver loads, the following message is emitted: alg: No test for 842 (842-nx) It seems like the simplest way to fix this message (other than adding a proper test) is to just insert the null test into the list in the testmgr. Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com Please add some real test vectors instead. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: default ioremap_*() variant defintions
On Fri, Jul 3, 2015 at 11:17 AM, Luis R. Rodriguez mcg...@suse.com wrote:
The 0-day build bot detected a build issue on a patch not upstream yet that
makes a driver use iorempa_uc(), this call is now upstream but we have no
drivers yet using it, the patch in question makes the atyfb framebuffer driver
use it. The build issue was the lack of the ioremap_uc() call being
implemented
on some non-x86 architectures. I *thought* I had added boiler plate code to
map
the ioremap_uc() call to ioremap_nocache() for archs that do not already
define
their own iorempa_uc() call, but upon further investigation it seems that was
not the case but found that this may be a bit different issue altogether.
The way include/asm-generic/io.h works for ioremap() calls and its variants
is:
#ifndef CONFIG_MMU
#ifndef ioremap
#define ioremap ioremap
static inline void __iomem *ioremap(phys_addr_t offset, size_t size)
{
return (void __iomem *)(unsigned long)offset;
}
#endif
...
#define iounmap iounmap
static inline void iounmap(void __iomem *addr)
{
}
#endif
#endif /* CONFIG_MMU */
That's the gist of it, but the catch here is the ioremap_*() variants and
where
they are defined. The first variant is ioremap_nocache() and then all other
variants by default map to this one. We've been stuffing the variant
definitions
within the #ifndef CONFIG_MMU and I don't think we should be as otherwise each
and everyone's archs will have to add their own variant default map to the
default ioremap_nocache() or whatever. That's exaclty what we have to day, and
from what I gather the purpose of the variant boiler plate is lost. I think
we should keep the ioremap() and ioreunmap() tucked under the CONFIG_MMU
but not the variants. For instance to address the build issue for ioremap_uc()
we either define ioremap_uc() for all archs or do something like this:
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index f56094cfdeff..6e5e80d5dd0c 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -769,14 +769,6 @@ static inline void __iomem *ioremap_nocache(phys_addr_t
offset, size_t size)
}
#endif
-#ifndef ioremap_uc
-#define ioremap_uc ioremap_uc
-static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
-{
- return ioremap_nocache(offset, size);
-}
-#endif
-
#ifndef ioremap_wc
#define ioremap_wc ioremap_wc
static inline void __iomem *ioremap_wc(phys_addr_t offset, size_t size)
@@ -802,6 +794,14 @@ static inline void iounmap(void __iomem *addr)
#endif
#endif /* CONFIG_MMU */
+#ifndef ioremap_uc
+#define ioremap_uc ioremap_uc
+static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
+{
+ return ioremap_nocache(offset, size);
+}
+#endif
+
#ifdef CONFIG_HAS_IOPORT_MAP
#ifndef CONFIG_GENERIC_IOMAP
#ifndef ioport_map
This builds on x86 and other archs now and I can verify that the default
boilerplate code is not used on x86. One small caveat:
I have no idea why its not picking up asm-generic ioremap_uc() for x86,
x86 does not use include/asm-generic/io.h. That's a helper-include
for archs that want to use it, but it's incomplete, see the patch
referenced below...
although this is the right thing to do the guard should not work as we never
define ioremap_uc() as a macro but we do as an exported symbol. The way
archs do their ioremap calls is they define externs and then they include
asm-generic to pick up the things they don't define. In the extern calls
for ioremap_uc() we never add a define there. Adding a simple one line
#define right after the extern declaration to itself should suffice to
fix paranoia but curious why this does work as-is right now.
I'd like review and consensus from other architecture folks if this is
the Right Thing To Do (TM) and if it is decide how we want to fix this.
For instance my preference would be to just add this fix as-is after
we've figured out the guard thing above, and then define these variants
in the documentation on the asm-generic file as safe to not have, and
safe to map to the default ioremap call. If you don't have a safe call
like this we should set out different expectations, for instance having
it depend on Kconfig symbol and then drivers depend on it, archs then
implement the symbols and can HAVE_ARCH_FOO. If everyone agrees with
this then there is quite a bit of cleanup possible as tons of archs do
tons of their own variant mapping definitions.
We're also discussing this issue in the patch here:
https://lkml.org/lkml/2015/6/22/98
[PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases:
Russell mentioned wanting to fix up ioremap_wt() for ARM [1], after
which I would look to re-spin this patch with the interface proposed
by Christoph [2].
[1]: https://lkml.org/lkml/2015/7/1/125
[2]: https://lkml.org/lkml/2015/6/22/391
___
Linuxppc-dev mailing list
Re: [PATCH SLOF v4 1/4] disk-label: simplify gpt-prep-partition? routine
Alexey Kardashevskiy a...@ozlabs.ru writes: On 07/02/2015 09:35 PM, Nikunj A Dadhania wrote: Signed-off-by: Nikunj A Dadhania nik...@linux.vnet.ibm.com Reviewed-by: Thomas Huth th...@redhat.com If it does not change SLOF behaviour in any way (and it does not, right?), It does not. it would be nice to see in the commit log. --- slof/fs/packages/disk-label.fs | 41 +++-- 1 file changed, 15 insertions(+), 26 deletions(-) diff --git a/slof/fs/packages/disk-label.fs b/slof/fs/packages/disk-label.fs index fe1c25e..f1f083a 100644 --- a/slof/fs/packages/disk-label.fs +++ b/slof/fs/packages/disk-label.fs @@ -352,42 +352,31 @@ CONSTANT /gpt-part-entry drop 0 ; -\ Check for GPT PReP partition GUID -9E1A2D38 CONSTANT GPT-PREP-PARTITION-1 -C612 CONSTANT GPT-PREP-PARTITION-2 -4316 CONSTANT GPT-PREP-PARTITION-3 -AA26 CONSTANT GPT-PREP-PARTITION-4 -8B49521E5A8B CONSTANT GPT-PREP-PARTITION-5 +\ Check for GPT PReP partition GUID. Only first 3 blocks are +\ byte-swapped treating last two blocks as contigous for simplifying +\ comparison +9E1A2D38CONSTANT GPT-PREP-PARTITION-1 +C612CONSTANT GPT-PREP-PARTITION-2 +4316CONSTANT GPT-PREP-PARTITION-3 +AA268B49521E5A8BCONSTANT GPT-PREP-PARTITION-4 : gpt-prep-partition? ( -- true|false ) - block gpt-part-entrypart-type-guid l@-le GPT-PREP-PARTITION-1 = IF - block gpt-part-entrypart-type-guid 4 + w@-le - GPT-PREP-PARTITION-2 = IF - block gpt-part-entrypart-type-guid 6 + w@-le - GPT-PREP-PARTITION-3 = IF -block gpt-part-entrypart-type-guid 8 + w@ -GPT-PREP-PARTITION-4 = IF - block gpt-part-entrypart-type-guid a + w@ - block gpt-part-entrypart-type-guid c + l@ swap lxjoin - GPT-PREP-PARTITION-5 = IF - TRUE EXIT - THEN -THEN - THEN - THEN - THEN - FALSE + block gpt-part-entrypart-type-guid + dup l@-le GPT-PREP-PARTITION-1 IF drop false EXIT THEN + dup 4 + w@-le GPT-PREP-PARTITION-2 IF drop false EXIT THEN + dup 6 + w@-le GPT-PREP-PARTITION-3 IF drop false EXIT THEN + 8 + x@GPT-PREP-PARTITION-4 = ; : load-from-gpt-prep-partition ( addr -- size ) - no-gpt? IF drop FALSE EXIT THEN + no-gpt? IF drop false EXIT THEN debug-disk-label? IF cr . GPT partition found cr THEN 1 read-sector block gptpart-entry-lba l@-le block-size * to seek-pos block gptpart-entry-size l@-le to gpt-part-size - block gptnum-part-entry l@-le dup 0= IF FALSE EXIT THEN + block gptnum-part-entry l@-le dup 0= IF false EXIT THEN 1+ 1 ?DO seek-pos 0 seek drop block gpt-part-size read drop gpt-prep-partition? IF @@ -405,7 +394,7 @@ AA26 CONSTANT GPT-PREP-PARTITION-4 THEN seek-pos gpt-part-size i * + to seek-pos LOOP - FALSE + false ; \ Extract the boot loader path from a bootinfo.txt file -- Alexey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
