[PATCH] rtc: add support for Maxim rtc max6916 v3.0

From: venkat-prashanth #Change Log: from v2.0 to v3.0 - fixed the out-of-tree Makefile and suitably added the modifications in the Makefile - fixed the bad indented Kconfig

[PATCH] rtc: add support for Maxim rtc max6916 v3.0

From: venkat-prashanth #Change Log: from v2.0 to v3.0 - fixed the out-of-tree Makefile and suitably added the modifications in the Makefile - fixed the bad indented Kconfig file -used a

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> Hi, > > "Du, Changbin" writes: > >> right, and that was my point: if we copy more to userspace, then we have > >> a real big problem. > >> > > Yes, we drop the data because we userspace buffer is not enough this time. > > The problem here is that really can we just drop

RE: [PATCH] usb: gadget: f_fs: report error if excess data received

> Hi, > > "Du, Changbin" writes: > >> right, and that was my point: if we copy more to userspace, then we have > >> a real big problem. > >> > > Yes, we drop the data because we userspace buffer is not enough this time. > > The problem here is that really can we just drop it silently? Maybe not.

Re: SHA1-MB algorithm broken on latest kernel

* Herbert Xu wrote: > On Thu, May 12, 2016 at 04:31:06PM -0700, Megha Dey wrote: > > Hi, > > > > When booting latest kernel with the CONFIG_CRYPTO_SHA1_MB enabled, I > > observe a panic. > > > > After having a quick look, on reverting the following patches, I am

Re: SHA1-MB algorithm broken on latest kernel

* Herbert Xu wrote: > On Thu, May 12, 2016 at 04:31:06PM -0700, Megha Dey wrote: > > Hi, > > > > When booting latest kernel with the CONFIG_CRYPTO_SHA1_MB enabled, I > > observe a panic. > > > > After having a quick look, on reverting the following patches, I am able > > to complete the

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

patch. >> > > Did you ever send a patch to fix this problem ? It is still broken in > next-20160512. > > Guenter > > >> Huacai >> >> On Wed, Apr 20, 2016 at 12:43 PM, Guenter Roeck <li...@roeck-us.net> >> wrote: >>> >>>

[PATCH] ixgbe: take online CPU number as MQ max limit when alloc_etherdev_mq()

Allocating 64 Tx/Rx as default doesn't benefit perfomrnace when less CPUs were assigned. especially when DCB is enabled, so we should take num_online_cpus() as top limit, and aslo to make sure every TC has at least one queue, take the MAX_TRAFFIC_CLASS as bottom limit of queues number.

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

; Did you ever send a patch to fix this problem ? It is still broken in > next-20160512. > > Guenter > > >> Huacai >> >> On Wed, Apr 20, 2016 at 12:43 PM, Guenter Roeck >> wrote: >>> >>> On 04/19/2016 08:37 PM, 陈华才 wrote: >>>> >&g

[PATCH] ixgbe: take online CPU number as MQ max limit when alloc_etherdev_mq()

Allocating 64 Tx/Rx as default doesn't benefit perfomrnace when less CPUs were assigned. especially when DCB is enabled, so we should take num_online_cpus() as top limit, and aslo to make sure every TC has at least one queue, take the MAX_TRAFFIC_CLASS as bottom limit of queues number.

Re: [PATCH] sched/core: don't include asm/mmu_context from drivers

On Fri, Apr 29, 2016 at 6:42 AM, Steven Rostedt wrote: > On Fri, 29 Apr 2016 10:52:32 +0200 > Arnd Bergmann wrote: > >> This reverts the earlier fix attempt and works around the problem >> by including both linux/mmu_context.h and asm/mmu_context.h from >>

Re: [PATCH] sched/core: don't include asm/mmu_context from drivers

On Fri, Apr 29, 2016 at 6:42 AM, Steven Rostedt wrote: > On Fri, 29 Apr 2016 10:52:32 +0200 > Arnd Bergmann wrote: > >> This reverts the earlier fix attempt and works around the problem >> by including both linux/mmu_context.h and asm/mmu_context.h from >> kernel/sched/core.c. This is not a good

linux-next: Tree for May 13

Hi all, Changes since 20160512: Dropped tree: rdma-leon (bad build and conflicts) The rdma-leon tree gained a build failure so I dropped it for today. The staging tree gained a build failure for which I applied a merge fix patch. The pinctrl tree lost its build failure. Non-merge commits

linux-next: Tree for May 13

Hi all, Changes since 20160512: Dropped tree: rdma-leon (bad build and conflicts) The rdma-leon tree gained a build failure so I dropped it for today. The staging tree gained a build failure for which I applied a merge fix patch. The pinctrl tree lost its build failure. Non-merge commits

[PATCH v2 4/4] ACPI 2.0 / AML: Fix module level execution by correctly parsing table as TermList

This experiment follows de-facto standard behavior, parsing entire table as a single TermList, so that all module level executions are possible during the table loading. If regressions are found against the enabling of this experimental fix, this patch is the only one that should get bisected

[PATCH v2 4/4] ACPI 2.0 / AML: Fix module level execution by correctly parsing table as TermList

This experiment follows de-facto standard behavior, parsing entire table as a single TermList, so that all module level executions are possible during the table loading. If regressions are found against the enabling of this experimental fix, this patch is the only one that should get bisected

[PATCH v2 3/4] ACPI 2.0 / AML: Enable correct ACPI subsystem initialization order for new table loading mode

This patch enables the following initialization order for the new table loading mode (which is enabled by setting acpi_gbl_parse_table_as_term_list to TRUE): 1. Install default region handlers (SystemMemory, SystemIo, PciConfig, EmbeddedControl via ECDT) without evaluating _REG; 2. Load

Re: [GIT PULL 00/10] perf/urgent fixes

re available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-urgent-for-mingo-20160512 > > for you to fetch changes up to 42ef8a78c1f49f53f29f0f3a6f9a5bcbc65323

[PATCH v2 3/4] ACPI 2.0 / AML: Enable correct ACPI subsystem initialization order for new table loading mode

This patch enables the following initialization order for the new table loading mode (which is enabled by setting acpi_gbl_parse_table_as_term_list to TRUE): 1. Install default region handlers (SystemMemory, SystemIo, PciConfig, EmbeddedControl via ECDT) without evaluating _REG; 2. Load

Re: [GIT PULL 00/10] perf/urgent fixes

the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-urgent-for-mingo-20160512 > > for you to fetch changes up to 42ef8a78c1f49f53f29f0f3a6f9a5bcbc653233e: > > perf stat: Fallback to user only counters when perf_event_paranoid

[PATCH v2 2/4] ACPICA: ACPI 2.0, Interpreter: Fix MLC issues by switching to new TermList grammar for table loading

The MLC (Module Level Code) is an ACPICA terminology describing the AML code out of any control method, its support is the main contention of the interpreter behavior during the table loading. The original implementation of MLC in ACPICA had several issues: 1. Out of any control method, besides

[PATCH v2 2/4] ACPICA: ACPI 2.0, Interpreter: Fix MLC issues by switching to new TermList grammar for table loading

The MLC (Module Level Code) is an ACPICA terminology describing the AML code out of any control method, its support is the main contention of the interpreter behavior during the table loading. The original implementation of MLC in ACPICA had several issues: 1. Out of any control method, besides

[PATCH v2 0/4] ACPI 2.0: Enable TermList interpretion for table loading

MLC (module level code) is an ACPICA terminology describing the AML code out of any control method, currently only Type1Opcode (If/Else/While) wrapped MLC code blocks are executed by the AML interpreter after the table loading. But the issue which is fixed by this patchset is: Not only

[PATCH v2 1/4] ACPICA: Dispatcher: Fix an issue that the opregions created by the linked MLC were not tracked

Operation regions created by MLC were not tracked by acpi_check_address_range(), this patch fixes this issue. ACPICA BZ 1279. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1279 Signed-off-by: Lv Zheng --- drivers/acpi/acpica/dsopcode.c |6 ++ 1

[PATCH v2 0/4] ACPI 2.0: Enable TermList interpretion for table loading

MLC (module level code) is an ACPICA terminology describing the AML code out of any control method, currently only Type1Opcode (If/Else/While) wrapped MLC code blocks are executed by the AML interpreter after the table loading. But the issue which is fixed by this patchset is: Not only

[PATCH v2 1/4] ACPICA: Dispatcher: Fix an issue that the opregions created by the linked MLC were not tracked

