Re: [PATCH] Fix x509_key_preparse() not to reject keys outside their validity time range

Am 14.03.2013 13:24, schrieb David Woodhouse: The x509_key_preparse() function will refuse to even *parse* a certificate when the system clock happens to be set to a time before the ValidFrom or after the ValidTo date. This is wrong. If date checks are to be done, they need to be done at the tim

Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

Am 04.02.2013 02:14, schrieb Greg KH: So you are right in that your driver will wait for forever for a disconnect() to happen, as it will never be called. I don't understand the problem that this is causing when it happens. What's wrong with udlfb that having the cpu suddently reset as the pow

Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

Am 04.02.2013 13:05, schrieb Alexander Holler: Am 04.02.2013 02:14, schrieb Greg KH: So you are right in that your driver will wait for forever for a disconnect() to happen, as it will never be called. I don't understand the problem that this is causing when it happens. What's

Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

Am 04.02.2013 20:25, schrieb Greg KH: > On Mon, Feb 04, 2013 at 08:17:04PM +0100, Alexander Holler wrote: >> Am 04.02.2013 13:05, schrieb Alexander Holler: >>> Am 04.02.2013 02:14, schrieb Greg KH: >>> >>>> So you are right in that your driver will wait

Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

Am 05.02.2013 18:22, schrieb Greg KH: On Tue, Feb 05, 2013 at 08:08:28AM +0100, Alexander Holler wrote: Am 04.02.2013 20:25, schrieb Greg KH: Where was that urb when the disconnect happened? The USB core should call your urb callback for any outstanding urbs at that point in time, with the

MODSIGN without RTC?

Hello, I wanted to try out MODSIGN with kernel 3.7.6 and I've just got hit by: [1.346445] X.509: Cert 6a23533cec71c4c52a1618fb4d830e06aa90474e is not yet valid The reason is likely that the (ARM) device in question doesn't have a RTC (oh, that topic again ;) ) and gets it's time on boot

Re: MODSIGN without RTC?

Am 07.02.2013 00:42, schrieb Alexander Holler: Hello, I wanted to try out MODSIGN with kernel 3.7.6 and I've just got hit by: [1.346445] X.509: Cert 6a23533cec71c4c52a1618fb4d830e06aa90474e is not yet valid The reason is likely that the (ARM) device in question doesn't have

Re: MODSIGN without RTC?

Am 07.02.2013 07:42, schrieb Geert Uytterhoeven: > On Thu, Feb 7, 2013 at 2:06 AM, Alexander Holler wrote: >> Am 07.02.2013 00:42, schrieb Alexander Holler: >>> I wanted to try out MODSIGN with kernel 3.7.6 and I've just got hit by: >>>

Re: MODSIGN without RTC?

Am 07.02.2013 08:01, schrieb Alexander Holler: Am 07.02.2013 07:42, schrieb Geert Uytterhoeven: On Thu, Feb 7, 2013 at 2:06 AM, Alexander Holler wrote: Am 07.02.2013 00:42, schrieb Alexander Holler: I wanted to try out MODSIGN with kernel 3.7.6 and I've just got hit by: [1.346445]

Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

Am 08.02.2013 05:07, schrieb Dave Airlie: But I've just switched to udl (instead of udlfb) and will see if I can fix the bugs there to make it usable as a console. udl is a rewrite of udlfb with some additional features (e.g. drm), so hopefully fixing the remaining problems there will require le

Re: MODSIGN without RTC?

Am 07.02.2013 19:44, schrieb Olaf Titz: Another option would be to make a configure option to just ignore the date. I'm not sure if I would like to use MODSIGN when I have to fear that the machine wouldn't start when the RTC fails or got set to a wrong date. Or just ignore the date unconditiona

Re: MODSIGN without RTC?

Am 11.02.2013 20:44, schrieb Alexander Holler: Am 07.02.2013 19:44, schrieb Olaf Titz: Another option would be to make a configure option to just ignore the date. I'm not sure if I would like to use MODSIGN when I have to fear that the machine wouldn't start when the RTC fails or go

[PATCH] rtc: rtc-hid-sensor-time: allow full years (16bit) in HID reports

