Re: [PATCH v18 19/22] richacl: Add richacl xattr handler

On Tue, Mar 15, 2016 at 12:10:14AM -0700, Christoph Hellwig wrote: > On Fri, Mar 11, 2016 at 09:19:05AM -0500, J. Bruce Fields wrote: > > On Fri, Mar 11, 2016 at 06:17:35AM -0800, Christoph Hellwig wrote: > > > On Mon, Feb 29, 2016 at 09:17:24AM +0100, Andreas Gruenbacher wrote: > > > > Add

Re: [PATCH v18 19/22] richacl: Add richacl xattr handler

On Tue, Mar 15, 2016 at 12:10:14AM -0700, Christoph Hellwig wrote: > On Fri, Mar 11, 2016 at 09:19:05AM -0500, J. Bruce Fields wrote: > > On Fri, Mar 11, 2016 at 06:17:35AM -0800, Christoph Hellwig wrote: > > > On Mon, Feb 29, 2016 at 09:17:24AM +0100, Andreas Gruenbacher wrote: > > > > Add

[RFC v2 -next 2/2] virtio_net: Read the advised MTU

This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it exists, read the advised MTU and use it. No proper error handling is provided for the case where a user changes the negotiated MTU. A future commit will add proper error handling. Instead, a warning is emitted if the guest

[RFC v2 -next 2/2] virtio_net: Read the advised MTU

This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it exists, read the advised MTU and use it. No proper error handling is provided for the case where a user changes the negotiated MTU. A future commit will add proper error handling. Instead, a warning is emitted if the guest

[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 feature bit as

[RFC v2 -next 1/2] virtio: Start feature MTU support

This commit adds the feature bit and associated mtu device entry for the virtio network device. Future commits will make use of these bits to support negotiated MTU. Signed-off-by: Aaron Conole --- v2: * No change include/uapi/linux/virtio_net.h | 3 +++ 1 file changed, 3

[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 feature bit as

[RFC v2 -next 1/2] virtio: Start feature MTU support

This commit adds the feature bit and associated mtu device entry for the virtio network device. Future commits will make use of these bits to support negotiated MTU. Signed-off-by: Aaron Conole --- v2: * No change include/uapi/linux/virtio_net.h | 3 +++ 1 file changed, 3 insertions(+) diff

Re: [RFC -next 2/2] virtio_net: Read and use the advised MTU

Sergei Shtylyov writes: > Hello. Hi Sergei, > On 03/10/2016 05:28 PM, Aaron Conole wrote: > >> This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it >> exists, read the advised MTU and use it. >> >> No proper error handling is provided

Re: [RFC -next 2/2] virtio_net: Read and use the advised MTU

Sergei Shtylyov writes: > Hello. Hi Sergei, > On 03/10/2016 05:28 PM, Aaron Conole wrote: > >> This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it >> exists, read the advised MTU and use it. >> >> No proper error handling is provided for the case where a user changes the

Re: [RFC -next 2/2] virtio_net: Read and use the advised MTU

Paolo Abeni writes: > On Thu, 2016-03-10 at 09:28 -0500, Aaron Conole wrote: >> This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it >> exists, read the advised MTU and use it. >> >> No proper error handling is provided for the case where a user changes

Re: [RFC -next 2/2] virtio_net: Read and use the advised MTU

Paolo Abeni writes: > On Thu, 2016-03-10 at 09:28 -0500, Aaron Conole wrote: >> This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it >> exists, read the advised MTU and use it. >> >> No proper error handling is provided for the case where a user changes the >> negotiated

Re: [PATCH 0/5] Modularize PCI_DW related drivers.

On 03/01/2016 04:35 PM, Arnd Bergmann wrote: > On Monday 29 February 2016 14:59:35 Kishon Vijay Abraham I wrote: >>> } >>> >>> You just need to pass the same resource in here htat you pass into >>> pci_remap_iospace(). >> >> I still seem to get the abort in ioremap_page_range(). >> >> Here's the

Re: [PATCH 0/5] Modularize PCI_DW related drivers.

On 03/01/2016 04:35 PM, Arnd Bergmann wrote: > On Monday 29 February 2016 14:59:35 Kishon Vijay Abraham I wrote: >>> } >>> >>> You just need to pass the same resource in here htat you pass into >>> pci_remap_iospace(). >> >> I still seem to get the abort in ioremap_page_range(). >> >> Here's the

Re: [PATCH] kbuild: drop FORCE from PHONY targets

