* [GIT PULL] ARM: mvebu: drivers for v4.9 (#1)
From: Gregory CLEMENT @ 2016-09-21 10:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the second tentative of first pull request for drivers for
mvebu for v4.9.
This time both patches received their Acked-by.
Gregory
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-drivers-4.9-1
for you to fetch changes up to c336dc7dac0747f6a4901bcd5a497e1b3fb265d7:
pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181 (2016-09-21 11:49:18 +0200)
----------------------------------------------------------------
mvebu drivers for 4.9 (part 1)
- Add pinctrl and clk support for the Orion5x SoC mv88f5181 variant
----------------------------------------------------------------
Jamie Lentin (2):
clk: mvebu: Add clk support for the orion5x SoC mv88f5181
pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181
.../devicetree/bindings/clock/mvebu-core-clock.txt | 1 +
.../bindings/pinctrl/marvell,orion-pinctrl.txt | 4 +-
drivers/clk/mvebu/orion.c | 70 ++++++++++++++++++++++
drivers/pinctrl/mvebu/pinctrl-orion.c | 23 +++----
4 files changed, 86 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH] clk: nxp: clk-lpc32xx: Unmap region obtained by of_iomap
From: Vladimir Zapolskiy @ 2016-09-21 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474368846-15916-1-git-send-email-arvind.yadav.cs@gmail.com>
On 20.09.2016 13:54, Arvind Yadav wrote:
> From: Arvind Yadav <arvind.yadav.cs@gmail.com>
>
> Free memory mapping, if lpc32xx_clk_init is not successful.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
> drivers/clk/nxp/clk-lpc32xx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
> index 90d740a..34c9735 100644
> --- a/drivers/clk/nxp/clk-lpc32xx.c
> +++ b/drivers/clk/nxp/clk-lpc32xx.c
> @@ -1513,6 +1513,7 @@ static void __init lpc32xx_clk_init(struct device_node *np)
> if (IS_ERR(clk_regmap)) {
> pr_err("failed to regmap system control block: %ld\n",
> PTR_ERR(clk_regmap));
> + iounmap(base);
> return;
> }
>
>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Thank you for the patch.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH] clk: mvebu: Add clk support for the orion5x SoC mv88f5181
From: Gregory CLEMENT @ 2016-09-21 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920195919.GD8319@codeaurora.org>
Hi Stephen,
On mar., sept. 20 2016, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 09/20, Gregory CLEMENT wrote:
>> From: Jamie Lentin <jm@lentin.co.uk>
>>
>> Referring to the u-boot sources for the Netgear WNR854T, add support
>> for the mv88f5181.
>>
>> [gregory.clement at free-electrons.com: fix commit title]
>> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
>> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>>
>> Hi Stephen and Mike,
>>
>> do you agree to give your acked-by on this patch. It is part of a
>> convertion of old orion5x Socv to the device tree. If you acked-by
>> this one, then I will be able to take it in my tree and avoiding
>> breaking the git bisect.
>
> Is the problem that we're changing some dts files somewhere and
> those platforms would stop booting if this change wasn't present?
> Given that we're adding a new compatible it seems like we're
> adding new SoC support, so having the clk patch and the dts patch
> come together in -next via a merge instead of basing the dts
> patch on top of the clk patch would be how things are normally
> done.
The problem appear if the dts for the board using the clock driver is
merged in Linus tree before the support in the driver. At this point the
board won't be able to boot.
It introduces a hole in the git bisect between the merge of the clock
subsystem and the arm-soc subsystem.
>
> If we're really changing some dts to be backwards incompatible,
> then I understand the bisect problem and you can have my ack.
>
> Acked-by: Stephen Boyd <sboyd@codeaurora.org.
Thanks,
Gregory
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH V3 3/4] ARM64 LPC: support serial based on low-pin-count
From: zhichang @ 2016-09-21 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5525856.MfDSSsiP5d@wuerfel>
On 2016?09?15? 05:33, Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 11:04:33 PM CEST zhichang.yuan wrote:
>> The 8250_hisi_lpc.c support both ACPI and dts similar to 8250_dw :
>>
>> +static struct platform_driver hs_lpc8250_driver = {
>> + .driver = {
>> + .name = "hisi-lpc-uart",
>> + .of_match_table = hs8250_of_match,
>> + .acpi_match_table = ACPI_PTR(hs8250_acpi_match),
>>
>> So, I am a little confused why we need to support dts in 8250_of.c and support ACPI in another
>> driver file.
>>
>
> After looking again, I'm pretty sure that drivers/tty/serial/8250/8250_pnp.c
> will handle the ACPI case without modifications, you just need to adapt
> the 8250_of driver to handle IORESOURCE_IO ports. This will be required
> anyway with the next version once the LPC bridge is on the PCI bus.
>
Yes. You are right.
When the indirectIO patch is accepted, no much changes needed in these two file to support LPC UART.
BTW, what is your target to change these two files to support LPC uart?
Do you think we don't need to add many new c files??
Best,
Zhichang
> Arnd
>
^ permalink raw reply
* [PATCH] pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181
From: Gregory CLEMENT @ 2016-09-21 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbo6JmR=K58KQ_J0Gd5_gLqub65watU-iEabQ0rWdeVpQ@mail.gmail.com>
Hi Linus,
On mar., sept. 20 2016, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Sep 20, 2016 at 6:26 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>
>> From: Jamie Lentin <jm@lentin.co.uk>
>>
>> As far as I'm aware the mv88f5181-b1 and mv88f5181l are the same at the
>> pinctrl level, so re-use the definitions for both.
>>
>> [gregory.clement at free-electrons.com: fix commit title]
>> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
>> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> Is this the patch from your pull request?
yes this one.
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Or do you prefer that I take it into the pinctrl tree?
No it is ok, it will be in the second tentaive of my pull request.
Thanks,
Gregory
>
> Yours,
> Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC] irqchip/gic-v3: Implement suspend and resume callbacks
From: Marc Zyngier @ 2016-09-21 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474447359-29551-1-git-send-email-clingutla@codeaurora.org>
+Sudeep, Lorenzo,
On 21/09/16 09:42, Lingutla Chandrasekhar wrote:
> Implement suspend and resume syscore_ops to disable and
> enable non wake up capable interrupts.
>
> When system enters suspend, enable only wakeup capable
> interrupts. While resuming, enable previously enabled interrupts
> and show triggered/pending interrupts.
The fundamental problem (which you're not mentioning at all) is that the
GICv3 architecture doesn't mention wake-up interrupts at all, so this
has to be entirely handled in firmware. Is that what is happening?
>
> Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index ede5672..511a5a1 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -33,6 +33,7 @@
> #include <linux/irqchip/arm-gic-common.h>
> #include <linux/irqchip/arm-gic-v3.h>
> #include <linux/irqchip/irq-partition-percpu.h>
> +#include <linux/syscore_ops.h>
>
> #include <asm/cputype.h>
> #include <asm/exception.h>
> @@ -57,6 +58,10 @@ struct gic_chip_data {
> u32 nr_redist_regions;
> unsigned int irq_nr;
> struct partition_desc *ppi_descs[16];
> +#ifdef CONFIG_PM
> + unsigned int wakeup_irqs[32];
> + unsigned int enabled_irqs[32];
Do not use ambiguous types for something that comes from the HW. Where
does this '32' comes from?
> +#endif
> };
>
> static struct gic_chip_data gic_data __read_mostly;
> @@ -330,6 +335,81 @@ static int gic_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu)
> return 0;
> }
>
> +#ifdef CONFIG_PM
> +static int gic_suspend(void)
> +{
> + unsigned int i;
> + void __iomem *base = gic_data.dist_base;
> +
> + for (i = 0; i * 32 < gic->irq_nr; i++) {
> + gic->enabled_irqs[i]
> + = readl_relaxed(base + GICD_ISENABLER + i * 4);
Do you realize that GICD_ISENABLER0 is always zero? What do you do for
PPIs? Please keep the assignment on a single line.
> + /* disable all of them */
> + writel_relaxed(0xffffffff, base + GICD_ICENABLER + i * 4);
> + /* enable the wakeup set */
> + writel_relaxed(gic->wakeup_irqs[i],
> + base + GICD_ISENABLER + i * 4);
On a single line as well.
> + }
> + return 0;
> +}
> +
> +static void gic_show_pending(void)
> +{
> + unsigned int i;
> + u32 enabled;
> + u32 pending[32];
> + void __iomem *base = gic_data.dist_base;
> +
> + for (i = 0; i * 32 < gic->irq_nr; i++) {
> + enabled = readl_relaxed(base + GICD_ICENABLER + i * 4);
> + pending[i] = readl_relaxed(base + GICD_ISPENDR + i * 4);
> + pending[i] &= enabled;
> + }
> +
> + for_each_set_bit(i, (unsigned long *)pending, gic->irq_nr) {
> + unsigned int irq = irq_find_mapping(gic->domain, i);
> + struct irq_desc *desc = irq_to_desc(irq);
> + const char *name = "null";
> +
> + if (desc == NULL)
> + name = "stray irq";
> + else if (desc->action && desc->action->name)
> + name = desc->action->name;
> +
> + pr_debug("Pending IRQ: %d [%s]\n", __func__, irq, name);
> + }
> +}
Please drop this function from this patch, it doesn't serve any purpose
other than your own debugging.
> +
> +static void gic_resume(void)
> +{
> + unsigned int i;
> + void __iomem *base = gic_data.dist_base;
> +
> + gic_show_pending();
> +
> + for (i = 0; i * 32 < gic->irq_nr; i++) {
> + /* disable all of them */
> + writel_relaxed(0xffffffff, base + GICD_ICENABLER + i * 4);
> + /* enable the enabled set */
> + writel_relaxed(gic->enabled_irqs[i],
> + base + GICD_ISENABLER + i * 4);
Same remarks as the suspend side.
> + }
> +}
> +
> +static struct syscore_ops gic_syscore_ops = {
> + .suspend = gic_suspend,
> + .resume = gic_resume,
> +};
> +
> +static int __init gic_init_sys(void)
> +{
> + register_syscore_ops(&gic_syscore_ops);
> + return 0;
> +}
> +device_initcall(gic_init_sys);
> +
> +#endif
> +
> static u64 gic_mpidr_to_affinity(unsigned long mpidr)
> {
> u64 aff;
> @@ -666,6 +746,32 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
> #define gic_smp_init() do { } while(0)
> #endif
>
> +#ifdef CONFIG_PM
> +int gic_set_wake(struct irq_data *d, unsigned int on)
> +{
> + int ret = -ENXIO;
> + unsigned int reg_offset, bit_offset;
> + unsigned int gicirq = gic_irq(d);
> + struct gic_chip_data *gic_data = irq_data_get_irq_chip_data(d);
> +
> + /* per-cpu interrupts cannot be wakeup interrupts */
> + WARN_ON(gicirq < 32);
How did you decide that? There is no such specification anywhere.
> +
> + reg_offset = gicirq / 32;
> + bit_offset = gicirq % 32;
> +
> + if (on)
> + gic_data->wakeup_irqs[reg_offset] |= 1 << bit_offset;
> + else
> + gic_data->wakeup_irqs[reg_offset] &= ~(1 << bit_offset);
> +
> + return ret;
> +}
> +
> +#else
> +#define gic_set_wake NULL
> +#endif
> +
> #ifdef CONFIG_CPU_PM
> /* Check whether it's single security state view */
> static bool gic_dist_security_disabled(void)
> @@ -707,6 +813,7 @@ static struct irq_chip gic_chip = {
> .irq_eoi = gic_eoi_irq,
> .irq_set_type = gic_set_type,
> .irq_set_affinity = gic_set_affinity,
> + .irq_set_wake = gic_set_wake,
> .irq_get_irqchip_state = gic_irq_get_irqchip_state,
> .irq_set_irqchip_state = gic_irq_set_irqchip_state,
> .flags = IRQCHIP_SET_TYPE_MASKED,
> @@ -723,6 +830,7 @@ static struct irq_chip gic_eoimode1_chip = {
> .irq_set_irqchip_state = gic_irq_set_irqchip_state,
> .irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity,
> .flags = IRQCHIP_SET_TYPE_MASKED,
> + .irq_set_wake = gic_set_wake,
Keep the fields in the same order.
> };
>
> #define GIC_ID_NR (1U << gic_data.rdists.id_bits)
>
But here's my fundamental objection: None of that should be required and
setting (IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MASK_ON_SUSPEND) as part of the
irqchip flags should be enough.
Can you explain why this doesn't work for you?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 2/4] ARM: tegra: nyan: Use external control for bq24735 charger
From: Jon Hunter @ 2016-09-21 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474444619.1239.13.camel@paulk.fr>
On 21/09/16 08:56, Paul Kocialkowski wrote:
...
> Sure, this is exported at: /sys/class/power_supply/bq24735 at 5-0009
> Also, note that the power-supply next branch[2] has some more fixes for the
> bq24735 driver.
I tested the bq24735 on next-20160919 without any of your changes and
when connecting or disconnecting the charger I see the following panic.
Do you see this?
Jon
/ # [ 30.120384] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 30.128489] pgd = c0004000
[ 30.131187] [00000004] *pgd=00000000
[ 30.134759] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 30.140141] Modules linked in:
[ 30.143192] CPU: 1 PID: 71 Comm: kworker/1:1 Not tainted 4.8.0-rc6-next-20160919-00002-gbc9771827865-dirty #574
[ 30.153254] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[ 30.159509] Workqueue: events power_supply_changed_work
[ 30.164723] task: ee19f880 task.stack: ee1a0000
[ 30.169239] PC is at sbs_external_power_changed+0x50/0x5c
[ 30.174624] LR is at mod_timer+0x194/0x270
[ 30.178705] pc : [<c05b0c58>] lr : [<c017cda0>] psr: 60000113
[ 30.178705] sp : ee1a1eb8 ip : 80000000 fp : ee8e3680
[ 30.190155] r10: eef98580 r9 : 00000000 r8 : 00000000
[ 30.195363] r7 : ee303000 r6 : c05afef8 r5 : ee3e03f8 r4 : ee3e03d0
[ 30.201872] r3 : 00000000 r2 : 00000000 r1 : 40000193 r0 : 00000001
[ 30.208382] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 30.215497] Control: 10c5387d Table: adcf006a DAC: 00000051
[ 30.221226] Process kworker/1:1 (pid: 71, stack limit = 0xee1a0210)
[ 30.227474] Stack: (0xee1a1eb8 to 0xee1a2000)
[ 30.231816] 1ea0: edc0bc00 ee303000
[ 30.239973] 1ec0: c05afef8 c05aff2c edc0bc20 c045ec1c eef95c80 eef95c80 00000001 eea82d5c
[ 30.248136] 1ee0: edc0bd98 00000000 ee3031c0 ee303218 c0eab740 c05afcc4 ee8e3680 ee3031c0
[ 30.256296] 1f00: eef9b800 00000000 eef98580 c0135824 eef98598 c0e02100 eef98580 ee8e3698
[ 30.264453] 1f20: 00000008 eef98598 c0e02100 ee1a0000 eef98580 c0135a74 ee840f80 ee8e3680
[ 30.272610] 1f40: c0135a3c 00000000 ee840f80 ee8e3680 c0135a3c 00000000 00000000 00000000
[ 30.280766] 1f60: 00000000 c013af18 00000000 00000000 00000000 ee8e3680 00000000 00000000
[ 30.288922] 1f80: ee1a1f80 ee1a1f80 00000000 00000000 ee1a1f90 ee1a1f90 ee1a1fac ee840f80
[ 30.297078] 1fa0: c013ae3c 00000000 00000000 c01078b8 00000000 00000000 00000000 00000000
[ 30.305234] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 30.313389] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 30.321555] [<c05b0c58>] (sbs_external_power_changed) from [<c05aff2c>] (__power_supply_changed_work+0x34/0x3c)
[ 30.331623] [<c05aff2c>] (__power_supply_changed_work) from [<c045ec1c>] (class_for_each_device+0x4c/0xb4)
[ 30.341254] [<c045ec1c>] (class_for_each_device) from [<c05afcc4>] (power_supply_changed_work+0x5c/0xb0)
[ 30.350713] [<c05afcc4>] (power_supply_changed_work) from [<c0135824>] (process_one_work+0x124/0x33c)
[ 30.359912] [<c0135824>] (process_one_work) from [<c0135a74>] (worker_thread+0x38/0x4d4)
[ 30.367983] [<c0135a74>] (worker_thread) from [<c013af18>] (kthread+0xdc/0xf4)
[ 30.375187] [<c013af18>] (kthread) from [<c01078b8>] (ret_from_fork+0x14/0x3c)
[ 30.382391] Code: e5911000 e3a00004 ebee0b88 e5943008 (e5933004)
[ 30.388504] ---[ end trace 083d55597e9a2254 ]---
[ 30.393140] Unable to handle kernel paging request at virtual address ffffffec
[ 30.400342] pgd = c0004000
[ 30.403038] [ffffffec] *pgd=afffd861, *pte=00000000, *ppte=00000000
[ 30.409309] Internal error: Oops: 37 [#2] PREEMPT SMP ARM
[ 30.414690] Modules linked in:
[ 30.417738] CPU: 1 PID: 71 Comm: kworker/1:1 Tainted: G D 4.8.0-rc6-next-20160919-00002-gbc9771827865-dirty #574
[ 30.429013] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[ 30.435265] task: ee19f880 task.stack: ee1a0000
[ 30.439782] PC is at kthread_data+0x4/0xc
[ 30.443779] LR is at wq_worker_sleeping+0x8/0xc8
[ 30.448381] pc : [<c013b8a8>] lr : [<c01366e0>] psr: 20000193
[ 30.448381] sp : ee1a1c58 ip : eef98f28 fp : ee1a1cb4
[ 30.459836] r10: eef98a00 r9 : c0e5f000 r8 : c0d9ea00
[ 30.465048] r7 : ee19fcc8 r6 : c0e02e08 r5 : ee19f880 r4 : eef98a00
[ 30.471556] r3 : 00000000 r2 : 00000020 r1 : 00000000 r0 : ee19f880
[ 30.478066] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
[ 30.485268] Control: 10c5387d Table: adcf006a DAC: 00000051
[ 30.490998] Process kworker/1:1 (pid: 71, stack limit = 0xee1a0210)
[ 30.497247] Stack: (0xee1a1c58 to 0xee1a2000)
[ 30.501590] 1c40: eef98a00 c0833a68
[ 30.509747] 1c60: 00000001 ee117a44 c0d99280 a0000193 00000000 c0833d4c 00000001 ee117a44
[ 30.517904] 1c80: 00000000 ee117540 ee19f880 c01faf3c 00000000 ee1a0000 ee1a18ec 00000001
[ 30.526060] 1ca0: ee1a1cc8 ee19fc40 c05b0c5c 00000001 ee1a1cc4 c0833d4c ee19f880 ee1a18ec
[ 30.534217] 1cc0: ee85d3c0 c012277c ee1a1cc8 ee1a1cc8 00000000 c0e5e2c4 c0e07638 ee1a1e68
[ 30.542374] 1ce0: 60000113 0000000b c05b0c5c 00000001 c05b0c5a c010b6f8 ee1a0210 0000000b
[ 30.550530] 1d00: c0e07638 ee1a0000 bf000000 00000008 65000000 31313935 20303030 30613365
[ 30.558687] 1d20: 34303030 65626520 38623065 35652038 30333439 28203830 33393565 34303033
[ 30.566843] 1d40: 00002029 c01b63c4 c0004000 00000004 ee1a1e68 00000017 00000000 00000017
[ 30.575000] 1d60: 00000004 eef98580 ee8e3680 c011a424 00000004 c0115c20 ee19f880 00000000
[ 30.583156] 1d80: ee19f900 ee2ecd80 ee19f880 c014a55c c014a460 ee19f880 eef98a00 00000000
[ 30.591312] 1da0: a0000193 c0e07efc 00000017 c0115888 00000004 ee1a1e68 ee1a0000 eef98580
[ 30.599469] 1dc0: ee8e3680 c01012ac 1514622a 00000000 ee19f900 c0149578 eef98a00 ee19f900
[ 30.607626] 1de0: 00000001 00000000 eef98a38 00000000 000043e1 c014e11c ee2ecd00 ee19f900
[ 30.615781] 1e00: 00000010 00000000 00000006 00000000 00000000 edc45440 c0d992c4 00000000
[ 30.623938] 1e20: 00000001 00000000 00000000 00000001 00004b4e 00000000 00000001 c0e5f000
[ 30.632095] 1e40: 00000000 00000000 ee19f900 ee19f900 c05b0c58 60000113 ffffffff ee1a1e9c
[ 30.640251] 1e60: 00000000 c010bd78 00000001 40000193 00000000 00000000 ee3e03d0 ee3e03f8
[ 30.648408] 1e80: c05afef8 ee303000 00000000 00000000 eef98580 ee8e3680 80000000 ee1a1eb8
[ 30.656566] 1ea0: c017cda0 c05b0c58 60000113 ffffffff 00000051 00000000 edc0bc00 ee303000
[ 30.664722] 1ec0: c05afef8 c05aff2c edc0bc20 c045ec1c eef95c80 eef95c80 00000001 eea82d5c
[ 30.672886] 1ee0: edc0bd98 00000000 ee3031c0 ee303218 c0eab740 c05afcc4 ee8e3680 ee3031c0
[ 30.681045] 1f00: eef9b800 00000000 eef98580 c0135824 eef98598 c0e02100 eef98580 ee8e3698
[ 30.689202] 1f20: 00000008 eef98598 c0e02100 ee1a0000 eef98580 c0135a74 ee840f80 ee8e3680
[ 30.697358] 1f40: c0135a3c 00000000 ee840f80 ee8e3680 c0135a3c 00000000 00000000 00000000
[ 30.705515] 1f60: 00000000 c013af18 00000000 00000000 00000000 ee8e3680 00000000 00000000
[ 30.713672] 1f80: ee1a1f80 ee1a1f80 00000001 00010001 ee1a1f90 ee1a1f90 ee1a1fac ee840f80
[ 30.721827] 1fa0: c013ae3c 00000000 00000000 c01078b8 00000000 00000000 00000000 00000000
[ 30.729983] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 30.738140] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 30.746304] [<c013b8a8>] (kthread_data) from [<c01366e0>] (wq_worker_sleeping+0x8/0xc8)
[ 30.754292] [<c01366e0>] (wq_worker_sleeping) from [<c0833a68>] (__schedule+0x45c/0x6f0)
[ 30.762364] [<c0833a68>] (__schedule) from [<c0833d4c>] (schedule+0x50/0xb4)
[ 30.769394] [<c0833d4c>] (schedule) from [<c012277c>] (do_exit+0x6e8/0xa90)
[ 30.776340] [<c012277c>] (do_exit) from [<c010b6f8>] (die+0x470/0x488)
[ 30.782853] [<c010b6f8>] (die) from [<c011a424>] (__do_kernel_fault.part.0+0x64/0x1e4)
[ 30.790751] [<c011a424>] (__do_kernel_fault.part.0) from [<c0115c20>] (do_page_fault+0x398/0x3a4)
[ 30.799601] [<c0115c20>] (do_page_fault) from [<c01012ac>] (do_DataAbort+0x38/0xb8)
[ 30.807238] [<c01012ac>] (do_DataAbort) from [<c010bd78>] (__dabt_svc+0x58/0x80)
[ 30.814613] Exception stack(0xee1a1e68 to 0xee1a1eb0)
[ 30.819650] 1e60: 00000001 40000193 00000000 00000000 ee3e03d0 ee3e03f8
[ 30.827807] 1e80: c05afef8 ee303000 00000000 00000000 eef98580 ee8e3680 80000000 ee1a1eb8
[ 30.835962] 1ea0: c017cda0 c05b0c58 60000113 ffffffff
[ 30.841002] [<c010bd78>] (__dabt_svc) from [<c05b0c58>] (sbs_external_power_changed+0x50/0x5c)
[ 30.849593] [<c05b0c58>] (sbs_external_power_changed) from [<c05aff2c>] (__power_supply_changed_work+0x34/0x3c)
[ 30.859660] [<c05aff2c>] (__power_supply_changed_work) from [<c045ec1c>] (class_for_each_device+0x4c/0xb4)
[ 30.869291] [<c045ec1c>] (class_for_each_device) from [<c05afcc4>] (power_supply_changed_work+0x5c/0xb0)
[ 30.878762] [<c05afcc4>] (power_supply_changed_work) from [<c0135824>] (process_one_work+0x124/0x33c)
[ 30.887963] [<c0135824>] (process_one_work) from [<c0135a74>] (worker_thread+0x38/0x4d4)
[ 30.896034] [<c0135a74>] (worker_thread) from [<c013af18>] (kthread+0xdc/0xf4)
[ 30.903240] [<c013af18>] (kthread) from [<c01078b8>] (ret_from_fork+0x14/0x3c)
[ 30.910443] Code: e34c00a4 ebff90d2 eafffff2 e5903418 (e5130014)
[ 30.916520] ---[ end trace 083d55597e9a2255 ]---
[ 30.921122] Fixing recursive fault but reboot is needed!
--
nvpublic
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang @ 2016-09-21 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26171742.fWcrANu6EP@wuerfel>
Hi, Arnd,
On 2016?09?15? 20:24, Arnd Bergmann wrote:
> On Thursday, September 15, 2016 12:05:51 PM CEST Gabriele Paoloni wrote:
>>> -----Original Message-----
>>> On Thursday, September 15, 2016 8:02:27 AM CEST Gabriele Paoloni wrote:
>>>>
>>>> From <<3.1.1. Open Firmware Properties for Bus Nodes>> in
>>>> http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
>>>>
>>>> I quote:
>>>> "There shall be an entry in the "ranges" property for each
>>>> of the Memory and/or I/O spaces if that address space is
>>>> mapped through the bridge."
>>>>
>>>> It seems to me that it is ok to have 1:1 address mapping and that
>>>> therefore of_translate_address() should fail if "ranges" is not
>>>> present.
>>>
>>> The key here is the definition of "mapped through the bridge".
>>> I can only understand this as "directly mapped", i.e. an I/O
>>> port of the child bus corresponds directly to a memory address
>>> on the parent bus, but this is not the case here.
>>>
>>> The problem with adding the mapping here is that it looks
>>> like it should be valid to create a page table entry for
>>> the address returned from the translation and access it through
>>> a pointer dereference, but that is clearly not possible.
>>
>> I understand that somehow we are abusing of the ranges property
>> here however the point is that with the current implementation ranges
>> is needed because otherwise the ipmi driver probe will fail here:
>>
>> of_ipmi_probe -> of_address_to_resource -> __of_address_to_resource
>> -> of_translate_address -> __of_translate_address
>>
>> Now we had a bit of discussion internally and to avoid
>> having ranges we came up with two possible solutions:
>>
>> 1) Using bit 3 of phys.hi cell in 2.2.1 of
>> http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
>> This would mean reworking of_bus_isa_get_flags in
>> http://lxr.free-electrons.com/source/drivers/of/address.c#L398
>> and setting a new flag to be checked in __of_address_to_resource
>>
>> 2) Adding a property in the bindings of each device that is
>> a child of our LPC bus and modify __of_address_to_resource
>> to check if the property is in the DT and eventually bypass
>> of_translate_address
>>
>> However in both 1) and 2) there are some issues:
>> in 1) we are not complying with the isa binding doc (we use
>> a bit that should be zero); in 2) we need to modify the
>> bindings documentation of the devices that are connected
>> to our LPC controller (therefore modifying other devices
>> bindings to fit our special case).
>>
>> I think that maybe having the 1:1 range mapping doesn't
>> reflect well the reality but it is the less painful
>> solution...
>>
>> What's your view?
>
> We can check the 'i' bit for I/O space in of_bus_isa_get_flags,
> and that should be enough to translate the I/O port number.
>
> The only part we need to change here is to not go through
> the crazy conversion all the way from PCI I/O space to a
> physical address and back to a (logical) port number
> that we do today with of_translate_address/pci_address_to_pio.
>
Sorry for the late response! Several days' leave....
Do you want to bypass of_translate_address and pci_address_to_pio for the registered specific PIO?
I think the bypass for of_translate_address is ok, but worry some new issues will emerge without the
conversion between physical address and logical/linux port number.
When PCI host bridge which support IO operations is configured and enabled, the pci_address_to_pio will
populate the logical IO range from ZERO for the first host bridge. Our LPC will also use part of the IO range
started from ZERO. It will make in/out enter the wrong branch possibly.
In V2, the 0 - 0x1000 logical IO range is reserved for LPC use only. But it seems not so good. In this way,
PCI has no chance to use low 4K IO range(logical).
So, in V3, applying the conversion from physical/cpu address to logical/linux IO port for any IO ranges,
including the LPC, but recorded the logical IO range for LPC. When calling in/out with a logical port address,
we can check this port fall into LPC logical IO range and get back the real IO.
Do you have further comments about this??
> I can think of a several of ways to fix __of_address_to_resource
> to just do the right thing according to the ISA binding to
> make the normal drivers work.
>
> The easiest solution is probably to hook into the
> "taddr == OF_BAD_ADDR" case in __of_address_to_resource
> and add a lookup for ISA buses there, and instead check
> if some special I/O port operations were registered
> for the port number, using an architecture specific
> function that arm64 implements. Other architectures
> like x86 that don't have a direct mapping between I/O
> ports and MMIO addresses would implement that same
> function differently.
What about add the specific quirk for Hip06 LPC in of_empty_ranges_quirk()??
you know, there are several cases in which of_translate_address return OF_BAD_ADDR.
And if we only check the special port range, it seems a bit risky. If some device want to use this port range
when no hip06 LPC is configured, the checking does not work. I think we should also check the relevant device.
Best,
Zhichang
>
> Arnd
>
^ permalink raw reply
* [PATCH] gpio: Added zynq specific check for special pins on bank zero
From: Shubhrajyoti Datta @ 2016-09-21 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474360324-8168-1-git-send-email-navam@xilinx.com>
On Tue, Sep 20, 2016 at 2:02 PM, Nava kishore Manne
<nava.manne@xilinx.com> wrote:
> From: Nava kishore Manne <nava.manne@xilinx.com>
>
> This patch adds zynq specific check for bank 0 pins 7 and 8
> are special and cannot be used as inputs
Is there any such pins for zynqmp?
>
> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
> ---
> drivers/gpio/gpio-zynq.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
> index e72794e..eae9d24 100644
> --- a/drivers/gpio/gpio-zynq.c
> +++ b/drivers/gpio/gpio-zynq.c
> @@ -96,6 +96,10 @@
> /* GPIO upper 16 bit mask */
> #define ZYNQ_GPIO_UPPER_MASK 0xFFFF0000
>
> +/* For GPIO quirks */
> +#define ZYNQ_GPIO BIT(0)
> +#define ZYNQMP_GPIO BIT(1)
if not can we remove ZYNQMP_GPIO ?
^ permalink raw reply
* [PATCH v5 02/16] dt/bindings: Update binding for PM domain idle states
From: Brendan Jackman @ 2016-09-21 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160920161748.GB46914@linaro.org>
On Tue, Sep 20 2016 at 17:17, Lina Iyer <lina.iyer@linaro.org> wrote:
> On Mon, Sep 19 2016 at 09:09 -0600, Brendan Jackman wrote:
>>
>>On Fri, Sep 16 2016 at 18:39, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> Hi Kevin,
>>>
>>> Thanks for looking at this and simplifying various discussions we had so
>>> far. I was thinking of summarizing something very similar. I couldn't
>>> due to lack of time.
>>>
>>> On 16/09/16 18:13, Kevin Hilman wrote:
>>>
>>> [...]
>>>
>>>> I think we're having some terminology issues...
>>>>
>>>> FWIW, the kernel terminolgy is actually "PM domain", not power domain.
>>>> This was intentional because the goal of the PM domain was to group
>>>> devices that some PM features. To be very specific to the kernel, they
>>>> us the same set of PM callbacks. Today, this is most commonly used to
>>>> model power domains, where a group of devices share a power rail, but it
>>>> does not need to be limited to that.
>>>>
>>>
>>> Agreed/Understood.
>>>
>>>> That being said, I'm having a hard time understanding the root of the
>>>> disagreement.
>>>>
>>>
>>> Yes. I tried to convey the same earlier, but have failed. The only
>>> disagreement is about a small part of this DT bindings. We would like to
>>> make it completely hierarchical up to CPU nodes. More comments on that
>>> below.
>>>
>>>> It seems that you and Sudeep would like to use domain-idle-states to
>>>> replace/superceed cpu-idle-states with the primary goal (and benefit)
>>>> being that it simplifies the DT bindings. Is that correct?
>>>>
>>>
>>> Correct, we want to deprecate cpu-idle-states with the introduction of
>>> this hierarchical PM bindings. Yes IMO, it simplifies things and avoids
>>> any ABI break we might trigger if we miss to consider some use-case now.
>>>
>>>> The objections have come in because that means that implies that CPUs
>>>> become their own domains, which may not be the case in hardware in the
>>>> sense that they share a power rail.
>>>>
>>>
>>> Agreed.
>>>
>>>> However, IMO, thinking of a CPU as it's own "PM domain" may make some
>>>> sense based on the terminology above.
>>>>
>>>
>>> Thanks for that, we do understand that it may not be 100% correct when
>>> we strictly considers hardware terminologies instead of above ones.
>>> As along as we see no issues with the above terminologies it should be fine.
>>>
>>>> I think the other objection may be that using a genpd to model domain
>>>> with only a single device in it may be overkill, and I agree with that.
>>>
>>> I too agree with that. Just because we represent that in DT in that way
>>> doesn't mean we need to create a genpd to model domain. We can always
>>> skip that if not required. That's pure implementation specifics and I
>>> have tried to convey the same in my previous emails. I must say you have
>>> summarized it very clearly in this email. Thanks again for that.
>>>
>>>> But, I'm not sure if making CPUs use domain-idle-states implies that
>>>> they necessarily have to use genpd is what you are proposing. Maybe
>>>> someone could clarify that?
>>>>
>>>
>>> No, I have not proposing anything around implementation in the whole
>>> discussion so far. I have constrained myself just to DT bindings so far.
>>> That's the main reason why I was opposed to mentions of OS vs platform
>>> co-ordinated modes of CPU suspend in this discussion. IMO that's
>>> completely out of scope of this DT binding we are defining here.
>>>
> Fair. But understand the PM Domain bindings do not impose any
> requirements of hierarchy. Domain idle states are defined by the
> property domain-idle-states in the domain node. How the DT bindings are
> organized is immaterial to the PM Domain core.
>
> It is a different exercise all together to look at CPU PSCI modes and
> have a unified way of representing them in DT. The current set of
> patches does not dictate where the domain idle states be located (pardon
> my example in the patch, which was not updated to reflect that). That
> said, I do require that domains that are controlled by the PSCI f/w be
> defined under the 'psci' node in DT, which is fair. All the domain needs
> are phandles to the idle state definitions; how the nodes are arranged
> in DT is not of consequence to the driver.
>
> In my mind providing a structure to CPU PM domains that can be used for
> both OSI and PC is a separate effort.
Do you mean a structure in the kernel or in DT? If the former, I agree,
if the latter I strongly disagree. I think DT bindings should be totally
unaware of PSCI suspend modes.
> It may also club what Brendan
> mentions below as part of the effort. The hierarchy that is presented in
> [1] is inherent in the PM domain hierarchy and idle states don't have to
> duplicate that information.
>
>>> Hope that helps/clarifies the misunderstanding/disagreement.
>>
>>Indeed. My intention was that the proposal would result in the exact
>>same kernel behaviour as Lina's current patchset, i.e. there is one
>>genpd per cluster, and CPU-level idle states are still handled by
>>cpuidle.
>>
>>The only change from the current patchset would be in initialisation
>>code: some coordination would need to be done to determine which idle
>>states go into cpuidle and which go into the genpds (whereas with the
>>current bindings, states from cpu-idle-states go into cpuidle and states
>>from domain-idle-states go into genpd). So you could say that this would
>>be a trade-off between binding simplicity and implementation simplicity.
>>
> I would not oppose the idea of virtual domains around CPUs (I admit I am
> not comfortable with the idea though), if that is the right thing to do.
> But the scope of that work is extensive and should not be clubbed as
> part of this proposal. It is an extensive code rework spanning cpuidle
> drivers and PSCI and there are hooks in this code to help you achieve
> that.
If we want to take the per-CPU domains approach, we _have_ to do it as
part of this proposal; it's a different set of semantics for the
cpu-idle-states/domain-idle-states properties. It would mean
cpu-idle-states is _superseded_ by domain idle states - implementing one
solution (where cpu-idle-states and domain idle states are both taken
into consideration by the implementation) then later switching to the
alternative (where cpu-idle-states is ignored when a CPU PM domain tree
is present) wouldn't make sense from a backward-compatibility
perspective.
You're right that implementing the alternative proposal in the Linux
kernel would mean quite a big rework. But, idealistically speaking,
Linux-specific implementation realities shouldn't be a factor in Device
Tree binding designs, right?
If people think that using both cpu-idle-states and domain-idle-states
is the pragmatic choice (or object fundamentally to the idea of devices
with idle states as being in their own PM domain) then that's fine IMO,
but it's a one-time decision and I think we should be clear about why
we're making it.
Cheers,
Brendan
^ permalink raw reply
* [PATCH 3/4] ARM: tegra: nyan-big: Include compatible revisions for proper detection
From: Paul Kocialkowski @ 2016-09-21 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5461eb20-9372-7fa1-0e48-3d0143393b8c@nvidia.com>
Resending with the right CC chain.
Le mercredi 21 septembre 2016 ? 10:15 +0100, Jon Hunter a ?crit?:
>
> On 21/09/16 08:43, Paul Kocialkowski wrote:
>
> ...
>
> > > > > > > > Depthcharge (the payload used with cros devices) will attempt to
> > > > > > > > detect
> > > > > > > > boards using their revision. This includes all the known
> > > > > > > > revisions
> > > > > > > > for
> > > > > > > > the nyan-big board so that the dtb can be selected preferably.
> > > > > > >
> > > > > > > May be I am missing something here, but for the mainline there is
> > > > > > > only
> > > > > > > one dtb available and so why is this needed for the mainline?
> > > > > >
> > > > > > There is indeed a single dts in mainline, but depthcharge will use
> > > > > > the
> > > > > > revision
> > > > > > to match the compatible string (e.g. it will look for google,nyan-
> > > > > > big-
> > > > > > rev5,
> > > > > > not
> > > > > > google,nyan-big), so we need to list them all in that single dts.
> > > > > > Otherwise,
> > > > > > depthcharge will fall back to the default config, which may or may
> > > > > > not
> > > > > > be
> > > > > > suitable for nyan.
> > > > >
> > > > > Is tegra124-nyan-big.dtb not the default?
> > > >
> > > > You can't expect that to always be the case. The image format allows
> > > > many
> > > > different dts to be provided, so I could easily build with
> > > > multi_v7_defconfig
> > > > and have various dts for various devices in the same image, and just
> > > > select
> > > > a
> > > > random one as default.
> > >
> > > Really? Sounds odd. I was hoping that tegra124-nyan-big.dtb would be a
> > > catch all.
>
> I meant I was hoping that compatible = "google,nyan-big" would be the
> catchall not the dtb file name ;-)
Yeah, I figured :)
>
> >
> > Yes, the image format (FIT) allows specifying multiple dtb and zImage
> > combinations in the same image[0].
>
> Yes I am aware of that. Typically, I have been testing using a FIT image
> with single zImage and dtb. Hence no problems.
>
> So are you wanting to create a FIT image to support multiple boards and
> use the single FIT image for all? If so then I can see why you want
> this. Again please describe the motivation for the changes in the
> changelog so it is clear why we are adding this.
Fair enough, will do in v2.
--
Paul Kocialkowski, developer of low-level free software for embedded devices
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160921/3e5c3e2d/attachment.sig>
^ permalink raw reply
* [PATCH 1/4] ARM: tegra: nyan: Use proper IRQ type definitions
From: Paul Kocialkowski @ 2016-09-21 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eb7540c0-4abd-86c0-7777-78fe1f12bc59@nvidia.com>
Resending with the right CC chain.
Le mercredi 21 septembre 2016 ? 10:06 +0100, Jon Hunter a ?crit?:
> On 21/09/16 09:26, Paul Kocialkowski wrote:
> >
> >
> > * PGP Signed by an unknown key
> >
> > Le mercredi 21 septembre 2016 ? 08:52 +0100, Jon Hunter a ?crit :
> > >
> > >
> > > On 20/09/16 19:14, Paul Kocialkowski wrote:
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > Old Signed by an unknown key
> > > >
> > > > Le mardi 20 septembre 2016 ? 18:15 +0100, Jon Hunter a ?crit :
> > > > >
> > > > >
> > > > >
> > > > > On 28/08/16 18:32, Paul Kocialkowski wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > This switches a few interrupt definitions that were using
> > > > > > GPIO_ACTIVE_HIGH as IRQ type, which is invalid.
> > > > >
> > > > > May be you are right, but this does not describe why this is invalid.
> > > > > Can you elaborate?
> > > >
> > > > GPIO_ACTIVE_HIGH is simply not the right kind of define to use in the
> > > > "interrupts" devicetree property. Values provided there are understood
> > > > as
> > > > IRQ_TYPE_ defines.
> > >
> > > Right, but you are changing the type as GPIO_ACTIVE_HIGH = 0 and
> > > IRQ_TYPE_EDGE_FALLING = 2 and there is no comment about why this has
> > > been changed. It might be correct, but you need to explain it.
> >
> > This actually makes the IRQ trigger values consistent with the drivers, that
> > define them regardless of devicetree anyway. The max98090 driver
> > has IRQF_TRIGGER_FALLING and bq24735 has IRQF_TRIGGER_RISING |
> > IRQF_TRIGGER_FALLING.
> >
> > This is really more of a cosmetic change, it doesn't impact actual use.
>
> So you are saying that the drivers don't actually use the DT types?
It appears so. At least they are hardcoded in the kernel driver.
>
> ?May be that is ok, and yes this is cosmetic, but this should be stated in
> the changelog as it is not clear what is going on here.
Fair enough, will do in v2.
--
Paul Kocialkowski, developer of low-level free software for embedded devices
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160921/c34cbaae/attachment-0001.sig>
^ permalink raw reply
* [PATCH V3 1/4] ARM64 LPC: Indirect ISA port IO introduced
From: zhichang @ 2016-09-21 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5264074.nuyDhEuOR4@wuerfel>
Hi, Arnd,
On 2016?09?14? 22:23, Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 10:16:28 PM CEST zhichang.yuan wrote:
>>>
>>> No need to guard includes with an #ifdef.
>> If remove #ifdef here, extio.h should not contain any function external declarations whose definitions are in
>> extio.c compiled only when CONFIG_ARM64_INDIRECT_PIO is yes.
>
> There is no problem with making declarations visible for functions that
> are not part of the kernel, we do that all the time.
>
>>>> +#define BUILDS_RW(bwl, type) \
>>>> +static inline void reads##bwl(const volatile void __iomem *addr, \
>>>> + void *buffer, unsigned int count) \
>>>> +{ \
>>>> + if (count) { \
>>>> + type *buf = buffer; \
>>>> + \
>>>> + do { \
>>>> + type x = __raw_read##bwl(addr); \
>>>> + *buf++ = x; \
>>>> + } while (--count); \
>>>> + } \
>>>> +} \
>>>> + \
>>>> +static inline void writes##bwl(volatile void __iomem *addr, \
>>>> + const void *buffer, unsigned int count) \
>>>> +{ \
>>>> + if (count) { \
>>>> + const type *buf = buffer; \
>>>> + \
>>>> + do { \
>>>> + __raw_write##bwl(*buf++, addr); \
>>>> + } while (--count); \
>>>> + } \
>>>> +}
>>>> +
>>>> +BUILDS_RW(b, u8)
>>>
>>> Why is this in here?
>> the readsb/writesb are defined in asm-generic/io.h which is included later, but the redefined insb/outsb need
>> to call them. Without these readsb/writesb definition before insb/outsb redefined, compile error occur.
>>
>> It seems that copy all the definitions of "asm-generic/io.h" is not a good idea, so I move the definitions of
>> those function needed here....
>>
>> Ok. I think your idea below defining in(s)/out(s) in a c file can solve this issue.
>>
>> #ifdef CONFIG_ARM64_INDIRECT_PIO
>> #define inb inb
>> extern u8 inb(unsigned long addr);
>>
>> #define outb outb
>> extern void outb(u8 value, unsigned long addr);
>>
>> #define insb insb
>> extern void insb(unsigned long addr, void *buffer, unsigned int count);
>>
>> #define outsb outsb
>> extern void outsb(unsigned long addr, const void *buffer, unsigned int count);
>> #endif
>>
>> and definitions of all these functions are in extio.c :
>>
>> u8 inb(unsigned long addr)
>> {
>> if (!arm64_extio_ops || arm64_extio_ops->start > addr ||
>> arm64_extio_ops->end < addr)
>> return readb(PCI_IOBASE + addr);
>> else
>> return arm64_extio_ops->pfin ?
>> arm64_extio_ops->pfin(arm64_extio_ops->devpara,
>> addr + arm64_extio_ops->ptoffset, NULL,
>> sizeof(u8), 1) : -1;
>> }
>> .....
>
> Yes, sounds good.
>
>>>> @@ -149,6 +185,60 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>>>> #define IO_SPACE_LIMIT (PCI_IO_SIZE - 1)
>>>> #define PCI_IOBASE ((void __iomem *)PCI_IO_START)
>>>>
>>>> +
>>>> +/*
>>>> + * redefine the in(s)b/out(s)b for indirect-IO.
>>>> + */
>>>> +#define inb inb
>>>> +static inline u8 inb(unsigned long addr)
>>>> +{
>>>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>>>> + if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
>>>> + addr <= arm64_extio_ops->end)
>>>> + return extio_inb(addr);
>>>> +#endif
>>>> + return readb(PCI_IOBASE + addr);
>>>> +}
>>>> +
>>>
>>> Looks ok, but you only seem to do this for the 8-bit
>>> accessors, when it should be done for 16-bit and 32-bit
>>> ones as well for consistency.
>> Hip06 LPC only support 8-bit I/O operations on the designated port.
>
> That is an interesting limitation. Maybe still call the extio operations
> and have them do WARN_ON_ONCE() instead?
>
> If you get a driver that calls inw/outw on the range that is owned
> by the LPC bus, you otherwise get an unhandled page fault in kernel
> space, which is not as nice.
As for this issue, I provided a wrong reply in the last email.
After double-checking with SoC guys, the inw(l)/outw(l) are OK with multiple 8-bit transfers to consecutive
I/O addresses.
Sorry for the wrong information!
Will support inw(l)/outw(l) in V4.
Best,
Zhichang
>
>>>> diff --git a/drivers/bus/extio.c b/drivers/bus/extio.c
>>>> new file mode 100644
>>>> index 0000000..1e7a9c5
>>>> --- /dev/null
>>>> +++ b/drivers/bus/extio.c
>>>> @@ -0,0 +1,66 @@
>>>
>>> This is in a globally visible directory
>>>
>>>> +
>>>> +struct extio_ops *arm64_extio_ops;
>>>
>>> But the identifier uses an architecture specific prefix. Either
>>> move the whole file into arch/arm64, or make the naming so that
>>> it can be used for everything.
>>
>> I perfer to move the whole file into arch/arm64, extio.h will be moved to arch/arm64/include/asm;
>
> Ok, that simplifies it a lot, you can just do everything in asm/io.h then.
>
> Arnd
>
^ permalink raw reply
* [PATCH 3/4] ARM: tegra: nyan-big: Include compatible revisions for proper detection
From: Jon Hunter @ 2016-09-21 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474443809.1239.4.camel@paulk.fr>
On 21/09/16 08:43, Paul Kocialkowski wrote:
...
>>>>>>> Depthcharge (the payload used with cros devices) will attempt to
>>>>>>> detect
>>>>>>> boards using their revision. This includes all the known revisions
>>>>>>> for
>>>>>>> the nyan-big board so that the dtb can be selected preferably.
>>>>>>
>>>>>> May be I am missing something here, but for the mainline there is only
>>>>>> one dtb available and so why is this needed for the mainline?
>>>>>
>>>>> There is indeed a single dts in mainline, but depthcharge will use the
>>>>> revision
>>>>> to match the compatible string (e.g. it will look for google,nyan-big-
>>>>> rev5,
>>>>> not
>>>>> google,nyan-big), so we need to list them all in that single dts.
>>>>> Otherwise,
>>>>> depthcharge will fall back to the default config, which may or may not
>>>>> be
>>>>> suitable for nyan.
>>>>
>>>> Is tegra124-nyan-big.dtb not the default?
>>>
>>> You can't expect that to always be the case. The image format allows many
>>> different dts to be provided, so I could easily build with
>>> multi_v7_defconfig
>>> and have various dts for various devices in the same image, and just select
>>> a
>>> random one as default.
>>
>> Really? Sounds odd. I was hoping that tegra124-nyan-big.dtb would be a
>> catch all.
I meant I was hoping that compatible = "google,nyan-big" would be the
catchall not the dtb file name ;-)
> Yes, the image format (FIT) allows specifying multiple dtb and zImage
> combinations in the same image[0].
Yes I am aware of that. Typically, I have been testing using a FIT image
with single zImage and dtb. Hence no problems.
So are you wanting to create a FIT image to support multiple boards and
use the single FIT image for all? If so then I can see why you want
this. Again please describe the motivation for the changes in the
changelog so it is clear why we are adding this.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* ftrace function_graph causes system crash
From: Jisheng Zhang @ 2016-09-21 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e38f79fdc1f4671943da74764c15050@SIWEX5A.sing.micron.com>
Hi Bean,
On Wed, 21 Sep 2016 07:50:58 +0000 "Bean Huo (beanhuo)" wrote:
> > From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org]
> > On Behalf Of Steven Rostedt
> > Sent: Dienstag, 20. September 2016 16:07
> > To: Bean Huo (beanhuo) <beanhuo@micron.com>
> > Cc: Zoltan Szubbocsev (zszubbocsev) <zszubbocsev@micron.com>;
> > catalin.marinas at arm.com; will.deacon at arm.com; rfi at lists.rocketboards.org;
> > linux-kernel at vger.kernel.org; mingo at redhat.com; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: ftrace function_graph causes system crash
> >
> > On Tue, 20 Sep 2016 13:10:39 +0000
> > "Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:
> >
> > > Hi, all
> > > I just use ftrace to do some latency study, found that function_graph
> > > can not Work, as long as enable it, will cause kernel panic. I searched this
> > online.
> > > Found that there are also some cause the same as mine. I am a newer of
> > ftrace.
> > > I want to know who know what root cause? Here is some partial log:
> > >
> > >
> >
> > Can you do a function bisect to find what function this is.
> >
> > This script is used to help find functions that are being traced by function tracer
> > or function graph tracing that causes the machine to reboot, hang, or crash.
> > Here's the steps to take.
> >
> > First, determine if function graph is working with a single function:
> >
> > # cd /sys/kernel/debug/tracing
> > # echo schedule > set_ftrace_filter
> > # echo function_graph > current_tracer
> >
> > If this works, then we know that something is being traced that shouldn't be.
> >
> > # echo nop > current_tracer
> >
> > # cat available_filter_functions > ~/full-file # ftrace-bisect ~/full-file ~/test-file
> > ~/non-test-file # cat ~/test-file > set_ftrace_filter
> >
> > *** Note *** this will take several minutes. Setting multiple functions is an
> > O(n^2) operation, and we are dealing with thousands of functions.
> > So go have coffee, talk with your coworkers, read facebook. And eventually,
> > this operation will end.
> >
> > # echo function_graph > current_tracer
> >
> > If it crashes, we know that ~/test-file has a bad function.
> >
> > Reboot back to test kernel.
> >
> > # cd /sys/kernel/debug/tracing
> > # mv ~/test-file ~/full-file
> >
> > If it didn't crash.
> >
> > # echo nop > current_tracer
> > # mv ~/non-test-file ~/full-file
> >
> > Get rid of the other test file from previous run (or save them off somewhere.
> > # rm -f ~/test-file ~/non-test-file
> >
> > And start again:
> >
> > # ftrace-bisect ~/full-file ~/test-file ~/non-test-file
> >
> > The good thing is, because this cuts the number of functions in ~/test-file by half,
> > the cat of it into set_ftrace_filter takes half as long each iteration, so don't talk
> > so much at the water cooler the second time.
> >
> > Eventually, if you did this correctly, you will get down to the problem function,
> > and all we need to do is to notrace it.
> >
> > The way to figure out if the problem function is bad, just do:
> >
> > # echo <problem-function> > set_ftrace_notrace # echo > set_ftrace_filter #
> > echo function_graph > current_tracer
> >
> > And if it doesn't crash, we are done.
> >
> > -- Steve
>
>
> Hi, Steve
> Thanks very much! This is a very useful trace tool, I now know the problem function,
> It is gt_counter_read, if not trace this function, ftrace function_graph work well.
I'm not sure whether the commit d6df3576e6b4 ("clocksource/drivers/arm_global_timer
: Prevent ftrace recursion") can fix this issue.
this commit is merged since v4.3, I noticed your kernel version is v4.0
Thanks,
Jisheng
> Do you know now how to deeply debug and trace which line is wrong through Ftrace?
>
> --Bean
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] ARM: tegra: nyan: Use proper IRQ type definitions
From: Jon Hunter @ 2016-09-21 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474446366.1239.17.camel@paulk.fr>
On 21/09/16 09:26, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mercredi 21 septembre 2016 ? 08:52 +0100, Jon Hunter a ?crit :
>> On 20/09/16 19:14, Paul Kocialkowski wrote:
>>>
>>>> Old Signed by an unknown key
>>>
>>> Le mardi 20 septembre 2016 ? 18:15 +0100, Jon Hunter a ?crit :
>>>>
>>>> On 28/08/16 18:32, Paul Kocialkowski wrote:
>>>>>
>>>>>
>>>>> This switches a few interrupt definitions that were using
>>>>> GPIO_ACTIVE_HIGH as IRQ type, which is invalid.
>>>>
>>>> May be you are right, but this does not describe why this is invalid.
>>>> Can you elaborate?
>>>
>>> GPIO_ACTIVE_HIGH is simply not the right kind of define to use in the
>>> "interrupts" devicetree property. Values provided there are understood as
>>> IRQ_TYPE_ defines.
>>
>> Right, but you are changing the type as GPIO_ACTIVE_HIGH = 0 and
>> IRQ_TYPE_EDGE_FALLING = 2 and there is no comment about why this has
>> been changed. It might be correct, but you need to explain it.
>
> This actually makes the IRQ trigger values consistent with the drivers, that
> define them regardless of devicetree anyway. The max98090 driver
> has IRQF_TRIGGER_FALLING and bq24735 has IRQF_TRIGGER_RISING |
> IRQF_TRIGGER_FALLING.
>
> This is really more of a cosmetic change, it doesn't impact actual use.
So you are saying that the drivers don't actually use the DT types? May
be that is ok, and yes this is cosmetic, but this should be stated in
the changelog as it is not clear what is going on here.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v3 3/3] clk: mvebu: migrate CP110 system controller to clk_hw API and registration
From: Marcin Wojtas @ 2016-09-21 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474448759-24482-1-git-send-email-mw@semihalf.com>
Now that we have clk_hw based provider APIs to register clks, we
can get rid of struct clk pointers while registering clks in Armada
CP110 system controller driver. This commit introduces new
API and registration for all clocks in CP110 HW blocks.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
drivers/clk/mvebu/cp110-system-controller.c | 150 +++++++++++++---------------
1 file changed, 72 insertions(+), 78 deletions(-)
diff --git a/drivers/clk/mvebu/cp110-system-controller.c b/drivers/clk/mvebu/cp110-system-controller.c
index f2303da..842bddd 100644
--- a/drivers/clk/mvebu/cp110-system-controller.c
+++ b/drivers/clk/mvebu/cp110-system-controller.c
@@ -87,7 +87,7 @@ struct cp110_gate_clk {
u8 bit_idx;
};
-#define to_cp110_gate_clk(clk) container_of(clk, struct cp110_gate_clk, hw)
+#define to_cp110_gate_clk(hw) container_of(hw, struct cp110_gate_clk, hw)
static int cp110_gate_enable(struct clk_hw *hw)
{
@@ -123,13 +123,14 @@ static const struct clk_ops cp110_gate_ops = {
.is_enabled = cp110_gate_is_enabled,
};
-static struct clk *cp110_register_gate(const char *name,
- const char *parent_name,
- struct regmap *regmap, u8 bit_idx)
+static struct clk_hw *cp110_register_gate(const char *name,
+ const char *parent_name,
+ struct regmap *regmap, u8 bit_idx)
{
struct cp110_gate_clk *gate;
- struct clk *clk;
+ struct clk_hw *hw;
struct clk_init_data init;
+ int ret;
gate = kzalloc(sizeof(*gate), GFP_KERNEL);
if (!gate)
@@ -146,39 +147,37 @@ static struct clk *cp110_register_gate(const char *name,
gate->bit_idx = bit_idx;
gate->hw.init = &init;
- clk = clk_register(NULL, &gate->hw);
- if (IS_ERR(clk))
+ hw = &gate->hw;
+ ret = clk_hw_register(NULL, hw);
+ if (ret) {
kfree(gate);
+ hw = ERR_PTR(ret);
+ }
- return clk;
+ return hw;
}
-static void cp110_unregister_gate(struct clk *clk)
+static void cp110_unregister_gate(struct clk_hw *hw)
{
- struct clk_hw *hw;
-
- hw = __clk_get_hw(clk);
- if (!hw)
- return;
-
- clk_unregister(clk);
+ clk_hw_unregister(hw);
kfree(to_cp110_gate_clk(hw));
}
-static struct clk *cp110_of_clk_get(struct of_phandle_args *clkspec, void *data)
+static struct clk_hw *cp110_of_clk_get(struct of_phandle_args *clkspec,
+ void *data)
{
- struct clk_onecell_data *clk_data = data;
+ struct clk_hw_onecell_data *clk_data = data;
unsigned int type = clkspec->args[0];
unsigned int idx = clkspec->args[1];
if (type == CP110_CLK_TYPE_CORE) {
if (idx > CP110_MAX_CORE_CLOCKS)
return ERR_PTR(-EINVAL);
- return clk_data->clks[idx];
+ return clk_data->hws[idx];
} else if (type == CP110_CLK_TYPE_GATABLE) {
if (idx > CP110_MAX_GATABLE_CLOCKS)
return ERR_PTR(-EINVAL);
- return clk_data->clks[CP110_MAX_CORE_CLOCKS + idx];
+ return clk_data->hws[CP110_MAX_CORE_CLOCKS + idx];
}
return ERR_PTR(-EINVAL);
@@ -189,8 +188,8 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
struct regmap *regmap;
struct device_node *np = pdev->dev.of_node;
const char *ppv2_name, *apll_name, *core_name, *eip_name, *nand_name;
- struct clk_onecell_data *cp110_clk_data;
- struct clk *clk, **cp110_clks;
+ struct clk_hw_onecell_data *cp110_clk_data;
+ struct clk_hw *hw, **cp110_clks;
u32 nand_clk_ctrl;
int i, ret;
@@ -203,80 +202,75 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
if (ret)
return ret;
- cp110_clks = devm_kcalloc(&pdev->dev, sizeof(struct clk *),
- CP110_CLK_NUM, GFP_KERNEL);
- if (!cp110_clks)
- return -ENOMEM;
-
- cp110_clk_data = devm_kzalloc(&pdev->dev,
- sizeof(*cp110_clk_data),
+ cp110_clk_data = devm_kcalloc(&pdev->dev, sizeof(*cp110_clk_data),
+ sizeof(struct clk_hw *) * CP110_CLK_NUM,
GFP_KERNEL);
if (!cp110_clk_data)
return -ENOMEM;
- cp110_clk_data->clks = cp110_clks;
- cp110_clk_data->clk_num = CP110_CLK_NUM;
+ cp110_clks = cp110_clk_data->hws;
+ cp110_clk_data->num = CP110_CLK_NUM;
- /* Register the APLL which is the root of the clk tree */
+ /* Register the APLL which is the root of the hw tree */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_APLL, &apll_name);
- clk = clk_register_fixed_rate(NULL, apll_name, NULL, 0,
- 1000 * 1000 * 1000);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_rate(NULL, apll_name, NULL, 0,
+ 1000 * 1000 * 1000);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail0;
}
- cp110_clks[CP110_CORE_APLL] = clk;
+ cp110_clks[CP110_CORE_APLL] = hw;
/* PPv2 is APLL/3 */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_PPV2, &ppv2_name);
- clk = clk_register_fixed_factor(NULL, ppv2_name, apll_name, 0, 1, 3);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, ppv2_name, apll_name, 0, 1, 3);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail1;
}
- cp110_clks[CP110_CORE_PPV2] = clk;
+ cp110_clks[CP110_CORE_PPV2] = hw;
/* EIP clock is APLL/2 */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_EIP, &eip_name);
- clk = clk_register_fixed_factor(NULL, eip_name, apll_name, 0, 1, 2);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, eip_name, apll_name, 0, 1, 2);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail2;
}
- cp110_clks[CP110_CORE_EIP] = clk;
+ cp110_clks[CP110_CORE_EIP] = hw;
/* Core clock is EIP/2 */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_CORE, &core_name);
- clk = clk_register_fixed_factor(NULL, core_name, eip_name, 0, 1, 2);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, core_name, eip_name, 0, 1, 2);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail3;
}
- cp110_clks[CP110_CORE_CORE] = clk;
+ cp110_clks[CP110_CORE_CORE] = hw;
/* NAND can be either APLL/2.5 or core clock */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_NAND, &nand_name);
if (nand_clk_ctrl & NF_CLOCK_SEL_400_MASK)
- clk = clk_register_fixed_factor(NULL, nand_name,
- apll_name, 0, 2, 5);
+ hw = clk_hw_register_fixed_factor(NULL, nand_name,
+ apll_name, 0, 2, 5);
else
- clk = clk_register_fixed_factor(NULL, nand_name,
- core_name, 0, 1, 1);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, nand_name,
+ core_name, 0, 1, 1);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail4;
}
- cp110_clks[CP110_CORE_NAND] = clk;
+ cp110_clks[CP110_CORE_NAND] = hw;
for (i = 0; i < CP110_MAX_GATABLE_CLOCKS; i++) {
const char *parent, *name;
@@ -335,16 +329,16 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
break;
}
- clk = cp110_register_gate(name, parent, regmap, i);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = cp110_register_gate(name, parent, regmap, i);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail_gate;
}
- cp110_clks[CP110_MAX_CORE_CLOCKS + i] = clk;
+ cp110_clks[CP110_MAX_CORE_CLOCKS + i] = hw;
}
- ret = of_clk_add_provider(np, cp110_of_clk_get, cp110_clk_data);
+ ret = of_clk_add_hw_provider(np, cp110_of_clk_get, cp110_clk_data);
if (ret)
goto fail_clk_add;
@@ -355,44 +349,44 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
fail_clk_add:
fail_gate:
for (i = 0; i < CP110_MAX_GATABLE_CLOCKS; i++) {
- clk = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
+ hw = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
- if (clk)
- cp110_unregister_gate(clk);
+ if (hw)
+ cp110_unregister_gate(hw);
}
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
fail4:
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
fail3:
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
fail2:
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
fail1:
- clk_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
+ clk_hw_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
fail0:
return ret;
}
static int cp110_syscon_clk_remove(struct platform_device *pdev)
{
- struct clk **cp110_clks = platform_get_drvdata(pdev);
+ struct clk_hw **cp110_clks = platform_get_drvdata(pdev);
int i;
of_clk_del_provider(pdev->dev.of_node);
for (i = 0; i < CP110_MAX_GATABLE_CLOCKS; i++) {
- struct clk *clk = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
+ struct clk_hw *hw = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
- if (clk)
- cp110_unregister_gate(clk);
+ if (hw)
+ cp110_unregister_gate(hw);
}
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
- clk_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
+ clk_hw_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 2/3] clk: mvebu: dynamically allocate resources in Armada CP110 system controller
From: Marcin Wojtas @ 2016-09-21 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474448759-24482-1-git-send-email-mw@semihalf.com>
Original commit, which added support for Armada CP110 system controller
used global variables for storing all clock information. It worked
fine for Armada 7k SoC, with single CP110 block. After dual-CP110 Armada 8k
was introduced, the data got overwritten and corrupted.
This patch fixes the issue by allocating resources dynamically in the
driver probe and storing it as platform drvdata.
Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CC: <stable@vger.kernel.org>
---
drivers/clk/mvebu/cp110-system-controller.c | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/mvebu/cp110-system-controller.c b/drivers/clk/mvebu/cp110-system-controller.c
index 59fe76e..f2303da 100644
--- a/drivers/clk/mvebu/cp110-system-controller.c
+++ b/drivers/clk/mvebu/cp110-system-controller.c
@@ -81,13 +81,6 @@ enum {
#define CP110_GATE_EIP150 25
#define CP110_GATE_EIP197 26
-static struct clk *cp110_clks[CP110_CLK_NUM];
-
-static struct clk_onecell_data cp110_clk_data = {
- .clks = cp110_clks,
- .clk_num = CP110_CLK_NUM,
-};
-
struct cp110_gate_clk {
struct clk_hw hw;
struct regmap *regmap;
@@ -196,7 +189,8 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
struct regmap *regmap;
struct device_node *np = pdev->dev.of_node;
const char *ppv2_name, *apll_name, *core_name, *eip_name, *nand_name;
- struct clk *clk;
+ struct clk_onecell_data *cp110_clk_data;
+ struct clk *clk, **cp110_clks;
u32 nand_clk_ctrl;
int i, ret;
@@ -209,6 +203,20 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
if (ret)
return ret;
+ cp110_clks = devm_kcalloc(&pdev->dev, sizeof(struct clk *),
+ CP110_CLK_NUM, GFP_KERNEL);
+ if (!cp110_clks)
+ return -ENOMEM;
+
+ cp110_clk_data = devm_kzalloc(&pdev->dev,
+ sizeof(*cp110_clk_data),
+ GFP_KERNEL);
+ if (!cp110_clk_data)
+ return -ENOMEM;
+
+ cp110_clk_data->clks = cp110_clks;
+ cp110_clk_data->clk_num = CP110_CLK_NUM;
+
/* Register the APLL which is the root of the clk tree */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_APLL, &apll_name);
@@ -336,10 +344,12 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
cp110_clks[CP110_MAX_CORE_CLOCKS + i] = clk;
}
- ret = of_clk_add_provider(np, cp110_of_clk_get, &cp110_clk_data);
+ ret = of_clk_add_provider(np, cp110_of_clk_get, cp110_clk_data);
if (ret)
goto fail_clk_add;
+ platform_set_drvdata(pdev, cp110_clks);
+
return 0;
fail_clk_add:
@@ -366,6 +376,7 @@ fail0:
static int cp110_syscon_clk_remove(struct platform_device *pdev)
{
+ struct clk **cp110_clks = platform_get_drvdata(pdev);
int i;
of_clk_del_provider(pdev->dev.of_node);
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 1/3] clk: mvebu: fix setting unwanted flags in CP110 gate clock
From: Marcin Wojtas @ 2016-09-21 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474448759-24482-1-git-send-email-mw@semihalf.com>
Armada CP110 system controller comprises its own routine responsble
for registering gate clocks. Among others 'flags' field in
struct clk_init_data was not set, using a random values, which
may cause an unpredicted behavior.
This patch fixes the problem by resetting all fields of clk_init_data
before assigning values for all gated clocks of Armada 7k/8k SoCs family.
Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
CC: <stable@vger.kernel.org>
---
drivers/clk/mvebu/cp110-system-controller.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/mvebu/cp110-system-controller.c b/drivers/clk/mvebu/cp110-system-controller.c
index 7fa42d6..59fe76e 100644
--- a/drivers/clk/mvebu/cp110-system-controller.c
+++ b/drivers/clk/mvebu/cp110-system-controller.c
@@ -142,6 +142,8 @@ static struct clk *cp110_register_gate(const char *name,
if (!gate)
return ERR_PTR(-ENOMEM);
+ memset(&init, 0, sizeof(init));
+
init.name = name;
init.ops = &cp110_gate_ops;
init.parent_names = &parent_name;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 0/3] Armada 7k/8k CP110 system controller fixes
From: Marcin Wojtas @ 2016-09-21 9:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the third version of the patchset adding fixes to CP110
system controller clock driver. Comparing to v2, the only change
is return value on alloc failures.
Any feedback would be very welcome.
Best regards,
Marcin
Changelog:
v3 -> v2
* return -ENOMEM on alloc failures
v1 -> v2
* replace setting CLK_IS_BASIC flag with clearing init structure fields
with memset
* minor improvements of allocation and error checking
* add migration to clk_hw
Marcin Wojtas (3):
clk: mvebu: fix setting unwanted flags in CP110 gate clock
clk: mvebu: dynamically allocate resources in Armada CP110 system
controller
clk: mvebu: migrate CP110 system controller to clk_hw API and
registration
drivers/clk/mvebu/cp110-system-controller.c | 155 +++++++++++++++-------------
1 file changed, 81 insertions(+), 74 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [GIT PULL] Allwinner late DT changes for 4.9
From: Maxime Ripard @ 2016-09-21 8:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof, Kevin,
This is a late (and last) PR for the Allwinner device trees.
It comes on top of the previous one (so it still has the dependency in
the clock changes).
Let me know if you have any questions,
Maxime
The following changes since commit 7a988a4dd29a8cfcf405a12441533d765d25a6b8:
ARM: dts: gr8: Add support for the GR8 evaluation board (2016-09-11 22:23:17 +0200)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-dt-for-4.9-3
for you to fetch changes up to 90cb4b8c7e3af989c78227954e01455fc7c1e767:
ARM: dts: sun8i: Add accelerometer to polaroid-mid2407pxe03 (2016-09-21 11:48:09 +0300)
----------------------------------------------------------------
Allwinner DT changes for 4.9, late edition
Here is a bunch of late changes for the 4.9 merge window, mostly:
- Added a bunch of touchscreens nodes to tablets
- Added support for the AXP806 PMIC found in the A80 boards
- Enabled a few pinmux options for the H3
----------------------------------------------------------------
Chen-Yu Tsai (5):
ARM: dts: sun9i: a80-optimus: Declare AXP809 SW regulator as unused
ARM: dts: sun9i: cubieboard4: Declare AXP809 SW regulator as unused
ARM: dts: sun9i: a80-optimus: Add AXP806 PMIC device node and regulators
ARM: dts: sun9i: cubieboard4: Add AXP806 PMIC device node and regulators
ARM: dts: sun9i: a80-optimus: Disable EHCI1
Hans de Goede (6):
ARM: dts: sun8i: Add touchscreen node for sun8i-a23-gt90h
ARM: dts: sun8i: Add touchscreen node for sun8i-a23-inet86dz
ARM: dts: sun8i: Add touchscreen node for sun8i-a23-polaroid-mid2407pxe03
ARM: dts: sun8i: Add touchscreen node for sun8i-a23-polaroid-mid2809pxe04
ARM: dts: sun8i: Add touchscreen node for sun8i-a33-ga10h
ARM: dts: sun8i: Add accelerometer to polaroid-mid2407pxe03
Icenowy Zheng (2):
ARM: dts: sun8i: add pinmux for UART1 at PG
ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board
Jorik Jonker (5):
dts: sun8i-h3: add pinmux definitions for UART2-3
dts: sun8i-h3: split off RTS/CTS for UART1 in seperate pinmux
dts: sun8i-h3: associate exposed UARTs on Orange Pi Boards
dts: sun8i-h3: add pinmux definitions for I2C0-2
dts: sun8i-h3: add I2C0-2 peripherals to H3 SOC
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 10 ++
arch/arm/boot/dts/sun8i-a23-gt90h-v4.dts | 9 ++
arch/arm/boot/dts/sun8i-a23-inet86dz.dts | 9 ++
.../boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts | 26 +++++
.../boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts | 9 ++
arch/arm/boot/dts/sun8i-a33-ga10h-v1.1.dts | 10 ++
arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 20 ++++
arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 2 +-
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 18 +++
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 18 +++
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 18 +++
arch/arm/boot/dts/sun8i-h3.dtsi | 85 +++++++++++++-
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 116 +++++++++++++++++++
arch/arm/boot/dts/sun9i-a80-optimus.dts | 123 ++++++++++++++++++++-
14 files changed, 468 insertions(+), 5 deletions(-)
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160921/3be903f5/attachment.sig>
^ permalink raw reply
* [PATCH v2] arm64: kgdb: handle read-only text / modules
From: Mark Rutland @ 2016-09-21 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921071955.21792-1-takahiro.akashi@linaro.org>
On Wed, Sep 21, 2016 at 04:19:55PM +0900, AKASHI Takahiro wrote:
> Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
> by using aarch64_insn_write() instead of probe_kernel_write().
> See how this works:
> commit 2f896d586610 ("arm64: use fixmap for text patching")
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Jason Wessel <jason.wessel@windriver.com>
> Cc: <stable@vger.kernel.org> # 3.18-3.19: 2f896d5: arm64: use fixmap
> Cc: <stable@vger.kernel.org> # 4.0-
For v3.18-v3.19, we also need commit f6242cac10427c54 ("arm64: Fix text
patching logic when using fixmap"), so as to not break the
!CONFIG_DEBUG_SET_MODULE_RONX case.
With that:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/include/asm/debug-monitors.h | 2 --
> arch/arm64/kernel/kgdb.c | 36 ++++++++++++++++++++++-----------
> 2 files changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
> index 4b6b3f7..b71420a 100644
> --- a/arch/arm64/include/asm/debug-monitors.h
> +++ b/arch/arm64/include/asm/debug-monitors.h
> @@ -61,8 +61,6 @@
>
> #define AARCH64_BREAK_KGDB_DYN_DBG \
> (AARCH64_BREAK_MON | (KGDB_DYN_DBG_BRK_IMM << 5))
> -#define KGDB_DYN_BRK_INS_BYTE(x) \
> - ((AARCH64_BREAK_KGDB_DYN_DBG >> (8 * (x))) & 0xff)
>
> #define CACHE_FLUSH_IS_SAFE 1
>
> diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> index 6732a27..b06a7a2 100644
> --- a/arch/arm64/kernel/kgdb.c
> +++ b/arch/arm64/kernel/kgdb.c
> @@ -19,6 +19,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/bug.h>
> #include <linux/cpumask.h>
> #include <linux/irq.h>
> #include <linux/irq_work.h>
> @@ -26,6 +27,8 @@
> #include <linux/kgdb.h>
> #include <linux/kprobes.h>
> #include <linux/percpu.h>
> +#include <asm/debug-monitors.h>
> +#include <asm/insn.h>
> #include <asm/ptrace.h>
> #include <asm/traps.h>
>
> @@ -370,15 +373,24 @@ void kgdb_arch_exit(void)
> unregister_die_notifier(&kgdb_notifier);
> }
>
> -/*
> - * ARM instructions are always in LE.
> - * Break instruction is encoded in LE format
> - */
> -struct kgdb_arch arch_kgdb_ops = {
> - .gdb_bpt_instr = {
> - KGDB_DYN_BRK_INS_BYTE(0),
> - KGDB_DYN_BRK_INS_BYTE(1),
> - KGDB_DYN_BRK_INS_BYTE(2),
> - KGDB_DYN_BRK_INS_BYTE(3),
> - }
> -};
> +struct kgdb_arch arch_kgdb_ops;
> +
> +int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> +{
> + int err;
> +
> + BUILD_BUG_ON(AARCH64_INSN_SIZE != BREAK_INSTR_SIZE);
> +
> + err = aarch64_insn_read((void *)bpt->bpt_addr, (u32 *)bpt->saved_instr);
> + if (err)
> + return err;
> +
> + return aarch64_insn_write((void *)bpt->bpt_addr,
> + (u32)AARCH64_BREAK_KGDB_DYN_DBG);
> +}
> +
> +int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> +{
> + return aarch64_insn_write((void *)bpt->bpt_addr,
> + *(u32 *)bpt->saved_instr);
> +}
> --
> 2.10.0
>
^ permalink raw reply
* [RFC] irqchip/gic-v3: Implement suspend and resume callbacks
From: Lingutla Chandrasekhar @ 2016-09-21 8:42 UTC (permalink / raw)
To: linux-arm-kernel
Implement suspend and resume syscore_ops to disable and
enable non wake up capable interrupts.
When system enters suspend, enable only wakeup capable
interrupts. While resuming, enable previously enabled interrupts
and show triggered/pending interrupts.
Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index ede5672..511a5a1 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -33,6 +33,7 @@
#include <linux/irqchip/arm-gic-common.h>
#include <linux/irqchip/arm-gic-v3.h>
#include <linux/irqchip/irq-partition-percpu.h>
+#include <linux/syscore_ops.h>
#include <asm/cputype.h>
#include <asm/exception.h>
@@ -57,6 +58,10 @@ struct gic_chip_data {
u32 nr_redist_regions;
unsigned int irq_nr;
struct partition_desc *ppi_descs[16];
+#ifdef CONFIG_PM
+ unsigned int wakeup_irqs[32];
+ unsigned int enabled_irqs[32];
+#endif
};
static struct gic_chip_data gic_data __read_mostly;
@@ -330,6 +335,81 @@ static int gic_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu)
return 0;
}
+#ifdef CONFIG_PM
+static int gic_suspend(void)
+{
+ unsigned int i;
+ void __iomem *base = gic_data.dist_base;
+
+ for (i = 0; i * 32 < gic->irq_nr; i++) {
+ gic->enabled_irqs[i]
+ = readl_relaxed(base + GICD_ISENABLER + i * 4);
+ /* disable all of them */
+ writel_relaxed(0xffffffff, base + GICD_ICENABLER + i * 4);
+ /* enable the wakeup set */
+ writel_relaxed(gic->wakeup_irqs[i],
+ base + GICD_ISENABLER + i * 4);
+ }
+ return 0;
+}
+
+static void gic_show_pending(void)
+{
+ unsigned int i;
+ u32 enabled;
+ u32 pending[32];
+ void __iomem *base = gic_data.dist_base;
+
+ for (i = 0; i * 32 < gic->irq_nr; i++) {
+ enabled = readl_relaxed(base + GICD_ICENABLER + i * 4);
+ pending[i] = readl_relaxed(base + GICD_ISPENDR + i * 4);
+ pending[i] &= enabled;
+ }
+
+ for_each_set_bit(i, (unsigned long *)pending, gic->irq_nr) {
+ unsigned int irq = irq_find_mapping(gic->domain, i);
+ struct irq_desc *desc = irq_to_desc(irq);
+ const char *name = "null";
+
+ if (desc == NULL)
+ name = "stray irq";
+ else if (desc->action && desc->action->name)
+ name = desc->action->name;
+
+ pr_debug("Pending IRQ: %d [%s]\n", __func__, irq, name);
+ }
+}
+
+static void gic_resume(void)
+{
+ unsigned int i;
+ void __iomem *base = gic_data.dist_base;
+
+ gic_show_pending();
+
+ for (i = 0; i * 32 < gic->irq_nr; i++) {
+ /* disable all of them */
+ writel_relaxed(0xffffffff, base + GICD_ICENABLER + i * 4);
+ /* enable the enabled set */
+ writel_relaxed(gic->enabled_irqs[i],
+ base + GICD_ISENABLER + i * 4);
+ }
+}
+
+static struct syscore_ops gic_syscore_ops = {
+ .suspend = gic_suspend,
+ .resume = gic_resume,
+};
+
+static int __init gic_init_sys(void)
+{
+ register_syscore_ops(&gic_syscore_ops);
+ return 0;
+}
+device_initcall(gic_init_sys);
+
+#endif
+
static u64 gic_mpidr_to_affinity(unsigned long mpidr)
{
u64 aff;
@@ -666,6 +746,32 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
#define gic_smp_init() do { } while(0)
#endif
+#ifdef CONFIG_PM
+int gic_set_wake(struct irq_data *d, unsigned int on)
+{
+ int ret = -ENXIO;
+ unsigned int reg_offset, bit_offset;
+ unsigned int gicirq = gic_irq(d);
+ struct gic_chip_data *gic_data = irq_data_get_irq_chip_data(d);
+
+ /* per-cpu interrupts cannot be wakeup interrupts */
+ WARN_ON(gicirq < 32);
+
+ reg_offset = gicirq / 32;
+ bit_offset = gicirq % 32;
+
+ if (on)
+ gic_data->wakeup_irqs[reg_offset] |= 1 << bit_offset;
+ else
+ gic_data->wakeup_irqs[reg_offset] &= ~(1 << bit_offset);
+
+ return ret;
+}
+
+#else
+#define gic_set_wake NULL
+#endif
+
#ifdef CONFIG_CPU_PM
/* Check whether it's single security state view */
static bool gic_dist_security_disabled(void)
@@ -707,6 +813,7 @@ static struct irq_chip gic_chip = {
.irq_eoi = gic_eoi_irq,
.irq_set_type = gic_set_type,
.irq_set_affinity = gic_set_affinity,
+ .irq_set_wake = gic_set_wake,
.irq_get_irqchip_state = gic_irq_get_irqchip_state,
.irq_set_irqchip_state = gic_irq_set_irqchip_state,
.flags = IRQCHIP_SET_TYPE_MASKED,
@@ -723,6 +830,7 @@ static struct irq_chip gic_eoimode1_chip = {
.irq_set_irqchip_state = gic_irq_set_irqchip_state,
.irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity,
.flags = IRQCHIP_SET_TYPE_MASKED,
+ .irq_set_wake = gic_set_wake,
};
#define GIC_ID_NR (1U << gic_data.rdists.id_bits)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 1/4] ARM: tegra: nyan: Use proper IRQ type definitions
From: Paul Kocialkowski @ 2016-09-21 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0ca614bf-4d27-9948-03e3-472d059f2153@nvidia.com>
Le mercredi 21 septembre 2016 ? 08:52 +0100, Jon Hunter a ?crit?:
> On 20/09/16 19:14, Paul Kocialkowski wrote:
> >
> > * PGP Signed by an unknown key
> >
> > Le mardi 20 septembre 2016 ? 18:15 +0100, Jon Hunter a ?crit :
> > >
> > > On 28/08/16 18:32, Paul Kocialkowski wrote:
> > > >
> > > >
> > > > This switches a few interrupt definitions that were using
> > > > GPIO_ACTIVE_HIGH as IRQ type, which is invalid.
> > >
> > > May be you are right, but this does not describe why this is invalid.
> > > Can you elaborate?
> >
> > GPIO_ACTIVE_HIGH is simply not the right kind of define to use in the
> > "interrupts" devicetree property. Values provided there are understood as
> > IRQ_TYPE_ defines.
>
> Right, but you are changing the type as GPIO_ACTIVE_HIGH = 0 and
> IRQ_TYPE_EDGE_FALLING = 2 and there is no comment about why this has
> been changed. It might be correct, but you need to explain it.
This actually makes the IRQ trigger values consistent with the drivers, that
define them regardless of devicetree anyway. The max98090 driver
has?IRQF_TRIGGER_FALLING and bq24735 has IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING.
This is really more of a cosmetic change, it doesn't impact actual use.
--
Paul Kocialkowski, developer of low-level free software for embedded devices
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160921/989111ff/attachment.sig>
^ permalink raw reply
* [v12, 7/8] base: soc: introduce soc_device_match() interface
From: Peter Rosin @ 2016-09-21 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474444574.270880035@f136.i.mail.ru>
On 2016-09-21 09:56, Alexander Shiyan wrote:
>> ?????, 21 ???????? 2016, 9:57 +03:00 ?? Yangbo Lu <yangbo.lu@nxp.com>:
>>
>> From: Arnd Bergmann < arnd@arndb.de >
>>
>> We keep running into cases where device drivers want to know the exact
>> version of the a SoC they are currently running on. In the past, this has
>> usually been done through a vendor specific API that can be called by a
>> driver, or by directly accessing some kind of version register that is
>> not part of the device itself but that belongs to a global register area
>> of the chip.
> ...
>> +const struct soc_device_attribute *soc_device_match(
>> +const struct soc_device_attribute *matches)
>> +{
>> +int ret = 0;
>> +
>> +if (!matches)
>> +return NULL;
>> +
>> +while (!ret) {
>> +if (!(matches->machine || matches->family ||
>> + matches->revision || matches->soc_id))
>> +break;
>> +ret = bus_for_each_dev(&soc_bus_type, NULL, (void *)matches,
>> + soc_device_match_one);
>> +if (!ret)
>> +matches++;
>
> So, what happen if next "matches" (after increment) will be NULL?
A crash?
> I think you should use while(matches) at the start of this procedure.
*arrgh*
*If* matches wrap, you indeed have *big* problems. *Elsewhere*
Hint: Please read the review comments on the previous version of this
series [1] before commenting further.
Cheers,
Peter
[1] https://www.mail-archive.com/netdev at vger.kernel.org/msg126617.html
^ 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