value is 16 bits wide. We will still support 8 bit values until the specification gets final (and maybe defines a way to set the time too). Signed-off-by: Alexander Holler --- drivers/rtc/rtc-hid-sensor-time.c | 33 ++--- 1 file changed, 26 insertions(+), 7 dele

Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

Am 29.01.2013 01:22, schrieb Andrew Morton: > On Fri, 25 Jan 2013 19:49:27 +0100 > Alexander Holler wrote: > >> When a device was disconnected the driver may hang at waiting for urbs it >> never >> will get. Fix this by using a timeout while waiting for the used sema

Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

Am 29.01.2013 01:56, schrieb Alexander Holler: Am 29.01.2013 01:22, schrieb Andrew Morton: On Fri, 25 Jan 2013 19:49:27 +0100 Alexander Holler wrote: When a device was disconnected the driver may hang at waiting for urbs it never will get. Fix this by using a timeout while waiting for the

Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

Am 29.01.2013 11:35, schrieb Alexander Holler: Am 29.01.2013 01:56, schrieb Alexander Holler: Am 29.01.2013 01:22, schrieb Andrew Morton: On Fri, 25 Jan 2013 19:49:27 +0100 Alexander Holler wrote: When a device was disconnected the driver may hang at waiting for urbs it never will get. Fix

Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

Am 29.01.2013 12:11, schrieb Alexander Holler: To explain the problem on shutdown a bit further, I think the following happens (usb and driver are statically linked and started by the kernel): shutdown -> kill signal -> usb stack shuts down -> udlfb waits (forever) for a kill or an

Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

Am 29.01.2013 16:51, schrieb Alexander Holler: Am 29.01.2013 12:11, schrieb Alexander Holler: To explain the problem on shutdown a bit further, I think the following happens (usb and driver are statically linked and started by the kernel): shutdown -> kill signal -> usb stack shut

Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

Am 29.01.2013 21:35, schrieb Alexander Holler: So, if the above down_timeout_killable() is only down_interruptible(), as in kernel 3.7.5, the box would not shutdown afterwards, because on shutdown no signal would be send to that kernel-thread which called dlfb_free_urb_list(). A last note

[PATCH 1/3] semaphore: introduce down_timeout_killable()

The name says it all, it's like down_timeout() but returns on fatal signals too. Signed-off-by: Alexander Holler --- include/linux/semaphore.h | 2 ++ kernel/semaphore.c| 37 + 2 files changed, 39 insertions(+) diff --git a/include/linux/semaph

[PATCH 2/3 v2] fb: udlfb: fix hang at disconnect

: Alexander Holler --- drivers/video/udlfb.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c index 86d449e..db6cc66 100644 --- a/drivers/video/udlfb.c +++ b/drivers/video/udlfb.c @@ -1832,8 +1832,9 @@ static void dlfb_free_urb_list

[PATCH 3/3] fb: smscufx: fix hang at disconnect

: Alexander Holler --- drivers/video/smscufx.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c index 97bd662..f26fa4f 100644 --- a/drivers/video/smscufx.c +++ b/drivers/video/smscufx.c @@ -1838,8 +1838,9 @@ static void

[PATCH 0/3] Include kernel config by default

Hello, I've seen too many systems where the config to build the used kernel got lost and people were unable to diagnose problems or to rebuild a modified or updated kernel. It's a subject which worries me since several years. Therefor I finally prepared the following patch(es) to include the conf

[PATCH 1/3] Include kernel config by default

the kernel. Therefor include the used configuration by default (e.g. to extract it using scripts/extract-ikconfig) and make it available through /proc/config.gz. Signed-off-by: Alexander Holler --- init/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/init/Kconfig b/init/Kconfig

[PATCH 2/3] Show option to not include kernel configuration only for embedded systems

The included kernel configuration only consumes a few kb. In order to prevent premature optimization, show the the option for not including the kernel configuration only for embedded systems. Signed-off-by: Alexander Holler --- init/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions

Re: [PATCH 0/3] Include kernel config by default

Am 26.01.2013 14:34, schrieb Alexander Holler: Hello, I've seen too many systems where the config to build the used kernel got lost and people were unable to diagnose problems or to rebuild a modified or updated kernel. It's a subject which worries me since several years. Therefor

