Re: [PATCH 4.14 117/126] net: sk_buff rbnode reorg

2018-11-29 Thread Mitch Harder
On Thu, Nov 29, 2018 at 4:33 AM Greg Kroah-Hartman wrote: > > On Thu, Oct 04, 2018 at 03:13:56PM -0500, Mitch Harder wrote: > > On Mon, Sep 17, 2018 at 5:42 PM, Greg Kroah-Hartman > > wrote: > > > 4.14-stable review patch. If anyone has any objections

Re: [PATCH 4.14 117/126] net: sk_buff rbnode reorg

2018-11-29 Thread Mitch Harder
On Thu, Nov 29, 2018 at 4:33 AM Greg Kroah-Hartman wrote: > > On Thu, Oct 04, 2018 at 03:13:56PM -0500, Mitch Harder wrote: > > On Mon, Sep 17, 2018 at 5:42 PM, Greg Kroah-Hartman > > wrote: > > > 4.14-stable review patch. If anyone has any objections

Re: [PATCH 4.14 117/126] net: sk_buff rbnode reorg

2018-10-04 Thread Mitch Harder
On Mon, Sep 17, 2018 at 5:42 PM, Greg Kroah-Hartman wrote: > 4.14-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Eric Dumazet > > commit bffa72cf7f9df842f0016ba03586039296b4caaf upstream > > skb->rbnode shares space with skb->next,

Re: [PATCH 4.14 117/126] net: sk_buff rbnode reorg

2018-10-04 Thread Mitch Harder
On Mon, Sep 17, 2018 at 5:42 PM, Greg Kroah-Hartman wrote: > 4.14-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Eric Dumazet > > commit bffa72cf7f9df842f0016ba03586039296b4caaf upstream > > skb->rbnode shares space with skb->next,

RE: [Intel-wired-lan] [PATCH 1/2] igb: Teardown SR-IOV before unregister_netdev()

2015-07-27 Thread Williams, Mitch A
ACK > -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Alex Williamson > Sent: Monday, July 27, 2015 4:19 PM > To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org >

RE: [Intel-wired-lan] [PATCH 2/2] ixgbe: Teardown SR-IOV before unregister_netdev()

2015-07-27 Thread Williams, Mitch A
ACK > -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Alex Williamson > Sent: Monday, July 27, 2015 4:19 PM > To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org >

RE: [Intel-wired-lan] [PATCH 2/2] ixgbe: Teardown SR-IOV before unregister_netdev()

2015-07-27 Thread Williams, Mitch A
ACK -Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Alex Williamson Sent: Monday, July 27, 2015 4:19 PM To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org Subject:

RE: [Intel-wired-lan] [PATCH 1/2] igb: Teardown SR-IOV before unregister_netdev()

2015-07-27 Thread Williams, Mitch A
ACK -Original Message- From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Alex Williamson Sent: Monday, July 27, 2015 4:19 PM To: intel-wired-...@lists.osuosl.org; Kirsher, Jeffrey T Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org Subject:

Re: BUG: scheduling while atomic 3.10.7 in ZRAM Swap

2013-09-11 Thread Mitch Harder
On Tue, Aug 20, 2013 at 9:51 AM, Mitch Harder wrote: > On Sun, Aug 18, 2013 at 11:44 PM, Minchan Kim wrote: >> Hello, >> >> On Mon, Aug 19, 2013 at 12:13:02PM +0800, Michael wang wrote: >>> Hi, Mitch >>> >>> On 08/17/2013 10:01 PM, Mitch Harder

Re: BUG: scheduling while atomic 3.10.7 in ZRAM Swap

2013-09-11 Thread Mitch Harder
On Tue, Aug 20, 2013 at 9:51 AM, Mitch Harder mitch.har...@sabayonlinux.org wrote: On Sun, Aug 18, 2013 at 11:44 PM, Minchan Kim minc...@kernel.org wrote: Hello, On Mon, Aug 19, 2013 at 12:13:02PM +0800, Michael wang wrote: Hi, Mitch On 08/17/2013 10:01 PM, Mitch Harder wrote: I'm

Re: BUG: scheduling while atomic 3.10.7 in ZRAM Swap

2013-08-20 Thread Mitch Harder
On Sun, Aug 18, 2013 at 11:44 PM, Minchan Kim wrote: > Hello, > > On Mon, Aug 19, 2013 at 12:13:02PM +0800, Michael wang wrote: >> Hi, Mitch >> >> On 08/17/2013 10:01 PM, Mitch Harder wrote: >> > I'm encountering a BUG while using a ZRAM Swap device. >&

Re: BUG: scheduling while atomic 3.10.7 in ZRAM Swap

