On 05/31/2013 10:42 AM, David Miller wrote:
From: Cong Wang xiyou.wangc...@gmail.com
Date: Fri, 31 May 2013 11:23:11 +0800
On Fri, May 31, 2013 at 9:27 AM, Matthias Schiffer
mschif...@universe-factory.net wrote:
Since some refactoring in 5f5a011, ndisc_send_redirect called
Hi,
we've hit the following panic several times in the last days on some of
our servers running kernel 3.9.4. Is seems to be a regression in the 3.9
series, as we never hit it with 3.8.x or earlier.
Please let me know if there is anything more I can do to help fix this;
I probably won't have time
Since some refactoring in 5f5a011, ndisc_send_redirect called
ndisc_fill_redirect_hdr_option on the wrong skb, leading to data corruption or
in the worst case a panic when the skb_put failed.
Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
---
net/ipv6/ndisc.c | 2 +-
1 file
On 06/10/2015 07:20 AM, gre...@linuxfoundation.org wrote:
On Wed, Jun 10, 2015 at 05:00:03AM +, Lisa Du wrote:
-Original Message-
From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
Sent: 2015年6月10日 5:12
To: Lisa Du
Cc: linux-kernel@vger.kernel.org
Subject: Re:
On 05/05/2015 12:36 PM, Markus Stenberg wrote:
If there are only IPv6 source specific default routes present, the
host gets -ENETUNREACH on e.g. connect() because ip6_dst_lookup_tail
calls ip6_route_output first, and given source address any, it fails,
and ip6_route_get_saddr is never called.
On 06/22/2015 12:05 AM, Markus Stenberg wrote:
Prefsrc is essentially historic non IPv6 construct. IPv6 SAS is based on dst,
src, metric ordered lookup just like the routing is too ( lookup rfc, some
src specific routing drafts for details ).
Therefore I do not see a problem. If you want
Hi,
I've come across the issue that applications with detached threads
(using pthread_detach or a pthread_attr_t with
pthread_attr_setdetachstate) will segfault using musl-libc on MIPS as
soon as the detached thread exits. As far as I can tell, the underlying
issue is the following:
To clean up
On 06/22/2015 07:58 AM, Steven Barth wrote:
On 22.06.2015 00:35, Matthias Schiffer wrote:
Could you explain in detail what you mean with If you want specific SA,
add same route with higher metric and/or (more) specific src match.?
Routes aren't bound to specific addresses except via the src
Hi,
we're experiencing weird nondeterministic hangs during bootconsole/console
handover on some ath79 systems on OpenWrt. I've seen this issue myself on
kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other
reports ([1], [2]) kernel 4.1.x is affected as well, and other SoCs like
On 03/22/2016 12:08 AM, Greg KH wrote:
> On Tue, Mar 22, 2016 at 12:02:57AM +0100, Matthias Schiffer wrote:
>> Hi,
>> we're experiencing weird nondeterministic hangs during bootconsole/console
>> handover on some ath79 systems on OpenWrt. I've seen this issue myself on
>
On 03/22/2016 06:40 AM, Antony Pavlov wrote:
> On Tue, 22 Mar 2016 00:02:57 +0100
> Matthias Schiffer <mschif...@universe-factory.net> wrote:
>
>> Hi,
>> we're experiencing weird nondeterministic hangs during bootconsole/console
>> handover on some ath79 systems
>> My theory is the following:
>>
>> As soon as ttyS0 is detected and installed as the console, there are two
>> console drivers active on the serial port at the same time: early0 and
>> ttyS0. I suspect that the hang occurs when the primitive early0
>> implementation prom_putchar_ar71xx waits
On 03/22/2016 04:38 PM, Peter Hurley wrote:
> On 03/22/2016 06:07 AM, Matthias Schiffer wrote:
>> I've tried your patch and I can't reproduce the issue anymore with it; I
>> have no idea if this actually has to do something with the issue, or the
>> change of the code path j
>> autoconfig_16550a() is doing all kinds of weird checks to detect different
>> hardware by writing a lot of register values which are documented as
>> reserved in the AR7242 datasheet (there's a leaked version going around
>> that can be easily googled...), no idea if any of those are
patch will disable 8250 autoconfig for ath79
altogether (the serial controller is detected as a 16550A, which is not
fully compatible with the ath79 serial, and the autoconfig may lead to
undefined behavior on ath79.)
Cc: <sta...@vger.kernel.org>
Signed-off-by: Matthias Schiffer &
On 12/15/2015 07:48 PM, Brian Norris wrote:
> Spansion and Winbond have occasionally used the same manufacturer ID,
> and they don't support the same features. Particularly, writing SR=0
> seems to break read access for Spansion's s25fl064k. Unfortunately, we
> don't currently have a way to
On 03/26/2016 07:57 PM, Matthias Schiffer wrote:
> On 12/15/2015 07:48 PM, Brian Norris wrote:
>> Spansion and Winbond have occasionally used the same manufacturer ID,
>> and they don't support the same features. Particularly, writing SR=0
>> seems to break read access for
On 03/28/2016 10:56 PM, Brian Norris wrote:
> On Mon, Mar 28, 2016 at 12:52:51AM +0200, Matthias Schiffer wrote:
>> On 03/26/2016 07:57 PM, Matthias Schiffer wrote:
>>> On 12/15/2015 07:48 PM, Brian Norris wrote:
>>>> Spansion and Winbond have occasionally
On 05/23/2016 04:01 PM, Cyrille Pitchen wrote:
> Hi Matthias,
>
> Le 18/05/2016 15:32, Matthias Schiffer a écrit :
>> This patch has been tested in OpenWrt for a few months and seems to work
>> correctly.
>>
>> Signed-off-by: Felix Fietkau <n...@nbd.name&
This patch has been tested in OpenWrt for a few months and seems to work
correctly.
Signed-off-by: Felix Fietkau <n...@nbd.name>
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
drivers/mtd/spi-nor/spi-nor.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/dri
ion manufacturer ID. All tested Spansion flash chips showed the
same behaviour: without 32321e9 and edf891e, subsequent reads only returned
zeros (as reported by Felix Fietkau, leading to 67b9bcd), but with 32321e9
and edf891e, the chip continued to work correctly.
Cc: Felix Fietkau <n...@nbd.nam
On 03/14/2017 04:28 PM, Jiri Benc wrote:
> On Fri, 10 Mar 2017 23:39:44 +0100, Matthias Schiffer wrote:
>> @@ -233,17 +234,30 @@ static struct vxlan_dev *vxlan_vs_find_vni(struct
>> vxlan_sock *vs, __be32 vni)
>> vni = 0;
>>
>> hlist_for_each_
On 03/15/2017 04:22 PM, Jiri Benc wrote:
> On Wed, 15 Mar 2017 15:29:29 +0100, Matthias Schiffer wrote:
>> While ensuring that the destination address is link-local iff the source
>> address is would also be an option, it didn't seem too useful as the
>> destination addres
There is no good reason to keep the flags twice in vxlan_dev and
vxlan_config.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
v2: new patch
drivers/net/vxlan.c | 76 +--
include/net/vxlan.h | 1
set in vxlan_setup before. This caused VXLAN-GPE to use the same
default port as other VXLAN sockets instead of the intended IANA-assigned
4790.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
v2: new patch
drivers/net/vxlan.c | 202 +
are used for the
follow-up patches that actually make VXLAN over link-local IPv6 work.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
v2: was "vxlan: don't allow link-local IPv6 local/remote addresses without
interface" before. v2 does a lot more
Address families of source and destination addresses must match, and
changelink operations can't change the address family.
In addition, always use the VXLAN_F_IPV6 to check if a VXLAN device uses
IPv4 or IPv6.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
v2: new
to respect the ifindex when link-local IPv6
addresses are used, so using the same VNI on multiple interfaces can
actually work.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
v2: use VXLAN_F_IPV6_LINKLOCAL in vxlan_vs_find_vni; rebase.
drivers/net/vxlan.
over IPv6 link-local
work, and allow multiple VXLANs wit the same VNI and port, as long as
link-local addresses on different interfaces are used. As suggested, I now
store in the flags field if the VXLAN uses link-local addresses or not.
Matthias Schiffer (6):
vxlan: refactor verification
If VXLAN is run over link-local IPv6 addresses, it is necessary to store
the ifindex in the FDB entries. Otherwise, the used interface is undefined
and unicast communication will most likely fail.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
v2: use u32 instead of
On 04/14/2017 07:27 PM, Sergei Shtylyov wrote:
> On 04/14/2017 07:44 PM, Matthias Schiffer wrote:
>
>> * Multicast addresses are never valid as local address
>> * Link-local IPv6 unicast addresses may only be used as remote when the
>> local address is link-local as we
On 04/14/2017 07:36 PM, Stephen Hemminger wrote:
> On Fri, 14 Apr 2017 18:44:44 +0200
> Matthias Schiffer <mschif...@universe-factory.net> wrote:
>
>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>> index 07f89b037681..95a71546e8f2 100644
>> --- a/dri
On 04/14/2017 07:38 PM, Stephen Hemminger wrote:
> On Fri, 14 Apr 2017 18:44:46 +0200
> Matthias Schiffer <mschif...@universe-factory.net> wrote:
>
>> As link-local addresses are only valid for a single interface, we can allow
>> to use the same VNI for multiple
to respect the ifindex when link-local IPv6
addresses are used, so using the same VNI on multiple interfaces can
actually work.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
drivers/net/vxlan.c | 88 -
1 file chang
If VXLAN is run over link-local IPv6 addresses, it is necessary to store
the ifindex in the FDB entries. Otherwise, the used interface is undefined
and unicast communication will most likely fail.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
drivers/net/vxlan.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
drivers/net/vxlan.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index e375560cc74e..cc0ace73d02e 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/v
.
The final patch lifts the limitation of not allowing multiple VXLANs with
the same VNI and port, as long as link-local IPv6 addresses are used and
different interfaces are specified. Again, this brings VXLAN a bit closer
to VLANs feature-wise.
Matthias Schiffer (3):
vxlan: don't allow link-local
addresses), and
add messages for the remaining attributes.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
drivers/net/vxlan.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index fd0ff9
When refactoring the vxlan config validation, some kernel log messages were
removed. This brings them back using the new netlink_ext_ack support, and
adds some more in the recently added code handling link-local IPv6
addresses.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.
On 06/26/2017 03:33 PM, David Ahern wrote:
> On 6/26/17 2:43 AM, Matthias Schiffer wrote:
>> On 06/26/2017 06:08 AM, David Ahern wrote:
>>> On 6/25/17 10:04 PM, David Ahern wrote:
>>>> On 6/25/17 3:56 PM, Matthias Schiffer wrote:
>>>>> Add support for
Add support for extended error reporting.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
include/net/rtnetlink.h | 3 ++-
net/core/rtnetlink.c| 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
Same changes as http://patchwork.ozlabs.org/patch/780351/ , split into
separate patches for each rtnl_link_ops field as requested.
Matthias Schiffer (5):
net: add netlink_ext_ack argument to rtnl_link_ops.newlink
net: add netlink_ext_ack argument to rtnl_link_ops.changelink
net: add
Add support for extended error reporting.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 7 ---
drivers/net/bonding/bond_netlink.c | 7 ---
drivers/net/caif/caif_hsi.c | 3 ++-
drive
Add support for extended error reporting.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 3 ++-
drivers/net/bonding/bond_netlink.c | 3 ++-
drivers/net/caif/caif_hsi.c | 3 ++-
drivers/net/can
Add support for extended error reporting.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
drivers/net/bonding/bond_netlink.c | 3 ++-
include/net/rtnetlink.h| 3 ++-
net/bridge/br_netlink.c| 3 ++-
net/core/rtnetlink.c | 3 ++-
4
Add support for extended error reporting.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
drivers/net/bonding/bond_netlink.c | 3 ++-
drivers/net/can/dev.c | 3 ++-
drivers/net/dummy.c| 3 ++-
drivers/net/geneve.c | 3 ++-
d
On 06/26/2017 06:08 AM, David Ahern wrote:
> On 6/25/17 10:04 PM, David Ahern wrote:
>> On 6/25/17 3:56 PM, Matthias Schiffer wrote:
>>> Add support for extended error reporting.
>>>
>>> Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
&g
The following functions are extended with a netlink_ext_ack argument to
allow extended error reporting:
* validate
* newlink
* changelink
* slave_validate
* slave_changelink
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
Checkpatch is unhappy about the long
On 06/23/2017 10:52 AM, Jiri Benc wrote:
> This patchset looks good overall (would send my Acked-by for most of
> this but I'm late).
>
> On Mon, 19 Jun 2017 10:03:55 +0200, Matthias Schiffer wrote:
>> Log messages in these
>> functions are removed, as it is generally
On 06/23/2017 12:23 PM, Johannes Berg wrote:
> On Fri, 2017-06-23 at 12:13 +0200, Matthias Schiffer wrote:
>>
>> I was told the extended netlink error facilities were not ready yet,
>> has that changed since the last release?
>
> Yes, the facility is in the kernel
On 04/16/2017 05:15 PM, Matthias Schiffer wrote:
> On 04/14/2017 07:38 PM, Stephen Hemminger wrote:
>> On Fri, 14 Apr 2017 18:44:46 +0200
>> Matthias Schiffer <mschif...@universe-factory.net> wrote:
>>
>>> As link-local addresses are only valid for a singl
to respect the ifindex when link-local IPv6
addresses are used, so using the same VNI on multiple interfaces can
actually work.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
Notes:
v2: use VXLAN_F_IPV6_LINKLOCAL in vxlan_vs_find_vni; rebase
v3: rebase
drive
as well defined as for IPv6, and there doesn't seem to
be much interest in having the support, it's not implemented for now.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
Notes:
v2: use u32 instead of __u32
v3: rebase, add note about IPv4 to commit message
drive
Address families of source and destination addresses must match, and
changelink operations can't change the address family.
In addition, always use the VXLAN_F_IPV6 to check if a VXLAN device uses
IPv4 or IPv6.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
Notes:
are used for the
follow-up patches that actually make VXLAN over link-local IPv6 work.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
Notes:
v2: was "vxlan: don't allow link-local IPv6 local/remote addresses without
interface" before. v2 does a lot more
There is no good reason to keep the flags twice in vxlan_dev and
vxlan_config.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
Notes:
v2: new patch
v3: rebase
drivers/net/vxlan.c | 76 +--
include/net/v
(as it is very unusual
for errors in netlink requests to be printed to the kernel log.) The commit
message of patch 5 has been extended to add a note about IPv4.
Matthias Schiffer (6):
vxlan: refactor verification and application of configuration
vxlan: get rid of redundant vxlan_dev.flags
vxlan
fault port as other VXLAN sockets instead of the intended IANA-assigned
4790.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
Notes:
v2: new patch
v3: remove kernel log messages
drivers/net/vxlan.c | 208
The access to the wrong variable could lead to a NULL dereference and
possibly other invalid memory reads in vxlan newlink/changelink requests
with a IFLA_MTU attribute.
Fixes: a985343ba906 "vxlan: refactor verification and application of
configuration"
Signed-off-by: Matthias Schiff
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
drivers/net/wireless/ath/ath9k/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/Makefile
b/drivers/net/wireless/ath/ath9k/Makefile
index 36a40ffdce15..90e4a3
hardware.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
checkpatch.pl wants me to write a more meaningful description for
ATH10K_SPECTRAL, but I don't actually know enough about the spectral scan
feature to do so...
drivers/net/wireless/ath/ath10k/Kconfig
routers, where we'd rather like to avoid the code size and RAM usage of the
relay support.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
drivers/net/wireless/ath/ath9k/Kconfig | 14 ++
drivers/net/wireless/ath/ath9k/Makefile | 4 ++--
d
On 08/01/2018 06:52 PM, Greg Kroah-Hartman wrote:
> 4.14-stable review patch. If anyone has any objections, please let me know.
It seems this patch is still missing from the 4.4.y and 4.9.y branches.
Matthias
>
> --
>
> From: Theodore Ts'o
>
> commit
On 02/06/2018 09:44 PM, Jacek Anaszewski wrote:
> On 02/06/2018 03:02 AM, Sasha Levin wrote:
>> On Sun, Feb 04, 2018 at 06:17:36PM +0100, Pavel Machek wrote:
>>>
*** if brightness=0, led off
*** else apply brightness if next timer <--- timer is stop, and will
never
On 03/12/2018 04:28 PM, Greg KH wrote:
> On Mon, Mar 12, 2018 at 04:00:01PM +0100, Matthias Schiffer wrote:
>> On 02/06/2018 09:44 PM, Jacek Anaszewski wrote:
>>> On 02/06/2018 03:02 AM, Sasha Levin wrote:
>>>> On Sun, Feb 04, 2018 at 06:17:
,
as disabling all.accept_ra would preclude users from explicitly enabling
accept_ra on individual interfaces.
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
net/ipv6/Kconfig| 12
net/ipv6/addrconf.c | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
On 03/26/2018 06:51 PM, Steven Rostedt wrote:
> On Sat, 24 Mar 2018 17:26:38 +0100
> Matthias Schiffer <mschif...@universe-factory.net> wrote:
>
>> @@ -905,8 +898,20 @@ static void profile_graph_return(struct
>> ftrace_graph_ret *trace)
>>
>> rec
the above alternatives, I chose the present approach to fix the
issue.
Fixes: e330b3bcd831 ("tracing: Show sample std dev in function profiling")
Fixes: 52d85d763086 ("ftrace: Fix stddev calculation in function profiler")
Signed-off-by: Matthias Schiffer <mschif...@universe-f
before:
https://www.linux-mips.org/archives/linux-mips/2014-11/msg00295.html
Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>
---
Caveats: I've only tested this on 32bit; it would be great if someone with
MIPS64 hardware or a working emulator setup could give it a spin. M
On 03/24/2018 05:26 PM, Matthias Schiffer wrote:
> It is well-known that it is not possible to accurately calculate variances
> just by accumulating squared samples; in fact, such an approach can even
> result in negative numbers. An earlier attempt to fix the calculation
> referred
On 03/24/2018 11:03 PM, Matthias Schiffer wrote:
> On 03/24/2018 05:26 PM, Matthias Schiffer wrote:
>> It is well-known that it is not possible to accurately calculate variances
>> just by accumulating squared samples; in fact, such an approach can even
>> result in negativ
Hi,
I'm currently trying to debug a performance bottleneck on low-end ath79
hardware running OpenWrt/LEDE, but it seems that ftrace is not working
correctly on these systems. I have tried this with recent 4.4.y and 4.9.y
with similar results; unfortunately, switching to a newer kernel is not
On 05/31/2013 10:42 AM, David Miller wrote:
> From: Cong Wang
> Date: Fri, 31 May 2013 11:23:11 +0800
>
>> On Fri, May 31, 2013 at 9:27 AM, Matthias Schiffer
>> wrote:
>>> Since some refactoring in 5f5a011, ndisc_send_redirect called
>>> ndisc_fill_redire
Hi,
we've hit the following panic several times in the last days on some of
our servers running kernel 3.9.4. Is seems to be a regression in the 3.9
series, as we never hit it with 3.8.x or earlier.
Please let me know if there is anything more I can do to help fix this;
I probably won't have time
Since some refactoring in 5f5a011, ndisc_send_redirect called
ndisc_fill_redirect_hdr_option on the wrong skb, leading to data corruption or
in the worst case a panic when the skb_put failed.
Signed-off-by: Matthias Schiffer
---
net/ipv6/ndisc.c | 2 +-
1 file changed, 1 insertion(+), 1
On 03/24/2018 05:26 PM, Matthias Schiffer wrote:
> It is well-known that it is not possible to accurately calculate variances
> just by accumulating squared samples; in fact, such an approach can even
> result in negative numbers. An earlier attempt to fix the calculation
> referred
On 03/24/2018 11:03 PM, Matthias Schiffer wrote:
> On 03/24/2018 05:26 PM, Matthias Schiffer wrote:
>> It is well-known that it is not possible to accurately calculate variances
>> just by accumulating squared samples; in fact, such an approach can even
>> result in negativ
On 03/26/2018 06:51 PM, Steven Rostedt wrote:
> On Sat, 24 Mar 2018 17:26:38 +0100
> Matthias Schiffer wrote:
>
>> @@ -905,8 +898,20 @@ static void profile_graph_return(struct
>> ftrace_graph_ret *trace)
>>
>> rec = ftrace_find_profiled_func(st
On 02/06/2018 09:44 PM, Jacek Anaszewski wrote:
> On 02/06/2018 03:02 AM, Sasha Levin wrote:
>> On Sun, Feb 04, 2018 at 06:17:36PM +0100, Pavel Machek wrote:
>>>
*** if brightness=0, led off
*** else apply brightness if next timer <--- timer is stop, and will
never
On 03/12/2018 04:28 PM, Greg KH wrote:
> On Mon, Mar 12, 2018 at 04:00:01PM +0100, Matthias Schiffer wrote:
>> On 02/06/2018 09:44 PM, Jacek Anaszewski wrote:
>>> On 02/06/2018 03:02 AM, Sasha Levin wrote:
>>>> On Sun, Feb 04, 2018 at 06:17:
Hi,
I'm currently trying to debug a performance bottleneck on low-end ath79
hardware running OpenWrt/LEDE, but it seems that ftrace is not working
correctly on these systems. I have tried this with recent 4.4.y and 4.9.y
with similar results; unfortunately, switching to a newer kernel is not
the above alternatives, I chose the present approach to fix the
issue.
Fixes: e330b3bcd831 ("tracing: Show sample std dev in function profiling")
Fixes: 52d85d763086 ("ftrace: Fix stddev calculation in function profiler")
Signed-off-by: Matthias Schiffer
---
kernel
before:
https://www.linux-mips.org/archives/linux-mips/2014-11/msg00295.html
Signed-off-by: Matthias Schiffer
---
Caveats: I've only tested this on 32bit; it would be great if someone with
MIPS64 hardware or a working emulator setup could give it a spin. My test
device runs on kernel 4.9.y, but I
routers, where we'd rather like to avoid the code size and RAM usage of the
relay support.
Signed-off-by: Matthias Schiffer
---
drivers/net/wireless/ath/ath9k/Kconfig | 14 ++
drivers/net/wireless/ath/ath9k/Makefile | 4 ++--
drivers/net/wireless/ath/ath9k/common
Signed-off-by: Matthias Schiffer
---
drivers/net/wireless/ath/ath9k/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/Makefile
b/drivers/net/wireless/ath/ath9k/Makefile
index 36a40ffdce15..90e4a341076c 100644
--- a/drivers/net/wireless
hardware.
Signed-off-by: Matthias Schiffer
---
checkpatch.pl wants me to write a more meaningful description for
ATH10K_SPECTRAL, but I don't actually know enough about the spectral scan
feature to do so...
drivers/net/wireless/ath/ath10k/Kconfig| 9 -
drivers/net/wireless/ath
,
as disabling all.accept_ra would preclude users from explicitly enabling
accept_ra on individual interfaces.
Signed-off-by: Matthias Schiffer
---
net/ipv6/Kconfig| 12
net/ipv6/addrconf.c | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/Kconfig b/net
On 06/26/2017 03:33 PM, David Ahern wrote:
> On 6/26/17 2:43 AM, Matthias Schiffer wrote:
>> On 06/26/2017 06:08 AM, David Ahern wrote:
>>> On 6/25/17 10:04 PM, David Ahern wrote:
>>>> On 6/25/17 3:56 PM, Matthias Schiffer wrote:
>>>>> Add support for
The access to the wrong variable could lead to a NULL dereference and
possibly other invalid memory reads in vxlan newlink/changelink requests
with a IFLA_MTU attribute.
Fixes: a985343ba906 "vxlan: refactor verification and application of
configuration"
Signed-off-by: Matthia
addresses), and
add messages for the remaining attributes.
Signed-off-by: Matthias Schiffer
---
drivers/net/vxlan.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index fd0ff97e3d81..01957e39f2cd 100644
When refactoring the vxlan config validation, some kernel log messages were
removed. This brings them back using the new netlink_ext_ack support, and
adds some more in the recently added code handling link-local IPv6
addresses.
Signed-off-by: Matthias Schiffer
---
drivers/net/vxlan.c | 43
driver (which completely broke probing, as the CPU port
index was always failing the num_ports check).
Fixes: af199a1a9cb0 ("net: dsa: microchip: set the correct number of
ports")
Signed-off-by: Matthias Schiffer
---
drivers/net/dsa/microchip/ksz8795.c | 2 +-
1 file changed, 1 inser
On Wed, 2020-08-26 at 07:59 -0300, Fabio Estevam wrote:
> Hi Matthias,
>
> On Wed, Aug 26, 2020 at 7:32 AM Matthias Schiffer
> wrote:
>
> > But the previous platform data that was removed in 8cdcd8aeee281
> > ("spi:
> > imx/fsl-lpspi: Convert to G
re the CPU nodes are referenced, e.g. a cooling
map).
Signed-off-by: Matthias Schiffer
---
drivers/of/base.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ea44fea99813..d547e9deced1 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -79
On Wed, 2020-08-26 at 10:01 -0300, Fabio Estevam wrote:
> On Wed, Aug 26, 2020 at 8:54 AM Matthias Schiffer
> wrote:
>
> > Before 8cdcd8aeee281, num_chipselect was set to 3 for spi0 and to 1
> > for
> > spi1 in arch/arm/mach-imx/mach-mx31lite.c. My understanding is
On Wed, 2020-08-26 at 08:01 -0500, Frank Rowand wrote:
> On 2020-08-26 07:02, Matthias Schiffer wrote:
> > Allow disabling CPU nodes using status = "disabled".
> >
> > This allows a bootloader to change the number of available CPUs
> > (for
> > example
On Wed, 2020-08-26 at 13:26 -0600, Rob Herring wrote:
> On Wed, Aug 26, 2020 at 8:47 AM Frank Rowand
> wrote:
> >
> > Hi Rob,
> >
> > On 2020-08-26 08:54, Matthias Schiffer wrote:
> > > On Wed, 2020-08-26 at 08:01 -0500, Frank Rowand wrote:
> > >
On Wed, 2020-08-26 at 10:49 -0300, Fabio Estevam wrote:
> On Wed, Aug 26, 2020 at 10:13 AM Matthias Schiffer
> wrote:
>
> > Using GPIOs for chipselect would require different pinmuxing. Also,
> > why
> > use GPIOs, when the SPI controller has this built in
On Thu, 2020-08-27 at 09:10 +0200, Matthias Schiffer wrote:
> On Wed, 2020-08-26 at 13:26 -0600, Rob Herring wrote:
> > On Wed, Aug 26, 2020 at 8:47 AM Frank Rowand <
> > frowand.l...@gmail.com>
> > wrote:
> > >
> > > Hi Rob,
> > >
>
As for I2C and SPI, it now is possible to reserve a fixed index for
mmc/mmcblk devices.
Signed-off-by: Matthias Schiffer
---
v4: moved alias documentation from example to description
v3: new patch
Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 4
1 file changed, 4
1 - 100 of 276 matches
Mail list logo