Re: Disable IPv4-mapped - enforce IPV6_V6ONLY

Am 22.02.2013 16:21, schrieb Alexander Holler: Hello, I'm searching for a way to either enforce IPV6_V6ONLY or to block IPv4-mapped addresses on ipv6-sockets (e.g. by using iptables) system-wide. E.g. net.ipv6.bindv6only doesn't help if something calls int v6on = 0; set

Re: Disable IPv4-mapped - enforce IPV6_V6ONLY

Am 25.02.2013 14:23, schrieb David Laight: A proper solution would be to either return false if net.ipv6.bindv6only is true and optval is false (which would break downward compatibility because it wouldn't just be a default and setsockopt might return an error) or to introduce a new sysctl var

[PATCH] crypto: Ignore validity dates of X.509 certificates by default

ff-by: Alexander Holler --- crypto/asymmetric_keys/Kconfig | 10 ++ crypto/asymmetric_keys/x509_public_key.c | 4 2 files changed, 14 insertions(+) diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig index 6d2c2ea..333976f 100644 --- a/crypto/asymmetric

Re: [GIT PULL] Load keys from signed PE binaries

Am 27.02.2013 11:17, schrieb James Courtier-Dutton: 3) Trust based on date. I trust everything from X that I put on my system 2 weeks ago, but one week ago X got hacked, so don't trust anything new from them until the hack has been stopped and the revokation/correction steps have been completed.

What is tip-bot?

Hello, until now I could successfully suppress my curiosity about those tip:foo messages, but as the bot (or one of them) has now catched me too, I want to ask what it is. Searching for "tip(-)bot" or similiar doesn't reveal some useful info (for obvious reasons). Could someone give me an UR

Re: What is tip-bot?

Am 19.02.2013 10:54, schrieb richard -rw- weinberger: On Tue, Feb 19, 2013 at 10:40 AM, Alexander Holler wrote: Hello, until now I could successfully suppress my curiosity about those tip:foo messages, but as the bot (or one of them) has now catched me too, I want to ask what it is

Re: What is tip-bot?

Am 19.02.2013 23:54, schrieb Randy Dunlap: On 02/19/2013 02:36 AM, Alexander Holler wrote: Am 19.02.2013 10:54, schrieb richard -rw- weinberger: On Tue, Feb 19, 2013 at 10:40 AM, Alexander Holler wrote: Hello, until now I could successfully suppress my curiosity about those tip:foo messages

Re: [PATCH 3/3] HID: sensor-hub: don't limit the driver only to USB bus

Am 21.02.2013 11:34, schrieb Benjamin Tissoires: Hi, Sorry for coming this late in the discussion (I was sick at the beginning of the week, preventing me to answer mails). On Mon, Feb 18, 2013 at 1:13 PM, Alexander Holler wrote: Hmm, what happens with Bluetooth sensor-hubs? Is the driver now

Re: [PATCH] mv643xx_eth: Fix a possible deadlock upon ifdown

Am 12.03.2013 10:04, schrieb Alexander Holler: I don't think so. Internally the driver calls mv643xx_eth_stop() therefore lockdep issues almost the same warning as when the interface is shut down (see below). And reading the code, I haven't seen how a Btw. I consider the shutd

Re: [PATCH] X.509: Remove certificate date checks

Am 14.03.2013 13:48, schrieb David Woodhouse: On Thu, 2013-03-14 at 12:34 +, David Howells wrote: Remove the certificate date checks that are performed when a certificate is parsed. There are two checks: a valid from and a valid to. The first check is causing a lot of problems with system

Re: [PATCH] X.509: Remove certificate date checks

Am 14.03.2013 18:09, schrieb David Woodhouse: On Thu, 2013-03-14 at 17:22 +0100, Alexander Holler wrote: Agreed (thats what my patch did). I've introduced a new config option because I don't know if something (a use case I don't know) relies on the validity check of the date

kernel BUG at fs/buffer.c:3205 (stable 3.5.3)

Hello, I'm currently experiencing some major problems trying to do a full backup. I've recently added an USB 3.0 card to my system and now it seems my full-backup routine evolved to a stress test. ;) What I'm doing is either tar cp . | mbuffer | bzip2smp >foo.tar.bz2 or dd if=/dev/sdaN bs=