Operation regions created by MLC were not tracked by acpi_check_address_range(), this patch fixes this issue. ACPICA BZ 1279. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1279 Signed-off-by: Lv Zheng --- drivers/acpi/acpica/dsopcode.c |6 ++ 1 file changed, 6

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On Fri, 13 May 2016 02:33:18 + "Tian, Kevin" wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Friday, May 13, 2016 1:48 AM > > > > On Thu, 12 May 2016 04:53:19 + > > "Tian, Kevin" wrote: > > > > > > From: Alex

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On Fri, 13 May 2016 02:33:18 + "Tian, Kevin" wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Friday, May 13, 2016 1:48 AM > > > > On Thu, 12 May 2016 04:53:19 + > > "Tian, Kevin" wrote: > > > > > > From: Alex Williamson

[PATCH V12 1/2] pinctrl: add DT binding doc for pincontrol of PMIC max77620/max20024

Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins which act as GPIO as well as special function mode. Add DT binding document to configure pins in function mode as well as pin configuration parameters. Signed-off-by: Laxman Dewangan Acked-by: Rob Herring

[PATCH V12 1/2] pinctrl: add DT binding doc for pincontrol of PMIC max77620/max20024

Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins which act as GPIO as well as special function mode. Add DT binding document to configure pins in function mode as well as pin configuration parameters. Signed-off-by: Laxman Dewangan Acked-by: Rob Herring Acked-by: Linus Walleij

[PATCH V12 2/2] gpio: max77620: add gpio driver for MAX77620/MAX20024

MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO pins. It also supports interrupts from these pins. Add GPIO driver for these pins to control via GPIO APIs. Signed-off-by: Laxman Dewangan Reviewed-by: Linus Walleij --- This as part of

[PATCH V12 2/2] gpio: max77620: add gpio driver for MAX77620/MAX20024

MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO pins. It also supports interrupts from these pins. Add GPIO driver for these pins to control via GPIO APIs. Signed-off-by: Laxman Dewangan Reviewed-by: Linus Walleij --- This as part of the max77620 series and mfd patch are already

[PATCH V12 2/2] pinctrl: max77620: add pincontrol driver for MAX77620/MAX20024

MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO pins which also act as the special function in alternate mode. Also there is configuration like push-pull, open drain, FPS timing etc for these pins. Add pin control driver to configure these parameters through pin control APIs.

[PATCH V12 1/2] gpio: add DT binding doc for gpio of PMIC max77620/max20024

Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins which act as GPIO as well as special function mode. Add DT binding document to support these pins in GPIO mode via GPIO framework. Signed-off-by: Laxman Dewangan Acked-by: Rob Herring Acked-by:

[PATCH V12 2/2] pinctrl: max77620: add pincontrol driver for MAX77620/MAX20024

MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO pins which also act as the special function in alternate mode. Also there is configuration like push-pull, open drain, FPS timing etc for these pins. Add pin control driver to configure these parameters through pin control APIs.

[PATCH V12 1/2] gpio: add DT binding doc for gpio of PMIC max77620/max20024

Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins which act as GPIO as well as special function mode. Add DT binding document to support these pins in GPIO mode via GPIO framework. Signed-off-by: Laxman Dewangan Acked-by: Rob Herring Acked-by: Linus Walleij --- This as part of the

Re: [tip:sched/core] sched/fair: Correct unit of load_above_capacity

On Thu, May 12, 2016 at 03:31:51AM -0700, tip-bot for Morten Rasmussen wrote: > Commit-ID: cfa10334318d8212d007da8c771187643c9cef35 > Gitweb: http://git.kernel.org/tip/cfa10334318d8212d007da8c771187643c9cef35 > Author: Morten Rasmussen > AuthorDate: Fri, 29 Apr

Re: [tip:sched/core] sched/fair: Correct unit of load_above_capacity

On Thu, May 12, 2016 at 03:31:51AM -0700, tip-bot for Morten Rasmussen wrote: > Commit-ID: cfa10334318d8212d007da8c771187643c9cef35 > Gitweb: http://git.kernel.org/tip/cfa10334318d8212d007da8c771187643c9cef35 > Author: Morten Rasmussen > AuthorDate: Fri, 29 Apr 2016 20:32:40 +0100 >

Re: UBSAN: Undefined behaviour in drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31

On Thu, 2016-05-12 at 17:56 -0400, Ilia Mirkin wrote: > On Thu, May 12, 2016 at 4:08 PM, James Bottomley > wrote: > > On Thu, 2016-05-12 at 19:02 +0300, Meelis Roos wrote: > > > This is from a dual-AthlonMP 32-bit x86 system with onboard > > > Adaptec > > > SCSI > > >

