* [PATCH 0/3] Trivial kernel-doc fixes
From: Takashi Iwai @ 2016-11-14 21:30 UTC (permalink / raw)
To: alsa-devel
Hi,
this is a short series of patches to fix trivial kernel-doc warnings
and errors.
Takashi
===
Takashi Iwai (3):
ALSA: ac97: Fix kernel-doc error with sphinx formatter
ALSA: compress: Fix kernel-doc warnings
ALSA: core: Fix kernel-doc warnings
include/sound/compress_driver.h | 1 +
include/sound/core.h | 20 ++++++++++----------
sound/pci/ac97/ac97_codec.c | 2 +-
3 files changed, 12 insertions(+), 11 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH 3/3] ALSA: core: Fix kernel-doc warnings
From: Takashi Iwai @ 2016-11-14 21:30 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <20161114213005.22443-1-tiwai@suse.de>
Several lines in sound/core.h get the kernel-doc warnings like
./include/sound/core.h:323: warning: No description found for parameter '...'
where we use define like foo(x, args...) and "args" isn't mentioned in
the comments. As an easy workaround, use simple __VA_ARGS__ for VLA
in macros.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
include/sound/core.h | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/sound/core.h b/include/sound/core.h
index 31079ea5e484..f7d8c10c4c45 100644
--- a/include/sound/core.h
+++ b/include/sound/core.h
@@ -308,8 +308,8 @@ __printf(4, 5)
void __snd_printk(unsigned int level, const char *file, int line,
const char *format, ...);
#else
-#define __snd_printk(level, file, line, format, args...) \
- printk(format, ##args)
+#define __snd_printk(level, file, line, format, ...) \
+ printk(format, ##__VA_ARGS__)
#endif
/**
@@ -319,8 +319,8 @@ void __snd_printk(unsigned int level, const char *file, int line,
* Works like printk() but prints the file and the line of the caller
* when configured with CONFIG_SND_VERBOSE_PRINTK.
*/
-#define snd_printk(fmt, args...) \
- __snd_printk(0, __FILE__, __LINE__, fmt, ##args)
+#define snd_printk(fmt, ...) \
+ __snd_printk(0, __FILE__, __LINE__, fmt, ##__VA_ARGS__)
#ifdef CONFIG_SND_DEBUG
/**
@@ -330,10 +330,10 @@ void __snd_printk(unsigned int level, const char *file, int line,
* Works like snd_printk() for debugging purposes.
* Ignored when CONFIG_SND_DEBUG is not set.
*/
-#define snd_printd(fmt, args...) \
- __snd_printk(1, __FILE__, __LINE__, fmt, ##args)
-#define _snd_printd(level, fmt, args...) \
- __snd_printk(level, __FILE__, __LINE__, fmt, ##args)
+#define snd_printd(fmt, ...) \
+ __snd_printk(1, __FILE__, __LINE__, fmt, ##__VA_ARGS__)
+#define _snd_printd(level, fmt, ...) \
+ __snd_printk(level, __FILE__, __LINE__, fmt, ##__VA_ARGS__)
/**
* snd_BUG - give a BUG warning message and stack trace
@@ -383,8 +383,8 @@ static inline bool snd_printd_ratelimit(void) { return false; }
* Works like snd_printk() for debugging purposes.
* Ignored when CONFIG_SND_DEBUG_VERBOSE is not set.
*/
-#define snd_printdd(format, args...) \
- __snd_printk(2, __FILE__, __LINE__, format, ##args)
+#define snd_printdd(format, ...) \
+ __snd_printk(2, __FILE__, __LINE__, format, ##__VA_ARGS__)
#else
__printf(1, 2)
static inline void snd_printdd(const char *format, ...) {}
--
2.10.2
^ permalink raw reply related
* [PATCH 1/3] ALSA: ac97: Fix kernel-doc error with sphinx formatter
From: Takashi Iwai @ 2016-11-14 21:30 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <20161114213005.22443-1-tiwai@suse.de>
Sphinx takes a word like (*foo)->bar in the kernel-doc comments as a
part of the emphasized marker, and complains like
./sound/pci/ac97/ac97_codec.c:1908: WARNING: Inline emphasis start-string without end-string.
For avoiding this, wrap it with the quotes (``) in the comment.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
sound/pci/ac97/ac97_codec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/ac97/ac97_codec.c b/sound/pci/ac97/ac97_codec.c
index 82259ca61e64..1ef7cdf1d3e8 100644
--- a/sound/pci/ac97/ac97_codec.c
+++ b/sound/pci/ac97/ac97_codec.c
@@ -1907,7 +1907,7 @@ static int ac97_reset_wait(struct snd_ac97 *ac97, int timeout, int with_modem)
* write). The other callbacks, wait and reset, are not mandatory.
*
* The clock is set to 48000. If another clock is needed, set
- * (*rbus)->clock manually.
+ * ``(*rbus)->clock`` manually.
*
* The AC97 bus instance is registered as a low-level device, so you don't
* have to release it manually.
--
2.10.2
^ permalink raw reply related
* [PATCH 2/3] ALSA: compress: Fix kernel-doc warnings
From: Takashi Iwai @ 2016-11-14 21:30 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <20161114213005.22443-1-tiwai@suse.de>
Some fields in struct snd_compr have no corresponding comments, and
the kernel-doc complains like:
./include/sound/compress_driver.h:162: warning: No description found for parameter 'id[64]'
./include/sound/compress_driver.h:162: warning: No description found for parameter 'proc_root'
./include/sound/compress_driver.h:162: warning: No description found for parameter 'proc_info_entry'
Actually all these are internal elements, just put "private:" comment
so that they will be ignored.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
include/sound/compress_driver.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/sound/compress_driver.h b/include/sound/compress_driver.h
index cee8c00f3d3e..9924bc9cbc7c 100644
--- a/include/sound/compress_driver.h
+++ b/include/sound/compress_driver.h
@@ -155,6 +155,7 @@ struct snd_compr {
struct mutex lock;
int device;
#ifdef CONFIG_SND_VERBOSE_PROCFS
+ /* private: */
char id[64];
struct snd_info_entry *proc_root;
struct snd_info_entry *proc_info_entry;
--
2.10.2
^ permalink raw reply related
* [ovmf test] 102236: all pass - PUSHED
From: osstest service owner @ 2016-11-14 21:29 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 102236 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102236/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a5991c8832c5301ec969c37cce5c1b332c7e0127
baseline version:
ovmf 653bde546200af46573cdfac88257f03b3420d88
Last test of basis 102229 2016-11-14 16:18:43 Z 0 days
Testing same since 102236 2016-11-14 19:27:09 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Giri P Mudusuru <giri.p.mudusuru@intel.com>
Michael Kinney <michael.d.kinney@intel.com>
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=a5991c8832c5301ec969c37cce5c1b332c7e0127
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf a5991c8832c5301ec969c37cce5c1b332c7e0127
+ branch=ovmf
+ revision=a5991c8832c5301ec969c37cce5c1b332c7e0127
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xa5991c8832c5301ec969c37cce5c1b332c7e0127 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osstest@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osstest@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/qemu-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
++ : daily-cron.ovmf
++ : git://xenbits.xen.org/qemu-xen.git
++ : git://git.qemu.org/qemu.git
+ TREE_LINUX=osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
+ TREE_XEN=osstest@xenbits.xen.org:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xen.org:/home/xen/git/libvirt.git
+ TREE_RUMPRUN=osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
+ TREE_SEABIOS=osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
+ TREE_OVMF=osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
+ TREE_XTF=osstest@xenbits.xen.org:/home/xen/git/xtf.git
+ info_linux_tree ovmf
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /home/osstest/repos/ovmf
+ git push osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git a5991c8832c5301ec969c37cce5c1b332c7e0127:refs/heads/xen-tested-master
To osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
653bde5..a5991c8 a5991c8832c5301ec969c37cce5c1b332c7e0127 -> xen-tested-master
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH 4/4] libselinux,libsemanage: link Python wrapper with Python
From: Nicolas Iooss @ 2016-11-14 21:28 UTC (permalink / raw)
To: selinux
In-Reply-To: <20161114212817.15781-1-nicolas.iooss@m4x.org>
When linking with -Wl,-no-undefined in LDFLAGS (in order to find
possible link-time errors), the Python wrapper module needs to be
linked with the right libpython.so. This library is found using
pkg-config in a new PYLIBS variable.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
---
libselinux/src/Makefile | 5 +++--
libsemanage/src/Makefile | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 82a1010af2d8..928cc049cedb 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -13,6 +13,7 @@ LIBDIR ?= $(PREFIX)/lib
SHLIBDIR ?= $(DESTDIR)/lib
INCLUDEDIR ?= $(PREFIX)/include
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
+PYLIBS ?= $(shell $(PKG_CONFIG) --libs $(PYPREFIX))
PYSITEDIR ?= $(DESTDIR)$(shell $(PYTHON) -c 'import site; print(site.getsitepackages()[0])')
RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -lruby"')
@@ -131,7 +132,7 @@ $(SWIGRUBYLOBJ): $(SWIGRUBYCOUT)
$(CC) $(CFLAGS) $(SWIG_CFLAGS) $(RUBYINC) -fPIC -DSHARED -c -o $@ $<
$(SWIGSO): $(SWIGLOBJ)
- $(CC) $(CFLAGS) -shared -o $@ $< -L. -lselinux $(LDFLAGS) -L$(LIBDIR)
+ $(CC) $(CFLAGS) -shared -o $@ $< -L. -lselinux $(LDFLAGS) $(PYLIBS) -L$(LIBDIR)
$(SWIGRUBYSO): $(SWIGRUBYLOBJ)
$(CC) $(CFLAGS) -shared -o $@ $^ -L. -lselinux $(LDFLAGS) $(RUBYLIBS) -L$(LIBDIR)
@@ -154,7 +155,7 @@ $(AUDIT2WHYLOBJ): audit2why.c
$(CC) $(filter-out -Werror, $(CFLAGS)) $(PYINC) -fPIC -DSHARED -c -o $@ $<
$(AUDIT2WHYSO): $(AUDIT2WHYLOBJ)
- $(CC) $(CFLAGS) -shared -o $@ $^ -L. $(LDFLAGS) -lselinux $(LIBSEPOLA) -L$(LIBDIR)
+ $(CC) $(CFLAGS) -shared -o $@ $^ -L. $(LDFLAGS) -lselinux $(LIBSEPOLA) $(PYLIBS) -L$(LIBDIR)
%.o: %.c policy.h
$(CC) $(CFLAGS) $(TLSFLAGS) -c -o $@ $<
diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
index 5c7bc6c6ea65..5176582f654d 100644
--- a/libsemanage/src/Makefile
+++ b/libsemanage/src/Makefile
@@ -13,6 +13,7 @@ LIBDIR ?= $(PREFIX)/lib
SHLIBDIR ?= $(DESTDIR)/lib
INCLUDEDIR ?= $(PREFIX)/include
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
+PYLIBS ?= $(shell $(PKG_CONFIG) --libs $(PYPREFIX))
PYSITEDIR ?= $(DESTDIR)$(shell $(PYTHON) -c 'import site; print(site.getsitepackages()[0])')
RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -lruby"')
@@ -79,7 +80,7 @@ $(SWIGRUBYLOBJ): $(SWIGRUBYCOUT)
$(CC) $(CFLAGS) $(SWIG_CFLAGS) $(RUBYINC) -fPIC -DSHARED -c -o $@ $<
$(SWIGSO): $(SWIGLOBJ)
- $(CC) $(CFLAGS) $(LDFLAGS) -shared -o $@ $< -L. -lsemanage -L$(LIBDIR)
+ $(CC) $(CFLAGS) $(LDFLAGS) -shared -o $@ $< -L. -lsemanage $(PYLIBS) -L$(LIBDIR)
$(SWIGRUBYSO): $(SWIGRUBYLOBJ)
$(CC) $(CFLAGS) $(LDFLAGS) -shared -o $@ $^ -L. -lsemanage $(RUBYLIBS) -L$(LIBDIR)
--
2.10.2
^ permalink raw reply related
* [PATCH 3/4] libsemanage: query for python site-packages dir directly
From: Nicolas Iooss @ 2016-11-14 21:28 UTC (permalink / raw)
To: selinux
In-Reply-To: <20161114212817.15781-1-nicolas.iooss@m4x.org>
Use the python interpreter to find the install directory, like commit
8162f10e670d ("libselinux: query for python site-packages dir directly")
did for libselinux.
While at it, do not install semanage.py (generated by SWIG) with
executable permission bits.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
---
libsemanage/src/Makefile | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
index 37d6eabbdae8..5c7bc6c6ea65 100644
--- a/libsemanage/src/Makefile
+++ b/libsemanage/src/Makefile
@@ -12,9 +12,8 @@ PREFIX ?= $(DESTDIR)/usr
LIBDIR ?= $(PREFIX)/lib
SHLIBDIR ?= $(DESTDIR)/lib
INCLUDEDIR ?= $(PREFIX)/include
-PYLIBVER ?= $(shell $(PYTHON) -c 'import sys;print("python%d.%d" % sys.version_info[0:2])')
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
-PYLIBDIR ?= $(LIBDIR)/$(PYLIBVER)
+PYSITEDIR ?= $(DESTDIR)$(shell $(PYTHON) -c 'import site; print(site.getsitepackages()[0])')
RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -lruby"')
RUBYINSTALL ?= $(DESTDIR)$(shell $(RUBY) -e 'puts RbConfig::CONFIG["vendorarchdir"]')
@@ -144,9 +143,9 @@ install: all
cd $(LIBDIR) && ln -sf $(LIBSO) $(TARGET)
install-pywrap: pywrap
- test -d $(PYLIBDIR)/site-packages || install -m 755 -d $(PYLIBDIR)/site-packages
- install -m 755 $(SWIGSO) $(PYLIBDIR)/site-packages/_semanage.so
- install -m 755 semanage.py $(PYLIBDIR)/site-packages
+ test -d $(PYSITEDIR) || install -m 755 -d $(PYSITEDIR)
+ install -m 755 $(SWIGSO) $(PYSITEDIR)/_semanage.so
+ install -m 644 semanage.py $(PYSITEDIR)
install-rubywrap: rubywrap
--
2.10.2
^ permalink raw reply related
* [PATCH 2/4] libselinux,libsemanage: link Ruby wrapper with -lruby
From: Nicolas Iooss @ 2016-11-14 21:28 UTC (permalink / raw)
To: selinux
In-Reply-To: <20161114212817.15781-1-nicolas.iooss@m4x.org>
When linking with -Wl,-no-undefined in LDFLAGS (in order to find
possible link-time errors), the Ruby wrapper module needs to be linked
with the libruby.so which is used by $(RUBY). Introduce a new RUBYLIBS
variable to find this library.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
---
libselinux/src/Makefile | 3 ++-
libsemanage/src/Makefile | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 4fe1f7002181..82a1010af2d8 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -15,6 +15,7 @@ INCLUDEDIR ?= $(PREFIX)/include
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
PYSITEDIR ?= $(DESTDIR)$(shell $(PYTHON) -c 'import site; print(site.getsitepackages()[0])')
RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
+RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -lruby"')
RUBYINSTALL ?= $(DESTDIR)$(shell $(RUBY) -e 'puts RbConfig::CONFIG["vendorarchdir"]')
LIBBASE ?= $(shell basename $(LIBDIR))
LIBSEPOLA ?= $(LIBDIR)/libsepol.a
@@ -133,7 +134,7 @@ $(SWIGSO): $(SWIGLOBJ)
$(CC) $(CFLAGS) -shared -o $@ $< -L. -lselinux $(LDFLAGS) -L$(LIBDIR)
$(SWIGRUBYSO): $(SWIGRUBYLOBJ)
- $(CC) $(CFLAGS) -shared -o $@ $^ -L. -lselinux $(LDFLAGS) -L$(LIBDIR)
+ $(CC) $(CFLAGS) -shared -o $@ $^ -L. -lselinux $(LDFLAGS) $(RUBYLIBS) -L$(LIBDIR)
$(LIBA): $(OBJS)
$(AR) rcs $@ $^
diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
index c646f274cbc1..37d6eabbdae8 100644
--- a/libsemanage/src/Makefile
+++ b/libsemanage/src/Makefile
@@ -16,6 +16,7 @@ PYLIBVER ?= $(shell $(PYTHON) -c 'import sys;print("python%d.%d" % sys.version_i
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
PYLIBDIR ?= $(LIBDIR)/$(PYLIBVER)
RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
+RUBYLIBS ?= $(shell $(RUBY) -e 'puts "-L" + RbConfig::CONFIG["libdir"] + " -lruby"')
RUBYINSTALL ?= $(DESTDIR)$(shell $(RUBY) -e 'puts RbConfig::CONFIG["vendorarchdir"]')
LIBBASE=$(shell basename $(LIBDIR))
@@ -82,7 +83,7 @@ $(SWIGSO): $(SWIGLOBJ)
$(CC) $(CFLAGS) $(LDFLAGS) -shared -o $@ $< -L. -lsemanage -L$(LIBDIR)
$(SWIGRUBYSO): $(SWIGRUBYLOBJ)
- $(CC) $(CFLAGS) $(LDFLAGS) -shared -o $@ $^ -L. -lsemanage -L$(LIBDIR)
+ $(CC) $(CFLAGS) $(LDFLAGS) -shared -o $@ $^ -L. -lsemanage $(RUBYLIBS) -L$(LIBDIR)
$(LIBA): $(OBJS)
$(AR) rcs $@ $^
--
2.10.2
^ permalink raw reply related
* [PATCH 1/4] libselinux,libsemanage: use Ruby to define RUBYINC
From: Nicolas Iooss @ 2016-11-14 21:28 UTC (permalink / raw)
To: selinux
This makes building libselinux and libsemanage more robust on systems
with several versions of Ruby installed: when building, only RUBY needs
to be set, without wondering about PKG_CONFIG_PATH or other environment
variables.
Using RbConfig::CONFIG["rubyarchhdrdir"] only works with Ruby >= 2.0 but
since previous Ruby versions are retired since 2015-02-23 this should
not have any impact
(https://www.ruby-lang.org/en/news/2015/02/23/support-for-ruby-1-9-3-has-ended/).
While at it, in libsemanage, use RbConfig::CONFIG["vendorarchdir"] to
install the Ruby extension, like commit 1cd80faa53b6 ("libselinux:
versioned ruby pkg-config and query vendorarchdir properly") did for
libselinux.
My main motivation with this patch is to make the build configuration
easier to define on Travis-CI or other continuous integration platforms.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
---
libselinux/src/Makefile | 3 +--
libsemanage/src/Makefile | 6 ++----
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 76efe49586c0..4fe1f7002181 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -14,8 +14,7 @@ SHLIBDIR ?= $(DESTDIR)/lib
INCLUDEDIR ?= $(PREFIX)/include
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
PYSITEDIR ?= $(DESTDIR)$(shell $(PYTHON) -c 'import site; print(site.getsitepackages()[0])')
-RUBYLIBVER ?= $(shell $(RUBY) -e 'print RUBY_VERSION.split(".")[0..1].join(".")')
-RUBYINC ?= $(shell $(PKG_CONFIG) --exists ruby-$(RUBYLIBVER) && $(PKG_CONFIG) --cflags ruby-$(RUBYLIBVER) || $(PKG_CONFIG) --cflags ruby)
+RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
RUBYINSTALL ?= $(DESTDIR)$(shell $(RUBY) -e 'puts RbConfig::CONFIG["vendorarchdir"]')
LIBBASE ?= $(shell basename $(LIBDIR))
LIBSEPOLA ?= $(LIBDIR)/libsepol.a
diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
index cd29a8abf5ab..c646f274cbc1 100644
--- a/libsemanage/src/Makefile
+++ b/libsemanage/src/Makefile
@@ -15,10 +15,8 @@ INCLUDEDIR ?= $(PREFIX)/include
PYLIBVER ?= $(shell $(PYTHON) -c 'import sys;print("python%d.%d" % sys.version_info[0:2])')
PYINC ?= $(shell $(PKG_CONFIG) --cflags $(PYPREFIX))
PYLIBDIR ?= $(LIBDIR)/$(PYLIBVER)
-RUBYLIBVER ?= $(shell $(RUBY) -e 'print RUBY_VERSION.split(".")[0..1].join(".")')
-RUBYPLATFORM ?= $(shell $(RUBY) -e 'print RUBY_PLATFORM')
-RUBYINC ?= $(shell $(PKG_CONFIG) --cflags ruby-$(RUBYLIBVER))
-RUBYINSTALL ?= $(LIBDIR)/ruby/site_ruby/$(RUBYLIBVER)/$(RUBYPLATFORM)
+RUBYINC ?= $(shell $(RUBY) -e 'puts "-I" + RbConfig::CONFIG["rubyarchhdrdir"] + " -I" + RbConfig::CONFIG["rubyhdrdir"]')
+RUBYINSTALL ?= $(DESTDIR)$(shell $(RUBY) -e 'puts RbConfig::CONFIG["vendorarchdir"]')
LIBBASE=$(shell basename $(LIBDIR))
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v7 9/9] DT:omap3+ads7846: use new common touchscreen bindings
From: Tony Lindgren @ 2016-11-14 21:28 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Sebastian Reichel, Dmitry Torokhov, Mark Rutland,
Benoît Cousson, Russell King, Arnd Bergmann, Michael Welling,
Mika Penttilä, Javier Martinez Canillas, Igor Grinberg,
Andrew F. Davis, Mark Brown, Jonathan Cameron, linux-input,
devicetree, linux-kernel, linux-omap, letux-kernel, linux-iio,
kernel
In-Reply-To: <bb3b82c63810026cd6c23a5788c3efc79fa53e60.1478890925.git.hns@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [161111 11:03]:
> The standard touch screen bindings [1] replace the private ti,swap-xy
> with touchscreen-swaped-x-y. And for the Openpandora we use
> touchscreen-size etc. to match the LCD screen size.
This one should not cause conflicts, so please feel free to merge along
with the driver changes:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [Buildroot] [PATCHv2] dtv-scan-tables: rename file to have only ASCII characters
From: Yann E. MORIN @ 2016-11-14 21:27 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479158436-4361-1-git-send-email-thomas.petazzoni@free-electrons.com>
Thomas, All,
On 2016-11-14 22:20 +0100, Thomas Petazzoni spake thusly:
> Since the bump of dtv-scan-tables to version
> ceb11833b35f05813b1f0397a60e0f3b99430aab in commit
> b1c8794d8ac0eb3895d13ae91d8e912ec469a105, one file contains non-ASCII
> characters, which causes encoding issues tvheadend. Since no other
> file in the dtv-scan-tables code base contains files with non-ASCII
> characters (despite having files named after cities in various
> countries that definitely do have non-ASCII characters), we rename
> this file so that it is named with only ASCII characters.
>
> This fixes the build of tvheadend, which was failing when the host
> Python interpreter was python3, due to a file name encoding issue.
>
> Fixes:
>
> http://autobuild.buildroot.net/results/1ae8bee297edb089535a2fb6ec724ebf7976888d/
> (tvheadend)
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Regards,
Yann E. MORIN.
> ---
> Changes since v1:
> - use a post-patch hook instead of doing the rename at the end of the
> installation step
> ---
> package/dtv-scan-tables/dtv-scan-tables.mk | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/package/dtv-scan-tables/dtv-scan-tables.mk b/package/dtv-scan-tables/dtv-scan-tables.mk
> index 8ef42b9..8a782cb 100644
> --- a/package/dtv-scan-tables/dtv-scan-tables.mk
> +++ b/package/dtv-scan-tables/dtv-scan-tables.mk
> @@ -17,6 +17,15 @@ DTV_SCAN_TABLES_SITE_METHOD = git
> DTV_SCAN_TABLES_LICENSE = GPLv2, LGPLv2.1
> DTV_SCAN_TABLES_LICENSE_FILES = COPYING COPYING.LGPL
>
> +# In order to avoid issues with file name encodings, we rename the
> +# only dtv-scan-tables file that has non-ASCII characters to have a
> +# name using only ASCII characters (pl-Krosno_Sucha_Gora)
> +define DTV_SCAN_TABLES_FIX_NONASCII_FILENAMES
> + mv $(@D)/dvb-t/pl-Krosno_Sucha* $(@D)/dvb-t/pl-Krosno_Sucha_Gora
> +endef
> +
> +DTV_SCAN_TABLES_POST_PATCH_HOOKS += DTV_SCAN_TABLES_FIX_NONASCII_FILENAMES
> +
> define DTV_SCAN_TABLES_INSTALL_TARGET_CMDS
> for f in atsc dvb-c dvb-s dvb-t; do \
> $(INSTALL) -d -m 0755 $(TARGET_DIR)/usr/share/dvb/$$f; \
> --
> 2.7.4
>
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply
* Re: [PATCH kvm-unit-tests v2 08/17] pci: provide pci_scan_bars()
From: Peter Xu @ 2016-11-14 21:27 UTC (permalink / raw)
To: Andrew Jones; +Cc: kvm, rkrcmar, agordeev, jan.kiszka, pbonzini
In-Reply-To: <20161114211834.ixslran5xejinji6@hawk.localdomain>
On Mon, Nov 14, 2016 at 10:18:34PM +0100, Andrew Jones wrote:
[...]
> > diff --git a/lib/pci.c b/lib/pci.c
> > index 0593699..2a58b30 100644
> > --- a/lib/pci.c
> > +++ b/lib/pci.c
> > @@ -230,11 +230,15 @@ void pci_print(void)
> >
> > void pci_scan_bars(struct pci_dev *dev)
> > {
> > - int i = 0;
> > + int i;
> > +
> > + memset(&dev->bar[0], 0, sizeof(dev->bar));
>
> I'm not sure what this memset is for. Anyway, if you need to zero a
> bar, why not just
>
> bar = (phys_addr_t)0;
The memset is to zero all bars before hand. But I think bar =
(phys_addr_t)0 works enough here:
void pci_scan_bars(struct pci_dev *dev)
{
int i;
for (i = 0; i < PCI_BAR_NUM; i++) {
if (!pci_bar_is_valid(dev, i))
continue;
dev->bar[i] = pci_bar_get_addr(dev, i);
if (pci_bar_is64(dev, i)) {
i++;
dev->bar[i] = (phys_addr_t)0;
}
}
}
Thanks,
-- peterx
^ permalink raw reply
* Re: [PATCH 6/6] usb: musb: Drop pointless PM runtime code for dsps glue
From: Tony Lindgren @ 2016-11-14 21:26 UTC (permalink / raw)
To: Johan Hovold
Cc: Bin Liu, Boris Brezillon, Greg Kroah-Hartman, Andreas Kemnade,
Felipe Balbi, George Cherian, Kishon Vijay Abraham I,
Ivaylo Dimitrov, Ladislav Michl, Laurent Pinchart,
Sergei Shtylyov, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161114155916.GV14744@localhost>
* Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161114 07:59]:
> On Fri, Nov 11, 2016 at 10:43:02AM -0800, Tony Lindgren wrote:
> > This already gets done automatically by PM runtime and we have
> > a separate autosuspend timeout in musb_core.c.
> >
> > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>
> > @@ -816,8 +801,6 @@ static int dsps_remove(struct platform_device *pdev)
> > platform_device_unregister(glue->musb);
> >
> > /* disable usbss clocks */
>
> Perhaps also drop this comment which no longer applies.
OK will drop and repost the whole series one more time on Tuesday
in case more comments are still coming.
> > - pm_runtime_dont_use_autosuspend(&pdev->dev);
> > - pm_runtime_put_sync(&pdev->dev);
> > pm_runtime_disable(&pdev->dev);
>
> Reviewed-by: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: rgw/multisite: unlock failure problem
From: Yehuda Sadeh-Weinraub @ 2016-11-14 21:26 UTC (permalink / raw)
To: Tianshan Qu; +Cc: ceph-devel
In-Reply-To: <CAEv+sP6p9sdMt61yucxy10azo5jwQf-e765YbcHvDYQcXrfWPQ@mail.gmail.com>
On Sun, Nov 13, 2016 at 10:40 PM, Tianshan Qu <qutianshan@gmail.com> wrote:
> Hi:
>
> There is a problem with unlock multiste sync log.
> The situation is set rgw_num_rados_handles > 1 and
> rgw_num_async_rados_threads default 32. since multisite use async
> thread pool, so lock and unlock operation may get different threads,
> which may direct to different rados handles, and lock operation use
> client.xxxx to identify owner, different rados handles means different
> client, leads to unlock fail, and next lock will return locked, rgw
> log will show many -16 error.
> Is there a good way to solve this?
Can you open a ceph tracker issue for that?
Thanks,
Yehuda
^ permalink raw reply
* [PATCH] qla2xxx: do not abort all commands in the adapter during EEH recovery
From: Mauricio Faria de Oliveira @ 2016-11-14 21:26 UTC (permalink / raw)
To: Himanshu.Madhani, qla2xxx-upstream
Cc: martin.petersen, jejb, linux-scsi, linux-kernel
The previous commit ("qla2xxx: fix invalid DMA access after command
aborts in PCI device remove") introduced a regression during an EEH
recovery, since the change to the qla2x00_abort_all_cmds() function
calls qla2xxx_eh_abort(), which verifies the EEH recovery condition
but handles it heavy-handed. (commit a465537ad1a4 "qla2xxx: Disable
the adapter and skip error recovery in case of register disconnect.")
This problem warrants a more general/optimistic solution right into
qla2xxx_eh_abort() (eg in case a real command abort arrives during
EEH recovery, or if it takes long enough to trigger command aborts);
but it's still worth to add a check to ensure the code added by the
previous commit is correct and contained within its owner function.
This commit just adds a 'if (!ha->flags.eeh_busy)' check around it.
(ahem; a trivial fix for this -rc series; sorry for this oversight.)
With it applied, both PCI device remove and EEH recovery works fine.
Fixes: 1535aa75a3d8 ("scsi: qla2xxx: fix invalid DMA access after
command aborts in PCI device remove")
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
---
drivers/scsi/qla2xxx/qla_os.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 567fa080e261..56d6142852a5 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -1456,15 +1456,20 @@ uint32_t qla2x00_isp_reg_stat(struct qla_hw_data *ha)
for (cnt = 1; cnt < req->num_outstanding_cmds; cnt++) {
sp = req->outstanding_cmds[cnt];
if (sp) {
- /* Get a reference to the sp and drop the lock.
- * The reference ensures this sp->done() call
- * - and not the call in qla2xxx_eh_abort() -
- * ends the SCSI command (with result 'res').
+ /* Don't abort commands in adapter during EEH
+ * recovery as it's not accessible/responding.
*/
- sp_get(sp);
- spin_unlock_irqrestore(&ha->hardware_lock, flags);
- qla2xxx_eh_abort(GET_CMD_SP(sp));
- spin_lock_irqsave(&ha->hardware_lock, flags);
+ if (!ha->flags.eeh_busy) {
+ /* Get a reference to the sp and drop the lock.
+ * The reference ensures this sp->done() call
+ * - and not the call in qla2xxx_eh_abort() -
+ * ends the SCSI command (with result 'res').
+ */
+ sp_get(sp);
+ spin_unlock_irqrestore(&ha->hardware_lock, flags);
+ qla2xxx_eh_abort(GET_CMD_SP(sp));
+ spin_lock_irqsave(&ha->hardware_lock, flags);
+ }
req->outstanding_cmds[cnt] = NULL;
sp->done(vha, sp, res);
}
--
1.8.3.1
^ permalink raw reply related
* [Buildroot] [PATCH v1 2/2] openjpeg: fix static linking of liblcms2
From: Peter Seiderer @ 2016-11-14 21:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161113143415.611cb424@free-electrons.com>
Hello Thomas,
On Sun, 13 Nov 2016 14:34:15 +0100, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 11 Nov 2016 23:54:11 +0100, Peter Seiderer wrote:
> > Fixes [1]:
> >
> > .../host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/liblcms2.a(cmsplugin.o): In function `_cmsDeleteContext':
> > cmsplugin.c:(.text+0x1c2): undefined reference to `_pthread_mutex_lock'
> > cmsplugin.c:(.text+0x1f6): undefined reference to `_pthread_mutex_unlock'
> >
> > http://autobuild.buildroot.net/results/5ce/5cee20afd8bef5268832cddcb3a5270746be7a57
> >
> > Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> > ---
> > Depends on [2] from Samuel Martin.
>
> Applied to master, thanks. Also, please submit the patch upstream.
O.k, done [1] ...
Regards,
Peter
[1] https://github.com/uclouvain/openjpeg/pull/867
> Thanks!
>
> Thomas
^ permalink raw reply
* Re: [PATCH] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
From: Florian Fainelli @ 2016-11-14 21:25 UTC (permalink / raw)
To: David Miller, alex.g; +Cc: gokhan, netdev, linux-kernel
In-Reply-To: <20161114.161818.1460191406108019273.davem@davemloft.net>
On 11/14/2016 01:18 PM, David Miller wrote:
> From: Alexandru Gagniuc <alex.g@adaptrum.com>
> Date: Sat, 12 Nov 2016 15:32:13 -0800
>
>> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
>> + ret = vsc8601_add_skew(phydev);
>
> I think you should use phy_interface_is_rgmii() here.
>
This would include all RGMII modes, here I think the intent is to check
for PHY_INTERFACE_MODE_RGMII_ID and PHY_INTERFACE_MODE_RGMII_TXID (or
RXID), Alexandru, what direction does the skew settings apply to?
--
Florian
^ permalink raw reply
* [U-Boot] [PATCH v3 7/8] x86: efi: Add a hello world test program
From: Alexander Graf @ 2016-11-14 21:24 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ3NXN_0vdiFcXoGjv5dzpz2fJYRRth2VvzrYqeYyKsCqQ@mail.gmail.com>
On 14/11/2016 21:58, Simon Glass wrote:
> Hi Alex,
>
> On 14 November 2016 at 13:46, Alexander Graf <agraf@suse.de> wrote:
>>
>>
>> On 14/11/2016 21:44, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 11 November 2016 at 23:23, Alexander Graf <agraf@suse.de> wrote:
>>>>
>>>>
>>>>
>>>>> Am 11.11.2016 um 17:17 schrieb Simon Glass <sjg@chromium.org>:
>>>>>
>>>>> Hi Alex,
>>>>>
>>>>>> On 7 November 2016 at 09:32, Alexander Graf <agraf@suse.de> wrote:
>>>>>>
>>>>>>
>>>>>>> On 07/11/2016 10:46, Simon Glass wrote:
>>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>>> On 19 October 2016 at 01:09, Alexander Graf <agraf@suse.de> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 18/10/2016 22:37, Simon Glass wrote:
>>>>>>>>>
>>>>>>>>> Hi Alex,
>>>>>>>>>
>>>>>>>>>> On 18 October 2016 at 01:14, Alexander Graf <agraf@suse.de> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 10/18/2016 04:29 AM, Simon Glass wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It is useful to have a basic sanity check for EFI loader support.
>>>>>>>>>>> Add
>>>>>>>>>>> a
>>>>>>>>>>> 'bootefi hello' command which loads HelloWord.efi and runs it
>>>>>>>>>>> under
>>>>>>>>>>> U-Boot.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> Changes in v3:
>>>>>>>>>>> - Include a link to the program instead of adding it to the tree
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, uh, where is the link?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I put it in the README (see the arm patch).
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm really not convinced this command buys us anything yet. I do
>>>>>>>>>> agree
>>>>>>>>>> that
>>>>>>>>>> we want automated testing - but can't we get that using QEMU and a
>>>>>>>>>> downloadable image file that we pass in as disk and have the distro
>>>>>>>>>> boot do
>>>>>>>>>> its magic?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That seems very heavyweight as a sanity check, although I agree it
>>>>>>>>> is
>>>>>>>>> useful.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It's not really much more heavy weight. The "image file" could simply
>>>>>>>> contain your hello world binary. But with this we don't just verify
>>>>>>>> whether "bootefi" works, but also whether the default boot path works
>>>>>>>> ok.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I don't think I understand what you mean by 'image file'. Is it
>>>>>>> something other than the .efi file? Do you mean a disk image?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes. For reasonable test coverage, we should also verify that the
>>>>>> distro
>>>>>> defaults wrote a sane boot script that automatically searches for a
>>>>>> default
>>>>>> EFI binary in /efi/boot/bootx86.efi on the first partition of all
>>>>>> devices
>>>>>> and runs it.
>>>>>>
>>>>>> So if we just provide an SD card image or hard disk image to QEMU which
>>>>>> contains a hello world .efi binary as that default boot file, we don't
>>>>>> only
>>>>>> test whether the "bootefi" command works, but also whether the distro
>>>>>> boot
>>>>>> script works.
>>>>>
>>>>>
>>>>> That's right.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> Here I am just making sure that EFI programs can start, print output
>>>>>>>>> and exit. It is a test that we can easily run without a lot of
>>>>>>>>> overhead, much less than a full distro boot.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Again, I don't think it's much more overhead and I do believe it
>>>>>>>> gives
>>>>>>>> us much cleaner separation between responsibilities of code (tests go
>>>>>>>> where tests are).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> You are talking about a functional test, something that tests things
>>>>>>> end to end. I prefer to at least start with a smaller test. Granted it
>>>>>>> takes a little more work but it means there are fewer things to hunt
>>>>>>> through when something goes wrong.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, I personally find unit tests terribly annoying and unproductive
>>>>>> and
>>>>>> functional tests very helpful :). And in this case, the effort to write
>>>>>> it
>>>>>> is about the same for both, just that the functional test actually
>>>>>> tells you
>>>>>> that things work or don't work at the end of the day.
>>>>>>
>>>>>> With a code base like U-Boot, a simple functional test like the above
>>>>>> plus
>>>>>> git bisect should get you to an offending patch very quickly.
>>>>>
>>>>>
>>>>> This is not a unit test - in fact the EFI stuff has no unit tests. I
>>>>> suppose if we are trying to find a name this is a small functional
>>>>> test since it exercises the general functionality.
>>>>>
>>>>> I am much keener on small tests than large ones for finding simple
>>>>> bugs. Of course you can generally bisect to find a bug, but the more
>>>>> layers of software you need to look for the harder this is.
>>>>>
>>>>> We could definitely use a pytest which checks an EFI boot into an
>>>>> image, but I don't think this obviates the need for a smaller targeted
>>>>> test like this one.
>>>>
>>>>
>>>> I think arguing over this is moot :). More tests is usually a good thing,
>>>> so whoever gets to write them gets to push them ;). As long as the licenses
>>>> are sound at least.
>>>
>>>
>>> OK good, well please can you review this at some point?
>>
>>
>> Review what exactly?
>
> I mean the patches. There should be ~14 in your queue.
Interesting. I see them on patchwork, but neither in my U-Boot folder,
my inbox nor my spam folder. I wonder what happened there.
Alex
^ permalink raw reply
* Re: [PATCH 3/4] PCI: dra7xx: Add support to force RC to work in GEN1 mode
From: Bjorn Helgaas @ 2016-11-14 21:24 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Bjorn Helgaas, Rob Herring, linux-omap, linux-pci, devicetree,
linux-kernel, nsekhar, Shawn Lin
In-Reply-To: <8ecc1325-365d-bdec-d435-729e0ea49d20@ti.com>
[+cc Shawn]
On Sat, Nov 12, 2016 at 12:40:10PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 12 November 2016 02:45 AM, Bjorn Helgaas wrote:
> > Hi Kishon,
> >
> > On Tue, Oct 11, 2016 at 06:28:34PM +0530, Kishon Vijay Abraham I wrote:
> >> PCIe in AM57x/DRA7x devices is by default
> >> configured to work in GEN2 mode. However there
> >> may be situations when working in GEN1 mode is
> >> desired. One example is limitation i925 (PCIe GEN2
> >> mode not supported at junction temperatures < 0C).
> >>
> >> Add support to force Root Complex to work in GEN1
> >> mode if so desired, but don't force GEN1 mode on
> >> any board just yet.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> >> ---
> >> Documentation/devicetree/bindings/pci/ti-pci.txt | 1 +
> >> drivers/pci/host/pci-dra7xx.c | 27 ++++++++++++++++++++++
> >> 2 files changed, 28 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> index 60e2516..a3d6ca3 100644
> >> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> @@ -25,6 +25,7 @@ PCIe Designware Controller
> >>
> >> Optional Property:
> >> - gpios : Should be added if a gpio line is required to drive PERST# line
> >> + - ti,pcie-is-gen1 : Force the PCIe controller to work in GEN1 (2.5 GT/s).
> >
> > Can we use "max-link-speed" so it's similar to imx6?
>
> yeah, maybe we should make it a generic PCI property?
I forgot that Shawn has already done this! I had already merged those
patches on pci/host-rockchip, but I moved them to pci/host since
they're not Rockchip-specific. Can you take a look at that and see if
you can do what you need based on that pci/host branch?
Bjorn
^ permalink raw reply
* [U-Boot] [PATCH v6 1/2] armv8/fsl-layerscape: fdt: fixup LS1043A rev1 GIC node
From: york sun @ 2016-11-14 21:24 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1477970547-28846-1-git-send-email-wenbin.song@nxp.com>
On 10/31/2016 08:35 PM, Wenbin song wrote:
> The LS1043A rev1.1 silicon supports two types of GIC offset: 4K alignment
> and 64K alignment. The bit SCFG_GIC400_ALIGN[GIC_ADDR_BIT] is used to choose
> which offset will be used. If GIC_ADDR_BIT bit is set, 4K alignment is used,
> or else 64K alignment is used. The rev1.0 silicon only supports the CIG offset
> with 4K alignment.
Wenbin,
According to your patch and your explanation, the rev 1 SoC supports 4K
alignment only. The rev 1.1 and newer SoC supports both 4K and 64K. If
you don't do anything in PBI, the default is 64K. Does this 64k
alignment apply to any other SoCs?
York
^ permalink raw reply
* Re: [PATCH 3/4] PCI: dra7xx: Add support to force RC to work in GEN1 mode
From: Bjorn Helgaas @ 2016-11-14 21:24 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Bjorn Helgaas, Rob Herring, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
Shawn Lin
In-Reply-To: <8ecc1325-365d-bdec-d435-729e0ea49d20-l0cyMroinI0@public.gmane.org>
[+cc Shawn]
On Sat, Nov 12, 2016 at 12:40:10PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 12 November 2016 02:45 AM, Bjorn Helgaas wrote:
> > Hi Kishon,
> >
> > On Tue, Oct 11, 2016 at 06:28:34PM +0530, Kishon Vijay Abraham I wrote:
> >> PCIe in AM57x/DRA7x devices is by default
> >> configured to work in GEN2 mode. However there
> >> may be situations when working in GEN1 mode is
> >> desired. One example is limitation i925 (PCIe GEN2
> >> mode not supported at junction temperatures < 0C).
> >>
> >> Add support to force Root Complex to work in GEN1
> >> mode if so desired, but don't force GEN1 mode on
> >> any board just yet.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> >> Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
> >> ---
> >> Documentation/devicetree/bindings/pci/ti-pci.txt | 1 +
> >> drivers/pci/host/pci-dra7xx.c | 27 ++++++++++++++++++++++
> >> 2 files changed, 28 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> index 60e2516..a3d6ca3 100644
> >> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> @@ -25,6 +25,7 @@ PCIe Designware Controller
> >>
> >> Optional Property:
> >> - gpios : Should be added if a gpio line is required to drive PERST# line
> >> + - ti,pcie-is-gen1 : Force the PCIe controller to work in GEN1 (2.5 GT/s).
> >
> > Can we use "max-link-speed" so it's similar to imx6?
>
> yeah, maybe we should make it a generic PCI property?
I forgot that Shawn has already done this! I had already merged those
patches on pci/host-rockchip, but I moved them to pci/host since
they're not Rockchip-specific. Can you take a look at that and see if
you can do what you need based on that pci/host branch?
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] sctp: change sk state only when it has assocs in sctp_shutdown
From: David Miller @ 2016-11-14 21:23 UTC (permalink / raw)
To: lucien.xin
Cc: netdev, linux-sctp, marcelo.leitner, nhorman, vyasevich,
andreyknvl
In-Reply-To: <d260f8b59f52d7ef00b83a554fc19d4aa91766a2.1479044677.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sun, 13 Nov 2016 21:44:37 +0800
> Now when users shutdown a sock with SEND_SHUTDOWN in sctp, even if
> this sock has no connection (assoc), sk state would be changed to
> SCTP_SS_CLOSING, which is not as we expect.
>
> Besides, after that if users try to listen on this sock, kernel
> could even panic when it dereference sctp_sk(sk)->bind_hash in
> sctp_inet_listen, as bind_hash is null when sock has no assoc.
>
> This patch is to move sk state change after checking sk assocs
> is not empty, and also merge these two if() conditions and reduce
> indent level.
>
> Fixes: d46e416c11c8 ("sctp: sctp should change socket state when shutdown is received")
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: change sk state only when it has assocs in sctp_shutdown
From: David Miller @ 2016-11-14 21:23 UTC (permalink / raw)
To: lucien.xin
Cc: netdev, linux-sctp, marcelo.leitner, nhorman, vyasevich,
andreyknvl
In-Reply-To: <d260f8b59f52d7ef00b83a554fc19d4aa91766a2.1479044677.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sun, 13 Nov 2016 21:44:37 +0800
> Now when users shutdown a sock with SEND_SHUTDOWN in sctp, even if
> this sock has no connection (assoc), sk state would be changed to
> SCTP_SS_CLOSING, which is not as we expect.
>
> Besides, after that if users try to listen on this sock, kernel
> could even panic when it dereference sctp_sk(sk)->bind_hash in
> sctp_inet_listen, as bind_hash is null when sock has no assoc.
>
> This patch is to move sk state change after checking sk assocs
> is not empty, and also merge these two if() conditions and reduce
> indent level.
>
> Fixes: d46e416c11c8 ("sctp: sctp should change socket state when shutdown is received")
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Zygo Blaxell @ 2016-11-14 21:22 UTC (permalink / raw)
To: James Pharaoh; +Cc: Austin S. Hemmelgarn, Mark Fasheh, linux-btrfs
In-Reply-To: <ab787485-c6ba-cada-07c5-f226d1c395e2@wellbehavedsoftware.com>
[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]
On Mon, Nov 14, 2016 at 09:07:51PM +0100, James Pharaoh wrote:
> On 14/11/16 20:51, Zygo Blaxell wrote:
> >On Mon, Nov 14, 2016 at 01:39:02PM -0500, Austin S. Hemmelgarn wrote:
> >>On 2016-11-14 13:22, James Pharaoh wrote:
> >>>One thing I am keen to understand is if BTRFS will automatically ignore
> >>>a request to deduplicate a file if it is already deduplicated? Given the
> >>>performance I see when doing a repeat deduplication, it seems to me that
> >>>it can't be doing so, although this could be caused by the CPU usage you
> >>>mention above.
> >>
> >>What's happening is that the dedupe ioctl does a byte-wise comparison of the
> >>ranges to make sure they're the same before linking them. This is actually
> >>what takes most of the time when calling the ioctl, and is part of why it
> >>takes longer the larger the range to deduplicate is. In essence, it's
> >>behaving like an OS should and not trusting userspace to make reasonable
> >>requests (which is also why there's a separate ioctl to clone a range from
> >>another file instead of deduplicating existing data).
> >
> > - the extent-same ioctl could check to see which extents
> > are referenced by the src and dst ranges, and return success
> > immediately without reading data if they are the same (but
> > userspace should already know this, or it's wasting a huge amount
> > of time before it even calls the kernel).
>
> Yes, this is what I am talking about. I believe I should be able to read
> data about the BTRFS data structures and determine if this is the case. I
> don't care if there are false matches, due to concurrent updates, but
> there'll be a /lot/ of repeat deduplications unless I do this, because even
> if the file is identical, the mtime etc hasn't changed, and I have a record
> of previously doing a dedupe, there's no guarantee that the file hasn't been
> rewritten in place (eg by rsync), and no way that I know of to reliably
> detect if a file has been changed.
>
> I am sure there are libraries out there which can look into the data
> structures of a BTRFS file system, I haven't researched this in detail
> though. I imagine that with some kind of lock on a BTRFS root, this could be
> achieved by simply reading the data from the disk, since I believe that
> everything is copy-on-write, so no existing data should be overwritten until
> all roots referring to it are updated. Perhaps I'm missing something
> though...
FIEMAP (VFS) and SEARCH_V2 (btrfs-specific) will both give you access
to the underlying physical block numbers. SEARCH_V2 is non-trivial
to use without reverse-engineering significant parts of btrfs-progs.
SEARCH_V2 is a generic tree-searching tool which will give you all kinds
of information about btrfs structures...it's essential for a sophisticated
deduplicator and overkill for a simple one.
For full-file dedup using FIEMAP you only need to look at the "physical"
field of the first extent (if it's zero or the same as the other file, the
files cannot be deduplicated or are already deduplicated, respectively).
The source for 'filefrag' (from e2fsprogs) is good for learning how
FIEMAP works.
For block-level dedup you need to look at each extent individually.
That's much slower and full of additional caveats. If you're going down
that road it's probably better to just improve duperemove instead.
> James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Maxime Ripard @ 2016-11-14 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108115129.f315ca5feefd22614859bbe3@free.fr>
On Tue, Nov 08, 2016 at 11:51:29AM +0100, Jean-Francois Moine wrote:
> On Mon, 7 Nov 2016 21:05:05 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai <wens@csie.org> wrote:
> > >
> > > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> > > > > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> > > > >
> > > > > Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> > > > > ---
> > > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > > - it handles the H3
> > > >
> > > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > > the newer SoCs.
> > >
> > > I started to add the H3 into the sun4i-i2s, but I am blocked with
> > > regmap.
> > > Many H3 registers are common with the A10, but some of them have more
> > > or less fields, the fields may be at different offsets. And, finally,
> > > some registers are completely different.
> > > This would not raise any problem, except with regmap which is really
> > > painful.
> >
> > That's weird, because regmap's regmap_field should make that much
> > easier.
>
> #define field_relaxed(addr, mask, val) \
> writel_relaxed((readl_relaxed(addr) & mask) | val, addr)
I'm not sure what you mean here.
> > > As I may understood, regmap is used to simplify suspend/resume, but, is
> > > it useful to save the I2S register on suspend?
> > > Practically, I am streaming some tune on my device. I suspend it for
> > > any reason. The next morning, I resume it. Are you sure I want to
> > > continue to hear the end of the tune?
> > >
> > > I better think that streaming should be simply stopped on suspend.
> >
> > You're mistaken. The code in there is for *runtime* suspend, ie when
> > the device is no longer used, so that case shouldn't even happen at
> > all.
> >
> > (And real suspend isn't supported anyway)
>
> Is it time to remove this useless code?
Which useless code?
> > > Then, there is no need to save the playing registers, and, here I am,
> > > there is no need to use regmap.
> > >
> > > May I go this way?
> >
> > No, please don't. regmap is also providing very useful features, such
> > as access to all the registers through debugfs, or tracing. What
> > exactly feels painful to you?
>
> When the I/O registers are in memory (that's the case), you may access
> them (read and write) thru /dev/mem.
For all the registers if you want to dump all of them. It needs
scripting, it needs root access, and it needs some tool (either devmem
or a custom one) to dump the values. And this is if you have the right
kernel configuration options (devmem enabled, with the protection
against mapped devices disabled).
It just works with debugfs.
> Also, is a register access trace really needed in this driver?
Yes.
> The pain is to define the regmap_config (which registers can be
> read/write/volatile and which can be the values the u-boot let us in
> the registers at startup time), and the lot of code which is run instead
> of simple load/store machine instructions.
This is only needed if you want to use caching, and caching is
optional.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/5cda6589/attachment.sig>
^ 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.