[PATCH 07/27] HID: wacom: switch inputs to devres

Simplifying the error code paths. We need to keep wacom_clean_inputs() around for now as the wireless module is using it to dynamically remove the inputs on disconnect. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 34

[PATCH 11/27] HID: wacom: use devres to allocate driver data

We started switching the driver to devres, so we should use it as much as possible. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c index ec088c1..56d62e8

[PATCH 04/27] HID: wacom: untie leds from inputs

Like remotes, LEDs should be handled by themself, not magically behind the inputs as they have a complete different life. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git

[PATCH 07/27] HID: wacom: switch inputs to devres

Simplifying the error code paths. We need to keep wacom_clean_inputs() around for now as the wireless module is using it to dynamically remove the inputs on disconnect. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 34 -- 1 file changed, 16

[PATCH 09/27] HID: wacom: convert LEDs to devres

Use our own wacom_devm_sysfs_create_group() as there is currently no generic one. It has been requested at least twice [1][2] but has been always rejected. However, in the Wacom case, for the wirelessly connected devices, we need to be able to release the created sysfs files without removing the

[PATCH 02/27] HID: wacom: store the type in wacom->shared for INTUOSHT and INTUOSHT2

The type is never set but we check for it in wacom_wireless_irq(). It looks like this is a big hack from the beginning, so fill in the gap only. Untested. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 5 +++-- 1 file changed, 3 insertions(+), 2

[PATCH 02/27] HID: wacom: store the type in wacom->shared for INTUOSHT and INTUOSHT2

The type is never set but we check for it in wacom_wireless_irq(). It looks like this is a big hack from the beginning, so fill in the gap only. Untested. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

[PATCH 09/27] HID: wacom: convert LEDs to devres

Use our own wacom_devm_sysfs_create_group() as there is currently no generic one. It has been requested at least twice [1][2] but has been always rejected. However, in the Wacom case, for the wirelessly connected devices, we need to be able to release the created sysfs files without removing the

[PATCH 01/27] HID: wacom: actually report the battery level for wireless connected

Since fd5f92b ("HID: wacom: reuse wacom_parse_and_register() in wireless_work"), wacom->shared->type is not set. Send the information of the battery if we have one. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_wac.c | 3 ++- 1 file changed, 2

[PATCH 01/27] HID: wacom: actually report the battery level for wireless connected

Since fd5f92b ("HID: wacom: reuse wacom_parse_and_register() in wireless_work"), wacom->shared->type is not set. Send the information of the battery if we have one. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_wac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH 14/27] HID: wacom: EKR: add a worker to add/remove resources on addition/removal

wacom_remote_status_irq() sends information of addition/removal of EKR. We want to allocate one input node per remote, so better having this in a separate worker, not handled in the IRQ directly. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom.h | 11

[PATCH 12/27] HID: wacom: devres manage the shared data too

wacom_release_shared_data() and wacom_remove_shared_data() are moved up so they can be referenced in wacom_add_shared_data(). There is no point in explicitly setting wacom_wac1->shared->type to 0 in wacom_wireless_work() (plus this would give an oops). Signed-off-by: Benjamin Tissoires

[PATCH 15/27] HID: wacom: EKR: have the wacom resources dynamically allocated

If we want to have one input device per remote, it's better to have our own struct wacom_remote which is dynamically allocated. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom.h | 13 +++-- drivers/hid/wacom_sys.c | 133

[PATCH 06/27] HID: wacom: switch battery to devres

Simplifying the error code paths. We need to keep wacom_destroy_battery() around for now as the wireless module and the remotes are using it to dynamically remove the battery supply on disconnect. Signed-off-by: Benjamin Tissoires # Conflicts: #

[PATCH 22/27] HID: wacom: EKR: attach the power_supply on first connection

Or Gnome complains about an empty battery. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 36 ++-- 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c

[PATCH 21/27] HID: wacom: EKR: have one power_supply per remote

Previously, all the remotes attached to the same receiver would share the same power_supply. That's not good as the remotes will constantly change the battery information according to their own state. To have something generic enough, we introduce struct wacom_battery which regroups all the

