All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Manuel Schoelling <manuel.schoelling@gmx.de>
Cc: devel@driverdev.osuosl.org, arnd@arndb.de,
	peter.p.waskiewicz.jr@intel.com, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org, khoroshilov@ispras.ru
Subject: Re: [PATCH] staging: gdm72xx: use time_before()
Date: Sun, 25 May 2014 18:33:05 +0000	[thread overview]
Message-ID: <20140525183305.GA11364@kroah.com> (raw)
In-Reply-To: <1401042273.7538.10.camel@schoellingm.dzne.de>

On Sun, May 25, 2014 at 08:24:33PM +0200, Manuel Schoelling wrote:
> On So, 2014-05-25 at 11:14 -0700, Greg KH wrote:
> > On Sun, May 25, 2014 at 03:08:59PM +0200, Manuel Schölling wrote:
> > > To be future-proof and for better readability the time comparisons are
> > > modified to use time_before() instead of plain, error-prone math.
> > > 
> > > Signed-off-by: Manuel Schölling <manuel.schoelling@gmx.de>
> > > ---
> > >  drivers/staging/gdm72xx/gdm_usb.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > This patch doesn't apply, can you please refresh it against my latest
> > tree and resend?
> That's weird. I pulled the lastest master from Linus and rebased the
> patch, but no modification of my patch was required (latest commit
> before my patch to that file was
> 8943a92fc257c439ffe55fb0f9896be57c58c56b according to my repo). 
> 
> Maybe you have a more recent version than Linus?


I have a much different version from Linus, with a few thousand patches
added, otherwise how would I be able to queue up stuff to go to Linus
for the next kernel release?  :)

For the staging patches, either use the linux-next tree (which you
should use for all kernel development), or my staging.git tree, and the
staging-next branch on git.kernel.org, which is what gets pulled into
linux-next every week-day.

If you have more questions about this, take a look at
Documentation/development-process/  it should explain how patches move
to Linus and why working against Linus's tree isn't going to get you
very far.

thanks,

greg k-h
--
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

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Manuel Schoelling <manuel.schoelling@gmx.de>
Cc: devel@driverdev.osuosl.org, arnd@arndb.de,
	peter.p.waskiewicz.jr@intel.com, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org, khoroshilov@ispras.ru
Subject: Re: [PATCH] staging: gdm72xx: use time_before()
Date: Sun, 25 May 2014 11:33:05 -0700	[thread overview]
Message-ID: <20140525183305.GA11364@kroah.com> (raw)
In-Reply-To: <1401042273.7538.10.camel@schoellingm.dzne.de>

On Sun, May 25, 2014 at 08:24:33PM +0200, Manuel Schoelling wrote:
> On So, 2014-05-25 at 11:14 -0700, Greg KH wrote:
> > On Sun, May 25, 2014 at 03:08:59PM +0200, Manuel Schölling wrote:
> > > To be future-proof and for better readability the time comparisons are
> > > modified to use time_before() instead of plain, error-prone math.
> > > 
> > > Signed-off-by: Manuel Schölling <manuel.schoelling@gmx.de>
> > > ---
> > >  drivers/staging/gdm72xx/gdm_usb.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > This patch doesn't apply, can you please refresh it against my latest
> > tree and resend?
> That's weird. I pulled the lastest master from Linus and rebased the
> patch, but no modification of my patch was required (latest commit
> before my patch to that file was
> 8943a92fc257c439ffe55fb0f9896be57c58c56b according to my repo). 
> 
> Maybe you have a more recent version than Linus?


I have a much different version from Linus, with a few thousand patches
added, otherwise how would I be able to queue up stuff to go to Linus
for the next kernel release?  :)

For the staging patches, either use the linux-next tree (which you
should use for all kernel development), or my staging.git tree, and the
staging-next branch on git.kernel.org, which is what gets pulled into
linux-next every week-day.

If you have more questions about this, take a look at
Documentation/development-process/  it should explain how patches move
to Linus and why working against Linus's tree isn't going to get you
very far.

thanks,

greg k-h

  reply	other threads:[~2014-05-25 18:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-25 13:08 [PATCH] gdm72xx: use time_before() Manuel Schölling
2014-05-25 13:08 ` Manuel Schölling
2014-05-25 18:14 ` [PATCH] staging: " Greg KH
2014-05-25 18:14   ` Greg KH
2014-05-25 18:24   ` Manuel Schoelling
2014-05-25 18:24     ` Manuel Schoelling
2014-05-25 18:33     ` Greg KH [this message]
2014-05-25 18:33       ` Greg KH
2014-05-25 18:43       ` Manuel Schoelling
2014-05-25 18:43         ` Manuel Schoelling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140525183305.GA11364@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arnd@arndb.de \
    --cc=devel@driverdev.osuosl.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=khoroshilov@ispras.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manuel.schoelling@gmx.de \
    --cc=peter.p.waskiewicz.jr@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.