linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Harald Welte <laforge@gnumonks.org>
Cc: mail@joachim-breitner.de, linux-kernel@vger.kernel.org,
	linux@dominikbrodowski.net
Subject: Re: [PATCH] [CM4000,CM4040] Add device class bits to enable udev device creation
Date: Tue, 14 Feb 2006 00:16:19 -0800	[thread overview]
Message-ID: <20060214001619.391fa4b4.akpm@osdl.org> (raw)
In-Reply-To: <20060214080542.GB4605@sunbeam.de.gnumonks.org>

Harald Welte <laforge@gnumonks.org> wrote:
>
> On Tue, Jan 31, 2006 at 06:09:27PM -0800, Andrew Morton wrote:
> > Harald Welte <laforge@gnumonks.org> wrote:
> > >
> > > Please apply this fix to the cm4000/4040 drivers, thanks!
> > > 
> > >  [CM4000,CM4040] Add device class bits to enable udev device creation
> > > 
> > >  Using this patch, Omnikey CardMan 4000 and 4040 devices automatically
> > >  get their device nodes created by udev.
> > 
> > Dominik has made quite widespread changes to these drivers - enough that
> > I'm not confident to fix the rejects, make it compile and hope that it
> > still works.
> 
> sorry for that.  I honestly don't have the time to track two trees, and
> I do all my development work against Linus' main tree, therefore my
> patches are against that tree, too.

Dominik maintains the pcmcia development tree, and these are
pcmcia drivers...

> > So can you please sort things out with Dominik?  I guess a tested patch
> > against -mm4 would be ideal.
> 
> The question is: Why wouldn't my patch directly go mainline but rather
> via -mm?  It is a very special-purpose device, the number of users are
> small, it clearly fixes the bug that no device nodes are created, and
> the fix came from the original maintainer.

pcmcia patches should preferably go via the pcmcia development tree, and
get integrated and reviewed by the maintainer and all that good stuff.

So it wouldn't go via -mm at all - pcmcia only goes into -mm for testing.


The more specific point is that your patch conflicted with Dominik's
current development tree in a big way.   That needs to get sorted out.

  reply	other threads:[~2006-02-14  8:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1138536696.6509.9.camel@otto.ehbuehl.net>
     [not found] ` <1138541796.6395.8.camel@otto.ehbuehl.net>
2006-01-31 10:10   ` [PATCH] [CM4000,CM4040] Add device class bits to enable udev device creation Harald Welte
2006-02-01  2:09     ` Andrew Morton
2006-02-14  8:05       ` Harald Welte
2006-02-14  8:16         ` Andrew Morton [this message]
2006-02-14  8:30           ` Harald Welte
     [not found]     ` <200601312259.32863.dtor_core@ameritech.net>
2006-02-01  9:03       ` Harald Welte

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=20060214001619.391fa4b4.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=laforge@gnumonks.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=mail@joachim-breitner.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).