* [PATCH 2/3] drivers/perf: arm_pmu: add arm_pmu_device_remove
From: Alexander Stein @ 2016-12-21 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221133854.GU3124@twins.programming.kicks-ass.net>
On Wednesday 21 December 2016 14:38:54, Peter Zijlstra wrote:
> On Wed, Dec 21, 2016 at 11:19:34AM +0100, Alexander Stein wrote:
> > Add ARM PMU removal function. This will be required by perf event drivers
> > when option DEBUG_TEST_DRIVER_REMOVE is enabled.
> >
> > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> > ---
> >
> > drivers/perf/arm_pmu.c | 14 ++++++++++++++
> > include/linux/perf/arm_pmu.h | 2 ++
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> > index a9bbdbf..b7ddc4c 100644
> > --- a/drivers/perf/arm_pmu.c
> > +++ b/drivers/perf/arm_pmu.c
> > @@ -1022,6 +1022,7 @@ int arm_pmu_device_probe(struct platform_device
> > *pdev,>
> > armpmu_init(pmu);
> >
> > pmu->plat_device = pdev;
> >
> > + platform_set_drvdata(pdev, pmu);
> >
> > if (node && (of_id = of_match_node(of_table, pdev->dev.of_node))) {
> >
> > init_fn = of_id->data;
> >
> > @@ -1073,6 +1074,19 @@ int arm_pmu_device_probe(struct platform_device
> > *pdev,>
> > return ret;
> >
> > }
> >
> > +int arm_pmu_device_remove(struct platform_device *pdev)
> > +{
> > + struct arm_pmu *pmu = platform_get_drvdata(pdev);
> > +
> > + __oprofile_cpu_pmu = NULL;
> > +
> > + perf_pmu_unregister(&pmu->pmu);
> > +
> > + cpu_pmu_destroy(pmu);
> > +
> > + return 0;
> > +}
>
> So normally, if there are events that use this pmu, we hold a reference
> on its module, which avoids removal from happening.
>
> How is that guarantee made by DEBUG_TEST_DRIVER_REMOVE ? Or will it
> simply kill everything even though there's active events for the PMU?
AFAICS you won't be able to hold any reference until this test remove is done.
This feature is implemented in really_probe(). If the driver is successfully
probed it will be removed and probed again.
But reading that part of the code I stumbled over suppress_bind_attrs which
would prevent this procedure. After some grepping I found commit 80c6397c3
("clk: oxnas: make it explicitly non-modular").
Essentially setting
> .suppress_bind_attrs = true
in the platform_driver.
IMHO this seems far better than to add some remove functions only for testing
a non-removable driver. I'll come up with a 2nd series, patch 1/3 is still
valid.
Best regards,
Alexander
^ permalink raw reply
* [PATCH v2 0/2] mark driver as non-removable
From: Alexander Stein @ 2016-12-21 15:03 UTC (permalink / raw)
To: linux-arm-kernel
Changes in v2;
* Instead of adding a remove function which is unused otherwise, mark the driver
as non-remoable
Using DEBUG_TEST_DRIVER_REMOVE every driver gets probed, removed and probed
again. This breaks drivers without removal function, e.g. arm perf
resulting in the following dump:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x6c/0x7c
sysfs: cannot create duplicate filename '/devices/armv7_cortex_a7'
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.9.0+ #212
Hardware name: Freescale LS1021A
Backtrace:
[<8020c044>] (dump_backtrace) from [<8020c2f0>] (show_stack+0x18/0x1c)
r7:00000009 r6:60000013 r5:80c1776c r4:00000000
[<8020c2d8>] (show_stack) from [<8046ead8>] (dump_stack+0x94/0xa8)
[<8046ea44>] (dump_stack) from [<8021ecd0>] (__warn+0xec/0x104)
r7:00000009 r6:8092efc8 r5:00000000 r4:bf04bd80
[<8021ebe4>] (__warn) from [<8021ed28>] (warn_slowpath_fmt+0x40/0x48)
r9:80a32848 r8:00000000 r7:00000000 r6:bf0ab780 r5:8091d590 r4:bf0df000
[<8021ecec>] (warn_slowpath_fmt) from [<8036d53c>] (sysfs_warn_dup+0x6c/0x7c)
r3:bf0df000 r2:8092ef94
[<8036d4d0>] (sysfs_warn_dup) from [<8036d628>] (sysfs_create_dir_ns+0x8c/0x9c)
r6:bf0ab780 r5:bf20ee08 r4:ffffffef
[<8036d59c>] (sysfs_create_dir_ns) from [<80471860>] (kobject_add_internal+0xa8/0x34c)
r6:bf0aa198 r5:00000000 r4:bf20ee08
[<804717b8>] (kobject_add_internal) from [<80471b54>] (kobject_add+0x50/0x94)
r7:00000000 r6:00000000 r5:00000000 r4:bf20ee08
[<80471b08>] (kobject_add) from [<80524590>] (device_add+0xe4/0x590)
r3:00000000 r2:00000000
r6:bf20ee00 r5:00000000 r4:bf20ee08
[<805244ac>] (device_add) from [<802a38a8>] (pmu_dev_alloc+0x88/0xd8)
r10:00000091 r9:80a32848 r8:00000000 r7:80a32840 r6:80c0ed3c r5:00000000
r4:bf1fe800
[<802a3820>] (pmu_dev_alloc) from [<80a0cd20>] (perf_event_sysfs_init+0x5c/0xb4)
r7:80a32840 r6:00000000 r5:bf1fe800 r4:80c0ede0
[<80a0ccc4>] (perf_event_sysfs_init) from [<80201778>] (do_one_initcall+0x48/0x178)
r6:80c45000 r5:80a0ccc4 r4:00000006
[<80201730>] (do_one_initcall) from [<80a00ecc>] (kernel_init_freeable+0x168/0x20c)
r8:80a00610 r7:80a32840 r6:80c45000 r5:80c45000 r4:00000006
[<80a00d64>] (kernel_init_freeable) from [<806febcc>] (kernel_init+0x10/0x11c)
r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:806febbc
r4:00000000
[<806febbc>] (kernel_init) from [<80208388>] (ret_from_fork+0x14/0x2c)
r5:806febbc r4:00000000
---[ end trace 9d251d389382804f ]---
This patchset marks the driver as explicitly non-remoavle preventing this error.
This disables bin/unbind for this driver as well.
Alexander Stein (2):
drivers/perf: arm_pmu: Use devm_ allocators
arm: perf: Mark as non-removable
arch/arm/kernel/perf_event_v7.c | 1 +
drivers/perf/arm_pmu.c | 14 ++++----------
2 files changed, 5 insertions(+), 10 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH v2 1/2] drivers/perf: arm_pmu: Use devm_ allocators
From: Alexander Stein @ 2016-12-21 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221150340.25657-1-alexander.stein@systec-electronic.com>
This eliminates several calls to kfree.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
drivers/perf/arm_pmu.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index b37b572..a9bbdbf 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -917,7 +917,8 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
bool using_spi = false;
struct platform_device *pdev = pmu->plat_device;
- irqs = kcalloc(pdev->num_resources, sizeof(*irqs), GFP_KERNEL);
+ irqs = devm_kcalloc(&pdev->dev, pdev->num_resources, sizeof(*irqs),
+ GFP_KERNEL);
if (!irqs)
return -ENOMEM;
@@ -939,7 +940,6 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
pr_err("PPI/SPI IRQ type mismatch for %s!\n",
dn->name);
of_node_put(dn);
- kfree(irqs);
return -EINVAL;
}
@@ -988,10 +988,8 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
int ret;
ret = irq_get_percpu_devid_partition(irq, &pmu->supported_cpus);
- if (ret) {
- kfree(irqs);
+ if (ret)
return ret;
- }
} else {
/* Otherwise default to all CPUs */
cpumask_setall(&pmu->supported_cpus);
@@ -1001,8 +999,6 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
/* If we matched up the IRQ affinities, use them to route the SPIs */
if (using_spi && i == pdev->num_resources)
pmu->irq_affinity = irqs;
- else
- kfree(irqs);
return 0;
}
@@ -1017,7 +1013,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
struct arm_pmu *pmu;
int ret = -ENODEV;
- pmu = kzalloc(sizeof(struct arm_pmu), GFP_KERNEL);
+ pmu = devm_kzalloc(&pdev->dev, sizeof(struct arm_pmu), GFP_KERNEL);
if (!pmu) {
pr_info("failed to allocate PMU device!\n");
return -ENOMEM;
@@ -1074,8 +1070,6 @@ int arm_pmu_device_probe(struct platform_device *pdev,
out_free:
pr_info("%s: failed to register PMU devices!\n",
of_node_full_name(node));
- kfree(pmu->irq_affinity);
- kfree(pmu);
return ret;
}
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/2] arm: perf: Mark as non-removable
From: Alexander Stein @ 2016-12-21 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221150340.25657-1-alexander.stein@systec-electronic.com>
This driver can only built into the kernel. So disallow driver bind/unbind
and also prevent a kernel error in case DEBUG_TEST_DRIVER_REMOVE is
enabled.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
arch/arm/kernel/perf_event_v7.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index b942349..795e373 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -2029,6 +2029,7 @@ static int armv7_pmu_device_probe(struct platform_device *pdev)
static struct platform_driver armv7_pmu_driver = {
.driver = {
.name = "armv7-pmu",
+ .suppress_bind_attrs = true,
.of_match_table = armv7_pmu_of_device_ids,
},
.probe = armv7_pmu_device_probe,
--
2.10.2
^ permalink raw reply related
* [linux-sunxi] Problems to Allwinner H3's eFUSE/SID
From: Bernhard Nortmann @ 2016-12-21 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <136061482160932@web34j.yandex.ru>
Side note:
Am 19.12.2016 um 16:22 schrieb Icenowy Zheng:
> [...]
>
> According to some facts:
> - The register based access to SID is weird: it needs ~5 register
> operations per word of SID.
> [...]
>
My experiments seem to indicate that Allwinner's implementation might be
overly complicated. I have used an alternative approach and did not notice
any issues so far.
They start by reading SID_PRCTL and use bit mask operations to get in the
key index value (PG_INDEX), then use a second write to set OP_LOCK and
READ_START. As far as I can tell, it's sufficient to construct (and write)
a single value from these three components. Allwinner finally clears out
the used bits by another mask operation, simply writing zero seems to get
that job done equally well.
My implementation can be seen in
https://github.com/n1tehawk/sunxi-tools/blob/20161220_sid-fix/uart0-helloworld-sdboot.c#L242-L256
or as assembler code in
https://github.com/n1tehawk/sunxi-tools/blob/20161220_sid-fix/sid_read_root.S#L43-L65
A corresponding PR is at
https://github.com/linux-sunxi/sunxi-tools/pull/91 ,
or you may clone my branch directly
("git clone https://github.com/n1tehawk/sunxi-tools.git -b
20161220_sid-fix").
Testers would be very welcome.
Regards, B. Nortmann
^ permalink raw reply
* [PATCH] ARM: dts: turris-omnia: add support for ethernet switch
From: Andrew Lunn @ 2016-12-21 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221102047.28036-1-uwe@kleine-koenig.org>
On Wed, Dec 21, 2016 at 11:20:47AM +0100, Uwe Kleine-K?nig wrote:
> The Turris Omnia features a Marvell MV88E7176 ethernet switch. Add it to
> the dts.
>
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> ---
> Hello,
>
> when the MAC is operated in rgmii mode and the switch in rgmii-id
> communication between them works fine. The other way round it doesn't work.
> The fixed-link nodes in the cpu port description is necessary to let the
> mv88e6xxx driver use the phy-mode description. Is this a bug?
It is somewhat deliberate. Normally, there is no phy at all for a cpu
port or a dsa port. If there is no phy, it makes no sense to set the
phy-mode. With fixed-link, there is a phy connected to the MAC, in
terms of how the network stack sees the devices. It is a somewhat
special phy, in fact its bandwidth is fixed, but it does support
phy-handle, and a few other phy properties and callbacks.
> Regarding the binding, I think the label in the port nodes is strange.
>
> label = "lan2"
>
> for an external port is fine. But
>
> label = "cpu"
>
> for a port facing a CPU MAC looks wrong, still more as the Turris Omnia has
> two ports connected to the SoC and so there are two ports with the same
> label.
This is somewhat historical. When DSA was designed, only one CPU port
was expected. There are in fact quite a few devices with two CPU
ports. I have some old proof of concept patches to support this, with
some basic load balancing. In the last few weeks, John Crispin has
been working on them, and has duel CPU ports working for the qca8k.
So i expect early next year we can make the Marvell chips support dual
CPU ports as well.
> I would suggest to use a separate property for that, e.g.
>
> cpu-port;
>
> and no label.
I would suggest keeping this idea for DSA v3, otherwise we end up with
messy code for little gain.
Andrew
^ permalink raw reply
* [v4, 3/3] ARM: dts: vf610-zii-dev-rev-b: Remove 'fixed-link' from DSA ports
From: Andrew Lunn @ 2016-12-21 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221132519.bkkqyfk3beow7nc5@pengutronix.de>
On Wed, Dec 21, 2016 at 02:25:19PM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Dec 21, 2016 at 03:58:45PM +0300, Nikita Yushchenko wrote:
> > > Remove 'fixed-link' nodes from DSA ports since they are not needed (they
> > > are not limiting link's speed and the ports will be configured to their
> > > maximux speed as a default)
> > >
> > > Suggested-by: Andrew Lunn <andrew@lunn.ch>
> > > Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> >
> > With this patch, ports connected to revB's second switch stop working.
>
> This is probably because without a fixed-link node the phy-mode setting
> isn't applied by the driver.
Yep, bad suggestion from me. If the phy-mode was not needed, then you
can drop the fixed-link. With the phy-mode, you also need the fixed
link.
Sorry for the wasted time,
Andrew
^ permalink raw reply
* [PATCH] i2c: uniphier[-f]: fix bool logic calculation
From: Masahiro Yamada @ 2016-12-21 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482256538.1984.23.camel@perches.com>
Hi Joe,
2016-12-21 2:55 GMT+09:00 Joe Perches <joe@perches.com>:
> On Wed, 2016-12-21 at 01:20 +0900, Masahiro Yamada wrote:
>> Hi.
>>
>> I have not got any comment, but does this seem
>> a right thing to do?
>
>> This code is working, but it should not depend on how "bool" is
>> typedef'ed, or the bit position of I2C_M_RD.
>
> <shrug>
>
> I think bool can be guaranteed to be _Bool.
>
> So a change not necessary as the original code
> has a c90 guarantee of the same result.
>
> 6.3.1.2 Boolean type
> 1
> When any scalar value is converted to _Bool, the result is 0 if the value compares equal
> to 0; otherwise, the result is 1.
>
Thanks for your comments!
_Bool works very nicely.
I have seen some (not very nice) projects
that define like "typedef char bool;"
So, I was wondering if I should write code
that works regardless how bool is defined.
Just my two cents.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH net-next 00/27] net: mvpp2: add basic support for PPv2.2
From: David Miller @ 2016-12-21 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482318994-23488-1-git-send-email-thomas.petazzoni@free-electrons.com>
Two things:
1) net-next is closed, please do not submit net-next material during
this time.
2) 27 patches is way too many to submit at one time, please keep your
patch series submissions to a small, reasonable size.
Thanks.
^ permalink raw reply
* [PATCH v3 net-next 0/3] Add support for the ethernet switch on the ESPRESSObin
From: David Miller @ 2016-12-21 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221090045.474-1-romain.perier@free-electrons.com>
net-next is not open, please do not submit net-next changes during this
time.
^ permalink raw reply
* [PATCH net-next 00/27] net: mvpp2: add basic support for PPv2.2
From: Thomas Petazzoni @ 2016-12-21 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221.110348.346806544020316686.davem@davemloft.net>
Hello,
On Wed, 21 Dec 2016 11:03:48 -0500 (EST), David Miller wrote:
> 1) net-next is closed, please do not submit net-next material during
> this time.
I did not expect you to review these patches right now, as I know
net-next is closed. However I expect other people in the net community
and people interested in Marvell platforms to look at those patches,
potentially test them and give feedback.
> 2) 27 patches is way too many to submit at one time, please keep your
> patch series submissions to a small, reasonable size.
OK, I will do some arbitrary cut in the series and send several
smaller series instead.
Thanks for the feedback,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net-next 00/27] net: mvpp2: add basic support for PPv2.2
From: David Miller @ 2016-12-21 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221171246.77e91d2c@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Wed, 21 Dec 2016 17:12:46 +0100
> Hello,
>
> On Wed, 21 Dec 2016 11:03:48 -0500 (EST), David Miller wrote:
>
>> 1) net-next is closed, please do not submit net-next material during
>> this time.
>
> I did not expect you to review these patches right now, as I know
> net-next is closed. However I expect other people in the net community
> and people interested in Marvell platforms to look at those patches,
> potentially test them and give feedback.
Then mark the patches as "RFC".
^ permalink raw reply
* [PATCH] ARM: dts: turris-omnia: add support for ethernet switch
From: Andrew Lunn @ 2016-12-21 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221102047.28036-1-uwe@kleine-koenig.org>
> /* Switch MV88E7176 at address 0x10 */
> + switch at 10 {
> + compatible = "marvell,mv88e6085";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dsa,member = <0 0>;
> +
> + reg = <0x10>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports at 0 {
> + reg = <0>;
> + label = "lan0";
> + phy-handle = <&lan0phy>;
snip
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + lan0phy: ethernet-phy at 0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + };
You probably don't need the phy-handle's and the whole mdio node. So
long as there is a simple mapping, port 0 uses the phy at address 0,
it should just work. You only need the mdio node when you want to
support PHY interrupts, or there is an odd mapping between port and
PHY, like the new switch chip added recently.
Andrew
^ permalink raw reply
* [PATCH] ARM: dts: turris-omnia: add support for ethernet switch
From: Uwe Kleine-König @ 2016-12-21 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221151814.GJ30952@lunn.ch>
Hello Andrew,
On Wed, Dec 21, 2016 at 04:18:14PM +0100, Andrew Lunn wrote:
> On Wed, Dec 21, 2016 at 11:20:47AM +0100, Uwe Kleine-K?nig wrote:
> > when the MAC is operated in rgmii mode and the switch in rgmii-id
> > communication between them works fine. The other way round it doesn't work.
> > The fixed-link nodes in the cpu port description is necessary to let the
> > mv88e6xxx driver use the phy-mode description. Is this a bug?
>
> It is somewhat deliberate. Normally, there is no phy at all for a cpu
> port or a dsa port. If there is no phy, it makes no sense to set the
> phy-mode. With fixed-link, there is a phy connected to the MAC, in
> terms of how the network stack sees the devices. It is a somewhat
> special phy, in fact its bandwidth is fixed, but it does support
> phy-handle, and a few other phy properties and callbacks.
Here the switch is the phy, and in this case it is necessary to
correctly configure it's physical properties. fixed-link is conceptual
wrong here because (IIUC) this is for MACs only. So (maybe also for DSA
v3 or a general phy cleanup) a standard binding to specify this which
doesn't formalise the switch (or general: phy) as MAC.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161221/2dc91dc6/attachment.sig>
^ permalink raw reply
* How to remove warn msg "cache: parent cpui should not be sleeping" i=1, 2, 3...
From: Sudeep Holla @ 2016-12-21 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221193703.6eac880c@xhacker>
On 21/12/16 11:37, Jisheng Zhang wrote:
> Hi all,
>
> I'm not sure this is a bug, when wake up from s2ram, I could get something
> like:
>
> [ 313.271464] Enabling non-boot CPUs ...
> [ 313.271551] CPU1: Booted secondary processor
> [ 313.271556] Detected VIPT I-cache on CPU1
> [ 313.301378] cache: parent cpu1 should not be sleeping
> [ 313.301504] CPU1 is up
> [ 313.301582] CPU2: Booted secondary processor
> [ 313.301585] Detected VIPT I-cache on CPU2
> [ 313.331485] cache: parent cpu2 should not be sleeping
> [ 313.331605] CPU2 is up
> [ 313.331683] CPU3: Booted secondary processor
> [ 313.331686] Detected VIPT I-cache on CPU3
> [ 313.361599] cache: parent cpu3 should not be sleeping
> [ 313.361719] CPU3 is up
>
> This is because we call cpu_device_create() when secondary cpu is brought
> online, the cpu_cache device's parent device: cpu device isn't already
> resumed, all device resume will resume after secondary cores are brought
> up.
>
> What's the elegant solution to remove this warning msg?
>
It is not a serious warning as you can see a comment in the code:
"/*
* This is a fib. But we'll allow new children to be added below
* a resumed device, even if the device hasn't been completed yet.
*/"
But if we think it needs to be removed, I have something like below in
my mind. I am not sure if this is hacky or not(completely untested, not
even compiled).
Regards,
Sudeep
-->8
diff --git i/drivers/base/cpu.c w/drivers/base/cpu.c
index 4c28e1a09786..2a5c04377adf 100644
--- i/drivers/base/cpu.c
+++ w/drivers/base/cpu.c
@@ -344,6 +344,14 @@ static int cpu_uevent(struct device *dev, struct
kobj_uevent_env *env)
}
#endif
+static int cpu_dev_pm_unset_is_prepared(unsigned int cpu)
+{
+ struct device *cpu_dev = get_cpu_device(cpu);
+
+ if(cpu_dev)
+ cpu_dev->power.is_prepared = false;
+ return 0;
+}
/*
* register_cpu - Setup a sysfs device for a CPU.
* @cpu - cpu->hotpluggable field set to 1 will generate a control file in
@@ -377,7 +385,9 @@ int register_cpu(struct cpu *cpu, int num)
per_cpu(cpu_sys_devices, num) = &cpu->dev;
register_cpu_under_node(num, cpu_to_node(num));
- return 0;
+ return cpuhp_setup_state_nocalls(CPUHP_CPUDEV_PM_PREPARE,
+ "base/cpu/dev_pm:prepare",
+ cpu_dev_pm_unset_is_prepared, NULL);
}
struct device *get_cpu_device(unsigned cpu)
diff --git i/include/linux/cpuhotplug.h w/include/linux/cpuhotplug.h
index 2ab7bf53d529..5bfe3c1aa148 100644
--- i/include/linux/cpuhotplug.h
+++ w/include/linux/cpuhotplug.h
@@ -51,6 +51,7 @@ enum cpuhp_state {
CPUHP_SLAB_PREPARE,
CPUHP_MD_RAID5_PREPARE,
CPUHP_RCUTREE_PREP,
+ CPUHP_CPUDEV_PM_PREPARE,
CPUHP_CPUIDLE_COUPLED_PREPARE,
CPUHP_POWERPC_PMAC_PREPARE,
CPUHP_POWERPC_MMU_CTX_PREPARE,
^ permalink raw reply related
* [PATCH net-next 14/27] net: mvpp2: add ip_version field in "struct mvpp2"
From: Andrew Lunn @ 2016-12-21 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482318994-23488-15-git-send-email-thomas.petazzoni@free-electrons.com>
Hi Thomas
Minor nit pick.
On Wed, Dec 21, 2016 at 12:16:21PM +0100, Thomas Petazzoni wrote:
> In preparation to the introduction for the support of PPv2.2 in the
> mvpp2 driver, this commit adds an ip_version field to the struct
> mvpp2
When i read this, i was thinking IPv4 vs IPv6. It is a network driver after all.
Could you maybe call this hw_version?
Thanks
Andrew
^ permalink raw reply
* [PATCH net-next 14/27] net: mvpp2: add ip_version field in "struct mvpp2"
From: Thomas Petazzoni @ 2016-12-21 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221170252.GO30952@lunn.ch>
Hello,
On Wed, 21 Dec 2016 18:02:52 +0100, Andrew Lunn wrote:
> On Wed, Dec 21, 2016 at 12:16:21PM +0100, Thomas Petazzoni wrote:
> > In preparation to the introduction for the support of PPv2.2 in the
> > mvpp2 driver, this commit adds an ip_version field to the struct
> > mvpp2
>
> When i read this, i was thinking IPv4 vs IPv6. It is a network driver after all.
> Could you maybe call this hw_version?
Sure, will do. Thanks for the feedback!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RFC] arm64/acpi: make ACPI boot preference configurable
From: Jonathan Toppins @ 2016-12-21 17:54 UTC (permalink / raw)
To: linux-arm-kernel
This patch allows a user to configure ACPI to be preferred over
device-tree.
Currently for ACPI to be used a user either has to set acpi=on on the
kernel command line or make sure any device tree passed to the kernel
is empty. If the dtb passed to the kernel is non-empty then device-tree
will be chosen as the boot method of choice even if it is not correct.
To prevent this situation where a system is only intended to be booted
via ACPI a user can set this kernel configuration so it ignores
device-tree settings unless ACPI table checks fail.
Signed-off-by: Jonathan Toppins <jtoppins@redhat.com>
---
arch/arm64/Kconfig | 13 +++++++++++++
arch/arm64/kernel/acpi.c | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 111742126897..e432e84245b9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -954,6 +954,19 @@ config ARM64_ACPI_PARKING_PROTOCOL
protocol even if the corresponding data is present in the ACPI
MADT table.
+config ARM64_PREFER_ACPI
+ bool "Prefer usage of ACPI boot tables over device-tree"
+ depends on ACPI
+ help
+ Normally device-tree is preferred over ACPI on arm64 unless
+ explicitly preferred via kernel command line, something like: acpi=on
+ This configuration changes this default behaviour by pretending
+ the user set acpi=on on the command line. This configuration still
+ allows the user to turn acpi table parsing off via acpi=off. If
+ for some reason the table checks fail the system will still fall
+ back to using device-tree unless the user explicitly sets acpi=force
+ on the command line.
+
config CMDLINE
string "Default kernel command string"
default ""
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 252a6d9c1da5..b5dfa5752ff7 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -43,7 +43,7 @@ int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ initialization */
EXPORT_SYMBOL(acpi_pci_disabled);
static bool param_acpi_off __initdata;
-static bool param_acpi_on __initdata;
+static bool param_acpi_on __initdata = IS_ENABLED(CONFIG_ARM64_PREFER_ACPI);
static bool param_acpi_force __initdata;
static int __init parse_acpi(char *arg)
--
2.10.2
^ permalink raw reply related
* ARM: imx: mmdc: Fix completely broken cpu hotplug code
From: Thomas Gleixner @ 2016-12-21 18:21 UTC (permalink / raw)
To: linux-arm-kernel
The cpu hotplug support of this perf driver is broken in several ways:
1) It adds a instance before setting up the state.
2) The state for the instance is different from the state of the
callback. It's just a randomly chosen state.
3) The instance registration is not error checked so nobody noticed that
the call can never succeed.
4) The state for the multi install callbacks is chosen randomly and
overwrites existing state. This is now prevented by the core code so the
call is guaranteed to fail.
5) The error exit path in the init function leaves the instance registered
and then frees the memory which contains the enqueued hlist node.
6) The remove function is removing the state and not the instance.
Fix it by:
- Setting up the state before adding instances. Use a dynamically allocated
state for it.
- Install instances after the state has been set up
- Remove the instance in the error path before freeing memory
- Remove instance not the state in the driver remove callback
While at is use raw_cpu_processor_id(), because cpu_processor_id() cannot
be used in preemptible context, and set the driver data after successful
registration of the pmu.
Fixes: e76bdfd7403a ("ARM: imx: Added perf functionality to mmdc driver")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Zhengyu Shen <zhengyu.shen@nxp.com>
Cc: Frank Li <frank.li@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/mach-imx/mmdc.c | 34 ++++++++++++++++++++++------------
include/linux/cpuhotplug.h | 1 +
2 files changed, 23 insertions(+), 12 deletions(-)
--- a/arch/arm/mach-imx/mmdc.c
+++ b/arch/arm/mach-imx/mmdc.c
@@ -60,6 +60,7 @@
#define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
+static enum cpuhp_state cpuhp_mmdc_state;
static int ddr_type;
struct fsl_mmdc_devtype_data {
@@ -451,8 +452,8 @@ static int imx_mmdc_remove(struct platfo
{
struct mmdc_pmu *pmu_mmdc = platform_get_drvdata(pdev);
+ cpuhp_state_remove_instance_nocalls(cpuhp_mmdc_state, &pmu_mmdc->node);
perf_pmu_unregister(&pmu_mmdc->pmu);
- cpuhp_remove_state_nocalls(CPUHP_ONLINE);
kfree(pmu_mmdc);
return 0;
}
@@ -472,6 +473,18 @@ static int imx_mmdc_perf_init(struct pla
return -ENOMEM;
}
+ /* The first instance registers the hotplug state */
+ if (!cpuhp_mmdc_state) {
+ ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
+ "perf/arm/mmdc:online", NULL,
+ mmdc_pmu_offline_cpu);
+ if (ret < 0) {
+ pr_err("cpuhp_setup_state_multi failed\n");
+ goto pmu_free;
+ }
+ cpuhp_mmdc_state = ret;
+ }
+
mmdc_num = mmdc_pmu_init(pmu_mmdc, mmdc_base, &pdev->dev);
if (mmdc_num == 0)
name = "mmdc";
@@ -485,26 +498,23 @@ static int imx_mmdc_perf_init(struct pla
HRTIMER_MODE_REL);
pmu_mmdc->hrtimer.function = mmdc_pmu_timer_handler;
- cpuhp_state_add_instance_nocalls(CPUHP_ONLINE,
- &pmu_mmdc->node);
- cpumask_set_cpu(smp_processor_id(), &pmu_mmdc->cpu);
- ret = cpuhp_setup_state_multi(CPUHP_AP_NOTIFY_ONLINE,
- "MMDC_ONLINE", NULL,
- mmdc_pmu_offline_cpu);
- if (ret) {
- pr_err("cpuhp_setup_state_multi failure\n");
- goto pmu_register_err;
- }
+ cpumask_set_cpu(raw_smp_processor_id(), &pmu_mmdc->cpu);
+
+ /* Register the pmu instance for cpu hotplug */
+ cpuhp_state_add_instance_nocalls(cpuhp_mmdc_state, &pmu_mmdc->node);
ret = perf_pmu_register(&(pmu_mmdc->pmu), name, -1);
- platform_set_drvdata(pdev, pmu_mmdc);
if (ret)
goto pmu_register_err;
+
+ platform_set_drvdata(pdev, pmu_mmdc);
return 0;
pmu_register_err:
pr_warn("MMDC Perf PMU failed (%d), disabled\n", ret);
+ cpuhp_state_remove_instance_nocalls(cpuhp_mmdc_state, &pmu_mmdc->node);
hrtimer_cancel(&pmu_mmdc->hrtimer);
+pmu_free:
kfree(pmu_mmdc);
return ret;
}
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -140,6 +140,7 @@ enum cpuhp_state {
CPUHP_AP_PERF_ARM_CCI_ONLINE,
CPUHP_AP_PERF_ARM_CCN_ONLINE,
CPUHP_AP_PERF_ARM_L2X0_ONLINE,
+ CPUHP_AP_PERF_ARM_MMDC_ONLINE,
CPUHP_AP_WORKQUEUE_ONLINE,
CPUHP_AP_RCUTREE_ONLINE,
CPUHP_AP_NOTIFY_ONLINE,
^ permalink raw reply
* [arm-platforms:kvm-arm64/gicv4-wip 17/39] drivers/irqchip/irq-gic-v3-its.c:698:24: error: 'id' undeclared
From: kbuild test robot @ 2016-12-21 18:26 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/gicv4-wip
head: 1bca4673c546185e9812e8479900eca8a3ca9c33
commit: 1136731f544e664ab2990fe615c049ead0479b6d [17/39] irqchip/gic-v3-its: Generalize LPI configuration
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1136731f544e664ab2990fe615c049ead0479b6d
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: the arm-platforms/kvm-arm64/gicv4-wip HEAD 1bca4673c546185e9812e8479900eca8a3ca9c33 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/irqchip/irq-gic-v3-its.c: In function 'lpi_update_config':
>> drivers/irqchip/irq-gic-v3-its.c:698:24: error: 'id' undeclared (first use in this function)
its_send_inv(its_dev, id);
^~
drivers/irqchip/irq-gic-v3-its.c:698:24: note: each undeclared identifier is reported only once for each function it appears in
vim +/id +698 drivers/irqchip/irq-gic-v3-its.c
c48ed51c Marc Zyngier 2014-11-24 692 * Humpf...
c48ed51c Marc Zyngier 2014-11-24 693 */
c48ed51c Marc Zyngier 2014-11-24 694 if (gic_rdists->flags & RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING)
c48ed51c Marc Zyngier 2014-11-24 695 __flush_dcache_area(cfg, sizeof(*cfg));
c48ed51c Marc Zyngier 2014-11-24 696 else
c48ed51c Marc Zyngier 2014-11-24 697 dsb(ishst);
c48ed51c Marc Zyngier 2014-11-24 @698 its_send_inv(its_dev, id);
c48ed51c Marc Zyngier 2014-11-24 699 }
c48ed51c Marc Zyngier 2014-11-24 700
c48ed51c Marc Zyngier 2014-11-24 701 static void its_mask_irq(struct irq_data *d)
:::::: The code at line 698 was first introduced by commit
:::::: c48ed51c0d101ec4351530bdd6e1a01808f0a441 irqchip: GICv3: ITS: irqchip implementation
:::::: TO: Marc Zyngier <marc.zyngier@arm.com>
:::::: CC: Jason Cooper <jason@lakedaemon.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 31902 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161222/15f88814/attachment-0001.gz>
^ permalink raw reply
* ARM: imx: mmdc: Fix completely broken cpu hotplug code
From: Thomas Gleixner @ 2016-12-21 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1612211917490.3424@nanos>
On Wed, 21 Dec 2016, Thomas Gleixner wrote:
> The cpu hotplug support of this perf driver is broken in several ways:
>
> 1) It adds a instance before setting up the state.
>
> 2) The state for the instance is different from the state of the
> callback. It's just a randomly chosen state.
>
> 3) The instance registration is not error checked so nobody noticed that
> the call can never succeed.
>
> 4) The state for the multi install callbacks is chosen randomly and
> overwrites existing state. This is now prevented by the core code so the
> call is guaranteed to fail.
>
> 5) The error exit path in the init function leaves the instance registered
> and then frees the memory which contains the enqueued hlist node.
>
> 6) The remove function is removing the state and not the instance.
>
> Fix it by:
>
> - Setting up the state before adding instances. Use a dynamically allocated
> state for it.
>
> - Install instances after the state has been set up
>
> - Remove the instance in the error path before freeing memory
>
> - Remove instance not the state in the driver remove callback
>
> While at is use raw_cpu_processor_id(), because cpu_processor_id() cannot
> be used in preemptible context, and set the driver data after successful
> registration of the pmu.
>
> Fixes: e76bdfd7403a ("ARM: imx: Added perf functionality to mmdc driver")
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: Zhengyu Shen <zhengyu.shen@nxp.com>
> Cc: Frank Li <frank.li@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
Shawn,
as I have the final hotplug notifier removal pending here, which will break
also the compilation of this driver, I would prefer to merge that through
my tree before the removal patches to avoid build breakage.
Thanks,
tglx
^ permalink raw reply
* [PATCH 10/18] arm64: ilp32: introduce binfmt_ilp32.c
From: Yury Norov @ 2016-12-21 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205153801.GE14429@e104818-lin.cambridge.arm.com>
On Mon, Dec 05, 2016 at 03:38:01PM +0000, Catalin Marinas wrote:
> On Fri, Oct 21, 2016 at 11:33:09PM +0300, Yury Norov wrote:
> > binfmt_ilp32.c is needed to handle ILP32 binaries
> >
> > Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> > Signed-off-by: Bamvor Zhang Jian <bamvor.zhangjian@linaro.org>
> > ---
> > arch/arm64/include/asm/elf.h | 6 +++
> > arch/arm64/kernel/Makefile | 1 +
> > arch/arm64/kernel/binfmt_ilp32.c | 97 ++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 104 insertions(+)
> > create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
> >
> > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> > index f259fe8..be29dde 100644
> > --- a/arch/arm64/include/asm/elf.h
> > +++ b/arch/arm64/include/asm/elf.h
> > @@ -175,10 +175,16 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
> >
> > #define COMPAT_ELF_ET_DYN_BASE (2 * TASK_SIZE_32 / 3)
> >
> > +#ifndef USE_AARCH64_GREG
> > /* AArch32 registers. */
> > #define COMPAT_ELF_NGREG 18
> > typedef unsigned int compat_elf_greg_t;
> > typedef compat_elf_greg_t compat_elf_gregset_t[COMPAT_ELF_NGREG];
> > +#else /* AArch64 registers for AARCH64/ILP32 */
> > +#define COMPAT_ELF_NGREG ELF_NGREG
> > +#define compat_elf_greg_t elf_greg_t
> > +#define compat_elf_gregset_t elf_gregset_t
> > +#endif
>
> I think you only need compat_elf_gregset_t definition here and leave the
> other two undefined.
I checked everything here again, and found that almost all compat defines
may be moved to corresponding binfmt files. If everything is OK, I'll
incorporate next patch to the series
Yury
--
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index abb75f5..76f0a5c 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -176,30 +176,10 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
#define COMPAT_ELF_ET_DYN_BASE (2 * TASK_SIZE_32 / 3)
-#ifndef USE_AARCH64_GREG
/* AArch32 registers. */
#define COMPAT_ELF_NGREG 18
typedef unsigned int compat_elf_greg_t;
typedef compat_elf_greg_t compat_elf_gregset_t[COMPAT_ELF_NGREG];
-#else /* AArch64 registers for AARCH64/ILP32 */
-#define COMPAT_ELF_NGREG ELF_NGREG
-#define compat_elf_greg_t elf_greg_t
-#define compat_elf_gregset_t elf_gregset_t
-#endif
-
-/* AArch32 EABI. */
-#define EF_ARM_EABI_MASK 0xff000000
-#define compat_elf_check_arch(x) (system_supports_32bit_el0() && \
- ((x)->e_machine == EM_ARM) && \
- ((x)->e_flags & EF_ARM_EABI_MASK))
-
-#define compat_start_thread compat_start_thread
-#define COMPAT_ARCH_DLINFO
-extern int aarch32_setup_vectors_page(struct linux_binprm *bprm,
- int uses_interp);
-#define compat_arch_setup_additional_pages \
- aarch32_setup_vectors_page
-
#endif /* CONFIG_COMPAT */
#endif /* !__ASSEMBLY__ */
diff --git a/arch/arm64/kernel/binfmt_elf32.c b/arch/arm64/kernel/binfmt_elf32.c
index 99a4cf2..7c38a22 100644
--- a/arch/arm64/kernel/binfmt_elf32.c
+++ b/arch/arm64/kernel/binfmt_elf32.c
@@ -17,16 +17,16 @@
#define COMPAT_ELF_HWCAP (compat_elf_hwcap)
#define COMPAT_ELF_HWCAP2 (compat_elf_hwcap2)
-#ifdef __AARCH64EB__
-#define COMPAT_ELF_PLATFORM ("v8b")
-#else
-#define COMPAT_ELF_PLATFORM ("v8l")
-#endif
-
#define compat_arch_setup_additional_pages \
aarch32_setup_vectors_page
struct linux_binprm;
extern int aarch32_setup_vectors_page(struct linux_binprm *bprm,
int uses_interp);
+/* AArch32 EABI. */
+#define compat_elf_check_arch(x) (system_supports_32bit_el0() && \
+ ((x)->e_machine == EM_ARM) && \
+ ((x)->e_flags & EF_ARM_EABI_MASK))
+
+
#include "../../../fs/compat_binfmt_elf.c"
diff --git a/arch/arm64/kernel/binfmt_ilp32.c b/arch/arm64/kernel/binfmt_ilp32.c
index dd62467..ec4a412 100644
--- a/arch/arm64/kernel/binfmt_ilp32.c
+++ b/arch/arm64/kernel/binfmt_ilp32.c
@@ -1,7 +1,9 @@
/*
* Support for ILP32 Linux/aarch64 ELF binaries.
*/
-#define USE_AARCH64_GREG
+
+#undef compat_elf_gregset_t
+#define compat_elf_gregset_t elf_gregset_t
#include <linux/elfcore-compat.h>
#include <linux/time.h>
^ permalink raw reply related
* [PATCH 2/2] mfd: mc13xxx: Pass the IRQF_TRIGGER_HIGH flag.
From: Magnus Lilja @ 2016-12-21 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482300049.831956101@f373.i.mail.ru>
Hi,
On 21 December 2016 at 07:00, Alexander Shiyan <shc_work@mail.ru> wrote:
>>???????, 20 ??????? 2016, 22:35 +03:00 ?? Magnus Lilja <lilja.magnus@gmail.com>:
>>
>>On 20 December 2016 at 06:20, Alexander Shiyan < shc_work@mail.ru > wrote:
>>>>???????, 20 ??????? 2016, 0:28 +03:00 ?? Magnus Lilja < lilja.magnus@gmail.com >:
>>>>
>>>>All supported mc13xxx devices have active high interrupt outputs. Make sure
>>>>to configure the interrupt as active high by passing the IRQF_TRIGGER_HIGH
>>>>flag. This is required at least on the i.MX31 PDK board.
>>>>
>>>>Signed-off-by: Magnus Lilja < lilja.magnus@gmail.com >
>>>>---
>>>>
>>>> drivers/mfd/mc13xxx-core.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>>diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
>>>>index d7f54e4..4cbe6b7 100644
>>>>--- a/drivers/mfd/mc13xxx-core.c
>>>>+++ b/drivers/mfd/mc13xxx-core.c
>>>>@@ -440,7 +440,7 @@ int mc13xxx_common_init(struct device *dev)
>>>> mc13xxx->irq_chip.irqs = mc13xxx->irqs;
>>>> mc13xxx->irq_chip.num_irqs = ARRAY_SIZE(mc13xxx->irqs);
>>>>
>>>>-ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq, IRQF_ONESHOT,
>>>>+ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq, IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
>>>> 0, &mc13xxx->irq_chip, &mc13xxx->irq_data);
>>>> if (ret)
>>>> return ret;
>>>
>>> IRQ line can be passed through inverter to IC.
>>> On my opinion the best way to handle all possible situations is parse
>>> devicetree IRQ flags and pass to the driver.
>>
>>My guess is that most boards follow the evaluation boards/kits and
>>don't have an inverter so I think the default should be TRIG_HIGH
>>since that will make most boards work automatically. But I can have a
>>look at making it configurable (with and without the use of device
>>tree), but for the device tree stuff I would need pointers to similar
>>code since my experience with that is none.
>>Any pointers to similar code?
>
> Hello.
>
> Perhaps I'm wrong and the desired active level has setup at the IRQ code level.
Don't think I understand what you mean here.
> Otherwise, I think you need to use something like the following:
>
> unsigned flags = irqd_get_trigger_type(irq_get_irq_data(irq));
> flags = (flags == IRQ_TYPE_NONE) ? IRQF_TRIGGER_HIGH : flags;
> ret = regmap_add_irq_chip(..., IRQF_ONESHOT | flags, ...);
That would work but I don't know how one would set the trigger type in
case of not using device trees. But that would only be a problem if a
board really has an inverter on the IRQ line so that can be solved
later, and might be not necessary to solve if mx31 boards are
converted to device tree usage.
I guess that get trigger_type can be set via the device tree magic
when using device trees.
Regards, Magnus
^ permalink raw reply
* [PATCH 1/3] dt-bindings: add vendor prefix for Lichee Pi
From: Icenowy Zheng @ 2016-12-21 20:02 UTC (permalink / raw)
To: linux-arm-kernel
Lichee Pi is a new "Pi"-named development board series.
Currently available device, Lichee Pi One, is by only one person as
night job, so the device series name is chosen to be the vendor prefix.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 16d3b5e7f5d1..4ec84b7a3c56 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -161,6 +161,7 @@ lacie LaCie
lantiq Lantiq Semiconductor
lenovo Lenovo Group Ltd.
lg LG Corporation
+licheepi Lichee Pi
linux Linux-specific binding
lltc Linear Technology Corporation
lsi LSI Corp. (LSI Logic)
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: sun5i: add a pinctrl node for 4bit mmc2
From: Icenowy Zheng @ 2016-12-21 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221200235.11617-1-icenowy@aosc.xyz>
Some board only use 4bit mode of mmc2.
Add a pinctrl node for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun5i.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 54170147040f..c058d37d5433 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -594,6 +594,14 @@
bias-pull-up;
};
+ mmc2_4bit_pins_a: mmc2-4bit at 0 {
+ pins = "PC6", "PC7", "PC8", "PC9",
+ "PC10", "PC11";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
spi2_pins_a: spi2 at 0 {
pins = "PE1", "PE2", "PE3";
function = "spi2";
--
2.11.0
^ permalink raw reply related
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