Re: kernel BUG at fs/buffer.c:3205 (stable 3.5.3)

Am 01.10.2012 11:21, schrieb Alexander Holler: Hello, Am 01.10.2012 11:10, schrieb Jan Kara: sha1sum Tainted: P O 3.5.4-9-gfa43f23-dirty #228 BTW, fglrx moodule taints the kernel because it is a proprietary driver. I know. Can you reproduce the issue without this module

AMD A10: MCE Instruction Cache Error

Hello, I've just got the following on an AMD A10 5800K: -- [ 8395.999581] [Hardware Error]: CPU:0 MC1_STATUS[-|CE|MiscV|-|AddrV|-|-]: 0x8c210151 [ 8395.999586] [Hardware Error]:MC1_ADDR: 0xa00e1203 [ 8395.999588] [Hardware Error]: Instruction Cache Error: Parity err

Re: AMD A10: MCE Instruction Cache Error

Am 02.11.2012 11:50, schrieb Alexander Holler: Hello, I've just got the following on an AMD A10 5800K: -- [ 8395.999581] [Hardware Error]: CPU:0 MC1_STATUS[-|CE|MiscV|-|AddrV|-|-]: 0x8c210151 [ 8395.999586] [Hardware Error]:MC1_ADDR: 0xa00e1203 [ 8395.9

Re: AMD A10: MCE Instruction Cache Error

Am 03.11.2012 05:49, schrieb Borislav Petkov: On Fri, Nov 02, 2012 at 02:53:45PM +0100, Alexander Holler wrote: Am 02.11.2012 11:50, schrieb Alexander Holler: Hello, I've just got the following on an AMD A10 5800K: -- [ 8395.999581] [Hardware Error]: CPU:0 MC1_STATUS[-|CE|MiscV|-|

Re: AMD A10: MCE Instruction Cache Error

Am 04.11.2012 16:21, schrieb Borislav Petkov: On Sat, Nov 03, 2012 at 11:45:25AM +0100, Alexander Holler wrote: Hmm, exactly that just happened twice in a row. Unfortunately the screen was already disabled (screen saving mode), so I couldn't see any message, if there was any. Just a dea

connector and netlink_broadcast (semop failed for cookie ...)

Hello, I've recently enabled CONFIG_CONNECTOR in kernel 3.6.6 and now I've got the message "semop failed for cookie ..." when using cryptsetup (I've never got that error before). A short search revealed the following discussion about ignoring errors from netlink_broadcast_filtered(): https:/

Re: [PATCH] video/smscufx: fix line counting in fb_write

Hello, Am 26.07.2012 19:26, schrieb Florian Tobias Schandinat: Well, as this patch fixes a bug I applied it as is. Thanks a lot, actually I was more interested to get that one-line-patch for udlfb, because I've discovered that bug using one of those Mimo-LCDs. ;) Are you responsible for th

x86: Regression in 3.6.4, bisected to "Exclude E820_RESERVED regions..."

Hello, I've just bisected a problem with 3.6.4. I had to revert commit 54ce8ce298f382a06186cb4672ad6aa090b050b6 (1e779aabe1f0768c2bf8f8c0a5583679b54a in mainline), otherwise my box didn't boot. I can't provide any output, because I don't see if that commit is applied. ;) Here is the s

Re: x86: Regression in 3.6.4, bisected to "Exclude E820_RESERVED regions..."

Am 29.10.2012 11:22, schrieb Alexander Holler: Hello, I've just bisected a problem with 3.6.4. I had to revert commit 54ce8ce298f382a06186cb4672ad6aa090b050b6 (1e779aabe1f0768c2bf8f8c0a5583679b54a in mainline), otherwise my box didn't boot. I can't provide any output, beca

Re: x86: Regression in 3.6.4, bisected to "Exclude E820_RESERVED regions..."

Am 29.10.2012 17:59, schrieb Greg Kroah-Hartman: On Mon, Oct 29, 2012 at 02:19:32PM +0100, Alexander Holler wrote: Am 29.10.2012 11:22, schrieb Alexander Holler: Hello, I've just bisected a problem with 3.6.4. I had to revert commit 54ce8ce298f382a06186cb4672ad6aa090b

