lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140630104744.GB2486@localhost>
Date:	Mon, 30 Jun 2014 12:47:44 +0200
From:	Johan Hovold <johan@...nel.org>
To:	Bryan Wu <cooloney@...il.com>
Cc:	Jiri Kosina <jkosina@...e.cz>, Johan Hovold <johan@...nel.org>,
	Janne Kanniainen <janne.kanniainen@...il.com>,
	Greg Kroah-Hartman <greg@...ah.com>,
	Bjørn Mork <bjorn@...k.no>,
	lkml <linux-kernel@...r.kernel.org>,
	Linux LED Subsystem <linux-leds@...r.kernel.org>,
	linux-usb@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: [PATCH 2/2 v2] HID: leds: Use attribute-groups in MSI GT683R
 driver

On Wed, Jun 25, 2014 at 03:55:10PM -0700, Bryan Wu wrote:
> On Wed, Jun 25, 2014 at 12:09 PM, Jiri Kosina <jkosina@...e.cz> wrote:
> > On Wed, 25 Jun 2014, Johan Hovold wrote:
> >
> >> Did you see the attribute-race series I posted? Not sure how best to
> >> handle the dependency, as those patches should probably go in through
> >> the LEDs tree, while the first patch in that series (adding the groups
> >> field) is a dependency for this patch.
> >>
> >> Jiri, how would this best be solved?
> >
> > I think the best course of action here is to gather Acks from the
> > respective maintainers, and take the whole lot trough a single tree
> > (probably the leds tree in this case) to avoid unnecessary intra-tree
> > dependencies in a rather straighforward situation like this.
> 
> I think the better place is HID/input tree, since this patch depends
> on the initial one which is not in my tree.
> I'm going to merge Johan's whole patchset and this patch probably
> depends Johan's work too.

Dmitry has ACKed the input-patch and Bryan has applied that one and the
leds-patches to his tree (of which the first one is a dependency of this
patch).

Jiri, are you saying that the gt683r-driver should go in through his
tree as well, that is all three patches including the first that you
have already applied? I just assumed your for-next branch was immutable,
but perhaps I was mistaken.

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