* Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
From: David Miller @ 2018-07-24 4:41 UTC (permalink / raw)
To: davejwatson; +Cc: vakul.garg, netdev, borisp, aviadye, doronrk
In-Reply-To: <20180723163509.GA91424@davejwatson-mba.local>
From: Dave Watson <davejwatson@fb.com>
Date: Mon, 23 Jul 2018 09:35:09 -0700
> I don't think this patch is safe as-is. sgin_arr is a stack array of
> size MAX_SKB_FRAGS (+ overhead), while my read of skb_cow_data is that
> it walks the whole chain of skbs from skb->next, and can return any
> number of segments. Therefore we need to heap allocate. I think I
> copied the IPSEC code here.
Ok I see what you are saying.
So it means that, when a non-NULL sgout is passed into decrypt_skb(),
via decrypt_skb_update(), via tls_sw_recvmsg() it means that it is the
zerocopy case and you know that you only have page frags and no SKB
frag list, right?
I agree with you that this change is therefore incorrect.
^ permalink raw reply
* [ANNOUNCE] xfsprogs for-next updated to d73a5b9
From: Eric Sandeen @ 2018-07-24 4:38 UTC (permalink / raw)
To: linux-xfs
[-- Attachment #1.1: Type: text/plain, Size: 19402 bytes --]
Hi folks,
The for-next branch of the xfsprogs repository at:
git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git
has just been updated.
I know there are more patches on the list. ;)
No need to resend at this point.
The new head of the for-next branch is commit:
d73a5b9 Get rid of XFS_BUF_SET_COUNT() macro
New Commits:
Carlos Maiolino (4):
[0433861] Get rid of XFS_BUF_PTR() macro
[69ac495] Get rid of XFS_BUF_TARGET() macro
[135e4bf] Get rid of XFS_BUF_COUNT() macro
[d73a5b9] Get rid of XFS_BUF_SET_COUNT() macro
Dave Chinner (1):
[959ef98] xfsprogs: convert to SPDX license tags
Code Diffstat:
LICENSES/GPL-2.0 | 353 +++++++++++++++
LICENSES/LGPL-2.1 | 503 +++++++++++++++++++++
Makefile | 1 +
copy/Makefile | 2 +-
copy/xfs_copy.c | 14 +-
copy/xfs_copy.h | 14 +-
db/Makefile | 2 +-
db/addr.c | 14 +-
db/addr.h | 14 +-
db/agf.c | 14 +-
db/agf.h | 14 +-
db/agfl.c | 14 +-
db/agfl.h | 14 +-
db/agi.c | 14 +-
db/agi.h | 14 +-
db/attr.c | 14 +-
db/attr.h | 14 +-
db/attrset.c | 14 +-
db/attrset.h | 14 +-
db/attrshort.c | 14 +-
db/attrshort.h | 14 +-
db/bit.c | 14 +-
db/bit.h | 14 +-
db/block.c | 14 +-
db/block.h | 14 +-
db/bmap.c | 14 +-
db/bmap.h | 14 +-
db/bmroot.c | 14 +-
db/bmroot.h | 14 +-
db/btblock.c | 14 +-
db/btblock.h | 14 +-
db/btdump.c | 16 +-
db/check.c | 14 +-
db/check.h | 14 +-
db/command.c | 14 +-
db/command.h | 14 +-
db/convert.c | 14 +-
db/convert.h | 14 +-
db/crc.c | 13 +-
db/crc.h | 13 +-
db/debug.c | 14 +-
db/debug.h | 14 +-
db/dir2.c | 14 +-
db/dir2.h | 14 +-
db/dir2sf.c | 14 +-
db/dir2sf.h | 14 +-
db/dquot.c | 14 +-
db/dquot.h | 14 +-
db/echo.c | 14 +-
db/echo.h | 14 +-
db/faddr.c | 14 +-
db/faddr.h | 14 +-
db/field.c | 14 +-
db/field.h | 14 +-
db/flist.c | 14 +-
db/flist.h | 1 +
db/fprint.c | 14 +-
db/fprint.h | 14 +-
db/frag.c | 14 +-
db/frag.h | 14 +-
db/freesp.c | 14 +-
db/freesp.h | 14 +-
db/fsmap.c | 16 +-
db/fsmap.h | 16 +-
db/fuzz.c | 14 +-
db/fuzz.h | 16 +-
db/hash.c | 14 +-
db/hash.h | 14 +-
db/help.c | 14 +-
db/help.h | 14 +-
db/info.c | 16 +-
db/init.c | 14 +-
db/init.h | 14 +-
db/inode.c | 14 +-
db/inode.h | 14 +-
db/input.c | 14 +-
db/input.h | 14 +-
db/io.c | 14 +-
db/io.h | 14 +-
db/logformat.c | 14 +-
db/logformat.h | 14 +-
db/malloc.c | 14 +-
db/malloc.h | 14 +-
db/metadump.c | 14 +-
db/metadump.h | 14 +-
db/output.c | 14 +-
db/output.h | 14 +-
db/print.c | 14 +-
db/print.h | 14 +-
db/quit.c | 14 +-
db/quit.h | 14 +-
db/sb.c | 14 +-
db/sb.h | 14 +-
db/sig.c | 14 +-
db/sig.h | 14 +-
db/strvec.c | 14 +-
db/strvec.h | 14 +-
db/symlink.c | 14 +-
db/symlink.h | 14 +-
db/text.c | 14 +-
db/text.h | 14 +-
db/type.c | 14 +-
db/type.h | 14 +-
db/write.c | 14 +-
db/write.h | 14 +-
db/xfs_admin.sh | 1 +
db/xfs_metadump.sh | 1 +
db/xfs_ncheck.sh | 1 +
debian/Makefile | 2 +-
doc/COPYING | 854 ------------------------------------
doc/Makefile | 2 +-
estimate/Makefile | 2 +-
estimate/xfs_estimate.c | 14 +-
fsck/Makefile | 2 +-
fsr/Makefile | 2 +-
fsr/xfs_fsr.c | 14 +-
growfs/Makefile | 2 +-
growfs/xfs_growfs.c | 14 +-
include/Makefile | 14 +-
include/atomic.h | 14 +-
include/avl64.h | 14 +-
include/bitops.h | 1 +
include/builddefs.in | 14 +-
include/buildmacros | 2 +-
include/buildrules | 2 +-
include/cache.h | 14 +-
include/command.h | 14 +-
include/convert.h | 14 +-
include/darwin.h | 14 +-
include/freebsd.h | 14 +-
include/fsgeom.h | 17 +-
include/gnukfreebsd.h | 14 +-
include/handle.h | 14 +-
include/hlist.h | 14 +-
include/input.h | 14 +-
include/install-sh | 2 +-
include/jdm.h | 14 +-
include/kmem.h | 14 +-
include/libfrog.h | 14 +-
include/libxcmd.h | 14 +-
include/libxfs.h | 14 +-
include/libxlog.h | 14 +-
include/linux.h | 14 +-
include/list.h | 14 +-
include/parent.h | 14 +-
include/path.h | 14 +-
include/platform_defs.h.in | 16 +-
include/project.h | 14 +-
include/ptvar.h | 16 +-
include/radix-tree.h | 15 +-
include/workqueue.h | 18 +-
include/xfs.h | 30 +-
include/xfs_arch.h | 14 +-
include/xfs_btree_trace.h | 14 +-
include/xfs_inode.h | 14 +-
include/xfs_log_recover.h | 14 +-
include/xfs_metadump.h | 14 +-
include/xfs_mount.h | 14 +-
include/xfs_multidisk.h | 14 +-
include/xfs_trace.h | 14 +-
include/xfs_trans.h | 14 +-
include/xqm.h | 14 +-
io/Makefile | 2 +-
io/attr.c | 14 +-
io/bmap.c | 14 +-
io/copy_file_range.c | 15 +-
io/cowextsize.c | 16 +-
io/encrypt.c | 15 +-
io/fadvise.c | 14 +-
io/fiemap.c | 14 +-
io/file.c | 14 +-
io/freeze.c | 14 +-
io/fsmap.c | 16 +-
io/fsync.c | 14 +-
io/getrusage.c | 14 +-
io/imap.c | 14 +-
io/init.c | 14 +-
io/init.h | 14 +-
io/inject.c | 14 +-
io/io.h | 14 +-
io/label.c | 17 +-
io/link.c | 14 +-
io/log_writes.c | 14 +-
io/madvise.c | 14 +-
io/mincore.c | 14 +-
io/mmap.c | 14 +-
io/open.c | 14 +-
io/parent.c | 14 +-
io/pread.c | 14 +-
io/prealloc.c | 14 +-
io/pwrite.c | 14 +-
io/readdir.c | 14 +-
io/reflink.c | 14 +-
io/resblks.c | 14 +-
io/scrub.c | 15 +-
io/seek.c | 14 +-
io/sendfile.c | 14 +-
io/shutdown.c | 14 +-
io/stat.c | 15 +-
io/statx.h | 2 +
io/swapext.c | 14 +-
io/sync.c | 14 +-
io/sync_file_range.c | 14 +-
io/truncate.c | 14 +-
io/utimes.c | 14 +-
io/xfs_bmap.sh | 2 +-
io/xfs_freeze.sh | 2 +-
io/xfs_mkfile.sh | 2 +-
libfrog/Makefile | 2 +-
libfrog/avl64.c | 14 +-
libfrog/convert.c | 14 +-
libfrog/darwin.c | 14 +-
libfrog/freebsd.c | 14 +-
libfrog/fsgeom.c | 17 +-
libfrog/irix.c | 14 +-
libfrog/linux.c | 14 +-
libfrog/paths.c | 14 +-
libfrog/projects.c | 14 +-
libfrog/ptvar.c | 16 +-
libfrog/radix-tree.c | 15 +-
libfrog/topology.c | 14 +-
libfrog/util.c | 14 +-
libfrog/workqueue.c | 19 +-
libhandle/Makefile | 2 +-
libhandle/handle.c | 14 +-
libhandle/jdm.c | 14 +-
libxcmd/Makefile | 2 +-
libxcmd/command.c | 14 +-
libxcmd/help.c | 14 +-
libxcmd/input.c | 14 +-
libxcmd/quit.c | 14 +-
libxfs/Makefile | 2 +-
libxfs/cache.c | 14 +-
libxfs/crc32.c | 6 +-
libxfs/crc32defs.h | 1 +
libxfs/defer_item.c | 16 +-
libxfs/gen_crc32table.c | 1 +
libxfs/init.c | 14 +-
libxfs/init.h | 14 +-
libxfs/kmem.c | 1 +
libxfs/libxfs_api_defs.h | 14 +-
libxfs/libxfs_io.h | 18 +-
libxfs/libxfs_priv.h | 14 +-
libxfs/logitem.c | 16 +-
libxfs/rdwr.c | 24 +-
libxfs/trans.c | 16 +-
libxfs/util.c | 14 +-
libxfs/xfs_cksum.h | 1 +
libxlog/Makefile | 2 +-
libxlog/util.c | 14 +-
libxlog/xfs_log_recover.c | 16 +-
logprint/Makefile | 2 +-
logprint/log_copy.c | 14 +-
logprint/log_dump.c | 14 +-
logprint/log_misc.c | 14 +-
logprint/log_print_all.c | 18 +-
logprint/log_print_trans.c | 14 +-
logprint/log_redo.c | 14 +-
logprint/logprint.c | 14 +-
logprint/logprint.h | 14 +-
m4/Makefile | 2 +-
man/Makefile | 2 +-
man/man2/ioctl_xfs_scrub_metadata.2 | 19 +-
mdrestore/Makefile | 2 +-
mdrestore/xfs_mdrestore.c | 14 +-
mkfs/Makefile | 2 +-
mkfs/proto.c | 22 +-
mkfs/xfs_mkfs.c | 28 +-
po/Makefile | 2 +-
quota/Makefile | 2 +-
quota/darwin.c | 14 +-
quota/edit.c | 14 +-
quota/free.c | 14 +-
quota/freebsd.c | 14 +-
quota/init.c | 14 +-
quota/init.h | 14 +-
quota/irix.c | 14 +-
quota/linux.c | 14 +-
quota/path.c | 14 +-
quota/project.c | 14 +-
quota/quot.c | 14 +-
quota/quota.c | 14 +-
quota/quota.h | 14 +-
quota/report.c | 14 +-
quota/state.c | 14 +-
quota/util.c | 14 +-
repair/Makefile | 2 +-
repair/README | 2 +
repair/agheader.c | 20 +-
repair/agheader.h | 14 +-
repair/attr_repair.c | 18 +-
repair/attr_repair.h | 14 +-
repair/avl.c | 14 +-
repair/avl.h | 14 +-
repair/bmap.c | 14 +-
repair/bmap.h | 14 +-
repair/btree.c | 14 +-
repair/btree.h | 14 +-
repair/da_util.c | 13 +-
repair/da_util.h | 14 +-
repair/dino_chunks.c | 16 +-
repair/dinode.c | 14 +-
repair/dinode.h | 14 +-
repair/dir2.c | 14 +-
repair/dir2.h | 14 +-
repair/err_protos.h | 14 +-
repair/globals.c | 14 +-
repair/globals.h | 14 +-
repair/incore.c | 14 +-
repair/incore.h | 14 +-
repair/incore_bmc.c | 14 +-
repair/incore_ext.c | 14 +-
repair/incore_ino.c | 14 +-
repair/init.c | 14 +-
repair/phase1.c | 14 +-
repair/phase2.c | 14 +-
repair/phase3.c | 14 +-
repair/phase4.c | 14 +-
repair/phase5.c | 14 +-
repair/phase6.c | 18 +-
repair/phase7.c | 14 +-
repair/prefetch.c | 6 +-
repair/prefetch.h | 2 +
repair/progress.c | 1 +
repair/progress.h | 2 +
repair/protos.h | 14 +-
repair/rmap.c | 16 +-
repair/rmap.h | 16 +-
repair/rt.c | 14 +-
repair/rt.h | 14 +-
repair/sb.c | 14 +-
repair/scan.c | 14 +-
repair/scan.h | 14 +-
repair/slab.c | 16 +-
repair/slab.h | 16 +-
repair/threads.c | 2 +
repair/threads.h | 2 +
repair/versions.c | 14 +-
repair/versions.h | 14 +-
repair/xfs_repair.c | 14 +-
rtcp/Makefile | 2 +-
rtcp/xfs_rtcp.c | 14 +-
scrub/Makefile | 2 +-
scrub/bitmap.c | 16 +-
scrub/bitmap.h | 16 +-
scrub/common.c | 16 +-
scrub/common.h | 16 +-
scrub/counter.c | 16 +-
scrub/counter.h | 16 +-
scrub/disk.c | 16 +-
scrub/disk.h | 16 +-
scrub/filemap.c | 16 +-
scrub/filemap.h | 16 +-
scrub/fscounters.c | 16 +-
scrub/fscounters.h | 16 +-
scrub/inodes.c | 16 +-
scrub/inodes.h | 16 +-
scrub/phase1.c | 16 +-
scrub/phase2.c | 16 +-
scrub/phase3.c | 16 +-
scrub/phase4.c | 16 +-
scrub/phase5.c | 16 +-
scrub/phase6.c | 16 +-
scrub/phase7.c | 16 +-
scrub/progress.c | 16 +-
scrub/progress.h | 16 +-
scrub/read_verify.c | 16 +-
scrub/read_verify.h | 16 +-
scrub/scrub.c | 16 +-
scrub/scrub.h | 16 +-
scrub/spacemap.c | 16 +-
scrub/spacemap.h | 16 +-
scrub/unicrash.c | 16 +-
scrub/unicrash.h | 16 +-
scrub/vfs.c | 16 +-
scrub/vfs.h | 16 +-
scrub/xfs_scrub.c | 16 +-
scrub/xfs_scrub.h | 16 +-
scrub/xfs_scrub_all.in | 19 +-
spaceman/Makefile | 2 +-
spaceman/file.c | 14 +-
spaceman/freesp.c | 14 +-
spaceman/info.c | 16 +-
spaceman/init.c | 14 +-
spaceman/init.h | 14 +-
spaceman/prealloc.c | 14 +-
spaceman/space.h | 14 +-
spaceman/trim.c | 14 +-
spaceman/xfs_info.sh | 1 +
tools/find-api-violations.sh | 1 +
tools/libxfs-apply | 1 +
tools/libxfs-diff | 1 +
tools/xfsbuflock.py | 19 +-
393 files changed, 1291 insertions(+), 5440 deletions(-)
create mode 100644 LICENSES/GPL-2.0
create mode 100644 LICENSES/LGPL-2.1
delete mode 100644 doc/COPYING
mode change 100755 => 100644 io/utimes.c
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 873 bytes --]
^ permalink raw reply
* [meta-oe][PATCH] iperf3: Upgrade to 3.6
From: mingli.yu @ 2018-07-24 5:42 UTC (permalink / raw)
To: openembedded-devel
From: Mingli Yu <mingli.yu@windriver.com>
* Licence-Update:
- Copyright years are updated to 2018
- Remove the part about src/tcp_window_size.{c,h}
as iperf3 uses get/setsockopt() with SO_SNDBUF
and SO_RCVBUF directly now
* Update the path parameter for --with-openssl as
${RECIPE_SYSROOT}/usr to fix the below do_configure
error
| checking for openssl/ssl.h in /poky-build/tmp/work/i586-poky-linux/iperf3/3.6-r0/recipe-sysroot... no
| checking whether compiling and linking against OpenSSL works... no
| configure: error: in `/poky-build/tmp/work/i586-poky-linux/iperf3/3.6-r0/build':
| configure: error: --with-openssl was given, but test for OpenSSL failed
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
.../iperf3/{iperf3_3.2.bb => iperf3_3.6.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta-oe/recipes-benchmark/iperf3/{iperf3_3.2.bb => iperf3_3.6.bb} (83%)
diff --git a/meta-oe/recipes-benchmark/iperf3/iperf3_3.2.bb b/meta-oe/recipes-benchmark/iperf3/iperf3_3.6.bb
similarity index 83%
rename from meta-oe/recipes-benchmark/iperf3/iperf3_3.2.bb
rename to meta-oe/recipes-benchmark/iperf3/iperf3_3.6.bb
index 2ed08110f..a575d465e 100644
--- a/meta-oe/recipes-benchmark/iperf3/iperf3_3.2.bb
+++ b/meta-oe/recipes-benchmark/iperf3/iperf3_3.6.bb
@@ -9,7 +9,7 @@ SECTION = "console/network"
BUGTRACKER = "https://github.com/esnet/iperf/issues"
AUTHOR = "ESNET <info@es.net>, Lawrence Berkeley National Laboratory <websupport@lbl.gov>"
LICENSE = "BSD"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=d098223e44bdd19585315ee75cd9d2d7"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=a9a036136b748453e839c0eb8906ef2e"
DEPENDS = "openssl"
@@ -18,7 +18,7 @@ SRC_URI = "git://github.com/esnet/iperf.git \
file://0002-Remove-pg-from-profile_CFLAGS.patch \
"
-SRCREV = "88d907f7fb58bfab5d086c5da60c922e1c582c92"
+SRCREV = "88f3ad87f38762081a6d7127890ff5c3a052b06a"
S = "${WORKDIR}/git"
@@ -28,6 +28,6 @@ PACKAGECONFIG[lksctp] = "ac_cv_header_netinet_sctp_h=yes,ac_cv_header_netinet_sc
CFLAGS += "-D_GNU_SOURCE"
-EXTRA_OECONF = "--with-openssl=${RECIPE_SYSROOT}"
+EXTRA_OECONF = "--with-openssl=${RECIPE_SYSROOT}/usr"
BBCLASSEXTEND = "native"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 1/2 V3] xfs_repair: notify user if free inodes contain errors
From: Eric Sandeen @ 2018-07-24 4:35 UTC (permalink / raw)
To: Eric Sandeen, linux-xfs
In-Reply-To: <75f628bc-e8e7-b4fd-0bbb-fb3ca0fabac8@sandeen.net>
On 7/23/18 7:34 PM, Eric Sandeen wrote:
> xfs_repair checks allocated but unused (free) inodes in on-disk clusters,
> and up until now silently repairs any errors, and as a result does not
> alter exit status if errors are found.
>
> The in-kernel verifiers will be noisy about these errors and instruct
> the user to run repair, so it's best if repair is explicit about any
> fixes it makes as a result.
>
> To ensure we catch anything the kernel would complain about, re-use
> xfs_dinode_verify to determine whether we must clear a free inode.
>
> Note, however, that the verifier contains only a subset of the checks
> currently in clear_dinode. This should be ok; if it's not, the checks
> should be added to the verifier in any case.
>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Ugh, dammit, pulled the trigger too soon, tests were looking fine until
the last few. Need to look at this more.
> ---
>
> diff --git a/libxfs/libxfs_api_defs.h b/libxfs/libxfs_api_defs.h
> index a98483b..05c06a7 100644
> --- a/libxfs/libxfs_api_defs.h
> +++ b/libxfs/libxfs_api_defs.h
> @@ -134,6 +134,7 @@
> #define xfs_symlink_hdr_ok libxfs_symlink_hdr_ok
>
> #define xfs_verify_cksum libxfs_verify_cksum
> +#define xfs_dinode_verify libxfs_dinode_verify
>
> #define xfs_alloc_ag_max_usable libxfs_alloc_ag_max_usable
> #define xfs_allocbt_maxrecs libxfs_allocbt_maxrecs
> diff --git a/repair/dinode.c b/repair/dinode.c
> index d36338f..c0db15a 100644
> --- a/repair/dinode.c
> +++ b/repair/dinode.c
> @@ -2560,12 +2560,20 @@ _("bad (negative) size %" PRId64 " on inode %" PRIu64 "\n"),
> */
> if (was_free) {
> /*
> - * easy case, inode free -- inode and map agree, clear
> + * easy case, inode free -- inode and map agree, check
> * it just in case to ensure that format, etc. are
> * set correctly
> */
> - if (!no_modify)
> - *dirty += clear_dinode(mp, dino, lino);
> + if (libxfs_dinode_verify(mp, lino, dino) != NULL) {
> + do_warn(
> + _("free inode %" PRIu64 " contains errors, "), lino);
> + if (!no_modify) {
> + *dirty += clear_dinode(mp, dino, lino);
> + do_warn(_("corrected\n"));
> + } else {
> + do_warn(_("would correct\n"));
> + }
> + }
> *used = is_free;
> return 0;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: arm: syna: add support for the AS370 SoC
From: Jisheng Zhang @ 2018-07-24 5:40 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-kernel, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20180720151529.GA26487@rob-hp-laptop>
Hi Rob
On Fri, 20 Jul 2018 09:15:29 -0600 Rob Herring wrote:
> On Fri, Jul 13, 2018 at 05:24:57PM +0800, Jisheng Zhang wrote:
> > The AS370 SoC is a new derivative of the berlin family. The only
> > difference is the SoC isn't named as berlin*.
>
> So is it a derivative or just rebranded?
A derivative new generation SoC.
>
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > Documentation/devicetree/bindings/arm/syna.txt | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/syna.txt b/Documentation/devicetree/bindings/arm/syna.txt
> > index 3bab18409b7a..3ba1d7b5ee74 100644
> > --- a/Documentation/devicetree/bindings/arm/syna.txt
> > +++ b/Documentation/devicetree/bindings/arm/syna.txt
> > @@ -1,4 +1,4 @@
> > -Marvell Berlin SoC Family Device Tree Bindings
> > +Synaptics SoC Device Tree Bindings
>
> Perhaps some note about what has happened here. Otherwise it looks
> strange having "Marvell Berlin" in the document when the title says
> Synaptics SoC.
Good idea. will do in v2
>
> > ---------------------------------------------------------------
> >
> > Work in progress statement:
> > @@ -13,6 +13,10 @@ stable binding/ABI.
> >
> > ---------------------------------------------------------------
> >
> > +Boards with the Synaptics AS370 SoC shall have the following properties:
> > + Required root node property:
> > + compatible: "syna,as370"
> > +
> > Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500
> > shall have the following properties:
> >
> > --
> > 2.18.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/3] dt-bindings: arm: syna: add support for the AS370 SoC
From: Jisheng Zhang @ 2018-07-24 5:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180720151529.GA26487@rob-hp-laptop>
Hi Rob
On Fri, 20 Jul 2018 09:15:29 -0600 Rob Herring wrote:
> On Fri, Jul 13, 2018 at 05:24:57PM +0800, Jisheng Zhang wrote:
> > The AS370 SoC is a new derivative of the berlin family. The only
> > difference is the SoC isn't named as berlin*.
>
> So is it a derivative or just rebranded?
A derivative new generation SoC.
>
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > Documentation/devicetree/bindings/arm/syna.txt | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/syna.txt b/Documentation/devicetree/bindings/arm/syna.txt
> > index 3bab18409b7a..3ba1d7b5ee74 100644
> > --- a/Documentation/devicetree/bindings/arm/syna.txt
> > +++ b/Documentation/devicetree/bindings/arm/syna.txt
> > @@ -1,4 +1,4 @@
> > -Marvell Berlin SoC Family Device Tree Bindings
> > +Synaptics SoC Device Tree Bindings
>
> Perhaps some note about what has happened here. Otherwise it looks
> strange having "Marvell Berlin" in the document when the title says
> Synaptics SoC.
Good idea. will do in v2
>
> > ---------------------------------------------------------------
> >
> > Work in progress statement:
> > @@ -13,6 +13,10 @@ stable binding/ABI.
> >
> > ---------------------------------------------------------------
> >
> > +Boards with the Synaptics AS370 SoC shall have the following properties:
> > + Required root node property:
> > + compatible: "syna,as370"
> > +
> > Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500
> > shall have the following properties:
> >
> > --
> > 2.18.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/4] MIPS: lantiq: Do not enable IRQs in dma open
From: David Miller @ 2018-07-24 5:39 UTC (permalink / raw)
To: hauke
Cc: paul.burton, netdev, andrew, vivien.didelot, f.fainelli, john,
linux-mips, dev, hauke.mehrtens
In-Reply-To: <dd3980b2-b699-a988-3ecd-8261c782244f@hauke-m.de>
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Tue, 24 Jul 2018 07:32:27 +0200
>
>
> On 07/24/2018 02:19 AM, Paul Burton wrote:
>> Hi Hauke,
>>
>> On Sat, Jul 21, 2018 at 09:13:55PM +0200, Hauke Mehrtens wrote:
>>> When a DMA channel is opened the IRQ should not get activated
>>> automatically, this allows it to pull data out manually without the help
>>> of interrupts. This is needed for a workaround in the vrx200 Ethernet
>>> driver.
>>>
>>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>>> ---
>>> arch/mips/lantiq/xway/dma.c | 1 -
>>> drivers/net/ethernet/lantiq_etop.c | 1 +
>>> 2 files changed, 1 insertion(+), 1 deletion(-)
>>
>> If you'd like this to go via the netdev tree to keep it with the rest of
>> the series:
>>
>> Acked-by: Paul Burton <paul.burton@mips.com>
>
> Thanks, I also prefer that this goes through netdev.
Please be sure to repost your series with Paul's ACK added.
Also, in the patch postings and cover letter, put "net-next" in
the Subject line so that the target tree is clear, like:
Subject: [PATCH net-next 1/4] MIPS: ...
Thank you.
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2018-07-23
From: David Miller @ 2018-07-24 4:30 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87tvopx3pm.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 23 Jul 2018 20:27:17 +0300
> this first pull request for 4.19 got delayed as I was on vacation for
> two weeks. I was supposed to send this before my vacation but didn't
> manage to do it due to other urgent stuff, but I'll try to catch up with
> everything this week so that we get everything ready on time for 4.19.
>
> More info in the signed tag below and please let me know if there are
> any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH net] sock: fix sg page frag coalescing in sk_alloc_sg
From: David Miller @ 2018-07-24 4:29 UTC (permalink / raw)
To: daniel; +Cc: netdev, davejwatson, borisp, john.fastabend
In-Reply-To: <20180723203754.4041-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Mon, 23 Jul 2018 22:37:54 +0200
> Current sg coalescing logic in sk_alloc_sg() (latter is used by tls and
> sockmap) is not quite correct in that we do fetch the previous sg entry,
> however the subsequent check whether the refilled page frag from the
> socket is still the same as from the last entry with prior offset and
> length matching the start of the current buffer is comparing always the
> first sg list entry instead of the prior one.
>
> Fixes: 3c4d7559159b ("tls: kernel TLS support")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Dave Watson <davejwatson@fb.com>
Applied and queued up for -stable, thanks Daniel.
^ permalink raw reply
* [PATCH kernel for v4.14 and v4.17 stable] KVM: PPC: Check if IOMMU page is contained in the pinned physical page
From: Alexey Kardashevskiy @ 2018-07-24 5:32 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, Michael Ellerman, stable, gregkh, #, v4.12+
A VM which has:
- a DMA capable device passed through to it (eg. network card);
- running a malicious kernel that ignores H_PUT_TCE failure;
- capability of using IOMMU pages bigger that physical pages
can create an IOMMU mapping that exposes (for example) 16MB of
the host physical memory to the device when only 64K was allocated to the VM.
The remaining 16MB - 64K will be some other content of host memory, possibly
including pages of the VM, but also pages of host kernel memory, host
programs or other VMs.
The attacking VM does not control the location of the page it can map,
and is only allowed to map as many pages as it has pages of RAM.
We already have a check in drivers/vfio/vfio_iommu_spapr_tce.c that
an IOMMU page is contained in the physical page so the PCI hardware won't
get access to unassigned host memory; however this check is missing in
the KVM fastpath (H_PUT_TCE accelerated code). We were lucky so far and
did not hit this yet as the very first time when the mapping happens
we do not have tbl::it_userspace allocated yet and fall back to
the userspace which in turn calls VFIO IOMMU driver, this fails and
the guest does not retry,
This stores the smallest preregistered page size in the preregistered
region descriptor and changes the mm_iommu_xxx API to check this against
the IOMMU page size.
This calculates maximum page size as a minimum of the natural region
alignment and compound page size. For the page shift this uses the shift
returned by find_linux_pte() which indicates how the page is mapped to
the current userspace - if the page is huge and this is not a zero, then
it is a leaf pte and the page is mapped within the range.
Fixes: 121f80ba68f1 ("KVM: PPC: VFIO: Add in-kernel acceleration for VFIO")
Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 76fa4975f3ed12d15762bc979ca44078598ed8ee)
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
The original patch did not apply because of fad953ce which fixed
all vmalloc's to use array_size() so the backport is pretty trivial
and applies to v4.17 stable as well.
---
arch/powerpc/include/asm/mmu_context.h | 4 ++--
arch/powerpc/kvm/book3s_64_vio.c | 2 +-
arch/powerpc/kvm/book3s_64_vio_hv.c | 6 ++++--
arch/powerpc/mm/mmu_context_iommu.c | 37 ++++++++++++++++++++++++++++++++--
drivers/vfio/vfio_iommu_spapr_tce.c | 2 +-
5 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index 44fdf47..6f67ff5 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -35,9 +35,9 @@ extern struct mm_iommu_table_group_mem_t *mm_iommu_lookup_rm(
extern struct mm_iommu_table_group_mem_t *mm_iommu_find(struct mm_struct *mm,
unsigned long ua, unsigned long entries);
extern long mm_iommu_ua_to_hpa(struct mm_iommu_table_group_mem_t *mem,
- unsigned long ua, unsigned long *hpa);
+ unsigned long ua, unsigned int pageshift, unsigned long *hpa);
extern long mm_iommu_ua_to_hpa_rm(struct mm_iommu_table_group_mem_t *mem,
- unsigned long ua, unsigned long *hpa);
+ unsigned long ua, unsigned int pageshift, unsigned long *hpa);
extern long mm_iommu_mapped_inc(struct mm_iommu_table_group_mem_t *mem);
extern void mm_iommu_mapped_dec(struct mm_iommu_table_group_mem_t *mem);
#endif
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 4dffa61..e14cec6 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -433,7 +433,7 @@ long kvmppc_tce_iommu_map(struct kvm *kvm, struct iommu_table *tbl,
/* This only handles v2 IOMMU type, v1 is handled via ioctl() */
return H_TOO_HARD;
- if (WARN_ON_ONCE(mm_iommu_ua_to_hpa(mem, ua, &hpa)))
+ if (WARN_ON_ONCE(mm_iommu_ua_to_hpa(mem, ua, tbl->it_page_shift, &hpa)))
return H_HARDWARE;
if (mm_iommu_mapped_inc(mem))
diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c
index c32e9bfe..648cf6c 100644
--- a/arch/powerpc/kvm/book3s_64_vio_hv.c
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@ -262,7 +262,8 @@ static long kvmppc_rm_tce_iommu_map(struct kvm *kvm, struct iommu_table *tbl,
if (!mem)
return H_TOO_HARD;
- if (WARN_ON_ONCE_RM(mm_iommu_ua_to_hpa_rm(mem, ua, &hpa)))
+ if (WARN_ON_ONCE_RM(mm_iommu_ua_to_hpa_rm(mem, ua, tbl->it_page_shift,
+ &hpa)))
return H_HARDWARE;
pua = (void *) vmalloc_to_phys(pua);
@@ -431,7 +432,8 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
mem = mm_iommu_lookup_rm(vcpu->kvm->mm, ua, IOMMU_PAGE_SIZE_4K);
if (mem)
- prereg = mm_iommu_ua_to_hpa_rm(mem, ua, &tces) == 0;
+ prereg = mm_iommu_ua_to_hpa_rm(mem, ua,
+ IOMMU_PAGE_SHIFT_4K, &tces) == 0;
}
if (!prereg) {
diff --git a/arch/powerpc/mm/mmu_context_iommu.c b/arch/powerpc/mm/mmu_context_iommu.c
index e0a2d8e..8160559 100644
--- a/arch/powerpc/mm/mmu_context_iommu.c
+++ b/arch/powerpc/mm/mmu_context_iommu.c
@@ -19,6 +19,7 @@
#include <linux/hugetlb.h>
#include <linux/swap.h>
#include <asm/mmu_context.h>
+#include <asm/pte-walk.h>
static DEFINE_MUTEX(mem_list_mutex);
@@ -27,6 +28,7 @@ struct mm_iommu_table_group_mem_t {
struct rcu_head rcu;
unsigned long used;
atomic64_t mapped;
+ unsigned int pageshift;
u64 ua; /* userspace address */
u64 entries; /* number of entries in hpas[] */
u64 *hpas; /* vmalloc'ed */
@@ -126,6 +128,8 @@ long mm_iommu_get(struct mm_struct *mm, unsigned long ua, unsigned long entries,
{
struct mm_iommu_table_group_mem_t *mem;
long i, j, ret = 0, locked_entries = 0;
+ unsigned int pageshift;
+ unsigned long flags;
struct page *page = NULL;
mutex_lock(&mem_list_mutex);
@@ -160,6 +164,12 @@ long mm_iommu_get(struct mm_struct *mm, unsigned long ua, unsigned long entries,
goto unlock_exit;
}
+ /*
+ * For a starting point for a maximum page size calculation
+ * we use @ua and @entries natural alignment to allow IOMMU pages
+ * smaller than huge pages but still bigger than PAGE_SIZE.
+ */
+ mem->pageshift = __ffs(ua | (entries << PAGE_SHIFT));
mem->hpas = vzalloc(entries * sizeof(mem->hpas[0]));
if (!mem->hpas) {
kfree(mem);
@@ -200,6 +210,23 @@ long mm_iommu_get(struct mm_struct *mm, unsigned long ua, unsigned long entries,
}
}
populate:
+ pageshift = PAGE_SHIFT;
+ if (PageCompound(page)) {
+ pte_t *pte;
+ struct page *head = compound_head(page);
+ unsigned int compshift = compound_order(head);
+
+ local_irq_save(flags); /* disables as well */
+ pte = find_linux_pte(mm->pgd, ua, NULL, &pageshift);
+ local_irq_restore(flags);
+
+ /* Double check it is still the same pinned page */
+ if (pte && pte_page(*pte) == head &&
+ pageshift == compshift)
+ pageshift = max_t(unsigned int, pageshift,
+ PAGE_SHIFT);
+ }
+ mem->pageshift = min(mem->pageshift, pageshift);
mem->hpas[i] = page_to_pfn(page) << PAGE_SHIFT;
}
@@ -350,7 +377,7 @@ struct mm_iommu_table_group_mem_t *mm_iommu_find(struct mm_struct *mm,
EXPORT_SYMBOL_GPL(mm_iommu_find);
long mm_iommu_ua_to_hpa(struct mm_iommu_table_group_mem_t *mem,
- unsigned long ua, unsigned long *hpa)
+ unsigned long ua, unsigned int pageshift, unsigned long *hpa)
{
const long entry = (ua - mem->ua) >> PAGE_SHIFT;
u64 *va = &mem->hpas[entry];
@@ -358,6 +385,9 @@ long mm_iommu_ua_to_hpa(struct mm_iommu_table_group_mem_t *mem,
if (entry >= mem->entries)
return -EFAULT;
+ if (pageshift > mem->pageshift)
+ return -EFAULT;
+
*hpa = *va | (ua & ~PAGE_MASK);
return 0;
@@ -365,7 +395,7 @@ long mm_iommu_ua_to_hpa(struct mm_iommu_table_group_mem_t *mem,
EXPORT_SYMBOL_GPL(mm_iommu_ua_to_hpa);
long mm_iommu_ua_to_hpa_rm(struct mm_iommu_table_group_mem_t *mem,
- unsigned long ua, unsigned long *hpa)
+ unsigned long ua, unsigned int pageshift, unsigned long *hpa)
{
const long entry = (ua - mem->ua) >> PAGE_SHIFT;
void *va = &mem->hpas[entry];
@@ -374,6 +404,9 @@ long mm_iommu_ua_to_hpa_rm(struct mm_iommu_table_group_mem_t *mem,
if (entry >= mem->entries)
return -EFAULT;
+ if (pageshift > mem->pageshift)
+ return -EFAULT;
+
pa = (void *) vmalloc_to_phys(va);
if (!pa)
return -EFAULT;
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
index b751dd6..b4c68f3 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -467,7 +467,7 @@ static int tce_iommu_prereg_ua_to_hpa(struct tce_container *container,
if (!mem)
return -EINVAL;
- ret = mm_iommu_ua_to_hpa(mem, tce, phpa);
+ ret = mm_iommu_ua_to_hpa(mem, tce, shift, phpa);
if (ret)
return -EINVAL;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 1/4] MIPS: lantiq: Do not enable IRQs in dma open
From: Hauke Mehrtens @ 2018-07-24 5:32 UTC (permalink / raw)
To: Paul Burton
Cc: davem, netdev, andrew, vivien.didelot, f.fainelli, john,
linux-mips, dev, hauke.mehrtens
In-Reply-To: <20180724001923.d4y7eth7k3ng44lq@pburton-laptop>
On 07/24/2018 02:19 AM, Paul Burton wrote:
> Hi Hauke,
>
> On Sat, Jul 21, 2018 at 09:13:55PM +0200, Hauke Mehrtens wrote:
>> When a DMA channel is opened the IRQ should not get activated
>> automatically, this allows it to pull data out manually without the help
>> of interrupts. This is needed for a workaround in the vrx200 Ethernet
>> driver.
>>
>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>> ---
>> arch/mips/lantiq/xway/dma.c | 1 -
>> drivers/net/ethernet/lantiq_etop.c | 1 +
>> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> If you'd like this to go via the netdev tree to keep it with the rest of
> the series:
>
> Acked-by: Paul Burton <paul.burton@mips.com>
Thanks, I also prefer that this goes through netdev.
> Though I'd be happier if we didn't have DMA code seemingly used only by
> an ethernet driver in arch/mips/ :)
There are also some out of tree driver that use this DMA code. This
should probably be converted to a DMA channel driver but that is not
very high on my todo list.
Hauke
^ permalink raw reply
* Re: [PATCH v4 5/5] doc: add ZLIB PMD guide
From: Verma, Shally @ 2018-07-24 5:32 UTC (permalink / raw)
To: De Lara Guarch, Pablo
Cc: dev@dpdk.org, Athreya, Narayana Prasad, Challa, Mahipal,
Sahu, Sunila, Gupta, Ashish
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D8977F8FFBFD@IRSMSX107.ger.corp.intel.com>
>-----Original Message-----
>From: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>Sent: 24 July 2018 02:49
>To: Verma, Shally <Shally.Verma@cavium.com>
>Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Challa, Mahipal
><Mahipal.Challa@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>
>Subject: RE: [dpdk-dev] [PATCH v4 5/5] doc: add ZLIB PMD guide
>
>External Email
>
>Hi Shally,
>
>> -----Original Message-----
>> From: Verma, Shally [mailto:Shally.Verma@cavium.com]
>> Sent: Monday, July 23, 2018 7:00 PM
>> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>> Cc: dev@dpdk.org; Athreya, Narayana Prasad
>> <NarayanaPrasad.Athreya@cavium.com>; Challa, Mahipal
>> <Mahipal.Challa@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
>> Gupta, Ashish <Ashish.Gupta@cavium.com>
>> Subject: RE: [dpdk-dev] [PATCH v4 5/5] doc: add ZLIB PMD guide
>>
>>
>>
>> >-----Original Message-----
>> >From: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>> >Sent: 23 July 2018 23:28
>> >To: Verma, Shally <Shally.Verma@cavium.com>
>> >Cc: dev@dpdk.org; Athreya, Narayana Prasad
>> ><NarayanaPrasad.Athreya@cavium.com>; Challa, Mahipal
>> ><Mahipal.Challa@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
>> >Gupta, Ashish <Ashish.Gupta@cavium.com>
>> >Subject: RE: [dpdk-dev] [PATCH v4 5/5] doc: add ZLIB PMD guide
>> >
>> >External Email
>> >
>> >> -----Original Message-----
>> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Shally Verma
>> >> Sent: Monday, July 23, 2018 3:51 PM
>> >> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>> >> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
>> >> mchalla@caviumnetworks.com; Sunila Sahu
>> >> <sunila.sahu@caviumnetworks.com>; Ashish Gupta
>> >> <ashish.gupta@caviumnetworks.com>
>> >> Subject: [dpdk-dev] [PATCH v4 5/5] doc: add ZLIB PMD guide
>> >>
>> >> Add zlib pmd feature support and user guide with build and run
>> >> instructions
>> >>
>> >> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>> >> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
>> >> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
>> >> ---
>> >> MAINTAINERS | 2 +
>> >> doc/guides/compressdevs/features/zlib.ini | 11 +++++
>> >> doc/guides/compressdevs/index.rst | 1 +
>> >> doc/guides/compressdevs/zlib.rst | 69
>> >> +++++++++++++++++++++++++++++++
>> >> 4 files changed, 83 insertions(+)
>> >>
>> >> diff --git a/MAINTAINERS b/MAINTAINERS index ca27c6f..7e3c450 100644
>> >> --- a/MAINTAINERS
>> >> +++ b/MAINTAINERS
>> >> @@ -875,6 +875,8 @@ F: drivers/common/qat/ ZLIB
>> >> M: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>> >> F: drivers/compress/zlib/
>> >> +F: doc/guides/compressdevs/zlib.rst
>> >> +F: doc/guides/compressdevs/features/zlib.ini
>> >>
>> >> Eventdev Drivers
>> >> ----------------
>> >> diff --git a/doc/guides/compressdevs/features/zlib.ini
>> >> b/doc/guides/compressdevs/features/zlib.ini
>> >> new file mode 100644
>> >> index 0000000..c794643
>> >> --- /dev/null
>> >> +++ b/doc/guides/compressdevs/features/zlib.ini
>> >> @@ -0,0 +1,11 @@
>> >> +;
>> >> +; Refer to default.ini for the full list of available PMD features.
>> >> +;
>> >> +; Supported features of 'ZLIB' compression driver.
>> >> +;
>> >> +[Features]
>> >> +Pass-through = Y
>> >> +Deflate = Y
>> >> +Fixed = Y
>> >> +Dynamic = Y
>> >> +OOP SGL In SGL Out = Y
>> >
>> >I assume that you support also "OOP SGL In LB Out" and "OOP LB In SGL Out",
>> right?
>> yes, but untested thus not claiming.
>
>Right, but knowing that a Linear buffer is basically an SGL with just one segment,
>I think it is safe to say that you support these two other cases.
>The only reason why we have them is in case, you only support one of them, but you don't support SGL in SGL Out).
>
>I won't have time to extend the test for those combinations in this release, I hope I can do that in the next one,
>but as said, I think it is safe to claim that this PMD supports all the cases.
Agree. However I would still wait to test them before claiming support.
Thanks
Shally
>
>>
>> Thanks
>> Shally
^ permalink raw reply
* Re: xfsprogs-dev failing to build
From: Darrick J. Wong @ 2018-07-24 4:27 UTC (permalink / raw)
To: Vincent McIntyre; +Cc: linux-xfs
In-Reply-To: <20180724040944.GH27624@mayhem.atnf.CSIRO.AU>
On Tue, Jul 24, 2018 at 02:09:44PM +1000, Vincent McIntyre wrote:
> Hi
>
> I am trying to build the latest xfsprogs on an older system,
> details below. The configure script is failing on what appears
> to be an unexpanded m4 macro,
>
> PKG_CHECK_MODULES(libicu, icu-i18n, have_libicu=yes, have_libicu=no)
Hmmm, I thought that pkg.m4 would be pulled in via aclocal
automatically, but I could be wrong. :/
What version of pkg-config (or I guess pkgconf?) is on the system?
> I'm not quite sure how to work around this or if it is a bug.
> Any advice would be appreciated.
Definitely some sort of bug...
--D
>
> Kind regards
> Vince
>
> System details:
>
> % cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
> NAME="Debian GNU/Linux"
> VERSION_ID="8"
> VERSION="8 (jessie)"
> ID=debian
> HOME_URL="http://www.debian.org/"
> SUPPORT_URL="http://www.debian.org/support"
> BUG_REPORT_URL="https://bugs.debian.org/"
>
> % git remote -v
> origin git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git (fetch)
> origin git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git (push)
>
> % git log -1
> commit 0821de47b419e6a2ed0e8a2c64fd26a93c398093
> Author: Eric Sandeen <sandeen@redhat.com>
> Date: Fri Jun 29 02:52:21 2018
>
> xfsprogs: Release v4.17.0
>
> Update all the necessary files for a 4.17.0 release.
>
> Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
>
> Problem demonstration:
>
> % make
> libtoolize -c `libtoolize -n -i >/dev/null 2>/dev/null && echo -i` -f
> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.
> libtoolize: copying file `./config.guess'
> libtoolize: copying file `./config.sub'
> libtoolize: copying file `./install-sh'
> libtoolize: copying file `./ltmain.sh'
> libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
> libtoolize: copying file `m4/libtool.m4'
> libtoolize: copying file `m4/ltoptions.m4'
> libtoolize: copying file `m4/ltsugar.m4'
> libtoolize: copying file `m4/ltversion.m4'
> libtoolize: copying file `m4/lt~obsolete.m4'
> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> cp include/install-sh .
> aclocal -I m4
> configure.ac:191: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
> m4/package_services.m4:4: AC_CONFIG_SYSTEMD_SYSTEM_UNIT_DIR is expanded from...
> configure.ac:191: the top level
> configure.ac:191: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
> m4/package_services.m4:4: AC_CONFIG_SYSTEMD_SYSTEM_UNIT_DIR is expanded from...
> configure.ac:191: the top level
> autoconf
> configure.ac:191: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
> m4/package_services.m4:4: AC_CONFIG_SYSTEMD_SYSTEM_UNIT_DIR is expanded from...
> configure.ac:191: the top level
> ./configure $LOCAL_CONFIGURE_OPTIONS
> checking for a BSD-compatible install... /usr/bin/install -c
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking how to print strings... printf
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for a sed that does not truncate output... /bin/sed
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for fgrep... /bin/grep -F
> checking for ld used by gcc... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 1572864
> checking whether the shell understands some XSI constructs... yes
> checking whether the shell understands "+="... yes
> checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
> checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
> checking for /usr/bin/ld option to reload object files... -r
> checking for objdump... objdump
> checking how to recognize dependent libraries... pass_all
> checking for dlltool... no
> checking how to associate runtime and link libraries... printf %s\n
> checking for ar... ar
> checking for archiver @FILE support... @
> checking for strip... strip
> checking for ranlib... ranlib
> checking for gawk... gawk
> checking command to parse /usr/bin/nm -B output from gcc object... ok
> checking for sysroot... no
> checking for mt... mt
> checking if mt is a manifest tool... no
> checking how to run the C preprocessor... gcc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fPIC -DPIC
> checking if gcc PIC flag -fPIC -DPIC works... yes
> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
> checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
> checking whether -lc should be explicitly linked in... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> checking for gcc... (cached) gcc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for gcc option to accept ISO C89... (cached) none needed
> checking for gcc... (cached) gcc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for gcc option to accept ISO C89... (cached) none needed
> checking for gcc... (cached) gcc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for gcc option to accept ISO C89... (cached) none needed
> checking for gmake... no
> checking for make... /usr/bin/make
> checking for tar... /bin/tar
> checking for gzip... /bin/gzip
> checking whether gcc -MM is supported... yes
> checking for sort... /usr/bin/sort
> checking whether ln -s works... yes
> checking for msgfmt... /usr/bin/msgfmt
> checking for msgmerge... /usr/bin/msgmerge
> checking for xgettext... /usr/bin/xgettext
> checking for rpm... no
> checking uuid.h usability... no
> checking uuid.h presence... no
> checking for uuid.h... no
> checking sys/uuid.h usability... no
> checking sys/uuid.h presence... no
> checking for sys/uuid.h... no
> checking uuid/uuid.h usability... yes
> checking uuid/uuid.h presence... yes
> checking for uuid/uuid.h... yes
> checking for uuid_compare... no
> checking for uuid_compare in -luuid... yes
> checking pthread.h usability... yes
> checking pthread.h presence... yes
> checking for pthread.h... yes
> checking for pthread_mutex_init in -lpthread... yes
> checking for fadvise ... yes
> checking for madvise ... yes
> checking for mincore ... yes
> checking for sendfile ... yes
> checking for getmntent ... yes
> checking for getmntinfo ... no
> checking for fallocate... yes
> checking for fiemap... yes
> checking for pwritev2... no
> checking for preadv... yes
> checking for copy_file_range... no
> checking for sync_file_range... yes
> checking for syncfs... yes
> checking mntent.h usability... yes
> checking mntent.h presence... yes
> checking for mntent.h... yes
> checking whether fls is declared... no
> checking for readdir... yes
> checking whether fsetxattr is declared... no
> checking whether mremap is declared... yes
> checking for struct fsxattr... no
> checking for GETFSMAP... no
> checking for struct statfs... yes
> checking for struct statfs.f_flags... yes
> checking for MAP_SYNC... no
> checking for library containing dm_task_create... no
> checking for mallinfo ... yes
> checking attr/attributes.h usability... no
> checking attr/attributes.h presence... no
> checking for attr/attributes.h... no
> checking for struct attrlist_cursor... no
> ./configure: line 14661: syntax error near unexpected token `libicu,'
> ./configure: line 14661: ` PKG_CHECK_MODULES(libicu, icu-i18n, have_libicu=yes, have_libicu=no)'
> Makefile:115: recipe for target 'include/builddefs' failed
> make: *** [include/builddefs] Error 2
>
> % less -N configure
> ...
> 14660 if test "$enable_libicu" = "yes" || test "$enable_libicu" = "probe"; then
> 14661 PKG_CHECK_MODULES(libicu, icu-i18n, have_libicu=yes, have_libicu=no)
> 14662
> 14663
> 14664
> 14665
> 14666 fi
>
> Package versions:
>
> % dpkg -l|grep icu
> ii icu-devtools 52.1-8+deb8u7 amd64 Development utilities for International Components for Unicode
> ii libicu-dev:amd64 52.1-8+deb8u7 amd64 Development files for International Components for Unicode
> ii libicu52:amd64 52.1-8+deb8u7 amd64 International Components for Unicode
>
> % dpkg -l | grep -w m4
> ii m4 1.4.17-4 amd64 macro processing language
>
> % dpkg -l | grep libtool
> ii libltdl7:amd64 2.4.2-1.11+b1 amd64 System independent dlopen wrapper for GNU libtool
> ii libtool 2.4.2-1.11 all Generic library support script
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Staging: octeon: Apply Licence and resolves warnings according to TODO list. There are also a few "checks" that probably should revised but i think most of them could be resolved by breaking down cvmx_usb_poll_channel()
From: Greg KH @ 2018-07-24 5:30 UTC (permalink / raw)
To: Georgios Tsotsos; +Cc: devel, jhogan, linux-kernel, aaro.koskinen
In-Reply-To: <20180723222117.542-1-tsotsos@gmail.com>
On Tue, Jul 24, 2018 at 01:21:17AM +0300, Georgios Tsotsos wrote:
> Signed-off-by: Georgios Tsotsos <tsotsos@gmail.com>
> ---
> drivers/staging/octeon-usb/octeon-hcd.c | 55 ++++++++++++++++++---------------
> drivers/staging/octeon-usb/octeon-hcd.h | 1 +
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- Your patch did many different things all at once, making it difficult
to review. All Linux kernel patches need to only do one thing at a
time. If you need to do multiple things (such as clean up all coding
style issues in a file/driver), do it in a sequence of patches, each
one doing only one thing. This will make it easier to review the
patches to ensure that they are correct, and to help alleviate any
merge issues that larger patches can cause.
- You did not specify a description of why the patch is needed, or
possibly, any description at all, in the email body. Please read the
section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what is needed in order to
properly describe the change.
- You did not write a descriptive Subject: for the patch, allowing Greg,
and everyone else, to know what this patch is all about. Please read
the section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what a proper Subject: line should
look like.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* Re: [PATCH] doc: add tested NICs in i40e guide
From: Xing, Beilei @ 2018-07-24 5:26 UTC (permalink / raw)
To: Li, Xiaoyun, Mcnamara, John, Zhang, Qi Z; +Cc: dev@dpdk.org
In-Reply-To: <1532327644-21715-1-git-send-email-xiaoyun.li@intel.com>
> -----Original Message-----
> From: Li, Xiaoyun
> Sent: Monday, July 23, 2018 2:34 PM
> To: Mcnamara, John <john.mcnamara@intel.com>; Xing, Beilei
> <beilei.xing@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: dev@dpdk.org; Li, Xiaoyun <xiaoyun.li@intel.com>
> Subject: [PATCH] doc: add tested NICs in i40e guide
>
> Add suggested kernel driver and firmware version for i40e PMD.
>
> Signed-off-by: Xiaoyun Li <xiaoyun.li@intel.com>
> ---
> doc/guides/nics/i40e.rst | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index
> d5b02c9..d377d92 100644
> --- a/doc/guides/nics/i40e.rst
> +++ b/doc/guides/nics/i40e.rst
> @@ -58,6 +58,35 @@ Prerequisites
> - Upgrade the NVM/FW version following the `Intel® Ethernet NVM Update
> Tool Quick Usage Guide for Linux
> <https://www-
> ssl.intel.com/content/www/us/en/embedded/products/networking/nvm-
> update-tool-quick-linux-usage-guide.html>`_ and `Intel® Ethernet NVM
> Update Tool: Quick Usage Guide for EFI
> <https://www.intel.com/content/www/us/en/embedded/products/network
> ing/nvm-update-tool-quick-efi-usage-guide.html>`_ if needed.
>
> +Tested NICs
The guide is only for i40e, so we'd better change the title, how about recommended matching list?
Also the patch title also needs to be changed.
> +-----------
> +
> +It is highly recommended to upgrade the i40e kernel driver and firmware
> +to avoid the compatibility issues with i40e PMD. Here is the suggested
> +matching list which has been tested and verified.
> +
> + +--------------+-----------------------+------------------+
> + | DPDK version | Kernel driver version | Firmware version |
> + +==============+=======================+==================+
> + | 18.05 | 2.4.6 | 6.01 |
> + +--------------+-----------------------+------------------+
> + | 18.02 | 2.4.3 | 6.01 |
> + +--------------+-----------------------+------------------+
> + | 17.11 | 2.1.26 | 6.01 |
> + +--------------+-----------------------+------------------+
> + | 17.08 | 2.0.19 | 6.01 |
> + +--------------+-----------------------+------------------+
> + | 17.05 | 1.5.23 | 5.05 |
> + +--------------+-----------------------+------------------+
> + | 17.02 | 1.5.23 | 5.05 |
> + +--------------+-----------------------+------------------+
> + | 16.11 | 1.5.23 | 5.05 |
> + +--------------+-----------------------+------------------+
> + | 16.07 | 1.4.25 | 5.04 |
> + +--------------+-----------------------+------------------+
> + | 16.04 | 1.4.25 | 5.02 |
> + +--------------+-----------------------+------------------+
> +
> Pre-Installation Configuration
> ------------------------------
>
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH 5/7] x86/vdso: Add vDSO functions for direct store instructions
From: Andy Lutomirski @ 2018-07-24 5:27 UTC (permalink / raw)
To: Fenghua Yu
Cc: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, H Peter Anvin,
Ashok Raj, Alan Cox, Ravi V Shankar, linux-kernel, x86
In-Reply-To: <20180724034205.GA245659@romley-ivt3.sc.intel.com>
On Mon, Jul 23, 2018 at 8:42 PM, Fenghua Yu <fenghua.yu@intel.com> wrote:
> On Mon, Jul 23, 2018 at 06:48:00PM -0700, Andy Lutomirski wrote:
>> On 07/23/2018 05:55 AM, Fenghua Yu wrote:
>> >The instructions can be implemented in intrinsic functions in future
>> >GCC. But the vDSO interfaces are available to user without the
>> I'm not convinced that any of this belongs in the vDSO at all. You could
>> just add AT_HWCAP (or AT_HWCAP2) flags for the new instructions. Or user
>
> Thomas asked to use vDSO. Please see the discussion thread:
> https://lkml.org/lkml/2018/6/19/316
I think he meant that, if these helpers belong in the kernel at all,
then they belong in the vDSO. But I think they mostly don't belong in
the kernel.
>
>> code could use CPUID just like for any other new instruction. But, if there
>> really is some compelling reason to add this to the vDSO, then see below:
>> >+notrace bool __vdso_movdiri_supported(void)
>> >+{
>> >+ return _vdso_funcs_data->movdiri_supported;
>> return static_cpu_has(X86_FEATURE_MOVDIRI);
>
> But boot_cpu_data (used in static_cpu_has) cannot be accessed by user
> unless mapped in VVAR. So this change cannot be compiled.
The underlying alternative infrastructure works in the vDSO. You'd
need to introduce an alternate version of _static_cpu_has if
BUILD_VDSO that skips the boot_cpu_has fallback.
^ permalink raw reply
* [PATCH net-next] bnxt_en: Fix logic of forward the VF MAC address to PF in bnxt_vf_validate_set_mac
From: YueHaibing @ 2018-07-24 5:24 UTC (permalink / raw)
To: davem, michael.chan; +Cc: linux-kernel, netdev, YueHaibing
Based on the comments,req->l2addr must match the VF MAC address
if firmware spec >= 1.2.2, mac_ok can be true.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
index a649108..7925964 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -954,12 +954,9 @@ static int bnxt_vf_validate_set_mac(struct bnxt *bp, struct bnxt_vf_info *vf)
if (ether_addr_equal((const u8 *)req->l2_addr, vf->mac_addr))
mac_ok = true;
} else if (is_valid_ether_addr(vf->vf_mac_addr)) {
- if (ether_addr_equal((const u8 *)req->l2_addr, vf->vf_mac_addr))
+ if (ether_addr_equal((const u8 *)req->l2_addr, vf->vf_mac_addr) &&
+ bp->hwrm_spec_code >= 0x10202)
mac_ok = true;
- } else if (bp->hwrm_spec_code < 0x10202) {
- mac_ok = true;
- } else {
- mac_ok = true;
}
if (mac_ok)
return bnxt_hwrm_exec_fwd_resp(bp, vf, msg_size);
--
2.7.0
^ permalink raw reply related
* Re: [PATCH 3/4] net: lantiq: Add Lantiq / Intel vrx200 Ethernet driver
From: Hauke Mehrtens @ 2018-07-24 5:27 UTC (permalink / raw)
To: Paul Burton
Cc: davem, netdev, andrew, vivien.didelot, f.fainelli, john,
linux-mips, dev, hauke.mehrtens
In-Reply-To: <20180724003443.y2fcakalxmwwkqab@pburton-laptop>
Hi Paul,
On 07/24/2018 02:34 AM, Paul Burton wrote:
> Hi Hauke,
>
> On Sat, Jul 21, 2018 at 09:13:57PM +0200, Hauke Mehrtens wrote:
>> diff --git a/arch/mips/lantiq/xway/sysctrl.c b/arch/mips/lantiq/xway/sysctrl.c
>> index e0af39b33e28..c704312ef7d5 100644
>> --- a/arch/mips/lantiq/xway/sysctrl.c
>> +++ b/arch/mips/lantiq/xway/sysctrl.c
>> @@ -536,7 +536,7 @@ void __init ltq_soc_init(void)
>> clkdev_add_pmu(NULL, "ahb", 1, 0, PMU_AHBM | PMU_AHBS);
>>
>> clkdev_add_pmu("1da00000.usif", "NULL", 1, 0, PMU_USIF);
>> - clkdev_add_pmu("1e108000.eth", NULL, 0, 0,
>> + clkdev_add_pmu("1e10b308.eth", NULL, 0, 0,
>> PMU_SWITCH | PMU_PPE_DPLUS | PMU_PPE_DPLUM |
>> PMU_PPE_EMA | PMU_PPE_TC | PMU_PPE_SLL01 |
>> PMU_PPE_QSB | PMU_PPE_TOP);
>
> Is this intentional?
Yes
> Why is it needed? Was the old address wrong? Does it change anything
> functionally?
The Ethernet driver is newly added in these patches, this entry was not
used before.
This has to match the device name and the device name is now named
1e10b308.eth because this only uses the register range of the pmac and
not of the complete switch core, this is different to the old driver
used in OpenWrt.
The lantiq clock code should really be converted to the common clock
framework so we can define this in device tree and do not need this code
any more.
I am planning to do this, but want to wait till the xrx500 clk code from
these patches is in mainline:
https://www.linux-mips.org/archives/linux-mips/2018-06/msg00092.html
There are already some more recent versions available internally.
> If it is needed it seems like a separate change - unless there's some
> reason it's tied to adding this driver?
>
> Should this really apply only to the lantiq,vr9 case or also to the
> similar lantiq,grx390 & lantiq,ar10 paths?
The AR10 has a similar switch core, but I haven't tested this device
with this Ethernet driver, but there is a good chance it works out of
the box when the sysctrl.c gets adapted and the correct device tree is
provided.
I do not know exactly what the grx390 SoC is, this is probably some
uncommon name for one of the Lantiq / Intel SoCs, I have to look this up.
>
> Whatever the answers to these questions it would be good to include them
> in the commit message.
I will update the commit massage for the v2.
Hauke
^ permalink raw reply
* [PATCH 5/5] fsi: Prevent multiple concurrent rescans
From: Benjamin Herrenschmidt @ 2018-07-24 5:05 UTC (permalink / raw)
To: openbmc
Cc: Joel Stanley, linux-aspeed, Andrew Jeffery, Eddie James,
Linux Kernel Mailing List, Benjamin Herrenschmidt
In-Reply-To: <20180724050519.31920-1-benh@kernel.crashing.org>
The bus scanning process isn't terribly good at parallel attempts
at rescanning the same bus. Let's have a per-master mutex protecting
the scanning process.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/fsi/fsi-core.c | 16 ++++++++++++++--
drivers/fsi/fsi-master.h | 2 ++
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index dea5bd48acc5..2c31563fdcae 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -1203,8 +1203,14 @@ static void fsi_master_unscan(struct fsi_master *master)
int fsi_master_rescan(struct fsi_master *master)
{
+ int rc;
+
+ mutex_lock(&master->scan_lock);
fsi_master_unscan(master);
- return fsi_master_scan(master);
+ rc = fsi_master_scan(master);
+ mutex_unlock(&master->scan_lock);
+
+ return rc;
}
EXPORT_SYMBOL_GPL(fsi_master_rescan);
@@ -1240,6 +1246,7 @@ int fsi_master_register(struct fsi_master *master)
int rc;
struct device_node *np;
+ mutex_init(&master->scan_lock);
master->idx = ida_simple_get(&master_ida, 0, INT_MAX, GFP_KERNEL);
dev_set_name(&master->dev, "fsi%d", master->idx);
@@ -1264,8 +1271,11 @@ int fsi_master_register(struct fsi_master *master)
}
np = dev_of_node(&master->dev);
- if (!of_property_read_bool(np, "no-scan-on-init"))
+ if (!of_property_read_bool(np, "no-scan-on-init")) {
+ mutex_lock(&master->scan_lock);
fsi_master_scan(master);
+ mutex_unlock(&master->scan_lock);
+ }
return 0;
}
@@ -1278,7 +1288,9 @@ void fsi_master_unregister(struct fsi_master *master)
master->idx = -1;
}
+ mutex_lock(&master->scan_lock);
fsi_master_unscan(master);
+ mutex_unlock(&master->scan_lock);
device_unregister(&master->dev);
}
EXPORT_SYMBOL_GPL(fsi_master_unregister);
diff --git a/drivers/fsi/fsi-master.h b/drivers/fsi/fsi-master.h
index f653f75da7be..040a7d4cf717 100644
--- a/drivers/fsi/fsi-master.h
+++ b/drivers/fsi/fsi-master.h
@@ -18,6 +18,7 @@
#define DRIVERS_FSI_MASTER_H
#include <linux/device.h>
+#include <linux/mutex.h>
/* Various protocol delays */
#define FSI_ECHO_DELAY_CLOCKS 16 /* Number clocks for echo delay */
@@ -59,6 +60,7 @@ struct fsi_master {
int idx;
int n_links;
int flags;
+ struct mutex scan_lock;
int (*read)(struct fsi_master *, int link, uint8_t id,
uint32_t addr, void *val, size_t size);
int (*write)(struct fsi_master *, int link, uint8_t id,
--
2.17.1
^ permalink raw reply related
* xfsprogs-dev failing to build
From: Vincent McIntyre @ 2018-07-24 4:09 UTC (permalink / raw)
To: linux-xfs
Hi
I am trying to build the latest xfsprogs on an older system,
details below. The configure script is failing on what appears
to be an unexpanded m4 macro,
PKG_CHECK_MODULES(libicu, icu-i18n, have_libicu=yes, have_libicu=no)
I'm not quite sure how to work around this or if it is a bug.
Any advice would be appreciated.
Kind regards
Vince
System details:
% cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
% git remote -v
origin git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git (fetch)
origin git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git (push)
% git log -1
commit 0821de47b419e6a2ed0e8a2c64fd26a93c398093
Author: Eric Sandeen <sandeen@redhat.com>
Date: Fri Jun 29 02:52:21 2018
xfsprogs: Release v4.17.0
Update all the necessary files for a 4.17.0 release.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Problem demonstration:
% make
libtoolize -c `libtoolize -n -i >/dev/null 2>/dev/null && echo -i` -f
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.
libtoolize: copying file `./config.guess'
libtoolize: copying file `./config.sub'
libtoolize: copying file `./install-sh'
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
cp include/install-sh .
aclocal -I m4
configure.ac:191: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
m4/package_services.m4:4: AC_CONFIG_SYSTEMD_SYSTEM_UNIT_DIR is expanded from...
configure.ac:191: the top level
configure.ac:191: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
m4/package_services.m4:4: AC_CONFIG_SYSTEMD_SYSTEM_UNIT_DIR is expanded from...
configure.ac:191: the top level
autoconf
configure.ac:191: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
m4/package_services.m4:4: AC_CONFIG_SYSTEMD_SYSTEM_UNIT_DIR is expanded from...
configure.ac:191: the top level
./configure $LOCAL_CONFIGURE_OPTIONS
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking for gawk... gawk
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking for gmake... no
checking for make... /usr/bin/make
checking for tar... /bin/tar
checking for gzip... /bin/gzip
checking whether gcc -MM is supported... yes
checking for sort... /usr/bin/sort
checking whether ln -s works... yes
checking for msgfmt... /usr/bin/msgfmt
checking for msgmerge... /usr/bin/msgmerge
checking for xgettext... /usr/bin/xgettext
checking for rpm... no
checking uuid.h usability... no
checking uuid.h presence... no
checking for uuid.h... no
checking sys/uuid.h usability... no
checking sys/uuid.h presence... no
checking for sys/uuid.h... no
checking uuid/uuid.h usability... yes
checking uuid/uuid.h presence... yes
checking for uuid/uuid.h... yes
checking for uuid_compare... no
checking for uuid_compare in -luuid... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_mutex_init in -lpthread... yes
checking for fadvise ... yes
checking for madvise ... yes
checking for mincore ... yes
checking for sendfile ... yes
checking for getmntent ... yes
checking for getmntinfo ... no
checking for fallocate... yes
checking for fiemap... yes
checking for pwritev2... no
checking for preadv... yes
checking for copy_file_range... no
checking for sync_file_range... yes
checking for syncfs... yes
checking mntent.h usability... yes
checking mntent.h presence... yes
checking for mntent.h... yes
checking whether fls is declared... no
checking for readdir... yes
checking whether fsetxattr is declared... no
checking whether mremap is declared... yes
checking for struct fsxattr... no
checking for GETFSMAP... no
checking for struct statfs... yes
checking for struct statfs.f_flags... yes
checking for MAP_SYNC... no
checking for library containing dm_task_create... no
checking for mallinfo ... yes
checking attr/attributes.h usability... no
checking attr/attributes.h presence... no
checking for attr/attributes.h... no
checking for struct attrlist_cursor... no
./configure: line 14661: syntax error near unexpected token `libicu,'
./configure: line 14661: ` PKG_CHECK_MODULES(libicu, icu-i18n, have_libicu=yes, have_libicu=no)'
Makefile:115: recipe for target 'include/builddefs' failed
make: *** [include/builddefs] Error 2
% less -N configure
...
14660 if test "$enable_libicu" = "yes" || test "$enable_libicu" = "probe"; then
14661 PKG_CHECK_MODULES(libicu, icu-i18n, have_libicu=yes, have_libicu=no)
14662
14663
14664
14665
14666 fi
Package versions:
% dpkg -l|grep icu
ii icu-devtools 52.1-8+deb8u7 amd64 Development utilities for International Components for Unicode
ii libicu-dev:amd64 52.1-8+deb8u7 amd64 Development files for International Components for Unicode
ii libicu52:amd64 52.1-8+deb8u7 amd64 International Components for Unicode
% dpkg -l | grep -w m4
ii m4 1.4.17-4 amd64 macro processing language
% dpkg -l | grep libtool
ii libltdl7:amd64 2.4.2-1.11+b1 amd64 System independent dlopen wrapper for GNU libtool
ii libtool 2.4.2-1.11 all Generic library support script
^ permalink raw reply
* Re: [RFC PATCH v1] media: uvcvideo: Cache URB header data before processing
From: Keiichi Watanabe @ 2018-07-24 4:18 UTC (permalink / raw)
To: kieran.bingham
Cc: Linux Kernel Mailing List, Laurent Pinchart,
Mauro Carvalho Chehab, Linux Media Mailing List, Tomasz Figa,
Douglas Anderson
In-Reply-To: <344dca0a-bdb1-7b4d-37d4-e6ebca05bf4f@ideasonboard.com>
Hi Kieran,
How is it going?
I would appreciate if you could review this patch.
Best regards,
Keiichi
On Thu, Jun 28, 2018 at 2:21 AM, Kieran Bingham
<kieran.bingham@ideasonboard.com> wrote:
> Hi Keiichi,
>
> I just wanted to reply here quickly to say this is a really interesting
> development.
>
> I would like to review and test it properly; however I am now on holiday
> until at least the 9th July and so I won't be able to look until after
> that date.
>
> I didn't want you to be left hanging though :-)
>
> Ping me if you haven't heard anything by the 20th or so. Of course if
> anyone else gets round to testing and reviewing then that's great too.
>
> Regards
> --
> Kieran
>
>
>
> On 27/06/18 11:34, Keiichi Watanabe wrote:
>> On some platforms with non-coherent DMA (e.g. ARM), USB drivers use
>> uncached memory allocation methods. In such situations, it sometimes
>> takes a long time to access URB buffers. This can be a cause of video
>> flickering problems if a resolution is high and a USB controller has
>> a very tight time limit. (e.g. dwc2) To avoid this problem, we copy
>> header data from (uncached) URB buffer into (cached) local buffer.
>>
>> This change should make the elapsed time of the interrupt handler
>> shorter on platforms with non-coherent DMA. We measured the elapsed
>> time of each callback of uvc_video_complete without/with this patch
>> while capturing Full HD video in
>> https://webrtc.github.io/samples/src/content/getusermedia/resolution/.
>> I tested it on the top of Kieran Bingham's Asynchronous UVC series
>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg128359.html.
>> The test device was Jerry Chromebook (RK3288) with Logitech Brio 4K.
>> I collected data for 5 seconds. (There were around 480 callbacks in
>> this case.) The following result shows that this patch makes
>> uvc_video_complete about 2x faster.
>>
>> | average | median | min | max | standard deviation
>> w/o caching| 45319ns | 40250ns | 33834ns | 142625ns| 16611ns
>> w/ caching| 20620ns | 19250ns | 12250ns | 56583ns | 6285ns
>>
>> In addition, we confirmed that this patch doesn't make it worse on
>> coherent DMA architecture by performing the same measurements on a
>> Broadwell Chromebox with the same camera.
>>
>> | average | median | min | max | standard deviation
>> w/o caching| 21026ns | 21424ns | 12263ns | 23956ns | 1932ns
>> w/ caching| 20728ns | 20398ns | 8922ns | 45120ns | 3368ns
>>
>> Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
>> ---
>>
>> After applying 6 patches in
>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg128359.html,
>> I measured elapsed time by adding the following code to
>> /drivers/media/usb/uvc/uvc_video.c
>>
>> @@ -XXXX,6 +XXXX,9 @@ static void uvc_video_complete(struct urb *urb)
>> struct uvc_video_queue *queue = &stream->queue;
>> struct uvc_buffer *buf = NULL;
>> int ret;
>> + ktime_t start, end;
>> + int elapsed_time;
>> + start = ktime_get();
>> switch (urb->status) {
>> case 0:
>>
>> @@ -XXXX,6 +XXXX,10 @@ static void uvc_video_complete(struct urb *urb)
>>
>> INIT_WORK(&uvc_urb->work, uvc_video_copy_data_work);
>> queue_work(stream->async_wq, &uvc_urb->work);
>> +
>> + end = ktime_get();
>> + elapsed_time = ktime_to_ns(ktime_sub(end, start));
>> + pr_err("elapsed time: %d ns", elapsed_time);
>> }
>>
>> /*
>>
>>
>> drivers/media/usb/uvc/uvc_video.c | 92 +++++++++++++++----------------
>> 1 file changed, 43 insertions(+), 49 deletions(-)
>> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
>> index a88b2e51a666..ff2eddc55530 100644
>> --- a/drivers/media/usb/uvc/uvc_video.c
>> +++ b/drivers/media/usb/uvc/uvc_video.c
>> @@ -391,36 +391,15 @@ static inline ktime_t uvc_video_get_time(void)
>>
>> static void
>> uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
>> - const u8 *data, int len)
>> + const u8 *data, int len, unsigned int header_size,
>> + bool has_pts, bool has_scr)
>> {
>> struct uvc_clock_sample *sample;
>> - unsigned int header_size;
>> - bool has_pts = false;
>> - bool has_scr = false;
>> unsigned long flags;
>> ktime_t time;
>> u16 host_sof;
>> u16 dev_sof;
>>
>> - switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
>> - case UVC_STREAM_PTS | UVC_STREAM_SCR:
>> - header_size = 12;
>> - has_pts = true;
>> - has_scr = true;
>> - break;
>> - case UVC_STREAM_PTS:
>> - header_size = 6;
>> - has_pts = true;
>> - break;
>> - case UVC_STREAM_SCR:
>> - header_size = 8;
>> - has_scr = true;
>> - break;
>> - default:
>> - header_size = 2;
>> - break;
>> - }
>> -
>> /* Check for invalid headers. */
>> if (len < header_size)
>> return;
>> @@ -717,11 +696,10 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
>> */
>>
>> static void uvc_video_stats_decode(struct uvc_streaming *stream,
>> - const u8 *data, int len)
>> + const u8 *data, int len,
>> + unsigned int header_size, bool has_pts,
>> + bool has_scr)
>> {
>> - unsigned int header_size;
>> - bool has_pts = false;
>> - bool has_scr = false;
>> u16 uninitialized_var(scr_sof);
>> u32 uninitialized_var(scr_stc);
>> u32 uninitialized_var(pts);
>> @@ -730,25 +708,6 @@ static void uvc_video_stats_decode(struct uvc_streaming *stream,
>> stream->stats.frame.nb_packets == 0)
>> stream->stats.stream.start_ts = ktime_get();
>>
>> - switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
>> - case UVC_STREAM_PTS | UVC_STREAM_SCR:
>> - header_size = 12;
>> - has_pts = true;
>> - has_scr = true;
>> - break;
>> - case UVC_STREAM_PTS:
>> - header_size = 6;
>> - has_pts = true;
>> - break;
>> - case UVC_STREAM_SCR:
>> - header_size = 8;
>> - has_scr = true;
>> - break;
>> - default:
>> - header_size = 2;
>> - break;
>> - }
>> -
>> /* Check for invalid headers. */
>> if (len < header_size || data[0] < header_size) {
>> stream->stats.frame.nb_invalid++;
>> @@ -957,10 +916,41 @@ static void uvc_video_stats_stop(struct uvc_streaming *stream)
>> * to be called with a NULL buf parameter. uvc_video_decode_data and
>> * uvc_video_decode_end will never be called with a NULL buffer.
>> */
>> +static void uvc_video_decode_header_size(const u8 *data, int *header_size,
>> + bool *has_pts, bool *has_scr)
>> +{
>> + switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
>> + case UVC_STREAM_PTS | UVC_STREAM_SCR:
>> + *header_size = 12;
>> + *has_pts = true;
>> + *has_scr = true;
>> + break;
>> + case UVC_STREAM_PTS:
>> + *header_size = 6;
>> + *has_pts = true;
>> + break;
>> + case UVC_STREAM_SCR:
>> + *header_size = 8;
>> + *has_scr = true;
>> + break;
>> + default:
>> + *header_size = 2;
>> + }
>> +}
>> +
>> static int uvc_video_decode_start(struct uvc_streaming *stream,
>> - struct uvc_buffer *buf, const u8 *data, int len)
>> + struct uvc_buffer *buf, const u8 *urb_data,
>> + int len)
>> {
>> u8 fid;
>> + u8 data[12];
>> + unsigned int header_size;
>> + bool has_pts = false, has_scr = false;
>> +
>> + /* Cache the header since urb_data is uncached memory. The size of
>> + * header is at most 12 bytes.
>> + */
>> + memcpy(data, urb_data, min(len, 12));
>>
>> /* Sanity checks:
>> * - packet must be at least 2 bytes long
>> @@ -983,8 +973,12 @@ static int uvc_video_decode_start(struct uvc_streaming *stream,
>> uvc_video_stats_update(stream);
>> }
>>
>> - uvc_video_clock_decode(stream, buf, data, len);
>> - uvc_video_stats_decode(stream, data, len);
>> + uvc_video_decode_header_size(data, &header_size, &has_pts, &has_scr);
>> +
>> + uvc_video_clock_decode(stream, buf, data, len, header_size, has_pts,
>> + has_scr);
>> + uvc_video_stats_decode(stream, data, len, header_size, has_pts,
>> + has_scr);
>>
>> /* Store the payload FID bit and return immediately when the buffer is
>> * NULL.
>> --
>> 2.18.0.rc2.346.g013aa6912e-goog
>>
>
> --
> Regards
> --
> Kieran
^ permalink raw reply
* Re: Incorrect name of PCM
From: Takashi Iwai @ 2018-07-24 5:22 UTC (permalink / raw)
To: Christopher Head; +Cc: alsa-devel
In-Reply-To: <20180723201722.2f96a07c@amdahl.home.chead.ca>
On Tue, 24 Jul 2018 05:17:22 +0200,
Christopher Head wrote:
>
> On Mon, 23 Jul 2018 19:40:36 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
>
> > OK, then another possibility is a BIOS bug. BIOS declares the pin as
> > HDMI incorrectly although it's a SPDIF.
>
> That would appear to be the case. According to the VT1708S datasheet,
> the typical application is for digital output widget node 0x12,
> attached to pin complex node 0x20, to be used for S/PDIF, and digital
> output widget node 0x15, attached to pin complex node 0x21, to be used
> for HDMI. The datasheet’s default values for the Configuration Default
> words for the two pin complex nodes agree with that configuration. This
> also appears to be how my motherboard is configured.
>
> However, I have attached /proc/asound/card0/codec#0; this file states
> that node 0x20 is HDMI and 0x21 is S/PDIF, and having decoded the raw
> words based on the Intel HDA specification revision 1.0a, I agree that
> the kernel is decoding them correctly. I assume the kernel driver
> doesn’t change these words, which means the information I’m seeing
> there, since it’s not the codec default, must have been put there by
> the BIOS, apparently erroneously.
>
> Is this something that the ALSA project wants to (or even can) add a
> quirk for? I am already running the most recent BIOS available.
You just need to disable the unused HDMI pin by setting the pin config
value, even without recompiling drivers. It can be overridden by
"patch" file, as mentioned in Documentation/sound/hd-audio/notes.rst.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH v5 net-next 0/3] rds: IPv6 support
From: David Miller @ 2018-07-24 4:18 UTC (permalink / raw)
To: ka-cheong.poon; +Cc: netdev, santosh.shilimkar, rds-devel, sowmini.varadhan
In-Reply-To: <cover.1532404047.git.ka-cheong.poon@oracle.com>
From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date: Mon, 23 Jul 2018 20:51:20 -0700
> This patch set adds IPv6 support to the kernel RDS and related
> modules.
Series applied.
^ permalink raw reply
* Re: [PATCH] xfsprogs: remove generated scrub files under clean target
From: Darrick J. Wong @ 2018-07-24 4:17 UTC (permalink / raw)
To: Eric Sandeen; +Cc: linux-xfs
In-Reply-To: <eed34d4b-7ec9-aedb-fbb3-1c887d375001@redhat.com>
On Mon, Jul 23, 2018 at 09:06:33PM -0700, Eric Sandeen wrote:
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Looks ok,
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
--D
> ---
>
> diff --git a/scrub/Makefile b/scrub/Makefile
> index d9ab148..acebecc 100644
> --- a/scrub/Makefile
> +++ b/scrub/Makefile
> @@ -97,6 +97,8 @@ ifeq ($(HAVE_HDIO_GETGEO),yes)
> LCFLAGS += -DHAVE_HDIO_GETGEO
> endif
>
> +LDIRT = $(XFS_SCRUB_ALL_PROG) *.service *.cron
> +
> default: depend $(LTCOMMAND) $(XFS_SCRUB_ALL_PROG) $(OPTIONAL_TARGETS)
>
> xfs_scrub_all: xfs_scrub_all.in
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 net-next 3/3] rds: Extend RDS API for IPv6 support
From: santosh.shilimkar @ 2018-07-24 4:16 UTC (permalink / raw)
To: Ka-Cheong Poon, netdev; +Cc: davem, rds-devel, sowmini.varadhan
In-Reply-To: <cbb2d34e7b627f8a89f3d774aee585c6945e048f.1532404047.git.ka-cheong.poon@oracle.com>
On 7/23/18 8:51 PM, Ka-Cheong Poon wrote:
> There are many data structures (RDS socket options) used by RDS apps
> which use a 32 bit integer to store IP address. To support IPv6,
> struct in6_addr needs to be used. To ensure backward compatibility, a
> new data structure is introduced for each of those data structures
> which use a 32 bit integer to represent an IP address. And new socket
> options are introduced to use those new structures. This means that
> existing apps should work without a problem with the new RDS module.
> For apps which want to use IPv6, those new data structures and socket
> options can be used. IPv4 mapped address is used to represent IPv4
> address in the new data structures.
>
> v4: Revert changes to SO_RDS_TRANSPORT
>
> Signed-off-by: Ka-Cheong Poon<ka-cheong.poon@oracle.com>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.