[PATCH 0/5] drivers: char: Fix checkpatch issues.

This patchset fixes checkpatch issues and use IDA allocation instead of bitmap. Varsha Rao (5): drivers: char: Replace "foo * bar" with "foo *bar". drivers: char: Add space after ','. drivers: char: Add blank line after declarations. drivers: char: Replace printk with pr_err. drivers:

[PATCH 0/5] drivers: char: Fix checkpatch issues.

This patchset fixes checkpatch issues and use IDA allocation instead of bitmap. Varsha Rao (5): drivers: char: Replace "foo * bar" with "foo *bar". drivers: char: Add space after ','. drivers: char: Add blank line after declarations. drivers: char: Replace printk with pr_err. drivers:

[PATCH 1/5] drivers: char: Replace "foo * bar" with "foo *bar".

Remove space after * in pointer type, to follow Linux coding style. This patch fixes the following checkpatch issue: ERROR: "foo * bar" should be "foo *bar" Signed-off-by: Varsha Rao --- drivers/char/misc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH 1/5] drivers: char: Replace "foo * bar" with "foo *bar".

Remove space after * in pointer type, to follow Linux coding style. This patch fixes the following checkpatch issue: ERROR: "foo * bar" should be "foo *bar" Signed-off-by: Varsha Rao --- drivers/char/misc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 1/5] locking: Introduce range reader/writer lock

On Mon 03-04-17 08:26:43, Davidlohr Bueso wrote: > On Mon, 03 Apr 2017, Laurent Dufour wrote: > >Le Tue, 28 Mar 2017 09:39:18 -0700, > >Davidlohr Bueso a écrit : > >>I'll wait to see if there are any more concerns and send a v2 with > >>your corrections. > > > >Hi Bavidlohr, I

Re: [PATCH 1/5] locking: Introduce range reader/writer lock

On Mon 03-04-17 08:26:43, Davidlohr Bueso wrote: > On Mon, 03 Apr 2017, Laurent Dufour wrote: > >Le Tue, 28 Mar 2017 09:39:18 -0700, > >Davidlohr Bueso a écrit : > >>I'll wait to see if there are any more concerns and send a v2 with > >>your corrections. > > > >Hi Bavidlohr, I think there is a

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, 3 Apr 2017, Alan Cox wrote: > If you need a tiny tiny tty layer console for some kind of not quite > mini-Linux please just steal the one from Fuzix or something similar > thats only a couple of K in size and only needs extremely simple send > byte/rx byte type handlers. This, however,

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, 3 Apr 2017, Alan Cox wrote: > If you need a tiny tiny tty layer console for some kind of not quite > mini-Linux please just steal the one from Fuzix or something similar > thats only a couple of K in size and only needs extremely simple send > byte/rx byte type handlers. This, however,

Re: [PATCH] Input: psmouse - fix cleaning up SMBus companions

