* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: tomas.hlavacek at nic.cz @ 2016-11-22 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120203037.pd5mhqyjeotileve@perseus.defre.kleine-koenig.org>
Hi Uwe!
On Sun, Nov 20, 2016 at 9:30 PM, Uwe Kleine-K?nig
<uwe@kleine-koenig.org> wrote:
> Hello Tomas,
>
> On Sat, Nov 19, 2016 at 09:09:07PM +0100, tomas.hlavacek at nic.cz wrote:
>> On Mon, Nov 14, 2016 at 9:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > Interrupts don't seem to work very well with the nxp,pca9538.
>> Which
>> > is probably why it is disabled by default.
>>
>> I was thinking about this issue and I can remember that there was
>> an earlier
>> prototype that had a shared interrupt line from PHY (88E1514) and
>> from the
>> PCA9538. In this case we needed to specifically disable the
>> interrupt of the
>> PHY to release the interrupt line (which needed a hack into PHY
>> driver
>> code). The IRQ from PHY is connected as an ordinary input to
>> PCA9538 in
>> later board prototype. And the same holds for the production
>> version.
>
> That would explain why I see an "irq but nobody cared" message when
> booting the original system.
>
> This isn't the problem I meant though. When adding interrupt-parent =
> <&pcawan>; interrupts = <7 IRQ_TYPE_LEVEL_LOW>; to the phy node I get
> an
> error saying that there is no irq domain associated with this device.
>
>> Do you have CZ11NIC13 or older board revision?
>
> CZ11NIC12 is indicated on my board.
:-( Well, this board version has wrongly matched length of some
differential pairs, IRQ from 88E1514 is connected differently, there
are slight differences in power supplies and (if I am not mistaken)
something changed in RTC support circuitry. It looks like a huge
mistake on our side.
Anyway I took your patch and tried few things:
- clean up comments
- add pca9538 interrupt-controller
- remove rtc disable (WFM with CZ11NIC13, which is the production board)
- add MBUS mem regions for CESA
- add IRQ for 88E1514 PHY - and there is a problem:
It seems that libphy is probed before pca9538 and we end up with:
[ 4.217550] libphy: orion_mdio_bus: probed
[ 4.221777] irq: no irq domain found for
/soc/internal-regs/i2c at 11000/i2cmux at 70/i2c at 7/gpio at 71 !
Any clue where to look in order to defer probing libphy or at least
orion_mdio_bus?
I'll post my version of the patch without the PHY IRQ (therefore
polling will kick in).
Thanks,
Tomas
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: David Lechner @ 2016-11-22 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479207611-18028-1-git-send-email-bgolaszewski@baylibre.com>
On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
> controller drivers to da850.dtsi.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> v1 -> v2:
> - moved the priority controller node above the cfgchip node
> - renamed added nodes to better reflect their purpose
>
> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 1bb1f6d..412eec6 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -210,6 +210,10 @@
> };
>
> };
> + prictrl: priority-controller at 14110 {
> + compatible = "ti,da850-mstpri";
> + reg = <0x14110 0x0c>;
I think we should add status = "disabled"; here and let boards opt in.
> + };
> cfgchip: chip-controller at 1417c {
> compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
> reg = <0x1417c 0x14>;
> @@ -451,4 +455,8 @@
> 1 0 0x68000000 0x00008000>;
> status = "disabled";
> };
> + memctrl: memory-controller at b0000000 {
> + compatible = "ti,da850-ddr-controller";
> + reg = <0xb0000000 0xe8>;
same here. status = "disabled";
> + };
> };
>
^ permalink raw reply
* [RFC PATCH 04/11] PCI: tegra: limit to MMU build only
From: Stephen Warren @ 2016-11-22 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4182371.efWsDqfOeS@wuerfel>
On 11/22/2016 02:16 PM, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 9:15:13 AM CET Stephen Warren wrote:
>> On 11/22/2016 02:26 AM, Vladimir Murzin wrote:
>>> This driver uses functionality which available for MMU build only,
>>> thus add dependency on MMU.
>>
>> I'd expect ARCH_TEGRA to depend on MMU instead.
>>
>
> Any particular reason for why we'd single out Tegra?
From the cover letter, it sounded like the point of the series was to
all !MMU builds for a bunch of SoCs with M-class cores. Tegra doesn't
have an M-class core so I wouldn't expect it to be included in such a
build. I'd expect the same fix that I suggested to apply to all
non-M-class SoCs, rather than fixing up individual drivers to depend on
!MMU.
^ permalink raw reply
* [PATCH V9 1/6] tracing: add a possibility of exporting function trace to other places instead of ring buffer only
From: Steven Rostedt @ 2016-11-22 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479715043-6534-2-git-send-email-zhang.chunyan@linaro.org>
On Mon, 21 Nov 2016 15:57:18 +0800
Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> Currently Function traces can be only exported to ring buffer, this
> patch added trace_export concept which can process traces and export
> them to a registered destination as an addition to the current only
> one output of Ftrace - i.e. ring buffer.
>
> In this way, if we want Function traces to be sent to other destination
> rather than ring buffer only, we just need to register a new trace_export
> and implement its own .write() function for writing traces to storage.
>
> With this patch, only Function trace (trace type is TRACE_FN)
> is supported.
>
> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
> ---
> include/linux/trace.h | 28 +++++++++++
> kernel/trace/trace.c | 129 +++++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 156 insertions(+), 1 deletion(-)
> create mode 100644 include/linux/trace.h
>
> diff --git a/include/linux/trace.h b/include/linux/trace.h
> new file mode 100644
> index 0000000..9330a58
> --- /dev/null
> +++ b/include/linux/trace.h
> @@ -0,0 +1,28 @@
> +#ifndef _LINUX_TRACE_H
> +#define _LINUX_TRACE_H
> +
> +#ifdef CONFIG_TRACING
> +/*
> + * The trace export - an export of Ftrace output. The trace_export
> + * can process traces and export them to a registered destination as
> + * an addition to the current only output of Ftrace - i.e. ring buffer.
> + *
> + * If you want traces to be sent to some other place rather than ring
> + * buffer only, just need to register a new trace_export and implement
> + * its own .write() function for writing traces to the storage.
> + *
> + * next - pointer to the next trace_export
> + * write - copy traces which have been delt with ->commit() to
> + * the destination
> + */
> +struct trace_export {
> + struct trace_export __rcu *next;
> + void (*write)(const void *, unsigned int);
> +};
> +
> +int register_ftrace_export(struct trace_export *export);
> +int unregister_ftrace_export(struct trace_export *export);
> +
> +#endif /* CONFIG_TRACING */
> +
> +#endif /* _LINUX_TRACE_H */
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8696ce6..038291d 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -40,6 +40,7 @@
> #include <linux/poll.h>
> #include <linux/nmi.h>
> #include <linux/fs.h>
> +#include <linux/trace.h>
> #include <linux/sched/rt.h>
>
> #include "trace.h"
> @@ -2128,6 +2129,129 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
> ftrace_trace_userstack(buffer, flags, pc);
> }
>
> +static void
> +trace_process_export(struct trace_export *export,
> + struct ring_buffer_event *event)
> +{
> + struct trace_entry *entry;
> + unsigned int size = 0;
> +
> + entry = ring_buffer_event_data(event);
> + size = ring_buffer_event_length(event);
> + export->write(entry, size);
> +}
> +
> +static DEFINE_MUTEX(ftrace_export_lock);
> +
> +static struct trace_export __rcu *ftrace_exports_list __read_mostly;
> +
> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
> +
> +static inline void ftrace_exports_enable(void)
> +{
> + static_branch_enable(&ftrace_exports_enabled);
> +}
> +
> +static inline void ftrace_exports_disable(void)
> +{
> + static_branch_disable(&ftrace_exports_enabled);
> +}
> +
> +void ftrace_exports(struct ring_buffer_event *event)
I'm currently testing the patches, but is there a reason that
ftrace_exports() is not static?
-- Steve
> +{
> + struct trace_export *export;
> +
> + preempt_disable_notrace();
> +
> + export = rcu_dereference_raw_notrace(ftrace_exports_list);
> + while (export) {
> + trace_process_export(export, event);
> + export = rcu_dereference_raw_notrace(export->next);
> + }
> +
> + preempt_enable_notrace();
> +}
> +
> +static inline void
> +add_trace_export(struct trace_export **list, struct trace_export *export)
> +{
> + rcu_assign_pointer(export->next, *list);
> + /*
> + * We are entering export into the list but another
> + * CPU might be walking that list. We need to make sure
> + * the export->next pointer is valid before another CPU sees
> + * the export pointer included into the list.
> + */
> + rcu_assign_pointer(*list, export);
> +}
> +
> +static inline int
> +rm_trace_export(struct trace_export **list, struct trace_export *export)
> +{
> + struct trace_export **p;
> +
> + for (p = list; *p != NULL; p = &(*p)->next)
> + if (*p == export)
> + break;
> +
> + if (*p != export)
> + return -1;
> +
> + rcu_assign_pointer(*p, (*p)->next);
> +
> + return 0;
> +}
> +
> +static inline void
> +add_ftrace_export(struct trace_export **list, struct trace_export *export)
> +{
> + if (*list == NULL)
> + ftrace_exports_enable();
> +
> + add_trace_export(list, export);
> +}
> +
> +static inline int
> +rm_ftrace_export(struct trace_export **list, struct trace_export *export)
> +{
> + int ret;
> +
> + ret = rm_trace_export(list, export);
> + if (*list == NULL)
> + ftrace_exports_disable();
> +
> + return ret;
> +}
> +
> +int register_ftrace_export(struct trace_export *export)
> +{
> + if (WARN_ON_ONCE(!export->write))
> + return -1;
> +
> + mutex_lock(&ftrace_export_lock);
> +
> + add_ftrace_export(&ftrace_exports_list, export);
> +
> + mutex_unlock(&ftrace_export_lock);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(register_ftrace_export);
> +
> +int unregister_ftrace_export(struct trace_export *export)
> +{
> + int ret;
> +
> + mutex_lock(&ftrace_export_lock);
> +
> + ret = rm_ftrace_export(&ftrace_exports_list, export);
> +
> + mutex_unlock(&ftrace_export_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(unregister_ftrace_export);
> +
> void
> trace_function(struct trace_array *tr,
> unsigned long ip, unsigned long parent_ip, unsigned long flags,
> @@ -2146,8 +2270,11 @@ trace_function(struct trace_array *tr,
> entry->ip = ip;
> entry->parent_ip = parent_ip;
>
> - if (!call_filter_check_discard(call, entry, buffer, event))
> + if (!call_filter_check_discard(call, entry, buffer, event)) {
> + if (static_branch_unlikely(&ftrace_exports_enabled))
> + ftrace_exports(event);
> __buffer_unlock_commit(buffer, event);
> + }
> }
>
> #ifdef CONFIG_STACKTRACE
^ permalink raw reply
* [RFC PATCH 04/11] PCI: tegra: limit to MMU build only
From: Arnd Bergmann @ 2016-11-22 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d9fd3fab-d648-0664-bd73-994bebf36bf4@wwwdotorg.org>
On Tuesday, November 22, 2016 3:27:35 PM CET Stephen Warren wrote:
> On 11/22/2016 02:16 PM, Arnd Bergmann wrote:
> > On Tuesday, November 22, 2016 9:15:13 AM CET Stephen Warren wrote:
> >> On 11/22/2016 02:26 AM, Vladimir Murzin wrote:
> >>> This driver uses functionality which available for MMU build only,
> >>> thus add dependency on MMU.
> >>
> >> I'd expect ARCH_TEGRA to depend on MMU instead.
> >>
> >
> > Any particular reason for why we'd single out Tegra?
>
> From the cover letter, it sounded like the point of the series was to
> all !MMU builds for a bunch of SoCs with M-class cores. Tegra doesn't
> have an M-class core so I wouldn't expect it to be included in such a
> build. I'd expect the same fix that I suggested to apply to all
> non-M-class SoCs, rather than fixing up individual drivers to depend on
> !MMU.
I think you misread that, the point is to get NOMMU support back for
machines other than ARMv7-M, the Cortex-M based machines already work
without this.
Arnd
^ permalink raw reply
* [PATCH V9 11/11] ARM64/PCI: Support for ACPI based PCI host controller
From: Bjorn Helgaas @ 2016-11-22 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1465588519-11334-12-git-send-email-tn@semihalf.com>
Hi Tomasz,
On Fri, Jun 10, 2016 at 09:55:19PM +0200, Tomasz Nowicki wrote:
> Implement pci_acpi_scan_root and other arch-specific call so that ARM64
> can start using ACPI to setup and enumerate PCI buses.
>
> Prior to buses enumeration the pci_acpi_scan_root() implementation looks
> for configuration space start address (obtained through ACPI _CBA method or
> MCFG interface). If succeed, it uses ECAM library to create new mapping.
> Then it attaches generic ECAM ops (pci_generic_ecam_ops) which are used
> for accessing configuration space later on.
> ...
> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
> + .release_info = pci_acpi_generic_release_info,
> +};
> +
> +/* Interface called from ACPI code to setup PCI host controller */
> struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> {
> - /* TODO: Should be revisited when implementing PCI on ACPI */
> - return NULL;
> + int node = acpi_get_node(root->device->handle);
> + struct acpi_pci_generic_root_info *ri;
> + struct pci_bus *bus, *child;
> +
> + ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
> + if (!ri)
> + return NULL;
> +
> + ri->cfg = pci_acpi_setup_ecam_mapping(root);
> + if (!ri->cfg) {
> + kfree(ri);
> + return NULL;
> + }
> +
> + acpi_pci_root_ops.pci_ops = &ri->cfg->ops->pci_ops;
This has already been merged, but this isn't right, is it? We're
writing a host controller-specific pointer into the single system-wide
acpi_pci_root_ops, then passing it on to acpi_pci_root_create().
Today, I think ri->cfg->ops->pci_ops is always &pci_generic_ecam_ops,
from this path:
ri->cfg = pci_acpi_setup_ecam_mapping
cfg = pci_ecam_create(..., &pci_generic_ecam_ops)
cfg = kzalloc(...)
cfg->ops = ops # &pci_generic_ecam_ops
But we're about to merge the ECAM quirks series, which will mean it
may not be &pci_generic_ecam_ops. Even apart from the ECAM quirks, we
should avoid this pattern of putting device-specific info in a single
shared structure because it's too difficult to verify that it's
correct.
> + bus = acpi_pci_root_create(root, &acpi_pci_root_ops, &ri->common,
> + ri->cfg);
Bjorn
^ permalink raw reply
* [GIT PULL] Second Round of Renesas ARM Based SoC Updates for v4.10
From: Olof Johansson @ 2016-11-22 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUtu9N28rOb+813DumtbyAZJB3G+euD0mwwXD_jCiXrRg@mail.gmail.com>
On Tue, Nov 22, 2016 at 1:56 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Olof,
>
> On Mon, Nov 21, 2016 at 5:35 PM, Olof Johansson <olof@lixom.net> wrote:
>> On Mon, Nov 21, 2016 at 8:27 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Mon, Nov 21, 2016 at 5:19 PM, Olof Johansson <olof@lixom.net> wrote:
>>>> On Mon, Nov 21, 2016 at 1:31 AM, Geert Uytterhoeven
>>>> <geert@linux-m68k.org> wrote:
>>>>> On Sat, Nov 19, 2016 at 2:28 AM, Olof Johansson <olof@lixom.net> wrote:
>>>>>> On Thu, Nov 17, 2016 at 02:34:25PM +0100, Simon Horman wrote:
>>>>>>> Please consider these second round of Renesas ARM based SoC updates for v4.10.
>>>>>
>>>>>>> * Basic support for r8a7745 SoC
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> Sergei Shtylyov (2):
>>>>>>> ARM: shmobile: r8a7745: basic SoC support
>>>>>>> ARM: shmobile: document SK-RZG1E board
>>>>>>
>>>>>> Is there a reason you're adding a config option per SoC?
>>>>>>
>>>>>> I think you'd be better off not adding these config options, and just adding
>>>>>> support for the SoCs through compatibles (and adding the drivers to defconfigs,
>>>>>> etc).
>>>>>
>>>>> Yes there is a reason: kernel size.
>>>>> The main offenders are the pinctrl tables, which add ca. 20-50 KiB per
>>>>> supported SoC.
>>>>
>>>> So don't turn on that pinctrl driver unless you have that SoC?
>>>
>>> The enablement of the pinctrl driver (and the clock driver, FWIW) is controlled
>>> by the SoC Kconfig symbol. If you want support for the SoC, you want the
>>> pinctrl driver, too.
>>
>> Oh, that's trivial to fix! Do as almost all other SoCs do, and don't
>> use silent options.
>
> What does that gain us? The ability to enable support for an SoC, without
> enabling the accompanying pinctrl driver, leading to a non-booting system?
It doesn't enable anything new, it just makes it less awkward for you
to add new SoCs in the future without creating dependencies on new
Kconfig symbols in the arch directory.
> As soon as you have any pinctrl properties in the DT, you need the pinctrl
> driver. Unless you disable CONFIG_PINCTRL (it's selected, and not
> user-controlled), and rely on fragile reset state/boot loader.
>
> Pinctrl (and clock and irqchip) on-SoC drivers are special: if you fail to
> include them, the system won't boot.
This isn't about booting without a pinctrl driver. It's about avoiding
adding new config symbols when they're not needed.
I started out comparing your way of using config options with, for
example, Exynos that has a bunch of different SoCs enabled. Having
dependencies described clearly has some value, since it can be hard to
know if you can turn off a driver and still have a bootable system
with some of the other platforms.
That being said, I think you should look at changing how you use your
config options to make it less messy to add new ones:
Looking around a bit, I noticed CLK_RENESAS_CPG_MSTP. This config
option is used awkwardly -- what you should have is a (silent) config
option that it depends on (such as {NEEDS|HAS}_CLK_CPG_MSTP or
similar), that each platform needing this can select. Then
CLK_RENESAS_CPG_MSTP only depends on that. No more need to touch this
config entry for every new SoC that is enabled.
Also, right now drivers/clk/renesas/Makefile is all keyed off of the
SoC config option, when instead you should consider a CLK_* option to
avoid duplication like you have today. For the shared platforms you
can do it just as above with HAS_.* config entries. Again, for some of
these you won't have to touch the clk/ directory at all any more for
new SoCs, the way the rcar2 ones have been made!
pinctrl config seems like it's a bit heavy on boiler plate as well.
Most of the entries do the same things. Many other platforms instead
select the pinctrl driver from the SoC Kconfig entry, maybe this is a
good approach here too, and avoids more boilerplate in the driver
directory. Of course, legacy SH platforms can probably be left alone
as they are though.
-Olof
^ permalink raw reply
* linux-next: manual merge of the clk tree with the arm-soc tree
From: Stephen Rothwell @ 2016-11-22 23:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdU5Df2kNT=ccr7Ts6=a1ELRJdiBbh1xxuqo+e_UeYw-tw@mail.gmail.com>
Hi Geert,
On Tue, 22 Nov 2016 10:36:46 +0100 Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Most of these are of the "add both sides" type.
> The only exception is the one in arch/arm/mach-shmobile/setup-rcar-gen2.c,
> where you just want to keep the call to of_clk_init(NULL);
>
> There's a resolution in
> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/?h=renesas-devel-20161117v2-v4.9-rc5%2brcar-rst
>
> Sorry for the mess.
Thanks for the help. Today I did this much earlier in the build and
got the following merge resolution (which matches yours, I think).
The resolution for arch/arm/mach-shmobile/setup-rcar-gen2.c is empty
because I used the clk tree side of the conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/boot/dts/r8a7779.dtsi
index 9d3bb74bd3f6,8cf16008a09b..000000000000
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@@ -590,11 -590,11 +590,16 @@@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0xff000044 4>;
+ };
+
+ rst: reset-controller at ffcc0000 {
+ compatible = "renesas,r8a7779-reset-wdt";
+ reg = <0xffcc0000 0x48>;
+ };
+
sysc: system-controller at ffd85000 {
compatible = "renesas,r8a7779-sysc";
reg = <0xffd85000 0x0200>;
diff --cc arch/arm/boot/dts/r8a7790.dtsi
index f554ef3c8096,3f10b0bf1b08..000000000000
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@@ -1471,11 -1471,11 +1471,16 @@@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7790-rst";
+ reg = <0 0xe6160000 0 0x0100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7790-sysc";
reg = <0 0xe6180000 0 0x0200>;
diff --cc arch/arm/boot/dts/r8a7791.dtsi
index 4c50de2faef1,c465c79bcca6..000000000000
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@@ -1485,11 -1482,11 +1485,16 @@@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7791-rst";
+ reg = <0 0xe6160000 0 0x0100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7791-sysc";
reg = <0 0xe6180000 0 0x0200>;
diff --cc arch/arm/boot/dts/r8a7792.dtsi
index 69789020cf39,6e1f61f65d29..000000000000
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@@ -120,11 -118,11 +120,16 @@@
IRQ_TYPE_LEVEL_LOW)>;
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7792-rst";
+ reg = <0 0xe6160000 0 0x0100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7792-sysc";
reg = <0 0xe6180000 0 0x0200>;
diff --cc arch/arm/boot/dts/r8a7793.dtsi
index a377dda17724,e4b385eccf74..000000000000
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@@ -1306,11 -1279,11 +1306,16 @@@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7793-rst";
+ reg = <0 0xe6160000 0 0x0100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7793-sysc";
reg = <0 0xe6180000 0 0x0200>;
diff --cc arch/arm/boot/dts/r8a7794.dtsi
index 63dc7f29d216,69e4f4fad89b..000000000000
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@@ -1377,11 -1375,11 +1377,16 @@@
};
};
+ prr: chipid at ff000044 {
+ compatible = "renesas,prr";
+ reg = <0 0xff000044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7794-rst";
+ reg = <0 0xe6160000 0 0x0100>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7794-sysc";
reg = <0 0xe6180000 0 0x0200>;
diff --cc arch/arm/mach-shmobile/setup-rcar-gen2.c
index 14c1f0ed2ecb,b527258e0a62..000000000000
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
diff --cc arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a39a702b904d,625dda713548..000000000000
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@@ -321,11 -321,11 +321,16 @@@
#power-domain-cells = <0>;
};
+ prr: chipid at fff00044 {
+ compatible = "renesas,prr";
+ reg = <0 0xfff00044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7795-rst";
+ reg = <0 0xe6160000 0 0x0200>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7795-sysc";
reg = <0 0xe6180000 0 0x0400>;
diff --cc arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 41a050d2f192,75c8c55a8248..000000000000
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@@ -243,11 -233,11 +243,16 @@@
#power-domain-cells = <0>;
};
+ prr: chipid at fff00044 {
+ compatible = "renesas,prr";
+ reg = <0 0xfff00044 0 4>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7796-rst";
+ reg = <0 0xe6160000 0 0x0200>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7796-sysc";
reg = <0 0xe6180000 0 0x0400>;
diff --cc drivers/soc/renesas/Makefile
index 91c42b34705f,86cc78cd1962..000000000000
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@@ -1,7 -1,8 +1,12 @@@
+obj-$(CONFIG_SOC_BUS) += renesas-soc.o
+
+ obj-$(CONFIG_ARCH_RCAR_GEN1) += rcar-rst.o
+ obj-$(CONFIG_ARCH_RCAR_GEN2) += rcar-rst.o
+ obj-$(CONFIG_ARCH_R8A7795) += rcar-rst.o
+ obj-$(CONFIG_ARCH_R8A7796) += rcar-rst.o
+
+obj-$(CONFIG_ARCH_R8A7743) += rcar-sysc.o r8a7743-sysc.o
+obj-$(CONFIG_ARCH_R8A7745) += rcar-sysc.o r8a7745-sysc.o
obj-$(CONFIG_ARCH_R8A7779) += rcar-sysc.o r8a7779-sysc.o
obj-$(CONFIG_ARCH_R8A7790) += rcar-sysc.o r8a7790-sysc.o
obj-$(CONFIG_ARCH_R8A7791) += rcar-sysc.o r8a7791-sysc.o
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-cm-fx6: enable S/PDIF support
From: christopher.spinrath at rwth-aachen.de @ 2016-11-23 0:07 UTC (permalink / raw)
To: linux-arm-kernel
From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
Enable the S/PDIF transceiver present on the cm-fx6 module.
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
---
arch/arm/boot/dts/imx6q-cm-fx6.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
index cad1dc5..42b1031 100644
--- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
+++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
@@ -89,6 +89,14 @@
gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ sound-spdif {
+ compatible = "fsl,imx-audio-spdif";
+ model = "imx-spdif";
+ spdif-controller = <&spdif>;
+ spdif-out;
+ spdif-in;
+ };
};
&cpu0 {
@@ -222,6 +230,13 @@
>;
};
+ pinctrl_spdif: spdifgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_16__SPDIF_IN 0x1b0b0
+ MX6QDL_PAD_GPIO_19__SPDIF_OUT 0x1b0b0
+ >;
+ };
+
pinctrl_uart4: uart4grp {
fsl,pins = <
MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
@@ -259,6 +274,12 @@
status = "okay";
};
+&spdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spdif>;
+ status = "okay";
+};
+
&uart4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart4>;
--
2.10.2
^ permalink raw reply related
* [RFC PATCH] ARM: dts: Add support for Turris Omnia
From: Tomas Hlavacek @ 2016-11-23 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479851991.26813.2@smtp.gmail.com>
Turris Omnia board by CZ.NIC:
* Marvell Armada 385 SoC
* 1 or 2 GB DDR3
* eMMC
* 8 MB SPI flash (U-Boot and rescue Linux image)
* 88E1514 PHY
* 88E6176 Ethernet switch (not supported)
Supported board revision: CZ11NIC13 (production board).
Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
---
Changes since Uwe's version:
- add MBUS regions (needed for Marvell CESA)
- remove rtc disable (WFM with CZ11NIC13 = production board)
- cleanup comments
Unsupported peripherals:
- MV88E7176 switch
- SFP
- LEDs
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-turris-omnia.dts | 279 ++++++++++++++++++++++++++
2 files changed, 280 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..f1d3b9ff 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-db-ap.dtb \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
+ armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 0000000..5ef3d62
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,279 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ *
+ * Copyright (C) 2016 Uwe Kleine-K?nig <uwe@kleine-koenig.org>
+ * Copyright (C) 2016 Tomas Hlavacek <tmshlvkc@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+ model = "Turris Omnia";
+ compatible = "cznic,turris-omnia", "marvell,armada385", \
+ "marvell,armada380";
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>; /* 1024 MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
+ MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
+ MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+
+ internal-regs {
+
+ /* USB part of the PCIe2/USB 2.0 port */
+ usb at 58000 {
+ status = "okay";
+ };
+
+ sata at a8000 {
+ status = "okay";
+ };
+
+ sdhci at d8000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhci_pins>;
+ status = "okay";
+
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ };
+
+ usb3 at f0000 {
+ status = "okay";
+ };
+
+ usb3 at f8000 {
+ status = "okay";
+ };
+ };
+
+ pcie-controller {
+ status = "okay";
+
+ pcie at 1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+
+ pcie at 2,0 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+ };
+
+ pcie at 3,0 {
+ /* Port 2, Lane 0 */
+ status = "okay";
+ };
+ };
+ };
+};
+
+/* Connected to 88E6176 switch, port 6 */
+ð0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* Connected to 88E6176 switch, port 5 */
+ð1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge1_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* WAN port */
+ð2 {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy = <&phy1>;
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ i2cmux at 70 {
+ compatible = "nxp,pca9547";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ status = "okay";
+
+ i2c at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+
+ /* STM32F0 command interface at address 0x2a.
+ * STM32F0 LED interface at address 0x2b.
+ */
+
+ eeprom at 54 {
+ compatible = "at,24c64";
+ reg = <0x54>;
+
+ /* The EEPROM contains data for bootloader.
+ * Contents:
+ * struct omnia_eeprom {
+ * u32 magic; (=0x0341a034)
+ * u32 ramsize;
+ * char region[4] (=0x0);
+ * u32 crc32;
+ * };
+ */
+ };
+ };
+
+ /* Channel 1: Routed to PCIe0/mSATA connector (CN7A).
+ * Channel 2: Routed to PCIe1/USB2 connector (CN61A).
+ * Channel 3: Routed to PCIe2 connector (CN62A).
+ * Channel 4: Routed to SFP+.
+ * Channel 5: ATSHA204A at address 0x64.
+ * Channel 6: Routed to user pin header CN11.
+ */
+
+ i2c at 7 {
+ /* GPIO expander for SFP+ signals */
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+
+ wangpio: gpio at 71 {
+ compatible = "nxp,pca9538";
+ reg = <0x71>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
+};
+
+&mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ status = "okay";
+
+ phy1: phy at 1 {
+ status = "okay";
+ compatible = "ethernet-phy-id0141.0DD1", \
+ "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ /* IRQ is connected to PCA9538 pin 7. Currently it
+ * can not be utilized.
+ */
+ };
+
+ /* Switch MV88E7176 at address 0x10. */
+};
+
+&pinctrl {
+ spi0cs1_pins: spi0-pins-0cs1 {
+ marvell,pins = "mpp26";
+ marvell,function = "spi0";
+ };
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins &spi0cs1_pins>;
+ status = "okay";
+
+ spi-nor at 0 {
+ compatible = "spansion,s25fl164k", "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+
+ partition at 0 {
+ reg = <0x0 0x00100000>;
+ label = "U-Boot";
+ };
+
+ partition at 1 {
+ reg = <0x00100000 0x00700000>;
+ label = "Rescue system";
+ };
+ };
+
+ /* SPI0 + CS1 (MPP26) is routed to a pin header CN11. */
+};
+
+&uart0 {
+ /* Pin header CN10. */
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+&uart1 {
+ /* Pin header CN11. */
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "okay";
+};
+
--
2.7.4
^ permalink raw reply related
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: tomas.hlavacek at nic.cz @ 2016-11-23 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479851991.26813.2@smtp.gmail.com>
Hi Uwe!
On Tue, Nov 22, 2016 at 10:59 PM, tomas.hlavacek at nic.cz wrote:
> Anyway I took your patch and tried few things:
> - add pca9538 interrupt-controller
> - add IRQ for 88E1514 PHY - and there is a problem:
...
I thought it over and if I am not mistaken this is not going to work
anyway, because pca9538 driver causes the GPIO driver to set
IRQ_NESTED_THREAD, so we can not simply use one of the GPIO expander
pins as IRQ source for 88E1514, because request_irq() on it will fail
ultimately.
Tomas
^ permalink raw reply
* [RFC PATCH] ARM: dts: Add support for Turris Omnia
From: Andrew Lunn @ 2016-11-23 0:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479859770-9375-1-git-send-email-tmshlvck@gmail.com>
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -0,0 +1,279 @@
> +/*
> + * Device Tree file for the Turris Omnia
> + * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
Hi Tomas
Cool that there is a link to the schematics. But please could you put
it lower down. It is more likely to be seen if it comes after the
copyright and license section.
> + sdhci at d8000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdhci_pins>;
> + status = "okay";
> +
> + bus-width = <8>;
> + no-1-8-v;
> + non-removable;
> + };
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins>;
> + status = "okay";
> +
> + i2cmux at 70 {
> + compatible = "nxp,pca9547";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x70>;
> + status = "okay";
> +
> + /* Channel 1: Routed to PCIe0/mSATA connector (CN7A).
> + * Channel 2: Routed to PCIe1/USB2 connector (CN61A).
> + * Channel 3: Routed to PCIe2 connector (CN62A).
> + * Channel 4: Routed to SFP+.
> + * Channel 5: ATSHA204A at address 0x64.
> + * Channel 6: Routed to user pin header CN11.
> + */
I've not looked at how the pca9547 works.... Will it instantiate a bus
only if there is a node in the device tree with a reg property?
What i'm thinking is that it is possible to indicate to the i2c core
that a device is on a bus using echo to a file. But this only works if
the bus exists. You could for example say using echo that there is an
at24 EEPROM on channel 4 and get access to the EEPROM inside the SFP
module. But that only works if the i2c bus exists. Does it?
No leds? No buttons via gpio-keys?
Andrew
^ permalink raw reply
* [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
From: Russell King - ARM Linux @ 2016-11-23 0:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.20.1611221106410.1814@knanqh.ubzr>
On Tue, Nov 22, 2016 at 11:34:48AM -0500, Nicolas Pitre wrote:
> On Tue, 22 Nov 2016, Arnd Bergmann wrote:
> > This adds an asm/asm-prototypes.h header for ARM to fix the broken symbol
> > versioning for symbols exported from assembler files.
> >
> > I couldn't find the correct prototypes for the compiler builtins,
> > so I went with the fake 'void f(void)' prototypes that we had
> > before, restoring the state before they were moved.
> >
> > Originally I assumed that the problem was just a harmless warning
> > in unusual configurations, but as Uwe found, we actually need this
> > to load most modules when symbol versioning is enabled, as it is
> > in many distro kernels.
> >
> > Cc: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> > Fixes: 4dd1837d7589 ("arm: move exports to definitions")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > Compared to the earlier version, I dropped the changes to the
> > csumpartial files, which now get handled correctly by Kbuild
> > even when the export comes from a macro, and I also dropped the
> > changes to the bitops files, which were already fixed in a
> > patch from Nico.
> >
> > The patch applies cleanly on top of the rmk/fixes tree but has
> > no effect there, as it also needs 4efca4ed05cb ("kbuild: modversions
> > for EXPORT_SYMBOL() for asm") and cc6acc11cad1 ("kbuild: be more
> > careful about matching preprocessed asm ___EXPORT_SYMBOL").
> >
> > With the combination of rmk/fixes, torvalds/master and these two
> > patches, symbol versioning works again on ARM. As it is still
> > broken on almost all other architectures (powerpc is fixed,
> > x86 has a patch), I wonder if we should make CONFIG_MODVERSIONS
> > as broken for everything else.
>
> I'm not sure I like this at all.
>
> The goal for moving EXPORT_SYMBOL() to assembly code where symbols were
> defined is to make things close together and avoid those centralized
> list of symbols that you can easily miss when modifying the actual code.
>
> This series is therefore bringing back a centralized list of symbols in
> a slightly different form, nullifying the advantages from having moved
> EXPORT_SYMBOL() to asm code. To me this looks like a big step backward.
>
> Why not simply extending the original idea of keeping exports close to
> the actual code by _also_ having a macro that provides the function
> prototype alongside the EXPORT_SYMBOL() instance? That could even be
> expressed with some EXPORT_SYMBOL_PROTO(ret, sym, arg...) macro that
> does it all.
What you're saying is that you don't like the solution that's taken
weeks to get merged up to this point, so where do we go from here
now? This crap has been broken since 4.9-rc1, and is a regression.
I think at this point, we just declare that modversions are broken
on ARM, and those who created this mess get to explain to people
why the fsck they broke the kernel.
4.9 is the next LTS kernel? ROTFL!
I agree with Nicolas - it seems that the whole EXPORT_SYMBOL() crap
has just been a pointless exercise in churn, resulting only in
something "different" because it looks "cool" to do it some other
way. There's no real benefit here at all, only harm.
Just revert the damned patches that created this breakage in the
first place please. It's now way too late to be trying to fix it
any other way.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: dts: imx7d: fix LCDIF clock assignment
From: Stefan Agner @ 2016-11-23 0:42 UTC (permalink / raw)
To: linux-arm-kernel
The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them
separately:
Clock Clock Root Description
apb_clk MAIN_AXI_CLK_ROOT AXI clock
pix_clk LCDIF_PIXEL_CLK_ROOT Pixel clock
ipg_clk_s MAIN_AXI_CLK_ROOT Peripheral access clock
All of them are switched by a single gate, which is part of the
IMX7D_LCDIF_PIXEL_ROOT_CLK clock. Hence using that clock also for
the AXI bus clock (clock-name "axi") makes sure the gate gets
enabled when accessing registers.
There seem to be no separate AXI display clock, and the clock is
optional. Hence remove the dummy clock.
This fixes kernel freezes when starting the X-Server (which
disables/re-enables the display controller).
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7s.dtsi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 0d7d5ac..2b6cb05 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -643,9 +643,8 @@
reg = <0x30730000 0x10000>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_LCDIF_PIXEL_ROOT_CLK>,
- <&clks IMX7D_CLK_DUMMY>,
- <&clks IMX7D_CLK_DUMMY>;
- clock-names = "pix", "axi", "disp_axi";
+ <&clks IMX7D_LCDIF_PIXEL_ROOT_CLK>;
+ clock-names = "pix", "axi";
status = "disabled";
};
};
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
From: Nicholas Piggin @ 2016-11-23 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.20.1611221106410.1814@knanqh.ubzr>
On Tue, 22 Nov 2016 11:34:48 -0500 (EST)
Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Tue, 22 Nov 2016, Arnd Bergmann wrote:
>
> > This adds an asm/asm-prototypes.h header for ARM to fix the broken symbol
> > versioning for symbols exported from assembler files.
> >
> > I couldn't find the correct prototypes for the compiler builtins,
> > so I went with the fake 'void f(void)' prototypes that we had
> > before, restoring the state before they were moved.
> >
> > Originally I assumed that the problem was just a harmless warning
> > in unusual configurations, but as Uwe found, we actually need this
> > to load most modules when symbol versioning is enabled, as it is
> > in many distro kernels.
> >
> > Cc: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> > Fixes: 4dd1837d7589 ("arm: move exports to definitions")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > Compared to the earlier version, I dropped the changes to the
> > csumpartial files, which now get handled correctly by Kbuild
> > even when the export comes from a macro, and I also dropped the
> > changes to the bitops files, which were already fixed in a
> > patch from Nico.
> >
> > The patch applies cleanly on top of the rmk/fixes tree but has
> > no effect there, as it also needs 4efca4ed05cb ("kbuild: modversions
> > for EXPORT_SYMBOL() for asm") and cc6acc11cad1 ("kbuild: be more
> > careful about matching preprocessed asm ___EXPORT_SYMBOL").
> >
> > With the combination of rmk/fixes, torvalds/master and these two
> > patches, symbol versioning works again on ARM. As it is still
> > broken on almost all other architectures (powerpc is fixed,
> > x86 has a patch), I wonder if we should make CONFIG_MODVERSIONS
> > as broken for everything else.
>
> I'm not sure I like this at all.
>
> The goal for moving EXPORT_SYMBOL() to assembly code where symbols were
> defined is to make things close together and avoid those centralized
> list of symbols that you can easily miss when modifying the actual code.
Right.
>
> This series is therefore bringing back a centralized list of symbols in
> a slightly different form, nullifying the advantages from having moved
> EXPORT_SYMBOL() to asm code. To me this looks like a big step backward.
Exported symbols have C declarations in headers already. For the most
part, anyway -- these ones Arnd adds are for compiler runtime which is
why some architectures haven't had the prototypes.
> Why not simply extending the original idea of keeping exports close to
> the actual code by _also_ having a macro that provides the function
> prototype alongside the EXPORT_SYMBOL() instance? That could even be
> expressed with some EXPORT_SYMBOL_PROTO(ret, sym, arg...) macro that
> does it all.
Well, the reason is to get 4.9 working, I never thought asm-prototypes.h
was a beautiful solution or it should not be changed if we can find ways
to improve it.
EXPORT_SYMBOL_PROTO() for asm code seems possibly a good idea for 4.10.
Of course your exported symbols will still have their prototypes in
various headers -- that redundancy is inherent.
Thanks,
Nick
^ permalink raw reply
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-23 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_xW+7KAC8fHquEwHynYzpy6OoO1ZjEm5mVKMo1S8j4Nw@mail.gmail.com>
On Tue, Nov 22, 2016 at 10:09:50AM +0000, Ard Biesheuvel wrote:
> On 17 November 2016 at 17:59, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > +PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
> > +describe all the address space they consume. In principle, this would
> > +be all the windows they forward down to the PCI bus, as well as the
> > +bridge registers themselves. The bridge registers include things like
> > +secondary/subordinate bus registers that determine the bus range below
> > +the bridge, window registers that describe the apertures, etc. These
> > +are all device-specific, non-architected things, so the only way a
> > +PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which
> > +contain the device-specific details. These bridge registers also
> > +include ECAM space, since it is consumed by the bridge.
> > +
> > +ACPI defined a Producer/Consumer bit that was intended to distinguish
> > +the bridge apertures from the bridge registers [4, 5]. However,
> > +BIOSes didn't use that bit correctly, and the result is that OSes have
> > +to assume that everything in a PCI host bridge _CRS is a window. That
> > +leaves no way to describe the bridge registers in the PNP0A03/PNP0A08
> > +device itself.
>
> Is that universally true? Or is it still possible to do the right
> thing here on new ACPI architectures such as arm64?
That's a very good question. I had thought that the ACPI spec had
given up on Consumer/Producer completely, but I was wrong. In the 6.0
spec, the Consumer/Producer bit is still documented in the Extended
Address Space Descriptor (sec 6.4.3.5.4). It is documented as
"ignored" in the QWord, DWord, and Word descriptors (sec 6.4.3.5.1,2,3).
Linux looks at the producer_consumer bit in acpi_decode_space(), which
I think is used for all these descriptors (QWord, DWord, Word, and
Extended). This doesn't quite follow the spec -- we probably should
ignore it except for Extended. In any event, acpi_decode_space() sets
IORESOURCE_WINDOW for Producer descriptors, but we don't test
IORESOURCE_WINDOW in the PCI host bridge code.
x86 and ia64 supply their own pci_acpi_root_prepare_resources()
functions that call acpi_pci_probe_root_resources(), which parses _CRS
and looks at producer_consumer. Then they do a little arch-specific
stuff on the result.
On arm64 we use acpi_pci_probe_root_resources() directly, with no
arch-specific stuff.
On all three arches, we ignore the Consumer/Producer bit, so all the
resources are treated as Producers, e.g., as bridge windows.
I think we *could* implement an arm64 version of
pci_acpi_root_prepare_resources() that would pay attention to the
Consumer/Producer bit by checking IORESOURCE_WINDOW. To be spec
compliant, we would have to use Extended descriptors for all bridge
windows, even if they would fit in a DWord or QWord.
Should we do that? I dunno. I'd like to hear your opinion(s).
It *would* be nice to have bridge registers in the bridge _CRS. That
would eliminate the need for looking up the HISI0081/PNP0C02 devices
to find the bridge registers. Avoiding that lookup is only a
temporary advantage -- the next round of bridges are supposed to fully
implement ECAM, and then we won't need to know where the registers
are.
Apart from the lookup, there's still some advantage in describing the
registers in the PNP0A03 device instead of an unrelated PNP0C02
device, because it makes /proc/iomem more accurate and potentially
makes host bridge hotplug cleaner. We would have to enhance the host
bridge driver to do the reservations currently done by pnp/system.c.
There's some value in doing it the same way as on x86, even though
that way is somewhat broken.
Whatever we decide, I think it's very important to get it figured out
ASAP because it affects the ECAM quirks that we're trying to merge in
v4.10.
> > +The workaround is to describe the bridge registers (including ECAM
> > +space) in PNP0C02 catch-all devices [6]. With the exception of ECAM,
> > +the bridge register space is device-specific anyway, so the generic
> > +PNP0A03/PNP0A08 driver (pci_root.c) has no need to know about it. For
> > +ECAM, pci_root.c learns about the space from either MCFG or the _CBA
> > +method.
> > +
> > +Note that the PCIe spec actually does require ECAM unless there's a
> > +standard firmware interface for config access, e.g., the ia64 SAL
> > +interface [7]. One reason is that we want a generic host bridge
> > +driver (pci_root.c), and a generic driver requires a generic way to
> > +access config space.
> > +
> > +
> > +[1] ACPI 6.0, sec 6.1:
> > + For any device that is on a non-enumerable type of bus (for
> > + example, an ISA bus), OSPM enumerates the devices' identifier(s)
> > + and the ACPI system firmware must supply an _HID object ... for
> > + each device to enable OSPM to do that.
> > +
> > +[2] ACPI 6.0, sec 3.7:
> > + The OS enumerates motherboard devices simply by reading through
> > + the ACPI Namespace looking for devices with hardware IDs.
> > +
> > + Each device enumerated by ACPI includes ACPI-defined objects in
> > + the ACPI Namespace that report the hardware resources the device
> > + could occupy [_PRS], an object that reports the resources that are
> > + currently used by the device [_CRS], and objects for configuring
> > + those resources [_SRS]. The information is used by the Plug and
> > + Play OS (OSPM) to configure the devices.
> > +
> > +[3] ACPI 6.0, sec 6.2:
> > + OSPM uses device configuration objects to configure hardware
> > + resources for devices enumerated via ACPI. Device configuration
> > + objects provide information about current and possible resource
> > + requirements, the relationship between shared resources, and
> > + methods for configuring hardware resources.
> > +
> > + When OSPM enumerates a device, it calls _PRS to determine the
> > + resource requirements of the device. It may also call _CRS to
> > + find the current resource settings for the device. Using this
> > + information, the Plug and Play system determines what resources
> > + the device should consume and sets those resources by calling the
> > + device?s _SRS control method.
> > +
> > + In ACPI, devices can consume resources (for example, legacy
> > + keyboards), provide resources (for example, a proprietary PCI
> > + bridge), or do both. Unless otherwise specified, resources for a
> > + device are assumed to be taken from the nearest matching resource
> > + above the device in the device hierarchy.
> > +
> > +[4] ACPI 6.0, sec 6.4.3.5.4:
> > + Extended Address Space Descriptor
> > + General Flags: Bit [0] Consumer/Producer:
> > + 1?This device consumes this resource
> > + 0?This device produces and consumes this resource
> > +
> > +[5] ACPI 6.0, sec 19.6.43:
> > + ResourceUsage specifies whether the Memory range is consumed by
> > + this device (ResourceConsumer) or passed on to child devices
> > + (ResourceProducer). If nothing is specified, then
> > + ResourceConsumer is assumed.
> > +
> > +[6] PCI Firmware 3.0, sec 4.1.2:
> > + If the operating system does not natively comprehend reserving the
> > + MMCFG region, the MMCFG region must be reserved by firmware. The
> > + address range reported in the MCFG table or by _CBA method (see
> > + Section 4.1.3) must be reserved by declaring a motherboard
> > + resource. For most systems, the motherboard resource would appear
> > + at the root of the ACPI namespace (under \_SB) in a node with a
> > + _HID of EISAID (PNP0C02), and the resources in this case should
> > + not be claimed in the root PCI bus?s _CRS. The resources can
> > + optionally be returned in Int15 E820 or EFIGetMemoryMap as
> > + reserved memory but must always be reported through ACPI as a
> > + motherboard resource.
> > +
> > +[7] PCI Express 3.0, sec 7.2.2:
> > + For systems that are PC-compatible, or that do not implement a
> > + processor-architecture-specific firmware interface standard that
> > + allows access to the Configuration Space, the ECAM is required as
> > + defined in this section.
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] clk: uniphier: add CPU-gear change (cpufreq) support
From: Masahiro Yamada @ 2016-11-23 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477503088-26508-1-git-send-email-yamada.masahiro@socionext.com>
Hi Stephen,
Ping.
2016-10-27 2:31 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> Core support code for CPU frequency changes, which will be used by
> the generic cpufreq driver.
>
> The register view is different from the generic clk-mux; it has
> a separate status register, and an update bit to load the register
> setting.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> drivers/clk/uniphier/Makefile | 3 +
> drivers/clk/uniphier/clk-uniphier-core.c | 3 +
> drivers/clk/uniphier/clk-uniphier-cpugear.c | 115 ++++++++++++++++++++++++++++
> drivers/clk/uniphier/clk-uniphier.h | 17 +++-
> 4 files changed, 136 insertions(+), 2 deletions(-)
> create mode 100644 drivers/clk/uniphier/clk-uniphier-cpugear.c
>
> diff --git a/drivers/clk/uniphier/Makefile b/drivers/clk/uniphier/Makefile
> index f27b3603..665d1d6 100644
> --- a/drivers/clk/uniphier/Makefile
> +++ b/drivers/clk/uniphier/Makefile
> @@ -1,8 +1,11 @@
> obj-y += clk-uniphier-core.o
> +
> +obj-y += clk-uniphier-cpugear.o
> obj-y += clk-uniphier-fixed-factor.o
> obj-y += clk-uniphier-fixed-rate.o
> obj-y += clk-uniphier-gate.o
> obj-y += clk-uniphier-mux.o
> +
> obj-y += clk-uniphier-sys.o
> obj-y += clk-uniphier-mio.o
> obj-y += clk-uniphier-peri.o
> diff --git a/drivers/clk/uniphier/clk-uniphier-core.c b/drivers/clk/uniphier/clk-uniphier-core.c
> index 26c53f7..0007218 100644
> --- a/drivers/clk/uniphier/clk-uniphier-core.c
> +++ b/drivers/clk/uniphier/clk-uniphier-core.c
> @@ -27,6 +27,9 @@ static struct clk_hw *uniphier_clk_register(struct device *dev,
> const struct uniphier_clk_data *data)
> {
> switch (data->type) {
> + case UNIPHIER_CLK_TYPE_CPUGEAR:
> + return uniphier_clk_register_cpugear(dev, regmap, data->name,
> + &data->data.cpugear);
> case UNIPHIER_CLK_TYPE_FIXED_FACTOR:
> return uniphier_clk_register_fixed_factor(dev, data->name,
> &data->data.factor);
> diff --git a/drivers/clk/uniphier/clk-uniphier-cpugear.c b/drivers/clk/uniphier/clk-uniphier-cpugear.c
> new file mode 100644
> index 0000000..9bff26e
> --- /dev/null
> +++ b/drivers/clk/uniphier/clk-uniphier-cpugear.c
> @@ -0,0 +1,115 @@
> +/*
> + * Copyright (C) 2016 Socionext Inc.
> + * Author: Masahiro Yamada <yamada.masahiro@socionext.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/regmap.h>
> +
> +#include "clk-uniphier.h"
> +
> +#define UNIPHIER_CLK_CPUGEAR_STAT 0 /* status */
> +#define UNIPHIER_CLK_CPUGEAR_SET 4 /* set */
> +#define UNIPHIER_CLK_CPUGEAR_UPD 8 /* update */
> +#define UNIPHIER_CLK_CPUGEAR_UPD_BIT BIT(0)
> +
> +struct uniphier_clk_cpugear {
> + struct clk_hw hw;
> + struct regmap *regmap;
> + unsigned int regbase;
> + unsigned int mask;
> +};
> +
> +#define to_uniphier_clk_cpugear(_hw) \
> + container_of(_hw, struct uniphier_clk_cpugear, hw)
> +
> +static int uniphier_clk_cpugear_set_parent(struct clk_hw *hw, u8 index)
> +{
> + struct uniphier_clk_cpugear *gear = to_uniphier_clk_cpugear(hw);
> + int ret;
> + unsigned int val;
> +
> + ret = regmap_write_bits(gear->regmap,
> + gear->regbase + UNIPHIER_CLK_CPUGEAR_SET,
> + gear->mask, index);
> + if (ret)
> + return ret;
> +
> + ret = regmap_write_bits(gear->regmap,
> + gear->regbase + UNIPHIER_CLK_CPUGEAR_SET,
> + UNIPHIER_CLK_CPUGEAR_UPD_BIT,
> + UNIPHIER_CLK_CPUGEAR_UPD_BIT);
> + if (ret)
> + return ret;
> +
> + return regmap_read_poll_timeout(gear->regmap,
> + gear->regbase + UNIPHIER_CLK_CPUGEAR_UPD,
> + val, !(val & UNIPHIER_CLK_CPUGEAR_UPD_BIT),
> + 0, 1);
> +}
> +
> +static u8 uniphier_clk_cpugear_get_parent(struct clk_hw *hw)
> +{
> + struct uniphier_clk_cpugear *gear = to_uniphier_clk_cpugear(hw);
> + int num_parents = clk_hw_get_num_parents(hw);
> + int ret;
> + unsigned int val;
> +
> + ret = regmap_read(gear->regmap,
> + gear->regbase + UNIPHIER_CLK_CPUGEAR_STAT, &val);
> + if (ret)
> + return ret;
> +
> + val &= gear->mask;
> +
> + return val < num_parents ? val : -EINVAL;
> +}
> +
> +static const struct clk_ops uniphier_clk_cpugear_ops = {
> + .determine_rate = __clk_mux_determine_rate,
> + .set_parent = uniphier_clk_cpugear_set_parent,
> + .get_parent = uniphier_clk_cpugear_get_parent,
> +};
> +
> +struct clk_hw *uniphier_clk_register_cpugear(struct device *dev,
> + struct regmap *regmap,
> + const char *name,
> + const struct uniphier_clk_cpugear_data *data)
> +{
> + struct uniphier_clk_cpugear *gear;
> + struct clk_init_data init;
> + int ret;
> +
> + gear = devm_kzalloc(dev, sizeof(*gear), GFP_KERNEL);
> + if (!gear)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = name;
> + init.ops = &uniphier_clk_cpugear_ops;
> + init.flags = CLK_SET_RATE_PARENT;
> + init.parent_names = data->parent_names;
> + init.num_parents = data->num_parents,
> +
> + gear->regmap = regmap;
> + gear->regbase = data->regbase;
> + gear->mask = data->mask;
> + gear->hw.init = &init;
> +
> + ret = devm_clk_hw_register(dev, &gear->hw);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + return &gear->hw;
> +}
> diff --git a/drivers/clk/uniphier/clk-uniphier.h b/drivers/clk/uniphier/clk-uniphier.h
> index 0244dba..9707b0f 100644
> --- a/drivers/clk/uniphier/clk-uniphier.h
> +++ b/drivers/clk/uniphier/clk-uniphier.h
> @@ -20,15 +20,24 @@
> struct device;
> struct regmap;
>
> -#define UNIPHIER_CLK_MUX_MAX_PARENTS 8
> +#define UNIPHIER_CLK_CPUGEAR_MAX_PARENTS 16
> +#define UNIPHIER_CLK_MUX_MAX_PARENTS 8
>
> enum uniphier_clk_type {
> + UNIPHIER_CLK_TYPE_CPUGEAR,
> UNIPHIER_CLK_TYPE_FIXED_FACTOR,
> UNIPHIER_CLK_TYPE_FIXED_RATE,
> UNIPHIER_CLK_TYPE_GATE,
> UNIPHIER_CLK_TYPE_MUX,
> };
>
> +struct uniphier_clk_cpugear_data {
> + const char *parent_names[UNIPHIER_CLK_CPUGEAR_MAX_PARENTS];
> + unsigned int num_parents;
> + unsigned int regbase;
> + unsigned int mask;
> +};
> +
> struct uniphier_clk_fixed_factor_data {
> const char *parent_name;
> unsigned int mult;
> @@ -58,6 +67,7 @@ struct uniphier_clk_data {
> enum uniphier_clk_type type;
> int idx;
> union {
> + struct uniphier_clk_cpugear_data cpugear;
> struct uniphier_clk_fixed_factor_data factor;
> struct uniphier_clk_fixed_rate_data rate;
> struct uniphier_clk_gate_data gate;
> @@ -90,7 +100,10 @@ struct uniphier_clk_data {
> }, \
> }
>
> -
> +struct clk_hw *uniphier_clk_register_cpugear(struct device *dev,
> + struct regmap *regmap,
> + const char *name,
> + const struct uniphier_clk_cpugear_data *data);
> struct clk_hw *uniphier_clk_register_fixed_factor(struct device *dev,
> const char *name,
> const struct uniphier_clk_fixed_factor_data *data);
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
From: Nicolas Pitre @ 2016-11-23 1:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123120436.18dc21e7@roar.ozlabs.ibm.com>
On Wed, 23 Nov 2016, Nicholas Piggin wrote:
> On Tue, 22 Nov 2016 11:34:48 -0500 (EST)
> Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>
> > On Tue, 22 Nov 2016, Arnd Bergmann wrote:
> >
> > > This adds an asm/asm-prototypes.h header for ARM to fix the broken symbol
> > > versioning for symbols exported from assembler files.
> > >
> > > I couldn't find the correct prototypes for the compiler builtins,
> > > so I went with the fake 'void f(void)' prototypes that we had
> > > before, restoring the state before they were moved.
> > >
> > > Originally I assumed that the problem was just a harmless warning
> > > in unusual configurations, but as Uwe found, we actually need this
> > > to load most modules when symbol versioning is enabled, as it is
> > > in many distro kernels.
> > >
> > > Cc: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> > > Fixes: 4dd1837d7589 ("arm: move exports to definitions")
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > Compared to the earlier version, I dropped the changes to the
> > > csumpartial files, which now get handled correctly by Kbuild
> > > even when the export comes from a macro, and I also dropped the
> > > changes to the bitops files, which were already fixed in a
> > > patch from Nico.
> > >
> > > The patch applies cleanly on top of the rmk/fixes tree but has
> > > no effect there, as it also needs 4efca4ed05cb ("kbuild: modversions
> > > for EXPORT_SYMBOL() for asm") and cc6acc11cad1 ("kbuild: be more
> > > careful about matching preprocessed asm ___EXPORT_SYMBOL").
> > >
> > > With the combination of rmk/fixes, torvalds/master and these two
> > > patches, symbol versioning works again on ARM. As it is still
> > > broken on almost all other architectures (powerpc is fixed,
> > > x86 has a patch), I wonder if we should make CONFIG_MODVERSIONS
> > > as broken for everything else.
> >
> > I'm not sure I like this at all.
> >
> > The goal for moving EXPORT_SYMBOL() to assembly code where symbols were
> > defined is to make things close together and avoid those centralized
> > list of symbols that you can easily miss when modifying the actual code.
>
> Right.
>
> >
> > This series is therefore bringing back a centralized list of symbols in
> > a slightly different form, nullifying the advantages from having moved
> > EXPORT_SYMBOL() to asm code. To me this looks like a big step backward.
>
> Exported symbols have C declarations in headers already. For the most
> part, anyway -- these ones Arnd adds are for compiler runtime which is
> why some architectures haven't had the prototypes.
Hmmm. That's right. That makes it much more justifiable.
My main objection is withdrawn.
However there is a bunch of includes added to asm-prototypes.h:
+#include <linux/arm-smccc.h>
+#include <linux/bitops.h>
+#include <linux/ftrace.h>
+#include <linux/io.h>
+#include <linux/platform_data/asoc-imx-ssi.h>
+#include <linux/string.h>
+#include <linux/uaccess.h>
+
+#include <asm/checksum.h>
+#include <asm/div64.h>
+#include <asm/memory.h>
Are those necessary at all?
Nicolas
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-23 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479860851.10840.11@smtp.gmail.com>
On Wed, Nov 23, 2016 at 01:27:31AM +0100, tomas.hlavacek at nic.cz wrote:
> Hi Uwe!
>
> On Tue, Nov 22, 2016 at 10:59 PM, tomas.hlavacek at nic.cz wrote:
> >Anyway I took your patch and tried few things:
> >- add pca9538 interrupt-controller
> >- add IRQ for 88E1514 PHY - and there is a problem:
> ...
>
> I thought it over and if I am not mistaken this is not going to work
> anyway, because pca9538 driver causes the GPIO driver to set
> IRQ_NESTED_THREAD, so we can not simply use one of the GPIO expander
> pins as IRQ source for 88E1514, because request_irq() on it will
> fail ultimately.
Actually, the phylib now does uses threaded IRQs, since i implemented
interrupt support for the mv88e6xxx driver. Its interrupts require
MDIO transactions, so have to be threaded.
However, i don't think using interrupts on the pca9538 are
reliable. Interrupt support is compile time optional for that
driver. It is not clear to me if distributions do compile the driver
with interrupts enabled. So it could be the probe fails with OpenWRT,
Debian, etc...
Andrew
^ permalink raw reply
* [PATCH 0/2] kexec-tools: arm64: Add dcache enabling facility
From: Pratyush Anand @ 2016-11-23 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8415f028-f42e-2980-9b60-e85aae046d02@infradead.org>
Hi Geoff,
On Wednesday 23 November 2016 12:26 AM, Geoff Levand wrote:
> Hi Pratyush,
>
> On 11/21/2016 08:32 PM, Pratyush Anand wrote:
>> It takes more that 2 minutes to verify SHA in purgatory when vmlinuz
>> image
>> is around 13MB and initramfs is around 30MB. It takes more than 20 second
>> even when we have -O2 optimization enabled. However, if dcache is enabled
>> during purgatory execution then, it takes just a second in SHA
>> verification.
>
> As I had mentioned in another thread, I think -O2 optimization is
> sufficient considering the complexity of the code needed to enable
> the dcache. Integrity checking is only needed for crash dump
> support. If the crash reboot takes an extra 20 seconds does it
> matter?
>
Even this 20 second for kdump case is also annoying and this could
increase if the size of initramfs increases.
Moreover, by default d-cache is still disabled, so even if it is complex
and you might see some instability, it will not affect the existing
systems. So, IMHO we should have this in the upstream.
> For the re-boot of a stable system where the new kernel is loaded
> then immediately kexec'ed into integrity checking is not needed.
> For that arm64 support needs to be added to kexec-lite.
I think kexec-lite is a separate project and --lite in kexec-tools was
never acked. So, even for `kexec -l` it will be helpful.
~Pratyush
^ permalink raw reply
* [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
From: Nicholas Piggin @ 2016-11-23 1:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123004106.GA14217@n2100.armlinux.org.uk>
On Wed, 23 Nov 2016 00:41:07 +0000
Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> On Tue, Nov 22, 2016 at 11:34:48AM -0500, Nicolas Pitre wrote:
> > On Tue, 22 Nov 2016, Arnd Bergmann wrote:
> > > This adds an asm/asm-prototypes.h header for ARM to fix the broken symbol
> > > versioning for symbols exported from assembler files.
> > >
> > > I couldn't find the correct prototypes for the compiler builtins,
> > > so I went with the fake 'void f(void)' prototypes that we had
> > > before, restoring the state before they were moved.
> > >
> > > Originally I assumed that the problem was just a harmless warning
> > > in unusual configurations, but as Uwe found, we actually need this
> > > to load most modules when symbol versioning is enabled, as it is
> > > in many distro kernels.
> > >
> > > Cc: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> > > Fixes: 4dd1837d7589 ("arm: move exports to definitions")
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > Compared to the earlier version, I dropped the changes to the
> > > csumpartial files, which now get handled correctly by Kbuild
> > > even when the export comes from a macro, and I also dropped the
> > > changes to the bitops files, which were already fixed in a
> > > patch from Nico.
> > >
> > > The patch applies cleanly on top of the rmk/fixes tree but has
> > > no effect there, as it also needs 4efca4ed05cb ("kbuild: modversions
> > > for EXPORT_SYMBOL() for asm") and cc6acc11cad1 ("kbuild: be more
> > > careful about matching preprocessed asm ___EXPORT_SYMBOL").
> > >
> > > With the combination of rmk/fixes, torvalds/master and these two
> > > patches, symbol versioning works again on ARM. As it is still
> > > broken on almost all other architectures (powerpc is fixed,
> > > x86 has a patch), I wonder if we should make CONFIG_MODVERSIONS
> > > as broken for everything else.
> >
> > I'm not sure I like this at all.
> >
> > The goal for moving EXPORT_SYMBOL() to assembly code where symbols were
> > defined is to make things close together and avoid those centralized
> > list of symbols that you can easily miss when modifying the actual code.
> >
> > This series is therefore bringing back a centralized list of symbols in
> > a slightly different form, nullifying the advantages from having moved
> > EXPORT_SYMBOL() to asm code. To me this looks like a big step backward.
> >
> > Why not simply extending the original idea of keeping exports close to
> > the actual code by _also_ having a macro that provides the function
> > prototype alongside the EXPORT_SYMBOL() instance? That could even be
> > expressed with some EXPORT_SYMBOL_PROTO(ret, sym, arg...) macro that
> > does it all.
>
> What you're saying is that you don't like the solution that's taken
> weeks to get merged up to this point, so where do we go from here
> now? This crap has been broken since 4.9-rc1, and is a regression.
>
> I think at this point, we just declare that modversions are broken
> on ARM, and those who created this mess get to explain to people
> why the fsck they broke the kernel.
Let's fix it instead :)
Why not merge Arnd's 2 patches? I think he mostly addressed your concerns
of them. Or...
>
> 4.9 is the next LTS kernel? ROTFL!
>
> I agree with Nicolas - it seems that the whole EXPORT_SYMBOL() crap
> has just been a pointless exercise in churn, resulting only in
> something "different" because it looks "cool" to do it some other
> way. There's no real benefit here at all, only harm.
>
> Just revert the damned patches that created this breakage in the
> first place please. It's now way too late to be trying to fix it
> any other way.
>
4dd1837d7589 diffstat is entirely in arch/arm. I think reverting that
would fix it (I haven't tested it myself so I would advise testing
before committing). So the ball is in your court.
As for process concerns, you have made valid points. Sometimes a mistake
is made or we make an incorrect assumption about how another person works
or what mailing lists they have read, or do not anticipate the fallout
from some change.
Everyone does it sometimes, so it's never a bad time to reflect on how
we work with others and try to do better.
Thanks,
Nick
^ permalink raw reply
* [PATCH 2/2] arm64: Pass RAM boundary and enable-dcache flag to purgatory
From: Pratyush Anand @ 2016-11-23 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53ee2a62-7822-5457-e59f-e65e64a57019@infradead.org>
Hi Geoff,
On Wednesday 23 November 2016 12:27 AM, Geoff Levand wrote:
> Hi Pratyush,
>
> On 11/21/2016 08:32 PM, Pratyush Anand wrote:
>> When "enable-dcache" is passed to the kexec() command line, kexec-tools
>> passes this information to purgatory, which in turn enables cache during
>> sha-256 verification.
>
> What's the point of this enable-dcache option? Why not just
> always enable the cache if we can?
As I have written in changelog of patch 1/2
"We are supporting only 4K and 64K page sizes. This code will not work if a
hardware is not supporting at least one of these page sizes. Therefore,
D-cache is disabled by default and enabled only when "enable-dcache" is
passed to the kexec()."
Although this is very unlikely that a hardware will support only 16K
page sizes, however it is possible. Therefore, its better to keep it
disabled by default.
~Pratyush
^ permalink raw reply
* [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Rick Chang @ 2016-11-23 1:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <badf8125-27ed-9c5b-fbc0-75716ffdfb0e@xs4all.nl>
Hi Hans,
On Tue, 2016-11-22 at 13:43 +0100, Hans Verkuil wrote:
> On 22/11/16 04:21, Rick Chang wrote:
> > Hi Hans,
> >
> > On Mon, 2016-11-21 at 15:51 +0100, Hans Verkuil wrote:
> >> On 17/11/16 04:38, Rick Chang wrote:
> >>> Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> >>> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> >>> ---
> >>> This patch depends on:
> >>> CCF "Add clock support for Mediatek MT2701"[1]
> >>> iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
> >>>
> >>> [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
> >>> [2] https://patchwork.kernel.org/patch/9164013/
> >>
> >> I assume that 1 & 2 will appear in 4.10? So this patch needs to go in
> >> after the
> >> other two are merged in 4.10?
> >>
> >> Regards,
> >>
> >> Hans
> >
> > [1] will appear in 4.10, but [2] will appear latter than 4.10.So this
> > patch needs to go in after [1] & [2] will be merged in 4.11.
>
> So what should I do? Merge the driver for 4.11 and wait with this patch
> until [2] is merged in 4.11? Does that sound reasonable?
>
> Regards,
>
> Hans
What do you think about this? You merge the driver first and I send this
patch again after [1] & [2] is merged.
^ permalink raw reply
* [PATCH 2/2] arm64: Pass RAM boundary and enable-dcache flag to purgatory
From: Dave Young @ 2016-11-23 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54cad725-90f0-8dfe-bee6-fe1d3e02175d@redhat.com>
On 11/23/16 at 07:16am, Pratyush Anand wrote:
> Hi Geoff,
>
> On Wednesday 23 November 2016 12:27 AM, Geoff Levand wrote:
> > Hi Pratyush,
> >
> > On 11/21/2016 08:32 PM, Pratyush Anand wrote:
> > > When "enable-dcache" is passed to the kexec() command line, kexec-tools
> > > passes this information to purgatory, which in turn enables cache during
> > > sha-256 verification.
> >
> > What's the point of this enable-dcache option? Why not just
> > always enable the cache if we can?
>
> As I have written in changelog of patch 1/2
>
> "We are supporting only 4K and 64K page sizes. This code will not work if a
> hardware is not supporting at least one of these page sizes. Therefore,
> D-cache is disabled by default and enabled only when "enable-dcache" is
> passed to the kexec()."
>
>
> Although this is very unlikely that a hardware will support only 16K page
> sizes, however it is possible. Therefore, its better to keep it disabled by
> default.
If it is *unlikely* it could be better to make it as default and add a
--disable-dcache instead.
>
> ~Pratyush
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Thanks
Dave
^ permalink raw reply
* [PATCH 2/2] arm64: Pass RAM boundary and enable-dcache flag to purgatory
From: Pratyush Anand @ 2016-11-23 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123020300.GA3481@dhcp-128-65.nay.redhat.com>
On Wednesday 23 November 2016 07:33 AM, Dave Young wrote:
>> Although this is very unlikely that a hardware will support only 16K page
>> > sizes, however it is possible. Therefore, its better to keep it disabled by
>> > default.
> If it is *unlikely* it could be better to make it as default and add a
> --disable-dcache instead.
>
I think, I can do that.
~Pratyush
^ 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