Manfred Schlaegl | Leitung Entwicklung Linz
GINZINGER ELECTRONIC SYSTEMS GMBH
Tel.: +43 7723 5422 153
Mobil: +43 676 841 208 253
Mail: manfred.schla...@ginzinger.com
Web: www.ginzinger.com
On 04.01.19 16:23, Marc Kleine-Budde wrote:
> On 12/19/18 7:39 PM, Manfred Schlaegl wr
riv->echo_skb[idx]. It is therefore kept NULL.
(As additional argument for revert: The order of check and usage of idx
was changed. idx is used to access an array element before checking it's
boundaries)
Signed-off-by: Manfred Schlaegl
---
drivers/net/can/dev.c | 27 +---
rmance.
To solve this, we simply remove the double-check, which is a paranoia
check anyways.
The modification was intensively tested on i.MX6 with linux-4.1, Winbond
W29N04GV and Micron MT29F4G08ABADAH4.
Signed-off-by: Manfred Schlaegl <manfred.schla...@ginzinger.com>
---
drivers/mtd/nand/
rmance.
To solve this, we simply remove the double-check, which is a paranoia
check anyways.
The modification was intensively tested on i.MX6 with linux-4.1, Winbond
W29N04GV and Micron MT29F4G08ABADAH4.
Signed-off-by: Manfred Schlaegl
---
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c | 9 +
1 f
t
>> discarded because of bad power saving behavior.
>>
>> This patch saves the reset dt properties on probe and does a reset on every
>> open after clocks where enabled, to make sure the clock is stable while and
>> after hard reset.
>>
>> Tested on i.MX6 and i.
t;
>> This patch saves the reset dt properties on probe and does a reset on every
>> open after clocks where enabled, to make sure the clock is stable while and
>> after hard reset.
>>
>> Tested on i.MX6 and i.MX28, both using LAN8720.
>>
>> Signed-off-by:
clocks where enabled, to make sure the clock is stable
while and after hard reset.
Tested on i.MX6 and i.MX28, both using LAN8720.
Signed-off-by: Manfred Schlaegl <manfred.schla...@ginzinger.com>
---
drivers/net/ethernet/freescale/fec.h | 4 ++
drivers/net/ethernet/freescale/fec_main.
clocks where enabled, to make sure the clock is stable
while and after hard reset.
Tested on i.MX6 and i.MX28, both using LAN8720.
Signed-off-by: Manfred Schlaegl
---
drivers/net/ethernet/freescale/fec.h | 4 ++
drivers/net/ethernet/freescale/fec_main.c | 77 +--
2
t
function.
It was tested on linux-4.1.25 and linux-4.7.0-rc2.
Signed-off-by: Manfred Schlaegl <manfred.schla...@ginzinger.com>
---
drivers/net/phy/smsc.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index
t
function.
It was tested on linux-4.1.25 and linux-4.7.0-rc2.
Signed-off-by: Manfred Schlaegl
---
drivers/net/phy/smsc.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index 2e21e93..b62c4aa 100644
--- a/drivers/net/
Pwm config may sleep so defer it using a worker.
On a Freescale i.MX53 based board we ran into "BUG: scheduling while
atomic" because input_inject_event locks interrupts, but
imx_pwm_config_v2 sleeps.
Tested on Freescale i.MX53 SoC with 4.6.0.
Signed-off-by: Manfred Schlaegl <
Pwm config may sleep so defer it using a worker.
On a Freescale i.MX53 based board we ran into "BUG: scheduling while
atomic" because input_inject_event locks interrupts, but
imx_pwm_config_v2 sleeps.
Tested on Freescale i.MX53 SoC with 4.6.0.
Signed-off-by: Manfred Schlaegl
---
dri
On 2016-05-27 10:54, Manfred Schlaegl wrote:
>
> Ok. Thanks for clarification.
> I will send a patch with the modifications you suggested before.
>
> The following patch will also have some slight modifications in line numbers
> to make it apply after
> cfae56f18 (in
On 2016-05-27 10:54, Manfred Schlaegl wrote:
>
> Ok. Thanks for clarification.
> I will send a patch with the modifications you suggested before.
>
> The following patch will also have some slight modifications in line numbers
> to make it apply after
> cfae56f18 (in
On 2016-05-26 02:36, Dmitry Torokhov wrote:
> On Tue, May 24, 2016 at 10:32:53AM +0200, Manfred Schlaegl wrote:
>> On 2016-05-20 18:59, Dmitry Torokhov wrote:
>>> Hi Manfred,
>>>
>>> On Wed, May 18, 2016 at 05:16:49PM +0200, Manfred Schlaegl wrote:
On 2016-05-26 02:36, Dmitry Torokhov wrote:
> On Tue, May 24, 2016 at 10:32:53AM +0200, Manfred Schlaegl wrote:
>> On 2016-05-20 18:59, Dmitry Torokhov wrote:
>>> Hi Manfred,
>>>
>>> On Wed, May 18, 2016 at 05:16:49PM +0200, Manfred Schlaegl wrote:
Pwm config may sleep so defer it using a worker.
On a Freescale i.MX53 based board we ran into "BUG: scheduling while
atomic" because input_inject_event locks interrupts, but
imx_pwm_config_v2 sleeps.
Tested on Freescale i.MX53 SoC with 4.6.0 and 4.1.24.
Signed-off-by: Manfre
Pwm config may sleep so defer it using a worker.
On a Freescale i.MX53 based board we ran into "BUG: scheduling while
atomic" because input_inject_event locks interrupts, but
imx_pwm_config_v2 sleeps.
Tested on Freescale i.MX53 SoC with 4.6.0 and 4.1.24.
Signed-off-by: Manfre
On 2016-05-20 18:59, Dmitry Torokhov wrote:
> Hi Manfred,
>
> On Wed, May 18, 2016 at 05:16:49PM +0200, Manfred Schlaegl wrote:
>> @@ -133,6 +149,8 @@ static int pwm_beeper_remove(struct platform_device
>> *pdev)
>> {
>> struct pwm_beeper *b
On 2016-05-20 18:59, Dmitry Torokhov wrote:
> Hi Manfred,
>
> On Wed, May 18, 2016 at 05:16:49PM +0200, Manfred Schlaegl wrote:
>> @@ -133,6 +149,8 @@ static int pwm_beeper_remove(struct platform_device
>> *pdev)
>> {
>> struct pwm_beeper *b
On 2016-05-18 18:06, Greg Kroah-Hartman wrote:
> On Wed, May 18, 2016 at 05:16:49PM +0200, Manfred Schlaegl wrote:
>> Pwm config may sleep so defer it using a worker.
>>
>> Trigger:
>> On a Freescale i.MX53 based board we ran into "BUG: scheduling while
>> at
On 2016-05-18 18:06, Greg Kroah-Hartman wrote:
> On Wed, May 18, 2016 at 05:16:49PM +0200, Manfred Schlaegl wrote:
>> Pwm config may sleep so defer it using a worker.
>>
>> Trigger:
>> On a Freescale i.MX53 based board we ran into "BUG: scheduling while
>> at
to
* 4.6(stable)
* 4.5.4 (stable)
* 4.4.10 (longterm)
* 4.1.24 (longterm)
Modified applicable to
* 3.18.33 (longterm)
Signed-off-by: Manfred Schlaegl <manfred.schla...@gmx.at>
---
drivers/input/misc/pwm-beeper.c | 54 +++--
1 file changed, 36 i
to
* 4.6(stable)
* 4.5.4 (stable)
* 4.4.10 (longterm)
* 4.1.24 (longterm)
Modified applicable to
* 3.18.33 (longterm)
Signed-off-by: Manfred Schlaegl
---
drivers/input/misc/pwm-beeper.c | 54 +++--
1 file changed, 36 insertions(+), 18 deletions(-)
On 2016-05-12 14:18, Thierry Reding wrote:
>
> I agree with Dmitry. Users of the PWM API should always assume that
> calls to the PWM API might sleep. Conditionalizing on pwm_can_sleep()
> isn't a good idea, since that function is scheduled to be removed. In
> fact it's been returning true
On 2016-05-12 14:18, Thierry Reding wrote:
>
> I agree with Dmitry. Users of the PWM API should always assume that
> calls to the PWM API might sleep. Conditionalizing on pwm_can_sleep()
> isn't a good idea, since that function is scheduled to be removed. In
> fact it's been returning true
Hello,
Any more feedback on this?
Just wanted to remember - this patch is still pending for integration.
kindly regards,
manfred
Hello,
Any more feedback on this?
Just wanted to remember - this patch is still pending for integration.
kindly regards,
manfred
On 2016-02-24 11:28, Philipp Zabel wrote:
> Am Dienstag, den 23.02.2016, 15:30 -0800 schrieb Stefan Agner:
>> Any comments on this?
>
> None other that I'm all in favor. consider patch 2
> Acked-by: Philipp Zabel <p.za...@pengutronix.de>
>
Same here!
Acked-by: Manf
On 2016-02-24 11:28, Philipp Zabel wrote:
> Am Dienstag, den 23.02.2016, 15:30 -0800 schrieb Stefan Agner:
>> Any comments on this?
>
> None other that I'm all in favor. consider patch 2
> Acked-by: Philipp Zabel
>
Same here!
Acked-by: Manfred Schlaegl
regards
Manfred
On 2016-02-22 20:46, Dmitry Torokhov wrote:
> On Wed, Feb 17, 2016 at 02:19:26PM +0100, Manfred Schlaegl wrote:
>> If the pwm can sleep defer actions to it using a worker.
>> A similar approach was used in leds-pwm (c971ff185)
>>
>> Trigger:
>> On a Freescale i.
On 2016-02-22 20:46, Dmitry Torokhov wrote:
> On Wed, Feb 17, 2016 at 02:19:26PM +0100, Manfred Schlaegl wrote:
>> If the pwm can sleep defer actions to it using a worker.
>> A similar approach was used in leds-pwm (c971ff185)
>>
>> Trigger:
>> On a Freescale i.
ale i.MX53 SoC with 4.5-rc1 and 4.1.
Unmodified applicable to
* 4.5-rc4
* 4.4.1 (stable)
* 4.3.5 (stable)
* 4.1.18 (longterm)
Modified applicable to
* 3.18.27 (longterm)
Signed-off-by: Manfred Schlaegl <manfred.schla...@gmx.at>
---
drivers/input/misc/p
ale i.MX53 SoC with 4.5-rc1 and 4.1.
Unmodified applicable to
* 4.5-rc4
* 4.4.1 (stable)
* 4.3.5 (stable)
* 4.1.18 (longterm)
Modified applicable to
* 3.18.27 (longterm)
Signed-off-by: Manfred Schlaegl
---
drivers/input/misc/pwm-beeper.c | 62 +
1 fi
On 2015-11-25 18:22, Philipp Zabel wrote:
> Am Mittwoch, den 15.07.2015, 17:50 +0200 schrieb Manfred Schlaegl:
>> To get full support for parallel and LVDS displays with drm:
>> Add representation for clock and data enable polarity in drm_display_mode
>> flags (similar to
On 2015-11-25 18:22, Philipp Zabel wrote:
> Am Mittwoch, den 15.07.2015, 17:50 +0200 schrieb Manfred Schlaegl:
>> To get full support for parallel and LVDS displays with drm:
>> Add representation for clock and data enable polarity in drm_display_mode
>> flags (similar to
now
de-active unset 1 1
de-active = 0 1 0 <--- corrected
de-active = 1 1 1
Tested on Freescale i.MX53(parallel) and i.MX6(LVDS).
Signed-off-by: Manfred Schlaegl
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 2 --
drivers/gp
videomode,
but there was no representation for this in struct drm_display_mode.
Example on Freescale i.MX53/i.MX6 SoC's:
* A parallel display using different clock polarity is set up using
display-timing in devicetree
* ipuv3 parallel outputs clock with wrong polarity
Signed-off-by: Manfred
Hello!
These patches address a problem we ran into using parallel displays
with Freescale i.MX53 and i.MX6 SoC's.
In short: We wanted to change the clock signal polarity by using
display-timing in the devicetree description, but the output signal stayed
unchanged.
Parallel displays may have
videomode,
but there was no representation for this in struct drm_display_mode.
Example on Freescale i.MX53/i.MX6 SoC's:
* A parallel display using different clock polarity is set up using
display-timing in devicetree
* ipuv3 parallel outputs clock with wrong polarity
Signed-off-by: Manfred
1 1
de-active = 0 1 0 --- corrected
de-active = 1 1 1
Tested on Freescale i.MX53(parallel) and i.MX6(LVDS).
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 2 --
drivers/gpu/ipu-v3/ipu
Hello!
These patches address a problem we ran into using parallel displays
with Freescale i.MX53 and i.MX6 SoC's.
In short: We wanted to change the clock signal polarity by using
display-timing in the devicetree description, but the output signal stayed
unchanged.
Parallel displays may have
On 2015-07-13 16:16, Michael Welling wrote:
> On Fri, Jul 10, 2015 at 10:55:30PM +0200, Manfred Schlaegl wrote:
>> On reading in_voltage_scale of we got an NULL pointer dereference Oops.
>>
>> The reason for this is, that mcp320x_read_raw tries to access
>> chip_i
On 2015-07-13 16:16, Michael Welling wrote:
On Fri, Jul 10, 2015 at 10:55:30PM +0200, Manfred Schlaegl wrote:
On reading in_voltage_scale of we got an NULL pointer dereference Oops.
The reason for this is, that mcp320x_read_raw tries to access
chip_info-resolution from struct mcp320x
use it was not referenced.
The acute problem exists since
b12206e917ac34bec41b9ff93d37d8bd53a2b3bc
iio: adc: mcp320x. Add support for more ADCs
This patch fixes the issue by setting chip_info in mcp320x_probe.
Signed-off-by: Manfred Schlaegl
---
drivers/iio/adc/mcp320x.c |2 ++
1 file chan
it was not referenced.
The acute problem exists since
b12206e917ac34bec41b9ff93d37d8bd53a2b3bc
iio: adc: mcp320x. Add support for more ADCs
This patch fixes the issue by setting chip_info in mcp320x_probe.
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
---
drivers/iio/adc/mcp320x.c
Hello Oliver,
On 2015-06-22 12:34, Oliver Hartkopp wrote:
> Hello Manfred,
>
> On 22.06.2015 12:10, Manfred Schlaegl wrote:
>> On 2015-06-21 18:50, Oliver Hartkopp wrote:
>>> As reported by Manfred Schlaegl here
>>>
>>> http://marc.info/?l=lin
Hello!
On 2015-06-21 18:50, Oliver Hartkopp wrote:
> As reported by Manfred Schlaegl here
>
>http://marc.info/?l=linux-netdev=143482089824232=2
>
> commit 514ac99c64b "can: fix multiple delivery of a single CAN frame for
> overlapping CAN filters" requires the sk
Hello Oliver,
On 2015-06-21 00:42, Oliver Hartkopp wrote:
>> 514ac99c64b22d83b52dfee3b8becaa69a92bc4a introduces a frame equality
>> check. Since the sk_buff pointer is not sufficient to do this (buffers
>> are reused), the check also compares time stamps.
>> In short: pointer+time stamp was
On 2015-06-22 08:48, Alexander Stein wrote:
> Am Samstag, 20. Juni 2015, 19:25:52 schrieb Manfred Schlaegl:
>> To prevent problems with interrupt latency, and due to the fact, that
>> the error will be counted anyway (icount.overrun), the dev_err is simply
>> removed.
>>
Hello Oliver,
On 2015-06-22 12:34, Oliver Hartkopp wrote:
Hello Manfred,
On 22.06.2015 12:10, Manfred Schlaegl wrote:
On 2015-06-21 18:50, Oliver Hartkopp wrote:
As reported by Manfred Schlaegl here
http://marc.info/?l=linux-netdevm=143482089824232w=2
commit 514ac99c64b can: fix
On 2015-06-22 08:48, Alexander Stein wrote:
Am Samstag, 20. Juni 2015, 19:25:52 schrieb Manfred Schlaegl:
To prevent problems with interrupt latency, and due to the fact, that
the error will be counted anyway (icount.overrun), the dev_err is simply
removed.
Background:
If an rx-fifo
Hello Oliver,
On 2015-06-21 00:42, Oliver Hartkopp wrote:
514ac99c64b22d83b52dfee3b8becaa69a92bc4a introduces a frame equality
check. Since the sk_buff pointer is not sufficient to do this (buffers
are reused), the check also compares time stamps.
In short: pointer+time stamp was assumed as
Hello!
On 2015-06-21 18:50, Oliver Hartkopp wrote:
As reported by Manfred Schlaegl here
http://marc.info/?l=linux-netdevm=143482089824232w=2
commit 514ac99c64b can: fix multiple delivery of a single CAN frame for
overlapping CAN filters requires the skb-tstamp to be set to check
As can be seen in function uart_insert_char (serial_core) the element
buf_overrun of struct uart_icount is used to count overruns of
tty-buffer.
Added support for counting of overruns in imx driver analogue to
serial_core.
Signed-off-by: Manfred Schlaegl
---
drivers/tty/serial/imx.c | 12
in a synchronous way
(unbuffered), and console may be a serial terminal, this leads to a
highly increased interrupt-latency (several milliseconds).
As a result of the high latency more rx-fifo overflows will happen, and
therefore a feedback loop of errors is created.
Signed-off-by: Manfred Schlaegl
lity
check is ensured.
I'm not really deep in linux network subsystem, so there may exists
more elegant solutions for the problem.
Signed-off-by: Manfred Schlaegl
---
drivers/net/can/dev.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
ind
fer.
>> Added support for counting of overruns in imx driver analogue to
>> serial_core.
>>
>> Signed-off-by: Manfred Schlaegl
>
> Your From: line in your email doesn't match this, please fix up and
> resend.
>
> Same goes for your other serial patch.
&
is ensured.
I'm not really deep in linux network subsystem, so there may exists
more elegant solutions for the problem.
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
---
drivers/net/can/dev.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/dev.c b/drivers/net/can
of overruns in imx driver analogue to
serial_core.
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
Your From: line in your email doesn't match this, please fix up and
resend.
Same goes for your other serial patch.
thanks,
greg k-h
Hi!
Argh.. Sorry for the mess
As can be seen in function uart_insert_char (serial_core) the element
buf_overrun of struct uart_icount is used to count overruns of
tty-buffer.
Added support for counting of overruns in imx driver analogue to
serial_core.
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
---
drivers/tty
in a synchronous way
(unbuffered), and console may be a serial terminal, this leads to a
highly increased interrupt-latency (several milliseconds).
As a result of the high latency more rx-fifo overflows will happen, and
therefore a feedback loop of errors is created.
Signed-off-by: Manfred Schlaegl
a logos_freed flag somewhere in lateinit, this patch
uses system_state==SYSTEM_BOOTING as indication for valid initdata.
Signed-off-by: Manfred Schlaegl
---
drivers/video/logo/logo.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/video/logo
a logos_freed flag somewhere in lateinit, this patch
uses system_state==SYSTEM_BOOTING as indication for valid initdata.
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
---
drivers/video/logo/logo.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git
the problem by removing tcp_v6_iif, in case of
CONFIG_IPV6=n.
Signed-off-by: Manfred Schlaegl
---
include/net/tcp.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index c9766f8..4062b4f 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -730,6
On 2014-10-18 17:40, Richard Weinberger wrote:
> Am 18.10.2014 um 17:24 schrieb Manfred Schlaegl:
>> On 2014-10-18 17:19, Richard Weinberger wrote:
>>> Am 18.10.2014 um 17:12 schrieb Manfred Schlaegl:
>>>> On 2014-10-18 16:42, Richard Weinberger wrote:
>>>&g
On 2014-10-18 17:40, Richard Weinberger wrote:
Am 18.10.2014 um 17:24 schrieb Manfred Schlaegl:
On 2014-10-18 17:19, Richard Weinberger wrote:
Am 18.10.2014 um 17:12 schrieb Manfred Schlaegl:
On 2014-10-18 16:42, Richard Weinberger wrote:
Am 18.10.2014 um 16:23 schrieb Manfred Schlaegl
solves the problem by removing tcp_v6_iif, in case of
CONFIG_IPV6=n.
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
---
include/net/tcp.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index c9766f8..4062b4f 100644
--- a/include/net/tcp.h
On 2014-10-18 17:19, Richard Weinberger wrote:
> Am 18.10.2014 um 17:12 schrieb Manfred Schlaegl:
>> On 2014-10-18 16:42, Richard Weinberger wrote:
>>> Am 18.10.2014 um 16:23 schrieb Manfred Schlaegl:
>>>> The pointer to bp stack-frame is no longer used. Removed it
On 2014-10-18 16:42, Richard Weinberger wrote:
> Am 18.10.2014 um 16:23 schrieb Manfred Schlaegl:
>> The pointer to bp stack-frame is no longer used. Removed it.
>
> Good catch!
Thank you.
>
>> This also removes a corresponding compiler-warning.
>
> Whic
The pointer to bp stack-frame is no longer used. Removed it.
This also removes a corresponding compiler-warning.
Signed-off-by: Manfred Schlaegl
---
arch/um/kernel/sysrq.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
The pointer to bp stack-frame is no longer used. Removed it.
This also removes a corresponding compiler-warning.
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
---
arch/um/kernel/sysrq.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/um/kernel/sysrq.c b
On 2014-10-18 16:42, Richard Weinberger wrote:
Am 18.10.2014 um 16:23 schrieb Manfred Schlaegl:
The pointer to bp stack-frame is no longer used. Removed it.
Good catch!
Thank you.
This also removes a corresponding compiler-warning.
Which warning exactly?
On normal (defconfig) builds
On 2014-10-18 17:19, Richard Weinberger wrote:
Am 18.10.2014 um 17:12 schrieb Manfred Schlaegl:
On 2014-10-18 16:42, Richard Weinberger wrote:
Am 18.10.2014 um 16:23 schrieb Manfred Schlaegl:
The pointer to bp stack-frame is no longer used. Removed it.
Good catch!
Thank you.
This also
of writing, which guarantees
>> the commit value read is the latest value written if the head is
>> advancing.
This is a fine solution! I'll verify this against my previous experimental setup
(3.12.x and 3.12.x-rt25), but I dont't expect any problems.
>>
>> Reported-by:
.
Reported-by: Manfred Schlaegl manfred.schla...@gmx.at
Cc: sta...@vger.kernel.org # 3.12.x+
The patch submitted by Manfred notes the commits which introduced the
race [1], but attributes those commits to the 3.11 cycle. Those commits
were merged in the 3.12 cycle.
You are right. I'm sorry
On 2014-04-08 14:42, Manfred Schlaegl wrote:
> The race was introduced while development of linux-3.11 by
> e8437d7ecbc50198705331449367d401ebb3181f and
> e9975fdec0138f1b2a85b9624e41660abd9865d4.
> Originally it was found and reproduced on linux-3.12.15 and
> linux-3.12.15-rt25,
On 2014-04-08 14:42, Manfred Schlaegl wrote:
The race was introduced while development of linux-3.11 by
e8437d7ecbc50198705331449367d401ebb3181f and
e9975fdec0138f1b2a85b9624e41660abd9865d4.
Originally it was found and reproduced on linux-3.12.15 and
linux-3.12.15-rt25, by sending 500 byte
// ERROR: tty_buffer head freed -> 6 bytes lost
continue;
}
}}}
This patch reintroduces a spin_lock to protect this case. Perhaps later
a lock-less solution could be found.
Signed-off-by: Manfred Schlaegl
---
drivers/tty/tty_buffer.c | 16 ++--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
;
}
}}}
This patch reintroduces a spin_lock to protect this case. Perhaps later
a lock-less solution could be found.
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
---
drivers/tty/tty_buffer.c | 16 ++--
include/linux/tty.h |1 +
2 files changed, 15 insertions
On 2013-08-27 02:51, Bryan Wu wrote:
> On Tue, Aug 13, 2013 at 4:17 AM, Manfred Schlaegl
> wrote:
>> fb_notifier_callback is called on any event fired by fb_notifier_call_chain.
>> Events may, or may not contain some data (fb_event.data).
>> In case of FB_EVENT_BLAN
On 2013-08-27 02:51, Bryan Wu wrote:
On Tue, Aug 13, 2013 at 4:17 AM, Manfred Schlaegl
manfred.schla...@gmx.at wrote:
fb_notifier_callback is called on any event fired by fb_notifier_call_chain.
Events may, or may not contain some data (fb_event.data).
In case of FB_EVENT_BLANK fb_event.data
/backlight.c line 43 I would suggest to return
immediately on events other than FB_EVENT_BLANK.
Signed-off-by: Manfred Schlaegl
---
Background information:
I'm currently working on a IMX53(ARM) based hardware and Linux 3.11-rc5 and
detected a problem in drivers/leds/trigger/ledtrig-backlight.c
/backlight.c line 43 I would suggest to return
immediately on events other than FB_EVENT_BLANK.
Signed-off-by: Manfred Schlaegl manfred.schla...@gmx.at
---
Background information:
I'm currently working on a IMX53(ARM) based hardware and Linux 3.11-rc5 and
detected a problem in drivers/leds/trigger
86 matches
Mail list logo
