[linux] 03/05: Update Origin and description for various patches now applied/merged upstream
debian-kernel at lists.debian.org
debian-kernel at lists.debian.org
Tue Apr 18 03:20:45 UTC 2017
This is an automated email from the git hooks/post-receive script.
benh pushed a commit to branch sid
in repository linux.
commit aa2adea45fbeaf5f42bbf5df94554c1631b135da
Author: Ben Hutchings <ben at decadent.org.uk>
Date: Tue Apr 18 04:17:47 2017 +0100
Update Origin and description for various patches now applied/merged upstream
---
.../patches/bugfix/all/ext4-fix-bug-838544.patch | 219 ++-------------------
...l-workqueue-for-creating-per-memcg-caches.patch | 30 +--
...-fix-overflow-in-check-for-priv-area-size.patch | 3 +-
...ket-fix-overflow-in-check-for-tp_frame_nr.patch | 3 +-
...cket-fix-overflow-in-check-for-tp_reserve.patch | 3 +-
...eeloff-operation-on-asocs-with-threads-sl.patch | 2 +-
.../arm/ARM-dts-orion5x-lschl-Fix-model-name.patch | 2 +-
...on5x-lschl-More-consistent-naming-on-link.patch | 2 +-
.../arm/arm-dts-add-support-for-turris-omnia.patch | 2 +-
...ris-omnia-add-support-for-ethernet-switch.patch | 2 +-
...eson-gx-add-firmware-reserved-memory-zone.patch | 3 +-
11 files changed, 50 insertions(+), 221 deletions(-)
diff --git a/debian/patches/bugfix/all/ext4-fix-bug-838544.patch b/debian/patches/bugfix/all/ext4-fix-bug-838544.patch
index 2bdf2b5..b7b3c7c 100644
--- a/debian/patches/bugfix/all/ext4-fix-bug-838544.patch
+++ b/debian/patches/bugfix/all/ext4-fix-bug-838544.patch
@@ -1,206 +1,25 @@
-From: "Darrick J. Wong" <darrick.wong at oracle.com>
-Date: Mon, 19 Sep 2016 22:52:16 -0700
-Subject: Re: Trouble mounting metadata_csum ext4 filesystems with v4.7.x after c9274d891869880648c4ee9365df3ecc7ba2e285: not enough inode bytes checksummed?
-Origin: https://www.spinics.net/lists/linux-fsdevel/msg101888.html
+From: Daeho Jeong <daeho.jeong at samsung.com>
+Date: Thu, 1 Dec 2016 11:49:12 -0500
+Subject: ext4: fix inode checksum calculation problem if i_extra_size is small
+Origin: https://git.kernel.org/linus/05ac5aa18abd7db341e54df4ae2b4c98ea0e43b7
Bug-Debian: https://bugs.debian.org/838544
-[cc Ted and the ext4 list]
-
-On Mon, Sep 19, 2016 at 03:19:03PM +0100, Nix wrote:
-> So I ran into spurious metadata corruption warnings in v4.7.2 due to the
-> problem fixed by c9274d8. I applied an early version of the fix,
-> rebooted, and oh dear root filesystem mount failure with invalid
-> checksum errors.
->
-> The problem persists in v4.7.4, as seen here in qemu emulation on a raw
-> image dd'ed directly from the thing that won't boot, with a couple of
-> printk()s:
->
-> # mount /dev/vda /new-root/
-> [ 8.124692] EXT4-fs (vda): couldn't mount as ext3 due to feature incompatibilities
-> [ 8.126977] EXT4-fs (vda): couldn't mount as ext2 due to feature incompatibilities
-> [ 9.017980] Inode size 256 > good old size 128; fits in inode: 0
-> [ 8.134897] inode 8: provided: 5c50l; calculated: 36e1i
-> [ 8.135098] EXT4-fs error (device vda): ext4_iget:4479: inode #8: comm mount: checksum invalid
-> [ 8.138992] EXT4-fs (vda): no journal found
-> [ 8.165744] UDF-fs: warning (device vda): udf_fill_super: No partition found (2)
-> mount: mounting /dev/vda on /new-root/ failed: Invalid argument
->
-> I added a bit of printking to show the failure of the journal inode
-> checksum to pass muster. e2fsck (from e2fsprogs 1.43.1-14) is quite
-> happy with this filesystem. Reverting c9274d8 makes everything happy
-> again (well, it does bring the original bug back, which is a rather
-> serious one, but other than that...):
->
-> [ 9.823032] EXT4-fs (vda): couldn't mount as ext3 due to feature incompatibilities
-> [ 9.824647] EXT4-fs (vda): couldn't mount as ext2 due to feature incompatibilities
-> [ 9.832593] inode 8: provided: 5c50l; calculated: 5c50i
-> [ 9.839253] inode 2: provided: d6ea92e9l; calculated: d6ea92e9i
-> [ 9.846947] EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null)
->
-> So c9274d8 is clearly messing up the calculation of the checksum.
->
-> The problem becomes more evident if we add more printk()s to the old
-> code, so we can see what region is being checksummed:
->
-> # mount /dev/vda /new-root
-> [ 6.827297] inode 8: unadjusted csum of 256 bytes with seed a5df92a7: 449a5c50
-> [ 6.827596] adjusted csum: 5c50
-> [ 6.835993] inode 2: unadjusted csum of 256 bytes with seed 759c6c33: d6ea92e9
-> [ 6.836173] adjusted csum: d6ea92e9
-> [ 6.844801] EXT4-fs (vda): mounted filesystem with ordered data mode. Opts:
->
-> and the new:
->
-> [ 11.098013] inode 8: csum of first 124 bytes with seed a5df92a7: f375b663
-> [ 11.098205] inode 8: added csum of 2 dummy_csum bytes with seed a5df92a7: 20cfebcb
-> [ 11.098420] inode 8: added csum of 2 bytes from offset 126 -- 128 to existing: d79e7432
-> [ 11.098646] inode 8: > GOOD_OLD_INODE_SIZE; added csum of 2 bytes from 128 -- 130 to existing: d10936e1
-> [ 11.098890] 8: adjusted csum: 36e1
-> [ 11.099133] EXT4-fs error (device vda): ext4_iget:4483: inode #8: comm mount: checksum invalid
->
-> We are not checksumming enough bytes! We used to checksum the entire
-> 256-byte inode: now, we checksum only 130 bytes of it, which isn't even
-> enough to cover the 28-byte extra_isize on this filesystem and is more
-> or less guaranteed to give the wrong answer. I'd fix the problem, but I
-> frankly can't see how the new code is meant to be equivalent to the old
-> code in any sense -- most particularly what the stuff around dummy_csum
-> is meant to do -- so I thought it better to let the people who wrote it
-> fix it :)
-
-Sh*t, I missed this during the review. So your filesystem image (thank
-you!) had this to say:
-
-debugfs> stats
-Inode size: 256
-debugfs> stat <8>
-Size of extra inode fields: 0
-
-Basically, a 128-byte inode inside a filesystem that allocated 256 bytes
-for each inode. As you point out, the old code would checksum the entire
-allocated space, whether or not the inode core used it. Obviously, you
-want this since inline extended attributes live in that space:
-
-csum = ext4_chksum(sbi, ei->i_csum_seed, (__u8 *)raw,
- EXT4_INODE_SIZE(inode->i_sb));
-
-The new code, on the other hand, carefully checksums around the
-i_checksum fields and only bothers to checksum the space between the end
-of i_checksum_hi and the end of the allocated space if the inode core is
-big enough to store i_checksum_hi. Since we allocated 256 bytes for
-each inode, we checksum the first two bytes after byte 128
-(EXT4_GOOD_OLD_INODE_SIZE), but then we see that i_extra_size == 0 so we
-never bother to checksum anything after that. This is of course wrong
-since we no longer checksum the xattr space and we've deviated from the
-pre-4.7.4 (documented) on-disk format.
-
-*FORTUNATELY* since the root inode fails the read verifier, the file (in
-this case the root dir) can't be modified and therefore nothing has been
-corrupted. Especially fortunate for you, the fs won't mount, reducing
-the chances that any serious damage has occurred.
-
-I /think/ the fix in this case is to hoist the last ext4_chksum call
-out of the EXT4_FITS_IN_INODE blob:
-
-if (EXT4_INODE_SIZE(inode->i_sb) > EXT4_GOOD_OLD_INODE_SIZE) {
- offset = offsetof(struct ext4_inode, i_checksum_hi);
- csum = ext4_chksum(sbi, csum, (__u8 *)raw +
- EXT4_GOOD_OLD_INODE_SIZE,
- offset - EXT4_GOOD_OLD_INODE_SIZE);
- if (EXT4_FITS_IN_INODE(raw, ei, i_checksum_hi)) {
- csum = ext4_chksum(sbi, csum, (__u8 *)&dummy_csum,
- csum_size);
- offset += csum_size;
- }
- csum = ext4_chksum(sbi, csum, (__u8 *)raw + offset,
- EXT4_INODE_SIZE(inode->i_sb) - offset);
-}
-
-Can you give that a try?
-
-> tune2fs output for this filesystem, particularly the extra_isize and
-> inode size fields are likely relevant:
->
-> tune2fs 1.43.1 (08-Jun-2016)
-> Filesystem volume name: root
-> Last mounted on: /
-> Filesystem UUID: 6c0f7fa7-d6c2-4054-bff3-3a878460bdc7
-> Filesystem magic number: 0xEF53
-> Filesystem revision #: 1 (dynamic)
-> Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
-> Filesystem flags: signed_directory_hash
-> Default mount options: (none)
-> Filesystem state: clean
-> Errors behavior: Continue
-> Filesystem OS type: Linux
-> Inode count: 65536
-> Block count: 262144
-> Reserved block count: 13107
-> Free blocks: 227009
-> Free inodes: 59499
-> First block: 0
-> Block size: 4096
-> Fragment size: 4096
-> Group descriptor size: 64
-> Reserved GDT blocks: 63
-> Blocks per group: 32768
-> Fragments per group: 32768
-> Inodes per group: 8192
-> Inode blocks per group: 512
-> RAID stripe width: 16
-> Flex block group size: 64
-> Filesystem created: Tue May 26 21:28:46 2009
-> Last mount time: Sun Sep 18 23:34:41 2016
-> Last write time: Mon Sep 19 13:51:59 2016
-> Mount count: 0
-> Maximum mount count: 36
-> Last checked: Mon Sep 19 13:51:59 2016
-> Check interval: 15552000 (6 months)
-> Next check after: Sat Mar 18 12:51:59 2017
-> Lifetime writes: 16 GB
-> Reserved blocks uid: 0 (user root)
-> Reserved blocks gid: 0 (group root)
-> First inode: 11
-> Inode size: 256
-> Required extra isize: 28
-> Desired extra isize: 28
-> Journal inode: 8
-> Default directory hash: half_md4
-> Directory Hash Seed: f1da2da0-057e-4ba0-a021-3d56db5b24ab
-> Journal backup: inode blocks
-> Checksum type: crc32c
-> Checksum: 0x92acf115
->
-> This is an old, upgraded fs from before the days of checksums, but even
-> so I'm surprised that with a 256-byte inode and no xattrs in use,
-> EXT4_FITS_IN_INODE is false. Maybe the extra_isize isn't big enough?
-
-It's zero, so yes. :)
-
-> An lzipped e2image of the problematic filesystem is available from
-> <http://www.esperi.org.uk/~nix/temporary/csum-corruption.img.lz>:
-> I have verified that the problem recurs with this image.
->
-> I can also replicate the problem in literally seconds if you need more
-> debugging output.
->
->
-> ... The mystery is why this isn't going wrong anywhere else: I have
-> metadata_csum working on every fs on a bunch of other ext4-using
-> systems, and indeed on every filesystem on this machine as well, as long
-> as c9274d8 is not applied. Many of them are similarly upgraded pre-csum
-> fses with the same inode size and extra_isize, but they work...
-
-Hard to say, but this bug only affects inodes with 0 < i_extra_size <= 4
-i.e. 128 < inode-core-size <= 130. Maybe an old ext3 fs that was
-created with 256 bytes per inode but inode-core-size of 128?
-
-Uck. Sorry about this mess.
-
---D
-
-[bwh: Converted to a patch]
+We've fixed the race condition problem in calculating ext4 checksum
+value in commit b47820edd163 ("ext4: avoid modifying checksum fields
+directly during checksum veficationon"). However, by this change,
+when calculating the checksum value of inode whose i_extra_size is
+less than 4, we couldn't calculate the checksum value in a proper way.
+This problem was found and reported by Nix, Thank you.
+
+Reported-by: Nix <nix at esperi.org.uk>
+Signed-off-by: Daeho Jeong <daeho.jeong at samsung.com>
+Signed-off-by: Youngjin Gil <youngjin.gil at samsung.com>
+Signed-off-by: Darrick J. Wong <darrick.wong at oracle.com>
+Signed-off-by: Theodore Ts'o <tytso at mit.edu>
---
+ fs/ext4/inode.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -71,10 +71,9 @@ static __u32 ext4_inode_csum(struct inod
diff --git a/debian/patches/bugfix/all/mm-memcontrol-use-special-workqueue-for-creating-per-memcg-caches.patch b/debian/patches/bugfix/all/mm-memcontrol-use-special-workqueue-for-creating-per-memcg-caches.patch
index 5b57876..b3365b7 100644
--- a/debian/patches/bugfix/all/mm-memcontrol-use-special-workqueue-for-creating-per-memcg-caches.patch
+++ b/debian/patches/bugfix/all/mm-memcontrol-use-special-workqueue-for-creating-per-memcg-caches.patch
@@ -1,38 +1,44 @@
From: Vladimir Davydov <vdavydov.dev at gmail.com>
-Date: Sat, 1 Oct 2016 16:39:09 +0300
+Date: Mon, 12 Dec 2016 16:41:29 -0800
Subject: mm: memcontrol: use special workqueue for creating per-memcg caches
-Origin: https://patchwork.kernel.org/patch/9361853/
+Origin: https://git.kernel.org/linus/13583c3d3224508582ec03d881d0b68dd3ee8e10
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=172981
Creating a lot of cgroups at the same time might stall all worker
threads with kmem cache creation works, because kmem cache creation is
-done with the slab_mutex held. The problem was amplified by commits
+done with the slab_mutex held. The problem was amplified by commits
801faf0db894 ("mm/slab: lockless decision to grow cache") in case of
SLAB and 81ae6d03952c ("mm/slub.c: replace kick_all_cpus_sync() with
synchronize_sched() in kmem_cache_shrink()") in case of SLUB, which
increased the maximal time the slab_mutex can be held.
To prevent that from happening, let's use a special ordered single
-threaded workqueue for kmem cache creation. This shouldn't introduce any
-functional changes regarding how kmem caches are created, as the work
-function holds the global slab_mutex during its whole runtime anyway,
-making it impossible to run more than one work at a time. By using a
-single threaded workqueue, we just avoid creating a thread per each
-work. Ordering is required to avoid a situation when a cgroup's work is
-put off indefinitely because there are other cgroups to serve, in other
-words to guarantee fairness.
+threaded workqueue for kmem cache creation. This shouldn't introduce
+any functional changes regarding how kmem caches are created, as the
+work function holds the global slab_mutex during its whole runtime
+anyway, making it impossible to run more than one work at a time. By
+using a single threaded workqueue, we just avoid creating a thread per
+each work. Ordering is required to avoid a situation when a cgroup's
+work is put off indefinitely because there are other cgroups to serve,
+in other words to guarantee fairness.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=172981
+Link: http://lkml.kernel.org/r/20161004131417.GC1862@esperanza
Signed-off-by: Vladimir Davydov <vdavydov.dev at gmail.com>
Reported-by: Doug Smythies <dsmythies at telus.net>
+Acked-by: Michal Hocko <mhocko at suse.com>
Cc: Christoph Lameter <cl at linux.com>
Cc: David Rientjes <rientjes at google.com>
Cc: Johannes Weiner <hannes at cmpxchg.org>
Cc: Joonsoo Kim <iamjoonsoo.kim at lge.com>
Cc: Michal Hocko <mhocko at kernel.org>
Cc: Pekka Enberg <penberg at kernel.org>
-Acked-by: Michal Hocko <mhocko at suse.com>
+Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
---
+ mm/memcontrol.c | 15 ++++++++++++++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2232,6 +2232,8 @@ struct memcg_kmem_cache_create_work {
diff --git a/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-priv-area-size.patch b/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-priv-area-size.patch
index 51b6937..2ba2e7c 100644
--- a/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-priv-area-size.patch
+++ b/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-priv-area-size.patch
@@ -1,7 +1,7 @@
From: Andrey Konovalov <andreyknvl at google.com>
Date: Wed, 29 Mar 2017 16:11:20 +0200
Subject: net/packet: fix overflow in check for priv area size
-Origin: https://patchwork.ozlabs.org/patch/744811/
+Origin: https://git.kernel.org/linus/2b6867c2ce76c596676bec7d2d525af525fdc6e2
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-7308
Subtracting tp_sizeof_priv from tp_block_size and casting to int
@@ -15,6 +15,7 @@ it can overflow inside BLK_PLUS_PRIV otherwise.
Signed-off-by: Andrey Konovalov <andreyknvl at google.com>
Acked-by: Eric Dumazet <edumazet at google.com>
+Signed-off-by: David S. Miller <davem at davemloft.net>
---
net/packet/af_packet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-tp_frame_nr.patch b/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-tp_frame_nr.patch
index 02434c8..1ca2d19 100644
--- a/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-tp_frame_nr.patch
+++ b/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-tp_frame_nr.patch
@@ -1,7 +1,7 @@
From: Andrey Konovalov <andreyknvl at google.com>
Date: Wed, 29 Mar 2017 16:11:21 +0200
Subject: net/packet: fix overflow in check for tp_frame_nr
-Origin: https://patchwork.ozlabs.org/patch/744812/
+Origin: https://git.kernel.org/linus/8f8d28e4d6d815a391285e121c3a53a0b6cb9e7b
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-7308
When calculating rb->frames_per_block * req->tp_block_nr the result
@@ -14,6 +14,7 @@ never overflow.
Signed-off-by: Andrey Konovalov <andreyknvl at google.com>
Acked-by: Eric Dumazet <edumazet at google.com>
+Signed-off-by: David S. Miller <davem at davemloft.net>
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-tp_reserve.patch b/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-tp_reserve.patch
index 491c30a..267e16c 100644
--- a/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-tp_reserve.patch
+++ b/debian/patches/bugfix/all/net-packet-fix-overflow-in-check-for-tp_reserve.patch
@@ -1,7 +1,7 @@
From: Andrey Konovalov <andreyknvl at google.com>
Date: Wed, 29 Mar 2017 16:11:22 +0200
Subject: net/packet: fix overflow in check for tp_reserve
-Origin: https://patchwork.ozlabs.org/patch/744813/
+Origin: https://git.kernel.org/linus/bcc5364bdcfe131e6379363f089e7b4108d35b70
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-7308
When calculating po->tp_hdrlen + po->tp_reserve the result can overflow.
@@ -10,6 +10,7 @@ Fix by checking that tp_reserve <= INT_MAX on assign.
Signed-off-by: Andrey Konovalov <andreyknvl at google.com>
Acked-by: Eric Dumazet <edumazet at google.com>
+Signed-off-by: David S. Miller <davem at davemloft.net>
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/debian/patches/bugfix/all/sctp-deny-peeloff-operation-on-asocs-with-threads-sl.patch b/debian/patches/bugfix/all/sctp-deny-peeloff-operation-on-asocs-with-threads-sl.patch
index 13f5d78..024c12b 100644
--- a/debian/patches/bugfix/all/sctp-deny-peeloff-operation-on-asocs-with-threads-sl.patch
+++ b/debian/patches/bugfix/all/sctp-deny-peeloff-operation-on-asocs-with-threads-sl.patch
@@ -1,7 +1,7 @@
From: Marcelo Ricardo Leitner <marcelo.leitner at gmail.com>
Date: Thu, 23 Feb 2017 09:31:18 -0300
Subject: sctp: deny peeloff operation on asocs with threads sleeping on it
-Origin: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit?id=dfcb9f4f99f1e9a49e43398a7bfbf56927544af1
+Origin: https://git.kernel.org/linus/dfcb9f4f99f1e9a49e43398a7bfbf56927544af1
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-6353
commit 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
diff --git a/debian/patches/features/arm/ARM-dts-orion5x-lschl-Fix-model-name.patch b/debian/patches/features/arm/ARM-dts-orion5x-lschl-Fix-model-name.patch
index 37545f7..c7a62ad 100644
--- a/debian/patches/features/arm/ARM-dts-orion5x-lschl-Fix-model-name.patch
+++ b/debian/patches/features/arm/ARM-dts-orion5x-lschl-Fix-model-name.patch
@@ -1,7 +1,7 @@
From: Roger Shimizu <rogershimizu at gmail.com>
Date: Mon, 30 Jan 2017 20:07:29 +0900
Subject: [PATCH 1/2] ARM: dts: orion5x-lschl: Fix model name
-Origin: https://git.kernel.org/next/linux-next/c/d566a78ab13abded6b4acdc9b3fafa8c46f3ed09
+Origin: https://git.kernel.org/linus/81917bad86a66f2bdcb12b4c10ab1bf333ed25ec
Model name should be consistent with legacy device file, so that user
can migrate their system from legacy device support to device-tree
diff --git a/debian/patches/features/arm/ARM-dts-orion5x-lschl-More-consistent-naming-on-link.patch b/debian/patches/features/arm/ARM-dts-orion5x-lschl-More-consistent-naming-on-link.patch
index c4b2938..a83af0d 100644
--- a/debian/patches/features/arm/ARM-dts-orion5x-lschl-More-consistent-naming-on-link.patch
+++ b/debian/patches/features/arm/ARM-dts-orion5x-lschl-More-consistent-naming-on-link.patch
@@ -2,7 +2,7 @@ From: Roger Shimizu <rogershimizu at gmail.com>
Date: Mon, 30 Jan 2017 20:07:30 +0900
Subject: [PATCH 2/2] ARM: dts: orion5x-lschl: More consistent naming on
linkstation series
-Origin: https://git.kernel.org/next/linux-next/c/56ba99b01308c360df5d18c6127f38b287550965
+Origin: https://git.kernel.org/linus/6cfd3cd8d8365cf78db1d25cd276d3d900eb8541
DTS files, which includes orion5x-linkstation.dtsi, are named:
orion5x-linkstation-*.dts
diff --git a/debian/patches/features/arm/arm-dts-add-support-for-turris-omnia.patch b/debian/patches/features/arm/arm-dts-add-support-for-turris-omnia.patch
index 2650e51..b743e4c 100644
--- a/debian/patches/features/arm/arm-dts-add-support-for-turris-omnia.patch
+++ b/debian/patches/features/arm/arm-dts-add-support-for-turris-omnia.patch
@@ -1,7 +1,7 @@
From: Uwe Kleine-König <uwe at kleine-koenig.org>
Date: Fri, 25 Nov 2016 15:26:58 +0100
Subject: ARM: dts: add support for Turris Omnia
-Origin: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=26ca8b52d6e18c10109cabda0f775dd9345bbfdf
+Origin: https://git.kernel.org/linus/26ca8b52d6e18c10109cabda0f775dd9345bbfdf
This machine is an open hardware router by cz.nic driven by a
Marvell Armada 385.
diff --git a/debian/patches/features/arm/arm-dts-turris-omnia-add-support-for-ethernet-switch.patch b/debian/patches/features/arm/arm-dts-turris-omnia-add-support-for-ethernet-switch.patch
index 80b7a7a..332a2ac 100644
--- a/debian/patches/features/arm/arm-dts-turris-omnia-add-support-for-ethernet-switch.patch
+++ b/debian/patches/features/arm/arm-dts-turris-omnia-add-support-for-ethernet-switch.patch
@@ -1,7 +1,7 @@
From: Uwe Kleine-König <uwe at kleine-koenig.org>
Date: Tue, 3 Jan 2017 20:35:01 +0100
Subject: [PATCH] ARM: dts: turris-omnia: add support for ethernet switch
-Origin: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=7b7db5ab33d2292d9b037cda0c41a795b094d940
+Origin: https://git.kernel.org/linus/7b7db5ab33d2292d9b037cda0c41a795b094d940
The Turris Omnia features a Marvell MV88E6176 ethernet switch. Add it to
the dts.
diff --git a/debian/patches/features/arm64/dts-meson-gx-add-firmware-reserved-memory-zone.patch b/debian/patches/features/arm64/dts-meson-gx-add-firmware-reserved-memory-zone.patch
index 23d281d..b8c0bd5 100644
--- a/debian/patches/features/arm64/dts-meson-gx-add-firmware-reserved-memory-zone.patch
+++ b/debian/patches/features/arm64/dts-meson-gx-add-firmware-reserved-memory-zone.patch
@@ -4,7 +4,7 @@ Subject: ARM64: dts: meson-gx: Add firmware reserved memory zones
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
-Origin: https://git.kernel.org/cgit/linux/kernel/git/khilman/linux-amlogic.git/commit?id=ecb88f3001ed9ee8c53450d971de8c18bcbf7925
+Origin: https://git.kernel.org/linus/bba8e3f42736cf7f974968a818e53b128286ad1d
Bug-Debian: https://bugs.debian.org/852132
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
@@ -26,6 +26,7 @@ Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
Reviewed-by: Andreas Färber <afaerber at suse.de>
[khilman: added Fixes tag, added _reserved and unit addresses]
Signed-off-by: Kevin Hilman <khilman at baylibre.com>
+Signed-off-by: Arnd Bergmann <arnd at arndb.de>
[bwh: Backported to 4.9: adjust filename]
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 18 ++++++++++++++++++
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/kernel/linux.git
More information about the Kernel-svn-changes
mailing list