On Apr 01 2017 or thereabouts, Dmitry Torokhov wrote: > When trying to destroy platform data after destruction of SMbus companion, > we need to make sure that we are actually dealing with an SMB companion > device, and not some random I2C client device. > > Fixes: 8eb92e5c9133 ("Input: psmouse -

Re: [PATCH] Input: psmouse - fix cleaning up SMBus companions

On Apr 01 2017 or thereabouts, Dmitry Torokhov wrote: > When trying to destroy platform data after destruction of SMbus companion, > we need to make sure that we are actually dealing with an SMB companion > device, and not some random I2C client device. > > Fixes: 8eb92e5c9133 ("Input: psmouse -

RE: [PATCH 3/4] sparc: convert mdesc_handle.refcnt from atomic_t to refcount_t

> From: "Reshetova, Elena" > Date: Mon, 3 Apr 2017 07:28:01 + > > > > >> From: Elena Reshetova > >> Date: Mon, 20 Feb 2017 13:06:20 +0200 > >> > >> > refcount_t type and corresponding API should be > >> > used instead of atomic_t when

RE: [PATCH 3/4] sparc: convert mdesc_handle.refcnt from atomic_t to refcount_t

> From: "Reshetova, Elena" > Date: Mon, 3 Apr 2017 07:28:01 + > > > > >> From: Elena Reshetova > >> Date: Mon, 20 Feb 2017 13:06:20 +0200 > >> > >> > refcount_t type and corresponding API should be > >> > used instead of atomic_t when the variable is used as > >> > a reference counter. This

Re: [PATCH v2] clk: stm32h7: Add stm32h743 clock driver

On Mon, Apr 3, 2017 at 9:39 AM, Rob Herring wrote: > On Wed, Mar 29, 2017 at 11:08:22AM +0200, gabriel.fernan...@st.com wrote: >> From: Gabriel Fernandez >> >> This patch enables clocks for STM32H743 boards. >> >> Signed-off-by: Gabriel Fernandez

Re: [PATCH v2] clk: stm32h7: Add stm32h743 clock driver

On Mon, Apr 3, 2017 at 9:39 AM, Rob Herring wrote: > On Wed, Mar 29, 2017 at 11:08:22AM +0200, gabriel.fernan...@st.com wrote: >> From: Gabriel Fernandez >> >> This patch enables clocks for STM32H743 boards. >> >> Signed-off-by: Gabriel Fernandez >> >> Just for the MFD changes: >> Acked-by: Lee

Re: [PATCH v1] reset: Make optional stuff optional for all users

On Mon, 2017-04-03 at 18:23 +0300, Andy Shevchenko wrote: > On Mon, 2017-04-03 at 17:09 +0200, Philipp Zabel wrote: > > On Mon, 2017-04-03 at 14:33 +, Shevchenko, Andriy wrote: > > > On Mon, 2017-04-03 at 17:31 +0300, Andy Shevchenko wrote: > > > > On Mon, 2017-04-03 at 16:27 +0200, Philipp

Re: [PATCH v1] reset: Make optional stuff optional for all users

On Mon, 2017-04-03 at 18:23 +0300, Andy Shevchenko wrote: > On Mon, 2017-04-03 at 17:09 +0200, Philipp Zabel wrote: > > On Mon, 2017-04-03 at 14:33 +, Shevchenko, Andriy wrote: > > > On Mon, 2017-04-03 at 17:31 +0300, Andy Shevchenko wrote: > > > > On Mon, 2017-04-03 at 16:27 +0200, Philipp

Re: [PATCH v2 6/9] Input: psmouse - add support for SMBus companions

On Apr 01 2017 or thereabouts, Dmitry Torokhov wrote: > On Fri, Mar 31, 2017 at 11:37:05AM +0200, Benjamin Tissoires wrote: > > Hi Dmitry, > > > > On Mar 10 2017 or thereabouts, Dmitry Torokhov wrote: > > > From: Benjamin Tissoires > > > > > > This provides glue

Re: [PATCH v2 6/9] Input: psmouse - add support for SMBus companions

On Apr 01 2017 or thereabouts, Dmitry Torokhov wrote: > On Fri, Mar 31, 2017 at 11:37:05AM +0200, Benjamin Tissoires wrote: > > Hi Dmitry, > > > > On Mar 10 2017 or thereabouts, Dmitry Torokhov wrote: > > > From: Benjamin Tissoires > > > > > > This provides glue between PS/2 devices that

Re: [PATCH 1/3] pinctrl: Add bindings for ARTPEC-6 pinmux

On Thu, Mar 30, 2017 at 01:27:44PM +0200, Jesper Nilsson wrote: > Add the bindings for the pinmux functions in the > ARTPEC-6 SoC, including bias and drive strength. > > Signed-off-by: Jesper Nilsson > --- > .../bindings/pinctrl/axis,artpec6-pinctrl.txt | 85 >

Re: [PATCH 1/3] pinctrl: Add bindings for ARTPEC-6 pinmux

On Thu, Mar 30, 2017 at 01:27:44PM +0200, Jesper Nilsson wrote: > Add the bindings for the pinmux functions in the > ARTPEC-6 SoC, including bias and drive strength. > > Signed-off-by: Jesper Nilsson > --- > .../bindings/pinctrl/axis,artpec6-pinctrl.txt | 85 > ++ >

Re: [PATCH 4/4] dt-bindings: input: Add Atmel PTC subsystem bindings

I think this patch should be first so you add the bindings before the driver. On 31/03/2017 at 17:22:50 +0200, Ludovic Desroches wrote: > Add description of the Atmel PTC subsystem bindings. > > Signed-off-by: Ludovic Desroches > --- >

Re: [PATCH 4/4] dt-bindings: input: Add Atmel PTC subsystem bindings

I think this patch should be first so you add the bindings before the driver. On 31/03/2017 at 17:22:50 +0200, Ludovic Desroches wrote: > Add description of the Atmel PTC subsystem bindings. > > Signed-off-by: Ludovic Desroches > --- > .../devicetree/bindings/input/atmel,ptc.txt| 67 >

Re: [PATCH 1/4] input: misc: introduce Atmel PTC driver

On 31/03/2017 at 17:22:47 +0200, Ludovic Desroches wrote: > From: Ludovic Desroches I think you probably want to switch to your microchip email. Also, this requires a proper commit message. > > Signed-off-by: Ludovic Desroches >

Re: [PATCH 1/4] input: misc: introduce Atmel PTC driver

On 31/03/2017 at 17:22:47 +0200, Ludovic Desroches wrote: > From: Ludovic Desroches I think you probably want to switch to your microchip email. Also, this requires a proper commit message. > > Signed-off-by: Ludovic Desroches > +struct atmel_ptc { > + void __iomem*ppp_regs;

RE: [PATCH V7 4/7] mfd: da9061: MFD core support

On 03 April 2017 15:31, Lee Jones wrote: > Subject: Re: [PATCH V7 4/7] mfd: da9061: MFD core support > > On Mon, 03 Apr 2017, Steve Twiss wrote: > > On 03 April 2017 15:12, Lee Jones wrote: > > > > > > @@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c, > > > >

RE: [PATCH V7 4/7] mfd: da9061: MFD core support

On 03 April 2017 15:31, Lee Jones wrote: > Subject: Re: [PATCH V7 4/7] mfd: da9061: MFD core support > > On Mon, 03 Apr 2017, Steve Twiss wrote: > > On 03 April 2017 15:12, Lee Jones wrote: > > > > > > @@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c, > > > >

Re: [PATCH v2] dt-bindings: Add documentation for GP10B GPU

On Thu, Mar 30, 2017 at 06:26:44PM +0900, Alexandre Courbot wrote: > GP10B's definition is mostly similar to GK20A's and GM20B's. The only > noticeable difference is the use of power domains instead of a regulator > for power supply. > > Signed-off-by: Alexandre Courbot >

Re: [PATCH v2] dt-bindings: Add documentation for GP10B GPU

On Thu, Mar 30, 2017 at 06:26:44PM +0900, Alexandre Courbot wrote: > GP10B's definition is mostly similar to GK20A's and GM20B's. The only > noticeable difference is the use of power domains instead of a regulator > for power supply. > > Signed-off-by: Alexandre Courbot > --- > Changes since v1:

Re: [PATCH] KEYS: encrypted: avoid encrypting/decrypting stack buffers

On Sat, 2017-04-01 at 20:33 -0700, Eric Biggers wrote: > On Sat, Apr 01, 2017 at 10:23:57PM -0400, Mimi Zohar wrote: > > On Sat, 2017-04-01 at 12:17 -0700, Eric Biggers wrote: > > > From: Eric Biggers > > > > > > Since v4.9, the crypto API cannot (normally) be used to

Re: [PATCH] KEYS: encrypted: avoid encrypting/decrypting stack buffers

On Sat, 2017-04-01 at 20:33 -0700, Eric Biggers wrote: > On Sat, Apr 01, 2017 at 10:23:57PM -0400, Mimi Zohar wrote: > > On Sat, 2017-04-01 at 12:17 -0700, Eric Biggers wrote: > > > From: Eric Biggers > > > > > > Since v4.9, the crypto API cannot (normally) be used to encrypt/decrypt > > > stack

[PATCH] of: irq: Export of_irq_count()

From: Thierry Reding of_irq_count() is handy for obtaining the number of interrupts assigned to a device tree node. It is reasonable to want to access this function from loadable modules, so export the symbol to allow that. Signed-off-by: Thierry Reding

[PATCH] of: irq: Export of_irq_count()

From: Thierry Reding of_irq_count() is handy for obtaining the number of interrupts assigned to a device tree node. It is reasonable to want to access this function from loadable modules, so export the symbol to allow that. Signed-off-by: Thierry Reding --- Hi Rob, Frank, This patch is

[PATCH] ACPI: emits change uevents to all physical companion devices of container's children

The caa73ea1 patch, "ACPI / hotplug / driver core: Handle containers in a special way", introduced the offline callback of acpi container. In the patch description, it mentions: For ACPI containers that callback simply walks the list of ACPI device objects right below the container object

[PATCH] ACPI: emits change uevents to all physical companion devices of container's children

The caa73ea1 patch, "ACPI / hotplug / driver core: Handle containers in a special way", introduced the offline callback of acpi container. In the patch description, it mentions: For ACPI containers that callback simply walks the list of ACPI device objects right below the container object

Re: [PATCH 3/3] hwmon: pwm-fan: remove no longer needed suspend/resume code

On Mon, Apr 03, 2017 at 03:47:06PM +0200, Bartlomiej Zolnierkiewicz wrote: > The suspend/resume is now properly handled by pwm-samsung driver > (pwm-fan is currently only used by ARM Exynos boards) and the old > code only handles ctx->pwm_value != 0 case. Just remove it. > > Signed-off-by:

Re: [PATCH 3/3] hwmon: pwm-fan: remove no longer needed suspend/resume code

On Mon, Apr 03, 2017 at 03:47:06PM +0200, Bartlomiej Zolnierkiewicz wrote: > The suspend/resume is now properly handled by pwm-samsung driver > (pwm-fan is currently only used by ARM Exynos boards) and the old > code only handles ctx->pwm_value != 0 case. Just remove it. > > Signed-off-by:

Re: [PATCH] KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings

Eric Biggers wrote: > @@ -135,6 +135,9 @@ int install_thread_keyring_to_cred(struct cred *new) > { > struct key *keyring; > > + if (new->thread_keyring) > + return -EEXIST; > + > keyring = keyring_alloc("_tid", new->uid, new->gid, new, >

Re: [PATCH] KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings

Eric Biggers wrote: > @@ -135,6 +135,9 @@ int install_thread_keyring_to_cred(struct cred *new) > { > struct key *keyring; > > + if (new->thread_keyring) > + return -EEXIST; > + > keyring = keyring_alloc("_tid", new->uid, new->gid, new, >

Re: [PATCH] Input: silead - list all supported compatible strings in binding document

Hello Rob, On 04/03/2017 11:25 AM, Rob Herring wrote: > On Wed, Mar 29, 2017 at 02:25:31PM -0400, Javier Martinez Canillas wrote: >> The driver contains compatible strings for different models, but the DT >> binding doc only lists one of them. Add the remaining to the document. >> >>

Re: Bad page state splats on arm64, v4.11-rc{3,4}

On Mon, Apr 03, 2017 at 04:48:15PM +0100, Catalin Marinas wrote: > On Mon, Apr 03, 2017 at 12:37:51PM +0100, Will Deacon wrote: > > On Mon, Apr 03, 2017 at 11:56:29AM +0100, Mark Rutland wrote: > > > On Fri, Mar 31, 2017 at 06:58:45PM +0100, Mark Rutland wrote: > > > > I'm seeing intermittent bad

Re: [PATCH] Input: silead - list all supported compatible strings in binding document

Hello Rob, On 04/03/2017 11:25 AM, Rob Herring wrote: > On Wed, Mar 29, 2017 at 02:25:31PM -0400, Javier Martinez Canillas wrote: >> The driver contains compatible strings for different models, but the DT >> binding doc only lists one of them. Add the remaining to the document. >> >>

Re: Bad page state splats on arm64, v4.11-rc{3,4}

On Mon, Apr 03, 2017 at 04:48:15PM +0100, Catalin Marinas wrote: > On Mon, Apr 03, 2017 at 12:37:51PM +0100, Will Deacon wrote: > > On Mon, Apr 03, 2017 at 11:56:29AM +0100, Mark Rutland wrote: > > > On Fri, Mar 31, 2017 at 06:58:45PM +0100, Mark Rutland wrote: > > > > I'm seeing intermittent bad

Re: [PATCH] hexagon/time: set ->min_delta_ticks and ->max_delta_ticks

On Thu, Mar 30, 2017 at 09:43:32PM +0200, Nicolai Stange wrote: > In preparation for making the clockevents core NTP correction aware, > all clockevent device drivers must set ->min_delta_ticks and > ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a > clockevent device's rate is

Re: [PATCH] hexagon/time: set ->min_delta_ticks and ->max_delta_ticks

On Thu, Mar 30, 2017 at 09:43:32PM +0200, Nicolai Stange wrote: > In preparation for making the clockevents core NTP correction aware, > all clockevent device drivers must set ->min_delta_ticks and > ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a > clockevent device's rate is

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Mon, Apr 03, 2017 at 04:18:23PM +0200, Christoph Hellwig wrote: > Mike, > > can you try the patch below? It's really easy to test on qemu so I will - just add a dummy virtio-serial-pci device with -device virtio-serial-pci and add threadirqs to kernel command line. However it doesn't look

Re: [PATCH] KEYS: fix freeing uninitialized memory in key_update()

Pulled.

Re: [PATCH v3 16/37] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

On Thu, Mar 30, 2017 at 03:46:02PM +0900, Masahiro Yamada wrote: > Add two compatible strings for UniPhier SoCs. > > "socionext,uniphier-denali-nand-v5a" is used on UniPhier sLD3, LD4, > Pro4, sLD8 SoCs. > > "socionext,uniphier-denali-nand-v5b" is used on UniPhier Pro5, PXs2, > LD6b, LD11, LD20

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Mon, Apr 03, 2017 at 04:18:23PM +0200, Christoph Hellwig wrote: > Mike, > > can you try the patch below? It's really easy to test on qemu so I will - just add a dummy virtio-serial-pci device with -device virtio-serial-pci and add threadirqs to kernel command line. However it doesn't look

Re: [PATCH] KEYS: fix freeing uninitialized memory in key_update()

Pulled.

Re: [PATCH v3 16/37] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants

On Thu, Mar 30, 2017 at 03:46:02PM +0900, Masahiro Yamada wrote: > Add two compatible strings for UniPhier SoCs. > > "socionext,uniphier-denali-nand-v5a" is used on UniPhier sLD3, LD4, > Pro4, sLD8 SoCs. > > "socionext,uniphier-denali-nand-v5b" is used on UniPhier Pro5, PXs2, > LD6b, LD11, LD20

Re: [PATCH] KEYS: fix dereferencing NULL payload with nonzero length

Eric Biggers wrote: > - if (_payload) { > + if (plen) { "if (_payload && plen)" would be better. David

Re: [PATCH] KEYS: fix dereferencing NULL payload with nonzero length

Eric Biggers wrote: > - if (_payload) { > + if (plen) { "if (_payload && plen)" would be better. David

Re: Bad page state splats on arm64, v4.11-rc{3,4}

On Mon, Apr 03, 2017 at 12:37:51PM +0100, Will Deacon wrote: > On Mon, Apr 03, 2017 at 11:56:29AM +0100, Mark Rutland wrote: > > On Fri, Mar 31, 2017 at 06:58:45PM +0100, Mark Rutland wrote: > > > Hi, > > > > > > I'm seeing intermittent bad page state splats on arm64 with 4.11-rc3 and > > >

Re: Bad page state splats on arm64, v4.11-rc{3,4}

On Mon, Apr 03, 2017 at 12:37:51PM +0100, Will Deacon wrote: > On Mon, Apr 03, 2017 at 11:56:29AM +0100, Mark Rutland wrote: > > On Fri, Mar 31, 2017 at 06:58:45PM +0100, Mark Rutland wrote: > > > Hi, > > > > > > I'm seeing intermittent bad page state splats on arm64 with 4.11-rc3 and > > >

Re: [PATCH v3 5/7] mfd: Add Device Tree bindings document for TI tps6105x chip

Hello Lee, On 04/03/2017 07:15 AM, Lee Jones wrote: [snip] >> + >> +The TP61050/TPS61052 is a high-power "white LED driver". This boost >> converter >> +is also used for other things than white LEDs, and also contains a GPIO pin. > > What functions does it offer? > Same comment than before,

Re: [PATCH v3 5/7] mfd: Add Device Tree bindings document for TI tps6105x chip

Hello Lee, On 04/03/2017 07:15 AM, Lee Jones wrote: [snip] >> + >> +The TP61050/TPS61052 is a high-power "white LED driver". This boost >> converter >> +is also used for other things than white LEDs, and also contains a GPIO pin. > > What functions does it offer? > Same comment than before,

Re: [PATCH v3 2/7] mfd: retu: Add OF device ID table

Hello Lee, On 04/03/2017 07:15 AM, Lee Jones wrote: [snip] >> >> +static const struct of_device_id retu_of_match[] = { >> +{ .compatible = "nokia,retu-mfd" }, >> +{ .compatible = "nokia,tahvo-mfd" }, > > Please drop the "-mfd". > Yes, I also didn't like it but I didn't want to

Re: [PATCH v3 2/7] mfd: retu: Add OF device ID table

Hello Lee, On 04/03/2017 07:15 AM, Lee Jones wrote: [snip] >> >> +static const struct of_device_id retu_of_match[] = { >> +{ .compatible = "nokia,retu-mfd" }, >> +{ .compatible = "nokia,tahvo-mfd" }, > > Please drop the "-mfd". > Yes, I also didn't like it but I didn't want to

Re: [PATCH] KEYS: encrypted: avoid encrypting/decrypting stack buffers

Pulled.

Re: [PATCH] KEYS: encrypted: avoid encrypting/decrypting stack buffers

Pulled.

Re: [PATCH v3 0/4] tty/serial: meson_uart: add support for core clock handling

Helmut Klein writes: > To be able to use the three none AO uarts of the meson gx SoCs (uart_A, s/none/non/ > uart_B & uart_C), the core clock has to be enabled (see chapter 22.3 of > the public s905 data sheet). > At least the u-boot of my s905 based media player (netxeon

Re: [PATCH v3 0/4] tty/serial: meson_uart: add support for core clock handling

Helmut Klein writes: > To be able to use the three none AO uarts of the meson gx SoCs (uart_A, s/none/non/ > uart_B & uart_C), the core clock has to be enabled (see chapter 22.3 of > the public s905 data sheet). > At least the u-boot of my s905 based media player (netxeon minimx-g) > doesn't

Re: [PATCH] KEYS: put keyring if install_session_keyring_to_cred() fails

Eric Biggers wrote: > +error3: > + key_put(keyring); > error2: > mutex_unlock(_session_mutex); I would prefer the put to be outside of the locked section. How about the attached instead? David --- commit 5f9e6fc4fdbbf9ada9bd03640b1c3ca50a3e5415 Author: Eric

Re: [RFC][PATCHv2 8/8] printk: enable printk offloading

On Wed 2017-03-29 18:25:11, Sergey Senozhatsky wrote: > Initialize the kernel printing thread and enable printk() > offloading. > > Signed-off-by: Sergey Senozhatsky > --- > kernel/printk/printk.c | 19 +++ > 1 file changed, 19 insertions(+) > >

Re: [RFC][PATCHv2 8/8] printk: enable printk offloading

On Wed 2017-03-29 18:25:11, Sergey Senozhatsky wrote: > Initialize the kernel printing thread and enable printk() > offloading. > > Signed-off-by: Sergey Senozhatsky > --- > kernel/printk/printk.c | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git

Re: [PATCH] KEYS: put keyring if install_session_keyring_to_cred() fails

Eric Biggers wrote: > +error3: > + key_put(keyring); > error2: > mutex_unlock(_session_mutex); I would prefer the put to be outside of the locked section. How about the attached instead? David --- commit 5f9e6fc4fdbbf9ada9bd03640b1c3ca50a3e5415 Author: Eric Biggers Date: Sat Apr

Re: [PATCH v3 1/7] mfd: Add Device Tree bindings document for retu/tahvo ASIC chips

Hello Lee, Thanks a lot for your feedback. On 04/03/2017 07:13 AM, Lee Jones wrote: > On Sat, 01 Apr 2017, Javier Martinez Canillas wrote: > >> There are Device Tree source files defining a device node for the >> retu/tahvo I2C chip, but there isn't a DT binding document for it. >> >>

Re: [PATCH v3 1/7] mfd: Add Device Tree bindings document for retu/tahvo ASIC chips

Hello Lee, Thanks a lot for your feedback. On 04/03/2017 07:13 AM, Lee Jones wrote: > On Sat, 01 Apr 2017, Javier Martinez Canillas wrote: > >> There are Device Tree source files defining a device node for the >> retu/tahvo I2C chip, but there isn't a DT binding document for it. >> >>

Re: [PATCH 1/3] cpufreq: Add Tegra186 cpufreq driver

On 04/03/2017 05:47 PM, Thierry Reding wrote: On Mon, Apr 03, 2017 at 03:42:23PM +0300, Mikko Perttunen wrote: Add a new cpufreq driver for Tegra186 (and likely later). The CPUs are organized into two clusters, Denver and A57, with two and four cores respectively. CPU frequency can be adjusted

Re: [PATCH 1/3] cpufreq: Add Tegra186 cpufreq driver

On 04/03/2017 05:47 PM, Thierry Reding wrote: On Mon, Apr 03, 2017 at 03:42:23PM +0300, Mikko Perttunen wrote: Add a new cpufreq driver for Tegra186 (and likely later). The CPUs are organized into two clusters, Denver and A57, with two and four cores respectively. CPU frequency can be adjusted

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Thu, Feb 23, 2017 at 07:40:13PM +0100, Pavel Machek wrote: > On Thu 2017-02-23 17:28:26, Frederic Weisbecker wrote: > > On Tue, Feb 14, 2017 at 08:27:43PM +0100, Pavel Machek wrote: > > > On Tue 2017-02-14 18:59:56, Pavel Machek wrote: > > > > Hi! > > > > > > > > > > > > Hmm. I moved keyboard

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Thu, Feb 23, 2017 at 07:40:13PM +0100, Pavel Machek wrote: > On Thu 2017-02-23 17:28:26, Frederic Weisbecker wrote: > > On Tue, Feb 14, 2017 at 08:27:43PM +0100, Pavel Machek wrote: > > > On Tue 2017-02-14 18:59:56, Pavel Machek wrote: > > > > Hi! > > > > > > > > > > > > Hmm. I moved keyboard

Re: [PATCH v3 01/11] dt-bindings: add binding for the Allwinner DE2 CCU

On Thu, Mar 30, 2017 at 03:46:03AM +0800, Icenowy Zheng wrote: > From: Icenowy Zheng > > Allwinner "Display Engine 2.0" contains some clock controls in it. > > In order to add them as clock drivers, we need a device tree binding. > Add the binding here. > > Signed-off-by:

Re: [PATCH v3 01/11] dt-bindings: add binding for the Allwinner DE2 CCU

On Thu, Mar 30, 2017 at 03:46:03AM +0800, Icenowy Zheng wrote: > From: Icenowy Zheng > > Allwinner "Display Engine 2.0" contains some clock controls in it. > > In order to add them as clock drivers, we need a device tree binding. > Add the binding here. > > Signed-off-by: Icenowy Zheng > ---

Re: [PATCH v3 3/4] tty/serial: meson_uart: add the core clock handling to the driver

On Mon, Apr 3, 2017 at 7:57 AM, Jerome Brunet wrote: > On Fri, 2017-03-31 at 18:54 +0200, Helmut Klein wrote: >> This patch gets the core clock as provided by the DT and enables it. >> The code was taken from Amlogic's serial driver, and was tested on my >> board. >> >>

Re: [PATCH v3 3/4] tty/serial: meson_uart: add the core clock handling to the driver

On Mon, Apr 3, 2017 at 7:57 AM, Jerome Brunet wrote: > On Fri, 2017-03-31 at 18:54 +0200, Helmut Klein wrote: >> This patch gets the core clock as provided by the DT and enables it. >> The code was taken from Amlogic's serial driver, and was tested on my >> board. >> >> Signed-off-by: Helmut

Re: [RFC][PATCH] spin loop arch primitives for busy waiting

On Mon, Apr 3, 2017 at 1:13 AM, Nicholas Piggin wrote: > > The loops have some restrictions on what can be used, but they are > intended to be small and simple so it's not generally a problem: > - Don't use cpu_relax. > - Don't use return or goto. > - Don't use sleeping or

Re: [RFC][PATCH] spin loop arch primitives for busy waiting

On Mon, Apr 3, 2017 at 1:13 AM, Nicholas Piggin wrote: > > The loops have some restrictions on what can be used, but they are > intended to be small and simple so it's not generally a problem: > - Don't use cpu_relax. > - Don't use return or goto. > - Don't use sleeping or spinning primitives.

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

> While I can agree on making Linux stuff less fatty, I can't agree on > doing this way. We have for now two subsystems to serve for serial > devices, you are proposing third one for only narrow class of devices. It should be actually most (all?) real serial ones. > From my point of view is

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

> While I can agree on making Linux stuff less fatty, I can't agree on > doing this way. We have for now two subsystems to serve for serial > devices, you are proposing third one for only narrow class of devices. It should be actually most (all?) real serial ones. > From my point of view is

Re: [RFC][PATCHv2 7/8] printk: add printk emergency_mode parameter

On Wed 2017-03-29 18:25:10, Sergey Senozhatsky wrote: > This param permits user-space to forcibly on/off printk emergency > mode via /sys/module/printk/parameters/emergency_mode node. > > We have annotated sections in the kernel that switch printk to > emergency, but there might be places/cases

Re: [RFC][PATCHv2 7/8] printk: add printk emergency_mode parameter

On Wed 2017-03-29 18:25:10, Sergey Senozhatsky wrote: > This param permits user-space to forcibly on/off printk emergency > mode via /sys/module/printk/parameters/emergency_mode node. > > We have annotated sections in the kernel that switch printk to > emergency, but there might be places/cases

Re: [PATCH 1/5] locking: Introduce range reader/writer lock

On Mon, 03 Apr 2017, Laurent Dufour wrote: Le Tue, 28 Mar 2017 09:39:18 -0700, Davidlohr Bueso a écrit : I'll wait to see if there are any more concerns and send a v2 with your corrections. Hi Bavidlohr, I think there is a major issue regarding the task catching a signal

Re: [PATCH 1/5] locking: Introduce range reader/writer lock

On Mon, 03 Apr 2017, Laurent Dufour wrote: Le Tue, 28 Mar 2017 09:39:18 -0700, Davidlohr Bueso a écrit : I'll wait to see if there are any more concerns and send a v2 with your corrections. Hi Bavidlohr, I think there is a major issue regarding the task catching a signal in

Re: [PATCH] Input: silead - list all supported compatible strings in binding document

On Wed, Mar 29, 2017 at 02:25:31PM -0400, Javier Martinez Canillas wrote: > The driver contains compatible strings for different models, but the DT > binding doc only lists one of them. Add the remaining to the document. > > Signed-off-by: Javier Martinez Canillas > --- >

Re: [PATCH] Input: silead - list all supported compatible strings in binding document

On Wed, Mar 29, 2017 at 02:25:31PM -0400, Javier Martinez Canillas wrote: > The driver contains compatible strings for different models, but the DT > binding doc only lists one of them. Add the remaining to the document. > > Signed-off-by: Javier Martinez Canillas > --- > >

Re: [PATCH v4 12/23] drivers/fsi: Add documentation for GPIO bindings

On Wed, Mar 29, 2017 at 12:43:29PM -0500, Christopher Bostic wrote: > From: Chris Bostic > > Add fsi master gpio device tree binding documentation > > Signed-off-by: Chris Bostic > Signed-off-by: Joel Stanley > --- >

Re: [PATCH v4 12/23] drivers/fsi: Add documentation for GPIO bindings

On Wed, Mar 29, 2017 at 12:43:29PM -0500, Christopher Bostic wrote: > From: Chris Bostic > > Add fsi master gpio device tree binding documentation > > Signed-off-by: Chris Bostic > Signed-off-by: Joel Stanley > --- > .../devicetree/bindings/fsi/fsi-master-gpio.txt| 24 >

Re: [BUG nohz]: wrong user and system time accounting

On Fri, Mar 31, 2017 at 11:11:19PM -0400, Luiz Capitulino wrote: > On Sat, 1 Apr 2017 01:24:54 +0200 > Frederic Weisbecker wrote: > > > On Fri, Mar 31, 2017 at 04:09:10PM -0400, Luiz Capitulino wrote: > > > On Thu, 30 Mar 2017 17:25:46 -0400 > > > Luiz Capitulino

Re: [PATCH v1] reset: Make optional stuff optional for all users

On Mon, 2017-04-03 at 17:09 +0200, Philipp Zabel wrote: > On Mon, 2017-04-03 at 14:33 +, Shevchenko, Andriy wrote: > > On Mon, 2017-04-03 at 17:31 +0300, Andy Shevchenko wrote: > > > On Mon, 2017-04-03 at 16:27 +0200, Philipp Zabel wrote: > > > > > > > > >   int rstc_id; > > > > >  

Re: [BUG nohz]: wrong user and system time accounting

On Fri, Mar 31, 2017 at 11:11:19PM -0400, Luiz Capitulino wrote: > On Sat, 1 Apr 2017 01:24:54 +0200 > Frederic Weisbecker wrote: > > > On Fri, Mar 31, 2017 at 04:09:10PM -0400, Luiz Capitulino wrote: > > > On Thu, 30 Mar 2017 17:25:46 -0400 > > > Luiz Capitulino wrote: > > > > > > > On Thu,

Re: [PATCH v1] reset: Make optional stuff optional for all users

On Mon, 2017-04-03 at 17:09 +0200, Philipp Zabel wrote: > On Mon, 2017-04-03 at 14:33 +, Shevchenko, Andriy wrote: > > On Mon, 2017-04-03 at 17:31 +0300, Andy Shevchenko wrote: > > > On Mon, 2017-04-03 at 16:27 +0200, Philipp Zabel wrote: > > > > > > > > >   int rstc_id; > > > > >  

[RFC 0/9] ARMv8.3 pointer authentication userspace support

This series adds support for the ARMv8.3 pointer authentication extension. I've included a quick intro to the extension below, with the usual series description below that. The final patch of the series adds additional documentation regarding the extension. I've based the series on the arm64

[RFC 0/9] ARMv8.3 pointer authentication userspace support

This series adds support for the ARMv8.3 pointer authentication extension. I've included a quick intro to the extension below, with the usual series description below that. The final patch of the series adds additional documentation regarding the extension. I've based the series on the arm64

[RFC 7/9] arm64: expose PAC bit positions via ptrace

When pointer authentication is in use, data/instruction pointers have a number of PAC bits inserted into them. The number and position of these bits depends on the configured TCR_ELx.TxSZ and whether tagging is enabled. ARMv8.3 allows tagging to differ for instruction and data pointers. For

[RFC 2/9] arm64: add pointer authentication register bits

The ARMv8.3 pointer authentication extension adds: * New fields in ID_AA64ISAR1 to report the presence of pointer authentication functionality. * New control bits in SCTLR_ELx to enable this functionality. * New system registers to hold the keys necessary for this functionality. * A new

[RFC 7/9] arm64: expose PAC bit positions via ptrace

When pointer authentication is in use, data/instruction pointers have a number of PAC bits inserted into them. The number and position of these bits depends on the configured TCR_ELx.TxSZ and whether tagging is enabled. ARMv8.3 allows tagging to differ for instruction and data pointers. For

[RFC 2/9] arm64: add pointer authentication register bits

The ARMv8.3 pointer authentication extension adds: * New fields in ID_AA64ISAR1 to report the presence of pointer authentication functionality. * New control bits in SCTLR_ELx to enable this functionality. * New system registers to hold the keys necessary for this functionality. * A new

Re: [patch RT 1/4] rtmutex: Make lock_killable work

On Sat, 01 Apr 2017 12:50:59 +0200 Thomas Gleixner wrote: > Locking an rt mutex killable does not work because signal handling is > restricted to TASK_INTERRUPTIBLE. > > Use signal_pending_state() unconditionaly. Does this mean rt mutex killable is not INTERRUPTIBLE?

Re: [patch RT 1/4] rtmutex: Make lock_killable work

On Sat, 01 Apr 2017 12:50:59 +0200 Thomas Gleixner wrote: > Locking an rt mutex killable does not work because signal handling is > restricted to TASK_INTERRUPTIBLE. > > Use signal_pending_state() unconditionaly. Does this mean rt mutex killable is not INTERRUPTIBLE? because the change log

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