[PATCH 10/27] HID: wacom: use devm_kasprintf for allocating the name of the remote

The sysfs group was indeed removed by kobject_put(wacom->remote_dir) in wacom_remove(), but the name of the group was never freed. Also remove the misplaced kobject_put(wacom->remote_dir) in the error path of wacom_remote_create_attr_group(). Signed-off-by: Benjamin Tissoires

[PATCH 18/27] HID: wacom: EKR: use devres groups to manage resources

This will be useful when each remote will be assigned its own input device. We won't need to unregister each input and sysfs and other elements one at a time. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 44

[PATCH 13/27] HID: wacom: leds: dynamically allocate LED groups

We need to add an action to ensure wacom->led.groups is null when wacom_led_control() gets called after the resources has been freed. This also prevents to send a LED command when there is no support from the device. Signed-off-by: Benjamin Tissoires ---

[PATCH 14/27] HID: wacom: EKR: add a worker to add/remove resources on addition/removal

wacom_remote_status_irq() sends information of addition/removal of EKR. We want to allocate one input node per remote, so better having this in a separate worker, not handled in the IRQ directly. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom.h | 11 +-- drivers/hid/wacom_sys.c

[PATCH 12/27] HID: wacom: devres manage the shared data too

wacom_release_shared_data() and wacom_remove_shared_data() are moved up so they can be referenced in wacom_add_shared_data(). There is no point in explicitly setting wacom_wac1->shared->type to 0 in wacom_wireless_work() (plus this would give an oops). Signed-off-by: Benjamin Tissoires ---

[PATCH 15/27] HID: wacom: EKR: have the wacom resources dynamically allocated

If we want to have one input device per remote, it's better to have our own struct wacom_remote which is dynamically allocated. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom.h | 13 +++-- drivers/hid/wacom_sys.c | 133

[PATCH 06/27] HID: wacom: switch battery to devres

Simplifying the error code paths. We need to keep wacom_destroy_battery() around for now as the wireless module and the remotes are using it to dynamically remove the battery supply on disconnect. Signed-off-by: Benjamin Tissoires # Conflicts: # drivers/hid/wacom_sys.c ---

[PATCH 10/27] HID: wacom: use devm_kasprintf for allocating the name of the remote

The sysfs group was indeed removed by kobject_put(wacom->remote_dir) in wacom_remove(), but the name of the group was never freed. Also remove the misplaced kobject_put(wacom->remote_dir) in the error path of wacom_remote_create_attr_group(). Signed-off-by: Benjamin Tissoires ---

[PATCH 18/27] HID: wacom: EKR: use devres groups to manage resources

This will be useful when each remote will be assigned its own input device. We won't need to unregister each input and sysfs and other elements one at a time. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 44 1 file changed, 28

[PATCH 13/27] HID: wacom: leds: dynamically allocate LED groups

We need to add an action to ensure wacom->led.groups is null when wacom_led_control() gets called after the resources has been freed. This also prevents to send a LED command when there is no support from the device. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom.h | 8 +++--

[PATCH 22/27] HID: wacom: EKR: attach the power_supply on first connection

Or Gnome complains about an empty battery. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 36 ++-- 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c index 04f5c75..1d79215 100644 ---

[PATCH 21/27] HID: wacom: EKR: have one power_supply per remote

Previously, all the remotes attached to the same receiver would share the same power_supply. That's not good as the remotes will constantly change the battery information according to their own state. To have something generic enough, we introduce struct wacom_battery which regroups all the

Re: [PATCH v9 04/13] task_isolation: add initial support

On Fri, Jul 01, 2016 at 04:59:26PM -0400, Chris Metcalf wrote: > On 6/29/2016 11:18 AM, Frederic Weisbecker wrote: > > > >I just feel that quiescing, on the way back to user after an unwanted > >interruption, is awkward. The quiescing should work once and for all > >on return back from the prctl.

Re: [PATCH v9 04/13] task_isolation: add initial support

