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 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
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 5012284700775a4e6e3fbe7
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 apply
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:36PM +0100, Pavel Machek
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
easily
rs.
Ruling out 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 Schiff
orted 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.
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 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 bo
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
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 af
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 calle
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 w
't have to
extend it to store both a signed value and an error code. Always getting
an up-to-date value may be desirable anyways, as it avoids inconsistent
current and power readings when switching between charging and
discharging.
Signed-off-by: Matthias Schiffer
---
drivers/power/supply/bq
device known to Linux
We can solve both issues by deriving the status from the current instead
of the flags field. The flags are now only used to distinguish "full"
from "not charging", and to determine the sign of the current on
BQ27XXX_O_ZERO devices.
Signed-off-by:
o I assume only the BQ27XXX_O_ZERO code path was incorrect.
Revert the behaviour for newer ICs.
Fixes: cd060b4d0868 "power: supply: bq27xxx: fix polarity of current_now"
Signed-off-by: Matthias Schiffer
---
@Andreas Kemnade: It would be great to get a confirmation that the
Openmoko ba
On Tue, 2021-02-23 at 15:11 +0100, Matthias Schiffer wrote:
> On all newer bq27xxx ICs, the AveragePower register contains a signed
> value; in addition to handling the raw value as unsigned, the driver
> code also didn't convert it to µW as expected.
>
> At least for the BQ2
Based-on-patch-by: Sascha Hauer
Link: https://lkml.org/lkml/2020/8/5/194
Signed-off-by: Matthias Schiffer
---
v2: fix missing symbols for modular mmcblock
drivers/mmc/core/block.c | 13 +++--
drivers/mmc/core/core.c | 40
drivers/mmc/core/core.h
The PIXCLK needs to be enabled in SCFG before accessing the DCU on LS1021A,
or the access will hang.
Signed-off-by: Matthias Schiffer
---
drivers/gpu/drm/fsl-dcu/Kconfig | 1 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 25 +++
drivers/gpu/drm/fsl-dcu
Based-on-patch-by: Sascha Hauer
Signed-off-by: Matthias Schiffer
Link: https://lkml.org/lkml/2020/8/5/194
---
drivers/mmc/core/block.c | 13 +++--
drivers/mmc/core/core.c | 38 ++
drivers/mmc/core/core.h | 3 +++
drivers/mmc/core/host.c
From: Max Merchel
"TQ-Systems" is written with a dash, as can be seen on
https://www.tq-group.com/en/imprint/
Signed-off-by: Max Merchel
Signed-off-by: Matthias Schiffer
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletio
All future TQMx86 SoMs will use a 24MHz LPC clock, so we can use that as
a default instead of listing each new module individually.
Signed-off-by: Matthias Schiffer
---
drivers/mfd/tqmx86.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/tqmx86.c b
The driver was registering IRQ 0 when no IRQ was set. This leads to
warnings with newer kernels.
Clear the resource flags, so no resource is registered at all in this
case.
Signed-off-by: Matthias Schiffer
---
drivers/mfd/tqmx86.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers
This fixes a bug in the IRQ setup of the tqmx86 MFD / GPIO drivers and
adds support for our upcoming Elkhart Lake module TQMxE40M (as well as
future SoMs).
As patch 2 depends on patch 1, it would make sense to push the whole
series through the same tree.
Matthias Schiffer (3):
gpio: tqmx86
The tqmx86 MFD driver was passing IRQ 0 for "no IRQ" in the past. This
causes warnings with newer kernels.
Prepare the gpio-tqmx86 driver for the fixed MFD driver by handling a
missing IRQ properly.
Signed-off-by: Matthias Schiffer
---
drivers/gpio/gpio-tqmx86.c | 6 +++---
1 file
On Wed, 2021-03-31 at 15:29 +0300, Andy Shevchenko wrote:
> On Wed, Mar 31, 2021 at 2:37 PM Matthias Schiffer
> wrote:
> >
> > The tqmx86 MFD driver was passing IRQ 0 for "no IRQ" in the past. This
> > causes warnings with newer kernels.
> >
> > Pr
On Wed, 2021-03-31 at 15:35 +0300, Andy Shevchenko wrote:
> On Wed, Mar 31, 2021 at 2:39 PM Matthias Schiffer
> wrote:
> >
> > The driver was registering IRQ 0 when no IRQ was set. This leads to
> > warnings with newer kernels.
> >
> > Clear the resource fl
On Wed, 2021-03-31 at 15:37 +0300, Andy Shevchenko wrote:
> On Wed, Mar 31, 2021 at 2:38 PM Matthias Schiffer
> wrote:
> >
> > All future TQMx86 SoMs will use a 24MHz LPC clock, so we can use that as
> > a default instead of listing each new module individually.
>
On Wed, 2021-03-31 at 15:39 +0300, Andy Shevchenko wrote:
> On Wed, Mar 31, 2021 at 3:37 PM Matthias Schiffer
> wrote:
> > On Wed, 2021-03-31 at 15:29 +0300, Andy Shevchenko wrote:
> > > On Wed, Mar 31, 2021 at 2:37 PM Matthias Schiffer
> > > wrote:
&
o I assume only the BQ27XXX_O_ZERO code path was incorrect.
Revert the behaviour for newer ICs.
Fixes: cd060b4d0868 "power: supply: bq27xxx: fix polarity of current_now"
Signed-off-by: Matthias Schiffer
---
v2: no changes
drivers/power/supply/bq27xxx_battery.c | 2 +-
1 file c
device known to Linux
We can solve both issues by deriving the status from the current instead
of the flags field. The flags are now only used to distinguish "full"
from "not charging", and to determine the sign of the current on
BQ27XXX_O_ZERO devices.
Signed-o
't have to
extend it to store both a signed value and an error code. Always getting
an up-to-date value may be desirable anyways, as it avoids inconsistent
current and power readings when switching between charging and
discharging.
Signed-off-by: Matthias Schiffer
---
v2: fixed units in
e759cda51b ("l2tp: use standard API for warning log messages")
Signed-off-by: Matthias Schiffer
---
v2:
- Add counter for invalid packets
- Reduce loglevel of more messages that can be abused for log spam
include/uapi/linux/l2tp.h | 1 +
net/l2tp/l
On Thu, 2021-04-01 at 09:04 +0100, Lee Jones wrote:
> On Wed, 31 Mar 2021, Andy Shevchenko wrote:
>
> > On Wed, Mar 31, 2021 at 4:33 PM Matthias Schiffer
> > wrote:
> > > On Wed, 2021-03-31 at 15:37 +0300, Andy Shevchenko wrote:
> > > > On Wed, Ma
2TP version are checked
before the T flag.
Reduce all warnings debug level when packets are passed to userspace.
Fixes: 5ee759cda51b ("l2tp: use standard API for warning log messages")
Signed-off-by: Matthias Schiffer
---
I'm unsure what to do about the pr_warn_ratelimited() i
Hi Tom,
On 2/19/21 9:12 PM, Tom Parkin wrote:
Hi Matthias,
Thanks for your patch!
On Fri, Feb 19, 2021 at 20:06:15 +0100, Matthias Schiffer wrote:
Before commit 5ee759cda51b ("l2tp: use standard API for warning log
messages"), it was possible for userspace applications to use
On 2/22/21 12:49 PM, Tom Parkin wrote:
On Sat, Feb 20, 2021 at 10:56:33 +0100, Matthias Schiffer wrote:
On 2/19/21 9:12 PM, Tom Parkin wrote:
On Fri, Feb 19, 2021 at 20:06:15 +0100, Matthias Schiffer wrote:
Before commit 5ee759cda51b ("l2tp: use standard API for warning log
messages&
On 2/23/21 10:47 AM, Tom Parkin wrote:
On Mon, Feb 22, 2021 at 14:31:38 -0800, Jakub Kicinski wrote:
On Mon, 22 Feb 2021 17:40:16 +0100 Matthias Schiffer wrote:
This will not be sufficient for my usecase: To stay compatible with older
versions of fastd, I can't set the T flag in the
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
>> Signed-off-by
Spansion 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
Signed-of
This patch has been tested in OpenWrt for a few months and seems to work
correctly.
Signed-off-by: Felix Fietkau
Signed-off-by: Matthias Schiffer
---
drivers/mtd/spi-nor/spi-nor.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
On Thu, 2019-06-06 at 17:09 +0200, Jessica Yu wrote:
> +++ Matthias Schiffer [03/06/19 12:57 +0200]:
> > Some archs like ARM store unwind information for .exit.text in
> > sections
> > with unusual names. As this unwind information refers to
> > .exit.text, it
efer to the .exit.text section:
imx_sdma: section 16 reloc 0 sym '': relocation 42 out of range
(0x7f015260 -> 0xc0f5a5e8)
where 0x7F00 is the module load area and 0xC000 is the vmalloc
area. Relocation 42 refers to R_ARM_PREL31, which is limited to signed
31bit offsets.
Signed-of
.
Signed-off-by: Matthias Schiffer
---
v2: Use __weak function as suggested by Jessica
include/linux/moduleloader.h | 5 +
kernel/module.c | 7 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
index
.IA_64.unwind.exit.text and .IA_64.unwind_info.exit.text appear in the ld
script - but I don't know much about that arch.
Also, I'm not sure if this is stable-worthy - just enabling
CONFIG_MODULE_UNLOAD should be a viable workaround on affected kernels.
v2: Use __weak function as suggest
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 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_
laces.
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
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
---
drivers/net/vxlan.c | 88 -
1 file changed, 60 insertions(+), 28 deletions
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
---
drivers/net/vxlan.c | 20 +++-
1 file changed
Signed-off-by: Matthias Schiffer
---
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/vxlan.c
@@ -2922,6 +2922,18 @@ static int
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 differe
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 acces
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 used the
On 03/22/2016 06:40 AM, Antony Pavlov wrote:
> On Tue, 22 Mar 2016 00:02:57 +0100
> Matthias Schiffer wrote:
>
>> Hi,
>> we're experiencing weird nondeterministic hangs during bootconsole/console
>> handover on some ath79 systems on OpenWrt. I've seen t
>> 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 inde
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 c
>> 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 problematic
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:
Signed-off-by: Matthias Schiffer
---
arch/mips/ath79/early_printk.c | 6
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
Q
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
From: Michael Krummsdorf
Set SPI_NOR_4B_OPCODES, as the flash supports 4-byte opcodes.
Signed-off-by: Michael Krummsdorf
Signed-off-by: Matthias Schiffer
---
drivers/mtd/spi-nor/micron-st.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/micron-st.c
From: Michael Krummsdorf
This allows to clock the cores with 1 GHz, 500 MHz and 250 MHz.
Signed-off-by: Michael Krummsdorf
Signed-off-by: Matthias Schiffer
---
drivers/clk/clk-qoriq.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-qoriq.c b
From: Michael Krummsdorf
Add support for the CDTech Electronics displays S070PWS19HP-FC21
(7.0" WSVGA) and S070SWV29HG-DC44 (7.0" WVGA) to panel-simple.
Signed-off-by: Michael Krummsdorf
Signed-off-by: Matthias Schiffer
---
drivers/gpu/drm/panel/panel-sim
Add the Tianma Micro-electronics TM070JVHG33 7.0" WXGA display to the
panel-simple compatible list.
Signed-off-by: Matthias Schiffer
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bin
From: Max Merchel
Add support for the Tianma Micro-electronics TM070JVHG33 7.0" WXGA display
to panel-simple.
Signed-off-by: Max Merchel
Signed-off-by: Matthias Schiffer
---
drivers/gpu/drm/panel/panel-simple.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/driver
From: Matthias Schiffer
This adds a few panels TQ-Systems uses with various starterkit
mainboards. Device trees actually using these panels will be added with
a later submission.
Matthias Schiffer (2):
dt-bindings: display: simple: add CDTech S070PWS19HP-FC21 and
S070SWV29HG-DC44
dt
Add the CDTech Electronics displays S070PWS19HP-FC21 (7.0" WSVGA) and
S070SWV29HG-DC44 (7.0" WVGA) to the panel-simple compatible list.
Signed-off-by: Matthias Schiffer
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 4
1 file changed, 4 insertions(+)
di
Hello all,
there have been numerous attempts to make the numbering of mmcblk
devices consistent, mostly by using aliases from the DTS ([1], [2],
[3]), but all have been (rightfully) rejected. Unless I have overlooked
a more recent development, no attempts for a different solution were
made.
As fa
On Wed, 2020-06-10 at 16:59 +0200, Sam Ravnborg wrote:
> Hi Matthias.
>
> Thanks, a few details you need to fix. See below.
>
> Sam
>
> On Wed, Jun 10, 2020 at 02:01:30PM +0200, Matthias Schiffer wrote:
> > From: Michael Krummsdorf
> >
> > Add supp
On Wed, 2020-06-10 at 16:52 +0200, Ulf Hansson wrote:
> On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer
> wrote:
> >
> > Hello all,
> >
> > there have been numerous attempts to make the numbering of mmcblk
> > devices consistent, mostly by using aliases from
0, 2020 at 11:51 AM Ulf Hansson
> wrote:
> >
> > On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer
> > wrote:
> > >
> > > Hello all,
> > >
> > > there have been numerous attempts to make the numbering of mmcblk
> > > devices cons
Add the CDTech Electronics displays S070PWS19HP-FC21 (7.0" WSVGA) and
S070SWV29HG-DC44 (7.0" WVGA) to the panel-simple compatible list.
Signed-off-by: Matthias Schiffer
---
v2: no changes
.../devicetree/bindings/display/panel/panel-simple.yaml | 4
1 file changed, 4
From: Michael Krummsdorf
Add support for the CDTech Electronics displays S070PWS19HP-FC21
(7.0" WSVGA) and S070SWV29HG-DC44 (7.0" WVGA) to panel-simple.
Signed-off-by: Michael Krummsdorf
Signed-off-by: Matthias Schiffer
---
v2:
- removed vrefresh
- added connector_type
drive
Add the Tianma Micro-electronics TM070JVHG33 7.0" WXGA display to the
panel-simple compatible list.
Signed-off-by: Matthias Schiffer
---
v2: no changes
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Document
From: Max Merchel
Add support for the Tianma Micro-electronics TM070JVHG33 7.0" WXGA display
to panel-simple.
Signed-off-by: Max Merchel
Signed-off-by: Matthias Schiffer
---
v2:
- added connector_type
- fixed bus_format
drivers/gpu/drm/panel/panel-simple.c | 15 +++
1
On Thu, 2020-06-11 at 14:42 +0200, Matthias Schiffer wrote:
> Add the CDTech Electronics displays S070PWS19HP-FC21 (7.0" WSVGA) and
> S070SWV29HG-DC44 (7.0" WVGA) to the panel-simple compatible list.
>
> Signed-off-by: Matthias Schiffer
> ---
>
> v2: no change
Add the CDTech Electronics displays S070PWS19HP-FC21 (7.0" WSVGA) and
S070SWV29HG-DC44 (7.0" WVGA) to the panel-simple compatible list.
Signed-off-by: Matthias Schiffer
---
v2: no changes
.../devicetree/bindings/display/panel/panel-simple.yaml | 4
1 file changed, 4
From: Matthias Schiffer
This adds a few panels TQ-Systems uses with various starterkit
mainboards. Device trees actually using these panels will be added with
a later submission.
Matthias Schiffer (2):
dt-bindings: display: simple: add CDTech S070PWS19HP-FC21 and
S070SWV29HG-DC44
dt
From: Max Merchel
Add support for the Tianma Micro-electronics TM070JVHG33 7.0" WXGA display
to panel-simple.
Signed-off-by: Max Merchel
Signed-off-by: Matthias Schiffer
---
v2:
- added connector_type
- fixed bus_format
drivers/gpu/drm/panel/panel-simple.c | 15 +++
1
Add the Tianma Micro-electronics TM070JVHG33 7.0" WXGA display to the
panel-simple compatible list.
Signed-off-by: Matthias Schiffer
---
v2: no changes
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Document
From: Michael Krummsdorf
Add support for the CDTech Electronics displays S070PWS19HP-FC21
(7.0" WSVGA) and S070SWV29HG-DC44 (7.0" WVGA) to panel-simple.
Signed-off-by: Michael Krummsdorf
Signed-off-by: Matthias Schiffer
---
v2:
- removed vrefresh
- added connector_type
drive
On Tue, 2020-08-25 at 11:39 +0200, Matthias Schiffer wrote:
> On Tue, 2020-08-25 at 11:14 +0200, Ulf Hansson wrote:
> > On Thu, 20 Aug 2020 at 09:59, Matthias Schiffer
> > wrote:
> > > +
> > > +static void __init mmc_of_reserve_idx(void)
> > > +{
> &
On Tue, 2020-08-25 at 11:39 +0200, Matthias Schiffer wrote:
> On Tue, 2020-08-25 at 11:14 +0200, Ulf Hansson wrote:
> > On Thu, 20 Aug 2020 at 09:59, Matthias Schiffer
> > wrote:
> > > --- a/drivers/mmc/core/host.c
> > > +++ b/drivers/mmc/core/host.c
> >
On Tue, 2020-08-25 at 14:27 +0200, Ulf Hansson wrote:
> On Tue, 25 Aug 2020 at 14:00, Matthias Schiffer
> wrote:
> >
> > On Tue, 2020-08-25 at 11:39 +0200, Matthias Schiffer wrote:
> > > On Tue, 2020-08-25 at 11:14 +0200, Ulf Hansson wrote:
> > > > On Thu,
x-mmc/msg26588.html .
Based-on-patch-by: Sascha Hauer
Link: https://lkml.org/lkml/2020/8/5/194
Signed-off-by: Matthias Schiffer
---
v3:
- remove unneeded mmcblock changes
- remove most helper functions to simplify code
- extended commit message
v2:
- fix missing symbols for modular mmcblock
dr
As for I2C and SPI, it now is possible to reserve a fixed index for
mmc/mmcblk devices.
Signed-off-by: Matthias Schiffer
---
v3: new patch
Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings
On Tue, 2020-08-25 at 11:24 -0300, Fabio Estevam wrote:
> Hi Matthias,
>
> On Tue, Aug 25, 2020 at 4:22 AM Matthias Schiffer
> wrote:
>
> > Hmm, unless I'm overlooking something, this is not going to work:
> >
> > - spi_get_gpio_descs() set
On Tue, 2020-08-25 at 14:16 -0300, Fabio Estevam wrote:
> On Tue, Aug 25, 2020 at 11:40 AM Matthias Schiffer
> wrote:
>
> > Makes sense. Does the following logic sound correct?
> >
> > - If num-cs is set, use that (and add it to the docs)
>
> I would not add nu
On Wed, 2020-08-26 at 12:32 +0200, Matthias Schiffer wrote:
> On Tue, 2020-08-25 at 14:16 -0300, Fabio Estevam wrote:
> > On Tue, Aug 25, 2020 at 11:40 AM Matthias Schiffer
> > wrote:
> >
> > > Makes sense. Does the following logic sound correct?
> > >
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 GPIO desc
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:
> > >
issue is trivially
reproducible by any RX without DMA that doesn't fill the FIFO up to the
configured level.
Signed-off-by: Matthias Schiffer
---
drivers/tty/serial/imx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 6b
1 - 100 of 204 matches
Mail list logo
