* Re: [libnftnl PATCH] src: Fix nftnl_assert() on data_len
From: Pablo Neira Ayuso @ 2020-02-14 17:32 UTC (permalink / raw)
To: Phil Sutter; +Cc: netfilter-devel
In-Reply-To: <20200214172417.11217-1-phil@nwl.cc>
On Fri, Feb 14, 2020 at 06:24:17PM +0100, Phil Sutter wrote:
> Typical idiom for *_get_u*() getters is to call *_get_data() and make
> sure data_len matches what each of them is returning. Yet they shouldn't
> trust *_get_data() to write into passed pointer to data_len since for
> chains and NFTNL_CHAIN_DEVICES attribute, it does not. Make sure these
> assert() calls trigger in those cases.
The intention to catch for unset attributes through the assertion,
right?
^ permalink raw reply
* [PATCH AUTOSEL 5.4 227/459] bpf: Print error message for bpftool cgroup show
From: Sasha Levin @ 2020-02-14 15:57 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Hechao Li, Daniel Borkmann, Sasha Levin, netdev, bpf
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Hechao Li <hechaol@fb.com>
[ Upstream commit 1162f844030ac1ac7321b5e8f6c9badc7a11428f ]
Currently, when bpftool cgroup show <path> has an error, no error
message is printed. This is confusing because the user may think the
result is empty.
Before the change:
$ bpftool cgroup show /sys/fs/cgroup
ID AttachType AttachFlags Name
$ echo $?
255
After the change:
$ ./bpftool cgroup show /sys/fs/cgroup
Error: can't query bpf programs attached to /sys/fs/cgroup: Operation
not permitted
v2: Rename check_query_cgroup_progs to cgroup_has_attached_progs
Signed-off-by: Hechao Li <hechaol@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20191224011742.3714301-1-hechaol@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/bpf/bpftool/cgroup.c | 56 ++++++++++++++++++++++++++------------
1 file changed, 39 insertions(+), 17 deletions(-)
diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
index 1ef45e55039e1..2f017caa678dc 100644
--- a/tools/bpf/bpftool/cgroup.c
+++ b/tools/bpf/bpftool/cgroup.c
@@ -117,6 +117,25 @@ static int count_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type)
return prog_cnt;
}
+static int cgroup_has_attached_progs(int cgroup_fd)
+{
+ enum bpf_attach_type type;
+ bool no_prog = true;
+
+ for (type = 0; type < __MAX_BPF_ATTACH_TYPE; type++) {
+ int count = count_attached_bpf_progs(cgroup_fd, type);
+
+ if (count < 0 && errno != EINVAL)
+ return -1;
+
+ if (count > 0) {
+ no_prog = false;
+ break;
+ }
+ }
+
+ return no_prog ? 0 : 1;
+}
static int show_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
int level)
{
@@ -161,6 +180,7 @@ static int show_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type,
static int do_show(int argc, char **argv)
{
enum bpf_attach_type type;
+ int has_attached_progs;
const char *path;
int cgroup_fd;
int ret = -1;
@@ -192,6 +212,16 @@ static int do_show(int argc, char **argv)
goto exit;
}
+ has_attached_progs = cgroup_has_attached_progs(cgroup_fd);
+ if (has_attached_progs < 0) {
+ p_err("can't query bpf programs attached to %s: %s",
+ path, strerror(errno));
+ goto exit_cgroup;
+ } else if (!has_attached_progs) {
+ ret = 0;
+ goto exit_cgroup;
+ }
+
if (json_output)
jsonw_start_array(json_wtr);
else
@@ -212,6 +242,7 @@ static int do_show(int argc, char **argv)
if (json_output)
jsonw_end_array(json_wtr);
+exit_cgroup:
close(cgroup_fd);
exit:
return ret;
@@ -228,7 +259,7 @@ static int do_show_tree_fn(const char *fpath, const struct stat *sb,
int typeflag, struct FTW *ftw)
{
enum bpf_attach_type type;
- bool skip = true;
+ int has_attached_progs;
int cgroup_fd;
if (typeflag != FTW_D)
@@ -240,22 +271,13 @@ static int do_show_tree_fn(const char *fpath, const struct stat *sb,
return SHOW_TREE_FN_ERR;
}
- for (type = 0; type < __MAX_BPF_ATTACH_TYPE; type++) {
- int count = count_attached_bpf_progs(cgroup_fd, type);
-
- if (count < 0 && errno != EINVAL) {
- p_err("can't query bpf programs attached to %s: %s",
- fpath, strerror(errno));
- close(cgroup_fd);
- return SHOW_TREE_FN_ERR;
- }
- if (count > 0) {
- skip = false;
- break;
- }
- }
-
- if (skip) {
+ has_attached_progs = cgroup_has_attached_progs(cgroup_fd);
+ if (has_attached_progs < 0) {
+ p_err("can't query bpf programs attached to %s: %s",
+ fpath, strerror(errno));
+ close(cgroup_fd);
+ return SHOW_TREE_FN_ERR;
+ } else if (!has_attached_progs) {
close(cgroup_fd);
return 0;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 228/459] net: phy: realtek: add logging for the RGMII TX delay configuration
From: Sasha Levin @ 2020-02-14 15:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Martin Blumenstingl, Florian Fainelli, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
[ Upstream commit 3aec743d69822d22d4a5b60deb9518ed8be6fa67 ]
RGMII requires a delay of 2ns between the data and the clock signal.
There are at least three ways this can happen. One possibility is by
having the PHY generate this delay.
This is a common source for problems (for example with slow TX speeds or
packet loss when sending data). The TX delay configuration of the
RTL8211F PHY can be set either by pin-strappping the RXD1 pin (HIGH
means enabled, LOW means disabled) or through configuring a paged
register. The setting from the RXD1 pin is also reflected in the
register.
Add debug logging to the TX delay configuration on RTL8211F so it's
easier to spot these issues (for example if the TX delay is enabled for
both, the RTL8211F PHY and the MAC).
This is especially helpful because there is no public datasheet for the
RTL8211F PHY available with all the RX/TX delay specifics.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/phy/realtek.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 677c45985338a..c76df51dd3c51 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -171,7 +171,9 @@ static int rtl8211c_config_init(struct phy_device *phydev)
static int rtl8211f_config_init(struct phy_device *phydev)
{
+ struct device *dev = &phydev->mdio.dev;
u16 val;
+ int ret;
/* enable TX-delay for rgmii-{id,txid}, and disable it for rgmii and
* rgmii-rxid. The RX-delay can be enabled by the external RXDLY pin.
@@ -189,7 +191,22 @@ static int rtl8211f_config_init(struct phy_device *phydev)
return 0;
}
- return phy_modify_paged(phydev, 0xd08, 0x11, RTL8211F_TX_DELAY, val);
+ ret = phy_modify_paged_changed(phydev, 0xd08, 0x11, RTL8211F_TX_DELAY,
+ val);
+ if (ret < 0) {
+ dev_err(dev, "Failed to update the TX delay register\n");
+ return ret;
+ } else if (ret) {
+ dev_dbg(dev,
+ "%s 2ns TX delay (and changing the value from pin-strapping RXD1 or the bootloader)\n",
+ val ? "Enabling" : "Disabling");
+ } else {
+ dev_dbg(dev,
+ "2ns TX delay was already %s (by pin-strapping RXD1 or bootloader configuration)\n",
+ val ? "enabled" : "disabled");
+ }
+
+ return 0;
}
static int rtl8211e_config_init(struct phy_device *phydev)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 229/459] crypto: chtls - Fixed memory leak
From: Sasha Levin @ 2020-02-14 15:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vinay Kumar Yadav, Herbert Xu, Sasha Levin, linux-crypto
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
[ Upstream commit 93e23eb2ed6c11b4f483c8111ac155ec2b1f3042 ]
Freed work request skbs when connection terminates.
enqueue_wr()/ dequeue_wr() is shared between softirq
and application contexts, should be protected by socket
lock. Moved dequeue_wr() to appropriate file.
Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/crypto/chelsio/chtls/chtls_cm.c | 27 +++++++++++++------------
drivers/crypto/chelsio/chtls/chtls_cm.h | 21 +++++++++++++++++++
drivers/crypto/chelsio/chtls/chtls_hw.c | 3 +++
3 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/drivers/crypto/chelsio/chtls/chtls_cm.c b/drivers/crypto/chelsio/chtls/chtls_cm.c
index aca75237bbcf8..dffa2aa855fdd 100644
--- a/drivers/crypto/chelsio/chtls/chtls_cm.c
+++ b/drivers/crypto/chelsio/chtls/chtls_cm.c
@@ -727,6 +727,14 @@ static int chtls_close_listsrv_rpl(struct chtls_dev *cdev, struct sk_buff *skb)
return 0;
}
+static void chtls_purge_wr_queue(struct sock *sk)
+{
+ struct sk_buff *skb;
+
+ while ((skb = dequeue_wr(sk)) != NULL)
+ kfree_skb(skb);
+}
+
static void chtls_release_resources(struct sock *sk)
{
struct chtls_sock *csk = rcu_dereference_sk_user_data(sk);
@@ -741,6 +749,11 @@ static void chtls_release_resources(struct sock *sk)
kfree_skb(csk->txdata_skb_cache);
csk->txdata_skb_cache = NULL;
+ if (csk->wr_credits != csk->wr_max_credits) {
+ chtls_purge_wr_queue(sk);
+ chtls_reset_wr_list(csk);
+ }
+
if (csk->l2t_entry) {
cxgb4_l2t_release(csk->l2t_entry);
csk->l2t_entry = NULL;
@@ -1735,6 +1748,7 @@ static void chtls_peer_close(struct sock *sk, struct sk_buff *skb)
else
sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_IN);
}
+ kfree_skb(skb);
}
static void chtls_close_con_rpl(struct sock *sk, struct sk_buff *skb)
@@ -2062,19 +2076,6 @@ static int chtls_conn_cpl(struct chtls_dev *cdev, struct sk_buff *skb)
return 0;
}
-static struct sk_buff *dequeue_wr(struct sock *sk)
-{
- struct chtls_sock *csk = rcu_dereference_sk_user_data(sk);
- struct sk_buff *skb = csk->wr_skb_head;
-
- if (likely(skb)) {
- /* Don't bother clearing the tail */
- csk->wr_skb_head = WR_SKB_CB(skb)->next_wr;
- WR_SKB_CB(skb)->next_wr = NULL;
- }
- return skb;
-}
-
static void chtls_rx_ack(struct sock *sk, struct sk_buff *skb)
{
struct cpl_fw4_ack *hdr = cplhdr(skb) + RSS_HDR;
diff --git a/drivers/crypto/chelsio/chtls/chtls_cm.h b/drivers/crypto/chelsio/chtls/chtls_cm.h
index 129d7ac649a93..3fac0c74a41fa 100644
--- a/drivers/crypto/chelsio/chtls/chtls_cm.h
+++ b/drivers/crypto/chelsio/chtls/chtls_cm.h
@@ -185,6 +185,12 @@ static inline void chtls_kfree_skb(struct sock *sk, struct sk_buff *skb)
kfree_skb(skb);
}
+static inline void chtls_reset_wr_list(struct chtls_sock *csk)
+{
+ csk->wr_skb_head = NULL;
+ csk->wr_skb_tail = NULL;
+}
+
static inline void enqueue_wr(struct chtls_sock *csk, struct sk_buff *skb)
{
WR_SKB_CB(skb)->next_wr = NULL;
@@ -197,4 +203,19 @@ static inline void enqueue_wr(struct chtls_sock *csk, struct sk_buff *skb)
WR_SKB_CB(csk->wr_skb_tail)->next_wr = skb;
csk->wr_skb_tail = skb;
}
+
+static inline struct sk_buff *dequeue_wr(struct sock *sk)
+{
+ struct chtls_sock *csk = rcu_dereference_sk_user_data(sk);
+ struct sk_buff *skb = NULL;
+
+ skb = csk->wr_skb_head;
+
+ if (likely(skb)) {
+ /* Don't bother clearing the tail */
+ csk->wr_skb_head = WR_SKB_CB(skb)->next_wr;
+ WR_SKB_CB(skb)->next_wr = NULL;
+ }
+ return skb;
+}
#endif
diff --git a/drivers/crypto/chelsio/chtls/chtls_hw.c b/drivers/crypto/chelsio/chtls/chtls_hw.c
index 2a34035d3cfbc..a217fe72602d4 100644
--- a/drivers/crypto/chelsio/chtls/chtls_hw.c
+++ b/drivers/crypto/chelsio/chtls/chtls_hw.c
@@ -350,6 +350,7 @@ int chtls_setkey(struct chtls_sock *csk, u32 keylen, u32 optname)
kwr->sc_imm.cmd_more = cpu_to_be32(ULPTX_CMD_V(ULP_TX_SC_IMM));
kwr->sc_imm.len = cpu_to_be32(klen);
+ lock_sock(sk);
/* key info */
kctx = (struct _key_ctx *)(kwr + 1);
ret = chtls_key_info(csk, kctx, keylen, optname);
@@ -388,8 +389,10 @@ int chtls_setkey(struct chtls_sock *csk, u32 keylen, u32 optname)
csk->tlshws.txkey = keyid;
}
+ release_sock(sk);
return ret;
out_notcb:
+ release_sock(sk);
free_tls_keyid(sk);
out_nokey:
kfree_skb(skb);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 230/459] net/wan/fsl_ucc_hdlc: remove set but not used variables 'ut_info' and 'ret'
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Chen Zhou, Hulk Robot, David S . Miller, Sasha Levin, netdev,
linuxppc-dev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Chen Zhou <chenzhou10@huawei.com>
[ Upstream commit 270fe2ceda66b6964d4c6f261d7f562a02c1c786 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wan/fsl_ucc_hdlc.c: In function ucc_hdlc_irq_handler:
drivers/net/wan/fsl_ucc_hdlc.c:643:23:
warning: variable ut_info set but not used [-Wunused-but-set-variable]
drivers/net/wan/fsl_ucc_hdlc.c: In function uhdlc_suspend:
drivers/net/wan/fsl_ucc_hdlc.c:880:23:
warning: variable ut_info set but not used [-Wunused-but-set-variable]
drivers/net/wan/fsl_ucc_hdlc.c: In function uhdlc_resume:
drivers/net/wan/fsl_ucc_hdlc.c:925:6:
warning: variable ret set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wan/fsl_ucc_hdlc.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 4ad0a0c33d853..607cb1edff964 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -640,11 +640,9 @@ static irqreturn_t ucc_hdlc_irq_handler(int irq, void *dev_id)
struct ucc_hdlc_private *priv = (struct ucc_hdlc_private *)dev_id;
struct net_device *dev = priv->ndev;
struct ucc_fast_private *uccf;
- struct ucc_tdm_info *ut_info;
u32 ucce;
u32 uccm;
- ut_info = priv->ut_info;
uccf = priv->uccf;
ucce = ioread32be(uccf->p_ucce);
@@ -877,7 +875,6 @@ static void resume_clk_config(struct ucc_hdlc_private *priv)
static int uhdlc_suspend(struct device *dev)
{
struct ucc_hdlc_private *priv = dev_get_drvdata(dev);
- struct ucc_tdm_info *ut_info;
struct ucc_fast __iomem *uf_regs;
if (!priv)
@@ -889,7 +886,6 @@ static int uhdlc_suspend(struct device *dev)
netif_device_detach(priv->ndev);
napi_disable(&priv->napi);
- ut_info = priv->ut_info;
uf_regs = priv->uf_regs;
/* backup gumr guemr*/
@@ -922,7 +918,7 @@ static int uhdlc_resume(struct device *dev)
struct ucc_fast __iomem *uf_regs;
struct ucc_fast_private *uccf;
struct ucc_fast_info *uf_info;
- int ret, i;
+ int i;
u32 cecr_subblock;
u16 bd_status;
@@ -967,16 +963,16 @@ static int uhdlc_resume(struct device *dev)
/* Write to QE CECR, UCCx channel to Stop Transmission */
cecr_subblock = ucc_fast_get_qe_cr_subblock(uf_info->ucc_num);
- ret = qe_issue_cmd(QE_STOP_TX, cecr_subblock,
- (u8)QE_CR_PROTOCOL_UNSPECIFIED, 0);
+ qe_issue_cmd(QE_STOP_TX, cecr_subblock,
+ (u8)QE_CR_PROTOCOL_UNSPECIFIED, 0);
/* Set UPSMR normal mode */
iowrite32be(0, &uf_regs->upsmr);
/* init parameter base */
cecr_subblock = ucc_fast_get_qe_cr_subblock(uf_info->ucc_num);
- ret = qe_issue_cmd(QE_ASSIGN_PAGE_TO_DEVICE, cecr_subblock,
- QE_CR_PROTOCOL_UNSPECIFIED, priv->ucc_pram_offset);
+ qe_issue_cmd(QE_ASSIGN_PAGE_TO_DEVICE, cecr_subblock,
+ QE_CR_PROTOCOL_UNSPECIFIED, priv->ucc_pram_offset);
priv->ucc_pram = (struct ucc_hdlc_param __iomem *)
qe_muram_addr(priv->ucc_pram_offset);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 232/459] PM / devfreq: exynos-ppmu: Fix excessive stack usage
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Arnd Bergmann, Chanwoo Choi, Sasha Levin, linux-pm,
linux-arm-kernel, linux-samsung-soc
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit d4556f5e99d5f603913bac01adaff8670cb2d08b ]
Putting a 'struct devfreq_event_dev' object on the stack is generally
a bad idea and here it leads to a warnig about potential stack overflow:
drivers/devfreq/event/exynos-ppmu.c:643:12: error: stack frame size of 1040 bytes in function 'exynos_ppmu_probe' [-Werror,-Wframe-larger-than=]
There is no real need for the device structure, only the string inside
it, so add an internal helper function that simply takes the string
as its argument and remove the device structure.
Fixes: 1dd62c66d345 ("PM / devfreq: events: extend events by type of counted data")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[cw00.choi: Fix the issue from 'desc->name' to 'desc[j].name']
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/devfreq/event/exynos-ppmu.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/devfreq/event/exynos-ppmu.c b/drivers/devfreq/event/exynos-ppmu.c
index 87b42055e6bc9..c4873bb791f88 100644
--- a/drivers/devfreq/event/exynos-ppmu.c
+++ b/drivers/devfreq/event/exynos-ppmu.c
@@ -101,17 +101,22 @@ static struct __exynos_ppmu_events {
PPMU_EVENT(dmc1_1),
};
-static int exynos_ppmu_find_ppmu_id(struct devfreq_event_dev *edev)
+static int __exynos_ppmu_find_ppmu_id(const char *edev_name)
{
int i;
for (i = 0; i < ARRAY_SIZE(ppmu_events); i++)
- if (!strcmp(edev->desc->name, ppmu_events[i].name))
+ if (!strcmp(edev_name, ppmu_events[i].name))
return ppmu_events[i].id;
return -EINVAL;
}
+static int exynos_ppmu_find_ppmu_id(struct devfreq_event_dev *edev)
+{
+ return __exynos_ppmu_find_ppmu_id(edev->desc->name);
+}
+
/*
* The devfreq-event ops structure for PPMU v1.1
*/
@@ -556,13 +561,11 @@ static int of_get_devfreq_events(struct device_node *np,
* use default if not.
*/
if (info->ppmu_type == EXYNOS_TYPE_PPMU_V2) {
- struct devfreq_event_dev edev;
int id;
/* Not all registers take the same value for
* read+write data count.
*/
- edev.desc = &desc[j];
- id = exynos_ppmu_find_ppmu_id(&edev);
+ id = __exynos_ppmu_find_ppmu_id(desc[j].name);
switch (id) {
case PPMU_PMNCNT0:
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 233/459] PM / devfreq: rk3399_dmc: Add COMPILE_TEST and HAVE_ARM_SMCCC dependency
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Chanwoo Choi, kbuild test robot, Sasha Levin, linux-pm
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Chanwoo Choi <cw00.choi@samsung.com>
[ Upstream commit eff5d31f7407fa9d31fb840106f1593399457298 ]
To build test, add COMPILE_TEST depedency to both ARM_RK3399_DMC_DEVFREQ
and DEVFREQ_EVENT_ROCKCHIP_DFI configuration. And ARM_RK3399_DMC_DEVFREQ
used the SMCCC interface so that add HAVE_ARM_SMCCC dependency to prevent
the build break.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/devfreq/Kconfig | 3 ++-
drivers/devfreq/event/Kconfig | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index af4a3ccb96b34..1433f2ba9d3b1 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -118,7 +118,8 @@ config ARM_TEGRA20_DEVFREQ
config ARM_RK3399_DMC_DEVFREQ
tristate "ARM RK3399 DMC DEVFREQ Driver"
- depends on ARCH_ROCKCHIP
+ depends on (ARCH_ROCKCHIP && HAVE_ARM_SMCCC) || \
+ (COMPILE_TEST && HAVE_ARM_SMCCC)
select DEVFREQ_EVENT_ROCKCHIP_DFI
select DEVFREQ_GOV_SIMPLE_ONDEMAND
select PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index cef2cf5347ca7..a53e0a6ffdfeb 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -34,7 +34,7 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
config DEVFREQ_EVENT_ROCKCHIP_DFI
tristate "ROCKCHIP DFI DEVFREQ event Driver"
- depends on ARCH_ROCKCHIP
+ depends on ARCH_ROCKCHIP || COMPILE_TEST
help
This add the devfreq-event driver for Rockchip SoC. It provides DFI
(DDR Monitor Module) driver to count ddr load.
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v7 00/15] add git-bugreport tool
From: Junio C Hamano @ 2020-02-14 17:32 UTC (permalink / raw)
To: Emily Shaffer
Cc: git, Derrick Stolee, Johannes Schindelin, Martin Ågren,
Aaron Schrab, Danh Doan, Eric Sunshine, SZEDER Gábor,
Andreas Schwab
In-Reply-To: <20200214015343.201946-1-emilyshaffer@google.com>
Emily Shaffer <emilyshaffer@google.com> writes:
> present(patch 9/15). This now uses POSIX character classes and {}
> notation instead of + and has been tested on OSX; I'd love to hear if
I'd rather not to see unnecessary uses of POSIX character classes.
The interdiff of this step between the previous and this round looks
to me more like "I used it, just because POSIX says I *can* use it",
not "I did so because I needed to do, and it should be OK on POSIX
platforms."
Instead of overly long
's/^\([^[:blank:]]*\)[[:blank:]]\{1,\}annotate:bugreport\[include\].* ::$/ "\1",/p'
just limiting ourselves to SP and saying
's/^\([^ ]*\) *annotate:bugreport\[include\].* ::$/ "\1",/p'
would keep the result much easier to read, I would think.
^ permalink raw reply
* Re: Readiness for 14.2.8 ?
From: Yuri Weinstein @ 2020-02-14 17:31 UTC (permalink / raw)
To: Yuri Weinstein, dev, Development, Ceph, Abhishek Lekshmanan,
Nathan Cutler, Casey Bodley, Patrick Donnelly, Neha Ojha,
Durgin, Josh, David Zafman, Weil, Sage, Ramana Venkatesh Raja,
Tamilarasi Muthamizhan, Dillaman, Jason, Sadeh-Weinraub, Yehuda,
Lekshmanan, Abhishek, Ilya Dryomov, Jeff Layton, ceph-qe-team,
Andrew Schoen
In-Reply-To: <CAMMFjmGDBQf+K5K2Zz4e6-PJS=y1YoUAEm5_X0tTUTre3EmZgA@mail.gmail.com>
corrected back to 14.2.8
On Fri, Feb 14, 2020 at 9:25 AM Yuri Weinstein <yweinste@redhat.com> wrote:
>
> Thank you !
>
> Correction - the subject line should say 14.2.7
>
> On Fri, Feb 14, 2020 at 9:19 AM Jan Fajerski <jfajerski@suse.com> wrote:
> >
> > On Mon, Feb 10, 2020 at 11:57:19AM -0800, Yuri Weinstein wrote:
> > >Below is the current queue of PRs:
> > >https://github.com/ceph/ceph/pulls?page=2&q=is%3Aopen+label%3Anautilus-batch-1+label%3Aneeds-qa
> > >
> > >Most PRs are being tested.
> > >Unless there are objections, we will start QE validation as soon as
> > >all PRs in this queue were merged.
> > >
> > >Dev leads - pls add and tag all RRs that must be included.
> > ceph-volume is ready, al backports are merged and tested (thank you Nathan!).
> > >
> > >Thx
> > >YuriW
> > >
> >
> > --
> > Jan Fajerski
> > Senior Software Engineer Enterprise Storage
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > (HRB 36809, AG Nürnberg)
> > Geschäftsführer: Felix Imendörffer
> >
^ permalink raw reply
* [PATCH AUTOSEL 5.4 235/459] pinctrl: sh-pfc: r8a7778: Fix duplicate SDSELF_B and SD1_CLK_B
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Geert Uytterhoeven, Sasha Levin, linux-renesas-soc, linux-gpio
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Geert Uytterhoeven <geert+renesas@glider.be>
[ Upstream commit 805f635703b2562b5ddd822c62fc9124087e5dd5 ]
The FN_SDSELF_B and FN_SD1_CLK_B enum IDs are used twice, which means
one set of users must be wrong. Replace them by the correct enum IDs.
Fixes: 87f8c988636db0d4 ("sh-pfc: Add r8a7778 pinmux support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191218194812.12741-2-geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7778.c b/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
index 24866a5958aee..a9875038ed9b6 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
@@ -2305,7 +2305,7 @@ static const struct pinmux_cfg_reg pinmux_config_regs[] = {
FN_ATAG0_A, 0, FN_REMOCON_B, 0,
/* IP0_11_8 [4] */
FN_SD1_DAT2_A, FN_MMC_D2, 0, FN_BS,
- FN_ATADIR0_A, 0, FN_SDSELF_B, 0,
+ FN_ATADIR0_A, 0, FN_SDSELF_A, 0,
FN_PWM4_B, 0, 0, 0,
0, 0, 0, 0,
/* IP0_7_5 [3] */
@@ -2349,7 +2349,7 @@ static const struct pinmux_cfg_reg pinmux_config_regs[] = {
FN_TS_SDAT0_A, 0, 0, 0,
0, 0, 0, 0,
/* IP1_10_8 [3] */
- FN_SD1_CLK_B, FN_MMC_D6, 0, FN_A24,
+ FN_SD1_CD_A, FN_MMC_D6, 0, FN_A24,
FN_DREQ1_A, 0, FN_HRX0_B, FN_TS_SPSYNC0_A,
/* IP1_7_5 [3] */
FN_A23, FN_HTX0_B, FN_TX2_B, FN_DACK2_A,
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 236/459] pinctrl: sh-pfc: sh7269: Fix CAN function GPIOs
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Geert Uytterhoeven, Sasha Levin, linux-sh, linux-renesas-soc,
linux-gpio
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Geert Uytterhoeven <geert+renesas@glider.be>
[ Upstream commit 02aeb2f21530c98fc3ca51028eda742a3fafbd9f ]
pinmux_func_gpios[] contains a hole due to the missing function GPIO
definition for the "CTX0&CTX1" signal, which is the logical "AND" of the
first two CAN outputs.
A closer look reveals other issues:
- Some functionality is available on alternative pins, but the
PINMUX_DATA() entries is using the wrong marks,
- Several configurations are missing.
Fix this by:
- Renaming CTX0CTX1CTX2_MARK, CRX0CRX1_PJ22_MARK, and
CRX0CRX1CRX2_PJ20_MARK to CTX0_CTX1_CTX2_MARK, CRX0_CRX1_PJ22_MARK,
resp. CRX0_CRX1_CRX2_PJ20_MARK for consistency with the
corresponding enum IDs,
- Adding all missing enum IDs and marks,
- Use the right (*_PJ2x) variants for alternative pins,
- Adding all missing configurations to pinmux_data[],
- Adding all missing function GPIO definitions to pinmux_func_gpios[].
See SH7268 Group, SH7269 Group User’s Manual: Hardware, Rev. 2.00:
[1] Table 1.4 List of Pins
[2] Figure 23.29 Connection Example when Using Channels 0 and 1 as One
Channel (64 Mailboxes × 1 Channel) and Channel 2 as One Channel
(32 Mailboxes × 1 Channel),
[3] Figure 23.30 Connection Example when Using Channels 0, 1, and 2 as
One Channel (96 Mailboxes × 1 Channel),
[4] Table 48.3 Multiplexed Pins (Port B),
[5] Table 48.4 Multiplexed Pins (Port C),
[6] Table 48.10 Multiplexed Pins (Port J),
[7] Section 48.2.4 Port B Control Registers 0 to 5 (PBCR0 to PBCR5).
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191218194812.12741-5-geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/sh/include/cpu-sh2a/cpu/sh7269.h | 11 ++++++--
drivers/pinctrl/sh-pfc/pfc-sh7269.c | 39 ++++++++++++++++++---------
2 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/arch/sh/include/cpu-sh2a/cpu/sh7269.h b/arch/sh/include/cpu-sh2a/cpu/sh7269.h
index d516e5d488180..b887cc402b712 100644
--- a/arch/sh/include/cpu-sh2a/cpu/sh7269.h
+++ b/arch/sh/include/cpu-sh2a/cpu/sh7269.h
@@ -78,8 +78,15 @@ enum {
GPIO_FN_WDTOVF,
/* CAN */
- GPIO_FN_CTX1, GPIO_FN_CRX1, GPIO_FN_CTX0, GPIO_FN_CTX0_CTX1,
- GPIO_FN_CRX0, GPIO_FN_CRX0_CRX1, GPIO_FN_CRX0_CRX1_CRX2,
+ GPIO_FN_CTX2, GPIO_FN_CRX2,
+ GPIO_FN_CTX1, GPIO_FN_CRX1,
+ GPIO_FN_CTX0, GPIO_FN_CRX0,
+ GPIO_FN_CTX0_CTX1, GPIO_FN_CRX0_CRX1,
+ GPIO_FN_CTX0_CTX1_CTX2, GPIO_FN_CRX0_CRX1_CRX2,
+ GPIO_FN_CTX2_PJ21, GPIO_FN_CRX2_PJ20,
+ GPIO_FN_CTX1_PJ23, GPIO_FN_CRX1_PJ22,
+ GPIO_FN_CTX0_CTX1_PJ23, GPIO_FN_CRX0_CRX1_PJ22,
+ GPIO_FN_CTX0_CTX1_CTX2_PJ21, GPIO_FN_CRX0_CRX1_CRX2_PJ20,
/* DMAC */
GPIO_FN_TEND0, GPIO_FN_DACK0, GPIO_FN_DREQ0,
diff --git a/drivers/pinctrl/sh-pfc/pfc-sh7269.c b/drivers/pinctrl/sh-pfc/pfc-sh7269.c
index 6cbb18ef77dc0..d20974a55d93a 100644
--- a/drivers/pinctrl/sh-pfc/pfc-sh7269.c
+++ b/drivers/pinctrl/sh-pfc/pfc-sh7269.c
@@ -737,13 +737,12 @@ enum {
CRX0_MARK, CTX0_MARK,
CRX1_MARK, CTX1_MARK,
CRX2_MARK, CTX2_MARK,
- CRX0_CRX1_MARK,
- CRX0_CRX1_CRX2_MARK,
- CTX0CTX1CTX2_MARK,
+ CRX0_CRX1_MARK, CTX0_CTX1_MARK,
+ CRX0_CRX1_CRX2_MARK, CTX0_CTX1_CTX2_MARK,
CRX1_PJ22_MARK, CTX1_PJ23_MARK,
CRX2_PJ20_MARK, CTX2_PJ21_MARK,
- CRX0CRX1_PJ22_MARK,
- CRX0CRX1CRX2_PJ20_MARK,
+ CRX0_CRX1_PJ22_MARK, CTX0_CTX1_PJ23_MARK,
+ CRX0_CRX1_CRX2_PJ20_MARK, CTX0_CTX1_CTX2_PJ21_MARK,
/* VDC */
DV_CLK_MARK,
@@ -821,6 +820,7 @@ static const u16 pinmux_data[] = {
PINMUX_DATA(CS3_MARK, PC8MD_001),
PINMUX_DATA(TXD7_MARK, PC8MD_010),
PINMUX_DATA(CTX1_MARK, PC8MD_011),
+ PINMUX_DATA(CTX0_CTX1_MARK, PC8MD_100),
PINMUX_DATA(PC7_DATA, PC7MD_000),
PINMUX_DATA(CKE_MARK, PC7MD_001),
@@ -833,11 +833,12 @@ static const u16 pinmux_data[] = {
PINMUX_DATA(CAS_MARK, PC6MD_001),
PINMUX_DATA(SCK7_MARK, PC6MD_010),
PINMUX_DATA(CTX0_MARK, PC6MD_011),
+ PINMUX_DATA(CTX0_CTX1_CTX2_MARK, PC6MD_100),
PINMUX_DATA(PC5_DATA, PC5MD_000),
PINMUX_DATA(RAS_MARK, PC5MD_001),
PINMUX_DATA(CRX0_MARK, PC5MD_011),
- PINMUX_DATA(CTX0CTX1CTX2_MARK, PC5MD_100),
+ PINMUX_DATA(CTX0_CTX1_CTX2_MARK, PC5MD_100),
PINMUX_DATA(IRQ0_PC_MARK, PC5MD_101),
PINMUX_DATA(PC4_DATA, PC4MD_00),
@@ -1289,30 +1290,32 @@ static const u16 pinmux_data[] = {
PINMUX_DATA(LCD_DATA23_PJ23_MARK, PJ23MD_010),
PINMUX_DATA(LCD_TCON6_MARK, PJ23MD_011),
PINMUX_DATA(IRQ3_PJ_MARK, PJ23MD_100),
- PINMUX_DATA(CTX1_MARK, PJ23MD_101),
+ PINMUX_DATA(CTX1_PJ23_MARK, PJ23MD_101),
+ PINMUX_DATA(CTX0_CTX1_PJ23_MARK, PJ23MD_110),
PINMUX_DATA(PJ22_DATA, PJ22MD_000),
PINMUX_DATA(DV_DATA22_MARK, PJ22MD_001),
PINMUX_DATA(LCD_DATA22_PJ22_MARK, PJ22MD_010),
PINMUX_DATA(LCD_TCON5_MARK, PJ22MD_011),
PINMUX_DATA(IRQ2_PJ_MARK, PJ22MD_100),
- PINMUX_DATA(CRX1_MARK, PJ22MD_101),
- PINMUX_DATA(CRX0_CRX1_MARK, PJ22MD_110),
+ PINMUX_DATA(CRX1_PJ22_MARK, PJ22MD_101),
+ PINMUX_DATA(CRX0_CRX1_PJ22_MARK, PJ22MD_110),
PINMUX_DATA(PJ21_DATA, PJ21MD_000),
PINMUX_DATA(DV_DATA21_MARK, PJ21MD_001),
PINMUX_DATA(LCD_DATA21_PJ21_MARK, PJ21MD_010),
PINMUX_DATA(LCD_TCON4_MARK, PJ21MD_011),
PINMUX_DATA(IRQ1_PJ_MARK, PJ21MD_100),
- PINMUX_DATA(CTX2_MARK, PJ21MD_101),
+ PINMUX_DATA(CTX2_PJ21_MARK, PJ21MD_101),
+ PINMUX_DATA(CTX0_CTX1_CTX2_PJ21_MARK, PJ21MD_110),
PINMUX_DATA(PJ20_DATA, PJ20MD_000),
PINMUX_DATA(DV_DATA20_MARK, PJ20MD_001),
PINMUX_DATA(LCD_DATA20_PJ20_MARK, PJ20MD_010),
PINMUX_DATA(LCD_TCON3_MARK, PJ20MD_011),
PINMUX_DATA(IRQ0_PJ_MARK, PJ20MD_100),
- PINMUX_DATA(CRX2_MARK, PJ20MD_101),
- PINMUX_DATA(CRX0CRX1CRX2_PJ20_MARK, PJ20MD_110),
+ PINMUX_DATA(CRX2_PJ20_MARK, PJ20MD_101),
+ PINMUX_DATA(CRX0_CRX1_CRX2_PJ20_MARK, PJ20MD_110),
PINMUX_DATA(PJ19_DATA, PJ19MD_000),
PINMUX_DATA(DV_DATA19_MARK, PJ19MD_001),
@@ -1663,12 +1666,24 @@ static const struct pinmux_func pinmux_func_gpios[] = {
GPIO_FN(WDTOVF),
/* CAN */
+ GPIO_FN(CTX2),
+ GPIO_FN(CRX2),
GPIO_FN(CTX1),
GPIO_FN(CRX1),
GPIO_FN(CTX0),
GPIO_FN(CRX0),
+ GPIO_FN(CTX0_CTX1),
GPIO_FN(CRX0_CRX1),
+ GPIO_FN(CTX0_CTX1_CTX2),
GPIO_FN(CRX0_CRX1_CRX2),
+ GPIO_FN(CTX2_PJ21),
+ GPIO_FN(CRX2_PJ20),
+ GPIO_FN(CTX1_PJ23),
+ GPIO_FN(CRX1_PJ22),
+ GPIO_FN(CTX0_CTX1_PJ23),
+ GPIO_FN(CRX0_CRX1_PJ22),
+ GPIO_FN(CTX0_CTX1_CTX2_PJ21),
+ GPIO_FN(CRX0_CRX1_CRX2_PJ20),
/* DMAC */
GPIO_FN(TEND0),
--
2.20.1
^ permalink raw reply related
* [PATCH 0/3] virtio-iommu on non-devicetree platforms
From: Jean-Philippe Brucker @ 2020-02-14 16:04 UTC (permalink / raw)
To: iommu, virtualization, linux-pci
Cc: joro, bhelgaas, mst, jasowang, kevin.tian, sebastien.boeuf,
eric.auger, jacob.jun.pan
Add topology description to the virtio-iommu driver and enable x86
platforms. Since the RFC [1] I've mostly given up on ACPI tables, since
the internal discussions seem to have reached a dead end. The built-in
topology description presented here isn't ideal, but it is simple to
implement and doesn't impose a dependency on ACPI or device-tree, which
can be beneficial to lightweight hypervisors.
The built-in description is an array in the virtio config space. The
driver parses the config space early and postpones endpoint probe until
the virtio-iommu device is ready. Each element in the array describes
either a PCI range or a single MMIO endpoint, and their associated
endpoint IDs:
struct virtio_iommu_topo_pci_range {
__le16 type; /* 1: PCI range */
__le16 hierarchy; /* PCI domain number */
__le16 requester_start; /* First BDF */
__le16 requester_end; /* Last BDF */
__le32 endpoint_start; /* First endpoint ID */
};
struct virtio_iommu_topo_endpoint {
__le16 type; /* 2: Endpoint */
__le16 reserved; /* 0 */
__le32 endpoint; /* Endpoint ID */
__le64 address; /* First MMIO address */
};
You can find the QEMU patches based on Eric's latest device on my
virtio-iommu/devel branch [2]. I test on both x86 q35, and aarch64 virt
machine with edk2.
[1] https://lore.kernel.org/linux-iommu/20191122105000.800410-1-jean-philippe@linaro.org/
[2] https://jpbrucker.net/git/qemu virtio-iommu/devel
Jean-Philippe Brucker (3):
iommu/virtio: Add topology description to virtio-iommu config space
PCI: Add DMA configuration for virtual platforms
iommu/virtio: Enable x86 support
MAINTAINERS | 2 +
drivers/iommu/Kconfig | 13 +-
drivers/iommu/Makefile | 1 +
drivers/iommu/virtio-iommu-topology.c | 343 ++++++++++++++++++++++++++
drivers/iommu/virtio-iommu.c | 3 +
drivers/pci/pci-driver.c | 5 +
include/linux/virt_iommu.h | 19 ++
include/uapi/linux/virtio_iommu.h | 26 ++
8 files changed, 411 insertions(+), 1 deletion(-)
create mode 100644 drivers/iommu/virtio-iommu-topology.c
create mode 100644 include/linux/virt_iommu.h
--
2.25.0
^ permalink raw reply
* [PATCH 2/3] PCI: Add DMA configuration for virtual platforms
From: Jean-Philippe Brucker @ 2020-02-14 16:04 UTC (permalink / raw)
To: iommu, virtualization, linux-pci
Cc: joro, bhelgaas, mst, jasowang, kevin.tian, sebastien.boeuf,
eric.auger, jacob.jun.pan
In-Reply-To: <20200214160413.1475396-1-jean-philippe@linaro.org>
Hardware platforms usually describe the IOMMU topology using either
device-tree pointers or vendor-specific ACPI tables. For virtual
platforms that don't provide a device-tree, the virtio-iommu device
contains a description of the endpoints it manages. That information
allows us to probe endpoints after the IOMMU is probed (possibly as late
as userspace modprobe), provided it is discovered early enough.
Add a hook to pci_dma_configure(), which returns -EPROBE_DEFER if the
endpoint is managed by a vIOMMU that will be loaded later, or 0 in any
other case to avoid disturbing the normal DMA configuration methods.
When CONFIG_VIRTIO_IOMMU_TOPOLOGY isn't selected, the call to
virt_dma_configure() is compiled out.
As long as the information is consistent, platforms can provide both a
device-tree and a built-in topology, and the IOMMU infrastructure is
able to deal with multiple DMA configuration methods.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/pci/pci-driver.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 0454ca0e4e3f..69303a814f21 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -18,6 +18,7 @@
#include <linux/kexec.h>
#include <linux/of_device.h>
#include <linux/acpi.h>
+#include <linux/virt_iommu.h>
#include "pci.h"
#include "pcie/portdrv.h"
@@ -1602,6 +1603,10 @@ static int pci_dma_configure(struct device *dev)
struct device *bridge;
int ret = 0;
+ ret = virt_dma_configure(dev);
+ if (ret)
+ return ret;
+
bridge = pci_get_host_bridge_device(to_pci_dev(dev));
if (IS_ENABLED(CONFIG_OF) && bridge->parent &&
--
2.25.0
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 238/459] ASoC: soc-topology: fix endianness issues
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Pierre-Louis Bossart, Mark Brown, Sasha Levin, alsa-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
[ Upstream commit 72bbeda0222bcd382ee33b3aff71346074410c21 ]
Sparse complains about a series of easy warnings, fix.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200102195952.9465-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/soc-topology.c | 42 +++++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c
index fef01e1dd15c5..d00203ef8305f 100644
--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -604,9 +604,11 @@ static int soc_tplg_kcontrol_bind_io(struct snd_soc_tplg_ctl_hdr *hdr,
ext_ops = tplg->bytes_ext_ops;
num_ops = tplg->bytes_ext_ops_count;
for (i = 0; i < num_ops; i++) {
- if (!sbe->put && ext_ops[i].id == be->ext_ops.put)
+ if (!sbe->put &&
+ ext_ops[i].id == le32_to_cpu(be->ext_ops.put))
sbe->put = ext_ops[i].put;
- if (!sbe->get && ext_ops[i].id == be->ext_ops.get)
+ if (!sbe->get &&
+ ext_ops[i].id == le32_to_cpu(be->ext_ops.get))
sbe->get = ext_ops[i].get;
}
@@ -621,11 +623,11 @@ static int soc_tplg_kcontrol_bind_io(struct snd_soc_tplg_ctl_hdr *hdr,
num_ops = tplg->io_ops_count;
for (i = 0; i < num_ops; i++) {
- if (k->put == NULL && ops[i].id == hdr->ops.put)
+ if (k->put == NULL && ops[i].id == le32_to_cpu(hdr->ops.put))
k->put = ops[i].put;
- if (k->get == NULL && ops[i].id == hdr->ops.get)
+ if (k->get == NULL && ops[i].id == le32_to_cpu(hdr->ops.get))
k->get = ops[i].get;
- if (k->info == NULL && ops[i].id == hdr->ops.info)
+ if (k->info == NULL && ops[i].id == le32_to_cpu(hdr->ops.info))
k->info = ops[i].info;
}
@@ -638,11 +640,11 @@ static int soc_tplg_kcontrol_bind_io(struct snd_soc_tplg_ctl_hdr *hdr,
num_ops = ARRAY_SIZE(io_ops);
for (i = 0; i < num_ops; i++) {
- if (k->put == NULL && ops[i].id == hdr->ops.put)
+ if (k->put == NULL && ops[i].id == le32_to_cpu(hdr->ops.put))
k->put = ops[i].put;
- if (k->get == NULL && ops[i].id == hdr->ops.get)
+ if (k->get == NULL && ops[i].id == le32_to_cpu(hdr->ops.get))
k->get = ops[i].get;
- if (k->info == NULL && ops[i].id == hdr->ops.info)
+ if (k->info == NULL && ops[i].id == le32_to_cpu(hdr->ops.info))
k->info = ops[i].info;
}
@@ -931,7 +933,7 @@ static int soc_tplg_denum_create_texts(struct soc_enum *se,
if (se->dobj.control.dtexts == NULL)
return -ENOMEM;
- for (i = 0; i < ec->items; i++) {
+ for (i = 0; i < le32_to_cpu(ec->items); i++) {
if (strnlen(ec->texts[i], SNDRV_CTL_ELEM_ID_NAME_MAXLEN) ==
SNDRV_CTL_ELEM_ID_NAME_MAXLEN) {
@@ -1325,7 +1327,7 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dmixer_create(
if (kc[i].name == NULL)
goto err_sm;
kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER;
- kc[i].access = mc->hdr.access;
+ kc[i].access = le32_to_cpu(mc->hdr.access);
/* we only support FL/FR channel mapping atm */
sm->reg = tplc_chan_get_reg(tplg, mc->channel,
@@ -1337,10 +1339,10 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dmixer_create(
sm->rshift = tplc_chan_get_shift(tplg, mc->channel,
SNDRV_CHMAP_FR);
- sm->max = mc->max;
- sm->min = mc->min;
- sm->invert = mc->invert;
- sm->platform_max = mc->platform_max;
+ sm->max = le32_to_cpu(mc->max);
+ sm->min = le32_to_cpu(mc->min);
+ sm->invert = le32_to_cpu(mc->invert);
+ sm->platform_max = le32_to_cpu(mc->platform_max);
sm->dobj.index = tplg->index;
INIT_LIST_HEAD(&sm->dobj.list);
@@ -1401,7 +1403,7 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_denum_create(
goto err_se;
tplg->pos += (sizeof(struct snd_soc_tplg_enum_control) +
- ec->priv.size);
+ le32_to_cpu(ec->priv.size));
dev_dbg(tplg->dev, " adding DAPM widget enum control %s\n",
ec->hdr.name);
@@ -1411,7 +1413,7 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_denum_create(
if (kc[i].name == NULL)
goto err_se;
kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER;
- kc[i].access = ec->hdr.access;
+ kc[i].access = le32_to_cpu(ec->hdr.access);
/* we only support FL/FR channel mapping atm */
se->reg = tplc_chan_get_reg(tplg, ec->channel, SNDRV_CHMAP_FL);
@@ -1420,8 +1422,8 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_denum_create(
se->shift_r = tplc_chan_get_shift(tplg, ec->channel,
SNDRV_CHMAP_FR);
- se->items = ec->items;
- se->mask = ec->mask;
+ se->items = le32_to_cpu(ec->items);
+ se->mask = le32_to_cpu(ec->mask);
se->dobj.index = tplg->index;
switch (le32_to_cpu(ec->hdr.ops.info)) {
@@ -1523,9 +1525,9 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dbytes_create(
if (kc[i].name == NULL)
goto err_sbe;
kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER;
- kc[i].access = be->hdr.access;
+ kc[i].access = le32_to_cpu(be->hdr.access);
- sbe->max = be->max;
+ sbe->max = le32_to_cpu(be->max);
INIT_LIST_HEAD(&sbe->dobj.list);
/* map standard io handlers and check for external handlers */
--
2.20.1
^ permalink raw reply related
* [PATCH 3/3] iommu/virtio: Enable x86 support
From: Jean-Philippe Brucker @ 2020-02-14 16:04 UTC (permalink / raw)
To: iommu, virtualization, linux-pci
Cc: joro, bhelgaas, mst, jasowang, kevin.tian, sebastien.boeuf,
eric.auger, jacob.jun.pan
In-Reply-To: <20200214160413.1475396-1-jean-philippe@linaro.org>
With the built-in topology description in place, x86 platforms can now
use the virtio-iommu.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/iommu/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 068d4e0e3541..adcbda44d473 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -508,8 +508,9 @@ config HYPERV_IOMMU
config VIRTIO_IOMMU
bool "Virtio IOMMU driver"
depends on VIRTIO=y
- depends on ARM64
+ depends on (ARM64 || X86)
select IOMMU_API
+ select IOMMU_DMA
select INTERVAL_TREE
help
Para-virtualised IOMMU driver with virtio.
--
2.25.0
^ permalink raw reply related
* [PATCH 1/3] iommu/virtio: Add topology description to virtio-iommu config space
From: Jean-Philippe Brucker @ 2020-02-14 16:04 UTC (permalink / raw)
To: iommu, virtualization, linux-pci
Cc: joro, bhelgaas, mst, jasowang, kevin.tian, sebastien.boeuf,
eric.auger, jacob.jun.pan
In-Reply-To: <20200214160413.1475396-1-jean-philippe@linaro.org>
Platforms without device-tree do not currently have a method for
describing the vIOMMU topology. Provide a topology description embedded
into the virtio device.
Use PCI FIXUP to probe the config space early, because we need to
discover the topology before any DMA configuration takes place, and the
virtio driver may be loaded much later. Since we discover the topology
description when probing the PCI hierarchy, the virtual IOMMU cannot
manage other platform devices discovered earlier.
This solution isn't elegant nor foolproof, but is the best we can do at
the moment and works with existing virtio-iommu implementations. It also
enables an IOMMU for lightweight hypervisors that do not rely on
firmware methods for booting.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
MAINTAINERS | 2 +
drivers/iommu/Kconfig | 10 +
drivers/iommu/Makefile | 1 +
drivers/iommu/virtio-iommu-topology.c | 343 ++++++++++++++++++++++++++
drivers/iommu/virtio-iommu.c | 3 +
include/linux/virt_iommu.h | 19 ++
include/uapi/linux/virtio_iommu.h | 26 ++
7 files changed, 404 insertions(+)
create mode 100644 drivers/iommu/virtio-iommu-topology.c
create mode 100644 include/linux/virt_iommu.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 38fe2f3f7b6f..6b978b0d0c90 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17780,6 +17780,8 @@ M: Jean-Philippe Brucker <jean-philippe@linaro.org>
L: virtualization@lists.linux-foundation.org
S: Maintained
F: drivers/iommu/virtio-iommu.c
+F: drivers/iommu/virtio-iommu-topology.c
+F: include/linux/virt_iommu.h
F: include/uapi/linux/virtio_iommu.h
VIRTUAL BOX GUEST DEVICE DRIVER
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d2fade984999..068d4e0e3541 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -516,4 +516,14 @@ config VIRTIO_IOMMU
Say Y here if you intend to run this kernel as a guest.
+config VIRTIO_IOMMU_TOPOLOGY
+ bool "Topology properties for the virtio-iommu"
+ depends on VIRTIO_IOMMU
+ default y
+ help
+ Enable early probing of the virtio-iommu device, to detect the
+ built-in topology description.
+
+ Say Y here if you intend to run this kernel as a guest.
+
endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 2104fb8afc06..f295cacf9c6e 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o
+obj-$(CONFIG_VIRTIO_IOMMU_TOPOLOGY) += virtio-iommu-topology.o
diff --git a/drivers/iommu/virtio-iommu-topology.c b/drivers/iommu/virtio-iommu-topology.c
new file mode 100644
index 000000000000..e4ab49701df5
--- /dev/null
+++ b/drivers/iommu/virtio-iommu-topology.c
@@ -0,0 +1,343 @@
+// SPDX-License-Identifier: GPL-2.0
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/dma-iommu.h>
+#include <linux/list.h>
+#include <linux/pci.h>
+#include <linux/virt_iommu.h>
+#include <linux/virtio_ids.h>
+#include <linux/virtio_pci.h>
+#include <uapi/linux/virtio_iommu.h>
+
+struct viommu_cap_config {
+ u8 bar;
+ u32 length; /* structure size */
+ u32 offset; /* structure offset within the bar */
+};
+
+union viommu_topo_cfg {
+ __le16 type;
+ struct virtio_iommu_topo_pci_range pci;
+ struct virtio_iommu_topo_endpoint ep;
+};
+
+struct viommu_spec {
+ struct device *dev; /* transport device */
+ struct fwnode_handle *fwnode;
+ struct iommu_ops *ops;
+ struct list_head list;
+ size_t num_items;
+ /* The config array of length num_items follows */
+ union viommu_topo_cfg cfg[];
+};
+
+static LIST_HEAD(viommus);
+static DEFINE_MUTEX(viommus_lock);
+
+#define VPCI_FIELD(field) offsetof(struct virtio_pci_cap, field)
+
+static inline int viommu_pci_find_capability(struct pci_dev *dev, u8 cfg_type,
+ struct viommu_cap_config *cap)
+{
+ int pos;
+ u8 bar;
+
+ for (pos = pci_find_capability(dev, PCI_CAP_ID_VNDR);
+ pos > 0;
+ pos = pci_find_next_capability(dev, pos, PCI_CAP_ID_VNDR)) {
+ u8 type;
+
+ pci_read_config_byte(dev, pos + VPCI_FIELD(cfg_type), &type);
+ if (type != cfg_type)
+ continue;
+
+ pci_read_config_byte(dev, pos + VPCI_FIELD(bar), &bar);
+
+ /* Ignore structures with reserved BAR values */
+ if (type != VIRTIO_PCI_CAP_PCI_CFG && bar > 0x5)
+ continue;
+
+ cap->bar = bar;
+ pci_read_config_dword(dev, pos + VPCI_FIELD(length),
+ &cap->length);
+ pci_read_config_dword(dev, pos + VPCI_FIELD(offset),
+ &cap->offset);
+
+ return pos;
+ }
+ return 0;
+}
+
+static void viommu_ccopy(__le32 *dst, u32 __iomem *src, size_t length)
+{
+ size_t i;
+
+ /* For the moment all our config structures align on 32b */
+ if (WARN_ON(length % 4))
+ return;
+
+ for (i = 0; i < length / 4; i++)
+ /* Keep little-endian data */
+ dst[i] = cpu_to_le32(ioread32(src + i));
+}
+
+static int viommu_parse_topology(struct device *dev,
+ struct virtio_iommu_config __iomem *cfg)
+{
+ size_t i;
+ size_t spec_length;
+ struct viommu_spec *viommu_spec;
+ u32 offset, item_length, num_items;
+
+ offset = ioread32(&cfg->topo_config.offset);
+ item_length = ioread32(&cfg->topo_config.item_length);
+ num_items = ioread32(&cfg->topo_config.num_items);
+ if (!offset || !num_items || !item_length)
+ return 0;
+
+ spec_length = sizeof(*viommu_spec) + num_items *
+ sizeof(union viommu_topo_cfg);
+ viommu_spec = kzalloc(spec_length, GFP_KERNEL);
+ if (!viommu_spec)
+ return -ENOMEM;
+
+ viommu_spec->dev = dev;
+
+ /* Copy in the whole array, sort it out later */
+ for (i = 0; i < num_items; i++) {
+ size_t read_length = min_t(size_t, item_length,
+ sizeof(union viommu_topo_cfg));
+
+ viommu_ccopy((__le32 *)&viommu_spec->cfg[i],
+ (void __iomem *)cfg + offset,
+ read_length);
+
+ offset += item_length;
+ }
+ viommu_spec->num_items = num_items;
+
+ mutex_lock(&viommus_lock);
+ list_add(&viommu_spec->list, &viommus);
+ mutex_unlock(&viommus_lock);
+
+ return 0;
+}
+
+static void viommu_pci_parse_topology(struct pci_dev *dev)
+{
+ int pos;
+ u32 features;
+ void __iomem *regs;
+ struct viommu_cap_config cap = {0};
+ struct virtio_pci_common_cfg __iomem *common_cfg;
+
+ /*
+ * The virtio infrastructure might not be loaded at this point. we need
+ * to access the BARs ourselves.
+ */
+ pos = viommu_pci_find_capability(dev, VIRTIO_PCI_CAP_COMMON_CFG, &cap);
+ if (!pos) {
+ pci_warn(dev, "common capability not found\n");
+ return;
+ }
+
+ if (pci_enable_device_mem(dev))
+ return;
+
+ regs = pci_iomap(dev, cap.bar, 0);
+ if (!regs)
+ return;
+
+ common_cfg = regs + cap.offset;
+
+ /* Find out if the device supports topology description */
+ writel(0, &common_cfg->device_feature_select);
+ features = ioread32(&common_cfg->device_feature);
+
+ pci_iounmap(dev, regs);
+
+ if (!(features & BIT(VIRTIO_IOMMU_F_TOPOLOGY))) {
+ pci_dbg(dev, "device doesn't have topology description");
+ return;
+ }
+
+ pos = viommu_pci_find_capability(dev, VIRTIO_PCI_CAP_DEVICE_CFG, &cap);
+ if (!pos) {
+ pci_warn(dev, "device config capability not found\n");
+ return;
+ }
+
+ regs = pci_iomap(dev, cap.bar, 0);
+ if (!regs)
+ return;
+
+ pci_info(dev, "parsing virtio-iommu topology\n");
+ viommu_parse_topology(&dev->dev, regs + cap.offset);
+ pci_iounmap(dev, regs);
+}
+
+/*
+ * Catch a PCI virtio-iommu implementation early to get the topology description
+ * before we start probing other endpoints.
+ */
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REDHAT_QUMRANET, 0x1040 + VIRTIO_ID_IOMMU,
+ viommu_pci_parse_topology);
+
+/*
+ * Return true if the device matches this topology structure. Write the endpoint
+ * ID into epid if it's the case.
+ */
+static bool viommu_parse_pci(struct pci_dev *pdev, union viommu_topo_cfg *cfg,
+ u32 *epid)
+{
+ u32 endpoint_start;
+ u16 start, end, domain;
+ u16 devid = pci_dev_id(pdev);
+ u16 type = le16_to_cpu(cfg->type);
+
+ if (type != VIRTIO_IOMMU_TOPO_PCI_RANGE)
+ return false;
+
+ start = le16_to_cpu(cfg->pci.requester_start);
+ end = le16_to_cpu(cfg->pci.requester_end);
+ domain = le16_to_cpu(cfg->pci.hierarchy);
+ endpoint_start = le32_to_cpu(cfg->pci.endpoint_start);
+
+ if (pci_domain_nr(pdev->bus) == domain &&
+ devid >= start && devid <= end) {
+ *epid = devid - start + endpoint_start;
+ return true;
+ }
+ return false;
+}
+
+static const struct iommu_ops *virt_iommu_setup(struct device *dev)
+{
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ const struct iommu_ops *viommu_ops = NULL;
+ struct fwnode_handle *viommu_fwnode;
+ struct viommu_spec *viommu_spec;
+ struct pci_dev *pci_dev = NULL;
+ struct device *viommu_dev;
+ bool found = false;
+ size_t i;
+ u32 epid;
+ int ret;
+
+ /* Already translated? */
+ if (fwspec && fwspec->ops)
+ return fwspec->ops;
+
+ if (dev_is_pci(dev)) {
+ pci_dev = to_pci_dev(dev);
+ } else {
+ /* At the moment we don't support platform devices */
+ return NULL;
+ }
+
+ mutex_lock(&viommus_lock);
+ list_for_each_entry(viommu_spec, &viommus, list) {
+ for (i = 0; i < viommu_spec->num_items; i++) {
+ union viommu_topo_cfg *cfg = &viommu_spec->cfg[i];
+
+ found = viommu_parse_pci(pci_dev, cfg, &epid);
+ if (found)
+ break;
+ }
+ if (found) {
+ viommu_ops = viommu_spec->ops;
+ viommu_fwnode = viommu_spec->fwnode;
+ viommu_dev = viommu_spec->dev;
+ break;
+ }
+ }
+ mutex_unlock(&viommus_lock);
+ if (!found)
+ return NULL;
+
+ /* We're not translating ourselves. */
+ if (viommu_dev == dev)
+ return NULL;
+
+ /*
+ * If we found a PCI range managed by the viommu, we're the ones that
+ * have to request ACS.
+ */
+ if (pci_dev)
+ pci_request_acs();
+
+ if (!viommu_ops)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ ret = iommu_fwspec_init(dev, viommu_fwnode, viommu_ops);
+ if (ret)
+ return ERR_PTR(ret);
+
+ iommu_fwspec_add_ids(dev, &epid, 1);
+
+ return viommu_ops;
+}
+
+/**
+ * virt_dma_configure - Configure DMA of virtualized devices
+ * @dev: the endpoint
+ *
+ * Setup the DMA and IOMMU ops of a virtual device, for platforms without DT or
+ * ACPI.
+ *
+ * Return: -EPROBE_DEFER if the device is managed by an IOMMU that hasn't been
+ * probed yet, 0 otherwise
+ */
+int virt_dma_configure(struct device *dev)
+{
+ const struct iommu_ops *iommu_ops;
+
+ iommu_ops = virt_iommu_setup(dev);
+ if (IS_ERR_OR_NULL(iommu_ops)) {
+ int ret = PTR_ERR(iommu_ops);
+
+ if (ret == -EPROBE_DEFER || ret == 0)
+ return ret;
+ dev_err(dev, "error %d while setting up virt IOMMU\n", ret);
+ return 0;
+ }
+
+ /*
+ * If we have reason to believe the IOMMU driver missed the initial
+ * add_device callback for dev, replay it to get things in order.
+ */
+ if (dev->bus && !device_iommu_mapped(dev))
+ iommu_probe_device(dev);
+
+ /* Assume coherent, as well as full 64-bit addresses. */
+#ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS
+ arch_setup_dma_ops(dev, 0, ~0ULL, iommu_ops, true);
+#else
+ iommu_setup_dma_ops(dev, 0, ~0ULL);
+#endif
+ return 0;
+}
+
+/**
+ * virt_set_iommu_ops - Set the IOMMU ops of a virtual IOMMU device
+ * @dev: the IOMMU device (transport)
+ * @ops: the new IOMMU ops or NULL
+ *
+ * Setup the iommu_ops associated to a viommu_spec, once the driver is loaded
+ * and the device probed.
+ */
+void virt_set_iommu_ops(struct device *dev, struct iommu_ops *ops)
+{
+ struct viommu_spec *viommu_spec;
+
+ mutex_lock(&viommus_lock);
+ list_for_each_entry(viommu_spec, &viommus, list) {
+ if (viommu_spec->dev == dev) {
+ viommu_spec->ops = ops;
+ viommu_spec->fwnode = ops ? dev->fwnode : NULL;
+ break;
+ }
+ }
+ mutex_unlock(&viommus_lock);
+}
+EXPORT_SYMBOL_GPL(virt_set_iommu_ops);
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index cce329d71fba..f18ba8e22ebd 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -21,6 +21,7 @@
#include <linux/virtio.h>
#include <linux/virtio_config.h>
#include <linux/virtio_ids.h>
+#include <linux/virt_iommu.h>
#include <linux/wait.h>
#include <uapi/linux/virtio_iommu.h>
@@ -1075,6 +1076,7 @@ static int viommu_probe(struct virtio_device *vdev)
if (ret)
goto err_free_vqs;
+ virt_set_iommu_ops(dev->parent, &viommu_ops);
iommu_device_set_ops(&viommu->iommu, &viommu_ops);
iommu_device_set_fwnode(&viommu->iommu, parent_dev->fwnode);
@@ -1122,6 +1124,7 @@ static void viommu_remove(struct virtio_device *vdev)
{
struct viommu_dev *viommu = vdev->priv;
+ virt_set_iommu_ops(vdev->dev.parent, NULL);
iommu_device_sysfs_remove(&viommu->iommu);
iommu_device_unregister(&viommu->iommu);
diff --git a/include/linux/virt_iommu.h b/include/linux/virt_iommu.h
new file mode 100644
index 000000000000..c68b03ec75ba
--- /dev/null
+++ b/include/linux/virt_iommu.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef VIRTIO_IOMMU_H_
+#define VIRTIO_IOMMU_H_
+
+#if IS_ENABLED(CONFIG_VIRTIO_IOMMU_TOPOLOGY)
+int virt_dma_configure(struct device *dev);
+void virt_set_iommu_ops(struct device *dev, struct iommu_ops *ops);
+#else /* !CONFIG_VIRTIO_IOMMU_TOPOLOGY */
+static inline int virt_dma_configure(struct device *dev)
+{
+ /* Don't disturb the normal DMA configuration methods */
+ return 0;
+}
+
+static inline void virt_set_iommu_ops(struct device *dev, struct iommu_ops *ops)
+{ }
+#endif /* !CONFIG_VIRTIO_IOMMU_TOPOLOGY */
+
+#endif /* VIRTIO_IOMMU_H_ */
diff --git a/include/uapi/linux/virtio_iommu.h b/include/uapi/linux/virtio_iommu.h
index 237e36a280cb..ec57d215086a 100644
--- a/include/uapi/linux/virtio_iommu.h
+++ b/include/uapi/linux/virtio_iommu.h
@@ -16,6 +16,7 @@
#define VIRTIO_IOMMU_F_BYPASS 3
#define VIRTIO_IOMMU_F_PROBE 4
#define VIRTIO_IOMMU_F_MMIO 5
+#define VIRTIO_IOMMU_F_TOPOLOGY 6
struct virtio_iommu_range_64 {
__le64 start;
@@ -27,6 +28,12 @@ struct virtio_iommu_range_32 {
__le32 end;
};
+struct virtio_iommu_topo_config {
+ __le32 offset;
+ __le32 num_items;
+ __le32 item_length;
+};
+
struct virtio_iommu_config {
/* Supported page sizes */
__le64 page_size_mask;
@@ -36,6 +43,25 @@ struct virtio_iommu_config {
struct virtio_iommu_range_32 domain_range;
/* Probe buffer size */
__le32 probe_size;
+ struct virtio_iommu_topo_config topo_config;
+};
+
+#define VIRTIO_IOMMU_TOPO_PCI_RANGE 0x1
+#define VIRTIO_IOMMU_TOPO_ENDPOINT 0x2
+
+struct virtio_iommu_topo_pci_range {
+ __le16 type;
+ __le16 hierarchy;
+ __le16 requester_start;
+ __le16 requester_end;
+ __le32 endpoint_start;
+};
+
+struct virtio_iommu_topo_endpoint {
+ __le16 type;
+ __le16 reserved;
+ __le32 endpoint;
+ __le64 address;
};
/* Request types */
--
2.25.0
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 239/459] fbdev: fix numbering of fbcon options
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Peter Rosin, Geert Uytterhoeven, Jonathan Corbet, Matthew Wilcox,
Bartlomiej Zolnierkiewicz, Sasha Levin, dri-devel, linux-fbdev,
linux-doc
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Peter Rosin <peda@axentia.se>
[ Upstream commit fd933c00ebe220060e66fb136a7050a242456566 ]
Three shall be the number thou shalt count, and the number of the
counting shall be three. Four shalt thou not count...
One! Two! Five!
Fixes: efb985f6b265 ("[PATCH] fbcon: Console Rotation - Add framebuffer console documentation")
Signed-off-by: Peter Rosin <peda@axentia.se>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190827110854.12574-2-peda@axentia.se
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/fb/fbcon.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst
index ebca41785abea..65ba402551374 100644
--- a/Documentation/fb/fbcon.rst
+++ b/Documentation/fb/fbcon.rst
@@ -127,7 +127,7 @@ C. Boot options
is typically located on the same video card. Thus, the consoles that
are controlled by the VGA console will be garbled.
-4. fbcon=rotate:<n>
+5. fbcon=rotate:<n>
This option changes the orientation angle of the console display. The
value 'n' accepts the following:
@@ -152,21 +152,21 @@ C. Boot options
Actually, the underlying fb driver is totally ignorant of console
rotation.
-5. fbcon=margin:<color>
+6. fbcon=margin:<color>
This option specifies the color of the margins. The margins are the
leftover area at the right and the bottom of the screen that are not
used by text. By default, this area will be black. The 'color' value
is an integer number that depends on the framebuffer driver being used.
-6. fbcon=nodefer
+7. fbcon=nodefer
If the kernel is compiled with deferred fbcon takeover support, normally
the framebuffer contents, left in place by the firmware/bootloader, will
be preserved until there actually is some text is output to the console.
This option causes fbcon to bind immediately to the fbdev device.
-7. fbcon=logo-pos:<location>
+8. fbcon=logo-pos:<location>
The only possible 'location' is 'center' (without quotes), and when
given, the bootup logo is moved from the default top-left corner
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 240/459] RDMA/rxe: Fix error type of mmap_offset
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Jiewei Ke, Jason Gunthorpe, Sasha Levin, linux-rdma
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Jiewei Ke <kejiewei.cn@gmail.com>
[ Upstream commit 6ca18d8927d468c763571f78c9a7387a69ffa020 ]
The type of mmap_offset should be u64 instead of int to match the type of
mminfo.offset. If otherwise, after we create several thousands of CQs, it
will run into overflow issues.
Link: https://lore.kernel.org/r/20191227113613.5020-1-kejiewei.cn@gmail.com
Signed-off-by: Jiewei Ke <kejiewei.cn@gmail.com>
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/sw/rxe/rxe_verbs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.h b/drivers/infiniband/sw/rxe/rxe_verbs.h
index 5c4b2239129cc..b0a02d4c8b933 100644
--- a/drivers/infiniband/sw/rxe/rxe_verbs.h
+++ b/drivers/infiniband/sw/rxe/rxe_verbs.h
@@ -407,7 +407,7 @@ struct rxe_dev {
struct list_head pending_mmaps;
spinlock_t mmap_offset_lock; /* guard mmap_offset */
- int mmap_offset;
+ u64 mmap_offset;
atomic64_t stats_counters[RXE_NUM_OF_COUNTERS];
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 245/459] ALSA: hda/realtek - Apply mic mute LED quirk for Dell E7xx laptops, too
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Takashi Iwai, Sasha Levin, alsa-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Takashi Iwai <tiwai@suse.de>
[ Upstream commit 5fab5829674c279839a7408ab30c71c6dfe726b9 ]
Dell E7xx laptops have also mic mute LED that is driven by the
dell-laptop platform driver. Bind it with the capture control as
already done for other models.
A caveat is that the fixup hook for the mic mute LED has to be applied
at last, otherwise it results in the invalid override of the callback.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205529
Link: https://lore.kernel.org/r/20200105081119.21396-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/pci/hda/patch_realtek.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 68832f52c1ad2..e8d5f6befa1f3 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5848,6 +5848,7 @@ enum {
ALC288_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC288_FIXUP_DELL_XPS_13,
ALC288_FIXUP_DISABLE_AAMIX,
+ ALC292_FIXUP_DELL_E7X_AAMIX,
ALC292_FIXUP_DELL_E7X,
ALC292_FIXUP_DISABLE_AAMIX,
ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK,
@@ -6543,12 +6544,19 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC293_FIXUP_DELL1_MIC_NO_PRESENCE
},
- [ALC292_FIXUP_DELL_E7X] = {
+ [ALC292_FIXUP_DELL_E7X_AAMIX] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc_fixup_dell_xps13,
.chained = true,
.chain_id = ALC292_FIXUP_DISABLE_AAMIX
},
+ [ALC292_FIXUP_DELL_E7X] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = snd_hda_gen_fixup_micmute_led,
+ /* micmute fixup must be applied at last */
+ .chained_before = true,
+ .chain_id = ALC292_FIXUP_DELL_E7X_AAMIX,
+ },
[ALC298_FIXUP_ALIENWARE_MIC_NO_PRESENCE] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 249/459] vfio/spapr/nvlink2: Skip unpinning pages on error exit
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexey Kardashevskiy, Alex Williamson, Sasha Levin, kvm
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Alexey Kardashevskiy <aik@ozlabs.ru>
[ Upstream commit 338b4e10f939a71194d8ecef7ece205a942cec05 ]
The nvlink2 subdriver for IBM Witherspoon machines preregisters
GPU memory in the IOMMI API so KVM TCE code can map this memory
for DMA as well. This is done by mm_iommu_newdev() called from
vfio_pci_nvgpu_regops::mmap.
In an unlikely event of failure the data->mem remains NULL and
since mm_iommu_put() (which unregisters the region and unpins memory
if that was regular memory) does not expect mem=NULL, it should not be
called.
This adds a check to only call mm_iommu_put() for a valid data->mem.
Fixes: 7f92891778df ("vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/vfio/pci/vfio_pci_nvlink2.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_nvlink2.c b/drivers/vfio/pci/vfio_pci_nvlink2.c
index f2983f0f84bea..3f5f8198a6bb1 100644
--- a/drivers/vfio/pci/vfio_pci_nvlink2.c
+++ b/drivers/vfio/pci/vfio_pci_nvlink2.c
@@ -97,8 +97,10 @@ static void vfio_pci_nvgpu_release(struct vfio_pci_device *vdev,
/* If there were any mappings at all... */
if (data->mm) {
- ret = mm_iommu_put(data->mm, data->mem);
- WARN_ON(ret);
+ if (data->mem) {
+ ret = mm_iommu_put(data->mm, data->mem);
+ WARN_ON(ret);
+ }
mmdrop(data->mm);
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 230/459] net/wan/fsl_ucc_hdlc: remove set but not used variables 'ut_info' and 'ret'
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Chen Zhou, netdev, Hulk Robot, linuxppc-dev,
David S . Miller
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Chen Zhou <chenzhou10@huawei.com>
[ Upstream commit 270fe2ceda66b6964d4c6f261d7f562a02c1c786 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wan/fsl_ucc_hdlc.c: In function ucc_hdlc_irq_handler:
drivers/net/wan/fsl_ucc_hdlc.c:643:23:
warning: variable ut_info set but not used [-Wunused-but-set-variable]
drivers/net/wan/fsl_ucc_hdlc.c: In function uhdlc_suspend:
drivers/net/wan/fsl_ucc_hdlc.c:880:23:
warning: variable ut_info set but not used [-Wunused-but-set-variable]
drivers/net/wan/fsl_ucc_hdlc.c: In function uhdlc_resume:
drivers/net/wan/fsl_ucc_hdlc.c:925:6:
warning: variable ret set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wan/fsl_ucc_hdlc.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 4ad0a0c33d853..607cb1edff964 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -640,11 +640,9 @@ static irqreturn_t ucc_hdlc_irq_handler(int irq, void *dev_id)
struct ucc_hdlc_private *priv = (struct ucc_hdlc_private *)dev_id;
struct net_device *dev = priv->ndev;
struct ucc_fast_private *uccf;
- struct ucc_tdm_info *ut_info;
u32 ucce;
u32 uccm;
- ut_info = priv->ut_info;
uccf = priv->uccf;
ucce = ioread32be(uccf->p_ucce);
@@ -877,7 +875,6 @@ static void resume_clk_config(struct ucc_hdlc_private *priv)
static int uhdlc_suspend(struct device *dev)
{
struct ucc_hdlc_private *priv = dev_get_drvdata(dev);
- struct ucc_tdm_info *ut_info;
struct ucc_fast __iomem *uf_regs;
if (!priv)
@@ -889,7 +886,6 @@ static int uhdlc_suspend(struct device *dev)
netif_device_detach(priv->ndev);
napi_disable(&priv->napi);
- ut_info = priv->ut_info;
uf_regs = priv->uf_regs;
/* backup gumr guemr*/
@@ -922,7 +918,7 @@ static int uhdlc_resume(struct device *dev)
struct ucc_fast __iomem *uf_regs;
struct ucc_fast_private *uccf;
struct ucc_fast_info *uf_info;
- int ret, i;
+ int i;
u32 cecr_subblock;
u16 bd_status;
@@ -967,16 +963,16 @@ static int uhdlc_resume(struct device *dev)
/* Write to QE CECR, UCCx channel to Stop Transmission */
cecr_subblock = ucc_fast_get_qe_cr_subblock(uf_info->ucc_num);
- ret = qe_issue_cmd(QE_STOP_TX, cecr_subblock,
- (u8)QE_CR_PROTOCOL_UNSPECIFIED, 0);
+ qe_issue_cmd(QE_STOP_TX, cecr_subblock,
+ (u8)QE_CR_PROTOCOL_UNSPECIFIED, 0);
/* Set UPSMR normal mode */
iowrite32be(0, &uf_regs->upsmr);
/* init parameter base */
cecr_subblock = ucc_fast_get_qe_cr_subblock(uf_info->ucc_num);
- ret = qe_issue_cmd(QE_ASSIGN_PAGE_TO_DEVICE, cecr_subblock,
- QE_CR_PROTOCOL_UNSPECIFIED, priv->ucc_pram_offset);
+ qe_issue_cmd(QE_ASSIGN_PAGE_TO_DEVICE, cecr_subblock,
+ QE_CR_PROTOCOL_UNSPECIFIED, priv->ucc_pram_offset);
priv->ucc_pram = (struct ucc_hdlc_param __iomem *)
qe_muram_addr(priv->ucc_pram_offset);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 252/459] ACPI: button: Add DMI quirk for Razer Blade Stealth 13 late 2019 lid switch
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jason Ekstrand, Hans de Goede, Rafael J . Wysocki, Sasha Levin,
linux-acpi
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Jason Ekstrand <jason@jlekstrand.net>
[ Upstream commit 0528904926aab19bffb2068879aa44db166c6d5f ]
Running evemu-record on the lid switch event shows that the lid reports
the first "close" but then never reports an "open". This causes systemd
to continuously re-suspend the laptop every 30s. Resetting the _LID to
"open" fixes the issue.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/acpi/button.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index ce93a355bd1c8..985afc62da82a 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -89,6 +89,17 @@ static const struct dmi_system_id lid_blacklst[] = {
},
.driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN,
},
+ {
+ /*
+ * Razer Blade Stealth 13 late 2019, notification of the LID device
+ * only happens on close, not on open and _LID always returns closed.
+ */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Razer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Razer Blade Stealth 13 Late 2019"),
+ },
+ .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN,
+ },
{}
};
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 253/459] iommu/vt-d: Match CPU and IOMMU paging mode
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jacob Pan, Eric Auger, Lu Baolu, Joerg Roedel, Sasha Levin, iommu
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
[ Upstream commit 79db7e1b4cf2a006f556099c13de3b12970fc6e3 ]
When setting up first level page tables for sharing with CPU, we need
to ensure IOMMU can support no less than the levels supported by the
CPU.
It is not adequate, as in the current code, to set up 5-level paging
in PASID entry First Level Paging Mode(FLPM) solely based on CPU.
Currently, intel_pasid_setup_first_level() is only used by native SVM
code which already checks paging mode matches. However, future use of
this helper function may not be limited to native SVM.
https://lkml.org/lkml/2019/11/18/1037
Fixes: 437f35e1cd4c8 ("iommu/vt-d: Add first level page table interface")
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/intel-pasid.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-pasid.c b/drivers/iommu/intel-pasid.c
index 040a445be3009..e7cb0b8a73327 100644
--- a/drivers/iommu/intel-pasid.c
+++ b/drivers/iommu/intel-pasid.c
@@ -499,8 +499,16 @@ int intel_pasid_setup_first_level(struct intel_iommu *iommu,
}
#ifdef CONFIG_X86
- if (cpu_feature_enabled(X86_FEATURE_LA57))
- pasid_set_flpm(pte, 1);
+ /* Both CPU and IOMMU paging mode need to match */
+ if (cpu_feature_enabled(X86_FEATURE_LA57)) {
+ if (cap_5lp_support(iommu->cap)) {
+ pasid_set_flpm(pte, 1);
+ } else {
+ pr_err("VT-d has no 5-level paging support for CPU\n");
+ pasid_clear_entry(pte);
+ return -EINVAL;
+ }
+ }
#endif /* CONFIG_X86 */
pasid_set_domain_id(pte, did);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 254/459] iommu/vt-d: Avoid sending invalid page response
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jacob Pan, Eric Auger, Lu Baolu, Joerg Roedel, Sasha Levin, iommu
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
[ Upstream commit 5f75585e19cc7018bf2016aa771632081ee2f313 ]
Page responses should only be sent when last page in group (LPIG) or
private data is present in the page request. This patch avoids sending
invalid descriptors.
Fixes: 5d308fc1ecf53 ("iommu/vt-d: Add 256-bit invalidation descriptor support")
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/intel-svm.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index ff7a3f9add325..518d0b2d12afd 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -654,11 +654,10 @@ static irqreturn_t prq_event_thread(int irq, void *d)
if (req->priv_data_present)
memcpy(&resp.qw2, req->priv_data,
sizeof(req->priv_data));
+ resp.qw2 = 0;
+ resp.qw3 = 0;
+ qi_submit_sync(&resp, iommu);
}
- resp.qw2 = 0;
- resp.qw3 = 0;
- qi_submit_sync(&resp, iommu);
-
head = (head + sizeof(*req)) & PRQ_RING_MASK;
}
--
2.20.1
^ permalink raw reply related
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Implement Wa_1606931601 (rev5)
From: Patchwork @ 2020-02-14 17:30 UTC (permalink / raw)
To: Anusha Srivatsa; +Cc: intel-gfx
In-Reply-To: <20200211234404.1728-1-anusha.srivatsa@intel.com>
== Series Details ==
Series: drm/i915/tgl: Implement Wa_1606931601 (rev5)
URL : https://patchwork.freedesktop.org/series/72433/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7922_full -> Patchwork_16530_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_16530_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb2/igt@gem_exec_balancer@smoke.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb6/igt@gem_exec_balancer@smoke.html
* igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb6/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb1/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
* igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +7 similar issues
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb6/igt@gem_exec_schedule@preempt-other-chain-bsd.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb1/igt@gem_exec_schedule@preempt-other-chain-bsd.html
* igt@gen7_exec_parse@basic-offset:
- shard-hsw: [PASS][7] -> [FAIL][8] ([i915#694])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-hsw2/igt@gen7_exec_parse@basic-offset.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-hsw2/igt@gen7_exec_parse@basic-offset.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#79])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#79])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +1 similar issue
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-kbl7/igt@kms_flip@flip-vs-suspend-interruptible.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-kbl1/igt@kms_flip@flip-vs-suspend-interruptible.html
* igt@kms_flip@flip-vs-wf_vblank-interruptible:
- shard-skl: [PASS][15] -> [FAIL][16] ([i915#34])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl5/igt@kms_flip@flip-vs-wf_vblank-interruptible.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl5/igt@kms_flip@flip-vs-wf_vblank-interruptible.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
- shard-glk: [PASS][17] -> [FAIL][18] ([i915#49])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-glk6/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-glk1/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +5 similar issues
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-apl3/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl9/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
* igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-glk: [PASS][25] -> [FAIL][26] ([i915#899])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-glk6/igt@kms_plane_lowres@pipe-a-tiling-x.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-glk1/igt@kms_plane_lowres@pipe-a-tiling-x.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][27] -> [SKIP][28] ([fdo#109441]) +4 similar issues
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb4/igt@kms_psr@psr2_primary_page_flip.html
* igt@perf_pmu@busy-no-semaphores-vcs1:
- shard-iclb: [PASS][29] -> [SKIP][30] ([fdo#112080]) +13 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb4/igt@perf_pmu@busy-no-semaphores-vcs1.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb5/igt@perf_pmu@busy-no-semaphores-vcs1.html
* igt@prime_busy@hang-bsd2:
- shard-iclb: [PASS][31] -> [SKIP][32] ([fdo#109276]) +19 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb1/igt@prime_busy@hang-bsd2.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb5/igt@prime_busy@hang-bsd2.html
#### Possible fixes ####
* igt@gem_ctx_isolation@bcs0-s3:
- shard-apl: [DMESG-WARN][33] ([i915#180]) -> [PASS][34] +4 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-apl8/igt@gem_ctx_isolation@bcs0-s3.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-apl2/igt@gem_ctx_isolation@bcs0-s3.html
* {igt@gem_ctx_persistence@engines-mixed-process@bcs0}:
- shard-skl: [FAIL][35] ([i915#679]) -> [PASS][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl7/igt@gem_ctx_persistence@engines-mixed-process@bcs0.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl6/igt@gem_ctx_persistence@engines-mixed-process@bcs0.html
* {igt@gem_ctx_persistence@engines-mixed-process@vcs0}:
- shard-skl: [INCOMPLETE][37] -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl7/igt@gem_ctx_persistence@engines-mixed-process@vcs0.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl6/igt@gem_ctx_persistence@engines-mixed-process@vcs0.html
* igt@gem_exec_balancer@hang:
- shard-tglb: [TIMEOUT][39] ([fdo#112271]) -> [PASS][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-tglb3/igt@gem_exec_balancer@hang.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-tglb3/igt@gem_exec_balancer@hang.html
* igt@gem_exec_schedule@pi-common-bsd:
- shard-iclb: [SKIP][41] ([i915#677]) -> [PASS][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb1/igt@gem_exec_schedule@pi-common-bsd.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb3/igt@gem_exec_schedule@pi-common-bsd.html
* igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [SKIP][43] ([fdo#112146]) -> [PASS][44] +8 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb2/igt@gem_exec_schedule@preemptive-hang-bsd.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb7/igt@gem_exec_schedule@preemptive-hang-bsd.html
* igt@gen7_exec_parse@basic-allocation:
- shard-hsw: [FAIL][45] ([i915#694]) -> [PASS][46]
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-hsw6/igt@gen7_exec_parse@basic-allocation.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-hsw5/igt@gen7_exec_parse@basic-allocation.html
* igt@i915_pm_dc@dc5-dpms:
- shard-iclb: [FAIL][47] ([i915#447]) -> [PASS][48]
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb3/igt@i915_pm_dc@dc5-dpms.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb1/igt@i915_pm_dc@dc5-dpms.html
* igt@i915_pm_dc@dc5-psr:
- shard-tglb: [SKIP][49] ([i915#668]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-tglb1/igt@i915_pm_dc@dc5-psr.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-tglb8/igt@i915_pm_dc@dc5-psr.html
* igt@i915_pm_dc@dc6-dpms:
- shard-iclb: [FAIL][51] ([i915#454]) -> [PASS][52]
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb3/igt@i915_pm_dc@dc6-dpms.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb2/igt@i915_pm_dc@dc6-dpms.html
* igt@i915_pm_rpm@modeset-stress-extra-wait:
- shard-glk: [DMESG-WARN][53] ([i915#118] / [i915#95]) -> [PASS][54]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-glk8/igt@i915_pm_rpm@modeset-stress-extra-wait.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-glk6/igt@i915_pm_rpm@modeset-stress-extra-wait.html
* igt@i915_selftest@live_workarounds:
- shard-tglb: [DMESG-FAIL][55] ([i915#1169]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-tglb3/igt@i915_selftest@live_workarounds.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-tglb1/igt@i915_selftest@live_workarounds.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [DMESG-WARN][57] ([i915#180]) -> [PASS][58] +2 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-kbl1/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding:
- shard-skl: [FAIL][59] ([i915#54]) -> [PASS][60]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl2/igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl1/igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-skl: [INCOMPLETE][61] ([i915#69]) -> [PASS][62]
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl3/igt@kms_fbcon_fbt@psr-suspend.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl6/igt@kms_fbcon_fbt@psr-suspend.html
* igt@kms_psr@psr2_sprite_blt:
- shard-iclb: [SKIP][63] ([fdo#109441]) -> [PASS][64] +2 similar issues
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb3/igt@kms_psr@psr2_sprite_blt.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html
* igt@perf_pmu@busy-vcs1:
- shard-iclb: [SKIP][65] ([fdo#112080]) -> [PASS][66] +18 similar issues
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb8/igt@perf_pmu@busy-vcs1.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb4/igt@perf_pmu@busy-vcs1.html
* igt@prime_mmap_coherency@ioctl-errors:
- shard-hsw: [FAIL][67] ([i915#831]) -> [PASS][68]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-hsw7/igt@prime_mmap_coherency@ioctl-errors.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-hsw6/igt@prime_mmap_coherency@ioctl-errors.html
* igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: [SKIP][69] ([fdo#109276]) -> [PASS][70] +24 similar issues
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb3/igt@prime_vgem@fence-wait-bsd2.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb2/igt@prime_vgem@fence-wait-bsd2.html
* igt@prime_vgem@sync-blt:
- shard-tglb: [INCOMPLETE][71] ([i915#409]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-tglb1/igt@prime_vgem@sync-blt.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-tglb8/igt@prime_vgem@sync-blt.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs1-nonpriv:
- shard-iclb: [FAIL][73] ([IGT#28]) -> [SKIP][74] ([fdo#112080])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb4/igt@gem_ctx_isolation@vcs1-nonpriv.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb5/igt@gem_ctx_isolation@vcs1-nonpriv.html
* igt@gem_tiled_blits@normal:
- shard-hsw: [FAIL][75] ([i915#818]) -> [FAIL][76] ([i915#694])
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-hsw7/igt@gem_tiled_blits@normal.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-hsw1/igt@gem_tiled_blits@normal.html
* igt@i915_pm_rpm@sysfs-read:
- shard-snb: [INCOMPLETE][77] ([i915#82]) -> [SKIP][78] ([fdo#109271])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-snb6/igt@i915_pm_rpm@sysfs-read.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-snb6/igt@i915_pm_rpm@sysfs-read.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [DMESG-WARN][79] ([i915#1226]) -> [SKIP][80] ([fdo#109349])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb4/igt@kms_dp_dsc@basic-dsc-enable-edp.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#28]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1169]: https://gitlab.freedesktop.org/drm/intel/issues/1169
[i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1226]: https://gitlab.freedesktop.org/drm/intel/issues/1226
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34
[i915#409]: https://gitlab.freedesktop.org/drm/intel/issues/409
[i915#447]: https://gitlab.freedesktop.org/drm/intel/issues/447
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
[i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#818]: https://gitlab.freedesktop.org/drm/intel/issues/818
[i915#82]: https://gitlab.freedesktop.org/drm/intel/issues/82
[i915#831]: https://gitlab.freedesktop.org/drm/intel/issues/831
[i915#899]: https://gitlab.freedesktop.org/drm/intel/issues/899
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7922 -> Patchwork_16530
CI-20190529: 20190529
CI_DRM_7922: 0367f4b85f1fbbb1f0df1064803c97d35ed53f24 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5436: 00a64098aaae2ac3154841d76c7b034165380282 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16530: fc2fdf6349df81db142615b3c34cd20aa320e7c5 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/index.html
_______________________________________________
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.