2013-08-20 Thread Mitch Harder
On Sun, Aug 18, 2013 at 11:44 PM, Minchan Kim minc...@kernel.org wrote: Hello, On Mon, Aug 19, 2013 at 12:13:02PM +0800, Michael wang wrote: Hi, Mitch On 08/17/2013 10:01 PM, Mitch Harder wrote: I'm encountering a BUG while using a ZRAM Swap device. The call trace seems to involve

BUG: scheduling while atomic 3.10.7 in ZRAM Swap

2013-08-17 Thread Mitch Harder
I'm encountering a BUG while using a ZRAM Swap device. The call trace seems to involve the changes recently added to 3.10.6 by the patch: zram: use zram->lock to protect zram_free_page() in swap free notify path The hardware is a x86 single CPU AMD Athlon XP system with 1GB RAM. I'm

BUG: scheduling while atomic 3.10.7 in ZRAM Swap

2013-08-17 Thread Mitch Harder
I'm encountering a BUG while using a ZRAM Swap device. The call trace seems to involve the changes recently added to 3.10.6 by the patch: zram: use zram-lock to protect zram_free_page() in swap free notify path The hardware is a x86 single CPU AMD Athlon XP system with 1GB RAM. I'm implementing

Re: [Techteam] [RFC PATCH] x86-32: Start out eflags and cr4 clean

2013-01-18 Thread Mitch Bradley
On 1/18/2013 4:35 PM, H. Peter Anvin wrote: > On 01/18/2013 05:05 PM, Mitch Bradley wrote: >> >> >> On 1/18/2013 2:42 PM, H. Peter Anvin wrote: >>> On 01/18/2013 04:40 PM, Andres Salomon wrote: >>>> Bad news on this patch; I've been told that it brea

Re: [Techteam] [RFC PATCH] x86-32: Start out eflags and cr4 clean

2013-01-18 Thread Mitch Bradley
On 1/18/2013 2:42 PM, H. Peter Anvin wrote: > On 01/18/2013 04:40 PM, Andres Salomon wrote: >> Bad news on this patch; I've been told that it breaks booting on an >> XO-1.5. Does anyone from OLPC know why yet? > > What are the settings of CR0 and CR4 on kernel entry on XO-1.5? CR0 is

Re: [Techteam] [RFC PATCH] x86-32: Start out eflags and cr4 clean

2013-01-18 Thread Mitch Bradley
On 1/18/2013 2:42 PM, H. Peter Anvin wrote: On 01/18/2013 04:40 PM, Andres Salomon wrote: Bad news on this patch; I've been told that it breaks booting on an XO-1.5. Does anyone from OLPC know why yet? What are the settings of CR0 and CR4 on kernel entry on XO-1.5? CR0 is 0x8011 CR4

Re: [Techteam] [RFC PATCH] x86-32: Start out eflags and cr4 clean

2013-01-18 Thread Mitch Bradley
On 1/18/2013 4:35 PM, H. Peter Anvin wrote: On 01/18/2013 05:05 PM, Mitch Bradley wrote: On 1/18/2013 2:42 PM, H. Peter Anvin wrote: On 01/18/2013 04:40 PM, Andres Salomon wrote: Bad news on this patch; I've been told that it breaks booting on an XO-1.5. Does anyone from OLPC know why

Re: zram: fix invalid memory references during disk write

2012-12-19 Thread Mitch Harder
On Wed, Dec 19, 2012 at 11:21 AM, Nitin Gupta wrote: > On 12/19/2012 08:17 AM, Greg KH wrote: >> On Wed, Dec 19, 2012 at 07:53:36AM -0800, Nitin Gupta wrote: >>> On 12/19/2012 07:08 AM, Greg KH wrote: On Tue, Dec 18, 2012 at 11:21:28PM -0800, Nitin Gupta wrote: > On 12/18/2012 07:49 PM,

Re: zram: fix invalid memory references during disk write

2012-12-19 Thread Mitch Harder
On Wed, Dec 19, 2012 at 11:21 AM, Nitin Gupta ngu...@vflare.org wrote: On 12/19/2012 08:17 AM, Greg KH wrote: On Wed, Dec 19, 2012 at 07:53:36AM -0800, Nitin Gupta wrote: On 12/19/2012 07:08 AM, Greg KH wrote: On Tue, Dec 18, 2012 at 11:21:28PM -0800, Nitin Gupta wrote: On 12/18/2012 07:49

Re: [PATCH] serial: tegra: add serial driver

2012-12-17 Thread Mitch Bradley
On 12/17/2012 12:04 PM, Stephen Warren wrote: > On 12/17/2012 02:58 PM, Mitch Bradley wrote: >> On 12/17/2012 11:36 AM, Stephen Warren wrote: >>> On 12/17/2012 05:10 AM, Laxman Dewangan wrote: >>>> Nvidia's Tegra has multiple uart controller which supports: >&g

Re: [PATCH] serial: tegra: add serial driver