On Fri, Jul 01, 2016 at 04:59:26PM -0400, Chris Metcalf wrote: > On 6/29/2016 11:18 AM, Frederic Weisbecker wrote: > > > >I just feel that quiescing, on the way back to user after an unwanted > >interruption, is awkward. The quiescing should work once and for all > >on return back from the prctl.

[PATCH 20/27] HID: wacom: EKR: allocate one input node per remote

Thanks to devres, we can now afford to create more than one input node without having to overload the remove/failure paths. Having one input node per remote is something which should have been implemented from start but the probability of having users with several remotes is quite low. Anyway,

[PATCH 23/27] HID: wacom: leds: use the ledclass instead of custom made sysfs files

The now obsolete sysfs files for LEDs and EKRemote are kept for backward compatibility. Both the EKR (read-only) and the regular Cintiqs and Intuos are now sharing the same led API. Signed-off-by: Benjamin Tissoires --- Documentation/ABI/testing/sysfs-driver-wacom

[PATCH 27/27] HID: wacom: leds: handle Cintiq 24HD leds buttons

The 24HD has 1 button per LED (first three buttons of each group). We need a special treatment for them as it's not a uniq button that switches between the LEDs. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_wac.c | 36

[PATCH 27/27] HID: wacom: leds: handle Cintiq 24HD leds buttons

The 24HD has 1 button per LED (first three buttons of each group). We need a special treatment for them as it's not a uniq button that switches between the LEDs. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_wac.c | 36 1 file changed, 36

[PATCH 20/27] HID: wacom: EKR: allocate one input node per remote

Thanks to devres, we can now afford to create more than one input node without having to overload the remove/failure paths. Having one input node per remote is something which should have been implemented from start but the probability of having users with several remotes is quite low. Anyway,

[PATCH 23/27] HID: wacom: leds: use the ledclass instead of custom made sysfs files

The now obsolete sysfs files for LEDs and EKRemote are kept for backward compatibility. Both the EKR (read-only) and the regular Cintiqs and Intuos are now sharing the same led API. Signed-off-by: Benjamin Tissoires --- Documentation/ABI/testing/sysfs-driver-wacom | 5 + drivers/hid/wacom.h

Re: [RFC PATCH v1] irqchip: add support for SMP irq router

Hey Sebastian, Mason, * Please fix mailer to wrap text at a sane length. I've re-wrapped and trimmed. On Tue, Jul 05, 2016 at 02:30:12PM +0200, Sebastian Frias wrote: > On 07/04/2016 02:11 PM, Mason wrote: ... > >> .../sigma,smp87xx-irqrouter.txt| 69 +++ > > > > In the

[PATCH 24/27] HID: wacom: leds: actually release the LEDs on disconnect

There is a bug (?) in devm_led_classdev_register() in which its increments the refcount of the parent. If the parent is an input device, that means the ref count never reaches 0 when devm_input_device_release() gets called. This means that the LEDs and all the devres resources attached to the

Re: [RFC PATCH v1] irqchip: add support for SMP irq router

Hey Sebastian, Mason, * Please fix mailer to wrap text at a sane length. I've re-wrapped and trimmed. On Tue, Jul 05, 2016 at 02:30:12PM +0200, Sebastian Frias wrote: > On 07/04/2016 02:11 PM, Mason wrote: ... > >> .../sigma,smp87xx-irqrouter.txt| 69 +++ > > > > In the

[PATCH 24/27] HID: wacom: leds: actually release the LEDs on disconnect

There is a bug (?) in devm_led_classdev_register() in which its increments the refcount of the parent. If the parent is an input device, that means the ref count never reaches 0 when devm_input_device_release() gets called. This means that the LEDs and all the devres resources attached to the

[PATCH 25/27] HID: wacom: leds: fix ordering of LED banks

Historically, 21UX2 and 24HD have the select groups inverted (0 is the right LED bank, and 1 the left one). This is not right, so fix that in the new LED API. For backward compatibility, we keep the wacom_led sysfs ABI stable. We don't need to care about luminance for these two devices as only

[PATCH 25/27] HID: wacom: leds: fix ordering of LED banks

