[PATCH v3 05/13] ARM: dts: sun8i-a83t: add mmc clock nodes

mmc clocks are compatible with that of earlier sun8i socs. This adds mmc0, mmc1, and mmc2 clock nodes for A83T. Signed-off-by: Vishnu Patekar Acked-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 30 ++ 1 file

[PATCH v3 02/13] clk: sunxi: add ahb1 clock for A83T

AHB1 on A83T is similar to ahb1 on A31, except parents are different. clock index 0b1x is PLL6. Signed-off-by: Vishnu Patekar Acked-by: Chen-Yu Tsai Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/sunxi.txt | 1 +

[PATCH v3 03/13] clk: sunxi: Add APB1 clock for A83T

APB1 is similar to sun4i-a10-apb0-clk, except different dividers. This adds support for apb1 on A83T. Signed-off-by: Vishnu Patekar Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/sunxi.txt | 1 + drivers/clk/sunxi/clk-sunxi.c | 13 + 2 files

[PATCH v3 04/13] ARM: dts: sun8i-a83t: Add basic clocks and resets

This adds A83T system bus clocks, bus gates, and clock resets. Three ahb reset registers are combined into one node. Signed-off-by: Vishnu Patekar --- arch/arm/boot/dts/sun8i-a83t.dtsi | 114 +- 1 file changed, 112 insertions(+), 2 deletions(-) diff --git

[PATCH v3 05/13] ARM: dts: sun8i-a83t: add mmc clock nodes

mmc clocks are compatible with that of earlier sun8i socs. This adds mmc0, mmc1, and mmc2 clock nodes for A83T. Signed-off-by: Vishnu Patekar Acked-by: Chen-Yu Tsai --- arch/arm/boot/dts/sun8i-a83t.dtsi | 30 ++ 1 file changed, 30 insertions(+) diff --git

[PATCH v3 02/13] clk: sunxi: add ahb1 clock for A83T

AHB1 on A83T is similar to ahb1 on A31, except parents are different. clock index 0b1x is PLL6. Signed-off-by: Vishnu Patekar Acked-by: Chen-Yu Tsai Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/sunxi.txt | 1 + drivers/clk/sunxi/clk-sunxi.c | 76

[PATCH v3 01/13] pinctrl: sunxi: Add A83T R_PIO controller support

The A83T has R_PIO pin controller, it's same as A23, execpt A83T interrupt bit is 6th and A83T has one extra pin PL12. Signed-off-by: Vishnu Patekar Acked-by: Chen-Yu Tsai Acked-by: Rob Herring ---

[PATCH v3 00/13] Add A83T clk, r_pio, mmc rsb support

Hello, This is v3 of series which adds further support for A83T, mainly adds clock support.Also adds R_PIO, PRCM related clocks, mmc, rsb support. A83T difference in short: R_PIO is slightly different from A23 r_pio. AHB1 has different parents as compared to a31-ahb1, APB1 has different

[PATCH v3 01/13] pinctrl: sunxi: Add A83T R_PIO controller support

The A83T has R_PIO pin controller, it's same as A23, execpt A83T interrupt bit is 6th and A83T has one extra pin PL12. Signed-off-by: Vishnu Patekar Acked-by: Chen-Yu Tsai Acked-by: Rob Herring --- .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + drivers/pinctrl/sunxi/Kconfig

[PATCH v3 00/13] Add A83T clk, r_pio, mmc rsb support

Hello, This is v3 of series which adds further support for A83T, mainly adds clock support.Also adds R_PIO, PRCM related clocks, mmc, rsb support. A83T difference in short: R_PIO is slightly different from A23 r_pio. AHB1 has different parents as compared to a31-ahb1, APB1 has different

[PATCH] memremap: check pfn validity before passing to pfn_to_page()

In memremap's helper function try_ram_remap(), we dereference a struct page pointer that was derived from a PFN that is known to be covered by a 'System RAM' iomem region, and is thus assumed to be a 'valid' PFN, i.e., a PFN that has a struct page associated with it and is covered by the kernel

[PATCH] memremap: check pfn validity before passing to pfn_to_page()

In memremap's helper function try_ram_remap(), we dereference a struct page pointer that was derived from a PFN that is known to be covered by a 'System RAM' iomem region, and is thus assumed to be a 'valid' PFN, i.e., a PFN that has a struct page associated with it and is covered by the kernel

Re: [PATCH v2 2/2] spi: spi-pic32: Add PIC32 SPI master driver

