Re: [PATCH V7 09/12] thermal: tegra: add thermtrip function

On 2016年03月16日 03:49, Eduardo Valentin wrote: > * PGP Signed by an unknown key > > On Tue, Mar 15, 2016 at 05:12:12PM +0800, Wei Ni wrote: >> >> >> On 2016年03月15日 03:16, Eduardo Valentin wrote: Old Signed by an unknown key >>> >>> On Fri, Mar 11, 2016 at 11:11:12AM +0800, Wei Ni wrote:

Re: [PATCH V7 09/12] thermal: tegra: add thermtrip function

On 2016年03月16日 03:49, Eduardo Valentin wrote: > * PGP Signed by an unknown key > > On Tue, Mar 15, 2016 at 05:12:12PM +0800, Wei Ni wrote: >> >> >> On 2016年03月15日 03:16, Eduardo Valentin wrote: Old Signed by an unknown key >>> >>> On Fri, Mar 11, 2016 at 11:11:12AM +0800, Wei Ni wrote:

Re: [RFC PATCH kernel] Revert "net/mlx4_core: Set UAR page size to 4KB regardless of system page size"

On 03/16/2016 04:10 PM, Eli Cohen wrote: On Wed, Mar 16, 2016 at 01:07:58PM +1100, Alexey Kardashevskiy wrote: So with v4.5 as a host, there is no actual distro available today to use as a guest in the next 6 months (or whatever it takes to backport this partucular patch back there). You

Re: [RFC PATCH kernel] Revert "net/mlx4_core: Set UAR page size to 4KB regardless of system page size"

On 03/16/2016 04:10 PM, Eli Cohen wrote: On Wed, Mar 16, 2016 at 01:07:58PM +1100, Alexey Kardashevskiy wrote: So with v4.5 as a host, there is no actual distro available today to use as a guest in the next 6 months (or whatever it takes to backport this partucular patch back there). You

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

On 15/03/2016:06:47:52 PM, James Morse wrote: > Hi David, > > On 09/03/16 05:32, David Long wrote: > > From: "David A. Long" > > diff --git a/arch/arm64/lib/copy_from_user.S > > b/arch/arm64/lib/copy_from_user.S > > index 4699cd7..0ac2131 100644 > > ---

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

On 15/03/2016:06:47:52 PM, James Morse wrote: > Hi David, > > On 09/03/16 05:32, David Long wrote: > > From: "David A. Long" > > diff --git a/arch/arm64/lib/copy_from_user.S > > b/arch/arm64/lib/copy_from_user.S > > index 4699cd7..0ac2131 100644 > > --- a/arch/arm64/lib/copy_from_user.S > > +++

Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage

On Fri, Mar 11, 2016 at 11:34:40AM +0300, Vladimir Davydov wrote: > On Thu, Mar 10, 2016 at 03:50:13PM -0500, Johannes Weiner wrote: > > When setting memory.high below usage, nothing happens until the next > > charge comes along, and then it will only reclaim its own charge and > > not the now

Re: [PATCH] mm: memcontrol: reclaim when shrinking memory.high below usage

On Fri, Mar 11, 2016 at 11:34:40AM +0300, Vladimir Davydov wrote: > On Thu, Mar 10, 2016 at 03:50:13PM -0500, Johannes Weiner wrote: > > When setting memory.high below usage, nothing happens until the next > > charge comes along, and then it will only reclaim its own charge and > > not the now

RE: [PATCH V2] ACPI: APD: Add device HID for future AMD UART controller

> From: Wang Hongcheng [mailto:annie.w...@amd.com] > Sent: Friday, March 11, 2016 5:28 PM > To: Rafael J. Wysocki; Len Brown; linux-a...@vger.kernel.org; linux- > ker...@vger.kernel.org; SPG_Linux_Kernel > Cc: Wang, Annie > Subject: [PATCH V2] ACPI: APD: Add device HID for future AMD UART >

RE: [PATCH V2] ACPI: APD: Add device HID for future AMD UART controller

> From: Wang Hongcheng [mailto:annie.w...@amd.com] > Sent: Friday, March 11, 2016 5:28 PM > To: Rafael J. Wysocki; Len Brown; linux-a...@vger.kernel.org; linux- > ker...@vger.kernel.org; SPG_Linux_Kernel > Cc: Wang, Annie > Subject: [PATCH V2] ACPI: APD: Add device HID for future AMD UART >

Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async

On Tue, Mar 15, 2016 at 11:07:38PM +0900, Sergey Senozhatsky wrote: > > something like this (*minimally tested so far*). > > -- move wake_up() and friends under the logbuf section; so we can detect ^^

Re: [RFC][PATCH v4 1/2] printk: Make printk() completely async