Historically, 21UX2 and 24HD have the select groups inverted (0 is the right LED bank, and 1 the left one). This is not right, so fix that in the new LED API. For backward compatibility, we keep the wacom_led sysfs ABI stable. We don't need to care about luminance for these two devices as only

[PATCH 17/27] HID: wacom: EKR: have proper allocator and destructor

The wacom_remote_create_attr_group() and wacom_remote_destroy_attr_group() functions were both allocating/destroying the sysfs groups but also initializing the parameters for the remotes. Have proper functions that can be called and extended. Signed-off-by: Benjamin Tissoires

[PATCH 17/27] HID: wacom: EKR: have proper allocator and destructor

The wacom_remote_create_attr_group() and wacom_remote_destroy_attr_group() functions were both allocating/destroying the sysfs groups but also initializing the parameters for the remotes. Have proper functions that can be called and extended. Signed-off-by: Benjamin Tissoires ---

[PATCH 08/27] HID: wacom: put the managed resources in a group

We currently have a complex clean_inputs() function while this can be handled all by devres. Set a group that we can destroy in wireless_work(). Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom.h | 1 + drivers/hid/wacom_sys.c | 69

[PATCH 08/27] HID: wacom: put the managed resources in a group

We currently have a complex clean_inputs() function while this can be handled all by devres. Set a group that we can destroy in wireless_work(). Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom.h | 1 + drivers/hid/wacom_sys.c | 69 +

[PATCH 16/27] HID: wacom: rework fail path in probe() and parse_and_register()

Thanks to devres management, we don't need to remember a lot of failure path. One or two is enough. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 37 ++--- 1 file changed, 14 insertions(+), 23 deletions(-) diff

[PATCH 26/27] HID: wacom: leds: handle the switch of the LEDs directly in the kernel

The EKR switches the LED directly, and there is no point in having userspace handling the switch it self when it's easy enough to do in the kernel. The other benefit is that now userspace does not need to have root access to the LED but need only to read them with user privileges. Signed-off-by:

[PATCH 19/27] HID: wacom: EKR: have one array of struct remotes instead of many arrays

No functional changes, just a prep patch for the one after. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom.h | 6 -- drivers/hid/wacom_sys.c | 53 + drivers/hid/wacom_wac.c | 2 +- 3 files changed,

[PATCH 16/27] HID: wacom: rework fail path in probe() and parse_and_register()

Thanks to devres management, we don't need to remember a lot of failure path. One or two is enough. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 37 ++--- 1 file changed, 14 insertions(+), 23 deletions(-) diff --git a/drivers/hid/wacom_sys.c

[PATCH 26/27] HID: wacom: leds: handle the switch of the LEDs directly in the kernel

The EKR switches the LED directly, and there is no point in having userspace handling the switch it self when it's easy enough to do in the kernel. The other benefit is that now userspace does not need to have root access to the LED but need only to read them with user privileges. Signed-off-by:

[PATCH 19/27] HID: wacom: EKR: have one array of struct remotes instead of many arrays

No functional changes, just a prep patch for the one after. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom.h | 6 -- drivers/hid/wacom_sys.c | 53 + drivers/hid/wacom_wac.c | 2 +- 3 files changed, 32 insertions(+), 29

[PATCH 03/27] HID: wacom: remove cleanup of wacom->remote_dir from wacom_clean_inputs()

wacom->remote_dir has nothing to do with inputs, so better not magically removing it when cleaning inputs. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git

[PATCH 00/27] HID: wacom: cleanup/EKR/LED

Hi, Initially, I thought the series would have been short because it was driven by 23/27 and 26/27. We wanted to have a common API for the LED in the kernel and also let the kernel switches the LED for us so that libinput doesn't need to have root access. The LED kernel API has kernel triggers

[PATCH 03/27] HID: wacom: remove cleanup of wacom->remote_dir from wacom_clean_inputs()

wacom->remote_dir has nothing to do with inputs, so better not magically removing it when cleaning inputs. Signed-off-by: Benjamin Tissoires --- drivers/hid/wacom_sys.c | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/drivers/hid/wacom_sys.c