Re: x86: Regression in 3.6.4, bisected to "Exclude E820_RESERVED regions..."

Am 29.10.2012 19:32, schrieb Greg Kroah-Hartman: On Mon, Oct 29, 2012 at 07:10:39PM +0100, Alexander Holler wrote: Am 29.10.2012 17:59, schrieb Greg Kroah-Hartman: On Mon, Oct 29, 2012 at 02:19:32PM +0100, Alexander Holler wrote: Am 29.10.2012 11:22, schrieb Alexander Holler: Hello, I&#x

Re: x86: Regression in 3.6.4, bisected to "Exclude E820_RESERVED regions..."

Am 30.10.2012 00:01, schrieb Greg Kroah-Hartman: Can you test out 3.6.5-rc1 and see if that works properly for you or not? It should have all of the fixes in it already. Just in time before I receive my new "memory layout" which might not have the problem with 3.6.4. ;) 3.6.5-rc1 booted ju

[PATCH 2/2] rtc: rtc-hid-sensor-time: enable HID input processing early

Enable the processing of HID input records before the RTC will be registered, in order to allow the RTC register function to read clock. Without doing that the clock can only be read after the probe function has finished. Signed-off-by: Alexander Holler --- drivers/rtc/rtc-hid-sensor-time.c | 7

[PATCH 1/2] rtc: rtc-hid-sensor-time: improve error handling when rtc register fails

Stop processing hid input when registering the RTC fails and handle a NULL returned from devm_rtc_device_register() as a failure too. Signed-off-by: Alexander Holler --- drivers/rtc/rtc-hid-sensor-time.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc

[PATCH 0/2] rtc: rtc-hid-sensor-time: enable HID input processing early

nged such, that combining them into just one patch doesn't make sense anymore. Regards, Alexander Holler -- 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

[PATCH] rtc: rtc-hid-sensor-time: add module alias to let the module load automatically

In order to get the module automatically loaded by hotplug mechanisms a MODULE_DEVICE_TABLE is needed. Therefor add one. This makes it also possible to use a module name other than HID-SENSOR-2000a0 which isn't very descriptive in kernel messages. Signed-off-by: Alexander Holler --- dr

[PATCH 0/4] iio: hid-sensor: add module alias for autoload

e to use a normale driver name. Therefor I've changed all driver names to KBUILD_MODNAME instead of HID-SENSOR-2000xx as the later isn't very descriptive when starring at kernel messages. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux

[PATCH 1/4] iio: hid-sensor-accel-3d: add module alias for autoload

Add a MODULE_DEVICE_TABLE in order to let hotplug mechanisms automatically load the driver. This makes it also possible to use the usual driver name instead of HID-SENSOR-2000xx which isn't very descriptive in kernel messages. Signed-off-by: Alexander Holler --- drivers/iio/accel/hid-s

[PATCH 4/4] iio: hid-sensor-magn-3d: add module alias for autoload

Add a MODULE_DEVICE_TABLE in order to let hotplug mechanisms automatically load the driver. This makes it also possible to use the usual driver name instead of HID-SENSOR-2000xx which isn't very descriptive in kernel messages. Signed-off-by: Alexander Holler --- drivers/iio/magnetomete

[PATCH 2/4] iio: hid-sensor-gyro-3d: add module alias for autoload

Add a MODULE_DEVICE_TABLE in order to let hotplug mechanisms automatically load the driver. This makes it also possible to use the usual driver name instead of HID-SENSOR-2000xx which isn't very descriptive in kernel messages. Signed-off-by: Alexander Holler --- drivers/iio/gyro/hid-s

[PATCH 3/4] iio: hid-sensor-als: add module alias for autoload

Add a MODULE_DEVICE_TABLE in order to let hotplug mechanisms automatically load the driver. This makes it also possible to use the usual driver name instead of HID-SENSOR-2000xx which isn't very descriptive in kernel messages. Signed-off-by: Alexander Holler --- drivers/iio/light/hid-s

Re: [PATCH 0/4] iio: hid-sensor: add module alias for autoload

tc0 instead of the above with the descriptive rtc_hid_sensor_time. Automatic loading of modules works too and it works on ARM, Intel and AMD as module or static linked. ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body o

