The function argument for the ISC_D0 on PC9 was incorrect. According to
the documentation it should be 'C' aka 3.
Signed-off-by: David Engraf
---
arch/arm/boot/dts/sama5d2-pinfunc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sama5d2-pinfunc
On 12.02.19 at 11:43, Andy Shevchenko wrote:
On Mon, Feb 11, 2019 at 2:40 PM David Engraf wrote:
On 11.02.19 at 12:40, Andy Shevchenko wrote:
On Mon, Feb 11, 2019 at 10:49 AM David Engraf wrote:
On 11.02.19 at 08:56, David Engraf wrote:
On 09.02.19 at 11:35, Andy Shevchenko wrote:
On Sat
On 12.02.19 at 01:56, Andrew Morton wrote:
On Sat, 9 Feb 2019 12:35:03 +0200 Andy Shevchenko
wrote:
On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton wrote:
On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko
wrote:
On Tue, Oct 30, 2018 at 5:22 PM David Engraf wrote:
Unpacking an external
On 11.02.19 at 12:40, Andy Shevchenko wrote:
On Mon, Feb 11, 2019 at 10:49 AM David Engraf wrote:
On 11.02.19 at 08:56, David Engraf wrote:
On 09.02.19 at 11:35, Andy Shevchenko wrote:
On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton
wrote:
On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko
On 11.02.19 at 08:56, David Engraf wrote:
On 09.02.19 at 11:35, Andy Shevchenko wrote:
On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton
wrote:
On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko
wrote:
On Tue, Oct 30, 2018 at 5:22 PM David Engraf
wrote:
Unpacking an external initrd may fail
On 09.02.19 at 11:35, Andy Shevchenko wrote:
On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton wrote:
On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko
wrote:
On Tue, Oct 30, 2018 at 5:22 PM David Engraf wrote:
Unpacking an external initrd may fail e.g. not enough memory. This leads
to an
On 05.02.19 at 14:23, Andy Shevchenko wrote:
On Tue, Feb 05, 2019 at 01:19:52PM +0100, David Engraf wrote:
dev_set_drvdata/dev_get_drvdata is used to access driver_data
in struct device.
The original comment might be slight confusing, though we all know the concept
of getters and setters
dev_set_drvdata/dev_get_drvdata is used to access driver_data
in struct device.
Signed-off-by: David Engraf
---
include/linux/device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index 6cb4640b6160..601594771153 100644
Unpacking an external initrd may fail e.g. not enough memory. This leads
to an incomplete rootfs because some files might be extracted already.
Fixed by cleaning the rootfs so the kernel is not using an incomplete
rootfs.
Signed-off-by: David Engraf
---
init/initramfs.c | 6 +++---
1 file
Unpacking an external initrd may fail e.g. not enough memory. This leads
to an incomplete rootfs because some files might be extracted already.
Fixed by cleaning the rootfs so the kernel is not using an incomplete
rootfs.
Signed-off-by: David Engraf
---
init/initramfs.c | 6 +++---
1 file
Hi Dmitry,
On 30.04.2018 at 23:20, Dmitry Torokhov wrote:
Hi David,
On Mon, Apr 30, 2018 at 11:03:24AM +0200, David Engraf wrote:
The current version only supports forwarding a single byte to the tty
layer.
This patch adds serio_write_length() to allow a serport driver writing
multiple bytes
-by: David Engraf
---
drivers/input/serio/serport.c | 7 ---
include/linux/serio.h | 13 -
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/input/serio/serport.c b/drivers/input/serio/serport.c
index f8ead9f9c77e..209343f636a3 100644
--- a/drivers
Am 28.04.2018 um 14:38 schrieb Wolfram Sang:
On Thu, Apr 26, 2018 at 11:53:14AM +0200, David Engraf wrote:
With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.
This patch polls RXRDY and
With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.
This patch polls RXRDY and reads all available bytes at
once.
Signed-off-by: David Engraf
---
drivers/i2c/busses/i2c-at91.c | 12
Hi Ludovic,
Am 25.04.2018 um 17:08 schrieb Ludovic Desroches:
Hi David,
On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:
With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts
Hi Ludovic,
Am 25.04.2018 um 17:08 schrieb Ludovic Desroches:
Hi David,
On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:
With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts
With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.
Signed-off-by: David Engraf
---
drivers/i2c/busses/i2c-at91.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff
treff: [PATCH resend] timers, sched_clock: Update timeout for clock wrap
Datum: Thu, 2 Mar 2017 10:02:16 +0100
Von: David Engraf
An: t...@linutronix.de, john.stu...@linaro.org
Kopie (CC): linux-kernel@vger.kernel.org, David Engraf
The scheduler clock framework may not use the correct timeout fo
clock
already wrapped.
On my ARM system the scheduler was no longer scheduling any other task than
the idle task because the sched_clock() wrapped.
Signed-off-by: David Engraf
---
kernel/time/sched_clock.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/time/sched_clock.c b/kernel
clock
already wrapped.
On my ARM system the scheduler was no longer scheduling any other task than
the idle task because the sched_clock() wrapped.
Signed-off-by: David Engraf
---
kernel/time/sched_clock.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/time/sched_clock.c b/kernel
Am 17.01.2017 um 10:13 schrieb Daniel Lezcano:
On 11/01/2017 14:50, David Engraf wrote:
On newer boards the TC can be read as single 32 bit value without locking.
Thus the clock can be used as reference for sched_clock which is much more
accurate than the jiffies implementation.
Tested on a
On newer boards the TC can be read as single 32 bit value without locking.
Thus the clock can be used as reference for sched_clock which is much more
accurate than the jiffies implementation.
Tested on a Atmel SAMA5D2 board.
Signed-off-by: David Engraf
---
drivers/clocksource/tcb_clksrc.c | 16
The QEMU e500 board needs to enable CONFIG_E500 to correctly boot. QEMU
for ppc64 uses e5500/e6500 emulation, thus CONFIG_PPC_E500MC is required
as well.
Signed-off-by: David Engraf
---
arch/powerpc/platforms/85xx/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc
Am 27.09.2016 um 01:08 schrieb Scott Wood:
On Mon, 2016-09-26 at 10:48 +0200, David Engraf wrote:
Am 25.09.2016 um 08:20 schrieb Scott Wood:
On Mon, Aug 22, 2016 at 04:46:43PM +0200, David Engraf wrote:
The PowerPC e5500/e6500 architecture is based on the e500mc core. Enable
CONFIG_E500 and
Am 25.09.2016 um 08:20 schrieb Scott Wood:
On Mon, Aug 22, 2016 at 04:46:43PM +0200, David Engraf wrote:
The PowerPC e5500/e6500 architecture is based on the e500mc core. Enable
CONFIG_E500 and CONFIG_PPC_E500MC when e5500/e6500 is used.
This will also fix using CONFIG_PPC_QEMU_E500 on PPC64
The PowerPC e5500/e6500 architecture is based on the e500mc core. Enable
CONFIG_E500 and CONFIG_PPC_E500MC when e5500/e6500 is used.
This will also fix using CONFIG_PPC_QEMU_E500 on PPC64.
Signed-off-by: David Engraf
---
arch/powerpc/platforms/Kconfig.cputype | 6 --
1 file changed, 4
On a system with low memory extracting the initramfs may fail. If this
happens the user gets "Failed to execute /init" instead of an initramfs
error.
Check return value of sys_write and call error() when the write was
incomplete or failed.
Signed-off-by: David Engraf
diff --
Am 08.04.2013 22:20, schrieb John Stultz:
On 03/19/2013 05:29 AM, David Engraf wrote:
Hello,
I've triggered an overflow when using ktime_add_ns() on a 32bit
architecture not supporting CONFIG_KTIME_SCALAR.
When passing a very high value for u64 nsec, e.g. 7881299347898368000
the d
Am 19.03.2013 13:38, schrieb Eric Dumazet:
On Tue, 2013-03-19 at 13:29 +0100, David Engraf wrote:
Hello,
I've triggered an overflow when using ktime_add_ns() on a 32bit
architecture not supporting CONFIG_KTIME_SCALAR.
When passing a very high value for u64 nsec, e.g. 788129934789836800
_KTIME_SCALAR (e.g. ARM, x86-32).
Best regards
- David
Signed-off-by: David Engraf
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index cc47812..320a7aa 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -275,6 +275,10 @@ ktime_t ktime_add_ns(const ktime_t kt, u64 nsec)
} else {
unsi
Am 15.02.2013 23:34, schrieb John Stultz:
On Mon, Feb 11, 2013 at 7:48 AM, David Engraf wrote:
I have encountered a problem when a linux system uses a clocksource with
mult = 1 and shift = 0 (clocksource cycle = nanoseconds). It may happen that
the function timekeeping_adjust reduces the value
, ktime_get will no longer work because
it uses timekeeping_get_ns which converts the cycle to nanoseconds with
mult as 0 and the system clocksource returns always 0.
Best regards
David Engraf
[1] http://lxr.linux.no/linux+v3.0.62/kernel/time/timekeeping.c#L821
--
To unsubscribe from this list
my system there is no change, but maybe this patch works on
your system.
Thanks
David Engraf
linux-2.6.22.1
diff -puN drivers/usb/host/pci-quirks_orig.c drivers/usb/host/pci-quirks.c
--- drivers/usb/host/pci-quirks_orig.c2007-07-10 20:56:30.0
+0200
+++ drivers/usb/host/pci-quirks.c
Greg KH schrieb:
> On Thu, Aug 02, 2007 at 10:32:21AM -0400, Alan Stern wrote:
>
>> On Thu, 2 Aug 2007, David Engraf wrote:
>>
>>
>>> This would be solution too, but what if someone uses the uhci controller
>>> and don't want the
>>&g
Alan Stern schrieb:
> On Wed, 1 Aug 2007, David Engraf wrote:
>
>
>> At the moment I have a Jetway/VIA Mainboard which seems to have a problem
>> with the handoff. Even
>> when I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not cleared.
>> I think
Greg KH schrieb:
> On Wed, Aug 01, 2007 at 09:21:12AM +0200, David Engraf wrote:
>
>> At the moment I have a Jetway/VIA Mainboard which seems to have a
>> problem with the handoff.
>> Evenwhen I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not
>> c
in my kernel, so I
think the kernel shouldn't take the
handover for the EHCI controller like other OS which do not have an usb
driver and so don't know that
there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.
David Engraf
Alan Stern schrieb:
> On Tue, 31 Jul 2007,
;class == PCI_CLASS_SERIAL_USB_EHCI)
+#endif
+
+#ifdef CONFIG_USB_EHCI_HCD
+if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
quirk_usb_disable_ehci(pdev);
+#endif
}
DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);
Thanks
David Engraf
Netcom Sicherheitstechn
38 matches
Mail list logo
