All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
To: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>
Cc: "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
	MANAGEM..." <alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org>,
	Linaro Kernel Mailman List
	<linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
	"open list:TARGET SUBSYSTEM"
	<linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Viresh Kumar
	<viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:"
	<linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:NETWORKING DRIVERS (WIRELESS)"
	<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	QCA ath9k Development
	<ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Intel Linux Wireless
	<ilw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Linux ACPI <linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:AMD IOMMU (AMD-VI)"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	"open list:BLUETOOTH DRIVERS"
	<linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux Memory Management List
	<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	Greg Kroah-Hartman <gregkh@li>
Subject: Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
Date: Sat, 26 Sep 2015 12:52:08 -0700	[thread overview]
Message-ID: <1443297128.2181.11.camel@HansenPartnership.com> (raw)
In-Reply-To: <2524822.pQu4UKMrlb-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>

On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
> > > You're going to change that into bool in the next patch, right?
> > 
> > Yeah.
> > 
> > > So what if bool is a byte and the field is not word-aligned
> > 
> > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > So, it will be aligned, isn't it?
> > 
> > > and changing
> > > that byte requires a read-modify-write.  How do we ensure that things remain
> > > consistent in that case?
> > 
> > I didn't understood why a read-modify-write is special here? That's
> > what will happen
> > to most of the non-word-sized fields anyway?
> > 
> > Probably I didn't understood what you meant..
> 
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
> 
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> 
> What's the result?

I think every CPU's  cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2.  If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was usually fixed by
padding (assuming the structure is not packed).  However, it was such a
problem that even the later alpha chips had byte extensions.

James

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Johannes Berg <johannes@sipsolutions.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>,
	QCA ath9k Development <ath9k-devel@qca.qualcomm.com>,
	Intel Linux Wireless <ilw@linux.intel.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	"open list:BLUETOOTH DRIVERS" <linux-bluetooth@vger.kernel.org>,
	"open list:AMD IOMMU (AMD-VI)" <iommu@lists.linux-foundation.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"open list:NETWORKING DRIVERS (WIRELESS)"
	<linux-wireless@vger.kernel.org>,
	"open list:TARGET SUBSYSTEM" <linux-scsi@vger.kernel.org>,
	"open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:"
	<linux-usb@vger.kernel.org>,
	"open list:EDAC-CORE" <linux-edac@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	"moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
	MANAGEM..." <alsa-devel@alsa-project.org>
Subject: Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
Date: Sat, 26 Sep 2015 12:52:08 -0700	[thread overview]
Message-ID: <1443297128.2181.11.camel@HansenPartnership.com> (raw)
In-Reply-To: <2524822.pQu4UKMrlb@vostro.rjw.lan>

On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > You're going to change that into bool in the next patch, right?
> > 
> > Yeah.
> > 
> > > So what if bool is a byte and the field is not word-aligned
> > 
> > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > So, it will be aligned, isn't it?
> > 
> > > and changing
> > > that byte requires a read-modify-write.  How do we ensure that things remain
> > > consistent in that case?
> > 
> > I didn't understood why a read-modify-write is special here? That's
> > what will happen
> > to most of the non-word-sized fields anyway?
> > 
> > Probably I didn't understood what you meant..
> 
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
> 
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> 
> What's the result?

I think every CPU's  cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2.  If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was usually fixed by
padding (assuming the structure is not packed).  However, it was such a
problem that even the later alpha chips had byte extensions.

James



WARNING: multiple messages have this Message-ID (diff)
From: James.Bottomley@HansenPartnership.com (James Bottomley)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
Date: Sat, 26 Sep 2015 12:52:08 -0700	[thread overview]
Message-ID: <1443297128.2181.11.camel@HansenPartnership.com> (raw)
In-Reply-To: <2524822.pQu4UKMrlb@vostro.rjw.lan>

On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > You're going to change that into bool in the next patch, right?
> > 
> > Yeah.
> > 
> > > So what if bool is a byte and the field is not word-aligned
> > 
> > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > So, it will be aligned, isn't it?
> > 
> > > and changing
> > > that byte requires a read-modify-write.  How do we ensure that things remain
> > > consistent in that case?
> > 
> > I didn't understood why a read-modify-write is special here? That's
> > what will happen
> > to most of the non-word-sized fields anyway?
> > 
> > Probably I didn't understood what you meant..
> 
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
> 
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> 
> What's the result?

