[v3 03/11] arm64: dts: ls1046a: add DT node for external interrupt lines
From: Biwen Li
Add device-tree node for external interrupt lines IRQ0-IRQ11.
Signed-off-by: Biwen Li
---
Change in v3:
- none
Change in v2:
- none
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 0246d975a206..dff3ee84c294 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -3,7 +3,7 @@
* Device Tree Include file for Freescale Layerscape-1046A family SoC.
*
* Copyright 2016 Freescale Semiconductor, Inc.
- * Copyright 2018 NXP
+ * Copyright 2018-2020 NXP
*
* Mingkai Hu
*/
@@ -314,6 +314,31 @@
compatible = "fsl,ls1046a-scfg", "syscon";
reg = <0x0 0x157 0x0 0x1>;
big-endian;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x157 0x1>;
+
+ extirq: interrupt-controller@1ac {
+ compatible = "fsl,ls1046a-extirq",
"fsl,ls1043a-extirq";
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x1ac 4>;
+ interrupt-map =
+ <0 0 &gic GIC_SPI 131
IRQ_TYPE_LEVEL_HIGH>,
+ <1 0 &gic GIC_SPI 132
IRQ_TYPE_LEVEL_HIGH>,
+ <2 0 &gic GIC_SPI 133
IRQ_TYPE_LEVEL_HIGH>,
+ <3 0 &gic GIC_SPI 135
IRQ_TYPE_LEVEL_HIGH>,
+ <4 0 &gic GIC_SPI 136
IRQ_TYPE_LEVEL_HIGH>,
+ <5 0 &gic GIC_SPI 137
IRQ_TYPE_LEVEL_HIGH>,
+ <6 0 &gic GIC_SPI 145
IRQ_TYPE_LEVEL_HIGH>,
+ <7 0 &gic GIC_SPI 146
IRQ_TYPE_LEVEL_HIGH>,
+ <8 0 &gic GIC_SPI 147
IRQ_TYPE_LEVEL_HIGH>,
+ <9 0 &gic GIC_SPI 149
IRQ_TYPE_LEVEL_HIGH>,
+ <10 0 &gic GIC_SPI 150
IRQ_TYPE_LEVEL_HIGH>,
+ <11 0 &gic GIC_SPI 151
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0x 0x0>;
+ };
};
crypto: crypto@170 {
--
2.17.1
[v3 08/11] arm64: dts: ls208xa-rdb: add interrupt line for RTC node
From: Biwen Li
Add interrupt line for RTC node on ls208xa-rdb
Signed-off-by: Biwen Li
---
Change in v3:
- none
Change in v2:
- none
arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
index d0d670227ae2..4b71c4fcb35f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa-rdb.dtsi
@@ -3,7 +3,7 @@
* Device Tree file for Freescale LS2080A RDB Board.
*
* Copyright 2016 Freescale Semiconductor, Inc.
- * Copyright 2017 NXP
+ * Copyright 2017-2020 NXP
*
* Abhimanyu Saini
*
@@ -56,6 +56,8 @@
rtc@68 {
compatible = "dallas,ds3232";
reg = <0x68>;
+ /* IRQ_RTC_B -> IRQ06, active low */
+ interrupts-extended = <&extirq 6
IRQ_TYPE_LEVEL_LOW>;
};
};
--
2.17.1
[v3 07/11] arm64: dts: ls208xa: add DT node for external interrupt lines
From: Biwen Li
Add device-tree node for external interrupt lines IRQ0-IRQ11.
Signed-off-by: Biwen Li
---
Change in v3:
- none
Change in v2:
- none
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 41102dacc2e1..f75aa2ce4e2b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -3,7 +3,7 @@
* Device Tree Include file for Freescale Layerscape-2080A family SoC.
*
* Copyright 2016 Freescale Semiconductor, Inc.
- * Copyright 2017 NXP
+ * Copyright 2017-2020 NXP
*
* Abhimanyu Saini
*
@@ -154,6 +154,37 @@
little-endian;
};
+ isc: syscon@1f7 {
+ compatible = "fsl,ls2080a-isc", "syscon";
+ reg = <0x0 0x1f7 0x0 0x1>;
+ little-endian;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x1f7 0x1>;
+
+ extirq: interrupt-controller@14 {
+ compatible = "fsl,ls2080a-extirq",
"fsl,ls1088a-extirq";
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x14 4>;
+ interrupt-map =
+ <0 0 &gic GIC_SPI 0
IRQ_TYPE_LEVEL_HIGH>,
+ <1 0 &gic GIC_SPI 1
IRQ_TYPE_LEVEL_HIGH>,
+ <2 0 &gic GIC_SPI 2
IRQ_TYPE_LEVEL_HIGH>,
+ <3 0 &gic GIC_SPI 3
IRQ_TYPE_LEVEL_HIGH>,
+ <4 0 &gic GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH>,
+ <5 0 &gic GIC_SPI 5
IRQ_TYPE_LEVEL_HIGH>,
+ <6 0 &gic GIC_SPI 6
IRQ_TYPE_LEVEL_HIGH>,
+ <7 0 &gic GIC_SPI 7
IRQ_TYPE_LEVEL_HIGH>,
+ <8 0 &gic GIC_SPI 8
IRQ_TYPE_LEVEL_HIGH>,
+ <9 0 &gic GIC_SPI 9
IRQ_TYPE_LEVEL_HIGH>,
+ <10 0 &gic GIC_SPI 10
IRQ_TYPE_LEVEL_HIGH>,
+ <11 0 &gic GIC_SPI 11
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0x 0x0>;
+ };
+ };
+
tmu: tmu@1f8 {
compatible = "fsl,qoriq-tmu";
reg = <0x0 0x1f8 0x0 0x1>;
--
2.17.1
[v3 05/11] arm64: dts: ls1088a: add DT node for external interrupt lines
From: Biwen Li
Add device-tree node for external interrupt lines IRQ0-IRQ11.
Signed-off-by: Biwen Li
---
Change in v3:
- none
Change in v2:
- none
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 169f4742ae3b..12fe8f079c28 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -2,7 +2,7 @@
/*
* Device Tree Include file for NXP Layerscape-1088A family SoC.
*
- * Copyright 2017 NXP
+ * Copyright 2017-2020 NXP
*
* Harninder Rai
*
@@ -206,6 +206,37 @@
little-endian;
};
+ isc: syscon@1f7 {
+ compatible = "fsl,ls1088a-isc", "syscon";
+ reg = <0x0 0x1f7 0x0 0x1>;
+ little-endian;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x1f7 0x1>;
+
+ extirq: interrupt-controller@14 {
+ compatible = "fsl,ls1088a-extirq";
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x14 4>;
+ interrupt-map =
+ <0 0 &gic GIC_SPI 0
IRQ_TYPE_LEVEL_HIGH>,
+ <1 0 &gic GIC_SPI 1
IRQ_TYPE_LEVEL_HIGH>,
+ <2 0 &gic GIC_SPI 2
IRQ_TYPE_LEVEL_HIGH>,
+ <3 0 &gic GIC_SPI 3
IRQ_TYPE_LEVEL_HIGH>,
+ <4 0 &gic GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH>,
+ <5 0 &gic GIC_SPI 5
IRQ_TYPE_LEVEL_HIGH>,
+ <6 0 &gic GIC_SPI 6
IRQ_TYPE_LEVEL_HIGH>,
+ <7 0 &gic GIC_SPI 7
IRQ_TYPE_LEVEL_HIGH>,
+ <8 0 &gic GIC_SPI 8
IRQ_TYPE_LEVEL_HIGH>,
+ <9 0 &gic GIC_SPI 9
IRQ_TYPE_LEVEL_HIGH>,
+ <10 0 &gic GIC_SPI 10
IRQ_TYPE_LEVEL_HIGH>,
+ <11 0 &gic GIC_SPI 11
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0x 0x0>;
+ };
+ };
+
tmu: tmu@1f8 {
compatible = "fsl,qoriq-tmu";
reg = <0x0 0x1f8 0x0 0x1>;
--
2.17.1
[v3 04/11] arm64: dts: ls1046ardb: Add interrupt line for RTC node
From: Hou Zhiqiang
Add interrupt line for RTC node, which is low level active.
Signed-off-by: Hou Zhiqiang
---
Change in v3:
- none
Change in v2:
- none
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index d53ccc56bb63..60acdf0b689e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -3,6 +3,7 @@
* Device Tree Include file for Freescale Layerscape-1046A family SoC.
*
* Copyright 2016 Freescale Semiconductor, Inc.
+ * Copyright 2019-2020 NXP
*
* Mingkai Hu
*/
@@ -74,6 +75,8 @@
rtc@51 {
compatible = "nxp,pcf2129";
reg = <0x51>;
+ /* IRQ_RTC_B -> IRQ05, active low */
+ interrupts-extended = <&extirq 5 IRQ_TYPE_LEVEL_LOW>;
};
};
--
2.17.1
[v3 06/11] arm64: dts: ls1088ardb: fix interrupt line for RTC node
From: Biwen Li
Fix interrupt line for RTC node on ls1088ardb
Signed-off-by: Biwen Li
---
Change in v3:
- none
Change in v2:
- none
arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index 5633e59febc3..89c40d3f9a50 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -2,7 +2,7 @@
/*
* Device Tree file for NXP LS1088A RDB Board.
*
- * Copyright 2017 NXP
+ * Copyright 2017-2020 NXP
*
* Harninder Rai
*
@@ -51,8 +51,8 @@
rtc@51 {
compatible = "nxp,pcf2129";
reg = <0x51>;
- /* IRQ10_B */
- interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+ /* IRQ_RTC_B -> IRQ0_B(CPLD) -> IRQ00(CPU),
active low */
+ interrupts-extended = <&extirq 0
IRQ_TYPE_LEVEL_LOW>;
};
};
};
--
2.17.1
[v3 02/11] arm64: dts: ls1043a: add DT node for external interrupt lines
From: Biwen Li
Add device-tree node for external interrupt lines IRQ0-IRQ11.
Signed-off-by: Biwen Li
---
Change in v3:
- none
Change in v2:
- none
.../arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 5c2e370f6316..38a6d951ecc5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -3,7 +3,7 @@
* Device Tree Include file for Freescale Layerscape-1043A family SoC.
*
* Copyright 2014-2015 Freescale Semiconductor, Inc.
- * Copyright 2018 NXP
+ * Copyright 2018-2020 NXP
*
* Mingkai Hu
*/
@@ -311,6 +311,31 @@
compatible = "fsl,ls1043a-scfg", "syscon";
reg = <0x0 0x157 0x0 0x1>;
big-endian;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x157 0x1>;
+
+ extirq: interrupt-controller@1ac {
+ compatible = "fsl,ls1043a-extirq";
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x1ac 4>;
+ interrupt-map =
+ <0 0 &gic GIC_SPI 131
IRQ_TYPE_LEVEL_HIGH>,
+ <1 0 &gic GIC_SPI 132
IRQ_TYPE_LEVEL_HIGH>,
+ <2 0 &gic GIC_SPI 133
IRQ_TYPE_LEVEL_HIGH>,
+ <3 0 &gic GIC_SPI 135
IRQ_TYPE_LEVEL_HIGH>,
+ <4 0 &gic GIC_SPI 136
IRQ_TYPE_LEVEL_HIGH>,
+ <5 0 &gic GIC_SPI 137
IRQ_TYPE_LEVEL_HIGH>,
+ <6 0 &gic GIC_SPI 145
IRQ_TYPE_LEVEL_HIGH>,
+ <7 0 &gic GIC_SPI 146
IRQ_TYPE_LEVEL_HIGH>,
+ <8 0 &gic GIC_SPI 147
IRQ_TYPE_LEVEL_HIGH>,
+ <9 0 &gic GIC_SPI 149
IRQ_TYPE_LEVEL_HIGH>,
+ <10 0 &gic GIC_SPI 150
IRQ_TYPE_LEVEL_HIGH>,
+ <11 0 &gic GIC_SPI 151
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0x 0x0>;
+ };
};
crypto: crypto@170 {
--
2.17.1
[v3 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt
From: Hou Zhiqiang
Add an new IRQ chip declaration for LS1043A and LS1088A
- compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A.
- compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA
Signed-off-by: Hou Zhiqiang
Signed-off-by: Biwen Li
---
Change in v3:
- cleanup code
- remove robust copyright
Change in v2:
- add despcription of bit reverse
- update copyright
drivers/irqchip/irq-ls-extirq.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/irqchip/irq-ls-extirq.c b/drivers/irqchip/irq-ls-extirq.c
index 4d1179fed77c..47804ce78b21 100644
--- a/drivers/irqchip/irq-ls-extirq.c
+++ b/drivers/irqchip/irq-ls-extirq.c
@@ -18,7 +18,7 @@
struct ls_extirq_data {
struct regmap *syscon;
u32 intpcr;
- boolbit_reverse;
+ boolis_ls1021a_or_ls1043a;
u32 nirq;
struct irq_fwspec map[MAXIRQ];
};
@@ -30,7 +30,7 @@ ls_extirq_set_type(struct irq_data *data, unsigned int type)
irq_hw_number_t hwirq = data->hwirq;
u32 value, mask;
- if (priv->bit_reverse)
+ if (priv->is_ls1021a_or_ls1043a)
mask = 1U << (31 - hwirq);
else
mask = 1U << hwirq;
@@ -174,14 +174,9 @@ ls_extirq_of_init(struct device_node *node, struct
device_node *parent)
if (ret)
goto out;
- if (of_device_is_compatible(node, "fsl,ls1021a-extirq")) {
- u32 revcr;
-
- ret = regmap_read(priv->syscon, LS1021A_SCFGREVCR, &revcr);
- if (ret)
- goto out;
- priv->bit_reverse = (revcr != 0);
- }
+ if (of_device_is_compatible(node, "fsl,ls1021a-extirq") || \
+ of_device_is_compatible(node, "fsl,ls1043a-extirq"))
+ priv->is_ls1021a_or_ls1043a = true;
domain = irq_domain_add_hierarchy(parent_domain, 0, priv->nirq, node,
&extirq_domain_ops, priv);
@@ -195,3 +190,5 @@ ls_extirq_of_init(struct device_node *node, struct
device_node *parent)
}
IRQCHIP_DECLARE(ls1021a_extirq, "fsl,ls1021a-extirq", ls_extirq_of_init);
+IRQCHIP_DECLARE(ls1043a_extirq, "fsl,ls1043a-extirq", ls_extirq_of_init);
+IRQCHIP_DECLARE(ls1088a_extirq, "fsl,ls1088a-extirq", ls_extirq_of_init);
--
2.17.1
Re: [PATCH v2 10/17] vdpa_sim: store parsed MAC address in a buffer
On 2020/11/26 下午10:49, Stefano Garzarella wrote:
As preparation for the next patches, we store the MAC address,
parsed during the vdpasim_create(), in a buffer that will be used
to fill 'config' together with other configurations.
Signed-off-by: Stefano Garzarella
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
Acked-by: Jason Wang
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index b84d9acd130c..9f2ca3a77025 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -29,6 +29,8 @@ static char *macaddr;
module_param(macaddr, charp, 0);
MODULE_PARM_DESC(macaddr, "Ethernet MAC address");
+u8 macaddr_buf[ETH_ALEN];
+
struct vdpasim_virtqueue {
struct vringh vring;
struct vringh_kiov iov;
@@ -386,13 +388,13 @@ static struct vdpasim *vdpasim_create(struct
vdpasim_dev_attr *dev_attr)
goto err_iommu;
if (macaddr) {
- mac_pton(macaddr, vdpasim->config.mac);
- if (!is_valid_ether_addr(vdpasim->config.mac)) {
+ mac_pton(macaddr, macaddr_buf);
+ if (!is_valid_ether_addr(macaddr_buf)) {
ret = -EADDRNOTAVAIL;
goto err_iommu;
}
} else {
- eth_random_addr(vdpasim->config.mac);
+ eth_random_addr(macaddr_buf);
}
for (i = 0; i < dev_attr->nvqs; i++)
@@ -528,6 +530,8 @@ static int vdpasim_set_features(struct vdpa_device *vdpa,
u64 features)
config->mtu = cpu_to_vdpasim16(vdpasim, 1500);
config->status = cpu_to_vdpasim16(vdpasim, VIRTIO_NET_S_LINK_UP);
+ memcpy(config->mac, macaddr_buf, ETH_ALEN);
+
return 0;
}
Re: [PATCH] posix_acl.h: define missing ACL functions on non-posix-acl build
On (20/11/30 12:15), Sergey Senozhatsky wrote: > On (20/11/29 18:00), Randy Dunlap wrote: > > On 11/29/20 5:44 PM, Sergey Senozhatsky wrote: > > > Some functions that are declared when CONFIG_POSIX_ACL is defined > > > are not declared when CONFIG_POSIX_ACL is not defined. Add the > > > missing ones: > > > set_posix_acl(), posix_acl_update_mode(), get_cached_acl(), > > > get_cached_acl_rcu(), set_cached_acl(), forget_cached_acl(). > > > > > > Signed-off-by: Sergey Senozhatsky > > > > Hi, > > > > I can't find CONFIG_POSIX_ACL in the kernel source tree. > > Should it be CONFIG_FS_POSIX_ACL ? > > Oh, yes, CONFIG_POSIX_ACL. My bad. ... CONFIG_FS_POSIX_ACL. I did it again. -ss
Re: [PATCH v2 08/17] vdpa_sim: add supported_features field in vdpasim_dev_attr
On 2020/11/26 下午10:49, Stefano Garzarella wrote:
Introduce a new VDPASIM_FEATURES macro with the generic features
supported by the vDPA simulator, and VDPASIM_NET_FEATURES macro with
vDPA-net features.
Add 'supported_features' field in vdpasim_dev_attr, to allow devices
to specify their features.
Co-developed-by: Max Gurtovoy
Signed-off-by: Max Gurtovoy
Signed-off-by: Stefano Garzarella
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
Acked-by: Jason Wang
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 393b54a9f0e4..36677fc3631b 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -49,12 +49,15 @@ struct vdpasim_virtqueue {
#define VDPASIM_VQ_NUM 0x2
#define VDPASIM_NAME "vdpasim-netdev"
-static u64 vdpasim_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
- (1ULL << VIRTIO_F_VERSION_1) |
- (1ULL << VIRTIO_F_ACCESS_PLATFORM) |
- (1ULL << VIRTIO_NET_F_MAC);
+#define VDPASIM_FEATURES ((1ULL << VIRTIO_F_ANY_LAYOUT) | \
+(1ULL << VIRTIO_F_VERSION_1) | \
+(1ULL << VIRTIO_F_ACCESS_PLATFORM))
+
+#define VDPASIM_NET_FEATURES (VDPASIM_FEATURES | \
+(1ULL << VIRTIO_NET_F_MAC))
struct vdpasim_dev_attr {
+ u64 supported_features;
int nvqs;
u32 id;
};
@@ -112,7 +115,7 @@ static void vdpasim_queue_ready(struct vdpasim *vdpasim,
unsigned int idx)
{
struct vdpasim_virtqueue *vq = &vdpasim->vqs[idx];
- vringh_init_iotlb(&vq->vring, vdpasim_features,
+ vringh_init_iotlb(&vq->vring, vdpasim->dev_attr.supported_features,
VDPASIM_QUEUE_MAX, false,
(struct vring_desc *)(uintptr_t)vq->desc_addr,
(struct vring_avail *)
@@ -121,7 +124,8 @@ static void vdpasim_queue_ready(struct vdpasim *vdpasim,
unsigned int idx)
(uintptr_t)vq->device_addr);
}
-static void vdpasim_vq_reset(struct vdpasim_virtqueue *vq)
+static void vdpasim_vq_reset(struct vdpasim *vdpasim,
+struct vdpasim_virtqueue *vq)
{
vq->ready = false;
vq->desc_addr = 0;
@@ -129,8 +133,8 @@ static void vdpasim_vq_reset(struct vdpasim_virtqueue *vq)
vq->device_addr = 0;
vq->cb = NULL;
vq->private = NULL;
- vringh_init_iotlb(&vq->vring, vdpasim_features, VDPASIM_QUEUE_MAX,
- false, NULL, NULL, NULL);
+ vringh_init_iotlb(&vq->vring, vdpasim->dev_attr.supported_features,
+ VDPASIM_QUEUE_MAX, false, NULL, NULL, NULL);
}
static void vdpasim_reset(struct vdpasim *vdpasim)
@@ -138,7 +142,7 @@ static void vdpasim_reset(struct vdpasim *vdpasim)
int i;
for (i = 0; i < vdpasim->dev_attr.nvqs; i++)
- vdpasim_vq_reset(&vdpasim->vqs[i]);
+ vdpasim_vq_reset(vdpasim, &vdpasim->vqs[i]);
spin_lock(&vdpasim->iommu_lock);
vhost_iotlb_reset(vdpasim->iommu);
@@ -498,7 +502,9 @@ static u32 vdpasim_get_vq_align(struct vdpa_device *vdpa)
static u64 vdpasim_get_features(struct vdpa_device *vdpa)
{
- return vdpasim_features;
+ struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
+
+ return vdpasim->dev_attr.supported_features;
}
static int vdpasim_set_features(struct vdpa_device *vdpa, u64 features)
@@ -510,7 +516,7 @@ static int vdpasim_set_features(struct vdpa_device *vdpa,
u64 features)
if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
return -EINVAL;
- vdpasim->features = features & vdpasim_features;
+ vdpasim->features = features & vdpasim->dev_attr.supported_features;
/* We generally only know whether guest is using the legacy interface
* here, so generally that's the earliest we can set config fields.
@@ -722,6 +728,7 @@ static int __init vdpasim_dev_init(void)
struct vdpasim_dev_attr dev_attr = {};
dev_attr.id = VIRTIO_ID_NET;
+ dev_attr.supported_features = VDPASIM_NET_FEATURES;
dev_attr.nvqs = VDPASIM_VQ_NUM;
vdpasim_dev = vdpasim_create(&dev_attr);
Re: [PATCH v2 09/17] vdpa_sim: add work_fn in vdpasim_dev_attr
On 2020/11/26 下午10:49, Stefano Garzarella wrote:
Rename vdpasim_work() in vdpasim_net_work() and add it to
the vdpasim_dev_attr structure.
Co-developed-by: Max Gurtovoy
Signed-off-by: Max Gurtovoy
Signed-off-by: Stefano Garzarella
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Acked-by: Jason Wang
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 36677fc3631b..b84d9acd130c 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -60,6 +60,8 @@ struct vdpasim_dev_attr {
u64 supported_features;
int nvqs;
u32 id;
+
+ work_func_t work_fn;
};
/* State of each vdpasim device */
@@ -153,7 +155,7 @@ static void vdpasim_reset(struct vdpasim *vdpasim)
++vdpasim->generation;
}
-static void vdpasim_work(struct work_struct *work)
+static void vdpasim_net_work(struct work_struct *work)
{
struct vdpasim *vdpasim = container_of(work, struct
vdpasim, work);
@@ -360,7 +362,7 @@ static struct vdpasim *vdpasim_create(struct
vdpasim_dev_attr *dev_attr)
goto err_alloc;
vdpasim->dev_attr = *dev_attr;
- INIT_WORK(&vdpasim->work, vdpasim_work);
+ INIT_WORK(&vdpasim->work, dev_attr->work_fn);
spin_lock_init(&vdpasim->lock);
spin_lock_init(&vdpasim->iommu_lock);
@@ -730,6 +732,7 @@ static int __init vdpasim_dev_init(void)
dev_attr.id = VIRTIO_ID_NET;
dev_attr.supported_features = VDPASIM_NET_FEATURES;
dev_attr.nvqs = VDPASIM_VQ_NUM;
+ dev_attr.work_fn = vdpasim_net_work;
vdpasim_dev = vdpasim_create(&dev_attr);
Re: [PATCH] posix_acl.h: define missing ACL functions on non-posix-acl build
On (20/11/29 18:00), Randy Dunlap wrote: > On 11/29/20 5:44 PM, Sergey Senozhatsky wrote: > > Some functions that are declared when CONFIG_POSIX_ACL is defined > > are not declared when CONFIG_POSIX_ACL is not defined. Add the > > missing ones: > > set_posix_acl(), posix_acl_update_mode(), get_cached_acl(), > > get_cached_acl_rcu(), set_cached_acl(), forget_cached_acl(). > > > > Signed-off-by: Sergey Senozhatsky > > Hi, > > I can't find CONFIG_POSIX_ACL in the kernel source tree. > Should it be CONFIG_FS_POSIX_ACL ? Oh, yes, CONFIG_POSIX_ACL. My bad. > How did you test this? You know what - scratch this patch. Sorry for the noise. Some of the posix_acl.h functions are guarded by ifdef/ifndef CONFIG_FS_POSIX_ACL, and some are not. This can break the build if the code in question doesn't use ifdef CONFIG_FS_POSIX_ACL (which happens with our code). But this patch is not enough, apparently, we need to add ifdef CONFIG_FS_POSIX_ACL to our code anyway, because of, for instance, posix_acl_alloc() which is undefined for !FS_POSIX_ACL builds. Sorry for the noise. -ss
Re: [PATCH v2 07/17] vdpa_sim: add device id field in vdpasim_dev_attr
On 2020/11/26 下午10:49, Stefano Garzarella wrote:
Remove VDPASIM_DEVICE_ID macro and add 'id' field in vdpasim_dev_attr,
that will be returned by vdpasim_get_device_id().
Use VIRTIO_ID_NET for vDPA-net simulator device id.
Co-developed-by: Max Gurtovoy
Signed-off-by: Max Gurtovoy
Signed-off-by: Stefano Garzarella
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Acked-by: Jason Wang
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index f98262add0e1..393b54a9f0e4 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -44,7 +44,6 @@ struct vdpasim_virtqueue {
#define VDPASIM_QUEUE_ALIGN PAGE_SIZE
#define VDPASIM_QUEUE_MAX 256
-#define VDPASIM_DEVICE_ID 0x1
#define VDPASIM_VENDOR_ID 0
#define VDPASIM_IOTLB_LIMIT 0 /* unlimited */
#define VDPASIM_VQ_NUM 0x2
@@ -57,6 +56,7 @@ static u64 vdpasim_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
struct vdpasim_dev_attr {
int nvqs;
+ u32 id;
};
/* State of each vdpasim device */
@@ -536,7 +536,9 @@ static u16 vdpasim_get_vq_num_max(struct vdpa_device *vdpa)
static u32 vdpasim_get_device_id(struct vdpa_device *vdpa)
{
- return VDPASIM_DEVICE_ID;
+ struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
+
+ return vdpasim->dev_attr.id;
}
static u32 vdpasim_get_vendor_id(struct vdpa_device *vdpa)
@@ -719,6 +721,7 @@ static int __init vdpasim_dev_init(void)
{
struct vdpasim_dev_attr dev_attr = {};
+ dev_attr.id = VIRTIO_ID_NET;
dev_attr.nvqs = VDPASIM_VQ_NUM;
vdpasim_dev = vdpasim_create(&dev_attr);
[PATCH] ASoC: mediatek: btcvsd fix tx stream assign
From: Lumi Lee
Fix tx/rx stream assign in write.
Write should use tx instead of rx.
Signed-off-by: Lumi Lee
---
sound/soc/mediatek/common/mtk-btcvsd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/common/mtk-btcvsd.c
b/sound/soc/mediatek/common/mtk-btcvsd.c
index 668fef3..a554c57 100644
--- a/sound/soc/mediatek/common/mtk-btcvsd.c
+++ b/sound/soc/mediatek/common/mtk-btcvsd.c
@@ -808,7 +808,7 @@ static ssize_t mtk_btcvsd_snd_write(struct mtk_btcvsd_snd
*bt,
spin_unlock_irqrestore(&bt->tx_lock, flags);
if (!avail) {
- int ret = wait_for_bt_irq(bt, bt->rx);
+ int ret = wait_for_bt_irq(bt, bt->tx);
if (ret)
return written_size;
--
1.7.9.5
Re: [PATCH 0/3] clear_warn_once: add timed interval resetting
On Thu, Nov 26, 2020 at 01:30:26AM -0500, Paul Gortmaker wrote: > But you currently can't make use of clear_warn_once unless you've got > debugfs enabled and mounted - which may not be desired by some people > in some deployment situations. Seems awfully special purpose. The problem with debugfs is security, or is it no convenient process that could do cron like functionality? If it's the first, perhaps what they really need is a way to get a partial debugfs? -Andi
Re: [PATCH v2 06/17] vdpa_sim: add struct vdpasim_dev_attr for device attributes
On 2020/11/26 下午10:49, Stefano Garzarella wrote:
vdpasim_dev_attr will contain device specific attributes. We starting
moving the number of virtqueues (i.e. nvqs) to vdpasim_dev_attr.
vdpasim_create() creates a new vDPA simulator following the device
attributes defined in the vdpasim_dev_attr parameter.
Co-developed-by: Max Gurtovoy
Signed-off-by: Max Gurtovoy
Signed-off-by: Stefano Garzarella
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
Acked-by: Jason Wang
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 62204e064841..f98262add0e1 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -55,11 +55,16 @@ static u64 vdpasim_features = (1ULL << VIRTIO_F_ANY_LAYOUT)
|
(1ULL << VIRTIO_F_ACCESS_PLATFORM) |
(1ULL << VIRTIO_NET_F_MAC);
+struct vdpasim_dev_attr {
+ int nvqs;
+};
+
/* State of each vdpasim device */
struct vdpasim {
struct vdpa_device vdpa;
struct vdpasim_virtqueue *vqs;
struct work_struct work;
+ struct vdpasim_dev_attr dev_attr;
/* spinlock to synchronize virtqueue state */
spinlock_t lock;
struct virtio_net_config config;
@@ -68,7 +73,6 @@ struct vdpasim {
u32 status;
u32 generation;
u64 features;
- int nvqs;
/* spinlock to synchronize iommu table */
spinlock_t iommu_lock;
};
@@ -133,7 +137,7 @@ static void vdpasim_reset(struct vdpasim *vdpasim)
{
int i;
- for (i = 0; i < vdpasim->nvqs; i++)
+ for (i = 0; i < vdpasim->dev_attr.nvqs; i++)
vdpasim_vq_reset(&vdpasim->vqs[i]);
spin_lock(&vdpasim->iommu_lock);
@@ -334,7 +338,7 @@ static const struct dma_map_ops vdpasim_dma_ops = {
static const struct vdpa_config_ops vdpasim_config_ops;
static const struct vdpa_config_ops vdpasim_batch_config_ops;
-static struct vdpasim *vdpasim_create(void)
+static struct vdpasim *vdpasim_create(struct vdpasim_dev_attr *dev_attr)
{
const struct vdpa_config_ops *ops;
struct vdpasim *vdpasim;
@@ -346,11 +350,12 @@ static struct vdpasim *vdpasim_create(void)
else
ops = &vdpasim_config_ops;
- vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL, ops, VDPASIM_VQ_NUM);
+ vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL, ops,
+ dev_attr->nvqs);
if (!vdpasim)
goto err_alloc;
- vdpasim->nvqs = VDPASIM_VQ_NUM;
+ vdpasim->dev_attr = *dev_attr;
INIT_WORK(&vdpasim->work, vdpasim_work);
spin_lock_init(&vdpasim->lock);
spin_lock_init(&vdpasim->iommu_lock);
@@ -361,7 +366,7 @@ static struct vdpasim *vdpasim_create(void)
goto err_iommu;
set_dma_ops(dev, &vdpasim_dma_ops);
- vdpasim->vqs = kcalloc(vdpasim->nvqs, sizeof(struct vdpasim_virtqueue),
+ vdpasim->vqs = kcalloc(dev_attr->nvqs, sizeof(struct vdpasim_virtqueue),
GFP_KERNEL);
if (!vdpasim->vqs)
goto err_iommu;
@@ -384,7 +389,7 @@ static struct vdpasim *vdpasim_create(void)
eth_random_addr(vdpasim->config.mac);
}
- for (i = 0; i < vdpasim->nvqs; i++)
+ for (i = 0; i < dev_attr->nvqs; i++)
vringh_set_iotlb(&vdpasim->vqs[i].vring, vdpasim->iommu);
vdpasim->vdpa.dma_dev = dev;
@@ -712,7 +717,11 @@ static const struct vdpa_config_ops
vdpasim_batch_config_ops = {
static int __init vdpasim_dev_init(void)
{
- vdpasim_dev = vdpasim_create();
+ struct vdpasim_dev_attr dev_attr = {};
+
+ dev_attr.nvqs = VDPASIM_VQ_NUM;
+
+ vdpasim_dev = vdpasim_create(&dev_attr);
if (!IS_ERR(vdpasim_dev))
return 0;
Re: [PATCH v2 05/17] vdpa_sim: rename vdpasim_config_ops variables
On 2020/11/26 下午10:49, Stefano Garzarella wrote:
These variables stores generic callbacks used by the vDPA simulator
core, so we can remove the 'net' word in their names.
Co-developed-by: Max Gurtovoy
Signed-off-by: Max Gurtovoy
Signed-off-by: Stefano Garzarella
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Acked-by: Jason Wang
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 40664d87f303..62204e064841 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -331,8 +331,8 @@ static const struct dma_map_ops vdpasim_dma_ops = {
.free = vdpasim_free_coherent,
};
-static const struct vdpa_config_ops vdpasim_net_config_ops;
-static const struct vdpa_config_ops vdpasim_net_batch_config_ops;
+static const struct vdpa_config_ops vdpasim_config_ops;
+static const struct vdpa_config_ops vdpasim_batch_config_ops;
static struct vdpasim *vdpasim_create(void)
{
@@ -342,9 +342,9 @@ static struct vdpasim *vdpasim_create(void)
int i, ret = -ENOMEM;
if (batch_mapping)
- ops = &vdpasim_net_batch_config_ops;
+ ops = &vdpasim_batch_config_ops;
else
- ops = &vdpasim_net_config_ops;
+ ops = &vdpasim_config_ops;
vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL, ops, VDPASIM_VQ_NUM);
if (!vdpasim)
@@ -657,7 +657,7 @@ static void vdpasim_free(struct vdpa_device *vdpa)
kfree(vdpasim->vqs);
}
-static const struct vdpa_config_ops vdpasim_net_config_ops = {
+static const struct vdpa_config_ops vdpasim_config_ops = {
.set_vq_address = vdpasim_set_vq_address,
.set_vq_num = vdpasim_set_vq_num,
.kick_vq= vdpasim_kick_vq,
@@ -684,7 +684,7 @@ static const struct vdpa_config_ops vdpasim_net_config_ops
= {
.free = vdpasim_free,
};
-static const struct vdpa_config_ops vdpasim_net_batch_config_ops = {
+static const struct vdpa_config_ops vdpasim_batch_config_ops = {
.set_vq_address = vdpasim_set_vq_address,
.set_vq_num = vdpasim_set_vq_num,
.kick_vq= vdpasim_kick_vq,
Re: [PATCH v2 04/17] vdpa_sim: remove the limit of IOTLB entries
On 2020/11/26 下午10:49, Stefano Garzarella wrote:
The simulated devices can support multiple queues, so this limit
should be defined according to the number of queues supported by
the device.
Since we are in a simulator, let's simply remove that limit.
Suggested-by: Jason Wang
Acked-by: Jason Wang
Signed-off-by: Stefano Garzarella
---
v2:
- added VDPASIM_IOTLB_LIMIT macro [Jason]
Sorry for being unclear. I meant adding a macro like
VHOST_IOTLB_UNLIMITED 0 in vhost_iotlb.h.
And use that in vdpa_sim.
Thanks
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index ad72f7b1a4eb..40664d87f303 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -46,6 +46,7 @@ struct vdpasim_virtqueue {
#define VDPASIM_QUEUE_MAX 256
#define VDPASIM_DEVICE_ID 0x1
#define VDPASIM_VENDOR_ID 0
+#define VDPASIM_IOTLB_LIMIT 0 /* unlimited */
#define VDPASIM_VQ_NUM 0x2
#define VDPASIM_NAME "vdpasim-netdev"
@@ -365,7 +366,7 @@ static struct vdpasim *vdpasim_create(void)
if (!vdpasim->vqs)
goto err_iommu;
- vdpasim->iommu = vhost_iotlb_alloc(2048, 0);
+ vdpasim->iommu = vhost_iotlb_alloc(VDPASIM_IOTLB_LIMIT, 0);
if (!vdpasim->iommu)
goto err_iommu;
Re: [PATCH v2 03/17] vdpa_sim: remove hard-coded virtq count
On 2020/11/26 下午10:49, Stefano Garzarella wrote:
From: Max Gurtovoy
Add a new attribute that will define the number of virt queues to be
created for the vdpasim device.
Signed-off-by: Max Gurtovoy
[sgarzare: replace kmalloc_array() with kcalloc()]
Signed-off-by: Stefano Garzarella
Acked-by: Jason Wang
---
v1:
- use kcalloc() instead of kmalloc_array() since some function expects
variables initialized to zero
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index c6eaf62df8ec..ad72f7b1a4eb 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -57,7 +57,7 @@ static u64 vdpasim_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
/* State of each vdpasim device */
struct vdpasim {
struct vdpa_device vdpa;
- struct vdpasim_virtqueue vqs[VDPASIM_VQ_NUM];
+ struct vdpasim_virtqueue *vqs;
struct work_struct work;
/* spinlock to synchronize virtqueue state */
spinlock_t lock;
@@ -67,6 +67,7 @@ struct vdpasim {
u32 status;
u32 generation;
u64 features;
+ int nvqs;
/* spinlock to synchronize iommu table */
spinlock_t iommu_lock;
};
@@ -131,7 +132,7 @@ static void vdpasim_reset(struct vdpasim *vdpasim)
{
int i;
- for (i = 0; i < VDPASIM_VQ_NUM; i++)
+ for (i = 0; i < vdpasim->nvqs; i++)
vdpasim_vq_reset(&vdpasim->vqs[i]);
spin_lock(&vdpasim->iommu_lock);
@@ -337,7 +338,7 @@ static struct vdpasim *vdpasim_create(void)
const struct vdpa_config_ops *ops;
struct vdpasim *vdpasim;
struct device *dev;
- int ret = -ENOMEM;
+ int i, ret = -ENOMEM;
if (batch_mapping)
ops = &vdpasim_net_batch_config_ops;
@@ -348,6 +349,7 @@ static struct vdpasim *vdpasim_create(void)
if (!vdpasim)
goto err_alloc;
+ vdpasim->nvqs = VDPASIM_VQ_NUM;
INIT_WORK(&vdpasim->work, vdpasim_work);
spin_lock_init(&vdpasim->lock);
spin_lock_init(&vdpasim->iommu_lock);
@@ -358,6 +360,11 @@ static struct vdpasim *vdpasim_create(void)
goto err_iommu;
set_dma_ops(dev, &vdpasim_dma_ops);
+ vdpasim->vqs = kcalloc(vdpasim->nvqs, sizeof(struct vdpasim_virtqueue),
+ GFP_KERNEL);
+ if (!vdpasim->vqs)
+ goto err_iommu;
+
vdpasim->iommu = vhost_iotlb_alloc(2048, 0);
if (!vdpasim->iommu)
goto err_iommu;
@@ -376,8 +383,8 @@ static struct vdpasim *vdpasim_create(void)
eth_random_addr(vdpasim->config.mac);
}
- vringh_set_iotlb(&vdpasim->vqs[0].vring, vdpasim->iommu);
- vringh_set_iotlb(&vdpasim->vqs[1].vring, vdpasim->iommu);
+ for (i = 0; i < vdpasim->nvqs; i++)
+ vringh_set_iotlb(&vdpasim->vqs[i].vring, vdpasim->iommu);
vdpasim->vdpa.dma_dev = dev;
ret = vdpa_register_device(&vdpasim->vdpa);
@@ -646,6 +653,7 @@ static void vdpasim_free(struct vdpa_device *vdpa)
kfree(vdpasim->buffer);
if (vdpasim->iommu)
vhost_iotlb_free(vdpasim->iommu);
+ kfree(vdpasim->vqs);
}
static const struct vdpa_config_ops vdpasim_net_config_ops = {
Re: [PATCH v2 02/17] vdpa_sim: remove unnecessary headers inclusion
On 2020/11/26 下午10:49, Stefano Garzarella wrote:
Some headers are not necessary, so let's remove them to do
some cleaning.
Signed-off-by: Stefano Garzarella
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 6a90fdb9cbfc..c6eaf62df8ec 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -7,24 +7,11 @@
*
*/
-#include
#include
-#include
I think the rule is to make sure e.g the structure definition can be via
direct inclusion. E.g struct device {} is defined in this file.
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
#include
#include
#include
-#include
And the __cpu_to_virtio16 is defined in this file.
Thanks
#include
#include
#include
Re: [PATCH v2 01/17] vdpa: remove unnecessary 'default n' in Kconfig entries
On 2020/11/26 下午10:49, Stefano Garzarella wrote: 'default n' is not necessary since it is already the default when nothing is specified. Suggested-by: Jason Wang Signed-off-by: Stefano Garzarella Acked-by: Jason Wang --- drivers/vdpa/Kconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig index 358f6048dd3c..4019ceb88181 100644 --- a/drivers/vdpa/Kconfig +++ b/drivers/vdpa/Kconfig @@ -14,7 +14,6 @@ config VDPA_SIM select DMA_OPS select VHOST_RING select GENERIC_NET_UTILS - default n help vDPA networking device simulator which loop TX traffic back to RX. This device is used for testing, prototyping and @@ -23,7 +22,6 @@ config VDPA_SIM config IFCVF tristate "Intel IFC VF vDPA driver" depends on PCI_MSI - default n help This kernel module can drive Intel IFC VF NIC to offload virtio dataplane traffic to hardware. @@ -41,7 +39,6 @@ config MLX5_VDPA_NET tristate "vDPA driver for ConnectX devices" select MLX5_VDPA depends on MLX5_CORE - default n help VDPA network driver for ConnectX6 and newer. Provides offloading of virtio net datapath such that descriptors put on the ring will
[PATCH] ARM: dts: mvebu: Add device tree for ATL-x530 Board
Add device tree file for x530 board. This has an Armada 385 SoC. Has
NAND-flash for user storage and SPI for booting. Covers majority of x530
and GS980MX variants.
Signed-off-by: Aryan Srivastava
Reviewed-by: Chris Packham
---
arch/arm/boot/dts/armada-385-atl-x530.dts | 235 ++
1 file changed, 235 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-atl-x530.dts
diff --git a/arch/arm/boot/dts/armada-385-atl-x530.dts
b/arch/arm/boot/dts/armada-385-atl-x530.dts
new file mode 100644
index ..2041bf09c578
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-atl-x530.dts
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Armada 385 Allied Telesis x530/GS980MX Board.
+ (x530/AT-GS980MX)
+ *
+ Copyright (C) 2020 Allied Telesis Labs
+ */
+
+/dts-v1/;
+#include "armada-385.dtsi"
+
+#include
+
+/ {
+ model = "x530/AT-GS980MX";
+ compatible = "alliedtelesis,gs980mx", "alliedtelesis,x530",
"marvell,armada385", "marvell,armada380";
+
+ chosen {
+ stdout-path = "serial1:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x4000>; /* 1GB */
+ };
+
+ soc {
+ ranges = ;
+
+ internal-regs {
+ i2c0: i2c@11000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+ };
+
+ uart0: serial@12000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+ };
+ };
+ };
+};
+
+&pciec {
+ status = "okay";
+};
+
+&pcie1 {
+ status = "okay";
+ reset-gpios = <&gpio1 23 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <40>;
+};
+
+&pcie2 {
+ status = "okay";
+};
+
+&devbus_cs1 {
+ compatible = "marvell,mvebu-devbus";
+ status = "okay";
+
+ devbus,bus-width= <8>;
+ devbus,turn-off-ps = <6>;
+ devbus,badr-skew-ps = <0>;
+ devbus,acc-first-ps = <124000>;
+ devbus,acc-next-ps = <248000>;
+ devbus,rd-setup-ps = <0>;
+ devbus,rd-hold-ps = <0>;
+
+ /* Write parameters */
+ devbus,sync-enable = <0>;
+ devbus,wr-high-ps = <6>;
+ devbus,wr-low-ps = <6>;
+ devbus,ale-wr-ps = <6>;
+
+ nvs@0 {
+ status = "okay";
+
+ compatible = "mtd-ram";
+ reg = <0 0x0008>;
+ bank-width = <1>;
+ label = "nvs";
+ };
+};
+
+&pinctrl {
+ i2c0_gpio_pins: i2c-gpio-pins-0 {
+ marvell,pins = "mpp2", "mpp3";
+ marvell,function = "gpio";
+ };
+};
+
+&i2c0 {
+ clock-frequency = <10>;
+ status = "okay";
+
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-1 = <&i2c0_gpio_pins>;
+ scl-gpio = <&gpio0 2 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ sda-gpio = <&gpio0 3 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+
+ i2c0mux: mux@71 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nxp,pca9544";
+ reg = <0x71>;
+ i2c-mux-idle-disconnect;
+
+ i2c@0 { /* POE devices MUX */
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ adt7476_2e: hwmon@2e {
+ compatible = "adi,adt7476";
+ reg = <0x2e>;
+ };
+
+ adt7476_2d: hwmon@2d {
+ compatible = "adi,adt7476";
+ reg = <0x2d>;
+ };
+ };
+
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ rtc@68 {
+ compatible = "dallas,ds1340";
+ reg = <0x68>;
+ };
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ gpio@20 {
+ compatible = "nxp,pca9554";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ };
+ };
+ };
+};
+
+&usb0
[ANNOUNCE] [CFP] Call for Sessions - linux.conf.au Online 2021 Kernel Miniconf
LCA2021 Kernel Miniconf - Online - 2021-01-23 - LCA Kernel Miniconf submissions now open! (Ever wanted to present at LCA, but couldn't justify flying to Australia? Well, 2021 is your chance - we're going online-only for reasons you're probably aware of.) Submissions close: 2020-12-18, 23:59 AoE/UTC-12 Submissions: https://linux.conf.au/proposals/submit/kernel-miniconf/ More info: https://lca-kernel.ozlabs.org/2021-cfs.html *** linux.conf.au 2021 will be held at the Australian National University, Canberra^W^W^W^W^W^Win the comfort of your own homes, by the magic of the internet, from 23-25 January 2021. The Kernel Miniconf is a single-day miniconf track, held on Saturday 23 January, about everything related to the kernel and low-level systems programming. The Kernel Miniconf will focus on a variety of kernel-related topics - technical presentations on up-and-coming kernel developments, the future direction of the kernel, and kernel development community and process matters. Past Kernel Miniconfs have included technical talks on topics such as memory management, RCU, scheduling and filesystems, as well as talks on Linux kernel community topics such as licensing and Linux kernel development process. We invite submissions on anything related to kernel and low-level systems programming. We welcome submissions from developers of all levels of experience in the kernel community, covering a broad range of topics. The focus of the miniconf will primarily be on Linux, however non-Linux talks of sufficient interest to a primarily Linux audience will be considered. -- Andrew Donnellan OzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
Re: [PATCH v1 0/9] Enable root to update the blacklist keyring
On Fri, Nov 20, 2020 at 07:04:17PM +0100, Mickaël Salaün wrote:
> Hi,
>
> This patch series mainly add a new configuration option to enable the
> root user to load signed keys in the blacklist keyring. This keyring is
> useful to "untrust" certificates or files. Enabling to safely update
> this keyring without recompiling the kernel makes it more usable.
I apologize for latency. This cycle has been difficult because of
final cuts with the huge SGX patch set.
I did skim through this and did not see anything striking (but it
was a quick look).
What would be easiest way to smoke test the changes?
> Regards,
>
> Mickaël Salaün (9):
> certs: Fix blacklisted hexadecimal hash string check
> certs: Make blacklist_vet_description() more strict
> certs: Factor out the blacklist hash creation
> certs: Check that builtin blacklist hashes are valid
> PKCS#7: Fix missing include
> certs: Fix blacklist flag type confusion
> certs: Allow root user to append signed hashes to the blacklist
> keyring
> certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID
> tools/certs: Add print-cert-tbs-hash.sh
>
> MAINTAINERS | 2 +
> certs/.gitignore | 1 +
> certs/Kconfig | 10 +
> certs/Makefile| 15 +-
> certs/blacklist.c | 210 +-
> certs/system_keyring.c| 5 +-
> crypto/asymmetric_keys/x509_public_key.c | 3 +-
> include/keys/system_keyring.h | 14 +-
> include/linux/verification.h | 2 +
> scripts/check-blacklist-hashes.awk| 37 +++
> .../platform_certs/keyring_handler.c | 26 +--
> tools/certs/print-cert-tbs-hash.sh| 91
> 12 files changed, 335 insertions(+), 81 deletions(-)
> create mode 100755 scripts/check-blacklist-hashes.awk
> create mode 100755 tools/certs/print-cert-tbs-hash.sh
>
>
> base-commit: 09162bc32c880a791c6c0668ce0745cf7958f576
> --
> 2.29.2
>
>
/Jarkko
Re: [PATCH] scsi: ses: Fix crash caused by kfree an invalid pointer
On 2020/11/29 13:12, Douglas Gilbert wrote: On 2020-11-28 6:27 p.m., James Bottomley wrote: On Sat, 2020-11-28 at 20:23 +0800, Ding Hui wrote: We can get a crash when disconnecting the iSCSI session, the call trace like this: [2a00fb70] kfree at 0830e224 [2a00fba0] ses_intf_remove at 01f200e4 [2a00fbd0] device_del at 086b6a98 [2a00fc50] device_unregister at 086b6d58 [2a00fc70] __scsi_remove_device at 0870608c [2a00fca0] scsi_remove_device at 08706134 [2a00fcc0] __scsi_remove_target at 087062e4 [2a00fd10] scsi_remove_target at 087064c0 [2a00fd70] __iscsi_unbind_session at 01c872c4 [2a00fdb0] process_one_work at 0810f35c [2a00fe00] worker_thread at 0810f648 [2a00fe70] kthread at 08116e98 In ses_intf_add, components count could be 0, and kcalloc 0 size scomp, but not saved in edev->component[i].scratch In this situation, edev->component[0].scratch is an invalid pointer, when kfree it in ses_intf_remove_enclosure, a crash like above would happen The call trace also could be other random cases when kfree cannot catch the invalid pointer We should not use edev->component[] array when the components count is 0 We also need check index when use edev->component[] array in ses_enclosure_data_process Tested-by: Zeng Zhicong Cc: stable # 2.6.25+ Signed-off-by: Ding Hui This doesn't really look to be the right thing to do: an enclosure which has no component can't usefully be controlled by the driver since there's nothing for it to do, so what we should do in this situation is refuse to attach like the proposed patch below. It does seem a bit odd that someone would build an enclosure that doesn't enclose anything, so would you mind running sg_ses -e '-e' is the short form of '--enumerate'. That will report the names and abbreviations of the diagnostic pages that the utility itself knows about (and supports). It won't show anything specific about the environment that sg_ses is executed in. You probably meant: sg_ses Examples of the likely forms are: sg_ses /dev/bsg/1:0:0:0 sg_ses /dev/sg2 sg_ses /dev/ses0 This from a nearby machine: $ lsscsi -gs [3:0:0:0] disk ATA Samsung SSD 850 1B6Q /dev/sda /dev/sg0 120GB [4:0:0:0] disk IBM-207x HUSMM8020ASS20 J4B6 /dev/sdc /dev/sg2 200GB [4:0:1:0] disk ATA INTEL SSDSC2KW25 003C /dev/sdd /dev/sg3 256GB [4:0:2:0] disk SEAGATE ST1NM0096 E005 /dev/sde /dev/sg4 10.0TB [4:0:3:0] enclosu Areca Te ARC-802801.37.69 0137 - /dev/sg5 - [4:0:4:0] enclosu Intel RES2SV240 0d00 - /dev/sg6 - [7:0:0:0] disk Kingston DataTravelerMini PMAP /dev/sdb /dev/sg1 1.03GB [N:0:0:1] disk WDC WDS256G1X0C-00ENX0__1 /dev/nvme0n1 - 256GB # sg_ses /dev/sg5 Areca Te ARC-802801.37.69 0137 Supported diagnostic pages: Supported Diagnostic Pages [sdp] [0x0] Configuration (SES) [cf] [0x1] Enclosure Status/Control (SES) [ec,es] [0x2] String In/Out (SES) [str] [0x4] Threshold In/Out (SES) [th] [0x5] Element Descriptor (SES) [ed] [0x7] Additional Element Status (SES-2) [aes] [0xa] Supported SES Diagnostic Pages (SES-2) [ssp] [0xd] Download Microcode (SES-2) [dm] [0xe] Subenclosure Nickname (SES-2) [snic] [0xf] Protocol Specific (SAS transport) [] [0x3f] # sg_ses -p cf /dev/sg5 Areca Te ARC-802801.37.69 0137 Configuration diagnostic page: number of secondary subenclosures: 0 generation code: 0x0 enclosure descriptor list Subenclosure identifier: 0 [primary] relative ES process id: 1, number of ES processes: 1 number of type descriptor headers: 9 enclosure logical identifier (hex): d5b401503fc0ec16 enclosure vendor: Areca Te product: ARC-802801.37.69 rev: 0137 vendor-specific data: 11 22 33 44 55 00 00 00 ."3DU... type descriptor header and text list Element type: Array device slot, subenclosure id: 0 number of possible elements: 24 text: ArrayDevicesInSubEnclsr0 Element type: Enclosure, subenclosure id: 0 number of possible elements: 1 text: EnclosureElementInSubEnclsr0 Element type: SAS expander, subenclosure id: 0 number of possible elements: 1 text: SAS Expander Element type: Cooling, subenclosure id: 0 number of possible elements: 5 text: CoolingElementInSubEnclsr0 Element type: Temperature sensor, subenclosure id: 0 number of possible elements: 2 text: TempSensorsInSubEnclsr0 Element type: Voltage sensor, subenclosure id: 0 number of possible elements: 2 text: VoltageSensorsInSubEnclsr0 Element type: SAS connector, subenclosure id: 0 number of possible elements: 3 text: Conn
Re: [PATCH] crypto: ecrdsa - use subsys_initcall instead of module_init
On Mon, Nov 30, 2020 at 10:21:56AM +0800, Tianjia Zhang wrote: > > > That is true only if there are non-generic implementations of > > the algorithms, which is not the case here. Please explain the > > real reason why this is needed. > > This is a generic algorithm, the author Vitaly Chikunov has also confirmed > it, please consider this patch again. As I said, the generic algorithm only needs to be loaded early *if* there are non-generic implementations. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/1] scsi: ufs: Remove scale down gear hard code
On Thu, 2020-11-26 at 17:58 -0800, Can Guo wrote: > Instead of making the scale down gear a hard code, make it a member of > ufs_clk_scaling struct. > > Signed-off-by: Can Guo Reviewed-by: Stanley Chu
Re: [PATCH] crypto: ecrdsa - use subsys_initcall instead of module_init
Hi Herbert, On 10/15/20 8:05 PM, Herbert Xu wrote: On Thu, Oct 15, 2020 at 07:02:41PM +0800, Tianjia Zhang wrote: All templates and generic algorithms have been registered in subsys_initcall instead of module_init. The ecrdsa algorithm happened to be missed. Here is a fix for it. That is true only if there are non-generic implementations of the algorithms, which is not the case here. Please explain the real reason why this is needed. Cheers, This is a generic algorithm, the author Vitaly Chikunov has also confirmed it, please consider this patch again. Thanks.
[PATCH] block: wbt: Remove unnecessary invoking of wbt_update_limits in wbt_init
From: Lei Chen It's unnecessary to call wbt_update_limits explicitly within wbt_init, because it will be called in the following function wbt_queue_depth_changed. Signed-off-by: Lei Chen --- block/blk-wbt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/block/blk-wbt.c b/block/blk-wbt.c index fd41008..0321ca8 100644 --- a/block/blk-wbt.c +++ b/block/blk-wbt.c @@ -835,7 +835,6 @@ int wbt_init(struct request_queue *q) rwb->enable_state = WBT_STATE_ON_DEFAULT; rwb->wc = 1; rwb->rq_depth.default_depth = RWB_DEF_DEPTH; - wbt_update_limits(rwb); /* * Assign rwb and add the stats callback. -- 1.8.3.1
Re: [PATCH] vdpa: ifcvf: Use dma_set_mask_and_coherent to simplify code
On 2020/11/29 下午8:54, Christophe JAILLET wrote:
'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by
an equivalent 'dma_set_mask_and_coherent()' which is much less verbose.
While at it, fix a typo (s/confiugration/configuration)
Signed-off-by: Christophe JAILLET
---
Acked-by: Jason Wang
drivers/vdpa/ifcvf/ifcvf_main.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index 8b4028556cb6..fa1af301cf55 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -417,16 +417,9 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
return ret;
}
- ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+ ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
if (ret) {
- IFCVF_ERR(pdev, "No usable DMA confiugration\n");
- return ret;
- }
-
- ret = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
- if (ret) {
- IFCVF_ERR(pdev,
- "No usable coherent DMA confiugration\n");
+ IFCVF_ERR(pdev, "No usable DMA configuration\n");
return ret;
}
[x86/cpu] 3d5f2fa9fa: Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode=
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: 3d5f2fa9faa040eb12bf93ddd8dac31b240609e7 ("[PATCH] x86/cpu: correct
values for GDT_ENTRY_INIT")
url:
https://github.com/0day-ci/linux/commits/Lukas-Bulwahn/x86-cpu-correct-values-for-GDT_ENTRY_INIT/20201126-195908
base: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git
9ea041b5e564b909207110a9edc04b287507756c
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+---+++
| | 9ea041b5e5 |
3d5f2fa9fa |
+---+++
| boot_failures | 0 | 4
|
| Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= | 0 | 4
|
+---+++
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
[2.499285] nmi_watchdog=panic
[2.500042] prompt_ramdisk=0
[2.500782] vga=normal
[2.501417] watchdog_thresh=60
[2.502444] traps: init[1] general protection fault ip:f7f66a14 sp:ffcb0370
error:0 in libc.so[f7f12000+67000]
[2.504610] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[2.506391] CPU: 1 PID: 1 Comm: init Not tainted
5.10.0-rc4-00713-g3d5f2fa9faa0 #1
[2.508040] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.12.0-1 04/01/2014
[2.509906] Call Trace:
[2.510558] dump_stack+0x57/0x6a
[2.511277] panic+0xfd/0x2be
[2.511931] do_exit.cold+0xa0/0xee
[2.512685] do_group_exit+0x35/0xa0
[2.513481] get_signal+0x16e/0x8b0
[2.514336] arch_do_signal_or_restart+0xe4/0x250
[2.515340] ? signal_wake_up_state+0x10/0x20
[2.516345] ? __send_signal+0x1de/0x3e0
[2.517318] ? force_sig_info_to_task+0xb5/0xd0
[2.518407] exit_to_user_mode_prepare+0xba/0x130
[2.519453] irqentry_exit_to_user_mode+0x5/0x20
[2.520506] exc_general_protection+0x22b/0x300
[2.521520] ? asm_exc_general_protection+0x8/0x30
[2.522557] asm_exc_general_protection+0x1e/0x30
[2.523562] RIP: 0023:0xf7f66a14
[2.524273] Code: Unable to access opcode bytes at RIP 0xf7f669ea.
[2.525455] RSP: 002b:ffcb0370 EFLAGS: 0200
[2.526568] RAX: RBX: RCX:
[2.528052] RDX: RSI: RDI:
[2.529611] RBP: R08: R09:
[2.531195] R10: R11: R12:
[2.532663] R13: R14: R15:
[2.542399] Kernel Offset: 0x39a0 from 0x8100 (relocation
range: 0x8000-0xbfff)
Kboot worker: lkp-worker47
To reproduce:
# build kernel
cd linux
cp config-5.10.0-rc4-00713-g3d5f2fa9faa0 .config
make HOSTCC=gcc-9 CC=gcc-9 ARCH=x86_64 olddefconfig prepare
modules_prepare bzImage
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Oliver Sang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.10.0-rc4 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc-9 (Debian 9.3.0-15) 9.3.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=90300
CONFIG_LD_VERSION=23500
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_CAN_LINK_STATIC=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_HAVE_KERNEL_ZSTD=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
# CONFIG_KERNEL_ZSTD is not set
CONFIG_DEFAULT_INIT=""
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_WATCH_QUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_
Re: [PATCH v4] vdpa: mlx5: fix vdpa/vhost dependencies
On 2020/11/29 上午5:39, Randy Dunlap wrote:
drivers/vdpa/mlx5/ uses vhost_iotlb*() interfaces, so select
VHOST_IOTLB to make them be built.
However, if VHOST_IOTLB is the only VHOST symbol that is
set/enabled, the object file still won't be built because
drivers/Makefile won't descend into drivers/vhost/ to build it,
so make drivers/Makefile build the needed binary whenever
VHOST_IOTLB is set, like it does for VHOST_RING.
Fixes these build errors:
ERROR: modpost: "vhost_iotlb_itree_next" [drivers/vdpa/mlx5/mlx5_vdpa.ko]
undefined!
ERROR: modpost: "vhost_iotlb_itree_first" [drivers/vdpa/mlx5/mlx5_vdpa.ko]
undefined!
Fixes: 29064bfdabd5 ("vdpa/mlx5: Add support library for mlx5 VDPA
implementation")
Fixes: aff90770e54c ("vdpa/mlx5: Fix dependency on MLX5_CORE")
Reported-by: kernel test robot
Signed-off-by: Randy Dunlap
Cc: Eli Cohen
Cc: Parav Pandit
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: virtualizat...@lists.linux-foundation.org
Cc: Saeed Mahameed
Cc: Leon Romanovsky
Cc: net...@vger.kernel.org
---
v2: change from select to depends on VHOST (Saeed)
v3: change to depends on VHOST_IOTLB (Jason)
v4: use select VHOST_IOTLB (Michael); also add to drivers/Makefile
drivers/Makefile |1 +
drivers/vdpa/Kconfig |1 +
2 files changed, 2 insertions(+)
--- linux-next-20201127.orig/drivers/vdpa/Kconfig
+++ linux-next-20201127/drivers/vdpa/Kconfig
@@ -32,6 +32,7 @@ config IFCVF
config MLX5_VDPA
bool
+ select VHOST_IOTLB
help
Support library for Mellanox VDPA drivers. Provides code that is
common for all types of VDPA drivers. The following drivers are
planned:
--- linux-next-20201127.orig/drivers/Makefile
+++ linux-next-20201127/drivers/Makefile
@@ -143,6 +143,7 @@ obj-$(CONFIG_OF)+= of/
obj-$(CONFIG_SSB) += ssb/
obj-$(CONFIG_BCMA)+= bcma/
obj-$(CONFIG_VHOST_RING) += vhost/
+obj-$(CONFIG_VHOST_IOTLB) += vhost/
obj-$(CONFIG_VHOST) += vhost/
obj-$(CONFIG_VLYNQ) += vlynq/
obj-$(CONFIG_GREYBUS) += greybus/
Acked-by: Jason Wang
Thanks
Re: md_raid: mdX_raid6 looping after sync_action "check" to "idle" transition
On 11/28/20 13:25, Donald Buczek wrote:
Dear Linux mdraid people,
we are using raid6 on several servers. Occasionally we had failures,
where a mdX_raid6 process seems to go into a busy loop and all I/O to
the md device blocks. We've seen this on various kernel versions.
The last time this happened (in this case with Linux 5.10.0-rc4), I took
some data.
The triggering event seems to be the md_check cron job trying to pause
the ongoing check operation in the morning with
echo idle > /sys/devices/virtual/block/md1/md/sync_action
This doesn't complete. Here's /proc/stack of this process:
root@done:~/linux_problems/mdX_raid6_looping/2020-11-27# ps -fp 2
UID PID PPID C STIME TTY TIME CMD
root 2 23331 0 02:00 ? 00:00:00 /bin/bash
/usr/bin/mdcheck --continue --duration 06:00
root@done:~/linux_problems/mdX_raid6_looping/2020-11-27# cat
/proc/2/stack
[<0>] kthread_stop+0x6e/0x150
[<0>] md_unregister_thread+0x3e/0x70
[<0>] md_reap_sync_thread+0x1f/0x1e0
[<0>] action_store+0x141/0x2b0
[<0>] md_attr_store+0x71/0xb0
[<0>] kernfs_fop_write+0x113/0x1a0
[<0>] vfs_write+0xbc/0x250
[<0>] ksys_write+0xa1/0xe0
[<0>] do_syscall_64+0x33/0x40
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Note, that md0 has been paused successfully just before.
What is the personality of md0? Is it also raid6?
2020-11-27T02:00:01+01:00 done CROND[2]: (root) CMD
(/usr/bin/mdcheck --continue --duration "06:00")
2020-11-27T02:00:01+01:00 done root: mdcheck continue checking
/dev/md0 from 10623180920
2020-11-27T02:00:01.382994+01:00 done kernel: [378596.606381] md:
data-check of RAID array md0
2020-11-27T02:00:01+01:00 done root: mdcheck continue checking
/dev/md1 from 11582849320
2020-11-27T02:00:01.437999+01:00 done kernel: [378596.661559] md:
data-check of RAID array md1
2020-11-27T06:00:01.842003+01:00 done kernel: [392996.625147] md:
md0: data-check interrupted.
2020-11-27T06:00:02+01:00 done root: pause checking /dev/md0 at
13351127680
2020-11-27T06:00:02.338989+01:00 done kernel: [392997.122520] md:
md1: data-check interrupted.
[ nothing related following ]
After that, we see md1_raid6 in a busy loop:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
2376 root 20 0 0 0 0 R 100.0 0.0 1387:38
md1_raid6
Seems the reap sync thread was trying to stop md1_raid6 while md1_raid6
was triggered again and again.
Also, all processes doing I/O do the md device block.
This is /proc/mdstat:
Personalities : [linear] [raid0] [raid1] [raid6] [raid5] [raid4]
[multipath]
md1 : active raid6 sdk[0] sdj[15] sdi[14] sdh[13] sdg[12] sdf[11]
sde[10] sdd[9] sdc[8] sdr[7] sdq[6] sdp[5] sdo[4] sdn[3] sdm[2] sdl[1]
109394518016 blocks super 1.2 level 6, 512k chunk, algorithm
2 [16/16] []
[==>..] check = 94.0%
(7350290348/7813894144) finish=57189.3min speed=135K/sec
bitmap: 0/59 pages [0KB], 65536KB chunk
md0 : active raid6 sds[0] sdah[15] sdag[16] sdaf[13] sdae[12]
sdad[11] sdac[10] sdab[9] sdaa[8] sdz[7] sdy[6] sdx[17] sdw[4] sdv[3]
sdu[2] sdt[1]
109394518016 blocks super 1.2 level 6, 512k chunk, algorithm
2 [16/16] []
bitmap: 0/59 pages [0KB], 65536KB chunk
So the RECOVERY_CHECK flag should be set, not sure if the simple changes
helps, but you may give it a try.
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 98bac4f..e2697d0 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -9300,7 +9300,8 @@ void md_check_recovery(struct mddev *mddev)
md_update_sb(mddev, 0);
if (test_bit(MD_RECOVERY_RUNNING, &mddev->recovery) &&
- !test_bit(MD_RECOVERY_DONE, &mddev->recovery)) {
+ (!test_bit(MD_RECOVERY_DONE, &mddev->recovery) ||
+test_bit(MD_RECOVERY_CHECK, &mddev->recovery))) {
/* resync/recovery still happening */
clear_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
goto unlock;
Thanks,
Guoqing
Re: [f2fs-dev] [PATCH] f2fs: add compr_inode and compr_blocks sysfs nodes
Alright, let's export readonly stats in new directory once you have such
requirement. :)
Thanks,
On 2020/11/30 10:02, Daeho Jeong wrote:
Sure, but I don't think we need to expose compr_inode and compr_block right now.
2020년 11월 27일 (금) 오후 6:44, Chao Yu 님이 작성:
Daeho,
How about updating this patch based on below patch?
f2fs: introduce a new per-sb directory in sysfs
On 2020/10/22 10:53, Daeho Jeong wrote:
Yep, It sounds good to me.
2020년 10월 21일 (수) 오후 3:08, Chao Yu 님이 작성:
On 2020/10/16 13:14, Daeho Jeong wrote:
From: Daeho Jeong
Added compr_inode to show compressed inode count and compr_blocks to
show compressed block count in sysfs.
As there are so many entries in ../f2fs// directory, it looks a mess
there, I suggest that we can add a new directory 'stats' in ../f2fs//,
in where we can store all readonly stats related entries there later.
How do you think?
Thanks,
Signed-off-by: Daeho Jeong
---
Documentation/ABI/testing/sysfs-fs-f2fs | 10 ++
fs/f2fs/sysfs.c | 17 +
2 files changed, 27 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 834d0becae6d..a01c26484c69 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -350,3 +350,13 @@ Date:April 2020
Contact:"Daeho Jeong"
Description:Give a way to change iostat_period time. 3secs by
default.
The new iostat trace gives stats gap given the period.
+
+What:/sys/fs/f2fs//compr_inode
+Date:October 2020
+Contact: "Daeho Jeong"
+Description: Show compressed inode count
+
+What:/sys/fs/f2fs//compr_blocks
+Date:October 2020
+Contact: "Daeho Jeong"
+Description: Show compressed block count
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index 94c98e412aa1..7139a29a00d3 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -223,6 +223,19 @@ static ssize_t avg_vblocks_show(struct f2fs_attr *a,
f2fs_update_sit_info(sbi);
return sprintf(buf, "%llu\n", (unsigned long long)(si->avg_vblocks));
}
+
+static ssize_t compr_inode_show(struct f2fs_attr *a,
+ struct f2fs_sb_info *sbi, char *buf)
+{
+ return sprintf(buf, "%u\n", atomic_read(&sbi->compr_inode));
+}
+
+static ssize_t compr_blocks_show(struct f2fs_attr *a,
+ struct f2fs_sb_info *sbi, char *buf)
+{
+ return sprintf(buf, "%llu\n", atomic64_read(&sbi->compr_blocks));
+}
+
#endif
static ssize_t main_blkaddr_show(struct f2fs_attr *a,
@@ -591,6 +604,8 @@ F2FS_STAT_ATTR(STAT_INFO, f2fs_stat_info,
gc_background_calls, bg_gc);
F2FS_GENERAL_RO_ATTR(moved_blocks_background);
F2FS_GENERAL_RO_ATTR(moved_blocks_foreground);
F2FS_GENERAL_RO_ATTR(avg_vblocks);
+F2FS_GENERAL_RO_ATTR(compr_inode);
+F2FS_GENERAL_RO_ATTR(compr_blocks);
#endif
#ifdef CONFIG_FS_ENCRYPTION
@@ -675,6 +690,8 @@ static struct attribute *f2fs_attrs[] = {
ATTR_LIST(moved_blocks_foreground),
ATTR_LIST(moved_blocks_background),
ATTR_LIST(avg_vblocks),
+ ATTR_LIST(compr_inode),
+ ATTR_LIST(compr_blocks),
#endif
NULL,
};
.
.
[PATCH] drm/gma500: Fix error return code in psb_driver_load()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers")
Reported-by: Hulk Robot
Signed-off-by: Jialin Zhang
---
drivers/gpu/drm/gma500/psb_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 34b4aae9a15e..074f403d7ca0 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -313,6 +313,8 @@ static int psb_driver_load(struct drm_device *dev, unsigned
long flags)
if (ret)
goto out_err;
+ ret = -ENOMEM;
+
dev_priv->mmu = psb_mmu_driver_init(dev, 1, 0, 0);
if (!dev_priv->mmu)
goto out_err;
--
2.25.1
Re: [PATCH] posix_acl.h: define missing ACL functions on non-posix-acl build
On 11/29/20 5:44 PM, Sergey Senozhatsky wrote:
> Some functions that are declared when CONFIG_POSIX_ACL is defined
> are not declared when CONFIG_POSIX_ACL is not defined. Add the
> missing ones:
> set_posix_acl(), posix_acl_update_mode(), get_cached_acl(),
> get_cached_acl_rcu(), set_cached_acl(), forget_cached_acl().
>
> Signed-off-by: Sergey Senozhatsky
Hi,
I can't find CONFIG_POSIX_ACL in the kernel source tree.
Should it be CONFIG_FS_POSIX_ACL ?
How did you test this?
> ---
> include/linux/posix_acl.h | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/include/linux/posix_acl.h b/include/linux/posix_acl.h
> index 90797f1b421d..f6d206359da5 100644
> --- a/include/linux/posix_acl.h
> +++ b/include/linux/posix_acl.h
> @@ -117,6 +117,39 @@ static inline int posix_acl_create(struct inode *inode,
> umode_t *mode,
> static inline void forget_all_cached_acls(struct inode *inode)
> {
> }
> +
> +static inline int set_posix_acl(struct inode *inode, int type,
> + struct posix_acl *acl)
> +{
> + return 0;
> +}
> +
> +static inline int posix_acl_update_mode(struct inode *, umode_t *,
> + struct posix_acl **)
> +{
> + return 0;
> +}
> +
> +static inline struct posix_acl *get_cached_acl(struct inode *inode,
> +int type)
> +{
> + return NULL;
> +}
> +
> +static inline struct posix_acl *get_cached_acl_rcu(struct inode *inode,
> +int type)
> +{
> + return NULL;
> +}
> +
> +static inline void set_cached_acl(struct inode *inode, int type,
> + struct posix_acl *acl)
> +{
> +}
> +
> +static inline void forget_cached_acl(struct inode *inode, int type)
> +{
> +}
> #endif /* CONFIG_FS_POSIX_ACL */
>
> struct posix_acl *get_acl(struct inode *inode, int type);
>
thanks.
--
~Randy
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/ibm/ibmvnic.c
between commit:
9281cf2d5840 ("ibmvnic: avoid memset null scrq msgs")
from the net tree and commit:
f019fb6392e5 ("ibmvnic: Introduce indirect subordinate Command Response Queue
buffer")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/ibm/ibmvnic.c
index bca1becd33f0,cdd1ff9aa9c4..
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@@ -2874,14 -2959,11 +2968,15 @@@ static int reset_one_sub_crq_queue(stru
irq_dispose_mapping(scrq->irq);
scrq->irq = 0;
}
-
- memset(scrq->msgs, 0, 4 * PAGE_SIZE);
- atomic_set(&scrq->used, 0);
- scrq->cur = 0;
- scrq->ind_buf.index = 0;
+ if (scrq->msgs) {
+ memset(scrq->msgs, 0, 4 * PAGE_SIZE);
+ atomic_set(&scrq->used, 0);
+ scrq->cur = 0;
++ scrq->ind_buf.index = 0;
+ } else {
+ netdev_dbg(adapter->netdev, "Invalid scrq reset\n");
+ return -EINVAL;
+ }
rc = h_reg_sub_crq(adapter->vdev->unit_address, scrq->msg_token,
4 * PAGE_SIZE, &scrq->crq_num, &scrq->hw_irq);
pgpTQRulbhg0E.pgp
Description: OpenPGP digital signature
[PATCH kernel] fs/io_ring: Fix lockdep warnings
There are a few potential deadlocks reported by lockdep and triggered by
syzkaller (a syscall fuzzer). These are reported as timer interrupts can
execute softirq handlers and if we were executing certain bits of io_ring,
a deadlock can occur. This fixes those bits by disabling soft interrupts.
Signed-off-by: Alexey Kardashevskiy
---
There are 2 reports.
Warning#1:
WARNING: inconsistent lock state
5.10.0-rc5_irqs_a+fstn1 #5 Not tainted
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/14/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
cb76f4a8 (&file_data->lock){+.?.}-{2:2}, at:
io_file_data_ref_zero+0x58/0x300
{SOFTIRQ-ON-W} state was registered at:
lock_acquire+0x2c4/0x5c0
_raw_spin_lock+0x54/0x80
sys_io_uring_register+0x1de0/0x2100
system_call_exception+0x160/0x240
system_call_common+0xf0/0x27c
irq event stamp: 4011767
hardirqs last enabled at (4011766): []
_raw_spin_unlock_irqrestore+0x54/0x90
hardirqs last disabled at (4011767): []
_raw_spin_lock_irqsave+0x48/0xb0
softirqs last enabled at (4011754): []
irq_enter_rcu+0xbc/0xc0
softirqs last disabled at (4011755): [] irq_exit+0x1d4/0x1e0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&file_data->lock);
lock(&file_data->lock);
*** DEADLOCK ***
2 locks held by swapper/14/0:
#0: c21cc3e8 (rcu_callback){}-{0:0}, at: rcu_core+0x2b0/0xfe0
#1: c21cc358 (rcu_read_lock){}-{1:2}, at:
percpu_ref_switch_to_atomic_rcu+0x148/0x400
stack backtrace:
CPU: 14 PID: 0 Comm: swapper/14 Not tainted 5.10.0-rc5_irqs_a+fstn1 #5
Call Trace:
[c97672c0] [c02b0268] print_usage_bug+0x3e8/0x3f0
[c9767360] [c02b0e88] mark_lock.part.48+0xc18/0xee0
[c9767480] [c02b1fb8] __lock_acquire+0xac8/0x21e0
[c97675d0] [c02b4454] lock_acquire+0x2c4/0x5c0
[c97676c0] [c167a38c] _raw_spin_lock_irqsave+0x7c/0xb0
[c9767700] [c07321b8] io_file_data_ref_zero+0x58/0x300
[c9767770] [c0be93e4]
percpu_ref_switch_to_atomic_rcu+0x3f4/0x400
[c9767800] [c02fe0d4] rcu_core+0x314/0xfe0
[c97678b0] [c167b5b8] __do_softirq+0x198/0x6c0
[c97679d0] [c020ba84] irq_exit+0x1d4/0x1e0
[c9767a00] [c00301c8] timer_interrupt+0x1e8/0x600
[c9767a70] [c0009d84] decrementer_common_virt+0x1e4/0x1f0
--- interrupt: 900 at snooze_loop+0xf4/0x300
LR = snooze_loop+0xe4/0x300
[c9767dc0] [c111b010] cpuidle_enter_state+0x520/0x910
[c9767e30] [c111b4c8] cpuidle_enter+0x58/0x80
[c9767e70] [c026da0c] call_cpuidle+0x4c/0x90
[c9767e90] [c026de80] do_idle+0x320/0x3d0
[c9767f10] [c026e308] cpu_startup_entry+0x38/0x50
[c9767f40] [c006f624] start_secondary+0x304/0x320
[c9767f90] [c000cc54] start_secondary_prolog+0x10/0x14
systemd[1]: systemd-udevd.service: Got notification message from PID 195
(WATCHDOG=1)
systemd-journald[175]: Sent WATCHDOG=1 notification.
Warning#2:
WARNING: inconsistent lock state
5.10.0-rc5_irqs_a+fstn1 #7 Not tainted
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/7/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
cc64b7a8 (&file_data->lock){+.?.}-{2:2}, at:
io_file_data_ref_zero+0x54/0x2d0
{SOFTIRQ-ON-W} state was registered at:
lock_acquire+0x2c4/0x5c0
_raw_spin_lock+0x54/0x80
io_sqe_files_unregister+0x5c/0x200
io_ring_exit_work+0x230/0x640
process_one_work+0x428/0xab0
worker_thread+0x94/0x770
kthread+0x204/0x210
ret_from_kernel_thread+0x5c/0x6c
irq event stamp: 3250736
hardirqs last enabled at (3250736): []
_raw_spin_unlock_irqrestore+0x54/0x90
hardirqs last disabled at (3250735): []
_raw_spin_lock_irqsave+0x48/0xb0
softirqs last enabled at (3250722): []
irq_enter_rcu+0xbc/0xc0
softirqs last disabled at (3250723): [] irq_exit+0x1d4/0x1e0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&file_data->lock);
lock(&file_data->lock);
*** DEADLOCK ***
2 locks held by swapper/7/0:
#0: c21cc3e8 (rcu_callback){}-{0:0}, at: rcu_core+0x2b0/0xfe0
#1: c21cc358 (rcu_read_lock){}-{1:2}, at:
percpu_ref_switch_to_atomic_rcu+0x148/0x400
stack backtrace:
CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.10.0-rc5_irqs_a+fstn1 #7
Call Trace:
[c974b280] [c02b0268] print_usage_bug+0x3e8/0x3f0
[c974b320] [c02b0e88] mark_lock.part.48+0xc18/0xee0
[c974b440] [c02b1fb8] __lock_acquire+0xac8/0x21e0
[c974b590] [c02b4454] lock_acquire+0x2c4/0x5c0
[c974b680] [c167a074] _raw_spin_lock+0x54/0x80
[c974b6b0] [c07321b4] io_file_data_ref_zero+0x54/0x2d0
[c974b720] [c0be93a4]
Re: [f2fs-dev] [PATCH] f2fs: add compr_inode and compr_blocks sysfs nodes
Sure, but I don't think we need to expose compr_inode and compr_block right now.
2020년 11월 27일 (금) 오후 6:44, Chao Yu 님이 작성:
>
> Daeho,
>
> How about updating this patch based on below patch?
>
> f2fs: introduce a new per-sb directory in sysfs
>
> On 2020/10/22 10:53, Daeho Jeong wrote:
> > Yep, It sounds good to me.
> >
> > 2020년 10월 21일 (수) 오후 3:08, Chao Yu 님이 작성:
> >>
> >> On 2020/10/16 13:14, Daeho Jeong wrote:
> >>> From: Daeho Jeong
> >>>
> >>> Added compr_inode to show compressed inode count and compr_blocks to
> >>> show compressed block count in sysfs.
> >>
> >> As there are so many entries in ../f2fs// directory, it looks a mess
> >> there, I suggest that we can add a new directory 'stats' in
> >> ../f2fs//,
> >> in where we can store all readonly stats related entries there later.
> >>
> >> How do you think?
> >>
> >> Thanks,
> >>
> >>>
> >>> Signed-off-by: Daeho Jeong
> >>> ---
> >>>Documentation/ABI/testing/sysfs-fs-f2fs | 10 ++
> >>>fs/f2fs/sysfs.c | 17 +
> >>>2 files changed, 27 insertions(+)
> >>>
> >>> diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
> >>> b/Documentation/ABI/testing/sysfs-fs-f2fs
> >>> index 834d0becae6d..a01c26484c69 100644
> >>> --- a/Documentation/ABI/testing/sysfs-fs-f2fs
> >>> +++ b/Documentation/ABI/testing/sysfs-fs-f2fs
> >>> @@ -350,3 +350,13 @@ Date:April 2020
> >>>Contact:"Daeho Jeong"
> >>>Description:Give a way to change iostat_period time. 3secs by
> >>> default.
> >>>The new iostat trace gives stats gap given the period.
> >>> +
> >>> +What:/sys/fs/f2fs//compr_inode
> >>> +Date:October 2020
> >>> +Contact: "Daeho Jeong"
> >>> +Description: Show compressed inode count
> >>> +
> >>> +What:/sys/fs/f2fs//compr_blocks
> >>> +Date:October 2020
> >>> +Contact: "Daeho Jeong"
> >>> +Description: Show compressed block count
> >>> diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
> >>> index 94c98e412aa1..7139a29a00d3 100644
> >>> --- a/fs/f2fs/sysfs.c
> >>> +++ b/fs/f2fs/sysfs.c
> >>> @@ -223,6 +223,19 @@ static ssize_t avg_vblocks_show(struct f2fs_attr *a,
> >>>f2fs_update_sit_info(sbi);
> >>>return sprintf(buf, "%llu\n", (unsigned long
> >>> long)(si->avg_vblocks));
> >>>}
> >>> +
> >>> +static ssize_t compr_inode_show(struct f2fs_attr *a,
> >>> + struct f2fs_sb_info *sbi, char *buf)
> >>> +{
> >>> + return sprintf(buf, "%u\n", atomic_read(&sbi->compr_inode));
> >>> +}
> >>> +
> >>> +static ssize_t compr_blocks_show(struct f2fs_attr *a,
> >>> + struct f2fs_sb_info *sbi, char *buf)
> >>> +{
> >>> + return sprintf(buf, "%llu\n", atomic64_read(&sbi->compr_blocks));
> >>> +}
> >>> +
> >>>#endif
> >>>
> >>>static ssize_t main_blkaddr_show(struct f2fs_attr *a,
> >>> @@ -591,6 +604,8 @@ F2FS_STAT_ATTR(STAT_INFO, f2fs_stat_info,
> >>> gc_background_calls, bg_gc);
> >>>F2FS_GENERAL_RO_ATTR(moved_blocks_background);
> >>>F2FS_GENERAL_RO_ATTR(moved_blocks_foreground);
> >>>F2FS_GENERAL_RO_ATTR(avg_vblocks);
> >>> +F2FS_GENERAL_RO_ATTR(compr_inode);
> >>> +F2FS_GENERAL_RO_ATTR(compr_blocks);
> >>>#endif
> >>>
> >>>#ifdef CONFIG_FS_ENCRYPTION
> >>> @@ -675,6 +690,8 @@ static struct attribute *f2fs_attrs[] = {
> >>>ATTR_LIST(moved_blocks_foreground),
> >>>ATTR_LIST(moved_blocks_background),
> >>>ATTR_LIST(avg_vblocks),
> >>> + ATTR_LIST(compr_inode),
> >>> + ATTR_LIST(compr_blocks),
> >>>#endif
> >>>NULL,
> >>>};
> >>>
> > .
> >
Re: [PATCH] arm64: dts: rockchip: rename sdhci nodename to mmc in rk3399.dtsi
On Mon, 16 Nov 2020 14:23:11 +0100, Johan Jonker wrote: > A test with the command below gives for example this error: > > /arch/arm64/boot/dts/rockchip/rk3399-evb.dt.yaml: > sdhci@fe33: $nodename:0: 'sdhci@fe33' > does not match '^mmc(@.*)?$' > > Fix it by renaming sdhci to mmc. > > [...] Applied, thanks! [1/1] arm64: dts: rockchip: rename sdhci nodename to mmc in rk3399.dtsi commit: 9a9f642784074d09efe9337e64b959f76c9f6913 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v5 0/7] Enable rk3066a HDMI sound
On Wed, 18 Nov 2020 14:58:15 +0100, Johan Jonker wrote: > First fix some legacy things in clk-rk3188.c that was never updated, > because probably nobody used rk3066a I2S before in the mainline kernel. > Update the rk3066a HDMI documents with a #sound-dai-cells property. > Include the code for sound in the HDMI driver. > Add a simple-sound-card compatible node to rk3066a.dtsi, > because I2S0 and HDMI TX are connected internally. > And as last enable rk3066a HDMI sound in the rk3066a-mk808.dts file. > > [...] Applied, thanks! [1/7] clk: rockchip: add CLK_SET_RATE_PARENT to sclk for rk3066a i2s and uart clocks commit: 5868491e1257786628fdd2457dfb77609f49f91d [2/7] clk: rockchip: fix i2s gate bits on rk3066 and rk3188 commit: caa2fd752ecb80faf7a2e1cdadc737187934675e Best regards, -- Heiko Stuebner
Re: [PATCH 0/3] arm64: dts: rockchip: rk3328-roc-cc: Misc improvements
On Thu, 26 Nov 2020 15:33:33 +0800, Chen-Yu Tsai wrote: > Here are some improvements for the ROC-RK3328-CC. > > Patch 1 sets dr_mode to "host" for OTG. Since the board has a type A > host port wired to the OTG controller, setting this is appropriate. > > Patch 2 enables HDMI audio. > > [...] Applied, thanks! [1/3] arm64: dts: rockchip: rk3328-roc-cc: Set dr_mode to "host" for OTG commit: 4076a007bd0f6171434bdb119a0b8797749b0502 [2/3] arm64: dts: rockchip: rk3328-roc-cc: Enable HDMI audio commit: 65f0b420dea7e70d70cd6ef0f12f9ff81ab90d23 [3/3] arm64: dts: rockchip: rk3328-roc-cc: Enable analog audio commit: 5df4d4d16ce4c6e6a5cb9d4b684b187f28258219 Best regards, -- Heiko Stuebner
Re: [PATCH 0/9] arm64: dts: rockchip: Engicam PX30.Core changes
On Mon, 9 Nov 2020 23:40:08 +0530, Jagan Teki wrote: > Series support Engicam PX30.Core SOM changes along with C.TOUCH > Open Frame 10.1" board. > > All respetive LCD panels are in Mainline already. > > thanks, > Jagan. > > [...] Applied, thanks! [1/9] arm64: dts: rockchip: px30-enagicam: Enable USB Host, OTG commit: 4548ea027c900f1e0f07a292b8e10dc3d2725f44 [2/9] arm64: dts: rockchip: px30-engicam-edimm2.2: Enable LVDS panel commit: 87761edeb2cd90b8251f269eb52c4b48152aace8 [3/9] dt-bindings: arm: rockchip: Add Engicam PX30.Core C.TOUCH 2.0 10.1" OF commit: 23708d46101b5d5538c88b84b764d0ed9d8957ca [4/9] arm64: dts: rockchip: Add Engicam PX30.Core C.TOUCH 2.0 10.1" OF commit: 0e418423be1c824b2cda37fd00528f62231cd219 [5/9] arm64: dts: rockchip: px30-engicam: Add WiFi support commit: 93a4e7d12468b0ab46796f3ed8dc5838dc7f63bc [6/9] arm64: dts: rockchip: px30-engicam: Add BT support commit: 1cc1e851d15b4ebd4c6c5f741cfdb58b988a4445 [7/9] arm64: defconfig: Enable ROCKCHIP_LVDS commit: dbb378a59cb2bdb01454098513d9b61355fbe377 [8/9] arm64: defconfig: Enable PHY_ROCKCHIP_INNO_DSIDPHY commit: ec68a66395d9ccedc9b2b2f6452edfd7cb0fdfd5 [9/9] arm64: defconfig: Enable USB_SERIAL_CP210X commit: cf35bff64f79b4ca8785766d67b608b76404d43f Best regards, -- Heiko Stuebner
Re: [PATCH] clk: rockchip: Remove redundant null check before clk_prepare_enable
On Fri, 27 Nov 2020 09:05:51 +, Xu Wang wrote: > Because clk_prepare_enable() already checked NULL clock parameter, > so the additional check is unnecessary, just remove it. Applied, thanks! [1/1] clk: rockchip: Remove redundant null check before clk_prepare_enable commit: 7f5b57a095f3b9532793d143655e83433bb448af Best regards, -- Heiko Stuebner
Re: [PATCH 2/3] powerpc/pseries/hotplug-cpu: fix memleak in dlpar_cpu_add_by_count
Qinglang Miao writes:
> kfree(cpu_drcs) should be called when it fails to perform
> of_find_node_by_path("/cpus") in dlpar_cpu_add_by_count,
> otherwise there would be a memleak.
>
> In fact, the patch a0ff72f9f5a7 ought to remove kfree in
> find_dlpar_cpus_to_add rather than dlpar_cpu_add_by_count.
> I guess there might be a mistake when apply that one.
>
> Fixes: a0ff72f9f5a7 ("powerpc/pseries/hotplug-cpu: Remove double free in
> error path")
> Reported-by: Hulk Robot
> Signed-off-by: Qinglang Miao
> ---
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 1 +
> 1 file changed, 1 insertion(+)
This is already fixed in my next by:
a40fdaf1420d ("Revert "powerpc/pseries/hotplug-cpu: Remove double free in
error path"")
cheers
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index f2837e33b..4bb1c9f2b 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -743,6 +743,7 @@ static int dlpar_cpu_add_by_count(u32 cpus_to_add)
> parent = of_find_node_by_path("/cpus");
> if (!parent) {
> pr_warn("Could not find CPU root node in device tree\n");
> + kfree(cpu_drcs);
> return -1;
> }
>
> --
> 2.23.0
[PATCH] posix_acl.h: define missing ACL functions on non-posix-acl build
Some functions that are declared when CONFIG_POSIX_ACL is defined
are not declared when CONFIG_POSIX_ACL is not defined. Add the
missing ones:
set_posix_acl(), posix_acl_update_mode(), get_cached_acl(),
get_cached_acl_rcu(), set_cached_acl(), forget_cached_acl().
Signed-off-by: Sergey Senozhatsky
---
include/linux/posix_acl.h | 33 +
1 file changed, 33 insertions(+)
diff --git a/include/linux/posix_acl.h b/include/linux/posix_acl.h
index 90797f1b421d..f6d206359da5 100644
--- a/include/linux/posix_acl.h
+++ b/include/linux/posix_acl.h
@@ -117,6 +117,39 @@ static inline int posix_acl_create(struct inode *inode,
umode_t *mode,
static inline void forget_all_cached_acls(struct inode *inode)
{
}
+
+static inline int set_posix_acl(struct inode *inode, int type,
+ struct posix_acl *acl)
+{
+ return 0;
+}
+
+static inline int posix_acl_update_mode(struct inode *, umode_t *,
+ struct posix_acl **)
+{
+ return 0;
+}
+
+static inline struct posix_acl *get_cached_acl(struct inode *inode,
+ int type)
+{
+ return NULL;
+}
+
+static inline struct posix_acl *get_cached_acl_rcu(struct inode *inode,
+ int type)
+{
+ return NULL;
+}
+
+static inline void set_cached_acl(struct inode *inode, int type,
+ struct posix_acl *acl)
+{
+}
+
+static inline void forget_cached_acl(struct inode *inode, int type)
+{
+}
#endif /* CONFIG_FS_POSIX_ACL */
struct posix_acl *get_acl(struct inode *inode, int type);
--
2.29.2
Re: [PATCH 0/5] Consolidate RPM interconnect and support to MSM8939
Georgi Djakov 于2020年11月26日周四 下午8:20写道： > > On 9/30/20 11:16, Jun Nie wrote: > > This patch set split shared RPM based interconnect operation code and add > > support to MSM8939 interconnect. > > > > Hi Jun, > > Are you planning to refresh this patchset? Yes. Just come back from a long vocation. Thanks for reminder! Jun > > Thanks, > Georgi
RE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt
> > > >>> Where did you get this information that the register on LS1043 > > > >>> and > > > >>> LS1046 is bit reversed? I cannot find such information in the RM. > > > >>> And does this mean all other SCFG registers are also bit reversed? > > > >>> If this is some information that is not covered by the RM, we > > > >>> probably should clarify it in the code and the commit message. > > > >> Hi Leo, > > > >> > > > >> I directly use the same logic to write the bit(field IRQ0~11INTP) > > > >> of the register SCFG_INTPCR in LS1043A and LS1046A. > > > >> Such as, > > > >> if I want to control the polarity of IRQ0(field IRQ0INTP, IRQ0 is > > > >> active low) of LS1043A/LS1046A, then I just need write a value 1 > > > >> << (31 - 0) > > > to it. > > > >> The logic depends on register's definition in LS1043A/LS1046A's RM. > > > > > > > > Ok. The SCFG_SCFGREVCR seems to be a one-off fixup only existed > > > > on > > > LS1021. And it is mandatory to be bit_reversed according to the RM > > > which is already taken care of in the RCW. So the bit reversed case > > > should be the only case supported otherwise a lot of other places > > > for SCFG access should be failed. > > > > > > > > I think we should remove the bit_reverse thing all together from > > > > the driver > > > for good. This will prevent future confusion. Rasmus, what do you think? > > > > > > Yes, all the ls1021a-derived boards I know of do have something like > > > > > > # Initialize bit reverse of SCFG registers > > > 09570200 > > > > > > in their pre-boot-loader config file. And yes, the RM does say > > > > > > This register must be written 0x_ as a part of > > > initialization sequence before writing to any other SCFG > > > register. > > > > > > but nowhere does it say "or else...", nor a little honest addendum > > > "because we accidentally released broken silicon with this > > > misfeature _and_ wrong POR value". > > > > Yeah. I do think they messed up at the beginning when trying to integrate > the big endian registers on little endian core. It is good that we are doing > it > correctly in later SoCs. > > > > > > > > Can we have an official statement from NXP stating that SCFGREVCR is > > > a hardware design bug? And can you send it through a time-machine so > > > I had it three years ago avoiding the whole "fsl,bit-reverse > > > device-tree-property, no, read the register if you're on a ls1021a and > > > decide" > hullabaloo. > > > > I'm not sure if it is possible to update the related documents right now > > for this. > But definitely it was not your fault to have introduced this in the driver > due to > the confusion from document. My suggestion to remove it is just to prevent > this from causing more confusions in the future as this driver is used on more > SoCs. > > Hi Biwen, > > Would you send a new version of this patch? Thanks. Hi Leo, sure, np. > > Regards, > Leo
[PATCH v2 15/15] usb: misc: usbtest: update to use the usb_control_msg_{send|recv}() API
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, instances of usb_control_msg() have been replaced with
usb_control_msg_{recv|send}() and the return value checking conditions have
also been modified appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/usbtest.c | 69 --
1 file changed, 29 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 150090ee4ec1..4337eff2a749 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -672,19 +672,15 @@ static int get_altsetting(struct usbtest_dev *dev)
struct usb_device *udev = interface_to_usbdev(iface);
int retval;
- retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
- USB_REQ_GET_INTERFACE, USB_DIR_IN|USB_RECIP_INTERFACE,
- 0, iface->altsetting[0].desc.bInterfaceNumber,
- dev->buf, 1, USB_CTRL_GET_TIMEOUT);
- switch (retval) {
- case 1:
- return dev->buf[0];
- case 0:
- retval = -ERANGE;
- fallthrough;
- default:
+ retval = usb_control_msg_recv(udev, 0, USB_REQ_GET_INTERFACE,
+ USB_DIR_IN|USB_RECIP_INTERFACE,
+ 0,
iface->altsetting[0].desc.bInterfaceNumber,
+ dev->buf, 1, USB_CTRL_GET_TIMEOUT,
GFP_KERNEL);
+
+ if (retval < 0)
return retval;
- }
+
+ return dev->buf[0];
}
static int set_altsetting(struct usbtest_dev *dev, int alternate)
@@ -872,14 +868,15 @@ static int ch9_postconfig(struct usbtest_dev *dev)
* ... although some cheap devices (like one TI Hub I've got)
* won't return config descriptors except before set_config.
*/
- retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
- USB_REQ_GET_CONFIGURATION,
- USB_DIR_IN | USB_RECIP_DEVICE,
- 0, 0, dev->buf, 1, USB_CTRL_GET_TIMEOUT);
- if (retval != 1 || dev->buf[0] != expected) {
+ retval = usb_control_msg_recv(udev, 0,
USB_REQ_GET_CONFIGURATION,
+ USB_DIR_IN | USB_RECIP_DEVICE, 0,
+ 0, dev->buf, 1,
USB_CTRL_GET_TIMEOUT,
+ GFP_KERNEL);
+
+ if (retval != 0 || dev->buf[0] != expected) {
dev_err(&iface->dev, "get config --> %d %d (1 %d)\n",
retval, dev->buf[0], expected);
- return (retval < 0) ? retval : -EDOM;
+ return retval;
}
}
@@ -1683,10 +1680,10 @@ static int test_halt(struct usbtest_dev *tdev, int ep,
struct urb *urb)
return retval;
/* set halt (protocol test only), verify it worked */
- retval = usb_control_msg(urb->dev, usb_sndctrlpipe(urb->dev, 0),
- USB_REQ_SET_FEATURE, USB_RECIP_ENDPOINT,
- USB_ENDPOINT_HALT, ep,
- NULL, 0, USB_CTRL_SET_TIMEOUT);
+ retval = usb_control_msg_send(urb->dev, 0, USB_REQ_SET_FEATURE,
+ USB_RECIP_ENDPOINT, USB_ENDPOINT_HALT,
+ ep, NULL, 0, USB_CTRL_SET_TIMEOUT,
+ GFP_KERNEL);
if (retval < 0) {
ERROR(tdev, "ep %02x couldn't set halt, %d\n", ep, retval);
return retval;
@@ -1845,30 +1842,22 @@ static int ctrl_out(struct usbtest_dev *dev,
/* write patterned data */
for (j = 0; j < len; j++)
buf[j] = (u8)(i + j);
- retval = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
- 0x5b, USB_DIR_OUT|USB_TYPE_VENDOR,
- 0, 0, buf, len, USB_CTRL_SET_TIMEOUT);
- if (retval != len) {
+ retval = usb_control_msg_send(udev, 0, 0x5b,
+ USB_DIR_OUT | USB_TYPE_VENDOR, 0,
+ 0, buf, len, USB_CTRL_SET_TIMEOUT,
+ GFP_KERNEL);
+ if (retval < 0) {
what = "write";
- if (retval >= 0) {
- ERROR(dev, "ctrl_out, wlen %d (expected %d)\n",
- retval, len);
- retval = -EBADMSG;
-
[PATCH v2 14/15] usb: misc: usbsevseg: update to use usb_control_msg_send()
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, instances of usb_control_msg() have been replaced with
usb_control_msg_send() appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/usbsevseg.c | 60 ++--
1 file changed, 17 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/misc/usbsevseg.c b/drivers/usb/misc/usbsevseg.c
index 551074f5b7ad..ade4bc58d5f2 100644
--- a/drivers/usb/misc/usbsevseg.c
+++ b/drivers/usb/misc/usbsevseg.c
@@ -74,15 +74,10 @@ static void update_display_powered(struct usb_sevsegdev
*mydev)
if (mydev->shadow_power != 1)
return;
- rc = usb_control_msg(mydev->udev,
- usb_sndctrlpipe(mydev->udev, 0),
- 0x12,
- 0x48,
- (80 * 0x100) + 10, /* (power mode) */
- (0x00 * 0x100) + (mydev->powered ? 1 : 0),
- NULL,
- 0,
- 2000);
+ rc = usb_control_msg_send(mydev->udev, 0, 0x12, 0x48,
+ (80 * 0x100) + 10, /* (power mode) */
+ (0x00 * 0x100) + (mydev->powered ? 1 : 0),
+ NULL, 0, 2000, GFP_KERNEL);
if (rc < 0)
dev_dbg(&mydev->udev->dev, "power retval = %d\n", rc);
@@ -99,15 +94,10 @@ static void update_display_mode(struct usb_sevsegdev *mydev)
if(mydev->shadow_power != 1)
return;
- rc = usb_control_msg(mydev->udev,
- usb_sndctrlpipe(mydev->udev, 0),
- 0x12,
- 0x48,
- (82 * 0x100) + 10, /* (set mode) */
- (mydev->mode_msb * 0x100) + mydev->mode_lsb,
- NULL,
- 0,
- 2000);
+ rc = usb_control_msg_send(mydev->udev, 0, 0x12, 0x48,
+ (82 * 0x100) + 10, /* (set mode) */
+ (mydev->mode_msb * 0x100) + mydev->mode_lsb,
+ NULL, 0, 2000, GFP_KERNEL);
if (rc < 0)
dev_dbg(&mydev->udev->dev, "mode retval = %d\n", rc);
@@ -117,48 +107,32 @@ static void update_display_visual(struct usb_sevsegdev
*mydev, gfp_t mf)
{
int rc;
int i;
- unsigned char *buffer;
+ unsigned char buffer[MAXLEN] = {0};
u8 decimals = 0;
if(mydev->shadow_power != 1)
return;
- buffer = kzalloc(MAXLEN, mf);
- if (!buffer)
- return;
-
/* The device is right to left, where as you write left to right */
for (i = 0; i < mydev->textlength; i++)
buffer[i] = mydev->text[mydev->textlength-1-i];
- rc = usb_control_msg(mydev->udev,
- usb_sndctrlpipe(mydev->udev, 0),
- 0x12,
- 0x48,
- (85 * 0x100) + 10, /* (write text) */
- (0 * 0x100) + mydev->textmode, /* mode */
- buffer,
- mydev->textlength,
- 2000);
+ rc = usb_control_msg_send(mydev->udev, 0, 0x12, 0x48,
+ (85 * 0x100) + 10, /* (write text) */
+ (0 * 0x100) + mydev->textmode, /* mode */
+ &buffer, mydev->textlength, 2000, mf);
if (rc < 0)
dev_dbg(&mydev->udev->dev, "write retval = %d\n", rc);
- kfree(buffer);
-
/* The device is right to left, where as you write left to right */
for (i = 0; i < sizeof(mydev->decimals); i++)
decimals |= mydev->decimals[i] << i;
- rc = usb_control_msg(mydev->udev,
- usb_sndctrlpipe(mydev->udev, 0),
- 0x12,
- 0x48,
- (86 * 0x100) + 10, /* (set decimal) */
- (0 * 0x100) + decimals, /* decimals */
- NULL,
- 0,
- 2000);
+ rc = usb_control_msg_send(mydev->udev, 0, 0x12, 0x48,
+ (86 * 0x100) + 10, /* (set decimal) */
+ (0 * 0x100) + decimals, /* decimals */
+ NULL, 0, 2000, mf);
if (rc < 0)
dev_dbg(&mydev->udev->dev, "decimal retval = %d\n", rc);
--
2.25.1
Re: [PATCH 1/1] ktest.pl: Fix incorrect reboot for grub2bls
On Fri, Nov 20, 2020 at 06:12:43PM -0800, Libo Chen wrote:
> This issue was first noticed when I was testing different kernels on
> Oracle Linux 8 which as Fedora 30+ adopts BLS as default. Even though a
> kernel entry was added successfully and the index of that kernel entry was
> retrieved correctly, ktest still wouldn't reboot the system into
> user-specified kernel.
>
> The bug was spotted in subroutine reboot_to where the if-statement never
> checks for REBOOT_TYPE "grub2bls", therefore the desired entry will not be
> set for the next boot.
>
> Add a check for "grub2bls" so that $grub_reboot $grub_number can
> be run before a reboot if REBOOT_TYPE is "grub2bls" then we can boot to
> the correct kernel.
>
> Fixes: ac2466456eaa ("ktest: introduce grub2bls REBOOT_TYPE option")
>
> Signed-off-by: Libo Chen
Thank you for the fix!
I tested the patch with fedora33. It works well.
Please feel free to add:
Tested-by: Masayoshi Mizuma
Thanks!
Masa
> ---
> tools/testing/ktest/ktest.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
> index cb16d2aac51c..54188ee16c48 100755
> --- a/tools/testing/ktest/ktest.pl
> +++ b/tools/testing/ktest/ktest.pl
> @@ -2040,7 +2040,7 @@ sub reboot_to {
>
> if ($reboot_type eq "grub") {
> run_ssh "'(echo \"savedefault --default=$grub_number --once\" | grub
> --batch)'";
> -} elsif ($reboot_type eq "grub2") {
> +} elsif (($reboot_type eq "grub2") or ($reboot_type eq "grub2bls")) {
> run_ssh "$grub_reboot $grub_number";
> } elsif ($reboot_type eq "syslinux") {
> run_ssh "$syslinux --once \\\"$syslinux_label\\\" $syslinux_path";
> --
> 2.27.0
>
[PATCH v2 13/15] usb: misc: trancevibrator: update to use usb_control_msg_send()
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, the instance of usb_control_msg() has been replaced with
usb_control_msg_send() and the return value checking condition has also
been modified appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/trancevibrator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/misc/trancevibrator.c
b/drivers/usb/misc/trancevibrator.c
index a3dfc77578ea..c50807b4f4ef 100644
--- a/drivers/usb/misc/trancevibrator.c
+++ b/drivers/usb/misc/trancevibrator.c
@@ -59,11 +59,11 @@ static ssize_t speed_store(struct device *dev, struct
device_attribute *attr,
dev_dbg(&tv->udev->dev, "speed = %d\n", tv->speed);
/* Set speed */
- retval = usb_control_msg(tv->udev, usb_sndctrlpipe(tv->udev, 0),
+ retval = usb_control_msg_send(tv->udev, 0,
0x01, /* vendor request: set speed */
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
tv->speed, /* speed value */
-0, NULL, 0, USB_CTRL_GET_TIMEOUT);
+0, NULL, 0, USB_CTRL_GET_TIMEOUT, GFP_KERNEL);
if (retval) {
tv->speed = old;
dev_dbg(&tv->udev->dev, "retval = %d\n", retval);
--
2.25.1
[PATCH v2 11/15] usb: misc: ldusb: update to use usb_control_msg_send()
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, the instance of usb_control_msg_send() has been replaced
with usb_control_msg_send() appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/ldusb.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/misc/ldusb.c b/drivers/usb/misc/ldusb.c
index 670e4d91e9ca..259ead4edecb 100644
--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -573,15 +573,13 @@ static ssize_t ld_usb_write(struct file *file, const char
__user *buffer,
}
if (dev->interrupt_out_endpoint == NULL) {
- /* try HID_REQ_SET_REPORT=9 on control_endpoint instead of
interrupt_out_endpoint */
- retval = usb_control_msg(interface_to_usbdev(dev->intf),
-
usb_sndctrlpipe(interface_to_usbdev(dev->intf), 0),
-9,
+ retval = usb_control_msg_send(interface_to_usbdev(dev->intf),
+0, 9,
USB_TYPE_CLASS | USB_RECIP_INTERFACE |
USB_DIR_OUT,
1 << 8, 0,
dev->interrupt_out_buffer,
bytes_to_write,
-USB_CTRL_SET_TIMEOUT);
+USB_CTRL_SET_TIMEOUT, GFP_KERNEL);
if (retval < 0)
dev_err(&dev->intf->dev,
"Couldn't submit HID_REQ_SET_REPORT %d\n",
--
2.25.1
[PATCH v2 12/15] usb: misc: lvstest: update to use the usb_control_msg_{send|recv}() API
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, instances of usb_control_msg() have been replaced with
usb_control_msg_{recv|send}() and the return value checking conditions have
also been modified appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/lvstest.c | 38 --
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/misc/lvstest.c b/drivers/usb/misc/lvstest.c
index f8686139d6f3..daa1b2c9139f 100644
--- a/drivers/usb/misc/lvstest.c
+++ b/drivers/usb/misc/lvstest.c
@@ -85,17 +85,17 @@ static void destroy_lvs_device(struct usb_device *udev)
static int lvs_rh_clear_port_feature(struct usb_device *hdev,
int port1, int feature)
{
- return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
+ return usb_control_msg_send(hdev, 0,
USB_REQ_CLEAR_FEATURE, USB_RT_PORT, feature, port1,
- NULL, 0, 1000);
+ NULL, 0, 1000, GFP_KERNEL);
}
static int lvs_rh_set_port_feature(struct usb_device *hdev,
int port1, int feature)
{
- return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
+ return usb_control_msg_send(hdev, 0,
USB_REQ_SET_FEATURE, USB_RT_PORT, feature, port1,
- NULL, 0, 1000);
+ NULL, 0, 1000, GFP_KERNEL);
}
static ssize_t u3_entry_store(struct device *dev,
@@ -257,13 +257,9 @@ static ssize_t get_dev_desc_store(struct device *dev,
{
struct usb_interface *intf = to_usb_interface(dev);
struct usb_device *udev;
- struct usb_device_descriptor *descriptor;
+ struct usb_device_descriptor descriptor;
int ret;
- descriptor = kmalloc(sizeof(*descriptor), GFP_KERNEL);
- if (!descriptor)
- return -ENOMEM;
-
udev = create_lvs_device(intf);
if (!udev) {
dev_err(dev, "failed to create lvs device\n");
@@ -271,18 +267,16 @@ static ssize_t get_dev_desc_store(struct device *dev,
goto free_desc;
}
- ret = usb_control_msg(udev, (PIPE_CONTROL << 30) | USB_DIR_IN,
- USB_REQ_GET_DESCRIPTOR, USB_DIR_IN, USB_DT_DEVICE << 8,
- 0, descriptor, sizeof(*descriptor),
- USB_CTRL_GET_TIMEOUT);
+ ret = usb_control_msg_recv(udev, 0, USB_REQ_GET_DESCRIPTOR,
+ USB_DIR_IN, USB_DT_DEVICE << 8,
+ 0, &descriptor, sizeof(descriptor),
+ USB_CTRL_GET_TIMEOUT, GFP_KERNEL);
if (ret < 0)
dev_err(dev, "can't read device descriptor %d\n", ret);
destroy_lvs_device(udev);
free_desc:
- kfree(descriptor);
-
if (ret < 0)
return ret;
@@ -336,10 +330,10 @@ static void lvs_rh_work(struct work_struct *work)
/* Examine each root port */
for (i = 1; i <= descriptor->bNbrPorts; i++) {
- ret = usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),
+ ret = usb_control_msg_recv(hdev, 0,
USB_REQ_GET_STATUS, USB_DIR_IN | USB_RT_PORT, 0, i,
- port_status, sizeof(*port_status), 1000);
- if (ret < 4)
+ port_status, sizeof(*port_status), 1000, GFP_KERNEL);
+ if (ret < 0)
continue;
portchange = le16_to_cpu(port_status->wPortChange);
@@ -420,13 +414,13 @@ static int lvs_rh_probe(struct usb_interface *intf,
usb_set_intfdata(intf, lvs);
/* how many number of ports this root hub has */
- ret = usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),
+ ret = usb_control_msg_recv(hdev, 0,
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN | USB_RT_HUB,
USB_DT_SS_HUB << 8, 0, &lvs->descriptor,
- USB_DT_SS_HUB_SIZE, USB_CTRL_GET_TIMEOUT);
- if (ret < (USB_DT_HUB_NONVAR_SIZE + 2)) {
+ USB_DT_SS_HUB_SIZE, USB_CTRL_GET_TIMEOUT, GFP_KERNEL);
+ if (ret < 0) {
dev_err(&hdev->dev, "wrong root hub descriptor read %d\n", ret);
- return ret < 0 ? ret : -EINVAL;
+ return ret;
}
/* submit urb to poll interrupt endpoint */
--
2.25.1
[PATCH v2 10/15] usb: misc: isight_firmware: update to use usb_control_msg_send()
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, the instances of usb_control_msg() have been replaced with
usb_control_msg_send(), and return value checking has also been
appropriately enforced.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/isight_firmware.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/misc/isight_firmware.c
b/drivers/usb/misc/isight_firmware.c
index 4d30095d6ad2..1bd14a431f6c 100644
--- a/drivers/usb/misc/isight_firmware.c
+++ b/drivers/usb/misc/isight_firmware.c
@@ -37,13 +37,10 @@ static int isight_firmware_load(struct usb_interface *intf,
struct usb_device *dev = interface_to_usbdev(intf);
int llen, len, req, ret = 0;
const struct firmware *firmware;
- unsigned char *buf = kmalloc(50, GFP_KERNEL);
+ unsigned char buf[50];
unsigned char data[4];
const u8 *ptr;
- if (!buf)
- return -ENOMEM;
-
if (request_firmware(&firmware, "isight.fw", &dev->dev) != 0) {
printk(KERN_ERR "Unable to load isight firmware\n");
ret = -ENODEV;
@@ -53,11 +50,11 @@ static int isight_firmware_load(struct usb_interface *intf,
ptr = firmware->data;
buf[0] = 0x01;
- if (usb_control_msg
- (dev, usb_sndctrlpipe(dev, 0), 0xa0, 0x40, 0xe600, 0, buf, 1,
-300) != 1) {
+ ret = usb_control_msg_send(dev, 0, 0xa0, 0x40, 0xe600,
+ 0, &buf, 1, 300, GFP_KERNEL);
+ if (ret != 0) {
printk(KERN_ERR
- "Failed to initialise isight firmware loader\n");
+ "Failed to initialise isight firmware loader\n");
ret = -ENODEV;
goto out;
}
@@ -82,15 +79,15 @@ static int isight_firmware_load(struct usb_interface *intf,
ret = -ENODEV;
goto out;
}
- memcpy(buf, ptr, llen);
+ memcpy(&buf, ptr, llen);
ptr += llen;
- if (usb_control_msg
- (dev, usb_sndctrlpipe(dev, 0), 0xa0, 0x40, req, 0,
-buf, llen, 300) != llen) {
+ ret = usb_control_msg_send(dev, 0, 0xa0, 0x40, req, 0,
+ &buf, llen, 300, GFP_KERNEL);
+ if (ret != 0) {
printk(KERN_ERR
- "Failed to load isight firmware\n");
+ "Failed to load isight firmware\n");
ret = -ENODEV;
goto out;
}
@@ -99,15 +96,14 @@ static int isight_firmware_load(struct usb_interface *intf,
}
buf[0] = 0x00;
- if (usb_control_msg
- (dev, usb_sndctrlpipe(dev, 0), 0xa0, 0x40, 0xe600, 0, buf, 1,
-300) != 1) {
+ ret = usb_control_msg_send(dev, 0, 0xa0, 0x40, 0xe600,
+ 0, &buf, 1, 300, GFP_KERNEL);
+ if (ret != 0) {
printk(KERN_ERR "isight firmware loading completion failed\n");
ret = -ENODEV;
}
out:
- kfree(buf);
release_firmware(firmware);
return ret;
}
--
2.25.1
[PATCH v2 09/15] usb: misc: iowarrior: update to use the usb_control_msg_{send|recv}() API
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, instances of usb_control_msg() have been replaced with
usb_control_msg_{recv|send}() appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/iowarrior.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c
index 70ec29681526..53726fffe5df 100644
--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -109,12 +109,12 @@ static int usb_get_report(struct usb_device *dev,
struct usb_host_interface *inter, unsigned char type,
unsigned char id, void *buf, int size)
{
- return usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
- USB_REQ_GET_REPORT,
- USB_DIR_IN | USB_TYPE_CLASS |
- USB_RECIP_INTERFACE, (type << 8) + id,
- inter->desc.bInterfaceNumber, buf, size,
- GET_TIMEOUT*HZ);
+ return usb_control_msg_recv(dev, 0,
+ USB_REQ_GET_REPORT,
+ USB_DIR_IN | USB_TYPE_CLASS |
+ USB_RECIP_INTERFACE, (type << 8) + id,
+ inter->desc.bInterfaceNumber, buf, size,
+ GET_TIMEOUT*HZ, GFP_KERNEL);
}
//#endif
@@ -123,13 +123,13 @@ static int usb_get_report(struct usb_device *dev,
static int usb_set_report(struct usb_interface *intf, unsigned char type,
unsigned char id, void *buf, int size)
{
- return usb_control_msg(interface_to_usbdev(intf),
- usb_sndctrlpipe(interface_to_usbdev(intf), 0),
- USB_REQ_SET_REPORT,
- USB_TYPE_CLASS | USB_RECIP_INTERFACE,
- (type << 8) + id,
- intf->cur_altsetting->desc.bInterfaceNumber, buf,
- size, HZ);
+ return usb_control_msg_send(interface_to_usbdev(intf),
+ 0,
+ USB_REQ_SET_REPORT,
+ USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+ (type << 8) + id,
+
intf->cur_altsetting->desc.bInterfaceNumber, buf,
+ size, HZ, GFP_KERNEL);
}
/*-*/
@@ -854,10 +854,10 @@ static int iowarrior_probe(struct usb_interface
*interface,
/* Set the idle timeout to 0, if this is interface 0 */
if (dev->interface->cur_altsetting->desc.bInterfaceNumber == 0) {
- usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
- 0x0A,
- USB_TYPE_CLASS | USB_RECIP_INTERFACE, 0,
- 0, NULL, 0, USB_CTRL_SET_TIMEOUT);
+ usb_control_msg_send(udev, 0,
+0x0A,
+USB_TYPE_CLASS | USB_RECIP_INTERFACE, 0,
+0, NULL, 0, USB_CTRL_SET_TIMEOUT,
GFP_KERNEL);
}
/* allow device read and ioctl */
dev->present = 1;
--
2.25.1
[PATCH v2 08/15] usb: misc: idmouse: update to use usb_control_msg_send()
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, the instance of usb_control_msg() has been replaced with
usb_control_msg_send() appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/idmouse.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/misc/idmouse.c b/drivers/usb/misc/idmouse.c
index e9437a176518..52126441a633 100644
--- a/drivers/usb/misc/idmouse.c
+++ b/drivers/usb/misc/idmouse.c
@@ -56,8 +56,9 @@ static const struct usb_device_id idmouse_table[] = {
#define FTIP_SCROLL 0x24
#define ftip_command(dev, command, value, index) \
- usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0), command, \
- USB_TYPE_VENDOR | USB_RECIP_ENDPOINT | USB_DIR_OUT, value, index, NULL,
0, 1000)
+ usb_control_msg_send(dev->udev, 0, command, \
+ USB_TYPE_VENDOR | USB_RECIP_ENDPOINT | USB_DIR_OUT, \
+ value, index, NULL, 0, 1000, GFP_KERNEL)
MODULE_DEVICE_TABLE(usb, idmouse_table);
--
2.25.1
[PATCH v2 07/15] usb: misc: ezusb: update to use usb_control_msg_send()
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, the instance of usb_control_msg() has been replaced with
usb_control_msg_send() appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/ezusb.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/misc/ezusb.c b/drivers/usb/misc/ezusb.c
index f058d8029761..78aaee56c2b7 100644
--- a/drivers/usb/misc/ezusb.c
+++ b/drivers/usb/misc/ezusb.c
@@ -31,24 +31,12 @@ static const struct ezusb_fx_type ezusb_fx1 = {
static int ezusb_writememory(struct usb_device *dev, int address,
unsigned char *data, int length, __u8 request)
{
- int result;
- unsigned char *transfer_buffer;
-
if (!dev)
return -ENODEV;
- transfer_buffer = kmemdup(data, length, GFP_KERNEL);
- if (!transfer_buffer) {
- dev_err(&dev->dev, "%s - kmalloc(%d) failed.\n",
- __func__, length);
- return -ENOMEM;
- }
- result = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), request,
+ return usb_control_msg_send(dev, 0, request,
USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
-address, 0, transfer_buffer, length, 3000);
-
- kfree(transfer_buffer);
- return result;
+address, 0, data, length, 3000, GFP_KERNEL);
}
static int ezusb_set_reset(struct usb_device *dev, unsigned short cpucs_reg,
--
2.25.1
[PATCH v2 06/15] usb: misc: emi62: update to use usb_control_msg_send()
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, the instance of usb_control_msg() has been replaced with
usb_control_msg_send() appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/emi62.c | 30 +++---
1 file changed, 7 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/misc/emi62.c b/drivers/usb/misc/emi62.c
index 3eea60437f56..6ac4e72d53e0 100644
--- a/drivers/usb/misc/emi62.c
+++ b/drivers/usb/misc/emi62.c
@@ -36,7 +36,7 @@
#define INTERNAL_RAM(address) (address <= MAX_INTERNAL_ADDRESS)
static int emi62_writememory(struct usb_device *dev, int address,
-const unsigned char *data, int length,
+const void *data, int length,
__u8 bRequest);
static int emi62_set_reset(struct usb_device *dev, unsigned char reset_bit);
static int emi62_load_firmware (struct usb_device *dev);
@@ -45,21 +45,11 @@ static void emi62_disconnect(struct usb_interface *intf);
/* thanks to drivers/usb/serial/keyspan_pda.c code */
static int emi62_writememory(struct usb_device *dev, int address,
-const unsigned char *data, int length,
+const void *data, int length,
__u8 request)
{
- int result;
- unsigned char *buffer = kmemdup(data, length, GFP_KERNEL);
-
- if (!buffer) {
- dev_err(&dev->dev, "kmalloc(%d) failed.\n", length);
- return -ENOMEM;
- }
- /* Note: usb_control_msg returns negative value on error or length of
the
-* data that was written! */
- result = usb_control_msg (dev, usb_sndctrlpipe(dev, 0), request, 0x40,
address, 0, buffer, length, 300);
- kfree (buffer);
- return result;
+ return usb_control_msg_send(dev, 0, request, 0x40, address,
+ 0, data, length, 300, GFP_KERNEL);
}
/* thanks to drivers/usb/serial/keyspan_pda.c code */
@@ -85,12 +75,9 @@ static int emi62_load_firmware (struct usb_device *dev)
int err = -ENOMEM;
int i;
__u32 addr; /* Address to write */
- __u8 *buf;
+ __u8 buf[FW_LOAD_SIZE];
dev_dbg(&dev->dev, "load_firmware\n");
- buf = kmalloc(FW_LOAD_SIZE, GFP_KERNEL);
- if (!buf)
- goto wraperr;
err = request_ihex_firmware(&loader_fw, "emi62/loader.fw", &dev->dev);
if (err)
@@ -140,11 +127,11 @@ static int emi62_load_firmware (struct usb_device *dev)
/* intel hex records are terminated with type 0 element */
while (rec && (i + be16_to_cpu(rec->len) < FW_LOAD_SIZE)) {
- memcpy(buf + i, rec->data, be16_to_cpu(rec->len));
+ memcpy(&buf[i], rec->data, be16_to_cpu(rec->len));
i += be16_to_cpu(rec->len);
rec = ihex_next_binrec(rec);
}
- err = emi62_writememory(dev, addr, buf, i, ANCHOR_LOAD_FPGA);
+ err = emi62_writememory(dev, addr, &buf, i, ANCHOR_LOAD_FPGA);
if (err < 0)
goto wraperr;
} while (rec);
@@ -209,8 +196,6 @@ static int emi62_load_firmware (struct usb_device *dev)
release_firmware(bitstream_fw);
release_firmware(firmware_fw);
- kfree(buf);
-
/* return 1 to fail the driver inialization
* and give real driver change to load */
return 1;
@@ -223,7 +208,6 @@ static int emi62_load_firmware (struct usb_device *dev)
release_firmware(bitstream_fw);
release_firmware(firmware_fw);
- kfree(buf);
dev_err(&dev->dev, "Error\n");
return err;
}
--
2.25.1
[PATCH v2 05/15] usb: misc: emi26: update to use usb_control_msg_send()
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, the instance of usb_control_msg() has been replaced with
usb_control_msg_send() appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/emi26.c | 31 ---
1 file changed, 8 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/misc/emi26.c b/drivers/usb/misc/emi26.c
index 24d841850e05..1dd024507f40 100644
--- a/drivers/usb/misc/emi26.c
+++ b/drivers/usb/misc/emi26.c
@@ -27,7 +27,7 @@
#define INTERNAL_RAM(address) (address <= MAX_INTERNAL_ADDRESS)
static int emi26_writememory( struct usb_device *dev, int address,
- const unsigned char *data, int length,
+ const void *data, int length,
__u8 bRequest);
static int emi26_set_reset(struct usb_device *dev, unsigned char reset_bit);
static int emi26_load_firmware (struct usb_device *dev);
@@ -35,22 +35,12 @@ static int emi26_probe(struct usb_interface *intf, const
struct usb_device_id *i
static void emi26_disconnect(struct usb_interface *intf);
/* thanks to drivers/usb/serial/keyspan_pda.c code */
-static int emi26_writememory (struct usb_device *dev, int address,
- const unsigned char *data, int length,
+static int emi26_writememory(struct usb_device *dev, int address,
+ const void *data, int length,
__u8 request)
{
- int result;
- unsigned char *buffer = kmemdup(data, length, GFP_KERNEL);
-
- if (!buffer) {
- dev_err(&dev->dev, "kmalloc(%d) failed.\n", length);
- return -ENOMEM;
- }
- /* Note: usb_control_msg returns negative value on error or length of
the
-* data that was written! */
- result = usb_control_msg (dev, usb_sndctrlpipe(dev, 0), request, 0x40,
address, 0, buffer, length, 300);
- kfree (buffer);
- return result;
+ return usb_control_msg_send(dev, 0, request, 0x40, address, 0,
+ data, length, 300, GFP_KERNEL);
}
/* thanks to drivers/usb/serial/keyspan_pda.c code */
@@ -77,11 +67,7 @@ static int emi26_load_firmware (struct usb_device *dev)
int err = -ENOMEM;
int i;
__u32 addr; /* Address to write */
- __u8 *buf;
-
- buf = kmalloc(FW_LOAD_SIZE, GFP_KERNEL);
- if (!buf)
- goto wraperr;
+ __u8 buf[FW_LOAD_SIZE];
err = request_ihex_firmware(&loader_fw, "emi26/loader.fw", &dev->dev);
if (err)
@@ -133,11 +119,11 @@ static int emi26_load_firmware (struct usb_device *dev)
/* intel hex records are terminated with type 0 element */
while (rec && (i + be16_to_cpu(rec->len) < FW_LOAD_SIZE)) {
- memcpy(buf + i, rec->data, be16_to_cpu(rec->len));
+ memcpy(&buf[i], rec->data, be16_to_cpu(rec->len));
i += be16_to_cpu(rec->len);
rec = ihex_next_binrec(rec);
}
- err = emi26_writememory(dev, addr, buf, i, ANCHOR_LOAD_FPGA);
+ err = emi26_writememory(dev, addr, &buf, i, ANCHOR_LOAD_FPGA);
if (err < 0)
goto wraperr;
} while (rec);
@@ -211,7 +197,6 @@ static int emi26_load_firmware (struct usb_device *dev)
release_firmware(bitstream_fw);
release_firmware(firmware_fw);
- kfree(buf);
return err;
}
--
2.25.1
[PATCH v2 04/15] usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, instances of usb_control_msg() have been replaced with
usb_control_msg_{recv|send}() appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/ehset.c | 76 +---
1 file changed, 32 insertions(+), 44 deletions(-)
diff --git a/drivers/usb/misc/ehset.c b/drivers/usb/misc/ehset.c
index 2752e1f4f4d0..f87890f9cd26 100644
--- a/drivers/usb/misc/ehset.c
+++ b/drivers/usb/misc/ehset.c
@@ -24,68 +24,57 @@ static int ehset_probe(struct usb_interface *intf,
int ret = -EINVAL;
struct usb_device *dev = interface_to_usbdev(intf);
struct usb_device *hub_udev = dev->parent;
- struct usb_device_descriptor *buf;
+ struct usb_device_descriptor buf;
u8 portnum = dev->portnum;
u16 test_pid = le16_to_cpu(dev->descriptor.idProduct);
switch (test_pid) {
case TEST_SE0_NAK_PID:
- ret = usb_control_msg(hub_udev, usb_sndctrlpipe(hub_udev, 0),
- USB_REQ_SET_FEATURE, USB_RT_PORT,
- USB_PORT_FEAT_TEST,
- (USB_TEST_SE0_NAK << 8) | portnum,
- NULL, 0, 1000);
+ ret = usb_control_msg_send(hub_udev, 0, USB_REQ_SET_FEATURE,
+ USB_RT_PORT, USB_PORT_FEAT_TEST,
+ (USB_TEST_SE0_NAK << 8) | portnum,
+ NULL, 0, 1000, GFP_KERNEL);
break;
case TEST_J_PID:
- ret = usb_control_msg(hub_udev, usb_sndctrlpipe(hub_udev, 0),
- USB_REQ_SET_FEATURE, USB_RT_PORT,
- USB_PORT_FEAT_TEST,
- (USB_TEST_J << 8) | portnum,
- NULL, 0, 1000);
+ ret = usb_control_msg_send(hub_udev, 0, USB_REQ_SET_FEATURE,
+ USB_RT_PORT, USB_PORT_FEAT_TEST,
+ (USB_TEST_J << 8) | portnum, NULL, 0,
+ 1000, GFP_KERNEL);
break;
case TEST_K_PID:
- ret = usb_control_msg(hub_udev, usb_sndctrlpipe(hub_udev, 0),
- USB_REQ_SET_FEATURE, USB_RT_PORT,
- USB_PORT_FEAT_TEST,
- (USB_TEST_K << 8) | portnum,
- NULL, 0, 1000);
+ ret = usb_control_msg_send(hub_udev, 0, USB_REQ_SET_FEATURE,
+ USB_RT_PORT, USB_PORT_FEAT_TEST,
+ (USB_TEST_K << 8) | portnum, NULL, 0,
+ 1000, GFP_KERNEL);
break;
case TEST_PACKET_PID:
- ret = usb_control_msg(hub_udev, usb_sndctrlpipe(hub_udev, 0),
- USB_REQ_SET_FEATURE, USB_RT_PORT,
- USB_PORT_FEAT_TEST,
- (USB_TEST_PACKET << 8) | portnum,
- NULL, 0, 1000);
+ ret = usb_control_msg_send(hub_udev, 0, USB_REQ_SET_FEATURE,
+ USB_RT_PORT, USB_PORT_FEAT_TEST,
+ (USB_TEST_PACKET << 8) | portnum,
+ NULL, 0, 1000, GFP_KERNEL);
break;
case TEST_HS_HOST_PORT_SUSPEND_RESUME:
/* Test: wait for 15secs -> suspend -> 15secs delay -> resume */
msleep(15 * 1000);
- ret = usb_control_msg(hub_udev, usb_sndctrlpipe(hub_udev, 0),
- USB_REQ_SET_FEATURE, USB_RT_PORT,
- USB_PORT_FEAT_SUSPEND, portnum,
- NULL, 0, 1000);
+ ret = usb_control_msg_send(hub_udev, 0, USB_REQ_SET_FEATURE,
+ USB_RT_PORT, USB_PORT_FEAT_SUSPEND,
+ portnum, NULL, 0, 1000, GFP_KERNEL);
if (ret < 0)
break;
msleep(15 * 1000);
- ret = usb_control_msg(hub_udev, usb_sndctrlpipe(hub_udev, 0),
- USB_REQ_CLEAR_FEATURE, USB_RT_PORT,
- USB_PORT_FEAT_SUSPEND, portnum,
- NULL, 0, 1000);
+ ret = usb_control_msg_send(hub_udev, 0, US
[PATCH v2 03/15] usb: misc: cytherm: update to use usb_control_msg_recv()
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, the instance of usb_control_msg() has been replaced with
usb_control_msg_recv().
The return value checking enforced by callers of the updated function have
also been appropriately updated.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/cytherm.c | 128 +
1 file changed, 43 insertions(+), 85 deletions(-)
diff --git a/drivers/usb/misc/cytherm.c b/drivers/usb/misc/cytherm.c
index 3e3802aaefa3..2ca36ea5b76a 100644
--- a/drivers/usb/misc/cytherm.c
+++ b/drivers/usb/misc/cytherm.c
@@ -51,12 +51,12 @@ static int vendor_command(struct usb_device *dev, unsigned
char request,
unsigned char value, unsigned char index,
void *buf, int size)
{
- return usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
- request,
- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
- value,
- index, buf, size,
- USB_CTRL_GET_TIMEOUT);
+ return usb_control_msg_recv(dev, 0,
+ request,
+ USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_OTHER,
+ value,
+ index, buf, size,
+ USB_CTRL_GET_TIMEOUT, GFP_KERNEL);
}
@@ -78,33 +78,27 @@ static ssize_t brightness_store(struct device *dev, struct
device_attribute *att
struct usb_interface *intf = to_usb_interface(dev);
struct usb_cytherm *cytherm = usb_get_intfdata(intf);
- unsigned char *buffer;
+ unsigned char buffer[8];
int retval;
-
- buffer = kmalloc(8, GFP_KERNEL);
- if (!buffer)
- return 0;
cytherm->brightness = simple_strtoul(buf, NULL, 10);
-
+
if (cytherm->brightness > 0xFF)
cytherm->brightness = 0xFF;
else if (cytherm->brightness < 0)
cytherm->brightness = 0;
-
+
/* Set brightness */
retval = vendor_command(cytherm->udev, WRITE_RAM, BRIGHTNESS,
- cytherm->brightness, buffer, 8);
- if (retval)
- dev_dbg(&cytherm->udev->dev, "retval = %d\n", retval);
+ cytherm->brightness, &buffer, 8);
+ if (!retval)
+ dev_dbg(&cytherm->udev->dev, "brightness set correctly\n");
/* Inform µC that we have changed the brightness setting */
retval = vendor_command(cytherm->udev, WRITE_RAM, BRIGHTNESS_SEM,
- 0x01, buffer, 8);
- if (retval)
- dev_dbg(&cytherm->udev->dev, "retval = %d\n", retval);
-
- kfree(buffer);
-
+ 0x01, &buffer, 8);
+ if (!retval)
+ dev_dbg(&cytherm->udev->dev, "µC informed of change in
brightness setting\n");
+
return count;
}
static DEVICE_ATTR_RW(brightness);
@@ -120,28 +114,22 @@ static ssize_t temp_show(struct device *dev, struct
device_attribute *attr, char
struct usb_cytherm *cytherm = usb_get_intfdata(intf);
int retval;
- unsigned char *buffer;
+ unsigned char buffer[8];
int temp, sign;
- buffer = kmalloc(8, GFP_KERNEL);
- if (!buffer)
- return 0;
-
/* read temperature */
- retval = vendor_command(cytherm->udev, READ_RAM, TEMP, 0, buffer, 8);
- if (retval)
- dev_dbg(&cytherm->udev->dev, "retval = %d\n", retval);
+ retval = vendor_command(cytherm->udev, READ_RAM, TEMP, 0, &buffer, 8);
+ if (!retval)
+ dev_dbg(&cytherm->udev->dev, "read temperature successfully\n");
temp = buffer[1];
/* read sign */
- retval = vendor_command(cytherm->udev, READ_RAM, SIGN, 0, buffer, 8);
- if (retval)
- dev_dbg(&cytherm->udev->dev, "retval = %d\n", retval);
+ retval = vendor_command(cytherm->udev, READ_RAM, SIGN, 0, &buffer, 8);
+ if (!retval)
+ dev_dbg(&cytherm->udev->dev, "read sign successfully\n");
sign = buffer[1];
- kfree(buffer);
-
return sprintf(buf, "%c%i.%i", sign ? '-' : '+', temp >> 1,
5*(temp - ((temp >> 1) << 1)));
}
@@ -157,21 +145,15 @@ static ssize_t button_show(struct device *dev, struct
device_attribute *attr, ch
struct usb_cytherm *cytherm = usb_get_intfdata(intf);
int retval;
- unsigned char *buffer;
-
- buffer = kmalloc(8, GFP_KERNEL);
- if (!buffer)
- return 0;
+ unsigned char buffer[8];
/* check button
[PATCH v2 02/15] usb: misc: cypress_cy7c63: update to use usb_control_msg_recv()
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, the instance of usb_control_msg() has been replaced with
usb_control_msg_recv().
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/cypress_cy7c63.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/misc/cypress_cy7c63.c
b/drivers/usb/misc/cypress_cy7c63.c
index 14faec51d7a5..76a320ef17a7 100644
--- a/drivers/usb/misc/cypress_cy7c63.c
+++ b/drivers/usb/misc/cypress_cy7c63.c
@@ -70,24 +70,15 @@ static int vendor_command(struct cypress *dev, unsigned
char request,
unsigned char address, unsigned char data)
{
int retval = 0;
- unsigned int pipe;
- unsigned char *iobuf;
-
- /* allocate some memory for the i/o buffer*/
- iobuf = kzalloc(CYPRESS_MAX_REQSIZE, GFP_KERNEL);
- if (!iobuf) {
- retval = -ENOMEM;
- goto error;
- }
+ u8 iobuf[CYPRESS_MAX_REQSIZE] = {0};
dev_dbg(&dev->udev->dev, "Sending usb_control_msg (data: %d)\n", data);
/* prepare usb control message and send it upstream */
- pipe = usb_rcvctrlpipe(dev->udev, 0);
- retval = usb_control_msg(dev->udev, pipe, request,
-USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,
-address, data, iobuf, CYPRESS_MAX_REQSIZE,
-USB_CTRL_GET_TIMEOUT);
+ retval = usb_control_msg_recv(dev->udev, 0, request,
+ USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_OTHER,
+ address, data, &iobuf,
CYPRESS_MAX_REQSIZE,
+ USB_CTRL_GET_TIMEOUT, GFP_KERNEL);
/* store returned data (more READs to be added) */
switch (request) {
@@ -107,8 +98,6 @@ static int vendor_command(struct cypress *dev, unsigned char
request,
break;
}
- kfree(iobuf);
-error:
return retval;
}
--
2.25.1
[PATCH v2 01/15] usb: misc: appledisplay: update to use the usb_control_msg_{send|recv}() API
The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg() as it ensures that a short read/write is treated
as an error, data can be used off the stack, and raw usb pipes need not be
created in the calling functions.
For this reason, instances of usb_control_msg() have been replaced with
usb_control_msg_{recv|send}(), and all return value checking
conditions have also been modified appropriately.
Signed-off-by: Anant Thazhemadam
---
drivers/usb/misc/appledisplay.c | 46 ++---
1 file changed, 19 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/misc/appledisplay.c b/drivers/usb/misc/appledisplay.c
index c8098e9b432e..117deb2fdc29 100644
--- a/drivers/usb/misc/appledisplay.c
+++ b/drivers/usb/misc/appledisplay.c
@@ -132,21 +132,17 @@ static int appledisplay_bl_update_status(struct
backlight_device *bd)
pdata->msgdata[0] = 0x10;
pdata->msgdata[1] = bd->props.brightness;
- retval = usb_control_msg(
- pdata->udev,
- usb_sndctrlpipe(pdata->udev, 0),
- USB_REQ_SET_REPORT,
- USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
- ACD_USB_BRIGHTNESS,
- 0,
- pdata->msgdata, 2,
- ACD_USB_TIMEOUT);
+ retval = usb_control_msg_send(pdata->udev,
+ 0,
+ USB_REQ_SET_REPORT,
+ USB_DIR_OUT | USB_TYPE_CLASS |
USB_RECIP_INTERFACE,
+ ACD_USB_BRIGHTNESS,
+ 0,
+ pdata->msgdata, 2,
+ ACD_USB_TIMEOUT, GFP_KERNEL);
mutex_unlock(&pdata->sysfslock);
- if (retval < 0)
- return retval;
- else
- return 0;
+ return retval;
}
static int appledisplay_bl_get_brightness(struct backlight_device *bd)
@@ -155,21 +151,17 @@ static int appledisplay_bl_get_brightness(struct
backlight_device *bd)
int retval, brightness;
mutex_lock(&pdata->sysfslock);
- retval = usb_control_msg(
- pdata->udev,
- usb_rcvctrlpipe(pdata->udev, 0),
- USB_REQ_GET_REPORT,
- USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
- ACD_USB_BRIGHTNESS,
- 0,
- pdata->msgdata, 2,
- ACD_USB_TIMEOUT);
- if (retval < 2) {
- if (retval >= 0)
- retval = -EMSGSIZE;
- } else {
+ retval = usb_control_msg_recv(pdata->udev,
+ 0,
+ USB_REQ_GET_REPORT,
+ USB_DIR_IN | USB_TYPE_CLASS |
USB_RECIP_INTERFACE,
+ ACD_USB_BRIGHTNESS,
+ 0,
+ pdata->msgdata, 2,
+ ACD_USB_TIMEOUT, GFP_KERNEL);
+ if (retval == 0)
brightness = pdata->msgdata[1];
- }
+
mutex_unlock(&pdata->sysfslock);
if (retval < 0)
--
2.25.1
[PATCH v2 00/15] drivers: usb: misc: update to use usb_control_msg_{send|recv}()
The new usb_control_msg_{send|recv}() API provides an improved way of
using usb_control_msg(). Using this, short reads/writes are considered
as errors, data can be used off the stack, and the need for the calling
function to create a raw usb pipe is eliminated.
This patch series aims to update existing instances of usb_control_msg()
in drivers/usb/misc to usb_control_msg_{send|recv}() appropriately, and
also update the return value checking mechanisms in place (if any), as
necessary so nothing breaks.
I was however unable to update one instance of usb_control_msg() in
drivers/usb/misc/apple-mfi-fastcharge.c.
The return value checking mechanism present here, is as follows.
if (retval) {
dev_dbg(&mfi->udev->dev, "retval = %d\n", retval);
return retval;
}
mfi->charge_type = val->intval;
return 0;
This implies that mfi->charge_type = val->intval only when number of
bytes transferred = 0, and the return value is directly returned
otherwise. Since the new API doesn't return the number of bytes
transferred, I wasn't quite sure how this instance could be updated.
In case this check is logically incorrect, a patch with a fix
can be sent in as well.
Changes in v2:
* Buffer variables that were previously dynamically allocated are no
longer dynamically allocated unless they have a variable length
(since that threw a warning).
Anant Thazhemadam (15):
usb: misc: appledisplay: update to use the
usb_control_msg_{send|recv}() API
usb: misc: cypress_cy7c63: update to use usb_control_msg_recv()
usb: misc: cytherm: update to use usb_control_msg_recv()
usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API
usb: misc: emi26: update to use usb_control_msg_send()
usb: misc: emi62: update to use usb_control_msg_send()
usb: misc: ezusb: update to use usb_control_msg_send()
usb: misc: idmouse: update to use usb_control_msg_send()
usb: misc: iowarrior: update to use the usb_control_msg_{send|recv}()
API
usb: misc: isight_firmware: update to use usb_control_msg_send()
usb: misc: ldusb: update to use usb_control_msg_send()
usb: misc: lvstest: update to use the usb_control_msg_{send|recv}()
API
usb: misc: trancevibrator: update to use usb_control_msg_send()
usb: misc: usbsevseg: update to use usb_control_msg_send()
usb: misc: usbtest: update to use the usb_control_msg_{send|recv}()
API
drivers/usb/misc/appledisplay.c| 46 +--
drivers/usb/misc/cypress_cy7c63.c | 21 ++---
drivers/usb/misc/cytherm.c | 128 ++---
drivers/usb/misc/ehset.c | 76 -
drivers/usb/misc/emi26.c | 31 ++-
drivers/usb/misc/emi62.c | 30 ++-
drivers/usb/misc/ezusb.c | 16 +---
drivers/usb/misc/idmouse.c | 5 +-
drivers/usb/misc/iowarrior.c | 34
drivers/usb/misc/isight_firmware.c | 30 +++
drivers/usb/misc/ldusb.c | 8 +-
drivers/usb/misc/lvstest.c | 38 -
drivers/usb/misc/trancevibrator.c | 4 +-
drivers/usb/misc/usbsevseg.c | 60 --
drivers/usb/misc/usbtest.c | 69 +++-
15 files changed, 216 insertions(+), 380 deletions(-)
--
2.25.1
Re: [f2fs-dev] [PATCH] f2fs: Fix deadlock between f2fs_quota_sync and block_operation
On 2020/11/29 1:41, Shachar Raindel wrote:
This deadlock is hitting Android users (Pixel 3/3a/4) with Magisk, due
to frequent umount/mount operations that trigger quota_sync, hitting
the race. See https://github.com/topjohnwu/Magisk/issues/3171 for
additional impact discussion.
In commit db6ec53b7e03, we added a semaphore to protect quota flags.
As part of this commit, we changed f2fs_quota_sync to call
f2fs_lock_op, in an attempt to prevent an AB/BA type deadlock with
quota_sem locking in block_operation. However, rwsem in Linux is not
recursive. Therefore, the following deadlock can occur:
f2fs_quota_sync
down_read(cp_rwsem) // f2fs_lock_op
filemap_fdatawrite
f2fs_write_data_pages
...
block_opertaion
down_write(cp_rwsem) - marks rwsem as
"writer pending"
down_read_trylock(cp_rwsem) - fails as there is
a writer pending.
Code keeps on trying,
live-locking the filesystem.
f2fs_write_single_data_page() will not grab read lock of cp_rwsem now, could you
please check f2fs code in mainline?
/* Dentry/quota blocks are controlled by checkpoint */
if (S_ISDIR(inode->i_mode) || IS_NOQUOTA(inode)) {
/*
* We need to wait for node_write to avoid block allocation
during
* checkpoint. This can only happen to quota writes which can
cause
* the below discard race condition.
*/
if (IS_NOQUOTA(inode))
down_read(&sbi->node_write);
fio.need_lock = LOCK_DONE;
err = f2fs_do_write_data_page(&fio);
if (IS_NOQUOTA(inode))
up_read(&sbi->node_write);
goto done;
}
Thanks,
We solve this by creating a new rwsem, used specifically to
synchronize this case, instead of attempting to reuse an existing
lock.
Signed-off-by: Shachar Raindel
Fixes: db6ec53b7e03 f2fs: add a rw_sem to cover quota flag changes
---
fs/f2fs/f2fs.h | 3 +++
fs/f2fs/super.c | 13 +++--
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index cb700d797296..b3e55137be7f 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1448,6 +1448,7 @@ struct f2fs_sb_info {
struct inode *meta_inode; /* cache meta blocks */
struct mutex cp_mutex; /* checkpoint procedure lock */
struct rw_semaphore cp_rwsem; /* blocking FS operations */
+ struct rw_semaphore cp_quota_rwsem; /* blocking quota sync
operations */
struct rw_semaphore node_write; /* locking node writes */
struct rw_semaphore node_change;/* locking node change */
wait_queue_head_t cp_wait;
@@ -1961,12 +1962,14 @@ static inline void f2fs_unlock_op(struct f2fs_sb_info
*sbi)
static inline void f2fs_lock_all(struct f2fs_sb_info *sbi)
{
+ down_write(&sbi->cp_quota_rwsem);
down_write(&sbi->cp_rwsem);
}
static inline void f2fs_unlock_all(struct f2fs_sb_info *sbi)
{
up_write(&sbi->cp_rwsem);
+ up_write(&sbi->cp_quota_rwsem);
}
static inline int __get_cp_reason(struct f2fs_sb_info *sbi)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 00eff2f51807..5ce61147d7e5 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -2209,8 +2209,16 @@ int f2fs_quota_sync(struct super_block *sb, int type)
* f2fs_dquot_commit
*block_operation
*down_read(quota_sem)
+*
+* However, we cannot use the cp_rwsem to prevent this
+* deadlock, as the cp_rwsem is taken for read inside the
+* f2fs_dquot_commit code, and rwsem is not recursive.
+*
+* We therefore use a special lock to synchronize
+* f2fs_quota_sync with block_operations, as this is the only
+* place where such recursion occurs.
*/
- f2fs_lock_op(sbi);
+ down_read(&sbi->cp_quota_rwsem);
down_read(&sbi->quota_sem);
ret = dquot_writeback_dquots(sb, type);
@@ -2251,7 +2259,7 @@ int f2fs_quota_sync(struct super_block *sb, int type)
if (ret)
set_sbi_flag(F2FS_SB(sb), SBI_QUOTA_NEED_REPAIR);
up_read(&sbi->quota_sem);
- f2fs_unlock_op(sbi);
+ up_read(&sbi->cp_quota_rwsem);
return ret;
}
@@ -3599,6 +3607,7 @@ static int f2fs_fill_super(struct super_block *sb, void *data, int silent)
init_rwsem(&sbi->cp_rwsem);
init_rwsem(&sbi->quota_sem);
+ init_rwsem(&sbi->cp_quota_rwsem);
init_waitqueue_head(&sbi->cp_wait);
init_sb_info(sbi);
[PATCH] leds: lm3533: Switch to using the new API kobj_to_dev()
fixed the following coccicheck:
drivers/leds/leds-lm3533.c:611:60-61: WARNING opportunity for kobj_to_dev().
Signed-off-by: Tian Tao
---
drivers/leds/leds-lm3533.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/leds-lm3533.c b/drivers/leds/leds-lm3533.c
index b3edee7..9791166 100644
--- a/drivers/leds/leds-lm3533.c
+++ b/drivers/leds/leds-lm3533.c
@@ -608,7 +608,7 @@ static struct attribute *lm3533_led_attributes[] = {
static umode_t lm3533_led_attr_is_visible(struct kobject *kobj,
struct attribute *attr, int n)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct lm3533_led *led = to_lm3533_led(led_cdev);
umode_t mode = attr->mode;
--
2.7.4
Re: linux-next: build warning after merge of the hwmon-staging tree
On Mon, 30 Nov 2020 at 00:56, Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the hwmon-staging tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> drivers/hwmon/pwm-fan.c: In function 'pwm_fan_is_visible':
> drivers/hwmon/pwm-fan.c:167:22: warning: unused variable 'ctx'
> [-Wunused-variable]
> 167 | struct pwm_fan_ctx *ctx = (struct pwm_fan_ctx *)data;
> | ^~~
>
> Introduced by commit
>
> 439ed83acc19 ("hwmon: (pwm-fan) Convert to hwmon_device_register_with_info
> API")
>
Ah yes. I removed the code that used ctx but forgot to remove the
assignment itself. I'm surprised it didn't generate a warning for me.
I can fix it up tomorrow and send a v3 patch series.
Thanks,
--
Paul Barker
Konsulko Group
Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK
On Sun, Nov 29, 2020 at 04:33:35AM +0900, Masahiro Yamada wrote:
> Revert commit cebc04ba9aeb ("add CONFIG_ENABLE_MUST_CHECK").
>
> A lot of warn_unused_result warnings existed in 2006, but until now
> they have been fixed thanks to people doing allmodconfig tests.
>
> Our goal is to always enable __must_check where appropriate, so this
> CONFIG option is no longer needed.
>
> I see a lot of defconfig (arch/*/configs/*_defconfig) files having:
>
> # CONFIG_ENABLE_MUST_CHECK is not set
>
> I did not touch them for now since it would be a big churn. If arch
> maintainers want to clean them up, please go ahead.
>
> While I was here, I also moved __must_check to compiler_attributes.h
> from compiler_types.h
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Jason A. Donenfeld
Acked-by: Nathan Chancellor
Re: [PATCH] powerpc: fix the allyesconfig build
On 2020/11/29 3:36, Jakub Kicinski wrote:
> On Sat, 28 Nov 2020 16:20:54 +1100 Stephen Rothwell wrote:
>> On Fri, 27 Nov 2020 17:56:42 -0800 Jakub Kicinski wrote:
>>>
>>> What's the offending structure in hisilicon? I'd rather have a look
>>> packing structs with pointers in 'em sounds questionable.
>>>
>>> I only see these two:
>>>
>>> $ git grep packed drivers/net/ethernet/hisilicon/
>>> drivers/net/ethernet/hisilicon/hns/hnae.h:struct __packed hnae_desc {
>>> drivers/net/ethernet/hisilicon/hns3/hns3_enet.h:struct __packed hns3_desc {
>>>
>>
>> struct hclge_dbg_reg_type_info which is 28 bytes long due to the
>> included struct struct hclge_dbg_reg_common_msg (which is 12 bytes
>> long). They are surrounded by #pragma pack(1)/pack().
>>
>> This forces the 2 pointers in each second array element of
>> hclge_dbg_reg_info[] to be 4 byte aligned (where pointers are 8 bytes
>> long on PPC64).
>
> Ah! Thanks, I don't see a reason for these to be packed.
> Looks like an accident, there is no reason to pack anything
> past struct hclge_dbg_reg_common_msg AFAICT.
>
> Huawei folks, would you mind sending a fix if the analysis is correct?
Yes, will send a patch to fix that. Thanks for the analysis.
> .
>
linux-next: build warning after merge of the hwmon-staging tree
Hi all,
After merging the hwmon-staging tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/hwmon/pwm-fan.c: In function 'pwm_fan_is_visible':
drivers/hwmon/pwm-fan.c:167:22: warning: unused variable 'ctx'
[-Wunused-variable]
167 | struct pwm_fan_ctx *ctx = (struct pwm_fan_ctx *)data;
| ^~~
Introduced by commit
439ed83acc19 ("hwmon: (pwm-fan) Convert to hwmon_device_register_with_info
API")
--
Cheers,
Stephen Rothwell
pgp25ktficzeY.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 18/18] MAINTAINERS: Add linux-actions ML for Actions Semi Arch
On 29.11.20 20:48, Cristian Ciocaltea wrote: > On Sat, Nov 28, 2020 at 01:13:50PM +0530, Manivannan Sadhasivam wrote: >> On Fri, Nov 20, 2020 at 01:56:12AM +0200, Cristian Ciocaltea wrote: >>> Add the linux-actions mailing list for the Actions Semi architecture. >>> >>> Signed-off-by: Cristian Ciocaltea >> >> There was a patch from me for this change but I don't mind taking yours >> as long as we keep the list updated :) > > Sorry about that, I often forget to manually append this mailing list > before submitting related patches and therefore I considered this is > a good opportunity to have this issue fixed once and for all.. :) > >> I have just one comment below, with that fixed: >> >> Reviewed-by: Manivannan Sadhasivam >> >>> --- >>> MAINTAINERS | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index a85c1881cf07..8428aba52581 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -1497,6 +1497,7 @@ ARM/ACTIONS SEMI ARCHITECTURE >>> M: Andreas Färber >>> M: Manivannan Sadhasivam >>> L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) >> >> No need to keep the generic list, please remove. Why? They're not mutually exclusive. Regards, Andreas > > Done, thanks! > >> Thanks, >> Mani >> >>> +L: linux-acti...@lists.infradead.org (moderated for non-subscribers) >>> S: Maintained >>> F: Documentation/devicetree/bindings/arm/actions.yaml >>> F: Documentation/devicetree/bindings/clock/actions,owl-cmu.txt >>> -- >>> 2.29.2 >>> -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
RE: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, .remove and .shutdown
> -Original Message- > From: Lee Jones [mailto:lee.jo...@linaro.org] > Sent: Friday, November 27, 2020 4:57 PM > To: Pkshih > Cc: Tony Chuang; kv...@codeaurora.org; linux-kernel@vger.kernel.org; > linux-wirel...@vger.kernel.org; > da...@davemloft.net; net...@vger.kernel.org; k...@kernel.org > Subject: Re: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, > .remove and .shutdown > > On Fri, 27 Nov 2020, Pkshih wrote: > > > On Fri, 2020-11-27 at 07:38 +, Lee Jones wrote: > > > On Fri, 27 Nov 2020, Pkshih wrote: > > > > > > > > > > > The subject prefix doesn't need 'realtek:'; use 'rtw88:'. > > > > > > > > On Thu, 2020-11-26 at 13:31 +, Lee Jones wrote: > > > > > Also strip out other duplicates from driver specific headers. > > > > > > > > > > Ensure 'main.h' is explicitly included in 'pci.h' since the latter > > > > > uses some defines from the former. It avoids issues like: > > > > > > > > > > from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5: > > > > > drivers/net/wireless/realtek/rtw88/pci.h:209:28: error: > > > > > ‘RTK_MAX_TX_QUEUE_NUM’ undeclared here (not in a function); did you > > > > > mean > > > > > ‘RTK_MAX_RX_DESC_NUM’? > > > > > 209 | DECLARE_BITMAP(tx_queued, RTK_MAX_TX_QUEUE_NUM); > > > > > | ^~~~ > > > > > > > > > > Fixes the following W=1 kernel build warning(s): > > > > > > > > > > drivers/net/wireless/realtek/rtw88/pci.c:1488:5: warning: no previous > > > > > prototype for ‘rtw_pci_probe’ [-Wmissing-prototypes] > > > > > 1488 | int rtw_pci_probe(struct pci_dev *pdev, > > > > > | ^ > > > > > drivers/net/wireless/realtek/rtw88/pci.c:1568:6: warning: no previous > > > > > prototype for ‘rtw_pci_remove’ [-Wmissing-prototypes] > > > > > 1568 | void rtw_pci_remove(struct pci_dev *pdev) > > > > > | ^~ > > > > > drivers/net/wireless/realtek/rtw88/pci.c:1590:6: warning: no previous > > > > > prototype for ‘rtw_pci_shutdown’ [-Wmissing-prototypes] > > > > > 1590 | void rtw_pci_shutdown(struct pci_dev *pdev) > > > > > | ^~~~ > > > > > > > > > > Cc: Yan-Hsuan Chuang > > > > > Cc: Kalle Valo > > > > > Cc: "David S. Miller" > > > > > Cc: Jakub Kicinski > > > > > Cc: linux-wirel...@vger.kernel.org > > > > > Cc: net...@vger.kernel.org > > > > > Signed-off-by: Lee Jones > > > > > --- > > > > > drivers/net/wireless/realtek/rtw88/pci.h | 8 > > > > > drivers/net/wireless/realtek/rtw88/rtw8723de.c | 1 + > > > > > drivers/net/wireless/realtek/rtw88/rtw8723de.h | 4 > > > > > drivers/net/wireless/realtek/rtw88/rtw8821ce.c | 1 + > > > > > drivers/net/wireless/realtek/rtw88/rtw8821ce.h | 4 > > > > > drivers/net/wireless/realtek/rtw88/rtw8822be.c | 1 + > > > > > drivers/net/wireless/realtek/rtw88/rtw8822be.h | 4 > > > > > drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 1 + > > > > > drivers/net/wireless/realtek/rtw88/rtw8822ce.h | 4 > > > > > 9 files changed, 12 insertions(+), 16 deletions(-) > > > > > > > > > > diff --git a/drivers/net/wireless/realtek/rtw88/pci.h > > > > > b/drivers/net/wireless/realtek/rtw88/pci.h > > > > > index ca17aa9cf7dc7..cda56919a5f0f 100644 > > > > > --- a/drivers/net/wireless/realtek/rtw88/pci.h > > > > > +++ b/drivers/net/wireless/realtek/rtw88/pci.h > > > > > @@ -5,6 +5,8 @@ > > > > > #ifndef __RTK_PCI_H_ > > > > > #define __RTK_PCI_H_ > > > > > > > > > > +#include "main.h" > > > > > + > > > > > > > > Please #include "main.h" ahead of "pci.h" in each of rtw8e.c. > > > > > > You mean instead of in pci.h? > > > > > > Surely that's a hack. > > > > > > > I mean don't include main.h in pci.h, but include both of them in each > > of rtw8e.c. > > > > +#include "main.h" > > +#include "pci.h" > > Yes, that's what I thought you meant. I think that's a hack. > > Source files shouldn't rely on the ordering of include files to > resolve dependencies. In fact, a lot of subsystems require includes to > be in alphabetical order. > > If a source or header file references a resource from a specific > header file (for instance here pci.h uses defines from main.h) then it > should explicitly include it. > > Can you tell me the technical reason as to why these drivers are > handled differently please? > No technical reason, but that's our coding convention that needs some changes now. Could you point out where kernel or subsystem describes the rules? Or, point out the subsystem you mentioned above. Then, I can study and follow the rules for further development. Thank you --- Ping-Ke
Re: [GIT pull] locking/urgent for v5.10-rc6
On Sun, Nov 29, 2020 at 11:31:41AM -0800, Linus Torvalds wrote: > On Sun, Nov 29, 2020 at 5:38 AM Thomas Gleixner wrote: > > > > Yet two more places which invoke tracing from RCU disabled regions in the > > idle path. Similar to the entry path the low level idle functions have to > > be non-instrumentable. > > This really seems less than optimal. > > In particular, lookie here: > > > @@ -94,9 +94,35 @@ void __cpuidle default_idle_call(void) > > > > trace_cpu_idle(1, smp_processor_id()); > > stop_critical_timings(); > > + > > + /* > > +* arch_cpu_idle() is supposed to enable IRQs, however > > +* we can't do that because of RCU and tracing. > > +* > > +* Trace IRQs enable here, then switch off RCU, and have > > +* arch_cpu_idle() use raw_local_irq_enable(). Note that > > +* rcu_idle_enter() relies on lockdep IRQ state, so switch > > that > > +* last -- this is very similar to the entry code. > > +*/ > > + trace_hardirqs_on_prepare(); > > + lockdep_hardirqs_on_prepare(_THIS_IP_); > > rcu_idle_enter(); > > + lockdep_hardirqs_on(_THIS_IP_); > > + > > arch_cpu_idle(); > > + > > + /* > > +* OK, so IRQs are enabled here, but RCU needs them > > disabled to > > +* turn itself back on.. funny thing is that disabling IRQs > > +* will cause tracing, which needs RCU. Jump through hoops > > to > > +* make it 'work'. > > +*/ > > + raw_local_irq_disable(); > > + lockdep_hardirqs_off(_THIS_IP_); > > rcu_idle_exit(); > > + lockdep_hardirqs_on(_THIS_IP_); > > + raw_local_irq_enable(); > > + > > start_critical_timings(); > > trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id()); > > } > > And look at what the code generation for the idle exit path is when > lockdep isn't even on. > > It's *literally* > > cli > call rcu_idle_exit > sti > > and guess what rcu_idle_exit does? > > Yeah, that one does "pushf; cli; call rcu_eqs_exit; popf". > > So here we are, in the somewhat critical "an interrupt woke us up" > section, and we're doing just ridiculously stupid things. > > I've pulled this, because it solves a problem, but there's a deeper > problem here in how all this is done. > > The idle path is actually quite important. I can point to real loads > where this is a big part of the CPU profile, because you end up having > lots of "go to sleep for very short times, because the thing we were > waiting for takes almost no time at all". This is because of the noinline implied by the noinstr on rcu_eqs_exit(). If I replace that with inline, it does get inlined. Except that, if I remember correctly, making that change messes up the tooling that enforces the no-instrumentation regions. I -think- that a combination of instrumentation_end() and s/noinstr/inline/ might work, but I will need to consult with the experts on this. Thanx, Paul
Linux 5.10-rc6
For the first part of the week, it really looked like things were
calming down quite nicely, and I mentally already went "Ahh,
Thanksgiving week, this is going to be a nice small, calm rc".
And then Friday rolled around, and everybody sent me their pull
requests for the week, and it all looks very normal again.
But at least this week isn't unusually bigger than normal - it's a
pretty normal rc6 stat-wise. So unless we have some big surprising
left-overs coming up, I think we're in good shape.
And the diffstat looks nice and flat too, which is a sign of just
widespread small fixes, rather than some big last-minute changes. The
exception is a chunk of fixes to the new vidtv driver, but that is not
only a new driver, it's a virtual test-driver for validation and
development rather than something that would affect users.
That vidtv driver shows up very clearly in the patch stats too, but
other than that it all looks very normal: mostly driver updates (even
ignoring the vidtv ones), with the usual smattering of small fixes
elsewhere - architecture code, networking, some filesystem stuff.
So I'm feeling pretty good about 5.10, and I hope I won't be proven
wrong about that. But please do test,
Linus
---
Al Cooper (1):
phy: usb: Fix incorrect clearing of tca_drv_sel bit in SETUP reg for 7211
Alan Stern (2):
USB: core: Fix regression in Hercules audio card
USB: core: Change %pK for __user pointers to %px
Alexander Duyck (3):
tcp: Allow full IP tos/IPv6 tclass to be reflected in L3 header
tcp: Set INET_ECN_xmit configuration in tcp_reinit_congestion_control
tcp: Set ECT0 bit in tos/tclass for synack when BPF needs ECN
Alexandra Winter (1):
s390/qeth: Remove pnso workaround
Alexandre Courbot (2):
media: mtk-vcodec: move firmware implementations into their own files
media: mtk-vcodec: fix build breakage when one of VPU or SCP is enabled
Amadeusz Sławiński (1):
efi/efivars: Set generic ops before loading SSDT
Amelie Delaunay (1):
usb: typec: stusb160x: fix power-opmode property with typec-power-opmode
Amit Sunil Dhamne (1):
firmware: xilinx: Use hash-table for api feature check
Anand K Mistry (1):
x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpb
Anmol Karn (1):
rose: Fix Null pointer dereference in rose_send_frame()
Antonio Borneo (1):
net: stmmac: fix incorrect merge of patch upstream
Anup Patel (1):
RISC-V: Add missing jump label initialization
Ard Biesheuvel (1):
efivarfs: revert "fix memory leak in efivarfs_create()"
Arnaldo Carvalho de Melo (1):
perf tools: Update copy of libbpf's hashmap.c
Arnd Bergmann (1):
arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
Ashish Kalra (1):
KVM: SVM: Fix offset computation bug in __sev_dbg_decrypt().
Avraham Stern (1):
iwlwifi: mvm: write queue_sync_state only for sync
Benjamin Berg (1):
platform/x86: thinkpad_acpi: Send tablet mode switch at wakeup time
Bryan O'Donoghue (2):
phy: qualcomm: usb: Fix SuperSpeed PHY OF dependency
phy: qualcomm: Fix 28 nm Hi-Speed USB PHY OF dependency
CK Hu (1):
drm/mediatek: dsi: Modify horizontal front/back porch byte formula
Can Guo (2):
scsi: ufs: Fix unexpected values from ufshcd_read_desc_param()
scsi: ufs: Make sure clk scaling happens only when HBA is runtime ACTIVE
Chen Baozi (1):
irqchip/exiu: Fix the index of fwspec for IRQ type
Chen Zhou (1):
KVM: SVM: fix error return code in svm_create_vcpu()
Chi-Hsien Lin (1):
MAINTAINERS: update maintainers list for Cypress
Chris Wilson (4):
drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission
drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock
drm/i915/gt: Don't cancel the interrupt shadow too early
drm/i915/gt: Free stale request on destroying the virtual engine
Christian Borntraeger (2):
s390/uv: handle destroy page legacy interface
MAINTAINERS: add uv.c also to KVM/s390
Christophe Leroy (1):
powerpc/32s: Use relocation offset when setting early hash table
Clark Wang (1):
spi: imx: fix the unbalanced spi runtime pm management
Colin Ian King (1):
phy: mediatek: fix spelling mistake in Kconfig "veriosn" -> "version"
Collin Walling (1):
KVM: s390: remove diag318 reset code
Cédric Le Goater (1):
KVM: PPC: Book3S HV: XIVE: Fix possible oops when accessing ESB page
Daniel W. S. Almeida (6):
media: vidtv: extract the initial CRC value to into a #define
media: vidtv: psi: add a Network Information Table (NIT)
media: vidtv: psi: Implement an Event Information Table (EIT)
media: vidtv: psi: extract descriptor chaining code into a helper
media: vidtv: Move s302m specific fields into encoder context
media: vidtv: psi: fix missing assignments in while loops
Daniel Xu (1):
btrfs: tree-checker:
[net-next PATCH] net: freescale: ucc_geth: remove unused SKB_ALLOC_TIMEOUT
This was added in commit ce973b141dfa ("[PATCH] Freescale QE UCC gigabit
ethernet driver") but doesn't appear to have been used. Remove it now.
Signed-off-by: Chris Packham
---
drivers/net/ethernet/freescale/ucc_geth.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h
b/drivers/net/ethernet/freescale/ucc_geth.h
index 3fe903972195..1a9bdf66a7d8 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -882,7 +882,6 @@ struct ucc_geth_hardware_statistics {
addresses */
#define TX_TIMEOUT (1*HZ)
-#define SKB_ALLOC_TIMEOUT 10
#define PHY_INIT_TIMEOUT10
#define PHY_CHANGE_TIME 2
--
2.29.2
Re: linux-kernel: Unused static inline functions
On Fri, 2020-03-06 at 16:07 -0800, Joe Perches wrote:
> On Fri, 2020-03-06 at 11:02 -0800, Nick Desaulniers wrote:
> > Turns out there are hundreds of unused static inline
> > > functions in kernel .h files.
> > >
> > > A trivial script to find some of them (with likely
> > > false positives as some might actually be used via ##
> > > token pasting mechanisms).
Hey Nick. It's been several months. Did you want to do
anything with this list? Maybe your newbie minions?
> > > (and there's almost certainly a better way to do this
> > > too as it takes a _very_ long time to run)
> > >
> > > $ grep-2.5.4 -rP --include=*.h '^[
> > > \t]*static\s+inline\s+(?:\w+\s+){1,3}\w+[ \t]*\(' * | \
> > > grep -P -oh '\w+\s*\(' | \
> > > sort | uniq -c | sort -n | grep -P '^\s+1\b' | \
> > > sed -r -e 's/^\s+1\s+//' -e 's/\(//' | \
> > > while read line ; do \
> > > echo -n "$line: " ; git grep -w $line | wc -l ; \
> > > done | \
> > > grep ": 1$"
> >
> > Please start sending patches to remove them and I'll review. If this
> > is a good amount of work, I have newbies that are looking to
> > contribute and can help.
>
> Hello Nick.
>
> Here is the current result of a slightly different run
> excluding ALL_UPPERCASE variants. Those upper case entries
> may have been autogenerated and are likely inappropriate to
> be removed.
>
> There are 1395 functions. Some are uapi and those should
> likely not be removed.
>
> All of these below may be unused, defined but unused, but
> it's possible some may be used by token-pasting.
>
> arch/alpha/include/asm/io.h:183:static inline void generic_iounmap(volatile
> void __iomem *a)
> arch/alpha/include/asm/io.h:188:static inline int generic_is_ioaddr(unsigned
> long a)
> arch/alpha/include/asm/io.h:193:static inline int generic_is_mmio(const
> volatile void __iomem *a)
> arch/alpha/include/asm/pal.h:121:qemu_get_walltime(void)
> arch/alpha/include/asm/pal.h:135:qemu_get_alarm(void)
> arch/alpha/include/uapi/asm/fpu.h:109:ieee_fpcr_to_swcr(unsigned long fp)
> arch/arc/include/asm/unwind.h:117:arch_unwind_init_running(struct
> unwind_frame_info *info,
> arch/arc/include/asm/unwind.h:125:static inline int arch_unw_user_mode(const
> struct unwind_frame_info *info)
> arch/arc/include/asm/unwind.h:130:static inline void
> arch_unw_init_blocked(struct unwind_frame_info *info)
> arch/arc/include/asm/unwind.h:135:static inline void
> arch_unw_init_frame_info(struct unwind_frame_info *info,
> arch/arm64/include/asm/arch_timer.h:67:static inline notrace u32
> arch_timer_read_cntp_tval_el0(void)
> arch/arm64/include/asm/arch_timer.h:72:static inline notrace u32
> arch_timer_read_cntv_tval_el0(void)
> arch/arm64/include/asm/arch_timer.h:77:static inline notrace u64
> arch_timer_read_cntpct_el0(void)
> arch/arm64/include/asm/arch_timer.h:82:static inline notrace u64
> arch_timer_read_cntvct_el0(void)
> arch/arm64/include/asm/atomic_ll_sc.h:237:__ll_sc_atomic64_dec_if_positive(atomic64_t
> *v)
> arch/arm64/include/asm/atomic_lse.h:111:static inline void
> __lse_atomic_sub(int i, atomic_t *v)
> arch/arm64/include/asm/atomic_lse.h:233:static inline void
> __lse_atomic64_and(s64 i, atomic64_t *v)
> arch/arm64/include/asm/atomic_lse.h:264:static inline void
> __lse_atomic64_sub(s64 i, atomic64_t *v)
> arch/arm64/include/asm/atomic_lse.h:319:static inline s64
> __lse_atomic64_dec_if_positive(atomic64_t *v)
> arch/arm64/include/asm/atomic_lse.h:80:static inline void
> __lse_atomic_and(int i, atomic_t *v)
> arch/arm64/include/asm/kvm_emulate.h:140:static inline unsigned long
> vcpu_read_elr_el1(const struct kvm_vcpu *vcpu)
> arch/arm64/include/asm/kvm_emulate.h:197:static inline unsigned long
> vcpu_read_spsr(const struct kvm_vcpu *vcpu)
> arch/arm64/include/asm/module.h:65:static inline bool
> plt_entry_is_initialized(const struct plt_entry *e)
> arch/arm64/include/asm/pgtable.h:191:static inline pte_t pte_mknoncont(pte_t
> pte)
> arch/arm64/include/asm/pgtable.h:316:static inline pmd_t pud_pmd(pud_t pud)
> arch/arm64/include/asm/uaccess.h:176:static inline void
> __uaccess_disable_hw_pan(void)
> arch/arm/include/asm/bitops.h:107:atomic_test_and_change_bit(unsigned int
> bit, volatile unsigned long *p)
> arch/arm/include/asm/bitops.h:36:static inline void
> atomic_set_bit(unsigned int bit, volatile unsigned long *p)
> arch/arm/include/asm/bitops.h:48:static inline void
> atomic_clear_bit(unsigned int bit, volatile unsigned long *p)
> arch/arm/include/asm/bitops.h:60:static inline void
> atomic_change_bit(unsigned int bit, volatile unsigned long *p)
> arch/arm/include/asm/bitops.h:73:atomic_test_and_set_bit(unsigned int
> bit, volatile unsigned long *p)
> arch/arm/include/asm/bitops.h:90:atomic_test_and_clear_bit(unsigned int
> bit, volatile unsigned long *p)
> arch/arm/include/asm/cputype.h:246:static inline unsigned int
> __attribute_const__ xscale_cpu_arch_version(void)
> arch/arm/include/asm/floppy.h:75:static inline void fd
Re: [PATCH] PCI: aardvark: Update comment about disabling link training
On Sunday 11 October 2020 19:21:49 Pali Rohár wrote: > On Thursday 24 September 2020 17:22:32 Pali Rohár wrote: > > On Thursday 24 September 2020 10:11:06 Bjorn Helgaas wrote: > > > On Thu, Sep 24, 2020 at 10:46:18AM +0200, Pali Rohár wrote: > > > > It is not HW bug or workaround for some cards but it is requirement by > > > > PCI > > > > Express spec. After fundamental reset is needed 100ms delay prior > > > > enabling > > > > link training. So update comment in code to reflect this requirement. > > > > > > > > Signed-off-by: Pali Rohár > > > > --- > > > > drivers/pci/controller/pci-aardvark.c | 7 ++- > > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/pci/controller/pci-aardvark.c > > > > b/drivers/pci/controller/pci-aardvark.c > > > > index 50ab6d7519ae..19b9b79226e5 100644 > > > > --- a/drivers/pci/controller/pci-aardvark.c > > > > +++ b/drivers/pci/controller/pci-aardvark.c > > > > @@ -259,7 +259,12 @@ static void advk_pcie_issue_perst(struct advk_pcie > > > > *pcie) > > > > if (!pcie->reset_gpio) > > > > return; > > > > > > > > - /* PERST does not work for some cards when link training is > > > > enabled */ > > > > + /* > > > > +* As required by PCI Express spec a delay for at least 100ms > > > > after > > > > +* de-asserting PERST# signal is needed before link training is > > > > enabled. > > > > +* So ensure that link training is disabled prior de-asserting > > > > PERST# > > > > +* signal to fulfill that PCI Express spec requirement. > > > > > > Can you please include the spec citation here? In the PCIe base spec, > > > PERST# is only mentioned in PCIe r5.0, sec 6.6.1, and I don't see the > > > connection there to 100ms between de-assert of PERST# and enabling > > > link training. > > > > Hello! I copied this "comment" from other place in pci-aardvark.c where > > that timeout 100ms is already applied. Timeout with explanation comment > > was introduced in following commit: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4c7d053d7f7 > > > > Here are links to discussions about that patch: > > > > https://lore.kernel.org/linux-pci/20190313213752.1246-1-r...@triplefau.lt/T/#u > > https://lore.kernel.org/linux-pci/20190522213351.21366-2-r...@triplefau.lt/T/#u > > Bjorn or Lorenzo, do you need something else for this patch? It just > updates comment and basically clarify why PERST does not work for some > cards when link training is enabled. PING? > > > Sec 6.1.1 does talk about 100ms before sending config requests (for > > > ports that support <= 5 GT/s), and 100ms after link training completes > > > (for ports that support > 5 GT/s). > > > > > > Maybe there's more language in a form-factor spec or something? > > > > > > > +*/ > > > > reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG); > > > > reg &= ~LINK_TRAINING_EN; > > > > advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG); > > > > -- > > > > 2.20.1 > > > >
[tip:master] BUILD SUCCESS bd4d2b7839cffa929d076cfb62562f5edb8e1b14
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: bd4d2b7839cffa929d076cfb62562f5edb8e1b14 Merge branch 'linus' elapsed time: 723m configs tested: 93 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig powerpc mpc8540_ads_defconfig m68k m5275evb_defconfig arm lpc32xx_defconfig xtensa defconfig mipsvocore2_defconfig sh sh7724_generic_defconfig mips loongson1c_defconfig powerpc64alldefconfig mips lemote2f_defconfig xtensa cadence_csp_defconfig powerpc pcm030_defconfig powerpcgamecube_defconfig arm colibri_pxa270_defconfig arm hackkit_defconfig powerpc eiger_defconfig mips pistachio_defconfig powerpc kilauea_defconfig mips ip22_defconfig armtrizeps4_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20201129 i386 randconfig-a003-20201129 i386 randconfig-a002-20201129 i386 randconfig-a005-20201129 i386 randconfig-a001-20201129 i386 randconfig-a006-20201129 x86_64 randconfig-a015-20201129 x86_64 randconfig-a011-20201129 x86_64 randconfig-a016-20201129 x86_64 randconfig-a014-20201129 x86_64 randconfig-a012-20201129 x86_64 randconfig-a013-20201129 i386 randconfig-a012-20201129 i386 randconfig-a013-20201129 i386 randconfig-a011-20201129 i386 randconfig-a016-20201129 i386 randconfig-a014-20201129 i386 randconfig-a015-20201129 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a003-20201129 x86_64 randconfig-a006-20201129 x86_64 randconfig-a004-20201129 x86_64 randconfig-a005-20201129 x86_64 randconfig-a002-20201129 x86_64 randconfig-a001-20201129 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v2 1/3] dt-bindings: net: fsl-fec add mdc/mdio bitbang option
On Sun, Nov 29, 2020 at 11:51:43PM +0100, Adrien Grassein wrote: > Hi Andrew, > > Please find my answers below. > > Le dim. 29 nov. 2020 à 23:41, Andrew Lunn a écrit : > > On Sun, Nov 29, 2020 at 10:59:58PM +0100, Adrien Grassein wrote: > > Add dt-bindings explanation for the two new gpios > > (mdio and mdc) used for bitbanging. > > Hi Adrien > > What is missing is an explanation of why! > > I'm sorry, it's my first upstreaming attempt. Hi Adrien Please take a look at https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html It is normal to have a patch 0/X which explains the big picture. Then the commit message for each patch should explain why you are doing something. That is much more important than what you are doing, i can see that from the patch itself. > I am currently upstreaming the "Nitrogen 8m Mini board" that seems to not use > a > "normal" mdio bus but a "bitbanged" one with the fsl fec driver. Any idea why? Anyway, you should not replicate code, don't copy bitbanging code into the FEC. Just use the existing bit-banger MDIO bus master driver. Andrew
Re: [PATCH v2 3/3] media: uapi: mpeg2: Split sequence and picture parameters
Hi Ezequiel,
On 2020-11-05 21:51, Ezequiel Garcia wrote:
> Typically, bitstreams are composed of one sequence header NAL unit,
> followed by a number of picture header and picture coding extension
> NAL units. Each picture can be composed by a number of slices.
>
> Let's split the MPEG-2 uAPI to follow these semantics more closely,
> allowing more usage flexibility. Having these controls splitted
> allows applications to set a sequence control at the beginning
> of a sequence, and then set a picture control for each frame.
>
> While here add padding fields where needed, and document
> the uAPI header thoroughly.
>
> Signed-off-by: Ezequiel Garcia
> ---
> .../media/v4l/ext-ctrls-codec.rst | 47 ++--
> .../media/v4l/pixfmt-compressed.rst | 5 +-
> drivers/media/v4l2-core/v4l2-ctrls.c | 45 +--
> drivers/staging/media/hantro/hantro_drv.c | 10 ++
> .../media/hantro/hantro_g1_mpeg2_dec.c| 14 ++-
> .../media/hantro/rk3399_vpu_hw_mpeg2_dec.c| 14 ++-
> drivers/staging/media/sunxi/cedrus/cedrus.c | 14 +++
> drivers/staging/media/sunxi/cedrus/cedrus.h | 2 +
> .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 8 +-
> include/media/mpeg2-ctrls.h | 110 +++---
> include/media/v4l2-ctrls.h| 4 +
> 11 files changed, 212 insertions(+), 61 deletions(-)
>
> diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> index 4c32b93f41a6..d919cbc119bd 100644
> --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> @@ -2218,14 +2218,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
> :stub-columns: 0
> :widths: 1 1 2
>
> -* - struct :c:type:`v4l2_mpeg2_sequence`
> - - ``sequence``
> - - Structure with MPEG-2 sequence metadata, merging relevant fields from
> - the sequence header and sequence extension parts of the bitstream.
> -* - struct :c:type:`v4l2_mpeg2_picture`
> - - ``picture``
> - - Structure with MPEG-2 picture metadata, merging relevant fields from
> - the picture header and picture coding extension parts of the bitstream.
> * - __u64
>- ``backward_ref_ts``
>- Timestamp of the V4L2 capture buffer to use as backward reference,
> used
> @@ -2243,14 +2235,28 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
> * - __u32
>- ``quantiser_scale_code``
>- Code used to determine the quantization scale to use for the IDCT.
> +* - __u8
> + - ``reserved``
> + - Applications and drivers must set this to zero.
>
> -.. c:type:: v4l2_mpeg2_sequence
> +``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE (struct)``
> +Specifies the sequence parameters (as extracted from the bitstream) for
> the
> +associated MPEG-2 slice data. This includes fields matching the syntax
> +elements from the sequence header and sequence extension parts of the
> +bitstream as specified by :ref:`mpeg2part2`.
> +
> +.. note::
> +
> + This compound control is not yet part of the public kernel API and
> + it is expected to change.
> +
> +.. c:type:: v4l2_ctrl_mpeg2_sequence
>
> .. cssclass:: longtable
>
> .. tabularcolumns:: |p{1.5cm}|p{6.3cm}|p{9.4cm}|
>
> -.. flat-table:: struct v4l2_mpeg2_sequence
> +.. flat-table:: struct v4l2_ctrl_mpeg2_sequence
> :header-rows: 0
> :stub-columns: 0
> :widths: 1 1 2
> @@ -2272,6 +2278,9 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
> * - __u8
>- ``chroma_format``
>- The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4).
> +* - __u8
> + - ``reserved``
> + - Applications and drivers must set this to zero.
> * - __u32
>- ``flags``
>- See :ref:`MPEG-2 Sequence Flags `.
> @@ -2292,13 +2301,24 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>- Indication that all the frames for the sequence are progressive
> instead
> of interlaced.
>
> -.. c:type:: v4l2_mpeg2_picture
> +``V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE (struct)``
> +Specifies the picture parameters (as extracted from the bitstream) for
> the
> +associated MPEG-2 slice data. This includes fields matching the syntax
> +elements from the picture header and picture coding extension parts of
> the
> +bitstream as specified by :ref:`mpeg2part2`.
> +
> +.. note::
> +
> + This compound control is not yet part of the public kernel API and
> + it is expected to change.
> +
> +.. c:type:: v4l2_ctrl_mpeg2_picture
>
> .. cssclass:: longtable
>
> .. tabularcolumns:: |p{1.5cm}|p{6.3cm}|p{9.4cm}|
>
> -.. flat-table:: struct v4l2_mpeg2_picture
> +.. flat-table:: struct v4l2_ctrl_mpeg2_picture
> :header-rows: 0
> :stub-columns: 0
> :widths: 1 1 2
> @@ -2319,6 +2339,9 @@ enum v4
Re: [RFC PATCH v2 0/6] fsdax: introduce fs query to support reflink
On Mon, Nov 23, 2020 at 08:41:10AM +0800, Shiyang Ruan wrote:
> This patchset is a try to resolve the problem of tracking shared page
> for fsdax.
>
> Change from v1:
> - Intorduce ->block_lost() for block device
> - Support mapped device
> - Add 'not available' warning for realtime device in XFS
> - Rebased to v5.10-rc1
>
> This patchset moves owner tracking from dax_assocaite_entry() to pmem
> device, by introducing an interface ->memory_failure() of struct
> pagemap. The interface is called by memory_failure() in mm, and
> implemented by pmem device. Then pmem device calls its ->block_lost()
> to find the filesystem which the damaged page located in, and call
> ->storage_lost() to track files or metadata assocaited with this page.
> Finally we are able to try to fix the damaged data in filesystem and do
> other necessary processing, such as killing processes who are using the
> files affected.
>
> The call trace is like this:
> memory_failure()
>pgmap->ops->memory_failure() => pmem_pgmap_memory_failure()
> gendisk->fops->block_lost() => pmem_block_lost() or
> md_blk_block_lost()
> sb->s_ops->storage_lost()=> xfs_fs_storage_lost()
> xfs_rmap_query_range()
>xfs_storage_lost_helper()
> mf_recover_controller->recover_fn => \
> memory_failure_dev_pagemap_kill_procs()
>
> The collect_procs() and kill_procs() are moved into a callback which
> is passed from memory_failure() to xfs_storage_lost_helper(). So we
> can call it when a file assocaited is found, instead of creating a
> file list and iterate it.
>
> The fsdax & reflink support for XFS is not contained in this patchset.
This looks promising - the overall architecture is a lot more
generic and less dependent on knowing about memory, dax or memory
failures. A few comments that I think would further improve
understanding the patchset and the implementation:
- the order of the patches is inverted. It should start with a
single patch introducing the mf_recover_controller structure for
callbacks, then introduce pgmap->ops->memory_failure, then
->block_lost, then the pmem and md implementations of ->block
list, then ->storage_lost and the XFS implementations of
->storage_lost.
- I think the names "block_lost" and "storage_lost" are misleading.
It's more like a "media failure" or a general "data corruption"
event at a specific physical location. The data may not be "lost"
but only damaged, so we might be able to recover from it without
"losing" anything. Hence I think they could be better named,
perhaps just "->corrupt_range"
- need to pass a {offset,len} pair through the chain, not just a
single offset. This will allow other types of devices to report
different ranges of failures, from a single sector to an entire
device.
- I'm not sure that passing the mf_recover_controller structure
through the corruption event chain is the right thing to do here.
A block device could generate this storage failure callback if it
detects an unrecoverable error (e.g. during a MD media scrub or
rebuild/resilver failure) and in that case we don't have PFNs or
memory device failure functions to perform.
IOWs, I think the action that is taken needs to be independent of
the source that generated the error. Even for a pmem device, we
can be using the page cache, so it may be possible to recover the
pmem error by writing the cached page (if it exists) back over the
pmem.
Hence I think that the recover function probably needs to be moved
to the address space ops, because what we do to recover from the
error is going to be dependent on type of mapping the filesystem
is using. If it's a DAX mapping, we call back into a generic DAX
function that does the vma walk and process kill functions. If it
is a page cache mapping, then if the page is cached then we can
try to re-write it to disk to fix the bad data, otherwise we treat
it like a writeback error and report it on the next
write/fsync/close operation done on that file.
This gets rid of the mf_recover_controller altogether and allows
the interface to be used by any sort of block device for any sort
of bottom-up reporting of media/device failures.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
Re: [PATCH] locks: remove trailing semicolon in macro definition
On Sun, 2020-11-29 at 10:15 -0800, James Bottomley wrote: > I think nowadays we should always use static inlines for argument > checking unless we're capturing debug information like __FILE__ or > __LINE__ or something that a static inline can't. IMO: __LINE__ should never be used. __func__ is the only thing that can't be captured correctly as the inline gets its own name. __builtin_return_address(1) would generally work well enough for the inlines. > There was a time when we had problems with compiler expansion of static > inlines, so we shouldn't go back and churn the code base to change it > because there's thousands of these and possibly some old compiler used > for an obscure architecture that still needs the define. That's not a very compelling argument to me. Those old compilers and obscure architectures should continue to use the old versions of the code.
Re: [PATCH v7] checkpatch: add fix option for LOGICAL_CONTINUATIONS
On Sun, 2020-11-29 at 14:25 +0530, Aditya wrote:
> On 23/11/20 3:58 pm, Aditya Srivastava wrote:
> > Currently, checkpatch warns if logical continuations are placed at the
> > start of a line and not at the end of previous line.
Acked-by: Joe Perches
> >
> > E.g., running checkpatch on commit 3485507fc272 ("staging:
> > bcm2835-camera: Reduce length of enum names") reports:
> >
> > CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the
> > previous line
> > + if (!ret
> > + && camera_port ==
> >
> > Provide a simple fix by inserting logical operator at the last
> > non-comment, non-whitespace char of the previous line and removing from
> > current line, if both the lines are additions(ie start with '+')
> >
> > Signed-off-by: Aditya Srivastava
> > ---
> > changes in v2: quote $operator at substitution
> >
> > changes in v3: add a check for previous line ending with comment;
> > If so, insert $operator at the last non-comment, non-whitespace char of the
> > previous line
> >
> > changes in v4: improve the matching mechanism by matching line termination
> > at comment or white space;
> > insert the operator before comments (if any) separated by a whitespace;
> > append the comment and its pre-whitespace after the inserted operator (if
> > comment was present),
> > ie if no comment was present nothing will be inserted after the operator
> >
> > changes in v5: improve regex for comment and line end with '$;'
> >
> > changes in v6: remove if-check; modify commit message
> >
> > changes in v7: add an extra '$' symbol at '$fixed[$fixlinenr - 1]' regex
> > substitution to ensure match at line end
> >
> > scripts/checkpatch.pl | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 5b1a5a65e69a..fb3c50e0bde2 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -3553,8 +3553,16 @@ sub process {
> >
> >
> > # check for && or || at the start of a line
> > if ($rawline =~ /^\+\s*(&&|\|\|)/) {
> > - CHK("LOGICAL_CONTINUATIONS",
> > - "Logical continuations should be on the previous
> > line\n" . $hereprev);
> > + my $operator = $1;
> > + if (CHK("LOGICAL_CONTINUATIONS",
> > + "Logical continuations should be on the
> > previous line\n" . $hereprev) &&
> > + $fix && $prevrawline =~ /^\+/) {
> > + # insert logical operator at last non-comment,
> > non-whitepsace char on previous line
> > + $prevline =~ /[\s$;]*$/;
> > + my $line_end = substr($prevrawline, $-[0]);
> > + $fixed[$fixlinenr - 1] =~ s/\Q$line_end\E$/
> > $operator$line_end/;
> > + $fixed[$fixlinenr] =~ s/\Q$operator\E\s*//;
> > + }
> > }
> >
> >
> > # check indentation starts on a tab stop
> >
>
> Hi Joe
> You probably missed this patch. Please review :)
>
> Thanks
> Aditya
Re: [PATCH v4 2/5] drm: panel: simple: Defer unprepare delay till next prepare to shorten it
Hi Douglas, On Mon, Nov 09, 2020 at 05:00:56PM -0800, Douglas Anderson wrote: > It is believed that all of the current users of the "unprepare" delay > don't actually need to wait the amount of time specified directly in > the unprepare phase. The purpose of the delay that's specified is to > allow the panel to fully power off so that we don't try to power it > back on before it's managed to full power down. > > Let's use this observation to avoid the fixed delay that we currently > have. Instead of delaying, we'll note the current time when the > unprepare happens. If someone then tries to prepare the panel later > and not enough time has passed, we'll do the delay before starting the > prepare phase. > > Signed-off-by: Douglas Anderson Applied to drm-misc-next. Sam
Re: [PATCH] drivers: gpio: add virtio-gpio guest driver
Hi, On Fri, Nov 27, 2020 at 07:30:03PM +0100, Enrico Weigelt, metux IT consult wrote: > Introducing new gpio driver for virtual GPIO devices via virtio. > > The driver allows routing gpio control into VM guests, eg. brigding > virtual gpios to specific host gpios, or attaching simulators for > automatic application testing. > > Signed-off-by: Enrico Weigelt, metux IT consult is there a spec of the virtio-gpio protocol available? If so, linking it in the commit message and/or driver/Kconfig would be nice. Best regards, Jonathan Neuschäfer signature.asc Description: PGP signature
Re: [PATCH v4 3/5] drm: panel: simple: Allow specifying the delay from prepare to enable
Hi Douglas, On Mon, Nov 09, 2020 at 05:00:57PM -0800, Douglas Anderson wrote: > On the panel I'm looking at, there's an 80 ms minimum time between HPD > being asserted by the panel and setting the backlight enable GPIO. > While we could just add an 80 ms "enable" delay, this is not ideal. > Link training is allowed to happen in parallel with this delay so the > fixed 80 ms delay over-delays. > > We'll support this by logging the time at the end of prepare and then > delaying in enable if enough time hasn't passed. > > Signed-off-by: Douglas Anderson Applied too. Sam
Re: [PATCH v4 4/5] drm: panel: simple: Add BOE NV110WTM-N61
Hi Douglas, On Mon, Nov 09, 2020 at 05:00:58PM -0800, Douglas Anderson wrote: > Add support for the BOE NV110WTM-N61 panel. The EDID lists two modes > (one for 60 Hz refresh rate and one for 40 Hz), so we'll list both of > them here. > > Note that the panel datasheet requires 80 ms between HPD asserting and > the backlight power being turned on. We'll use the new timing > constraints structure to do this cleanly. This assumes that the > backlight will be enabled _after_ the panel enable finishes. This is > how it works today and seems a sane assumption. > > Signed-off-by: Douglas Anderson I applied the binding patch (bindings before driver patch), and added the missing flags while applying this patch. All to drm-misc-next. Sam
Re: [PATCH v4 1/5] drm: panel: simple: Fixup the struct panel_desc kernel doc
Hi Douglas, On Mon, Nov 09, 2020 at 05:00:55PM -0800, Douglas Anderson wrote: > When I run: > scripts/kernel-doc -rst drivers/gpu/drm/panel/panel-simple.c > > I see that several of the kernel-doc entries aren't showing up because > they don't specify the full path down the hierarchy. Let's fix that > and also move to inline kernel docs. > > Signed-off-by: Douglas Anderson Thanks, applied to drm-misc-next. Could you do a follow-up patch that moves the rest as inline comments and verify that all fields are described. (W=1 should show no warnings). That would be appreciated! Sam
[PATCH v2 2/3] net: fsl: fec: add mdc/mdio bitbang option
This patch adds the ability for the fec to use the
mdc/mdio bitbang protocol to communicate with its phy.
It adds two new optional parameters in the
devicetree definition for the two needed GPIO (mdc and mdio).
It uses the mdio-bitbang generic implementation.
Signed-off-by: Adrien Grassein
---
drivers/net/ethernet/freescale/fec.h | 5 ++
drivers/net/ethernet/freescale/fec_main.c | 101 +++---
2 files changed, 95 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.h
b/drivers/net/ethernet/freescale/fec.h
index c527f4ee1d3a..84bf9be4c6f5 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -15,6 +15,7 @@
//
#include
+#include
#include
#include
#include
@@ -590,6 +591,10 @@ struct fec_enet_private {
int pps_enable;
unsigned int next_counter;
+ struct mdiobb_ctrl fec_main_bb_ctrl;
+ struct gpio_desc *gd_mdc;
+ struct gpio_desc *gd_mdio;
+
u64 ethtool_stats[];
};
diff --git a/drivers/net/ethernet/freescale/fec_main.c
b/drivers/net/ethernet/freescale/fec_main.c
index 04f24c66cf36..4f22c8e3fe7e 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2050,6 +2050,48 @@ static int fec_enet_mii_probe(struct net_device *ndev)
return 0;
}
+static void fec_main_bb_ctrl_set_mdc(struct mdiobb_ctrl *ctrl, int level)
+{
+ struct fec_enet_private *fep = container_of(ctrl,
+ struct
fec_enet_private, fec_main_bb_ctrl);
+ if (level)
+ gpiod_direction_input(fep->gd_mdc);
+ else
+ gpiod_direction_output(fep->gd_mdc, 0);
+}
+
+static void fec_main_bb_ctrl_set_mdio_dir(struct mdiobb_ctrl *ctrl, int output)
+{
+ struct fec_enet_private *fep = container_of(ctrl,
+ struct
fec_enet_private, fec_main_bb_ctrl);
+ if (output)
+ gpiod_direction_output(fep->gd_mdio, 0);
+ else
+ gpiod_direction_input(fep->gd_mdio);
+}
+
+static void fec_main_bb_ctrl_set_mdio_data(struct mdiobb_ctrl *ctrl, int value)
+{
+ struct fec_enet_private *fep = container_of(ctrl,
+ struct
fec_enet_private, fec_main_bb_ctrl);
+ gpiod_direction_output(fep->gd_mdio, value);
+}
+
+static int fec_main_bb_ctrl_get_mdio_data(struct mdiobb_ctrl *ctrl)
+{
+ struct fec_enet_private *fep = container_of(ctrl,
+ struct
fec_enet_private, fec_main_bb_ctrl);
+ return gpiod_get_value(fep->gd_mdio);
+}
+
+static const struct mdiobb_ops fec_main_bb_ops = {
+ .owner = THIS_MODULE,
+ .set_mdc = fec_main_bb_ctrl_set_mdc,
+ .set_mdio_dir = fec_main_bb_ctrl_set_mdio_dir,
+ .set_mdio_data = fec_main_bb_ctrl_set_mdio_data,
+ .get_mdio_data = fec_main_bb_ctrl_get_mdio_data,
+};
+
static int fec_enet_mii_init(struct platform_device *pdev)
{
static struct mii_bus *fec0_mii_bus;
@@ -2150,18 +2192,27 @@ static int fec_enet_mii_init(struct platform_device
*pdev)
/* Clear any pending transaction complete indication */
writel(FEC_ENET_MII, fep->hwp + FEC_IEVENT);
- fep->mii_bus = mdiobus_alloc();
- if (fep->mii_bus == NULL) {
- err = -ENOMEM;
- goto err_out;
- }
+ if (fep->gd_mdc && fep->gd_mdio) {
+ fep->fec_main_bb_ctrl.ops = &fec_main_bb_ops;
+ fep->mii_bus = alloc_mdio_bitbang(&fep->fec_main_bb_ctrl);
+ if (!fep->mii_bus) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+ } else {
+ fep->mii_bus = mdiobus_alloc();
+ if (!fep->mii_bus) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+ fep->mii_bus->read = fec_enet_mdio_read;
+ fep->mii_bus->write = fec_enet_mdio_write;
- fep->mii_bus->name = "fec_enet_mii_bus";
- fep->mii_bus->read = fec_enet_mdio_read;
- fep->mii_bus->write = fec_enet_mdio_write;
+ fep->mii_bus->priv = fep;
+ }
snprintf(fep->mii_bus->id, MII_BUS_ID_SIZE, "%s-%x",
pdev->name, fep->dev_id + 1);
- fep->mii_bus->priv = fep;
+ fep->mii_bus->name = "fec_enet_mii_bus";
fep->mii_bus->parent = &pdev->dev;
err = of_mdiobus_register(fep->mii_bus, node);
@@ -2178,7 +2229,10 @@ static int fec_enet_mii_init(struct platform_device
*pdev)
return 0;
err_out_free_mdiobus:
- mdiobus_free(fep->mii_bus);
+ if (fep->gd_mdc && fep->gd_mdio)
+ free_mdio_bitbang(fep->mii_bus);
+ else
+ mdiobus_free(fep->mii_bus);
err_out:
[PATCH v2 3/3] net: fsl: fec: add imx8mq support.
This patch adds the imx8mq support to the
fsl fec driver.
Quirks are extracted from the NXP driver (5.4).
Signed-off-by: Adrien Grassein
---
drivers/net/ethernet/freescale/fec_main.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fec_main.c
b/drivers/net/ethernet/freescale/fec_main.c
index 4f22c8e3fe7e..a4bb1adbf9ed 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -131,6 +131,14 @@ static const struct fec_devinfo fec_imx6ul_info = {
FEC_QUIRK_HAS_COALESCE | FEC_QUIRK_CLEAR_SETUP_MII,
};
+static const struct fec_devinfo fec_imx8mq_info = {
+ .quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
+ FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM |
+ FEC_QUIRK_HAS_VLAN | FEC_QUIRK_HAS_AVB |
+ FEC_QUIRK_ERR007885 | FEC_QUIRK_BUG_CAPTURE |
+ FEC_QUIRK_HAS_RACC | FEC_QUIRK_HAS_COALESCE
+};
+
static struct platform_device_id fec_devtype[] = {
{
/* keep it for coldfire */
@@ -158,6 +166,11 @@ static struct platform_device_id fec_devtype[] = {
.name = "imx6ul-fec",
.driver_data = (kernel_ulong_t)&fec_imx6ul_info,
}, {
+ .name = "imx8mq-fec",
+ .driver_data = (kernel_ulong_t)&fec_imx8mq_info,
+ },
+
+ {
/* sentinel */
}
};
@@ -171,6 +184,7 @@ enum imx_fec_type {
MVF600_FEC,
IMX6SX_FEC,
IMX6UL_FEC,
+ IMX8MQ_FEC,
};
static const struct of_device_id fec_dt_ids[] = {
@@ -181,6 +195,8 @@ static const struct of_device_id fec_dt_ids[] = {
{ .compatible = "fsl,mvf600-fec", .data = &fec_devtype[MVF600_FEC], },
{ .compatible = "fsl,imx6sx-fec", .data = &fec_devtype[IMX6SX_FEC], },
{ .compatible = "fsl,imx6ul-fec", .data = &fec_devtype[IMX6UL_FEC], },
+ { .compatible = "fsl,imx8mq-fec", .data = &fec_devtype[IMX8MQ_FEC], },
+
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, fec_dt_ids);
--
2.20.1
[PATCH v2 1/3] dt-bindings: net: fsl-fec add mdc/mdio bitbang option
Add dt-bindings explanation for the two new gpios (mdio and mdc) used for bitbanging. Signed-off-by: Adrien Grassein --- Documentation/devicetree/bindings/net/fsl-fec.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt index 9b543789cd52..e9fa992354b7 100644 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt @@ -22,6 +22,10 @@ Optional properties: - fsl,err006687-workaround-present: If present indicates that the system has the hardware workaround for ERR006687 applied and does not need a software workaround. +- mdc-gpios: Bitbanged MDIO Management Data Clock GPIO. If specified, +mdio-gpios should be specified too. +- mdio-gpios: Bitbanged MDIO Management Data I/O GPIO. If specified, +mdc-gpios should be specified too. - fsl,stop-mode: register bits of stop mode control, the format is <&gpr req_gpr req_bit>. gpr is the phandle to general purpose register node. -- 2.20.1
Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC
Hi Florian,
> On 11/27/2020 4:33 PM, Lukasz Majewski wrote:
> >> So why use DSA at all? What benefit does it bring you? Why not do
> >> the entire switch configuration from within FEC, or a separate
> >> driver very closely related to it?
> >
> > Mine rationale to use DSA and FEC:
> > - Make as little changes to FEC as possible
>
> Which is entirely possible if you stick to Vladimir suggestions of
> exporting services for the MTIP switch driver.
Ok.
>
> >
> > - Provide separate driver to allow programming FDB, MDB, VLAN setup.
> > This seems straightforward as MTIP has separate memory region
> > (from FEC) for switch configuration, statistics, learning, static
> > table programming. What is even more bizarre FEC and MTIP have the
> > same 8 registers (with different base address and +4 offset :-) ) as
> > interface to handle DMA0 transfers.
>
> OK, not sure how that is relevant here? The register organization
> should never ever dictate how to pick a particular subsystem.
>
> >
> > - According to MTIP description from NXP documentation, there is a
> > separate register for frame forwarding, so it _shall_ also fit
> > into DSA.
>
> And yet it does not, Vladimir went into great length into explaining
> what makes the MTIP + dual FEC different here and why it does not
> qualify for DSA.
I'm very grateful for this insight and explanation from Vladimir.
> Basically any time you have DMA + integrated switch
> tightly coupled you have what we have coined a "pure switchdev"
> wrapper.
Ok.
>
> >
> >
> > For me it would be enough to have:
> >
> > - lan{12} - so I could enable/disable it on demand (control when
> > switch ports are passing or not packets).
> >
> > - Use standard net tools (like bridge) to setup FDB/MDB, vlan
> >
> > - Read statistics from MTIP ports (all of them)
> >
> > - I can use lan1 (bridged or not) to send data outside. It would be
> > also correct to use eth0.
>
> You know you can do that without having DSA, right? Look at mlxsw,
> look at rocker. You can call multiple times register_netdevice() with
> custom network devices that behave differently whether HW bridging
> offload is offered or not, whether the switch is declared in Device
> Tree or not.
I will look into those examples and try to follow them for MTIP.
>
> >
> > I'm for the most pragmatic (and simple) solution, which fulfill
> > above requirements.
>
> The most pragmatic solution is to implement switchdev operations to
> offer HW bridging offload, VLAN programming, FDB/MDB programming.
Ok.
>
> It seems to me that you are trying to look for a framework to avoid
> doing a bit of middle layer work between switchdev and the FEC driver
> and that is not setting you for success.
I'm not afraid to rework FEC. I just thought that DSA would be the best
fit for the MTIP. However, after posting the RFC, the community gave me
arguments that I was wrong.
I'm happy for having so detailed feedback :-).
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpZOvvHC3mHF.pgp
Description: OpenPGP digital signature
Re: [PATCH] hwmon: corsair-psu: update supported devices
On Sun, Nov 29, 2020 at 04:54:43PM +0100, Wilken Gottwalt wrote: > On Sun, 29 Nov 2020 05:00:49 -0800 > Guenter Roeck wrote: > > > On Sun, Nov 29, 2020 at 07:36:18AM +0100, Wilken Gottwalt wrote: > > > On Sat, 28 Nov 2020 17:21:40 -0300 > > > Jonas Malaco wrote: > > > > > > > On Sat, Nov 28, 2020 at 7:35 AM Wilken Gottwalt > > > > wrote: > > > > > > > > > > On Sat, 28 Nov 2020 02:37:38 -0300 > > > > > Jonas Malaco wrote: > > > > > > > > > > > On Thu, Nov 26, 2020 at 8:43 AM Wilken Gottwalt > > > > > > wrote: > > > > > > > > > > > > > > Adds support for another Corsair PSUs series: AX760i, AX860i, > > > > > > > AX1200i, > > > > > > > AX1500i and AX1600i. The first 3 power supplies are supported > > > > > > > through > > > > > > > the Corsair Link USB Dongle which is some kind of USB/Serial/TTL > > > > > > > converter especially made for the COM ports of these power > > > > > > > supplies. > > > > > > > There are 3 known revisions of these adapters. The AX1500i power > > > > > > > supply > > > > > > > has revision 3 built into the case and AX1600i is the only one in > > > > > > > that > > > > > > > series, which has an unique usb hid id like the RM/RX series. > > > > > > > > > > > > Can I ask what AXi power supplies were tested? > > > > > > > > > > > > I ask because, based on the user-space implementations I am aware > > > > > > of, > > > > > > the AXi dongle protocol appears to be different from the RMi/HXi > > > > > > series. > > > > > > > > > > I was not able to test this against the AX power supplies, they are > > > > > really > > > > > hard to find (and are far to expensive). But I went through all these > > > > > tools > > > > > and stuck to the most common commands, which all 3 series support. > > > > > Not every > > > > > series supports all commands (there also seem to be different > > > > > firmwares in > > > > > the micro-conrollers). But this is fine, some sensors will show up as > > > > > N/A. > > > > > Even my HX850i does not support all commands covered in this driver. > > > > > > > > I think the similarities come from all using wrappers over the PMBus > > > > interface to the voltage controller. But I am not sure the wrapping > > > > protocols are identical. > > > > > > > > For example, cpsumon shows significantly more things going on during a > > > > read than what is needed for the RMi/HXi series.[1] > > > > > > > > [1] > > > > https://github.com/ka87/cpsumon/blob/fd639684d7f9/libcpsumon/src/cpsumon.c#L213-L231 > > > > > > > > > > > > > > > > > > > AXi dongle: > > > > > > - https://github.com/ka87/cpsumon > > > > > > > > > > This tool made me to consider including the AX series, because it > > > > > uses some > > > > > of the same commands on the AX760i, AX860i, AX1200i and AX1500i. But > > > > > it is > > > > > a usb-serial tool only. But it was nice to know, that the commands > > > > > are mostly > > > > > the same. I left out all the commands for configuring, PCIe power > > > > > rails, > > > > > efficiency and others which do not really belong into hwmon. > > > > > > > > > > > RMi/HXi: > > > > > > - https://github.com/jonasmalacofilho/liquidctl > > > > > > - https://github.com/audiohacked/OpenCorsairLink > > > > > > > > > > This tool made me include the AX series, because it uses the rmi > > > > > protocol > > > > > component for the rmi driver (RM/HX series) and the corsair dongles. > > > > > > > > The corsairlink_driver_dongle has no implementations for reading sensor > > > > data (compare that with the corsairlink_driver_rmi).[2][3] There is > > > > also no code that actually tries to read (write) from (to) the device > > > > using that dongle driver.[4] > > > > > > > > I also looked at a few of the issues, and all of the ones I read > > > > mentioned AXi support being under development, and the hypothesis of the > > > > AXi series being compatible with the RMi/HXi code still remaining to be > > > > confirmed. > > > > > > > > [2] > > > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/drivers/dongle.c#L33-L39 > > > > [3] > > > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/drivers/rmi.c#L33-L57 > > > > [4] > > > > https://github.com/audiohacked/OpenCorsairLink/blob/61d336a61b85/main.c#L106 > > > > > > > > > > > > > > > > > > > - https://github.com/notaz/corsairmi > > > > > > > > > > This one covers only some HX/RM PSUs, but is uses the rawhid access > > > > > which > > > > > made me looking up the actual usb chips/bridges Corsair uses. > > > > > > > > > > > > > > > > > One additional concern is that the non-HID AXi dongles may only > > > > > > have bulk > > > > > > USB endpoints, and this is a HID driver.[1] > > > > > > > > > > You are right, in the case of the dongles it could be different. But > > > > > I did > > > > > some research on Corsair usb driven devices and they really like to > > > > > stick to > > > > > the cp210x, which is an usb hid bridge. The commit > > > > > b9326057a3d8447f5d2e74a7
Re: [PATCH 0/3] drm/ingenic: Add support for delta-RGB panels
Hi Paul. On Thu, Nov 19, 2020 at 03:55:56PM +, Paul Cercueil wrote: > Hi, > > This patchset adds support for delta-RGB panels to the ingenic-drm > driver. Delta-RGB panels have diamond-pattern subpixel layout, and > expect odd lines to have RGB subpixel ordering, and even lines to have > GBR subpixel ordering. > > Such panel is used in the YLM (aka. Anbernic) RG-99, RG-300, RG-280M > and RG-280V handheld gaming consoles. > > Cheers, > -Paul > > Paul Cercueil (3): > drm/ingenic: Compute timings according to adjusted_mode->crtc_* > drm/ingenic: Properly compute timings when using a 3x8-bit panel > drm/ingenic: Add support for serial 8-bit delta-RGB panels Strange panel, at least strange bit order. Patches looks good and are all: Reviewed-by: Sam Ravnborg
Re: [PATCH] omapfb: fbcon: remove trailing semicolon in macro definition
Hi Tom, On Fri, Nov 27, 2020 at 11:05:08AM -0800, t...@redhat.com wrote: > From: Tom Rix > > The macro use will already have a semicolon. > > Signed-off-by: Tom Rix Thanks, applied to drm-misc-next. Sam
[PATCH] This is a driver for the HXi series of Corsair ATX power supplies.
It is based on Marius Zachmann's corsair-cpro driver, since it follows a similar communication pattern, just with a different protocol. The devices: Corsair's HXi line of "smart" power supplies that provide monitoring data via a proprietary USB-HID interface. The protocol strongly resembles PMBus, and gives access to voltage, current, and power measurements for each of the PSU's rails. The driver: Again, I based this heavily on the corsair-cpro driver as the requirements are very similar (weird USB-HID communication, maintaining compatibility with existing userspace tools, providing hardware monitoring data). I've tested the driver pretty thoroughly on my HX850i, and existing userspace tools show that the protocol is common to all HXi series PSUs. I'm looking to acquire some more Corsair PSU variants (RMi, and AXi), to see if support can be expanded to them as well. I do not work for Corsair and I intend to keep this driver maintainted as long as I feasibly can. Signed-off-by: Jack Doan --- Documentation/hwmon/corsair-hxi-psu.rst | 50 +++ Documentation/hwmon/index.rst | 1 + MAINTAINERS | 6 + drivers/hwmon/Kconfig | 10 + drivers/hwmon/Makefile | 1 + drivers/hwmon/corsair-hxi-psu.c | 504 6 files changed, 572 insertions(+) create mode 100644 Documentation/hwmon/corsair-hxi-psu.rst create mode 100644 drivers/hwmon/corsair-hxi-psu.c diff --git a/Documentation/hwmon/corsair-hxi-psu.rst b/Documentation/hwmon/corsair-hxi-psu.rst new file mode 100644 index ..91d6beb36f88 --- /dev/null +++ b/Documentation/hwmon/corsair-hxi-psu.rst @@ -0,0 +1,50 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver corsair-hxi-psu +== + +Supported devices: + + * Corsair HXi ATX power supplies (HX750i, HX850i, HX1000i and HX1200i) + +Author: Jack Doan + +Description +--- + +This driver provides a sysfs interface for the Corsair HXi series of ATX +power supplies. + +Usage Notes +--- + +Since it is a USB device, hot-swapping is possible. The device is auto-detected. + +Sysfs entries +- + +* in0_input / in0_labelVoltage on ATX_12V +* in1_input / in1_labelVoltage on ATX_5V +* in2_input / in2_labelVoltage on ATX_3V +* in3_input / in3_labelInput AC voltage + +* curr0_input / curr0_labelCurrent on ATX_12V +* curr1_input / curr1_labelCurrent on ATX_5V +* curr2_input / curr2_labelCurrent on ATX_3V + +* power1_input / power1_labelPower on ATX_12V +* power2_input / power2_labelPower on ATX_5V +* power3_input / power3_labelPower on ATX_3V +* power4_input / power4_labelTotal AC Power + +* temp1_input Temperature before PSU fan +* temp2_input Temperature after PSU fan + +Future work + + +* Adding support for monitoring and control of the fan +* Getting and setting the overcurrent-protection mode +* Testing on other lines of Corsair PSUs (RMi, AXi) +* Broadening support to other "smart" ATX PSUs (NZXT, Seasonic) +* Potentially pulling this into the PMBus code diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index b797db738225..afa598fee1e6 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -49,6 +49,7 @@ Hardware Monitoring Kernel Drivers bt1-pvt coretemp corsair-cpro + corsair-hxi-psu da9052 da9055 dell-smm-hwmon diff --git a/MAINTAINERS b/MAINTAINERS index 2daa6ee673f7..2c84a0820ef5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4485,6 +4485,12 @@ L: linux-hw...@vger.kernel.org S: Maintained F: drivers/hwmon/corsair-cpro.c +CORSAIR-HXI-PSU HARDWARE MONITOR DRIVER +M: Jack Doan +L: linux-hw...@vger.kernel.org +S: Maintained +F: drivers/hwmon/corsair-hxi-psu.c + COSA/SRP SYNC SERIAL DRIVER M: Jan "Yenya" Kasprzak S: Maintained diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index a850e4f0e0bd..fd28bb859199 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -449,6 +449,16 @@ config SENSORS_CORSAIR_CPRO This driver can also be built as a module. If so, the module will be called corsair-cpro. +config SENSORS_CORSAIR_HXI_PSU + tristate "Corsair HXi power supplies" + depends on HID + help + If you say yes here you get monitoring support for the Corsair HXi series + of ATX power supplies + + This driver can also be built as a module. If so, the module + will be called corsair-hxi-psu. + config SENSORS_DRIVETEMP tristate "Hard disk drives with temperature sensors" depends on SCSI && ATA diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 9db2903b61e5..8924270c60b7 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -57,6 +57,7 @@ obj-$(CONFIG_SENSORS_AXI_FAN_CONTROL) += axi-fan-control.o obj-$(CONFIG_SENSORS_BT1_PVT) +=
Re: [PATCH] mlxsw: switch from 'pci_' to 'dma_' API
Am 29.11.2020 um 22:17 schrieb Christophe JAILLET:
> he wrappers in include/linux/pci-dma-compat.h should go away.
>
> The patch has been generated with the coccinelle script below and has been
> hand modified to replace GFP_ with a correct flag.
> It has been compile tested.
>
> When memory is allocated in 'mlxsw_pci_queue_init()' and
> 'mlxsw_pci_fw_area_init()' GFP_KERNEL can be used because this flag is
> already used in the same function.
>
> When memory is allocated in 'mlxsw_pci_mbox_alloc()' GFP_KERNEL can be
> used because it is only called from a probe function. The call chain is:
> --> mlxsw_pci_probe
> --> mlxsw_pci_cmd_init
> --> mlxsw_pci_mbox_alloc
>
> @@
> @@
> -PCI_DMA_BIDIRECTIONAL
> +DMA_BIDIRECTIONAL
>
> @@
> @@
> -PCI_DMA_TODEVICE
> +DMA_TO_DEVICE
>
> @@
> @@
> -PCI_DMA_FROMDEVICE
> +DMA_FROM_DEVICE
>
> @@
> @@
> -PCI_DMA_NONE
> +DMA_NONE
>
> @@
> expression e1, e2, e3;
> @@
> -pci_alloc_consistent(e1, e2, e3)
> +dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
>
> @@
> expression e1, e2, e3;
> @@
> -pci_zalloc_consistent(e1, e2, e3)
> +dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
>
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_free_consistent(e1, e2, e3, e4)
> +dma_free_coherent(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_map_single(e1, e2, e3, e4)
> +dma_map_single(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_unmap_single(e1, e2, e3, e4)
> +dma_unmap_single(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4, e5;
> @@
> -pci_map_page(e1, e2, e3, e4, e5)
> +dma_map_page(&e1->dev, e2, e3, e4, e5)
>
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_unmap_page(e1, e2, e3, e4)
> +dma_unmap_page(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_map_sg(e1, e2, e3, e4)
> +dma_map_sg(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_unmap_sg(e1, e2, e3, e4)
> +dma_unmap_sg(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
> +dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_dma_sync_single_for_device(e1, e2, e3, e4)
> +dma_sync_single_for_device(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
> +dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2, e3, e4;
> @@
> -pci_dma_sync_sg_for_device(e1, e2, e3, e4)
> +dma_sync_sg_for_device(&e1->dev, e2, e3, e4)
>
> @@
> expression e1, e2;
> @@
> -pci_dma_mapping_error(e1, e2)
> +dma_mapping_error(&e1->dev, e2)
>
> @@
> expression e1, e2;
> @@
> -pci_set_dma_mask(e1, e2)
> +dma_set_mask(&e1->dev, e2)
>
> @@
> expression e1, e2;
> @@
> -pci_set_consistent_dma_mask(e1, e2)
> +dma_set_coherent_mask(&e1->dev, e2)
>
> Signed-off-by: Christophe JAILLET
> ---
> If needed, see post from Christoph Hellwig on the kernel-janitors ML:
>https://marc.info/?l=kernel-janitors&m=158745678307186&w=4
> ---
> drivers/net/ethernet/mellanox/mlxsw/pci.c | 52 +++
> 1 file changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c
> b/drivers/net/ethernet/mellanox/mlxsw/pci.c
> index 641cdd81882b..7519d3b6934e 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
> @@ -323,8 +323,8 @@ static int mlxsw_pci_wqe_frag_map(struct mlxsw_pci
> *mlxsw_pci, char *wqe,
> struct pci_dev *pdev = mlxsw_pci->pdev;
> dma_addr_t mapaddr;
>
> - mapaddr = pci_map_single(pdev, frag_data, frag_len, direction);
> - if (unlikely(pci_dma_mapping_error(pdev, mapaddr))) {
> + mapaddr = dma_map_single(&pdev->dev, frag_data, frag_len, direction);
> + if (unlikely(dma_mapping_error(&pdev->dev, mapaddr))) {
> dev_err_ratelimited(&pdev->dev, "failed to dma map tx frag\n");
> return -EIO;
> }
> @@ -342,7 +342,7 @@ static void mlxsw_pci_wqe_frag_unmap(struct mlxsw_pci
> *mlxsw_pci, char *wqe,
>
> if (!frag_len)
> return;
> - pci_unmap_single(pdev, mapaddr, frag_len, direction);
> + dma_unmap_single(&pdev->dev, mapaddr, frag_len, direction);
> }
>
> static int mlxsw_pci_rdq_skb_alloc(struct mlxsw_pci *mlxsw_pci,
> @@ -858,9 +858,9 @@ static int mlxsw_pci_queue_init(struct mlxsw_pci
> *mlxsw_pci, char *mbox,
> tasklet_setup(&q->tasklet, q_ops->tasklet);
>
> mem_item->size = MLXSW_PCI_AQ_SIZE;
> - mem_item->buf = pci_alloc_consistent(mlxsw_pci->pdev,
> - mem_item->size,
> - &mem_item->mapaddr);
> + mem_item->buf = dma_alloc_coherent(&mlxsw_pci->pdev->dev,
> +mem_item->size, &mem_item->mapad
[PATCH] mlxsw: switch from 'pci_' to 'dma_' API
he wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.
When memory is allocated in 'mlxsw_pci_queue_init()' and
'mlxsw_pci_fw_area_init()' GFP_KERNEL can be used because this flag is
already used in the same function.
When memory is allocated in 'mlxsw_pci_mbox_alloc()' GFP_KERNEL can be
used because it is only called from a probe function. The call chain is:
--> mlxsw_pci_probe
--> mlxsw_pci_cmd_init
--> mlxsw_pci_mbox_alloc
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
@@
-PCI_DMA_NONE
+DMA_NONE
@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(&e1->dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(&e1->dev, e2, e3, e4)
@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(&e1->dev, e2)
@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(&e1->dev, e2)
@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(&e1->dev, e2)
Signed-off-by: Christophe JAILLET
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors&m=158745678307186&w=4
---
drivers/net/ethernet/mellanox/mlxsw/pci.c | 52 +++
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c
b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index 641cdd81882b..7519d3b6934e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -323,8 +323,8 @@ static int mlxsw_pci_wqe_frag_map(struct mlxsw_pci
*mlxsw_pci, char *wqe,
struct pci_dev *pdev = mlxsw_pci->pdev;
dma_addr_t mapaddr;
- mapaddr = pci_map_single(pdev, frag_data, frag_len, direction);
- if (unlikely(pci_dma_mapping_error(pdev, mapaddr))) {
+ mapaddr = dma_map_single(&pdev->dev, frag_data, frag_len, direction);
+ if (unlikely(dma_mapping_error(&pdev->dev, mapaddr))) {
dev_err_ratelimited(&pdev->dev, "failed to dma map tx frag\n");
return -EIO;
}
@@ -342,7 +342,7 @@ static void mlxsw_pci_wqe_frag_unmap(struct mlxsw_pci
*mlxsw_pci, char *wqe,
if (!frag_len)
return;
- pci_unmap_single(pdev, mapaddr, frag_len, direction);
+ dma_unmap_single(&pdev->dev, mapaddr, frag_len, direction);
}
static int mlxsw_pci_rdq_skb_alloc(struct mlxsw_pci *mlxsw_pci,
@@ -858,9 +858,9 @@ static int mlxsw_pci_queue_init(struct mlxsw_pci
*mlxsw_pci, char *mbox,
tasklet_setup(&q->tasklet, q_ops->tasklet);
mem_item->size = MLXSW_PCI_AQ_SIZE;
- mem_item->buf = pci_alloc_consistent(mlxsw_pci->pdev,
-mem_item->size,
-&mem_item->mapaddr);
+ mem_item->buf = dma_alloc_coherent(&mlxsw_pci->pdev->dev,
+ mem_item->size, &mem_item->mapaddr,
+ GFP_KERNEL);
if (!mem_item->buf)
return -ENOMEM;
@@ -890,8 +890,8 @@ static int mlxsw_pci_queue_init(struct mlxsw_pci
*mlxsw_pci, char *mbox,
err_q_ops_init:
kfree(q->elem_info);
err_elem_info_alloc:
- pci_free_consistent(mlxsw_pci->pdev, mem_item->size,
-