Re: [PATCH 0/4] iio: hid-sensor: add module alias for autoload

Am 11.07.2013 19:27, schrieb Srinivas Pandruvada: On 07/10/2013 08:58 AM, Alexander Holler wrote: Am 10.07.2013 17:27, schrieb Srinivas Pandruvada: Hi, There was no intention to prevent auto loading. Did you get chance to test these changes? Sure, I always test patches before I send them

Re: "Virtual" Interrupts -- Need help please

make such impossible. So the correct behaviour is to not hard break lines on the sender side and leave that to the reader on the receiving side, as only the receiving side knows the line width. Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu

Re: "Virtual" Interrupts -- Need help please

Am 09.09.2013 13:45, schrieb Guenter Roeck: On 09/09/2013 04:18 AM, Alexander Holler wrote: Am 09.09.2013 13:02, schrieb Mark Brown: On Sun, Sep 08, 2013 at 05:35:56PM -0700, Guenter Roeck wrote: Please fix your mailer to word wrap within paragraphs, not doing this makes your mail very hard

Re: "Virtual" Interrupts -- Need help please

Am 09.09.2013 15:45, schrieb Mark Brown: > On Mon, Sep 09, 2013 at 01:18:01PM +0200, Alexander Holler wrote: >> Am 09.09.2013 13:02, schrieb Mark Brown: > >>> makes your mail very hard to read. It looks like your mailer has also >>> reflowed Daniel's mail. &g

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

he none-dt case. Regards, Alexander Holler -- 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/

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

Am 11.09.2013 09:05, schrieb Alexander Holler: Am 10.09.2013 17:00, schrieb Joel Fernandes: I think your initial patch is much better than fixing up DT but then I may be missing other problems with your patch that Linus's patch addresses. The initial patch had the problem that it not

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

And another small update. ;) Am 11.09.2013 09:16, schrieb Alexander Holler: To summarize what happens if a driver uses a gpio as irq: gpio_request() // This works only if the gpio was not requested before gpio_direction_input() gpio_to_irq() // This needs an irq-mapping request_threaded_irq

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

Am 11.09.2013 09:30, schrieb Alexander Holler: And another small update. ;) Am 11.09.2013 09:16, schrieb Alexander Holler: To summarize what happens if a driver uses a gpio as irq: gpio_request() // This works only if the gpio was not requested before gpio_direction_input() gpio_to_irq

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

T at all? And how will this be done? I found the way it was done in the reverted patch very confusing because it needed an IRQ number. That IRQ number depends on the mapping and isn't hw specific (and currently just human doable because of the simple mapping). Regards, Alexander Holler -- To

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

Am 11.09.2013 18:14, schrieb Javier Martinez Canillas: On 09/11/2013 05:30 PM, Alexander Holler wrote: Am 22.08.2013 00:02, schrieb Linus Walleij: On Tue, Aug 20, 2013 at 12:04 AM, Laurent Pinchart wrote: On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote: I don't see how sh

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