Re: UBSAN: Undefined behaviour in drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31

On Thu, 2016-05-12 at 17:56 -0400, Ilia Mirkin wrote: > On Thu, May 12, 2016 at 4:08 PM, James Bottomley > wrote: > > On Thu, 2016-05-12 at 19:02 +0300, Meelis Roos wrote: > > > This is from a dual-AthlonMP 32-bit x86 system with onboard > > > Adaptec > > > SCSI > > > controller, once during

Re: transparent huge pages breaks KVM on AMD.

On Thu, May 12, 2016 at 11:42:16PM +0300, Kirill A. Shutemov wrote: > But I guess it should apply cleanly to v4.5. Or at least without major > conflicts. [11/511]mh@fan:~/linux/debug/linux$ curl 'http://marc.info/?l=linux-rdma=146307074800836=2' | patch -p1 % Total% Received % Xferd

Re: transparent huge pages breaks KVM on AMD.

On Thu, May 12, 2016 at 11:42:16PM +0300, Kirill A. Shutemov wrote: > But I guess it should apply cleanly to v4.5. Or at least without major > conflicts. [11/511]mh@fan:~/linux/debug/linux$ curl 'http://marc.info/?l=linux-rdma=146307074800836=2' | patch -p1 % Total% Received % Xferd