2012-12-17 Thread Mitch Bradley
On 12/17/2012 11:36 AM, Stephen Warren wrote: > On 12/17/2012 05:10 AM, Laxman Dewangan wrote: >> Nvidia's Tegra has multiple uart controller which supports: >> - APB dma based controller fifo read/write. >> - End Of Data interrupt in incoming data to know whether end >> of frame achieve or not.

Re: [PATCH] serial: tegra: add serial driver

2012-12-17 Thread Mitch Bradley
On 12/17/2012 11:36 AM, Stephen Warren wrote: On 12/17/2012 05:10 AM, Laxman Dewangan wrote: Nvidia's Tegra has multiple uart controller which supports: - APB dma based controller fifo read/write. - End Of Data interrupt in incoming data to know whether end of frame achieve or not. - Hw

Re: [PATCH] serial: tegra: add serial driver

2012-12-17 Thread Mitch Bradley
On 12/17/2012 12:04 PM, Stephen Warren wrote: On 12/17/2012 02:58 PM, Mitch Bradley wrote: On 12/17/2012 11:36 AM, Stephen Warren wrote: On 12/17/2012 05:10 AM, Laxman Dewangan wrote: Nvidia's Tegra has multiple uart controller which supports: - APB dma based controller fifo read/write

Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

2012-11-13 Thread Mitch Bradley
On 11/13/2012 8:29 AM, Stephen Warren wrote: > On 11/13/2012 11:10 AM, Mitch Bradley wrote: >> It seems to me that this capebus discussion is missing an important >> point. The name capebus suggests that it is a bus, so there should be a >> parent node to represent that

Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

2012-11-13 Thread Mitch Bradley
s. If something about the design of capebus makes that impossible, I respectfully suggest that its design should be reviewed, taking into account the many years of industry experience about modularity. Mitch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body o

Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

2012-11-13 Thread Mitch Bradley
respectfully suggest that its design should be reviewed, taking into account the many years of industry experience about modularity. Mitch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http

Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

2012-11-13 Thread Mitch Bradley
On 11/13/2012 8:29 AM, Stephen Warren wrote: On 11/13/2012 11:10 AM, Mitch Bradley wrote: It seems to me that this capebus discussion is missing an important point. The name capebus suggests that it is a bus, so there should be a parent node to represent that bus. It should have a driver

Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

2012-11-08 Thread Mitch Bradley
On 11/8/2012 3:28 AM, Koen Kooi wrote: > > Op 7 nov. 2012, om 23:35 heeft Ryan Mallon het volgende > geschreven: > >> On 06/11/12 08:40, Tabi Timur-B04825 wrote: >>> On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely >>> wrote: >>> Jane is building custom BeagleBone expansion boards called

Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

2012-11-08 Thread Mitch Bradley
On 11/8/2012 3:28 AM, Koen Kooi wrote: Op 7 nov. 2012, om 23:35 heeft Ryan Mallon rmal...@gmail.com het volgende geschreven: On 06/11/12 08:40, Tabi Timur-B04825 wrote: On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Jane is building custom BeagleBone

Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

2012-11-06 Thread Mitch Bradley
On 11/6/2012 12:37 PM, Stephen Warren wrote: > On 11/05/2012 01:40 PM, Grant Likely wrote: >> Hey folks, >> >> As promised, here is my early draft to try and capture what device >> tree overlays need to do and how to get there. Comments and >> suggestions greatly appreciated. > > Interesting.

Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

2012-11-06 Thread Mitch Bradley
On 11/6/2012 12:37 PM, Stephen Warren wrote: On 11/05/2012 01:40 PM, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Interesting. This just came

Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts

2012-10-23 Thread Mitch Bradley
On 10/23/2012 1:15 PM, Jon Hunter wrote: > Hi Mitch, > > On 10/23/2012 11:55 AM, Mitch Bradley wrote: >> On 10/23/2012 4:49 AM, Jon Hunter wrote: >> >>> Therefore, I believe it will improve search time and hence, boot time if >>> we have interrupt-parent

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

2012-10-23 Thread Mitch Bradley
it". Now I see that you meant that the driver should explicitly call abstracted functions. On 10/23/2012 7:20 AM, Felipe Balbi wrote: > HI, > > On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote: >> On 10/23/2012 12:03 AM, Felipe Balbi wrote: >>> Hi, >>&g

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

2012-10-23 Thread Mitch Bradley
On 10/23/2012 12:03 AM, Felipe Balbi wrote: > Hi, > > I much prefer having drivers explicitly manage all their resources, > which would mean that pinctrl calls need to be done on probe() and, if > necessary, during suspend()/resume(). Per-driver resource management is certainly convenient when

Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts

2012-10-23 Thread Mitch Bradley
On 10/23/2012 4:49 AM, Jon Hunter wrote: > Therefore, I believe it will improve search time and hence, boot time if > we have interrupt-parent defined in each node. I strongly suspect (based on many years of performance tuning, with special focus on boot time) that the time difference will be

Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts

2012-10-23 Thread Mitch Bradley
On 10/23/2012 4:49 AM, Jon Hunter wrote: Therefore, I believe it will improve search time and hence, boot time if we have interrupt-parent defined in each node. I strongly suspect (based on many years of performance tuning, with special focus on boot time) that the time difference will be

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

2012-10-23 Thread Mitch Bradley
On 10/23/2012 12:03 AM, Felipe Balbi wrote: Hi, I much prefer having drivers explicitly manage all their resources, which would mean that pinctrl calls need to be done on probe() and, if necessary, during suspend()/resume(). Per-driver resource management is certainly convenient when you

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

2012-10-23 Thread Mitch Bradley
meant that the driver should explicitly call abstracted functions. On 10/23/2012 7:20 AM, Felipe Balbi wrote: HI, On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote: On 10/23/2012 12:03 AM, Felipe Balbi wrote: Hi, I much prefer having drivers explicitly manage all

Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts

2012-10-23 Thread Mitch Bradley
On 10/23/2012 1:15 PM, Jon Hunter wrote: Hi Mitch, On 10/23/2012 11:55 AM, Mitch Bradley wrote: On 10/23/2012 4:49 AM, Jon Hunter wrote: Therefore, I believe it will improve search time and hence, boot time if we have interrupt-parent defined in each node. I strongly suspect (based

Re: dtc: import latest upstream dtc

2012-10-10 Thread Mitch Bradley
On 10/10/2012 1:16 PM, David Gibson wrote: > On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote: >> On 10/10/2012 10:16 AM, Stephen Warren wrote: >>> On 10/10/2012 01:24 AM, David Gibson wrote: On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote: > On Oct 9, 2012, at 6:04

Re: dtc: import latest upstream dtc

2012-10-10 Thread Mitch Bradley
On 10/10/2012 8:45 AM, Stephen Warren wrote: > On 10/10/2012 12:23 PM, Mitch Bradley wrote: >> On 10/10/2012 7:09 AM, Rob Herring wrote: >>> On 10/09/2012 04:16 PM, Stephen Warren wrote: >>>> On 10/01/2012 12:39 PM, Jon Loeliger wrote: >>>>>> >&g

Re: dtc: import latest upstream dtc

2012-10-10 Thread Mitch Bradley
On 10/10/2012 8:40 AM, Stephen Warren wrote: > On 10/10/2012 11:09 AM, Rob Herring wrote: >> On 10/09/2012 04:16 PM, Stephen Warren wrote: >>> On 10/01/2012 12:39 PM, Jon Loeliger wrote: > > What more do you think needs discussion re: dtc+cpp? How not to abuse the ever-loving

Re: dtc: import latest upstream dtc

2012-10-10 Thread Mitch Bradley
On 10/10/2012 7:09 AM, Rob Herring wrote: > On 10/09/2012 04:16 PM, Stephen Warren wrote: >> On 10/01/2012 12:39 PM, Jon Loeliger wrote: What more do you think needs discussion re: dtc+cpp? >>> >>> How not to abuse the ever-loving shit out of it? :-) >> >> Perhaps we can just handle this

Re: dtc: import latest upstream dtc

2012-10-10 Thread Mitch Bradley
On 10/10/2012 7:09 AM, Rob Herring wrote: On 10/09/2012 04:16 PM, Stephen Warren wrote: On 10/01/2012 12:39 PM, Jon Loeliger wrote: What more do you think needs discussion re: dtc+cpp? How not to abuse the ever-loving shit out of it? :-) Perhaps we can just handle this through the regular

Re: dtc: import latest upstream dtc

2012-10-10 Thread Mitch Bradley
On 10/10/2012 8:40 AM, Stephen Warren wrote: On 10/10/2012 11:09 AM, Rob Herring wrote: On 10/09/2012 04:16 PM, Stephen Warren wrote: On 10/01/2012 12:39 PM, Jon Loeliger wrote: What more do you think needs discussion re: dtc+cpp? How not to abuse the ever-loving shit out of it? :-)

Re: dtc: import latest upstream dtc

2012-10-10 Thread Mitch Bradley
On 10/10/2012 8:45 AM, Stephen Warren wrote: On 10/10/2012 12:23 PM, Mitch Bradley wrote: On 10/10/2012 7:09 AM, Rob Herring wrote: On 10/09/2012 04:16 PM, Stephen Warren wrote: On 10/01/2012 12:39 PM, Jon Loeliger wrote: What more do you think needs discussion re: dtc+cpp? How

Re: dtc: import latest upstream dtc

