Re: [PATCH v8 12/14] power: bq24257: Add various device-specific sysfs properties

W dniu 29.09.2015 o 07:34, Andreas Dannenberg pisze: > This patch adds support for enabling/disabling optional device specific > features through sysfs properties at runtime. > > * High-impedance mode enable/disable > * Sysoff enable/disable > > Refer to the respective device datasheets for more

Re: [PATCH 1/2] selftests/pstore: add pstore test script for pre-reboot

Hello, I'm sorry for my late reply. Mark Salyzyn wrote: Perfectly match is an issue, since something else might be using pmsg. For instance, one of the applications that uses this interface packetizes the messages so they can be picked out from other sources that do not comply with the header

Re: [PATCH v7 08/15] power: bq24257: Allow manual setting of input current limit

W dniu 26.09.2015 o 00:54, Andreas Dannenberg pisze: > A new optional device property called "ti,current-limit" is introduced > to allow disabling the D+/D- USB signal-based charger type auto- > detection algorithm used to set the input current limit and instead to > use a fixed input current

Re: [PATCH v8 09/14] power: bq24257: Add over voltage protection setting support

W dniu 29.09.2015 o 07:33, Andreas Dannenberg pisze: > A new optional device property called "ti,ovp-voltage" is introduced to > allow configuring the input over voltage protection setting. > > This commit also adds the basic sysfs support for custom properties > which is being used to allow

Re: [PATCH v8 11/14] power: bq24257: Allow input current limit sysfs access

W dniu 29.09.2015 o 07:33, Andreas Dannenberg pisze: > This patch allows reading and writing of the input current limit through > the power supply's input_current_limit sysfs property. This allows > userspace to see what charger was detected (if the D+/D- USB signal- > based charger type detection

Re: [PATCH v8 10/14] power: bq24257: Add input DPM voltage threshold setting support

W dniu 29.09.2015 o 07:33, Andreas Dannenberg pisze: > A new optional device property called "ti,in-dpm-voltage" is introduced > to allow configuring the input voltage threshold for the devices' > dynamic power path management (DPM) feature. In short, it can be used to > prevent the input voltage

Re: [PATCH 21/25] mm: implement new mprotect_key() system call

On Mon, 2015-09-28 at 12:18 -0700, Dave Hansen wrote: > From: Dave Hansen > > mprotect_key() is just like mprotect, except it also takes a > protection key as an argument. On systems that do not support > protection keys, it still works, but requires that key=0.

[PATCH v9 0/3] Enable PPI sysfs interface for TPM 2.0

v9: * Fixed naming for __compat_only_sysfs_link_entry_to_kobj() v8: * Renamed sysfs_link_entry_to_kobj() to __compat_only_sysfs_link_entry_to_kobj() v7: * Fixed compile error when CONFIG_SYSFS is not enabled. v6: * Updated documentation. v5: * Removed dangling export of

[PATCH v9 3/3] tpm: update PPI documentation to address the location change.

Updated Documentation/ABI/testing/sysfs-driver-ppi in order to explain where PPI attributes are located and how backwards compatiblity is addressed. Signed-off-by: Jarkko Sakkinen --- Documentation/ABI/testing/sysfs-driver-ppi | 19 --- 1 file

Re: [PATCH v8 14/14] Documentation: power: bq24257: Document exported sysfs entries

W dniu 29.09.2015 o 07:34, Andreas Dannenberg pisze: > Document the settings exported by bq24257 charger driver through sysfs > entries: > - ovp_voltage > - in_dpm_voltage > - high_impedance_enable > - sysoff_enable > > Signed-off-by: Andreas Dannenberg > --- >

Re: [PATCH v8 07/14] power: bq24257: Allow manual setting of input current limit

W dniu 29.09.2015 o 07:33, Andreas Dannenberg pisze: > A new optional device property called "ti,current-limit" is introduced > to allow disabling the D+/D- USB signal-based charger type auto- > detection algorithm used to set the input current limit and instead to > use a fixed input current

Re: [PATCH v8 08/14] power: bq24257: Add SW-based approach for Power Good determination

W dniu 29.09.2015 o 07:33, Andreas Dannenberg pisze: > A software-based approach for determining the charger's input voltage > "Power Good" state is introduced for devices like the bq24250 which > don't have a dedicated hardware pin for that purpose. This SW-based > approach is also used for other

[PATCH] kselftest: replace rm -f command with $(RM)

Some test's Makefile using "$(RM)" while the other's using "rm -f". It is better to use one of them in all tests. "$(RM)" is clearly defined as a Makefile implicit variable which defaults to "rm -f". Ref. https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html Signed-off-by:

[RFC 4/6] drm/i915: Add i915 perf event for Haswell OA unit

