[PATCH 1/1] Removed Dead Code

[PATCH 1/1] Removed Dead Code

[Michael Spradling]

Signed-off-by: Michael Spradling <mike@mspradling.com>

---
 drivers/video/s1d13xxxfb.c |   50 --------------------------------------------
 1 files changed, 0 insertions(+), 50 deletions(-)

diff --git a/drivers/video/s1d13xxxfb.c b/drivers/video/s1d13xxxfb.c
index 0deb0a8..d3059cd 100644
--- a/drivers/video/s1d13xxxfb.c
+++ b/drivers/video/s1d13xxxfb.c
@@ -409,28 +409,6 @@ s1d13xxxfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
  ************************************************************/
 
 /**
- *	bltbit_wait_bitset - waits for change in register value
- *	@info : framebuffer structure
- *	@bit  : value expected in register
- *	@timeout : ...
- *
- *	waits until value changes INTO bit
- */
-static u8
-bltbit_wait_bitset(struct fb_info *info, u8 bit, int timeout)
-{
-	while (!(s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit)) {
-		udelay(10);
-		if (!--timeout) {
-			dbg_blit("wait_bitset timeout\n");
-			break;
-		}
-	}
-
-	return timeout;
-}
-
-/**
  *	bltbit_wait_bitclear - waits for change in register value
  *	@info : frambuffer structure
  *	@bit  : value currently in register
@@ -453,34 +431,6 @@ bltbit_wait_bitclear(struct fb_info *info, u8 bit, int timeout)
 	return timeout;
 }
 
-/**
- *	bltbit_fifo_status - checks the current status of the fifo
- *	@info : framebuffer structure
- *
- *	returns number of free words in buffer
- */
-static u8
-bltbit_fifo_status(struct fb_info *info)
-{
-	u8 status;
-
-	status = s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0);
-
-	/* its empty so room for 16 words */
-	if (status & BBLT_FIFO_EMPTY)
-		return 16;
-
-	/* its full so we dont want to add */
-	if (status & BBLT_FIFO_FULL)
-		return 0;
-
-	/* its atleast half full but we can add one atleast */
-	if (status & BBLT_FIFO_NOT_FULL)
-		return 1;
-
-	return 0;
-}
-
 /*
  *	s1d13xxxfb_bitblt_copyarea - accelerated copyarea function
  *	@info : framebuffer structure
-- 
1.6.5.2

[PATCH 1/1] Removed Dead Code

[Michael Spradling]

Signed-off-by: Michael Spradling <mike@mspradling.com>

---
 drivers/video/s1d13xxxfb.c |   50 --------------------------------------------
 1 files changed, 0 insertions(+), 50 deletions(-)

diff --git a/drivers/video/s1d13xxxfb.c b/drivers/video/s1d13xxxfb.c
index 0deb0a8..d3059cd 100644
--- a/drivers/video/s1d13xxxfb.c
+++ b/drivers/video/s1d13xxxfb.c
@@ -409,28 +409,6 @@ s1d13xxxfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
  ************************************************************/
 
 /**
- *	bltbit_wait_bitset - waits for change in register value
- *	@info : framebuffer structure
- *	@bit  : value expected in register
- *	@timeout : ...
- *
- *	waits until value changes INTO bit
- */
-static u8
-bltbit_wait_bitset(struct fb_info *info, u8 bit, int timeout)
-{
-	while (!(s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit)) {
-		udelay(10);
-		if (!--timeout) {
-			dbg_blit("wait_bitset timeout\n");
-			break;
-		}
-	}
-
-	return timeout;
-}
-
-/**
  *	bltbit_wait_bitclear - waits for change in register value
  *	@info : frambuffer structure
  *	@bit  : value currently in register
@@ -453,34 +431,6 @@ bltbit_wait_bitclear(struct fb_info *info, u8 bit, int timeout)
 	return timeout;
 }
 
-/**
- *	bltbit_fifo_status - checks the current status of the fifo
- *	@info : framebuffer structure
- *
- *	returns number of free words in buffer
- */
-static u8
-bltbit_fifo_status(struct fb_info *info)
-{
-	u8 status;
-
-	status = s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0);
-
-	/* its empty so room for 16 words */
-	if (status & BBLT_FIFO_EMPTY)
-		return 16;
-
-	/* its full so we dont want to add */
-	if (status & BBLT_FIFO_FULL)
-		return 0;
-
-	/* its atleast half full but we can add one atleast */
-	if (status & BBLT_FIFO_NOT_FULL)
-		return 1;
-
-	return 0;
-}
-
 /*
  *	s1d13xxxfb_bitblt_copyarea - accelerated copyarea function
  *	@info : framebuffer structure
-- 
1.6.5.2

[PATCH 1/1] Removed Dead Code

[Michael Spradling]

Signed-off-by: Michael Spradling <mike@mspradling.com>

---
 drivers/video/s1d13xxxfb.c |   50 --------------------------------------------
 1 files changed, 0 insertions(+), 50 deletions(-)

diff --git a/drivers/video/s1d13xxxfb.c b/drivers/video/s1d13xxxfb.c
index 0deb0a8..d3059cd 100644
--- a/drivers/video/s1d13xxxfb.c
+++ b/drivers/video/s1d13xxxfb.c
@@ -409,28 +409,6 @@ s1d13xxxfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
  ************************************************************/
 
 /**
- *	bltbit_wait_bitset - waits for change in register value
- *	@info : framebuffer structure
- *	@bit  : value expected in register
- *	@timeout : ...
- *
- *	waits until value changes INTO bit
- */
-static u8
-bltbit_wait_bitset(struct fb_info *info, u8 bit, int timeout)
-{
-	while (!(s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit)) {
-		udelay(10);
-		if (!--timeout) {
-			dbg_blit("wait_bitset timeout\n");
-			break;
-		}
-	}
-
-	return timeout;
-}
-
-/**
  *	bltbit_wait_bitclear - waits for change in register value
  *	@info : frambuffer structure
  *	@bit  : value currently in register
@@ -453,34 +431,6 @@ bltbit_wait_bitclear(struct fb_info *info, u8 bit, int timeout)
 	return timeout;
 }
 
-/**
- *	bltbit_fifo_status - checks the current status of the fifo
- *	@info : framebuffer structure
- *
- *	returns number of free words in buffer
- */
-static u8
-bltbit_fifo_status(struct fb_info *info)
-{
-	u8 status;
-
-	status = s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0);
-
-	/* its empty so room for 16 words */
-	if (status & BBLT_FIFO_EMPTY)
-		return 16;
-
-	/* its full so we dont want to add */
-	if (status & BBLT_FIFO_FULL)
-		return 0;
-
-	/* its atleast half full but we can add one atleast */
-	if (status & BBLT_FIFO_NOT_FULL)
-		return 1;
-
-	return 0;
-}
-
 /*
  *	s1d13xxxfb_bitblt_copyarea - accelerated copyarea function
  *	@info : framebuffer structure
-- 
1.6.5.2

Re: [PATCH 1/1] Removed Dead Code

[Michael Spradling]

Does anyone have any comments, how do I know if this patch is ever taken in...
Is there a server somewhere that shows integration status

On Tue, Nov 17, 2009 at 12:38:47AM -0500, Michael Spradling wrote:
> Signed-off-by: Michael Spradling <mike@mspradling.com>
> 
> ---
>  drivers/video/s1d13xxxfb.c |   50 --------------------------------------------
>  1 files changed, 0 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/video/s1d13xxxfb.c b/drivers/video/s1d13xxxfb.c
> index 0deb0a8..d3059cd 100644
> --- a/drivers/video/s1d13xxxfb.c
> +++ b/drivers/video/s1d13xxxfb.c
> @@ -409,28 +409,6 @@ s1d13xxxfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
>   ************************************************************/
>  
>  /**
> - *	bltbit_wait_bitset - waits for change in register value
> - *	@info : framebuffer structure
> - *	@bit  : value expected in register
> - *	@timeout : ...
> - *
> - *	waits until value changes INTO bit
> - */
> -static u8
> -bltbit_wait_bitset(struct fb_info *info, u8 bit, int timeout)
> -{
> -	while (!(s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit)) {
> -		udelay(10);
> -		if (!--timeout) {
> -			dbg_blit("wait_bitset timeout\n");
> -			break;
> -		}
> -	}
> -
> -	return timeout;
> -}
> -
> -/**
>   *	bltbit_wait_bitclear - waits for change in register value
>   *	@info : frambuffer structure
>   *	@bit  : value currently in register
> @@ -453,34 +431,6 @@ bltbit_wait_bitclear(struct fb_info *info, u8 bit, int timeout)
>  	return timeout;
>  }
>  
> -/**
> - *	bltbit_fifo_status - checks the current status of the fifo
> - *	@info : framebuffer structure
> - *
> - *	returns number of free words in buffer
> - */
> -static u8
> -bltbit_fifo_status(struct fb_info *info)
> -{
> -	u8 status;
> -
> -	status = s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0);
> -
> -	/* its empty so room for 16 words */
> -	if (status & BBLT_FIFO_EMPTY)
> -		return 16;
> -
> -	/* its full so we dont want to add */
> -	if (status & BBLT_FIFO_FULL)
> -		return 0;
> -
> -	/* its atleast half full but we can add one atleast */
> -	if (status & BBLT_FIFO_NOT_FULL)
> -		return 1;
> -
> -	return 0;
> -}
> -
>  /*
>   *	s1d13xxxfb_bitblt_copyarea - accelerated copyarea function
>   *	@info : framebuffer structure
> -- 
> 1.6.5.2
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] Removed Dead Code

[Nicolas Palix]

On Wednesday 18 November 2009 01:12:22 Michael Spradling wrote:
> Does anyone have any comments, how do I know if this patch is ever taken in...
> Is there a server somewhere that shows integration status

Declare linux-next in your git repository with
git remote add linux-next <url>

<url> can be one of the following:
http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Then, retrieve daily release with git remote update.
You can use GUI, like qgit, or git log, and search for your name.

For info about linux-next, check
http://linux.f-seidel.de/linux-next/pmwiki/pmwiki.php?n=Linux-next.Linux-next

Alternatively, you can check the gitweb server of linux-next
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary

> 
> On Tue, Nov 17, 2009 at 12:38:47AM -0500, Michael Spradling wrote:
> > Signed-off-by: Michael Spradling <mike@mspradling.com>
> > 
> > ---
> >  drivers/video/s1d13xxxfb.c |   50 --------------------------------------------
> >  1 files changed, 0 insertions(+), 50 deletions(-)
> > 
> > diff --git a/drivers/video/s1d13xxxfb.c b/drivers/video/s1d13xxxfb.c
> > index 0deb0a8..d3059cd 100644
> > --- a/drivers/video/s1d13xxxfb.c
> > +++ b/drivers/video/s1d13xxxfb.c
> > @@ -409,28 +409,6 @@ s1d13xxxfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
> >   ************************************************************/
> >  
> >  /**
> > - *	bltbit_wait_bitset - waits for change in register value
> > - *	@info : framebuffer structure
> > - *	@bit  : value expected in register
> > - *	@timeout : ...
> > - *
> > - *	waits until value changes INTO bit
> > - */
> > -static u8
> > -bltbit_wait_bitset(struct fb_info *info, u8 bit, int timeout)
> > -{
> > -	while (!(s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit)) {
> > -		udelay(10);
> > -		if (!--timeout) {
> > -			dbg_blit("wait_bitset timeout\n");
> > -			break;
> > -		}
> > -	}
> > -
> > -	return timeout;
> > -}
> > -
> > -/**
> >   *	bltbit_wait_bitclear - waits for change in register value
> >   *	@info : frambuffer structure
> >   *	@bit  : value currently in register
> > @@ -453,34 +431,6 @@ bltbit_wait_bitclear(struct fb_info *info, u8 bit, int timeout)
> >  	return timeout;
> >  }
> >  
> > -/**
> > - *	bltbit_fifo_status - checks the current status of the fifo
> > - *	@info : framebuffer structure
> > - *
> > - *	returns number of free words in buffer
> > - */
> > -static u8
> > -bltbit_fifo_status(struct fb_info *info)
> > -{
> > -	u8 status;
> > -
> > -	status = s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0);
> > -
> > -	/* its empty so room for 16 words */
> > -	if (status & BBLT_FIFO_EMPTY)
> > -		return 16;
> > -
> > -	/* its full so we dont want to add */
> > -	if (status & BBLT_FIFO_FULL)
> > -		return 0;
> > -
> > -	/* its atleast half full but we can add one atleast */
> > -	if (status & BBLT_FIFO_NOT_FULL)
> > -		return 1;
> > -
> > -	return 0;
> > -}
> > -
> >  /*
> >   *	s1d13xxxfb_bitblt_copyarea - accelerated copyarea function
> >   *	@info : framebuffer structure
> > -- 
> > 1.6.5.2
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Nicolas Palix

Re: [PATCH 1/1] Removed Dead Code

[Bernd Petrovitsch]

On Tue, 2009-11-17 at 19:12 -0500, Michael Spradling wrote:
> Does anyone have any comments, how do I know if this patch is ever taken in...
Yes (but perhaps not the one you expected;-).
A review takes usually more than a day (since people tend to have other,
higher priorities too). And BTW it doesn't speed up if you send the same
3 times without good reason (and if there is a good reason, there is no
need to hide it). And the subject as above is *much* better (as it
describes the intentions of the patch and not your personal ones) than
the one on the 1st mail.

A good way to speed up the review process is to send the mail also
directly to the relevant maintainers and interested people (and probably
the big kernel-mailinglist. No need to subscribe it - it is expected
that people use Reply-to-all and not delete any Cc:s - unless you really
know what you do[0]). The simplest way is to use
scripts/get_maintainer.pl to get a list of probably interested and
*relevant* (read: subsystem maintainer) people/mailing-lists.

Even if 5 people review and ack-it hereover, it is no help as long as
the maintainer(s) ignore it (or NACK it for whatever reason).

As for the patch as such: Not that I looked into the framebuffer
driver(s) or anywhere else, but it's probably good to also mention why
you believe that that functions are dead code.
There basically two possibilities: Was in for ages and isn't used any
longer or is needed for new features. And the subsystem maintainer
should know (and I don't know - so I can't comment on it) .....

> Is there a server somewhere that shows integration status
Not until you run one;-)
You usually should get some feedback who is taking it and - depending on
subsystem, it's maintainer, the length of the chain towards Linux,
release dates, etc. - it eventually shows up in mainline and you may get
some status mails before (e.g. AKPM has scripts which also report
towards submitters - and reviewers IIRC).

	Bernd

[0]: *If* you really know what you do, you will know it on your own.
     Before, just stick to the rule;-)
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [PATCH 1/1] Removed Dead Code

[Michael Spradling]

I know it takes more than a day to take a patch in, however I just wanted to know
a little more about the process.  Sorry about the 3 emails.  If you look at the
headers you will notice they are all from different email accounts.  I had trouble
with my email and I did not see my messages post to the mailing list. Thanks for
your advice and input....

I was just wondering how one checks the status of it.
On Wed, Nov 18, 2009 at 01:01:51PM +0100, Bernd Petrovitsch wrote:
> On Tue, 2009-11-17 at 19:12 -0500, Michael Spradling wrote:
> > Does anyone have any comments, how do I know if this patch is ever taken in...
> Yes (but perhaps not the one you expected;-).
> A review takes usually more than a day (since people tend to have other,
> higher priorities too). And BTW it doesn't speed up if you send the same
> 3 times without good reason (and if there is a good reason, there is no
> need to hide it). And the subject as above is *much* better (as it
> describes the intentions of the patch and not your personal ones) than
> the one on the 1st mail.
> 
> A good way to speed up the review process is to send the mail also
> directly to the relevant maintainers and interested people (and probably
> the big kernel-mailinglist. No need to subscribe it - it is expected
> that people use Reply-to-all and not delete any Cc:s - unless you really
> know what you do[0]). The simplest way is to use
> scripts/get_maintainer.pl to get a list of probably interested and
> *relevant* (read: subsystem maintainer) people/mailing-lists.
> 
> Even if 5 people review and ack-it hereover, it is no help as long as
> the maintainer(s) ignore it (or NACK it for whatever reason).
> 
> As for the patch as such: Not that I looked into the framebuffer
> driver(s) or anywhere else, but it's probably good to also mention why
> you believe that that functions are dead code.
> There basically two possibilities: Was in for ages and isn't used any
> longer or is needed for new features. And the subsystem maintainer
> should know (and I don't know - so I can't comment on it) .....
> 
> > Is there a server somewhere that shows integration status
> Not until you run one;-)
> You usually should get some feedback who is taking it and - depending on
> subsystem, it's maintainer, the length of the chain towards Linux,
> release dates, etc. - it eventually shows up in mainline and you may get
> some status mails before (e.g. AKPM has scripts which also report
> towards submitters - and reviewers IIRC).
> 
> 	Bernd
> 
> [0]: *If* you really know what you do, you will know it on your own.
>      Before, just stick to the rule;-)
> -- 
> Firmix Software GmbH                   http://www.firmix.at/
> mobil: +43 664 4416156                 fax: +43 1 7890849-55
>           Embedded Linux Development and Services
> 
> 

Re: [PATCH 1/1] Removed Dead Code

[Michael Spradling]

I did base my patch on the linux-next tree.  I think I will just sit back and
be patient.  I don't want to spam the list with patches that do fit with the
communities standards.

Thanks
Michael

On Wed, Nov 18, 2009 at 10:05:09AM +0100, Nicolas Palix wrote:
> On Wednesday 18 November 2009 01:12:22 Michael Spradling wrote:
> > Does anyone have any comments, how do I know if this patch is ever taken in...
> > Is there a server somewhere that shows integration status
> 
> Declare linux-next in your git repository with
> git remote add linux-next <url>
> 
> <url> can be one of the following:
> http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> 
> Then, retrieve daily release with git remote update.
> You can use GUI, like qgit, or git log, and search for your name.
> 
> For info about linux-next, check
> http://linux.f-seidel.de/linux-next/pmwiki/pmwiki.php?n=Linux-next.Linux-next
> 
> Alternatively, you can check the gitweb server of linux-next
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary
> 
> > 
> > On Tue, Nov 17, 2009 at 12:38:47AM -0500, Michael Spradling wrote:
> > > Signed-off-by: Michael Spradling <mike@mspradling.com>
> > > 
> > > ---
> > >  drivers/video/s1d13xxxfb.c |   50 --------------------------------------------
> > >  1 files changed, 0 insertions(+), 50 deletions(-)
> > > 
> > > diff --git a/drivers/video/s1d13xxxfb.c b/drivers/video/s1d13xxxfb.c
> > > index 0deb0a8..d3059cd 100644
> > > --- a/drivers/video/s1d13xxxfb.c
> > > +++ b/drivers/video/s1d13xxxfb.c
> > > @@ -409,28 +409,6 @@ s1d13xxxfb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
> > >   ************************************************************/
> > >  
> > >  /**
> > > - *	bltbit_wait_bitset - waits for change in register value
> > > - *	@info : framebuffer structure
> > > - *	@bit  : value expected in register
> > > - *	@timeout : ...
> > > - *
> > > - *	waits until value changes INTO bit
> > > - */
> > > -static u8
> > > -bltbit_wait_bitset(struct fb_info *info, u8 bit, int timeout)
> > > -{
> > > -	while (!(s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0) & bit)) {
> > > -		udelay(10);
> > > -		if (!--timeout) {
> > > -			dbg_blit("wait_bitset timeout\n");
> > > -			break;
> > > -		}
> > > -	}
> > > -
> > > -	return timeout;
> > > -}
> > > -
> > > -/**
> > >   *	bltbit_wait_bitclear - waits for change in register value
> > >   *	@info : frambuffer structure
> > >   *	@bit  : value currently in register
> > > @@ -453,34 +431,6 @@ bltbit_wait_bitclear(struct fb_info *info, u8 bit, int timeout)
> > >  	return timeout;
> > >  }
> > >  
> > > -/**
> > > - *	bltbit_fifo_status - checks the current status of the fifo
> > > - *	@info : framebuffer structure
> > > - *
> > > - *	returns number of free words in buffer
> > > - */
> > > -static u8
> > > -bltbit_fifo_status(struct fb_info *info)
> > > -{
> > > -	u8 status;
> > > -
> > > -	status = s1d13xxxfb_readreg(info->par, S1DREG_BBLT_CTL0);
> > > -
> > > -	/* its empty so room for 16 words */
> > > -	if (status & BBLT_FIFO_EMPTY)
> > > -		return 16;
> > > -
> > > -	/* its full so we dont want to add */
> > > -	if (status & BBLT_FIFO_FULL)
> > > -		return 0;
> > > -
> > > -	/* its atleast half full but we can add one atleast */
> > > -	if (status & BBLT_FIFO_NOT_FULL)
> > > -		return 1;
> > > -
> > > -	return 0;
> > > -}
> > > -
> > >  /*
> > >   *	s1d13xxxfb_bitblt_copyarea - accelerated copyarea function
> > >   *	@info : framebuffer structure
> > > -- 
> > > 1.6.5.2
> > > 
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> 
> -- 
> Nicolas Palix

Re: [PATCH 1/1] Removed Dead Code

[Bernd Petrovitsch]

On Wed, 2009-11-18 at 07:11 -0500, Michael Spradling wrote:
> I know it takes more than a day to take a patch in, however I just wanted to know
> a little more about the process.  Sorry about the 3 emails.  If you look at the
E.g. Documentation/SubmittingPatches has more. Perhaps the LKML-FAQ
(google it, it's easy to find).

> headers you will notice they are all from different email accounts.  I had trouble
I didn't notice (and obviously didn't look good enough).

> with my email and I did not see my messages post to the mailing list. Thanks for
That may also take some time as vger.kernel.org hosts quite a few lists
with not so few subscribers and it also depends on the receiving side
(think of e.g. greylisting and/or overloaded spam- and virus-scanners
because of the next spam flood), it may take some time.
Email isn't (and never was) a realtime in any way.

> your advice and input....
And for the future: fullquoting is the most unreadable way to quote
emails (let alone *comment* on the and *review* the contents)[0]. Google
the netiquette - as the URL I know by heart is in German - (even it's
from Usenet/newsgroups) and "learn to quote". SCNR - I always wanted to
write that once;-)

[ Useless fullquote deleted. People can find it via google after a few
hours/days(?) or in their inbox anyways. ]

	Bernd

[0]: Think of the possibility that many people - /me included - may
     plain simply choose to ignore unreadable and/or not (and/or hardly)
     understandable emails. The language barrier may be a small part of
     it (and abused as an excuse - no need to excuse, just make it
     better the next time) but the more important issue is to make
     reading your emails as easy as possible[1].
     If the other doesn't have time or motivation to invest 5 minutes in
     a cleanly formatted mail with simple and easy to read sentences
     because punctuation and spelling is OK, why should I invest 5
     minutes to try to decode what that wants to say?
     And id the sender invests only 30 minutes to really make sure that
     misinterpretations should not happen because every comment is
     worded simple, placed at the place where the comment belongs and
     irrelevant lines are deleted, that is next to no investment even if
     you save only 2 minutes for each reader (because on the more
     crowded lists you will have probably have much moire readers than
     you thought - even if they don't answer. While I'm at it: "Me
     too!" mails are discouraged too - unless explicitly asked).
[1]: For the more commercial/business oriented people: Think of each
     email as another type of business card.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [PATCH 1/1] Removed Dead Code

[Davidlohr Bueso]

On Tue, Nov 17, 2009 at 07:12:22PM -0500, Michael Spradling wrote:
> Does anyone have any comments, how do I know if this patch is ever taken in...
> Is there a server somewhere that shows integration status

You should also always CC the LKML and of course the maintainer of the piece of code you are changing, in this case:

Kristoffer Ericson <kristoffer.ericson@gmail.com>


Davidlohr.