m calling
here "work unwinding" ;)
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/
As nobody could answer what the parameter -c for echo should be, I assume
it's a typo. Normally I don't care much about those, but this one might make
people search for the meaning of the parameter -c.
Signed-off-by: Alexander Holler
---
Documentation/dynamic-debug-howto.txt | 4 ++
of one of the various shells,
a typo (looks unlikely) or do I miss something else which make me look a
noob?
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
wish everyone a merry christmas,
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 previously, because it came late and I was happy
with the series of patches you've already had done.
Thanks a lot (for the previous series too).
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
er seen a comment inside the kernel sources which does point to
a CVE, so I assume there already does exists some agreement about not
doing so.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
command lines would be best.)
Just call
rfcomm connect rfcomm9 01:23:45:67:89:ab
wait until the connection happened (a message will appear) and then
press ctrl-c. This still terminates the bluetooth connection, but the
device in /dev is now left.
Regards,
Alexander Holler
--
To unsubscribe fro
elp, but that looks only like a longterm solution.
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/
at
perfect and when you try to fix something, the patch is refused because
it is as imperfect as the whole driver (even if the patch would cure
some problems).
So the only fix which won't be refused is a rewrite of the driver which
often just isn't what people are willing to do.
Reg
ly time (handled like times at -rc7) before
a merge window for a new version. That would give people the possibility
to get their bugfix-patches into mainline in order to get them into the
stable series without the need to spend a version number.
Regards,
Alexander Holler
--
To unsubscribe from this
Am 04.11.2013 20:49, schrieb Geert Uytterhoeven:
On Mon, Nov 4, 2013 at 6:00 PM, Alexander Holler wrote:
3.14
3.141
3.1415
3.14159
3.141592
3.1415926
(...)
4.0
Since when does \pi converge to 4.0?
Since 3.12 > 3.9. ;)
--
To unsubscribe from this list: send the line "unsubscri
Am 04.11.2013 20:49, schrieb Geert Uytterhoeven:
On Mon, Nov 4, 2013 at 6:00 PM, Alexander Holler wrote:
3.14
3.141
3.1415
3.14159
3.141592
3.1415926
(...)
4.0
Since when does \pi converge to 4.0?
The attention span of most people is usually limited, so they won't
follow very
0
That would
- not be crazy numbers,
- make some math loving people happy,
- make people remembering that number,
- be a test for broken version number parsers,
- not as boring as usual version numbers,
- be in good tradition (e.g. TeX),
- make some maintainers hate me for that suggestion,
Am 24.10.2013 19:04, schrieb Randy Dunlap:
On 10/24/13 10:03, Aldo Iljazi wrote:
On 24-10-2013 19:59, Alexander Holler wrote:
Am 24.10.2013 18:52, schrieb Aldo Iljazi:
On 24-10-2013 19:43, Alexander Holler wrote:
Am 24.10.2013 18:39, schrieb Randy Dunlap:
nconfig supports use of or just
Am 24.10.2013 19:03, schrieb Randy Dunlap:
On 10/24/13 09:43, Alexander Holler wrote:
Am 24.10.2013 18:39, schrieb Randy Dunlap:
nconfig supports use of or just numeric key for the same functions.
Ah, that isn't mentioned in the global help.
I found it there (in global help):
Unle
Am 24.10.2013 18:39, schrieb Randy Dunlap:
nconfig supports use of or just numeric key for the same functions.
Ah, that isn't mentioned in the global help.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Am 24.10.2013 17:02, schrieb Aldo Iljazi:
On 24-10-2013 17:03, Alexander Holler wrote:
Am 24.10.2013 13:56, schrieb Aldo Iljazi:
Since nconfig is there, menuconfig is redundant.
I am proposing to remove it from the kernel.
Looks like nconfig depends on F-keys, which unfortunately do
a very good idea.
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/
pic after I received your private mail.
And third, "the fuck" just describes the topic perfectly.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
if there is any. ;)
> lot of information into a variable name is not always so successful...
> Actually, I really appreciate comments on functions, that explain the
> purpose of the function, and the constraints on its usage.
I didn't want do suggest getting rid of (ne
Am 26.09.2013 05:48, schrieb Al Viro:
On Thu, Sep 26, 2013 at 05:27:15AM +0200, Alexander Holler wrote:
Oh, personally I don't have any limit there. ;) I like descriptive
function and variable names whenever they make sense. And often they
make comments uneccessary and therefor prevent e
Am 26.09.2013 05:04, schrieb Al Viro:
On Thu, Sep 26, 2013 at 04:57:32AM +0200, Alexander Holler wrote:
Am 26.09.2013 04:52, schrieb Alexander Holler:
I'm aware of people which do nest 8 levels deep just to avoid a return,
break or goto.
But trying to limit that by limiting the line l
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
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
ies into the ground because most of them are unable to
even think about having the money needed to talk with Microsoft lawyers
in front of a court.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
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
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
ch.pl, usally get a full stop at
the first barrier.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read t
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
e their uses in cases like e.g.
fs/binfmt_misc.c
Besides that CamelCase is one character less long than camel_case.
I'm awaiting kernel developer uniforms. There are too many different
black t-shirts around. ;)
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line &qu
r some unspoken reason it always got ignored.
It would make wonder if it would be accepted this time, just because of
another author name.
Regards,
Alexander Holler
Am 25.09.2013 08:20, schrieb Lee, Chun-Yi:
The check of valid_from and valid_to fields on X.509 certificate is a
time bomb to MODSI
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
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
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
or to type less when reading linux kernel code.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read t
hat a mess. I assume that is the price that bindings don't have to change.
Thanks for clarifying that,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
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
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
Am 12.09.2013 12:11, schrieb Javier Martinez Canillas:
On 09/12/2013 10:55 AM, Alexander Holler wrote:
...
By the way, how do you define two GPIOs/IRQs from different
gpio-banks/irq-controllers wuth that scheme?
That is indeed a very good question and I don't have a definite a
Am 11.09.2013 19:42, schrieb Alexander Holler:
> Am 11.09.2013 18:14, schrieb Javier Martinez Canillas:
>> So for example in an OMAP board DT you can define something like this:
>>
>> ethernet@5,0 {
>> compatible = "smsc,lan9221", "smsc,lan911
Am 11.09.2013 18:14, schrieb Javier Martinez Canillas:
On 09/11/2013 05:30 PM, Alexander Holler wrote:
Am 22.08.2013 00:02, schrieb Linus Walleij:
On Tue, Aug 20, 2013 at 12:04 AM, Laurent Pinchart
wrote:
On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote:
I don't see how sh
T at all? And how will this be done? I found the way it was done in
the reverted patch very confusing because it needed an IRQ number. That
IRQ number depends on the mapping and isn't hw specific (and currently
just human doable because of the simple mapping).
Regards,
Alexander Holler
--
To
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
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
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
he none-dt case.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Am 09.09.2013 15:45, schrieb Mark Brown:
> On Mon, Sep 09, 2013 at 01:18:01PM +0200, Alexander Holler wrote:
>> Am 09.09.2013 13:02, schrieb Mark Brown:
>
>>> makes your mail very hard to read. It looks like your mailer has also
>>> reflowed Daniel's mail.
&g
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
make such impossible.
So the correct behaviour is to not hard break lines on the sender side
and leave that to the reader on the receiving side, as only the
receiving side knows the line width.
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
Am 15.08.2013 19:36, schrieb Benjamin Tissoires:
> On Wed, Aug 14, 2013 at 10:03 PM, Alexander Holler
> wrote:
>>>>> - hid->group = HID_GROUP_GENERIC;
>>>>> + parser = vzalloc(sizeof(struct hid_parser));
>>>>
>>>>
>
So you actually create a new parser and the subject (that existing) of
this patch is misleading.
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
Am 13.08.2013 21:15, schrieb Benjamin Tissoires:
On Tue, Aug 13, 2013 at 8:37 PM, Alexander Holler wrote:
Another problem is that I don't have any commercial sensor hub and I'm
therefor not a very relvant as tester (I've implemented the firmware for my
HID (sensor hub) device
ide here too, therefor I've
added the descriptor I'm using below.
Regards,
Alexander Holler
--my-descriptor--
0x05, 0x20, // HID_USAGE_PAGE_SENSOR
0xa1, 0x01, // COLLECTION (Application)
0x09, 0xa0, // HID_USAGE_SENSOR_CATEGORY_TIME
looking in
someone else source. ;)
Fortunately that forced me to enable some debug options which have shown
a bug Jiri fixed right after I've reported it.
So if your explanation answered Andrew Morton questions, I'm fine,
because my driver still works as I think it should. ;)
Thanks agai
Am 09.08.2013 18:21, schrieb Alexander Holler:
I've now also verified if hid-sensor-hub receives an event with
sensor_hub_raw_event() in the error-path (hid_device_io_stop() called
and probe() failed), and this still *does* happen. That event (input
report) doesn't come through hid-sen
Am 09.08.2013 13:12, schrieb Jiri Kosina:
On Fri, 9 Aug 2013, Alexander Holler wrote:
=
[ INFO: inconsistent lock state ]
3.10.5-dockstar-00038-g03242d1-dirty #408 Not tainted
-
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} us
Am 09.08.2013 00:11, schrieb Andrew Morton:
On Thu, 1 Aug 2013 20:39:02 +0200 Alexander Holler
wrote:
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
Am 07.08.2013 07:52, schrieb Greg Kroah-Hartman:
On Tue, Aug 06, 2013 at 03:37:13PM +0200, Alexander Holler wrote:
Am 06.08.2013 12:14, schrieb Greg Kroah-Hartman:
What exactly is a platform device anyway?
Originally it was a "something that wasn't connected to a bus, but just
ernel summit and not let us out until we have this all
> worked out.
MFD uses platform devices too.
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
Am 02.08.2013 17:35, schrieb Alexander Holler:
> Am 02.08.2013 11:57, schrieb Alexander Holler:
>
>> There must have been a bug in the patch too. I've also added that
>> iinterrupt-parent stuff (with the same flags as used by the driver) and
>>
Am 02.08.2013 11:57, schrieb Alexander Holler:
> There must have been a bug in the patch too. I've also added that
> iinterrupt-parent stuff (with the same flags as used by the driver) and
> just have let the driver call
>
> request_threaded_irq(gpio_to_irq(gpio), flag
to say I didn't like the syntax too, and it wasn't obvious
how the syntax is and how to conclude from a gpio number to an
irq-number and the patch didn't really include some documentation or
useful example.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the lin
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
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
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
tc0
instead of the above with the descriptive rtc_hid_sensor_time.
Automatic loading of modules works too and it works on ARM, Intel and
AMD as module or static linked. ;)
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
Add a MODULE_DEVICE_TABLE in order to let hotplug mechanisms automatically
load the driver.
This makes it also possible to use the usual driver name instead of
HID-SENSOR-2000xx which isn't very descriptive in kernel messages.
Signed-off-by: Alexander Holler
---
drivers/iio/gyro/hid-s
Add a MODULE_DEVICE_TABLE in order to let hotplug mechanisms automatically
load the driver.
This makes it also possible to use the usual driver name instead of
HID-SENSOR-2000xx which isn't very descriptive in kernel messages.
Signed-off-by: Alexander Holler
---
drivers/iio/light/hid-s
Add a MODULE_DEVICE_TABLE in order to let hotplug mechanisms automatically
load the driver.
This makes it also possible to use the usual driver name instead of
HID-SENSOR-2000xx which isn't very descriptive in kernel messages.
Signed-off-by: Alexander Holler
---
drivers/iio/magnetomete
e to use a normale driver name.
Therefor I've changed all driver names to KBUILD_MODNAME instead of
HID-SENSOR-2000xx as the later isn't very descriptive when starring at
kernel messages.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux
Add a MODULE_DEVICE_TABLE in order to let hotplug mechanisms automatically
load the driver.
This makes it also possible to use the usual driver name instead of
HID-SENSOR-2000xx which isn't very descriptive in kernel messages.
Signed-off-by: Alexander Holler
---
drivers/iio/accel/hid-s
In order to get the module automatically loaded by hotplug mechanisms a
MODULE_DEVICE_TABLE is needed.
Therefor add one.
This makes it also possible to use a module name other than HID-SENSOR-2000a0
which isn't very descriptive in kernel messages.
Signed-off-by: Alexander Holler
---
dr
nged such, that
combining them into just one patch doesn't make sense anymore.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
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
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
Am 06.07.2013 20:21, schrieb Jiri Kosina:
> On Sat, 6 Jul 2013, Alexander Holler wrote:
>
>> I've now traced down why the above patch _really_ is needed: it's because of
>> how the locking is done in the hid-subsystem. So my intuition to use a work
>> was ok, b
Am 27.06.2013 01:51, schrieb Alexander Holler:
Am 27.06.2013 00:07, schrieb Greg KH:
On Wed, Jun 26, 2013 at 11:34:35PM +0200, Alexander Holler wrote:
+ /*
+* The HID device has to be registered to read the clock.
+* Because rtc_device_register() might read the time, we
Am 26.06.2013 23:34, schrieb Alexander Holler:
Am 26.06.2013 21:55, schrieb Andrew Morton:
On Thu, 20 Jun 2013 12:39:36 +0200 Alexander Holler
wrote:
+static void hid_time_register_rtc_work(struct work_struct *work)
+{
+ struct hid_time_state *time_state
Am 27.06.2013 00:07, schrieb Greg KH:
> On Wed, Jun 26, 2013 at 11:34:35PM +0200, Alexander Holler wrote:
>>>> + /*
>>>> + * The HID device has to be registered to read the clock.
>>>> + * Because rtc_device_register() might read the time, we have to de
Am 26.06.2013 21:55, schrieb Andrew Morton:
> On Thu, 20 Jun 2013 12:39:36 +0200 Alexander Holler
> wrote:
>
>> rtc_device_register() might want to read the clock which doesn't work
>> before the hid device is registered. Therefor we delay the registration of
>>
Am 25.06.2013 16:18, schrieb Dean Jenkins:
On 17/05/13 05:43, Alexander Holler wrote:
To reproduce it, call rfcomm connect /dev/rfcommN and after the
connection to the remote device happened, power down the remote device
and wait 20s (the timeout until a connection drop will be discovered
Am 14.06.2013 21:11, schrieb John Stultz:
On 06/14/2013 09:52 AM, Alexander Holler wrote:
Those config options don't make sense anymore with the new hctosys
mechanism introduced with the previous patch.
That means two things:
- If a (hardware) clock is available it will be used to se
ready accomplished to add locking to prevent that 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/
Am 20.06.2013 19:27, schrieb John Stultz:
On 06/20/2013 03:15 AM, Alexander Holler wrote:
Am 17.06.2013 20:10, schrieb John Stultz:
On 06/14/2013 11:01 PM, Alexander Holler wrote:
What do you think I should write?
void set_systime_was_set(void) and void clear_systime_was_set(void)?
And
rtc_device_register() might want to read the clock which doesn't work
before the hid device is registered. Therefor we delay the registration of
the rtc driver by moving it to a work.
Signed-off-by: Alexander Holler
---
Changes to v1:
I've fixed a bug calling rtc_device_unreg
Am 17.06.2013 20:10, schrieb John Stultz:
On 06/14/2013 11:01 PM, Alexander Holler wrote:
Am 14.06.2013 20:28, schrieb John Stultz:
On 06/14/2013 11:05 AM, Alexander Holler wrote:
Am 14.06.2013 19:41, schrieb John Stultz:
On 06/14/2013 09:52 AM, Alexander Holler wrote:
In order to let an
Am 18.06.2013 03:59, schrieb Jingoo Han:
On Tuesday, June 18, 2013 12:40 AM, Alexander Holler wrote:
Am 14.06.2013 19:19, schrieb Alexander Holler:
Hello,
I've just tested some things with 3.10-rc5+ and discovered that
rtc_device_unregister is broken. This is most likely because of the
s
Am 14.06.2013 19:19, schrieb Alexander Holler:
Hello,
I've just tested some things with 3.10-rc5+ and discovered that
rtc_device_unregister is broken. This is most likely because of the
switch to devm*. As 3.10 is already at -rc5, I'm posting this without
Just in case the quest
Am 14.06.2013 20:28, schrieb John Stultz:
On 06/14/2013 11:05 AM, Alexander Holler wrote:
Am 14.06.2013 19:41, schrieb John Stultz:
On 06/14/2013 09:52 AM, Alexander Holler wrote:
In order to let an RTC set the time at boot without the problem that a
second RTC overwrites it, the flag
Am 14.06.2013 19:41, schrieb John Stultz:
On 06/14/2013 09:52 AM, Alexander Holler wrote:
In order to let an RTC set the time at boot without the problem that a
second RTC overwrites it, the flag systime_was_set is introduced.
systime_was_set will be true, if a persistent clock sets the time
Am 14.06.2013 19:23, schrieb John Stultz:
On 06/14/2013 09:52 AM, Alexander Holler wrote:
Some RTCs offer a higher resolution than seconds. To support reading such
high resolution timestamps from inside the kernel implement
rtc_read_timeval() and add a read_timeval to the rtc-ops.
So I like
someone is faster than I and can fix it before I found the time for a
solution or before 3.10 becomes final.
Therefor here are just the message my kernel 3.10-rc5 died with, when
removing an USB-RTC. I assume removing a RTC wasn't tested because
almost no one does such. ;)
Regards,
A
Some HID clocks do provide milliseconds. Make it possible to read a high
precision timestamp by supporting rtc_read_timeval().
Signed-off-by: Alexander Holler
---
drivers/rtc/rtc-hid-sensor-time.c | 74 +++
include/linux/hid-sensor-ids.h| 1 +
2 files
Some RTCs do provide a higher precision than seconds. Add support for them
by trying rtc_read_timeval() before using rtc_read_time() to get the time
in the hctosys mechanism.
Signed-off-by: Alexander Holler
---
drivers/rtc/class.c | 35 ---
1 file changed, 24
do "persistent"
clocks might have two instances, this shouldn't be a problem at all.
Signed-off-by: Alexander Holler
---
Documentation/rtc.txt | 8 +++---
drivers/rtc/Kconfig | 35 ++-
drivers/rtc/Makefile| 1 -
drivers/rtc/class.c | 30 --
kernel (mainly hctosys). Therfor there is
currently no need to set the clock or to extend the (rtc-)userspace api to
support high precision timestamps.
Signed-off-by: Alexander Holler
---
drivers/rtc/interface.c | 28
include/linux/rtc.h | 3 +++
2 files changed, 31
-off-by: Alexander Holler
---
include/linux/time.h | 6 ++
kernel/time/timekeeping.c | 10 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/include/linux/time.h b/include/linux/time.h
index d5d229b..888280f 100644
--- a/include/linux/time.h
+++ b/include/linux
rtc_device_register() might want to read the clock which doesn't work
before the hid device is registered. Therefor we delay the registration of
the rtc driver by moving it to a work.
Signed-off-by: Alexander Holler
---
drivers/rtc/rtc-hid-sensor-time.c
ht be
handled by the driver named rtc_cmos too).
This will replace the existent driver/mechanism hctosys and the kernel
config options CONFIG_RTC_HCTOSYS and CONFIG_RTC_HCTOSYS_DEVICE (done
with one of the following patches)
Signed-off-by: Alexander Holler
---
Documentation/kernel
401 - 500 of 723 matches
Mail list logo