Gen graphics hardware can be set up to periodically write snapshots of performance counters into a circular buffer via its Observation Architecture and this patch exposes that capability to userspace via the i915 perf interface. Cc: Chris Wilson Signed-off-by: Robert

[RFC 5/6] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

Consistent with the kernel.perf_event_paranoid sysctl option that can allow non-root users to access system wide cpu metrics, this can optionally allow non-root users to access system wide OA counter metrics from Gen graphics hardware. Signed-off-by: Robert Bragg ---

[RFC 6/6] drm/i915: add oa_event_min_timer_exponent sysctl

The minimal sampling period is now configurable via a dev.i915.oa_event_min_timer_exponent sysctl parameter. Following the precedent set by perf, the default is the minimum that won't (on its own) exceed the default kernel.perf_event_max_sample_rate default of 10 samples/s. Signed-off-by:

Re: [PATCH v8 00/41] Richacls

2015-09-28 19:46 GMT+02:00 J. Bruce Fields : > On Mon, Sep 28, 2015 at 07:10:06PM +0200, Andreas Grünbacher wrote: >> 2015-09-28 18:35 GMT+02:00 J. Bruce Fields : >> > On Mon, Sep 28, 2015 at 12:08:51AM +0200, Andreas Gruenbacher wrote: >> >> Open issues

Re: [PATCH 21/25] mm: implement new mprotect_key() system call

On 09/28/2015 11:39 PM, Michael Ellerman wrote: > On Mon, 2015-09-28 at 12:18 -0700, Dave Hansen wrote: >> From: Dave Hansen >> >> mprotect_key() is just like mprotect, except it also takes a >> protection key as an argument. On systems that do not support >>

Re: [Intel-gfx] [RFC 4/6] drm/i915: Add i915 perf event for Haswell OA unit

Hi Robert, [auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore] config: i386-defconfig (attached as .config) reproduce: git checkout a1d59679ae8f3e7e7659e9723ae3fc69af2532e6 # save the attached .config to linux build tree make ARCH=i386 All warnings (new

[RFC 3/6] drm/i915: Add static '3D' Haswell OA unit config

Adds a static OA unit, MUX + B Counter configuration for basic '3D' metrics on Haswell. This is autogenerated from an internal XML description of metric sets. Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/i915_drv.h|

[RFC 1/6] drm/i915: Add i915 perf infrastructure

This adds a DRM_IOCTL_I915_PERF_OPEN ioctl comparable to perf_event_open that opens a file descriptor for an event source. Based on our initial experience aiming to use the core perf infrastructure, this interface is inspired by perf, but focused on exposing metrics about work running on Gen

[RFC 0/6] Non perf based Gen Graphics OA unit driver

After some recent progress enabling the Observation Architecture unit for Gen8+, we can hopefully paint a fairly complete picture of the requirements for supporting the unit from Haswell to Skylake and so I'm looking again at the challenges in upstreaming this work. Considering this, it looked

[RFC 2/6] drm/i915: rename OACONTROL GEN7_OACONTROL

OACONTROL changes quite a bit for gen8, with some bits split out into a per-context OACTXCONTROL register Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- drivers/gpu/drm/i915/i915_reg.h| 2 +- 2 files changed, 3 insertions(+), 3

Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()

On 09/28, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > > Honestly, I do not really like the new helper... I understand this > > is subjective, so I won't insist. But how about 1/1? We do not need > > fd/file at all. With this patch your sys_getvpid() can just use > >

Re: [kbuild-all] [Intel-gfx] [RFC 4/6] drm/i915: Add i915 perf event for Haswell OA unit

On Tue, Sep 29, 2015 at 05:18:45PM +0200, Peter Zijlstra wrote: > On Tue, Sep 29, 2015 at 10:55:39PM +0800, kbuild test robot wrote: > > Hi Robert, > > > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, please > > ignore] > > > > config: i386-defconfig (attached as .config)

Re: [PATCH v3 2/2] PCI: Add support for Enhanced Allocation devices

More responses inline. Thanks again, Sean On Tue, Sep 29, 2015 at 01:25:59PM -0700, David Daney wrote: > Thanks for reviewing the new code. Expect a revised patch soon. Great! Let me know if I can help :) > > Other responses below... > > > On 09/29/2015 12:27 PM, Sean O. Stalley wrote: >

RE: [PATCH v4 3/9] btrfs: add .copy_file_range file operation

