All of lore.kernel.org
 help / color / mirror / Atom feed
* [merged] revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
  To: hdegoede, frowand.list, gregkh, paul.burton, regressions, robh+dt,
	stable, tj, mm-commits


The patch titled
     Subject: Revert "console: don't prefer first registered if DT specifies stdout-path"
has been removed from the -mm tree.  Its filename was
     revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Hans de Goede <hdegoede@redhat.com>
Subject: Revert "console: don't prefer first registered if DT specifies stdout-path"

This reverts commit 05fd007e4629 ("console: don't prefer first registered
if DT specifies stdout-path").

The reverted commit changes existing behavior on which many ARM boards
rely.  Many ARM small-board-computers, like e.g.  the Raspberry Pi have
both a video output and a serial console.  Depending on whether the user
is using the device as a more regular computer; or as a headless device we
need to have the console on either one or the other.

Many users rely on the kernel behavior of the console being present on
both outputs, before the reverted commit the console setup with no
console= kernel arguments on an ARM board which sets stdout-path in dt
would look like this:

[root@localhost ~]# cat /proc/consoles
ttyS0                -W- (EC p a)    4:64
tty0                 -WU (E  p  )    4:1

Where as after the reverted commit, it looks like this:

[root@localhost ~]# cat /proc/consoles
ttyS0                -W- (EC p a)    4:64

This commit reverts commit 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") restoring the original behavior.

Fixes: 05fd007e4629 ("console: don't prefer first registered if DT specifies stdout-path")
Link: http://lkml.kernel.org/r/20161104121135.4780-2-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/of/base.c       |    2 --
 include/linux/console.h |    6 ------
 kernel/printk/printk.c  |   13 +------------
 3 files changed, 1 insertion(+), 20 deletions(-)

diff -puN drivers/of/base.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path drivers/of/base.c
--- a/drivers/of/base.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/drivers/of/base.c
@@ -2077,8 +2077,6 @@ void of_alias_scan(void * (*dt_alloc)(u6
 			name = of_get_property(of_aliases, "stdout", NULL);
 		if (name)
 			of_stdout = of_find_node_opts_by_path(name, &of_stdout_options);
-		if (of_stdout)
-			console_set_by_of();
 	}
 
 	if (!of_aliases)
diff -puN include/linux/console.h~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path include/linux/console.h
--- a/include/linux/console.h~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/include/linux/console.h
@@ -173,12 +173,6 @@ static inline void console_sysfs_notify(
 #endif
 extern bool console_suspend_enabled;
 
-#ifdef CONFIG_OF
-extern void console_set_by_of(void);
-#else
-static inline void console_set_by_of(void) {}
-#endif
-
 /* Suspend and resume console messages over PM events */
 extern void suspend_console(void);
 extern void resume_console(void);
diff -puN kernel/printk/printk.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path kernel/printk/printk.c
--- a/kernel/printk/printk.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/kernel/printk/printk.c
@@ -253,17 +253,6 @@ static int preferred_console = -1;
 int console_set_on_cmdline;
 EXPORT_SYMBOL(console_set_on_cmdline);
 
-#ifdef CONFIG_OF
-static bool of_specified_console;
-
-void console_set_by_of(void)
-{
-	of_specified_console = true;
-}
-#else
-# define of_specified_console false
-#endif

^ permalink raw reply

* [merged] revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
  To: hdegoede, frowand.list, gregkh, paul.burton, regressions, robh+dt,
	stable, tj, mm-commits


The patch titled
     Subject: Revert "console: don't prefer first registered if DT specifies stdout-path"
has been removed from the -mm tree.  Its filename was
     revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Hans de Goede <hdegoede@redhat.com>
Subject: Revert "console: don't prefer first registered if DT specifies stdout-path"

This reverts commit 05fd007e4629 ("console: don't prefer first registered
if DT specifies stdout-path").

The reverted commit changes existing behavior on which many ARM boards
rely.  Many ARM small-board-computers, like e.g.  the Raspberry Pi have
both a video output and a serial console.  Depending on whether the user
is using the device as a more regular computer; or as a headless device we
need to have the console on either one or the other.

Many users rely on the kernel behavior of the console being present on
both outputs, before the reverted commit the console setup with no
console= kernel arguments on an ARM board which sets stdout-path in dt
would look like this:

[root@localhost ~]# cat /proc/consoles
ttyS0                -W- (EC p a)    4:64
tty0                 -WU (E  p  )    4:1

Where as after the reverted commit, it looks like this:

[root@localhost ~]# cat /proc/consoles
ttyS0                -W- (EC p a)    4:64

This commit reverts commit 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") restoring the original behavior.

Fixes: 05fd007e4629 ("console: don't prefer first registered if DT specifies stdout-path")
Link: http://lkml.kernel.org/r/20161104121135.4780-2-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/of/base.c       |    2 --
 include/linux/console.h |    6 ------
 kernel/printk/printk.c  |   13 +------------
 3 files changed, 1 insertion(+), 20 deletions(-)

diff -puN drivers/of/base.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path drivers/of/base.c
--- a/drivers/of/base.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/drivers/of/base.c
@@ -2077,8 +2077,6 @@ void of_alias_scan(void * (*dt_alloc)(u6
 			name = of_get_property(of_aliases, "stdout", NULL);
 		if (name)
 			of_stdout = of_find_node_opts_by_path(name, &of_stdout_options);
-		if (of_stdout)
-			console_set_by_of();
 	}
 
 	if (!of_aliases)
diff -puN include/linux/console.h~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path include/linux/console.h
--- a/include/linux/console.h~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/include/linux/console.h
@@ -173,12 +173,6 @@ static inline void console_sysfs_notify(
 #endif
 extern bool console_suspend_enabled;
 
-#ifdef CONFIG_OF
-extern void console_set_by_of(void);
-#else
-static inline void console_set_by_of(void) {}
-#endif
-
 /* Suspend and resume console messages over PM events */
 extern void suspend_console(void);
 extern void resume_console(void);
diff -puN kernel/printk/printk.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path kernel/printk/printk.c
--- a/kernel/printk/printk.c~revert-console-dont-prefer-first-registered-if-dt-specifies-stdout-path
+++ a/kernel/printk/printk.c
@@ -253,17 +253,6 @@ static int preferred_console = -1;
 int console_set_on_cmdline;
 EXPORT_SYMBOL(console_set_on_cmdline);
 
-#ifdef CONFIG_OF
-static bool of_specified_console;
-
-void console_set_by_of(void)
-{
-	of_specified_console = true;
-}
-#else
-# define of_specified_console false
-#endif
-
 /* Flag: console code may call schedule() */
 static int console_may_schedule;
 
@@ -2657,7 +2646,7 @@ void register_console(struct console *ne
 	 *	didn't select a console we take the first one
 	 *	that registers here.
 	 */
-	if (preferred_console < 0 && !of_specified_console) {
+	if (preferred_console < 0) {
 		if (newcon->index < 0)
 			newcon->index = 0;
 		if (newcon->setup == NULL ||
_

Patches currently in -mm which might be from hdegoede@redhat.com are



^ permalink raw reply

* [merged] ocfs2-fix-not-enough-credit-panic.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
  To: junxiao.bi, jlbec, joseph.qi, mfasheh, mm-commits


The patch titled
     Subject: ocfs2: fix not enough credit panic
has been removed from the -mm tree.  Its filename was
     ocfs2-fix-not-enough-credit-panic.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Junxiao Bi <junxiao.bi@oracle.com>
Subject: ocfs2: fix not enough credit panic

The following panic was caught when run ocfs2 disconfig single test (block
size 512 and cluster size 8192).  ocfs2_journal_dirty() return -ENOSPC,
that means credits were used up.  The total credit should include 3 times
of "num_dx_leaves" from ocfs2_dx_dir_rebalance(), because 2 times will be
consumed in ocfs2_dx_dir_transfer_leaf() and 1 time will be consumed in
ocfs2_dx_dir_new_cluster()->
__ocfs2_dx_dir_new_cluster()->ocfs2_dx_dir_format_cluster().  But only two
times is included in ocfs2_dx_dir_rebalance_credits(), fix it.  This can
cause read-only fs(v4.1+) or panic for mainline linux depending on mount
option.

[34377.331151] ------------[ cut here ]------------
[34377.332007] kernel BUG at fs/ocfs2/journal.c:775!
[34377.344107] invalid opcode: 0000 [#1] SMP
[34377.346090] Modules linked in: ocfs2 nfsd lockd grace nfs_acl auth_rpcgss sunrpc autofs4 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sd_mod sg ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ppdev xen_kbdfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea parport_pc parport acpi_cpufreq i2c_piix4 i2c_core pcspkr ext4 jbd2 mbcache xen_blkfront floppy pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod
[34377.346090] CPU: 2 PID: 10601 Comm: dd Not tainted 4.1.12-71.el6uek.bug24939243.x86_64 #2
[34377.346090] Hardware name: Xen HVM domU, BIOS 4.4.4OVM 02/11/2016
[34377.346090] task: ffff8800b6de6200 ti: ffff8800a7d48000 task.ti: ffff8800a7d48000
[34377.346090] RIP: 0010:[<ffffffffa06e7397>]  [<ffffffffa06e7397>] ocfs2_journal_dirty+0xa7/0xb0 [ocfs2]
[34377.346090] RSP: 0018:ffff8800a7d4b6d8  EFLAGS: 00010286
[34377.346090] RAX: 00000000ffffffe4 RBX: 00000000814d0a9c RCX: 00000000000004f9
[34377.346090] RDX: ffffffffa008e990 RSI: ffffffffa008f1ee RDI: ffff8800622b6460
[34377.346090] RBP: ffff8800a7d4b6f8 R08: ffffffffa008f288 R09: ffff8800622b6460
[34377.346090] R10: 0000000000000000 R11: 0000000000000282 R12: 0000000002c8421e
[34377.346090] R13: ffff88006d0cad00 R14: ffff880092beef60 R15: 0000000000000070
[34377.346090] FS:  00007f9b83e92700(0000) GS:ffff8800be880000(0000) knlGS:0000000000000000
[34377.346090] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[34377.346090] CR2: 00007fb2c0d1a000 CR3: 0000000008f80000 CR4: 00000000000406e0
[34377.346090] Stack:
[34377.346090]  00000000814d0a9c ffff88005fe61e00 ffff88006e995c00 ffff880009847c00
[34377.346090]  ffff8800a7d4b768 ffffffffa06c0999 ffff88009d3c2a10 ffff88005fe61e30
[34377.346090]  ffff8800997ce500 ffff8800997ce980 ffff880092beef60 000000100000000e
[34377.346090] Call Trace:
[34377.346090]  [<ffffffffa06c0999>] ocfs2_dx_dir_transfer_leaf+0x159/0x1a0 [ocfs2]
[34377.346090]  [<ffffffffa06c3eeb>] ocfs2_dx_dir_rebalance+0xd9b/0xea0 [ocfs2]
[34377.346090]  [<ffffffffa06dedb2>] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2]
[34377.346090]  [<ffffffffa0761180>] ? ocfs2_refcount_tree_et_ops+0x60/0xfffffffffffe4b31 [ocfs2]
[34377.346090]  [<ffffffffa06e7730>] ? ocfs2_journal_access_dl+0x20/0x20 [ocfs2]
[34377.346090]  [<ffffffffa06c6b63>] ocfs2_find_dir_space_dx+0xd3/0x300 [ocfs2]
[34377.346090]  [<ffffffffa06c9709>] ocfs2_prepare_dx_dir_for_insert+0x219/0x450 [ocfs2]
[34377.346090]  [<ffffffffa06c9b16>] ocfs2_prepare_dir_for_insert+0x1d6/0x580 [ocfs2]
[34377.346090]  [<ffffffffa06dee90>] ? ocfs2_read_inode_block+0x10/0x20 [ocfs2]
[34377.346090]  [<ffffffffa06f38e2>] ocfs2_mknod+0x5a2/0x1400 [ocfs2]
[34377.346090]  [<ffffffffa06f4933>] ocfs2_create+0x73/0x180 [ocfs2]
[34377.346090]  [<ffffffff81211de8>] vfs_create+0xd8/0x100
[34377.346090]  [<ffffffff8120f5fd>] ? lookup_real+0x1d/0x60
[34377.346090]  [<ffffffff81212535>] lookup_open+0x185/0x1c0
[34377.346090]  [<ffffffff8121571d>] do_last+0x36d/0x780
[34377.346090]  [<ffffffff812a85d6>] ? security_file_alloc+0x16/0x20
[34377.346090]  [<ffffffff81215bc2>] path_openat+0x92/0x470
[34377.346090]  [<ffffffff81215fea>] do_filp_open+0x4a/0xa0
[34377.346090]  [<ffffffff8132c570>] ? find_next_zero_bit+0x10/0x20
[34377.346090]  [<ffffffff812232ec>] ? __alloc_fd+0xac/0x150
[34377.346090]  [<ffffffff8120459a>] do_sys_open+0x11a/0x230
[34377.346090]  [<ffffffff810259d3>] ? syscall_trace_enter_phase1+0x153/0x180
[34377.346090]  [<ffffffff812046ee>] SyS_open+0x1e/0x20
[34377.346090]  [<ffffffff816cb6ee>] system_call_fastpath+0x12/0x71
[34377.346090] Code: 1d 3f 29 09 00 48 85 db 74 1f 48 8b 03 0f 1f 80 00 00 00 00 48 8b 7b 08 48 83 c3 10 4c 89 e6 ff d0 48 8b 03 48 85 c0 75 eb eb 90 <0f> 0b eb fe 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54
[34377.346090] RIP  [<ffffffffa06e7397>] ocfs2_journal_dirty+0xa7/0xb0 [ocfs2]
[34377.346090]  RSP <ffff8800a7d4b6d8>
[34377.615401] ---[ end trace 91ac5312a6ee1288 ]---
[34377.618919] Kernel panic - not syncing: Fatal exception
[34377.619910] Kernel Offset: disabled

Link: http://lkml.kernel.org/r/1478248135-31963-1-git-send-email-junxiao.bi@oracle.com
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Mark Fasheh <mfasheh@versity.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Joseph Qi <joseph.qi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 fs/ocfs2/dir.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN fs/ocfs2/dir.c~ocfs2-fix-not-enough-credit-panic fs/ocfs2/dir.c
--- a/fs/ocfs2/dir.c~ocfs2-fix-not-enough-credit-panic
+++ a/fs/ocfs2/dir.c
@@ -3699,7 +3699,7 @@ static void ocfs2_dx_dir_transfer_leaf(s
 static int ocfs2_dx_dir_rebalance_credits(struct ocfs2_super *osb,
 					  struct ocfs2_dx_root_block *dx_root)
 {
-	int credits = ocfs2_clusters_to_blocks(osb->sb, 2);
+	int credits = ocfs2_clusters_to_blocks(osb->sb, 3);
 
 	credits += ocfs2_calc_extend_credits(osb->sb, &dx_root->dr_list);
 	credits += ocfs2_quota_trans_credits(osb->sb);
_

Patches currently in -mm which might be from junxiao.bi@oracle.com are



^ permalink raw reply

* [ANNOUNCE] libdrm 2.4.73
From: Emil Velikov @ 2016-11-14 20:03 UTC (permalink / raw)
  To: xorg-announce; +Cc: ML dri-devel

Emil Velikov (3):
      headers: Add README file
      xd86drm: read more than 128 bytes of uevent in drmParsePciBusInfo
      Bump version for release

git tag: libdrm-2.4.73

https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.bz2
MD5:  bc1cee09cde72ffe3b952e8f50ccdaa8  libdrm-2.4.73.tar.bz2
SHA1: 7abe64965ac4aa77d51746e70d6f2a38f100483d  libdrm-2.4.73.tar.bz2
SHA256: 96bfd39242fe168017d95f22e141645a35591f5902a7d98c2fa4ca8c31df5e4d
 libdrm-2.4.73.tar.bz2
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.bz2.sig

https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.gz
MD5:  595a17e209f27602d3b1198e9a03e2d0  libdrm-2.4.73.tar.gz
SHA1: dd2e4993c8ee56b8f363e667e00e8aef1a7a733b  libdrm-2.4.73.tar.gz
SHA256: 047d3073e3ecdf06e5419f74f8de8543e59f83d451c37519db4b6c8393620bfe
 libdrm-2.4.73.tar.gz
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.gz.sig
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* [merged] mm-hugetlb-fix-huge-page-reservation-leak-in-private-mapping-error-paths.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
  To: mike.kravetz, aneesh.kumar, dave.hansen, hillf.zj, jstancek,
	kirill.shutemov, mhocko, n-horiguchi, stable, mm-commits


The patch titled
     Subject: mm/hugetlb: fix huge page reservation leak in private mapping error paths
has been removed from the -mm tree.  Its filename was
     mm-hugetlb-fix-huge-page-reservation-leak-in-private-mapping-error-paths.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Mike Kravetz <mike.kravetz@oracle.com>
Subject: mm/hugetlb: fix huge page reservation leak in private mapping error paths

Error paths in hugetlb_cow() and hugetlb_no_page() may free a newly
allocated huge page.  If a reservation was associated with the huge page,
alloc_huge_page() consumed the reservation while allocating.  When the
newly allocated page is freed in free_huge_page(), it will increment the
global reservation count.  However, the reservation entry in the reserve
map will remain.  This is not an issue for shared mappings as the entry in
the reserve map indicates a reservation exists.  But, an entry in a
private mapping reserve map indicates the reservation was consumed and no
longer exists.  This results in an inconsistency between the reserve map
and the global reservation count.  This 'leaks' a reserved huge page.

Create a new routine restore_reserve_on_error() to restore the reserve
entry in these specific error paths.  This routine makes use of a new
function vma_add_reservation() which will add a reserve entry for a
specific address/page.

In general, these error paths were rarely (if ever) taken on most
architectures.  However, powerpc contained arch specific code that that
resulted in an extra fault and execution of these error paths on all
private mappings.

Fixes: 67961f9db8c4 ("mm/hugetlb: fix huge page reserve accounting for private mappings)
Link: http://lkml.kernel.org/r/1476933077-23091-2-git-send-email-mike.kravetz@oracle.com
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Reported-by: Jan Stancek <jstancek@redhat.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kirill A . Shutemov <kirill.shutemov@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/hugetlb.c |   66 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff -puN mm/hugetlb.c~mm-hugetlb-fix-huge-page-reservation-leak-in-private-mapping-error-paths mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-fix-huge-page-reservation-leak-in-private-mapping-error-paths
+++ a/mm/hugetlb.c
@@ -1826,11 +1826,17 @@ static void return_unused_surplus_pages(
  * is not the case is if a reserve map was changed between calls.  It
  * is the responsibility of the caller to notice the difference and
  * take appropriate action.
+ *
+ * vma_add_reservation is used in error paths where a reservation must
+ * be restored when a newly allocated huge page must be freed.  It is
+ * to be called after calling vma_needs_reservation to determine if a
+ * reservation exists.
  */
 enum vma_resv_mode {
 	VMA_NEEDS_RESV,
 	VMA_COMMIT_RESV,
 	VMA_END_RESV,
+	VMA_ADD_RESV,
 };
 static long __vma_reservation_common(struct hstate *h,
 				struct vm_area_struct *vma, unsigned long addr,
@@ -1856,6 +1862,14 @@ static long __vma_reservation_common(str
 		region_abort(resv, idx, idx + 1);
 		ret = 0;
 		break;
+	case VMA_ADD_RESV:
+		if (vma->vm_flags & VM_MAYSHARE)
+			ret = region_add(resv, idx, idx + 1);
+		else {
+			region_abort(resv, idx, idx + 1);
+			ret = region_del(resv, idx, idx + 1);
+		}
+		break;
 	default:
 		BUG();
 	}
@@ -1903,6 +1917,56 @@ static void vma_end_reservation(struct h
 	(void)__vma_reservation_common(h, vma, addr, VMA_END_RESV);
 }
 
+static long vma_add_reservation(struct hstate *h,
+			struct vm_area_struct *vma, unsigned long addr)
+{
+	return __vma_reservation_common(h, vma, addr, VMA_ADD_RESV);
+}
+
+/*
+ * This routine is called to restore a reservation on error paths.  In the
+ * specific error paths, a huge page was allocated (via alloc_huge_page)
+ * and is about to be freed.  If a reservation for the page existed,
+ * alloc_huge_page would have consumed the reservation and set PagePrivate
+ * in the newly allocated page.  When the page is freed via free_huge_page,
+ * the global reservation count will be incremented if PagePrivate is set.
+ * However, free_huge_page can not adjust the reserve map.  Adjust the
+ * reserve map here to be consistent with global reserve count adjustments
+ * to be made by free_huge_page.
+ */
+static void restore_reserve_on_error(struct hstate *h,
+			struct vm_area_struct *vma, unsigned long address,
+			struct page *page)
+{
+	if (unlikely(PagePrivate(page))) {
+		long rc = vma_needs_reservation(h, vma, address);
+
+		if (unlikely(rc < 0)) {
+			/*
+			 * Rare out of memory condition in reserve map
+			 * manipulation.  Clear PagePrivate so that
+			 * global reserve count will not be incremented
+			 * by free_huge_page.  This will make it appear
+			 * as though the reservation for this page was
+			 * consumed.  This may prevent the task from
+			 * faulting in the page at a later time.  This
+			 * is better than inconsistent global huge page
+			 * accounting of reserve counts.
+			 */
+			ClearPagePrivate(page);
+		} else if (rc) {
+			rc = vma_add_reservation(h, vma, address);
+			if (unlikely(rc < 0))
+				/*
+				 * See above comment about rare out of
+				 * memory condition.
+				 */
+				ClearPagePrivate(page);
+		} else
+			vma_end_reservation(h, vma, address);
+	}
+}
+
 struct page *alloc_huge_page(struct vm_area_struct *vma,
 				    unsigned long addr, int avoid_reserve)
 {
@@ -3498,6 +3562,7 @@ retry_avoidcopy:
 	spin_unlock(ptl);
 	mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
 out_release_all:
+	restore_reserve_on_error(h, vma, address, new_page);
 	put_page(new_page);
 out_release_old:
 	put_page(old_page);
@@ -3680,6 +3745,7 @@ backout:
 	spin_unlock(ptl);
 backout_unlocked:
 	unlock_page(page);
+	restore_reserve_on_error(h, vma, address, page);
 	put_page(page);
 	goto out;
 }
_

Patches currently in -mm which might be from mike.kravetz@oracle.com are



^ permalink raw reply

* [merged] mm-filemap-dont-allow-partially-uptodate-page-for-pipes.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
  To: guaneryu, jack, viro, mm-commits


The patch titled
     Subject: mm/filemap: don't allow partially uptodate page for pipes
has been removed from the -mm tree.  Its filename was
     mm-filemap-dont-allow-partially-uptodate-page-for-pipes.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Eryu Guan <guaneryu@gmail.com>
Subject: mm/filemap: don't allow partially uptodate page for pipes

Starting from 4.9-rc1 kernel, I started noticing some test failures of
sendfile(2) and splice(2) (sendfile0N and splice01 from LTP) when testing
on sub-page block size filesystems (tested both XFS and ext4), these
syscalls start to return EIO in the tests.  e.g.

sendfile02    1  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return expected value, expected: 26, got: -1
sendfile02    2  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return expected value, expected: 24, got: -1
sendfile02    3  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return expected value, expected: 22, got: -1
sendfile02    4  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return expected value, expected: 20, got: -1

This is because that in sub-page block size cases, we don't need the whole
page to be uptodate, only the part we care about is uptodate is OK (if fs
has ->is_partially_uptodate defined).  But page_cache_pipe_buf_confirm()
doesn't have the ability to check the partially-uptodate case, it needs
the whole page to be uptodate.  So it returns EIO in this case.

This is a regression introduced by commit 82c156f85384 ("switch
generic_file_splice_read() to use of ->read_iter()").  Prior to the
change, generic_file_splice_read() doesn't allow partially-uptodate page
either, so it worked fine.

Fix it by skipping the partially-uptodate check if we're working on a pipe
in do_generic_file_read(), so we read the whole page from disk as long as
the page is not uptodate.

I think the other way to fix it is to add the ability to check & allow
partially-uptodate page to page_cache_pipe_buf_confirm(), but that is much
harder to do and seems gain little.

Link: http://lkml.kernel.org/r/1477986187-12717-1-git-send-email-guaneryu@gmail.com
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/filemap.c |    3 +++
 1 file changed, 3 insertions(+)

diff -puN mm/filemap.c~mm-filemap-dont-allow-partially-uptodate-page-for-pipes mm/filemap.c
--- a/mm/filemap.c~mm-filemap-dont-allow-partially-uptodate-page-for-pipes
+++ a/mm/filemap.c
@@ -1732,6 +1732,9 @@ find_page:
 			if (inode->i_blkbits == PAGE_SHIFT ||
 					!mapping->a_ops->is_partially_uptodate)
 				goto page_not_up_to_date;
+			/* pipes can't handle partially uptodate pages */
+			if (unlikely(iter->type & ITER_PIPE))
+				goto page_not_up_to_date;
 			if (!trylock_page(page))
 				goto page_not_up_to_date;
 			/* Did it get truncated before we got the lock? */
_

Patches currently in -mm which might be from guaneryu@gmail.com are



^ permalink raw reply

* [merged] coredump-fix-unfreezable-coredumping-task.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
  To: aryabinin, mhocko, oleg, pavel, rjw, stable, tj, viro, mm-commits


The patch titled
     Subject: coredump: fix unfreezable coredumping task
has been removed from the -mm tree.  Its filename was
     coredump-fix-unfreezable-coredumping-task.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Subject: coredump: fix unfreezable coredumping task

It could be not possible to freeze coredumping task when it waits for
'core_state->startup' completion, because threads are frozen in
get_signal() before they got a chance to complete 'core_state->startup'.

Inability to freeze a task during suspend will cause suspend to fail. 
Also CRIU uses cgroup freezer during dump operation.  So with an
unfreezable task the CRIU dump will fail because it waits for a
transition from 'FREEZING' to 'FROZEN' state which will never happen.

Use freezer_do_not_count() to tell freezer to ignore coredumping task
while it waits for core_state->startup completion.

Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 fs/coredump.c |    3 +++
 1 file changed, 3 insertions(+)

diff -puN fs/coredump.c~coredump-fix-unfreezable-coredumping-task fs/coredump.c
--- a/fs/coredump.c~coredump-fix-unfreezable-coredumping-task
+++ a/fs/coredump.c
@@ -1,6 +1,7 @@
 #include <linux/slab.h>
 #include <linux/file.h>
 #include <linux/fdtable.h>
+#include <linux/freezer.h>
 #include <linux/mm.h>
 #include <linux/stat.h>
 #include <linux/fcntl.h>
@@ -423,7 +424,9 @@ static int coredump_wait(int exit_code,
 	if (core_waiters > 0) {
 		struct core_thread *ptr;
 
+		freezer_do_not_count();
 		wait_for_completion(&core_state->startup);
+		freezer_count();
 		/*
 		 * Wait for all the threads to become inactive, so that
 		 * all the thread context (extended register state, like
_

Patches currently in -mm which might be from aryabinin@virtuozzo.com are



^ permalink raw reply

* [merged] coredump-fix-unfreezable-coredumping-task.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
  To: aryabinin, mhocko, oleg, pavel, rjw, stable, tj, viro, mm-commits


The patch titled
     Subject: coredump: fix unfreezable coredumping task
has been removed from the -mm tree.  Its filename was
     coredump-fix-unfreezable-coredumping-task.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Subject: coredump: fix unfreezable coredumping task

It could be not possible to freeze coredumping task when it waits for
'core_state->startup' completion, because threads are frozen in
get_signal() before they got a chance to complete 'core_state->startup'.

Inability to freeze a task during suspend will cause suspend to fail. 
Also CRIU uses cgroup freezer during dump operation.  So with an
unfreezable task the CRIU dump will fail because it waits for a
transition from 'FREEZING' to 'FROZEN' state which will never happen.

Use freezer_do_not_count() to tell freezer to ignore coredumping task
while it waits for core_state->startup completion.

Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Tejun Heo <tj@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 fs/coredump.c |    3 +++
 1 file changed, 3 insertions(+)

diff -puN fs/coredump.c~coredump-fix-unfreezable-coredumping-task fs/coredump.c
--- a/fs/coredump.c~coredump-fix-unfreezable-coredumping-task
+++ a/fs/coredump.c
@@ -1,6 +1,7 @@
 #include <linux/slab.h>
 #include <linux/file.h>
 #include <linux/fdtable.h>
+#include <linux/freezer.h>
 #include <linux/mm.h>
 #include <linux/stat.h>
 #include <linux/fcntl.h>
@@ -423,7 +424,9 @@ static int coredump_wait(int exit_code,
 	if (core_waiters > 0) {
 		struct core_thread *ptr;
 
+		freezer_do_not_count();
 		wait_for_completion(&core_state->startup);
+		freezer_count();
 		/*
 		 * Wait for all the threads to become inactive, so that
 		 * all the thread context (extended register state, like
_

Patches currently in -mm which might be from aryabinin@virtuozzo.com are



^ permalink raw reply

* [merged] memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
  To: gthelen, cl, hannes, iamjoonsoo.kim, mhocko, penberg, rientjes,
	thgarnie, vdavydov.dev, mm-commits


The patch titled
     Subject: memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB
has been removed from the -mm tree.  Its filename was
     memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Greg Thelen <gthelen@google.com>
Subject: memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB

While testing OBJFREELIST_SLAB integration with pagealloc, we found a bug
where kmem_cache(sys) would be created with both CFLGS_OFF_SLAB &
CFLGS_OBJFREELIST_SLAB.  When it happened, critical allocations needed for
loading drivers or creating new caches will fail.

The original kmem_cache is created early making OFF_SLAB not possible. 
When kmem_cache(sys) is created, OFF_SLAB is possible and if pagealloc is
enabled it will try to enable it first under certain conditions.  Given
kmem_cache(sys) reuses the original flag, you can have both flags at the
same time resulting in allocation failures and odd behaviors.

This fix discards allocator specific flags from memcg before calling
create_cache.

The bug exists since 4.6-rc1 and affects testing debug pagealloc
configurations.

Fixes: b03a017bebc4 ("mm/slab: introduce new slab management type, OBJFREELIST_SLAB")
Link: http://lkml.kernel.org/r/1478553075-120242-1-git-send-email-thgarnie@google.com
Signed-off-by: Greg Thelen <gthelen@google.com>
Signed-off-by: Thomas Garnier <thgarnie@google.com>
Tested-by: Thomas Garnier <thgarnie@google.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/slab_common.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -puN mm/slab_common.c~memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab mm/slab_common.c
--- a/mm/slab_common.c~memcg-prevent-memcg-caches-to-be-both-off_slab-objfreelist_slab
+++ a/mm/slab_common.c
@@ -533,8 +533,8 @@ void memcg_create_kmem_cache(struct mem_
 
 	s = create_cache(cache_name, root_cache->object_size,
 			 root_cache->size, root_cache->align,
-			 root_cache->flags, root_cache->ctor,
-			 memcg, root_cache);
+			 root_cache->flags & CACHE_CREATE_MASK,
+			 root_cache->ctor, memcg, root_cache);
 	/*
 	 * If we could not create a memcg cache, do not complain, because
 	 * that's not critical at all as we can always proceed with the root
_

Patches currently in -mm which might be from gthelen@google.com are

mm-slab-faster-active-and-free-stats.patch


^ permalink raw reply

* [merged] mm-kmemleak-scan-dataro_after_init.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
  To: jakub.kicinski, arnd, catalin.marinas, heiko.carstens, johannes,
	schwidefsky, xiyou.wangcong, mm-commits


The patch titled
     Subject: mm: kmemleak: scan .data.ro_after_init
has been removed from the -mm tree.  Its filename was
     mm-kmemleak-scan-dataro_after_init.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: mm: kmemleak: scan .data.ro_after_init

Limit the number of kmemleak false positives by including
.data.ro_after_init in memory scanning.  To achieve this we need to add
symbols for start and end of the section to the linker scripts.

The problem was been uncovered by commit 56989f6d8568 ("genetlink: mark
families as __ro_after_init").

Link: http://lkml.kernel.org/r/1478274173-15218-1-git-send-email-jakub.kicinski@netronome.com
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/s390/kernel/vmlinux.lds.S    |    2 ++
 include/asm-generic/sections.h    |    3 +++
 include/asm-generic/vmlinux.lds.h |    5 ++++-
 mm/kmemleak.c                     |    1 +
 4 files changed, 10 insertions(+), 1 deletion(-)

diff -puN arch/s390/kernel/vmlinux.lds.S~mm-kmemleak-scan-dataro_after_init arch/s390/kernel/vmlinux.lds.S
--- a/arch/s390/kernel/vmlinux.lds.S~mm-kmemleak-scan-dataro_after_init
+++ a/arch/s390/kernel/vmlinux.lds.S
@@ -62,9 +62,11 @@ SECTIONS
 
 	. = ALIGN(PAGE_SIZE);
 	__start_ro_after_init = .;
+	__start_data_ro_after_init = .;
 	.data..ro_after_init : {
 		 *(.data..ro_after_init)
 	}
+	__end_data_ro_after_init = .;
 	EXCEPTION_TABLE(16)
 	. = ALIGN(PAGE_SIZE);
 	__end_ro_after_init = .;
diff -puN include/asm-generic/sections.h~mm-kmemleak-scan-dataro_after_init include/asm-generic/sections.h
--- a/include/asm-generic/sections.h~mm-kmemleak-scan-dataro_after_init
+++ a/include/asm-generic/sections.h
@@ -14,6 +14,8 @@
  * [_sdata, _edata]: contains .data.* sections, may also contain .rodata.*
  *                   and/or .init.* sections.
  * [__start_rodata, __end_rodata]: contains .rodata.* sections
+ * [__start_data_ro_after_init, __end_data_ro_after_init]:
+ *		     contains data.ro_after_init section
  * [__init_begin, __init_end]: contains .init.* sections, but .init.text.*
  *                   may be out of this range on some architectures.
  * [_sinittext, _einittext]: contains .init.text.* sections
@@ -31,6 +33,7 @@ extern char _data[], _sdata[], _edata[];
 extern char __bss_start[], __bss_stop[];
 extern char __init_begin[], __init_end[];
 extern char _sinittext[], _einittext[];
+extern char __start_data_ro_after_init[], __end_data_ro_after_init[];
 extern char _end[];
 extern char __per_cpu_load[], __per_cpu_start[], __per_cpu_end[];
 extern char __kprobes_text_start[], __kprobes_text_end[];
diff -puN include/asm-generic/vmlinux.lds.h~mm-kmemleak-scan-dataro_after_init include/asm-generic/vmlinux.lds.h
--- a/include/asm-generic/vmlinux.lds.h~mm-kmemleak-scan-dataro_after_init
+++ a/include/asm-generic/vmlinux.lds.h
@@ -259,7 +259,10 @@
  * own by defining an empty RO_AFTER_INIT_DATA.
  */
 #ifndef RO_AFTER_INIT_DATA
-#define RO_AFTER_INIT_DATA *(.data..ro_after_init)
+#define RO_AFTER_INIT_DATA						\
+	__start_data_ro_after_init = .;					\
+	*(.data..ro_after_init)						\
+	__end_data_ro_after_init = .;
 #endif
 
 /*
diff -puN mm/kmemleak.c~mm-kmemleak-scan-dataro_after_init mm/kmemleak.c
--- a/mm/kmemleak.c~mm-kmemleak-scan-dataro_after_init
+++ a/mm/kmemleak.c
@@ -1414,6 +1414,7 @@ static void kmemleak_scan(void)
 	/* data/bss scanning */
 	scan_large_block(_sdata, _edata);
 	scan_large_block(__bss_start, __bss_stop);
+	scan_large_block(__start_data_ro_after_init, __end_data_ro_after_init);
 
 #ifdef CONFIG_SMP
 	/* per-cpu sections scanning */
_

Patches currently in -mm which might be from jakub.kicinski@netronome.com are



^ permalink raw reply

* [merged] lib-stackdepot-export-save-fetch-stack-for-drivers.patch removed from -mm tree
From: akpm @ 2016-11-14 20:03 UTC (permalink / raw)
  To: chris, aryabinin, daniel.vetter, dvyukov, glider, iamjoonsoo.kim,
	kirill, mm-commits


The patch titled
     Subject: lib/stackdepot: export save/fetch stack for drivers
has been removed from the -mm tree.  Its filename was
     lib-stackdepot-export-save-fetch-stack-for-drivers.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: lib/stackdepot: export save/fetch stack for drivers

Some drivers would like to record stacktraces in order to aide leak
tracing.  As stackdepot already provides a facility for only storing the
unique traces, thereby reducing the memory required, export that
functionality for use by drivers.

The code was originally created for KASAN and moved under lib in commit
cd11016e5f521 ("mm, kasan: stackdepot implementation.  Enable stackdepot
for SLAB") so that it could be shared with mm/.  In turn, we want to share
it now with drivers.

Link: http://lkml.kernel.org/r/20161108133209.22704-1-chris@chris-wilson.co.uk
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 lib/stackdepot.c |    2 ++
 1 file changed, 2 insertions(+)

diff -puN lib/stackdepot.c~lib-stackdepot-export-save-fetch-stack-for-drivers lib/stackdepot.c
--- a/lib/stackdepot.c~lib-stackdepot-export-save-fetch-stack-for-drivers
+++ a/lib/stackdepot.c
@@ -192,6 +192,7 @@ void depot_fetch_stack(depot_stack_handl
 	trace->entries = stack->entries;
 	trace->skip = 0;
 }
+EXPORT_SYMBOL_GPL(depot_fetch_stack);
 
 /**
  * depot_save_stack - save stack in a stack depot.
@@ -283,3 +284,4 @@ exit:
 fast_exit:
 	return retval;
 }
+EXPORT_SYMBOL_GPL(depot_save_stack);
_

Patches currently in -mm which might be from chris@chris-wilson.co.uk are



^ permalink raw reply

* Re: [PATCH 2/2] clk: hisilicon: add CRG driver for Hi3516CV300 SoC
From: Stephen Boyd @ 2016-11-14 20:03 UTC (permalink / raw)
  To: Jiancheng Xue
  Cc: mturquette, robh+dt, mark.rutland, linux-kernel, linux-clk,
	devicetree, bin.chen, elder, hermit.wangheming, yanhaifeng,
	wenpan, howell.yang
In-Reply-To: <0c3b49a4-f58c-253a-fd87-ab52b0b26010@hisilicon.com>

On 11/14, Jiancheng Xue wrote:
> Hi Stephen,
> 
> On 2016/11/12 8:04, Stephen Boyd wrote:
> > On 10/29, Jiancheng Xue wrote:
> > 
> > Should be a From: Pan Wen here?
> > 
> >> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset
> >> Generator) module generates clock and reset signals used
> >> by other module blocks on SoC.
> >>
> >> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
> > 
> > And you should have signed it off? Care to resend or state that
> > this is incorrectly attributed to you instead of Pan Wen?
> > 
> 
> Pan Wen is the main author of this patch. I just made some small modification
> with agreement from him. Do I need to resend this patch if it's better to add my
> signed-off?
> 

Sure I'll apply the resent one. But you should also make sure to
retain Pan Wen's authorship. I'll go do that when applying it.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* Re: [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
From: Paulo Zanoni @ 2016-11-14 20:03 UTC (permalink / raw)
  To: Matt Roper; +Cc: intel-gfx, stable
In-Reply-To: <20161109013809.GG6536@intel.com>

Em Ter, 2016-11-08 às 17:38 -0800, Matt Roper escreveu:
> On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote:
> > 
> > The previous spec version said "double Ytile planes minimum lines",
> > and I interpreted this as referring to what the spec calls "Y tile
> > minimum", but in fact it was referring to what the spec calls
> > "Minimum
> > Scanlines for Y tile". I noticed that Mahesh Kumar had a different
> > interpretation, so I sent and email to the spec authors and got
> > clarification on the correct meaning. Also, BSpec was updated and
> > should be clear now.
> > 
> > Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the
> > memory bandwidth WA")
> > Cc: stable@vger.kernel.org
> > Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> This seems to match my reading of the spec update from Nov 4th, so:
> 
> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>

Patch merged today. Thanks for the review!

> 
> 
> > 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index cc9e0c0..653525f 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3624,6 +3624,9 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> >  		y_min_scanlines = 4;
> >  	}
> >  
> > +	if (apply_memory_bw_wa)
> > +		y_min_scanlines *= 2;
> > +
> >  	plane_bytes_per_line = width * cpp;
> >  	if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> >  	    fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > @@ -3644,8 +3647,6 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> >  				 plane_blocks_per_line);
> >  
> >  	y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
> > -	if (apply_memory_bw_wa)
> > -		y_tile_minimum *= 2;
> >  
> >  	if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> >  	    fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > -- 
> > 2.7.4
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* Re: [Intel-gfx] [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
From: Paulo Zanoni @ 2016-11-14 20:03 UTC (permalink / raw)
  To: Matt Roper; +Cc: intel-gfx, stable
In-Reply-To: <20161109013809.GG6536@intel.com>

Em Ter, 2016-11-08 às 17:38 -0800, Matt Roper escreveu:
> On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote:
> > 
> > The previous spec version said "double Ytile planes minimum lines",
> > and I interpreted this as referring to what the spec calls "Y tile
> > minimum", but in fact it was referring to what the spec calls
> > "Minimum
> > Scanlines for Y tile". I noticed that Mahesh Kumar had a different
> > interpretation, so I sent and email to the spec authors and got
> > clarification on the correct meaning. Also, BSpec was updated and
> > should be clear now.
> > 
> > Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the
> > memory bandwidth WA")
> > Cc: stable@vger.kernel.org
> > Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> This seems to match my reading of the spec update from Nov 4th, so:
> 
> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>

Patch merged today. Thanks for the review!

> 
> 
> > 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index cc9e0c0..653525f 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3624,6 +3624,9 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> >  		y_min_scanlines = 4;
> >  	}
> >  
> > +	if (apply_memory_bw_wa)
> > +		y_min_scanlines *= 2;
> > +
> >  	plane_bytes_per_line = width * cpp;
> >  	if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> >  	    fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > @@ -3644,8 +3647,6 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> >  				 plane_blocks_per_line);
> >  
> >  	y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
> > -	if (apply_memory_bw_wa)
> > -		y_tile_minimum *= 2;
> >  
> >  	if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> >  	    fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > -- 
> > 2.7.4
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

^ permalink raw reply

* Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Geert Uytterhoeven @ 2016-11-14 20:04 UTC (permalink / raw)
  To: Rob Herring
  Cc: Laurent Pinchart, Ramesh Shanmugasundaram, Mark Rutland,
	Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
	Antti Palosaari, Chris Paterson, Geert Uytterhoeven,
	Linux Media Mailing List,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <20161114195200.s62ga2bnutsrocyf@rob-hp-laptop>

Hi Rob,

On Mon, Nov 14, 2016 at 8:52 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
>> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>> > @@ -0,0 +1,136 @@

>> > +Example
>> > +--------
>> > +
>> > +SoC common dtsi file
>> > +
>> > +           drif00: rif@e6f40000 {
>> > +                   compatible = "renesas,r8a7795-drif",
>> > +                                "renesas,rcar-gen3-drif";
>> > +                   reg = <0 0xe6f40000 0 0x64>;
>> > +                   interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
>> > +                   clocks = <&cpg CPG_MOD 515>;
>> > +                   clock-names = "fck";
>> > +                   dmas = <&dmac1 0x20>, <&dmac2 0x20>;
>> > +                   dma-names = "rx", "rx";
>
> rx, rx? That doesn't make sense. While we don't explicitly disallow
> this, I'm thinking we should. I wonder if there's any case this is
> valid. If not, then a dtc check for this could be added.

The device can be used with either dmac1 or dmac2.
Which one is used is decided at run time, based on the availability of
DMA channels per DMAC, which is a limited resource.

>> > +                   power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > +                   status = "disabled";
>> > +           };
>> > +
>> > +           drif01: rif@e6f50000 {
>> > +                   compatible = "renesas,r8a7795-drif",
>> > +                                "renesas,rcar-gen3-drif";
>> > +                   reg = <0 0xe6f50000 0 0x64>;
>> > +                   interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
>> > +                   clocks = <&cpg CPG_MOD 514>;
>> > +                   clock-names = "fck";
>> > +                   dmas = <&dmac1 0x22>, <&dmac2 0x22>;
>> > +                   dma-names = "rx", "rx";
>> > +                   power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > +                   status = "disabled";
>> > +           };
>> > +
>> > +           drif0: rif@0 {
>> > +                   compatible = "renesas,r8a7795-drif",
>> > +                                "renesas,rcar-gen3-drif";
>> > +                   sub-channels = <&drif00>, <&drif01>;
>> > +                   status = "disabled";
>> > +           };
>>
>> I'm afraid this really hurts my eyes, especially using the same compatible
>> string for both the channel and sub-channel nodes.
>>
>> We need to decide how to model the hardware in DT. Given that the two channels
>> are mostly independent having separate DT nodes makes sense to me. However, as
>> they share the clock and sync signals, somehow grouping them makes sense. I
>> see three ways to do so, and there might be more.
>>
>> 1. Adding an extra DT node for the channels group, with phandles to the two
>> channels. This is what you're proposing here.
>>
>> 2. Adding an extra DT node for the channels group, as a parent of the two
>> channels.
>>
>> 3. Adding phandles to the channels, pointing to each other, or possibly a
>> phandle from channel 0 pointing to channel 1.
>>
>> Neither of these options seem perfect to me. I don't like option 1 as the
>> group DT node really doesn't describe a hardware block. If we want to use a DT
>> node to convey group information, option 2 seems better to me. However, it
>> somehow abuses the DT parent-child model that is supposed to describe
>> relationships from a control bus point of view. Option 3 has the drawback of
>> not scaling properly, at least with phandles in both channels pointing to the
>> other one.
>>
>> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
>> solve all those problems :-)
>
> What's the purpose/need for grouping them?
>
> I'm fine with Option 2, though I want to make sure it is really needed.

Each half of a DRIF pair is basically an SPI slave controller without TX
capability, sharing clock and chip-select between the two halves.
Hence you can use either one half to receive 1 bit per clock pulse,
or both halves to receive 2 bits per clock pulse.
You cannot use both halves for independent operation due to the signal
sharing.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Geert Uytterhoeven @ 2016-11-14 20:04 UTC (permalink / raw)
  To: Rob Herring
  Cc: Laurent Pinchart, Ramesh Shanmugasundaram, Mark Rutland,
	Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
	Antti Palosaari, Chris Paterson, Geert Uytterhoeven,
	Linux Media Mailing List, devicetree@vger.kernel.org,
	Linux-Renesas
In-Reply-To: <20161114195200.s62ga2bnutsrocyf@rob-hp-laptop>

Hi Rob,

On Mon, Nov 14, 2016 at 8:52 PM, Rob Herring <robh@kernel.org> wrote:
> On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
>> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>> > @@ -0,0 +1,136 @@

>> > +Example
>> > +--------
>> > +
>> > +SoC common dtsi file
>> > +
>> > +           drif00: rif@e6f40000 {
>> > +                   compatible = "renesas,r8a7795-drif",
>> > +                                "renesas,rcar-gen3-drif";
>> > +                   reg = <0 0xe6f40000 0 0x64>;
>> > +                   interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
>> > +                   clocks = <&cpg CPG_MOD 515>;
>> > +                   clock-names = "fck";
>> > +                   dmas = <&dmac1 0x20>, <&dmac2 0x20>;
>> > +                   dma-names = "rx", "rx";
>
> rx, rx? That doesn't make sense. While we don't explicitly disallow
> this, I'm thinking we should. I wonder if there's any case this is
> valid. If not, then a dtc check for this could be added.

The device can be used with either dmac1 or dmac2.
Which one is used is decided at run time, based on the availability of
DMA channels per DMAC, which is a limited resource.

>> > +                   power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > +                   status = "disabled";
>> > +           };
>> > +
>> > +           drif01: rif@e6f50000 {
>> > +                   compatible = "renesas,r8a7795-drif",
>> > +                                "renesas,rcar-gen3-drif";
>> > +                   reg = <0 0xe6f50000 0 0x64>;
>> > +                   interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
>> > +                   clocks = <&cpg CPG_MOD 514>;
>> > +                   clock-names = "fck";
>> > +                   dmas = <&dmac1 0x22>, <&dmac2 0x22>;
>> > +                   dma-names = "rx", "rx";
>> > +                   power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > +                   status = "disabled";
>> > +           };
>> > +
>> > +           drif0: rif@0 {
>> > +                   compatible = "renesas,r8a7795-drif",
>> > +                                "renesas,rcar-gen3-drif";
>> > +                   sub-channels = <&drif00>, <&drif01>;
>> > +                   status = "disabled";
>> > +           };
>>
>> I'm afraid this really hurts my eyes, especially using the same compatible
>> string for both the channel and sub-channel nodes.
>>
>> We need to decide how to model the hardware in DT. Given that the two channels
>> are mostly independent having separate DT nodes makes sense to me. However, as
>> they share the clock and sync signals, somehow grouping them makes sense. I
>> see three ways to do so, and there might be more.
>>
>> 1. Adding an extra DT node for the channels group, with phandles to the two
>> channels. This is what you're proposing here.
>>
>> 2. Adding an extra DT node for the channels group, as a parent of the two
>> channels.
>>
>> 3. Adding phandles to the channels, pointing to each other, or possibly a
>> phandle from channel 0 pointing to channel 1.
>>
>> Neither of these options seem perfect to me. I don't like option 1 as the
>> group DT node really doesn't describe a hardware block. If we want to use a DT
>> node to convey group information, option 2 seems better to me. However, it
>> somehow abuses the DT parent-child model that is supposed to describe
>> relationships from a control bus point of view. Option 3 has the drawback of
>> not scaling properly, at least with phandles in both channels pointing to the
>> other one.
>>
>> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
>> solve all those problems :-)
>
> What's the purpose/need for grouping them?
>
> I'm fine with Option 2, though I want to make sure it is really needed.

Each half of a DRIF pair is basically an SPI slave controller without TX
capability, sharing clock and chip-select between the two halves.
Hence you can use either one half to receive 1 bit per clock pulse,
or both halves to receive 2 bits per clock pulse.
You cannot use both halves for independent operation due to the signal
sharing.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* Re: [PATCH 1/3] block: fast-path for small and simple direct I/O requests
From: Jens Axboe @ 2016-11-14 20:00 UTC (permalink / raw)
  To: Omar Sandoval; +Cc: axboe, linux-block, linux-fsdevel, hch, Christoph Hellwig
In-Reply-To: <20161114193339.GA31821@vader.DHCP.thefacebook.com>

On 11/14/2016 12:33 PM, Omar Sandoval wrote:
> On Fri, Nov 11, 2016 at 10:11:25PM -0700, Jens Axboe wrote:
>> From: Christoph Hellwig <hch@lst.de>
>>
>> This patch adds a small and simple fast patch for small direct I/O
>> requests on block devices that don't use AIO.  Between the neat
>> bio_iov_iter_get_pages helper that avoids allocating a page array
>> for get_user_pages and the on-stack bio and biovec this avoid memory
>> allocations and atomic operations entirely in the direct I/O code
>> (lower levels might still do memory allocations and will usually
>> have at least some atomic operations, though).
>>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> Signed-off-by: Jens Axboe <axboe@fb.com>
>> ---
>>  fs/block_dev.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 80 insertions(+)
>>
>
> [snip]
>
>>  static ssize_t
>>  blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
>>  {
>>  	struct file *file = iocb->ki_filp;
>>  	struct inode *inode = bdev_file_inode(file);
>> +	int nr_pages;
>>
>> +	nr_pages = iov_iter_npages(iter, BIO_MAX_PAGES);
>> +	if (!nr_pages)
>> +		return 0;
>> +	if (is_sync_kiocb(iocb) && nr_pages <= DIO_INLINE_BIO_VECS)
>> +		return __blkdev_direct_IO_simple(iocb, iter, nr_pages);
>>  	return __blockdev_direct_IO(iocb, inode, I_BDEV(inode), iter,
>>  				    blkdev_get_block, NULL, NULL,
>>  				    DIO_SKIP_DIO_COUNT);
>
> __blockdev_direct_IO() does a few cache prefetches that we're now
> bypassing, do we want to do the same in __blkdev_direct_IO_simple()?
> That's the stuff added in 65dd2aa90aa1 ("dio: optimize cache misses in
> the submission path").

Prefetches like that tend to grow stale, in my experience. So we should
probably just evaluate the new path cache behavior and see if it makes
sense.

-- 
Jens Axboe


^ permalink raw reply

* Re: [PATCH] Handle SForced in storage_modifiers
From: Luc Van Oostenryck @ 2016-11-14 20:04 UTC (permalink / raw)
  To: Jeff Layton; +Cc: linux-sparse, Al Viro
In-Reply-To: <1479150736-28392-1-git-send-email-jlayton@redhat.com>

On Mon, Nov 14, 2016 at 02:12:16PM -0500, Jeff Layton wrote:
> We have been seeing errors like this for a while now in the sparse
> Fedora package, when doing kernel builds:
> 
>     ./include/linux/err.h:53:25: warning: dereference of noderef expression
>     ./include/linux/err.h:35:16: warning: dereference of noderef expression
> 
> This spews all over the build because this comes from IS_ERR(), which
> is called everywhere. Even odder, it turns out that if we build the
> package with -fpic turned off, then it works fine.
> 
> With some brute-force debugging, I think I've finally found the cause.
> This array is missing the SForced element. When this is added then the
> problem goes away.
> 
> As to why this goes away when -fpic is removed, I can only assume that
> we get lucky with the memory layout and have a zeroed out region just
> beyond the end of the array.
> 
> Fixes: 3829c4d8b097776e6b3472290a9fae08a705ab7a
> Cc: Al Viro <viro@ftp.linux.org.uk>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> ---
>  parse.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/parse.c b/parse.c
> index 205e12644a6c..b290ff2636f2 100644
> --- a/parse.c
> +++ b/parse.c
> @@ -1286,7 +1286,8 @@ static unsigned long storage_modifiers(struct decl_state *ctx)
>  		[SAuto] = MOD_AUTO,
>  		[SExtern] = MOD_EXTERN,
>  		[SStatic] = MOD_STATIC,
> -		[SRegister] = MOD_REGISTER
> +		[SRegister] = MOD_REGISTER,
> +		[SForced] = 0
>  	};
>  	return mod[ctx->storage_class] | (ctx->is_inline ? MOD_INLINE : 0)
>  		| (ctx->is_tls ? MOD_TLS : 0);
> -- 

Humm,

The array is statically initialized and never modified,
your patch shouldn't change anything, and this regardless of
the memory layout or compiler options.


Luc Van Oostenryck

^ permalink raw reply

* Re: [PATCH 0/7] FBC atomic cleanups
From: Paulo Zanoni @ 2016-11-14 20:04 UTC (permalink / raw)
  To: intel-gfx
In-Reply-To: <1478883461-20201-1-git-send-email-paulo.r.zanoni@intel.com>

Em Sex, 2016-11-11 às 14:57 -0200, Paulo Zanoni escreveu:
> Ville pointed out two ugly defects in the FBC code, and while trying
> to fix them I spotted a few extra things. No real-world bugs fixed
> here, but IMHO the code is much easier to read now.

I merged patches 1-5 and 7, and will resend patch 6 as a separate
series. Thanks for the quick reviews!

> 
> Paulo Zanoni (7):
>   drm/i915/fbc: move the intel_fbc_can_choose() call out of the loop
>   drm/i915/fbc: replace a loop with
> drm_atomic_get_existing_crtc_state()
>   drm/i915/fbc: extract intel_fbc_can_enable()
>   drm/i915/fbc: inline intel_fbc_can_choose()
>   drm/i915/fbc: use drm_atomic_get_existing_crtc_state when
> appropriate
>   drm/i915/fbc: move from crtc_state->enable_fbc to
>     plane_state->enable_fbc
>   drm/i915/fbc: convert intel_fbc.c to use INTEL_GEN()
> 
>  drivers/gpu/drm/i915/intel_drv.h |  4 +-
>  drivers/gpu/drm/i915/intel_fbc.c | 97 ++++++++++++++++++----------
> ------------
>  2 files changed, 46 insertions(+), 55 deletions(-)
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* Re: [PATCH v5 04/21] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1
From: Konrad Rzeszutek Wilk @ 2016-11-14 20:05 UTC (permalink / raw)
  To: xen-devel, boris.ostrovsky
  Cc: andrew.cooper3, wei.liu2, klancaster, jbeulich, lars.kurth
In-Reply-To: <1474571626-6694-5-git-send-email-boris.ostrovsky@oracle.com>


On Sat, Nov 12, 2016 at 01:02:08PM +0000, Ken Lancaster wrote:
> My apologies for the delay, this is approved.
> 
> We approve the action to re-license http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=801d469ad8b2b88f669326327df03d03200efbfb under LGPLv2.1 as requested.
> 
> Best,
> 
> Ken Lancaster
> 
> 
..snip..

Heya!

Sending this email to xen-devel mailing list.

Ken,

Thank you so much for helping out with this!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply

* Re: Announcing btrfs-dedupe
From: James Pharaoh @ 2016-11-14 20:07 UTC (permalink / raw)
  To: Zygo Blaxell, Austin S. Hemmelgarn; +Cc: Mark Fasheh, linux-btrfs
In-Reply-To: <20161114195102.GI21290@hungrycats.org>

On 14/11/16 20:51, Zygo Blaxell wrote:
> On Mon, Nov 14, 2016 at 01:39:02PM -0500, Austin S. Hemmelgarn wrote:
>> On 2016-11-14 13:22, James Pharaoh wrote:
>>> One thing I am keen to understand is if BTRFS will automatically ignore
>>> a request to deduplicate a file if it is already deduplicated? Given the
>>> performance I see when doing a repeat deduplication, it seems to me that
>>> it can't be doing so, although this could be caused by the CPU usage you
>>> mention above.
 >>
>> What's happening is that the dedupe ioctl does a byte-wise comparison of the
>> ranges to make sure they're the same before linking them.  This is actually
>> what takes most of the time when calling the ioctl, and is part of why it
>> takes longer the larger the range to deduplicate is.  In essence, it's
>> behaving like an OS should and not trusting userspace to make reasonable
>> requests (which is also why there's a separate ioctl to clone a range from
>> another file instead of deduplicating existing data).
>
> 	- the extent-same ioctl could check to see which extents
> 	are referenced by the src and dst ranges, and return success
> 	immediately without reading data if they are the same (but
> 	userspace should already know this, or it's wasting a huge amount
> 	of time before it even calls the kernel).

Yes, this is what I am talking about. I believe I should be able to read 
data about the BTRFS data structures and determine if this is the case. 
I don't care if there are false matches, due to concurrent updates, but 
there'll be a /lot/ of repeat deduplications unless I do this, because 
even if the file is identical, the mtime etc hasn't changed, and I have 
a record of previously doing a dedupe, there's no guarantee that the 
file hasn't been rewritten in place (eg by rsync), and no way that I 
know of to reliably detect if a file has been changed.

I am sure there are libraries out there which can look into the data 
structures of a BTRFS file system, I haven't researched this in detail 
though. I imagine that with some kind of lock on a BTRFS root, this 
could be achieved by simply reading the data from the disk, since I 
believe that everything is copy-on-write, so no existing data should be 
overwritten until all roots referring to it are updated. Perhaps I'm 
missing something though...

James

^ permalink raw reply

* [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161113192203.7101-1-hdegoede@redhat.com>

Hi,

On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
> Just like on sun8i all sun5i tablets use the same interrupt and power
> gpios for their touchscreens. I've checked all known a13 fex files and
> only the UTOO P66 uses a different gpio for the interrupt.
> 
> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> fills in the necessary gpios to avoid duplication in the tablet dts files,
> just like we do in sun8i-reference-design-tablet.dtsi.
> 
> This will make future patches adding touchscreen nodes to a13 tablets
> simpler.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  arch/arm/boot/dts/sun5i-a13-utoo-p66.dts           | 38 ++++++++--------------
>  .../boot/dts/sun5i-reference-design-tablet.dtsi    | 25 ++++++++++++++
>  2 files changed, 39 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> index a8b0bcc..3d7ff10 100644
> --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> @@ -83,22 +83,6 @@
>  	allwinner,pins = "PG3";
>  };
>  
> -&i2c1 {
> -	icn8318: touchscreen at 40 {
> -		compatible = "chipone,icn8318";
> -		reg = <0x40>;
> -		interrupt-parent = <&pio>;
> -		interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&ts_wake_pin_p66>;
> -		wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> -		touchscreen-size-x = <800>;
> -		touchscreen-size-y = <480>;
> -		touchscreen-inverted-x;
> -		touchscreen-swapped-x-y;
> -	};
> -};
> -
>  &mmc2 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&mmc2_pins_a>;
> @@ -121,20 +105,26 @@
>  		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>  		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>  	};
> -
> -	ts_wake_pin_p66: ts_wake_pin at 0 {
> -		allwinner,pins = "PB3";
> -		allwinner,function = "gpio_out";
> -		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> -		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> -	};
> -
>  };
>  
>  &reg_usb0_vbus {
>  	gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
>  };
>  
> +&touchscreen {
> +	compatible = "chipone,icn8318";
> +	reg = <0x40>;
> +	/* The P66 uses a different EINT then the reference design */
> +	interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> +	/* The icn8318 binding expects wake-gpios instead of power-gpios */
> +	wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> +	touchscreen-size-x = <800>;
> +	touchscreen-size-y = <480>;
> +	touchscreen-inverted-x;
> +	touchscreen-swapped-x-y;
> +	status = "okay";
> +};
> +
>  &uart1 {
>  	/* The P66 uses the uart pins as gpios */
>  	status = "disabled";
> diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> index 20cc940..7af488a 100644
> --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> @@ -41,6 +41,7 @@
>   */
>  #include "sunxi-reference-design-tablet.dtsi"
>  
> +#include <dt-bindings/interrupt-controller/irq.h>
>  #include <dt-bindings/pwm/pwm.h>
>  
>  / {
> @@ -84,6 +85,23 @@
>  };
>  
>  &i2c1 {
> +	/*
> +	 * The gsl1680 is rated at 400KHz and it will not work reliable at
> +	 * 100KHz, this has been confirmed on multiple different q8 tablets.
> +	 * All other devices on this bus are also rated for 400KHz.
> +	 */
> +	clock-frequency = <400000>;
> +
> +	touchscreen: touchscreen {
> +		interrupt-parent = <&pio>;
> +		interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&ts_power_pin>;
> +		power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> +		/* Tablet dts must provide reg and compatible */
> +		status = "disabled";
> +	};
> +
>  	pcf8563: rtc at 51 {
>  		compatible = "nxp,pcf8563";
>  		reg = <0x51>;
> @@ -125,6 +143,13 @@
>  		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>  	};
>  
> +	ts_power_pin: ts_power_pin {
> +		allwinner,pins = "PB3";
> +		allwinner,function = "gpio_out";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
> +

For the next release, we'll switch to the generic pin mux properties
("pins" and "function"), and we actually implemented the fact that the
drive and pull properties are optional, so you can drop them both.

You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/7e78a172/attachment.sig>

^ permalink raw reply

* Re: [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree
In-Reply-To: <20161113192203.7101-1-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 4706 bytes --]

Hi,

On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
> Just like on sun8i all sun5i tablets use the same interrupt and power
> gpios for their touchscreens. I've checked all known a13 fex files and
> only the UTOO P66 uses a different gpio for the interrupt.
> 
> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> fills in the necessary gpios to avoid duplication in the tablet dts files,
> just like we do in sun8i-reference-design-tablet.dtsi.
> 
> This will make future patches adding touchscreen nodes to a13 tablets
> simpler.
> 
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>  arch/arm/boot/dts/sun5i-a13-utoo-p66.dts           | 38 ++++++++--------------
>  .../boot/dts/sun5i-reference-design-tablet.dtsi    | 25 ++++++++++++++
>  2 files changed, 39 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> index a8b0bcc..3d7ff10 100644
> --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> @@ -83,22 +83,6 @@
>  	allwinner,pins = "PG3";
>  };
>  
> -&i2c1 {
> -	icn8318: touchscreen@40 {
> -		compatible = "chipone,icn8318";
> -		reg = <0x40>;
> -		interrupt-parent = <&pio>;
> -		interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&ts_wake_pin_p66>;
> -		wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> -		touchscreen-size-x = <800>;
> -		touchscreen-size-y = <480>;
> -		touchscreen-inverted-x;
> -		touchscreen-swapped-x-y;
> -	};
> -};
> -
>  &mmc2 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&mmc2_pins_a>;
> @@ -121,20 +105,26 @@
>  		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>  		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>  	};
> -
> -	ts_wake_pin_p66: ts_wake_pin@0 {
> -		allwinner,pins = "PB3";
> -		allwinner,function = "gpio_out";
> -		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> -		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> -	};
> -
>  };
>  
>  &reg_usb0_vbus {
>  	gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
>  };
>  
> +&touchscreen {
> +	compatible = "chipone,icn8318";
> +	reg = <0x40>;
> +	/* The P66 uses a different EINT then the reference design */
> +	interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> +	/* The icn8318 binding expects wake-gpios instead of power-gpios */
> +	wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> +	touchscreen-size-x = <800>;
> +	touchscreen-size-y = <480>;
> +	touchscreen-inverted-x;
> +	touchscreen-swapped-x-y;
> +	status = "okay";
> +};
> +
>  &uart1 {
>  	/* The P66 uses the uart pins as gpios */
>  	status = "disabled";
> diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> index 20cc940..7af488a 100644
> --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> @@ -41,6 +41,7 @@
>   */
>  #include "sunxi-reference-design-tablet.dtsi"
>  
> +#include <dt-bindings/interrupt-controller/irq.h>
>  #include <dt-bindings/pwm/pwm.h>
>  
>  / {
> @@ -84,6 +85,23 @@
>  };
>  
>  &i2c1 {
> +	/*
> +	 * The gsl1680 is rated at 400KHz and it will not work reliable at
> +	 * 100KHz, this has been confirmed on multiple different q8 tablets.
> +	 * All other devices on this bus are also rated for 400KHz.
> +	 */
> +	clock-frequency = <400000>;
> +
> +	touchscreen: touchscreen {
> +		interrupt-parent = <&pio>;
> +		interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&ts_power_pin>;
> +		power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> +		/* Tablet dts must provide reg and compatible */
> +		status = "disabled";
> +	};
> +
>  	pcf8563: rtc@51 {
>  		compatible = "nxp,pcf8563";
>  		reg = <0x51>;
> @@ -125,6 +143,13 @@
>  		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>  	};
>  
> +	ts_power_pin: ts_power_pin {
> +		allwinner,pins = "PB3";
> +		allwinner,function = "gpio_out";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
> +

For the next release, we'll switch to the generic pin mux properties
("pins" and "function"), and we actually implemented the fact that the
drive and pull properties are optional, so you can drop them both.

You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply

* Re: [PATCH v10 3/3] drm/fence: add out-fences support
From: Daniel Vetter @ 2016-11-14 20:08 UTC (permalink / raw)
  To: Brian Starkey
  Cc: Gustavo Padovan, dri-devel, Linux Kernel Mailing List,
	Daniel Stone, Rob Clark, Greg Hackmann, John Harrison,
	Laurent Pinchart, Sean Paul, Stéphane Marchesin, m.chehab,
	Maarten Lankhorst, Gustavo Padovan, Syrjala, Ville
In-Reply-To: <20161114145720.GB24412@e106950-lin.cambridge.arm.com>

On Mon, Nov 14, 2016 at 3:57 PM, Brian Starkey <brian.starkey@arm.com> wrote:
> I was just writing some internal docs, and it occurred to me that the
> out-fence implementation here doesn't seem to match what we discussed
> with Ville a few weeks back (which had completely slipped my mind).
>
> Did the idea of returning -1 fences for multiple commits within a
> frame get dropped? I didn't see any discussion further than that
> thread on v5 from October:
> http://lkml.iu.edu/hypermail/linux/kernel/1610.2/04727.html

Atm we only support a queue depth of 1, and not faster than vblank.
This was just discussions to make sure we're not drawing ourselves
into a corner with this uabi.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply

* [PATCH 2/2] ARM: dts: sun8i: reference-design-tablet: ldo_io1 is vcc-touchscreen
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161113192203.7101-2-hdegoede@redhat.com>

On Sun, Nov 13, 2016 at 08:22:03PM +0100, Hans de Goede wrote:
> On some Q8 and other tablets ldo_io1 is used as vcc-touchscreen,
> config at as such in sun8i-reference-design-tablet.dtsi.
> 
> Note that it will only be enabled when it us actually referenced by
> a foo-supply property in the touchscreen node, so for tablets which
> do not use ldo_io1 as vcc-touchscreen, it will be disabled.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/4197396f/attachment.sig>

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.