* [PATCH 0/4] ARM: davinci: Remove DMA resources for MMC/SPI
From: Sekhar Nori @ 2016-10-01 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160928103530.15291-1-peter.ujfalusi@ti.com>
On Wednesday 28 September 2016 04:05 PM, Peter Ujfalusi wrote:
> Hi,
>
> The drivers for davinci MMC and SPI have been converted to the new DMAengine API
> and no longer rely on the IORESOURCE_DMA.
> This is the case for at least one release cycle so now we can remove the
> IORESOURCE_DMA for these devices.
Hi Peter, applied to v4.10/cleanup branch of my tree. Thanks!
~Sekhar
^ permalink raw reply
* [PATCH 1/3] Revert "ACPI, PCI, IRQ: reduce static IRQ array size to 16"
From: Sinan Kaya @ 2016-10-01 17:46 UTC (permalink / raw)
To: linux-arm-kernel
This reverts commit 5c5087a55390 ("ACPI,PCI,IRQ: reduce static IRQ array
size to 16").
The code maintains a fixed size array for IRQ penalties. The array
gets updated by external calls such as acpi_penalize_sci_irq,
acpi_penalize_isa_irq to reflect the actual interrupt usage of the
system. Since the IRQ distribution is platform specific, this is
not known ahead of time. The IRQs get updated based on the SCI
interrupt number BIOS has chosen or the ISA IRQs that were assigned
to existing peripherals.
By the time ACPI gets initialized, this code tries to determine an
IRQ number based on penalty values in this array. It will try to locate
the IRQ with the least penalty assignment so that interrupt sharing is
avoided if possible.
A couple of notes about the external APIs:
1. These API can be called before the ACPI is started. Therefore, one
cannot assume that the PCI link objects are initialized for calculating
penalties.
2. The polarity and trigger information passed via the
acpi_penalize_sci_irq from the BIOS may not match what the IRQ subsystem
is reporting as the call might have been placed before the IRQ is
registered by the interrupt subsystem.
The previous change was in the direction to remove these external API and
try to calculate the penalties at runtime for the ISA path as well. This
didn't work out well with the existing platforms.
Restoring the old behavior for IRQ < 256 and the new behavior will remain
effective for IRQ >= 256.
Link: http://www.spinics.net/lists/linux-pci/msg54599.html
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/acpi/pci_link.c | 35 ++++++++++++++++++-----------------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index c983bf7..f3792f4 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -438,6 +438,7 @@ static int acpi_pci_link_set(struct acpi_pci_link *link, int irq)
* enabled system.
*/
+#define ACPI_MAX_IRQS 256
#define ACPI_MAX_ISA_IRQS 16
#define PIRQ_PENALTY_PCI_POSSIBLE (16*16)
@@ -446,7 +447,7 @@ static int acpi_pci_link_set(struct acpi_pci_link *link, int irq)
#define PIRQ_PENALTY_ISA_USED (16*16*16*16*16)
#define PIRQ_PENALTY_ISA_ALWAYS (16*16*16*16*16*16)
-static int acpi_isa_irq_penalty[ACPI_MAX_ISA_IRQS] = {
+static int acpi_irq_penalty[ACPI_MAX_IRQS] = {
PIRQ_PENALTY_ISA_ALWAYS, /* IRQ0 timer */
PIRQ_PENALTY_ISA_ALWAYS, /* IRQ1 keyboard */
PIRQ_PENALTY_ISA_ALWAYS, /* IRQ2 cascade */
@@ -511,7 +512,7 @@ static int acpi_irq_get_penalty(int irq)
}
if (irq < ACPI_MAX_ISA_IRQS)
- return penalty + acpi_isa_irq_penalty[irq];
+ return penalty + acpi_irq_penalty[irq];
penalty += acpi_irq_pci_sharing_penalty(irq);
return penalty;
@@ -538,14 +539,14 @@ int __init acpi_irq_penalty_init(void)
for (i = 0; i < link->irq.possible_count; i++) {
if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
- acpi_isa_irq_penalty[link->irq.
+ acpi_irq_penalty[link->irq.
possible[i]] +=
penalty;
}
} else if (link->irq.active &&
- (link->irq.active < ACPI_MAX_ISA_IRQS)) {
- acpi_isa_irq_penalty[link->irq.active] +=
+ (link->irq.active < ACPI_MAX_IRQS)) {
+ acpi_irq_penalty[link->irq.active] +=
PIRQ_PENALTY_PCI_POSSIBLE;
}
}
@@ -828,7 +829,7 @@ static void acpi_pci_link_remove(struct acpi_device *device)
}
/*
- * modify acpi_isa_irq_penalty[] from cmdline
+ * modify acpi_irq_penalty[] from cmdline
*/
static int __init acpi_irq_penalty_update(char *str, int used)
{
@@ -837,24 +838,24 @@ static int __init acpi_irq_penalty_update(char *str, int used)
for (i = 0; i < 16; i++) {
int retval;
int irq;
- int new_penalty;
retval = get_option(&str, &irq);
if (!retval)
break; /* no number found */
- /* see if this is a ISA IRQ */
- if ((irq < 0) || (irq >= ACPI_MAX_ISA_IRQS))
+ if (irq < 0)
+ continue;
+
+ if (irq >= ARRAY_SIZE(acpi_irq_penalty))
continue;
if (used)
- new_penalty = acpi_irq_get_penalty(irq) +
- PIRQ_PENALTY_ISA_USED;
+ acpi_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
+ PIRQ_PENALTY_ISA_USED;
else
- new_penalty = 0;
+ acpi_irq_penalty[irq] = 0;
- acpi_isa_irq_penalty[irq] = new_penalty;
if (retval != 2) /* no next number */
break;
}
@@ -870,14 +871,14 @@ static int __init acpi_irq_penalty_update(char *str, int used)
*/
void acpi_penalize_isa_irq(int irq, int active)
{
- if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
- acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
- (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
+ if (irq >= 0 && irq < ARRAY_SIZE(acpi_irq_penalty))
+ acpi_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
+ (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
}
bool acpi_isa_irq_available(int irq)
{
- return irq >= 0 && (irq >= ARRAY_SIZE(acpi_isa_irq_penalty) ||
+ return irq >= 0 && (irq >= ARRAY_SIZE(acpi_irq_penalty) ||
acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
}
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Sinan Kaya @ 2016-10-01 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475343976-20744-1-git-send-email-okaya@codeaurora.org>
The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
resource requirements") removed PCI_USING penalty from
acpi_pci_link_allocate function as there is no longer a fixed size penalty
array for both PCI and IRQ interrupts.
We need to add the PCI_USING penalty for ISA interrupts too if the link is
in use and matches our ISA IRQ number.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/acpi/pci_link.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index f3792f4..06c2a11 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -620,6 +620,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link)
acpi_device_bid(link->device));
return -ENODEV;
} else {
+ if (link->irq.active < ACPI_MAX_IRQS)
+ acpi_irq_penalty[link->irq.active] +=
+ PIRQ_PENALTY_PCI_USING;
+
printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
acpi_device_name(link->device),
acpi_device_bid(link->device), link->irq.active);
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Sinan Kaya @ 2016-10-01 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475343976-20744-1-git-send-email-okaya@codeaurora.org>
This reverts commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize
function"). SCI penalty API was replaced by the runtime penalty calculation
based on the value of acpi_gbl_FADT.sci_interrupt.
acpi_gbl_FADT.sci_interrupt type does not get updated at the right time
for some platforms and results in incorrect penalty assignment for PCI
IRQs as irq_get_trigger_type returns the wrong type.
Link: http://www.spinics.net/lists/linux-pci/msg54599.html
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
arch/x86/kernel/acpi/boot.c | 1 +
drivers/acpi/pci_link.c | 34 ++++++++++++++--------------------
include/linux/acpi.h | 1 +
3 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 90d84c3..0ffd26e 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger,
polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
+ acpi_penalize_sci_irq(bus_irq, trigger, polarity);
/*
* stash over-ride to indicate we've been here
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index 06c2a11..6a2af19 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -495,27 +495,10 @@ static int acpi_irq_pci_sharing_penalty(int irq)
static int acpi_irq_get_penalty(int irq)
{
- int penalty = 0;
-
- /*
- * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
- * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
- * use for PCI IRQs.
- */
- if (irq == acpi_gbl_FADT.sci_interrupt) {
- u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
-
- if (type != IRQ_TYPE_LEVEL_LOW)
- penalty += PIRQ_PENALTY_ISA_ALWAYS;
- else
- penalty += PIRQ_PENALTY_PCI_USING;
- }
-
- if (irq < ACPI_MAX_ISA_IRQS)
- return penalty + acpi_irq_penalty[irq];
+ if (irq < ACPI_MAX_IRQS)
+ return acpi_irq_penalty[irq];
- penalty += acpi_irq_pci_sharing_penalty(irq);
- return penalty;
+ return acpi_irq_pci_sharing_penalty(irq);
}
int __init acpi_irq_penalty_init(void)
@@ -886,6 +869,17 @@ bool acpi_isa_irq_available(int irq)
acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
}
+void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
+{
+ if (irq >= 0 && irq < ARRAY_SIZE(acpi_irq_penalty)) {
+ if (trigger != ACPI_MADT_TRIGGER_LEVEL ||
+ polarity != ACPI_MADT_POLARITY_ACTIVE_LOW)
+ acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS;
+ else
+ acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING;
+ }
+}
+
/*
* Over-ride default table to reserve additional IRQs for use by ISA
* e.g. acpi_irq_isa=5
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4d8452c..85ac7d5 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -318,6 +318,7 @@ struct pci_dev;
int acpi_pci_irq_enable (struct pci_dev *dev);
void acpi_penalize_isa_irq(int irq, int active);
bool acpi_isa_irq_available(int irq);
+void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
void acpi_pci_irq_disable (struct pci_dev *dev);
extern int ec_read(u8 addr, u8 *val);
--
1.9.1
^ permalink raw reply related
* [RFC] arm64: Enforce observed order for spinlock and data
From: Mark Rutland @ 2016-10-01 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <66a031ac2405e352ab0d5f19d7ddb8e9@codeaurora.org>
Hi Brent,
Evidently my questions weren't sufficiently clear; even with your answers it's
not clear to me what precise issue you're attempting to solve. I've tried to be
more specific this time.
At a high-level, can you clarify whether you're attempting to solve is:
(a) a functional correctness issue (e.g. data corruption)
(b) a performance issue
And whether this was seen in practice, or found through code inspection?
On Sat, Oct 01, 2016 at 12:11:36PM -0400, bdegraaf at codeaurora.org wrote:
> On 2016-09-30 15:32, Mark Rutland wrote:
> >On Fri, Sep 30, 2016 at 01:40:57PM -0400, Brent DeGraaf wrote:
> >>+ * so LSE needs an explicit barrier here as well. Without this, the
> >>+ * changed contents of the area protected by the spinlock could be
> >>+ * observed prior to the lock.
> >>+ */
> >
> >By whom? We generally expect that if data is protected by a lock, you take
> >the lock before accessing it. If you expect concurrent lockless readers,
> >then there's a requirement on the writer side to explicitly provide the
> >ordering it requires -- spinlocks are not expected to provide that.
>
> More details are in my response to Robin, but there is an API arm64 supports
> in spinlock.h which is used by lockref to determine whether a lock is free or
> not. For that code to work properly without adding these barriers, that API
> needs to take the lock.
Can you please provide a concrete example of a case where things go wrong,
citing the code (or access pattern) in question? e.g. as in the commit messages
for:
8e86f0b409a44193 ("arm64: atomics: fix use of acquire + release for full barrier semantics)
859b7a0e89120505 ("mm/slub: fix lockups on PREEMPT && !SMP kernels")
(for the latter, I messed up the register -> var mapping in one paragraph, but
the style and reasoning is otherwise sound).
In the absence of a concrete example as above, it's very difficult to reason
about what the underlying issue is, and what a valid fix would be for said
issue.
> >What pattern of accesses are made by readers and writers such that there is
> >a problem?
Please note here I was asking specifically w.r.t. the lockref code, e.g. which
loads could see stale data, and what does the code do based on this value such
that there is a problem.
> I added the barriers to the readers/writers because I do not know these are
> not similarly abused. There is a lot of driver code out there, and ensuring
> order is the safest way to be sure we don't get burned by something similar
> to the lockref access.
Making the architecture-provided primitives overly strong harms performance and
efficiency (in general), makes the code harder to maintain and optimise in
future, and only masks the issue (which could crop up on other architectures,
for instance).
Thanks,
Mark.
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066
From: Mark Rutland @ 2016-10-01 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001140939.GA31220@vaio-ubuntu>
Hi,
On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?= wrote:
> For some reason accessing memory region above 0xfe000000 freezes
> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> solved same way.
>
> Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
> ---
> arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 0d0dae3..44c8956 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -93,6 +93,19 @@
> };
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + /*
> + * The rk3066 cannot use the memory area above 0x9F000000
> + * for some unknown reason.
> + */
> + unusable at 9F000000 {
> + reg = <0x9F000000 0x1000000>;
> + };
I don't think this is a sane workaround, but it is at best difficult to tell,
given there's no reason given for why this memory is unusable.
For instance, if bus accesses to this address hang, then this patch only makes
the hand less likely, since the kernel will still map the region (and therefore
the CPU can perform speculative accesses).
Are issues with this memory consistently seen in practice?
Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to determine if
the memory is returning erroneous values?
Thanks,
Mark.
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066
From: Heiko Stuebner @ 2016-10-01 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001181711.GB17554@remoulade>
Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
> Hi,
>
> On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?=
wrote:
> > For some reason accessing memory region above 0xfe000000 freezes
> > system on rk3066. There is similiar bug on later rockchip soc (rk3288)
> > solved same way.
> >
> > Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
> > ---
> >
> > arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/rk3066a.dtsi
> > b/arch/arm/boot/dts/rk3066a.dtsi index 0d0dae3..44c8956 100644
> > --- a/arch/arm/boot/dts/rk3066a.dtsi
> > +++ b/arch/arm/boot/dts/rk3066a.dtsi
> > @@ -93,6 +93,19 @@
> >
> > };
> >
> > };
> >
> > + reserved-memory {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > + /*
> > + * The rk3066 cannot use the memory area above 0x9F000000
> > + * for some unknown reason.
> > + */
> > + unusable at 9F000000 {
> > + reg = <0x9F000000 0x1000000>;
> > + };
>
> I don't think this is a sane workaround, but it is at best difficult to
> tell, given there's no reason given for why this memory is unusable.
>
> For instance, if bus accesses to this address hang, then this patch only
> makes the hand less likely, since the kernel will still map the region (and
> therefore the CPU can perform speculative accesses).
>
> Are issues with this memory consistently seen in practice?
>
> Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to determine
> if the memory is returning erroneous values?
just for the sake of completeness, on the rk3288 the issue was the dma not
being able to access the specific memory region (interestingly also the last
16MB but of the 4GB area supported on the rk3288). So memory itself was ok,
just dma access to it failed.
We didn't find any other sane solution to limit the dma access in a general way
at the time, so opted for just blocking the memory region (as it was similarly
only
In the patch above, the newly blocked area is in the middle of the two 1gb
memory areas (0x60000000-0xa0000000-1, 0xa0000000-0xe0000000-1).
Pavel, apart from Mark's CONFIG_MEMTEST request above could you also specifiy
what type of error you see please?
Thanks
Heiko
^ permalink raw reply
* [PATCH 00/15] improve function-level documentation
From: Julia Lawall @ 2016-10-01 19:46 UTC (permalink / raw)
To: linux-arm-kernel
These patches fix cases where the documentation above a function definition
is not consistent with the function header. Issues are detected using the
semantic patch below (http://coccinelle.lip6.fr/). Basically, the semantic
patch parses a file to find comments, then matches each function header,
and checks that the name and parameter list in the function header are
compatible with the comment that preceeds it most closely.
// <smpl>
@initialize:ocaml@
@@
let tbl = ref []
let fnstart = ref []
let success = Hashtbl.create 101
let thefile = ref ""
let parsed = ref []
let nea = ref []
let parse file =
thefile := List.nth (Str.split (Str.regexp "linux-next/") file) 1;
let i = open_in file in
let startline = ref 0 in
let fn = ref "" in
let ids = ref [] in
let rec inside n =
let l = input_line i in
let n = n + 1 in
match Str.split_delim (Str.regexp_string "*/") l with
before::after::_ ->
(if not (!fn = "")
then tbl := (!startline,n,!fn,List.rev !ids)::!tbl);
startline := 0;
fn := "";
ids := [];
outside n
| _ ->
(match Str.split (Str.regexp "[ \t]+") l with
"*"::name::rest ->
let len = String.length name in
(if !fn = "" && len > 2 && String.sub name (len-2) 2 = "()"
then fn := String.sub name 0 (len-2)
else if !fn = "" && (not (rest = [])) && List.hd rest = "-"
then
if String.get name (len-1) = ':'
then fn := String.sub name 0 (len-1)
else fn := name
else if not(!fn = "") && len > 2 &&
String.get name 0 = '@' && String.get name (len-1) = ':'
then ids := (String.sub name 1 (len-2)) :: !ids);
| _ -> ());
inside n
and outside n =
let l = input_line i in
let n = n + 1 in
if String.length l > 2 && String.sub l 0 3 = "/**"
then
begin
startline := n;
inside n
end
else outside n in
try outside 0 with End_of_file -> ()
let hashadd tbl k v =
let cell =
try Hashtbl.find tbl k
with Not_found ->
let cell = ref [] in
Hashtbl.add tbl k cell;
cell in
cell := v :: !cell
@script:ocaml@
@@
tbl := [];
fnstart := [];
Hashtbl.clear success;
parsed := [];
nea := [];
parse (List.hd (Coccilib.files()))
@r@
identifier f;
position p;
@@
f at p(...) { ... }
@script:ocaml@
p << r.p;
f << r.f;
@@
parsed := f :: !parsed;
fnstart := (List.hd p).line :: !fnstart
@param@
identifier f;
type T;
identifier i;
parameter list[n] ps;
parameter list[n1] ps1;
position p;
@@
f@p(ps,T i,ps1) { ... }
@script:ocaml@
@@
tbl := List.rev (List.sort compare !tbl)
@script:ocaml@
p << param.p;
f << param.f;
@@
let myline = (List.hd p).line in
let prevline =
List.fold_left
(fun prev x ->
if x < myline
then max x prev
else prev)
0 !fnstart in
let _ =
List.exists
(function (st,fn,nm,ids) ->
if prevline < st && myline > st && prevline < fn && myline > fn
then
begin
(if not (String.lowercase f = String.lowercase nm)
then
Printf.printf "%s:%d %s doesn't match preceding comment: %s\n"
!thefile myline f nm);
true
end
else false)
!tbl in
()
@script:ocaml@
p << param.p;
n << param.n;
n1 << param.n1;
i << param.i;
f << param.f;
@@
let myline = (List.hd p).line in
let prevline =
List.fold_left
(fun prev x ->
if x < myline
then max x prev
else prev)
0 !fnstart in
let _ =
List.exists
(function (st,fn,nm,ids) ->
if prevline < st && myline > st && prevline < fn && myline > fn
then
begin
(if List.mem i ids then hashadd success (st,fn,nm) i);
(if ids = [] (* arg list seems not obligatory *)
then ()
else if not (List.mem i ids)
then
Printf.printf "%s:%d %s doesn't appear in ids: %s\n"
!thefile myline i (String.concat " " ids)
else if List.length ids <= n || List.length ids <= n1
then
(if not (List.mem f !nea)
then
begin
nea := f :: !nea;
Printf.printf "%s:%d %s not enough args\n" !thefile myline f;
end)
else
let foundid = List.nth ids n in
let efoundid = List.nth (List.rev ids) n1 in
if not(foundid = i || efoundid = i)
then
Printf.printf "%s:%d %s wrong arg in position %d: %s\n"
!thefile myline i n foundid);
true
end
else false)
!tbl in
()
@script:ocaml@
@@
List.iter
(function (st,fn,nm,ids) ->
if List.mem nm !parsed
then
let entry =
try !(Hashtbl.find success (st,fn,nm))
with Not_found -> [] in
List.iter
(fun id ->
if not (List.mem id entry) && not (id = "...")
then Printf.printf "%s:%d %s not used\n" !thefile st id)
ids)
!tbl
// </smpl>
---
drivers/clk/keystone/pll.c | 4 ++--
drivers/clk/sunxi/clk-mod0.c | 2 +-
drivers/clk/tegra/cvb.c | 10 +++++-----
drivers/dma-buf/sw_sync.c | 6 +++---
drivers/gpu/drm/gma500/intel_i2c.c | 3 +--
drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++--
drivers/irqchip/irq-metag-ext.c | 1 -
drivers/irqchip/irq-vic.c | 1 -
drivers/mfd/tc3589x.c | 4 ++--
drivers/power/supply/ab8500_fg.c | 8 ++++----
drivers/power/supply/abx500_chargalg.c | 1 +
drivers/power/supply/intel_mid_battery.c | 2 +-
drivers/power/supply/power_supply_core.c | 4 ++--
fs/crypto/crypto.c | 4 ++--
fs/crypto/fname.c | 4 ++--
fs/ubifs/file.c | 2 +-
fs/ubifs/gc.c | 2 +-
fs/ubifs/lprops.c | 2 +-
fs/ubifs/lpt_commit.c | 4 +---
fs/ubifs/replay.c | 2 +-
lib/kobject_uevent.c | 6 +++---
lib/lru_cache.c | 4 ++--
lib/nlattr.c | 2 +-
23 files changed, 39 insertions(+), 43 deletions(-)
^ permalink raw reply
* [PATCH 07/15] clk: sunxi: mod0: improve function-level documentation
From: Julia Lawall @ 2016-10-01 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475351192-27079-1-git-send-email-Julia.Lawall@lip6.fr>
Use the actual function name in the function documentation.
Issue detected using Coccinelle (http://coccinelle.lip6.fr/)
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/clk/sunxi/clk-mod0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi/clk-mod0.c b/drivers/clk/sunxi/clk-mod0.c
index e54266c..4417ae1 100644
--- a/drivers/clk/sunxi/clk-mod0.c
+++ b/drivers/clk/sunxi/clk-mod0.c
@@ -24,7 +24,7 @@
#include "clk-factors.h"
/**
- * sun4i_get_mod0_factors() - calculates m, n factors for MOD0-style clocks
+ * sun4i_a10_get_mod0_factors() - calculates m, n factors for MOD0-style clocks
* MOD0 rate is calculated as follows
* rate = (parent_rate >> p) / (m + 1);
*/
^ permalink raw reply related
* [PATCH] ARM: dts: rockchip: Reserve unusable memory region on rk3066
From: Paweł Jarosz @ 2016-10-01 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6962779.A926KxJite@phil>
Hi,
main symptom is complete system freeze.
With CONFIG_MEMTEST enabled and with passed "memtest" to the kernel all
tests run ok.
But when i run command for example "memtester 800M" or simple "apt
update" freeze happening.
And when i reserve this region in dts, board is stable again.
Thanks,
Pawel
W dniu 01.10.2016 o 21:18, Heiko Stuebner pisze:
> Am Samstag, 1. Oktober 2016, 19:17:11 CEST schrieb Mark Rutland:
>> Hi,
>>
>> On Sat, Oct 01, 2016 at 04:09:39PM +0200, =?UTF-8?q?Pawe=C5=82=20Jarosz?=
> wrote:
>>> For some reason accessing memory region above 0xfe000000 freezes
>>> system on rk3066. There is similiar bug on later rockchip soc (rk3288)
>>> solved same way.
>>>
>>> Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
>>> ---
>>>
>>> arch/arm/boot/dts/rk3066a.dtsi | 13 +++++++++++++
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/rk3066a.dtsi
>>> b/arch/arm/boot/dts/rk3066a.dtsi index 0d0dae3..44c8956 100644
>>> --- a/arch/arm/boot/dts/rk3066a.dtsi
>>> +++ b/arch/arm/boot/dts/rk3066a.dtsi
>>> @@ -93,6 +93,19 @@
>>>
>>> };
>>>
>>> };
>>>
>>> + reserved-memory {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> + /*
>>> + * The rk3066 cannot use the memory area above 0x9F000000
>>> + * for some unknown reason.
>>> + */
>>> + unusable at 9F000000 {
>>> + reg = <0x9F000000 0x1000000>;
>>> + };
>> I don't think this is a sane workaround, but it is at best difficult to
>> tell, given there's no reason given for why this memory is unusable.
>>
>> For instance, if bus accesses to this address hang, then this patch only
>> makes the hand less likely, since the kernel will still map the region (and
>> therefore the CPU can perform speculative accesses).
>>
>> Are issues with this memory consistently seen in practice?
>>
>> Can you enable CONFIG_MEMTEST and pass 'memtest' to the kernel, to determine
>> if the memory is returning erroneous values?
> just for the sake of completeness, on the rk3288 the issue was the dma not
> being able to access the specific memory region (interestingly also the last
> 16MB but of the 4GB area supported on the rk3288). So memory itself was ok,
> just dma access to it failed.
>
> We didn't find any other sane solution to limit the dma access in a general way
> at the time, so opted for just blocking the memory region (as it was similarly
> only
>
> In the patch above, the newly blocked area is in the middle of the two 1gb
> memory areas (0x60000000-0xa0000000-1, 0xa0000000-0xe0000000-1).
>
> Pavel, apart from Mark's CONFIG_MEMTEST request above could you also specifiy
> what type of error you see please?
>
>
> Thanks
> Heiko
^ permalink raw reply
* [PATCH 00/15] improve function-level documentation
From: Joe Perches @ 2016-10-01 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475351192-27079-1-git-send-email-Julia.Lawall@lip6.fr>
On Sat, 2016-10-01 at 21:46 +0200, Julia Lawall wrote:
> These patches fix cases where the documentation above a function definition
> is not consistent with the function header. Issues are detected using the
> semantic patch below (http://coccinelle.lip6.fr/). Basically, the semantic
> patch parses a file to find comments, then matches each function header,
> and checks that the name and parameter list in the function header are
> compatible with the comment that preceeds it most closely.
Hi Julia.
Would it be possible for a semantic patch to scan for
function definitions where the types do not have
identifiers and update the definitions to match the
declarations?
For instance, given:
<some.h>
int foo(int);
<some.c>
int foo(int bar)
{
return baz;
}
Could coccinelle output:
diff a/some.h b/some.h
[]
-int foo(int);
+int foo(int bar);
^ permalink raw reply
* [PATCH 00/15] improve function-level documentation
From: Julia Lawall @ 2016-10-01 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475353194.1996.3.camel@perches.com>
On Sat, 1 Oct 2016, Joe Perches wrote:
> On Sat, 2016-10-01 at 21:46 +0200, Julia Lawall wrote:
> > These patches fix cases where the documentation above a function definition
> > is not consistent with the function header. Issues are detected using the
> > semantic patch below (http://coccinelle.lip6.fr/). Basically, the semantic
> > patch parses a file to find comments, then matches each function header,
> > and checks that the name and parameter list in the function header are
> > compatible with the comment that preceeds it most closely.
>
> Hi Julia.
>
> Would it be possible for a semantic patch to scan for
> function definitions where the types do not have
> identifiers and update the definitions to match the
> declarations?
>
> For instance, given:
>
> <some.h>
> int foo(int);
>
> <some.c>
> int foo(int bar)
> {
> return baz;
> }
>
> Could coccinelle output:
>
> diff a/some.h b/some.h
> []
> -int foo(int);
> +int foo(int bar);
The following seems to work:
@r@
identifier f;
position p;
type T, t;
parameter list[n] ps;
@@
T f at p(ps,t,...);
@s@
identifier r.f,x;
type r.T, r.t;
parameter list[r.n] ps;
@@
T f(ps,t x,...) { ... }
@@
identifier r.f, s.x;
position r.p;
type r.T, r.t;
parameter list[r.n] ps;
@@
T f at p(ps,t
+ x
,...);
After letting it run for a few minutes without making any effort to
include .h files, I get over 2700 changed lines.
julia
^ permalink raw reply
* [PATCH] ARM: dts: vf610-zii-dev-rev-b: Remove I2C3
From: Andrey Smirnov @ 2016-10-02 1:28 UTC (permalink / raw)
To: linux-arm-kernel
I2C3 bus was only brought out in revision A1 of the board and revision
B1 only brings out 3 I2C busses (I2C0, I2C1 and I2C2).
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 5c1fcab..fa19cfd 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -499,13 +499,6 @@
};
};
-&i2c3 {
- clock-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c3>;
- status = "okay";
-};
-
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart0>;
@@ -663,13 +656,6 @@
>;
};
- pinctrl_i2c3: i2c3grp {
- fsl,pins = <
- VF610_PAD_PTA30__I2C3_SCL 0x37ff
- VF610_PAD_PTA31__I2C3_SDA 0x37ff
- >;
- };
-
pinctrl_leds_debug: pinctrl-leds-debug {
fsl,pins = <
VF610_PAD_PTD20__GPIO_74 0x31c2
--
2.5.5
^ permalink raw reply related
* [PATCH] ARM: dts: vfxxx: Add node corresponding to OCOTP
From: Andrey Smirnov @ 2016-10-02 1:30 UTC (permalink / raw)
To: linux-arm-kernel
Add node corresponding to OCOTP IP block.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
arch/arm/boot/dts/vfxxx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2c13ec6..75850c0 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,12 @@
status = "disabled";
};
+ ocotp: ocotp at 400a5000 {
+ compatible = "fsl,vf610-ocotp";
+ reg = <0x400a5000 0x1000>;
+ clocks = <&clks VF610_CLK_OCOTP>;
+ };
+
snvs0: snvs at 400a7000 {
compatible = "fsl,sec-v4.0-mon", "syscon", "simple-mfd";
reg = <0x400a7000 0x2000>;
--
2.5.5
^ permalink raw reply related
* [PATCH] crypto: arm64/sha256 - add support for SHA256 using NEON instructions
From: Ard Biesheuvel @ 2016-10-02 2:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8J9rHA2opKqHQr74GU6xxwMpaJak1mNpRVpOf=+BZ81w@mail.gmail.com>
On 29 September 2016 at 16:37, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 29 September 2016 at 15:51, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> This is a port to arm64 of the NEON implementation of SHA256 that lives
>> under arch/arm/crypto.
>>
>> Due to the fact that the AArch64 assembler dialect deviates from the
>> 32-bit ARM one in ways that makes sharing code problematic, and given
>> that this version only uses the NEON version whereas the original
>> implementation supports plain ALU assembler, NEON and Crypto Extensions,
>> this code is built from a version sha256-armv4.pl that has been
>> transliterated to the AArch64 NEON dialect.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> arch/arm64/crypto/Kconfig | 5 +
>> arch/arm64/crypto/Makefile | 11 +
>> arch/arm64/crypto/sha256-armv4.pl | 413 +++++++++
>> arch/arm64/crypto/sha256-core.S_shipped | 883 ++++++++++++++++++++
>> arch/arm64/crypto/sha256_neon_glue.c | 103 +++
>> 5 files changed, 1415 insertions(+)
>>
>> diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
>> index 2cf32e9887e1..d32371198474 100644
>> --- a/arch/arm64/crypto/Kconfig
>> +++ b/arch/arm64/crypto/Kconfig
>> @@ -18,6 +18,11 @@ config CRYPTO_SHA2_ARM64_CE
>> depends on ARM64 && KERNEL_MODE_NEON
>> select CRYPTO_HASH
>>
>> +config CRYPTO_SHA2_ARM64_NEON
>> + tristate "SHA-224/SHA-256 digest algorithm (ARMv8 NEON)"
>> + depends on ARM64 && KERNEL_MODE_NEON
>> + select CRYPTO_HASH
>> +
>> config CRYPTO_GHASH_ARM64_CE
>> tristate "GHASH (for GCM chaining mode) using ARMv8 Crypto Extensions"
>> depends on ARM64 && KERNEL_MODE_NEON
>> diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
>> index abb79b3cfcfe..5156ebee0488 100644
>> --- a/arch/arm64/crypto/Makefile
>> +++ b/arch/arm64/crypto/Makefile
>> @@ -29,6 +29,9 @@ aes-ce-blk-y := aes-glue-ce.o aes-ce.o
>> obj-$(CONFIG_CRYPTO_AES_ARM64_NEON_BLK) += aes-neon-blk.o
>> aes-neon-blk-y := aes-glue-neon.o aes-neon.o
>>
>> +obj-$(CONFIG_CRYPTO_SHA2_ARM64_NEON) := sha256-neon.o
>
> There is a typo here that I only spotted just now: this should be += not :=
>
> Herbert, if you're picking this up, could you please fix this at merge
> time? Or do you need me to resend?
>
Please disregard this patch for now. I will follow up with a more
elaborate series for SHA256 on arm64
^ permalink raw reply
* [PATCH] ARM: dts: vf610-zii-dev-rev-b: Remove I2C3
From: Andrew Lunn @ 2016-10-02 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475371719-28736-1-git-send-email-andrew.smirnov@gmail.com>
On Sat, Oct 01, 2016 at 06:28:39PM -0700, Andrey Smirnov wrote:
> I2C3 bus was only brought out in revision A1 of the board and revision
> B1 only brings out 3 I2C busses (I2C0, I2C1 and I2C2).
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [RFC 05/11] iommu/dma: iommu_dma_(un)map_mixed
From: Christoffer Dall @ 2016-10-02 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b1b30b3-4199-9e18-362c-b8bc9d45277d@arm.com>
On Fri, Sep 30, 2016 at 02:24:40PM +0100, Robin Murphy wrote:
> Hi Eric,
>
> On 27/09/16 21:48, Eric Auger wrote:
> > iommu_dma_map_mixed and iommu_dma_unmap_mixed operate on
> > IOMMU_DOMAIN_MIXED typed domains. On top of standard iommu_map/unmap
> > they reserve the IOVA window to prevent the iova allocator to
> > allocate in those areas.
> >
> > Signed-off-by: Eric Auger <eric.auger@redhat.com>
> > ---
> > drivers/iommu/dma-iommu.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/dma-iommu.h | 18 ++++++++++++++++++
> > 2 files changed, 66 insertions(+)
> >
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 04bbc85..db21143 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -759,3 +759,51 @@ int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
> > return 0;
> > }
> > EXPORT_SYMBOL(iommu_get_dma_msi_region_cookie);
> > +
> > +int iommu_dma_map_mixed(struct iommu_domain *domain, unsigned long iova,
> > + phys_addr_t paddr, size_t size, int prot)
> > +{
> > + struct iova_domain *iovad;
> > + unsigned long lo, hi;
> > + int ret;
> > +
> > + if (domain->type != IOMMU_DOMAIN_MIXED)
> > + return -EINVAL;
> > +
> > + if (!domain->iova_cookie)
> > + return -EINVAL;
> > +
> > + iovad = cookie_iovad(domain);
> > +
> > + lo = iova_pfn(iovad, iova);
> > + hi = iova_pfn(iovad, iova + size - 1);
> > + reserve_iova(iovad, lo, hi);
>
> This can't work reliably - reserve_iova() will (for good reason) merge
> any adjacent or overlapping entries, so any unmap is liable to free more
> IOVA space than actually gets unmapped, and things will get subtly out
> of sync and go wrong later.
>
> The more general issue with this whole approach, though, is that it
> effectively rules out userspace doing guest memory hotplug or similar,
> and I'm not we want to paint ourselves into that corner. Basically, as
> soon as a device is attached to a guest, the entirety of the unallocated
> IPA space becomes reserved, and userspace can never add anything further
> to it, because any given address *might* be in use for an MSI mapping.
Ah, we didn't think of that when discussing this design at KVM Forum,
because the idea was that the IOVA allocator was in charge of that
resource, and the IOVA was a separate concept from the IPA space.
I think what tripped us up, is that while the above is true for the MSI
configuration where we trap the bar and do the allocation at VFIO init
time, the guest device driver can program DMA to any address without
trapping, and therefore there's an inherent relationship between the
IOVA and the IPA space. Is that right?
>
> I think it still makes most sense to stick with the original approach of
> cooperating with userspace to reserve a bounded area - it's just that we
> can then let automatic mapping take care of itself within that area.
I was thinking that it's also possible to do it the other way around: To
let userspace say wherever memory may be hotplugged and do the
allocation within the remaining area, but I suppose that's pretty much
the same thing, and it should just depend on what's easiest to implement
and what userspace can best predict.
>
> Speaking of which, I've realised the same fundamental reservation
> problem already applies to PCI without ACS, regardless of MSIs. I just
> tried on my Juno with guest memory placed at 0x4000000000, (i.e.
> matching the host PA of the 64-bit PCI window), and sure enough when the
> guest kicks off some DMA on the passed-through NIC, the root complex
> interprets the guest IPA as (unsupported) peer-to-peer DMA to a BAR
> claimed by the video card, and it fails. I guess this doesn't get hit in
> practice on x86 because the guest memory map is unlikely to be much
> different from the host's.
>
> It seems like we basically need a general way of communicating fixed and
> movable host reservations to userspace :/
>
Yes, this makes sense to me. Do we have any existing way of
discovering this from userspace or can we think of something?
Thanks,
-Christoffer
^ permalink raw reply
* [1/3] Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"
From: Jonathan Liu @ 2016-10-02 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475343976-20744-1-git-send-email-okaya@codeaurora.org>
On 2 October 2016 at 04:46, Sinan Kaya <okaya@codeaurora.org> wrote:
> This reverts commit 5c5087a55390 ("ACPI,PCI,IRQ: reduce static IRQ array
> size to 16").
>
> The code maintains a fixed size array for IRQ penalties. The array
> gets updated by external calls such as acpi_penalize_sci_irq,
> acpi_penalize_isa_irq to reflect the actual interrupt usage of the
> system. Since the IRQ distribution is platform specific, this is
> not known ahead of time. The IRQs get updated based on the SCI
> interrupt number BIOS has chosen or the ISA IRQs that were assigned
> to existing peripherals.
>
> By the time ACPI gets initialized, this code tries to determine an
> IRQ number based on penalty values in this array. It will try to locate
> the IRQ with the least penalty assignment so that interrupt sharing is
> avoided if possible.
>
> A couple of notes about the external APIs:
> 1. These API can be called before the ACPI is started. Therefore, one
> cannot assume that the PCI link objects are initialized for calculating
> penalties.
> 2. The polarity and trigger information passed via the
> acpi_penalize_sci_irq from the BIOS may not match what the IRQ subsystem
> is reporting as the call might have been placed before the IRQ is
> registered by the interrupt subsystem.
>
> The previous change was in the direction to remove these external API and
> try to calculate the penalties at runtime for the ISA path as well. This
> didn't work out well with the existing platforms.
>
> Restoring the old behavior for IRQ < 256 and the new behavior will remain
> effective for IRQ >= 256.
>
> Link: http://www.spinics.net/lists/linux-pci/msg54599.html
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 35 ++++++++++++++++++-----------------
> 1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..f3792f4 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -438,6 +438,7 @@ static int acpi_pci_link_set(struct acpi_pci_link *link, int irq)
> * enabled system.
> */
>
> +#define ACPI_MAX_IRQS 256
> #define ACPI_MAX_ISA_IRQS 16
>
> #define PIRQ_PENALTY_PCI_POSSIBLE (16*16)
> @@ -446,7 +447,7 @@ static int acpi_pci_link_set(struct acpi_pci_link *link, int irq)
> #define PIRQ_PENALTY_ISA_USED (16*16*16*16*16)
> #define PIRQ_PENALTY_ISA_ALWAYS (16*16*16*16*16*16)
>
> -static int acpi_isa_irq_penalty[ACPI_MAX_ISA_IRQS] = {
> +static int acpi_irq_penalty[ACPI_MAX_IRQS] = {
> PIRQ_PENALTY_ISA_ALWAYS, /* IRQ0 timer */
> PIRQ_PENALTY_ISA_ALWAYS, /* IRQ1 keyboard */
> PIRQ_PENALTY_ISA_ALWAYS, /* IRQ2 cascade */
> @@ -511,7 +512,7 @@ static int acpi_irq_get_penalty(int irq)
> }
>
> if (irq < ACPI_MAX_ISA_IRQS)
> - return penalty + acpi_isa_irq_penalty[irq];
> + return penalty + acpi_irq_penalty[irq];
>
> penalty += acpi_irq_pci_sharing_penalty(irq);
> return penalty;
> @@ -538,14 +539,14 @@ int __init acpi_irq_penalty_init(void)
>
> for (i = 0; i < link->irq.possible_count; i++) {
> if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
> - acpi_isa_irq_penalty[link->irq.
> + acpi_irq_penalty[link->irq.
> possible[i]] +=
> penalty;
> }
>
> } else if (link->irq.active &&
> - (link->irq.active < ACPI_MAX_ISA_IRQS)) {
> - acpi_isa_irq_penalty[link->irq.active] +=
> + (link->irq.active < ACPI_MAX_IRQS)) {
> + acpi_irq_penalty[link->irq.active] +=
> PIRQ_PENALTY_PCI_POSSIBLE;
> }
> }
> @@ -828,7 +829,7 @@ static void acpi_pci_link_remove(struct acpi_device *device)
> }
>
> /*
> - * modify acpi_isa_irq_penalty[] from cmdline
> + * modify acpi_irq_penalty[] from cmdline
> */
> static int __init acpi_irq_penalty_update(char *str, int used)
> {
> @@ -837,24 +838,24 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> for (i = 0; i < 16; i++) {
> int retval;
> int irq;
> - int new_penalty;
>
> retval = get_option(&str, &irq);
>
> if (!retval)
> break; /* no number found */
>
> - /* see if this is a ISA IRQ */
> - if ((irq < 0) || (irq >= ACPI_MAX_ISA_IRQS))
> + if (irq < 0)
> + continue;
> +
> + if (irq >= ARRAY_SIZE(acpi_irq_penalty))
> continue;
>
> if (used)
> - new_penalty = acpi_irq_get_penalty(irq) +
> - PIRQ_PENALTY_ISA_USED;
> + acpi_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> + PIRQ_PENALTY_ISA_USED;
> else
> - new_penalty = 0;
> + acpi_irq_penalty[irq] = 0;
>
> - acpi_isa_irq_penalty[irq] = new_penalty;
> if (retval != 2) /* no next number */
> break;
> }
> @@ -870,14 +871,14 @@ static int __init acpi_irq_penalty_update(char *str, int used)
> */
> void acpi_penalize_isa_irq(int irq, int active)
> {
> - if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
> - acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> - (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
> + if (irq >= 0 && irq < ARRAY_SIZE(acpi_irq_penalty))
> + acpi_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> + (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
> }
>
> bool acpi_isa_irq_available(int irq)
> {
> - return irq >= 0 && (irq >= ARRAY_SIZE(acpi_isa_irq_penalty) ||
> + return irq >= 0 && (irq >= ARRAY_SIZE(acpi_irq_penalty) ||
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
> }
>
This series fixes one or more network adapters in VirtualBox not
working with Linux 32-bit x86 guest if I have 4 network adapters
enabled. The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [2/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Jonathan Liu @ 2016-10-02 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475343976-20744-2-git-send-email-okaya@codeaurora.org>
On 2 October 2016 at 04:46, Sinan Kaya <okaya@codeaurora.org> wrote:
> The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
> resource requirements") removed PCI_USING penalty from
> acpi_pci_link_allocate function as there is no longer a fixed size penalty
> array for both PCI and IRQ interrupts.
>
> We need to add the PCI_USING penalty for ISA interrupts too if the link is
> in use and matches our ISA IRQ number.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index f3792f4..06c2a11 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -620,6 +620,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link)
> acpi_device_bid(link->device));
> return -ENODEV;
> } else {
> + if (link->irq.active < ACPI_MAX_IRQS)
> + acpi_irq_penalty[link->irq.active] +=
> + PIRQ_PENALTY_PCI_USING;
> +
> printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
> acpi_device_name(link->device),
> acpi_device_bid(link->device), link->irq.active);
This series fixes one or more network adapters in VirtualBox not
working with Linux 32-bit x86 guest if I have 4 network adapters
enabled. The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [3/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Jonathan Liu @ 2016-10-02 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475343976-20744-3-git-send-email-okaya@codeaurora.org>
On 2 October 2016 at 04:46, Sinan Kaya <okaya@codeaurora.org> wrote:
> This reverts commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize
> function"). SCI penalty API was replaced by the runtime penalty calculation
> based on the value of acpi_gbl_FADT.sci_interrupt.
>
> acpi_gbl_FADT.sci_interrupt type does not get updated at the right time
> for some platforms and results in incorrect penalty assignment for PCI
> IRQs as irq_get_trigger_type returns the wrong type.
>
> Link: http://www.spinics.net/lists/linux-pci/msg54599.html
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> arch/x86/kernel/acpi/boot.c | 1 +
> drivers/acpi/pci_link.c | 34 ++++++++++++++--------------------
> include/linux/acpi.h | 1 +
> 3 files changed, 16 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 90d84c3..0ffd26e 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger,
> polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
>
> mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
> + acpi_penalize_sci_irq(bus_irq, trigger, polarity);
>
> /*
> * stash over-ride to indicate we've been here
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 06c2a11..6a2af19 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -495,27 +495,10 @@ static int acpi_irq_pci_sharing_penalty(int irq)
>
> static int acpi_irq_get_penalty(int irq)
> {
> - int penalty = 0;
> -
> - /*
> - * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> - * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> - * use for PCI IRQs.
> - */
> - if (irq == acpi_gbl_FADT.sci_interrupt) {
> - u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
> -
> - if (type != IRQ_TYPE_LEVEL_LOW)
> - penalty += PIRQ_PENALTY_ISA_ALWAYS;
> - else
> - penalty += PIRQ_PENALTY_PCI_USING;
> - }
> -
> - if (irq < ACPI_MAX_ISA_IRQS)
> - return penalty + acpi_irq_penalty[irq];
> + if (irq < ACPI_MAX_IRQS)
> + return acpi_irq_penalty[irq];
>
> - penalty += acpi_irq_pci_sharing_penalty(irq);
> - return penalty;
> + return acpi_irq_pci_sharing_penalty(irq);
> }
>
> int __init acpi_irq_penalty_init(void)
> @@ -886,6 +869,17 @@ bool acpi_isa_irq_available(int irq)
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
> }
>
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
> +{
> + if (irq >= 0 && irq < ARRAY_SIZE(acpi_irq_penalty)) {
> + if (trigger != ACPI_MADT_TRIGGER_LEVEL ||
> + polarity != ACPI_MADT_POLARITY_ACTIVE_LOW)
> + acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS;
> + else
> + acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING;
> + }
> +}
> +
> /*
> * Over-ride default table to reserve additional IRQs for use by ISA
> * e.g. acpi_irq_isa=5
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 4d8452c..85ac7d5 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -318,6 +318,7 @@ struct pci_dev;
> int acpi_pci_irq_enable (struct pci_dev *dev);
> void acpi_penalize_isa_irq(int irq, int active);
> bool acpi_isa_irq_available(int irq);
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
> void acpi_pci_irq_disable (struct pci_dev *dev);
>
> extern int ec_read(u8 addr, u8 *val);
This series fixes one or more network adapters in VirtualBox not
working with Linux 32-bit x86 guest if I have 4 network adapters
enabled. The following message no longer appears in the kernel log:
ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [PATCH v3 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts
From: Noralf Trønnes @ 2016-10-02 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1708178720.178936.b155d019-5320-4754-bbe2-4afc1ae71cd6.open-xchange@email.1und1.de>
Den 29.09.2016 07:37, skrev Stefan Wahren:
>> Noralf Tr?nnes <noralf@tronnes.org> hat am 29. September 2016 um 00:22
>> geschrieben:
>>
>>
>>
>> Den 29.09.2016 00:00, skrev Eric Anholt:
>>> Noralf Tr?nnes <noralf@tronnes.org> writes:
>>>
>>>> If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0),
>>>> the driver has no way to fill/drain the FIFO to stop the interrupts.
>>>> In this case the controller has to be disabled and the transfer
>>>> completed to avoid hang.
>>>>
>>>> (CLKT | ERR) and DONE interrupts are completed in their own paths, and
>>>> the controller is disabled in the transfer function after completion.
>>>> Unite the code paths and do disabling inside the interrupt routine.
>>>>
>>>> Clear interrupt status bits in the united completion path instead of
>>>> trying to do it on every interrupt which isn't necessary.
>>>> Only CLKT, ERR and DONE can be cleared that way.
>>>>
>>>> Add the status value to the error value in case of TXW/RXR errors to
>>>> distinguish them from the other S_LEN error.
>>> I was surprised that not writing the TXW/RXR bits on handling their
>>> interrupts was OK, given that we were doing so before, but it's a level
>>> interrupt and those bits are basically ignored on write.
>>>
>>> This patch and 3, 4, and 6 are:
>>>
>>> Reviewed-by: Eric Anholt <eric@anholt.net>
>>>
>>> Patch 5 is:
>>>
>>> Acked-by: Eric Anholt <eric@anholt.net>
>>>
>>> Note for future debug: The I2C_C_CLEAR on errors will take some time to
>>> resolve -- if you were in non-idle state and I2C_C_READ, it sets an
>>> abort_rx flag and runs through the state machine to send a NACK and a
>>> STOP, I think. Since we're setting CLEAR without I2CEN, that NACK will
>>> be hanging around queued up for next time we start the engine.
>> Maybe you're able to explain the issues I had with reset:
>> https://github.com/raspberrypi/linux/issues/1653
>>
>> Should we put your note into the commit message?
>> It will most likely be lost if it just stays in this email.
> I prefer to have this kind of information as a code comment.
Eric, does this look good to you as a code comment:
/*
* Note about I2C_C_CLEAR on error:
* The I2C_C_CLEAR on errors will take some time to resolve -- if you
were in
* non-idle state and I2C_C_READ, it sets an abort_rx flag and runs through
* the state machine to send a NACK and a STOP. Since we're setting CLEAR
* without I2CEN, that NACK will be hanging around queued up for next time
* we start the engine.
*/
If it is, I'll resend the series with this change and add all the ack's
and r-b's.
Noralf.
^ permalink raw reply
* [PATCH] crypto: sunxi-ss: mark sun4i_hash() static
From: Herbert Xu @ 2016-10-02 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474691326-15541-1-git-send-email-baoyou.xie@linaro.org>
On Sat, Sep 24, 2016 at 12:28:46PM +0800, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/crypto/sunxi-ss/sun4i-ss-hash.c:168:5: warning: no previous prototype for 'sun4i_hash' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
This patch has already been applied.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: arm64/sha256 - add support for SHA256 using NEON instructions
From: Herbert Xu @ 2016-10-02 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_M+FcuDSaGsJYjD96=Q1iXyFDD3KWy=4vUbeLWRgrHJw@mail.gmail.com>
On Sat, Oct 01, 2016 at 07:58:56PM -0700, Ard Biesheuvel wrote:
>
> Please disregard this patch for now. I will follow up with a more
> elaborate series for SHA256 on arm64
Thanks for the heads up.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Marek Vasut @ 2016-10-02 16:44 UTC (permalink / raw)
To: linux-arm-kernel
The LCDIF interrupt should be triggered by the rising edge of the
IRQ line because we only want the interrupt to trigger once per each
frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
by software, so the previous behavior before this patch, where the
interrupt was triggered by level-high status of the IRQ line, caused
the interrupt to fire again immediatelly after it was handled, which
caused the system to lock up due to the high rate of interrupts.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 1a473e8..9526c38 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -1143,7 +1143,7 @@
lcdif1: lcdif at 02220000 {
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
reg = <0x02220000 0x4000>;
- interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
<&clks IMX6SX_CLK_LCDIF_APB>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
@@ -1154,7 +1154,7 @@
lcdif2: lcdif at 02224000 {
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
reg = <0x02224000 0x4000>;
- interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>;
clocks = <&clks IMX6SX_CLK_LCDIF2_PIX>,
<&clks IMX6SX_CLK_LCDIF_APB>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: dts: imx6sx: Fix LCDIF interrupt type
From: Fabio Estevam @ 2016-10-02 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161002164435.5812-1-marex@denx.de>
Hi Marek,
On Sun, Oct 2, 2016 at 1:44 PM, Marek Vasut <marex@denx.de> wrote:
> The LCDIF interrupt should be triggered by the rising edge of the
> IRQ line because we only want the interrupt to trigger once per each
> frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted
> by software, so the previous behavior before this patch, where the
> interrupt was triggered by level-high status of the IRQ line, caused
> the interrupt to fire again immediatelly after it was handled, which
> caused the system to lock up due to the high rate of interrupts.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> ---
> arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
> index 1a473e8..9526c38 100644
> --- a/arch/arm/boot/dts/imx6sx.dtsi
> +++ b/arch/arm/boot/dts/imx6sx.dtsi
> @@ -1143,7 +1143,7 @@
> lcdif1: lcdif at 02220000 {
> compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
> reg = <0x02220000 0x4000>;
> - interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
What about mx6ul and mx6sl.dtsi? Shouldn't they be also updated?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox