Re: [PATCH] ACPI : Dummy acpi_video_register should return error code

On 06/23/2016 05:05 AM, Rafael J. Wysocki wrote: > On Thursday, June 23, 2016 12:26:01 AM Arvind Yadav wrote: >> The inline acpi_video_register stub simply allows compilation on systems >> with CONFIG_ACPI_VIDEO disabled. the dummy acpi_video_register does not >> register an acpi_bus_driver at

Re: [PATCH] ACPI : Dummy acpi_video_register should return error code

On 06/23/2016 05:05 AM, Rafael J. Wysocki wrote: > On Thursday, June 23, 2016 12:26:01 AM Arvind Yadav wrote: >> The inline acpi_video_register stub simply allows compilation on systems >> with CONFIG_ACPI_VIDEO disabled. the dummy acpi_video_register does not >> register an acpi_bus_driver at

Re: [PATCH] mmc: core: add auto bkops support

在 2016/6/22 22:08, Alex Lemberg 写道: HI Shawn, On 6/21/16, 4:44 AM, "Shawn Lin" wrote: On 2016/6/20 21:33, Alex Lemberg wrote: Hi Shawn, […] + +static int mmc_stop_auto_bkops(struct mmc_card *card) +{ + int err = 0; + + if

Re: [PATCH] mmc: core: add auto bkops support

在 2016/6/22 22:08, Alex Lemberg 写道: HI Shawn, On 6/21/16, 4:44 AM, "Shawn Lin" wrote: On 2016/6/20 21:33, Alex Lemberg wrote: Hi Shawn, […] + +static int mmc_stop_auto_bkops(struct mmc_card *card) +{ + int err = 0; + + if (!card->ext_csd.auto_bkops_en) + return

Re: [RFC PATCH 1/4] Documentation: mmc: add description for new caps

在 2016/6/22 23:06, Doug Anderson 写道: Hi, On Wed, Jun 8, 2016 at 1:20 AM, Shawn Lin wrote: Let's add some basic description for cap-no-sdio, cap-no-sd and cap-no-mmc. Signed-off-by: Shawn Lin ---

Re: [RFC PATCH 1/4] Documentation: mmc: add description for new caps

在 2016/6/22 23:06, Doug Anderson 写道: Hi, On Wed, Jun 8, 2016 at 1:20 AM, Shawn Lin wrote: Let's add some basic description for cap-no-sdio, cap-no-sd and cap-no-mmc. Signed-off-by: Shawn Lin --- Documentation/devicetree/bindings/mmc/mmc.txt | 3 +++ 1 file changed, 3 insertions(+) diff

Re: [PATCH v9 1/8] perf evlist: Introduce aux evlist

On 2016/6/22 21:40, Arnaldo Carvalho de Melo wrote: Em Wed, Jun 22, 2016 at 08:17:02AM -0500, Nilay Vaish escreveu: On 22 June 2016 at 04:08, Wang Nan wrote: +struct perf_evlist *perf_evlist__new_aux(struct perf_evlist *parent) +{ + struct perf_evlist *evlist; + +

Re: [PATCH] staging: wilc1000: fix error handling in wilc_debugfs_init()

Hi All, On Wed, Jun 22, 2016 at 10:39 PM, Luis de Bethencourt wrote: > The common format to check if a function returned an error pointer is to > use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors. > > Also, if there was an error returning -EINVAL

Re: [PATCH v9 1/8] perf evlist: Introduce aux evlist

On 2016/6/22 21:40, Arnaldo Carvalho de Melo wrote: Em Wed, Jun 22, 2016 at 08:17:02AM -0500, Nilay Vaish escreveu: On 22 June 2016 at 04:08, Wang Nan wrote: +struct perf_evlist *perf_evlist__new_aux(struct perf_evlist *parent) +{ + struct perf_evlist *evlist; + + if

Re: [PATCH] staging: wilc1000: fix error handling in wilc_debugfs_init()

Hi All, On Wed, Jun 22, 2016 at 10:39 PM, Luis de Bethencourt wrote: > The common format to check if a function returned an error pointer is to > use PTR_ERR(). Instead of ERR_PTR() which is used to return said errors. > > Also, if there was an error returning -EINVAL instead of -1 is more >

Re: [PATCH v4 net] ipvs: fix bind to link-local mcast IPv6 address in backup

On Fri, Jun 17, 2016 at 09:42:49AM +0300, Julian Anastasov wrote: > > Hello, > > On Thu, 16 Jun 2016, Quentin Armitage wrote: > > > When using HEAD from > > https://git.kernel.org/cgit/utils/kernel/ipvsadm/ipvsadm.git/, > > the command: > > ipvsadm --start-daemon backup --mcast-interface

Re: [PATCH v4 net] ipvs: fix bind to link-local mcast IPv6 address in backup

On Fri, Jun 17, 2016 at 09:42:49AM +0300, Julian Anastasov wrote: > > Hello, > > On Thu, 16 Jun 2016, Quentin Armitage wrote: > > > When using HEAD from > > https://git.kernel.org/cgit/utils/kernel/ipvsadm/ipvsadm.git/, > > the command: > > ipvsadm --start-daemon backup --mcast-interface

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Mon, Jun 20, 2016 at 9:01 PM, Linus Torvalds wrote: > On Mon, Jun 20, 2016 at 4:43 PM, Andy Lutomirski wrote: >> >> On my laptop, this adds about 1.5µs of overhead to task creation, >> which seems to be mainly caused by vmalloc inefficiently

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Mon, Jun 20, 2016 at 9:01 PM, Linus Torvalds wrote: > On Mon, Jun 20, 2016 at 4:43 PM, Andy Lutomirski wrote: >> >> On my laptop, this adds about 1.5µs of overhead to task creation, >> which seems to be mainly caused by vmalloc inefficiently allocating >> individual pages even when a

Re: [PATCH v9 5/8] perf record: Toggle overwrite ring buffer for reading

On 2016/6/22 22:33, Nilay Vaish wrote: On 22 June 2016 at 04:08, Wang Nan wrote: @@ -549,17 +573,72 @@ static struct perf_event_header finished_round_event = { .type = PERF_RECORD_FINISHED_ROUND, }; -static int record__mmap_read_all(struct record *rec)

Re: [PATCH v9 5/8] perf record: Toggle overwrite ring buffer for reading

On 2016/6/22 22:33, Nilay Vaish wrote: On 22 June 2016 at 04:08, Wang Nan wrote: @@ -549,17 +573,72 @@ static struct perf_event_header finished_round_event = { .type = PERF_RECORD_FINISHED_ROUND, }; -static int record__mmap_read_all(struct record *rec) +static void

Re: [RFC PATCH v2 6/6] drm/rockchip: Add dmc notifier in vop driver

Hi Lin, On 2016년 06월 22일 21:25, hl wrote: > Hi Chanwoo Choi, > > On 2016年06月22日 15:11, Chanwoo Choi wrote: >> Hi, >> >> On 2016년 06월 06일 19:13, Lin Huang wrote: >>> when in ddr frequency scaling process, vop can not do >>> enable or disable operate, since dcf will base on vop vblank >>> time to

Re: [RFC PATCH v2 6/6] drm/rockchip: Add dmc notifier in vop driver

Hi Lin, On 2016년 06월 22일 21:25, hl wrote: > Hi Chanwoo Choi, > > On 2016年06月22日 15:11, Chanwoo Choi wrote: >> Hi, >> >> On 2016년 06월 06일 19:13, Lin Huang wrote: >>> when in ddr frequency scaling process, vop can not do >>> enable or disable operate, since dcf will base on vop vblank >>> time to

[PATCH 2/2] sparc64: Fix pagetable freeing for hugepage regions

8M pages now allocate page tables till PMD level only. So, when freeing page table for 8M hugepage backed region, make sure we don't try to access non-existent PTE level. Signed-off-by: Nitin Gupta --- arch/sparc/include/asm/hugetlb.h | 8

[PATCH 1/2] sparc64: Trim page tables for 8M hugepages

For PMD aligned (8M) hugepages, we currently allocate all four page table levels which is wasteful. We now allocate till PMD level only which saves memory usage from page tables. Orabug: 22630259 Signed-off-by: Nitin Gupta --- arch/sparc/include/asm/pgtable_64.h | 7

[PATCH 2/2] sparc64: Fix pagetable freeing for hugepage regions

8M pages now allocate page tables till PMD level only. So, when freeing page table for 8M hugepage backed region, make sure we don't try to access non-existent PTE level. Signed-off-by: Nitin Gupta --- arch/sparc/include/asm/hugetlb.h | 8 arch/sparc/mm/hugetlbpage.c | 98

[PATCH 1/2] sparc64: Trim page tables for 8M hugepages

For PMD aligned (8M) hugepages, we currently allocate all four page table levels which is wasteful. We now allocate till PMD level only which saves memory usage from page tables. Orabug: 22630259 Signed-off-by: Nitin Gupta --- arch/sparc/include/asm/pgtable_64.h | 7 +++-

Re: [PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to report multitouch data

On Thu, May 12, 2016 at 8:12 AM, Benjamin Tissoires wrote: > > There is no reasons to filter out keyboard and consumer control collections > in hid-multitouch. > With the previous hid-input fix, there is now a full support of the Type > Cover and we can remove all

Re: [PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to report multitouch data

On Thu, May 12, 2016 at 8:12 AM, Benjamin Tissoires wrote: > > There is no reasons to filter out keyboard and consumer control collections > in hid-multitouch. > With the previous hid-input fix, there is now a full support of the Type > Cover and we can remove all specific bits from hid-core and

Re: [PATCH 1/6] regulator: core: Allow simultaneous use of enable op and GPIO

On Wed, Jun 22, 2016 at 7:34 PM, Mark Brown wrote: > On Wed, Jun 22, 2016 at 05:25:53PM +0900, Alexandre Courbot wrote: >> The current regulator enable/disable mechanism does not call the driver >> enable/disable op if an enable GPIO is set. It may be desirable to use >> both

Re: [PATCH 1/6] regulator: core: Allow simultaneous use of enable op and GPIO

On Wed, Jun 22, 2016 at 7:34 PM, Mark Brown wrote: > On Wed, Jun 22, 2016 at 05:25:53PM +0900, Alexandre Courbot wrote: >> The current regulator enable/disable mechanism does not call the driver >> enable/disable op if an enable GPIO is set. It may be desirable to use >> both mechanisms though,

Re: [PATCH v3 2/2] PCI: Rockchip: Add Rockchip PCIe controller support

在 2016/6/23 8:29, Brian Norris 写道: Hi Shawn, I'm familiarizing myself a bit with your PCIe core, but I'm certainly no expert, so I may have some dumb comments. Also a few other general comments. On Thu, Jun 16, 2016 at 09:50:35AM +0800, Shawn Lin wrote: This patch adds Rockchip PCIe

Re: [PATCH v3 2/2] PCI: Rockchip: Add Rockchip PCIe controller support

在 2016/6/23 8:29, Brian Norris 写道: Hi Shawn, I'm familiarizing myself a bit with your PCIe core, but I'm certainly no expert, so I may have some dumb comments. Also a few other general comments. On Thu, Jun 16, 2016 at 09:50:35AM +0800, Shawn Lin wrote: This patch adds Rockchip PCIe

Re: [PATCH v3] cgroup: Disable IRQs while holding css_set_lock

On 2016/6/23 4:28, Daniel Bristot de Oliveira wrote: > While testing the deadline scheduler + cgroup setup I hit this > warning. > ... > The warn is the spin_(lock|unlock)_bh(_set_lock) in the interrupt > context. Converting the spin_lock_bh to spin_lock_irq(save) to avoid > this problem - and

Re: [PATCH v3] cgroup: Disable IRQs while holding css_set_lock

On 2016/6/23 4:28, Daniel Bristot de Oliveira wrote: > While testing the deadline scheduler + cgroup setup I hit this > warning. > ... > The warn is the spin_(lock|unlock)_bh(_set_lock) in the interrupt > context. Converting the spin_lock_bh to spin_lock_irq(save) to avoid > this problem - and

RE: [PATCH v3 1/3] ACPI / button: Remove initial lid state notification

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Subject: Re: [PATCH v3 1/3] ACPI / button: Remove initial lid state > notification > > On Wednesday, June 01, 2016 06:10:34 PM Lv Zheng wrote: > > The _LID control method's initial returning value is not reliable. > > > > The

RE: [PATCH v3 1/3] ACPI / button: Remove initial lid state notification

Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Subject: Re: [PATCH v3 1/3] ACPI / button: Remove initial lid state > notification > > On Wednesday, June 01, 2016 06:10:34 PM Lv Zheng wrote: > > The _LID control method's initial returning value is not reliable. > > > > The

Re: adf_ctl_drv.c:(.init.text+0x14915): undefined reference to `adf_init_pf_wq' (was Linux 4.4.13)

On 06/22/16 17:37, Greg KH wrote: > On Wed, Jun 22, 2016 at 04:41:07PM -0700, Randy Dunlap wrote: >> On 06/22/16 03:49, Hans de Bruin wrote: >>> On 06/20/2016 07:17 PM, Randy Dunlap wrote: On 06/20/16 08:43, Greg KH wrote: > On Sun, Jun 19, 2016 at 09:12:29AM +0200, Hans de Bruin wrote:

Re: adf_ctl_drv.c:(.init.text+0x14915): undefined reference to `adf_init_pf_wq' (was Linux 4.4.13)

On 06/22/16 17:37, Greg KH wrote: > On Wed, Jun 22, 2016 at 04:41:07PM -0700, Randy Dunlap wrote: >> On 06/22/16 03:49, Hans de Bruin wrote: >>> On 06/20/2016 07:17 PM, Randy Dunlap wrote: On 06/20/16 08:43, Greg KH wrote: > On Sun, Jun 19, 2016 at 09:12:29AM +0200, Hans de Bruin wrote:

Re: Boot failure on emev2/kzm9d (was: Re: [PATCH v2 11/11] mm/slab: lockless decision to grow cache)

On Wed, Jun 22, 2016 at 12:08:59PM -0700, Paul E. McKenney wrote: > On Wed, Jun 22, 2016 at 05:01:35PM +0200, Geert Uytterhoeven wrote: > > On Wed, Jun 22, 2016 at 2:52 AM, Joonsoo Kim wrote: > > > Could you try below patch to check who causes the hang? > > > > > > And, if

Re: Boot failure on emev2/kzm9d (was: Re: [PATCH v2 11/11] mm/slab: lockless decision to grow cache)

On Wed, Jun 22, 2016 at 12:08:59PM -0700, Paul E. McKenney wrote: > On Wed, Jun 22, 2016 at 05:01:35PM +0200, Geert Uytterhoeven wrote: > > On Wed, Jun 22, 2016 at 2:52 AM, Joonsoo Kim wrote: > > > Could you try below patch to check who causes the hang? > > > > > > And, if sysalt-t works when

Re: [PATCH 1/4] drivers: input: powerkey for HISI 65xx SoC

On Tue, Jun 21, 2016 at 05:06:23PM -0700, John Stultz wrote: > On Tue, Jun 14, 2016 at 3:43 PM, John Stultz wrote: > > From: Jorge Ramirez-Ortiz > > > > This driver provides a input driver for the power button on the > > HiSi 65xx SoC for

Re: [PATCH 1/4] drivers: input: powerkey for HISI 65xx SoC

On Tue, Jun 21, 2016 at 05:06:23PM -0700, John Stultz wrote: > On Tue, Jun 14, 2016 at 3:43 PM, John Stultz wrote: > > From: Jorge Ramirez-Ortiz > > > > This driver provides a input driver for the power button on the > > HiSi 65xx SoC for boards like HiKey. > > > > This driver was originally by

Re: [PATCH v2] mailbox: pcc: Add PCC request and free channel declarations

On Thursday, June 16, 2016 02:09:38 PM Hoan Tran wrote: > Exports pcc_mbox_request_channel() and pcc_mbox_free_channel() > declarations into a pcc.h header file. > > v2 > * Introduce pcc.h header file for pcc client methods > > v1 > * Initial > > Signed-off-by: Hoan Tran

Re: [PATCH v2] mailbox: pcc: Add PCC request and free channel declarations

On Thursday, June 16, 2016 02:09:38 PM Hoan Tran wrote: > Exports pcc_mbox_request_channel() and pcc_mbox_free_channel() > declarations into a pcc.h header file. > > v2 > * Introduce pcc.h header file for pcc client methods > > v1 > * Initial > > Signed-off-by: Hoan Tran Ashwin, Prakash,

Re: [PATCH v6 0/5] ACPI / processor_idle: Add ACPI v6.0 LPI support

On Wednesday, June 22, 2016 06:45:15 PM Sudeep Holla wrote: > Hi Rafael, > > On 14/06/16 15:48, Sudeep Holla wrote: > > ACPI 6.0 introduced LPI(Low Power Idle) states that provides an alternate > > method to describe processor idle states. It extends the specification > > to allow the expression

Re: [PATCH v6 0/5] ACPI / processor_idle: Add ACPI v6.0 LPI support

On Wednesday, June 22, 2016 06:45:15 PM Sudeep Holla wrote: > Hi Rafael, > > On 14/06/16 15:48, Sudeep Holla wrote: > > ACPI 6.0 introduced LPI(Low Power Idle) states that provides an alternate > > method to describe processor idle states. It extends the specification > > to allow the expression

Re: adf_ctl_drv.c:(.init.text+0x14915): undefined reference to `adf_init_pf_wq' (was Linux 4.4.13)

On Wed, Jun 22, 2016 at 04:41:07PM -0700, Randy Dunlap wrote: > On 06/22/16 03:49, Hans de Bruin wrote: > > On 06/20/2016 07:17 PM, Randy Dunlap wrote: > >> On 06/20/16 08:43, Greg KH wrote: > >>> On Sun, Jun 19, 2016 at 09:12:29AM +0200, Hans de Bruin wrote: > On 06/08/2016 03:43 AM, Greg KH

Re: adf_ctl_drv.c:(.init.text+0x14915): undefined reference to `adf_init_pf_wq' (was Linux 4.4.13)

On Wed, Jun 22, 2016 at 04:41:07PM -0700, Randy Dunlap wrote: > On 06/22/16 03:49, Hans de Bruin wrote: > > On 06/20/2016 07:17 PM, Randy Dunlap wrote: > >> On 06/20/16 08:43, Greg KH wrote: > >>> On Sun, Jun 19, 2016 at 09:12:29AM +0200, Hans de Bruin wrote: > On 06/08/2016 03:43 AM, Greg KH

Re: [PATCH v4 1/5] ACPICA: Namespace: Fix a regression that MLC support triggers dead lock in dynamic table loading

On Tuesday, June 21, 2016 09:55:53 AM Zheng, Lv wrote: > Hi, Mika > > > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > > Subject: Re: [PATCH v4 1/5] ACPICA: Namespace: Fix a regression that MLC > > support triggers dead lock in dynamic table loading > > > > On Tue, Jun 21, 2016

Re: [PATCH v4 1/5] ACPICA: Namespace: Fix a regression that MLC support triggers dead lock in dynamic table loading

On Tuesday, June 21, 2016 09:55:53 AM Zheng, Lv wrote: > Hi, Mika > > > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > > Subject: Re: [PATCH v4 1/5] ACPICA: Namespace: Fix a regression that MLC > > support triggers dead lock in dynamic table loading > > > > On Tue, Jun 21, 2016

Re: [PATCH] thermal: rcar-thermal: enable hwmon when thermal_zone

Hi Zhang > From: Kuninori Morimoto > > rcar-thermal is supporting both thermal_zone_of_sensor_register() and > thermal_zone_device_register(). But thermal_zone_of_sensor_register() > doesn't enable hwmon as default. > This patch enables it to keep

Re: [PATCH] thermal: rcar-thermal: enable hwmon when thermal_zone

Hi Zhang > From: Kuninori Morimoto > > rcar-thermal is supporting both thermal_zone_of_sensor_register() and > thermal_zone_device_register(). But thermal_zone_of_sensor_register() > doesn't enable hwmon as default. > This patch enables it to keep compatibility > > Signed-off-by: Kuninori

Re: [PATCH] fbdev: atyfb: fix array overflow

On Wed, Jun 22, 2016 at 02:37:11PM +0200, Arnd Bergmann wrote: > When building with CONFIG_UBSAN_SANITIZE_ALL on ARM, I get this > gcc warning for atyfb: > > drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_bl_update_status': > drivers/video/fbdev/aty/atyfb_base.c:167:33: warning: array

Re: [PATCH] fbdev: atyfb: fix array overflow

On Wed, Jun 22, 2016 at 02:37:11PM +0200, Arnd Bergmann wrote: > When building with CONFIG_UBSAN_SANITIZE_ALL on ARM, I get this > gcc warning for atyfb: > > drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_bl_update_status': > drivers/video/fbdev/aty/atyfb_base.c:167:33: warning: array

RE: 4.7 regression - ACPICA: Hardware: Enhance acpi_hw_validate_register() with access_width/bit_offset awareness

Hi, Mike > From: Mike Galbraith [mailto:umgwanakikb...@gmail.com] > Subject: 4.7 regression - ACPICA: Hardware: Enhance > acpi_hw_validate_register() with access_width/bit_offset awareness > > In my aging (ok old) HP DL980 G7 [Lv Zheng] Which may mean Windows Vista cannot run on this machine,

RE: 4.7 regression - ACPICA: Hardware: Enhance acpi_hw_validate_register() with access_width/bit_offset awareness

Hi, Mike > From: Mike Galbraith [mailto:umgwanakikb...@gmail.com] > Subject: 4.7 regression - ACPICA: Hardware: Enhance > acpi_hw_validate_register() with access_width/bit_offset awareness > > In my aging (ok old) HP DL980 G7 [Lv Zheng] Which may mean Windows Vista cannot run on this machine,

Re: [PATCH] acpi: thermal: Remove create_workqueue

On Tuesday, June 07, 2016 09:13:51 AM Tejun Heo wrote: > On Tue, Jun 07, 2016 at 08:45:40AM +0530, Bhaktipriya Shridhar wrote: > > alloc_workqueue replaces deprecated create_workqueue(). > > > > A dedicated workqueue has been used since the workqueue > > acpi_thermal_pm_queue with workitem

Re: [PATCH update v7 15/15] acpi, numa: Enable ACPI based NUMA on ARM64

On Friday, June 17, 2016 11:53:02 AM Hanjun Guo wrote: > From: Hanjun Guo > > Add function needed for cpu to node mapping, and enable ACPI based > NUMA for ARM64 in Kconfig > > Signed-off-by: Hanjun Guo > Signed-off-by: Robert Richter

Re: [PATCH] acpi: thermal: Remove create_workqueue

On Tuesday, June 07, 2016 09:13:51 AM Tejun Heo wrote: > On Tue, Jun 07, 2016 at 08:45:40AM +0530, Bhaktipriya Shridhar wrote: > > alloc_workqueue replaces deprecated create_workqueue(). > > > > A dedicated workqueue has been used since the workqueue > > acpi_thermal_pm_queue with workitem

Re: [PATCH update v7 15/15] acpi, numa: Enable ACPI based NUMA on ARM64

On Friday, June 17, 2016 11:53:02 AM Hanjun Guo wrote: > From: Hanjun Guo > > Add function needed for cpu to node mapping, and enable ACPI based > NUMA for ARM64 in Kconfig > > Signed-off-by: Hanjun Guo > Signed-off-by: Robert Richter > [david.da...@cavium.com added ACPI_NUMA default to y for

Re: [PATCH v3 1/3] ACPI / button: Remove initial lid state notification

On Wednesday, June 01, 2016 06:10:34 PM Lv Zheng wrote: > The _LID control method's initial returning value is not reliable. > > The _LID control method is described to return the "current" lid state. > However the word of "current" has ambiguity, many BIOSen return the lid > state upon the last

Re: [PATCH v3 1/3] ACPI / button: Remove initial lid state notification

On Wednesday, June 01, 2016 06:10:34 PM Lv Zheng wrote: > The _LID control method's initial returning value is not reliable. > > The _LID control method is described to return the "current" lid state. > However the word of "current" has ambiguity, many BIOSen return the lid > state upon the last

Re: [PATCH v3 2/2] PCI: Rockchip: Add Rockchip PCIe controller support

Hi Shawn, I'm familiarizing myself a bit with your PCIe core, but I'm certainly no expert, so I may have some dumb comments. Also a few other general comments. On Thu, Jun 16, 2016 at 09:50:35AM +0800, Shawn Lin wrote: > This patch adds Rockchip PCIe controller support found > on RK3399 Soc

Re: [PATCH v3 2/2] PCI: Rockchip: Add Rockchip PCIe controller support

Hi Shawn, I'm familiarizing myself a bit with your PCIe core, but I'm certainly no expert, so I may have some dumb comments. Also a few other general comments. On Thu, Jun 16, 2016 at 09:50:35AM +0800, Shawn Lin wrote: > This patch adds Rockchip PCIe controller support found > on RK3399 Soc

Re: [PATCH] acpi: pci_slot: Use generic pr_debug utility

On Friday, May 27, 2016 09:13:29 AM Joe Perches wrote: > Remove the dbg macro and debug module parameter and use > the generic kernel facility. > > Trivially reduces defconfig object size on x86-64 > > $ size drivers/acpi/pci_slot.o* >text data bss dec hex filename >

Re: [PATCH] acpi: pci_slot: Use generic pr_debug utility

On Friday, May 27, 2016 09:13:29 AM Joe Perches wrote: > Remove the dbg macro and debug module parameter and use > the generic kernel facility. > > Trivially reduces defconfig object size on x86-64 > > $ size drivers/acpi/pci_slot.o* >text data bss dec hex filename >

Re: [PATCH] acpi: pci_slot: Use more common logging style

On Friday, May 27, 2016 09:00:28 AM Joe Perches wrote: > Use generic pr_ functions with pr_fmt for info and err. > > This also reduces object size a trivial bit: > > $ size drivers/acpi/pci_slot.o* >text data bss dec hex filename > 935 752 51692

Re: [PATCH] acpi: pci_slot: Use more common logging style

On Friday, May 27, 2016 09:00:28 AM Joe Perches wrote: > Use generic pr_ functions with pr_fmt for info and err. > > This also reduces object size a trivial bit: > > $ size drivers/acpi/pci_slot.o* >text data bss dec hex filename > 935 752 51692

Re: [PATCH V4 1/2] cpufreq: Handle sorted frequency tables more efficiently

On Tuesday, June 07, 2016 03:55:14 PM Viresh Kumar wrote: > cpufreq drivers aren't required to provide a sorted frequency table > today, and even the ones which provide a sorted table aren't handled > efficiently by cpufreq core. > > This patch adds infrastructure to verify if the freq-table

Re: [PATCH V4 1/2] cpufreq: Handle sorted frequency tables more efficiently

On Tuesday, June 07, 2016 03:55:14 PM Viresh Kumar wrote: > cpufreq drivers aren't required to provide a sorted frequency table > today, and even the ones which provide a sorted table aren't handled > efficiently by cpufreq core. > > This patch adds infrastructure to verify if the freq-table

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Wed, Jun 22, 2016 at 9:30 AM, Josh Poimboeuf wrote: > Andy, > > So I got a chance to look at this some more. I'm thinking that to make > this feature more consistently useful, we shouldn't only annotate > pt_regs frames for calls to handlers; other calls should be

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Wed, Jun 22, 2016 at 9:30 AM, Josh Poimboeuf wrote: > Andy, > > So I got a chance to look at this some more. I'm thinking that to make > this feature more consistently useful, we shouldn't only annotate > pt_regs frames for calls to handlers; other calls should be annotated as > well:

[PATCH v2 0/3] Support DAX for device-mapper dm-linear devices

This patch-set adds DAX support to device-mapper dm-linear devices used by LVM. It works with LVM commands as follows: - Creation of a logical volume with all DAX capable devices (such as pmem) sets the logical volume DAX capable as well. - Once a logical volume is set to DAX capable, the

[PATCH v2 2/3] dm: add infrastructure for DAX support

Change mapped device to implement direct_access function, dm_blk_direct_access(), which calls a target direct_access function. 'struct target_type' is extended to have target direct_access interface. This function limits direct accessible size to the dm_target's limit with max_io_len(). Extend

[PATCH v2 0/3] Support DAX for device-mapper dm-linear devices

This patch-set adds DAX support to device-mapper dm-linear devices used by LVM. It works with LVM commands as follows: - Creation of a logical volume with all DAX capable devices (such as pmem) sets the logical volume DAX capable as well. - Once a logical volume is set to DAX capable, the

[PATCH v2 2/3] dm: add infrastructure for DAX support

Change mapped device to implement direct_access function, dm_blk_direct_access(), which calls a target direct_access function. 'struct target_type' is extended to have target direct_access interface. This function limits direct accessible size to the dm_target's limit with max_io_len(). Extend

[PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support

Currently, presence of direct_access() in block_device_operations indicates support of DAX on its block device. Because block_device_operations is instantiated with 'const', this DAX capablity may not be enabled conditinally. In preparation for supporting DAX to device-mapper devices, add

[PATCH v2 3/3] dm linear: add DAX support

Change dm-linear to implement direct_access function, linear_direct_access(), which maps sector and calls direct_access function of its physical target device. Change dm-linear to sets 'dax_supported' when its target physical device supports DAX. Signed-off-by: Toshi Kani

[PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support

Currently, presence of direct_access() in block_device_operations indicates support of DAX on its block device. Because block_device_operations is instantiated with 'const', this DAX capablity may not be enabled conditinally. In preparation for supporting DAX to device-mapper devices, add

[PATCH v2 3/3] dm linear: add DAX support

Change dm-linear to implement direct_access function, linear_direct_access(), which maps sector and calls direct_access function of its physical target device. Change dm-linear to sets 'dax_supported' when its target physical device supports DAX. Signed-off-by: Toshi Kani Cc: Alasdair Kergon

[PATCH] PM / hibernate: Do not free preallocated safe pages during image restore

From: Rafael J. Wysocki The core image restoration code preallocates some safe pages (ie. pages that weren't used by the image kernel before hibernation) for future use before allocating the bulk of memory for loading the image data. Those safe pages are then freed

[PATCH] PM / hibernate: Do not free preallocated safe pages during image restore

From: Rafael J. Wysocki The core image restoration code preallocates some safe pages (ie. pages that weren't used by the image kernel before hibernation) for future use before allocating the bulk of memory for loading the image data. Those safe pages are then freed so they can be allocated

Re: [PATCH] Input: regulator-haptic: fix spelling mistake: "dveice" -> "device"

On Wed, Jun 22, 2016 at 06:02:29PM +0100, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake > > Signed-off-by: Colin Ian King Applied, thank you. > --- > drivers/input/misc/regulator-haptic.c | 2 +- > 1 file

Re: [PATCH] Input: regulator-haptic: fix spelling mistake: "dveice" -> "device"

On Wed, Jun 22, 2016 at 06:02:29PM +0100, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake > > Signed-off-by: Colin Ian King Applied, thank you. > --- > drivers/input/misc/regulator-haptic.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

[PATCH v2] PM / hibernate: Simplify mark_unsafe_pages()

From: Rafael J. Wysocki Rework mark_unsafe_pages() to use a simpler method of clearing all bits in free_pages_map and to set the bits for the "unsafe" pages (ie. pages that were used by the image kernel before hibernation) with the help of duplicate_memory_bitmap().

[PATCH v2] PM / hibernate: Simplify mark_unsafe_pages()

From: Rafael J. Wysocki Rework mark_unsafe_pages() to use a simpler method of clearing all bits in free_pages_map and to set the bits for the "unsafe" pages (ie. pages that were used by the image kernel before hibernation) with the help of duplicate_memory_bitmap(). For this purpose, move the

Re: [RFC] capabilities: add capability cgroup controller

Quoting Kees Cook (keesc...@chromium.org): > On Wed, Jun 22, 2016 at 11:17 AM, Serge E. Hallyn wrote: > > Quoting Topi Miettinen (toiwo...@gmail.com): > >> On 06/22/16 17:14, Serge E. Hallyn wrote: > >> > Quoting Topi Miettinen (toiwo...@gmail.com): > >> >> On 06/21/16 15:45,

Re: [RFC] capabilities: add capability cgroup controller

Quoting Kees Cook (keesc...@chromium.org): > On Wed, Jun 22, 2016 at 11:17 AM, Serge E. Hallyn wrote: > > Quoting Topi Miettinen (toiwo...@gmail.com): > >> On 06/22/16 17:14, Serge E. Hallyn wrote: > >> > Quoting Topi Miettinen (toiwo...@gmail.com): > >> >> On 06/21/16 15:45, Serge E. Hallyn

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

On 23/06/16 03:02, Thiago Jung Bauermann wrote: > Hello Balbir, > Hi Thiago >>> 3. have IMA pass-on its event log (where integrity measurements are >>> >>>registered) accross kexec to the second kernel, so that the event >>>history is preserved. >> >> OK.. and this is safe? Do both the

Re: [PATCH v3 0/9] kexec_file_load implementation for PowerPC

On 23/06/16 03:02, Thiago Jung Bauermann wrote: > Hello Balbir, > Hi Thiago >>> 3. have IMA pass-on its event log (where integrity measurements are >>> >>>registered) accross kexec to the second kernel, so that the event >>>history is preserved. >> >> OK.. and this is safe? Do both the

Re: [PATCH 7/7] staging/android: remove sync framework TODO

Hi Gustavo, On 20 June 2016 at 16:53, Gustavo Padovan wrote: > - - port libsync tests to kselftest I believe the tests haven't landed yet right, so this should stay right ? -Emil

Re: [PATCH 7/7] staging/android: remove sync framework TODO

Hi Gustavo, On 20 June 2016 at 16:53, Gustavo Padovan wrote: > - - port libsync tests to kselftest I believe the tests haven't landed yet right, so this should stay right ? -Emil

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

On Wed, Jun 22, 2016 at 2:48 PM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 5:52 PM, Andy Lutomirski wrote: >> On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu >> wrote: >>> On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy

[RESEND][PATCH] device-tree: nexus7: Remove power gpio key entry and use pmic8xxx-pwrkey

Since the pmic8xxx-pwrkey driver is already supported in the qcom-apq8064.dtsi, and the pmic8xxx-pwrkey supports logic to configure proper device shutdown when ps_hold goes low, it is better to use that driver then a generic gpio button. Thus this patch remove the gpio power key entry here, so we

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

On Wed, Jun 22, 2016 at 2:48 PM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 5:52 PM, Andy Lutomirski wrote: >> On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu >> wrote: >>> On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy Lutomirski wrote: Is there a straightforward way that

[RESEND][PATCH] device-tree: nexus7: Remove power gpio key entry and use pmic8xxx-pwrkey

Since the pmic8xxx-pwrkey driver is already supported in the qcom-apq8064.dtsi, and the pmic8xxx-pwrkey supports logic to configure proper device shutdown when ps_hold goes low, it is better to use that driver then a generic gpio button. Thus this patch remove the gpio power key entry here, so we

Re: adf_ctl_drv.c:(.init.text+0x14915): undefined reference to `adf_init_pf_wq' (was Linux 4.4.13)

On 06/22/16 03:49, Hans de Bruin wrote: > On 06/20/2016 07:17 PM, Randy Dunlap wrote: >> On 06/20/16 08:43, Greg KH wrote: >>> On Sun, Jun 19, 2016 at 09:12:29AM +0200, Hans de Bruin wrote: On 06/08/2016 03:43 AM, Greg KH wrote: > I'm announcing the release of the 4.4.13 kernel. >

Re: adf_ctl_drv.c:(.init.text+0x14915): undefined reference to `adf_init_pf_wq' (was Linux 4.4.13)

On 06/22/16 03:49, Hans de Bruin wrote: > On 06/20/2016 07:17 PM, Randy Dunlap wrote: >> On 06/20/16 08:43, Greg KH wrote: >>> On Sun, Jun 19, 2016 at 09:12:29AM +0200, Hans de Bruin wrote: On 06/08/2016 03:43 AM, Greg KH wrote: > I'm announcing the release of the 4.4.13 kernel. >

Re: [patch] mm, compaction: abort free scanner if split fails

On Wed, 22 Jun 2016, Andrew Morton wrote: > And > mm-compaction-split-freepages-without-holding-the-zone-lock-fix.patch > churns things around some more. Now this: > > > /* Found a free page, will break it into order-0 pages */ > order = page_order(page); >

Re: [patch] mm, compaction: abort free scanner if split fails

On Wed, 22 Jun 2016, Andrew Morton wrote: > And > mm-compaction-split-freepages-without-holding-the-zone-lock-fix.patch > churns things around some more. Now this: > > > /* Found a free page, will break it into order-0 pages */ > order = page_order(page); >

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

Am Mittwoch, 22 Juni 2016, 18:18:01 schrieb Dave Young: > On 06/21/16 at 04:48pm, Thiago Jung Bauermann wrote: > > +/** > > + * kexec_locate_mem_hole - find free memory to load segment or use in > > purgatory + * @image: kexec image being updated. > > + * @size: Memory size. > > + * @align:

Re: [PATCH v3 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

Am Mittwoch, 22 Juni 2016, 18:18:01 schrieb Dave Young: > On 06/21/16 at 04:48pm, Thiago Jung Bauermann wrote: > > +/** > > + * kexec_locate_mem_hole - find free memory to load segment or use in > > purgatory + * @image: kexec image being updated. > > + * @size: Memory size. > > + * @align:

[PATCH 3.14 10/29] ecryptfs: forbid opening files without mmap handler

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Jann Horn commit 2f36db71009304b3f0b95afacd8eba1f9f046b87 upstream. This prevents users from triggering a stack overflow through a recursive invocation of pagefault handling

[PATCH 3.14 10/29] ecryptfs: forbid opening files without mmap handler

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Jann Horn commit 2f36db71009304b3f0b95afacd8eba1f9f046b87 upstream. This prevents users from triggering a stack overflow through a recursive invocation of pagefault handling that involves

<    1   2   3   4   5   6   7   8   9   10   >