On Fri, Oct 10, 2014 at 11:20:14AM +0200, Johan Hovold wrote:
On Fri, Oct 10, 2014 at 11:12:09AM +0200, Frans Klaver wrote:
I'll move the new entries up. How about I throw in a separate patch that
cleans up stuff around the PID definitions? There's some alignment off
as well. That doesn't
Add new IDs for the Xsens Awinda Station and Awinda Dongle.
While at it, order the definitions by PID and add a logical separation
between devices using Xsens' VID and those using FTDI's VID.
Cc: sta...@vger.kernel.org
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
drivers/usb/serial
On Fri, Oct 10, 2014 at 11:34:43AM +0200, Johan Hovold wrote:
On Fri, Oct 10, 2014 at 11:32:27AM +0200, Frans Klaver wrote:
Add new IDs for the Xsens Awinda Station and Awinda Dongle.
While at it, order the definitions by PID and add a logical separation
between devices using Xsens' VID
Add new IDs for the Xsens Awinda Station and Awinda Dongle.
While at it, order the definitions by PID and add a logical separation
between devices using Xsens' VID and those using FTDI's VID.
Cc: sta...@vger.kernel.org
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
Third time's a charm
On Fri, Oct 10, 2014 at 11:54:00AM +0200, Johan Hovold wrote:
On Fri, Oct 10, 2014 at 11:52:08AM +0200, Frans Klaver wrote:
Add new IDs for the Xsens Awinda Station and Awinda Dongle.
While at it, order the definitions by PID and add a logical separation
between devices using Xsens' VID
On Thu, Oct 9, 2014 at 10:27 PM, Chuck Ebbert wrote:
> On Thu, 9 Oct 2014 22:16:11 +0200
> Frans Klaver wrote:
>
>> On Thu, Oct 9, 2014 at 9:58 PM, Marc Burkhardt wrote:
>> >
>> >
>> >>On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt
>> >>
On Thu, Oct 9, 2014 at 9:58 PM, Marc Burkhardt wrote:
>
>
>>On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt
>>wrote:
>>> I upgraded from 3.10 on that machine. 3.12 didn't work for me due to
>>a hibernation bug. The rest was left out... :/
>>
>>If you still have the 3.12 kernel around, could you
Hi,
Please put your replies below the relevant quote.
On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt wrote:
> I upgraded from 3.10 on that machine. 3.12 didn't work for me due to a
> hibernation bug. The rest was left out... :/
If you still have the 3.12 kernel around, could you test if
On Thu, Oct 9, 2014 at 9:25 PM, Frans Klaver wrote:
> Hi,
>
> On Thu, Oct 9, 2014 at 9:04 PM, Marc Burkhardt wrote:
>> Hi there,
>> I noticed, that 'acpitool -e' doesn't work any longer sind I upgraded to
>> 3.17.
>> The tool stalls at
>>
>>
Hi,
On Thu, Oct 9, 2014 at 9:04 PM, Marc Burkhardt wrote:
> Hi there,
> I noticed, that 'acpitool -e' doesn't work any longer sind I upgraded to 3.17.
> The tool stalls at
>
>Device S-state Status Sysfs node
> ---
> 1. LID S3
On 9 October 2014 19:32:46 CEST, Mark Rutland wrote:
>On Thu, Oct 09, 2014 at 05:09:36PM +0100, Guenter Roeck wrote:
>> On Thu, Oct 09, 2014 at 04:07:56PM +0100, Mark Rutland wrote:
>> > Hi,
>> >
>> > On Thu, Oct 09, 2014 at 03:50:42PM +0100, Frans
From: René Moll
Signed-off-by: René Moll
Signed-off-by: Tjerk Hofmeijer
Signed-off-by: Frans Klaver
---
.../bindings/power/reset/ltc2952-poweroff.txt | 31 ++
1 file changed, 31 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/reset/ltc2952
-off-by: René Moll
Signed-off-by: Tjerk Hofmeijer
Signed-off-by: Frans Klaver
---
drivers/power/reset/Kconfig| 10 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/ltc2952-poweroff.c | 327 +
3 files changed, 338 insertions
This is version 4 of the series that adds support for the ltc2952 powerpath
chip.
This series adds a driver for the LTC2952, an external power control chip, which
signals the OS to shut down. Additionally this driver lets the kernel power
down the board.
This driver was tested with:
- kernel
On Tue, Oct 07, 2014 at 10:15:44AM +0200, Frans Klaver wrote:
> On Mon, Oct 06, 2014 at 02:32:10PM -0700, Guenter Roeck wrote:
> > On Mon, Oct 06, 2014 at 10:40:35AM +0200, Frans Klaver wrote:
> > > +static struct platform_driver ltc2952_poweroff_driver = {
> > > + .pro
On Tue, Oct 07, 2014 at 10:15:44AM +0200, Frans Klaver wrote:
On Mon, Oct 06, 2014 at 02:32:10PM -0700, Guenter Roeck wrote:
On Mon, Oct 06, 2014 at 10:40:35AM +0200, Frans Klaver wrote:
+static struct platform_driver ltc2952_poweroff_driver = {
+ .probe = ltc2952_poweroff_probe
This is version 4 of the series that adds support for the ltc2952 powerpath
chip.
This series adds a driver for the LTC2952, an external power control chip, which
signals the OS to shut down. Additionally this driver lets the kernel power
down the board.
This driver was tested with:
- kernel
was used.
Signed-off-by: René Moll li...@r-moll.nl
Signed-off-by: Tjerk Hofmeijer tjerk.hofmei...@xsens.com
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
drivers/power/reset/Kconfig| 10 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/ltc2952-poweroff.c | 327
From: René Moll li...@r-moll.nl
Signed-off-by: René Moll li...@r-moll.nl
Signed-off-by: Tjerk Hofmeijer tjerk.hofmei...@xsens.com
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
.../bindings/power/reset/ltc2952-poweroff.txt | 31 ++
1 file changed, 31 insertions
On 9 October 2014 19:32:46 CEST, Mark Rutland mark.rutl...@arm.com wrote:
On Thu, Oct 09, 2014 at 05:09:36PM +0100, Guenter Roeck wrote:
On Thu, Oct 09, 2014 at 04:07:56PM +0100, Mark Rutland wrote:
Hi,
On Thu, Oct 09, 2014 at 03:50:42PM +0100, Frans Klaver wrote:
From: René Moll li
Hi,
On Thu, Oct 9, 2014 at 9:04 PM, Marc Burkhardt m...@osknowledge.org wrote:
Hi there,
I noticed, that 'acpitool -e' doesn't work any longer sind I upgraded to 3.17.
The tool stalls at
Device S-state Status Sysfs node
---
1. LID
On Thu, Oct 9, 2014 at 9:25 PM, Frans Klaver franskla...@gmail.com wrote:
Hi,
On Thu, Oct 9, 2014 at 9:04 PM, Marc Burkhardt m...@osknowledge.org wrote:
Hi there,
I noticed, that 'acpitool -e' doesn't work any longer sind I upgraded to
3.17.
The tool stalls at
Device S-state
Hi,
Please put your replies below the relevant quote.
On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt m...@osknowledge.org wrote:
I upgraded from 3.10 on that machine. 3.12 didn't work for me due to a
hibernation bug. The rest was left out... :/
If you still have the 3.12 kernel around,
On Thu, Oct 9, 2014 at 9:58 PM, Marc Burkhardt m...@osknowledge.org wrote:
On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt m...@osknowledge.org
wrote:
I upgraded from 3.10 on that machine. 3.12 didn't work for me due to
a hibernation bug. The rest was left out... :/
If you still have the 3.12
On Thu, Oct 9, 2014 at 10:27 PM, Chuck Ebbert cebbert.l...@gmail.com wrote:
On Thu, 9 Oct 2014 22:16:11 +0200
Frans Klaver franskla...@gmail.com wrote:
On Thu, Oct 9, 2014 at 9:58 PM, Marc Burkhardt m...@osknowledge.org wrote:
On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt m
On Tue, Oct 07, 2014 at 06:16:19AM -0700, Guenter Roeck wrote:
> On 10/07/2014 01:15 AM, Frans Klaver wrote:
> > On Mon, Oct 06, 2014 at 02:32:10PM -0700, Guenter Roeck wrote:
>
> >> Any reason for not using devm_gpiod_get() for those functions ?
> >
> > Re
Olof, Anton,
Care to pitch in?
Thanks,
Frans
On Thu, Sep 25, 2014 at 11:32 AM, Frans Klaver wrote:
> On Thu, Sep 25, 2014 at 11:27 AM, Mark Rutland wrote:
>> On Wed, Sep 24, 2014 at 07:59:34PM +0100, Frans Klaver wrote:
>>> On Wed, Sep 24, 2014 at 04:34:32PM +0100,
On Mon, Oct 06, 2014 at 02:32:10PM -0700, Guenter Roeck wrote:
> On Mon, Oct 06, 2014 at 10:40:35AM +0200, Frans Klaver wrote:
> > + * - kill (output)
> > + * The last action during shut down is triggering this signalling, such
> > + * that the PowerPath Co
On Mon, Oct 06, 2014 at 02:32:10PM -0700, Guenter Roeck wrote:
On Mon, Oct 06, 2014 at 10:40:35AM +0200, Frans Klaver wrote:
+ * - kill (output)
+ * The last action during shut down is triggering this signalling, such
+ * that the PowerPath Control will power down the hardware
Olof, Anton,
Care to pitch in?
Thanks,
Frans
On Thu, Sep 25, 2014 at 11:32 AM, Frans Klaver franskla...@gmail.com wrote:
On Thu, Sep 25, 2014 at 11:27 AM, Mark Rutland mark.rutl...@arm.com wrote:
On Wed, Sep 24, 2014 at 07:59:34PM +0100, Frans Klaver wrote:
On Wed, Sep 24, 2014 at 04:34:32PM
On Tue, Oct 07, 2014 at 06:16:19AM -0700, Guenter Roeck wrote:
On 10/07/2014 01:15 AM, Frans Klaver wrote:
On Mon, Oct 06, 2014 at 02:32:10PM -0700, Guenter Roeck wrote:
Any reason for not using devm_gpiod_get() for those functions ?
René said in the first review round:
devm_
From: René Moll
Signed-off-by: René Moll
Signed-off-by: Tjerk Hofmeijer
Signed-off-by: Frans Klaver
---
.../bindings/power/reset/ltc2952-poweroff.txt | 31 ++
1 file changed, 31 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/reset/ltc2952
-off-by: Ren� Moll
Signed-off-by: Tjerk Hofmeijer
Signed-off-by: Frans Klaver
---
drivers/power/reset/Kconfig| 10 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/ltc2952-poweroff.c | 381 +
3 files changed, 392 insertions
This is version 3 of the series that adds support for the ltc2952 powerpath
chip.
This series adds a driver for the LTC2952, an external power control chip, which
signals the OS to shut down. Additionally this driver lets the kernel power
down the board.
This driver was tested with:
- kernel
This is version 3 of the series that adds support for the ltc2952 powerpath
chip.
This series adds a driver for the LTC2952, an external power control chip, which
signals the OS to shut down. Additionally this driver lets the kernel power
down the board.
This driver was tested with:
- kernel
From: René Moll li...@r-moll.nl
Signed-off-by: René Moll li...@r-moll.nl
Signed-off-by: Tjerk Hofmeijer tjerk.hofmei...@xsens.com
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
.../bindings/power/reset/ltc2952-poweroff.txt | 31 ++
1 file changed, 31 insertions
was used.
Signed-off-by: Ren� Moll li...@r-moll.nl
Signed-off-by: Tjerk Hofmeijer tjerk.hofmei...@xsens.com
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
drivers/power/reset/Kconfig| 10 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/ltc2952-poweroff.c | 381
On 2 October 2014 21:34:10 CEST, Michael Opdenacker
wrote:
>Hi Frans,
>
>On 10/02/2014 09:43 AM, Frans Klaver wrote:
>> On Thu, Oct 2, 2014 at 6:45 AM, Michael Opdenacker
>> wrote:
>>> Signed-off-by: Michael Opdenacker
>
>>> ---
>>> include/li
On Thu, Oct 2, 2014 at 6:45 AM, Michael Opdenacker
wrote:
> Signed-off-by: Michael Opdenacker
> ---
> include/linux/mod_devicetable.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index
On 2 October 2014 21:34:10 CEST, Michael Opdenacker
michael.opdenac...@free-electrons.com wrote:
Hi Frans,
On 10/02/2014 09:43 AM, Frans Klaver wrote:
On Thu, Oct 2, 2014 at 6:45 AM, Michael Opdenacker
michael.opdenac...@free-electrons.com wrote:
Signed-off-by: Michael Opdenacker
On Thu, Oct 2, 2014 at 6:45 AM, Michael Opdenacker
michael.opdenac...@free-electrons.com wrote:
Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com
---
include/linux/mod_devicetable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Signed-off-by: Frans Klaver
---
Documentation/usb/gadget_configfs.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/usb/gadget_configfs.txt
b/Documentation/usb/gadget_configfs.txt
index 4cf53e4..635e574 100644
--- a/Documentation/usb/gadget_configfs.txt
+++ b
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
Documentation/usb/gadget_configfs.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/usb/gadget_configfs.txt
b/Documentation/usb/gadget_configfs.txt
index 4cf53e4..635e574 100644
--- a/Documentation/usb
On Mon, Sep 29, 2014 at 12:30:43PM +0200, Frans Klaver wrote:
> On Mon, Sep 29, 2014 at 11:54:40AM +0200, Sebastian Andrzej Siewior wrote:
> > For your "too much work for irq" problem: Could you add trace_printk()
> > in tx/rx dma start/complete, and irq routine? The inte
On Mon, Sep 29, 2014 at 12:30:43PM +0200, Frans Klaver wrote:
On Mon, Sep 29, 2014 at 11:54:40AM +0200, Sebastian Andrzej Siewior wrote:
For your too much work for irq problem: Could you add trace_printk()
in tx/rx dma start/complete, and irq routine? The interresting part is
what
On Mon, Sep 29, 2014 at 3:27 PM, Sebastian Andrzej Siewior
wrote:
> * Frans Klaver | 2014-09-29 11:38:23 [+0200]:
>
>>threshold
> fixed
>
>>> +/*
>>> + * It claims to be 16C750 compatible however it is a little different.
>>> + * It has E
On Mon, Sep 29, 2014 at 11:54:40AM +0200, Sebastian Andrzej Siewior wrote:
> There is a patch named "ARM: edma: unconditionally ack the error
> interrupt". I have the feeling that this is not really required once we
> delay set_termios. I couldn't reproduce the bug with beagleblack with my
> usual
On Wed, Sep 10, 2014 at 09:29:57PM +0200, Sebastian Andrzej Siewior wrote:
> +/*
> + * This two wrapper ensure, that enable_runtime_pm_tx() can be called more
> than
These two wrappers ensure that enable_runtime_pm_tx() ...
> + * once and disable_runtime_pm_tx() will still disable RPM because
On Wed, Sep 10, 2014 at 09:30:01PM +0200, Sebastian Andrzej Siewior wrote:
> + /*
> + * We enable TRIG_GRANU for RX and TX and additionaly we set
> + * SCR_TX_EMPTY bit. The result is the following:
> + * - RX_TRIGGER amount of bytes in the FIFO will cause an interrupt.
> +
On Wed, Sep 10, 2014 at 09:30:08PM +0200, Sebastian Andrzej Siewior wrote:
> There is nothing to do for RPM in the RX path. If the HW goes off then it
> won't assert the DMA line and the transfer won't happen. So we hope that
> the HW does not go off for RX to work (DMA or PIO makes no difference
On Wed, Sep 10, 2014 at 09:30:07PM +0200, Sebastian Andrzej Siewior wrote:
> Sometimes the OMAP UART does not signal the DMA engine to unload the FIFO.
> Usually this happens when we have >threshold bytes in the FIFO
> and start the DMA transfer. It seems that in those cases the UART won't
>
On Thu, Sep 25, 2014 at 05:14:03PM +0200, Sebastian Andrzej Siewior wrote:
> * Frans Klaver | 2014-09-22 11:28:54 [+0200]:
>
> >I guess then we'd still have to answer the question why the yocto build
> >calls set_termios() so often, but that's not on you then. Did you notice
&
On Thu, Sep 25, 2014 at 05:14:03PM +0200, Sebastian Andrzej Siewior wrote:
* Frans Klaver | 2014-09-22 11:28:54 [+0200]:
I guess then we'd still have to answer the question why the yocto build
calls set_termios() so often, but that's not on you then. Did you notice
it even changing settings
On Wed, Sep 10, 2014 at 09:30:07PM +0200, Sebastian Andrzej Siewior wrote:
Sometimes the OMAP UART does not signal the DMA engine to unload the FIFO.
Usually this happens when we have threshold bytes in the FIFO
and start the DMA transfer. It seems that in those cases the UART won't
trigger
On Wed, Sep 10, 2014 at 09:30:08PM +0200, Sebastian Andrzej Siewior wrote:
There is nothing to do for RPM in the RX path. If the HW goes off then it
won't assert the DMA line and the transfer won't happen. So we hope that
the HW does not go off for RX to work (DMA or PIO makes no difference
On Wed, Sep 10, 2014 at 09:30:01PM +0200, Sebastian Andrzej Siewior wrote:
+ /*
+ * We enable TRIG_GRANU for RX and TX and additionaly we set
+ * SCR_TX_EMPTY bit. The result is the following:
+ * - RX_TRIGGER amount of bytes in the FIFO will cause an interrupt.
+ * -
On Wed, Sep 10, 2014 at 09:29:57PM +0200, Sebastian Andrzej Siewior wrote:
+/*
+ * This two wrapper ensure, that enable_runtime_pm_tx() can be called more
than
These two wrappers ensure that enable_runtime_pm_tx() ...
+ * once and disable_runtime_pm_tx() will still disable RPM because the
On Mon, Sep 29, 2014 at 11:54:40AM +0200, Sebastian Andrzej Siewior wrote:
There is a patch named ARM: edma: unconditionally ack the error
interrupt. I have the feeling that this is not really required once we
delay set_termios. I couldn't reproduce the bug with beagleblack with my
usual test
On Mon, Sep 29, 2014 at 3:27 PM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
* Frans Klaver | 2014-09-29 11:38:23 [+0200]:
threshold
fixed
+/*
+ * It claims to be 16C750 compatible however it is a little different.
+ * It has EFR and has no FCR7_64byte bit. The AFE
On Thu, Sep 25, 2014 at 06:28:47PM +0200, Oscar Utbult wrote:
> On 2014-09-25 16:48, Frans Klaver wrote:
> > On Thu, Sep 25, 2014 at 3:41 PM, wrote:
> >> Subject: [PATCH 1/1] Changed "&" with "and" in
> >> Documentation/applying-patches
On 25 September 2014 17:14:03 CEST, Sebastian Andrzej Siewior
wrote:
>* Frans Klaver | 2014-09-22 11:28:54 [+0200]:
>
>>I guess then we'd still have to answer the question why the yocto
>build
>>calls set_termios() so often, but that's not on you then. Did you
>notice
>
On Thu, Sep 25, 2014 at 3:41 PM, wrote:
> Subject: [PATCH 1/1] Changed "&" with "and" in
> Documentation/applying-patches.txt.
Documentation/SubmittingPatches says:
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I]
On Thu, Sep 25, 2014 at 4:20 PM, Frans Klaver wrote:
> On Sat, Aug 23, 2014 at 1:19 PM, Schrey wrote:
>> Greetings.
>>
>> On an administered server, I noticed that there's a constant load
>> around 0.70 when running kernels 3.10 and 3.12, even if
>> the syste
On Sat, Aug 23, 2014 at 1:19 PM, Schrey wrote:
> Greetings.
>
> On an administered server, I noticed that there's a constant load
> around 0.70 when running kernels 3.10 and 3.12, even if
> the system is doing nothing, and in single user mode.
> Culprit seems to be the process 'khubd'.
> No such
On Thu, Sep 25, 2014 at 12:16:28PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 25, 2014 at 11:19:51AM +0200, Frans Klaver wrote:
> > If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
> > calculated n values in serial_omap_is_baud_mode16() may become 0. This
> &
On Thu, Sep 25, 2014 at 11:27 AM, Mark Rutland wrote:
> On Wed, Sep 24, 2014 at 07:59:34PM +0100, Frans Klaver wrote:
>> On Wed, Sep 24, 2014 at 04:34:32PM +0100, Mark Rutland wrote:
>> > On Wed, Sep 24, 2014 at 04:14:48PM +0100, Frans Klaver wrote:
>> > > On Wed, Se
)
[] (tty_ioctl) from [] (do_vfs_ioctl+0x4a0/0x560)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x4c/0x74)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x30)
Signed-off-by: Frans Klaver
---
Resend to add sta...@vger.kernel.org to CC. As far as I know, this applies to
v3.9 and up.
Thanks,
Frans
drivers/tty
] (SyS_ioctl) from [c000e480] (ret_fast_syscall+0x0/0x30)
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
Resend to add sta...@vger.kernel.org to CC. As far as I know, this applies to
v3.9 and up.
Thanks,
Frans
drivers/tty/serial/omap-serial.c | 12 ++--
1 file changed, 10 insertions
On Thu, Sep 25, 2014 at 11:27 AM, Mark Rutland mark.rutl...@arm.com wrote:
On Wed, Sep 24, 2014 at 07:59:34PM +0100, Frans Klaver wrote:
On Wed, Sep 24, 2014 at 04:34:32PM +0100, Mark Rutland wrote:
On Wed, Sep 24, 2014 at 04:14:48PM +0100, Frans Klaver wrote:
On Wed, Sep 24, 2014 at 03:38
On Thu, Sep 25, 2014 at 12:16:28PM +0200, Greg Kroah-Hartman wrote:
On Thu, Sep 25, 2014 at 11:19:51AM +0200, Frans Klaver wrote:
If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n values in serial_omap_is_baud_mode16() may become 0. This
causes a division by zero
On Sat, Aug 23, 2014 at 1:19 PM, Schrey debian-ker...@schreyben.de wrote:
Greetings.
On an administered server, I noticed that there's a constant load
around 0.70 when running kernels 3.10 and 3.12, even if
the system is doing nothing, and in single user mode.
Culprit seems to be the process
On Thu, Sep 25, 2014 at 4:20 PM, Frans Klaver franskla...@gmail.com wrote:
On Sat, Aug 23, 2014 at 1:19 PM, Schrey debian-ker...@schreyben.de wrote:
Greetings.
On an administered server, I noticed that there's a constant load
around 0.70 when running kernels 3.10 and 3.12, even if
the system
On Thu, Sep 25, 2014 at 3:41 PM, os...@oscr.io wrote:
Subject: [PATCH 1/1] Changed with and in
Documentation/applying-patches.txt.
Documentation/SubmittingPatches says:
Describe your changes in imperative mood, e.g. make xyzzy do frotz
instead of [This patch] makes xyzzy do frotz or [I]
On 25 September 2014 17:14:03 CEST, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
* Frans Klaver | 2014-09-22 11:28:54 [+0200]:
I guess then we'd still have to answer the question why the yocto
build
calls set_termios() so often, but that's not on you then. Did you
notice
it even
On Thu, Sep 25, 2014 at 06:28:47PM +0200, Oscar Utbult wrote:
On 2014-09-25 16:48, Frans Klaver wrote:
On Thu, Sep 25, 2014 at 3:41 PM, os...@oscr.io wrote:
Subject: [PATCH 1/1] Changed with and in
Documentation/applying-patches.txt.
Documentation/SubmittingPatches says
On Wed, Sep 24, 2014 at 04:34:32PM +0100, Mark Rutland wrote:
> On Wed, Sep 24, 2014 at 04:14:48PM +0100, Frans Klaver wrote:
> > On Wed, Sep 24, 2014 at 03:38:49PM +0100, Mark Rutland wrote:
> > > On Wed, Sep 24, 2014 at 03:22:22PM +0100, Frans Klaver wrote:
> > > You
On Wed, Sep 24, 2014 at 03:38:49PM +0100, Mark Rutland wrote:
> On Wed, Sep 24, 2014 at 03:22:22PM +0100, Frans Klaver wrote:
> > On Wed, Sep 24, 2014 at 02:16:55PM +0100, Mark Rutland wrote:
> > > On Wed, Sep 24, 2014 at 02:11:17PM +0100, Frans Klaver wrote:
> > &g
On Wed, Sep 24, 2014 at 02:16:55PM +0100, Mark Rutland wrote:
> On Wed, Sep 24, 2014 at 02:11:17PM +0100, Frans Klaver wrote:
> > In some cases you want to instantiate a battery even before it is
> > attached; it is perfectly reasonable for a device to start up on
> > wall-p
Document the sbs,always-present property of sbs batteries.
Signed-off-by: Frans Klaver
---
Documentation/devicetree/bindings/power_supply/sbs_sbs-battery.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/power_supply/sbs_sbs-battery.txt
b/Documentation
about this.
Thanks,
Frans
Frans Klaver (2):
sbs-battery: add forced instantiation from device tree
sbs-battery: dts: document always-present property
.../devicetree/bindings/power_supply/sbs_sbs-battery.txt | 2 ++
drivers/power/sbs-battery.c | 11
. The downside of these approaches is that the user needs
to keep the information related to the i2c battery in different places,
which is inconvenient.
Add the "sbs,always-present" option to the device tree. If set, the
battery is instantiated without sanity checking the connection.
Signed-off
On Wed, Sep 24, 2014 at 10:41:11AM +0200, Frans Klaver wrote:
> On Wed, Sep 24, 2014 at 01:08:52AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Sep 24, 2014 at 09:55:21AM +0200, Frans Klaver wrote:
> > > If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
> &g
On Wed, Sep 24, 2014 at 01:08:52AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Sep 24, 2014 at 09:55:21AM +0200, Frans Klaver wrote:
> > If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
> > calculated n values in serial_omap_is_baud_mode16() may become 0. This
> &
the CamelCasing from the variable names.
Signed-off-by: Frans Klaver
---
drivers/tty/serial/omap-serial.c | 42 +++-
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e454b7c..18c30ca
ing
stuff, but it doesn't really make sense to move bugs around before fixing them,
unless fixing them requires moving them around.
Anyway, here's the respin.
v1..v2:
- swapped fix and cleanup to ease backporting
Frans Klaver (2):
tty: omap-serial: fix division by zero
tty: omap-serial:
)
[] (tty_ioctl) from [] (do_vfs_ioctl+0x4a0/0x560)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x4c/0x74)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x30)
Signed-off-by: Frans Klaver
---
drivers/tty/serial/omap-serial.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git
] (SyS_ioctl) from [c000e480] (ret_fast_syscall+0x0/0x30)
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
drivers/tty/serial/omap-serial.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index
, but it doesn't really make sense to move bugs around before fixing them,
unless fixing them requires moving them around.
Anyway, here's the respin.
v1..v2:
- swapped fix and cleanup to ease backporting
Frans Klaver (2):
tty: omap-serial: fix division by zero
tty: omap-serial: pull out
the CamelCasing from the variable names.
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
drivers/tty/serial/omap-serial.c | 42 +++-
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
On Wed, Sep 24, 2014 at 01:08:52AM -0700, Greg Kroah-Hartman wrote:
On Wed, Sep 24, 2014 at 09:55:21AM +0200, Frans Klaver wrote:
If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n values in serial_omap_is_baud_mode16() may become 0. This
causes a division by zero
On Wed, Sep 24, 2014 at 10:41:11AM +0200, Frans Klaver wrote:
On Wed, Sep 24, 2014 at 01:08:52AM -0700, Greg Kroah-Hartman wrote:
On Wed, Sep 24, 2014 at 09:55:21AM +0200, Frans Klaver wrote:
If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n values
. The downside of these approaches is that the user needs
to keep the information related to the i2c battery in different places,
which is inconvenient.
Add the sbs,always-present option to the device tree. If set, the
battery is instantiated without sanity checking the connection.
Signed-off-by: Frans
about this.
Thanks,
Frans
Frans Klaver (2):
sbs-battery: add forced instantiation from device tree
sbs-battery: dts: document always-present property
.../devicetree/bindings/power_supply/sbs_sbs-battery.txt | 2 ++
drivers/power/sbs-battery.c | 11
Document the sbs,always-present property of sbs batteries.
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
Documentation/devicetree/bindings/power_supply/sbs_sbs-battery.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/power_supply/sbs_sbs
On Wed, Sep 24, 2014 at 02:16:55PM +0100, Mark Rutland wrote:
On Wed, Sep 24, 2014 at 02:11:17PM +0100, Frans Klaver wrote:
In some cases you want to instantiate a battery even before it is
attached; it is perfectly reasonable for a device to start up on
wall-power and be connected
On Wed, Sep 24, 2014 at 03:38:49PM +0100, Mark Rutland wrote:
On Wed, Sep 24, 2014 at 03:22:22PM +0100, Frans Klaver wrote:
On Wed, Sep 24, 2014 at 02:16:55PM +0100, Mark Rutland wrote:
On Wed, Sep 24, 2014 at 02:11:17PM +0100, Frans Klaver wrote:
In some cases you want to instantiate
On Wed, Sep 24, 2014 at 04:34:32PM +0100, Mark Rutland wrote:
On Wed, Sep 24, 2014 at 04:14:48PM +0100, Frans Klaver wrote:
On Wed, Sep 24, 2014 at 03:38:49PM +0100, Mark Rutland wrote:
On Wed, Sep 24, 2014 at 03:22:22PM +0100, Frans Klaver wrote:
You mention that there's a GPIO that can
On Tue, Sep 23, 2014 at 8:38 PM, Tony Lindgren wrote:
> * Frans Klaver [140923 11:12]:
>> On 23 September 2014 19:17:20 CEST, Peter Hurley
>> wrote:
>> >
>> >I would've thought the first 2 patches had already been picked up
>> >because
>&
To determine the correct divisor, we need to know the difference between
the desired baud rate and the actual baud rate. The calculation for this
difference is implemented twice within omap_serial_baud_is_mode16().
Pull out the calculation for easier maintenance.
Signed-off-by: Frans Klaver
Hi Greg,
Here's a couple of patches that fix a divison by zero in omap-serial.c. One's a
cleanup, the other the actual fix.
Thanks,
Frans
Frans Klaver (2):
tty: omap-serial: pull out calculation from baud_is_mode16
tty: omap-serial: fix a division by zero
drivers/tty/serial/omap-serial.c
701 - 800 of 999 matches
Mail list logo