On Tue, Mar 15, 2016 at 11:07:38PM +0900, Sergey Senozhatsky wrote: > > something like this (*minimally tested so far*). > > -- move wake_up() and friends under the logbuf section; so we can detect ^^

Re: [RFC PATCH kernel] Revert "net/mlx4_core: Set UAR page size to 4KB regardless of system page size"

On Wed, Mar 16, 2016 at 01:07:58PM +1100, Alexey Kardashevskiy wrote: > > So with v4.5 as a host, there is no actual distro available today to > use as a guest in the next 6 months (or whatever it takes to > backport this partucular patch back there). > > You could have added a module parameter

Re: [RFC PATCH kernel] Revert "net/mlx4_core: Set UAR page size to 4KB regardless of system page size"

On Wed, Mar 16, 2016 at 01:07:58PM +1100, Alexey Kardashevskiy wrote: > > So with v4.5 as a host, there is no actual distro available today to > use as a guest in the next 6 months (or whatever it takes to > backport this partucular patch back there). > > You could have added a module parameter

RE: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller

> From: Wang Hongcheng [mailto:annie.w...@amd.com] > Sent: Friday, March 11, 2016 10:59 AM > To: Linus Walleij; linux-g...@vger.kernel.org; linux-kernel@vger.kernel.org; > SPG_Linux_Kernel > Cc: Wang, Annie > Subject: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller > > Add

RE: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller

> From: Wang Hongcheng [mailto:annie.w...@amd.com] > Sent: Friday, March 11, 2016 10:59 AM > To: Linus Walleij; linux-g...@vger.kernel.org; linux-kernel@vger.kernel.org; > SPG_Linux_Kernel > Cc: Wang, Annie > Subject: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller > > Add

Re: [PATCH] mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage

On Fri, Mar 11, 2016 at 12:19:31PM +0300, Vladimir Davydov wrote: > On Fri, Mar 11, 2016 at 09:18:25AM +0100, Michal Hocko wrote: > > On Thu 10-03-16 15:50:14, Johannes Weiner wrote: > ... > > > @@ -5037,9 +5040,36 @@ static ssize_t memory_max_write(struct > > > kernfs_open_file *of, > > > if

Re: [PATCH] mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage

On Fri, Mar 11, 2016 at 12:19:31PM +0300, Vladimir Davydov wrote: > On Fri, Mar 11, 2016 at 09:18:25AM +0100, Michal Hocko wrote: > > On Thu 10-03-16 15:50:14, Johannes Weiner wrote: > ... > > > @@ -5037,9 +5040,36 @@ static ssize_t memory_max_write(struct > > > kernfs_open_file *of, > > > if

Re: [PATCH RFC 0/2] mempool based chained scatterlist alloc/free api api

On Tue, 2016-03-15 at 16:12 -0700, James Bottomley wrote: > On Tue, 2016-03-15 at 15:39 -0700, Ming Lin wrote: > > From: Ming Lin > > > > Hi list, > > > > This moves the mempool based chained scatterlist alloc/free code > > from > > scsi_lib.c to lib/scatterlist.c. > >

Re: [PATCH RFC 0/2] mempool based chained scatterlist alloc/free api api

On Tue, 2016-03-15 at 16:12 -0700, James Bottomley wrote: > On Tue, 2016-03-15 at 15:39 -0700, Ming Lin wrote: > > From: Ming Lin > > > > Hi list, > > > > This moves the mempool based chained scatterlist alloc/free code > > from > > scsi_lib.c to lib/scatterlist.c. > > > > So other drivers(for

Re: [PATCH V2 2/2] mailbox: Introduce TI message manager driver

On Tue, Mar 15, 2016 at 10:35 PM, Nishanth Menon wrote: > On Tue, Mar 15, 2016 at 12:31 AM, Jassi Brar wrote: >> On Tue, Mar 8, 2016 at 8:07 PM, Nishanth Menon wrote: >>> Jassi, >>> >>> On Tue, Mar 8, 2016 at 1:10 AM, Jassi Brar

Re: [PATCH V2 2/2] mailbox: Introduce TI message manager driver

On Tue, Mar 15, 2016 at 10:35 PM, Nishanth Menon wrote: > On Tue, Mar 15, 2016 at 12:31 AM, Jassi Brar wrote: >> On Tue, Mar 8, 2016 at 8:07 PM, Nishanth Menon wrote: >>> Jassi, >>> >>> On Tue, Mar 8, 2016 at 1:10 AM, Jassi Brar wrote: On Tue, Mar 8, 2016 at 2:18 AM, Nishanth Menon

Re: [GIT PULL] LED subsystem updates for 4.6

On Mon, Mar 14, 2016 at 3:24 AM, Jacek Anaszewski wrote: > > New LED class driver: > > - Add driver for the ISSI IS31FL32xx family of LED controllers. Grr. This has apparently not gotten with the program, and causes a few annoying warnings:

Re: [GIT PULL] LED subsystem updates for 4.6

On Mon, Mar 14, 2016 at 3:24 AM, Jacek Anaszewski wrote: > > New LED class driver: > > - Add driver for the ISSI IS31FL32xx family of LED controllers. Grr. This has apparently not gotten with the program, and causes a few annoying warnings: drivers/leds/leds-is31fl32xx.c: In function

Re: [GIT PULL] LED subsystem updates for 4.6

On Tue, Mar 15, 2016 at 12:51 AM, Jacek Anaszewski wrote: > > I just wanted to make sure that no unexpected problem has occurred > after rebasing onto 4.5 release. Is it in some way more advantageous to > base a pull request on rc7, than on a final release? I'd rather

Re: [GIT PULL] LED subsystem updates for 4.6

On Tue, Mar 15, 2016 at 12:51 AM, Jacek Anaszewski wrote: > > I just wanted to make sure that no unexpected problem has occurred > after rebasing onto 4.5 release. Is it in some way more advantageous to > base a pull request on rc7, than on a final release? I'd rather see the pull request based

Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources

On 03/15/2016 10:46 PM, David Lechner wrote: On 03/15/2016 05:45 PM, Sergei Shtylyov wrote: No, this register is shared b/w MUSB and OHCI. The proper thing to do is to write the PHY driver and let it control this shared register. OK. I've started working on this. I am looking at using

Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources

On 03/15/2016 10:46 PM, David Lechner wrote: On 03/15/2016 05:45 PM, Sergei Shtylyov wrote: No, this register is shared b/w MUSB and OHCI. The proper thing to do is to write the PHY driver and let it control this shared register. OK. I've started working on this. I am looking at using

Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature

> > The following series adds the ability for a hypervisor to set an MTU on the > guest during feature negotiation phase. This is useful for VM orchestration > when, for instance, tunneling is involved and the MTU of the various systems > should be homogenous. > > The first patch adds the

Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature

> > The following series adds the ability for a hypervisor to set an MTU on the > guest during feature negotiation phase. This is useful for VM orchestration > when, for instance, tunneling is involved and the MTU of the various systems > should be homogenous. > > The first patch adds the

Re: [PATCH] nouveau: fix nv40_perfctr_next() cleanup regression

On 03/15/2016 12:24 AM, Arnd Bergmann wrote: > gcc-6 warns about code in the nouveau driver that is obviously silly: > > drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function > 'nv40_perfctr_next': > drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison > always

Re: [PATCH] nouveau: fix nv40_perfctr_next() cleanup regression

On 03/15/2016 12:24 AM, Arnd Bergmann wrote: > gcc-6 warns about code in the nouveau driver that is obviously silly: > > drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function > 'nv40_perfctr_next': > drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison > always

Re: [PATCH] cpufreq: acpi: Allow new dynamics attributes to be added to acpi_cpufreq_attr

On 09-03-16, 14:13, Rafael J. Wysocki wrote: > On Wed, Mar 9, 2016 at 10:41 AM, Viresh Kumar wrote: > > On 03-03-16, 18:29, Rafael J. Wysocki wrote: > >> Srinivas, can you please take this and rebase your patch on top of it? > >> Or if you prefer, I can take it into my

Re: [PATCH] cpufreq: acpi: Allow new dynamics attributes to be added to acpi_cpufreq_attr

On 09-03-16, 14:13, Rafael J. Wysocki wrote: > On Wed, Mar 9, 2016 at 10:41 AM, Viresh Kumar wrote: > > On 03-03-16, 18:29, Rafael J. Wysocki wrote: > >> Srinivas, can you please take this and rebase your patch on top of it? > >> Or if you prefer, I can take it into my linux-next branch. > > > >

Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()

On 16-03-16, 01:51, Rafael J. Wysocki wrote: > OK, so the problem with doing that in syscore ops is that the I2C bus > needed for it may not be available at that point, which is fair > enough. Not just that. We wouldn't call syscore-ops for the boot-cpu. It never went away. > Still, though, the

Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()

On 16-03-16, 01:51, Rafael J. Wysocki wrote: > OK, so the problem with doing that in syscore ops is that the I2C bus > needed for it may not be available at that point, which is fair > enough. Not just that. We wouldn't call syscore-ops for the boot-cpu. It never went away. > Still, though, the

Re: [RESEND PATCH v2] ARM64: ACPI: Update documentation for latest specification version

Hi Al Stone, On Wed, Mar 16, 2016 at 1:58 AM, Al Stone wrote: > The ACPI 6.1 specification was recently released at the end of January 2016, > but the arm64 kernel documentation for the use of ACPI was written for the > 5.1 version of the spec. There were significant

Re: [RESEND PATCH v2] ARM64: ACPI: Update documentation for latest specification version

Hi Al Stone, On Wed, Mar 16, 2016 at 1:58 AM, Al Stone wrote: > The ACPI 6.1 specification was recently released at the end of January 2016, > but the arm64 kernel documentation for the use of ACPI was written for the > 5.1 version of the spec. There were significant additions to the spec that

Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()

On 15-03-16, 13:11, Rafael J. Wysocki wrote: > On Tue, Mar 15, 2016 at 7:10 AM, Viresh Kumar wrote: > > On 12-03-16, 03:05, Rafael J. Wysocki wrote: > >> From: Rafael J. Wysocki > >> > >> cpufreq_resume() attempts to resync the current

Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq_resume()

On 15-03-16, 13:11, Rafael J. Wysocki wrote: > On Tue, Mar 15, 2016 at 7:10 AM, Viresh Kumar wrote: > > On 12-03-16, 03:05, Rafael J. Wysocki wrote: > >> From: Rafael J. Wysocki > >> > >> cpufreq_resume() attempts to resync the current frequency with > >> policy->cur for the first online CPU,

Re: kernel OOPS in MM(?)

Hello, On 2016-03-10 12:31, Evgenii Lepikhin wrote: > We need help to understand the source of the problem and may be to create a > bugreport. Here is crash report: > > Mar 10 04:03:51 l28 kernel: [2075560.434445] BUG: unable to handle kernel > paging request at 40008021 > Mar 10

Re: kernel OOPS in MM(?)

Hello, On 2016-03-10 12:31, Evgenii Lepikhin wrote: > We need help to understand the source of the problem and may be to create a > bugreport. Here is crash report: > > Mar 10 04:03:51 l28 kernel: [2075560.434445] BUG: unable to handle kernel > paging request at 40008021 > Mar 10

Re: [PATCH V2 2/3] vfio, platform: make reset driver a requirement

Hi Sinan, On 03/13/2016 06:25 PM, Sinan Kaya wrote: > On 3/11/2016 11:54 AM, Sinan Kaya wrote: >> The code was allowing platform devices to be used without a supporting VFIO >> reset driver. The hardware can be left in some inconsistent state after a >> guest machine abort. >> >> The reset driver

Re: [PATCH V2 2/3] vfio, platform: make reset driver a requirement

Hi Sinan, On 03/13/2016 06:25 PM, Sinan Kaya wrote: > On 3/11/2016 11:54 AM, Sinan Kaya wrote: >> The code was allowing platform devices to be used without a supporting VFIO >> reset driver. The hardware can be left in some inconsistent state after a >> guest machine abort. >> >> The reset driver

Re: [WTF] utterly tasteless ABI in hfi1 (around ->write()/->write_iter())

On Tue, Mar 15, 2016 at 9:17 PM, Al Viro wrote: > > Take a look at drivers/staging/rdma/hfi1/file_ops.c in -next and > compare hfi1_write_iter() with hfi1_file_write(). Folks, this ABI is too > ugly to live, let alone to be allowed breeding. > > It's also

Re: [WTF] utterly tasteless ABI in hfi1 (around ->write()/->write_iter())

On Tue, Mar 15, 2016 at 9:17 PM, Al Viro wrote: > > Take a look at drivers/staging/rdma/hfi1/file_ops.c in -next and > compare hfi1_write_iter() with hfi1_file_write(). Folks, this ABI is too > ugly to live, let alone to be allowed breeding. > > It's also brittle as hell -

[WTF] utterly tasteless ABI in hfi1 (around ->write()/->write_iter())

Folks, we'd discussed that kind of crap already; why, in name of everything unholy, is that kind of garbage brought back in a new driver? Having both ->write() and ->write_iter() *AND* having entirely unrelated interpretation of user input on those two on the same device is bogus,

[WTF] utterly tasteless ABI in hfi1 (around ->write()/->write_iter())

Folks, we'd discussed that kind of crap already; why, in name of everything unholy, is that kind of garbage brought back in a new driver? Having both ->write() and ->write_iter() *AND* having entirely unrelated interpretation of user input on those two on the same device is bogus,

Re: [PATCH 3.10 00/18] 3.10.101-stable review

On Tue, Mar 15, 2016 at 08:08:09PM -0700, Guenter Roeck wrote: > On 03/14/2016 10:52 AM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.10.101 release. > >There are 18 patches in this series, all will be posted as a response > >to this one. If anyone has any

Re: [PATCH 3.10 00/18] 3.10.101-stable review

On Tue, Mar 15, 2016 at 08:08:09PM -0700, Guenter Roeck wrote: > On 03/14/2016 10:52 AM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.10.101 release. > >There are 18 patches in this series, all will be posted as a response > >to this one. If anyone has any

Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util

Hi Mike, On 03/15/2016 03:06 PM, Michael Turquette wrote: >>> > > void cpufreq_set_freq_update_hook(int cpu, struct freq_update_hook >>> > > *hook, >>> > > + void (*func)(struct freq_update_hook *hook, >>> > > + enum sched_class_util

Re: [PATCH 5/8] sched/cpufreq: pass sched class into cpufreq_update_util

Hi Mike, On 03/15/2016 03:06 PM, Michael Turquette wrote: >>> > > void cpufreq_set_freq_update_hook(int cpu, struct freq_update_hook >>> > > *hook, >>> > > + void (*func)(struct freq_update_hook *hook, >>> > > + enum sched_class_util

Re: [PATCH 1/1] KVM: don't allow irq_fpu_usable when the VCPU's XCR0 is loaded

On 03/16/2016 03:32 AM, Paolo Bonzini wrote: On 15/03/2016 19:27, Andy Lutomirski wrote: On Mon, Mar 14, 2016 at 6:17 AM, Paolo Bonzini wrote: On 11/03/2016 22:33, David Matlack wrote: Is this better than just always keeping the host's XCR0 loaded outside if the

Re: [PATCH 1/1] KVM: don't allow irq_fpu_usable when the VCPU's XCR0 is loaded

On 03/16/2016 03:32 AM, Paolo Bonzini wrote: On 15/03/2016 19:27, Andy Lutomirski wrote: On Mon, Mar 14, 2016 at 6:17 AM, Paolo Bonzini wrote: On 11/03/2016 22:33, David Matlack wrote: Is this better than just always keeping the host's XCR0 loaded outside if the KVM interrupts-disabled

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

On Tue, Mar 15, 2016 at 8:43 PM, Xiao Guangrong wrote: > > > On 03/16/2016 03:01 AM, David Matlack wrote: >> >> On Mon, Mar 14, 2016 at 12:46 AM, Xiao Guangrong >> wrote: >>> >>> >>> >>> On 03/12/2016 04:47 AM, David Matlack wrote:

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

On Tue, Mar 15, 2016 at 8:43 PM, Xiao Guangrong wrote: > > > On 03/16/2016 03:01 AM, David Matlack wrote: >> >> On Mon, Mar 14, 2016 at 12:46 AM, Xiao Guangrong >> wrote: >>> >>> >>> >>> On 03/12/2016 04:47 AM, David Matlack wrote: >>> I have not been able to trigger this bug on Linux 4.3,

Re: [PATCH V7 03/12] thermal: tegra: get rid of PDIV/HOTSPOT hack

On 2016年03月16日 03:56, Eduardo Valentin wrote: > * PGP Signed by an unknown key > > On Tue, Mar 15, 2016 at 02:21:53PM +0800, Wei Ni wrote: >> >> >> On 2016年03月15日 04:05, Eduardo Valentin wrote: Old Signed by an unknown key >>> >>> On Fri, Mar 11, 2016 at 11:09:14AM +0800, Wei Ni wrote:

Re: [PATCH V7 03/12] thermal: tegra: get rid of PDIV/HOTSPOT hack

On 2016年03月16日 03:56, Eduardo Valentin wrote: > * PGP Signed by an unknown key > > On Tue, Mar 15, 2016 at 02:21:53PM +0800, Wei Ni wrote: >> >> >> On 2016年03月15日 04:05, Eduardo Valentin wrote: Old Signed by an unknown key >>> >>> On Fri, Mar 11, 2016 at 11:09:14AM +0800, Wei Ni wrote:

Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources

On 03/15/2016 05:45 PM, Sergei Shtylyov wrote: No, this register is shared b/w MUSB and OHCI. The proper thing to do is to write the PHY driver and let it control this shared register. OK. I've started working on this. I am looking at using struct usb_phy, however, enum usb_phy_type

Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources

On 03/15/2016 05:45 PM, Sergei Shtylyov wrote: No, this register is shared b/w MUSB and OHCI. The proper thing to do is to write the PHY driver and let it control this shared register. OK. I've started working on this. I am looking at using struct usb_phy, however, enum usb_phy_type

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

On 03/16/2016 03:01 AM, David Matlack wrote: On Mon, Mar 14, 2016 at 12:46 AM, Xiao Guangrong wrote: On 03/12/2016 04:47 AM, David Matlack wrote: I have not been able to trigger this bug on Linux 4.3, and suspect it is due to this commit from Linux 4.2:

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

On 03/16/2016 03:01 AM, David Matlack wrote: On Mon, Mar 14, 2016 at 12:46 AM, Xiao Guangrong wrote: On 03/12/2016 04:47 AM, David Matlack wrote: I have not been able to trigger this bug on Linux 4.3, and suspect it is due to this commit from Linux 4.2: 653f52c kvm,x86: load guest FPU

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

On Tue, Mar 15, 2016 at 2:14 AM, Christoph Hellwig wrote: > On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote: >> A loosely related question is what can be done for tools around existing >> interfaces for ACLs. I recently found out NTFS-3g has this xattr: >> >>

Re: [PATCH v18 00/22] Richacls (Core and Ext4)

On Tue, Mar 15, 2016 at 2:14 AM, Christoph Hellwig wrote: > On Fri, Mar 11, 2016 at 02:05:16PM -0600, Steve French wrote: >> A loosely related question is what can be done for tools around existing >> interfaces for ACLs. I recently found out NTFS-3g has this xattr: >> >> static const char

[PATCH v2 06/22] ncr5380: Remove PSEUDO_DMA macro

For those wrapper drivers which only implement Programmed IO, have NCR5380_dma_xfer_len() evaluate to zero. That allows PDMA to be easily disabled at run-time and so the PSEUDO_DMA macro is no longer needed. Also remove the spin counters used for debugging pseudo DMA drivers. Signed-off-by: Finn

[PATCH v2 06/22] ncr5380: Remove PSEUDO_DMA macro

For those wrapper drivers which only implement Programmed IO, have NCR5380_dma_xfer_len() evaluate to zero. That allows PDMA to be easily disabled at run-time and so the PSEUDO_DMA macro is no longer needed. Also remove the spin counters used for debugging pseudo DMA drivers. Signed-off-by: Finn

[PATCH v2 03/22] ncr5380: Remove REAL_DMA and REAL_DMA_POLL macros

For the NCR5380.c core driver, these macros are never used. If REAL_DMA were to be defined, compilation would fail. For the atari_NCR5380.c core driver, REAL_DMA is always defined. Hence these macros are pointless. Signed-off-by: Finn Thain Reviewed-by: Hannes

[PATCH v2 03/22] ncr5380: Remove REAL_DMA and REAL_DMA_POLL macros

For the NCR5380.c core driver, these macros are never used. If REAL_DMA were to be defined, compilation would fail. For the atari_NCR5380.c core driver, REAL_DMA is always defined. Hence these macros are pointless. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke ---

[PATCH v2 05/22] ncr5380: Disable the DMA errata workaround flag by default

The only chip that needs the workarounds enabled is an early NMOS device. That means that the common case is to disable them. Unfortunately the sense of the flag is such that it has to be set for the common case. Rename the flag so that zero can be used to mean "no errata workarounds needed".

[PATCH v2 01/22] g_ncr5380: Remove CONFIG_SCSI_GENERIC_NCR53C400

This change brings a number of improvements: fewer macros, better test coverage, simpler code and sane Kconfig options. The downside is a small chance of incompatibility (which seems unavoidable). CONFIG_SCSI_GENERIC_NCR53C400 exists to enable or inhibit pseudo DMA transfers when the driver is

[PATCH v2 01/22] g_ncr5380: Remove CONFIG_SCSI_GENERIC_NCR53C400

This change brings a number of improvements: fewer macros, better test coverage, simpler code and sane Kconfig options. The downside is a small chance of incompatibility (which seems unavoidable). CONFIG_SCSI_GENERIC_NCR53C400 exists to enable or inhibit pseudo DMA transfers when the driver is

[PATCH v2 05/22] ncr5380: Disable the DMA errata workaround flag by default

The only chip that needs the workarounds enabled is an early NMOS device. That means that the common case is to disable them. Unfortunately the sense of the flag is such that it has to be set for the common case. Rename the flag so that zero can be used to mean "no errata workarounds needed".

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On 03/15/2016 03:37 PM, Michael Turquette wrote: Yuck sysfs.. I would really rather we did not expose this per default. > > > And certainly not in this weird form. >>> > > >>> > > I'm happy to change capacity_margin to up_threshold and use a >>> > > percentage. >>> > > >>> > > The

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On 03/15/2016 03:37 PM, Michael Turquette wrote: Yuck sysfs.. I would really rather we did not expose this per default. > > > And certainly not in this weird form. >>> > > >>> > > I'm happy to change capacity_margin to up_threshold and use a >>> > > percentage. >>> > > >>> > > The

[PATCH v2 10/22] ncr5380: Merge DMA implementation from atari_NCR5380 core driver

Adopt the DMA implementation from atari_NCR5380.c. This means that atari_scsi and sun3_scsi can make use of the NCR5380.c core driver and the atari_NCR5380.c driver fork can be made redundant. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke ---

[PATCH v2 08/22] ncr5380: Use DMA hooks for PDMA

Those wrapper drivers which use DMA define the REAL_DMA macro and those which use pseudo DMA define PSEUDO_DMA. These macros need to be removed for a number of reasons, not least of which is to have drivers share more code. Redefine the PDMA send and receive hooks as DMA setup hooks, so that the

[PATCH v2 10/22] ncr5380: Merge DMA implementation from atari_NCR5380 core driver

Adopt the DMA implementation from atari_NCR5380.c. This means that atari_scsi and sun3_scsi can make use of the NCR5380.c core driver and the atari_NCR5380.c driver fork can be made redundant. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke --- drivers/scsi/NCR5380.c | 170

[PATCH v2 08/22] ncr5380: Use DMA hooks for PDMA

Those wrapper drivers which use DMA define the REAL_DMA macro and those which use pseudo DMA define PSEUDO_DMA. These macros need to be removed for a number of reasons, not least of which is to have drivers share more code. Redefine the PDMA send and receive hooks as DMA setup hooks, so that the

[PATCH v2 11/22] atari_scsi: Adopt NCR5380.c core driver

Add support for the Atari ST DMA chip to the NCR5380.c core driver. This code is copied from atari_NCR5380.c. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke --- drivers/scsi/NCR5380.c| 32

[PATCH v2 12/22] sun3_scsi: Adopt NCR5380.c core driver

Add support for the custom Sun 3 DMA logic to the NCR5380.c core driver. This code is copied from atari_NCR5380.c. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke --- The Sun 3 DMA code is still configured by macros. I have simplified things

[PATCH v2 07/22] ncr5380: Remove BOARD_REQUIRES_NO_DELAY macro

The io_recovery_delay macro is intended to insert a microsecond delay between the chip register accesses that begin a DMA operation. This is reportedly needed for some ISA boards. Reverse the sense of the macro test so that in the common case, where no delay is required, drivers need not define

[PATCH v2 12/22] sun3_scsi: Adopt NCR5380.c core driver

Add support for the custom Sun 3 DMA logic to the NCR5380.c core driver. This code is copied from atari_NCR5380.c. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke --- The Sun 3 DMA code is still configured by macros. I have simplified things slightly but I have avoided more ambitious

[PATCH v2 07/22] ncr5380: Remove BOARD_REQUIRES_NO_DELAY macro

The io_recovery_delay macro is intended to insert a microsecond delay between the chip register accesses that begin a DMA operation. This is reportedly needed for some ISA boards. Reverse the sense of the macro test so that in the common case, where no delay is required, drivers need not define

[PATCH v2 11/22] atari_scsi: Adopt NCR5380.c core driver

Add support for the Atari ST DMA chip to the NCR5380.c core driver. This code is copied from atari_NCR5380.c. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke --- drivers/scsi/NCR5380.c| 32 drivers/scsi/atari_scsi.c |6 +++--- 2 files changed,

[PATCH v2 09/22] ncr5380: Adopt uniform DMA setup convention

Standardize the DMA setup hooks so that the DMA implementation in atari_NCR5380.c can be reconciled with pseudo DMA implementation in NCR5380.c. Calls to NCR5380_dma_recv_setup() and NCR5380_dma_send_setup() return a negative value on failure, zero on PDMA transfer success and a positive byte

[PATCH v2 09/22] ncr5380: Adopt uniform DMA setup convention

Standardize the DMA setup hooks so that the DMA implementation in atari_NCR5380.c can be reconciled with pseudo DMA implementation in NCR5380.c. Calls to NCR5380_dma_recv_setup() and NCR5380_dma_send_setup() return a negative value on failure, zero on PDMA transfer success and a positive byte

[PATCH v2 22/22] mac_scsi: Fix pseudo DMA implementation

Fix various issues: Comments about bus errors are incorrect. The PDMA asm must return the size of the memory access that faulted so the transfer count can be adjusted accordingly. A phase change may cause a bus error but should not be treated as failure. A bus error does not always imply a phase

[PATCH v2 14/22] ncr5380: Reduce max_lun limit

The driver has a limit of eight LUs because of the byte-sized bitfield that is used for busy flags. That means the maximum LUN is 7. The default is 8. Signed-off-by: Finn Thain --- Changed since v1: - Reduce shost->max_lun limit instead of adding 'MAX_LUN' limit.

[PATCH v2 22/22] mac_scsi: Fix pseudo DMA implementation

Fix various issues: Comments about bus errors are incorrect. The PDMA asm must return the size of the memory access that faulted so the transfer count can be adjusted accordingly. A phase change may cause a bus error but should not be treated as failure. A bus error does not always imply a phase

[PATCH v2 14/22] ncr5380: Reduce max_lun limit

The driver has a limit of eight LUs because of the byte-sized bitfield that is used for busy flags. That means the maximum LUN is 7. The default is 8. Signed-off-by: Finn Thain --- Changed since v1: - Reduce shost->max_lun limit instead of adding 'MAX_LUN' limit. --- drivers/scsi/NCR5380.c |

[PATCH v2 18/22] ncr5380: Remove DONT_USE_INTR and AUTOPROBE_IRQ macros

Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke --- drivers/scsi/NCR5380.c | 12 +--- drivers/scsi/NCR5380.h |4 drivers/scsi/arm/oak.c |2 -- drivers/scsi/dmx3191d.c |2 -- drivers/scsi/dtc.c | 12

[PATCH v2 13/22] ncr5380: Remove disused atari_NCR5380.c core driver

Now that atari_scsi and sun3_scsi have been converted to use the NCR5380.c core driver, remove atari_NCR5380.c. Also remove the last vestiges of its Tagged Command Queueing implementation from the wrapper drivers. The TCQ support in atari_NCR5380.c is abandoned by this patch. It is not merged

[PATCH v2 18/22] ncr5380: Remove DONT_USE_INTR and AUTOPROBE_IRQ macros

Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke --- drivers/scsi/NCR5380.c | 12 +--- drivers/scsi/NCR5380.h |4 drivers/scsi/arm/oak.c |2 -- drivers/scsi/dmx3191d.c |2 -- drivers/scsi/dtc.c | 12 +++- drivers/scsi/g_NCR5380.c |2

[PATCH v2 13/22] ncr5380: Remove disused atari_NCR5380.c core driver

Now that atari_scsi and sun3_scsi have been converted to use the NCR5380.c core driver, remove atari_NCR5380.c. Also remove the last vestiges of its Tagged Command Queueing implementation from the wrapper drivers. The TCQ support in atari_NCR5380.c is abandoned by this patch. It is not merged

[PATCH v2 04/22] atari_NCR5380: Remove DMA_MIN_SIZE macro

Only the atari_scsi and sun3_scsi drivers define DMA_MIN_SIZE. Both drivers also define NCR5380_dma_xfer_len, which means DMA_MIN_SIZE can be removed from the core driver. This removes another discrepancy between the two core drivers. Signed-off-by: Finn Thain ---

[PATCH v2 00/22] ncr5380: Eliminate macros, reduce code duplication, fix bugs etc

This patch series has more macro elimination and some tweaks to the DMA hooks so that all the wrapper drivers can share the same core DMA algorithm. This resolves the major discrepancies between the two core drivers, which relate to code conditional on the REAL_DMA and PSEUDO_DMA macros. After

[PATCH v2 04/22] atari_NCR5380: Remove DMA_MIN_SIZE macro

Only the atari_scsi and sun3_scsi drivers define DMA_MIN_SIZE. Both drivers also define NCR5380_dma_xfer_len, which means DMA_MIN_SIZE can be removed from the core driver. This removes another discrepancy between the two core drivers. Signed-off-by: Finn Thain --- Changes since v1: - Retain

[PATCH v2 00/22] ncr5380: Eliminate macros, reduce code duplication, fix bugs etc

This patch series has more macro elimination and some tweaks to the DMA hooks so that all the wrapper drivers can share the same core DMA algorithm. This resolves the major discrepancies between the two core drivers, which relate to code conditional on the REAL_DMA and PSEUDO_DMA macros. After

[PATCH v2 20/22] atari_scsi: Set a reasonable default for cmd_per_lun

This setting does not need to be conditional on Atari ST or TT. Signed-off-by: Finn Thain --- Changed since v1: - Set the default cmd_per_lun to 4 based on test results. --- drivers/scsi/atari_scsi.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

[PATCH v2 21/22] atari_scsi: Allow can_queue to be increased for Falcon

The benefit of limiting can_queue to 1 is that atari_scsi shares the ST DMA chip more fairly with other drivers (e.g. falcon-ide). Unfortunately, this can limit SCSI bus utilization. On systems without IDE, atari_scsi should issue SCSI commands whenever it can arbitrate for the bus. Make that

  1   2   3   4   5   6   7   8   9   10   >