On 03/05/2016 09:10 AM, Mark Brown wrote: > On Fri, Mar 04, 2016 at 07:14:42PM +0530, Purna Chandra Mandal wrote: >> The PIC32 SPI driver is capable of performing SPI transfers >> using PIO or external DMA engine. GPIO controlled /CS support > I don't seem to have patch 1 in this series. Sorry

Re: [PATCH v2 2/2] spi: spi-pic32: Add PIC32 SPI master driver

On 03/05/2016 09:10 AM, Mark Brown wrote: > On Fri, Mar 04, 2016 at 07:14:42PM +0530, Purna Chandra Mandal wrote: >> The PIC32 SPI driver is capable of performing SPI transfers >> using PIO or external DMA engine. GPIO controlled /CS support > I don't seem to have patch 1 in this series. Sorry

[PATCH] ACPICA: Events: Execute some _REG methods in early boot

The regression caused _REG methods to not be run in early boot for all space IDs, but a removed comment stated that _REG methods should be executed for IDs like embedded_controller. Before the regression this was the case: [0.230469] Executing Method \_SB.PCI0.LPCB.EC._REG [

[PATCH] ACPICA: Events: Execute some _REG methods in early boot

The regression caused _REG methods to not be run in early boot for all space IDs, but a removed comment stated that _REG methods should be executed for IDs like embedded_controller. Before the regression this was the case: [0.230469] Executing Method \_SB.PCI0.LPCB.EC._REG [

Re: [PATCH 3/3] iio:adc:at91-sama5d2: add support for signed conversion

On 03/03/16 16:09, Ludovic Desroches wrote: > The at91-sama5d2 ADC controller can achieve unsigned and signed > conversion. For each channel, a signed and an unsigned variant are > created. > We can't set the sign mode for each channel. For that reason, the > controller has to be configured upon

Re: [PATCH 3/3] iio:adc:at91-sama5d2: add support for signed conversion

On 03/03/16 16:09, Ludovic Desroches wrote: > The at91-sama5d2 ADC controller can achieve unsigned and signed > conversion. For each channel, a signed and an unsigned variant are > created. > We can't set the sign mode for each channel. For that reason, the > controller has to be configured upon

Re: [PATCH 2/3] iio:adc:at91-sama5d2: fix identation

On 03/03/16 16:09, Ludovic Desroches wrote: > Remove some extra tabs. > > Signed-off-by: Ludovic Desroches I find it hard to care about this sort of patch, but whatever. Applied to the togreg branch of iio.git - pushed out as testing.. etc etc. Jonathan > --- >

Re: [PATCH 2/3] iio:adc:at91-sama5d2: fix identation

On 03/03/16 16:09, Ludovic Desroches wrote: > Remove some extra tabs. > > Signed-off-by: Ludovic Desroches I find it hard to care about this sort of patch, but whatever. Applied to the togreg branch of iio.git - pushed out as testing.. etc etc. Jonathan > --- >

Re: [PATCH 1/3] iio:adc:at91-sama5d2: fix typo

On 03/03/16 16:09, Ludovic Desroches wrote: > Fix typo in the name of a macro. > > Signed-off-by: Ludovic Desroches Oops ;) Applied to the togreg branch of iio.git - initially pushed out as testing for the autobuilders to play with it. Not sure if I will be doing

Re: [PATCH 1/3] iio:adc:at91-sama5d2: fix typo

On 03/03/16 16:09, Ludovic Desroches wrote: > Fix typo in the name of a macro. > > Signed-off-by: Ludovic Desroches Oops ;) Applied to the togreg branch of iio.git - initially pushed out as testing for the autobuilders to play with it. Not sure if I will be doing another pull request to Greg

Re: [PATCH 1/2] ASoC: cs35l32: avoid uninitialized variable access

On Mon, Jan 25, 2016 at 06:07:32PM +0100, Arnd Bergmann wrote: > gcc warns about the possibilty of accessing a property read from > devicetree in cs35l32_i2c_probe() when it has not been initialized > because CONFIG_OF is disabled: > > sound/soc/codecs/cs35l32.c: In function 'cs35l32_i2c_probe':

Re: [PATCH 1/2] ASoC: cs35l32: avoid uninitialized variable access

On Mon, Jan 25, 2016 at 06:07:32PM +0100, Arnd Bergmann wrote: > gcc warns about the possibilty of accessing a property read from > devicetree in cs35l32_i2c_probe() when it has not been initialized > because CONFIG_OF is disabled: > > sound/soc/codecs/cs35l32.c: In function 'cs35l32_i2c_probe':

[PATCH] sc16is7xx: remove useless "uart_handle_cts_change"