[PATCH 00/27] HID: wacom: cleanup/EKR/LED

Hi, Initially, I thought the series would have been short because it was driven by 23/27 and 26/27. We wanted to have a common API for the LED in the kernel and also let the kernel switches the LED for us so that libinput doesn't need to have root access. The LED kernel API has kernel triggers

Re: [PATCH v2] sched/deadline: remove useless param from setup_new_dl_entity

On 05/07/16 10:20, Steven Rostedt wrote: > On Wed, 29 Jun 2016 20:07:43 +0100 > Juri Lelli wrote: > > > > --- > > kernel/sched/deadline.c | 14 +++--- > > 1 file changed, 11 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/sched/deadline.c

Re: [PATCH v2] sched/deadline: remove useless param from setup_new_dl_entity

On 05/07/16 10:20, Steven Rostedt wrote: > On Wed, 29 Jun 2016 20:07:43 +0100 > Juri Lelli wrote: > > > > --- > > kernel/sched/deadline.c | 14 +++--- > > 1 file changed, 11 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > > index

Re: [PATCH v3 14/14] regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range

On Tue, Jun 14, 2016 at 11:13:22AM +0200, Boris Brezillon wrote: > Document the pwm-dutycycle-unit and pwm-dutycycle-range properties. Acked-by: Mark Brown signature.asc Description: PGP signature

Re: [PATCH v3 14/14] regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range

On Tue, Jun 14, 2016 at 11:13:22AM +0200, Boris Brezillon wrote: > Document the pwm-dutycycle-unit and pwm-dutycycle-range properties. Acked-by: Mark Brown signature.asc Description: PGP signature

Re: is pid_namespace leak in v3.10?

On 07/05, Xishi Qiu wrote: > > I find pid_namespace leak by "cat /proc/slabinfo | grep pid_namespace". > The kernel version is RHEL 7.1 (kernel v3.10 stable). > The following is the test case, after several times, the count of > pid_namespace > become very large, is it correct? Apparently not,

Re: is pid_namespace leak in v3.10?

On 07/05, Xishi Qiu wrote: > > I find pid_namespace leak by "cat /proc/slabinfo | grep pid_namespace". > The kernel version is RHEL 7.1 (kernel v3.10 stable). > The following is the test case, after several times, the count of > pid_namespace > become very large, is it correct? Apparently not,

Re: [PATCH v3 13/14] regulator: pwm: Support extra continuous mode cases

On Tue, Jun 14, 2016 at 11:13:21AM +0200, Boris Brezillon wrote: > The continuous mode allows one to declare a PWM regulator without having > to declare the voltage <-> dutycycle association table. It works fine as > long as your voltage(dutycycle) function is linear, but also has the > following

Re: [PATCH v3 13/14] regulator: pwm: Support extra continuous mode cases

On Tue, Jun 14, 2016 at 11:13:21AM +0200, Boris Brezillon wrote: > The continuous mode allows one to declare a PWM regulator without having > to declare the voltage <-> dutycycle association table. It works fine as > long as your voltage(dutycycle) function is linear, but also has the > following

Re: [PATCH v3 12/14] regulator: pwm: Retrieve correct voltage

On Tue, Jun 14, 2016 at 11:13:20AM +0200, Boris Brezillon wrote: > The continuous PWM voltage regulator is caching the voltage value in > the ->volt_uV field. While most of the time this value should reflect the > real voltage, sometime it can be sightly different if the PWM device > rounded the

Re: [PATCH v3 12/14] regulator: pwm: Retrieve correct voltage

On Tue, Jun 14, 2016 at 11:13:20AM +0200, Boris Brezillon wrote: > The continuous PWM voltage regulator is caching the voltage value in > the ->volt_uV field. While most of the time this value should reflect the > real voltage, sometime it can be sightly different if the PWM device > rounded the

Re: [PATCH v3 11/14] regulator: pwm: Properly initialize the ->state field

On Tue, Jun 14, 2016 at 11:13:19AM +0200, Boris Brezillon wrote: > The ->state field is currently initialized to 0, thus referencing the > voltage selector at index 0, which might not reflect the current > voltage value. > If possible, retrieve the current voltage selector from the PWM state, >

