* Patch "ath10k: prevent sta pointer rcu violation" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: michal.kazior, alexander.levin, gregkh, kvalo; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ath10k: prevent sta pointer rcu violation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ath10k-prevent-sta-pointer-rcu-violation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Michal Kazior <michal.kazior@tieto.com>
Date: Thu, 12 Jan 2017 16:14:30 +0100
Subject: ath10k: prevent sta pointer rcu violation
From: Michal Kazior <michal.kazior@tieto.com>
[ Upstream commit 0a744d927406389e00687560d9ce3c5ab0e58db9 ]
Station pointers are RCU protected so driver must
be extra careful if it tries to store them
internally for later use outside of the RCU
section it obtained it in.
It was possible for station teardown to race with
some htt events. The possible outcome could be a
use-after-free and a crash.
Only peer-flow-control capable firmware was
affected (so hardware-wise qca99x0 and qca4019).
This could be done in sta_state() itself via
explicit synchronize_net() call but there's
already a convenient sta_pre_rcu_remove() op that
can be hooked up to avoid extra rcu stall.
The peer->sta pointer itself can't be set to
NULL/ERR_PTR because it is later used in
sta_state() for extra sanity checks.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/mac.c | 18 ++++++++++++++++++
2 files changed, 19 insertions(+)
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -314,6 +314,7 @@ struct ath10k_peer {
struct ieee80211_vif *vif;
struct ieee80211_sta *sta;
+ bool removed;
int vdev_id;
u8 addr[ETH_ALEN];
DECLARE_BITMAP(peer_ids, ATH10K_MAX_NUM_PEER_IDS);
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3738,6 +3738,9 @@ struct ieee80211_txq *ath10k_mac_txq_loo
if (!peer)
return NULL;
+ if (peer->removed)
+ return NULL;
+
if (peer->sta)
return peer->sta->txq[tid];
else if (peer->vif)
@@ -7422,6 +7425,20 @@ ath10k_mac_op_switch_vif_chanctx(struct
return 0;
}
+static void ath10k_mac_op_sta_pre_rcu_remove(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta)
+{
+ struct ath10k *ar;
+ struct ath10k_peer *peer;
+
+ ar = hw->priv;
+
+ list_for_each_entry(peer, &ar->peers, list)
+ if (peer->sta == sta)
+ peer->removed = true;
+}
+
static const struct ieee80211_ops ath10k_ops = {
.tx = ath10k_mac_op_tx,
.wake_tx_queue = ath10k_mac_op_wake_tx_queue,
@@ -7462,6 +7479,7 @@ static const struct ieee80211_ops ath10k
.assign_vif_chanctx = ath10k_mac_op_assign_vif_chanctx,
.unassign_vif_chanctx = ath10k_mac_op_unassign_vif_chanctx,
.switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
+ .sta_pre_rcu_remove = ath10k_mac_op_sta_pre_rcu_remove,
CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
Patches currently in stable-queue which might be from michal.kazior@tieto.com are
queue-4.9/ath10k-prevent-sta-pointer-rcu-violation.patch
^ permalink raw reply
* Patch "audit: log 32-bit socketcalls" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: rgb, alexander.levin, davem, gregkh, paul; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
audit: log 32-bit socketcalls
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
audit-log-32-bit-socketcalls.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Richard Guy Briggs <rgb@redhat.com>
Date: Tue, 17 Jan 2017 11:07:15 -0500
Subject: audit: log 32-bit socketcalls
From: Richard Guy Briggs <rgb@redhat.com>
[ Upstream commit 62bc306e2083436675e33b5bdeb6a77907d35971 ]
32-bit socketcalls were not being logged by audit on x86_64 systems.
Log them. This is basically a duplicate of the call from
net/socket.c:sys_socketcall(), but it addresses the impedance mismatch
between 32-bit userspace process and 64-bit kernel audit.
See: https://github.com/linux-audit/audit-kernel/issues/14
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/audit.h | 20 ++++++++++++++++++++
net/compat.c | 17 ++++++++++++++---
2 files changed, 34 insertions(+), 3 deletions(-)
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -387,6 +387,20 @@ static inline int audit_socketcall(int n
return __audit_socketcall(nargs, args);
return 0;
}
+
+static inline int audit_socketcall_compat(int nargs, u32 *args)
+{
+ unsigned long a[AUDITSC_ARGS];
+ int i;
+
+ if (audit_dummy_context())
+ return 0;
+
+ for (i = 0; i < nargs; i++)
+ a[i] = (unsigned long)args[i];
+ return __audit_socketcall(nargs, a);
+}
+
static inline int audit_sockaddr(int len, void *addr)
{
if (unlikely(!audit_dummy_context()))
@@ -513,6 +527,12 @@ static inline int audit_socketcall(int n
{
return 0;
}
+
+static inline int audit_socketcall_compat(int nargs, u32 *args)
+{
+ return 0;
+}
+
static inline void audit_fd_pair(int fd1, int fd2)
{ }
static inline int audit_sockaddr(int len, void *addr)
--- a/net/compat.c
+++ b/net/compat.c
@@ -22,6 +22,7 @@
#include <linux/filter.h>
#include <linux/compat.h>
#include <linux/security.h>
+#include <linux/audit.h>
#include <linux/export.h>
#include <net/scm.h>
@@ -781,14 +782,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd
COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
{
- int ret;
- u32 a[6];
+ u32 a[AUDITSC_ARGS];
+ unsigned int len;
u32 a0, a1;
+ int ret;
if (call < SYS_SOCKET || call > SYS_SENDMMSG)
return -EINVAL;
- if (copy_from_user(a, args, nas[call]))
+ len = nas[call];
+ if (len > sizeof(a))
+ return -EINVAL;
+
+ if (copy_from_user(a, args, len))
return -EFAULT;
+
+ ret = audit_socketcall_compat(len / sizeof(a[0]), a);
+ if (ret)
+ return ret;
+
a0 = a[0];
a1 = a[1];
Patches currently in stable-queue which might be from rgb@redhat.com are
queue-4.9/audit-log-32-bit-socketcalls.patch
^ permalink raw reply
* Patch "ASoC: dapm: handle probe deferrals" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: linus.walleij, alexander.levin, broonie, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ASoC: dapm: handle probe deferrals
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
asoc-dapm-handle-probe-deferrals.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Linus Walleij <linus.walleij@linaro.org>
Date: Fri, 13 Jan 2017 10:23:52 +0100
Subject: ASoC: dapm: handle probe deferrals
From: Linus Walleij <linus.walleij@linaro.org>
[ Upstream commit 37e1df8c95e2c8a57c77eafc097648f6e40a60ff ]
This starts to handle probe deferrals on regulators and clocks
on the ASoC DAPM.
I came to this patch after audio stopped working on Ux500 ages
ago and I finally looked into it to see what is wrong. I had
messages like this in the console since a while back:
ab8500-codec.0: ASoC: Failed to request audioclk: -517
ab8500-codec.0: ASoC: Failed to create DAPM control audioclk
ab8500-codec.0: Failed to create new controls -12
snd-soc-mop500.0: ASoC: failed to instantiate card -12
snd-soc-mop500.0: Error: snd_soc_register_card failed (-12)!
snd-soc-mop500: probe of snd-soc-mop500.0 failed with error -12
Apparently because the widget table for the codec looks like
this (sound/soc/codecs/ab8500-codec.c):
static const struct snd_soc_dapm_widget ab8500_dapm_widgets[] = {
/* Clocks */
SND_SOC_DAPM_CLOCK_SUPPLY("audioclk"),
/* Regulators */
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AUD", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC1", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC2", 0, 0),
SND_SOC_DAPM_REGULATOR_SUPPLY("V-DMIC", 0, 0),
So when we call snd_soc_register_codec() and any of these widgets
get a deferred probe we do not get an -EPROBE_DEFER (-517) back as
we should and instead we just fail. Apparently the code assumes
that clocks and regulators must be available at this point and
not defer.
After this patch it rather looks like this:
ab8500-codec.0: Failed to create new controls -517
snd-soc-mop500.0: ASoC: failed to instantiate card -517
snd-soc-mop500.0: Error: snd_soc_register_card failed (-517)!
(...)
abx500-clk.0: registered clocks for ab850x
snd-soc-mop500.0: ab8500-codec-dai.0 <-> ux500-msp-i2s.1 mapping ok
snd-soc-mop500.0: ab8500-codec-dai.1 <-> ux500-msp-i2s.3 mapping ok
I'm pretty happy about the patch as it it, but I'm a bit
uncertain on how to proceed: there are a lot of users of the
external functions snd_soc_dapm_new_control() (111 sites)
and that will now return an occassional error pointer, which
is not handled in the calling sites.
I want an indication from the maintainers whether I should just
go in and augment all these call sites, or if deferred probe
is frowned upon when it leads to this much overhead.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/soc-dapm.c | 42 ++++++++++++++++++++++++++++++++++++++++++
sound/soc/soc-topology.c | 9 +++++++++
2 files changed, 51 insertions(+)
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -358,6 +358,10 @@ static int dapm_kcontrol_data_alloc(stru
snd_soc_dapm_new_control_unlocked(widget->dapm,
&template);
kfree(name);
+ if (IS_ERR(data->widget)) {
+ ret = PTR_ERR(data->widget);
+ goto err_data;
+ }
if (!data->widget) {
ret = -ENOMEM;
goto err_data;
@@ -392,6 +396,10 @@ static int dapm_kcontrol_data_alloc(stru
data->widget = snd_soc_dapm_new_control_unlocked(
widget->dapm, &template);
kfree(name);
+ if (IS_ERR(data->widget)) {
+ ret = PTR_ERR(data->widget);
+ goto err_data;
+ }
if (!data->widget) {
ret = -ENOMEM;
goto err_data;
@@ -3311,11 +3319,22 @@ snd_soc_dapm_new_control(struct snd_soc_
mutex_lock_nested(&dapm->card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME);
w = snd_soc_dapm_new_control_unlocked(dapm, widget);
+ /* Do not nag about probe deferrals */
+ if (IS_ERR(w)) {
+ int ret = PTR_ERR(w);
+
+ if (ret != -EPROBE_DEFER)
+ dev_err(dapm->dev,
+ "ASoC: Failed to create DAPM control %s (%d)\n",
+ widget->name, ret);
+ goto out_unlock;
+ }
if (!w)
dev_err(dapm->dev,
"ASoC: Failed to create DAPM control %s\n",
widget->name);
+out_unlock:
mutex_unlock(&dapm->card->dapm_mutex);
return w;
}
@@ -3338,6 +3357,8 @@ snd_soc_dapm_new_control_unlocked(struct
w->regulator = devm_regulator_get(dapm->dev, w->name);
if (IS_ERR(w->regulator)) {
ret = PTR_ERR(w->regulator);
+ if (ret == -EPROBE_DEFER)
+ return ERR_PTR(ret);
dev_err(dapm->dev, "ASoC: Failed to request %s: %d\n",
w->name, ret);
return NULL;
@@ -3356,6 +3377,8 @@ snd_soc_dapm_new_control_unlocked(struct
w->clk = devm_clk_get(dapm->dev, w->name);
if (IS_ERR(w->clk)) {
ret = PTR_ERR(w->clk);
+ if (ret == -EPROBE_DEFER)
+ return ERR_PTR(ret);
dev_err(dapm->dev, "ASoC: Failed to request %s: %d\n",
w->name, ret);
return NULL;
@@ -3474,6 +3497,16 @@ int snd_soc_dapm_new_controls(struct snd
mutex_lock_nested(&dapm->card->dapm_mutex, SND_SOC_DAPM_CLASS_INIT);
for (i = 0; i < num; i++) {
w = snd_soc_dapm_new_control_unlocked(dapm, widget);
+ if (IS_ERR(w)) {
+ ret = PTR_ERR(w);
+ /* Do not nag about probe deferrals */
+ if (ret == -EPROBE_DEFER)
+ break;
+ dev_err(dapm->dev,
+ "ASoC: Failed to create DAPM control %s (%d)\n",
+ widget->name, ret);
+ break;
+ }
if (!w) {
dev_err(dapm->dev,
"ASoC: Failed to create DAPM control %s\n",
@@ -3750,6 +3783,15 @@ int snd_soc_dapm_new_pcm(struct snd_soc_
dev_dbg(card->dev, "ASoC: adding %s widget\n", link_name);
w = snd_soc_dapm_new_control_unlocked(&card->dapm, &template);
+ if (IS_ERR(w)) {
+ ret = PTR_ERR(w);
+ /* Do not nag about probe deferrals */
+ if (ret != -EPROBE_DEFER)
+ dev_err(card->dev,
+ "ASoC: Failed to create %s widget (%d)\n",
+ link_name, ret);
+ goto outfree_kcontrol_news;
+ }
if (!w) {
dev_err(card->dev, "ASoC: Failed to create %s widget\n",
link_name);
--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -1473,6 +1473,15 @@ widget:
widget = snd_soc_dapm_new_control(dapm, &template);
else
widget = snd_soc_dapm_new_control_unlocked(dapm, &template);
+ if (IS_ERR(widget)) {
+ ret = PTR_ERR(widget);
+ /* Do not nag about probe deferrals */
+ if (ret != -EPROBE_DEFER)
+ dev_err(tplg->dev,
+ "ASoC: failed to create widget %s controls (%d)\n",
+ w->name, ret);
+ goto hdr_err;
+ }
if (widget == NULL) {
dev_err(tplg->dev, "ASoC: failed to create widget %s controls\n",
w->name);
Patches currently in stable-queue which might be from linus.walleij@linaro.org are
queue-4.9/asoc-dapm-handle-probe-deferrals.patch
queue-4.9/pinctrl-mvebu-use-seq_puts-in-mvebu_pinconf_group_dbg_show.patch
queue-4.9/asoc-dapm-fix-some-pointer-error-handling.patch
^ permalink raw reply
* Patch "ASoC: wm_adsp: Return an error on write to a disabled volatile control" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: ckeepax, alexander.levin, broonie, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ASoC: wm_adsp: Return an error on write to a disabled volatile control
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
asoc-wm_adsp-return-an-error-on-write-to-a-disabled-volatile-control.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date: Mon, 6 Mar 2017 16:54:33 +0000
Subject: ASoC: wm_adsp: Return an error on write to a disabled volatile control
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
[ Upstream commit 67430a39ca7a6af28aade5acb92d43ee257c1014 ]
Volatile controls should only be accessed when the firmware is active,
currently however writes to these controls will succeed, but the data
will be lost, if the firmware is powered down. Update this behaviour such
that an error is returned the same as it is for reads.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/codecs/wm_adsp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -789,7 +789,10 @@ static int wm_coeff_put(struct snd_kcont
mutex_lock(&ctl->dsp->pwr_lock);
- memcpy(ctl->cache, p, ctl->len);
+ if (ctl->flags & WMFW_CTL_FLAG_VOLATILE)
+ ret = -EPERM;
+ else
+ memcpy(ctl->cache, p, ctl->len);
ctl->set = 1;
if (ctl->enabled && ctl->dsp->running)
@@ -816,6 +819,8 @@ static int wm_coeff_tlv_put(struct snd_k
ctl->set = 1;
if (ctl->enabled && ctl->dsp->running)
ret = wm_coeff_write_control(ctl, ctl->cache, size);
+ else if (ctl->flags & WMFW_CTL_FLAG_VOLATILE)
+ ret = -EPERM;
}
mutex_unlock(&ctl->dsp->pwr_lock);
Patches currently in stable-queue which might be from ckeepax@opensource.wolfsonmicro.com are
queue-4.9/asoc-wm_adsp-return-an-error-on-write-to-a-disabled-volatile-control.patch
^ permalink raw reply
* Patch "ASoC: dapm: fix some pointer error handling" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: linus.walleij, alexander.levin, broonie, dan.carpenter, gregkh
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ASoC: dapm: fix some pointer error handling
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
asoc-dapm-fix-some-pointer-error-handling.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Linus Walleij <linus.walleij@linaro.org>
Date: Fri, 20 Jan 2017 14:07:52 +0100
Subject: ASoC: dapm: fix some pointer error handling
From: Linus Walleij <linus.walleij@linaro.org>
[ Upstream commit 639467c8f26d834c934215e8b59129ce442475fe ]
commit 66feeec9322132689d42723df2537d60f96f8e44
"RFC: ASoC: dapm: handle probe deferrals"
forgot a to update some two sites where the call
was used. The static codechecks quickly found them.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 66feeec93221 ("RFC: ASoC: dapm: handle probe deferrals")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/soc-dapm.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -3843,6 +3843,16 @@ int snd_soc_dapm_new_dai_widgets(struct
template.name);
w = snd_soc_dapm_new_control_unlocked(dapm, &template);
+ if (IS_ERR(w)) {
+ int ret = PTR_ERR(w);
+
+ /* Do not nag about probe deferrals */
+ if (ret != -EPROBE_DEFER)
+ dev_err(dapm->dev,
+ "ASoC: Failed to create %s widget (%d)\n",
+ dai->driver->playback.stream_name, ret);
+ return ret;
+ }
if (!w) {
dev_err(dapm->dev, "ASoC: Failed to create %s widget\n",
dai->driver->playback.stream_name);
@@ -3862,6 +3872,16 @@ int snd_soc_dapm_new_dai_widgets(struct
template.name);
w = snd_soc_dapm_new_control_unlocked(dapm, &template);
+ if (IS_ERR(w)) {
+ int ret = PTR_ERR(w);
+
+ /* Do not nag about probe deferrals */
+ if (ret != -EPROBE_DEFER)
+ dev_err(dapm->dev,
+ "ASoC: Failed to create %s widget (%d)\n",
+ dai->driver->playback.stream_name, ret);
+ return ret;
+ }
if (!w) {
dev_err(dapm->dev, "ASoC: Failed to create %s widget\n",
dai->driver->capture.stream_name);
Patches currently in stable-queue which might be from linus.walleij@linaro.org are
queue-4.9/asoc-dapm-handle-probe-deferrals.patch
queue-4.9/pinctrl-mvebu-use-seq_puts-in-mvebu_pinconf_group_dbg_show.patch
queue-4.9/asoc-dapm-fix-some-pointer-error-handling.patch
^ permalink raw reply
* Re: [PATCH] reset: uniphier: add PXs3 reset data
From: Philipp Zabel @ 2017-10-05 8:30 UTC (permalink / raw)
To: Masahiro Yamada
Cc: devicetree, linux-kernel, Rob Herring, Mark Rutland,
linux-arm-kernel
In-Reply-To: <1507170657-26432-1-git-send-email-yamada.masahiro@socionext.com>
On Thu, 2017-10-05 at 11:30 +0900, Masahiro Yamada wrote:
> Add basic reset data for Socionext's new SoC PXs3.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Thanks, applied to the reset/next branch.
regards
Philipp
> ---
>
> .../devicetree/bindings/reset/uniphier-reset.txt | 3 +++
> drivers/reset/reset-uniphier.c | 26
> ++++++++++++++++++++++
> 2 files changed, 29 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/reset/uniphier-
> reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> index 68a6f48..93efed6 100644
> --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> @@ -13,6 +13,7 @@ Required properties:
> "socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC
> "socionext,uniphier-ld11-reset" - for LD11 SoC
> "socionext,uniphier-ld20-reset" - for LD20 SoC
> + "socionext,uniphier-pxs3-reset" - for PXs3 SoC
> - #reset-cells: should be 1.
>
> Example:
> @@ -44,6 +45,7 @@ Required properties:
> "socionext,uniphier-ld11-mio-reset" - for LD11 SoC (MIO)
> "socionext,uniphier-ld11-sd-reset" - for LD11 SoC (SD)
> "socionext,uniphier-ld20-sd-reset" - for LD20 SoC
> + "socionext,uniphier-pxs3-sd-reset" - for PXs3 SoC
> - #reset-cells: should be 1.
>
> Example:
> @@ -74,6 +76,7 @@ Required properties:
> "socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC
> "socionext,uniphier-ld11-peri-reset" - for LD11 SoC
> "socionext,uniphier-ld20-peri-reset" - for LD20 SoC
> + "socionext,uniphier-pxs3-peri-reset" - for PXs3 SoC
> - #reset-cells: should be 1.
>
> Example:
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-
> uniphier.c
> index bda2dd1..6ed808d 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -114,6 +114,20 @@ static const struct uniphier_reset_data
> uniphier_ld20_sys_reset_data[] = {
> UNIPHIER_RESET_END,
> };
>
> +static const struct uniphier_reset_data
> uniphier_pxs3_sys_reset_data[] = {
> + UNIPHIER_RESETX(2, 0x200c, 0), /* NAND */
> + UNIPHIER_RESETX(4, 0x200c, 2), /* eMMC */
> + UNIPHIER_RESETX(8, 0x200c, 12), /* STDMAC */
> + UNIPHIER_RESETX(12, 0x200c, 4), /* USB30 link
> (GIO0) */
> + UNIPHIER_RESETX(13, 0x200c, 5), /* USB31 link
> (GIO1) */
> + UNIPHIER_RESETX(16, 0x200c, 16), /* USB30-PHY0 */
> + UNIPHIER_RESETX(17, 0x200c, 18), /* USB30-PHY1 */
> + UNIPHIER_RESETX(18, 0x200c, 20), /* USB30-PHY2 */
> + UNIPHIER_RESETX(20, 0x200c, 17), /* USB31-PHY0 */
> + UNIPHIER_RESETX(21, 0x200c, 19), /* USB31-PHY1 */
> + UNIPHIER_RESET_END,
> +};
> +
> /* Media I/O reset data */
> #define UNIPHIER_MIO_RESET_SD(id, ch) \
> UNIPHIER_RESETX((id), 0x110 + 0x200 * (ch), 0)
> @@ -359,6 +373,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> .compatible = "socionext,uniphier-ld20-reset",
> .data = uniphier_ld20_sys_reset_data,
> },
> + {
> + .compatible = "socionext,uniphier-pxs3-reset",
> + .data = uniphier_pxs3_sys_reset_data,
> + },
> /* Media I/O reset, SD reset */
> {
> .compatible = "socionext,uniphier-ld4-mio-reset",
> @@ -392,6 +410,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> .compatible = "socionext,uniphier-ld20-sd-reset",
> .data = uniphier_pro5_sd_reset_data,
> },
> + {
> + .compatible = "socionext,uniphier-pxs3-sd-reset",
> + .data = uniphier_pro5_sd_reset_data,
> + },
> /* Peripheral reset */
> {
> .compatible = "socionext,uniphier-ld4-peri-reset",
> @@ -421,6 +443,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> .compatible = "socionext,uniphier-ld20-peri-reset",
> .data = uniphier_pro4_peri_reset_data,
> },
> + {
> + .compatible = "socionext,uniphier-pxs3-peri-reset",
> + .data = uniphier_pro4_peri_reset_data,
> + },
> /* Analog signal amplifiers reset */
> {
> .compatible = "socionext,uniphier-ld11-adamv-reset",
^ permalink raw reply
* Patch "ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: horms+renesas, alexander.levin, geert+renesas, gregkh
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-dts-r8a7790-use-r-car-gen-2-fallback-binding-for-msiof-nodes.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Simon Horman <horms+renesas@verge.net.au>
Date: Tue, 20 Dec 2016 11:32:39 +0100
Subject: ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for msiof nodes
From: Simon Horman <horms+renesas@verge.net.au>
[ Upstream commit 654450baf2afba86cf328e1849ccac61ec4630af ]
Use recently added R-Car Gen 2 fallback binding for msiof nodes in
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/r8a7790.dtsi | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1493,7 +1493,8 @@
};
msiof0: spi@e6e20000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e20000 0 0x0064>;
interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7790_CLK_MSIOF0>;
@@ -1507,7 +1508,8 @@
};
msiof1: spi@e6e10000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e10000 0 0x0064>;
interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7790_CLK_MSIOF1>;
@@ -1521,7 +1523,8 @@
};
msiof2: spi@e6e00000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6e00000 0 0x0064>;
interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7790_CLK_MSIOF2>;
@@ -1535,7 +1538,8 @@
};
msiof3: spi@e6c90000 {
- compatible = "renesas,msiof-r8a7790";
+ compatible = "renesas,msiof-r8a7790",
+ "renesas,rcar-gen2-msiof";
reg = <0 0xe6c90000 0 0x0064>;
interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7790_CLK_MSIOF3>;
Patches currently in stable-queue which might be from horms+renesas@verge.net.au are
queue-4.9/arm-dts-r8a7790-use-r-car-gen-2-fallback-binding-for-msiof-nodes.patch
^ permalink raw reply
* Patch "arm64: kasan: avoid bad virt_to_pfn()" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: mark.rutland, alexander.levin, catalin.marinas, gregkh, labbott,
will.deacon
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: kasan: avoid bad virt_to_pfn()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-kasan-avoid-bad-virt_to_pfn.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Mark Rutland <mark.rutland@arm.com>
Date: Mon, 6 Mar 2017 19:06:40 +0000
Subject: arm64: kasan: avoid bad virt_to_pfn()
From: Mark Rutland <mark.rutland@arm.com>
[ Upstream commit b0de0ccc8b9edd8846828e0ecdc35deacdf186b0 ]
Booting a v4.11-rc1 kernel with DEBUG_VIRTUAL and KASAN enabled produces
the following splat (trimmed for brevity):
[ 0.000000] virt_to_phys used for non-linear address: ffff200008080000 (0xffff200008080000)
[ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:14 __virt_to_phys+0x48/0x70
[ 0.000000] PC is at __virt_to_phys+0x48/0x70
[ 0.000000] LR is at __virt_to_phys+0x48/0x70
[ 0.000000] Call trace:
[ 0.000000] [<ffff2000080b1ac0>] __virt_to_phys+0x48/0x70
[ 0.000000] [<ffff20000a03b86c>] kasan_init+0x1c0/0x498
[ 0.000000] [<ffff20000a034018>] setup_arch+0x2fc/0x948
[ 0.000000] [<ffff20000a030c68>] start_kernel+0xb8/0x570
[ 0.000000] [<ffff20000a0301e8>] __primary_switched+0x6c/0x74
This is because we use virt_to_pfn() on a kernel image address when
trying to figure out its nid, so that we can allocate its shadow from
the same node.
As with other recent changes, this patch uses lm_alias() to solve this.
We could instead use NUMA_NO_NODE, as x86 does for all shadow
allocations, though we'll likely want the "real" memory shadow to be
backed from its corresponding nid anyway, so we may as well be
consistent and find the nid for the image shadow.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/mm/kasan_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -153,7 +153,7 @@ void __init kasan_init(void)
clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
vmemmap_populate(kimg_shadow_start, kimg_shadow_end,
- pfn_to_nid(virt_to_pfn(_text)));
+ pfn_to_nid(virt_to_pfn(lm_alias(_text))));
/*
* vmemmap_populate() has populated the shadow region that covers the
Patches currently in stable-queue which might be from mark.rutland@arm.com are
queue-4.9/arm64-kasan-avoid-bad-virt_to_pfn.patch
^ permalink raw reply
* Patch "ARM: dts: exynos: Add CPU OPPs for Exynos4412 Prime" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: b.zolnierkie, afaerber, alexander.levin, ben, dianders, gregkh,
krzk, thomas.ab, tjakobi
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: dts: exynos: Add CPU OPPs for Exynos4412 Prime
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-dts-exynos-add-cpu-opps-for-exynos4412-prime.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date: Thu, 29 Dec 2016 14:36:51 +0100
Subject: ARM: dts: exynos: Add CPU OPPs for Exynos4412 Prime
From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
[ Upstream commit 80b7a2e2498bcffb1a79980dfbeb7a1275577b28 ]
Add CPU operating points for Exynos4412 Prime (it supports
additional 1704MHz & 1600MHz OPPs and 1500MHz OPP is just
a regular non-turbo OPP on this SoC). Also update relevant
cooling maps to account for new OPPs.
ODROID-X2/U2/U3 boards use Exynos4412 Prime SoC version so
update their board files accordingly.
Based on Hardkernel's kernel for ODROID-X2/U2/U3 boards.
Cc: Doug Anderson <dianders@chromium.org>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Cc: Ben Gamari <ben@smart-cactus.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +-
arch/arm/boot/dts/exynos4412-odroidx2.dts | 1
arch/arm/boot/dts/exynos4412-prime.dtsi | 41 ++++++++++++++++++++++++
arch/arm/boot/dts/exynos4412.dtsi | 2 -
5 files changed, 48 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -97,11 +97,11 @@
thermal-zones {
cpu_thermal: cpu-thermal {
cooling-maps {
- map0 {
+ cooling_map0: map0 {
/* Corresponds to 800MHz at freq_table */
cooling-device = <&cpu0 7 7>;
};
- map1 {
+ cooling_map1: map1 {
/* Corresponds to 200MHz at freq_table */
cooling-device = <&cpu0 13 13>;
};
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -13,6 +13,7 @@
/dts-v1/;
#include "exynos4412-odroid-common.dtsi"
+#include "exynos4412-prime.dtsi"
/ {
model = "Hardkernel ODROID-U3 board based on Exynos4412";
@@ -47,11 +48,11 @@
cooling-maps {
map0 {
trip = <&cpu_alert1>;
- cooling-device = <&cpu0 7 7>;
+ cooling-device = <&cpu0 9 9>;
};
map1 {
trip = <&cpu_alert2>;
- cooling-device = <&cpu0 13 13>;
+ cooling-device = <&cpu0 15 15>;
};
map2 {
trip = <&cpu_alert0>;
--- a/arch/arm/boot/dts/exynos4412-odroidx2.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx2.dts
@@ -12,6 +12,7 @@
*/
#include "exynos4412-odroidx.dts"
+#include "exynos4412-prime.dtsi"
/ {
model = "Hardkernel ODROID-X2 board based on Exynos4412";
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-prime.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Samsung's Exynos4412 Prime SoC device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Exynos4412 Prime SoC revision supports higher CPU frequencies than
+ * non-Prime version. Therefore we need to update OPPs table and
+ * thermal maps accordingly.
+ */
+
+&cpu0_opp_1500 {
+ /delete-property/turbo-mode;
+};
+
+&cpu0_opp_table {
+ opp@1600000000 {
+ opp-hz = /bits/ 64 <1600000000>;
+ opp-microvolt = <1350000>;
+ clock-latency-ns = <200000>;
+ };
+ opp@1704000000 {
+ opp-hz = /bits/ 64 <1704000000>;
+ opp-microvolt = <1350000>;
+ clock-latency-ns = <200000>;
+ };
+};
+
+&cooling_map0 {
+ cooling-device = <&cpu0 9 9>;
+};
+
+&cooling_map1 {
+ cooling-device = <&cpu0 15 15>;
+};
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -130,7 +130,7 @@
opp-microvolt = <1287500>;
clock-latency-ns = <200000>;
};
- opp@1500000000 {
+ cpu0_opp_1500: opp@1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
Patches currently in stable-queue which might be from b.zolnierkie@samsung.com are
queue-4.9/arm-dts-exynos-add-cpu-opps-for-exynos4412-prime.patch
^ permalink raw reply
* Re: [PATCH] reset: uniphier: add PXs3 reset data
From: Philipp Zabel @ 2017-10-05 8:30 UTC (permalink / raw)
To: Masahiro Yamada
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1507170657-26432-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
On Thu, 2017-10-05 at 11:30 +0900, Masahiro Yamada wrote:
> Add basic reset data for Socionext's new SoC PXs3.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Thanks, applied to the reset/next branch.
regards
Philipp
> ---
>
> .../devicetree/bindings/reset/uniphier-reset.txt | 3 +++
> drivers/reset/reset-uniphier.c | 26
> ++++++++++++++++++++++
> 2 files changed, 29 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/reset/uniphier-
> reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> index 68a6f48..93efed6 100644
> --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> @@ -13,6 +13,7 @@ Required properties:
> "socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC
> "socionext,uniphier-ld11-reset" - for LD11 SoC
> "socionext,uniphier-ld20-reset" - for LD20 SoC
> + "socionext,uniphier-pxs3-reset" - for PXs3 SoC
> - #reset-cells: should be 1.
>
> Example:
> @@ -44,6 +45,7 @@ Required properties:
> "socionext,uniphier-ld11-mio-reset" - for LD11 SoC (MIO)
> "socionext,uniphier-ld11-sd-reset" - for LD11 SoC (SD)
> "socionext,uniphier-ld20-sd-reset" - for LD20 SoC
> + "socionext,uniphier-pxs3-sd-reset" - for PXs3 SoC
> - #reset-cells: should be 1.
>
> Example:
> @@ -74,6 +76,7 @@ Required properties:
> "socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC
> "socionext,uniphier-ld11-peri-reset" - for LD11 SoC
> "socionext,uniphier-ld20-peri-reset" - for LD20 SoC
> + "socionext,uniphier-pxs3-peri-reset" - for PXs3 SoC
> - #reset-cells: should be 1.
>
> Example:
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-
> uniphier.c
> index bda2dd1..6ed808d 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -114,6 +114,20 @@ static const struct uniphier_reset_data
> uniphier_ld20_sys_reset_data[] = {
> UNIPHIER_RESET_END,
> };
>
> +static const struct uniphier_reset_data
> uniphier_pxs3_sys_reset_data[] = {
> + UNIPHIER_RESETX(2, 0x200c, 0), /* NAND */
> + UNIPHIER_RESETX(4, 0x200c, 2), /* eMMC */
> + UNIPHIER_RESETX(8, 0x200c, 12), /* STDMAC */
> + UNIPHIER_RESETX(12, 0x200c, 4), /* USB30 link
> (GIO0) */
> + UNIPHIER_RESETX(13, 0x200c, 5), /* USB31 link
> (GIO1) */
> + UNIPHIER_RESETX(16, 0x200c, 16), /* USB30-PHY0 */
> + UNIPHIER_RESETX(17, 0x200c, 18), /* USB30-PHY1 */
> + UNIPHIER_RESETX(18, 0x200c, 20), /* USB30-PHY2 */
> + UNIPHIER_RESETX(20, 0x200c, 17), /* USB31-PHY0 */
> + UNIPHIER_RESETX(21, 0x200c, 19), /* USB31-PHY1 */
> + UNIPHIER_RESET_END,
> +};
> +
> /* Media I/O reset data */
> #define UNIPHIER_MIO_RESET_SD(id, ch) \
> UNIPHIER_RESETX((id), 0x110 + 0x200 * (ch), 0)
> @@ -359,6 +373,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> .compatible = "socionext,uniphier-ld20-reset",
> .data = uniphier_ld20_sys_reset_data,
> },
> + {
> + .compatible = "socionext,uniphier-pxs3-reset",
> + .data = uniphier_pxs3_sys_reset_data,
> + },
> /* Media I/O reset, SD reset */
> {
> .compatible = "socionext,uniphier-ld4-mio-reset",
> @@ -392,6 +410,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> .compatible = "socionext,uniphier-ld20-sd-reset",
> .data = uniphier_pro5_sd_reset_data,
> },
> + {
> + .compatible = "socionext,uniphier-pxs3-sd-reset",
> + .data = uniphier_pro5_sd_reset_data,
> + },
> /* Peripheral reset */
> {
> .compatible = "socionext,uniphier-ld4-peri-reset",
> @@ -421,6 +443,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> .compatible = "socionext,uniphier-ld20-peri-reset",
> .data = uniphier_pro4_peri_reset_data,
> },
> + {
> + .compatible = "socionext,uniphier-pxs3-peri-reset",
> + .data = uniphier_pro4_peri_reset_data,
> + },
> /* Analog signal amplifiers reset */
> {
> .compatible = "socionext,uniphier-ld11-adamv-reset",
--
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
* [PATCH] reset: uniphier: add PXs3 reset data
From: Philipp Zabel @ 2017-10-05 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1507170657-26432-1-git-send-email-yamada.masahiro@socionext.com>
On Thu, 2017-10-05 at 11:30 +0900, Masahiro Yamada wrote:
> Add basic reset data for Socionext's new SoC PXs3.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Thanks, applied to the reset/next branch.
regards
Philipp
> ---
>
> ?.../devicetree/bindings/reset/uniphier-reset.txt???|??3 +++
> ?drivers/reset/reset-uniphier.c?????????????????????| 26
> ++++++++++++++++++++++
> ?2 files changed, 29 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/reset/uniphier-
> reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> index 68a6f48..93efed6 100644
> --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> @@ -13,6 +13,7 @@ Required properties:
> ?????"socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC
> ?????"socionext,uniphier-ld11-reset" - for LD11 SoC
> ?????"socionext,uniphier-ld20-reset" - for LD20 SoC
> +????"socionext,uniphier-pxs3-reset" - for PXs3 SoC
> ?- #reset-cells: should be 1.
> ?
> ?Example:
> @@ -44,6 +45,7 @@ Required properties:
> ?????"socionext,uniphier-ld11-mio-reset" - for LD11 SoC (MIO)
> ?????"socionext,uniphier-ld11-sd-reset"??- for LD11 SoC (SD)
> ?????"socionext,uniphier-ld20-sd-reset"??- for LD20 SoC
> +????"socionext,uniphier-pxs3-sd-reset"??- for PXs3 SoC
> ?- #reset-cells: should be 1.
> ?
> ?Example:
> @@ -74,6 +76,7 @@ Required properties:
> ?????"socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC
> ?????"socionext,uniphier-ld11-peri-reset" - for LD11 SoC
> ?????"socionext,uniphier-ld20-peri-reset" - for LD20 SoC
> +????"socionext,uniphier-pxs3-peri-reset" - for PXs3 SoC
> ?- #reset-cells: should be 1.
> ?
> ?Example:
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-
> uniphier.c
> index bda2dd1..6ed808d 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -114,6 +114,20 @@ static const struct uniphier_reset_data
> uniphier_ld20_sys_reset_data[] = {
> ? UNIPHIER_RESET_END,
> ?};
> ?
> +static const struct uniphier_reset_data
> uniphier_pxs3_sys_reset_data[] = {
> + UNIPHIER_RESETX(2, 0x200c, 0), /* NAND */
> + UNIPHIER_RESETX(4, 0x200c, 2), /* eMMC */
> + UNIPHIER_RESETX(8, 0x200c, 12), /* STDMAC */
> + UNIPHIER_RESETX(12, 0x200c, 4), /* USB30 link
> (GIO0) */
> + UNIPHIER_RESETX(13, 0x200c, 5), /* USB31 link
> (GIO1) */
> + UNIPHIER_RESETX(16, 0x200c, 16), /* USB30-PHY0 */
> + UNIPHIER_RESETX(17, 0x200c, 18), /* USB30-PHY1 */
> + UNIPHIER_RESETX(18, 0x200c, 20), /* USB30-PHY2 */
> + UNIPHIER_RESETX(20, 0x200c, 17), /* USB31-PHY0 */
> + UNIPHIER_RESETX(21, 0x200c, 19), /* USB31-PHY1 */
> + UNIPHIER_RESET_END,
> +};
> +
> ?/* Media I/O reset data */
> ?#define UNIPHIER_MIO_RESET_SD(id, ch) \
> ? UNIPHIER_RESETX((id), 0x110 + 0x200 * (ch), 0)
> @@ -359,6 +373,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> ? .compatible = "socionext,uniphier-ld20-reset",
> ? .data = uniphier_ld20_sys_reset_data,
> ? },
> + {
> + .compatible = "socionext,uniphier-pxs3-reset",
> + .data = uniphier_pxs3_sys_reset_data,
> + },
> ? /* Media I/O reset, SD reset */
> ? {
> ? .compatible = "socionext,uniphier-ld4-mio-reset",
> @@ -392,6 +410,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> ? .compatible = "socionext,uniphier-ld20-sd-reset",
> ? .data = uniphier_pro5_sd_reset_data,
> ? },
> + {
> + .compatible = "socionext,uniphier-pxs3-sd-reset",
> + .data = uniphier_pro5_sd_reset_data,
> + },
> ? /* Peripheral reset */
> ? {
> ? .compatible = "socionext,uniphier-ld4-peri-reset",
> @@ -421,6 +443,10 @@ static const struct of_device_id
> uniphier_reset_match[] = {
> ? .compatible = "socionext,uniphier-ld20-peri-reset",
> ? .data = uniphier_pro4_peri_reset_data,
> ? },
> + {
> + .compatible = "socionext,uniphier-pxs3-peri-reset",
> + .data = uniphier_pro4_peri_reset_data,
> + },
> ? /* Analog signal amplifiers reset */
> ? {
> ? .compatible = "socionext,uniphier-ld11-adamv-reset",
^ permalink raw reply
* Patch "arm: dts: mt2701: Add subsystem clock controller device nodes" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: jamesjj.liao, alexander.levin, gregkh, matthias.bgg
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm: dts: mt2701: Add subsystem clock controller device nodes
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-dts-mt2701-add-subsystem-clock-controller-device-nodes.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: James Liao <jamesjj.liao@mediatek.com>
Date: Wed, 28 Dec 2016 13:46:45 +0800
Subject: arm: dts: mt2701: Add subsystem clock controller device nodes
From: James Liao <jamesjj.liao@mediatek.com>
[ Upstream commit f235c7e7a75325f28a33559a71f25a0eca6112db ]
Add MT2701 subsystem clock controllers, inlcude mmsys, imgsys,
vdecsys, hifsys, ethsys and bdpsys.
Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/mt2701.dtsi | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -174,4 +174,40 @@
clocks = <&uart_clk>;
status = "disabled";
};
+
+ mmsys: syscon@14000000 {
+ compatible = "mediatek,mt2701-mmsys", "syscon";
+ reg = <0 0x14000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ imgsys: syscon@15000000 {
+ compatible = "mediatek,mt2701-imgsys", "syscon";
+ reg = <0 0x15000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vdecsys: syscon@16000000 {
+ compatible = "mediatek,mt2701-vdecsys", "syscon";
+ reg = <0 0x16000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ hifsys: syscon@1a000000 {
+ compatible = "mediatek,mt2701-hifsys", "syscon";
+ reg = <0 0x1a000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ ethsys: syscon@1b000000 {
+ compatible = "mediatek,mt2701-ethsys", "syscon";
+ reg = <0 0x1b000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ bdpsys: syscon@1c000000 {
+ compatible = "mediatek,mt2701-bdpsys", "syscon";
+ reg = <0 0x1c000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
};
Patches currently in stable-queue which might be from jamesjj.liao@mediatek.com are
queue-4.9/arm-dts-mt2701-add-subsystem-clock-controller-device-nodes.patch
^ permalink raw reply
* Patch "ARM: dts: am335x-chilisom: Wakeup from RTC-only state by power on event" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:29 UTC (permalink / raw)
To: m.niestroj, alexander.levin, gregkh, tony; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: dts: am335x-chilisom: Wakeup from RTC-only state by power on event
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-dts-am335x-chilisom-wakeup-from-rtc-only-state-by-power-on-event.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Marcin Niestroj <m.niestroj@grinn-global.com>
Date: Fri, 9 Dec 2016 12:33:27 +0100
Subject: ARM: dts: am335x-chilisom: Wakeup from RTC-only state by power on event
From: Marcin Niestroj <m.niestroj@grinn-global.com>
[ Upstream commit ca244a83ecc7f0a9242ee2116e622cb6d7ec2a90 ]
On chiliSOM TPS65217 nWAKEUP pin is connected to AM335x internal RTC
EXT_WAKEUP input. In RTC-only state TPS65217 is notifying about power on
events (such as power buton presses) by setting nWAKEUP output
low. After that it waits 5s for proper device boot. Currently it doesn't
happen, as the processor doesn't listen for such events. Consequently
TPS65217 changes state from SLEEP (RTC-only state) to OFF.
Enable EXT_WAKEUP input of AM335x's RTC, so the processor can properly
detect power on events and recover immediately from RTC-only states,
without powering off RTC and losing time.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/am335x-chilisom.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/arm/boot/dts/am335x-chilisom.dtsi
+++ b/arch/arm/boot/dts/am335x-chilisom.dtsi
@@ -124,6 +124,14 @@
&rtc {
system-power-controller;
+
+ pinctrl-0 = <&ext_wakeup>;
+ pinctrl-names = "default";
+
+ ext_wakeup: ext-wakeup {
+ pins = "ext_wakeup0";
+ input-enable;
+ };
};
/* NAND Flash */
Patches currently in stable-queue which might be from m.niestroj@grinn-global.com are
queue-4.9/arm-dts-am335x-chilisom-wakeup-from-rtc-only-state-by-power-on-event.patch
^ permalink raw reply
* Patch "ARM: dts: BCM5301X: Fix memory start address" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:29 UTC (permalink / raw)
To: jon.mason, alexander.levin, f.fainelli, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: dts: BCM5301X: Fix memory start address
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-dts-bcm5301x-fix-memory-start-address.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Jon Mason <jon.mason@broadcom.com>
Date: Wed, 8 Feb 2017 15:37:12 -0500
Subject: ARM: dts: BCM5301X: Fix memory start address
From: Jon Mason <jon.mason@broadcom.com>
[ Upstream commit 88d1fa70c21d7b431386cfe70cdc514d98b0c9c4 ]
Memory starts at 0x80000000, not 0. 0 "works" due to mirrior of the
first 128M of RAM to that address. Anything greater than 128M will
quickly find nothing there. Correcting the starting address has
everything working again.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
Fixes: 7eb05f6d ("ARM: dts: bcm5301x: Add BCM SVK DT files")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/bcm953012k.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/bcm953012k.dts
+++ b/arch/arm/boot/dts/bcm953012k.dts
@@ -48,7 +48,7 @@
};
memory {
- reg = <0x00000000 0x10000000>;
+ reg = <0x80000000 0x10000000>;
};
};
Patches currently in stable-queue which might be from jon.mason@broadcom.com are
queue-4.9/arm-dts-bcm5301x-fix-memory-start-address.patch
^ permalink raw reply
* Patch "ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:29 UTC (permalink / raw)
To: afzal.mohd.ma, alexander.levin, gregkh, rmk+kernel,
vladimir.murzin
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-8635-1-nommu-allow-enabling-remap_vectors_to_ram.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Date: Sat, 7 Jan 2017 17:48:10 +0100
Subject: ARM: 8635/1: nommu: allow enabling REMAP_VECTORS_TO_RAM
From: Afzal Mohammed <afzal.mohd.ma@gmail.com>
[ Upstream commit 8a792e9afbce84a0fdaf213fe42bb97382487094 ]
REMAP_VECTORS_TO_RAM depends on DRAM_BASE, but since DRAM_BASE is a
hex, REMAP_VECTORS_TO_RAM could never get enabled. Also depending on
DRAM_BASE is redundant as whenever REMAP_VECTORS_TO_RAM makes itself
available to Kconfig, DRAM_BASE also is available as the Kconfig
gets sourced on !MMU.
Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/Kconfig-nommu | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/Kconfig-nommu
+++ b/arch/arm/Kconfig-nommu
@@ -34,8 +34,7 @@ config PROCESSOR_ID
used instead of the auto-probing which utilizes the register.
config REMAP_VECTORS_TO_RAM
- bool 'Install vectors to the beginning of RAM' if DRAM_BASE
- depends on DRAM_BASE
+ bool 'Install vectors to the beginning of RAM'
help
The kernel needs to change the hardware exception vectors.
In nommu mode, the hardware exception vectors are normally
Patches currently in stable-queue which might be from afzal.mohd.ma@gmail.com are
queue-4.9/arm-8635-1-nommu-allow-enabling-remap_vectors_to_ram.patch
^ permalink raw reply
* ✓ Fi.CI.BAT: success for drm/i915: Miscellaneous fixes to reduce dependency for I915_MAX_PIPES
From: Patchwork @ 2017-10-05 8:29 UTC (permalink / raw)
To: Mika Kahola; +Cc: intel-gfx
In-Reply-To: <1505375586-23015-1-git-send-email-mika.kahola@intel.com>
== Series Details ==
Series: drm/i915: Miscellaneous fixes to reduce dependency for I915_MAX_PIPES
URL : https://patchwork.freedesktop.org/series/30336/
State : success
== Summary ==
Series 30336v1 drm/i915: Miscellaneous fixes to reduce dependency for I915_MAX_PIPES
https://patchwork.freedesktop.org/api/1.0/series/30336/revisions/1/mbox/
Test gem_exec_suspend:
Subgroup basic-s3:
pass -> DMESG-FAIL (fi-kbl-7560u) fdo#103039
Subgroup basic-s4-devices:
pass -> DMESG-FAIL (fi-kbl-7560u) fdo#102846 +1
Test gem_flink_basic:
Subgroup bad-flink:
pass -> DMESG-WARN (fi-kbl-7560u) fdo#103049 +4
Test drv_module_reload:
Subgroup basic-reload:
pass -> DMESG-WARN (fi-cfl-s) k.org#196765 +1
fdo#103039 https://bugs.freedesktop.org/show_bug.cgi?id=103039
fdo#102846 https://bugs.freedesktop.org/show_bug.cgi?id=102846
fdo#103049 https://bugs.freedesktop.org/show_bug.cgi?id=103049
k.org#196765 https://bugzilla.kernel.org/show_bug.cgi?id=196765
fi-bdw-5557u total:289 pass:268 dwarn:0 dfail:0 fail:0 skip:21 time:457s
fi-bdw-gvtdvm total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:472s
fi-blb-e6850 total:289 pass:224 dwarn:1 dfail:0 fail:0 skip:64 time:394s
fi-bsw-n3050 total:289 pass:243 dwarn:0 dfail:0 fail:0 skip:46 time:563s
fi-bwr-2160 total:289 pass:184 dwarn:0 dfail:0 fail:0 skip:105 time:289s
fi-bxt-dsi total:289 pass:259 dwarn:0 dfail:0 fail:0 skip:30 time:527s
fi-bxt-j4205 total:289 pass:260 dwarn:0 dfail:0 fail:0 skip:29 time:533s
fi-byt-j1900 total:289 pass:254 dwarn:1 dfail:0 fail:0 skip:34 time:549s
fi-byt-n2820 total:289 pass:250 dwarn:1 dfail:0 fail:0 skip:38 time:524s
fi-cfl-s total:289 pass:253 dwarn:4 dfail:0 fail:0 skip:32 time:561s
fi-cnl-y total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:628s
fi-elk-e7500 total:289 pass:230 dwarn:0 dfail:0 fail:0 skip:59 time:440s
fi-glk-1 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:599s
fi-hsw-4770 total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:444s
fi-hsw-4770r total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:420s
fi-ilk-650 total:289 pass:229 dwarn:0 dfail:0 fail:0 skip:60 time:469s
fi-ivb-3520m total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:506s
fi-ivb-3770 total:289 pass:261 dwarn:0 dfail:0 fail:0 skip:28 time:477s
fi-kbl-7500u total:289 pass:264 dwarn:1 dfail:0 fail:0 skip:24 time:508s
fi-kbl-7560u total:125 pass:105 dwarn:5 dfail:2 fail:0 skip:12
fi-kbl-7567u total:289 pass:265 dwarn:4 dfail:0 fail:0 skip:20 time:491s
fi-kbl-r total:289 pass:262 dwarn:0 dfail:0 fail:0 skip:27 time:604s
fi-pnv-d510 total:289 pass:223 dwarn:1 dfail:0 fail:0 skip:65 time:666s
fi-skl-6260u total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:477s
fi-skl-6700hq total:289 pass:263 dwarn:0 dfail:0 fail:0 skip:26 time:658s
fi-skl-6700k total:289 pass:265 dwarn:0 dfail:0 fail:0 skip:24 time:531s
fi-skl-6770hq total:289 pass:269 dwarn:0 dfail:0 fail:0 skip:20 time:518s
fi-skl-gvtdvm total:289 pass:266 dwarn:0 dfail:0 fail:0 skip:23 time:471s
fi-snb-2520m total:289 pass:251 dwarn:0 dfail:0 fail:0 skip:38 time:586s
fi-snb-2600 total:289 pass:250 dwarn:0 dfail:0 fail:0 skip:39 time:432s
247cb84af034b8e90ecd22cd69adb13a7a305350 drm-tip: 2017y-10m-05d-06h-44m-09s UTC integration manifest
8cfe68398c52 drm/i915: Cleanup South Error Interrupts
0d33f4b14e6e drm/i915: Favor for_each_pipe() macro
2186fb8c0912 drm/i915: Fold IRQ pipe masks
9a30dd749459 drm/i915: Remove I915_MAX_PIPES dependency for DDB allocation
c77afd8ee903 drm/i915: Don't relay on I915_MAX_PIPES
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5906/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [BUGFIX PATCH] kprobes/x86: Remove IRQ disabling from jprobe handlers
From: Masami Hiramatsu @ 2017-10-05 8:28 UTC (permalink / raw)
To: Ingo Molnar
Cc: mingo, x86, Steven Rostedt, linux-kernel, Peter Zijlstra,
Ananth N Mavinakayanahalli, Thomas Gleixner, H . Peter Anvin,
Paul E . McKenney, Alexei Starovoitov, Alexei Starovoitov,
Linus Torvalds
In-Reply-To: <20171005075704.2wv3vcg35s4g5jhq@gmail.com>
On Thu, 5 Oct 2017 09:57:04 +0200
Ingo Molnar <mingo@kernel.org> wrote:
>
> * Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> > On Wed, 4 Oct 2017 12:41:01 +0200
> > Ingo Molnar <mingo@kernel.org> wrote:
> >
> > >
> > > * Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > >
> > > > Hmm, actually we can not disable jprobe, that has no separate Kconfig.
> > > > So we need to introduce new kconfig for that.
> > > >
> > > > And, there are several network protocols using jprobe to trace events.
> > > > (e.g. NET_DCCPPROBE and NET_TCPPROBE)
> > > > I think they need to migrate to trace-event at first.
> > > >
> > > > So, how about below idea?
> > > >
> > > > 1. Introduce CONFIG_JPROBE_API which only separate jprobe general parts
> > > > (no arch dependent code involves) and make it default n.
> > > > 2. Mark break_handler and jprobe APIs deprecated so that no new user comes up.
> > > > 3. migrate in-kernel jprobe user to trace-event or ftrace.
> > > > (may take some time)
> > >
> > > So my suggestion would be to just return from register_jprobe() and don't register
> > > anything.
> >
> > with CONFIG_JPROBE_API=n, is that right?
>
> No, unconditionally off with a WARN_ON_ONCE() warning in the registry function and
> the deactivation of all in-kernel uses (such as self-tests).
>
> The point is to make people that _truly_ rely on it complain - not just make them
> silently turn on a Kconfig option ...
Hmm, but in that case, anyway we have to remove or rename the function
like register_jprobe. Or would that "unconditionally" mean "#if 0"?
> > > Yes, there are usecases of jprobes in the kernel, but they all look
> > > pretty ancient and unused.
> >
> > Hmm, in that case, should we also remove those users? If we disable such way
> > those features are just useless.
>
> My hypothesis is that those features are not used (hence useless), but we should
> first test whether there's any reliance before we remove code.
Agreed.
Thank you,
>
> Thanks,
>
> Ingo
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH] pci/uio: enable prefetchable resources mapping
From: Bruce Richardson @ 2017-10-05 8:28 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Changpeng Liu, dev
In-Reply-To: <c401d10c-523a-bb44-6003-3415c0f3ede4@intel.com>
On Thu, Oct 05, 2017 at 01:06:41AM +0100, Ferruh Yigit wrote:
> On 6/3/2017 11:57 PM, Changpeng Liu wrote:
> > For PCI prefetchable resources, Linux will create a
> > write combined file as well, the library will try
> > to map resourceX_wc file first, if the file does
> > not exist, then it will map resourceX as usual.
>
> Hi Changpeng,
>
> Code part looks OK, but can you please describe more why we should try
> write combined resource file first, what is the benefit of using it _wc
> file?
>
> Thanks,
> ferruh
>
Also, if we use a write combining resource file, I believe we will use
correct ordering of instructions within our drivers. Does applying this
patch not also mean that we would need memory barriers inside all the
drivers, so as to ensure that we don't have a queue doorbell write
reordered with the descriptor writes? I don't think it's safe to apply
this change on it's own, without driver changes, since all PMDs assume
strong ordering on IA.
Regards,
/Bruce
>
> >
> > Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
> > ---
> > lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 19 ++++++++++++++-----
> > 1 file changed, 14 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> > index fa10329..d9fc20a 100644
> > --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> > +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> > @@ -321,7 +321,7 @@
> >
> > /* update devname for mmap */
> > snprintf(devname, sizeof(devname),
> > - "%s/" PCI_PRI_FMT "/resource%d",
> > + "%s/" PCI_PRI_FMT "/resource%d_wc",
> > pci_get_sysfs_path(),
> > loc->domain, loc->bus, loc->devid,
> > loc->function, res_idx);
> > @@ -335,13 +335,22 @@
> > }
> >
> > /*
> > - * open resource file, to mmap it
> > + * open prefetchable resource file first, try to mmap it
> > */
> > fd = open(devname, O_RDWR);
> > if (fd < 0) {
> > - RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
> > - devname, strerror(errno));
> > - goto error;
> > + snprintf(devname, sizeof(devname),
> > + "%s/" PCI_PRI_FMT "/resource%d",
> > + pci_get_sysfs_path(),
> > + loc->domain, loc->bus, loc->devid,
> > + loc->function, res_idx);
> > + /* then try to map resource file */
> > + fd = open(devname, O_RDWR);
> > + if (fd < 0) {
> > + RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
> > + devname, strerror(errno));
> > + goto error;
> > + }
> > }
> >
> > /* try mapping somewhere close to the end of hugepages */
> >
>
^ permalink raw reply
* Re: SD card reader problems on Cherry-Trail
From: Carlo Caione @ 2017-10-05 8:26 UTC (permalink / raw)
To: Adrian Hunter; +Cc: Ulf Hansson, linux-mmc
In-Reply-To: <32d4293d-7e9d-8f0d-966f-235a8283182f@intel.com>
On Thu, Oct 5, 2017 at 10:10 AM, Adrian Hunter <adrian.hunter@intel.com> wrote:
> On 05/10/17 10:59, Carlo Caione wrote:
>> On Thu, Oct 5, 2017 at 9:52 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>> + Adrian
>>
>> /cut
>>>> - With high speed SDHC cards I get a weird behavior where apparently
>>>> there is no problem but it's impossible to format the card. mkfs.ext4
>>>> gets stuck at:
>>>>
>>>> Discarding device blocks: 4096/3778299
>>
>> Just discovered that this is just reeeeeally slow, not stuck. Still
>> something is fishy about this.
>>
>> /cut
>>> Looping in Adrian, as he maintains sdhci.
>>>
>>> I guess some more useful information would also be about what commit
>>> you are running and whether this is a regression or not.
>>
>> Yeah, some more info:
>>
>> - Reproduced with the latest master on linus repo (4.14.0-rc3)
>> - No idea if this is a regression or not. This is a new hardware we
>> are trying to enable and I have never seen it working fine (I should
>> blindly try some old kernel)
>> - Windows is working fine so not an HW issue
>> - CPU is x5-Z8350
>
> Can you provide an acpidump?
DSDT https://paste.fedoraproject.org/paste/DXlkVidxM7U9LS2OpqvLGQ/raw
--
Carlo Caione | +39.340.80.30.096 | Endless
^ permalink raw reply
* master - fsadm: add --help
From: Zdenek Kabelac @ 2017-10-05 8:26 UTC (permalink / raw)
To: lvm-devel
Gitweb: https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=3ae8adce928d4ce6ef36c87c2a0bb8aa737346b8
Commit: 3ae8adce928d4ce6ef36c87c2a0bb8aa737346b8
Parent: 9940c2f754e3292b6d96628682c254941ae6cc58
Author: Zdenek Kabelac <zkabelac@redhat.com>
AuthorDate: Thu Oct 5 10:16:20 2017 +0200
Committer: Zdenek Kabelac <zkabelac@redhat.com>
CommitterDate: Thu Oct 5 10:23:20 2017 +0200
fsadm: add --help
Newer version of blockdev tool needs --help as the tool is no longer
printing help without this option like it used to in past.
---
WHATS_NEW | 1 +
scripts/fsadm.sh | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/WHATS_NEW b/WHATS_NEW
index b2037a6..0cdd398 100644
--- a/WHATS_NEW
+++ b/WHATS_NEW
@@ -1,5 +1,6 @@
Version 2.02.175 -
======================================
+ Use --help with blockdev when checking for --getsize64 support in fsadm.
Fix metadata corruption in vgsplit intermediate state.
Require LV name with pvmove in a shared VG.
Allow shared active mirror LVs with lvmlockd, dlm, and cmirrord.
diff --git a/scripts/fsadm.sh b/scripts/fsadm.sh
index 459905f..753da2b 100755
--- a/scripts/fsadm.sh
+++ b/scripts/fsadm.sh
@@ -365,7 +365,7 @@ detect_mounted() {
# get the full size of device in bytes
detect_device_size() {
# check if blockdev supports getsize64
- "$BLOCKDEV" 2>&1 | "$GREP" getsize64 >"$NULL"
+ "$BLOCKDEV" --help 2>&1 | "$GREP" getsize64 >"$NULL"
if test $? -eq 0; then
DEVSIZE=$("$BLOCKDEV" --getsize64 "$VOLUME")
test -n "$DEVSIZE" || error "Cannot read size of device \"$VOLUME\"."
^ permalink raw reply related
* master - dmeventd: schedule exit on break
From: Zdenek Kabelac @ 2017-10-05 8:25 UTC (permalink / raw)
To: lvm-devel
Gitweb: https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=9940c2f754e3292b6d96628682c254941ae6cc58
Commit: 9940c2f754e3292b6d96628682c254941ae6cc58
Parent: a95f656d0df0fb81d68fa27bfee2350953677174
Author: Zdenek Kabelac <zkabelac@redhat.com>
AuthorDate: Wed Oct 4 13:58:21 2017 +0200
Committer: Zdenek Kabelac <zkabelac@redhat.com>
CommitterDate: Thu Oct 5 10:19:21 2017 +0200
dmeventd: schedule exit on break
When dmeventd receives SIGTERM/INT/HUP/QUIT it validates if exit is possible.
If there was any device still monitored, such exit request used to
be ignored/refused. This 'usually' worked reasonably well, however if there
is very short time period between last device is unmonitored and signal
reception - there was possibility such EXIT was ignored, as dmeventd has
not yet got into idle state even commands like 'vgchange -an' has already
finished.
This patch changes logic towards scheduling EXIT to the nearest
point when there is no monitored device.
EXIT is never forgotten.
NOTE: if there is only a single monitored device and someone sends
SIGTERM and later someone uses i.e. 'lvchange --refresh' after
unmonitoring dmeventd will exit and new instance needs to be
started.
---
WHATS_NEW_DM | 1 +
daemons/dmeventd/dmeventd.c | 13 ++++++++-----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/WHATS_NEW_DM b/WHATS_NEW_DM
index 5a11e2e..ea01089 100644
--- a/WHATS_NEW_DM
+++ b/WHATS_NEW_DM
@@ -1,5 +1,6 @@
Version 1.02.144 -
======================================
+ Schedule exit when received SIGTERM in dmeventd.
Also try to unmount /boot on blkdeactivate -u if on top of supported device.
Use blkdeactivate -r wait in blk-availability systemd service/initscript.
Add blkdeactivate -r wait option to wait for MD resync/recovery/reshape.
diff --git a/daemons/dmeventd/dmeventd.c b/daemons/dmeventd/dmeventd.c
index 3a92ab6..cc520d3 100644
--- a/daemons/dmeventd/dmeventd.c
+++ b/daemons/dmeventd/dmeventd.c
@@ -62,6 +62,8 @@
#include <syslog.h>
+#define DM_SIGNALED_EXIT 1
+#define DM_SCHEDULED_EXIT 2
static volatile sig_atomic_t _exit_now = 0; /* set to '1' when signal is given to exit */
/* List (un)link macros. */
@@ -1750,7 +1752,7 @@ static void _init_thread_signals(void)
*/
static void _exit_handler(int sig __attribute__((unused)))
{
- _exit_now = 1;
+ _exit_now = DM_SIGNALED_EXIT;
}
#ifdef __linux__
@@ -2248,6 +2250,8 @@ int main(int argc, char *argv[])
for (;;) {
if (_idle_since) {
if (_exit_now) {
+ if (_exit_now == DM_SCHEDULED_EXIT)
+ break; /* Only prints shutdown message */
log_info("dmeventd detected break while being idle "
"for %ld second(s), exiting.",
(long) (time(NULL) - _idle_since));
@@ -2264,15 +2268,14 @@ int main(int argc, char *argv[])
break;
}
}
- } else if (_exit_now) {
- _exit_now = 0;
+ } else if (_exit_now == DM_SIGNALED_EXIT) {
+ _exit_now = DM_SCHEDULED_EXIT;
/*
* When '_exit_now' is set, signal has been received,
* but can not simply exit unless all
* threads are done processing.
*/
- log_warn("WARNING: There are still devices being monitored.");
- log_warn("WARNING: Refusing to exit.");
+ log_info("dmeventd received break, scheduling exit.");
}
_process_request(&fifos);
_cleanup_unused_threads();
^ permalink raw reply related
* Re: [PATCH 5/6] crypto: talitos - use kzalloc instead of kmalloc
From: Christophe LEROY @ 2017-10-05 8:24 UTC (permalink / raw)
To: linux-crypto, Herbert Xu
In-Reply-To: <0ef5b121c6d362b20d30c8eb37739287a2ee4905.1575825623.git.christophe.leroy@c-s.fr>
Le 21/09/2017 à 09:19, Christophe Leroy a écrit :
> Use kzalloc() to zeroize the extended descriptor at allocation and
> further zeorising
This patch significantly degrades performances.
I will submit a new serie soon.
Christophe
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> drivers/crypto/talitos.c | 23 +----------------------
> drivers/crypto/talitos.h | 2 --
> 2 files changed, 1 insertion(+), 24 deletions(-)
>
> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> index cd8a37e60259..a5b608b54c74 100644
> --- a/drivers/crypto/talitos.c
> +++ b/drivers/crypto/talitos.c
> @@ -75,7 +75,6 @@ static void to_talitos_ptr_len(struct talitos_ptr *ptr, unsigned int len,
> bool is_sec1)
> {
> if (is_sec1) {
> - ptr->res = 0;
> ptr->len1 = cpu_to_be16(len);
> } else {
> ptr->len = cpu_to_be16(len);
> @@ -118,7 +117,6 @@ static void map_single_talitos_ptr(struct device *dev,
>
> to_talitos_ptr_len(ptr, len, is_sec1);
> to_talitos_ptr(ptr, dma_addr, is_sec1);
> - to_talitos_ptr_ext_set(ptr, 0, is_sec1);
> }
>
> /*
> @@ -287,7 +285,6 @@ int talitos_submit(struct device *dev, int ch, struct talitos_desc *desc,
> /* map descriptor and save caller data */
> if (is_sec1) {
> desc->hdr1 = desc->hdr;
> - desc->next_desc = 0;
> request->dma_desc = dma_map_single(dev, &desc->hdr1,
> TALITOS_DESC_SIZE,
> DMA_BIDIRECTIONAL);
> @@ -1099,7 +1096,6 @@ static int sg_to_link_tbl_offset(struct scatterlist *sg, int sg_count,
> to_talitos_ptr(link_tbl_ptr + count,
> sg_dma_address(sg) + offset, 0);
> to_talitos_ptr_len(link_tbl_ptr + count, len, 0);
> - to_talitos_ptr_ext_set(link_tbl_ptr + count, 0, 0);
> count++;
> cryptlen -= len;
> offset = 0;
> @@ -1125,7 +1121,6 @@ int talitos_sg_map(struct device *dev, struct scatterlist *src,
> bool is_sec1 = has_ftr_sec1(priv);
>
> to_talitos_ptr_len(ptr, len, is_sec1);
> - to_talitos_ptr_ext_set(ptr, 0, is_sec1);
>
> if (sg_count == 1) {
> to_talitos_ptr(ptr, sg_dma_address(src) + offset, is_sec1);
> @@ -1197,11 +1192,9 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
> if (desc->hdr & DESC_HDR_TYPE_IPSEC_ESP) {
> to_talitos_ptr(&desc->ptr[2], edesc->iv_dma, is_sec1);
> to_talitos_ptr_len(&desc->ptr[2], ivsize, is_sec1);
> - to_talitos_ptr_ext_set(&desc->ptr[2], 0, is_sec1);
> } else {
> to_talitos_ptr(&desc->ptr[3], edesc->iv_dma, is_sec1);
> to_talitos_ptr_len(&desc->ptr[3], ivsize, is_sec1);
> - to_talitos_ptr_ext_set(&desc->ptr[3], 0, is_sec1);
> }
>
> /* cipher key */
> @@ -1221,7 +1214,6 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
> * typically 12 for ipsec
> */
> to_talitos_ptr_len(&desc->ptr[4], cryptlen, is_sec1);
> - to_talitos_ptr_ext_set(&desc->ptr[4], 0, is_sec1);
>
> sg_link_tbl_len = cryptlen;
>
> @@ -1275,8 +1267,6 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
> to_talitos_ptr(tbl_ptr, edesc->dma_link_tbl + offset,
> is_sec1);
> }
> - } else {
> - edesc->icv_ool = false;
> }
>
> /* ICV data */
> @@ -1386,7 +1376,7 @@ static struct talitos_edesc *talitos_edesc_alloc(struct device *dev,
> alloc_len += icv_stashing ? authsize : 0;
> }
>
> - edesc = kmalloc(alloc_len, GFP_DMA | flags);
> + edesc = kzalloc(alloc_len, GFP_DMA | flags);
> if (!edesc) {
> dev_err(dev, "could not allocate edescriptor\n");
> err = ERR_PTR(-ENOMEM);
> @@ -1467,7 +1457,6 @@ static int aead_decrypt(struct aead_request *req)
> DESC_HDR_MODE1_MDEU_CICV;
>
> /* reset integrity check result bits */
> - edesc->desc.hdr_lo = 0;
>
> return ipsec_esp(edesc, req, ipsec_esp_decrypt_hwauth_done);
> }
> @@ -1554,12 +1543,10 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
> bool is_sec1 = has_ftr_sec1(priv);
>
> /* first DWORD empty */
> - desc->ptr[0] = zero_entry;
>
> /* cipher iv */
> to_talitos_ptr(&desc->ptr[1], edesc->iv_dma, is_sec1);
> to_talitos_ptr_len(&desc->ptr[1], ivsize, is_sec1);
> - to_talitos_ptr_ext_set(&desc->ptr[1], 0, is_sec1);
>
> /* cipher key */
> map_single_talitos_ptr(dev, &desc->ptr[2], ctx->keylen,
> @@ -1598,7 +1585,6 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
> DMA_FROM_DEVICE);
>
> /* last DWORD empty */
> - desc->ptr[6] = zero_entry;
>
> if (sync_needed)
> dma_sync_single_for_device(dev, edesc->dma_link_tbl,
> @@ -1744,7 +1730,6 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
> int sg_count;
>
> /* first DWORD empty */
> - desc->ptr[0] = zero_entry;
>
> /* hash context in */
> if (!req_ctx->first || req_ctx->swinit) {
> @@ -1753,8 +1738,6 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
> (char *)req_ctx->hw_context,
> DMA_TO_DEVICE);
> req_ctx->swinit = 0;
> - } else {
> - desc->ptr[1] = zero_entry;
> }
> /* Indicate next op is not the first. */
> req_ctx->first = 0;
> @@ -1763,8 +1746,6 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
> if (ctx->keylen)
> map_single_talitos_ptr(dev, &desc->ptr[2], ctx->keylen,
> (char *)&ctx->key, DMA_TO_DEVICE);
> - else
> - desc->ptr[2] = zero_entry;
>
> sg_count = edesc->src_nents ?: 1;
> if (is_sec1 && sg_count > 1)
> @@ -1781,7 +1762,6 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
> sync_needed = true;
>
> /* fifth DWORD empty */
> - desc->ptr[4] = zero_entry;
>
> /* hash/HMAC out -or- hash context out */
> if (req_ctx->last)
> @@ -1794,7 +1774,6 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc,
> req_ctx->hw_context, DMA_FROM_DEVICE);
>
> /* last DWORD empty */
> - desc->ptr[6] = zero_entry;
>
> if (is_sec1 && from_talitos_ptr_len(&desc->ptr[3], true) == 0)
> talitos_handle_buggy_hash(ctx, edesc, &desc->ptr[3]);
> diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
> index 8dd8f40e2771..6112ff1fc334 100644
> --- a/drivers/crypto/talitos.h
> +++ b/drivers/crypto/talitos.h
> @@ -52,8 +52,6 @@ struct talitos_ptr {
> __be32 ptr; /* address */
> };
>
> -static const struct talitos_ptr zero_entry;
> -
> /* descriptor */
> struct talitos_desc {
> __be32 hdr; /* header high bits */
>
^ permalink raw reply
* Re: [PATCH v8 0/7] net/i40e: GPT-C and GTP-U enabling
From: Wu, Jingjing @ 2017-10-05 8:23 UTC (permalink / raw)
To: Xing, Beilei; +Cc: Chilikin, Andrey, dev@dpdk.org
In-Reply-To: <1507191297-122088-1-git-send-email-beilei.xing@intel.com>
> -----Original Message-----
> From: Xing, Beilei
> Sent: Thursday, October 5, 2017 4:15 PM
> To: Wu, Jingjing <jingjing.wu@intel.com>
> Cc: Chilikin, Andrey <andrey.chilikin@intel.com>; dev@dpdk.org
> Subject: [PATCH v8 0/7] net/i40e: GPT-C and GTP-U enabling
>
> This patch set enables RSS/FDIR/cloud filter for GPT-C and GTP-U.
>
> v8 changes:
> - Remove 'enable RSS for new pctype' as it can be set with the
> configuration in Kirill's patch.
> - Resolve conflicts.
>
> v7 changes:
> - Distinguish GTP-C request and response message in mbuf description.
> - Clarify GTP-C response message is not supported.
> - Version_type 0x30 is invalid for GTP-C, replace with 0x32.
> - Refine metadata parsing function.
> - Rework for checking fdir programming status.
>
> v6 changes:
> - Reword description of GTP item and GTP structure, mainly support
> GTPv1, not include GTPv0 and GTPv2.
>
> v5 changes:
> - Fix code style.
> - Reword commit log.
>
> v4 changes:
> - Refine fdir related code.
> - Rework profile metadata parsing function.
> - Fix code style.
>
> v3 changes:
> - Rework implementation to support the new profile.
> - Add GTPC and GTPU tunnel type in software packet type parser.
> - Update ptype info when loading profile.
> - Fix bug of updating pctype info.
>
>
> v2 changes:
> - Enable RSS/FDIR/cloud filter dinamicly by checking profile
> - Add GTPC and GTPU items to distinguish rule for GTP-C or GTP-U
> - Rework FDIR/cloud filter enabling function
>
> Beilei Xing (7):
> mbuf: support GTP in software packet type parser
> net/i40e: update ptype and pctype info
> ethdev: add GTP items to support flow API
> net/i40e: finish integration FDIR with generic flow API
> net/i40e: add FDIR support for GTP-C and GTP-U
> net/i40e: add cloud filter parsing function for GTP
> net/i40e: enable cloud filter for GTP-C and GTP-U
>
> app/test-pmd/cmdline_flow.c | 40 ++
> app/test-pmd/config.c | 3 +
> doc/guides/prog_guide/rte_flow.rst | 17 +
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 +
> drivers/net/i40e/i40e_ethdev.c | 505 +++++++++++++++++++++++-
> drivers/net/i40e/i40e_ethdev.h | 156 +++++++-
> drivers/net/i40e/i40e_fdir.c | 585 +++++++++++++++++++++++++++-
> drivers/net/i40e/i40e_flow.c | 503 ++++++++++++++++++++----
> drivers/net/i40e/rte_pmd_i40e.c | 6 +-
> lib/librte_ether/rte_flow.h | 52 +++
> lib/librte_mbuf/rte_mbuf_ptype.c | 2 +
> lib/librte_mbuf/rte_mbuf_ptype.h | 32 ++
> 12 files changed, 1774 insertions(+), 131 deletions(-)
>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
Thanks
Jingjing
^ permalink raw reply
* Re: [PATCH v1] s390/qeth: use kstrtobool() in qeth_bridgeport_hostnotification_store()
From: Julian Wiedmann @ 2017-10-05 8:22 UTC (permalink / raw)
To: Andy Shevchenko, Ursula Braun, Martin Schwidefsky, Heiko Carstens,
linux-s390, David Miller, netdev
In-Reply-To: <20171004133851.18595-1-andriy.shevchenko@linux.intel.com>
On 10/04/2017 03:38 PM, Andy Shevchenko wrote:
> The sysfs enabled value is a boolean, so kstrtobool() is a better fit
> for parsing the input string since it does the range checking for us.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
Thanks Andy, queued up for our next upstream submission.
^ permalink raw reply
* Re: [PATCH BlueZ] gatt: Fix sending indications with proxy
From: Yunhan Wang @ 2017-10-05 8:21 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CALvjcs-EbVqERVoOaHgHXaLKGFY_4P6nY5ZTJ=+Af2+ug21tzQ@mail.gmail.com>
Hi, Luiz
With this change, all are working fine via using AcquireWrite and
AcquireNotify now in my end. I have not yet see any issue so far. Any
other concern or better idea?
Thanks
Best wishes
Yunhan
On Wed, Oct 4, 2017 at 7:55 AM, Yunhan Wang <yunhanw@google.com> wrote:
> Hi, Luiz
>
> On Wed, Oct 4, 2017 at 4:19 AM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi Yunhan,
>>
>> On Tue, Oct 3, 2017 at 9:35 PM, Yunhan Wang <yunhanw@google.com> wrote:
>>> When using AcquireNotify with indication, the proxy needs to be filled in
>>> send_notification_to_devices so as to get indication confirmation in
>>> applciation.
>>> ---
>>> src/gatt-database.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/src/gatt-database.c b/src/gatt-database.c
>>> index 0c84b2569..47304704a 100644
>>> --- a/src/gatt-database.c
>>> +++ b/src/gatt-database.c
>>> @@ -1831,7 +1831,7 @@ static bool pipe_io_read(struct io *io, void *user_data)
>>> buf, bytes_read,
>>> gatt_db_attribute_get_handle(chrc->ccc),
>>> chrc->props & BT_GATT_CHRC_PROP_INDICATE,
>>> - NULL);
>>> + chrc->proxy);
>>>
>>> return true;
>>> }
>>> --
>>> 2.14.2.822.g60be5d43e6-goog
>>
>> Im not sure this the correct fix, the reason why the proxy is NULL is
>> because the fd is being used for io, though the confirmation has no
>> effect on the flow control Id expect some inband signalling in this
>> case but that might actually require something like a socketpair in
>> order to be able to write confirmation back.
>>
> I think pipe_io_read should be pretty similar to property_changed_cb
> in https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n2103,
> both are used to handle the written value from application. Therefore,
> send_notification_to_devices should be fine here with proxy. For
> "socketpair", I guess you concern is Confirm? If Confirm is defined in
> application, then confirmation should be able to be sent back to
> application. If Confirm is not defined, it should be also fine in
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-database.c#n883.
>> --
>> Luiz Augusto von Dentz
>
> Thanks
> Best wishes
> Yunhan
^ 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.