SC16is7xx has feature for auto hardware flow control using RTS/CTS, so we don't need "uart_handle_cts_change" to invoke "start_tx/stop_tx" for flow control. In addition, for software CTS, interrupt "SC16IS7XX_IIR_CTSRTS_SRC" just report the nCTS change of state from active(low) to inactive(high),

[PATCH] sc16is7xx: remove useless "uart_handle_cts_change"

SC16is7xx has feature for auto hardware flow control using RTS/CTS, so we don't need "uart_handle_cts_change" to invoke "start_tx/stop_tx" for flow control. In addition, for software CTS, interrupt "SC16IS7XX_IIR_CTSRTS_SRC" just report the nCTS change of state from active(low) to inactive(high),

[tip:mm/pkeys] mm/pkeys: Fix siginfo ABI breakage caused by new u64 field

Commit-ID: 49cd53bf14aeb471c4a2682300dfc05ef2fd09f2 Gitweb: http://git.kernel.org/tip/49cd53bf14aeb471c4a2682300dfc05ef2fd09f2 Author: Dave Hansen AuthorDate: Tue, 1 Mar 2016 04:54:51 -0800 Committer: Ingo Molnar CommitDate: Sat, 5 Mar

[tip:mm/pkeys] mm/pkeys: Fix siginfo ABI breakage caused by new u64 field

Commit-ID: 49cd53bf14aeb471c4a2682300dfc05ef2fd09f2 Gitweb: http://git.kernel.org/tip/49cd53bf14aeb471c4a2682300dfc05ef2fd09f2 Author: Dave Hansen AuthorDate: Tue, 1 Mar 2016 04:54:51 -0800 Committer: Ingo Molnar CommitDate: Sat, 5 Mar 2016 15:00:06 +0100 mm/pkeys: Fix siginfo ABI

[tip:x86/mm] x86/mm/kmmio: Fix mmiotrace for hugepages

Commit-ID: cfa52c0cfa4d727aa3e457bf29aeff296c528a08 Gitweb: http://git.kernel.org/tip/cfa52c0cfa4d727aa3e457bf29aeff296c528a08 Author: Karol Herbst AuthorDate: Thu, 3 Mar 2016 02:03:11 +0100 Committer: Ingo Molnar CommitDate: Sat, 5 Mar 2016

[tip:x86/mm] x86/mm/kmmio: Fix mmiotrace for hugepages

Commit-ID: cfa52c0cfa4d727aa3e457bf29aeff296c528a08 Gitweb: http://git.kernel.org/tip/cfa52c0cfa4d727aa3e457bf29aeff296c528a08 Author: Karol Herbst AuthorDate: Thu, 3 Mar 2016 02:03:11 +0100 Committer: Ingo Molnar CommitDate: Sat, 5 Mar 2016 13:24:41 +0100 x86/mm/kmmio: Fix mmiotrace

Re: [PATCH] drm/gma500: Make mdfld_dsi_connector_dpms() return a value

* Ingo Molnar wrote: > as we have this in Makefile: > > # enforce correct pointer usage > KBUILD_CFLAGS += $(call cc-option,-Werror=incompatible-pointer-types) Sorry, never mind - this is a recent commit that is not upstream. So there's no upstream build regression.

Re: [PATCH] drm/gma500: Make mdfld_dsi_connector_dpms() return a value

* Ingo Molnar wrote: > as we have this in Makefile: > > # enforce correct pointer usage > KBUILD_CFLAGS += $(call cc-option,-Werror=incompatible-pointer-types) Sorry, never mind - this is a recent commit that is not upstream. So there's no upstream build regression. Thanks,

[GIT PULL for v4.5] media fixes

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.5-4 For: - some last time changes before we stablize the new entity function integer numbers at uAPI; - probe: fix erroneous return value on i2c/adp1653 driver. - fix tx 5v

[GIT PULL for v4.5] media fixes

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.5-4 For: - some last time changes before we stablize the new entity function integer numbers at uAPI; - probe: fix erroneous return value on i2c/adp1653 driver. - fix tx 5v

Re: [tip:mm/pkeys] mm/pkeys: Fix siginfo ABI breakage caused by new u64 field

* Linus Torvalds wrote: > On Thu, Mar 3, 2016 at 8:53 AM, tip-bot for Dave Hansen > wrote: > > > > If u64 has a natural alignment of 8 bytes (this is rare, most 32-bit > > platforms align it to 4 bytes), then the leadup to the _sifields union >

Re: [tip:mm/pkeys] mm/pkeys: Fix siginfo ABI breakage caused by new u64 field