Re: [PATCH v3 11/14] regulator: pwm: Properly initialize the ->state field

On Tue, Jun 14, 2016 at 11:13:19AM +0200, Boris Brezillon wrote: > The ->state field is currently initialized to 0, thus referencing the > voltage selector at index 0, which might not reflect the current > voltage value. > If possible, retrieve the current voltage selector from the PWM state, >

Re: [PATCH v3 10/14] regulator: pwm: Switch to the atomic PWM API

On Tue, Jun 14, 2016 at 11:13:18AM +0200, Boris Brezillon wrote: > Use the atomic API wherever appropriate and get rid of pwm_apply_args() > call (the reference period and polarity are now explicitly set when > calling pwm_apply_state()). Acked-by: Mark Brown signature.asc

Re: [PATCH v3 10/14] regulator: pwm: Switch to the atomic PWM API

On Tue, Jun 14, 2016 at 11:13:18AM +0200, Boris Brezillon wrote: > Use the atomic API wherever appropriate and get rid of pwm_apply_args() > call (the reference period and polarity are now explicitly set when > calling pwm_apply_state()). Acked-by: Mark Brown signature.asc Description: PGP

pn533 driver crash

Hi We have ported pn533 driver from current upstream kernel to vendor kernel that our target hardware runs, and are having crashes. Analysis shows that same is possible in upstream kernel as well. commit b31d5103c message states that pn533_recv_frame() can be entered with dev->cmd not set. And

pn533 driver crash

Hi We have ported pn533 driver from current upstream kernel to vendor kernel that our target hardware runs, and are having crashes. Analysis shows that same is possible in upstream kernel as well. commit b31d5103c message states that pn533_recv_frame() can be entered with dev->cmd not set. And

Re: portable device tree connector -- problem statement

On 07/05/16 01:31, Mark Brown wrote: > On Mon, Jul 04, 2016 at 01:58:53PM -0700, Frank Rowand wrote: > >> On the other hand, I have no previous detailed knowledge of the beagle >> family. > > This is in no way specific to the BeagleBones, there's plenty of other > boards out there with similar

Re: portable device tree connector -- problem statement

On 07/05/16 01:31, Mark Brown wrote: > On Mon, Jul 04, 2016 at 01:58:53PM -0700, Frank Rowand wrote: > >> On the other hand, I have no previous detailed knowledge of the beagle >> family. > > This is in no way specific to the BeagleBones, there's plenty of other > boards out there with similar

Re: [PATCH] drivers/perf: arm-pmu: Handle per-interrupt affinity mask

On Fri, Jul 01, 2016 at 02:21:31PM +0100, Marc Zyngier wrote: > On a big-little system, PMUs can be wired to CPUs using per CPU > interrups (PPI). In this case, it is important to make sure that > the enable/disable do happen on the right set of CPUs. > > So instead of relying on the

Re: [PATCH] drivers/perf: arm-pmu: Handle per-interrupt affinity mask

On Fri, Jul 01, 2016 at 02:21:31PM +0100, Marc Zyngier wrote: > On a big-little system, PMUs can be wired to CPUs using per CPU > interrups (PPI). In this case, it is important to make sure that > the enable/disable do happen on the right set of CPUs. > > So instead of relying on the

Re: [PATCH v23 08/22] richacl: Compute maximum file masks from an acl

On Thu, 2016-06-30 at 15:46 +0200, Andreas Gruenbacher wrote: > Compute upper bound owner, group, and other file masks with as few > permissions as possible without denying any permissions that the NFSv4 > acl in a richacl grants. > > This algorithm is used when a file inherits an acl at create

Re: [PATCH v23 08/22] richacl: Compute maximum file masks from an acl

On Thu, 2016-06-30 at 15:46 +0200, Andreas Gruenbacher wrote: > Compute upper bound owner, group, and other file masks with as few > permissions as possible without denying any permissions that the NFSv4 > acl in a richacl grants. > > This algorithm is used when a file inherits an acl at create

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