I think every CPU's  cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2.  If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was usually fixed by
padding (assuming the structure is not packed).  However, it was such a
problem that even the later alpha chips had byte extensions.

James

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Johannes Berg <johannes@sipsolutions.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>,
	QCA ath9k Development <ath9k-devel@qca.qualcomm.com>,
	Intel Linux Wireless <ilw@linux.intel.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	"open list:BLUETOOTH DRIVERS" <linux-bluetooth@vger.kernel.org>,
	"open list:AMD IOMMU (AMD-VI)" <iommu@lists.linux-foundation.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"open list:NETWORKING DRIVERS (WIRELESS)"
	<linux-wireless@vger.kernel.org>,
	"open list:TARGET SUBSYSTEM" <linux-scsi@vger.kernel.org>,
	"open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:"
	<linux-usb@vger.kernel.org>,
	"open list:EDAC-CORE" <linux-edac@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	"moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
	MANAGEM..." <alsa-devel@alsa-project.org>
Subject: Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
Date: Sat, 26 Sep 2015 12:52:08 -0700	[thread overview]
Message-ID: <1443297128.2181.11.camel@HansenPartnership.com> (raw)
In-Reply-To: <2524822.pQu4UKMrlb@vostro.rjw.lan>

On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > You're going to change that into bool in the next patch, right?
> > 
> > Yeah.
> > 
> > > So what if bool is a byte and the field is not word-aligned
> > 
> > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > So, it will be aligned, isn't it?
> > 
> > > and changing
> > > that byte requires a read-modify-write.  How do we ensure that things remain
> > > consistent in that case?
> > 
> > I didn't understood why a read-modify-write is special here? That's
> > what will happen
> > to most of the non-word-sized fields anyway?
> > 
> > Probably I didn't understood what you meant..
> 
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
> 
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> 
> What's the result?

I think every CPU's  cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2.  If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was usually fixed by
padding (assuming the structure is not packed).  However, it was such a
problem that even the later alpha chips had byte extensions.

James


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
To: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>
Cc: "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
	MANAGEM..." <alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org>,
	Linaro Kernel Mailman List
	<linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
	"open list:TARGET SUBSYSTEM"
	<linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Viresh Kumar
	<viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"open list:ULTRA-WIDEBAND \(UWB\) SUBSYSTEM:"
	<linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:NETWORKING DRIVERS \(WIRELESS\)"
	<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	QCA ath9k Development
	<ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Intel Linux Wireless
	<ilw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Linux ACPI <linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:AMD IOMMU \(AMD-VI\)"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	"open list:BLUETOOTH DRIVERS"
	<linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux Memory Management List
	<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	Greg Kroah-Hartman <gregkh@li
Subject: Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
Date: Sat, 26 Sep 2015 12:52:08 -0700	[thread overview]
Message-ID: <1443297128.2181.11.camel@HansenPartnership.com> (raw)
In-Reply-To: <2524822.pQu4UKMrlb-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>

On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
> > > You're going to change that into bool in the next patch, right?
> > 
> > Yeah.
> > 
> > > So what if bool is a byte and the field is not word-aligned
> > 
> > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > So, it will be aligned, isn't it?
> > 
> > > and changing
> > > that byte requires a read-modify-write.  How do we ensure that things remain
> > > consistent in that case?
> > 
> > I didn't understood why a read-modify-write is special here? That's
> > what will happen
> > to most of the non-word-sized fields anyway?
> > 
> > Probably I didn't understood what you meant..
> 
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
> 
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> 
> What's the result?

I think every CPU's  cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2.  If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was usually fixed by
padding (assuming the structure is not packed).  However, it was such a
problem that even the later alpha chips had byte extensions.

James

  parent reply	other threads:[~2015-09-26 19:52 UTC|newest]