* Linus Torvalds wrote: > On Thu, Mar 3, 2016 at 8:53 AM, tip-bot for Dave Hansen > wrote: > > > > If u64 has a natural alignment of 8 bytes (this is rare, most 32-bit > > platforms align it to 4 bytes), then the leadup to the _sifields union > > matters: > > Side note: I'm not sure that

Re: [PATCH] steal_account_process_tick() should return jiffies

On Sat, Mar 05, 2016 at 11:27:01AM +0100, Thomas Gleixner wrote: > Chris, > > On Fri, 4 Mar 2016, Chris Friesen wrote: > > First of all the subject line should contain a subsystem prefix, > i.e. "sched/cputime:" > > > The callers of steal_account_process_tick() expect it to return whether > >

Re: [PATCH] steal_account_process_tick() should return jiffies

On Sat, Mar 05, 2016 at 11:27:01AM +0100, Thomas Gleixner wrote: > Chris, > > On Fri, 4 Mar 2016, Chris Friesen wrote: > > First of all the subject line should contain a subsystem prefix, > i.e. "sched/cputime:" > > > The callers of steal_account_process_tick() expect it to return whether > >

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

Am 04.03.2016 um 17:18 schrieb Paul Bolle: > [Added Tilman and Christoph.] > > On vr, 2016-03-04 at 16:24 +0100, Arnd Bergmann wrote: >> I actually did more patches that I ended up not submitting: >> >> * move hisax to staging >> * remove i4l support from gigaset > > For the record: I have no

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

Am 04.03.2016 um 17:18 schrieb Paul Bolle: > [Added Tilman and Christoph.] > > On vr, 2016-03-04 at 16:24 +0100, Arnd Bergmann wrote: >> I actually did more patches that I ended up not submitting: >> >> * move hisax to staging >> * remove i4l support from gigaset > > For the record: I have no

Re: [PATCH] staging/android: add flags member to sync ioctl structs

Hi Greg, Allow me to chip in as well. On 3 March 2016 at 16:17, Greg Kroah-Hartman wrote: > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: >> From: Gustavo Padovan >> >> Play safe and add flags member to all

Re: [PATCH] staging/android: add flags member to sync ioctl structs

Hi Greg, Allow me to chip in as well. On 3 March 2016 at 16:17, Greg Kroah-Hartman wrote: > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: >> From: Gustavo Padovan >> >> Play safe and add flags member to all structs. So we don't need to >> break API or create new IOCTL in the

Re: [PATCHv9 1/3] rdmacg: Added rdma cgroup controller

Hello, Parav. On Sat, Mar 05, 2016 at 04:45:09PM +0530, Parav Pandit wrote: > Design that remains same from v6 to v10. > * spin lock is still fine grained at cgroup level instead of one > global shared lock among all cgroups. > In future it can be optimized further to do per cpu or using >

Re: [PATCHv9 1/3] rdmacg: Added rdma cgroup controller

Hello, Parav. On Sat, Mar 05, 2016 at 04:45:09PM +0530, Parav Pandit wrote: > Design that remains same from v6 to v10. > * spin lock is still fine grained at cgroup level instead of one > global shared lock among all cgroups. > In future it can be optimized further to do per cpu or using >

Re: [PATCH V4 3/6] slimbus: Add messaging APIs to slimbus framework

