Re: [PATCH 2/2] kthread: don't use to_live_kthread() in kthread_park() and kthread_unpark()

On Mon, 31 Oct 2016, Oleg Nesterov wrote: > I think we need to unexport kthread_park/unpark, and either make it return > "void" or actually fix the race with kthred_stop/exit. This patch just adds > WARN_ON(PF_EXITING) for now. I'll have a look. > The usage of kthread_park() in cpuhp code

Re: [PATCH 2/2] kthread: don't use to_live_kthread() in kthread_park() and kthread_unpark()

On Mon, 31 Oct 2016, Oleg Nesterov wrote: > I think we need to unexport kthread_park/unpark, and either make it return > "void" or actually fix the race with kthred_stop/exit. This patch just adds > WARN_ON(PF_EXITING) for now. I'll have a look. > The usage of kthread_park() in cpuhp code

Re: [PATCH] arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers

Hi Marcin, On mar., nov. 08 2016, Thomas Petazzoni wrote: > Hello, > > On Tue, 8 Nov 2016 17:31:32 +0100, Marcin Wojtas wrote: >> Enabling SPI controllers, which are attached to different busses >> inside an SoC, may result in overlapping enumeration and

Re: [PATCH] arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers

Hi Marcin, On mar., nov. 08 2016, Thomas Petazzoni wrote: > Hello, > > On Tue, 8 Nov 2016 17:31:32 +0100, Marcin Wojtas wrote: >> Enabling SPI controllers, which are attached to different busses >> inside an SoC, may result in overlapping enumeration and cause >> sysfs registration failure.

Re: [PATCH] ACPI / gpio: avoid warning for gpio hogging code

On Tue, Nov 8, 2016 at 2:40 PM, Arnd Bergmann wrote: > The newly added acpi_gpiochip_scan_gpios function produces a few harmless > warnings: > > drivers/gpio/gpiolib-acpi.c: In function ‘acpi_gpiochip_add’: > drivers/gpio/gpiolib-acpi.c:925:7: error: ‘dflags’ may be used

Re: [PATCH v4 1/3] leds: Introduce userspace leds driver

Hi, On 11/09/2016 08:05 AM, Pavel Machek wrote: Hi! +struct uleds_device { + struct uleds_user_dev user_dev; + struct led_classdev led_cdev; + struct mutexmutex; + enum uleds_statestate; + wait_queue_head_t waitq; + unsigned

Re: [PATCH] ACPI / gpio: avoid warning for gpio hogging code

On Tue, Nov 8, 2016 at 2:40 PM, Arnd Bergmann wrote: > The newly added acpi_gpiochip_scan_gpios function produces a few harmless > warnings: > > drivers/gpio/gpiolib-acpi.c: In function ‘acpi_gpiochip_add’: > drivers/gpio/gpiolib-acpi.c:925:7: error: ‘dflags’ may be used uninitialized > in this

Re: [PATCH v4 1/3] leds: Introduce userspace leds driver

Hi, On 11/09/2016 08:05 AM, Pavel Machek wrote: Hi! +struct uleds_device { + struct uleds_user_dev user_dev; + struct led_classdev led_cdev; + struct mutexmutex; + enum uleds_statestate; + wait_queue_head_t waitq; + unsigned

[PATCH v4 2/2] pinctrl: samsung: Add GPF support for Exynos5433

This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need to support the multiple memory map because the registers of GPFx are located in the different domain. Cc: Linus Walleij Cc: Rob Herring Cc: Mark Rutland

Re: [PATCH 7/8] blk-wbt: add general throttling mechanism

On Tue 08-11-16 08:41:09, Jens Axboe wrote: > On Tue, Nov 08 2016, Jan Kara wrote: > > On Tue 01-11-16 15:08:50, Jens Axboe wrote: > > > We can hook this up to the block layer, to help throttle buffered > > > writes. > > > > > > wbt registers a few trace points that can be used to track what is >

Re: [PATCH 7/8] blk-wbt: add general throttling mechanism

On Tue 08-11-16 08:41:09, Jens Axboe wrote: > On Tue, Nov 08 2016, Jan Kara wrote: > > On Tue 01-11-16 15:08:50, Jens Axboe wrote: > > > We can hook this up to the block layer, to help throttle buffered > > > writes. > > > > > > wbt registers a few trace points that can be used to track what is >

[PATCH v4 2/2] pinctrl: samsung: Add GPF support for Exynos5433

This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need to support the multiple memory map because the registers of GPFx are located in the different domain. Cc: Linus Walleij Cc: Rob Herring Cc: Mark Rutland Cc: Tomasz Figa Cc: Krzysztof Kozlowski Cc: Sylwester Nawrocki

[PATCH v4 1/2] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank

This patch supports the multiple IORESOURCE_MEM resources for one pin-bank. In the pre-existing Exynos series, the registers of the gpio bank are included in the one memory map. But, some gpio bank need to support the one more memory map (IORESOURCE_MEM) because the registers of gpio bank are

[PATCH v4 1/2] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank

This patch supports the multiple IORESOURCE_MEM resources for one pin-bank. In the pre-existing Exynos series, the registers of the gpio bank are included in the one memory map. But, some gpio bank need to support the one more memory map (IORESOURCE_MEM) because the registers of gpio bank are

[PATCH v4 0/2] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM

This patches support the multiple IORESOURCE_MEM resources for one pin-bank to support tye GPF of Samsung 64-bit Exynos5433 SoC. The exynos5433 device-tree patches were already merged. Changes from v3: - Merged the Exynos5433, TM2/TM2E Device-tree patch. - Fix the build error of

[PATCH v4 0/2] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM

This patches support the multiple IORESOURCE_MEM resources for one pin-bank to support tye GPF of Samsung 64-bit Exynos5433 SoC. The exynos5433 device-tree patches were already merged. Changes from v3: - Merged the Exynos5433, TM2/TM2E Device-tree patch. - Fix the build error of

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

Am Dienstag, 8. November 2016, 16:17:59 CET schrieb Martin Steigerwald: > Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald: > > Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula: > > > On Mon, 07 Nov 2016, Martin Steigerwald wrote: > > > > It

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

Am Dienstag, 8. November 2016, 16:17:59 CET schrieb Martin Steigerwald: > Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald: > > Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula: > > > On Mon, 07 Nov 2016, Martin Steigerwald wrote: > > > > It is also the same

Re: [PATCH] gpio: davinci: Use unique labels for each gpio chip

On Thu, Nov 3, 2016 at 12:34 PM, Axel Haslam wrote: > The gpiod framework uses the chip label to match a specific chip. > The davinci gpio driver, creates several chips using always the same > label, which is not compatible with gpiod. > > To allow platform data to declare

Re: [PATCH] gpio: davinci: Use unique labels for each gpio chip

On Thu, Nov 3, 2016 at 12:34 PM, Axel Haslam wrote: > The gpiod framework uses the chip label to match a specific chip. > The davinci gpio driver, creates several chips using always the same > label, which is not compatible with gpiod. > > To allow platform data to declare gpio lookup tables,

Re: [PATCH] wireless: fix bogus maybe-uninitialized warning

> Ideally we prefer that drivers/net/wireless and net/wireless changes > are > split into different patches as they get applied to different trees. > Johannes, is it ok if I take this change through my tree this time? Sure, please do, thanks. (I don't particularly care about the lib80211 stuff

Re: [PATCH] wireless: fix bogus maybe-uninitialized warning

> Ideally we prefer that drivers/net/wireless and net/wireless changes > are > split into different patches as they get applied to different trees. > Johannes, is it ok if I take this change through my tree this time? Sure, please do, thanks. (I don't particularly care about the lib80211 stuff

Re: [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards

I would expect that VCO clock will force recalculation for all its children if I am not mistaken. 2016-11-08 17:19 GMT+01:00 Gabriel Fernandez : > On 11/08/2016 09:52 AM, Radosław Pietrzyk wrote: >> >> 2016-11-08 9:35 GMT+01:00 Gabriel Fernandez

Re: [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards

I would expect that VCO clock will force recalculation for all its children if I am not mistaken. 2016-11-08 17:19 GMT+01:00 Gabriel Fernandez : > On 11/08/2016 09:52 AM, Radosław Pietrzyk wrote: >> >> 2016-11-08 9:35 GMT+01:00 Gabriel Fernandez : >>> >>> Hi Radosław >>> >>> Many thanks for

Re: [PATCH] drivers: tca8418: Change the interrupt type

Hello Dmitry, On Tue, Nov 08, 2016 at 04:04:00PM -0800, Dmitry Torokhov wrote: > On Mon, Nov 07, 2016 at 03:40:24PM +0100, Maxime Ripard wrote: > > The TCA8418 interrupt has a level trigger, not a edge one. > > > > Signed-off-by: Maxime Ripard > > Hmm, maybe

Re: [PATCH] drivers: tca8418: Change the interrupt type

Hello Dmitry, On Tue, Nov 08, 2016 at 04:04:00PM -0800, Dmitry Torokhov wrote: > On Mon, Nov 07, 2016 at 03:40:24PM +0100, Maxime Ripard wrote: > > The TCA8418 interrupt has a level trigger, not a edge one. > > > > Signed-off-by: Maxime Ripard > > Hmm, maybe we could rely on OF data for

Re: BUG: 'list_empty(>free_vbufs)' is true!

On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > > Hi, > > > > I can relatively easily reproduce this bug: How? > > BUG: 'list_empty(>free_vbufs)' is true! > The following might be helpful for debugging - if kernel

Re: BUG: 'list_empty(>free_vbufs)' is true!

On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > > Hi, > > > > I can relatively easily reproduce this bug: How? > > BUG: 'list_empty(>free_vbufs)' is true! > The following might be helpful for debugging - if kernel

Re: [PATCH 1/2] kthread: don't use to_live_kthread() in kthread_stop()

On Mon, 31 Oct 2016, Oleg Nesterov wrote: > kthread_stop() had to use to_live_kthread() simply because it was not > possible to access kthread->exited after the exiting kthread clears > task_struct->vfork_done. Now that to_kthread() is always valid we can > do wake_up_process() +

Re: [PATCH 1/2] kthread: don't use to_live_kthread() in kthread_stop()

On Mon, 31 Oct 2016, Oleg Nesterov wrote: > kthread_stop() had to use to_live_kthread() simply because it was not > possible to access kthread->exited after the exiting kthread clears > task_struct->vfork_done. Now that to_kthread() is always valid we can > do wake_up_process() +

<    15   16   17   18   19   20