Hi, Anna Schumaker > -Original Message- > From: linux-btrfs-ow...@vger.kernel.org > [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Anna Schumaker > Sent: Wednesday, September 30, 2015 2:05 AM > To: linux-...@vger.kernel.org; linux-bt...@vger.kernel.org; >

Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()

On 09/29/2015 12:37 AM, Eric W. Biederman wrote: Oleg Nesterov writes: On 09/25, Konstantin Khlebnikov wrote: +struct ns_common *proc_ns_fdget(int fd, int nstype, struct fd *fd_ref) { - struct file *file; + struct ns_common *ns; + struct fd f; - file

Re: [PATCH v3 2/2] PCI: Add support for Enhanced Allocation devices

On 09/29/2015 03:47 PM, Sean O. Stalley wrote: [...] diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 6a9a111..7c60b16 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2148,6 +2148,284 @@ void pci_pm_init(struct pci_dev *dev) } } +static unsigned long

Re: [RFC 0/6] Non perf based Gen Graphics OA unit driver

On 2015.09.29 15:39:03 +0100, Robert Bragg wrote: > > - Logistically it might be more practical to contain this to the > graphics stack. > > It seems fair to consider that if we can't see a very compelling > benefit to building on perf, then containing this work to >

Re: [RFC v2 00/18] kthread: Use kthread worker API more widely

On Mon, Sep 21, 2015 at 03:03:41PM +0200, Petr Mladek wrote: > My intention is to make it easier to manipulate kthreads. This RFC tries > to use the kthread worker API. It is based on comments from the > first attempt. See https://lkml.org/lkml/2015/7/28/648 and > the list of changes below. > >

Re: [PATCH v7 03/11] task_isolation: support PR_TASK_ISOLATION_STRICT mode

On 09/28/2015 06:38 PM, Andy Lutomirski wrote: On Mon, Sep 28, 2015 at 2:54 PM, Chris Metcalf wrote: On 09/28/2015 04:51 PM, Andy Lutomirski wrote: On Mon, Sep 28, 2015 at 11:17 AM, Chris Metcalf @@ -35,8 +36,12 @@ static inline enum ctx_state

[PATCH v4 6/9] vfs: Copy should use file_out rather than file_in

The way to think about this is that the destination filesystem reads the data from the source file and processes it accordingly. This is especially important to avoid an infinate loop when doing a "server to server" copy on NFS. Signed-off-by: Anna Schumaker ---

[PATCH v4 0/9] VFS: In-kernel copy system call

Copy system calls came up during Plumbers a while ago, mostly because several filesystems (including NFS and XFS) are currently working on copy acceleration implementations. We haven't heard from Zach Brown in a while, so I volunteered to push his patches upstream so individual filesystems don't

[PATCH v4 1/9] vfs: add copy_file_range syscall and vfs helper

From: Zach Brown Add a copy_file_range() system call for offloading copies between regular files. This gives an interface to underlying layers of the storage stack which can copy without reading and writing all the data. There are a few candidates that should support copy

[PATCH v4 3/9] btrfs: add .copy_file_range file operation

From: Zach Brown This rearranges the existing COPY_RANGE ioctl implementation so that the .copy_file_range file operation can call the core loop that copies file data extent items. The extent copying loop is lifted up into its own function. It retains the core btrfs error

Re: [PATCH v2] capabilities.7, prctl.2: Document ambient capabilities

On Tue, Sep 29, 2015 at 10:47 AM, Kees Cook wrote: > On Mon, Sep 28, 2015 at 6:03 PM, Andy Lutomirski wrote: >> Signed-off-by: Andy Lutomirski >> --- >> man2/prctl.2| 12 >> man7/capabilities.7 | 40

Re: [PATCH v7 03/11] task_isolation: support PR_TASK_ISOLATION_STRICT mode

On Tue, Sep 29, 2015 at 10:57 AM, Chris Metcalf wrote: > On 09/29/2015 01:46 PM, Andy Lutomirski wrote: >> >> On Tue, Sep 29, 2015 at 10:35 AM, Chris Metcalf >> wrote: >>> >>> Well, the most interesting category is things that don't actually >>> trigger

Re: [PATCH v2] capabilities.7, prctl.2: Document ambient capabilities

On Tue, Sep 29, 2015 at 10:49 AM, Andy Lutomirski wrote: > On Tue, Sep 29, 2015 at 10:47 AM, Kees Cook wrote: >> On Mon, Sep 28, 2015 at 6:03 PM, Andy Lutomirski wrote: >>> Signed-off-by: Andy Lutomirski >>> --- >>>

Re: [PATCH v7 03/11] task_isolation: support PR_TASK_ISOLATION_STRICT mode

On 09/29/2015 01:46 PM, Andy Lutomirski wrote: On Tue, Sep 29, 2015 at 10:35 AM, Chris Metcalf wrote: Well, the most interesting category is things that don't actually trigger a signal (e.g. minor page fault) since those are things that cause significant issues with task

Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()

Oleg Nesterov writes: > On 09/28, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> > Honestly, I do not really like the new helper... I understand this >> > is subjective, so I won't insist. But how about 1/1? We do not need >> > fd/file at all. With

Re: [PATCH] kselftest: replace $(RM) with rm -f command