On Sat, Feb 06, 2016 at 11:44:22AM -0700, Sagar Dharia wrote: > + spin_lock_irqsave(>txn_lock, flags); > + msg = ctrl->tid_tbl[tid]; > + if (msg == NULL || msg->rbuf == NULL) { > + spin_unlock_irqrestore(>txn_lock, flags); > + dev_err(>dev, "Got response to

Re: [PATCH V4 6/6] slim: qcom: Add runtime-pm support using clock-pause feature

On Sat, Feb 06, 2016 at 11:44:25AM -0700, Sagar Dharia wrote: > @@ -253,6 +276,7 @@ static int msm_xfer_msg(struct slim_controller *ctrl, > struct slim_msg_txn *txn, > if (txn->msg && txn->msg->wbuf) > memcpy(puc, txn->msg->wbuf, txn->msg->num_bytes); > > + > return

Re: [PATCH V4 3/6] slimbus: Add messaging APIs to slimbus framework

On Sat, Feb 06, 2016 at 11:44:22AM -0700, Sagar Dharia wrote: > + spin_lock_irqsave(>txn_lock, flags); > + msg = ctrl->tid_tbl[tid]; > + if (msg == NULL || msg->rbuf == NULL) { > + spin_unlock_irqrestore(>txn_lock, flags); > + dev_err(>dev, "Got response to

Re: [PATCH V4 6/6] slim: qcom: Add runtime-pm support using clock-pause feature

On Sat, Feb 06, 2016 at 11:44:25AM -0700, Sagar Dharia wrote: > @@ -253,6 +276,7 @@ static int msm_xfer_msg(struct slim_controller *ctrl, > struct slim_msg_txn *txn, > if (txn->msg && txn->msg->wbuf) > memcpy(puc, txn->msg->wbuf, txn->msg->num_bytes); > > + > return

Re: [PATCH V4 0/6] Introduce framework for SLIMbus device drivers

On Sat, Feb 06, 2016 at 11:44:19AM -0700, Sagar Dharia wrote: > SLIMbus (Serial Low Power Interchip Media Bus) is a specification > developed by MIPI (Mobile Industry Processor Interface) alliance. > SLIMbus is a 2-wire implementation, which is used to communicate with > peripheral components like

Re: [PATCH V4 1/6] SLIMbus: Device management on SLIMbus

On Sat, Feb 06, 2016 at 11:44:20AM -0700, Sagar Dharia wrote: > +static void schedule_slim_report(struct slim_controller *ctrl, > + struct slim_device *sb, bool report) > +{ > + struct sb_report_wd *sbw; > + > + dev_dbg(>dev, "report:%d for slave:%s\n",

Re: [PATCH] drm/gma500: Make mdfld_dsi_connector_dpms() return a value

* Patrik Jakobsson wrote: > Hi Daniel, > > A patch to fix this is already merged into drm-misc: > > commit db9b60400f9253c25ae639797df2d0ff7a35d9d8 > Author: Sudip Mukherjee > Date: Tue Feb 2 11:35:55 2016 +0530 > > drm/gma500:

Re: [PATCH V4 0/6] Introduce framework for SLIMbus device drivers

On Sat, Feb 06, 2016 at 11:44:19AM -0700, Sagar Dharia wrote: > SLIMbus (Serial Low Power Interchip Media Bus) is a specification > developed by MIPI (Mobile Industry Processor Interface) alliance. > SLIMbus is a 2-wire implementation, which is used to communicate with > peripheral components like

Re: [PATCH V4 1/6] SLIMbus: Device management on SLIMbus

On Sat, Feb 06, 2016 at 11:44:20AM -0700, Sagar Dharia wrote: > +static void schedule_slim_report(struct slim_controller *ctrl, > + struct slim_device *sb, bool report) > +{ > + struct sb_report_wd *sbw; > + > + dev_dbg(>dev, "report:%d for slave:%s\n",

Re: [PATCH] drm/gma500: Make mdfld_dsi_connector_dpms() return a value

* Patrik Jakobsson wrote: > Hi Daniel, > > A patch to fix this is already merged into drm-misc: > > commit db9b60400f9253c25ae639797df2d0ff7a35d9d8 > Author: Sudip Mukherjee > Date: Tue Feb 2 11:35:55 2016 +0530 > > drm/gma500: remove helper function > > We were getting build

Re: [PATCH 1/2] ASoC: cs35l32: avoid uninitialized variable access

On Mon, Jan 25, 2016 at 06:07:32PM +0100, Arnd Bergmann wrote: > - if (i2c_client->dev.of_node) { > + if (IS_ENABLED(CONFIG_OF) && i2c_client->dev.of_node) { This feels it's going to be happening a lot and we should probably have a dev_has_of_node() helper that does the

Re: [PATCH v2 2/2] spi: spi-pic32: Add PIC32 SPI master driver

On Fri, Mar 04, 2016 at 07:14:42PM +0530, Purna Chandra Mandal wrote: > The PIC32 SPI driver is capable of performing SPI transfers > using PIO or external DMA engine. GPIO controlled /CS support I don't seem to have patch 1 in this series. signature.asc Description: PGP signature

Re: [PATCH V4 4/6] slim: qcom: Add Qualcomm Slimbus controller driver

On Sat, Feb 06, 2016 at 11:44:23AM -0700, Sagar Dharia wrote: > > +if SLIMBUS > +config SLIM_QCOM_CTRL > + tristate "Qualcomm Slimbus Manager Component" > + depends on SLIMBUS > + default n > + help n is the default. > +static irqreturn_t msm_slim_interrupt(int irq, void *d) >

Re: [PATCH 1/2] ASoC: cs35l32: avoid uninitialized variable access

On Mon, Jan 25, 2016 at 06:07:32PM +0100, Arnd Bergmann wrote: > - if (i2c_client->dev.of_node) { > + if (IS_ENABLED(CONFIG_OF) && i2c_client->dev.of_node) { This feels it's going to be happening a lot and we should probably have a dev_has_of_node() helper that does the

Re: [PATCH v2 2/2] spi: spi-pic32: Add PIC32 SPI master driver

On Fri, Mar 04, 2016 at 07:14:42PM +0530, Purna Chandra Mandal wrote: > The PIC32 SPI driver is capable of performing SPI transfers > using PIO or external DMA engine. GPIO controlled /CS support I don't seem to have patch 1 in this series. signature.asc Description: PGP signature

Re: [PATCH V4 4/6] slim: qcom: Add Qualcomm Slimbus controller driver

On Sat, Feb 06, 2016 at 11:44:23AM -0700, Sagar Dharia wrote: > > +if SLIMBUS > +config SLIM_QCOM_CTRL > + tristate "Qualcomm Slimbus Manager Component" > + depends on SLIMBUS > + default n > + help n is the default. > +static irqreturn_t msm_slim_interrupt(int irq, void *d) >

Re: [PATCH] spi/rockchip: Make sure spi clk is on in rockchip_spi_set_cs

On Fri, Feb 26, 2016 at 10:31:50AM +0800, Huang, Tao wrote: > You misunderstand me. I talk about spi_setup, as > Documentation/spi/spi-summary, which would normally be called from > probe() before the first I/O is done to the device. > spi_setup will call spi_set_cs(spi, false), which introduced

Re: [PATCH] spi/rockchip: Make sure spi clk is on in rockchip_spi_set_cs

On Fri, Feb 26, 2016 at 10:31:50AM +0800, Huang, Tao wrote: > You misunderstand me. I talk about spi_setup, as > Documentation/spi/spi-summary, which would normally be called from > probe() before the first I/O is done to the device. > spi_setup will call spi_set_cs(spi, false), which introduced

Re: [PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote: > On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote: > > The drm_encoder_cleanup() was missing both from the error path of > > dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was > > enabled and we ended up

Re: [PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote: > On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote: > > The drm_encoder_cleanup() was missing both from the error path of > > dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was > > enabled and we ended up

Re: [PATCH v10 05/12] task_isolation: support CONFIG_TASK_ISOLATION_ALL

* Chris Metcalf wrote: > On 03/03/2016 01:34 PM, Andi Kleen wrote: > >Chris Metcalf writes: > >>+config TASK_ISOLATION_ALL > >>+ bool "Provide task isolation on all CPUs by default (except CPU 0)" > >>+ depends on TASK_ISOLATION > >>+ help >

Re: [PATCH v10 05/12] task_isolation: support CONFIG_TASK_ISOLATION_ALL

* Chris Metcalf wrote: > On 03/03/2016 01:34 PM, Andi Kleen wrote: > >Chris Metcalf writes: > >>+config TASK_ISOLATION_ALL > >>+ bool "Provide task isolation on all CPUs by default (except CPU 0)" > >>+ depends on TASK_ISOLATION > >>+ help > >>+If the user doesn't pass the

Applied "regulator: max8973: add support for junction thermal warning" to the regulator tree

The patch regulator: max8973: add support for junction thermal warning has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regulator: max8973: add support for junction thermal warning" to the regulator tree

The patch regulator: max8973: add support for junction thermal warning has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "regmap: irq: add devm apis for regmap_{add,del}_irq_chip" to the regmap tree

The patch regmap: irq: add devm apis for regmap_{add,del}_irq_chip has been applied to the regmap tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regmap: replace regmap_write_bits()" to the regmap tree

The patch regmap: replace regmap_write_bits() has been applied to the regmap tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "regulator: max8973: add DT binding details for junction warn temp" to the regulator tree

The patch regulator: max8973: add DT binding details for junction warn temp has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in

Applied "regmap: irq: add devm apis for regmap_{add,del}_irq_chip" to the regmap tree

The patch regmap: irq: add devm apis for regmap_{add,del}_irq_chip has been applied to the regmap tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "regulator: max8973: add DT binding details for junction warn temp" to the regulator tree

The patch regulator: max8973: add DT binding details for junction warn temp has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in

Applied "regmap: replace regmap_write_bits()" to the regmap tree

The patch regmap: replace regmap_write_bits() has been applied to the regmap tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler

On Sat, Mar 5, 2016 at 12:39 AM, Christoph Hellwig wrote: > Btw, can someone explain why you guys waste so much time hacking and > arguing about a legacy codebase (old request code and I/O schedulers) > that everyone would really like to see disappear. Why don't you > spend

Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler

On Sat, Mar 5, 2016 at 12:39 AM, Christoph Hellwig wrote: > Btw, can someone explain why you guys waste so much time hacking and > arguing about a legacy codebase (old request code and I/O schedulers) > that everyone would really like to see disappear. Why don't you > spend your time on blk-mq

Re: [PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote: > The drm_encoder_cleanup() was missing both from the error path of > dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was > enabled and we ended up deferring probe of HDMI at boot. > > This call isn't needed from

Re: [PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote: > The drm_encoder_cleanup() was missing both from the error path of > dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was > enabled and we ended up deferring probe of HDMI at boot. > > This call isn't needed from

Re: [PATCH] [media] hide unused functions for !MEDIA_CONTROLLER

Em Fri, 4 Mar 2016 17:34:43 -0700 Shuah Khan escreveu: > On 03/04/2016 05:06 PM, Arnd Bergmann wrote: > > Some functions in the au0828 driver are only used when > > CONFIG_MEDIA_CONTROLLER > > is enabled, and otherwise defined as empty functions: > > > >

Re: [PATCH] [media] hide unused functions for !MEDIA_CONTROLLER

Em Fri, 4 Mar 2016 17:34:43 -0700 Shuah Khan escreveu: > On 03/04/2016 05:06 PM, Arnd Bergmann wrote: > > Some functions in the au0828 driver are only used when > > CONFIG_MEDIA_CONTROLLER > > is enabled, and otherwise defined as empty functions: > > > > media/usb/au0828/au0828-core.c:208:13:

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

* Rafael J. Wysocki wrote: > > Honestly I wonder if it's better to just try the "no notifiers with fast > > drivers" approach to start. The notifiers could always be added if platform > > owners complain that they absolutely require them. > > Well, I'm not sure what

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

* Rafael J. Wysocki wrote: > > Honestly I wonder if it's better to just try the "no notifiers with fast > > drivers" approach to start. The notifiers could always be added if platform > > owners complain that they absolutely require them. > > Well, I'm not sure what happens if we start to

Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"

* Luis R. Rodriguez wrote: > The current documentation refers to using set_memory_wc() as a > possible hole strategy when you have overlapping ioremap() regions, The whole explanation should talk about virtual aliases over the same physical address, not some 'overlapping

Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"

* Luis R. Rodriguez wrote: > The current documentation refers to using set_memory_wc() as a > possible hole strategy when you have overlapping ioremap() regions, The whole explanation should talk about virtual aliases over the same physical address, not some 'overlapping regions'. I see

Re: Overlapping ioremap() calls, set_memory_*() semantics

* Luis R. Rodriguez wrote: > On Fri, Mar 4, 2016 at 10:18 AM, Toshi Kani wrote: > > On Fri, 2016-03-04 at 10:44 +0100, Ingo Molnar wrote: > >> * Luis R. Rodriguez wrote: > >> > >> Could you outline a specific case where it's done

Re: Overlapping ioremap() calls, set_memory_*() semantics

* Luis R. Rodriguez wrote: > On Fri, Mar 4, 2016 at 10:18 AM, Toshi Kani wrote: > > On Fri, 2016-03-04 at 10:44 +0100, Ingo Molnar wrote: > >> * Luis R. Rodriguez wrote: > >> > >> Could you outline a specific case where it's done intentionally - and the > >> purpose behind that intention? > >

Re: Overlapping ioremap() calls, set_memory_*() semantics

* Toshi Kani wrote: > > So I'd say that since ioremap() in itself is fragile enough, we should work > > towards eliminating overlapping ranges. > > > > The thing is, the whole vmap_area logic is based around non-overlapping > > ranges, sorted into the vmap_area_root

Re: Overlapping ioremap() calls, set_memory_*() semantics

* Toshi Kani wrote: > > So I'd say that since ioremap() in itself is fragile enough, we should work > > towards eliminating overlapping ranges. > > > > The thing is, the whole vmap_area logic is based around non-overlapping > > ranges, sorted into the vmap_area_root rbtree. > > > > Just

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

On 03/05/2016 07:12 AM, David Rivshin (Allworx) wrote: On Fri, 04 Mar 2016 16:38:01 +0100 Jacek Anaszewski wrote: On 03/04/2016 03:27 PM, David Rivshin (Allworx) wrote: (Stefan, sorry for the duplicate, I just realized that I originally replied only to you by

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

On 03/05/2016 07:12 AM, David Rivshin (Allworx) wrote: On Fri, 04 Mar 2016 16:38:01 +0100 Jacek Anaszewski wrote: On 03/04/2016 03:27 PM, David Rivshin (Allworx) wrote: (Stefan, sorry for the duplicate, I just realized that I originally replied only to you by accident). On Thu, 3 Mar 2016

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

On 03/05/2016 06:29 AM, David Rivshin (Allworx) wrote: On Fri, 4 Mar 2016 22:39:06 +0100 Jacek Anaszewski wrote: On 03/04/2016 08:02 PM, David Rivshin (Allworx) wrote: On Fri, 04 Mar 2016 17:01:52 +0100 Jacek Anaszewski wrote: On

Re: [PATCH 4/4] leds: Replace dedicated SN3218 driver with IS31FL32XX driver

On 03/05/2016 06:34 AM, David Rivshin (Allworx) wrote: On Thu, 03 Mar 2016 15:51:36 +0100 Jacek Anaszewski wrote: Hi David, I'll wait for Tested-by from Stefan before applying this patch. If Stefan will have managed to test your driver with his hardware by the end

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

On 03/05/2016 06:29 AM, David Rivshin (Allworx) wrote: On Fri, 4 Mar 2016 22:39:06 +0100 Jacek Anaszewski wrote: On 03/04/2016 08:02 PM, David Rivshin (Allworx) wrote: On Fri, 04 Mar 2016 17:01:52 +0100 Jacek Anaszewski wrote: On 03/04/2016 04:05 PM, David Rivshin (Allworx) wrote: On

Re: [PATCH 4/4] leds: Replace dedicated SN3218 driver with IS31FL32XX driver

On 03/05/2016 06:34 AM, David Rivshin (Allworx) wrote: On Thu, 03 Mar 2016 15:51:36 +0100 Jacek Anaszewski wrote: Hi David, I'll wait for Tested-by from Stefan before applying this patch. If Stefan will have managed to test your driver with his hardware by the end of this cycle, it will

Re: Fix preempt-rt on AT91

Hi Sebastian, On 18/01/2016 at 18:42:59 +0100, Sebastian Andrzej Siewior wrote : > > 3/ Finally, the kernel will crash when initializing the PMC driver. This is > > solved by this series that will hopefully land in the mainline: > > > >

Re: Fix preempt-rt on AT91

Hi Sebastian, On 18/01/2016 at 18:42:59 +0100, Sebastian Andrzej Siewior wrote : > > 3/ Finally, the kernel will crash when initializing the PMC driver. This is > > solved by this series that will hopefully land in the mainline: > > > >

Re: [PATCH v3 00/19] x86, boot: kaslr cleanup and 64bit kaslr support

Forget mentioning this patchset is based on v4.5-rc6 of Linus's tree. On 03/05/16 at 12:24am, Baoquan He wrote: > ***Background: > Previously a bug is reported that kdump didn't work when kaslr is enabled. > During > discussing that bug fix, we found current kaslr has a limilation that it can >

Re: [PATCH v3 00/19] x86, boot: kaslr cleanup and 64bit kaslr support

Forget mentioning this patchset is based on v4.5-rc6 of Linus's tree. On 03/05/16 at 12:24am, Baoquan He wrote: > ***Background: > Previously a bug is reported that kdump didn't work when kaslr is enabled. > During > discussing that bug fix, we found current kaslr has a limilation that it can >

[tip:sched/urgent] sched/cputime: Fix steal time accounting vs. CPU hotplug

Commit-ID: e9532e69b8d1d1284e8ecf8d2586de34aec61244 Gitweb: http://git.kernel.org/tip/e9532e69b8d1d1284e8ecf8d2586de34aec61244 Author: Thomas Gleixner AuthorDate: Fri, 4 Mar 2016 15:59:42 +0100 Committer: Ingo Molnar CommitDate: Sat, 5 Mar 2016

[tip:sched/urgent] sched/cputime: Fix steal time accounting vs. CPU hotplug

Commit-ID: e9532e69b8d1d1284e8ecf8d2586de34aec61244 Gitweb: http://git.kernel.org/tip/e9532e69b8d1d1284e8ecf8d2586de34aec61244 Author: Thomas Gleixner AuthorDate: Fri, 4 Mar 2016 15:59:42 +0100 Committer: Ingo Molnar CommitDate: Sat, 5 Mar 2016 09:17:20 +0100 sched/cputime: Fix steal

<    1   2   3   4   5   >