2012-10-10 Thread Mitch Bradley
On 10/10/2012 1:16 PM, David Gibson wrote: On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote: On 10/10/2012 10:16 AM, Stephen Warren wrote: On 10/10/2012 01:24 AM, David Gibson wrote: On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote: On Oct 9, 2012, at 6:04 PM, Scott Wood

Re: dtc: import latest upstream dtc

2012-10-09 Thread Mitch Bradley
On 10/9/2012 11:16 AM, Stephen Warren wrote: > On 10/01/2012 12:39 PM, Jon Loeliger wrote: >>> >>> What more do you think needs discussion re: dtc+cpp? >> >> How not to abuse the ever-loving shit out of it? :-) > > Perhaps we can just handle this through the regular patch review > process; I

Re: dtc: import latest upstream dtc

2012-10-09 Thread Mitch Bradley
On 10/9/2012 11:16 AM, Stephen Warren wrote: On 10/01/2012 12:39 PM, Jon Loeliger wrote: What more do you think needs discussion re: dtc+cpp? How not to abuse the ever-loving shit out of it? :-) Perhaps we can just handle this through the regular patch review process; I think it may be

Re: [GIT PULL] Update LZO compression

2012-08-16 Thread Mitch Harder
On Thu, Aug 16, 2012 at 5:17 PM, Andi Kleen wrote: > On Thu, Aug 16, 2012 at 11:55:06AM -0700, james northrup wrote: >> looks like ARM results are inconclusive from a lot of folks without >> bandwidth to do a write-up, what about just plain STAGING status for ARM so >> the android tweakers can

Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences

2012-08-16 Thread Mitch Bradley
On 8/16/2012 8:38 AM, Stephen Warren wrote: > On 08/16/2012 12:08 AM, Alexandre Courbot wrote: >> Some device drivers (panel backlights especially) need to follow precise >> sequences for powering on and off, involving gpios, regulators, PWMs >> with a precise powering order and delays to respect

Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences

2012-08-16 Thread Mitch Bradley
On 8/16/2012 8:38 AM, Stephen Warren wrote: On 08/16/2012 12:08 AM, Alexandre Courbot wrote: Some device drivers (panel backlights especially) need to follow precise sequences for powering on and off, involving gpios, regulators, PWMs with a precise powering order and delays to respect between

Re: [GIT PULL] Update LZO compression

2012-08-16 Thread Mitch Harder
On Thu, Aug 16, 2012 at 5:17 PM, Andi Kleen a...@firstfloor.org wrote: On Thu, Aug 16, 2012 at 11:55:06AM -0700, james northrup wrote: looks like ARM results are inconclusive from a lot of folks without bandwidth to do a write-up, what about just plain STAGING status for ARM so the android

Re: DT GPIO numbering?

2012-08-06 Thread Mitch Bradley
On 8/6/2012 5:58 PM, Johannes Stezenbach wrote: > On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote: >> On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren wrote: >> >>> I can't comment on the sysfs-vs-dev interface location, but I don't >>> think it addresses Johannes' issue; finding out

Re: DT GPIO numbering?

2012-08-06 Thread Mitch Bradley
On 8/6/2012 5:58 PM, Johannes Stezenbach wrote: On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote: On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren swar...@wwwdotorg.org wrote: I can't comment on the sysfs-vs-dev interface location, but I don't think it addresses Johannes' issue;

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences

2012-07-31 Thread Mitch Bradley
On 8/1/2012 9:47 AM, Alex Courbot wrote: > On 07/31/2012 09:55 PM, Mitch Bradley wrote: >> On 7/31/2012 8:38 PM, Thierry Reding wrote: >>> On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote: >>>> On 7/31/2012 6:56 PM, Thierry Reding wrote: >>>>

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences

2012-07-31 Thread Mitch Bradley
On 7/31/2012 8:38 PM, Thierry Reding wrote: > On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote: >> On 7/31/2012 6:56 PM, Thierry Reding wrote: >>> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote: >>>> On 07/31/2012 07:45 AM, Stephen Warren

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences

2012-07-31 Thread Mitch Bradley
On 7/31/2012 6:56 PM, Thierry Reding wrote: > On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote: >> On 07/31/2012 07:45 AM, Stephen Warren wrote: >>> I wonder if using the same structure/array as input and output would >>> simplify the API; the platform data would fill in the fields

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences

2012-07-31 Thread Mitch Bradley
On 7/31/2012 6:56 PM, Thierry Reding wrote: On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote: On 07/31/2012 07:45 AM, Stephen Warren wrote: I wonder if using the same structure/array as input and output would simplify the API; the platform data would fill in the fields mentioned

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences

2012-07-31 Thread Mitch Bradley
On 7/31/2012 8:38 PM, Thierry Reding wrote: On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote: On 7/31/2012 6:56 PM, Thierry Reding wrote: On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote: On 07/31/2012 07:45 AM, Stephen Warren wrote: I wonder if using the same

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences

2012-07-31 Thread Mitch Bradley
On 8/1/2012 9:47 AM, Alex Courbot wrote: On 07/31/2012 09:55 PM, Mitch Bradley wrote: On 7/31/2012 8:38 PM, Thierry Reding wrote: On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote: On 7/31/2012 6:56 PM, Thierry Reding wrote: On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot

Re: [PATCH v2] Btrfs: allow mount -o remount,compress=no

2012-07-19 Thread Mitch Harder
On Wed, Jul 18, 2012 at 8:28 PM, David Sterba wrote: > On Fri, Jul 13, 2012 at 10:19:14AM -0500, Mitch Harder wrote: >> I was testing the lz4(hc) patches, and I found the the compression >> INCOMPAT flags are not being updated using the method in this patch. >> >> The

Re: [PATCH v2] Btrfs: allow mount -o remount,compress=no

2012-07-19 Thread Mitch Harder
On Wed, Jul 18, 2012 at 8:28 PM, David Sterba d...@jikos.cz wrote: On Fri, Jul 13, 2012 at 10:19:14AM -0500, Mitch Harder wrote: I was testing the lz4(hc) patches, and I found the the compression INCOMPAT flags are not being updated using the method in this patch. The compression INCOMPAT

Re: [PATCH v2] Btrfs: allow mount -o remount,compress=no

2012-07-13 Thread Mitch Harder
On Thu, Jun 28, 2012 at 10:40 AM, David Sterba wrote: > On Tue, Jun 26, 2012 at 08:48:37AM +0200, Arnd Hannemann wrote: >> How show should we proceed to get above mentioned patch >> (or the similar patch from Andrei Popa) merged? > > Josef picked the patch into btrfs-next, I see not problem to

Re: [PATCH v2] Btrfs: allow mount -o remount,compress=no

2012-07-13 Thread Mitch Harder
On Thu, Jun 28, 2012 at 10:40 AM, David Sterba d...@jikos.cz wrote: On Tue, Jun 26, 2012 at 08:48:37AM +0200, Arnd Hannemann wrote: How show should we proceed to get above mentioned patch (or the similar patch from Andrei Popa) merged? Josef picked the patch into btrfs-next, I see not problem

Re: ext3 SMP bug ? PANIC in __d_find_alias

2007-12-12 Thread Mitch
to trigger it ever so often if there is other activity also going on. M Original Message Subject: Re: ext3 SMP bug ? PANIC in __d_find_alias Date: Wed, 12 Dec 2007 20:36:40 +0100 From: Rafael J. Wysocki <[EMAIL PROTECTED]> To: Mitch <[EMAIL PROTECTED]> CC: linux-

ext3 SMP bug ? PANIC in __d_find_alias

2007-12-12 Thread Mitch
? The fact that this is tainted (due to nvidia) is a red herring i think because both my machines (the SMP and UP one) are using the same nvidia module and the panic is in ext3 code. Help Mitch Dec 10 03:02:43 home kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address

ext3 SMP bug ? PANIC in __d_find_alias

2007-12-12 Thread Mitch
? The fact that this is tainted (due to nvidia) is a red herring i think because both my machines (the SMP and UP one) are using the same nvidia module and the panic is in ext3 code. Help Mitch Dec 10 03:02:43 home kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address

Re: ext3 SMP bug ? PANIC in __d_find_alias