Thread overview: 121+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-25 16:41 [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Viresh Kumar
2015-09-25 16:41 ` Viresh Kumar
2015-09-25 16:41 ` Viresh Kumar
2015-09-25 16:41 ` Viresh Kumar
2015-09-25 16:41 ` [PATCH V4 2/2] debugfs: Pass bool pointer to debugfs_create_bool() Viresh Kumar
2015-09-25 16:41   ` Viresh Kumar
2015-09-25 16:41   ` Viresh Kumar
     [not found] ` <e28c4b4deaf766910c366ab87b64325da59c8ad6.1443198783.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-09-25 17:42   ` [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Johannes Berg
2015-09-25 17:42     ` Johannes Berg
2015-09-25 17:42     ` Johannes Berg
2015-09-25 17:42     ` Johannes Berg
     [not found]     ` <1443202945.2161.8.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2015-09-25 18:47       ` Viresh Kumar
2015-09-25 18:47         ` Viresh Kumar
2015-09-25 18:47         ` Viresh Kumar
2015-09-25 18:47         ` Viresh Kumar
2015-09-25 18:49         ` Johannes Berg
2015-09-25 18:49           ` Johannes Berg
2015-09-25 18:49           ` Johannes Berg
     [not found]           ` <1443206945.2161.9.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2015-09-25 18:52             ` Viresh Kumar
2015-09-25 18:52               ` Viresh Kumar
2015-09-25 18:52               ` Viresh Kumar
2015-09-25 18:52               ` Viresh Kumar
2015-09-25 20:26               ` Rafael J. Wysocki
2015-09-25 20:26                 ` Rafael J. Wysocki
2015-09-25 20:26                 ` Rafael J. Wysocki
     [not found]                 ` <4331507.W3ZDWldbWu-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2015-09-25 20:33                   ` Rafael J. Wysocki
2015-09-25 20:33                     ` Rafael J. Wysocki
2015-09-25 20:33                     ` Rafael J. Wysocki
2015-09-25 20:33                     ` Rafael J. Wysocki
2015-09-25 20:25                     ` Viresh Kumar
2015-09-25 20:25                       ` Viresh Kumar
2015-09-25 20:25                       ` Viresh Kumar
2015-09-25 20:25                       ` Viresh Kumar
2015-09-25 20:25                       ` Viresh Kumar
     [not found]                       ` <CAKohpok2Z2m7GZt1GzZzofeHEioF=XJEq8YVgtY=VtS9tmpb_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-25 20:58                         ` Rafael J. Wysocki
2015-09-25 20:58                           ` Rafael J. Wysocki
2015-09-25 20:58                           ` Rafael J. Wysocki
2015-09-25 20:58                           ` Rafael J. Wysocki
2015-09-25 20:58                           ` Rafael J. Wysocki
2015-09-25 21:44                           ` Viresh Kumar
2015-09-25 21:44                             ` Viresh Kumar
2015-09-25 21:44                             ` Viresh Kumar
2015-09-25 21:44                             ` Viresh Kumar
2015-09-25 21:44                             ` Viresh Kumar
2015-09-25 22:19                             ` Rafael J. Wysocki
2015-09-25 22:19                               ` Rafael J. Wysocki
2015-09-25 22:19                               ` Rafael J. Wysocki
2015-09-25 22:19                               ` Rafael J. Wysocki
     [not found]                               ` <CAJZ5v0i+xJ4U13vCVsvXc7S8wP0AokbmNXPidBkDwbjXMM8fCw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-26 18:40                                 ` Viresh Kumar
2015-09-26 18:40                                   ` Viresh Kumar
2015-09-26 18:40                                   ` Viresh Kumar
2015-09-26 18:40                                   ` Viresh Kumar
2015-09-26 18:40                                   ` Viresh Kumar
2015-09-26 19:33                                   ` Arnd Bergmann
2015-09-26 19:33                                     ` Arnd Bergmann
2015-09-26 19:33                                     ` Arnd Bergmann
2015-09-26 19:33                                     ` Arnd Bergmann
2015-09-27 14:10                                     ` Rafael J. Wysocki
2015-09-27 14:10                                       ` Rafael J. Wysocki
2015-09-27 14:10                                       ` Rafael J. Wysocki
2015-09-27 14:10                                       ` Rafael J. Wysocki
2015-09-27 14:10                                       ` Rafael J. Wysocki
2015-09-28  8:24                                       ` Arnd Bergmann
2015-09-28  8:24                                         ` Arnd Bergmann
2015-09-28  8:24                                         ` Arnd Bergmann
2015-09-28  8:24                                         ` Arnd Bergmann
2015-09-28  8:24                                         ` Arnd Bergmann
2015-09-28 13:07                                         ` Rafael J. Wysocki
2015-09-28 13:07                                           ` Rafael J. Wysocki
2015-09-28 13:07                                           ` Rafael J. Wysocki
2015-09-28 13:07                                           ` Rafael J. Wysocki
2015-09-28 13:07                                           ` Rafael J. Wysocki
     [not found]                           ` <2524822.pQu4UKMrlb-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2015-09-26 19:52                             ` James Bottomley [this message]
2015-09-26 19:52                               ` James Bottomley
2015-09-26 19:52                               ` James Bottomley
2015-09-26 19:52                               ` James Bottomley
2015-09-26 19:52                               ` James Bottomley
2015-09-27 14:09                               ` Rafael J. Wysocki
2015-09-27 14:09                                 ` Rafael J. Wysocki
2015-09-27 14:09                                 ` Rafael J. Wysocki
2015-09-27 14:09                                 ` Rafael J. Wysocki
     [not found]                                 ` <3461169.v5xKdGLGjP-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2015-09-28  8:58                                   ` David Laight
2015-09-28  8:58                                     ` David Laight
2015-09-28  8:58                                     ` David Laight
2015-09-28  8:58                                     ` David Laight
2015-09-28  8:58                                     ` David Laight
2015-09-28  8:58                                     ` David Laight
     [not found]                                     ` <063D6719AE5E284EB5DD2968C1650D6D1CBA3BF7-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
2015-09-28 14:26                                       ` James Bottomley
2015-09-28 14:26                                         ` James Bottomley
2015-09-28 14:26                                         ` James Bottomley
2015-09-28 14:26                                         ` James Bottomley
2015-09-28 14:26                                         ` James Bottomley
2015-09-28 14:50                                         ` David Laight
2015-09-28 14:50                                           ` David Laight
2015-09-28 14:50                                           ` David Laight
2015-09-28 14:50                                           ` David Laight
2015-09-28 14:50                                           ` David Laight
2015-09-28 14:50                                           ` David Laight
2015-09-28 15:11                                           ` James Bottomley
2015-09-28 15:11                                             ` James Bottomley
2015-09-28 15:11                                             ` James Bottomley
2015-09-28 15:11                                             ` James Bottomley
2015-09-28 15:11                                             ` James Bottomley
2015-09-28 15:31                                             ` David Laight
2015-09-28 15:31                                               ` David Laight
2015-09-28 15:31                                               ` David Laight
2015-09-28 15:31                                               ` David Laight
2015-09-28 15:31                                               ` David Laight
2015-09-28 15:31                                               ` David Laight
2015-09-25 20:18 ` Rafael J. Wysocki
2015-09-25 20:18   ` Rafael J. Wysocki
2015-09-25 20:18   ` Rafael J. Wysocki
2015-09-25 20:22   ` Rafael J. Wysocki
2015-09-25 20:22     ` Rafael J. Wysocki
2015-09-25 20:22     ` Rafael J. Wysocki
2015-09-27  5:31 ` Jiri Slaby
     [not found]   ` <CAJPN1uvPyZ+hZ64_0ZXU9wPLuAR-qm06GrRmHTjc9+rgiChYDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-27 14:35     ` Viresh Kumar
2015-09-27 14:35       ` Viresh Kumar
2015-09-27 14:35       ` Viresh Kumar
2015-09-27 14:35       ` Viresh Kumar
2015-09-27 14:35       ` Viresh Kumar

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=1443297128.2181.11.camel@HansenPartnership.com \
    --to=james.bottomley-d9phhud1jfjcxq6kfmz53/egyhegw8jk@public.gmane.org \
    --cc=alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org \
    --cc=ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org \
    --cc=gregkh@li \
    --cc=ilw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
    --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
    --cc=viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    /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.