* [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
* [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 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 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
* Re: [PATCH 2/2] tpm/tpm2-chip: fix kdoc errors
From: Jarkko Sakkinen @ 2016-11-14 21:30 UTC (permalink / raw)
To: Winkler, Tomas
Cc: tpmdd-devel@lists.sourceforge.net, Jason Gunthorpe,
linux-kernel@vger.kernel.org
In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B5431BEFA@hasmsx108.ger.corp.intel.com>
On Mon, Nov 14, 2016 at 01:05:41PM +0000, Winkler, Tomas wrote:
> .org
> > Subject: Re: [PATCH 2/2] tpm/tpm2-chip: fix kdoc errors
> >
> > On Tue, Nov 01, 2016 at 03:05:14AM +0200, Tomas Winkler wrote:
> > > Use correct kdoc format, describe correct parameters and return values.
> > >
> > > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > > ---
> > > drivers/char/tpm/tpm2-cmd.c | 107
> > > +++++++++++++++++++++++++++-----------------
> > > 1 file changed, 66 insertions(+), 41 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> > > index 7df55d58c939..a7a519c87bee 100644
> > > --- a/drivers/char/tpm/tpm2-cmd.c
> > > +++ b/drivers/char/tpm/tpm2-cmd.c
> > > @@ -258,11 +258,13 @@ static const struct tpm_input_header
> > tpm2_pcrread_header = {
> > > * tpm2_pcr_read() - read a PCR value
> > > * @chip: TPM chip to use.
> > > * @pcr_idx: index of the PCR to read.
> > > - * @ref_buf: buffer to store the resulting hash,
> > > + * @res_buf: buffer to store the resulting hash,
> > > *
> > > - * 0 is returned when the operation is successful. If a negative
> > > number is
> > > - * returned it remarks a POSIX error code. If a positive number is
> > > returned
> > > - * it remarks a TPM error.
> > > + *
> > > + * Return:
> > > + * 0 when the operation is successful
> > > + * A negative number for system errors (errno)
> > > + * A positive number for a TPM error.
> > > */
> > > int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf) {
> > > @@ -304,13 +306,15 @@ static const struct tpm_input_header
> > > tpm2_pcrextend_header = {
> > >
> > > /**
> > > * tpm2_pcr_extend() - extend a PCR value
> > > + *
> > > * @chip: TPM chip to use.
> > > * @pcr_idx: index of the PCR.
> > > * @hash: hash value to use for the extend operation.
> > > *
> > > - * 0 is returned when the operation is successful. If a negative
> > > number is
> > > - * returned it remarks a POSIX error code. If a positive number is
> > > returned
> > > - * it remarks a TPM error.
> > > + * Return:
> > > + * 0 when the operation is successful
> > > + * A negative number for system errors (errno)
> > > + * A positive number for a TPM error.
> >
> > Put this to tpm_transmit_cmd only and refer to that from other functions with
> > "same as with tpm_transmit_cmd()" with parenthesis because that marks in rst
> > a link to that function.
>
> And then tpm_transmit_cmd() will point to tpm_transmit() ?
For tpm_transmit() those error codes don't apply. It never returns TPM
error codes.
> I'm not sure I'm happy about those links, rst is okay but after all mostly we're just looking directly to the sources with a simple editor.
> Anyhow this patch is to resolve the kdoc syntax bug, the overhaul of the documentation can be built on top of it.
Do you know how could I easily get the rendered output for this? If I do
make htmldocs. At least when I tried it, it generates only those kdoc
comments that are imported to the rst files (like I do with
tpm_vtmp_proxy).
> Thanks
> Tomas
/Jarkko
^ permalink raw reply
* Re: [PATCH net-next 00/11] Start adding support for mv88e6390 family
From: David Miller @ 2016-11-14 21:30 UTC (permalink / raw)
To: andrew; +Cc: netdev, vivien.didelot
In-Reply-To: <20161113202403.GB18258@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 13 Nov 2016 21:24:03 +0100
> I'm happy to respin, but i'm wondering why the don't apply.
Andrew, even though this issue has been resolved, it looks like Vivien
has some feedback for you to address with this series so I guess I'll
see a v2 or similar soon.
Thanks.
^ permalink raw reply
* (unknown),
From: 5415306259-PhIK+mYhcR9sDcysRhXauQC/G2K4zDHf @ 2016-11-14 21:31 UTC (permalink / raw)
To: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
[-- Attachment #1: text_1479159022652.txt --]
[-- Type: text/plain, Size: 149 bytes --]
(Undeliverable: Who is this?) [http://products.office.com/en-us/CMSImages/Office365Logo_Orange.png?version=b8d100a9-0a8b-8e6a-88e1-ef488fee0470]
Your
[-- Attachment #2: Type: text/plain, Size: 421 bytes --]
This picture message or video message was sent using Multimedia Messaging Service.
To play video messages sent to email, Apple QuickTime 6.5 or higher is required. Visit www.apple.com/quicktime/download to download the free player or upgrade your existing QuickTime Player. Note: During the download process when asked to choose an installation type (Minimum, Recommended or Custom), select Minimum for faster download.
[-- Attachment #3: Type: text/plain, Size: 205 bytes --]
_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [PATCH] net: stmmac: Add support for ethtool::nway_reset
From: David Miller @ 2016-11-14 21:33 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, peppe.cavallaro, alexandre.torgue, linux-kernel
In-Reply-To: <680b3968-5cdc-2229-fb8d-e9e75f87809a@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 13 Nov 2016 13:35:04 -0800
> Le 13/11/2016 à 13:24, Florian Fainelli a écrit :
>> If we have a PHY device, just invoke genphy_restart_aneg() to restart
>> auto-negotiation.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> David, please drop this patch for now, since I have another one pending
> which is going to touch the net_device/phydev interaction, this one also
> causes a build warning since priv is not used.
Ok, thanks for letting me know.
^ permalink raw reply
* [Buildroot] [PATCH] toolchain: Bump ARC tools to arc-2016.09-rc1
From: Thomas Petazzoni @ 2016-11-14 21:33 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479146197-41383-1-git-send-email-vzakhar@synopsys.com>
Hello,
On Mon, 14 Nov 2016 20:56:37 +0300, Vlad Zakharov wrote:
> As described at:
> 4520524ba055706236db9f00dd79f1b2e2e87fde
> this commit continues a series of updates of ARC tools.
> This time we're updating tools to arc-2016.09-rc1.
>
> This update contains a lot of important fixes, e.g. it fixes:
> http://autobuild.buildroot.net/results/4c7/4c77f33c842b37bf28cb931edf1b290e1bf4d93c//
> http://autobuild.buildroot.net/results/902/902729a0b98675ad803939e3ecdcf230065a6012//
> and other failures.
>
> Other important change is that we also update gdb. Now we are
> using gdb 7.12.
>
> This version of gdb requires C++ toolchain support so we add
> corresponding dependency to gdb Config.in file.
>
> Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
I have rebuilt and updated the pre-built ARC toolchain used by the
autobuilders to use this new set of tools.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/1] secilc: do not build secilc man page if it is up to date
From: Nicolas Iooss @ 2016-11-14 21:33 UTC (permalink / raw)
To: selinux
When running "make all" several times in the root directory of the
project, the following lines always appear (and the command takes some
seconds to complete on my system with a slow hard drive):
xmlto man secilc.8.xml
Note: Writing secilc.8
This is because "make man" always builds secilc.8 even though
secilc.8.xml has not been modified. Introduce an intermediate target to
avoid this behavior.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
---
secilc/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/secilc/Makefile b/secilc/Makefile
index 9bea186ba0b9..40254ce44caf 100644
--- a/secilc/Makefile
+++ b/secilc/Makefile
@@ -25,7 +25,9 @@ $(SECILC): $(SECILC_OBJS)
test: $(SECILC)
./$(SECILC) test/policy.cil
-man: $(MANPAGE).xml
+man: $(MANPAGE)
+
+$(MANPAGE): $(MANPAGE).xml
$(XMLTO) man $(MANPAGE).xml
install: all man
--
2.10.2
^ permalink raw reply related
* Re: [PATCH igt v4 05/13] igt/gem_exec_parse: make global vars local to main()
From: Matthew Auld @ 2016-11-14 21:33 UTC (permalink / raw)
To: Robert Bragg; +Cc: Intel Graphics Development
In-Reply-To: <20161114205122.10742-6-robert@sixbynine.org>
On 14 November 2016 at 20:51, Robert Bragg <robert@sixbynine.org> wrote:
> Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH nf-next] netfilter: nf_tables: validate maximum value of u32 netlink hash attribute
From: Laura Garcia Liebana @ 2016-11-14 21:33 UTC (permalink / raw)
To: netfilter-devel
Use the function nft_parse_u32_check() to fetch the value and validate
the u32 attribute into the hash len u8 field.
This patch revisits 4da449ae1df9 ("netfilter: nft_exthdr: Add size check
on u8 nft_exthdr attributes").
Signed-off-by: Laura Garcia Liebana <nevola@gmail.com>
---
net/netfilter/nft_hash.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nft_hash.c b/net/netfilter/nft_hash.c
index 97ad8e30e4b4..eb2721af898d 100644
--- a/net/netfilter/nft_hash.c
+++ b/net/netfilter/nft_hash.c
@@ -53,6 +53,7 @@ static int nft_hash_init(const struct nft_ctx *ctx,
{
struct nft_hash *priv = nft_expr_priv(expr);
u32 len;
+ int err;
if (!tb[NFTA_HASH_SREG] ||
!tb[NFTA_HASH_DREG] ||
@@ -66,8 +67,10 @@ static int nft_hash_init(const struct nft_ctx *ctx,
priv->sreg = nft_parse_register(tb[NFTA_HASH_SREG]);
priv->dreg = nft_parse_register(tb[NFTA_HASH_DREG]);
- len = ntohl(nla_get_be32(tb[NFTA_HASH_LEN]));
- if (len == 0 || len > U8_MAX)
+ err = nft_parse_u32_check(tb[NFTA_HASH_LEN], U8_MAX, &len);
+ if (err < 0)
+ return err;
+ if (len == 0)
return -ERANGE;
priv->len = len;
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] remote-curl: don't hang when a server dies before any output
From: Jeff King @ 2016-11-14 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Turner, git, spearce
In-Reply-To: <xmqqpolxwyh6.fsf@gitster.mtv.corp.google.com>
On Mon, Nov 14, 2016 at 01:19:49PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > So something like this. It turned out to be a lot uglier than I had
> > hoped because we get fed the data from curl in odd-sized chunks, so we
> > need a state machine.
>
> It is unfortunate that we have to snoop the protocol like this to
> infer an error, but I do not think we can do better than that
> approach. FWIW, I did not find the logic in update_pktline_state()
> you wrote ugly at all.
>
> Having to assume that the end of each round from the other end must
> be a FLUSH does feel somewhat ugly and brittle, though.
Yeah, I agree. The other option is to signal to fetch-pack that we saw
EOF on the server request, and then we do not have to snoop; it knows
where in the protocol state it is at.
But doing that is a little tricky. We could send our own flush packet,
but that doesn't quite work. When fetch-pack sees a flush it does not
know if it is the server's flush and it should wait for our flush, or if
the server hung up prematurely and the flush is from us. :)
The "elegant" solution is to just wrap the server's data in another set
of pktlines. So the server flush becomes "00080000" (8 bytes including
our pktline, and then 4 bytes for the flush packet). But wrapping each
pktline gets a little hairy. What happens when the server sends us a
pktline of LARGE_PACKET_MAX? We can't wrap that without sending our own
pktline that's LARGE_PACKET_MAX+4.
One solution is that pktlines 0001-0003 are unused and impossible for
data. So we could send the server pktlines as-is, and use pktline 0001
as our special signal for "end of http request". A server shouldn't ever
send that, and if they did (perhaps to try something malicious), it
would just cause fetch-pack to think they prematurely ended the
conversation.
Hmm. I suppose that doesn't quite work, though. One of the problems is
that the server sends a partial pktline, in which case our special flush
packet would get gobbled up as data for that broken pktline.
So you really do need framing or some other out-of-band communication,
or resolve yourself to snooping in remote-curl.
-Peff
^ permalink raw reply
* [layerindex-web] Fixes to import_project.py
From: Mark Hatle @ 2016-11-14 21:33 UTC (permalink / raw)
To: yocto; +Cc: Liam Howlett
I've pushed two new commits to the mhatle/django18 branch.
Below are the two additional commits. These fix issues we discovered in the
import_project.py script.
commit 842c76a95a48be5b18def0b713d1158a4dea24b2
Author: Liam R. Howlett <Liam.Howlett@WindRiver.com>
Date: Fri Nov 4 11:10:22 2016 -0400
layerindex/tools/import_project.py: Code cleanup
Remove ; and spaces when setting variables in calls.
Signed-off-by: Liam R. Howlett <Liam.Howlett@WindRiver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
commit 5951402e7275738696409a5ca5fa08b0c1d57031
Author: Liam R. Howlett <Liam.Howlett@WindRiver.com>
Date: Fri Nov 4 11:09:29 2016 -0400
layerindex/tools/import_project.py: Detect remote name & branch
Don't assume remote name is origin, run `git remote` to get the remote
name. When checking the remote, detect the branch as well, that way the
layerindex will work if the remote branch name and local branch name do
not match.
Note that this currently only supports one remote.
Signed-off-by: Liam R. Howlett <Liam.Howlett@WindRiver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
^ permalink raw reply
* [Buildroot] [git commit] openjpeg: security bump to version 2.1.2
From: Thomas Petazzoni @ 2016-11-14 21:33 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=eac8c9ee2439fb4a43c9cef5371ae268489cd185
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
See CHANGELOG.md for the full list of fixes, including security issues.
See CVE number lists at [1] and [2].
[1] http://advisories.mageia.org/MGASA-2016-0362.html
[2] https://lists.fedoraproject.org/archives/list/package-announce at lists.fedoraproject.org/thread/HPMDEUIMHTLKMHELDL4F4HZ7X4Y34JEB/
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/openjpeg/openjpeg.hash | 2 +-
package/openjpeg/openjpeg.mk | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/package/openjpeg/openjpeg.hash b/package/openjpeg/openjpeg.hash
index 35d4fbd..c0abd0c 100644
--- a/package/openjpeg/openjpeg.hash
+++ b/package/openjpeg/openjpeg.hash
@@ -1,2 +1,2 @@
# Locally computed:
-sha256 4afc996cd5e0d16360d71c58216950bcb4ce29a3272360eb29cadb1c8bce4efc openjpeg-2.1.tar.gz
+sha256 4ce77b6ef538ef090d9bde1d5eeff8b3069ab56c4906f083475517c2c023dfa7 openjpeg-2.1.2.tar.gz
diff --git a/package/openjpeg/openjpeg.mk b/package/openjpeg/openjpeg.mk
index bf12526..ca22068 100644
--- a/package/openjpeg/openjpeg.mk
+++ b/package/openjpeg/openjpeg.mk
@@ -4,8 +4,8 @@
#
################################################################################
-OPENJPEG_VERSION = 2.1
-OPENJPEG_SITE = $(call github,uclouvain,openjpeg,version.$(OPENJPEG_VERSION))
+OPENJPEG_VERSION = 2.1.2
+OPENJPEG_SITE = $(call github,uclouvain,openjpeg,v$(OPENJPEG_VERSION))
OPENJPEG_LICENSE = BSD-2c
OPENJPEG_LICENSE_FILES = LICENSE
OPENJPEG_INSTALL_STAGING = YES
^ permalink raw reply related
* [Buildroot] [PATCH] openjpeg: security bump to version 2.1.2
From: Thomas Petazzoni @ 2016-11-14 21:34 UTC (permalink / raw)
To: buildroot
In-Reply-To: <08339f7ad87912d98912f4c52268b6c79ffd515c.1479156463.git.baruch@tkos.co.il>
Hello,
On Mon, 14 Nov 2016 22:47:43 +0200, Baruch Siach wrote:
> See CHANGELOG.md for the full list of fixes, including security issues.
>
> See CVE number lists at [1] and [2].
>
> [1] http://advisories.mageia.org/MGASA-2016-0362.html
> [2] https://lists.fedoraproject.org/archives/list/package-announce at lists.fedoraproject.org/thread/HPMDEUIMHTLKMHELDL4F4HZ7X4Y34JEB/
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> package/openjpeg/openjpeg.hash | 2 +-
> package/openjpeg/openjpeg.mk | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
Applied to master, thanks.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH igt v4 06/13] igt/gem_exec_parse: init global parser_version in fixture
From: Matthew Auld @ 2016-11-14 21:33 UTC (permalink / raw)
To: Robert Bragg; +Cc: Intel Graphics Development
In-Reply-To: <20161114205122.10742-7-robert@sixbynine.org>
On 14 November 2016 at 20:51, Robert Bragg <robert@sixbynine.org> wrote:
> This adds a static global int parser_version that can be referenced by
> all subtests without needing multiple GETPARAM requests.
>
> Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [Buildroot] [git commit] dtv-scan-tables: rename file to have only ASCII characters
From: Thomas Petazzoni @ 2016-11-14 21:34 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=7f4dfd11888d1a092f3b92e8550b3958d87412f3
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
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; \
^ permalink raw reply related
* [Buildroot] [PATCHv2] dtv-scan-tables: rename file to have only ASCII characters
From: Thomas Petazzoni @ 2016-11-14 21:34 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479158436-4361-1-git-send-email-thomas.petazzoni@free-electrons.com>
Hello,
On Mon, 14 Nov 2016 22:20:36 +0100, Thomas Petazzoni wrote:
> 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>
> ---
> 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(+)
Applied to master, thanks. Thanks Yann for reviewing the patch!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net] ipv4: fix cloning issues in fib_trie_unmerge()
From: Eric Dumazet @ 2016-11-14 21:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Alexander Duyck
From: Eric Dumazet <edumazet@google.com>
I had crashes in a DEBUG_PAGEALLOC kernels in fib_table_flush() or
fib_table_lookup() that I back tracked to a refcounting issue
happening when we clone struct fib_alias in fib_trie_unmerge()
While fixing this issue, I also noticed a mem leak happening
if fib_insert_alias() fails.
Fixes: 0ddcf43d5d4a0 ("ipv4: FIB Local/MAIN table collapse")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>
---
net/ipv4/fib_trie.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 4cff74d4133f..ebf49ab889e8 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1737,14 +1737,19 @@ struct fib_table *fib_trie_unmerge(struct fib_table *oldtb)
goto out;
memcpy(new_fa, fa, sizeof(*fa));
+ if (fa->fa_info)
+ fa->fa_info->fib_treeref++;
/* insert clone into table */
if (!local_l)
local_l = fib_find_node(lt, &local_tp, l->key);
if (fib_insert_alias(lt, local_tp, local_l, new_fa,
- NULL, l->key))
+ NULL, l->key)) {
+ kmem_cache_free(fn_alias_kmem, new_fa);
+ fib_release_info(fa->fa_info);
goto out;
+ }
}
/* stop loop if key wrapped back to 0 */
^ permalink raw reply related
* [PATCH libibmad] configure.ac: Update AM_INIT_AUTOMAKE to use subdir-objects
From: Hal Rosenstock @ 2016-11-14 21:34 UTC (permalink / raw)
To: Weiny, Ira; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
With this option, the objects are placed into the subdirectory of
the build directory corresponding to the subdirectory of the source file.
Fixes the following warning:
Makefile.am:16: warning: source file 'src/dump.c' is in a subdirectory,
Makefile.am:16: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
Signed-off-by: Hal Rosenstock <hal-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
diff --git a/configure.ac b/configure.ac
index 843dbfd..6453e11 100644
--- a/configure.ac
+++ b/configure.ac
@@ -6,7 +6,7 @@ AC_CONFIG_SRCDIR([src/sa.c])
AC_CONFIG_AUX_DIR(config)
AC_CONFIG_MACRO_DIR(config)
AM_CONFIG_HEADER(config.h)
-AM_INIT_AUTOMAKE
+AM_INIT_AUTOMAKE([subdir-objects])
AC_SUBST(RELEASE, ${RELEASE:-unknown})
AC_SUBST(TARBALL, ${TARBALL:-${PACKAGE}-${VERSION}.tar.gz})
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 related
* Re: [MISSED PATCH] xattr: Fix setting security xattrs on sockfs
From: Casey Schaufler @ 2016-11-14 21:29 UTC (permalink / raw)
To: Andreas Gruenbacher, Alexander Viro, Linus Torvalds,
Andrew Morton
Cc: linux-fsdevel, Miklos Szeredi
In-Reply-To: <1479068614-5952-1-git-send-email-agruenba@redhat.com>
On 11/13/2016 12:23 PM, Andreas Gruenbacher wrote:
> Al,
>
> here is a fix for a regression introduced in commit 6c6ef9f2 (which is
> contained in v4.9-rc1). The fix was originally posted on November 3 [*], with
> no reaction:
>
> https://patchwork.kernel.org/patch/9410885/
> https://patchwork.kernel.org/patch/9411123/
>
> So may I again ask you to have a look, preferably before we slip yet another -rc?
This is a critical regression fix for Smack. Without
the fix it is impossible to properly configure certain
system services.
>
> Thanks,
> Andreas
>
> --
>
> The IOP_XATTR flag is set on sockfs because sockfs supports getting the
> "system.sockprotoname" xattr. Since commit 6c6ef9f2, this flag is checked for
> setxattr support as well. This is wrong on sockfs because security xattr
> support there is supposed to be provided by security_inode_setsecurity. The
> smack security module relies on socket labels (xattrs).
>
> Fix this by adding a security xattr handler on sockfs that returns
> -EAGAIN, and by checking for -EAGAIN in setxattr.
>
> We cannot simply check for -EOPNOTSUPP in setxattr because there are
> filesystems that neither have direct security xattr support nor support
> via security_inode_setsecurity. A more proper fix might be to move the
> call to security_inode_setsecurity into sockfs, but it's not clear to me
> if that is safe: we would end up calling security_inode_post_setxattr after
> that as well.
>
> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
> ---
> fs/xattr.c | 22 ++++++++++++++--------
> net/socket.c | 15 +++++++++++++++
> 2 files changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index 3368659..2d13b4e 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -170,7 +170,7 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const char *name,
> const void *value, size_t size, int flags)
> {
> struct inode *inode = dentry->d_inode;
> - int error = -EOPNOTSUPP;
> + int error = -EAGAIN;
> int issec = !strncmp(name, XATTR_SECURITY_PREFIX,
> XATTR_SECURITY_PREFIX_LEN);
>
> @@ -183,15 +183,21 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const char *name,
> security_inode_post_setxattr(dentry, name, value,
> size, flags);
> }
> - } else if (issec) {
> - const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
> -
> + } else {
> if (unlikely(is_bad_inode(inode)))
> return -EIO;
> - error = security_inode_setsecurity(inode, suffix, value,
> - size, flags);
> - if (!error)
> - fsnotify_xattr(dentry);
> + }
> + if (error == -EAGAIN) {
> + error = -EOPNOTSUPP;
> +
> + if (issec) {
> + const char *suffix = name + XATTR_SECURITY_PREFIX_LEN;
> +
> + error = security_inode_setsecurity(inode, suffix, value,
> + size, flags);
> + if (!error)
> + fsnotify_xattr(dentry);
> + }
> }
>
> return error;
> diff --git a/net/socket.c b/net/socket.c
> index 5a9bf5e..9820725 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -341,8 +341,23 @@ static const struct xattr_handler sockfs_xattr_handler = {
> .get = sockfs_xattr_get,
> };
>
> +static int sockfs_security_xattr_set(const struct xattr_handler *handler,
> + struct dentry *dentry, struct inode *inode,
> + const char *suffix, const void *value,
> + size_t size, int flags)
> +{
> + /* Handled by LSM. */
> + return -EAGAIN;
> +}
> +
> +static const struct xattr_handler sockfs_security_xattr_handler = {
> + .prefix = XATTR_SECURITY_PREFIX,
> + .set = sockfs_security_xattr_set,
> +};
> +
> static const struct xattr_handler *sockfs_xattr_handlers[] = {
> &sockfs_xattr_handler,
> + &sockfs_security_xattr_handler,
> NULL
> };
>
^ permalink raw reply
* [U-Boot] [PATCH v3 7/8] x86: efi: Add a hello world test program
From: Simon Glass @ 2016-11-14 21:35 UTC (permalink / raw)
To: u-boot
In-Reply-To: <477cfddb-1d3c-ede3-d106-f71ab17a4a01@suse.de>
Hi Alex,
On 14 November 2016 at 14:24, Alexander Graf <agraf@suse.de> wrote:
>
>
> 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.
I'm really not sure but I have seen similar things. I will see if I
can figure it out.
Regards,
Simon
^ permalink raw reply
* Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
From: NeilBrown @ 2016-11-14 21:35 UTC (permalink / raw)
To: Mark Brown
Cc: Baolin Wang, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Lee Jones, John Stultz,
Charles Keepax, patches, Linux PM list, USB
In-Reply-To: <20161114120430.hpnetdedyofhlkad@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3323 bytes --]
On Mon, Nov 14 2016, Mark Brown wrote:
> On Mon, Nov 14, 2016 at 03:21:13PM +1100, NeilBrown wrote:
>> On Thu, Nov 10 2016, Baolin Wang wrote:
>
>> > Fourth, we need integrate all charger plugin/out
>> > event in one framework, not from extcon, maybe type-c in future.
>
>> Why not extcon? Given that a charger is connected by an external
>> connector, extcon seems like exactly the right thing to use.
>
>> Obviously extcon doesn't report the current that was negotiated, but
>> that is best kept separate. The battery charger can be advised of the
>> available current either via extcon or separately via the usb
>> subsystem. Don't conflate the two.
>
> Conflating the two seems like the whole point here. We're looking for
> something that sits between the power supply code and the USB code and
> tells the power supply code what it's allowed to do which is the result
> of a combination of physical cable detection and USB protocol. It seems
> reasonable that extcon drivers ought to be part of this but it doesn't
> seem like they are the whole story.
I don't think "between the power supply code and the USB code" is where
this thing sits. I think it sits inside the power-supply driver.
We already have extcon which sits between the phy and the power_supply
code, and the usb_notifier which sits between the USB code and the
power supply code. We don't need another go-between.
If we have extcon able to deliver reliable information about cable type,
and if with have the usb notifier able to deliver reliable information
about negotiated current, and if the power supply manager is able to
register with the correct extcon and the correct usb notifier, then the
power supply manager *could* handle all the notifications and make the
correct determinations and set the current limits itself. All this
could be done entirely internally, without the help of any new
subsystem.
Do you agree?
Clearly doing it that way would result in lots of code duplication and
would mean that each driver probably gets its own private set of bugs,
but it would be possible. Just undesirable.
So yes, it makes perfect to provide common code which handles the
registrations, and captures the events, and translates the different
events into current levels and feeds those back to the driver. This
isn't some new subsystem, this is just a resource, provided by a
library, that power drivers can allocate and initialize if the want to.
To quote myself:
> 5/ Now that all cable connection notifications are sent over extcon and
> all vbus_draw notifications are sent over the usb_phy notifier, write
> some support code that a power supply client can use to be told what
> power is available.
> e.g. a battery charger driver would call:
> register_power_client(.....)
> or similar, providing a phandle (or similar) for the usb phy and a
> function to call back when the available current changes (or maybe a
> work_struct containing the function pointer)
>
> register_power_client() would then register with extcon and separately
> with the usb_phy notifier. When the different events arrive it
> calculates what ranges of currents are expected and calls the
> call-back function with those details.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
From: Pandiyan, Dhinakaran @ 2016-11-14 21:35 UTC (permalink / raw)
To: Navare, Manasi D; +Cc: Nikula, Jani, intel-gfx@lists.freedesktop.org
In-Reply-To: <20161110233256.GA4623@intel.com>
On Thu, 2016-11-10 at 15:32 -0800, Manasi Navare wrote:
> On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > Not validating the the mode rate against link rate results not pruning
> > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> > support 4k @ 60Hz. But, we do not reject this mode currently.
> >
> > So, make use of the helpers in intel_dp in validate mode rates against
> > max. data rate of a configuration.
> >
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 4 ++--
> > drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++++++++++-
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > 3 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 7a9e122..7a73e43 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > return min(source_max, sink_max);
> > }
> >
> > -static int
> > +int
> > intel_dp_link_required(int pixel_clock, int bpp)
> > {
> > /* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> > return (pixel_clock * bpp + 7) / 8;
> > }
> >
> > -static int
> > +int
> > intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> > {
> > /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 3ffbd69..38d2ce0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -335,7 +335,17 @@ static enum drm_mode_status
> > intel_dp_mst_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > {
> > + struct intel_connector *intel_connector = to_intel_connector(connector);
> > + struct intel_dp *intel_dp = intel_connector->mst_port;
> > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > + int link_clock = intel_dp_max_link_rate(intel_dp);
> > + int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > + int bpp = 24; /* MST uses fixed bpp */
> > + int mode_rate;
> > + int link_max_data_rate;
>
> In the SST equivalent mode_valid function, this variable is named as
> max_rate, I think you should name it as max_rate as well for consistency.
> Other than that this looks good, we definitely need this for mode validation
> at an early stage.
>
> Regards
> Manasi
>
Well, one of the goals of Patch 1/2 is to reduce ambiguity that has led
to some confusing hacks. I prefer clarity over consistency and anyway
this variable is local to this function :)
-DK
> > +
> > + link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> > + mode_rate = intel_dp_link_required(mode->clock, bpp);
> >
> > /* TODO - validate mode against available PBN for link */
> > if (mode->clock < 10000)
> > @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> > if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > return MODE_H_ILLEGAL;
> >
> > - if (mode->clock > max_dotclk)
> > + if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
> > return MODE_CLOCK_HIGH;
> >
> > return MODE_OK;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index c2f3863..313419d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > bool __intel_dp_read_desc(struct intel_dp *intel_dp,
> > struct intel_dp_desc *desc);
> > bool intel_dp_read_desc(struct intel_dp *intel_dp);
> > +int intel_dp_link_required(int pixel_clock, int bpp);
> > +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> >
> > /* intel_dp_aux_backlight.c */
> > int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
> > --
> > 2.7.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ 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.