Am 11.09.2013 19:42, schrieb Alexander Holler: > Am 11.09.2013 18:14, schrieb Javier Martinez Canillas: >> So for example in an OMAP board DT you can define something like this: >> >> ethernet@5,0 { >> compatible = "smsc,lan9221", "smsc,lan911

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

Am 12.09.2013 12:11, schrieb Javier Martinez Canillas: On 09/12/2013 10:55 AM, Alexander Holler wrote: ... By the way, how do you define two GPIOs/IRQs from different gpio-banks/irq-controllers wuth that scheme? That is indeed a very good question and I don't have a definite a

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

Am 12.09.2013 12:28, schrieb Alexander Holler: Am 12.09.2013 12:11, schrieb Javier Martinez Canillas: On 09/12/2013 10:55 AM, Alexander Holler wrote: ... By the way, how do you define two GPIOs/IRQs from different gpio-banks/irq-controllers wuth that scheme? That is indeed a very good

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

Am 12.09.2013 13:09, schrieb Alexander Holler: Am 12.09.2013 12:28, schrieb Alexander Holler: Am 12.09.2013 12:11, schrieb Javier Martinez Canillas: On 09/12/2013 10:55 AM, Alexander Holler wrote: ... By the way, how do you define two GPIOs/IRQs from different gpio-banks/irq-controllers

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

Am 12.09.2013 13:26, schrieb Alexander Holler: Am 12.09.2013 13:09, schrieb Alexander Holler: Am 12.09.2013 12:28, schrieb Alexander Holler: Am 12.09.2013 12:11, schrieb Javier Martinez Canillas: On 09/12/2013 10:55 AM, Alexander Holler wrote: ... So, if I understood the code correctly

Re: [PATCH] RFC: interrupt consistency check for OF GPIO IRQs

hat a mess. I assume that is the price that bindings don't have to change. Thanks for clarifying that, Alexander Holler -- 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/

Re: checkpatch guide for newbies

Am 26.09.2013 04:11, schrieb Al Viro: > On Wed, Sep 25, 2013 at 12:10:57AM +0200, Alexander Holler wrote: > >> Sure and I'm the last one who wants that people do have to use >> anything else than i for simple loop counters. And allowing longer >> lines doesn't

Re: checkpatch guide for newbies

Am 26.09.2013 04:52, schrieb Alexander Holler: > I'm aware of people which do nest 8 levels deep just to avoid a return, > break or goto. > > But trying to limit that by limiting the line length is like ... > (choose your own own misguided comparison, it's too late

Re: checkpatch guide for newbies

Am 26.09.2013 05:04, schrieb Al Viro: On Thu, Sep 26, 2013 at 04:57:32AM +0200, Alexander Holler wrote: Am 26.09.2013 04:52, schrieb Alexander Holler: I'm aware of people which do nest 8 levels deep just to avoid a return, break or goto. But trying to limit that by limiting the line l

Re: checkpatch guide for newbies

Am 26.09.2013 05:48, schrieb Al Viro: On Thu, Sep 26, 2013 at 05:27:15AM +0200, Alexander Holler wrote: Oh, personally I don't have any limit there. ;) I like descriptive function and variable names whenever they make sense. And often they make comments uneccessary and therefor prevent e

Re: checkpatch guide for newbies

if there is any. ;) > lot of information into a variable name is not always so successful... > Actually, I really appreciate comments on functions, that explain the > purpose of the function, and the constraints on its usage. I didn't want do suggest getting rid of (ne

Re: [PATCH] add exFAT driver

pic after I received your private mail. And third, "the fuck" just describes the topic perfectly. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo i

Re: checkpatch guide for newbies

or to type less when reading linux kernel code. Regards, Alexander Holler -- 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 t

Re: checkpatch guide for newbies

Am 24.09.2013 19:26, schrieb Alexander Holler: Am 24.09.2013 18:36, schrieb Bjorn Helgaas: On Mon, Sep 23, 2013 at 3:01 AM, Dan Carpenter wrote: Long Lines Historically screens were 80 characters wide and it was annoying when code went over the edge. These days we have

Re: checkpatch guide for newbies

Am 24.09.2013 19:43, schrieb Alexander Holler: Am 24.09.2013 19:26, schrieb Alexander Holler: Am 24.09.2013 18:36, schrieb Bjorn Helgaas: On Mon, Sep 23, 2013 at 3:01 AM, Dan Carpenter wrote: Long Lines Historically screens were 80 characters wide and it was annoying when

Re: checkpatch guide for newbies

Am 24.09.2013 22:13, schrieb Bjorn Helgaas: On Tue, Sep 24, 2013 at 1:29 PM, Peter Senna Tschudin wrote: On Tue, Sep 24, 2013 at 7:26 PM, Alexander Holler wrote: On Mon, Sep 23, 2013 at 3:01 AM, Dan Carpenter wrote: Long Lines Historically screens were 80 characters

Re: [PATCH] X.509: Remove validity check of certificate date

r some unspoken reason it always got ignored. It would make wonder if it would be accepted this time, just because of another author name. Regards, Alexander Holler Am 25.09.2013 08:20, schrieb Lee, Chun-Yi: The check of valid_from and valid_to fields on X.509 certificate is a time bomb to MODSI

Re: [PATCH] checkpatch: Find CamelCase definitions of struct/union/enum

