* [RFC] arm64/acpi: make ACPI boot preference configurable
From: Jonathan Toppins @ 2016-12-21 17:54 UTC (permalink / raw)
To: linux-arm-kernel
This patch allows a user to configure ACPI to be preferred over
device-tree.
Currently for ACPI to be used a user either has to set acpi=on on the
kernel command line or make sure any device tree passed to the kernel
is empty. If the dtb passed to the kernel is non-empty then device-tree
will be chosen as the boot method of choice even if it is not correct.
To prevent this situation where a system is only intended to be booted
via ACPI a user can set this kernel configuration so it ignores
device-tree settings unless ACPI table checks fail.
Signed-off-by: Jonathan Toppins <jtoppins@redhat.com>
---
arch/arm64/Kconfig | 13 +++++++++++++
arch/arm64/kernel/acpi.c | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 111742126897..e432e84245b9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -954,6 +954,19 @@ config ARM64_ACPI_PARKING_PROTOCOL
protocol even if the corresponding data is present in the ACPI
MADT table.
+config ARM64_PREFER_ACPI
+ bool "Prefer usage of ACPI boot tables over device-tree"
+ depends on ACPI
+ help
+ Normally device-tree is preferred over ACPI on arm64 unless
+ explicitly preferred via kernel command line, something like: acpi=on
+ This configuration changes this default behaviour by pretending
+ the user set acpi=on on the command line. This configuration still
+ allows the user to turn acpi table parsing off via acpi=off. If
+ for some reason the table checks fail the system will still fall
+ back to using device-tree unless the user explicitly sets acpi=force
+ on the command line.
+
config CMDLINE
string "Default kernel command string"
default ""
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 252a6d9c1da5..b5dfa5752ff7 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -43,7 +43,7 @@ int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ initialization */
EXPORT_SYMBOL(acpi_pci_disabled);
static bool param_acpi_off __initdata;
-static bool param_acpi_on __initdata;
+static bool param_acpi_on __initdata = IS_ENABLED(CONFIG_ARM64_PREFER_ACPI);
static bool param_acpi_force __initdata;
static int __init parse_acpi(char *arg)
--
2.10.2
^ permalink raw reply related
* [PATCH net-next 14/27] net: mvpp2: add ip_version field in "struct mvpp2"
From: Thomas Petazzoni @ 2016-12-21 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221170252.GO30952@lunn.ch>
Hello,
On Wed, 21 Dec 2016 18:02:52 +0100, Andrew Lunn wrote:
> On Wed, Dec 21, 2016 at 12:16:21PM +0100, Thomas Petazzoni wrote:
> > In preparation to the introduction for the support of PPv2.2 in the
> > mvpp2 driver, this commit adds an ip_version field to the struct
> > mvpp2
>
> When i read this, i was thinking IPv4 vs IPv6. It is a network driver after all.
> Could you maybe call this hw_version?
Sure, will do. Thanks for the feedback!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net-next 14/27] net: mvpp2: add ip_version field in "struct mvpp2"
From: Andrew Lunn @ 2016-12-21 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482318994-23488-15-git-send-email-thomas.petazzoni@free-electrons.com>
Hi Thomas
Minor nit pick.
On Wed, Dec 21, 2016 at 12:16:21PM +0100, Thomas Petazzoni wrote:
> In preparation to the introduction for the support of PPv2.2 in the
> mvpp2 driver, this commit adds an ip_version field to the struct
> mvpp2
When i read this, i was thinking IPv4 vs IPv6. It is a network driver after all.
Could you maybe call this hw_version?
Thanks
Andrew
^ permalink raw reply
* How to remove warn msg "cache: parent cpui should not be sleeping" i=1, 2, 3...
From: Sudeep Holla @ 2016-12-21 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221193703.6eac880c@xhacker>
On 21/12/16 11:37, Jisheng Zhang wrote:
> Hi all,
>
> I'm not sure this is a bug, when wake up from s2ram, I could get something
> like:
>
> [ 313.271464] Enabling non-boot CPUs ...
> [ 313.271551] CPU1: Booted secondary processor
> [ 313.271556] Detected VIPT I-cache on CPU1
> [ 313.301378] cache: parent cpu1 should not be sleeping
> [ 313.301504] CPU1 is up
> [ 313.301582] CPU2: Booted secondary processor
> [ 313.301585] Detected VIPT I-cache on CPU2
> [ 313.331485] cache: parent cpu2 should not be sleeping
> [ 313.331605] CPU2 is up
> [ 313.331683] CPU3: Booted secondary processor
> [ 313.331686] Detected VIPT I-cache on CPU3
> [ 313.361599] cache: parent cpu3 should not be sleeping
> [ 313.361719] CPU3 is up
>
> This is because we call cpu_device_create() when secondary cpu is brought
> online, the cpu_cache device's parent device: cpu device isn't already
> resumed, all device resume will resume after secondary cores are brought
> up.
>
> What's the elegant solution to remove this warning msg?
>
It is not a serious warning as you can see a comment in the code:
"/*
* This is a fib. But we'll allow new children to be added below
* a resumed device, even if the device hasn't been completed yet.
*/"
But if we think it needs to be removed, I have something like below in
my mind. I am not sure if this is hacky or not(completely untested, not
even compiled).
Regards,
Sudeep
-->8
diff --git i/drivers/base/cpu.c w/drivers/base/cpu.c
index 4c28e1a09786..2a5c04377adf 100644
--- i/drivers/base/cpu.c
+++ w/drivers/base/cpu.c
@@ -344,6 +344,14 @@ static int cpu_uevent(struct device *dev, struct
kobj_uevent_env *env)
}
#endif
+static int cpu_dev_pm_unset_is_prepared(unsigned int cpu)
+{
+ struct device *cpu_dev = get_cpu_device(cpu);
+
+ if(cpu_dev)
+ cpu_dev->power.is_prepared = false;
+ return 0;
+}
/*
* register_cpu - Setup a sysfs device for a CPU.
* @cpu - cpu->hotpluggable field set to 1 will generate a control file in
@@ -377,7 +385,9 @@ int register_cpu(struct cpu *cpu, int num)
per_cpu(cpu_sys_devices, num) = &cpu->dev;
register_cpu_under_node(num, cpu_to_node(num));
- return 0;
+ return cpuhp_setup_state_nocalls(CPUHP_CPUDEV_PM_PREPARE,
+ "base/cpu/dev_pm:prepare",
+ cpu_dev_pm_unset_is_prepared, NULL);
}
struct device *get_cpu_device(unsigned cpu)
diff --git i/include/linux/cpuhotplug.h w/include/linux/cpuhotplug.h
index 2ab7bf53d529..5bfe3c1aa148 100644
--- i/include/linux/cpuhotplug.h
+++ w/include/linux/cpuhotplug.h
@@ -51,6 +51,7 @@ enum cpuhp_state {
CPUHP_SLAB_PREPARE,
CPUHP_MD_RAID5_PREPARE,
CPUHP_RCUTREE_PREP,
+ CPUHP_CPUDEV_PM_PREPARE,
CPUHP_CPUIDLE_COUPLED_PREPARE,
CPUHP_POWERPC_PMAC_PREPARE,
CPUHP_POWERPC_MMU_CTX_PREPARE,
^ permalink raw reply related
* [PATCH] ARM: dts: turris-omnia: add support for ethernet switch
From: Uwe Kleine-König @ 2016-12-21 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221151814.GJ30952@lunn.ch>
Hello Andrew,
On Wed, Dec 21, 2016 at 04:18:14PM +0100, Andrew Lunn wrote:
> On Wed, Dec 21, 2016 at 11:20:47AM +0100, Uwe Kleine-K?nig wrote:
> > when the MAC is operated in rgmii mode and the switch in rgmii-id
> > communication between them works fine. The other way round it doesn't work.
> > The fixed-link nodes in the cpu port description is necessary to let the
> > mv88e6xxx driver use the phy-mode description. Is this a bug?
>
> It is somewhat deliberate. Normally, there is no phy at all for a cpu
> port or a dsa port. If there is no phy, it makes no sense to set the
> phy-mode. With fixed-link, there is a phy connected to the MAC, in
> terms of how the network stack sees the devices. It is a somewhat
> special phy, in fact its bandwidth is fixed, but it does support
> phy-handle, and a few other phy properties and callbacks.
Here the switch is the phy, and in this case it is necessary to
correctly configure it's physical properties. fixed-link is conceptual
wrong here because (IIUC) this is for MACs only. So (maybe also for DSA
v3 or a general phy cleanup) a standard binding to specify this which
doesn't formalise the switch (or general: phy) as MAC.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161221/2dc91dc6/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: turris-omnia: add support for ethernet switch
From: Andrew Lunn @ 2016-12-21 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221102047.28036-1-uwe@kleine-koenig.org>
> /* Switch MV88E7176 at address 0x10 */
> + switch at 10 {
> + compatible = "marvell,mv88e6085";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dsa,member = <0 0>;
> +
> + reg = <0x10>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports at 0 {
> + reg = <0>;
> + label = "lan0";
> + phy-handle = <&lan0phy>;
snip
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + lan0phy: ethernet-phy at 0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + };
You probably don't need the phy-handle's and the whole mdio node. So
long as there is a simple mapping, port 0 uses the phy at address 0,
it should just work. You only need the mdio node when you want to
support PHY interrupts, or there is an odd mapping between port and
PHY, like the new switch chip added recently.
Andrew
^ permalink raw reply
* [PATCH net-next 00/27] net: mvpp2: add basic support for PPv2.2
From: David Miller @ 2016-12-21 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221171246.77e91d2c@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Wed, 21 Dec 2016 17:12:46 +0100
> Hello,
>
> On Wed, 21 Dec 2016 11:03:48 -0500 (EST), David Miller wrote:
>
>> 1) net-next is closed, please do not submit net-next material during
>> this time.
>
> I did not expect you to review these patches right now, as I know
> net-next is closed. However I expect other people in the net community
> and people interested in Marvell platforms to look at those patches,
> potentially test them and give feedback.
Then mark the patches as "RFC".
^ permalink raw reply
* [PATCH net-next 00/27] net: mvpp2: add basic support for PPv2.2
From: Thomas Petazzoni @ 2016-12-21 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221.110348.346806544020316686.davem@davemloft.net>
Hello,
On Wed, 21 Dec 2016 11:03:48 -0500 (EST), David Miller wrote:
> 1) net-next is closed, please do not submit net-next material during
> this time.
I did not expect you to review these patches right now, as I know
net-next is closed. However I expect other people in the net community
and people interested in Marvell platforms to look at those patches,
potentially test them and give feedback.
> 2) 27 patches is way too many to submit at one time, please keep your
> patch series submissions to a small, reasonable size.
OK, I will do some arbitrary cut in the series and send several
smaller series instead.
Thanks for the feedback,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 net-next 0/3] Add support for the ethernet switch on the ESPRESSObin
From: David Miller @ 2016-12-21 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221090045.474-1-romain.perier@free-electrons.com>
net-next is not open, please do not submit net-next changes during this
time.
^ permalink raw reply
* [PATCH net-next 00/27] net: mvpp2: add basic support for PPv2.2
From: David Miller @ 2016-12-21 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482318994-23488-1-git-send-email-thomas.petazzoni@free-electrons.com>
Two things:
1) net-next is closed, please do not submit net-next material during
this time.
2) 27 patches is way too many to submit at one time, please keep your
patch series submissions to a small, reasonable size.
Thanks.
^ permalink raw reply
* [PATCH] i2c: uniphier[-f]: fix bool logic calculation
From: Masahiro Yamada @ 2016-12-21 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482256538.1984.23.camel@perches.com>
Hi Joe,
2016-12-21 2:55 GMT+09:00 Joe Perches <joe@perches.com>:
> On Wed, 2016-12-21 at 01:20 +0900, Masahiro Yamada wrote:
>> Hi.
>>
>> I have not got any comment, but does this seem
>> a right thing to do?
>
>> This code is working, but it should not depend on how "bool" is
>> typedef'ed, or the bit position of I2C_M_RD.
>
> <shrug>
>
> I think bool can be guaranteed to be _Bool.
>
> So a change not necessary as the original code
> has a c90 guarantee of the same result.
>
> 6.3.1.2 Boolean type
> 1
> When any scalar value is converted to _Bool, the result is 0 if the value compares equal
> to 0; otherwise, the result is 1.
>
Thanks for your comments!
_Bool works very nicely.
I have seen some (not very nice) projects
that define like "typedef char bool;"
So, I was wondering if I should write code
that works regardless how bool is defined.
Just my two cents.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [v4, 3/3] ARM: dts: vf610-zii-dev-rev-b: Remove 'fixed-link' from DSA ports
From: Andrew Lunn @ 2016-12-21 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221132519.bkkqyfk3beow7nc5@pengutronix.de>
On Wed, Dec 21, 2016 at 02:25:19PM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Dec 21, 2016 at 03:58:45PM +0300, Nikita Yushchenko wrote:
> > > Remove 'fixed-link' nodes from DSA ports since they are not needed (they
> > > are not limiting link's speed and the ports will be configured to their
> > > maximux speed as a default)
> > >
> > > Suggested-by: Andrew Lunn <andrew@lunn.ch>
> > > Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> >
> > With this patch, ports connected to revB's second switch stop working.
>
> This is probably because without a fixed-link node the phy-mode setting
> isn't applied by the driver.
Yep, bad suggestion from me. If the phy-mode was not needed, then you
can drop the fixed-link. With the phy-mode, you also need the fixed
link.
Sorry for the wasted time,
Andrew
^ permalink raw reply
* [PATCH] ARM: dts: turris-omnia: add support for ethernet switch
From: Andrew Lunn @ 2016-12-21 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221102047.28036-1-uwe@kleine-koenig.org>
On Wed, Dec 21, 2016 at 11:20:47AM +0100, Uwe Kleine-K?nig wrote:
> The Turris Omnia features a Marvell MV88E7176 ethernet switch. Add it to
> the dts.
>
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> ---
> Hello,
>
> when the MAC is operated in rgmii mode and the switch in rgmii-id
> communication between them works fine. The other way round it doesn't work.
> The fixed-link nodes in the cpu port description is necessary to let the
> mv88e6xxx driver use the phy-mode description. Is this a bug?
It is somewhat deliberate. Normally, there is no phy at all for a cpu
port or a dsa port. If there is no phy, it makes no sense to set the
phy-mode. With fixed-link, there is a phy connected to the MAC, in
terms of how the network stack sees the devices. It is a somewhat
special phy, in fact its bandwidth is fixed, but it does support
phy-handle, and a few other phy properties and callbacks.
> Regarding the binding, I think the label in the port nodes is strange.
>
> label = "lan2"
>
> for an external port is fine. But
>
> label = "cpu"
>
> for a port facing a CPU MAC looks wrong, still more as the Turris Omnia has
> two ports connected to the SoC and so there are two ports with the same
> label.
This is somewhat historical. When DSA was designed, only one CPU port
was expected. There are in fact quite a few devices with two CPU
ports. I have some old proof of concept patches to support this, with
some basic load balancing. In the last few weeks, John Crispin has
been working on them, and has duel CPU ports working for the qca8k.
So i expect early next year we can make the Marvell chips support dual
CPU ports as well.
> I would suggest to use a separate property for that, e.g.
>
> cpu-port;
>
> and no label.
I would suggest keeping this idea for DSA v3, otherwise we end up with
messy code for little gain.
Andrew
^ permalink raw reply
* [linux-sunxi] Problems to Allwinner H3's eFUSE/SID
From: Bernhard Nortmann @ 2016-12-21 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <136061482160932@web34j.yandex.ru>
Side note:
Am 19.12.2016 um 16:22 schrieb Icenowy Zheng:
> [...]
>
> According to some facts:
> - The register based access to SID is weird: it needs ~5 register
> operations per word of SID.
> [...]
>
My experiments seem to indicate that Allwinner's implementation might be
overly complicated. I have used an alternative approach and did not notice
any issues so far.
They start by reading SID_PRCTL and use bit mask operations to get in the
key index value (PG_INDEX), then use a second write to set OP_LOCK and
READ_START. As far as I can tell, it's sufficient to construct (and write)
a single value from these three components. Allwinner finally clears out
the used bits by another mask operation, simply writing zero seems to get
that job done equally well.
My implementation can be seen in
https://github.com/n1tehawk/sunxi-tools/blob/20161220_sid-fix/uart0-helloworld-sdboot.c#L242-L256
or as assembler code in
https://github.com/n1tehawk/sunxi-tools/blob/20161220_sid-fix/sid_read_root.S#L43-L65
A corresponding PR is at
https://github.com/linux-sunxi/sunxi-tools/pull/91 ,
or you may clone my branch directly
("git clone https://github.com/n1tehawk/sunxi-tools.git -b
20161220_sid-fix").
Testers would be very welcome.
Regards, B. Nortmann
^ permalink raw reply
* [PATCH v2 2/2] arm: perf: Mark as non-removable
From: Alexander Stein @ 2016-12-21 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221150340.25657-1-alexander.stein@systec-electronic.com>
This driver can only built into the kernel. So disallow driver bind/unbind
and also prevent a kernel error in case DEBUG_TEST_DRIVER_REMOVE is
enabled.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
arch/arm/kernel/perf_event_v7.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index b942349..795e373 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -2029,6 +2029,7 @@ static int armv7_pmu_device_probe(struct platform_device *pdev)
static struct platform_driver armv7_pmu_driver = {
.driver = {
.name = "armv7-pmu",
+ .suppress_bind_attrs = true,
.of_match_table = armv7_pmu_of_device_ids,
},
.probe = armv7_pmu_device_probe,
--
2.10.2
^ permalink raw reply related
* [PATCH v2 1/2] drivers/perf: arm_pmu: Use devm_ allocators
From: Alexander Stein @ 2016-12-21 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221150340.25657-1-alexander.stein@systec-electronic.com>
This eliminates several calls to kfree.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
drivers/perf/arm_pmu.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index b37b572..a9bbdbf 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -917,7 +917,8 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
bool using_spi = false;
struct platform_device *pdev = pmu->plat_device;
- irqs = kcalloc(pdev->num_resources, sizeof(*irqs), GFP_KERNEL);
+ irqs = devm_kcalloc(&pdev->dev, pdev->num_resources, sizeof(*irqs),
+ GFP_KERNEL);
if (!irqs)
return -ENOMEM;
@@ -939,7 +940,6 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
pr_err("PPI/SPI IRQ type mismatch for %s!\n",
dn->name);
of_node_put(dn);
- kfree(irqs);
return -EINVAL;
}
@@ -988,10 +988,8 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
int ret;
ret = irq_get_percpu_devid_partition(irq, &pmu->supported_cpus);
- if (ret) {
- kfree(irqs);
+ if (ret)
return ret;
- }
} else {
/* Otherwise default to all CPUs */
cpumask_setall(&pmu->supported_cpus);
@@ -1001,8 +999,6 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
/* If we matched up the IRQ affinities, use them to route the SPIs */
if (using_spi && i == pdev->num_resources)
pmu->irq_affinity = irqs;
- else
- kfree(irqs);
return 0;
}
@@ -1017,7 +1013,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
struct arm_pmu *pmu;
int ret = -ENODEV;
- pmu = kzalloc(sizeof(struct arm_pmu), GFP_KERNEL);
+ pmu = devm_kzalloc(&pdev->dev, sizeof(struct arm_pmu), GFP_KERNEL);
if (!pmu) {
pr_info("failed to allocate PMU device!\n");
return -ENOMEM;
@@ -1074,8 +1070,6 @@ int arm_pmu_device_probe(struct platform_device *pdev,
out_free:
pr_info("%s: failed to register PMU devices!\n",
of_node_full_name(node));
- kfree(pmu->irq_affinity);
- kfree(pmu);
return ret;
}
--
2.10.2
^ permalink raw reply related
* [PATCH v2 0/2] mark driver as non-removable
From: Alexander Stein @ 2016-12-21 15:03 UTC (permalink / raw)
To: linux-arm-kernel
Changes in v2;
* Instead of adding a remove function which is unused otherwise, mark the driver
as non-remoable
Using DEBUG_TEST_DRIVER_REMOVE every driver gets probed, removed and probed
again. This breaks drivers without removal function, e.g. arm perf
resulting in the following dump:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x6c/0x7c
sysfs: cannot create duplicate filename '/devices/armv7_cortex_a7'
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.9.0+ #212
Hardware name: Freescale LS1021A
Backtrace:
[<8020c044>] (dump_backtrace) from [<8020c2f0>] (show_stack+0x18/0x1c)
r7:00000009 r6:60000013 r5:80c1776c r4:00000000
[<8020c2d8>] (show_stack) from [<8046ead8>] (dump_stack+0x94/0xa8)
[<8046ea44>] (dump_stack) from [<8021ecd0>] (__warn+0xec/0x104)
r7:00000009 r6:8092efc8 r5:00000000 r4:bf04bd80
[<8021ebe4>] (__warn) from [<8021ed28>] (warn_slowpath_fmt+0x40/0x48)
r9:80a32848 r8:00000000 r7:00000000 r6:bf0ab780 r5:8091d590 r4:bf0df000
[<8021ecec>] (warn_slowpath_fmt) from [<8036d53c>] (sysfs_warn_dup+0x6c/0x7c)
r3:bf0df000 r2:8092ef94
[<8036d4d0>] (sysfs_warn_dup) from [<8036d628>] (sysfs_create_dir_ns+0x8c/0x9c)
r6:bf0ab780 r5:bf20ee08 r4:ffffffef
[<8036d59c>] (sysfs_create_dir_ns) from [<80471860>] (kobject_add_internal+0xa8/0x34c)
r6:bf0aa198 r5:00000000 r4:bf20ee08
[<804717b8>] (kobject_add_internal) from [<80471b54>] (kobject_add+0x50/0x94)
r7:00000000 r6:00000000 r5:00000000 r4:bf20ee08
[<80471b08>] (kobject_add) from [<80524590>] (device_add+0xe4/0x590)
r3:00000000 r2:00000000
r6:bf20ee00 r5:00000000 r4:bf20ee08
[<805244ac>] (device_add) from [<802a38a8>] (pmu_dev_alloc+0x88/0xd8)
r10:00000091 r9:80a32848 r8:00000000 r7:80a32840 r6:80c0ed3c r5:00000000
r4:bf1fe800
[<802a3820>] (pmu_dev_alloc) from [<80a0cd20>] (perf_event_sysfs_init+0x5c/0xb4)
r7:80a32840 r6:00000000 r5:bf1fe800 r4:80c0ede0
[<80a0ccc4>] (perf_event_sysfs_init) from [<80201778>] (do_one_initcall+0x48/0x178)
r6:80c45000 r5:80a0ccc4 r4:00000006
[<80201730>] (do_one_initcall) from [<80a00ecc>] (kernel_init_freeable+0x168/0x20c)
r8:80a00610 r7:80a32840 r6:80c45000 r5:80c45000 r4:00000006
[<80a00d64>] (kernel_init_freeable) from [<806febcc>] (kernel_init+0x10/0x11c)
r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:806febbc
r4:00000000
[<806febbc>] (kernel_init) from [<80208388>] (ret_from_fork+0x14/0x2c)
r5:806febbc r4:00000000
---[ end trace 9d251d389382804f ]---
This patchset marks the driver as explicitly non-remoavle preventing this error.
This disables bin/unbind for this driver as well.
Alexander Stein (2):
drivers/perf: arm_pmu: Use devm_ allocators
arm: perf: Mark as non-removable
arch/arm/kernel/perf_event_v7.c | 1 +
drivers/perf/arm_pmu.c | 14 ++++----------
2 files changed, 5 insertions(+), 10 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH 2/3] drivers/perf: arm_pmu: add arm_pmu_device_remove
From: Alexander Stein @ 2016-12-21 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221133854.GU3124@twins.programming.kicks-ass.net>
On Wednesday 21 December 2016 14:38:54, Peter Zijlstra wrote:
> On Wed, Dec 21, 2016 at 11:19:34AM +0100, Alexander Stein wrote:
> > Add ARM PMU removal function. This will be required by perf event drivers
> > when option DEBUG_TEST_DRIVER_REMOVE is enabled.
> >
> > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> > ---
> >
> > drivers/perf/arm_pmu.c | 14 ++++++++++++++
> > include/linux/perf/arm_pmu.h | 2 ++
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> > index a9bbdbf..b7ddc4c 100644
> > --- a/drivers/perf/arm_pmu.c
> > +++ b/drivers/perf/arm_pmu.c
> > @@ -1022,6 +1022,7 @@ int arm_pmu_device_probe(struct platform_device
> > *pdev,>
> > armpmu_init(pmu);
> >
> > pmu->plat_device = pdev;
> >
> > + platform_set_drvdata(pdev, pmu);
> >
> > if (node && (of_id = of_match_node(of_table, pdev->dev.of_node))) {
> >
> > init_fn = of_id->data;
> >
> > @@ -1073,6 +1074,19 @@ int arm_pmu_device_probe(struct platform_device
> > *pdev,>
> > return ret;
> >
> > }
> >
> > +int arm_pmu_device_remove(struct platform_device *pdev)
> > +{
> > + struct arm_pmu *pmu = platform_get_drvdata(pdev);
> > +
> > + __oprofile_cpu_pmu = NULL;
> > +
> > + perf_pmu_unregister(&pmu->pmu);
> > +
> > + cpu_pmu_destroy(pmu);
> > +
> > + return 0;
> > +}
>
> So normally, if there are events that use this pmu, we hold a reference
> on its module, which avoids removal from happening.
>
> How is that guarantee made by DEBUG_TEST_DRIVER_REMOVE ? Or will it
> simply kill everything even though there's active events for the PMU?
AFAICS you won't be able to hold any reference until this test remove is done.
This feature is implemented in really_probe(). If the driver is successfully
probed it will be removed and probed again.
But reading that part of the code I stumbled over suppress_bind_attrs which
would prevent this procedure. After some grepping I found commit 80c6397c3
("clk: oxnas: make it explicitly non-modular").
Essentially setting
> .suppress_bind_attrs = true
in the platform_driver.
IMHO this seems far better than to add some remove functions only for testing
a non-removable driver. I'll come up with a 2nd series, patch 1/3 is still
valid.
Best regards,
Alexander
^ permalink raw reply
* [PATCH v4 0/9] Implement clocksource for rockchip SoC using rockchip timer
From: Alexander Kochetkov @ 2016-12-21 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480436092-10728-1-git-send-email-al.kochet@gmail.com>
Hello Heiko, Daniel!
Are there any reasons why the patches [1][2] are not applied yet into kernel?
How can I help in applying patches?
Regards,
Alexander.
[1] http://lists.infradead.org/pipermail/linux-rockchip/2016-November/thread.html#13236
[PATCH v4 0/9] Implement clocksource for rockchip SoC using rockchip timer
[2] http://lists.infradead.org/pipermail/linux-rockchip/2016-December/013308.html
> 29 ????. 2016 ?., ? 19:14, Alexander Kochetkov <al.kochet@gmail.com> ???????(?):
>
> Hello,
>
> This patch series contain:
> - devicetree bindings clarification for rockchip timers
> - dts files fixes for rk3228-evb, rk3229-evb and rk3188
> - implementation of clocksource and sched clock for rockchip SoC
>
> The clock supplying the arm-global-timer on the rk3188 is coming from the
> the cpu clock itself and thus changes its rate everytime cpufreq adjusts
> the cpu frequency making this timer unsuitable as a stable clocksource.
>
> The rk3188, rk3288 and following socs share a separate timer block already
> handled by the rockchip-timer driver. Therefore adapt this driver to also
> be able to act as clocksource on rk3188.
>
> In order to test clocksource you can run following commands and check
> how much time it take in real. On rk3188 it take about ~45 seconds.
>
> cpufreq-set -f 1.6GHZ
> date; sleep 60; date
>
> rk3288 (and probably anything newer) is irrelevant to this patch,
> as it has the arch timer interface. This patch may be usefull
> for Cortex-A9/A5 based parts.
>
> Regards,
> Alexander.
>
> This is try 4. Please discard all v1, v2, v3 patches.
>
> Changes in v4:
> merged 7 and 8 from series 3
> merged 10, 11, 12, 13 from series 3
> fixed commit message
>
> Changes in v3:
> added patches:
> ARM: dts: rockchip: disable arm-global-timer for rk3188
> clocksource/drivers/rockchip_timer: Prevent ftrace recursion
>
> devicetree v1 patches:
> https://patchwork.ozlabs.org/patch/699019/
> https://patchwork.ozlabs.org/patch/699020/
>
> kernel v1 patches:
> https://patchwork.kernel.org/patch/9443975/
> https://patchwork.kernel.org/patch/9443971/
> https://patchwork.kernel.org/patch/9443959/
> https://patchwork.kernel.org/patch/9443963/
> https://patchwork.kernel.org/patch/9443979/
> https://patchwork.kernel.org/patch/9443989/
> https://patchwork.kernel.org/patch/9443987/
> https://patchwork.kernel.org/patch/9443977/
> https://patchwork.kernel.org/patch/9443991/
>
> Alexander Kochetkov (9):
> dt-bindings: clarify compatible property for rockchip timers
> ARM: dts: rockchip: update compatible property for rk3228 timer
> ARM: dts: rockchip: update compatible property for rk3229 timer
> ARM: dts: rockchip: add timer entries to rk3188 SoC
> ARM: dts: rockchip: disable arm-global-timer for rk3188
> clocksource/drivers/rockchip_timer: split bc_timer into rk_timer and
> rk_clock_event_device
> clocksource/drivers/rockchip_timer: low level routines take rk_timer
> as parameter
> clocksource/drivers/rockchip_timer: move TIMER_INT_UNMASK out of
> rk_timer_enable()
> clocksource/drivers/rockchip_timer: implement clocksource timer
>
> .../bindings/timer/rockchip,rk-timer.txt | 12 +-
> arch/arm/boot/dts/rk3188.dtsi | 17 ++
> arch/arm/boot/dts/rk3228-evb.dts | 4 +
> arch/arm/boot/dts/rk3229-evb.dts | 4 +
> drivers/clocksource/rockchip_timer.c | 207 +++++++++++++++-----
> 5 files changed, 190 insertions(+), 54 deletions(-)
>
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH v8 1/8] soc: samsung: add exynos chipid driver support
From: Andrzej Hajda @ 2016-12-21 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481375323-29724-2-git-send-email-pankaj.dubey@samsung.com>
On 10.12.2016 14:08, Pankaj Dubey wrote:
> Exynos SoCs have Chipid, for identification of product IDs and SoC revisions.
> This patch intends to provide initialization code for all these functionalities,
> at the same time it provides some sysfs entries for accessing these information
> to user-space.
>
> This driver uses existing binding for exynos-chipid.
>
> CC: Grant Likely <grant.likely@linaro.org>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> [m.szyprowski: for suggestion and code snippet of product_id_to_soc_id]
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/soc/samsung/Kconfig | 5 ++
> drivers/soc/samsung/Makefile | 1 +
> drivers/soc/samsung/exynos-chipid.c | 116 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 122 insertions(+)
> create mode 100644 drivers/soc/samsung/exynos-chipid.c
>
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index 2455339..f9ab858 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -14,4 +14,9 @@ config EXYNOS_PM_DOMAINS
> bool "Exynos PM domains" if COMPILE_TEST
> depends on PM_GENERIC_DOMAINS || COMPILE_TEST
>
> +config EXYNOS_CHIPID
> + bool "Exynos Chipid controller driver" if COMPILE_TEST
> + depends on (ARM && ARCH_EXYNOS) || ((ARM || ARM64) && COMPILE_TEST)
> + select SOC_BUS
> +
> endif
> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> index 3619f2e..2a8a85e 100644
> --- a/drivers/soc/samsung/Makefile
> +++ b/drivers/soc/samsung/Makefile
> @@ -1,3 +1,4 @@
> obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o exynos3250-pmu.o exynos4-pmu.o \
> exynos5250-pmu.o exynos5420-pmu.o
> obj-$(CONFIG_EXYNOS_PM_DOMAINS) += pm_domains.o
> +obj-$(CONFIG_EXYNOS_CHIPID) += exynos-chipid.o
> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> new file mode 100644
> index 0000000..cf0128b
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-chipid.c
> @@ -0,0 +1,116 @@
> +/*
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * EXYNOS - CHIP ID support
> + * Author: Pankaj Dubey <pankaj.dubey@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/sys_soc.h>
> +
> +#define EXYNOS_SUBREV_MASK (0xF << 4)
> +#define EXYNOS_MAINREV_MASK (0xF << 0)
> +#define EXYNOS_REV_MASK (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
> +
> +static const struct exynos_soc_id {
> + const char *name;
> + unsigned int id;
> + unsigned int mask;
> +} soc_ids[] = {
> + { "EXYNOS3250", 0xE3472000, 0xFFFFF000 },
> + { "EXYNOS4210", 0x43200000, 0xFFFE0000 },
> + { "EXYNOS4212", 0x43220000, 0xFFFE0000 },
> + { "EXYNOS4412", 0xE4412000, 0xFFFE0000 },
> + { "EXYNOS5250", 0x43520000, 0xFFFFF000 },
> + { "EXYNOS5260", 0xE5260000, 0xFFFFF000 },
> + { "EXYNOS5410", 0xE5410000, 0xFFFFF000 },
> + { "EXYNOS5420", 0xE5420000, 0xFFFFF000 },
> + { "EXYNOS5440", 0xE5440000, 0xFFFFF000 },
> + { "EXYNOS5800", 0xE5422000, 0xFFFFF000 },
> + { "EXYNOS7420", 0xE7420000, 0xFFFFF000 },
> + { "EXYNOS5433", 0xE5433000, 0xFFFFF000 },
I wonder why there are different masks in case of Exynos42*?
In specs I have access to mask is always 0xFFFFF000.
> +};
> +
> +static const char * __init product_id_to_soc_id(unsigned int product_id)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(soc_ids); i++)
> + if ((product_id & soc_ids[i].mask) == soc_ids[i].id)
> + return soc_ids[i].name;
> + return "UNKNOWN";
> +}
> +
> +static const struct of_device_id of_exynos_chipid_ids[] = {
> + {
> + .compatible = "samsung,exynos4210-chipid",
> + },
> + {},
> +};
> +
> +/**
> + * exynos_chipid_early_init: Early chipid initialization
> + */
> +int __init exynos_chipid_early_init(void)
> +{
> + struct soc_device_attribute *soc_dev_attr;
> + struct soc_device *soc_dev;
> + struct device_node *root;
> + struct device_node *np;
> + void __iomem *exynos_chipid_base;
> + const struct of_device_id *match;
> + u32 product_id;
> + u32 revision;
> +
> + np = of_find_matching_node_and_match(NULL,
> + of_exynos_chipid_ids, &match);
> + if (!np)
> + return -ENODEV;
> +
> + exynos_chipid_base = of_iomap(np, 0);
> +
> + if (!exynos_chipid_base)
> + return PTR_ERR(exynos_chipid_base);
> +
> + product_id = readl_relaxed(exynos_chipid_base);
> + revision = product_id & EXYNOS_REV_MASK;
> + iounmap(exynos_chipid_base);
> +
> + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> + if (!soc_dev_attr)
> + return -ENODEV;
> +
> + soc_dev_attr->family = "Samsung Exynos";
> +
> + root = of_find_node_by_path("/");
> + of_property_read_string(root, "model", &soc_dev_attr->machine);
> + of_node_put(root);
> +
> + soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%x", revision);
> + soc_dev_attr->soc_id = product_id_to_soc_id(product_id);
> +
> +
> + pr_info("Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
> + product_id_to_soc_id(product_id), revision);
I wonder if it wouldn't be good to log numeric value of whole PRO_ID
register, this way we will have also useful log for chips not know to
soc_ids array.
It will show also some missing bits: masked bits, package_information
and reserved bit. Btw. package_information can be used to distinguish
S5PC210 and S5PV310.
And small optimization, you can reuse soc_dev_attr->soc_id instead of
calling the same function again.
And finally all log could be moved after soc_device_register, this way
you can use:
struc device *dev = soc_device_to_device(soc_dev);
dev_info(dev, ...);
Regards
Andrzej
> +
> + soc_dev = soc_device_register(soc_dev_attr);
> + if (IS_ERR(soc_dev)) {
> + kfree(soc_dev_attr->revision);
> + kfree_const(soc_dev_attr->soc_id);
> + kfree(soc_dev_attr);
> + return PTR_ERR(soc_dev);
> + }
> +
> + return 0;
> +}
> +early_initcall(exynos_chipid_early_init);
^ permalink raw reply
* [PATCH 2/3] drivers/perf: arm_pmu: add arm_pmu_device_remove
From: Peter Zijlstra @ 2016-12-21 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221101935.17178-3-alexander.stein@systec-electronic.com>
On Wed, Dec 21, 2016 at 11:19:34AM +0100, Alexander Stein wrote:
> Add ARM PMU removal function. This will be required by perf event drivers
> when option DEBUG_TEST_DRIVER_REMOVE is enabled.
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
> drivers/perf/arm_pmu.c | 14 ++++++++++++++
> include/linux/perf/arm_pmu.h | 2 ++
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index a9bbdbf..b7ddc4c 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -1022,6 +1022,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
> armpmu_init(pmu);
>
> pmu->plat_device = pdev;
> + platform_set_drvdata(pdev, pmu);
>
> if (node && (of_id = of_match_node(of_table, pdev->dev.of_node))) {
> init_fn = of_id->data;
> @@ -1073,6 +1074,19 @@ int arm_pmu_device_probe(struct platform_device *pdev,
> return ret;
> }
>
> +int arm_pmu_device_remove(struct platform_device *pdev)
> +{
> + struct arm_pmu *pmu = platform_get_drvdata(pdev);
> +
> + __oprofile_cpu_pmu = NULL;
> +
> + perf_pmu_unregister(&pmu->pmu);
> +
> + cpu_pmu_destroy(pmu);
> +
> + return 0;
> +}
So normally, if there are events that use this pmu, we hold a reference
on its module, which avoids removal from happening.
How is that guarantee made by DEBUG_TEST_DRIVER_REMOVE ? Or will it
simply kill everything even though there's active events for the PMU?
^ permalink raw reply
* [v4, 1/3] ARM: dts: vf610-zii-dev-rev-b: Remove leftover PWM pingroup
From: Nikita Yushchenko @ 2016-12-21 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482131877-6097-1-git-send-email-andrew.smirnov@gmail.com>
> Remove pwm0grp since it is:
>
> a) Not referenced anywhere in the DTS file (unlike Tower board it
> is based on, this board does not use/expose FTM0)
>
> b) Configures PTB2 and PTB3 in a way that contradicts
> pinctrl-mdio-mux
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Tested-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
^ permalink raw reply
* [v4, 3/3] ARM: dts: vf610-zii-dev-rev-b: Remove 'fixed-link' from DSA ports
From: Uwe Kleine-König @ 2016-12-21 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482325125-15725-1-git-send-email-nikita.yoush@cogentembedded.com>
On Wed, Dec 21, 2016 at 03:58:45PM +0300, Nikita Yushchenko wrote:
> > Remove 'fixed-link' nodes from DSA ports since they are not needed (they
> > are not limiting link's speed and the ports will be configured to their
> > maximux speed as a default)
> >
> > Suggested-by: Andrew Lunn <andrew@lunn.ch>
> > Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>
> With this patch, ports connected to revB's second switch stop working.
This is probably because without a fixed-link node the phy-mode setting
isn't applied by the driver.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [RFC PATCH 1/7] PF driver modified to enable HW filter support, changes works in backward compatibility mode Enable required things in Makefile Enable LZ4 dependecy inside config file
From: Sunil Kovvuri @ 2016-12-21 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482310011-1862-2-git-send-email-satha.rao@caviumnetworks.com>
>
> #define NIC_MAX_RSS_HASH_BITS 8
> #define NIC_MAX_RSS_IDR_TBL_SIZE (1 << NIC_MAX_RSS_HASH_BITS)
> +#define NIC_TNS_RSS_IDR_TBL_SIZE 5
So you want to use only 5 queues per VF when TNS is enabled, is it ??
There are 4096 RSS indices in total, for each VF you can use max 32.
I guess you wanted to set no of hash bits to 5 instead of table size.
> #define RSS_HASH_KEY_SIZE 5 /* 320 bit key */
>
> struct nicvf_rss_info {
> @@ -255,74 +258,6 @@ struct nicvf_drv_stats {
> struct u64_stats_sync syncp;
> };
>
> -struct nicvf {
> - struct nicvf *pnicvf;
> - struct net_device *netdev;
> - struct pci_dev *pdev;
> - void __iomem *reg_base;
Didn't get why you moved this structure to the end of file.
Looks like an unnecessary modification.
> +static unsigned int num_vfs;
> +module_param(num_vfs, uint, 0644);
> +MODULE_PARM_DESC(num_vfs, "Non zero positive value, specifies number of VF's per physical port");
So what if driver is built-in instead of module, I can't use TNS is it ?
>
> +/* Set RBDR Backpressure (RBDR_BP) and CQ backpressure (CQ_BP) of vnic queues
> + * to 129 each
Why 129 ??
RBDR minimum size is 8K buffers, why you want to assert BP when still
~4K buffers
are available. Isn't 4K a huge number to start asserting backpressure ?
^ permalink raw reply
* [v4, 3/3] ARM: dts: vf610-zii-dev-rev-b: Remove 'fixed-link' from DSA ports
From: Nikita Yushchenko @ 2016-12-21 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482131877-6097-3-git-send-email-andrew.smirnov@gmail.com>
> Remove 'fixed-link' nodes from DSA ports since they are not needed (they
> are not limiting link's speed and the ports will be configured to their
> maximux speed as a default)
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
With this patch, ports connected to revB's second switch stop working.
Nikita
^ 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