[PATCH net-next 10/12] net: hns3: refactor PF/VF RSS hash key configuration
From: Yufeng Mo
In order to make it more readable, this patch modifies PF/VF's
RSS hash key configuring function.
Signed-off-by: Yufeng Mo
Signed-off-by: Jian Shen
Signed-off-by: Weihang Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 15 +++
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 15 +++
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 7239e3c..e1f4ba1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3609,28 +3609,27 @@ static int hclge_set_rss_algo_key(struct hclge_dev
*hdev,
{
struct hclge_rss_config_cmd *req;
struct hclge_desc desc;
- int key_offset;
+ int key_offset = 0;
+ int key_counts;
int key_size;
int ret;
+ key_counts = HCLGE_RSS_KEY_SIZE;
req = (struct hclge_rss_config_cmd *)desc.data;
- for (key_offset = 0; key_offset < 3; key_offset++) {
+ while (key_counts) {
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_RSS_GENERIC_CONFIG,
false);
req->hash_config |= (hfunc & HCLGE_RSS_HASH_ALGO_MASK);
req->hash_config |= (key_offset << HCLGE_RSS_HASH_KEY_OFFSET_B);
- if (key_offset == 2)
- key_size =
- HCLGE_RSS_KEY_SIZE - HCLGE_RSS_HASH_KEY_NUM * 2;
- else
- key_size = HCLGE_RSS_HASH_KEY_NUM;
-
+ key_size = min(HCLGE_RSS_HASH_KEY_NUM, key_counts);
memcpy(req->hash_key,
key + key_offset * HCLGE_RSS_HASH_KEY_NUM, key_size);
+ key_counts -= key_size;
+ key_offset++;
ret = hclge_cmd_send(&hdev->hw, &desc, 1);
if (ret) {
dev_err(&hdev->pdev->dev,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 3c2ffc7..8aa7167 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -539,13 +539,15 @@ static int hclgevf_set_rss_algo_key(struct hclgevf_dev
*hdev,
{
struct hclgevf_rss_config_cmd *req;
struct hclgevf_desc desc;
- int key_offset;
+ int key_offset = 0;
+ int key_counts;
int key_size;
int ret;
+ key_counts = HCLGEVF_RSS_KEY_SIZE;
req = (struct hclgevf_rss_config_cmd *)desc.data;
- for (key_offset = 0; key_offset < 3; key_offset++) {
+ while (key_counts) {
hclgevf_cmd_setup_basic_desc(&desc,
HCLGEVF_OPC_RSS_GENERIC_CONFIG,
false);
@@ -554,15 +556,12 @@ static int hclgevf_set_rss_algo_key(struct hclgevf_dev
*hdev,
req->hash_config |=
(key_offset << HCLGEVF_RSS_HASH_KEY_OFFSET_B);
- if (key_offset == 2)
- key_size =
- HCLGEVF_RSS_KEY_SIZE - HCLGEVF_RSS_HASH_KEY_NUM * 2;
- else
- key_size = HCLGEVF_RSS_HASH_KEY_NUM;
-
+ key_size = min(HCLGEVF_RSS_HASH_KEY_NUM, key_counts);
memcpy(req->hash_key,
key + key_offset * HCLGEVF_RSS_HASH_KEY_NUM, key_size);
+ key_counts -= key_size;
+ key_offset++;
ret = hclgevf_cmd_send(&hdev->hw, &desc, 1);
if (ret) {
dev_err(&hdev->pdev->dev,
--
2.7.4
[PATCH net-next 11/12] net: hns3: some modifications to simplify and optimize code
From: Yufeng Mo
This patch deletes some redundant code and refactors some bloated
functions.
Signed-off-by: Yufeng Mo
Signed-off-by: Weihang Li
Signed-off-by: Yonglong Liu
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 32 +++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 102 ++---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 2 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 99 ++--
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 25 ++---
5 files changed, 151 insertions(+), 109 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 22526ba..49b4072 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -436,7 +436,7 @@ static void hns3_get_strings(struct net_device *netdev, u32
stringset, u8 *data)
switch (stringset) {
case ETH_SS_STATS:
buff = hns3_get_strings_tqps(h, buff);
- h->ae_algo->ops->get_strings(h, stringset, (u8 *)buff);
+ ops->get_strings(h, stringset, (u8 *)buff);
break;
case ETH_SS_TEST:
ops->get_strings(h, stringset, data);
@@ -511,6 +511,11 @@ static void hns3_get_drvinfo(struct net_device *netdev,
struct hns3_nic_priv *priv = netdev_priv(netdev);
struct hnae3_handle *h = priv->ae_handle;
+ if (!h->ae_algo->ops->get_fw_version) {
+ netdev_err(netdev, "could not get fw version!\n");
+ return;
+ }
+
strncpy(drvinfo->version, hns3_driver_version,
sizeof(drvinfo->version));
drvinfo->version[sizeof(drvinfo->version) - 1] = '\0';
@@ -531,7 +536,7 @@ static u32 hns3_get_link(struct net_device *netdev)
{
struct hnae3_handle *h = hns3_get_handle(netdev);
- if (h->ae_algo && h->ae_algo->ops && h->ae_algo->ops->get_status)
+ if (h->ae_algo->ops->get_status)
return h->ae_algo->ops->get_status(h);
else
return 0;
@@ -561,7 +566,7 @@ static void hns3_get_pauseparam(struct net_device *netdev,
{
struct hnae3_handle *h = hns3_get_handle(netdev);
- if (h->ae_algo && h->ae_algo->ops && h->ae_algo->ops->get_pauseparam)
+ if (h->ae_algo->ops->get_pauseparam)
h->ae_algo->ops->get_pauseparam(h, ¶m->autoneg,
¶m->rx_pause, ¶m->tx_pause);
}
@@ -611,9 +616,6 @@ static int hns3_get_link_ksettings(struct net_device
*netdev,
u8 media_type;
u8 link_stat;
- if (!h->ae_algo || !h->ae_algo->ops)
- return -EOPNOTSUPP;
-
ops = h->ae_algo->ops;
if (ops->get_media_type)
ops->get_media_type(h, &media_type, &module_type);
@@ -741,8 +743,7 @@ static u32 hns3_get_rss_key_size(struct net_device *netdev)
{
struct hnae3_handle *h = hns3_get_handle(netdev);
- if (!h->ae_algo || !h->ae_algo->ops ||
- !h->ae_algo->ops->get_rss_key_size)
+ if (!h->ae_algo->ops->get_rss_key_size)
return 0;
return h->ae_algo->ops->get_rss_key_size(h);
@@ -752,8 +753,7 @@ static u32 hns3_get_rss_indir_size(struct net_device
*netdev)
{
struct hnae3_handle *h = hns3_get_handle(netdev);
- if (!h->ae_algo || !h->ae_algo->ops ||
- !h->ae_algo->ops->get_rss_indir_size)
+ if (!h->ae_algo->ops->get_rss_indir_size)
return 0;
return h->ae_algo->ops->get_rss_indir_size(h);
@@ -764,7 +764,7 @@ static int hns3_get_rss(struct net_device *netdev, u32
*indir, u8 *key,
{
struct hnae3_handle *h = hns3_get_handle(netdev);
- if (!h->ae_algo || !h->ae_algo->ops || !h->ae_algo->ops->get_rss)
+ if (!h->ae_algo->ops->get_rss)
return -EOPNOTSUPP;
return h->ae_algo->ops->get_rss(h, indir, key, hfunc);
@@ -775,7 +775,7 @@ static int hns3_set_rss(struct net_device *netdev, const
u32 *indir,
{
struct hnae3_handle *h = hns3_get_handle(netdev);
- if (!h->ae_algo || !h->ae_algo->ops || !h->ae_algo->ops->set_rss)
+ if (!h->ae_algo->ops->set_rss)
return -EOPNOTSUPP;
if ((h->pdev->revision == 0x20 &&
@@ -800,9 +800,6 @@ static int hns3_get_rxnfc(struct net_device *netdev,
{
struct hnae3_handle *h = hns3_get_handle(netdev);
- if (!h->ae_algo || !h->ae_algo->ops)
- return -EOPNOTSUPP;
-
switch (cmd->cmd) {
case ETHTOOL_GRXRINGS:
cmd->data = h->kinfo.num_tqps;
@@ -916,9 +913,6 @@ static int hns3_set_rxnfc(struct net_device *netdev, struct
ethtool_rxnfc *cmd)
{
struct hnae3_handle *h = hns3_get_handle(netdev);
- if (!h->ae_algo || !h->ae_algo->ops)
- return -EOPNOTSUPP;
-
switch (cmd->cmd) {
case ETHTOOL_SRXFH:
[PATCH net-next 07/12] net: hns3: Delete the redundant user nic codes
From: Yonglong Liu
Since HNAE3_CLIENT_UNIC and HNAE3_DEV_UNIC is not used any more,
this patch removes the redundant codes.
Signed-off-by: Yonglong Liu
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hnae3.c| 21 -
drivers/net/ethernet/hisilicon/hns3/hnae3.h| 7 -
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 1 -
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 34 --
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 16 --
5 files changed, 10 insertions(+), 69 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 738e013..0de3d6b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -16,14 +16,10 @@ static LIST_HEAD(hnae3_ae_dev_list);
*/
static DEFINE_MUTEX(hnae3_common_lock);
-static bool hnae3_client_match(enum hnae3_client_type client_type,
- enum hnae3_dev_type dev_type)
+static bool hnae3_client_match(enum hnae3_client_type client_type)
{
- if ((dev_type == HNAE3_DEV_KNIC) && (client_type == HNAE3_CLIENT_KNIC ||
-client_type == HNAE3_CLIENT_ROCE))
- return true;
-
- if (dev_type == HNAE3_DEV_UNIC && client_type == HNAE3_CLIENT_UNIC)
+ if (client_type == HNAE3_CLIENT_KNIC ||
+ client_type == HNAE3_CLIENT_ROCE)
return true;
return false;
@@ -39,9 +35,6 @@ void hnae3_set_client_init_flag(struct hnae3_client *client,
case HNAE3_CLIENT_KNIC:
hnae3_set_bit(ae_dev->flag, HNAE3_KNIC_CLIENT_INITED_B, inited);
break;
- case HNAE3_CLIENT_UNIC:
- hnae3_set_bit(ae_dev->flag, HNAE3_UNIC_CLIENT_INITED_B, inited);
- break;
case HNAE3_CLIENT_ROCE:
hnae3_set_bit(ae_dev->flag, HNAE3_ROCE_CLIENT_INITED_B, inited);
break;
@@ -61,10 +54,6 @@ static int hnae3_get_client_init_flag(struct hnae3_client
*client,
inited = hnae3_get_bit(ae_dev->flag,
HNAE3_KNIC_CLIENT_INITED_B);
break;
- case HNAE3_CLIENT_UNIC:
- inited = hnae3_get_bit(ae_dev->flag,
- HNAE3_UNIC_CLIENT_INITED_B);
- break;
case HNAE3_CLIENT_ROCE:
inited = hnae3_get_bit(ae_dev->flag,
HNAE3_ROCE_CLIENT_INITED_B);
@@ -82,7 +71,7 @@ static int hnae3_init_client_instance(struct hnae3_client
*client,
int ret;
/* check if this client matches the type of ae_dev */
- if (!(hnae3_client_match(client->type, ae_dev->dev_type) &&
+ if (!(hnae3_client_match(client->type) &&
hnae3_get_bit(ae_dev->flag, HNAE3_DEV_INITED_B))) {
return 0;
}
@@ -99,7 +88,7 @@ static void hnae3_uninit_client_instance(struct hnae3_client
*client,
struct hnae3_ae_dev *ae_dev)
{
/* check if this client matches the type of ae_dev */
- if (!(hnae3_client_match(client->type, ae_dev->dev_type) &&
+ if (!(hnae3_client_match(client->type) &&
hnae3_get_bit(ae_dev->flag, HNAE3_DEV_INITED_B)))
return;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 2e478d9..63cdc18 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -102,15 +102,9 @@ enum hnae3_loop {
enum hnae3_client_type {
HNAE3_CLIENT_KNIC,
- HNAE3_CLIENT_UNIC,
HNAE3_CLIENT_ROCE,
};
-enum hnae3_dev_type {
- HNAE3_DEV_KNIC,
- HNAE3_DEV_UNIC,
-};
-
/* mac media type */
enum hnae3_media_type {
HNAE3_MEDIA_TYPE_UNKNOWN,
@@ -220,7 +214,6 @@ struct hnae3_ae_dev {
struct list_head node;
u32 flag;
u8 override_pci_need_reset; /* fix to stop multiple reset happening */
- enum hnae3_dev_type dev_type;
enum hnae3_reset_type reset_type;
void *priv;
};
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 0ef4470..07e7c3a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1837,7 +1837,6 @@ static int hns3_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
ae_dev->pdev = pdev;
ae_dev->flag = ent->driver_data;
- ae_dev->dev_type = HNAE3_DEV_KNIC;
ae_dev->reset_type = HNAE3_NONE_RESET;
hns3_get_dev_capability(pdev, ae_dev);
pci_set_drvdata(pdev, ae_dev);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 35d2a45..9fe00a8 100
[PATCH net-next 08/12] net: hns3: small changes for magic numbers
From: Jian Shen
In order to improve readability, this patch uses macros to
replace some magic numbers, and adds some comments for some
others.
Signed-off-by: Jian Shen
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 118 +++--
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 24 +++--
2 files changed, 79 insertions(+), 63 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 9fe00a8..36a92a1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -4490,19 +4490,19 @@ static bool hclge_fd_convert_tuple(u32 tuple_bit, u8
*key_x, u8 *key_y,
case 0:
return false;
case BIT(INNER_DST_MAC):
- for (i = 0; i < 6; i++) {
- calc_x(key_x[5 - i], rule->tuples.dst_mac[i],
+ for (i = 0; i < ETH_ALEN; i++) {
+ calc_x(key_x[ETH_ALEN - 1 - i], rule->tuples.dst_mac[i],
rule->tuples_mask.dst_mac[i]);
- calc_y(key_y[5 - i], rule->tuples.dst_mac[i],
+ calc_y(key_y[ETH_ALEN - 1 - i], rule->tuples.dst_mac[i],
rule->tuples_mask.dst_mac[i]);
}
return true;
case BIT(INNER_SRC_MAC):
- for (i = 0; i < 6; i++) {
- calc_x(key_x[5 - i], rule->tuples.src_mac[i],
+ for (i = 0; i < ETH_ALEN; i++) {
+ calc_x(key_x[ETH_ALEN - 1 - i], rule->tuples.src_mac[i],
rule->tuples.src_mac[i]);
- calc_y(key_y[5 - i], rule->tuples.src_mac[i],
+ calc_y(key_y[ETH_ALEN - 1 - i], rule->tuples.src_mac[i],
rule->tuples.src_mac[i]);
}
@@ -4538,19 +4538,19 @@ static bool hclge_fd_convert_tuple(u32 tuple_bit, u8
*key_x, u8 *key_y,
return true;
case BIT(INNER_SRC_IP):
- calc_x(tmp_x_l, rule->tuples.src_ip[3],
- rule->tuples_mask.src_ip[3]);
- calc_y(tmp_y_l, rule->tuples.src_ip[3],
- rule->tuples_mask.src_ip[3]);
+ calc_x(tmp_x_l, rule->tuples.src_ip[IPV4_INDEX],
+ rule->tuples_mask.src_ip[IPV4_INDEX]);
+ calc_y(tmp_y_l, rule->tuples.src_ip[IPV4_INDEX],
+ rule->tuples_mask.src_ip[IPV4_INDEX]);
*(__le32 *)key_x = cpu_to_le32(tmp_x_l);
*(__le32 *)key_y = cpu_to_le32(tmp_y_l);
return true;
case BIT(INNER_DST_IP):
- calc_x(tmp_x_l, rule->tuples.dst_ip[3],
- rule->tuples_mask.dst_ip[3]);
- calc_y(tmp_y_l, rule->tuples.dst_ip[3],
- rule->tuples_mask.dst_ip[3]);
+ calc_x(tmp_x_l, rule->tuples.dst_ip[IPV4_INDEX],
+ rule->tuples_mask.dst_ip[IPV4_INDEX]);
+ calc_y(tmp_y_l, rule->tuples.dst_ip[IPV4_INDEX],
+ rule->tuples_mask.dst_ip[IPV4_INDEX]);
*(__le32 *)key_x = cpu_to_le32(tmp_x_l);
*(__le32 *)key_y = cpu_to_le32(tmp_y_l);
@@ -4799,6 +4799,7 @@ static int hclge_fd_check_spec(struct hclge_dev *hdev,
*unused |= BIT(INNER_SRC_MAC) | BIT(INNER_DST_MAC) |
BIT(INNER_IP_TOS);
+ /* check whether src/dst ip address used */
if (!tcp_ip6_spec->ip6src[0] && !tcp_ip6_spec->ip6src[1] &&
!tcp_ip6_spec->ip6src[2] && !tcp_ip6_spec->ip6src[3])
*unused |= BIT(INNER_SRC_IP);
@@ -4823,6 +4824,7 @@ static int hclge_fd_check_spec(struct hclge_dev *hdev,
BIT(INNER_IP_TOS) | BIT(INNER_SRC_PORT) |
BIT(INNER_DST_PORT);
+ /* check whether src/dst ip address used */
if (!usr_ip6_spec->ip6src[0] && !usr_ip6_spec->ip6src[1] &&
!usr_ip6_spec->ip6src[2] && !usr_ip6_spec->ip6src[3])
*unused |= BIT(INNER_SRC_IP);
@@ -4966,14 +4968,14 @@ static int hclge_fd_get_tuple(struct hclge_dev *hdev,
case SCTP_V4_FLOW:
case TCP_V4_FLOW:
case UDP_V4_FLOW:
- rule->tuples.src_ip[3] =
+ rule->tuples.src_ip[IPV4_INDEX] =
be32_to_cpu(fs->h_u.tcp_ip4_spec.ip4src);
- rule->tuples_mask.src_ip[3] =
+ rule->tuples_mask.src_ip[IPV4_INDEX] =
be32_to_cpu(fs->m_u.tcp_ip4_spec.ip4src);
- rule->tuples.dst_ip[3] =
+ rule->tuples.dst_ip[IPV4_INDEX] =
be32_to_cpu(fs->h_u.tcp_ip4_spec.ip4dst);
- rul
Re: [PATCH v8 01/13] clk: samsung: add needed IDs for DMC clocks in Exynos5420
On Wed, 5 Jun 2019 at 18:54, Lukasz Luba wrote: > > Define new IDs for clocks used by Dynamic Memory Controller in > Exynos5422 SoC. > > Acked-by: Rob Herring > Acked-by: Chanwoo Choi > Signed-off-by: Lukasz Luba > --- > include/dt-bindings/clock/exynos5420.h | 18 +- > 1 file changed, 17 insertions(+), 1 deletion(-) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
[PATCH net-next 09/12] net: hns3: use macros instead of magic numbers
From: Yufeng Mo
This patch adds some macros instead of magic numbers in serval places
Signed-off-by: Yufeng Mo
Signed-off-by: Weihang Li
Signed-off-by: Yunsheng Lin
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 5 ++-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 5 +++
.../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 9 ++--
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 52 ++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 2 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 19 +---
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 11 +++--
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 3 ++
8 files changed, 72 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index d1588ea..22526ba 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -60,6 +60,7 @@ static const struct hns3_stats hns3_rxq_stats[] = {
#define HNS3_NIC_LB_TEST_PKT_NUM 1
#define HNS3_NIC_LB_TEST_RING_ID 0
#define HNS3_NIC_LB_TEST_PACKET_SIZE 128
+#define HNS3_NIC_LB_SETUP_USEC 1
/* Nic loopback test err */
#define HNS3_NIC_LB_TEST_NO_MEM_ERR1
@@ -117,7 +118,7 @@ static int hns3_lp_up(struct net_device *ndev, enum
hnae3_loop loop_mode)
return ret;
ret = hns3_lp_setup(ndev, loop_mode, true);
- usleep_range(1, 2);
+ usleep_range(HNS3_NIC_LB_SETUP_USEC, HNS3_NIC_LB_SETUP_USEC * 2);
return ret;
}
@@ -132,7 +133,7 @@ static int hns3_lp_down(struct net_device *ndev, enum
hnae3_loop loop_mode)
return ret;
}
- usleep_range(1, 2);
+ usleep_range(HNS3_NIC_LB_SETUP_USEC, HNS3_NIC_LB_SETUP_USEC * 2);
return 0;
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 7d78b5a..c9fd730 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -649,6 +649,11 @@ enum hclge_mac_vlan_tbl_opcode {
HCLGE_MAC_VLAN_LKUP,/* Lookup a entry through mac_vlan key */
};
+enum hclge_mac_vlan_add_resp_code {
+ HCLGE_ADD_UC_OVERFLOW = 2, /* ADD failed for UC overflow */
+ HCLGE_ADD_MC_OVERFLOW, /* ADD failed for MC overflow */
+};
+
#define HCLGE_MAC_VLAN_BIT0_EN_B 0
#define HCLGE_MAC_VLAN_BIT1_EN_B 1
#define HCLGE_MAC_EPORT_SW_EN_B12
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
index e1007d9..d4a8ae8 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c
@@ -64,6 +64,7 @@ static void hclge_dbg_dump_reg_common(struct hclge_dev *hdev,
char *cmd_buf, int msg_num, int offset,
enum hclge_opcode_type cmd)
{
+#define BD_DATA_NUM 6
struct hclge_desc *desc_src;
struct hclge_desc *desc;
int bd_num, buf_len;
@@ -92,14 +93,16 @@ static void hclge_dbg_dump_reg_common(struct hclge_dev
*hdev,
return;
}
- max = (bd_num * 6) <= msg_num ? (bd_num * 6) : msg_num;
+ max = (bd_num * BD_DATA_NUM) <= msg_num ?
+ (bd_num * BD_DATA_NUM) : msg_num;
desc = desc_src;
for (i = 0; i < max; i++) {
- (((i / 6) > 0) && ((i % 6) == 0)) ? desc++ : desc;
+ ((i > 0) && ((i % BD_DATA_NUM) == 0)) ? desc++ : desc;
if (dfx_message->flag)
dev_info(&hdev->pdev->dev, "%s: 0x%x\n",
-dfx_message->message, desc->data[i % 6]);
+dfx_message->message,
+desc->data[i % BD_DATA_NUM]);
dfx_message++;
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 36a92a1..7239e3c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -28,6 +28,8 @@
#define HCLGE_MAC_STATS_FIELD_OFF(f) (offsetof(struct hclge_mac_stats, f))
#define HCLGE_BUF_SIZE_UNIT256
+#define HCLGE_BUF_MUL_BY 2
+#define HCLGE_BUF_DIV_BY 2
static int hclge_set_mac_mtu(struct hclge_dev *hdev, int new_mps);
static int hclge_init_vlan_config(struct hclge_dev *hdev);
@@ -728,6 +730,8 @@ static int hclge_parse_func_status(struct hclge_dev *hdev,
static int hclge_query_function_status(struct hclge_dev *hdev)
{
+#define HCLGE_QUERY_MAX_CNT5
+
struct hclge_func_status_cmd *req;
struct hclge
[PATCH net-next 01/12] net: hns3: log detail error info of ROCEE ECC and AXI errors
From: Xiaofei Tan
This patch logs detail error info of ROCEE ECC and AXI errors for
debug purpose, and remove unnecessary reset for ROCEE overflow
errors.
Signed-off-by: Xiaofei Tan
Signed-off-by: Huazhong Tan
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 2 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 87 --
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h | 1 +
3 files changed, 83 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 61cb10d..5e6c749 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -268,6 +268,8 @@ enum hclge_opcode_type {
HCLGE_CONFIG_ROCEE_RAS_INT_EN = 0x1580,
HCLGE_QUERY_CLEAR_ROCEE_RAS_INT = 0x1581,
HCLGE_ROCEE_PF_RAS_INT_CMD = 0x1584,
+ HCLGE_QUERY_ROCEE_ECC_RAS_INFO_CMD = 0x1585,
+ HCLGE_QUERY_ROCEE_AXI_RAS_INFO_CMD = 0x1586,
HCLGE_IGU_EGU_TNL_INT_EN= 0x1803,
HCLGE_IGU_COMMON_INT_EN = 0x1806,
HCLGE_TM_QCN_MEM_INT_CFG= 0x1A14,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
index 784512d..64defd3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
@@ -1388,6 +1388,66 @@ static int hclge_handle_all_ras_errors(struct hclge_dev
*hdev)
return ret;
}
+static int hclge_log_rocee_axi_error(struct hclge_dev *hdev)
+{
+ struct device *dev = &hdev->pdev->dev;
+ struct hclge_desc desc[3];
+ int ret;
+
+ hclge_cmd_setup_basic_desc(&desc[0], HCLGE_QUERY_ROCEE_AXI_RAS_INFO_CMD,
+ true);
+ hclge_cmd_setup_basic_desc(&desc[1], HCLGE_QUERY_ROCEE_AXI_RAS_INFO_CMD,
+ true);
+ hclge_cmd_setup_basic_desc(&desc[2], HCLGE_QUERY_ROCEE_AXI_RAS_INFO_CMD,
+ true);
+ desc[0].flag |= cpu_to_le16(HCLGE_CMD_FLAG_NEXT);
+ desc[1].flag |= cpu_to_le16(HCLGE_CMD_FLAG_NEXT);
+
+ ret = hclge_cmd_send(&hdev->hw, &desc[0], 3);
+ if (ret) {
+ dev_err(dev, "failed(%d) to query ROCEE AXI error sts\n", ret);
+ return ret;
+ }
+
+ dev_info(dev, "AXI1: %08X %08X %08X %08X %08X %08X\n",
+le32_to_cpu(desc[0].data[0]), le32_to_cpu(desc[0].data[1]),
+le32_to_cpu(desc[0].data[2]), le32_to_cpu(desc[0].data[3]),
+le32_to_cpu(desc[0].data[4]), le32_to_cpu(desc[0].data[5]));
+ dev_info(dev, "AXI2: %08X %08X %08X %08X %08X %08X\n",
+le32_to_cpu(desc[1].data[0]), le32_to_cpu(desc[1].data[1]),
+le32_to_cpu(desc[1].data[2]), le32_to_cpu(desc[1].data[3]),
+le32_to_cpu(desc[1].data[4]), le32_to_cpu(desc[1].data[5]));
+ dev_info(dev, "AXI3: %08X %08X %08X %08X\n",
+le32_to_cpu(desc[2].data[0]), le32_to_cpu(desc[2].data[1]),
+le32_to_cpu(desc[2].data[2]), le32_to_cpu(desc[2].data[3]));
+
+ return 0;
+}
+
+static int hclge_log_rocee_ecc_error(struct hclge_dev *hdev)
+{
+ struct device *dev = &hdev->pdev->dev;
+ struct hclge_desc desc[2];
+ int ret;
+
+ ret = hclge_cmd_query_error(hdev, &desc[0],
+ HCLGE_QUERY_ROCEE_ECC_RAS_INFO_CMD,
+ HCLGE_CMD_FLAG_NEXT, 0, 0);
+ if (ret) {
+ dev_err(dev, "failed(%d) to query ROCEE ECC error sts\n", ret);
+ return ret;
+ }
+
+ dev_info(dev, "ECC1: %08X %08X %08X %08X %08X %08X\n",
+le32_to_cpu(desc[0].data[0]), le32_to_cpu(desc[0].data[1]),
+le32_to_cpu(desc[0].data[2]), le32_to_cpu(desc[0].data[3]),
+le32_to_cpu(desc[0].data[4]), le32_to_cpu(desc[0].data[5]));
+ dev_info(dev, "ECC2: %08X %08X %08X\n", le32_to_cpu(desc[1].data[0]),
+le32_to_cpu(desc[1].data[1]), le32_to_cpu(desc[1].data[2]));
+
+ return 0;
+}
+
static int hclge_log_rocee_ovf_error(struct hclge_dev *hdev)
{
struct device *dev = &hdev->pdev->dev;
@@ -1456,19 +1516,33 @@ hclge_log_and_clear_rocee_ras_error(struct hclge_dev
*hdev)
status = le32_to_cpu(desc[0].data[0]);
- if (status & HCLGE_ROCEE_RERR_INT_MASK) {
- dev_warn(dev, "ROCEE RAS AXI rresp error\n");
- reset_type = HNAE3_FUNC_RESET;
- }
+ if (status & HCLGE_ROCEE_AXI_ERR_INT_MASK) {
+ if (status & HCLGE_ROCEE_RERR_INT_MASK)
+ dev_warn(dev, "ROCEE RAS AXI rresp error\n");
+
+ if (status & HCLGE_ROCEE_BERR_INT_MASK)
+ dev_warn(dev, "ROCEE RAS AXI bresp error\n");
- if (status & HCLGE_ROCEE_BERR
[PATCH net-next 06/12] net: hns3: trigger VF reset if a VF has an over_8bd_nfe_err
From: Weihang Li
We trigger PF reset when a RAS error of NIC named over_8bd_nfe_err
occurred before. But it is possible that a VF causes that error, it's
reasonable to trigger VF reset instead of PF reset in this case.
This patch add detection of vf_id if a over_8bd_nfe_err occurs, if
vf_id is 0, we trigger PF reset. Otherwise, we will trigger VF reset
on the VF with error.
Signed-off-by: Weihang Li
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 17 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 79 ++
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h | 3 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 2 +-
4 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 5e6c749..7d78b5a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -180,6 +180,9 @@ enum hclge_opcode_type {
HCLGE_OPC_CFG_COM_TQP_QUEUE = 0x0B20,
HCLGE_OPC_RESET_TQP_QUEUE = 0x0B22,
+ /* PPU commands */
+ HCLGE_OPC_PPU_PF_OTHER_INT_DFX = 0x0B4A,
+
/* TSO command */
HCLGE_OPC_TSO_GENERIC_CONFIG= 0x0C01,
HCLGE_OPC_GRO_GENERIC_CONFIG= 0x0C10,
@@ -980,6 +983,20 @@ struct hclge_get_m7_bd_cmd {
u8 rsv[20];
};
+struct hclge_query_ppu_pf_other_int_dfx_cmd {
+ __le16 over_8bd_no_fe_qid;
+ __le16 over_8bd_no_fe_vf_id;
+ __le16 tso_mss_cmp_min_err_qid;
+ __le16 tso_mss_cmp_min_err_vf_id;
+ __le16 tso_mss_cmp_max_err_qid;
+ __le16 tso_mss_cmp_max_err_vf_id;
+ __le16 tx_rd_fbd_poison_qid;
+ __le16 tx_rd_fbd_poison_vf_id;
+ __le16 rx_rd_fbd_poison_qid;
+ __le16 rx_rd_fbd_poison_vf_id;
+ u8 rsv[4];
+};
+
int hclge_cmd_init(struct hclge_dev *hdev);
static inline void hclge_write_reg(void __iomem *base, u32 reg, u32 value)
{
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
index 64defd3..4a40b0a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
@@ -1693,6 +1693,81 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct
hnae3_ae_dev *ae_dev)
return PCI_ERS_RESULT_RECOVERED;
}
+/* hclge_query_8bd_info: query information about over_8bd_nfe_err
+ * @hdev: pointer to struct hclge_dev
+ * @vf_id: Index of the virtual function with error
+ * @q_id: Physical index of the queue with error
+ *
+ * This function get specific index of queue and function which causes
+ * over_8bd_nfe_err by using command. If vf_id is 0, it means error is
+ * caused by PF instead of VF.
+ */
+static int hclge_query_over_8bd_err_info(struct hclge_dev *hdev, u16 *vf_id,
+u16 *q_id)
+{
+ struct hclge_query_ppu_pf_other_int_dfx_cmd *req;
+ struct hclge_desc desc;
+ int ret;
+
+ hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_PPU_PF_OTHER_INT_DFX, true);
+ ret = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (ret)
+ return ret;
+
+ req = (struct hclge_query_ppu_pf_other_int_dfx_cmd *)desc.data;
+ *vf_id = le16_to_cpu(req->over_8bd_no_fe_vf_id);
+ *q_id = le16_to_cpu(req->over_8bd_no_fe_qid);
+
+ return 0;
+}
+
+/* hclge_handle_over_8bd_err: handle MSI-X error named over_8bd_nfe_err
+ * @hdev: pointer to struct hclge_dev
+ * @reset_requests: reset level that we need to trigger later
+ *
+ * over_8bd_nfe_err is a special MSI-X because it may caused by a VF, in
+ * that case, we need to trigger VF reset. Otherwise, a PF reset is needed.
+ */
+static void hclge_handle_over_8bd_err(struct hclge_dev *hdev,
+ unsigned long *reset_requests)
+{
+ struct device *dev = &hdev->pdev->dev;
+ u16 vf_id;
+ u16 q_id;
+ int ret;
+
+ ret = hclge_query_over_8bd_err_info(hdev, &vf_id, &q_id);
+ if (ret) {
+ dev_err(dev, "fail(%d) to query over_8bd_no_fe info\n",
+ ret);
+ return;
+ }
+
+ dev_warn(dev, "PPU_PF_ABNORMAL_INT_ST over_8bd_no_fe found, vf_id(%d),
queue_id(%d)\n",
+vf_id, q_id);
+
+ if (vf_id) {
+ if (vf_id >= hdev->num_alloc_vport) {
+ dev_err(dev, "invalid vf id(%d)\n", vf_id);
+ return;
+ }
+
+ /* If we need to trigger other reset whose level is higher
+* than HNAE3_VF_FUNC_RESET, no need to trigger a VF reset
+* here.
+*/
+ if (*reset_requests != 0)
+ return;
+
+ ret = hclge_inform_reset_assert_to_vf(&hdev->vport[vf_id]);
+ if
[PATCH net-next 02/12] net: hns3: fix wrong size of mailbox responding data
From: Zhongzhu Liu
According to user manual, the maximum size of mailbox responding
data is 8 bytes, the macro HCLGE_MBX_MAX_RESP_DATA_SIZE
should be defined as 8 instead of 16.
Fixes: 9194d18b0577 ("net: hns3: fix the problem that the supported port is
empty")
Signed-off-by: Zhongzhu Liu
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
index 83e19c6..8ad5292 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
@@ -69,7 +69,7 @@ enum hclge_mbx_vlan_cfg_subcode {
};
#define HCLGE_MBX_MAX_MSG_SIZE 16
-#define HCLGE_MBX_MAX_RESP_DATA_SIZE 16
+#define HCLGE_MBX_MAX_RESP_DATA_SIZE 8
#define HCLGE_MBX_RING_MAP_BASIC_MSG_NUM 3
#define HCLGE_MBX_RING_NODE_VARIABLE_NUM 3
--
2.7.4
[PATCH net-next 03/12] net: hns3: make HW GRO handling compliant with SW GRO
From: Yunsheng Lin
Currently when a GRO packet is assembled by HW, the checksum is
modified to reflect the entire packet by HW and skb->ip_summed is
set to CHECKSUM_UNNECESSARY, which is not compliant with SW GRO.
This patch sets up skb's network and transport header, sets the
GRO packet's checksum according to pseudo header and set the
skb->ip_summed to CHECKSUM_PARTIAL.
This patch also use gso_size to distinguish GRO packet from
normal packet, use eth_type_vlan to check the VLAN type and set
the SKB_GSO_TCP_FIXEDID according to BD info during HW GRO info
processing.
Signed-off-by: Yunsheng Lin
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 44 +
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 0501b78..c37509e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2384,13 +2385,13 @@ static void hns3_nic_reuse_page(struct sk_buff *skb,
int i,
}
}
-static int hns3_gro_complete(struct sk_buff *skb)
+static int hns3_gro_complete(struct sk_buff *skb, u32 l234info)
{
__be16 type = skb->protocol;
struct tcphdr *th;
int depth = 0;
- while (type == htons(ETH_P_8021Q)) {
+ while (eth_type_vlan(type)) {
struct vlan_hdr *vh;
if ((depth + VLAN_HLEN) > skb_headlen(skb))
@@ -2401,10 +2402,24 @@ static int hns3_gro_complete(struct sk_buff *skb)
depth += VLAN_HLEN;
}
+ skb_set_network_header(skb, depth);
+
if (type == htons(ETH_P_IP)) {
+ const struct iphdr *iph = ip_hdr(skb);
+
depth += sizeof(struct iphdr);
+ skb_set_transport_header(skb, depth);
+ th = tcp_hdr(skb);
+ th->check = ~tcp_v4_check(skb->len - depth, iph->saddr,
+ iph->daddr, 0);
} else if (type == htons(ETH_P_IPV6)) {
+ const struct ipv6hdr *iph = ipv6_hdr(skb);
+
depth += sizeof(struct ipv6hdr);
+ skb_set_transport_header(skb, depth);
+ th = tcp_hdr(skb);
+ th->check = ~tcp_v6_check(skb->len - depth, &iph->saddr,
+ &iph->daddr, 0);
} else {
netdev_err(skb->dev,
"Error: FW GRO supports only IPv4/IPv6, not 0x%04x,
depth: %d\n",
@@ -2412,13 +2427,16 @@ static int hns3_gro_complete(struct sk_buff *skb)
return -EFAULT;
}
- th = (struct tcphdr *)(skb->data + depth);
skb_shinfo(skb)->gso_segs = NAPI_GRO_CB(skb)->count;
if (th->cwr)
skb_shinfo(skb)->gso_type |= SKB_GSO_TCP_ECN;
- skb->ip_summed = CHECKSUM_UNNECESSARY;
+ if (l234info & BIT(HNS3_RXD_GRO_FIXID_B))
+ skb_shinfo(skb)->gso_type |= SKB_GSO_TCP_FIXEDID;
+ skb->csum_start = (unsigned char *)th - skb->head;
+ skb->csum_offset = offsetof(struct tcphdr, check);
+ skb->ip_summed = CHECKSUM_PARTIAL;
return 0;
}
@@ -2656,18 +2674,20 @@ static int hns3_set_gro_and_checksum(struct
hns3_enet_ring *ring,
struct sk_buff *skb, u32 l234info,
u32 bd_base_info, u32 ol_info)
{
- u16 gro_count;
u32 l3_type;
- gro_count = hnae3_get_field(l234info, HNS3_RXD_GRO_COUNT_M,
- HNS3_RXD_GRO_COUNT_S);
+ skb_shinfo(skb)->gso_size = hnae3_get_field(bd_base_info,
+ HNS3_RXD_GRO_SIZE_M,
+ HNS3_RXD_GRO_SIZE_S);
/* if there is no HW GRO, do not set gro params */
- if (!gro_count) {
+ if (!skb_shinfo(skb)->gso_size) {
hns3_rx_checksum(ring, skb, l234info, bd_base_info, ol_info);
return 0;
}
- NAPI_GRO_CB(skb)->count = gro_count;
+ NAPI_GRO_CB(skb)->count = hnae3_get_field(l234info,
+ HNS3_RXD_GRO_COUNT_M,
+ HNS3_RXD_GRO_COUNT_S);
l3_type = hnae3_get_field(l234info, HNS3_RXD_L3ID_M,
HNS3_RXD_L3ID_S);
@@ -2678,11 +2698,7 @@ static int hns3_set_gro_and_checksum(struct
hns3_enet_ring *ring,
else
return -EFAULT;
- skb_shinfo(skb)->gso_size = hnae3_get_field(bd_base_info,
- HNS3_RXD_GRO_SIZE_M,
- HNS3_RXD_GRO_SIZE_S);
-
- return hns3_gro_complete(skb);
+ return hns3_gro_
[PATCH net-next 04/12] net: hns3: replace numa_node_id with numa_mem_id for buffer reusing
From: Yunsheng Lin This patch replaces numa_node_id with numa_mem_id when doing buffer reusing checking, because the buffer still can be reused when the buffer is from the nearest node and the local node has no memory attached. Signed-off-by: Yunsheng Lin Signed-off-by: Peng Li Signed-off-by: Huazhong Tan --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c index c37509e..969d4c1 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -2367,7 +2367,7 @@ static void hns3_nic_reuse_page(struct sk_buff *skb, int i, /* Avoid re-using remote pages, or the stack is still using the page * when page_offset rollback to zero, flag default unreuse */ - if (unlikely(page_to_nid(desc_cb->priv) != numa_node_id()) || + if (unlikely(page_to_nid(desc_cb->priv) != numa_mem_id()) || (!desc_cb->page_offset && page_count(desc_cb->priv) > 1)) return; @@ -2583,7 +2583,7 @@ static int hns3_alloc_skb(struct hns3_enet_ring *ring, int length, memcpy(__skb_put(skb, length), va, ALIGN(length, sizeof(long))); /* We can reuse buffer as-is, just make sure it is local */ - if (likely(page_to_nid(desc_cb->priv) == numa_node_id())) + if (likely(page_to_nid(desc_cb->priv) == numa_mem_id())) desc_cb->reuse_flag = 1; else /* This page cannot be reused so discard it */ put_page(desc_cb->priv); -- 2.7.4
[PATCH net-next 05/12] net: hns3: refactor hns3_get_new_int_gl function
From: Yunsheng Lin
This patch adds a new hns3_get_new_flow_lvl function to calculate
the packet flow level, which is used to decide the interrupt
coalescence parameter, in order to make the flow level calculation
code more readable and make the future calculation ajdustment easier.
Signed-off-by: Yunsheng Lin
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 77 +++--
1 file changed, 45 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 969d4c1..0ef4470 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2938,36 +2938,20 @@ int hns3_clean_rx_ring(
return recv_pkts;
}
-static bool hns3_get_new_int_gl(struct hns3_enet_ring_group *ring_group)
+static bool hns3_get_new_flow_lvl(struct hns3_enet_ring_group *ring_group)
{
- struct hns3_enet_tqp_vector *tqp_vector =
- ring_group->ring->tqp_vector;
+#define HNS3_RX_LOW_BYTE_RATE 1
+#define HNS3_RX_MID_BYTE_RATE 2
+#define HNS3_RX_ULTRA_PACKET_RATE 40
+
enum hns3_flow_level_range new_flow_level;
- int packets_per_msecs;
- int bytes_per_msecs;
+ struct hns3_enet_tqp_vector *tqp_vector;
+ int packets_per_msecs, bytes_per_msecs;
u32 time_passed_ms;
- u16 new_int_gl;
-
- if (!tqp_vector->last_jiffies)
- return false;
-
- if (ring_group->total_packets == 0) {
- ring_group->coal.int_gl = HNS3_INT_GL_50K;
- ring_group->coal.flow_level = HNS3_FLOW_LOW;
- return true;
- }
- /* Simple throttlerate management
-* 0-10MB/s lower (5 ints/s)
-* 10-20MB/s middle(2 ints/s)
-* 20-1249MB/s high (18000 ints/s)
-* > 4pps ultra (8000 ints/s)
-*/
- new_flow_level = ring_group->coal.flow_level;
- new_int_gl = ring_group->coal.int_gl;
+ tqp_vector = ring_group->ring->tqp_vector;
time_passed_ms =
jiffies_to_msecs(jiffies - tqp_vector->last_jiffies);
-
if (!time_passed_ms)
return false;
@@ -2977,9 +2961,14 @@ static bool hns3_get_new_int_gl(struct
hns3_enet_ring_group *ring_group)
do_div(ring_group->total_bytes, time_passed_ms);
bytes_per_msecs = ring_group->total_bytes;
-#define HNS3_RX_LOW_BYTE_RATE 1
-#define HNS3_RX_MID_BYTE_RATE 2
+ new_flow_level = ring_group->coal.flow_level;
+ /* Simple throttlerate management
+* 0-10MB/s lower (5 ints/s)
+* 10-20MB/s middle(2 ints/s)
+* 20-1249MB/s high (18000 ints/s)
+* > 4pps ultra (8000 ints/s)
+*/
switch (new_flow_level) {
case HNS3_FLOW_LOW:
if (bytes_per_msecs > HNS3_RX_LOW_BYTE_RATE)
@@ -2999,13 +2988,40 @@ static bool hns3_get_new_int_gl(struct
hns3_enet_ring_group *ring_group)
break;
}
-#define HNS3_RX_ULTRA_PACKET_RATE 40
-
if (packets_per_msecs > HNS3_RX_ULTRA_PACKET_RATE &&
&tqp_vector->rx_group == ring_group)
new_flow_level = HNS3_FLOW_ULTRA;
- switch (new_flow_level) {
+ ring_group->total_bytes = 0;
+ ring_group->total_packets = 0;
+ ring_group->coal.flow_level = new_flow_level;
+
+ return true;
+}
+
+static bool hns3_get_new_int_gl(struct hns3_enet_ring_group *ring_group)
+{
+ struct hns3_enet_tqp_vector *tqp_vector;
+ u16 new_int_gl;
+
+ if (!ring_group->ring)
+ return false;
+
+ tqp_vector = ring_group->ring->tqp_vector;
+ if (!tqp_vector->last_jiffies)
+ return false;
+
+ if (ring_group->total_packets == 0) {
+ ring_group->coal.int_gl = HNS3_INT_GL_50K;
+ ring_group->coal.flow_level = HNS3_FLOW_LOW;
+ return true;
+ }
+
+ if (!hns3_get_new_flow_lvl(ring_group))
+ return false;
+
+ new_int_gl = ring_group->coal.int_gl;
+ switch (ring_group->coal.flow_level) {
case HNS3_FLOW_LOW:
new_int_gl = HNS3_INT_GL_50K;
break;
@@ -3022,9 +3038,6 @@ static bool hns3_get_new_int_gl(struct
hns3_enet_ring_group *ring_group)
break;
}
- ring_group->total_bytes = 0;
- ring_group->total_packets = 0;
- ring_group->coal.flow_level = new_flow_level;
if (new_int_gl != ring_group->coal.int_gl) {
ring_group->coal.int_gl = new_int_gl;
return true;
--
2.7.4
[PATCH net-next 00/12] net: hns3: some code optimizations & cleanups & bugfixes
This patch-set includes code optimizations, cleanups and bugfixes for the HNS3 ethernet controller driver. [patch 1/12] logs more detail error info for ROCE RAS errors. [patch 2/12] fixes a wrong size issue for mailbox responding. [patch 3/12] makes HW GRO handing compliant with SW one. [patch 4/12] refactors hns3_get_new_int_gl. [patch 5/12] adds handling for VF's over_8bd_nfe_err. [patch 6/12 - 12/12] adds some code optimizations and cleanups, to make the code more readable and compliant with some static code analysis tools, these modifications do not change the logic of the code. Jian Shen (1): net: hns3: small changes for magic numbers Weihang Li (2): net: hns3: trigger VF reset if a VF has an over_8bd_nfe_err net: hns3: fix some coding style issues Xiaofei Tan (1): net: hns3: log detail error info of ROCEE ECC and AXI errors Yonglong Liu (1): net: hns3: Delete the redundant user nic codes Yufeng Mo (3): net: hns3: use macros instead of magic numbers net: hns3: refactor PF/VF RSS hash key configuration net: hns3: some modifications to simplify and optimize code Yunsheng Lin (3): net: hns3: make HW GRO handling compliant with SW GRO net: hns3: replace numa_node_id with numa_mem_id for buffer reusing net: hns3: refactor hns3_get_new_int_gl function Zhongzhu Liu (1): net: hns3: fix wrong size of mailbox responding data drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h| 2 +- drivers/net/ethernet/hisilicon/hns3/hnae3.c| 21 +- drivers/net/ethernet/hisilicon/hns3/hnae3.h| 7 - drivers/net/ethernet/hisilicon/hns3/hns3_dcbnl.c | 12 +- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 199 ++- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 43 +-- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 24 ++ .../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 19 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 181 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h | 4 +- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 391 +++-- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 26 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 4 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 140 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 85 ++--- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 3 + 16 files changed, 682 insertions(+), 479 deletions(-) -- 2.7.4
Re: [PATCHv4 2/2] mtd: spi-nor: cadence-quadspi: add reset control
On 05/08/2019 04:43 PM, Dinh Nguyen wrote:
> Get the reset control properties for the QSPI controller and bring them
> out of reset. Most will have just one reset bit, but there is an additional
> OCP reset bit that is used ECC. The OCP reset bit will also need to get
> de-asserted as well. [1]
>
It's always good to say why the change is needed, e.g. reset the controller at
init to have it in a clean state in case the bootloader messed with it.
> [1]
> https://www.intel.com/content/www/us/en/programmable/hps/arria-10/hps.html#reg_soc_top/sfo1429890575955.html
>
> Suggested-by: Tien-Fong Chee
> Signed-off-by: Dinh Nguyen
> ---
> v4: fix compile error
> v3: return full error by using PTR_ERR(rtsc)
> move reset control calls until after the clock enables
> use udelay(2) to be safe
> Add optional OCP(Open Core Protocol) reset signal
> v2: use devm_reset_control_get_optional_exclusive
> print an error message
> return -EPROBE_DEFER
> ---
> drivers/mtd/spi-nor/cadence-quadspi.c | 30 +++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
> b/drivers/mtd/spi-nor/cadence-quadspi.c
> index 792628750eec..d3906e5a1d44 100644
> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1336,6 +1337,8 @@ static int cqspi_probe(struct platform_device *pdev)
> struct cqspi_st *cqspi;
> struct resource *res;
> struct resource *res_ahb;
> + struct reset_control *rstc;
> + struct reset_control *rstc_ocp;
> const struct cqspi_driver_platdata *ddata;
> int ret;
> int irq;
> @@ -1402,6 +1405,33 @@ static int cqspi_probe(struct platform_device *pdev)
> goto probe_clk_failed;
> }
>
> + /* Obtain QSPI reset control */
> + rstc = devm_reset_control_get_optional_exclusive(dev, "qspi");
> + if (IS_ERR(rstc)) {
> + dev_err(dev, "Cannot get QSPI reset.\n");
> + if (PTR_ERR(rstc) == -EPROBE_DEFER)
what I meant was to get rid of this if and return PTR_ERR(rstc) directly.
> + return PTR_ERR(rstc);
> + }
> +
> + rstc_ocp = devm_reset_control_get_optional_exclusive(dev, "qspi-ocp");
> + if (IS_ERR(rstc_ocp)) {
> + dev_err(dev, "Cannot get QSPI OCP reset.\n");
> + if (PTR_ERR(rstc_ocp) == -EPROBE_DEFER)
> + return PTR_ERR(rstc_ocp);
> + }
> +
> + if (rstc) {> + reset_control_assert(rstc);
> + udelay(2);
why 2us? what's the appropriate length of time that we should wait between
assert and deassert?
> + reset_control_deassert(rstc);
> + }
> +
> + if (rstc_ocp) {
> + reset_control_assert(rstc_ocp);
Does it mater the order in which you assert these signals? can we group these
module resets asserts, i.e. first do the assert for both rstc and rstcp and then
the deassert?
> + udelay(2);
> + reset_control_deassert(rstc_ocp);
Is software deassert needed? I'm looking at [2], Table 46. PER1 Group, Generated
Module Resets, and it seems that software deassert is not an option for
qspi_flash_ecc_rst_n
[2]https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/arria-10/a10_5v4.pdf
> + }
> +
> cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
> ddata = of_device_get_match_data(dev);
> if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
>
Re: [PATCH v8 03/13] clk: samsung: add BPLL rate table for Exynos 5422 SoC
On Wed, 5 Jun 2019 at 18:54, Lukasz Luba wrote: > > Add new table rate for BPLL for Exynos5422 SoC supporting Dynamic Memory > Controller frequencies for driver's DRAM timings. > > Acked-by: Chanwoo Choi > Signed-off-by: Lukasz Luba > --- > drivers/clk/samsung/clk-exynos5420.c | 17 - > 1 file changed, 16 insertions(+), 1 deletion(-) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v8 06/13] drivers: memory: extend of_memory by LPDDR3 support
On Wed, 5 Jun 2019 at 18:54, Lukasz Luba wrote: > > The patch adds AC timings information needed to support LPDDR3 and memory > controllers. The structure is used in of_memory and currently in Exynos > 5422 DMC. Add parsing data needed for LPDDR3 support. > It is currently used in Exynos5422 Dynamic Memory Controller. > > Signed-off-by: Lukasz Luba > --- > drivers/memory/of_memory.c | 154 + > drivers/memory/of_memory.h | 18 + > include/memory/jedec_ddr.h | 62 +++ > 3 files changed, 234 insertions(+) Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
RE: [PATCH V4 1/4] dt-bindings: imx: Add clock binding doc for i.MX8MN
Hi, Maxime
> -Original Message-
> From: Maxime Ripard
> Sent: Thursday, June 6, 2019 3:41 PM
> To: Anson Huang
> Cc: mturque...@baylibre.com; sb...@kernel.org; robh...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de;
> ker...@pengutronix.de; feste...@gmail.com; catalin.mari...@arm.com;
> will.dea...@arm.com; o...@lixom.net; ja...@amarulasolutions.com;
> horms+rene...@verge.net.au; bjorn.anders...@linaro.org; Leonard Crestez
> ; dingu...@kernel.org;
> enric.balle...@collabora.com; Aisheng Dong ;
> Abel Vesa ; Jacky Bai ;
> l.st...@pengutronix.de; Peng Fan ; linux-
> c...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; dl-linux-imx
>
> Subject: Re: [PATCH V4 1/4] dt-bindings: imx: Add clock binding doc for
> i.MX8MN
>
> Hi,
>
> On Thu, Jun 06, 2019 at 09:33:20AM +0800, anson.hu...@nxp.com wrote:
> > From: Anson Huang
> >
> > Add the clock binding doc for i.MX8MN.
> >
> > Signed-off-by: Anson Huang
> > ---
> > Changes since V3:
> > - switch binding doc from .txt to .yaml.
> > ---
> > .../devicetree/bindings/clock/imx8mn-clock.yaml| 115 +++
> > include/dt-bindings/clock/imx8mn-clock.h | 215
> +
> > 2 files changed, 330 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/imx8mn-clock.yaml
> > create mode 100644 include/dt-bindings/clock/imx8mn-clock.h
> >
> > diff --git a/Documentation/devicetree/bindings/clock/imx8mn-clock.yaml
> > b/Documentation/devicetree/bindings/clock/imx8mn-clock.yaml
> > new file mode 100644
> > index 000..8cb8fcf
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/imx8mn-clock.yaml
> > @@ -0,0 +1,115 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/bindings/clock/imx8mn-clock.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NXP i.MX8M Nano Clock Control Module Binding
> > +
> > +maintainers:
> > + - Anson Huang
> > +
> > +description: |
> > + NXP i.MX8M Nano clock control module is an integrated clock
> > +controller, which
> > + generates and supplies to all modules.
> > +
> > + This binding uses common clock bindings [1]
> > + Documentation/devicetree/bindings/clock/clock-bindings.txt
>
> Which part exactly are you using?
>
> I'm not sure it's worth referring to. Any provider property should be listed
> here, and the consumer properties are already checked.
Agreed, I will remove this reference statement in next version.
>
> > +properties:
> > + compatible:
> > +const: fsl,imx8mn-ccm
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + clocks:
> > +items:
> > + - description: 32k osc
> > + - description: 24m osc
> > + - description: ext1 clock input
> > + - description: ext2 clock input
> > + - description: ext3 clock input
> > + - description: ext4 clock input
> > +
> > + clock-names:
> > +items:
> > + - const: osc_32k
> > + - const: osc_24m
> > + - const: clk_ext1
> > + - const: clk_ext2
> > + - const: clk_ext3
> > + - const: clk_ext4
> > +
> > + '#clock-cells':
> > +const: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - '#clock-cells'
> > +
> > +examples:
> > + # Clock Control Module node:
> > + - |
> > +clk: clock-controller@3038 {
> > +compatible = "fsl,imx8mn-ccm";
> > +reg = <0x0 0x3038 0x0 0x1>;
> > +#clock-cells = <1>;
> > +clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>,
> > + <&clk_ext2>, <&clk_ext3>, <&clk_ext4>;
> > +clock-names = "osc_32k", "osc_24m", "clk_ext1",
> > + "clk_ext2", "clk_ext3", "clk_ext4";
> > +};
> > +
> > + # Required external clocks for Clock Control Module node:
> > + - |
> > +osc_32k: clock-osc-32k {
> > +compatible = "fixed-clock";
> > +#clock-cells = <0>;
> > +clock-frequency = <32768>;
> > + clock-output-names = "osc_32k";
> > +};
> > +
> > +osc_24m: clock-osc-24m {
> > +compatible = "fixed-clock";
> > +#clock-cells = <0>;
> > +clock-frequency = <2400>;
> > +clock-output-names = "osc_24m";
> > +};
> > +
> > +clk_ext1: clock-ext1 {
> > +compatible = "fixed-clock";
> > +#clock-cells = <0>;
> > +clock-frequency = <13300>;
> > +clock-output-names = "clk_ext1";
> > +};
> > +
> > +clk_ext2: clock-ext2 {
> > +compatible = "fixed-clock";
> > +#clock-cells = <0>;
> > +clock-frequency = <13300>;
> > +clock-output-names = "clk_ext2";
> > +};
> > +
> > +clk_ext3: clock-ext3 {
> > +compatible = "fixed-clock";
> > +#clock-cells = <0>;
> > +clock-frequency = <13300>;
> > +clock-output-names = "clk_ext3";
> > +};
> > +
Re: [PATCH] arm64: dts: sdm845: Add CPU topology
+CC Morten who had an interest in this
On Thursday 06 Jun 2019 at 10:20:12 (+0200), Vincent Guittot wrote:
> On Thu, 6 Jun 2019 at 09:49, Quentin Perret wrote:
> >
> > Hi Vincent,
> >
> > On Thursday 06 Jun 2019 at 09:05:16 (+0200), Vincent Guittot wrote:
> > > Hi Quentin,
> > >
> > > On Wed, 5 Jun 2019 at 19:21, Quentin Perret
> > > wrote:
> > > >
> > > > On Friday 17 May 2019 at 14:55:19 (-0700), Stephen Boyd wrote:
> > > > > Quoting Amit Kucheria (2019-05-16 04:54:45)
> > > > > > (cc'ing Andy's correct email address)
> > > > > >
> > > > > > On Wed, May 15, 2019 at 2:46 AM Stephen Boyd
> > > > > > wrote:
> > > > > > >
> > > > > > > Quoting Amit Kucheria (2019-05-13 04:54:12)
> > > > > > > > On Mon, May 13, 2019 at 4:31 PM Amit Kucheria
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Jan 15, 2019 at 12:13 AM Matthias Kaehlcke
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > The 8 CPU cores of the SDM845 are organized in two clusters
> > > > > > > > > > of 4 big
> > > > > > > > > > ("gold") and 4 little ("silver") cores. Add a cpu-map node
> > > > > > > > > > to the DT
> > > > > > > > > > that describes this topology.
> > > > > > > > >
> > > > > > > > > This is partly true. There are two groups of gold and silver
> > > > > > > > > cores,
> > > > > > > > > but AFAICT they are in a single cluster, not two separate
> > > > > > > > > ones. SDM845
> > > > > > > > > is one of the early examples of ARM's Dynamiq architecture.
> > > > > > > > >
> > > > > > > > > > Signed-off-by: Matthias Kaehlcke
> > > > > > > > >
> > > > > > > > > I noticed that this patch sneaked through for this merge
> > > > > > > > > window but
> > > > > > > > > perhaps we can whip up a quick fix for -rc2?
> > > > > > > > >
> > > > > > > >
> > > > > > > > And please find attached a patch to fix this up. Andy, since
> > > > > > > > this
> > > > > > > > hasn't landed yet (can we still squash this into the original
> > > > > > > > patch?),
> > > > > > > > I couldn't add a Fixes tag.
> > > > > > > >
> > > > > > >
> > > > > > > I had the same concern. Thanks for catching this. I suspect this
> > > > > > > must
> > > > > > > cause some problem for IPA given that it can't discern between
> > > > > > > the big
> > > > > > > and little "power clusters"?
> > > > > >
> > > > > > Both EAS and IPA, I believe. It influences the scheduler's view of
> > > > > > the
> > > > > > the topology.
> > > > >
> > > > > And EAS and IPA are OK with the real topology? I'm just curious if
> > > > > changing the topology to reflect reality will be a problem for those
> > > > > two.
> > > >
> > > > FWIW, neither EAS nor IPA depends on this. Not the upstream version of
> > > > EAS at least (which is used in recent Android kernels -- 4.19+).
> > > >
> > > > But doing this is still required for other things in the scheduler (the
> > > > so-called 'capacity-awareness' code). So until we have a better
> > > > solution, this patch is doing the right thing.
> > >
> > > I'm not sure to catch what you mean ?
> > > Which so-called 'capacity-awareness' code are you speaking about ? and
> > > what is the problem ?
> >
> > I'm talking about the wake-up path. ATM select_idle_sibling() is totally
> > unaware of capacity differences. In its current form, this function
> > basically assumes that all CPUs in a given sd_llc have the same
> > capacity, which would be wrong if we had a single MC level for SDM845.
> > So, until select_idle_sibling() is 'fixed' to be capacity-aware, we need
> > two levels of sd for asymetric systems (including DynamIQ) so the
> > wake_cap() story actually works.
> >
> > I hope that clarifies it :)
>
> hmm... does this justifies this wrong topology ?
> select_idle_sibling() is called only when system is overloaded and
> scheduler disables the EAS path
> In this case, the scheduler looks either for an idle cpu or for evenly
> spreading the loads
Yeah but a big task can end up being placed on a little CPU even if a
big CPU is idle. So, it's definitely sub-optimal.
> This is maybe not always optimal and should probably be fixed but
> doesn't justifies a wrong topology description IMHO
I totally agree, the proper fix is to get select_idle_sibling() capacity
aware. And actually, it is true the DT should represent the HW, so
perhaps Amit's fix is the right thing to do so we don't let those hacky
topologies creep into mainline ... I just want to make sure we are fully
aware and OK with the fact that the performance on this platform might
be a little inconsistent until select_idle_sibling() is fixed.
Thanks,
Quentin
Re: [PATCH v8 07/13] dt-bindings: memory-controllers: add Exynos5422 DMC device description
On Wed, 5 Jun 2019 at 18:54, Lukasz Luba wrote:
>
> The patch adds description for DT binding for a new Exynos5422 Dynamic
> Memory Controller device.
>
> Signed-off-by: Lukasz Luba
> ---
> .../memory-controllers/exynos5422-dmc.txt | 84 +++
> 1 file changed, 84 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
>
> diff --git
> a/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
> b/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
> new file mode 100644
> index ..989ee0839fdf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt
> @@ -0,0 +1,84 @@
> +* Exynos5422 frequency and voltage scaling for Dynamic Memory Controller
> device
> +
> +The Samsung Exynos5422 SoC has DMC (Dynamic Memory Controller) to which the
> DRAM
> +memory chips are connected. The driver is to monitor the controller in
> runtime
> +and switch frequency and voltage. To monitor the usage of the controller in
> +runtime, the driver uses the PPMU (Platform Performance Monitoring Unit),
> which
> +is able to measure the current load of the memory.
> +When 'userspace' governor is used for the driver, an application is able to
> +switch the DMC and memory frequency.
> +
> +Required properties for DMC device for Exynos5422:
> +- compatible: Should be "samsung,exynos5422-dmc".
> +- clocks : list of clock specifiers, must contain an entry for each
> + required entry in clock-names for CLK_FOUT_SPLL, CLK_MOUT_SCLK_SPLL,
> + CLK_FF_DOUT_SPLL2, CLK_FOUT_BPLL, CLK_MOUT_BPLL, CLK_SCLK_BPLL,
> + CLK_MOUT_MX_MSPLL_CCORE, CLK_MOUT_MX_MSPLL_CCORE_PHY, CLK_MOUT_MCLK_CDREX,
> + CLK_DOUT_CLK2X_PHY0, CLK_CLKM_PHY0, CLK_CLKM_PHY1
> +- clock-names : should include "fout_spll", "mout_sclk_spll",
> "ff_dout_spll2",
> + "fout_bpll", "mout_bpll", "sclk_bpll", "mout_mx_mspll_ccore",
> + "mout_mx_mspll_ccore_phy", "mout_mclk_cdrex", "dout_clk2x_phy0",
> "clkm_phy0",
> + "clkm_phy1" entries
> +- devfreq-events : phandles for PPMU devices connected to this DMC.
> +- vdd-supply : phandle for voltage regulator which is connected.
> +- reg : registers of two CDREX controllers.
> +- operating-points-v2 : phandle for OPPs described in v2 definition.
> +- device-handle : phandle of the connected DRAM memory device. For more
> + information please refer to documentation file:
> + Documentation/devicetree/bindings/ddr/lpddr3.txt
> +- devfreq-events : phandles of the PPMU events used by the controller.
> +- samsung,syscon-clk : phandle of the clock register set used by the
> controller,
> + these registers are used for enabling a 'pause' feature and are not
> + exposed by clock framework but they must be used in a safe way.
> + The register offsets are in the driver code and specyfic for this SoC
> + type.
> +
> +Example:
> +
> + ppmu_dmc0_0: ppmu@10d0 {
> + compatible = "samsung,exynos-ppmu";
> + reg = <0x10d0 0x2000>;
> + clocks = <&clock CLK_PCLK_PPMU_DREX0_0>;
> + clock-names = "ppmu";
> + events {
> + ppmu_event_dmc0_0: ppmu-event3-dmc0_0 {
> + event-name = "ppmu-event3-dmc0_0";
> + };
> + };
> + };
> +
> + dmc: memory-controller@10c2 {
> + compatible = "samsung,exynos5422-dmc";
> + reg = <0x10c2 0x100>, <0x10c3 0x100>,
> + clocks =<&clock CLK_FOUT_SPLL>,
I think you should not have tab after '='. Instead align consecutive
lines with the first one.
> + <&clock CLK_MOUT_SCLK_SPLL>,
> + <&clock CLK_FF_DOUT_SPLL2>,
> + <&clock CLK_FOUT_BPLL>,
> + <&clock CLK_MOUT_BPLL>,
> + <&clock CLK_SCLK_BPLL>,
> + <&clock CLK_MOUT_MX_MSPLL_CCORE>,
> + <&clock CLK_MOUT_MX_MSPLL_CCORE_PHY>,
> + <&clock CLK_MOUT_MCLK_CDREX>,
> + <&clock CLK_DOUT_CLK2X_PHY0>,
> + <&clock CLK_CLKM_PHY0>,
> + <&clock CLK_CLKM_PHY1>;
> + clock-names = "fout_spll",
> + "mout_sclk_spll",
> + "ff_dout_spll2",
> + "fout_bpll",
> + "mout_bpll",
> + "sclk_bpll",
> + "mout_mx_mspll_ccore",
> + "mout_mx_mspll_ccore_phy",
> + "mout_mclk_cdrex",
> + "dout_clk2x_phy0",
> + "clkm_phy0",
> +
Re: [PATCH 2/2] arm64: defconfig: add Panfrost driver
On 04/06/2019 13:20, Tomeu Vizoso wrote: > With the goal of making it easier for CI services such as KernelCI to > run tests for it. > > Signed-off-by: Tomeu Vizoso > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 4d583514258c..d588ceb9aa3c 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -505,6 +505,7 @@ CONFIG_DRM_HISI_HIBMC=m > CONFIG_DRM_HISI_KIRIN=m > CONFIG_DRM_MESON=m > CONFIG_DRM_PL111=m > +CONFIG_DRM_PANFROST=m > CONFIG_FB=y > CONFIG_FB_MODE_HELPERS=y > CONFIG_BACKLIGHT_GENERIC=m > Acked-by: Neil Armstrong
Re: [PATCH 1/2] ARM: multi_v7_defconfig: add Panfrost driver
Hi Olof, Arnd, Could you take these directly or an arm soc maintainer should take them in their trees ? Thanks, Neil On 04/06/2019 13:20, Tomeu Vizoso wrote: > With the goal of making it easier for CI services such as KernelCI to > run tests for it. > > Signed-off-by: Tomeu Vizoso > --- > arch/arm/configs/multi_v7_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index 6b748f214eae..952dff9d39f2 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -656,6 +656,7 @@ CONFIG_DRM_VC4=m > CONFIG_DRM_ETNAVIV=m > CONFIG_DRM_MXSFB=m > CONFIG_DRM_PL111=m > +CONFIG_DRM_PANFROST=m > CONFIG_FB_EFI=y > CONFIG_FB_WM8505=y > CONFIG_FB_SH_MOBILE_LCDC=y > And BTW : Acked-by: Neil Armstrong
Re: [PATCH] Powerpc/Watchpoint: Restore nvgprs while returning from exception
On 6/6/19 12:59 PM, Ravi Bangoria wrote: > Powerpc hw triggers watchpoint before executing the instruction. > To make trigger-after-execute behavior, kernel emulates the > instruction. If the instruction is 'load something into non- > volatile register', exception handler should restore emulated > register state while returning back, otherwise there will be > register state corruption. Ex, Adding a watchpoint on a list > can corrput the list: > > # cat /proc/kallsyms | grep kthread_create_list > c121c8b8 d kthread_create_list > > Add watchpoint on kthread_create_list->next: s/kthread_create_list->next/kthread_create_list->prev/
Re: [PATCH 6/7] media: cedrus: Add infra for extra buffers connected to capture buffers
On Mon, Jun 03, 2019 at 05:48:25PM +0200, Jernej Škrabec wrote:
> Dne ponedeljek, 03. junij 2019 ob 14:18:59 CEST je Maxime Ripard napisal(a):
> > > +static void cedrus_buf_cleanup(struct vb2_buffer *vb)
> > > +{
> > > + struct vb2_queue *vq = vb->vb2_queue;
> > > +
> > > + if (!V4L2_TYPE_IS_OUTPUT(vq->type)) {
> > > + struct cedrus_ctx *ctx = vb2_get_drv_priv(vq);
> > > + struct cedrus_buffer *cedrus_buf;
> > > +
> > > + cedrus_buf = vb2_to_cedrus_buffer(vq->bufs[vb->index]);
> > > +
> > > + if (cedrus_buf->extra_buf_size)
> > > + dma_free_coherent(ctx->dev->dev,
> > > + cedrus_buf-
> >extra_buf_size,
> > > + cedrus_buf-
> >extra_buf,
> > > + cedrus_buf-
> >extra_buf_dma);
> > > + }
> > > +}
> > > +
> >
> > I'm really not a fan of allocating something somewhere, and freeing it
> > somewhere else. Making sure you don't leak something is hard enough to
> > not have some non-trivial allocation scheme.
>
> Ok, what about introducing two new optional methods in engine callbacks,
> buffer_init and buffer_destroy, which would be called from cedrus_buf_init()
> and
> cedrus_buf_cleanup(), respectively. That way all (de)allocation logic stays
> within the same engine.
Yep, that would work for me.
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH v3 2/2] media: atmel: atmel-sama5d2-isc: fixed checkpatch warnings
Hi Eugen,
On Thu, Jun 06, 2019 at 07:43:47AM +, eugen.hris...@microchip.com wrote:
> From: Eugen Hristev
>
> Checkpatch complaining that locks do not have comments,
> unaligned code and macro reuse of same argument in to_isc_clk.
> Fixed them by renaming, realigning and adding struct comments
>
> Signed-off-by: Eugen Hristev
> ---
> Changes in v3:
> - new patch, addresses the checkpatch issues that Hans asked to fix
>
> drivers/media/platform/atmel/atmel-isc.h | 51
> +---
> drivers/media/platform/atmel/atmel-sama5d2-isc.c | 4 +-
> 2 files changed, 48 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.h
> b/drivers/media/platform/atmel/atmel-isc.h
> index 0bd5dff..6ff9fa8 100644
> --- a/drivers/media/platform/atmel/atmel-isc.h
> +++ b/drivers/media/platform/atmel/atmel-isc.h
> @@ -24,14 +24,14 @@ struct isc_clk {
> struct clk_hw hw;
> struct clk *clk;
> struct regmap *regmap;
> - spinlock_t lock;
> + spinlock_t lock; /* synchronize access to clock registers */
You probably want to serialise the access, not synchronise it (i.e. happen
at the same time). So, s/synchronise/serialise/ ?
Same on the isc_device fields below.
With that,
Acked-by: Sakari Ailus
> u8 id;
> u8 parent_id;
> u32 div;
> struct device *dev;
> };
>
> -#define to_isc_clk(hw) container_of(hw, struct isc_clk, hw)
> +#define to_isc_clk(v) container_of(v, struct isc_clk, hw)
>
> struct isc_buffer {
> struct vb2_v4l2_buffer vb;
> @@ -146,6 +146,47 @@ struct isc_ctrls {
>
> #define ISC_PIPE_LINE_NODE_NUM 11
>
> +/*
> + * struct isc_device - ISC device driver data/config struct
> + * @regmap: Register map
> + * @hclock: Hclock clock input (refer datasheet)
> + * @ispck: iscpck clock (refer datasheet)
> + * @isc_clks:ISC clocks
> + *
> + * @dev: Registered device driver
> + * @v4l2_dev:v4l2 registered device
> + * @video_dev: registered video device
> + *
> + * @vb2_vidq:video buffer 2 video queue
> + * @dma_queue_lock: lock to synchronize the dma buffer queue
> + * @dma_queue: the queue for dma buffers
> + * @cur_frm: current isc frame/buffer
> + * @sequence:current frame number
> + * @stop:true if isc is not streaming, false if streaming
> + * @comp:completion reference that signals frame completion
> + *
> + * @fmt: current v42l format
> + * @user_formats:list of formats that are supported and agreed with sd
> + * @num_user_formats:how many formats are in user_formats
> + *
> + * @config: current ISC format configuration
> + * @try_config: the current ISC try format , not yet activated
> + *
> + * @ctrls: holds information about ISC controls
> + * @do_wb_ctrl: control regarding the DO_WHITE_BALANCE button
> + * @awb_work:workqueue reference for autowhitebalance
> histogram
> + * analysis
> + *
> + * @lock:lock for synchronizing userspace file operations
> + * with ISC operations
> + * @awb_lock:lock for synchronizing awb work queue operations
> + * with DMA/buffer operations
> + *
> + * @pipeline:configuration of the ISC pipeline
> + *
> + * @current_subdev: current subdevice: the sensor
> + * @subdev_entities: list of subdevice entitites
> + */
> struct isc_device {
> struct regmap *regmap;
> struct clk *hclock;
> @@ -157,7 +198,7 @@ struct isc_device {
> struct video_device video_dev;
>
> struct vb2_queuevb2_vidq;
> - spinlock_t dma_queue_lock;
> + spinlock_t dma_queue_lock; /* sync access to dma queue */
> struct list_headdma_queue;
> struct isc_buffer *cur_frm;
> unsigned intsequence;
> @@ -175,8 +216,8 @@ struct isc_device {
> struct v4l2_ctrl*do_wb_ctrl;
> struct work_struct awb_work;
>
> - struct mutexlock;
> - spinlock_t awb_lock;
> + struct mutexlock; /* sync access to file operations */
> + spinlock_t awb_lock; /* sync access to DMA buffers from
> awb work queue */
>
> struct regmap_field *pipeline[ISC_PIPE_LINE_NODE_NUM];
>
> diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> index 69faaaf..299243f 100644
> --- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> +++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> @@ -87,8 +87,8 @@ static int isc_parse_dt(struct device *dev, struct
> isc_device *isc)
> break;
> }
>
> -
Re: [PATCH v8 02/13] clk: samsung: add new clocks for DMC for Exynos5422 SoC
On Wed, 5 Jun 2019 at 18:54, Lukasz Luba wrote:
>
> This patch provides support for clocks needed for Dynamic Memory Controller
> in Exynos5422 SoC. It adds CDREX base register addresses, new DIV, MUX and
> GATE entries.
>
> Acked-by: Chanwoo Choi
> Signed-off-by: Lukasz Luba
> ---
> drivers/clk/samsung/clk-exynos5420.c | 57 ++--
> 1 file changed, 53 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 34cce3c5898f..eecbfcc6b3cf 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -134,6 +134,8 @@
> #define SRC_CDREX 0x20200
> #define DIV_CDREX0 0x20500
> #define DIV_CDREX1 0x20504
> +#define GATE_BUS_CDREX00x20700
> +#define GATE_BUS_CDREX10x20704
> #define KPLL_LOCK 0x28000
> #define KPLL_CON0 0x28100
> #define SRC_KFC0x28200
> @@ -248,6 +250,8 @@ static const unsigned long exynos5x_clk_regs[]
> __initconst = {
> DIV_CDREX1,
> SRC_KFC,
> DIV_KFC0,
> + GATE_BUS_CDREX0,
> + GATE_BUS_CDREX1,
> };
>
> static const unsigned long exynos5800_clk_regs[] __initconst = {
> @@ -425,6 +429,9 @@ PNAME(mout_group13_5800_p) = { "dout_osc_div",
> "mout_sw_aclkfl1_550_cam" };
> PNAME(mout_group14_5800_p) = { "dout_aclk550_cam", "dout_sclk_sw" };
> PNAME(mout_group15_5800_p) = { "dout_osc_div", "mout_sw_aclk550_cam" };
> PNAME(mout_group16_5800_p) = { "dout_osc_div", "mout_mau_epll_clk" };
> +PNAME(mout_mx_mspll_ccore_phy_p) = { "sclk_bpll", "mout_sclk_dpll",
> + "mout_sclk_mpll", "ff_dout_spll2",
> + "mout_sclk_spll", "mout_sclk_epll"};
>
> /* fixed rate clocks generated outside the soc */
> static struct samsung_fixed_rate_clock
> @@ -450,7 +457,7 @@ static const struct samsung_fixed_factor_clock
> static const struct samsung_fixed_factor_clock
> exynos5800_fixed_factor_clks[] __initconst = {
> FFACTOR(0, "ff_dout_epll2", "mout_sclk_epll", 1, 2, 0),
> - FFACTOR(0, "ff_dout_spll2", "mout_sclk_spll", 1, 2, 0),
> + FFACTOR(CLK_FF_DOUT_SPLL2, "ff_dout_spll2", "mout_sclk_spll", 1, 2,
> 0),
> };
>
> static const struct samsung_mux_clock exynos5800_mux_clks[] __initconst = {
> @@ -472,11 +479,14 @@ static const struct samsung_mux_clock
> exynos5800_mux_clks[] __initconst = {
> MUX(0, "mout_aclk300_disp1", mout_group5_5800_p, SRC_TOP2, 24, 2),
> MUX(0, "mout_aclk300_gscl", mout_group5_5800_p, SRC_TOP2, 28, 2),
>
> + MUX(CLK_MOUT_MX_MSPLL_CCORE_PHY, "mout_mx_mspll_ccore_phy",
> + mout_mx_mspll_ccore_phy_p, SRC_TOP7, 0, 3),
> +
> MUX(CLK_MOUT_MX_MSPLL_CCORE, "mout_mx_mspll_ccore",
> - mout_mx_mspll_ccore_p, SRC_TOP7, 16, 2),
> + mout_mx_mspll_ccore_p, SRC_TOP7, 16, 3),
> MUX_F(CLK_MOUT_MAU_EPLL, "mout_mau_epll_clk",
> mout_mau_epll_clk_5800_p,
> SRC_TOP7, 20, 2, CLK_SET_RATE_PARENT, 0),
> - MUX(0, "sclk_bpll", mout_bpll_p, SRC_TOP7, 24, 1),
> + MUX(CLK_SCLK_BPLL, "sclk_bpll", mout_bpll_p, SRC_TOP7, 24, 1),
> MUX(0, "mout_epll2", mout_epll2_5800_p, SRC_TOP7, 28, 1),
>
> MUX(0, "mout_aclk550_cam", mout_group3_5800_p, SRC_TOP8, 16, 3),
> @@ -648,7 +658,7 @@ static const struct samsung_mux_clock exynos5x_mux_clks[]
> __initconst = {
>
> MUX(0, "mout_sclk_mpll", mout_mpll_p, SRC_TOP6, 0, 1),
> MUX(CLK_MOUT_VPLL, "mout_sclk_vpll", mout_vpll_p, SRC_TOP6, 4, 1),
> - MUX(0, "mout_sclk_spll", mout_spll_p, SRC_TOP6, 8, 1),
> + MUX(CLK_MOUT_SCLK_SPLL, "mout_sclk_spll", mout_spll_p, SRC_TOP6, 8,
> 1),
> MUX(0, "mout_sclk_ipll", mout_ipll_p, SRC_TOP6, 12, 1),
> MUX(0, "mout_sclk_rpll", mout_rpll_p, SRC_TOP6, 16, 1),
> MUX_F(CLK_MOUT_EPLL, "mout_sclk_epll", mout_epll_p, SRC_TOP6, 20, 1,
> @@ -806,8 +816,21 @@ static const struct samsung_div_clock
> exynos5x_div_clks[] __initconst = {
> "mout_aclk400_disp1", DIV_TOP2, 4, 3),
>
> /* CDREX Block */
> + /*
> +* The three clocks below are controlled using the same register and
> +* bits. They are put into one because there is a need of
> +* synchronization between the BUS and DREXs (two external memory
> +* interfaces).
> +* They are put here to show this HW assumption and for clock
> +* information summary completeness.
> +*/
> DIV(CLK_DOUT_PCLK_CDREX, "dout_pclk_cdrex", "dout_aclk_cdrex1",
> DIV_CDREX0, 28, 3),
> + DIV(CLK_DOUT_PCLK_DREX0, "dout_pclk_drex0", "dout_cclk_drex0",
> + DIV_CDREX0, 28, 3),
> + DIV(CLK_DOUT_PCLK_DREX1, "dout_pclk_drex1", "dout_cclk_drex0",
> +
Re: [BPF v1] tools: bpftool: Fix JSON output when lookup fails
2019-06-05 21:17 UTC+0200 ~ Krzesimir Nowak
> In commit 9a5ab8bf1d6d ("tools: bpftool: turn err() and info() macros
> into functions") one case of error reporting was special cased, so it
> could report a lookup error for a specific key when dumping the map
> element. What the code forgot to do is to wrap the key and value keys
> into a JSON object, so an example output of pretty JSON dump of a
> sockhash map (which does not support looking up its values) is:
>
> [
> "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x00"
> ],
> "value": {
> "error": "Operation not supported"
> },
> "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x01"
> ],
> "value": {
> "error": "Operation not supported"
> }
> ]
>
> Note the key-value pairs inside the toplevel array. They should be
> wrapped inside a JSON object, otherwise it is an invalid JSON. This
> commit fixes this, so the output now is:
>
> [{
> "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x00"
> ],
> "value": {
> "error": "Operation not supported"
> }
> },{
> "key": ["0x0a","0x41","0x00","0x02","0x1f","0x78","0x00","0x01"
> ],
> "value": {
> "error": "Operation not supported"
> }
> }
> ]
>
> Fixes: 9a5ab8bf1d6d ("tools: bpftool: turn err() and info() macros into
> functions")
> Cc: Quentin Monnet
> Signed-off-by: Krzesimir Nowak
Thanks for the fix!
Quentin
Re: [PATCH] arm64: dts: sdm845: Add CPU topology
On 6/6/19 10:20 AM, Vincent Guittot wrote:
On Thu, 6 Jun 2019 at 09:49, Quentin Perret wrote:
Hi Vincent,
On Thursday 06 Jun 2019 at 09:05:16 (+0200), Vincent Guittot wrote:
Hi Quentin,
On Wed, 5 Jun 2019 at 19:21, Quentin Perret wrote:
On Friday 17 May 2019 at 14:55:19 (-0700), Stephen Boyd wrote:
Quoting Amit Kucheria (2019-05-16 04:54:45)
(cc'ing Andy's correct email address)
On Wed, May 15, 2019 at 2:46 AM Stephen Boyd wrote:
Quoting Amit Kucheria (2019-05-13 04:54:12)
On Mon, May 13, 2019 at 4:31 PM Amit Kucheria wrote:
On Tue, Jan 15, 2019 at 12:13 AM Matthias Kaehlcke wrote:
The 8 CPU cores of the SDM845 are organized in two clusters of 4 big
("gold") and 4 little ("silver") cores. Add a cpu-map node to the DT
that describes this topology.
This is partly true. There are two groups of gold and silver cores,
but AFAICT they are in a single cluster, not two separate ones. SDM845
is one of the early examples of ARM's Dynamiq architecture.
Signed-off-by: Matthias Kaehlcke
I noticed that this patch sneaked through for this merge window but
perhaps we can whip up a quick fix for -rc2?
And please find attached a patch to fix this up. Andy, since this
hasn't landed yet (can we still squash this into the original patch?),
I couldn't add a Fixes tag.
I had the same concern. Thanks for catching this. I suspect this must
cause some problem for IPA given that it can't discern between the big
and little "power clusters"?
Both EAS and IPA, I believe. It influences the scheduler's view of the
the topology.
And EAS and IPA are OK with the real topology? I'm just curious if
changing the topology to reflect reality will be a problem for those
two.
FWIW, neither EAS nor IPA depends on this. Not the upstream version of
EAS at least (which is used in recent Android kernels -- 4.19+).
But doing this is still required for other things in the scheduler (the
so-called 'capacity-awareness' code). So until we have a better
solution, this patch is doing the right thing.
I'm not sure to catch what you mean ?
Which so-called 'capacity-awareness' code are you speaking about ? and
what is the problem ?
I'm talking about the wake-up path. ATM select_idle_sibling() is totally
unaware of capacity differences. In its current form, this function
basically assumes that all CPUs in a given sd_llc have the same
capacity, which would be wrong if we had a single MC level for SDM845.
So, until select_idle_sibling() is 'fixed' to be capacity-aware, we need
two levels of sd for asymetric systems (including DynamIQ) so the
wake_cap() story actually works.
I hope that clarifies it :)
hmm... does this justifies this wrong topology ?
select_idle_sibling() is called only when system is overloaded and
scheduler disables the EAS path
In this case, the scheduler looks either for an idle cpu or for evenly
spreading the loads
This is maybe not always optimal and should probably be fixed but
doesn't justifies a wrong topology description IMHO
The big/Little cluster detection in wake_cap() doesn't work anymore with
DynamIQ w/o Phanton (DIE) domain. So the decision of going sis() or slow
path is IMHO broken.
But I support the idea of not introducing Phantom Domains in device tree
and fix wake_cap() instead.
Re: [PATCH v3 3/5] soc: renesas: Enable RZ/A1 IRQC on RZ/A1H and RZ/A2M
On Thu, May 02, 2019 at 02:32:18PM +0200, Geert Uytterhoeven wrote: > Auto-enable support for the RZ/A1 Interrupt Controller when configuring > a kernel which supports RZ/A1H or RZ/A2M SoCs. > Keep selects sorted while at it. > > This is similar to how interrupt controllers for other Renesas SoCs are > enabled. > > Signed-off-by: Geert Uytterhoeven > Reviewed-by: Simon Horman Thanks, applied for v5.3.
Re: rcu_read_lock lost its compiler barrier
On Mon, Jun 03, 2019 at 10:46:40AM +0800, Herbert Xu wrote:
> The case we were discussing is from net/ipv4/inet_fragment.c from
> the net-next tree:
BTW, thank you for keeping me and other people who intervened in that
discussion in Cc:...
Andrea
>
> void fqdir_exit(struct fqdir *fqdir)
> {
> ...
> fqdir->dead = true;
>
> /* call_rcu is supposed to provide memory barrier semantics,
>* separating the setting of fqdir->dead with the destruction
>* work. This implicit barrier is paired with inet_frag_kill().
>*/
>
> INIT_RCU_WORK(&fqdir->destroy_rwork, fqdir_rwork_fn);
> queue_rcu_work(system_wq, &fqdir->destroy_rwork);
> }
>
> and
>
> void inet_frag_kill(struct inet_frag_queue *fq)
> {
> ...
> rcu_read_lock();
> /* The RCU read lock provides a memory barrier
>* guaranteeing that if fqdir->dead is false then
>* the hash table destruction will not start until
>* after we unlock. Paired with inet_frags_exit_net().
>*/
> if (!fqdir->dead) {
> rhashtable_remove_fast(&fqdir->rhashtable, &fq->node,
> fqdir->f->rhash_params);
> ...
> }
> ...
> rcu_read_unlock();
> ...
> }
>
> I simplified this to
>
> Initial values:
>
> a = 0
> b = 0
>
> CPU1 CPU2
>
> a = 1 rcu_read_lock
> synchronize_rcu if (a == 0)
> b = 2 b = 1
> rcu_read_unlock
>
> On exit we want this to be true:
> b == 2
Re: [PATCH v4 2/2] arm64: dts: qcom: Add Lenovo Miix 630
On 06/06/2019 10:13, Lee Jones wrote: > On Thu, 06 Jun 2019, Bjorn Andersson wrote: > >> On Wed 05 Jun 22:50 PDT 2019, Lee Jones wrote: >> >>> On Tue, 23 Apr 2019, Jeffrey Hugo wrote: >>> This adds the initial DT for the Lenovo Miix 630 laptop. Supported functionality includes USB (host), microSD-card, keyboard, and trackpad. Signed-off-by: Jeffrey Hugo --- arch/arm64/boot/dts/qcom/Makefile | 1 + .../boot/dts/qcom/msm8998-clamshell.dtsi | 278 ++ .../boot/dts/qcom/msm8998-lenovo-miix-630.dts | 30 ++ >>> >>> What's happening with this patch? >>> >> >> The thermal-zones are wrong, but I'm okay with an incremental patch for >> that... > > I guess it would take you about 10 seconds to whip those out when > merging? https://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git/commit/?h=for-next&id=ad480e0149cfc10defe76e88354b977360adb7a1 AFAIU, the fixup is to just drop the thermal-zones section altogether. Regards.
[PATCH][next] ipv6: fix spelling mistake: "wtih" -> "with"
From: Colin Ian King
There is a spelling mistake in a NL_SET_ERR_MSG message. Fix it.
Signed-off-by: Colin Ian King
---
net/ipv6/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index fbaa7e9e0d9c..641a31d42ef9 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3342,7 +3342,7 @@ static struct fib6_info *ip6_route_info_create(struct
fib6_config *cfg,
goto out;
}
if (rt->fib6_src.plen) {
- NL_SET_ERR_MSG(extack, "Nexthops can not be used wtih
source routing");
+ NL_SET_ERR_MSG(extack, "Nexthops can not be used with
source routing");
goto out;
}
rt->nh = nh;
--
2.20.1
[PATCH net] net: mvpp2: Use strscpy to handle stat strings
Use a safe strscpy call to copy the ethtool stat strings into the
relevant buffers, instead of a memcpy that will be accessing
out-of-bound data.
Fixes: 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics")
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 7a67e23a2c2b..d8e5241097a9 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1304,8 +1304,8 @@ static void mvpp2_ethtool_get_strings(struct net_device
*netdev, u32 sset,
int i;
for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_regs); i++)
- memcpy(data + i * ETH_GSTRING_LEN,
- &mvpp2_ethtool_regs[i].string, ETH_GSTRING_LEN);
+ strscpy(data + i * ETH_GSTRING_LEN,
+ mvpp2_ethtool_regs[i].string, ETH_GSTRING_LEN);
}
}
--
2.20.1
Re: [tip:locking/core] Documentation/atomic_t.txt: Clarify pure non-rmw usage
On Mon, Jun 03, 2019 at 06:46:54AM -0700, tip-bot for Peter Zijlstra wrote:
> Commit-ID: fff9b6c7d26943a8eb32b58364b7ec6b9369746a
> Gitweb:
> https://git.kernel.org/tip/fff9b6c7d26943a8eb32b58364b7ec6b9369746a
> Author: Peter Zijlstra
> AuthorDate: Fri, 24 May 2019 13:52:31 +0200
> Committer: Ingo Molnar
> CommitDate: Mon, 3 Jun 2019 12:32:57 +0200
>
> Documentation/atomic_t.txt: Clarify pure non-rmw usage
>
> Clarify that pure non-RMW usage of atomic_t is pointless, there is
> nothing 'magical' about atomic_set() / atomic_read().
>
> This is something that seems to confuse people, because I happen upon it
> semi-regularly.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Reviewed-by: Greg Kroah-Hartman
> Acked-by: Will Deacon
> Cc: Linus Torvalds
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Link:
> https://lkml.kernel.org/r/20190524115231.gn2...@hirez.programming.kicks-ass.net
> Signed-off-by: Ingo Molnar
I'd appreciate if you could Cc: me in future changes to this doc.
(as currently suggested by get_maintainer.pl).
This is particularly annoying when you spend time to review such
changes:
https://lkml.kernel.org/r/20190528111558.GA9106@andrea
Thanks,
Andrea
> ---
> Documentation/atomic_t.txt | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt
> index dca3fb0554db..89eae7f6b360 100644
> --- a/Documentation/atomic_t.txt
> +++ b/Documentation/atomic_t.txt
> @@ -81,9 +81,11 @@ Non-RMW ops:
>
> The non-RMW ops are (typically) regular LOADs and STOREs and are canonically
> implemented using READ_ONCE(), WRITE_ONCE(), smp_load_acquire() and
> -smp_store_release() respectively.
> +smp_store_release() respectively. Therefore, if you find yourself only using
> +the Non-RMW operations of atomic_t, you do not in fact need atomic_t at all
> +and are doing it wrong.
>
> -The one detail to this is that atomic_set{}() should be observable to the RMW
> +A subtle detail of atomic_set{}() is that it should be observable to the RMW
> ops. That is:
>
>C atomic-set
Re: [PATCH] arm64: dts: sdm845: Add CPU topology
On Thu, 6 Jun 2019 at 10:34, Dietmar Eggemann wrote:
>
> On 6/6/19 10:20 AM, Vincent Guittot wrote:
> > On Thu, 6 Jun 2019 at 09:49, Quentin Perret wrote:
> >>
> >> Hi Vincent,
> >>
> >> On Thursday 06 Jun 2019 at 09:05:16 (+0200), Vincent Guittot wrote:
> >>> Hi Quentin,
> >>>
> >>> On Wed, 5 Jun 2019 at 19:21, Quentin Perret
> >>> wrote:
>
> On Friday 17 May 2019 at 14:55:19 (-0700), Stephen Boyd wrote:
> > Quoting Amit Kucheria (2019-05-16 04:54:45)
> >> (cc'ing Andy's correct email address)
> >>
> >> On Wed, May 15, 2019 at 2:46 AM Stephen Boyd
> >> wrote:
> >>>
> >>> Quoting Amit Kucheria (2019-05-13 04:54:12)
> On Mon, May 13, 2019 at 4:31 PM Amit Kucheria
> wrote:
> >
> > On Tue, Jan 15, 2019 at 12:13 AM Matthias Kaehlcke
> > wrote:
> >>
> >> The 8 CPU cores of the SDM845 are organized in two clusters of 4
> >> big
> >> ("gold") and 4 little ("silver") cores. Add a cpu-map node to the
> >> DT
> >> that describes this topology.
> >
> > This is partly true. There are two groups of gold and silver cores,
> > but AFAICT they are in a single cluster, not two separate ones.
> > SDM845
> > is one of the early examples of ARM's Dynamiq architecture.
> >
> >> Signed-off-by: Matthias Kaehlcke
> >
> > I noticed that this patch sneaked through for this merge window but
> > perhaps we can whip up a quick fix for -rc2?
> >
>
> And please find attached a patch to fix this up. Andy, since this
> hasn't landed yet (can we still squash this into the original
> patch?),
> I couldn't add a Fixes tag.
>
> >>>
> >>> I had the same concern. Thanks for catching this. I suspect this must
> >>> cause some problem for IPA given that it can't discern between the big
> >>> and little "power clusters"?
> >>
> >> Both EAS and IPA, I believe. It influences the scheduler's view of the
> >> the topology.
> >
> > And EAS and IPA are OK with the real topology? I'm just curious if
> > changing the topology to reflect reality will be a problem for those
> > two.
>
> FWIW, neither EAS nor IPA depends on this. Not the upstream version of
> EAS at least (which is used in recent Android kernels -- 4.19+).
>
> But doing this is still required for other things in the scheduler (the
> so-called 'capacity-awareness' code). So until we have a better
> solution, this patch is doing the right thing.
> >>>
> >>> I'm not sure to catch what you mean ?
> >>> Which so-called 'capacity-awareness' code are you speaking about ? and
> >>> what is the problem ?
> >>
> >> I'm talking about the wake-up path. ATM select_idle_sibling() is totally
> >> unaware of capacity differences. In its current form, this function
> >> basically assumes that all CPUs in a given sd_llc have the same
> >> capacity, which would be wrong if we had a single MC level for SDM845.
> >> So, until select_idle_sibling() is 'fixed' to be capacity-aware, we need
> >> two levels of sd for asymetric systems (including DynamIQ) so the
> >> wake_cap() story actually works.
> >>
> >> I hope that clarifies it :)
> >
> > hmm... does this justifies this wrong topology ?
> > select_idle_sibling() is called only when system is overloaded and
> > scheduler disables the EAS path
> > In this case, the scheduler looks either for an idle cpu or for evenly
> > spreading the loads
> > This is maybe not always optimal and should probably be fixed but
> > doesn't justifies a wrong topology description IMHO
>
> The big/Little cluster detection in wake_cap() doesn't work anymore with
> DynamIQ w/o Phanton (DIE) domain. So the decision of going sis() or slow
> path is IMHO broken.
That's probably not the right thread to discuss this further but i'm
not sure to understand why wake_cap() doesn't work as it compares the
capacity_orig of local cpu and prev cpu which are the same whatever
the sche domainœ
> But I support the idea of not introducing Phantom Domains in device tree
> and fix wake_cap() instead.
Re: [PATCH v2 RESEND] scripts: use pkg-config to locate libcrypto
David Woodhouse wrote: > On Thu, 2019-06-06 at 09:55 +0200, Rolf Eike Beer wrote: > > +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || > > -lcrypto) > That's going to run: > > $ pkg-config --libs libcrypto || -lcrypto > > > If libcrypto.pc isn't there, it's going to get this: > > > -lcrypto: command not found > > I think you meant: > > +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || echo > -lcrypto) Doh! Thanks, v3 in a minute. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
RE: [PATCH 1/3] x86/CPU: Add more Icelake model number
> From: Borislav Petkov [mailto:b...@alien8.de] >> ... >> Dropping my SOB or adding a text "[Qiuxu: Get the macros in the Ice Lake >> group sorted by > > model number.]" at the end of the commit message - which one is > > better/clear for you? > > I'll add that note when applying. > > Thx. Thanks Boris! -Qiuxu
Re: [PATCH] RISC-V: Break load reservations during switch_to
Ah that’s sneaky!! > On Jun 6, 2019, at 12:17 AM, Palmer Dabbelt wrote: > > The comment describes why in detail. This was found because QEMU never > gives up load reservations, the issue is unlikely to manifest on real > hardware. > > Thanks to Carlos Eduardo for finding the bug! > > Signed-off-by: Palmer Dabbelt > --- > arch/riscv/kernel/entry.S | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S > index 1c1ecc238cfa..e9fc3480e6b4 100644 > --- a/arch/riscv/kernel/entry.S > +++ b/arch/riscv/kernel/entry.S > @@ -330,6 +330,24 @@ ENTRY(__switch_to) > add a3, a0, a4 > add a4, a1, a4 > REG_S ra, TASK_THREAD_RA_RA(a3) > + /* > + * The Linux ABI allows programs to depend on load reservations being > + * broken on context switches, but the ISA doesn't require that the > + * hardware ever breaks a load reservation. The only way to break a > + * load reservation is with a store conditional, so we emit one here. > + * Since nothing ever takes a load reservation on TASK_THREAD_RA_RA we > + * know this will always fail, but just to be on the safe side this > + * writes the same value that was unconditionally written by the > + * previous instruction. > + */ > +#if (TASK_THREAD_RA_RA != 0) > +# error "The offset between ra and ra is non-zero" > +#endif > +#if (__riscv_xlen == 64) > + sc.d x0, ra, 0(a3) > +#else > + sc.w x0, ra, 0(a3) > +#endif > REG_S sp, TASK_THREAD_SP_RA(a3) > REG_S s0, TASK_THREAD_S0_RA(a3) > REG_S s1, TASK_THREAD_S1_RA(a3) > -- > 2.21.0 > signature.asc Description: Message signed with OpenPGP
Re: [PATCH v3 2/2] media: atmel: atmel-sama5d2-isc: fixed checkpatch warnings
On 06.06.2019 11:34, Sakari Ailus wrote:
> Hi Eugen,
>
> On Thu, Jun 06, 2019 at 07:43:47AM +, eugen.hris...@microchip.com wrote:
>> From: Eugen Hristev
>>
>> Checkpatch complaining that locks do not have comments,
>> unaligned code and macro reuse of same argument in to_isc_clk.
>> Fixed them by renaming, realigning and adding struct comments
>>
>> Signed-off-by: Eugen Hristev
>> ---
>> Changes in v3:
>> - new patch, addresses the checkpatch issues that Hans asked to fix
>>
>> drivers/media/platform/atmel/atmel-isc.h | 51
>> +---
>> drivers/media/platform/atmel/atmel-sama5d2-isc.c | 4 +-
>> 2 files changed, 48 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/media/platform/atmel/atmel-isc.h
>> b/drivers/media/platform/atmel/atmel-isc.h
>> index 0bd5dff..6ff9fa8 100644
>> --- a/drivers/media/platform/atmel/atmel-isc.h
>> +++ b/drivers/media/platform/atmel/atmel-isc.h
>> @@ -24,14 +24,14 @@ struct isc_clk {
>> struct clk_hw hw;
>> struct clk *clk;
>> struct regmap *regmap;
>> -spinlock_t lock;
>> +spinlock_t lock; /* synchronize access to clock registers */
>
> You probably want to serialise the access, not synchronise it (i.e. happen
> at the same time). So, s/synchronise/serialise/ ?
Hello Sakari,
For sure, what I meant is to use access synchronization : do not access
in the same time (synchronize one with another to avoid corruption of
data, etc.)
You believe serialize is a better term ? I considered 'synchronization'
to be more generic : this definition which I found online :
Data synchronization is the process of maintaining the consistency and
uniformity of data instances across all consuming applications and
storing devices. It ensures that the same copy or version of data is
used in all devices - from source to destination.
If you think serialize is better I can change it
Eugen
>
> Same on the isc_device fields below.
>
> With that,
>
> Acked-by: Sakari Ailus
>
>> u8 id;
>> u8 parent_id;
>> u32 div;
>> struct device *dev;
>> };
>>
>> -#define to_isc_clk(hw) container_of(hw, struct isc_clk, hw)
>> +#define to_isc_clk(v) container_of(v, struct isc_clk, hw)
>>
>> struct isc_buffer {
>> struct vb2_v4l2_buffer vb;
>> @@ -146,6 +146,47 @@ struct isc_ctrls {
>>
>> #define ISC_PIPE_LINE_NODE_NUM 11
>>
>> +/*
>> + * struct isc_device - ISC device driver data/config struct
>> + * @regmap: Register map
>> + * @hclock: Hclock clock input (refer datasheet)
>> + * @ispck: iscpck clock (refer datasheet)
>> + * @isc_clks: ISC clocks
>> + *
>> + * @dev:Registered device driver
>> + * @v4l2_dev: v4l2 registered device
>> + * @video_dev: registered video device
>> + *
>> + * @vb2_vidq: video buffer 2 video queue
>> + * @dma_queue_lock: lock to synchronize the dma buffer queue
>> + * @dma_queue: the queue for dma buffers
>> + * @cur_frm:current isc frame/buffer
>> + * @sequence: current frame number
>> + * @stop: true if isc is not streaming, false if streaming
>> + * @comp: completion reference that signals frame completion
>> + *
>> + * @fmt:current v42l format
>> + * @user_formats: list of formats that are supported and agreed with sd
>> + * @num_user_formats: how many formats are in user_formats
>> + *
>> + * @config: current ISC format configuration
>> + * @try_config: the current ISC try format , not yet activated
>> + *
>> + * @ctrls: holds information about ISC controls
>> + * @do_wb_ctrl: control regarding the DO_WHITE_BALANCE button
>> + * @awb_work: workqueue reference for autowhitebalance
>> histogram
>> + * analysis
>> + *
>> + * @lock: lock for synchronizing userspace file operations
>> + * with ISC operations
>> + * @awb_lock: lock for synchronizing awb work queue operations
>> + * with DMA/buffer operations
>> + *
>> + * @pipeline: configuration of the ISC pipeline
>> + *
>> + * @current_subdev: current subdevice: the sensor
>> + * @subdev_entities:list of subdevice entitites
>> + */
>> struct isc_device {
>> struct regmap *regmap;
>> struct clk *hclock;
>> @@ -157,7 +198,7 @@ struct isc_device {
>> struct video_device video_dev;
>>
>> struct vb2_queuevb2_vidq;
>> -spinlock_t dma_queue_lock;
>> +spinlock_t dma_queue_lock; /* sync access to dma queue */
>> struct list_headdma_queue;
>> struct isc_buffer *cur_frm;
>> unsigned intsequence;
>> @@ -175,8 +216,8 @@ struct isc_device {
>> struct v4l2_ctrl*do_wb_ctrl;
>> struct work_struct
Re: [PATCH v2] dt-bindings: iio: accel: adxl372: switch to YAML bindings
On Fri, 2019-05-31 at 17:11 -0300, Lucas Oshiro wrote:
> [External]
>
>
> Convert the old device tree documentation to yaml format.
>
> Signed-off-by: Lucas Oshiro
> Signed-off-by: Rodrigo Ribeiro
> Co-developed-by: Rodrigo Ribeiro
> Reviewed-by: Matheus Tavares
> Reviewed-by: Marcelo Schmitt
Reviewed-by: Alexandru Ardelean
> ---
> V2:
> - Update MAINTAINERS file
> - Remove description field for reg and interrupts properties
> - Add interrupts as a required property
>
> .../bindings/iio/accel/adi,adxl372.yaml | 63 +++
> .../devicetree/bindings/iio/accel/adxl372.txt | 33 --
> MAINTAINERS | 2 +-
> 3 files changed, 64 insertions(+), 34 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
> delete mode 100644 Documentation/devicetree/bindings/iio/accel/adxl372.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
> b/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
> new file mode 100644
> index ..a7fafb9bf5c6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/accelerometers/adi,adxl372.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer
> +
> +maintainers:
> + - Stefan Popa
> +
> +description: |
> + Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer that
> supports
> + both I2C & SPI interfaces
> +https://www.analog.com/en/products/adxl372.html
> +
> +properties:
> + compatible:
> +enum:
> + - adi,adxl372
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +examples:
> + - |
> +#include
> +#include
> +i2c0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +/* Example for a I2C device node */
> +accelerometer@53 {
> +compatible = "adi,adxl372";
> +reg = <0x53>;
> +interrupt-parent = <&gpio>;
> +interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> +};
> +};
> + - |
> +#include
> +#include
> +spi0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +accelerometer@0 {
> +compatible = "adi,adxl372";
> +reg = <0>;
> +spi-max-frequency = <100>;
> +interrupt-parent = <&gpio>;
> +interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> +};
> +};
> diff --git a/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> deleted file mode 100644
> index a289964756a7..
> --- a/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer
> -
> -http://www.analog.com/media/en/technical-documentation/data-sheets/adxl372.pdf
> -
> -Required properties:
> - - compatible : should be "adi,adxl372"
> - - reg: the I2C address or SPI chip select number for the device
> -
> -Required properties for SPI bus usage:
> - - spi-max-frequency: Max SPI frequency to use
> -
> -Optional properties:
> - - interrupts: interrupt mapping for IRQ as documented in
> - Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> -
> -Example for a I2C device node:
> -
> - accelerometer@53 {
> - compatible = "adi,adxl372";
> - reg = <0x53>;
> - interrupt-parent = <&gpio>;
> - interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> - };
> -
> -Example for a SPI device node:
> -
> - accelerometer@0 {
> - compatible = "adi,adxl372";
> - reg = <0>;
> - spi-max-frequency = <100>;
> - interrupt-parent = <&gpio>;
> - interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> - };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 43a9cebb2c19..06cca7cd9627 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -559,7 +559,7 @@ S: Supported
> F: drivers/iio/accel/adxl372.c
> F: drivers/iio/accel/adxl372_spi.c
> F: drivers/iio/accel/adxl372_i2c.c
> -F: Documentation/devicetree/bindings/iio/accel/adxl372.txt
> +F: Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
>
> AF9013 MEDIA DRIVER
> M: Antti Palosaari
> --
> 2.21.0
>
Re: KASAN: use-after-free Read in device_del
Am Montag, den 03.06.2019, 04:41 -0700 schrieb syzbot:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:69bbe8c7 usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=1684d87ca0
> kernel config: https://syzkaller.appspot.com/x/.config?x=193d8457178b3229
> dashboard link: https://syzkaller.appspot.com/bug?extid=93f2f45b19519b289613
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
Will this do?
Regards
Oliver
From 6867abc1701f18892d32e8aeaf644901e9bcbf82 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Wed, 5 Jun 2019 13:49:21 +0200
Subject: [PATCH] usb: hso: initialize so that we can tear down in the error
case
Initualization must follow the sequence stuff is undone in case
we bail out. Thus the parent pointer must be set earlier.
Signed-off-by: Oliver Neukum
---
drivers/net/usb/hso.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 6a0ecddff310..4d9100fb9f6e 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2653,6 +2653,9 @@ static struct hso_device *hso_create_bulk_serial_device(
BULK_URB_TX_SIZE))
goto exit;
+ /* and record this serial */
+ set_serial_by_index(serial->minor, serial);
+
serial->in_endp = hso_get_ep(interface, USB_ENDPOINT_XFER_BULK,
USB_DIR_IN);
if (!serial->in_endp) {
@@ -2669,9 +2672,6 @@ static struct hso_device *hso_create_bulk_serial_device(
serial->write_data = hso_std_serial_write_data;
- /* and record this serial */
- set_serial_by_index(serial->minor, serial);
-
/* setup the proc dirs and files if needed */
hso_log_port(hso_dev);
--
2.16.4
[PATCH v2] hwmon: (smsc47m1) fix (suspicious) outside array bounds warnings
Kbuild test robot reports outside array bounds warnings.
This is reproducible for ARCH=sh allmodconfig with the kernel.org
toolchains available at:
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-sh4-linux.tar.xz
CC [M] drivers/hwmon/smsc47m1.o
drivers/hwmon/smsc47m1.c: In function 'fan_div_store':
drivers/hwmon/smsc47m1.c:370:49: warning: array subscript [0, 2] is outside
array bounds of 'u8[3]' {aka 'unsigned char[3]'} [-Warray-bounds]
tmp = 192 - (old_div * (192 - data->fan_preload[nr])
~^~~~
drivers/hwmon/smsc47m1.c:372:19: warning: array subscript [0, 2] is outside
array bounds of 'u8[3]' {aka 'unsigned char[3]'} [-Warray-bounds]
data->fan_preload[nr] = clamp_val(tmp, 0, 191);
~^~~~
drivers/hwmon/smsc47m1.c:373:53: warning: array subscript [0, 2] is outside
array bounds of 'const u8[3]' {aka 'const unsigned char[3]'} [-Warray-bounds]
smsc47m1_write_value(data, SMSC47M1_REG_FAN_PRELOAD[nr],
^~~~
Looking at the code, I believe these are false positives.
While it is ridiculous to patch our driver to make the insane
compiler happy, clarifying the unreachable path will be helpful
not only for compilers but also for humans.
Reported-by: kbuild test robot
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Use unreachable() instead of WARN_ON()
- Mention that the report seems suspicious
drivers/hwmon/smsc47m1.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hwmon/smsc47m1.c b/drivers/hwmon/smsc47m1.c
index cc6aca6e436c..6d366c9cb906 100644
--- a/drivers/hwmon/smsc47m1.c
+++ b/drivers/hwmon/smsc47m1.c
@@ -351,6 +351,8 @@ static ssize_t fan_div_store(struct device *dev,
tmp |= data->fan_div[2] << 4;
smsc47m1_write_value(data, SMSC47M2_REG_FANDIV3, tmp);
break;
+ default:
+ unreachable();
}
/* Preserve fan min */
--
2.17.1
[PATCH v3] scripts: use pkg-config to locate libcrypto
>From 71e19be4247fbaa2540dfb321e2b148234680a13 Mon Sep 17 00:00:00 2001 From: Rolf Eike Beer Date: Thu, 22 Nov 2018 16:40:49 +0100 Subject: [PATCH] scripts: use pkg-config to locate libcrypto Otherwise build fails if the headers are not in the default location. While at it also ask pkg-config for the libs, with fallback to the existing value. Signed-off-by: Rolf Eike Beer Cc: sta...@vger.kernel.org # 4.19.x --- scripts/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) v2: add CRYPTO_LIBS and CRYPTO_CFLAGS v3: fix fallback -lcrypto diff --git a/scripts/Makefile b/scripts/Makefile index 9d442ee050bd..9489c3b550df 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -8,7 +8,11 @@ # conmakehash: Create chartable # conmakehash: Create arrays for initializing the kernel console tables +PKG_CONFIG?= pkg-config + HOST_EXTRACFLAGS += -I$(srctree)/tools/include +CRYPTO_LIBS = $(shell $(PKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto) +CRYPTO_CFLAGS = $(shell $(PKG_CONFIG) --cflags libcrypto 2> /dev/null) hostprogs-$(CONFIG_BUILD_BIN2C) += bin2c hostprogs-$(CONFIG_KALLSYMS) += kallsyms @@ -23,8 +27,9 @@ hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include -HOSTLDLIBS_sign-file = -lcrypto -HOSTLDLIBS_extract-cert = -lcrypto +HOSTLDLIBS_sign-file = $(CRYPTO_LIBS) +HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS) +HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS) always := $(hostprogs-y) $(hostprogs-m) -- 2.21.0 -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
[PATCH v4] selinux: lsm: fix a missing-check bug in selinux_sb_eat_lsm_o pts()
In selinux_sb_eat_lsm_opts(), 'arg' is allocated by kmemdup_nul(). It
returns NULL when fails. So 'arg' should be checked. And 'mnt_opts'
should be freed when error.
Signed-off-by: Gen Zhang
Fixes: 99dbbb593fe6 ("selinux: rewrite selinux_sb_eat_lsm_opts()")
---
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 3ec702c..13479cd 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2616,10 +2616,11 @@ static int selinux_sb_eat_lsm_opts(char *options, void
**mnt_opts)
char *from = options;
char *to = options;
bool first = true;
+ int rc;
while (1) {
int len = opt_len(from);
- int token, rc;
+ int token;
char *arg = NULL;
token = match_opt_prefix(from, len, &arg);
@@ -2635,15 +2636,15 @@ static int selinux_sb_eat_lsm_opts(char *options, void
**mnt_opts)
*q++ = c;
}
arg = kmemdup_nul(arg, q - arg, GFP_KERNEL);
+ if (!arg) {
+ rc = -ENOMEM;
+ goto free_opt;
+ }
}
rc = selinux_add_opt(token, arg, mnt_opts);
if (unlikely(rc)) {
kfree(arg);
- if (*mnt_opts) {
- selinux_free_mnt_opts(*mnt_opts);
- *mnt_opts = NULL;
- }
- return rc;
+ goto free_opt;
}
} else {
if (!first) { // copy with preceding comma
@@ -2661,6 +2662,12 @@ static int selinux_sb_eat_lsm_opts(char *options, void
**mnt_opts)
}
*to = '\0';
return 0;
+free_opt:
+ if (*mnt_opts) {
+ selinux_free_mnt_opts(*mnt_opts);
+ *mnt_opts = NULL;
+ }
+ return rc;
}
static int selinux_sb_remount(struct super_block *sb, void *mnt_opts)
[PATCH 1/2] arm64: defconfig: enable Lima driver
A bunch of arm64 boards can now use the Lima driver, let's enable it in defconfig, it will be useful to have it enabled for KernelCI boot and runtime testing. Signed-off-by: Neil Armstrong --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index d588ceb9aa3c..7e9d684332be 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -505,6 +505,7 @@ CONFIG_DRM_HISI_HIBMC=m CONFIG_DRM_HISI_KIRIN=m CONFIG_DRM_MESON=m CONFIG_DRM_PL111=m +CONFIG_DRM_LIMA=m CONFIG_DRM_PANFROST=m CONFIG_FB=y CONFIG_FB_MODE_HELPERS=y -- 2.21.0
[PATCH 2/2] ARM: multi_v7_defconfig: enable Lima driver
A bunch of armv7 boards can now use the Lima driver, let's enable it in defconfig, it will be useful to have it enabled for KernelCI boot and runtime testing. Signed-off-by: Neil Armstrong --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 952dff9d39f2..0757e0278e22 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -656,6 +656,7 @@ CONFIG_DRM_VC4=m CONFIG_DRM_ETNAVIV=m CONFIG_DRM_MXSFB=m CONFIG_DRM_PL111=m +CONFIG_DRM_LIMA=m CONFIG_DRM_PANFROST=m CONFIG_FB_EFI=y CONFIG_FB_WM8505=y -- 2.21.0
Re: [PATCH 02/13] bus_find_device: Unify the match callback with class_find_device
On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose wrote:
>
> There is an arbitrary difference between the prototypes of
> bus_find_device() and class_find_device() preventing their callers
> from passing the same pair of data and match() arguments to both of
> them, which is the const qualifier used in the prototype of
> class_find_device(). If that qualifier is also used in the
> bus_find_device() prototype, it will be possible to pass the same
> match() callback function to both bus_find_device() and
> class_find_device(), which will allow some optimizations to be made in
> order to avoid code duplication going forward. Also with that, constify
> the "data" parameter as it is passed as a const to the match function.
>
> For this reason, change the prototype of bus_find_device() to match
> the prototype of class_find_device() and adjust its callers to use the
> const qualifier in accordance with the new prototype of it.
>
> Cc: Alexander Shishkin
> Cc: Andrew Lunn
> Cc: Andreas Noever
> Cc: Arnd Bergmann
> Cc: Bjorn Helgaas
> Cc: Corey Minyard
> Cc: Christian Borntraeger
> Cc: David Kershner
> Cc: "David S. Miller"
> Cc: David Airlie
> Cc: Felipe Balbi
> Cc: Frank Rowand
> Cc: Grygorii Strashko
> Cc: Harald Freudenberger
> Cc: Hartmut Knaack
> Cc: Heiko Stuebner
> Cc: Jason Gunthorpe
> Cc: Jonathan Cameron
> Cc: Jonathan Cameron
> Cc: "James E.J. Bottomley"
> Cc: Len Brown
> Cc: Mark Brown
> Cc: Michael Ellerman
> Cc: Michael Jamet
> Cc: "Martin K. Petersen"
> Cc: Peter Oberparleiter
> Cc: Rob Herring
> Cc: Sebastian Ott
> Cc: Srinivas Kandagatla
> Cc: Yehezkel Bernat
> Cc: Wolfram Sang
> Cc: raf...@kernel.org
> Cc: Greg Kroah-Hartman
> Signed-off-by: Suzuki K Poulose
For the ACPI changes:
Acked-by: Rafael J. Wysocki
> ---
> arch/powerpc/platforms/pseries/ibmebus.c | 4 ++--
> drivers/acpi/acpi_lpss.c | 4 ++--
> drivers/acpi/sleep.c | 2 +-
> drivers/acpi/utils.c | 4 ++--
> drivers/base/bus.c | 6 +++---
> drivers/base/devcon.c | 2 +-
> drivers/char/ipmi/ipmi_si_platform.c | 2 +-
> drivers/firmware/efi/dev-path-parser.c | 4 ++--
> drivers/gpu/drm/drm_mipi_dsi.c | 2 +-
> drivers/hwtracing/coresight/coresight.c| 6 +++---
> drivers/hwtracing/coresight/of_coresight.c | 2 +-
> drivers/hwtracing/intel_th/core.c | 5 ++---
> drivers/i2c/i2c-core-acpi.c| 4 ++--
> drivers/i2c/i2c-core-of.c | 4 ++--
> drivers/iio/inkern.c | 2 +-
> drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 2 +-
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 2 +-
> drivers/net/ethernet/ti/cpsw-phy-sel.c | 4 ++--
> drivers/net/ethernet/ti/davinci_emac.c | 2 +-
> drivers/net/ethernet/toshiba/tc35815.c | 4 ++--
> drivers/nvmem/core.c | 2 +-
> drivers/of/of_mdio.c | 2 +-
> drivers/of/platform.c | 2 +-
> drivers/pci/probe.c| 2 +-
> drivers/pci/search.c | 4 ++--
> drivers/s390/cio/css.c | 4 ++--
> drivers/s390/cio/device.c | 4 ++--
> drivers/s390/cio/scm.c | 4 ++--
> drivers/s390/crypto/ap_bus.c | 8
> drivers/scsi/scsi_proc.c | 2 +-
> drivers/spi/spi.c | 4 ++--
> drivers/staging/most/core.c| 4 ++--
> drivers/thunderbolt/switch.c | 4 ++--
> drivers/usb/core/devio.c | 4 ++--
> drivers/usb/core/usb.c | 4 ++--
> drivers/usb/phy/phy-am335x-control.c | 4 ++--
> drivers/usb/phy/phy-isp1301.c | 4 ++--
> drivers/visorbus/visorbus_main.c | 4 ++--
> include/linux/device.h | 4 ++--
> sound/soc/rockchip/rk3399_gru_sound.c | 2 +-
> 40 files changed, 69 insertions(+), 70 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/ibmebus.c
> b/arch/powerpc/platforms/pseries/ibmebus.c
> index 84e8ec4..b91eb09 100644
> --- a/arch/powerpc/platforms/pseries/ibmebus.c
> +++ b/arch/powerpc/platforms/pseries/ibmebus.c
> @@ -147,13 +147,13 @@ static const struct dma_map_ops ibmebus_dma_ops = {
> .unmap_page = ibmebus_unmap_page,
> };
>
> -static int ibmebus_match_path(struct device *dev, void *data)
> +static int ibmebus_match_path(struct device *dev, const void *data)
> {
> struct device_node *dn = to_platform_device(dev)->dev.of_node;
> return (of_find_node_by_path(data) == dn);
> }
>
> -static
Re: [PATCH] RISC-V: defconfig: enable clocks, serial console
On Wed, Jun 05, 2019 at 10:50:42AM -0700, Kevin Hilman wrote: > Enable PRCI clock driver and serial console by default, so the default > upstream defconfig is bootable to a serial console. > > Signed-off-by: Kevin Hilman Looks good: Reviewed-by: Christoph Hellwig
Re: [PATCH] iio:core: Fix bug in length of event info_mask and catch unhandled bits set in masks.
On Tue, 2019-06-04 at 20:40 +0800, Young Xiao wrote:
> [External]
>
>
> The incorrect limit for the for_each_set_bit loop was noticed whilst fixing
> this other case. Note that as we only have 3 possible entries a the moment
> and the value was set to 4, the bug would not have any effect currently.
> It will bite fairly soon though, so best fix it now.
>
> See commit ef4b4856593f ("iio:core: Fix bug in length of event info_mask and
> catch unhandled bits set in masks.") for details.
>
> Signed-off-by: Young Xiao <92siuy...@gmail.com>
Reviewed-by: Alexandru Ardelean
Thanks for this patch.
This fix is validated also by the fact that iio_device_add_info_mask_type() has
this check on the same iteration.
> ---
> drivers/iio/industrialio-core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index f5a4581..dd8873a 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1107,6 +1107,8 @@ static int iio_device_add_info_mask_type_avail(struct
> iio_dev *indio_dev,
> char *avail_postfix;
>
> for_each_set_bit(i, infomask, sizeof(*infomask) * 8) {
> + if (i >= ARRAY_SIZE(iio_chan_info_postfix))
> + return -EINVAL;
> avail_postfix = kasprintf(GFP_KERNEL,
> "%s_available",
> iio_chan_info_postfix[i]);
> --
> 2.7.4
>
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
On Thu, 6 Jun 2019 at 09:08, Greg KH wrote: > > On Thu, Jun 06, 2019 at 08:55:29AM +0200, Ard Biesheuvel wrote: > > On Wed, 5 Jun 2019 at 22:48, Nick Desaulniers > > wrote: > > > > > > On Wed, Jun 5, 2019 at 11:42 AM Ard Biesheuvel > > > wrote: > > > > For the record, this is an example of why I think backporting those > > > > clang enablement patches is a bad idea. > > > > > > There's always a risk involved with backports of any kind; more CI > > > coverage can help us mitigate some of these risks in an automated > > > fashion before we get user reports like this. I meet with the > > > KernelCI folks weekly, so I'll double check on the coverage of the > > > stable tree's branches. The 0day folks are also very responsive and > > > I've spoken with them a few times, so I'll try to get to the bottom of > > > why this wasn't reported by either of those. > > > > > > Also, these patches help keep Android, CrOS, and Google internal > > > production kernels closer to their upstream sources. > > > > > > > We can't actually build those > > > > kernels with clang, can we? So what is the point? > > > > > > Here's last night's build: > > > https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/114388434 > > > > > > > If you are saying that plain upstream 4.9-stable defconfig can be > > built with Clang, then I am pleasantly surprised. > > I know some specific configs can, there's no rule that I know of that > 'defconfig' support is required. But then again, it might also work, > try it and see :) > Well, it is the rule that the arm64 maintainers use. > > > Also, Android and CrOS have shipped X million devices w/ 4.9 kernels > > > built with Clang. I think this number will grow at least one order of > > > magnitude imminently. > > > > > > > I know that (since you keep reminding me :-)), but obviously, Google > > does not care about changes that regress GCC support. > > What are you talking about? Bugs happen all the time, what specifically > did "Google" do to break gcc support? If you are referring to this > patch, and it is a regression, of course I will revert it. But note > that gcc and 4.9 works just fine for all of the other users right now, > remember we do do a lot of testing of these releases. > Don't get me wrong: I am not blaming Google for this. But having strict Documented/ stable-rules, violating them by backporting patches that are clearly not bug fixes, and *then* saying 'bugs happen all the time' makes no sense to me at all.
[PATCH v2 1/4] mfd: madera: Update DT bindings to add additional CODECs
From: Richard Fitzgerald This adds the cs47l15, cs42l92, cs47l92 and cs47l93 to the list of compatible strings and updates some properties that need to note the new CODECs. Signed-off-by: Richard Fitzgerald Signed-off-by: Charles Keepax --- No change since v1. Thanks, Charles Documentation/devicetree/bindings/mfd/madera.txt | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/madera.txt b/Documentation/devicetree/bindings/mfd/madera.txt index db3266088386a..cad0f28005027 100644 --- a/Documentation/devicetree/bindings/mfd/madera.txt +++ b/Documentation/devicetree/bindings/mfd/madera.txt @@ -11,10 +11,14 @@ bindings/sound/madera.txt Required properties: - compatible : One of the following chip-specific strings: +"cirrus,cs47l15" "cirrus,cs47l35" "cirrus,cs47l85" "cirrus,cs47l90" "cirrus,cs47l91" +"cirrus,cs42l92" +"cirrus,cs47l92" +"cirrus,cs47l93" "cirrus,wm1840" - reg : I2C slave address when connected using I2C, chip select number when @@ -22,7 +26,7 @@ Required properties: - DCVDD-supply : Power supply for the device as defined in bindings/regulator/regulator.txt -Mandatory on CS47L35, CS47L90, CS47L91 +Mandatory on CS47L15, CS47L35, CS47L90, CS47L91, CS42L92, CS47L92, CS47L93 Optional on CS47L85, WM1840 - AVDD-supply, DBVDD1-supply, DBVDD2-supply, CPVDD1-supply, CPVDD2-supply : @@ -35,7 +39,7 @@ Required properties: (CS47L85, WM1840) - SPKVDD-supply : Power supply for the device -(CS47L35) +(CS47L15, CS47L35) - interrupt-controller : Indicates that this device is an interrupt controller -- 2.11.0
[PATCH v2 3/4] mfd: madera: Add Madera core support for CS47L15
From: Richard Fitzgerald
This patch adds all the core support and defines for the Cirrus
Logic CS47L15 smart audio CODEC.
Registers or fields are named MADERA_* if it is part of the
common hardware platform and does not conflict with any other
Madera codecs. It is named CS47L15_* if it is unique to CS47L15
and conflicts with definitions on other codecs.
Signed-off-by: Richard Fitzgerald
Signed-off-by: Charles Keepax
---
Changes since v1:
- Corrected a couple of register defaults and removed a couple of registers
Thanks,
Charles
drivers/mfd/Kconfig |7 +
drivers/mfd/Makefile |3 +
drivers/mfd/cs47l15-tables.c | 1300 ++
drivers/mfd/madera-core.c| 44 ++
drivers/mfd/madera-i2c.c |7 +
drivers/mfd/madera-spi.c |7 +
drivers/mfd/madera.h |6 +
include/linux/mfd/madera/core.h |2 +
include/linux/mfd/madera/registers.h |5 +
9 files changed, 1381 insertions(+)
create mode 100644 drivers/mfd/cs47l15-tables.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 294d9567cc71c..cae6977f6fc03 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -260,6 +260,13 @@ config MFD_MADERA_SPI
Support for the Cirrus Logic Madera platform audio SoC
core functionality controlled via SPI.
+config MFD_CS47L15
+ bool "Cirrus Logic CS47L15"
+ select PINCTRL_CS47L15
+ depends on MFD_MADERA
+ help
+ Support for Cirrus Logic CS47L15 Smart Codec
+
config MFD_CS47L35
bool "Cirrus Logic CS47L35"
select PINCTRL_CS47L35
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 52b1a90ff5159..5444e89f14806 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -75,6 +75,9 @@ obj-$(CONFIG_MFD_WM8994) += wm8994.o
obj-$(CONFIG_MFD_WM97xx) += wm97xx-core.o
madera-objs:= madera-core.o
+ifeq ($(CONFIG_MFD_CS47L15),y)
+madera-objs+= cs47l15-tables.o
+endif
ifeq ($(CONFIG_MFD_CS47L35),y)
madera-objs+= cs47l35-tables.o
endif
diff --git a/drivers/mfd/cs47l15-tables.c b/drivers/mfd/cs47l15-tables.c
new file mode 100644
index 0..ea5fd05de769c
--- /dev/null
+++ b/drivers/mfd/cs47l15-tables.c
@@ -0,0 +1,1300 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Regmap tables for CS47L15 codec
+ *
+ * Copyright (C) 2016-2019 Cirrus Logic, Inc. and
+ * Cirrus Logic International Semiconductor Ltd.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include "madera.h"
+
+static const struct reg_sequence cs47l15_reva_16_patch[] = {
+ { 0x8C, 0x },
+ { 0x8C, 0x },
+ { 0x314, 0x0080 },
+ { 0x4A8, 0x6023 },
+ { 0x4A9, 0x6023 },
+ { 0x4D4, 0x0008 },
+ { 0x4CF, 0x0F00 },
+ { 0x4D7, 0x1B2B },
+ { 0x8C, 0x },
+ { 0x8C, 0x },
+};
+
+int cs47l15_patch(struct madera *madera)
+{
+ int ret;
+
+ ret = regmap_register_patch(madera->regmap,
+ cs47l15_reva_16_patch,
+ ARRAY_SIZE(cs47l15_reva_16_patch));
+ if (ret < 0) {
+ dev_err(madera->dev,
+ "Error in applying 16-bit patch: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(cs47l15_patch);
+
+static const struct reg_default cs47l15_reg_default[] = {
+ { 0x0020, 0x }, /* R32 (0x20) - Tone Generator 1 */
+ { 0x0021, 0x1000 }, /* R33 (0x21) - Tone Generator 2 */
+ { 0x0022, 0x }, /* R34 (0x22) - Tone Generator 3 */
+ { 0x0023, 0x1000 }, /* R35 (0x23) - Tone Generator 4 */
+ { 0x0024, 0x }, /* R36 (0x24) - Tone Generator 5 */
+ { 0x0030, 0x }, /* R48 (0x30) - PWM Drive 1 */
+ { 0x0031, 0x0100 }, /* R49 (0x31) - PWM Drive 2 */
+ { 0x0032, 0x0100 }, /* R50 (0x32) - PWM Drive 3 */
+ { 0x0061, 0x01ff }, /* R97 (0x61) - Sample Rate Sequence Select 1 */
+ { 0x0062, 0x01ff }, /* R98 (0x62) - Sample Rate Sequence Select 2 */
+ { 0x0063, 0x01ff }, /* R99 (0x63) - Sample Rate Sequence Select 3 */
+ { 0x0064, 0x01ff }, /* R100 (0x64) - Sample Rate Sequence Select 4
*/
+ { 0x0066, 0x01ff }, /* R102 (0x66) - Always On Triggers Sequence
Select 1 */
+ { 0x0067, 0x01ff }, /* R103 (0x67) - Always On Triggers Sequence
Select 2 */
+ { 0x0090, 0x }, /* R144 (0x90) - Haptics Control 1 */
+ { 0x0091, 0x7fff }, /* R145 (0x91) - Haptics Control 2 */
+ { 0x0092, 0x }, /* R146 (0x92) - Haptics Phase 1 Intensity */
+ { 0x0093, 0x }, /* R147 (0x93) - Haptics Phase 1 Duration */
+ { 0x0094, 0x }, /* R148 (0x94) - Haptics Phase 2 Intensity */
+ { 0x0095, 0x }, /* R149 (0x95) - Haptics Phase 2 D
[PATCH v2 2/4] mfd: madera: Remove some unused registers and fix some defaults
Signed-off-by: Charles Keepax
---
New since v1 of the series.
Thanks,
Charles
drivers/mfd/cs47l35-tables.c | 54 +--
drivers/mfd/cs47l85-tables.c | 122 ++-
drivers/mfd/cs47l90-tables.c | 76 ---
3 files changed, 6 insertions(+), 246 deletions(-)
diff --git a/drivers/mfd/cs47l35-tables.c b/drivers/mfd/cs47l35-tables.c
index 338b825127f13..fe838cbc2a7ee 100644
--- a/drivers/mfd/cs47l35-tables.c
+++ b/drivers/mfd/cs47l35-tables.c
@@ -109,9 +109,8 @@ static const struct reg_default cs47l35_reg_default[] = {
{ 0x0174, 0x007d }, /* R372 (0x174) - FLL1 Control 4 */
{ 0x0175, 0x }, /* R373 (0x175) - FLL1 Control 5 */
{ 0x0176, 0x }, /* R374 (0x176) - FLL1 Control 6 */
- { 0x0177, 0x0281 }, /* R375 (0x177) - FLL1 Loop Filter Test 1 */
{ 0x0179, 0x }, /* R377 (0x179) - FLL1 Control 7 */
- { 0x017a, 0x0b06 }, /* R378 (0x17a) - FLL1 EFS2 */
+ { 0x017a, 0x2906 }, /* R378 (0x17a) - FLL1 EFS2 */
{ 0x017f, 0x }, /* R383 (0x17f) - FLL1 Synchroniser 1 */
{ 0x0180, 0x }, /* R384 (0x180) - FLL1 Synchroniser 2 */
{ 0x0181, 0x }, /* R385 (0x181) - FLL1 Synchroniser 3 */
@@ -174,9 +173,6 @@ static const struct reg_default cs47l35_reg_default[] = {
{ 0x0434, 0x }, /* R1076 (0x434) - Output Path Config 5R */
{ 0x0435, 0x0180 }, /* R1077 (0x435) - DAC Digital Volume 5R */
{ 0x0437, 0x0200 }, /* R1079 (0x437) - Noise Gate Select 5R */
- { 0x0440, 0x0003 }, /* R1088 (0x440) - DRE Enable */
- { 0x0448, 0x0a83 }, /* R1096 (0x448) - eDRE Enable */
- { 0x044a, 0x }, /* R1098 (0x44a) - eDRE Manual */
{ 0x0450, 0x }, /* R1104 (0x450) - DAC AEC Control 1 */
{ 0x0451, 0x }, /* R1105 (0x451) - DAC AEC Control 2 */
{ 0x0458, 0x }, /* R1112 (0x458) - Noise Gate Control */
@@ -720,28 +716,6 @@ static const struct reg_default cs47l35_reg_default[] = {
{ 0x0ef3, 0x }, /* R3827 (0xef3) - ISRC 2 CTRL 1 */
{ 0x0ef4, 0x0001 }, /* R3828 (0xef4) - ISRC 2 CTRL 2 */
{ 0x0ef5, 0x }, /* R3829 (0xef5) - ISRC 2 CTRL 3 */
- { 0x1300, 0x }, /* R4864 (0x1300) - DAC Comp 1 */
- { 0x1302, 0x }, /* R4866 (0x1302) - DAC Comp 2 */
- { 0x1380, 0x }, /* R4992 (0x1380) - FRF Coefficient 1L 1 */
- { 0x1381, 0x }, /* R4993 (0x1381) - FRF Coefficient 1L 2 */
- { 0x1382, 0x }, /* R4994 (0x1382) - FRF Coefficient 1L 3 */
- { 0x1383, 0x }, /* R4995 (0x1383) - FRF Coefficient 1L 4 */
- { 0x1390, 0x }, /* R5008 (0x1390) - FRF Coefficient 1R 1 */
- { 0x1391, 0x }, /* R5009 (0x1391) - FRF Coefficient 1R 2 */
- { 0x1392, 0x }, /* R5010 (0x1392) - FRF Coefficient 1R 3 */
- { 0x1393, 0x }, /* R5011 (0x1393) - FRF Coefficient 1R 4 */
- { 0x13a0, 0x }, /* R5024 (0x13a0) - FRF Coefficient 4L 1 */
- { 0x13a1, 0x }, /* R5025 (0x13a1) - FRF Coefficient 4L 2 */
- { 0x13a2, 0x }, /* R5026 (0x13a2) - FRF Coefficient 4L 3 */
- { 0x13a3, 0x }, /* R5027 (0x13a3) - FRF Coefficient 4L 4 */
- { 0x13b0, 0x }, /* R5040 (0x13b0) - FRF Coefficient 5L 1 */
- { 0x13b1, 0x }, /* R5041 (0x13b1) - FRF Coefficient 5L 2 */
- { 0x13b2, 0x }, /* R5042 (0x13b2) - FRF Coefficient 5L 3 */
- { 0x13b3, 0x }, /* R5043 (0x13b3) - FRF Coefficient 5L 4 */
- { 0x13c0, 0x }, /* R5040 (0x13c0) - FRF Coefficient 5R 1 */
- { 0x13c1, 0x }, /* R5041 (0x13c1) - FRF Coefficient 5R 2 */
- { 0x13c2, 0x }, /* R5042 (0x13c2) - FRF Coefficient 5R 3 */
- { 0x13c3, 0x }, /* R5043 (0x13c3) - FRF Coefficient 5R 4 */
{ 0x1700, 0x2001 }, /* R5888 (0x1700) - GPIO1 Control 1 */
{ 0x1701, 0xf000 }, /* R5889 (0x1701) - GPIO1 Control 2 */
{ 0x1702, 0x2001 }, /* R5890 (0x1702) - GPIO2 Control 1 */
@@ -892,7 +866,6 @@ static bool cs47l35_16bit_readable_register(struct device
*dev,
case MADERA_FLL1_CONTROL_6:
case MADERA_FLL1_CONTROL_7:
case MADERA_FLL1_EFS_2:
- case MADERA_FLL1_LOOP_FILTER_TEST_1:
case CS47L35_FLL1_SYNCHRONISER_1:
case CS47L35_FLL1_SYNCHRONISER_2:
case CS47L35_FLL1_SYNCHRONISER_3:
@@ -967,9 +940,6 @@ static bool cs47l35_16bit_readable_register(struct device
*dev,
case MADERA_OUTPUT_PATH_CONFIG_5R:
case MADERA_DAC_DIGITAL_VOLUME_5R:
case MADERA_NOISE_GATE_SELECT_5R:
- case MADERA_DRE_ENABLE:
- case MADERA_EDRE_ENABLE:
- case MADERA_EDRE_MANUAL:
case MADERA_DAC_AEC_CONTROL_1:
case MADERA_DAC_AEC_CONTROL_2:
case MADERA_NOISE_GATE_CONTROL:
@@ -1439,28 +1409,6 @@ static bool cs47l35_16bit_re
[PATCH v2 4/4] mfd: madera: Add Madera core support for CS47L92
From: Richard Fitzgerald
This patch adds all the core support and defines for the Cirrus
Logic CS42L92, CS47L92 and CS47L93 smart audio CODECs.
Registers or fields are named MADERA_* if it is part of the
common hardware platform and does not conflict with any other
Madera codecs. It is named CS47L15_* if it is unique to CS47L15
and conflicts with definitions on other codecs.
Signed-off-by: Stuart Henderson
Signed-off-by: Richard Fitzgerald
Signed-off-by: Charles Keepax
---
Changes since v1:
- Corrected a couple of register defaults and removed a couple of registers
Thanks,
Charles
drivers/mfd/Kconfig |7 +
drivers/mfd/Makefile |3 +
drivers/mfd/cs47l92-tables.c | 1947 ++
drivers/mfd/madera-core.c| 58 +
drivers/mfd/madera-i2c.c | 11 +
drivers/mfd/madera-spi.c | 11 +
drivers/mfd/madera.h |7 +
include/linux/mfd/madera/core.h |4 +
include/linux/mfd/madera/registers.h | 195
9 files changed, 2243 insertions(+)
create mode 100644 drivers/mfd/cs47l92-tables.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index cae6977f6fc03..784e00db2b282 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -288,6 +288,13 @@ config MFD_CS47L90
help
Support for Cirrus Logic CS47L90 and CS47L91 Smart Codecs
+config MFD_CS47L92
+ bool "Cirrus Logic CS47L92/93"
+ select PINCTRL_CS47L92
+ depends on MFD_MADERA
+ help
+ Support for Cirrus Logic CS42L92, CS47L92 and CS47L93 Smart Codecs
+
config MFD_ASIC3
bool "Compaq ASIC3"
depends on GPIOLIB && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5444e89f14806..8ae665f483a09 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -87,6 +87,9 @@ endif
ifeq ($(CONFIG_MFD_CS47L90),y)
madera-objs+= cs47l90-tables.o
endif
+ifeq ($(CONFIG_MFD_CS47L92),y)
+madera-objs+= cs47l92-tables.o
+endif
obj-$(CONFIG_MFD_MADERA) += madera.o
obj-$(CONFIG_MFD_MADERA_I2C) += madera-i2c.o
obj-$(CONFIG_MFD_MADERA_SPI) += madera-spi.o
diff --git a/drivers/mfd/cs47l92-tables.c b/drivers/mfd/cs47l92-tables.c
new file mode 100644
index 0..c8a2343813502
--- /dev/null
+++ b/drivers/mfd/cs47l92-tables.c
@@ -0,0 +1,1947 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Regmap tables for CS47L92 codec
+ *
+ * Copyright (C) 2016-2019 Cirrus Logic, Inc. and
+ * Cirrus Logic International Semiconductor Ltd.
+ *
+ * Author: Stuart Henderson
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include "madera.h"
+
+static const struct reg_sequence cs47l92_reva_16_patch[] = {
+ { 0x3A2, 0x2C29 },
+ { 0x3A3, 0x0E00 },
+ { 0x281, 0x },
+ { 0x282, 0x },
+ { 0x4EA, 0x0100 },
+ { 0x22B, 0x },
+ { 0x4A0, 0x0080 },
+ { 0x4A1, 0x },
+ { 0x4A2, 0x },
+ { 0x180B, 0x033F },
+ { 0x190B, 0x033F },
+ { 0x442, 0x0304 },
+ { 0x34C, 0x0003 },
+ { 0x124, 0x0C49 },
+ { 0x120, 0x0345 },
+ { 0x120, 0x0305 },
+ { 0x4FA, 0x5064 },
+ { 0x1300, 0x050E },
+ { 0x1302, 0x0101 },
+ { 0x1380, 0x02E0 },
+ { 0x1381, 0xF942 },
+ { 0x1382, 0x04CE },
+ { 0x1383, 0xFF06 },
+ { 0x1390, 0x0304 },
+ { 0x1391, 0xF8FF },
+ { 0x1392, 0x04F3 },
+ { 0x1393, 0xFF00 },
+ { 0x13A0, 0x02E0 },
+ { 0x13A1, 0xF942 },
+ { 0x13A2, 0x04CE },
+ { 0x13A3, 0xFF06 },
+ { 0x13B0, 0x0304 },
+ { 0x13B1, 0xF8FF },
+ { 0x13B2, 0x04F3 },
+ { 0x13B3, 0xFF00 },
+ { 0x412, 0x0005 },
+ { 0x41A, 0x0005 },
+ { 0x422, 0x0005 },
+};
+
+static const struct reg_sequence cs47l92_reva_32_patch[] = {
+ { 0x3030, 0x04A00C01 },
+ { 0x3032, 0x0225F501 },
+ { 0x3044, 0x04A00C00 },
+ { 0x3046, 0x0225FF01 },
+ { 0x3080, 0x04A00C01 },
+ { 0x3082, 0x0226F501 },
+ { 0x3094, 0x04A00C00 },
+ { 0x3096, 0x0226FF01 },
+ { 0x30D1, 0x04A10C01 },
+ { 0x30D2, 0x0227F501 },
+ { 0x30E4, 0x04A10C00 },
+ { 0x30E6, 0x0227FF01 },
+ { 0x3120, 0x04A10C01 },
+ { 0x3122, 0x0228F501 },
+ { 0x3134, 0x04A10C00 },
+ { 0x3136, 0x0228FF01 },
+ { 0x3170, 0x04A20C01 },
+ { 0x3172, 0x022B0101 },
+ { 0x3174, 0x0229F501 },
+ { 0x3184, 0x04A20C00 },
+ { 0x3186, 0x022B0100 },
+ { 0x3188, 0x0229FF01 },
+ { 0x31C0, 0x04A20C01 },
+ { 0x31C2, 0x022B0001 },
+ { 0x31C4, 0x022AF501 },
+ { 0x31D4, 0x04A20C00 },
+ { 0x31D6, 0x022B },
+ { 0x31D8, 0x022AFF01 },
+};
+
+int cs47l92_patch(struct madera *madera)
+{
+ int ret;
+
+ ret = regmap_register_patch(madera->regmap,
+ cs47l92_reva_16_p
Re: [PATCH] ocxl: do not use C++ style comments in uapi header
Hi Michael, On Wed, Jun 5, 2019 at 3:18 PM Andrew Donnellan wrote: > > On 4/6/19 10:12 pm, Masahiro Yamada wrote: > > On Tue, Jun 4, 2019 at 8:54 PM Frederic Barrat > > wrote: > >> > >> > >> > >> Le 04/06/2019 à 13:16, Masahiro Yamada a écrit : > >>> Linux kernel tolerates C++ style comments these days. Actually, the > >>> SPDX License tags for .c files start with //. > >>> > >>> On the other hand, uapi headers are written in more strict C, where > >>> the C++ comment style is forbidden. > >>> > >>> Signed-off-by: Masahiro Yamada > >>> --- > >> > >> Thanks! > >> Acked-by: Frederic Barrat > >> > > > > Please hold on this patch until > > we get consensus about the C++ comment style. > > > > Discussion just started here: > > https://lore.kernel.org/patchwork/patch/1083801/ > > If you choose to proceed with this patch: > > Acked-by: Andrew Donnellan After some discussion, the other one was applied to the media subsystem. Please pick up this one with Frederic and Andrew's Ack. Thanks. -- Best Regards Masahiro Yamada
Re: [PATCH 02/13] bus_find_device: Unify the match callback with class_find_device
On 05/06/2019 16:13, Suzuki K Poulose wrote: There is an arbitrary difference between the prototypes of bus_find_device() and class_find_device() preventing their callers from passing the same pair of data and match() arguments to both of them, which is the const qualifier used in the prototype of class_find_device(). If that qualifier is also used in the bus_find_device() prototype, it will be possible to pass the same match() callback function to both bus_find_device() and class_find_device(), which will allow some optimizations to be made in order to avoid code duplication going forward. Also with that, constify the "data" parameter as it is passed as a const to the match function. For this reason, change the prototype of bus_find_device() to match the prototype of class_find_device() and adjust its callers to use the const qualifier in accordance with the new prototype of it. Cc: Alexander Shishkin Cc: Andrew Lunn Cc: Andreas Noever Cc: Arnd Bergmann Cc: Bjorn Helgaas Cc: Corey Minyard Cc: Christian Borntraeger Cc: David Kershner Cc: "David S. Miller" Cc: David Airlie Cc: Felipe Balbi Cc: Frank Rowand Cc: Grygorii Strashko Cc: Harald Freudenberger Cc: Hartmut Knaack Cc: Heiko Stuebner Cc: Jason Gunthorpe Cc: Jonathan Cameron Cc: Jonathan Cameron Cc: "James E.J. Bottomley" Cc: Len Brown Cc: Mark Brown Cc: Michael Ellerman Cc: Michael Jamet Cc: "Martin K. Petersen" Cc: Peter Oberparleiter Cc: Rob Herring Cc: Sebastian Ott Cc: Srinivas Kandagatla Cc: Yehezkel Bernat Cc: Wolfram Sang Cc:raf...@kernel.org Cc: Greg Kroah-Hartman Signed-off-by: Suzuki K Poulose --- arch/powerpc/platforms/pseries/ibmebus.c | 4 ++-- drivers/acpi/acpi_lpss.c | 4 ++-- drivers/acpi/sleep.c | 2 +- drivers/acpi/utils.c | 4 ++-- drivers/base/bus.c | 6 +++--- drivers/base/devcon.c | 2 +- drivers/char/ipmi/ipmi_si_platform.c | 2 +- drivers/firmware/efi/dev-path-parser.c | 4 ++-- drivers/gpu/drm/drm_mipi_dsi.c | 2 +- drivers/hwtracing/coresight/coresight.c| 6 +++--- drivers/hwtracing/coresight/of_coresight.c | 2 +- drivers/hwtracing/intel_th/core.c | 5 ++--- drivers/i2c/i2c-core-acpi.c| 4 ++-- drivers/i2c/i2c-core-of.c | 4 ++-- drivers/iio/inkern.c | 2 +- drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 2 +- drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 2 +- drivers/net/ethernet/ti/cpsw-phy-sel.c | 4 ++-- drivers/net/ethernet/ti/davinci_emac.c | 2 +- drivers/net/ethernet/toshiba/tc35815.c | 4 ++-- drivers/nvmem/core.c | 2 +- For NVMEM changes, Acked-by: Srinivas Kandagatla --srini
Re: [PATCH v4 2/2] arm64: dts: qcom: Add Lenovo Miix 630
On Thu, 06 Jun 2019, Marc Gonzalez wrote: > On 06/06/2019 10:13, Lee Jones wrote: > > > On Thu, 06 Jun 2019, Bjorn Andersson wrote: > > > >> On Wed 05 Jun 22:50 PDT 2019, Lee Jones wrote: > >> > >>> On Tue, 23 Apr 2019, Jeffrey Hugo wrote: > >>> > This adds the initial DT for the Lenovo Miix 630 laptop. Supported > functionality includes USB (host), microSD-card, keyboard, and trackpad. > > Signed-off-by: Jeffrey Hugo > --- > arch/arm64/boot/dts/qcom/Makefile | 1 + > .../boot/dts/qcom/msm8998-clamshell.dtsi | 278 ++ > .../boot/dts/qcom/msm8998-lenovo-miix-630.dts | 30 ++ > >>> > >>> What's happening with this patch? > >>> > >> > >> The thermal-zones are wrong, but I'm okay with an incremental patch for > >> that... > > > > I guess it would take you about 10 seconds to whip those out when > > merging? > > https://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git/commit/?h=for-next&id=ad480e0149cfc10defe76e88354b977360adb7a1 > > AFAIU, the fixup is to just drop the thermal-zones section altogether. Yes, exactly. A 10 second job. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [tip:locking/core] Documentation/atomic_t.txt: Clarify pure non-rmw usage
On Thu, Jun 06, 2019 at 10:44:21AM +0200, Andrea Parri wrote: > On Mon, Jun 03, 2019 at 06:46:54AM -0700, tip-bot for Peter Zijlstra wrote: > > Commit-ID: fff9b6c7d26943a8eb32b58364b7ec6b9369746a > > Gitweb: > > https://git.kernel.org/tip/fff9b6c7d26943a8eb32b58364b7ec6b9369746a > > Author: Peter Zijlstra > > AuthorDate: Fri, 24 May 2019 13:52:31 +0200 > > Committer: Ingo Molnar > > CommitDate: Mon, 3 Jun 2019 12:32:57 +0200 > > > > Documentation/atomic_t.txt: Clarify pure non-rmw usage > > > > Clarify that pure non-RMW usage of atomic_t is pointless, there is > > nothing 'magical' about atomic_set() / atomic_read(). > > > > This is something that seems to confuse people, because I happen upon it > > semi-regularly. > > > > Signed-off-by: Peter Zijlstra (Intel) > > Reviewed-by: Greg Kroah-Hartman > > Acked-by: Will Deacon > > Cc: Linus Torvalds > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Link: > > https://lkml.kernel.org/r/20190524115231.gn2...@hirez.programming.kicks-ass.net > > Signed-off-by: Ingo Molnar > > I'd appreciate if you could Cc: me in future changes to this doc. > (as currently suggested by get_maintainer.pl). > > This is particularly annoying when you spend time to review such > changes: > > https://lkml.kernel.org/r/20190528111558.GA9106@andrea Sure, I hadn't realized the LKMM entry had appropriated this file, I considered it part of the ATOMIC entry there.
Re: [PATCH] RISC-V: Break load reservations during switch_to
On Wed, Jun 05, 2019 at 04:17:35PM -0700, Palmer Dabbelt wrote: > REG_S ra, TASK_THREAD_RA_RA(a3) > + /* > + * The Linux ABI allows programs to depend on load reservations being > + * broken on context switches, but the ISA doesn't require that the > + * hardware ever breaks a load reservation. The only way to break a > + * load reservation is with a store conditional, so we emit one here. > + * Since nothing ever takes a load reservation on TASK_THREAD_RA_RA we > + * know this will always fail, but just to be on the safe side this > + * writes the same value that was unconditionally written by the > + * previous instruction. > + */ > +#if (TASK_THREAD_RA_RA != 0) I don't think this check works as intended. TASK_THREAD_RA_RA is a parameterized macro, thus the above would never evaluate to 0. The error message also is rather odd while we're at it. > +#if (__riscv_xlen == 64) > + sc.d x0, ra, 0(a3) > +#else > + sc.w x0, ra, 0(a3) > +#endif I'd rather add an macro ala REG_S to asm.h and distinguish between the xlen variants there: #define REG_SC __REG_SEL(sc.d, sc.w)
[PATCH 1/1] ARM: dts: imx6ull-colibri: enable UHS-I for USDHC1
From: Igor Opaniuk
Allows to use the SD interface at a higher speed mode if the card
supports it. For this the signaling voltage is switched from 3.3V to
1.8V under the usdhc1's drivers control.
Signed-off-by: Igor Opaniuk
---
arch/arm/boot/dts/imx6ul.dtsi | 4
arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi | 11 +--
arch/arm/boot/dts/imx6ull-colibri.dtsi | 6 ++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index fc388b84bf22..91a0ced44e27 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -857,6 +857,8 @@
<&clks IMX6UL_CLK_USDHC1>,
<&clks IMX6UL_CLK_USDHC1>;
clock-names = "ipg", "ahb", "per";
+ fsl,tuning-step= <2>;
+ fsl,tuning-start-tap = <20>;
bus-width = <4>;
status = "disabled";
};
@@ -870,6 +872,8 @@
<&clks IMX6UL_CLK_USDHC2>;
clock-names = "ipg", "ahb", "per";
bus-width = <4>;
+ fsl,tuning-step= <2>;
+ fsl,tuning-start-tap = <20>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi
b/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi
index 006690ea98c0..7dc7770cf52c 100644
--- a/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx6ull-colibri-eval-v3.dtsi
@@ -145,13 +145,20 @@
};
&usdhc1 {
- pinctrl-names = "default";
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
pinctrl-0 = <&pinctrl_usdhc1 &pinctrl_snvs_usdhc1_cd>;
- no-1-8-v;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz &pinctrl_snvs_usdhc1_cd>;
+ pinctrl-2 = <&pinctrl_usdhc1_100mhz &pinctrl_snvs_usdhc1_cd>;
+ pinctrl-3 = <&pinctrl_usdhc1 &pinctrl_snvs_usdhc1_sleep_cd>;
cd-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
disable-wp;
wakeup-source;
keep-power-in-suspend;
vmmc-supply = <®_3v3>;
+ vqmmc-supply = <®_sd1_vmmc>;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6ull-colibri.dtsi
b/arch/arm/boot/dts/imx6ull-colibri.dtsi
index 9ad1da159768..d56728f03c35 100644
--- a/arch/arm/boot/dts/imx6ull-colibri.dtsi
+++ b/arch/arm/boot/dts/imx6ull-colibri.dtsi
@@ -545,6 +545,12 @@
>;
};
+ pinctrl_snvs_usdhc1_sleep_cd: snvs-usdhc1-cd-grp-slp {
+ fsl,pins = <
+ MX6ULL_PAD_SNVS_TAMPER0__GPIO5_IO00 0x0
+ >;
+ };
+
pinctrl_snvs_wifi_pdn: snvs-wifi-pdn-grp {
fsl,pins = <
MX6ULL_PAD_BOOT_MODE1__GPIO5_IO11 0x14
--
2.17.1
RE: [PATCH -mm 0/1] signal: simplify set_user_sigmask/restore_user_sigmask
From: Linus Torvalds > Sent: 05 June 2019 18:25 > On Wed, Jun 5, 2019 at 8:58 AM Oleg Nesterov wrote: > > > > To simplify the review, please see the code with this patch applied. > > I am using epoll_pwait() as an example because it looks very simple. > > I like it. > > However. > > I think I'd like it even more if we just said "we don't need > restore_saved_sigmask AT ALL". > > Which would be fairly easy to do with something like the attached... That would always call the signal handlers even when EINTR wasn't being returned (which I think ought to happen ...). The real purpose of restore_saved_sigmask() is to stop signal handlers that are enabled by the temporary mask being called. If a signal handler is called, I presume that the trampoline calls back into the kernel to get further handlers called and to finally restore the original signal mask? What happens if a signal handler calls something that would normally write to current->saved_sigmask? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: rcu_read_lock lost its compiler barrier
On Thu, Jun 06, 2019 at 02:14:38PM +0800, Herbert Xu wrote:
> On Wed, Jun 05, 2019 at 11:05:11PM -0700, Paul E. McKenney wrote:
> >
> > In case you were wondering, the reason that I was giving you such
> > a hard time was that from what I could see, you were pushing for no
> > {READ,WRITE}_ONCE() at all. ;-)
>
> Hmm, that's exactly what it should be in net/ipv4/inet_fragment.c.
> We don't need the READ_ONCE/WRITE_ONCE (or volatile marking) at
> all. Even if the compiler dices and slices the reads/writes of
> "a" into a thousand pieces, it should still work if the RCU
> primitives are worth their salt.
OK, so I take it that there is additional synchronization in there
somewhere that is not captured in your simplified example code?
Or is your point instead that given the initial value of "a" being
zero and the value stored to "a" being one, there is no way that
any possible load and store tearing (your slicing and dicing) could
possibly mess up the test of the value loaded from "a"?
> But I do concede that in the general RCU case you must have the
> READ_ONCE/WRITE_ONCE calls for rcu_dereference/rcu_assign_pointer.
OK, good that we are in agreement on this part, at least! ;-)
Thanx, Paul
[PATCH 2/2] clk: rockchip: convert pclk_wdt boilerplat to new SGRF_GATE macro
Convert the boilerplate code for manual addition of the watchdog clock
to the new SGRF_GATE macro for all affected socs.
Signed-off-by: Heiko Stuebner
---
drivers/clk/rockchip/clk-px30.c | 11 +++
drivers/clk/rockchip/clk-rk3288.c | 11 +++
drivers/clk/rockchip/clk-rk3368.c | 11 +++
drivers/clk/rockchip/clk-rk3399.c | 11 +++
4 files changed, 12 insertions(+), 32 deletions(-)
diff --git a/drivers/clk/rockchip/clk-px30.c b/drivers/clk/rockchip/clk-px30.c
index 68d23be18cbc..2e10b9f211eb 100644
--- a/drivers/clk/rockchip/clk-px30.c
+++ b/drivers/clk/rockchip/clk-px30.c
@@ -803,6 +803,9 @@ static struct rockchip_clk_branch px30_clk_branches[]
__initdata = {
GATE(ACLK_GIC, "aclk_gic", "aclk_bus_pre", CLK_IGNORE_UNUSED,
PX30_CLKGATE_CON(13), 12, GFLAGS),
GATE(ACLK_DCF, "aclk_dcf", "aclk_bus_pre", 0, PX30_CLKGATE_CON(13), 15,
GFLAGS),
+ /* aclk_dmac is controlled by sgrf_soc_con1[11]. */
+ SGRF_GATE(ACLK_DMAC, "aclk_dmac", "aclk_bus_pre"),
+
GATE(0, "hclk_bus_niu", "hclk_bus_pre", CLK_IGNORE_UNUSED,
PX30_CLKGATE_CON(13), 9, GFLAGS),
GATE(0, "hclk_rom", "hclk_bus_pre", CLK_IGNORE_UNUSED,
PX30_CLKGATE_CON(13), 14, GFLAGS),
GATE(HCLK_PDM, "hclk_pdm", "hclk_bus_pre", 0, PX30_CLKGATE_CON(14), 1,
GFLAGS),
@@ -981,14 +984,6 @@ static void __init px30_clk_init(struct device_node *np)
return;
}
- /* aclk_dmac is controlled by sgrf_soc_con1[11]. */
- clk = clk_register_fixed_factor(NULL, "aclk_dmac", "aclk_bus_pre", 0,
1, 1);
- if (IS_ERR(clk))
- pr_warn("%s: could not register clock aclk_dmac: %ld\n",
- __func__, PTR_ERR(clk));
- else
- rockchip_clk_add_lookup(ctx, clk, ACLK_DMAC);
-
rockchip_clk_register_plls(ctx, px30_pll_clks,
ARRAY_SIZE(px30_pll_clks),
PX30_GRF_SOC_STATUS0);
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 85907f31c63f..9e3dbc4a7632 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -776,6 +776,9 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
GATE(PCLK_GRF, "pclk_grf", "pclk_pd_alive", CLK_IGNORE_UNUSED,
RK3288_CLKGATE_CON(14), 11, GFLAGS),
GATE(0, "pclk_alive_niu", "pclk_pd_alive", 0, RK3288_CLKGATE_CON(14),
12, GFLAGS),
+ /* Watchdog pclk is controlled by RK3288_SGRF_SOC_CON0[1]. */
+ SGRF_GATE(PCLK_WDT, "pclk_wdt", "pclk_pd_alive"),
+
/* pclk_pd_pmu gates */
GATE(PCLK_PMU, "pclk_pmu", "pclk_pd_pmu", CLK_IGNORE_UNUSED,
RK3288_CLKGATE_CON(17), 0, GFLAGS),
GATE(0, "pclk_intmem1", "pclk_pd_pmu", CLK_IGNORE_UNUSED,
RK3288_CLKGATE_CON(17), 1, GFLAGS),
@@ -939,14 +942,6 @@ static void __init rk3288_clk_init(struct device_node *np)
return;
}
- /* Watchdog pclk is controlled by RK3288_SGRF_SOC_CON0[1]. */
- clk = clk_register_fixed_factor(NULL, "pclk_wdt", "pclk_pd_alive", 0,
1, 1);
- if (IS_ERR(clk))
- pr_warn("%s: could not register clock pclk_wdt: %ld\n",
- __func__, PTR_ERR(clk));
- else
- rockchip_clk_add_lookup(ctx, clk, PCLK_WDT);
-
rockchip_clk_register_plls(ctx, rk3288_pll_clks,
ARRAY_SIZE(rk3288_pll_clks),
RK3288_GRF_SOC_STATUS1);
diff --git a/drivers/clk/rockchip/clk-rk3368.c
b/drivers/clk/rockchip/clk-rk3368.c
index d239bbc2fc77..b70de6cacac4 100644
--- a/drivers/clk/rockchip/clk-rk3368.c
+++ b/drivers/clk/rockchip/clk-rk3368.c
@@ -820,6 +820,9 @@ static struct rockchip_clk_branch rk3368_clk_branches[]
__initdata = {
GATE(PCLK_GPIO2, "pclk_gpio2", "pclk_pd_alive", 0,
RK3368_CLKGATE_CON(22), 2, GFLAGS),
GATE(PCLK_GPIO1, "pclk_gpio1", "pclk_pd_alive", 0,
RK3368_CLKGATE_CON(22), 1, GFLAGS),
+ /* Watchdog pclk is controlled by sgrf_soc_con3[7]. */
+ SGRF_GATE(PCLK_WDT, "pclk_wdt", "pclk_pd_alive"),
+
/*
* pclk_vio gates
* pclk_vio comes from the exactly same source as hclk_vio
@@ -886,14 +889,6 @@ static void __init rk3368_clk_init(struct device_node *np)
return;
}
- /* Watchdog pclk is controlled by sgrf_soc_con3[7]. */
- clk = clk_register_fixed_factor(NULL, "pclk_wdt", "pclk_pd_alive", 0,
1, 1);
- if (IS_ERR(clk))
- pr_warn("%s: could not register clock pclk_wdt: %ld\n",
- __func__, PTR_ERR(clk));
- else
- rockchip_clk_add_lookup(ctx, clk, PCLK_WDT);
-
rockchip_clk_register_plls(ctx, rk3368_pll_clks,
ARRAY_SIZE(rk3368_pll_clks),
RK3368_GRF_SOC_STATUS0);
diff --git a/drivers/clk/rockchip/clk-rk3399.c
b/drivers/clk/rockchip/clk-rk3399.c
index 2322d712
Re: [PATCH v2] Add a document on rebasing and merging
On Tue, 04 Jun 2019, Jonathan Corbet wrote: > Every merge window seems to involve at least one episode where subsystem > maintainers don't manage their trees as Linus would like. Document the > expectations so that at least he has something to point people to. Good stuff. Some notes inline. BR, Jani. > > Acked-by: David Rientjes > Signed-off-by: Jonathan Corbet > --- > Changes in v2: > - Try to clear up "reparenting" v. "history modification" > - Make the "don't rebase public branches" rule into more of a guideline > - Fix typos noted by Geert > - Rename the document to better reflect its contents > > Documentation/maintainer/index.rst| 1 + > .../maintainer/rebasing-and-merging.rst | 216 ++ > 2 files changed, 217 insertions(+) > create mode 100644 Documentation/maintainer/rebasing-and-merging.rst > > diff --git a/Documentation/maintainer/index.rst > b/Documentation/maintainer/index.rst index 2a14916930cb..56e2c09dfa39 > 100644 --- a/Documentation/maintainer/index.rst > +++ b/Documentation/maintainer/index.rst > @@ -10,5 +10,6 @@ additions to this manual. > :maxdepth: 2 > > configure-git > + rebasing-and-merging > pull-requests > > diff --git a/Documentation/maintainer/rebasing-and-merging.rst > b/Documentation/maintainer/rebasing-and-merging.rst new file mode 100644 > index ..2987bd45dfb2 > --- /dev/null > +++ b/Documentation/maintainer/rebasing-and-merging.rst > @@ -0,0 +1,216 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > + > +Rebasing and merging > + > + > +Maintaining a subsystem, as a general rule, requires a familiarity with > the +Git source-code management system. Git is a powerful tool with a lot > of +features; as is often the case with such tools, there are right and > wrong +ways to use those features. This document looks in particular at > the use +of rebasing and merging. Maintainers often get in trouble when > they use +those tools incorrectly, but avoiding problems is not actually > all that +hard. > + > +One thing to be aware of in general is that, unlike many other projects, > +the kernel community is not scared by seeing merge commits in its > +development history. Indeed, given the scale of the project, avoiding > +merges would be nearly impossible. Some problems encountered by > +maintainers result from a desire to avoid merges, while others come from > +merging a little too often. > + > +Rebasing > + > + > +"Rebasing" is the process of changing the history of a series of commits > +within a repository. There are two different types of operations that are > +referred to as rebasing since both are done with the ``git rebase`` > +command, but there are significant differences between them: > + > + - Rebasing can change the parent (starting) commit upon which a series of > + patches is built. For example, a rebase operation could take a patch > + set built on the previous kernel release and base it, instead, on the > + current release. We'll call this operation "reparenting" in the > + discussion below. > + > + - Changing the history of a set of patches by fixing (or deleting) broken > + commits, adding patches, adding tags to commit changelogs, or changing > + the order in which commits are applied. In the following text, this > + type of operation will be referred to as "history modification" > + > +The term "rebasing" will be used to refer to both of the above operations. > +Used properly, rebasing can yield a cleaner and clearer development > +history; used improperly, it can obscure that history and introduce bugs. > + > +There are a few rules of thumb that can help developers to avoid the worst > +perils of rebasing: > + > + - History that has been exposed to the world beyond your private system > + should usually not be changed. Others may have pulled a copy of your > + tree and built on it; modifying your tree will create pain for them. > If > + work is in need of rebasing, that is usually a sign that it is not yet > + ready to be committed to a public repository. > + > + That said, there are always exceptions. Some trees (linux-next being > + a significant example) are frequently rebased by their nature, and > + developers know not to base work on them. Developers will sometimes > + expose an unstable branch for others to test with or for automated > + testing services. If you do expose a branch that may be unstable in > + this way, be sure that prospective users know not to base work on it. > + > + - Do not rebase a branch that contains history created by others. If you > + have pulled changes from another developer's repository, you are now a > + custodian of their history. You should not change it. With few > + exceptions, for example, a broken commit in a tree like this should be > + explicitly reverted rather than disappeared via history modification. > + > + - Do not reparent a tree wi
[PATCH 1/2] clk: rockchip: add a type from SGRF-controlled gate clocks
Some clk gates on Rockchip SoCs are part of the SGRF (secure general
register files) and thus only controllable from secure mode, with the
most prominent example being the watchdog.
In most cases we still want to define this as a real clock though,
to have complete clock tree and not reference the generic base-clock
from the devicetree.
So far we've just defined this as factor-1-1 clocks in the clock init,
so define a special clock-type for it so that this definition can be
part of the general tree-definition and save some boilerplate code.
Signed-off-by: Heiko Stuebner
---
drivers/clk/rockchip/clk.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
index 1b5270755431..2a911923cf81 100644
--- a/drivers/clk/rockchip/clk.h
+++ b/drivers/clk/rockchip/clk.h
@@ -820,6 +820,10 @@ struct rockchip_clk_branch {
.gate_offset= -1, \
}
+/* SGRF clocks are only accessible from secure mode, so not controllable */
+#define SGRF_GATE(_id, cname, pname) \
+ FACTOR(_id, cname, pname, 0, 1, 1)
+
struct rockchip_clk_provider *rockchip_clk_init(struct device_node *np,
void __iomem *base, unsigned long nr_clks);
void rockchip_clk_of_add_provider(struct device_node *np,
--
2.20.1
Re: [tip:locking/core] Documentation/atomic_t.txt: Clarify pure non-rmw usage
On Thu, Jun 06, 2019 at 11:04:39AM +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2019 at 10:44:21AM +0200, Andrea Parri wrote:
> > On Mon, Jun 03, 2019 at 06:46:54AM -0700, tip-bot for Peter Zijlstra wrote:
> > > Commit-ID: fff9b6c7d26943a8eb32b58364b7ec6b9369746a
> > > Gitweb:
> > > https://git.kernel.org/tip/fff9b6c7d26943a8eb32b58364b7ec6b9369746a
> > > Author: Peter Zijlstra
> > > AuthorDate: Fri, 24 May 2019 13:52:31 +0200
> > > Committer: Ingo Molnar
> > > CommitDate: Mon, 3 Jun 2019 12:32:57 +0200
> > >
> > > Documentation/atomic_t.txt: Clarify pure non-rmw usage
> > >
> > > Clarify that pure non-RMW usage of atomic_t is pointless, there is
> > > nothing 'magical' about atomic_set() / atomic_read().
> > >
> > > This is something that seems to confuse people, because I happen upon it
> > > semi-regularly.
> > >
> > > Signed-off-by: Peter Zijlstra (Intel)
> > > Reviewed-by: Greg Kroah-Hartman
> > > Acked-by: Will Deacon
> > > Cc: Linus Torvalds
> > > Cc: Peter Zijlstra
> > > Cc: Thomas Gleixner
> > > Link:
> > > https://lkml.kernel.org/r/20190524115231.gn2...@hirez.programming.kicks-ass.net
> > > Signed-off-by: Ingo Molnar
> >
> > I'd appreciate if you could Cc: me in future changes to this doc.
> > (as currently suggested by get_maintainer.pl).
> >
> > This is particularly annoying when you spend time to review such
> > changes:
> >
> > https://lkml.kernel.org/r/20190528111558.GA9106@andrea
>
> Sure, I hadn't realized the LKMM entry had appropriated this file, I
> considered it part of the ATOMIC entry there.
Thanks. Well, that was not a 'secret', c.f.,
70b83069f70d ("tools/memory-model: Add informal LKMM documentation to
MAINTAINERS")
Andrea
Re: [PATCH v8 02/13] clk: samsung: add new clocks for DMC for Exynos5422 SoC
Hi Krzysztof,
On 6/6/19 10:34 AM, Krzysztof Kozlowski wrote:
> On Wed, 5 Jun 2019 at 18:54, Lukasz Luba wrote:
>>
>> This patch provides support for clocks needed for Dynamic Memory Controller
>> in Exynos5422 SoC. It adds CDREX base register addresses, new DIV, MUX and
>> GATE entries.
>>
>> Acked-by: Chanwoo Choi
>> Signed-off-by: Lukasz Luba
>> ---
>> drivers/clk/samsung/clk-exynos5420.c | 57 ++--
>> 1 file changed, 53 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>> b/drivers/clk/samsung/clk-exynos5420.c
>> index 34cce3c5898f..eecbfcc6b3cf 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -134,6 +134,8 @@
>> #define SRC_CDREX 0x20200
>> #define DIV_CDREX0 0x20500
>> #define DIV_CDREX1 0x20504
>> +#define GATE_BUS_CDREX00x20700
>> +#define GATE_BUS_CDREX10x20704
>> #define KPLL_LOCK 0x28000
>> #define KPLL_CON0 0x28100
>> #define SRC_KFC0x28200
>> @@ -248,6 +250,8 @@ static const unsigned long exynos5x_clk_regs[]
>> __initconst = {
>> DIV_CDREX1,
>> SRC_KFC,
>> DIV_KFC0,
>> + GATE_BUS_CDREX0,
>> + GATE_BUS_CDREX1,
>> };
>>
>> static const unsigned long exynos5800_clk_regs[] __initconst = {
>> @@ -425,6 +429,9 @@ PNAME(mout_group13_5800_p) = { "dout_osc_div",
>> "mout_sw_aclkfl1_550_cam" };
>> PNAME(mout_group14_5800_p) = { "dout_aclk550_cam", "dout_sclk_sw" };
>> PNAME(mout_group15_5800_p) = { "dout_osc_div", "mout_sw_aclk550_cam" };
>> PNAME(mout_group16_5800_p) = { "dout_osc_div", "mout_mau_epll_clk" };
>> +PNAME(mout_mx_mspll_ccore_phy_p) = { "sclk_bpll", "mout_sclk_dpll",
>> + "mout_sclk_mpll", "ff_dout_spll2",
>> + "mout_sclk_spll", "mout_sclk_epll"};
>>
>> /* fixed rate clocks generated outside the soc */
>> static struct samsung_fixed_rate_clock
>> @@ -450,7 +457,7 @@ static const struct samsung_fixed_factor_clock
>> static const struct samsung_fixed_factor_clock
>> exynos5800_fixed_factor_clks[] __initconst = {
>> FFACTOR(0, "ff_dout_epll2", "mout_sclk_epll", 1, 2, 0),
>> - FFACTOR(0, "ff_dout_spll2", "mout_sclk_spll", 1, 2, 0),
>> + FFACTOR(CLK_FF_DOUT_SPLL2, "ff_dout_spll2", "mout_sclk_spll", 1, 2,
>> 0),
>> };
>>
>> static const struct samsung_mux_clock exynos5800_mux_clks[] __initconst = {
>> @@ -472,11 +479,14 @@ static const struct samsung_mux_clock
>> exynos5800_mux_clks[] __initconst = {
>> MUX(0, "mout_aclk300_disp1", mout_group5_5800_p, SRC_TOP2, 24, 2),
>> MUX(0, "mout_aclk300_gscl", mout_group5_5800_p, SRC_TOP2, 28, 2),
>>
>> + MUX(CLK_MOUT_MX_MSPLL_CCORE_PHY, "mout_mx_mspll_ccore_phy",
>> + mout_mx_mspll_ccore_phy_p, SRC_TOP7, 0, 3),
>> +
>> MUX(CLK_MOUT_MX_MSPLL_CCORE, "mout_mx_mspll_ccore",
>> - mout_mx_mspll_ccore_p, SRC_TOP7, 16, 2),
>> + mout_mx_mspll_ccore_p, SRC_TOP7, 16, 3),
>> MUX_F(CLK_MOUT_MAU_EPLL, "mout_mau_epll_clk",
>> mout_mau_epll_clk_5800_p,
>> SRC_TOP7, 20, 2, CLK_SET_RATE_PARENT, 0),
>> - MUX(0, "sclk_bpll", mout_bpll_p, SRC_TOP7, 24, 1),
>> + MUX(CLK_SCLK_BPLL, "sclk_bpll", mout_bpll_p, SRC_TOP7, 24, 1),
>> MUX(0, "mout_epll2", mout_epll2_5800_p, SRC_TOP7, 28, 1),
>>
>> MUX(0, "mout_aclk550_cam", mout_group3_5800_p, SRC_TOP8, 16, 3),
>> @@ -648,7 +658,7 @@ static const struct samsung_mux_clock
>> exynos5x_mux_clks[] __initconst = {
>>
>> MUX(0, "mout_sclk_mpll", mout_mpll_p, SRC_TOP6, 0, 1),
>> MUX(CLK_MOUT_VPLL, "mout_sclk_vpll", mout_vpll_p, SRC_TOP6, 4, 1),
>> - MUX(0, "mout_sclk_spll", mout_spll_p, SRC_TOP6, 8, 1),
>> + MUX(CLK_MOUT_SCLK_SPLL, "mout_sclk_spll", mout_spll_p, SRC_TOP6, 8,
>> 1),
>> MUX(0, "mout_sclk_ipll", mout_ipll_p, SRC_TOP6, 12, 1),
>> MUX(0, "mout_sclk_rpll", mout_rpll_p, SRC_TOP6, 16, 1),
>> MUX_F(CLK_MOUT_EPLL, "mout_sclk_epll", mout_epll_p, SRC_TOP6, 20, 1,
>> @@ -806,8 +816,21 @@ static const struct samsung_div_clock
>> exynos5x_div_clks[] __initconst = {
>> "mout_aclk400_disp1", DIV_TOP2, 4, 3),
>>
>> /* CDREX Block */
>> + /*
>> +* The three clocks below are controlled using the same register and
>> +* bits. They are put into one because there is a need of
>> +* synchronization between the BUS and DREXs (two external memory
>> +* interfaces).
>> +* They are put here to show this HW assumption and for clock
>> +* information summary completeness.
>> +*/
>> DIV(CLK_DOUT_PCLK_CDREX, "dout_pclk_cdrex", "dout_aclk_cdrex1",
>> DIV_CDREX0, 28, 3),
>> + D
Re: [PATCH 01/13] acpi: utils: Cleanup acpi_dev_match_cb
On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose wrote:
>
> acpi_dev_match_cb match function modifies the "data" argument
> to pass on a result which could be easily deduced from the result
> of the bus_find_device() call at the caller site. Clean this
> up in preparation to convert the "match" argument for bus_find_device
> to accept a "const" data pointer, similar to class_find_device. This
> would allow consolidating the match routines for these two APIs.
This changelog can be improved IMO.
In fact, the final goal here is to pass (const void *) as the second
argument to acpi_dev_match_cb() (which you could do right away in this
patch if I'm not mistaken) which is because you want to modify the
prototype of bus_find_device().
So why don't you write something like this in the changelog:
"The prototype of bus_find_device() will be unified with that of
class_find_device() subsequently, but for this purpose the callback
functions passed to it need to take (const void *) as the second
argument. Consequently, they cannot modify the memory pointed to by
that argument which currently is not the case for acpi_dev_match_cb().
However, acpi_dev_match_cb() really need not modify the "match" object
passed to it, because acpi_dev_get_first_match_dev() which uses it via
bus_find_device() can easily convert the result of bus_find_device()
into the pointer to return.
For this reason, update acpi_dev_match_cb() to avoid the redundant
memory updates and change the type of its second argument to (const
void *)."
>
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/acpi/utils.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> index 7def63a..1391b63 100644
> --- a/drivers/acpi/utils.c
> +++ b/drivers/acpi/utils.c
> @@ -725,8 +725,6 @@ bool acpi_dev_found(const char *hid)
> EXPORT_SYMBOL(acpi_dev_found);
>
> struct acpi_dev_match_info {
> - const char *dev_name;
> - struct acpi_device *adev;
> struct acpi_device_id hid[2];
> const char *uid;
> s64 hrv;
> @@ -746,9 +744,6 @@ static int acpi_dev_match_cb(struct device *dev, void
> *data)
And why not to change the type of the second arg to "const void *data" here?
> strcmp(adev->pnp.unique_id, match->uid)))
> return 0;
>
> - match->dev_name = acpi_dev_name(adev);
> - match->adev = adev;
> -
> if (match->hrv == -1)
> return 1;
>
> @@ -818,7 +813,7 @@ acpi_dev_get_first_match_dev(const char *hid, const char
> *uid, s64 hrv)
> match.hrv = hrv;
>
> dev = bus_find_device(&acpi_bus_type, NULL, &match,
> acpi_dev_match_cb);
> - return dev ? match.adev : NULL;
> + return dev ? to_acpi_device(dev) : NULL;
> }
> EXPORT_SYMBOL(acpi_dev_get_first_match_dev);
>
> --
Re: [PATCH v2] ARM: configs: Remove useless UEVENT_HELPER_PATH
On 04/06/2019 at 10:14, Krzysztof Kozlowski wrote:
> Remove the CONFIG_UEVENT_HELPER_PATH because:
> 1. It is disabled since commit 1be01d4a5714 ("driver: base: Disable
> CONFIG_UEVENT_HELPER by default") as its dependency (UEVENT_HELPER) was
> made default to 'n',
> 2. It is not recommended (help message: "This should not be used today
> [...] creates a high system load") and was kept only for ancient
> userland,
> 3. Certain userland specifically requests it to be disabled (systemd
> README: "Legacy hotplug slows down the system and confuses udev").
>
> Signed-off-by: Krzysztof Kozlowski
> Acked-by: Geert Uytterhoeven
>
> ---
>
> Changes since v2:
> 1. Remove unrelated files.
> 2. Add Geert's ack.
> ---
> arch/arm/configs/acs5k_defconfig | 1 -
> arch/arm/configs/acs5k_tiny_defconfig | 1 -
> arch/arm/configs/am200epdkit_defconfig| 1 -
> arch/arm/configs/aspeed_g4_defconfig | 1 -
> arch/arm/configs/aspeed_g5_defconfig | 1 -
> arch/arm/configs/at91_dt_defconfig| 1 -
[..]
> arch/arm/configs/sama5_defconfig | 1 -
for at91 (at91_dt_defconfig & sama5_defconfig):
Acked-by: Nicolas Ferre
> arch/arm/configs/socfpga_defconfig| 1 -
> arch/arm/configs/spear13xx_defconfig | 1 -
> arch/arm/configs/spear3xx_defconfig | 1 -
> arch/arm/configs/spear6xx_defconfig | 1 -
> arch/arm/configs/spitz_defconfig | 1 -
> arch/arm/configs/tango4_defconfig | 1 -
> arch/arm/configs/tct_hammer_defconfig | 1 -
> arch/arm/configs/u300_defconfig | 1 -
> arch/arm/configs/u8500_defconfig | 1 -
> arch/arm/configs/vexpress_defconfig | 1 -
> arch/arm/configs/viper_defconfig | 1 -
> arch/arm/configs/xcep_defconfig | 1 -
> arch/arm/configs/zeus_defconfig | 1 -
> arch/arm/configs/zx_defconfig | 1 -
> 69 files changed, 69 deletions(-)
[..]
--
Nicolas Ferre
Re: [PATCH 07/13] drivers: Add generic match helper by ACPI_COMPANION device
On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose wrote:
>
> Add a generic helper to match a device by the acpi device.
"by its ACPI companion device object", please.
Also, it would be good to combine this patch with the patch(es) that
cause device_match_acpi_dev() to be actually used.
Helpers without any users are arguably not useful.
>
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: Mark Brown
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/base/core.c| 6 ++
> include/linux/device.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index b827ca1..597095b 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -3346,3 +3346,9 @@ int device_match_devt(struct device *dev, const void
> *pdevt)
> return dev->devt == *(dev_t *)pdevt;
> }
> EXPORT_SYMBOL_GPL(device_match_devt);
> +
> +int device_match_acpi_dev(struct device *dev, const void *adev)
> +{
> + return ACPI_COMPANION(dev) == adev;
> +}
> +EXPORT_SYMBOL(device_match_acpi_dev);
> diff --git a/include/linux/device.h b/include/linux/device.h
> index f315692..a03b50d 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -166,6 +166,7 @@ void subsys_dev_iter_exit(struct subsys_dev_iter *iter);
> int device_match_of_node(struct device *dev, const void *np);
> int device_match_fwnode(struct device *dev, const void *fwnode);
> int device_match_devt(struct device *dev, const void *pdevt);
> +int device_match_acpi_dev(struct device *dev, const void *adev);
>
> int bus_for_each_dev(struct bus_type *bus, struct device *start, void *data,
> int (*fn)(struct device *dev, void *data));
> --
> 2.7.4
>
[PATCH -next] phy: tegra: xusb: Remove set but not used variable 'priv'
Fixes gcc '-Wunused-but-set-variable' warning: drivers/phy/tegra/xusb-tegra210.c: In function 'tegra210_hsic_phy_power_on': drivers/phy/tegra/xusb-tegra210.c:1236:31: warning: variable 'priv' set but not used [-Wunused-but-set-variable] It's never used, so can be removed Signed-off-by: YueHaibing --- drivers/phy/tegra/xusb-tegra210.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/phy/tegra/xusb-tegra210.c b/drivers/phy/tegra/xusb-tegra210.c index eb754baa8d71..4076b22c4087 100644 --- a/drivers/phy/tegra/xusb-tegra210.c +++ b/drivers/phy/tegra/xusb-tegra210.c @@ -1233,13 +1233,10 @@ static int tegra210_hsic_phy_power_on(struct phy *phy) struct tegra_xusb_hsic_lane *hsic = to_hsic_lane(lane); struct tegra_xusb_hsic_pad *pad = to_hsic_pad(lane->pad); struct tegra_xusb_padctl *padctl = lane->pad->padctl; - struct tegra210_xusb_padctl *priv; unsigned int index = lane->index; u32 value; int err; - priv = to_tegra210_xusb_padctl(padctl); - err = regulator_enable(pad->supply); if (err) return err;
Re: [PATCH 01/13] acpi: utils: Cleanup acpi_dev_match_cb
Hi Rafael,
On 06/06/2019 10:14, Rafael J. Wysocki wrote:
On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose wrote:
acpi_dev_match_cb match function modifies the "data" argument
to pass on a result which could be easily deduced from the result
of the bus_find_device() call at the caller site. Clean this
up in preparation to convert the "match" argument for bus_find_device
to accept a "const" data pointer, similar to class_find_device. This
would allow consolidating the match routines for these two APIs.
This changelog can be improved IMO.
I agree. Will update it.
In fact, the final goal here is to pass (const void *) as the second
argument to acpi_dev_match_cb() (which you could do right away in this
patch if I'm not mistaken) which is because you want to modify the
prototype of bus_find_device().
So why don't you write something like this in the changelog:
"The prototype of bus_find_device() will be unified with that of
class_find_device() subsequently, but for this purpose the callback
functions passed to it need to take (const void *) as the second
argument. Consequently, they cannot modify the memory pointed to by
that argument which currently is not the case for acpi_dev_match_cb().
However, acpi_dev_match_cb() really need not modify the "match" object
passed to it, because acpi_dev_get_first_match_dev() which uses it via
bus_find_device() can easily convert the result of bus_find_device()
into the pointer to return.
Sure.
For this reason, update acpi_dev_match_cb() to avoid the redundant
memory updates and change the type of its second argument to (const
void *)."
We can't do that quite yet, until we unify the prototype of the
bus_find_device().
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: linux-a...@vger.kernel.org
Signed-off-by: Suzuki K Poulose
---
drivers/acpi/utils.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 7def63a..1391b63 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -725,8 +725,6 @@ bool acpi_dev_found(const char *hid)
EXPORT_SYMBOL(acpi_dev_found);
struct acpi_dev_match_info {
- const char *dev_name;
- struct acpi_device *adev;
struct acpi_device_id hid[2];
const char *uid;
s64 hrv;
@@ -746,9 +744,6 @@ static int acpi_dev_match_cb(struct device *dev, void *data)
And why not to change the type of the second arg to "const void *data" here?
Because, that would conflict with what bus_find_device() expects now. We make
the change only later. Since this change was a bit more intrusive than simply
changing the type of the parameter, I kept it as a preparatory patch.
Thanks for the review !
Suzuki
Re: general protection fault in rb_erase (2)
syzbot has bisected this bug to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend
Date: Sat Jun 30 13:17:47 2018 +
bpf: sockhash fix omitted bucket lock in sock_close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1644ea92a0
start commit: 156c0591 Merge tag 'linux-kselftest-5.2-rc4' of git://git...
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=1544ea92a0
console output: https://syzkaller.appspot.com/x/log.txt?x=1144ea92a0
kernel config: https://syzkaller.appspot.com/x/.config?x=60564cb52ab29d5b
dashboard link: https://syzkaller.appspot.com/bug?extid=e8c40862180d8949d624
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11f031fea0
Reported-by: syzbot+e8c40862180d8949d...@syzkaller.appspotmail.com
Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH v2 2/2] PCI: Create device link for NVIDIA GPU
NVIDIA Turing GPUs include hardware support for USB Type-C and
VirtualLink. It helps in delivering the power, display, and data
required to power VR headsets through a single USB Type-C connector.
The Turing GPU is a multi-function PCI device. It has the following
four functions:
- VGA display controller (Function 0)
- Audio controller (Function 1)
- USB xHCI Host controller (Function 2)
- USB Type-C USCI controller (Function 3)
The function 0 is tightly coupled with other functions in the
hardware. When function 0 goes in D3 state, then it will do
power gating for most of the hardware blocks. Some of these
hardware blocks are being used by other functions which
leads to functional failure. So if any of these functions (1/2/3)
are in D0 state, then function 0 should also be in D0 state.
'commit 07f4f97d7b4b ("vga_switcheroo: Use device link for
HDA controller")' creates the device link from function 1 to
function 0. A similar kind of device link needs to be created
between function 0 and functions 2 and 3 for NVIDIA Turing GPU.
This patch does the same and creates the required device links. It
will make function 0 to be D0 state if any other function is in D0
state.
Signed-off-by: Abhishek Sahu
---
* Changes from v1:
1. Minor changes in commit log
2. used pci_create_device_link() helper function
drivers/pci/quirks.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 379cd7fbcb12..b9182c4e5e42 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4966,6 +4966,32 @@ DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMD,
PCI_ANY_ID,
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
PCI_CLASS_MULTIMEDIA_HD_AUDIO, 8, quirk_gpu_hda);
+/*
+ * Create device link for NVIDIA GPU with integrated USB xHCI Host
+ * controller to VGA.
+ */
+static void quirk_gpu_usb(struct pci_dev *usb)
+{
+ pci_create_device_link(usb, 2, 0, PCI_BASE_CLASS_DISPLAY, 16);
+}
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
+ PCI_CLASS_SERIAL_USB, 8, quirk_gpu_usb);
+
+/*
+ * Create device link for NVIDIA GPU with integrated Type-C UCSI controller
+ * to VGA. Currently there is no class code defined for UCSI device over PCI
+ * so using UNKNOWN class for now and it will be updated when UCSI
+ * over PCI gets a class code.
+ */
+#define PCI_CLASS_SERIAL_UNKNOWN 0x0c80
+static void quirk_gpu_usb_typec_ucsi(struct pci_dev *ucsi)
+{
+ pci_create_device_link(ucsi, 3, 0, PCI_BASE_CLASS_DISPLAY, 16);
+}
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
+ PCI_CLASS_SERIAL_UNKNOWN, 8,
+ quirk_gpu_usb_typec_ucsi);
+
/*
* Some IDT switches incorrectly flag an ACS Source Validation error on
* completions for config read requests even though PCIe r4.0, sec
--
2.17.1
[PATCH v2 1/2] PCI: Code reorganization for creating device link
In Multi-function PCI device, one function (consumer) can have
hardware functional dependencies on another function (supplier).
Whenever the consumer is active and in D0 state, the supplier should
also be in D0 state. Currently, the device link is being created from
HDA function to VGA function for GPU's. This patch does minor code
reorganization. It introduces a helper function which creates device
link from consumer pci device to supplier pci device and uses this
helper function for creating device link from HDA to VGA. This helper
function can be used in future for creating device link from one
function to another function.
Signed-off-by: Abhishek Sahu
---
* Changes from v1:
1. Make the helper function generic which takes supplier class,
class shift and function number also.
2. Minor changes in commit log
drivers/pci/quirks.c | 53 +++-
1 file changed, 33 insertions(+), 20 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index a077f67fe1da..379cd7fbcb12 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4916,35 +4916,48 @@ static void quirk_fsl_no_msi(struct pci_dev *pdev)
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, quirk_fsl_no_msi);
/*
- * GPUs with integrated HDA controller for streaming audio to attached displays
- * need a device link from the HDA controller (consumer) to the GPU (supplier)
- * so that the GPU is powered up whenever the HDA controller is accessed.
- * The GPU and HDA controller are functions 0 and 1 of the same PCI device.
- * The device link stays in place until shutdown (or removal of the PCI device
- * if it's hotplugged). Runtime PM is allowed by default on the HDA controller
- * to prevent it from permanently keeping the GPU awake.
+ * Multi-function PCI devices can have hardware functional dependencies from
+ * one function (consumer) to another function (supplier). Whenever the
+ * consumer is in D0 state, the supplier should also be in D0 state. This is
+ * a helper function which creates device link from the consumer to the
+ * supplier. The device link stays in place until shutdown (or removal of
+ * the PCI device if it's hotplugged). Runtime PM is allowed by default on
+ * consumers to prevent it from permanently keeping the supplier awake.
*/
-static void quirk_gpu_hda(struct pci_dev *hda)
+static void pci_create_device_link(struct pci_dev *pdev, unsigned int consumer,
+ unsigned int supplier, unsigned int class,
+ unsigned int class_shift)
{
- struct pci_dev *gpu;
+ struct pci_dev *supplier_pdev;
- if (PCI_FUNC(hda->devfn) != 1)
+ if (PCI_FUNC(pdev->devfn) != consumer)
return;
- gpu = pci_get_domain_bus_and_slot(pci_domain_nr(hda->bus),
- hda->bus->number,
- PCI_DEVFN(PCI_SLOT(hda->devfn), 0));
- if (!gpu || (gpu->class >> 16) != PCI_BASE_CLASS_DISPLAY) {
- pci_dev_put(gpu);
+ supplier_pdev = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
+ pdev->bus->number,
+ PCI_DEVFN(PCI_SLOT(pdev->devfn), supplier));
+ if (!supplier_pdev || (supplier_pdev->class >> class_shift) != class) {
+ pci_dev_put(supplier_pdev);
return;
}
- if (!device_link_add(&hda->dev, &gpu->dev,
-DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME))
- pci_err(hda, "cannot link HDA to GPU %s\n", pci_name(gpu));
+ if (device_link_add(&pdev->dev, &supplier_pdev->dev,
+ DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME))
+ pci_info(pdev, "Linked with %s\n", pci_name(supplier_pdev));
+ else
+ pci_err(pdev, "Cannot link with %s\n", pci_name(supplier_pdev));
+
+ pm_runtime_allow(&pdev->dev);
+ pci_dev_put(supplier_pdev);
+}
- pm_runtime_allow(&hda->dev);
- pci_dev_put(gpu);
+/*
+ * Create device link for GPUs with integrated HDA controller for streaming
+ * audio to attached displays.
+ */
+static void quirk_gpu_hda(struct pci_dev *hda)
+{
+ pci_create_device_link(hda, 1, 0, PCI_BASE_CLASS_DISPLAY, 16);
}
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
PCI_CLASS_MULTIMEDIA_HD_AUDIO, 8, quirk_gpu_hda);
--
2.17.1
[PATCH v2 0/2] PCI: device link quirk for NVIDIA GPU
* v2: 1. Make the pci device link helper function generic which can be used for other multi-function PCI devices also. 2. Minor changes in comments and commit logs. * v1: NVIDIA Turing GPU [1] has hardware support for USB Type-C and VirtualLink [2]. The Turing GPU is a multi-function PCI device which has the following four functions: - VGA display controller (Function 0) - Audio controller (Function 1) - USB xHCI Host controller (Function 2) - USB Type-C USCI controller (Function 3) Currently NVIDIA and Nouveau GPU drivers only manage function 0. Rest of the functions are managed by other drivers. These functions internally in the hardware are tightly coupled. When function 0 goes in runtime suspended state, then it will do power gating for most of the hardware blocks. Some of these hardware blocks are used by the other PCI functions, which leads to functional failure. In the mainline kernel, the device link is present between function 0 and function 1. This patch series deals with creating a similar kind of device link between function 0 and functions 2 and 3. [1] https://www.nvidia.com/content/dam/en-zz/Solutions/design-visualization/technologies/turing-architecture/NVIDIA-Turing-Architecture-Whitepaper.pdf [2] https://en.wikipedia.org/wiki/VirtualLink Abhishek Sahu (2): PCI: Code reorganization for creating device link PCI: Create device link for NVIDIA GPU drivers/pci/quirks.c | 79 +--- 1 file changed, 59 insertions(+), 20 deletions(-) -- 2.17.1
[PATCH v3] selinux: lsm: fix a missing-check bug in selinux_add_mnt_opt( )
In selinux_add_mnt_opt(), 'val' is allocated by kmemdup_nul(). It returns
NULL when fails. So 'val' should be checked. And 'mnt_opts' should be
freed when error.
Signed-off-by: Gen Zhang
Fixes: 757cbe597fe8 ("LSM: new method: ->sb_add_mnt_opt()")
---
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 3ec702c..4e4c1c6 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1052,15 +1052,23 @@ static int selinux_add_mnt_opt(const char *option,
const char *val, int len,
if (token == Opt_error)
return -EINVAL;
- if (token != Opt_seclabel)
- val = kmemdup_nul(val, len, GFP_KERNEL);
+ if (token != Opt_seclabel) {
+ val = kmemdup_nul(val, len, GFP_KERNEL);
+ if (!val) {
+ rc = -ENOMEM;
+ goto free_opt;
+ }
+ }
rc = selinux_add_opt(token, val, mnt_opts);
if (unlikely(rc)) {
kfree(val);
- if (*mnt_opts) {
- selinux_free_mnt_opts(*mnt_opts);
- *mnt_opts = NULL;
- }
+ goto free_opt;
+ }
+ return rc;
+free_opt:
+ if (*mnt_opts) {
+ selinux_free_mnt_opts(*mnt_opts);
+ *mnt_opts = NULL;
}
return rc;
}
Re: [PATCH 07/13] drivers: Add generic match helper by ACPI_COMPANION device
On 06/06/2019 10:17, Rafael J. Wysocki wrote: On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose wrote: Add a generic helper to match a device by the acpi device. "by its ACPI companion device object", please. Sure. Also, it would be good to combine this patch with the patch(es) that cause device_match_acpi_dev() to be actually used. Helpers without any users are arguably not useful. Sure, the helpers will be part of the part2 of the whole series, which will actually have the individual subsystems consuming the new helpers. For your reference, it is available here : http://linux-arm.org/git?p=linux-skp.git;a=shortlog;h=refs/heads/driver-cleanup/v2 e.g: http://linux-arm.org/git?p=linux-skp.git;a=commit;h=59534e843e2f214f1f29659993f6e423bef16b28 I could simply pull those patches into this part, if you prefer that. However, that would be true for the other patches in the part2. I am open to suggestions, on how to split the series. Cheers Suzuki
Re: rcu_read_lock lost its compiler barrier
On Thu, Jun 06, 2019 at 02:06:19AM -0700, Paul E. McKenney wrote: > > Or is your point instead that given the initial value of "a" being > zero and the value stored to "a" being one, there is no way that > any possible load and store tearing (your slicing and dicing) could > possibly mess up the test of the value loaded from "a"? Exactly. If you can dream up of a scenario where the compiler can get this wrong I'm all ears. > > But I do concede that in the general RCU case you must have the > > READ_ONCE/WRITE_ONCE calls for rcu_dereference/rcu_assign_pointer. > > OK, good that we are in agreement on this part, at least! ;-) Well only because we're allowing crazy compilers that can turn a simple word-aligned word assignment (a = b) into two stores. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
Hi, On Thu, Jun 06, 2019 at 10:54:51AM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2019-06-06 at 01:50 +0300, Aaro Koskinen wrote: > > Hi, > > > > When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN does > > not work anymore: > > > > [ 42.004303] b43legacy-phy0: Loading firmware version 0x127, patch level > > 14 (2005-04-18 02:36:27) > > [ 42.184837] b43legacy-phy0 debug: Chip initialized > > [ 42.184873] b43legacy-phy0 ERROR: The machine/kernel does not support > > the required 30-bit DMA mask > > > > The same happens with the current mainline. > > How much RAM do you have ? The system has 1129 MB RAM. Booting with mem=1G makes it work. A.
[PATCH v3 2/8] arm64: irqflags: Pass flags as readonly operand to restore instruction
Flags are only read by the instructions doing the irqflags restore operation. Pass the operand as read only to the asm inline instead of read-write. Signed-off-by: Julien Thierry Cc: Catalin Marinas Cc: Will Deacon --- arch/arm64/include/asm/irqflags.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h index 62996318..9c93152 100644 --- a/arch/arm64/include/asm/irqflags.h +++ b/arch/arm64/include/asm/irqflags.h @@ -119,8 +119,8 @@ static inline void arch_local_irq_restore(unsigned long flags) __msr_s(SYS_ICC_PMR_EL1, "%0") "dsbsy", ARM64_HAS_IRQ_PRIO_MASKING) - : "+r" (flags) : + : "r" (flags) : "memory"); } -- 1.9.1
[PATCH v3 0/8] arm64: IRQ priority masking and Pseudo-NMI fixes
Version one[1] of this series attempted to fix the issue reported by Zenghui[2] when using the function_graph tracer with IRQ priority masking. Since then, I realized that priority masking and the use of Pseudo-NMIs was more broken than I thought. * Patch 1-2 are just some cleanup * Patch 3 fixes a potential issue with not clobbering condition flags in irqflags operations * Patch 4 fixes an issue where calling C code in Pseudo-NMI before entering NMI enter could lead to potential races * Patch 5 fixes the function_graph issue when using priority masking * Patch 6 introduces some debug to hopefully avoid breaking things in the future * Patch 7 is a rebased version of the patch sent by Wei Li[3] fixing an error that can happen during on some platform using the priority masking feature * Patch 8 re-enables the Pseudo-NMI selection Changes since V2 [4]: - Rebase on v5.2-rc3 - clobber conditions flags for asm that needs it as pointed out by Marc Z. and Robin M. - Fix the naming of the new PMR bit value - Introduce some helper for the debug conditions - use WARN_ONCE for debug that might be very noisy - Reenable pseudo NMI. Changes since V1 [1]: - Fix possible race condition between NMI and trace irqflags - Simplify the representation of PSR.I in the PMR value - Include Wei Li's fix - Rebase on v5.1-rc7 [1] https://marc.info/?l=linux-arm-kernel&m=155542458004480&w=2 [2] https://www.spinics.net/lists/arm-kernel/msg716956.html [3] https://www.spinics.net/lists/arm-kernel/msg722171.html [4] https://lkml.org/lkml/2019/4/29/643 Cheers, Julien --> Julien Thierry (7): arm64: Do not enable IRQs for ct_user_exit arm64: irqflags: Pass flags as readonly operand to restore instruction arm64: irqflags: Add condition flags to inline asm clobber list arm64: Fix interrupt tracing in the presence of NMIs arm64: Fix incorrect irqflag restore for priority masking arm64: irqflags: Introduce explicit debugging for IRQ priorities arm64: Allow selecting Pseudo-NMI again Wei Li (1): arm64: fix kernel stack overflow in kdump capture kernel arch/arm64/Kconfig | 12 +- arch/arm64/include/asm/arch_gicv3.h | 4 +- arch/arm64/include/asm/cpufeature.h | 6 +++ arch/arm64/include/asm/daifflags.h | 75 + arch/arm64/include/asm/irqflags.h | 79 +- arch/arm64/include/asm/kvm_host.h | 7 ++-- arch/arm64/include/asm/ptrace.h | 10 - arch/arm64/kernel/entry.S | 84 + arch/arm64/kernel/irq.c | 26 arch/arm64/kernel/process.c | 2 +- arch/arm64/kernel/smp.c | 6 +-- arch/arm64/kvm/hyp/switch.c | 2 +- drivers/irqchip/irq-gic-v3.c| 6 +++ kernel/irq/irqdesc.c| 8 +++- 14 files changed, 227 insertions(+), 100 deletions(-) -- 1.9.1
[PATCH v3 6/8] arm64: irqflags: Introduce explicit debugging for IRQ priorities
Using IRQ priority masking to enable/disable interrupts is a bit
sensitive as it requires to deal with both ICC_PMR_EL1 and PSR.I.
Introduce some validity checks to both highlight the states in which
functions dealing with IRQ enabling/disabling can (not) be called, and
bark a warning when called in an unexpected state.
Since these checks are done on hotpaths, introduce a build option to
choose whether to do the checking.
Signed-off-by: Julien Thierry
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/Kconfig | 11 +++
arch/arm64/include/asm/cpufeature.h | 6 ++
arch/arm64/include/asm/daifflags.h | 7 +++
arch/arm64/include/asm/irqflags.h | 14 +-
4 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 697ea05..8acc40e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1436,6 +1436,17 @@ config ARM64_PSEUDO_NMI
If unsure, say N
+if ARM64_PSEUDO_NMI
+config ARM64_DEBUG_PRIORITY_MASKING
+ bool "Debug interrupt priority masking"
+ help
+ This adds runtime checks to functions enabling/disabling
+ interrupts when using priority masking. The additional checks verify
+ the validity of ICC_PMR_EL1 when calling concerned functions.
+
+ If unsure, say N
+endif
+
config RELOCATABLE
bool
help
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index bc895c8..693a086 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -617,6 +617,12 @@ static inline bool system_uses_irq_prio_masking(void)
cpus_have_const_cap(ARM64_HAS_IRQ_PRIO_MASKING);
}
+static inline bool system_has_prio_mask_debugging(void)
+{
+ return IS_ENABLED(CONFIG_ARM64_DEBUG_PRIORITY_MASKING) &&
+ system_uses_irq_prio_masking();
+}
+
#define ARM64_SSBD_UNKNOWN -1
#define ARM64_SSBD_FORCE_DISABLE 0
#define ARM64_SSBD_KERNEL 1
diff --git a/arch/arm64/include/asm/daifflags.h
b/arch/arm64/include/asm/daifflags.h
index f93204f..eca5bee 100644
--- a/arch/arm64/include/asm/daifflags.h
+++ b/arch/arm64/include/asm/daifflags.h
@@ -28,6 +28,10 @@
/* mask/save/unmask/restore all exceptions, including interrupts. */
static inline void local_daif_mask(void)
{
+ WARN_ON(system_has_prio_mask_debugging() &&
+ (read_sysreg_s(SYS_ICC_PMR_EL1) == (GIC_PRIO_IRQOFF |
+ GIC_PRIO_PSR_I_SET)));
+
asm volatile(
"msrdaifset, #0xf // local_daif_mask\n"
:
@@ -62,6 +66,9 @@ static inline void local_daif_restore(unsigned long flags)
{
bool irq_disabled = flags & PSR_I_BIT;
+ WARN_ON(system_has_prio_mask_debugging() &&
+ !(read_sysreg(daif) & PSR_I_BIT));
+
if (!irq_disabled) {
trace_hardirqs_on();
diff --git a/arch/arm64/include/asm/irqflags.h
b/arch/arm64/include/asm/irqflags.h
index b6f757f..cac2d2a 100644
--- a/arch/arm64/include/asm/irqflags.h
+++ b/arch/arm64/include/asm/irqflags.h
@@ -40,6 +40,12 @@
*/
static inline void arch_local_irq_enable(void)
{
+ if (system_has_prio_mask_debugging()) {
+ u32 pmr = read_sysreg_s(SYS_ICC_PMR_EL1);
+
+ WARN_ON_ONCE(pmr != GIC_PRIO_IRQON && pmr != GIC_PRIO_IRQOFF);
+ }
+
asm volatile(ALTERNATIVE(
"msrdaifclr, #2 // arch_local_irq_enable\n"
"nop",
@@ -53,6 +59,12 @@ static inline void arch_local_irq_enable(void)
static inline void arch_local_irq_disable(void)
{
+ if (system_has_prio_mask_debugging()) {
+ u32 pmr = read_sysreg_s(SYS_ICC_PMR_EL1);
+
+ WARN_ON_ONCE(pmr != GIC_PRIO_IRQON && pmr != GIC_PRIO_IRQOFF);
+ }
+
asm volatile(ALTERNATIVE(
"msrdaifset, #2 // arch_local_irq_disable",
__msr_s(SYS_ICC_PMR_EL1, "%0"),
@@ -86,7 +98,7 @@ static inline int arch_irqs_disabled_flags(unsigned long
flags)
asm volatile(ALTERNATIVE(
"and%w0, %w1, #" __stringify(PSR_I_BIT),
- "eor%w0, %w1, #" __stringify(GIC_PRIO_IRQOFF),
+ "eor%w0, %w1, #" __stringify(GIC_PRIO_IRQON),
ARM64_HAS_IRQ_PRIO_MASKING)
: "=&r" (res)
: "r" ((int) flags)
--
1.9.1
Re: rcu_read_lock lost its compiler barrier
On Thu, Jun 06, 2019 at 10:38:56AM +0200, Andrea Parri wrote: > On Mon, Jun 03, 2019 at 10:46:40AM +0800, Herbert Xu wrote: > > > The case we were discussing is from net/ipv4/inet_fragment.c from > > the net-next tree: > > BTW, thank you for keeping me and other people who intervened in that > discussion in Cc:... FWIW I didn't drop you from the Cc list. The email discussion was taken off-list by someone else and I simply kept that Cc list when I brought it back onto lkml. On a second look I did end up dropping Eric but I think he's had enough of this discussion :) -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH v3 1/8] arm64: Do not enable IRQs for ct_user_exit
For el0_dbg and el0_error, DAIF bits get explicitly cleared before calling ct_user_exit. When context tracking is disabled, DAIF gets set (almost) immediately after. When context tracking is enabled, among the first things done is disabling IRQs. What is actually needed is: - PSR.D = 0 so the system can be debugged (should be already the case) - PSR.A = 0 so async error can be handled during context tracking Do not clear PSR.I in those two locations. Signed-off-by: Julien Thierry Cc:Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Cc: Marc Zyngier --- arch/arm64/kernel/entry.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index cd0c7af..89ab6bd 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -870,7 +870,7 @@ el0_dbg: mov x1, x25 mov x2, sp bl do_debug_exception - enable_daif + enable_da_f ct_user_exit b ret_to_user el0_inv: @@ -922,7 +922,7 @@ el0_error_naked: enable_dbg mov x0, sp bl do_serror - enable_daif + enable_da_f ct_user_exit b ret_to_user ENDPROC(el0_error) -- 1.9.1
[PATCH v3 3/8] arm64: irqflags: Add condition flags to inline asm clobber list
Some of the inline assembly instruction use the condition flags and need
to include "cc" in the clobber list.
Fixes: commit 4a503217ce37 ("arm64: irqflags: Use ICC_PMR_EL1 for interrupt
masking")
Suggested-by: Marc Zyngier
Signed-off-by: Julien Thierry
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/include/asm/irqflags.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/irqflags.h
b/arch/arm64/include/asm/irqflags.h
index 9c93152..fbe1aba 100644
--- a/arch/arm64/include/asm/irqflags.h
+++ b/arch/arm64/include/asm/irqflags.h
@@ -92,7 +92,7 @@ static inline unsigned long arch_local_save_flags(void)
ARM64_HAS_IRQ_PRIO_MASKING)
: "=&r" (flags), "+r" (daif_bits)
: "r" ((unsigned long) GIC_PRIO_IRQOFF)
- : "memory");
+ : "cc", "memory");
return flags;
}
@@ -136,7 +136,7 @@ static inline int arch_irqs_disabled_flags(unsigned long
flags)
ARM64_HAS_IRQ_PRIO_MASKING)
: "=&r" (res)
: "r" ((int) flags)
- : "memory");
+ : "cc", "memory");
return res;
}
--
1.9.1
[PATCH v3 5/8] arm64: Fix incorrect irqflag restore for priority masking
When using IRQ priority masking to disable interrupts, in order to deal
with the PSR.I state, local_irq_save() would convert the I bit into a
PMR value (GIC_PRIO_IRQOFF). This resulted in local_irq_restore()
potentially modifying the value of PMR in undesired location due to the
state of PSR.I upon flag saving [1].
In an attempt to solve this issue in a less hackish manner, introduce
a bit (GIC_PRIO_IGNORE_PMR) for the PMR values that can represent
whether PSR.I is being used to disable interrupts, in which case it
takes precedence of the status of interrupt masking via PMR.
GIC_PRIO_IGNORE_PMR is chosen such that ( |
GIC_PRIO_IGNORE_PMR) does not mask more interrupts than as
some sections (e.g. arch_cpu_idle(), interrupt acknowledge path)
requires PMR not to mask interrupts that could be signaled to the
CPU when using only PSR.I.
[1] https://www.spinics.net/lists/arm-kernel/msg716956.html
Fixes: commit 4a503217ce37 ("arm64: irqflags: Use ICC_PMR_EL1 for interrupt
masking")
Signed-off-by: Julien Thierry
Reported-by: Zenghui Yu
Cc: Steven Rostedt
Cc: Wei Li
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Christoffer Dall
Cc: Marc Zyngier
Cc: James Morse
Cc: Suzuki K Pouloze
Cc: Oleg Nesterov
---
arch/arm64/include/asm/arch_gicv3.h | 4 ++-
arch/arm64/include/asm/daifflags.h | 68 ++---
arch/arm64/include/asm/irqflags.h | 67 +++-
arch/arm64/include/asm/kvm_host.h | 7 ++--
arch/arm64/include/asm/ptrace.h | 10 --
arch/arm64/kernel/entry.S | 38 ++---
arch/arm64/kernel/process.c | 2 +-
arch/arm64/kernel/smp.c | 8 +++--
arch/arm64/kvm/hyp/switch.c | 2 +-
9 files changed, 123 insertions(+), 83 deletions(-)
diff --git a/arch/arm64/include/asm/arch_gicv3.h
b/arch/arm64/include/asm/arch_gicv3.h
index 14b41dd..9e991b6 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -163,7 +163,9 @@ static inline bool gic_prio_masking_enabled(void)
static inline void gic_pmr_mask_irqs(void)
{
- BUILD_BUG_ON(GICD_INT_DEF_PRI <= GIC_PRIO_IRQOFF);
+ BUILD_BUG_ON(GICD_INT_DEF_PRI < (GIC_PRIO_IRQOFF |
+GIC_PRIO_PSR_I_SET));
+ BUILD_BUG_ON(GICD_INT_DEF_PRI >= GIC_PRIO_IRQON);
gic_write_pmr(GIC_PRIO_IRQOFF);
}
diff --git a/arch/arm64/include/asm/daifflags.h
b/arch/arm64/include/asm/daifflags.h
index db452aa..f93204f 100644
--- a/arch/arm64/include/asm/daifflags.h
+++ b/arch/arm64/include/asm/daifflags.h
@@ -18,6 +18,7 @@
#include
+#include
#include
#define DAIF_PROCCTX 0
@@ -32,6 +33,11 @@ static inline void local_daif_mask(void)
:
:
: "memory");
+
+ /* Don't really care for a dsb here, we don't intend to enable IRQs */
+ if (system_uses_irq_prio_masking())
+ gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
+
trace_hardirqs_off();
}
@@ -43,7 +49,7 @@ static inline unsigned long local_daif_save(void)
if (system_uses_irq_prio_masking()) {
/* If IRQs are masked with PMR, reflect it in the flags */
- if (read_sysreg_s(SYS_ICC_PMR_EL1) <= GIC_PRIO_IRQOFF)
+ if (read_sysreg_s(SYS_ICC_PMR_EL1) != GIC_PRIO_IRQON)
flags |= PSR_I_BIT;
}
@@ -59,36 +65,44 @@ static inline void local_daif_restore(unsigned long flags)
if (!irq_disabled) {
trace_hardirqs_on();
- if (system_uses_irq_prio_masking())
- arch_local_irq_enable();
- } else if (!(flags & PSR_A_BIT)) {
- /*
-* If interrupts are disabled but we can take
-* asynchronous errors, we can take NMIs
-*/
if (system_uses_irq_prio_masking()) {
- flags &= ~PSR_I_BIT;
+ gic_write_pmr(GIC_PRIO_IRQON);
+ dsb(sy);
+ }
+ } else if (system_uses_irq_prio_masking()) {
+ u64 pmr;
+
+ if (!(flags & PSR_A_BIT)) {
/*
-* There has been concern that the write to daif
-* might be reordered before this write to PMR.
-* From the ARM ARM DDI 0487D.a, section D1.7.1
-* "Accessing PSTATE fields":
-* Writes to the PSTATE fields have side-effects on
-* various aspects of the PE operation. All of these
-* side-effects are guaranteed:
-* - Not to be visible to earlier instructions in
-* the execution stream.
-* - To be visible to later instructions in the
-* execution stream
-*
-
[PATCH v3 8/8] arm64: Allow selecting Pseudo-NMI again
Now that Pseudo-NMI are fixed, allow the use of that option again
This reverts commit 96a13f57b946be7a6c10405e4bd780c0b6b6fe63 ("arm64:
Kconfig: Make ARM64_PSEUDO_NMI depend on BROKEN for now").
Signed-off-by: Julien Thierry
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8acc40e..a9dde24 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1423,7 +1423,6 @@ config ARM64_MODULE_PLTS
config ARM64_PSEUDO_NMI
bool "Support for NMI-like interrupts"
- depends on BROKEN #
1556553607-46531-1-git-send-email-julien.thie...@arm.com
select CONFIG_ARM_GIC_V3
help
Adds support for mimicking Non-Maskable Interrupts through the use of
--
1.9.1
[PATCH v3 4/8] arm64: Fix interrupt tracing in the presence of NMIs
In the presence of any form of instrumentation, nmi_enter() should be
done before calling any traceable code and any instrumentation code.
Currently, nmi_enter() is done in handle_domain_nmi(), which is much
too late as instrumentation code might get called before. Move the
nmi_enter/exit() calls to the arch IRQ vector handler.
On arm64, it is not possible to know if the IRQ vector handler was
called because of an NMI before acknowledging the interrupt. However, It
is possible to know whether normal interrupts could be taken in the
interrupted context (i.e. if taking an NMI in that context could
introduce a potential race condition).
When interrupting a context with IRQs disabled, call nmi_enter() as soon
as possible. In contexts with IRQs enabled, defer this to the interrupt
controller, which is in a better position to know if an interrupt taken
is an NMI.
Fixes: bc3c03ccb ("arm64: Enable the support of pseudo-NMIs")
Signed-off-by: Julien Thierry
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: Mark Rutland
---
arch/arm64/kernel/entry.S| 44 +---
arch/arm64/kernel/irq.c | 17 +
drivers/irqchip/irq-gic-v3.c | 6 ++
kernel/irq/irqdesc.c | 8 ++--
4 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 89ab6bd..46358a3 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -435,6 +435,20 @@ tsk.reqx28 // current thread_info
irq_stack_exit
.endm
+#ifdef CONFIG_ARM64_PSEUDO_NMI
+ /*
+* Set res to 0 if irqs were masked in interrupted context.
+* Otherwise set res to non-0 value.
+*/
+ .macro test_irqs_unmasked res:req, pmr:req
+alternative_if ARM64_HAS_IRQ_PRIO_MASKING
+ sub \res, \pmr, #GIC_PRIO_IRQON
+alternative_else
+ mov \res, xzr
+alternative_endif
+ .endm
+#endif
+
.text
/*
@@ -631,19 +645,19 @@ ENDPROC(el1_sync)
el1_irq:
kernel_entry 1
enable_da_f
-#ifdef CONFIG_TRACE_IRQFLAGS
+
#ifdef CONFIG_ARM64_PSEUDO_NMI
alternative_if ARM64_HAS_IRQ_PRIO_MASKING
ldr x20, [sp, #S_PMR_SAVE]
-alternative_else
- mov x20, #GIC_PRIO_IRQON
-alternative_endif
- cmp x20, #GIC_PRIO_IRQOFF
- /* Irqs were disabled, don't trace */
- b.ls1f
+alternative_else_nop_endif
+ test_irqs_unmasked res=x0, pmr=x20
+ cbz x0, 1f
+ bl asm_nmi_enter
+1:
#endif
+
+#ifdef CONFIG_TRACE_IRQFLAGS
bl trace_hardirqs_off
-1:
#endif
irq_handler
@@ -662,14 +676,22 @@ alternative_else_nop_endif
bl preempt_schedule_irq// irq en/disable is done inside
1:
#endif
-#ifdef CONFIG_TRACE_IRQFLAGS
+
#ifdef CONFIG_ARM64_PSEUDO_NMI
/*
* if IRQs were disabled when we received the interrupt, we have an NMI
* and we are not re-enabling interrupt upon eret. Skip tracing.
*/
- cmp x20, #GIC_PRIO_IRQOFF
- b.ls1f
+ test_irqs_unmasked res=x0, pmr=x20
+ cbz x0, 1f
+ bl asm_nmi_exit
+1:
+#endif
+
+#ifdef CONFIG_TRACE_IRQFLAGS
+#ifdef CONFIG_ARM64_PSEUDO_NMI
+ test_irqs_unmasked res=x0, pmr=x20
+ cbnzx0, 1f
#endif
bl trace_hardirqs_on
1:
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 92fa817..fdd9cb2 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -27,8 +27,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
unsigned long irq_err_count;
@@ -76,3 +78,18 @@ void __init init_IRQ(void)
if (!handle_arch_irq)
panic("No interrupt controller found.");
}
+
+/*
+ * Stubs to make nmi_enter/exit() code callable from ASM
+ */
+asmlinkage void notrace asm_nmi_enter(void)
+{
+ nmi_enter();
+}
+NOKPROBE_SYMBOL(asm_nmi_enter);
+
+asmlinkage void notrace asm_nmi_exit(void)
+{
+ nmi_exit();
+}
+NOKPROBE_SYMBOL(asm_nmi_exit);
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index f44cd89..0bf0fc4 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -495,7 +495,13 @@ static asmlinkage void __exception_irq_entry
gic_handle_irq(struct pt_regs *regs
if (gic_supports_nmi() &&
unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
+ if (interrupts_enabled(regs))
+ nmi_enter();
+
gic_handle_nmi(irqnr, regs);
+
+ if (interrupts_enabled(regs))
+ nmi_exit();
return;
}
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index c52b737..a92b335 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -680,6 +680,8 @@ int __handle_domain_irq(struct irq_domain *domain, unsigned
int hwirq,
* @
[PATCH v3 7/8] arm64: fix kernel stack overflow in kdump capture kernel
From: Wei Li
When enabling ARM64_PSEUDO_NMI feature in kdump capture kernel, it will
report a kernel stack overflow exception:
[0.00] CPU features: detected: IRQ priority masking
[0.00] alternatives: patching kernel code
[0.00] Insufficient stack space to handle exception!
[0.00] ESR: 0x9644 -- DABT (current EL)
[0.00] FAR: 0x0040
[0.00] Task stack: [0x097f..0x097f4000]
[0.00] IRQ stack: [0x..0x4000]
[0.00] Overflow stack: [0x80002b7cf290..0x80002b7d0290]
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.34-lw+ #3
[0.00] pstate: 43c5 (nZcv DAIF -PAN -UAO)
[0.00] pc : el1_sync+0x0/0xb8
[0.00] lr : el1_irq+0xb8/0x140
[0.00] sp : 0040
[0.00] pmr_save: 0070
[0.00] x29: 097f3f60 x28: 09806240
[0.00] x27: 8000 x26: 4000
[0.00] x25: x24: 09329028
[0.00] x23: 4005 x22: 08095c6c
[0.00] x21: 097f3f70 x20: 0070
[0.00] x19: 097f3e30 x18:
[0.00] x17: x16:
[0.00] x15: 097f9708 x14: 89a382ef
[0.00] x13: 09a382fd x12: 09824000
[0.00] x11: 097fb7b0 x10: 08730028
[0.00] x9 : 09440018 x8 : 000d
[0.00] x7 : 6b20676e69686374 x6 : 003b
[0.00] x5 : x4 : 08093600
[0.00] x3 : 00040008 x2 : 7db2e689fc2b8e00
[0.00] x1 : x0 : 097f3e30
[0.00] Kernel panic - not syncing: kernel stack overflow
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.34-lw+ #3
[0.00] Call trace:
[0.00] dump_backtrace+0x0/0x1b8
[0.00] show_stack+0x24/0x30
[0.00] dump_stack+0xa8/0xcc
[0.00] panic+0x134/0x30c
[0.00] __stack_chk_fail+0x0/0x28
[0.00] handle_bad_stack+0xfc/0x108
[0.00] __bad_stack+0x90/0x94
[0.00] el1_sync+0x0/0xb8
[0.00] init_gic_priority_masking+0x4c/0x70
[0.00] smp_prepare_boot_cpu+0x60/0x68
[0.00] start_kernel+0x1e8/0x53c
[0.00] ---[ end Kernel panic - not syncing: kernel stack overflow ]---
The reason is init_gic_priority_masking() may unmask PSR.I while the
irq stacks are not inited yet. Some "NMI" could be raised unfortunately
and it will just go into this exception.
In this patch, we just write the PMR in smp_prepare_boot_cpu(), and delay
unmasking PSR.I after irq stacks inited in init_IRQ().
Fixes: e79321883842 ("arm64: Switch to PMR masking when starting CPUs")
Signed-off-by: Wei Li
[JT: make init_gic_priority_masking() not modify daif, rebase on other
priority masking fixes]
Signed-off-by: Julien Thierry
---
arch/arm64/kernel/irq.c | 9 +
arch/arm64/kernel/smp.c | 8 +---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index fdd9cb2..e8daa7a 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -77,6 +77,15 @@ void __init init_IRQ(void)
irqchip_init();
if (!handle_arch_irq)
panic("No interrupt controller found.");
+
+ if (system_uses_irq_prio_masking()) {
+ /*
+* Now that we have a stack for our IRQ handler, set
+* the PMR/PSR pair to a consistent state.
+*/
+ WARN_ON(read_sysreg(daif) & PSR_A_BIT);
+ local_daif_restore(DAIF_PROCCTX_NOIRQ);
+ }
}
/*
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 4deaee3..83cdb0a 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -192,13 +192,7 @@ static void init_gic_priority_masking(void)
WARN_ON(!(cpuflags & PSR_I_BIT));
- /* We can only unmask PSR.I if we can take aborts */
- if (!(cpuflags & PSR_A_BIT)) {
- gic_write_pmr(GIC_PRIO_IRQOFF);
- write_sysreg(cpuflags & ~PSR_I_BIT, daif);
- } else {
- gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
- }
+ gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
}
/*
--
1.9.1
[PATCH] VMCI: Fixup atomic64_t abuse
The VMCI driver is abusing atomic64_t and atomic_t, there is no actual
atomic RmW operations around.
Rewrite the code to use a regular u64 with READ_ONCE() and
WRITE_ONCE() and a cast to 'unsigned long'. This fully preserves
whatever broken there was (it's not endian-safe for starters, and also
looks to be missing ordering).
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/vmw_vmci_defs.h | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
--- a/include/linux/vmw_vmci_defs.h
+++ b/include/linux/vmw_vmci_defs.h
@@ -438,8 +438,8 @@ enum {
struct vmci_queue_header {
/* All fields are 64bit and aligned. */
struct vmci_handle handle; /* Identifier. */
- atomic64_t producer_tail; /* Offset in this queue. */
- atomic64_t consumer_head; /* Offset in peer queue. */
+ u64 producer_tail; /* Offset in this queue. */
+ u64 consumer_head; /* Offset in peer queue. */
};
/*
@@ -740,13 +740,9 @@ static inline void *vmci_event_data_payl
* prefix will be used, so correctness isn't an issue, but using a
* 64bit operation still adds unnecessary overhead.
*/
-static inline u64 vmci_q_read_pointer(atomic64_t *var)
+static inline u64 vmci_q_read_pointer(u64 *var)
{
-#if defined(CONFIG_X86_32)
- return atomic_read((atomic_t *)var);
-#else
- return atomic64_read(var);
-#endif
+ return READ_ONCE(*(unsigned long *)var);
}
/*
@@ -755,23 +751,17 @@ static inline u64 vmci_q_read_pointer(at
* never exceeds a 32bit value in this case. On 32bit SMP, using a
* locked cmpxchg8b adds unnecessary overhead.
*/
-static inline void vmci_q_set_pointer(atomic64_t *var,
- u64 new_val)
+static inline void vmci_q_set_pointer(u64 *var, u64 new_val)
{
-#if defined(CONFIG_X86_32)
- return atomic_set((atomic_t *)var, (u32)new_val);
-#else
- return atomic64_set(var, new_val);
-#endif
+ /* XXX buggered on big-endian */
+ WRITE_ONCE(*(unsigned long *)var, (unsigned long)new_val);
}
/*
* Helper to add a given offset to a head or tail pointer. Wraps the
* value of the pointer around the max size of the queue.
*/
-static inline void vmci_qp_add_pointer(atomic64_t *var,
- size_t add,
- u64 size)
+static inline void vmci_qp_add_pointer(u64 *var, size_t add, u64 size)
{
u64 new_val = vmci_q_read_pointer(var);
@@ -848,8 +838,8 @@ static inline void vmci_q_header_init(st
const struct vmci_handle handle)
{
q_header->handle = handle;
- atomic64_set(&q_header->producer_tail, 0);
- atomic64_set(&q_header->consumer_head, 0);
+ q_header->producer_tail = 0;
+ q_header->consumer_head = 0;
}
/*
Re: [PATCH V2 3/4] arm64/mm: Consolidate page fault information capture
On Tue, Jun 04, 2019 at 03:42:09PM +0100, Catalin Marinas wrote:
> On Mon, Jun 03, 2019 at 12:11:24PM +0530, Anshuman Khandual wrote:
> > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > index da02678..4bb65f3 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> > @@ -435,6 +435,14 @@ static bool is_el0_instruction_abort(unsigned int esr)
> > return ESR_ELx_EC(esr) == ESR_ELx_EC_IABT_LOW;
> > }
> >
> > +/*
> > + * This is applicable only for EL0 write aborts.
> > + */
> > +static bool is_el0_write_abort(unsigned int esr)
> > +{
> > + return (esr & ESR_ELx_WNR) && !(esr & ESR_ELx_CM);
> > +}
>
> What makes this EL0 only?
It returns false for EL1 faults caused by DC IVAC, where write
permission is required. EL0 can only issue maintenance that requires
read permission.
For whatever reason, the architecture says that WnR is always 1b1, even
if read permission was sufficient.
How about:
/*
* Note: not valid for EL1 DC IVAC, but we never use that such that it
* should fault.
*/
static bool is_write_abort(unsigned int esr)
{
return (esr & ESR_ELx_WNR) && !(esr & ESR_ELx_CM);
}
... which would also address your concern about EL1 writes to a user
mapping.
Thanks,
Mark.
Re: [PATCH 1/3] ARM64: trivial: s/TIF_SECOMP/TIF_SECCOMP/ comment typo fix
On Wed, Jun 05, 2019 at 03:04:06PM -0700, Kees Cook wrote: > On Wed, Jun 05, 2019 at 04:30:09PM -0400, George G. Davis wrote: > > Fix a s/TIF_SECOMP/TIF_SECCOMP/ comment typo > > > > Cc: Jiri Kosina > > Signed-off-by: George G. Davis > > Sneaky missing "C"! :) > > Reviewed-by: Kees Cook I've already got a few arm64 patches for -rc4, so I'll include this one in my pull as it's harmless. Cheers, Will
[PATCH v6 1/2] Bluetooth: hci_qca: Load customized NVM based on the device property
QCA BTSOC NVM is a customized firmware file and different vendors may
want to have different BTSOC configuration (e.g. Configure SCO over PCM
or I2S, Setting Tx power, etc.) via this file. This patch will allow
vendors to download different NVM firmware file by reading a device
property "firmware-name".
Signed-off-by: Rocky Liao
---
Changes in v6:
* Added read firmware-name property for both QCA6174 and WCN399X
---
drivers/bluetooth/btqca.c | 8 ++--
drivers/bluetooth/btqca.h | 6 --
drivers/bluetooth/hci_qca.c | 18 +-
3 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index cc12eec..a78b80e 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -332,7 +332,8 @@ int qca_set_bdaddr_rome(struct hci_dev *hdev, const
bdaddr_t *bdaddr)
EXPORT_SYMBOL_GPL(qca_set_bdaddr_rome);
int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
- enum qca_btsoc_type soc_type, u32 soc_ver)
+ enum qca_btsoc_type soc_type, u32 soc_ver,
+ const char *firmware_name)
{
struct rome_config config;
int err;
@@ -365,7 +366,10 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
/* Download NVM configuration */
config.type = TLV_TYPE_NVM;
- if (qca_is_wcn399x(soc_type))
+ if (firmware_name)
+ snprintf(config.fwname, sizeof(config.fwname),
+"qca/%s", firmware_name);
+ else if (qca_is_wcn399x(soc_type))
snprintf(config.fwname, sizeof(config.fwname),
"qca/crnv%02x.bin", rom_ver);
else
diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
index 4c4fe2b..8c037bb 100644
--- a/drivers/bluetooth/btqca.h
+++ b/drivers/bluetooth/btqca.h
@@ -140,7 +140,8 @@ enum qca_btsoc_type {
int qca_set_bdaddr_rome(struct hci_dev *hdev, const bdaddr_t *bdaddr);
int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
- enum qca_btsoc_type soc_type, u32 soc_ver);
+ enum qca_btsoc_type soc_type, u32 soc_ver,
+ const char *firmware_name);
int qca_read_soc_version(struct hci_dev *hdev, u32 *soc_version);
int qca_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr);
static inline bool qca_is_wcn399x(enum qca_btsoc_type soc_type)
@@ -155,7 +156,8 @@ static inline int qca_set_bdaddr_rome(struct hci_dev *hdev,
const bdaddr_t *bdad
}
static inline int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
-enum qca_btsoc_type soc_type, u32 soc_ver)
+enum qca_btsoc_type soc_type, u32 soc_ver,
+const char *firmware_name)
{
return -EOPNOTSUPP;
}
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 57322c4..05ee0a1 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -169,6 +169,7 @@ struct qca_serdev {
struct qca_power *bt_power;
u32 init_speed;
u32 oper_speed;
+ const char *firmware_name;
};
static int qca_power_setup(struct hci_uart *hu, bool on);
@@ -190,6 +191,17 @@ static enum qca_btsoc_type qca_soc_type(struct hci_uart
*hu)
return soc_type;
}
+static const char *qca_get_firmware_name(struct hci_uart *hu)
+{
+ if (hu->serdev) {
+ struct qca_serdev *qsd = serdev_device_get_drvdata(hu->serdev);
+
+ return qsd->firmware_name;
+ } else {
+ return NULL;
+ }
+}
+
static void __serial_clock_on(struct tty_struct *tty)
{
/* TODO: Some chipset requires to enable UART clock on client
@@ -1195,6 +1207,7 @@ static int qca_setup(struct hci_uart *hu)
struct qca_data *qca = hu->priv;
unsigned int speed, qca_baudrate = QCA_BAUDRATE_115200;
enum qca_btsoc_type soc_type = qca_soc_type(hu);
+ const char *firmware_name = qca_get_firmware_name(hu);
int ret;
int soc_ver = 0;
@@ -1245,7 +1258,8 @@ static int qca_setup(struct hci_uart *hu)
bt_dev_info(hdev, "QCA controller version 0x%08x", soc_ver);
/* Setup patch / NVM configurations */
- ret = qca_uart_setup(hdev, qca_baudrate, soc_type, soc_ver);
+ ret = qca_uart_setup(hdev, qca_baudrate, soc_type, soc_ver,
+ firmware_name);
if (!ret) {
set_bit(QCA_IBS_ENABLED, &qca->flags);
qca_debugfs_init(hdev);
@@ -1439,6 +1453,8 @@ static int qca_serdev_probe(struct serdev_device *serdev)
qcadev->serdev_hu.serdev = serdev;
data = of_device_get_match_data(&serdev->dev);
serdev_device_set_drvdata(serdev, qcadev);
+ device_property_read_string(&serdev->dev, "firmware-name",
+&qcadev->firmware_name);
if (data && qca_is_wcn399x(data->soc_type)) {
qcadev->b
Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_')
Ard Biesheuvel wrote: > On Thu, 6 Jun 2019 at 09:50, Rolf Eike Beer wrote: > > Am Donnerstag, 6. Juni 2019, 09:38:41 CEST schrieb Rolf Eike Beer: > > > Greg KH wrote: > > > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > > > > I decided to dig out a toy project which uses a DragonBoard 410c. > > > > > This > > > > > has > > > > > been "running" with kernel 4.9, which I would keep this way for > > > > > unrelated > > > > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it > > > > > was > > > > > buildable, which was good enough. > > > > > > > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > > > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): in > > > > > function > > > > > `handle_kernel_image': > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > c:63 > > > > > > > > > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > > > > aarch64-unknown-linux-gnueabi-ld: > > > > > ./drivers/firmware/efi/libstub/lib.a(arm64- stub.stub.o): relocation > > > > > R_AARCH64_ADR_PREL_PG_HI21 against symbol > > > > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not > > > > > be > > > > > used when making a shared object; recompile with -fPIC > > > > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub. > > > > > c:63 > > > > > > > > > > (.init.text+0xc): dangerous relocation: unsupported relocation > > > > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target > > > > > 'vmlinux' > > > > > failed -make[1]: *** [vmlinux] Error 1 > > > > > > > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca > > > > > from > > > > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), > > > > > reverting > > > > > this commit fixes the build. > > > > > > > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as > > > > > 9.1.0. > > > > > See > > > > > the attached .config for reference. > > > > > > > > > > If you have questions or patches just ping me. > > > > > > > > Does Linus's latest tree also fail for you (or 5.1)? > > > > > > 5.1.7 with the same config as before and "make olddefconfig" builds for > > > me. > > > > Just for the fun of it: both 4.19 and 4.19.48 also work. > Could you please check whether patch > 60f38de7a8d4e816100ceafd1b382df52527bd50 applies cleanly, and whether > it fixes the problem? Thanks. The part in drivers/firmware/efi/libstub/arm-stub.c needs to be applied by hand, but afterwards things build fine. Eike -- Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source signature.asc Description: This is a digitally signed message part.
[PATCH v6 2/2] dt-bindings: net: bluetooth: Add device property firmware-name for QCA6174
This patch adds an optional device property "firmware-name" to allow the
driver to load customized nvm firmware file based on this property.
Signed-off-by: Rocky Liao
---
Changes in v6:
* Added read firmware-name property for both QCA6174 and WCN399X
---
Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
index 7ef6118..68b67d9 100644
--- a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
+++ b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
@@ -17,6 +17,7 @@ Optional properties for compatible string qcom,qca6174-bt:
- enable-gpios: gpio specifier used to enable chip
- clocks: clock provided to the controller (SUSCLK_32KHZ)
+ - firmware-name: specify the name of nvm firmware to load
Required properties for compatible string qcom,wcn399x-bt:
@@ -28,6 +29,7 @@ Required properties for compatible string qcom,wcn399x-bt:
Optional properties for compatible string qcom,wcn399x-bt:
- max-speed: see Documentation/devicetree/bindings/serial/slave-device.txt
+ - firmware-name: specify the name of nvm firmware to load
Examples:
@@ -40,6 +42,7 @@ serial@757 {
enable-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>;
clocks = <&divclk4>;
+ firmware-name = "nvm_00440302.bin";
};
};
@@ -52,5 +55,6 @@ serial@898000 {
vddrf-supply = <&vreg_l17a_1p3>;
vddch0-supply = <&vreg_l25a_3p3>;
max-speed = <320>;
+ firmware-name = "crnv21.bin";
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
Re: [PATCH 23/23] NFS: Add fs_context support.
Schumaker, Anna wrote: > > 17 files changed, 1293 insertions(+), 1331 deletions(-) > > Can you please split this patch up? Um... Al and I have split it up somewhat. See the other 22 patches in the series ;-) Splitting it up further is going to be tricky because of the way stuff weaves around all over the place in fs/nfs/. I can have a go, but, for various reasons, I'm not going to have time to look at that till after the next merge window. I don't know whether SteveD has a sufficiently empty plate to offload that to him? > The mailing list dropped it because it's over 100,000 characters > (http://vger.kernel.org/majordomo-info.html#taboo) and I can't use the > version you sent directly to me because Office365 / Evolution keeps > converting tabs to spaces somewhere along the line. Note also this bit in the cover letter: The patches can be found here also: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git on branch: mount-api-nfs ;-) David
Re: [PATCH] lockref: Limit number of cmpxchg loop retries
On Thu, Jun 06, 2019 at 08:03:27AM +, Jan Glauber wrote: > On Wed, Jun 05, 2019 at 01:16:46PM -0700, Linus Torvalds wrote: > > On Wed, Jun 5, 2019 at 6:49 AM Jan Glauber wrote: > > > > > > Add an upper bound to the loop to force the fallback to spinlocks > > > after some time. A retry value of 100 should not impact any hardware > > > that does not have this issue. > > > > > > With the retry limit the performance of an open-close testcase > > > improved between 60-70% on ThunderX2. > > > > Btw, did you do any kind of performance analysis across different > > retry limit values? > > I tried 15/50/100/200/500, results were largely identical up to 100. > For SMT=4 a higher retry value might be better, but unless we can add a > sysctl value 100 looked like a good compromise to me. Perhaps I'm just getting confused pre-morning-coffee, but I thought the original complaint (and the reason for this patch even existing) was that when many CPUs were hammering the lockref then performance tanked? In which case, increasing the threshold as the number of CPUs increases seems counter-intuitive to me because it suggests that the larger the system, the harder we should try to make the cmpxchg work. Will
KMSAN: uninit-value in rt2500usb_bbp_read
Hello, syzbot found the following crash on: HEAD commit:f75e4cfe kmsan: use kmsan_handle_urb() in urb.c git tree: kmsan console output: https://syzkaller.appspot.com/x/log.txt?x=12f8b01ea0 kernel config: https://syzkaller.appspot.com/x/.config?x=602468164ccdc30a dashboard link: https://syzkaller.appspot.com/bug?extid=a106a5b084a6890d2607 compiler: clang version 9.0.0 (/home/glider/llvm/clang 06d00afa61eef8f7f501ebdb4e8612ea43ec2d78) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14f746f2a0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=153072d2a0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+a106a5b084a6890d2...@syzkaller.appspotmail.com usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-1: config 0 descriptor?? usb 1-1: reset high-speed USB device number 2 using dummy_hcd usb 1-1: device descriptor read/64, error -71 ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x09 failed for offset 0x with error -71 ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x04d0 with error -71 == BUG: KMSAN: uninit-value in rt2500usb_regbusy_read drivers/net/wireless/ralink/rt2x00/rt2500usb.c:116 [inline] BUG: KMSAN: uninit-value in rt2500usb_bbp_read+0x174/0x640 drivers/net/wireless/ralink/rt2x00/rt2500usb.c:172 CPU: 1 PID: 4943 Comm: kworker/1:2 Not tainted 5.1.0+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622 __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310 rt2500usb_regbusy_read drivers/net/wireless/ralink/rt2x00/rt2500usb.c:116 [inline] rt2500usb_bbp_read+0x174/0x640 drivers/net/wireless/ralink/rt2x00/rt2500usb.c:172 rt2500usb_validate_eeprom drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1387 [inline] rt2500usb_probe_hw+0x3b1/0x2230 drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1764 rt2x00lib_probe_dev+0xb81/0x3090 drivers/net/wireless/ralink/rt2x00/rt2x00dev.c:1427 rt2x00usb_probe+0x7c7/0xf70 drivers/net/wireless/ralink/rt2x00/rt2x00usb.c:837 rt2500usb_probe+0x50/0x60 drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1977 usb_probe_interface+0xd66/0x1320 drivers/usb/core/driver.c:361 really_probe+0xdae/0x1d80 drivers/base/dd.c:513 driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454 __device_attach+0x454/0x730 drivers/base/dd.c:844 device_initial_probe+0x4a/0x60 drivers/base/dd.c:891 bus_probe_device+0x137/0x390 drivers/base/bus.c:514 device_add+0x288d/0x30e0 drivers/base/core.c:2106 usb_set_configuration+0x30dc/0x3750 drivers/usb/core/message.c:2027 generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210 usb_probe_device+0x14c/0x200 drivers/usb/core/driver.c:266 really_probe+0xdae/0x1d80 drivers/base/dd.c:513 driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454 __device_attach+0x454/0x730 drivers/base/dd.c:844 device_initial_probe+0x4a/0x60 drivers/base/dd.c:891 bus_probe_device+0x137/0x390 drivers/base/bus.c:514 device_add+0x288d/0x30e0 drivers/base/core.c:2106 usb_new_device+0x23e5/0x2ff0 drivers/usb/core/hub.c:2534 hub_port_connect drivers/usb/core/hub.c:5089 [inline] hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] port_event drivers/usb/core/hub.c:5350 [inline] hub_event+0x48d1/0x7290 drivers/usb/core/hub.c:5432 process_one_work+0x1572/0x1f00 kernel/workqueue.c:2269 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415 kthread+0x4b5/0x4f0 kernel/kthread.c:254 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Local variable description: reg.i.i@rt2500usb_bbp_read Variable was created at: rt2500usb_register_read_lock drivers/net/wireless/ralink/rt2x00/rt2500usb.c:72 [inline] rt2500usb_regbusy_read drivers/net/wireless/ralink/rt2x00/rt2500usb.c:115 [inline] rt2500usb_bbp_read+0xa4/0x640 drivers/net/wireless/ralink/rt2x00/rt2500usb.c:172 rt2500usb_validate_eeprom drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1387 [inline] rt2500usb_probe_hw+0x3b1/0x2230 drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1764 == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.
[PATCH 04/10] vfs: Add a mount-notification facility [ver #3]
Add a mount notification facility whereby notifications about changes in
mount topology and configuration can be received. Note that this only
covers vfsmount topology changes and not superblock events. A separate
facility will be added for that.
Firstly, an event queue needs to be created:
fd = open("/dev/event_queue", O_RDWR);
ioctl(fd, IOC_WATCH_QUEUE_SET_SIZE, page_size << n);
then a notification can be set up to report notifications via that queue:
struct watch_notification_filter filter = {
.nr_filters = 1,
.filters = {
[0] = {
.type = WATCH_TYPE_MOUNT_NOTIFY,
.subtype_filter[0] = UINT_MAX,
},
},
};
ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter);
mount_notify(AT_FDCWD, "/", 0, fd, 0x02);
In this case, it would let me monitor the mount topology subtree rooted at
"/" for events. Mount notifications propagate up the tree towards the
root, so a watch will catch all of the events happening in the subtree
rooted at the watch.
After setting the watch, records will be placed into the queue when, for
example, as superblock switches between read-write and read-only. Records
are of the following format:
struct mount_notification {
struct watch_notification watch;
__u32 triggered_on;
__u32 changed_mount;
} *n;
Where:
n->watch.type will be WATCH_TYPE_MOUNT_NOTIFY.
n->watch.subtype will indicate the type of event, such as
NOTIFY_MOUNT_NEW_MOUNT.
n->watch.info & WATCH_INFO_LENGTH will indicate the length of the
record.
n->watch.info & WATCH_INFO_ID will be the fifth argument to
mount_notify(), shifted.
n->watch.info & WATCH_INFO_FLAG_0 will be used for
NOTIFY_MOUNT_READONLY, being set if the superblock becomes R/O, and
being cleared otherwise, and for NOTIFY_MOUNT_NEW_MOUNT, being set
if the new mount is a submount (e.g. an automount).
n->triggered_on indicates the ID of the mount on which the watch
was installed.
n->changed_mount indicates the ID of the mount that was affected.
The mount IDs can be retrieved with the fsinfo() syscall, using the
fsinfo_mount_info and fsinfo_mount_child attributes. There are
notification counters there too for when a buffer overrun occurs, thereby
allowing the mount tree to be quickly rescanned.
Note that it is permissible for event records to be of variable length -
or, at least, the length may be dependent on the subtype. Note also that
the queue can be shared between multiple notifications of various types.
Signed-off-by: David Howells
---
arch/x86/entry/syscalls/syscall_32.tbl |1
arch/x86/entry/syscalls/syscall_64.tbl |1
fs/Kconfig |9 ++
fs/Makefile|1
fs/mount.h | 33 --
fs/mount_notify.c | 180
fs/namespace.c |9 +-
include/linux/dcache.h |1
include/linux/syscalls.h |2
include/uapi/linux/watch_queue.h | 24
kernel/sys_ni.c|3 +
11 files changed, 250 insertions(+), 14 deletions(-)
create mode 100644 fs/mount_notify.c
diff --git a/arch/x86/entry/syscalls/syscall_32.tbl
b/arch/x86/entry/syscalls/syscall_32.tbl
index 03decae51513..a8416a9a0ccb 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -439,3 +439,4 @@
432i386fsmount sys_fsmount
__ia32_sys_fsmount
433i386fspick sys_fspick
__ia32_sys_fspick
434i386fsinfo sys_fsinfo
__ia32_sys_fsinfo
+435i386mount_notifysys_mount_notify
__ia32_sys_mount_notify
diff --git a/arch/x86/entry/syscalls/syscall_64.tbl
b/arch/x86/entry/syscalls/syscall_64.tbl
index ea63df9a1020..ea052a94eb97 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@ -356,6 +356,7 @@
432common fsmount __x64_sys_fsmount
433common fspick __x64_sys_fspick
434common fsinfo __x64_sys_fsinfo
+435common mount_notify__x64_sys_mount_notify
#
# x32-specific system call numbers start at 512 to avoid cache impact
diff --git a/fs/Kconfig b/fs/Kconfig
index 9e7d2f2c0111..a26bbe27a791 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -121,6 +121,15 @@ source "fs/crypto/Kconfig"
source "fs/notify/Kconfig"
+config MOUNT_NOTIFICATIONS
+ bool "Mount topology change notifications"
+ select WATCH_QUEUE
+ help
+ This option provid
Re: single copy atomicity for double load/stores on 32-bit systems
On Tue, Jun 04, 2019 at 09:41:04AM +0200, Geert Uytterhoeven wrote:
> Hi Paul,
>
> On Mon, Jun 3, 2019 at 10:14 PM Paul E. McKenney
> wrote:
> > On Mon, Jun 03, 2019 at 06:08:35PM +, Vineet Gupta wrote:
> > > On 5/31/19 1:21 AM, Peter Zijlstra wrote:
> > > >> I'm not sure how to interpret "natural alignment" for the case of
> > > >> double
> > > >> load/stores on 32-bit systems where the hardware and ABI allow for 4
> > > >> byte
> > > >> alignment (ARCv2 LDD/STD, ARM LDRD/STRD )
> > > > Natural alignment: !((uintptr_t)ptr % sizeof(*ptr))
> > > >
> > > > For any u64 type, that would give 8 byte alignment. the problem
> > > > otherwise being that your data spans two lines/pages etc..
> > >
> > > Sure, but as Paul said, if the software doesn't expect them to be atomic
> > > by
> > > default, they could span 2 hardware lines to keep the implementation
> > > simpler/sane.
> >
> > I could imagine 8-byte types being only four-byte aligned on 32-bit systems,
> > but it would be quite a surprise on 64-bit systems.
>
> Or two-byte aligned?
>
> M68k started with a 16-bit data bus, and alignment rules were retained
> when gaining a wider data bus.
>
> BTW, do any platforms have issues with atomicity of 4-byte types on
> 16-bit data buses? I believe some embedded ARM or PowerPC do have
> such buses.
But m68k is !SMP-only, correct? If so, the only issues would be
interactions with interrupt handlers and the like, and doesn't current
m68k hardware use exact interrupts? Or is it still possible to interrupt
an m68k in the middle of an instruction like it was in the bad old days?
Thanx, Paul
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