e their uses in cases like e.g. fs/binfmt_misc.c Besides that CamelCase is one character less long than camel_case. I'm awaiting kernel developer uniforms. There are too many different black t-shirts around. ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line &qu

Re: [PATCH] add exFAT driver

this for years, nothing new here at all. Maybe a silly question, but isn't exFAT protected by some MS owned patents which might drive Linux users into the hand of MS lawyers as already happened with FAT? It would make me wonder if not. Maybe you could ask Samsung about that too, when you are

Re: [PATCH] checkpatch: Find CamelCase definitions of struct/union/enum

ch.pl, usally get a full stop at the first barrier. Regards, Alexander Holler -- 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 t

Re: [PATCH] add exFAT driver

Am 25.09.2013 22:21, schrieb Greg Kroah-Hartman: On Wed, Sep 25, 2013 at 09:28:56PM +0200, Alexander Holler wrote: Maybe a silly question, but isn't exFAT protected by some MS owned patents which might drive Linux users into the hand of MS lawyers as already happened with FAT? It would

Re: [PATCH] add exFAT driver

Am 25.09.2013 23:44, schrieb Anton Altaparmakov: > Hi, > > On 25 Sep 2013, at 21:21, Greg Kroah-Hartman > wrote: >> On Wed, Sep 25, 2013 at 09:28:56PM +0200, Alexander Holler wrote: >>> >>> Maybe a silly question, but isn't exFAT protected by some MS

Re: [PATCH] add exFAT driver

ies into the ground because most of them are unable to even think about having the money needed to talk with Microsoft lawyers in front of a court. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to m

Re: [PATCH 4/9] ARM: export default read_current_timer

Am 09.10.2012 18:06, schrieb Russell King - ARM Linux: On Tue, Oct 09, 2012 at 04:40:54PM +0100, Jonathan Austin wrote: Hi Arnd, On 09/10/12 16:22, Arnd Bergmann wrote: diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c index 9d0a300..0dc5385 100644 --- a/arch/arm/lib/delay.c +++ b/arch/

[PATCH 1/2 RESEND RFC] Make IKCONFIG an embedded option, enabled by default

rnels. Signed-off-by: Alexander Holler --- init/Kconfig | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 6fdd6e3..add21a3 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -658,7 +658,8 @@ config RCU_BOOST_DELAY endmenu # "RCU Subsystem&

Re: "read_current_timer" undefined!

9/393 If you need a patch for 3.6, here is what I did before I found the above thread: -- From a026451fdc98a5981e10a18ffa394e53a40b0691 Mon Sep 17 00:00:00 2001 From: Alexander Holler Date: Thu, 18 Oct 2012 07:29:39 +0200 Subject: [PATCH] arm: arch timer: expor

Re: RFC: sign the modules at install time

Am 19.10.2012 13:25, schrieb David Howells: Stephen Rothwell wrote: So, this still generates the keys during the normal build, right? That would be a problem for build servers that have limited randomness available to them, I think. openssl uses /dev/urandom (unlike gpg), so that's less of

Re: [BUGFIX PATCH] rtc: eliminate extra call of ida_simple_remove()

rtc_device_unregister() and only call the function in rtc_device_release(). Signed-off-by: Lothar Waßmann I've just discovered the same problem. Although I've removed the call to ida_simple_remove() in rtc_device_release() (for symmetry of register/unregister) I can offer a Signed-off-by: Alexander

[PATCH 1/2] HID: autodetect HID sensor hubs.

blacklist might be created. Signed-off-by: Alexander Holler --- drivers/hid/hid-core.c | 10 +- drivers/hid/hid-sensor-hub.c | 32 +--- include/linux/hid-sensor-ids.h |1 - include/linux/hid.h|2 ++ 4 files changed, 12 insertions

[PATCH 2/2] Revert "HID: sensors: add to special driver list"

Those IDs aren't necessary anymore. This reverts commit c8147d9ea19bfe7d8e569351bc7239e118dd6997. Signed-off-by: Alexander Holler --- drivers/hid/hid-core.c |5 - drivers/hid/hid-ids.h |6 -- 2 files changed, 0 insertions(+), 11 deletions(-) diff --git a/drivers/hi

  1   2   3   4   5   6   7   8   >