On Fri, Jul 01, 2016 at 05:33:42PM +0900, Andi Shyti wrote: > The ir-spi is a simple device driver which supports the > connection between an IR LED and the MOSI line of an SPI device. Please split the binding from the driver. > The driver, indeed, uses the SPI framework to stream the raw data

Re: [PATCH] [media] rc: ir-spi: add support for IR LEDs connected with SPI

On Fri, Jul 01, 2016 at 05:33:42PM +0900, Andi Shyti wrote: > The ir-spi is a simple device driver which supports the > connection between an IR LED and the MOSI line of an SPI device. Please split the binding from the driver. > The driver, indeed, uses the SPI framework to stream the raw data

Re: [PATCH 1/2] qe/ic: move qe_ic_init from platforms to irqchip

On Tue, Jul 05, 2016 at 07:27:21AM +, Qiang Zhao wrote: > On 07/05/2016 11:19 AM, Jason Cooper wrote: > > -Original Message- > > From: Jason Cooper [mailto:ja...@lakedaemon.net] > > Sent: Tuesday, July 05, 2016 11:19 AM > > To: Qiang Zhao > >

Re: [PATCH 1/2] qe/ic: move qe_ic_init from platforms to irqchip

On Tue, Jul 05, 2016 at 07:27:21AM +, Qiang Zhao wrote: > On 07/05/2016 11:19 AM, Jason Cooper wrote: > > -Original Message- > > From: Jason Cooper [mailto:ja...@lakedaemon.net] > > Sent: Tuesday, July 05, 2016 11:19 AM > > To: Qiang Zhao > > Cc: o...@buserror.net;

Re: [PATCH v2] sched/deadline: remove useless param from setup_new_dl_entity

On Wed, 29 Jun 2016 20:07:43 +0100 Juri Lelli wrote: > --- > kernel/sched/deadline.c | 14 +++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index fcb7f0217ff4..2000ad2294d5 100644 > ---

Re: [PATCH v2] sched/deadline: remove useless param from setup_new_dl_entity

On Wed, 29 Jun 2016 20:07:43 +0100 Juri Lelli wrote: > --- > kernel/sched/deadline.c | 14 +++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index fcb7f0217ff4..2000ad2294d5 100644 > ---

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote: > On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki wrote: > > On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote: > >> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote: > >> > On 2016/6/30

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote: > On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki wrote: > > On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote: > >> On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote: > >> > On 2016/6/30 21:27, Rafael J. Wysocki

Re: [PATCH 0/3] perf tools: Add hist_entry allocation callbacks

Em Tue, Jul 05, 2016 at 08:56:02AM +0200, Jiri Olsa escreveu: > hi, > this patchset tries to add support provide own allocation > zalloc/free methods for hist_entry object. > > v2 changes: > - merged patch 1 and 2 from RFC Thanks applied.

Re: [PATCH 0/3] perf tools: Add hist_entry allocation callbacks

Em Tue, Jul 05, 2016 at 08:56:02AM +0200, Jiri Olsa escreveu: > hi, > this patchset tries to add support provide own allocation > zalloc/free methods for hist_entry object. > > v2 changes: > - merged patch 1 and 2 from RFC Thanks applied.

Re: powerpc/pseries: fix error return value in cmm_mem_going_offline