2007-12-12 Thread Mitch
it ever so often if there is other activity also going on. M Original Message Subject: Re: ext3 SMP bug ? PANIC in __d_find_alias Date: Wed, 12 Dec 2007 20:36:40 +0100 From: Rafael J. Wysocki [EMAIL PROTECTED] To: Mitch [EMAIL PROTECTED] CC: linux-kernel@vger.kernel.org, [EMAIL

More ext3 panics on 2.6.22 [Fwd: ext3_ordered_writepage panic on shiny new 2.6.22]

2007-10-02 Thread Mitch
Subject: ext3_ordered_writepage panic on shiny new 2.6.22 Date: Sat, 14 Jul 2007 18:18:14 +0400 From: Mitch <[EMAIL PROTECTED]> To: linux-kernel@vger.kernel.org Hi Light load on my system and encoding a home video to the disk using mencoder and i get this... BUG: unable to handle kernel NULL pointer

More ext3 panics on 2.6.22 [Fwd: ext3_ordered_writepage panic on shiny new 2.6.22]

2007-10-02 Thread Mitch
panic on shiny new 2.6.22 Date: Sat, 14 Jul 2007 18:18:14 +0400 From: Mitch [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Hi Light load on my system and encoding a home video to the disk using mencoder and i get this... BUG: unable to handle kernel NULL pointer dereference at virtual

ext3_ordered_writepage panic on shiny new 2.6.22

2007-07-14 Thread Mitch
Hi Light load on my system and encoding a home video to the disk using mencoder and i get this... BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c01a478e *pde = Oops: [#1] PREEMPT SMP Modules linked in: nls_iso8859_1 nls_cp437

ext3_ordered_writepage panic on shiny new 2.6.22

2007-07-14 Thread Mitch
Hi Light load on my system and encoding a home video to the disk using mencoder and i get this... BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c01a478e *pde = Oops: [#1] PREEMPT SMP Modules linked in: nls_iso8859_1 nls_cp437

Re: [2.6.22-rc3][ACPI?] Resume from s2r doesn't work.

2007-06-02 Thread Mitch Davis
tp://bugzilla.kernel.org/show_bug.cgi?id=7988 And if you haven't already (and your problem occurs with a stock kernel), you might want to log this as a bug like I did. Hope this helps. Mitch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message

Re: [2.6.22-rc3][ACPI?] Resume from s2r doesn't work.

2007-06-02 Thread Mitch Davis
(and your problem occurs with a stock kernel), you might want to log this as a bug like I did. Hope this helps. Mitch. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: [PATCH] msi: Immediately mask and unmask msi-x irqs.

2007-04-03 Thread Williams, Mitch A
Acked-by: Mitch Williams <[EMAIL PROTECTED]> >This is a simplified and actually more comprehensive form of a bug >fix from Mitch Williams <[EMAIL PROTECTED]>. [snip] >Then if people do have a kernel message stating "No irq for vector" we >will know it is

RE: [PATCH] msi: Immediately mask and unmask msi-x irqs.

2007-04-03 Thread Williams, Mitch A
Acked-by: Mitch Williams [EMAIL PROTECTED] This is a simplified and actually more comprehensive form of a bug fix from Mitch Williams [EMAIL PROTECTED]. [snip] Then if people do have a kernel message stating No irq for vector we will know it is yet another novel cause that needs a complete new

RE: [PATCH 2.6.21-rc5] Flush MSI-X table writes (rev 3)

2007-03-30 Thread Williams, Mitch A
related to "no vector for IRQ" in the wild, then I have to change my stance and agree that this should be pushed to -stable. Every one of those messages indicates that we hit the race condition. -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu

RE: [PATCH 2.6.21-rc5] Flush MSI-X table writes (rev 3)

2007-03-30 Thread Williams, Mitch A
Greg KH wrote: > >> Perhaps we should put this into 2.6.22 then backport it to >2.6.21.x once it >> seems safe to do so. If we decide to go this way, we'll >need to ask Mitch >> to remind us to do the backport at the appropriate time, >else we'll surely >>

[PATCH 2.6.20.4] Flush MSI-X table writes (rev 3)

2007-03-30 Thread Mitch Williams
flushes are required in the various affinity setting routines. This patch has been validated with (unreleased) network hardware which uses MSI-X. Revised with input from Eric Biederman. Signed-off-by: Mitch Williams <[EMAIL PROTECTED]> diff -urpN -X dontdiff linux-2.6.20.4-clean/drive

Re: [PATCH 2.6.20.4]

2007-03-30 Thread Mitch Williams
On Fri, 2007-03-30 at 11:56 -0700, Mitch Williams wrote: > This patch fixes a kernel bug which is triggered when using the > irqbalance daemon with MSI-X hardware. > Grrr. Evolution cut-n-sometimes-paste feature bit me. Will resend with a proper subject line. -Mitch - To unsubsc

[PATCH 2.6.21-rc5] Flush MSI-X table writes (rev 3)

2007-03-30 Thread Mitch Williams
flushes are required in the various affinity setting routines. This patch has been validated with (unreleased) network hardware which uses MSI-X. Revised with input from Eric Biederman. Signed-off-by: Mitch Williams <[EMAIL PROTECTED]> diff -urpN -X dontdiff linux-2.6.21-rc5-clean/drive

[PATCH 2.6.20.4]

2007-03-30 Thread Mitch Williams
This patch fixes a kernel bug which is triggered when using the irqbalance daemon with MSI-X hardware. Because both MSI-X interrupt messages and MSI-X table writes are posted, it's possible for them to cross while in-flight. This results in interrupts being received long after the kernel thinks

[PATCH 2.6.21-rc5] Flush MSI-X table writes (rev 3)

2007-03-30 Thread Mitch Williams
flushes are required in the various affinity setting routines. This patch has been validated with (unreleased) network hardware which uses MSI-X. Revised with input from Eric Biederman. Signed-off-by: Mitch Williams [EMAIL PROTECTED] diff -urpN -X dontdiff linux-2.6.21-rc5-clean/drivers/pci

[PATCH 2.6.20.4]

2007-03-30 Thread Mitch Williams
This patch fixes a kernel bug which is triggered when using the irqbalance daemon with MSI-X hardware. Because both MSI-X interrupt messages and MSI-X table writes are posted, it's possible for them to cross while in-flight. This results in interrupts being received long after the kernel thinks

Re: [PATCH 2.6.20.4]

2007-03-30 Thread Mitch Williams
On Fri, 2007-03-30 at 11:56 -0700, Mitch Williams wrote: This patch fixes a kernel bug which is triggered when using the irqbalance daemon with MSI-X hardware. Grrr. Evolution cut-n-sometimes-paste feature bit me. Will resend with a proper subject line. -Mitch - To unsubscribe from this list

[PATCH 2.6.20.4] Flush MSI-X table writes (rev 3)

2007-03-30 Thread Mitch Williams
flushes are required in the various affinity setting routines. This patch has been validated with (unreleased) network hardware which uses MSI-X. Revised with input from Eric Biederman. Signed-off-by: Mitch Williams [EMAIL PROTECTED] diff -urpN -X dontdiff linux-2.6.20.4-clean/drivers/pci/msi.c

RE: [PATCH 2.6.21-rc5] Flush MSI-X table writes (rev 3)

2007-03-30 Thread Williams, Mitch A
Greg KH wrote: Perhaps we should put this into 2.6.22 then backport it to 2.6.21.x once it seems safe to do so. If we decide to go this way, we'll need to ask Mitch to remind us to do the backport at the appropriate time, else we'll surely forget. Yes, that's what I just asked him

RE: [PATCH 2.6.21-rc5] Flush MSI-X table writes (rev 3)

2007-03-30 Thread Williams, Mitch A
be pushed to -stable. Every one of those messages indicates that we hit the race condition. -Mitch - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table (rev 2)

2007-03-29 Thread Williams, Mitch A
t. So the answer to your question is, "probably not". -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table (rev 2)

2007-03-29 Thread Williams, Mitch A
Eric W. Biederman wrote: >Do we still need the flush the set affinity routines? >Shouldn't flush in mask and unmask should now be enough? Yeah, I think you're right. I've removed that call, and we're running some basic validation on the change. I'll post a new patch tomorrow AM.

[PATCH 2.6.21-rc5] MSI: read-flush MSI-X table (rev 2)

2007-03-29 Thread Mitch Williams
from Eric Biederman. Signed-off-by: Mitch Williams <[EMAIL PROTECTED]> diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c linux-2.6.21-rc5/arch/i386/kernel/io_apic.c --- linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c 2007-03-28 10:05:22.0 -0700 +++ linux-

[PATCH 2.6.21-rc5] MSI: read-flush MSI-X table (rev 2)

2007-03-29 Thread Mitch Williams
from Eric Biederman. Signed-off-by: Mitch Williams [EMAIL PROTECTED] diff -urpN -X dontdiff linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c linux-2.6.21-rc5/arch/i386/kernel/io_apic.c --- linux-2.6.21-rc5-clean/arch/i386/kernel/io_apic.c 2007-03-28 10:05:22.0 -0700 +++ linux-2.6.21-rc5

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table (rev 2)

2007-03-29 Thread Williams, Mitch A
Eric W. Biederman wrote: Do we still need the flush the set affinity routines? Shouldn't flush in mask and unmask should now be enough? Yeah, I think you're right. I've removed that call, and we're running some basic validation on the change. I'll post a new patch tomorrow AM. -Mitch

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table (rev 2)

2007-03-29 Thread Williams, Mitch A
the answer to your question is, probably not. -Mitch - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table

2007-03-28 Thread Williams, Mitch A
gt;MSI is disabled before we unregister it, we don't know of any >MSI implementation problems that will result in a screaming IRQ. >I would say set enable/disable to the mask/unmask methods. > OK, that's easy. I'll whip up a patch today, test it overnight, and post it tomorrow. Thanks f

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table

2007-03-28 Thread Williams, Mitch A
we unregister it, we don't know of any MSI implementation problems that will result in a screaming IRQ. I would say set enable/disable to the mask/unmask methods. OK, that's easy. I'll whip up a patch today, test it overnight, and post it tomorrow. Thanks for looking at this. -Mitch

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table

2007-03-27 Thread Williams, Mitch A
Eric W. Biederman wrote: >> However the mask function is called at EVERY interrupt, >> so this change would be VERY expensive. > >If true I think that would be bad. However I don't see it. >Where in handle_edge_irq do we mask the interrupt? >The only place I see us calling ->mask is from

RE: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table

2007-03-27 Thread Williams, Mitch A
be VERY expensive. If the driver really needs to disable the interrupt, then it can call irq_disable(). Otherwise, mask (as-is) should be fine -- it masks the interrupt at the APIC, and the device's interrupt moderation should take care of keeping it from generating interrupts right away. -Mitch -

  1   2   >