[PATCH 10/20] ethernet: ucc_geth: remove {rx,tx}_glbl_pram_offset from struct ucc_geth_private
These fields are only used within ucc_geth_startup(), so they might as
well be local variables in that function rather than being stashed in
struct ucc_geth_private.
Aside from making that struct a tiny bit smaller, it also shortens
some lines (getting rid of pointless casts while here), and fixes the
problems with using IS_ERR_VALUE() on a u32 as explained in commit
800cd6fb76f0 ("soc: fsl: qe: change return type of cpm_muram_alloc()
to s32").
Signed-off-by: Rasmus Villemoes
---
drivers/net/ethernet/freescale/ucc_geth.c | 21 +
drivers/net/ethernet/freescale/ucc_geth.h | 2 --
2 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index e1574c14b7e5..b132fcfc7c17 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -2351,6 +2351,7 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
u8 function_code = 0;
u8 __iomem *endOfRing;
u8 numThreadsRxNumerical, numThreadsTxNumerical;
+ s32 rx_glbl_pram_offset, tx_glbl_pram_offset;
ugeth_vdbg("%s: IN", __func__);
uccf = ugeth->uccf;
@@ -2495,17 +2496,15 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
*/
/* Tx global PRAM */
/* Allocate global tx parameter RAM page */
- ugeth->tx_glbl_pram_offset =
+ tx_glbl_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_tx_global_pram),
UCC_GETH_TX_GLOBAL_PRAM_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->tx_glbl_pram_offset)) {
+ if (tx_glbl_pram_offset < 0) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for
p_tx_glbl_pram\n");
return -ENOMEM;
}
- ugeth->p_tx_glbl_pram =
- (struct ucc_geth_tx_global_pram __iomem *) qe_muram_addr(ugeth->
- tx_glbl_pram_offset);
+ ugeth->p_tx_glbl_pram = qe_muram_addr(tx_glbl_pram_offset);
/* Fill global PRAM */
/* TQPTR */
@@ -2656,17 +2655,15 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
/* Rx global PRAM */
/* Allocate global rx parameter RAM page */
- ugeth->rx_glbl_pram_offset =
+ rx_glbl_pram_offset =
qe_muram_alloc(sizeof(struct ucc_geth_rx_global_pram),
UCC_GETH_RX_GLOBAL_PRAM_ALIGNMENT);
- if (IS_ERR_VALUE(ugeth->rx_glbl_pram_offset)) {
+ if (rx_glbl_pram_offset < 0) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate DPRAM memory for
p_rx_glbl_pram\n");
return -ENOMEM;
}
- ugeth->p_rx_glbl_pram =
- (struct ucc_geth_rx_global_pram __iomem *) qe_muram_addr(ugeth->
- rx_glbl_pram_offset);
+ ugeth->p_rx_glbl_pram = qe_muram_addr(rx_glbl_pram_offset);
/* Fill global PRAM */
/* RQPTR */
@@ -2928,7 +2925,7 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
((u32) ug_info->numThreadsTx) << ENET_INIT_PARAM_TGF_SHIFT;
ugeth->p_init_enet_param_shadow->rgftgfrxglobal |=
- ugeth->rx_glbl_pram_offset | ug_info->riscRx;
+ rx_glbl_pram_offset | ug_info->riscRx;
if ((ug_info->largestexternallookupkeysize !=
QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_NONE) &&
(ug_info->largestexternallookupkeysize !=
@@ -2966,7 +2963,7 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
}
ugeth->p_init_enet_param_shadow->txglobal =
- ugeth->tx_glbl_pram_offset | ug_info->riscTx;
+ tx_glbl_pram_offset | ug_info->riscTx;
if ((ret_val =
fill_init_enet_entries(ugeth,
&(ugeth->p_init_enet_param_shadow->
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h
b/drivers/net/ethernet/freescale/ucc_geth.h
index c80bed2c995c..be47fa8ced15 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -1166,9 +1166,7 @@ struct ucc_geth_private {
struct ucc_geth_exf_global_pram __iomem *p_exf_glbl_param;
u32 exf_glbl_param_offset;
struct ucc_geth_rx_global_pram __iomem *p_rx_glbl_pram;
- u32 rx_glbl_pram_offset;
struct ucc_geth_tx_global_pram __iomem *p_tx_glbl_pram;
- u32 tx_glbl_pram_offset;
struct ucc_geth_send_queue_mem_region __iomem *p_send_q_mem_reg;
u32 send_q_mem_reg_offset;
struct ucc_geth_thread_data_tx __iomem *p_thread_data_tx;
--
2.23.0
[PATCH 11/20] ethernet: ucc_geth: fix use-after-free in ucc_geth_remove()
ugeth is the netdiv_priv() part of the netdevice. Accessing the memory pointed to by ugeth (such as done by ucc_geth_memclean() and the two of_node_puts) after free_netdev() is thus use-after-free. Signed-off-by: Rasmus Villemoes --- drivers/net/ethernet/freescale/ucc_geth.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c index b132fcfc7c17..ba911d05d36d 100644 --- a/drivers/net/ethernet/freescale/ucc_geth.c +++ b/drivers/net/ethernet/freescale/ucc_geth.c @@ -3895,13 +3895,13 @@ static int ucc_geth_remove(struct platform_device* ofdev) struct ucc_geth_private *ugeth = netdev_priv(dev); struct device_node *np = ofdev->dev.of_node; - unregister_netdev(dev); - free_netdev(dev); ucc_geth_memclean(ugeth); if (of_phy_is_fixed_link(np)) of_phy_deregister_fixed_link(np); of_node_put(ugeth->ug_info->tbi_node); of_node_put(ugeth->ug_info->phy_node); + unregister_netdev(dev); + free_netdev(dev); return 0; } -- 2.23.0
Re: [PATCH v3 1/3] HID: hid-sensor-custom: Add custom sensor iio support
On Thu, 3 Dec 2020 11:53:50 +0800
Ye Xiang wrote:
> Currently custom sensors properties are not decoded and it is up to
> user space to interpret.
>
> Some manufacturers already standardized the meaning of some custom sensors.
> They can be presented as a proper IIO sensor. We can identify these sensors
> based on manufacturer and serial number property in the report.
>
> This change is identifying hinge sensor when the manufacturer is "INTEL".
> This creates a platform device so that a sensor driver can be loaded to
> process these sensors.
>
> Signed-off-by: Ye Xiang
Hi,
A few little comments inline.
Others are much more familiar with this code than I am though so I'm sure
they will give a more in depth review!
> ---
> drivers/hid/hid-sensor-custom.c | 181
> include/linux/hid-sensor-ids.h | 14 +++
> 2 files changed, 195 insertions(+)
>
> diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
> index 4d25577a8573..b8e59021c6a8 100644
> --- a/drivers/hid/hid-sensor-custom.c
> +++ b/drivers/hid/hid-sensor-custom.c
> @@ -4,6 +4,7 @@
> * Copyright (c) 2015, Intel Corporation.
> */
>
> +#include
> #include
> #include
> #include
> @@ -21,6 +22,7 @@
> #define HID_CUSTOM_TOTAL_ATTRS (HID_CUSTOM_MAX_CORE_ATTRS + 1)
> #define HID_CUSTOM_FIFO_SIZE 4096
> #define HID_CUSTOM_MAX_FEATURE_BYTES 64
> +#define HID_SENSOR_USAGE_LENGTH (4 + 1)
>
> struct hid_sensor_custom_field {
> int report_id;
> @@ -50,6 +52,8 @@ struct hid_sensor_custom {
> struct kfifo data_fifo;
> unsigned long misc_opened;
> wait_queue_head_t wait;
> + struct platform_device *custom_pdev;
> + bool custom_pdev_exposed;
Note on this below. I'm not sure the boolean brings us any advantages.
> };
>
> /* Header for each sample to user space via dev interface */
> @@ -746,11 +750,164 @@ static void hid_sensor_custom_dev_if_remove(struct
> hid_sensor_custom
>
> }
>
> +/*
> + * use sensors luid which is defined in FW, such as ISH,
> + * to identify sensor.
Perhaps rephrase as
luid defined in FW (e.g. ISH). May be used to identify sensor.
> + */
> +static const char *const known_sensor_luid[] = { "020B" };
> +
> +static int get_luid_table_index(unsigned char *usage_str)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(known_sensor_luid); i++) {
> + if (!strncmp(usage_str, known_sensor_luid[i],
> + strlen(known_sensor_luid[i])))
> + return i;
> + }
> +
> + return -1;
> +}
> +
> +static int get_known_custom_sensor_index(struct hid_sensor_hub_device *hsdev)
> +{
> + struct hid_sensor_hub_attribute_info sensor_manufacturer = { 0 };
> + struct hid_sensor_hub_attribute_info sensor_luid_info = { 0 };
> + int report_size;
> + int ret;
> + u16 *w_buf;
> + char *buf;
> + int w_buf_len = sizeof(u16) * HID_CUSTOM_MAX_FEATURE_BYTES;
> + int buf_len = sizeof(char) * HID_CUSTOM_MAX_FEATURE_BYTES;
> + int i;
> + int index;
> +
> + w_buf = kzalloc(w_buf_len, GFP_KERNEL);
> + if (!w_buf) {
> + ret = -ENOMEM;
> + goto error_out2;
> + }
> +
> + buf = kzalloc(buf_len, GFP_KERNEL);
> + if (!buf) {
> + ret = -ENOMEM;
> + goto error_out1;
> + }
> + /* get manufacturer info */
> + ret = sensor_hub_input_get_attribute_info(
> + hsdev, HID_FEATURE_REPORT, hsdev->usage,
> + HID_USAGE_SENSOR_PROP_MANUFACTURER, _manufacturer);
> + if (ret < 0) {
> + ret = -ENODEV;
> + goto error_out;
> + }
> +
> + report_size =
> + sensor_hub_get_feature(hsdev, sensor_manufacturer.report_id,
> +sensor_manufacturer.index, w_buf_len,
> +w_buf);
> + if (report_size <= 0) {
> + hid_err(hsdev->hdev,
> + "Failed to get sensor manufacturer info %d\n",
> + report_size);
> + ret = -ENODEV;
> + goto error_out;
> + }
> +
> + /* convert from wide char to char */
> + for (i = 0; i < buf_len - 1 && w_buf[i]; i++)
> + buf[i] = (char)w_buf[i];
> +
> + /* ensure it's ISH sensor */
> + if (strncmp(buf, "INTEL", strlen("INTEL"))) {
> + ret = -ENODEV;
> + goto error_out;
> + }
> +
> + memset(w_buf, 0, w_buf_len);
> + memset(buf, 0, buf_len);
> +
> + /* get real usage id */
> + ret = sensor_hub_input_get_attribute_info(
> + hsdev, HID_FEATURE_REPORT, hsdev->usage,
> + HID_USAGE_SENSOR_PROP_SERIAL_NUM, _luid_info);
> + if (ret < 0) {
> + ret = -ENODEV;
> + goto error_out;
> + }
> +
> + report_size = sensor_hub_get_feature(hsdev, sensor_luid_info.report_id,
> +
[PATCH 06/20] soc: fsl: qe: add cpm_muram_free_addr() helper
Add a helper that takes a virtual address rather than the muram
offset. This will be used in a couple of places to avoid having to
store both the offset and the virtual address, as well as removing
NULL checks from the callers.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_common.c | 12
include/soc/fsl/qe/qe.h| 5 +
2 files changed, 17 insertions(+)
diff --git a/drivers/soc/fsl/qe/qe_common.c b/drivers/soc/fsl/qe/qe_common.c
index 303cc2f5eb4a..448ef7f5321a 100644
--- a/drivers/soc/fsl/qe/qe_common.c
+++ b/drivers/soc/fsl/qe/qe_common.c
@@ -238,3 +238,15 @@ dma_addr_t cpm_muram_dma(void __iomem *addr)
return muram_pbase + (addr - muram_vbase);
}
EXPORT_SYMBOL(cpm_muram_dma);
+
+/*
+ * As cpm_muram_free, but takes the virtual address rather than the
+ * muram offset.
+ */
+void cpm_muram_free_addr(const void __iomem *addr)
+{
+ if (!addr)
+ return;
+ cpm_muram_free(cpm_muram_offset(addr));
+}
+EXPORT_SYMBOL(cpm_muram_free_addr);
diff --git a/include/soc/fsl/qe/qe.h b/include/soc/fsl/qe/qe.h
index 8ee3747433c0..66f1afc393d1 100644
--- a/include/soc/fsl/qe/qe.h
+++ b/include/soc/fsl/qe/qe.h
@@ -104,6 +104,7 @@ s32 cpm_muram_alloc_fixed(unsigned long offset, unsigned
long size);
void __iomem *cpm_muram_addr(unsigned long offset);
unsigned long cpm_muram_offset(const void __iomem *addr);
dma_addr_t cpm_muram_dma(void __iomem *addr);
+void cpm_muram_free_addr(const void __iomem *addr);
#else
static inline s32 cpm_muram_alloc(unsigned long size,
unsigned long align)
@@ -135,6 +136,9 @@ static inline dma_addr_t cpm_muram_dma(void __iomem *addr)
{
return 0;
}
+static inline void cpm_muram_free_addr(const void __iomem *addr)
+{
+}
#endif /* defined(CONFIG_CPM) || defined(CONFIG_QUICC_ENGINE) */
/* QE PIO */
@@ -239,6 +243,7 @@ static inline int qe_alive_during_sleep(void)
#define qe_muram_addr cpm_muram_addr
#define qe_muram_offset cpm_muram_offset
#define qe_muram_dma cpm_muram_dma
+#define qe_muram_free_addr cpm_muram_free_addr
#ifdef CONFIG_PPC32
#define qe_iowrite8(val, addr) out_8(addr, val)
--
2.23.0
[PATCH 07/20] ethernet: ucc_geth: use qe_muram_free_addr()
This removes the explicit NULL checks, and allows us to stop storing
at least some of the _offset values separately.
Signed-off-by: Rasmus Villemoes
---
drivers/net/ethernet/freescale/ucc_geth.c | 77 ++-
1 file changed, 33 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index 6446f2e562c9..bbcdb77be9a8 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -1921,50 +1921,39 @@ static void ucc_geth_memclean(struct ucc_geth_private
*ugeth)
ugeth->uccf = NULL;
}
- if (ugeth->p_thread_data_tx) {
- qe_muram_free(ugeth->thread_dat_tx_offset);
- ugeth->p_thread_data_tx = NULL;
- }
- if (ugeth->p_thread_data_rx) {
- qe_muram_free(ugeth->thread_dat_rx_offset);
- ugeth->p_thread_data_rx = NULL;
- }
- if (ugeth->p_exf_glbl_param) {
- qe_muram_free(ugeth->exf_glbl_param_offset);
- ugeth->p_exf_glbl_param = NULL;
- }
- if (ugeth->p_rx_glbl_pram) {
- qe_muram_free(ugeth->rx_glbl_pram_offset);
- ugeth->p_rx_glbl_pram = NULL;
- }
- if (ugeth->p_tx_glbl_pram) {
- qe_muram_free(ugeth->tx_glbl_pram_offset);
- ugeth->p_tx_glbl_pram = NULL;
- }
- if (ugeth->p_send_q_mem_reg) {
- qe_muram_free(ugeth->send_q_mem_reg_offset);
- ugeth->p_send_q_mem_reg = NULL;
- }
- if (ugeth->p_scheduler) {
- qe_muram_free(ugeth->scheduler_offset);
- ugeth->p_scheduler = NULL;
- }
- if (ugeth->p_tx_fw_statistics_pram) {
- qe_muram_free(ugeth->tx_fw_statistics_pram_offset);
- ugeth->p_tx_fw_statistics_pram = NULL;
- }
- if (ugeth->p_rx_fw_statistics_pram) {
- qe_muram_free(ugeth->rx_fw_statistics_pram_offset);
- ugeth->p_rx_fw_statistics_pram = NULL;
- }
- if (ugeth->p_rx_irq_coalescing_tbl) {
- qe_muram_free(ugeth->rx_irq_coalescing_tbl_offset);
- ugeth->p_rx_irq_coalescing_tbl = NULL;
- }
- if (ugeth->p_rx_bd_qs_tbl) {
- qe_muram_free(ugeth->rx_bd_qs_tbl_offset);
- ugeth->p_rx_bd_qs_tbl = NULL;
- }
+ qe_muram_free_addr(ugeth->p_thread_data_tx);
+ ugeth->p_thread_data_tx = NULL;
+
+ qe_muram_free_addr(ugeth->p_thread_data_rx);
+ ugeth->p_thread_data_rx = NULL;
+
+ qe_muram_free_addr(ugeth->p_exf_glbl_param);
+ ugeth->p_exf_glbl_param = NULL;
+
+ qe_muram_free_addr(ugeth->p_rx_glbl_pram);
+ ugeth->p_rx_glbl_pram = NULL;
+
+ qe_muram_free_addr(ugeth->p_tx_glbl_pram);
+ ugeth->p_tx_glbl_pram = NULL;
+
+ qe_muram_free_addr(ugeth->p_send_q_mem_reg);
+ ugeth->p_send_q_mem_reg = NULL;
+
+ qe_muram_free_addr(ugeth->p_scheduler);
+ ugeth->p_scheduler = NULL;
+
+ qe_muram_free_addr(ugeth->p_tx_fw_statistics_pram);
+ ugeth->p_tx_fw_statistics_pram = NULL;
+
+ qe_muram_free_addr(ugeth->p_rx_fw_statistics_pram);
+ ugeth->p_rx_fw_statistics_pram = NULL;
+
+ qe_muram_free_addr(ugeth->p_rx_irq_coalescing_tbl);
+ ugeth->p_rx_irq_coalescing_tbl = NULL;
+
+ qe_muram_free_addr(ugeth->p_rx_bd_qs_tbl);
+ ugeth->p_rx_bd_qs_tbl = NULL;
+
if (ugeth->p_init_enet_param_shadow) {
return_init_enet_entries(ugeth,
&(ugeth->p_init_enet_param_shadow->
--
2.23.0
[PATCH 09/20] ethernet: ucc_geth: replace kmalloc+memset by kzalloc
Signed-off-by: Rasmus Villemoes
---
drivers/net/ethernet/freescale/ucc_geth.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index f854ff90f238..e1574c14b7e5 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -2904,14 +2904,11 @@ static int ucc_geth_startup(struct ucc_geth_private
*ugeth)
* allocated resources can be released when the channel is freed.
*/
if (!(ugeth->p_init_enet_param_shadow =
- kmalloc(sizeof(struct ucc_geth_init_pram), GFP_KERNEL))) {
+ kzalloc(sizeof(struct ucc_geth_init_pram), GFP_KERNEL))) {
if (netif_msg_ifup(ugeth))
pr_err("Can not allocate memory for
p_UccInitEnetParamShadows\n");
return -ENOMEM;
}
- /* Zero out *p_init_enet_param_shadow */
- memset((char *)ugeth->p_init_enet_param_shadow,
- 0, sizeof(struct ucc_geth_init_pram));
/* Fill shadow InitEnet command parameter structure */
--
2.23.0
Re: [PATCH 1/1] dt-bindings: eliminate yamllint warnings
On Fri, Dec 04, 2020 at 10:42:26AM +0800, Zhen Lei wrote: > All warnings are related only to "wrong indentation", except one: > Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:4:1: \ > [error] missing document start "---" (document-start) > > Signed-off-by: Zhen Lei > Cc: Rob Herring > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: David Airlie > Cc: Daniel Vetter > Cc: Sumit Semwal > Cc: Thierry Reding > Cc: Sam Ravnborg > Cc: Hans Verkuil > Cc: Mauro Carvalho Chehab > Cc: Sakari Ailus > Cc: Ricardo Ribalda > Cc: Ulf Hansson > Cc: Matthias Brugger > Cc: Liam Girdwood > Cc: Mark Brown For the bindings/display/* parts: Acked-by: Sam Ravnborg
[PATCH 02/20] ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram
Table 8-53 in the QUICC Engine Reference manual shows definitions of
fields up to a size of 192 bytes, not just 128. But in table 8-111,
one does find the text
Base Address of the Global Transmitter Parameter RAM Page. [...]
The user needs to allocate 128 bytes for this page. The address must
be aligned to the page size.
I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual;
they both have this inconsistency (and the table numbers are the
same).
Adding a bit of debug printing, on my board the struct
ucc_geth_tx_global_pram is allocated at offset 0x880, while
the (opaque) ucc_geth_thread_data_tx gets allocated immediately
afterwards, at 0x900. So whatever the engine writes into the thread
data overlaps with the tail of the global tx pram (and devmem says
that something does get written during a simple ping).
I haven't observed any failure that could be attributed to this, but
it seems to be the kind of thing that would be extremely hard to
debug. So extend the struct definition so that we do allocate 192
bytes.
Signed-off-by: Rasmus Villemoes
---
drivers/net/ethernet/freescale/ucc_geth.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h
b/drivers/net/ethernet/freescale/ucc_geth.h
index 3fe903972195..c80bed2c995c 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -575,7 +575,14 @@ struct ucc_geth_tx_global_pram {
u32 vtagtable[0x8]; /* 8 4-byte VLAN tags */
u32 tqptr; /* a base pointer to the Tx Queues Memory
Region */
- u8 res2[0x80 - 0x74];
+ u8 res2[0x78 - 0x74];
+ u64 snums_en;
+ u32 l2l3baseptr;/* top byte consists of a few other bit fields
*/
+
+ u16 mtu[8];
+ u8 res3[0xa8 - 0x94];
+ u32 wrrtablebase; /* top byte is reserved */
+ u8 res4[0xc0 - 0xac];
} __packed;
/* structure representing Extended Filtering Global Parameters in PRAM */
--
2.23.0
[PATCH 03/20] ethernet: ucc_geth: remove unused read of temoder field
In theory, such a read-after-write might be required by the hardware, but nothing in the data sheet suggests that to be the case. The name test also suggests that it's some debug leftover. Signed-off-by: Rasmus Villemoes --- drivers/net/ethernet/freescale/ucc_geth.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c index 380c1f09adaf..6446f2e562c9 100644 --- a/drivers/net/ethernet/freescale/ucc_geth.c +++ b/drivers/net/ethernet/freescale/ucc_geth.c @@ -2359,7 +2359,6 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth) u32 init_enet_pram_offset, cecr_subblock, command; u32 ifstat, i, j, size, l2qt, l3qt; u16 temoder = UCC_GETH_TEMODER_INIT; - u16 test; u8 function_code = 0; u8 __iomem *endOfRing; u8 numThreadsRxNumerical, numThreadsTxNumerical; @@ -2667,8 +2666,6 @@ static int ucc_geth_startup(struct ucc_geth_private *ugeth) temoder |= ((ug_info->numQueuesTx - 1) << TEMODER_NUM_OF_QUEUES_SHIFT); out_be16(>p_tx_glbl_pram->temoder, temoder); - test = in_be16(>p_tx_glbl_pram->temoder); - /* Function code register value to be used later */ function_code = UCC_BMR_BO_BE | UCC_BMR_GBL; /* Required for QE */ -- 2.23.0
[PATCH 04/20] soc: fsl: qe: make cpm_muram_offset take a const void* argument
Allow passing const-qualified pointers without requiring a cast in the
caller.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_common.c | 2 +-
include/soc/fsl/qe/qe.h| 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_common.c b/drivers/soc/fsl/qe/qe_common.c
index 75075591f630..0fbdc965c4cb 100644
--- a/drivers/soc/fsl/qe/qe_common.c
+++ b/drivers/soc/fsl/qe/qe_common.c
@@ -223,7 +223,7 @@ void __iomem *cpm_muram_addr(unsigned long offset)
}
EXPORT_SYMBOL(cpm_muram_addr);
-unsigned long cpm_muram_offset(void __iomem *addr)
+unsigned long cpm_muram_offset(const void __iomem *addr)
{
return addr - (void __iomem *)muram_vbase;
}
diff --git a/include/soc/fsl/qe/qe.h b/include/soc/fsl/qe/qe.h
index 3feddfec9f87..8ee3747433c0 100644
--- a/include/soc/fsl/qe/qe.h
+++ b/include/soc/fsl/qe/qe.h
@@ -102,7 +102,7 @@ s32 cpm_muram_alloc(unsigned long size, unsigned long
align);
void cpm_muram_free(s32 offset);
s32 cpm_muram_alloc_fixed(unsigned long offset, unsigned long size);
void __iomem *cpm_muram_addr(unsigned long offset);
-unsigned long cpm_muram_offset(void __iomem *addr);
+unsigned long cpm_muram_offset(const void __iomem *addr);
dma_addr_t cpm_muram_dma(void __iomem *addr);
#else
static inline s32 cpm_muram_alloc(unsigned long size,
@@ -126,7 +126,7 @@ static inline void __iomem *cpm_muram_addr(unsigned long
offset)
return NULL;
}
-static inline unsigned long cpm_muram_offset(void __iomem *addr)
+static inline unsigned long cpm_muram_offset(const void __iomem *addr)
{
return -ENOSYS;
}
--
2.23.0
[PATCH 00/20] ethernet: ucc_geth: assorted fixes and simplifications
While trying to figure out how to allow bumping the MTU with the
ucc_geth driver, I fell into a rabbit hole and stumbled on a whole
bunch of issues of varying importance - some are outright bug fixes,
while most are a matter of simplifying the code to make it more
accessible.
At the end of digging around the code and data sheet to figure out how
it all works, I think the MTU issue might be fixed by a one-liner, but
I'm not sure it can be that simple. It does seem to work (ping -s X
works for larger values of X, and wireshark confirms that the packets
are not fragmented).
Re patch 2, someone in NXP should check how the hardware actually
works and make an updated reference manual available.
Rasmus Villemoes (20):
ethernet: ucc_geth: set dev->max_mtu to 1518
ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram
ethernet: ucc_geth: remove unused read of temoder field
soc: fsl: qe: make cpm_muram_offset take a const void* argument
soc: fsl: qe: store muram_vbase as a void pointer instead of u8
soc: fsl: qe: add cpm_muram_free_addr() helper
ethernet: ucc_geth: use qe_muram_free_addr()
ethernet: ucc_geth: remove unnecessary memset_io() calls
ethernet: ucc_geth: replace kmalloc+memset by kzalloc
ethernet: ucc_geth: remove {rx,tx}_glbl_pram_offset from struct
ucc_geth_private
ethernet: ucc_geth: fix use-after-free in ucc_geth_remove()
ethernet: ucc_geth: factor out parsing of {rx,tx}-clock{,-name}
properties
ethernet: ucc_geth: constify ugeth_primary_info
ethernet: ucc_geth: don't statically allocate eight ucc_geth_info
ethernet: ucc_geth: use UCC_GETH_{RX,TX}_BD_RING_ALIGNMENT macros
directly
ethernet: ucc_geth: remove bd_mem_part and all associated code
ethernet: ucc_geth: replace kmalloc_array()+for loop by kcalloc()
ethernet: ucc_geth: add helper to replace repeated switch statements
ethernet: ucc_geth: inform the compiler that numQueues is always 1
ethernet: ucc_geth: simplify rx/tx allocations
drivers/net/ethernet/freescale/ucc_geth.c | 553 --
drivers/net/ethernet/freescale/ucc_geth.h | 15 +-
drivers/soc/fsl/qe/qe_common.c| 20 +-
include/soc/fsl/qe/qe.h | 15 +-
include/soc/fsl/qe/ucc_fast.h | 1 -
5 files changed, 219 insertions(+), 385 deletions(-)
--
2.23.0
Re: [PATCH v2 2/2] drm: panel: add Khadas TS050 panel driver
Hi Neil,
> +
> +static int khadas_ts050_panel_probe(struct mipi_dsi_device *dsi)
> +{
> + struct khadas_ts050_panel *khadas_ts050;
> + int err;
> +
> + dsi->lanes = 4;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
> + MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET;
> +
> + khadas_ts050 = devm_kzalloc(>dev, sizeof(*khadas_ts050),
> + GFP_KERNEL);
> + if (!khadas_ts050)
> + return -ENOMEM;
> +
> + mipi_dsi_set_drvdata(dsi, khadas_ts050);
> + khadas_ts050->link = dsi;
> +
> + err = khadas_ts050_panel_add(khadas_ts050);
> + if (err < 0)
> + return err;
> +
> + return mipi_dsi_attach(dsi);
> +}
If mipi_dsi_attach() failes then da a drm_panel_remove() like this:
ret = mipi_dsi_attach(dsi);
if (ret)
drm_panel_remove(_ts050->base);
return ret;
This is again something several panels gets wrong.
With this fixed:
Reviewed-by: Sam Ravnborg
I assume you will fix it while applying.
Sam
Re: [RFC PATCH v1 07/12] efi: Replace strstarts() by str_has_prefix().
Le vendredi 4 décembre 2020, 19:02:09 CET James Bottomley a écrit :
> On Fri, 2020-12-04 at 18:07 +0100, Ard Biesheuvel wrote:
> > On Fri, 4 Dec 2020 at 18:06,
> >
> > wrote:
> > > From: Francis Laniel
> > >
> > > The two functions indicates if a string begins with a given prefix.
> > > The only difference is that strstarts() returns a bool while
> > > str_has_prefix()
> > > returns the length of the prefix if the string begins with it or 0
> > > otherwise.
> >
> > Why?
>
> I think I can answer that. If the conversion were done properly (which
> it's not) you could get rid of the double strings in the code which are
> error prone if you update one and forget another. This gives a good
> example: 3d739c1f6156 ("tracing: Use the return of str_has_prefix() to
> remove open coded numbers"). so in your code you'd replace things like
>
> if (strstarts(option, "rgb")) {
> option += strlen("rgb");
> ...
>
> with
>
> len = str_has_prefix(option, "rgb");
> if (len) {
> option += len
> ...
The proposed changes were a bit mechanical and I did not think about using the
returned value in the way you proposed.
This a good idea though, so I can modify my patches to include this and send a
v2!
> Obviously you also have cases where strstart is used as a boolean with
> no need to know the length ... I think there's no value to converting
> those.
For the v2, should I only change cases where using str_has_prefix() brings a
benefit over strstarts() or all the cases?
> James
Re: [Bug 202453] TRACE irq/18-i801_smb Tainted when enabled threadirqs in kernel commandline.
On Sat, Dec 05 2020 at 17:24, Oleksandr Natalenko wrote:
> On Sat, Dec 05, 2020 at 05:19:18PM +0100, Thomas Gleixner wrote:
>> +/**
>> + * generic_dispatch_irq - Dispatch an interrupt from an interrupt handler
>> + * @irq:The irq number to handle
>> + *
>> + * A wrapper around generic_handle_irq() which ensures that interrupts are
>> + * disabled when the primary handler of the dispatched irq is invoked.
>> + * This is useful for interrupt handlers with dispatching to be safe for
>> + * the forced threaded case.
>> + */
>> +int generic_dispatch_irq(unsigned int irq)
>> +{
>> +unsigned long flags;
>> +int ret;
>> +
>> +local_irq_save();
>> +ret = generic_handle_irq(irq);
>> +local_irq_restore();
>
> FWIW, for me explodes build on v5.10-rc6. I had to change it to
> local_irq_save/restore(flags) (without taking an address via &).
That's right. Don't know what I was thinking when writing it and then
compiling with the patch removed (just checked history ...) Oh, well
Re: [PATCH 3/3] exec: Transform exec_update_mutex into a rw_semaphore
Davidlohr Bueso writes: > On Fri, 04 Dec 2020, Linus Torvalds wrote: > >>On Fri, Dec 4, 2020 at 12:30 PM Bernd Edlinger >> wrote: >>> >perf_event_open (exec_update_mutex -> ovl_i_mutex) >> >>Side note: this one looks like it should be easy to fix. >> >>Is there any real reason why exec_update_mutex is actually gotten that >>early, and held for that long in the perf event code? > > afaict just to validate the whole operation early. Per 79c9ce57eb2 the > mutex will guard the check and the perf_install_in_context vs exec. > >> >>I _think_ we could move the ptrace check to be much later, to _just_ before >>that >> >> * This is the point on no return; we cannot fail hereafter. >> >>point in the perf event install chain.. > > Peter had the idea of doing the ptrace_may_access() check twice: first > lockless and early, then under exec_update_mutex when it mattered right > before perf_install_in_context(): > > https://lore.kernel.org/linux-fsdevel/20200828123720.gz1362...@hirez.programming.kicks-ass.net/ > >> >>I don't think it needs to be moved down even that much, I think it >>would be sufficient to move it down below the "perf_event_alloc()", >>but I didn't check very much. > > Yeah we could just keep a single ptrace_may_access() check just further > down until it won't deadlock. I am trying to understand why the permission check is there. The ptrace_may_access check came in with the earliest version of the code I can find. So going down that path hasn't helped. There are about 65 calls of perf_pmu_register so it definitely makes me nervous holding a semaphore over perf_event_alloc. What is truly silly in all of this is perf_uprobe_event_init fails if !perfmon_capable(). Which means the ptrace_may_access check and holding exec_update_mutex is completely irrelevant to the function of create_local_trace_uprobe. Which is strange in and of itself. I would have thought uprobes would have been the kind of probe that it would be safe for ordinary users to use. This is a much deeper rabit hole than I had anticipated when I started looking and I will have to come back to this after the weekend. If at all possible I would love to be able to move the grabbing of exec_update_mutex after perf_event_alloc and the pluggable functions it calls. It doesn't feel possible to audit that. On the flip side the task is passed in as hw.target. So it may not be possible to move the permission check. It is chaos. Eric
[PATCH][next] arm64: fix the mm build error in mm/kfence/core.c
When I build kernel with ARCH=arm64, the building errors came out like
this:
CC mm/kfence/core.o
In file included from ../mm/kfence/core.c:21:
../arch/arm64/include/asm/kfence.h: In function ‘kfence_protect_page’:
../arch/arm64/include/asm/kfence.h:12:2: error: implicit declaration of
function ‘set_memory_valid’ [-Werror=implicit-function-declaration]
12 | set_memory_valid(addr, 1, !protect);
| ^~~~
cc1: some warnings being treated as errors
which introduced by commit d54febeba2ff ("kfence: use pt_regs to
generate stack trace on faults").
Signed-off-by: Hui Su
---
arch/arm64/include/asm/kfence.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/kfence.h b/arch/arm64/include/asm/kfence.h
index 6c0afeeab635..4d73e34da59d 100644
--- a/arch/arm64/include/asm/kfence.h
+++ b/arch/arm64/include/asm/kfence.h
@@ -4,6 +4,7 @@
#define __ASM_KFENCE_H
#include
+#include
static inline bool arch_kfence_init_pool(void) { return true; }
--
2.25.1
[PATCH] proc: fix lookup in /proc/net subdirectories after setns(2)
commit 1fde6f21d90f8ba5da3cb9c54ca991ed72696c43
proc: fix /proc/net/* after setns(2)
only forced revalidation of regular files under /proc/net/
However, /proc/net/ is unusual in the sense of /proc/net/foo handlers
take netns pointer from parent directory which is old netns.
Steps to reproduce:
(void)open("/proc/net/sctp/snmp", O_RDONLY);
unshare(CLONE_NEWNET);
int fd = open("/proc/net/sctp/snmp", O_RDONLY);
read(fd, , 1);
Read will read wrong data from original netns.
Patch forces lookup on every directory under /proc/net .
Fixes: 1da4d377f943 ("proc: revalidate misc dentries")
Reported-by: "Rantala, Tommi T. (Nokia - FI/Espoo)"
Signed-off-by: Alexey Dobriyan
---
fs/proc/generic.c | 24 ++--
fs/proc/internal.h |7 +++
fs/proc/proc_net.c | 16
include/linux/proc_fs.h |8 +++-
4 files changed, 36 insertions(+), 19 deletions(-)
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -349,6 +349,16 @@ static const struct file_operations proc_dir_operations = {
.iterate_shared = proc_readdir,
};
+static int proc_net_d_revalidate(struct dentry *dentry, unsigned int flags)
+{
+ return 0;
+}
+
+const struct dentry_operations proc_net_dentry_ops = {
+ .d_revalidate = proc_net_d_revalidate,
+ .d_delete = always_delete_dentry,
+};
+
/*
* proc directories can do almost nothing..
*/
@@ -471,8 +481,8 @@ struct proc_dir_entry *proc_symlink(const char *name,
}
EXPORT_SYMBOL(proc_symlink);
-struct proc_dir_entry *proc_mkdir_data(const char *name, umode_t mode,
- struct proc_dir_entry *parent, void *data)
+struct proc_dir_entry *_proc_mkdir(const char *name, umode_t mode,
+ struct proc_dir_entry *parent, void *data, bool force_lookup)
{
struct proc_dir_entry *ent;
@@ -484,10 +494,20 @@ struct proc_dir_entry *proc_mkdir_data(const char *name,
umode_t mode,
ent->data = data;
ent->proc_dir_ops = _dir_operations;
ent->proc_iops = _dir_inode_operations;
+ if (force_lookup) {
+ pde_force_lookup(ent);
+ }
ent = proc_register(parent, ent);
}
return ent;
}
+EXPORT_SYMBOL_GPL(_proc_mkdir);
+
+struct proc_dir_entry *proc_mkdir_data(const char *name, umode_t mode,
+ struct proc_dir_entry *parent, void *data)
+{
+ return _proc_mkdir(name, mode, parent, data, false);
+}
EXPORT_SYMBOL_GPL(proc_mkdir_data);
struct proc_dir_entry *proc_mkdir_mode(const char *name, umode_t mode,
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -310,3 +310,10 @@ extern unsigned long task_statm(struct mm_struct *,
unsigned long *, unsigned long *,
unsigned long *, unsigned long *);
extern void task_mem(struct seq_file *, struct mm_struct *);
+
+extern const struct dentry_operations proc_net_dentry_ops;
+static inline void pde_force_lookup(struct proc_dir_entry *pde)
+{
+ /* /proc/net/ entries can be changed under us by setns(CLONE_NEWNET) */
+ pde->proc_dops = _net_dentry_ops;
+}
--- a/fs/proc/proc_net.c
+++ b/fs/proc/proc_net.c
@@ -39,22 +39,6 @@ static struct net *get_proc_net(const struct inode *inode)
return maybe_get_net(PDE_NET(PDE(inode)));
}
-static int proc_net_d_revalidate(struct dentry *dentry, unsigned int flags)
-{
- return 0;
-}
-
-static const struct dentry_operations proc_net_dentry_ops = {
- .d_revalidate = proc_net_d_revalidate,
- .d_delete = always_delete_dentry,
-};
-
-static void pde_force_lookup(struct proc_dir_entry *pde)
-{
- /* /proc/net/ entries can be changed under us by setns(CLONE_NEWNET) */
- pde->proc_dops = _net_dentry_ops;
-}
-
static int seq_open_net(struct inode *inode, struct file *file)
{
unsigned int state_size = PDE(inode)->state_size;
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -80,6 +80,7 @@ extern void proc_flush_pid(struct pid *);
extern struct proc_dir_entry *proc_symlink(const char *,
struct proc_dir_entry *, const char *);
+struct proc_dir_entry *_proc_mkdir(const char *, umode_t, struct
proc_dir_entry *, void *, bool);
extern struct proc_dir_entry *proc_mkdir(const char *, struct proc_dir_entry
*);
extern struct proc_dir_entry *proc_mkdir_data(const char *, umode_t,
struct proc_dir_entry *, void *);
@@ -162,6 +163,11 @@ static inline struct proc_dir_entry *proc_symlink(const
char *name,
static inline struct proc_dir_entry *proc_mkdir(const char *name,
struct proc_dir_entry *parent) {return NULL;}
static inline struct proc_dir_entry *proc_create_mount_point(const char *name)
{ return NULL; }
+static inline struct proc_dir_entry *_proc_mkdir(const char *name, umode_t
mode,
+ struct
Re: [PATCH v4 net-next 1/2] net: dsa: add optional stats64 support
On Fri, Dec 04, 2020 at 03:56:23PM +0100, Oleksij Rempel wrote: > Allow DSA drivers to export stats64 > > Signed-off-by: Oleksij Rempel > Reviewed-by: Vladimir Oltean Reviewed-by: Andrew Lunn Andrew
Re: [PATCH 1/7] net: macb: add userio bits as platform configuration
On Fri, Dec 04, 2020 at 02:34:15PM +0200, Claudiu Beznea wrote: > This is necessary for SAMA7G5 as it uses different values for > PHY interface and also introduces hdfctlen bit. > > Signed-off-by: Claudiu Beznea Reviewed-by: Andrew Lunn Andrew
Re: [PATCH 5/7] dt-bindings: add documentation for sama7g5 gigabit ethernet interface
On Fri, Dec 04, 2020 at 02:34:19PM +0200, Claudiu Beznea wrote: > Add documentation for SAMA7G5 gigabit ethernet interface. > > Signed-off-by: Claudiu Beznea Reviewed-by: Andrew Lunn Andrew
Re: [PATCH 2/7] net: macb: add capability to not set the clock rate
On Fri, Dec 04, 2020 at 02:34:16PM +0200, Claudiu Beznea wrote: > SAMA7G5's ethernet IPs TX clock could be provided by its generic clock or > by the external clock provided by the PHY. The internal IP logic divides > properly this clock depending on the link speed. The patch adds a new > capability so that macb_set_tx_clock() to not be called for IPs having > this capability (the clock rate, in case of generic clock, is set at the > boot time via device tree and the driver only enables it). > > Signed-off-by: Claudiu Beznea Reviewed-by: Andrew Lunn Andrew
Re: [PATCH v4 net-next 2/2] net: dsa: qca: ar9331: export stats64
> +static void ar9331_stats_update(struct ar9331_sw_port *port,
> + struct rtnl_link_stats64 *stats)
> +{
> + struct ar9331_sw_stats *s = >stats;
> +
> + stats->rx_packets = s->rxbroad + s->rxmulti + s->rx64byte +
> + s->rx128byte + s->rx256byte + s->rx512byte + s->rx1024byte +
> + s->rx1518byte + s->rxmaxbyte;
> + stats->tx_packets = s->txbroad + s->txmulti + s->tx64byte +
> + s->tx128byte + s->tx256byte + s->tx512byte + s->tx1024byte +
> + s->tx1518byte + s->txmaxbyte;
> + stats->rx_bytes = s->rxgoodbyte;
> + stats->tx_bytes = s->txbyte;
> + stats->rx_errors = s->rxfcserr + s->rxalignerr + s->rxrunt +
> + s->rxfragment + s->rxoverflow;
> + stats->tx_errors = s->txoversize;
> + stats->multicast = s->rxmulti;
> + stats->collisions = s->txcollision;
> + stats->rx_length_errors = s->rxrunt + s->rxfragment + s->rxtoolong;
> + stats->rx_crc_errors = s->rxfcserr + s->rxalignerr + s->rxfragment;
> + stats->rx_frame_errors = s->rxalignerr;
> + stats->rx_missed_errors = s->rxoverflow;
> + stats->tx_aborted_errors = s->txabortcol;
> + stats->tx_fifo_errors = s->txunderrun;
> + stats->tx_window_errors = s->txlatecol;
> + stats->rx_nohandler = s->filtered;
> +}
> +
Since these are u64 and you cannot take the mutex, you need to using
include/linux/u64_stats_sync.h
Andrew
Re: [PATCH 7/7] net: macb: add support for sama7g5 emac interface
On Fri, Dec 04, 2020 at 02:34:21PM +0200, Claudiu Beznea wrote: > Add support for SAMA7G5 10/100Mbps interface. > > Signed-off-by: Claudiu Beznea Reviewed-by: Andrew Lunn Andrew
Re: [PATCH net v3] bonding: fix feature flag setting at init time
On Thu, Dec 3, 2020 at 11:45 AM Jakub Kicinski wrote:
...
> nit: let's narrow down the ifdef-enery
>
> no need for the ifdef here, if the helper looks like this:
>
> +static void bond_set_xfrm_features(struct net_device *bond_dev, u64 mode)
> +{
> +#ifdef CONFIG_XFRM_OFFLOAD
> + if (mode == BOND_MODE_ACTIVEBACKUP)
> + bond_dev->wanted_features |= BOND_XFRM_FEATURES;
> + else
> + bond_dev->wanted_features &= ~BOND_XFRM_FEATURES;
> +
> + netdev_update_features(bond_dev);
> +#endif /* CONFIG_XFRM_OFFLOAD */
> +}
>
> Even better:
>
> +static void bond_set_xfrm_features(struct net_device *bond_dev, u64 mode)
> +{
> + if (!IS_ENABLED(CONFIG_XFRM_OFFLOAD))
> + return;
> +
> + if (mode == BOND_MODE_ACTIVEBACKUP)
> + bond_dev->wanted_features |= BOND_XFRM_FEATURES;
> + else
> + bond_dev->wanted_features &= ~BOND_XFRM_FEATURES;
> +
> + netdev_update_features(bond_dev);
> +}
>
> (Assuming BOND_XFRM_FEATURES doesn't itself hide under an ifdef.)
It is, but doesn't need to be. I can mix these changes in as well.
--
Jarod Wilson
ja...@redhat.com
Re: [PATCH v3 3/6] ARM: dts: sun8i: v3s: Add node for system control
On 12/3/20 10:44 AM, Chen-Yu Tsai wrote:
> On Fri, Dec 4, 2020 at 12:25 AM Martin Cerveny wrote:
>>
>> Hello.
>>
>> On Thu, 3 Dec 2020, Chen-Yu Tsai wrote:
>>
>>> Hi,
>>>
>>> On Mon, Nov 16, 2020 at 8:57 PM Martin Cerveny
>>> wrote:
Allwinner V3s has system control and SRAM C1 region similar to H3.
Signed-off-by: Martin Cerveny
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 0c7341676921..70193512c222 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -161,6 +161,20 @@ syscon: system-control@1c0 {
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+ sram_c: sram@1d0 {
+ compatible = "mmio-sram";
+ reg = <0x01d0 0x8>;
>>>
>>> How was this address derived? Did you check that there is actually SRAM
>>> here?
>>
>> Yes, I did some checking (mmap). But I repeated measurement and found
>> mirrored regions:
>>
>> - SRAM_C is mirrored from 0x_4000 (primary location) to 0x01d0_4000
>> (size 0xb000)
>>(probably exact size is 0xb0c0)
>> - rest of 0x01d0_ are discontinuously filled with R/W register sets
>>(probably some internals registers from VE) that I thought to be SRAM too
>> - register SRAM_CTRL_REG0==0x01c00_ (value 0x7fff_) switch whole
>>region 0x01d0_-0x01df_ __AND__ 0x_4000-0x_
>> - VE/cedrus code use this regions indirectly
>>(VE_AVC_SRAM_PORT_OFFSET/VE_AVC_SRAM_PORT_DATA...)
>>and it is not influenced by "true" SRAM mapping or size
>
> Could you add this to your commit log? That would make the information
> available to others, and you could mention that you only added the
> location that is contiguous SRAM without the interspersed registers.
>
> So based on this, and what we've seen with the H616, I'm guessing
> 0x01d0_ - 0x01df_ exposes all the internal guts of the VE,
> while SRAM C @ 0x4000 just maps a small portion out.
>
>> -> so I suppose to better use only SRAM_C lower definition:
>
> Yes that would be more appropriate, as it matches the manual, and as you
> mentioned, is *real* SRAM.
My reading of the manual and comments in the BSP U-Boot is that the high
address near the VE registers is the "real" address. The alternate SRAM
mapping just past the end of SRAM A1 exists specifically so the boot ROM
can load boot0/TOC0 images larger than would fit in SRAM A1.
I don't have a copy of the V3s BROM, but here's the logic from the
beginning of the H6 SBROM, which first enables the VE bus clock and
reset before mapping the SRAM:
; VE_BGR_REG |= BIT(16)
2dc: e59f113c ldr r1, [pc, #316] ; 420
2e0: e5912000 ldr r2, [r1]
2e4: e3a03801 mov r3, #65536 ; 0x1
2e8: e1822003 orr r2, r2, r3
2ec: e5812000 str r2, [r1]
; VE_BGR_REG |= BIT(0)
2f0: e59f1128 ldr r1, [pc, #296] ; 420
2f4: e5912000 ldr r2, [r1]
2f8: e3a03001 mov r3, #1
2fc: e1822003 orr r2, r2, r3
300: e5812000 str r2, [r1]
; SRAM_CTRL_REG0 &= BIT(31)
304: e3a01403 mov r1, #50331648 ; 0x300
308: e5912000 ldr r2, [r1]
30c: e3c220ff bic r2, r2, #255 ; 0xff
310: e3c22cff bic r2, r2, #65280 ; 0xff00
314: e3c228ff bic r2, r2, #16711680 ; 0xff
318: e3c2247f bic r2, r2, #2130706432 ; 0x7f00
31c: e5812000 str r2, [r1]
; SRAM_CTRL_REG1 = BIT(24) | BIT(0)
320: e59f10fc ldr r1, [pc, #252] ; 424
324: e3a02401 mov r2, #16777216 ; 0x100
328: e1822003 orr r2, r2, r3
32c: e5812000 str r2, [r1]
...
420: .word 0300169c
424: .word 0304
Then U-Boot SPL[1] sets the SRAM back to "normal mode" before turning
off the VE gating and reset:
//VE SRAM:set sram to normal mode, default boot mode
reg_val = readl(SUNXI_SYSCRL_BASE+0X0004);
reg_val &= ~(0x1<<24);
writel(reg_val, SUNXI_SYSCRL_BASE+0X0004);
//VE gating Bus Reset :brom set them, but not require now
reg_val = readl(CCMU_VE_BGR_REG);
reg_val &= ~(0x1<<0);
reg_val &= ~(0x1<<16);
writel(reg_val, CCMU_VE_BGR_REG);
Other SoCs have a similar code to unmap SRAM C[2]. The AHB1 bus clock
frequency limitation makes sense given that it has to go through the VE
hardware block to get to the SRAM.
In fact, the AHB1 clock limitation when using the low mapping should be
reason enough to prefer the high mapping.
Cheers,
Samuel
[1]:
https://github.com/Allwinner-Homlet/H6-BSP4.9-brandy/blob/master/u-boot-2014.07/board/sunxi/sun50iw6p1/sun50iw6p1.c#L60
[2]:
https://github.com/Allwinner-Homlet/H6-BSP4.9-brandy/blob/master/u-boot-2014.07/board/sunxi/sun8iw10p1/sun8iw10p1.c#L75
Re: [PATCH 6/7] net: macb: add support for sama7g5 gem interface
On Fri, Dec 04, 2020 at 02:34:20PM +0200, Claudiu Beznea wrote: > Add support for SAMA7G5 gigabit ethernet interface. > > Signed-off-by: Claudiu Beznea Reviewed-by: Andrew Lunn Andrew
Re: [PATCH] phy: mediatek: statify mtk_hdmi_phy_driver
Hi, Vinod:
Vinod Koul 於 2020年12月5日 週六 下午5:11寫道：
>
> mtk_hdmi_phy_driver is not declared as static, so statify it.
>
> drivers/phy/mediatek/phy-mtk-hdmi.c:204:24: warning: symbol
> 'mtk_hdmi_phy_driver' was not declared. Should it be static?
>
Acked-by: Chun-Kuang Hu
> Signed-off-by: Vinod Koul
> ---
> drivers/phy/mediatek/phy-mtk-hdmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c
> b/drivers/phy/mediatek/phy-mtk-hdmi.c
> index 47c029d4b270..c5c61f5a9ea0 100644
> --- a/drivers/phy/mediatek/phy-mtk-hdmi.c
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
> @@ -201,7 +201,7 @@ static const struct of_device_id mtk_hdmi_phy_match[] = {
> {},
> };
>
> -struct platform_driver mtk_hdmi_phy_driver = {
> +static struct platform_driver mtk_hdmi_phy_driver = {
> .probe = mtk_hdmi_phy_probe,
> .driver = {
> .name = "mediatek-hdmi-phy",
> --
> 2.26.2
>
Re: [PATCH 1/3] iio: dummy: convert all simple allocation devm_ variants
On Thu, 3 Dec 2020 11:50:03 +0200
Alexandru Ardelean wrote:
> Since a main requirement for an IIO device is to have a parent device
> object, it makes sense to attach more of the IIO device's objects to the
> lifetime of the parent object, to clean up the code.
> The idea is to also provide a base example that is more up-to-date with
> what's going on lately with most IIO drivers.
To some degree maybe, it's also very very handy for testing odd corner
cases with. I'd definitely not recommend it as a reference driver
because it inherently has some odd corners because we need to
fake various things that don't exist without hardware.
>
> This change tackles the simple allocations, to convert them to
> device-managed calls, and tie them to the parent device.
I'm confused or maybe I missrecall how this works.
IIRC there isn't a parent device...
Maybe we could create one via a bit of smoke and magic.
>
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/iio/dummy/iio_simple_dummy.c | 29
> 1 file changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/iio/dummy/iio_simple_dummy.c
> b/drivers/iio/dummy/iio_simple_dummy.c
> index c0b7ef900735..2a2e62f780a1 100644
> --- a/drivers/iio/dummy/iio_simple_dummy.c
> +++ b/drivers/iio/dummy/iio_simple_dummy.c
> @@ -574,11 +574,9 @@ static struct iio_sw_device *iio_dummy_probe(const char
> *name)
>* parent = >dev;
>*/
>
> - swd = kzalloc(sizeof(*swd), GFP_KERNEL);
> - if (!swd) {
> - ret = -ENOMEM;
> - goto error_kzalloc;
> - }
> + swd = devm_kzalloc(parent, sizeof(*swd), GFP_KERNEL);
> + if (!swd)
> + return ERR_PTR(-ENOMEM);
> /*
>* Allocate an IIO device.
>*
> @@ -587,11 +585,9 @@ static struct iio_sw_device *iio_dummy_probe(const char
> *name)
>* It also has a region (accessed by iio_priv()
>* for chip specific state information.
>*/
> - indio_dev = iio_device_alloc(parent, sizeof(*st));
> - if (!indio_dev) {
> - ret = -ENOMEM;
> - goto error_ret;
> - }
> + indio_dev = devm_iio_device_alloc(parent, sizeof(*st));
> + if (!indio_dev)
> + return ERR_PTR(-ENOMEM);
>
> st = iio_priv(indio_dev);
> mutex_init(>lock);
> @@ -615,7 +611,7 @@ static struct iio_sw_device *iio_dummy_probe(const char
> *name)
>*indio_dev->name = id->name;
>*indio_dev->name = spi_get_device_id(spi)->name;
>*/
> - indio_dev->name = kstrdup(name, GFP_KERNEL);
> + indio_dev->name = devm_kstrdup(parent, name, GFP_KERNEL);
>
> /* Provide description of available channels */
> indio_dev->channels = iio_dummy_channels;
> @@ -632,7 +628,7 @@ static struct iio_sw_device *iio_dummy_probe(const char
> *name)
>
> ret = iio_simple_dummy_events_register(indio_dev);
> if (ret < 0)
> - goto error_free_device;
> + return ERR_PTR(ret);
>
> ret = iio_simple_dummy_configure_buffer(indio_dev);
> if (ret < 0)
> @@ -649,11 +645,6 @@ static struct iio_sw_device *iio_dummy_probe(const char
> *name)
> iio_simple_dummy_unconfigure_buffer(indio_dev);
> error_unregister_events:
> iio_simple_dummy_events_unregister(indio_dev);
> -error_free_device:
> - iio_device_free(indio_dev);
> -error_ret:
> - kfree(swd);
> -error_kzalloc:
> return ERR_PTR(ret);
> }
>
> @@ -683,10 +674,6 @@ static int iio_dummy_remove(struct iio_sw_device *swd)
>
> iio_simple_dummy_events_unregister(indio_dev);
>
> - /* Free all structures */
> - kfree(indio_dev->name);
> - iio_device_free(indio_dev);
> -
> return 0;
> }
>
Re: [PATCH 4/7] dt-bindings: add documentation for sama7g5 ethernet interface
On Fri, Dec 04, 2020 at 02:34:18PM +0200, Claudiu Beznea wrote: > Add documentation for SAMA7G5 ethernet interface. > > Signed-off-by: Claudiu Beznea Reviewed-by: Andrew Lunn Andrew
Re: crypto: sun4i-ss: error with kmap
On Fri, Dec 04, 2020 at 09:58:21PM +0100, Thomas Gleixner wrote:
> On Fri, Dec 04 2020 at 20:27, Corentin Labbe wrote:
> > On Fri, Dec 04, 2020 at 04:08:27PM +0100, Thomas Gleixner wrote:
> >> On Fri, Dec 04 2020 at 14:26, Corentin Labbe wrote:
> >> > On Fri, Dec 04, 2020 at 12:34:05AM +0100, Thomas Gleixner wrote:
> >> >> The unmap comes from sg_miter_stop() and looking at the previous
> >> >> map/unmap cycles there are never nested maps.
> >> >>
> >> >> [ 996.943030] cryptset-316 0d..4 73943317us :
> >> >> __kmap_local_pfn_prot: kmap_local_pfn: 1 ffefd000
> >> >>
> >> >> is the first event which allocates a nested map.
> >> >>
> >> >> So something goes south either in sg_miter or in the crypto maze.
> >> >>
> >> >> Enabling CONFIG_DEBUG_KMAP_LOCAL and function tracing might give us
> >> >> more clue.
> >> >
> >> > Done, http://kernel.montjoie.ovh/130466.log
> >>
> >> Does not provide more information with the debug enabled. So can you
> >> please enable CONFIG_FUNCTION_TRACER and add 'ftrace=function' to the
> >> command line?
> >
> > Done, http://kernel.montjoie.ovh/130490.log
>
> Aaargh. That overwrites everything while printing out that
> warning.
>
> Can you please replace the debug patch with the one below and try again?
> That stops the trace right on the condition.
>
> Thanks,
>
> tglx
> ---
> diff --git a/mm/highmem.c b/mm/highmem.c
> index b49364a306b8..8f8862f79d23 100644
> --- a/mm/highmem.c
> +++ b/mm/highmem.c
> @@ -485,6 +485,7 @@ static inline bool kmap_high_unmap_local(unsigned long
> vaddr)
> {
> #ifdef ARCH_NEEDS_KMAP_HIGH_GET
> if (vaddr >= PKMAP_ADDR(0) && vaddr < PKMAP_ADDR(LAST_PKMAP)) {
> + trace_printk("kunmap_high: %lx\n", vaddr);
> kunmap_high(pte_page(pkmap_page_table[PKMAP_NR(vaddr)]));
> return true;
> }
> @@ -520,6 +521,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t
> prot)
> preempt_disable();
> idx = arch_kmap_local_map_idx(kmap_local_idx_push(), pfn);
> vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> + trace_printk("kmap_local_pfn: %d %lx\n", idx, (unsigned long) vaddr);
> BUG_ON(!pte_none(*(kmap_pte - idx)));
> pteval = pfn_pte(pfn, prot);
> set_pte_at(_mm, vaddr, kmap_pte - idx, pteval);
> @@ -545,8 +547,10 @@ void *__kmap_local_page_prot(struct page *page, pgprot_t
> prot)
>
> /* Try kmap_high_get() if architecture has it enabled */
> kmap = arch_kmap_local_high_get(page);
> - if (kmap)
> + if (kmap) {
> + trace_printk("kmap_local_high_get: %lx\n", (unsigned long)
> kmap);
> return kmap;
> + }
>
> return __kmap_local_pfn_prot(page_to_pfn(page), prot);
> }
> @@ -578,7 +582,11 @@ void kunmap_local_indexed(void *vaddr)
>
> preempt_disable();
> idx = arch_kmap_local_unmap_idx(kmap_local_idx(), addr);
> - WARN_ON_ONCE(addr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
> + trace_printk("kunmap_local: %i %lx\n", idx, (unsigned long) vaddr);
> + if (addr != __fix_to_virt(FIX_KMAP_BEGIN + idx)) {
> + tracing_off();
> + BUG();
> + }
>
> arch_kmap_local_pre_unmap(addr);
> pte_clear(_mm, addr, kmap_pte - idx);
>
Hello, the result could be found at http://kernel.montjoie.ovh/130739.log
Thanks
Re: [External] Re: [PATCH 5/9] mm: memcontrol: convert NR_FILE_THPS account to pages
On Sat, Dec 05, 2020 at 11:29:26PM +0800, Muchun Song wrote: > On Sat, Dec 5, 2020 at 10:09 PM Greg KH wrote: > > > > On Sat, Dec 05, 2020 at 09:02:20PM +0800, Muchun Song wrote: > > > Converrt NR_FILE_THPS account to pages. > > > > > > Signed-off-by: Muchun Song > > > --- > > > drivers/base/node.c | 3 +-- > > > fs/proc/meminfo.c | 2 +- > > > mm/filemap.c| 2 +- > > > mm/huge_memory.c| 3 ++- > > > mm/khugepaged.c | 2 +- > > > mm/memcontrol.c | 5 ++--- > > > 6 files changed, 8 insertions(+), 9 deletions(-) > > > > > > diff --git a/drivers/base/node.c b/drivers/base/node.c > > > index 05c369e93e16..f6a9521bbcf8 100644 > > > --- a/drivers/base/node.c > > > +++ b/drivers/base/node.c > > > @@ -466,8 +466,7 @@ static ssize_t node_read_meminfo(struct device *dev, > > > HPAGE_PMD_NR), > > >nid, K(node_page_state(pgdat, > > > NR_SHMEM_PMDMAPPED) * > > > HPAGE_PMD_NR), > > > - nid, K(node_page_state(pgdat, NR_FILE_THPS) * > > > - HPAGE_PMD_NR), > > > + nid, K(node_page_state(pgdat, NR_FILE_THPS)), > > > > Again, is this changing a user-visable value? > > > > Of course not. > > In the previous, the NR_FILE_THPS account is like below: > > __mod_lruvec_page_state(page, NR_FILE_THPS, 1); > > With this patch, it is: > > __mod_lruvec_page_state(page, NR_FILE_THPS, HPAGE_PMD_NR); > > So the result is not changed from the view of user space. So you "broke" it on the previous patch and "fixed" it on this one? Why not just do it all in one patch? Confused, greg k-h
Re: [External] Re: [PATCH 5/9] mm: memcontrol: convert NR_FILE_THPS account to pages
On Sat, Dec 5, 2020 at 11:32 PM Greg KH wrote: > > On Sat, Dec 05, 2020 at 11:29:26PM +0800, Muchun Song wrote: > > On Sat, Dec 5, 2020 at 10:09 PM Greg KH wrote: > > > > > > On Sat, Dec 05, 2020 at 09:02:20PM +0800, Muchun Song wrote: > > > > Converrt NR_FILE_THPS account to pages. > > > > > > > > Signed-off-by: Muchun Song > > > > --- > > > > drivers/base/node.c | 3 +-- > > > > fs/proc/meminfo.c | 2 +- > > > > mm/filemap.c| 2 +- > > > > mm/huge_memory.c| 3 ++- > > > > mm/khugepaged.c | 2 +- > > > > mm/memcontrol.c | 5 ++--- > > > > 6 files changed, 8 insertions(+), 9 deletions(-) > > > > > > > > diff --git a/drivers/base/node.c b/drivers/base/node.c > > > > index 05c369e93e16..f6a9521bbcf8 100644 > > > > --- a/drivers/base/node.c > > > > +++ b/drivers/base/node.c > > > > @@ -466,8 +466,7 @@ static ssize_t node_read_meminfo(struct device *dev, > > > > HPAGE_PMD_NR), > > > >nid, K(node_page_state(pgdat, > > > > NR_SHMEM_PMDMAPPED) * > > > > HPAGE_PMD_NR), > > > > - nid, K(node_page_state(pgdat, NR_FILE_THPS) * > > > > - HPAGE_PMD_NR), > > > > + nid, K(node_page_state(pgdat, NR_FILE_THPS)), > > > > > > Again, is this changing a user-visable value? > > > > > > > Of course not. > > > > In the previous, the NR_FILE_THPS account is like below: > > > > __mod_lruvec_page_state(page, NR_FILE_THPS, 1); > > > > With this patch, it is: > > > > __mod_lruvec_page_state(page, NR_FILE_THPS, HPAGE_PMD_NR); > > > > So the result is not changed from the view of user space. > > So you "broke" it on the previous patch and "fixed" it on this one? Why > not just do it all in one patch? Sorry for the confusion. I mean that the "previous" is without all of this patch series. So this series is aimed to convert the unit of all different THP vmstat counters from HPAGE_PMD_NR to pages. Thanks. > > Confused, > > greg k-h -- Yours, Muchun
Re: [PATCH 3/7] net: macb: unprepare clocks in case of failure
On Fri, Dec 04, 2020 at 02:34:17PM +0200, Claudiu Beznea wrote: > Unprepare clocks in case of any failure in fu540_c000_clk_init(). Hi Claudiu Nice patchset. Simple to understand. > > +err_disable_clocks: > + clk_disable_unprepare(*tx_clk); > + clk_disable_unprepare(*hclk); > + clk_disable_unprepare(*pclk); > + clk_disable_unprepare(*rx_clk); > + clk_disable_unprepare(*tsu_clk); This looks correct, but it would be more symmetrical to add a macb_clk_uninit() function for the four main clocks. I'm surprised it does not already exist. Andrew
[PATCH] proc: fix lookup in /proc/net subdirectories after setns(2)
commit 1fde6f21d90f8ba5da3cb9c54ca991ed72696c43
proc: fix /proc/net/* after setns(2)
only forced revalidation of regular files under /proc/net/
However, /proc/net/ is unusual in the sense of /proc/net/foo handlers
take netns pointer from parent directory which is old netns.
Steps to reproduce:
(void)open("/proc/net/sctp/snmp", O_RDONLY);
unshare(CLONE_NEWNET);
int fd = open("/proc/net/sctp/snmp", O_RDONLY);
read(fd, , 1);
Read will read wrong data from original netns.
Patch forces lookup on every directory under /proc/net .
Fixes: 1da4d377f943 ("proc: revalidate misc dentries")
Reported-by: "Rantala, Tommi T. (Nokia - FI/Espoo)"
Signed-off-by: Alexey Dobriyan
---
fs/proc/generic.c | 24 ++--
fs/proc/internal.h |7 +++
fs/proc/proc_net.c | 16
include/linux/proc_fs.h |8 +++-
4 files changed, 36 insertions(+), 19 deletions(-)
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -349,6 +349,16 @@ static const struct file_operations proc_dir_operations = {
.iterate_shared = proc_readdir,
};
+static int proc_net_d_revalidate(struct dentry *dentry, unsigned int flags)
+{
+ return 0;
+}
+
+const struct dentry_operations proc_net_dentry_ops = {
+ .d_revalidate = proc_net_d_revalidate,
+ .d_delete = always_delete_dentry,
+};
+
/*
* proc directories can do almost nothing..
*/
@@ -471,8 +481,8 @@ struct proc_dir_entry *proc_symlink(const char *name,
}
EXPORT_SYMBOL(proc_symlink);
-struct proc_dir_entry *proc_mkdir_data(const char *name, umode_t mode,
- struct proc_dir_entry *parent, void *data)
+struct proc_dir_entry *_proc_mkdir(const char *name, umode_t mode,
+ struct proc_dir_entry *parent, void *data, bool force_lookup)
{
struct proc_dir_entry *ent;
@@ -484,10 +494,20 @@ struct proc_dir_entry *proc_mkdir_data(const char *name,
umode_t mode,
ent->data = data;
ent->proc_dir_ops = _dir_operations;
ent->proc_iops = _dir_inode_operations;
+ if (force_lookup) {
+ pde_force_lookup(ent);
+ }
ent = proc_register(parent, ent);
}
return ent;
}
+EXPORT_SYMBOL_GPL(_proc_mkdir);
+
+struct proc_dir_entry *proc_mkdir_data(const char *name, umode_t mode,
+ struct proc_dir_entry *parent, void *data)
+{
+ return _proc_mkdir(name, mode, parent, data, false);
+}
EXPORT_SYMBOL_GPL(proc_mkdir_data);
struct proc_dir_entry *proc_mkdir_mode(const char *name, umode_t mode,
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -310,3 +310,10 @@ extern unsigned long task_statm(struct mm_struct *,
unsigned long *, unsigned long *,
unsigned long *, unsigned long *);
extern void task_mem(struct seq_file *, struct mm_struct *);
+
+extern const struct dentry_operations proc_net_dentry_ops;
+static inline void pde_force_lookup(struct proc_dir_entry *pde)
+{
+ /* /proc/net/ entries can be changed under us by setns(CLONE_NEWNET) */
+ pde->proc_dops = _net_dentry_ops;
+}
--- a/fs/proc/proc_net.c
+++ b/fs/proc/proc_net.c
@@ -39,22 +39,6 @@ static struct net *get_proc_net(const struct inode *inode)
return maybe_get_net(PDE_NET(PDE(inode)));
}
-static int proc_net_d_revalidate(struct dentry *dentry, unsigned int flags)
-{
- return 0;
-}
-
-static const struct dentry_operations proc_net_dentry_ops = {
- .d_revalidate = proc_net_d_revalidate,
- .d_delete = always_delete_dentry,
-};
-
-static void pde_force_lookup(struct proc_dir_entry *pde)
-{
- /* /proc/net/ entries can be changed under us by setns(CLONE_NEWNET) */
- pde->proc_dops = _net_dentry_ops;
-}
-
static int seq_open_net(struct inode *inode, struct file *file)
{
unsigned int state_size = PDE(inode)->state_size;
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -80,6 +80,7 @@ extern void proc_flush_pid(struct pid *);
extern struct proc_dir_entry *proc_symlink(const char *,
struct proc_dir_entry *, const char *);
+struct proc_dir_entry *_proc_mkdir(const char *, umode_t, struct
proc_dir_entry *, void *, bool);
extern struct proc_dir_entry *proc_mkdir(const char *, struct proc_dir_entry
*);
extern struct proc_dir_entry *proc_mkdir_data(const char *, umode_t,
struct proc_dir_entry *, void *);
@@ -162,6 +163,11 @@ static inline struct proc_dir_entry *proc_symlink(const
char *name,
static inline struct proc_dir_entry *proc_mkdir(const char *name,
struct proc_dir_entry *parent) {return NULL;}
static inline struct proc_dir_entry *proc_create_mount_point(const char *name)
{ return NULL; }
+static inline struct proc_dir_entry *_proc_mkdir(const char *name, umode_t
mode,
+ struct
Re: [PATCH 5/9] mm: memcontrol: convert NR_FILE_THPS account to pages
On Sat, Dec 05, 2020 at 09:02:20PM +0800, Muchun Song wrote: > Converrt NR_FILE_THPS account to pages. > > Signed-off-by: Muchun Song > --- > drivers/base/node.c | 3 +-- > fs/proc/meminfo.c | 2 +- > mm/filemap.c| 2 +- > mm/huge_memory.c| 3 ++- > mm/khugepaged.c | 2 +- > mm/memcontrol.c | 5 ++--- > 6 files changed, 8 insertions(+), 9 deletions(-) > > diff --git a/drivers/base/node.c b/drivers/base/node.c > index 05c369e93e16..f6a9521bbcf8 100644 > --- a/drivers/base/node.c > +++ b/drivers/base/node.c > @@ -466,8 +466,7 @@ static ssize_t node_read_meminfo(struct device *dev, > HPAGE_PMD_NR), >nid, K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED) * > HPAGE_PMD_NR), > - nid, K(node_page_state(pgdat, NR_FILE_THPS) * > - HPAGE_PMD_NR), > + nid, K(node_page_state(pgdat, NR_FILE_THPS)), Again, is this changing a user-visable value?
Re: [PATCH v3 3/3] iio:Documentation: Add documentation for hinge sensor channels
On Thu, 3 Dec 2020 11:53:52 +0800 Ye Xiang wrote: > Add channel description for hinge sensor, including channel label > attribute and raw data description. > > Signed-off-by: Ye Xiang > --- > Documentation/ABI/testing/sysfs-bus-iio | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio > b/Documentation/ABI/testing/sysfs-bus-iio > index df42bed09f25..82303b1bdff0 100644 > --- a/Documentation/ABI/testing/sysfs-bus-iio > +++ b/Documentation/ABI/testing/sysfs-bus-iio > @@ -1802,3 +1802,20 @@ Contact: linux-...@vger.kernel.org > Description: > Unscaled light intensity according to CIE 1931/DIN 5033 color > space. > Units after application of scale are nano nanowatts per square > meter. > + > +What:/sys/bus/iio/devices/iio:deviceX/in_anglY_raw > +KernelVersion: 5.12 > +Contact: linux-...@vger.kernel.org > +Description: > + Angle of rotation for channel Y. Units after application of > scale > + and offset are radians. This entry is already mostly in the doc around line 200, just without the index. Please just add the What: line to that block to reduce repetition. If you want to add... "Where present, Y indexes the channel." or something like that feel free. > + > +What:/sys/bus/iio/devices/iio:deviceX/in_anglY_label > +KernelVersion: 5.12 > +Contact: linux-...@vger.kernel.org > +Description: > + Optional symbolic label for channel Y. > + For Intel hid hinge sensor, the label values are: > + hinge, keyboard, screen. It means the three channels > + each correspond respectively to hinge angle, keyboard angle, > + and screen angle. Makes sense to keep this block separate given the additional info provided. Alternative would be to add it to the one with in_voltageY_label which would be odd given what follows! Thanks, Jonathan
Re: [PATCH 5/7] regmap: sdw: use no_pm routines for SoundWire 1.2 MBQ
On Sat, Dec 05, 2020 at 08:52:50AM -0600, Pierre-Louis Bossart wrote:
>
> > > MODULE_DESCRIPTION("Regmap SoundWire MBQ Module");
> > > -MODULE_LICENSE("GPL v2");
> > > +MODULE_LICENSE("GPL");
> >
> > Why do you want to change this ?
>
> We only use MODULE_LICENSE("GPL") for new contributions since 'GPL v2' does
> not bring any information on the license, is equivalent to 'GPL' and only
> exists for 'historical reasons', see
>
> https://www.kernel.org/doc/html/latest/process/license-rules.html
>
>
> “GPL” Module is licensed under GPL version 2. This does not express any
> distinction between GPL-2.0-only or GPL-2.0-or-later. The exact license
> information can only be determined via the license information in the
> corresponding source files.
>
> “GPL v2” Same as “GPL”. It exists for historic reasons.
>
> We should have used 'GPL' in the initial regmap MBQ patch but didn't for
> some reason, this change just realigns with what we intended.
>
> That said, this is unrelated to this no_pm patch so could be in a separate
> one if you preferred it that way.
It should be separate as it does not have anything to do with the real
reason this patch was submitted.
thanks,
greg k-h
Re: [External] Re: [PATCH 5/9] mm: memcontrol: convert NR_FILE_THPS account to pages
On Sat, Dec 05, 2020 at 11:39:24PM +0800, Muchun Song wrote: > On Sat, Dec 5, 2020 at 11:32 PM Greg KH wrote: > > > > On Sat, Dec 05, 2020 at 11:29:26PM +0800, Muchun Song wrote: > > > On Sat, Dec 5, 2020 at 10:09 PM Greg KH > > > wrote: > > > > > > > > On Sat, Dec 05, 2020 at 09:02:20PM +0800, Muchun Song wrote: > > > > > Converrt NR_FILE_THPS account to pages. > > > > > > > > > > Signed-off-by: Muchun Song > > > > > --- > > > > > drivers/base/node.c | 3 +-- > > > > > fs/proc/meminfo.c | 2 +- > > > > > mm/filemap.c| 2 +- > > > > > mm/huge_memory.c| 3 ++- > > > > > mm/khugepaged.c | 2 +- > > > > > mm/memcontrol.c | 5 ++--- > > > > > 6 files changed, 8 insertions(+), 9 deletions(-) > > > > > > > > > > diff --git a/drivers/base/node.c b/drivers/base/node.c > > > > > index 05c369e93e16..f6a9521bbcf8 100644 > > > > > --- a/drivers/base/node.c > > > > > +++ b/drivers/base/node.c > > > > > @@ -466,8 +466,7 @@ static ssize_t node_read_meminfo(struct device > > > > > *dev, > > > > > HPAGE_PMD_NR), > > > > >nid, K(node_page_state(pgdat, > > > > > NR_SHMEM_PMDMAPPED) * > > > > > HPAGE_PMD_NR), > > > > > - nid, K(node_page_state(pgdat, > > > > > NR_FILE_THPS) * > > > > > - HPAGE_PMD_NR), > > > > > + nid, K(node_page_state(pgdat, > > > > > NR_FILE_THPS)), > > > > > > > > Again, is this changing a user-visable value? > > > > > > > > > > Of course not. > > > > > > In the previous, the NR_FILE_THPS account is like below: > > > > > > __mod_lruvec_page_state(page, NR_FILE_THPS, 1); > > > > > > With this patch, it is: > > > > > > __mod_lruvec_page_state(page, NR_FILE_THPS, HPAGE_PMD_NR); > > > > > > So the result is not changed from the view of user space. > > > > So you "broke" it on the previous patch and "fixed" it on this one? Why > > not just do it all in one patch? > > Sorry for the confusion. I mean that the "previous" is without all of this > patch > series. So this series is aimed to convert the unit of all different THP > vmstat > counters from HPAGE_PMD_NR to pages. Thanks. I'm sorry, I still do not understand. It looks to me that you are changing the number printed to userspace here. Where is the corrisponding change that changed the units for this function? Is it in this patch? If so, sorry, I did not see that at all... thanks, greg k-h
[PATCH v5 04/19] dt-bindings: usb: Add "ulpi/serial/hsic" PHY types
Aside from the UTMI+ there are also ULPI, Serial and HSIC PHY types that can be specified in the phy_type HCD property. Add them to the enumeration of the acceptable values. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/PHY types can be/PHY types that can be" - Drop quotes from around the string constants. Changelog v4: - Move the new PHY types definitions into the usb.yaml schema where the phy_type property is now defined. --- Documentation/devicetree/bindings/usb/usb.yaml | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/usb.yaml b/Documentation/devicetree/bindings/usb/usb.yaml index 991c02725e2b..6dc4821e63c3 100644 --- a/Documentation/devicetree/bindings/usb/usb.yaml +++ b/Documentation/devicetree/bindings/usb/usb.yaml @@ -27,11 +27,13 @@ properties: phy_type: description: Tells USB controllers that we want to configure the core to support a - UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is selected. In case - this isn't passed via DT, USB controllers should default to HW - capability. + UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is selected, UTMI+ low + pin interface if ULPI is specified, Serial core/PHY interconnect if + serial is specified and High-Speed Inter-Chip feature if HSIC is + selected. In case this isn't passed via DT, USB controllers should + default to HW capability. $ref: /schemas/types.yaml#/definitions/string -enum: [utmi, utmi_wide] +enum: [utmi, utmi_wide, ulpi, serial, hsic] maximum-speed: description: -- 2.29.2
Re: [Bug 202453] TRACE irq/18-i801_smb Tainted when enabled threadirqs in kernel commandline.
On Sat, Dec 05, 2020 at 05:19:18PM +0100, Thomas Gleixner wrote:
> On Fri, Dec 04 2020 at 21:19, Oleksandr Natalenko wrote:
> > On Thu, Dec 03, 2020 at 07:04:00PM +,
> > bugzilla-dae...@bugzilla.kernel.org wrote:
> >>2) Have a wrapper around handle_generic_irq() which ensures that
> >> interrupts are disabled before invoking it.
>
> > The question is whether it's guaranteed under all circumstances
> > including forced irq threading. The i801 driver has assumptions about
> > this, so I wouldn't be surprised if there are more.
>
> Assuming that a final answer might take some time, the below which
> implements #2 will make it at least work for now.
>
> Thanks,
>
> tglx
> ---
> Subject: genirq, i2c: Provide and use generic_dispatch_irq()
> From: Thomas Gleixner
> Date: Thu, 03 Dec 2020 19:12:24 +0100
>
> Carlos reported that on his system booting with 'threadirqs' on the command
> line result in the following warning:
>
> irq 31 handler irq_default_primary_handler+0x0/0x10 enabled interrupts
> WARNING: CPU: 2 PID: 989 at kernel/irq/handle.c:153
> __handle_irq_event_percpu+0x19f/0x1b0
>
> The reason is in the i2c stack:
>
> i801_isr()
> i801_host_notify_isr()
> i2c_handle_smbus_host_notify()
> generic_handle_irq()
>
> and that explodes with forced interrupt threading because it's called with
> interrupts enabled.
>
> It would be possible to set IRQF_NO_THREAD on the i801 interrupt to exclude
> it from force threading, but that would break on RT and require a larger
> update.
>
> It's also unclear whether there are other drivers which can reach that code
> path via i2c_slave_host_notify_cb(). As there are enough i2c drivers which
> use threaded interrupt handlers by default it seems not completely
> impossible that this can happen even without force threaded interrupts.
>
> For a quick fix provide a wrapper around generic_handle_irq() which has a
> local_irq_save/restore() around the invocation and use it in the i2c code.
>
> Reported-by: Carlos Jimenez
> Signed-off-by: Thomas Gleixner
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=202453
> ---
> drivers/i2c/i2c-core-base.c |2 +-
> include/linux/irqdesc.h |1 +
> kernel/irq/irqdesc.c| 20
> 3 files changed, 22 insertions(+), 1 deletion(-)
>
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -1385,7 +1385,7 @@ int i2c_handle_smbus_host_notify(struct
> if (irq <= 0)
> return -ENXIO;
>
> - generic_handle_irq(irq);
> + generic_dispatch_irq(irq);
>
> return 0;
> }
> --- a/include/linux/irqdesc.h
> +++ b/include/linux/irqdesc.h
> @@ -153,6 +153,7 @@ static inline void generic_handle_irq_de
> }
>
> int generic_handle_irq(unsigned int irq);
> +int generic_dispatch_irq(unsigned int irq);
>
> #ifdef CONFIG_HANDLE_DOMAIN_IRQ
> /*
> --- a/kernel/irq/irqdesc.c
> +++ b/kernel/irq/irqdesc.c
> @@ -652,6 +652,26 @@ int generic_handle_irq(unsigned int irq)
> }
> EXPORT_SYMBOL_GPL(generic_handle_irq);
>
> +/**
> + * generic_dispatch_irq - Dispatch an interrupt from an interrupt handler
> + * @irq: The irq number to handle
> + *
> + * A wrapper around generic_handle_irq() which ensures that interrupts are
> + * disabled when the primary handler of the dispatched irq is invoked.
> + * This is useful for interrupt handlers with dispatching to be safe for
> + * the forced threaded case.
> + */
> +int generic_dispatch_irq(unsigned int irq)
> +{
> + unsigned long flags;
> + int ret;
> +
> + local_irq_save();
> + ret = generic_handle_irq(irq);
> + local_irq_restore();
FWIW, for me explodes build on v5.10-rc6. I had to change it to
local_irq_save/restore(flags) (without taking an address via &).
> + return ret;
> +}
> +
> #ifdef CONFIG_HANDLE_DOMAIN_IRQ
> /**
> * __handle_domain_irq - Invoke the handler for a HW irq belonging to a
> domain
--
Oleksandr Natalenko (post-factum)
Re: [PATCH 2/7] net: batman-adv: remove unneeded MODULE_VERSION() usage
On Sat, 05 Dec 2020 08:06:40 +0100 Sven Eckelmann wrote: > On Wednesday, 2 December 2020 13:49:54 CET Enrico Weigelt, metux IT consult > wrote: > > Remove MODULE_VERSION(), as it isn't needed at all: the only version > > making sense is the kernel version. > > Is there some explanation besides an opinion? Some kind goal which you want > to > achieve with it maybe? > > At least for us it was an easy way to query the release cycle information via > batctl. Which made it easier for us to roughly figure out what an reporter/ > inquirer was using - independent of whether he is using the in-kernel version > or a backported version. > > Loosing this source of information and breaking parts of batctl and other > tools (respondd, ...) is not the end of the world. But I would at least know > why this is now necessary. No, no, if it breaks your user space we can't do it, let's leave batman alone, then. I think this is mostly a clean up. In-tree the kernel version is usually far more dependable because backports don't include version bumps. Indeed it would be great if the clear motivation was spelled out in the cover letter and/or patches.
Re: [PATCH 1/7] net: 8021q: remove unneeded MODULE_VERSION() usage
On Sat, Dec 05, 2020 at 01:20:18PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 02, 2020 at 01:49:53PM +0100, Enrico Weigelt, metux IT consult
> wrote:
> > Remove MODULE_VERSION(), as it isn't needed at all: the only version
> > making sense is the kernel version.
> >
> > Signed-off-by: Enrico Weigelt, metux IT consult
> > ---
> > net/8021q/vlan.c | 8 +---
> > 1 file changed, 1 insertion(+), 7 deletions(-)
> >
> > diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
> > index f292e0267bb9..683e9e825b9e 100644
> > --- a/net/8021q/vlan.c
> > +++ b/net/8021q/vlan.c
> > @@ -36,15 +36,10 @@
> > #include "vlan.h"
> > #include "vlanproc.h"
> >
> > -#define DRV_VERSION "1.8"
> > -
> > /* Global VLAN variables */
> >
> > unsigned int vlan_net_id __read_mostly;
> >
> > -const char vlan_fullname[] = "802.1Q VLAN Support";
> > -const char vlan_version[] = DRV_VERSION;
> > -
> > /* End of global variables definitions. */
> >
> > static int vlan_group_prealloc_vid(struct vlan_group *vg,
> > @@ -687,7 +682,7 @@ static int __init vlan_proto_init(void)
> > {
> > int err;
> >
> > - pr_info("%s v%s\n", vlan_fullname, vlan_version);
> > + pr_info("802.1Q VLAN Support\n");
>
> How do we feel about deleting this not really informative message
> altogether in a future patch?
It too should be removed. If drivers are working properly, they are
quiet.
[PATCH 4/8] tty: serial: jsm: Fixed file by added more spacing in line 613
Fixed a coding style issue Signed-off-by: Clement Smith --- drivers/tty/serial/jsm/jsm_tty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c index 2bc5f32e59f4..45e212be64c4 100644 --- a/drivers/tty/serial/jsm/jsm_tty.c +++ b/drivers/tty/serial/jsm/jsm_tty.c @@ -610,7 +610,7 @@ void jsm_input(struct jsm_channel *ch) if (*(ch->ch_equeue + tail + i) & UART_LSR_BI) tty_insert_flip_char(port, *(ch->ch_rqueue + tail + i), TTY_BREAK); else if (*(ch->ch_equeue + tail + i) & UART_LSR_PE) - tty_insert_flip_char(port, *(ch->ch_rqueue +tail +i), TTY_PARITY); + tty_insert_flip_char(port, *(ch->ch_rqueue + tail + i), TTY_PARITY); else if (*(ch->ch_equeue +tail +i) & UART_LSR_FE) tty_insert_flip_char(port, *(ch->ch_rqueue +tail +i), TTY_FRAME); else -- 2.27.0
[PATCH v2] Revert "ACPI / resources: Use AE_CTRL_TERMINATE to terminate resources walks"
This reverts commit 8a66790b7850a6669129af078768a1d42076a0ef.
Switching this function to AE_CTRL_TERMINATE broke the documented
behaviour of acpi_dev_get_resources() - AE_CTRL_TERMINATE does not, in
fact, terminate the resource walk because acpi_walk_resource_buffer()
ignores it (specifically converting it to AE_OK), referring to that
value as "an OK termination by the user function". This means that
acpi_dev_get_resources() does not abort processing when the preproc
function returns a negative value.
Signed-off-by: Daniel Scally
---
drivers/acpi/resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index ad04824ca3ba..f2f5f1dc7c61 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -541,7 +541,7 @@ static acpi_status acpi_dev_process_resource(struct
acpi_resource *ares,
ret = c->preproc(ares, c->preproc_data);
if (ret < 0) {
c->error = ret;
- return AE_CTRL_TERMINATE;
+ return AE_ABORT_METHOD;
} else if (ret > 0) {
return AE_OK;
}
--
2.25.1
Re: [PATCH] mm/memblock:use a more appropriate order calculation when free memblock pages
On Fri, 4 Dec 2020 at 18:44, Jon Hunter wrote:
>
>
> On 04/12/2020 16:07, Marek Szyprowski wrote:
> > Hi All,
> >
> > On 04.12.2020 14:42, Qian Cai wrote:
> >> On Thu, 2020-12-03 at 23:23 +0800, carver4...@163.com wrote:
> >>> From: Hailong Liu
> >>>
> >>> When system in the booting stage, pages span from [start, end] of a
> >>> memblock
> >>> are freed to buddy in a order as large as possible (less than MAX_ORDER)
> >>> at
> >>> first, then decrease gradually to a proper order(less than end) in a loop.
> >>>
> >>> However, *min(MAX_ORDER - 1UL, __ffs(start))* can not get the largest
> >>> order
> >>> in some cases.
> >>> Instead, *__ffs(end - start)* may be more appropriate and meaningful.
> >>>
> >>> Signed-off-by: Hailong Liu
> >> Reverting this commit on the top of today's linux-next fixed boot crashes
> >> on
> >> multiple NUMA systems.
> >
> > I confirm. Reverting commit 4df001639c84 ("mm/memblock: use a more
> > appropriate order calculation when free memblock pages") on top of linux
> > next-20201204 fixed booting of my ARM32bit test systems.
>
>
> FWIW, I also confirm that this is causing several 32-bit Tegra platforms
> to crash on boot and reverting this fixes the problem.
I had the same experience on an arm64 system.
Cheers,
Anders
Re: [PATCH v2 1/5] arm64: dts: meson: g12b: odroid-n2: fix PHY deassert timing requirements
On Tue, Dec 1, 2020 at 2:21 PM Stefan Agner wrote:
>
> According to the datasheet (Rev. 1.9) the RTL8211F requires at least
> 72ms "for internal circuits settling time" before accessing the PHY
> egisters. This fixes an issue where the Ethernet link doesn't come up
> when using ip link set down/up:
> [ 29.360965] meson8b-dwmac ff3f.ethernet eth0: Link is Down
> [ 34.569012] meson8b-dwmac ff3f.ethernet eth0: PHY [0.0:00] driver
> [RTL8211F Gigabit Ethernet] (irq=31)
> [ 34.676732] meson8b-dwmac ff3f.ethernet: Failed to reset the dma
> [ 34.678874] meson8b-dwmac ff3f.ethernet eth0: stmmac_hw_setup: DMA
> engine initialization failed
> [ 34.687850] meson8b-dwmac ff3f.ethernet eth0: stmmac_open: Hw setup
> failed
>
> Fixes: 658e4129bb81 ("arm64: dts: meson: g12b: odroid-n2: add the Ethernet
> PHY reset line")
> Signed-off-by: Stefan Agner
with the "registers" typo above fixed:
Reviewed-by: Martin Blumenstingl
[PATCH v5 09/19] dt-bindings: usb: renesas-xhci: Refer to the usb-xhci.yaml file
With minor peculiarities (like uploading some vendor-specific firmware) these are just Generic xHCI controllers fully compatible with its properties. Make sure the Renesas USB xHCI DT nodes are also validated against the Generic xHCI DT schema. Signed-off-by: Serge Semin Reviewed-by: Rob Herring Reviewed-by: Yoshihiro Shimoda --- Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml index 0f078bd0a3e5..7e5ed196b52c 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml @@ -11,7 +11,7 @@ maintainers: - Yoshihiro Shimoda allOf: - - $ref: "usb-hcd.yaml" + - $ref: "usb-xhci.yaml" properties: compatible: @@ -69,7 +69,7 @@ required: - power-domains - resets -additionalProperties: false +unevaluatedProperties: false examples: - | -- 2.29.2
Re: [PATCH 1/8] tty: serial: jsm: Fixed file by added more spacing in line 610
On Sat, Dec 05, 2020 at 07:50:08PM +0530, Clement Smith wrote: > Fixed a coding style issue > > Signed-off-by: Clement Smith > --- > drivers/tty/serial/jsm/jsm_tty.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) The subject lines in this series is really funny. Please don't do this. If you want to get practice in making coding style cleanups, do it in drivers/staging/ which is why the code is there. Don't "practice" in other parts of the kernel as it just gets in the way of other development and review efforts. good luck! greg k-h
Re: [PATCH 4/8] Documentation: HID: intel-ish-hid editing & corrections
On Thu, 3 Dec 2020 22:20:18 -0800 Randy Dunlap wrote: > Do basic editing & correction to intel-ish-hid.rst: > - fix grammar, verb tense, punctutation, and word phrasing > - fix spellos > - hyphenate multi-word adjectives > - collapse 2 spaces to one space in the middle of sentences > - use "I2C" instead of lower-case letters (as Linux I2C does) > - change space indentation to tab > - use HID instead of hid consistently > - use a list so that some line items do not run together > - use "a UUID" instead of "an UUID" > > > Signed-off-by: Randy Dunlap > Cc: Jiri Kosina > Cc: Jonathan Cameron > Cc: Srinivas Pandruvada > Cc: linux-in...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > --- > Documentation/hid/intel-ish-hid.rst | 74 +- > 1 file changed, 38 insertions(+), 36 deletions(-) > > --- linux-next-20201201.orig/Documentation/hid/intel-ish-hid.rst > +++ linux-next-20201201/Documentation/hid/intel-ish-hid.rst > @@ -4,19 +4,19 @@ Intel Integrated Sensor Hub (ISH) > > A sensor hub enables the ability to offload sensor polling and algorithm > processing to a dedicated low power co-processor. This allows the core > -processor to go into low power modes more often, resulting in the increased > +processor to go into low power modes more often, resulting in increased > battery life. > > -There are many vendors providing external sensor hubs confirming to HID > -Sensor usage tables, and used in several tablets, 2 in 1 convertible laptops > +There are many vendors providing external sensor hubs conforming to HID > +Sensor usage tables, and used in several tablets, 2-in-1 convertible laptops Does that sentence actually make sense? Perhaps.. There are many vendors providing external sensor hubs conforming to HID Sensor usage tables. These may be found in tablets, 2-in-1 convertible laptops ... > and embedded products. Linux had this support since Linux 3.9. > > Intel® introduced integrated sensor hubs as a part of the SoC starting from > Cherry Trail and now supported on multiple generations of CPU packages. There > are many commercial devices already shipped with Integrated Sensor Hubs > (ISH). > -These ISH also comply to HID sensor specification, but the difference is the > +These ISH also comply to HID sensor specification, but the difference is the > transport protocol used for communication. The current external sensor hubs > -mainly use HID over i2C or USB. But ISH doesn't use either i2c or USB. > +mainly use HID over I2C or USB. But ISH doesn't use either I2C or USB. > > 1. Overview > === > @@ -35,7 +35,7 @@ for a very high speed communication:: > - -- > PCIPCI > - -- > -|Host controller|--> |ISH processor | > + |Host controller| --> |ISH processor | > - -- >USB Link > - -- > @@ -50,13 +50,13 @@ applications implemented in the firmware > The ISH allows multiple sensor management applications executing in the > firmware. Like USB endpoints the messaging can be to/from a client. As part > of > enumeration process, these clients are identified. These clients can be > simple > -HID sensor applications, sensor calibration application or senor firmware > +HID sensor applications, sensor calibration application or sensor firmware Plural vs singular messy in here. Probably just make all the applications plural. > update application. > > The implementation model is similar, like USB bus, ISH transport is also > implemented as a bus. Each client application executing in the ISH processor > is registered as a device on this bus. The driver, which binds each device > -(ISH HID driver) identifies the device type and registers with the hid core. > +(ISH HID driver) identifies the device type and registers with the HID core. > > 2. ISH Implementation: Block Diagram > > @@ -104,7 +104,7 @@ is registered as a device on this bus. T > > The ISH is exposed as "Non-VGA unclassified PCI device" to the host. The PCI > product and vendor IDs are changed from different generations of processors. > So > -the source code which enumerate drivers needs to update from generation to > +the source code which enumerates drivers needs to update from generation to > generation. > > 3.2 Inter Processor Communication (IPC) driver > @@ -112,41 +112,42 @@ generation. > > Location: drivers/hid/intel-ish-hid/ipc > > -The IPC message used memory mapped I/O. The registers are defined in > +The IPC message uses memory mapped I/O. The registers are defined in > hw-ish-regs.h. > > 3.2.1 IPC/FW message types > ^^ > >
[PATCH v5 05/19] dt-bindings: usb: usb-hcd: Add "tpl-support" property
The host controller device might be designed to work for the particular products or applications. In that case its DT node is supposed to be equipped with the tpl-support property. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/it'/its" - Discard '|' from the property description, since we don't need to preserve the text formatting. --- Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml index 52cc84c400c0..9881ac10380d 100644 --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml @@ -17,6 +17,12 @@ properties: description: Phandle of a companion device $ref: /schemas/types.yaml#/definitions/phandle + tpl-support: +description: + Indicates if the Targeted Peripheral List is supported for given + targeted hosts (non-PC hosts). +type: boolean + additionalProperties: true examples: -- 2.29.2
[PATCH v5 11/19] dt-bindings: usb: dwc3: Add interrupt-names property support
The controller driver supports two types of DWC USB3 devices: with a common interrupt lane and with individual interrupts for each mode. Add support for both these cases to the DWC USB3 DT schema. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/both of these cases support/support for both these cases" - Drop quotes from around the string constants. Changelog v4: - Discard the block scalar style modifier "|" from the interrupts property description. --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index f645fd918421..94ede43586f7 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -34,8 +34,19 @@ properties: const: snps,dwc3 interrupts: +description: + It's either a single common DWC3 interrupt (dwc_usb3) or individual + interrupts for the host, gadget and DRD modes. +minItems: 1 +maxItems: 3 + + interrupt-names: minItems: 1 maxItems: 3 +oneOf: + - const: dwc_usb3 + - items: + enum: [host, peripheral, otg] clocks: description: -- 2.29.2
Re: [PATCH] fix namespaced fscaps when !CONFIG_SECURITY
Oh, I see you'd changed it inline :) Thanks
On Sat, Dec 05, 2020 at 11:40:00AM -0600, Serge E. Hallyn wrote:
> How odd - where did that come from?
>
> James, I force-pushed that with corrected bugzilla link to
> 2020-11-29/fix-nscaps. Sorry about that.
>
> On Fri, Dec 04, 2020 at 07:58:14AM -0800, Andrew G. Morgan wrote:
> > The correct bug reference for this patch is:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=209689
> >
> > Reviewed-by: Andrew G. Morgan
> >
> > On Mon, Nov 30, 2020 at 6:58 PM James Morris wrote:
> > >
> > > On Sun, 29 Nov 2020, Serge E. Hallyn wrote:
> > >
> > > > Hi James,
> > > >
> > > > would you mind adding this to the security tree? (You can cherrypick
> > > > from
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux.git/commit/?h=2020-11-29/fix-nscaps
> > > > )
> > >
> > > Sure.
> > >
> > > >
> > > > thanks,
> > > > -serge
> > > >
> > > > On Tue, Nov 17, 2020 at 08:09:59AM -0800, Andrew G. Morgan wrote:
> > > > > Signed-off-by: Andrew G. Morgan
> > > > >
> > > > >
> > > > > On Tue, Nov 17, 2020 at 7:09 AM Serge E. Hallyn
> > > > > wrote:
> > > > >
> > > > > > Namespaced file capabilities were introduced in 8db6c34f1dbc .
> > > > > > When userspace reads an xattr for a namespaced capability, a
> > > > > > virtualized representation of it is returned if the caller is
> > > > > > in a user namespace owned by the capability's owning rootid.
> > > > > > The function which performs this virtualization was not hooked
> > > > > > up if CONFIG_SECURITY=n. Therefore in that case the original
> > > > > > xattr was shown instead of the virtualized one.
> > > > > >
> > > > > > To test this using libcap-bin (*1),
> > > > > >
> > > > > > $ v=$(mktemp)
> > > > > > $ unshare -Ur setcap cap_sys_admin-eip $v
> > > > > > $ unshare -Ur setcap -v cap_sys_admin-eip $v
> > > > > > /tmp/tmp.lSiIFRvt8Y: OK
> > > > > >
> > > > > > "setcap -v" verifies the values instead of setting them, and
> > > > > > will check whether the rootid value is set. Therefore, with
> > > > > > this bug un-fixed, and with CONFIG_SECURITY=n, setcap -v will
> > > > > > fail:
> > > > > >
> > > > > > $ v=$(mktemp)
> > > > > > $ unshare -Ur setcap cap_sys_admin=eip $v
> > > > > > $ unshare -Ur setcap -v cap_sys_admin=eip $v
> > > > > > nsowner[got=1000, want=0],/tmp/tmp.HHDiOOl9fY differs in []
> > > > > >
> > > > > > Fix this bug by calling cap_inode_getsecurity() in
> > > > > > security_inode_getsecurity() instead of returning
> > > > > > -EOPNOTSUPP, when CONFIG_SECURITY=n.
> > > > > >
> > > > > > *1 - note, if libcap is too old for getcap to have the '-n'
> > > > > > option, then use verify-caps instead.
> > > > > >
> > > > > > Signed-off-by: Serge Hallyn
> > > > > > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1593431
> > > > > > Cc: Hervé Guillemet
> > > > > > Cc: Andrew G. Morgan
> > > > > > Cc: Casey Schaufler
> > > > > > ---
> > > > > > include/linux/security.h | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/include/linux/security.h b/include/linux/security.h
> > > > > > index bc2725491560..39642626a707 100644
> > > > > > --- a/include/linux/security.h
> > > > > > +++ b/include/linux/security.h
> > > > > > @@ -869,7 +869,7 @@ static inline int security_inode_killpriv(struct
> > > > > > dentry *dentry)
> > > > > >
> > > > > > static inline int security_inode_getsecurity(struct inode *inode,
> > > > > > const
> > > > > > char *name, void **buffer, bool alloc)
> > > > > > {
> > > > > > - return -EOPNOTSUPP;
> > > > > > + return cap_inode_getsecurity(inode, name, buffer, alloc);
> > > > > > }
> > > > > >
> > > > > > static inline int security_inode_setsecurity(struct inode *inode,
> > > > > > const
> > > > > > char *name, const void *value, size_t size, int flags)
> > > > > > --
> > > > > > 2.25.1
> > > > > >
> > > > > >
> > > >
> > >
> > > --
> > > James Morris
> > >
Re: [PATCH] interconnect: qcom: fix rpmh link failures
On Sat, Dec 5, 2020 at 12:27 AM Bjorn Andersson wrote: > On Fri 04 Dec 10:50 CST 2020, Arnd Bergmann wrote: > > Your patch looks correct to me, so: > Reviewed-by: Bjorn Andersson > > > But we're going to have to sprinkle a handful of these throughout the > tree and we're not a lot of people who "understand" what it does (and at > least I keep getting them wrong...) Right, I already ran into another one. > Perhaps it would be more reasonable to maintain this long term if we > drop the possibility of compile testing these drivers independently of > rpmh and command db? (I.e. drop the function stubs and rely on > RPMH/COMMAND_DB to enable building under COMPILE_TEST)? Agreed, I think that would be best. As long as RPMH and COMMAND_DB can individually be enabled for CONFIG_COMPILE_TEST, all the drivers will get enabled in an allmodconfig build, and we can just list the dependencies. I don't really like the headers too much that have an #ifdef CONFIG_SUBSYSTEM with an alternative set of inline functions, unless there is a reasonable expectations that drivers work fine if that subsystem is disabled. E.g. having the option to disable IPv6 makes sense despite the complexity that adds, but compile-testing a driver without a required subsystem that can also be enabled for compile-testing hurts more than it helps. > And just to make it clear, I think we should merge your patch to fix > v5.11; then consider to simplify this past that. Yes, sounds good. Arnd
[PATCH v5 12/19] dt-bindings: usb: dwc3: Add synopsys,dwc3 compatible string
The DWC USB3 driver and some DTS files like Exynos 5250, Keystone k2e, etc expects the DWC USB3 DT node to have the compatible string with the "synopsys" vendor prefix. Let's add the corresponding compatible string to the controller DT schema, but mark it as deprecated seeing the Synopsys, Inc. is presented with just "snps" vendor prefix. Signed-off-by: Serge Semin --- Changelog v2: - Drop quotes from around the compat string constant. Changelog v4: - Get the patch back, since we can't discard the deprecated prefix from the driver. --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 94ede43586f7..b1890558affe 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -31,7 +31,10 @@ allOf: properties: compatible: contains: - const: snps,dwc3 + oneOf: +- const: snps,dwc3 +- const: synopsys,dwc3 + deprecated: true interrupts: description: -- 2.29.2
[PATCH v5 13/19] dt-bindings: usb: dwc3: Add Tx De-emphasis constraints
In accordance with the driver comments the PIPE3 de-emphasis can be tuned to be either -6dB, -2.5dB or disabled. Let's add the de-emphasis property constraints so the DT schema would make sure the controller DT node is equipped with correct value. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Changelog v2: - Grammar fix: "s/tunned/tuned" - Grammar fix: remove redundant "or" conjunction. --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index b1890558affe..e39ad899c92e 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -156,6 +156,10 @@ properties: The value driven to the PHY is controlled by the LTSSM during USB3 Compliance mode. $ref: /schemas/types.yaml#/definitions/uint8 +enum: + - 0 # -6dB de-emphasis + - 1 # -3.5dB de-emphasis + - 2 # No de-emphasis snps,dis_u3_susphy_quirk: description: When set core will disable USB3 suspend phy -- 2.29.2
[PATCH v4 2/3] usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one
Originally the procedure of the ULPI transaction finish detection has been
developed as a simple busy-loop with just decrementing counter and no
delays. It's wrong since on different systems the loop will take a
different time to complete. So if the system bus and CPU are fast enough
to overtake the ULPI bus and the companion PHY reaction, then we'll get to
take a false timeout error. Fix this by converting the busy-loop procedure
to take the standard bus speed, address value and the registers access
mode into account for the busy-loop delay calculation.
Here is the way the fix works. It's known that the ULPI bus is clocked
with 60MHz signal. In accordance with [1] the ULPI bus protocol is created
so to spend 5 and 6 clock periods for immediate register write and read
operations respectively, and 6 and 7 clock periods - for the extended
register writes and reads. Based on that we can easily pre-calculate the
time which will be needed for the controller to perform a requested IO
operation. Note we'll still preserve the attempts counter in case if the
DWC USB3 controller has got some internals delays.
[1] UTMI+ Low Pin Interface (ULPI) Specification, Revision 1.1,
October 20, 2004, pp. 30 - 36.
Fixes: 88bc9d194ff6 ("usb: dwc3: add ULPI interface support")
Signed-off-by: Serge Semin
Acked-by: Heikki Krogerus
---
drivers/usb/dwc3/ulpi.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
index 3cc4f4970c05..54c877f7b51d 100644
--- a/drivers/usb/dwc3/ulpi.c
+++ b/drivers/usb/dwc3/ulpi.c
@@ -7,6 +7,8 @@
* Author: Heikki Krogerus
*/
+#include
+#include
#include
#include "core.h"
@@ -17,12 +19,22 @@
DWC3_GUSB2PHYACC_ADDR(ULPI_ACCESS_EXTENDED) | \
DWC3_GUSB2PHYACC_EXTEND_ADDR(a) : DWC3_GUSB2PHYACC_ADDR(a))
-static int dwc3_ulpi_busyloop(struct dwc3 *dwc)
+#define DWC3_ULPI_BASE_DELAY DIV_ROUND_UP(NSEC_PER_SEC, 6000L)
+
+static int dwc3_ulpi_busyloop(struct dwc3 *dwc, u8 addr, bool read)
{
+ unsigned long ns = 5L * DWC3_ULPI_BASE_DELAY;
unsigned int count = 1000;
u32 reg;
+ if (addr >= ULPI_EXT_VENDOR_SPECIFIC)
+ ns += DWC3_ULPI_BASE_DELAY;
+
+ if (read)
+ ns += DWC3_ULPI_BASE_DELAY;
+
while (count--) {
+ ndelay(ns);
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYACC(0));
if (reg & DWC3_GUSB2PHYACC_DONE)
return 0;
@@ -47,7 +59,7 @@ static int dwc3_ulpi_read(struct device *dev, u8 addr)
reg = DWC3_GUSB2PHYACC_NEWREGREQ | DWC3_ULPI_ADDR(addr);
dwc3_writel(dwc->regs, DWC3_GUSB2PHYACC(0), reg);
- ret = dwc3_ulpi_busyloop(dwc);
+ ret = dwc3_ulpi_busyloop(dwc, addr, true);
if (ret)
return ret;
@@ -71,7 +83,7 @@ static int dwc3_ulpi_write(struct device *dev, u8 addr, u8
val)
reg |= DWC3_GUSB2PHYACC_WRITE | val;
dwc3_writel(dwc->regs, DWC3_GUSB2PHYACC(0), reg);
- return dwc3_ulpi_busyloop(dwc);
+ return dwc3_ulpi_busyloop(dwc, addr, false);
}
static const struct ulpi_ops dwc3_ulpi_ops = {
--
2.29.2
[PATCH v4 3/3] usb: dwc3: ulpi: Fix USB2.0 HS/FS/LS PHY suspend regression
First of all the commit e0082698b689 ("usb: dwc3: ulpi: conditionally
resume ULPI PHY") introduced the Suspend USB2.0 HS/FS/LS PHY regression,
as by design of the fix any attempt to read/write from/to the PHY control
registers will completely disable the PHY suspension, which consequently
will increase the USB bus power consumption. Secondly the fix won't work
well for the very first attempt of the ULPI PHY control registers IO,
because after disabling the USB2.0 PHY suspension functionality it will
still take some time for the bus to resume from the sleep state if one has
been reached before it. So the very first PHY register read/write
operation will take more time than the busy-loop provides and the IO
timeout error might be returned anyway.
Here we suggest to fix the denoted problems in the following way. First of
all let's not disable the Suspend USB2.0 HS/FS/LS PHY functionality so to
make the controller and the USB2.0 bus more power efficient. Secondly
instead of that we'll extend the PHY IO op wait procedure with 1 - 1.2 ms
sleep if the PHY suspension is enabled (1ms should be enough as by LPM
specification it is at most how long it takes for the USB2.0 bus to resume
from L1 (Sleep) state). Finally in case if the USB2.0 PHY suspension
functionality has been disabled on the DWC USB3 controller setup procedure
we'll compensate the USB bus resume process latency by extending the
busy-loop attempts counter.
Fixes: e0082698b689 ("usb: dwc3: ulpi: conditionally resume ULPI PHY")
Signed-off-by: Serge Semin
Acked-by: Heikki Krogerus
---
drivers/usb/dwc3/ulpi.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
index 54c877f7b51d..f23f4c9a557e 100644
--- a/drivers/usb/dwc3/ulpi.c
+++ b/drivers/usb/dwc3/ulpi.c
@@ -24,7 +24,7 @@
static int dwc3_ulpi_busyloop(struct dwc3 *dwc, u8 addr, bool read)
{
unsigned long ns = 5L * DWC3_ULPI_BASE_DELAY;
- unsigned int count = 1000;
+ unsigned int count = 1;
u32 reg;
if (addr >= ULPI_EXT_VENDOR_SPECIFIC)
@@ -33,6 +33,10 @@ static int dwc3_ulpi_busyloop(struct dwc3 *dwc, u8 addr,
bool read)
if (read)
ns += DWC3_ULPI_BASE_DELAY;
+ reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
+ if (reg & DWC3_GUSB2PHYCFG_SUSPHY)
+ usleep_range(1000, 1200);
+
while (count--) {
ndelay(ns);
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYACC(0));
@@ -50,12 +54,6 @@ static int dwc3_ulpi_read(struct device *dev, u8 addr)
u32 reg;
int ret;
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
- if (reg & DWC3_GUSB2PHYCFG_SUSPHY) {
- reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
- }
-
reg = DWC3_GUSB2PHYACC_NEWREGREQ | DWC3_ULPI_ADDR(addr);
dwc3_writel(dwc->regs, DWC3_GUSB2PHYACC(0), reg);
@@ -73,12 +71,6 @@ static int dwc3_ulpi_write(struct device *dev, u8 addr, u8
val)
struct dwc3 *dwc = dev_get_drvdata(dev);
u32 reg;
- reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
- if (reg & DWC3_GUSB2PHYCFG_SUSPHY) {
- reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
- dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
- }
-
reg = DWC3_GUSB2PHYACC_NEWREGREQ | DWC3_ULPI_ADDR(addr);
reg |= DWC3_GUSB2PHYACC_WRITE | val;
dwc3_writel(dwc->regs, DWC3_GUSB2PHYACC(0), reg);
--
2.29.2
Re: [PATCH v4 11/19] sched/core: Make migrate disable and CPU hotplug cooperative
On 04/12/20 21:19, Qian Cai wrote:
> On Tue, 2020-11-17 at 19:28 +, Valentin Schneider wrote:
>> We did have some breakage in that area, but all the holes I was aware of
>> have been plugged. What would help here is to see which tasks are still
>> queued on that outgoing CPU, and their recent activity.
>>
>> Something like
>> - ftrace_dump_on_oops on your kernel cmdline
>> - trace-cmd start -e 'sched:*'
>>
>>
>> ought to do it. Then you can paste the (tail of the) ftrace dump.
>>
>> I also had this laying around, which may or may not be of some help:
>
> Okay, your patch did not help, since it can still be reproduced using this,
>
It wasn't meant to fix this, only add some more debug prints :)
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/hotplug/cpu_hotplug/functional/cpuhotplug04.sh
>
> # while :; do cpuhotplug04.sh -l 1; done
>
> The ftrace dump has too much output on this 256-CPU system, so I have not had
> the patient to wait for it to finish after 15-min. But here is the log
> capturing
> so far (search for "kernel BUG" there).
>
> http://people.redhat.com/qcai/console.log
>
>From there I see:
[20798.166987][ T650] CPU127 nr_running=2
[20798.171185][ T650] p=migration/127
[20798.175161][ T650] p=kworker/127:1
so this might be another workqueue hurdle. This should be prevented by:
06249738a41a ("workqueue: Manually break affinity on hotplug")
In any case, I'll give this a try on a TX2 next week and see where it gets
me.
Note that much earlier in your log, you have a softlockup on CPU127:
[ 74.278367][ C127] watchdog: BUG: soft lockup - CPU#127 stuck for 23s!
[swapper/0:1]
Re: [PATCH 1/7] soundwire: bus: use sdw_update_no_pm when initializing a device
Thanks for the review Vinod.
On 12/5/20 1:45 AM, Vinod Koul wrote:
On 03-12-20, 04:46, Bard Liao wrote:
From: Pierre-Louis Bossart
When a Slave device is resumed, it may resume the bus and restart the
enumeration. During that process, we absolutely don't want to call
regular read/write routines which will wait for the resume to
complete, otherwise a deadlock occurs.
Fixes: 60ee9be25571 ('soundwire: bus: add PM/no-PM versions of read/write
functions')
Change looks okay, but not sure why this is a fix for adding no pm
version?
when we added the no_pm version, we missed the two cases below where
sdw_update() was used and that creates a deadlock. To me that's a
conceptual bug, we didn't fully use the no_pm versions, hence the Fixes tag.
It's ok to remove the tag if you don't think it's useful/relevant, what
matters is that we agree on the content.
Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Rander Wang
Signed-off-by: Bard Liao
---
drivers/soundwire/bus.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index d1e8c3a54976..60c42508c6c6 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -489,6 +489,18 @@ sdw_read_no_pm(struct sdw_slave *slave, u32 addr)
return buf;
}
+static int sdw_update_no_pm(struct sdw_slave *slave, u32 addr, u8 mask, u8 val)
+{
+ int tmp;
+
+ tmp = sdw_read_no_pm(slave, addr);
+ if (tmp < 0)
+ return tmp;
+
+ tmp = (tmp & ~mask) | val;
+ return sdw_write_no_pm(slave, addr, tmp);
+}
+
/**
* sdw_nread() - Read "n" contiguous SDW Slave registers
* @slave: SDW Slave
@@ -1256,7 +1268,7 @@ static int sdw_initialize_slave(struct sdw_slave *slave)
val = slave->prop.scp_int1_mask;
/* Enable SCP interrupts */
- ret = sdw_update(slave, SDW_SCP_INTMASK1, val, val);
+ ret = sdw_update_no_pm(slave, SDW_SCP_INTMASK1, val, val);
if (ret < 0) {
dev_err(slave->bus->dev,
"SDW_SCP_INTMASK1 write failed:%d\n", ret);
@@ -1271,7 +1283,7 @@ static int sdw_initialize_slave(struct sdw_slave *slave)
val = prop->dp0_prop->imp_def_interrupts;
val |= SDW_DP0_INT_PORT_READY | SDW_DP0_INT_BRA_FAILURE;
- ret = sdw_update(slave, SDW_DP0_INTMASK, val, val);
+ ret = sdw_update_no_pm(slave, SDW_DP0_INTMASK, val, val);
if (ret < 0)
dev_err(slave->bus->dev,
"SDW_DP0_INTMASK read failed:%d\n", ret);
--
2.17.1
Re: [PATCH] spi: dw: Fix error return code in dw_spi_bt1_probe()
Hello Zhang
On Fri, Dec 04, 2020 at 04:42:37PM +0800, Zhang Changzhong wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver")
> Reported-by: Hulk Robot
> Signed-off-by: Zhang Changzhong
Thanks for the patch. Definitely
Acked-by: Serge Semin
-Sergey
> ---
> drivers/spi/spi-dw-bt1.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-dw-bt1.c b/drivers/spi/spi-dw-bt1.c
> index f382dfad..c279b78 100644
> --- a/drivers/spi/spi-dw-bt1.c
> +++ b/drivers/spi/spi-dw-bt1.c
> @@ -280,8 +280,10 @@ static int dw_spi_bt1_probe(struct platform_device *pdev)
> dws->bus_num = pdev->id;
> dws->reg_io_width = 4;
> dws->max_freq = clk_get_rate(dwsbt1->clk);
> - if (!dws->max_freq)
> + if (!dws->max_freq) {
> + ret = -EINVAL;
> goto err_disable_clk;
> + }
>
> init_func = device_get_match_data(>dev);
> ret = init_func(pdev, dwsbt1);
> --
> 2.9.5
>
[PATCH v4 1/3] usb: dwc3: ulpi: Use VStsDone to detect PHY regs access completion
In accordance with [1] the DWC_usb3 core sets the GUSB2PHYACCn.VStsDone
bit when the PHY vendor control access is done and clears it when the
application initiates a new transaction. The doc doesn't say anything
about the GUSB2PHYACCn.VStsBsy flag serving for the same purpose. Moreover
we've discovered that the VStsBsy flag can be cleared before the VStsDone
bit. So using the former as a signal of the PHY control registers
completion might be dangerous. Let's have the VStsDone flag utilized
instead then.
[1] Synopsys DesignWare Cores SuperSpeed USB 3.0 xHCI Host Controller
Databook, 2.70a, December 2013, p.388
Fixes: 88bc9d194ff6 ("usb: dwc3: add ULPI interface support")
Signed-off-by: Serge Semin
Acked-by: Heikki Krogerus
---
Changelog v3:
- Add Fixes tag to the commit log.
---
drivers/usb/dwc3/core.h | 1 +
drivers/usb/dwc3/ulpi.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 2f95f08ca511..1b241f937d8f 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -285,6 +285,7 @@
/* Global USB2 PHY Vendor Control Register */
#define DWC3_GUSB2PHYACC_NEWREGREQ BIT(25)
+#define DWC3_GUSB2PHYACC_DONE BIT(24)
#define DWC3_GUSB2PHYACC_BUSY BIT(23)
#define DWC3_GUSB2PHYACC_WRITE BIT(22)
#define DWC3_GUSB2PHYACC_ADDR(n) (n << 16)
diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
index aa213c9815f6..3cc4f4970c05 100644
--- a/drivers/usb/dwc3/ulpi.c
+++ b/drivers/usb/dwc3/ulpi.c
@@ -24,7 +24,7 @@ static int dwc3_ulpi_busyloop(struct dwc3 *dwc)
while (count--) {
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYACC(0));
- if (!(reg & DWC3_GUSB2PHYACC_BUSY))
+ if (reg & DWC3_GUSB2PHYACC_DONE)
return 0;
cpu_relax();
}
--
2.29.2
[PATCH RESEND v4 0/3] usb: dwc3: ulpi: Fix UPLI registers read/write ops
Our Baikal-T1 SoC is equipped with DWC USB3 IP core as a USB2.0 bus
controller. In general the DWC USB3 driver is working well for it except
the ULPI-bus part. We've found out that the DWC USB3 ULPI-bus driver detected
PHY with VID:PID tuple as 0x:0x, which of course wasn't true since
it was supposed to be 0x0424:0x0006. After a short digging inside the
ulpi.c code and studying the DWC USB3 documentation, it has been
discovered that the ULPI bus IO ops didn't work quite correct. The
busy-loop had stopped waiting before the actual operation was finished. We
found out that the problem was caused by several bugs hidden in the DWC
USB3 ULPI-bus IO implementation.
First of all in accordance with the DWC USB3 databook [1] the ULPI IO
busy-loop is supposed to use the GUSB2PHYACCn.VStsDone flag as an
indication of the PHY vendor control access completion. Instead it polled
the GUSB2PHYACCn.VStsBsy flag, which as we discovered can be cleared a
bit before the VStsDone flag.
Secondly having the simple counter-based loop in the modern kernel is
really a weak design of the busy-looping pattern especially seeing the
ULPI operations delay can be easily estimated [2], since the bus clock is
fixed to 60MHz.
Finally the root cause of the denoted in the prologue problem was due to
the Suspend PHY DWC USB3 feature perception. The commit e0082698b689
("usb: dwc3: ulpi: conditionally resume ULPI PHY") introduced the Suspend
USB2.0 HS/FS/LS PHY regression as the Low-power consumption mode would be
disable after a first attempt to read/write from the ULPI PHY control
registers, and still didn't fix the problem it was originally intended for
since the very first attempt of the ULPI PHY control registers IO would
need much more time than the busy-loop provided. So instead of disabling
the Suspend USB2.0 HS/FS/LS PHY feature we suggest to just extend the
busy-loop delay in case if the GUSB2PHYCFGn.SusPHY flag set to 1. By doing
so we'll eliminate the regression and fix the false busy-loop timeout
problem.
[1] Synopsys DesignWare Cores SuperSpeed USB 3.0 xHCI Host Controller
Databook, 2.70a, December 2013, p.388
[2] UTMI+ Low Pin Interface (ULPI) Specification, Revision 1.1,
October 20, 2004, pp. 30 - 36.
Link:
https://lore.kernel.org/linux-usb/20201010222351.7323-1-sergey.se...@baikalelectronics.ru
Changelog v2:
- Add Heikki'es acked-byt tag.
- Resend the series so it wouldn't be lost but merged in the kernel 5.10.
Link:
https://lore.kernel.org/linux-usb/20201026164050.30380-1-sergey.se...@baikalelectronics.ru
Changelog v3:
- Add Fixes tag to the commit log of the patch:
[PATCH 1/3] usb: dwc3: ulpi: Use VStsDone to detect PHY regs access completion
Link:
https://lore.kernel.org/linux-usb/2020090254.12842-1-sergey.se...@baikalelectronics.ru
Changelog v4:
- Just resend.
Fixes: e0082698b689 ("usb: dwc3: ulpi: conditionally resume ULPI PHY")
Fixes: 88bc9d194ff6 ("usb: dwc3: add ULPI interface support")
Signed-off-by: Serge Semin
Acked-by: Heikki Krogerus
Cc: Alexey Malahov
Cc: Pavel Parkhomenko
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (3):
usb: dwc3: ulpi: Use VStsDone to detect PHY regs access completion
usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one
usb: dwc3: ulpi: Fix USB2.0 HS/FS/LS PHY suspend regression
drivers/usb/dwc3/core.h | 1 +
drivers/usb/dwc3/ulpi.c | 38 +-
2 files changed, 22 insertions(+), 17 deletions(-)
--
2.29.2
[PATCH v5 08/19] dt-bindings: usb: xhci: Add Broadcom STB v2 compatible device
For some reason the "brcm,xhci-brcm-v2" compatible string has been missing in the original bindings file. Add it to the Generic xHCI Controllers DT schema since the controller driver expects it to be supported. Signed-off-by: Serge Semin Acked-by: Florian Fainelli Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/usb/generic-xhci.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml index 1ea1d49a8175..23d73df96ea3 100644 --- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml @@ -26,7 +26,9 @@ properties: - marvell,armada-8k-xhci - const: generic-xhci - description: Broadcom STB SoCs with xHCI -const: brcm,bcm7445-xhci +enum: + - brcm,xhci-brcm-v2 + - brcm,bcm7445-xhci - description: Generic xHCI device const: xhci-platform deprecated: true -- 2.29.2
[PATCH v3 09/10] usb: dwc3: qcom: Detect DWC3 DT-nodes with "usb"-prefixed names
In accordance with the USB HCD/DRD schema all the USB controllers are
supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the
existing DT-nodes will be renamed in a subsequent patch let's first make
sure the DWC3 Qualcomm driver supports them and second falls back to the
deprecated naming so not to fail on the legacy DTS-files passed to the
newer kernels.
Signed-off-by: Serge Semin
Reviewed-by: Bjorn Andersson
---
drivers/usb/dwc3/dwc3-qcom.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index c703d552bbcf..49ad8d507d37 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -630,7 +630,8 @@ static int dwc3_qcom_of_register_core(struct
platform_device *pdev)
struct device *dev = >dev;
int ret;
- dwc3_np = of_get_child_by_name(np, "dwc3");
+ dwc3_np = of_get_child_by_name(np, "usb") ?:
+ of_get_child_by_name(np, "dwc3");
if (!dwc3_np) {
dev_err(dev, "failed to find dwc3 core child\n");
return -ENODEV;
--
2.29.2
[PATCH v5 19/19] dt-bindings: usb: intel,keembay-dwc3: Validate DWC3 sub-node
Intel Keem Bay DWC3 compatible DT nodes are supposed to have a DWC USB3
compatible sub-node to describe a fully functioning USB interface. Let's
use the available DWC USB3 DT schema to validate the Qualcomm DWC3
sub-nodes.
Note since the generic DWC USB3 DT node is supposed to be named as generic
USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
regexp and fix the DT node example.
Signed-off-by: Serge Semin
---
Changelog v5:
- This is a new patch created for the new Intel Keem Bay bindings file,
which has been added just recently.
---
.../devicetree/bindings/usb/intel,keembay-dwc3.yaml | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
index dd32c10ce6c7..43b91ab62004 100644
--- a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml
@@ -34,11 +34,8 @@ properties:
# Required child node:
patternProperties:
- "^dwc3@[0-9a-f]+$":
-type: object
-description:
- A child node must exist to represent the core DWC3 IP block.
- The content of the node is defined in dwc3.txt.
+ "^usb@[0-9a-f]+$":
+$ref: snps,dwc3.yaml#
required:
- compatible
@@ -68,7 +65,7 @@ examples:
#address-cells = <1>;
#size-cells = <1>;
- dwc3@3400 {
+ usb@3400 {
compatible = "snps,dwc3";
reg = <0x3400 0x1>;
interrupts = ;
--
2.29.2
[PATCH v5 14/19] dt-bindings: usb: dwc3: Add Frame Length Adj constraints
In accordance with the IP core databook the snps,quirk-frame-length-adjustment property can be set within [0, 0x3F]. Let's make sure the DT schema applies a correct constraints on the property. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index e39ad899c92e..feb41f3e6b21 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -243,6 +243,8 @@ properties: length adjustment when the fladj_30mhz_sdbnd signal is invalid or incorrect. $ref: /schemas/types.yaml#/definitions/uint32 +minimum: 0 +maximum: 0x3f snps,rx-thr-num-pkt-prd: description: -- 2.29.2
[PATCH v5 06/19] dt-bindings: usb: Add generic "usb-phy" property
Even though the Generic PHY framework is the more preferable way of setting the USB PHY up, there are still many dts-files and DT bindings which rely on having the legacy "usb-phy" specified to attach particular USB PHYs to USB cores. Let's have the "usb-phy" property described in the generic USB HCD binding file so it would be validated against the nodes in which it's specified. Mark the property as deprecated to discourage the developers from using it. Signed-off-by: Serge Semin Acked-by: Martin Blumenstingl Reviewed-by: Rob Herring --- Changelog v2: - Discard '|' from the property description, since we don't need to preserve the text formatting. Changelog v4: - Move the "usb-phy" property definition into the usb.yaml schema where all generic USB properties are now defined. --- Documentation/devicetree/bindings/usb/usb.yaml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/usb.yaml b/Documentation/devicetree/bindings/usb/usb.yaml index 6dc4821e63c3..5400893d693e 100644 --- a/Documentation/devicetree/bindings/usb/usb.yaml +++ b/Documentation/devicetree/bindings/usb/usb.yaml @@ -24,6 +24,13 @@ properties: description: Name specifier for the USB PHY + usb-phy: +$ref: /schemas/types.yaml#/definitions/phandle-array +description: + List of all the USB PHYs on this HCD to be accepted by the legacy USB + Physical Layer subsystem. +deprecated: true + phy_type: description: Tells USB controllers that we want to configure the core to support a -- 2.29.2
[PATCH v3 08/10] arm64: dts: apm: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named despite of the warning comment about possible backward
compatibility issues.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++--
arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index a83c82c50e29..832dd85b00bd 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -597,8 +597,8 @@ serial0: serial@1060 {
interrupts = <0x0 0x4c 0x4>;
};
- /* Do not change dwusb name, coded for backward compatibility */
- usb0: dwusb@1900 {
+ /* Node-name might need to be coded as dwusb for backward
compatibility */
+ usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1900 0x0 0x10>;
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 0f37e77f5459..1520a945b7f9 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -923,8 +923,8 @@ sata3: sata@1a80 {
phy-names = "sata-phy";
};
- /* Do not change dwusb name, coded for backward compatibility */
- usb0: dwusb@1900 {
+ /* Node-name might need to be coded as dwusb for backward
compatibility */
+ usb0: usb@1900 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1900 0x0 0x10>;
@@ -933,7 +933,7 @@ usb0: dwusb@1900 {
dr_mode = "host";
};
- usb1: dwusb@1980 {
+ usb1: usb@1980 {
status = "disabled";
compatible = "snps,dwc3";
reg = <0x0 0x1980 0x0 0x10>;
--
2.29.2
[PATCH v5 16/19] dt-bindings: usb: meson-g12a-usb: Validate DWC2/DWC3 sub-nodes
Amlogic G12A USB DT sub-nodes are supposed to be compatible with the generic DWC USB2 and USB3 devices. Since now we've got DT schemas for both of the later IP cores let's make sure that the Amlogic G12A USB DT nodes are fully evaluated including the DWC sub-nodes. Signed-off-by: Serge Semin Reviewed-by: Neil Armstrong Reviewed-by: Rob Herring Reviewed-by: Martin Blumenstingl --- Changelog v2: - Use "oneOf: [dwc2.yaml#, snps,dwc3.yaml#]" instead of the bulky "if: properties: compatibe: ..." statement. --- .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml index 1eda16dd4ee0..e349fa5de606 100644 --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml @@ -79,7 +79,9 @@ properties: patternProperties: "^usb@[0-9a-f]+$": -type: object +oneOf: + - $ref: dwc2.yaml# + - $ref: snps,dwc3.yaml# additionalProperties: false -- 2.29.2
[PATCH v3 06/10] arm: dts: keystone: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/keystone-k2e.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi
b/arch/arm/boot/dts/keystone-k2e.dtsi
index fa1b8499c5a7..b8f152e7af7f 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -52,7 +52,7 @@ {
usb: usb@268 {
interrupts = ;
- dwc3@269 {
+ usb@269 {
interrupts = ;
};
};
@@ -78,7 +78,7 @@ keystone_usb1: usb@2500 {
dma-ranges;
status = "disabled";
- usb1: dwc3@2501 {
+ usb1: usb@2501 {
compatible = "snps,dwc3";
reg = <0x2501 0x7>;
interrupts = ;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 8d046a1b690c..fc9fdc857ae8 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -217,7 +217,7 @@ keystone_usb0: usb@268 {
dma-ranges;
status = "disabled";
- usb0: dwc3@269 {
+ usb0: usb@269 {
compatible = "snps,dwc3";
reg = <0x269 0x7>;
interrupts = ;
--
2.29.2
Re: [PATCH v2] pwm: bcm2835: Support apply function for atomic configuration
Hello Uwe,
On Sat, Dec 05, 2020 at 12:28:34AM +0100, Uwe Kleine-König wrote:
> Hello Sean,
>
> On Fri, Dec 04, 2020 at 11:38:46AM +, Sean Young wrote:
> > On Fri, Dec 04, 2020 at 12:13:26PM +0100, Uwe Kleine-König wrote:
> > > On Fri, Dec 04, 2020 at 08:44:17AM +, Sean Young wrote:
> > > > On Fri, Dec 04, 2020 at 12:42:15AM +0100, Lino Sanfilippo wrote:
> > > > > > You're storing an unsigned long long (i.e. 64 bits) in an u32. If
> > > > > > you are sure that this won't discard relevant bits, please explain
> > > > > > this in a comment for the cursory reader.
> > > > >
> > > > > > Also note that round_closed is probably wrong, as .apply() is
> > > > > > supposed to round down the period to the next achievable period.
> > > > > > (But
> > > > > > fixing this has to do done in a separate patch.)
> > > > >
> > > > > According to commit 11fc4edc4 rounding to the closest integer has
> > > > > been introduced
> > > > > to improve precision in case that the pwm controller is used by the
> > > > > pwm-ir-tx driver.
> > > > > I dont know how strong the requirement is to round down the period in
> > > > > apply(), but I
> > > > > can imagine that this may be a good reason to deviate from this rule.
> > > > > (CCing Sean Young who introduced DIV_ROUND_CLOSEST)
> > > >
> > > > There was a problem where the carrier is incorrect for some IR hardware
> > > > which uses a carrier of 455kHz. With periods that small, rounding errors
> > > > do really matter and rounding down might cause problems.
> > > >
> > > > A policy of rounding down the carrier is not the right thing to do
> > > > for pwm-ir-tx, and such a change will probably break pwm-ir-tx in some
> > > > edge cases.
> > >
> > > IMO it's not an option to say: pwm-driver A is used for IR, so A's
> > > .apply uses round-nearest and pwm-driver B is used for $somethingelse,
> > > so B's .apply uses round-down.
> >
> > I'm not saying that one driver should have one it one way and another driver
> > another way.
>
> I read between your lines that you think that round-nearest is the
> single best strategy, is that right?
Certain the default strategy. When setting a pwm of period X, I would
expect it set it to the closest period it can match to X. Doing anything
else by default is a surprising API.
What real life uses-cases are there for round down? If you want to round
down, is there any need for round up?
Hypothetically you may want e.g. nearest to 100kHz but absolutely no less
than 100kHz. I don't know when this comes up, it would be interesting to
hear where this is needed.
In fact, I am not sure you can guarantee this; when programming the hardware
there is some division arithmetic which may do some rounding and you'll end
up with slightly more than 100kHz.
Equally, you way want e.g. nearest 1MHz but absolutely no more than 1MHz.
This would require round-up for the period.
> If you have two consumer drivers and one requires round-nearest and the
> other requires round-down, how would you suggest to implement these two?
So when does really happen?
> Always adapting the low-level driver depending on which consumer is in
> use sounds wrong. So I conclude that the expectation about the
> implemented rounding behaviour should be the same for all drivers.
Agreed.
> And
> if your consumer happens to require a different strategy you're either
> out of luck (bad), or we need to expand the PWM API to make this
> possible, probably by implementing a round_state callback that tells the
> caller the resulting state if the given state is applied.
Agreed.
> > Why is is easier to implement?
>
> If pwm_apply_state (and so pwm_round_state) rounds down, you can achieve
> round-nearest (simplified: Ignoring polarity, just looking for period) using:
>
> lower_state = pwm_round_state(pwm, target_state);
> upper_state = {
> .period = 2 * target_state.period - lower_state.period,
> ...
> }
> tmp = pwm_round_state(pwm, upper)
>
> if tmp.period < target_state.period:
> # tmp == lower_state
> return lower_state
>
> else while tmp.period > target_state.period:
> upper = tmp;
> tmp.period -= 1
> tmp = pwm_round_state(pwm, tmp)
>
> I admit it is not pretty. But please try to implement it the other way
> around (i.e. pwm_round_state rounding to nearest and search for a
> setting that yields the biggest period not above target.period without
> just trying all steps). I spend a few brain cycles and the corner cases
> are harder. (But maybe I'm not smart enough, so please convince me.)
Ok. Does pwm hardware always work on a linear scale?
> Note that with round-nearest there is another complication: Assume a PWM
> that can implement period = 500 µs and period = 1000 µs (and nothing
> inbetween). That corresponds to the frequencies 2000 Hz and 1000 Hz.
> round_nearest for state with period = 700 µs (corresponding to 1428.5714
>
Re: [PATCH v2 2/5] arm64: dts: meson: fix PHY deassert timing requirements
On Tue, Dec 1, 2020 at 2:21 PM Stefan Agner wrote:
>
> According to the datasheet (Rev. 1.9) the RTL8211F requires at least
> 72ms "for internal circuits settling time" before accessing the PHY
> egisters. This fixes an issue seen on ODROID-C2 where the Ethernet
> link doesn't come up when using ip link set down/up:
> [ 6630.714855] meson8b-dwmac c941.ethernet eth0: Link is Down
> [ 6630.785775] meson8b-dwmac c941.ethernet eth0: PHY [stmmac-0:00]
> driver [RTL8211F Gigabit Ethernet] (irq=36)
> [ 6630.893071] meson8b-dwmac c941.ethernet: Failed to reset the dma
> [ 6630.893800] meson8b-dwmac c941.ethernet eth0: stmmac_hw_setup: DMA
> engine initialization failed
> [ 6630.902835] meson8b-dwmac c941.ethernet eth0: stmmac_open: Hw setup
> failed
>
> Fixes: f29cabf240ed ("arm64: dts: meson: use the generic Ethernet PHY reset
> GPIO bindings")
> Signed-off-by: Stefan Agner
with the "registers" typo above fixed:
Reviewed-by: Martin Blumenstingl
[PATCH v3 10/10] arm64: dts: qcom: Harmonize DWC USB3 DT nodes name
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin
Acked-by: Krzysztof Kozlowski
Reviewed-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/ipq8074.dtsi| 4 ++--
arch/arm64/boot/dts/qcom/msm8996.dtsi| 4 ++--
arch/arm64/boot/dts/qcom/msm8998.dtsi| 2 +-
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
9 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index defcbd15edf9..34e97da98270 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -1064,7 +1064,7 @@ {
status = "okay";
extcon = <_id>;
- dwc3@760 {
+ usb@760 {
extcon = <_id>;
dr_mode = "otg";
maximum-speed = "high-speed";
@@ -1075,7 +1075,7 @@ {
status = "okay";
extcon = <_id>;
- dwc3@6a0 {
+ usb@6a0 {
extcon = <_id>;
dr_mode = "otg";
};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index 829e37ac82f6..984e855bd8fd 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -427,7 +427,7 @@ usb_0: usb@8af8800 {
resets = < GCC_USB0_BCR>;
status = "disabled";
- dwc_0: dwc3@8a0 {
+ dwc_0: usb@8a0 {
compatible = "snps,dwc3";
reg = <0x8a0 0xcd00>;
interrupts = ;
@@ -468,7 +468,7 @@ usb_1: usb@8cf8800 {
resets = < GCC_USB1_BCR>;
status = "disabled";
- dwc_1: dwc3@8c0 {
+ dwc_1: usb@8c0 {
compatible = "snps,dwc3";
reg = <0x8c0 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index fd6ae5464dea..4b073b8584de 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -1768,7 +1768,7 @@ usb3: usb@6af8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
- dwc3@6a0 {
+ usb@6a0 {
compatible = "snps,dwc3";
reg = <0x06a0 0xcc00>;
interrupts = <0 131 IRQ_TYPE_LEVEL_HIGH>;
@@ -1979,7 +1979,7 @@ usb2: usb@76f8800 {
power-domains = < USB30_GDSC>;
status = "disabled";
- dwc3@760 {
+ usb@760 {
compatible = "snps,dwc3";
reg = <0x0760 0xcc00>;
interrupts = <0 138 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index c45870600909..7cc7897e7b83 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -1678,7 +1678,7 @@ usb3: usb@a8f8800 {
resets = < GCC_USB_30_BCR>;
- usb3_dwc3: dwc3@a80 {
+ usb3_dwc3: usb@a80 {
compatible = "snps,dwc3";
reg = <0x0a80 0xcd00>;
interrupts = ;
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index a80c578484ba..f8a55307b855 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -337,7 +337,7 @@ _phy_sec {
{
status = "okay";
- dwc3@758 {
+ usb@758 {
dr_mode = "host";
};
};
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index b654b802e95c..f6ef17553064 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -544,7 +544,7 @@ usb3: usb@7678800 {
assigned-clock-rates = <1920>, <2>;
status = "disabled";
-
[PATCH RESEND v3 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
As the subject states this series is an attempt to harmonize the xHCI,
EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
framework of the patchset [1].
Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
controllers with "synopsys,"-vendor prefix compatible string in favor of
the ones with valid "snps,"-prefix. It's done in all the DTS files,
which have been unfortunate to define such nodes.
Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
been erroneously declared as boolean while having uint32 type. Neil said
it was ok to init that property with 0x20 value.
Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
and DWC USB3 DT nodes name as in accordance with their DT schema the
corresponding node name is suppose to comply with the Generic USB HCD DT
schema, which requires the USB nodes to have the name acceptable by the
regexp: "^usb(@.*)?". Such requirement had been applicable even before we
introduced the new DT schema in [1], but as we can see it hasn't been
strictly implemented for a lot the DTS files. Since DT schema is now
available the automated DTS validation shall make sure that the rule isn't
violated.
Note most of these patches have been a part of the last three patches of
[1]. But since there is no way to have them merged in in a combined
manner, I had to move them to the dedicated series and split them up so to
be accepted by the corresponding subsystem maintainers one-by-one.
[1] Link:
https://lore.kernel.org/linux-usb/20201014101402.18271-1-sergey.se...@baikalelectronics.ru/
Changelog v1:
- As Krzysztof suggested I've created a script which checked whether the
node names had been also updated in all the depended dts files. As a
result I found two more files which should have been also modified:
arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
- Correct the USB DWC3 nodes name found in
arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.
Link:
https://lore.kernel.org/linux-usb/20201020115959.2658-1-sergey.se...@baikalelectronics.ru
Changelog v2:
- Drop the patch:
[PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
and get back the one which marks the "synopsys,dwc3" compatible string
as deprecated into the DT schema related series.
- Drop the patches:
[PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
[PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
[PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
[PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
[PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
[PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
[PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
[PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
[PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
[PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
[PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
since they have been applied to the corresponding maintainers repos.
- Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
sub-node and falling back to the "dwc3@"-prefixed one on failure.
Link:
https://lore.kernel.org/linux-usb/2020091552.15593-1-sergey.se...@baikalelectronics.ru
Changelog v3:
- Drop the patches:
[PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
[PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes
name
[PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
since they have been applied to the corresponding maintainers repos.
Cc: Vineet Gupta
Cc: Rafal Milecki
Cc: Wei Xu
Cc: Thomas Bogendoerfer
Cc: Michael Ellerman
Cc: Jason Cooper
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Benoit Cousson
Cc: Patrice Chotard
Cc: Maxime Ripard
Cc: Khuong Dinh
Cc: Andy Gross
Cc: Alexey Brodkin
Cc: Hauke Mehrtens
Cc: Maxime Coquelin
Cc: Alexandre Torgue
Cc: Amelie Delaunay
Cc: Vladimir Zapolskiy
Cc: Paul Cercueil
Cc: Matthias Brugger
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Sebastian Hesselbarth
Cc: Kukjin Kim
Cc: Li Yang
Cc: Tony Lindgren
Cc: Chen-Yu Tsai
Cc: Bjorn Andersson
Cc: Jun Li
Cc: linux-snps-...@lists.infradead.org
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc:
[PATCH 5/9] mm: memcontrol: convert NR_FILE_THPS account to pages
Converrt NR_FILE_THPS account to pages.
Signed-off-by: Muchun Song
---
drivers/base/node.c | 3 +--
fs/proc/meminfo.c | 2 +-
mm/filemap.c| 2 +-
mm/huge_memory.c| 3 ++-
mm/khugepaged.c | 2 +-
mm/memcontrol.c | 5 ++---
6 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 05c369e93e16..f6a9521bbcf8 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -466,8 +466,7 @@ static ssize_t node_read_meminfo(struct device *dev,
HPAGE_PMD_NR),
nid, K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED) *
HPAGE_PMD_NR),
-nid, K(node_page_state(pgdat, NR_FILE_THPS) *
- HPAGE_PMD_NR),
+nid, K(node_page_state(pgdat, NR_FILE_THPS)),
nid, K(node_page_state(pgdat, NR_FILE_PMDMAPPED) *
HPAGE_PMD_NR)
#endif
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index f447ac191d24..9b2cb770326e 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -135,7 +135,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
show_val_kb(m, "ShmemPmdMapped: ",
global_node_page_state(NR_SHMEM_PMDMAPPED) * HPAGE_PMD_NR);
show_val_kb(m, "FileHugePages: ",
- global_node_page_state(NR_FILE_THPS) * HPAGE_PMD_NR);
+ global_node_page_state(NR_FILE_THPS));
show_val_kb(m, "FilePmdMapped: ",
global_node_page_state(NR_FILE_PMDMAPPED) * HPAGE_PMD_NR);
#endif
diff --git a/mm/filemap.c b/mm/filemap.c
index 28e7309c29c8..c4dcb1144883 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -206,7 +206,7 @@ static void unaccount_page_cache_page(struct address_space
*mapping,
if (PageTransHuge(page))
__dec_lruvec_page_state(page, NR_SHMEM_THPS);
} else if (PageTransHuge(page)) {
- __dec_lruvec_page_state(page, NR_FILE_THPS);
+ __mod_lruvec_page_state(page, NR_FILE_THPS, -HPAGE_PMD_NR);
filemap_nr_thps_dec(mapping);
}
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 1a13e1dab3ec..37840bdeaad0 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2748,7 +2748,8 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
if (PageSwapBacked(head))
__dec_lruvec_page_state(head, NR_SHMEM_THPS);
else
- __dec_lruvec_page_state(head, NR_FILE_THPS);
+ __mod_lruvec_page_state(head, NR_FILE_THPS,
+ -HPAGE_PMD_NR);
}
__split_huge_page(page, list, end);
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index ad316d2e1fee..1e1ced2208d0 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1859,7 +1859,7 @@ static void collapse_file(struct mm_struct *mm,
if (is_shmem)
__inc_lruvec_page_state(new_page, NR_SHMEM_THPS);
else {
- __inc_lruvec_page_state(new_page, NR_FILE_THPS);
+ __mod_lruvec_page_state(new_page, NR_FILE_THPS, HPAGE_PMD_NR);
filemap_nr_thps_inc(mapping);
}
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 39cb7f1b00d3..dce76dddac61 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1514,7 +1514,7 @@ static struct memory_stat memory_stats[] = {
* constant(e.g. powerpc).
*/
{ "anon_thp", PAGE_SIZE, NR_ANON_THPS },
- { "file_thp", 0, NR_FILE_THPS },
+ { "file_thp", PAGE_SIZE, NR_FILE_THPS },
{ "shmem_thp", 0, NR_SHMEM_THPS },
#endif
{ "inactive_anon", PAGE_SIZE, NR_INACTIVE_ANON },
@@ -1546,8 +1546,7 @@ static int __init memory_stats_init(void)
for (i = 0; i < ARRAY_SIZE(memory_stats); i++) {
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- if (memory_stats[i].idx == NR_FILE_THPS ||
- memory_stats[i].idx == NR_SHMEM_THPS)
+ if (memory_stats[i].idx == NR_SHMEM_THPS)
memory_stats[i].ratio = HPAGE_PMD_SIZE;
#endif
VM_BUG_ON(!memory_stats[i].ratio);
--
2.11.0
Re: [PATCH 2/8] Documentation: HID: amd-sfh-hid editing & corrections
On Thu, 3 Dec 2020 22:20:16 -0800 Randy Dunlap wrote: > Do basic editing & correction to amd-sfh-hid.rst: > - fix punctuation > - use HID instead of hid consistently > - fix grammar, verb tense > > Signed-off-by: Randy Dunlap > Cc: Jiri Kosina > Cc: Jonathan Cameron > Cc: Srinivas Pandruvada > Cc: linux-in...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org Trivial suggested addition inline. > --- > Documentation/hid/amd-sfh-hid.rst | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > --- linux-next-20201201.orig/Documentation/hid/amd-sfh-hid.rst > +++ linux-next-20201201/Documentation/hid/amd-sfh-hid.rst > @@ -3,7 +3,7 @@ > > AMD Sensor Fusion Hub > = > -AMD Sensor Fusion Hub (SFH) is part of an SOC starting from Ryzen based > platforms. > +AMD Sensor Fusion Hub (SFH) is part of an SOC starting from Ryzen-based > platforms. > The solution is working well on several OEM products. AMD SFH uses HID over > PCIe bus. > In terms of architecture it resembles ISH, however the major difference is > all > the HID reports are generated as part of the kernel driver. > @@ -45,20 +45,20 @@ the HID reports are generated as part of > AMD HID Transport Layer > --- > AMD SFH transport is also implemented as a bus. Each client application > executing in the AMD MP2 is > -registered as a device on this bus. Here: MP2 which is an ARM core connected > to x86 for processing > +registered as a device on this bus. Here, MP2 is an ARM core connected to > x86 for processing > sensor data. The layer, which binds each device (AMD SFH HID driver) > identifies the device type and > -registers with the hid core. Transport layer attach a constant "struct > hid_ll_driver" object with > +registers with the HID core. Transport layer attaches a constant "struct > hid_ll_driver" object with > each device. Once a device is registered with HID core, the callbacks > provided via this struct are > used by HID core to communicate with the device. AMD HID Transport layer > implements the synchronous calls. > > AMD HID Client Layer > > -This layer is responsible to implement HID request and descriptors. As > firmware is OS agnostic, HID > +This layer is responsible to implement HID requests and descriptors. As > firmware is OS agnostic, HID > client layer fills the HID request structure and descriptors. HID client > layer is complex as it is > -interface between MP2 PCIe layer and HID. HID client layer initialized the > MP2 PCIe layer and holds > +interface between MP2 PCIe layer and HID. HID client layer initializes the > MP2 PCIe layer and holds > the instance of MP2 layer. It identifies the number of sensors connected > using MP2-PCIe layer. Base Based ? (maybe) > -on that allocates the DRAM address for each and every sensor and pass it to > MP2-PCIe driver.On > -enumeration of each the sensor, client layer fills the HID Descriptor > structure and HID input repor > +on that allocates the DRAM address for each and every sensor and passes it > to MP2-PCIe driver. On > +enumeration of each sensor, client layer fills the HID Descriptor structure > and HID input report > structure. HID Feature report structure is optional. The report descriptor > structure varies from > sensor to sensor. > > @@ -72,7 +72,7 @@ The communication between X86 and MP2 is > 2. Data transfer via DRAM. > 3. Supported sensor info via P2C registers. > > -Commands are sent to MP2 using C2P Mailbox registers. Writing into C2P > Message registers generate > +Commands are sent to MP2 using C2P Mailbox registers. Writing into C2P > Message registers generates > interrupt to MP2. The client layer allocates the physical memory and the > same is sent to MP2 via > the PCI layer. MP2 firmware writes the command output to the access DRAM > memory which the client > layer has allocated. Firmware always writes minimum of 32 bytes into DRAM. > So as a protocol driver
Re: [PATCH v2 00/18] Add CMU/RMU/DMA/MMC/I2C support for Actions Semi S500 SoCs
Hi Mani, On Sat, Dec 05, 2020 at 11:41:15AM +0530, Manivannan Sadhasivam wrote: > Hi Cristi, > > On Fri, Nov 20, 2020 at 01:55:54AM +0200, Cristian Ciocaltea wrote: > > Hi, > > > > This patchset brings a series of improvements for the Actions Semi S500 > > SoCs family, by adding support for Clock & Reset Management Units, DMA, > > MMC, I2C & SIRQ controllers. > > > > Please note the patches consist mostly of DTS and bindings/compatibles > > changes, since all the work they depend on has been already merged, > > i.e. clock fixes/additions, pinctrl driver, sirq driver. > > > > For the moment, I have only enabled the features I could test on > > RoseapplePi SBC. > > > > I was hoping to apply this series for v5.11 but we ran out of time. So expect > this series to be in v5.12. No problem, thanks a lot for taking care of this! Kind regards, Cristi > Thanks, > Mani > > > Thanks, > > Cristi > > > > Changes in v2: > > - Added new bindings/compatibles for S500 DMA, MMC & I2C controllers > > - Added support for the SIRQ controller > > - Added new entries in MAINTAINERS > > - Updated naming of some patches in v1 > > > > Cristian Ciocaltea (18): > > arm: dts: owl-s500: Add Clock Management Unit > > arm: dts: owl-s500: Set CMU clocks for UARTs > > arm: dts: owl-s500: Add Reset controller > > dt-bindings: dma: owl: Add compatible string for Actions Semi S500 SoC > > dmaengine: owl: Add compatible for the Actions Semi S500 DMA > > controller > > arm: dts: owl-s500: Add DMA controller > > arm: dts: owl-s500: Add pinctrl & GPIO support > > dt-bindings: mmc: owl: Add compatible string for Actions Semi S500 SoC > > arm: dts: owl-s500: Add MMC support > > dt-bindings: i2c: owl: Convert Actions Semi Owl binding to a schema > > MAINTAINERS: Update entry for Actions Semi Owl I2C binding > > i2c: owl: Add compatible for the Actions Semi S500 I2C controller > > arm: dts: owl-s500: Add I2C support > > arm: dts: owl-s500: Add SIRQ controller > > arm: dts: owl-s500-roseapplepi: Use UART clock from CMU > > arm: dts: owl-s500-roseapplepi: Add uSD support > > arm: dts: owl-s500-roseapplepi: Add I2C pinctrl configuration > > MAINTAINERS: Add linux-actions ML for Actions Semi Arch > > > > .../devicetree/bindings/dma/owl-dma.yaml | 5 +- > > .../devicetree/bindings/i2c/i2c-owl.txt | 29 > > .../devicetree/bindings/i2c/i2c-owl.yaml | 62 > > .../devicetree/bindings/mmc/owl-mmc.yaml | 4 +- > > MAINTAINERS | 3 +- > > arch/arm/boot/dts/owl-s500-roseapplepi.dts| 97 +++- > > arch/arm/boot/dts/owl-s500.dtsi | 140 ++ > > drivers/dma/owl-dma.c | 1 + > > drivers/i2c/busses/i2c-owl.c | 1 + > > 9 files changed, 304 insertions(+), 38 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-owl.txt > > create mode 100644 Documentation/devicetree/bindings/i2c/i2c-owl.yaml > > > > -- > > 2.29.2 > >
[PATCH v5 07/19] dt-bindings: usb: Convert xHCI bindings to DT schema
Currently the DT bindings of Generic xHCI Controllers are described by
means of the legacy text file. Since such format is deprecated in favor of
the DT schema, let's convert the Generic xHCI Controllers bindings file to
the corresponding yaml files. There will be two of them: a DT schema for
the xHCI controllers on a generic platform and a DT schema validating a
generic xHCI controllers properties. The later will be used to validate
the xHCI controllers, which aside from some vendor-specific features
support the basic xHCI functionality.
An xHCI-compatible DT node shall support the standard USB HCD properties
and custom ones like: usb2-lpm-disable, usb3-lpm-capable,
quirk-broken-port-ped and imod-interval-ns. In addition if a generic xHCI
controller is being validated against the DT schema it is also supposed to
be equipped with mandatory compatible string, single registers range,
single interrupts source, and is supposed to optionally contain up to two
reference clocks for the controller core and CSRs.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
---
Changelog v2:
- Add explicit "additionalProperties: true" to the usb-xhci.yaml schema,
since additionalProperties/unevaluatedProperties are going to be mandary
for each binding.
---
.../devicetree/bindings/usb/generic-xhci.yaml | 63 +++
.../devicetree/bindings/usb/usb-xhci.txt | 41
.../devicetree/bindings/usb/usb-xhci.yaml | 42 +
3 files changed, 105 insertions(+), 41 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/generic-xhci.yaml
delete mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.txt
create mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.yaml
diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
new file mode 100644
index ..1ea1d49a8175
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: USB xHCI Controller Device Tree Bindings
+
+maintainers:
+ - Mathias Nyman
+
+allOf:
+ - $ref: "usb-xhci.yaml#"
+
+properties:
+ compatible:
+oneOf:
+ - description: Generic xHCI device
+const: generic-xhci
+ - description: Armada 37xx/375/38x/8k SoCs
+items:
+ - enum:
+ - marvell,armada3700-xhci
+ - marvell,armada-375-xhci
+ - marvell,armada-380-xhci
+ - marvell,armada-8k-xhci
+ - const: generic-xhci
+ - description: Broadcom STB SoCs with xHCI
+const: brcm,bcm7445-xhci
+ - description: Generic xHCI device
+const: xhci-platform
+deprecated: true
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+minItems: 1
+maxItems: 2
+
+ clock-names:
+minItems: 1
+items:
+ - const: core
+ - const: reg
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+usb@f0931000 {
+ compatible = "generic-xhci";
+ reg = <0xf0931000 0x8c8>;
+ interrupts = <0x0 0x4e 0x0>;
+};
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
deleted file mode 100644
index 0c5cff84a969..
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-USB xHCI controllers
-
-Required properties:
- - compatible: should be one or more of
-
-- "generic-xhci" for generic XHCI device
-- "marvell,armada3700-xhci" for Armada 37xx SoCs
-- "marvell,armada-375-xhci" for Armada 375 SoCs
-- "marvell,armada-380-xhci" for Armada 38x SoCs
-- "brcm,bcm7445-xhci" for Broadcom STB SoCs with XHCI
-- "xhci-platform" (deprecated)
-
-When compatible with the generic version, nodes must list the
-SoC-specific version corresponding to the platform first
-followed by the generic version.
-
- - reg: should contain address and length of the standard XHCI
-register set for the device.
- - interrupts: one XHCI interrupt should be described here.
-
-Optional properties:
- - clocks: reference to the clocks
- - clock-names: mandatory if there is a second clock, in this case
-the name must be "core" for the first clock and "reg" for the
-second one
- - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
- - usb3-lpm-capable: determines if platform is USB3 LPM capable
- - quirk-broken-port-ped: set if the controller has broken port disable
mechanism
- - imod-interval-ns: default interrupt moderation interval is 5000ns
- - phys : see usb-hcd.yaml in the current directory
-
-additionally the properties from usb-hcd.yaml (in the current directory) are
-supported.
-
-
-Example:
- usb@f0931000 {
[PATCH net v4] bonding: fix feature flag setting at init time
Don't try to adjust XFRM support flags if the bond device isn't yet
registered. Bad things can currently happen when netdev_change_features()
is called without having wanted_features fully filled in yet. This code
runs both on post-module-load mode changes, as well as at module init
time, and when run at module init time, it is before register_netdevice()
has been called and filled in wanted_features. The empty wanted_features
led to features also getting emptied out, which was definitely not the
intended behavior, so prevent that from happening.
Originally, I'd hoped to stop adjusting wanted_features at all in the
bonding driver, as it's documented as being something only the network
core should touch, but we actually do need to do this to properly update
both the features and wanted_features fields when changing the bond type,
or we get to a situation where ethtool sees:
esp-hw-offload: off [requested on]
I do think we should be using netdev_update_features instead of
netdev_change_features here though, so we only send notifiers when the
features actually changed.
Fixes: a3b658cfb664 ("bonding: allow xfrm offload setup post-module-load")
Reported-by: Ivan Vecera
Suggested-by: Ivan Vecera
Cc: Jay Vosburgh
Cc: Veaceslav Falico
Cc: Andy Gospodarek
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Thomas Davis
Cc: net...@vger.kernel.org
Signed-off-by: Jarod Wilson
---
v2: rework based on further testing and suggestions from ivecera
v3: add helper function, remove goto
v4: drop hunk not directly related to fix, clean up ifdeffery
drivers/net/bonding/bond_options.c | 22 +++---
include/net/bonding.h | 2 --
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/net/bonding/bond_options.c
b/drivers/net/bonding/bond_options.c
index 9abfaae1c6f7..a4e4e15f574d 100644
--- a/drivers/net/bonding/bond_options.c
+++ b/drivers/net/bonding/bond_options.c
@@ -745,6 +745,19 @@ const struct bond_option *bond_opt_get(unsigned int option)
return _opts[option];
}
+static void bond_set_xfrm_features(struct net_device *bond_dev, u64 mode)
+{
+ if (!IS_ENABLED(CONFIG_XFRM_OFFLOAD))
+ return;
+
+ if (mode == BOND_MODE_ACTIVEBACKUP)
+ bond_dev->wanted_features |= BOND_XFRM_FEATURES;
+ else
+ bond_dev->wanted_features &= ~BOND_XFRM_FEATURES;
+
+ netdev_update_features(bond_dev);
+}
+
static int bond_option_mode_set(struct bonding *bond,
const struct bond_opt_value *newval)
{
@@ -767,13 +780,8 @@ static int bond_option_mode_set(struct bonding *bond,
if (newval->value == BOND_MODE_ALB)
bond->params.tlb_dynamic_lb = 1;
-#ifdef CONFIG_XFRM_OFFLOAD
- if (newval->value == BOND_MODE_ACTIVEBACKUP)
- bond->dev->wanted_features |= BOND_XFRM_FEATURES;
- else
- bond->dev->wanted_features &= ~BOND_XFRM_FEATURES;
- netdev_change_features(bond->dev);
-#endif /* CONFIG_XFRM_OFFLOAD */
+ if (bond->dev->reg_state == NETREG_REGISTERED)
+ bond_set_xfrm_features(bond->dev, newval->value);
/* don't cache arp_validate between modes */
bond->params.arp_validate = BOND_ARP_VALIDATE_NONE;
diff --git a/include/net/bonding.h b/include/net/bonding.h
index d9d0ff3b0ad3..adc3da776970 100644
--- a/include/net/bonding.h
+++ b/include/net/bonding.h
@@ -86,10 +86,8 @@
#define bond_for_each_slave_rcu(bond, pos, iter) \
netdev_for_each_lower_private_rcu((bond)->dev, pos, iter)
-#ifdef CONFIG_XFRM_OFFLOAD
#define BOND_XFRM_FEATURES (NETIF_F_HW_ESP | NETIF_F_HW_ESP_TX_CSUM | \
NETIF_F_GSO_ESP)
-#endif /* CONFIG_XFRM_OFFLOAD */
#ifdef CONFIG_NET_POLL_CONTROLLER
extern atomic_t netpoll_block_tx;
--
2.28.0
[PATCH v5 18/19] dt-bindings: usb: qcom,dwc3: Validate DWC3 sub-node
Qualcomm msm8996/sc7180/sdm845 DWC3 compatible DT nodes are supposed to
have a DWC USB3 compatible sub-node to describe a fully functioning USB
interface. Let's use the available DWC USB3 DT schema to validate the
Qualcomm DWC3 sub-nodes.
Note since the generic DWC USB3 DT node is supposed to be named as generic
USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
regexp and fix the DT node example.
Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
---
Changelog v2:
- Discard the "^dwc3@[0-9a-f]+$" nodes from being acceptable as sub-nodes.
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index 2cf525d21e05..b336662e838c 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -103,11 +103,8 @@ properties:
# Required child node:
patternProperties:
- "^dwc3@[0-9a-f]+$":
-type: object
-description:
- A child node must exist to represent the core DWC3 IP block
- The content of the node is defined in dwc3.txt.
+ "^usb@[0-9a-f]+$":
+$ref: snps,dwc3.yaml#
required:
- compatible
@@ -162,7 +159,7 @@ examples:
resets = < GCC_USB30_PRIM_BCR>;
-dwc3@a60 {
+usb@a60 {
compatible = "snps,dwc3";
reg = <0 0x0a60 0 0xcd00>;
interrupts = ;
--
2.29.2
[PATCH v5 15/19] dt-bindings: usb: meson-g12a-usb: Fix FL-adj property value
An empty snps,quirk-frame-length-adjustment won't cause any change performed by the driver. Moreover the DT schema validation will fail, since it expects the property being assigned with some value. So set fix the example by setting a valid FL-adj value in accordance with Neil Armstrong comment. Link: https://lore.kernel.org/linux-usb/20201010224121.12672-16-sergey.se...@baikalelectronics.ru/ Signed-off-by: Serge Semin Acked-by: Neil Armstrong Reviewed-by: Rob Herring Reviewed-by: Martin Blumenstingl --- Note the same problem is in the DT source file arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi . --- .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml index c0058332b967..1eda16dd4ee0 100644 --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml @@ -229,6 +229,6 @@ examples: interrupts = <30>; dr_mode = "host"; snps,dis_u2_susphy_quirk; - snps,quirk-frame-length-adjustment; + snps,quirk-frame-length-adjustment = <0x20>; }; }; -- 2.29.2
[PATCH 1/3] drivers/hv: make max_num_channels_supported configurable
To make the number of supported channels configurable, this patch
introduces uint max_num_channels_supported as module parameter.
Also macro MAX_NUM_CHANNELS_SUPPORTED_DEFAULT is introduced with
value 256, which is the currently used macro value.
MAX_NUM_CHANNELS_SUPPORTED was found and replaced in two locations.
During module initialization sanity checks are applied which will result
in EINVAL or ERANGE if the given value is no multiple of 32 or larger than
MAX_NUM_CHANNELS.
Signed-off-by: Stefan Eschenbacher
Co-developed-by: Max Stolze
Signed-off-by: Max Stolze
---
drivers/hv/hyperv_vmbus.h | 6 +++---
drivers/hv/vmbus_drv.c| 20 +++-
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 02f3e8988836..edeee1c0497d 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -194,11 +194,11 @@ int hv_ringbuffer_read(struct vmbus_channel *channel,
#define MAX_NUM_CHANNELS ((HV_HYP_PAGE_SIZE >> 1) << 3)
/* The value here must be in multiple of 32 */
-/* TODO: Need to make this configurable */
-#define MAX_NUM_CHANNELS_SUPPORTED 256
+#define MAX_NUM_CHANNELS_SUPPORTED_DEFAULT 256
+extern uint max_num_channels_supported;
#define MAX_CHANNEL_RELIDS \
- max(MAX_NUM_CHANNELS_SUPPORTED, HV_EVENT_FLAGS_COUNT)
+ max((ulong) max_num_channels_supported, (ulong) HV_EVENT_FLAGS_COUNT)
enum vmbus_connect_state {
DISCONNECTED,
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 502f8cd95f6d..8f1c8a606b4a 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -48,6 +48,11 @@ static int hyperv_cpuhp_online;
static void *hv_panic_page;
+uint max_num_channels_supported = MAX_NUM_CHANNELS_SUPPORTED_DEFAULT;
+module_param(max_num_channels_supported, uint, 0);
+MODULE_PARM_DESC(max_num_channels_supported,
+ "Number of supported vmbus channels. Must be a multiple of 32 and equal
to or less than 16348");
+
/* Values parsed from ACPI DSDT */
static int vmbus_irq;
int vmbus_interrupt;
@@ -1220,7 +1225,7 @@ static void vmbus_chan_sched(struct hv_per_cpu_context
*hv_cpu)
u32 maxbits, relid;
if (vmbus_proto_version < VERSION_WIN8) {
- maxbits = MAX_NUM_CHANNELS_SUPPORTED;
+ maxbits = max_num_channels_supported;
recv_int_page = vmbus_connection.recv_int_page;
} else {
/*
@@ -2620,6 +2625,17 @@ static int __init hv_acpi_init(void)
if (!hv_is_hyperv_initialized())
return -ENODEV;
+ // Check if max_num_channels_supported is a multiple of 32 and smaller
MAX_NUM_CHANNELS
+ if (max_num_channels_supported % 32 != 0) {
+ pr_err("max_num_channels_supported is %u, but must be a
multiple of 32\n",
+ max_num_channels_supported);
+ return -EINVAL;
+ } else if (max_num_channels_supported > MAX_NUM_CHANNELS) {
+ pr_err("max_num_channels_supported is %u which exceeds maximum
of %lu\n",
+ max_num_channels_supported, MAX_NUM_CHANNELS);
+ return -ERANGE;
+ }
+
init_completion(_event);
/*
@@ -2641,6 +2657,8 @@ static int __init hv_acpi_init(void)
if (ret)
goto cleanup;
+ pr_info("Supporting up to %u channels\n", max_num_channels_supported);
+
hv_setup_kexec_handler(hv_kexec_handler);
hv_setup_crash_handler(hv_crash_handler);
--
2.20.1
[PATCH 3/3] drivers/hv: add default number of vmbus channels to Kconfig
The default number of vmbus channels (macro MAX_NUM_CHANNELS_SUPPORTED_DEFAULT) is made configurable through the new Kconfig option HYPERV_VMBUS_DEFAULT_CHANNELS. Signed-off-by: Stefan Eschenbacher Co-developed-by: Max Stolze Signed-off-by: Max Stolze --- drivers/hv/Kconfig| 13 + drivers/hv/hyperv_vmbus.h | 2 +- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig index 79e5356a737a..40bee5b05ccd 100644 --- a/drivers/hv/Kconfig +++ b/drivers/hv/Kconfig @@ -26,4 +26,17 @@ config HYPERV_BALLOON help Select this option to enable Hyper-V Balloon driver. +config HYPERV_VMBUS_DEFAULT_CHANNELS + int "Default number of VMBus channels (as multiple of 32)" + range 0 512 + default 8 + depends on HYPERV + help + Specify the default number of VMBus channels here as nth multiple of + 32. The value must be equal to or less than 512. + The default is 8 meaning the number of channels is 8 * 32 = 256. + A different value can be set when loading the hv_vmbus module by + setting the parameter max_num_channels_supported directly to the + number of channels and not as a multiple of 32. + endmenu diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h index 52dcfa1c17ef..47af2c76ce57 100644 --- a/drivers/hv/hyperv_vmbus.h +++ b/drivers/hv/hyperv_vmbus.h @@ -194,7 +194,7 @@ int hv_ringbuffer_read(struct vmbus_channel *channel, #define MAX_NUM_CHANNELS ((HV_HYP_PAGE_SIZE >> 1) << 3) /* The value here must be in multiple of 32 */ -#define MAX_NUM_CHANNELS_SUPPORTED_DEFAULT 256 +#define MAX_NUM_CHANNELS_SUPPORTED_DEFAULT (CONFIG_HYPERV_VMBUS_DEFAULT_CHANNELS * 32) extern uint max_num_channels_supported; #define MAX_CHANNEL_RELIDS \ -- 2.20.1
[PATCH 2/3] drivers/hv: fix misleading typo in comment
Fixes a misleading typo in the comment for the macro MAX_NUM_CHANNELS, where two digits have been twisted. Signed-off-by: Stefan Eschenbacher Co-developed-by: Max Stolze Signed-off-by: Max Stolze --- drivers/hv/hyperv_vmbus.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h index edeee1c0497d..52dcfa1c17ef 100644 --- a/drivers/hv/hyperv_vmbus.h +++ b/drivers/hv/hyperv_vmbus.h @@ -187,7 +187,7 @@ int hv_ringbuffer_read(struct vmbus_channel *channel, u64 *requestid, bool raw); /* - * The Maximum number of channels (16348) is determined by the size of the + * The Maximum number of channels (16384) is determined by the size of the * interrupt page, which is HV_HYP_PAGE_SIZE. 1/2 of HV_HYP_PAGE_SIZE is to * send endpoint interrupts, and the other is to receive endpoint interrupts. */ -- 2.20.1
Re: [PATCH 3/8] Documentation: HID: hiddev editing & corrections
On Thu, 3 Dec 2020 22:20:17 -0800 Randy Dunlap wrote: > Do basic editing & correction to hiddev.rst: > - use HID instead of hid consistently One case inline, where I think the usage of hid-core might have been deliberate. > - add hyphenation of multi-word adjectives > - drop a duplicate word > - unhyphenate "a priori" > > > Signed-off-by: Randy Dunlap > Cc: Jiri Kosina > Cc: Benjamin Tissoires > Cc: linux-in...@vger.kernel.org > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > --- > Documentation/hid/hiddev.rst | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > --- linux-next-20201201.orig/Documentation/hid/hiddev.rst > +++ linux-next-20201201/Documentation/hid/hiddev.rst > @@ -27,7 +27,7 @@ the following:: >--> hiddev.c > POWER / MONITOR CONTROL > > In addition, other subsystems (apart from USB) can potentially feed > -events into the input subsystem, but these have no effect on the hid > +events into the input subsystem, but these have no effect on the HID > device interface. > > Using the HID Device Interface > @@ -72,8 +72,8 @@ The hiddev API uses a read() interface, > > HID devices exchange data with the host computer using data > bundles called "reports". Each report is divided into "fields", > -each of which can have one or more "usages". In the hid-core, > -each one of these usages has a single signed 32 bit value. > +each of which can have one or more "usages". In the HID core, Hmm. hid-core is (I think) kind of referring to the code in hid-core.c Whereas a Human Interface Device core (HID core) sounds like something different. Not my doc though! > +each one of these usages has a single signed 32-bit value. > > read(): > --- > @@ -113,7 +113,7 @@ HIDIOCAPPLICATION >- (none) > > This ioctl call returns the HID application usage associated with the > -hid device. The third argument to ioctl() specifies which application > +HID device. The third argument to ioctl() specifies which application > index to get. This is useful when the device has more than one > application collection. If the index is invalid (greater or equal to > the number of application collections this device has) the ioctl > @@ -181,7 +181,7 @@ looked up by type (input, output or feat > must be filled in by the user. The ID can be absolute -- the actual > report id as reported by the device -- or relative -- > HID_REPORT_ID_FIRST for the first report, and (HID_REPORT_ID_NEXT | > -report_id) for the next report after report_id. Without a-priori > +report_id) for the next report after report_id. Without a priori > information about report ids, the right way to use this ioctl is to > use the relative IDs above to enumerate the valid IDs. The ioctl > returns non-zero when there is no more next ID. The real report ID is > @@ -200,7 +200,7 @@ HIDIOCGUCODE >- struct hiddev_usage_ref (read/write) > > Returns the usage_code in a hiddev_usage_ref structure, given that > -given its report type, report id, field index, and index within the > +its report type, report id, field index, and index within the > field have already been filled into the structure. > > HIDIOCGUSAGE
[PATCH 6/9] mm: memcontrol: convert NR_SHMEM_THPS account to pages
Convert NR_SHMEM_THPS account to pages
Signed-off-by: Muchun Song
---
drivers/base/node.c | 3 +--
fs/proc/meminfo.c | 2 +-
mm/filemap.c| 2 +-
mm/huge_memory.c| 3 ++-
mm/khugepaged.c | 2 +-
mm/memcontrol.c | 26 ++
mm/page_alloc.c | 2 +-
mm/shmem.c | 3 ++-
8 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index f6a9521bbcf8..a64f9c5484a0 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -462,8 +462,7 @@ static ssize_t node_read_meminfo(struct device *dev,
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
,
nid, K(node_page_state(pgdat, NR_ANON_THPS)),
-nid, K(node_page_state(pgdat, NR_SHMEM_THPS) *
- HPAGE_PMD_NR),
+nid, K(node_page_state(pgdat, NR_SHMEM_THPS)),
nid, K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED) *
HPAGE_PMD_NR),
nid, K(node_page_state(pgdat, NR_FILE_THPS)),
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 9b2cb770326e..574779b6e48c 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -131,7 +131,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
show_val_kb(m, "AnonHugePages: ",
global_node_page_state(NR_ANON_THPS));
show_val_kb(m, "ShmemHugePages: ",
- global_node_page_state(NR_SHMEM_THPS) * HPAGE_PMD_NR);
+ global_node_page_state(NR_SHMEM_THPS));
show_val_kb(m, "ShmemPmdMapped: ",
global_node_page_state(NR_SHMEM_PMDMAPPED) * HPAGE_PMD_NR);
show_val_kb(m, "FileHugePages: ",
diff --git a/mm/filemap.c b/mm/filemap.c
index c4dcb1144883..5fdefbbc1bc2 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -204,7 +204,7 @@ static void unaccount_page_cache_page(struct address_space
*mapping,
if (PageSwapBacked(page)) {
__mod_lruvec_page_state(page, NR_SHMEM, -nr);
if (PageTransHuge(page))
- __dec_lruvec_page_state(page, NR_SHMEM_THPS);
+ __mod_lruvec_page_state(page, NR_SHMEM_THPS,
-HPAGE_PMD_NR);
} else if (PageTransHuge(page)) {
__mod_lruvec_page_state(page, NR_FILE_THPS, -HPAGE_PMD_NR);
filemap_nr_thps_dec(mapping);
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 37840bdeaad0..0e8541bd9f50 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2746,7 +2746,8 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
spin_unlock(_queue->split_queue_lock);
if (mapping) {
if (PageSwapBacked(head))
- __dec_lruvec_page_state(head, NR_SHMEM_THPS);
+ __mod_lruvec_page_state(head, NR_SHMEM_THPS,
+ -HPAGE_PMD_NR);
else
__mod_lruvec_page_state(head, NR_FILE_THPS,
-HPAGE_PMD_NR);
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 1e1ced2208d0..4fe79ccfc312 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1857,7 +1857,7 @@ static void collapse_file(struct mm_struct *mm,
}
if (is_shmem)
- __inc_lruvec_page_state(new_page, NR_SHMEM_THPS);
+ __mod_lruvec_page_state(new_page, NR_SHMEM_THPS, HPAGE_PMD_NR);
else {
__mod_lruvec_page_state(new_page, NR_FILE_THPS, HPAGE_PMD_NR);
filemap_nr_thps_inc(mapping);
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index dce76dddac61..48d70c1ad301 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1497,7 +1497,7 @@ struct memory_stat {
unsigned int idx;
};
-static struct memory_stat memory_stats[] = {
+static const struct memory_stat memory_stats[] = {
{ "anon", PAGE_SIZE, NR_ANON_MAPPED },
{ "file", PAGE_SIZE, NR_FILE_PAGES },
{ "kernel_stack", 1, NR_KERNEL_STACK_B },
@@ -1508,14 +1508,9 @@ static struct memory_stat memory_stats[] = {
{ "file_dirty", PAGE_SIZE, NR_FILE_DIRTY },
{ "file_writeback", PAGE_SIZE, NR_WRITEBACK },
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- /*
-* The ratio will be initialized in memory_stats_init(). Because
-* on some architectures, the macro of HPAGE_PMD_SIZE is not
-* constant(e.g. powerpc).
-*/
{ "anon_thp", PAGE_SIZE, NR_ANON_THPS },
{ "file_thp", PAGE_SIZE, NR_FILE_THPS },
- { "shmem_thp", 0, NR_SHMEM_THPS },
+ { "shmem_thp", PAGE_SIZE, NR_SHMEM_THPS },
#endif
{ "inactive_anon", PAGE_SIZE, NR_INACTIVE_ANON },
{ "active_anon", PAGE_SIZE, NR_ACTIVE_ANON },
@@ -1540,23 +1535,6 @@ static struct memory_stat
Re: [PATCH v2 5/5] arm64: dts: meson: g12b: w400: fix PHY deassert timing requirements
On Tue, Dec 1, 2020 at 2:21 PM Stefan Agner wrote:
>
> According to the datasheet (Rev. 1.9) the RTL8211F requires at least
> 72ms "for internal circuits settling time" before accessing the PHY
> egisters. On similar boards with the same PHY this fixes an issue where
> Ethernet link would not come up when using ip link set down/up.
>
> Fixes: 2cd2310fca4c ("arm64: dts: meson-g12b-ugoos-am6: add initial
> device-tree")
> Signed-off-by: Stefan Agner
with the "registers" typo above fixed:
Reviewed-by: Martin Blumenstingl
[PATCH net v1 2/2] net: dsa: microchip: improve port count comments
From: Sven Van Asbroeck
Port counts in microchip dsa drivers can be quite confusing:
on the ksz8795, ksz_chip_data->port_cnt excludes the cpu port,
yet on the ksz9477, it includes the cpu port.
Add comments to document this situation explicitly.
Fixes: 912aae27c6af ("net: dsa: microchip: really look for phy-mode in port
nodes")
Signed-off-by: Sven Van Asbroeck
---
Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git # 905b2032fa42
To: Woojung Huh
To: Microchip Linux Driver Support
To: Andrew Lunn
To: Vivien Didelot
To: Florian Fainelli
To: Vladimir Oltean
To: "David S. Miller"
To: Jakub Kicinski
Cc: Helmut Grohne
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
drivers/net/dsa/microchip/ksz8795.c | 12 +---
drivers/net/dsa/microchip/ksz9477.c | 16
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz8795.c
b/drivers/net/dsa/microchip/ksz8795.c
index f5779e152377..99183347053f 100644
--- a/drivers/net/dsa/microchip/ksz8795.c
+++ b/drivers/net/dsa/microchip/ksz8795.c
@@ -1190,7 +1190,9 @@ static const struct ksz_chip_data ksz8795_switch_chips[]
= {
.num_alus = 0,
.num_statics = 8,
.cpu_ports = 0x10, /* can be configured as cpu port */
- .port_cnt = 4, /* total physical port count */
+ .port_cnt = 4, /* total physical port count, excluding
+* the cpu port
+*/
},
{
.chip_id = 0x8794,
@@ -1199,7 +1201,9 @@ static const struct ksz_chip_data ksz8795_switch_chips[]
= {
.num_alus = 0,
.num_statics = 8,
.cpu_ports = 0x10, /* can be configured as cpu port */
- .port_cnt = 3, /* total physical port count */
+ .port_cnt = 3, /* total physical port count, excluding
+* the cpu port
+*/
},
{
.chip_id = 0x8765,
@@ -1208,7 +1212,9 @@ static const struct ksz_chip_data ksz8795_switch_chips[]
= {
.num_alus = 0,
.num_statics = 8,
.cpu_ports = 0x10, /* can be configured as cpu port */
- .port_cnt = 4, /* total physical port count */
+ .port_cnt = 4, /* total physical port count, excluding
+* the cpu port
+*/
},
};
diff --git a/drivers/net/dsa/microchip/ksz9477.c
b/drivers/net/dsa/microchip/ksz9477.c
index 2f5506ac7d19..e56122ffd495 100644
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@ -1482,7 +1482,9 @@ static const struct ksz_chip_data ksz9477_switch_chips[]
= {
.num_alus = 4096,
.num_statics = 16,
.cpu_ports = 0x7F, /* can be configured as cpu port */
- .port_cnt = 7, /* total physical port count */
+ .port_cnt = 7, /* total physical port count, including
+* the cpu port
+*/
.phy_errata_9477 = true,
},
{
@@ -1492,7 +1494,9 @@ static const struct ksz_chip_data ksz9477_switch_chips[]
= {
.num_alus = 4096,
.num_statics = 16,
.cpu_ports = 0x7F, /* can be configured as cpu port */
- .port_cnt = 7, /* total physical port count */
+ .port_cnt = 7, /* total physical port count, including
+* the cpu port
+*/
.phy_errata_9477 = true,
},
{
@@ -1502,7 +1506,9 @@ static const struct ksz_chip_data ksz9477_switch_chips[]
= {
.num_alus = 4096,
.num_statics = 16,
.cpu_ports = 0x07, /* can be configured as cpu port */
- .port_cnt = 3, /* total port count */
+ .port_cnt = 3, /* total physical port count, including
+* the cpu port
+*/
},
{
.chip_id = 0x00956700,
@@ -1511,7 +1517,9 @@ static const struct ksz_chip_data ksz9477_switch_chips[]
= {
.num_alus = 4096,
.num_statics = 16,
.cpu_ports = 0x7F, /* can be configured as cpu port */
- .port_cnt = 7, /* total physical port count */
+ .port_cnt = 7, /* total physical port count, including
+* the cpu port
+*/
},
};
--
2.17.1
Re: [PATCH v2 4/5] arm64: dts: meson: g12a: x96-max: fix PHY deassert timing requirements
On Tue, Dec 1, 2020 at 2:21 PM Stefan Agner wrote:
>
> According to the datasheet (Rev. 1.9) the RTL8211F requires at least
> 72ms "for internal circuits settling time" before accessing the PHY
> egisters. On similar boards with the same PHY this fixes an issue where
> Ethernet link would not come up when using ip link set down/up.
>
> Fixes: ed5e8f689154 ("arm64: dts: meson: g12a: x96-max: fix the Ethernet PHY
> reset line")
> Signed-off-by: Stefan Agner
with the "registers" typo above fixed:
Reviewed-by: Martin Blumenstingl
Re: [External] Re: [PATCH 5/9] mm: memcontrol: convert NR_FILE_THPS account to pages
On Sat, Dec 5, 2020 at 10:09 PM Greg KH wrote: > > On Sat, Dec 05, 2020 at 09:02:20PM +0800, Muchun Song wrote: > > Converrt NR_FILE_THPS account to pages. > > > > Signed-off-by: Muchun Song > > --- > > drivers/base/node.c | 3 +-- > > fs/proc/meminfo.c | 2 +- > > mm/filemap.c| 2 +- > > mm/huge_memory.c| 3 ++- > > mm/khugepaged.c | 2 +- > > mm/memcontrol.c | 5 ++--- > > 6 files changed, 8 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/base/node.c b/drivers/base/node.c > > index 05c369e93e16..f6a9521bbcf8 100644 > > --- a/drivers/base/node.c > > +++ b/drivers/base/node.c > > @@ -466,8 +466,7 @@ static ssize_t node_read_meminfo(struct device *dev, > > HPAGE_PMD_NR), > >nid, K(node_page_state(pgdat, > > NR_SHMEM_PMDMAPPED) * > > HPAGE_PMD_NR), > > - nid, K(node_page_state(pgdat, NR_FILE_THPS) * > > - HPAGE_PMD_NR), > > + nid, K(node_page_state(pgdat, NR_FILE_THPS)), > > Again, is this changing a user-visable value? > Of course not. In the previous, the NR_FILE_THPS account is like below: __mod_lruvec_page_state(page, NR_FILE_THPS, 1); With this patch, it is: __mod_lruvec_page_state(page, NR_FILE_THPS, HPAGE_PMD_NR); So the result is not changed from the view of user space. Thanks. -- Yours, Muchun
RE: [PATCH 0/3] drivers/hv: make max_num_channels_supported configurable
From: Stefan Eschenbacher > > According to the TODO comment in hyperv_vmbus.h the value in macro > MAX_NUM_CHANNELS_SUPPORTED should be configurable. The first patch > accomplishes that by introducting uint max_num_channels_supported as > module parameter. > Also macro MAX_NUM_CHANNELS_SUPPORTED_DEFAULT is introduced with > value 256, which is the currently used macro value. > MAX_NUM_CHANNELS_SUPPORTED was found and replaced in two locations. > > During module initialization sanity checks are applied which will result > in EINVAL or ERANGE if the given value is no multiple of 32 or larger than > MAX_NUM_CHANNELS. > > While testing, we found a misleading typo in the comment for the macro > MAX_NUM_CHANNELS which is fixed by the second patch. > > The third patch makes the added default macro configurable by > introduction and use of Kconfig parameter HYPERV_VMBUS_DEFAULT_CHANNELS. > Default value remains at 256. > > Two notes on these patches: > 1) With above patches it is valid to configure max_num_channels_supported > and MAX_NUM_CHANNELS_SUPPORTED_DEFAULT as 0. We simply don't know if that > is a valid value. Doing so while testing still left us with a working > Debian VM in Hyper-V on Windows 10. > 2) To set the Kconfig parameter the user currently has to divide the > desired default number of channels by 32 and enter the result of that > calculation. This way both known constraints we got from the comments in > the code are enforced. It feels a bit unintuitive though. We haven't found > Kconfig options to ensure that the value is a multiple of 32. So if you'd > like us to fix that we'd be happy for some input on how to settle it with > Kconfig. > > Signed-off-by: Stefan Eschenbacher > Co-developed-by: Max Stolze > Signed-off-by: Max Stolze > > Stefan Eschenbacher (3): > drivers/hv: make max_num_channels_supported configurable > drivers/hv: fix misleading typo in comment > drivers/hv: add default number of vmbus channels to Kconfig > > drivers/hv/Kconfig| 13 + > drivers/hv/hyperv_vmbus.h | 8 > drivers/hv/vmbus_drv.c| 20 +++- > 3 files changed, 36 insertions(+), 5 deletions(-) > > -- > 2.20.1 Stefan -- this cover letter email came through, but it doesn't look like the individual patch emails did. So you might want to check your patch sending process. Thanks for your interest in this old "TODO" item. But let me provide some additional background. Starting in Windows 8 and Windows Server 2012, Hyper-V revised the mechanism by which channel interrupt notifications are made. The MAX_NUM_CHANNELS_SUPPORTED value is only used with Windows 7 and Windows Server 2008 R2, neither of which is officially supported any longer. See the code at the top of vmbus_chan_sched() where the VMBus protocol version is checked, and MAX_NUM_CHANNELS_SUPPORTED is used only when the protocol version indicates we're running on Windows 7 (or the equivalent Windows Server 2008 R2). Because the old mechanism was superseded, making the value configurable doesn't have any benefit. At some point, we will remove this old code path entirely, including the #define MAX_NUM_CHANNELS_SUPPORTED. The comment with the "TODO" could be removed, but other than that, I don't think we want to make these changes. Michael
[GIT PULL] SCSI fixes for 5.10-rc6
Four small fixes in two drivers. The mpt3sas fixes are all timeout
under unusual conditions problems and the storvsc is a missed incoming
packet validation and a missed error return.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Andrea Parri (Microsoft) (1):
scsi: storvsc: Validate length of incoming packet in
storvsc_on_channel_callback()
Jing Xiangfeng (1):
scsi: storvsc: Fix error return in storvsc_probe()
Sreekanth Reddy (1):
scsi: mpt3sas: Increase IOCInit request timeout to 30s
Suganath Prabu S (1):
scsi: mpt3sas: Fix ioctl timeout
And the diffstat:
drivers/scsi/mpt3sas/mpt3sas_base.c | 2 +-
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 2 +-
drivers/scsi/storvsc_drv.c | 9 -
3 files changed, 10 insertions(+), 3 deletions(-)
With full diff below.
James
---
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index e4cc92bc4d94..bb940cbcbb5d 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -6459,7 +6459,7 @@ _base_send_ioc_init(struct MPT3SAS_ADAPTER *ioc)
r = _base_handshake_req_reply_wait(ioc,
sizeof(Mpi2IOCInitRequest_t), (u32 *)_request,
- sizeof(Mpi2IOCInitReply_t), (u16 *)_reply, 10);
+ sizeof(Mpi2IOCInitReply_t), (u16 *)_reply, 30);
if (r != 0) {
ioc_err(ioc, "%s: handshake failed (r=%d)\n", __func__, r);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index 0f2b681449e6..edd26a2570fa 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -664,7 +664,7 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc, struct
mpt3_ioctl_command karg,
Mpi26NVMeEncapsulatedRequest_t *nvme_encap_request = NULL;
struct _pcie_device *pcie_device = NULL;
u16 smid;
- u8 timeout;
+ unsigned long timeout;
u8 issue_reset;
u32 sz, sz_arg;
void *psge;
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 0c65fbd41035..99c8ff81de74 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1246,6 +1246,11 @@ static void storvsc_on_channel_callback(void *context)
request = (struct storvsc_cmd_request *)
((unsigned long)desc->trans_id);
+ if (hv_pkt_datalen(desc) < sizeof(struct vstor_packet) -
vmscsi_size_delta) {
+ dev_err(>device, "Invalid packet len\n");
+ continue;
+ }
+
if (request == _device->init_request ||
request == _device->reset_request) {
memcpy(>vstor_packet, packet,
@@ -1994,8 +1999,10 @@ static int storvsc_probe(struct hv_device *device,
alloc_ordered_workqueue("storvsc_error_wq_%d",
WQ_MEM_RECLAIM,
host->host_no);
- if (!host_dev->handle_error_wq)
+ if (!host_dev->handle_error_wq) {
+ ret = -ENOMEM;
goto err_out2;
+ }
INIT_WORK(_dev->host_scan_work, storvsc_host_scan);
/* Register the HBA and start the scsi bus scan */
ret = scsi_add_host(host, >device);
[PATCH net v1 1/2] net: dsa: microchip: fix devicetree parsing of cpu node
From: Sven Van Asbroeck
On the ksz8795, if the devicetree contains a cpu node,
devicetree parsing fails and the whole driver errors out.
Fix the devicetree parsing code by making it use the
correct number of ports.
Fixes: 912aae27c6af ("net: dsa: microchip: really look for phy-mode in port
nodes")
Tested-by: Sven Van Asbroeck # ksz8795
Signed-off-by: Sven Van Asbroeck
---
Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git # 905b2032fa42
To: Woojung Huh
To: Microchip Linux Driver Support
To: Andrew Lunn
To: Vivien Didelot
To: Florian Fainelli
To: Vladimir Oltean
To: "David S. Miller"
To: Jakub Kicinski
Cc: Helmut Grohne
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
drivers/net/dsa/microchip/ksz_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/microchip/ksz_common.c
b/drivers/net/dsa/microchip/ksz_common.c
index e5f047129b15..17b804c44c53 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -431,7 +431,7 @@ int ksz_switch_register(struct ksz_device *dev,
if (of_property_read_u32(port, "reg",
_num))
continue;
- if (port_num >= dev->port_cnt)
+ if (port_num >= dev->ds->num_ports)
return -EINVAL;
of_get_phy_mode(port,
>ports[port_num].interface);
--
2.17.1
[PATCH 5/8] tty: serial: jsm: Fixed file by added more spacing in line 614
Fixed a coding style issue Signed-off-by: Clement Smith --- drivers/tty/serial/jsm/jsm_tty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c index 45e212be64c4..75c9bfa5077c 100644 --- a/drivers/tty/serial/jsm/jsm_tty.c +++ b/drivers/tty/serial/jsm/jsm_tty.c @@ -611,7 +611,7 @@ void jsm_input(struct jsm_channel *ch) tty_insert_flip_char(port, *(ch->ch_rqueue + tail + i), TTY_BREAK); else if (*(ch->ch_equeue + tail + i) & UART_LSR_PE) tty_insert_flip_char(port, *(ch->ch_rqueue + tail + i), TTY_PARITY); - else if (*(ch->ch_equeue +tail +i) & UART_LSR_FE) + else if (*(ch->ch_equeue + tail + i) & UART_LSR_FE) tty_insert_flip_char(port, *(ch->ch_rqueue +tail +i), TTY_FRAME); else tty_insert_flip_char(port, *(ch->ch_rqueue +tail +i), TTY_NORMAL); -- 2.27.0
Re:
On Sat, Dec 5, 2020 at 3:10 AM Rasmus Villemoes wrote: > > On 03/12/2020 19.46, Yury Norov wrote: > > > I would prefer to avoid changing the find*bit() semantics. As for now, > > if any of find_*_bit() > > finds nothing, it returns the size of the bitmap it was passed. > > Yeah, we should actually try to fix that, it causes bad code generation. > It's hard, because callers of course do that "if ret == size" check. But > it's really silly that something like find_first_bit needs to do that > "min(i*BPL + __ffs(word), size)" - the caller does a comparison anyway, > that comparison might as well be "ret >= size" rather than "ret == > size", and then we could get rid of that branch (which min() necessarily > becomes) at the end of find_next_bit. We didn't do that 5 years ago because it's too invasive and the improvement is barely measurable, the difference is 2 instructions (on arm64).e. Has something changed since that? 2 : 0: aa0003e3mov x3, x0 4: aa0103e0mov x0, x1 8: b4000181cbz x1, 38 c: f9400064ldr x4, [x3] 10: d2800802mov x2, #0x40 // #64 14: 91002063add x3, x3, #0x8 18: b4c4cbz x4, 30 1c: 1408b 3c 20: f8408464ldr x4, [x3], #8 24: 91010045add x5, x2, #0x40 28: b5c4cbnzx4, 40 2c: aa0503e2mov x2, x5 30: eb5fcmp x2, x0 34: 5463b.cc20 // b.lo, b.ul, b.last 38: d65f03c0ret 3c: d282mov x2, #0x0// #0 40: dac00084rbitx4, x4 44: dac01084clz x4, x4 48: 8b020080add x0, x4, x2 4c: d65f03c0ret 0050 : 50: aa0003e4mov x4, x0 54: aa0103e0mov x0, x1 58: b4000181cbz x1, 88 5c: f9400083ldr x3, [x4] 60: d2800802mov x2, #0x40 // #64 64: 91002084add x4, x4, #0x8 68: b4c3cbz x3, 80 6c: 1408b 8c 70: f8408483ldr x3, [x4], #8 74: 91010045add x5, x2, #0x40 78: b5c3cbnzx3, 90 7c: aa0503e2mov x2, x5 80: eb02001fcmp x0, x2 84: 5468b.hi70 // b.pmore 88: d65f03c0ret 8c: d282mov x2, #0x0// #0 90: dac00063rbitx3, x3 94: dac01063clz x3, x3 98: 8b020062add x2, x3, x2 9c: eb02001fcmp x0, x2 a0: 9a829000cselx0, x0, x2, ls // ls = plast a4: d65f03c0ret > I haven't dug very deep into this, but I could also imagine the > arch-specific parts of this might become a little easier to do if the > semantics were just "if no such bit, return an indeterminate value >= > the size". > > > Changing this for > > a single function would break the consistency, and may cause problems > > for those who > > rely on existing behaviour. > > True. But I think it should be possible - I suppose most users are via > the iterator macros, which could all be updated at once. Changing ret == > size to ret >= size will still work even if the implementations have not > been switched over, so it should be doable. Since there's no assembler users for it, we can do just: #define find_first_bit(bitmap, size) min(better_find_first_bit((bitmap), (size)), (size)) ... and deprecate find_first_bit. > > Passing non-positive size to find_*_bit() should produce undefined > > behaviour, because we cannot dereference a pointer to the bitmap in > > this case; this is most probably a sign of a problem on a caller side > > anyways. > > No, the out-of-line bitmap functions should all handle the case of a > zero-size bitmap sensibly. I could be more specific, the behaviour is defined: don't dereference the address and return undefined value (which now is always 0). > Is bitmap full? Yes (all the 0 bits are set). > Is bitmap empty? Yes, (none of the 0 bits are set). > Find the first bit set (returns 0, there's no such bit) I can't answer because this object is not a map of bits - there's no room for bits inside. > Etc. The static inlines for small_const_nbits do assume that the pointer > can be dereferenced, which is why small_const_nbits was updated to mean > 1<=bits<=BITS_PER_LONG rather than just bits<=BITS_PER_LONG. I don't want to do something like if (size == 0) return -1; ... because it legitimizes this kind of usage and hides problems on callers' side. Instead, I'd add WARN_ON(size == 0), but I don't think it's so critical to bother with it. Yury > Rasmus
[PATCH 8/9] mm: memcontrol: convert NR_FILE_PMDMAPPED account to pages
Convert NR_FILE_PMDMAPPED account to pages
Signed-off-by: Muchun Song
---
drivers/base/node.c | 3 +--
fs/proc/meminfo.c | 2 +-
mm/rmap.c | 6 --
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index fe90888f90a8..679215cdeb87 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -465,8 +465,7 @@ static ssize_t node_read_meminfo(struct device *dev,
nid, K(node_page_state(pgdat, NR_SHMEM_THPS)),
nid, K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED)),
nid, K(node_page_state(pgdat, NR_FILE_THPS)),
-nid, K(node_page_state(pgdat, NR_FILE_PMDMAPPED) *
- HPAGE_PMD_NR)
+nid, K(node_page_state(pgdat, NR_FILE_PMDMAPPED))
#endif
);
len += hugetlb_report_node_meminfo(buf, len, nid);
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index b2bff8359497..a0828df01721 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -137,7 +137,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
show_val_kb(m, "FileHugePages: ",
global_node_page_state(NR_FILE_THPS));
show_val_kb(m, "FilePmdMapped: ",
- global_node_page_state(NR_FILE_PMDMAPPED) * HPAGE_PMD_NR);
+ global_node_page_state(NR_FILE_PMDMAPPED));
#endif
#ifdef CONFIG_CMA
diff --git a/mm/rmap.c b/mm/rmap.c
index 3089ad6bf468..e383c5619501 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1222,7 +1222,8 @@ void page_add_file_rmap(struct page *page, bool compound)
__mod_lruvec_page_state(page, NR_SHMEM_PMDMAPPED,
HPAGE_PMD_NR);
else
- __inc_node_page_state(page, NR_FILE_PMDMAPPED);
+ __mod_lruvec_page_state(page, NR_FILE_PMDMAPPED,
+ HPAGE_PMD_NR);
} else {
if (PageTransCompound(page) && page_mapping(page)) {
VM_WARN_ON_ONCE(!PageLocked(page));
@@ -1264,7 +1265,8 @@ static void page_remove_file_rmap(struct page *page, bool
compound)
__mod_lruvec_page_state(page, NR_SHMEM_PMDMAPPED,
-HPAGE_PMD_NR);
else
- __dec_node_page_state(page, NR_FILE_PMDMAPPED);
+ __mod_lruvec_page_state(page, NR_FILE_PMDMAPPED,
+ -HPAGE_PMD_NR);
} else {
if (!atomic_add_negative(-1, >_mapcount))
return;
--
2.11.0
Re: [PATCH] arm64: dts: meson: fix spi-max-frequency on Khadas VIM2
On Wed, Nov 25, 2020 at 3:40 AM Christian Hewitt
wrote:
>
> From: Artem Lapkin
>
> The max frequency for the w25q32 (VIM v1.2) and w25q128 (VIM v1.4) spifc
> chip should be 104Mhz not 30MHz.
>
> Fixes: b8b74dda3908 ("ARM64: dts: meson-gxm: Add support for Khadas VIM2")
> Signed-off-by: Artem Lapkin
Reviewed-by: Martin Blumenstingl
[PATCH 9/9] mm: memcontrol: make the slab calculation consistent
Although the ratio of the slab is one, we also should read the ratio
from the related memory_stats instead of hard-coding. And the local
variable of size is already the value of slab_unreclaimable. So we
do not need to read again.
Signed-off-by: Muchun Song
---
mm/memcontrol.c | 112 +---
1 file changed, 74 insertions(+), 38 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 48d70c1ad301..0e9e8ca7e770 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1493,48 +1493,75 @@ static bool mem_cgroup_wait_acct_move(struct mem_cgroup
*memcg)
struct memory_stat {
const char *name;
- unsigned int ratio;
unsigned int idx;
};
static const struct memory_stat memory_stats[] = {
- { "anon", PAGE_SIZE, NR_ANON_MAPPED },
- { "file", PAGE_SIZE, NR_FILE_PAGES },
- { "kernel_stack", 1, NR_KERNEL_STACK_B },
- { "percpu", 1, MEMCG_PERCPU_B },
- { "sock", PAGE_SIZE, MEMCG_SOCK },
- { "shmem", PAGE_SIZE, NR_SHMEM },
- { "file_mapped", PAGE_SIZE, NR_FILE_MAPPED },
- { "file_dirty", PAGE_SIZE, NR_FILE_DIRTY },
- { "file_writeback", PAGE_SIZE, NR_WRITEBACK },
+ { "anon", NR_ANON_MAPPED },
+ { "file", NR_FILE_PAGES },
+ { "kernel_stack", NR_KERNEL_STACK_B },
+ { "percpu", MEMCG_PERCPU_B },
+ { "sock", MEMCG_SOCK },
+ { "shmem", NR_SHMEM},
+ { "file_mapped",NR_FILE_MAPPED },
+ { "file_dirty", NR_FILE_DIRTY },
+ { "file_writeback", NR_WRITEBACK},
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- { "anon_thp", PAGE_SIZE, NR_ANON_THPS },
- { "file_thp", PAGE_SIZE, NR_FILE_THPS },
- { "shmem_thp", PAGE_SIZE, NR_SHMEM_THPS },
+ { "anon_thp", NR_ANON_THPS},
+ { "file_thp", NR_FILE_THPS},
+ { "shmem_thp", NR_SHMEM_THPS },
#endif
- { "inactive_anon", PAGE_SIZE, NR_INACTIVE_ANON },
- { "active_anon", PAGE_SIZE, NR_ACTIVE_ANON },
- { "inactive_file", PAGE_SIZE, NR_INACTIVE_FILE },
- { "active_file", PAGE_SIZE, NR_ACTIVE_FILE },
- { "unevictable", PAGE_SIZE, NR_UNEVICTABLE },
-
- /*
-* Note: The slab_reclaimable and slab_unreclaimable must be
-* together and slab_reclaimable must be in front.
-*/
- { "slab_reclaimable", 1, NR_SLAB_RECLAIMABLE_B },
- { "slab_unreclaimable", 1, NR_SLAB_UNRECLAIMABLE_B },
+ { "inactive_anon", NR_INACTIVE_ANON},
+ { "active_anon",NR_ACTIVE_ANON },
+ { "inactive_file", NR_INACTIVE_FILE},
+ { "active_file",NR_ACTIVE_FILE },
+ { "unevictable",NR_UNEVICTABLE },
+ { "slab_reclaimable", NR_SLAB_RECLAIMABLE_B },
+ { "slab_unreclaimable", NR_SLAB_UNRECLAIMABLE_B },
/* The memory events */
- { "workingset_refault_anon", 1, WORKINGSET_REFAULT_ANON },
- { "workingset_refault_file", 1, WORKINGSET_REFAULT_FILE },
- { "workingset_activate_anon", 1, WORKINGSET_ACTIVATE_ANON },
- { "workingset_activate_file", 1, WORKINGSET_ACTIVATE_FILE },
- { "workingset_restore_anon", 1, WORKINGSET_RESTORE_ANON },
- { "workingset_restore_file", 1, WORKINGSET_RESTORE_FILE },
- { "workingset_nodereclaim", 1, WORKINGSET_NODERECLAIM },
+ { "workingset_refault_anon",WORKINGSET_REFAULT_ANON },
+ { "workingset_refault_file",WORKINGSET_REFAULT_FILE },
+ { "workingset_activate_anon", WORKINGSET_ACTIVATE_ANON},
+ { "workingset_activate_file", WORKINGSET_ACTIVATE_FILE},
+ { "workingset_restore_anon",WORKINGSET_RESTORE_ANON },
+ { "workingset_restore_file",WORKINGSET_RESTORE_FILE },
+ { "workingset_nodereclaim", WORKINGSET_NODERECLAIM },
};
+/* Translate stat items to the correct unit for memory.stat output */
+static int memcg_page_state_unit(int item)
+{
+ int unit;
+
+ switch (item) {
+ case NR_SLAB_RECLAIMABLE_B:
+ case NR_SLAB_UNRECLAIMABLE_B:
+ case WORKINGSET_REFAULT_ANON:
+ case WORKINGSET_REFAULT_FILE:
+ case WORKINGSET_ACTIVATE_ANON:
+ case WORKINGSET_ACTIVATE_FILE:
+ case WORKINGSET_RESTORE_ANON:
+ case WORKINGSET_RESTORE_FILE:
+ case WORKINGSET_NODERECLAIM:
+ case MEMCG_PERCPU_B:
+ case NR_KERNEL_STACK_B:
+ unit
[PATCH 1/8] tty: serial: jsm: Fixed file by added more spacing in line 610
Fixed a coding style issue Signed-off-by: Clement Smith --- drivers/tty/serial/jsm/jsm_tty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c index 689774c073ca..512b77195e9f 100644 --- a/drivers/tty/serial/jsm/jsm_tty.c +++ b/drivers/tty/serial/jsm/jsm_tty.c @@ -607,7 +607,7 @@ void jsm_input(struct jsm_channel *ch) * Give the Linux ld the flags in the * format it likes. */ - if (*(ch->ch_equeue +tail +i) & UART_LSR_BI) + if (*(ch->ch_equeue + tail + i) & UART_LSR_BI) tty_insert_flip_char(port, *(ch->ch_rqueue +tail +i), TTY_BREAK); else if (*(ch->ch_equeue +tail +i) & UART_LSR_PE) tty_insert_flip_char(port, *(ch->ch_rqueue +tail +i), TTY_PARITY); -- 2.27.0
Re: [PATCH v2] arm64: dts: meson-sm1: fix typo in opp table
On Mon, Nov 30, 2020 at 7:04 AM Dongjin Kim wrote: > > The freqency 151200 should be 15. there's a typo in "frequency". I hope that Kevin can fix this up while applying the patch > > Signed-off-by: Dongjin Kim apart from the typo above: Reviewed-by: Martin Blumenstingl (while reviewing I noticed that we generally use 0.3V less for each OPP table step than the downstream kvim3l.dts - that's a discussion we need to have elsewhere though)