On Tue, Sep 29, 2015 at 2:57 AM, Michael Ellerman wrote: > On Mon, 2015-09-28 at 03:16 +, Mathieu Desnoyers wrote: >> - On Sep 27, 2015, at 10:10 PM, Wang Long long.wangl...@huawei.com wrote: >> >> > Some test's Makefile using "$(RM)" while the other's >> > using "rm

Re: [PATCH v7 03/11] task_isolation: support PR_TASK_ISOLATION_STRICT mode

On Tue, Sep 29, 2015 at 10:35 AM, Chris Metcalf wrote: > On 09/28/2015 06:38 PM, Andy Lutomirski wrote: >> >> On Mon, Sep 28, 2015 at 2:54 PM, Chris Metcalf >> wrote: >>> >>> On 09/28/2015 04:51 PM, Andy Lutomirski wrote: On Mon, Sep 28, 2015

Re: [PATCH v2] capabilities.7, prctl.2: Document ambient capabilities

On Mon, Sep 28, 2015 at 6:03 PM, Andy Lutomirski wrote: > Signed-off-by: Andy Lutomirski > --- > man2/prctl.2| 12 > man7/capabilities.7 | 40 ++-- > 2 files changed, 46 insertions(+), 6 deletions(-) > >

[PATCH v4 5/9] vfs: Copy shouldn't forbid ranges inside the same file

This is perfectly valid for BTRFS and XFS, so let's leave this up to filesystems to check. Signed-off-by: Anna Schumaker Reviewed-by: David Sterba Reviewed-by: Darrick J. Wong --- fs/read_write.c | 4 1 file changed, 4

[PATCH v4 8/9] vfs: Add vfs_copy_file_range() support for pagecache copies

This allows us to have an in-kernel copy mechanism that avoids frequent switches between kernel and user space. This is especially useful so NFSD can support server-side copies. I make pagecache copies configurable by adding three new (exclusive) flags: - COPY_FR_REFLINK tells

[PATCH v4 2/9] x86: add sys_copy_file_range to syscall tables

From: Zach Brown Add sys_copy_file_range to the x86 syscall tables. Signed-off-by: Zach Brown [Anna Schumaker: Update syscall number in syscall_32.tbl] Signed-off-by: Anna Schumaker --- arch/x86/entry/syscalls/syscall_32.tbl | 1 +

[PATCH v4 9/9] btrfs: btrfs_copy_file_range() only supports reflinks

Reject copies that don't have the COPY_FR_REFLINK flag set. Signed-off-by: Anna Schumaker Reviewed-by: David Sterba --- fs/btrfs/ioctl.c | 4 1 file changed, 4 insertions(+) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index

[PATCH v4 10/9] copy_file_range.2: New page documenting copy_file_range()

copy_file_range() is a new system call for copying ranges of data completely in the kernel. This gives filesystems an opportunity to implement some kind of "copy acceleration", such as reflinks or server-side-copy (in the case of NFS). Signed-off-by: Anna Schumaker

[PATCH v4 4/9] vfs: Copy should check len after file open mode

I don't think it makes sense to report that a copy succeeded if the files aren't open properly. Signed-off-by: Anna Schumaker Reviewed-by: David Sterba --- fs/read_write.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH v4 7/9] vfs: Remove copy_file_range mountpoint checks

I still want to do an in-kernel copy even if the files are on different mountpoints, and NFS has a "server to server" copy that expects two files on different mountpoints. Let's have individual filesystems implement this check instead. Signed-off-by: Anna Schumaker

Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()

On 09/29, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > > OK, I won't insist, this too looks better to me than proc_ns_fdget(_ref). > > > > And in any case fcheck_files() makes more sense than fdget(), somehow I did > > not think about this when I sent 1/1. > > > > Hmm.

Re: [PATCH 0/1] ns: introduce proc_get_ns_by_fd()

Oleg Nesterov writes: > On 09/29, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> > OK, I won't insist, this too looks better to me than >> > proc_ns_fdget(_ref). >> > >> > And in any case fcheck_files() makes more sense than fdget(), somehow I did

Re: [PATCH v3 2/2] PCI: Add support for Enhanced Allocation devices

Hi David, Thanks for working on this. I gave it a look and added my comments inline below. I have a few concerns, but overall I like it :) To clarify, you are only trying to add support for Bridges that have EA entries to describe the resource range of downstream devices? I ask because the spec

Re: [PATCH v3 2/2] PCI: Add support for Enhanced Allocation devices

Thanks for reviewing the new code. Expect a revised patch soon. Other responses below... On 09/29/2015 12:27 PM, Sean O. Stalley wrote: Hi David, Thanks for working on this. I gave it a look and added my comments inline below. I have a few concerns, but overall I like it :) To clarify, you