Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 27 Apr 2019 08:41:17 +0200
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Kimberly Brown <kimbrownkd@gmail.com>
Cc:     linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/8] kobject: Add default group support to kobj_type
 and replace subsystem uses
Message-ID: <20190427064117.GA15575@kroah.com>
References: <20190322201440.GA30814@ubu-Virtual-Machine>
 <cover.1554151487.git.kimbrownkd@gmail.com>
 <20190425201253.GA12131@kroah.com>
 <20190427061856.GA675@ubu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190427061856.GA675@ubu>
User-Agent: Mutt/1.11.4 (2019-03-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Apr 27, 2019 at 02:18:56AM -0400, Kimberly Brown wrote:
> On Thu, Apr 25, 2019 at 10:12:53PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Apr 01, 2019 at 10:51:10PM -0400, Kimberly Brown wrote:
> > > This patchset adds support for default attribute groups to kobj_type.
> > > Also, the uses of kobj_type's default_attrs field are replaced with
> > > default_groups in the following subsystems:
> > >  - samples
> > >  - block
> > >  - net
> > >  - irq
> > >  - padata
> > >  - cpufreq
> > >  - livepatch
> > > 
> > > The subsystem maintainers and lists will be copied on the subsystem
> > > patches.
> > > 
> > > The uses of kobj_type's default_attrs field in the other subsystems will
> > > be replaced in future patchsets.
> > 
> > Thanks for all of these, now queued up.  Patches to fix up the other
> > subsystems are always welcome :)
> > 
> > greg k-h
> 
> Thanks, Greg! I'll start preparing more patches.
> 
> I know that patches should be in linux-next for some time before the
> merge window opens. How long do they typically need to be in linux-next?

It depends on the maintainer, what they feel like.  I like to have a
week or so, but some like more, and others less.

Sorry there's not a single answer.

> I'm trying to figure out if the next patches I work on could be included
> in the next merge window, in which case I'll let the maintainers know
> that the patch will either need to go through the driver-core tree or
> wait for the next release cycle.

Mention that I can take them all through my tree now, as that's usually
the easiest thing for api changes like this.

thanks,

greg k-h