On Tue, 2016-08-03 at 21:26:17 UTC, Rasmus Villemoes wrote: > cmm_mem_going_offline is (only) called from cmm_memory_cb(), which > sends the return value through notifier_from_errno(). The latter > expects 0 or -errno (notifier_to_errno(notifier_from_errno(x)) is 0 > for any x >= 0, so passing a

Re: powerpc/pseries: fix error return value in cmm_mem_going_offline

On Tue, 2016-08-03 at 21:26:17 UTC, Rasmus Villemoes wrote: > cmm_mem_going_offline is (only) called from cmm_memory_cb(), which > sends the return value through notifier_from_errno(). The latter > expects 0 or -errno (notifier_to_errno(notifier_from_errno(x)) is 0 > for any x >= 0, so passing a

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Tue, Jul 05, 2016 at 02:18:28PM +0200, Paolo Bonzini wrote: > > > On 05/07/2016 07:41, Neo Jia wrote: > > On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote: > >> The vGPU folks would like to trap the first access to a BAR by setting > >> vm_ops on the VMAs produced by mmap-ing a

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Tue, Jul 05, 2016 at 02:18:28PM +0200, Paolo Bonzini wrote: > > > On 05/07/2016 07:41, Neo Jia wrote: > > On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote: > >> The vGPU folks would like to trap the first access to a BAR by setting > >> vm_ops on the VMAs produced by mmap-ing a

Re: [PATCH] MAINTAINERS: update STM32 maintainers list

On Thursday, June 30, 2016 11:47:44 AM CEST Alexandre Torgue wrote: > > On 06/22/2016 03:56 PM, Maxime Coquelin wrote: > > I will have less time to work on STM32 platform, so I propose > > Alexandre as co-maintainer. > > > > Alex is working in the STMicroelectronics division in charge of STM32 >

Re: [PATCH] MAINTAINERS: update STM32 maintainers list

On Thursday, June 30, 2016 11:47:44 AM CEST Alexandre Torgue wrote: > > On 06/22/2016 03:56 PM, Maxime Coquelin wrote: > > I will have less time to work on STM32 platform, so I propose > > Alexandre as co-maintainer. > > > > Alex is working in the STMicroelectronics division in charge of STM32 >

Re: [PATCH] arm64: defconfig: Enable s2mps11 regulator clk and s3c rtc driver

Hello Alim, On 07/05/2016 06:06 AM, Alim Akhtar wrote: > The s3c rtc controller on exynos7 platform uses rtc source clock > from s2mps11 pmic. This patch enables the required bits to make > rtc work on exynos7-espresso board. > > Signed-off-by: Alim Akhtar > --- Looks

Re: [PATCH] arm64: defconfig: Enable s2mps11 regulator clk and s3c rtc driver

Hello Alim, On 07/05/2016 06:06 AM, Alim Akhtar wrote: > The s3c rtc controller on exynos7 platform uses rtc source clock > from s2mps11 pmic. This patch enables the required bits to make > rtc work on exynos7-espresso board. > > Signed-off-by: Alim Akhtar > --- Looks good to me. Reviewed-by:

Re: [PATCH 2/3] pinctrl: Add STM32F746 MCU support

[[PATCH 2/3] pinctrl: Add STM32F746 MCU support] On 05/07/2016 (Tue 15:40) Alexandre TORGUE wrote: > From: Maxime Coquelin > > This patch which adds STM32F746 pinctrl and GPIO support, relies on the > generic STM32 pinctrl driver. > > Signed-off-by: Maxime Coquelin

Re: [PATCH 2/3] pinctrl: Add STM32F746 MCU support

[[PATCH 2/3] pinctrl: Add STM32F746 MCU support] On 05/07/2016 (Tue 15:40) Alexandre TORGUE wrote: > From: Maxime Coquelin > > This patch which adds STM32F746 pinctrl and GPIO support, relies on the > generic STM32 pinctrl driver. > > Signed-off-by: Maxime Coquelin > Signed-off-by: Alexandre

Re: [PATCH v3 1/4] dma-buf/fence-array: add fence_is_array()

Am 05.07.2016 um 01:57 schrieb Gustavo Padovan: From: Gustavo Padovan Add helper to check if fence is array. v2: Comments from Chris Wilson - remove ternary if from ops comparison - add EXPORT_SYMBOL(fence_array_ops) Cc: Chris Wilson

Re: [PATCH v3 1/4] dma-buf/fence-array: add fence_is_array()

Am 05.07.2016 um 01:57 schrieb Gustavo Padovan: From: Gustavo Padovan Add helper to check if fence is array. v2: Comments from Chris Wilson - remove ternary if from ops comparison - add EXPORT_SYMBOL(fence_array_ops) Cc: Chris Wilson Cc: Christian König Signed-off-by:

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