for several months now.
> >
> > Yes, I can't load the page, too. BTW, wouldn't it be better to add
> > Frank Seidel as recipient because he was the manager of the wiki?
>
> I did send an email query about the wiki status -- with a "thank you!"
> for the work
been gone for several months now.
Yes, I can't load the page, too. BTW, wouldn't it be better to add
Frank Seidel as recipient because he was the manager of the wiki?
I did send an email query about the wiki status -- with a thank you!
for the work involved -- a couple of days ago. Didn't
Hi,
Stephen Rothwell wrote:
> I have created today's linux-next tree at
i bet your $SUBJECT was meant for the Tree for Feb 25, wasn't it?
;-)
Thanks,
Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Hi,
Stephen Rothwell wrote:
I have created today's linux-next tree at
i bet your $SUBJECT was meant for the Tree for Feb 25, wasn't it?
;-)
Thanks,
Frank
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Hi Stephen,
Stephen Rothwell schrieb:
> I am now including tarballs in
> http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/.
at least the bz2 tar i just looked at from that URL has a problem
with the prefix resulting to this toplevel extraction:
next-20080222arch
next-20080222block
Stephen Rothwell schrieb:
> I am now including tarballs in
> http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/.
Looks great :-) Of course i also just put a ref to it on the
wiki.
Thanks,
Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hello Stephen,
Stephen Rothwell wrote:
> On Fri, 22 Feb 2008 01:07:01 +0100 Frank Seidel <[EMAIL PROTECTED]> wrote:
>> Hi, i'll provide tars of the current linux-next tree reachable
>> via my http://linux-next.f-seidel.de wiki ("Tar Downloads").
>> Is t
Greg KH wrote:
> Any reason we can't get these on kernel.org so that the mirror system
> will kick in for the whole world?
Only that i don't have a kernel.org account ;-) But Stephen has and
i suppose he'll put it there.
Thanks,
Frank
--
To unsubscribe from this list: send the line "unsubscribe
Randy Dunlap wrote:
> Looks close. It needs to be scriptable (not just a dynamically generated
> link) and have predictable names. As long as those are true, then it
> should be great.
Yes, i would have scripted it when it tourned out to be of use for others.
But as i just saw Stephen already
Randy Dunlap wrote:
> I'd like to see tarballs too, please...
Hi, i'll provide tars of the current linux-next tree reachable
via my http://linux-next.f-seidel.de wiki ("Tar Downloads").
Is that what you were looking for?
Thanks,
Frank
--
To unsubscribe from this list: send the line "unsubscribe
Randy Dunlap wrote:
I'd like to see tarballs too, please...
Hi, i'll provide tars of the current linux-next tree reachable
via my http://linux-next.f-seidel.de wiki (Tar Downloads).
Is that what you were looking for?
Thanks,
Frank
--
To unsubscribe from this list: send the line unsubscribe
Randy Dunlap wrote:
Looks close. It needs to be scriptable (not just a dynamically generated
link) and have predictable names. As long as those are true, then it
should be great.
Yes, i would have scripted it when it tourned out to be of use for others.
But as i just saw Stephen already has
Greg KH wrote:
Any reason we can't get these on kernel.org so that the mirror system
will kick in for the whole world?
Only that i don't have a kernel.org account ;-) But Stephen has and
i suppose he'll put it there.
Thanks,
Frank
--
To unsubscribe from this list: send the line unsubscribe
Hello Stephen,
Stephen Rothwell wrote:
On Fri, 22 Feb 2008 01:07:01 +0100 Frank Seidel [EMAIL PROTECTED] wrote:
Hi, i'll provide tars of the current linux-next tree reachable
via my http://linux-next.f-seidel.de wiki (Tar Downloads).
Is that what you were looking for?
I was going to start
Hi Stephen,
Stephen Rothwell schrieb:
I am now including tarballs in
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/.
at least the bz2 tar i just looked at from that URL has a problem
with the prefix resulting to this toplevel extraction:
next-20080222arch
next-20080222block
...
Stephen Rothwell schrieb:
I am now including tarballs in
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/.
Looks great :-) Of course i also just put a ref to it on the
wiki.
Thanks,
Frank
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
James Bottomley wrote:
> On Wed, 2008-02-20 at 16:34 +1100, Stephen Rothwell wrote:
>> There were no merge conflicts and only one build failure!
>
> Is the merge log available anywhere yet?
Yes, there is the Next/merge.log file in linux-next.
James Bottomley wrote:
On Wed, 2008-02-20 at 16:34 +1100, Stephen Rothwell wrote:
There were no merge conflicts and only one build failure!
Is the merge log available anywhere yet?
Yes, there is the Next/merge.log file in linux-next.
Stephen Rothwell wrote:
> That would work. Chris has the right idea, though. Just set up
> linux-next as a remote on any existing clone of Linus' tree and the
> "fetch" will forcibly update the linux-next/master branch (remember to
> not have that branch checked out when you fetch).
>
> If you
Stephen Rothwell wrote:
That would work. Chris has the right idea, though. Just set up
linux-next as a remote on any existing clone of Linus' tree and the
fetch will forcibly update the linux-next/master branch (remember to
not have that branch checked out when you fetch).
If you keep a
Frank Seidel wrote:
> Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they
> also really hope - at least i very strongly do - you not only call on us when
> things become a burden, but let us help and assist you right from the start.
I just started a little naiv
Greg KH wrote:
> Can we write these things down somewhere on the web so that I, and
> others, remember them in a few months? :)
Although this probably isn't what you were asking for, i anyway started
to put some of the basic things about linux-next together and filled a
naive little webpage with
Greg KH wrote:
Can we write these things down somewhere on the web so that I, and
others, remember them in a few months? :)
Although this probably isn't what you were asking for, i anyway started
to put some of the basic things about linux-next together and filled a
naive little webpage with
Frank Seidel wrote:
Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they
also really hope - at least i very strongly do - you not only call on us when
things become a burden, but let us help and assist you right from the start.
I just started a little naive webpage
lected to mention the other brave souls who volunteered: Frank
> Seidel, Ann Davis, and Harvey Harrison who I hope to be able to call on
> in times of need.
Hey, I'm sure you just temporarily forgot the discussion about that point
we had the days before ;-) Never mind, just kidding! :-)
souls who volunteered: Frank
Seidel, Ann Davis, and Harvey Harrison who I hope to be able to call on
in times of need.
Hey, I'm sure you just temporarily forgot the discussion about that point
we had the days before ;-) Never mind, just kidding! :-)
Lets get serious. I cannot speak for Ann
Hi,
On Thursday 07 February 2008 09:08, Pierre Ossman wrote:
> On Mon, 4 Feb 2008 19:25:42 +0100
> Frank Seidel <[EMAIL PROTECTED]> wrote:
> > Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
>
> I see you've guys have kept yourself busy in my a
Hi,
On Thursday 07 February 2008 09:08, Pierre Ossman wrote:
On Mon, 4 Feb 2008 19:25:42 +0100
Frank Seidel [EMAIL PROTECTED] wrote:
Signed-off-by: Frank Seidel [EMAIL PROTECTED]
I see you've guys have kept yourself busy in my absence. :)
Yes, we really did :)
As for the patch, it looks
From: Frank Seidel <[EMAIL PROTECTED]>
This patch (base on current linus git tree plus Philip Langdales
suspend/resume patch) adds support for the Ricoh RL5c476 chip:
with this the mmc adapter that needs this disabler (R5C843) can
also be handled correctly when it sits on a RL5c476.
(+
Philip Langdale <[EMAIL PROTECTED]>
Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
---
drivers/mmc/host/ricoh_mmc.c | 97 +++
1 file changed, 72 insertions(+), 25 deletions(-)
--- a/drivers/mmc/host/ricoh_mmc.c
+++ b/drivers/mmc/host/ricoh_mmc
Hi,
On Samstag 02 Februar 2008 08:16:48, you (Philip Langdale) wrote:
> Again, thanks a lot for investigating and finding the appropriate magic
> incantations. My main comment is to please base this on top of my
> suspend/resume
> patch which Pierre said he accepted but which isn't in his tree
Langdale [EMAIL PROTECTED]
Signed-off-by: Frank Seidel [EMAIL PROTECTED]
---
drivers/mmc/host/ricoh_mmc.c | 97 +++
1 file changed, 72 insertions(+), 25 deletions(-)
--- a/drivers/mmc/host/ricoh_mmc.c
+++ b/drivers/mmc/host/ricoh_mmc.c
@@ -41,6 +41,46 @@ static
From: Frank Seidel [EMAIL PROTECTED]
This patch (base on current linus git tree plus Philip Langdales
suspend/resume patch) adds support for the Ricoh RL5c476 chip:
with this the mmc adapter that needs this disabler (R5C843) can
also be handled correctly when it sits on a RL5c476.
(+ minor style
Hi,
On Samstag 02 Februar 2008 08:16:48, you (Philip Langdale) wrote:
Again, thanks a lot for investigating and finding the appropriate magic
incantations. My main comment is to please base this on top of my
suspend/resume
patch which Pierre said he accepted but which isn't in his tree yet -
On Sunday 03 February 2008 18:58, Rabin Vincent wrote:
> Do you mean the PRIO_* cases in the switch? They're still independent
> of position after the patch because they don't fall through.
Yes, sure, this is fully correct now. Just if somehting whatsoever
is put ahead touching retval one need
On Sunday 03 February 2008 04:04, Rabin Vincent wrote:
> This check is not required because the condition is always true.
> ...
> - if (niceval > retval)
> - retval = niceval;
> + retval = 20 -
On Sunday 03 February 2008 04:12, Denis Cheng wrote:
> --- a/drivers/block/cciss.c
> +++ b/drivers/block/cciss.c
> @@ -67,7 +67,7 @@ MODULE_LICENSE("GPL");
> #include
>
> /* define the PCI info for the cards we can control */
> -static const struct pci_device_id cciss_pci_device_id[] = {
>
On Sunday 03 February 2008 04:12, Denis Cheng wrote:
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -67,7 +67,7 @@ MODULE_LICENSE(GPL);
#include linux/cciss_ioctl.h
/* define the PCI info for the cards we can control */
-static const struct pci_device_id
On Sunday 03 February 2008 04:04, Rabin Vincent wrote:
This check is not required because the condition is always true.
...
- if (niceval retval)
- retval = niceval;
+ retval = 20 - task_nice(p);
On Sunday 03 February 2008 18:58, Rabin Vincent wrote:
Do you mean the PRIO_* cases in the switch? They're still independent
of position after the patch because they don't fall through.
Yes, sure, this is fully correct now. Just if somehting whatsoever
is put ahead touching retval one need to
On Saturday 02 February 2008 08:16, Philip Langdale wrote:
> Again, thanks a lot for investigating and finding the appropriate magic
> incantations. My main comment is to please base this on top of my
> suspend/resume
> patch which Pierre said he accepted but which isn't in his tree yet - I guess
On Saturday 02 February 2008 08:16, Philip Langdale wrote:
Again, thanks a lot for investigating and finding the appropriate magic
incantations. My main comment is to please base this on top of my
suspend/resume
patch which Pierre said he accepted but which isn't in his tree yet - I guess
From: Frank Seidel <[EMAIL PROTECTED]>
Even some more constifications
Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
---
drivers/char/nozomi.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/char/nozomi.c
+++ b/drivers/char/nozomi.c
@@ -
From: Jan Engelhardt <[EMAIL PROTECTED]>
nozomi: constify structures and annotate vars
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
---
drivers/char/nozomi.c | 38 ++
1 file changed, 18
From: Frank Seidel <[EMAIL PROTECTED]>
Minor cleanups and removal of in-file changelog:
- Correction of misspellings and wrong encoded Name
- changed 'unsigned' to 'unsigned int' for better readability
- use of generic devicefile access macro
- fixed/added explanatory comment to ntty_pu
Cleanups and constification of nozomi driver
Mostly trivial cleanups and updates and constification
and annotations of vars.
Patches are based on current linus git tree (while
[PATCH v2 1/3] is already in Gregs gregkh-2.6 tree).
Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
nozomi.c
Cleanups and constification of nozomi driver
Mostly trivial cleanups and updates and constification
and annotations of vars.
Patches are based on current linus git tree (while
[PATCH v2 1/3] is already in Gregs gregkh-2.6 tree).
Signed-off-by: Frank Seidel [EMAIL PROTECTED]
nozomi.c | 174
From: Frank Seidel [EMAIL PROTECTED]
Minor cleanups and removal of in-file changelog:
- Correction of misspellings and wrong encoded Name
- changed 'unsigned' to 'unsigned int' for better readability
- use of generic devicefile access macro
- fixed/added explanatory comment to ntty_put_char
From: Jan Engelhardt [EMAIL PROTECTED]
nozomi: constify structures and annotate vars
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
Signed-off-by: Frank Seidel [EMAIL PROTECTED]
---
drivers/char/nozomi.c | 38 ++
1 file changed, 18 insertions(+), 20
From: Frank Seidel [EMAIL PROTECTED]
Even some more constifications
Signed-off-by: Frank Seidel [EMAIL PROTECTED]
---
drivers/char/nozomi.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/char/nozomi.c
+++ b/drivers/char/nozomi.c
@@ -395,7 +395,7 @@ struct
On Friday 01 February 2008 08:28, Sam Ravnborg wrote:
> __devinitdata is for non-const data.
> __devinitconst is for const data.
>
> You cannot mix const and non-const data in the same section,
> if you do so gcc will complain.
> It may build for you if all uses of __devinitdata in the
> same
On Thursday 31 January 2008 22:39, Jan Engelhardt wrote:
> On Jan 31 2008 22:10, Frank Seidel wrote:
> >(Re: [PATCH 012/196 ver2] nozomi driver) and is a rework
> >of the nozomi constify patch from Jan Engelhardt.
>
> It's hard to find what you actually reworked...
No, just
This one is based on the last patch i sent
(Re: [PATCH 012/196 ver2] nozomi driver) and is a rework
of the nozomi constify patch from Jan Engelhardt.
Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
---
drivers/char/nozomi.c | 50 --
From: Frank Seidel <[EMAIL PROTECTED]>
This patch (based on current linus git tree) adds support for
the Ricoh RL5c476 chip: with this the mmc adapter that needs this
disabler (R5C843) can also be handled correctly when it sits
on a RL5c476.
Signed-off-by: Frank Seidel <[EMAIL
From: Frank Seidel [EMAIL PROTECTED]
This patch (based on current linus git tree) adds support for
the Ricoh RL5c476 chip: with this the mmc adapter that needs this
disabler (R5C843) can also be handled correctly when it sits
on a RL5c476.
Signed-off-by: Frank Seidel [EMAIL PROTECTED
This one is based on the last patch i sent
(Re: [PATCH 012/196 ver2] nozomi driver) and is a rework
of the nozomi constify patch from Jan Engelhardt.
Signed-off-by: Frank Seidel [EMAIL PROTECTED]
---
drivers/char/nozomi.c | 50 --
1 file changed
On Thursday 31 January 2008 22:39, Jan Engelhardt wrote:
On Jan 31 2008 22:10, Frank Seidel wrote:
(Re: [PATCH 012/196 ver2] nozomi driver) and is a rework
of the nozomi constify patch from Jan Engelhardt.
It's hard to find what you actually reworked...
No, just use interdiff and its easy
On Friday 01 February 2008 08:28, Sam Ravnborg wrote:
__devinitdata is for non-const data.
__devinitconst is for const data.
You cannot mix const and non-const data in the same section,
if you do so gcc will complain.
It may build for you if all uses of __devinitdata in the
same source file
On Friday 25 January 2008 20:43, Greg KH wrote:
> One more time, with a "real" changelog entry that I can use, and a
> signed-off-by: so that I can apply it to the tree would be good :)
Oops, sorry. Must have been much too long ago since i sent my last
patch :)
Thanks,
Frank
--
To unsubscribe
From: Frank Seidel <[EMAIL PROTECTED]>
Minor cleanups and removal of in-file changelog:
- Correction of misspellings and wrong encoded Name
- changed 'unsigned' to 'unsigned int' for better readability
- use of generic devicefile access macro
- fixed/added explanatory comment to ntty_pu
* CHANGELOG
- * Version 2.1d
- * 11-November-2007 Jiri Slaby, Frank Seidel
- * - Big rework of multicard support by Jiri
- * - Major cleanups (semaphore to mutex, endianess, no major reservation)
- * - Optimizations
- *
- * Version 2.1c
- * 30-October-2007 Frank Seidel
- * - Completed multicard support
Hi,
thanks for your feedback.
On Freitag 25 Januar 2008 09:31:25, you (Jan Engelhardt) wrote:
> On Jan 24 2008 23:09, Greg Kroah-Hartman wrote:
> >+/*
> >+ * nozomi.c -- HSDPA driver Broadband Wireless Data Card - Globe Trotter
> >+ *
> >+ * Written by: Ulf Jakobsson,
> >+ * Jan
From: Frank Seidel <[EMAIL PROTECTED]>
This is a driver to control the cardbus wireless data card that works on
3g networks.
Greg Kroah-Hartman <[EMAIL PROTECTED]> did the initial driver cleanup.
Thanks to Arnaud Patard <[EMAIL PROTECTED]> for help with bugfixing.
Thanks to
From: Frank Seidel [EMAIL PROTECTED]
This is a driver to control the cardbus wireless data card that works on
3g networks.
Greg Kroah-Hartman [EMAIL PROTECTED] did the initial driver cleanup.
Thanks to Arnaud Patard [EMAIL PROTECTED] for help with bugfixing.
Thanks to Alan Cox for a lot of tty
From: Frank Seidel [EMAIL PROTECTED]
Minor cleanups and removal of in-file changelog:
- Correction of misspellings and wrong encoded Name
- changed 'unsigned' to 'unsigned int' for better readability
- use of generic devicefile access macro
- fixed/added explanatory comment to ntty_put_char
Hi,
thanks for your feedback.
On Freitag 25 Januar 2008 09:31:25, you (Jan Engelhardt) wrote:
On Jan 24 2008 23:09, Greg Kroah-Hartman wrote:
+/*
+ * nozomi.c -- HSDPA driver Broadband Wireless Data Card - Globe Trotter
+ *
+ * Written by: Ulf Jakobsson,
+ * Jan �erfeldt,
2.1d
- * 11-November-2007 Jiri Slaby, Frank Seidel
- * - Big rework of multicard support by Jiri
- * - Major cleanups (semaphore to mutex, endianess, no major reservation)
- * - Optimizations
- *
- * Version 2.1c
- * 30-October-2007 Frank Seidel
- * - Completed multicard support
- * - Minor
On Friday 25 January 2008 20:43, Greg KH wrote:
One more time, with a real changelog entry that I can use, and a
signed-off-by: so that I can apply it to the tree would be good :)
Oops, sorry. Must have been much too long ago since i sent my last
patch :)
Thanks,
Frank
--
To unsubscribe from
On Dienstag 27 November 2007 23:12:20, you (Greg KH) wrote:
> Frank, want me to take the last version you just sent out and update my
> version?
Yes, that would be great.
Thanks a lot,
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Dienstag 27 November 2007 23:12:20, you (Greg KH) wrote:
Frank, want me to take the last version you just sent out and update my
version?
Yes, that would be great.
Thanks a lot,
Frank
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
ll change.
It is a further cleanup of the read/write_mem32 functions to get rid of
unpleasant and not needed attributes (resolved together with great help
from Jiri again).
Thanks,
Frank
---
>From [EMAIL PROTECTED] Tue Apr 9 12:12:43 2002
Date: Fri, 9 Nov 2007 14:49:23 +0100
From: Frank Seidel <[
cleanup of the read/write_mem32 functions to get rid of
unpleasant and not needed attributes (resolved together with great help
from Jiri again).
Thanks,
Frank
---
From [EMAIL PROTECTED] Tue Apr 9 12:12:43 2002
Date: Fri, 9 Nov 2007 14:49:23 +0100
From: Frank Seidel [EMAIL PROTECTED]
To: Greg KH
On Mittwoch 14 November 2007 19:32:01, you (Frank Seidel) wrote:
> Hi,
>
> this is a small trivial rework of the dcdbas driver so
> HAL can get uevents when platform devices are added or removed.
Sorry for the noise! In the meantime i realized (thanks to a nice
colleague) this
On Mittwoch 14 November 2007 19:32:01, you (Frank Seidel) wrote:
Hi,
this is a small trivial rework of the dcdbas driver so
HAL can get uevents when platform devices are added or removed.
Sorry for the noise! In the meantime i realized (thanks to a nice
colleague) this isn't really necessary
to use of new platform platform_register_device to
also get uevents on loading and unloading the driver.
Signed-off-by: Frank Seidel <[EMAIL PROTECTED]>
---
drivers/firmware/dcdbas.c | 57 +-
1 files changed, 31 insertions(+), 26 del
to use of new platform platform_register_device to
also get uevents on loading and unloading the driver.
Signed-off-by: Frank Seidel [EMAIL PROTECTED]
---
drivers/firmware/dcdbas.c | 57 +-
1 files changed, 31 insertions(+), 26 deletions
On Sonntag 11 November 2007 17:43:28, you (Frank Seidel) wrote:
> this one also holds the - little reworked and optimized -
> cleanup of the read/write_mem32 functions.
Yes, again a new version, but this one really has a big rework of
the multicard support from Jiri (with minor changes f
On Samstag 10 November 2007 00:48:11, you (Jiri Slaby) wrote:
> nozomi, tty cleanup
> - init and deinit tty driver at module load/unload. When the OS (user)
> loads the driver the hardware usually is ready to driver.
> - merge (unify) MAX_PORT, NTTY_TTY_MINORS into NOZOMI_MAX_PORTS
> - remove
On Samstag 10 November 2007 00:47:31, you (Jiri Slaby) wrote:
> nozomi, remove struct irq
> struct irq (named as my_irq) is used only in ISR and its called functions.
> We might silently use u16 variable on stack and remove all references to
> this structure. This is the first step of struct
On Montag 12 November 2007 08:54:52, you (Adrian Bunk) wrote:
> On Sat, Nov 10, 2007 at 11:04:41PM +0100, Jiri Slaby wrote:
> > Why? Anyway I think this is the case. The body of the then branch is
> > executed at
> > most once, while the else branch each time but last. If you write/read 1002
> >
On Montag 12 November 2007 08:54:52, you (Adrian Bunk) wrote:
On Sat, Nov 10, 2007 at 11:04:41PM +0100, Jiri Slaby wrote:
Why? Anyway I think this is the case. The body of the then branch is
executed at
most once, while the else branch each time but last. If you write/read 1002
bytes, it
On Samstag 10 November 2007 00:47:31, you (Jiri Slaby) wrote:
nozomi, remove struct irq
struct irq (named as my_irq) is used only in ISR and its called functions.
We might silently use u16 variable on stack and remove all references to
this structure. This is the first step of struct
On Samstag 10 November 2007 00:48:11, you (Jiri Slaby) wrote:
nozomi, tty cleanup
- init and deinit tty driver at module load/unload. When the OS (user)
loads the driver the hardware usually is ready to driver.
- merge (unify) MAX_PORT, NTTY_TTY_MINORS into NOZOMI_MAX_PORTS
- remove struct
On Sonntag 11 November 2007 17:43:28, you (Frank Seidel) wrote:
this one also holds the - little reworked and optimized -
cleanup of the read/write_mem32 functions.
Yes, again a new version, but this one really has a big rework of
the multicard support from Jiri (with minor changes from me
least it builds with no warnings on i386 now...
Thanks to Arnaud Patard <[EMAIL PROTECTED]> for help with bugfixing.
Thanks to Alan Cox for a lot of tty fixes.
Thanks to Satyam Sharma <[EMAIL PROTECTED]> for fixing buildbreakage.
Thanks to Frank Seidel <[EMAIL PROTECTED]> for a lot of bugfixe
On Sonntag 11 November 2007 03:37:28, you (Frank Seidel) wrote:
> While in the read_mem32 the unlikekly really seems to be of no use at all (the
> switch-case ahead seems to be hit nearly always), the unlikely in the
> write_mem32 seems to be fine.
> I compared after each 30 sec
On Sonntag 11 November 2007 03:37:28, you (Frank Seidel) wrote:
While in the read_mem32 the unlikekly really seems to be of no use at all (the
switch-case ahead seems to be hit nearly always), the unlikely in the
write_mem32 seems to be fine.
I compared after each 30 seconds and got median
on i386 now...
Thanks to Arnaud Patard [EMAIL PROTECTED] for help with bugfixing.
Thanks to Alan Cox for a lot of tty fixes.
Thanks to Satyam Sharma [EMAIL PROTECTED] for fixing buildbreakage.
Thanks to Frank Seidel [EMAIL PROTECTED] for a lot of bugfixes and
rewriting to make it a sane Linux
On Samstag 10 November 2007 23:04:41, you (Jiri Slaby) wrote:
> On 11/10/2007 05:15 PM, Adrian Bunk wrote:
> > On Fri, Nov 09, 2007 at 06:51:35PM -0500, Jiri Slaby wrote:
> >> ...
> >> - if (size_bytes - i == 2) {
> >> + if (unlikely(size_bytes - i == 2)) {
> >> ...
> >
> >
On Samstag 10 November 2007 00:27:03, you (Frank Seidel) wrote:
> I really appreciated any feedback or hint were to dig further or what
> should be done and fixed.
Thanks to the great patches from Jiri Slaby <[EMAIL PROTECTED]>
this is now again a probably big step forward for the n
On Samstag 10 November 2007 00:51:33, you (Jiri Slaby) wrote:
> nozomi, cleanup read and write
>
> - remove macros testing for endianness, le*_to_cpu and complements will do
> it
> - pointers cleanup (no need to have different pointers for be and le)
> - put unlikely into reading/writing while
On Samstag 10 November 2007 00:49:32, you (Jiri Slaby) wrote:
> Especially on this I would like to see feedback. Unlock and lock the
> spinlock just around the tty_flip_buffer_push would be much more easier, but
> won't it break anything?
> --
> nozomi, fix tty_flip_buffer_push
>
>
On Samstag 10 November 2007 00:50:12, you (Jiri Slaby) wrote:
> nozomi, remove unused includes
>
defered those (to review next week together with patch 7 and 8)
Thanks,
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Samstag 10 November 2007 00:50:53, you (Jiri Slaby) wrote:
> nozomi, remove void * casts
Yes, they are of course pointless. Applied your patch
without changes.
Thanks,
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Samstag 10 November 2007 00:48:52, you (Jiri Slaby) wrote:
> nozomi, lock cleanup
>
> - semaphore is deprecated, use mutex instead
> - don't return -ERESTARTSYS when signal might not be pending since it's not
> permitted (unknown retval mioght reach userspace)
> - don't lock interruptible in
On Samstag 10 November 2007 00:47:31, you (Jiri Slaby) wrote:
> nozomi, remove struct irq
>
> struct irq (named as my_irq) is used only in ISR and its called functions.
> We might silently use u16 variable on stack and remove all references to
> this structure. This is the first step of struct
On Samstag 10 November 2007 00:48:11, you (Jiri Slaby) wrote:
> nozomi, tty cleanup
>
> - init and deinit tty driver at module load/unload. When the OS (user)
> loads the driver the hardware usually is ready to driver.
> - merge (unify) MAX_PORT, NTTY_TTY_MINORS into NOZOMI_MAX_PORTS
> - remove
On Samstag 10 November 2007 00:46:11, you (Jiri Slaby) wrote:
> nozomi, ioctls cleanup
>
> - init tty_wait
> - don't forget to wake up tiocmiwait waiters
> - convert the whole tiocmiwait into wait_event_interruptible
> - don't check for cmd == TIOCGICOUNT in ntty_ioctl_tiocgicount, as it's
>
On Samstag 10 November 2007 00:46:51, you (Jiri Slaby) wrote:
> nozomi, reorder and cleanup probe, remove
> - remap space after requesting region, to not map something we cannot use
> anyway
> - init spin lock before request_irq, because due to shared irq debug, isr
> might be called
On Samstag 10 November 2007 00:45:30, you (Jiri Slaby) wrote:
> nozomi, tty index cleanup
>
> - don't store unneeded copy of tty->index into port structure, tty->index
> is available everywhere
> - mod tty->index by MAX_PORT where expected (otherwise array index out of
> bounds)
The last
1 - 100 of 136 matches
Mail list logo