RE: [PATCH v8 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

Hi Lars, Thanks for the review... > > On 05/12/2016 02:29 PM, Kedareswara rao Appana wrote: > [...] > > +- xlnx,include-sg : Indicates the controller to operate in simple or > > + scatter gather dma mode > > This is also a software runtime configuration parameter.

RE: [PATCH v8 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

Hi Lars, Thanks for the review... > > On 05/12/2016 02:29 PM, Kedareswara rao Appana wrote: > [...] > > +- xlnx,include-sg : Indicates the controller to operate in simple or > > + scatter gather dma mode > > This is also a software runtime configuration parameter.

Re: [PATCH 2/2] clk: rockchip: fix the rk3399 sdmmc sample shift

Shawn, On Thu, May 12, 2016 at 4:47 PM, Shawn Lin wrote: > 在 2016/5/13 7:10, Brian Norris 写道: >> >> On Thu, May 12, 2016 at 11:03:17AM -0700, Doug Anderson wrote: >>> >>> Just like every other Rockhip device, the MMC "_sample" clocks should >>> have a shift of 0, not a

Re: [PATCH 2/2] clk: rockchip: fix the rk3399 sdmmc sample shift

Shawn, On Thu, May 12, 2016 at 4:47 PM, Shawn Lin wrote: > 在 2016/5/13 7:10, Brian Norris 写道: >> >> On Thu, May 12, 2016 at 11:03:17AM -0700, Doug Anderson wrote: >>> >>> Just like every other Rockhip device, the MMC "_sample" clocks should >>> have a shift of 0, not a shift of 1. The rk3399

RE: [PATCH v4 3/5] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

Hi Paul, > > Nice Kedar! > > Is this getting applied? I would really like to see this get into the > mainline. This patch got applied to the dma-next branch... Here @ http://git.kernel.org/cgit/linux/kernel/git/vkoul/slave-dma.git/log/?h=next Thanks, Kedar.

RE: [PATCH v4 3/5] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

Hi Paul, > > Nice Kedar! > > Is this getting applied? I would really like to see this get into the > mainline. This patch got applied to the dma-next branch... Here @ http://git.kernel.org/cgit/linux/kernel/git/vkoul/slave-dma.git/log/?h=next Thanks, Kedar.

arm build failures in -next due to 'sched/core: Add switch_mm_irqs_off() and use it in the scheduler'

Hi Andy, I see various arm build failures in -next. One example is spitz_defconfig. Bisect points to commit 'sched/core: Add switch_mm_irqs_off() and use it in the scheduler'. Reverting the commit fixes the problem. In file included from include/linux/mmu_context.h:4:0, from

arm build failures in -next due to 'sched/core: Add switch_mm_irqs_off() and use it in the scheduler'

Hi Andy, I see various arm build failures in -next. One example is spitz_defconfig. Bisect points to commit 'sched/core: Add switch_mm_irqs_off() and use it in the scheduler'. Reverting the commit fixes the problem. In file included from include/linux/mmu_context.h:4:0, from

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

Hi Jeffrey, On Fri, Apr 29, 2016 at 05:45:13PM +0800, jeffrey.lin wrote: > Raydium I2C touch driver. > > Signed-off-by: jeffrey.lin I was looking at the driver and there were a few issues (buffer overflows, forgetting releasing firmware, general flow, etc), that I tried

Re: [PATCH] driver: input :touchscreen : add Raydium I2C touch driver

Hi Jeffrey, On Fri, Apr 29, 2016 at 05:45:13PM +0800, jeffrey.lin wrote: > Raydium I2C touch driver. > > Signed-off-by: jeffrey.lin I was looking at the driver and there were a few issues (buffer overflows, forgetting releasing firmware, general flow, etc), that I tried correcting in the

Re: [PATCH 2/2] mm, oom: protect !costly allocations some more for !CONFIG_COMPACTION

> From: Michal Hocko > > Joonsoo has reported that he is able to trigger OOM for !costly high > order requests (heavy fork() workload close the OOM) with the new > oom detection rework. This is because we rely only on should_reclaim_retry > when the compaction is disabled and it

Re: [PATCH 2/2] mm, oom: protect !costly allocations some more for !CONFIG_COMPACTION

> From: Michal Hocko > > Joonsoo has reported that he is able to trigger OOM for !costly high > order requests (heavy fork() workload close the OOM) with the new > oom detection rework. This is because we rely only on should_reclaim_retry > when the compaction is disabled and it only checks

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

> >>+ gpiod = fwnode_get_named_gpiod(>fwnode, "reset-gpios"); > >>+ /* Deassert the reset signal */ > >>+ if (!IS_ERR(gpiod)) > >>+ gpiod_direction_output(gpiod, 0); > > > >This is wrong I think. You must only ignore -ENODEV, all other error > >At least -ENOSYS should also be

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

> >>+ gpiod = fwnode_get_named_gpiod(>fwnode, "reset-gpios"); > >>+ /* Deassert the reset signal */ > >>+ if (!IS_ERR(gpiod)) > >>+ gpiod_direction_output(gpiod, 0); > > > >This is wrong I think. You must only ignore -ENODEV, all other error > >At least -ENOSYS should also be

Re: [PATCH 1/2] mmotm: mm-oom-rework-oom-detection-fix

> From: Michal Hocko > > watermark check should use classzone_idx rather than high_zoneidx > to check reserves against the correct (preferred) zone. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton > mm/page_alloc.c | 2

Re: [PATCH 1/2] mmotm: mm-oom-rework-oom-detection-fix

> From: Michal Hocko > > watermark check should use classzone_idx rather than high_zoneidx > to check reserves against the correct (preferred) zone. > > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton > mm/page_alloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

Re: [RFC 2/3] drm/mediatek: add support for Mediatek SoC MT2701

Hi, YT: On Thu, 2016-05-12 at 19:49 +0800, yt.s...@mediatek.com wrote: > From: YT Shen > > This patch add support for the Mediatek MT2701 DISP subsystem. > There is only one OVL engine in MT2701, and we have shadow > register support here. > > Signed-off-by: YT Shen

Re: [RFC 2/3] drm/mediatek: add support for Mediatek SoC MT2701

Hi, YT: On Thu, 2016-05-12 at 19:49 +0800, yt.s...@mediatek.com wrote: > From: YT Shen > > This patch add support for the Mediatek MT2701 DISP subsystem. > There is only one OVL engine in MT2701, and we have shadow > register support here. > > Signed-off-by: YT Shen > --- > @@ -385,12

why the count nr_file_pages is not equal to nr_inactive_file + nr_active_file ?

I find the count nr_file_pages is not equal to nr_inactive_file + nr_active_file. There are 8 cpus, 2 zones in my system. I think may be the pagevec trigger the problem, but PAGEVEC_SIZE is only 14. Does anyone know the reason? Thanks, Xishi Qiu root@hi3650:/ # cat /proc/vmstat nr_free_pages

why the count nr_file_pages is not equal to nr_inactive_file + nr_active_file ?

I find the count nr_file_pages is not equal to nr_inactive_file + nr_active_file. There are 8 cpus, 2 zones in my system. I think may be the pagevec trigger the problem, but PAGEVEC_SIZE is only 14. Does anyone know the reason? Thanks, Xishi Qiu root@hi3650:/ # cat /proc/vmstat nr_free_pages

[PATCH v3 0/2] mfd: lp873x: Add lp873x PMIC support

The LP873X chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators. - Configurable General Purpose Output Signals(GPO). PMIC interacts with the main processor through i2c. PMIC has couple of

[PATCH v3 2/2] mfd: lp873x: Add lp873x PMIC support

The LP873X chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators. - Configurable General Purpose Output Signals(GPO). PMIC interacts with the main processor through i2c. PMIC has couple of

[PATCH v3 0/2] mfd: lp873x: Add lp873x PMIC support

The LP873X chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators. - Configurable General Purpose Output Signals(GPO). PMIC interacts with the main processor through i2c. PMIC has couple of

[PATCH v3 2/2] mfd: lp873x: Add lp873x PMIC support

The LP873X chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators. - Configurable General Purpose Output Signals(GPO). PMIC interacts with the main processor through i2c. PMIC has couple of

[PATCH v3 1/2] Documentation: mfd: LP873X: Add information for the mfd and regulator drivers

Add information for the mfd and regulator drivers. Acked-by: Rob Herring Signed-off-by: Keerthy --- Changes in v3: * Changed the example node lable to pmic from lp8733. Documentation/devicetree/bindings/mfd/lp873x.txt | 55 1

[PATCH v3 1/2] Documentation: mfd: LP873X: Add information for the mfd and regulator drivers

Add information for the mfd and regulator drivers. Acked-by: Rob Herring Signed-off-by: Keerthy --- Changes in v3: * Changed the example node lable to pmic from lp8733. Documentation/devicetree/bindings/mfd/lp873x.txt | 55 1 file changed, 55 insertions(+) create

[Patch v5 0/8] Qualcomm SCM Rework

The following set of patches does a bit of rework on the existing Qualcomm SCM firmware. The first couple of patches deals with turning the current SCM into a platform driver. The next couple are cleanups that make adding the 64 support a little easier. I added in a patch to convert the scm-32

[Patch v5 0/8] Qualcomm SCM Rework

The following set of patches does a bit of rework on the existing Qualcomm SCM firmware. The first couple of patches deals with turning the current SCM into a platform driver. The next couple are cleanups that make adding the 64 support a little easier. I added in a patch to convert the scm-32

[Patch v5 2/8] firmware: qcom: scm: Convert SCM to platform driver

This patch converts the Qualcomm SCM firmware driver into a platform driver. Signed-off-by: Andy Gross --- drivers/firmware/qcom_scm.c | 165 +--- 1 file changed, 156 insertions(+), 9 deletions(-) diff --git

[Patch v5 2/8] firmware: qcom: scm: Convert SCM to platform driver

This patch converts the Qualcomm SCM firmware driver into a platform driver. Signed-off-by: Andy Gross --- drivers/firmware/qcom_scm.c | 165 +--- 1 file changed, 156 insertions(+), 9 deletions(-) diff --git a/drivers/firmware/qcom_scm.c

[Patch v5 6/8] firmware: qcom: scm: Add support for ARM64 SoCs

From: Kumar Gala Add an implementation of the SCM interface that works on ARM64 SoCs. This is used by things like determine if we have HDCP support or not on the system. Signed-off-by: Kumar Gala Signed-off-by: Andy Gross ---

[Patch v5 6/8] firmware: qcom: scm: Add support for ARM64 SoCs

From: Kumar Gala Add an implementation of the SCM interface that works on ARM64 SoCs. This is used by things like determine if we have HDCP support or not on the system. Signed-off-by: Kumar Gala Signed-off-by: Andy Gross --- drivers/firmware/qcom_scm-32.c | 4 +

[Patch v5 4/8] firmware: qcom: scm: Generalize shared error map

This patch moves the qcom_scm_remap_error function to the include file where can be used by both the 32 and 64 bit versions of the code. Reviewed-by: Stephen Boyd Acked-by: Bjorn Andersson Signed-off-by: Andy Gross

[Patch v5 4/8] firmware: qcom: scm: Generalize shared error map

This patch moves the qcom_scm_remap_error function to the include file where can be used by both the 32 and 64 bit versions of the code. Reviewed-by: Stephen Boyd Acked-by: Bjorn Andersson Signed-off-by: Andy Gross Signed-off-by: Andy Gross --- drivers/firmware/qcom_scm-32.c | 17

[Patch v5 7/8] dts: qcom: apq8084: Add SCM firmware node

This patch adds the firmware node for the SCM Acked-by: Bjorn Andersson Signed-off-by: Andy Gross --- arch/arm/boot/dts/qcom-apq8084.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi

[Patch v5 8/8] arm64: dts: msm8916: Add SCM firmware node

This adds the devicetree node for the SCM firmware. Acked-by: Bjorn Andersson Signed-off-by: Andy Gross --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi

[Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

This patch converts the Qualcomm SCM driver to use the streaming DMA APIs for communication buffers. Signed-off-by: Andy Gross --- drivers/firmware/qcom_scm-32.c | 189 +++-- drivers/firmware/qcom_scm.c| 6 +-

[Patch v5 7/8] dts: qcom: apq8084: Add SCM firmware node

This patch adds the firmware node for the SCM Acked-by: Bjorn Andersson Signed-off-by: Andy Gross --- arch/arm/boot/dts/qcom-apq8084.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi b/arch/arm/boot/dts/qcom-apq8084.dtsi index

[Patch v5 8/8] arm64: dts: msm8916: Add SCM firmware node

This adds the devicetree node for the SCM firmware. Acked-by: Bjorn Andersson Signed-off-by: Andy Gross --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi index

[Patch v5 5/8] firmware: qcom: scm: Convert to streaming DMA APIS

This patch converts the Qualcomm SCM driver to use the streaming DMA APIs for communication buffers. Signed-off-by: Andy Gross --- drivers/firmware/qcom_scm-32.c | 189 +++-- drivers/firmware/qcom_scm.c| 6 +- drivers/firmware/qcom_scm.h| 10 ++- 3

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

On 04/19/2016 10:41 PM, Huacai Chen wrote: This is a kernel bug, I'll send a patch. Did you ever send a patch to fix this problem ? It is still broken in next-20160512. Guenter Huacai On Wed, Apr 20, 2016 at 12:43 PM, Guenter Roeck <li...@roeck-us.net> wrote: On 04/19/2016 08:37 P

[Patch v5 1/8] dt/bindings: firmware: Add Qualcomm SCM binding

This patch adds the device tree support for the Qualcomm SCM firmware. Signed-off-by: Andy Gross --- .../devicetree/bindings/firmware/qcom,scm.txt | 28 ++ 1 file changed, 28 insertions(+) create mode 100644

[Patch v5 3/8] firmware: qcom: scm: Use atomic SCM for cold boot

This patch changes the cold_set_boot_addr function to use atomic SCM calls. cold_set_boot_addr required adding qcom_scm_call_atomic2 to support the two arguments going to the smc call. Using atomic removes the need for memory allocation and instead places all arguments in registers.

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

On 04/19/2016 10:41 PM, Huacai Chen wrote: This is a kernel bug, I'll send a patch. Did you ever send a patch to fix this problem ? It is still broken in next-20160512. Guenter Huacai On Wed, Apr 20, 2016 at 12:43 PM, Guenter Roeck wrote: On 04/19/2016 08:37 PM, 陈华才 wrote: Hi, Could

[Patch v5 1/8] dt/bindings: firmware: Add Qualcomm SCM binding

This patch adds the device tree support for the Qualcomm SCM firmware. Signed-off-by: Andy Gross --- .../devicetree/bindings/firmware/qcom,scm.txt | 28 ++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/firmware/qcom,scm.txt diff

[Patch v5 3/8] firmware: qcom: scm: Use atomic SCM for cold boot

This patch changes the cold_set_boot_addr function to use atomic SCM calls. cold_set_boot_addr required adding qcom_scm_call_atomic2 to support the two arguments going to the smc call. Using atomic removes the need for memory allocation and instead places all arguments in registers.

Re: [LKP] [lkp] [net] 9317bb6982: INFO: task cat-kmsg:893 blocked for more than 300 seconds.

Oh right, sorry for the delay. On Thu, May 12, 2016 at 8:01 PM, Huang, Ying wrote: > "Huang, Ying" writes: > >> Eric Dumazet writes: >>> On Mon, May 9, 2016 at 6:26 PM, Huang, Ying >>> wrote:

Re: [LKP] [lkp] [net] 9317bb6982: INFO: task cat-kmsg:893 blocked for more than 300 seconds.

Oh right, sorry for the delay. On Thu, May 12, 2016 at 8:01 PM, Huang, Ying wrote: > "Huang, Ying" writes: > >> Eric Dumazet writes: >>> On Mon, May 9, 2016 at 6:26 PM, Huang, Ying >>> wrote: Hi, Eric, kernel test robot writes: > FYI, we noticed the following commit:

Re: [tip:sched/core] sched/fair: Clean up scale confusion

On Thu, May 12, 2016 at 03:31:27AM -0700, tip-bot for Peter Zijlstra wrote: > Commit-ID: 1be0eb2a97d756fb7dd8c9baf372d81fa9699c09 > Gitweb: http://git.kernel.org/tip/1be0eb2a97d756fb7dd8c9baf372d81fa9699c09 > Author: Peter Zijlstra > AuthorDate: Fri, 6 May 2016

Re: [tip:sched/core] sched/fair: Clean up scale confusion

On Thu, May 12, 2016 at 03:31:27AM -0700, tip-bot for Peter Zijlstra wrote: > Commit-ID: 1be0eb2a97d756fb7dd8c9baf372d81fa9699c09 > Gitweb: http://git.kernel.org/tip/1be0eb2a97d756fb7dd8c9baf372d81fa9699c09 > Author: Peter Zijlstra > AuthorDate: Fri, 6 May 2016 12:21:23 +0200 >

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

On Fri, May 13, 2016 at 6:02 AM, Arend van Spriel wrote: > On 12-05-16 11:34, Wei-Ning Huang wrote: >> On Thu, May 12, 2016 at 2:33 AM, Dan Williams wrote: >>> On Wed, 2016-05-11 at 13:03 +0800, Wei-Ning Huang wrote: On Fri, May 6, 2016 at 4:19

Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support

On Fri, May 13, 2016 at 6:02 AM, Arend van Spriel wrote: > On 12-05-16 11:34, Wei-Ning Huang wrote: >> On Thu, May 12, 2016 at 2:33 AM, Dan Williams wrote: >>> On Wed, 2016-05-11 at 13:03 +0800, Wei-Ning Huang wrote: On Fri, May 6, 2016 at 4:19 PM, Wei-Ning Huang wrote: > > On

Re: [PATCH 3/6] dt-bindings: mtu3: add devicetree bindings

On Thu, 2016-05-12 at 22:09 -0500, Rob Herring wrote: > On Thu, May 12, 2016 at 9:00 PM, chunfeng yun > wrote: > > Hi, > > > > On Thu, 2016-05-12 at 19:02 -0400, Alan Cooper wrote: > >> On Thu, May 12, 2016 at 3:24 AM, chunfeng yun > >>

Re: [PATCH 3/6] dt-bindings: mtu3: add devicetree bindings

On Thu, 2016-05-12 at 22:09 -0500, Rob Herring wrote: > On Thu, May 12, 2016 at 9:00 PM, chunfeng yun > wrote: > > Hi, > > > > On Thu, 2016-05-12 at 19:02 -0400, Alan Cooper wrote: > >> On Thu, May 12, 2016 at 3:24 AM, chunfeng yun > >> wrote: > >> >> > + - mediatek,enable-manual-drd :

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:1706:9: error: too few arguments to function 'ib_map_mr_sg' n = ib_map_mr_sg(mr, tx->tx_frags, ^ In file included from

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:1706:9: error: too few arguments to function 'ib_map_mr_sg' n = ib_map_mr_sg(mr, tx->tx_frags, ^ In file included from

Re: [PATCH 2/2] cpufreq: governor: CPUFREQ_GOV_STOP never fails

On 12-05-16, 15:14, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > None of the cpufreq governors currently in the tree will ever fail > an invocation of the ->governor() callback with the event argument > equal to CPUFREQ_GOV_STOP (unless invoked with

Re: [PATCH 1/2] cpufreq: governor: CPUFREQ_GOV_POLICY_EXIT never fails

On 12-05-16, 15:13, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > None of the cpufreq governors currently in the tree will ever fail > an invocation of the ->governor() callback with the event argument > equal to CPUFREQ_GOV_POLICY_EXIT (unless invoked with

  1   2   3   4   5   6   7   8   9   10   >