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 time the cert is *used*. It should be perfectly possible to load a
cert which is post-dated, and can only be used for validation at some
point in the future. The key in question should immediately start
working at its ValidFrom date, and stop again at its ValidTo date. It
should be allowed to *exist* in the kernel both before and after those
times.
On systems where the hardware clock is inaccurate (a common occurrence
and one which doesn't even get noticed when you use NTP or something
else to fix it during the boot sequence), this was preventing the module
signing cert from being loaded during boot. When the clock got fixed
later on in he boot sequence, things *should* have started working. But
they didn't...
Signed-off-by: David Woodhouse
---
Arguably, for the specific case of module signing we shouldn't bother
checking for a current time before the ValidFrom date *at all*. It's
*always* going to be a screwed up system clock, because we don't have a
usage model of post-dating module signatures. We should simply document
that the date is *not* checked for module signing, and have done with
it. But that's a separate issue.
diff --git a/crypto/asymmetric_keys/x509_public_key.c
b/crypto/asymmetric_keys/x509_public_key.c
index 06007f0..326dc80 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -154,8 +154,6 @@ static int x509_key_preparse(struct key_preparsed_payload
*prep)
(now.tm_sec < cert->valid_from.tm_sec
))) {
pr_warn("Cert %s is not yet valid\n", cert->fingerprint);
- ret = -EKEYREJECTED;
- goto error_free_cert;
}
if (now.tm_year > cert->valid_to.tm_year ||
(now.tm_year == cert->valid_to.tm_year &&
@@ -170,8 +168,6 @@ static int x509_key_preparse(struct key_preparsed_payload
*prep)
(now.tm_sec > cert->valid_to.tm_sec
))) {
pr_warn("Cert %s has expired\n", cert->fingerprint);
- ret = -EKEYEXPIRED;
- goto error_free_cert;
}
cert->pub->algo = x509_public_key_algorithms[cert->pkey_algo];
Why not remove the check and warning there too?
Regards,
Alexander
--
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 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 powerdown happened without it knowing about it? There is nothing wrong with that. I've just explained why a problem doesn't occur on shutdown but on disconnect (of the device). Regards, Alexander -- 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 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 wrong with udlfb that having the cpu suddently reset as the powerdown happened without it knowing about it? There is nothing wrong with that. I've just explained why a problem doesn't occur on shutdown but on disconnect (of the device). Maybe my explanation before was just to long and I try to explain it a bit shorter: If a device gets disconnected, the disconnect in udlfb might wait forever in down_interruptible() (because it waits for an urb it never receives). This even prevents a shutdown afterwards, because that down_interruptible() never receives a signal (at shutdown, because kernel threads don't get such). So the change from down_timeout() to down_interruptible() in dlfb_free_urb_list() with commit 33077b8d3042e01da61924973e372abe589ba297 only results in that the following code (thus the break there) will never be reached if an urb got missed (because of a disconnect). And the accompanying comment (... at shutdown) is misleading, because on shutdown, the kernel thread which calls dlfb_free_urb_list() never gets a signal, so the interruption just never happens. As I've experienced the "missing urb on disconnect" problem quiet often, I've changed that down_interruptible() to down_timeout() (in v1 and in v2 to down_timeout_interruptible, because I wasn't aware that no signal arrives on shutdown). Hmm, ok, that explanation isn't much shorter. ;) Regards, Alexander -- 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 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 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 powerdown happened >>>> without it knowing about it? >>> >>> There is nothing wrong with that. I've just explained why a problem >>> doesn't occur on shutdown but on disconnect (of the device). >> >> Maybe my explanation before was just to long and I try to explain it >> a bit shorter: >> >> If a device gets disconnected, the disconnect in udlfb might wait >> forever in down_interruptible() (because it waits for an urb it >> never receives). This even prevents a shutdown afterwards, because >> that down_interruptible() never receives a signal (at shutdown, >> because kernel threads don't get such). > > 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 proper error flag being set, are you handling that properly? I don't know where that urb is as I don't handle it. I just know that _interruptible doesn't make any sense and _timeout is necessary here. But as nobody else seems to have a problem, nobody else see seems to see the problem there and I seem to be unable to explain it, just ignore that patch. Regards, Alexander -- 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 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 proper error flag being set, are you handling that properly? I don't know where that urb is as I don't handle it. What do you mean by that? The urb is being sent back to your driver, right? If not, that's a bug, but please be sure that your urb callback isn't really being called. I meant it isn't _my_ driver. ;) I'm just trying to add some würgarounds without having the need to rewrite the whole driver. In regard to that "urb missing problem", I think I've just named it wrong and the actual problem is a race-condition between the semaphore handling (which is used to keep track of the urbs) and the urb handling inside the driver. 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 less work. Regards, Alexander -- 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/
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 through NTP. The used certificate was generated automatically. Having a look at it, the following is shown: Validity Not Before: Feb 6 02:56:46 2013 GMT Not After : Jan 13 02:56:46 2113 GMT Without having thought about possible security problems, my first idea would be to let the validity start at 1970. As I never did such I never had thought about possible implications when doing such (e.g. I don't know if someone checks the start date for plausabilitiy) Another solution would be to retry loading of the certificate if the time gets set (and e.g. differs more than a year). Has someone already thought about how to solve that problem? Or did everyone use sane systems which have a (working) RTC? Regards, Alexander -- 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: 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 a RTC (oh, that topic again ;) ) and gets it's time on boot through NTP. The used certificate was generated automatically. Having a look at it, the following is shown: Validity Not Before: Feb 6 02:56:46 2013 GMT Not After : Jan 13 02:56:46 2113 GMT Without having thought about possible security problems, my first idea would be to let the validity start at 1970. As I never did such I never had thought about possible implications when doing such (e.g. I don't know if someone checks the start date for plausabilitiy) Another solution would be to retry loading of the certificate if the time gets set (and e.g. differs more than a year). Has someone already thought about how to solve that problem? Or did everyone use sane systems which have a (working) RTC? 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. Regards, Alexander -- 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: 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: >>> >>> [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 through NTP. >>> >>> The used certificate was generated automatically. Having a look at it, >>> the following is shown: >>> >>> Validity >>> Not Before: Feb 6 02:56:46 2013 GMT >>> Not After : Jan 13 02:56:46 2113 GMT >>> >>> Without having thought about possible security problems, my first idea >>> would be to let the validity start at 1970. As I never did such I never >>> had thought about possible implications when doing such (e.g. I don't >>> know if someone checks the start date for plausabilitiy) >>> >>> Another solution would be to retry loading of the certificate if the >>> time gets set (and e.g. differs more than a year). >>> >>> Has someone already thought about how to solve that problem? Or did >>> everyone use sane systems which have a (working) RTC? >> >> >> Another option would be to make a configure option to just ignore the date. > > Or an option to auto-advance the clock to the "Not Before" date if needed... > >> 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. > > Hmm, nice failure mode... And the dream of every vendor, finally a working expiration date. And a nice TV-B-Gone, just feed a wrong date once. ;) Regards, Alexader -- 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: 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] 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 through NTP. The used certificate was generated automatically. Having a look at it, the following is shown: Validity Not Before: Feb 6 02:56:46 2013 GMT Not After : Jan 13 02:56:46 2113 GMT Without having thought about possible security problems, my first idea would be to let the validity start at 1970. As I never did such I never had thought about possible implications when doing such (e.g. I don't know if someone checks the start date for plausabilitiy) Another solution would be to retry loading of the certificate if the time gets set (and e.g. differs more than a year). Has someone already thought about how to solve that problem? Or did everyone use sane systems which have a (working) RTC? Another option would be to make a configure option to just ignore the date. Or an option to auto-advance the clock to the "Not Before" date if needed... 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. Hmm, nice failure mode... And the dream of every vendor, finally a working expiration date. And a nice TV-B-Gone, just feed a wrong date once. ;) I've digged a bit around about how to disable the date check, but then decided that I shouldn't try to implement that (CONFIG_MODSIGN_IGNORE_DATES) because of missing knowledge about the (usage of) crypto-api. I think adding attributes to the key and the parsed key like bool ingore_dates and bool parsed_dates_invalid might be an option. Using such x509_key_preparse() could just set parsed_dates_invalid instead of returning with -EKEYREJECTED or -EKEYEXPIRED, if it encounters invalid dates. Regards, Alexander -- 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 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 less work. I may have fixed the major udl problem with being a console, patch was posted to dri-devel yesterday, and I've pushed it into -next. Thanks a lot. I will check it. Regards, Alexander -- 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: 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 unconditionally. After all, when a certificate check fails due to out-of-validity-period, then you can always "fix" that by appropriately setting the clock. So for security, in this application, the date check is outright useless. I don't think that is an option, because the date check is part of the crypto-api and not a part of the modsign-stuff. So it's necessary that the crypto-api offers a flag to ignore the dates and another flag to mark such keys as invalid because of the date. The first flag is necessary to load and use the keys, the second flag for (maybe) other users of the crypto-api which might not use such invalid keys. Regards, Alexander -- 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: 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 got set to a wrong date. Or just ignore the date unconditionally. After all, when a certificate check fails due to out-of-validity-period, then you can always "fix" that by appropriately setting the clock. So for security, in this application, the date check is outright useless. I don't think that is an option, because the date check is part of the crypto-api and not a part of the modsign-stuff. So it's necessary that the crypto-api offers a flag to ignore the dates and another flag to mark such keys as invalid because of the date. The first flag is necessary to load and use the keys, the second flag for (maybe) other users of the crypto-api which might not use such invalid keys. Another option would be, to just load every key, regardless of the dates of the keys, and let the user of the keys (e.g. modsign) decide if they accept the dates in the keys. But I'm missing the big picture about the crypto-api and their users, therefor I better don't touch that part of the kernel myself. ;) Regards, Alexander -- 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/
[PATCH] rtc: rtc-hid-sensor-time: allow full years (16bit) in HID reports
The draft for HID-sensors (HUTRR39) currently doesn't define the range
for the attribute year. Asking one of the authors revealed that full years
(e.g. 2013 instead of just 13) were meant.
So we now allow both, 8 bit and 16 bit values for the attribute year and
assuming full years when the 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 deletions(-)
diff --git a/drivers/rtc/rtc-hid-sensor-time.c
b/drivers/rtc/rtc-hid-sensor-time.c
index 31c5728..f3ef38a 100644
--- a/drivers/rtc/rtc-hid-sensor-time.c
+++ b/drivers/rtc/rtc-hid-sensor-time.c
@@ -85,10 +85,13 @@ static int hid_time_capture_sample(struct
hid_sensor_hub_device *hsdev,
switch (usage_id) {
case HID_USAGE_SENSOR_TIME_YEAR:
- time_buf->tm_year = *(u8 *)raw_data;
- if (time_buf->tm_year < 70)
- /* assume we are in 1970...2069 */
- time_buf->tm_year += 100;
+ if (raw_len == 1) {
+ time_buf->tm_year = *(u8 *)raw_data;
+ if (time_buf->tm_year < 70)
+ /* assume we are in 1970...2069 */
+ time_buf->tm_year += 100;
+ } else
+ time_buf->tm_year = *(u16 *)raw_data-1900;
break;
case HID_USAGE_SENSOR_TIME_MONTH:
/* sensor sending the month as 1-12, we need 0-11 */
@@ -151,11 +154,27 @@ static int hid_time_parse_report(struct platform_device
*pdev,
return -EINVAL;
}
if (time_state->info[i].size != 1) {
- dev_err(&pdev->dev,
- "attribute '%s' not 8 bits wide!\n",
+ /*
+* The draft for HID-sensors (HUTRR39) currently
+* doesn't define the range for the year attribute.
+* Therefor we support both 8 bit (0-99) and 16 bit
+* (full) as size for the year.
+*/
+ if (time_state->info[i].attrib_id !=
+ HID_USAGE_SENSOR_TIME_YEAR) {
+ dev_err(&pdev->dev,
+ "attribute '%s' not 8 bits wide!\n",
hid_time_attrib_name(
time_state->info[i].attrib_id));
- return -EINVAL;
+ return -EINVAL;
+ }
+ if (time_state->info[i].size != 2) {
+ dev_err(&pdev->dev,
+ "attribute '%s' not 8 or 16 bits
wide!\n",
+ hid_time_attrib_name(
+ time_state->info[i].attrib_id));
+ return -EINVAL;
+ }
}
if (time_state->info[i].units !=
HID_USAGE_SENSOR_UNITS_NOT_SPECIFIED &&
--
1.8.1.4
--
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 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 semaphore.
>>
>> There is still a memory leak if a timeout happens, but at least the driver
>> now continues his disconnect routine.
>>
>> ...
>>
>> --- a/drivers/video/udlfb.c
>> +++ b/drivers/video/udlfb.c
>> @@ -1832,8 +1832,9 @@ static void dlfb_free_urb_list(struct dlfb_data *dev)
>> /* keep waiting and freeing, until we've got 'em all */
>> while (count--) {
>>
>> -/* Getting interrupted means a leak, but ok at disconnect */
>> -ret = down_interruptible(&dev->urbs.limit_sem);
>> +/* Timeout likely occurs at disconnect (resulting in a leak) */
>> +ret = down_timeout_killable(&dev->urbs.limit_sem,
>> +FREE_URB_TIMEOUT);
>> if (ret)
>> break;
>
> This is rather a hack. Do you have an understanding of the underlying
> bug? Why is the driver waiting for things which will never happen?
It is a hack, but I don't want to rewrite the whole driver. There is
already an attempt to do so, udl. The hack is a quick solution which
doesn't make something worse, just better. The only drawback might be
the few additional bytes for the implementation of
down_timeout_killable(), but I thought such should be already available,
and wondered it wasn't.
Fixing the underlying problem (including removing the leaks) would just
end up in another rewrite and I prefer to have a look at udl, maybe
fixing the current problems to use such a device as console there.
I've only posted this small patch series, because some (longterm) stable
kernels don't have udl, and smscufx, which is in large parts identical
to udlfb might want that patch too.
Just in case: I don't know anything about smscufx and have discovered
the similarities between those drivers only when I did a git grep to
search for something I fixed with a previous patch.
Regards,
Alexander
--
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 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 used semaphore.
There is still a memory leak if a timeout happens, but at least the driver
now continues his disconnect routine.
...
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1832,8 +1832,9 @@ static void dlfb_free_urb_list(struct dlfb_data *dev)
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
- /* Getting interrupted means a leak, but ok at disconnect */
- ret = down_interruptible(&dev->urbs.limit_sem);
+ /* Timeout likely occurs at disconnect (resulting in a leak) */
+ ret = down_timeout_killable(&dev->urbs.limit_sem,
+ FREE_URB_TIMEOUT);
if (ret)
break;
This is rather a hack. Do you have an understanding of the underlying
bug? Why is the driver waiting for things which will never happen?
To add a bit more explanation:
I've experienced that bug after moving the fb-damage-handling into a
workqueue (to make the driver usable as console). This likely has
increased the possibility that an urb gets missed when the usb-stack
calls the (usb-)disconnect function of the driver. But I don't know as I
couldn't use the driver before (as fbcon) so I don't really have a
comparison.
What currently happens here is something like that:
fb -> damage -> workload which sends urb and waits for answer
device disconnect -> dlfb_usb_disconnect() -> stall (no answer to the
above urb)
I don't know why the disconnect waits for all urbs. The code looks like
it does that just to free the allocated memory. As I'm not very familiar
with the usb-stack, I would have to read up about the urb-handling to
find out how to free the memory otherwise.
As the previous comment in the code suggests that urbs already got
missed (on shutdown) before, I assume that even without my patch, which
moved the damage into a workqueue, the problem could occur which then
prevents a shutdown as there is no timeout. As I've experienced that
problem not only on disconnect, but on shutdown too (no shutdown was
possible), I have to assume, that the previous used down_interruptible()
didn't get a signal on shutdown (if the driver is used as fbcon),
therefor I consider the timeout as necessary.
Regards,
Alexander
--
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 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 this by using a timeout while waiting for the used
semaphore.
There is still a memory leak if a timeout happens, but at least the
driver
now continues his disconnect routine.
...
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1832,8 +1832,9 @@ static void dlfb_free_urb_list(struct
dlfb_data *dev)
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
-/* Getting interrupted means a leak, but ok at disconnect */
-ret = down_interruptible(&dev->urbs.limit_sem);
+/* Timeout likely occurs at disconnect (resulting in a
leak) */
+ret = down_timeout_killable(&dev->urbs.limit_sem,
+FREE_URB_TIMEOUT);
if (ret)
break;
This is rather a hack. Do you have an understanding of the underlying
bug? Why is the driver waiting for things which will never happen?
To add a bit more explanation:
I've experienced that bug after moving the fb-damage-handling into a
workqueue (to make the driver usable as console). This likely has
increased the possibility that an urb gets missed when the usb-stack
calls the (usb-)disconnect function of the driver. But I don't know as I
couldn't use the driver before (as fbcon) so I don't really have a
comparison.
What currently happens here is something like that:
fb -> damage -> workload which sends urb and waits for answer
device disconnect -> dlfb_usb_disconnect() -> stall (no answer to the
above urb)
I don't know why the disconnect waits for all urbs. The code looks like
it does that just to free the allocated memory. As I'm not very familiar
with the usb-stack, I would have to read up about the urb-handling to
find out how to free the memory otherwise.
As the previous comment in the code suggests that urbs already got
missed (on shutdown) before, I assume that even without my patch, which
moved the damage into a workqueue, the problem could occur which then
prevents a shutdown as there is no timeout. As I've experienced that
problem not only on disconnect, but on shutdown too (no shutdown was
possible), I have to assume, that the previous used down_interruptible()
didn't get a signal on shutdown (if the driver is used as fbcon),
therefor I consider the timeout as necessary.
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 urb which it doesn't get.
Maybe the sequence is different if the usb-stack and udlfb are used as a
module and/or udlfb is used only for X/fb. I'm not sure what actually
does shut down the usb-stack in such a case, but maybe more than one
kill signal might be thrown around.
Regards,
Alexander
--
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 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 urb which it doesn't get. Having a second look at what I've written above, I'm not even sure if the kernel sends one or more fatal signals on shutdown at all. I've just assumed it because otherwise down_interruptible() wouldn't have worked before (it would have stalled on shutdown too (if an urb got missed), not only on disconnect). Sounds like an interesting question I should read about (if/when fatal signals are issued by the kernel). ;) Maybe the sequence is different if the usb-stack and udlfb are used as a module and/or udlfb is used only for X/fb. I'm not sure what actually does shut down the usb-stack in such a case, but maybe more than one kill signal might be thrown around. Regards, Alexander -- 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 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 shuts down -> udlfb waits (forever)
for a kill or an urb which it doesn't get.
Having a second look at what I've written above, I'm not even sure if
the kernel sends one or more fatal signals on shutdown at all. I've just
assumed it because otherwise down_interruptible() wouldn't have worked
before (it would have stalled on shutdown too (if an urb got missed),
not only on disconnect).
Sounds like an interesting question I should read about (if/when fatal
signals are issued by the kernel). ;)
Maybe the sequence is different if the usb-stack and udlfb are used as a
module and/or udlfb is used only for X/fb. I'm not sure what actually
does shut down the usb-stack in such a case, but maybe more than one
kill signal might be thrown around.
If anyone still follows my monologue: The question was interesting
enough that I couldn't resist for long. ;)
(all pasted => format broken)
In drivers/tty/sysrq.c there is
--
static void send_sig_all(int sig)
{
struct task_struct *p;
read_lock(&tasklist_lock);
for_each_process(p) {
if (p->flags & PF_KTHREAD)
continue;
if (is_global_init(p))
continue;
do_send_sig_info(sig, SEND_SIG_FORCED, p, true);
}
read_unlock(&tasklist_lock);
}
static void sysrq_handle_term(int key)
{
send_sig_all(SIGTERM);
console_loglevel = 8;
}
(...)
static void sysrq_handle_kill(int key)
{
send_sig_all(SIGKILL);
console_loglevel = 8;
}
--
Now I've done some learning by doing (kernel 3.7.5 + some patches):
--
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index df249f3..db8a86c 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1876,14 +1876,18 @@ static void dlfb_free_urb_list(struct dlfb_data
*dev)
unsigned long flags;
pr_notice("Freeing all render urbs\n");
+ if (current->flags & PF_KTHREAD)
+ pr_info("AHO: I'm a kernel thread\n");
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
/* Timeout likely occurs at disconnect (resulting in a
leak) */
ret = down_timeout_killable(&dev->urbs.limit_sem,
FREE_URB_TIMEOUT);
- if (ret)
+ if (ret) {
+ pr_info("AHO: ret %d\n", ret);
break;
+ }
spin_lock_irqsave(&dev->urbs.lock, flags);
--
Now I've disconnected the display. And, as send_sig_all() already
suggests, the result was (besides discovering an oops in
call_timer_fn.isra (once)):
--
[ 120.963010] udlfb: AHO: I'm a kernel thread
[ 122.957024] udlfb: AHO: ret -62
--
(-62 is -ETIME)
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: dlfb_usb_disconnect() (thus dlfb_free_urb_list()) isn't
called on shutdown if the device would still be connected. So the
problem only might happen, if the screen will be disconnected before
shutdown (and an urb gets missed). So the subject of my patch is correct. ;)
Regards,
Alexander
--
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 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: dlfb_usb_disconnect() (thus dlfb_free_urb_list()) isn't called on shutdown if the device would still be connected. So the problem only might happen, if the screen will be disconnected before shutdown (and an urb gets missed). So the subject of my patch is correct. ;) Hmm, wrong, sorry, I still have something to add: As no signal arrives at all, v1 of that patch is enough and the implementation of down_timeout_killable() isn't necessary at all. If there is a chance that the patch would be Acked-by by someone, I would made a v3, replacing + ret = down_timeout(&dev->urbs.limit_sem, GET_URB_TIMEOUT); in v1 with + ret = down_timeout(&dev->urbs.limit_sem, FREE_URB_TIMEOUT); as this seems to be what it should be. Regards, Alexander -- 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/
[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/semaphore.h b/include/linux/semaphore.h
index dc368b8..b508d4d 100644
--- a/include/linux/semaphore.h
+++ b/include/linux/semaphore.h
@@ -41,6 +41,8 @@ extern int __must_check down_interruptible(struct semaphore
*sem);
extern int __must_check down_killable(struct semaphore *sem);
extern int __must_check down_trylock(struct semaphore *sem);
extern int __must_check down_timeout(struct semaphore *sem, long jiffies);
+extern int __must_check down_timeout_killable(struct semaphore *sem,
+ long jiffies);
extern void up(struct semaphore *sem);
#endif /* __LINUX_SEMAPHORE_H */
diff --git a/kernel/semaphore.c b/kernel/semaphore.c
index 4567fc0..4a5e823 100644
--- a/kernel/semaphore.c
+++ b/kernel/semaphore.c
@@ -37,6 +37,8 @@ static noinline void __down(struct semaphore *sem);
static noinline int __down_interruptible(struct semaphore *sem);
static noinline int __down_killable(struct semaphore *sem);
static noinline int __down_timeout(struct semaphore *sem, long jiffies);
+static noinline int __down_timeout_killable(struct semaphore *sem,
+ long jiffies);
static noinline void __up(struct semaphore *sem);
/**
@@ -169,6 +171,35 @@ int down_timeout(struct semaphore *sem, long jiffies)
EXPORT_SYMBOL(down_timeout);
/**
+ * down_timeout_killable - acquire the semaphore within a specified time or
+ * until a fatal signal arrives.
+ * @sem: the semaphore to be acquired
+ * @jiffies: how long to wait before failing
+ *
+ * Attempts to acquire the semaphore. If no more tasks are allowed to
+ * acquire the semaphore, calling this function will put the task to sleep.
+ * If the semaphore is not released within the specified number of jiffies,
+ * this function returns -ETIME. If the sleep is interrupted by a fatal signal,
+ * this function will return -EINTR. If the semaphore is successfully acquired,
+ * this function returns 0.
+ */
+int down_timeout_killable(struct semaphore *sem, long jiffies)
+{
+ unsigned long flags;
+ int result = 0;
+
+ raw_spin_lock_irqsave(&sem->lock, flags);
+ if (likely(sem->count > 0))
+ sem->count--;
+ else
+ result = __down_timeout_killable(sem, jiffies);
+ raw_spin_unlock_irqrestore(&sem->lock, flags);
+
+ return result;
+}
+EXPORT_SYMBOL(down_timeout_killable);
+
+/**
* up - release the semaphore
* @sem: the semaphore to release
*
@@ -253,6 +284,12 @@ static noinline int __sched __down_timeout(struct
semaphore *sem, long jiffies)
return __down_common(sem, TASK_UNINTERRUPTIBLE, jiffies);
}
+static noinline int __sched __down_timeout_killable(struct semaphore *sem,
+ long jiffies)
+{
+ return __down_common(sem, TASK_KILLABLE, jiffies);
+}
+
static noinline void __sched __up(struct semaphore *sem)
{
struct semaphore_waiter *waiter = list_first_entry(&sem->wait_list,
--
1.7.11.7
--
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/
[PATCH 2/3 v2] fb: udlfb: fix hang at disconnect
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 semaphore.
There is still a memory leak if a timeout happens, but at least the driver
now continues his disconnect routine.
Cc:
Signed-off-by: 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(struct dlfb_data *dev)
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
- /* Getting interrupted means a leak, but ok at disconnect */
- ret = down_interruptible(&dev->urbs.limit_sem);
+ /* Timeout likely occurs at disconnect (resulting in a leak) */
+ ret = down_timeout_killable(&dev->urbs.limit_sem,
+ FREE_URB_TIMEOUT);
if (ret)
break;
--
1.7.11.7
--
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/
[PATCH 3/3] fb: smscufx: fix hang at disconnect
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 semaphore.
There is still a memory leak if a timeout happens, but at least the driver
now continues his disconnect routine.
Cc:
Signed-off-by: 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 ufx_free_urb_list(struct ufx_data *dev)
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
- /* Getting interrupted means a leak, but ok at shutdown*/
- ret = down_interruptible(&dev->urbs.limit_sem);
+ /* Timeout likely occurs at disconnect (resulting in a leak) */
+ ret = down_timeout_killable(&dev->urbs.limit_sem,
+ FREE_URB_TIMEOUT);
if (ret)
break;
--
1.7.11.7
--
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/
[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 config by default, make it by default accessible through /proc/config.gz, to hide the option to not include the config below "embedded" and to remove all now unnecessary IKCONFIG_* options from 174 defconfigs (almost all of them enabled those options explicit). I've already posted that two times before (https://lkml.org/lkml/2012/7/25/2 and https://lkml.org/lkml/2012/10/18/132) without even getting a single response. So I don't know if it's a totally foolish idea, if nobody is interested, or if the previous patches just weren't seen by anybody. I've now added the maintainers of the two large architectures (x86 and arm), the master himself and a few other people to cc (sorry if I've missed any important person), and I made the subject more clearly. Maybe this will provoke at least a single response. ;) Regards, Alexander -- 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/
[PATCH 1/3] Include kernel config by default
The configuration used to build a kernel (.config) is an import part of the kernel because it defines many aspects how the kernel handles all kind of stuff. Without knowing the used configuration, it is almost impossible to diagnose problems or to determine how many functionalities are handled by 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 index be8b7f5..ccf43c6 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -680,6 +680,7 @@ endmenu # "RCU Subsystem" config IKCONFIG tristate "Kernel .config support" + default y ---help--- This option enables the complete Linux kernel ".config" file contents to be saved in the kernel. It provides documentation @@ -692,6 +693,7 @@ config IKCONFIG config IKCONFIG_PROC bool "Enable access to .config through /proc/config.gz" + default y depends on IKCONFIG && PROC_FS ---help--- This option enables access to the kernel configuration file -- 1.7.11.7 -- 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/
[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(-) diff --git a/init/Kconfig b/init/Kconfig index ccf43c6..0b01c41 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -679,7 +679,7 @@ config RCU_NOCB_CPU endmenu # "RCU Subsystem" config IKCONFIG - tristate "Kernel .config support" + tristate "Kernel .config support" if EMBEDDED default y ---help--- This option enables the complete Linux kernel ".config" file @@ -692,7 +692,7 @@ config IKCONFIG /proc/config.gz if enabled (below). config IKCONFIG_PROC - bool "Enable access to .config through /proc/config.gz" + bool "Enable access to .config through /proc/config.gz" if EMBEDDED default y depends on IKCONFIG && PROC_FS ---help--- -- 1.7.11.7 -- 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 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 I finally prepared the following patch(es) to include the config by default, make it by default accessible through /proc/config.gz, to hide the option to not include the config below "embedded" and to remove all now unnecessary IKCONFIG_* options from 174 defconfigs (almost all of them enabled those options explicit). I've already posted that two times before (https://lkml.org/lkml/2012/7/25/2 and https://lkml.org/lkml/2012/10/18/132) without even getting a single response. So I don't know if it's a totally foolish idea, if nobody is interested, or if the previous patches just weren't seen by anybody. I've now added the maintainers of the two large architectures (x86 and arm), the master himself and a few other people to cc (sorry if I've missed any important person), and I made the subject more clearly. Maybe this will provoke at least a single response. ;) To add a last note: I really only care about the first patch which sets the default to y. The other two patches are more or less "nice to have" (imho) and the third patch could be even splitted into 14 patches (one for every architecture) or even 174 singles patches (one for every board(-type). If requested I would split the third patch. But now I'm finished. ;) So if no one responses (or feels responsible), I won't bother again through sending them again. Regards, Alexander -- 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: 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;
setsockopt(sd, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&v6on, sizeof(v6on))
In such a case I still want to disable or block IPv4-mapped addresses on
that socket, even if the program thinks it nows it better.
Until now I haven't found a solution.
I've now done it by the following hack:
---
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index d1e2e8e..9eefd3e 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -235,7 +235,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int
level, int optname,
if (optlen < sizeof(int) ||
inet_sk(sk)->inet_num)
goto e_inval;
- np->ipv6only = valbool;
+ np->ipv6only = valbool || net->ipv6.sysctl.bindv6only;
retv = 0;
break;
---
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 variable like
net.ipv6.bindv6only_enforced_silently. ("silently" because setsockopt()
wouldn't return an error if net.ipv6.bindv6only is true and optval
(v6only in the example above) is false.)
I would volunteer to write a patch which introduces something like
net.ipv6.bindv6only_enforced_silently if some maintainer would give me
his ok.
If so, the question remains if
systemctl net.ipv6.bindv6only_enforced_silently = 1
should set systemctl.net.ipv6.bindv6only too or if an error should be
returned if net.ipv6.bindv6only is false.
Regards,
Alexander
--
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: 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 variable like
net.ipv6.bindv6only_enforced_silently.
("silently" because setsockopt() wouldn't return an error if
net.ipv6.bindv6only is true and optval
(v6only in the example above) is false.)
I would volunteer to write a patch which introduces something like
net.ipv6.bindv6only_enforced_silently if some maintainer would give me his ok.
If so, the question remains if
systemctl net.ipv6.bindv6only_enforced_silently = 1
should set systemctl.net.ipv6.bindv6only too or if an error should be returned
if
net.ipv6.bindv6only is false.
I am not convinced why you need this, and I am not in favor of
enfocing IPV6_V6ONLY, but... some points:
It's some kind of security feature I want to have. I just don't want to
search for applications which are listening on IPv4 ports (too) even
when only IPv6 was configured. There exists several of them.
- We should allow system-admin to "enforce" IPV6_V6ONLY to 0 as well.
- CAP_NET_ADMIN users should always be able to use both modes
(They can do sysctl anyway.)
- setsockopt should fail w/ EPERM if user tries to override.
I can imagine that some programs will always try to clear IPV6_V6ONLY
(maybe for portability with other OS which default to setting it
for security reasons) and will error-exit if it fails.
So non-silent enforcing could be a PITA.
Exactly.
You really don't want to (globally) stop an application setting
IPV6_V6ONLY, such a program may well be creating separate IPv4
and IPv6 sockets.
Agreed. Applications which are setting IPV6_V6ONLY to true usually do
know what they are doing. But some braindead (configured) applications
are disabling it (and would bail out if setsockopt() would return an error).
Some of this needs to be part of some application wide 'security'
framework - that probably doesn't exist!
Should there also be similar controls for the use of IPv4
mapped addresses in actual on-the-wire IPv6 packets - eg those
destined for a remote gateway on an IPv6 only system?
I think that can be handled by iptables by just blocking e.g.
:::0:0/96 and ::0/96.
But it's a pain to find and take care of apps which are ignoring the
default (net.ipv6.bindv6only) and are disabling IPV6_V6ONLY explicit for
whatever reason.
Therefor I would like to have that
net.ipv6.bindv6only_enforced_silently. Disabling IPv4 in general is not
what I want.
Regards,
Alexander
--
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/
[PATCH] crypto: Ignore validity dates of X.509 certificates by default
I don't see any real use case where checking the validity dates of X.509
certificates at parsing time adds any security gain. In contrast, doing so
makes MODSIGN unusable on systems without a RTC (or systems with a possible
wrong date in a existing RTC or systems where the RTC is read after the keys
got loaded).
So just disable checking the dates in the parser by default.
(In fact I even think the check in the parser should be deleted at all,
because those dates should be checked at the time of usage and not at
parsing time, if someone really cares about these dates.)
Signed-off-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_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -35,4 +35,14 @@ config X509_CERTIFICATE_PARSER
data and provides the ability to instantiate a crypto key from a
public key packet found inside the certificate.
+config X509_CERTIFICATE_PARSER_IGNORE_DATES
+ bool "Ignore validity dates of X.509 certificates in the parser"
+ depends on X509_CERTIFICATE_PARSER
+ default y
+ help
+ Ignore the validity dates in X.509 certificates (Not Before
+ and Not After) when they get parsed. Otherwise loading them will
+ fail when the time is set wrong (which is e.g. a problem at startup
+ on systems without a RTC).
+
endif # ASYMMETRIC_KEY_TYPE
diff --git a/crypto/asymmetric_keys/x509_public_key.c
b/crypto/asymmetric_keys/x509_public_key.c
index 06007f0..c9a73e2 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -106,7 +106,9 @@ error_no_sig:
static int x509_key_preparse(struct key_preparsed_payload *prep)
{
struct x509_certificate *cert;
+#if !defined(CONFIG_X509_CERTIFICATE_PARSER_IGNORE_DATES)
struct tm now;
+#endif
size_t srlen, sulen;
char *desc = NULL;
int ret;
@@ -137,6 +139,7 @@ static int x509_key_preparse(struct key_preparsed_payload
*prep)
goto error_free_cert;
}
+#if !defined(CONFIG_X509_CERTIFICATE_PARSER_IGNORE_DATES)
time_to_tm(CURRENT_TIME.tv_sec, 0, &now);
pr_devel("Now: %04ld-%02d-%02d %02d:%02d:%02d\n",
now.tm_year + 1900, now.tm_mon + 1, now.tm_mday,
@@ -173,6 +176,7 @@ static int x509_key_preparse(struct key_preparsed_payload
*prep)
ret = -EKEYEXPIRED;
goto error_free_cert;
}
+#endif
cert->pub->algo = x509_public_key_algorithms[cert->pkey_algo];
cert->pub->id_type = PKEY_ID_X509;
--
1.8.1.2
--
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: [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. E.g. the Bit9 case, where malware was able to be signed. Which date? In reality dates are (mostly) defined as fixed points, but computers just don't have such. E.g. currently you can't use modsign based on X.509 certificates if the date comes through USB, because modsign tries to load the certificate before before the USB stack comes up, which ends up with invalid dates (Not Before). And changing the system date isn't that hard for an attacker if he is already able to do other bad things. Regards, Alexander -- 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/
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 URL to source or documentation about that tool so that I can enlight myself about it's meaning? Thanks in advance, Alexander -- 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: 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. Searching for "tip(-)bot" or similiar doesn't reveal some useful info (for obvious reasons). Could someone give me an URL to source or documentation about that tool so that I can enlight myself about it's meaning? AFAIK tip-bot is a set of shell scripts used by _T_glx, _I_ngo and _P_eter. :) So messages from tip-bot are just acknowledgments (like those from Greg) that a patch has found it's way into one of the trees, with the difference that tip-bot sends those acknowledgments to lkml too, whereas Greg's scripts send them only to involved parties and not the lkml? Regards, Alexander -- 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: 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, 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 URL to source or documentation about that tool so that I can enlight myself about it's meaning? AFAIK tip-bot is a set of shell scripts used by _T_glx, _I_ngo and _P_eter. :) So messages from tip-bot are just acknowledgments (like those from Greg) that a patch has found it's way into one of the trees, with the difference that tip-bot sends those acknowledgments to lkml too, whereas Greg's scripts send them only to involved parties and not the lkml? Yes, that is my understanding of it. Thanks a lot for clarification. In the meanwhile I've found an article at lwn about the kernel development process which lists many of the git repositories used by various maintainers. And that list includes tip. ;) So the reason for my ignorance was that I didn't know that tip is actually the name of a git repository used by the x86 maintainers. Regards, Alexander -- 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 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 able to handle them too? It should, yes. It should, but the full features are not enabled. We also need to patch hidp so that it can handle .request() too. Otherwise, when the sensor hub will request a "get feature" or a "set feature", then nothing will be triggered. However, I don't think it will prevent us from removing the test against USB/I2C. It's just something we need to work on too. Thanks. I've just ordered me one of those bt-sensors from TI, maybe I will be able to make it HID over GATT aware to play a bit with it. The BT spec for HID over GATT doesn't talk about sensors, but if I will find a way to program the device without buying more hw, I will have a look if it is possible. ;) Regards, Alexander -- 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] 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 shutdown of the interface for just changing the MTU more a problem than that lockdep-warning. E.g. I had serious problems with dhcpcd which sets the MTU to 1500 when an interface appears. What then happened was the following: (1) interface comes up (2) dhcpcd sets MTU to 1500 (3) a different MTU comes through DHCP (4) driver shuts down if, sets MTU, turns on IF back to (1) (endless loop) I'm not sure if dhcpcd still does that (it's some time since I discovered and reported that), but I consider it a crude way to shut down the IF to set the MTU. Regards, Alexander -- 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] 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 clocks that don't keep good time and the second places an implicit expiry date upon the kernel when used for module signing, so do we really need them? While the date check is entirely bogus for the specific case of module signing, I don't think we necessarily ought to rip it out of our generic X.509 support entirely. Some use cases *might* want to check the dates, and should be permitted to do so. Just don't refuse to even *parse* the key outside its valid date range... :) 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 dates in the parser. If there currently isn't such a user, just removing the validity check in the parser might be enough. Offering the parsed dates for later usage is still a good idea. Regards, Alexander -- 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] 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 dates in the parser. If there currently isn't such a user, just removing the validity check in the parser might be enough. Is there *is* such a user, it's broken already. The key could have been loaded (and passed the existing check) *months* ago, expired seconds after it was loaded, and your hypothetical user could still be happily trusting it. As the user (program or whatever) calls the parser, he knows if he can trust it to validate dates. So there might be something for which the current implementation works (parsing date = using date). I just don't know, because I've only discovered that glitch while trying to use modsign to be sure no unsigned module (I've compiled myself) will be become loaded (I compile the kernel and delete the keys right afterwards). So I don't know anything if and how the crypto-api to load x.509 keys is used besides modsign. ;) Regards, Alexander -- 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/
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=4M | mbuffer | bzip2smp >foo.img.bz2 bzip2smp spawns 7 threads on this machine (an intel Core i7 860 @ 2.80GHz) with HT enabled, which really seems to stress the HW (I get various throttling events). Source is an SSD, target an USB 3.0 disk. Besides a problem with USB 3.0 which just manifest in those 4 message: - Sep 14 13:00:36 krabat kernel: [15189.243914] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd Sep 14 13:00:36 krabat kernel: [15189.259625] usb 2-2: Parent hub missing LPM exit latency info. Power management will be impacted. Sep 14 13:00:36 krabat kernel: [15189.259800] xhci_hcd :02:00.0: xHCI xhci_drop_endpoint called with disabled ep 880215ad4380 Sep 14 13:00:36 krabat kernel: [15189.259806] xhci_hcd :02:00.0: xHCI xhci_drop_endpoint called with disabled ep 880215ad43c0 - at least one (visible) bug occured: - Sep 13 00:14:34 krabat kernel: [14450.085735] [ cut here ] Sep 13 00:14:34 krabat kernel: [14450.085740] kernel BUG at fs/buffer.c:3205! Sep 13 00:14:34 krabat kernel: [14450.085741] invalid opcode: [#1] SMP Sep 13 00:14:34 krabat kernel: [14450.085743] CPU 0 Sep 13 00:14:34 krabat kernel: [14450.085743] Modules linked in: nls_iso8859_1 nls_cp850 vfat fat rfcomm fuse hidp ipt_MASQUERADE xt_CHECKSUM iptable_mangle iptable_nat nf_nat binfmt_misc sunrpc bridge stp llc it87 hwmon_vid ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_physdev ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter btusb bluetooth rfkill joydev usbhid usb_storage uas loop snd_hda_codec_hdmi snd_hda_codec_realtek coretemp crc32c_intel uhci_hcd snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm i7core_edac fglrx(PO) ehci_hcd edac_core xhci_hcd microcode sg snd_timer lpc_ich r8169 snd mfd_core mii usbcore soundcore usb_common snd_page_alloc virtio_blk virtio_balloon virtio_pci virtio_net virtio virtio_ring kvm_intel kvm ipv6 [last unloaded: scsi_wait_scan] Sep 13 00:14:34 krabat kernel: [14450.085775] Sep 13 00:14:34 krabat kernel: [14450.085777] Pid: 438, comm: kswapd0 Tainted: P O 3.5.3-00010-g0fc1af2 #220 Gigabyte Technology Co., Ltd. P55M-UD4/P55M-UD4 Sep 13 00:14:34 krabat kernel: [14450.085779] RIP: 0010:[] [] free_buffer_head+0x2e/0x30 Sep 13 00:14:34 krabat kernel: [14450.085785] RSP: 0018:880216b4fb50 EFLAGS: 00010287 Sep 13 00:14:34 krabat kernel: [14450.085786] RAX: 8800949b7c78 RBX: 8800949b7bc8 RCX: 00018027001d Sep 13 00:14:34 krabat kernel: [14450.085787] RDX: 00018027001e RSI: 0001 RDI: 8800949b7c30 Sep 13 00:14:34 krabat kernel: [14450.085788] RBP: 88020480c520 R08: R09: 8111eb5d Sep 13 00:14:34 krabat kernel: [14450.085789] R10: 81856780 R11: 007d R12: 0001 Sep 13 00:14:34 krabat kernel: [14450.085790] R13: 0001 R14: ea20e880 R15: 880216b4fd18 Sep 13 00:14:34 krabat kernel: [14450.085791] FS: () GS:88021fc0() knlGS: Sep 13 00:14:34 krabat kernel: [14450.085793] CS: 0010 DS: ES: CR0: 8005003b Sep 13 00:14:34 krabat kernel: [14450.085794] CR2: 006d9504 CR3: 000103659000 CR4: 07f0 Sep 13 00:14:34 krabat kernel: [14450.085795] DR0: DR1: DR2: Sep 13 00:14:34 krabat kernel: [14450.085796] DR3: DR6: 0ff0 DR7: 0400 Sep 13 00:14:34 krabat kernel: [14450.085797] Process kswapd0 (pid: 438, threadinfo 880216b4e000, task 8802169112c0) Sep 13 00:14:34 krabat kernel: [14450.085797] Stack: Sep 13 00:14:34 krabat kernel: [14450.085798] 0001 8111ebec ea20e900 8800949b7d68 Sep 13 00:14:34 krabat kernel: [14450.085800] ea00026f5240 ea20e8c0 88020480c520 810e851b Sep 13 00:14:34 krabat kernel: [14450.085802] 8802 0002ec2d 0002ec2d Sep 13 00:14:34 krabat kernel: [14450.085804] Call Trace: Sep 13 00:14:34 krabat kernel: [14450.085807] [] ? try_to_free_buffers+0x7c/0xc0 Sep 13 00:14:34 krabat kernel: [14450.085810] [] ? move_to_new_page+0x20b/0x260 Sep 13 00:14:34 krabat kernel: [14450.085812] [] ? migrate_pages+0x407/0x4d0 Sep 13 00:14:34 krabat kernel: [14450.085814] [] ? isolate_freepages_block+0x100/0x100 Sep 13 00:14:34 krabat kernel: [14450.085816] [] ? compact_zone+0x1ec/0x2f0 Sep 13 00:14:34 krabat kernel: [14450.085818] [] ? __compact_pgdat+0x13b/0x180 Sep 13 00:14:34 krabat kernel: [14450.085820] [] ?
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 loaded? I will try it with a clean 3.6. Most of the 9 additional patches here are for ARM boxes, but anyway. I will need a few days. Just tried my "tar cp . | mbuffer | bzip2smp >/usb3/ext4/foo.tar.bz2 using a kernel 3.6 without using fglrx and without any additional patches. The first try already ended up in a broken archive (tar djf => bzip2: Data integrity error when decompressing), but (again) without the BUG() in fs/buffer.c getting hit. Will do some more tests, trying hit that BUG(). Regards, Alexander -- 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/
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 error during data load from IC. [ 8395.999590] [Hardware Error]: cache level: L1, tx: INSN, mem-tx: IRD -- Kernel is 3.6.5, MB is an Asus F2A85-M with BIOS 5103 (the latest). Can someone enlight me about what might be wrong with my (new) system (memtest didn't show an errors)? What IC is meant? As far as I know, this processor doesn't support ECC, so I wonder where that parity error does come from. Regards, Alexander -- 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: 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.999588] [Hardware Error]: Instruction Cache Error: Parity error during data load from IC. [ 8395.999590] [Hardware Error]: cache level: L1, tx: INSN, mem-tx: IRD -- Kernel is 3.6.5, MB is an Asus F2A85-M with BIOS 5103 (the latest). Can someone enlight me about what might be wrong with my (new) system (memtest didn't show an errors)? What IC is meant? As far as I know, this processor doesn't support ECC, so I wonder where that parity error does come from. I assume IC means Instruction Cache. ;) As the kernel didn't reboot or halt, this seems to have been a correctable error. Which leads me to another question. I have mcelog running, but it doesn't seem to receive the error. With my previous Intel-HW and an older kernel, mcelog received MCE errors (trip temperatur). But since the kernel now decodes those message themself, that doesn't seem to happen anymore. mcelog is silent, but now I've seen the above message on all my consoles. So now I have two question: - First, if the error is something I should ask AMD about, - Second, if the kernel could mention that it is an recoverable error. And if so and if such errors aren't something to get panic (e.g. it isn't unusual to receive such), if the kernel could output that message with another priority. Regards, Alexander -- 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: 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|-|AddrV|-|-]: 0x8c210151 [ 8395.999586] [Hardware Error]:MC1_ADDR: 0xa00e1203 [ 8395.999588] [Hardware Error]: Instruction Cache Error: Parity error during data load from IC. [ 8395.999590] [Hardware Error]: cache level: L1, tx: INSN, mem-tx: IRD -- Kernel is 3.6.5, MB is an Asus F2A85-M with BIOS 5103 (the latest). ... So now I have two question: - First, if the error is something I should ask AMD about, Not really, it is a single bit flip which got corrected, simply watch out if you get more of those. - Second, if the kernel could mention that it is an recoverable error. And if so and if such errors aren't something to get panic (e.g. it isn't unusual to receive such), if the kernel could output that message with another priority. As I said above, it got corrected. If it were critical, it would've either panicked or you wouldnt've seen it at all (probably only after reboot). 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 dead box (not overclocked, I don't do such, I even had enabled the power saving mode in the BIOS, which seems to mean max. 3800 MHz). I think I should start getting nervous. :( What I meant with another priority is using something else than pr_emerg(), because pr_emerge() causes the message to become displayed on every console, at least on my F17 with default settings. Of course, I'm happy it was displayed using pr_emerg() so I haven't missed it. Now I know that even if ECC isn't available for users which don't want or need power hungry and loud servers, at least some parity is used to verify the operations with the internal memory (cache). But on the other way, if that message isn't really critical, something else than pr_emerge() should be used. Thanks for the answer. Regards, Alexander -- 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: 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 dead box (not overclocked, I don't do such, I even had enabled the power saving mode in the BIOS, which seems to mean max. 3800 MHz). I think I should start getting nervous. :( How do you know this happened twice if you couldn't see any message? I was remotely logged in and there aren't that many faults which lead to complete stand still of hw (no reset). But as you said I can't know, the only thing I know is that a box with new mb, memory and apu come to a complete stand still, and such shortly after I've received an emergency message which told me that a bit inside the cpu switched unexpected. Adding to that, the box did the same as what it did while it received the MCE, a backup from a sata-atached ssd to an usb3-hd which includes compression and encryption which keeps all cores at work most of the time for several hours. Also, can you enable netconsole or serial console, if possible, and try to catch full dmesg from the boot and up until it happens. As I was logged in remotely by network, I know it wasn't the same MCE as before (just a disconnect and dead hw). But I don't know what else it was. And as I recently got hit by a broken RAM module, which was a pain to find, I'm not very happy that I have to go through similiar pain again with new HW. The probability to get a working HW and SW combination just has become to low in the last years. All the (IT) companies better should spend the money they now give their lawyers their QA and engineering departments instead. Sorry for the rant, also I'm used to live with hw and sw errors (as a sw-dev), I'm currently just a bit annoyed. ;) I will setup something to monitor the box through the serial and will let it backup itself all the time, trying to catch some usefull information. Regards, Alexander -- 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/
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://lkml.org/lkml/2011/8/19/60 connector doesn't use netlink_broadcast_filtered() directly but it returns netlink_broadcast() in cn_netlink_send() while netlink_broadcast() just is a wrapper around netlink_broadcast_filtered(). Could it be the case that cn_netlink_send() has to ignore the same return codes as done in kobject_uevent_env()? Or maybe the users of cn_netlink_send() have to ignore them? Regards, Alexander -- 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] 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 that too? Regards, Alexander -- 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/
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 start of the dmesg with the memory map (with the above commit reverted): - [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.6.4-1-g924 (root@krabat.ahsoftware) (gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) ) #258 SMP Mon Oct 29 11:08:32 CET 2012 [0.00] Command line: ro root=/dev/sdb2 rootfstype=ext4 enforcing=0 cgroup_disable=memory vga=0x346 video=vesafb:mtrr:3,ywrap radeon.modeset=0 [0.00] KERNEL supported cpus: [0.00] AMD AuthenticAMD [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x9d7cafff] usable [0.00] BIOS-e820: [mem 0x9d7cb000-0x9dd6afff] reserved [0.00] BIOS-e820: [mem 0x9dd6b000-0x9dd7afff] ACPI data [0.00] BIOS-e820: [mem 0x9dd7b000-0x9e0e6fff] ACPI NVS [0.00] BIOS-e820: [mem 0x9e0e7000-0x9e669fff] reserved [0.00] BIOS-e820: [mem 0x9e66a000-0x9e66afff] usable [0.00] BIOS-e820: [mem 0x9e66b000-0x9e870fff] ACPI NVS [0.00] BIOS-e820: [mem 0x9e871000-0x9ec8] usable [0.00] BIOS-e820: [mem 0x9ec9-0x9eff3fff] reserved [0.00] BIOS-e820: [mem 0x9eff4000-0x9eff] usable [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x00011000-0x0001beff] usable [0.00] NX (Execute Disable) protection: active [0.00] DMI 2.7 present. [0.00] DMI: System manufacturer System Product Name/F2A85-M, BIOS 5103 09/19/2012 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x1bf000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B write-through [0.00] C-C write-protect [0.00] D-E7FFF uncachable [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base mask 8000 write-back [0.00] 1 base 8000 mask E000 write-back [0.00] 2 base 9F00 mask FF00 uncachable [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] TOM2: 0001bf00 aka 7152M [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: update [mem 0x9f00-0x] usable ==> reserved [0.00] e820: last_pfn = 0x9f000 max_arch_pfn = 0x4 [0.00] initial memory mapped: [mem 0x-0x1fff] [0.00] Base memory trampoline at [88098000] 98000 size 24576 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0x9eff] [0.00] [mem 0x-0x7fff] page 1G [0.00] [mem 0x8000-0x9eff] page 2M [0.00] kernel direct mapping tables up to 0x9eff @ [mem 0x1fbfe000-0x1fff] [0.00] init_memory_mapping: [mem 0x1-0x1beff] [0.00] [mem 0x1-0x17fff] page 1G [0.00] [mem 0x18000-0x1beff] page 2M [0.00] kernel direct mapping tables up to 0x1beff @ [mem 0x9effe000-0x9eff] [0.00] ACPI: RSDP 000f0490 00024 (v02 ALASKA) ... - If I can help more, just ask. Regards, Alexander -- 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: 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, because I don't see if that commit is applied. ;) That sentence missed an 'any'. But I've now attached a serial, here is the output: -- early console in decompress_kernel Decompressing Linux... Parsing ELF... done. Booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.6.4 (root@krabat.ahsoftware) (gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) ) #265 SMP Mon Oct 29 14:07:32 CET 2012 [0.00] Command line: ro root=/dev/sdb2 rootfstype=ext4 enforcing=0 cgroup_disable=memory vga=0x346 video=vesafb:mtrr:3,ywrap radeon.modeset=0 earlycon=uart8250,io,0x3f8,115200n8 earlyprintk=ttyS0,115200 [0.00] KERNEL supported cpus: [0.00] AMD AuthenticAMD [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x9d7cafff] usable [0.00] BIOS-e820: [mem 0x9d7cb000-0x9dd6afff] reserved [0.00] BIOS-e820: [mem 0x9dd6b000-0x9dd7afff] ACPI data [0.00] BIOS-e820: [mem 0x9dd7b000-0x9e0e6fff] ACPI NVS [0.00] BIOS-e820: [mem 0x9e0e7000-0x9e669fff] reserved [0.00] BIOS-e820: [mem 0x9e66a000-0x9e66afff] usable [0.00] BIOS-e820: [mem 0x9e66b000-0x9e870fff] ACPI NVS [0.00] BIOS-e820: [mem 0x9e871000-0x9ec8] usable [0.00] BIOS-e820: [mem 0x9ec9-0x9eff3fff] reserved [0.00] BIOS-e820: [mem 0x9eff4000-0x9eff] usable [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x00011000-0x0001beff] usable [0.00] Early serial console at I/O port 0x3f8 (options '115200n8') [0.00] bootconsole [uart0] enabled [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.6.4 (root@krabat.ahsoftware) (gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) ) #265 SMP Mon Oct 29 14:07:32 CET 2012 [0.00] Command line: ro root=/dev/sdb2 rootfstype=ext4 enforcing=0 cgroup_disable=memory vga=0x346 video=vesafb:mtrr:3,ywrap radeon.modeset=0 earlycon=uart8250,io,0x3f8,115200n8 earlyprintk=ttyS0,115200 [0.00] KERNEL supported cpus: [0.00] AMD AuthenticAMD [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x9d7cafff] usable [0.00] BIOS-e820: [mem 0x9d7cb000-0x9dd6afff] reserved [0.00] BIOS-e820: [mem 0x9dd6b000-0x9dd7afff] ACPI data [0.00] BIOS-e820: [mem 0x9dd7b000-0x9e0e6fff] ACPI NVS [0.00] BIOS-e820: [mem 0x9e0e7000-0x9e669fff] reserved [0.00] BIOS-e820: [mem 0x9e66a000-0x9e66afff] usable [0.00] BIOS-e820: [mem 0x9e66b000-0x9e870fff] ACPI NVS [0.00] BIOS-e820: [mem 0x9e871000-0x9ec8] usable [0.00] BIOS-e820: [mem 0x9ec9-0x9eff3fff] reserved [0.00] BIOS-e820: [mem 0x9eff4000-0x9eff] usable [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x00011000-0x0001beff] usable [0.0
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 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. ;) That sentence missed an 'any'. But I've now attached a serial, here is the output: Thanks for this, it should be fixed in the next 3.6.y release, we needed to add two more commits from upstream: 844ab6f993b1d32eb40512503d35ff6ad0c57030 f82f64dd9f485e13f29f369772d4a0e868e5633a If you apply those two, and it doesn't solve the problem for you, please let us know. They don't applied cleanly, but after fixing the conflicts it seem's to work. Of course, I don't know the difference with applying those two commits or reverting the commit in 3.6.4, but I assume it's better to add the two instead of reverting the one (I'm currently to lazy to read and understand the commit-messages). ;) Thanks, Alexander -- 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: 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'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. ;)
That sentence missed an 'any'. But I've now attached a serial, here is
the output:
Thanks for this, it should be fixed in the next 3.6.y release, we needed
to add two more commits from upstream:
844ab6f993b1d32eb40512503d35ff6ad0c57030
f82f64dd9f485e13f29f369772d4a0e868e5633a
If you apply those two, and it doesn't solve the problem for you, please
let us know.
They don't applied cleanly, but after fixing the conflicts it seem's
to work.
The conflict was in the printk, right? I fixed that up in the 3.4
stable tree.
No, I've come up with that on top of 3.6.4:
-
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index ab1f6a9..d7aea41 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -35,40 +35,44 @@ struct map_range {
unsigned page_size_mask;
};
-static void __init find_early_table_space(struct map_range *mr,
unsigned long end,
- int use_pse, int use_gbpages)
+/*
+ * First calculate space needed for kernel direct mapping page tables
to cover
+ * mr[0].start to mr[nr_range - 1].end, while accounting for possible
2M and 1GB
+ * pages. Then find enough contiguous space for those page tables.
+ */
+static void __init find_early_table_space(struct map_range *mr, int
nr_range)
{
- unsigned long puds, pmds, ptes, tables, start = 0, good_end = end;
+ int i;
+ unsigned long puds = 0, pmds = 0, ptes = 0, tables;
+ unsigned long start = 0, good_end;
phys_addr_t base;
- puds = (end + PUD_SIZE - 1) >> PUD_SHIFT;
- tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
-
- if (use_gbpages) {
- unsigned long extra;
-
- extra = end - ((end>>PUD_SHIFT) << PUD_SHIFT);
- pmds = (extra + PMD_SIZE - 1) >> PMD_SHIFT;
- } else
- pmds = (end + PMD_SIZE - 1) >> PMD_SHIFT;
+ for (i = 0; i < nr_range; i++) {
+ unsigned long range, extra;
- tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
+ range = mr[i].end - mr[i].start;
+ puds += (range + PUD_SIZE - 1) >> PUD_SHIFT;
- if (use_pse) {
- unsigned long extra;
+ if (mr[i].page_size_mask & (1 << PG_LEVEL_1G)) {
+ extra = range - ((range >> PUD_SHIFT) << PUD_SHIFT);
+ pmds += (extra + PMD_SIZE - 1) >> PMD_SHIFT;
+ } else {
+ pmds += (range + PMD_SIZE - 1) >> PMD_SHIFT;
+ }
- extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT);
+ if (mr[i].page_size_mask & (1 << PG_LEVEL_2M)) {
+ extra = range - ((range >> PMD_SHIFT) << PMD_SHIFT);
#ifdef CONFIG_X86_32
- extra += PMD_SIZE;
+ extra += PMD_SIZE;
#endif
- /* The first 2/4M doesn't use large pages. */
- if (mr->start < PMD_SIZE)
- extra += mr->end - mr->start;
-
- ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
- } else
- ptes = (end + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ ptes += (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ } else {
+ ptes += (range + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ }
+ }
+ tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
+ tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
tables += roundup(ptes * sizeof(pte_t), PAGE_SIZE);
#ifdef CONFIG_X86_32
@@ -86,7 +90,7 @@ static void __init find_early_table_space(struct
map_range *mr, unsigned long en
pgt_buf_top = pgt_buf_start + (tables >> PAGE_SHIFT);
printk(KERN_DEBUG "kernel direct mapping tables up to %#lx @ [mem
%#010lx-%#010lx]\n",
- end - 1, pgt_buf_start << PAGE_SHIFT,
+ mr[nr_range - 1].end - 1, pgt_buf_start << PAGE_SHIFT,
(pgt_buf_top << PAGE_SHIFT) - 1);
}
@@ -267,7 +271,7 @@ unsigned long __init_refok
init_memory_mapping(unsigned long start,
* nodes are discovered.
*/
if (!after_bootmem)
- find_early_table_space(&mr[0],
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 just fine, thanks a lot. Regards, Alexander -- 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/
[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 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/rtc/rtc-hid-sensor-time.c
b/drivers/rtc/rtc-hid-sensor-time.c
index 1ab3d13..1006a62 100644
--- a/drivers/rtc/rtc-hid-sensor-time.c
+++ b/drivers/rtc/rtc-hid-sensor-time.c
@@ -279,11 +279,18 @@ static int hid_time_probe(struct platform_device *pdev)
return ret;
}
+ /*
+* Enable HID input processing early in order to be able to read the
+* clock already in devm_rtc_device_register().
+*/
+ hid_device_io_start(hsdev->hdev);
+
time_state->rtc = devm_rtc_device_register(&pdev->dev,
"hid-sensor-time", &hid_time_rtc_ops,
THIS_MODULE);
if (IS_ERR_OR_NULL(time_state->rtc)) {
+ hid_device_io_stop(hsdev->hdev);
ret = time_state->rtc ? PTR_ERR(time_state->rtc) : -ENODEV;
time_state->rtc = NULL;
sensor_hub_remove_callback(hsdev, HID_USAGE_SENSOR_TIME);
--
1.8.1.4
--
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/
[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-hid-sensor-time.c
b/drivers/rtc/rtc-hid-sensor-time.c
index 7273b01..1ab3d13 100644
--- a/drivers/rtc/rtc-hid-sensor-time.c
+++ b/drivers/rtc/rtc-hid-sensor-time.c
@@ -283,9 +283,11 @@ static int hid_time_probe(struct platform_device *pdev)
"hid-sensor-time", &hid_time_rtc_ops,
THIS_MODULE);
- if (IS_ERR(time_state->rtc)) {
+ if (IS_ERR_OR_NULL(time_state->rtc)) {
+ ret = time_state->rtc ? PTR_ERR(time_state->rtc) : -ENODEV;
+ time_state->rtc = NULL;
+ sensor_hub_remove_callback(hsdev, HID_USAGE_SENSOR_TIME);
dev_err(&pdev->dev, "rtc device register failed!\n");
- return PTR_ERR(time_state->rtc);
}
return ret;
--
1.8.1.4
--
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/
[PATCH 0/2] rtc: rtc-hid-sensor-time: enable HID input processing early
The following 2 patches together replace the previous send patch "rtc: rtc-hid-sensor-time: delay registering as rtc into a work". They are based on the current master, so they might become included in 3.11. I've splitted the changes into two patches because the patch changed 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-info.html Please read the FAQ at http://www.tux.org/lkml/
[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
---
drivers/rtc/rtc-hid-sensor-time.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-hid-sensor-time.c
b/drivers/rtc/rtc-hid-sensor-time.c
index 7273b01..b5a2874 100644
--- a/drivers/rtc/rtc-hid-sensor-time.c
+++ b/drivers/rtc/rtc-hid-sensor-time.c
@@ -23,10 +23,6 @@
#include
#include
-/* Format: HID-SENSOR-usage_id_in_hex */
-/* Usage ID from spec for Time: 0x2000A0 */
-#define DRIVER_NAME "HID-SENSOR-2000a0" /* must be lowercase */
-
enum hid_time_channel {
CHANNEL_SCAN_INDEX_YEAR,
CHANNEL_SCAN_INDEX_MONTH,
@@ -300,9 +296,19 @@ static int hid_time_remove(struct platform_device *pdev)
return 0;
}
+static struct platform_device_id hid_time_ids[] = {
+ {
+ /* Format: HID-SENSOR-usage_id_in_hex_lowercase */
+ .name = "HID-SENSOR-2000a0",
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, hid_time_ids);
+
static struct platform_driver hid_time_platform_driver = {
+ .id_table = hid_time_ids,
.driver = {
- .name = DRIVER_NAME,
+ .name = KBUILD_MODNAME,
.owner = THIS_MODULE,
},
.probe = hid_time_probe,
--
1.8.1.4
--
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/
[PATCH 0/4] iio: hid-sensor: add module alias for autoload
Hello, I'm not sure if it was by intention that none of the hid-sensor drivers were loaded automatically. But I assume it was not by intention. Therefor I've added a module alias to every hid-sensor driver by adding a MODULE_DEVICE_TABLE. This has another benefit: it makes it possible 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-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/
[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-sensor-accel-3d.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c
b/drivers/iio/accel/hid-sensor-accel-3d.c
index bbcbd71..275c5d7 100644
--- a/drivers/iio/accel/hid-sensor-accel-3d.c
+++ b/drivers/iio/accel/hid-sensor-accel-3d.c
@@ -30,10 +30,6 @@
#include
#include "../common/hid-sensors/hid-sensor-trigger.h"
-/*Format: HID-SENSOR-usage_id_in_hex*/
-/*Usage ID from spec for Accelerometer-3D: 0x200073*/
-#define DRIVER_NAME "HID-SENSOR-200073"
-
enum accel_3d_channel {
CHANNEL_SCAN_INDEX_X,
CHANNEL_SCAN_INDEX_Y,
@@ -389,9 +385,19 @@ static int hid_accel_3d_remove(struct platform_device
*pdev)
return 0;
}
+static struct platform_device_id hid_accel_3d_ids[] = {
+ {
+ /* Format: HID-SENSOR-usage_id_in_hex_lowercase */
+ .name = "HID-SENSOR-200073",
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, hid_accel_3d_ids);
+
static struct platform_driver hid_accel_3d_platform_driver = {
+ .id_table = hid_accel_3d_ids,
.driver = {
- .name = DRIVER_NAME,
+ .name = KBUILD_MODNAME,
.owner = THIS_MODULE,
},
.probe = hid_accel_3d_probe,
--
1.8.1.5
--
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/
[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/magnetometer/hid-sensor-magn-3d.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index 99f4e49..e71127a 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -30,10 +30,6 @@
#include
#include "../common/hid-sensors/hid-sensor-trigger.h"
-/*Format: HID-SENSOR-usage_id_in_hex*/
-/*Usage ID from spec for Magnetometer-3D: 0x200083*/
-#define DRIVER_NAME "HID-SENSOR-200083"
-
enum magn_3d_channel {
CHANNEL_SCAN_INDEX_X,
CHANNEL_SCAN_INDEX_Y,
@@ -390,9 +386,19 @@ static int hid_magn_3d_remove(struct platform_device *pdev)
return 0;
}
+static struct platform_device_id hid_magn_3d_ids[] = {
+ {
+ /* Format: HID-SENSOR-usage_id_in_hex_lowercase */
+ .name = "HID-SENSOR-200083",
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, hid_magn_3d_ids);
+
static struct platform_driver hid_magn_3d_platform_driver = {
+ .id_table = hid_magn_3d_ids,
.driver = {
- .name = DRIVER_NAME,
+ .name = KBUILD_MODNAME,
.owner = THIS_MODULE,
},
.probe = hid_magn_3d_probe,
--
1.8.1.5
--
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/
[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-sensor-gyro-3d.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c
b/drivers/iio/gyro/hid-sensor-gyro-3d.c
index bc943dd..9cc8aa1 100644
--- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
+++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
@@ -30,10 +30,6 @@
#include
#include "../common/hid-sensors/hid-sensor-trigger.h"
-/*Format: HID-SENSOR-usage_id_in_hex*/
-/*Usage ID from spec for Gyro-3D: 0x200076*/
-#define DRIVER_NAME "HID-SENSOR-200076"
-
enum gyro_3d_channel {
CHANNEL_SCAN_INDEX_X,
CHANNEL_SCAN_INDEX_Y,
@@ -389,9 +385,19 @@ static int hid_gyro_3d_remove(struct platform_device *pdev)
return 0;
}
+static struct platform_device_id hid_gyro_3d_ids[] = {
+ {
+ /* Format: HID-SENSOR-usage_id_in_hex_lowercase */
+ .name = "HID-SENSOR-200076",
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, hid_gyro_3d_ids);
+
static struct platform_driver hid_gyro_3d_platform_driver = {
+ .id_table = hid_gyro_3d_ids,
.driver = {
- .name = DRIVER_NAME,
+ .name = KBUILD_MODNAME,
.owner = THIS_MODULE,
},
.probe = hid_gyro_3d_probe,
--
1.8.1.5
--
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/
[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-sensor-als.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-als.c
b/drivers/iio/light/hid-sensor-als.c
index cdc2cad..9adfef0 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -30,10 +30,6 @@
#include
#include "../common/hid-sensors/hid-sensor-trigger.h"
-/*Format: HID-SENSOR-usage_id_in_hex*/
-/*Usage ID from spec for Ambiant-Light: 0x200041*/
-#define DRIVER_NAME "HID-SENSOR-200041"
-
#define CHANNEL_SCAN_INDEX_ILLUM 0
struct als_state {
@@ -355,9 +351,19 @@ static int hid_als_remove(struct platform_device *pdev)
return 0;
}
+static struct platform_device_id hid_als_ids[] = {
+ {
+ /* Format: HID-SENSOR-usage_id_in_hex_lowercase */
+ .name = "HID-SENSOR-200041",
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, hid_als_ids);
+
static struct platform_driver hid_als_platform_driver = {
+ .id_table = hid_als_ids,
.driver = {
- .name = DRIVER_NAME,
+ .name = KBUILD_MODNAME,
.owner = THIS_MODULE,
},
.probe = hid_als_probe,
--
1.8.1.5
--
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 0/4] iio: hid-sensor: add module alias for autoload
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 out. Ok, I haven't tested the changes with the iio HID drivers (I don't have any commercial HID sensor hub, so I've just compile tested these patches here, double reading them), but I've tested the similiar changes with a patch for rtc-hid-sensor-time I've send out yesterday. (sorry, no link, lkml.org seems dead, just search for "rtc-hid-sensor-time: add module alias") It works just fine. An example output is now Jul 9 19:27:21 dockstar3 kernel: [5.12] rtc_hid_sensor_time HID-SENSOR-2000a0.0: milliseconds supported Jul 9 19:27:21 dockstar3 kernel: [5.132864] rtc_hid_sensor_time HID-SENSOR-2000a0.0: rtc core: setting system clock to 2013-07-09 17:26:51:328000 UTC (1373390811) Jul 9 19:27:21 dockstar3 kernel: [5.146105] rtc_hid_sensor_time HID-SENSOR-2000a0.0: rtc core: registered hid-sensor-time as rtc0 Before the output was e.g. HID-SENSOR-2000a0 HID-SENSOR-2000a0.0: rtc core: registered hid-sensor-time as rtc0 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 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 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 out. Ok, I haven't tested the changes with the iio HID drivers (I don't have any commercial HID sensor hub, so I've just compile tested these patches here, double reading them), but I've tested the similiar changes with a patch for rtc-hid-sensor-time I've send out yesterday. (sorry, no link, lkml.org seems dead, just search for "rtc-hid-sensor-time: add module alias") It works just fine. An example output is now Jul 9 19:27:21 dockstar3 kernel: [5.12] rtc_hid_sensor_time HID-SENSOR-2000a0.0: milliseconds supported Jul 9 19:27:21 dockstar3 kernel: [5.132864] rtc_hid_sensor_time HID-SENSOR-2000a0.0: rtc core: setting system clock to 2013-07-09 17:26:51:328000 UTC (1373390811) Jul 9 19:27:21 dockstar3 kernel: [5.146105] rtc_hid_sensor_time HID-SENSOR-2000a0.0: rtc core: registered hid-sensor-time as rtc0 Before the output was e.g. HID-SENSOR-2000a0 HID-SENSOR-2000a0.0: rtc core: registered hid-sensor-time as rtc0 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. ;) Do you have tested the patches with a real device? I assume you have one. ;) 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: "Virtual" Interrupts -- Need help please
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 to read. It looks like your mailer has also reflowed Daniel's mail. That's just wrong. Mail readers should wrap lines, not senders. And readers can do this since some decades. The reason is obvious: No sender knows the line width the receiver can display. So, for example, if the sender hard breaks lines every 80 chars, a reader with a device which just displays 60 characters at max. will see every second line with at most 20 characters. I assume you can guess how such does look like. Furthermore there are still a lot of people which do like to read mails with line length as long their display is possible to show, and hard breaking lines on the receiver side does 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" 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: "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 to read. It looks like your mailer has also reflowed Daniel's mail. That's just wrong. Mail readers should wrap lines, not senders. And readers can do this since some decades. The reason is obvious: No sender knows the line width the receiver can display. So, for example, if the sender hard breaks lines every 80 chars, a reader with a device which just displays 60 characters at max. will see every second line with at most 20 characters. I assume you can guess how such does look like. Furthermore there are still a lot of people which do like to read mails with line length as long their display is possible to show, and hard breaking lines on the receiver side does make such impossible. Uups, sorry, I meant on the sender side here. ;) 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. I am using thunderbird and/or mutt. I don't think they reflow anything, or at least the logged mail doesn't seem to have been reflowed (nor does the text above). As for what I write myself, I prefer to wrap manually, meaning automatic insertion of newlines is turned off. Guess I can not do it right for That just the right thing to do. everyone. 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: "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. > >> That's just wrong. Mail readers should wrap lines, not senders. And >> readers can do this since some decades. > > There's a specific way for senders to request that if it's desired, set > format=flowed in the MIME type to tell the recipient that the formatting > isn't important. > >> The reason is obvious: No sender knows the line width the receiver >> can display. So, for example, if the sender hard breaks lines every >> 80 chars, a reader with a device which just displays 60 characters >> at max. will see every second line with at most 20 characters. I >> assume you can guess how such does look like. Furthermore there are >> still a lot of people which do like to read mails with line length >> as long their display is possible to show, and hard breaking lines >> on the receiver side does 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. > > This doesn't work well with lots of content (like patches) commonly > handled in technical contexts - the line breaks actually mean something > and it's hard fo the mail client to figure out what is going on unless > someone tells it. I wonder what all the hard line breaks you added to your mail do mean? Hard line breaks in paragraphs, as you've requested, doesn't mean anything. They just make eamils extremly ugly, e.g. your one is displayed here with a whole lot of unused white space because I'm not using a CGA screen. And people who do read your mail on a phone with less than 80 or 75 chars will see it as even more ugly. And imho it just works if hard line breaks are used where they belong too, the code or to end paragraphs or otherwise where they have a meaning, but not just always after 75 or 80 chars. 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 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 only did introduce irq-mappings for only those gpios which are marked as IRQs, but it requested those gpios too and preconfigured them And that breaks every driver which uses gpios for IRQs. 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() So I would suggest multiple steps to change that: 1. Create a mapping for every gpio found in DT (or all gpios if no DT is used). I think that is what Linus patch does (sorry, I haven't really followed this thread and didn't look in deep at the patch). 2. Implement gpio_request_for_irq() This would just be a small macro for gpio_request(); gpio_direction_input() 3. Change all drivers which do use gpio_to_irq() to use gpio_request_for_irq() instead of gpio_request() and gpio_direction_input(). This will end up with a big series of more or less trivial patches (I count 677 occurences of gpio_to_irq) and might be splitted. 4. request gpios and set them to input when a gpio is marked as an IRQ in the DT and DT is used. Change gpio_rquest_for_irq() to a NOP if DT is used or leave it as it is for the 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 only did introduce irq-mappings for only those gpios which are marked as IRQs, but it requested those gpios too and preconfigured them And that breaks every driver which uses gpios for IRQs. 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() So I would suggest multiple steps to change that: 1. Create a mapping for every gpio found in DT (or all gpios if no DT is used). I think that is what Linus patch does (sorry, I haven't really followed this thread and didn't look in deep at the patch). 2. Implement gpio_request_for_irq() This would just be a small macro for gpio_request(); gpio_direction_input() 3. Change all drivers which do use gpio_to_irq() to use gpio_request_for_irq() instead of gpio_request() and gpio_direction_input(). This will end up with a big series of more or less trivial patches (I count 677 occurences of gpio_to_irq) and might be splitted. 4. request gpios and set them to input when a gpio is marked as an IRQ in the DT and DT is used. Change gpio_rquest_for_irq() to a NOP if DT is used or leave it as it is for the none-dt case. But I still see a possible problem with requesting a gpio (centralized) if it is marked as IRQ in DT: it does this always. I'm not sure, but there might be cases where this isn't wanted. Just that a GPIO is marked as IRQ in the DT for one driver, doesn't mean that this driver will be really used (and something else might use the GPIO instead). 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
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() So I would suggest multiple steps to change that: 1. Create a mapping for every gpio found in DT (or all gpios if no DT is used). I think that is what Linus patch does (sorry, I haven't really followed this thread and didn't look in deep at the patch). 2. Implement gpio_request_for_irq() This would just be a small macro for gpio_request(); gpio_direction_input() I would add gpio_to_irq() to that macro, so that it returns the irq number or zero if something failed. 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: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() // This needs an irq-mapping request_threaded_irq() So I would suggest multiple steps to change that: 1. Create a mapping for every gpio found in DT (or all gpios if no DT is used). I think that is what Linus patch does (sorry, I haven't really followed this thread and didn't look in deep at the patch). 2. Implement gpio_request_for_irq() This would just be a small macro for gpio_request(); gpio_direction_input() I would add gpio_to_irq() to that macro, so that it returns the irq number or zero if something failed. Doing that, it would be easy to mark gpio_to_irq() as deprecated and driver authors would change automatically to use gpio_request_for_irq() (or gpio_request_as_irq() which might more correct english). So I would suggest just the two steps above, the first with the mapping and the second which introduces gpio_request_as_irq() and marks gpio_to_irq() as deprecated. Everthing else I would leave out for the future (so I wouldn't request gpios centrally). 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 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 sharing works here, or how another user, i.e. another one >>> than the user wanting to recieve the IRQ, can validly request such a line? >>> What would the usecase for that valid request be? >> >> When the GPIO is wired to a status signal (such as an MMC card detect signal) >> the driver might want to read the state of the signal independently of the >> interrupt handler. > > That is true. But for such a complex usecase I think it's reasonable that > we only specify the GPIO in the device tree, and the driver utilizing the > IRQ need to take that and perform gpio_to_irq() on it, and then it still > works to use it both ways. Hmm, the problem is that DT is seen as fixed. So if someone marks a GPIO as an IRQ, it can never be used otherwise. So if you really go this way, you should make this pretty clear in the documentation. Looking from the other side, why do you want to mark GPIOs as IRQs in the DT 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 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 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 sharing works here, or how another user, i.e. another one
than the user wanting to recieve the IRQ, can validly request such a line?
What would the usecase for that valid request be?
When the GPIO is wired to a status signal (such as an MMC card detect signal)
the driver might want to read the state of the signal independently of the
interrupt handler.
That is true. But for such a complex usecase I think it's reasonable that
we only specify the GPIO in the device tree, and the driver utilizing the
IRQ need to take that and perform gpio_to_irq() on it, and then it still
works to use it both ways.
Hmm, the problem is that DT is seen as fixed. So if someone marks a GPIO
as an IRQ, it can never be used otherwise. So if you really go this way,
you should make this pretty clear in the documentation.
DT is fixed because that describes the hardware which is fixed of course. So if
a chip IRQ line is connected to a GPIO pin in a controller that should be
described in the DT and that pin can't be used for anything else.
If you request an gpio for every gpio which defined as IRQ centrally,
drivers can't just use that gpio as gpio afterwards. And there might be
one driver which uses the irq but another one which wants the gpio. But
if you define a gpio as irq in dt, you take away that choice.
Looking from the other side, why do you want to mark GPIOs as IRQs in
the DT at all?
Because from the component point-of-view that is wired to the SoC, that GPIO is
an IRQ line and so it has to be described.
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).
That's is not true. You don't define an IRQ number what you define is a GPIO
number that is mapped as IRQ. The GPIO number does not depend on the mapping and
it only depends on the GPIO controller.
This has absolutely nothing to do with the reverted patches and is described in
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
The only difference is that the reverted patches did actually take an action
when a GPIO pin was mapped as an IRQ (requesting the GPIO and as input).
So for example in an OMAP board DT you can define something like this:
ethernet@5,0 {
compatible = "smsc,lan9221", "smsc,lan9115";
interrupt-parent = <&gpio6>;
interrupts = <16 8>;
};
Since each OMAP GPIO bank has 32 GPIO pins, then what you are defining is that
the GPIO 176 (5 * 32 + 16) will be mapped as the IRQ line for the ethernet
controller.
I explained the exact use case I'm trying to solve in the thread "Re: [PATCH v3]
gpio: interrupt consistency check for OF GPIO IRQs" [1] if you need more
context. I'm sure others cc'ed in this thread have different (but similar)
requirements.
So I would extend my previous proposal
(http://www.mail-archive.com/linux-omap@vger.kernel.org/msg95202.html)
for a gpio_request_as_irq() such, that I would change that to
request_irq_new(number, irq_controller) where the irq_controller would
be the gpio-controller in case of omap (while marking gpio_to_irq() as
deprecated).
So request_irq_new() would than do the following on omap if the
irq-controller is a gpio-controller:
gpio_request() // This works only if the gpio was not requested before
gpio_direction_input()
(build irq-mapping)
gpio_to_irq() // This needs an irq-mapping
return request_threaded_irq()
and all drivers could replace the above sequence just with
request_irq_new(number_from_dt, irq-controller_from_dt).
How's that?
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 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,lan9115";
>> interrupt-parent = <&gpio6>;
>> interrupts = <16 8>;
>> };
>>
>> Since each OMAP GPIO bank has 32 GPIO pins, then what you are defining
>> is that
>> the GPIO 176 (5 * 32 + 16) will be mapped as the IRQ line for the
>> ethernet
>> controller.
By the way, how do you define two GPIOs/IRQs from different
gpio-banks/irq-controllers wuth that scheme?
Would that be like below?
ethernet@5,0 {
compatible = "smsc,lan9221", "smsc,lan9115";
interrupt-parent = <&gpio6>;
interrupts = <16 8>;
interrupt-parent = <&gpio7>;
interrupts = <1 IRQF_TRIGGER_FALLING>; /* GPIO7_1 */
};
So multiple definitions of interrupt-parent are allowed and the order
does matter? And such does work? Sorry for asking, but I'm relatively
new to DT. ;)
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 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 answer.
Would that be like below?
ethernet@5,0 {
compatible = "smsc,lan9221", "smsc,lan9115";
interrupt-parent = <&gpio6>;
interrupts = <16 8>;
interrupt-parent = <&gpio7>;
interrupts = <1 IRQF_TRIGGER_FALLING>; /* GPIO7_1 */
};
...
So, if I understood the code correctly the DT IRQ core doesn't expect a device
node to have more than one "interrupt-parent" property.
It *should* work though if you have multiple "interrupts" properties defined and
all of them have the same "interrupt-parent":
interrupt-parent = <&gpio6>;
interrupts = <1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
interrupts = <2 IRQF_TRIGGER_LOW>; /* GPIO6_2 */
since of_irq_map_one() will be called for each "interrupts" and the correct
"interrupt-parent" will get obtained by of_irq_find_parent().
I assumed that answer. So to make such a scenario possible, something
like this might be neccessary:
interrupts = <&gpio6 1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
interrupts = <&gpio7 2 IRQF_TRIGGER_LOW>; /* GPIO7_2 */
or, to be compatible
interrupts = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */
interrupts = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */
Another problem is the naming. In all the above cases, the driver would
not know which IRQ he should use for what. Maybe the order defines it,
but that wouldn't be very verbose. And I think just changing the name
would make travelling the tree impossible, as only the driver itself
would know the name and it's meaning.
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 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 question and I don't have a definite answer.
Would that be like below?
ethernet@5,0 {
compatible = "smsc,lan9221", "smsc,lan9115";
interrupt-parent = <&gpio6>;
interrupts = <16 8>;
interrupt-parent = <&gpio7>;
interrupts = <1 IRQF_TRIGGER_FALLING>; /* GPIO7_1 */
};
...
So, if I understood the code correctly the DT IRQ core doesn't expect
a device
node to have more than one "interrupt-parent" property.
It *should* work though if you have multiple "interrupts" properties
defined and
all of them have the same "interrupt-parent":
interrupt-parent = <&gpio6>;
interrupts = <1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
interrupts = <2 IRQF_TRIGGER_LOW>; /* GPIO6_2 */
since of_irq_map_one() will be called for each "interrupts" and the
correct
"interrupt-parent" will get obtained by of_irq_find_parent().
I assumed that answer. So to make such a scenario possible, something
like this might be neccessary:
interrupts = <&gpio6 1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
interrupts = <&gpio7 2 IRQF_TRIGGER_LOW>; /* GPIO7_2 */
or, to be compatible
interrupts = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */
interrupts = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */
Another problem is the naming. In all the above cases, the driver would
not know which IRQ he should use for what. Maybe the order defines it,
but that wouldn't be very verbose. And I think just changing the name
would make travelling the tree impossible, as only the driver itself
would know the name and it's meaning.
On a second look, travelling the tree is still possible if the solution
would be like above (without that interrupt-parent). So if a driver
requires two interrupts he could use
interrupt-foo = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */
interrupt-bar = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */
And travelling the tree will still be possible because walking from the
interrupt-controllers (those gpio) downwards would end up at the
interrupt definitions, so the name of them isn't needed to find them in
the tree.
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 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 wuth that scheme?
That is indeed a very good question and I don't have a definite answer.
Would that be like below?
ethernet@5,0 {
compatible = "smsc,lan9221", "smsc,lan9115";
interrupt-parent = <&gpio6>;
interrupts = <16 8>;
interrupt-parent = <&gpio7>;
interrupts = <1 IRQF_TRIGGER_FALLING>; /* GPIO7_1 */
};
...
So, if I understood the code correctly the DT IRQ core doesn't expect
a device
node to have more than one "interrupt-parent" property.
It *should* work though if you have multiple "interrupts" properties
defined and
all of them have the same "interrupt-parent":
interrupt-parent = <&gpio6>;
interrupts = <1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
interrupts = <2 IRQF_TRIGGER_LOW>; /* GPIO6_2 */
since of_irq_map_one() will be called for each "interrupts" and the
correct
"interrupt-parent" will get obtained by of_irq_find_parent().
I assumed that answer. So to make such a scenario possible, something
like this might be neccessary:
interrupts = <&gpio6 1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
interrupts = <&gpio7 2 IRQF_TRIGGER_LOW>; /* GPIO7_2 */
or, to be compatible
interrupts = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */
interrupts = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */
Another problem is the naming. In all the above cases, the driver would
not know which IRQ he should use for what. Maybe the order defines it,
but that wouldn't be very verbose. And I think just changing the name
would make travelling the tree impossible, as only the driver itself
would know the name and it's meaning.
On a second look, travelling the tree is still possible if the solution
would be like above (without that interrupt-parent). So if a driver
requires two interrupts he could use
interrupt-foo = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */
interrupt-bar = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */
And travelling the tree will still be possible because walking from the
interrupt-controllers (those gpio) downwards would end up at the
interrupt definitions, so the name of them isn't needed to find them in
the tree.
I've just seen how they solved it for dma:
dmas = <&edma0 16
&edma0 17>;
dma-names = "rx", "tx";
so it would be like
interrupts = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */
interrupts = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */
interrupt-names = "foo", "bar";
Or this would be possible:
interrupt-parent = <&gpio6 &gpio7>;
interrupts = <1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */
interrupts = <1 IRQF_TRIGGER_LOW>; /* GPIO7_1 */
interrupt-names = "foo", "bar";
Regards,
Alexander
--
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 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 the DT IRQ core doesn't expect a device node to have more than one "interrupt-parent" property. It *should* work though if you have multiple "interrupts" properties defined and all of them have the same "interrupt-parent": interrupt-parent = <&gpio6>; interrupts = <1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */ interrupts = <2 IRQF_TRIGGER_LOW>; /* GPIO6_2 */ since of_irq_map_one() will be called for each "interrupts" and the correct "interrupt-parent" will get obtained by of_irq_find_parent(). I assumed that answer. So to make such a scenario possible, something like this might be neccessary: interrupts = <&gpio6 1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */ interrupts = <&gpio7 2 IRQF_TRIGGER_LOW>; /* GPIO7_2 */ or, to be compatible interrupts = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */ interrupts = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */ Another problem is the naming. In all the above cases, the driver would not know which IRQ he should use for what. Maybe the order defines it, but that wouldn't be very verbose. And I think just changing the name would make travelling the tree impossible, as only the driver itself would know the name and it's meaning. On a second look, travelling the tree is still possible if the solution would be like above (without that interrupt-parent). So if a driver requires two interrupts he could use interrupt-foo = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */ interrupt-bar = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */ And travelling the tree will still be possible because walking from the interrupt-controllers (those gpio) downwards would end up at the interrupt definitions, so the name of them isn't needed to find them in the tree. I've just seen how they solved it for dma: dmas = <&edma0 16 &edma0 17>; dma-names = "rx", "tx"; so it would be like interrupts = <1 IRQF_TRIGGER_HIGH &gpio6>; /* GPIO6_1 */ interrupts = <1 IRQF_TRIGGER_LOW &gpio7>; /* GPIO7_1 */ interrupt-names = "foo", "bar"; Or this would be possible: interrupt-parent = <&gpio6 &gpio7>; interrupts = <1 IRQF_TRIGGER_HIGH>; /* GPIO6_1 */ interrupts = <1 IRQF_TRIGGER_LOW>; /* GPIO7_1 */ interrupt-names = "foo", "bar"; And looking at how gpios are defined, I think it should be like that: interrupts = <&gpio6 1 IRQF_TRIGGER_HIGH &gpio7 2 IRQF_TRIGGER_LOW >; interrupt-names = "foo", "bar"; So without that interrupt-parent. Regards, Alexander -- 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 12.09.2013 17:19, schrieb Stephen Warren: IRQs, DMA channels, and GPIOs are all different things. Their bindings are defined independently. While it's good to define new types of bindings consistently with other bindings, this hasn't always happened, so you can make zero assumptions about the IRQ bindings by reading the documentation for any other kind of binding. Multiple interrupts are defined as follows: // Optional; otherwise inherited from parent/grand-parent/... interrupt-parent = <&gpio6>; // Must be in a fixed order, unless binding defines that the // optional interrupt-names property is to be used. interrupts = <1 IRQF_TRIGGER_HIGH> <2 IRQF_TRIGGER_LOW>; // Optional; binding for device defines whether it must // be present interrupt-names = "foo", "bar"; If you need multiple interrupts, each with a different parent, you need to use an interrupt-map property (Google it for a more complete explanation I guess). Unlike "interrupts", "interrupt-map" has a phandle in each entry, and hence each entry can refer to a different IRQ controller. You end up defining a dummy interrupt controller node (which may be the leaf node with multiple IRQ outputs, which then points at itself as the interrupt parent), pointing the leaf node's interrupt-parent at that node, and then having interrupt-map "demux" the N interrupt outputs to the various interrupt controllers. -- 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/ What 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 mean people have to use long names, it allows them use >> them (if it makes sense). That's a big difference. >> >> On the other side it's almost impossible to use verbose variable or >> function names where they would make sense. Not to speak about all >> the ugly splitted lines just to be below that ancient CGA limit. > > Yeah, the things people will do to avoid not nesting the living > hell out of their code... > > Tell you what - pick a random place where the code is nested 8 levels > deep and I'm fairly sure that you will end up with your finger on one > hell of ugliness. Ugliness in logical structure, not in forced line > breaks. Let's experiment... Aha. In drivers/pci/hotplug/ibmphp_pci.c, > 258 lines of deeply indented shite^Wcode that must be good since it compiles: > > 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 for me I currently only meorize some of those which don't make sense in english) 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: 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 for me I > currently only meorize some of those which don't make sense in english) But I'm still able to offer a solution: ;) limit the number of tabs, not the line length (at least not to 80). 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: 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 length is like ... (choose your own own misguided comparison, it's too late for me I currently only meorize some of those which don't make sense in english) But I'm still able to offer a solution: ;) limit the number of tabs, not the line length (at least not to 80). With that limited (and it's visually harder to keep track of), what's the problem with 80-column limit on line length? Just how long do you want those "descriptive names" to be? 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 errors because those descriptive names are visible whenever the function or variable is used, and comments usually appear only once and get forgotten when scrolled out of the screen. But just take a function like void get_xtime_and_monotonic_and_sleep_offset(struct timespec *xtim, struct timespec *wtom, struct timespec *sleep); I like such function names ;) (ok I wouldn't have use those and), but it's hard to press this into 80 characters, especially when the arguments should have some meaning too (e.g. what does wtom stand for?) If you use that somewhere you get get_xtime_and_monotonic_and_sleep_offset(a, b, c) using silly names and that already is a 58 characters long. So only 22 are left to distribute over 3 variable names. And now think what happens if that wouldn't be a void function. 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: 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 errors because those descriptive names are visible whenever the function or variable is used, and comments usually appear only once and get forgotten when scrolled out of the screen. But just take a function like void get_xtime_and_monotonic_and_sleep_offset(struct timespec *xtim, struct timespec *wtom, struct timespec *sleep); Charming... Now, try to tell one such name from another, when the only difference is buried in the middle of long phrase. And yes, I've seen mistakes clearly of that origin. Made them myself, actually. Nothing is perfect. But the source of the discussion was that I don't aggree that limiting the line length makes code more simple. E.g. In your previous example they could have used some verbose name for "flag" without having to cross an obvious non-existing limit. Such the author might have seen the "problem" early himself. And I think we all do sometimes write silly code, even when we should know it better. E.g. my first version of something like your example don't have necessarily been better as I'm usually first write something down which I believe should work, not taking care about anything but functionality. Then I take a break and have a second look in such a way like you just have exercised it. And I think most people are unable to write perfect code right out of their fingers. Of course, I think I got much better in avoiding deep nesting right from the beginning, but I'm sure I still write sometimes stupid code. And then there are those time constraints one just has to withstand, besides the fact that it happens sometimes that I just don't won't to have a look at my own code again. (The last limit is often reached by endless reviews with comments to remove a space here and rename a variable there). Nothing is more annoying than rewriting source until it looks like if the commenter has written it. People do think differently, people see code differently and people write code differently and trying to unify that with unnecessary rules just annoys almost everyone. I do like it if I can tell who has written some code by just looking at it, at least if it is readable and isn't in some obvious uglyand hard to read and hard to understand state. n8, 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 07:53, schrieb Julia Lawall: >> void get_xtime_and_monotonic_and_sleep_offset(struct timespec *xtim, >> struct timespec *wtom, struct timespec >> *sleep); >> >> I like such function names ;) (ok I wouldn't have use those and), but it's >> hard to press this into 80 characters, especially when the arguments should >> have some meaning too (e.g. what does wtom stand for?) >> >> If you use that somewhere you get >> >> get_xtime_and_monotonic_and_sleep_offset(a, b, c) >> >> using silly names and that already is a 58 characters long. So only 22 are >> left to distribute over 3 variable names. And now think what happens if that >> wouldn't be a void function. > > Personally, I prefer to use my screen real estate for multiple 80-column > windows, so I can see different parts of the code at once. Anything that > goes over 80 columns is very hard to read. > > Perhaps it is a bad example, but I don't even find this very long name > very understandable. Monotonic is an adjective and xtime and sleep are > nouns, so I don't understand how it all fits together. Maybe cramming a It just was the first long function name I came about. And sometimes a bit background information helps a lot. So without knowing anything else about that function, I assume the monotonic time is meant and the author didn't want to add _time_ to the name because it already is long. In case of the wtom I would think it's from a second author and I still have no clue what it might be. Maybe I'm missing some backgroud information here too and should actually read the description of the function, 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 (necessary or helpful) comments. 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] add exFAT driver
Am 26.09.2013 12:41, schrieb Dan Carpenter: Anton, I already told you politely in a private email that you are being offtopic. This is professional email list for programmers. Most of us are forbidden to discuss laws except with our corporate legal dept. None of us are lawyers. We're not qualified to read any of your links or interpret how they apply to anyone. We can't help you or respond to you. In other words, shut the fuck up. Let's not continue this thread. First my first name is Alexander and not Anton, and second I haven't respond to any mail on that topic 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 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 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 larger screens, but we keep the 80 character limit because it forces us to write simpler code. Sorry, but that just isn't true and never was. Having a line wide limit of 80 characters while forcing tabs to be 8 characters long limits most code to just 72 characters. And even less (max 64) inside constructs like if, for or while. The only outcome of that totally silly rule is that variable names will become shorted to silly acronyms almost nobody does understand make code unreadable. I always feel like beeing in the IT stone age when programmers thought they have to use variable names like a, b and c to save storage, memory 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 the FAQ at http://www.tux.org/lkml/
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 larger screens, but we keep the 80 character limit because it forces us to write simpler code. Sorry, but that just isn't true and never was. Having a line wide limit of 80 characters while forcing tabs to be 8 characters long limits most code to just 72 characters. And even less (max 64) inside constructs like if, for or while. The only outcome of that totally silly rule is that variable names will become shorted to silly acronyms almost nobody does understand make code unreadable. I forgot to mention function names, which are often even worse shortened than variable names. I always feel like beeing in the IT stone age when programmers thought they have to use variable names like a, b and c to save storage, memory 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 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/
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 code went over the edge. These days we have larger screens, but we keep the 80 character limit because it forces us to write simpler code. Sorry, but that just isn't true and never was. Having a line wide limit of 80 characters while forcing tabs to be 8 characters long limits most code to just 72 characters. And even less (max 64) inside constructs like if, for or while. The only outcome of that totally silly rule is that variable names will become shorted to silly acronyms almost nobody does understand make code unreadable. I forgot to mention function names, which are often even worse shortened than variable names. I always feel like beeing in the IT stone age when programmers thought they have to use variable names like a, b and c to save storage, memory or to type less when reading linux kernel code. Just in case of ... It isn't my intention to start a discussion about that 80 character limit, but justifying it with wrong arguments shouldn't be done. You could write "'It's there and you have to live with it.", but trying to justify it with obviously wrong arguments should not be done. Code doesn't get more simple by forcing people to use akronymous, abrevations or to split lines. 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: 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 wide and it was annoying when code went over the edge. These days we have larger screens, but we keep the 80 character limit because it forces us to write simpler code. Sorry, but that just isn't true and never was. Having a line wide limit of 80 characters while forcing tabs to be 8 characters long limits most code to just 72 characters. And even less (max 64) inside constructs like if, for or while. The only outcome of that totally silly rule is that variable names will become shorted to silly acronyms almost nobody does understand make code unreadable. In the context of a two-sentence paragraph, Dan's original text is pithy and accurate. A Wikipedia article would deserve more elaboration. Obviously the skill of the programmer is the overwhelming factor, but I think restricting the line length does help encourage simpler, better-factored code. It's also part of the whole "it's better to be consistent than to be better" thing. If 95% of the files in Linux use 80-character lines and the remainder use longer lines, it's just an ongoing hassle for the reader. I always feel like beeing in the IT stone age when programmers thought they have to use variable names like a, b and c to save storage, memory or to type less when reading linux kernel code. I was about to disagree because I've never seen variables named a, b or c, but I found that there are at least 2238 variables named a, b or c in linux-next. This is not good. That is not self-evident. In many cases, e.g., loop iterators, simple names are fine. Nothing is gained by renaming a loop counter from "a" to "array_index." Simple names for simple things help the reader focus on more important aspects of the code. 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 mean people have to use long names, it allows them use them (if it makes sense). That's a big difference. On the other side it's almost impossible to use verbose variable or function names where they would make sense. Not to speak about all the ugly splitted lines just to be below that ancient CGA limit. So such a limit doesn't enforces or helps people to write simpler code. It encourages using silly names and confusing line breaks, but in no way it helps in writing more simple code. It might make help to keep the code base consistent in regard to line lengths and confusing line breaks, but that's almost all it does. 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] X.509: Remove validity check of certificate date
(I've resend this message, because the one I've replied to contained
contained kernel@vger... and not linux-kernel@vger... as addressee)
I've already sent exactly the same patch here:
http://lkml.org/lkml/2013/3/27/449
and here:
https://lkml.org/lkml/2013/6/6/207
but for 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 MODSIGN function, It causes kernel module could not be
load because the RTC on system may messed by user action (e.g. refresh
BIOS) that should not be trusted.
Base on the discussion of David Howells's "[PATCH] X.509: Remove
certificate date checks":
https://lkml.org/lkml/2013/3/14/257
This patch removed the validity check of certificate date but still keep
the valid_from and valid_to fields for future usage.
Signed-off-by: Lee, Chun-Yi
cc: David Howells
cc: David Woodhouse
cc: Rusty Russell
cc: Josh Boyer
cc: Alexander Holler
cc: Matthew Garrett
cc: Peter Jones
---
crypto/asymmetric_keys/x509_public_key.c | 38 --
1 files changed, 0 insertions(+), 38 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_public_key.c
b/crypto/asymmetric_keys/x509_public_key.c
index 06007f0..5a2 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -106,7 +106,6 @@ error_no_sig:
static int x509_key_preparse(struct key_preparsed_payload *prep)
{
struct x509_certificate *cert;
- struct tm now;
size_t srlen, sulen;
char *desc = NULL;
int ret;
@@ -137,43 +136,6 @@ static int x509_key_preparse(struct key_preparsed_payload
*prep)
goto error_free_cert;
}
- time_to_tm(CURRENT_TIME.tv_sec, 0, &now);
- pr_devel("Now: %04ld-%02d-%02d %02d:%02d:%02d\n",
-now.tm_year + 1900, now.tm_mon + 1, now.tm_mday,
-now.tm_hour, now.tm_min, now.tm_sec);
- if (now.tm_year < cert->valid_from.tm_year ||
- (now.tm_year == cert->valid_from.tm_year &&
-(now.tm_mon < cert->valid_from.tm_mon ||
- (now.tm_mon == cert->valid_from.tm_mon &&
- (now.tm_mday < cert->valid_from.tm_mday ||
- (now.tm_mday == cert->valid_from.tm_mday &&
-(now.tm_hour < cert->valid_from.tm_hour ||
- (now.tm_hour == cert->valid_from.tm_hour &&
- (now.tm_min < cert->valid_from.tm_min ||
- (now.tm_min == cert->valid_from.tm_min &&
-(now.tm_sec < cert->valid_from.tm_sec
- ))) {
- pr_warn("Cert %s is not yet valid\n", cert->fingerprint);
- ret = -EKEYREJECTED;
- goto error_free_cert;
- }
- if (now.tm_year > cert->valid_to.tm_year ||
- (now.tm_year == cert->valid_to.tm_year &&
-(now.tm_mon > cert->valid_to.tm_mon ||
- (now.tm_mon == cert->valid_to.tm_mon &&
- (now.tm_mday > cert->valid_to.tm_mday ||
- (now.tm_mday == cert->valid_to.tm_mday &&
-(now.tm_hour > cert->valid_to.tm_hour ||
- (now.tm_hour == cert->valid_to.tm_hour &&
- (now.tm_min > cert->valid_to.tm_min ||
- (now.tm_min == cert->valid_to.tm_min &&
-(now.tm_sec > cert->valid_to.tm_sec
- ))) {
- pr_warn("Cert %s has expired\n", cert->fingerprint);
- ret = -EKEYEXPIRED;
- goto error_free_cert;
- }
-
cert->pub->algo = x509_public_key_algorithms[cert->pkey_algo];
cert->pub->id_type = PKEY_ID_X509;
--
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] checkpatch: Find CamelCase definitions of struct/union/enum
Am 25.09.2013 18:19, schrieb Al Viro: On Wed, Sep 25, 2013 at 08:35:44AM -0700, Joe Perches wrote: We disagree. Obviously. I think Propercase should be discouraged. ie: Qdisc et al. Excuse me, but "Joe happens to think that something should be discouraged" is not a problem. "Joe uses checkpatch.pl as force multiplier, recruiting hundreds of monkeys to enforce his personal preferences", OTOH, very much is. You are calling for ban on any mixed-case identifiers. I see at least three cases where they can be legitimate: * labels a-la Enomem, etc. I've been using those and I will keep doing so, checkpatch.pl and its users be damned. * enum members, to distinguish those from defines (first letter capitalized vs. all-caps). * (local) typedefs for structs; I really don't like their use for anything non-local, but IMO they have 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 "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] add exFAT driver
Am 25.09.2013 20:45, schrieb Greg Kroah-Hartman: > On Wed, Sep 25, 2013 at 07:32:36PM +0100, Matthew Garrett wrote: >> On Wed, Sep 25, 2013 at 10:27:04AM -0700, Greg Kroah-Hartman wrote: >> >>> Who did you contact at Samsung? I'll be visiting there in a week so I >>> can try to track some people done in person. I really want their >>> signed-off-by: on the patch, as it is their code to start with, and it's >>> a bit rude to not get their approval for the code to be merged. >> >> It's arguably rude, but it's fine under the certificate of origin. > > Oh, I totally agree, just trying to be nice here. If a company objects > to having their code included in the tree, we should always take that > into consideration, especially given the ability for others to maintain > it. We've done 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 there. 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] checkpatch: Find CamelCase definitions of struct/union/enum
Am 25.09.2013 21:48, schrieb Joe Perches: > As I've said multiple times, checkpatch is a stupid > little tool that can be ignored by anyone with > different tastes. Just that this isn't true for ordinary innocent people posting patches. Their patches, if not passed by checkpatch.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 the FAQ at http://www.tux.org/lkml/
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 make me wonder if not. Maybe you could ask Samsung about that too, when you are there. Because Samsung released the code under the GPLv2, and their lawyers understand what that means, should answer any question you might have about this. thanks, I'll have to thank for the clarification. 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] 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 owned >>> patents which might drive Linux users into the hand of MS lawyers as >>> already happened with FAT? > > Yes, it is. You cannot use exFAT without a Microsoft patent license (unless > you live in countries without software patents perhaps). That part about software patents is a farce. Here in Germany (and as I understood in whole Europe), software patents should not exist. But the FAT patent got approved by our Bungesgerichtshof, which is something like the Federal Supreme court in the US. 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] add exFAT driver
Am 26.09.2013 00:10, schrieb Greg Kroah-Hartman: > Please stick to technical discussions about the code on the kernel > mailing lists. Legal discussions can be left up to the lawyers, of > which we are not. Hmm, but I would like to know if someone has to fear getting owned by Microsoft if he would use that driver. Giving the rumours about Linux companies having to pay Microsoft and giving the fact that all of those licencees seem to don't have to speak about what Microsoft claims patents for and for what they have to pay, I obviously think adding that driver to Linux and thus making exFAT more general accepted is a very bad idea. Of course, I'm not a lawyer too, but as a responsible Linux developer, I should at least be able to warn other parities when they approach me and want to use exFAT. Doing such without the maybe necessary license might drive small companies 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 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 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/arm/lib/delay.c @@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val) *timer_val = delay_timer->read_current_timer(); return 0; } +EXPORT_SYMBOL_GPL(read_current_timer); Perhaps this fits better in armksyms.c? That way it lives with arm_delay_ops and friends. It's always much better to put things next to where they're defined rather than spreading them around. armksyms.c is a reminant of the 1.x days of doing things... but still remains to allow what are mostly assembly symbols to be exported. I needed that to build udlfb as a module. For the 3.6 stable kernels this has to be done in arch/arm/kernel/arch_timer.c (along with an #include ) So I'm not sure if an Cc: can be used here, but a patch should be submitted for inclusion into the 3.6 stable series too. Regards, Alexander -- 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/
[PATCH 1/2 RESEND RFC] Make IKCONFIG an embedded option, enabled by default
Knowing (being sure) which configuration was used to build a (maybe running) kernel is important for many scenarios. It's usually much more important than saving a few kb in the size of the kernel. Therefor turn on CONFIG_IKCONFIG and CONFIG_IKCONFIG_PROC by default and make them visible only when CONFIG_EMBEDDED is enabled, preventing premature optimization. Because I just have seen too many systems where the used config got lost and people were unable to rebuild an updated kernel, I finally prepared this patch. IKCONFIG is already enabled in most distributions and embedded kernels. 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" config IKCONFIG - tristate "Kernel .config support" + tristate "Kernel .config support" if EMBEDDED + default y ---help--- This option enables the complete Linux kernel ".config" file contents to be saved in the kernel. It provides documentation @@ -670,8 +671,9 @@ config IKCONFIG /proc/config.gz if enabled (below). config IKCONFIG_PROC - bool "Enable access to .config through /proc/config.gz" + bool "Enable access to .config through /proc/config.gz" if EMBEDDED depends on IKCONFIG && PROC_FS + default y ---help--- This option enables access to the kernel configuration file through /proc/config.gz. -- 1.7.11.7 -- 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: "read_current_timer" undefined!
Hello,
Am 18.10.2012 14:16, schrieb Thomas Meyer:
ERROR: "read_current_timer" [drivers/gpu/drm/udl/udl.ko] undefined!
ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
There is already a long thread about that, along with patches:
https://lkml.org/lkml/2012/10/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: export read_current_timer()
Exporting read_current_timmer is needed e.g. for users of get_cycles()
like udlfb which otherwise can't be build as a module.
This seems to have been forgotten in
commit 923df96b9f31b7d08d8438ff9677326d9537accf.
Cc: sta...@vger.kernel.org
Signed-off-by: Alexander Holler
---
arch/arm/kernel/arch_timer.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index cf25880..7f24d1f 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -232,6 +233,7 @@ int read_current_timer(unsigned long *timer_val)
*timer_val = arch_counter_get_cntpct();
return 0;
}
+EXPORT_SYMBOL(read_current_timer);
static struct clocksource clocksource_counter = {
.name = "arch_sys_counter",
--
1.7.3.4
--
Regards,
Alexander
--
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: 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 a problem. Hmm, please don't forget the case where people want to build the kernel in some sandbox (like chroot or similiar) where the build-system doesn't have access to /dev. I haven't checked what openssl does if that is the case, so maybe the script which calls it should either offer a verbose error message for that case, or should be prepared that openssl might fail because of a missing /dev/urandom. If that's already done, just ignore my email, I haven't read the complete thread, sorry. Regards, Alexander -- 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: [BUGFIX PATCH] rtc: eliminate extra call of ida_simple_remove()
Am 05.12.2012 16:25, schrieb Lothar Waßmann: Unbinding an RTC chip driver from its device leads to the error message: |ida_remove called for id=0 which is not allocated. This is caused by a redundant call to ida_simple_remove() in rtc_device_unregister(). Eliminate the call in 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 Holler A Cc: might make sense, but it should just remove a warning, so I don't know if that qualifies for the stable series. Regards, Alexander -- 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/
[PATCH 1/2] HID: autodetect HID sensor hubs.
It should not be necessary to add IDs for HID sensor hubs to lists
in hid-core.c and hid-sensor-hub.c. So instead of a whitelist,
autodetect such sensor hubs, based on a collection of type
physical inside a useage page of type sensor. If some sensor hubs
stil must be usable as raw devices, a 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(+), 33 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index f4109fd..2085230 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -713,7 +713,11 @@ static int hid_scan_report(struct hid_device *hid)
hid_scan_usage(hid, u);
break;
}
- }
+ } else if (page == HID_UP_SENSOR &&
+ item.type == HID_ITEM_TYPE_MAIN &&
+ item.tag == HID_MAIN_ITEM_TAG_BEGIN_COLLECTION &&
+ (item_udata(&item) & 0xff) == HID_COLLECTION_PHYSICAL)
+ hid->group = HID_GROUP_SENSOR_HUB;
}
return 0;
@@ -1465,6 +1469,10 @@ EXPORT_SYMBOL_GPL(hid_disconnect);
* there is a proper autodetection and autoloading in place (based on presence
* of HID_DG_CONTACTID), so those devices don't need to be added to this list,
* as we are doing the right thing in hid_scan_usage().
+ *
+ * Autodetection for HID sensor hubs exists too. If a collection of type
+ * physical is found inside a usage page of type sensor, hid-sensor-hub will be
+ * used as a driver. See hid_scan_report().
*/
static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index d9d73e9..ca88ddc 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -82,23 +82,6 @@ struct hid_sensor_hub_callbacks_list {
void *priv;
};
-static int sensor_hub_check_for_sensor_page(struct hid_device *hdev)
-{
- int i;
- int ret = -EINVAL;
-
- for (i = 0; i < hdev->maxcollection; i++) {
- struct hid_collection *col = &hdev->collection[i];
- if (col->type == HID_COLLECTION_PHYSICAL &&
- (col->usage & HID_USAGE_PAGE) == HID_UP_SENSOR) {
- ret = 0;
- break;
- }
- }
-
- return ret;
-}
-
static struct hid_report *sensor_hub_report(int id, struct hid_device *hdev,
int dir)
{
@@ -524,10 +507,6 @@ static int sensor_hub_probe(struct hid_device *hdev,
hid_err(hdev, "parse failed\n");
goto err_free;
}
- if (sensor_hub_check_for_sensor_page(hdev) < 0) {
- hid_err(hdev, "sensor page not found\n");
- goto err_free;
- }
INIT_LIST_HEAD(&hdev->inputs);
ret = hid_hw_start(hdev, 0);
@@ -630,16 +609,7 @@ static void sensor_hub_remove(struct hid_device *hdev)
}
static const struct hid_device_id sensor_hub_devices[] = {
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8086,
- USB_DEVICE_ID_SENSOR_HUB_1020) },
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8087,
- USB_DEVICE_ID_SENSOR_HUB_1020) },
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8086,
- USB_DEVICE_ID_SENSOR_HUB_09FA) },
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8087,
- USB_DEVICE_ID_SENSOR_HUB_09FA) },
- { HID_USB_DEVICE(USB_VENDOR_ID_STANTUM_STM,
- USB_DEVICE_ID_SENSOR_HUB_7014) },
+ { HID_DEVICE(BUS_USB, HID_GROUP_SENSOR_HUB, HID_ANY_ID, HID_ANY_ID) },
{ }
};
MODULE_DEVICE_TABLE(hid, sensor_hub_devices);
diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
index ca8d7e9..55f2773 100644
--- a/include/linux/hid-sensor-ids.h
+++ b/include/linux/hid-sensor-ids.h
@@ -19,7 +19,6 @@
#ifndef _HID_SENSORS_IDS_H
#define _HID_SENSORS_IDS_H
-#define HID_UP_SENSOR 0x0020
#define HID_MAX_PHY_DEVICES0xFF
/* Accel 3D (200073) */
diff --git a/include/linux/hid.h b/include/linux/hid.h
index c076041..c5f6ec2 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -167,6 +167,7 @@ struct hid_item {
#define HID_UP_MSVENDOR0xff00
#define HID_UP_CUSTOM 0x00ff
#define HID_UP_LOGIVENDOR 0xffbc
+#define HID_UP_SENSOR 0x0020
#define HID_
[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/hid/hid-core.c b/drivers/hid/hid-core.c
index 2085230..943a6bc 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1579,10 +1579,6 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_GYRATION,
USB_DEVICE_ID_GYRATION_REMOTE_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK,
USB_DEVICE_ID_HOLTEK_ON_LINE_GRIP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT,
USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD) },
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8086,
USB_DEVICE_ID_SENSOR_HUB_1020) },
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8086,
USB_DEVICE_ID_SENSOR_HUB_09FA) },
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8087,
USB_DEVICE_ID_SENSOR_HUB_1020) },
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8087,
USB_DEVICE_ID_SENSOR_HUB_09FA) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_KEYTOUCH, USB_DEVICE_ID_KEYTOUCH_IEC) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_ERGO_525V) },
@@ -1680,7 +1676,6 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_SUNPLUS, USB_DEVICE_ID_SUNPLUS_WDESKTOP)
},
- { HID_USB_DEVICE(USB_VENDOR_ID_STANTUM_STM,
USB_DEVICE_ID_SENSOR_HUB_7014) },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb300) },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304) },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb323) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 9d7a428..8fd25d3 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -432,11 +432,6 @@
#define USB_VENDOR_ID_IMATION 0x0718
#define USB_DEVICE_ID_DISC_STAKKA 0xd000
-#define USB_VENDOR_ID_INTEL_8086 0x8086
-#define USB_VENDOR_ID_INTEL_8087 0x8087
-#define USB_DEVICE_ID_SENSOR_HUB_1020 0x1020
-#define USB_DEVICE_ID_SENSOR_HUB_09FA 0x09FA
-
#define USB_VENDOR_ID_IRTOUCHSYSTEMS 0x6615
#define USB_DEVICE_ID_IRTOUCH_INFRARED_USB 0x0070
@@ -714,7 +709,6 @@
#define USB_VENDOR_ID_STANTUM_STM 0x0483
#define USB_DEVICE_ID_MTP_STM 0x3261
-#define USB_DEVICE_ID_SENSOR_HUB_7014 0x7014
#define USB_VENDOR_ID_STANTUM_SITRONIX 0x1403
#define USB_DEVICE_ID_MTP_SITRONIX 0x5001
--
1.7.8.6
--
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/
