[PATCH net-next 7/7] net: hns3: Cleanup for non-static function in hns3 driver
This patch fixes the following warning from sparse:
warning: symbol 'hns3_set_multicast_list' was not declared.
Should it be static.
hns3_set_multicast_list turns out to be not used, so delete it.
Signed-off-by: Yunsheng Lin
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 4 ++--
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 14 +++---
.../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 20
.../ethernet/hisilicon/hns3/hns3pf/hns3_ethtool.c| 4 ++--
4 files changed, 15 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 05985d8..8ecd807 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -276,8 +276,8 @@ int hclge_cmd_send(struct hclge_hw *hw, struct hclge_desc
*desc, int num)
return retval;
}
-enum hclge_cmd_status hclge_cmd_query_firmware_version(struct hclge_hw *hw,
- u32 *version)
+static enum hclge_cmd_status hclge_cmd_query_firmware_version(
+ struct hclge_hw *hw, u32 *version)
{
struct hclge_query_version_cmd *resp;
struct hclge_desc desc;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 6115c2f..c91c779 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -1550,8 +1550,8 @@ static int hclge_tx_buffer_calc(struct hclge_dev *hdev,
* @buf_alloc: pointer to buffer calculation data
* @return: 0: calculate sucessful, negative: fail
*/
-int hclge_rx_buffer_calc(struct hclge_dev *hdev,
-struct hclge_pkt_buf_alloc *buf_alloc)
+static int hclge_rx_buffer_calc(struct hclge_dev *hdev,
+ struct hclge_pkt_buf_alloc *buf_alloc)
{
u32 rx_all = hdev->pkt_buf_size;
int no_pfc_priv_num, pfc_priv_num;
@@ -2828,9 +2828,9 @@ int hclge_map_vport_ring_to_vector(struct hclge_vport
*vport, int vector_id,
return 0;
}
-int hclge_map_handle_ring_to_vector(struct hnae3_handle *handle,
- int vector,
- struct hnae3_ring_chain_node *ring_chain)
+static int hclge_map_handle_ring_to_vector(
+ struct hnae3_handle *handle, int vector,
+ struct hnae3_ring_chain_node *ring_chain)
{
struct hclge_vport *vport = hclge_get_vport(handle);
struct hclge_dev *hdev = vport->back;
@@ -3206,8 +3206,8 @@ static void hclge_prepare_mac_addr(struct
hclge_mac_vlan_tbl_entry_cmd *new_req,
new_req->mac_addr_lo16 = cpu_to_le16(low_val & 0x);
}
-u16 hclge_get_mac_addr_to_mta_index(struct hclge_vport *vport,
- const u8 *addr)
+static u16 hclge_get_mac_addr_to_mta_index(struct hclge_vport *vport,
+ const u8 *addr)
{
u16 high_val = addr[1] | (addr[0] << 8);
struct hclge_dev *hdev = vport->back;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
index aa73855..26bbc91 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -24,7 +24,7 @@
#include "hnae3.h"
#include "hns3_enet.h"
-const char hns3_driver_name[] = "hns3";
+static const char hns3_driver_name[] = "hns3";
const char hns3_driver_version[] = VERMAGIC_STRING;
static const char hns3_driver_string[] =
"Hisilicon Ethernet Network Driver for Hip08 Family";
@@ -304,18 +304,6 @@ static int hns3_nic_net_stop(struct net_device *netdev)
return 0;
}
-void hns3_set_multicast_list(struct net_device *netdev)
-{
- struct hnae3_handle *h = hns3_get_handle(netdev);
- struct netdev_hw_addr *ha = NULL;
-
- if (h->ae_algo->ops->set_mc_addr) {
- netdev_for_each_mc_addr(ha, netdev)
- if (h->ae_algo->ops->set_mc_addr(h, ha->addr))
- netdev_err(netdev, "set multicast fail\n");
- }
-}
-
static int hns3_nic_uc_sync(struct net_device *netdev,
const unsigned char *addr)
{
@@ -360,7 +348,7 @@ static int hns3_nic_mc_unsync(struct net_device *netdev,
return 0;
}
-void hns3_nic_set_rx_mode(struct net_device *netdev)
+static void hns3_nic_set_rx_mode(struct net_device *netdev)
{
struct hnae3_handle *h = hns3_get_handle(netdev);
@@ -2596,7 +2584,7 @@ static void hns3_fini_ring(struct hns3_enet_ring *ring)
ring->next_to_use = 0;
}
-int hns3_buf_size2type(u32 buf_size)
+static int hns3_buf_size2type(u32 buf_size)
{
int bd_size_type;
@@ -2908,7 +2896,7 @@ static int hns3_client_s
Re: [PATCH] leds: tca6507: Remove unnecessary reg check
On Sun 2017-10-08 19:55:05, Christos Gkekas wrote: > Variable reg is unsigned so checking whether it is less than zero is not > necessary. > > Signed-off-by: Christos Gkekas Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH net-next 6/7] net: hns3: Cleanup for endian issue in hns3 driver
This patch fixes a lot of endian issues detected by sparse.
Signed-off-by: Yunsheng Lin
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 8 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 10 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 206 -
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 26 ++-
.../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 4 +-
5 files changed, 145 insertions(+), 109 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 648b64b..05985d8 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -208,7 +208,7 @@ int hclge_cmd_send(struct hclge_hw *hw, struct hclge_desc
*desc, int num)
* which will be use for hardware to write back
*/
ntc = hw->cmq.csq.next_to_use;
- opcode = desc[0].opcode;
+ opcode = le16_to_cpu(desc[0].opcode);
while (handle < num) {
desc_to_use = &hw->cmq.csq.desc[hw->cmq.csq.next_to_use];
*desc_to_use = desc[handle];
@@ -225,7 +225,7 @@ int hclge_cmd_send(struct hclge_hw *hw, struct hclge_desc
*desc, int num)
* If the command is sync, wait for the firmware to write back,
* if multi descriptors to be sent, use the first one to check
*/
- if (HCLGE_SEND_SYNC(desc->flag)) {
+ if (HCLGE_SEND_SYNC(le16_to_cpu(desc->flag))) {
do {
if (hclge_cmd_csq_done(hw))
break;
@@ -244,9 +244,9 @@ int hclge_cmd_send(struct hclge_hw *hw, struct hclge_desc
*desc, int num)
pr_debug("Get cmd desc:\n");
if (likely(!hclge_is_special_opcode(opcode)))
- desc_ret = desc[handle].retval;
+ desc_ret = le16_to_cpu(desc[handle].retval);
else
- desc_ret = desc[0].retval;
+ desc_ret = le16_to_cpu(desc[0].retval);
if ((enum hclge_cmd_return_status)desc_ret ==
HCLGE_CMD_EXEC_SUCCESS)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index d2ff0e3..8f3ba02a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -434,8 +434,8 @@ struct hclge_rss_input_tuple_cmd {
#define HCLGE_RSS_CFG_TBL_SIZE 16
struct hclge_rss_indirection_table_cmd {
- u16 start_table_index;
- u16 rss_set_bitmap;
+ __le16 start_table_index;
+ __le16 rss_set_bitmap;
u8 rsv[4];
u8 rss_result[HCLGE_RSS_CFG_TBL_SIZE];
};
@@ -446,7 +446,7 @@ struct hclge_rss_indirection_table_cmd {
#define HCLGE_RSS_TC_SIZE_MGENMASK(14, 12)
#define HCLGE_RSS_TC_VALID_B 15
struct hclge_rss_tc_mode_cmd {
- u16 rss_tc_mode[HCLGE_MAX_TC_NUM];
+ __le16 rss_tc_mode[HCLGE_MAX_TC_NUM];
u8 rsv[8];
};
@@ -601,7 +601,7 @@ struct hclge_cfg_func_mta_filter_cmd {
#define HCLGE_CFG_MTA_ITEM_IDX_S 0x0
#define HCLGE_CFG_MTA_ITEM_IDX_M GENMASK(11, 0)
struct hclge_cfg_func_mta_item_cmd {
- u16 item_idx; /* Only used lowest 12 bit */
+ __le16 item_idx; /* Only used lowest 12 bit */
u8 accept; /* Only used lowest 1 bit */
u8 rsv[21];
};
@@ -645,7 +645,7 @@ struct hclge_vlan_filter_pf_cfg_cmd {
};
struct hclge_vlan_filter_vf_cfg_cmd {
- u16 vlan_id;
+ __le16 vlan_id;
u8 resp_code;
u8 rsv;
u8 vlan_cfg;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 5103f23..6115c2f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -362,7 +362,7 @@ static int hclge_64_bit_update_stats(struct hclge_dev *hdev)
#define HCLGE_64_BIT_RTN_DATANUM 4
u64 *data = (u64 *)(&hdev->hw_stats.all_64_bit_stats);
struct hclge_desc desc[HCLGE_64_BIT_CMD_NUM];
- u64 *desc_data;
+ __le64 *desc_data;
int i, k, n;
int ret;
@@ -376,14 +376,14 @@ static int hclge_64_bit_update_stats(struct hclge_dev
*hdev)
for (i = 0; i < HCLGE_64_BIT_CMD_NUM; i++) {
if (unlikely(i == 0)) {
- desc_data = (u64 *)(&desc[i].data[0]);
+ desc_data = (__le64 *)(&desc[i].data[0]);
n = HCLGE_64_BIT_RTN_DATANUM - 1;
} else {
- desc_data = (u64 *)(&desc[i]);
+ desc_data = (__le64 *)(&desc[i]);
n = HCLGE_64_BIT_RTN_DATANUM;
}
[PATCH net-next 5/7] net: hns3: Cleanup for struct that used to send cmd to firmware
The hclge_tm module has already added _cmd to the end of struct
that used to send cmd to firmware. This will help us finding the
endian issues.
This patch adds the _cmd to the end of struct that used to send
cmd to firmware in hclge_main module.
Signed-off-by: Yunsheng Lin
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 4 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 72 -
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 163 +++--
3 files changed, 120 insertions(+), 119 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 8b511e6..648b64b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -279,12 +279,12 @@ int hclge_cmd_send(struct hclge_hw *hw, struct hclge_desc
*desc, int num)
enum hclge_cmd_status hclge_cmd_query_firmware_version(struct hclge_hw *hw,
u32 *version)
{
- struct hclge_query_version *resp;
+ struct hclge_query_version_cmd *resp;
struct hclge_desc desc;
int ret;
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_QUERY_FW_VER, 1);
- resp = (struct hclge_query_version *)desc.data;
+ resp = (struct hclge_query_version_cmd *)desc.data;
ret = hclge_cmd_send(hw, &desc, 1);
if (!ret)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 9cff7db..d2ff0e3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -221,12 +221,12 @@ enum hclge_opcode_type {
#define HCLGE_RCB_INIT_QUERY_TIMEOUT 10
#define HCLGE_RCB_INIT_FLAG_EN_B 0
#define HCLGE_RCB_INIT_FLAG_FINI_B 8
-struct hclge_config_rcb_init {
+struct hclge_config_rcb_init_cmd {
__le16 rcb_init_flag;
u8 rsv[22];
};
-struct hclge_tqp_map {
+struct hclge_tqp_map_cmd {
__le16 tqp_id; /* Absolute tqp id for in this pf */
u8 tqp_vf; /* VF id */
#define HCLGE_TQP_MAP_TYPE_PF 0
@@ -246,7 +246,7 @@ enum hclge_int_type {
HCLGE_INT_EVENT,
};
-struct hclge_ctrl_vector_chain {
+struct hclge_ctrl_vector_chain_cmd {
u8 int_vector_id;
u8 int_cause_num;
#define HCLGE_INT_TYPE_S 0
@@ -263,18 +263,18 @@ struct hclge_ctrl_vector_chain {
#define HCLGE_TC_NUM 8
#define HCLGE_TC0_PRI_BUF_EN_B 15 /* Bit 15 indicate enable or not */
#define HCLGE_BUF_UNIT_S 7 /* Buf size is united by 128 bytes */
-struct hclge_tx_buff_alloc {
+struct hclge_tx_buff_alloc_cmd {
__le16 tx_pkt_buff[HCLGE_TC_NUM];
u8 tx_buff_rsv[8];
};
-struct hclge_rx_priv_buff {
+struct hclge_rx_priv_buff_cmd {
__le16 buf_num[HCLGE_TC_NUM];
__le16 shared_buf;
u8 rsv[6];
};
-struct hclge_query_version {
+struct hclge_query_version_cmd {
__le32 firmware;
__le32 firmware_rsv[5];
};
@@ -328,14 +328,14 @@ struct hclge_pkt_buf_alloc {
};
#define HCLGE_RX_COM_WL_EN_B 15
-struct hclge_rx_com_wl_buf {
+struct hclge_rx_com_wl_buf_cmd {
__le16 high_wl;
__le16 low_wl;
u8 rsv[20];
};
#define HCLGE_RX_PKT_EN_B 15
-struct hclge_rx_pkt_buf {
+struct hclge_rx_pkt_buf_cmd {
__le16 high_pkt;
__le16 low_pkt;
u8 rsv[20];
@@ -348,7 +348,7 @@ struct hclge_rx_pkt_buf {
#define HCLGE_PF_MAC_NUM_MASK 0x3
#define HCLGE_PF_STATE_MAINBIT(HCLGE_PF_STATE_MAIN_B)
#define HCLGE_PF_STATE_DONEBIT(HCLGE_PF_STATE_DONE_B)
-struct hclge_func_status {
+struct hclge_func_status_cmd {
__le32 vf_rst_state[4];
u8 pf_state;
u8 mac_id;
@@ -359,7 +359,7 @@ struct hclge_func_status {
u8 rsv[2];
};
-struct hclge_pf_res {
+struct hclge_pf_res_cmd {
__le16 tqp_num;
__le16 buf_size;
__le16 msixcap_localid_ba_nic;
@@ -395,7 +395,7 @@ struct hclge_pf_res {
#define HCLGE_CFG_DEFAULT_SPEED_S 16
#define HCLGE_CFG_DEFAULT_SPEED_M GENMASK(23, 16)
-struct hclge_cfg_param {
+struct hclge_cfg_param_cmd {
__le32 offset;
__le32 rsv;
__le32 param[4];
@@ -405,7 +405,7 @@ struct hclge_cfg_param {
#define HCLGE_DESC_NUM 0x40
#define HCLGE_ALLOC_VALID_B0
-struct hclge_vf_num {
+struct hclge_vf_num_cmd {
u8 alloc_valid;
u8 rsv[23];
};
@@ -413,13 +413,13 @@ struct hclge_vf_num {
#define HCLGE_RSS_DEFAULT_OUTPORT_B4
#define HCLGE_RSS_HASH_KEY_OFFSET_B4
#define HCLGE_RSS_HASH_KEY_NUM 16
-struct hclge_rss_config {
+struct hclge_rss_config_cmd {
u8 hash_config;
u8 rsv[7];
u8 hash_key[HCLGE_RSS_HASH_KEY_NUM];
};
-struct hclge_rss_input_tuple {
+struct hclge_rss_input_tuple_cmd {
u8 ipv4_tcp_en;
u8 ipv4_udp_en;
u8 ipv4_sctp_en;
@@ -433,7 +433
[PATCH net-next 3/7] net: hns3: Cleanup indentation for Kconfig in the the hisilicon folder
This patch fixes a few indentation for Kconfig file in the hisilicon folder. Signed-off-by: Yunsheng Lin --- drivers/net/ethernet/hisilicon/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/Kconfig b/drivers/net/ethernet/hisilicon/Kconfig index 9d7cb03..3b6 100644 --- a/drivers/net/ethernet/hisilicon/Kconfig +++ b/drivers/net/ethernet/hisilicon/Kconfig @@ -78,7 +78,7 @@ config HNS_ENET config HNS3 tristate "Hisilicon Network Subsystem Support HNS3 (Framework)" -depends on PCI + depends on PCI ---help--- This selects the framework support for Hisilicon Network Subsystem 3. This layer facilitates clients like ENET, RoCE and user-space ethernet @@ -87,7 +87,7 @@ config HNS3 config HNS3_HCLGE tristate "Hisilicon HNS3 HCLGE Acceleration Engine & Compatibility Layer Support" -depends on PCI_MSI + depends on PCI_MSI depends on HNS3 ---help--- This selects the HNS3_HCLGE network acceleration engine & its hardware @@ -96,7 +96,7 @@ config HNS3_HCLGE config HNS3_ENET tristate "Hisilicon HNS3 Ethernet Device Support" -depends on 64BIT && PCI + depends on 64BIT && PCI depends on HNS3 && HNS3_HCLGE ---help--- This selects the Ethernet Driver for Hisilicon Network Subsystem 3 for hip08 -- 1.9.1
[PATCH net-next 4/7] net: hns3: Consistently using GENMASK in hns3 driver
This patch uses GENMASK to generate bit mask whenever
possible in hns3 driver.
Signed-off-by: Yunsheng Lin
---
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 48 +++---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 4 +-
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 6b6d28e..9cff7db 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -250,11 +250,11 @@ struct hclge_ctrl_vector_chain {
u8 int_vector_id;
u8 int_cause_num;
#define HCLGE_INT_TYPE_S 0
-#define HCLGE_INT_TYPE_M 0x3
+#define HCLGE_INT_TYPE_M GENMASK(1, 0)
#define HCLGE_TQP_ID_S 2
-#define HCLGE_TQP_ID_M (0x7ff << HCLGE_TQP_ID_S)
+#define HCLGE_TQP_ID_M GENMASK(12, 2)
#define HCLGE_INT_GL_IDX_S 13
-#define HCLGE_INT_GL_IDX_M (0x3 << HCLGE_INT_GL_IDX_S)
+#define HCLGE_INT_GL_IDX_M GENMASK(14, 13)
__le16 tqp_type_and_id[HCLGE_VECTOR_ELEMENTS_PER_CMD];
u8 vfid;
u8 rsv;
@@ -372,28 +372,28 @@ struct hclge_pf_res {
};
#define HCLGE_CFG_OFFSET_S 0
-#define HCLGE_CFG_OFFSET_M 0xf /* Byte (8-10.3) */
+#define HCLGE_CFG_OFFSET_M GENMASK(19, 0)
#define HCLGE_CFG_RD_LEN_S 24
-#define HCLGE_CFG_RD_LEN_M (0xf << HCLGE_CFG_RD_LEN_S)
+#define HCLGE_CFG_RD_LEN_M GENMASK(27, 24)
#define HCLGE_CFG_RD_LEN_BYTES 16
#define HCLGE_CFG_RD_LEN_UNIT 4
#define HCLGE_CFG_VMDQ_S 0
-#define HCLGE_CFG_VMDQ_M (0xff << HCLGE_CFG_VMDQ_S)
+#define HCLGE_CFG_VMDQ_M GENMASK(7, 0)
#define HCLGE_CFG_TC_NUM_S 8
-#define HCLGE_CFG_TC_NUM_M (0xff << HCLGE_CFG_TC_NUM_S)
+#define HCLGE_CFG_TC_NUM_M GENMASK(15, 8)
#define HCLGE_CFG_TQP_DESC_N_S 16
-#define HCLGE_CFG_TQP_DESC_N_M (0x << HCLGE_CFG_TQP_DESC_N_S)
+#define HCLGE_CFG_TQP_DESC_N_M GENMASK(31, 16)
#define HCLGE_CFG_PHY_ADDR_S 0
-#define HCLGE_CFG_PHY_ADDR_M (0x1f << HCLGE_CFG_PHY_ADDR_S)
+#define HCLGE_CFG_PHY_ADDR_M GENMASK(4, 0)
#define HCLGE_CFG_MEDIA_TP_S 8
-#define HCLGE_CFG_MEDIA_TP_M (0xff << HCLGE_CFG_MEDIA_TP_S)
+#define HCLGE_CFG_MEDIA_TP_M GENMASK(15, 8)
#define HCLGE_CFG_RX_BUF_LEN_S 16
-#define HCLGE_CFG_RX_BUF_LEN_M (0x << HCLGE_CFG_RX_BUF_LEN_S)
+#define HCLGE_CFG_RX_BUF_LEN_M GENMASK(31, 16)
#define HCLGE_CFG_MAC_ADDR_H_S 0
-#define HCLGE_CFG_MAC_ADDR_H_M (0x << HCLGE_CFG_MAC_ADDR_H_S)
+#define HCLGE_CFG_MAC_ADDR_H_M GENMASK(15, 0)
#define HCLGE_CFG_DEFAULT_SPEED_S 16
-#define HCLGE_CFG_DEFAULT_SPEED_M (0xff << HCLGE_CFG_DEFAULT_SPEED_S)
+#define HCLGE_CFG_DEFAULT_SPEED_M GENMASK(23, 16)
struct hclge_cfg_param {
__le32 offset;
@@ -441,9 +441,9 @@ struct hclge_rss_indirection_table {
};
#define HCLGE_RSS_TC_OFFSET_S 0
-#define HCLGE_RSS_TC_OFFSET_M (0x3ff << HCLGE_RSS_TC_OFFSET_S)
+#define HCLGE_RSS_TC_OFFSET_M GENMASK(9, 0)
#define HCLGE_RSS_TC_SIZE_S12
-#define HCLGE_RSS_TC_SIZE_M(0x7 << HCLGE_RSS_TC_SIZE_S)
+#define HCLGE_RSS_TC_SIZE_MGENMASK(14, 12)
#define HCLGE_RSS_TC_VALID_B 15
struct hclge_rss_tc_mode {
u16 rss_tc_mode[HCLGE_MAX_TC_NUM];
@@ -501,7 +501,7 @@ struct hclge_config_mac_mode {
};
#define HCLGE_CFG_SPEED_S 0
-#define HCLGE_CFG_SPEED_M (0x3f << HCLGE_CFG_SPEED_S)
+#define HCLGE_CFG_SPEED_M GENMASK(5, 0)
#define HCLGE_CFG_DUPLEX_B 7
#define HCLGE_CFG_DUPLEX_M BIT(HCLGE_CFG_DUPLEX_B)
@@ -518,7 +518,7 @@ struct hclge_config_mac_speed_dup {
#define HCLGE_QUERY_AN_B 0
#define HCLGE_QUERY_DUPLEX_B 2
-#define HCLGE_QUERY_SPEED_M(0x1f << HCLGE_QUERY_SPEED_S)
+#define HCLGE_QUERY_SPEED_MGENMASK(4, 0)
#define HCLGE_QUERY_AN_M BIT(HCLGE_QUERY_AN_B)
#define HCLGE_QUERY_DUPLEX_M BIT(HCLGE_QUERY_DUPLEX_B)
@@ -528,7 +528,7 @@ struct hclge_query_an_speed_dup {
u8 rsv[23];
};
-#define HCLGE_RING_ID_MASK 0x3ff
+#define HCLGE_RING_ID_MASK GENMASK(9, 0)
#define HCLGE_TQP_ENABLE_B 0
#define HCLGE_MAC_CFG_AN_EN_B 0
@@ -565,9 +565,9 @@ enum hclge_mac_vlan_tbl_opcode {
#define HCLGE_MAC_EPORT_SW_EN_B0xc
#define HCLGE_MAC_EPORT_TYPE_B 0xb
#define HCLGE_MAC_EPORT_VFID_S 0x3
-#define HCLGE_MAC_EPORT_VFID_M (0xff << HCLGE_MAC_EPORT_VFID_S)
+#define HCLGE_MAC_EPORT_VFID_M GENMASK(10, 3)
#define HCLGE_MAC_EPORT_PFID_S 0x0
-#define HCLGE_MAC_EPORT_PFID_M (0x7 << HCLGE_MAC_EPORT_PFID_S)
+#define HCLGE_MAC_EPORT_PFID_M GENMASK(2, 0)
struct hclge_mac_vlan_tbl_entry {
u8 flags;
u8 resp_code;
@@ -583,7 +583,7 @@ struct hclge_mac_vlan_tbl_entry {
};
#define HCLGE_CFG_MTA_MAC
Re: [PATCH 1/3] mmc: dw_mmc: cancel the CTO timer after a voltage switch
On 2017/9/28 4:56, Douglas Anderson wrote:
When running with the commit 03de19212ea3 ("mmc: dw_mmc: introduce
timer for broken command transfer over scheme") I found this message
in the log:
Unexpected command timeout, state 7
It turns out that we weren't properly cancelling the new CTO timer in
the case that a voltage switch was done. Let's promote the cancel
into the dw_mci_cmd_interrupt() function to fix this.
Reviewed-by: Shawn Lin
Fixes: 03de19212ea3 ("mmc: dw_mmc: introduce timer for broken command transfer over
scheme")
Signed-off-by: Douglas Anderson
---
drivers/mmc/host/dw_mmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 860313bd952a..f5b2bb4b4d98 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2570,6 +2570,8 @@ static void dw_mci_write_data_pio(struct dw_mci *host)
static void dw_mci_cmd_interrupt(struct dw_mci *host, u32 status)
{
+ del_timer(&host->cto_timer);
+
if (!host->cmd_status)
host->cmd_status = status;
@@ -2662,7 +2664,6 @@ static irqreturn_t dw_mci_interrupt(int irq, void *dev_id)
}
if (pending & SDMMC_INT_CMD_DONE) {
- del_timer(&host->cto_timer);
mci_writel(host, RINTSTS, SDMMC_INT_CMD_DONE);
dw_mci_cmd_interrupt(host, pending);
}
Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework
On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote: > On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote: > > On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote: > > > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote: > > > > Hello, > > > > > > > > One thing that comes up a lot every LSF is the fact that we have no > > > > general way > > > > that we do performance testing. Every fs developer has a set of > > > > scripts or > > > > things that they run with varying degrees of consistency, but nothing > > > > central > > > > that we all use. I for one am getting tired of finding regressions > > > > when we are > > > > deploying new kernels internally, so I wired this thing up to try and > > > > address > > > > this need. > > > > > > > > We all hate convoluted setups, the more brain power we have to put in > > > > to setting > > > > something up the less likely we are to use it, so I took the xfstests > > > > approach > > > > of making it relatively simple to get running and relatively easy to > > > > add new > > > > tests. For right now the only thing this framework does is run fio > > > > scripts. I > > > > chose fio because it already gathers loads of performance data about > > > > it's runs. > > > > We have everything we need there, latency, bandwidth, cpu time, and all > > > > broken > > > > down by reads, writes, and trims. I figure most of us are familiar > > > > enough with > > > > fio and how it works to make it relatively easy to add new tests to the > > > > framework. > > > > > > > > I've posted my code up on github, you can get it here > > > > > > > > https://github.com/josefbacik/fsperf > > > > > > > > All (well most) of the results from fio are stored in a local sqlite > > > > database. > > > > Right now the comparison stuff is very crude, it simply checks against > > > > the > > > > previous run and it only checks a few of the keys by default. You can > > > > check > > > > latency if you want, but while writing this stuff up it seemed that > > > > latency was > > > > too variable from run to run to be useful in a "did my thing regress or > > > > improve" > > > > sort of way. > > > > > > > > The configuration is brain dead simple, the README has examples. All > > > > you need > > > > to do is make your local.cfg, run ./setup and then run ./fsperf and you > > > > are good > > > > to go. > > > > > > Why re-invent the test infrastructure? Why not just make it a > > > tests/perf subdir in fstests? > > > > > > > Probably should have led with that shouldn't I have? There's nothing > > keeping me > > from doing it, but I didn't want to try and shoehorn in a python thing into > > fstests. I need python to do the sqlite and the json parsing to dump into > > the > > sqlite database. > > > > Now if you (and others) are not opposed to this being dropped into > > tests/perf > > then I'll work that up. But it's definitely going to need to be done in > > python. > > I know you yourself have said you aren't opposed to using python in the > > past, so > > if that's still the case then I can definitely wire it all up. > > I have no problems with people using python for stuff like this but, > OTOH, I'm not the fstests maintainer anymore :P I have no problem either if python is really needed, after all this is a very useful infrastructure improvement. But the python version problem brought up by Ted made me a bit nervous, we need to work that round carefully. OTOH, I'm just curious, what is the specific reason that python is a hard requirement? If we can use perl, that'll be much easier for fstests. BTW, opinions from key fs developers/fstests users, like you, are also very important and welcomed :) Thanks, Eryu > > > > > The plan is to add lots of workloads as we discover regressions and > > > > such. We > > > > don't want anything that takes too long to run otherwise people won't > > > > run this, > > > > so the existing tests don't take much longer than a few minutes each. > > > > I will be > > > > adding some more comparison options so you can compare against averages > > > > of all > > > > previous runs and such. > > > > > > Yup, that fits exactly into what fstests is for... :P > > > > > > Integrating into fstests means it will be immediately available to > > > all fs developers, it'll run on everything that everyone already has > > > setup for filesystem testing, and it will have familiar mkfs/mount > > > option setup behaviour so there's no new hoops for everyone to jump > > > through to run it... > > > > > > > TBF I specifically made it as easy as possible because I know we all hate > > trying > > to learn new shit. > > Yeah, it's also hard to get people to change their workflows to add > a whole new test harness into them. It's easy if it's just a new > command to an existing workflow :P > > > I figured this was different enough to warrant a separate > > project, especially since I'm going to add block
Re: [PATCH v2 0/5] Switch arm64 over to qrwlock
On Mon, Oct 09, 2017 at 12:30:52AM +0300, Yury Norov wrote: > The bottomline of discussion [1] was that queued locks are more > effective when SoC has many CPUs. And 4 is not many. qspinlock, yes. qrwlock not, as it fully depends on arch_spinlock_t for the queueing. qrwlock is just a generic rwlock_t implementation.
Re: [PATCH] drm/rockchip: Fix memory leak in rockchip_drm_sys_resume()
Hi Sean, On 09/28/2017 11:16 AM, jeffy wrote: Hi Sean, On 09/28/2017 04:27 AM, Sean Paul wrote: >@@ -299,6 +300,7 @@ static int rockchip_drm_sys_resume(struct device *dev) > > priv = drm->dev_private; > drm_atomic_helper_resume(drm, priv->state); >+drm_atomic_state_put(priv->state); Won't this be freed for you eventually in commit_tail()? i think the drm_atomic_state_put in commit_tail is paired to the drm_atomic_state_get in drm_atomic_helper_commit. and the kmemleak shows(after a few suspend/resume): unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c [] create_object+0x138/0x254 [] kmemleak_alloc+0x58/0x8c [] __kmalloc+0x1d4/0x2a0 [] usb_alloc_urb+0x30/0x60 [] alloc_ctrl_urb+0x38/0x120 [btusb] [] btusb_send_frame+0x64/0xf8 [btusb] oops, the log is wrong... it should be: unreferenced object 0xffc0c75fe600 (size 256): comm "bash", pid 168, jiffies 4294748032 (age 557.932s) hex dump (first 32 bytes): e0 4a 02 ce c0 ff ff ff 00 98 f2 c8 c0 ff ff ff .J.. 00 98 f2 c8 c0 ff ff ff 00 45 9f cb c0 ff ff ff .E.. backtrace: [] kmemleak_alloc+0x58/0x8c [] __kmalloc+0x1dc/0x2d4 [] drm_atomic_state_init+0xb8/0x114 [] drm_atomic_state_alloc+0x70/0xa4 [] drm_atomic_helper_duplicate_state+0x94/0x210 [] drm_atomic_helper_suspend+0xb4/0x160 [] rockchip_drm_sys_suspend+0x5c/0xa0 [] platform_pm_suspend+0x58/0x74 [] dpm_run_callback+0x13c/0x2f0 [] __device_suspend+0x28c/0x3fc [] dpm_suspend+0x1cc/0x50c [] dpm_suspend_start+0x8c/0xa4 [] suspend_devices_and_enter+0x12c/0xd84 [] pm_suspend+0xa38/0xb98 [] state_store+0xe0/0x108 [] kobj_attr_store+0x48/0x58 since it's allocated in the drm_atomic_helper_suspend(), maybe it would make more sense to unref it in drm_atomic_helper_resume(), i'll send a v2 patch for it :) checking the current code, i saw only i915/intel_display.c has this drm_atomic_state_put for the state allocated by drm_atomic_helper_suspend(), there're many drivers missing that(or maybe they free it in some other way?) Sean
Re: [RFC PATCH] mm: shm: round up tmpfs size to huge page size when huge=always
On Sun 08-10-17 15:56:51, Kirill A. Shutemov wrote: > On Sat, Oct 07, 2017 at 04:22:10AM +0800, Yang Shi wrote: > > When passing "huge=always" option for mounting tmpfs, THP is supposed to > > be allocated all the time when it can fit, but when the available space is > > smaller than the size of THP (2MB on x86), shmem fault handler still tries > > to allocate huge page every time, then fallback to regular 4K page > > allocation, i.e.: > > > > # mount -t tmpfs -o huge,size=3000k tmpfs /tmp > > # dd if=/dev/zero of=/tmp/test bs=1k count=2048 > > # dd if=/dev/zero of=/tmp/test1 bs=1k count=2048 > > > > The last dd command will handle 952 times page fault handler, then exit > > with -ENOSPC. > > > > Rounding up tmpfs size to THP size in order to use THP with "always" > > more efficiently. And, it will not wast too much memory (just allocate > > 511 extra pages in worst case). > > Hm. I don't think it's good idea to silently increase size of fs. Agreed! > Maybe better just refuse to mount with huge=always for too small fs? We cannot we simply have the remaining page !THP? What is the actual problem? -- Michal Hocko SUSE Labs
[PATCH v2] drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()
Kmemleak reported memory leak after suspend and resume:
unreferenced object 0xffc0e31d8880 (size 128):
comm "bash", pid 181, jiffies 4294763583 (age 24.694s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 20 a2 eb c0 ff ff ff . ..
01 00 00 00 00 00 00 00 80 87 1d e3 c0 ff ff ff
backtrace:
[] __save_stack_trace+0x48/0x6c
[] create_object+0x138/0x254
[] kmemleak_alloc+0x58/0x8c
[] kmem_cache_alloc_trace+0x188/0x254
[] drm_atomic_state_alloc+0x3c/0x88
[] drm_atomic_helper_duplicate_state+0x28/0x158
[] drm_atomic_helper_suspend+0x5c/0xf0
Problem here is that we are duplicating the drm_atomic_state in
drm_atomic_helper_suspend(), but not unreference it in the resume path.
Fixes: 1494276000db ("drm/atomic-helper: Implement subsystem-level
suspend/resume")
Signed-off-by: Jeffy Chen
---
Changes in v2:
Unref duplicated drm_atomic_state in drm_atomic_helper_resume() instead
of specific drivers.
drivers/gpu/drm/drm_atomic_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 01c34bc5b5b0..4a262380c631 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3052,6 +3052,7 @@ int drm_atomic_helper_resume(struct drm_device *dev,
drm_modeset_backoff(&ctx);
}
+ drm_atomic_state_put(state);
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
--
2.11.0
[PATCH] powerpc/powernv: Add kernel cmdline parameter to disable imc
Add a kernel command line parameter option to disable In-Memory Collection
(IMC) counters and add documentation. This helps in debug.
Signed-off-by: Anju T Sudhakar
Reviewed-By: Madhavan Srinivasan
---
Documentation/admin-guide/kernel-parameters.txt | 7 +
arch/powerpc/platforms/powernv/opal-imc.c | 35 +
2 files changed, 42 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 0549662..06a8da1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -820,6 +820,13 @@
disable_ipv6= [IPV6]
See Documentation/networking/ipv6.txt.
+ disable_imc=[PPC]
+ Format {nest | core | all}
+ Disable imc counters during boot.
+ nest- Disable nest-imc counters.
+ core- Disable core and thread imc counters.
+ all-- Disable nest, core and thread imc counters.
+
disable_mtrr_cleanup [X86]
The kernel tries to adjust MTRR layout from continuous
to discrete, to make X server driver able to add WB
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c
b/arch/powerpc/platforms/powernv/opal-imc.c
index 21f6531..e929f33 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -22,6 +22,28 @@
#include
#include
+static bool disable_nest_imc;
+static bool disable_core_imc;
+
+/*
+ * diasble_imc=nest: skip the registration of nest pmus.
+ * disable_imc=core: skip the registration of core and thread pmus.
+ * disable_imc=all : disables nest, core and thread.
+ */
+static int __init disable_imc_counters(char *p)
+{
+ if (strncmp(p, "nest", 4) == 0)
+ disable_nest_imc = true;
+ else if (strncmp(p, "core", 4) == 0)
+ disable_core_imc = true;
+ else if (strncmp(p, "all", 3) == 0) {
+ disable_nest_imc = true;
+ disable_core_imc = true;
+ }
+ return 0;
+}
+early_param("disable_imc", disable_imc_counters);
+
/*
* imc_get_mem_addr_nest: Function to get nest counter memory region
* for each chip
@@ -169,6 +191,10 @@ static int opal_imc_counters_probe(struct platform_device
*pdev)
return -ENODEV;
}
+ /* If kernel is booted with disable_imc parameters, then return */
+ if (disable_nest_imc && disable_core_imc)
+ return -ENODEV;
+
for_each_compatible_node(imc_dev, NULL, IMC_DTB_UNIT_COMPAT) {
if (of_property_read_u32(imc_dev, "type", &type)) {
pr_warn("IMC Device without type property\n");
@@ -177,12 +203,21 @@ static int opal_imc_counters_probe(struct platform_device
*pdev)
switch (type) {
case IMC_TYPE_CHIP:
+ if (disable_nest_imc)
+ continue;
+
domain = IMC_DOMAIN_NEST;
break;
case IMC_TYPE_CORE:
+ if (disable_core_imc)
+ continue;
+
domain =IMC_DOMAIN_CORE;
break;
case IMC_TYPE_THREAD:
+ if (disable_core_imc)
+ continue;
+
domain = IMC_DOMAIN_THREAD;
break;
default:
--
2.7.4
Re: [PATCH] net/core: Fix BUG to BUG_ON conditionals.
Hi Tim,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.14-rc4 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Tim-Hansen/net-core-Fix-BUG-to-BUG_ON-conditionals/20171009-070451
config: x86_64-randconfig-s1-10091351 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/module.h:9,
from net//core/skbuff.c:41:
net//core/skbuff.c: In function '__pskb_pull_tail':
>> include/linux/compiler.h:156:2: error: expected ';' before 'if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^
include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
^~
>> net//core/skbuff.c:1884:2: note: in expansion of macro 'if'
if (!skb_has_frag_list(skb))
^~
>> include/linux/compiler.h:170:3: error: expected statement before ')' token
}))
^
include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
^~
>> net//core/skbuff.c:1884:2: note: in expansion of macro 'if'
if (!skb_has_frag_list(skb))
^~
include/linux/compiler.h:170:4: error: expected statement before ')' token
}))
^
include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
^~
>> net//core/skbuff.c:1884:2: note: in expansion of macro 'if'
if (!skb_has_frag_list(skb))
^~
--
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/module.h:9,
from net/core/skbuff.c:41:
net/core/skbuff.c: In function '__pskb_pull_tail':
>> include/linux/compiler.h:156:2: error: expected ';' before 'if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^
include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
^~
net/core/skbuff.c:1884:2: note: in expansion of macro 'if'
if (!skb_has_frag_list(skb))
^~
>> include/linux/compiler.h:170:3: error: expected statement before ')' token
}))
^
include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
^~
net/core/skbuff.c:1884:2: note: in expansion of macro 'if'
if (!skb_has_frag_list(skb))
^~
include/linux/compiler.h:170:4: error: expected statement before ')' token
}))
^
include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
^~
net/core/skbuff.c:1884:2: note: in expansion of macro 'if'
if (!skb_has_frag_list(skb))
^~
vim +156 include/linux/compiler.h
2bcd521a Steven Rostedt 2008-11-21 148
2bcd521a Steven Rostedt 2008-11-21 149 #ifdef CONFIG_PROFILE_ALL_BRANCHES
2bcd521a Steven Rostedt 2008-11-21 150 /*
2bcd521a Steven Rostedt 2008-11-21 151 * "Define 'is'", Bill Clinton
2bcd521a Steven Rostedt 2008-11-21 152 * "Define 'if'", Steven Rostedt
2bcd521a Steven Rostedt 2008-11-21 153 */
ab3c9c68 Linus Torvalds 2009-04-07 154 #define if(cond, ...) __trace_if(
(cond , ## __VA_ARGS__) )
ab3c9c68 Linus Torvalds 2009-04-07 155 #define __trace_if(cond) \
b33c8ff4 Arnd Bergmann 2016-02-12 @156 if
(__builtin_constant_p(!!(cond)) ? !!(cond) : \
2bcd521a Steven Rostedt 2008-11-21 157 ({
\
2bcd521a Steven Rostedt 2008-11-21 158 int __r;
\
2bcd521a Steven Rostedt 2008-11-21 159 static struct
ftrace_branch_data\
2bcd521a Steven Rostedt 2008-11-21 160
__attribute__((__aligned__(4)))
Re: [PATCH v2] kconfig: Remove menu_end_entry()
Hi Ulf, [auto build test ERROR on linus/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ulf-Magnusson/kconfig-Remove-menu_end_entry/20171009-140245 config: x86_64-randconfig-x018-201741 compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: make ARCH=x86_64 randconfig make ARCH=x86_64 All error/warnings (new ones prefixed by >>): scripts/kconfig/zconf.tab.o: In function `zconfparse': >> zconf.tab.c:(.text+0x9b39): undefined reference to `menu_end_entry' zconf.tab.c:(.text+0xa5a5): undefined reference to `menu_end_entry' collect2: error: ld returned 1 exit status make[2]: *** [scripts/kconfig/conf] Error 1 make[2]: Target 'oldconfig' not remade because of errors. make[1]: *** [oldconfig] Error 2 make: *** [sub-make] Error 2 -- scripts/kconfig/zconf.tab.c: In function 'zconfparse': >> scripts/kconfig/zconf.tab.c:1555:2: warning: implicit declaration of >> function 'menu_end_entry' [-Wimplicit-function-declaration] menu_end_entry(); ^~ scripts/kconfig/zconf.tab.o: In function `zconfparse': >> zconf.tab.c:(.text+0x9b39): undefined reference to `menu_end_entry' zconf.tab.c:(.text+0xa5a5): undefined reference to `menu_end_entry' collect2: error: ld returned 1 exit status make[2]: *** [scripts/kconfig/conf] Error 1 make[2]: Target 'oldnoconfig' not remade because of errors. make[1]: *** [oldnoconfig] Error 2 make: *** [sub-make] Error 2 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [alsa-devel] [PATCH] sound/pci/riptide or drivers/base/firmware: Fix a possible sleep-in-atomic bug
On Mon, 09 Oct 2017 04:13:16 +0200,
Jia-Ju Bai wrote:
>
> The riptide driver may sleep under a spinlock, and the function call path is:
> snd_riptide_prepare (acquire the spinlock)
> setsampleformat
> sendcmd
> riptide_reset
> try_to_load_firmware
> request_firmware
> _request_firmware (drivers/base/firmware_class.c)
> _request_firmware_prepare
> kzalloc(GFP_KERNEL) --> may sleep
>
> To fix it, GFP_KERNEL is replaced with GFP_ATOMIC in
> _request_firmware_prepare.
> This bug is found by my static analysis tool and my code review.
>
> Signed-off-by: Jia-Ju Bai
This doesn't happen. try_to_load_firmware() aborts before the
request_firmware() call when chip == NULL, which is the case from
sendcmd().
And, moreover, the call of request_firmware() itself inside the
spinlock would be already buggy.
thanks,
Takashi
> ---
> drivers/base/firmware_class.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 4b57cf5..d89f676 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -1138,7 +1138,7 @@ static inline void kill_pending_fw_fallback_reqs(bool
> only_kill_custom) { }
> struct firmware_buf *buf;
> int ret;
>
> - *firmware_p = firmware = kzalloc(sizeof(*firmware), GFP_KERNEL);
> + *firmware_p = firmware = kzalloc(sizeof(*firmware), GFP_ATOMIC);
> if (!firmware) {
> dev_err(device, "%s: kmalloc(struct firmware) failed\n",
> __func__);
> --
> 1.7.9.5
>
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
Re: [RFC] workqueue: Fix irq inversion deadlock in manage_workers()
On Sun, Oct 08, 2017 at 12:03:47PM -0700, Tejun Heo wrote:
> So, if I'm not mistaken, this is a regression caused by b9c16a0e1f73
> ("locking/mutex: Fix lockdep_assert_held() fail") which seems to
> replace irqsave operations inside mutex to unconditional irq ones.
No, it existed before that. You're looking at the DEBUG_MUTEX case, the
normal case looked like:
diff --git a/kernel/locking/mutex.h b/kernel/locking/mutex.h
index 4410a4af42a3..6ebc1902f779 100644
--- a/kernel/locking/mutex.h
+++ b/kernel/locking/mutex.h
@@ -9,10 +9,6 @@
* !CONFIG_DEBUG_MUTEXES case. Most of them are NOPs:
*/
-#define spin_lock_mutex(lock, flags) \
- do { spin_lock(lock); (void)(flags); } while (0)
-#define spin_unlock_mutex(lock, flags) \
- do { spin_unlock(lock); (void)(flags); } while (0)
#define mutex_remove_waiter(lock, waiter, task) \
__list_del((waiter)->list.prev, (waiter)->list.next)
Which is exactly what lives today.
Re: [PATCH] coccinelle: api: detect duplicate chip data arrays
> > I put kbuild in CC. I don't know what is the criterion for including
> > semantic patches.
>
> We may have 3 options:
>
> 1) push this patch to upstream, so that all users can run the check
> (with obvious cost)
I tried on my laptop with only one core and no indexing. In this case,
Coccinelle uses git grep to find relevant files. It finds only one. The
time for the whole process is 2 seconds.
> 2) try to optimize away the extra overheads by improving
> script/coccicheck to support conditional run of some cocci scripts
With Coccinelle, you can make virtual rules that are defined or not on the
command line and determine what does or not happen. At the moment, putting
virtual full at the top of the file and making all processing depend on
full has the very undesirable effect of causing all of the .cfiles to be
parsed, but I can fix that.
Another possibility is adding "depends on file in "drivers/power/supply""
to the first rule, which everything else depends on. I doubt that would
affect performance, because the git grep already has a high cost for
starting a shell, but it would make clearer what is going on.
julia
> 3) let 0-day maintain and run a collection of 3rd-party scripts if
> (1,2) turns out to be hard or not always applicable for some scripts
>
> What do you think? At least it'd be easy and quick for us to implement (3).
>
> Thanks,
> Fengguang
>
> > > >> Also maybe the name of the script should include "bq27xxx_data"?
> > > >
> > > > OK
> > > >
> > > >> Few more comments below...
> > > >>
> > > >> On Sun, Oct 1, 2017 at 5:42 AM, Julia Lawall
> > > wrote:
> > > >> > This semantic patch detects duplicate arrays declared using
> > > BQ27XXX_DATA
> > > >> > within a single structure. It is currently specific to the file
> > > >> > drivers/power/supply/bq27xxx_battery.c.
> > > >> >
> > > >> > Signed-off-by: Julia Lawall
> > > >> >
> > > >> > ---
> > > >> > scripts/coccinelle/api/battery.cocci | 161
> > > +++
> > > >> > 1 file changed, 161 insertions(+)
> > > >> >
> > > >> > diff --git a/scripts/coccinelle/api/battery.cocci
> > > b/scripts/coccinelle/api/battery.cocci
> > > >> > new file mode 100644
> > > >> > index 000..77c145a
> > > >> > --- /dev/null
> > > >> > +++ b/scripts/coccinelle/api/battery.cocci
> > > >> > @@ -0,0 +1,161 @@
> > > >> > +/// Detect BQ27XXX_DATA structures with identical registers, dm
> > > registers or
> > > >> > +/// properties.
> > > >> > +//# Doesn't unfold macros used in register or property fields.
> > > >> > +//# Requires OCaml scripting
> > > >> > +///
> > > >> > +// Confidence: High
> > > >> > +// Copyright: (C) 2017 Julia Lawall, Inria/LIP6, GPLv2.
> > > >> > +// URL: http://coccinelle.lip6.fr/
> > > >> > +// Requires: 1.0.7
> > > >> > +// Keywords: BQ27XXX_DATA
> > > >> > +
> > > >> > +virtual report
> > > >> > +
> > > >> > +@initialize:ocaml@
> > > >> > +@@
> > > >> > +
> > > >> > +let print_report p msg =
> > > >> > + let p = List.hd p in
> > > >> > + Printf.printf "%s:%d:%d-%d: %s" p.file p.line p.col p.col_end msg
> > > >> > +
> > > >> > +@str depends on report@
> > > >> > +type t;
> > > >> > +identifier i,i1,i2;
> > > >> > +expression e1,e2;
> > > >> > +@@
> > > >> > +
> > > >> > +t i[] = {
> > > >> > + ...,
> > > >> > + [e1] = BQ27XXX_DATA(i1,...),
> > > >> > + ...,
> > > >> > + [e2] = BQ27XXX_DATA(i2,...),
> > > >> > + ...,
> > > >> > +};
> > > >> > +
> > > >> > +@script:ocaml tocheck@
> > > >> > +i1 << str.i1;
> > > >> > +i2 << str.i2;
> > > >> > +i1regs; i2regs;
> > > >> > +i1dmregs; i2dmregs;
> > > >> > +i1props; i2props;
> > > >> > +@@
> > > >> > +
> > > >> > +if not(i1 = i2)
> > > >> > +then
> > > >> > + begin
> > > >> > +i1regs := make_ident (i1 ^ "_regs");
> > > >> > +i2regs := make_ident (i2 ^ "_regs");
> > > >> > +i1dmregs := make_ident (i1 ^ "_dm_regs");
> > > >> > +i2dmregs := make_ident (i2 ^ "_dm_regs");
> > > >> > +i1props := make_ident (i1 ^ "_props");
> > > >> > +i2props := make_ident (i2 ^ "_props")
> > > >> > + end
> > > >> > +
> > > >> > +(*
> > > *)
> > > >> > +
> > > >> > +@getregs1@
> > > >> > +typedef u8;
> > > >> > +identifier tocheck.i1regs;
> > > >> > +initializer list i1regs_vals;
> > > >> > +position p1;
> > > >> > +@@
> > > >> > +
> > > >> > +u8 i1regs@p1[...] = { i1regs_vals, };
> > > >> > +
> > > >> > +@getregs2@
> > > >> > +identifier tocheck.i2regs;
> > > >> > +initializer list i2regs_vals;
> > > >> > +position p2;
> > > >> > +@@
> > > >> > +
> > > >> > +u8 i2regs@p2[...] = { i2regs_vals, };
> > > >> > +
> > > >> > +@script:ocaml@
> > > >> > +(_,i1regs_vals) << getregs1.i1regs_vals;
> > > >> > +(_,i2regs_vals) << getregs2.i2regs_vals;
> > > >> > +i1regs << tocheck.i1regs;
> > > >> > +i2regs << tocheck.i2regs;
> > > >> > +p1 << getregs1.p1;
> > > >> > +p2 << getregs2.p2;
> > > >> > +@@
> > > >> > +
> > > >> > +if i1regs < i2regs &&
> > > >> > + List.sort compare i1regs
Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory
On Mon 09-10-17 08:33:16, Michal Hocko wrote:
> On Sat 07-10-17 00:37:55, Yang Shi wrote:
> >
> >
> > On 10/6/17 2:37 AM, Michal Hocko wrote:
> > > On Thu 05-10-17 05:29:10, Yang Shi wrote:
> [...]
> > > > + list_for_each_entry_safe(s, s2, &slab_caches, list) {
> > > > + if (!is_root_cache(s) || (s->flags &
> > > > SLAB_RECLAIM_ACCOUNT))
> > > > + continue;
> > > > +
> > > > + memset(&sinfo, 0, sizeof(sinfo));
> > >
> > > why do you zero out the structure. All the fields you are printing are
> > > filled out in get_slabinfo.
> >
> > No special reason, just wipe out the potential stale data on the stack.
>
> Do not add code that has no meaning. The OOM killer is a slow path but
> that doesn't mean we should throw spare cycles out of the window.
With this fixed and the compile fix [1] folded, feel free to add my
Acked-by: Michal Hocko
[1]
http://lkml.kernel.org/r/1507492085-42264-1-git-send-email-yan...@alibaba-inc.com
--
Michal Hocko
SUSE Labs
Re: [PATCH v3] mm, sysctl: make NUMA stats configurable
On 2017年10月03日 17:23, Michal Hocko wrote:
> On Thu 28-09-17 14:11:41, Kemi Wang wrote:
>> This is the second step which introduces a tunable interface that allow
>> numa stats configurable for optimizing zone_statistics(), as suggested by
>> Dave Hansen and Ying Huang.
>>
>> =
>> When page allocation performance becomes a bottleneck and you can tolerate
>> some possible tool breakage and decreased numa counter precision, you can
>> do:
>> echo [C|c]oarse > /proc/sys/vm/numa_stats_mode
>> In this case, numa counter update is ignored. We can see about
>> *4.8%*(185->176) drop of cpu cycles per single page allocation and reclaim
>> on Jesper's page_bench01 (single thread) and *8.1%*(343->315) drop of cpu
>> cycles per single page allocation and reclaim on Jesper's page_bench03 (88
>> threads) running on a 2-Socket Broadwell-based server (88 threads, 126G
>> memory).
>>
>> Benchmark link provided by Jesper D Brouer(increase loop times to
>> 1000):
>> https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/mm/
>> bench
>>
>> =
>> When page allocation performance is not a bottleneck and you want all
>> tooling to work, you can do:
>> echo [S|s]trict > /proc/sys/vm/numa_stats_mode
>>
>> =
>> We recommend automatic detection of numa statistics by system, this is also
>> system default configuration, you can do:
>> echo [A|a]uto > /proc/sys/vm/numa_stats_mode
>> In this case, numa counter update is skipped unless it has been read by
>> users at least once, e.g. cat /proc/zoneinfo.
>
> I am still not convinced the auto mode is worth all the additional code
> and a safe default to use. The whole thing could have been 0/1 with a
> simpler parsing and less code to catch readers.
>
I understood your concern.
Well, we may get rid of auto mode if there is some obvious disadvantage
here. Now, I tend to keep it because most people may not touch this interface,
and auto mode is helpful in such case.
> E.g. why do we have to do static_branch_enable on any read or even
> vmstat_stop? Wouldn't open be sufficient?
>
NUMA stats is used in four files:
/proc/zoneinfo
/proc/vmstat
/sys/devices/system/node/node*/numastat
/sys/devices/system/node/node*/vmstat
In auto mode, each *read* will trigger the update of NUMA counter.
So, we should make sure the target branch is jumped to the branch
for NUMA counter update once the file is read from user space.
the intension of static_branch_enable in vmstat_stop(in the call site
of file->file_ops.read) is for reading /proc/vmstat in case.
I guess the *open* means file->file_op.open here, right?
Do you suggest to move static_branch_enable to file->file_op.open? Thanks.
>> @@ -153,6 +153,8 @@ static DEVICE_ATTR(meminfo, S_IRUGO, node_read_meminfo,
>> NULL);
>> static ssize_t node_read_numastat(struct device *dev,
>> struct device_attribute *attr, char *buf)
>> {
>> +if (vm_numa_stats_mode == VM_NUMA_STAT_AUTO_MODE)
>> +static_branch_enable(&vm_numa_stats_mode_key);
>> return sprintf(buf,
>> "numa_hit %lu\n"
>> "numa_miss %lu\n"
>> @@ -186,6 +188,8 @@ static ssize_t node_read_vmstat(struct device *dev,
>> n += sprintf(buf+n, "%s %lu\n",
>> vmstat_text[i + NR_VM_ZONE_STAT_ITEMS],
>> sum_zone_numa_state(nid, i));
>> +if (vm_numa_stats_mode == VM_NUMA_STAT_AUTO_MODE)
>> +static_branch_enable(&vm_numa_stats_mode_key);
>> #endif
>>
>> for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++)
> [...]
>> @@ -1582,6 +1703,10 @@ static int zoneinfo_show(struct seq_file *m, void
>> *arg)
>> {
>> pg_data_t *pgdat = (pg_data_t *)arg;
>> walk_zones_in_node(m, pgdat, false, false, zoneinfo_show_print);
>> +#ifdef CONFIG_NUMA
>> +if (vm_numa_stats_mode == VM_NUMA_STAT_AUTO_MODE)
>> +static_branch_enable(&vm_numa_stats_mode_key);
>> +#endif
>> return 0;
>> }
>>
>> @@ -1678,6 +1803,10 @@ static int vmstat_show(struct seq_file *m, void *arg)
>>
>> static void vmstat_stop(struct seq_file *m, void *arg)
>> {
>> +#ifdef CONFIG_NUMA
>> +if (vm_numa_stats_mode == VM_NUMA_STAT_AUTO_MODE)
>> +static_branch_enable(&vm_numa_stats_mode_key);
>> +#endif
>> kfree(m->private);
>> m->private = NULL;
>> }
>> --
>> 2.7.4
>>
>
Re: [PATCH 3/3] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory
On Sat 07-10-17 00:37:55, Yang Shi wrote:
>
>
> On 10/6/17 2:37 AM, Michal Hocko wrote:
> > On Thu 05-10-17 05:29:10, Yang Shi wrote:
[...]
> > > + list_for_each_entry_safe(s, s2, &slab_caches, list) {
> > > + if (!is_root_cache(s) || (s->flags & SLAB_RECLAIM_ACCOUNT))
> > > + continue;
> > > +
> > > + memset(&sinfo, 0, sizeof(sinfo));
> >
> > why do you zero out the structure. All the fields you are printing are
> > filled out in get_slabinfo.
>
> No special reason, just wipe out the potential stale data on the stack.
Do not add code that has no meaning. The OOM killer is a slow path but
that doesn't mean we should throw spare cycles out of the window.
--
Michal Hocko
SUSE Labs
Re: [alsa-devel] [PATCH] opl3: Fix a possible sleep-in-atomic bug in snd_opl3_find_patch
Jia-Ju Bai wrote: > The driver may sleep under a spinlock, and the function call path is: > snd_opl3_note_on (acquire the spinlock) > snd_opl3_find_patch > kzalloc(GFP_KERNEL) --> may sleep This call path is not possible because create_patch is not set. Regards, Clemens
[PATCH] KVM: remove printing of vcpu address
Code currently prints the address of the kvm_vcpu structure in an error
message. It is not immediately clear what value this address adds to
the error string, we can use the vcpu ID instead. Printing unnecessary
kernel addresses to dmesg poses a security risk.
Remove the address from error message output, show vcpu ID instead.
Signed-off-by: Tobin C. Harding
---
virt/kvm/arm/arch_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 8e89d63005c7..ca6c331cad28 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -88,7 +88,7 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void
*dev_id)
* interrupt at this point is a sure sign of some major
* breakage.
*/
- pr_warn("Unexpected interrupt %d on vcpu %p\n", irq, vcpu);
+ pr_warn("Unexpected interrupt %d on vcpu ID %d\n", irq, vcpu->vcpu_id);
return IRQ_HANDLED;
}
--
2.7.4
[PATCH] KVM: remove printing of token address
KVM currently prints the address of the consumer token. It is not
immediately clear what benefit it is to see this address. Printing
this address leaks kernel pointers into dmesg and is a security risk.
Remove the consumer token address from error message output.
Signed-off-by: Tobin C. Harding
---
virt/kvm/eventfd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index f2ac53ab8243..b54503ed60bd 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -416,8 +416,7 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
irqfd->consumer.start = kvm_arch_irq_bypass_start;
ret = irq_bypass_register_consumer(&irqfd->consumer);
if (ret)
- pr_info("irq bypass consumer (token %p) registration
fails: %d\n",
- irqfd->consumer.token, ret);
+ pr_info("irq bypass consumer registration fails: %d\n",
ret);
}
#endif
--
2.7.4
Re: [PATCH] fs, mm: account filp and names caches to kmemcg
On Fri 06-10-17 12:33:03, Shakeel Butt wrote:
> >> names_cachep = kmem_cache_create("names_cache", PATH_MAX, 0,
> >> - SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
> >> + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT, NULL);
> >
> > I might be wrong but isn't name cache only holding temporary objects
> > used for path resolution which are not stored anywhere?
> >
>
> Even though they're temporary, many containers can together use a
> significant amount of transient uncharged memory. We've seen machines
> with 100s of MiBs in names_cache.
Yes that might be possible but are we prepared for random ENOMEM from
vfs calls which need to allocate a temporary name?
>
> >> filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
> >> - SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
> >> + SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT,
> >> NULL);
> >> percpu_counter_init(&nr_files, 0, GFP_KERNEL);
> >> }
> >
> > Don't we have a limit for the maximum number of open files?
> >
>
> Yes, there is a system limit of maximum number of open files. However
> this limit is shared between different users on the system and one
> user can hog this resource. To cater that, we set the maximum limit
> very high and let the memory limit of each user limit the number of
> files they can open.
Similarly here. Are all syscalls allocating a fd prepared to return
ENOMEM?
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/2] lib/test: Delete five error messages for a failed memory allocation
On Sat 07-10-17 19:48:37, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sat, 7 Oct 2017 17:34:23 +0200
>
> Omit extra messages for a memory allocation failure in these functions.
>
> This issue was detected by using the Coccinelle software.
Yes this makes sense. None of those really explain what the allocation
failure effect is. The allocation path already tells us about the
failure enough.
> Signed-off-by: Markus Elfring
Acked-by: Michal Hocko
> ---
> lib/test_kasan.c | 5 ++---
> lib/test_kmod.c | 8 ++--
> lib/test_list_sort.c | 9 +++--
> 3 files changed, 7 insertions(+), 15 deletions(-)
>
> diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> index a25c9763fce1..ef1a3ac1397e 100644
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -353,10 +353,9 @@ static noinline void __init
> memcg_accounted_kmem_cache(void)
>*/
> for (i = 0; i < 5; i++) {
> p = kmem_cache_alloc(cache, GFP_KERNEL);
> - if (!p) {
> - pr_err("Allocation failed\n");
> + if (!p)
> goto free_cache;
> - }
> +
> kmem_cache_free(cache, p);
> msleep(100);
> }
> diff --git a/lib/test_kmod.c b/lib/test_kmod.c
> index fba78d25e825..337f408b4de6 100644
> --- a/lib/test_kmod.c
> +++ b/lib/test_kmod.c
> @@ -783,10 +783,8 @@ static int kmod_config_sync_info(struct kmod_test_device
> *test_dev)
> free_test_dev_info(test_dev);
> test_dev->info = vzalloc(config->num_threads *
>sizeof(struct kmod_test_device_info));
> - if (!test_dev->info) {
> - dev_err(test_dev->dev, "Cannot alloc test_dev info\n");
> + if (!test_dev->info)
> return -ENOMEM;
> - }
>
> return 0;
> }
> @@ -1089,10 +1087,8 @@ static struct kmod_test_device
> *alloc_test_dev_kmod(int idx)
> struct miscdevice *misc_dev;
>
> test_dev = vzalloc(sizeof(struct kmod_test_device));
> - if (!test_dev) {
> - pr_err("Cannot alloc test_dev\n");
> + if (!test_dev)
> goto err_out;
> - }
>
> mutex_init(&test_dev->config_mutex);
> mutex_init(&test_dev->trigger_mutex);
> diff --git a/lib/test_list_sort.c b/lib/test_list_sort.c
> index 28e817387b04..5474f3f3e41d 100644
> --- a/lib/test_list_sort.c
> +++ b/lib/test_list_sort.c
> @@ -76,17 +76,14 @@ static int __init list_sort_test(void)
> pr_debug("start testing list_sort()\n");
>
> elts = kcalloc(TEST_LIST_LEN, sizeof(*elts), GFP_KERNEL);
> - if (!elts) {
> - pr_err("error: cannot allocate memory\n");
> + if (!elts)
> return err;
> - }
>
> for (i = 0; i < TEST_LIST_LEN; i++) {
> el = kmalloc(sizeof(*el), GFP_KERNEL);
> - if (!el) {
> - pr_err("error: cannot allocate memory\n");
> + if (!el)
> goto exit;
> - }
> +
>/* force some equivalencies */
> el->value = prandom_u32() % (TEST_LIST_LEN / 3);
> el->serial = i;
> --
> 2.14.2
--
Michal Hocko
SUSE Labs
Re: [PATCH v3 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants.
Hello Kalyan, On Mon, 9 Oct 2017 02:31:30 + Kalyan Kinthada wrote: > On 05/10/17 20:41, Miquel RAYNAL wrote: > > Hello Kalyan, > > > > On Thu, 28 Sep 2017 13:57:56 +1300 > > Kalyan Kinthada wrote: > > > >> When the arbitration between NOR and NAND flash is enabled > >> the field bit[21] in the Data Flash Control Register > >> needs to be set to 1 according to guidleine GL-5830741 mentioned > > Typo: guideline ^ > I will correct this typo in the next patch version. > >> in Marvell Errata document MV-S501377-00, Rev. D. > > Thanks for that, I checked it. > > > >> This commit sets the FORCE_CSX bit to 1 for all > >> ARMADA370 variants as the arbitration is always enabled by default. > >> This change does not apply for pxa3xx variants because the > >> FORCE_CSX bit does not exist/reserved on the NFCv1. > > Sorry to bother you again but I am reworking the pxa3xx_nand driver > > and so I would like to deeply understand why this is needed because > > I will have to integrate it in my work too. > > > > So please tell me what is your setup, do you really use NAND/NOR > > arbitration? Do you have not-Don't Care CS NAND chips? I have some > > doubts because even if the spec precises in the NAND controller > > chapter that arbitration is always enabled by default, the bit 27 > > (NfArbiterEn) in the SoC Device Multiplex Register at offset > > 0x00018208 is actually at 0 by default (disabled). Did you enable > > this bit manually ? I checked with devmem on my setup and this bit > > was unset. > Yes, my setup use NAND/NOR arbitration and use a Don't > care CS Nand Chip. The bit 27 at offset 0x00018208 is set to 1 > by default in my case. I did not manually set the bit 27 to 1. Actually if you use Don't Care CS NAND chips you should not need the force CS bit, as it is mentioned in the guidelines you pointed, this bit is only useful for *not* don't care CS NAND chips (and the name "force CS" is pretty straight forward too!). Otherwise what bootloader and kernel do you use to have this bit set by default? You may also want to check if this bit is set by your bootloader by stopping it before it loads Linux and check manually the value of this bit with 'md' (on U-Boot). Thank you, Miquèl > > Please let me now if you have any other question or do you want me > to send the updated patch version with the typo fixed. > > Thank You, > Kalyan > > > > > Thank you for your time, > > Miquèl > > > >> The NDCR_ND_MODE conflicts with the new NDCR_FORCE_CSX but is > >> unused so remove it along with NDCR_NAND_MODE. > >> > >> Signed-off-by: Kalyan Kinthada > >> --- > > > > > >> drivers/mtd/nand/pxa3xx_nand.c | 9 +++-- > >> 1 file changed, 7 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/mtd/nand/pxa3xx_nand.c > >> b/drivers/mtd/nand/pxa3xx_nand.c index 85cff68643e0..a6a7a5af7bed > >> 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c > >> +++ b/drivers/mtd/nand/pxa3xx_nand.c > >> @@ -67,8 +67,7 @@ > >> #define NDCR_DWIDTH_M(0x1 << 26) > >> #define NDCR_PAGE_SZ (0x1 << 24) > >> #define NDCR_NCSX(0x1 << 23) > >> -#define NDCR_ND_MODE (0x3 << 21) > >> -#define NDCR_NAND_MODE(0x0) > >> +#define NDCR_FORCE_CSX(0x1 << 21) > >> #define NDCR_CLR_PG_CNT (0x1 << 20) > >> #define NFCV1_NDCR_ARB_CNTL (0x1 << 19) > >> #define NFCV2_NDCR_STOP_ON_UNCOR (0x1 << 19) > >> @@ -1464,6 +1463,9 @@ static int pxa3xx_nand_config_ident(struct > >> pxa3xx_nand_info *info) info->chunk_size = PAGE_CHUNK_SIZE; > >>info->reg_ndcr = 0x0; /* enable all interrupts */ > >>info->reg_ndcr |= (pdata->enable_arbiter) ? > >> NDCR_ND_ARB_EN : 0; > >> + /* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#: > >> GL-5830741 */ > >> + if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370) > >> + info->reg_ndcr |= NDCR_FORCE_CSX; > >>info->reg_ndcr |= NDCR_RD_ID_CNT(READ_ID_BYTES); > >>info->reg_ndcr |= NDCR_SPARE_EN; > >> > >> @@ -1498,6 +1500,9 @@ static void pxa3xx_nand_detect_config(struct > >> pxa3xx_nand_info *info) info->reg_ndcr = ndcr & > >>~(NDCR_INT_MASK | NDCR_ND_ARB_EN | > >> NFCV1_NDCR_ARB_CNTL); info->reg_ndcr |= (pdata->enable_arbiter) ? > >> NDCR_ND_ARB_EN : 0; > >> + /* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#: > >> GL-5830741 */ > >> + if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370) > >> + info->reg_ndcr |= NDCR_FORCE_CSX; > >>info->ndtr0cs0 = nand_readl(info, NDTR0CS0); > >>info->ndtr1cs0 = nand_readl(info, NDTR1CS0); > >> } > > > > -- Miquel Raynal, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH 10/12] net/mlx4: replace with
On Mon, Oct 09, 2017 at 02:56:56PM +0900, Masahiro Yamada wrote: > 2017-10-09 3:55 GMT+09:00 Leon Romanovsky : > > On Mon, Oct 09, 2017 at 02:29:15AM +0900, Masahiro Yamada wrote: > >> 2017-10-09 2:00 GMT+09:00 David Miller : > >> > From: Masahiro Yamada > >> > Date: Mon, 9 Oct 2017 01:10:11 +0900 > >> > > >> >> The headers > >> >> - include/linux/mlx4/device.h > >> >> - drivers/net/ethernet/mellanox/mlx4/mlx4.h > >> >> require the definition of struct radix_tree_root, but do not need to > >> >> know anything about other radix tree stuff. > >> >> > >> >> Include instead of to > >> >> reduce the header dependency. > >> >> > >> >> While we are here, let's add missing where > >> >> radix tree accessors are used. > >> >> > >> >> Signed-off-by: Masahiro Yamada > >> > > >> > Honestly this makes things more complicated. > >> > >> > >> The idea is simple; include necessary headers explicitly. > >> > >> Putting everything into one common header > >> means most of C files are forced to parse unnecessary headers. > > > > It is neglected, only first caller will actually parse that header file, > > other callers will check the #ifndef pragma without need to reparse the > > whole file. > > > > > You completely neglected the point of the discussion. > > I am trying to not include unnecessary headers at all. > I understand it and have no issues with that, just have hard time to justify for myself any benefit of doing it. Thanks > > > > -- > Best Regards > Masahiro Yamada signature.asc Description: PGP signature
Re: [PATCH v2 1/1] mm: only dispaly online cpus of the numa node
On 2017/10/3 21:56, Michal Hocko wrote: > On Tue 03-10-17 14:47:26, Will Deacon wrote: >> On Mon, Oct 02, 2017 at 02:54:46PM -0700, Andrew Morton wrote: >>> On Mon, 2 Oct 2017 11:38:07 +0100 Will Deacon wrote: >>> > When I executed numactl -H(which read > /sys/devices/system/node/nodeX/cpumap > and display cpumask_of_node for each node), but I got different result on > X86 and arm64. For each numa node, the former only displayed online CPUs, > and the latter displayed all possible CPUs. Unfortunately, both Linux > documentation and numactl manual have not described it clear. > > I sent a mail to ask for help, and Michal Hocko > replied > that he preferred to print online cpus because it doesn't really make much > sense to bind anything on offline nodes. > > Signed-off-by: Zhen Lei > Acked-by: Michal Hocko > --- > drivers/base/node.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) Which tree is this intended to go through? I'm happy to take it via arm64, but I don't want to tread on anybody's toes in linux-next and it looks like there are already queued changes to this file via Andrew's tree. >>> >>> I grabbed it. I suppose there's some small risk of userspace breakage >>> so I suggest it be a 4.15-rc1 thing? >> >> To be honest, I suspect the vast majority (if not all) code that reads this >> file was developed for x86, so having the same behaviour for arm64 sounds >> like something we should do ASAP before people try to special case with >> things like #ifdef __aarch64__. >> >> I'd rather have this in 4.14 if possible. > > Agreed! > +1 -- Thanks! BestRegards
Re: [for-next][PATCH 15/16] ftrace: Add freeing algorithm to free ftrace_mod_maps
Hi Steve, On Sun, Oct 8, 2017 at 11:42 AM, Steven Rostedt wrote: >> > "Joel Fernandes (Google)" wrote: >> > Also could you let me know what is the correct behavior of the filters >> > after a module being traced is unloaded, are the filters supposed to >> > be setup again after the module is unloaded, before the module can be >> > loaded again? >> >> Actually I learnt that it doesn't get preserved and wrote a patch to fix >> that, let me know >> what you think, thanks. (its only lightly tested - checked that the filters >> are preserved, >> will do more testing tomorrow): > > They should not be preserved, it's too non-deterministic. > > I'm wondering why the setting of the ip to zero didn't keep it from > showing up again. I'll have to investigate that. > I found that the entries weren't being cleared for the init functions as the records weren't available at module unload time. Posted a patch to fix this: https://lkml.org/lkml/2017/10/8/196 thanks, - Joel
Re: [PATCH 00/12] radix-tree: split out struct radix_tree_root out to
On Mon, Oct 09, 2017 at 02:58:58PM +0900, Masahiro Yamada wrote: > 2017-10-09 3:52 GMT+09:00 Leon Romanovsky : > > On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote: > > > > <...> > >> > >> By splitting out the radix_tree_root definition, > >> we can reduce the header file dependency. > >> > >> Reducing the header dependency will help for speeding the kernel > >> build, suppressing unnecessary recompile of objects during > >> git-bisect'ing, etc. > > > > If we judge by the diffstat of this series, there won't be any > > visible change in anything mentioned above. > > > Of course, judging by the diffstat is wrong. > I'm more than happy to be wrong and you for sure can help me. Can you provide any quantitative support of your claims? Thanks > > > -- > Best Regards > Masahiro Yamada > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html signature.asc Description: PGP signature
Re: [for-next][PATCH 15/16] ftrace: Add freeing algorithm to free ftrace_mod_maps
Hi Steve,
On Sat, Oct 7, 2017 at 9:52 PM, Joel Fernandes (Google)
wrote:
[..]
>>>
>>> On Fri, Oct 6, 2017 at 11:07 AM, Steven Rostedt wrote:
>>> > From: "Steven Rostedt (VMware)"
>>> >
>>> > The ftrace_mod_map is a descriptor to save module init function names in
>>> > case they were traced, and the trace output needs to reference the
>>> > function
>>> > name from the function address. But after the function is unloaded, it
>>> > the maps should be freed, as the rest of the function names are as well.
>>>
>>> Just checking for my understanding of this patch - wouldn't this also
>>> mean that if there were any look ups of the init functions that may be
>>> needed at trace output time, then those look ups wont be possible any
>>> more after module is unloaded?
>>
>> Yes. That's true for all functions in the module. When a module is
>> unloaded, all references to it in kallsyms is also freed. Try it on a
>> current kernel. Trace a function in a module, then unload that module.
>> The trace data will just show the ip hex address of the module function
>> after that.
>>
>
> I tried your core branch and I see some weirdness with the filters:
>
> Here's the code for the module:
>
> #include
> #include
> #include
>
> void bar(void)
> {
> printk(KERN_INFO "bar!\n");
> }
>
> void foo(void)
> {
> printk(KERN_INFO "foo!\n");
> bar();
> }
>
> static int __init hello_init(void)
> {
> printk(KERN_INFO "Hello world!\n");
> foo();
> return 0;
> }
>
> static void __exit hello_cleanup(void)
> {
> printk(KERN_INFO "Cleaning up module.\n");
> }
>
> module_init(hello_init);
> module_exit(hello_cleanup);
>
[..]
> Also I wasn't able to see the call from hello_init -> bar and bar ->
> foo so I'm not fully sure if that's a bug or I did something wrong.
> I'm happy to try out anything you suggest.
This was I think because of function inlining, using 'noinline' on the
foo and bar functions in the above module makes it all work properly
(tested on ftrace/core branch).
thanks,
- Joel
Re: [PATCH 00/12] radix-tree: split out struct radix_tree_root out to
2017-10-09 3:52 GMT+09:00 Leon Romanovsky : > On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote: > > <...> >> >> By splitting out the radix_tree_root definition, >> we can reduce the header file dependency. >> >> Reducing the header dependency will help for speeding the kernel >> build, suppressing unnecessary recompile of objects during >> git-bisect'ing, etc. > > If we judge by the diffstat of this series, there won't be any > visible change in anything mentioned above. Of course, judging by the diffstat is wrong. -- Best Regards Masahiro Yamada
Re: [PATCH 10/12] net/mlx4: replace with
2017-10-09 3:55 GMT+09:00 Leon Romanovsky : > On Mon, Oct 09, 2017 at 02:29:15AM +0900, Masahiro Yamada wrote: >> 2017-10-09 2:00 GMT+09:00 David Miller : >> > From: Masahiro Yamada >> > Date: Mon, 9 Oct 2017 01:10:11 +0900 >> > >> >> The headers >> >> - include/linux/mlx4/device.h >> >> - drivers/net/ethernet/mellanox/mlx4/mlx4.h >> >> require the definition of struct radix_tree_root, but do not need to >> >> know anything about other radix tree stuff. >> >> >> >> Include instead of to >> >> reduce the header dependency. >> >> >> >> While we are here, let's add missing where >> >> radix tree accessors are used. >> >> >> >> Signed-off-by: Masahiro Yamada >> > >> > Honestly this makes things more complicated. >> >> >> The idea is simple; include necessary headers explicitly. >> >> Putting everything into one common header >> means most of C files are forced to parse unnecessary headers. > > It is neglected, only first caller will actually parse that header file, > other callers will check the #ifndef pragma without need to reparse the > whole file. > You completely neglected the point of the discussion. I am trying to not include unnecessary headers at all. -- Best Regards Masahiro Yamada
Re: [PATCH 3/3] ARM: dts: gr-peach: Add ETHER pin group
On Fri, Oct 06, 2017 at 02:25:23PM +0200, jacopo mondi wrote: > Hi Simon, > > On Thu, Oct 05, 2017 at 10:58:20AM +0200, Jacopo Mondi wrote: > > Add pin configuration subnode for ETHER pin group and enable the interface. > > > > Signed-off-by: Jacopo Mondi > > --- > > arch/arm/boot/dts/r7s72100-gr-peach.dts | 38 > > + > > 1 file changed, 38 insertions(+) > > > > Can you confirm you have not applied this yet? Confirmed.
Re: [PATCH 10/12] net/mlx4: replace with
2017-10-09 2:32 GMT+09:00 Joe Perches :
> On Mon, 2017-10-09 at 02:29 +0900, Masahiro Yamada wrote:
>> The idea is simple; include necessary headers explicitly.
>
> Try that for kernel.h
>
> There's a reason aggregation of #includes is useful.
>
We should use a common sense for the balance between
- aggregation of #includes
- reduce the number of parsed headers
As I had already said, if you do not like this change, you can just
throw it away.
That's fine because the impact is very limited.
Honestly, I am not so interested in this driver.
I changed sh, net/mlx4, net/mlx5, drm/i915 for bonus while I am here.
I assume your objection is addressed to this driver change,
not the whole series.
I am more interested in the global headers like
include/linux/{irqdomain.h, fs.h} etc.
radix-tree-root.h vs radix-tree.h
has a big difference in terms of parsed headers (17 vs 128).
For example, the following is the analysis on arm64.
include the following 17 headers:
include/linux/radix-tree-root.h \
include/linux/types.h \
include/uapi/linux/types.h \
arch/arm64/include/generated/uapi/asm/types.h \
include/uapi/asm-generic/types.h \
include/asm-generic/int-ll64.h \
include/uapi/asm-generic/int-ll64.h \
arch/arm64/include/uapi/asm/bitsperlong.h \
include/asm-generic/bitsperlong.h \
include/uapi/asm-generic/bitsperlong.h \
include/uapi/linux/posix_types.h \
include/linux/stddef.h \
include/uapi/linux/stddef.h \
include/linux/compiler.h \
include/linux/compiler-gcc.h \
arch/arm64/include/uapi/asm/posix_types.h \
include/uapi/asm-generic/posix_types.h \
include the following 128 headers:
include/linux/radix-tree.h \
include/linux/bitops.h \
arch/arm64/include/generated/uapi/asm/types.h \
include/uapi/asm-generic/types.h \
include/asm-generic/int-ll64.h \
include/uapi/asm-generic/int-ll64.h \
arch/arm64/include/uapi/asm/bitsperlong.h \
include/asm-generic/bitsperlong.h \
include/uapi/asm-generic/bitsperlong.h \
arch/arm64/include/asm/bitops.h \
include/linux/compiler.h \
include/linux/compiler-gcc.h \
include/uapi/linux/types.h \
include/uapi/linux/posix_types.h \
include/linux/stddef.h \
include/uapi/linux/stddef.h \
arch/arm64/include/uapi/asm/posix_types.h \
include/uapi/asm-generic/posix_types.h \
arch/arm64/include/asm/barrier.h \
include/asm-generic/barrier.h \
include/asm-generic/bitops/builtin-__ffs.h \
include/asm-generic/bitops/builtin-ffs.h \
include/asm-generic/bitops/builtin-__fls.h \
include/asm-generic/bitops/builtin-fls.h \
include/asm-generic/bitops/ffz.h \
include/asm-generic/bitops/fls64.h \
include/asm-generic/bitops/find.h \
include/asm-generic/bitops/sched.h \
include/asm-generic/bitops/hweight.h \
include/asm-generic/bitops/arch_hweight.h \
include/asm-generic/bitops/const_hweight.h \
include/asm-generic/bitops/lock.h \
include/asm-generic/bitops/non-atomic.h \
include/asm-generic/bitops/le.h \
arch/arm64/include/uapi/asm/byteorder.h \
include/linux/byteorder/big_endian.h \
include/uapi/linux/byteorder/big_endian.h \
include/linux/types.h \
include/linux/swab.h \
include/uapi/linux/swab.h \
arch/arm64/include/generated/uapi/asm/swab.h \
include/uapi/asm-generic/swab.h \
include/linux/byteorder/generic.h \
include/linux/bug.h \
arch/arm64/include/asm/bug.h \
include/linux/stringify.h \
arch/arm64/include/asm/asm-bug.h \
arch/arm64/include/asm/brk-imm.h \
include/asm-generic/bug.h \
include/linux/kernel.h \
/home/masahiro/toolchains/aarch64-linaro-4.9/gcc-linaro-4.9-2016.02-x86_64_aarch64-linux-gnu/lib/gcc/aarch64-linux-gnu/4.9.4/include/stdarg.h
\
include/linux/linkage.h \
include/linux/export.h \
arch/arm64/include/asm/linkage.h \
include/linux/log2.h \
include/linux/typecheck.h \
include/linux/printk.h \
include/linux/init.h \
include/linux/kern_levels.h \
include/linux/cache.h \
include/uapi/linux/kernel.h \
include/uapi/linux/sysinfo.h \
arch/arm64/include/asm/cache.h \
arch/arm64/include/asm/cputype.h \
arch/arm64/include/asm/sysreg.h \
include/linux/dynamic_debug.h \
include/linux/jump_label.h \
arch/arm64/include/asm/jump_label.h \
arch/arm64/include/asm/insn.h \
include/linux/build_bug.h \
include/linux/list.h \
include/linux/poison.h \
include/uapi/linux/const.h \
include/linux/preempt.h \
arch/arm64/include/generated/asm/preempt.h \
include/asm-generic/preempt.h \
include/linux/thread_info.h \
include/linux/restart_block.h \
arch/arm64/include/asm/current.h \
arch/arm64/include/asm/thread_info.h \
arch/arm64/include/asm/memory.h \
arch/arm64/include/asm/page-def.h \
arch/arm64/include/generated/asm/sizes.h \
include/asm-generic/sizes.h \
include/linux/sizes.h \
include/linux/mmdebug.h \
include/asm-generic/memory_model.h \
include/linux/pfn.h \
arch/arm64/include/asm/stack_pointer.h \
include/linux/radix-tree-root.h \
include/linux/rcupdate.h \
include/
Re: [PATCH V1] pinctrl: qcom: spmi-gpio: Update GPIO EN_CTL when setting pin config
On Sun 08 Oct 22:34 PDT 2017, Fenglin Wu wrote:
> On 10/6/2017 12:27 AM, Bjorn Andersson wrote:
> > On Mon 11 Sep 17:32 PDT 2017, fengl...@codeaurora.org wrote:
> >
> > > From: Fenglin Wu
> > >
> > > GPIO is expected to be disabled iff PIN_CONFIG_BIAS_HIGH_IMPEDANCE is
> > > configured. Update is_enabled flag in config_set() so that it can
> > > reflect GPIO status correctly. Also modify EN_CTL register based on
> > > is_enabled flag in config_set() to configure the GPIO properly.
> > >
> > > Signed-off-by: Fenglin Wu
> > > ---
> > > drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> > > b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> > > index c2c0bab..a0edaa8 100644
> > > --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> > > +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> > > @@ -453,6 +453,7 @@ static int pmic_gpio_config_set(struct pinctrl_dev
> > > *pctldev, unsigned int pin,
> > > pad = pctldev->desc->pins[pin].drv_data;
> > > + pad->is_enabled = true;
> > > for (i = 0; i < nconfs; i++) {
> > > param = pinconf_to_config_param(configs[i]);
> > > arg = pinconf_to_config_argument(configs[i]);
> > > @@ -600,6 +601,10 @@ static int pmic_gpio_config_set(struct pinctrl_dev
> > > *pctldev, unsigned int pin,
> > > return ret;
> > > }
> > > + val = pad->is_enabled << PMIC_GPIO_REG_MASTER_EN_SHIFT;
> > > +
> > > + ret = pmic_gpio_write(state, pad, PMIC_GPIO_REG_EN_CTL, val);
> > > +
> >
> > This looks good.
> >
> > Acked-by: Bjorn Andersson
> >
> >
> > But I spotted another issue while reviewing this; currently the initial
> > state of is_enabled is unconditionally set to enabled in
> > pmic_gpio_populate(), so reading the initial pinconf or configuring a
> > pinmux before setting a pinconf will operate on the potentially wrong
> > information.
> >
> > So I think the initial value should be read out from REG_EN_CTL rather
> > than being just "true".
> >
> > Can you please either submit another patch for this?
>
> Hmm, considering a GPIO which is disabled by default in hardware
> setting, what's its expected state if we only define "function" for it?
> I was thinking we need to enable it once it has any setting in pinmux or
> pinconf. If you think that we need to keep its original state until we
> set pinconf for it, yes, I can submit a change to address this.
>
Are there valid cases where only function should be selected and no
other configuration is used? If so it makes sense to make
pmic_gpio_set_mux() enable the block.
Regardless of this, if there are disabled pins that are not mentioned in
DT they will still appear as enabled in the debugfs interface; and this
I consider an error worth fixing.
Regards,
Bjorn
Re: [PATCH] dt-bindings: irqchip: renesas-irqc: Document R-Car M3-W, V3M, D3 support
On Fri, Oct 06, 2017 at 01:51:32PM +0200, Geert Uytterhoeven wrote: > Document support for the Interrupt Controller for Externel Devices > (INTC-EX) in the Renesas M3-W (r8a7796), V3M (r8a77970), and D3 > (r8a77995) SoCs. > > No driver update is needed. > > Signed-off-by: Geert Uytterhoeven Acked-by: Simon Horman
[PATCH 1/2] ARM: dts: dra7: Increase max-voltage of pbias regulator
From: Ravikumar Kattekola
As per recent TRM, PBIAS cell on dra7 devices supports
3.3v and not 3.0v as documented earlier.
Update PBIAS regulator max voltage to match this.
Document reference:
SPRUI30C – DRA75x, DRA74x Technical reference manual- November 2016
Tested on:
DRA75x PG 2.0 REV H EVM
Signed-off-by: Ravikumar Kattekola
Signed-off-by: Sekhar Nori
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 02a136a4661a..14d75c589369 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -170,7 +170,7 @@
pbias_mmc_reg: pbias_mmc_omap5 {
regulator-name =
"pbias_mmc_omap5";
regulator-min-microvolt
= <180>;
- regulator-max-microvolt
= <300>;
+ regulator-max-microvolt
= <330>;
};
};
--
2.11.0
[PATCH 0/2] dra7/omap5: Increase max-voltage of pbias to 3.3v
Max voltage of pbias was set to 3.0v because of an error in TRM in omap5/dra7 SoCs. It's now corrected to be 3.3v. Corresponding change in pbias regulator driver is already merged in ulf -next commit 27eae9d4b9d4cd9c204ef81f46078d91362ed41c Author: Ravikumar Kattekola Date: Thu Aug 31 15:48:45 2017 +0530 regulator: pbias: Select voltage table based on max-voltage Reference manuals of OMAP5x and DRA7x have been updated to reflect the PBIAS regulator max-voltage as 3.3V instead of 3.0V, while OMAP3x and OMAP4x are still quoting 3.0V. So, as of now, the pbias driver needs to support both 3.0V and 3.3V IO voltage based on the max-voltage supported by the PBIAS regulator. Document reference: SWPU249AF - OMAP543x Technical reference manual - August 2016 SPRUI30C – DRA75x, DRA74x Technical reference manual November 2016 Tested on: DRA75x PG 2.0 REV H EVM Signed-off-by: Ravikumar Kattekola Signed-off-by: Sekhar Nori Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Mark Brown Ravikumar Kattekola (2): ARM: dts: dra7: Increase max-voltage of pbias regulator ARM: dts: omap5: Increase max-voltage of pbias regulator arch/arm/boot/dts/dra7.dtsi | 2 +- arch/arm/boot/dts/omap5.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.11.0
[PATCH 2/2] ARM: dts: omap5: Increase max-voltage of pbias regulator
From: Ravikumar Kattekola
As per recent TRM, PBIAS cell on omap5 devices supports
3.3v and not 3.0v as documented earlier.
Update PBIAS regulator max voltage to match this.
Document reference:
SWPU249AF - OMAP543x Technical reference manual August 2016
Signed-off-by: Ravikumar Kattekola
Signed-off-by: Sekhar Nori
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index eaff2a5751dd..e6af460ee301 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -194,7 +194,7 @@
pbias_mmc_reg: pbias_mmc_omap5 {
regulator-name =
"pbias_mmc_omap5";
regulator-min-microvolt
= <180>;
- regulator-max-microvolt
= <300>;
+ regulator-max-microvolt
= <330>;
};
};
};
--
2.11.0
Re: [PATCH 13/14] netfilter/ipvs: Use %pS printk format for direct addresses
On Wed, Sep 06, 2017 at 10:28:00PM +0200, Helge Deller wrote: > The debug and error printk functions in ipvs uses wrongly the %pF instead of > the %pS printk format specifier for printing symbols for the address returned > by _builtin_return_address(0). Fix it for the ia64, ppc64 and parisc64 > architectures. > > Signed-off-by: Helge Deller > Cc: Wensong Zhang > Cc: net...@vger.kernel.org > Cc: lvs-de...@vger.kernel.org > Cc: netfilter-de...@vger.kernel.org Sorry for the delay in processing this. Acked-by: Simon Horman Pablo, could you take this through the nf-next tree directly?
Re: [PATCH v3 3/5] media: atmel-isc: Enable the clocks during probe
Hi Sakari,
Sorry for late answer, because I was in vacation last week.
On 2017/9/29 5:25, Sakari Ailus wrote:
Hi Wenyou,
On Thu, Sep 28, 2017 at 04:18:26PM +0800, Wenyou Yang wrote:
To meet the relationship, enable the HCLOCK and ispck during the
device probe, "isc_pck frequency is less than or equal to isc_ispck,
and isc_ispck is greater than or equal to HCLOCK."
Meanwhile, call the pm_runtime_enable() in the right place.
Signed-off-by: Wenyou Yang
---
Changes in v3: None
Changes in v2: None
drivers/media/platform/atmel/atmel-isc.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isc.c
b/drivers/media/platform/atmel/atmel-isc.c
index 0b15dc1a3a0b..f092c95587c1 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -1594,6 +1594,7 @@ static int isc_async_complete(struct v4l2_async_notifier
*notifier)
struct isc_subdev_entity *sd_entity;
struct video_device *vdev = &isc->video_dev;
struct vb2_queue *q = &isc->vb2_vidq;
+ struct device *dev = isc->dev;
int ret;
ret = v4l2_device_register_subdev_nodes(&isc->v4l2_dev);
@@ -1677,6 +1678,10 @@ static int isc_async_complete(struct v4l2_async_notifier
*notifier)
return ret;
}
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+ pm_request_idle(dev);
Remember that the driver's async complete function could never get called.
What would be the reason to move it here?
The ISC provides the clock for the sensor, namely, it is the clock
provider for the external sensor.
So it keeps active to make the sensor probe successfully.
Otherwise, the sensor, such as 0v7670 fails to probe due to the failure
to clk_enable().
+
return 0;
}
@@ -1856,25 +1861,37 @@ static int atmel_isc_probe(struct platform_device *pdev)
return ret;
}
+ ret = clk_prepare_enable(isc->hclock);
+ if (ret) {
+ dev_err(dev, "failed to enable hclock: %d\n", ret);
+ return ret;
+ }
+
ret = isc_clk_init(isc);
if (ret) {
dev_err(dev, "failed to init isc clock: %d\n", ret);
- goto clean_isc_clk;
+ goto unprepare_hclk;
}
isc->ispck = isc->isc_clks[ISC_ISPCK].clk;
+ ret = clk_prepare_enable(isc->ispck);
+ if (ret) {
+ dev_err(dev, "failed to enable ispck: %d\n", ret);
+ goto unprepare_hclk;
+ }
+
/* ispck should be greater or equal to hclock */
ret = clk_set_rate(isc->ispck, clk_get_rate(isc->hclock));
if (ret) {
dev_err(dev, "failed to set ispck rate: %d\n", ret);
- goto clean_isc_clk;
+ goto unprepare_clk;
}
ret = v4l2_device_register(dev, &isc->v4l2_dev);
if (ret) {
dev_err(dev, "unable to register v4l2 device.\n");
- goto clean_isc_clk;
+ goto unprepare_clk;
}
ret = isc_parse_dt(dev, isc);
@@ -1907,8 +1924,6 @@ static int atmel_isc_probe(struct platform_device *pdev)
break;
}
- pm_runtime_enable(dev);
-
return 0;
cleanup_subdev:
@@ -1917,7 +1932,11 @@ static int atmel_isc_probe(struct platform_device *pdev)
unregister_v4l2_device:
v4l2_device_unregister(&isc->v4l2_dev);
-clean_isc_clk:
+unprepare_clk:
+ clk_disable_unprepare(isc->ispck);
+unprepare_hclk:
+ clk_disable_unprepare(isc->hclock);
I think you're missing clk_disable_unprepare() in the driver's remove
callback.
Will add in next version.
+
isc_clk_cleanup(isc);
return ret;
Best Regards,
Wenyou Yang
[PATCH] page_alloc.c: inline __rmqueue()
__rmqueue() is called by rmqueue_bulk() and rmqueue() under zone->lock
and that lock can be heavily contended with memory intensive applications.
Since __rmqueue() is a small function, inline it can save us some time.
With the will-it-scale/page_fault1/process benchmark, when using nr_cpu
processes to stress buddy:
On a 2 sockets Intel-Skylake machine:
base %change head
77342+6.3% 82203will-it-scale.per_process_ops
On a 4 sockets Intel-Skylake machine:
base %change head
75746+4.6% 79248will-it-scale.per_process_ops
This patch adds inline to __rmqueue().
Signed-off-by: Aaron Lu
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0e309ce4a44a..c9605c7ebaf6 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2291,7 +2291,7 @@ __rmqueue_fallback(struct zone *zone, int order, int
start_migratetype)
* Do the hard work of removing an element from the buddy allocator.
* Call me with the zone->lock already held.
*/
-static struct page *__rmqueue(struct zone *zone, unsigned int order,
+static inline struct page *__rmqueue(struct zone *zone, unsigned int order,
int migratetype)
{
struct page *page;
--
2.13.6
Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs
On 6.10.2017 18:18, Moritz Fischer wrote: > On Fri, Oct 06, 2017 at 01:49:44PM +0200, Michal Simek wrote: >> On 26.9.2017 20:15, Philip Balister wrote: >>> On 09/26/2017 02:06 PM, Michal Simek wrote: On 26.9.2017 19:58, Philip Balister wrote: > On 09/26/2017 01:50 PM, Moritz Fischer wrote: >> Michal, >> >> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote: >>> Hi, >>> >>> On 25.9.2017 18:11, Moritz Fischer wrote: Hi Michal, On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote: > Hi Moritz > > sorry for delay. No problem. > > On 12.9.2017 01:22, Moritz Fischer wrote: >> Add support for the National Instruments Project Sulfur SDR >> motherboards Rev 2,3 and 4. >> >> Signed-off-by: Moritz Fischer >> --- >> arch/arm/boot/dts/Makefile| 3 + >> arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts | 84 +++ >> arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 >> ++ >> arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts | 26 ++ >> arch/arm/boot/dts/zynq-ni-sulfur.dtsi | 133 >> ++ >> 5 files changed, 364 insertions(+) >> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts >> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts >> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts >> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi > > Is this publicly available board? Will be in Q1 2018 was announced at GRCon'17 ([1]). Some of the Rev3s are currently deployed in Norway as part of a radar system. > I am not quite sure we should apply these dts files. There are a lot > of > boards with zynq and there must be any strong argument for applying > this > to the tree. For arm32 with even flat tree structure. What's the issue with merging them, except for having 3 more files? >>> >>> For me this is not a problem because on Linux side it is not increasing >>> build time. >>> I want to see the value for community. All xilinx platforms are >>> evaluation generic purpose boards which are showing how to connect stuff >>> together. >>> On the other hand this is real product. >> >> Uh. >> >>> I would let arm-soc maintainer to decide if this is fine or not. I >>> definitely don't want to end up in situation that we will have dts for >>> real products which are not bringing any value for others. >> >> Sure, it's the maintainers call. >> >> I do intend to have my customers run mainline on it eventually, currently >> I'm a handful of patches away from making that happen. So yes, running >> mainline is a usecase that matters to me. >> >> It is one thing to keep bitching about vendor kernels as a community >> continuously, but then if someone goes through the effort and actually >> tries to run mainline, you give them crap like that above. >> >> Our products usually come with full schematics [1], firmware, fpga code >> and all >> available, I don't know what makes them less useful to the community as a >> platform to experiment and develop on than Xilinx eval boards. >> >> There's several people that I know of both hobbyists and companies that >> build systems around these platforms, so I don't know ... > > I expect this product to be delivered with full source and a mainline > kernel, so lets make it easy for Moritz to do the right thing here. This > makes long term support of this product much easier. > > Acked-by: Philip Balister I think this is the right way to go. Get ACK from Arnd or Olof or Kevin and I will merge this. I am simply just afraid that if a lot of zynq customers will ask for it we can will end up with a lot of zynq/zynqmp based dts files in the kernel and arm-soc guys will stop this that it is simply too much and won't accept +1 case. >>> >>> I share the same concerns. Unfortunately, there doesn't seem like any >>> other structured way to manage dts files. >>> >>> As an OpenEmbedded guy, I know I can carry them with BSP's, but not >>> everyone uses OpenEmbedded. I'd love to see a long term scalable >>> solution for tracking dts files, but that is outside the scope of >>> Moritz's request. >> >> Are you guys coming to ELCE? There will be Devicetree Workshop which >> will be good place to talk about this. > > Yeah, it's on Thursday, right? Yep Thursday but no exact time yet. M
Re: [BUG] vt6655: A possible sleep-in-atomic bug in vt6655_suspend
On Mon, Oct 09, 2017 at 09:10:28AM +0800, Jia-Ju Bai wrote: > According to device_main.c, the driver may sleep under a spinlock, > and the function call path is: > vt6655_suspend (acquire the spinlock) > pci_set_power_state > __pci_start_power_transition (drivers/pci/pci.c) > msleep --> may sleep > > A possible fix is to replace msleep with mdelay in > __pci_start_power_transition in drivers/pci/pci.c. Patches are usually best to send in for things that you find like this. thanks, greg k-h
Re: [PATCH V1] pinctrl: qcom: spmi-gpio: Update GPIO EN_CTL when setting pin config
On 10/6/2017 12:27 AM, Bjorn Andersson wrote:
On Mon 11 Sep 17:32 PDT 2017, fengl...@codeaurora.org wrote:
From: Fenglin Wu
GPIO is expected to be disabled iff PIN_CONFIG_BIAS_HIGH_IMPEDANCE is
configured. Update is_enabled flag in config_set() so that it can
reflect GPIO status correctly. Also modify EN_CTL register based on
is_enabled flag in config_set() to configure the GPIO properly.
Signed-off-by: Fenglin Wu
---
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index c2c0bab..a0edaa8 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -453,6 +453,7 @@ static int pmic_gpio_config_set(struct pinctrl_dev
*pctldev, unsigned int pin,
pad = pctldev->desc->pins[pin].drv_data;
+ pad->is_enabled = true;
for (i = 0; i < nconfs; i++) {
param = pinconf_to_config_param(configs[i]);
arg = pinconf_to_config_argument(configs[i]);
@@ -600,6 +601,10 @@ static int pmic_gpio_config_set(struct pinctrl_dev
*pctldev, unsigned int pin,
return ret;
}
+ val = pad->is_enabled << PMIC_GPIO_REG_MASTER_EN_SHIFT;
+
+ ret = pmic_gpio_write(state, pad, PMIC_GPIO_REG_EN_CTL, val);
+
This looks good.
Acked-by: Bjorn Andersson
But I spotted another issue while reviewing this; currently the initial
state of is_enabled is unconditionally set to enabled in
pmic_gpio_populate(), so reading the initial pinconf or configuring a
pinmux before setting a pinconf will operate on the potentially wrong
information.
So I think the initial value should be read out from REG_EN_CTL rather
than being just "true".
Can you please either submit another patch for this?
Hmm, considering a GPIO which is disabled by default in hardware
setting, what's its expected state if we only define "function" for it?
I was thinking we need to enable it once it has any setting in pinmux or
pinconf. If you think that we need to keep its original state until we
set pinconf for it, yes, I can submit a change to address this.
Regards,
Bjorn
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework
On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote: > On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote: > > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote: > > > Hello, > > > > > > One thing that comes up a lot every LSF is the fact that we have no > > > general way > > > that we do performance testing. Every fs developer has a set of scripts > > > or > > > things that they run with varying degrees of consistency, but nothing > > > central > > > that we all use. I for one am getting tired of finding regressions when > > > we are > > > deploying new kernels internally, so I wired this thing up to try and > > > address > > > this need. > > > > > > We all hate convoluted setups, the more brain power we have to put in to > > > setting > > > something up the less likely we are to use it, so I took the xfstests > > > approach > > > of making it relatively simple to get running and relatively easy to add > > > new > > > tests. For right now the only thing this framework does is run fio > > > scripts. I > > > chose fio because it already gathers loads of performance data about it's > > > runs. > > > We have everything we need there, latency, bandwidth, cpu time, and all > > > broken > > > down by reads, writes, and trims. I figure most of us are familiar > > > enough with > > > fio and how it works to make it relatively easy to add new tests to the > > > framework. > > > > > > I've posted my code up on github, you can get it here > > > > > > https://github.com/josefbacik/fsperf > > > > > > All (well most) of the results from fio are stored in a local sqlite > > > database. > > > Right now the comparison stuff is very crude, it simply checks against the > > > previous run and it only checks a few of the keys by default. You can > > > check > > > latency if you want, but while writing this stuff up it seemed that > > > latency was > > > too variable from run to run to be useful in a "did my thing regress or > > > improve" > > > sort of way. > > > > > > The configuration is brain dead simple, the README has examples. All you > > > need > > > to do is make your local.cfg, run ./setup and then run ./fsperf and you > > > are good > > > to go. > > > > Why re-invent the test infrastructure? Why not just make it a > > tests/perf subdir in fstests? > > > > Probably should have led with that shouldn't I have? There's nothing keeping > me > from doing it, but I didn't want to try and shoehorn in a python thing into > fstests. I need python to do the sqlite and the json parsing to dump into the > sqlite database. > > Now if you (and others) are not opposed to this being dropped into tests/perf > then I'll work that up. But it's definitely going to need to be done in > python. > I know you yourself have said you aren't opposed to using python in the past, > so > if that's still the case then I can definitely wire it all up. I have no problems with people using python for stuff like this but, OTOH, I'm not the fstests maintainer anymore :P > > > The plan is to add lots of workloads as we discover regressions and such. > > > We > > > don't want anything that takes too long to run otherwise people won't run > > > this, > > > so the existing tests don't take much longer than a few minutes each. I > > > will be > > > adding some more comparison options so you can compare against averages > > > of all > > > previous runs and such. > > > > Yup, that fits exactly into what fstests is for... :P > > > > Integrating into fstests means it will be immediately available to > > all fs developers, it'll run on everything that everyone already has > > setup for filesystem testing, and it will have familiar mkfs/mount > > option setup behaviour so there's no new hoops for everyone to jump > > through to run it... > > > > TBF I specifically made it as easy as possible because I know we all hate > trying > to learn new shit. Yeah, it's also hard to get people to change their workflows to add a whole new test harness into them. It's easy if it's just a new command to an existing workflow :P > I figured this was different enough to warrant a separate > project, especially since I'm going to add block device jobs so Jens can test > block layer things. If we all agree we'd rather see this in fstests then I'm > happy to do that too. Thanks, I'm not fussed either way - it's a good discussion to have, though. If I want to add tests (e.g. my time-honoured fsmark tests), where should I send patches? Cheers, Dave. -- Dave Chinner da...@fromorbit.com
RE: [RFC v5 7/8] platform/x86: intel_pmc_ipc: Use generic Intel IPC device calls
> From: sathyanarayanan.kuppusw...@linux.intel.com
> [mailto:sathyanarayanan.kuppusw...@linux.intel.com]
> Sent: Sunday, October 8, 2017 3:50 AM
> To: a.zu...@towertech.it; x...@kernel.org; w...@iguana.be;
> mi...@redhat.com; alexandre.bell...@free-electrons.com; Zha, Qipeng
> ; h...@zytor.com; dvh...@infradead.org;
> t...@linutronix.de; lee.jo...@linaro.org; a...@infradead.org; Chakravarty,
> Souvik K
> Cc: linux-...@vger.kernel.org; linux-watch...@vger.kernel.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org;
> sathyao...@gmail.com; Kuppuswamy Sathyanarayanan
>
> Subject: [RFC v5 7/8] platform/x86: intel_pmc_ipc: Use generic Intel IPC
> device calls
>
> From: Kuppuswamy Sathyanarayanan
>
>
> Removed redundant IPC helper functions and refactored the driver to use
> generic IPC device driver APIs. Also, cleaned up the driver to minimize the
> usage of global variable ipcdev by propogating the struct intel_pmc_ipc_dev
> pointer or by getting it from device private data.
>
> This patch also cleans-up PMC IPC user drivers(intel_telemetry_pltdrv.c,
> intel_soc_pmic_bxtwc.c) to use APIs provided by generic IPC driver.
>
> Signed-off-by: Kuppuswamy Sathyanarayanan
>
> ---
> arch/x86/include/asm/intel_pmc_ipc.h | 37 +--
> drivers/mfd/intel_soc_pmic_bxtwc.c| 21 +-
> drivers/platform/x86/intel_pmc_ipc.c | 393
> ++
> drivers/platform/x86/intel_telemetry_pltdrv.c | 119
> include/linux/mfd/intel_soc_pmic.h| 2 +
> 5 files changed, 238 insertions(+), 334 deletions(-)
>
> Changes since v4:
> * None
>
> Changes since v3:
> * Added unique name to PMC regmaps.
> * Added support to clear interrupt bit.
> * Added intel_ipc_dev_put() support.
>
> Changes since v1:
> * Removed custom APIs.
> * Cleaned up PMC IPC user drivers to use APIs provided by generic
>IPC driver.
>
> diff --git a/arch/x86/include/asm/intel_pmc_ipc.h
> b/arch/x86/include/asm/intel_pmc_ipc.h
> index fac89eb..9fc7c3c 100644
> --- a/arch/x86/include/asm/intel_pmc_ipc.h
> +++ b/arch/x86/include/asm/intel_pmc_ipc.h
> @@ -1,10 +1,15 @@
> #ifndef _ASM_X86_INTEL_PMC_IPC_H_
> #define _ASM_X86_INTEL_PMC_IPC_H_
>
> +#include
> +
> +#define INTEL_PMC_IPC_DEV"intel_pmc_ipc"
> +#define PMC_PARAM_LEN2
> +
> /* Commands */
> #define PMC_IPC_PMIC_ACCESS 0xFF
> -#define PMC_IPC_PMIC_ACCESS_READ0x0
> -#define PMC_IPC_PMIC_ACCESS_WRITE 0x1
> +#define PMC_IPC_PMIC_ACCESS_READ0x0
> +#define PMC_IPC_PMIC_ACCESS_WRITE 0x1
> #define PMC_IPC_USB_PWR_CTRL 0xF0
> #define PMC_IPC_PMIC_BLACKLIST_SEL 0xEF
> #define PMC_IPC_PHY_CONFIG 0xEE
> @@ -28,13 +33,14 @@
> #define PMC_GCR_TELEM_DEEP_S0IX_REG 0x78
> #define PMC_GCR_TELEM_SHLW_S0IX_REG 0x80
>
> +static inline void pmc_cmd_init(u32 *cmd, u32 param1, u32 param2) {
> + cmd[0] = param1;
> + cmd[1] = param2;
> +}
> +
> #if IS_ENABLED(CONFIG_INTEL_PMC_IPC)
>
> -int intel_pmc_ipc_simple_command(int cmd, int sub); -int
> intel_pmc_ipc_raw_cmd(u32 cmd, u32 sub, u8 *in, u32 inlen,
> - u32 *out, u32 outlen, u32 dptr, u32 sptr);
> -int intel_pmc_ipc_command(u32 cmd, u32 sub, u8 *in, u32 inlen,
> - u32 *out, u32 outlen);
> int intel_pmc_s0ix_counter_read(u64 *data); int intel_pmc_gcr_read(u32
> offset, u32 *data); int intel_pmc_gcr_write(u32 offset, u32 data); @@ -42,23
> +48,6 @@ int intel_pmc_gcr_update(u32 offset, u32 mask, u32 val);
>
> #else
>
> -static inline int intel_pmc_ipc_simple_command(int cmd, int sub) -{
> - return -EINVAL;
> -}
> -
> -static inline int intel_pmc_ipc_raw_cmd(u32 cmd, u32 sub, u8 *in, u32
> inlen,
> - u32 *out, u32 outlen, u32 dptr, u32 sptr)
> -{
> - return -EINVAL;
> -}
> -
> -static inline int intel_pmc_ipc_command(u32 cmd, u32 sub, u8 *in, u32
> inlen,
> - u32 *out, u32 outlen)
> -{
> - return -EINVAL;
> -}
> -
> static inline int intel_pmc_s0ix_counter_read(u64 *data) {
> return -EINVAL;
> diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c
> b/drivers/mfd/intel_soc_pmic_bxtwc.c
> index 15bc052..f9df9e7 100644
> --- a/drivers/mfd/intel_soc_pmic_bxtwc.c
> +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
> @@ -271,6 +271,8 @@ static int regmap_ipc_byte_reg_read(void *context,
> unsigned int reg,
> u8 ipc_in[2];
> u8 ipc_out[4];
> struct intel_soc_pmic *pmic = context;
> + u32 cmd[PMC_PARAM_LEN] = {PMC_IPC_PMIC_ACCESS,
> + PMC_IPC_PMIC_ACCESS_READ};
>
> if (!pmic)
> return -EINVAL;
> @@ -284,9 +286,8 @@ static int regmap_ipc_byte_reg_read(void *context,
> unsigned int reg,
>
> ipc_in[0] = reg;
> ipc_in[1] = i2c_addr;
> - ret = intel_pmc_ipc_command(PMC_IPC_PMIC_ACCESS,
> - PMC_IPC_PMIC_ACCESS_READ,
> - ipc_in, sizeof(ipc_in), (u32 *)ipc_out, 1);
> + ret = ipc
RE: [RFC v5 6/8] platform/x86: intel_punit_ipc: Use generic intel ipc device calls
> From: sathyanarayanan.kuppusw...@linux.intel.com
> [mailto:sathyanarayanan.kuppusw...@linux.intel.com]
> Sent: Sunday, October 8, 2017 3:50 AM
> To: a.zu...@towertech.it; x...@kernel.org; w...@iguana.be;
> mi...@redhat.com; alexandre.bell...@free-electrons.com; Zha, Qipeng
> ; h...@zytor.com; dvh...@infradead.org;
> t...@linutronix.de; lee.jo...@linaro.org; a...@infradead.org; Chakravarty,
> Souvik K
> Cc: linux-...@vger.kernel.org; linux-watch...@vger.kernel.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org;
> sathyao...@gmail.com; Kuppuswamy Sathyanarayanan
>
> Subject: [RFC v5 6/8] platform/x86: intel_punit_ipc: Use generic intel ipc
> device calls
>
> From: Kuppuswamy Sathyanarayanan
>
>
> Removed redundant IPC helper functions and refactored the driver to use
> APIs provided by generic IPC driver. This patch also cleans-up PUNIT IPC user
> drivers(intel_telemetry_pltdrv.c) to use APIs provided by generic IPC driver.
>
> Signed-off-by: Kuppuswamy Sathyanarayanan
>
> ---
> arch/x86/include/asm/intel_punit_ipc.h| 125 +--
> drivers/platform/x86/Kconfig | 1 +
> drivers/platform/x86/intel_punit_ipc.c| 303
> ++
> drivers/platform/x86/intel_telemetry_pltdrv.c | 97 +
> 4 files changed, 223 insertions(+), 303 deletions(-)
>
> Changes since v4:
> * None
>
> Changes since v2:
> * Added unique name to PUNIT BIOS, GTD, & ISP regmaps.
> * Added intel_ipc_dev_put() support.
>
> Changes since v1:
> * Removed custom APIs.
> * Cleaned up PUNIT IPC user drivers to use APIs provided by generic
>IPC driver.
>
> diff --git a/arch/x86/include/asm/intel_punit_ipc.h
> b/arch/x86/include/asm/intel_punit_ipc.h
> index 201eb9d..cf1630c 100644
> --- a/arch/x86/include/asm/intel_punit_ipc.h
> +++ b/arch/x86/include/asm/intel_punit_ipc.h
> @@ -1,10 +1,8 @@
> #ifndef _ASM_X86_INTEL_PUNIT_IPC_H_
> #define _ASM_X86_INTEL_PUNIT_IPC_H_
>
> -/*
> - * Three types of 8bit P-Unit IPC commands are supported,
> - * bit[7:6]: [00]: BIOS; [01]: GTD; [10]: ISPD.
> - */
> +#include
> +
> typedef enum {
> BIOS_IPC = 0,
> GTDRIVER_IPC,
> @@ -12,61 +10,60 @@ typedef enum {
> RESERVED_IPC,
> } IPC_TYPE;
>
> -#define IPC_TYPE_OFFSET 6
> -#define IPC_PUNIT_BIOS_CMD_BASE (BIOS_IPC <<
> IPC_TYPE_OFFSET)
> -#define IPC_PUNIT_GTD_CMD_BASE (GTDDRIVER_IPC <<
> IPC_TYPE_OFFSET)
> -#define IPC_PUNIT_ISPD_CMD_BASE (ISPDRIVER_IPC <<
> IPC_TYPE_OFFSET)
> -#define IPC_PUNIT_CMD_TYPE_MASK (RESERVED_IPC <<
> IPC_TYPE_OFFSET)
> +#define PUNIT_BIOS_IPC_DEV "punit_bios_ipc"
> +#define PUNIT_GTD_IPC_DEV"punit_gtd_ipc"
> +#define PUNIT_ISP_IPC_DEV"punit_isp_ipc"
> +#define PUNIT_PARAM_LEN 3
>
> /* BIOS => Pcode commands */
> -#define IPC_PUNIT_BIOS_ZERO (IPC_PUNIT_BIOS_CMD_BASE
> | 0x00)
> -#define IPC_PUNIT_BIOS_VR_INTERFACE
> (IPC_PUNIT_BIOS_CMD_BASE | 0x01)
> -#define IPC_PUNIT_BIOS_READ_PCS
> (IPC_PUNIT_BIOS_CMD_BASE | 0x02)
> -#define IPC_PUNIT_BIOS_WRITE_PCS (IPC_PUNIT_BIOS_CMD_BASE
> | 0x03)
> -#define IPC_PUNIT_BIOS_READ_PCU_CONFIG
> (IPC_PUNIT_BIOS_CMD_BASE | 0x04)
> -#define IPC_PUNIT_BIOS_WRITE_PCU_CONFIG
> (IPC_PUNIT_BIOS_CMD_BASE | 0x05)
> -#define IPC_PUNIT_BIOS_READ_PL1_SETTING
> (IPC_PUNIT_BIOS_CMD_BASE | 0x06)
> -#define IPC_PUNIT_BIOS_WRITE_PL1_SETTING (IPC_PUNIT_BIOS_CMD_BASE
> | 0x07)
> -#define IPC_PUNIT_BIOS_TRIGGER_VDD_RAM
> (IPC_PUNIT_BIOS_CMD_BASE | 0x08)
> -#define IPC_PUNIT_BIOS_READ_TELE_INFO
> (IPC_PUNIT_BIOS_CMD_BASE | 0x09)
> -#define IPC_PUNIT_BIOS_READ_TELE_TRACE_CTRL
> (IPC_PUNIT_BIOS_CMD_BASE | 0x0a)
> -#define IPC_PUNIT_BIOS_WRITE_TELE_TRACE_CTRL
> (IPC_PUNIT_BIOS_CMD_BASE | 0x0b)
> -#define IPC_PUNIT_BIOS_READ_TELE_EVENT_CTRL
> (IPC_PUNIT_BIOS_CMD_BASE | 0x0c)
> -#define IPC_PUNIT_BIOS_WRITE_TELE_EVENT_CTRL
> (IPC_PUNIT_BIOS_CMD_BASE | 0x0d)
> -#define IPC_PUNIT_BIOS_READ_TELE_TRACE
> (IPC_PUNIT_BIOS_CMD_BASE | 0x0e)
> -#define IPC_PUNIT_BIOS_WRITE_TELE_TRACE
> (IPC_PUNIT_BIOS_CMD_BASE | 0x0f)
> -#define IPC_PUNIT_BIOS_READ_TELE_EVENT
> (IPC_PUNIT_BIOS_CMD_BASE | 0x10)
> -#define IPC_PUNIT_BIOS_WRITE_TELE_EVENT
> (IPC_PUNIT_BIOS_CMD_BASE | 0x11)
> -#define IPC_PUNIT_BIOS_READ_MODULE_TEMP
> (IPC_PUNIT_BIOS_CMD_BASE | 0x12)
> -#define IPC_PUNIT_BIOS_RESERVED
> (IPC_PUNIT_BIOS_CMD_BASE | 0x13)
> -#define IPC_PUNIT_BIOS_READ_VOLTAGE_OVER
> (IPC_PUNIT_BIOS_CMD_BASE | 0x14)
> -#define IPC_PUNIT_BIOS_WRITE_VOLTAGE_OVER
> (IPC_PUNIT_BIOS_CMD_BASE | 0x15)
> -#define IPC_PUNIT_BIOS_READ_RATIO_OVER
> (IPC_PUNIT_BIOS_CMD_BASE | 0x16)
> -#define IPC_PUNIT_BIOS_WRITE_RATIO_OVER
> (IPC_PUNIT_BIOS_CMD_BASE | 0x17)
> -#define IPC_PUNIT_BIOS_READ_VF_GL_CTRL
> (IPC_PUNIT_BIOS_CMD_B
Re: [BUG] mm/vmalloc: ___might_sleep is called under a spinlock in __purge_vmap_area_lazy
Thanks for your reply and explanation :) I will improve my analysis. Thanks, Jia-Ju Bai On 2017/10/9 12:10, Kirill A. Shutemov wrote: On Mon, Oct 09, 2017 at 12:00:33PM +0800, Jia-Ju Bai wrote: The ___might_sleep is called under a spinlock, and the function call graph is: __purge_vmap_area_lazy (acquire the spinlock) cond_resched_lock ___might_sleep In this situation, ___might_sleep may prints error log message because a spinlock is held. A possible fix is to remove ___might_sleep in cond_resched_lock. This bug is found by my static analysis tool and my code review. This analysis doesn't makes sense. The point of cond_resched_lock() is that it drops the lock, if resched is required. ___might_sleep() is called with preempt_offset equal to PREEMPT_LOCK_OFFSET, so it won't report error if it's the only lock we hold.
Re: linux-4.14-rc3/arch/powerpc/perf/imc-pmu.c:599: pointless test ?
David Binderman writes:
> Hello there,
>
> linux-4.14-rc3/arch/powerpc/perf/imc-pmu.c:599]: (style) Unsigned variable
> 'ncpu' can't be negative so it is unnecessary to test it.
>
> Source code is
>
> if (ncpu >= 0 && ncpu < nr_cpu_ids) {
>
> but
>
> unsigned int ncpu, core_id;
>
> Suggest remove test.
Thanks.
Notifying the author would be more helpful:
$ git blame -L 599,599 arch/powerpc/perf/imc-pmu.c
39a846db1d574 (Anju T Sudhakar 2017-07-19 03:06:35 +0530 599) if (ncpu >= 0
&& ncpu < nr_cpu_ids) {
$ git log -1 --format=%ae 39a846db1d574
a...@linux.vnet.ibm.com
cheers
RE: [RFC v5 4/8] platform: x86: Add generic Intel IPC driver
> From: sathyanarayanan.kuppusw...@linux.intel.com
> [mailto:sathyanarayanan.kuppusw...@linux.intel.com]
> Sent: Sunday, October 8, 2017 3:50 AM
> To: a.zu...@towertech.it; x...@kernel.org; w...@iguana.be;
> mi...@redhat.com; alexandre.bell...@free-electrons.com; Zha, Qipeng
> ; h...@zytor.com; dvh...@infradead.org;
> t...@linutronix.de; lee.jo...@linaro.org; a...@infradead.org; Chakravarty,
> Souvik K
> Cc: linux-...@vger.kernel.org; linux-watch...@vger.kernel.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org;
> sathyao...@gmail.com; Kuppuswamy Sathyanarayanan
>
> Subject: [RFC v5 4/8] platform: x86: Add generic Intel IPC driver
>
> From: Kuppuswamy Sathyanarayanan
>
>
> Currently intel_scu_ipc.c, intel_pmc_ipc.c and intel_punit_ipc.c redundantly
> implements the same IPC features and has lot of code duplication between
> them. This driver addresses this issue by grouping the common IPC
> functionalities under the same driver.
>
> Signed-off-by: Kuppuswamy Sathyanarayanan
>
> ---
> drivers/platform/x86/Kconfig| 8 +
> drivers/platform/x86/Makefile | 1 +
> drivers/platform/x86/intel_ipc_dev.c| 576
>
> include/linux/platform_data/x86/intel_ipc_dev.h | 206 +
> 4 files changed, 791 insertions(+)
> create mode 100644 drivers/platform/x86/intel_ipc_dev.c
> create mode 100644 include/linux/platform_data/x86/intel_ipc_dev.h
>
> Changes since v4:
> * None
>
> Changes since v3:
> * Fixed NULL pointer exception in intel_ipc_dev_get().
> * Fixed error in check for duplicate intel_ipc_dev.
> * Added custom interrupt handler support.
> * Used char array for error string conversion.
> * Added put dev support.
> * Added devm_* variant of intel_ipc_dev_get().
>
> Changes since v2:
> * Added ipc_dev_cmd API support.
>
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index da2d9ba..724ee696 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -1153,6 +1153,14 @@ config SILEAD_DMI
> with the OS-image for the device. This option supplies the missing
> information. Enable this for x86 tablets with Silead touchscreens.
>
> +config INTEL_IPC_DEV
> + bool "Intel IPC Device Driver"
> + depends on X86_64
> + ---help---
> + This driver implements core features of Intel IPC device. Devices
> + like PMC, SCU, PUNIT, etc can use interfaces provided by this
> + driver to implement IPC protocol of their respective device.
> +
> endif # X86_PLATFORM_DEVICES
>
> config PMC_ATOM
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index 2b315d0..99a1af1 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -84,3 +84,4 @@ obj-$(CONFIG_PMC_ATOM) +=
> pmc_atom.o
> obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
> obj-$(CONFIG_MLX_CPLD_PLATFORM) += mlxcpld-hotplug.o
> obj-$(CONFIG_INTEL_TURBO_MAX_3) += intel_turbo_max_3.o
> +obj-$(CONFIG_INTEL_IPC_DEV) += intel_ipc_dev.o
> diff --git a/drivers/platform/x86/intel_ipc_dev.c
> b/drivers/platform/x86/intel_ipc_dev.c
> new file mode 100644
> index 000..f55ddec
> --- /dev/null
> +++ b/drivers/platform/x86/intel_ipc_dev.c
> @@ -0,0 +1,576 @@
> +/*
> + * intel_ipc_dev.c: Intel IPC device class driver
> + *
> + * (C) Copyright 2017 Intel Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; version 2
> + * of the License.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* mutex to sync different ipc devices in same channel */ static struct
> +mutex channel_lock[IPC_CHANNEL_MAX];
> +
> +static char *ipc_err_sources[] = {
> + [IPC_DEV_ERR_NONE] =
> + "No error",
> + [IPC_DEV_ERR_CMD_NOT_SUPPORTED] =
> + "Command not-supported/Invalid",
> + [IPC_DEV_ERR_CMD_NOT_SERVICED] =
> + "Command not-serviced/Invalid param",
> + [IPC_DEV_ERR_UNABLE_TO_SERVICE] =
> + "Unable-to-service/Cmd-timeout",
> + [IPC_DEV_ERR_CMD_INVALID] =
> + "Command-invalid/Cmd-locked",
> + [IPC_DEV_ERR_CMD_FAILED] =
> + "Command-failed/Invalid-VR-id",
> + [IPC_DEV_ERR_EMSECURITY] =
> + "Invalid Battery/VR-Error",
> + [IPC_DEV_ERR_UNSIGNEDKERNEL] =
> + "Unsigned kernel",
> +};
> +
> +static void ipc_channel_lock_init(void) {
> + int i;
> +
> + for (i = 0; i < IPC_CHANNEL_MAX; i++)
> + mutex_init(&channel_lock[i]);
> +}
> +
> +static struct class intel_ipc_class = {
> + .name = "intel_ipc",
> + .owner = THIS_MODULE,
> +};
> +
> +static int ipc_dev_lock(struct intel_ipc_dev *ipc_dev) {
> + int ch
[PATCH] x86/mm/64: Fix reboot interaction with CR4.PCIDE
Trying to reboot via real mode fails with PCID on: long mode cannot
be exited while CR4.PCIDE is set. (No, I have no idea why, but the
SDM and actual CPUs are in agreement here.) The result is a GPF and
a hang instead of a reboot.
I didn't catch this in testing because neither my computer nor my VM
reboots this way. I can trigger it with reboot=bios, though.
Fixes: 660da7c9228f ("x86/mm: Enable CR4.PCIDE on supported systems")
Reported-by: Steven Rostedt (VMware)
Tested-by: Steven Rostedt (VMware)
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/reboot.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 54180fa6f66f..add33f600531 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -105,6 +105,10 @@ void __noreturn machine_real_restart(unsigned int type)
load_cr3(initial_page_table);
#else
write_cr3(real_mode_header->trampoline_pgd);
+
+ /* Exiting long mode will fail if CR4.PCIDE is set. */
+ if (static_cpu_has(X86_FEATURE_PCID))
+ cr4_clear_bits(X86_CR4_PCIDE);
#endif
/* Jump to the identity-mapped low memory code */
--
2.13.6
Re: Linux 4.14-rc4
On Sun, 2017-10-08 at 21:18 -0700, Linus Torvalds wrote: > Another week, another -rc. Any idea if you want to break up MAINTAINERS?
Re: netlink backwards compatibility in userspace tools
From: "Jason A. Donenfeld"
Date: Fri, 29 Sep 2017 12:22:42 +0200
> One handy aspect of Netlink is that it's backwards compatible. This
> means that you can run old userspace utilities on new kernels, even if
> the new kernel supports new features and netlink attributes. The wire
> format is stable enough that the data marshaled can be extended
> without breaking compat. Neat.
>
> I was wondering, though, what you think the best stance is toward
> these old userspace utilities. What should they do if the kernel sends
> it netlink attributes that it does not recognize? At the moment, I'm
> doing something like this:
>
> static void warn_unrecognized(void)
> {
> static bool once = false;
> if (once)
> return;
> once = true;
> fprintf(stderr,
> "Warning: this program received from your kernel one or more\n"
> "attributes that it did not recognize. It is possible that\n"
> "this version of wg(8) is older than your kernel. You may\n"
> "want to update this program.\n");
> }
>
> This seems like a somewhat sensible warning, but then I wonder about
> distributions like Debian, which has a long stable life cycle, so it
> frequently has very old tools (ancient iproute2 for example). Then,
> VPS providers have these Debian images run on top of newer kernels.
> People in this situation would undoubtedly see the above warning a lot
> and not be able to do anything about it. Not horrible, but a bit
> annoying. Is this an okay annoyance? Or is it advised to just have no
> warning at all? One idea would be to put it behind an environment
> variable flag, but I don't like too many nobs.
>
> I'm generally wondering about attitudes toward this kind of userspace
> program behavior in response to newer kernels.
Generally, yes you should simply ignore attributes you don't understand.
But we keep coming back to this issue, because it's not always the best
thing to do.
For example, let's say you have settings X and Y for object A.
User A has a newer tool and is able to set both X and Y, as well as
see them in dumps. And let's further assume that Y's setting has some
kind of influence on the behavior of X.
User B has an older tool, and sees X but not Y because Y is not
understood by the older tool. User B will not be able to figure out
why X is not behaving the way they expect it to, because of the loss
of information.
Similar, even more serious, issues arise when setting values. User B
can set X and wonder why it's not doing what they expect it to do
because of setting Y which they can't even see with their tools.
For this reason it might be beneficical to at least say to the user
"Warning, I've seen one or more unrecognized netlink attributes."
so that there is at least a chance for the user to figure out what
might be happening to them.
Re: [PATCH v3 3/5] sparc64: SPARC optimised fls function
From: Vijay Kumar Date: Fri, 6 Oct 2017 10:54:51 -0600 > +#define LXCNT_O0_G2 \ > + .word 0x85b002e8 > + > + .text > + .register %g2, #scratch > + .register %g3, #scratch > + > +ENTRY(NG4fls) > + LXCNT_O0_G2 !lzcnt %o0, %g2 Agreed with others that you should name this LZCNT_* instead of LXCNT_*.
Re: [PATCH V5 4/7] blk-mq: introduce blk_mq_dequeue_from_ctx()
On Tue, Oct 03, 2017 at 02:01:09AM -0700, Christoph Hellwig wrote:
> On Sat, Sep 30, 2017 at 06:27:17PM +0800, Ming Lei wrote:
> > This function is introduced for dequeuing request
> > from sw queue so that we can dispatch it in
> > scheduler's way.
> >
> > More importantly, some SCSI devices may set
> > q->queue_depth, which is a per-request_queue limit,
> > and applied on pending I/O from all hctxs. This
> > function is introduced for avoiding to dequeue too
> > many requests from sw queue when ->dispatch isn't
> > flushed completely.
>
> Weird commit log formatting, please use your 70+ chacters to format the
> text.
OK.
>
> > @@ -882,6 +882,44 @@ void blk_mq_flush_busy_ctxs(struct blk_mq_hw_ctx
> > *hctx, struct list_head *list)
> > }
> > EXPORT_SYMBOL_GPL(blk_mq_flush_busy_ctxs);
> >
> > +struct dispatch_rq_data {
> > + struct blk_mq_hw_ctx *hctx;
> > + struct request *rq;
> > +};
> > +
> > +static bool dispatch_rq_from_ctx(struct sbitmap *sb, unsigned int bitnr,
> > void *data)
>
> Overly long line.
>
> But except for that this looks ok to me except for the fact that you
> just add an unused function.
OK
--
Ming
Re: [PATCH V5 8/8] blk-mq: improve bio merge from blk-mq sw queue
On Tue, Oct 03, 2017 at 02:21:43AM -0700, Christoph Hellwig wrote: > This looks generally good to me, but I really worry about the impact > on very high iops devices. Did you try this e.g. for random reads > from unallocated blocks on an enterprise NVMe SSD? Looks no such impact, please see the following data in the fio test(libaio, direct, bs=4k, 64jobs, randread, none scheduler) [root@storageqe-62 results]# ../parse_fio 4.14.0-rc2.no_blk_mq_perf+-nvme-64jobs-mq-none.log 4.14.0-rc2.BLK_MQ_PERF_V5+-nvme-64jobs-mq-none.log --- IOPS(K) |NONE |NONE --- randread | 650.98 | 653.15 --- OR: If you worry about this impact, can we simply disable merge on NVMe for none scheduler? It is basically impossible to merge NVMe's request/bio when none is used, but it can be doable in case of kyber scheduler. -- Ming
Re: [PATCH] qed: Delete redundant check on dcb_app priority
From: Christos Gkekas Date: Sun, 8 Oct 2017 23:46:47 +0100 > dcb_app priority is unsigned thus checking whether it is less than zero > is redundant. > > Signed-off-by: Christos Gkekas Applied to net-next.
Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.
From: Tim Hansen Date: Sun, 8 Oct 2017 16:03:38 -0400 > Mistakenly sent the patch previously with a missing semicolon. > Apologies. > > Fix BUG() calls to use BUG_ON(conditional) macros. > > This was found using make coccicheck M=net/core on linux next > tag next-20170929 > > Signed-off-by: Tim Hansen You're going to have to submit this new version again, the way you replied to the original patch caused the fixed version to not get queued up in patchwork properly.
Re: [PATCH] net: ethernet: stmmac: Clean up dead code
From: Christos Gkekas Date: Sun, 8 Oct 2017 20:13:49 +0100 > Many macros in dwmac-ipq806x are unused and should be removed. > Moreover gmac->id is an unsigned variable and therefore checking > whether it is less than zero is redundant. > > Signed-off-by: Christos Gkekas Applied.
Linux 4.14-rc4
Another week, another -rc.
This release does seem to continue to be more active in the rc's than
usual, but it actually feels like it's calming down. So rc4 is larger
than an rc4 release usually is (about 400 non-merge commits, when
usually at this stage we should be at ~300), but at the same time it
feels fairly normal. There was the watchdog merge that I already
mentioned in the rc3 release, but other than that it looks much more
like a normal rc than rc3 did, for example.
In particular, ignoring that core watchdog thing, it's the usual
"mostly drivers and arch updates". This time most of the arch updates
(by far) are arm, and the driver5s are dominated by networking, but
there's other stuff in there too (USB, MMC, HID..). And then the usual
random stuff elsewhere.
The good news is that the diffstat is pretty flat - ie the changes are
pretty small. The exception is that core watchdog thing, and some
stm32 dts-file reorg.
So I do have some hope that things are approaching normal. I'd expect
that to continue, and things start calming down. If rc5 doesn't show
noticeable signs of that calming down, I suspect we'll have to start
thinking about rc8 etc, but we'll see The kernel summit is
approaching, so people will be traveling later in the release cycle.
We'll see how that affects things too.
Anyway, shortlog appended, go out and test,
Linus
---
Aaron Armstrong Skomra (1):
HID: wacom: leds: Don't try to control the EKR's read-only LEDs
Adam Wallis (1):
usb: host: xhci-plat: allow sysdev to inherit from ACPI
Adrian Salido (1):
HID: i2c-hid: allocate hid buffers for real worst case
Akinobu Mita (1):
iio: adc: ti-ads1015: fix comparator polarity setting
Alan Stern (9):
usb-storage: fix bogus hardware error messages for ATA pass-thru devices
usb-storage: unusual_devs entry to fix write-access regression
for Seagate external drives
USB: uas: fix bug in handling of alternate settings
USB: gadgetfs: fix copy_to_user while holding spinlock
USB: gadgetfs: Fix crash caused by inadequate synchronization
USB: g_mass_storage: Fix deadlock when driver is unbound
USB: dummy-hcd: fix connection failures (wrong speed)
USB: dummy-hcd: fix infinite-loop resubmission bug
USB: dummy-hcd: Fix erroneous synchronization change
Aleksander Morgado (1):
rndis_host: support Novatel Verizon USB730L
Alexander Potapenko (1):
tun: bail out from tun_get_user() if the skb is empty
Alexander Shishkin (3):
stm class: Fix a use-after-free
intel_th: pci: Add Cedar Fork PCH support
intel_th: pci: Add Lewisburg PCH support
Alexandre Belloni (1):
ARM: at91: Replace uses of virt_to_phys with __pa_symbol
Alexandre Torgue (2):
ARM: dts: stm32: Fix STMPE1600 binding on stm32429i-eval board
ARM: dts: stm32: use right pinctrl compatible for stm32f469
Alexandru Moise (1):
mm, hugetlb, soft_offline: save compound page order before page migration
Alexei Starovoitov (1):
bpf: fix bpf_tail_call() x64 JIT
Alexey Brodkin (1):
ARC: [*defconfig] Reenable soft lock-up detector
Alexey Khoroshilov (1):
serial: sccnxp: Fix error handling in sccnxp_probe()
Alexey Kodanev (1):
vti: fix use after free in vti_tunnel_xmit/vti6_tnl_xmit
Amir Goldstein (6):
ovl: fix may_write_real() for overlayfs directories
ovl: fix error value printed in ovl_lookup_index()
ovl: fix dput() of ERR_PTR in ovl_cleanup_index()
ovl: fix dentry leak in ovl_indexdir_cleanup()
ovl: fix missing unlock_rename() in ovl_do_copy_up()
ovl: fix regression caused by exclusive upper/work dir protection
Amrani, Ram (2):
RDMA/qedr: Parse VLAN ID correctly and ignore the value of zero
RDMA/qedr: Parse vlan priority as sl
Andrea Arcangeli (1):
userfaultfd: non-cooperative: fix fork use after free
Andrew Lunn (1):
net: dsa: mv88e6xxx: Allow dsa and cpu ports in multiple vlans
Andrey Konovalov (2):
uwb: ensure that endpoint is interrupt
uwb: properly check kthread_run return value
Antoine Tenart (1):
net: mvpp2: do not select the internal source clock
Anton Blanchard (1):
powerpc/powernv: Increase memory block size to 1GB on radix
Ard Biesheuvel (1):
ahci: don't ignore result code of ahci_reset_controller()
Arend Van Spriel (2):
brcmfmac: add length check in brcmf_cfg80211_escan_handler()
brcmfmac: setup passive scan if requested by user-space
Arnd Bergmann (10):
ata: avoid gcc-7 warning in ata_timing_quantize
staging: unisys/visorbus: add __init/__exit annotations
android: binder: fix type mismatch warning
usb: gadget: dummy: fix nonsensical comparisons
ath10k: mark PM functions as __maybe_unused
rocker: fix rocker_tlv_put_* functions for KASAN
netlink: fix nla_put_{u8,u16,u32} for KASAN
mm: meminit: mark init_reserved_page as __meminit
ARM: defconfig: FR
Re: [BUG] mm/vmalloc: ___might_sleep is called under a spinlock in __purge_vmap_area_lazy
On Mon, Oct 09, 2017 at 12:00:33PM +0800, Jia-Ju Bai wrote: > The ___might_sleep is called under a spinlock, and the function call graph > is: > __purge_vmap_area_lazy (acquire the spinlock) > cond_resched_lock > ___might_sleep > > In this situation, ___might_sleep may prints error log message because a > spinlock is held. > A possible fix is to remove ___might_sleep in cond_resched_lock. > > This bug is found by my static analysis tool and my code review. This analysis doesn't makes sense. The point of cond_resched_lock() is that it drops the lock, if resched is required. ___might_sleep() is called with preempt_offset equal to PREEMPT_LOCK_OFFSET, so it won't report error if it's the only lock we hold. -- Kirill A. Shutemov
Re: [RFC PATCH] mm: shm: round up tmpfs size to huge page size when huge=always
On Mon, Oct 09, 2017 at 03:51:06AM +0800, Yang Shi wrote: > > > On 10/8/17 5:56 AM, Kirill A. Shutemov wrote: > > On Sat, Oct 07, 2017 at 04:22:10AM +0800, Yang Shi wrote: > > > When passing "huge=always" option for mounting tmpfs, THP is supposed to > > > be allocated all the time when it can fit, but when the available space is > > > smaller than the size of THP (2MB on x86), shmem fault handler still tries > > > to allocate huge page every time, then fallback to regular 4K page > > > allocation, i.e.: > > > > > > # mount -t tmpfs -o huge,size=3000k tmpfs /tmp > > > # dd if=/dev/zero of=/tmp/test bs=1k count=2048 > > > # dd if=/dev/zero of=/tmp/test1 bs=1k count=2048 > > > > > > The last dd command will handle 952 times page fault handler, then exit > > > with -ENOSPC. > > > > > > Rounding up tmpfs size to THP size in order to use THP with "always" > > > more efficiently. And, it will not wast too much memory (just allocate > > > 511 extra pages in worst case). > > > > Hm. I don't think it's good idea to silently increase size of fs. > > How about printing a warning to say the filesystem is resized? > > > > > Maybe better just refuse to mount with huge=always for too small fs? > > It sounds fine too. When mounting tmpfs with "huge=always", if the size is > not THP size aligned, it just can refuse to mount, then show warning about > alignment restriction. Honestly, I wouldn't bother. Using filesystem at near-full capacity is not best practice. Performance penalty for doing is fair enough. And forcing alignment doesn't really fixes anything: user still allowed to fill the filesystem with files less than 2M in size. -- Kirill A. Shutemov
[BUG] mm/vmalloc: ___might_sleep is called under a spinlock in __purge_vmap_area_lazy
The ___might_sleep is called under a spinlock, and the function call graph is: __purge_vmap_area_lazy (acquire the spinlock) cond_resched_lock ___might_sleep In this situation, ___might_sleep may prints error log message because a spinlock is held. A possible fix is to remove ___might_sleep in cond_resched_lock. This bug is found by my static analysis tool and my code review. Thanks, Jia-Ju Bai
[PATCH] timers: avoid an unnecessory iteration in __run_timers()
When we know next expired timer is later than current jiffies, we don't need to
call collect_expired_timers() again checking empty hlists.
Signed-off-by: Zhenzhong Duan
---
kernel/time/timer.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index f2674a0..02be824 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1560,8 +1560,7 @@ static int collect_expired_timers(struct timer_base *base,
* jiffies, otherwise forward to the next expiry time:
*/
if (time_after(next, jiffies)) {
- /* The call site will increment clock! */
- base->clk = jiffies - 1;
+ base->clk = jiffies;
return 0;
}
base->clk = next;
--
1.7.3
[PATCH v2] kbuild: comments cleanup in Makefile.lib
It has: 1. Move comments close to what it want to comment. 2. Comments cleanup & improvement. Signed-off-by: Cao jin --- scripts/Makefile.lib | 21 +++-- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 5e975fe..580e605 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -4,8 +4,7 @@ ccflags-y += $(EXTRA_CFLAGS) cppflags-y += $(EXTRA_CPPFLAGS) ldflags-y += $(EXTRA_LDFLAGS) -# -# flags that take effect in sub directories +# flags that take effect in current and sub directories export KBUILD_SUBDIR_ASFLAGS := $(KBUILD_SUBDIR_ASFLAGS) $(subdir-asflags-y) export KBUILD_SUBDIR_CCFLAGS := $(KBUILD_SUBDIR_CCFLAGS) $(subdir-ccflags-y) @@ -14,14 +13,16 @@ export KBUILD_SUBDIR_CCFLAGS := $(KBUILD_SUBDIR_CCFLAGS) $(subdir-ccflags-y) # When an object is listed to be built compiled-in and modular, # only build the compiled-in version - obj-m := $(filter-out $(obj-y),$(obj-m)) # Libraries are always collected in one lib file. # Filter out objects already built-in - lib-y := $(filter-out $(obj-y), $(sort $(lib-y) $(lib-m))) +# Determine modorder. +# Unfortunately, we don't have information about ordering between -y +# and -m subdirs. Just put -y's first. +modorder := $(patsubst %/,%/modules.order, $(filter %/, $(obj-y)) $(obj-m:.o=.ko)) # Handle objects in subdirs # --- @@ -29,12 +30,6 @@ lib-y := $(filter-out $(obj-y), $(sort $(lib-y) $(lib-m))) # and add the directory to the list of dirs to descend into: $(subdir-y) # o if we encounter foo/ in $(obj-m), remove it from $(obj-m) # and add the directory to the list of dirs to descend into: $(subdir-m) - -# Determine modorder. -# Unfortunately, we don't have information about ordering between -y -# and -m subdirs. Just put -y's first. -modorder := $(patsubst %/,%/modules.order, $(filter %/, $(obj-y)) $(obj-m:.o=.ko)) - __subdir-y := $(patsubst %/,%,$(filter %/, $(obj-y))) subdir-y += $(__subdir-y) __subdir-m := $(patsubst %/,%,$(filter %/, $(obj-m))) @@ -43,10 +38,9 @@ obj-y:= $(patsubst %/, %/built-in.o, $(obj-y)) obj-m := $(filter-out %/, $(obj-m)) # Subdirectories we need to descend into - subdir-ym := $(sort $(subdir-y) $(subdir-m)) -# if $(foo-objs) exists, foo.o is a composite object +# if $(foo-objs), $(foo-y), or $(foo-m) exists, foo.o is a composite object multi-used-y := $(sort $(foreach m,$(obj-y), $(if $(strip $($(m:.o=-objs)) $($(m:.o=-y))), $(m multi-used-m := $(sort $(foreach m,$(obj-m), $(if $(strip $($(m:.o=-objs)) $($(m:.o=-y)) $($(m:.o=-m))), $(m multi-used := $(multi-used-y) $(multi-used-m) @@ -90,8 +84,7 @@ subdir-ym := $(addprefix $(obj)/,$(subdir-ym)) obj-dirs := $(addprefix $(obj)/,$(obj-dirs)) # These flags are needed for modversions and compiling, so we define them here -# already -# $(modname_flags) #defines KBUILD_MODNAME as the name of the module it will +# $(modname_flags) defines KBUILD_MODNAME as the name of the module it will # end up in (or would, if it gets compiled in) # Note: Files that end up in two or more modules are compiled without the # KBUILD_MODNAME definition. The reason is that any made-up name would -- 2.1.0
Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework
On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote: > > Probably should have led with that shouldn't I have? There's nothing keeping > me > from doing it, but I didn't want to try and shoehorn in a python thing into > fstests. I need python to do the sqlite and the json parsing to dump into the > sqlite database. What version of python are you using? From inspection it looks like some variant of python 3.x (you're using print as a function w/o using "from __future import print_function") but it's not immediately obvious from the top-level fsperf shell script what version of python your scripts are dependant upon. This could potentially be a bit of a portability issue across various distributions --- RHEL doesn't ship with Python 3.x at all, and on Debian you need to use python3 to get python 3.x, since /usr/bin/python still points at Python 2.7 by default. So I could see this as a potential issue for xfstests. I'm currently using Python 2.7 in my wrapper scripts for, among other things, to parse xUnit XML format and create nice summaries like this: ext4/4k: 337 tests, 6 failures, 21 skipped, 3814 seconds Failures: generic/232 generic/233 generic/361 generic/388 generic/451 generic/459 So I'm not opposed to python, but I will note that if you are using modules from the Python Package Index, and they are modules which are not packaged by your distribution (so you're using pip or easy_install to pull them off the network), it does make doing hermetic builds from trusted sources to be a bit trickier. If you have a secops team who wants to know the provenance of software which get thrown in production data centers (and automated downloading from random external sources w/o any code review makes them break out in hives), use of PyPI adds a new wrinkle. It's not impossible to solve, by any means, but it's something to consider. - Ted
Re: [PATCH] kbuild: comments cleanup in Makefile.lib
Masahiro-san, On 10/04/2017 12:58 PM, Masahiro Yamada wrote: > Hi Cao, > > > 2017-09-19 20:36 GMT+09:00 Cao jin : >> It has: >> 1. Move comments close to what it want to comment. >> 2. Comments cleanup & improvement. >> >> Signed-off-by: Cao jin >> >> -# if $(foo-objs) exists, foo.o is a composite object >> +# if $(foo-objs) or $(foo-y) or $(foo-m) exists, foo.o is a composite object > > > Nit: > > "if $(foo-objs), $(foo-y), or $(foo-m) exists" will be better. > Yes, true. >> multi-used-y := $(sort $(foreach m,$(obj-y), $(if $(strip $($(m:.o=-objs)) >> $($(m:.o=-y))), $(m >> multi-used-m := $(sort $(foreach m,$(obj-m), $(if $(strip $($(m:.o=-objs)) >> $($(m:.o=-y)) $($(m:.o=-m))), $(m >> multi-used := $(multi-used-y) $(multi-used-m) >> @@ -90,7 +84,6 @@ subdir-ym := $(addprefix $(obj)/,$(subdir-ym)) >> obj-dirs := $(addprefix $(obj)/,$(obj-dirs)) >> >> # These flags are needed for modversions and compiling, so we define them >> here >> -# already >> # $(modname_flags) #defines KBUILD_MODNAME as the name of the module it will > > > I am not sure if "#defines" is intentional or not. > I think "#" is unnecessary. > Yes, agree with you -- Sincerely, Cao jin
[RESEND PATCH] media: uvcvideo: Fix memory leak of uvc resources
The refcount would be inited to 1 in kref_init(), so we don't need to
increase it at the end of uvc_register_video().
Fixes: 9d15cd958c17 ("media: uvcvideo: Convert from using an atomic variable to
a reference count")
Signed-off-by: Jeffy Chen
---
drivers/media/usb/uvc/uvc_driver.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 6d22b22cb35b..dd6106411eb0 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1939,7 +1939,6 @@ static int uvc_register_video(struct uvc_device *dev,
else
stream->chain->caps |= V4L2_CAP_VIDEO_OUTPUT;
- kref_get(&dev->ref);
return 0;
}
--
2.11.0
[PATCH] media: uvcvideo: Fix memory leak of uvc resources
The refcount would be inited to 1 in kref_init(), so we don't need to
increase it at the end of uvc_probe().
Fixes: 9d15cd958c17 ("media: uvcvideo: Convert from using an atomic variable to
a reference count")
Signed-off-by: Jeffy Chen
---
drivers/media/usb/uvc/uvc_driver.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 6d22b22cb35b..dd6106411eb0 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1939,7 +1939,6 @@ static int uvc_register_video(struct uvc_device *dev,
else
stream->chain->caps |= V4L2_CAP_VIDEO_OUTPUT;
- kref_get(&dev->ref);
return 0;
}
--
2.11.0
Re: [PATCH v3 12/33] tracing: Add variable support to hist triggers
Hi Tom,
On Fri, Sep 22, 2017 at 02:59:52PM -0500, Tom Zanussi wrote:
> Add support for saving the value of a current event's event field by
> assigning it to a variable that can be read by a subsequent event.
>
> The basic syntax for saving a variable is to simply prefix a unique
> variable name not corresponding to any keyword along with an '=' sign
> to any event field.
>
> Both keys and values can be saved and retrieved in this way:
>
> # echo 'hist:keys=next_pid:vals=$ts0:ts0=common_timestamp ...
The 'common_timestamp' needs a '$' prefix, right?
> # echo 'hist:timer_pid=common_pid:key=$timer_pid ...'
>
> If a variable isn't a key variable or prefixed with 'vals=', the
> associated event field will be saved in a variable but won't be summed
> as a value:
>
> # echo 'hist:keys=next_pid:ts1=common_timestamp:...
Ditto.
>
> Multiple variables can be assigned at the same time:
>
> # echo 'hist:keys=pid:vals=$ts0,$b,field2:ts0=common_timestamp,b=field1
> ...
>
> Multiple (or single) variables can also be assigned at the same time
> using separate assignments:
>
> # echo 'hist:keys=pid:vals=$ts0:ts0=common_timestamp:b=field1:c=field2 ...
Same here..
So you separated the variable definition and it should not be a part
of key or value field, right?
>
> Variables set as above can be used by being referenced from another
> event, as described in a subsequent patch.
That means, a variable should be unique (in a tracing instance at least).
>
> Signed-off-by: Tom Zanussi
> Signed-off-by: Baohong Liu
> ---
> kernel/trace/trace_events_hist.c | 374
> ++-
> 1 file changed, 334 insertions(+), 40 deletions(-)
>
> diff --git a/kernel/trace/trace_events_hist.c
> b/kernel/trace/trace_events_hist.c
> index c2abe41..0d99548 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -30,6 +30,13 @@ typedef u64 (*hist_field_fn_t) (struct hist_field *field,
> void *event,
> struct ring_buffer_event *rbe);
>
> #define HIST_FIELD_OPERANDS_MAX 2
> +#define HIST_FIELDS_MAX (TRACING_MAP_FIELDS_MAX +
> TRACING_MAP_VARS_MAX)
> +
> +struct hist_var {
> + char*name;
> + struct hist_trigger_data*hist_data;
> + unsigned intidx;
> +};
>
> struct hist_field {
> struct ftrace_event_field *field;
> @@ -40,6 +47,7 @@ struct hist_field {
> unsigned intis_signed;
> struct hist_field *operands[HIST_FIELD_OPERANDS_MAX];
> struct hist_trigger_data*hist_data;
> + struct hist_var var;
> };
>
> static u64 hist_field_none(struct hist_field *field, void *event,
> @@ -138,6 +146,14 @@ enum hist_field_flags {
> HIST_FIELD_FL_LOG2 = 1 << 9,
> HIST_FIELD_FL_TIMESTAMP = 1 << 10,
> HIST_FIELD_FL_TIMESTAMP_USECS = 1 << 11,
> + HIST_FIELD_FL_VAR = 1 << 12,
> + HIST_FIELD_FL_VAR_ONLY = 1 << 13,
And then I'm not sure what _VAR_ONLY flag is for. IIUC it's used to
identify pure variable definition from a definition in value fields.
But it's not possible anymore, no?
> +};
> +
> +struct var_defs {
> + unsigned intn_vars;
> + char*name[TRACING_MAP_VARS_MAX];
> + char*expr[TRACING_MAP_VARS_MAX];
> };
>
[SNIP]
> +static int create_var_field(struct hist_trigger_data *hist_data,
> + unsigned int val_idx,
> + struct trace_event_file *file,
> + char *var_name, char *expr_str)
> +{
> + unsigned long flags = 0;
> +
> + if (WARN_ON(val_idx >= TRACING_MAP_VALS_MAX + TRACING_MAP_VARS_MAX))
> + return -EINVAL;
> +
> + if (find_var(file, var_name) && !hist_data->remove) {
Is this for the uniqueness check? But I think it only checks
variables in the current event (file).
> + return -EINVAL;
> + }
> +
> + flags |= HIST_FIELD_FL_VAR;
> + hist_data->n_vars++;
> + if (hist_data->n_vars > TRACING_MAP_VARS_MAX) {
> + return -EINVAL;
> + }
> +
> + flags |= HIST_FIELD_FL_VAR_ONLY;
> +
> + return __create_val_field(hist_data, val_idx, file, var_name, expr_str,
> flags);
> +}
> +
[SNIP]
> +static int parse_var_defs(struct hist_trigger_data *hist_data)
> +{
> + char *s, *str, *var_name, *field_str;
> + unsigned int i, j, n_vars = 0;
> + int ret = 0;
> +
> + for (i = 0; i < hist_data->attrs->n_assignments; i++) {
> + str = hist_data->attrs->assignment_str[i];
> + for (j = 0; j < TRACING_MAP_VARS_MAX; j++) {
> + field_str = strsep(&str, ",");
> + if (!field_str)
> + break;
> +
> + var_name = strsep(&field_str, "=");
> + if (!var_name || !field_str)
Re: [PATCH 12/12] dt-bindings: usb: mtu3: remove optional pinctrls
On Thu, 2017-10-05 at 17:33 -0500, Rob Herring wrote: > On Thu, Sep 28, 2017 at 08:17:20AM +0800, Chunfeng Yun wrote: > > Remove optional pinctrls due to using FORCE/RG_IDDIG to implement > > manual switch function. > > Another not backwards compatible change. Please explain why that is > okay. The old way of manual switch function uses the IDDIG pin (IDPIN) to switch mode between device and host indirectly by pulling up or pulling down it by driver. But there is a limitation, when the IDDIG pin is connected to the ground, the driver can't pull it up anymore, so it will fail when the receptacle is micro type. And there is no such limitation through FORCE/RG_IDDIG, because when the FORCE_IDDIG is set, the staus of RG_IDDIG is given higher priority than IDDIG pin. So it is okay no matter whether id_float and id_ground pins are provided or not. > > > > > Signed-off-by: Chunfeng Yun > > --- > > .../devicetree/bindings/usb/mediatek,mtu3.txt |7 --- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > > b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > > index 49c982b..b2271d8 100644 > > --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > > @@ -30,9 +30,10 @@ Optional properties: > > when supports dual-role mode. > > - vbus-supply : reference to the VBUS regulator, needed when supports > > dual-role mode. > > - - pinctl-names : a pinctrl state named "default" must be defined, > > - "id_float" and "id_ground" are optinal which depends on > > - "mediatek,enable-manual-drd" > > + - pinctrl-names : a pinctrl state named "default" is optional, and need be > > + defined if auto drd switch is enabled, that means the property dr_mode > > + is set as "otg", and meanwhile the property "mediatek,enable-manual-drd" > > + is not set. > > - pinctrl-0 : pin control group > > See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt > > > > -- > > 1.7.9.5 > >
Re: [RFC] workqueue: Fix irq inversion deadlock in manage_workers()
On Sun, Oct 08, 2017 at 07:03:47PM +, Tejun Heo wrote:
> Hello, Boqun.
>
Hi Tejun,
> On Sun, Oct 08, 2017 at 05:02:23PM +0800, Boqun Feng wrote:
> > Josef reported a HARDIRQ-safe -> HARDIRQ-unsafe lock order detected by
> > lockdep:
> >
> > | [ 1270.472259] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
> > | [ 1270.472783] 4.14.0-rc1-xfstests-12888-g76833e8 #110 Not tainted
> > | [ 1270.473240] -
> > | [ 1270.473710] kworker/u5:2/5157 [HC0[0]:SC0[0]:HE0:SE1] is trying to
> > acquire:
> > | [ 1270.474239] (&(&lock->wait_lock)->rlock){+.+.}, at:
> > [] __mutex_unlock_slowpath+0xa2/0x280
> > | [ 1270.474994]
> > | [ 1270.474994] and this task is already holding:
> > | [ 1270.475440] (&pool->lock/1){-.-.}, at: []
> > worker_thread+0x366/0x3c0
> > | [ 1270.476046] which would create a new lock dependency:
> > | [ 1270.476436] (&pool->lock/1){-.-.} ->
> > (&(&lock->wait_lock)->rlock){+.+.}
> > | [ 1270.476949]
> > | [ 1270.476949] but this new dependency connects a HARDIRQ-irq-safe lock:
> > | [ 1270.477553] (&pool->lock/1){-.-.}
> > ...
> > | [ 1270.488900] to a HARDIRQ-irq-unsafe lock:
> > | [ 1270.489327] (&(&lock->wait_lock)->rlock){+.+.}
> > ...
> > | [ 1270.494735] Possible interrupt unsafe locking scenario:
> > | [ 1270.494735]
> > | [ 1270.495250]CPU0CPU1
> > | [ 1270.495600]
> > | [ 1270.495947] lock(&(&lock->wait_lock)->rlock);
> > | [ 1270.496295]local_irq_disable();
> > | [ 1270.496753]lock(&pool->lock/1);
> > | [ 1270.497205]
> > lock(&(&lock->wait_lock)->rlock);
> > | [ 1270.497744]
> > | [ 1270.497948] lock(&pool->lock/1);
> >
> > , which will cause a irq inversion deadlock if the above lock scenario
> > happens.
> >
> > The root cause of this safe -> unsafe lock order is the
> > mutex_unlock(pool::manager_arb) in manage_workers() with pool::lock
>
> So, if I'm not mistaken, this is a regression caused by b9c16a0e1f73
> ("locking/mutex: Fix lockdep_assert_held() fail") which seems to
> replace irqsave operations inside mutex to unconditional irq ones.
>
Hmm.. I don't that commit replaced _irqsave with _irq ones. That commit
simply exposed mutex::wait_lock to lockdep(especially for the irq
inversion deadlock checking).
Even before that commit, the !DEBUG version of spin_{,un}lock_mutex()
wouldn't disable interrupts. So this is not a regression, it's a real
deadlock potential, which had not been detected until commit
b9c16a0e1f73.
Regards,
Boqun
> I suppose it's a requirement we can add but that needs to be an
> explicit change with backing rationales.
>
> Thanks.
>
> --
> tejun
signature.asc
Description: PGP signature
RE: [PATCH v6 3/3] eeprom: at24: enable runtime pm support
Hi Tomasz, >-Original Message- >From: sakari.ai...@iki.fi [mailto:sakari.ai...@iki.fi] >Sent: Tuesday, October 03, 2017 7:21 PM >To: Tomasz Figa >Cc: Mani, Rajmohan ; Mohandass, Divagar >; robh...@kernel.org; >mark.rutl...@arm.com; w...@the-dreams.de; devicet...@vger.kernel.org; >linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; >mika.westerb...@linux.intel.com; linux...@vger.kernel.org >Subject: Re: [PATCH v6 3/3] eeprom: at24: enable runtime pm support > >Hi Tomasz, > >On Wed, Sep 20, 2017 at 12:32:22PM +0300, sakari.ai...@iki.fi wrote: >> > >> >> @@ -743,11 +770,17 @@ static int at24_probe(struct i2c_client >> > >> >> *client, const struct i2c_device_id *id) >> > >> >> >> > >> >> i2c_set_clientdata(client, at24); >> > >> >> >> > >> >> + /* enable runtime pm */ >> > >> >> + pm_runtime_get_noresume(&client->dev); >> > >> >> + pm_runtime_set_active(&client->dev); >> > >> >> + pm_runtime_enable(&client->dev); >> > >> >> > >> Do we need this get_noresume/set_active dance? I remember it was >> > >> for some reason needed for PCI devices, but I don't see why for >> > >> I2C anything else than just pm_runtime_enable() would be necessary. >> > > >> > > You specifically do not need (all) this for PCI devices, but AFAIU >> > > for I涎 >> > > devices you do. The runtime PM status of a device is disabled by >> > > default and the use count is zero, but on ACPI based systems the >> > > device is still powered on. >> > >> > Okay, so _get_noresume() and _set_active() would do the thing for >> > ACPI indeed, but not sure about other platforms. Perhaps _enable(), >> > _get_sync() would be more general? >> >> What I ended up doing in e.g. the smiapp driver was to explicitly >> power the device on first and then enable runtime PM. (See >> drivers/media/i2c/smiapp/smiapp-core.c .) This approach works even if >> CONFIG_PM is disabled, both on DT and ACPI. > >pm_runtime_get_noresume() + pm_runtime_put() can be replaced by a single >pm_runtime_idle() call (where pm_runtime_put() was). pm_runtime_enable() >is required to enable runtime PM for a device. Verified the change suggested by Sakari. Let me know I can send a updated patch version with this change. > >pm_runtime_allow() may be omitted but then to make the runtime PM >framework to make the power state transitions this needs to be configured >from the user space --- which I don't think is intended. > >Cc linux-pm, too. > >-- >Regards, > >Sakari Ailus >e-mail: sakari.ai...@iki.fi
[PATCH] fs/cachefiles: Fix a possible sleep-in-atomic bug in cachefiles_printk_object
The kernel may sleep under a write spinlock, and the function call path is:
cachefiles_mark_object_active (acquire the spinlock)
cachefiles_printk_object
kmalloc(GFP_NOIO) --> may sleep
To fix it, GFP_NOIO is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai
---
fs/cachefiles/namei.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c
index 3978b32..39e1504 100644
--- a/fs/cachefiles/namei.c
+++ b/fs/cachefiles/namei.c
@@ -83,7 +83,7 @@ static noinline void cachefiles_printk_object(struct
cachefiles_object *object,
{
u8 *keybuf;
- keybuf = kmalloc(CACHEFILES_KEYBUF_SIZE, GFP_NOIO);
+ keybuf = kmalloc(CACHEFILES_KEYBUF_SIZE, GFP_ATOMIC);
if (object)
__cachefiles_printk_object(object, "", keybuf);
if (xobject)
--
1.7.9.5
[PATCH] lib/vsprintf: add default case to 'i' specifier
%pi leaks kernel addresses if incorrectly specified. Currently the printk specifier %pi (%pI) contains a switch statement without a default clause. The %pi specifier requires a subsequent character (4, 6, or S) controlling the output. If the specifier is incomplete the switch statement will fall through and print the variable argument address in hex instead of the value of the argument (as an IP address). If uncaught this leaks kernel addresses into dmesg. We can return an error string to make the bug visible and stop addresses leaking. Add a default clause returning an error string, stops leaking addresses and makes the buggy code Signed-off-by: Tobin C. Harding --- lib/vsprintf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 86c3385b9eb3..155702f05b14 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -1775,6 +1775,8 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr, default: return string(buf, end, "(invalid address)", spec); }} + default: + return string(buf, end, "(invalid specifier, form: %pi4)", spec); } break; case 'E': -- 2.7.4
Re: [PATCH v7 3/6] coresight: of: Use of_cpu_node_to_id helper
Hi Suzuki,
On Fri, Oct 06, 2017 at 11:36:07AM +0100, Suzuki K Poulose wrote:
> Reuse the new generic helper, of_cpu_node_to_id() to map a
> given CPU phandle to a logical CPU number.
>
> Cc: Leo Yan
> Acked-by: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
Tested-by: Leo Yan
BTW, I think the function get_cpu_for_node() in the file
arch/arm64/kernel/topology.c we also can refactor with the same
function, just reminding for this.
> ---
> Changes since V4:
> - Fix a regression introduced in v4, reported by bugrobot
> Changes since V3:
> - Reflect the renaming of the helper and return value changes
> ---
> drivers/hwtracing/coresight/of_coresight.c | 15 +++
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/of_coresight.c
> b/drivers/hwtracing/coresight/of_coresight.c
> index a18794128bf8..7c375443ede6 100644
> --- a/drivers/hwtracing/coresight/of_coresight.c
> +++ b/drivers/hwtracing/coresight/of_coresight.c
> @@ -104,26 +104,17 @@ static int of_coresight_alloc_memory(struct device *dev,
> int of_coresight_get_cpu(const struct device_node *node)
> {
> int cpu;
> - bool found;
> - struct device_node *dn, *np;
> + struct device_node *dn;
>
> dn = of_parse_phandle(node, "cpu", 0);
> -
> /* Affinity defaults to CPU0 */
> if (!dn)
> return 0;
> -
> - for_each_possible_cpu(cpu) {
> - np = of_cpu_device_node_get(cpu);
> - found = (dn == np);
> - of_node_put(np);
> - if (found)
> - break;
> - }
> + cpu = of_cpu_node_to_id(dn);
> of_node_put(dn);
>
> /* Affinity to CPU0 if no cpu nodes are found */
> - return found ? cpu : 0;
> + return (cpu < 0) ? 0 : cpu;
> }
> EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
>
> --
> 2.13.6
>
[PATCH] xen/vcpu: Use a unified name about cpu hotplug state for pv and pvhvm
As xen_cpuhp_setup is called by PV and PVHVM, the name of "x86/xen/hvm_guest"
is confusing.
Signed-off-by: Zhenzhong Duan
---
arch/x86/xen/enlighten.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0e7ef69..d669e9d 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -93,11 +93,11 @@ int xen_cpuhp_setup(int (*cpu_up_prepare_cb)(unsigned int),
int rc;
rc = cpuhp_setup_state_nocalls(CPUHP_XEN_PREPARE,
- "x86/xen/hvm_guest:prepare",
+ "x86/xen/guest:prepare",
cpu_up_prepare_cb, cpu_dead_cb);
if (rc >= 0) {
rc = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
- "x86/xen/hvm_guest:online",
+ "x86/xen/guest:online",
xen_cpu_up_online, NULL);
if (rc < 0)
cpuhp_remove_state_nocalls(CPUHP_XEN_PREPARE);
--
1.7.3
Re: [PATCH] coccinelle: api: detect duplicate chip data arrays
On Thu, Oct 05, 2017 at 09:40:51PM +0200, Julia Lawall wrote:
On Thu, 5 Oct 2017, Liam Breck wrote:
Hi Julia,
On Thu, Oct 5, 2017 at 12:25 PM, Julia Lawall wrote:
>
>
> On Thu, 5 Oct 2017, Liam Breck wrote:
>
>> Hi, sorry for slow reply...
>>
>> Can we patch something to make this script run by default on
>> bq7_battery_i2c build? If so let's do that.
>
> I don't think anything is set up for that. But any changes to the file
> should be checked by the 0-day bot.
How do we ask the 0-day bot team to configure their build to run this
script? Will they just pick it up?
I put kbuild in CC. I don't know what is the criterion for including
semantic patches.
We may have 3 options:
1) push this patch to upstream, so that all users can run the check
(with obvious cost)
2) try to optimize away the extra overheads by improving
script/coccicheck to support conditional run of some cocci scripts
3) let 0-day maintain and run a collection of 3rd-party scripts if
(1,2) turns out to be hard or not always applicable for some scripts
What do you think? At least it'd be easy and quick for us to implement (3).
Thanks,
Fengguang
>> Also maybe the name of the script should include "bq27xxx_data"?
>
> OK
>
>> Few more comments below...
>>
>> On Sun, Oct 1, 2017 at 5:42 AM, Julia Lawall wrote:
>> > This semantic patch detects duplicate arrays declared using BQ27XXX_DATA
>> > within a single structure. It is currently specific to the file
>> > drivers/power/supply/bq27xxx_battery.c.
>> >
>> > Signed-off-by: Julia Lawall
>> >
>> > ---
>> > scripts/coccinelle/api/battery.cocci | 161
+++
>> > 1 file changed, 161 insertions(+)
>> >
>> > diff --git a/scripts/coccinelle/api/battery.cocci
b/scripts/coccinelle/api/battery.cocci
>> > new file mode 100644
>> > index 000..77c145a
>> > --- /dev/null
>> > +++ b/scripts/coccinelle/api/battery.cocci
>> > @@ -0,0 +1,161 @@
>> > +/// Detect BQ27XXX_DATA structures with identical registers, dm registers
or
>> > +/// properties.
>> > +//# Doesn't unfold macros used in register or property fields.
>> > +//# Requires OCaml scripting
>> > +///
>> > +// Confidence: High
>> > +// Copyright: (C) 2017 Julia Lawall, Inria/LIP6, GPLv2.
>> > +// URL: http://coccinelle.lip6.fr/
>> > +// Requires: 1.0.7
>> > +// Keywords: BQ27XXX_DATA
>> > +
>> > +virtual report
>> > +
>> > +@initialize:ocaml@
>> > +@@
>> > +
>> > +let print_report p msg =
>> > + let p = List.hd p in
>> > + Printf.printf "%s:%d:%d-%d: %s" p.file p.line p.col p.col_end msg
>> > +
>> > +@str depends on report@
>> > +type t;
>> > +identifier i,i1,i2;
>> > +expression e1,e2;
>> > +@@
>> > +
>> > +t i[] = {
>> > + ...,
>> > + [e1] = BQ27XXX_DATA(i1,...),
>> > + ...,
>> > + [e2] = BQ27XXX_DATA(i2,...),
>> > + ...,
>> > +};
>> > +
>> > +@script:ocaml tocheck@
>> > +i1 << str.i1;
>> > +i2 << str.i2;
>> > +i1regs; i2regs;
>> > +i1dmregs; i2dmregs;
>> > +i1props; i2props;
>> > +@@
>> > +
>> > +if not(i1 = i2)
>> > +then
>> > + begin
>> > +i1regs := make_ident (i1 ^ "_regs");
>> > +i2regs := make_ident (i2 ^ "_regs");
>> > +i1dmregs := make_ident (i1 ^ "_dm_regs");
>> > +i2dmregs := make_ident (i2 ^ "_dm_regs");
>> > +i1props := make_ident (i1 ^ "_props");
>> > +i2props := make_ident (i2 ^ "_props")
>> > + end
>> > +
>> > +(* *)
>> > +
>> > +@getregs1@
>> > +typedef u8;
>> > +identifier tocheck.i1regs;
>> > +initializer list i1regs_vals;
>> > +position p1;
>> > +@@
>> > +
>> > +u8 i1regs@p1[...] = { i1regs_vals, };
>> > +
>> > +@getregs2@
>> > +identifier tocheck.i2regs;
>> > +initializer list i2regs_vals;
>> > +position p2;
>> > +@@
>> > +
>> > +u8 i2regs@p2[...] = { i2regs_vals, };
>> > +
>> > +@script:ocaml@
>> > +(_,i1regs_vals) << getregs1.i1regs_vals;
>> > +(_,i2regs_vals) << getregs2.i2regs_vals;
>> > +i1regs << tocheck.i1regs;
>> > +i2regs << tocheck.i2regs;
>> > +p1 << getregs1.p1;
>> > +p2 << getregs2.p2;
>> > +@@
>> > +
>> > +if i1regs < i2regs &&
>> > + List.sort compare i1regs_vals = List.sort compare i2regs_vals
>> > +then
>> > + let msg =
>> > +Printf.sprintf
>> > + "WARNING %s and %s (line %d) have the same registers\n"
>>
>> "are identical" vs "have the same..."
>
> OK, I guess identical would be appropriate for regsand dm_regs, but
> perhaps not for properties because there the same values might be in a
> different order.
The order of the properties has no impact, so a duplicate is
functionally identical.
>
> julia
>
>> > + i1regs i2regs (List.hd p2).line in
>> > + print_report p1 msg
>> > +
>> > +(* *)
>> > +
>> > +@getdmregs1@
>> > +identifier tocheck.i1dmregs;
>> > +initializer list i1dmregs_vals;
>> > +position p1;
>> > +@@
>> > +
>> > +struct bq27xxx_dm_reg i1dmregs@p1[] = { i1dmregs_vals, };
>> > +
>> > +@getdmregs2@
>> > +identifier tocheck.i2dmregs;
>> > +initializer list i2dm
Re: [PATCH 10/12] dt-bindings: usb: mtu3: add a optional property to disable u3ports
On Thu, 2017-10-05 at 17:31 -0500, Rob Herring wrote: > On Thu, Sep 28, 2017 at 08:17:18AM +0800, Chunfeng Yun wrote: > > Add a new optional property to disable u3ports > > > > Signed-off-by: Chunfeng Yun > > --- > > .../devicetree/bindings/usb/mediatek,mtu3.txt |2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > > b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > > index 49f5476..7c611d1 100644 > > --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > > @@ -44,6 +44,8 @@ Optional properties: > > - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode > > - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup > > control register, it depends on "mediatek,enable-wakeup". > > + - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0, > > + bit1 for u3port1, ... etc; > > How does this relate to the XHCI change? Same comment applies. There is a upper layer called IPPC (IP Power and Clock interface) shared by device IP and host IP (xHCI) to control power and clock of each port. So I can disable or enable xCHI's ports by IPPC indirectly.
[BUG] sound/core/seq: A possible sleep-in-atomic bug in snd_virmidi_dev_receive_event
According to seq_virmidi.c, the driver may sleep under a read spinlock. The function call path is: snd_virmidi_dev_receive_event (acquire the spinlock) snd_seq_dump_var_event copy_from_user --> may sleep This bug is found by my static analysis tool and my code review. Thanks, Jia-Ju Bai
Re: [PATCH 9/9] arm64: dts: register Hi3660's thermal sensor
on 2017/10/3 3:06, Daniel Lezcano wrote:
On 22/09/2017 11:42, Tao Wang wrote:
From: Kevin Wangtao
add binding for tsensor on H3660, this tsensor is used for
SoC thermal control, it supports alarm interrupt.
Signed-off-by: Kevin Wangtao
I'm not able to apply this patch. Does it rely on another patch?
No, This patch is based on linux-next
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index b7a90d6..ae90991 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -978,5 +978,13 @@
clocks = <&crg_ctrl HI3660_OSC32K>;
clock-names = "apb_pclk";
};
+
+ tsensor: tsensor@fff3 {
+ compatible = "hisilicon,hi3660-tsensor";
+ reg = <0x0 0xfff3 0x0 0x1000>;
+ interrupts = ;
+ #thermal-sensor-cells = <1>;
+ };
+
};
};
[PATCH] opl3: Fix a possible sleep-in-atomic bug in snd_opl3_find_patch
The driver may sleep under a spinlock, and the function call path is: snd_opl3_note_on (acquire the spinlock) snd_opl3_find_patch kzalloc(GFP_KERNEL) --> may sleep To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool and my code review. Signed-off-by: Jia-Ju Bai --- sound/drivers/opl3/opl3_synth.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/opl3/opl3_synth.c b/sound/drivers/opl3/opl3_synth.c index ddcc1a3..2e1cb2b 100644 --- a/sound/drivers/opl3/opl3_synth.c +++ b/sound/drivers/opl3/opl3_synth.c @@ -325,7 +325,7 @@ struct fm_patch *snd_opl3_find_patch(struct snd_opl3 *opl3, int prog, int bank, if (!create_patch) return NULL; - patch = kzalloc(sizeof(*patch), GFP_KERNEL); + patch = kzalloc(sizeof(*patch), GFP_ATOMIC); if (!patch) return NULL; patch->prog = prog; -- 1.7.9.5
Re: [PATCH v3 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants.
On 05/10/17 20:41, Miquel RAYNAL wrote: > Hello Kalyan, > > On Thu, 28 Sep 2017 13:57:56 +1300 > Kalyan Kinthada wrote: > >> When the arbitration between NOR and NAND flash is enabled >> the field bit[21] in the Data Flash Control Register >> needs to be set to 1 according to guidleine GL-5830741 mentioned > Typo: guideline ^ I will correct this typo in the next patch version. >> in Marvell Errata document MV-S501377-00, Rev. D. > Thanks for that, I checked it. > >> This commit sets the FORCE_CSX bit to 1 for all >> ARMADA370 variants as the arbitration is always enabled by default. >> This change does not apply for pxa3xx variants because the FORCE_CSX >> bit does not exist/reserved on the NFCv1. > Sorry to bother you again but I am reworking the pxa3xx_nand driver and > so I would like to deeply understand why this is needed because I will > have to integrate it in my work too. > > So please tell me what is your setup, do you really use NAND/NOR > arbitration? Do you have not-Don't Care CS NAND chips? I have some > doubts because even if the spec precises in the NAND controller chapter > that arbitration is always enabled by default, the bit 27 (NfArbiterEn) > in the SoC Device Multiplex Register at offset 0x00018208 is actually > at 0 by default (disabled). Did you enable this bit manually ? I > checked with devmem on my setup and this bit was unset. Yes, my setup use NAND/NOR arbitration and use a Don't care CS Nand Chip. The bit 27 at offset 0x00018208 is set to 1 by default in my case. I did not manually set the bit 27 to 1. Please let me now if you have any other question or do you want me to send the updated patch version with the typo fixed. Thank You, Kalyan > > Thank you for your time, > Miquèl > >> The NDCR_ND_MODE conflicts with the new NDCR_FORCE_CSX but is unused >> so remove it along with NDCR_NAND_MODE. >> >> Signed-off-by: Kalyan Kinthada >> --- > > >> drivers/mtd/nand/pxa3xx_nand.c | 9 +++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mtd/nand/pxa3xx_nand.c >> b/drivers/mtd/nand/pxa3xx_nand.c index 85cff68643e0..a6a7a5af7bed >> 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c >> +++ b/drivers/mtd/nand/pxa3xx_nand.c >> @@ -67,8 +67,7 @@ >> #define NDCR_DWIDTH_M (0x1 << 26) >> #define NDCR_PAGE_SZ (0x1 << 24) >> #define NDCR_NCSX (0x1 << 23) >> -#define NDCR_ND_MODE(0x3 << 21) >> -#define NDCR_NAND_MODE (0x0) >> +#define NDCR_FORCE_CSX (0x1 << 21) >> #define NDCR_CLR_PG_CNT(0x1 << 20) >> #define NFCV1_NDCR_ARB_CNTL(0x1 << 19) >> #define NFCV2_NDCR_STOP_ON_UNCOR (0x1 << 19) >> @@ -1464,6 +1463,9 @@ static int pxa3xx_nand_config_ident(struct >> pxa3xx_nand_info *info) info->chunk_size = PAGE_CHUNK_SIZE; >> info->reg_ndcr = 0x0; /* enable all interrupts */ >> info->reg_ndcr |= (pdata->enable_arbiter) ? NDCR_ND_ARB_EN : >> 0; >> +/* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#: >> GL-5830741 */ >> +if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370) >> +info->reg_ndcr |= NDCR_FORCE_CSX; >> info->reg_ndcr |= NDCR_RD_ID_CNT(READ_ID_BYTES); >> info->reg_ndcr |= NDCR_SPARE_EN; >> >> @@ -1498,6 +1500,9 @@ static void pxa3xx_nand_detect_config(struct >> pxa3xx_nand_info *info) info->reg_ndcr = ndcr & >> ~(NDCR_INT_MASK | NDCR_ND_ARB_EN | >> NFCV1_NDCR_ARB_CNTL); info->reg_ndcr |= (pdata->enable_arbiter) ? >> NDCR_ND_ARB_EN : 0; >> +/* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#: >> GL-5830741 */ >> +if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370) >> +info->reg_ndcr |= NDCR_FORCE_CSX; >> info->ndtr0cs0 = nand_readl(info, NDTR0CS0); >> info->ndtr1cs0 = nand_readl(info, NDTR1CS0); >> } > >
Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework
On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote: > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote: > > Hello, > > > > One thing that comes up a lot every LSF is the fact that we have no general > > way > > that we do performance testing. Every fs developer has a set of scripts or > > things that they run with varying degrees of consistency, but nothing > > central > > that we all use. I for one am getting tired of finding regressions when we > > are > > deploying new kernels internally, so I wired this thing up to try and > > address > > this need. > > > > We all hate convoluted setups, the more brain power we have to put in to > > setting > > something up the less likely we are to use it, so I took the xfstests > > approach > > of making it relatively simple to get running and relatively easy to add new > > tests. For right now the only thing this framework does is run fio > > scripts. I > > chose fio because it already gathers loads of performance data about it's > > runs. > > We have everything we need there, latency, bandwidth, cpu time, and all > > broken > > down by reads, writes, and trims. I figure most of us are familiar enough > > with > > fio and how it works to make it relatively easy to add new tests to the > > framework. > > > > I've posted my code up on github, you can get it here > > > > https://github.com/josefbacik/fsperf > > > > All (well most) of the results from fio are stored in a local sqlite > > database. > > Right now the comparison stuff is very crude, it simply checks against the > > previous run and it only checks a few of the keys by default. You can check > > latency if you want, but while writing this stuff up it seemed that latency > > was > > too variable from run to run to be useful in a "did my thing regress or > > improve" > > sort of way. > > > > The configuration is brain dead simple, the README has examples. All you > > need > > to do is make your local.cfg, run ./setup and then run ./fsperf and you are > > good > > to go. > > Why re-invent the test infrastructure? Why not just make it a > tests/perf subdir in fstests? > Probably should have led with that shouldn't I have? There's nothing keeping me from doing it, but I didn't want to try and shoehorn in a python thing into fstests. I need python to do the sqlite and the json parsing to dump into the sqlite database. Now if you (and others) are not opposed to this being dropped into tests/perf then I'll work that up. But it's definitely going to need to be done in python. I know you yourself have said you aren't opposed to using python in the past, so if that's still the case then I can definitely wire it all up. > > The plan is to add lots of workloads as we discover regressions and such. > > We > > don't want anything that takes too long to run otherwise people won't run > > this, > > so the existing tests don't take much longer than a few minutes each. I > > will be > > adding some more comparison options so you can compare against averages of > > all > > previous runs and such. > > Yup, that fits exactly into what fstests is for... :P > > Integrating into fstests means it will be immediately available to > all fs developers, it'll run on everything that everyone already has > setup for filesystem testing, and it will have familiar mkfs/mount > option setup behaviour so there's no new hoops for everyone to jump > through to run it... > TBF I specifically made it as easy as possible because I know we all hate trying to learn new shit. I figured this was different enough to warrant a separate project, especially since I'm going to add block device jobs so Jens can test block layer things. If we all agree we'd rather see this in fstests then I'm happy to do that too. Thanks, Josef
Re: [PATCH v3] mm, sysctl: make NUMA stats configurable
On 2017年09月29日 15:03, Vlastimil Babka wrote: > On 09/28/2017 08:11 AM, Kemi Wang wrote: >> This is the second step which introduces a tunable interface that allow >> numa stats configurable for optimizing zone_statistics(), as suggested by >> Dave Hansen and Ying Huang. >> >> = >> When page allocation performance becomes a bottleneck and you can tolerate >> some possible tool breakage and decreased numa counter precision, you can >> do: >> echo [C|c]oarse > /proc/sys/vm/numa_stats_mode >> In this case, numa counter update is ignored. We can see about >> *4.8%*(185->176) drop of cpu cycles per single page allocation and reclaim >> on Jesper's page_bench01 (single thread) and *8.1%*(343->315) drop of cpu >> cycles per single page allocation and reclaim on Jesper's page_bench03 (88 >> threads) running on a 2-Socket Broadwell-based server (88 threads, 126G >> memory). >> >> Benchmark link provided by Jesper D Brouer(increase loop times to >> 1000): >> https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/mm/ >> bench >> >> = >> When page allocation performance is not a bottleneck and you want all >> tooling to work, you can do: >> echo [S|s]trict > /proc/sys/vm/numa_stats_mode >> >> = >> We recommend automatic detection of numa statistics by system, this is also >> system default configuration, you can do: >> echo [A|a]uto > /proc/sys/vm/numa_stats_mode >> In this case, numa counter update is skipped unless it has been read by >> users at least once, e.g. cat /proc/zoneinfo. >> >> Branch target selection with jump label: >> a) When numa_stats_mode is changed to *strict*, jump to the branch for numa >> counters update. >> b) When numa_stats_mode is changed to *coarse*, return back directly. >> c) When numa_stats_mode is changed to *auto*, the branch target used in >> last time is kept, and the branch target is changed to the branch for numa >> counters update once numa counters are *read* by users. >> >> Therefore, with the help of jump label, the page allocation performance is >> hardly affected when numa counters are updated with a call in >> zone_statistics(). Meanwhile, the auto mode can give people benefit without >> manual tuning. >> >> Many thanks to Michal Hocko, Dave Hansen and Ying Huang for comments to >> help improve the original patch. >> >> ChangeLog: >> V2->V3: >> a) Propose a better way to use jump label to eliminate the overhead of >> branch selection in zone_statistics(), as inspired by Ying Huang; >> b) Add a paragraph in commit log to describe the way for branch target >> selection; >> c) Use a more descriptive name numa_stats_mode instead of vmstat_mode, >> and change the description accordingly, as suggested by Michal Hocko; >> d) Make this functionality NUMA-specific via ifdef >> >> V1->V2: >> a) Merge to one patch; >> b) Use jump label to eliminate the overhead of branch selection; >> c) Add a single-time log message at boot time to help tell users what >> happened. >> >> Reported-by: Jesper Dangaard Brouer >> Suggested-by: Dave Hansen >> Suggested-by: Ying Huang >> Signed-off-by: Kemi Wang >> --- >> Documentation/sysctl/vm.txt | 24 + >> drivers/base/node.c | 4 ++ >> include/linux/vmstat.h | 23 >> init/main.c | 3 ++ >> kernel/sysctl.c | 7 +++ >> mm/page_alloc.c | 10 >> mm/vmstat.c | 129 >> >> 7 files changed, 200 insertions(+) >> >> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt >> index 9baf66a..e310e69 100644 >> --- a/Documentation/sysctl/vm.txt >> +++ b/Documentation/sysctl/vm.txt >> @@ -61,6 +61,7 @@ Currently, these files are in /proc/sys/vm: >> - swappiness >> - user_reserve_kbytes >> - vfs_cache_pressure >> +- numa_stats_mode >> - watermark_scale_factor >> - zone_reclaim_mode >> >> @@ -843,6 +844,29 @@ ten times more freeable objects than there are. >> >> = >> >> +numa_stats_mode >> + >> +This interface allows numa statistics configurable. >> + >> +When page allocation performance becomes a bottleneck and you can tolerate >> +some possible tool breakage and decreased numa counter precision, you can >> +do: >> +echo [C|c]oarse > /proc/sys/vm/numa_stats_mode >> + >> +When page allocation performance is not a bottleneck and you want all >> +tooling to work, you can do: >> +echo [S|s]trict > /proc/sys/vm/numa_stat_mode >> + >> +We recommend automatic detection of numa statistics by system, because numa >> +statistics does not affect system's decision and it is very rarely >> +consumed. you can do: >> +echo [A|a]uto > /proc/sys/vm/numa_stats_mode >> +Th
Re: [PATCH 01/12] mmc: dt-bindings: update Mediatek MMC bindings
On Mon, 2017-10-02 at 08:53 +0200, Ulf Hansson wrote: > [...] > > >> > >> > Required properties: > >> > >> > -- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc" > >> > >> > +- compatible: value should be either of the following. > >> > >> > + "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135 > >> > >> > + "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173 > >> > >> > + "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701 > >> > >> > + "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712 > >> > >> > +- reg: physical base address of the controller and length > >> > >> > - interrupts: Should contain MSDC interrupt number > >> > >> > -- clocks: MSDC source clock, HCLK > >> > >> > -- clock-names: "source", "hclk" > >> > >> > +- clocks: MSDC source clock, HCLK, source_cg > >> > >> > +- clock-names: "source", "hclk", "source_cg" > >> > >> > >> > >> All chips support source_cg? That's not backwards compatible for > >> > >> existing compatible strings if the driver requires it. > >> > > Not all chips support source_cg, for chips which do not support > >> > > source_cg, no need source_cg here, and the driver will parse it > >> > > to know if current chip support it. > >> > > >> > In such case you must not add add a required binding for it. I think > >> > that is what Rob is trying to point out for you. > >> > > >> > [...] > >> > > >> > Kind regards > >> > Uffe > >> The source_cg is required(MUST) at MT2712 and future SoCs, but not > >> required(do not have it) at previous SoCs, so that put it at required > >> properties, let the driver to handle it. > > Then you must explain that in the binding... > > On 29 September 2017 at 03:56, Chaotian Jing > wrote: > > On Wed, 2017-09-27 at 09:18 +0800, Chaotian Jing wrote: > >> On Wed, 2017-09-27 at 00:33 +0200, Ulf Hansson wrote: > >> > On 14 September 2017 at 04:10, Chaotian Jing > >> > wrote: > >> > > On Wed, 2017-09-13 at 09:10 -0500, Rob Herring wrote: > >> > >> On Tue, Sep 12, 2017 at 05:07:41PM +0800, Chaotian Jing wrote: > >> > >> > Change the comptiable for support of multi-platform > >> > >> > Add description for reg > >> > >> > Add description for source_cg > >> > >> > Add description for mediatek,latch-ck > >> > >> > >> > >> This is at least the 3rd patch with exactly the same vague subject. > >> > >> Please make the subject somewhat unique. > >> > >> > >> > > Thx, will change the subject at next version > >> > >> > > >> > >> > Signed-off-by: Chaotian Jing > >> > >> > --- > >> > >> > Documentation/devicetree/bindings/mmc/mtk-sd.txt | 13 ++--- > >> > >> > 1 file changed, 10 insertions(+), 3 deletions(-) > >> > >> > > >> > >> > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt > >> > >> > b/Documentation/devicetree/bindings/mmc/mtk-sd.txt > >> > >> > index 4182ea3..405cd06 100644 > >> > >> > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt > >> > >> > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt > >> > >> > @@ -7,10 +7,15 @@ This file documents differences between the core > >> > >> > properties in mmc.txt > >> > >> > and the properties used by the msdc driver. > >> > >> > > > > > Any other comments about it ? still must not add a required binding for > > it ? if add a optional binding for it, how to add it ? as cannot > > duplicate "clocks" & "clock-names" in one node. > > > > > > I suggest you keep the description of the new clock name part of the > "Required properties:" header. However, after each clock name, > explicit state when the clock is required/optional. Something along > the lines as sdhci-msm does it. > Documentation/devicetree/bindings/mmc/sdhci-msm.txt > > Kind regards > Uffe Thx, I will send a new series of patch v2 to review.
Re: [PATCH 8/9] dt-bindings: usb: mtk-xhci: add a optional property to disable u3ports
On Thu, 2017-10-05 at 17:16 -0500, Rob Herring wrote: > On Wed, Sep 27, 2017 at 05:23:04PM +0800, Chunfeng Yun wrote: > > Add a new optional property to disable u3ports > > > > Signed-off-by: Chunfeng Yun > > --- > > .../devicetree/bindings/usb/mediatek,mtk-xhci.txt |2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt > > b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt > > index 5611a2e..2d9b459 100644 > > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt > > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt > > @@ -38,6 +38,8 @@ Optional properties: > > mode; > > - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup > > control register, it depends on "mediatek,wakeup-src". > > + - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0, > > + bit1 for u3port1, ... etc; > > I think you should have child nodes for ports and use "status" to > disable them (or omit them). IIRC, the common USB bus binding already > defines ports. I survey it to see whether it can replace the current way thanks > > > - vbus-supply : reference to the VBUS regulator; > > - usb3-lpm-capable : supports USB3.0 LPM > > - pinctrl-names : a pinctrl state named "default" must be defined > > -- > > 1.7.9.5 > >
[PATCH] sound/pci/riptide or drivers/base/firmware: Fix a possible sleep-in-atomic bug
The riptide driver may sleep under a spinlock, and the function call path is:
snd_riptide_prepare (acquire the spinlock)
setsampleformat
sendcmd
riptide_reset
try_to_load_firmware
request_firmware
_request_firmware (drivers/base/firmware_class.c)
_request_firmware_prepare
kzalloc(GFP_KERNEL) --> may sleep
To fix it, GFP_KERNEL is replaced with GFP_ATOMIC in _request_firmware_prepare.
This bug is found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai
---
drivers/base/firmware_class.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 4b57cf5..d89f676 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1138,7 +1138,7 @@ static inline void kill_pending_fw_fallback_reqs(bool
only_kill_custom) { }
struct firmware_buf *buf;
int ret;
- *firmware_p = firmware = kzalloc(sizeof(*firmware), GFP_KERNEL);
+ *firmware_p = firmware = kzalloc(sizeof(*firmware), GFP_ATOMIC);
if (!firmware) {
dev_err(device, "%s: kmalloc(struct firmware) failed\n",
__func__);
--
1.7.9.5
GOOD DAY
CONTACT US TODAY FOR BUSINESS OR PERSONAL LOAN.
Re: [PATCH] ceph: Fix bool initialization/comparison
> On 7 Oct 2017, at 22:02, Thomas Meyer wrote:
>
> Bool initializations should use true and false. Bool tests don't need
> comparisons.
>
> Signed-off-by: Thomas Meyer
> ---
>
> diff -u -p a/fs/ceph/caps.c b/fs/ceph/caps.c
> --- a/fs/ceph/caps.c
> +++ b/fs/ceph/caps.c
> @@ -1711,7 +1711,7 @@ void ceph_check_caps(struct ceph_inode_i
>
> /* if we are unmounting, flush any unused caps immediately. */
> if (mdsc->stopping)
> - is_delayed = 1;
> + is_delayed = true;
>
> spin_lock(&ci->i_ceph_lock);
>
> @@ -3185,8 +3185,8 @@ static void handle_cap_flush_ack(struct
> int dirty = le32_to_cpu(m->dirty);
> int cleaned = 0;
> bool drop = false;
> - bool wake_ci = 0;
> - bool wake_mdsc = 0;
> + bool wake_ci = false;
> + bool wake_mdsc = false;
>
> list_for_each_entry_safe(cf, tmp_cf, &ci->i_cap_flush_list, i_list) {
> if (cf->tid == flush_tid)
Applied, thanks
Yan, Zheng
Re: [f2fs-dev] [PATCH] f2fs: Fix bool initialization/comparison
On 2017/10/8 3:30, Joe Perches wrote: > On Sat, 2017-10-07 at 23:33 +0900, Ju Hyung Park wrote: >> Isn't this bogus? >> >> "bool" type in Linux kernel is a typedef to "_Bool" >> and true/false is defined as 1 and 0 by enum at include/linux/stddef.h. > > Bogus? Well, not really. It's just a neatening and it's > identical object code. > > The idea is that true/false is more intelligible than 1/0 > for a human reader. Yes, that's just cleanup. Hi Thomas, could you change the commit message a bit? > >> On Sat, Oct 7, 2017 at 11:02 PM, Thomas Meyer wrote: >>> Bool initializations should use true and false. Bool tests don't need >>> comparisons. > [] >>> diff -u -p a/fs/f2fs/data.c b/fs/f2fs/data.c > [] >>> @@ -419,7 +419,7 @@ next: >>> bio_page = fio->encrypted_page ? fio->encrypted_page : fio->page; >>> >>> /* set submitted = 1 as a return value */ Comment should be updated too. Thanks, >>> - fio->submitted = 1; >>> + fio->submitted = true; >>> >>> inc_page_count(sbi, WB_DATA_TYPE(bio_page)); >>> > > And it's probably better to change the comment too. > > > . >
Re: [PATCH v1 1/4] perf annotate: create a new hists to manage multiple events samples
On 10/7/2017 2:54 AM, Arnaldo Carvalho de Melo wrote:
> Em Sat, Oct 07, 2017 at 12:31:37AM +0800, Jin, Yao escreveu:
>> On 10/5/2017 9:21 PM, Arnaldo Carvalho de Melo wrote:
>>> Em Wed, Aug 16, 2017 at 06:18:33PM +0800, Jin Yao escreveu:
An issue is found during using perf annotate.
>
perf record -e cycles,branches ...
perf annotate main --stdio
>
The result only shows cycles. It should show both cycles and
branches on the left side. It works with "--group", but need
this to work even without groups.
>>>
>>> Right, for --group we know that we'll be reading all the counters at
>>> each sample, so it all works and we can use the current design.
>
>>> When we're not using groups tho, each sample has just one of the events
>>> and we end up with separate views.
>
>>> Note tho that since the annotation buckets are kept per 'struct symbol'
>>> instance, this problem should be present only in the hist_entry based
>>> views, i.e. 'perf report' and 'perf top', right?
>
>> Yes, it seems to be in hist_entry based view.
>
> Ok.
>
> But note that your initial statement of the problem:
>
>
> An issue is found during using perf annotate.
>
> perf record -e cycles,branches ...
> perf annotate main --stdio
>
> The result only shows cycles. It should show both cycles and
> branches on the left side. It works with "--group", but need
> this to work even without groups.
>
>
> Can be solved right now, its just a matter of accessing the other
> buckets in a given symbol, just like we have for --group.
>
> The only problem is in presenting a list of symbols which can be
> annotated, we have them for each evsel, and you, rightly, want to show
> the list of all symbols in all evsels.
>
> Ok?
>
Hi Arnaldo, I just feel there might be another problem when displaying the
result.
I will talk about this in below.
>>> I.e. all struct hist_entry->ms.sym instances point to the same stuct
>>> symbol and thus will use the same annotation histogram buckets, i.e.
>>> symbol__annotation(hist_entry->ms.sym) point to the same 'struct
>>> annotation' instance, and then its a matter of passing this pointer to
>>> annotation__histogram(notes, IDX) where this IDX is perf_evsel->idx.
>
>>> I wonder if we can't just add a new rb_node in struct hist_entry and
>>> have it in two rb_trees, i.e. in two 'struct hists' instances, one per
>>> evsel and one per evlist.
>
>> Currently we just have per-evsel hists. This idea will create a new
>> per-evlist hists.
>
>> struct perf_evlist {
>> ..
>> struct histshists;
>> };
>
>> And let the hist_entry be linked in both per-evsel hists and per-evlist
>> hists.
>
>> Please correct me if my understanding is wrong for this idea.
>
> Yes, do you see problems with trying to do it this way? At a first sight
> seems like it will reuse more code, no?
>
> I.e. in hists__findnew_entry(), when not finding an existing hist_entry
> in the per-evsel hists you end up calling hist_entry__new(), right here
> you'll add it to the evsel->evlist->hists, and when we want to go from
> a hist_entry to the evlist it is in we'll use:
>
> hists_to_evsel(he->hists)->evlist
>
> Right?
>
> - Arnaldo
>
With this method, we can get the events from per-evlist hists.
For example, when printing the symbol annotate of 'cycles', we can also get the
'branches' from per-evlist hists. So we can print the values of both 'cycles'
and 'branches' in annotate view of 'cycles'.
The problem might be, once the annotate view of 'cycles' being printed, the
view of 'branches' will be printed in next. Maybe they are the same symbol
(e.g. function A), so duplicated.
The problem is that we only sort the per-evsel hists, but we don't sort the
per-evlist hists.
>From my personal opinion, we may need a new sorted hists for multiple events.
>That will avoid the symbol duplication.
Maybe I misunderstand something, please correct me if I'm wrong.
Thanks
Jin Yao
RE: [PATCH] qed: Delete redundant check on dcb_app priority
> dcb_app priority is unsigned thus checking whether it is less than zero > is redundant. > > Signed-off-by: Christos Gkekas Thanks Acked-By: Tomer Tayar
Re: [PATCH v2 1/2] uio: dt-bindings: document binding for uio-pdrv-genirq
On Sun, Oct 8, 2017 at 4:03 PM, Chris Packham wrote: > Hi Rob, Greg, > > On 04/10/17 10:38, Rob Herring wrote: >> On Fri, Sep 22, 2017 at 03:48:13AM +1200, Chris Packham wrote: >>> Document the device tree bindings for the uio-prv-genirq driver. Provide >>> some examples on how it can be used. >>> >>> Signed-off-by: Chris Packham >>> --- >>> .../bindings/uio/linux,uio-pdrv-genirq.txt | 28 >>> ++ >>> 1 file changed, 28 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/uio/linux,uio-pdrv-genirq.txt >> >> NAK. >> >> I'm sure this has come up before but if you want to map a device to a >> uio driver, then add its compatible string to the driver. Bindings >> describe h/w devices. > > Fair enough. > > The problem for me is that the uio-pdrv-genirq is so generic it could > apply to pretty much any hardware device. The driver has dt-awareness > but it currently doesn't have any built-in compatible string (it is set > via a module param). > > My use-case is a microcontoller with a userspace driver all I need out > of the kernel is i2c access and interrupts. Any suggestions as to how to > move forward with this. Define the binding for the uC regardless of how the driver is implemented. Then add its compatible to the uio-pdev driver. That's how we've dealt with spi-dev for example. Rob
[BUG] ssb: Possible sleep-in-atomic bugs in ssb_pcmcia_read8
According to pcmcia.c, the driver may sleep under a spinlock. The function call paths are: ssb_pcmcia_read8 (acquire the spinlock) select_core_and_segment ssb_pcmcia_switch_segment ssb_pcmcia_cfg_write pcmcia_write_config_byte pcmcia_access_config (drivers/pcmcia/pcmcia_resource.c) mutex_lock --> may sleep ssb_pcmcia_read8 (acquire the spinlock) select_core_and_segment ssb_pcmcia_switch_segment sssb_pcmcia_cfg_read pcmcia_read_config_byte pcmcia_access_config (drivers/pcmcia/pcmcia_resource.c) mutex_lock --> may sleep A possible fix is to use spinlock instead of mutex lock in pcmcia_access_config in drivers/pcmcia/pcmcia_resource.c. These bugs are found by my static analysis tool and my code review. Thanks, Jia-Ju Bai
Re: [PATCH v2 4/4] mm:swap: skip swapcache for swapin of synchronous device
On Fri, Sep 29, 2017 at 4:51 PM, huang ying
wrote:
> On Wed, Sep 20, 2017 at 1:43 PM, Minchan Kim wrote:
[snip]
>> diff --git a/mm/memory.c b/mm/memory.c
>> index ec4e15494901..163ab2062385 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -2842,7 +2842,7 @@ EXPORT_SYMBOL(unmap_mapping_range);
>> int do_swap_page(struct vm_fault *vmf)
>> {
>> struct vm_area_struct *vma = vmf->vma;
>> - struct page *page = NULL, *swapcache;
>> + struct page *page = NULL, *swapcache = NULL;
>> struct mem_cgroup *memcg;
>> struct vma_swap_readahead swap_ra;
>> swp_entry_t entry;
>> @@ -2881,17 +2881,35 @@ int do_swap_page(struct vm_fault *vmf)
>> }
>> goto out;
>> }
>> +
>> +
>> delayacct_set_flag(DELAYACCT_PF_SWAPIN);
>> if (!page)
>> page = lookup_swap_cache(entry, vma_readahead ? vma : NULL,
>> vmf->address);
>> if (!page) {
>> - if (vma_readahead)
>> - page = do_swap_page_readahead(entry,
>> - GFP_HIGHUSER_MOVABLE, vmf, &swap_ra);
>> - else
>> - page = swapin_readahead(entry,
>> - GFP_HIGHUSER_MOVABLE, vma, vmf->address);
>> + struct swap_info_struct *si = swp_swap_info(entry);
>> +
>> + if (!(si->flags & SWP_SYNCHRONOUS_IO)) {
>> + if (vma_readahead)
>> + page = do_swap_page_readahead(entry,
>> + GFP_HIGHUSER_MOVABLE, vmf, &swap_ra);
>> + else
>> + page = swapin_readahead(entry,
>> + GFP_HIGHUSER_MOVABLE, vma,
>> vmf->address);
>> + swapcache = page;
>> + } else {
>> + /* skip swapcache */
>> + page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma,
>> vmf->address);
>> + if (page) {
>> + __SetPageLocked(page);
>> + __SetPageSwapBacked(page);
>> + set_page_private(page, entry.val);
>> + lru_cache_add_anon(page);
>> + swap_readpage(page, true);
>> + }
>> + }
>
> I have a question for this. If a page is mapped in multiple processes
> (for example, because of fork). With swap cache, after swapping out
> and swapping in, the page will be still shared by these processes.
> But with your changes, it appears that there will be multiple pages
> with same contents mapped in multiple processes, even if the page
> isn't written in these processes. So this may waste some memory in
> some situation? And copying from device is even faster than looking
> up swap cache in your system?
Hi, Minchan,
Could you help me on this?
Best Regards,
Huang, Ying
[snip]
Re: [PATCH] Added default implementation for of_find_all_nodes(). This function is used by board.c from the board module (drivers/staging/board).
On Sun, Oct 8, 2017 at 11:28 AM, Artur Lorincz wrote: > Signed-off-by: Artur Lorincz > --- > include/linux/of.h | 5 + > 1 file changed, 5 insertions(+) I replied to you on the previous version[1]. Why are you sending this again? Rob [1] https://lkml.org/lkml/2017/10/6/805