On Tue, Mar 15, 2016 at 1:45 PM, Michal Marek wrote: > Dne 15.3.2016 v 19:27 Andy Lutomirski napsal(a): >> Fair enough, although I'm curious why this happens. It might be worth >> changing the docs to say that .PHONY is *not* an substitute for FORCE >> in that context, then. > >

Re: [PATCH] kbuild: drop FORCE from PHONY targets

On Tue, Mar 15, 2016 at 1:45 PM, Michal Marek wrote: > Dne 15.3.2016 v 19:27 Andy Lutomirski napsal(a): >> Fair enough, although I'm curious why this happens. It might be worth >> changing the docs to say that .PHONY is *not* an substitute for FORCE >> in that context, then. > > These two are

[PATCH 1/2] btrfs: cleaner_kthread() doesn't need explicit freeze

cleaner_kthread() is not marked freezable, and therefore calling try_to_freeze() in its context is a pointless no-op. In addition to that, as has been clearly demonstrated by 80ad623edd2d ("Revert "btrfs: clear PF_NOFREEZE in cleaner_kthread()"), it's perfectly valid / legal for

[PATCH 2/2] btrfs: transaction_kthread() is not freezable

transaction_kthread() is calling try_to_freeze(), but that's just an expeinsive no-op given the fact that the thread is not marked freezable. After removing this, disk-io.c is now independent on freezer API. Signed-off-by: Jiri Kosina --- fs/btrfs/disk-io.c | 15

[PATCH 1/2] btrfs: cleaner_kthread() doesn't need explicit freeze

cleaner_kthread() is not marked freezable, and therefore calling try_to_freeze() in its context is a pointless no-op. In addition to that, as has been clearly demonstrated by 80ad623edd2d ("Revert "btrfs: clear PF_NOFREEZE in cleaner_kthread()"), it's perfectly valid / legal for

[PATCH 2/2] btrfs: transaction_kthread() is not freezable

transaction_kthread() is calling try_to_freeze(), but that's just an expeinsive no-op given the fact that the thread is not marked freezable. After removing this, disk-io.c is now independent on freezer API. Signed-off-by: Jiri Kosina --- fs/btrfs/disk-io.c | 15 ++- 1 file

Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity

Quoting Dietmar Eggemann (2016-03-15 12:13:58) > On 14/03/16 05:22, Michael Turquette wrote: > > arch_scale_freq_capacity is weird. It specifies an arch hook for an > > implementation that could easily vary within an architecture or even a > > chip family. > > > > This patch helps to mitigate

Re: [PATCH 2/2] nouveau: use new vga_switcheroo power domain.

Hi Dave, On Thu, Mar 10, 2016 at 08:04:26AM +1000, Dave Airlie wrote: > On 10 March 2016 at 00:40, Lukas Wunner wrote: > > On Wed, Mar 09, 2016 at 04:14:05PM +1000, Dave Airlie wrote: > >> From: Dave Airlie > >> > >> This fixes GPU auto powerdown on the

Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity

Quoting Dietmar Eggemann (2016-03-15 12:13:58) > On 14/03/16 05:22, Michael Turquette wrote: > > arch_scale_freq_capacity is weird. It specifies an arch hook for an > > implementation that could easily vary within an architecture or even a > > chip family. > > > > This patch helps to mitigate

Re: [PATCH 2/2] nouveau: use new vga_switcheroo power domain.

Hi Dave, On Thu, Mar 10, 2016 at 08:04:26AM +1000, Dave Airlie wrote: > On 10 March 2016 at 00:40, Lukas Wunner wrote: > > On Wed, Mar 09, 2016 at 04:14:05PM +1000, Dave Airlie wrote: > >> From: Dave Airlie > >> > >> This fixes GPU auto powerdown on the Lenovo W541, > >> since we advertise

Re: [PATCH] kbuild: drop FORCE from PHONY targets

Dne 15.3.2016 v 19:27 Andy Lutomirski napsal(a): > Fair enough, although I'm curious why this happens. It might be worth > changing the docs to say that .PHONY is *not* an substitute for FORCE > in that context, then. These two are unrelated, except that FORCE is redundant for a .PHONY target.

Re: [PATCH] kbuild: drop FORCE from PHONY targets

Dne 15.3.2016 v 19:27 Andy Lutomirski napsal(a): > Fair enough, although I'm curious why this happens. It might be worth > changing the docs to say that .PHONY is *not* an substitute for FORCE > in that context, then. These two are unrelated, except that FORCE is redundant for a .PHONY target.

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 1:14 PM, Dave Chinner wrote: > > Root can still change the group id of a file that has exposed stale > data and hence make it visible outside of the group based > containment wall. Ok, Dave, now you're just being ridiculous. The issue has never been

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Tue, Mar 15, 2016 at 1:14 PM, Dave Chinner wrote: > > Root can still change the group id of a file that has exposed stale > data and hence make it visible outside of the group based > containment wall. Ok, Dave, now you're just being ridiculous. The issue has never been - and *should* never

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

On Tue, Mar 15, 2016 at 08:45:14AM -0700, Jeremy Allison wrote: > On Tue, Mar 15, 2016 at 12:11:03AM -0700, Christoph Hellwig wrote: > > People have long learned that we only have 'alloc' permissions. Any > > model that mixes allow and deny ACE is a mistake. > > People can also learn and change

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

On Tue, Mar 15, 2016 at 08:45:14AM -0700, Jeremy Allison wrote: > On Tue, Mar 15, 2016 at 12:11:03AM -0700, Christoph Hellwig wrote: > > People have long learned that we only have 'alloc' permissions. Any > > model that mixes allow and deny ACE is a mistake. > > People can also learn and change

[PATCH] Staging: speakup: Clear hi font bit from attributes

Previously, speakup would see the hi-font bit in attributes. Since this bit has nothing to do with attributes, we need to clear it. Signed-off-by: Samuel Thibault --- a/drivers/staging/speakup/main.c +++ b/drivers/staging/speakup/main.c @@ -267,7 +267,7 @@ static

[PATCH] regulator: Don't print error in devm_regulator_bulk_get() on -EPROBE_DEFER

The regulators may not be available just because their driver's probe was not executed and the regulators were not registered yet. So don't print an error in this case to avoid polluting the kernel log and confuse the users. Signed-off-by: Javier Martinez Canillas ---

[PATCH] Staging: speakup: Clear hi font bit from attributes

Previously, speakup would see the hi-font bit in attributes. Since this bit has nothing to do with attributes, we need to clear it. Signed-off-by: Samuel Thibault --- a/drivers/staging/speakup/main.c +++ b/drivers/staging/speakup/main.c @@ -267,7 +267,7 @@ static struct notifier_block

[PATCH] regulator: Don't print error in devm_regulator_bulk_get() on -EPROBE_DEFER

The regulators may not be available just because their driver's probe was not executed and the regulators were not registered yet. So don't print an error in this case to avoid polluting the kernel log and confuse the users. Signed-off-by: Javier Martinez Canillas ---

Re: [PATCH v6 5/8] kbuild: add fine grained build dependencies for exported symbols

Dne 15.3.2016 v 21:33 Michal Marek napsal(a): > Dne 14.3.2016 v 03:42 Nicolas Pitre napsal(a): >> +# Filter out exported kernel symbol names from the preprocessor output. >> +# See also __KSYM_DEPS__ in include/linux/export.h. >> +# We disable the depfile generation here, so as not to overwrite

Re: [PATCH v6 5/8] kbuild: add fine grained build dependencies for exported symbols

Dne 15.3.2016 v 21:33 Michal Marek napsal(a): > Dne 14.3.2016 v 03:42 Nicolas Pitre napsal(a): >> +# Filter out exported kernel symbol names from the preprocessor output. >> +# See also __KSYM_DEPS__ in include/linux/export.h. >> +# We disable the depfile generation here, so as not to overwrite

Re: [PATCH v6 5/8] kbuild: add fine grained build dependencies for exported symbols

Dne 14.3.2016 v 03:42 Nicolas Pitre napsal(a): > +# Filter out exported kernel symbol names from the preprocessor output. > +# See also __KSYM_DEPS__ in include/linux/export.h. > +# We disable the depfile generation here, so as not to overwrite the existing > +# depfile while fixdep is parsing it

Re: [PATCH v6 5/8] kbuild: add fine grained build dependencies for exported symbols

Dne 14.3.2016 v 03:42 Nicolas Pitre napsal(a): > +# Filter out exported kernel symbol names from the preprocessor output. > +# See also __KSYM_DEPS__ in include/linux/export.h. > +# We disable the depfile generation here, so as not to overwrite the existing > +# depfile while fixdep is parsing it

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

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 had not yet been mentioned -- for example, the 6.0 mechanisms added to

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

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 had not yet been mentioned -- for example, the 6.0 mechanisms added to

Re: [PATCH 7/8] cpufreq: Frequency invariant scheduler load-tracking support

Quoting Dietmar Eggemann (2016-03-15 12:13:46) > Hi Mike, > > On 14/03/16 05:22, Michael Turquette wrote: > > From: Dietmar Eggemann > > > > Implements cpufreq_scale_freq_capacity() to provide the scheduler with a > > frequency scaling correction factor for more

Re: [PATCH 7/8] cpufreq: Frequency invariant scheduler load-tracking support

Quoting Dietmar Eggemann (2016-03-15 12:13:46) > Hi Mike, > > On 14/03/16 05:22, Michael Turquette wrote: > > From: Dietmar Eggemann > > > > Implements cpufreq_scale_freq_capacity() to provide the scheduler with a > > frequency scaling correction factor for more accurate load-tracking. > > > >

[PATCH] kvm-pr: manage illegal instructions

While writing some instruction tests for kvm-unit-tests for powerpc, I've found that illegal instructions are not managed correctly with kvm-pr, while it is fine with kvm-hv. When an illegal instruction (like ".long 0") is processed by kvm-pr, the kernel logs are filled with: Couldn't

[PATCH] kvm-pr: manage illegal instructions

While writing some instruction tests for kvm-unit-tests for powerpc, I've found that illegal instructions are not managed correctly with kvm-pr, while it is fine with kvm-hv. When an illegal instruction (like ".long 0") is processed by kvm-pr, the kernel logs are filled with: Couldn't

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Mon, Mar 14, 2016 at 10:46:03AM -0400, Theodore Ts'o wrote: > On Mon, Mar 14, 2016 at 06:34:00AM -0400, Ric Wheeler wrote: > > I think that once we enter this mode, the local file system has effectively > > ceded its role to prevent stale data exposure to the upper layer. In effect, > > this

Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Mon, Mar 14, 2016 at 10:46:03AM -0400, Theodore Ts'o wrote: > On Mon, Mar 14, 2016 at 06:34:00AM -0400, Ric Wheeler wrote: > > I think that once we enter this mode, the local file system has effectively > > ceded its role to prevent stale data exposure to the upper layer. In effect, > > this

Re: [PATCH v5 1/4] i2c: add a protocol parameter to the alert callback

On Mar 15 2016 or thereabouts, Guenter Roeck wrote: > On Tue, Mar 15, 2016 at 03:53:41PM +0100, Benjamin Tissoires wrote: > > .alert() is meant to be generic, but there is currently no way > > for the device driver to know which protocol generated the alert. > > Add a parameter in .alert() to help

Re: [PATCH v5 1/4] i2c: add a protocol parameter to the alert callback

On Mar 15 2016 or thereabouts, Guenter Roeck wrote: > On Tue, Mar 15, 2016 at 03:53:41PM +0100, Benjamin Tissoires wrote: > > .alert() is meant to be generic, but there is currently no way > > for the device driver to know which protocol generated the alert. > > Add a parameter in .alert() to help

Re: [PATCH 1/5] ftrace perf: Check sample types only for sampling events

On Wed, 9 Mar 2016 21:46:41 +0100 Jiri Olsa wrote: > Currently we check sample type for ftrace:function event > even if it's not created as sampling event. That prevents > creating ftrace_function event in counting mode. > > Making sure we check sample types only for sampling

Re: [PATCH 1/5] ftrace perf: Check sample types only for sampling events

On Wed, 9 Mar 2016 21:46:41 +0100 Jiri Olsa wrote: > Currently we check sample type for ftrace:function event > even if it's not created as sampling event. That prevents > creating ftrace_function event in counting mode. > > Making sure we check sample types only for sampling events. > >

[PATCH v2] devpts: Make ptmx be owned by the userns owner as a fallback

New devpts instances have ptmx owned by the inner uid and gid 0. For container-style namespaces (LXC, etc), this should have no effect, this is fine. For sandbox-style namespaces (xdg-app and similar), this is problematic -- there may not be an inner 0:0. If that happens, devpts mounts will

[PATCH v2] devpts: Make ptmx be owned by the userns owner as a fallback

New devpts instances have ptmx owned by the inner uid and gid 0. For container-style namespaces (LXC, etc), this should have no effect, this is fine. For sandbox-style namespaces (xdg-app and similar), this is problematic -- there may not be an inner 0:0. If that happens, devpts mounts will

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

On Tue, Mar 15, 2016 at 02:21:53PM +0800, Wei Ni wrote: > > > On 2016年03月15日 04:05, Eduardo Valentin wrote: > > * PGP Signed by an unknown key > > > > On Fri, Mar 11, 2016 at 11:09:14AM +0800, Wei Ni wrote: > >> Get rid of T124-specific PDIV/HOTSPOT hack. > >> tegra-soctherm.c contained a hack

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

On Tue, Mar 15, 2016 at 02:21:53PM +0800, Wei Ni wrote: > > > On 2016年03月15日 04:05, Eduardo Valentin wrote: > > * PGP Signed by an unknown key > > > > On Fri, Mar 11, 2016 at 11:09:14AM +0800, Wei Ni wrote: > >> Get rid of T124-specific PDIV/HOTSPOT hack. > >> tegra-soctherm.c contained a hack

Re: [RFC qemu 0/4] A PV solution for live migration optimization

* Li, Liang Z (liang.z...@intel.com) wrote: > > On Mon, Mar 14, 2016 at 05:03:34PM +, Dr. David Alan Gilbert wrote: > > > * Li, Liang Z (liang.z...@intel.com) wrote: > > > > > > > > > > Hi, > > > > > I'm just catching back up on this thread; so without reference > > > > > to any particular

Re: [RFC qemu 0/4] A PV solution for live migration optimization

* Li, Liang Z (liang.z...@intel.com) wrote: > > On Mon, Mar 14, 2016 at 05:03:34PM +, Dr. David Alan Gilbert wrote: > > > * Li, Liang Z (liang.z...@intel.com) wrote: > > > > > > > > > > Hi, > > > > > I'm just catching back up on this thread; so without reference > > > > > to any particular

Re: [PATCH V7 05/12] thermal: tegra: add Tegra210 specific SOC_THERM driver

On Tue, Mar 15, 2016 at 02:59:52PM +0800, Wei Ni wrote: > > > On 2016年03月15日 02:57, Eduardo Valentin wrote: > > * PGP Signed by an unknown key > > > > On Fri, Mar 11, 2016 at 11:10:25AM +0800, Wei Ni wrote: > >> Add Tegra210 specific SOC_THERM driver. > >> > >> Signed-off-by: Wei Ni

Re: [PATCH V7 05/12] thermal: tegra: add Tegra210 specific SOC_THERM driver

On Tue, Mar 15, 2016 at 02:59:52PM +0800, Wei Ni wrote: > > > On 2016年03月15日 02:57, Eduardo Valentin wrote: > > * PGP Signed by an unknown key > > > > On Fri, Mar 11, 2016 at 11:10:25AM +0800, Wei Ni wrote: > >> Add Tegra210 specific SOC_THERM driver. > >> > >> Signed-off-by: Wei Ni > >> --- >

[PATCH] Staging: wlan-ng: moved memset() calls after copy_from_user() call

This patch moves memset() calls from p80211netdev_ethtool() after copy_from_user() call in order to avoid unnecessary instruction in case copy_from_user() fails. Signed-off-by: Claudiu Beznea --- drivers/staging/wlan-ng/p80211netdev.c | 6 +++--- 1 file changed, 3

[PATCH] Staging: wlan-ng: moved memset() calls after copy_from_user() call

This patch moves memset() calls from p80211netdev_ethtool() after copy_from_user() call in order to avoid unnecessary instruction in case copy_from_user() fails. Signed-off-by: Claudiu Beznea --- drivers/staging/wlan-ng/p80211netdev.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

Re: [PATCH V7 08/12] of: add notes of critical trips for soctherm

On Tue, Mar 15, 2016 at 04:14:15PM +0800, Wei Ni wrote: > > > On 2016年03月15日 15:49, Wei Ni wrote: > > > > > > On 2016年03月15日 05:00, Eduardo Valentin wrote: > >> * PGP Signed by an unknown key > >> > >> On Fri, Mar 11, 2016 at 11:11:00AM +0800, Wei Ni wrote: > >>> The "critical" type trip in

Re: [PATCH V7 08/12] of: add notes of critical trips for soctherm

On Tue, Mar 15, 2016 at 04:14:15PM +0800, Wei Ni wrote: > > > On 2016年03月15日 15:49, Wei Ni wrote: > > > > > > On 2016年03月15日 05:00, Eduardo Valentin wrote: > >> * PGP Signed by an unknown key > >> > >> On Fri, Mar 11, 2016 at 11:11:00AM +0800, Wei Ni wrote: > >>> The "critical" type trip in

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

On Tue, Mar 15, 2016 at 05:12:12PM +0800, Wei Ni wrote: > > > On 2016年03月15日 03:16, Eduardo Valentin wrote: > > * PGP Signed by an unknown key > > > > On Fri, Mar 11, 2016 at 11:11:12AM +0800, Wei Ni wrote: > >> Add support for hardware critical thermal limits to the > >> SOC_THERM driver. It

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

On Tue, Mar 15, 2016 at 05:12:12PM +0800, Wei Ni wrote: > > > On 2016年03月15日 03:16, Eduardo Valentin wrote: > > * PGP Signed by an unknown key > > > > On Fri, Mar 11, 2016 at 11:11:12AM +0800, Wei Ni wrote: > >> Add support for hardware critical thermal limits to the > >> SOC_THERM driver. It

Re: [REGRESSION] Headphones no longer working on MacPro6,1 with 4.4

On Tue, 15 Mar 2016 20:38:41 +0100, Takashi Iwai wrote: > > On Tue, 15 Mar 2016 20:23:09 +0100, > Laura Abbott wrote: > > > > Hi, > > > > We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 > > that the headphone jack on a MacPro6,1 stopped working on an upgrade from >

Re: [REGRESSION] Headphones no longer working on MacPro6,1 with 4.4

On Tue, 15 Mar 2016 20:38:41 +0100, Takashi Iwai wrote: > > On Tue, 15 Mar 2016 20:23:09 +0100, > Laura Abbott wrote: > > > > Hi, > > > > We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 > > that the headphone jack on a MacPro6,1 stopped working on an upgrade from >

Re: [PATCH] iommu/vt-d: Ratelimit fault handler

On Tue, 2016-03-15 at 10:35 -0600, Alex Williamson wrote: > Fault rates can easily overwhelm the console and make the system > unresponsive.  Ratelimit to allow an opportunity for maintenance. > > Signed-off-by: Alex Williamson Rather than just rate-limiting the

Re: [PATCH] iommu/vt-d: Ratelimit fault handler

On Tue, 2016-03-15 at 10:35 -0600, Alex Williamson wrote: > Fault rates can easily overwhelm the console and make the system > unresponsive.  Ratelimit to allow an opportunity for maintenance. > > Signed-off-by: Alex Williamson Rather than just rate-limiting the printk, I'd prefer to handle

Re: [PATCH 1/2] Staging: wlan-ng: removed prototype of p80211_stt_findproto() from this file.

Hi Claudiu, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.5 next-20160315] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Claudiu-Beznea/Staging-wlan-ng

Re: [PATCH 1/2] Staging: wlan-ng: removed prototype of p80211_stt_findproto() from this file.

Hi Claudiu, [auto build test ERROR on staging/staging-testing] [also build test ERROR on v4.5 next-20160315] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Claudiu-Beznea/Staging-wlan-ng

Re: [PATCH V7 11/12] arm64: tegra: add soctherm node for Tegra210

On Tue, Mar 15, 2016 at 06:43:00PM +0800, Wei Ni wrote: > > > On 2016年03月15日 03:25, Eduardo Valentin wrote: > > * PGP Signed by an unknown key > > > > On Fri, Mar 11, 2016 at 11:11:34AM +0800, Wei Ni wrote: > >> Adds soctherm node for Tegra210, and add cpu, > >> gpu, mem, pllx as thermal-zones.

Re: [PATCH V7 11/12] arm64: tegra: add soctherm node for Tegra210

On Tue, Mar 15, 2016 at 06:43:00PM +0800, Wei Ni wrote: > > > On 2016年03月15日 03:25, Eduardo Valentin wrote: > > * PGP Signed by an unknown key > > > > On Fri, Mar 11, 2016 at 11:11:34AM +0800, Wei Ni wrote: > >> Adds soctherm node for Tegra210, and add cpu, > >> gpu, mem, pllx as thermal-zones.

Re: [PATCH 4/5] ftrace: Make ftrace_hash_rec_enable return update bool

On Sat, 12 Mar 2016 17:35:02 +0900 Namhyung Kim wrote: > Hi Jiri, > > On Fri, Mar 11, 2016 at 07:15:06PM +0100, Jiri Olsa wrote: > > On Fri, Mar 11, 2016 at 11:28:00PM +0900, Namhyung Kim wrote: > > > > SNIP > > > > > > @@ -1694,7 +1695,7 @@ static void

[PATCH v7 0/3] fallocate for block devices to provide zero-out

Hi, This is a redesign of the patch series that fixes various interface problems with the existing "zero out this part of a block device" code. BLKZEROOUT2 is gone. The first patch is still a fix to the existing BLKZEROOUT ioctl to invalidate the page cache if the zeroing command to the

Re: [PATCH 4/5] ftrace: Make ftrace_hash_rec_enable return update bool

On Sat, 12 Mar 2016 17:35:02 +0900 Namhyung Kim wrote: > Hi Jiri, > > On Fri, Mar 11, 2016 at 07:15:06PM +0100, Jiri Olsa wrote: > > On Fri, Mar 11, 2016 at 11:28:00PM +0900, Namhyung Kim wrote: > > > > SNIP > > > > > > @@ -1694,7 +1695,7 @@ static void __ftrace_hash_rec_update(struct > >

[PATCH v7 0/3] fallocate for block devices to provide zero-out

Hi, This is a redesign of the patch series that fixes various interface problems with the existing "zero out this part of a block device" code. BLKZEROOUT2 is gone. The first patch is still a fix to the existing BLKZEROOUT ioctl to invalidate the page cache if the zeroing command to the

[PATCH 3/3] block: implement (some of) fallocate for block devices

After much discussion, it seems that the fallocate feature flag FALLOC_FL_ZERO_RANGE maps nicely to SCSI WRITE SAME; and the feature FALLOC_FL_PUNCH_HOLE maps nicely to the devices that have been whitelisted for zeroing SCSI UNMAP. Punch still requires that FALLOC_FL_KEEP_SIZE is set. A length

[PATCH 3/3] block: implement (some of) fallocate for block devices

After much discussion, it seems that the fallocate feature flag FALLOC_FL_ZERO_RANGE maps nicely to SCSI WRITE SAME; and the feature FALLOC_FL_PUNCH_HOLE maps nicely to the devices that have been whitelisted for zeroing SCSI UNMAP. Punch still requires that FALLOC_FL_KEEP_SIZE is set. A length

[PATCH 2/3] block: require write_same and discard requests align to logical block size

Make sure that the offset and length arguments that we're using to construct WRITE SAME and DISCARD requests are actually aligned to the logical block size. Failure to do this causes other errors in other parts of the block layer or the SCSI layer because disks don't support partial logical block

[PATCH 1/3] block: invalidate the page cache when issuing BLKZEROOUT.

Invalidate the page cache (as a regular O_DIRECT write would do) to avoid returning stale cache contents at a later time. v5: Refactor the 4.4 refactoring of the ioctl code into separate functions. Split the page invalidation and the new ioctl into separate patches. Signed-off-by: Darrick J.

[PATCH 2/3] block: require write_same and discard requests align to logical block size

Make sure that the offset and length arguments that we're using to construct WRITE SAME and DISCARD requests are actually aligned to the logical block size. Failure to do this causes other errors in other parts of the block layer or the SCSI layer because disks don't support partial logical block

[PATCH 1/3] block: invalidate the page cache when issuing BLKZEROOUT.

Invalidate the page cache (as a regular O_DIRECT write would do) to avoid returning stale cache contents at a later time. v5: Refactor the 4.4 refactoring of the ioctl code into separate functions. Split the page invalidation and the new ioctl into separate patches. Signed-off-by: Darrick J.

Re: [GIT PULL] RCU changes for v4.6

On Tue, Mar 15, 2016 at 12:10:03PM -0700, Linus Torvalds wrote: > On Tue, Mar 15, 2016 at 11:48 AM, Paul E. McKenney > wrote: > > > > On the quick quizzes, if you want me to get rid of them, they are gone. > > You don't have to remove them (but I do think cartoons etc

Re: [GIT PULL] RCU changes for v4.6

On Tue, Mar 15, 2016 at 12:10:03PM -0700, Linus Torvalds wrote: > On Tue, Mar 15, 2016 at 11:48 AM, Paul E. McKenney > wrote: > > > > On the quick quizzes, if you want me to get rid of them, they are gone. > > You don't have to remove them (but I do think cartoons etc should be). > > But

Re: [REGRESSION] Headphones no longer working on MacPro6,1 with 4.4

On Tue, 15 Mar 2016 20:23:09 +0100, Laura Abbott wrote: > > Hi, > > We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 > that the headphone jack on a MacPro6,1 stopped working on an upgrade from 4.3 > to 4.4. > > The bugzilla has the alsainfo, diffing shows that the

Re: [REGRESSION] Headphones no longer working on MacPro6,1 with 4.4

On Tue, 15 Mar 2016 20:23:09 +0100, Laura Abbott wrote: > > Hi, > > We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 > that the headphone jack on a MacPro6,1 stopped working on an upgrade from 4.3 > to 4.4. > > The bugzilla has the alsainfo, diffing shows that the

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

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 region? >>>

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

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 region? >>> >>> Probably not.

[PATCH 1/2] Staging: wlan-ng: removed prototype of p80211_stt_findproto() from this file.

This patch removes the prototype of p80211_stt_findproto() from p80211conv.h since global scope is not necessary. Signed-off-by: Claudiu Beznea --- drivers/staging/wlan-ng/p80211conv.h | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH 1/2] Staging: wlan-ng: removed prototype of p80211_stt_findproto() from this file.

This patch removes the prototype of p80211_stt_findproto() from p80211conv.h since global scope is not necessary. Signed-off-by: Claudiu Beznea --- drivers/staging/wlan-ng/p80211conv.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/wlan-ng/p80211conv.h

[PATCH 2/2] Staging: wlan-ng: convert p80211_stt_findproto() to static inline functions

This patch convert p80211_stt_findproto() to "static inline" since it is used only in p80211conv.c file and also has few instructins. After the scope was changed to static the function definition was moved at the beginning of the file to avoid undefined references. Signed-off-by: Claudiu Beznea

[PATCH 2/2] Staging: wlan-ng: convert p80211_stt_findproto() to static inline functions

This patch convert p80211_stt_findproto() to "static inline" since it is used only in p80211conv.c file and also has few instructins. After the scope was changed to static the function definition was moved at the beginning of the file to avoid undefined references. Signed-off-by: Claudiu Beznea

[REGRESSION] Headphones no longer working on MacPro6,1 with 4.4

Hi, We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 that the headphone jack on a MacPro6,1 stopped working on an upgrade from 4.3 to 4.4. The bugzilla has the alsainfo, diffing shows that the Amp-Out vals are different. I tried a revert of 9f660a1c4 (" ALSA:

[REGRESSION] Headphones no longer working on MacPro6,1 with 4.4

Hi, We received a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1316119 that the headphone jack on a MacPro6,1 stopped working on an upgrade from 4.3 to 4.4. The bugzilla has the alsainfo, diffing shows that the Amp-Out vals are different. I tried a revert of 9f660a1c4 (" ALSA:

Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity

On 14/03/16 05:22, Michael Turquette wrote: > arch_scale_freq_capacity is weird. It specifies an arch hook for an > implementation that could easily vary within an architecture or even a > chip family. > > This patch helps to mitigate this weirdness by defaulting to the > cpufreq-provided

Re: [PATCH 7/8] cpufreq: Frequency invariant scheduler load-tracking support

Hi Mike, On 14/03/16 05:22, Michael Turquette wrote: > From: Dietmar Eggemann > > Implements cpufreq_scale_freq_capacity() to provide the scheduler with a > frequency scaling correction factor for more accurate load-tracking. > > The factor is: > >

Re: [PATCH 7/8] cpufreq: Frequency invariant scheduler load-tracking support

Hi Mike, On 14/03/16 05:22, Michael Turquette wrote: > From: Dietmar Eggemann > > Implements cpufreq_scale_freq_capacity() to provide the scheduler with a > frequency scaling correction factor for more accurate load-tracking. > > The factor is: > > current_freq(cpu) <<

Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity

On 14/03/16 05:22, Michael Turquette wrote: > arch_scale_freq_capacity is weird. It specifies an arch hook for an > implementation that could easily vary within an architecture or even a > chip family. > > This patch helps to mitigate this weirdness by defaulting to the > cpufreq-provided

Re: [GIT PULL] RCU changes for v4.6

On Tue, Mar 15, 2016 at 11:48 AM, Paul E. McKenney wrote: > > On the quick quizzes, if you want me to get rid of them, they are gone. You don't have to remove them (but I do think cartoons etc should be). But dammit, you don't need to duplicate a big file or use a

Re: [GIT PULL] RCU changes for v4.6

On Tue, Mar 15, 2016 at 11:48 AM, Paul E. McKenney wrote: > > On the quick quizzes, if you want me to get rid of them, they are gone. You don't have to remove them (but I do think cartoons etc should be). But dammit, you don't need to duplicate a big file or use a non-standard format for

<    2   3   4   5   6   7   8   9   10   11   >